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-2188Done

11.4.7 The published API reference — the docs surface rendering every operation from the spec, plus the two doors that reach it

Repo: motir-core. One PR. The story's user-facing card: the public documentation surface a developer reads, and the two entrances that get them there. Until this lands, the API is complete and undiscoverable.

Build to the asset 11.4.2 produces in design/api-docs/ — read design-notes.md and the mock BEFORE writing any markup, and treat the design as authoritative about which elements this card owns and which belong to the surfaces it only places an affordance in.

What to build

  1. The docs shell + the reference page, at the routes 11.4.1's Amendment 4 pins, in the public route group so an unauthenticated developer can read it. Render every operation from the emitted document — grouped by resource, each showing method, path, required scope, parameters, request body, response schema and error statuses.
  2. The copy-pasteable authenticated example per operation: a curl carrying Authorization: Bearer motir_pat_… with a placeholder token, correct for that operation's method, path and body, with a copy affordance.
  3. Both entrances, because a door drawn and not built is the same as no door:
    • the public entry, in the shipped public chrome, exactly where the design places it;
    • the in-app entry on app/(authed)/settings/account/api-tokens/page.tsx, linking a user who has just minted a token to the reference and the guide. Add only that affordance — do not otherwise change the token manager, which design/settings/ owns.
  4. Read the spec from the emitter, not over HTTP. The page and the served document have the same source (11.4.4's registry); a page that fetches its own public URL adds a network round trip, a failure mode and a bootstrapping problem for no gain.
  5. The real-product states: the surface stays navigable as operations grow (in-page navigation and find, per the design), wide code blocks scroll inside their own container rather than the page, the small-viewport layout works, and there is a spec-unavailable state that says what a reader should do.

Compose components/ui/* primitives and the --el-* / shape tokens; no Tier-0 colour, no raw spacing utilities, no invented colour. Page chrome goes through next-intl with an en.json key and its zh.json twin for every string — the catalog-parity gate is enforced. Spec-derived operation text stays English, per Amendment 4; if the amendment decided otherwise, follow the amendment.

Scope BOUNDARY

Ends at the reference surface and its two entrances. It writes no prose content — the getting-started guide and the stability policy are 11.4.8, which mounts into the shell this card establishes. It changes no schema, no operation declaration and no endpoint; a rendering problem traced to a bad declaration is fixed in 11.4.5, not patched in the view. It does not redesign the settings page, the public top bar or the explore pages — one affordance each, as drawn. It ships its own unit tests; the story-level coverage gate and the E2E are separate cards.

Acceptance criteria

  • The reference renders every operation in the emitted document — asserted by comparing the rendered operation set against the registry, so an operation added later cannot go unrendered.
  • Each operation shows its method, path, required scope, parameters, request body where it has one, response schema and error statuses, and a copy-pasteable authenticated curl example correct for that operation.
  • The pages are reachable without a session: an unauthenticated request to the reference route renders it.
  • The public entry affordance exists in the shipped public chrome, and the in-app entry exists on the API-tokens settings page — both placed and labelled as the design draws them, and both asserted by a test that follows the link to the reference.
  • No file under app/(authed)/settings/account/api-tokens/ changes apart from the added link.
  • The spec-unavailable state renders a useful message rather than an empty page or a crash.
  • Wide code blocks scroll within their own container; the page body never scrolls horizontally at a small viewport.
  • Every new UI string has an en.json key and a zh.json twin; the catalog-parity check passes.
  • The rendered surface matches the design asset; any deliberate deviation is recorded in design/api-docs/design-notes.md with its reason.
  • New files join the per-file coverage thresholds in vitest.config.ts at the ≥90% floor.

Context refs

  • design/api-docs/ — the design asset (11.4.2); build to it, and read its ownership notes.
  • lib/api/v1/openapi/ — the emitter and registry (11.4.4 / 11.4.5) the page reads.
  • app/(public)/explore/layout.tsx · app/(public)/_components/PublicTopBar.tsx · app/(public)/explore/_components/ExploreFooter.tsx — the shipped public group and its chrome.
  • app/(authed)/settings/account/api-tokens/page.tsx — the in-app door's host surface.
  • components/ui/* · app/globals.css — primitives and the token layers.
  • messages/en.json · messages/zh.json — the catalogs every new string joins in pairs.
  • Blockers: 11.4.2 · 11.4.5. Parent story: 11.4.