alternatives-before-codelisted

# Alternatives Before Code ## Purpose Prevent the first plausible implementation from becoming the decision by default. ## Preserves Tradeoff analysis. ## Required Evidence - Decision to be made. - Constraints that affect reversibility, blast radius, cost, or testability. - Existing architecture notes or code boundaries if available. ## Failure Signs - Only the anchored solution is considered. - The no-build or minimal option is hidden. - Complexity is recommended without naming the cost it buys. ## When To Use - The change affects architecture, data shape, workflow, dependencies, or public behavior. - Multiple implementation strategies are plausible. - Reversibility, blast radius, or testability matters. - The user has already anchored on one solution. ## When Not To Use - One-line fixes with obvious verification. - Formatting, renames, generated files, or lockfile-only work. - Emergency mitigation where delay would increase impact. ## Inputs Expected - Decision to be made. - Constraints such as time, compatibility, migration risk, ownership, and test surface. - Existing architecture notes, ADRs, or code boundaries if available. ## Output Expected ```md Decision: Option A - Minimal: Option B - Structural: Option C - Conservative/no-build: Recommendation: Change-my-mind evidence: ``` ## Process 1. Name the decision in one sentence. 2. Produce a minimal option, a structural option, and a conservative/no-build option. 3. Compare cost, reversibility, blast radi