Qwen Code への貢献

Web Shell のサイドバーにはワークスペースなしセッションが並びます。daemon は実行中の prompt や接続中の client があるセッションの削除を拒み、バッチ削除 API は HTTP 200 の応答に含まれる各項目の errors[] で session_busy を返します。

先行する #12636 では現在の行の Delete を無効にしました。maintainer は、先に離脱してから削除する案を後続の Issue #12669 に残しました。現在のタブが detach しても、別のタブが同じセッションに接続したままの可能性があります。

未変更のソース baseline では、現在のワークスペースなしセッションの行に Delete は表示されても無効でした。ボタンを有効にするだけでは、このタブが接続中のまま削除を要求し、daemon から session_busy が返ります。

通常の New task の戻り値だけでは detach の成功を証明できません。clearSession は detach の例外を握りつぶし、SDK は clientId がない場合の detach を何もしないまま成功扱いにします。サイドバーの件数も実際の状態より遅れることがあります。

PR 初版の上流レビューでは別の Critical が見つかりました。非同期の detach や削除中でも Cancel などで確認ダイアログを閉じられ、削除処理はその後も続いてしまいました。

クライアントには現在の行に対する順序付きの処理がありませんでした。削除を確認し、元のセッションから離れ、detach 完了を証明してから、固定した元の ID を削除する必要があります。daemon の busy 保護は正しく、維持します。

既存の callback は New task の結果を捨て、通常の clearSession は detach 失敗を隠し得ました。どちらも削除要求の前提にはできません。

サイドバーの二つの Delete 入口から、アイドル状態の現在のワークスペースなしセッションに既存の確認ダイアログを開けるようにしました。確認時に App の実行状態と元のセッション ID を再確認し、実行中の作業は引き続き保護します。

削除専用の await 可能な callback は createNewSession({ kind: 'global' }) を再利用し、厳密な clearSession 検査を行います。想定したセッション ID と一致する空でない二箇所の clientId を要求し、detach 失敗を通知し、detach の完了後に固定した元の ID のバッチ削除を要求します。

removed または notFound の場合だけ行を消します。項目ごとの session_busy や要求失敗では行を残し、エラーを表示します。離脱済みなら一覧を更新します。daemon の busy 保護と別系統の /delete セレクターは変更していません。

上流レビュー後、処理中はダイアログを閉じるすべての操作を無効化し、onClose に同期的な busy ガードを追加しました。detach または削除の間は確認ダイアログが表示されたままです。

レビューの提案に沿って、commit a2b39eb405 では削除中に進捗を表示し（Deleting... と aria-busy）、セッションの接続準備が整うまで Delete を無効にし、離脱の失敗とナビゲーションの取消しを同じ通知にまとめ、省略可能な callback の不要な分岐を削除し、再試行・更新・厳密な detach の回帰テストを追加しました。英語と中国語の設計文書も合わせて更新しました。

daemon は起動時に独立した ACP 子プロセスを preheat し、最初のセッションがコールドスタートのコストを払わなくて済むようにしています。その代償として、daemon が既に HTTP と WebSocket を提供しているのに、子プロセスはまだ argv を解析し設定を初期化している、という時間窓が生まれます。

ProcessRegistry は daemon が生成したすべての子プロセスを登録し、shutdown 時にそれらが確かに消えたことを証明する責任を負います。ACP 子プロセスは detached で生成されて自らプロセスグループのリーダーになるため、負のプロセスグループ ID へ signal を送ればツリー全体に一度で届きます。

#10140 以降、shutdown の契約は意図的に厳格です。子プロセスが終了し、かつそのプロセスグループがもう存在しないことの双方を証明できない限り、daemon は非ゼロで終了します。この証明のどの分岐を緩めることも安全性に関わる変更であり、自動修正に回せない理由でもあります。

macOS と Node.js v26.8.2 の環境で、preheat の完了前に daemon へ SIGTERM を送ると exit 1 になりました。永続ログには pgid への SIGKILL 送信失敗、ACP child process shutdown failed、daemon shutdown incomplete が残ります。しかし事後に ps、プロセスグループの照会、lsof のいずれで確認しても残留はありません。

計測を入れると順序が分かりました。グループへの SIGTERM は成功し、約 2 ミリ秒後に preheat の中断処理が同期的な kill を発行します。その時点で子プロセスは既に終了しているものの Node はまだ exit イベントを配信しておらず、グループへの SIGKILL が EPERM を返します。その後 exit イベントが届き、グループ全体が消えます。detached な子プロセスを使う最小の Node プローブで、同じカーネルおよびランタイムから見えるタイミングを安定して再現できます。

