Skip to content

moooon

Motir

Vibe your whole project. Bring an idea — Motir's three AI layers plan it, track it, and ship it, end to end. You're looking at Motir, built in Motir.

  • Vibe Project
  • Open Source
  • AI Agent
  • AI Loop
1
requests
0
upvotes
145
planned
1,361
shipped

Motir · Roadmap

MOTIR-4096Done

(motir-core) The lane is called `Acceptance video` and no longer publishes one — rename it to the acceptance TESTS and retire the CI publisher, now that the agent uploads the receipt over MCP

Opened by Zhu Yue ·

Decision (Yue, 2026-09-01): CI does not upload the acceptance recording any more — the agent publishes it through the Motir MCP surface. What is left in this workflow is a test lane, and its name should say so.

The lane still carries the whole CI publishing apparatus. It runs on every PR run of the lane and does nothing useful: on run 33441202811 the publish step reported "Nothing to publish: 2 publishable recording(s), none produced by a spec this run changed" — while still shipping a PAT into the job.

What to rename

  • The workflow name:Acceptance tests, and the file → .github/workflows/acceptance-tests.yml.
  • The job names, the shard job's display name, and the artifact names (playwright-report-acceptance-video-shard-*).
  • The header prose. A large part of it is about publishing — the publish-once-across-shards argument (MOTIR-2600), the ownership filter (MOTIR-1937), the one-clip-per-run defect (MOTIR-1734), the belt-and-braces "the baseline never publishes" section. Those paragraphs go with the step they explain; do not leave orphaned reasoning about a mechanism the file no longer has.
  • docs/decisions/acceptance-video.md gets an amendment recording that the publisher moved to MCP and when — not a deletion. The receipt concept, the lifecycle and the review flow are unchanged; only who uploads changed.

What to retire

The publish step and its env, .github/actions/upload-acceptance-video/, scripts/upload-acceptance-video.mjs, and tests/acceptance-video-uploader.test.tsafter checking what else consumes them. Anything still reachable stays and the card says why. The ACCEPTANCE_* env names, ACCEPTANCE_FALLBACK_STORY_KEY, and the owned-specs step exist only to feed the uploader; verify before deleting rather than assuming.

What must NOT change

  • MOTIR-1949's property. A PR that owns no acceptance spec still shows no check at all — absent, not a greyed Skipped. That is why this is a separate paths:-filtered workflow and not a job in ci.yml, and the rename must not turn it into one.
  • The push: main baseline and its membership gate (MOTIR-2760, MOTIR-2908) — separate cards own those.
  • The recording itself. Playwright still records (video: 'on'); the clips still land in the report artifact a reviewer can open. Only the CI upload goes.

Acceptance criteria

  1. grep -ri 'acceptance.video\|acceptance-video' .github/ scripts/ package.json returns nothing but the ADR's history/amendment section. Predicate, not a file count.
  2. No job anywhere references MOTIR_UPLOAD_TOKEN. ⚠️ Interaction: MOTIR-4093 wires that same secret into the Vitest lane for the lifecycle guard. Whichever card lands second must leave the guard's credential working — check origin/main before deleting the secret's last consumer, and if the guard is already wired, the secret stays and only this workflow's use goes.
  3. On a PR that changes an acceptance*.spec.ts, gh run list shows a run named Acceptance tests; on a PR that changes nothing in the trigger's paths:, the PR carries no acceptance check of any name.
  4. Branch protection is updated in the same change window — the required-check name moves with the workflow, and a stale required check named Acceptance video would block every PR forever. Say in the PR body whether the check was required, and confirm the new name after merge.
  5. The artifact a red leg leaves behind is still findable: a failing shard still uploads its Playwright report with the video and trace (MOTIR-1706's defect was a red leg leaving nothing).

Context refs

  • .github/workflows/acceptance-video.yml — the publish step at the end of the shard job, and the header.
  • attach_file on the MCP surface is the door the agent now uses for a card's evidence; app/api/work-items/[id]/acceptance-evidence/ and the acceptance panel are unchanged and stay.
  • The starter carries a copy of this lane and gets its own card — one repo, one PR.

Discussion

No comments yet.

Adding to this discussion signs you in on app.motir.co and brings you back to this request.

Add a comment