-
改名：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>
