factory-init

factory-init

このスキルの機能

factory-init は、統合されたブラウンフィールドのブートストラップを調整します。既存のコードベースをリバースエンジニアリングし、3 つすべてのプロジェクトメモリレイヤーに反映して、それらがコードとどの程度整合しているかを測定するコマンドです。

リーフライフサイクルスキルである product-init、product-clarify、product-implement、product-analyze、architect-init、architect-clarify、architect-implement、architect-analyze、change-init、change-clarify、change-publish を直接調整します。ピアオーケストレーターである factory-product／factory-architect／factory-learn は決して調整しません。

独自の最終ステップであるスイープは、ファクトリー内で唯一のレイヤー横断分析です。カバレッジマトリクス（.adlc/coverage/coverage.md）を作成します。これは機能領域のピボットと、4 つのトレーサビリティ関係 PDR↔ADR、PDR↔コード、ADR↔コード、ChDR↔コードで構成され、前回のスイープとの差分からドリフトを検出します。

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

スコープの境界：対象はプロジェクトローカルのメモリのみです（PDR、ADR、ChDR、およびコード）。チームコンテキスト指令（CDR／team-init）はここではブートストラップしません。これらは外部の team-ai-directives リポジトリに公開され、factory-learn が担当します。スイープの最終出力には、ブートストラップ中に見つかった再利用可能なパターンについて factory-learn／/team-init の実行を推奨する文章が含まれます。

---

使用するタイミング

• 既存のリポジトリ（コードが存在し、PDR、ADR、ChDR がない、または一部しかない）で ADLC を導入し、1 回の実行ですべてのブートストラップを行いたい場合。
• レイヤー横断の整合性監査（--refresh）を定期的に行いたい場合。文書化されていない決定、決定のないコード、プロダクトとアーキテクチャの不一致を確認できます。

使用しない場合：

• グリーンフィールド／空のプロジェクト → factory-product と factory-architect を実行します（ルートを指定）。
• 単一レイヤーの作業 → factory-product／factory-architect／factory-learn を直接実行します。
• CDR／チーム指令への貢献 → factory-learn。
• 機能の実装 → factory-mission。

---

ルートの分類

条件	ルート
コードが存在し、メモリレコードがない	ブートストラップ（全パイプライン）
.adlc/coverage/coverage.md が存在する、または --refresh が指定されている	リフレッシュ（スイープのみ）
部分的な状態	レイヤーごとのスキップを適用してブートストラップ（以下を参照）
コードがない	停止：グリーンフィールドです。factory-product／factory-architect のルート指定を使用します

レイヤーごとのスキップ — 各トラックは個別に分類します。あるレイヤーのメモリとコンパイル済みアーティファクトの両方が存在する場合、そのレイヤーは init／implement をスキップし、analyze のみ実行します。

レイヤー	init／implement をスキップする条件	常に実行
product	docs/adlc/memory/pdr/（従来の .adlc/memory/pdr/ にフォールバックし、いずれかが空でない）および docs/adlc/product/PRD.md が存在する	product-analyze
architecture	docs/adlc/memory/adr/（従来の .adlc/memory/adr/ にフォールバックし、いずれかが空でない）および docs/adlc/architect/AD.md が存在する	architect-analyze
change	docs/adlc/memory/chdr/（従来の .adlc/memory/chdr/ にフォールバックし、いずれかが空でない）および docs/adlc/memory/chdr.md が存在する	（ChDR はスイープに直接反映されます）

---

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

factory-init は固定の名前付きスキル DAG（ステップ解決方式は fixed）を実装します。トラックは順次実行され、各トラックの完了後に次のトラックが始まります。理由：人間がドメインごとに一貫したレビューセッションを行えること、architect-clarify が承認済み PDR の決定をコンテキストとして読み取ること（アーキテクチャはプロダクトを支えるため）、スイープが最も成熟した入力を受け取ることです。

ブートストラップルート（12 ステップ、3 つの確認ゲート＋最終マトリックスレビュー）

#	ステップ	スキル	フェーズ	output_type
1	product-init	product-init	生成	draft (.adlc/drafts/pdr/)
2	product-clarify⭐	product-clarify	確認	decision
3	product-implement	product-implement	構築	artifact-ref (docs/adlc/product/PRD.md)
4	architect-init	architect-init	生成	draft (.adlc/drafts/adr/)
5	architect-clarify⭐	architect-clarify (承認済み PDR リストを読み込み)	確認	decision
6	architect-implement	architect-implement	構築	artifact-ref (docs/adlc/architect/AD.md)
7	change-init	change-init	生成	draft (.adlc/drafts/chdr/)
8	change-clarify⭐	change-clarify	確認	decision
9	change-publish	change-publish	構築	artifact-ref (docs/adlc/memory/chdr/)
10	product-analyze	product-analyze	分析	findings
11	architect-analyze	architect-analyze	分析	findings
12	sweep	インライン（このスキルの「スイープステップ」§）	分析	findings (.adlc/coverage/coverage.md ＋履歴)

リフレッシュルート（1 ステップ＋ループ）

