## Stage discipline — preceding stages are behavior-frozen A stage that is already `done` — a `depends-on` predecessor whose work is merged into this run's base — is **behavior-frozen**: code it added or modified keeps its existing behavior. Later stages MAY call, extend, or compose with that code, but MUST NOT change what it already does. This preserves the verified-stays-verified invariant — a completed, conformance-passed stage must not silently regress when a later stage runs. - **implementation-planning** — decompose stages forward-only. No stage's scope may require altering an earlier stage's behavior; each stage builds additively on its predecessors' Stage Exit Contracts. If delivering an increment would force changing an earlier stage's behavior, that earlier stage was mis-scoped — fold the change into that stage or re-partition; do not plan a later stage that rewrites it. - **implementation** — the executor MUST NOT alter the behavior of any file added or modified by a preceding done stage. Touching such a file to *extend* it (a new branch, a new caller, an additive field) is allowed; changing its existing behavior is not. If a plan step appears to require a behavior change to prior-stage code, treat it as a planning defect. Do two things and only these: record the finding, then route to a new `implementation-planning` run. Never silently rewrite the prior-stage code. - **Report evidence (declaration-level).** When this stage modifies a file that a preceding stage added or modified, the final report MUST record three facts in the deliverable's edits / Validation Evidence section: which file, why it was touched, and how the prior stage's behavior was preserved. Absent that note, a reviewer treats a prior-stage edit as an unverified regression risk.