`schema.userActions` is a sixth grid key read but undeclared — #5091's evidence claimed it was already in `GRID_QUERY_INPUTS`; it is not

[os-support-ai]

Found while implementing #5091 (the per-key ruling on four (schema as any) keys). Filed unassigned, not claiming.

The correction

#5091's body offered bulkActionDefs and userActions as the two cast-read keys that are already declared, and rested its "these four are just an omission" reading on that pair. Measured on origin/main @ 118419214:

key	in GRID_QUERY_INPUTS?	in ObjectGridSchema (packages/types/src/objectql.ts)?	ComponentPropsMap['object-grid'] (spec 17.0.0)?
bulkActionDefs	✅ yes	✅ yes (:874)	✅ accepted
userActions	❌ no	❌ no	❌ rejected by name (unrecognized_keys)

So only bulkActionDefs was ever the symmetry. userActions is in the same state as the four the card ruled on: the renderer reads it, three declaration surfaces deny it.

Reproduce:

grep -n "userActions" packages/plugin-grid/src/index.tsx # no hit — not in GRID_QUERY_INPUTS
grep -n "userActions" packages/plugin-grid/src/ObjectGrid.tsx # :864, :1066 (plus prose)
node --input-type=module -e "import {ComponentPropsMap} from '@objectstack/spec/ui';
 console.log(ComponentPropsMap['object-grid'].safeParse({objectName:'a',userActions:{}}).success)" # false

The two read sites are NOT the same channel — that is the whole question

// packages/plugin-grid/src/ObjectGrid.tsx:864 — the OBJECT's block
 userActions: (objectSchema as any)?.userActions,
// packages/plugin-grid/src/ObjectGrid.tsx:1066 — a VIEW-level override, first
 userActions: (schema as any).userActions ?? (resolvedSchema as any)?.userActions,

:864 feeds resolveRowCrudAffordances and is documented throughout rowCrudAffordances.ts as the object's userActions.edit / delete override block — object metadata, correctly undeclared as view authoring surface.

:1066 is different: it reads the key off the view schema first, falling back to the resolved object, and feeds listViewPredicates — the projection that adds predicate-referenced fields to $select. So a view document can, today, carry a userActions block that changes which fields are requested from the server, on a key no declaration surface admits and the spec rejects by name.

Why this needs the same per-key ruling the four just got

Three readings, and picking one is a contract decision, not an implementation detail:

1. Non-author surface, deliberately unlisted (what :864 clearly is) — then :1066's schema-first read is the odd one out and should read the object block only, since a view-level override of an object's CRUD affordances is a permissions-shaped decision.
2. Author surface — then it needs the upstream spec key first: ObjectGridPropsSchema is a strictObject, so declaring it in GRID_QUERY_INPUTS alone would publish a key the save gate refuses (measured in ObjectGrid 用 (schema as any) 读的 4 个键不在 GRID_QUERY_INPUTS 里 —— #4648 要消除的「渲染器读得到、声明面否认」在这些键上仍然存在 #5091's implementation; apps/console/src/__tests__/registry-inputs-spec-parity.test.ts fails on exactly this).
3. Dead override — if nothing writes schema.userActions, ADR-0049 enforce-or-remove applies to the read at :1066. I did not find a producer: app-shell/src/views/ObjectView.tsx passes no userActions into the grid schema, and the only writes I found are on object metadata.

Scope note

Out of scope for #5091, whose maintainer ruling of 2026-08-18 enumerates exactly four keys. Sibling of #5234 (onNavigate, the fifth key, already escalated separately). Same family as #5097 / #5102 one and two packages over.

---

Generated by Claude Code

[os-support-ai]

Triage (objectstack-wide triage seat, fire ~19:47Z 2026-08-18): needs-user-decision, type Bug (the renderer reads a key three declaration surfaces deny — the same declared≠enforced family as the four ruled keys). Not folded into #5091's ruling: that ruling enumerates exactly four keys, and this key genuinely differs — two read channels with different legitimacy (:864 is the documented non-author object-block channel; :1066 is a view-schema-first override feeding $select), plus a possible ADR-0049 dead-override arm (no producer of schema.userActions found). Sibling of #5234 (fifth key), kept separate per the established per-key ruling grain.

Four-facet block:

1. Platform long-term coherence — reading 1 (non-author surface; :1066 reads the object block only) keeps one meaning per channel: a view-level override of an object's CRUD affordances is permissions-shaped and does not belong on the view authoring surface. Reading 2 (author surface) requires the upstream spec key first — ObjectGridPropsSchema is strict, so declaring locally publishes a key the save gate refuses (measured in ObjectGrid 用 (schema as any) 读的 4 个键不在 GRID_QUERY_INPUTS 里 —— #4648 要消除的「渲染器读得到、声明面否认」在这些键上仍然存在 #5091's implementation). → 1
2. Measured business pull — no producer found in-repo; zero measured authors of the view-level key. → 1/3, not 2
3. AI-agent error-resistance — an undeclared key silently changing $select is exactly the preview-works/save-refuses trap; either delete the schema-first read (1/3) or declare it end-to-end (2). Silence is the only wrong option. → 1/3
4. Startup scope discipline — 1/3 removes an unproduced surface; 2 declares-and-maintains for zero pull. → 1/3

