ci(release): the human act is the environment approval, not a typed version (ADR-0125)

[os-elon]

⛔ Governed surface — docs/adr/** + AGENTS.md. Do not queue, do not arm auto-merge. This is yours to merge by hand (Prime Directive #14). No auto-merge is armed and none will be.

Maintainer ruling, 2026-08-20:

release workflow 我觉得,合并 changeset 后,发版本前只需要有人工批准就可以,没必要现在这样一定需要我去手工输入版本号。

What changes

The 2026-08-07 ruling 「版本发布必须是人工的」 is untouched and still binding. What changes is which human act carries it.

	Before	After
What starts the release	you open Actions → Run workflow	merging the Version Packages PR
The human confirmation	you type the exact version	you approve the release environment
What runs unattended	nothing	queue a deployment and wait
Where the barrier lives	the workflow_dispatchevent — no push can synthesise it	the environment's required reviewers — a repo setting

That last row is the whole risk, and it is why D3 below exists.

Why the typed version was not the thing protecting you

Typing 17.1.0 did two jobs:

1. Proved a human was there. Its point — but the workflow_dispatchevent is what did that, not the typing.
2. Cross-checked the intent. Nearly vacuous: changeset publish ships what package.json says, so a wrong string never publishes the wrong version, it aborts the run. It catches exactly one thing — you believing main carries a version it doesn't — and showing you the version covers that strictly better than asking you to recite it.

#10146 is the cost of asking for the string at all: that run's log said 17.5.0, which is @object-ui/console@17.5.0, the vendored objectui build, while this repo was publishing 17.1.0. A maintainer retyping a number read off a release log had a live chance of stopping their own release.

The decisions (ADR-0125)

• D1 — publish runs on push to main, gated on one predicate computed by the existing hardened audit: main's @objectstack/cli version is absent from npm. True only just after a version PR merges; false on the other ~18 daily landings, so no ordinary merge queues a deployment. The version is read from the object database at github.sha with release workflow: publish pushes tags + npm but its version commit never reaches main — twice now (rc.3 c6a52d3, rc.4 a10cbc77); landing the commit must be part of the publish lane #6170's tripwire, never off disk.
• D2 — environment: release holds the whole job — no checkout, no build, no publish — and the job's name: is computed from the audited version, so the approval screen reads “Publish 17.2.0 to npm (awaiting approval)”. You confirm a version you are shown.
• D3 — ⛔ Void if the release environment loses its required reviewers. An unprotected environment passes automatically and silently and is indistinguishable in the log from an approved one. Under a push trigger that isn't a degraded gate, it's no gate — rc.3/rc.4 by design. You confirmed the reviewers are configured; the ADR, the workflow header and Prime Directive Add missing Field.phone() helper and factory methods for Action/Dashboard/Report #15 all now say the decision is conditional on that, and that no file here can check it.
• D4 — workflow_dispatch survives as the repair lane: no version input, plus a dispatch-only force for finishing a partial publish (the one case D1's predicate can't see — canary on npm, stragglers not). Same environment gate.
• D5 — Workflow-level concurrency → per-job groups. The old group was keyed on github.event_name and its comment said the point was that the lanes can never displace each other; that key stops separating anything once both lanes are pushes. Worse: a job waiting on approval holds its run in progress, so under one shared group an hour spent deciding would evict the intervening main pushes and stop chore: version packages (rc) #4935 regenerating.

The guard keeps R2's tripwire and adds one: refuse if the tree has moved off the version the approval was given against.

AGENTS.md #15

Gains the new reserved act — ⛔ never approve a pending release deployment — and records that merging the Version Packages PR is no longer adjacent to the release but is its trigger, which makes it the single most load-bearing prohibition in that directive.

Verification

Repo gates run locally, all green: check:adr-links, check:adr-anchors, check:doc-authoring, check:doc-anchors, check:required-contexts, check:workflow-status-functions, scripts/pm/check-governed-prose.mjs.

check:workflow-status-functions caught a real defect on the first pass: the publish job's if: read needs.*.outputs.* without a status function. Fixed as success() && ( … ) — the parentheses are load-bearing, since && binds tighter than || and success() && A || B would have let the force branch publish on top of a failed audit, which is the job that computes the version the name, guard and tag all read.

Job matrix after the change:

job	if	environment	concurrency
version-pr	event == push	–	release-version-pr-<ref>
release-integrity	(both events)	–	release-integrity-<ref>
publish	success() && (pending || forced dispatch)	release	release-publish-<ref>
docker	!cancelled() && (…published)	–	–

One residual race is documented in the file rather than hidden: if the version-PR landing's audit job is itself pending behind an earlier one and a third push arrives, GitHub cancels it and the release quietly doesn't queue. Narrow, visible (no approval request arrives), and recoverable with no special handling — the version is still absent from npm, so the dispatch repair lane re-audits and queues the same deployment.

Landing this is a no-op, and that is the point

17.1.0 already shipped — run 32362556463 succeeded at 11:26 on 2d3860d, and npm now carries latest: 17.1.0 with @objectstack/cli, @objectstack/spec, @objectstack/core, @objectstack/account and @objectstack/console all present, plus the full tag set on the remote. (That run is also the production proof of #10148's fix: same lane, same pnpm pin, the publish it previously died before reaching.)

So merging this PR queues nothing: main carries 17.1.0, npm has it, D1's predicate is false, and publish is skipped on the landing push exactly as it will be on every ordinary merge. The new path first does anything real on the next Version Packages PR — which is the gentlest possible way to find out whether it behaves, since a wrong predicate shows up as no deployment queued rather than as an unwanted publish.

What is verified here is the YAML's shape, every gate the repo runs against it, and the predicate's arithmetic. What cannot be verified from here is the end-to-end push→approve path; that is observed on the next release.