shared-memory-intake

共有メモリへの投稿

~/.codex/memories/ は Codex 専用のメモリストアです。Codex の統合処理では MEMORY.md、memory_summary.md、rollout_summaries/ が書き込まれます。エージェントがこれらを 直接編集することはありません。ここへの唯一の書き込み経路は、 ~/.codex/memories/extensions/ad_hoc/notes/ に置くメモです。統合処理ではこのメモを 取り込む必要があります（extensions/ad_hoc/instructions.md）。~/.agents/shared-memory-inbox/ は、 この経路の手前にある外部投稿用ストアです。各ホストには、それぞれ専用の受信箱と Codex メモリがあります。動的な主張は、アクティブなセッションで検証されるまで UNCONFIRMED として扱ってください。

ここに含める内容

投稿するのは、後のセッションが直接適用できる再利用可能な事実や手法です（パス、 動作するコマンド、ツールの制限、訂正された認識など）。セッション中に生まれた ワークフロー（うまくいった手順の順序）を含め、その時点でこのセッション以降にも 役立つ可能性があると判断したものは、何でも投稿してください。それが全体に当てはまると 証明する必要はありません。採用するかどうかはレビューで判断します。ルール、スキル、 レシピにすべきだと思う場合は、投稿を参照する項目も ~/.agents/retro-inbox/pending/ に 追加してください。maintenance.md §3 の行を書ける場合は kind: proposal、それ以外は kind: note とします。何がうまくいかなかったか、どのルール、ゲート、ブリーフを変更すべきかを振り返る内容は、 ここではなく ~/.agents/retro-inbox/ に送ってください（形式は maintenance.md §3）。セッション終了時の書き込みに両方の内容がある場合は、項目を2つに分け、 受信箱ごとに1つずつ作成してください。同じテキストを両方に、または引き継ぎメモに コピーしないでください。

アクターの契約

アクターを明示してください：--as claude または --as codex。実行環境から 推測してはいけません。

アクター	許可される操作	禁止される操作
claude	Codex メモリの読み取り、inbox/pending/ への投稿の作成（1件）	Codex メモリ、メモ、または別の投稿の編集や削除
codex	ad_hoc メモの読み取り、レビュー、書き込み、編集、投稿の移動	MEMORY.md、memory_summary.md、rollout_summaries/ への書き込み、メモや投稿の削除

Claude：投稿

このスキルのディレクトリから python3 scripts/read_memory.py keyword [keyword ...] を実行すると、 大文字と小文字を区別せずにキーワードを検索できます。このスクリプトは Codex メモリ、サマリー、 ad_hoc メモ、保留中・処理済み・却下された投稿を読み取ります。--status を指定すると、ファイル数、 最新の mtime、MEMORY.md より新しいメモを表示します。この時間フラグは統合処理が行われたことを 証明するものではありません。通常モードでは何も書き込みません。--self-test は一時ツリーを作成し、 リーダーをテストします。メモリを変更できないため、アクターのフラグは不要で、すべてのエージェントが このリーダーを使用できます。

1. MEMORY.md を読み、既存の現在の主張を新しい投稿として言い換えないでください。

2. YAML フロントマターを付けた Markdown ファイルを1つ、~/.agents/shared-memory-inbox/pending/ に 一意の名前で作成してください：

   schema_version: 1
   source_runtime: claude
   submitted_at: 2026-07-26T00:00:00Z
   cwd: /absolute/path
   source_session: opaque-session-id
   claim_status: unverified
   evidence_host: hostname-or-fleet-id
   

   同一ホストの証拠には evidence_host は任意です。引用する情報源が別のホストにしか 存在しない場合は必須です。

3. 再利用可能な結論、情報源の参照、証拠、不明点だけを記載してください。認証情報、トークン、 秘密鍵、Cookie、生のトランスクリプトは絶対に含めないでください。

4. 引き継ぎ前に検証してください：

   python3 ~/.agents/skills/shared-memory-intake/scripts/validate_submission.py /absolute/path/to/submission.md
   

5. 訂正は supersedes_submission を指定した新しい投稿としてください。以前の提案を上書きしないでください。

Codex：レビューと引き継ぎ

1. 単独キュレーター用リースを取得します：mkdir ~/.agents/shared-memory-inbox/.curator.lock。 すでに存在する場合は停止し、アクティブなキュレーターとの競合を報告します。結果を記録した後、失敗した場合も含めてrmdirで解放します。
2. 候補に対してバリデーターを実行します。スキーマまたはシークレットパターンの検査に失敗した場合は却下します。
3. 引用されているソースを確認し、動的な主張をすべてライブ検証します。ホストをまたぐ証拠については、evidence_hostを必須とし、そのホスト上で検証します。キュレーターのホストと検証時刻を記録します。ホストにアクセスできない場合、その主張はUNCONFIRMEDのままにします。
4. MEMORY.mdを読みます。すでに記載されている主張はスキップし、変更された形で記載されている主張については、新しい形を記録し、古いものにsupersededのマークを付けます。
5. そのホストのextensions/ad_hoc/notes/に、キュレーション実行ごとに1つのノートを作成します。ファイル名は<UTC timestamp>-shared-inbox-curation.mdとします。保持する主張ごとに1つの箇条書きを記載し、情報として記述します（指示や提案として記述しないでください）。ライフサイクル状態として、active、superseded（置き換え先を明記）、またはUNCONFIRMEDを記載し、ソースの提出ファイルも記載します。ノートを修正する場合は編集し、削除はしないでください。
6. 別のホストでは、ローカルのステージングディレクトリにネイティブのWriteツールでノートを書き込み、scpでそのホストのnotes/に転送し、両端でsha256を比較します（使用例は1回、2026-10-15 remote-44）。
7. 各候補をprocessed/（引き継ぎ済み）またはrejected/に移動します。実行レポートを~/.agents/shared-memory-inbox/curation-<date>-<machine key>.mdに書きます。提出ごとに1行とし、ファイル、結果、理由、検証済みかUNCONFIRMEDか、バリデーターの終了コードを記載します。提出ファイルは削除しないでください。
8. ノートが存在し、候補が移動されると、引き継ぎは完了です。統合処理でその内容が取り込まれたかどうかは後で確認する事項です（2026-10-15時点では未確認：8月のノートのテキストはMEMORY.mdにありません）。主張がMEMORY.mdにあると報告するのは、そのテキストを実際に見つけてからにしてください。どちらの場合も、ノートと処理済みの提出ファイルは検索可能な状態に保たれます。

Codex：メンテナンス

1. 同じ単独キュレーター用リースを取得します。アクティブなキュレーターとの競合がある場合は停止します。
2. 現在のMEMORY.mdの項目を調べ、パス、バージョン、モデル、デプロイ、または古くなった参照の変更を確認します。
3. 主張を修正する場合は、それを保持しているノートを編集します。該当するノートがない場合は、新しいノートを作成します（上記ステップ5）。未検証の動的な主張はUNCONFIRMEDに格下げし、置き換えられた主張には、置き換え先への参照とともにsupersededのマークを付けます。
4. 前回の実行以降に引き継いだ各ノートのテキストがMEMORY.mdに記載されていることを確認します。統合処理で取り込まれていないノートがあれば報告します。

バリデーター

scripts/validate_submission.pyを使用します。これは対象を絞った事前チェックゲートであり、主張が真実であることの証明でも、完全なシークレットスキャナーでもありません。合格した場合に認められるのはレビューのみです。証拠の検証と引き継ぎは、引き続きCodexが担当します。