Story-2357: Issues for determination — the first COMPOUND row

🛰️ Satellite — why this one matters more than "one more editable list"

Issues for determination are the spine of the fight. Every filing, every hearing, every piece of evidence is ultimately aimed at one of them. Vega drafts them from the pleadings; if it mis-frames an issue, or puts the burden on the wrong side, the Brief quietly lies about who has to prove what — and counsel had no way to correct it in place. The block was read-only.

Every Brief block promoted before this one (relief, key instruments, governing law, adversary's best shots) was a list of strings. An issue is not a string. It is two facts welded together:

{ "issue": "Whether the Change-in-Law notice was served in time", "burden": "Respondent" }

So this Story is the first time a single EditableList row has to hold two kinds of the frozen vocabulary at once: an EditableField for the text and an EditableChoice for the burden. Getting that seam right is what the Story is actually about — the issues block is just its first consumer.

✈️ Airplane — the analogy: a form on a clipboard vs a line on a ledger

The tempting move is to reach for the form world: a little dialog with a text input and a radio group, an Add button, a Save. That is exactly wrong, and the frozen vocabulary (docs/design/editable-surface-vocabulary.md §1) says why:

Is counsel reading something that already exists (→ Editable Surface), or filling in something new (→ form)?

Counsel is reading the issues Vega already framed. So it is a ledger line, not a clipboard: you click the words and fix the words, you click the burden badge and flip the burden. Each act commits on its own, instantly, with rollback. There is no Save button because there is nothing to save — the record already moved.

🔬 Microscope — the seam, and why it is shaped this way

WHY the primitive stays value-agnostic: three adapters, no issue-shaped code

EditableList is now generic over its item type. It never learns what an issue is. It learns only how to read a row's text, how to write text back onto a row, and how to make a row from typed text:

itemText?:     (item: T) => string           // read the editable text
itemWithText?: (item: T, text: string) => T // write it back, keeping the rest
newItem?:      (text: string) => T          // build a row from the draft row

Omit all three and the item is its text — which is every caller that predates the seam (relief, instruments, governing law, best shots). They did not change a line. A fourth optional prop, itemMeta(item, index), renders the row's second kind beneath its text. The primitive puts it in a box; it never asks what is in the box.

WHY one onSave for both kinds

The frame edit contract is full value per field: a write sends the whole issues array, not a patch of one row. So a text edit, a burden flip, an add, and a remove are all the same act — "here is the new issues". The burden choice does not get its own write path; it maps over the array, swaps one row's burden, and hands the whole thing to the same onSave. One field, one commit seam, one rollback.

WHY the burden is a Choice and not a radio

Vocabulary §3, founder-ruled: "There is no radio kind — radios belong to the form world." A two-option in-place value is a two-option EditableChoice. It renders through the existing "BURDEN · CLAIMANT" badge, so promoting the field changed the pixels not at all — the badge that used to be a label is now a button. That is the whole point of an editable surface: it looks like the record until you touch it.

WHY a new issue defaults to CLAIMANT

An unset burden is a hole in the record, and a "choose one" prompt on every add is friction on the one act counsel does most (Minimize-user-input doctrine). The claimant proves its own case unless someone says otherwise — that is the default the law itself uses. One click flips it.

WHY an unknown burden shows a placeholder instead of being "fixed"

A frame written earlier may carry burden: "claimant" (lowercase) or something the picker does not know. We fold case-insensitively onto the two canonical wire values; anything still unmatched renders the choice's placeholder ("Set the burden"). We do not silently rewrite it to Claimant on display — a display act must never assert a fact the record does not carry.

The gate: does the write path actually accept this?

What changed

How to see it

1. pnpm storybook → MatterDetail/IssueList — every state above, no auth, no backend.
2. In the app: a matter's Brief → The dispute → Issues for determination. Click an issue to edit its words. Click its BURDEN · … badge to flip the side. "Add an issue" opens a fresh row (burden: Claimant). Clear a row's text to remove it.

One sentence to remember: the primitive learned to hold two kinds in one row by learning nothing about issues — three adapters and a slot, and the burden rides the same full-array commit as the words.