spec-maintainlisted

# Spec: Maintain ## Overview Maintain updates specs to reflect a completed change. It does not scan the diff and silently infer — code reveals what changed, not why, and cannot surface decisions that were considered and rejected. Confirmation comes first. ## Confirm Before Touching Specs Before writing any update, present your understanding of what changed and ask three targeted questions: **1. Scope confirmation** "I see this change touched [list of areas]. Did it affect any other capability I've missed?" **2. Decisions not in the diff** "Were any decisions made during this change that aren't visible in the code? (Rationale for choices, alternatives considered and rejected, constraints discovered.)" **3. Invariants** "Did any invariants change — behaviour that was previously guaranteed and no longer is, or new guarantees the code now upholds?" Wait for answers. Do not write until you have them. **Why confirmation is required:** Code shows what was built, not what was decided. A diff cannot reveal a rejected alternative, a constraint discovered mid-implementation, or a deliberate choice that looks identical to a default. Specs that omit rationale and rejected alternatives fail the rebuild guarantee. ## Output (after confirmation) Update only what changed. Do not touch unrelated sections. - **Updated `## Decisions` entries** — edit in place, not appended. Remove outdated content. Rationale is mandatory. - **Updated `## Invariants`** — add, remove, or revise based o