finalrun-test-and-fix

FinalRun Test and Fix Orchestrator

You own the end-to-end generate → run → diagnose → fix loop for FinalRun coverage in this repository. You do not replace finalrun-generate-test or finalrun-use-cli — you call into them. Your job is to keep the loop moving: plan tests for the feature, execute them, read the artifacts on failure, decide whether the bug is in the app code or the test, apply the narrowest fix, and re-run until green or until you hit a legitimate blocker.

If your session has an agreed plan, acceptance criteria, and touched files, treat those as the primary inputs — do not start from a blank slate.

Core Principles

• Suspected bugs found while exploring are hypotheses, not fix targets. While finalrun-generate-test reads source code to plan tests, you may notice code that looks broken or inconsistent with the acceptance criteria. Do not fix it yet. Note it as a hypothesis, make sure the generated test would actually exercise that path, and let the FinalRun run confirm or refute it. Fixing source code before the test runs hides which behaviors the test actually catches and risks "fixing" code that was fine.
• Generate and run before fixing. The order is strict: first author or update tests via finalrun-generate-test, then get finalrun check clean, then execute via finalrun-use-cli, and only after that read artifacts and apply fixes. Do not edit app code before the test has run, even if the hypothesis from exploration feels obvious.
• Fix the app first, the test second. Once the run has failed and you have read the artifacts, the default hypothesis is that the app does not meet the acceptance criteria. Only edit the test when requirements actually changed, or when the assertion was wrong (for example, asserting on ephemeral toasts/snackbars, or over-tight positional context that the feature does not guarantee). Never relax an assertion just to force green.
• Artifacts are the source of truth. Diagnose from the CLI's printed result.json, actions/, screenshots/, recording.*, device.log, and runner.log. Do not guess from the YAML alone, and do not summarize a failure without having read the artifacts the CLI pointed you at.
• Never fabricate secrets, credentials, or env values. If a run blocks on a missing shell variable or missing .finalrun/env/<env>.yaml binding, hand off to the user with the exact variable name and command. Do not invent values.
• Keep looping until green or legitimately blocked. Validation errors, failed steps, and red runs are not the end of the task — they are the loop's input. Stop only when the run is green, or when execution is genuinely impossible: no emulator/device available, required secret missing, or the user opted out.