これは #12277 の検証中に最初に観測したため、Local Control をまったく呼ばない、未変更の公式コミットの隔離ビルドで確認し直しました。同じ EPERM と同じ exit 1 が現れたので、ポート修正が原因である可能性は排除され、そのブランチの回帰ではなく独立した報告として扱えるようになりました。

グループへの signal 経路はプロセスグループを ESRCH のときにしか外さず、それ以外の errno はすべて null 合体代入で cleanup proof のエラーに書き込まれます。その結果、最初のエラーが子プロセスの生存期間を通じて latch され、ファイル内のどこにもリセットがありません。clean path はその latch されたエラーを、unclean-exit の判定に到達する前に throw します。したがって一過性のエラーが一度起きるだけで、完全に正常な shutdown が非ゼロ終了に変わります。

このファイルは自己矛盾しています。生存グループを調べるヘルパーは EPERM を致命扱いする signal 経路のわずか 15 行下で EPERM を許容しており、子プロセスを直接 kill する呼び出しに至ってはすべてのエラーを飲み込みます。同じ EPERM が、ある呼び出し経由なら無視され、別の経由なら致命になります。一方でリポジトリ全体の慣習は許容側にあり、プロセス生存確認のヘルパーは EPERM をプロセスが生きている積極的な証拠として読みます。

第二の独立した原因は子プロセス側にあります。完全な ACP signal handler の設置が遅く、起動中に届いた SIGTERM は既定動作となって子プロセスは signal によって終了します。親側の厳格な契約はそれを正しく unclean と判定します。第一の原因だけを直した段階では daemon はなお exit 1 で、shutdown 中の unclean 終了というエラーに変わりました。第二層は推測ではなくこの形で判明しています。

グループへの signal 経路は、EPERM をグローバルに latch するのではなく、プロセスグループ単位で暫定的に保持するようにしました。その後の liveness 検査やプロセステーブルが、そのグループの消滅、または zombie と terminal のエントリしか残っていないことを証明した時点で、グループと暫定エラーの両方を破棄します。生きたメンバーが 10 秒の期限まで残った場合は、元の EPERM を取り出して最終的な失敗に含めます。それ以外の errno は fail-closed のままです。

子プロセス側は signal 処理を三段階に分け、同期的に引き継ぎます。CLI バンドルのエントリで最小の handler を、主起動フローに入ったら汎用 cleanup を実行する startup handler を、session・writer・MCP・transport の状態が揃ったら完全な managed ACP handler を設置します。各段階で新しい handler を設置してから古い handler を外すため、listen の空白はありません。

引き継ぎ完了前に signal が届いた場合は、保留中の shutdown を完全な handler に渡し、古い cleanup の Promise がプロセスを直接終了させないようにして、writer・session・MCP の cleanup が飛ばされないようにします。この新経路は厳密な ACP フラグ、daemon のスタンプ、daemon 専用の親 capability が同時に揃うときだけ有効なので、通常の CLI 利用、エディタ直結の ACP、親側の厳格な unclean-exit 判定はいずれも変更されません。

qwen serve は 127.0.0.1 だけを listen する常駐 daemon を起動します。Local Control は同じネットワーク上のスマートフォンからその daemon に届くようにする機能で、primary listener を外部へ広げるのではなく、同じプロセス内で選択した LAN IPv4 アドレスに二つ目の HTTP listener を開き、同一の Express アプリケーションを提供します。

二つの入口は認証の強さを変える必要があります。primary listener は daemon の runtime token を受け付け、これはコード実行を含む完全な API 権限に相当します。LAN listener は URL fragment で渡され QR コードになる使い捨ての pairing token だけを受け付けます。権限の区別はリクエストがどちらの listener から入ったかで行うため、各 listener に記録された authority と origin が HTTP の Host 検査と WebSocket の Origin 検査の両方に使われます。

TCP はアドレスとポートの組で bind するので、127.0.0.1:51873 と 10.131.53.163:51873 は通常は別のエンドポイントです。primary のポート番号を再利用しても安全に見えたのはこのためです。衝突はその LAN エンドポイント自体が使われているときだけ起こり、--port 0 はそれを起こしやすくします。OS が ephemeral port を取る池は、すべての outbound TCP 接続が送信元ポートを選ぶ池と同じだからです。

