先週、Claude Codeセッションが、私の注文キューに180件の未処理アイテムがあり、そのいずれも13日以上経過しておらず、254件中221件がClaude Codeセッションによって書き込まれていたと伝えました。それ自身がカウントしたのです。システム内で最大の単一メールボックスは、システム自身が自分自身に取り組んでいるものでした：36件の注文で、そのうち約30件はツール自体が自身のツールを改善しているものでした。

私はしばらくそのリストを見ていませんでした。それが書き留めておく価値のある部分です。

この投稿に含まれるもの： プロジェクトごとに1つの TODO.md が10プロジェクトで機能しなくなった経緯、代替案が落ち着いた形、3つの破綻とそれぞれが残したゲート、そしてこのシステム全体が私に今も課しているコストです。中央部分は、複数のリポジトリを頭の中にすべて収めきれないほど扱っている場合、どのようなツールを使ってそれらを操作していても盗用できる内容です。

10プロジェクトと1つのMarkdownファイル

私は昨年末にClaude Codeを使って複数のプロジェクトを横断して作業し始めました。当時のシステム全体は、各プロジェクトフォルダ内の TODO.md でした。セッションを開き、必要な作業を伝えれば、ファイルが残りを保持してくれました。2〜3プロジェクトであれば、これは全く問題ありません。私はそれを推奨します。

しかし、それが10になりました。10の進行中のプロジェクト、Mac Studio上の10のフォルダ、10のTODOファイル、そして3つの問題が同時に発生し始めました。

アイデアが帰宅途中で失われました。外出中に何かが思いついても、それを書き留める場所は、私が座っていないマシン上のプロジェクトフォルダ内のMarkdownファイルでした。戻ってきた頃には、それは消えていました。

朝は、したくない決断になりました。10のリスト、共有ビューなし、優先順位付けなし。今日、私が取り組むべきプロジェクトはどれか？正直な答えは、通常、最後に触れたものであり、それは優先順位の逆です。

そしてプロジェクトは数週間沈黙しました。完了したからではなく、私のセットアップにそれを伝えるものが何もなかったからです。ファイルは無視されていることを知らせてはくれません。

約1ヶ月前、私は何よりも重要なことを教えてくれるものを望むことにしました。別のリストではなく、リストの上位にある層です。

現在の様子

先週、私は先延ばしにしていたことをしました。マニュアルを書いたのです。コードのドキュメントではなく、オペレーターのためのマニュアルであり、オペレーターは私自身です。どこで何をし、どのコマンドが存在し、メモがどのように注文になるか、そして人間を待つ4つの場所です。8つのセクションに及びます。それを書くことは有用な不快感を伴いました。なぜなら、唯一のユーザーのためのマニュアルを必要とするツールは、その成長について何かを物語っているからです。

以下は、そのマニュアルのうち、一般化できる部分です。作業になり得るものはすべて1つの収集ポイントに入り、そこから正確に1つのパスを持ちます。

（ここでは図を省略しています。2つのフローチャートは元の投稿にあります。）

この背後では2つの時計仕掛けが動いており、どちらも考えません。launch agentが15分ごとに（StartInterval 900）ドロップボックスを空にし、エントリを適切なプロジェクトのリストに振り分けます。もう1つは30分ごとに（StartInterval 1800）承認済みの注文をピックアップし、すべてのリポジトリから意図的に外れた ~/.cache/master-dispatch-worktrees の下のgit作業ツリーでヘッドレスに実行します。ソートステップにはモデルは関与していません。そのため、これほど頻繁に実行できるのです。

私が最も使用するのは、最も賢くない部分です。私は自分自身にメールを送ります。

（ここでは図を省略しています。2つのフローチャートは元の投稿にあります。）

それが、私の3つの問題のうち最初のものの解決策です。私が常にアクセスできるのは自分の受信トレイなので、それがエントリポイントになりました。それがしないことは、メモを作業に変えることです。それは注文になり、そして停止します。これが、なぜこれにゲートがすべて存在するのかという理由につながります。

3つのセッション、1つのファイル

7月17日、私は3つのClaude Codeセッションを並行して実行していました。すべてがプロジェクトごとの支出制限を保持する共有設定ファイルに触れていました。それぞれがファイルを読んで自分の行を変更し、ファイル全体を書き戻しました。古典的な読み込み-変更-書き込みですが、書き手はスレッドではなくエージェントであり、私はそれを同時実行性として考えていませんでした。最後の書き手が勝ちました。1つのセッションの例外は、次のセッションによって静かに消去されました。

修正は平凡なものです。共有リソースは現在、小さな mit-lock ラッパーを通じてのみ書き込み可能で、これは10分の古いタイムアウトと監査ログを備えたmkdirベースのロックです。pre-toolフックは、保護されたパスのいずれかに書き込むBashコマンドを、それが通過しない限り拒否します。

平凡ではなかったのは、その背後にある認識でした。私は並行セッションを、気づくだろう並行人間のように扱っていました。彼らは気づきません。彼らはプロセスであり、2つが状態を共有する瞬間、あなたは2つのスレッドに負うのと同じ規律を彼らに負っています。それが、他のすべてが今立脚している3つのルールの由来です。リポジトリごとに1つの書き手、共有リソースごとに1つの所有者、クロスプロジェクト作業のための1つのチャネル。

完了した以上の作業を生み出したツール

これが冒頭のカウントにつながります。