#	ステップ	フェーズ	output_type
1	sweep（再スキャン＋再構築＋ドリフト差分）	分析	findings

修正ループ

• product-analyze / architect-analyze の CRITICAL/HIGH → 各自のトラックの確認⭐に戻ります（エグゼキューターのデフォルト動作。max_corrections で上限を設定。デフォルトは 2）。
• sweep の CRITICAL/HIGH 検出結果はレイヤータグ（ADR-361）に基づいてルーティングされます。各検出結果には [layer: product|architecture|change|cross] が付与され、対応するトラックの確認（product-clarify / architect-clarify / change-clarify）にルーティングされます。cross の検出結果は、引用された記録を所有するトラックにルーティングされます。曖昧な場合は、人間による確認のために停止します（ハイブリッドゲート）。max_corrections で上限を設定します。

---

スイープステップ（インラインの複合ステップ）

スイープは、このオーケストレーター（ステップ skill: factory-init、プロンプト＝このセクション）によって実行されます。リーフスキルによる実行ではありません。

入力（すべて読み取り専用）

| ソース | 取得内容 | |--| | product-init ＋ architect-init のセットアップスクリプト（再実行。冪等な JSON スキャナー） | サブシステム、機能領域、技術スタック | | docs/adlc/memory/{pdr,adr,chdr}/（レガシーの .adlc/memory/ をフォールバックとして使用、＋インデックス） | レイヤーごとの承認済み決定 | | docs/adlc/product/PRD.md、docs/adlc/architect/AD.md | コンパイル済みアーティファクト | | .adlc/coverage/coverage.md（存在する場合） | 前回のマトリックス → ドリフト差分 |

出力：.adlc/coverage/coverage.md（および history/<date>-<run_id>.md）

1. ピボット：領域カバレッジ — 行軸はサブシステム ∪ 機能領域の和集合です。名前やディレクトリの重複を照合し、マッピング列で対応付けます。照合できない行は分けたまま、フラグを付けます。すべてのセルに根拠（レコード ID、ファイルパス）を記載します。セルを捏造してはいけません。

## Pivot: Area Coverage

| Area | Feature-Area | Sub-System | PDRs | ADRs | ChDRs | Code Evidence | Coverage |
|------|--------------|------------|------|------|-------|---------------|----------|
| payments | billing | payments | 3 | 1 | 4 | present (src/payments/) | 62% |

2. 関係 — 4 種類の双方向ペアワイズ関係です。各セクションには Coverage: N% の行と、レコード ID またはパスを引用したギャップの行を記載し、それぞれに [layer: ...] を付けます。

関係	ギャップの方向
PDR↔ADR	アーキテクチャ上の裏付けがないプロダクト上の決定、プロダクト上の根拠がない孤立した ADR（自動的に不具合とはせず、重要度は MEDIUM）
PDR↔code	決定済みだが未実装、実装済みだが未文書化
ADR↔code	決定済みだがコードに反映されていない、ADR に記録されていないコードパターン
ChDR↔code	ADR がない ChDR 密集領域（進行中の変更にアーキテクチャ記録がない）、現状と一致しなくなったコードを記述する ChDR（決定が置き換えられている）

PDR↔ADR のマッピングには、レコード間のテキスト上の重複が必要です。これは提案であり、断定ではありません。

各ギャップの行は次の形式にします。

- Gap: <description citing PDR-NNN / ADR-NNN / ChDR-NNN or a file path> [layer: product|architecture|change|cross]

3. 重要度モデル（ファミリー標準）：規約違反 = CRITICAL、承認済みの決定にコードが反する = HIGH、未文書化／未決定の不一致 = MEDIUM、未照合の領域、スタイル = LOW。

4. ドリフトセクション — ## Drift vs <previous date> sweep（初回のスイープでは ## Baseline）：新たなギャップ、解消したギャップ、後退した領域を記載します。更新時には、この差分がレポートそのものになります。

5. Findings 出力 — 重要度順の概要を output_type: findings として公開します（トラッカーと統合済みの場合はコメントバス、そうでない場合は runs/<run_id>/findings/sweep.md）。修正の振り分けのため、各 finding に [layer: ...] を付けます（ADR-361）。マトリックスファイル自体が成果物です。マトリックスはレコードを編集せず、報告と修正の明確化のみを行います。

---

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

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

1. 公開先：local に固定されます。出力は .adlc/（ドラフト、カバレッジ）と docs/adlc/（メモリレコード、docs/adlc/product/PRD.md、docs/adlc/architect/AD.md）に書き込まれます。トラッカーと統合済みの場合は、tracker の完了サマリーコメントも投稿されます。
2. 出力タイプ（PDR-050 に準拠）：初期化ステップ → draft、clarify⭐ → decision、implement/publish → artifact-ref、analyze + sweep → findings。
3. 監督の既定値：hybrid。人間による承認ゲートは、3 つの clarify⭐ ステップ（PDR、ADR、ChDR の承認）と最終的なカバレッジマトリックスのレビューで厳格に適用されます。
4. 事前チェック：product-*、architect-*、change-* のライフサイクルスキルがインストールされていることを確認します。チーム AI 指示の設定は不要です（CDR は対象外）。設定されていない場合も、architect-init によるチーム指示の重複排除は適切に機能低下します。
5. ワークツリー／リース／ハートビート：他の同階層のオーケストレーターと同様に、共有エグゼキューターの契約に従います。
6. CDR 引き継ぎの案内：スイープ後に（手順を追加せず、文章のみで）次を提示します。「ブートストラップ中に再利用可能なパターンが見つかった場合 → factory-learn または /team-init を実行してください。」

