plugin-list `ListView.tsx:1591` carries the same view/object `userActions` collision as #5240 — and here the object's CRUD block is never reached at all

[os-support-ai]

Filed unassigned by the repo:objectui execution seat, as directed by the maintainer's 2026-08-20 ruling on #5240 (Q2 = B), verbatim: 「4 张 同意」. The ruling's words: "the identical (worse) plugin-list/src/ListView.tsx:1591 instance is filed as a sibling card by the repo:objectui seat per its holding note."

⛔ Deliberately not filed earlier. Both the dev and the PM held it while Q2 was open, because filing it would have pre-committed the scope decision (widen #5240 to both read sites vs. fix plugin-grid there and file a sibling). Q2 is now ruled B, so it is filed.

The defect

packages/plugin-list/src/ListView.tsx:1591 carries the same shape #5240 removes from plugin-grid:

(schema as any).userActions ?? (objectDef as any)?.userActions

Two different contracts share the key name userActions:

level	schema	content
view	UserActionsConfigSchema	toolbar policy — sort, search, filter, refresh, rowHeight, addRecordForm, editInline, buttons. Rejects edit by name.
object	the CRUD blocks	{edit, delete, create} carrying visibleWhen / disabledWhen

listViewPredicates reads the object-level one, and its loop skips every non-object value. So a spec-valid toolbar block on the view shadows the object's CRUD predicates through the ??, and their fields are silently dropped from $select — the objectui#3501 fail-closed CEL fault, reached with a success receipt rather than an error.

Why this instance is worse than the one #5240 fixes

On the app-shell path the left operand is always a truthy object literal: packages/app-shell/src/views/ObjectView.tsx:1902-1904 builds userActions unconditionally. So ?? never falls through, and the object's CRUD block is never reached at all on that path — not "sometimes shadowed", never consumed.

(That same file is the one #5240's original card cited as evidence that no producer writes this key. It does, unconditionally. That is what fired the roll-back clause on #5240 and got the ruling's premises re-measured.)

Scope

The fix is the shape #5240 lands in plugin-grid, applied here: drop the view-schema-first read, and carry the collision comment stating the measured reason — view userActions is toolbar policy, object userActions is the CRUD-predicate block, only the object block is interpretable by listViewPredicates. ⛔ Do not write "non-author surface, deliberately unlisted" — the repository contradicts it, and Q1=A exists precisely to keep that claim out of the census artifact.

⚠️ Serial with #5240 — land that one first, or at minimum read its final diff, so both read sites end up with the same shape and the same comment rather than two spellings of one fix.

⚠️ Not the producer half. The question of bridgeListView emitting onto an object-grid node a key that ComponentPropsMap['object-grid'] rejects by name is a spec-coordination card, routed through triage by the same ruling. ⛔ Not in scope here and it does not block this.

Reproduce

grep -n "userActions" packages/plugin-list/src/ListView.tsx | sed -n '1,20p'
sed -n '1900,1906p' packages/app-shell/src/views/ObjectView.tsx # unconditional construction

Evidence, measurements and the full ruling are on #5240 — this card does not restate them.

Related: #5240 (the ruling and the plugin-grid half), #5091 (the declared-surface ruling for the grid keys), #3501 (the fail-closed CEL fault this lands in), #5241 (the exemption-comment pattern Q1=A points at).

[os-support-ai]

Claim: PM loop round 22
Session: session_01RV6yuVCxymHYE16PL9vQkE
Branch: claude/issue-5398-listview-userActions-collision
Worktree: objectui-issue-5398
Domain: repo:objectui
File surface: packages/plugin-list/src/ListView.tsx (the :1591 read) plus the collision comment and its pin (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus
Clause-②: no — removes a read of an undeclared surface; no public surface widened
Serial constraints cleared: the blocker is discharged — #5240 landed via PR #5426 at 17:07:12Z, so its shape and comment wording now exist on main to copy. ⛔ packages/plugin-grid is done and must not be re-touched here. Disjoint from everything else in flight: #5421 (surface TBD, instructed to stop if it lands in an in-flight package), plus PRs #5429 (packages/fields) and #5430 (packages/auth) awaiting gates.

⚠️ This card exists because it was held serial rather than batched with #5240 — the whole point was that both read sites end up with one shape instead of two spellings of one fix. Read PR #5426's final diff first and copy it; ⛔ do not invent a second wording.

---

Generated by Claude Code

[os-support-ai]

os-dev-report

{
 "issue": 5398,
 "status": "done",
 "branch": "claude/issue-5398-listview-userActions-collision",
 "pr": "https://github.com/objectstack-ai/objectui/pull/5434",
 "premise_still_valid": true,
 "summary": "Mirrored PR #5426 onto the sibling read site: the $select predicate harvest in packages/plugin-list/src/ListView.tsx now reads (objectDef as any)?.userActions only, with the view-schema-first left operand gone. Both userActions read sites in that file carry the collision comment stating the MEASURED reason (view = UserActionsConfigSchema toolbar policy which rejects `edit` by name; object = the CRUD-predicate block, the only shape listViewPredicates can read) — never 'non-author surface, deliberately unlisted'. The card's app-shell claim was verified rather than inherited, and it holds in a STRONGER form than stated: ObjectView.tsx builds userActions as an object literal of two spreads onto fullSchema, which is handed straight to ListView, so the left operand is `{}` at worst — never nullish — and the object's CRUD block was never consumed at all on that path, with or without authored toolbar policy. A third producer was found inside plugin-list's own dependency reach: normalizeListViewSchema MANUFACTURES a view-level userActions from a legacy show* view, which the new pin uses as its producer assertion. plugin-grid and app-shell were not touched.",
 "tests": "All at final commit 392c6e452 (tree byte-identical: `git status` clean, `git diff HEAD` empty). NO build artifact sits between edit and test in any vitest leg — vitest.config.mts aliases every @object-ui/* specifier to that package's src/, and the worktree had NO dist/ at all while every suite and both ablation legs ran (packages/core/dist, packages/react/dist, packages/plugin-list/dist all verified absent); @objectstack/spec is the published 17.0.0 from node_modules, nothing local builds it. The dependency closure was built only AFTERWARDS, because tsc --noEmit needs the .d.ts files. Runs (all from repo root, all under flock /tmp/os-heavy-verify.lock): `pnpm exec vitest run packages/plugin-list/ packages/app-shell/src/views/ObjectView --maxWorkers=2` -> 'Test Files 55 passed (55) / Tests 780 passed (780)'; new pin file alone -> 'Tests 12 passed (12)'; `pnpm --filter @object-ui/plugin-list type-check` -> exit 0, output echoed the real script name 'tsc --noEmit && tsc -p tsconfig.test.json' (not a zero-match filter, and tsconfig.test.json covers the new test file); `pnpm --filter @object-ui/plugin-list lint` -> '388 problems (0 errors, 388 warnings)', pre-existing. Gates: check:control-bytes OK (4492 files), check:spec-symbols OK, check:phantom-deps OK, check:self-import OK, check:lint-coverage OK, type-check:coverage OK, check:esm-specifiers OK, check-changeset-presence.mjs OK (merge-base 02f48b662, 3 files changed, 1 changeset), check-changeset-no-major.mjs OK, check-changeset-fixed.mjs OK; plus a manual control-byte scan of each changed file (clean). REVERSE-VERIFICATION, two legs, predicted before running, fix committed first, each leg restored with `git checkout HEAD -- ...` and the restore proven byte-identical via an empty `git diff HEAD` before the green run. Leg 1 (restore the view-first `??`): predicted TWO red rather than the grid's one — the toolbar-block case AND the empty-block case, because {} is truthy, while the no-view-key case stays green since `??` legitimately falls through; observed 'Tests 2 failed | 10 passed', exactly those two. MATCHES. Leg 2 (delete the userActions line from the harvest entirely, the 'tidy finish' mutation): predicted three red, every projection case loses `status`; observed 'Tests 3 failed | 9 passed'. MATCHES. Leg 2 is what shows the first projection case pins something — it is green on both legs of leg 1, so alone it pins only that the read still exists. No rebuild was required between legs because nothing is built into the path under test (src alias, no dist/); the restore leg was re-measured, not assumed, as part of the 780-test run.",
 "open_questions": [],
 "out_of_scope_findings": [
 "filed as #5435 (unassigned, no labels): normalizeListViewSchema's SHOW_FLAG_TO_USER_ACTION folds legacy showGroup/showHideFields/showColor into userActions.group/hideFields/rowColor — three keys UserActionsConfigSchema does not declare, so ListViewSchema.safeParse refuses each BY NAME (unrecognized_keys, exactly 1 issue per fixture, with userActions.sort as the passing control). The fold therefore emits a view document its own save gate rejects, and three toolbar affordances ListView honours have no spec-legal spelling. Coordination call (spec gains the keys vs ADR-0049 enforce-or-remove), so left for PM triage."
 ]
}

---

Generated by Claude Code