fix: name custom actions the way FlutterFlow files them

[sgardoll]

The bug

A deploy failed with:

init_qa_analytics.dart: Action "initQaAnalytics" declaration not found.

FlutterFlow snake_cases an artifact name naively — an underscore before every capital — so initQAAnalytics is filed as init_q_a_analytics.dart. The generated file used the human-idiomatic init_qa_analytics.dart, which the deploy reads back as initQaAnalytics, a name that appears nowhere in the code.

The same bundle shipped logAppError and logOpFailed, which round-tripped fine — no acronym, no loss. That contrast is what identified it, and both are now regression fixtures.

Fixes

getCustomActionFileNameError checks in FlutterFlow's own direction: the identifier derived from the file name must equal the declared function. It reuses deriveIdentifierName (now exported) instead of duplicating the derivation that goes over the wire — that duplication is exactly how a check drifts from reality. Wired into both validateDartFile (deploy gate) and validateArtifactCompatibility (review), because a rule in only one surface labels a finding blocking and then deploys it anyway.

The client validator could not have caught this before: normalizeFunctionName lowercases and strips punctuation, so initQAAnalytics and initQaAnalytics looked identical to it.

The CustomClass file-name rule went the other way and is relaxed. A Code File's path is a free-text field in the FlutterFlow editor, so q_a_service.dart holding class QAService is valid and deploys. The rule was blocking a pairing FlutterFlow accepts. It is now a review warning, removed from the deploy gate, with the false "FlutterFlow expects" wording dropped.

Also in here

• Summary tab. Manual steps never fed the status computation, yet rendered with the alert triangle in orange-900 rust next to a 95/100 score and all-green per-file ticks. Now an info icon, real amber, and a lead line stating they do not block. Red is reserved for what genuinely stops a push.
• Review contract asks for manualActions with explicit exclusions, so the review stops volunteering work FlutterFlow already does — creating the action, declaring parameters read off the signature. manualActions is the key the review stage already emits, with title/location/timing/detail.
• Workflow steps no longer name the model that runs each one.
• pub.dev version resolution (separate commit, pre-existing work): resolves a package's version against the project's SDK floor instead of pinning ^1.0.0, falling back to an unconstrained dependency rather than stalling a deploy.

Upstream

The root cause was the BuildShip system prompts, which never stated the naming rule. Those are corrected and deployed separately (buildship@1f406a0). This PR is the enforcement backstop: the prompts are guidance, these validators are the gate.

Verification

npm test 192/192 · npm run build clean · node --check app.js

One pre-existing fixture was corrected rather than the rule — a return-type test paired supported.dart with a loadProduct function, a combination FlutterFlow would genuinely reject.

Not visually verified: Chrome tooling failed throughout with a cross-extension error, so the Summary-tab restyle is confirmed by computed values and the emitted bundle, not by eye.

🤖 Generated with Claude Code

[greptile-apps]

Your organization has used all 50 credits included in the free plan this billing period. To keep receiving reviews, upgrade your plan.

[sgardoll]

@greptileai please review pr and resolve conflicts

[greptile-apps]

Greptile Summary

This PR aligns Custom Action filenames with FlutterFlow’s identifier derivation, relaxes Code File naming to advisory status, updates review/manual-action presentation, and adds SDK-aware pub.dev dependency resolution.

• Adds matching review and deploy validation for Custom Action filenames.
• Resolves missing package versions against project SDK constraints while preserving existing dependencies.
• Clarifies non-blocking manual steps and removes model names from workflow labels.

Confidence Score: 4/5

The dependency-resolution defect should be fixed before merging because projects using ^0.0.x packages can receive a pubspec that cannot satisfy generated code requirements.

The new caret arithmetic overstates the versions admitted by ^0.0.x constraints, causing dependency planning to preserve an incompatible existing pin instead of raising it to the generated code’s required patch.

Files Needing Attention: src/pubVersions.js, src/dependencyResolution.js

