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

11.5.21 The COLLECTION reads over `/api/v1` — `listReady` and `listSprints`

The second of the three read slices 11.5.4 was split into. It ports the two COLLECTION reads and converts exactly the suites they break, so this card lands green on its own.

methodv1 operation
listReadyGET /api/v1/projects/{projectKey}/ready
listSprintsGET /api/v1/projects/{projectKey}/sprints, walked to exhaustion

Both mappers go into the adapter module 11.5.4 introduces; this card does not define a second one.

What is specific to these two

  • The ready ORDER is the server's — the dispatch rank (type asc, priority desc, key asc) — and passes through untouched. A client that re-sorted would be re-deriving the decision the ready endpoint exists to own.
  • assigneeId is TRI-STATE on the wire. Absent means any assignee; the literal none means the UNASSIGNED bucket. The view model's null IS that bucket, so it must become the literal — dropping it as "no value" silently widens the filter.
  • kind / priority are REPEATABLE (11.5.15 made them exploded arrays). motir ready --kinds epic,story must put ?kind=epic&kind=story on the wire.
  • A sprint's committedPoints / committedIssueCount pass THROUGH, never defaulted. null means "never activated", and a ?? 0 would report a scope-lock baseline that was never taken.
  • The ready row's dependencies is TOTAL on a v1 server — two arrays, empty rather than missing — so the view model's optional block is always present, and motir ready's BLOCKS column keeps its data.

Scope BOUNDARY

These two methods and the suites they break. It does NOT port getWorkItem / getWorkItemActivity (11.5.22) or touch --json. It does NOT change render.ts, any flag, or any human-readable output string. It does NOT delete the MCP transport (11.5.6).

Acceptance criteria

  • Both methods call /api/v1 through the transport core; no MCP tool call remains on either path.
  • motir ready, motir sprint and motir status produce output identical to the MCP-era implementation for the same data — including the BLOCKS / BLOCKED BY columns, asserted against a row carrying real edges.
  • --kinds epic,story puts TWO kind parameters on the wire, asserted off the recorded request rather than off the client call.
  • The unassigned bucket sends assigneeId=none; an absent filter sends no assigneeId at all. Both asserted on the wire.
  • The ready page's ORDER is the server's — asserted by feeding a page whose rank differs from every field the client could sort on.
  • A sprint that was never started still reports null committed figures, not zeros.
  • A paged read carries the opaque cursor through unchanged, and never hands one collection's cursor to another.
  • The whole packages/cli suite is GREEN at this commit.
  • The per-file coverage floor (≥90%) holds on every new and modified file.

Context refs

  • scratchpad/11.5.4-wip.patch — this slice's mappers and fixtures are already written there.
  • 11.5.4 — the adapter module and the harness's /api/v1 capability this builds on.
  • 11.5.15 — why kind / priority are arrays.
  • lib/api/v1/ready/schema.ts · sprints/schema.ts — the wire shapes.
  • packages/cli/test/read.test.ts (the ready / sprint blocks) · commands.network.test.ts — the suites this slice converts.
  • Story: 11.5.