Screen rules written at each render site have no single place to be wrong

[bmethod]

Source: two consecutive review rounds on #32, 2026-09-10, where the fix was right and the rule it belonged to was the defect.

Reached by: add a row type to a screen that has a per-row rule. The new type will not carry the rule, and nothing will fail.

Two rules on Home were written at each render site rather than in one place, and each reached most of its sites and missed one. In both cases the miss was the row type added last:

• The selection rule. Concern and agent rows read the focus flag; change rows, added by the recap work, did not. A selected change stayed highlighted while the reader was on a meter tile and Enter acted on the tile.
• The Timeline target. A row was identified by its cursor time, and every change detected in one sample carries that sample's time — so opening the second of three simultaneous changes always landed on the first.

Both are fixed and both are now single expressions. The pattern is what remains.

This is not forgetfulness. A rule spread across call sites has no single place to be wrong, so a new site that skips it produces no failure — and the test named for the rule usually exercises whichever site was written first. The focus test used a concern row alone, which is why it passed throughout.

The design pass (#38) adds row types to Home. The next one to arrive will meet the same shape.

Done when

• The screens under src/ui/ are swept for per-site rules of this shape — a predicate or an identity computed at each render site rather than once — and each is reduced to one expression the sites read.
• Each rule found has one test that walks every row type the screen draws, asserting up front that the fixture really carries them all, so it cannot quietly narrow when a fixture changes.

Context

• Location: src/ui/home.tsx, src/ui/timeline-screen.tsx, src/ui/agents.tsx, src/ui/storage-screen.tsx.
• The two instances that prompted this are fixed in the UI: act, recap, trend, settings editors and shape after the redesign #24 phase 2 work; this is the sweep for the rest.
• Related: The test suite prints render warnings and fails on none of them #37, render warnings the suite prints and fails on none of — the same shape in a different tool, where a signal exists and nothing gates on it.

[linear-code]

VSY-24

[bmethod]

A third and fourth instance, and a sharper statement of why tests do not catch this class.

Third: the rule "follow the chosen change by identity" reached the mouse path and not the keyboard path, so opening a row with Enter recorded no identity and a prepended event made the highlight jump while the cursor still referred to the row the reader opened. That instance appeared inside the fix for the second instance.

Fourth: a subject's raw unit was dropped on three separate paths — a duplicated subject whose first half created the watch without it, a verdict event that copied the decoded name and not the unit, and a last-resort fallback. Three sites, each individually correct, no owner of the identity.

Why the tests pass throughout, stated by the agent that hit all four:

Tests assert behaviour at a site. Nothing asserts that a rule reaches every site, so the tests pass at the sites that exist and say nothing about the one that was added.

That is the gap this issue is about. It is not that the rules are wrong or that anyone forgot — it is that a rule spread across call sites has no single place to be wrong, and no test shape currently asserts completeness rather than correctness.

Both instances are fixed, and the second was fixed by giving the identity an owner rather than by adding it in three places. That is the shape the sweep should aim for.

[bmethod]

The sweep is two cases, not one rule. Established by a fifth instance, where the fix that worked on Home and the Timeline was insufficient.

Resolve at render is sufficient where a list only grows or shrinks at one end. Home and the Timeline prepend: an arrival moves every row below it, so a stale index always names a row that is one or more places off, and resolving by identity in the frame that draws it is enough.

Resolve and record is required where a list re-orders. The Agents list sorts by priority, so an arrival can land exactly on the row number a departed lane left behind. A stale index is then indistinguishable from a live one — the list has a row there, the clamp finds it, nothing looks wrong — and only writing the resolved row back removes it.

That distinction is what the sweep has to apply per screen rather than uniformly.

Three known copies of the first form, each needing the question asked of it: storage-screen.tsx, timeline-screen.tsx, settings-screen.tsx. Whether any of their lists re-order was not answered.

One more finding for whoever does the sweep: on the Agents list the write-back effect must be declared before the effect that follows a lane opened from Home or a card. With the two reversed the suite hangs — they write different rows on every pass and never settle, so the render loops rather than merely choosing wrongly. That was tested rather than assumed, and an ordering constraint between two effects is exactly the kind of thing a sweep breaks by accident.