decide

# Decide ## Prepare Before a design walkthrough, inspect the relevant code and record concrete bugs, inconsistencies, and decision points in `plans/<YYYYMMDD>-<topic>.md` or the appropriate app-scoped `plans/` directory. Preserve existing edits; never discard speculative or user-authored work without explicit approval. Order decisions by dependency and leverage, not document order. ## Decision walkthrough For each decision: 1. Show `## Decision N: <title>`. 2. Give two to four sentences of context grounded in real files or functions. 3. State the trade-off in one sentence. 4. Ask exactly one interactive question with two to four mutually exclusive options. - Use `ask_user` when available. In Codex Plan mode, use `request_user_input` when that is the exposed interactive question tool. - Never substitute a plain-text question when repository instructions require an interactive overlay. - Keep labels to five words or fewer. - Put the recommendation first and suffix its label with `(Recommended)`. - Explain each option and its trade-off in one sentence. - Do not add an `Other` option when the client adds one automatically. 5. After the answer, write `Logged: <decision>.` and continue. If the user acknowledges an issue without choosing, log the recommended choice and say they can correct the assumption. At the end, provide a `| # | Decision | Choice |` table and offer to turn the audit into an implementation plan. Do not write implementation code during t...