-
前一提交（c03ae10b）的 git add 因命令里混了一个已失效的 pathspec 而整体失败， 只有此前单独 git mv 出去的改名部分被记录下来，实际的引用修正全部漏提交。 补上：docs/README.md 索引（todo 表挪到 done 表 + 顶部状态行）、其余 27 系列 文档里指向该文档的相对链接（todo/ 与 done/ 下深度不同，分别处理）、 system/agents/*/agent.md 与 tools.md 里 cwd 深度 3 的 ../../../../../ 相对引用 （agent-md-refs.test.js 会校验这些链接真实可解析到文件）、_registry.json 的 description 字段、work-graph-templates/README.md、server/ 源码里的设计文档路径注释。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JnCKUFSGvdz4SY7BvYWdMU
-
按 docs/README.md 既有约定（done/ 放「已实现/当前有效」），把两份已落地的 阶段设计文档移入 done/system-design/： - 27-p1-virtual-reference.md P1 虚拟引用寻址，commit 226489d - 27-p2-org-graph.md P2 Org Graph，70a4727 + f20d0d8，真实建公司端到端验证过 用 git mv 保留历史（R098 / R087）。移动断掉的 33 处相对链接已全部修复： moved 文件内的出向链接改 ../../todo/system-design/，todo/ 下 6 个文件的入向链接 改 ../../done/system-design/。全 docs/ 扫描无断链。 README 此前严重过时——只列了 2 份 27 文档，实际已有 11 份。本次补全 todo/ 表格， 每份标注状态与作用（总纲 / 需求源头 / 命名规范 / 端到端 / 参考场景 / P3+P4 已实现 / 验收契约 / P4 设计中），并在 done/ 表格补上 P1、P2 两行。 ■ 刻意没有移动 27-p3-p4-work-graph-console.md 它虽然已实现（c3abf4a），但文档正被另一进程持续修改（工作区 M 状态）。 移动会打断它的编辑路径，等它收尾后再归档。 ■ 三份文件的链接修复留在工作区未提交 27-naming-conventions.md / 27-p3-p4-work-graph-console.md / 27-requirement.md 里，我的链接修复与另一进程的在途编辑混在同一文件中，单独拆分风险大于收益。 工作区内容是正确的（链接已指向新路径），会随它下次提交一并带上。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
按 27-p3-p4-work-graph-console.md v0.3 实现，三轮开发+校验后测试全绿 （693/693，P2 26/26、DevLoop 230/230 未被打破，web:build 干净）。 服务层 - work-graph-db.js 定义层(work_graph_*) + 运行时层(graph_runs/graph_run_nodes/ graph_run_loop_records) 五张表；状态转换表照 unit-registry 模式； 复用 org-graph-service 四项校验 + 新增第五项 fail-fallback-edge - graph-engine.js advanceOne 幂等原语；agent_call / subgraph 两种 executor； 手动与自动共用同一原语；双层熔断（单边 loop_count + 按 root_run_id 共池的 backward_count）；任务级预算挂 root run；三层暂停/停止级联； 重试按 contract_hash unchanged 判据 - graph-run-sse.js 按 run_id 广播，状态转换+timeline+SSE 三者原子化 - goal-contract.js 验收契约格式与执行器（R-15.6 验收先行） 引擎泛化（R-15.4）：org graph 与 work graph 走同一套 advanceOne， 定义层两套、运行时层一套，三层下钻用 parent_run_id 链。 R-16 失败归因：validator-reflection 专职归因节点；fail_reason 多边路由 （精确匹配→兜底边→死路）；子 run 收敛透传 success/fail + fail_reason + remediation_note 三值；infra_flake 不烧任何计数。 路由 / 前端 / 模板 - routes/graph-run.js 八个端点；company.js 任务入口 - WorkGraphCanvas.vue 扩展 UnitsDAG（subgraph 角标、backward 虚线曲线、 N/3 循环徽标、异常流程视觉降权）；GraphConsole.vue 三栏 + 四 tab 详情 - 五个新 agent 模板：validator-reflection / org-validator / planner-validator / coder-validator / workgraph-planning 命名统一（R-15.3 + NAMING §三）：org 节点改为 org-{职能}， 三个 org-graph 模板末节点收敛到 org-validator；org_graph_edges 加 fail_reason 列并把唯一索引补上该列（避免精确边与兜底边互相吞掉）。 三轮校验修掉的主要缺陷：subgraph 重跑不起新子 run 导致永久死锁； SSE/timeline 零调用方；org 侧 fail_reason 写入被丢弃；fail-fallback-edge 只做了一层；backward_count 跨 run 树重置架空熔断外层； seedEntryNodes 误点亮只有 fail 入边的节点。 已知缺口见后续提交：remediation_note 仅在 backward 边落库、 total_tokens 预算维度无生产方。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
命名轴从「业务领域」({domain}-{职能}) 改为「所在图的层级」： org graph 节点 org-{职能} org-planner / org-coder / org-validator work graph 节点 {父 org 节点全名}-{职能} org-coder-validator 三个模板因此首尾同名，只有中段职能不同——规划和验收本身不分领域： dev org-planner → org-coder → org-validator content org-planner → org-writer → org-validator ops org-planner → org-monitor → org-validator ■ NAMING §三 补上此前完全缺失的一条轴：节点名 ≠ 本体名 R-15.3 指出的关键区分。禁止裸用 validator 的理由是「一家公司内两个节点不能 重名」，该理由针对节点、不针对本体。本体若被迫带前缀，coder-validator 会复制成 org-coder-validator / content-coder-validator 多份，与 P1「同一份本体、多处引用、 各自私有语境」直接冲突。落到 schema 上就是 node_name / system_agent_id 两个字段。 同时写入 §3.3（三个 validator 是三个独立本体，验的东西本质不同，与 §八bis 「不特化」原则不冲突）与 §3.4（存量 agent 归位：innovator→org-innovator、 hunter→innovator-hunt、digester→innovator-digest、evolver→innovator-evolver， 依据是 retrain-pipeline.js 里三者就是 innovator work graph 的三阶段）。 §3.4 顺带解决 27 号文档 §七 挂了很久的 6 个命名冲突 id。 ■ 代码层已改 system/org-graph-templates/{dev,content,ops}.json + README、 system/templates/orggraph-planning/{agent.md,tools.md} ■ 代码层未改（已在 §3.4 末尾标注） §3.4 的四个存量 agent 重命名需要单独一次迁移（目录改名 + system_agents 表 + retrain-pipeline.js 等引用点），本次未做。 验证：三张模板图改名后实跑 validateGraph 仍全部通过四项校验； npm run test:unit 676 全绿；test-company-e2e 114/114。 未触碰 27-p3-p4-work-graph-console.md（另一进程正在做 P3 开发，且其中命名已符合 R-15.3）与 27-requirement.md（原文照搬文档）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
改名：task-benchmark / task-test-data / task-test-script → goal-benchmark / goal-test-data / goal-test-script 理由（推翻此前"验收标准跟着一次 task 执行走"的论证）：关键区分是基数。 一个人类需求描述 = 1 个 goal，是验收的边界；而 goal 在图中会分解出 N 个 task （并行分支、下钻的 sub agent）。验收回答的是"人类想要的东西做到了没有"， 这是 goal 级判定；挂在 task 上会导致"以哪个 task 的验收为准"无法回答。 NAMING §一 作用域表补入 goal / task 两行及其基数定义；§四 重写选型理由； §六 增加与 §四 的辨析注（OKR 从 goal 解放后，goal 被重新赋予"人类需求"新义）。 连带： - acceptance.json 的键改为 goal_id - work_graphs schema 补 goal_id，与 okr_node_id / task_id 并列（三者基数不同， 分别是 1 / 长周期归属 / N，不能用单一字段表达） - 新增 27-REQ R-12 记录本次决策及其推翻关系 修复上一轮的一处失误：全局改名误改了 27-REQ 中的原话引用（R-10 一度被改成 "goal-benchmark 或者 goal-benchmark"）。原文照搬文档不得被批量替换触及，已还原。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
此前 27 系列全部是对用户需求的转述与结构化解读，原话一句都没留存 （搜 "judge-loop-jump"、"元 agent 架构来继承生成" 等关键短语均 0 命中）。 转述会漂移，出现"当初到底怎么说的"争议时缺少可回溯的依据。 格式与定位对齐仓库既有惯例 docs/prd/newfunction/_spec/requirement.md （DevLoop 的原始需求页："用户提出的需求原话照搬，再做结构化解析"）。 内容：11 条需求原话逐条照搬（R-1..R-11），含笔误一律保留 （validtor / syste agent / intergration / fin in / object-key result）， 每条标注落在哪份文档的哪一节，附"需求 → 设计落点"速查表。 同时记录三处关键推翻关系，便于回溯设计演变： - R-7 推翻了"benchmark/test data 是系统基础设施"的误读 - R-9.1 推翻了 P2 v0.1-v0.3 的静态汇报结构建模及 A/B/C 三个折中方案 - R-9.4 使跨公司污染风险及其三个缓解方案全部作废 另澄清 27-EXAMPLE 的「配图工厂」是为走查虚构的场景，非用户原始需求。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
新增四份文档： - 27-e2e-task-execution-flow.md — 跨阶段总览：建公司 → 下达任务 → org graph 逐节点执行 → work graph 规划与循环 → 验收收敛。核心发现：这套流程 70-80% 已在 docs/prd/newfunction/_spec/ 里被完整设计（DevLoop 的 L1/L2/L3 三层循环、 BugTriager 四分类归因、分级预算熔断、contract_hash 闸门），DevLoop 实为本 架构唯一跑通的参考实现，通用引擎应从它抽象而来。 - 27-example-dev-company-walkthrough.md — 参考场景走查，把架构在一家具体公司 上跑一遍数（各阶段 JSON 形态、fan-out/fan-in 图、成本估算 ~44 次调用、 按阻塞程度排序的 8 个断点清单），作为实现靶子与端到端验收场景。 - 27-naming-conventions.md — 统一命名规范 {作用域}-{职能}。消歧三种 benchmark （skill- / agent- / task-）；OKR 体系正名（goal → okr，第 1 层 Goal → Objective）； 规划类统一为 orggraph-planning / workgraph-planning / brd-prd-sdd-planning。 - 27-p3-p4-work-graph-console.md — P3/P4 合并设计：Work Graph 执行引擎（支持 启动/下一步/暂停/停止/重试，手动与自动共用同一 advance 原语）+ 执行控制台页面。 重写 27-p2-org-graph.md 至 v0.4：Org Graph 从「静态汇报结构」重定位为 「company 级别生成的 workflow」，与 Work Graph 同构（condition/edge_kind 执行流边）， 两层共用同一套 schema、执行引擎与画布组件。org_graph_edges 从未写入过数据， 可直接 DROP 重建，零迁移负担；hire() 不再需要 reportsTo（图整体规划整体写入）， P2 对 company-service.js 的侵入缩至零。 同步修正总纲至 v0.3：Org Graph/Work Graph 术语定义、§3.1 架构图、§3.3 整节； 标注 P1 已实现（226489d）；P6「DevLoop 收编」从「可选」改为「应前置」。 修正三处过期陈述：P1 已实现（非设计稿）、runProject 已完整实现（非 501）、 UnitsDAG.vue 已实现 Kahn 分波 DAG 渲染（画布应扩展而非重写）。 并记录一处待处理冲突：graph-service.js:44 已落地的全量唯一索引与 P2 需要的 部分唯一索引冲突，实现 T1 时必须先 DROP。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>