The canonical issue page — the read surface a PROD-N link opens. A Server-Component route at /issues/[key] that composes the shipped reads (getWorkItem, children, parent chain, links, revisions) into one page: header (type icon · identifier · title · status), the rendered Markdown description + AI-drafted explanation, a read-only core-fields panel, a parent breadcrumb + child list for tree navigation, a workflow-aware inline status control and an inline assignee picker (the only two write affordances on the page — everything else routes to 2.3.6's edit form), and a relationships panel that becomes the FIRST production caller of 2.2.6's isReady (finding #21's payoff — the blocked/ready badge). The layout reserves explicit, documented extension slots for Epic 5 (comments · attachments · custom fields · activity) so that Story lands as additions, not a rewrite.
Prerequisites (all shipped or in-flight): Story 1.4 ships the work-item reads (workItemsService.getWorkItem, listChildren, getWorkItemSubtree, listRevisions) + the work_item_link dependency table. Story 2.1 ships the type metadata + icons (lib/issues/issueTypes.ts). Story 2.2 ships the workflow statuses / transitions / category taxonomy and workflowsService.isReady + canTransition (2.2.6 — this Story is its first PRODUCTION caller; until now isReady is exercised only by the _test route). Story 2.3 ships MarkdownView (2.3.5), the filtered pickers + StatusPicker/AssigneePicker (2.3.4/2.3.6), and the /issues/[key]/edit route (2.3.6) the detail page's "Edit" button targets. This Story is read-first: it adds NO new mutation primitives — the two inline controls reuse 2.2.4's gated updateStatus and 2.3.6's now-status-free updateWorkItem (for assignee). All routes follow motir-core/CLAUDE.md's 4-layer architecture and carry an explicit workspaceId gate at the application layer (finding #26 — RLS is defense-in-depth, inert under the dev/CI superuser until the Epic-8 cutover). Route reconciliation (rung 2 > rung 3): issue routes live under the shipped active-project shell at app/(authed)/issues/[key]/ (resolving the active project via getActiveProject()), NOT the card-illustrative /projects/[key]/issues/... — same decision recorded as finding #50 for 2.3.3/2.3.6. The detail page (page.tsx) and 2.3.6's edit page (edit/page.tsx) are siblings in that tree; getWorkItemByIdentifier is shared — whichever of 2.4.1 / 2.3.6 lands first adds it, the other reuses it (do NOT add a second copy).
pnpm install && pnpm prisma generate && pnpm prisma migrate dev against a fresh local DB (no new migration expected — this Story is read-first).pnpm test — Vitest covers: getIssueDetail shape + cross-workspace 404 (2.4.1); fields panel + AI-drafted badge (2.4.2); breadcrumb/children + isolation (2.4.3); inline status/assignee actions (2.4.4); readiness verdict + link grouping (2.4.5).pnpm test:e2e — issue-detail-flow (2.4.6 — incl. the link add/remove + guardrail scenarios from 2.4.9) + the shell-a11y sweep on /issues/[key] (incl. the open add-link combobox).PROD-N link; confirm header, rendered Markdown description, AI-drafted explanation badge, core fields, parent breadcrumb, child list all render; the "Edit" button opens the 2.3.6 form.