planning-disciplinelisted

# Planning discipline — type-level design + invariant-first Two disciplines, applied together at plan time. Type-level design says who owns what; invariant-first says what must stay true and who enforces it. Neither substitutes for the other. A post-hoc design review that fails is a plan that failed earlier: by then the refactor is too large to fold into the same change and gets postponed, and postponed refactors compound. ## Type-level design (SOLID from the start) Apply the Single Responsibility Principle in its original form: a type has one reason to change, one actor it answers to. Enforced during planning and implementation, not discovered in review. **At plan time:** - For every type the plan touches, state which responsibilities it gains. A type gaining a responsibility outside the contract its name states ⇒ the plan includes the extraction as part of the same work item — never "as a follow-up". - New state added to an existing type must name its lifetime (who resets it, when). Two different lifetimes living in one type is a split signal. **While implementing — the tripwire.** Stop and propose a split immediately (mid-task, not at review time) when a type being edited: exceeds ~300 lines, or ~15 stored properties, or holds state with two different lifetimes, or gains a responsibility its name doesn't cover. Proposing the split is mandatory; deferring it is the user's call, never a silent default. God classes are never designed — they accrete through individu