---

競合の解消

• factory-product／factory-architect の既存コードベース向けルートは、引き続き単一レイヤーのエントリーポイントです。factory-init は統合版です。レイヤーごとにスキップできるため、すでに一方のレイヤーが文書化されているリポジトリでは、再実行のコストを抑えられます。
• factory-learn の履歴マイニングルートは、進行中／段階的な ChDR マイニング（インシデント後、リファクタリング前）です。factory-init は一度限りの詳細なブートストラップ（全期間）です。どちらも同じ change-* リーフスキルを再利用します。
• team-init（既存コードベース向け CDR）には、現在ファクトリールートがありません。これは factory-learn における既知のギャップであり、ここでは対象外です。

---

注意すべき危険信号

• マトリックスのセルを捏造する — すべてのカバレッジセルとギャップには、レコード ID またはファイルパスを引用する必要があります。引用のないギャップはコンテキスト汚染です。
• PDR↔ADR のマッピングを断定する — マッピングは文面上の根拠に基づいて提案します。重複する記述なしに「これらは関連していると思う」とするのは捏造です。
• 黙って調整する — 機能領域とサブシステムを、マッピングを明示せずに統合したり、未調整の行をギャップとして示したりすると、製品とアーキテクチャの不一致が隠れてしまいます。
• 確認ゲートを省略する — スイープは ACCEPTED の決定を監査するため最後に行います。ドラフトや自動承認されたレコードをスイープすると、パイプラインの目的が損なわれます。
• 修正の振り分けを無条件に行う — スイープの指摘には [layer: ...] タグが必要です。すべてを「直前の確認」に送ると、製品上のギャップがアーキテクチャレビューに回されます。
• マトリックスがレコードを編集する — スイープは報告のみを行います。決定を変更できるのは、人間の承認を得た clarify⭐ ステップだけです。

検証

• 12 個すべてのブートストラップ手順が完了している（または、レイヤーごとのスキップが適用され、その理由が状態に記録されている）
• docs/adlc/product/PRD.md、docs/adlc/architect/AD.md、docs/adlc/memory/{pdr,adr,chdr}/ が、トラックごとに作成されている
• .adlc/coverage/coverage.md が作成され、Pivot（すべてのレイヤー列）、それぞれに Coverage: N% を含む 4 つの関係、レイヤータグと引用を含むギャップ行、Drift/Baseline セクションが記載されている
• 以前のマトリックスが .adlc/coverage/history/<date>-<run_id>.md にアーカイブされている
• すべてのスイープ指摘に [layer: ...] のタグが付いている。CRITICAL/HIGH の指摘は、該当するトラックの確認に回されている（max_corrections による上限あり）
• ハイブリッドモードで 3 つの確認ゲート（製品、アーキテクチャ、変更）と最終マトリックスレビューが実行されている
• 最終出力に CDR の引き継ぎ推奨が提示されている
• スイープ自体によって変更されたレコードが 0 件である

設定

• PDR_DRAFTS_DIR — {REPO_ROOT}/.adlc/drafts/pdr
• ADR_DRAFTS_DIR — {REPO_ROOT}/.adlc/drafts/adr
• CHDR_DRAFTS_DIR — {REPO_ROOT}/.adlc/drafts/chdr
• COVERAGE_DIR — {REPO_ROOT}/.adlc/coverage（coverage.md + history/）
• PRD_FILE — {REPO_ROOT}/docs/adlc/product/PRD.md | AD_FILE — {REPO_ROOT}/docs/adlc/architect/AD.md
• 共有実行状態 — adlc-cli workflow state ヘルパー経由の {REPO_ROOT}/.adlc/workflows/runs/<run_id>/state.json（ADR-395、リース／再開）

参考資料

• factory-mission/references/executor.md — 共有エグゼキューター契約（ステップスキーマ、フェーズ、修正ループ、出力タイプ）
• factory-mission/references/tracker-integration.md — コメントバス、マーカーコメント、分散リース
• PDR-072（factory-init スキル — ブラウンフィールドの統合ブートストラップ + カバレッジマトリックス）
• ADR-361（スイープにおけるレイヤータグ付き修正の振り分け）
• ADR-341（グラフとしてのワークフロー — 固定 DAG を選択。宣言型グラフも引き続き選択肢）
• PDR-050（出力タイプの分類 — draft/decision/findings/artifact-ref）
• factory-product/SKILL.md、factory-architect/SKILL.md、factory-learn/SKILL.md — 同階層のオーケストレーター。単一レイヤーのエントリーポイント