sealbridge 0.2.2 → 0.3.0

package/README.ja.md

@@ -14,11 +14,13 @@ Windows PowerShell:
 irm https://sealbridge.dev/install.ps1 | iex
 ```
 
-インストーラーは現在のリリース sealbridge 0.2.1 を固定指定しており、同バージョンは npm で公開済みです。Node 22以上があれば `npm i -g sealbridge` または `npx sealbridge@latest` も使えます。
+インストーラーは npm で公開待ちの sealbridge 0.3.0 を固定指定しています。更新したインストーラーは npm 公開後にデプロイしてください。Node 22以上があれば `npm i -g sealbridge` または `npx sealbridge@latest` も使えます。
 
-ユーザー専用ディレクトリに導入し、Nodeが必要な場合は公式Node 22.22.0のチェックサムを検証します。秘密情報の入力・テレメトリー・管理者権限・Git・pnpmは不要です。macOS/Linuxでは新しいターミナルを開くか `. "$HOME/.profile"` を実行してください（パイプ実行では親シェルのPATHを変更できません）。Windowsでは現在と次回のPATHを設定します。`sealbridge doctor`、`sealbridge demo` で確認できます。doctorは中継器のヘルスチェックを1回行います。オフライン警告があってもインストールは保持します。
+Node 22 以上と同じインストール先の npm が正常に動く場合は再利用します。それ以外は既存の Node を変更せず、npm 同梱の Node をユーザー専用ディレクトリに導入します。Nodeが必要な場合は公式Node 22.22.0のチェックサムを検証します。秘密情報の入力・テレメトリー・管理者権限・Git・pnpmは不要です。macOS/Linuxでは新しいターミナルを開くか `. "$HOME/.profile"` を実行してください（パイプ実行では親シェルのPATHを変更できません）。Windowsでは現在と次回のPATHを設定します。`sealbridge doctor`、`sealbridge demo` で確認できます。doctorは中継器のヘルスチェックを1回行います。オフライン警告があってもインストールは保持します。
 
-インストーラーと `sealbridge doctor` は、Node 実行ファイルの解決済みパスとバージョンを表示します。Windows では、インストール先の npm ランチャーが使う Node を確認します。ランチャーと同じディレクトリにある `node.exe` が PATH より優先されます。macOS/Linux では PATH 上の Node を使います。doctor は自身を実行している Node を表示するため、後から PATH を変更すると結果が変わる場合があります。正常な項目は短い `(OK)` 行で表示し、対処方法は `(WARN)` 行だけに表示します。ワーカー鍵がなくても正常です。タスクを受け取る前に `.acp` ディレクトリを作成して `sealbridge keygen "$HOME/.acp/worker.private.json"` を実行するか、`--key` で既存の鍵を指定してください。
+リリース注記：次の機能は sealbridge npm パッケージの 0.3.0 から利用できます。CLI 0.2.2 以前では対応していません：`doctor --offline`。
+
+インストーラーと `sealbridge doctor` は、Node 実行ファイルの解決済みパスとバージョンを表示します。Windows では解決済み Node と同じ場所に npm が必要です。macOS/Linux では Node と同じディレクトリの npm ランチャーが npm の JavaScript エントリーを指している必要があります（シンボリックリンク対応）。その Node で npm を直接実行します。Windows のコマンドと PowerShell ランチャーは選択した Node を固定し、macOS/Linux のランチャーは PATH の先頭に置いた Node を使います。doctor は自身を実行している Node を表示するため、macOS/Linux で後から PATH を変更すると結果が変わる場合があります。正常な項目は短い `(OK)` 行で表示し、対処方法は `(WARN)` 行だけに表示します。鍵は初回使用時に作成します。インストーラーと doctor は鍵を生成しません。`sealbridge doctor --offline` は中継器へ接続せずローカル設定を検査します。
 
 削除はスクリプトを保存して `sh install.sh --uninstall` または `& ./install.ps1 -Uninstall`（PowerShellでの --uninstall 表記）を実行します。鍵は保持します。Unixではシェル設定の `# sealbridge installer` 行も削除してください。npmのみの導入は `npm uninstall -g sealbridge` で削除できます。保存先は `~/.local/share/sealbridge` と `%LOCALAPPDATA%\Sealbridge` です。
 
