factory-mission

factory-mission

ファクトリー実行中 — まずお読みください

ADLC_RUN_ID が設定されている場合、ワークフローエンジンはこのスキルを execute ステップとして無人で実行し、その後に完了ゲートが続きます。必ず次の手順に従ってください。

1. ミッションは実行対象の Issue です。 引数の --issue <ref> から取得します。指定がない、または空の場合は ADLC_ISSUE_REF を使用します。どちらもない場合は、質問せずに {"conclusion":"blocked: factory run without an issue"} を ADLC_STEP_OUTPUT に書き込み、終了してください。
2. その Issue のミッションを最初から最後まで実行します（以下のフェーズ 0～6）：概要作成、テスト（RED）、コード作成（GREEN）、収束、続いて変更対象のリポジトリでドラフトのコード MR/PR を新規作成するか、既存のものを再利用します。
3. 終了する前に、必ず次を行ってください。 開いた、または再利用したコード MR/PR の mr_url と、1 行の conclusion を ADLC_STEP_OUTPUT に書き込みます。値が文字列のフラットな JSON オブジェクトとし、ファイル内の既存のキーは保持してください。エンジンは完了ゲートで mr_url をリンクします。結果にかかわらず実行してください。MR がない場合は、conclusion だけを書き込みます。
4. 質問したり、回答を待ったりしてはいけません。 このステップの後にある完了ゲートが承認の場です。ここで質問すると、何も実装されないままステップが終了します。

---

このスキルでできること

factory-mission はソフトウェアファクトリーの実行ハーネスオーケストレーターです。機能の説明を受け取り、ミッション概要（目標、制約、対象外事項、成功基準）に整理し、順序付きのステップリストを生成して、サブエージェントを順次実行することで各ステップを実行します。

次の主要なファクトリープラットフォーム機能を実装しています。

1. ユニバーサルスキルルーティング：ステップのディスパッチを分離します。インストール済みのスキルをスキャンし、その一覧をサブエージェントに渡します（どのツールがステップに適しているかはモデルが選択します）。
2. トラッカー非依存の統合（references/tracker-integration.md）：--issue <ref> を指定して呼び出すと、チケットのコンテキストを取得し、自動化／ディスパッチ用ラベル（autonomous／supervised）に従い、ステータスコメントとイテレーションログを書き戻します。
3. エージェント間コメントバス（references/tracker-integration.md §Inter-Agent Comment Bus）：トラッカーと統合されている場合、各ステップのターミナル出力（判断、調査結果、成果物の参照。ドラフトは含みません）を、PR／MR／issue に構造化コメントとして公開します。次のステップは開始前に前のステップのマーカーを読み取ります。これは、セッション境界、ランタイムの切り替え、ポッドのクラッシュをまたいで保持される、永続的なエージェント間メモリーです。ドラフトはローカルディスクに保持されます。
4. 自己完結型ワーカーブリーフ：ミッション概要はドラフトとして .adlc/workflows/runs/<run_id>/brief.md に保存されます。再開した実行とランタイムをまたぐワーカーは、セッションコンテキストに依存せず、ディスクからこれを読み取ります。
5. ワークツリーの分離：各実行には専用の git ワークツリーが割り当てられます。ユーザーのメインチェックアウトには決して触れません。終了時にクリーンアップされます（保存されていない作業がある場合は保持されます）。
6. リースベースの稼働確認：状態ファイルには、ハートビートと TTL を備えた更新可能なリースが含まれます。再開時に、実行中、期限切れ、完了済みの各状態を区別できます。
7. 停止の検出：サブエージェントのディスパッチ後、設定可能な時間枠（デフォルトは 20 分）で、観測可能な進捗を確認します。サーキットブレーカーを通過したハング状態のエージェントを検出して終了させます。
8. レーンベースのディスパッチ（references/lanes.md）：ステップは異なるレーンで実行できます。inline（このセッション）、agent（メイカー／チェッカーを分離するための、同じ CLI の新しいセッション）、または cli:<runtime>（任意のベンダー間実行）です。agent レーンは、無人ステージのデフォルトです。
9. スクラッチパッドツール：サブエージェントは、公開前にメモ、ドラフト、レビューを段階的にまとめるため、名前付きの実行専用スクラッチパッド（.adlc/workflows/runs/<run_id>/scratchpads/<name>.txt）を共有します。
10. ワークフローメモリーと自己改善：永続的な JSONL データベース（ワークスペース全体で共有される .adlc/workflows/memory.jsonl）に、実行をまたいだ学びを保存します。factory-learn は定期的に振り返りを行い、メモリーの整理と重み付けをします。
11. 階層型コンテキストパラメーター：ワークフローとエージェントは、パラメーターを {{params.<key>}} として参照します。値は、最も具体的なものから順に解決されます：agent < workflow < repository < project < default。
12. テストとコードの分離：autonomous モードまたは supervised モードでは、implement を、順次実行される test（テストエージェントが読み取り専用の src/ の下に失敗するテストを作成）と code（実装エージェントが読み取り専用の tests/ の下にコードを作成）に分割します。各実行は必須の機械的ゲートで終了します（Phase 5 を参照）。RED ゲートはコーディング開始前に新しいテストスイートが失敗することを証明し、GREEN ゲートはコンバージに到達する前にテストが成功することを証明します。

