Product policy: define support tiers and stability labels for runtimes and public surfaces

[devallibus]

Summary

gametau now spans multiple runtimes, shims, providers, examples, and generated surfaces. Without a clear support/stability policy, the maintenance burden and public expectations will drift apart.

Why this matters

• Users need to know which surfaces are stable, experimental, or provisional.
• Maintainers need a defensible standard for promotion, deprecation, and support burden.
• A support policy helps keep the project from overcommitting to every plausible runtime/backend idea.

Suggested scope

• Define support tiers for runtimes, providers, and public APIs.
• Define promotion and deprecation criteria.
• Label public surfaces accordingly in docs and package metadata where practical.

Candidate labels

• stable
• experimental
• provisional/internal

Acceptance criteria

• The project publishes a documented support/stability policy.
• Runtimes and major public surfaces are labeled consistently.
• Promotion/deprecation criteria are explicit.
• The policy is reflected in README/site/docs rather than only in issue threads.

Related

• Brainstorming: evolve gametau from runtime portability to execution-topology portability #154
• Tracking: agent-friendly and LLM-first gametau tooling #138