Motir

Type: code · Executor: coding_agent · Repo: motir-marketing · ONE PR.

The seven documents and a renderer for them, on the host that serves the brand. This is the RECEIVING half of the move: the documents port across as they are, and the pages are built to the design asset.

⚠️ RE-FILED 2026-08-30 — this card now lives under MOTIR-3932

It was authored under MOTIR-3909, and this card is the reason that story's cross-parent leaf edges looked unliftable: it sat upstream of MOTIR-3884 while the deletion card sat downstream of it, so a story-level edge in either direction was a cycle, and three leaf edges were wired under plan-rules/fixtures/phase-skeleton.md's no-legal-lift limb.

The exemption did not apply. phase-skeleton.md offers RE-FILE as remedy (b) and it was never tested. This card's repo is motir-marketing, which is MOTIR-3932's entire repository set, and that story is "motir.co renders the public reading surface" — which is exactly what this card does. Re-filed here with the design asset, the interleave is gone: every remaining cross-story edge runs one way, and MOTIR-3909 blocked_by MOTIR-3932 carries the whole ordering.

What arrives

content/legal/*.md from motir-core — terms, privacy, cookies, acceptable-use, dpa, subprocessors, model-providers (git ls-tree -r origin/main -- content/legal at e76d1afdd, seven files). Byte-for-byte, front matter included: their prose is moooon B.V.'s legal work, and a diff on the way across is a change to a published contract nobody approved. The PR body carries the checksum of each file on both sides.

What has to be BUILT here, because this repository does not have it

Measured on motir-marketing origin/main 3035904:

The front-matter parser is a MOVE, not a rewrite. motir-core's parseLegalDocument and byPreferredOrder are exported and pure precisely so they are unit-testable; port them and their tests rather than writing a second parser with different behaviour around TBD, an absent title, or an empty changeSummary.

Choosing the Markdown renderer is this card's call, and the criterion is not convenience: the documents are trusted first-party content, so sanitisation is not the driver; the drivers are that headings, lists and tables render to the design asset's treatment and that nothing is added to the dependency tree that the subprocessor page would then have to disclose. Say in the PR body which was chosen and why.

The English-only consequence, stated rather than discovered

motir-core carries messages/en.json AND messages/zh.json, and the legal.* namespace (metaTitle, indexTitle, allDocuments, indexContact, breadcrumbAria, the version lines) exists in both. motir-marketing is English-only, so the page chrome around these documents loses its Chinese translation. The DOCUMENTS themselves were never translated — there are seven English files and no zh variants — so what is lost is the surrounding labels, not the contract text. That is accepted here and recorded on the card; adding an i18n framework to the marketing site is a different question, and no card in this story owns it because nothing in this story depends on it.

The crawl surface

• app/robots.ts and app/sitemap.ts already exist in this repository. The seven documents and the index are added to the sitemap; nothing about motir-core's sitemap changes, because it never listed them (git grep -i legal origin/main -- app/sitemap.ts → no matches; MOTIR-3881 settled that).
• Server-rendered, no client directive, no gate — the reason is in motir-core's shipped layout comment and it still applies: "a legal page a crawler cannot read is one a customer's procurement review cannot find."
• No loading.tsx anywhere above the document route. [slug]/page.tsx calls notFound() for an unknown slug, and a loading boundary above a route that decides existence turns a 404 into a 200 that renders like one.

The referrer this card owns in its own repository

lib/destinations.ts derives LEGAL_PRIVACY, LEGAL_TERMS and LEGAL_INDEX from APP_ORIGIN — they currently point at app.motir.co/legal/*. Once these pages exist here they are same-origin, and app/_components/SiteFooter.tsx renders all three. tests/destinations.test.ts asserts the current shape and moves with them.

Boundary

• It does not rewrite the documents, and it does not renumber, retitle or re-version them.
• It does not delete anything from motir-core — the deletion card does, over in MOTIR-3909, and it runs later for a reason: delete before the redirect and the paths 404 for everyone holding a link. That ordering is carried by the story edge.
• It issues no redirect. app.motir.co/legal/* → motir.co/legal/* is MOTIR-3884's — a sibling subtask under this same story, and blocked_by THIS card, so the destination exists before the redirect points at it.
• It builds no chrome. The header, nav and footer are MOTIR-3880's asset, rendered by its own sibling cards here; this card composes whatever chrome this repository has when it runs and says which in the PR body.
• It reads no database and adds no API call. These pages are files on disk.

Acceptance criteria

• The seven documents are at motir-marketing/content/legal/, byte-identical to motir-core origin/main — the PR body carries a per-file checksum from both sides.
• /legal renders the index with all seven rows in PREFERRED_ORDER, and /legal/<slug> renders each document, matching the design asset — layout, states and the primitives it names.
• Both arms of the effective-date line render, and the literal TBD never reaches a page — asserted by a test over the real content/legal/ directory, which is the arm in force today.
• An unknown slug is a genuine 404 with that status code, asserted; no loading.tsx sits above the document route.
• The front-matter parser is the ported parseLegalDocument, and its unit tests come with it — including the absent-title, TBD-date and empty-changeSummary cases.
• lib/destinations.ts's LEGAL_* are same-origin, SiteFooter renders them, and tests/destinations.test.ts asserts the new shape.
• app/sitemap.ts lists /legal and all seven documents; app/robots.ts does not disallow them.
• No database client, no Prisma import and no connection string appears in this repository — the standing rule for this repo, asserted.
• The chosen Markdown renderer is named in the PR body with the reason, and any new dependency is checked against content/legal/subprocessors.md's own disclosure before it is added.
• The English-only consequence is recorded in the PR body and in a comment beside the copy, naming what is lost and what is not.
• pnpm lint · format:check · typecheck · build · test pass; AA contrast holds in both themes.

Context refs

• motir-core/content/legal/ — the seven documents, at origin/main e76d1afdd
• motir-core/app/(public)/legal/page.tsx · [slug]/page.tsx · layout.tsx — the shipped behaviour, including the notFound() and no-loading.tsx reasoning
• motir-core/lib/legal/documents.ts — parseLegalDocument, byPreferredOrder, PREFERRED_ORDER, and the TBD → null mapping
• motir-core/tests/legal/legalDocuments.test.ts · legalPagesRender.test.tsx — the tests that come with the parser and the pages
• motir-marketing/lib/destinations.ts · app/_components/SiteFooter.tsx · tests/destinations.test.ts — the in-repo referrers
• motir-marketing/app/sitemap.ts · app/robots.ts — the crawl surface
• motir-marketing/package.json — the dependency set, and the disclosure consequence of adding to it
• the design asset — blocked_by, sibling
• MOTIR-3884 — the redirect, which this card unblocks; sibling
• the marketing Vitest gate — asserts this card's output, and stays in MOTIR-3909 because its other blocker is a motir-core card

Advisory dispositions

• The remaining reference advisories name cards this one's Boundary excludes. A boundary exists to say a deliverable is somebody else's, and naming the owner is what makes the exclusion checkable — so the reference is deliberate and no edge is owed.