rfclisted

# RFC Produce an architecture RFC in the user's canonical format. The user is a Staff Engineer biased toward simplicity, FP, modular monoliths, and pragmatic DDD — challenge over-engineering inside the doc itself, do not defer it to review. ## Steps 1. **Clarify scope before writing.** If the input is vague ("RFC for caching"), ask 1-3 targeted questions: what problem prompted it, what's the current state, what's the deadline / urgency. Do not invent context. 2. **Read the repo** if relevant — `package.json`, top-level structure, existing ADRs/RFCs (`docs/rfc/`, `docs/adr/`, `.docs/`) to mirror naming and tone. 3. **Draft all 10 sections.** Do not skip any. If a section is genuinely empty, write `N/A — <one-line reason>` rather than removing it. 4. **Surface 2-3 realistic options.** Never present a single recommendation as "the" answer. Include a "do nothing / defer" option when honest. 5. **Trade-offs must be concrete.** Cost in dev hours, operational complexity, blast radius if it fails. No marketing prose. 6. **Recommendation must justify itself against the other options**, not in isolation. 7. **Risks ≠ trade-offs.** Risks are what could go wrong despite the right choice (regression, scope creep, dependency change, hiring gap). ## Required sections (in order) 1. **Problem Statement** — one paragraph, no jargon. What hurts today. 2. **Context** — current architecture, team, constraints from history. Link to relevant code/docs. 3. **Constraints** — hard limits (complia