Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
Goal

Set expectations so users do not confuse user-visible UI with uniformly finished behavior across the whole product.

​
Prerequisites

  • None

​
Workflow

1
Treat projects, stacks, nodes, observability, and backup foundations as live product areas.
2
Use caveat language only where the implementation clearly justifies it, such as assistant-driven diagnosis or workflow-specific operational limits.
3
Read maturity badges on docs pages before assuming full operational depth.

​
Status language

  • Live: stable, user-reliable, and expected to work as documented.
  • Live with caveats: real and usable, but with operational or UX limitations that matter.
  • Partial / evolving: present in the product, but not yet mature enough to treat as fully finished.

​
How to read maturity in these docs

The goal is not to downgrade working product areas. It is to distinguish between features that are clearly implemented and stable, features that are implemented but still have meaningful operational limits, and features that are still evolving in scope or polish. Billing, team, domains, settings, notifications, and global environment management are all real product areas in the current implementation and should be documented as such.

​
Expected result

Readers know how much confidence to place in a given area before adopting it heavily.

Plans and usage

Use the billing area to inspect plans, subscription state, usage, transactions, payment methods, and spending limits.

AI build diagnosis

Failed builds combine deterministic pattern evidence with governed model analysis and can hand bounded repair work to Deploy or Debug.