graphlemon 自举可行性分析：能不能自己开发自己

日期: 2026-07-29（2026-07-30 更新：缺口 2/3 已完成详细设计，见更新记录） 性质: 探索性分析，不是已确认的架构决策，未写入 sdd-mvcp-contract.json。若决定采纳，需要走一次正式的 AskUserQuestion 决策流程，再回填进 05-实施约束与依赖.md 和 contract.json。 结论先说：机制上大部分已经具备（三个 Org Agent 落在目标项目 .claude/agents/*.md、c_project_create 对 target_folder_path 没有排除平台自身路径、git worktree 隔离已经是既定决策），但有三个真缺口会让"自己改自己"从"能跑"变成"跑了但可能很危险"。下面先列缺口，再用一个具体场景走一遍，标出每一步是"✅ 已具备"还是"⚠️ 缺口"。

2026-07-30 更新记录：用户就三个缺口逐条给出方向性决策（1. 确认无条件强制 worktree；2. 确认需要独立 supervisor 进程，可考虑复用 Hermes CLI；3. 明确否决"核心文件强制人工评审"的原提案，改为"supervisor 自动监督回滚即可，不需要人工评审"）。据此完成了 docs/supervisor-design-comparison.md（方案选型：不把 Hermes CLI 接入 supervisor 决策链路，改为复用 graphloop 已验证过的隔离/manifest/apply 库，见 supervisor/isolation/）和 docs/supervisor-auto-rollback-design.md（缺口 2 的蓝绿实例机制 + 缺口 3 的自动回滚机制完整状态机设计）。下面缺口 2/3 的原始描述保留作为问题记录，其"推荐方案"段落已更新为指向这两份新文档。

1. 前提：自举不是从零开始的

自我迭代能力只有在 PH0/PH1（development-plan.md）已经由人类（配合 Claude Code 交互式开发，就是我们现在这个对话在做的事）跑通一次之后才谈得上——这不是缺口，是任何自举系统的必然前提，就像第一版 C 编译器不可能用 C 自己写。development-plan.md 的关键路径已经隐含了这一点。

2. 三个真缺口

缺口 1：worktree 隔离目前只在"并行"时强制，自我修改时必须无条件强制

03-C 3.6 节现有约束是"并行写代码的节点必须先申请 git_worktree_ref"。改别的 target project 时，单个 Coder 节点串行工作直接改主 checkout 问题不大。但如果 target project 就是 graphlemon 自己，正在跑这个任务的后端进程本身就在读取这份代码——直接改主 checkout 有实时干扰正在运行的调度器的风险。

需要新增规则：target_folder_path == graphlemon 平台自身安装路径 时，无论是否并行，一律强制 git_worktree_ref，且 Coder/Validator 的自测/复核全部在 worktree 副本里跑，不碰主 checkout。

缺口 2：没有"应用变更 + 生效"这一步——这是最大的缺口

Validator 在 worktree 里 PASS 之后，现有机制（git_worktree_ref 执行完成后清理并合并回主分支）能把代码合并进 graphlemon 自己仓库的主分支。但合并到主分支的代码不会被正在运行的那个 Node.js/Python 进程自动重新加载。需要重启才能生效，而"正在执行调度逻辑的那个进程"不可能自己发指令重启自己——发出重启指令的那一刻，进程就要被杀掉了。

当前 SDD 里没有任何 controller/process 定义这一步。这不是简单补个接口能解决的，需要一个新的架构组件。

推荐方案（蓝绿实例，而不是原地重启）：不在主进程里做"重启自己"，而是让 Validator 直接对着 worktree 里跑起来的一个独立的第二份 graphlemon 实例（换端口、换一份临时/只读数据库）做验证；通过后由一个在 Graph Engine 控制范围之外的独立 Deploy Supervisor（与架构文档里 Coder Work Graph 内部的"Supervisor（调度子 Agent）"是两个不同概念，注意区分）执行切换：停旧实例 → merge 分支到主分支 → 起新实例。这样"运行中的自己"永远不需要重启自己。

（2026-07-30 已完成详细设计并回填正式 SDD） 完整状态机、健康检查信号、cutover/回滚流程、MVP 固定参数见 docs/supervisor-auto-rollback-design.md；已同步进 01-M/03-C/04-P/05/06/contract.json（新增 REQ-15）。方案选型（为什么不直接用 Hermes CLI 当 Deploy Supervisor 的决策大脑，而是复用 graphloop 已验证的隔离/manifest/apply 库）见 docs/supervisor-design-comparison.md。

缺口 3：核心代码/身份文件的自我修改没有对应缺口 3.5 节 org_graph_definition 那样的强制人工评审

05 节 §5.6 已经规定 org_graph_definition（Org Graph 结构 YAML）的变更必须走人工 PR 评审，不允许系统自主提交；skill（Work Graph 技能定义）允许系统自主迭代但要求 Git 可回滚。但这两条规则都没覆盖：

1. .claude/agents/{planner,coder,validator}.md（Org Agent 身份文件，对应 SOUL.md）——如果 Coder 被要求"优化一下 Validator 的判断逻辑"，改的是判定裁决者本身的人设，一旦改坏（比如让它变得更宽松、更容易判 PASS），系统会在没有外部校验的情况下自我欺骗，而且没人会发现，因为发现问题的机制本身已经被改坏了。
2. 调度器/执行器抽象层等核心引擎代码——和改一个 UI 组件的风险完全不是一个量级。

原提案（已被用户否决，保留作记录）：曾建议 .claude/agents/*.md 的变更、以及触碰 Graph Engine 调度器/执行器抽象层核心逻辑的变更一律强制 blocked_pending_human，走和 org_graph_definition 一样的人工评审通道。

用户更正（2026-07-30，原话）："改坏了的 validator 没有人工评审倒不是问题，坏了由 supervisor 能够监督回滚即可。所以核心是需要一个三方的 agent 来作为补充 supervisor 接口。" —— 即：不要求核心文件改动必须先经人工评审才能生效，而是允许系统自主提交，由缺口 2 的同一个 Supervisor 在部署后持续监控行为信号（例如 Validator 的 approve 率是否偏离历史基线），一旦检测到异常自动回滚，不需要人在"改之前"把关。

（2026-07-30 已完成详细设计） docs/supervisor-auto-rollback-design.md 第 6 节 validator_approval_rate 信号即直接对应"改坏了的 validator"这个场景：从 execution_event/work_node_execution 表按滚动窗口统计 Validator 判定 PASS 的比例，与部署前的历史基线做纯算术比较，偏离阈值即触发自动回滚（该文档第 7.2 节），全程不需要人工评审代码内容。仍保留的唯一人工介入点是"自动回滚机制本身失败"（例如连上一个已知良好版本都起不来）这类基础设施兜底场景（该文档第 7.3 节），而不是"代码判断谁对谁错"。

bug_record.root_cause_category 新增 core_engine 分类的建议仍然保留，但用途从"触发强制人工评审"改为"触发时跳过 fast_lane、走完整的蓝绿部署+监控流程"（普通 Skill 级别的自主迭代可能不需要这么重的验证）。

同理，如果这次自我修改涉及 01-M 自身的数据库 schema（比如给 work_node_execution 加字段），05 §5.6 现有的"允许停机迁移"假设是给人工运维用的，没覆盖"系统自主决定给自己数据库做 schema 变更"——这类改动同样纳入蓝绿部署+监控流程，而不是强制转人工，具体的 schema 迁移在蓝绿切换中的时序（迁移脚本什么时候跑、跑坏了怎么回滚）是 supervisor-auto-rollback-design.md 未覆盖的开放问题，需要后续补充。

3. 模拟走一遍：修复自己状态机里的一个边界 bug

场景：人类发现 graphlemon 自己的 p_org_task_lifecycle 状态机实现里，loop_round >= 3 转 blocked_pending_human 的判断写成了 loop_round > 3（off-by-one，第 3 轮本该拦截却继续跑了）。这段逻辑就在 graphlemon 自己的调度器代码里——一个很好的自举测试用例，因为它既真实又刚好踩中"核心引擎代码"这条线。

步骤	操作	状态
1. 项目登记	c_pick_folder 选中 graphlemon 自己的仓库路径，c_project_create 校验 has_git_repo=true（它自己确实是），创建 .graphlemon/ 子目录	✅ 已具备，架构对 target_folder_path 没有排除平台自身路径
2. 提出目标	c_task_create({goal_text: "修复 p_org_task_lifecycle 里 loop_round 边界判断的 off-by-one", project_id: <self>})	✅ 已具备
3. Planner 触发	c_org_node_trigger(planner)，Planner 读取的正是 graphlemon 自己的 04-P 文档 + 对应源码	⚠️ 轻微缺口：Planner 的 skill 是按"从 PRD 写新 SDD"设计的，这次是"改一处已有实现"，c_work_graph_plan 目前没有区分这两种 graph_manifest 生成路径。大概率能工作（Planner 有能力判断这是小范围修复），但没有显式设计，建议补一条轻量修复路径的规则
4. Coder 节点执行	c_work_node_run 触发 Coder，按缺口 1 的新规则强制走 git_worktree_ref，在隔离副本里改代码、跑单测	⚠️ 命中缺口 1（需要新规则：self-target 场景无条件强制 worktree）
5. Validator 复核	Validator 在 worktree 副本里复现原 bug 场景，确认修复且无回归	⚠️→✅ 命中缺口 3：这次改动是调度器核心代码，root_cause_category 应标记 core_engine，触发的是完整蓝绿部署+监控流程（而不是强制转人工），机制已设计（supervisor-auto-rollback-design.md）
6. 合并到主分支	worktree 分支 merge 回 graphlemon 自己仓库的主分支	✅ 机制已具备（07 节"执行完成后清理 worktree 并合并回主分支"）
7. 生效	需要让正在运行的后端进程加载新代码	⚠️→✅ 命中缺口 2（最大的缺口）：需要蓝绿实例 + 独立于 Graph Engine 之外的 Deploy Supervisor 来完成切换，完整状态机/健康检查/回滚流程已设计并回填 SDD（supervisor-auto-rollback-design.md），尚未实现代码
8. 数据库 schema	本例的判断逻辑修复不涉及 01-M schema 变更，不触发	（本例未命中，但换个例子——比如给 work_node_execution 加字段——会命中缺口 3 的 schema 部分，supervisor-auto-rollback-design.md 第 10 节已列为未覆盖的开放问题）
9. 完成	蓝绿切换完成（Deploy Supervisor 健康检查通过后自动完成，无需人工确认）后 task.status=done	走到这一步，一次"系统被告知自己的缺陷 → 自己诊断根因 → 自己修复 → 自己验证 → 自动部署并被 Deploy Supervisor 持续监控（异常自动回滚）"的完整闭环就跑通了，且全程不需要人工介入代码内容评审

4. 小结

9 步里 3 步直接可用，1 步大概率可用但没显式设计，剩下 5 步（含最关键的"合并后如何生效"）命中三个真缺口。2026-07-30 更新：缺口 2（蓝绿实例生效）和缺口 3（核心文件自我修改的治理，按用户更正为"自动回滚而非强制人工评审"）已完成详细设计，分别落在 docs/supervisor-auto-rollback-design.md（状态机/健康检查/回滚流程/MVP 参数）和 docs/supervisor-design-comparison.md（方案选型依据）。缺口 1（worktree 无条件强制）仍是待写入 05 节的一条治理规则，成本低。

如果要推进，建议顺序：先把缺口 1（一条治理规则）写进 05 节和 contract.json，成本低、马上能落地；缺口 2/3 的设计已经具备可实施粒度，可以作为 PH4 之后的独立 Phase（PH5：自举能力）排入 development-plan.md，不影响当前 PH0-PH4 主线——具体是现在就把 PH5 的 Unit 分解也做出来，还是先确认设计稿本身没问题再排，由用户决定。