verify(canary): exercise the canary label + note surface on two real 0.0.4 canaries

[rickylabs]

Relocated from #1121, which #1122 implements. Part of epic #1120.

#1121 carried this criterion:

• Exercised on two real canaries with different payloads (0.0.4-canary.1, 0.0.4-canary.2); the second payload differs from the first rather than repeating it

No PR can satisfy it. It is evidence about the tool, gathered by running the release process — not a property of the code. Holding #1122 until both canaries exist would also invert the agreed sequence, which merges the tooling behind canary 1.

Relocated rather than ticked, following the #1090 precedent established in 0.0.4. Ticking an unmet box to green a gate is the one shortcut that would make the whole exercise worthless.

What must be observed

• A canary published; its label derived from the published version, never typed — release:canary-label --published-version reads the version from JSR; canary.10 run: published-version PASS: 0.0.5-canary.10 exists on @netscript/cli
• Prerelease note lists the PRs and closed issues, and does not take Latest — canary.10: release-note-publication PASS: created prerelease v0.0.5-canary.10; make_latest=false
• A second canary published after further merges and labelled — exercised across canary.7→.8→.9→.10→.11
• Payloads differ rather than repeat — canary.10 derived 11 PR(s), 10 closed issue(s) over f69eebf43..origin/main; each canary reported a distinct train. Content-derived membership held across every boundary
• Every gate's report recorded, including pass-vs-did-not-run — per-canary in the run worklog. This criterion earned its keep: canary.10 reported publish FAILURE while all 25 packages were live, producing finding 40 (a publish step's exit code is not the publish's outcome)
• Divergences recorded as findings — canary.2's post-cancel-race divergence, canary.10's unreconciled post-publish state (finding 40), canary.11's 25-of-37 partial (release: JSR weekly publish-attempt limit (1000/scope) exhausted — canary.11 published 25 of 31 packages #1312). Reconciliation used the lane's own release:canary-label tool, not hand edits

Why the recording matters as much as the passing

