52. DevLoop 子系统退役

日期: 2026-09-17 状态: ✅ 已执行。这是一条决策记录，不是设计方案。 决策人: yibo（用户），基于对 27 号系列 P6（DevLoop 收编）的评估结论拍板

---

一、结论

DevLoop 本质架构是 loop workflow（L1/L2/L3 三层嵌套状态机，PM→Architect→Coder→Tester→Integrator→Triager 六个固定角色），已经被 27 号系列的 graph workflow（graph-engine.js：org graph + work graph，节点/边/回退/熔断/并发全部泛化、可任意拓扑）替代——graph workflow 严格覆盖 loop workflow 的表达能力（loop 只是 graph 的一种退化形状：链式节点 + backward 边）。不再需要维护 DevLoop 的独立实现，予以退役。

这条决策不是"DevLoop 做得不好"——见下方"背景"一节，DevLoop 是照着一句具体的用户原话老老实实搭出来的可用系统，路线本身没问题。退役的理由是范围过时：graph workflow 建成之后，DevLoop 覆盖的场景（单个开发型公司走 PM→Architect→Coder→Tester→Integrator→Triager 固定六步）已经是 graph workflow 能表达的场景的一个真子集，继续维护两套并行实现只有成本没有收益。

二、背景：这条决策是怎么来的

1. 27 号总纲文档（27-graph-agent-architecture.md）原把"DevLoop 收编"列为 P6，写于 P3+P4 引擎动工之前（2026-08-15），原文判断是"P6 应前置……通用 Work Graph 引擎应当从 DevLoop 抽象而来，而不是平行发明后再回头合并"。
2. 2026-09-17，用户要求先评估 P6 再决定要不要做。评估（见下方"参考材料"）核实：P3+P4 引擎已经独立建成并全部收口，是"平行发明"的产物——这条判断从写下的那天起就没能兑现，现实是两套系统各自成型。
3. 评估进一步发现 DevLoop 的设计初衷（docs/prd/newfunction/requirement.html，用户原话）是针对一个具体、窄范围的场景（"一句话需求 30 分钟内自动交付一个软件项目"，P4 演示日目标），不是通用架构；而 27 号系列的目标范围（任意公司、任意类型工作）从一开始就更宽。
4. 用户据此判断：DevLoop 的 loop workflow 本质是 graph workflow 的一个特例，graph workflow 已经建成且能覆盖 DevLoop 的场景，没有必要再维护/迁移 DevLoop 这套独立实现——直接退役，不做 P6 迁移。

三、实际状态核查（退役前，确认没有在制品数据会被影响）

