sys_approval_action.action renders raw machine values (`submit` / `approve`) in the shipped en bundle — the #7232 humanization covered `status` and missed the sibling field

[hotlong]

Blocked-by: #8543

Symptom

The shipped en bundle entries for sys_approval_action.action are the raw machine values — a user reading an approval action row sees submit / approve (lowercase machine tokens) where every sibling surface shows humanized English. fieldOptionLabel in @object-ui/i18n falls back to the option's own label with no humanization step, so nothing downstream absorbs it: what is in the bundle is what renders.

This is the exact defect one field over from the five sys_approval_request.status labels discussed on #8543 — except those five were deliberately humanized by #7232 (closed), whose sweep covered status and missed action. This one ships raw today.

Provenance

Measured and reported by the #8543 dev seat in its needs_decision report of 2026-08-13 22:52Z (session recorded there), which explicitly left grading and carding to triage: "the sibling field sys_approval_action.action already ships raw lowercase submit / approve in en. Same defect one field over … it exists today independent of this card." Filed by the triage seat after a duplicate check: #7232 (closed) is the prior humanization pass that missed this field; no open card covers it.

Why blocked rather than queued

The fix's location is exactly what the #8543 ruling decides — where deliberately-authored rendered English is allowed to live:

• Variant A (blanket overwrite): the en bundle stops being a legal home for this text ⇒ the fix must land as source-side labels, and a bundle-only fix would be silently reverted by the next regeneration.
• Variant B (authored-only overwrite): a bundle edit could stand, but bare-string options currently seed through the authored channel, so the guard-rail work decides the mechanics.
• Variant C (contract-first, the dev-recommended destination): the labels belong beside the action vocabulary in packages/spec — in which case this card re-routes to domain:spec at unlock.

Fixing it now in the en bundle under merge-mode semantics would work today but pre-empts (or is destroyed by) every one of the three variants. One ruling, then this becomes a small mechanical dispatch.

Unlock instruction: when #8543's ruling lands, re-verify this card against the chosen variant, re-route the domain label if C, and queue.

Related

• check-i18n-bundles merge mode never updates an EXISTING field description, so editing one leaves the en bundle silently stale (and the gate green) #8543 — the decision card whose ruling determines the fix location (this defect is evidence in its fork: it shows what variant A's overwrite would spread).
• [approvals] Unify the approval-status vocabulary across i18n bundles (zh "待处理"→"待审批", my_pending view label; humanize the en status options) #7232 (closed) — the prior humanization pass that established the deliberate-English precedent for status and missed this sibling.

Filed unassigned by the triage seat Routine.

[hotlong]

Unlock update: the #8543 ruling has landed — variant C won. (Maintainer live session, 2026-08-13 ~23:50Z, 「接受你的全部建议」.)

Per this card's own unlock instruction: re-routed domain:services → domain:spec — under C, the humanized action labels belong beside the action vocabulary in packages/spec, then flow out through regeneration.

Still pm:blocked, deliberately: the blocker is now #8543's implementation, not its ruling — this card's fix shares #8543's exact file surface (spec label constants + i18n-extract + regenerated bundles), so it must not be dispatched in parallel. The implementing seat for #8543 should either fold this sibling in (same treatment, one PR, declare it in the PR body) or land it immediately after — either way, close this card only when sys_approval_action.action renders humanized English end-to-end.

Recorded by the triage seat on the maintainer's direct channel.

---

Generated by Claude Code