1つのプロンプトが、レビューされ、テストされ、文書化され、マージされた変更になります — その間、ユーザーは別の作業ができます。Pipelineは12のステップで構成され、そのすべてを引き受けます。

Pipeline

得られるもの

• 各Taskは専用の分離されたブランチで作業するため、並列のTask同士が衝突することはなく、メインのコードは安全に保たれます。
• 結果を目にする前に、AIによるレビューと自動修正が行われます。
• ユニットテストとエンドツーエンドテストが自動で実行されます。
• 結果は、指定した受け入れ基準に照らして検証されます。
• ドキュメントとBehavioral Contractsは自動的に最新の状態に保たれます。
• マージはキューに入れられ、変更が反映される前にビルドが成功しなければなりません。
• 何かが失敗した場合、AITMは自力で復旧し、任意のステップから再開できます。
• すべてのTaskに、読みやすい結果サマリーと履歴が残ります。

12のステップ

1. Branch — Taskは、他のTaskと衝突しない専用の安全な作業領域を得ます。得られるもの：作業の準備が整うまで、メインのコードに手が加えられません。
2. Architect — AIがプロンプトと関連するコードを読み、解決策を計画します。得られるもの：プロジェクトのどの部分を変更するかについて、よく練られた計画。
3. Code — 計画が実際のファイル変更になります。得られるもの：完成した実装。
4. Compliance-check — 複雑なTaskについて、差分を要件と独立して照合します。単純なTaskではスキップされ、指摘事項はReviewに引き継がれます。得られるもの：要件の見落としを早期に把握。
5. Review — AIが同僚のように作業を確認し、判定を下します。得られるもの：人を待つことなく得られる、第二の視点。
6. Fix — Reviewが指摘した事項に対処します。Reviewとの間で数回ループすることがあります。得られるもの：整えられた結果。
7. Test — プロジェクトの自動ユニットテストを実行します。得られるもの：変更が既存の動作を壊していないという確信。
8. E2E — 実際のユーザーのようにアプリを操作するテストを実行します。プロジェクトにエンドツーエンドテストがある場合のみ、Testと並列で実行されます。得られるもの：ユーザーの一連の操作全体の検証。
9. Verify — 結果をTaskの受け入れ基準と照合します。それぞれpassed、failed、unverifiableのいずれかで終わります。得られるもの：Taskが依頼どおりに動作するかどうかについての、明確な答え。
10. Snapshot — UIのスクリーンショットを取得する任意のステップ。得られるもの：変更の視覚的な記録。
11. Docs — 変更内容を反映するよう、ドキュメントとBehavioral Contractsを更新します。常に実行されます。得られるもの：陳腐化しないドキュメント。
12. Chain-audit — 依存するTaskのチェーンの最後のTaskに対してのみ動作し、それ以前のすべてのTaskの基準を再確認します。得られるもの：チェーン全体が整合しているという保証。

マージはPipelineのステップではありません — 最後のステップの後、TaskはMerge queueに入り、devブランチへマージされます。それまでの間、完了したTaskにはFinalizing…マーカーが表示されます。詳細はMerging, Post-Merge Fixes & Scope Gateを参照してください。

ユーザーが関与する場面

• Taskの結果を確認します — 結果とアーカイブの確認を参照してください。
• 結果が意図と合わない場合は、プロンプトを編集します。
• Pipelineが停止した場合は、あるステップから再開するか、Taskを再度キューに入れます。

ステップが失敗した場合

停止したステップは自動的に再試行されます。再試行回数はSettings → Pipelineで設定します。devとの同期後にビルドが失敗している場合は修復が試みられ、マージコンフリクトはまずAIによる解決が試みられます。それでも解決しない場合、Taskはフラグが立ったままとなり、その理由が表示されます。失敗またはコンフリクトしたTaskのカードには、復旧の提案ボタンが表示されます。