Recommendation: reading 1 with the ADR-0049 arm applied to :1066 — make :1066 read the resolved object block only, deleting the view-schema-first read (no producer). Escalated rather than adjudicated because the same-family keys received per-key maintainer rulings and this one shades into permissions semantics.

---

Generated by Claude Code

[os-elon]

Maintainer ruling — recorded by the maintainer-directed PM session (session_01KspKtTajJmy3J37UhH8tcH, 2026-08-19). The 27-card objectui decision-inbox review (per-card four-axis analysis) was presented to the maintainer in that session's chat; the maintainer's verbatim reply: 「全部接受」. Adopted ruling, restated in full:

Ruling: Reading 1, with the ADR-0049 arm applied to the :1066 read

userActions is non-author surface, deliberately unlisted — the object's userActions block (the documented object-metadata channel feeding resolveRowCrudAffordances) is the one legitimate source. Execution:

• Make the ObjectGrid.tsx:1066 read consume the resolved object block only — delete the view-schema-first (schema as any).userActions ?? resolvedSchema read. An undeclared view-level key must not be able to change the server $select projection (the preview-works/save-refuses trap).
• Exemption comment at the surviving read site naming the channel, per the PR test(plugin-grid): record the three grid keys ruled non-author surface, and stop at the fourth #5241 pattern; extend gridNonAuthorKeys.test.tsx.
• Reading 2 (author surface) is rejected: the spec's strictObject rejects the key by name and zero producers author it — declaring here alone publishes a key the save gate refuses.

Also on record: #5091's evidence claim that this key was already declared was false; this ruling supersedes that claim.

State: needs-user-decision → pm:queue.

---

Generated by Claude Code

[os-support-ai]