未変更のソース baseline でも、公開されている npm 0.24.1 パッケージでも同じ挙動を再現しました。一時的な socket で LAN エンドポイントを占有してから Local Control の有効化を要求すると、HTTP 500 と code local_control_enable_failed が返り、内部エラーは listen EADDRINUSE: address already in use 10.131.53.163:51873 でした。

daemon のログにはリクエストが 500 を返したことしか残らず、EADDRINUSE という理由は記録されません。runtime のエラーログ handler が最初の bind 成功後にしか登録されないからです。利用者には原因を追えない失敗だけが見え、状態自体は正しく active は false、残留した Local Control listener もありません。

占有していた socket を解放して同一のリクエストを送ると 200 が返り、lsof は同じ daemon が 127.0.0.1:51873 と 10.131.53.163:51873 の両方を listen していることを示しました。同じポート番号を二つのローカルアドレスに bind すること自体は問題なく、primary listener が衝突源ではないと確認できます。

LocalControlService は bind の前に LAN エンドポイントを計算していました。primary daemon のポートを読み、そこから authority、origin、pairing URL を組み立て、listener identity と資格情報を登録してから、同じポートで listen を呼びます。ポートの選択とエンドポイントのメタデータが結合していました。

メタデータが bind より先に生成されるため、listen に渡すポートだけを変えても、pairing URL、CORS origin、listener identity、返却される status は古いエンドポイントを指したままになります。拒否すべきリクエストを通すか、pairing URL を渡した当のスマートフォンを締め出すかのどちらかになります。

失敗経路自体は一時状態を正しく巻き戻しますが、ポートの再試行はなく、エラーが永続ログに届くこともありません。route は既知の interface / target エラー以外をすべて一つの汎用的な 500 local_control_enable_failed に写していました。

LAN listener は引き続き primary のポートを優先し、型付きの EADDRINUSE のときだけ一度だけ port 0 へ退避します。それ以外の errno は従来どおり失敗させ、権限やアドレスの問題を無条件の再試行で隠さないようにしています。

通常経路も退避経路も、同期的な listening コールバックの中で server.address() から無条件にエンドポイントを導出するようにしました。これにより、通常経路が bind 前にメタデータを先読みで組み立てていた二重経路が解消されます。authority、origin、pairing URL、listener identity、返却する status はすべて実際に取得したポートから埋めます。退避時はまず古い origin を外し、authority を持たない Local Control として listener を標識するため、新しい identity が登録されるまで Host gate は既定で拒否します。

最終的な bind 失敗は不透明な単一の 500 ではなく、409 address_in_use、403 bind_denied、409 invalid_address という対処可能なコードに写します。既存の DaemonLogger を注入し、退避と最終失敗の双方が永続ログに残るようにしました。ログ呼び出しは例外境界で包み、ログ sink の失敗が既に起動済みの listener を巻き戻さないようにしています。runtime token も pairing token もログには書きません。

Web Shell のエディターは、選択したファイル参照を正確な [start,end) 範囲を持つ CodeMirror の inline tag として保持します。送信時に tag を prompt のテキストへ変換し、UserMessage は inputAnnotations を使って参照を chip として描画します。

利用者は同じテキストを手入力できます。文字列の一致だけでは、通常の文字とファイル選択で挿入した参照を区別できません。

literal @foo then [foo] ではエディターが二つ目の @foo を正しく chip として保持していました。送信後の注釈は選択した chip の [18,22) ではなく、前方の通常テキストの [8,12) を指し、メッセージが利用者の選択を誤って示しました。

私のコンポーネント再現では元の prompt 文字列は変わりませんでした。注釈と UI のずれを証明したもので、モデル入力やファイル解決の変化は確認していません。

送信処理はエディターの実際の inline placement を使って prompt を構成しながら、inputAnnotations の生成時にはその範囲を渡していませんでした。helper が indexOf(serialized, cursor) で先頭から探すため、前方の同じ文字列が chip の注釈を取得しました。

描画時の検査は注釈の文字と対象部分の文字列を比べるだけでした。どちらにも @foo があるため、誤った位置でも通ってしまいました。

私はソースを調査し、実際の CodeMirror エディター、送信 hook、UserMessage を組み合わせて再現し、上流の関連報告を確認して Bug Report テンプレートで #12980 を提出しました。製品パッチは提出していません。