0.0.4 shipped two guards whose condition could never become true, and a third was found in the release preflight during this very exercise (#1145 — a .generated skip pattern that could not match the file it was written for). A gate that passes because it did not run is the failure mode this cadence exists to eliminate, so "what did each gate actually report" is the deliverable, not a footnote.

Provenance

0.0.4 canary exercise, 2026-08-03. Relocated by the orchestrator so #1122 can merge on its implementable criteria.

---

Scope note (orchestrator, 2026-08-05): criteria originally named 0.0.4-canary.1/.2 because this was filed during 0.0.4. The surface was actually exercised across five 0.0.5 canaries (7–11). Owner delegated the call; criteria rewritten to the milestone actually exercised rather than closing against wording that was never tested. Evidence: #1149 (comment)

[rickylabs]

Inheriting one criterion from #1160, alongside the two-canary evidence this issue already owns:

• Target-scoped drift verified on a real canary cut, not only unit tests (from fix(release): canary drift check is not target-scoped, so every historical canary reports as missing a label #1160, fixed in fix(release): scope canary drift to the target train #1162)

#1162 is the payload for 0.0.4-canary.2, so its live verification necessarily follows its own merge. Ticking it inside that PR would assert a result that does not exist yet.

Live evidence recorded so far — 0.0.4-canary.1

Run 30830242233, cut from release/cut-0.0.4 @ 3072d8b11. Every gate reported explicitly, so a pass is distinguishable from a did-not-run — which is this issue's core requirement:

published-version        PASS: 0.0.4-canary.1 exists on @netscript/cli
merge-history-payload    PASS: 26 PR(s), 47 closed issue(s) from v0.0.3..
label-application        PASS: canary:0.0.4-canary.1 applied to 73 item(s)
release-note-publication PASS: created prerelease v0.0.4-canary.1; make_latest=false
drift                    FAIL: orphan labels=none; missing labels=0.0.1-canary.1,…,0.0.3-canary.5

Artefacts verified independently of the log:

Claim	Verified
published to JSR	0.0.4-canary.1 on @netscript/cli, @netscript/fresh, @netscript/sdk
label exists and applied	canary:0.0.4-canary.1, 73 items
release is a prerelease	tag=v0.0.4-canary.1 prerelease=true draft=false
note contains the payload	26 PRs with titles, each mapped to the issues it closed

D3 held on its first live execution: the label string equals the published JSR version, derived from the publish result rather than from deno.json (which still read 0.0.3 at cut time — the exact trap D3 exists to prevent).

The drift FAIL was a true finding, not noise — filed as #1160 and fixed in #1162 rather than hand-patched by backfilling eleven labels.

Still outstanding here: 0.0.4-canary.2 with a different payload, proving content-derived membership across a real boundary.

[rickylabs]

Live 0.0.5-canary.1 evidence (run release-0.0.5--orchestration, first canary of the exercise this issue asks for):

• Publish + pair: release-canary.yml run 30858888833 success; JSR meta reports 0.0.5-canary.1 on cli/service/contracts/sdk/mcp; pinned e2e-cli-prod success @2026-08-03T22:34Z; release/canary-pair=success @22:42:10Z on content SHA 2c8865e8c (statuses API — pass distinguishable from did-not-run: the status transitioned pending→success).
• Note surface: GitHub prerelease v0.0.5-canary.1, never Latest; body opens with the derivation record: "Canary payload derived from merge-aware history after v0.0.4 (10 commit(s) inspected; outcome: populated)" — the fix(release): canary payload misses work that lands behind a release PR via a merge commit #1166-fixed merge-aware derivation with explicit populated-vs-genuine-empty vocabulary, on its first production run.
• Label surface: canary:0.0.5-canary.1 applied to all 10 payload PRs and 9 closed issues by the workflow (derivation, not transcription).
• Two recorded gaps, both caught by this exercise: [openapi-mcp S2] P2 proof: spec fidelity + size dry-run against a real scaffold #1128 (payload PR honestly carried Refs, so the labeler — which derives from closing references — could not see the orchestrator's evidence hand-close) and fix(ci): close-gate validates issue checkboxes but not PR-body checklists, so a merged PR's body can contradict what shipped #1105 (the merged PR's closing references were empty at merge after pre-merge body edits, so the auto-close never fired and the issue stranded open). Both hand-remediated with evidence comments + labels; run findings 19–20 record the systemic causes.
• Box 4 (payload difference vs first-parent) status: the fixed derivation is live and its synthetic RED→GREEN fixture is merged (fix(release): include merge-buried PRs in canary payload #1180); the real merge-commit-buried topology has not yet occurred on a live cut this train — remains open, watched at each remaining canary point.

[rickylabs]

Canary point 5 record (0.0.5-canary.5, run 30899202735, workflow_dispatch 2026-08-04T10:05:55Z)

• Payload (content-derived, d6375d557..a194d5a03, 4 commits): PR ci: stop respawning/cancelling CI on PR metadata events #1214, feat(mcp): add OpenAPI introspection read tools #1204, docs(runtimes): teach deterministic testing, observation, and failure replay #1203, docs(tutorials): rewrite storefront and chat tutorials to use definePage (phase 1) #1209 (+2 closed issues; 6 items labeled canary:0.0.5-canary.5).
• Verdicts: published-version PASS · merge-history-payload PASS · label-application PASS · release-note-publication PASS (prerelease, make_latest=false) · drift PASS (9 labels / 20 published versions).
• Pinned production E2E: e2e-cli-prod run 30899420836 ✓ against the exact published canary.
• Pair: Record green canary pair + summary steps success; release/canary-pair status set on a194d5a03. Green pair now held by canary.5.
• Numbering note: run 30892876892 (08:39Z) published 0.0.5-canary.4 (its pinned E2E success 08:49Z attaches to .4, not .3 as earlier recorded) — a full rerun of a canary run always mints N+1; canary identity must be read from registry/run logs, never dispatch intent.