ワークプレーン

このドキュメントの大部分は、エージェントが何に到達できるかを扱っています。アクセスマップ、権限、Permitted と Observed の間のドリフトです。このページが扱うのはもう一方の半分 — エージェントとセッションが作業そのものをどう調整するか — であり、これまでサイトの他の部分ではコマンドとイベントの一覧としてしか説明されてこなかった部分です。

この仕組みが解決する問題は仮定上のものではありません。このプロジェクト自身が開発中に苦しんできた問題そのものです。互いを見ることができないセッション、セッション間で分岐する状態、重複して行われる作業、1 人の端末にしか存在せず端末を閉じると失われる決定です。 アクセスを統制しながら作業について何も語らないコントロールプレーンは、その空白を元の場所に残したままにします。

作業項目とは何か

作業項目とは、所有者、状態、永続的な記録を持つ作業単位です。チャットメッセージでも、他者のトラッカーにあるチケットでもありません。監査 ledger と同じストアに存在するため、後から何が起きたかを、コントロールプレーンが記録する他のすべてと同じ手段で確認できます。

その周囲には 3 つのプリミティブがあります。

プリミティブ	機能
メッセージ	ある参加者が別の参加者へ、誰も読まないログにブロードキャストするのではなく、永続的に情報を伝える
確認応答	受信者がメッセージを引き受けたことを記録する。「既読」と「回答済み」は同じ意味ではなくなる
引き継ぎ	作業項目の所有権が移り、その理由も移動に添付される

確認応答には立ち止まって考える価値があります。調整が破綻するのは、メッセージが届かなかった場合よりも、見られたのに対応されなかった場合のほうがはるかに多いためです。この 2 つを区別できないシステムは、どちらが起きたかも伝えられません。

現時点で実在するものと、実在しないもの

1 · 調整は 1 つのワークフローに限定され、公開通信プレーンは意図的に配線されていません。 メッセージ、確認応答、引き継ぎは、そのワークフロー自身の実行内では実在します。あらゆるものを横断する一般的な通信プレーンは接続されていません。これは見落としではありません。起動テストが boot による配線を許される authority source を検証し、それ以外が現れると失敗します （cmd/olivares/communicationauthorityboot_test.go、 TestBootWiresExactCommunicationRequestAuthoritySourcesOnly）。誤って配線すれば、本番環境で驚く前にテストが赤くなります。

2 · エージェント間 dispatch は、承認済みの宛先がある場合にだけマウントされます。 リモート作業 executor は、その前段に承認ゲートを置いて構築されます（cmd/olivares/wire.go）。設定ファイルが丁寧に要求したというだけで、任意の peer に作業を dispatch する経路はありません。

3 · shadow モードと作業に対する最終権限は存在しません。 「近日提供」でも「一部実装」でもなく、欠如しています。現時点のデプロイメントは、セッションに対する最終決定権をワークプレーンへ渡せません。製品のどの部分も、その機能を提供していると解釈してはなりません。仮に実装されるなら、既存の情報源との比較期間という、機能することを示す証拠が必要です。バージョン番号を上げるだけでは足りません。

制限をここに記す理由

別のやり方では、利用者にとってさらに悪い結果になるからです。設計だけを説明し、統合時になって境界を発見させるページは、午後を丸ごと奪います。欠けている半分を「ロードマップ」と呼ぶページは、このプロジェクトが拒否する種類の主張になります。誠実さと限界のページが一般原則を示し、ここではその原則を製品の最新サーフェスへ適用しています。

次に見る場所

モジュール概要 — 他のモジュールの中でオーケストレーションが位置する場所。
オーケストレーションのリファレンス — ワークフロー実行を所有するモジュール。
イベントバスのリファレンス — ワークプレーンが発行するイベントを AsyncAPI コントラクトとして説明します。
ガバナンス下のワークフローを構築する — プレーンが行うことと行わないことを理解した後の実践的な手順。