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-4224Implemented

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

  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 guardstests/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

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