Motir

Estimate: 25m

The design asset for showing ready / blocked readiness INSIDE the /issues quick-view (peek) modal. The shipped quick-view.mock.html (2.5.18) deliberately scoped the peek as a read preview and listed the readiness badge (2.4.5) as DETAIL-ONLY (design-notes "What the peek shows vs. what stays detail-only", L805–811). This subtask reconciles that decision: the peek should surface an item's readiness so a user can tell at a glance, while scanning the list, whether the item is Ready to start or Blocked (and on what) — without opening the full page. Because the existing mockup does not draw this in the peek, 2.5.21 would be improvising UI without this asset — the planning-time design gate (notes.html mistake #31), the same gate 2.5.7 / 2.5.9 / 2.5.18 closed for their surfaces.

No new visual primitive — reuse the shipped ReadinessBadge (2.4.5). The ready/blocked treatment already exists as a reusable primitive (components/ui/ReadinessBadge — mint "Ready to start" / peach "Blocked · Waiting on N issue(s) — PROD-3, PROD-8" with the open blockers named as links, state carried by TEXT not colour alone, AA-safe per finding #35). This design DOES NOT invent a new badge — it decides WHERE the existing badge sits in the peek and how it behaves in the modal context. Update design/work-items/quick-view.mock.html + the design-notes.md "Work-item quick view (peek) modal" section to cover:

• Placement — where the ReadinessBadge lives in the two-column peek (e.g. a full-width row at the top of the main column above the Description, or at the top of the 300px core-fields rail). Pick one and justify it briefly; keep it consistent with how the badge reads on the detail page.
• States (multi-panel) — blocked (named open blockers as links), ready ("All blockers resolved"), and no blockers at all (mirror the detail-page rule: an item with no is_blocked_by in-edge shows NO banner — there is no readiness signal to give; confirm the peek follows the same rule rather than rendering an empty/"ready" banner for everything).
• Blocker links inside a modal — the named-blocker links route to /issues/[key]. Decide whether clicking one swaps the peek to that key (?peek=) or navigates to the full page (closing the peek); the detail-page badge links straight to the detail page — note which the peek uses and why.
• Reconcile the design-notes — move "readiness badge" OUT of the peek's "Detail-only" list and into "What the peek shows", so the doc and the mockup agree (the relationships/links panel itself STAYS detail-only — only the readiness signal is promoted).

Mirror the output convention of the prior design subtasks (2.4.7 / 2.5.7 / 2.5.9 / 2.5.18). Colour only through --el-*; the badge's tones come from --el-tint-mint / --el-tint-peach with --el-text-strong; AA-safe (finding #35); toggle dark mode in the mockup to confirm token parity.

Acceptance criteria

• quick-view.mock.html gains the readiness treatment in the peek (the shipped ReadinessBadge shape — NO new visual primitive) with blocked · ready · no-blockers (no banner) panels, and the design-notes.md peek section documents its placement, the named-blocker link behaviour (swap-peek vs. navigate), and the no-blockers rule.
• The design-notes "Detail-only" list is updated — readiness is promoted into the peek; the relationships/links panel stays detail-only.
• Consistent with the detail-page readiness banner (2.4.5) and tree.png toolbar; colour flows only through --el-*; state is conveyed by text + icon, not colour alone; AA-safe (finding #35).

Context refs

• design/work-items/quick-view.mock.html + design-notes.md "Work-item quick view (peek) modal" section (the surface to extend) + its "Detail-only" line to reconcile
• design/work-items/relationships.mock.html + the design-notes.md "Relationships panel + ready/blocked badge" section (2.4.5) — the readiness banner this reuses
• components/ui/ReadinessBadge.tsx (the shipped primitive) + components/ui/* inventory + app/globals.css --el-* tiers + the /tokens route