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

11.5.8 Story end-to-end — teach the socket harness to serve `/api/v1`'s DYNAMIC routes, then drive the BUILT binary through the whole loop against them

This story's E2E, in the only form it has: the CLI has no browser surface, so Playwright is the wrong instrument and the equivalent — the artefact a user actually runs, driven end to end over a real socket — is the built-binary story suite Story 7.9 established. Same harness, re-pointed.

The real work: the harness cannot serve a v1 route yet

tests/helpers/mcpHttpServer.ts puts a real HTTP listener in front of REAL App-Router route modules, and it serves exactly three paths today — /api/mcp and the two /api/cli/device/* endpoints. None of them has a dynamic path segment, and every /api/v1 route does ([projectKey], [key], [sprintId]). So the adapter has never had to match a pattern or build the { params } object a handler is called with. That is this card's first deliverable:

  1. Route MATCHING + params. Register v1 route modules against their path patterns, match an incoming pathname, extract the segment values, and invoke the handler with the { params } shape Next gives it — including the async-params form the shipped handlers use. Serve /api/openapi/v1.json too if the client reads it.
  2. Keep the harness's honesty property. It 404s anything it was not asked for, on purpose, so a test that accidentally depends on some other route fails instead of silently passing against a hand-built fake. Do not widen that into a catch-all.
  3. Real everything else. Real withV1Route, real bearer auth and scope gate, real rate limiter, real services, real Postgres. Nothing stubbed but the two programs the CLI shells out to and deliberately does not own — the user's coding agent and gh — which the harness already fakes and records.

Then: drive the loop

Re-point tests/cli/cli-story.test.ts at the v1 harness and walk the journey a user walks: authenticate with a real PAT → link a project → list the ready set → show an item (with its build-order waves) → read its activity → fetch a dispatch prompt → run the fake agent → mark integrated → close the session. Plus the states a happy path skips: an empty ready set, a revoked token, a scope-refused call, a rate-limited call, a not-found key.

The assertion strings do not change. They are the byte-identical proof: the suite asserted this output against MCP, it asserts the same output against v1, and any edit to an expected string is the tell that the migration lost something — not that the test was wrong.

No acceptance video. Non-UI story, exempt under the acceptance-video rule's carve-out, exactly as 11.111.3 were; and the story's own success condition is that a user sees nothing change, so there is nothing to watch.

Scope BOUNDARY

Ends at the harness's v1 support and the re-pointed story suite. It does NOT re-test individual endpoint behaviour (11.7 owns that) or unit-level client behaviour (11.5.7). It does NOT change product code — a failure here is a defect to report against the card that caused it. It does NOT install a browser or a Playwright lane for a program that has no browser surface. It does NOT publish anything: this card ends at a green suite.

Acceptance criteria

  • The harness serves /api/v1 route modules by pattern, extracts dynamic segments correctly for single- and multi-segment paths, and passes the handler the params shape it expects — asserted directly, including a request whose path matches no registered pattern still 404ing.
  • The built binary — the tsup bundle package.json#bin points at, as a real child process over a real socket — completes the full loop above against real routes, a real PAT and real Postgres.
  • Every expected-output string in the command-level suites is unchanged from its pre-migration value; the diff for those files shows no assertion edits.
  • The five non-happy states each produce their intended message and exit code: empty ready set, revoked token, missing scope, rate limit, unknown key.
  • motir show renders the build-order WAVE view with real per-child dependency edges served by a real route.
  • The suite runs in the root vitest lane (it needs Postgres) and leaves no worker-shared state behind — the harness's existing build lock and stamp still hold across workers.

Context refs

  • tests/helpers/mcpHttpServer.ts — the adapter to extend; its header documents exactly why it serves one path today and why it 404s everything else.
  • tests/helpers/cliHarness.ts — the built-binary spawner, its cross-worker build lock, and the recorded fakes for the coding agent and gh.
  • tests/cli/cli-story.test.ts — the suite to re-point, and the source of the unchanged assertion strings.
  • app/api/v1/**/route.ts — the handlers to register; note every one takes a dynamic segment and an async params object.
  • lib/api/v1/route.tswithV1Route, which stays entirely real in this harness.
  • Predecessor: 11.5.6 — the CLI is not fully on v1 until that card lands.
  • Story: 11.5.