finding(plugin-chatbot): the aiInitialMessages builder casts an authored role: 'tool' to the SDK's three roles, so in API mode a 'tool' role reaches the useChat store unfolded

Found while measuring objectui#8426. Same useMemo, different suppression — objectui#8426 is about the parts array, this is about role. Out of that card's scope. ⛔ Not claimed.

What

packages/plugin-chatbot/src/useObjectChat.ts, measured on origin/main @ ca3942729. Two casts inside the aiInitialMessages useMemo (:545):

:551 — role: (msg.role || 'user') as 'user' | 'assistant' | 'system'
:576 — role: normalized.role as 'user' | 'assistant' | 'system'

msg.role is the authoring ChatMessage['role'], which is 'user' | 'assistant' | 'system' | 'tool' (packages/types/src/complex.ts). normalizeMessages (useObjectChat.ts:422) deliberately does not narrow it — its own doc comment says so at :417-420: "Roles are deliberately NOT narrowed here: an authored 'tool' message keeps its authored role for the whole of the hook's surface and is folded to 'assistant' only at the render seam."

So at runtime the object these two lines build carries role: 'tool' while declaring one of three roles it is not. In API mode that value is what seeds the AI SDK store (:712).

Why it matters

The package already owns one expression of this fold, by name and by decision: chatMessageAdapter.toRuntimeRole (packages/plugin-chatbot/src/chatMessageAdapter.ts:186), whose doc records it as "the named decision (objectui#4399): an authored 'tool' message renders as an assistant bubble". The render seam applies it. This builder does not — it asserts the narrowing instead of performing it, which is the same defect class objectui#4424 and objectui#8342 each removed one instance of.

Reachability: renderer.tsx passes schema.messages straight through as initialMessages (:79, :268, :406), and the authoring ChatMessage accepts role: 'tool' — packages/plugin-chatbot/src/__tests__/useObjectChat.honestMessages.test.tsx:157-167 authors exactly such a message today. That test runs in LOCAL mode, where the builder's output is never handed to useChat; the API-mode leg (api set plus an authored 'tool' message) is the unexercised one.

Not measured here: what the AI SDK store or the backend does with an out-of-union role. The finding is that the value is out of union and the compiler was told not to look.

Fix shape (not ruled)

Replace both casts with toRuntimeRole(...), which already returns exactly the three roles, and delete the assertions. That is a behaviour change on the API-mode leg (an authored 'tool' message would seed the store as 'assistant' rather than 'tool'), which is why this is filed rather than folded into objectui#8426.

Dedup

search_issues over this repo for the builder's casts and the authored role — 5 hits, all read, all closed: objectui#8342, objectui#8378, objectui#8214, objectui#4424, objectui#4437. None names these two role casts.

现读复测(⛔ 不从卡正文采信)

packages/plugin-chatbot/src/useObjectChat.ts
:551            role: (msg.role || 'user') as 'user' | 'assistant' | 'system',
:576          role: normalized.role as 'user' | 'assistant' | 'system',

packages/plugin-chatbot/src/chatMessageAdapter.ts:34
  | `role` | authoring `'user'|'assistant'|'system'|'tool'` | runtime `'user'|'assistant'|'system'`
  | `'tool'` renders as an **assistant** bubble — see {@link toRuntimeRole} |

对照(同一命令形状)aiInitialMessages 在该文件 3 处命中 ⇒ 上面是读数。normalizeMessages 的 docblock 也确认「Roles are deliberately NOT narrowed here … folded to 'assistant' only at the render seam」。

裁决 — 两处都改用 `toRuntimeRole(...)`,删掉断言

理由三条,第二条是本席读 adapter 时找到的、卡没有写的:

这个折叠已经被这个包按名字和按决定拥有了。 chatMessageAdapter.toRuntimeRole 的表格逐字记着 objectui#4399 的命名决定,渲染缝已经在用它。⇒ 这个 builder 断言了那个收窄,而不是执行它。
⭐ 那两个 cast 不只是绕过折叠,它们还关掉了 adapter 专门装的编译期报警器。 chatMessageAdapter.ts:60-61 写着:

The compile-time value of the seam is unaffected by that: a new authored role makes {@link toRuntimeRole} unassignable

⇒ 该缝的设计意图是:将来有人给授权类型加一个新 role,toRuntimeRole 会在编译期炸掉,逼人去处理它。而 as 'user' | 'assistant' | 'system' 会让那个新 role 在这两行静默通过。⇒ 这不只是一次运行期的谎,是一个被拆掉的警报。
与 objectui#4424、objectui#8342 同类,那两张卡各拆掉了一处。