@@ -43,8 +45,12 @@ irm https://sealbridge.dev/install.ps1 | iex
 [![License](https://img.shields.io/badge/License-Apache_2.0_%2F_MIT-blue.svg)](./LICENSE)
 [![X (@takapon01234)](https://img.shields.io/badge/X-%40takapon01234-000000?logo=x)](https://x.com/takapon01234)
 
-> **ステータス**: Sealbridge の最新リリース `v0.2.1` は npm パッケージ `sealbridge` として公開済みです。以前の `v1.0.0` 表記は Sealbridge 改称前の ACP / agent-collab-platform の旧リリースを指し、Sealbridge の npm リリースではありません。
-> **目的**: 異なる所有者の自律エージェントが、相手のランタイムや認証情報を信頼せずに、仕事の分割・委譲・実行・検証・検収を行うためのオープンソースのプロトコルと参照実装です。  
+[![Sealbridge のデモ：インストール、コードレビューの依頼、署名付き結果の受領、監査ログの確認（英語字幕付き）](docs/media/sealbridge-demo.gif)](docs/media/sealbridge-demo.mp4)
+
+30秒のデモ、音声なし — [MP4を見る](docs/media/sealbridge-demo.mp4)。
+
+> **ステータス**: Sealbridge `v0.3.0` を npm パッケージ `sealbridge` としてリリース準備中で、公開待ちです。以前の `v1.0.0` 表記は Sealbridge 改称前の ACP / agent-collab-platform の旧リリースを指し、Sealbridge の npm リリースではありません。
+> **目的**: 異なる所有者の自律エージェントが、相手のランタイムや認証情報を信頼せずに、仕事の分割・委譲・実行・検証・検収を行うためのオープンソースのプロトコルと参照実装です。
 > **作成者**: [@takapon01234](https://x.com/takapon01234)
 
 - CI では、967件の自動単体・統合・適合性テスト（`pnpm test`）と、敵対的セキュリティテストスイート（`pnpm test:security-proof`）を実行します。
@@ -63,26 +69,168 @@ irm https://sealbridge.dev/install.ps1 | iex
 git clone https://github.com/sealbridge/sealbridge.git && cd sealbridge && pnpm install --frozen-lockfile && pnpm build && pnpm sealbridge demo
 ```
 
-**Claude Desktop**、**Cursor**、**Codex**、**Grok Bot** から MCP サーバー（`sealbridge mcp-server`）として直接呼び出す場合の設定例：
+### ローカルホスト設定
+
+リリース注記：次の機能は sealbridge npm パッケージの 0.3.0 から利用できます。CLI 0.2.2 以前では対応していません：`setup`、`accept`。
+
+このコマンドを含むリリースでは `sealbridge setup --help` を確認し、
+`sealbridge setup --host cursor` または `sealbridge setup --host claude-desktop`
+（macOS/Windows）を実行します。`setup` だけなら検出したユーザーホストが1つのときに選択し、
+複数なら端末で選びます。`--host` の繰り返し、`--all-detected` にも対応します。
+Claude Code は `--host claude-code --project` と絶対パスが必須です。
+`--dry-run` は計画、`--print` は登録案だけを表示し、どちらも書き込みません。
+ソース版は先にビルドし `node cli/dist/index.js setup` を使います。
+
+setup は依頼者鍵（`--worker` ならワーカー鍵も）を作成・再利用し、既存の
+`config.json` の relays 形式で既定値を記録します。絶対パスの Node/CLI で
+`mcp-server --require-approval` を登録し、送信前と最終検収時にホストのフォーム
+elicitation を要求します。ホストの対応状況はオフラインでは検出できず、非対応なら
+送信前に `APPROVAL_CHANNEL_UNAVAILABLE` を返します。明示的に
+`--no-require-approval` を指定すると従来の `mcp-server` を登録し、ホストは
+依頼ごとの確認なしに送信し、最終結果を自動承認できます。適用時・`--dry-run`・
+`--print` は登録ごとの承認モードを表示します。通信もプロセス起動もしません。
+`--relay URL` は代替既定値の記録で、保存済みの先頭と異なれば停止します。
+既存の Sealbridge 登録も完全一致が必要です。承認モードが異なる登録は
+`SETUP_APPROVAL_MODE_CONFLICT` で停止し、変更しません。
+`--update-existing --dry-run` または `--update-existing --print` で確認後、
+`--update-existing` で Sealbridge 登録だけを置換できます。従来の登録を維持するには
+`--no-require-approval` を指定します。設定画面を閉じて適用してください。
+変更する既存ファイルの原文を `<data-root>/setup/backups` に保存します。
+バックアップはホストの資格情報を含む場合があります。複数ファイルは一括確定できません。
+部分失敗なら結果を確認し、原因を解消して再実行します。ホストを再読込しツールを確認してください。
+登録だけでは仕事を承認せず、ホストの動作確認は別途必要です。setup を実行しなければ
+既存設定は変わらず、同じオプションで再実行しても変更しません。
+
+[エージェント向け手順](sites/connect-agent.txt) に、人間が実行する
+`sealbridge accept --paste` と `acp_list_invites`/`workerRef`、または
+`acp_discover_workers` から返った `workerDid` と `relayUrl` を
+`acp_delegate_task` へ渡す手順を記載しています。招待取込・オープン検索には
+それぞれ対応するリリースが必要です。help とツール一覧を確認してください。
+ホスト設定は厳密な JSON のみ対応し、TOML/JSONC は今後の対応です。
+
+`mcp-server`、`delegate`、`worker start`、`discover`、`invite create` は `--key` と `--relay` を省略できます。既定の中継器は `https://relay.sealbridge.dev` です。MCP の初期化・ツール一覧は通信せず、検索は公開ディレクトリを取得し、依頼は暗号化したタスクを送ります。中継器には経路メタデータが見えます。招待作成はローカル署名のみで、ワーカーを起動しません。
+
+鍵は `<data-root>/identities/requester.private.json` と `worker.private.json` に保存し再利用します。MCP と delegate は依頼者、worker start と CLI の招待作成はワーカーの鍵を使います。MCP の署名ツールはサーバーの依頼者鍵（または明示した鍵）を使います。MCP は必要になるまで鍵を読み込みません。保存先は絶対パスの `SEALBRIDGE_DATA_DIR`、次に `ACP_DATA_DIR`、未指定なら Windows は `%LOCALAPPDATA%\Sealbridge`（代替: home/AppData/Local）、macOS は `~/Library/Application Support/Sealbridge`、Linux は `$XDG_DATA_HOME/sealbridge`（代替: `~/.local/share/sealbridge`）です。
+
+POSIX ではディレクトリ 0700・鍵 0600 とし、所有者・種類・モードを検査します。Windows は LOCALAPPDATA 配下の DACL を継承します。Node のモードはユーザー限定 DACL を設定せず、この版では ACL を検証しません。保存先を変更した場合は親のアクセス設定を継承するため、利用者が管理します。検出可能なリンク・通常ファイル以外は拒否します。ただし macOS の root 所有の `/var`・`/tmp` から対応する `/private` ディレクトリへのリンクは認めます。同じディレクトリ内のハードリンクが使えない場合は `IDENTITY_CREATION_UNSUPPORTED` です。
+
+既定の鍵がない場合、役割に一致する `~/.acp/{requester,worker}.private.json` と旧 contacts 保存先の `owner.private.json`（依頼者のみ）を元の場所で再利用します。異なる依頼者鍵が競合すると `IDENTITY_SELECTION_REQUIRED` になるため `--key` で選択してください。既定保存先の鍵を優先し、不正・読取不可の鍵を置換しません。`keygen <path>` は未使用の明示パスへの作成専用です。
+
+リリース注記：次の機能は sealbridge npm パッケージの 0.3.0 から利用できます。CLI 0.2.2 以前では対応していません：`config key-store`、`doctor --offline`。
+
+秘密鍵の既定保存先はファイルです。`sealbridge config key-store` は有効な方式と選択元を表示し、`sealbridge config key-store file|keychain` は version 1 の `<data-root>/config.json` に中継器設定とともに `"keyStore"` を保存します。優先順位はプログラム指定 > `SEALBRIDGE_KEY_STORE` > config > 既定の file です。`--key <path>` は常にファイルを指定します。設定時は利用可否を確認し、他方式に既存の鍵があれば表示します。鍵の移動・作成・削除は行いません。他の設定項目を保持し、同じ値の再設定では既存バイト列を維持します。保存後も環境変数の指定が優先されます。
+
+`--key` 省略時、board post/serve/dispatch は requester、board claim は worker、contacts・invite open・invite request-reissue は requester、invite reissue は worker を使います。既存の明示ファイル読込と MCP ツール名は維持します。board 一覧・contacts 一覧・MCP 一覧では鍵を作成しません。contacts ファイルと返信招待の既定ディレクトリは従来どおりです。invite open は旧 requester ファイルを含む役割の鍵を再利用し、初回は選択した方式に従います。ファイル方式の出力は `local.keyFile`、keychain 方式はファイルパスの代わりに `local.keyStore` と `local.role` を含みます。`invite share` は鍵ストアへアクセスしません。
+
+keychain 方式は任意の [`@napi-rs/keyring`](https://github.com/Brooooooklyn/keyring-node)（MIT ライセンス、2.x の 2.1.2 以降）を動的に読み込みます。Sealbridge と同じ場所に `npm install --no-save --package-lock=false --prefix /path/to/sealbridge @napi-rs/keyring@^2.1.2`、ソースチェックアウトでは `pnpm --filter @acp/runtime add --optional @napi-rs/keyring@^2.1.2` で導入します。グローバル導入だけでは足りず、runtime モジュールから解決できる必要があります。Linux では Secret Service を指定し、メモリ内だけのストアは選択しません。ネイティブ配布物には依存ライブラリのライセンス表記も含まれます。
+
+保存内容は Ed25519 の秘密 JWK JSON で、`kid` に公開 DID を格納します。サービス名は `sealbridge:<正規化した絶対データルートの SHA-256>`、アカウント名は `requester` / `worker` です。作成時に鍵ファイルは書かず、データルート内で鍵情報を含まない一時的な `.keychain-<role>.lock` を使います。同時作成は `KEY_STORE_BUSY` です。終了時にロックが残った場合は、書込プロセスを閉じてから手動で削除します。
+
+明示した keychain を利用できない場合は `KEY_STORE_UNAVAILABLE` とし、ファイルに切り替えません。未指定時はファイルが既定ですが、資格情報ストアを検査でき、keychain に同じ役割の鍵があれば明示選択が必要です。ファイルもあれば `KEY_STORE_CONFLICT`、なければ `KEY_STORE_SELECTION_REQUIRED` です。明示選択はどちらの鍵も移動・削除しません。モジュールやストアへアクセスできない未設定環境ではファイル動作を維持し、keychain の存在は検査できません。自動移行は行いません。`sealbridge doctor --offline` は鍵を生成せず中継器に接続せずに、方式・選択元（`option`・`env`・`config`・`default`）・場所・鍵の有無を表示します。OS の資格情報アクセス画面が出る場合があります。
+
+組み込みアプリは runtime の `KeyStore`（`load`、`createIfMissing`、`exists`、`describe`）を実装し、`AcpMcpServer` に `identityOptions: { keyStore: myStore }`、または `resolveStoredIdentity` / `inspectStoredIdentity` に `{ keyStore: myStore }` を渡せます。値または Promise を返せます。`createIfMissing` は既存の鍵を保持し、`describe` は方式・場所のメタデータのみを返します。`FileKeyStore` は既存のファイル実装を使用し、同期 API の `resolveOrCreateIdentity` / `inspectLocalIdentity` はファイル専用のままです。
+
+明示した `--relay` は接続先を固定します。未指定なら検証済み招待の中継器が公開既定値より優先されます。明示の許可リスト（プログラムの空リストを含む）と注入した transport の優先順位は維持します。ループバック接続には引き続き `--allow-private-relay` が必要です。
+
+
+リリース注記：次の機能は sealbridge npm パッケージの 0.3.0 から利用できます。CLI 0.2.2 以前では対応していません：`accept`、`invites`、`acp_list_invites`、`acp_remove_invite`。
+
+招待はモデル実行の外で、ご自身でターミナルに保存します。
+
+```sh
+sealbridge accept "https://sealbridge.app/i#acp-invite:..." --alias reviewer
+# または人が操作する TTY で貼り付けます:
+sealbridge accept --paste --alias reviewer
+# またはファイル・アプリからのパイプで読み込みます:
+sealbridge accept --stdin --alias reviewer < invitation.txt
+sealbridge invites list
+```
+
+ホストには `acp_list_invites {}` を呼び出してもらい、返された `saved:…` の参照または正確な別名を
+`acp_delegate_task {"workerRef":"reviewer","title":"Review diff","description":"Review these changes","input":{"diff":"..."}}`
+に渡します。モデルに招待トークンを渡す必要はありません。招待ページはローカル検証後に accept コマンドを表示します。
+保存時は通信せず、相互招待や連絡先の承諾権限を作成しません。仕事の承認にもなりません。
+依頼時は設定済みの承認方針に従い入力を外部へ送信します。名前・説明は表示データとして扱います。
+
+招待の所持者は期限または失効まで提案を送れる場合があります。署名付き保存先は
+`<data-root>/invites/<sha256-local-owner-DID>.json` です。CLI と MCP は同じ端末・OS アカウント・
+データルート・依頼者鍵を使います。リモート MCP の場合はその端末で保存してください。
+POSIX はディレクトリ 0700・ファイル 0600、Windows は親の DACL を継承し ACL は検証しません。
+上書き保存先の親アクセス権はユーザーが管理します。位置引数のリンクはシェル履歴やプロセス一覧に
+残る場合があります。`--paste` は人の TTY を必須とし、argv・シェル履歴へのリンクの記載を避けますが、
+端末履歴を消去しません。非 TTY は直ちに `INVITE_INPUT_UNAVAILABLE` を返します。
+
+`--stdin` はパイプ・ファイルからリンクを EOF まで読みます（68 KiB、読み取り全体で 10 秒）。
+アプリは `sealbridge accept --stdin --alias reviewer` を起動し、子プロセスの stdin にリンクを
+書き込んでパイプを閉じます。前後の空白・CRLF と空行を除き、空入力・複数の非空行は拒否します。
+TTY は `INVITE_STDIN_REQUIRES_PIPE` を返すため、端末では `--paste` を使ってください。
+位置引数・`--paste`・`--stdin` は併用できません。入力リンクや読み取りエラーの内容は出力しません。
+既存のトークンを含まない JSON 出力には `alias`、`workerRef`、`agentDid`、`displayName`、
+`effectiveExpiresAt` が含まれます。JSON 用の追加フラグは不要です。
+
+別名は先頭が英数字の ASCII 英数字・ハイフン・アンダースコア 1–64 文字で、大文字小文字を区別します。
+省略時は表示名と安定したダイジェスト接尾辞から生成します。同一招待の保存は冪等で、別名の衝突は
+`ALIAS_EXISTS` です。期限切れも一覧に残りますが依頼には使えません。更新は明示的に
+`sealbridge invites remove reviewer`（または `acp_remove_invite {"workerRef":"reviewer"}`）後に再保存します。
+削除はローカルで冪等です。発行者の招待やワーカーの受諾設定は変更しません。
+排他ロックと同一ディレクトリの一時ファイルで置換します。`INVITE_STORE_BUSY` は既存ロックを削除しません。
+書き込みプロセスが動いていないことを確認後、ご自身で対応する `<store-file>.lock` を削除して再試行できます。
+
+保存する招待トークンにも共通の key-store 選択（プログラム指定 > 環境変数 > config > file）を適用します。
+file 方式では従来の署名付き JSON 形式とバイト列を維持します。keychain 方式の新規項目は署名付き
+メタデータに `inviteSecret` 参照と `tokenDigest` を記録し、トークンは同じデータルート別サービスの
+`invite:<entry id>` アカウントへ保存します。既存のインライン項目は自動移行せず読み込めます。
+file に戻しても既存参照は keychain から解決し、新規保存はインラインに戻ります。一覧や MCP の結果に
+トークンを含めません。利用不能は `KEY_STORE_UNAVAILABLE`、文字列の欠落・不一致は
+`INVITE_SECRET_MISSING`・`INVITE_SECRET_MISMATCH` とし、ファイルに切り替えません。
+削除は参照先の文字列の削除と欠落確認を先に行い、その後にメタデータを置換します。
+`INVITE_SECRET_DELETE_FAILED` ではメタデータを維持し、同じ別名・参照で `remove`・
+`invites remove`・`acp_remove_invite` を再実行できます。文字列削除後に置換が失敗すると
+解決は `INVITE_SECRET_MISSING` になりますが、削除の再実行は文字列なしで完了できます。
+
+既存の依頼者鍵を使い、明示的にインラインのトークンを移行できます。
+
+```sh
+sealbridge invites migrate --to keychain --dry-run
+sealbridge invites migrate --to keychain
+# 必要なら既存の依頼者ファイルを指定:
+sealbridge invites migrate --to keychain --key /path/to/requester.private.json
+```
+
+dry run は書き込まず対象件数を表示します。適用時は全件の書込・読戻しを確認してから、トークンを
+含まない署名付きメタデータへ一括置換します。失敗時は元のメタデータファイルを維持します。
+失敗前に書いた文字列が残る場合は再実行時に再利用します。方式の設定や依頼者鍵は変更しません。
+参照・別名・保存日時は維持します。組み込みアプリは同期の `SecretStore.get/set/delete` を
+`InviteStoreOptions.secretStore` または MCP の `identityOptions.secretStore` に注入できます。
+設定したネイティブ方式は `await InviteStore.open(owner, options)` で読み込みます。
+`new InviteStore(owner, options)` は同期のファイル・注入方式 API を維持します。
+独自の identity `KeyStore` だけを注入した場合はインライン保存を維持し、外部保存には別途
+`secretStore` を指定します。明示した鍵ファイルは署名者の選択にのみ使い、招待には共通の方式選択を適用します。
+
+組み込みでは `store.import(link, alias, { pendingConfirmation: true })` で確認待ちとして保存できます。
+`SavedInvite.importState` は `unconfirmed` になり、`listUnconfirmed()` はトークンを含まない情報を返します。
+`removeUnconfirmed({ olderThan: timestamp })` は日時より厳密に古い確認待ちだけを削除し、`{ removed }` を返します。
+使う前に `retain(workerRef)` で保存を確定します。それまでは `resolve` が `INVITE_CONFIRMATION_REQUIRED` を返します。
+通常の import（重複を含む）も保存を確定し、確認待ちとしての再取込は過去の保存を変更しません。
+`connections confirm-invite` は接続確認の試行前に保存を確定します。拒否・中断時も保持し、所有者の同意確認は別に行います。
+マーカーがない既存項目は整理の対象外です。これらのメソッドは通信しません。
+再試行と組み込み時の契約は[招待のライフサイクル](docs/connections/invite-lifecycle.ja.md)を参照してください。
+
+中継器の既定候補は `<data-root>/config.json` に保存できます。
 
 ```json
 {
-  "mcpServers": {
-    "sealbridge": {
-      "command": "node",
-      "args": [
-        "/path/to/sealbridge/cli/dist/index.js",
-        "mcp-server",
-        "--key",
-        "/tmp/alice.private.json",
-        "--relay",
-        "https://relay.sealbridge.dev"
-      ]
-    }
-  }
+  "version": 1,
+  "relays": ["https://relay.sealbridge.dev", "https://relay.example"]
 }
 ```
 
+ファイルがない場合は `{ "version": 1, "relays": ["https://relay.sealbridge.dev"] }` をメモリ内で使い、読取時にファイルや鍵を作成しません。CLI の通信操作と MCP の中継器操作で読み込み、MCP の初期化・ツール一覧では読み込みません。保存先とファイルには鍵ストアと同じ権限を使います（POSIX では 0700/0600）。
+
+ローカル候補は先頭だけを使います。残りの候補へ通信・登録せず、HTTP 401 を含む失敗後にも切り替えません。フェイルオーバー、複数中継器への送信、並列検索、別中継器への自動再送はありません。選択順序は注入した transport、明示の固定先、検証済み招待、ローカル候補の先頭、組込み既定値です。招待の中継器は候補リストに含まれていなくても選べますが、既存の許可リストは引き続き適用し、候補によって拡張しません。カード・招待・マニフェスト・検索結果・監査経路は単一の URL を維持します。
+
+候補の URL は origin と pathname（末尾スラッシュなし）に正規化し、順序を維持して重複を除きます。通信前に全候補をローカル検証し、不正・読取不可の設定では操作を停止します。互換形式 `{ "version": 1, "relay": "https://relay.example" }` は単一候補として受け入れ、読取で書き換えません。矛盾する `relay` と `relays` は拒否します。既存の CLI `--relay`、MCP `relayUrl`、コンストラクターの `relay` は単一値のままです。設定管理コマンドや MCP 引数の追加はありません。
+
 MCP ホストは、信頼できないツール引数を渡すことがあります。`--allow-worker`、`--allow-relay`、そして `--require-approval` または `--approval-webhook` を付けて、プロンプト注入でタスク入力が任意のワーカーや中継器へ送られないようにします。フラグの説明は下の MCP の節にあります。
 
 ## 1画面サマリ
@@ -159,16 +307,16 @@ pnpm build
 
 公開中継器は非信頼の転送路です。セッションのペイロードは受信者の `did:key` へ暗号化され、中継器が保存するのは暗号文です。経路のメタデータは見えたままです。`decryptEnvelopePayload`、`WorkerNode`、`RequesterClient`、`VerificationEngine` は、既定で暗号化された封筒を要求します（`requireEncrypted: true`）。平文のセッション封筒は `UNENCRYPTED_ENVELOPE_REJECTED` で拒否されます。`{ requireEncrypted: false }` と `allowUnencryptedEnvelopes: true` は、呼び出し側が明示したときだけ平文を開き、レガシーのメモリ内フィクスチャ向けです。自前で動かす場合は `packages/relay/wrangler.toml.example` を `packages/relay/wrangler.toml` にコピーし、自分の Wrangler アカウントでデプロイします。ワーカーは受信者ごとの受信箱を別々の Durable Object（`inbox:<recipientDid>`）に分け、エージェントカードは専用の `registry` オブジェクトに置きます。
 
-キューに入ったエンベロープは10分で期限切れになります。再生キャッシュとエージェントカードは1時間で期限切れになります。受信箱の上限は256件、1件256 KiB、合計4 MiBです。`POST /envelopes`、`GET /envelopes`、`POST /agents` は送信元IPごとにレート制限されます（既定は1分あたり300リクエスト）。バイト予算またはレート制限を超えると HTTP 429 を返します。既存の中継器へ新しいビルドを載せる前に、下のデプロイ手順を読んでください。
+新しく受理する封筒の保持期間は既定24時間です（`ACP_ENVELOPE_TTL_MS` またはローカルの `--envelope-ttl-ms`）。更新前に保存した期限は維持します。再送記録とエージェントカードは1時間で期限切れになります。再送記録の期限切れ・入替後も、キュー内に同じ ID があれば拒否します。両方の記録がなくなった後の再送履歴は保持しません。受信箱の上限はリース中も含め256件、1件256 KiB、合計4 MiBです。送信者ごとの上限は宛先ごとに既定256件です。キュー・全体容量や送信者の件数による一時拒否は HTTP 429、`{"error":"RELAY_RETRY_LATER","retryable":true,"retryAfterMs":60000}`、`Retry-After: 60` を返し、その封筒を保存しません。1件または宛先のバイト上限に単体でも収まらない封筒は恒久エラーの HTTP 400 です。既存クライアントは送信を自動再試行せず `RELAY_REJECTED: 429` を返します。[保持と受理の設定](docs/relay-reliability.ja.md#保持と受理)を参照してください。`POST /envelopes`、`GET /envelopes`、`POST /agents` は送信元IPごとにレート制限されます（既定は1分あたり300リクエスト）。レート制限は従来の HTTP 429 を維持します。既存の中継器へ新しいビルドを載せる前に、下のデプロイ手順を読んでください。
 
 **自前中継器のデプロイ**
 
-進行中の通信が空になるまで、この変更を稼働中の中継器へデプロイしないでください。以前のビルドは、すべてのキューとエージェントレジストリを `acp-relay` という1つの Durable Object に、1つの JSON スナップショットとして保存していました。このビルドはそのオブジェクトを読みません。
+公開中継器で既定値・受理応答を変えるには、運用者による Worker のデプロイ・設定更新が必要です。この変更ではデプロイしません。ローカル・組み込みの中継器は更新後に新しい既定値を使います。現在の宛先別受信箱は保存済み期限・クラス名・マイグレーションタグを維持します。宛先別に分ける前の版を置き換える場合は、先に通信を排出してください。その版の単一 `acp-relay` オブジェクトは現在のワーカーから読みません。
 
-1. 送信を止めるか、少なくとも15分待って、キュー内のエンベロープを期限切れにし、受信側に再送させてください。
+1. 宛先別に分ける前の版では送信を止め、キューを排出するか、設定した保持期間を待ちます。配置を変える前に古いキューが空であることを確認してください。
 2. `packages/relay/wrangler.toml.example` を `packages/relay/wrangler.toml` にコピーし、自分の Wrangler アカウントでデプロイします。`pnpm --filter @acp/relay exec wrangler deploy`
-3. エージェントは次の起動時に再登録します。古いオブジェクトに残った未配送のエンベロープは移行されないので、クライアントが再送します。
-4. Worker に任意で置ける環境変数は `ACP_RATE_LIMIT_MAX`、`ACP_RATE_LIMIT_WINDOW_MS`、`ACP_MAX_ENVELOPE_BYTES`、`ACP_MAX_QUEUE_SIZE`、`ACP_MAX_QUEUE_BYTES`、`ACP_ENVELOPE_TTL_MS`、`ACP_SEEN_TTL_MS`、`ACP_AGENT_CARD_TTL_MS` です。任意の `RATE_LIMITER` バインディングは、アイソレート内のウィンドウに加えて検査されます。
+3. エージェントは次の起動時に再登録します。古いオブジェクトの未配送の封筒は移行されません。必要な再試行は呼び出し側が明示的に行います。
+4. Worker に任意で置ける環境変数は `ACP_RATE_LIMIT_MAX`、`ACP_RATE_LIMIT_WINDOW_MS`、`ACP_MAX_ENVELOPE_BYTES`、`ACP_MAX_QUEUE_SIZE`、`ACP_MAX_QUEUE_BYTES`、`ACP_MAX_ENVELOPES_PER_SENDER`、`ACP_ENVELOPE_TTL_MS`、`ACP_SEEN_TTL_MS`、`ACP_AGENT_CARD_TTL_MS` です。任意の `RATE_LIMITER` バインディングは、アイソレート内のウィンドウに加えて検査されます。
 
 Durable Object のクラス名は変わらないので、例にある `v1` マイグレーションはそのまま使えます。新しいオブジェクト名は、同じクラスの別インスタンスです。古い `acp-relay` インスタンスは、参照が残っていないことを確認してから Wrangler で削除できます。
 
@@ -195,6 +343,28 @@ pnpm sealbridge worker start --key /tmp/bob.private.json \
 
 `sealbridge worker` は `--publish` を付けない限り、公開リレーのディレクトリへ AgentCard を登録しません。招待トークンを直接渡してください。`sealbridge discover` に出るのは `--publish` したワーカーだけです。
 
+ワーカー起動時の標準出力は従来どおり、1行目がトークン、2行目が HTTPS 招待リンクです。
+`--invite-output none` で両方を省略できます。`--invite-output file:/absolute/path/invite.txt`
+または `--invite-output fd:3` は、トークンと改行だけを別の出力先へ渡し、標準出力には複製しません。
+ファイルは未使用パスへモード `0600` で排他的に作成します。親ディレクトリは事前に作成し、
+POSIX では現在のユーザーが所有し、グループ・他ユーザーの権限を付けないでください（通常 `0700`）。
+既存ファイルと検出可能なリンクは拒否します。Windows は親の ACL を継承し、ACL は検証しません。
+`fd:<n>` は POSIX 専用です。Windows では引数解析時に `INVITE_OUTPUT_FD_UNSUPPORTED_PLATFORM` で
+拒否し、鍵の作成・リレーへの登録・待受開始は行いません。Windows の Node が継承する追加の stdio
+パイプは、同期ファイル書き込みに使える通常のファイル記述子ではありません。
+Windows で招待を別の出力先へ渡すには `file:<path>` を使ってください。
+継承する記述子は 2 より大きく、パイプ・ソケット・ファイルを指定します。ファイルは
+現在のユーザーが所有し、グループ・他ユーザーの権限がないことが必要です。出力先と寿命は親プロセスが
+管理し、ワーカーは記述子を閉じません。配送に失敗すると `INVITE_OUTPUT_UNAVAILABLE` で停止し、
+招待の表示と待受開始は行いません。
+
+すべてのモードで、招待の配送（または省略）後、待受開始前に stderr へ `invite_ready` JSON を1行出します。
+フィールドは `event`、`inviteDigest`（`sha256:` とトークンの完全な16進ダイジェスト）、
+`expiresAt`（ISO 日時）、`workerDid`、`relay` です。トークンや招待リンクは含みません。
+このイベントは中継器への接続完了を表しません。状態・イベント JSON は共通のフィールド選択処理を使い、
+診断キーとダイジェストを維持し、認識しない自由形式の値を `[redacted]` に置き換えます。
+承認プロンプトと、明示的に有効にした受信箱・受信フックの内容は従来どおりです。
+
 `--inbox /path/to/inbox.jsonl` を指定すると、対話エージェント向けの受信箱を保存します。
 提案の検証と受諾承認後、実行前に復号済みの `{ receivedAt, taskId,
 requesterOwnerDid, requesterAgentDid, title, description, input }` を1行ずつ追記します。
@@ -212,10 +382,149 @@ DID による検索は `agentDid` の完全一致を `ownerDid` の別名一致
 
 `--max-input-tokens`、`--max-output-tokens`、`--max-tool-invocations`、`--max-wall-clock-seconds` は、ワーカーが受ける契約の上限です。どれかを超える提案は、`--auto-accept` でも `ACCEPT` の前に拒否されます。マニフェストの `timeoutSeconds` は `--max-wall-clock-seconds` と比較します。`--max-concurrent-tasks` は同時実行数の上限です（既定は 8）。`--max-requests-per-minute` は、依頼者 DID ごとの提案回数の上限です。
 
-`--allow-requester <did>` は繰り返せます。カンマ区切りでも指定できます。`--allow-any-requester` は、すべての依頼者を明示的に許可します。`--adapter claude`、`codex`、`openai` で `--auto-accept`（および `--auto-approve` / `--yes`）を使うときは、どちらかの許可フラグが必要です。公開ディレクトリから見つかったワーカーが、持ち主の API キーを任意の依頼者に使わせないためです。上の sandbox 例に許可リストは不要です。
+`--allow-requester <did>` は対象を制限するだけで、信頼を付けません。すべての limited の依頼に検査と所有者が開く操作が必要です。CLI contacts の明示的な信頼は独立して維持します。
+
+### つながりによる受付
+
+[English](docs/connections/admission.md)
+
+リリース注記：次の機能は sealbridge npm パッケージの 0.3.0 から利用できます。CLI 0.2.2 以前では対応していません：`requests`、`accept`、`connections`、`pending`、`worker start --allow-task-type`、`acp_list_connections`、`acp_list_connection_requests`。
+
+状態は所有者の端末ごとの `none`・`pending`・`connected`・`blocked` です。
+connected は期限なしの limited 同意です。すべてのアダプターで、limited の依頼は
+検査完了と所有者が開く操作を経てから受諾します。自動承認方針では省略できません。
+既定の検査器は `unavailable` を返すため、内容は保留のままです。公開リリース前に
+検査プロバイダーが必要です。
+
+未接続の相手からの有効な依頼は、暗号化済み封筒として最大24時間または依頼の期限まで
+保存し、終端の `PENDING_OWNER_APPROVAL`・`retryable:false`・CLI 終了値3を返します。
+自動再試行はしません。署名・スキーマ・能力・申告予算・公開スキル・運用者の制限は
+保存や招待の結び付けより前に確認します。新しい受付情報には題名・説明のプレビューを
+保存しません。未検査の `requests show` は `INSPECTION_INCOMPLETE` です。
+平文の受信箱と受信フックは、検査と所有者が開く操作の後だけ使います。
+
+```sh
+sealbridge worker start --adapter sandbox --publish --allow-task-type json --max-input-tokens 50000
+sealbridge discover --skill json-task
+sealbridge requests list
+sealbridge requests show REQUEST_ID
+sealbridge requests approve REQUEST_ID
+sealbridge requests discard REQUEST_ID
+sealbridge requests deny REQUEST_ID
+```
+
+`--publish` はディレクトリへの掲載だけを行います。未掲載のワーカーも同じ受付規則です。
+`--allow-requester` は対象を制限するだけで信頼を付けません。予算は
+`--max-input-tokens`・`--max-output-tokens`・`--max-tool-invocations`・
+`--max-wall-clock-seconds`、頻度は `--max-requests-per-minute` で設定します。
+公開設定の `public` は掲載だけを制御し、`alwaysAsk:false` は
+`CONNECTION_OPENING_REQUIRED` を返します。
+
+招待は発行者だけが同意済みの接続申し込みで、最初に使った所有者 DID に結び付きます。
+別の所有者が同じ有効な招待を使うと保留です。接続解除後も招待の期限まで結び付けを保持します。
+期限切れ・相手の不一致・失効した招待は保存前に拒否します。成立済みの接続は招待の期限や
+失効では消えません。後続の依頼は古いトークンを添付せず、確認済みの相手 DID を使います。
+保存済み `workerRef` は引き続き招待を選び、使うたびに期限を確認します。
+取り込みやプレビューだけでは、どちらの役割にも接続同意を付けません。
+
+```sh
+sealbridge accept --paste --alias reviewer
+sealbridge connections confirm-invite reviewer --role requester
+sealbridge connections request --to PEER_DID --relay https://relay.sealbridge.dev --role worker
+sealbridge connections list --role worker
+sealbridge connections approve REQUEST_ID --role worker
+sealbridge connections reject REQUEST_ID
+sealbridge connections withdraw REQUEST_ID
+sealbridge connections disconnect PEER_DID
+sealbridge connections block PEER_DID
+sealbridge connections unblock PEER_DID
+sealbridge connections prior-approved
+sealbridge connections connect-prior PEER_DID --relay https://relay.sealbridge.dev
+sealbridge connections sync --role requester --relay https://relay.sealbridge.dev --once
+sealbridge connections status reviewer --role requester
+```
+
+確認送信後に `sync --once` を実行し、`connections status reviewer` で照会します。
+保存済み workerRef または相手の所有者 DID も指定できます。既定の役割は requester です。
+照会はローカルの記録だけを読み、送信や鍵の作成はしません。`pending_peer` は相手の承認が
+ローカルに未適用、`connected` はローカルの limited 接続です。交換記録がある場合は
+`acknowledgementPending` も返します。同じ情報を
+`WorkerTrustStore.connectionStatus(peerOwnerDid)` から取得できます。
+ほかの状態は `none`・`pending_owner`・`inactive`・`expired`・`blocked` です。
+このプロトコルは相手側の拒否を通知しません。期限切れの申し込みの詳細は既存の削除処理まで
+照会でき、成立済みの接続は期限切れで消えません。
+詳しくは[接続状態の照会](docs/connections/connection-exchange.ja.md#接続状態の照会)を参照してください。
+
+判断には人間の TTY または注入された人間用審査プロバイダーが必要で、`--yes` はありません。
+ローカルの役割・DID と相手の所有者 DID を確認してください。requester と worker の既定鍵は別です。
+送信側の同意は送信前に保存し、申し込みは14日で失効します。reject は申し込みだけを7日間
+受け付けなくし、その間も依頼は保留できます。discard は内容だけを削除し、deny はブロックです。
+ブロックは片方向で、相手に応答しません。解除・ブロックは次の受付から効き、受諾済みの仕事は
+明示的な CANCEL で止めます。同時の申し込みは2つの DID を昇順にして同じ接続 ID を導きます。
+承認・ACK の状態を保存してからリレー受信確認を返します。sync は依頼を再送しません。
+内容の24時間と送信済み同意の14日は別の期限です。
+
+依頼の承認と接続への同意は別の判断です。CLI や MCP フォームで順に確認でき、明示的な
+接続同意がなければ申し込みを添付しません。相手の署名付き同意がない保留依頼を承認した場合、
+こちらから申し込みます。こちらの判断だけで相手の同意は作りません。接続の確認後は依頼者の
+所有者が新しい依頼を明示的に開始します。`pending resubmit` も未使用の監査・出力パスを使い、
+新しい依頼として改めて検査し、所有者が開きます。
+
+既存の署名付き受付・招待ファイルは読み取れ、一覧・読み取りで書き換えません。従来の有限の
+許可は保留を省略せず、接続へ自動変換しません。残っている承認履歴は `prior-approved` から
+所有者の操作で申し込みます。相手の同意も必要です。従来の拒否はブロックとして残ります。
+CLI の明示的な contacts 設定は独立して維持します。`requests approve ID --trust trusted` は
+別系統の従来の24時間許可です。接続の操作から trusted は作りません。最初の変更で v2 に進むため、
+旧版へ戻す必要があれば事前に v1 を保存してください。新旧の書き込み処理は併用しません。
+接続・版の記録は1,000件・1 MiBの境界を維持し、成立済みの記録を自動削除しません。
+
+廃止した CLI の `--open`・`--access-mode`・`--open-*`・`--allow-any-requester` と JS の
+`accessMode`・`openPolicy`・`allowAnyRequester` は移行案内付きの `ACCESS_MODE_REMOVED` です。
+MCP 検索の旧 `accessMode` 引数は JSON-RPC -32602 です。検索は署名と期限を確認した
+最新の掲載カードすべてを返し、運用モードの欄は返しません。旧カードの署名済み原本は保持します。
+`acp_list_connections {}`・`acp_list_connection_requests {}` は鍵を作らず、サーバーの署名者の
+ローカル情報だけを返します。所有者の判断は人間用 CLI で行います。
+
+board の claim と dispatch は、選択した投稿者の現在の接続が必要です。
+未接続なら `CONNECTION_REQUIRED` で、接続だけでは依頼・リースを承認しません。
+接続と版を確認してからリースを消費します。保存済みのタスク封筒は、同じ署名済みバイト列と ID で受理または元の期限まで再試行し、リースを再消費しません。
+一度だけの入場券と別の応募キューは後続の検討です。
+
+[プロトコル版とリリース時計](docs/connections/protocol-versions.ja.md)も参照してください。
+
+依頼側は CLI/MCP の保留依頼を既存のデータルート内の
+`requesters/<requester-did-hash>/pending.private.json` に24時間保存します（POSIX 0600）。
+非公開レコードにはタスク本文・入力と、使用した場合は招待参照を含みます。
+一覧・エラーには招待情報やタスク本文を返しません。保留応答には `pendingId`、
+`originalTaskId` と次の操作案内が加わります。元のタスク ID または依頼者 DID を
+ワーカー所有者に伝え、審査対象を確認してください。
+
+```sh
+sealbridge pending list
+sealbridge pending resubmit PENDING_ID --audit ./fresh-audit.jsonl --out ./fresh-result.json
+sealbridge pending remove PENDING_ID
+```
+
+同じ依頼者の鍵・データルートを使い、明示的な鍵には `--key FILE` を指定します。
+再送は現在の承認方針（CLI の既定は対話承認）に従い、`--auto-approve` は所有者が
+明示的に許可した場合だけ指定します。監査・出力には未使用のパスを指定します。
+中継器・承認設定を再確認し、保存済み招待の期限・失効も引き続き確認します。
+保存した workerRef を使った保留記録には参照だけを保持し、招待トークンを複製せず、明示的な再送時に参照を解決し直します。
+MCP は `acp_list_pending_requests {}` と `acp_resubmit_pending_request {pendingId}` を提供し、
+現在の送信先確認と必須のホスト承認を適用します。再送は新しいタスク ID を作り、
+再度の保留は同じレコードを更新、完了は resolved、その他のエラーは failed として記録します。
+保存期限は延長せず、期限切れのレコードは次の保存更新時に削除します。一覧は最後に観測したローカル状態で、遠隔の承認状態は取得せず、
+自動再送もしません。再送時に対応版を選び直し、新しい検査と所有者が開く操作を行います。状態照会・通知は今後の検討事項です。
+
+`--allowed-peer DID` は繰り返し・カンマ区切りで、全信頼レベルの受信とセッション送信（進捗・復旧を含む）を制限します。対象外には応答しないため、別の手段で伝えてください。公開登録は引き続き `--publish` の指定が必要です。
 
 **ターミナル 3 — 依頼側 Alice**
 
+既定の検査プロバイダーは利用不可のため、この例は終端の `PENDING_OWNER_APPROVAL`
+（終了値3）を返し、成果物や検収済み監査は作りません。自動再試行はしません。
+完了には検査プロバイダーを設定し、接続の審査後に新しい依頼を所有者が開く必要があります。
+`--auto-accept` ではこれらの操作を省略できません。
+
 ```sh
 pnpm sealbridge keygen /tmp/alice.private.json
 # プロンプトが出たら Bob のトークン全体を貼り付ける
@@ -229,7 +538,7 @@ pnpm sealbridge audit-verify /tmp/alice-audit.jsonl
 pnpm sealbridge discover --relay http://127.0.0.1:8787 --allow-private-relay
 ```
 
-期待する結果は、双方の `SETTLED`、JSON の成果物、`"valid":true` と `"status":"VALID"` です。トラストアンカーファイルも `--expect-final-state` / `--expect-last-hash` / `--expect-entry-count` も無いとき、`statusLabel` は `VALID (no trust anchor: truncation not checked)` です。ハッシュ鎖は検証できていますが、より古い妥当な接頭辞は排除していません。Alice は署名・ダイジェスト・予算、JSON Schema、登録済みの隔離チェックを検証し、最後に署名付きの最終承認を取ります。`--auto-approve` は最終検収をポリシー承認にする明示的な選択です。人間が確認するときは外してください。`acp://invite?token=...` も受け付けます。招待の代わりに `--to <Bob の DID> --relay <URL>` も使えます。Bob は手元の `/tmp/bob-audit.jsonl` を自分で検証できます。
+受付と所有者が開く操作を経た後の結果は、双方の `SETTLED`、JSON の成果物、`"valid":true` と `"status":"VALID"` です。トラストアンカーファイルも `--expect-final-state` / `--expect-last-hash` / `--expect-entry-count` も無いとき、`statusLabel` は `VALID (no trust anchor: truncation not checked)` です。ハッシュ鎖は検証できていますが、より古い妥当な接頭辞は排除していません。Alice は署名・ダイジェスト・予算、JSON Schema、登録済みの隔離チェックを検証し、最後に署名付きの最終承認を取ります。`--auto-approve` は最終検収をポリシー承認にする明示的な選択です。人間が確認するときは外してください。`acp://invite?token=...` も受け付けます。招待の代わりに `--to <Bob の DID> --relay <URL>` も使えます。Bob は手元の `/tmp/bob-audit.jsonl` を自分で検証できます。
 
 **アダプタを選ぶ**
 
@@ -281,23 +590,48 @@ docker run --rm -i -v sealbridge-data:/data sealbridge
 ## MCP、進捗、失効、クォーラム
 
 ```sh
-pnpm sealbridge mcp-server --key /tmp/alice.private.json --relay https://relay.sealbridge.dev
+pnpm sealbridge mcp-server
 ```
 
+リリース注記：次の機能は sealbridge npm パッケージの 0.3.0 から利用できます。CLI 0.2.2 以前では対応していません：`acp_list_invites`、`acp_remove_invite`、`acp_list_pending_requests`、`acp_resubmit_pending_request`。
+
 `sealbridge mcp-server` は、依存ライブラリを増やさない JSON-RPC 2.0 の MCP サーバーです。標準入力に、改行区切り JSON と `Content-Length` フレームの両方を受けます。Claude Code、Cursor、Codex、Grok Bot から次のツールを呼べます。
 
 | ツール                     | 戻り値                                                                 |
 | -------------------------- | ---------------------------------------------------------------------- |
+| `acp_list_invites`          | 保存した参照・別名・公開メタデータ・期限状態                           |
+| `acp_remove_invite`         | ローカル削除結果。発行者の招待は失効しません                           |
 | `acp_delegate_task`        | 検証済み成果物、`taskId`、状態、監査の要約                             |
 | `acp_delegate_multi`       | 複数ワーカーへの `race` または `quorum` 委任                           |
 | `acp_verify_audit_bundle`  | 暗号検証レポート。トラストアンカーで末尾切断を見たかも含む             |
 | `acp_create_invite`        | 署名済み `acp-invite` トークン                                         |
 | `acp_revoke_token`         | このプロセスに保存した署名済み `RevocationNotice`                      |
-| `acp_discover_workers`     | 中継器に登録された署名済みエージェントカード                           |
+| `acp_discover_workers`     | 既定では公開済み open ワーカーの現在のカード                           |
 | `acp_inspect_revocations`  | このサーバープロセスに記録された失効通知                               |
+| `acp_message_status` | 送信側のローカル状態。送信・更新取得・ポーリングはしません |
+| `acp_list_pending_requests` | タスク本文・招待情報を含まないローカルの保留記録                       |
+| `acp_resubmit_pending_request` | 所有者の審査後、現在の確認・承認を適用して新しいタスクを送信        |
 
 `initialize` は、この手順を示したサーバー `instructions` を返します。同じ実装が `@acp/runtime` の `AcpMcpServer` です。サーバー鍵は、ツールが行う依頼側の承認に署名します。`acp_discover_workers` はディレクトリの読み取り専用です。`GET /agents` の前に、委任と同じリレー許可リストと `validateRelayEndpointUrl` を使い、タスク入力は送りません。`acp_inspect_revocations` はメモリ上のレジストリを読むだけで、ワーカーには接続しません。
 
+フラグなしの `sealbridge mcp-server` で `acp_discover_workers {}` を呼ぶと、既定の `https://relay.sealbridge.dev` に公開されたワーカーを列挙します。結果を選び、その `workerDid` と `relayUrl` をそのまま `acp_delegate_task` に渡します。
+
+```json
+{
+  "workerDid": "<検索結果の workerDid>",
+  "relayUrl": "<検索結果の relayUrl>",
+  "title": "Echo JSON",
+  "description": "入力された JSON を返す",
+  "input": { "hello": "world" }
+}
+```
+
+単一ワーカーへの委任で `description` を省略すると、タイトルを使います。既定ではワーカー許可リストの設定は不要ですが、明示された許可リストは引き続き適用されます。
+
+MCP 検索は最新の署名と期限を確認した掲載カードすべてを返します。`skillId` と `taskType` で絞り込み、旧 `accessMode` は JSON-RPC -32602 です。元の署名付きカード・スキル・`protocolVersions`・`workerDid`・`relayUrl`・`acceptance: "worker_decides"` を返し、運用モードは返しません。
+
+掲載は `--publish` で選び、接続や依頼の承認を意味しません。未接続の依頼は終端の `PENDING_OWNER_APPROVAL` です。拒否時に別の相手へ切り替えたり自動再試行したりしません。
+
 `acp_delegate_task` と `acp_delegate_multi` は、タスク入力を中継器経由で対象ワーカーへ送ります。ホストが引数を組み立てるときは、送信先を制限します。
 
 ```sh
@@ -311,7 +645,11 @@ pnpm sealbridge mcp-server \
 
 `--allow-worker <did>` と `--allow-relay <url>` は、繰り返しとカンマ区切りの両方を受けます。`--allow-worker` があるとき、素のワーカー DID は一覧と一致しなければなりません。招待トークンは、その `agentDid` または `ownerDid` のどちらかが一覧にあれば許可されます。それ以外は、接続する前に `MCP_WORKER_NOT_ALLOWED` で拒否します。`--allow-relay` があるとき、リレー URL は末尾スラッシュを除いたオリジンとパスへ正規化します。設定した `--relay`、ツールの `relayUrl`、招待トークンに埋め込まれたリレー URL は、すべて一覧と一致しなければなりません。一致しなければ `MCP_RELAY_NOT_ALLOWED` です。ツール呼び出しや招待が `--relay` と別の中継器を選ぶ場合も、その URL が一覧になければ拒否します。許可リストを付けないプログラムからの利用では、`allowAnyRelay: true` を明示したときだけ別の中継器を選べます。許可リストがあるときは、そちらが優先されます。設定したリレー URL は `validateRelayEndpointUrl` で検査します。
 
-`--require-approval` は `InteractiveCliApprovalProvider` を使い、入力を送る前と最終検収のときに標準入力で確認します。`--approval-webhook <url>` は、所有者決定モードの `WebhookApprovalProvider` を使います。`{ taskId, summaryHash, reason, approverDid }` を POST し、HTTP 2xx かつ `{ approved: true }` のときだけ続行します。`{ approved: false }` または 2xx 以外は `APPROVAL_REJECTED` となり、何も送りません。独自の承認器は `AcpMcpServer` の `approvalProvider` に渡します。許可リストとこの承認は、`delegate` / `delegateMulti` がタスク入力を中継器へ書く前に実行されます。挙動は `conformance/p1-7-mcp-outbound-policy.test.ts` が固定します。
+`--require-approval`（プログラムでは `requireInteractiveApproval: true`）は、タスク送信前と最終検収時に MCP のフォーム elicitation を要求します。ホストはフォーム対応を広告し、プロトコル `2025-06-18` を使用する必要があります。従来の空の `elicitation: {}` もフォーム対応として扱いますが、URL のみの対応では利用できません。`action: accept` かつ真偽値の `approved: true` の場合だけ承認します。各フォームの待機は最大60秒で、タスクの残り期限も超えません。複数ワーカーには送信先ごとに総数を示して確認します。送信時は解決済みタスクと入力、検収時は成果物と署名済みメタデータを表示し、大きすぎる確認内容は `APPROVAL_REVIEW_TOO_LARGE` で拒否します。
+
+フォーム非対応のホストでは、タスク送信前に `APPROVAL_CHANNEL_UNAVAILABLE` を返します。elicitation 対応ホスト、または `--approval-webhook` を使用してください。標準出力への端末プロンプト表示や MCP 標準入力からの承認読み取りは、TTY でも行いません。通常の CLI worker/delegate の端末承認は従来どおりです。フォーム表示と利用者の決定の返却はホストに依存します。
+
+`--require-approval` も明示的な webhook/provider 設定もない場合、従来の policy-auto 動作は変わりません。`--approval-webhook <url>` は所有者決定モードを維持し、`{ taskId, summaryHash, reason, approverDid }` を POST して HTTP 2xx かつ `{ approved: true }` の場合のみ続行します。拒否または非2xxは `APPROVAL_REJECTED` です。独自の承認器は `AcpMcpServer.approvalProvider` で指定できます。許可リスト検査の後、送信承認では確定したマニフェスト・宛先・入力を確認します。最終検収の失敗は送信後にも発生するため、失敗が未送信を意味するとは限りません。関連テストは `conformance/mcp-host-approval.test.ts`、`conformance/mcp-approval-session.test.ts`、`conformance/p1-7-mcp-outbound-policy.test.ts` です。
 
 ワーカーは実行中に `PROGRESS`（`percent`、`step`、`message`、途中のトークン数やツール回数）を送れます。ほかのセッション封筒と同じ暗号と相互署名の監査に入ります。`delegate(request, { onProgress })` は、`DELIVER` の前に復号した更新を受け取ります。申告された使用量は `QuotaMeter` に計上されます。
 
@@ -333,6 +671,12 @@ HTTP の受信、SSE ストリーム、WebSocket の受信と購読には、宛
 node examples/network-collab/run.mjs
 ```
 
+## マニフェストのプロトコル版
+
+ライブラリはマニフェスト0.1.0と0.2.0を検証し、明示的な互換方針を提供します。
+送信は相互に対応する最新の版を選び、0.2.0 を優先します。設定済みのリリース時計は [版の説明](docs/connections/protocol-versions.ja.md)を参照してください。
+スキーマ・方針・相手の観測については[プロトコル版](docs/connections/protocol-versions.ja.md)を参照してください。
+
 ## 5つの設計原則
 
 1. **認証情報を共有しない。** 依頼側は、API キーや生の資格情報を受託側へ渡しません。必要な権限は、期限・回数・スコープ・委譲深さを絞った `CapabilityToken`（UCAN / Biscuit 風）として発行し、依頼側 Gateway がプロキシ検証します。
@@ -341,12 +685,25 @@ node examples/network-collab/run.mjs
 4. **BYOK と署名付き利用レシート。** LLM の費用は、契約クォータの範囲で実行側が自己負担します（BYOK）。実行側ランタイムが計量し、`UsageReceipt` に署名します。決済手段はコアから切り離し、後からプラグインにできます。
 5. **信頼できない入力と、双方が持つ監査証跡。** 他オーナーからのデータは `untrusted` としてサンドボックスで処理します。すべての状態遷移は Ed25519 署名の追記専用ハッシュチェーンになり、双方がコピーを保持します。
 
+### つながりの状態と永続化
+
+`@acp/runtime` は、所有者のローカル操作用のつながり状態・永続化APIを提供します。
+connected は期限なしの limited に対応し、ライブ経路の受付に使います。
+接続 metadata は、検証済みの招待・エージェントカードから得た任意の `peerDisplayName` を保持します。
+`listConnections()`・`connections list`・`connectionStatus()`・`connections status`・
+MCP の接続一覧・過去の承認候補一覧は、
+招待の削除後も既知の表示名を返します。表示名は情報としてのみ扱い、識別と同意の判断は
+DID に基づきます。同じ表示名でも所有者 DID は異なる場合があります。
+旧記録や相手のカードが不明な場合は省略でき、読み取りで書き換えません。通信形式の変更はありません。
+
+APIとストアの互換性は[つながりの状態と永続化](docs/connections/connection-state.ja.md)を参照してください。
+
 ## ドキュメント
 
 | ファイル                                                                               | 内容                                                                                                |
 | :------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------- |
 | [`SECURITY_PROOF.ja.md`](./SECURITY_PROOF.ja.md)                                       | 敵対的セキュリティテストスイート（形式的証明ではない）と `pnpm test:security-proof`                 |
-| [`ARCHITECTURE.ja.md`](./ARCHITECTURE.ja.md)                                           | 全体像、信頼境界、タスク状態機械、5つの安全機構、既存プロトコルとの比較、脅威モデル                 |
+| [`ARCHITECTURE.ja.md`](./ARCHITECTURE.ja.md)                                           | 全体像、信頼境界、タスク状態機械、5つの制御、既存プロトコルとの比較、信頼の前提                 |
 | [`REPO_STRUCTURE.ja.md`](./REPO_STRUCTURE.ja.md)                                       | モノレポ構成、技術選定、MVP の範囲、マイルストーン M0〜M3、実装タスクの分割                         |
 | [`spec/README.ja.md`](./spec/README.ja.md)                                             | プロトコル概要、メッセージエンベロープ、正規化と署名                                                |
 | [`spec/task-manifest.schema.json`](./spec/task-manifest.schema.json)                   | `TaskManifest` の JSON Schema（Draft 2020-12）                                                      |
@@ -355,6 +712,20 @@ node examples/network-collab/run.mjs
 | [`AGENTS.md`](AGENTS.md)                                                               | 自律 Worker / Requester の運用手順                                                                  |
 | [`SKILL.md`](SKILL.md)                                                                 | 持ち運び用エージェントスキル                                                                        |
 
+### つながり交換ライブラリ
+
+署名付きの申し込み・承認・ACK と、永続化・検査・所有者確認・通信を注入する
+`ConnectionService` を公開します。runtime・CLI・MCP・board に所有者ごとの永続化と保留内容の審査を接続します。
+接続の申し込み時刻と既定の14日後の期限は、一度取得した時刻から計算します。ワーカーと CLI が発行するカードも、最大30日を含め同じ方法で有効期間を計算します。
+詳細は[つながり交換](docs/connections/connection-exchange.ja.md)を参照してください。
+
+組み込み側は `ConnectionAdmissionReview` を明示的に使い、保留中の受信接続の公開情報を
+一覧し、所有者の操作後に `approve(id)`（limited の同意）または `reject(id)` を呼べます。
+CLI は `connections review list|approve ID|reject ID` で、判断には本人の確認が必要です。
+組み込み検査は接続情報だけが対象です。既定の受信・タスク検査は `unavailable` のままで、
+タスクは開きません。[受信接続の審査](docs/connections/admission.ja.md#受信接続の審査)を参照してください。
+
+
 ## ローカルの M0–M1 実装
 
 Node.js 22 LTS と pnpm 10 が必要です。WP-1 から WP-6 は `@acp/core`、`@acp/ledger`、`@acp/sandbox`、`@acp/runtime`、`@acp/relay`、`@acp/cli`、`@acp/two-owner-demo` として実装されています。
@@ -396,6 +767,19 @@ pnpm sealbridge audit-verify /tmp/alice-audit.jsonl \
 
 [デモの手順](examples/two-owner-demo/README.md)、[ワイヤ規約](spec/README.ja.md)、[適合性テスト](conformance/README.md)、[M1 セキュリティモデル](docs/security-model.md)、[敵対的セキュリティテストスイート](SECURITY_PROOF.ja.md) を読んでください。M1 は署名付きリレーエンベロープと、制限付き JavaScript 子プロセスです。M2/M3 は任意の強化 OCI 実行と、ペイロードのエンドツーエンド暗号化を追加します。ルートのコードは Apache-2.0 です。DelegateOS から取り込んだ部分の MIT 表記は [NOTICE](NOTICE) に残しています。
 
+## 組み込み SDK
+
+型付き ESM 入口 `sealbridge/sdk` は、保存済み招待・鍵と秘密のストア・接続の審査・
+MCP のホストなどの公開 API を提供します。0.3.0 から利用でき、CLI 0.2.2 以前では対応していません。
+既存の CLI と内部パスも引き続き利用できます。
+[公開範囲と互換性の契約](docs/sdk.ja.md)を参照してください。
+
+## 保留内容のライブラリ
+
+`@acp/runtime` は、暗号化済みリクエストの保存と注入用の検査プロバイダーを提供します。
+内容の表示には検査完了の受領書が必要で、既定のプロバイダーは保留を継続します。
+API とホストの役割は[保留内容のライブラリ契約](docs/connections/held-content.ja.md)を参照してください。
+
 ## 作成者・リンク
 
 - **作成者 (X / Twitter)**: [@takapon01234](https://x.com/takapon01234)
@@ -407,3 +791,81 @@ pnpm sealbridge audit-verify /tmp/alice-audit.jsonl \
 公式サイトは https://sealbridge.dev、招待受信ページは `https://sealbridge.app/i#<invite>` を想定しています。静的サイトのソース・ビルド・公開手順は [Web サイトの運用](docs/sites.ja.md) を参照してください。このリポジトリへの追加だけでは公開されません。
 
 推奨の中継 URL は `https://relay.sealbridge.dev` です。従来の `https://acp-relay.agent-collab.workers.dev` も同じ中継器として引き続き利用できます。既存の署名付き招待を編集せず、そのまま利用してください。新ホストへ切り替える場合は MCP の中継許可リストも更新します。
+
+## 保存済みの送信待ち
+
+CLI worker/delegate・board・MCP ホストは、承認済みのタスク封筒を
+`<data-root>/delivery/<sha256-local-signer-DID>/` に保存します。
+イベントと監査エントリの両方を保存してから送信します。一時的な送信失敗では、
+同じ署名済み暗号文・封筒 ID を、1分、5分、15分、その後は1時間ごとに再試行します。
+検証済みの relay の待機指定があれば、さらに待ちます。relay の受理または元のタスク期限で
+再試行を止めます。受理はキューへの保存であり、所有者による開封・エージェントの実行・
+検収完了を示しません。`PENDING_OWNER_APPROVAL` は終端のままで、再依頼は明示操作です。
+
+同じ署名者・データルートでゲートウェイを次回起動すると送信待ちを再開します。
+停止中は再試行しません。通信の復旧は任意の双方向セッションの復元やアダプターの再実行を
+意味しません。既定のワーカーのタスクジャーナルと受信記録で記録済み依頼の再実行を抑止し、
+明示した inbox/audit のジャーナルパスを優先します。heartbeat と接続同意用 outbox は従来どおりです。
+
+C1 の永続化はゲートウェイのプロセス再起動を対象とし、送信・受領確認より前に書き込みとアトミックな置換を完了します。封筒・受信記録・既定のタスクジャーナルではファイルやディレクトリを fsync せず、電源断時の永続化は保証しません。lease・再試行・relay 受理の管理情報は、中断後に同じ封筒 ID で再送する場合があります。明示した inbox/audit のタスクジャーナルは従来の flush 方針を維持します。変更のないレコードとディレクトリ一覧の検証を再利用し、索引更新・復元時の走査・定期削除はバッチまたはレコードごとにイベントループへ制御を返します。
+
+セッションの送信と処理済み受信記録は、準備時に署名者ロックを取得せず、一意の一時ファイルへ非同期に書き込みます。ハンドルを閉じてからアトミックに公開し、同じ署名者・relay の独立したタスクは並行して書き込めます。公開時に署名者ロックの下で容量と受信記録の状態を再確認し、ファイルシステムの再試行待機は行いません。既定のタスクジャーナルは追記ハンドルと変更のない検証済みチェックポイントを再利用し、圧縮時とワーカー停止時にハンドルを閉じます。
+並行する依頼は、署名者の送信ストアを共有し、それぞれのタスクと relay の対応を維持します。
+
+POSIX のディレクトリ・ファイルは 0700/0600、Windows は親の DACL を継承します。
+稼働中の送信は、受理の結果を取得した後に完了済みバッチの暗号文を削除します。
+保守処理は期限切れの送信待ちを閉じてからメッセージ情報を削除し、残った完了・終了済み
+バッチも削除します。中身を含まないメッセージ情報と
+受信重複処理の記録は `max(createdAt, 元の deliveryDeadline)` の7日後まで保持します。
+読み取り・再試行で期限を延ばしません。保守処理は起動時と稼働中の毎分に行い、停止中の
+期限切れファイルは次回の保守まで残る場合があります。ローカル上限は送信待ち1,024通、
+封筒 JSON 合計32 MiB、封筒1通256 KiB、メッセージ・受信記録は各10,000件です。
+容量不足・保存失敗は固定のエラーとして報告し、未保存の送信や有効な記録の追い出しは行いません。
+
+組み込みホストは `deliveryService` または `deliveryOptions` を注入し、
+`startDelivery()`/`stopDelivery()` で稼働を制御できます。独自の transport で再起動後も
+送るには固定の relay URL と resolver が必要です。名前のない注入 transport は従来の
+一時的な動作です。初期化・道具の一覧・ローカル読み取りでは送信を開始せず、鍵も作りません。
+transport の `send()` 単体は1回の試行のままです。この変更に relay の配備は不要で、
+受理後の封筒には既存の relay の保持期間が適用されます。
+[relay の動作](docs/relay-reliability.ja.md)も参照してください。
+
+
+MCP の送信の3道具 (`acp_delegate_task`・`acp_delegate_multi`・
+`acp_resubmit_pending_request`) は任意の `idempotencyKey` を受け付けます。
+Unicode 文字列を正規化せず UTF-8 の1〜200バイトで指定します
+（例: `"idempotencyKey":"review-2026-11-02"`）。同じ署名者・道具・キー・内容なら
+再起動後も最初の結果を返し、送信と承認を繰り返しません。内容が違えば
+`IDEMPOTENCY_CONFLICT` となり、新しいキーが必要です。キーと結果は元の期限
+（複数では最も遅い子の期限）の7日後まで保持します。保留の再参照では再依頼せず、
+試行回数も増やしません。別サーバーは `IDEMPOTENCY_IN_PROGRESS`、中断後は
+`APPROVAL_INTERRUPTED` または `IDEMPOTENCY_RESULT_UNAVAILABLE` を返し、承認や実行を
+やり直しません。最終検収は別で、キー省略時の動作は従来どおりです。
+保持期間・ランタイムのフック・復旧は[relay の動作](docs/relay-reliability.ja.md)を参照します。
+relay のデプロイは不要です。
+
+### 受信側の配達状態
+
+検証済みの 0.2.0 タスクでは、受信側署名付き `DeliveryStatus` で本文を含まない
+保留・開く・アダプターへの引き渡し・終了を記録します。タスク連番・双方向監査とは別です。
+未接続の相手には `received_held` と `closed` だけを返し、後の接続承認でも元の履歴を
+送りません。検査・表示だけでは開かず、結果成功時の後片付けでは閉じません。
+接続解除は待機中の詳細を、ブロックは待機中の全状態を送信対象から外します。
+版の宣言がない相手は従来の 0.1.0 の動作です。記録は元の配達期限から7日後まで保持し、
+稼働中の保守が期限切れを削除します。引き渡しは既読や実行の証明ではありません。
+両ゲートウェイの対応が必要で、relay の配備は不要です。
+状態の記録元・保持・動作は [relay の動作](docs/relay-reliability.ja.md)を参照してください。
+
+### ローカルの送信状態
+
+`idempotencyKey` 付き送信のキャッシュ再参照でも、元のメッセージ ID・タスク ID を使います。
+状態照会は送信結果のキャッシュとは独立して、その ID に保存された最新の観測を返します。
+
+`acp_message_status {"messageId":"<元の PROPOSE UUID>"}` または
+`acp_message_status {"taskId":"<元のタスク ID>"}` は、送信・更新取得・ポーリング・削除を
+せず送信側の記録を読みます。指定は一方だけにし、複数一致するタスク ID は `messageId` で
+選びます。元の期限（作成時刻が後ならその時刻）の7日後に失効し、不明・別の署名者・
+期限切れは `found:false` です。当初未接続の相手の詳細は `received_held`/`closed` だけです。
+受信側の主張は双方向監査とは別で、引き渡しは既読・実行の証明ではありません。
+委任結果のキャッシュや保留の明示的な再依頼とは別の読み取りです。relay の配備は不要で、
+詳細な観測には相手の C4 対応が必要です。[relay の動作](docs/relay-reliability.ja.md)を参照してください。