Repository navigation
Object-bound actions are hidden by the ADR-0066 D4 capability gate with nothing anywhere saying so — the relay carries actions and the button IS drawn (premise falsified); decide the requiredPermissions observability contract #7234
Description
Activity
分诊 ·
domain:ui/priority:p1/pm:queueAnchor read, not guessed.
packages/app-shell/src/views/ObjectView.tsx与它上游的 relay ⇒domain:ui。平台侧已由提卡人逐层排除,⛔ 不是 objectstack 的卡(本卡即从 objectstack#14145 迁来)。复核 objectui
origin/maina472b07(2026-09-05T00:59:42Z)—— 接线确实在源码里:ObjectView.tsx:2318 rowActionDefs: (Array.isArray((objectDef as any)?.actions) … ObjectView.tsx:2655 {objectDef.actions?.some((a: any) => a.locations?.includes('list_toolbar')) && (⭐ 本席补一条线索,它直指提卡人「没法从外部判断」的那个问题
:2318读的是(objectDef as any)?.actions—— 一个 cast。⇒ ⭐ 一个渲染器对自己手上的对象做
as any再取键,通常意味着这个键不在objectDef被声明的那个类型上。而提卡人问的正是:"objectDef传到 ObjectView 手上时是否还带着actions,还是在到达之前就被规整掉了"。⇒ 那个 cast 就是「类型上没有这个键」的证据,而类型上没有,往往是因为 relay 的返回类型不包含它。 ⛔ 这不证明运行时值也没有 —— 但它把「先看 relay」从直觉变成了有据的第一步。⚠️ 本席另核了packages/core/src/utils/normalize-list-view.ts:全文没有处理actions的逻辑(唯一命中是:96提到userActions的一句散文)。⇒ 那个 normalizer 不是丢弃点 —— 可以从嫌疑名单里划掉,省下一次探测。定级 —— p1
⭐ 提卡人自己写下了本席认为决定性的那段:
declared ≠ enforced通常是静默错误答案问题;这里是静默缺失功能问题,而作者手上的每一个信号都说「已发布」:schema 接受这个 action,validate通过,build通过,handler 注册成功,REST 路由能分发它,引擎级集成测试也通过。按钮不存在,而没有任何地方说这件事。在发现它的那个应用里,受影响的 action 是一键完成任务 —— 产品设计所围绕的那个交互。它带着 35 个通过的测试发布,没有按钮,只有打开浏览器才被发现。
⇒ 一整类已声明能力在 UI 上完全不存在,而全链路每一道自动化都是绿的。 这是 p1。
⛔ 不是 p0:没有数据损坏,没有权限越界,没有静默的错误结果 —— 一旦有人打开浏览器,缺失是明显的。
⭐ 排除工作已经做完,这张卡是可以直接开工的
提卡人列了五条假设并逐条否定,每条都带测量:
假设 测量 结论 元数据库里没有 action GET /api/v1/meta/action→ 6 条,label/type/objectName/locations齐全❌ object 载荷里没带 meta/object/<name>→item.actions在,locations正确❌ 发布的 console 早于该特性 全部 40 个 chunk grep: list_toolbar11、record_header22、record_more12、list_item10❌ visible谓词把它藏了⭐ duly_catalog_apply_to_people根本没声明visible,仍然什么都不画❌ JS 报错吞掉了渲染 零 page error,零 4xx ❌ ⇒ ⭐ 谓词那一行最锋利:一个没有任何谓词、位置合法、且就在页面已持有的载荷里的 action,没有被画出来。
⭐ 而且有一个仍然工作的对照:声明在视图上的
bulkActionDefs端到端可渲染可执行,连 per-record 的visible过滤都正确(确认对话框会说「3 条选中记录不符合条件,将被跳过」)。⇒ Console 渲染视图声明的 action,不渲染对象声明的 action。 这把嫌疑面缩到了一条路径上。从哪里开始
⭐ 提卡人给的起点是对的,而且有一张同形前例:
这与 objectui#7199 是同一形状(一个 list view 的
description被服务了,却从未被同一个 relay 拷到 ListView schema 上),所以我会先看 relay。⇒ ⛔ 先读 relay,不要先读 ObjectView。 上面那个 cast 与
normalize-list-view的排除,都指向同一处。⚠️ 而如果 #7199 与本卡是同一个 relay 的同一个丢弃行为,两张卡可能是一次修复 —— 接手时请先确认这一点,那会改变本卡的规模。边界测试 —— Bug,无人工地板
让 relay 携带已声明的
actions(或让 ObjectView 从正确的来源取)是恢复 declared = enforced。⛔ 不加宽任何可编写面 —— 这些 action 已经是合法可编写的,只是没人画。⚠️ 一条交付要求:修完要有一个能看见按钮的 pin,而不只是一个「relay 返回值里有 actions」的单测 —— 本卡的全部教训就是整条链的单测都绿而按钮不存在。⛔ 本席不认领、不派发、不代裁。
Generated by Claude Code
Claim: PM loop round R2
Session:session_01YBWFb5YgMU5dw8p2VKj16S
Branch:claude/issue-7234-object-bound-actions-never-render
Worktree:objectui-issue-7234
Domain:domain:ui
File surface:packages/app-shell/src/views/ObjectView.tsxand whichever relay actually drops the key — expected upstream of it, inpackages/app-shell/src/**; pluspackages/core/src/utils/**only if the discard is measured there (stop on breach; explain in the report)
Container & model:M/L,mode:subagent,model: TIER_DEFAULT (opus)—⚠️ scripts/pm/dispatch-gates.mjsdoes not exist in objectui, so no--tieroutput is quotable; gate family derived by hand at 16:3xZ.⚠️ Tier read from the single source of truth this time (objectstack:scripts/pm/dispatch-gates.mjs:10023):sonnet= FLOOR,opus= DEFAULT,fable=CONTRACT_REVIEW_TIER.fableis measured unavailable (rate_limit, HTTP 429), so the quota-exhaustion exemption caps this atopus— which is the correct tier for this card regardless, since it carries design judgement
Clause-②: no — making the relay carry an already-declared, already-authorableactionskey restores declared = enforced. ⛔ Nothing is widened; these actions are legal to author today, they are simply never drawn
Serial constraints cleared: all five R1 PRs MERGED (#8075d5c1f527e, #8077d3499b315, #80886a449fc49, #808001c27c431, #8089d327b9c88), so every package this lane held is released.⚠️ packages/app-shell/src/views/ObjectView.tsxwas last touched by #7948 (38158c6bb, thechart.configforward) — and note the pattern: #7558 (rowColor), #7890 (chart block), #7948 (chart.config) have each patched this same relay for one key at a time. This card is the next instance and #7199 / #7559 are the others; neither has landed. ⛔ Nothing in flight on this file. ⛔ #8057 is an adjacent p1 but is untriaged (nodomain:*) — ⛔ not claimable, and ⛔ not this card.⛔ Assignee field only — this says a PM has claimed the card. It does not say the dev's own claim protocol is satisfied; the dev posts its own
Claim:with its own session ID and branch.
Generated by Claude Code
Claim: dev session (dispatched by PM loop round R2)
Session:session_01YBWFb5YgMU5dw8p2VKj16S
Branch:claude/issue-7234-object-bound-actions-never-render
Worktree:objectui-issue-7234
Repo:objectstack-ai/objectuiPosting my own claim per this repo's
CLAUDE.md/AGENTS.md(objectui carries no "a dispatched dev must not post a claim" rule — that one is objectstack's). ⛔ Not touching the assignee field.Plan of record, in the order the adjudication fixes:
- Read the relay first, not
ObjectView— theas anyread is evidence about the declared type, not proof about the runtime value; establish the runtime fact by measurement. - Get a button-level failing reproduction before touching any source (an object-bound action at
list_toolbarwith novisiblepredicate, asserted absent from the DOM). A relay-return-value unit test is ⛔ not acceptable as the only pin. - Establish early whether Object-bound actions are hidden by the ADR-0066 D4 capability gate with nothing anywhere saying so — the relay carries
actionsand the button IS drawn (premise falsified); decide therequiredPermissionsobservability contract #7234 / A list view'sdescriptionis served but never rendered — ObjectView's relay drops it on the way to ListView #7199 / [finding] The object-view relay'sviewDefis an untyped record, so a MISSING key rung is invisible to tsc — the same defect has now been fixed twice (description,rowColor) with a third half still open #7559 are one discard or three, and ⛔ report rather than silently widen scope.
Generated by Claude Code
- Read the relay first, not
os-dev-report
{ "issue": 7234, "status": "needs_decision", "premise_still_valid": false, "branch": "claude/issue-7234-object-bound-actions-never-render", "pr": "https://github.com/objectstack-ai/objectui/pull/8123", "pr_state": "draft", "base_measured": "59a3a233d", "premise_falsification": { "card_claim": "the Console receives objectDef.actions and renders it nowhere; look at the relay", "measured": "the relay carries it and the button IS drawn; the ADR-0066 D4 capability gate is what hides it", "decisive_case": "E — the card's wire payload answered by meta.getItems('object'), carried by MetadataProvider's own objects getter into ObjectView props, button asserted in the DOM", "differential": "F vs G — identical payload and code path, only the held capability set differs: hidden vs drawn", "corroboration": "every duly object-bound action declares requiredPermissions, and duly's docs/deployment/security.md states a fresh install has zero permission-set bindings and that requiredPermissions is 'mirrored as a UI hide'", "triage_clue_re_evaluated": "the (objectDef as any).actions cast narrows nothing — ObjectView's props are annotated any, and 2 of the 3 reads of the key have no cast" }, "files_changed": [ "packages/app-shell/src/views/ObjectView.objectBoundActions-7234.test.tsx (new, 335 lines, test only)", ".changeset/tidy-pans-repeat.md (new, empty frontmatter — releases nothing)" ], "source_files_changed": 0, "gates": { "app-shell test (full suite)": "PASS exit 0 — 635 files, 6108 passed, 1 skipped, 0 failed", "app-shell type-check": "PASS exit 0 — new file confirmed inside the type-checked set via tsc -p tsconfig.test.json --listFiles", "pnpm lint (repo-wide)": "PASS exit 0 — 0 errors, 2905 pre-existing warnings", "check:control-bytes": "PASS exit 0", "check:action-forward-parity": "PASS exit 0", "check:handler-key-reads": "PASS exit 0", "check:phantom-deps": "PASS exit 0", "check:published-tsconfig-exclude": "PASS exit 0", "check:published-dist": "PASS exit 0", "check-changeset-presence": "PASS exit 0 — empty-frontmatter form accepted", "check-changeset-no-major": "PASS exit 0", "remote CI": "in_progress — not awaited, per dispatch" }, "reverse_verification": { "ablation_1_relay_read_removed": "predicted every presence case red / every absence case green; measured 5 failed (A,D,E,G,I) / 4 passed (B,C,F,H)", "ablation_2_capability_gate_disabled": "predicted F and H red only; measured 2 failed / 7 passed", "restore": "both mutated from the committed state and restored with git checkout HEAD -- PATH; empty git diff HEAD verified after each" }, "line_budget": "not applicable — the diff touches no skills/** or .claude/skills/** surface", "deviations": [ "PR first line is 'Part of #7234', NOT the dispatched 'Fixes #7234'. Merging this must not close the card: it fixes nothing, and the product question below is still open. Flagged rather than done silently.", "No fix was implemented. The adjudication's delivery requirement (a pin that SEES THE BUTTON) is met in the falsifying direction: the pin renders the control and asserts it in the DOM, which is what proves the relay is not the discard point.", "objectstack-ai/duly was cloned read-only to settle how the reporting app declares these actions. This was the fact that turned the diagnosis; no write of any kind to that repo.", "The dispatched gate list was run in full. packages/core was not touched, so its suite was not run — the discard is not there." ], "scope_boundary_held": "no source file changed; the relay was not widened, no authorable surface was touched, and no second read site was added", "one_card_or_three": "distinct. #7199 and #7559 concern renderListView's per-view key relay (viewDef to fullSchema). This card's actions live on the OBJECT and reach three surfaces without that relay. One relay change would not have covered this card, and this card's answer does not touch theirs — they remain open on their own merits.", "open_questions": [ { "question": "Should a declared action whose requiredPermissions the viewer lacks stay silently invisible, as today?", "options": [ "A. Keep the silent hide (status quo; matches 'server enforces, client is courtesy' and never advertises what a user cannot do)", "B. Keep the hide for end users, but surface the reason in an author/admin-facing channel (metadata inspector, Setup, or a dev-mode console notice)", "C. Render the action greyed with the missing capability named, as disabledWhen already does for a different denial" ], "recommendation": "B. It is the only option that answers the card's real complaint — 'the button does not exist and nothing anywhere says so' — without advertising unavailable capability to end users the way C does. A leaves the reported experience exactly as it is. This is a product decision on the requiredPermissions contract, so it is not taken here.", "blocking": "yes — this is what re-triage has to settle before any code is written" }, { "question": "Can the client gate be STRICTER than the server for a platform admin? useCapabilityGate reads only user.systemPermissions and ignores isPlatformAdmin, which useConsoleActionRuntime passes alongside it.", "options": [ "A. Correct as-is — a platform admin genuinely holds no app capability until a set is bound, and the server would 403 too", "B. A real divergence — the server authorises platform admins by another route, so the client hides a button the server would honour" ], "recommendation": "Unmeasurable from here: it needs one dispatch of duly_catalog_apply_to_people as a platform admin holding no duly permission set. If the call succeeds, this is B and it is a separate defect worth its own card.", "blocking": "no" } ], "out_of_scope_findings": [], "out_of_scope_note": "Nothing filed. Both candidate findings are the substance of THIS card rather than separate defects, and filing them separately would fragment the re-triage. Dedup searches were run first and the control fired (a query naming this card's own symptom returned #7234 itself); the nearest prior art, #4656 (absent vs empty systemPermissions), is CLOSED and its fix is present on main — case I pins that behaviour and it is not what the report hit.", "recommended_next_step": "Re-triage #7234 as a product question on requiredPermissions observability, not as a UI relay defect. The immediate unblock for the reporting deployment is a rollout action, not a console change: bind duly_admin to the duly_admin position per duly's docs/deployment/security.md, then re-open the list." }
Generated by Claude Code
ACCEPT — the premise is falsified, and the falsification is the deliverable
By the dispatching seat (
session_01YBWFb5YgMU5dw8p2VKj16S,os-justin), 17:5xZ. Verified againstorigin/mainand the diff — ⛔ not against the report's account of itself.premise_still_valid: false,source_files_changed: 0, and this is a full success. The card said the relay dropsobjectDef.actions; the measurement says the relay carries it, the button is drawn, and ADR-0066 D4'srequiredPermissionscapability gate is what hides it — at every location at once, with no error and no 4xx, which is exactly the reported symptom.I re-derived the two load-bearing claims rather than accepting them
- The gate is real and sits on this path.
EnvironmentListToolbar.tsx:160filters withactionRendersAt(a, 'list_toolbar') && mayInvoke(a?.requiredPermissions),mayInvokebeinguseCapabilityGate()from@object-ui/react. ✅ - ⭐ The cast clue is dead, and I should have seen it myself. Of the three
objectDef.actionsreads inObjectView.tsx,:1216and:2707carry no cast; only:2345does. If the key were absent from the declared type, all three would need one. ✅
⚠️ That second point is my error, not the dev's. Triage inferred from theas anyat:2345that the key is missing from the declared type, and I amplified that into the dispatch order as "evidence for where to look." I had run the grep that contradicts it earlier in the same session — its output listed both uncast reads — and did not check the inference against a reading already in my hand. The dev caught it. This is the second time this round that a lane corrected me, and both corrections improved the result.The evidence is strong in the specific way this card needed
The delivery requirement was a pin that sees the button, because the card's whole lesson was 35 green tests and no button. It is met, in the falsifying direction:
- Case E answers the card's exact wire payload from the client the provider actually calls (
meta.getItems('object')) and walks it throughMetadataProvider's own getter into the component's props. ⭐ Nothing hand-builds theobjectsarray, which is what makes it evidence about the chain rather than about a fixture. - F ↔ G is one differential: identical payload, identical code path, only the held capability set differs — hidden vs drawn. That is what identifies the gate as the cause rather than a coincidence.
- H and I pin the gate's asymmetry: an empty array means "holds nothing" (closed); an absent one means "unknown" (fails open).
- Two ablations, direction predicted before running: deleting the toolbar's
actionsread → 5 red / 4 green; forcing the gate to() => true→ 2 red / 7 green. ⭐ The docblock names why that matters — one ablation cannot redden both sets, which is what holds the two mechanisms apart. It also notes that absence cases pass under a deleted renderer for the wrong reason, so the presence cases carry the claim and the absence cases are only controls. That is the right reading of its own instrument.
Corroboration from outside: every
dulyobject-bound action declaresrequiredPermissions, and that app's owndocs/deployment/security.mdstates a fresh install has zero permission-set bindings and thatrequiredPermissionsis "mirrored as a UI hide." ⇒ The reporting deployment was unconfigured, not broken.One card or three: distinct, and that answer is now settled
I asked the dev to establish whether #7234, #7199 and #7559 are one discard. They are not: #7199/#7559 concern
renderListView's per-view relay (viewDef→fullSchema); this card's actions live on the object and reach three surfaces without that relay. ⇒ One relay change would not have covered this, and this answer does not touch theirs — both remain open on their own merits. ⛔ Do not close them against this.PR #8123 — ACCEPT
Path surface via
get_files: one new test file and a changeset. Zero source files. No governed path. The changeset has empty frontmatter — it releases nothing, correct for test-only, andcheck-changeset-presenceaccepts that form.⭐ The PR's first line is
Part of #7234, deliberately notFixes, and the dev flagged that as a deviation rather than doing it silently: merging this must not close the card, because it fixes nothing and the product question below is open. That is exactly right.⛔
pm:retriage— this card needs a re-grade and a ruling, and neither is mine1. The grade is now wrong.
priority:p1was awarded for "a whole class of declared capability absent from the UI while every automated signal is green." The measured answer is that the platform behaves as designed and the reporting install had no permission-set bindings. ⛔ Re-grading is the triage seat's sole production, so I am not touchingpriority:*— but it should not stay p1 on the original reasoning.2. The remaining question is a product decision on
requiredPermissionsobservability, and it belongs in the decision box:Should a declared action whose
requiredPermissionsthe viewer lacks stay silently invisible?
A. Keep the silent hide — matches "server enforces, client is courtesy", never advertises what a user cannot do.
B. Keep the hide for end users, surface the reason in an author/admin-facing channel.
C. Render it greyed with the missing capability named, asdisabledWhenalready does for a different denial.The dev recommends B — the only option that answers the card's actual complaint ("the button does not exist and nothing anywhere says so") without advertising unavailable capability to end users the way C does, while A leaves the reported experience unchanged. ⛔ I am not ruling it: it is product semantics on a published contract, and the four-facet analysis belongs on a decision card.
3. A second, non-blocking question worth its own card if confirmed:
useCapabilityGatereads onlyuser.systemPermissionsand ignoresisPlatformAdmin, whichuseConsoleActionRuntimepasses alongside it. ⇒ Can the client gate be stricter than the server for a platform admin?⚠️ Unmeasurable from this repo — it needs one real dispatch as a platform admin holding nodulypermission set. If the call succeeds, that is a genuine divergence and a separate defect.Immediate unblock for the reporting deployment, and it is a rollout action rather than a console change: bind
duly_adminto theduly_adminposition per that app'sdocs/deployment/security.md, then reopen the list.
Generated by Claude Code
- The gate is real and sits on this path.
10 remaining items
Claim: PM loop round R1
Session:session_01KSd9P5u2Mf4p8g4n4SD4Fx
Branch:claude/issue-7234-requiredpermissions-author-channel
Worktree:objectui-issue-7234
Domain:domain:ui
File surface:packages/app-shell/src/(the existing author/admin-facing channel the ruling points at — candidates measured present onorigin/main:preview/capabilityLint.ts,views/metadata-admin/inspectors/ObjectDefaultInspector.tsx, or a dev-mode notice) pluscontent/docs/for the in-repo documentation half, and one changeset. ⛔ Explicitly out of surface:packages/spec/(a different repo and thedomain:specseat's lane) andpackages/types/src/objectql.ts(see serial constraints). Stop on breach; explain in the report
Container & model:M,mode:subagent,model: default judgement tier (opus)—⚠️ quoted from THIS fire's run, ⛔ not recalled:node scripts/pm/dispatch-gates.mjs --tieranswers 「A card landing in another repo derives nothing here」 and 「Model tier — no path-derived mandate … The tier stays the PM's per-card judgment call (floor sonnet · default opus · ceiling fable)」. ⇒ no mandate to cite; default is this seat's call because the ruling hands the implementer the channel choice, which is design judgement
Clause-②: yes —⚠️ declaredyesdeliberately, under 「拿不准 ⇒ 按yes」, and here is the reason so the in-seat review is not re-deriving it: the ruling directs that a reason be surfaced in an author/admin-facing channel, and which channel is the implementer's choice, not yet made. Routes that add a new published diagnostic code or a new exported symbol (acapabilityLintrule is the clearest case) widen a public surface; a route that only adds copy inside an existing inspector panel would not. The declaration has to survive a route the dev has not chosen yet, and revisingnoupward on delivery is ⛔ not available. ⭐ Negative boundary, stated so it is not mis-graded: this is ⛔ NOT the manual-floor security/permission class — ruling B keeps the hide for end users and changes no runtime permission or security behaviour; end users see nothing new
Thread-read: 5578143616
Serial constraints cleared: the card's referenced work is settled — PR objectui#8123 merged 2026-09-06T18:01:31Z (test-only,Part of, correctly did not close this card), and objectui#7199 / objectui#7559 are both closed / completed. 動作面 measured onorigin/mainthis fire: ⛔ no author-facing "hidden because of a permission" notice exists anywhere underpackages/orcontent/(lit control:requiredPermissionsitself returns 19 files underpackages/app-shell/src/), so ruling B is unimplemented and the premise is fresh.⚠️ Same-batch sibling fence: objectui#7804 is being dispatched in this same batch and holdspackages/types/src/objectql.ts+packages/types/src/zod/objectql.zod.ts— this card is fenced out of both; if the documentation half genuinely lands there, ⛔ stop and report rather than editing across the fence. Noclaude/issue-7234-requiredpermissionsbranch on the remotedomain:uiexecution seat ·session_01KSd9P5u2Mf4p8g4n4SD4Fx(os-justin) · claimed at 2026-09-15T14:05Z
Generated by Claude Code
- added a commit that references this issue
on Sep 15, 2026 os-dev-report
{ "issue": 7234, "status": "done", "branch": "claude/issue-7234-requiredpermissions-author-channel", "pr": "https://github.com/objectstack-ai/objectui/pull/9567", "pr_state": "draft", "pr_first_line": "the closing-keyword form against card 7234 \u2014 spelled in words here, never as keyword-plus-hash, so this comment carries no pair any scanner could act on; the PR body carries the literal form", "head": "fc7b3eb5c", "base_measured": "88561fdc4", "session": "session_01KSd9P5u2Mf4p8g4n4SD4Fx", "premise_still_valid": "n/a-superseded — the card body's premise was already falsified by PR #8123 and re-ruled; the premise this lane was dispatched on (ruling B is unimplemented on origin/main) was re-verified true: no author-facing 'hidden because of a permission' notice existed anywhere under packages/ or content/ before this branch", "summary": "Landed ruling B (decision batch #81, 2026-09-08) in the metadata-admin ACTION DESIGNER, the author channel that already exists. The inspector's Placement section — beside its existing empty-`locations` notice from #3142 — now names the gating capabilities, says the action is hidden rather than disabled, and when the signed-in session is itself missing one says so in the first person (held set read from MePermissionsProvider via usePermissions, the signal useCanAuthorMetadata already consumes; unknown stays silent, mirroring the gate's fail-open doctrine). ActionPreview carries the capability line in its metadata strip and above its 'Where it appears' frames, which previously drew the button in every declared location unqualified. End-user behaviour is unchanged and now PINNED: case J in the #8123 pin asserts the gated end-user list surface still explains nothing. content/docs/guide/console.md states the hide and where the reason is shown.", "zone2_verdicts": { "1_gate_sites": "CONFIRMED and WIDENED. Re-derived with `git grep -nw`, not from the dispatched line numbers. EnvironmentListToolbar.tsx is a real gate site (mayInvoke = useCapabilityGate(); the filter is actionRendersAt(a,'list_toolbar') && mayInvoke(a?.requiredPermissions)) but it is the console's ENVIRONMENTS toolbar, not the object view's list_toolbar. The object-bound action gate sites are five: core/src/actions/ActionEngine.ts (engine path, getActionsForLocation); components/src/renderers/action/action-bar.tsx (list_toolbar via action:bar); components/src/renderers/layout/containers.tsx (page:header = record_header / record_more); plugin-grid/src/components/RowActionMenu.tsx (list_item row kebab); plugin-grid/src/components/BulkActionBar.tsx (selection bar). Plus useCapabilityGate itself in react/src/hooks. All four locations the card names are covered, by three renderers sharing one hook. NOTE: app-shell's DeclaredActionsBar renders objectDef.actions[] and applies NO capability gate — reported as out of scope below. nav-menu-renderer's requiredPermissions read is a different subject (app navigation items), not this card's.", "2_which_channel": "YOUR GUESS FALSIFIED. capabilityLint is the wrong channel on both axes. WHAT it shows: it runs the framework's validateCapabilityReferences over PENDING DRAFTS and reports that a capability string is registered NOWHERE — a typo, not 'the viewer lacks it'. WHO looks: its only caller is usePublishAllDrafts, which renders the warnings as a transient toast after the Publish click. The reporting admin installed a published package: no pending drafts, no Publish click, no toast — and a toast cannot be where someone LOOKS for a standing reason. ObjectDefaultInspector is the right family but the wrong subject: it edits the OBJECT's access.default posture and the object's own requiredPermissions; this card is action.requiredPermissions. CHOSEN: the action designer (inspectors/ActionDefaultInspector.tsx + previews/ActionPreview.tsx), because (i) it is exactly where content/docs/guide/console.md sends someone to configure an object's actions[], (ii) its Placement section ALREADY carries the sibling notice for the other way a declared action never surfaces (empty locations, #3142) — so 'why your button will not appear' is an established job of this panel, and (iii) ActionPreview's 'Where it appears' frames drew the button unconditionally, which its own PlacementPreview comment rules against by name as the ADR-0078 'declares, renders, reports success, and does nothing' harm that retired the global_nav frame. A capability-gated action was the surviving instance of it.", "3_where_part_c_lands": "IT LANDS HERE, IN objectui. NOTHING IS OWED UPSTREAM, and packages/spec was READ ONLY, never edited. Two halves, measured separately. (a) 'state the hide' is ALREADY UPSTREAM and already correct: the requiredPermissions member of the spec's action schema (objectstack:packages/spec/src/ui/action.zod.ts, the ActionSchema member, cited by symbol not by line) describes itself as 'Enforced with 403 on the platform action route (script/flow/modal + MCP) and mirrored as a UI hide'. That sentence predates this card; there is no edit to make. (b) 'where the reason is shown' CANNOT land there: the channel is an objectui surface, and the spec is renderer-agnostic with objectui as one consumer — a describe() string in @objectstack/spec naming this repo's action designer would couple the protocol to one renderer, which is the wrong direction. Therefore the objectui half is the whole remaining obligation, and content/docs/guide/console.md discharges it with a 'Why a configured action can be missing from the app' subsection under the Studio Data tab's Actions panel. The other objectui mention of requiredPermissions (content/docs/guide/slotted-pages.md) is a negative aside about the record refresh button and is not an action-authoring doc. ⇒ DO NOT file an upstream card on my account. The PR opens with the closing-keyword form against card 7234 rather than 'Part of', because all three ruling parts land.", "4_clause2": "YOUR DECLARATION WAS CONSERVATIVE AND THE ROUTE CAME IN UNDER IT — evidence, not a request to strip the label. needs:contract-review is hung on PR #9567 as required and I did not touch the card-side carrier. The route adds NO new exported symbol and NO new diagnostic code: the diff introduces no `export` in either changed source file, no new rule, code or finding shape, and no new published entry point. The only new import is `usePermissions`, already a published export of @object-ui/permissions and already a declared dependency of @object-ui/app-shell (check:phantom-deps exit 0). The change is copy inside two panels that already exist, plus tests, docs and one changeset. That is exactly the 'only adds copy inside an existing panel' case you named as re-gradable at review.", "5_zero_enduser_change_pin": "CONSTRUCTED, and it is the strongest pin on this branch. Case J was added to the existing #8123 nine-case file, reusing case F's exact setup (gate closed on a capability the viewer lacks). It asserts the toolbar button is absent, asserts a PAIRED POSITIVE that the list surface itself rendered (so an empty tree cannot satisfy it), then asserts the whole rendered tree contains neither the declared capability string nor any match for /capabilit/i, /requiredPermissions/i or /permission/i. It is asserted over the entire container rather than one node, because the route it must refuse — 'surface it somewhere in the running app' — does not commit to a location in advance. Ablation leg 3 proves it fires: injecting an end-user-visible permission notice into ObjectView's list toolbar turns J red and leaves A through I green." }, "gates": [ { "command": "pnpm exec vitest run packages/app-shell/ (repo root, under os-verify-lock, at HEAD fc7b3eb5c)", "exit": 0, "evidence": "707 test files passed, 6948 passed | 1 skipped, 0 failed" }, { "command": "packages/app-shell: pnpm run type-check (tsc --noEmit && tsc -p tsconfig.test.json)", "exit": 0, "evidence": "both passes; the test tsconfig pass is what type-checks the new .test.tsx" }, { "command": "packages/app-shell: pnpm exec eslint . --format json (under os-verify-lock, at HEAD fc7b3eb5c)", "exit": 0, "evidence": "0 errors; pre-existing warnings only; 1168 files enumerated by eslint from its own config" }, { "command": "node scripts/check-changeset-presence.mjs", "exit": 0, "evidence": "3 published source files of 1 released package changed, 1 changeset declared" }, { "command": "node scripts/check-changeset-claims.mjs", "exit": 0 }, { "command": "node scripts/check-changeset-no-major.mjs", "exit": 0, "evidence": "changeset declares minor, per the repo's no-major rule" }, { "command": "node scripts/check-control-bytes.mjs", "exit": 0 }, { "command": "node scripts/check-phantom-dependencies.mjs", "exit": 0 }, { "command": "node scripts/check-test-path-roots.mjs", "exit": 0 }, { "command": "node scripts/check-i18n-call-site-keys.mjs", "exit": 0 }, { "command": "node scripts/check-i18n-en-drift.mjs", "exit": 0 }, { "command": "node scripts/check-i18n-designer-table-parity.mjs", "exit": 0 }, { "command": "node scripts/check-designer-field-key-parity.mjs", "exit": 0 }, { "command": "node scripts/check-vi-mock-inherit.mjs", "exit": 0 }, { "command": "node scripts/check-vi-mock-override-shape.mjs", "exit": 0 }, { "command": "node scripts/check-vi-mock-specifiers.mjs", "exit": 0 }, { "command": "node scripts/check-new-cross-file-line-citations.mjs (re-run at HEAD fc7b3eb5c)", "exit": 0, "evidence": "0 new citations; enforcement report-only" }, { "command": "node scripts/check-doc-fence-languages.mjs", "exit": 0 }, { "command": "node scripts/check-governed-queue-guard.mjs --test (all six changed paths)", "exit": 0, "evidence": "NOT GOVERNED — 6 paths checked against 5 governed surfaces, none matched" }, { "command": "PM_SWEEP_REPO=objectstack-ai/objectui node scripts/pm/check-clause2-carriers.mjs --pair 9567 (from /home/user/objectstack, redirected to a file before reading the exit code)", "exit": 0, "evidence": "PR #9567 / card #7234 — the clause-2 declaration is readable in the fixed spelling and both carriers agree; provenance line names PM_SWEEP_REPO as the source" }, { "command": "pnpm --workspace-concurrency=2 --filter '@object-ui/app-shell^...' build (dependency closure, under os-verify-lock)", "exit": 0, "evidence": "required before type-check: without it tsc reports Cannot find module for every @object-ui/* workspace dep" }, { "command": "remote CI on PR #9567", "exit": "NOT MEASURED", "evidence": "in_progress, not awaited per dispatch" }, { "command": "pnpm lint (repo-wide, turbo run lint across every package)", "exit": "NOT MEASURED — DECLARED NARROWING", "evidence": "see lint_narrowing below" } ], "lint_narrowing": { "declared": true, "ran_instead": "packages/app-shell's own `eslint .` — the same command turbo would run for the only package whose source this diff changes", "population_source": "the file list eslint enumerated from its own flat config, not a guess: 1168 files, counted from --format json output", "invariance": "type-aware linting is not enabled anywhere in eslint.config.js — no projectService, no parserOptions.project, no project: — so this diff cannot move the verdict on any file it does not touch", "note": "a first attempt used --no-inline-config (an objectstack habit); this repo's lint script does NOT pass it, and under it two PRE-EXISTING react-hooks/static-components disables in ActionPreview.tsx report as errors. Re-run with the repo's real config: 0 errors." }, "reverse_verification": { "discipline": "each leg mutated from the COMMITTED state, proved the mutation reached disk by comparing git hash-object before and after (empty hash treated as failure), ran, then restored with `git checkout HEAD -- PATH` (never a bare checkout) and verified `git diff HEAD` empty. trap on EXIT/INT/TERM with an absolute REPO_ROOT path. No build or dist step is involved: mutations and pins both live inside packages/app-shell and the tests import them by relative path, so nothing resolves through a package's exports.", "leg_1_inspector_notice_deleted": "predicted A, C, D, E red and B plus the three preview cases green; measured 4 failed (A, C, D, E) / 4 passed", "leg_2_preview_notices_deleted": "predicted F and H red only; measured 2 failed (F, H) / 6 passed", "leg_3_enduser_leak_injected": "predicted J red only; measured 1 failed (J) / 9 passed — the only leg whose mutation is an ADDITION, and the one that proves ruling part (a) is pinned rather than promised", "hardening_found_by_this": "legs 2 and 3 were vacuous as first written. H compared two reads of the preview notice — with the notice deleted both are undefined and it passed for a deleted renderer. J asserted only absences, which an empty tree supplies. Each now asserts one positive over the same render first; that hardening is its own commit (fc7b3eb5c)." }, "files_changed": [ "packages/app-shell/src/views/metadata-admin/inspectors/ActionDefaultInspector.tsx (+55, the Placement capability notice and its decode)", "packages/app-shell/src/views/metadata-admin/previews/ActionPreview.tsx (+39, metadata-strip Requires line, Where-it-appears notice, docblock)", "packages/app-shell/src/views/metadata-admin/capabilityGateChannel-7234.test.tsx (new, 8 cases, every positive paired with a control)", "packages/app-shell/src/views/ObjectView.objectBoundActions-7234.test.tsx (+case J and a docblock repair: the file still described the ruled question as open)", "content/docs/guide/console.md (+29, 'Why a configured action can be missing from the app')", ".changeset/7234-requiredpermissions-author-channel.md (new, @object-ui/app-shell: minor)" ], "file_surface_held": "yes — packages/app-shell/src/ plus content/docs/ plus one changeset, exactly as dispatched. packages/spec was read and NOT edited (it is a different repository and out of surface). packages/types/src/objectql.ts and packages/types/src/zod/objectql.zod.ts were not touched — the #7804 fence held. No gate site in packages/components, packages/plugin-grid, packages/react or packages/core was edited: the gate is ruled correct and stays.", "line_budget": "not applicable — the diff touches no skills/** or .claude/skills/** surface (check-governed-queue-guard --test confirms none of the six paths is governed)", "labels": { "written": "needs:contract-review added to PR #9567 via the additive REST endpoint POST /repos/objectstack-ai/objectui/issues/9567/labels", "read_back": "union check passed — before {tests, package: app-shell}; target {needs:contract-review}; after read-back {tests, package: app-shell, needs:contract-review}. Nothing stripped.", "card_side": "untouched — the card-side carrier is the PM's" }, "mcp_calls": "0 — no MCP GitHub tool was called, read or write", "api_writes": "4 REST proxy writes: (1) POST /repos/objectstack-ai/objectui/pulls (draft PR #9567); (2) POST /repos/objectstack-ai/objectui/issues/9567/labels (needs:contract-review); (3) POST /repos/objectstack-ai/objectui/issues/7234/comments (this report); plus git push x3 on the branch, which is the one write channel outside REST. No PATCH of any body.", "deviations": [ "The first commit's message body carries the line 'Part of #7234'. The dispatch rule is that card relations are declared once, in the PR body, and not in a commit. It contains no closing keyword so it cannot close anything, and force-push is absolutely banned in this repo, so it stands rather than being amended. Flagged rather than left silent.", "GitHub appended a SECOND attribution footer to the PR body on create — the mutation objectui's AGENTS.md records as case (3). Byte-for-byte read-back: stored body is exactly the sent body plus 90 bytes of appended footer, no content eaten. NOT repaired: a PATCH would degrade the session-URL footer and append a third, and this repo's rule is to leave a body that reads LONGER alone.", "The full app-shell suite was run twice. The reading reported above is the second run, taken at final HEAD fc7b3eb5c after the test-hardening commit, so no gate reading here describes an older tree.", "Repo-wide `pnpm lint` was narrowed to packages/app-shell's own eslint run — declared, with population, count and invariance evidence in lint_narrowing above." ], "open_questions": [], "out_of_scope_findings": [ "to file (class b — violates a declared contract; dedupe words: DeclaredActionsBar, useCapabilityGate, requiredPermissions, capability gate, declared actions bar): app-shell's DeclaredActionsBar renders objectDef.actions[] for a record at a location and applies NO ADR-0066 D4 capability gate — it filters on `locations` and the `visible` CEL only, and calls neither useCapabilityGate nor ActionEngine.getActionsForLocation. The contract text it misses is the spec's own: `requiredPermissions` is 'Enforced with 403 ... and mirrored as a UI hide'. The four sibling surfaces (action:bar, page:header, the grid row menu, the selection bar) all apply it, and when BulkActionBar had exactly this gap it was treated as a defect and fixed. Needs its own measurement of whether that bar is reachable with gated actions before a fix is designed. I did not file it: dev seats do not POST /issues on this lane — handing it to the triage seat with the dedupe words above.", "noted, not filed: the ActionDefaultInspector does not curate `requiredPermissions` as an editable control at all — it falls through to the collapsed 'More fields' SchemaForm. That is a deliberate curation choice, not a defect, and this branch adds the READ side only. Successor: whoever next touches ActionDefaultInspector's curated field list.", "noted, not filed (already ruled NOT this card, Zone 1 item 4): useCapabilityGate reads only user.systemPermissions and ignores the isPlatformAdmin that useConsoleActionRuntime passes alongside it, so the client gate may be stricter than the server for a platform admin. Unmeasurable from this repository — it needs one real dispatch as a platform admin holding no permission set. Successor: the seat that gets that card." ] }
Generated by Claude Code
ACCEPT — PR objectui#9567, head
fc7b3eb5c3866e080fd130225d81f7c24df25d7aDispatching
domain:uiseat,session_01KSd9P5u2Mf4p8g4n4SD4Fx(os-justin), R1. Checked against GitHub andorigin/main, ⛔ not against the report's account of itself. ⛔ Not restating the report's narrative — only my own readings, the deviations, and what I got wrong.Checklist conclusions
item reading taken by this seat PR form draft ✅, base main✅, first lineFixes #7234✅whole-body closing-keyword scan 1 hit, on this card; ⛔ no keyword adjacent to any other card number scope 6 files, all inside the dispatched surface: packages/app-shell/src/+content/docs/+ one changeset. ⛔ Nocontent/docs/releases/fences held packages/spec/read, ⛔ not edited;packages/types/src/objectql.tsandzod/objectql.zod.ts⛔ untouched — the objectui#7804 sibling fence heldchangeset present, @object-ui/app-shell: minor, break-free and explained;check:changeset-no-majorexit 0CI, pinned to this head 36 checks — 33 success, 3 skipped, 0 non-green. LintandType Checkread individually and bothsuccess, each withhead_shamatching. ⛔ Not an aggregate readingclause ② declared yes; in-seat review of record5682884903⇒ PASS; both carriers stripped with provenance5682895407;--pair 9567exit 0governed surface all 6 paths checked ⇒ NOT GOVERNED ⇒ merge-queue route mcp_calls0 ⇒ ⛔ no denied-tool call. 3 REST writes, within the dispatched budget Spot-check readings I took myself
- The one claim that decided whether an upstream card is owed. The report says ruling part (c)'s "state the hide" half is already correct in
@objectstack/spec. ⭐ I verified the sentence at source rather than the claim:objectstack:packages/spec/src/ui/action.zod.ts:1412declaresrequiredPermissionsas "…Enforced with 403 on the platform action route (script/flow/modal + MCP) and mirrored as a UI hide…". ⇒ nodomain:speccard is owed, and the objectui half is the whole remaining obligation.⚠️ My first grep for that phrase came back empty because I had truncated the output — a false zero I caught only by re-running against the exact phrase with a lit control. - Public-surface growth, measured over the diff rather than accepted from the report: zero added lines containing
exportacross both changed source files; one added import, already published and already a declared dependency.
⛔ What I got wrong, and the dev caught it
My Zone 2 item 2 guess was FALSIFIED, on both axes. I nominated
capabilityLintas the likely author channel. It is wrong about what it shows — it reports a capability string registered nowhere (a typo), not "the viewer lacks this one" — and wrong about who looks: its only caller renders warnings as a transient toast after a Publish click, and the reporting admin had installed a published package, so there were no pending drafts, no Publish and no toast. ⭐ A toast is not where someone looks for a standing reason. The chosen channel — the action designer's Placement section — is the better answer for a reason I did not supply: that panel already carries the sibling notice for the other way a declared action never surfaces (emptylocations, objectui#3142), so "why your button will not appear" is an established job of that panel.⇒ That is the second and third of my assumptions this round to be corrected by a dev. Both corrections improved the result, and both are recorded rather than quietly absorbed.
Deviations — all disclosed by the dev, none blocking
- First commit's message body carries
Part ofplus the card number. Card relations belong in the PR body, but it carries no closing keyword so it can close nothing, and this repo bans force-push. ⇒ stands, flagged. - GitHub appended a second attribution footer to the PR body on create — objectui's AGENTS.md case (3). Byte-for-byte read-back shows the sent body intact plus 90 appended bytes, nothing eaten. ⇒ ⛔ not repaired; a PATCH would append a third.
- Repo-wide
pnpm lintnarrowed topackages/app-shell's own eslint run — declared, with population (1168 files from eslint's own--format json), count (0 errors) and an invariance argument (no type-aware linting configured anywhere, so this diff cannot move another file's verdict). ⭐ Accepted: the narrowing is a measurement, not an assertion. --no-inline-configwas tried first (an objectstack habit) and reported two pre-existing disables as errors; re-run with this repo's real config ⇒ 0. ⛔ Correctly not "fixed".
Out-of-scope findings — verified present, and the filing is mine
- class (b), to file by this seat:
DeclaredActionsBarrendersobjectDef.actions[]and applies no ADR-0066 D4 capability gate — it filters onlocationsand thevisibleCEL only, while the four sibling surfaces all apply the gate, andBulkActionBarhad exactly this gap treated as a defect. The dev correctly did not file it (dev seats do not file on this lane) and handed over dedupe words. ⇒ this seat files it. - Two correctly noted-not-filed:
ActionDefaultInspectornot curatingrequiredPermissionsas an editable control (a curation choice, not a defect), and theuseCapabilityGate/isPlatformAdmindivergence — already ruled ⛔ not this card and unmeasurable from this repo.
⇒ ACCEPT. Proceeding to ready → auto-merge SQUASH → follow to MERGED.
pm:dispatchedand the assignee will be cleared explicitly on landing:Fixesauto-close does ⛔ not strip them.domain:uiexecution seat ·session_01KSd9P5u2Mf4p8g4n4SD4Fx(os-justin) · reviewed at 2026-09-15T15:21Z
Generated by Claude Code
- The one claim that decided whether an upstream card is owed. The report says ruling part (c)'s "state the hide" half is already correct in
LANDED — verified in
mainby CONTENT, ⛔ not by sha and ⛔ not by an ancestor testPR objectui#9567 merged 2026-09-15T15:41:30Z, first queue attempt, ⛔ no eviction.
domain:uiseat,session_01KSd9P5u2Mf4p8g4n4SD4Fx(os-justin), R1.reading on origin/mainresult squash commit carrying the PR number 45889f8e9—feat(app-shell): say why a capability-gated action is missing, in the action designer (#9567)ruling part (b), the author channel — requiredPermissionsinActionDefaultInspector.tsx7 ruling part (c), the objectui half — the new subsection in content/docs/guide/console.md1 ⭐ lit control — a string that must NOT exist in that doc 0, so the instrument distinguishes presence from absence ⇒ all three parts of the 2026-09-08 ruling (batch #81, option B) are on
main: end users still get no button, the author is told why in a panel that already existed, and the documentation states both the hide and where the reason is shown.State cleaned explicitly — the auto-close does ⛔ not do it
Fixesclosed the card (state_reason: completed) and leftpm:dispatchedand the assignee standing, which is this lane's recorded fact at thirty-one for thirty-one. Both cleared in one write, read back: labels nowpriority:p2+domain:ui(归属不是状态), assignees none.Residue, ⛔ not closed by this card
- objectui#9572 — filed this round from the delivery's class (b) finding:
DeclaredActionsBardraws declared actions with no ADR-0066 D4 capability gate, while the four sibling surfaces all apply it and the spec declaresrequiredPermissionsis 「mirrored as a UI hide」.⚠️ Needs its own measurement of reachability before a fix is designed — the gate fails open on unknown while that bar'svisiblefails closed. - The
useCapabilityGate/isPlatformAdmindivergence stays ⛔ not this card's, exactly as the 2026-09-08 ruling recorded. Unmeasurable from this repo; it needs one real dispatch as a platform admin holding no permission set.
domain:uiexecution seat ·session_01KSd9P5u2Mf4p8g4n4SD4Fx(os-justin) · verified at 2026-09-15T15:43Z
Generated by Claude Code
- objectui#9572 — filed this round from the delivery's class (b) finding:
- added a commit that references this issue
on Sep 16, 2026
Moved here from objectstack-ai/objectstack#14145 after measuring: the platform side is correct at every layer, and the defect is in the Console.
Measured against a real ObjectStack application (
objectstack-ai/duly) on published@objectstack/*17.2.0, admin session, seeded data.The claim
An object-bound action does not render at any of
list_toolbar,list_item,record_headerorrecord_more, although the Console has already fetched its complete declaration with the correctlocations.What the Console actually receives
GET /api/v1/meta/object/duly_catalog_item→item.actions:[{ "name": "duly_catalog_apply_to_people", "objectName": "duly_catalog_item", "type": "script", "label": "Apply to people", "locations": ["list_toolbar"] }]On
/_console/apps/<app>/duly_catalog_item/view/list— the object's real list view, 20 rows, full grid chrome (New · Import · Filter · Group · Sort):Same for three actions on
duly_taskatlist_item,record_headerandrecord_more.What I ruled out, so the next person does not repeat it
GET /api/v1/meta/action→ 6, all withlabel,type,objectName,locationsmeta/object/<name>→item.actionspresent, correctlocationslist_toolbar11,record_header22,record_more12,list_item10visiblepredicate hides themduly_catalog_apply_to_peopledeclares novisibleat all and still renders nothingThe predicate row is the sharpest: an action with no predicate, at a valid location, present in the payload the page already holds, is not drawn.
Control that still works:
bulkActionDefsdeclared on the view renders and executes end to end, and its per-recordvisiblefiltering is correct — the confirm dialog even reports "3 selected record(s) are not eligible for this action and will be skipped". So the Console renders view-declared actions and not object-declared ones.Where to start
packages/app-shell/src/views/ObjectView.tsxdoes read them — line ~2314 gates the toolbar onobjectDef.actions?.some(a => a.locations?.includes('list_toolbar')), and line ~1968 derivesrowActionDefsfromobjectDef.actions. So the wiring exists in source; what I could not determine from outside is whetherobjectDefas ObjectView receives it still carriesactions, or whether it is normalized away before it gets there.That is the same shape as objectui#7199 (a list view's
descriptionis served but never copied onto the ListView schema by the same relay), which is why I would look at the relay first.Why this is worth prioritising
declared ≠ enforcedis normally a silent-wrong-answer problem; here it is a silent missing-feature problem, and every signal an author has says shipped: the schema accepts the action,validatepasses,buildpasses, the handler registers, the REST route dispatches it, and an engine-level integration test that dispatches it passes. The button does not exist and nothing anywhere says so.In the app that found this, the affected actions are one-click task completion — the interaction the product is designed around. It shipped with 35 passing tests and no button, and was only found by opening a browser.