factory-init

factory-init

此技能的作用

factory-init 编排统一的存量项目引导：通过一条命令，对现有代码库进行逆向工程，建立全部三个项目记忆层，并衡量它们与代码的契合程度。

它直接协调各个叶级生命周期技能——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。

其自身的最后一步 sweep 是工厂中唯一的跨层分析：它会构建覆盖矩阵（.adlc/coverage/coverage.md）——一份按功能领域透视的矩阵，以及四种可追溯关系：PDR↔ADR、PDR↔代码、ADR↔代码、ChDR↔代码——并与上一次 sweep 的结果进行差异比较，以检测偏移。

它遵循 factory-mission/references/executor.md 中共享执行器引擎契约，作为 Kind-A DAG 编排器运行。

范围边界：仅处理项目本地记忆（PDR、ADR、ChDR + 代码）。团队上下文指令（CDR / team-init）不会在此处引导——它们会发布到外部的 team-ai-directives 仓库，并由 factory-learn 负责。sweep 的最终输出会用文字建议：对于引导过程中发现的可复用模式，运行 factory-learn / /team-init。

---

适用场景

• 你要在现有仓库中采用 ADLC（已有代码，但没有或只有部分 PDR、ADR、ChDR），并希望一次性完成完整引导。
• 你想执行定期跨层契合度审计（--refresh）：哪些决策没有文档记录，哪些代码没有对应规范，产品与架构在哪些方面存在分歧。

不适用场景：

• 全新项目 / 空项目 → 改为运行 factory-product 和 factory-architect（指定路由）。
• 单层工作 → 直接运行 factory-product / factory-architect / factory-learn。
• 贡献 CDR / 团队指令 → 使用 factory-learn。
• 功能实现 → 使用 factory-mission。

---

路由分类

条件	路由
已有代码，没有记忆记录	引导（完整流水线）
.adlc/coverage/coverage.md 已存在，或指定了 --refresh	刷新（仅运行 sweep）
状态不完整	引导时按层跳过（见下文）
没有代码	停止：这是全新项目——使用 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 直接供 sweep 使用）

---

生命周期 DAG 与步骤解析

factory-init 实现一个固定命名技能 DAG（fixed 步骤解析）。各轨道依次运行——一个轨道完成后，下一个才会开始。原因：每个领域都让人工进行一次连贯的审查；architect-clarify 会将已接受的 PDR 决策作为上下文（架构服务于产品）；sweep 则能获得最成熟的输入。

引导路线（12 个步骤、3 个澄清关卡 + 最终矩阵审查）

#	步骤	技能	阶段	output_type
1	product-init	product-init	生成	草稿（.adlc/drafts/pdr/）
2	product-clarify⭐	product-clarify	澄清	决策
3	product-implement	product-implement	构建	制品引用（docs/adlc/product/PRD.md）
4	architect-init	architect-init	生成	草稿（.adlc/drafts/adr/）
5	architect-clarify⭐	architect-clarify（读取已接受的 PDR 列表）	澄清	决策
6	architect-implement	architect-implement	构建	制品引用（docs/adlc/architect/AD.md）
7	change-init	change-init	生成	草稿（.adlc/drafts/chdr/）
8	change-clarify⭐	change-clarify	澄清	决策
9	change-publish	change-publish	构建	制品引用（docs/adlc/memory/chdr/）
10	product-analyze	product-analyze	分析	发现项
11	architect-analyze	architect-analyze	分析	发现项
12	sweep	内联（此技能，§扫查步骤）	分析	发现项（.adlc/coverage/coverage.md + 历史记录）

刷新路线（1 个步骤 + 循环）

#	步骤	阶段	output_type
1	sweep（重新扫描 + 重建 + 漂移差异）	分析	发现项

修正循环

• product-analyze / architect-analyze 中的 CRITICAL/HIGH → 返回其自身轨道的澄清步骤⭐（执行器默认设置，受 max_corrections 限制，默认值为 2）。
• sweep 中的 CRITICAL/HIGH 发现项按层级标签路由：每个发现项都带有 [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. 关系 — 四种成对、双向关系；每个部分都有一行 Coverage: N%，并列出引用记录 ID 或路径的差距行，每行均带有 [layer: ...] 标签：

关系	差距方向
PDR↔ADR	没有架构支持的产品决策；孤立的 ADR（没有产品依据——MEDIUM，不会自动判定为缺陷）
PDR↔code	已决策但尚未实现；已实现但未记录
ADR↔code	已决策但未反映在代码中；没有 ADR 的代码模式
ChDR↔code	ChDR 密集领域没有 ADR（正在变更，但没有架构记录）；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. 发现项输出 — 按严重性排序的摘要以 output_type: findings 发布（与跟踪器集成时发布到评论总线，否则发布到 runs/<run_id>/findings/sweep.md）；每条发现项都带有 [layer: ...] 标签，以便路由修正任务。矩阵文件本身就是产物；矩阵绝不会编辑记录——它会报告并明确需要修正的内容。

---

共享执行器覆盖项

factory-init 按如下方式覆盖共享执行器引擎原语：

1. 发布目标：固定为 local。输出写入 .adlc/（草稿、覆盖率）和 docs/adlc/（记忆记录、docs/adlc/product/PRD.md、docs/adlc/architect/AD.md）。如果与跟踪器集成，还会发布一条 tracker 完成摘要评论。
2. 输出类型（依据输出类型分类）：初始化步骤 → draft；澄清⭐ → decision；实现／发布 → artifact-ref；分析 + 扫描 → findings。
3. 监督默认值：hybrid。在三个澄清⭐步骤（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 映射关系——映射必须基于文本证据提出；没有重叠文本却说“我们认为两者相关”就是编造。
• 悄然协调——将功能领域与子系统合并，却不标明映射关系（或将未协调的行标记为缺口），会掩盖产品与架构之间的分歧。
• 跳过澄清关卡——全面检查放在最后，是因为它要审计已接受的决策；检查草稿或自动接受的记录会破坏整个流程。
• 盲目分派修正——全面检查发现的问题必须带有 [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%）、带层标签且附有引用的缺口行，以及 Drift/Baseline 部分
• 已将上一版矩阵归档至 .adlc/coverage/history/<date>-<run_id>.md
• 每项全面检查发现的问题均已标记 [layer: ...]；CRITICAL/HIGH 问题已分派给对应跟踪流程的澄清环节（受 max_corrections 限制）
• 混合模式下已触发三个澄清关卡（产品、架构、变更）以及最终矩阵评审
• 已在最终输出中提出 CDR 交接建议
• 全面检查本身未修改任何记录

配置

• 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
• 共享运行状态 — {REPO_ROOT}/.adlc/workflows/runs/<run_id>/state.json，通过 adlc-cli workflow state 辅助工具访问（共享运行状态；租约/恢复）

参考资料

• factory-mission/references/executor.md — 共享执行器契约（步骤模式、阶段、修正循环、输出类型）
• factory-mission/references/tracker-integration.md — 评论总线、标记评论、分布式租约
• factory-init 矩阵（factory-init 技能——统一的棕地引导流程 + 覆盖矩阵）
• 带层标签的修正分派
• 将工作流视为图——已选择固定 DAG；声明式图仍是一个选项
• 输出类型分类（输出类型分类——草稿/决策/发现/制品引用）
• factory-product/SKILL.md、factory-architect/SKILL.md、factory-learn/SKILL.md — 同级编排器；单层入口