AITM が完了した作業を dev にマージする方法、マージ後のテスト失敗を取り消すのではなく前方修正する方法、そしてタスクが触れるべきものだけに触れたことを検証する方法。
マージ、マージ後の修正、Scope Gate
マージの仕組み
すべてのタスクは、専用の git ブランチ／Worktree で実行されます。パイプラインが完了する（実装、
レビュー、テストがすべて緑になる）と、タスクは AITM のMerge queueに入ります。これは直列化された
キューで、並行するタスクが同時に dev にマージされて、互いの
変更を踏み荒らすことがないようにします。
- 自動マージのトリガー。
autoMergeDevが有効なタスクは、パイプラインの完了後にdevへ自動的にマージされます。手動の承認ステップはないため、完了した作業は、人間がマージをクリックするのを待って溜まるのではなく、継続的に反映されます。 - マージ前のビルドゲート。 タスクのブランチはまず現在の
devに追従するよう更新され、その後、マージ後の姿になった状態でビルドと型チェックが行われます。チェックが赤の場合、fix agent に限られた回数の試行が与えられます。すでにdevに存在するエラーは、タスクの責任にはなりません。ゲートが赤のままなら、タスクはマージされず、ビルド出力が添付された状態でconflictで終了します。 - コンフリクトの処理。 タスクのブランチが、すでに
devに反映された内容とコンフリクトする場合、AITM は異なる戦略でマージをリトライし、その後、コンフリクトしたファイルを AI コンフリクトリゾルバーに引き渡します。リゾルバーは両方の変更を統合し、ビルドゲートを再実行します。conflictで待機しているタスクは自動的に再チェックされます。その間に原因が解消していれば、自己修復してマージへ進みます。 - dev への制御されたマージ。 マージはキューから1件ずつ行われるため、
devが中途半端にマージされた状態になることはありません。マージはパイプラインのステップではありません。タスクは Finalizing… マーカー付きでfinishedと表示され、マージが反映されるとarchivedになります。タスクがconflictのままの間は、同じタブ内の他のキュー待ちのタスクがその後ろで待機します。そのため、早めに解決する価値があります。
dev にマージされているところ。マージ後のエラー検出と修正
タスクのブランチが dev にマージされると、AITM は影響を受けるテストを
dev の新しい状態に対して再実行します。それらが失敗した場合も、デフォルトの対応は
マージを取り消すことではありません。
例：あるタスクが共有モデルに新しいフィールドを追加します。問題なくマージされ、そのタスク自身のテストも 通ります。しかし、別のブランチですでに進行中だった別のタスクが、そのモデルの古い形に依存していました。 両方が反映された後、共有の統合テストが失敗し始めます。どちらかのマージを取り消す （それでは、それぞれの変更のうち、無関係で正常に動いている半分まで捨ててしまいます）代わりに、AITM は次のように対処します。
- 実際に失敗しているファイル／テストと、どのタスクの変更が原因かを切り分けます。
- ブランチ上で前方修正します。失敗している領域だけを対象とした是正タスクが作成され、
元のどちらのタスクの diff からでもなく、
devの現在の状態から作業します。 - 修正が再び
devに近づくことを許される前に、単独で再テストします。 - 他のタスクと同じキューを通して、修正をマージします。
この「前方修正」の考え方は、連鎖的な被害を避けます。他の作業がすでにその上に積み上がった後でマージを 取り消すと、さらに取り消しが連鎖して必要になります。実際の不具合をその場で、専用のブランチ上で修正することで、 影響範囲は、見つかった1つの問題に限定されます。
タスクスコープの評価（Business Scope Gate）
すべてのタスクは、触れる予定のファイルをあらかじめ宣言します。タスクが完了すると、 Business Scope Gate が、実際に変更されたファイルをその宣言と比較します。
- スコープ外とは、変更されたファイルが宣言されておらず、タスクの 目的との間にもっともらしい関連がないことを意味します。たとえば、チェックアウトページに関するタスクが、無関係な管理設定ファイルも編集している場合です。
- スコープの修正（Scope amendments）。 宣言されていないファイルに触れることが正当な場合もあります。 共有の型を変更しなければならなかった、あるいは定数が隣のファイルにある、といった場合です。その場合、 タスクは、黙って範囲を逸脱するのではなく、追加のファイルについての短く明示的な理由（「スコープの修正」）を 記録します。理由が付いた修正は受け入れられ、説明のない追加ファイルは受け入れられません。
- ブロッキングとアドバイザリの違反。 宣言されていないファイルのすべてが
同じように扱われるわけではありません。
- ブロッキング — 変更されたファイルがタスクにとって明らかに無関係である場合 （別の機能領域、共有する依存関係なし、理由の提示なし）。解決されるまでマージが 止まります。
- アドバイザリ — 変更されたファイルが、宣言されたスコープと同じディレクトリ／モジュールにあり、 関連している可能性が高い場合（例：同じ機能フォルダ内の兄弟ファイル）。レビュー対象として フラグが立てられますが、それだけでマージをブロックすることはありません。
バグになるものと新しいタスクになるもの
レビューのステップが、直接の diff を超える何かを見つけた場合、AITM は2つの結果のどちらにするかを決定します。
- 指摘がブロッキングのスコープ違反である場合、またはタスクが本来行うはずだったことと無関係な本物の欠陥である場合は、バグになります。 すでに壊れていて、現在のタスクの結果とは無関係に、独自の修正サイクルが必要なものです。
- 指摘が改良、あると望ましい改善、または別の作業中に浮かび上がった正当ではあるがスコープ外のアイデアである場合は、新しい（フォローアップの）タスクになります。 現在のタスクのスコープを広げるのではなく、それ自身の条件でキューに入ります。
この分け方により、各タスクの diff は依頼されたことに集中したままで、同時にレビュアーが途中で気づいたすべてを 取りこぼしません。レビュー中に観察されたものは何も黙って捨てられることはなく、かといって無関係な変更に紛れ込まされることもありません。
タスクが失敗し、人間の介入が必要な場合
すべての失敗が自動的に復旧できるわけではありません。AITM の Watchdog と自己修復の仕組みは、
インフラストラクチャの一時的な不調や、通常のコンパイル／テストの失敗を自力で処理しますが、一部のエラーは
終端的であり、さらなるリトライではなく、人間の判断を必要とします。タスクが終端の
failed 状態で終了するのは、次の場合です。
- 設定が誤っている。 無効な API キー、誤った設定、不正な形式の JSON。壊れた環境は、コードではどうにもできません。
- AI に必要なデータが欠けている。 タスクのプロンプトが不完全または曖昧である、 必要なコンテキストが提供されなかった、または要件の記述が不十分である。
- ユーザーにしか解決できない根本的な障害がある。 アーキテクチャの明確化が必要、 スコープに争いがある、またはサードパーティのサービスが停止していて、作業を続行する前に 明示的な確認が必要。
例：要件が既存のアーキテクチャと矛盾するためにタスクが失敗したとします。AITM は どちらの設計が正しいかを推測できません。人間が明確にする必要があります。この時点で次のようになります。
- タスクは
failedとマークされます。 - ユーザー（と Claude）が、Chat または Brainstorm で根本原因を議論します。
- ユーザーが判断します。より明確なスコープで再キューするか。まず別のアーキテクチャ設計タスクを登録するか。 アプローチを調整するか。
- その後、改善された理解のもとで新しいタスクを作成するか、更新したプロンプトで再キューします。
すべての失敗がバグではありません。人間の入力なしには本質的に解決できないものも多くあります。 失敗は無駄な作業を意味しません。失敗した実行の診断情報とログは、どこで問題が起きたかを正確に示してくれます。 そしてタスクが失敗したとき、それは行き止まりではなく、 ユーザーと AITM の間の対話のきっかけなのです。
ブランチモデル
AITM が管理するすべてのプロジェクトは、同じ2ブランチのリリースモデルに従います。
devはデフォルト／統合ブランチです。 すべてのパイプライン タスクはdevにマージされます。ここに、完了してテスト済みの作業が継続的に反映されます （上記の Merge queue を参照）。mainは安定したリリースブランチです。 個々のタスクではなく、リリース時のdev→mainマージによってのみ更新されます。masterブランチは存在しません。 AITM がそれを作成することも、期待することもありません。- インポートされたプロジェクトは、独自の統合ブランチを維持できます。 オンボーディングする
プロジェクトがすでに統合ブランチに別の名前を使っている場合は、Project
settings の Integration branch 設定（
defaultBranch）で指定し、そこにある Verify remote チェックで、実際の git リモートに対して解決できることを確認してください。 - Docker リリースに同梱されている Gitea は、デモ用リポジトリを
devをデフォルトブランチとして作成するため、この同じモデルにそのまま一致します。
タスクのプロジェクトに使用可能な git リモートがない場合、タスクは、生の git エラーを表示する代わりに、 Project settings → Verify remote へ案内する、対処可能なメッセージとともに停止します。