Vitest gate (motir-marketing) — the host router, the per-host canonical and crawl surface, and the standing no-database-client rule
Opened by Zhu Yue ·
The story-level Vitest gate for motir-marketing — a coverage floor over what the router and the canonical card changed, the seams between them that their own units mock, and the repository's standing guards re-asserted after the largest change to its request path since it gained /p/*. It runs after both code cards merge and measures their REAL merged coverage; it does not enumerate cases they should have written.
What it does at run time
- Coverage floor — run
vitest --coverageover the story's changed surface (proxy.ts,lib/publicHost.ts,lib/tenantDomain.ts, the workspace-root route,app/sitemap.ts,app/robots.ts, the metadata and JSON-LD builders underapp/p/**) and, wherever a file is under the project's per-file floor, write the missing branch tests — the arms the two cards' own units left: the router's host-normalisation edge cases, the sitemap on a host the contract 404s, the redirect helper whenaddressesis absent from an older DTO. - Integration seams — the seams the units mock: (a) the contract's real
PublicHostResolutionDtofixtures (recorded frommotir-core's OpenAPI examples, ase2e/fixtures/*.jsonare) driven through the router into a rendered tab page, asserting the host-relativehrefs and the canonical in ONE pass; (b) the index'sprimaryHostfield driven throughloadAllPublicProjectsinto the sitemap, asserting inclusion and omission per host; (c) the alias resolution driven through the router into the301. - Standing guards —
tests/publicProject/standingRules.test.ts's no-database-client rule still holds;SITE_ORIGINis still read by one module;appOrigin's build-fails-when-unset behaviour is unchanged; the newNEXT_PUBLIC_MOTIR_TENANT_DOMAINobeys the same single-reader rule; the request path never calls the contract formotir.co.
Scaffolds verified, not assumed: the fixtures directory and the publicApiStub exist (e2e/stub/publicApiStub.ts, e2e/fixtures/), but they serve the Playwright lane — this gate runs in node/jsdom and stubs fetch in-process; say which it uses and why.
Acceptance criteria
- Every file in the changed surface listed above meets the project's per-file coverage floor after this card, with the report attached to the PR.
- The three seam tests exist and each drives a real recorded fixture through the real consumer code (no
vi.mockof the module under test). - The standing guards named above are asserted in this card's suite and are green; the tenant-domain variable has exactly one reader.
- No production code changes except test-only helpers; no file outside
motir-marketingis touched.
Context refs
motir-marketing/vitest.config.mts·tests/publicProject/*.test.ts(standingRules,publicApiSeam,crawlIndex,projectShell) — the suites this extendsmotir-marketing/e2e/fixtures/·e2e/stub/publicApiStub.ts— the recorded shapes (for the browser lane; this card records its own for node)- the router · the canonical card — what it measures
- MOTIR-4121 — the previous story's gate for this repository, the shape to follow
Discussion
No comments yet.
Adding to this discussion signs you in on app.motir.co and brings you back to this request.