CI-001B2 — Make releases protected, backend-first, and fail-closed

[daliu]

Outcome

Replace the current automatic, frontend-first, fail-open release workflow with a release gate that cannot publish a dependent website before its compatible backend. Remove every server credential from the frontend build job and make missing authority/config an explicit failure.

This ticket changes release behavior and is blocked on an owner choice before source edits:

1. Recommended: merges run CI only; staging/production releases are manual, protected, exact-commit actions.
2. Alternative: main automatically deploys to isolated staging, while production remains a protected manual action.

Do not preserve today's “merge automatically publishes production Pages” behavior for backend-dependent changes; it cannot satisfy backend-first approval.

Officer impact: Officers will approve a merge separately from a protected release, and a missing backend credential will be shown as a stopped release rather than a green success.

Officer documentation: Update OFFICER_START_HERE.md, docs/officers/PUBLISH_AND_CHECK.md, docs/officers/ACCESS_CONTINUITY.md, and the exact root release-status docs after the owner selects the release model.

Deployment evidence: None at creation. This ticket changes the gate only; CI-001D performs and proves the staged/live release.

Current verified defect

.github/workflows/deploy.yml currently:

• runs on every main push;
• publishes GitHub Pages before the Firebase job;
• passes FIREBASE_SERVICE_ACCOUNT into the frontend build environment;
• installs firebase-tools@latest over the network during deployment instead of using the lockfile version;
• deploys all Functions, Rules, and indexes rather than an approved target set;
• reports success when FIREBASE_SERVICE_ACCOUNT is missing and Firebase is skipped.

That workflow cannot safely release PR #132/#118.

Atomic source outcome after owner decision

1. Separate merge/CI from release authorization.
2. Require an exact merged commit and its required checks before release.
3. Validate environment, target project, approved deploy scope, and authority before any mutable install, build, or publication.
4. Use the lockfile-pinned Firebase CLI; do not install latest during release.
5. Give the frontend build only public browser configuration. Never pass a cloud service credential or write a key file in that job.
6. Make the backend job complete and verify first; the website job must depend on its success.
7. Use fixed reviewed deployment targets rather than caller-supplied shell text or a broad all-Functions default.
8. Make missing/mismatched authority, skipped backend, wrong ref, or partial verification fail the workflow and prevent website publication.
9. Give jobs minimum GitHub permissions; CI-001C supplies the approved short-lived cloud identity.
10. Keep staging and production evidence distinct.

Acceptance criteria

• Dave/board records the selected release model and names production approvers.
• A normal merge cannot silently publish a backend-dependent production website.
• No server credential exists in the frontend environment, build files, artifacts, or logs.
• Backend verification is a hard prerequisite of website publication.
• Missing authority/config fails before deployment and cannot end in an overall green “skipped” release.
• Firebase CLI/version comes from the committed lockfile.
• Deployment targets are fixed, reviewed, and shell-injection safe.
• A temporary synthetic missing-authority probe fails and publishes nothing, then is removed.
• Workflow YAML/static checks, CI, and affected officer procedures pass independent review.
• CI-001C provider configuration and CI-001D actual deployment remain separate.

Stop conditions

Stop if the owner has not chosen the release model, if an implementation needs a cloud key in source/frontend, if it accepts arbitrary deployment targets, or if it can publish the website after a failed/skipped backend. Do not deploy from this ticket.

Claim protocol

Creation is not a claim. After the owner decision, publish the exact allowed files, assign one agent, and post CLAIMED by <canonical agent> at <UTC>; branch <branch> before editing. Coordinate root-document ownership with PR #132/#118; do not overwrite its profile-recovery sections.

[daliu]

OWNER DECISION / CLAIM at 2026-07-13T08:54:57Z:

Dave authorized agents to push, merge, and deploy and directed the queue to proceed one issue at a time. The selected release model is the recommended option: normal merges run CI only; staging and production releases are separate manual, exact-commit, protected actions. Production still requires the environment's named human approval and the short-lived authority owned by #133; this authorization does not invent credentials or provider configuration.

CLAIMED by /root at 2026-07-13T08:54:57Z; branch codex/issue-135-protected-releases.

Initial exclusive source scope:

• .github/workflows/deploy.yml
• OFFICER_START_HERE.md
• OFFICER_HANDBOOK.md
• docs/officers/README.md
• docs/officers/PUBLISH_AND_CHECK.md
• docs/officers/ACCESS_CONTINUITY.md

PR #132/#118 retains SECURITY.md, OPERATIONS_RUNBOOK.md, profile/runtime/Rules tests, and its officer profile sections. #134 retains only its declared Sentry files. I will post a scope amendment before touching any additional path. This ticket changes and tests the gate; it will not perform a Firebase or website deployment.