# 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 演示日：<30 分钟、<50 万 token）、非目标声明。