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

11.5.17 `searchWorkItems` onto the v1 collection, and the four `total` readers onto `countWorkItems`

Port MotirClient.searchWorkItems onto GET /api/v1/projects/{projectKey}/work-items, and carry out the consumer half of ADR Amendment 11 Q3: SearchPage.total goes away, countWorkItems arrives over 11.5.16's …/work-items/count, and each of the six total reads routes to whichever of the two it actually meant.

Why this is NOT part of 11.5.4

Same shape as nextReady, and the same rule. Amendment 11 Q3 settles that the count-only sites stop pretending to be searches — but three of the six total reads live in command files, which 11.5.4's boundary forbids touching ("does NOT change … any command file"):

  • packages/cli/src/commands/read.ts:105 — inFlightCount: search.total, from a limit: 1 search
  • packages/cli/src/commands/read.ts:188 — renderSprintItems(result.items, result.total)
  • packages/cli/src/commands/doctor.ts:80 — total: page.total, from a limit: 1 search
  • packages/cli/src/commands/plan.ts:163 — if (page.total > 0) return;

The other two are outside that boundary but belong with them: packages/cli/src/session.ts:128 (total = page.total, inside a full page walk) and packages/cli/src/doctor.ts:319 (renders the ServerProbe.project.total the command sets).

Keeping total on SearchPage by having searchWorkItems ALSO call /count was considered and rejected: it makes two requests where one sufficed on motir status and motir doctor, and it ships the shape Amendment 11 explicitly named as the wrong one.

The split, per read

sitebecomes
commands/read.ts:105 · commands/doctor.ts:80countWorkItems — they send limit: 1 and discard the row. They are counts.
commands/plan.ts:163countWorkItems — > 0 is a count question.
session.ts:128items.length — it already walks every page, so it HAS the number.
commands/read.ts:188Follows whatever collectSprintItems returns after the session.ts change.
doctor.ts:319Unchanged — it renders ServerProbe.project.total, which the command still sets.

Scope BOUNDARY

searchWorkItems, the new countWorkItems, and the six reads above. It does NOT touch render.ts (a diff on it fails this card, the same as 11.5.4), any other command, any flag, or any output string — motir status, motir doctor and motir plan must print byte-identically. It does NOT change a server endpoint: 11.5.16 shipped everything the server owes this card.

Acceptance criteria

  • searchWorkItems calls /api/v1/projects/{projectKey}/work-items through the transport, sending the versioned FilterAST envelope, and returns the same result set the MCP tool did for an identical filter.
  • countWorkItems calls …/work-items/count and is the ONLY way the CLI learns a match count.
  • SearchPage no longer declares total; no file reads it.
  • motir status, motir doctor and motir plan produce byte-identical output to the MCP-era implementation for the same underlying data, asserted per command.
  • motir status and motir doctor each make ONE request for their count, not a paging walk and not a search-plus-count.
  • render.ts is byte-identical to its pre-card state.
  • No generated wire type is imported outside the adapter module.
  • The per-file coverage floor (≥90%) holds on every new and modified file.

Context refs

  • ADR docs/decisions/public-api-conventions.md Amendment 11 — Q3 is this card's brief.
  • 11.5.16 — the count operation this consumes.
  • 11.5.4 — the adapter module and transport wiring this builds on.
  • packages/cli/src/mcpClient.ts — searchWorkItems, SearchPage.
  • packages/cli/test/helpers/mcpTestServer.ts — must serve /api/v1 for these wrappers, as 11.5.4 establishes.
  • Story: 11.5.