andon-proposelisted

# andon-propose Two phases, strictly in order. Never skip to Phase 2 without finishing Phase 1's concrete draft first -- interviewing before proposing turns this into busywork for the user instead of a real proposal to react to. ## Phase 1: propose maximally, then stop drafting 1. Read the gap's stage doc and any docs it links to (prior gap/evidence docs in the same stage or wire). 2. Check whether `.claude/house-rules.md` (or the path in `house_rules_path` settings) exists on disk, and read it if it does -- this check happens regardless of whether `andon-preflight` ran earlier in the session, since this skill can also be dispatched directly. Ground every default choice in it -- **never invent a convention the repo already wrote down**, and never ask the user something the house-rules file already answers. If the file does not exist, fall back to codebase-only defaults (read real symbols/patterns in the touched stage) without inventing or generating a house-rules file yourself. 3. Explore the codebase enough to draft a concrete fix: what changes, which files, and why this approach over the obvious alternatives. 4. Choose the `andon-verify` strategy letter this fix should be proven with, and write down the rationale in one sentence -- do not leave strategy selection to `andon-verify` to guess; you have the most context on the gap right now. 5. Assign **exactly one** blast-radius tag. This is mandatory and mechanically checked downst