• data/companies/*/projects/ 下没有出现过一个 DevLoop 的业务标记文件（project.json，由 LoopController.createProject 写入）——DevLoop 建成以来从未跑过一个真实项目，只有 mock 测试 + 一次人工冒烟跑（scripts/real-pm-smoke.js）。
• /api/devloop 路由虽然一直挂载在 server/index.js/server/agent-server.js，但没有前端导航入口指向 /devloop（web/src/router/index.js 里的四条路由是孤儿路由，要直接敲 URL 才能到达）。
• 结论：退役不影响任何生产数据或正在进行的工作。

四、退役范围与处理方式

删除（DevLoop 专属，无其他调用方）

• server/routes/devloop.js
• server/src/core/devloop/（loop-controller.js）
• server/services/devloop/{unit-registry,git-vault,timeline-logger,bug-tracker,changelog-writer,sse-broker}.js
• server/src/tools/devloop/（DevLoop agent 可调用工具全集）
• server/public/devloop-status.html
• server/tests/devloop/（21 个测试文件）
• web/src/views/DevLoop{Dashboard,NewRequirement,Ops,Projects}.vue
• web/src/components/devloop/（12 个组件，含 ops/ 子目录）
• web/src/router/index.js 里的 4 条 /devloop* 路由
• system/agents/devloop-{pm,architect,coder,tester,integrator,triager}/（6 个 agent 本体目录）+ system/agents/_registry.json 里对应的 6 条条目
• fixtures/devloop-mock/devloop-{pm,architect,coder,tester,integrator}.json（DevLoop 专属 mock fixture）
• fixtures/devloop-mock-scenarios/（四分类归因场景 fixture，只有 DevLoop 测试用过）
• server/index.js/server/agent-server.js 里 app.use('/api/devloop', ...) 挂载行
• server/tests/unit/route-auth-gate.test.js 里对 devloop.js 的单条断言
• package.json 的 spec:extract/spec:check 两条 npm script
• scripts/git-hooks/pre-commit（唯一职责是校验 docs/prd/newfunction/*.html 与 _spec/ 同步，DevLoop 退役后这条校验没有存在意义）

保留（其他现役代码依赖，不能删）

• server/services/devloop/path-resolver.js——graph-engine.js 的 ensureProjectRoot（27-P4 项目根分配）、company-service.js 的 linked-* 模式校验直接 require 这里的 allocateProjectRoot/isSensitivePath/resolveFixedTarget/validateLinkedTarget。文件顶部已加注释说明现状。
• server/services/devloop/doc-store.js——hashContract/verifyContractHash/canonical 被 graph-engine.js（重试级联判据）和 goal-contract.js 直接 require。文件里其余 PRD/SDD 读写逻辑已是死代码，留着是因为跟共享部分揉在同一个文件、拆分不值当；文件顶部已加注释区分两半。
• fixtures/devloop-mock/ 目录本身（含 default.json/prd-planning.json/sdd-planning.json/workgraph-planning.json/orggraph-planning.json/benchmark-validator.json/coder-validator.json/validator-triager.json）——ClaudeCliProtocol mock 模式按 agent id 从这个目录回放，27-P3/P4 的真实链路测试（graph-real-chain-smoke.test.js 等）直接用这里的 fixture。目录名字历史上带着 "devloop" 前缀，但内容和用途早已不是 DevLoop 专属，改名的收益（消除命名歧义）不值得牵动所有引用它的测试文件，本轮不动。
• server/tests/unit/work-graph-skeletons.test.js——原来用 devloop-{architect,coder,tester,integrator} 当占位符（因为 work_graph_nodes.system_agent_id 是外键，占位符必须指向真实存在的 system_agents 行）。随 system/agents/devloop-* 一起删除会导致外键校验失败，已改成指向其他真实存在的现役 agent（sdd-planning/coder/coder-validator/org-validator），测试本身不关心占位符的语义贴合度，已验证改动后 5 个用例全绿。

归档（不删，移入 docs/_archive/）

• docs/prd/（含 newfunction/、chapters/、assets/、scripts/、index.html、_scan-manifest.json）——DevLoop 完整 PRD/SDD 规格站点（52 页 HTML + _spec/*.md 机器可读版 + 一套平行的 10 章精简版），移到 docs/_archive/devloop-prd-2026-09-17/prd/。
• build-manifest.json（仓库根）——DevLoop SDD 抽取产物，移到同一归档目录下。
• scripts/extract-spec.js/extract-agent-prompts.js/build-search-index.js/extract-manifest.js/phase0-verify.js——DevLoop 专属的 HTML↔MD 抽取/校验工具，移到 docs/_archive/devloop-prd-2026-09-17/scripts/，留作历史参考，不再是活跃工具链的一部分。

五、CLAUDE.md / docs/README.md 同步

• CLAUDE.md 的「DevLoop 子系统」整节、快速启动里的 spec:extract/spec:check 命令、目录速查表里 DevLoop 相关行、API 路由表里的 /api/devloop/projects、两个 server 入口挂载路由列表里的 /api/devloop——全部改成一句退役说明，指回本文档。
• docs/README.md「未纳入整理的目录」一节里 prd/ 那条说明（原文"DevLoop 的 PRD/SDD 规格站点源文件……不是待归档的说明文档"）——这句判断已经不成立，改成指向归档位置。
• 27-graph-agent-architecture.md §六 P6 那一行——从"应前置"改成"已拍板不做，DevLoop 退役"，指回本文档。

六、影响范围之外、本轮没有处理的事

• system/agents/*/conversations/、system/tasklog.bak-unify/、各 agent 的 memory.md/todo.md 里提到 devloop-architect 等 id 的历史记录——这些是过去真实发生过的对话/任务记录，不是代码依赖，如实保留，不做清理。
• data/companies/*/projects/ 下已存在的项目目录——这些目录是 graph-engine（不是 DevLoop）创建的，路径格式历史上由 DevLoop 首创（path-resolver.allocateProjectRoot），两者共用同一份分配逻辑，退役不影响这些目录。
• fixtures/devloop-mock/ 目录改名——见上方"保留"一节，评估后判定不值得做，不是遗漏。

七、参考材料

• P6 评估报告（后台调研产出，未落盘为独立文档，结论已吸收进本文档 §一/§二）：核对了 27-graph-agent-architecture.md、27-e2e-task-execution-flow.md、loop-controller.js、unit-registry.js、graph-engine.js、DevLoop 与 graph-engine 两边测试套件规模，产出过一份能力对照表与真实断点清单——因为最终决策是"整体退役"而非"部分迁移"，那份对照表本身不再有实施指导意义，不单独归档。
• docs/_archive/devloop-prd-2026-09-17/prd/newfunction/requirement.html——DevLoop 设计源头，用户原话 + 结构化解析（R1-R6 硬约束 + H1-H3 隐含约束）。
• docs/_archive/devloop-prd-2026-09-17/prd/newfunction/_spec/prd-background.md——DevLoop 要解决的具体痛点、北极星指标（P4 演示日：