Filed by the repo:objectos seat (objectstack#9831) at 2026-09-04T12:55Z, out of the incident on #261 — where a merge by this seat replaced a working (stale) production site with a broken one, and the seat did not understand at merge time that it was publishing.
Maintainer instruction, verbatim (2026-09-04):
所有的部署应该有人工确认
The gap, stated mechanically
In this repo, merging to main IS deploying to production. There is no step between them.
merge PR → push to main → deploy-docs.yml → pnpm run deploy
→ Cloudflare Worker docs-objectos
→ docs.objectos.ai (live)
The workflow declares environment: name: cloudflare-docs, which is exactly the GitHub mechanism that can require a human approval before a job runs. It is not configured with one.
Measured, rather than read from settings (the settings API is not reachable from the agent container): PR #263 merged at 12:36:47Z and deploy run #142 started at 12:36:48Z — one second later. A job gated by a required reviewer sits in Waiting until a human approves. This one did not wait.
Why this is priority:p0
The agent seat that caused today's outage never held Cloudflare credentials and never ran a deploy command. Its actual privilege was merge to main — and that silently carries "publish to production" with it. Every guardrail this lane operates under (draft PRs, review checklists, merge queue, governed-surface rules) is built around the belief that merging is a reversible, internal act. In this repo it is not, and nothing anywhere says so.
Compounding it, and why "just revert" is not the safety net anyone assumes: an oversized upload is rejected at version creation, so a failed deploy does not roll back — it leaves the previously-uploaded version serving. A git revert of a bad deploy therefore does not restore the site. Recovery requires a Cloudflare-side version rollback, which needs credentials no agent has. The forward path is automatic and unattended; the recovery path is manual and gated. That asymmetry is the defect.
The ask (maintainer action — no agent can do this)
Repo Settings → Environments → cloudflare-docs → Required reviewers. Add at least one human. That makes every production deploy stop and wait for a click, without changing a line of workflow code.
Worth deciding at the same time:
⛔ Lane frozen until this exists
This seat is not merging anything to main in this repo until there is a human gate on the deploy, regardless of how safe the diff looks. A docs-content PR and a production release are the same act here, and this seat has now demonstrated it cannot be trusted to hold that distinction in its head. Recorded on the seat post; the queue cards that would fire a deploy are blocked on this card.
Related: #261 (the outage), #262 (nothing measures the bundle before deploy), #265 (behaviour unverifiable before deploy), objectstack (the skills-side rule).
Filed by the
repo:objectosseat (objectstack#9831) at 2026-09-04T12:55Z, out of the incident on #261 — where a merge by this seat replaced a working (stale) production site with a broken one, and the seat did not understand at merge time that it was publishing.Maintainer instruction, verbatim (2026-09-04):
The gap, stated mechanically
In this repo, merging to
mainIS deploying to production. There is no step between them.The workflow declares
environment: name: cloudflare-docs, which is exactly the GitHub mechanism that can require a human approval before a job runs. It is not configured with one.Measured, rather than read from settings (the settings API is not reachable from the agent container): PR #263 merged at 12:36:47Z and deploy run #142 started at 12:36:48Z — one second later. A job gated by a required reviewer sits in
Waitinguntil a human approves. This one did not wait.Why this is
priority:p0The agent seat that caused today's outage never held Cloudflare credentials and never ran a deploy command. Its actual privilege was merge to
main— and that silently carries "publish to production" with it. Every guardrail this lane operates under (draft PRs, review checklists, merge queue, governed-surface rules) is built around the belief that merging is a reversible, internal act. In this repo it is not, and nothing anywhere says so.Compounding it, and why "just revert" is not the safety net anyone assumes: an oversized upload is rejected at version creation, so a failed deploy does not roll back — it leaves the previously-uploaded version serving. A git revert of a bad deploy therefore does not restore the site. Recovery requires a Cloudflare-side version rollback, which needs credentials no agent has. The forward path is automatic and unattended; the recovery path is manual and gated. That asymmetry is the defect.
The ask (maintainer action — no agent can do this)
Repo Settings → Environments →
cloudflare-docs→ Required reviewers. Add at least one human. That makes every production deploy stop and wait for a click, without changing a line of workflow code.Worth deciding at the same time:
www.objectos.app/*should still be bound to this Worker at all — raised separately by the maintainer on 2026-09-04 and not part of this card; the binding is pre-existing (5b4df1b, 2026-06-04) and unrelated to the outage.⛔ Lane frozen until this exists
This seat is not merging anything to
mainin this repo until there is a human gate on the deploy, regardless of how safe the diff looks. A docs-content PR and a production release are the same act here, and this seat has now demonstrated it cannot be trusted to hold that distinction in its head. Recorded on the seat post; the queue cards that would fire a deploy are blocked on this card.Related: #261 (the outage), #262 (nothing measures the bundle before deploy), #265 (behaviour unverifiable before deploy), objectstack (the skills-side rule).