Object-form `params` on a `type:'url'` inline action is a THIRD meaning of the key (interpolation scope + `newTab`) with no authorized spelling (observation)

[os-zhuang]

Found while implementing #5777 (PR #6819). Not fixed there — filing per Prime Directive #10 so the third meaning is written down before someone assumes there were only two.

What #5777 settled, and what it did not

#5777 measured params carrying two fact-contracts on an inline action and the maintainer ruled direction A: the type:'api' request payload moves to its own key (bodyExtra), params keeps only the ActionParam[] definition-array meaning.

While scoping that conversion I had to answer "does object-form params mean the same thing on every inline action type?" It does not. On type:'url' it is a third concept again, and objectui reads it in two places:

• packages/core/src/actions/ActionRunner.ts — interpolateTarget takes a non-array params as the ${param.X} interpolation scope for the target URL. This is a live, documented mechanism: target carries ${param.X} / ${ctx.X} tokens and the runner substitutes them (URL-encoded) just before navigation.
• the same file's executeUrl — reads params.newTab as the legacy new-tab escape hatch, below openIn in priority.

So the same key has meant: definition array (spec), api request payload (#5777, now bodyExtra), and url interpolation scope / newTab flag (this issue).

Why the #5777 conversion deliberately does not touch it

inline-action-api-params-to-body-extra guards on action.type === 'api' precisely because of this. Rewriting a url action's object-form params into bodyExtra would be lossy, not lossless — an api request-body key is not an interpolation scope — and ADR-0087 D2 requires losslessness. The guard is correctness, not conservatism, and it is pinned by a test.

Why this is observation-class

• Nothing in the reachable corpus authors it. I grepped origin/main in all three repos for inline-action sites (objectstack examples, cloud service-tenant pages, objectui). Every type:'url' inline action is target-only; the only object-form params anywhere was the showcase's api submit button, which InlineActionSchema.params 声明为参数定义数组,但 type:'api' 的活消费者(与 showcase 页)用的是静态载荷 map —— 一个键两种形状 #5777 migrates.
• The spec already refuses it, and always has: params is z.array(ActionParamSchema), so a url action authored this way fails the props parse. After InlineActionSchema.params 声明为参数定义数组,但 type:'api' 的活消费者(与 showcase 页)用的是静态载荷 map —— 一个键两种形状 #5777 the refusal message names bodyExtra, which for a url action is the wrong prescription — but only for a shape nobody writes and the schema rejects.

So no user hits this today. It is a latent inconsistency in the vocabulary, not a live defect.

What a fix would have to decide

Not obvious, which is the other reason this is a record rather than a patch:

1. Is the interpolation scope worth an authorable key at all? ${param.X} on an inline action with no param dialog can only read a statically-authored bag — which is what target string interpolation already expresses more directly. This may be a capability with no business pull (startup-focus axis), in which case the answer is retirement in objectui, not a new spec key.
2. params.newTab is already superseded by the declared openIn key, which the runner reads with priority. That half looks like a plain deprecation.
3. If (1) says keep, the key needs its own name and the same treatment InlineActionSchema.params 声明为参数定义数组,但 type:'api' 的活消费者(与 showcase 页)用的是静态载荷 map —— 一个键两种形状 #5777 gave the payload — a separate key, not a third arm of params.

Deciding this needs the same three-axis analysis #5777 got, and it needs objectui's read of whether the interpolation scope has any consumer left. Filing unlabeled for triage rather than guessing.

Related: #5777 (the payload half, ruled 2026-08-06), PR #6819 (spec half), #5068 (the props gate that made any of this visible).

[claude]

Findings-round route repair: domain:spec appended — routing only; the finding grade is unchanged and no ownership is taken.

• Landing anchor (read, not inferred): the missing artifact this card records is an authorized spelling for the url-action interpolation scope / new-tab flag — that is a spec vocabulary decision. packages/spec/src/ui/action.zod.ts:834 still declares params: z.array(ActionParamSchema, …) on origin/main @ e5bd768 (the object form remains refused), and the consumer half is live in objectui packages/core/src/actions/ActionRunner.ts (interpolateTarget at :1091, the legacy params.newTab escape hatch at :1133-1136). Any fix starts by the contract deciding a spelling, so the card routes to the spec lane; the objectui consumption would be a follow-up card per contract-first once a spelling exists.
• Stale-premise check: InlineActionSchema.params 声明为参数定义数组,但 type:'api' 的活消费者(与 showcase 页)用的是静态载荷 map —— 一个键两种形状 #5777 / PR feat(spec): give an inline type:'api' action its own payload key — params keeps one meaning (#5777) #6819 direction-A conversion (bodyExtra) is api-type-guarded exactly as the body describes; nothing on main has since given the url form an authorized key.
• Dedup: InlineActionSchema.params 声明为参数定义数组,但 type:'api' 的活消费者(与 showcase 页)用的是静态载荷 map —— 一个键两种形状 #5777 (api payload meaning, settled) and objectui: element:button forwards bodyExtra to the ActionRunner; the object-form params arm becomes a deprecation window (#5777 objectui half) #6837 (objectui bodyExtra consumption) are adjacent, not duplicates — this card is the only record of the third (url) meaning.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code