---

使用するタイミング

• ファクトリー対応チーム内で「この機能をエンドツーエンドで構築する」場合。
• サーキットブレーカー、スコアの回帰チェック、堅牢な再開メカニズム（factory-mission --resume）を備えた実行ループが必要な場合。
• チケットキューを対象に自律実行したい場合。

使用しない場合：

• ファクトリーを使わないスタンドアロンプロジェクトの場合（adlc-cli workflow run <workflow.yml> を実行してください。これは CLI エンジンで、実行状態を共有します）。
• 些細な 1 行の変更の場合（直接変更してください）。

---

プロセス

factory-mission は、共有実行コントラクト（references/executor.md）およびトラッカー非依存レイヤー（references/tracker-integration.md）に沿って実行されます。

Phase 0 to 4：セットアップとコンパイル

1. 実行の mission.yml（.adlc/workflows/runs/<run_id>/mission.yml）を読み込みます。実行と監督の方法を解決します。
2. --issue <ref> が指定されている場合（ファクトリー実行では、指定されていなければ ADLC_ISSUE_REF を使用します）：
   • 認証情報と MCP／CLI ツールを確認します（references/tracker-integration.md）。
   • イシューの内容を取得し、主要なブリーフの説明として使用します。
   • ラベルを読み込みます。ディスパッチが interactive、またはゲーティングが human-required の場合は、実行を停止します（インタラクティブセッションに引き継ぎます）。
   • この実行ではコメントバスが有効です。ステップの出力はマーカーコメントとして PR／MR／イシューに公開されます。
3. イシューが指定されていない場合（ファクトリー実行以外）：引数から仕様の説明を読み込みます。コメントバスは無効で、ステップ間のやり取りにはローカルファイルのみを使用します。
4. ミッションブリーフを構成します（Goal、Constraints、Non-Goals、Success Criteria）。ブリーフは draft であり、コメントバスには公開されません。
5. agent < workflow < repository < project < default の順に階層的なコンテキストパラメーターを解決し、固定した値のマップをブリーフに埋め込みます。
6. ルート分類（spec、change、quick）に基づいてステップリストを生成します。各ステップでは、実行コントラクトに従い、output_type（draft／decision／findings／artifact-ref）と reads_from（マーカーまたはローカルパス）を宣言します。

チームインデックスのフォールバック： セッション開始時にチームのレコードクラスインデックスが注入されていない場合は、docs/adlc/memory/ からバインディングレコードを直接読み込みます（二重読み込みの順序：最初に docs/adlc/memory、次にレガシーの .adlc/memory をフォールバックとして使用）。そのフォールバックについて1行で明記します。注入が欠落していても、決して処理を停止しないでください。

