test(app): pin the template install-failure polarity as a pure function (#10074)

[aryanorastar]

Summary

The regression test #10100 deferred. #10100 fixed the quick-template sheet so a failed install is surfaced as an error instead of a false success (#10074), but shipped without a regression test — the decision lived inline in the widget's post-await branch, unreachable by a hermetic test without a full widget harness (five stubbed API calls plus path_provider platform channels).

This extracts only that decision — the success/error polarity of the terminal outcome — into templateCreationOutcomeIsError, a pure function the sheet now derives its install-branch snackbar from. Everything else is byte-identical to #10100.

• New TemplateCreationOutcome enum + templateCreationOutcomeIsError (one pure file, no Flutter deps).
• The sheet's install branch sources its success/error choice from the classifier instead of an inline bool; the arm order flips (error-first) but the behavior is identical.
• Unit tests pin the full outcome table, including installFailed → error — the Bug: summary template set as standard/default is not being applied #10074 guarantee — so the failed-install-reads-as-success regression cannot be silently reintroduced.

Behavior identity (verified line-by-line)

Diff is the import line + the install-branch arm-swap; nothing else in _createTemplate changed. Confirmed unchanged vs the #10100 baseline: quickTemplateCreated analytics timing (still fires on submit success, before install), getApps() ordering (still before install), the if (mounted && createdApp != null) gating (so a mid-flow sheet dismissal still cancels install exactly as before), the createdWithoutInstall/submitFailed branches, and the catch block.

• success → installed → not error → appCreatedAndInstalled + summarized-apps sheet
• !success → installFailed → error → failedToInstallApp (provider already showed its dialog)

Failure class

Failure-Class: none

test: commit — adds the regression coverage a prior fix: (#10100) deferred; no new triggering defect.

Product invariants affected

none (verified with scripts/pr-preflight --suggest)

Validation

• Five hermetic unit tests (app/test/unit/template_creation_outcome_test.dart) pin the table: installFailed → true and submitFailed → true (errors); installed → false and createdWithoutInstall → false (success); plus an exhaustiveness assertion that exactly {submitFailed, installFailed} read as errors. Each calls the exact function production calls — flipping the classifier fails the test.
• Not run locally — no Flutter SDK on this machine (same stated constraint as fix(users): gate multi-language mode by the live STT capability policy #10097/fix(app): stop reporting a failed template install as success #10100/refactor(app): trust the server's single_language_mode, drop the client mirror (after #10097) #10126, all merged/approved); tests are hermetic and the app CI lane runs them.
• Behavior identity and analyzer-cleanliness (imports used, exhaustive switch, no use_build_context_synchronously regression, createdApp.name non-null promotion intact) independently reviewed against the fix(app): stop reporting a failed template install as success #10100 baseline before opening.
• make preflight (local lane, this PR body) → all selected checks pass.

Out of scope, named

• The submitFailed/createdWithoutInstall outcomes are classified and tested but the sheet's other two branches still snackbar inline (they were never the Bug: summary template set as standard/default is not being applied #10074 surface and have a single, unconditional polarity). Routing them through the classifier too would be ceremony, not safety.
• A broader flow-orchestration extraction was considered and dropped: it drifted analytics timing, getApps() ordering, and mid-dismiss install behavior for no gain over this focused pin.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Git-on-my-level]

Nice follow-up to #10100 — this cleanly closes the deferred-test gap: the install-failure polarity is now a pure, hermetically-testable function, and the sheet derives its snackbar from it.

What I verified:

• Behavior identity holds. The install branch is an arm-swap (error-first) with the same snackbar calls and the same mounted && createdApp != null gating: success → installed → success snackbar + summarized sheet, !success → installFailed → error snackbar. Identical to fix(app): stop reporting a failed template install as success #10100.
• The classifier is exhaustive and correct. installFailed and submitFailed read as errors; installed and createdWithoutInstall read as success — exactly the Bug: summary template set as standard/default is not being applied #10074 guarantee.
• The five unit tests pin the full table, including installFailed → error, so the failed-install-reads-as-success regression cannot be silently reintroduced. Flipping the classifier breaks them.
• Checks are green on the current head (Android Compile Smoke, Dart Analyze ratchet, Flutter Tests, Generated Files all pass; the earlier cancelled/skipped preflight runs were from prior pushes).
• Leaving submitFailed/createdWithoutInstall snackbar-ing inline is a reasonable call — single unconditional polarity, never the Bug: summary template set as standard/default is not being applied #10074 surface — and the classifier still handles them for future-proofing.

Small, cohesive, low-risk. I am leaving a positive signal rather than formal approval (automation is gated from approving on this one); a maintainer can merge this with confidence. Thanks @aryanorastar for closing the test gap properly.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[kodjima33]

Test-only (app): pins template install-failure polarity as a pure function (#10074) — approve only per policy (mobile area, not a bug fix to merge)