異なるエージェントが同じツリーを取得しないでください。

並列エージェントに関する難しい問題

s09 ～ s11 では複数のチームメイトを同時に起動できますが、チームメイトはすべて同じ作業ディレクトリ内にあるという落とし穴があります。 alice は auth.py を変更しており、bob も同時に auth.py を変更しています - git の競合、ファイルの混乱、テストの相互汚染。

s12 の解決策は git worktree です。同じウェアハウスの場合、git worktree add を通じて異なるディレクトリの異なるブランチをチェックアウトできます。各エージェントは独自のワークツリーを取得し、互いに見えない独自のディレクトリで動作します。

my-repo/                           # 主工作区（lead 用）
.worktrees/
  alice-auth/                      # alice 的隔离目录
    (branch: wt/alice-auth)
  bob-api/                         # bob 的隔离目录
    (branch: wt/bob-api)
  index.json                       # worktree 注册表
  events.jsonl                     # 生命周期事件日志

2 つの面での分業

s12 システムを明示的に 2 つのプレーンに分割します。

• コントロール プレーン: .tasks/ の JSON ファイル。タスクは、依存関係、所有者、ステータスを含む、「何をするか」の抽象的な単位です。
• 実行プレーン: .worktrees/ のディレクトリ。ワークツリーは「どこで実行するか」の物理的なコンテナ、つまりディレクトリ + ブランチです。

この 2 つは、task.worktree と worktree.task_id を通じて双方向にバインドされます。

この種の分離により、次のことが可能になります。タスク管理メカニズムを再利用しますが、 実行環境は変更します (たとえば、git worktree ではなく docker コンテナ)。 または、タスクメカニズムを変更しますが、 ワークツリーを再利用します (たとえば、JSON ファイルではなくデータベース)。

ライフサイクルのデモンストレーション

以下で完全に実行してください: タスクの作成 → ワークツリーの作成 → コマンドの実行 → 保持または削除。各ステップはイベント ログ (events.jsonl) に記録され、運用環境での監視に使用されます。

維持するか削除するか

ワークツリーがその使命を完了すると、2 つの結末があります:

• remove: git worktree remove --force、ディレクトリの削除。ブランチも通常はクリーンアップされます。これは、「この探索はもう必要ありません」と同じです。
• keep: .worktrees/index.json 内でのみ status: kept をマークすると、物理ディレクトリが予約されます。これは、「この結果が得られるので、マージするまで待ってください」と同じです。

共通モード: サブエージェントは実験的リファクタリングを実行します → 良好な結果で実行します → 保持 → 人間によるレビュー → メイン ブランチにマージ → 手動で削除します。効果が悪い？取り外して捨てるだけです。