Motir

The smallest card in the story and the one that unblocks the most: three fields the v1 schemas drop, each of which a shipped CLI renderer reads. In all three cases the data already exists — v1 narrowed it away at the schema, so this is a widening, not a new read.

What to build

1. Per-CHILD dependencies on workItemDetailSchema.children. Today children is workItemRefSchema[] with no edge block, so assignChildWaves — the build-order WAVE view 7.9.16b shipped — has no v1 source. Attach via workItemsService.getDependencyEdgesForItems, which the MCP get_work_item tool and the ready route already use: two batched queries for the whole page, never one per child. A 43-child story stays a single round-trip.
2. Per-ROW dependencies on workItemSummarySchema. Same projection, applied to the work-item collection so renderSprintItems' BLOCKED BY / BLOCKS columns (7.9.16) have a source. Bounded over the page already read.
3. The blocked ancestor's TITLE on readinessSchema. lib/dto/workItems.ts:393 carries a full WorkItemSummaryDto; lib/api/v1/workItems/schema.ts:406 maps it to detail.readiness.blockedByAncestor?.identifier ?? null. renderReadinessLine prints blocked by ancestor <key> — <title>. Widen the schema to carry both; add alongside blockedByAncestorKey, do not replace it — that field is published API under §8.

The N+1 is the risk, and it is the only one

Each of these is a page-level projection or a field already in hand. The failure mode is doing it per row: invisible on a 3-item fixture, quadratic on a real sprint. ADR Amendment 3 Q4 permits exactly the bounded form and forbids the per-row one; app/api/v1/projects/[projectKey]/ready/route.ts is the shipped worked example, with the reasoning in its header.

Scope BOUNDARY

Ends at these three fields. It adds NO endpoint — every route it touches already exists. It does NOT change any service, repository or query; all three projections call methods that ship today. It does NOT touch the MCP surface, which already returns all three. It does NOT change or remove any existing field: §8 is additive-only, so blockedByAncestorKey stays exactly as it is.

Acceptance criteria

• workItemDetailSchema.children carries a dependencies block with the SAME key names the MCP tool emits (blockedBy / blocks, each entry { key, title, status }), asserted against the MCP payload for the same row so the two cannot disagree from day one.
• workItemSummarySchema carries the same block on the collection read.
• readinessSchema carries the blocked ancestor's title alongside the existing key; blockedByAncestorKey is unchanged and still published.
• Every projection is BOUNDED: a query-count assertion proves a page of N children or N rows costs a constant number of queries, driven with N large enough that a per-row implementation would fail it.
• Each new field appears in the emitted OpenAPI document, and the operation-coverage test stays green.
• packages/cli/src/render.ts's assignChildWaves, renderSprintItems and renderReadinessLine each render correctly when fed the v1 payload — driven through the REAL renderer, not asserted by inspection.
• No existing field is renamed, retyped or removed from any published schema.
• The per-file coverage floor (≥90%) holds on every changed file.

Context refs

• 11.7.1 Q4 — records these as §8-permitted additions and confirms the bounded form.
• lib/api/v1/workItems/schema.ts — workItemDetailSchema, workItemSummarySchema, readinessSchema (~line 240), and the mapper at ~line 406 that currently drops the ancestor.
• lib/dto/workItems.ts:393 — blockedByAncestor: WorkItemSummaryDto | null, the full object already in hand.
• lib/services/workItemsService.ts — getDependencyEdgesForItems (~line 3885).
• lib/mcp/dependencyEdges.ts + lib/mcp/tools/getWorkItem.ts — the shipped attach pattern and the key names to match exactly.
• app/api/v1/projects/[projectKey]/ready/route.ts — the bounded-projection precedent, reasoning in its header.
• packages/cli/src/render.ts — the three consumers: lines 570, 372, 739.
• Consumers: 11.5.4 (the CLI adapters) and 11.6 (whose criterion 5 reads on field 1).
• Story: 11.7.