plan-update ยท diff
git:20260717.e1d5341 to git:20260720.2e4f3b4
12 added, 18 removed. Audit A to A.
---
name: plan-update
- description: Make the smallest evidence-backed correction to an existing implementation plan. Use when implementation or validation proves incorrect ordering, a missing prerequisite or gate, an impossible instruction, a contradiction, an incomplete contract, or unjustified complexity.
+ description: Make the smallest evidence-backed correction to implementation-plan mechanics. Use when implementation or validation proves incorrect ordering, prerequisites, phase scope, dependencies, steps, or validation gates.
---
# Plan Update
- Correct a plan only when the current work proves it is wrong or incomplete. Do not use the plan as a progress log.
-
- ## Valid Reasons
-
- - The selected phase cannot be implemented safely as written.
- - Validation proves that a required step or gate is missing.
- - Phase order or dependencies are wrong.
- - A required validation gate is insufficient or impossible.
- - The plan contradicts an authoritative repository contract.
- - A concrete prerequisite must become part of the selected scope.
- - The phase prescribes complexity that repository evidence shows is unnecessary to satisfy its stated contract.
+ Correct an implementation plan without making product, architecture, or behavior decisions.
## Workflow
- 1. Identify the exact plan defect and affected phase.
- 2. Confirm it with repository or validation evidence.
- 3. Make the smallest correction.
- 4. Preserve the existing plan structure and style.
- 5. Continue the selected implementation or validation work after the correction.
+ 1. Identify the authoritative plan, exact mechanical defect, evidence, and affected phases.
+ 2. Confirm that the correction is local. Use `plan-create` when multiple phases require broad replanning.
+ 3. Use `spec-update` when the defect concerns product behavior, architecture semantics, a public contract, or acceptance meaning. Use `architecture-refine` when runtime architecture remains unsettled.
+ 4. For plans affecting long-running or distributed workloads, verify established guarantees cover restarts, rolling replacement, concurrent replicas, in-flight or duplicate work, partial failure, and recovery. Repair omissions only when repository evidence or a settled contract determines the behavior.
+ 5. Stop for user direction when the correction materially expands authorized scope.
+ 6. Apply the smallest correction in the plan's existing structure and style.
+ 7. Verify affected dependencies, cross-references, invariants, environmental and failure assumptions, acceptance evidence, and downstream phases remain consistent.
- Do not rewrite unrelated phases, add speculative roadmap work, duplicate implementation details already clear from code, or disguise scope expansion as plan maintenance.
+ Do not use plans as progress logs, add speculative roadmap work, rewrite unrelated phases, or disguise scope expansion as maintenance.
+
+ Finish by reporting the defect, evidence, exact correction, affected phases, and whether implementation or validation can safely resume.