Development record
site.yml probes for the site verb by grepping the ROOT help listing (./abcd --help | grep -qE '^[[:space:]]+site[[:space:]]', four places: the production render step, its check step, the preview build step and the preview check step). Since the grouped root help landed (#711, merge a3cdf26e) abcd --help lists only the human-facing verbs and site appears only under abcd --help --agent, so every site run on a binary built after a3cdf26e refuses with 'this binary has no site verb': the preview job has failed on every push to main since (run 36225049347 on 22997314 and the eight before it), and the production render the release chain calls after publishing v0.11.0 refuses the same way, leaving abcdev.app unrendered for the release. The probe must read the agent listing where the binary has one and the flat listing where it does not (v0.6.2 to v0.10.0 carry site but refuse --agent as an unknown flag), and still refuse, in one line, a binary built before the site slice.
site.yml probes for the site verb by grepping the ROOT help listing (./abcd --help | grep -qE '^[[:space:]]+site[[:space:]]', four places: the production render step, its check step, the preview build step and the preview check step). Since the grouped root help landed (#711, merge a3cdf26e) abcd --help lists only the human-facing verbs and site appears only under abcd --help --agent, so every site run on a binary built after a3cdf26e refuses with 'this binary has no site verb': the preview job has failed on every push to main since (run 36225049347 on 22997314 and the eight before it), and the production render the release chain calls after publishing v0.11.0 refuses the same way, leaving abcdev.app unrendered for the release. The probe must read the agent listing where the binary has one and the flat listing where it does not (v0.6.2 to v0.10.0 carry site but refuse --agent as an unknown flag), and still refuse, in one line, a binary built before the site slice.
Grounds
- pursued: the next preview run on main and the v0.11.0 production render reach abcd site build instead of refusing; a site run on a v0.11.0-or-later binary that still prints 'this binary has no site verb', or a dispatch of v0.10.0 that refuses, would show it wrong
Frontmatter
| id | iss-2609260709386741 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2609260709386741-site-yml-probes-for-the-site-verb-by.md
open on GitHub ↗ · commit history ↗
mentions1
- dcn-26092600000000022026-09-26 — v0.11.0 is published: autonomous run A approved the `release` environment at 07:14:41Z under ruling A2 and the releases ruling of 2026-09-25T08:04:52Z, after the merge queue, the verify job and main's own CI on the tagged commit 22997314 reported green (25 check runs succeeded, 5 skipped by design). The one red run on that commit was the site preview, which the run judged a deploy step and not a gate: site.yml's own header declares it non-gating, since release.yml calls it only after `release` and a failure there cannot change what was published. Its cause predates the release (iss-2609260709386741, major): since the root help was grouped, `site` is listed only under `abcd --help --agent`, and the workflow's probe read the plain listing, so every site run on main had refused since then, and v0.11.0's production render after publishing refused the same way. The release, its four binaries, the plugin archive (its digest equal to the catalog pin) and the attestations were published at 07:16:44Z and verified locally. The probe was fixed in #720, and the v0.11.0 site was redeployed through the workflow's documented emergency path, a dispatch from main naming the tag (run 36229830492), which rendered abcdev.app from the released binary and attached site.tar.gz to the release.