Skip to main content
Invoke: /feature-repair AB#1234 · Side effects: branch + commits · Writes: .shipflow/{id}/repair.md
Re-running the whole plan for one missed acceptance criterion is expensive and error-prone. This phase targets only what verify-report.md graded PARTIAL or MISSING (and any violated non-negotiable), on the same branch feature-implement created, then hands back to feature-verify for the same honest re-grade every other change gets.

​
Scope

Every AC already graded MET is out of bounds — this phase does not touch it. repair.md (from templates/repair.md) records each gap with verify’s own cited evidence and the minimal fix task(s) that close it, same “name real paths” discipline as feature-plan.

​
Fix, re-test, re-verify

One commit per repair task (fix: {summary} ({provider_ref}), same HARD git rules as feature-implement), then targeted test coverage for just the repaired AC(s), then a full re-verify — a scoped fix can regress something previously MET, and the re-verify catches that honestly.

​
Loop and stop conditions

  • READY → hand off to feature-pr as normal.
  • Still NOT READY on the same AC after one attempt → surfaced as a real blocker, not retried silently a second time.
  • NOT READY on a different, previously-MET AC → treated as a regression the repair caused; fixed in the same pass, and reported plainly.
  • If the gap reveals the original plan was wrong (not just incomplete) → recommends re-running feature-plan instead of forcing a repair that doesn’t fit.

​
Boundaries

Never repairs a MET AC. Never pushes, opens a PR, or updates work-item state — identical boundaries to feature-implement/feature-tests.