| name | repair-spec-safely |
| description | Repair a candidate spec only after concrete readiness findings exist or the user explicitly requests repair. Convert findings into bounded edits while preserving fixed decisions, capability truth, scope, and intent; do not publish or claim readiness without reevaluation. |
Repair a spec safely
Produce a revised local candidate, a finding-resolution map, and an original-to-revised diff.
- Pin the original candidate hash, repository SHA, findings, fixed decisions, recent operator
decisions, and declared skills.
- Map every actionable finding to the smallest sufficient edit. Mark duplicates, unsupported
findings, and decision-blocked findings explicitly rather than rewriting around them.
- Preserve scope, compatibility posture, capability truth, and user intent. Never invent an
architecture, existing path, runtime feature, or external contract to satisfy the rubric.
- Compare original and revised claims. Stop if the repair changes a fixed decision, expands scope,
weakens a safety boundary, or requires a product/architecture choice.
- Stay within the configured correction budget. Do not recursively self-approve.
- Emit the full revised Markdown, the finding-to-edit resolution map, and a diff artifact.
- Run the normal evaluator afresh; only its new evidence may claim readiness.
Do not publish, loop past budget, or treat the absence of remaining prose findings as
SPEC_READY.
