## 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 call, extend, or compose with that code without changing what it already does. This preserves the verified-stays-verified invariant — a completed, conformance-passed stage should not silently regress when a later stage runs. No code compares this stage's diff against the file set a preceding stage touched, so this rule reaches the run as an instruction, not as a gate. What is checked is narrower: the verifier's rejection survives synthesis (`validators/validate-run.py` `_validate_verifier_fail_blocks_verdict`) and a mutation outside the attempt's write policy is reported (`scripts/okstra_ctl/execution_mutation_audit.py` `_source_changes`). - **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 does 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 records 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.