factory-product

factory-product

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

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

1. 開始： bash {REPO_ROOT}/.agents/skills/factory-mission/scripts/bash/run-branch.sh — Windows では pwsh {REPO_ROOT}/.agents/skills/factory-mission/scripts/powershell/run-branch.ps1 を使用します（各ヘルパーには scripts/powershell/ に PowerShell 版があります。Windows では bash 版ではなく、そちらを使用してください）
2. DAG が課題に対して解決したライフサイクルの各ステップを実行します。ファイルを変更したステップの後には必ず、書き込み、移動、削除したすべてのパスを指定して commit-step.sh を実行します。
3. 戻る前に、必ず： open-mr.sh を実行してから、ADLC_STEP_OUTPUT に1行の conclusion を書き込みます。何も変更されなかった場合も含め、結果にかかわらず実行してください。
4. 承認を求めたり、回答を待ったりしないでください。 このステップの後にあるエンジンのゲートが承認にあたります。ここで質問すると、何も公開されないままステップが終了します。

コミット、プッシュ、MR の作成を行うのはこのオーケストレーターだけであり、これらの操作はヘルパー経由でのみ行います。product-* スキルはこれらの操作を行いません。詳細については、ブランチの実行、ステップコミット、ドラフト MR を参照してください。

---

このスキルの機能

factory-product は、プロダクトの意思決定に関するライフサイクルをオーケストレーションします。個々のプロダクト関連スキル（product-init、product-specify、product-clarify、product-implement、product-analyze）を連携させ、共有レイアウトの docs/adlc/product/PRD.md を一貫した状態に保ちます。

factory-mission/references/executor.md に定められた共有エンジンの契約に沿って、Kind-A DAG オーケストレーターとして動作します。

---

使用する場面

• プロダクトの要件と意思決定（PDR）を、エンドツーエンドで初期化、改善、または分析したい場合。
• 再開チェックポイントを備えた、ガイド付きで承認ゲートがあり、検証済みのプロダクト定義プロセスを利用したい場合。

使用しない場面：

• ソフトウェアの実装タスクを実行する場合（代わりに factory-mission を使用してください）。
• アーキテクチャ決定記録を作成する場合（代わりに factory-architect を使用してください）。

---

ライフサイクル DAG とステップの解決

factory-product は、固定された名前付きスキル DAG（ステップ解決方式：fixed）を実装します。

グリーンフィールドルート（空のプロジェクトでのデフォルト）

1. specify（generate フェーズ）-> product-specify を呼び出し、.adlc/drafts/pdr/ に PDR のドラフトを共同で作成します。
2. clarify⭐（clarify フェーズ）-> product-clarify を呼び出し、対話形式で品質チェックを実施して、PDR を承認済みとしてマークします（人間による承認ゲート）。
3. implement（build フェーズ）-> product-implement を呼び出し、承認済みの PDR を docs/adlc/product/PRD.md にまとめ、docs/adlc/memory/pdr/ に昇格します。
4. analyze（analyze フェーズ）-> product-analyze を呼び出し、PRD と PDR の整合性を検証し、重大度順のレポートを出力します。

ブラウンフィールドルート（コードは存在するが、PDR がない場合のデフォルト）

1. init（generate フェーズ）-> product-init を呼び出し、既存のコードベースから PDR のドラフトをリバースエンジニアリングします。
2. clarify⭐ → implement → analyze（グリーンフィールドと同じ）。

リフレッシュルート（PRD.md とメモリの PDR がすでに存在する場合のデフォルト）

1. analyze（analyze フェーズ）-> まず product-analyze を実行し、ドリフトを検出します。
2. clarify⭐ → implement → analyze（ドリフトを修正するサイクル）。

---

共有 Executor のオーバーライド

factory-product は、共有 Executor エンジンのプリミティブを次のようにオーバーライドします。

1. 公開先：local に固定されています。出力は docs/adlc/memory/pdr/ と docs/adlc/product/PRD.md に書き込まれます。トラッカーと連携している場合は、tracker の完了サマリーコメントも投稿されます。
2. 出力タイプ：各ステップでは、次の output_type が割り当てられます。
   • specify/init → draft（PDR のドラフトはコメントバスには公開されず、.adlc/drafts/pdr/ に保存されます）
   • clarify⭐ → decision（承認／却下された PDR の一覧がコメントバスに公開されます）
   • implement → artifact-ref（PRD.md のパス参照が公開され、内容はディスク上に保存されます）
   • analyze → findings（重大度順の整合性レポートがコメントバスに公開されます）
