factory-architect

factory-architect

ファクトリーの実行時 — まずこちらをお読みください

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 の作成を行うのはこのオーケストレーターだけであり、専用ヘルパーを通じてのみ実行します。architect-* スキルはこれらを行いません。詳細はブランチの実行、ステップのコミット、ドラフト MRを参照してください。

---

このスキルの機能

factory-architect は、アーキテクチャ決定のライフサイクルをオーケストレーションします。個々のアーキテクチャ関連スキル（architect-init、architect-specify、architect-clarify、architect-implement、architect-analyze）を調整し、プロジェクトのルートにある一貫した AD.md を維持します。

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

---

使用する場面

• プロジェクトのシステムレベルの設計と決定（ADR）を、最初から最後まで立ち上げ、改善、または分析したい場合。
• アーキテクチャの観点が Rozanski & Woods の方法論に準拠していることを確認したい場合。

使用しない場面：

• 製品要件の定義（代わりに factory-product を使用してください）。
• 機能レベルのソフトウェア実行（代わりに factory-mission を使用してください）。

---

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

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

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

1. specify（generate フェーズ）→ architect-specify を呼び出し、ADR のドラフトを .adlc/drafts/adr/ に共同で作成します。
2. clarify⭐（clarify フェーズ）→ architect-clarify を呼び出して対話形式の品質チェックを行い、ADR を Accepted とします（人間による承認ゲート）。
3. implement（build フェーズ）→ architect-implement を呼び出し、承認済みの ADR を AD.md（サブシステム別）にまとめ、docs/adlc/memory/adr/ に昇格させます。
4. analyze（analyze フェーズ）→ architect-analyze を呼び出し、AD/ADR の一貫性を検証して、重大度順のレポートを出力します。

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

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

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

1. analyze（analyze フェーズ）→ 最初に architect-analyze を実行して、乖離を検出します。
2. clarify⭐ → implement → analyze（乖離を修正するサイクル）。

---

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

factory-architect は、共有エグゼキューターエンジンのプリミティブを次のようにオーバーライドします。

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

---

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

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

ファクトリー実行（ワークフローエンジンによって ADLC_RUN_ID が設定されます）では、このオーケストレーターだけが（architect-* ライフサイクルスキルは決して行わず）、以下の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-architect --step <step> --output-type <draft|decision|artifact-ref|findings> --summary "<one line, no issue text>" --records <IDs> -- <paths the step wrote> ステップが書き込んだ、移動した、または削除したすべてのパスを渡します（昇格したドラフトの旧パスも含めます。ヘルパーは許可リスト内の削除もコミットします）。ライフサイクルの書き込み許可リスト（.adlc/drafts/adr/、docs/adlc/memory/adr/、docs/adlc/architect/AD.md、docs/adlc/architect/views/）内のパスのみを渡してください。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、分析のみのパス）。実行ブランチにコミットがなければ何も開かず、レビュー対象がないことがゲートに表示されます。同じ JSON オブジェクトに1行の conclusion も記入してください（ゲートの intent-conclusion ルール）。 ファクトリー実行では、このステップの後にあるエンジンのゲートが承認そのものです。自分で承認を求めないでください（「implement を承認しますか？」などとは尋ねません）。課題に必要なステップを完了し、open-mr.sh を実行して、結論を述べてから戻ってください。

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