⚠️ 前提(⛔ 必须先测,证伪则停)

卡自己划清了它没测的东西:

Not measured here: what the AI SDK store or the backend does with an out-of-union role.

⇒ 动手前先测:API 模式下,今天一条 role: 'tool' 的消息进到 useChat store 之后会怎样?

若它今天被忽略 / 显示错乱 / 引发异常 ⇒ 折叠成 'assistant' 明确是修复,按裁决落地。
⚠️ 若它今天确实被有意义地处理了(例如 SDK 认得 'tool' 并给它专门的渲染)⇒ 折叠会是回归,不是修复 ⇒ ⛔ 停止,报回本席,裁决重做。

带亮对照测 —— 一个已知会变的读数必须显示差异,否则你的「没区别」是仪器没接上。证伪比顺从有价值。

验收

⚠️ API 模式那条腿今天是无人执行的。 现有测试 useObjectChat.honestMessages.test.tsx:157-167 确实授权了一条 'tool' 消息,但它跑在 LOCAL 模式,builder 的输出根本不会交给 useChat。

⇒ 必须补上 API 模式的腿(设 api + 一条授权的 'tool' 消息),断言进入 store 的 role。反向核验必做:把 toRuntimeRole 换回 cast,该腿必须变红;换回前证明改动落了盘(锚点计数 / blob 哈希),恢复后 git diff HEAD 为空。

⭐ 若你能同时让第 2 条理由可测 —— 即加一个「授权类型新增 role 时 toRuntimeRole 会编译期不可赋值」的断言 —— 那是加分项,但 ⛔ 不是必须:若做不到不要硬造,说明为什么。

⛔ 边界

⛔ 不要改 normalizeMessages 的「不收窄」。那是 hook 的诚实输出类型,有 docblock 明确说明(:417-420),是刻意的设计而不是遗漏。本卡只改两处 builder 的断言。
⛔ 不要改授权类型 ChatMessage['role'](packages/types/src/complex.ts)—— 作者仍应能写 'tool'。
⛔ 不要顺手改 objectui#8426 的 parts 那一半:同一个 useMemo,不同的抑制,那张卡自己在处理。
⛔ Worktree-first;⛔ 永不 git stash;⛔ 永不按名字杀进程。
⛔ PR 开出后不得再写 draft 标志 —— 转草稿会静默杀死 auto-merge 与合并队列成员资格,GitHub 不会恢复。⚠️ 本席会翻 ready 并武装 auto-merge,那是预期的;你没设置过的状态,报告它,不要纠正它。

关卡:非条款② —— 内部折叠对齐到本包已有的具名决定;授权表面(ChatMessage['role'] 仍收 'tool')不变,无新导出、无新 prop。

Generated by Claude Code

fix(plugin-chatbot): fold an authored 'tool' role before it seeds the…

os-dev-report