3. 修正ループ：analyze が CRITICAL または HIGH の整合性エラーを返した場合、Executor は reads_from に analyze マーカーを指定して clarify に戻します。clarify は、PR/MR/issue のコメントバス（またはローカルのフォールバック）から調査結果を読み取ります。このループは max_corrections（デフォルトは 2）によって制限されます。上限を超えると、オーケストレーターは処理を停止し、人によるレビューに回します。
4. 監督のデフォルト：hybrid です。clarify⭐（PDR の承認）と最終的な PRD.md のレビューでは、人によるゲートが必ず適用されます。
5. 事前チェック：Phase 0 の開始前に、product-* ライフサイクルスキルがワークスペースにインストールされていることを確認します。

---

実行ブランチ、ステップごとのコミット、ドラフト MR

必要条件： factory-mission スキル（実行ヘルパーを提供）：adlc-cli skills add tikalk/adlc-team-skills --skill factory-mission

ファクトリー実行（ワークフローエンジンによって ADLC_RUN_ID が設定されている場合）では、このオーケストレーターだけが（product-* ライフサイクルスキルは決して行いません）、常に次の3つのヘルパーを通じて実行ブランチをコミットおよびプッシュし、ドラフト MR を作成します。

1. 最初のステップの前： bash {REPO_ROOT}/.agents/skills/factory-mission/scripts/bash/run-branch.sh — プロジェクトルートで ADLC_ISSUE_REF から factory/intent/<repo>-<iid> をチェックアウトします。既存のブランチを再利用するか、origin から続行します。他の intent レーンや再ディスパッチとの間で共有されます。
2. 各ステップの後（specify／init、clarify、implement、analyze の修正）： bash {REPO_ROOT}/.agents/skills/factory-mission/scripts/bash/commit-step.sh --orchestrator factory-product --step <step> --output-type <draft|decision|artifact-ref|findings> --summary "<one line, no issue text>" --records <IDs> -- <paths the step wrote> ステップが書き込み、移動、または削除したすべてのパスを渡します（昇格したドラフトの古いパスも含めます。ヘルパーは許可リスト内の削除もコミットします）。パスはライフサイクルの書き込み許可リスト内のものに限ります（.adlc/drafts/pdr/、docs/adlc/memory/pdr/、docs/adlc/product/PRD.md、.adlc/product/sections/、.adlc/product/state.json）。ヘルパーは sha: <sha> または sha: none を出力します。その sha をステップのバスマーカーに記載します（バスには内容ではなくポインターを渡します）。.adlc/workflows/** は絶対にステージしないでください。
3. 戻る前に、必ず： bash {REPO_ROOT}/.agents/skills/factory-mission/scripts/bash/open-mr.sh — 実行ブランチだけをプッシュし、ドラフト MR を1件見つけるか作成します（マージコミット方式、スカッシュなし。マイルストーン／担当者は MR の所有権に関する決定に従います）。さらに mr_url を ADLC_STEP_OUTPUT に書き込み、エンジンのゲートがリンクします（context.link）。結果にかかわらず呼び出してください。何もコミットされていない場合（sha: none、analyze のみの実行など）は、実行ブランチにコミットがないため何も作成されず、ゲートにはレビュー対象がないことが表示されます。同じ JSON オブジェクトに1行の conclusion も書き込みます（ゲートの intent-conclusion ルール）。
   ファクトリー実行では、このステップの後にあるエンジンのゲートが承認そのものです。自分で承認を求めないでください（「implement を承認しますか？」などの質問はしないでください）。issue に必要なステップを完了し、open-mr.sh を実行し、結論を述べて戻ってください。

ファクトリー実行の外では、ユーザーがオプトインした場合（.adlc/init-options.json の adlc.commit_steps: true、またはこのスキルに渡された --commit。この場合は commit-step.sh に渡します）を除き、ヘルパーは何もしません。run-branch.sh と open-mr.sh は ADLC_RUN_ID がない場合は動作しません。ヘルパーがゼロ以外の終了コードを返した場合（パスの拒否、コミッター ID の欠落、トラッカーのスコープなど）は実行を停止し、そのことを報告してください。回避策を講じてはいけません。