Motir

Repo: motir-core. One PR. The story's end-to-end test — the verification_recipe automated — and, because this story ships a surface a person watches, its acceptance video.

The flow to drive

1. Arrive unauthenticated and reach the reference through the public door, from the shipped public chrome — not by typing the URL. A test that navigates directly proves the page exists and proves nothing about whether anyone can find it.
2. Read an operation: open one from the catalogue, see its method, path, required scope, parameters, response schema and error statuses.
3. Copy the authenticated example and assert what landed on the clipboard is the curl for that operation, with the bearer header present.
4. Follow getting-started through its five steps and land on the stability policy from the docs navigation.
5. Reach the reference from the in-app door: signed in, from the API-tokens settings page, follow the link and arrive.
6. Fetch the spec itself over real HTTP with no Authorization header and assert it parses as a document — the client-facing half of the surface, which no browser assertion covers.

The states, not just the happy path

• Spec unavailable — the failure state renders its message rather than an empty page or a crash.
• Small viewport — the flow works at a phone width, and the page body does not scroll horizontally while a wide code block does scroll inside its own container.
• Wait on authoritative signals, never on timeouts — the repo's E2E discipline.

The acceptance video

This Story has a user-observable surface, so the E2E also records and publishes the acceptance video to the story, using the shipped harness and its chaptering — it is the receipt a reviewer watches to accept, not merely a pass/fail signal.

Pace it for a human. The clip is something a person watches; a run that races through every chapter in a few seconds satisfies every criterion and produces a receipt nobody can review. Let each step be legible — the operation opening, the example being copied, the guide being read — and let the chapters carry the story's shape.

Scope BOUNDARY

Ends at the browser flow, the unauthenticated spec fetch and the published video. It asserts no schema-level or document-structure property — the drift guard (11.4.6) and the story gate (11.4.9) own those, and re-deriving them here would be slower and weaker. It changes no production code: a defect it finds is a bug filed against the card that owns the surface, not a patch here. It does not test 11.5's CLI or 11.6's MCP alignment.

Acceptance criteria

• A Playwright spec drives the whole flow above, reaching the reference through the public door and separately through the in-app door, both by clicking rather than by direct navigation.
• The copied example is asserted from the clipboard and matches the opened operation.
• The getting-started walk and the policy page are reached from the docs navigation.
• The spec URL is fetched with no credentials and the response parses as a document.
• The spec-unavailable state and the small-viewport layout are both asserted.
• Every wait is on an authoritative signal; no fixed sleeps.
• The run records and publishes the acceptance video to the story, chaptered, and paced to be watchable — the publish step's own watchability floor passes without the pacing being tuned down to meet it.
• The spec runs in the existing Playwright CI matrix.

Context refs

• tests/e2e/acceptance-cli-connect.spec.ts — a shipped acceptance spec with chaptering and publishing; the pattern to follow.
• docs/decisions/acceptance-video.md — the acceptance-video contract, including why there is a watchability FLOOR and no duration ceiling.
• .github/workflows/acceptance-video.yml — the publishing lane; .github/workflows/ci.yml — the Playwright matrix this spec joins.
• design/api-docs/ — the surface under test and the states it must show (11.4.2).
• Blockers: 11.4.7 · 11.4.8. Sibling suites: 11.4.6 · 11.4.9. Parent story: 11.4.