7月28日までに、キューは180件の未処理注文を抱え、そのいずれも13日以上経過していませんでした。つまり、システムは7月20日以降、1日あたり約20件の新規注文を生み出していた一方で、私は2〜5件をクローズしていました。254件のドロップボックスエントリのうち221件が私ではなくAIセッションによって書き込まれ、そのうち163件がオーケストレーションレポ自体のセッションからのものでした。

何も壊れていませんでした。それらの注文はすべて合理的でした。それがまさに問題なのです。Claude Codeセッションは役に立ちたがり、実在のリポジトリで1つ開けば、10の真の改善点を見つけます。よりクリーンなリファクタリング、古くなったドキュメント、より厳密にできるテストです。10の合理的な観察を15のリポジトリで掛け合わせると、1人の人間が決して捌ききれない流れが生まれます。私の受信トレイはミスで埋まっていたのではありません。良いアイデアで埋まっていたのです。

修正は、立証責任を逆転させます。それまでは、誰かが積極的に削除しない限り、注文は存在していました。今は、トリガーを命名できる場合にのみ存在します。ユーザーまたは顧客に影響を与える障害、セキュリティ、金銭、またはデータに対するリスク、デプロイのブロッカー、または私が声に出して言うことです。「よりクリーンになるだろう」「通りすがりに気づいた」「一貫性のため」はトリガーではありません。それらはパイプラインではなく、私が読むセッションサマリーに入ります。これを遡及的に適用すると、19のメタオーダーが一度にアーカイブされ、合計が165から144になりました。

ここで意図的に構築しなかったものは、興味深いものです。明白な動きはAIゲートキーパーです。モデルに各受信注文を判断させ、ノイズを拒否させます。私はそうしませんでした。なぜなら、同じ週に、長い、よく構造化され、完全に妥当な、しかし不適切に書かれた注文が通り、それが文字通りに取られれば、186の顧客メールボックスの送信メールを、それが運ぶことを意図されていないサービスにルーティングするところだったからです。モデルゲートキーパーは、それをまっすぐに通過させていたでしょう。それは、捕捉するはずだったまさにその失敗クラスを含んでいたでしょう。一部の問題は、別のモデルを追加しても改善しません。

間違ったものを見ていたガード

最も最近のものは昨日からのものであり、私は同じクラスの失敗に4回目にあたっています。

1つのセッションが自分のリポジトリにのみ書き込むというルールはpre-toolフックによって強制されており、昨日まではそのフックはコマンドを見て機能していました。それは外部パスに書き込む形状を知っていました。出力リダイレクト、tee、git -C、sed -iです。7月28日、ロールアウトスクリプトがPythonヒアドキュメントを通じて21の外部リポジトリに書き込みました。フックは文字列が付いた python3 呼び出しを見て、それを通過させました。なぜならヒアドキュメントは書き込みのように見えるもののリストになかったからです。

修正は、意図の推測をやめることでした。現在は、自律的な実行の前にすべてのリポジトリのgit状態を記録し、後で比較するチェックがあります。変更がどのように行われたかは気にせず、行われるべきでない場所に変更が現れたかどうかのみです。それは3つの場所でフェイルクローズします。欠落したチェックはディスパッチャーの開始をブロックし、失敗したベースラインは注文を中止し、欠落したベースラインは全クリアではなく不一致としてカウントされます。

パターンマッチングはコマンドが何をするかを推測します。前後を比較することは、それが何をしたかを測定します。それを学ぶのに私は4回の試行を要しました。そして、私は初日からそれをそのように設計することはなかったでしょう。

コストと、まだ開いているもの

オーケストレーションレイヤーは32のシェルスクリプトと約6,300行で、145のテストがコピーに対して実行され、実際の注文には決して触れません。21のフックがツールコールの前、途中、後で発火します。リポジトリ境界、リソースロック、かつて200行中199行を破壊したデータベースダンプフラグをブロックするチェック、検証済みリストにない事実を含む送信メールを拒否するもの。そのどれも設計されたものではありません。各部分は、何かが通り抜けた場所に位置しています。

4つの場所がまだ私を待って停止しており、それが何も驚くべきことが起こらない理由です。注文は、私が承認するまで何もしません。私自身が提出した注文も含みます。dialogueとマークされた作業は、私なしでは実行されません。完了した作業が自分自身をマージすることはありません。そして、テキストに支払い、顧客、または本番デプロイが言及されているものは、承認されていても開始前に保留されます。なぜなら7月27日、50ユーロの顧客返金がキューにあり、承認され、自律的とマークされ、実行の準備ができていたからです。

今日の正直な状態：149件の注文が記録されており、そのうち122件が承認され待機中です。トリガールールは流入を遅らせましたが、逆転はさせませんでした。根本的な緊張は解決されておらず、解決できるかどうかもわかりません。なぜなら、それはツールのバグではないからです。人間が評価できるよりも速く候補作業を生成するマシンは、常にキューに行き着きます。そして、私が構築したすべてのゲートは、私が意図的にボトルネックになることを選んだ場所です。

昨年末に10のプロジェクトとプロジェクトごとに1つのMarkdownファイルでこれを始めたとしたら、何を differently するでしょうか。ドロップボックスと承認ゲートを最初に構築し、それ以外は何も構築しません。それら2つは、私が一度も修復する必要がなかった唯一の部分です。このシステムの他のすべては、私は2回構築しました。

もしあなたが似たようなものを運用していて、人間がすべてのアイテムを読むことなく流入を正直に保つ方法を見つけているなら、お聞きしたいです。