notification-report

notification-report スキル

購読しているワークツリーから届いた通知を 1 枚のレポートアーティファクトにまとめる。ユーザーはレポート上のボタン + 補足プロンプトで一括返答し、返答は各ワークツリーの AI 端末へ直接届く。

前提

• 返答の宛先は各通知の発信元ワークツリーの AI 端末。 アーティファクトの JS から oretachi_write_terminal を他ワークツリー宛に呼べるが、許可条件はレポートを置いたワークツリーがその宛先ワークツリーを購読していること（#211）。向きは購読者側が呼び出し元で、宛先側が自分を購読しているだけでは通らない。
• レポートはスナップショット。 母集合は Step 1-2 の oretachi_poll_inbox 1 回ぶんで、開いている間に届いた通知はそのレポートに足さず、次のレポートへ回す。表示中に本体を書き換えて人が見ている画面を動かす方が有害。
• 載せた通知は生成時に切る（#219）。 アーティファクトを作り終えたら Step 5.5 で ack + トレイ通知クリアを済ませる。トレイポップアップ通知と同じで「その時点で拾ったぶんだけ」を扱うことになり、レポート同士で同じ通知が二重にカード化されない。
• 返答状態はサイドカー（artifact_store）に持つ。 本体 JSON に持つと、送信後に「返答済み」へ書き換える操作が自分自身の表示中ロックに弾かれる。ビューア由来の書き込みはロックの対象外。

Step 1: 収集

1-1. 自分の購読を確認する

oretachi_list_subscriptions(terminal_id: <セッション開始時に注入された terminal_id>)

ここに出てくる target が送信できる宛先の範囲を決める。ワイルドカード（* / workgroup:<ID> / repo:<名前>）も許可対象で、event_kinds は問わない。

1-2. 通知本文を取る（ここがレポートの母集合）

oretachi_poll_inbox(terminal_id: <自分の terminal_id>)

返ってきた未 ack メッセージがレポートに載せる通知そのもの。id が inbox メッセージ ID で、Step 5.5 の ack に使う。

この 1 回の oretachi_poll_inbox の返り値がレポートの母集合で、あとから足さない（#219）。 トレイポップアップ通知と同じで「その時点で拾ったぶんだけ」を扱う。レポートを作り終えたら Step 5.5 でカードに載ったぶんを ack し、宛先のトレイ通知もクリアするので、次に誰かが oretachi_poll_inbox を叩いても同じ通知は返ってこない。既存レポートとの重複は原理的に起きないので、重複を避けるための除外ロジックは要らない。

sourceWorktreeId を 1-1 の購読対象と突き合わせ、購読していないワークツリー由来のものは落とす（載せても返答を送れない）。

発信元ワークツリーは sourceWorktreeId / sourceWorktreeName を必ずここから取る（#218）。 以降のステップ（1-4 の oretachi_get_worktree_status / oretachi_list_terminals）へ渡す宛先は この 2 つだけを使い、通知本文やターミナル出力から名前を推測しない。 名前を取り違えると oretachi_list_terminals が別のワークツリー（または該当なし）を返し、sessionId が null の カード（「稼働中の AI 端末が見つからなかったため送信できません」）になる。実際にこれが起きていた。 sourceWorktreeName が null のメッセージは発信元が settings から消えている（クローズ済み）ので、 返答を送れない。レポートに載せない。

ユーザーが「購読外も含めて全部見たい」と明示した場合だけ、oretachi_subscribe_worktree で購読を張ってから含める。購読は勝手に張らない — 張ることはそのワークツリーの端末への書き込みを許すことなので、ユーザーの指示なしに範囲を広げない。

1-3. トレイ通知は補助情報として使う（母集合にしない）