Skip to content

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.