Motir

The second half of the finding on 2026-09-01: the lane holds 23 acceptance*.spec.ts members (orientation only — recount on fresh origin/main) because the guard meant to force them out has never been able to read a receipt. Fixing the guard is its own card; this one does the work the guard would have demanded.

MOTIR-2769 did this triage once. The lane refilled, because nothing enforced the lifecycle afterwards.

The rule being applied

docs/decisions/acceptance-receipt-lifecycle.md §3: a spec is a TEST, its video is one EXECUTION. Once the story's receipt is APPROVED the spec has discharged its job and leaves the lane by exactly one of two routes — there is no third, and no "leave it for now", which is the silent default that grew the lane to 26 last time:

• PROMOTE — the flow is worth protecting on every PR. Rename it out of the acceptance prefix, swap the import to _helpers/promoted-regression (which no-ops the chaptering and pacing), and keep every assertion.
• RETIRE — the receipt exists and the flow is covered elsewhere. Delete it, and say where the coverage now lives. A deletion that cannot name its cover is a coverage regression wearing a cleanup's clothes.

⚠️ The destination is not always the main lane. This lane's server is CLOUD-ON with the motir-ai, code-health and GitHub-provisioning mocks; the main lane's is none of those. A spec whose subject is gated must be promoted into cloud-<name>.spec.ts (playwright.cloud.config.ts, MOTIR-2849), or it goes green off-cloud for a reason it is not testing — the MOTIR-2601 failure. docs/acceptance-lane-triage.md records which spec went where last time.

⚠️ Do not edit a spec's assertions to match how the product behaves today. That reflex is right for a regression test and exactly backwards for a receipt (motir-core#2051 is the instance).

Acceptance criteria

1. Every member of the lane at the start of this card has a recorded disposition — promoted (and to which lane) or retired (and where its coverage lives) — appended to docs/acceptance-lane-triage.md, one line per spec.
2. After the change, find tests/e2e -maxdepth 1 -name 'acceptance*.spec.ts' returns only specs whose story's receipt is not approved. Verify by running tests/e2e-acceptance-lane-membership.test.ts with MOTIR_GUARD_BASE_URL + MOTIR_GUARD_TOKEN set — it must pass on its own strength, not by degrading.
3. No assertion is lost without a named home: for each promoted spec, its assertions survive the rename; for each retired one, the doc line names the spec or suite that covers the flow.
4. Every promoted spec runs in a lane that can actually reach its surface — a cloud-gated subject lands in the cloud lane, not the main one. State per promoted spec which flags its subject needs and which lane supplies them.
5. The E2E shard plan still accounts for every spec that moved (tests/e2e-shard-plan.test.ts fails on an unmeasured new spec — it must be green, not bypassed).

Out of scope

The guard's credential (its own card), the lane's trigger and concurrency (theirs), and the rename. This card moves specs and records dispositions; it does not touch acceptance-video.yml.