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 · Work items

MOTIR-4121Done

Vitest gate (motir-marketing) — the /p/* coverage floor, the public-API seam, and the standing no-database-client rule

The story's motir-marketing suite gate — the second half of the per-repo split. It runs after this story's five motir-marketing page cards merge and measures their real, merged result.

1 · Coverage floor over the /p/* surface this story added — app/p/** and lib/publicProject.ts — filling whatever the per-card units left between them. This repository's suite is jsdom + node with no database, so it is fast and there is no excuse for a thin one.

2 · The seam the units mock: the public-API client. Every page here reads through one module, and every unit test of a page mocks it. So the seam nothing covers is the module against the shapes motir-core actually returns: drive recorded real responses from the public contract through lib/publicProject.ts and out to the components' props, including the cursor round trip. A key that drifts between the served document and the DTO restated in this repository is exactly the failure public-surface-hosts.md §8 cost 2 names, and it is invisible to a mock that was written from the same assumption as the code.

3 · The guarantees coverage cannot see.

  • The standing no-database rule. lib/explore.ts states it — "this repository does NOT read the database … No database client (the standing repo rule, asserted by a test)". Find that assertion, and make sure it reaches app/p/** and lib/publicProject.ts too rather than only the surfaces it was written for.
  • Origins do not cross. Every canonical, og:url and JSON-LD @id on a /p/* page names SITE_ORIGIN; every API read names APP_ORIGIN. Getting these the wrong way round is silent in production and is precisely what lib/siteOrigin.ts's header warns about.
  • The error state is reachable. With the public API unreachable, every /p/* route renders its error state rather than throwing — asserted per route, since this is the state that only exists because the renderer and the data are now in different deployments.

Do not re-assert what the page cards already ship, and do not duplicate the E2E: this is a suite, not a browser. Its residue is the seam, the guards, and the coverage top-up.

Acceptance criteria

  • Coverage over app/p/** and lib/publicProject.ts meets this repository's floor, with the gaps filled here.
  • A seam test drives recorded real public-API responses through the data module to the rendered output for each /p/* route, cursor paging included, and fails on a key drift.
  • The no-database-client assertion covers the new files; a deliberate @prisma/client import anywhere under app/p/** turns the suite red.
  • A test asserts SITE_ORIGIN for every canonical / og:url / JSON-LD @id on /p/*, and APP_ORIGIN for every API read.
  • Every /p/* route renders its error state — not an exception — when the public API is unreachable, asserted per route.
  • The suite runs in the existing test job with no new CI job, and pnpm test stays a seconds-long run.
  • No file outside motir-marketing is touched.

Context refs

  • motir-marketing/vitest.config.mts · tests/setup.ts — the harness
  • motir-marketing/tests/explore/ · tests/legal/ — the closest precedents for testing a surface fed by the public API
  • motir-marketing/tests/appOrigin.test.ts · tests/siteOrigin.test.ts · tests/destinations.test.ts — the origin assertions to extend
  • motir-marketing/lib/explore.ts — the standing no-database rule and where it is asserted
  • motir-core/app/api/openapi/public.json/route.ts — the served contract the recorded fixtures must come from
  • motir-core/docs/decisions/public-surface-hosts.md §8 costs 1 and 2