MOTIR-2611 broke `acceptance-api-docs.spec.ts` and its own PR could not see it — the sandbox guide's step 2 now has TWO Copy buttons, and the acceptance lane only triggers on `acceptance*.spec.ts` paths

Repo: motir-core. One PR. main is red in the acceptance lane right now, and it will stay red for every PR that touches an acceptance spec until this lands.

What happens

Playwright E2E (acceptance-video) → tests/e2e/acceptance-api-docs.spec.ts:269 "a reader with no session finds the sandbox guide from the rail and leaves with a runnable docker run", in the chapter Copy the command it came for:

Error: locator.click: Error: strict mode violation:
  locator('#start-the-container').getByRole('button', { name: 'Copy' }) resolved to 2 elements
    at tests/e2e/acceptance-api-docs.spec.ts:322

1 failed | 74 passed (29.9m).

Why

MOTIR-2611 (9379ee22, #2015) did exactly what its AC 1 asked: step 2 now renders a docker pull + docker run pair. Two commands means two <pre> blocks in #start-the-container, so two Copy buttons — and line 322's locator is unscoped.

The spec was already half-prepared for this: line 319 reads page.locator('#start-the-container pre').first(). The pre got a .first(); the button never did.

Why its own PR was green

The acceptance workflow triggers on paths: ['tests/e2e/acceptance*.spec.ts']. #2015 touched lib/apiDocs/sandbox.ts and no spec, so the lane never ran on it — the page changed and the only test that reads that page was not executed. It surfaced on the next unrelated PR that happened to touch an acceptance spec (#2017, the quick-view story), whose own spec passed.

This is the main-is-never-tested-directly shape: two green PRs, one red main.

Do this

1. Fix the locator so it names the command it means. Prefer scoping to the run block over .first() — the chapter's whole point is "the command it came for", and after MOTIR-2611 there are two commands, so .first() would silently assert the pull while the copied-text assertion below still expects the docker run. Read what line 325's assertion actually checks and make the locator agree with it.
2. Cover the pull command too, or say in a comment why it is not covered — a page that renders two commands and tests one is how the next one drifts.

The structural half (the reason this is high, not a one-liner)

A docs page and the spec that reads it are one unit, and the lane's paths: filter cuts between them. Either:

• widen the acceptance workflow's paths: to include the sources its specs assert against (lib/apiDocs/** at minimum), or
• state explicitly, in the workflow header, that a change to a page an acceptance spec reads must touch that spec to get itself tested — and accept the recurrence.

The first is the real fix; the second is a decision, not an oversight. Pick one deliberately rather than leaving the gap unnamed. Note the trade the first option makes: the lane is ~30 min and publishes receipts, so widening the filter means more PRs pay for it — worth costing before choosing.

Acceptance criteria

1. acceptance-api-docs.spec.ts:269 passes against the current /docs/sandbox, with the copied-text assertion checking the command the chapter names.
2. The locator cannot silently pass on the wrong command — if it scopes by position, a comment says which block that is and why.
3. A deliberate choice is recorded (in the PR body) on the paths: gap above, and if the answer is "widen", the workflow change ships in this PR.
4. The acceptance lane is green on the PR.

Context refs

• tests/e2e/acceptance-api-docs.spec.ts:318-326 — the failing chapter; :319 already carries the .first() the button lacks.
• lib/apiDocs/sandbox.ts — step 2 start-the-container and its command builder, as MOTIR-2611 left them.
• .github/workflows/acceptance-video.yml — the paths: filter that let this through.
• Observed on run 31423865640 (PR #2017), job Playwright E2E (acceptance-video).