Migration status
This page is the canonical classification of public and development surfaces. The root release status owns exact source and registry versions; DECISIONS.md routes durable choices. Status was reconciled against the linked manifests, contracts, and registry pages on 2026-08-15.
Classification
Section titled “Classification”| Status | Meaning | Current surfaces | Evidence or next gate |
|---|---|---|---|
| Stable | Published and supported; this is not a promise of post-1.0 API stability. | The registry versions and their baseline CLI/workspace behavior listed in the release-status table. | Registry links live in that table; baseline regressions live with Tropo, Ozone, Exo, and create-vivary. |
| Optional | Installed, configured, or invoked only by explicit choice; optional is independent of maturity. | Ozone and Exo beyond the Tropo + Strato baseline; storage and semantic-memory capabilities including vivary-memory-cognee; Obsidian and active-context integrations; and the published but experimental vivary-mcp. |
Architecture boundaries, semantic-memory gates, active-context gates, and the MCP install boundary. |
| Experimental | Published and opt-in where callable, with contracts that may still change before 1.0. | The thin-v0.3 init/adoption contract in create-vivary; vivary-core; governed Tropo, Strato, Ozone, and Exo paths; the provider-neutral recall firewall; and the optional read-only vivary-mcp adapter. |
Thin adoption regressions, Core contract tests, role envelopes, and MCP contract tests. |
| Held | Complete or partial source work that must not be described as published, graduated, or default-enabled. | The staged, unpublished train: the five component patches create-vivary / @vivary/create 0.4.3, vivary-tropo 0.5.4, vivary-strato 0.1.3, vivary-ozone 0.3.2, and vivary-exo 0.3.1, plus the front-door meta-package vivary 0.2.0. The Vivary Governed Context train published and was verified on 2026-08-15, so every version in the root release status is still registry truth. |
The release policy resolved by #149, the documentation acceptance completed by #210, and the per-item human gates in the release workflow. |
| Deprecated | Formally discouraged with a documented replacement and removal policy. | None. Legacy full workspace layouts and legacy Exo graph commands remain read-compatible surfaces, not deprecations. New init/adopt no longer generate the full layout. | Doctor compatibility contract and legacy Exo commands. |
| Planned | Described intent with no shipped behavior claim. | Cloud storage adapters and non-file/cloud migration targets; any broader MCP transport or named-client compatibility. | Data-layer future work; MCP external conformance remains explicitly unproven. These are plans or hypotheses until implementation evidence exists. |
Moving forward without rewriting history
Section titled “Moving forward without rewriting history”Existing releases keep their independent package versions; no historical tag,
changelog entry, or registry artifact is renumbered. A named train coordinates a set
of versions but is not itself a package version. Only the two distributions of the
same scaffolder—create-vivary on PyPI and @vivary/create on npm—remain numerically
lockstep. The policy and lifecycle are owned by the
release workflow, resolving the
choice requested by #149.
Published install commands resolve the registry versions in the root table. Do not infer publication from a manifest version. When a train is verified, the root table changes from old registry truth to new registry truth. This page changes only if a surface’s classification changes.