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

11.6.4 Re-base the PROJECT, SPRINT, BACKLOG and IDENTITY tools onto the shared schemas

The second family, same treatment as 11.6.3: every tool whose output is a project, a sprint, a backlog page, a workspace or the caller's identity derives from the shared schema instead of a hand-built object.

The tools

list_projects · whoami · list_sprints · create_sprint · update_sprint · delete_sprint · start_sprint · complete_sprint · move_to_sprint · move_to_backlog.

list_sprints.ts is the tool that does not return through toolOk (verified on origin/main — the only one). 11.6.2 settles its disposition; this card is where the sprint family lands either way, so if that card brought it through the helper, this is where its payload gets re-based like its siblings.

The sprint membership moves (move_to_sprint / move_to_backlog) have a REST counterpart with a per-item result shape (11.3's membership endpoints). Derive from that rather than re-authoring a parallel outcome object — a batch move reporting per-item outcomes in two different shapes on two surfaces is the same defect one resource over.

Scope BOUNDARY

Ends at this family. It does NOT touch the work-item tools (11.6.3) or the work-loop tools (11.6.5). It does NOT ship the CI drift guard (11.6.6). It does NOT change any tool's name, arguments, scope or description text. It does NOT change /api/v1.

Acceptance criteria

  • Every tool listed above builds its structuredContent from the shared project / sprint / backlog / identity schema or a declared narrowing of it; no hand-authored object and no as unknown as cast remains.
  • Each tool's observable payload is UNCHANGED — same keys, same values — asserted by tests/mcp/sprint-tools.test.ts, list-projects.test.ts and tools.test.ts passing unmodified.
  • list_sprints is inside the totality mechanism, not an unexplained outlier.
  • The membership moves derive their per-item outcome shape from the REST membership schema rather than declaring a parallel one.
  • The totality mechanism accepts this family with no exemption entry.
  • No file imports both zod and zod/v4.
  • The per-file coverage floor (≥90%) holds on every changed file.

Context refs

  • 11.6.2 — the seam and list_sprints' disposition.
  • lib/mcp/tools/listProjects.ts · whoami.ts · listSprints.ts · createSprint.ts · updateSprint.ts · deleteSprint.ts · startSprint.ts · completeSprint.ts · moveToSprint.ts · moveToBacklog.ts — the subjects. Note listProjects.ts builds structuredContent directly today.
  • lib/api/v1/projects/schema.ts · sprints/schema.ts (including membershipMoveResultSchema) · identity/schema.ts · rankedCollections.ts — the shapes derived from.
  • tests/mcp/sprint-tools.test.ts · list-projects.test.ts · tools.test.ts — must pass unmodified.
  • Story: 11.6.