Repair and rerun

Use Reflow’s retained evidence and execution plan to diagnose a failure with your coding agent, then rerun the affected checks.

Use Reflow to inspect this failure. Determine whether the application regressed or the test needs updating, make the smallest justified repair, then plan and rerun the affected checks. Show me the before-and-after evidence and unresolved failures before preparing the PR.

Tests can be saved in Reflow or in your repository. Use a slug or test ID with plan/apply for either location; the paths below show repository examples. See test storage for selection and authoring.

The repair loop

1. Read the failed step, its inputs and retained evidence. Compare the result with the intended behavior and current application knowledge.
2. Fix the application or update an obsolete test within the requested scope. Preserve assertions that describe behavior the application must keep.
3. Keep the same target and run reflow plan. Changed flow steps, covered source files and dependency outputs invalidate affected evidence automatically.
4. Run reflow apply, inspect the actual outcomes and snapshots, and prepare the relevant delta for the PR. A successful command still needs its business result checked.

The Reflow skill guides your connected agent through MCP and the same tools as the CLI. No second model configuration is required.

Changes already select what reruns

Suppose checkout needs seed-customer. Changing the seed step means the next plan runs that step and the checkout work that depends on it. Unrelated matching work can reuse its evidence. If the browser session has ended, Reflow includes the steps needed to reconstruct it.

covers narrows which source files affect a flow. Without it, the known Git working tree is covered conservatively. Planning observes staged, unstaged and untracked non-ignored source changes; it does not execute steps or poll external systems for changes. Apply checks the current plan again before admission.

Source coverage through symbolic links

Links to files or directories inside the checkout can reuse evidence when both the link and its covered target contents are unchanged. Reflow fingerprints the resolved contents as well as the link, including executable permissions. A target edit, addition, deletion or changed link invalidates the affected coverage. covers can name the link path or its descendants, for example covers: ["shared-skills/**"].

Links resolved outside the checkout, broken or cyclic links, unreadable targets, submodules and targets outside the Git source inventory remain uncertain. Within a covered directory target, Git-ignored sibling files are excluded just as they are elsewhere in the checkout. A link directly to an ignored or wholly unrepresented target remains uncertain. Reflow does not read ignored target contents. Source inspection runs during planning and again before execution. Large checkouts with many links can take several seconds to inspect. Planning stops if link expansion exceeds its inspection bounds. Unresolved coverage keeps the affected steps selected for execution; narrowing covers is appropriate only when it accurately describes the source that affects that flow.

The improved source fingerprint requires one fresh execution after upgrading from a release that treated every link as uncertain. Subsequent unchanged plans can reuse that evidence. This does not resolve an unknown execution outcome or remove the need to inspect its effects before retrying.

reflow plan .reflow/flows/checkout.md
reflow apply .reflow/flows/checkout.md

When to request fresh evidence

If a database, feature flag or running application changed without a corresponding source or input change, the agent can use taint to request another observation:

reflow taint checkout
reflow plan .reflow/flows/checkout.md
reflow apply .reflow/flows/checkout.md

Use checkout#Confirm order to select a named step, quoted when it contains spaces. The plan includes its affected dependents. Taint does not undo external writes or clear live ownership. Named mailboxes and generated test values stay the same. Use reflow reset only when you intend to replace the selected group’s test data, then plan again. Reset does not delete application records or resolve uncertain execution. If completion is unknown, inspect the existing run and reconcile its effects before deliberately retrying. After an uncertain apply response, keep its request identity; a new request can repeat an external write.

Keep the repair meaningful

A selector can become obsolete; a missing role selector can be a regression. The agent must distinguish them using the requested change and application rules. It should stop when the intended behavior is unclear, access is missing, completion is uncertain, or the same failure repeats without progress. It reports the remaining problem instead of weakening assertions or accepting a different screenshot to make the run green.

The optional model-assisted browser runner has a narrower selector-repair feature. It requires configured provider authority and only replaces eligible element targets, preserving the verb, values and modifiers. Device execution can retain a repair proposal for a subsequent candidate run. It does not automatically apply that proposal. Assertions, visual mismatches and external commands are not silently healed. self_heal: false disables the separate in-run selector repair; it does not prevent your coding agent from making an ordinary, reviewable source change.

See Snapshots and review for browser, terminal and database evidence, and Write a flow for dependencies and variables.