Skip to content
Motir
Start free

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
Follow  — continues on app.motir.co
Request a featureAtom feed

← Motir · Work items

MOTIR-4224Implemented

Vitest gate (motir-marketing) — the host router, the per-host canonical and crawl surface, and the standing no-database-client rule

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

  1. Coverage floor — run vitest --coverage over 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 under app/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 when addresses is absent from an older DTO.
  2. Integration seams — the seams the units mock: (a) the contract's real PublicHostResolutionDto fixtures (recorded from motir-core's OpenAPI examples, as e2e/fixtures/*.json are) driven through the router into a rendered tab page, asserting the host-relative hrefs and the canonical in ONE pass; (b) the index's primaryHost field driven through loadAllPublicProjects into the sitemap, asserting inclusion and omission per host; (c) the alias resolution driven through the router into the 301.
  3. Standing guards — tests/publicProject/standingRules.test.ts's no-database-client rule still holds; SITE_ORIGIN is still read by one module; appOrigin's build-fails-when-unset behaviour is unchanged; the new NEXT_PUBLIC_MOTIR_TENANT_DOMAIN obeys the same single-reader rule; the request path never calls the contract for motir.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.mock of 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-marketing is touched.

Context refs

  • motir-marketing/vitest.config.mts · tests/publicProject/*.test.ts (standingRules, publicApiSeam, crawlIndex, projectShell) — the suites this extends
  • motir-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