`normaliseOptions` 把继承来的选项重建成 `{ label, value }` —— field-backed action param 丢掉字段自己声明的 `visibleWhen` / `color`

[qq9340100]

发现于 framework#5016 的实施过程（objectstack-ai/objectstack#6235），与那单的修复无关（那单开放的是作者写在 param 上的内联选项，走的是另一条分支），按 Prime Directive #10 单独立单，未认领。

事实

packages/app-shell/src/utils/resolveActionParams.ts:228 的 normaliseOptions 把每个条目重建成 { label, value }：

return options.map((o) => {
  const raw = typeof o === 'string' ? { label: o, value: o } : o;
  const label = optionLabel ? optionLabel(objectName, fieldName, raw.value, raw.label) : raw.label;
  return { label, value: raw.value };   // 其余键在这里消失
});

它出现在 resolveActionParam 的这一行（同文件 :331）：

const resolvedOptions = param.options ?? normaliseOptions(field.options, ownerName, param.field, ctx.fieldOptionLabel);

所以只有从字段继承的列表被重建。作者显式写在 param 上的 options 走左半，逐字下沉。

后果（今天就能撞上）

一个对象字段声明了逐选项 visibleWhen（@objectstack/spec 的 SelectOptionSchema 早已声明，ADR-0058 / #2284），在对象表单里正常按谓词收窄；同一个字段被 action param 以 { field: 'xxx' } 继承后，visibleWhen 在 normaliseOptions 里被丢掉，对话框把所有选项都列出来 —— 包括那些谓词本该藏起来的。同一份字段元数据，两个 surface 两种行为，没有任何提示。

color 同理（虽然影响面小得多：对话框只建输入控件，本来也不渲染 color）。

修法方向（不要猜，值得先定一次）

normaliseOptions 真正需要做的只有两件事：把裸字符串规格化成 { label, value }，以及经 fieldOptionLabel 翻译 label。保留其余键是一行的事：

- return { label, value: raw.value };
+ return { ...raw, label, value: raw.value };

但连带要动两处类型（这是需要一并想清楚的部分，不是纯粹一行）：

• RawActionParam.options?: Array<{ label: string; value: string }>（同文件 :52）
• ActionParamDef.options?: Array<{ label: string; value: string }>（packages/core/src/actions/ActionRunner.ts:436）

两者都比它们承载的东西窄。目标词汇是 @object-ui/types 的 SelectOptionMetadata（packages/types/src/field-types.ts:289），也是 paramToField 下游控件真正读的形状 —— 收敛到它、还是只加 visibleWhen?: FieldRulePredicate，值得定一次再动。

顺带：framework 侧 objectstack-ai/objectstack#6235 落地后，ActionParamSchema.options[] 会接受 visibleWhen，所以上面两个 TS 类型也会成为「服务端接受、TS 作者写不出来」的那种不对称 —— 两件事一起修比较划算。

参考

• action param 的 options[] 该不该讲字段级的逐选项词汇(color / visibleWhen)? —— 三处形状,三种拼法 objectstack#5016（裁决与逐键 liveness 审计）、feat(spec): action param 的 options[] 声明逐选项 visibleWhen (#5016) objectstack#6235（framework 侧实施，含完整消费链证据）
• resolveCascadingOptions（packages/core/src/evaluator/optionRules.ts:101）—— 读 visibleWhen 的那一处

[claude]

Triage: pm:queue. ⛔ No domain:* — objectui is a whole-repo seat and carries no domain routing (per the seat protocol, repo:* is the routing vocabulary and domain lanes are the objectstack in-repo split).

Transfer check — this one stays in objectui

Run explicitly, because the body cross-references three framework items. The landing sites are both objectui-local:

• packages/app-shell/src/utils/resolveActionParams.ts — normaliseOptions at :228, called at :331;
• the two widened types: RawActionParam.options (same file, :52) and ActionParamDef.options (packages/core/src/actions/ActionRunner.ts:436).

Nothing lands in packages/spec, so the "shared contract surfaces have one owner" transfer does not fire, and it is not feature-level or cross-repo. It stays on the objectui queue.

Why pm:queue rather than finding

The harm is present-tense and asymmetric between two surfaces of the same field metadata: a select field with per-option visibleWhen narrows correctly in an object form, and the same field inherited by an action param renders every option in the dialog — including the ones the predicate exists to hide — with no signal anywhere. SelectOptionSchema has declared visibleWhen since ADR-0058 / #2284, and resolveCascadingOptions (packages/core/src/evaluator/optionRules.ts:101) is a live reader, so this is a consumer silently dropping a declared, honoured key — not dormant drift. The body locates it to the line and the runtime half is a one-line change (return { ...raw, label, value: raw.value }).

Not blocked on the framework side — and that is the load-bearing reading

Worth stating plainly, because the body's own framing could be read the other way: the defective path is options inherited from the field, whose SelectOptionSchema already declares visibleWhen today. It does not depend on objectstack#6235 / #5016 (which open visibleWhen on options authored inline on the param, the other branch at :331). So there is no Blocked-by: here and no reason to wait — the fix is correct and useful against today's main. The framework work only adds a second source of the same keys later.

The typing decision is shared with #3309 — decide it once

The one part that is not mechanical is which vocabulary the two widened types should speak, and objectui#3309 (pm:queue, unassigned) is the same question one interface over: BulkActionParam.options is typed closed while its runtime spreads and its destination (SelectOptionMetadata, packages/types/src/field-types.ts:289) declares color / icon / disabled / visibleWhen. #3309 already carries a triage recommendation to take the smaller route (a [key: string]: unknown catch-all matching the parent's existing idiom) rather than binding to SelectOptionMetadata.

Not a duplicate — different files, different mechanism (#3309 is type-only and states it is not a runtime bug; this one drops keys at runtime). But they should land on the same answer, and if they land in either order the second should follow the first. Cross-linked in both directions; ⛔ do not ride them in one batch if the chosen route touches SelectOptionMetadata in both.

Dedup (three repos, open issues and PRs)

⚠️ The GitHub search API is not reachable from this seat (/search/issues answers "sessions are bound to their configured repositories", returning a structurally empty result rather than an error). Dedup was done by paginating all 442 open issues and PRs across the three repos and matching locally on normaliseOptions, resolveActionParams, ActionParamDef, visibleWhen.

No duplicate. Neighbours: objectui#3309 (above), objectstack#5016 (pm:queue, domain:spec, target:v17 — the ruling on whether param options[] may speak field-level vocabulary) and its in-flight framework PR objectstack#6235. The visibleWhen keyword matches a large family in the framework repo (#6146 / #5149 / #5775 / #4953 …) — all predicate-evaluation or SDUI-declaration items, none touching this resolver.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code