RFC NNNN: Title¶
- Status: Draft
- Author: Your name
- Created: YYYY-MM-DD
Summary¶
One paragraph describing the change.
Motivation¶
What problem does this solve, and for whom? Include measurements or concrete examples where they exist. Explain why the problem is worth solving now.
Design¶
Describe the change in enough detail that someone familiar with Wybthon could implement it. Cover:
- the public API, with signatures and short examples;
- the runtime behavior and the contracts it relies on or changes;
- how it interacts with existing features (reactivity, ownership, the kernel, the router, the build);
- error handling and dev-mode diagnostics.
Breaking changes¶
List every public API that's removed, renamed, or changes behavior, and what replaces it. Write "None" if there aren't any.
Alternatives considered¶
What else did you consider, and why didn't you choose it? Include "do nothing."
Drawbacks and risks¶
What does this cost in complexity, performance, bundle size, or maintenance? What could go wrong?
Testing¶
How will the change be verified? Name the unit tests, browser tests, benchmarks, or work gates involved.
Unresolved questions¶
What's still open? What's deliberately left for later RFCs?
Decision¶
Filled in by a maintainer when the RFC is accepted or rejected.