Motir

Every acceptance recording this run owned failed to publish, and the lane reported success. Two independent failures compound here: the publish itself is broken, and the step that runs it does not fail when it fails.

Surfaced while running MOTIR-2479 (Story MOTIR-2258). The spec is fine — it records a 47s chaptered clip and passes locally and in CI. Nothing reached the story.

The evidence

Run 31307902905, job 93231084525, Playwright E2E (acceptance-video) — check status: pass, 25m42s. Inside it:

Publishing 2 of 17 recording(s) — the ones produced by the acceptance spec(s) this run changed:
  tests/e2e/acceptance-permission-gated-ui.spec.ts, tests/e2e/acceptance-roles-permissions.spec.ts.
Authenticating the acceptance-video publish via keyless GitHub OIDC.
Failed to publish acceptance-permission-gate-…-chromium → MOTIR-2258:
  Failed to parse URL from vercel_blob_client_Wv5V9fWWFsXURacA_MDY2…
##[error]Acceptance publish failed for MOTIR-2258: Failed to parse URL from vercel_blob_client_…
Failed to publish acceptance-roles-permissio-…-chromium → MOTIR-2282:
  Failed to parse URL from vercel_blob_client_ODU1…
##[error]Acceptance publish failed for MOTIR-2282: …
2 publish failure(s) and 1 unpublishable recording(s) out of 18.
Published 0 of 2 owned acceptance recording(s) (18 recorded in this run).

And the step's own conclusion, from the jobs API:

{"conclusion":"success","name":"Publish the acceptance video"}

Two stories lost their receipt — MOTIR-2258 and MOTIR-2282 — and no signal anywhere says so.

Two defects, and they should be fixed in this order

1 · THE STEP FAILS OPEN — fix this first, it is the one that hid the other. The uploader printed two ##[error] lines and Published 0 of 2, and still exited 0. A publish step whose failure is invisible is worse than no publish step: it converts a missing artifact into a silently missing artifact, and the only way anyone finds out is by reading a 4,500-line log for a lane that says pass. Exit non-zero when an OWNED recording fails to publish. (An unpublishable clip — MOTIR-2268's 14.5s one, below the watchable floor — is a different verdict and may stay non-fatal, but it should be counted separately from a failure.)

2 · THE BLOB UPLOAD IS BROKEN. Failed to parse URL from vercel_blob_client_<token> — a token is being passed where a URL is expected. MOTIR_UPLOAD_TOKEN is empty in this run (line 4307) and the script correctly fell back to keyless OIDC, which authenticated fine; the failure is after that, in the blob handoff. Read the publish path end to end rather than patching the string: the shape of the message says an argument order or a return value changed, not that a credential is missing.

Why this is highest priority

This is the published-artifact-vs-obtainable shape exactly, and the reason that rule exists: a green lane is not evidence that an artifact was published. Every story that has "records the acceptance video" in its acceptance criteria has been closing on a check that cannot fail. Nobody knows how long this has been broken, which is the first thing to establish.

Acceptance criteria

• The publish step exits NON-ZERO when any owned recording fails to publish, and a test or a dry-run proves it (the guard must be shown to be able to fail — the THE GUARD CAN ACTUALLY FAIL convention this repo already uses).
• An unpublishable-but-not-failed recording (under the watchable floor) is reported and counted distinctly from a failure, and does not turn the lane red on its own.
• The blob upload succeeds: a run publishes its owned recordings, and the PR body carries the story key + the resolved video URL, fetched — not the lane's exit code.
• How far back does this go? Walk the recent Acceptance video runs and record in the PR body the last run that actually published, so the blast radius on already-done cards is known rather than assumed.
• MOTIR-2258 and MOTIR-2282 get their recordings published, or a card each to re-record.

Context refs

• scripts/upload-acceptance-video.mjs — resolveStoryKey, findRecordings, and the blob handoff that throws.
• .github/workflows/acceptance-video.yml — the step whose conclusion is success while the script reports failure.
• Run 31307902905 / job 93231084525 — the log quoted above.
• MOTIR-1680 — the previous uploader defect (published the wrong clip), same file, and evidence this path has form. </descriptionMd>