# 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/done/supervisor-design-comparison.md`（方案选型：不把 Hermes CLI 接入 supervisor 决策链路，改为复用 graphloop 已验证过的隔离/manifest/apply 库，见 `supervisor/isolation/`）和 `docs/done/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/done/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/done/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/done/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/done/supervisor-auto-rollback-design.md`（状态机/健康检查/回滚流程/MVP 参数）和 `docs/done/supervisor-design-comparison.md`（方案选型依据）。缺口 1（worktree 无条件强制）仍是待写入 05 节的一条治理规则，成本低。

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