# RFC-NNNN: <one-line title>

- **Status:** Draft | Open for comment | Accepted | Rejected | Withdrawn
- **Author:** <name>
- **Created:** YYYY-MM-DD
- **Discussion:** <link to PR or issue>
- **Resolves to:** ADR-NNNN(s), spec(s), or "no code change"

## Summary

One paragraph. What is this RFC proposing, and why now?

A reader should be able to decide from this paragraph alone whether the
RFC is relevant to them.

## Motivation

The problem. Why does the current state need to change? What goes wrong
if we do nothing? Include evidence — links to incidents, eval scores,
user reports — not just opinion.

## Proposal

The concrete change being proposed. This is the bulk of the RFC. Cover:

- **What changes** — files, modules, schemas, user-visible behavior
- **What stays the same** — the boundary of the proposal
- **Migration path** — how do we get from current state to proposed state
- **Compatibility** — what breaks, what's deprecated, what needs warning

Use sub-sections, diagrams, code examples freely. RFCs are living documents
until accepted — make them clear, not short.

## Alternatives

What else we considered. Each gets a paragraph or two. The alternatives
section is where reviewers usually have the most to say — being explicit
about what was rejected and why short-circuits a lot of back-and-forth.

## Drawbacks

The honest costs of accepting this RFC. If you can't think of any, you
haven't thought hard enough — every change has a cost.

## Unresolved questions

What we don't know yet that we'd like reviewer input on. Phrase as
questions, not statements.

## Outcome

Filled in when the RFC is accepted or rejected. Lists the ADRs, specs,
and PRs that came out of this RFC. If rejected, why.