maintainer の yiliang114 が #12992 を作成し、実際の chip placement を注釈生成へ渡して prompt の接頭部分と shell モードのオフセットを考慮しました。レビュー後に回帰テストを追加し、独自 provider の placement が一致しない場合は、変換後のテキストが全体で一意のときだけ文字列照合へ戻る処理を加えました。

Qwen Code は通常起動時に、ルートディレクトリの mtime が 30 日を超え、ユーザーの作業がないように見える agent worktree を削除します。サブディレクトリ内の編集ではこの時刻が更新されるとは限りません。修正前の文書ではユーザー命名の worktree は自動削除しないとされていました。

ユーザー向けの enter_worktree と agent 隔離は作成 API を共有し、検証器は agent-<7hex> と完全に一致する名前も許すため、ディレクトリ名だけでは作成元を証明できません。

修正前は、ユーザー命名の worktree でも agent-<7hex> に一致し、ルートの mtime が 30 日を超え、追跡済みの変更もブランチ固有のコミットもなければ、クリーンアップ対象になり得ました。

その後 worktree は強制削除されました。未追跡ファイルは Git 履歴にないため、消えた内容を Git から復元できませんでした。

同じ見落としは、新規ファイルを残した実際の agent 作成 worktree にも及び得ました。この広いリスクは修正前のソース経路からの判断であり、実行した再現ではユーザー命名の worktree を使いました。

クリーンアップ処理はディレクトリ名を agent 由来の証明として扱っていましたが、ユーザーの worktree 名の検証でも同じ形式が許されます。修正では永続的な作成元マーカーは追加されていません。

修正前の変更確認は git status --porcelain --untracked-files=no を使って新規ファイルを見落とし、その後の git worktree remove --force がファイルを削除していました。

私はソース上の経路を追い、一時的な Git リポジトリで実際のクリーンアップ関数を呼んで再現し、上流の重複報告を調べ、プロジェクトの Bug Report テンプレートで #12735 を提出しました。製品コードは変更していません。

マージ済みの二つの PR はいずれも maintainer が作成しました。#12763 は主に隣接する Issue #12758 を扱い、未追跡ファイルと例外に該当しない ignored ファイルを調べる共通検査を導入しました。#12739 は #12735 の実際の Git を使う回帰テスト、保護理由のログ、文書を追加しました。どちらにも私の提出したコードは含まれません。

Qwen Code へのプルリクエストは、AI のレビューボットがレビューします。ボットが投稿する指摘は、どれも文字で書かれた重要度のマーカーで始まります。**[Critical]** は必ず直すべき問題、**[Suggestion]** は任意の提案です。重要度を表す専用の欄はなく、コメント冒頭のこのマーカーが唯一の手がかりです。

Autofix は GitHub Actions のワークフロー（qwen-autofix.yml）で、プルリクエストを引き受け、こうした指摘への修正を一回ずつ自動で push します。任意の提案を取り込み続けてプルリクエストが際限なく膨らむのを防ぐため、六回目から（差分が予算を超えて増えた場合はそれより早く）Critical-only モードに切り替わります。それ以降、コードを変えてよいのは Critical の指摘、正式な変更要求、失敗したチェック、マージの衝突だけで、提案は「保留」として記録され、人の判断に任されます。ワークフローは JSON を扱うコマンドラインツール jq で各コメントの重要度を読むため、文字列が一致するかどうかでボットの次の動きが決まります。

レビューの指摘には、問題が本当にあることを示す証拠として、テストの出力やログ、差分をコードブロックに貼り付けます。8 月 28 日にマージされた PR #9740 は、この決まりを提案にも広げ、提案にも証拠の引用を求めるようにしました。ところがレビュー機能自身のテストは **[Critical]** という文字列をそのまま出力するため、それ以降、この文字列が「引用された証拠」として提案の中にたびたび現れるようになりました。

Issue #10216 は Autofix 自身が作ったものです。Autofix は #9740 を処理する中でこの誤判定を確認しましたが、修正には qwen-autofix.yml を変える必要がありました。これはそのプルリクエストの範囲外で、しかも Autofix が編集を禁じられているファイルです。そこで Autofix はこの指摘を Issue として保留し、人に修正を委ねました。リポジトリの設計ドキュメント docs/design/review-tone.md も、同じ修正を今後の課題として挙げていました。

