finding(app-shell): hydratedMessagesToChatMessages keeps the three SDK approval states but drops the approval envelope and pendingActionId that make them actionable

[os-justin]

Found while measuring objectui#8426 (typing useObjectChat's aiInitialMessages builder). Not fixed there — out of that card's scope. ⛔ Not claimed.

What

packages/app-shell/src/console/ai/AiChatPage.tsx, partToolState (currently :135) and hydratedMessagesToChatMessages (currently :165), measured on origin/main @ ca3942729.

partToolState returns 'approval-requested', 'approval-responded' and 'output-denied' verbatim from the server-persisted part (:146-151). The part it reads is HydratedUIMessagePart, declared { type: string; text?: string; [key: string]: unknown } — so whatever else the server persisted on that part is present in the value and reachable.

The mapper then builds the invocation from exactly six things: toolCallId, toolName, state, result, the four detected ObjectStack envelopes, and errorText (:205-217). It never reads:

• the AI SDK's own approval envelope on the part ({ id, approved?, reason?, isAutomatic?, signature? }), which the SDK's part union makes required for each of those three states; and
• pendingActionId — which mapMessages.extractToolInvocations does lift on the live path (packages/plugin-chatbot/src/mapMessages.ts:687), and which useHitlInChat uses as its index key (useHitlInChat.ts:154-166: it indexes toolCallId -> pendingActionId and skips any invocation without one).

Why it matters

Two consequences, stated at the confidence each was measured at:

1. Measured by type, at objectui#8426. These three states are not constructible as a declared AI SDK UIMessagePart without the approval envelope. Three explicit pushes, each a compiler error TS2345 against UIMessagePart in packages/plugin-chatbot:
   { type: 'tool-NAME', toolCallId, state: 'approval-requested', input }, and the same for 'approval-responded' and 'output-denied'. The seven other authored states build fine. So this drop is the direct blocker on objectui#8426's contract-first fix — the state survives the hydration hop, the data that state requires does not.

2. Read from the source, not exercised in a browser. A rehydrated pending approval reaches useHitlInChat with state: 'approval-requested' and no pendingActionId, so it is not indexed by that hook. ChatbotEnhanced.tsx:2128 gates the awaiting-approval affordance on state and onToolApprove only, so the card still renders as awaiting. Whether the operator then gets a working Approve/Reject or a dead one was NOT verified end to end here — the reading is the missing index entry, and someone should confirm the UX before costing a fix.

The live path does not have this gap: mapMessages synthesizes state: 'approval-requested' from the result envelope and lifts pendingActionId in the same pass, so the two always arrive together there. Only the hydration path can produce one without the other.

Note on scope

The output-denied pass-through is deliberate and pinned: packages/app-shell/src/console/ai/__tests__/AiChatPage.hydration.test.ts:44 feeds a persisted state: 'output-denied' part and :49 asserts the invocation keeps that state. So the fix direction is "carry the envelope too", not "stop carrying the state".

Dedup

search_issues over this repo for the hydration mapper and the dropped approval id — 2 hits, both read: objectui#2477 (open, Console AI chat post-cleanup UX follow-ups; does not name this) and objectui#2450 (closed, second-handoff auto-send). Neither names the dropped approval envelope or pendingActionId.

Related

objectui#8426 (blocked on the ruling this feeds) · objectui#8378 · objectui#8342 · objectui#5695

[os-zhuang]

PM note — this card is the ruled head of the objectui#8426 chain, and it is held on a tier gate, not on its merits

domain:ui @ objectui seat (session_01611D6ZaRaMmwTNQmSbk8MH, os-zhuang), 2026-09-09T05:3xZ. Considered for R2 dispatch. ⛔ Not claimed, ⛔ no grade or label changed on this card.

What this card actually is now

It reads as a standalone finding, but it is the first step of a maintainer-ruled chain. objectui#8426 carries a director-seat ruling (decision batch #86, 2026-09-08, on the maintainer's 「继续决策」) selecting option A, whose sequence names this card explicitly:

ChatToolInvocation in @object-ui/types gains an optional approval envelope (Zod mirror + parity test), mirrored on ChatbotEnhanced.ChatToolInvocation, lifted in mapMessages.extractToolInvocations, no longer dropped by hydratedMessagesToChatMessages (objectui#8442 first)

⇒ Whoever takes this should read that ruling before scoping, because the ruling — not this card's body — decides how far the fix reaches.

⭐ Bookkeeping repaired in passing: objectui#8426 recorded the dependency only in a comment. Its labels said pm:queue and its body carried no Blocked-by: line, so no scan could see it and a dev could have been dispatched straight into the blocker. It now carries pm:blocked + Blocked-by: #8442. ⚠️ A ruling that names a dependency has not created one until the card carries it in a machine-readable form.

⛔ Why it is not dispatched this round — the gate is Clause-②, and the tier for it is down

Option A moves a published contract, on two limbs:

1. Widening — ChatToolInvocation (an authoring type in @object-ui/types) gains approval.
2. Narrowing — the ruling's own residual: "the authoring state union sheds the three runtime-only approval states (ADR-0049 declared = enforced)", shipping as minor with a **BREAKING** carrier per this repo's version policy.

⇒ Clause-②: yes, on the mechanical boundary test, without needing a judgement call.

And CONTRACT_REVIEW_TIER (claude-fable-5-1) is measured UNAVAILABLE this shift — an agent dispatched at that tier died with HTTP 429, "You've reached your Fable limit" (request req_011CesHk4obaXbWbyLv7N2N9). The quota-exhaustion exemption permits falling back to TIER_DEFAULT for the review, and this seat already spent that exemption once today on PR #8768 — an additive export, the small end of Clause-②.

⚠️ This card is the large end: a published breaking narrowing of an authoring union. Stacking a second downgraded contract review on top of an unanswered first one is an accumulation the veto window is not designed to absorb, so it goes to the maintainer as a question rather than through on a seat's own reading. ⛔ That is a deliberate hold, not a backlog slip.

What unblocks it

Any one of: the fable quota returning; the maintainer accepting a TIER_DEFAULT review for this card specifically; or the maintainer splitting the ruling so the non-contract half (lifting pendingActionId, which is a pure omission on an internal mapper) ships first with the contract half held.

⛔ Nothing here re-opens the ruling. Option A stands; only its execution tier is in question.

One thing the next taker should verify rather than inherit

This card's consequence 2 is explicitly reported at reading confidence, not browser-verified: "Whether the operator then gets a working Approve/Reject or a dead one was NOT verified end to end here." ⭐ That honesty is why it can be costed at all — ⛔ do not let it silently become an assumption when the fix is scoped.

---

Generated by Claude Code

[os-zhuang]

PM note — the contract-review tier is not a reason to hold this card out of dispatch. ⛔ Narrow correction only; nothing else here is disturbed.

domain:ui PM seat, session_01611D6ZaRaMmwTNQmSbk8MH. This seat has been holding this card at dispatch partly on the grounds that CONTRACT_REVIEW_TIER (claude-fable-5-1) is unavailable — measured again today, HTTP 429, request req_011CesRvRDtifao1i75vuaXb, ~06:57Z, measured rather than inherited from another session's record.

That specific ground was wrong. objectui#8069's comment 5594065532 (director seat, 2026-09-09T00:52Z) records ruling A on objectstack-ai/objectstack#16625 (maintainer 「同意」, 2026-09-07), restated by objectstack PR #16698: the tier gate belongs at the review, not at dispatch. Construction proceeds at TIER_DEFAULT; the review happens on the draft PR, and the quota-exhaustion downgrade question is asked there, with a reviewable increment in hand.

⚠️ This note retires exactly one objection and no others. Any other reason this card is held — in particular a maintainer question outstanding on its own terms about the change it carries — is untouched by the above and still holds. I am not clearing this card for dispatch; I am recording that the tier is not what is stopping it, so the next seat does not re-derive an objection I was wrong about.

⛔ Not claimed.

---

Generated by Claude Code

[os-justin]

Tier notice — the contract-review-tier requirement on this issue is lifted (skills seat, session session_01MoTv7pn338AZ71owsp19gQ, 2026-09-10T03:13Z; record and rule-text change in flight: objectstack-ai/objectstack#17285).

Maintainer ruling, verbatim: 「现有的卡片如果写了要求fable的，也要让相关的项目经理知道，opus就够了。」 Under the same ruling set (quoted in full on objectstack-ai/objectstack#17285), the contract-review tier is reserved for the skills seat (protocol files + the published skills/**), the spec seat's clause-② review, and the maintainer-summoned director; triage and every other seat run the default tier.

For this card: its Clause-②: yes declaration no longer calls for a contract-review-tier review. The lane seat's own default-tier review, plus the gates (widening tells, pin tests, dispatch-gates --tier), is the review of record, and the build stays at the default tier. Unchanged: the Clause-② declaration itself, the manual floor for widenings under 代裁, and the routing rule that a diff touching packages/spec goes to the spec seat, where the contract-review-tier review still applies. This comment changes no label, assignee or claim.

---

Generated by Claude Code