Plan: Verified Baseline Authority

Outcome

Resolve every moving or exact baseline request to one immutable verified identity. The control plane owns selection; release inventory, cache, downloads, and bundled content only retrieve and verify that identity.

Delivery Order

1. Extend packages/contract with { channel, version? }, the complete verified identity, and typed authority, integrity, and unavailable failures.
2. Make apps/api select and validate the authoritative release identity, then project version-bound artifact metadata from it.
3. Make apps/cli retrieve only the selected identity, verify archive and content digests, and accept stable, explicit bundled, or an exact version across update, check, tools, and scaffold.
4. Prove the contract, API inventory/registry, CLI resolver/cache/bundled paths, packaged help, and cross-command exact-version propagation.

Locked Rules

• stable is the newest complete published baseline. A newer non-stable release, conflicting identity, or incomplete inventory fails typed and never falls back.
• Exact-version requests cannot be substituted.
• Exact requests select the matching stable release and return BaselineNotFound when absent.
• Published schema-v2 manifests require nonblank compatibility.cliVersionRange; historical exact requests use only their selected verified metadata.
• A verified schema-v1 release uses deployment compatibility only for the currently configured stable or matching exact version; historical schema-v1 releases fail typed integrity until backfilled to v2.
• GitHub, cache state, artifact URLs, and bundled content cannot select or redefine stable.
• Inventory pagination and redirects remain same-origin, complete, cycle-free, and bounded to 100 pages.
• Cache and bundled bytes are accepted only after digest, version, provenance, and compatibility checks.
• An implicit default-stable request may continue only from typed remote-access failure to the independently verified bundled baseline. Eligibility comes from positive transport, timeout, authority-unconfigured, network, unavailable-status, archive transport, or the archive endpoint's declared unavailable HTTP 503 rather than the public reason or failure message.
• Explicit stable and exact-version requests remain fail-closed on remote-access failure. Explicit bundled resolves verified bundled bytes immediately.
• Integrity and authority failures always fail closed, including stale or incomplete inventory, disagreement, substitution, compatibility failure, and manifest, archive, cache, or content digest failure. Typed archive 422 integrity, 409 authority, and 404 not-found responses preserve their declared failures. Inventory and selected-manifest network failures and transient HTTP 408, 429, 500, 502, 503, or 504 are availability; inventory 401, 403, or 404, manifest 404, and other non-transient statuses are integrity. Selected-manifest initial and redirect URLs require absolute HTTP(S); all hops are manual and bounded to 20.
• Malformed successful authority responses, relative, invalid, or unsupported initial or redirected archive URLs, inventory pagination cycles, cross-origin traversal, and inventory safety-limit exhaustion are fail-closed. Existing incomplete cache material is an integrity failure, which remains authoritative when its repair download is unavailable.
• Implicit fallback preserves requested stable identity and reports retrieval: fallback with bundled source/provenance; explicit bundled reports its own request and retrieval: available.

Verification Gate

• Contract: full protocol and type gates.
• API: registry, inventory, HTTP handler, and public snapshot gates.
• CLI: resolver, control-plane client, command propagation, public output, typecheck, and packaged build gates.
• Docs: root implementation reference, operator runbook, routed control-plane decision, and this spec record agree with implemented behavior.