Three navigations, one matter

🛰️ Satellite — why a matter page needs three navigations, not one tab strip

A litigator's matter is three different questions at once, and a single tab strip answers none of them well. "What matter am I in and how urgent is it?" is identity — it changes nothing. "What facet of the work am I reading, and through which proceeding?" is surface + scope — it changes what's on screen. "What fast action do I fire?" is a verb — it opens a tool. Fold all three into one row and every control fights for the same space; the Inbox — the assigned counsel's actual daily queue of agent proposals, routed emails, and unassigned docs — gets exiled to a rail icon with a tiny badge, where it can never have the list + preview + filters it needs.

The naive fix is "add more tabs / more rail icons." That is exactly the drift this Story reverses: it is how you end up with a 10-icon rail nobody can scan and an Inbox that is structurally too small to use. The locked answer is separation by role: Ribbon = know + reach, Worknav = choose surface + scope, Action Rail = persistent tools. Each region owns one verb, so nothing duplicates and the Inbox gets the full body it always needed.

✈️ Airplane — the one enum that runs the Worknav

The Inbox is the trickiest call. It is not a Work Mode (those are facets of the matter's substance — Brief, Documents, Proof…); it is a queue of "what needs me," a different category entirely. But it also must not be a rail panel, a notification drawer, or an agent-panel subview — those are all too small and break the single-source rule. So it becomes a Triage Mode: leftmost in the Worknav, behind a divider, carrying the pending count badge — modeled as one more value in a single active-mode enum.

WorknavMode = "inbox" | "brief" | "strategy" | "record"
            | "chronology" | "proof" | "filings" | "hearings"

Option-B layers (visible separators between each):
  Inbox ┃ Brief·Strategy ┃ Record·Chronology·Proof ┃ Filings·Hearings
  Triage ┃   Think        ┃      Evidence            ┃     Act

The one analogy that holds all the way down: the Proceeding Lens is a camera, and each mode tells it how to behave. On Triage (Inbox) the camera is off — the view is always matter-wide, so the lens chip is hidden (a live scope chip that does nothing is a lie); per-item proceeding chips carry scope instead. On Switch modes (Brief / Strategy) the camera swaps lenses — you get the proceeding-specific brief, a distinct artifact, not a filtered one. On Narrow modes (Documents…Hearings) the camera zooms — same body, filtered to the scoped proceeding, with a crimson scope strip and a one-click reset.

🔬 Microscope — the seams that make it real

Region per file (storyable in isolation)

The header splits into matter-ribbon.tsx (row 1) and matter-worknav.tsx (row 2), composed by matter-detail-header.tsx. WHY split: each navigation is a region with its own locked lexicon and its own states, so each gets its own Storybook file and stays small — the header is now a thin sticky wrapper, not a 150-line do-everything client.

The Worknav enum + lens taxonomy (presentation, not the client)

presentation.ts exposes WORKNAV_MODES (the ordered list, each tagged triage or work, divider after Inbox) and LENS_TYPE (the triage/switch/narrow map). WHY in presentation: AGENTS.md keeps mode order, class tags, and lens behavior out of the client file — the Worknav just renders the map and decides "is the lens hidden?" from LENS_TYPE[activeMode] === "triage".

The lens chip's three scope treatments

When shown (Switch + Narrow), the lens chip renders one of three token-backed treatments: main (default Main-arbitration scope, plain), scoped (a named proceeding — crimson border-left + crimson dot), wide (explicit Matter-wide aggregate — dashed). WHY crimson only for scoped: crimson is a status hue (design system), so it marks the one state that narrows what counsel sees — a proceeding filter is active and must be visible at a glance.

The Action Rail drops to four

RailIconId collapses from ten ids to intake | notes | audit | settings — Inbox left for the Worknav, and the redundant mark-filed / log-call / mira / marginalia / parties verbs go with it. Intake is the polymorphic Add (the +); admin is renamed settings and still opens the Matter administration panel. WHY four: the rail owns only always-available matter tools; mode-local actions (Inbox triage chips, Proof open-links) live inside the active work surface, not the rail.

Record ≠ documents — rename the container, not the contents

The document Work Mode becomes Record (tab label) and the page is the Evidentiary Record (heading / empty state). The route moves /matters/[id]/documents → /matters/[id]/record (old path deleted, no back-compat redirect — proxy.ts localizes bare paths and there are no external links). The Worknav Record mode navigates there; internal links (revalidate, business-action route template, page-help map, gateway route tags, the legacy sub-nav) all repoint. WHY only the container: the items inside the Record are documents — so the documents DB table, the document_type catalog, the register's "Document Type" column, and every backend /app/.../documents path and S3 key stay exactly as they are. Record is the shelf; documents are the books.

What shipped

Verify: pnpm lint (0 errors), tsc --noEmit ✓, pnpm test (matter-detail suites pass), pnpm storybook:check ✓ (drift + build), i18n en/hi parity ✓, color-literal scan clean.

Files changed

27 file(s), +629 / -276 lines