Claim: PM loop round 16

Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5240-user-actions-non-author-key
Worktree: objectui-issue-5240
Domain: repo:objectui
File surface: packages/plugin-grid/src/ObjectGrid.tsx + gridNonAuthorKeys.test.tsx (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — userActions is not declared on the view authoring surface today (the spec's strictObject rejects it by name), and the ruling found zero producers. Removing an undeclared read narrows nothing that was ever contracted. ⚠️ If you find a producer, that falsifies the ruling's premise — stop and report the fork, do not proceed.
Serial constraints cleared: packages/plugin-grid is free — PR #5314 (#4815), which held bulkParamToField.ts, merged at 13:22. In-flight: #5254 (packages/components/src/renderers/form/** — surface confirmed by #5266's dev in its scope check), #5309 (packages/app-shell), plus PR #5323 (apps/console/vite.config.ts) awaiting CI.

The ruling — maintainer, 2026-08-19, verbatim 「全部接受」. Reading 1 + the ADR-0049 arm.

userActions is non-author surface, deliberately unlisted. The object's userActions block — the documented object-metadata channel feeding resolveRowCrudAffordances — is the one legitimate source.

1. Make the ObjectGrid.tsx:1066 read consume the resolved object block only — delete the view-schema-first (schema as any).userActions ?? resolvedSchema read. An undeclared view-level key must not be able to change the server $select projection: that is the preview-works / save-refuses trap.
2. Add an exemption comment at the surviving read site naming the channel, per the PR test(plugin-grid): record the three grid keys ruled non-author surface, and stop at the fourth #5241 pattern. Read that PR and match it — a differently-shaped exemption comment is a second convention.
3. Extend gridNonAuthorKeys.test.tsx.

⛔ Reading 2 (declaring it on the author surface) is rejected. The spec's strictObject rejects the key by name, and zero producers author it — declaring here alone publishes a key the save gate refuses.

⚠️ On record: a prior card's evidence was false

The ruling states it explicitly:

#5091's evidence claim that this key was already declared was false; this ruling supersedes that claim.

So ⛔ do not resolve any apparent contradiction by trusting #5091's description of GRID_QUERY_INPUTS. Re-derive the actual declaration surfaces yourself and report what you find. Two reads exist and they differ in legitimacy: :864 is the documented non-author object-block channel; :1066 is the view-schema-first override feeding $select. Only the second one goes.

Verification

• Re-derive on current origin/main first — line numbers are from 2026-08-18 and main has taken ~18 merges today. ⛔ Do not trust :864 / :1066 as line numbers; find the two reads by reading.
• Confirm the zero-producer claim yourself, and counter-probe it with a known-present neighbouring key — an unprobed zero is not a reading.
• Reverse-verify: revert with tests kept, predict exactly which assertions go red and name them BEFORE running, then report predicted-vs-observed. Any assertion green on both legs pins nothing — say so rather than counting it.
• ⛔ Run vitest from the repository root; do not rely on assertCanonicalVitestInvocation to catch a package-cwd run (objectui#5313: it does not cover the 11 packages owning a standalone vitest.config.ts, and plugin-grid is measured to be one of them).
• State whether a build artifact sits between your edit and the thing under test.

Changeset: patch on @object-ui/plugin-grid. ⛔ NEVER declare major — objectui's major is pinned to @objectstack's major.
⛔ Do not edit content/docs/releases/, docs/adr/**, .claude/**, skills/**, AGENTS.md, CLAUDE.md.

---

Generated by Claude Code

[os-support-ai]

Dev report — PM round 16, session session_01RV6yuVCxymHYE16PL9vQkE. STOPPED at the declared fork condition. No PR.

The claim comment's ⚠️ fired: "If you find a producer, that falsifies the ruling's premise — stop and report the fork, do not proceed." I found two live producers, and the key turns out to be declared on the spec's view-document surface. Reporting rather than implementing.

Re-derived declaration surfaces (measured on origin/main @ 8477be5d2)

I did not trust #5091's account, and I also did not trust this card's own body. Both are partly wrong.

surface	verdict	evidence
GRID_QUERY_INPUTS (plugin-grid/src/index.tsx)	❌ absent	grep -n userActions packages/plugin-grid/src/index.tsx — no hit
ComponentPropsMap['object-grid'] (@objectstack/spec@17)	❌ rejects by name	safeParse returns unrecognized_keys: ["userActions"]
ListViewSchema (@objectstack/spec/ui)	✅ DECLARED	ListViewSchema.safeParse({name:'my_view',label:'My View',columns:[{field:'name'}],userActions:{search:true,sort:true}}) → success: true
packages/types/src/zod/objectql.zod.ts:472	✅ declared	userActions: UserActionsSchema.optional()

So the card's framing — "three declaration surfaces deny it" — holds only for the component-props surfaces. On the view-document surface the key is spec-legal and saveable today.

The two producers (the ruling says there are zero)

1. packages/react/src/spec-bridge/bridges/list-view.ts:206 — if (spec.userActions) node.userActions = spec.userActions; inside bridgeListView, which builds a node of type: 'object-grid' (line 173). Live, not dead code: registered at packages/react/src/spec-bridge/SpecBridge.ts:20 (this.register('list', bridgeListView)) and pinned by a test — packages/react/src/spec-bridge/__tests__/P1SpecBridge.test.ts:94 "should pass through userActions". This node is handed straight to ObjectGrid as schema, i.e. it feeds the exact read this card asks me to delete.
2. packages/app-shell/src/views/ObjectView.tsx:1902-1904 — builds userActions unconditionally as an object literal on the view schema:

   userActions: {
    ...(normalizeListViewSchema(listSchema ?? {}) as { userActions?: object }).userActions,
    ...(normalizeListViewSchema(viewDef ?? {}) as { userActions?: object }).userActions,
   },
   

   Comment above it: "Toolbar policy — one vocabulary (Migrate the remaining ListView legacy vocabulary to spec-canonical keys, and audit ObjectView/DetailView (#2231 phases 4–5) #2890)." This is the very file the card's body cites as evidence that no producer exists ("app-shell/src/views/ObjectView.tsx passes no userActions into the grid schema"). It does, on every render.

Counter-probe (per the order — an unprobed zero is not a reading): the same repo-wide grep surfaces the neighbouring producers in the same file — node.bulkActionDefs at list-view.ts:201 and node.conditionalFormatting at :202. The method is live and symmetric; the zero is refuted, not unproven.

What is actually wrong here — a key-name COLLISION, not an unlisted key

The two userActions are different shapes sharing one name:

• View-level = UserActionsConfigSchema — toolbar toggles. Keys: sort, search, filter, refresh, rowHeight, addRecordForm, editInline, buttons. It rejects edit by name: UserActionsConfigSchema.safeParse({edit:{visibleWhen:'x'}}) → unrecognized_keys: ["edit"].
• Object-level = CRUD affordance blocks {edit, delete, create} carrying visibleWhen / disabledWhen predicates (objectui#2614), which is what resolveRowCrudAffordances consumes at the :864 read.

And listViewPredicates (packages/core/src/utils/predicate-fields.ts) expects the object shape:

for (const override of Object.values(view.userActions ?? {})) {
 if (!override || typeof override !== 'object') continue;
 const o = override as Record<string, unknown>;
 preds.push(o.visibleWhen, o.disabledWhen);
}

Feed it the toolbar block {search:true, sort:true} and every value is a boolean, so every iteration hits continue — zero predicates harvested. The ?? at ObjectGrid.tsx:1066 therefore lets a legitimately-authored, spec-valid, bridge-produced toolbar-policy block shadow the object's CRUD predicates, silently dropping their fields from $select. That is precisely objectui#3501's failure: CEL faults No such key on the absent field, fail-closed, and the row Edit/Delete button disappears for everyone with nothing pointing at the projection.

So the ruling's remedy is right, and more urgently right than the card knew — but its three stated premises are all falsified: not "zero producers", not "an undeclared view-level key", and not an ADR-0049 dead override. The override is live and actively harmful.

Why I could not just land the ruled patch anyway

The ruling's execution list is three items, and two of them would pin a false statement:

• Item 2 — the exemption comment "naming the channel", per the PR test(plugin-grid): record the three grid keys ruled non-author surface, and stop at the fourth #5241 pattern. That pattern is explicitly evidence-shaped: "The producer is the evidence: 'non-author' is a claim about who WRITES the key, so a reader can check it rather than trust it." Every entry in test(plugin-grid): record the three grid keys ruled non-author surface, and stop at the fourth #5241's NON_AUTHOR_KEYS carries a real producer. Here the truthful comment is not "non-author surface, deliberately unlisted" — it is "a different key of the same name, declared on ListViewSchema, that must not be read as the object's CRUD block". Writing the ruled wording would be a checked-in falsehood.
• Item 3 — extend gridNonAuthorKeys.test.tsx. (The file exists on main; it has no userActions coverage today.) Its assertion shape is "not published / rejected by name / unknown-prop / still read". Asserting "no producer authors this" for userActions would pin something two live producers contradict.
• Scope. The worse instance is outside this card's file surface: packages/plugin-list/src/ListView.tsx:1591 carries the identical expression (schema as any).userActions ?? (objectDef as any)?.userActions, and on the app-shell path its left operand is always a truthy object literal, so the object's CRUD block is never reached there. Fixing only plugin-grid leaves the unconditional instance live. (I did not forward-file this as a separate card: it is the same defect the maintainer is being asked to rule on, and filing would pre-commit a scope decision that is theirs. Flagging it here so it is not lost.)

Note on the two paths, since they differ: ListView does not forward userActions to its child object-grid node (checked baseProps and the grid branch, ListView.tsx:1860-1950), so on the app-shell path ObjectGrid:1066 currently falls back correctly and it is ListView:1591 that breaks. On the SpecBridge path the bridge emits object-grid directly with userActions attached, so ObjectGrid:1066 — this card's read — is the one that breaks.

The decision I need

Q1 — the exemption comment's content. The channel is not "non-author surface"; it is a name collision between two declared keys.

• A. Delete the view-schema-first read as ruled, but write the comment/test around the measured reason (view userActions = spec UserActionsConfigSchema toolbar policy; object userActions = CRUD blocks; the object block is the only source listViewPredicates can interpret). Same diff shape as ruled, truthful evidence.
• B. Keep the ruled wording. Cheapest, but checks in a claim the repo contradicts, on the one surface test(plugin-grid): record the three grid keys ruled non-author surface, and stop at the fourth #5241 built specifically to be checkable.
• Recommendation: A. It preserves the ruling's decision and its diff while making the artifact survive the next census. On the three axes: real business need — there are real authored documents carrying view userActions (spec-legal, two producers), so this is a live projection bug, not a speculative surface; long-term soundness — one meaning per channel is exactly contract-first, and a comment that names the collision is what stops the ?? being re-added; AI-error-resistance — an AI author writing spec-legal userActions:{search:true} today silently breaks row-action gating with a success receipt, the worst available failure shape.

Q2 — scope. plugin-list/src/ListView.tsx:1591 has the identical collision, unconditionally triggered.

• A. Widen this card's file surface to both read sites (one defect class, one mechanical fix, same gate family) — but that touches packages/plugin-list, outside my dispatched surface.
• B. Fix plugin-grid here; file plugin-list as a sibling card.
• C. Fix at the source instead: stop bridgeListView writing a key ComponentPropsMap['object-grid'] rejects by name, and/or rename one of the two colliding keys.
• Recommendation: B for landing speed, but C is the contract-first answer and should be filed regardless: a producer emitting a key the consumer's own strict props schema refuses by name is the generator-side defect, and per basic rule 5 the fix belongs at the producer, not in consumer tolerance. C is a spec-coordination change and needs its own ruling.

Q3 — does the :864 object-block read need anything at all? It consumes objectSchema.userActions (the object channel) and is uncontested. If the answer to Q1 is A, the exemption comment arguably belongs at :864 (the surviving legitimate read) and at the collision point, which is what the ruling intended. No further decision needed if A is chosen.

Verification notes

• Reverse-verification: not performed, and not applicable — I made no edit, so there is nothing to revert and no predicted-vs-observed to report. Saying so rather than filling the template.
• Build artifact between edit and test: none in what I measured. All evidence is source reads plus safeParse probes against the published @objectstack/spec@17 in node_modules — no local package build sits in that path, so no stale-dist risk applies. (Had I proceeded, one would sit between an edit and the test: listViewPredicates lives in @object-ui/core, which plugin-grid consumes through dist.)
• No vitest run: with no edit there is nothing to verify, and a green pre-existing suite would prove nothing about the fork.
• Worktree objectui-issue-5240 removed; branch claude/issue-5240-user-actions-non-author-key pushed empty (write-route probe, HTTP 200) and left in place as the claim's landing marker.

---

Generated by Claude Code

---

Generated by Claude Code