RFC NNNN:
| Status | Proposed |
| Author(s) | <your name / handle> |
| Discussion | <link to the originating Discussion, if any> |
| Implementation | <issue/PR links, filled in as work lands> |
Status is maintained by maintainers:
Proposedwhile the PR is open,Acceptedon merge,Declinedon close,Superseded by NNNNlater.
Summary
One paragraph: what this changes, in plain terms.
Motivation
What problem does this solve, and why is it worth the ongoing cost? Tie it to a concrete need (a Discussion, a recurring issue, a user request). Per the project's first principle, argue the long-run liability, not just the short-term convenience.
Guide-level explanation
Explain the change as you'd teach it to a user or contributor: new commands, syntax, API shapes, behavior. Examples first.
Reference-level design
The precise design: data structures, IR/AST/planner changes, storage/format impact, migration path, error behavior. Enough that a reviewer can find the holes.
Invariants & deny-list check
Which Hard Invariants in ../dev/invariants.md does this touch? Does it brush against any deny-list item — and if so, why is this the justified exception? State explicitly that no invariant is weakened, or which Known Gap moves.
Drawbacks & alternatives
What does this cost, what did you reject, and why. "Do nothing" is a valid alternative to weigh.
Reversibility
Is this reversible? On-disk/wire/format and substrate choices are near-permanent and demand more evidence; a CLI flag or doc is cheap to undo. Say which this is.
Unresolved questions
What's deliberately left open for review to settle.