Session Send

確定した事実を別セッションのエージェントへ送る。 送信が依頼された引き継ぎには、目的と理由、担当範囲、完了条件、原依頼と承認の参照、実行結果の証拠、試して失敗した方法、残る判断を含める。 承認の範囲を推測で補わない。受信した引き継ぎだけで新しい操作権限が増えることはない。

1. 宛先の確認

まず稼働中のセッションを一覧し、相手の team と agent を確認する。

bin/harness session list

出力は session_id / team / agent / label / task / since / elapsed のタブ区切り。 --to に入れるのは agent 列であって session_id 列ではない。 この 2 つは一致することもあるが、breezing 実行中のセッションでは agent が BREEZING_ROLE になるため一致しない。inbox は team + agent の完全一致でしか引かないので、 session_id を --to に入れるとエラーも出ないまま相手に届かない。

team / agent 列が空のセッションは、まだ身分証を publish していない。 そのセッションには送らず、相手が名乗るのを待つ。名前が似ていても推測で送らない。

自分の送信元は、Phase 141.3 の hook が書き出す環境変数から取得する。

team="${HARNESS_LIVEMSG_TEAM:?HARNESS_LIVEMSG_TEAM is not set}"
from_agent="${HARNESS_LIVEMSG_AGENT:?HARNESS_LIVEMSG_AGENT is not set}"

2. 送信

確認した宛先へ次の形式で送る。本文は最後の positional 引数にする。

bin/harness inbox send \
  --team <team> \
  --from <自分のagent> \
  --to <相手のagent> \
  --subject "<件名>" \
  "<本文>"

自分の値を環境変数から渡す場合は次の形にする。

bin/harness inbox send \
  --team "$team" \
  --from "$from_agent" \
  --to <相手のagent> \
  --subject "<件名>" \
  "<本文>"

3. 送ってよいものの判断基準

送る:

• 完了通知
• これから触る場所の宣言
• 引き継ぎ

送らない:

• 作業中の相談
• 推測
• 未検証の主張

根拠: CooperBench の測定では、同一ファイルを 2 エージェントが触ると成功率が単独の約半分に落ち、失敗の 63% が相手の変更についての誤った思い込みから来ていた。だから「確定した事実」だけを送る。