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-4105Blocked

Playwright E2E + acceptance video (motir-core) — /legal is gone from the app host and the configured legal journey still works without it

Opened by Zhu Yue ·

Type: test · Executor: coding_agent · Repo: motir-core · ONE PR. This story's end-to-end walk on the application host, and — because a person watches the surfaces it drives — its acceptance receipt.

The walk is about what is GONE and what still works without it. MOTIR-4015 walks the configured and unconfigured legal links under MOTIR-3909, with app/(public)/legal/ still in the tree; its step asserting a 404 on /legal was cut in the same plan that created this card, because that route only stops answering here.

The flow, which is this story's verification recipe automated

The route is gone:

  1. Request /legal and /legal/terms on the application host — asserted on the STATUS CODE, not on a rendered page. A 404, or whatever MOTIR-3884's redirect answers with if it is reached first — assert what the shipped arrangement actually returns, read from it, rather than asserting a number this card guessed. Either way, nothing served from this repository renders a legal document.
  2. next build produces no route under app/(public)/legal; the route manifest is in the PR body.

The configured journey still works with nothing in content/:

  1. Sign-up shows both legal links, each href equal to the configured absolute URL on the brand host, and each a plain anchor rather than a client-navigating link — assert the element and the attribute, because a cross-origin next/link looks identical until it is used.
  2. Sign in — the rail's Legal row is present and points at the configured index.
  3. A signed-in reader whose accepted version is materially behind is held at /re-consent; each outstanding row links to that document's configured URL; Agree and continue returns them to where they were going, and a second page load is not held.

The unconfigured arm still degrades correctly:

  1. With no manifest: the sign-up card renders NO legal paragraph at all, the rail has no Legal row, and nothing 500s. ⚠️ AMENDED 2026-09-01 (MOTIR-4004, docs/decisions/public-surface-hosts.md AMENDMENT 2 §D): the notice is ABSENT, not re-flowed — a sentence entirely about two documents becomes FALSE rather than merely weaker when they do not exist. This is the self-hoster's state, and after this story it is the state of a build with neither a manifest nor any documents in the tree — which no earlier lane could exercise.

⚠️ THE LANE — read its configuration before writing a line in it

The manifest and MOTIR_CLOUD are process-wide, server-side reads. A branch resolved that way has no per-test override and no client seam a request stub can reach, so a spec written in a lane that does not set them passes on unfixed code and stays green for ever — the failure mode is a permanent pass, not a red test.

Rung-2 evidence that a cloud lane already exists: tests/e2e/cloud-legal-reconsent.spec.ts is shipped and drives the re-consent hold. Start there, and read MOTIR-4015's spec as it merged — it solved this same lane problem one story earlier, and re-solving it is duplicated work.

  • name the exact mechanism each arm relies on, in the spec's own comment;
  • assert the arm is MOUNTED before asserting anything about it — that the build really is in the unconfigured state, that it really is cloud — so nothing can pass vacuously;
  • if one lane cannot host both arms, say so and put each arm in the lane that can, rather than weakening an assertion to fit.

States, not just the happy path

  • Empty — step 6's unconfigured arm.
  • Loading — waited on by authoritative signals, never a timeout.
  • Error — a configured entry whose URL is unreachable: the page must still render, because the link's target is another host's problem and not a reason for sign-up to fail.
  • TerminalAgree and continue is the terminal act; assert the acceptance is recorded and the next load is not held.

The acceptance video

The walk drives surfaces a person watches, so this card records and publishes it to this story as its acceptance receipt. It is PACED for a human — a reviewer watches it to accept the story — so the spec waits on real signals and does not race. There is no duration cap; the only machine check is a floor, and a clip too fast to watch fails the publish. The receipt's subject is the absence: what a reviewer needs to see is that the documents left and the journey did not break.

⚠️ What this card does NOT walk

  • motir.co/legal in a browser. MOTIR-3886's — the public site's whole-journey spec, already done, whose step 4 opens a legal document from the footer on the public host. Standing up a second cross-origin harness here would duplicate it.
  • The 301 itselfMOTIR-3884's.
  • The manifest seam's unit-level behaviourthe vitest gate's, in this story.
  • The deployed manifestthe live-gate confirmation reads that from the running application; an E2E against a local build cannot.

Acceptance criteria

  • One spec covering steps 1–6, green in CI, waiting on authoritative signals throughout — no arbitrary timeouts.
  • Step 1 asserts the STATUS CODE for /legal and /legal/terms, and the PR body states which arrangement produced it (the deleted route, or the redirect reaching them first) with the reading that established it — not an assumed number.
  • Step 2's route manifest is in the PR body and contains no app/(public)/legal entry.
  • Step 3 asserts the element type AND the href — a plain anchor, and a URL equal to the configured value rather than a path.
  • Step 5 drives the hold, the row's configured link, the agree act, the recorded acceptance and the un-held second load.
  • Step 6 asserts each unconfigured behaviour specifically, including the ABSENCE of the sign-up legal paragraph — the assertion is that the element is not in the tree, never that a re-flowed sentence reads well. ⚠️ AMENDED 2026-09-01 (MOTIR-4004, docs/decisions/public-surface-hosts.md AMENDMENT 2 §D): the notice is ABSENT, not re-flowed — a sentence entirely about two documents becomes FALSE rather than merely weaker when they do not exist.
  • Each of the four state cases above is asserted.
  • The spec asserts each arm is MOUNTED before asserting anything about it, and names in a comment the exact mechanism that puts the lane in that arm.
  • The acceptance video is recorded, paced for a human, and published to this story; the publish is green and its evidence id is recorded on the card.
  • The spec adds no flake: it is run repeatedly in the lane before the card closes, and any environmental failure is triaged and logged, never re-run blind.
  • The PR body records which assertions were inherited from MOTIR-4015 and which are new, so the two specs are not silently divergent copies.

Context refs

  • motir-core/tests/e2e/cloud-legal-reconsent.spec.ts — the shipped re-consent walk and the cloud lane it runs in; the starting point
  • motir-core/tests/e2e/_helpers/ — the fixtures and the acceptance-video pattern
  • motir-core/docs/decisions/acceptance-video.md — the receipt's contract and its floor
  • motir-core/CLAUDE.md — the E2E discipline (authoritative waits)
  • motir-core/app/(auth)/sign-up/_components/SignUpCard.tsx · app/(authed)/_components/SidebarNav.tsx · app/(auth)/re-consent/ — the surfaces walked
  • the deletion card — what makes step 1 true; blocked_by
  • MOTIR-4015 — the sibling walk under MOTIR-3909, whose 404 step was cut and landed here
  • MOTIR-3886 — the public-site walk that covers motir.co/legal

Advisory dispositions

  • Any reference advisory naming MOTIR-4015 or the cards under MOTIR-3909: NOT an owed leaf edge. They sit in another container, and this story is blocked_by that container; the edge belongs BETWEEN the stories and already exists (core.md gate 4's cross-parent limb; gate 7).
  • The remaining reference advisories name cards this one's What this card does NOT walk list excludes. Naming the owner is what makes the exclusion checkable, so the reference is deliberate and no edge is owed.

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