Release validation and promotion

release-contract.json and the two manual GitHub workflows are the only normal production release authority. The gateway and octonode-cloud-api are one exact release pair. Automatic Cloudflare builds may run wrangler versions upload; they must not deploy traffic. Provider-side traffic changes are break-glass actions and require an incident record.

Operator configuration

Repository Actions variables own the smoke context:

• OCTONODE_PRODUCTION_ORIGIN — exact HTTPS origin, without a path;
• OCTONODE_RELEASE_SMOKE_WORKSPACE — dedicated user:, org:, or team: workspace;
• OCTONODE_RELEASE_SMOKE_PROJECT and OCTONODE_RELEASE_SMOKE_WORKFLOW — synthetic fixture IDs.

Repository secrets are CLOUDFLARE_ACCOUNT_ID, CLOUDFLARE_API_TOKEN, OCTONODE_RELEASE_SMOKE_TOKEN, and OCTONODE_RELEASE_BROWSER_SESSION. The Cloudflare token is limited to version upload/read/deploy for the two Workers. The API token is a revocable bearer for the dedicated workspace. The browser secret is a separate revocable Playwright storage-state JSON fixture; it is parsed in memory and never written to an artifact. Record names, owners, scopes, expiry, and rotation timestamps—never values.

GitHub Actions billing/spend must allow a runner to start. A billing rejection happens before any workflow preflight can run. The current private-repository policy uses a distinct manual promotion workflow instead of treating an unprotected environment label as approval.

Candidate action

Dispatch .github/workflows/release.yml from main with the exact current 40-character commit SHA and the current gateway/cloud-control version UUIDs. Before install or upload, the workflow checks the ref, SHA, configured context, version IDs, and required secret names. Wrangler writes one structured NDJSON record per upload; the workflow takes each candidate ID from that upload record, not a later version listing.

The candidate stays at 0% public traffic. Exact control/candidate and both mixed pairs must pass strict smoke, the three-case corpus runs ten times per variant, and the paired rollback drill must restore the controls. The workflow then stops. Its promotion identity is only:

release-candidate-<candidate-run-id>/release-manifest.json

The manifest contains the repository, main SHA, run ID, configured-origin/context digest, four Worker version IDs, named gate outcomes, 30-sample experiment outcome, rollback result, artifact references, and creation time. It contains no headers, cookies, tokens, user data, or fixture content. Candidate mode has no production-promotion job or candidate-at-100% command.

Promotion action

Dispatch .github/workflows/promote-release.yml with only the successful candidate run ID. The workflow retrieves that run and named artifact through the repository Actions API. It rejects a non-candidate workflow, unsuccessful/non-main run, stale main SHA, configured-context drift, malformed manifest, mismatched pair, or a run superseded by a later successful candidate before traffic changes.

Promotion verifies ordinary traffic is still the recorded control pair, promotes cloud control first, verifies the temporary mixed pair, then promotes the gateway. It rebuilds nothing. Exact candidate smoke runs immediately and after the initial measured 15-minute monitoring window. Redispatch is a no-op only when both candidate IDs are already current and smoke still passes.

If promotion or production smoke fails, rollback restores gateway control first and cloud control second, then smoke-tests the exact control pair. A failed compensation or control smoke is recovery-required: freeze release actions and attach the observed partial pair for manual recovery. Never treat a partially restored pair as rollback success.

Evidence and failure contract

Retain candidate/production run URLs, commit SHA, paired IDs, redacted smoke JSON, synthetic screenshots, the scanned unauthenticated trace, 30-sample experiment report, rollback evidence, and engineering/security/QA signoffs. Authenticated traces are prohibited.

Every operator failure must report:

PROBLEM: failed path or stage
CAUSE: known cause or bounded likely causes
FIX: exact command, setting, or credential name
EVIDENCE: redacted artifact/run and release IDs

Repository-ready evidence does not mean production-ready. Production readiness additionally requires restored Actions billing, upload-only provider build settings, provisioned credentials, a successful candidate and distinct promotion run, live signoffs, rollback evidence, and the monitoring window recorded against issue #88.