正当な提案は **[Suggestion]** で始まりますが、コードブロック内のテスト出力で **[Critical]** を引用することがあります。引用された文字列は証拠であってコメント自身の重要度ではないのに、以前のワークフローは本文全体からこの文字列を探していました。ワークフロー内の 12 箇所と検証スクリプトの 4 箇所が、位置を問わない contains("**[Critical]**") を使っていたのです。

Critical-only モードでは、その提案が必須の問題として扱われます。するとボットがそのためにコードを変えてしまうおそれがあり、これはまさに Critical-only モードが防ぐためのものです。さらにその提案は、何が未対応のまま残っているかを人に伝える保留リストから消え、作者ごとのフィードバック枠の集計も狂いました。

返信が問題をさらに広げました。インラインの返信は、スレッド最初のコメントの分類を引き継ぎます。そのため、マーカーを引用した提案があると、その下の返信までもが必須の指摘のように見えてしまいます。実際にはどちらも必須ではありません。

一箇所の書き間違いではなく、文字列一致による同じ判定が 16 回繰り返されていました。判定結果を使う場所がワークフローに三つあり（修正担当に何を頼むか、保留リスト、作者ごとの枠の集計）、それぞれがレビューコメント、インラインのスレッドの最初のコメント、返信の親コメント、Issue コメントの四種類を読みます。一箇所だけ直すと、ワークフローの中で判定が食い違ってしまいます。

新しい規則は、コメントのソースの冒頭だけを見ます。先頭の空白、HTML コメント、目に見えない Unicode の書式文字を読み飛ばしてから、マーカーを確かめます。空白として表示されうる HTML タグや文字参照をすべて見えないものとして扱うことは、意図的にしていません。ドキュメントも「表示された文字で判定する」とは言わず、この狭い規則をそのまま書くように改めました。

#9740 は、証拠の中に引用されたマーカーを無害化するようレビューボットにも指示しています。新しい誤判定は減りますが、過去のコメント、ほかのボット、メンテナー、今後コメントを書く別のツールまでは防げません。規則を置くべきなのは、ワークフローがこの信号を読む場所です。本物の Critical のコメントと、それを正しく引き継ぐ返信は、これまでどおり機能します。

16 箇所の判定はすべて同じ規則、つまり「コメントの冒頭にあるマーカーだけを数える」に従うようになりました。この規則は、判定を含む 9 個の独立した jq プログラム（ワークフロー 7 個、検証スクリプト 2 個）それぞれに一度ずつ書かれています。本文の後ろで引用されたマーカーは重要度を変えなくなり、冒頭の本物の Critical はこれまでどおり有効です。

レビューコメントを書くコードにも、対応する安全策を入れました。Critical の指摘を含んだままのコメントの前に、書き出しの一文、枠の説明、格下げの案内が挿入された場合は、短く目に見える Critical の見出しを先頭に加え、厳しくなった判定を引き続き満たすようにします。

テストは YAML とシェルのファイルから実際の jq プログラムを取り出し、見本のコメントで実行します。引用された証拠、直接のコメント、スレッドと返信の引き継ぎ、保留リスト、枠の集計を確かめます。後続のコミットでは、Critical を引用した見本をテスト間で共通化し、枠を超えたときの案内を「**[Critical]** を付ける」から「コメントを **[Critical]** で始める」に改め、設計ドキュメント review-tone.md、Autofix の説明、レビューボットの投稿手順を新しい規則に合わせました。古い書き方が戻らないよう、テストも一つ加えています。

Qwen Code では、モデルはツールを呼び出して作業を進めます。ツール名と JSON の引数を書くとプログラムがそれを実行し、結果がモデルに戻ります。send_message はそのツールの一つで、メインのエージェント（ユーザーではなくモデル自身）が、別のエージェントに追加の指示を送るときに使います。受け取った側はそれを作業として扱い、ファイルを編集したりコマンドを実行したりするので、送り先の取り違えは見た目だけの問題ではありません。

メインのエージェントが指示を出せる相手は二種類あり、どちらもバックグラウンドで並行して動きます。どちらも同じ Agent ツールで起動し、違いは名前を渡すかどうかだけです。名前を渡さなければ、一つの仕事のために起動される名前のないエージェントになり、バックグラウンドタスクの登録簿（BackgroundTaskRegistry）に記録されます。先に team_create でチームを作ってから名前を渡すと、qa-reviewer のような常駐のメンバーになり、TeamManager が管理するメンバー一覧に加わります。

