factory-intent

factory-intent

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

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

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

コミット、プッシュ、MR の作成を行うのは、このオーケストレーターだけです。また、操作はこれらのヘルパーを通じてのみ行います。ライフサイクルスキルはこれらの操作を行いません。詳細はブランチ実行、ステップコミット、ドラフト MRをご覧ください。

---

このスキルの機能

factory-intent は、2つのレーンにわたる意図のライフサイクルをオーケストレーションします。 プロダクトライフサイクルスキル（product-init、product-specify、 product-clarify、product-implement、product-analyze）と アーキテクチャライフサイクルスキル（architect-init、architect-specify、 architect-clarify、architect-implement、architect-analyze）を連携させ、 単一のミッションブリーフから一貫した PRD.md と AD.md を維持します。

共有実行エンジン契約である factory-mission/references/executor.md に沿って、 Kind-A DAG オーケストレーターとして動作します。 2つのオーケストレーターを、エイリアスのない1つの2レーン DAG に置き換えます。

---

使用するタイミング

• 1つの意図から、プロダクト要件とアーキテクチャ上の決定をエンドツーエンドで取りまとめ、それぞれを独自のゲートで承認したい場合。
• 再開用チェックポイントを備えた、ガイド付きで承認ゲートがあり、検証可能な定義プロセスを利用したい場合。

使用しない場合：

• ソフトウェア実装タスクを実行する場合（代わりに factory-mission を使用してください）。
• すでに意図の段階を終えている単一レーンのフォローアップの場合（レーンスキルを直接呼び出してください）。

単一レーンの実行（レーンの有効化）

ブリーフで一方のレーンのみが必要な場合は、両レーン用の workflow.yml ではなく、そのレーンのエントリーワークフローを実行してください。

• プロダクトのみ → workflow-product.yml（specify → clarify → gate-decisions → build-and-verify。プロダクトコマンドと PDR を範囲とするゲートを使用します）。
• アーキテクチャのみ → workflow-architecture.yml（同じ構成で、アーキテクチャコマンドと ADR を範囲とするゲートを使用します）。

各エントリーは、ゲートコンテキスト契約（records/since/link）を備え、削除された旧オーケストレーターと同じステップ構成を踏襲します。適応型エグゼキューターは、ディスパッチ時に同様に route 入力を解決します。

---

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

factory-intent は、レーンごと、フェーズごとに1つのステップを持つ固定名前付きスキル DAG（fixed ステップ解決）を実装します。

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

1. product-specify / architect-specify（generate）— .adlc/drafts/pdr/ と .adlc/drafts/adr/ にドラフトを作成します。
2. product-clarify / architect-clarify⭐（clarify）— 品質をチェックします。各レーンは独自のゲートで、自身のドラフトを承認済みとしてマークします。
3. gate-product-decisions / gate-architecture-decisions — スコープを固定した、個別の人間によるゲートです。どちらのゲートも、もう一方のレーンの成果物を承認できません。一方のレーンがゲートでブロックされても、もう一方のレーンでのドラフト作成はブロックされません。両方のゲートが通過するまで待機するのは、共同実装のみです。
4. build-and-verify — 共同実装（product-implement、 architect-implement）を行った後、共同分析（product-analyze、 architect-analyze）を行います。

ブラウンフィールド／リフレッシュのルート

レーンごとのルート入力（product_route、architecture_route）で、グリーンフィールド／ブラウンフィールド（init）／リフレッシュ（分析優先）をそれぞれ独立して選択します。一方のレーンがリフレッシュする間に、もう一方のレーンでグリーンフィールドを実行できます。適応型（LLM）エグゼキューターはディスパッチ時にルートを解決し、各レーンで init、specify、分析優先のいずれかを選択します。以下のチェックイン済み workflow.yml は、ヘッドレス実行向けのグリーンフィールドのデフォルト（specify レーン）を定義しています。

---

境界とタイブレーク

プロダクトは WHAT／WHY／FOR WHOM（課題、ペルソナ、スコープ、優先度、ビジネス指標、NFR の目標値）を決定します。HOW（技術スタック、パターン、インターフェース、NFR の実現方法）に関する内容は、プロダクトの決定事項ではなく、アーキテクチャレーンへの引き継ぎメモとして記録します。重複に関する意見の相違は指名された人間にエスカレーションし、その裁定はコメントバスに decision 出力として投稿します（人間によるタイブレークであり、自動解決はありません）。適応型エグゼキューターは、人間の裁定が下されるまで共同の implement を実行してはなりません（チェックイン済み workflow.yml はグリーンフィールドのデフォルトである 2 ゲートを定義しています。タイブレーク待ちは、このファイル内のゲートではなく、ディスパッチ時に適用されます）。

---

共有エグゼキューターのオーバーライド

1. 公開先：local（docs/adlc/memory/ + PRD/AD）に固定されています。
2. 出力タイプ：specify／init → draft、clarify⭐ → decision、implement → artifact-ref、analyze → findings。
3. 修正ループ：レーンごとの HIGH／CRITICAL は、そのレーンを clarify に戻します。max_corrections（デフォルトは 2）の範囲内で実行し、上限を超えた場合は停止して人間のレビューを待ちます。（これは適応型エグゼキューターの動作です。以下のチェックイン済み workflow.yml のヘッドレスループは、上限付きで再実装したものにすぎません。）
4. 監督のデフォルト：hybrid — 両方の clarify と最終レビューで人間がゲートを担当します。マージの承認は常に人間が行います。
5. 事前チェック：Phase 0 の開始前に、product-* と architect-* の両方のライフサイクルスキルがインストールされていることを確認します。

---

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

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

ファクトリー実行（ワークフローエンジンが設定する ADLC_RUN_ID）では、このオーケストレーターだけが、レーンのライフサイクルスキルは決して行わず、常に次の3つのヘルパーを使って実行ブランチをコミット、プッシュし、ドラフト MR を開きます。

1. 最初のステップの前： bash {REPO_ROOT}/.agents/skills/factory-mission/scripts/bash/run-branch.sh — プロジェクトルートで ADLC_ISSUE_REF を基に factory/intent/<repo>-<iid> をチェックアウトします。既存のブランチを再利用するか、origin から続行します。両方のレーンで共有され、再ディスパッチでも引き継がれます。
2. 各ステップの後（specify／init、clarify、implement、analyze の修正）： bash {REPO_ROOT}/.agents/skills/factory-mission/scripts/bash/commit-step.sh --orchestrator factory-intent --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、.adlc/drafts/adr/、docs/adlc/memory/adr/、docs/adlc/architect/AD.md、docs/adlc/architect/views/、.adlc/architect/state.json）内のパスのみを渡してください。 .adlc/workflows/** をステージングしてはいけません。ヘルパーは sha: <sha> または sha: none を出力します。その sha をステップのバスマーカーに記載してください（バスが運ぶのはコンテンツではなくポインターです）。
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、分析のみのパスなど）は、実行ブランチにコミットがないため MR は作成されず、ゲートにはレビュー対象がないことが表示されます。同じ JSON オブジェクトに1行の conclusion も書き込んでください（ゲートの intent-conclusion ルール）。 ファクトリー実行では、このステップ後のエンジンのゲートが承認そのものです。自分で承認を求めてはいけません（「implement を承認しますか？」など）。課題に必要なステップを完了し、open-mr.sh を実行して、結論を示してから戻ってください。

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