タスクの実行が終わったら、実際に何が起きたのかを知りたくなるはずです。何が変更されたのか、うまく動いたのか、問題があった場合はどう進めればよいのか。

結果とアーカイブの読み方

完了したタスクの結果を開く

実行中、完了済み、アーカイブ済みを問わず、任意のタスクカードをクリックすると結果ビューが開きます。次の内容が表示されます。

• 何が、なぜ行われたかの要約
• 変更されたファイルの完全な一覧
• パイプラインのステップごとの結果（ステップごとの pass/fail）
• オプションの Snapshot ステップが有効だった場合、実行中に取得されたスクリーンショット
• メタデータ：所要時間、処理した AI プロバイダー／モデル、Git コミットへのリンク

判定の理解

2種類の自動チェックが判定を生成します。ユニットテストの判定は、プロジェクトの既存のテストスイートに基づく、単純な pass または fail です。エンドツーエンド (E2E) の判定は、E2E テストが実際に動作しているアプリを操作するため、取りうる結果がもう少し多くなります。

失敗したタスクの扱い

failed ステータスは、パイプラインがリトライの予算内で自力では解決できない事態に遭遇したことを意味します。タスクを開くと、どのステップが失敗したか、記録された理由、そして Watchdog が先に自動復旧を試みた場合はその診断を確認できます。そこから通常は、最初からやり直すのではなく、失敗したステップ（修正をより前の段階から始める必要がある場合はそれ以前のステップ）からタスクを再開できます。AITM は、すでに成功したものをすべて保持します。

コンフリクトの扱い

conflict ステータスは、AITM の自動 Git マージが本物のコンフリクト、つまり同じ行に互換性のない形で触れる2つの変更に遭遇し、AI 支援による解決の試みでも安全に解消できなかったことを意味します。この場合、AITM はどのファイルがコンフリクトしたかを正確に示すため、ユーザーが解決できます。両方の変更が意図的に見える場合に、推測してどちらか一方を黙って選ぶことはありません。

アーカイブ

タスクが完了し、その変更が dev にマージされると、アーカイブに保管されます。アーカイブは、完了したすべてのタスクの検索可能な記録で、新しい順に、タイトル、プロジェクト、完了日、最終ステータスが表示されます。これは恒久的な監査証跡です。

アーカイブでは、タスクを（プロジェクト、日付、ステータスで）検索・絞り込みし、そのいずれについても完全な記録、つまり元のプロンプト、パイプラインのステップ、レビューの判定、テスト結果、そして Docs ステップが書いた変更内容の平易な要約を開けます。アーカイブされたタスクが閉じ込められるわけではなく、Restore でキューに戻せます。過去の作業の派生版を作る場合は、通常、アーカイブされたプロンプトを出発点として再利用する新しいタスクの方がすっきりします。