scope-minimalismlisted

# Scope minimalism The task defines the change; everything beyond it needs a stated reason or an approval. Fewer lines, fewer files, fewer moving parts — the smallest change that honestly solves the task. Restraint shortens the solution, never the reading. ## The ladder — a reflex, not a research project Walk the doctrine's build ladder and stop at the first rung that holds: not built → existing code edited → stdlib → platform-native → already-installed dependency → the smallest new function that works → the smallest diff that integrates it without breaking existing behavior. When two rungs would work, take the higher one and move on. Rungs with per-stack examples, the edge-case tiebreak, and when a rung is refused: `references/ladder.md`. ## The task shape — before the first edit Goal: (singular — two goals are two tasks) Non-goals: (name at least one; empty means scope was never decided) Files likely touched: (a file outside the list mid-task is the scope tripwire) Smallest acceptable change: Tests/checks: Needs-approval: (the doctrine's approval gates, plus anything task-specific) The shape is where the thinking happens: resolve open questions by reading or research before the first edit — trial-and-error editing burns steps and trust. If the goal, file set, or smallest acceptable change shifts mid-task, re-shape and say so — silent scope drift is the failure the form exists