Found while implementing #6726 (out of that card's scope — it names the records arm and only that arm).
The shape
#6726 removed the records arm from seven DataSource.find() consumers, after measuring that nothing produces it at that seam. Two arms reading other keys QueryResult does not declare were left standing in the same expressions, deliberately, because the card measured records and not them:
packages/components/src/hooks/related-count-store.ts — typeof res?.count === 'number' ? res.count : …, tried second, ahead of the contract's rows member. count is not a QueryResult member; the store already asks for the server count via $count: true and reads it back as total, which is one.packages/plugin-view/src/ObjectView.tsx (~:935) — else if (Array.isArray((results as any).value)) { items = (results as any).value; }, the last branch of the unwrap ladder, after data. value is not a QueryResult member either — it is the OData spelling that ObjectStackAdapter.normalizeQueryResult and ApiDataSource.normalizeQueryResult both read on the raw payload, i.e. strictly below the adapter, exactly like records.
Both are dead rather than actively wrong on today's tree (each sits behind the contract's own member), which is the same standing six of #6726's seven had.
What is NOT measured here
⛔ No producer sweep was run for count or value — #6726's sweep asked about records. Recording the shape is not the same as measuring the arm, and this card should not be actioned on #6726's numbers. What a fix owes, per module:
- does any producer emit
count / value at that seam (repo-wide, with a control term that must hit and does);
- only if none does — delete the arm and pin the contract read, one pin per module.
Note value also appears in extractRecords (packages/core/src/utils/extract-records.ts), which #6839 is about; whoever takes that card and this one should check they agree rather than landing two different answers for the same key.
Why it is worth recording
AGENTS.md #0.1: a tolerant arm is where a non-conforming producer keeps working unrejected. #6726's own history is the argument for not leaving the residue unnamed — the records/items confusion outlived two cards (#5458, #5945) precisely because each pass fixed the spellings it had been asked about and said nothing about the ones it had not.
⛔ Do not widen QueryResult to bless count or value — that is a published-type change and a maintainer decision, same hard floor as #6726.
No PR here; recording only.
Found while implementing #6726 (out of that card's scope — it names the
recordsarm and only that arm).The shape
#6726 removed the
recordsarm from sevenDataSource.find()consumers, after measuring that nothing produces it at that seam. Two arms reading other keysQueryResultdoes not declare were left standing in the same expressions, deliberately, because the card measuredrecordsand not them:packages/components/src/hooks/related-count-store.ts—typeof res?.count === 'number' ? res.count : …, tried second, ahead of the contract's rows member.countis not aQueryResultmember; the store already asks for the server count via$count: trueand reads it back astotal, which is one.packages/plugin-view/src/ObjectView.tsx(~:935) —else if (Array.isArray((results as any).value)) { items = (results as any).value; }, the last branch of the unwrap ladder, afterdata.valueis not aQueryResultmember either — it is the OData spelling thatObjectStackAdapter.normalizeQueryResultandApiDataSource.normalizeQueryResultboth read on the raw payload, i.e. strictly below the adapter, exactly likerecords.Both are dead rather than actively wrong on today's tree (each sits behind the contract's own member), which is the same standing six of #6726's seven had.
What is NOT measured here
⛔ No producer sweep was run for
countorvalue— #6726's sweep asked aboutrecords. Recording the shape is not the same as measuring the arm, and this card should not be actioned on #6726's numbers. What a fix owes, per module:count/valueat that seam (repo-wide, with a control term that must hit and does);Note
valuealso appears inextractRecords(packages/core/src/utils/extract-records.ts), which #6839 is about; whoever takes that card and this one should check they agree rather than landing two different answers for the same key.Why it is worth recording
AGENTS.md #0.1: a tolerant arm is where a non-conforming producer keeps working unrejected. #6726's own history is the argument for not leaving the residue unnamed — the
records/itemsconfusion outlived two cards (#5458, #5945) precisely because each pass fixed the spellings it had been asked about and said nothing about the ones it had not.⛔ Do not widen
QueryResultto blesscountorvalue— that is a published-type change and a maintainer decision, same hard floor as #6726.No PR here; recording only.