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

BUG — the `…/work-items/count` endpoint left two structural guards red: unprobed in the MCP drift guard, uncovered in the conformance walk

MOTIR-2318 (11.5.16) added GET /api/v1/projects/{projectKey}/work-items/count and its WorkItemCount component, and left two guards failing on this branch:

  1. tests/mcp/drift-guard.test.ts — "EVERY shared resource is either PROBED or explained — none silently skipped". WorkItemCount is neither: no MCP payload derives from it, and MCP_UNREACHABLE_RESOURCES does not say why.
  2. tests/api/v1/work-item-conformance.test.ts — "fails loudly if an endpoint is added to this story without a conformance step". The count route matches the suite's work-items filter and is not in its covered list.

Both are guards that exist precisely to catch a new endpoint arriving without its paperwork, and both did their job — nobody ran them. Confirmed pre-existing: they fail at the branch HEAD with this card's changes stashed.

Acceptance criteria

  1. WorkItemCount is EXPLAINED in MCP_UNREACHABLE_RESOURCES, not probed: the MCP search_work_items still reports a total on the page itself, which is the shape Amendment 12 moved away from for v1 and deliberately left alone for MCP. The entry says so, and says what would close it (the MCP search dropping its total).
  2. The count endpoint joins the conformance walk with a real step, not just the covered list — asserted AGAINST the collection it counts, because "it counts what the collection would page" is its whole promise and a count that drifts from the page is the only way it can be wrong.
  3. pnpm vitest run tests/mcp tests/api/v1 is green.