GA and Staged Rollout

The current GA state is `BLOCKED / NOT STARTED`. There is no real installer, public download, production update origin, or user participating in a staged rollout. Week 8 completes a NON_PRODUCTION control-plane rehearsal and fail-closed contract, not a production GA.

Inspect the machine-readable GA rehearsal record, the GA rehearsal schema, or the Release Manifest page.

Control-plane path rehearsed

The rehearsal uses a temporary Ed25519 test key and a synthetic updates.example.test origin. It verifies ten signed pointer revisions:

1. initial staged / 5%;
2. expansion to 25%;
3. pause while retaining 25%;
4. resume with the same cohort;
5. expansion to 50%;
6. transition to full / 100%;
7. routine renewal at the start of the T−72h window with a higher sequence;
8. pause from full / 100% without reopening or changing the approved percentage;
9. resume to full / 100%; and
10. expiry incident recovery that goes directly to withdrawn / 0% with a higher sequence.

Every revision preserves the same Manifest reference and cohort seed while the sequence increases strictly. Routine renewal is allowed only inside the approved T−72h window; an expired pointer cannot use normal renewal and can recover only directly to a safe paused or withdrawn state. The rehearsal also verifies that pause and resume cannot hide an expansion, withdrawal must be zero percent, and bad signatures, sequence rollback, skipped stages, reference drift, or seed drift fail closed.

It uses zero production credentials, zero production-network calls, and zero provider mutations. It publishes zero real artifacts, and every productionCredit value is none.

How a production staged rollout works

In a production release, the client combines a private installation ID with the public cohort seed to select a stable bucket. Increasing the percentage for the same release keeps installations selected by an earlier stage in the cohort. This is an installation-level mechanism; it does not identify a user, company, geography, or entitlement.

Direct website downloads are not controlled by the updater percentage. Publishing an installer link during an early stage would bypass stable bucketing, so website downloads, the update feed, announcements, and third-party mirrors require separate exposure approvals.

Pause, withdrawal, or pointer expiry blocks future installations. It does not uninstall, downgrade, or restore clients that already installed the release. Problems on installed clients require a higher-version forward fix or controlled recovery from a pre-upgrade backup.

Why GA remains blocked

Production GA still lacks:

• a real publisher, brand rights, official domain, launch markets, and verified support, security, privacy, and legal channels;
• canonical Git history, a formally signed tag, protected native macOS arm64 and x64 runners, and production credentials;
• signing, notarization, real platform acceptance, product media, and a 14-day soak bound to the same candidate bytes;
• a client with production trust enabled, an immutable HTTPS update origin, and provider-specific create-only and CAS atomic publication;
• monitoring, alerts, on-call ownership, and incident response with reliable denominators by version, architecture, and stage.

Until every fact exists and receives independent approval, claims such as “GA released,” “automatic updates live,” “100% rollout complete,” or “public installers available” remain prohibited.