MotirBuilding in public
MOTIR · moooon
onMotir
You’re viewing a public project. Anyone can view it — no account needed. Sign in to submit, upvote, or comment on requests.View-only — you can’t edit work items
MOTIR-2690

The starter's acceptance-video lane still carries `continue-on-error: true` — the pre-MOTIR-2499 shape that reports success while receipts are lost

Done
Description

Found while building MOTIR-2673, the starter's design-result lane, which was written deliberately WITHOUT continue-on-error. Its neighbour still has one.

.github/workflows/acceptance-video.yml in nextjs-prisma-vercel-starter, line 151:

      - name: Publish the acceptance video
        if: success()
        continue-on-error: true
        uses: ./.github/actions/upload-acceptance-video

This is the exact shape MOTIR-2499 removed from motir-core, and for a reason that transfers whole: continue-on-error rewrites a failing step's conclusion to success — on the checks UI, in gh pr checks, AND in the REST API. Measured upstream from 2026-08-07, the publish failed on every run ("Published 0 of 2", two ##[error] lines), the lane reported pass each time, and two stories lost their receipt with nothing anywhere saying so. A check that cannot fail is worse than no check.

Every project scaffolded from this starter inherits it, so the blast radius is every adopter's acceptance receipts, not one repo's.

What replaces it

The wrapper existed so a side effect could never gate a merge. Both cases that justified it are handled INSIDE the uploader, which returns 0 for each — verify that this starter's vendored copy does too before removing the wrapper:

  • No credential (a fork PR gets neither OIDC nor the secret) → log that publishing is opt-in and return 0.
  • A defect in a spec this run does not own → reported and annotated as a warning, counted separately; only the specs the PR changed can fail it.

What SHOULD fail the step is exactly what remains: a story this PR owns ending the run without a published receipt.

The ::error:: annotation and the job summary stay — they put the reason on the run page instead of thousands of lines into the raw log. They become a second channel rather than the only one.

Acceptance criteria

  • continue-on-error: true is removed from the publish step in .github/workflows/acceptance-video.yml.
  • Before removing it, the vendored scripts/upload-acceptance-video.mjs (or the composite action it calls) is confirmed to return 0 for the no-credential case and for a non-owned unwatchable/over-cap recording — and made to, if it does not. Removing the wrapper without that check turns a fork PR red.
  • A test asserts the publish step carries no continue-on-error, the way tests/design-assets-uploader.test.ts asserts it for the design-result lane — a workflow file is not typechecked, linted or executed by any suite, so the property is guarded or it is not held.
  • A comment on the step records WHY it must not come back, naming the measured cost, so the next reader does not re-add it as a kindness.

Context refs

  • nextjs-prisma-vercel-starter/.github/workflows/acceptance-video.yml — the step, line ~151.
  • motir-core/.github/workflows/acceptance-video.yml — the publish step's header, which carries the full rationale and the measurement.
  • nextjs-prisma-vercel-starter/.github/workflows/design-result.yml — the sibling lane written without one, and its guard test.
  • MOTIR-1941 — the port that brought the acceptance lane here, before MOTIR-2499 landed upstream.