Important Files Changed

Filename	Overview
src/flutterFlowArtifactValidation.js	Adds a blocking Custom Action filename round-trip check and changes Custom Class filename mismatches to advisory findings.
src/flutterFlowSyncMetadata.js	Exports the existing filename-to-identifier derivation so validation and wire metadata share one implementation.
src/dependencyResolution.js	Plans dependency additions and overrides from project constraints, but inherits incorrect ^0.0.x reachability from the new constraint parser.
src/pubVersions.js	Implements version and constraint arithmetic; its caret upper bound is too broad for 0.0.x versions and can preserve an unusable project constraint.
src/pubRegistry.js	Selects non-retracted stable package releases compatible with the project’s declared SDK floors and falls back without throwing.
src/pubspecSync.js	Extends textual pubspec parsing and mutation to preserve existing structure while applying planned dependency overrides.
app.js	Integrates filename validation, dependency planning, and updated Summary-tab/manual-step presentation into deploy and UI flows.
src/bundleDeployPlanner.js	Carries only explicitly required dependency minima and leaves inferred package versions for project-aware resolution.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  A[Generated artifact dependencies] --> B[Bundle deploy plan]
  B --> C[Read project pubspec]
  C --> D[Parse SDK floors and existing constraints]
  D --> E{Dependency already declared?}
  E -- Yes --> F[Check whether constraint reaches required minimum]
  E -- No --> G[Resolve compatible pub.dev release]
  F --> H[Keep or override constraint]
  G --> I[Add resolved or unconstrained dependency]
  H --> J[Merge complete pubspec]
  I --> J
  J --> K[FlutterFlow deploy]

Loading

Prompt To Fix All With AI

### Issue 1
src/pubVersions.js:78-83
**Incorrect zero-major caret bound**

When generated code requires a newer patch than an existing `^0.0.x` dependency, this upper-bound calculation treats the constraint as reaching the next minor version, so dependency planning preserves an incompatible constraint and the FlutterFlow project build can fail.

```suggestion
function caretUpperBound(version) {
  const parsed = parseVersion(version);
  if (!parsed) return null;
  if (parsed.major > 0) return `${parsed.major + 1}.0.0`;
  if (parsed.minor > 0) return `0.${parsed.minor + 1}.0`;
  return `0.0.${parsed.patch + 1}`;
}
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "fix: name custom actions the way Flutter..." | Re-trigger Greptile}

[greptile-apps]

Incorrect zero-major caret bound

When generated code requires a newer patch than an existing ^0.0.x dependency, this upper-bound calculation treats the constraint as reaching the next minor version, so dependency planning preserves an incompatible constraint and the FlutterFlow project build can fail.

Suggested change

	function caretUpperBound(version) {
	const parsed = parseVersion(version);
	if (!parsed) return null;
	if (parsed.major > 0) return `${parsed.major + 1}.0.0`;
	return `0.${parsed.minor + 1}.0`;
	}
	function caretUpperBound(version) {
	const parsed = parseVersion(version);
	if (!parsed) return null;
	if (parsed.major > 0) return `${parsed.major + 1}.0.0`;
	if (parsed.minor > 0) return `0.${parsed.minor + 1}.0`;
	return `0.0.${parsed.patch + 1}`;
	}

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/pubVersions.js
Line: 78-83

Comment:
**Incorrect zero-major caret bound**

When generated code requires a newer patch than an existing `^0.0.x` dependency, this upper-bound calculation treats the constraint as reaching the next minor version, so dependency planning preserves an incompatible constraint and the FlutterFlow project build can fail.

```suggestion
function caretUpperBound(version) {
  const parsed = parseVersion(version);
  if (!parsed) return null;
  if (parsed.major > 0) return `${parsed.major + 1}.0.0`;
  if (parsed.minor > 0) return `0.${parsed.minor + 1}.0`;
  return `0.0.${parsed.patch + 1}`;
}
```

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.