00-SDD-生成记录

元信息

字段	值
project	graphlemon
version	v1.7.0（决策：MVP 阶段只用 Claude Code ACP 一种执行后端，不考虑 Hermes CLI，见架构文档 7.2 节；新增 Claude Code plan 额度耗尽的等待重试机制 p_usage_limit_wait，见 03-C 3.6 节、04-P 4.4.1 节；新增 PH5 自举能力——Deploy Supervisor 蓝绿部署与自动回滚，见 01-M 1.15/1.16 节、03-C 3.15 节、04-P 4.6 节、06 节 REQ-15，详细设计见 docs/done/supervisor-auto-rollback-design.md）
owner	bboonnee
effective_date	2026-07-30
方法论	复用本地 Hermes planning profile 的 project-sdd-planning skill（MVCP：Model/View/Controller/Process）

输入来源

本 SDD 的输入不是独立的 PRD 文件，而是 docs/graphlemon_architecture.md（v0.9，已与用户逐项对齐确认）。经用户确认，该文档作为 PRD 等价输入直接驱动本 SDD 编写（见架构文档第 8 / 9 / 10 / 12 / 13 节的全部已确认决策）。

产出清单

1. 01-M-模型设计.md
2. 02-V-界面与交互.md
3. 03-C-控制与接口.md
4. 04-P-流程与状态流转.md
5. 05-实施约束与依赖.md
6. 06-验收与测试锚点.md
7. sdd-mvcp-contract.json（Coder Agent 可直接消费的结构化约束包）

范围声明

本 SDD 覆盖架构文档第 11 节定义的 MVP 范围：单一 Dev Organizer 全链路（Planner → Coder → Validator 三节点 Org Graph + Validator → Planner 回退边），以"贪吃蛇游戏"类边界清晰任务为验收场景。不覆盖：多 Goal 并发（架构已支持，但 MVP 并发数参数固定为 1，非本期开发重点）。

执行后端范围收窄（决策，2026-07-29）：MVP 阶段只实现 Claude Code ACP 一种执行后端，不考虑 Hermes CLI 后端。此前"双后端能力不对等"的框架（架构文档 10.1/7.2 节）不再适用——不是"两个后端能力不对等"，而是"只有一个后端"。执行器抽象层（Executor Interface）的接口设计仍然保留，为未来接入其他底层引擎留出扩展点，但 MVP 阶段只需要有一个可用实现。Hermes profile 的内容复用（SOUL.md/skills，见架构文档第 9 节）不受影响——复用的是人设与方法论文本，落地形式是 Claude Code 的 project-scoped subagent 定义文件（.claude/agents/{planner,coder,validator}.md），不是运行 Hermes CLI 本身。

非目标（non-goals）

• 不做飞书 Base 迁移的历史数据导入（历史 Hermes profile 的 memories/、sessions/ 不做自动迁移，按架构文档 9.1 节人工筛选复用）。
• 不做多租户/多团队权限体系（MVP 单用户使用）。
• 不做 Hermes CLI 执行后端（决策，2026-07-29：MVP 阶段只用 Claude Code ACP 一种后端，见范围声明）。
• 不做 Skill 自主迭代的人工审批 UI（已确认 Skill 自主迭代立即生效，只需 Git 可追溯，见架构文档 8 节决策 1）。
• 不做完整多项目管理 UI（项目列表/切换），数据模型预留 project 但 MVP 只支持单个 active 项目。
• 不做日志清理周期的用户可配置（仅保留天数/总量上限可配，清理任务触发频率固定）。

假设（待验证，需标注 owner）

ID	假设	Owner	验证计划	状态
A-1	Claude Code 的 agent()/parallel()/pipeline() 原语可通过 claude -p 非交互式调用，且能返回结构化可解析结果	bboonnee	已完成 spike 实测（spikes/a1-dynamic-workflows/），真实账号运行，成本 $0.46	confirmed（2026-07-29）：claude -p ... < /dev/null 无交互提示、40s 完成、structured_output 精确匹配预期（sum=29）、permission_denials 为空；唯一限制是不能加 --bare（会跳过登录态发现），需用完整冷启动调用。具体实现契约见 03-C 3.5 节
A-2	本地 Hermes profile 的 SOUL.md/AGENTS.md 可以原样迁移到目标项目的 .claude/agents/{planner,coder,validator}.md 而不需要大改人设内容	bboonnee	U-004：实际迁移一次并跑通真实 claude --agent planner -p 调用；U-033：PH1~PH4 积累的全部真实调用数据上做最终复核	部分成立（最终结论，2026-08-02，U-033 收口）：维持 U-004（2026-07-31）记录的"部分成立"判定，不改判为 confirmed——Coder 的 SOUL.md 当时确实需要实质性重写（飞书 Base token/lark-cli 强耦合、--dangerously-skip-permissions 指示），这条偏差本身就是"部分成立"判定的直接依据，事后追加的真实运行数据不会让一次已发生的大改变回没发生过。U-033 的复核范围是"PH1~PH4 期间积累的真实运行数据有没有暴露出 U-004 当时没发现的新偏差"——结论：没有。证据：① Planner 的迁移人设在 U-004 之后又被真实验证了三次，视角各不相同（U-011 的 plan_work_graph 真实调用里，回复原文引用了"SOUL 原则 #10"这个具体编号；U-031 的 agentType spike 里，追问身份时模型明确自称"Planning Agent (PL)"；U-031 完整 plan_documents() 四节点真实调用再次印证），每次都是准确的迁移后身份，没有退化成通用助手人设，也没有再暴露新的强耦合内容；② Coder/Validator 的迁移人设在 U-014 的"贪吃蛇游戏"真实完整闭环（真实写代码、真实跑测试、真实给出裁决）里被验证过，闭环成功完成，人设内容本身没有再暴露除 U-004 已修复三处之外的新问题；③ 期间唯一另外发现的一个人设相关缺陷（05 §5.4.1.2：subagent frontmatter 的 disallowedTools 不支持按子命令限定，导致 Validator 一度完全没有 Bash 权限）是工具权限层的 Claude Code 平台行为差异，不是 SOUL.md/AGENTS.md 内容本身需要大改，不计入 A-2 的偏差范围（A-2 问的是人设文本能不能原样迁移，不是工具层配置语法）。结论：A-2 的最终状态是"部分成立"，偏差范围到 U-004 为止已经完全摸清，PH1~PH4 的真实运行没有扩大这个偏差范围，可以正式收口，不需要为此新建 Unit 或阻塞 PH5 排期。见 agents/{planner,coder,validator}/SOUL.md 各自文件头的迁移说明、development-plan.md U-033 的实现补充
A-3	Hermes CLI 后端在 MVP 阶段以"单点执行 Org Agent"方式接入即可满足验收	bboonnee	不适用（决策，2026-07-29：MVP 阶段不考虑 Hermes CLI 后端，见范围声明）	not_applicable
A-4	控制台为本地 Web 应用，文件夹选择由本地后端代拉系统原生对话框（c_pick_folder）实现	bboonnee	已确认为产品决策（架构文档 13.1 节决策 5），实施时需按 macOS/Windows/Linux 分别验证原生对话框调用方式	confirmed