The register, actually on the route

🛰️ Satellite — a feature nobody is mounted to is a feature nobody has

The most expensive defect in this codebase is the one that demos green and never ships: work declared done at the component boundary (passes in Storybook, passes a fixture test) while the system boundary — the real route, real backend, the empty first-run state — is never exercised. Six Stories of register can be perfect in isolation and still be, to the lawyer opening a matter, nothing at all: they see the old mock. The register exists only when the route renders it.

The naive version of "mount it" is a one-line import swap. That is the trap. Mounting live means closing the four data seams the Storybook harnesses faked — saved views, the row corpus, the status timeline, the filing derivation — through the real trust boundary, with a first paint that is not a spinner, and proving the zero-document first run (the actual state of every new matter) renders an empty register, not a crash. Swap the mount and retire the legacy, so old and new can't drift apart.

✈️ Airplane — prefetch on the server, hydrate on the client, the same flight every list flies

PRAMAAN has exactly one shape for a list surface: the RSC prefetches into a server QueryClient, dehydrates it, and wraps the client tree in HydrationBoundary; the client reads the same query key from a warm cache — server-rendered first paint, no refetch flash. Story 1517 already built the saved-views half of that round-trip (proxy + gateway + generated hooks). This Story flies it on the live route.

page.tsx (RSC)
  ├─ mattersGateway.listDocuments(id)  ──▶ DocumentListItem[]  (server gateway, already wired)
  │     toRegisterDocuments(...)        ──▶ RegisterDocument[]  → prop
  └─ prefetchQuery(appListDocumentSavedViewsQueryKey(id),
                   documentSavedViewsGateway.list)  ──▶ dehydrate
                                                        │
        <HydrationBoundary> ──────────────────────────┘
          <LiveMatterDocumentsPage matterId documents={rows} />
            └─ <SavedViewsRegister>  ──useAppListDocumentSavedViews(id)──▶ reads warm cache

The one analogy that holds all the way down: the register is a stage, and this Story is raising the curtain. Every actor was rehearsed in a closed room (Storybook). Raising the curtain doesn't rewrite the play — it connects the stage to the house lights (the route), the script to the prompter (the saved-views cache), and lets the audience (counsel) finally see it. The actors don't change; their wiring to the real room does.

🔬 Microscope — the four seams, closed

Saved views — RSC prefetch, best-effort

page.tsx prefetches the matter's views with the exact generated key (appListDocumentSavedViewsQueryKey(numericMatterId)) and the server gateway as the queryFn, mirroring the document-types route. WHY the prefetch is wrapped in try/catch and swallows: a saved-views blip must not 404 the whole Documents page — the client useAppListDocumentSavedViews hook refetches through its /api/internal/* proxy and renders its own viewsLoadFailed state. The documents themselves still ride orNotFound, because no documents = no page.

The row corpus — a prop, not a hook

SavedViewsRegister was authored to take documents: RegisterDocument[] as a prop — the row corpus is server-owned, the saved-views are hook-owned. So the live page adapts the wire rows once with toRegisterDocuments(rows) and passes them down. WHY a prop and not useAppListMatterDocuments: the documents-list browser→server proxy does not exist yet (the systemic gap tracked as Story-1049), and the route already fetches the corpus server-side through the typed gateway. Feeding it as a prop is the wired truth today; the optimistic upload add (onUploaded prepends a row) keeps working because the adapter is pure and re-runs on every rows change.

The detail drawer — lifted into the live container

RegisterTable always exposed onOpenDocument, but nothing upstream filled it — clicking a row did nothing. This Story threads one optional prop through RegisterView and lets SavedViewsRegister own the drawer: it tracks the open row id, builds the drawer view-model with toDocumentDetail, and mounts DocumentDetailDrawerContainer (whose useAppListDocumentStatusEvents hook streams the timeline). WHY the container, not the leaf: the drawer's data hooks belong with the corpus and the query client — the leaf stays Storybook-verifiable without a backend.

Mode-1 honesty — AI/derived columns render empty

The adapter maps every Mode-2/AI field (ai name, document type, tags, proceeding, pages) to its null/empty placeholder, and the filing type/state to null (no batch filing-link endpoint or proxy exists yet — a documented Mode-1 seam, not a gap to paper over). The register renders these as "processing"/"—" until EPIC-009 fills them, so a new matter looks truthful, not broken.

What shipped

Verify: pnpm typecheck ✓, pnpm lint (0 errors), pnpm test (623 passed), pnpm build ✓, storybook:drift ✓, git diff --check ✓.

Files changed

7 file(s), +190 / -211 lines