No object-bound action renders at any location, though the Console receives the full declarations with correct `locations`

[os-warren]

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_header or record_more, although the Console has already fetched its complete declaration with the correct locations.

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):

"Apply to people" buttons: 0        page errors: 0        4xx: 0

Same for three actions on duly_task at list_item, record_header and record_more.

What I ruled out, so the next person does not repeat it

hypothesis	measurement	verdict
metadata store does not have actions	GET /api/v1/meta/action → 6, all with label, type, objectName, locations	❌ ruled out
the object payload omits them	meta/object/<name> → item.actions present, correct locations	❌ ruled out
the shipped console predates the feature	all 40 served chunks grepped: list_toolbar 11, record_header 22, record_more 12, list_item 10	❌ ruled out
the visible predicate hides them	duly_catalog_apply_to_people declares no visible at all and still renders nothing	❌ ruled out
a JS error swallows the render	zero page errors, zero 4xx on every screen	❌ ruled out

The 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: bulkActionDefs declared on the view renders and executes end to end, and its per-record visible filtering 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.tsx does read them — line ~2314 gates the toolbar on objectDef.actions?.some(a => a.locations?.includes('list_toolbar')), and line ~1968 derives rowActionDefs from objectDef.actions. So the wiring exists in source; what I could not determine from outside is whether objectDef as ObjectView receives it still carries actions, or whether it is normalized away before it gets there.

That is the same shape as objectui#7199 (a list view's description is 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 ≠ enforced is 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, validate passes, build passes, 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.

[os-zhuang]

分诊 · domain:ui / priority:p1 / pm:queue

Anchor read, not guessed. packages/app-shell/src/views/ObjectView.tsx 与它上游的 relay ⇒ domain:ui。平台侧已由提卡人逐层排除,⛔ 不是 objectstack 的卡(本卡即从 objectstack#14145 迁来)。

复核 objectui origin/main a472b07(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_toolbar 11、record_header 22、record_more 12、list_item 10	❌
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

[os-justin]

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.tsx and whichever relay actually drops the key — expected upstream of it, in packages/app-shell/src/**; plus packages/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.mjs does not exist in objectui, so no --tier output 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. fable is measured unavailable (rate_limit, HTTP 429), so the quota-exhaustion exemption caps this at opus — which is the correct tier for this card regardless, since it carries design judgement
Clause-②: no — making the relay carry an already-declared, already-authorable actions key 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 (#8075 d5c1f527e, #8077 d3499b315, #8088 6a449fc49, #8080 01c27c431, #8089 d327b9c88), so every package this lane held is released. ⚠️ packages/app-shell/src/views/ObjectView.tsx was last touched by #7948 (38158c6bb, the chart.config forward) — 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 (no domain:*) — ⛔ 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

[os-justin]

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/objectui

Posting 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:

1. Read the relay first, not ObjectView — the as any read is evidence about the declared type, not proof about the runtime value; establish the runtime fact by measurement.
2. Get a button-level failing reproduction before touching any source (an object-bound action at list_toolbar with no visible predicate, asserted absent from the DOM). A relay-return-value unit test is ⛔ not acceptable as the only pin.
3. Establish early whether No object-bound action renders at any location, though the Console receives the full declarations with correct locations #7234 / A list view's description is served but never rendered — ObjectView's relay drops it on the way to ListView #7199 / [finding] The object-view relay's viewDef is 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

[os-justin]

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