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-1734

Acceptance-video uploader publishes only ONE clip per lane run — every extra chaptered acceptance spec is silently dropped

Done
Description

Found at motir run [MOTIR-1733](motir:cms35kapg002m04i9eln2bllr) (out-of-scope finding, logged not absorbed — notes.html #27).

scripts/upload-acceptance-video.mjs findArtifacts() resolves exactly one artifact set per lane run:

const chapters = files.find((f) => f.endsWith('chapters.json'));   // FIRST match in walk order
const inDog = (f, ext) => f.endsWith(ext) && (!chapters || path.dirname(f) === path.dirname(chapters));
const video = files.find((f) => inDog(f, '.webm'));

main() calls it ONCE, and ci.yml's Publish the acceptance video step runs the script ONCE for the whole acceptance-video lane. Its comment ("Only the chaptered happy-path test writes chapters") was true when the dogfood was the lane's only chaptered spec — it is no longer true.

Impact. The lane's testMatch is **/acceptance*.spec.ts, and the planner rule (MOTIR-1644) creates an acceptance-video subtask for EVERY user-facing story, so the lane now holds several chaptered specs, each with its own acceptance-story.json:

  • acceptance-video.spec.ts → MOTIR-1627 (dogfood)
  • acceptance-augment-replan.spec.ts → MOTIR-811
  • acceptance-plan-change-conversation.spec.ts → MOTIR-1726 (MOTIR-1733, this run)

Only whichever chapters.json fs.readdirSync yields first is published; the other stories get no acceptance video at all, with no warning — the run is green and the publish step reports success for one story. That defeats the per-story acceptance receipt MOTIR-1700 promises, and it gets worse with every new user-facing story.

Acceptance criteria

  • findArtifacts returns every recording directory that contains a chapters.json (video + trace + chapters + story sidecar per directory), not the first.
  • main() publishes each one to ITS OWN declared story; a per-recording failure is reported without aborting the remaining publishes.
  • A recording with a video but NO chapters.json keeps today's fallback behaviour (PR-derived / fallback story), and a red run still publishes nothing.
  • Two recordings that declare the SAME story publish both (or dedupe deliberately) — decided and stated, not left to walk order.
  • Unit coverage over a fixture output dir with 3 recordings proves 3 publishes with the 3 distinct story keys.