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，然后将一行 conclusion 写入 ADLC_STEP_OUTPUT。无论结果如何，即使没有任何更改，也要执行。
4. 绝不请求批准或等待回复。此步骤之后引擎的关卡就是审批；在这里提问会导致步骤结束，且不会发布任何内容。

只有此编排器可以提交、推送和创建 MR，且只能通过这些辅助脚本执行；生命周期技能绝不会执行这些操作。详情请见：分支运行、步骤提交与草稿 MR。

---

此技能的功能

factory-intent 在两条路径上编排意图生命周期。它协调产品生命周期技能（product-init、product-specify、product-clarify、product-implement、product-analyze）和架构生命周期技能（architect-init、architect-specify、architect-clarify、architect-implement、architect-analyze），根据单个 Mission Brief 维护一致的 PRD.md 和 AD.md。

它遵循 factory-mission/references/executor.md 中的共享执行器引擎契约，作为 Kind-A DAG 编排器运行。它用一个双路径 DAG 取代两个并列编排器，不设别名。

---

何时使用

• 你想从一个意图端到端梳理产品需求和架构决策，并让每项内容都在各自的关卡上签署。
• 你想使用带有验收关卡、经过验证且包含恢复检查点的引导式定义流程。

不应使用的情况：

• 执行软件实现任务（请改用 factory-mission）。
• 处理已完成意图阶段的单路径后续任务（直接调用对应路径的技能）。

单路径运行（路径激活）

当 Brief 只需要一条路径时，请运行该路径的入口工作流，而不是双路径的 workflow.yml：

• 仅产品 → workflow-product.yml（specify → clarify → gate-decisions → build-and-verify，产品命令，范围限定为 PDR 的关卡）。
• 仅架构 → workflow-architecture.yml（结构相同，使用架构命令，范围限定为 ADR 的关卡）。

每个入口都以关卡上下文契约（记录／起点／链接）映射已移除并列编排器的步骤结构；自适应执行器也会在调度时以相同方式解析其 route 输入。

---

生命周期 DAG 与步骤解析

factory-intent 实现了一个固定命名技能 DAG（fixed 步骤解析），每个路径在每个阶段各有一个步骤：

Greenfield 路径（空项目时的默认路径）

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）。

Brownfield / 刷新路径

每个泳道的路径输入（product_route、architecture_route）会分别选择 greenfield / brownfield（init）/ 刷新（先分析）—— 一个泳道可以刷新，同时另一个泳道执行 greenfield。自适应（LLM） 执行器会在分发时解析路径（为每个泳道选择 init、specify 或 先分析）；下方纳入版本控制的 workflow.yml 编码的是无头执行的 greenfield 默认值（specify 泳道）。

---

边界与裁决

产品泳道决定 WHAT / WHY / FOR WHOM（问题、用户画像、范围、优先级、 业务指标、NFR 目标）。任何回答 HOW 的内容（技术栈、模式、接口、NFR 机制）都记录为交接给架构泳道的备注，绝不作为产品决策。重叠争议升级给指定的人类；裁决以 decision 输出的形式发布到评论总线 （人类裁决，不自动解决）。自适应执行器不得运行联合 implement，直到人类裁决结果发布（纳入版本控制的 workflow.yml 编码的是 greenfield 双关卡默认值；裁决等待在分发时强制执行，而不是通过该文件中的关卡实现）。

---

共享执行器覆盖项

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），此编排器——且只有它，绝不是各泳道生命周期技能——会提交并推送运行分支、打开草稿 MR，且始终通过以下三个辅助脚本完成：

1. 第一步之前： bash {REPO_ROOT}/.agents/skills/factory-mission/scripts/bash/run-branch.sh —— 在项目根目录检出 factory/intent/<repo>-<iid>（来自 ADLC_ISSUE_REF），复用现有分支或从 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）。它会输出 sha: <sha> 或 sha: none；将该 sha 写入步骤的总线标记（总线传递的是指针，而非内容）。绝不要暂存 .adlc/workflows/**。
3. 返回之前，始终执行： bash {REPO_ROOT}/.agents/skills/factory-mission/scripts/bash/open-mr.sh —— 只推送运行分支，查找或打开一个草稿 MR（合并提交，不使用 squash；里程碑/负责人按 MR 归属决策确定），并将 mr_url 写入 ADLC_STEP_OUTPUT，引擎的门禁会链接到该地址（context.link）。无论结果如何，都要调用它——即使没有提交内容（sha: none，仅执行了分析）：如果运行分支上没有提交，它不会打开 MR，门禁会显示没有内容需要审核。还要在同一个 JSON 对象中写入一行 conclusion（适用于门禁的意图结论规则）。 在工厂运行中，引擎在此步骤之后的门禁就是审批：不要自行请求审批（不要问“是否批准 implement？”）——完成议题所需的步骤，运行 open-mr.sh，陈述结论并返回。

在工厂运行之外，除非用户选择启用（在 .adlc/init-options.json 中设置 adlc.commit_steps: true，或向此技能传入 --commit，再由你转交给 commit-step.sh），否则这些辅助脚本不会执行任何操作；没有 ADLC_RUN_ID 时，run-branch.sh 和 open-mr.sh 绝不会执行。如果辅助脚本以非零状态码退出（路径被拒绝、缺少提交者身份、跟踪器范围问题），则停止运行——报告问题，不要尝试绕过。