Graph Engineering 系列对照笔记——待确认事项清单
日期: 2026-08-04（2026-08-05 更新：A/B/D/E/F/G 已确认方向，C 已确认暂不做）
性质: 从三份对照笔记里提取出的全部"待讨论的开放问题"，去重合并后按主题整理，供逐条确认方案。每条确认后会展开成独立的需求文档（参考 docs/work-graph-parallel-execution-requirements.md 的产出方式），本文件本身只做索引和现状追踪，不写详细方案。
来源文档：
docs/reference/graph-engineering-1000-agents-5-steps.diff-with-graphlemon.md（简称"5 步版对照"）docs/reference/graph-engineering-vs-loop-engineering-overview.diff-with-graphlemon.md（简称"综述版对照"）docs/reference/Graph Engineering with Claude_ 14-Step roadmap from 0 to graph architect (Full Course).diff-with-graphlemon.md（简称"14 步版对照"）
三份笔记里有几条开放问题实质上是同一件事的不同角度，已在下面合并并标注了原始出处。
状态图例
- 🔲 待确认：还没讨论方案
- 🟡 讨论中/已产出需求文档，待评审
- ✅ 已确认，进入设计/实现
- ⛔ 已确认不做（附理由）
A. 架构文档要不要正式采用"工作图 / 角色图"命名
状态：✅ 已确认——两组术语等价，不是新概念
来源：5 步版对照 §4 开放问题 3 + 综述版对照 §8 开放问题 1（同一件事，两份笔记从不同角度各自提出）
背景：综述版文章提出一条治理红线——"工作图"（任务怎么拆怎么合，可以快变）vs "角色图"（谁有权改什么，必须慢变可审计）。这条边界跟 graphlemon 现有的 Org Graph（人工固定设计，架构变更需人工评审）/ Work Graph（每次任务动态生成）边界几乎是同一件事的两种命名。5 步版对照笔记是从"什么时候不该用 Graph"的角度独立推出同一条边界的。
确认结果（2026-08-05）：工作图 是 Work Graph 的字面翻译，graphlemon 本来就这么叫；角色图 不是 Org Graph 的字面翻译，但语义完全对得上——Org Graph 本来就是"角色（Planner/Coder/Validator）之间固定的组织关系图"，角色图 是更准确的中文释义，不是新造的概念。两组术语直接画等号：Work Graph ≡ 工作图，Org Graph ≡ 角色图。
待办：✅ 已完成（2026-08-05）。docs/graphlemon_architecture.md §2 术语表的 Org Graph/Work Graph 定义行已补充等价说明，并在术语表后新增"术语对照"段落引用综述版文章原文。
B. loop-until-dry 要不要在 Validator 落地
状态：✅ 已实现（2026-08-06）→ 需求文档 docs/todo/validator-loop-until-dry-skill-requirements.md + 设计文档 docs/todo/validator-loop-until-dry-skill-design.md
来源：5 步版对照 §4 开放问题 1
背景：Org-level Loop 目前固定 3 轮上限（docs/sdd/04-P-流程与状态流转.md 已标注这是"未来优化候选"）。14 步版对照进一步发现：这不只是优先级问题——work_graph_orchestrate.py::topological_order 对有环的 graph_manifest 直接报错，Work Graph 被设计成严格 DAG，图内根本不支持回路，要支持 loop-until-dry 需要动执行模型本身，不是加一个判断逻辑那么简单。
确认结果（2026-08-05）：不改 Work Graph 执行模型本身（不引入图内回路）。做成一个独立的 Skill（例如 validate-until-dry 之类），把"连续 K 轮无新发现才停止、去重比对全部见过的而非仅已确认的"这套收敛逻辑封装成 Validator 可调用的方法论/工具，并且要求 .claude/agents/validator.md 在跑到"未知规模缺陷扫描"这类场景时记得调用它——落地方式是 Skill + Agent 定义引用，不是改 Graph Engine 底层。
待办：✅ 已实现（2026-08-06）。关键设计澄清：loop-until-dry 不需要图内回路——收敛循环发生在单个 Work Node 一次 claude -p 会话内部（多轮工具调用），graph_manifest 本身仍是无环的，不需要碰 topological_order。实现内容：新 Skill skills/unknown-scope-defect-sweep/SKILL.md（K=2 连续无新发现停止、20 轮硬上限、去重键必须是结构性标识而非自然语言描述、去重集合是"全部见过的"而非"已确认的"——14 步版点名的常见坑），接入 agent_profile.py::FRONTMATTER["validator"]["skills"]；agents/validator/AGENTS.md"必须加载"一节新增触发指引（任务描述说不清验收对象确切数量/边界时加载）。FR-3 的判定框架接线选择了复用 qa-task-validation 已有的 PASS/FAIL/INCONCLUSIVE 判断，没有接 F 的 root_cause_trace/三视角评审团——两者是流水线上不同阶段（验证本身 vs 验证失败后的根因归属），不应该混用，设计文档第 2 节记录了这个取舍。本轮唯一有确定性代码行为、可测试的部分是 FR-4（Skill 接入 agent_profile.py 渲染进部署产物），新增 test_agent_profile.py::test_validator_references_unknown_scope_defect_sweep_skill；验收标准 1-3（真的能找全、真的能正确去重、真的能在硬上限停止）依赖真实 claude -p 多轮工具调用行为，只能用 RUN_REAL_AGENT_E2E=1 验证，不在本轮 mock 测试范围内，如实记录（跟 F 设计文档"视角节点并发时间收益的实测"是同一类限制）。python3 -m unittest discover -s src（587 tests）全绿，零回归。
C. 按节点分层选模型——策略归属
状态：⛔ 已确认暂不做
来源：5 步版对照 §4 开放问题 2 + 14 步版对照 §1 表格第 12 行 / §3 开放问题 3
背景：agent_profile.py 里 Planner/Coder/Validator 三个 Org Agent 目前全部固定 claude-sonnet-5。14 步版对照进一步发现：Work Graph 层的管线其实已经打通了一半——_render_node_script 支持往生成的单节点脚本里塞 model 参数，run_fn(cwd, model=None) 也留了口子，但没有任何调用方真正传入非 None 的值，graph_manifest 的节点结构里也没有 model 字段。基础设施就位，缺的是"谁来决定每个节点该用哪个模型"这层策略。
确认结果（2026-08-05）：暂时不做。_render_node_script 的 model 参数保留现状（存在但不接线），Org Graph 三节点继续统一用 claude-sonnet-5。如果后续 G（并行执行）上线后节点数变多、成本变成真实痛点，再重新评估。
D. Time-travel 调试要不要立项
状态：✅ 已实现（2026-08-06）→ 需求文档 docs/todo/work-graph-time-travel-debugging-requirements.md + 设计文档 docs/todo/work-graph-time-travel-debugging-design.md
来源：综述版对照 §6
背景：LangGraph 的 checkpointer 支持回到任意历史检查点重放/分叉。graphlemon 目前的容错（部分节点失败保留已成功节点输出）、人在回路（Start/Pause/Stop）、记忆（.claude/agent-memory/）都已具备，唯独"回到某个历史节点重新分叉执行"没有，现状是"用 git 历史 + 手动重跑"。
确认结果（2026-08-05）：立项。
待办：✅ 已实现（2026-08-06，后端+控制台一起做，用户确认）。核心发现：ux_work_graph_run_active 唯一索引是带 WHERE 条件的部分索引（只约束非终态 run），比背景描述的风险小——v1 裁剪成只支持从已终态的父 run 分叉，完全绕开这条约束，不需要碰它。FR-1 的"覆盖 input_payload 重新触发执行"的歧义，最终决定成替换输出、不重新提示（分叉点本身不重新跑 claude -p，只把它的 output_payload 换成人工提供的新内容，只有严格下游节点真的重新执行）——设计文档第 2 节记录了为什么这样解决了跨调用方约定不统一的问题。实现依赖零改动执行引擎：预先把非下游节点插入成 status='done' 的 work_node_execution 行，run_work_node() 已有的 REQ-06 断点续跑短路逻辑自动完成"复用而不重跑"，run_graph()/topological_layers() 一行都没动。
新增：src/work_graph_fork.py（create_fork/execute_fork/fork_work_graph_run/start_fork_in_background，_reconstruct_build_prompt 支持 Planner 固定文档链和 E 的通用 task_prompt 两种图形状，其余形状明确报错而不是产出错误提示词）；work_graph_run新增 parent_run_id/fork_of_node_exec_id（migrate_add_work_graph_fork_columns 迁移已有数据库）；查询层（work_graph_run_query.py/task_query.py）透出这两个字段；新 HTTP 端点 POST /api/work-nodes/:node_exec_id/fork（_handle_task_execute 同款"同步创建+后台真实执行"模式）；控制台 v_run_detail 新增"从这里分叉"表单（仅 done 节点）+ 分叉徽标（链接回父 run），v_graph_console 的运行列表用 🔀 标出分叉分支。真实跑通了一次端到端验证（启动真实 backend、真实 HTTP fork 请求、确认新 run 正确落库并可追溯）。测试覆盖需求文档验收标准 1-3（PRD 换内容后下游真实重跑/BRD 不动、原始 run 完全不受影响、同一节点可分叉多次互不干扰）。python3 -m unittest discover -s src（608 tests）+ 前端 3 个 smoke test 全绿；supervisor 套件里一个真实候选进程冒烟测试用 git stash create 快照当前工作树来测试未提交状态，只快照 tracked 文件——本轮新增的 3 个文件当时还是 untracked，被这个测试技巧本身漏掉导致候选进程 import 失败，不是代码问题，提交后自然解决（真实生产的 stage_deployment() 用的是真实 commit hash，不会有这个问题）。
E. Planning Skill 提示词强化——识别可并行节点 + 通用 Work Graph 设计能力
状态：✅ 已实现（2026-08-06）→ 需求文档 docs/todo/dynamic-work-graph-design-skill-requirements.md + 设计文档 docs/todo/dynamic-work-graph-design-skill-design.md
来源：综述版对照 §7 开放问题 3 + 14 步版对照 §3 开放问题 2（同一主题：让 Planning 阶段更早识别并行机会）
背景：work_graph_plan.py 里 Planning Skill 的 prompt（约在 work_graph_plan.py:67 附近）目前只要求"一个 artifact_type 一个节点"，没有引导 Claude 识别哪些节点互不依赖。目前观察到的真实 graph_manifest（如 BRD→PRD→SDD→Benchmark）是纯串行链，架构文档 §6.1 设想的并行候选点从未真正被生成过。
确认结果（2026-08-05）：提示词强化肯定要做——把"对每个箭头问是否真的有数据流动"的提问方式、以及"并行可分解 / 单一上下文装不下 / 收益覆盖成本"这三条尺子写进 Planning 相关 prompt。但范围比原开放问题更大：不能只强化 Planner 自己写 BRD/PRD/SDD/Benchmark 那条链的 prompt——架构文档 §5 本来就说"每个 Org Agent 拥有一个 Planning Skill"（Coder 和 Validator 各自也要规划自己的 Work Graph），"如何识别 fan-out/fan-in、设计一张动态 Work Graph"这套方法论应该是跨 Org Agent 通用的能力，而不是分别在 Planner/Coder/Validator 三份 Planning Skill 里各写一遍。用户原话："planner agent 里面要有多个 skill，不仅仅是 brd prd sdd benchmark 还有给其他 org graph 的 node 节点的 agent 做各种动态 work graph 的设计"。
待办：✅ 已实现（2026-08-06）。G 已经回答了 FR-2（并行分组字段格式）：不需要新字段，topological_layers() 完全靠 depends_on/edges 结构本身推导独立性——设计文档第 1 节记录了这个结论。实现内容：新 Skill skills/design-dynamic-work-graph/SKILL.md（跨 Org Agent 通用方法论，接入 agent_profile.py::FRONTMATTER["coder"]["skills"]/["validator"]["skills"]）；work_graph_plan.py 新增 _GENERIC_PROMPT_TEMPLATE（org_node != "planner" 时使用，每节点自带 task_prompt，Planner 原有固定链路 _PROMPT_TEMPLATE 完全不动，零回归）+ generic_node_prompt_builder()。按需求文档非目标 #1（"不要求第一版就覆盖 Coder/Validator 全部真实工作场景，只需要证明机制走得通"）收窄范围：没有改动 e2e_pipeline.py::implement_code() 的现有单节点生产路径——新增测试证明"给 Coder 一个可拆成 3 个独立模块补测试的场景 → 生成正确的 graph_manifest → topological_layers() 确认三个节点落在同一层 → run_graph() 端到端跑完"这条链路本身成立（src/test_work_graph_plan.py：GenericPlanningPromptTest/CoderThreeIndependentModulesScenarioTest/GenericNodePromptBuilderTest/GenericPathEndToEndViaRunGraphTest），不是接入真实生产路径。python3 -m unittest discover -s src（580 tests）全绿，零回归。
F. 三视角评审团机制要不要推广到其他验证点
状态：✅ 已实现（2026-08-06）→ 需求文档 docs/todo/verifier-fan-out-jury-requirements.md + 设计文档 docs/todo/verifier-fan-out-jury-design.md
来源：综述版对照 §7 开放问题 4 + 14 步版对照 §3 开放问题 4（同一主题）
背景：root_cause_trace.judge_root_cause（正确性/需求完整性/Skill 缺陷三视角，≥2/3 一致才定案，否则升级人工）目前只服务于 Validator 的 test_failed 根因溯源场景。run_graph() 自身的 verify_fn 是单一验证器 + 失败重试一次，没有多视角/对抗式/评审团这类"重打法"。综述版文章把这类重仓验证归为"高风险场景才用"，暗示应该按风险分级选验证强度，而不是所有节点统一同一套。
确认结果（2026-08-05）：要做，而且明确了实现方式——不是继续用现在 root_cause_trace.judge_root_cause 那种 Python 层直接顺序调用三个 perspective_fn 的写法，而是把三视角评审团做成一张真正的 Work Graph fan-out/fan-in 菱形拓扑：fan-out 出 N 个独立的验证节点（每个节点是一次独立的 claude -p 调用，带自己的视角提示词），fan-in 节点做投票/汇总。用户原话："三视角评审团可以做，做成 work graph 的 fan out 图来实现吧"。
待办：✅ 已实现（2026-08-06）。汇总节点没有做成第四个 Work Node——投票是纯 zero_token 聚合（跟 E 里 edge_type 的区分直接对应），不需要 Agent 推理，做成普通 Python 函数在 run_graph() 返回后直接对 outputs 计数，不产生额外 claude -p 调用/token 成本，设计文档第 1 节记录了这个取舍。实现内容：root_cause_trace.py 新增 _tally_perspectives()（>=2/3 判定规则从 judge_root_cause 抽出来，闭包版和 Work Graph 版共用同一份规则，不是两份容易失配的实现）+ judge_root_cause_via_work_graph()（N 个视角节点用真实 schema 约束的结构化输出，不再像 real_validator_perspective 那样手工解析"CATEGORY:/DETAIL:"文本行）。闭包版 judge_root_cause/real_validator_perspective 保留，不废弃（轻量备选，见设计文档第 4 节）。org_level_loop.run_fix_loop（唯一真实生产调用方）已迁移到 Work Graph 版本，fixer/verify 两次调用保持不变的 flat trigger_org_node 调用。顺带修了一个真实的潜在 bug：judge_root_cause_via_work_graph 是第一个真正触发 run_graph() 多节点并发层的生产代码路径（之前所有真实 graph_manifest 要么单节点要么严格串行链，G 的并发调度从未在生产里真正跑过），暴露出 scheduler.py::run_goal_to_completion/task_execution.py::start_task_execution_in_background 的 schema.connect(db_path) 都没传 check_same_thread=False——已一并修复。测试改造范围（设计文档第 5 节标注的最高风险点）：test_org_level_loop.py/test_scheduler.py 的 3 个测试把 mock 边界从 org_node_trigger.trigger_org_node（拦截"CATEGORY:"提示词）改成 work_graph_execute.write_workflow_script/execute_work_graph。新增测试证明验收标准 1-3（三次真实独立 Work Node 执行、判定规则与闭包版等价、每个视角节点的 input_payload 不含其他视角内容）+ 一个直接验证并发重叠的测试（ConcurrentPerspectiveExecutionTest）。python3 -m unittest discover -s src（586 tests）+ discover -s supervisor（125 tests）全绿，零回归。FR-4（verify_fn 通用对接其他验证点）本轮不实现，标注"应该"优先级，留待后续。
G. Work Graph 节点并行执行（Python 线程池方案）
状态：✅ 已实现（2026-08-06）→ 需求文档见 docs/work-graph-parallel-execution-requirements.md
来源：14 步版对照 §3 开放问题 1
背景：run_graph() 目前严格串行执行所有节点，即使 graph_manifest 里的节点互不依赖。已经讨论过按拓扑层分批 + 线程池并发的方案，核心风险（SQLite 并发写入、worktree 创建竞态、配额错误处理）都已识别，且发现 backend_server.py 里已有可复用的"共享连接 + threading.Lock()"先例。已产出完整需求文档（目标/非目标/功能需求/验收标准/风险/开放问题）。
确认结果（2026-08-05）：确认要做，用户强调"这个很核心"。触发规则明确为：只要 Work Graph 规划了 fan-out/fan-in 的并行节点，节点触发时就应该并行执行——这跟需求文档 FR-1/FR-2 已经写的内容一致，不需要改需求文档的功能需求本身，只需要在文档里把这句话作为明确的验收口径固化下来。
待办：✅ 已实现（2026-08-06），按设计文档第 11 节的分步实施顺序落地——src/work_graph_orchestrate.py：topological_layers()（层内并发、层间屏障，topological_order() 改为薄封装）、_LockedConn/_FetchedRows（线程安全 conn 代理，注意：实现比设计文档原稿更严格——锁必须覆盖 execute() 到 fetchone()/fetchall() 的整个周期，不能只锁 execute() 本身；这个差异是 RunGraphRealSqliteConcurrencyTest 真实跑出 database is locked/空 file_path 类错误后修的，不是理论推导）、run_graph() 改层级调度 + _run_one_node() + WorkGraphLayerError；src/work_node_run.py：create_worktree() 加 _worktree_creation_lock。新增测试：src/test_work_graph_orchestrate.py（TopologicalLayersTest、RunGraphConcurrencyTest 同层并发+层间屏障、RunGraphLayerErrorTest 失败不取消同层兄弟节点、RunGraphConcurrentResumeTest、RunGraphQuotaCoexistsWithNormalCompletionTest、RunGraphRealSqliteConcurrencyTest 真实 sqlite 多轮并发）、src/test_work_node_run.py（ConcurrentCreateWorktreeTest 真实 git worktree 并发创建）。已知遗留限制（设计文档已诚实记录，本轮未解决）：单节点配额等待可长达数小时，会拖住整层其他已完成节点的返回——需要更细粒度的可中断调度才能解决，超出本次范围。python3 -m unittest discover -s src（575 tests）+ discover -s supervisor -p "test_*.py"（125 tests）全绿，零回归。
H. 统一 Role Package 抽象层
状态：✅ 已实现（2026-08-06）→ 需求文档 docs/todo/role-package-abstraction-requirements.md + 设计文档 docs/todo/role-package-abstraction-design.md
来源：不属于三份 Graph Engineering 对照笔记，是用户对照 Agentic Enterprise 产品目标（"role + context + skills + applications + workflows + permissions + acceptance criteria；all essentially are context for intelligent computing"）单独提出的差距检查，2026-08-06。
背景：逐维度核对代码发现，七个维度里六个都有对应实现（applications 是真空白），但没有被收敛成一个统一的"role package"格式——理解"Validator 这个角色完整定义是什么"现在得同时读 agent_profile.py + skills/qa-task-validation/SKILL.md + .claude/agent-memory/validator/ + docs/sdd/06-验收与测试锚点.md 四个地方拼出来。更根本的问题：role 本身不是数据驱动的——ORG_NODES = ("planner", "coder", "validator") 硬编码元组，schema.py 四张表的 CHECK (org_node IN ('planner','coder','validator')) 约束——新增角色需要改代码和 schema，不是"包一个新角色进来"。
需求评审结果（2026-08-06）：方向确认，目标/非目标/FR-1~6 按原文通过，进入设计阶段。逐条核实过文档里对代码现状的描述后，发现两处需要修正/补充：
- 风险第 1 条的依赖清单不准确，且遗漏了真正的大头。文档写"
ORG_NODES/FRONTMATTER被deploy_agent_definitions、org_node_trigger、work_graph_orchestrate等多处代码直接依赖"——实测work_graph_orchestrate.py根本不import agent_profile，这条是误判；真正from src.agent_profile import ORG_NODES/from src import agent_profile的只有org_node_trigger.py（校验org_node合法性）和project_scaffold.py（调deploy_agent_definitions()这一个单一入口）——这部分实际依赖面比文档描述的更小，是个好消息。但文档完全没提到两处真正硬编码了三元组的地方：src/work_graph_run_query.py::_VALID_ORG_NODES，以及分量最大的——frontend/app.js里四处独立硬编码（ORG_NODE_DETAIL_RE路由正则、ORG_NODE_ORDER排序数组、任务创建表单的<option value="planner">下拉硬编码列表、byOrgNode查找对象字面量）。设计阶段的依赖梳理必须把这四处也纳入，不能只看schema.py+agent_profile.py。 - 验收标准 1 的边界需要说清楚，不要造成"前端也覆盖了"的错觉。标准 1 明确写了"这个新角色不需要真的接入 Org Graph 执行"（呼应非目标 #1），这意味着即使 FR-3/FR-4（schema +
agent_profile.py）全部做完，PH3 控制台依然认不出这个新角色（上面第 1 点列的 4 处前端硬编码不在 FR-3/FR-4 范围内）——这不是要求本轮解决，而是要求设计文档明确写清楚"前端展示新角色是本轮已知不覆盖的范围"，不要让"新增角色不用改代码"这句话被误读成端到端成立。
其余判断（role 表外键 vs 自由文本+应用层校验、applications 维度最小定义、迁移步骤、workflows 字段怎么接 E）维持文档第 8 节"留待详细设计阶段回答"不变，本次评审不抢先拍板。
实现结果（2026-08-06，FR-3 范围问题跟用户确认过——4 张表一次性全改，不分阶段）：
- 载体格式选了 JSON,不是 YAML：05 §5.7 纯 stdlib 约束排除了 PyYAML；Skill 文件的 YAML frontmatter 之所以能用是因为 graphlemon 自己的代码从来不解析它（只有 Claude Code 自己解析），但 Role Package 需要被
agent_profile.py真正读懂，手写 YAML 子集解析器风险高，json.load零风险。roles/{planner,coder,validator}/role.json三个文件落地，覆盖七个维度。 - role.json 是"引用清单",不是内容复制：
identity.soul_md_path/agents_md_path原样指向没动过的agents/<role>/SOUL.md/AGENTS.md——这个决定让"部署产物必须不变"这条验收标准（标准 2）几乎自动成立：render_agent_definition()的 body 拼接逻辑一行没变，只有 frontmatter 字段的来源从硬编码字典变成解析role.json。逐字节验证过：直接用git show HEAD:src/agent_profile.py跑旧代码、跟新代码的render_agent_definition()输出做 diff，三个角色全部逐字节相同。 agent_profile.py改造：ORG_NODES从硬编码三元组变成扫描roles/目录发现（_discover_role_ids()），FRONTMATTER/_DESCRIPTIONS/_MIGRATED_FROM_PROFILE三个硬编码字典全部删除。三个公开函数都加了roles_dir可选参数，专门用来在测试里证明"新增角色不用改代码"——测试往临时目录塞一个新角色的role.json，直接调用这三个未经修改的函数，确认新角色能被发现、渲染、部署（NewRoleWithoutCodeChangeTest）。- Schema：4 张表全改——
skill.owner_org_node/task.assigned_org_node/work_graph_run.org_node/agent_profile.org_node的CHECK (x IN ('planner','coder','validator'))全部放开成CHECK (x != '')。评审阶段发现的真实改动面比原始风险描述更细：task/work_graph_run/skill被多张表外键引用，但因为改的是父表、子表的REFERENCES定义本身不需要变，只需要重建这 4 张父表本身，不需要动任何子表——按 SQLite 官方文档给的流程（PRAGMA foreign_keys=OFF→ 重建 →PRAGMA foreign_key_check校验无悬空外键 →PRAGMA foreign_keys=ON）写了migrate_relax_org_node_constraints()，依赖 D 的migrate_add_work_graph_fork_columns()先跑（内部会自动调用，幂等）。ux_work_graph_run_active（D 依赖的分区唯一索引）、task的三个索引，重建后都验证过仍然生效。 - 顺手修了评审阶段发现的遗漏依赖：
work_graph_run_query.py::_VALID_ORG_NODES改成直接引用agent_profile.ORG_NODES，不再自己维护一份硬编码三元组。 - 明确没做的部分（如实记录，评审阶段已经说清楚边界）：
frontend/app.js的 4 处硬编码三角色枚举（路由正则、排序数组、下拉列表、查找对象）本轮不改——新增一个角色之后 PH3 控制台依然认不出它，这是刻意保留的已知缺口，不是遗漏；role表外键完整性方案本轮也没做，用的是更简单的"放开枚举"。
python3 -m unittest discover -s src（623 tests）+ discover -s supervisor（125 tests）全绿，零回归。至此 Graph Engineering 系列 A/B/D/E/F/G/H 全部完成，C 已确认不做。
工作量与优先级评估（2026-08-06）
| 项 | 一句话 | 阶段 | 工作量 | 优先级 | 依赖 |
|---|---|---|---|---|---|
| G 并行执行 | Work Graph 层内并发、层间屏障 | ✅ 已实现（bc0eaa5，575 测试全绿） |
M | 已完成 | 无 |
| E 动态 Work Graph 设计能力 | 让 Coder/Validator 也能规划自己的图，Planning 提示词识别可并行节点 | ✅ 已实现（2026-08-06，580 测试全绿） | L | 已完成 | G（已满足） |
| F 三视角评审团 fan-out | judge_root_cause 从 Python 函数改成 Work Graph 菱形拓扑 |
✅ 已实现（2026-08-06，586 测试全绿） | M | 已完成 | 无（G 已满足） |
| B loop-until-dry Skill | Validator 未知规模扫描收敛能力 | ✅ 已实现（2026-08-06，587 测试全绿） | S/M | 已完成 | 无 |
| H Role Package 抽象层 | 统一 role/context/skills/applications/workflows/permissions/acceptance 打包格式 | ✅ 已实现（2026-08-06，623 测试全绿） | XL | 已完成 | 无（E 已满足） |
| D Time-travel 调试 | 回到历史节点分叉重跑 | ✅ 已实现（2026-08-06，608 测试全绿） | L | 已完成 | 无 |
| C 按节点选模型 | — | ⛔ 已确认不做 | — | — | — |
| A 术语对照 | — | ✅ 已完成 | — | — | — |
2026-08-06 更新的关键判断：G 已经被 graphlemon 自己的自举循环实现并验证（不是本轮对话做的——git log 显示提交 bc0eaa5，src/work_graph_orchestrate.py 里 topological_layers()/_LockedConn/WorkGraphLayerError 都是真代码，python3 -m unittest discover -s src 跑出 575 测试全绿，跟 G 条目自己记录的实现细节吻合）。这把之前"G 和 E 必须一起排"的判断更新为：E 现在是唯一的剩余瓶颈——并行执行引擎已经是真的了，但 plan_work_graph() 的提示词依然硬编码只产出一条 BRD→PRD→SDD→Benchmark 直链，没有 E，G 造好的并行能力仍然没有真实的图可以运行。F 也从"强依赖 G，排在后面"变成"G 的执行引擎已经存在，可以直接排"，工作量估算不变但不再需要等待。
工作量估算依据：G（已完成，实际证实是 M 量级——6 步实施计划，改动集中在一个模块）；E（L——Coder/Validator 从未真正走过 plan_work_graph/run_graph 路径，是全新集成，还要防止破坏 Planner 现有生产路径）；F（M——判定逻辑已验证过，只是把 Python 函数调用改造成图形状）；B（S/M——不碰执行引擎，纯提示词工程）；H（XL——自己的需求文档写明"改动面比 B/D/E/F/G 任何一条都大"，4 张表 CHECK 约束+多处代码依赖+从零定义 applications）；D（L——动一条有连锁风险的唯一约束，且控制台可视化工作量可能比后端还大）。
当前推进顺序建议：
- E（P0）——现在是把 G 的投入变成真实收益的唯一剩余步骤，优先推进详细设计。
- F（P1）——G 的执行引擎已就绪，可以直接进入详细设计，不必再等。
- B（P2）——随时可插空，跟其他项无依赖冲突。
- H（P2，建议独立设计周期）——价值是长期的（系统现在被硬编码死在 3 个角色上），不阻塞任何短期工作。
- D（P3）——现在的图都还很简单，time-travel 要解决的"大图不好调"痛点要等 E 落地、图真的变复杂后才会显现。
下一步要我先把 E 推进到详细设计吗？