-
界面走查（真 server + HTTP + 真 AgentManager，底层 mock 协议）已把 manual 模式全流程点通：org 节点起子图 → 下钻 work graph → 单步 → 第 3 步触发回退（徽标 0/3→1/3、run 级 1/5 双层计数同时可见）→ 归因记录与 remediation_note 完整送达 → 收敛后父节点结算、左栏前移。 mock 侧补两处缺失接线（都是「四环漏一环」，非新功能） - ClaudeCliProtocol._sendMockPrompt 按 agent 类型查 fixture：图执行侧的 agent 名带公司前缀（resolveAgentName 返回 {cid}:{id}），fixture 不该 按公司复制一份。DevLoop 侧名字不含冒号，行为不变 - graph-engine.defaultAgentExecutor 接住 mock/files 事件：此前只有 DevLoop 的 loop-controller 接，图执行侧没接，于是 mock 下 readNodeProduct 永远找不到 attempt-{n}.json，validator 系节点恒 blocked。 写入限制在节点产物目录内，越界丢弃并留痕 新增 5 份 P3 fixture（workgraph-planning / prd-planning / sdd-planning / coder-validator / validator-triager），coder-validator 用 sequence 演示 一次回退。图必须放 chunks 不能只放 result——callAgent 的 output 来自 流式 chunks，session/result 的文本不进 output。 控制台入口：CompanyDashboard 加「🕸️ 执行控制台」按钮（路由早已注册， 此前无任何入口，只能手敲 URL）。 scripts/p3-demo-setup.js：手工测试准备脚本（雇人+写图+起 run），头部 写明它是两个已知缺口的绕行，缺口修好后第 1 步即可删。 _registry.json 补齐 6 条本体登记（brd/prd/sdd-planning、goal-benchmark、 benchmark/testdata-validator）——同轮新增的 template-refs 防线测试正是 因为缺这 6 条而变红，防线抓到了「交付与报告不符」。 文档 - 27-REQ R-18：招聘归 workgraph-planning（方案 a）、停用 mock 改真 CLI - 27-P3B 真实运行前置（新增）：11 个工作项分三批，含现状核实 10 条证据 （seedTemplates 无运行时调用方、10 条悬空 company_hired 行、 FAILING_VERDICTS 不含 "fail" 导致验收假放行等） 测试 719/719 全绿（66 文件）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> -
R-16（归因由专职 subagent 做，回退边多条）： - §四.D.2.2 归因改为 org-validator work graph 内的 validator-reflection 专职节点，与 DevLoop 的 Integrator/BugTriager 分工同构；给出四类 fail_reason 取值与 DevLoop 四分类的对照 - §四.D.0 子 run 收敛改为透传三值（success/fail + fail_reason + remediation_note），归因结论才能穿透子 run 边界供父层选边 - §四.D.2.1 熔断改为双层计数：单边 loop_count 防同路径死循环，新增 run 级 backward_count 防"换个借口继续退"——多条回退边各自计数会把 硬顶架空成 3xN；infra_flake 不烧任何计数 - §三.7 写入前校验新增第五项 fail-fallback-edge（强制兜底边） - schema：graph_runs 加 backward_count - 任务表加 T13/T14，验收标准加 9b/9c/9d - skill_defect 属 L4，v1 保留归因取值但动作降级为挂起等人工 base agent 四段式（新增 §九bis）： - 核实后原表述"已强制一套四段式生命周期"只对一半 - Context Flush / P0 事前阻断阀 / OKR 联动确实在跑 - Hot Swap 换技能包静默失效：system/skills/ 目录不存在， agent-chat.js:1908 的 existsSync 守卫使其空转且不报错 - 后果：EXECUTE 才拿破坏性权限只剩 prompt 话术约束，无机制保障 - phase 参数无取值/顺序校验，且被直接拼进文件路径 需求文档：补回 R-15.1 全文、R-15.4 后半、R-15.5、R-15.6 及速查表 对应行（此前被误回滚丢失），新增 R-16 条目。R-15.3 的命名表保留 NAMING §三 重写后的版本，未还原旧版。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
-
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>