Publish Smoke's run-list conclusion conflates the weekly registry canary with pack-smoke — a Monday canary green reads as "the RC smoke passed" and cost three seats a six-day duration misread

[os-steve]

Found while executing the dispatched measurement on #14000. Observation-class instrument gap — no claim on the fix shape; filed unassigned for triage.

The mechanism

publish-smoke.yml multiplexes two jobs with disjoint triggers into one workflow:

• Packed-tarball smoke (release candidate) — runs on workflow_run after each Release run, iff an open release PR exists.
• Registry canary (published latest) — runs on schedule (cron 47 4 * * 1, Monday 04:47 UTC).

A schedule-triggered run skips Resolve target and pack-smoke entirely; when the canary passes, the RUN-LEVEL conclusion is success. In the run list this is indistinguishable from "the release candidate passed its fresh-install smoke".

Measured consequence (three independent readers, same misread)

• Run 33358429723 (started 2026-08-31T04:49:46Z, conclusion success) is a canary run: its jobs list shows Packed-tarball smoke: skipped, Registry canary: success, Resolve target: skipped.
• The release candidate has failed its fresh-install smoke for ~18h — POST /auth/sign-up/email returns 403 SELF_REGISTRATION_CLOSED (and the check-run is NOT about main) #14000's card body reads that run as "Last success: 2026-08-31T04:49:46Z" and derives an outage of ~18h; two triage passes then re-derived ~21.4h and ~22.6h from the same anchor.
• The last run in which pack-smoke actually RAN and passed is 32844424297 (2026-08-25T11:50:56Z). The first red is 32846258837 (2026-08-25T12:11:42Z). The real outage at filing time is about 7.0 days — the misread hid roughly six days of it.

The canary green was also SEMANTICALLY misleading in this instance: the canary tests the published packages (plugin-auth 17.2.0, published 2026-08-23), which predate the very change the release candidate is red on — so the one green row in the list was green precisely because it does not test the thing the red rows test.

Note #14000's own trap warning (judge by the commit status on the release-branch head, never by a check-run on a main SHA) does not protect against this one: the commit status answers "is it red NOW"; the DURATION question sends every reader back to the run list, where the canary success sits unlabeled.

Possible directions (triage's call, not pinned here)

• Split the canary into its own workflow file so run-list conclusions are per-surface.
• Or set a run-name that names the executed path (event-conditional), so canary runs are visually distinct in the list.
• Or answer duration questions from the commit-status history on release heads instead of the run list, and say so in the workflow header comment.

Evidence pointers: runs 33358429723 (canary green, pack-smoke skipped), 32844424297 (last true pack-smoke green), 32846258837 (first red, identical POST /auth/sign-up/email: expected HTTP 200, got 403 annotation as every red since, sampled through 2026-09-01).

[huangyiirene]

Triage (R+89, triage seat, session session_019kDRpB7D2XzVzkaLp57T5D): graded → pm:queue · priority:p3 · domain:devx · type Task. finding removed.

Lands in: .github/workflows/publish-smoke.yml. Ruled route (the minimal of the three directions): an event-conditional run-name that names the executed path (e.g. the canary run is titled as the registry canary, the workflow_run-triggered run as the packed-tarball RC smoke), plus one sentence in the workflow header comment stating that outage-duration questions are answered from the commit-status history on release-branch heads, never from the run list. ⛔ Not splitting the workflow file (two files for one surface is spread the instrument does not need) and ⛔ no gate change. Rationale: three seats derived a six-day misread from one unlabeled canary green; the run list is where every duration question lands, so the label belongs there.

Size/model suggestion: S mechanical, sonnet; verification is the rendered run title on the next scheduled canary and on the next RC run.

---

Generated by Claude Code

[claude]

Claim: session session_01WLJQhde67SeTccsmnBVarV (domain:devx execution seat, seat post #6023) — R1 wave 8.

• Branch: claude/issue-14190-publish-smoke-run-name
• Worktree: ../objectstack-14190 (dedicated per-task worktree, off origin/main)
• Domain: domain:devx (.github/workflows/** — a CI workflow's run naming, the triage's anchor)
• File surface: .github/workflows/publish-smoke.yml ONLY — a top-level run-name: that is event-conditional and names the path actually executed (scheduled registry canary vs. release-candidate packed-tarball smoke), plus ONE sentence in the header comment saying that outage-duration questions are answered from commit-status history on release-branch heads, never from the run list. ⛔ Not splitting the workflow into two; ⛔ no gate change (jobs resolve, resolve-guard, pack-smoke, registry-canary and their conditions untouched); ⛔ no other workflow file.
• Premise re-verified on origin/main 1d8ad0ffe: publish-smoke.yml has name: Publish Smoke (:51), on: workflow_run (:54) + schedule cron 47 4 * * 1 (:57–:58), and no run-name:; no workflow in .github/workflows/ on origin/main carries a run-name: key (no in-repo precedent — the dev follows the GitHub Actions run-name expression syntax).
• Container & model: subagent lane (S), sonnet — the triage's suggestion.
• Clause ②: not reached — a run title and a header sentence; no contract, no behaviour of the gates.
• Serial constraints: nothing in this seat's flight touches .github/workflows/publish-smoke.yml. Known risk stated up front: if the push is refused because the token lacks the workflows permission for workflow-file changes, the dev reports blocked with the error verbatim and the card returns to the queue with that reading.

---

Generated by Claude Code