factory-learn

factory-learn

此技能的作用

factory-learn 协调软件工厂的持续改进学习循环。它协调各个与学习相关的技能（team-init、team-levelup、change-init、change-clarify、change-publish、team-repair、evals-analyze），将草案指令转化为经过验证、已发布且精简的团队上下文资产。

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

---

何时使用

• 你想将来之不易的会话经验提取并汇总到团队的中央 team-ai-directives 仓库中。
• 你想挖掘 git 提交历史，记录过去回退和紧急修复背后的理由（ChDR）。
• 你想运行“构建以删除”（Harness 衰减检查），清理冗余规则。

不适用场景：

• 用于产品级规格制定或开发（请改用 factory-product 或 factory-mission）。
• 团队指令仓库完全未配置时（请先运行 /team-setup）。

---

生命周期 DAG 与步骤解析

factory-learn 实现了一个固定命名技能 DAG（fixed 步骤解析）：

会话经验路线（默认在会话结束时运行）

1. specify（generate 阶段）-> 调用 team-levelup，从当前会话中提取候选上下文指令记录（CDR）和合规项。
2. clarify⭐（clarify 阶段）-> 调用 team-levelup，审核待处理的 CDR。执行 evals-regression 门禁（将合规金标集作为 verify 子阶段运行，确保质量没有下降）。
3. publish（build 阶段）-> 调用 team-levelup，打包已接受的 CDR、为其建立索引，并整理一份面向 team-ai-directives 仓库的草案 PR。
4. prune（analyze 阶段）-> 对指令存储运行清理机器人，检测并提议弃用已被取代、相互矛盾或过时的规则。弃用信息会反馈给 team-levelup。

历史挖掘路线（既有项目）

1. init（generate 阶段）-> 调用 change-init，从 git 历史记录和问题跟踪系统中挖掘变更决策记录（ChDR）。
2. clarify⭐（clarify 阶段）-> 调用 change-clarify，对挖掘出的主张进行交互式来源审查。
3. publish（build 阶段）-> 调用 change-publish，将已接受的 ChDR 纳入 docs/adlc/memory/chdr/ 并重新生成索引。

维护与构建以删除路线（定期运行）

1. verify（verify 阶段）-> 运行 team-repair --build-to-delete。临时禁用规则后，重新运行金标集评估。每条规则检查两个问题：
   • 构建以删除：如果模型在没有该规则的情况下也能通过，则将该规则标记为冗余。
   • 提升为检查（优先采用确定性检查，EVAL-010）：如果某项确定性检查（单元测试 / 二进制评分器 / pre-commit 钩子 / lint 规则 / CI 作业）能够通过机械方式强制执行该规则，则将其标记为可提升项——一次性为检查付出成本，而不是在每个会话中反复注入模糊规则。
2. clarify⭐ -> 向 team-levelup 提议弃用冗余规则，并将机械规则提升为检查，供人工审核。提升项会进入操作 P — 提升为检查（team-levelup Phase 2b）；检查一旦创建并在 CI 中运行，CDR 就会被弃用或精简为一个简短指针。两项提议都会以 findings 的形式发布。

工作流回顾路线

定期或按需运行，分析其他工厂技能（例如 factory-mission、factory-product）的过往运行记录，并生成工作流记忆：

1. analyze（analyze 阶段）-> 扫描已完成/失败运行的共享状态（通过 adlc-cli workflow status 查看 .adlc/workflows/runs/<run_id>/state.json）和证据文件。识别模式、反复出现的错误或成功的修正。
   • 同时检查 .adlc/drafts/{adr,pdr,chdr,cdr,evals}/ 中尚未澄清的条目（frontmatter/标题状态为 proposed/discovered/draft）；将每项都作为一条发现（草稿 ID + 类型 + 时长）列出，无论是否曾触发 session_end/file_edited 钩子。
2. clarify⭐ -> 向用户展示拟议的记忆（在 gated/hybrid 模式下），或自动批准（在 autonomous 模式下）。
3. publish（build 阶段）-> 将已批准的记忆写入 .adlc/workflows/memory.jsonl（工作区全局）。记忆包含权重和使用次数；过时或适得其反的记忆会自动归档。

---

共享执行器覆盖项

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

1. 发布目标：固定为 external-repo。在配置的 team-ai-directives 仓库中打开或更新草稿拉取请求。由于发布目标是 directives 仓库中的 PR，评论总线也会在该 PR 上运行——步骤输出（决策、发现）会作为标记评论发布到 directives PR。
2. 输出类型：步骤使用以下 output_type 赋值：
   • specify/init → draft（CDR/ChDR 草稿保留在 .adlc/drafts/ 中，不发布到评论总线）
   • clarify⭐ → decision（已接受/拒绝的 CDR/ChDR 列表发布到 directives PR 上的评论总线）
   • publish → artifact-ref（发布 PR URL 引用，内容保留在磁盘上）
   • prune/verify → findings（冗余/弃用报告发布到评论总线）
3. 反馈循环摄取：自动使用 evals-analyze 的输出（当应用测试因规范问题失败时，evals-analyze 会自动路由到 team-levelup，进而触发此协调器）。
4. 监督默认值：hybrid。在 clarify⭐（批准 CDR/ChDR 条目）和最终创建 PR 时，均强制设置人工审核关卡。
5. 飞行前检查：验证是否已安装 team-levelup、change-* 和 team-* 技能，并确认 .adlc/init-options.json 中已设置 directives 仓库路径。