This template is for the public contribution track. See README.md for the separately versioned maintainer design-series lifecycle.
| Status | Proposed |
| Author track | Public contribution |
| 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.
One paragraph: what this changes, in plain terms.
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.
Explain the change as you'd teach it to a user or contributor: new commands, syntax, API shapes, behavior. Examples first.
The precise design: data structures, IR/AST/planner changes, storage/format impact, migration path, error behavior. Enough that a reviewer can find the holes.
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.
What does this cost, what did you reject, and why. "Do nothing" is a valid alternative to weigh.
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.
What's deliberately left open for review to settle.