この二種類が重なることはありません。メンバーはバックグラウンドタスクの登録簿に入らないので task_id を持たず、list_agents にも表示されません。名前のないバックグラウンドのエージェントには、to で指定できる名前がありません。両方の宛先を持つエージェントは存在しないので、正しい呼び出しでは二つの欄のどちらか一つだけを埋めます。

task_id という名前は誤解を招きます。宛先を別に添える必要のある「注文番号」ではなく、エージェント自身の番号で、起動したときに general-purpose-<接尾辞> のような形で返されます。バックグラウンドのエージェントは一つの仕事のためだけに存在するので、仕事の番号がそのままエージェントの番号になります。一方でチームにも担当者付きの作業項目（共有の task_list）があり、「タスク」という言葉が両方で使われているため、いっそう紛らわしくなっています。

修正前のツールは、一度の呼び出しで二つの欄を両方受け付け、先に task_id を見て、それが空のときだけ to を見ていました。決められた仕様ではなく、if/else の順番がそうなっていただけで、両方に値があるかどうかも確かめていませんでした。そのため、to: "qa-reviewer" と実在する task_id を同時に渡すと、メッセージはそのバックグラウンドのエージェントに届き、ツールは成功を返し、qa-reviewer には何も届きません。送り先を間違えたことはどこにも示されません。受け取ったエージェントはそれを作業として実行し、すでに終わっていた場合はこのメッセージで再び動き出します。

task_id が見つからない場合は「バックグラウンドタスクが見つかりません」というエラーになり、to が正しくても無視されました。qa-reviewer を両方の欄に入れた場合もこうなります。二つの欄が同じエージェントを表すと考えれば、ごく自然な書き方です。

メンバーの名前を task_id に入れると、必ず失敗します。メンバーはバックグラウンドタスクの登録簿に入らないからです。エラーの内容は正しいものの、向かう先を誤らせるものでした。バックグラウンドタスクの話しかせず、メンバーには触れず、どう直せばよいかも示しません。モデルから見ると、qa-reviewer は実際にバックグラウンドで動いているので、矛盾した答えにさえ見えます。list_agents で確かめても、メンバーは表示されないので役に立ちません。そこからモデルは再試行を繰り返したり、メンバーがいなくなったと考えて同じ作業をやり直したり、指示そのものをあきらめたりするかもしれません。元の報告にこうした経過は記録されておらず、コード上起こりえたことであって、観察された事実ではありません。

JSON Schema で必須なのは message だけで、宛先の二つのフィールドはどちらも任意でした。コードは「task_id を先に見て、次に to を見る」という順番を書いているだけで、本来守られるべき規則、つまり有効な呼び出しは二つのうち一つだけを選ぶ、ということは表していませんでした。

登録簿で見つからないと、メソッドはすぐに戻り、その値がメンバーの名前かどうかは確かめませんでした。TeamManager はメンバー一覧と名前の照合規則をすでに持っていたにもかかわらずです。

メンテナーが実際の CLI で一通り動かしたところ、もう一つの問題が見つかりました。テスト用のヘルパーは llmContent と returnDisplay を直接読めますが、ツールの呼び出しが失敗したとき、CoreToolScheduler がモデルに渡すのは error.message です。ヒントは正しく作られていても、このフィールドに書き込むまではモデルに届いていませんでした。

この規則は schema にそのまま書くことができません。send_message は以前、トップレベルの oneOf で二者択一を定めていましたが、そのせいで Anthropic のモデルではツール全体が使えなくなり（#7984）、oneOf は削除されました。そのため実行時に確かめるしかありません。

両方の欄が埋まっているかどうかの確認は、どのツールにもある引数検証の入口 validateToolParamValues に置きました。呼び出しが作られる前に実行されるので、曖昧な呼び出しは INVALID_TOOL_PARAMS で終わり、スケジューラ、タスクの待ち行列、TeamManager のいずれも配送を始められません。

BackgroundTaskRegistry で見つからなかったときに限り、現在のチームを調べます。既存の findMemberByName を使うので、"QA Reviewer" と書いても正式な qa-reviewer に対応づけられます。メンバー一覧に本当にいる場合だけ、to を使うよう案内します。

本番コードの最後の変更は一行です。一致した場合に、既存のヒントを error.message、つまり CoreToolScheduler が実際にモデルへ渡すフィールドに追加します。モデル提供元に渡す schema、SEND_MESSAGE_NOT_FOUND のエラー型、待ち行列、TeamManager の配送方法は変えていません。無関係な未知の task_id には、元のエラー文が一字一句そのまま返ります。