27-REQ · 原始需求
所属: 27 Graph Agent 架构 的需求源头文档。 版本: v0.1 日期: 2026-08-15 定位: 用户提出的需求原话照搬，再做结构化解析。本页是 27 系列所有设计决策的「源头」。 格式与定位对齐仓库既有惯例
docs/prd/newfunction/_spec/requirement.md（DevLoop 的原始需求页）。
为什么需要这一页
27 系列其余文档（E2E / P2 / P3-P4 / EXAMPLE / NAMING）全部是对下面这些原话的转述与结构化解读，包括 27-example-dev-company-walkthrough.md 里那个「配图工厂」场景——那是为了走查而虚构的例子，不是用户给的。
转述会漂移。当出现「当初到底是怎么说的」这类争议、或者需要判断某个设计决策是不是过度解读时，以本页为准。
照搬原则：原文一字不改，含笔误（validtor / syste agent / intergration / fin in / object-key result 等）与不完整的句子，一律保留。笔误本身有时是理解意图的线索。
R-1 · 起点：P2 对 P1 的依赖排查
你看一下todo 的 需求文档，p2 的部分有多少依赖于 p1 的实现
落点：无独立文档，结论并入 27-P2 §九。
R-2 · 要一份 P2 详细设计
那你现在写一个新的 p2 的需求设计文档，来对 p2 的需求进行详细设计，任务划分
落点：27-P2（初版 v0.1，后经 R-3 / R-10 两次重写）
R-3 · Org Graph 由第一个 agent 动态生成
org graph 生成，应该由 company 的第一个 agent： org graph creator agent 来实现，根据这个公司的目标，描述，类型，来生成，比如要生成开发，还是运营，还是内容生成，会有多个不同的 org graph的模板，然后根据需求+agent list 动态来生成 org graph
落点：27-P2 §4.1（orggraph-planning agent）、§4.6（system/org-graph-templates/）
后续变更：其中 org graph creator 这个名字在 R-10 的命名统一中改为 orggraph-planning。
R-4 · 要一个执行控制台页面
我们需要一个新的页面，展示公司的 org graph 和每一个 org node 运行的 work graph，这个需求也需要设计一下，这个界面还需要设计一下 MVCP，数据库设计，界面设计，有启动，下一步，暂停，停止，重试这样的操作按钮，还需要展示每一个节点的运行日志，边的输入输出，loop 的划线，这些展示，还有主流程如何处理，异常流程如何处理，下钻的 sub agent 的流程如何处理和展示。
落点：27-P3/P4 全文（§四 按 MVCP 四象限组织）
关键澄清：此处的 "MVCP" 经确认是 Model-View-Control-Process，即仓库既有 SDD 的四象限文档格式（docs/prd/newfunction/_spec/sdd-{model,view,control,process}.md），不是 MVP（最小可行范围）。
R-5 · 手动 / 自动两种执行模式
对，而且运行有自动化和手动化两个选择，如果是手动，则 org graph，work graph 的执行是需要在界面上点击下一步下一步来完成，如果是自动则是授权自动从头到尾自动执行，一个节点完成则自动跳转到下一个节点执行
落点：27-P3/P4 §四.C（execution_mode ∈ {manual, auto}，两者共用同一个 advanceOne() 原语，区别只在谁触发下一次调用）
R-6 · 完整的七阶段流程（核心需求）
我说一下我理解的 process， 1， 用户新建一个 company 写入 company 的目标和描述2. company 默认有一个 org graph creator，根据用户描述，生成基础的 org graph，每一个 org graph node 可以从 system agent 中引用实现，也可以新建一个 system agent 来实现，比如开发 company，需要有 planner，code，validator 三个基础的 org graph 3. 用户输入一个具体的开发task， 4. org planner agent 作为执行 orggraph 的第一个节点，首先调用 planning work graph subagent，来规划执行 planning work graph 的这个任务，生成针对 planner agent 这个节点的 work graph，比如 brd->prd->sdd->benchmark->testdata->planner validtor->judge-loop-jump 来完成开发的第一个阶段需求planner的工作，这里面的每一个 work graph 节点都是一个 system agent 的引用，并且完成第一个 loop 闭环的跳转，如果成功则完成，如果有 bug 则跳转到对应的节点，让其只针对某一个部分开始修改。5 完成当前 org graph 节点工作，进入下一个 code graph node agent 的工作 6 code agent 也需要先调用 planning-work graph subagent 来设计 code work graph，可能是可以 fan out 并行多个 phase 的 code subagent->unit test 的开发，如果 unittest 有问题则loop 到 code subagent 来持续修改，全部并行完成后 fin in 节点到一个整合，->intergration test 来完成测试，如果有 bug 则判断是重新 planning 一个新的 work graph ，还是跳转到原有某个 work graph 节点来完成 7 codeagent 完成则进入全局的 validetor agent 来进行整体的判断，测试，审计，benchmark 的测试，test data 的测试等等，成功后完成，不成功则需要判断为什么会报错，是不是需要迭代某一个 syste agent 的 skill memory data llm 才能完成，先迭代 system agent ，再 loop 某个 work graph workflow ，再跑到 validator 验证，直至最后满足这个任务的 benchmark 或者 test data。 这个流程你整理成为一个文档，并且跟我们的 p2 设计比较，更新文档。 还有哪些没有考虑到的地方，这个流程是否是这样实现的？
落点：27-E2E 全文（§三 七阶段逐段还原、§四 与既有设计的差异、§七 未考虑到的地方）
由此产生的三条核心结论（27-E2E §二）：
- 这套流程 70-80% 已在
docs/prd/newfunction/_spec/被完整设计过（DevLoop 的 L1/L2/L3） - DevLoop 是这套架构的一个硬编码实例
- 第七步「迭代 system agent」是真正全新的一层（后定名 L4）
R-7 · 更正：benchmark / test data 是 work graph 的节点，不是基础设施
我描述的 benchmark 和 test data 是 workgraph 的两个 subagent 节点，例如在code planner agent，他的 work graph里包含了要规划当前 goal task 的 benchmark 或者 test data 或者 test script 来完成最终对这个 goal 的验收，所以 work graph 里 就需要调用 code-planner-benchmark code-planner-test-data code-planner-test-script 这三个 system agent ，动态选择是否需要在 work graph 中加入这三个节点，还是只需要其中某一个，来完成 code planner。
落点：27-E2E §十一（验收产出节点设计）
这条更正推翻了什么：此前我把 benchmark / test data 理解成系统级基础设施，因而去核实 benchmark-runner.js 并判定「是假的、test data 不存在」。该判断与本需求无关——本流程根本不使用 benchmark-runner.js。
后续变更：文中的 code-planner-benchmark / code-planner-test-data / code-planner-test-script 三个名字，经 R-10 与 R-12 两轮，最终定为 goal-benchmark / goal-test-data / goal-test-script（作用域从"父 org node"改为"goal"）。
R-8 · 是否需要独立的 example 文档
是否将我的描述的这个用户流程，更新迭代在文档里，并且作为一个 example 文档？
落点：27-EXAMPLE ⚠️ 注意：该文档用的是虚构的「配图工厂」场景，不是本页 R-6 的原文。R-6 的原文只在本页。
R-9 · 四个关键决策（回答确认问题）
以下四条是针对具体设计分叉的定案回答，逐条照搬。
R-9.1 · Org Graph 的定位（最大的架构分叉）
org graph 是由 company 级别生成的 workflow ，work graph 是由 org graph node 级别生成的 workflow 我不知道这个解释清楚了么？
落点：27-E2E §五定案、27-P2 v0.4 §一、27 号总纲 v0.3 §二术语表 + §3.3
推翻了什么：P2 v0.1-v0.3 把 Org Graph 建模为静态汇报结构（边是 reports_to / collaborates_with），以及我提出的 A/B/C 三个折中方案，全部作废。新模型下两层图同构，共用一套 schema、引擎与 UI。
R-9.2 · 元 Agent 继承
我们所有的org graph work graph 的 subagent 的 node agent，都是由一个元 agent 架构来继承生成的，统一有全局通用+公司/角色记忆分区
落点：27-E2E §八bis
关联发现：元 agent 在仓库里已有实物 —— system/templates/base/（"标准基座员工 Base Agent"），已强制 RESEARCH → PLAN → EXECUTE → VERIFY 四段式 + 阶段间 context flush + 换装元技能 + 失败写 _lessons.md 打回上一阶段。它本身就是一个最小 work graph。
R-9.3 · 验收产物由谁生成、由谁执行
验收产物在 org graph 中是由 planner 生成，由 validator 执行，每一个 node agent 的 benchmark 是由自身的 work graph 的 validator/test script/test benchmark/test script /节点来运行,
落点：27-E2E §11.3
要点：验收是逐层递归的——不是最外层一次总检，每一层图收尾都跑自己那层的验收；且执行由 agent 节点承担，不由引擎硬编码。
R-9.4 · L4 拆成 company / general 两条通道
迭代 system agent 本体，也是分为 company 还是 general 的部分，company 的部分在运行过程中就需要自动迭代，general 的部分需要 system agent 的管理者 master agent 或者人工来驱动执行，比如每日定时或者手工执行agent dream流程来自我更新，根据今天所有的 company 执行的成功 失败 经验，来更新 general 的本体部分
落点：27-E2E §八（L4-company / L4-general 对照表）、§8.1（agent dream 流程）
解决了什么：此前我提出的「为修一个任务而改坏十家公司共用 agent」这一跨公司污染风险（原 §7.2），以及我给的三个缓解方案（fork 副本 / 只改私有 / 人工确认），因这条分层而全部不再需要——在线自动迭代永远只碰 company 分区，general 本体的更新被移出任务循环。
R-10 · P2 重写 + 统一命名前缀
把 p2 文档按新的执行流边模型重写，仓库里的 benchmark 是 单 agent-benchmark 或者是 skill-benchmark ，给他们改个名字 ，我们这次聊的是goal-benchmark 或者 task-benchmark，我们在前面都统一加上前缀，包括 planner validator 也要加上 code-planner code-validator ，planning 是 workgraph-planning brd-planning，prd-planning orggraph-planning 这样起名，你可以统一排查一下
落点：27-P2 v0.4 全文重写、27-NAMING 全文
取舍过程：原话给了 goal- 与 task- 两个选项。我初次选了 task-，理由是"goal 已被 OKR 体系占用"；R-11 把 OKR 正名后该理由失效，我改用"验收标准跟着一次 task 执行走"作为理由继续保留 task-。这个理由在 R-12 被推翻，最终定为 goal-。
R-11 · OKR 正名
okr 树应该叫做 object-key result ，可以修改一下，不要叫做 goal 了
落点：27-NAMING §六
要点：体系整体从 goal 改为 okr；且当前第 1 层节点也叫 "Goal" 是一处自我遮蔽，建议正名为 Objective（O-001），成为标准的 Objective → Key Result → Sub-Task 三层。代码层已于 commit 74ea1ff 实施完毕（okr-service.js/routes/okr.js、/api/okr + 旧路径别名、scripts/migrate-goals-to-okr.js 迁移脚本、7 例单测）。
R-12 · 验收产物定名 goal-，并给出 goal 与 task 的层级区分
改回 goal-benchmark，因为 task 可能有很多个，task 是 sub agent 或者并行的层次，但是 goal 对于一个人类的需求描述只有一个，task 在 graph 中可能会有多个
落点：27-NAMING §四（含 goal / task / okr 三者的层级定义）
这条推翻了什么：推翻了 R-10 阶段"验收标准跟着一次 task 执行走"这个理由。关键区分是基数：
| 概念 | 基数 | 说明 |
|---|---|---|
| goal | 一个人类需求描述 = 1 个 | 验收的边界。"这次交付到底算不算满足了人的要求" |
| task | 一个 goal 分解出 N 个 | 图中的执行单元，可并行、可下钻 sub agent |
| okr | 跨多个 goal 的长周期度量树 | Objective / Key Result（见 R-11） |
验收标准回答的是"人类想要的东西做到了没有"，这是 goal 级的判定；task 只是达成它的执行分支，一个 goal 下有很多个，把验收挂在 task 上会导致"到底以哪个 task 的验收为准"无法回答。
R-13 · P2 需求审计中的四个定案
针对「P2 是否兑现原话」的逐条比对，四个分叉的定案回答，逐条照搬。
R-13.1 · goal 分三层
公司的目标是公司的 goal 叫做 company-goal ，任务的目标叫做 task-goal ，还有每一个子任务的目标叫做 subagent-goal，应该这么叫吧？
落点：27-NAMING §四「goal 是三层递归的」、27-P2 §4.1 第 1 步
澄清了什么：R-12 说的「一个人类需求描述只有一个 goal」，指的其实是三层里的 task-goal。三个验收 agent（goal-benchmark / goal-test-data / goal-test-script）保持通用，不按层级拆分——在哪一层调用就为那一层的 goal 产出标准，与 R-9.2 元 agent 继承一致。
后续变更（R-14）：subagent-goal 按执行者命名，与另两个的作用域命名轴不一致，已定名为 subtask-goal。上方原话保留提出时的用词，不随之改写。
R-13.2 · 公司类型由 agent 推断
完全由 orggraph-planning 推断
落点：27-P2 §4.6（模板是起点集合，不是代码里的 switch(type)）
推翻了什么：审计时我把「不给 company.json 加枚举 type 字段」记为「我擅自偏离了 R-3 原话（原话把类型列为输入）」。本条确认 LLM 推断正是所需，当前设计无需修改，那条自我记过的缺陷不成立。
R-13.3 · 新 agent 从元 agent 继承
从 base 元 agent 继承 + agent-creator 填内容，建成后可以手动或者根据 company 的需求设置自动innovator 培养训练
落点：27-P2 §4.1 第 7 步、§五 T5b
这是 R-9.2 在 P2 的落地点：模板不存在的角色，先从 system/templates/base/ 继承骨架（自动带上 RESEARCH → PLAN → EXECUTE → VERIFY 四段式），再由 agent-creator 填充角色定义——不是直接走现有的 needs_training 全量培养分支。训练是可选后置步骤，可手动触发或按公司需求配置自动。新建 agent 一律 scope='company'。
R-13.4 · org graph 强制单入口
强制单入口（推荐）
落点：27-P2 §3.3 第 2 条（原为 open question，现已定案）
R-14 · 命名轴统一为作用域
改成 subtask-goal
落点：27-NAMING §四
定案：三层 goal 一律按作用域命名 —— company-goal / task-goal / subtask-goal。R-13.1 提出时第三个叫 subagent-goal（按执行者命名，与另两个的轴不一致），本条统一。R-13.1 的原话引用保留提出时的用词，不随之改写。
R-15 · P3 需求规划讨论中的六个定案
针对「27 系列 P3 该做成什么样」的一轮讨论产出。
⚠️ 本节两种来源混排，逐条标注：R-15.1 / R-15.2 / R-15.3 有用户原话（引用块内一字不改，遵循本页照搬原则）；R-15.4 / R-15.5 / R-15.6 是选项式确认——选项文本由我拟、用户勾选，不是用户自己的措辞，因此只记为定案，不冒充原话。
📌 恢复记录（2026-08-15）：R-15.1 的全文、R-15.4 的后半、R-15.5、R-15.6、以及速查表对应行，曾因一次错误回滚（
git checkout --）丢失，后据会话上下文补回。R-15.3 的「节点名 vs 本体名」表未按原始版本还原——它在丢失期间被 27-NAMING §三 的重写取代（命名轴从「业务领域」改为「所在图的层级」），新版更贴合 R-15.3 引用的原话，故保留新版。
R-15.1 · 讨论对象是 org graph 这条线的 P3
有一个进程正在开发p2 我们来看看 p3 的需求的规划
对 我们要讨论 org graph 的 p3
澄清了什么：仓库里有两条互不相干的 P3，容易混。
| DevLoop 的 P3 | 27 系列的 P3 | |
|---|---|---|
| 出处 | docs/prd/newfunction/_spec/plan-migration.md |
27 总纲 §六 |
| 内容 | L1+L2 联动，跨 Unit runProject |
Work Graph 最小闭环 |
| 状态 | runProject 已实现（loop-controller.js:576） |
零代码 |
本条确认讨论的是后者。下文 R-15.2 起全部属于 27 系列。
落点：27-P3/P4 全文。
R-15.2 · workgraph-planning 是全局通用 agent
① 用全局通用 workgraph-planning
澄清了什么：每个 org node 接到任务时不是各自带一份规划能力，而是都调同一个全局 workgraph-planning 本体，靠记忆分区区分它在不同 org node / 不同公司下的语境。与 R-9.2 元 agent 继承、27-P1 虚拟引用寻址一致——agent 池不随 org node 数量膨胀。
落点：27-NAMING §二（该条目已在表内）、27-P3/P4 阶段 D。
R-15.3 · validator 分两个层级，各有全局本体
② org graph 的 validator 叫做 org-validator work graph 里面生成的 validator 叫做 xx-validator 比如 planner agent 的 validator 叫做 planner-validator ，code agent 内生成的 work graph 的 validator 叫做 code-validator。所以是两个层级的不同的 validator ，每个层级的 validator 在 system agent 里面都有对应的全局 agent ，比如有 planner-validator coder-validator org-validator ， org-validator agent 里面也许会调用 benchmark-validator testdata-validator 等等不同的 sub agent 来完成任务。
两级验收的分工：
| 节点名 | 验什么 | 决定什么 | 失败退到哪 | |
|---|---|---|---|---|
| org 层 | org-validator |
整个任务达成了吗（27-E2E §三 阶段 7 的全局 validator） | 整个 org graph run 的收敛 | 退回某个 org node，整张 work graph 重跑 |
| work 层 | {orgNode}-validator |
这个 org node 自己的产出合格吗 | 该 org node 的 success/fail | 退回本张 work graph 内的某个节点 |
节点名 vs 本体名（本条推导出的一条新规则）：
| 例 | 带前缀？ | |
|---|---|---|
| system agent 本体 | planner-validator / coder-validator / org-validator |
❌ 不带领域前缀 |
| org graph 节点 | org-planner / org-coder / org-validator |
✅ 带 org- |
| work graph 节点 | {父 org 节点职能}-{职能} |
✅ 带父节点名 |
禁止裸用 validator 的理由是「一家公司内两个节点不能重名」——该理由针对的是节点，不针对本体。本体若被迫带领域前缀，coder-validator 会复制成多份，与 P1「同一份本体、多处引用、各自私有语境」直接冲突。
三个 validator 是三个独立本体：它们验的东西本质不同——规划产物 / 代码 / 整个任务达成，是不同能力，不是同一能力的不同语境。27-E2E §八bis 的「不特化」原则针对的是同一能力在不同 org node 下，与本条不冲突。
org-validator 调 sub agent 不需要新机制：org-validator 本身是一个 org node，按定义有自己的 work graph，benchmark-validator / testdata-validator 就是这张 work graph 的节点，落在已有的递归模型里，引擎不加分支。
连带影响：R-9.3「planner 生成、validator 执行」的两个角色现在分属两个不同的 org node——goal-benchmark / goal-test-data / goal-test-script 在 org-planner 的 work graph 里产出，由 org-validator 这个 org node 消费。因此需要跨 org node 的产物传递机制，27-P3/P4 现有的 output_ref（节点内产物指针）不够。
落点：27-NAMING §三 + 新增 validator 命名轴、27-P2 §4.6 三个模板、27-P3/P4。
R-15.4 · 引擎泛化，定义层与运行时层分离
选项确认，非原话。给出的三个选项是：引擎泛化接受表名参数（选中）/ org graph 执行时物化成 work_graph 实例 / 先只做 work graph 把 org graph 执行推到 P5。
推翻了什么：27-P3/P4 §四.A 的注释专门为「不拆定义表和实例表」辩护，理由是 work graph「规划完即执行、执行完即归档」，定义即实例。该前提在 org graph 也要被执行之后失效——org graph 是建公司时生成一次、活整个公司生命周期的长期定义，一份定义要被跑很多次（每来一个任务跑一遍）。
定案：定义层保留两套（org_graph_* 长期 / work_graph_* 一次性），运行时层统一为一套 graph_runs + graph_run_nodes，引擎只操作运行时层，定义从哪来由 graph_runs.graph_kind 决定。三层下钻改用 parent_run_id 一条链（取代 parent_node_id）；任务级总预算（27-E2E §7.1）挂 root run，子 run 上溯扣同一个池；暂停/停止沿同一条链向下级联（§7.5）。
连带定案：org node 与 work node 的执行语义不同——前者是「起一张子图并等它收敛」（子 run completed → success，blocked → fail），后者是「一次 agent 调用」。引擎需要 agent_call / subgraph 两种 node executor。org 层回退不强制插 loop_validator 节点（会污染「这家公司有哪些角色」的语义），改由引擎对 edge_kind='backward' 的边统一计数 + 硬顶熔断。
落点：27-P3/P4 §四.A / §四.D。
R-15.5 · P3 范围含 workgraph-planning + 任务入口
选项确认，非原话。
推翻了什么：27-P3/P4 §一非目标把 workgraph-planning 排除在外，代价是该文档 §八.5 自己承认「只能用手写测试数据构造图，不能端到端验证从一句自然语言目标到一张可执行的图这条链路」。且 27 总纲 §六本来就把 workgraph-planning 列为 P3 交付物。任务入口（用户 → 公司）是 27-E2E §四 #7 标注的「完全空白」，没有它图没有来源。
定案：两者都收进 P3，作为最后一个阶段（前面的阶段全部不起 LLM、可独立验收，与 27-P2 §五「三个可独立验收的阶段」同一套切法）。
落点：27-P3/P4 §一非目标（两条作废）、§五任务划分。
R-15.6 · 验收契约提到最前面
选项确认，非原话。
依据：27-E2E §十「整条流程的终止条件（验收）是实现程度最低的一环……先建验收，再建循环——否则会得到一个跑得很顺畅但永远不知道该不该停的系统」。按该节 v0.2 调整，「验收先行」的含义不是建 benchmark 基础设施（那是误解），而是定义验收契约格式 + 建执行器。
定案：P3 新增一个前置阶段，先定 goal-benchmark / goal-test-data / goal-test-script 三种产物的统一契约格式并建执行器，再动引擎。
落点：27-P3/P4 §五任务划分、27-E2E §十一。
R-16 · 失败归因由专职 subagent 做，回退边是多条
org-validator 判定任务未达成时，退回 code-coder（实现有问题）还是 code-planner（规划有问题）? 这个org-validator 会有自己的 work graph 里的 subagent 决定，它首先需要有一个 validator-reflection subagent 来判断当前的 bug 的源头是哪个 agent 的哪个 skill 的问题，还是哪个 agent 的输入约束不够的问题，还是哪个 agent 的执行问题，判断完原因，才知道是先改 skill，还是直接让某个 agent 直接+bug context 描述直接重做。 所以回退的边是多个的，不是一个的，在回放的时候才知道用哪个边实现回退。你觉得如何？
落点：27-P3/P4 §四.D.2.2（选边）、§四.D.0（子 run 回写透传）、§四.D.2.1（熔断）
这条回答了什么：27-P3/P4 v0.3 §八.1 把「一个节点有多条 fail 边时走哪条」列为本版最需要确认的 open question，本条关闭它。
关键结构：归因不是失败节点自己顺手吐一个 reason，而是 org-validator 自己 work graph 里排第一位的一个专职节点 validator-reflection。这与 DevLoop 的既有分工同构——Integrator 判定集成失败、BugTriager 单独归因，是两个不同 agent，理由是同一个 agent 既当裁判又当法医容易把「我判失败」和「我认为该怪谁」混成一次输出。
三分类归因与 DevLoop 四分类的对照：
| 原话的归因 | DevLoop 对应 | 回退动作 |
|---|---|---|
| 哪个 agent 的执行问题 | impl_bug |
该 agent 带 bug context 重做 |
| 哪个 agent 的输入约束不够 | contract_mismatch / spec_ambiguous |
退回上游产出约束的那个节点 |
| 哪个 agent 的哪个 skill 的问题 | 无对应 | 先改 skill —— 这一支即 L4-company |
| （原话未提）进程超时 / 被杀 | infra_flake |
直接重跑，不烧预算、不动节点 |
⚠️ 「skill 问题」这一支落在 P3 的非目标里（L4 是三级恢复中最贵、爆炸半径最大的一级，27-E2E §十 建议最后做）。建议：v1 保留 skill_defect 这个归因取值让 reflection 照常判定（数据先攒着，归因体系一次成型），但动作降级为「挂起等人工」，不自动触发 L4。infra_flake 建议补上——纯引擎逻辑、近乎零成本，不补则超时会被误判成执行问题、白烧一轮预算。
对 schema 的要求：子 run 收敛时不能只回写 success/fail，还要把 fail_reason 和 remediation_note 一起透传回父节点——因为决定走哪条边的是子图里的 reflection 节点，不是失败节点本身。27-P3/P4 §四.D.0 原表只写了「子 run completed → success；blocked/failed → fail」，缺这条透传。
本条带出的一个熔断漏洞：v0.3 §四.D.2.1 按 (run_id, edge_id) 计数、硬顶 3，前提是一个节点只有一条回退边。多条回退边各自计数后，硬顶实际变成 3×N——reflection 只要每次归因到不同 agent、走不同的边，就永远撞不到任何一个计数器的顶。这是 27-E2E §7.1「每级都重置下一级计数器则没有终止条件」的同型变体。修法：双层计数，单边计数（防同一路径死循环）+ graph_runs.backward_count 的 run 级总回退计数（防「换个借口继续退」），任一撞顶即 force_terminated。这与任务级总预算是两回事——预算管花了多少钱，这个管绕了多少圈，两者都要。
两处待确认（尚未定案）：
- 归因能精确到哪一层。原话说「直接让某个 agent 直接 +bug context 描述直接重做」，若 reflection 判定问题在某个 org node 内部 work graph 的具体节点，org 层的边只能退到 org node 粒度。建议保持层级封装：org 层只退到 org node，
remediation_note跟着传下去，由该 org node 自己的workgraph-planning决定是重新规划一张图还是复用旧图只重跑某节点——这让 27-E2E §四 #4 的「重新 planning vs 跳回节点」留在 org node 内部判断。另一条路是允许跨层直接寻址目标节点，更快但破坏封装，且控制台「暂停/单步」的层级语义会变含糊。 validator-reflection的命名。按 27-NAMING §三 现行规则（work graph 节点 ={父 org 节点职能}-{职能}），它作为org-validator的 work graph 节点应为validator-reflection，与原话一致。但它做的是归因不是判定，是否改叫validator-triager（对齐 DevLoop 的 BugTriager）待定。
附 · 需求 → 设计落点 速查
| 需求 | 一句话 | 主要落点 |
|---|---|---|
| R-3 | org graph 由第一个 agent 按公司描述动态生成 | P2 §4.1 / §4.6 |
| R-4 | 执行控制台页面（MVCP + 五个控制按钮 + 日志 + loop 划线 + 下钻） | P3/P4 全文 |
| R-5 | 手动 / 自动两种执行模式 | P3/P4 §四.C |
| R-6 | 七阶段端到端流程 | E2E §三 |
| R-7 | 验收产物是 work graph 的动态可选节点 | E2E §十一 |
| R-9.1 | org graph = company 级 workflow；work graph = org node 级 workflow | E2E §五 / P2 §一 / 总纲 §3.3 |
| R-9.2 | 所有 node agent 由元 agent 继承生成 | E2E §八bis |
| R-9.3 | 验收逐层递归，planner 生成、validator 执行 | E2E §11.3 |
| R-9.4 | L4 拆 company（自动）/ general（dream，人工或 master 驱动） | E2E §八 / §8.1 |
| R-10 | 统一命名前缀 | NAMING 全文 |
| R-11 | OKR 正名，不叫 goal | NAMING §六 |
| R-12 | 验收产物定名 goal-；goal 唯一、task 多个 |
NAMING §四 |
| R-13 | goal 三层；类型由 agent 推断；新 agent 从 base 继承；强制单入口 | NAMING §四 / P2 §3.3 §4.1 §五 |
| R-14 | 命名轴统一为作用域：subagent-goal → subtask-goal |
NAMING §四 |
| R-15.1 | 讨论的是 27 系列的 P3，不是 DevLoop 的 P3 | P3/P4 全文 |
| R-15.2 | workgraph-planning 是全局通用 agent，不按 org node 特化 |
NAMING §二 / P3/P4 阶段 D |
| R-15.3 | validator 分 org / work 两层；本体名不带领域前缀 | NAMING §三 / P2 §4.6 / P3/P4 |
| R-15.4 | 引擎泛化，定义层（org/work 两套）与运行时层（graph_runs 一套）分离 |
P3/P4 §四.A / §四.D |
| R-15.5 | P3 范围含 workgraph-planning + 任务入口，两条非目标作废 |
P3/P4 §一 / §五 |
| R-15.6 | 验收契约格式 + 执行器提到最前面，作为 P3 的前置阶段 | P3/P4 §五 / E2E §十一 |
| R-16 | 归因由 validator-reflection 专职节点做；回退边多条，运行时选边；熔断需双层计数 |
P3/P4 §四.D.0 / §四.D.2.1 / §四.D.2.2 |