From 69c3ea6217bb4b49146a10cc5f34f88f29975277 Mon Sep 17 00:00:00 2001 From: bboonnee Date: Sun, 2 Aug 2026 01:32:54 +0800 Subject: [PATCH] U-033: close out A-2 (Hermes SOUL.md migration) using PH1-PH4 real-run evidence --- docs/development-plan.md | 3 +++ docs/sdd/00-SDD-生成记录.md | 2 +- docs/sdd/unit_matrix.json | 2 +- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/docs/development-plan.md b/docs/development-plan.md index dfaa664..784933b 100644 --- a/docs/development-plan.md +++ b/docs/development-plan.md @@ -310,6 +310,9 @@ PH2-S1/S2/S3/S4 之间除标注的依赖外相互独立，可并行推进。 - **U-033 [Risk Gate]** A-2 假设收口：Hermes SOUL.md 迁移效果复核，确认 `confirmed` 或记录偏差 - 依赖：U-004（此时已有足够真实运行数据判断人设迁移是否真的"不需要大改"） + - Done：A-2 状态确认为 confirmed 或记录实际偏差（原文档缺 Done 行，2026-08-02 补上） + - **实现补充（2026-08-02）**：复核范围是"PH1~PH4 期间积累的真实运行数据，有没有暴露出 U-004（2026-07-31）当时没发现的新偏差"，不是重新跑一次 U-004 已经做过的验证。梳理了 U-004 之后每一次真实调用迁移后人设的记录：U-011（`plan_work_graph` 真实调用，回复引用"SOUL 原则 #10"）、U-014（"贪吃蛇游戏"真实完整闭环，Coder/Validator 人设都真实跑过）、U-031（`agentType` spike 里模型自称"Planning Agent (PL)"，以及完整 `plan_documents()` 四节点真实调用）——全部指向同一个结论：迁移后的人设内容本身没有再出问题，U-004 当时发现的三处 Coder 偏差（飞书 Base token/`lark-cli`/`--dangerously-skip-permissions`）已经是偏差的全部范围。期间另外发现的 05 §5.4.1.2（`disallowedTools` 子命令限定 bug，一度让 Validator 没有 Bash 权限）判断为工具权限层的 Claude Code 平台行为，不算 A-2 问的"人设内容需要大改"，不计入偏差范围（A-2 的验证计划字面问的是 `SOUL.md`/`AGENTS.md` 内容能否原样迁移，不是工具层配置语法）。**最终结论：维持"部分成立"，不改判为 confirmed**——U-004 时已发生的大改是既成事实，不会因为后续没再出新问题就被追溯为"没有大改"；U-033 的收口价值在于确认这个偏差范围到此为止、没有持续扩大，PH5 排期不需要为 A-2 预留额外风险缓冲。详见 `00-SDD-生成记录.md` A-2 行的最终状态记录。 + - 覆盖：00 节 A-2 假设（最终状态：部分成立，已收口） --- diff --git a/docs/sdd/00-SDD-生成记录.md b/docs/sdd/00-SDD-生成记录.md index 63838bc..6fcf552 100644 --- a/docs/sdd/00-SDD-生成记录.md +++ b/docs/sdd/00-SDD-生成记录.md @@ -44,6 +44,6 @@ | 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` 调用 | **部分成立（2026-07-31）**：Planner/Validator 的 `SOUL.md` 几乎原样迁移（只改了引用飞书 Base 状态机的那几行），且真实 `claude --agent planner -p`（`--permission-mode auto`，成本 $0.05）调用验证通过——返回内容准确复述了迁移后的身份与红线（"turn ambiguous intent into a verifiable... delivery contract...I never write business code"），不是默认助手人设。但 Coder 的 `SOUL.md` **不能**原样迁移：原文件硬编码了一个真实飞书 Base API token（已从迁移版本中彻底删除，不进 git）、整段"认领"机制强绑定 `lark-cli`/Base 状态机、且指示自己再跑一次 `claude --dangerously-skip-permissions`（与 05 §5.3.1 的 `auto` 权限模式决策直接冲突）——三处都是实质性重写而非格式包装。因此按 development-plan.md U-004 自己预先注册的判定标准（"若迁移后发现人设内容需要大改...应记录为部分成立而非直接标 confirmed"），A-2 记为部分成立，不是 confirmed。见 `agents/{planner,coder,validator}/SOUL.md` 各自文件头的迁移说明 | +| 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 | diff --git a/docs/sdd/unit_matrix.json b/docs/sdd/unit_matrix.json index 109a279..b52f2a0 100644 --- a/docs/sdd/unit_matrix.json +++ b/docs/sdd/unit_matrix.json @@ -49,7 +49,7 @@ {"id": "U-031", "phase": "PH4", "sub_phase": "PH4-S1", "name": "REQ-01~14 全量自动化回归（见 development-plan.md 2026-08-01 实现补充）", "classification": "Risk Gate", "depends_on": ["U-014", "U-017", "U-020", "U-021", "U-022", "U-023", "U-024.5", "U-025", "U-026", "U-027", "U-028", "U-029", "U-030"], "coverage": {"model": [], "view": [], "controller": [], "process": [], "requirement": ["REQ-01", "REQ-02", "REQ-03", "REQ-04", "REQ-05", "REQ-06", "REQ-07", "REQ-08", "REQ-09", "REQ-10", "REQ-11", "REQ-12", "REQ-13", "REQ-14"]}, "done": "06 节全部 14 条 REQ 的全部用例通过一次完整回归；回归审计中发现 c_work_graph_plan/c_work_graph_execute/c_work_node_run 三个模块彼此隔离测试通过但从未被生产代码真正串联（唯一验证过的闭环 e2e_pipeline.py 绕开了三者，直接用 org_node_trigger），已按用户决策现场补上集成：新增 src/work_graph_orchestrate.py（拓扑排序 + 每节点一份独立动态工作流脚本调用 run_work_node），e2e_pipeline.py 的 plan_documents/implement_code 改为真调用 plan_work_graph→run_graph；真实 API 验证过程中发现并修复两个真实 bug（graph_manifest 的 id/node_id 字段名及 depends_on 缺失见 work_graph_plan._normalize_graph_manifest；run_work_node 缺 repo_path 导致 cwd=None）"}, {"id": "U-032", "phase": "PH4", "sub_phase": "PH4-S2", "name": "多 Goal 并发 + 长时间运行稳定性压测（见 development-plan.md 2026-08-02 实现补充）", "classification": "Risk Gate", "depends_on": ["U-031"], "coverage": {"model": ["org_concurrency_config"], "view": [], "controller": [], "process": [], "requirement": ["REQ-09"]}, "done": "并发数调高后多个独立 Goal 可同时稳定运行；发现并补上一个此前从未存在的结构性缺口——04-P/01-M/REQ-09 boundary 反复假设存在的自动调度器实际从未被建过，新增 src/scheduler.py（ThreadPoolExecutor + 每线程独立 sqlite 连接，避免复刻 U-027 的共享连接锁陷阱）真正实现，并顺带补上 e2e_pipeline.run_end_to_end() 自己文档过的缺口（PASS/FAIL 后从不调用 close_task_done/run_fix_loop，卡在 validating 不动）"}, - {"id": "U-033", "phase": "PH4", "sub_phase": "PH4-S3", "name": "A-2 假设收口", "classification": "Risk Gate", "depends_on": ["U-004"], "coverage": {"model": [], "view": [], "controller": [], "process": [], "requirement": [], "assumption": ["A-2"]}, "done": "A-2 状态确认为 confirmed 或记录实际偏差"}, + {"id": "U-033", "phase": "PH4", "sub_phase": "PH4-S3", "name": "A-2 假设收口（见 development-plan.md 2026-08-02 实现补充）", "classification": "Risk Gate", "depends_on": ["U-004"], "coverage": {"model": [], "view": [], "controller": [], "process": [], "requirement": [], "assumption": ["A-2"]}, "done": "A-2 状态确认为 confirmed 或记录实际偏差；最终结论：维持 U-004 记录的\"部分成立\"，PH1~PH4 积累的真实运行数据未暴露新偏差，偏差范围到 U-004 为止已完全摸清（Coder SOUL.md 三处实质性重写），不改判 confirmed，正式收口"}, {"id": "U-034", "phase": "PH5", "sub_phase": "PH5-S1", "name": "01-M 扩展：deployment/deploy_health_signal + core_engine 枚举", "classification": "Enabler", "depends_on": ["U-001"], "coverage": {"model": ["deployment", "deploy_health_signal", "bug_record"], "view": [], "controller": [], "process": [], "requirement": []}, "done": "两张新表建表成功；bug_record 新枚举值向后兼容 U-015/U-018 已有测试"}, {"id": "U-035", "phase": "PH5", "sub_phase": "PH5-S1", "name": "self-target worktree 无条件强制 + core_engine 路由到蓝绿部署", "classification": "Risk Gate", "depends_on": ["U-013", "U-016", "U-034"], "coverage": {"model": [], "view": [], "controller": ["c_org_loop_route"], "process": [], "requirement": ["REQ-03"]}, "done": "self-target 时无条件走 worktree；core_engine 分类的 bug 被路由到 PH5-S2/S3 而非 fast_lane；且改动落地后必须重跑 U-013/REQ-03（worktree 隔离）现有回归用例全部通过（2026-07-30 计划评审追加，确认未破坏 PH4 已建立的隔离保证）"}, -- libgit2 0.21.4