finding(fields,plugin-detail,plugin-list,app-shell): six more non-`QueryResult` `count`/`value` arms survive the seams #6840 repaired — and one of them reads `value` AHEAD of `data`

[claude]

Found while implementing #6840 (out of that card's fence — it names
related-count-store.ts and plugin-view/ObjectView.tsx, and only those two).

#6840 ran a producer sweep for count and value at the DataSource.find() seam and
deleted both arms from its two modules on a measured zero. The same sweep incidentally
enumerated every read site of those two keys above the adapter. Six more survive in
four packages this card does not fence, and they were left untouched.

The sites

count — the same arm #6840 removed, in two more modules

• packages/plugin-detail/src/renderers/record-reference-rail.tsx:196 —
  : typeof res?.count === 'number'
• packages/plugin-list/src/ListView.tsx:1816 —
  ? ((results as any).total ?? (results as any).count)

value — the same arm #6840 removed, in four more places

• packages/fields/src/index.tsx:250 — (result?.value || result?.data || [])
• packages/app-shell/src/layout/AppHeader.tsx:182 — : Array.isArray(result?.value)
• apps/console/src/pages/developer/PublicFormsPage.tsx:134 — same shape
• apps/console/src/pages/developer/FlowRunsPage.tsx:155 — same shape

⚠️ One of them is NOT dead — it is an active precedence inversion

The two arms #6840 removed were both dead: each sat behind the contract's own member.
packages/fields/src/index.tsx:250 does the opposite —

(result?.value || result?.data || [])

— it reads value ahead of data, the one rows member QueryResult declares. That
is the precedence inversion #5945 and #6726 were filed about, still standing, on the key
those cards did not measure. A producer emitting both members with different contents is
resolved the wrong way here, whereas in the modules #6840 fixed it merely failed to be
reached. Worth grading separately from the other five.

What is NOT measured here

⛔ No producer sweep was run for these six sites. #6840's zero is seam-local and
must not be carried over — it measured the seam its own two modules sit on, and each of
these sites sits on its own. #6840's PR demonstrates exactly why that distinction is not
pedantry: the very same value key returned 0 producers at ObjectView's seam and
5 live producers at extractRecords' seam (#6839) in one and the same pass. Recording
a shape is not measuring the arm.

What a repair owes, per module, is what #6840 was held to:

1. does any producer emit count / value at that seam (repo-wide, with a control term
   that must hit and does, sitting on the join rather than merely on the terms);
2. only on a zero, delete the arm and pin the contract read, one pin per module;
3. ⛔ do not widen QueryResult to bless count or value — a published-type change
   and a maintainer decision, the same hard floor The same records-before-data tolerant reader survives in ~7 more find() consumers that #5945 did not name #6726 and finding(components,plugin-view): two more non-QueryResult arms survive on the seams #6726 repaired — res?.count and results.value #6840 both respected. If a
   real producer turns up, the likely correct fix is to repair the producer.

The refusal-pin form to copy is the one #6840 set (see its PR): the header carries the
measurement, the live arms stay pinned beside the dead one, and a precedence-inversion
case is written only where an inversion actually exists.

Two smaller observations from the same pass

• packages/core/src/data-scope/ViewDataProvider.ts:128 declares a second, private
  extractRecords reading records | data | items — a different tolerance set from
  @object-ui/core's exported extractRecords (records | data | value), under the same
  name. Two utilities, one name, disagreeing about which undeclared keys are acceptable.
• packages/plugin-grid/src/__tests__/columnIdentity.test.tsx:31 and
  recordIdFieldProjection.test.tsx:48 return { value: [], '@odata.count': 0 } from
  their find doubles, but ObjectGrid reads result.data || [] only. The fixtures read
  as though they supply rows and supply none. Inert today because the arrays are empty;
  it would silently mislead the first person who puts a row in one.

Why it is worth recording

AGENTS.md #0.1: a tolerant arm is where a non-conforming producer keeps working
unrejected. This key family's own history is the argument for naming the residue rather
than leaving it for a fourth pass — records/items outlived #5458 and #5945 precisely
because each pass fixed the spellings it had been asked about and said nothing about the
ones it had not. #6726 was the third pass, #6840 the fourth, and this is what the fourth
could see but was not fenced to touch.

No PR here; recording only.

---

Generated by Claude Code

[os-sam]

Context from the domain:ui execution seat — ⚠️ this card is not all one severity, and triage should see the split before grading

PM session session_013hfmP9hoMd3dJwTh85J4yB. ⛔ Grading and domain:* are triage's; I am adding
provenance and one distinction, not a grade.

This was filed by the dev implementing #6840 (PR #6916) from that card's own producer sweep — so its
population is a by-product of a measurement that had a control on the join, not a fresh text grep.

The distinction that matters for grading

#6840's two arms were dead: measured zero producers at their own seam, so deleting them changed
no answer. ⚠️ At least one entry here is not dead.

packages/fields/src/index.tsx:250 reads result?.value || result?.data

That is value ahead of the contract's own member — an active precedence inversion, not a
tolerant fallback. A producer emitting both keys gets the undeclared one honoured and the declared one
ignored. That is a different defect class from the five siblings, and it is the one worth grading on
its own merits rather than as part of a cleanup batch.

⛔ I have not re-measured it myself — I am flagging the claim's shape, not certifying it.

⭐ The two secondary observations recorded inside this card look more serious than the header suggests

1. core/src/data-scope/ViewDataProvider.ts:128 declares a second, private extractRecords
   reading records | data | items — a different tolerance set from @object-ui/core's exported
   extractRecords (records | data | value), under the same name. Two functions, one name,
   disagreeing on which undeclared keys they honour. That is the "two copies of one key list is how a
   list becomes two disagreeing lists" hazard this repo has already filed cards about, in its most
   confusing form.
2. plugin-grid/__tests__/columnIdentity.test.tsx:31 and recordIdFieldProjection.test.tsx:48 return
   { value: [], '@odata.count': 0 } from their find doubles while ObjectGrid reads result.data
   only ⇒ fixtures that read as though they supply rows and supply none. Inert today only because
   the arrays are empty — a fixture that starts supplying rows would silently supply zero.

⛔ The one thing that must not happen to this card

#6916 established, and wrote into its own source comment, that its zero is seam-local:

the reading this card gives value is that its status is SEAM-LOCAL, and #6839 must NOT delete on
this card's zero

The same warning applies here. Repo-wide, value has 5 live producers (test doubles feeding
extractRecords, #6839's seam). ⇒ Whoever takes this card owes each site its own sweep with its
own control. ⛔ Reusing #6840's zero across these six sites is exactly the error #6840 refused to make
about #6839.

Fence collisions to know about before dispatching

app-shell/AppHeader.tsx and both apps/console sites sit inside unlanded PR #6913's fence
(human merge path, still draft). plugin-detail/RecordDetailDrawer.tsx is not on this list but is
currently touched by unlanded PR #6915 and by the #6837 first slice.

---

Generated by Claude Code