Story-2295: the Record register — saveable views (B, EPIC-2270)

The Record is one dataset. What changes is how counsel looks at it — and that way of looking is a thing you can name, save, and come back to. The GitHub-Projects model, worded for lawyers.

The idea in one line

A view = columns + grouping + row order + filters, saved under a name. Narrowing the register is not a mode you fall out of; it is a draft of a view, and the register offers to keep it.

The uncomfortable thing this ticket found

There were two registers, and the features this Story asked for were already built — in the wrong one.

The prototype's own header said it: "Prototype gate: mock data only … live wiring is founder-gated." It had zero importers. Its filter bar rendered its placeholder as a <span> — it could never be typed into. This is the exact failure AGENTS.md names: done at the component boundary, never at the system boundary. Fixtures lie in your favour.

Two conflicts, resolved against the live contract

Rule applied: the frame loses to the live contract.

The engine (pure, unit-tested)

lib/documents/register/filters.ts — the filter bar's algebra. One box, no query language.

• Free text matches the display name and the original filename — counsel searches for what they uploaded.
• Chips of the same kind OR; chips of different kinds AND.
• Power-user shorthand: type side:ours, get the same chip the typeahead makes.
• Suggestions only ever offer values on screen — you can never pick a filter that empties the register.

Persistence: no backend change

The saved-view contract already carried an opaque filters jsonb (it was holding the slice value and the hierarchy toggle). The filter bar's query + chips ride the same door.

viewStateToFilters(view) → { hierarchy, sliceValue?, query?, chips? }

So "a view = columns + grouping + order + filters" is true end-to-end, persisted server-side, per matter, shared with the team — and the Zustand fallback the brief allowed for was never needed. A malformed chip from an older client is dropped, not fatal: a saved view must always open.

What the default view now is

• Grouped by side, in doctrinal order — ours → opposing → court → others, not alphabetical. Counsel reads a record as a confrontation: our own case first, then what we answer, then the bench. Alphabetical opened on "court", an order nobody asked for.
• No slicer. sliceBy was tags, which pinned the slice rail open on every first paint. It is now null, so the rail appears only while slicing — as the frame says.

The surfaces

Why arrivals are a context, not the Zustand store

The Import drawer and the register are siblings under the matter shell; the drawer owns the upload queue. The in-flight items cross through a React context the shell hosts (matter-arrivals.tsx).

Deliberately not HR-23 Zustand: in-flight uploads are ephemeral and must never persist. A rehydrated "arriving" row after a reload would be a ghost document that never lands. The store is for client state worth keeping; this is client state worth forgetting.

Bundle grouping still works inside views

The Story-2281 family collapse (parent_document_id) is untouched: the bundle filter still runs before the engine, so group summaries and slice counts describe what counsel is actually looking at. The filter bar was inserted at the same point in the pipeline, for the same reason.

Verification