Define a status taxonomy for renderers (parallel to spec version taxonomy from #1240)

[zeroasterisk]

Follow-up from #1302 (review thread between @ditman and me).

#1240 settled on a clear taxonomy for specification versions: draft / candidate / final / deprecated. We don't have an equivalent for renderers, and the Roadmap currently uses an informal mix:

• ✅ Stable — Web Core Lib, Lit, Angular, Flutter, Markdown, React
• 📋 Planned — Jetpack Compose, SwiftUI
• 💡 Proposed — Vue, Svelte, ShadCN

@ditman raised the question: should we replace Stable with Available or similar? I pushed back on Available (loses the maturity signal — a freshly-shipped renderer is "available" the moment it's published, indistinguishable from one hardened by users for a year). But Stable is also imperfect pre-1.0.

Options to consider

1. Mirror the spec taxonomy — draft / candidate / stable / deprecated. Couples renderer maturity to the spec version it targets. Conceptually clean; reuses vocabulary contributors already learned.
2. OSS-standard ladder — alpha / beta / stable / deprecated. Most renderers would currently be beta since we're pre-1.0. Honest but might feel like a downgrade.
3. Available / Planned / Proposed (@ditman's suggestion) — Simple, flat, no maturity signal.
4. Hybrid — Use the spec taxonomy for renderer↔spec compatibility (per spec version), and a separate maturity label per renderer overall.

Things to decide

• Single status per renderer, or status per (renderer × spec version) cell? (The reference table is already 2D today.)
• Do we want a "recommended" / "latest" signal, or is that implied by the table ordering?
• Should the labels live in docs/glossary.md next to the spec version taxonomy?

cc @polina-c @ditman @jacobsimionato

[ditman]

I don't have strong feelings about what we end up using, except that "Stable" normally has attached SLAs. I don't mind marking the current renderers as "beta"! /cc @ava-cassiopeia also had thoughts about the "stable" nomenclature!

[polina-c]

First, I suggest to step backand and check terminology.

Per glossary, what we have in the folder renderers is a mix of framework adapters and core libraries.

renderer is a one of two entities which interaction a2ui specifies: a2ui defines how agent and renderer should talk to each other. framework adapter or adapter is a library that helps to create a renderer that use a certain framework.

So, unless we want to adjust terminology in glossary, I would suggest to reorganize the folder renderers to fit the therminology, and update docs to stop calling adapters 'renderers':

• a2ui
  • adapters
    • markdown
    • java_script
      • java_script_core (renamed web_core, because there also can be wasm_core that is also web)
      • react
      • lit
      • angular

Or, maybe instead of java_script_core we should use just core, bercause the parent folder implies the language.

Thoghts?

[ditman]

Or, maybe instead of java_script_core we should use just core, bercause the parent folder implies the language.

I'd rather move these to their own repos, rather than moving the directory structure now. Also, the directory names ideally should map to NPM package names (so renaming web_core to something else is "hard", but it has been proposed to rename it to just "core", because it's vended from npm so the "web" bits are redundant)

[polina-c]

@zeroasterisk , @ditman and I started discussing this offline. I will update this discussion when we align.