Phase 5：Converge ループの実行

ステップを順番に実行します。implement／converge に到達したら、次の処理を行います。

テストとコードの分離実行（TDD必須）

autonomous モードと supervised モードでは、implement ステップを2つの順次実行されるサブエージェントのディスパッチに分割し、それぞれを機械的な検証実行で締めくくります。

1. テストエージェント（test ステップ）：
   • 指示：spec.md に基づいて、tests/ に失敗するテストスイートを作成します。
   • 強制事項：src/ をハードな読み取り専用としてマウントし、書き込み可能なのは tests/ のみとします。
   • RED ゲート（必須）：実行担当者はテストスイートを実行し、少なくとも1つのテストが失敗することを確認します。テストスイートがすぐに成功した場合は、機能がすでに存在するか、テストが何も検証していないことを意味します。実行結果を添えて SPEC_CORRECTION_NEEDED に進み、code ステップには決して進みません。失敗したテスト数を実行ログに記録します。
2. 実装エージェント（code ステップ）：
   • 指示：テストに合格するために必要最小限の実装コードを src/ に記述します。
   • 強制事項：tests/、spec.md、plan.md をハードな読み取り専用としてマウントし、書き込み可能なのは src/ のみとします。
   • GREEN ゲート（必須）：実行担当者はテストスイートを再度実行します。テストスイートが失敗している状態で converge に進むことは決してありません。失敗がある場合は、失敗一覧を添えて直接 code ステップに戻ります（この差し戻しは converge サーキットブレーカーを消費しません。消費するのは失敗したイテレーションのみです。mission.yml の code ステップ再試行上限を使用してください）。

分割を省略できるのは、実行でテスト対象がないと宣言されている場合に限ります。具体的には、mission.yml で tdd: false が設定されている場合、ドキュメント／設定のみのステップの場合、または interactive モードの場合です（立ち会いのペアが独自の規律を適用します。例：superpowers の test-driven-development）。autonomous／supervised モードのコードを含むステップでは、分割を決して省略しません。

Converge ループ（Implement ↔ Converge）

1. implement ステップを実行します（または test + code ステップを実行します。まず RED→GREEN ゲートを適用します）。
2. converge ステップを実行します（独立した判定モードで、ブリーフと Non-Goals に照らして確認します）。
3. converge が次を返した場合：
   • DONE（かつ品質が quality_threshold を上回る）：ループを終了します。
   • CONTINUE：consecutive_tasks_appended をインクリメントします。サーキットブレーカー（デフォルトは3）とスコア低下カウンターを確認します。繰り返します。
   • SPEC_CORRECTION_NEEDED：停止し、Phase 6 に進みます。

フェーズ 6：完了と書き戻し

1. トラッカーと統合されている場合：PR/MR/issue からすべてのマーカーコメントを読み取り、監査証跡（決定事項、テスト結果、実装成果物の参照、収束履歴）をまとめます。
2. 共有実行を終了します：最後に adlc-cli workflow state advance <run_id> --step <last> --status completed を実行します（実行ディレクトリが永続的なアーカイブとなるため、別途移動する必要はありません）。
3. iterations.md に実装ごとのログを書き込みます。
4. トラッカーと統合されている場合：
   • 完了サマリーをチケットのコメントとして投稿します（マーカー：factory-mission:status=completed:run=<run_id>）。
   • ライフサイクルラベルを executing から validation に変更します（またはマージ済みの場合は done に変更します）。
   • 作成した PR に agent-authored を付与します。
   • ファクトリー実行の場合は、コードの MR/PR URL を mr_url として ADLC_STEP_OUTPUT に書き込みます（上記の「ファクトリー実行の場合」を参照）。
   • PR のマージはコードオーナーの承認まで保留します（承認なしで自動マージすることは決してありません）。
5. 監査サマリー全体を出力します。