-
company-goal / task-goal 按作用域命名，subagent-goal 按执行者命名，轴不一致。 统一为 subtask-goal。 27-REQ R-13.1 的原话引用保留提出时的用词「subagent-goal」不改写——原文照搬 文档不参与批量替换（这是上一轮误改 R-10 原话引用留下的规矩）。新增 R-14 记录 本次定名及其与 R-13.1 的关系。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
起因：逐条比对 27-REQ 的原话与 P2 v0.4，发现四处偏离，其中两处是设计悄悄 改变了原意。本次修正并落定。 代码（P2 §五 T0）： - company.json 新增 goal 字段（company-goal），create({id,name,goal,description}) - POST /api/company/create 与 update() 同步支持 - 修的是一个实打实的遗漏：R-6 原话是"写入 company 的目标和描述"（两个字段）， 而 create() 一直只有 description。orggraph-planning 规划流水线的主依据本该是 company-goal，此前根本拿不到。 文档定案（R-13）： - R-13.1 goal 三层递归：company-goal / task-goal / subagent-goal，与"验收逐层 递归"对应。澄清 R-12 说的"唯一的那个 goal"其实是 task-goal；三个验收 agent 保持通用不按层级拆分。记录一处待定：subagent-goal 按执行者命名，与另两个的 作用域命名轴不一致（按轴应为 subtask-goal）。 - R-13.2 公司类型完全由 orggraph-planning 推断 —— 这条**推翻了我自己记的一个 缺陷**：审计时我把"不加 type 枚举字段"记为擅自偏离原话，实际那正是所需， 当前设计无需改动。 - R-13.3 新 agent 从 system/templates/base 元 agent 继承骨架（自动带四段式 RESEARCH→PLAN→EXECUTE→VERIFY）+ agent-creator 填充，而非直接走 needs_training 全量培养；新建一律 scope='company'；innovator 训练是可选后置步骤。 这是 R-9.2"所有 node agent 由元 agent 继承生成"在 P2 的落地点（新增 T5b）。 - R-13.4 org graph 强制单入口，原 open question 关闭。 顺带修掉 P2 的一处内部不一致：§六 承诺"提供手动触发 orggraph-planning 的端点" 给存量公司补图，但 §四.3 API 表和 §五 任务表都没有。已补 POST …/org-graph/replan。 另更正 R-11 中"代码层未执行"的过期表述——OKR 正名已于 74ea1ff 实施完毕。 回归：npm run test:unit 652 例全绿。 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>
