[finding] The "2. Contextual Actions" fence in objectui/concept.mdx still carries two non-visibility off-spec shapes: an undeclared `type` value and `confirm` instead of `confirmText`

[os-elon]

Found while fixing #13087, which scoped itself to the visible / disabled predicate values in this same YAML fence. These two are a different defect class (an undeclared enum value, and a key refused by name), so they were left rather than folded in — but they mean the fence still does not parse after #13087's fix, and that is worth recording explicitly rather than leaving implicit.

Site: content/docs/protocol/objectui/concept.mdx, section "### 2. Contextual Actions". Re-locate by content, not by line number.

A. type: standard_edit / workflow_approve / standard_delete are not declared action types

ActionType admits six values. Measured against the built @objectstack/spec (packages/spec/dist/ui), commit d872a474e1:

ActionSchema.safeParse({ name: 'edit_record', label: 'Edit', type: 'standard_edit' })
 -> success = false
 -> { code: 'invalid_value', path: ['type'],
 message: 'Invalid option: expected one of "script"|"url"|"modal"|"flow"|"api"|"form"' }

Declared at packages/spec/src/ui/action.zod.ts:949 — type: ActionType.default('script').

These three strings exist nowhere else in the product. Two sweeps on the same commit:

git grep -rn "standard_edit\|standard_delete\|workflow_approve" -- content/docs
 -> 3 hits, all three inside this one fence

grep -rn "standard_edit" packages --include=*.ts
 -> no output (control: the same instrument returns hits for "workflow_approve"? also none;
 positive control for the instrument itself is the content/docs sweep above, which returns 3)

So this is not a renamed key with a mechanical target — there is no standard_* builtin-action vocabulary to rename onto. Deciding what these examples should say is a small documentation judgment (invent three real actions with declared type values, or restructure the example around one), which is why it is filed rather than fixed inline.

B. confirm: true is refused by name; the declared key is confirmText

Same fence, on the delete action. Measured on the same commit:

ActionSchema.safeParse({ name: 'delete_record', label: 'Delete', type: 'form', target: 'x', confirm: true })
 -> success = false
 -> { code: 'unrecognized_keys', keys: ['confirm'],
 message: 'Unrecognized key(s) on this action: `confirm`. Did you mean `confirm` -> `confirmText`? ...' }

 control, same run: the same object WITHOUT `confirm` parses -> success = true

confirmText is declared at packages/spec/src/ui/action.zod.ts and documented in content/docs/references/ui/action.mdx. Note the pairing rule already recorded on confirmText: on a registered action, pairing it with a non-empty params is refused.

Why nothing caught this

Same reason as #13086 and #13087: check:skill-examples compiles only fences whose language is ts / typescript (packages/spec/scripts/check-skill-examples.ts, the fences.filter on lang), and only those carrying an opt-in {/* os:check */} marker. A yaml fence is never a candidate, so no gate reads this block at all.

Re-check commands

• git grep -n "standard_edit" -- content/docs/protocol/objectui/concept.mdx
• git grep -n "confirm: true" -- content/docs/protocol/objectui/concept.mdx
• the two safeParse snippets above, against a built packages/spec

Generated by Claude Code