Give the scaffolder's foreign-file edits one whitespace rule

[seenu-k]

create-eigen-game owns most of what it writes — four template trees copied whole and token-substituted. Three edits are different: they modify files flutter create produced, in a directory flutterfire configure will edit next. This gives those three one shared rule and writes down the doctrine behind them.

The bug

Each of the three normalised newlines itself, with two different answers:

Site	Expression
desugaring	endsWith("\n") ? "\n" : "\n\n"
release signing	endsWith("\n") ? "" : "\n"
launcher icons	endsWith("\n") ? "" : "\n"

Desugaring always left a blank separator line, the other two never did. Since desugaring runs first and leaves a trailing newline, the release-signing block then landed flush against it in every generated project. appendBlock now owns the whitespace and nothing else — one blank line before, one newline after, block constants carrying neither — and the scaffold test pins the separation rather than only the contents.

Verified by rendering a scaffold against a realistic flutter create stub and reading the output; the appended blocks are now spaced like Flutter's own.

A comment that said the opposite of its code

A comment beside the release-signing block claimed it still prepends import java.util.Properties. That edit was removed when AGP 9 broke it — the block parses key.properties with the Kotlin stdlib now. The comment described the exact thing the surrounding code exists to avoid, so it is rewritten to record the history without claiming a prepend exists.

The doctrine, in MAINTAINERS.md

New section, Editing files the scaffolder does not own:

• Append, never insert, with the three edits tabled against the string that identifies each, and why includes("signingConfigs") would never fire (Flutter's own template already contains it).
• Why FlutterFire's // START:/// END: markers are deliberately not copied. They are attribution, not machinery: in flutterfire_cli 1.4.1 the two constants appear in ten places and every one is string construction — nothing reads them back. Its idempotency comes from contains(_googleServicesPluginClassPath), the same mechanism used here. FlutterFire needs a regex anchor because it must inject into the single permitted plugins { } block; an append needs no anchor, so a marker would add text without adding capability. One shared marker text also means it could not replace selectively even if it read them.
• The one condition that earns a marker pair: a block whose content must be found and replaced on a later run, which a content probe cannot do — includes("releaseKeyProperties") answers "is mine here?" but never "where does mine end?". That arrives with an upgrade command and not before, so the section records the shape to use then: one pair per block, versioned marker text, guarded on exactly one properly nested pair.
• Never in templates/ — those files are wholly owned and rendered whole.
• Configuration values are assigned, not appended, into the declared empty slots in wrangler.jsonc and app-config.json, plus the JSON-versus-JSONC rule: plain JSON is decoded and re-encoded, commented JSONC has its single assignment rewritten in place, and the safety there is the match count rather than the pattern.

A companion note lands in eigen-flutter's firebase_link.dart, where the JSONC half is implemented: eigeninteractive/eigen-flutter#36.

Verification

pnpm lint clean · pnpm -r typecheck clean · pnpm -r test 358 passed.

🤖 Generated with Claude Code