RFC-NNNN — <Short Title>

• Status: Draft | Open | Final-Comment-Period | Accepted | Rejected | Withdrawn
• Author(s): @name
• Reviewers: @name, @name
• Opened: YYYY-MM-DD
• Closes: YYYY-MM-DD (review window end)
• Promotes to ADR: ADR-NNNN (on acceptance)

Summary

One paragraph. What this changes for consumers.

Motivation

What problem does this solve? What use cases motivate it? Cite real evidence (incident, request, support tickets) where possible.

Detailed design

The proposal. Include:

• Method / schema / wire changes (before → after).
• Code samples for every breaking call site.
• New types / classes / packages introduced.
• Deprecation tags applied.

Backwards compatibility

What breaks. Who is affected (which consumers, which versions).

Migration path:

• For internal callers: …
• For external plugin authors: …
• Deprecation window: <N versions / months>.

Migration plan (for this codebase)

How the repo moves to the new state:

• Add the new shape behind a flag.
• Codemod the call sites.
• Flip the default.
• Remove the old shape after one major version.

Drawbacks

What is worse after this lands?

Alternatives

Alternative A — <name>

…

Alternative B — <name>

…

Unresolved questions

These must close before acceptance.

• …

Acceptance criteria

This RFC is Accepted when:

• Maintainer of every affected package has thumbs-up.
• Final-Comment-Period (48h) has elapsed without new objections.
• Migration plan is concrete enough that any agent could execute it.
• ADR promotion PR is open and references this RFC.

See also

• ADR-NNNN
• Issue / PR refs