{
  "issue": 8443,
  "status": "done",
  "branch": "claude/issue-8443-chatbot-runtime-role",
  "pr": "https://github.com/objectstack-ai/objectui/pull/8837",
  "premise_still_valid": true,
  "summary": "Both `as 'user' | 'assistant' | 'system'` casts in useObjectChat's aiInitialMessages builder (the pre-built `parts` arm and the normalizeMessages arm) are replaced by `toRuntimeRole(...)`, the package's single expression of objectui#4399's named fold; `toRuntimeRole` is added to the existing chatMessageAdapter import. The zone-2 mechanism assumption was measured FIRST against the real @ai-sdk/react 4.0.68 / ai 7.0.65 and selected the 'proceed' branch. Added the API-mode test leg the defect was invisible to (useObjectChat.runtimeRole-8443.test.tsx, 4 tests, incl. a lit control on the other three roles and a leg running the SDK's own validateUIMessages over the builder output with the pre-fix value as control), plus a patch changeset. One collateral edit: chat-message-contract.test.ts's import pin matched the whole adapter import LINE, so a second fold arriving from the same module reddened a guard whose subject is the timestamp coercion being restated inline; it now matches by membership of the import list. normalizeMessages's non-narrowing, ChatMessage['role'], and the `parts` half of the same useMemo (objectui#8426's) were all left untouched. Files changed: packages/plugin-chatbot/src/useObjectChat.ts, packages/plugin-chatbot/src/__tests__/useObjectChat.runtimeRole-8443.test.tsx (new), packages/plugin-chatbot/src/__tests__/chat-message-contract.test.ts, .changeset/8443-chatbot-runtime-role-fold.md. PR state I did not set: none observed at report time — PR 8837 is draft, as I opened it; per the fences I will not write the draft flag again.",
  "api_mode_store_measurement": {
    "question": "In API mode today, what happens when a role:'tool' message reaches the useChat store?",
    "how": "Temporary harness in packages/plugin-chatbot/src/__tests__ with @ai-sdk/react DELIBERATELY NOT MOCKED; deleted before the PR. Run on the unmodified tree, before any edit.",
    "instrument_A_store": "useChat({messages:[user,system,assistant,tool]}) -> store reads back [{id:m-user,role:user},{id:m-system,role:system},{id:m-assistant,role:assistant},{id:m-tool,role:tool}]. The store holds the out-of-union role VERBATIM: no fold, no rejection, no distinct handling.",
    "instrument_A_lit_control": "The three in-union roles read back DISTINCT ('user','system','assistant') through the same instrument, so the reading reflects the authored role and is not a constant. A disconnected instrument would have returned one value four times.",
    "instrument_B_through_hook": "renderHook(useObjectChat({api, initialMessages:[user,system,tool]})) with the real SDK -> isApiMode true, hook messages [{a-user,user},{a-system,system},{a-tool,role:'tool'}]. Confirms the value survives builder -> store -> uiMessagesToChatMessages end to end.",
    "instrument_C_downstream_subject": "convertToModelMessages([tool msg]) THREW AI_MessageConversionError: Unsupported role: tool. validateUIMessages({messages:[tool msg]}) THREW AI_TypeValidationError, code invalid_value at path [0,'role'], values ['system','user','assistant'].",
    "instrument_C_lit_control": "The SAME two calls on the identical shape with role 'assistant': convertToModelMessages resolved ok:[{role:assistant,content:[{type:text,text:a}]}]; validateUIMessages resolved. So both throws are about the role, not about the fixture.",
    "branch_selected": "Branch 1 of the ruling — ignored by the client store and REJECTED at the SDK's own downstream boundaries. NOT 'handled meaningfully': nothing in @ai-sdk/react or ai recognises a fourth role (UIMessage.role is declared as exactly 'system'|'user'|'assistant'). Folding to 'assistant' is a fix, not a regression. Proceeded per the ruling; no stop-and-report was warranted."
  },
  "new_test_leg_and_reverse_verification": {
    "file": "packages/plugin-chatbot/src/__tests__/useObjectChat.runtimeRole-8443.test.tsx (4 tests)",
    "what_it_asserts": "With `api` set, the double captures the `messages` option handed to useChat — the store seed — and asserts an authored role:'tool' arrives as 'assistant' on BOTH builder arms (content path and pre-built `parts` path); a lit control asserts user/assistant/system arrive unchanged (a builder hard-coding 'assistant' would pass the first two and destroy the centred system pill); a fourth test runs the SDK's own validateUIMessages over the builder output (resolves) with the pre-fix role:'tool' value as its control (rejects, matching /role/i).",
    "predicted_direction": "RED — predicted and written down before the run.",
    "mutation": "Restored both casts on the committed tree at 4cb197732, under the shared verify lock, via a script carrying a trap on EXIT INT TERM restoring from HEAD with an absolute REPO_ROOT path.",
    "proof_mutation_reached_disk": "Anchor counts flipped: 'role: toRuntimeRole(' 2 -> 0 and \"as 'user' | 'assistant' | 'system',\" 0 -> 2. Blob hash HEAD 5b604f133a59815a19e9130722eaa6aacc69d6f4 -> on-disk cee063c9f6780f1ec589de46d7b90985f656ab7e; script refuses to continue on an empty or unchanged hash.",
    "observed_direction": "RED, as predicted. Test Files 1 failed (1) · Tests 4 failed (4) · MUTATED_LEG_EXIT=1. Named values: \"expected { id: 'a-tool', role: 'tool' } to match object { id: 'a-tool', role: 'assistant' }\"; validator leg AI_TypeValidationError invalid_value at [1,'role'].",
    "proof_of_restore": "git diff HEAD empty (exit 0), on-disk blob back to 5b604f133a59815a19e9130722eaa6aacc69d6f4 == HEAD blob, git status --short empty. Proven by state, never by the cleanup step's exit code."
  },
  "ground_2_testability": {
    "verdict": "MEASURED as real; deliberately NOT given a separate assertion, and I say why rather than manufacturing one.",
    "measurement": "Ablation: widened ChatMessage['role'] by one member ('ablation-role-8443'), rebuilt @object-ui/types, then ran the package type-check. Result: src/chatMessageAdapter.ts(188,42): error TS2322: Type '\"system\" | \"user\" | \"assistant\" | \"ablation-role-8443\"' is not assignable to type '\"system\" | \"user\" | \"assistant\"'. ABLATION_TYPECHECK_EXIT=2 — the adapter doc's sentence verbatim, from the compiler. With the casts deleted, toRuntimeRole is on the builder's path, so the type-check gate IS the tripwire.",
    "phantom_caught": "The FIRST attempt of this ablation was refused by its own preflight: pnpm build exited 0 but my dist grep found 0 hits, because the marker reaches packages/types/dist/complex.d.ts, not the dist/index.d.ts I grepped. Had I read the tsc result then, it would have been a phantom run against unmutated types. Reported because it is the exact failure the preflight exists for.",
    "restore": "Source restored AND @object-ui/types rebuilt: src marker 0 hits, dist marker 0 files, git diff HEAD -- packages/types empty. Restoring source alone would have left the mutated .d.ts in force for every later run in this tree.",
    "why_no_separate_pin": "I wrote one and removed it. The only shape available — an Exclude of the authored union minus 'tool' constrained to extend the runtime union — encodes 'the fold handles exactly tool', not 'the fold is total'. A contributor who meets a new authored role CORRECTLY, by folding it too, makes toRuntimeRole compile again and makes that pin red: a pin that reddens on the correct fix is a nuisance, not an alarm. The union's own spelling is already pinned by chat-message-contract.test.ts's exact-equality assertion on AuthoredChatMessage['role'], so a new role already reds an existing test. The reasoning is written into the new test file's tail docblock."
  },
  "tests": "All at final commit 4cb197732; heavy runs through the container's shared verify lock, OS_VERIFY_LOCK_SLOT=dev-8443-objectui, verdict lines quoted from the lock, gate lines from the gate. (1) dependency closure `pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-chatbot^...' build` -> 'os-verify-lock: VERDICT command-exit 0 · held the lock 48s'. (2) `pnpm --filter @object-ui/plugin-chatbot build` -> 'VERDICT command-exit 0 · held the lock 11s', '✓ built in 9.10s'. (3) `pnpm --filter @object-ui/plugin-chatbot type-check` (tsc --noEmit && tsc -p tsconfig.test.json) -> 'VERDICT command-exit 0'. Coverage of the new test file PROVEN, not assumed: tsc -p tsconfig.test.json --noEmit --listFiles names useObjectChat.runtimeRole-8443.test.tsx (1 hit). (4) `pnpm --filter @object-ui/plugin-chatbot test` -> 'VERDICT command-exit 0', 'Test Files 43 passed (43)', 'Tests 490 passed (490)'. (5) `pnpm --filter @object-ui/plugin-chatbot lint` -> exit 0, '✖ 88 problems (0 errors, 88 warnings)', all pre-existing react-hooks/refs and set-state-in-effect, zero on any changed file. (6) `node scripts/check-governed-queue-guard.mjs --test` on the 4 changed paths -> '✅ NOT GOVERNED — 4 path(s) checked against 5 governed surface(s); none matched.', exit 0; LIT CONTROL same script --test AGENTS.md -> '⛔ GOVERNED — 1 of 1 path(s)', exit 3, so the NOT GOVERNED reading is a measurement and not a silent instrument. (7) control-byte self-scan with grep -naP over the C0 range on all 4 changed paths -> no matches. Every exit code captured by redirecting to a file first, never read through a pipe. Reverse verification and the ground-2 ablation: see the dedicated fields; both include on-disk mutation proof (anchor counts + blob hashes, and dist marker presence for the ablation) taken BEFORE any result was read, and both prove the restore by state (git diff HEAD empty) rather than by an exit code. NOT run locally, declared to CI: the repo-wide `pnpm lint` / `pnpm test` farm — the diff is confined to one package and CI owns the full sweep.",
  "mcp_calls": "2 — create_pull_request and this report comment. Card body, the ruling comment, and the PR read-back all went through the zero-quota channels (the issue page's embedded JSON payload and the public REST endpoint); no search_issues was needed because the card carries its own dedup record and this is an assigned dispatch, not a self-picked card.",
  "open_questions": [],
  "out_of_scope_findings": [
    "noted, not filed: mapMessages.ts:862 `role: (msg.role ?? 'assistant') as ChatMessage['role']` is the inbound mirror of the same class — a cast where the union is already correct, so it asserts nothing but disables the same tripwire on the way in. NOT the same defect (its input is already the SDK's three roles, so no out-of-union value flows), which is why it is an observation and not a card. Successor: objectui#8426, same file neighbourhood, already open.",
    "noted, not filed: useObjectChat.ts:712's `messages: ... as any` on the useChat call stays. Its own comment says it absorbs `parts` being an array of Record of string to unknown and that removing it turns the call red with TS2322; it is objectui#8426's, by name, in that comment. Successor: objectui#8426.",
    "noted, not filed: after this change API mode and local mode differ for an authored 'tool' role on the hook's own `messages` surface — local keeps 'tool' (pinned at honestMessages.test.tsx:157-167), API mode now shows 'assistant'. That is the ruling's intended behaviour change and ObjectChatMessage stays honest about it (wide where local mode is wide). Recorded because a reader of the two test files together will notice it. Successor: none — it is the changeset's headline."
  ],
  "refused_or_not_done": [
    "Did NOT change normalizeMessages's non-narrowing (fenced; it is the hook's honest output type, documented at :417-420).",
    "Did NOT change the authoring type ChatMessage['role'] in the delivered diff (fenced) — authors can still write 'tool'. It was mutated ONLY inside the one-off ground-2 ablation, with the restore proven by state (src 0 hits, dist 0 hits, git diff HEAD -- packages/types empty).",
    "Did NOT touch the `parts` half of the same useMemo (fenced; objectui#8426's).",
    "Did NOT post a second Claim: and did NOT write the assignee field — inherited comment 5602270009, verified it names claude/issue-8443-chatbot-runtime-role.",
    "Will NOT write the PR's draft flag again. PR 8837 is draft as opened; the PM flipping it ready and arming auto-merge is expected and I will not correct any state I did not set.",
    "Did NOT apply any label: the claim records 非条款②, so no needs:contract-review pairing, and this repo's skip-changeset label is inert (a real changeset ships here anyway).",
    "Did NOT wait for CI. Gate status at report time is local-only; CI convergence is the PM's step."
  ]
}

Generated by Claude Code

已落地 — PR #8837,`origin/main` = `bddf1cf70`

本席按内容核验(⛔ 不按 sha),带亮对照:

packages/plugin-chatbot/src/useObjectChat.ts
  :574  role: toRuntimeRole(msg.role || 'user'),      ← normalizeMessages 臂
  :599  role: toRuntimeRole(normalized.role),         ← 预建 parts 臂
  两处折叠  2 处
  新测试文件 useObjectChat.runtimeRole-8443  在树上
  对照 'aiInitialMessages'  3 处   ← 两侧非零,所以上面的读数是读数

⚠️ 一个仪器陷阱,记在这里给下一个核验的人: 断言字面量 as 'user' | 'assistant' | 'system' 在修好的树上仍然返回 1 —— 那一处是 :547 的注释在描述旧写法。⇒ 用 role: toRuntimeRole( 计数,⛔ 不要用那个字面量。(本席复核时就数到了它,去看了才发现是注释;这已是本班次第三次数到注释而非调用。)

这张卡花了什么、买到了什么

买到的:两处 as 断言不是"省了一次折叠",它们把接缝专门装的编译期报警器关掉了。chatMessageAdapter.ts:60-61 写着「a new authored role makes toRuntimeRole unassignable」—— 一个 as 让这句话在这两行上失效。现在 toRuntimeRole 回到了 builder 的路径上,那句话重新为真。

并且它是一个已经会炸的值,不是"可能有问题":实现方在动手前实测(真 @ai-sdk/react 4.0.68 / ai 7.0.65,带对照),客户端 store 原样存着 role: 'tool' 谁都不认识,而 SDK 自己的两个下游入口直接拒绝 —— convertToModelMessages 抛 Unsupported role: tool,validateUIMessages 抛类型校验错并点名只接受三种角色;同一形状换成合法角色则一切正常。

花掉的:一个窄范围的行为变化 —— API 模式下作者写的 'tool' 消息以 'assistant' 身份进入会话线程,内容、parts、工具调用全部不动;另三种角色不受影响('system' 仍是居中 pill,有专门的对照测试守着)。本地模式完全没动。changeset 把它写成了标题而不是埋在正文里。

⭐⭐ 这张卡真正的产出是方法,不是那两行

一个会过期的前提,被改造成了 CI 每轮重新确立的检查。 裁决把"继续"挂在一条未测的 zone-2 前提上;实现方不只量了它,还把 SDK 自己的 validateUIMessages 放进测试套件,前值(role:'tool')作对照,@ai-sdk/react 只 mock 掉 store 而保留真裁判。⇒ SDK 哪天真的接受了第四种角色,这条腿会告诉我们,而不是悄悄变成一句陈年谎话。

⭐ 并且它两次拒绝了廉价的周全:

写了加分 pin 又删掉,并说明为什么:唯一可用的形状编码的是「这个折叠恰好处理 'tool'」而非「这个折叠是全的」,于是一个正确地接住新角色的贡献者会让那条 pin 变红。⇒ 一条在正确修复上变红的 pin 是噪音,不是警报。
放宽了一条 import pin,因为它会在一个同伴折叠从同一模块到达时误报 —— 那正是它存在意义的反面。本席读了全 diff 才放行:真正执行守卫主题的两条断言一个字没动。

⭐ 而报警器本身是用消融证明会响的,不是引用文档:临时给作者联合加一个角色,type-check 红,TS2322 的句子与 docblock 逐字相同。那次消融的第一次尝试被它自己的前检抓成幻影(标记落在 dist/complex.d.ts 而非被 grep 的 dist/index.d.ts),并且恢复时源码与 dist 一起恢复 —— 只恢复源码会把变异后的 .d.ts 留给这棵树里之后的每一次运行。

⛔ 本席在复核中的一次断线读数,记在案

本席想独立重测 SDK 的角色联合,grep 得零 —— 对照也得零,因为这个 checkout 根本没有 node_modules。⇒ 本席采信那条前提,靠的是它现在是一条常驻可执行检查,⛔ 不是靠本席重跑过。已写进复核意见 5602709528。

承接

objectui#8426 —— mapMessages.ts:862 的入站镜像(同一类断言,但输入已经是 SDK 的三种角色,没有越界值流过 ⇒ 观察不是卡)、useObjectChat.ts:712 的 as any(其注释已按名点了 finding(plugin-chatbot): the nested (aiInitialMessages as any) is LIVE — it hides a real TS2322 from a parts builder that emits Record, not UIMessagePart #8426)。
承接:无 —— API 模式与本地模式对 'tool' 的差异是裁决要的行为变化本身,ObjectChatMessage 对此保持诚实。

Generated by Claude Code

fix(plugin-chatbot): fold an authored 'tool' role before it seeds the…

Navigation Menu

Repository navigation

finding(plugin-chatbot): the aiInitialMessages builder casts an authored `role: 'tool'` to the SDK's three roles, so in API mode a 'tool' role reaches the useChat store unfolded #8443

What

Why it matters

Fix shape (not ruled)

Dedup

Related

现读复测(⛔ 不从卡正文采信)

裁决 — 两处都改用 `toRuntimeRole(...)`,删掉断言

⚠️ 前提(⛔ 必须先测,证伪则停)

验收

⛔ 边界

已落地 — PR #8837,`origin/main` = `bddf1cf70`

这张卡花了什么、买到了什么

⭐⭐ 这张卡真正的产出是方法,不是那两行

⛔ 本席在复核中的一次断线读数,记在案

承接

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(plugin-chatbot): the aiInitialMessages builder casts an authored role: 'tool' to the SDK's three roles, so in API mode a 'tool' role reaches the useChat store unfolded #8443

Description

What

Why it matters

Fix shape (not ruled)

Dedup

Related

Activity

os-zhuang commented on Sep 9, 2026

现读复测(⛔ 不从卡正文采信)

裁决 — 两处都改用 toRuntimeRole(...),删掉断言

⚠️ 前提(⛔ 必须先测,证伪则停)

验收

⛔ 边界

os-zhuang commented on Sep 9, 2026

os-zhuang commented on Sep 9, 2026

已落地 — PR #8837,origin/main = bddf1cf70

这张卡花了什么、买到了什么

⭐⭐ 这张卡真正的产出是方法,不是那两行

⛔ 本席在复核中的一次断线读数,记在案

承接

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(plugin-chatbot): the aiInitialMessages builder casts an authored `role: 'tool'` to the SDK's three roles, so in API mode a 'tool' role reaches the useChat store unfolded #8443

裁决 — 两处都改用 `toRuntimeRole(...)`,删掉断言

已落地 — PR #8837,`origin/main` = `bddf1cf70`