Superpowers SDD 计划级工作区用结构化身份根治 Subagent-Driven Development 的跨计划账本冲突【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers本文基于 superpowers 仓库的设计规格 2026-07-06-sdd-plan-scoped-workspace.md完整解读 SDDSubagent-Driven Development持久进度工作区从扁平单目录演进为每计划一个独立目录.superpowers/sdd/plan-slug/的设计动机、三层修复方案、配套脚本接口与确定性测试/RED→GREEN 评估方法。读完后你能理解为什么账本ledger缺少计划身份会在多计划工作树中导致任务被静默跳过、如何通过sdd-workspace/task-brief/review-package三个脚本实现结构性隔离以及这套改动是如何用可复现的压力测试验证修复没有破坏合法恢复的。背景持久进度工作区的设计初衷与暴露的缺陷SDD 技能skills/subagent-driven-development/SKILL.md的核心循环是为计划中的每个任务派发一个全新实现者子代理任务完成后做一次任务评审全部任务完成后再做整分支评审。这个流程有一个昂贵的失败模式控制器controller在会话上下文压缩compaction后丢失做到哪了的记忆从而把已完成的任务重新派发一遍。为此技能引入了持久进度工作区.superpowers/sdd/v6.0.0/v6.0.3 引入其中progress.md账本记录每个任务的完成状态SKILL.md 要求控制器在技能启动时检查账本、跳过已标记完成的任务、从第一个未完成的任务恢复。但规格文档指出了两个结构性缺陷工作区没有计划身份也没有生命周期终点。所有产物都只用裸任务编号命名progress.md、task-N-brief.md、task-N-report.md账本里没有记录这个账本属于哪个计划文件没有任何指令负责删除工作区过期状态会永久残留并不断累积。后果是同一个工作树worktree中执行后续计划的新会话会把上一个计划的账本当成自己的进度按技能的字面指令跳过整批任务。实际观察到的失败serf 仓库2026-06-22 → 2026-07-05规格记录了三类真实发生的事故这是本次设计的事实基础跨计划冲突只能临时绕开cc-plugin-marketplaces工作树在一次会话周期内累积了 68 个文件、横跨三个计划。第二个计划P2的控制器被迫自创progress-p2.md和p2-task-N-report.md来躲避 P1 的账本而 P2 的 brief 文件却悄悄覆盖了 P1 在默认路径上的同名文件现场还留下一个被遗弃的progress-p3.md存根。Git 污染发生三次SDD 的临时文件被提交进版本库需要两次清理提交8305e340d、c966261a5serf 主分支至今仍跟踪着三个产物其中包括一份在另一台机器上写成的报告——它现在会在每个新工作树里显形。一个后续计划的 task-1 报告还覆盖了无关的已跟踪文件留下永久性的git status噪音。自愈式.gitignore只在脚本运行时才写入被观察到有控制器是手工追加账本的从未创建.gitignore而一旦文件被 git 跟踪gitignore 就完全失效。根因判断规格的根因表述非常凝练身份在数据中无处安放正确性依赖一个没有触发器的清理动作。任何只靠计划结束时清理的方案恰好会在账本本来要存活下来的崩溃/压缩场景里失效。因此修复必须是结构性的——身份要写进路径和文件本身而不是依赖纪律。设计一每计划一个工作区目录结构性身份核心改动工作区从.superpowers/sdd/变为.superpowers/sdd/plan-slug/其中plan-slug是计划文件去掉.md扩展名后的文件名basename。superpowers 的计划文件本来就遵循带日期的 kebab-case 命名如2026-07-04-plugin-marketplaces-p1-backend-core所以 slug 天然稳定且可区分。不同计划的产物从此不可能再互相覆盖一个过期的兄弟目录是惰性的——因为没有任何指令会指向它。sdd-workspace工作区位置的唯一事实来源解析工作区的脚本是 scripts/sdd-workspace。它的职责是解析并创建某计划的产物目录把绝对路径打印到 stdout。核心实现逻辑节选# Usage: sdd-workspace PLAN_FILE set -euo pipefail if [ $# -ne 1 ]; then echo usage: sdd-workspace PLAN_FILE 2 exit 2 fi plan$1 [ -f $plan ] || { echo no such plan file: $plan 2; exit 2; } slug$(basename $plan .md) [ -n $slug ] [ $slug ! . ] [ $slug ! .. ] \ || { echo cannot derive a workspace name from: $plan 2; exit 2; } root$(git rev-parse --show-toplevel) base$root/.superpowers/sdd dir$base/$slug mkdir -p $dir printf *\n $base/.gitignore cd $dir pwd从源码可以确认几个设计决策参数契约缺少参数、计划文件不存在、或 slug 剥离.md后为空一律以exit 2报错成功时打印计划目录的绝对路径。自愈式.gitignore放在父级脚本每次运行时向.superpowers/sdd/.gitignore注意是父目录不是各计划目录写入一行*使所有计划的工作区整体对git status与git add -A不可见且不需要修改任何已跟踪文件。这同时回答了规格中为什么.gitignore要放在父级的问题只要任何脚本跑过一次全部兄弟目录都被忽略。为什么放在工作树而不是.git/下脚本头注释明确说明——Claude Code 把.git/视为受保护路径并拒绝代理写入会导致实现者子代理无法写报告文件放在工作树里配合自忽略的.gitignore才能两全。单一事实来源task-brief和review-package都通过调用sdd-workspace来解析目录见下杜绝三个脚本各自硬编码路径产生漂移。三个脚本的新接口规格为skills/subagent-driven-development/scripts/下三个脚本定义了新接口当前仓库中三者均已落地脚本签名默认输出位置sdd-workspacesdd-workspace PLAN_FILE打印repo-root/.superpowers/sdd/plan-slug/绝对路径task-brieftask-brief PLAN_FILE N [OUTFILE]workspace/task-N-brief.mdreview-packagereview-package PLAN_FILE BASE HEAD [OUTFILE]workspace/review-base7..head7.difftask-brief的签名不变只是默认 OUTFILE 经由sdd-workspace落到本计划的目录下它用 awk 按Task N标题从计划文件中抽取该任务全文保证实现者一次读取就能拿到完整需求任务文本不必穿过控制器上下文。review-package则新增了 PLAN_FILE 作为第一参数这是向后不兼容的签名变化生成包含提交列表、--stat摘要和-U10完整 diff 的评审包并按提交范围命名使修复轮次的再评审天然得到不同的文件。规格明确声明不为旧的扁平布局保留兼容路径。理由是脚本与 SKILL.md 在同一个插件版本中一起发布且没有别的东西调用这些脚本——这一点在规格中被标注为已明确确认无向后兼容处理。设计二账本首行显式写明所属计划手工账本的兜底目录隔离防住了走脚本的控制器但现实中存在不跑脚本、手工写账本的控制器在 serf 的 ask_user 会话中被实际观察到。因此账本文件workspace/progress.md在创建时的第一行必须是# SDD ledger — plan: docs/superpowers/plans/plan-file.md相应地SKILL.md 的启动检查被改写为计划作用域 条件守卫。当前 SKILL.md 的 Setup 一节约 L122–L140的实际表述是正向的配方式指令而非禁令技能启动时运行scripts/sdd-workspace PLAN_FILE打印出本计划的 git 忽略目录它是本计划全部产物账本、brief、报告、评审包的家另一个计划的目录永远轮不到你读或写。检查workspace/progress.md首行写明你的计划文件的账本中带Task N: complete行的任务是 DONE不要重新派发最后一个任务是修复轮次的则说明卡在修复循环中间从下一轮恢复。首行写明的是另一个计划文件、或残留在旧扁平路径.superpowers/sdd/progress.md的账本——那是别的计划的进度原地保留自己新开一份。这个守卫恰好覆盖两类情况绕过脚本手工记账的控制器以及升级前遗留在旧扁平路径上的脏数据。规格还保留了一条方法论约束守卫的具体措辞服从评估结果见下文 Evaluation只为 RED 基线中真实观测到的失败追加计数器不做臆防。设计三工作区生命周期终点是卫生问题不是正确性问题规格刻意区分了正确性与卫生目录隔离已经保证了正确性删除只是收尾。时机是最终整分支评审干净、且其修复波次如有已合并——在移交给finishing-a-development-branch技能之前——控制器删除自己计划的工作区目录rm -rf $WORKSPACE。理由工作的记录此刻已经在 git 历史里账本的存在意义计划中途的压缩恢复已经用尽。SKILL.md 的 Finish 一节约 L416–L421落地了这一条当最终整分支评审干净且修复已合并删除本计划的工作区——记录现在在 git 里。兄弟目录属于其他计划不要动。这条不碰兄弟目录规则同样保护了被观察到的一类人为留存物跨计划交接文件如WAVE1-HANDOFF.md直接放在.superpowers/sdd/根下不属于任何计划的清理范围。设计四SKILL.md 的触点清单规格列出了 SKILL.md 中需要改动的位置当前仓库中均已体现Durable Progress / Setup工作区解析走sdd-workspace PLAN_FILE账本检查限定在本计划工作区内账本创建格式含计划身份首行失配守卫完成时删除git clean -fdx危险提示更新为新路径工作区是 git 忽略的临时区被git clean -fdx清掉后从git log恢复。Handling Implementer Status / Constructing Reviewer Prompts / File Handoffs / Red Flags / Example Workflow脚本调用全部更新为新签名review-package PLAN_FILE BASE HEAD。SKILL.md 的 Example Workflow 一节现在演示了完整链路sdd-workspace解析 →task-brief生成 →review-package PLAN_FILE BASE HEAD出包 → 账本记账 → 最终删除工作区。规格验证过 implementer-prompt.md 与 task-reviewer-prompt.md 不含任何工作区路径无需改动。Red Flags 表格只在 RED 基线显示出结构修复 守卫文本都关不掉的失败时才追加。明确不做的事Out of scope规格用一整节划定了边界避免范围蔓延不改动finishing-a-development-branch或任何其他技能除现有的父级.gitignore外不引入针对.superpowers/提交的其他 git 级防护不回头清理 serf 仓库的历史污染单独立项跟进不做旧布局迁移或回退读取。确定性测试test-sdd-workspace.sh规格要求扩展 tests/claude-code/test-sdd-workspace.sh当前该文件已实现全部断言并在临时目录中的干净 git 仓库上运行覆盖参数校验sdd-workspace无参数、或缺失计划文件均以 exit 2 报错每计划解析plan-a.md与plan-b.md解析到repo/.superpowers/sdd/plan-a与plan-b两个互不相同的已存在目录自忽略验证.superpowers/sdd/.gitignore内容为*写入artifact.md后git status --porcelain不出现.superpowersgit add -A之后暂存区里也没有它产物落位task-brief plan-a.md 1的输出路径必须是repo/.superpowers/sdd/plan-a/task-1-brief.mdreview-package新签名review-package plan-a.md HEAD~1 HEAD写出repo/.superpowers/sdd/plan-a/review-*.diff不带 PLAN_FILE 的旧调用方式以 exit 2 报错显式 OUTFILE 参数被尊重链接工作树隔离git worktree add出的第二个工作树解析出自己根下的.superpowers/sdd/plan-a与主工作树不同路径且同样对git status不可见——这条断言重新锚定到新布局上确认每工作树、每计划的双维度隔离。规格还要求对既有的test-subagent-driven-development.sh/-integration.sh做旧路径期望审计初次 grep 未发现审计本身是任务门禁。RED → GREEN 评估为什么结构修复在没有复现假设失败的情况下仍然值得发布这部分是本规格最有方法论价值的内容结果完整记录在 2026-07-06-sdd-plan-scoped-workspace-eval-results.md。方法压力场景以全新 sonnet 子代理会话跑在临时目录中的夹具仓库上绝不在本工作树内采用压缩后恢复的会话框架每次重复人工评分被测输出是控制器的恢复决策不真正派发实现者。RED 基线意外假设的失败没有复现最初假设的失败——控制器盲目把陈旧的外部账本当作自己的进度——没有复现跨三种会话框架新会话、可能已恢复、带技能信任账本指令的忠实压缩后恢复共 25/25 次重复控制器都通过法证手段核对了账本引用的提交与 git 历史及计划文件拒绝外部账本并从 Task 1 开始——代价是每次恢复花 6–13 次工具调用做跨计划法证。为诚实证明这一点烧掉了两代夹具v1伪造哈希被一眼识破、v2桩实现被判定为虚假的评审通过记录S2 对照组两次都失败。因此规格重新界定re-scope了主张改动凭结构性记录冲突、临时旁路命名、被覆盖的 brief、git 污染——都来自 serf 仓库加上实测的鉴别成本发布由维护者签核代替 writing-skills 方法论中失败基线的要求。重新界定后的门禁S1 GREEN要求 5/5夹具同时存在旧扁平账本残留和计划 A 的已完成计划级工作区升级后最坏情况恢复中的控制器在计划 B 上直接解析自己的计划级工作区并从 Task 1 开始每次重复记录tool_uses与 RED 基线7/13/9/10/6对比成本差。S2 RED 对照要求 ≥4/5与 S2 GREEN要求 5/5使用诚实的 v3 夹具引用的提交真实实现了各任务的规格、轮换作者、时间戳分散验证合法的同计划恢复——识别任务 1–2 已完成、派发 Task 3。这一条保护的是账本的原始用途修复不能破坏它对照组同时验证夹具本身的可信度。实际结果评估文档的结果表组被测文本夹具结果S1 RED发布版v1v2probe三种框架15/15 拒绝误采平均 9.0 次工具调用做跨计划法证S1 GREEN本分支v3 scoped5/5全部经结构判定工作区 身份首行无一靠提交内容法证S2 RED对照发布版v3 flat5/5验证夹具有效S2 GREEN本分支v3 scoped5/5合法恢复未被破坏评估文档对成本对比的处理值得注意S1 GREEN 的原始工具调用数均值 9.6并没有低于 RED probe均值 9.0文档对此做了诚实披露——GREEN 夹具含有更多陈旧物三处账本位置且判定方式的本质区别在于probe 轮的控制器必须靠跨计划提交/计划文件法证来断定账本是谁的GREEN 轮的控制器按结构判定解析自己的工作区、核对身份首行误归因在新布局下从机制上不可能发生。这才是承重结论而非调用数下降。评估还发现并披露了夹具生成器自身的 bugci计数器在命令替换子shell中被自增导致不生效使所有提交塌缩到同一作者、同一时间戳——恰好是使 v2 对照组失效的夹具制造的历史破绽被计划文本中 Step 1 的自检门禁引用哈希可解析 两个作者跨两天在场景运行前抓住用把计数器持久化到文件的一行级修复解决。风险与接受理由规格对三类已知风险给出了明确处置不同目录下同名计划文件的 slug 冲突接受。计划文件名按惯例带日期前缀实践中同 basename 即同一计划此时恢复正是期望行为。控制器完全绕过脚本、全手工记账缓解手段是账本身份首行守卫S1 评估测量文本指令是否真正约束行为。计划完成后工作区残留、又从头重跑同一计划账本合法地属于同一计划恢复而非重启就是设计行为分叉场景由既有的git log交叉核对技能原文已有覆盖。参考文件路径内容docs/superpowers/specs/2026-07-06-sdd-plan-scoped-workspace.md本文主体设计规格问题、根因、四层设计、边界、测试与风险docs/superpowers/specs/2026-07-06-sdd-plan-scoped-workspace-eval-results.mdRED→GREEN 评估完整记录夹具迭代、逐字回复引用、成本表docs/superpowers/plans/2026-07-06-sdd-plan-scoped-workspace.md该设计的实施计划skills/subagent-driven-development/scripts/sdd-workspace工作区解析脚本唯一事实来源skills/subagent-driven-development/scripts/task-brief任务 brief 抽取脚本skills/subagent-driven-development/scripts/review-package评审包生成脚本新签名skills/subagent-driven-development/SKILL.mdSDD 技能定义含新守卫文本与 Example Workflowtests/claude-code/test-sdd-workspace.sh工作区脚本的确定性 shell 测试套件这套设计给出的通用启示是当持久化状态会被多个逻辑实体此处是计划共享时身份必须编码在路径结构里并由文件首行自证清理策略只能作为卫生手段而非正确性前提同时一个无法复现的假设失败并不妨碍基于真实结构性事故和可测量成本发布改动——前提是像本规格这样用对照组守住原机制仍有效的回归线。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Superpowers SDD 计划级工作区：用结构化身份根治 Subagent-Driven Development 的跨计划账本冲突
Superpowers SDD 计划级工作区用结构化身份根治 Subagent-Driven Development 的跨计划账本冲突【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers本文基于 superpowers 仓库的设计规格 2026-07-06-sdd-plan-scoped-workspace.md完整解读 SDDSubagent-Driven Development持久进度工作区从扁平单目录演进为每计划一个独立目录.superpowers/sdd/plan-slug/的设计动机、三层修复方案、配套脚本接口与确定性测试/RED→GREEN 评估方法。读完后你能理解为什么账本ledger缺少计划身份会在多计划工作树中导致任务被静默跳过、如何通过sdd-workspace/task-brief/review-package三个脚本实现结构性隔离以及这套改动是如何用可复现的压力测试验证修复没有破坏合法恢复的。背景持久进度工作区的设计初衷与暴露的缺陷SDD 技能skills/subagent-driven-development/SKILL.md的核心循环是为计划中的每个任务派发一个全新实现者子代理任务完成后做一次任务评审全部任务完成后再做整分支评审。这个流程有一个昂贵的失败模式控制器controller在会话上下文压缩compaction后丢失做到哪了的记忆从而把已完成的任务重新派发一遍。为此技能引入了持久进度工作区.superpowers/sdd/v6.0.0/v6.0.3 引入其中progress.md账本记录每个任务的完成状态SKILL.md 要求控制器在技能启动时检查账本、跳过已标记完成的任务、从第一个未完成的任务恢复。但规格文档指出了两个结构性缺陷工作区没有计划身份也没有生命周期终点。所有产物都只用裸任务编号命名progress.md、task-N-brief.md、task-N-report.md账本里没有记录这个账本属于哪个计划文件没有任何指令负责删除工作区过期状态会永久残留并不断累积。后果是同一个工作树worktree中执行后续计划的新会话会把上一个计划的账本当成自己的进度按技能的字面指令跳过整批任务。实际观察到的失败serf 仓库2026-06-22 → 2026-07-05规格记录了三类真实发生的事故这是本次设计的事实基础跨计划冲突只能临时绕开cc-plugin-marketplaces工作树在一次会话周期内累积了 68 个文件、横跨三个计划。第二个计划P2的控制器被迫自创progress-p2.md和p2-task-N-report.md来躲避 P1 的账本而 P2 的 brief 文件却悄悄覆盖了 P1 在默认路径上的同名文件现场还留下一个被遗弃的progress-p3.md存根。Git 污染发生三次SDD 的临时文件被提交进版本库需要两次清理提交8305e340d、c966261a5serf 主分支至今仍跟踪着三个产物其中包括一份在另一台机器上写成的报告——它现在会在每个新工作树里显形。一个后续计划的 task-1 报告还覆盖了无关的已跟踪文件留下永久性的git status噪音。自愈式.gitignore只在脚本运行时才写入被观察到有控制器是手工追加账本的从未创建.gitignore而一旦文件被 git 跟踪gitignore 就完全失效。根因判断规格的根因表述非常凝练身份在数据中无处安放正确性依赖一个没有触发器的清理动作。任何只靠计划结束时清理的方案恰好会在账本本来要存活下来的崩溃/压缩场景里失效。因此修复必须是结构性的——身份要写进路径和文件本身而不是依赖纪律。设计一每计划一个工作区目录结构性身份核心改动工作区从.superpowers/sdd/变为.superpowers/sdd/plan-slug/其中plan-slug是计划文件去掉.md扩展名后的文件名basename。superpowers 的计划文件本来就遵循带日期的 kebab-case 命名如2026-07-04-plugin-marketplaces-p1-backend-core所以 slug 天然稳定且可区分。不同计划的产物从此不可能再互相覆盖一个过期的兄弟目录是惰性的——因为没有任何指令会指向它。sdd-workspace工作区位置的唯一事实来源解析工作区的脚本是 scripts/sdd-workspace。它的职责是解析并创建某计划的产物目录把绝对路径打印到 stdout。核心实现逻辑节选# Usage: sdd-workspace PLAN_FILE set -euo pipefail if [ $# -ne 1 ]; then echo usage: sdd-workspace PLAN_FILE 2 exit 2 fi plan$1 [ -f $plan ] || { echo no such plan file: $plan 2; exit 2; } slug$(basename $plan .md) [ -n $slug ] [ $slug ! . ] [ $slug ! .. ] \ || { echo cannot derive a workspace name from: $plan 2; exit 2; } root$(git rev-parse --show-toplevel) base$root/.superpowers/sdd dir$base/$slug mkdir -p $dir printf *\n $base/.gitignore cd $dir pwd从源码可以确认几个设计决策参数契约缺少参数、计划文件不存在、或 slug 剥离.md后为空一律以exit 2报错成功时打印计划目录的绝对路径。自愈式.gitignore放在父级脚本每次运行时向.superpowers/sdd/.gitignore注意是父目录不是各计划目录写入一行*使所有计划的工作区整体对git status与git add -A不可见且不需要修改任何已跟踪文件。这同时回答了规格中为什么.gitignore要放在父级的问题只要任何脚本跑过一次全部兄弟目录都被忽略。为什么放在工作树而不是.git/下脚本头注释明确说明——Claude Code 把.git/视为受保护路径并拒绝代理写入会导致实现者子代理无法写报告文件放在工作树里配合自忽略的.gitignore才能两全。单一事实来源task-brief和review-package都通过调用sdd-workspace来解析目录见下杜绝三个脚本各自硬编码路径产生漂移。三个脚本的新接口规格为skills/subagent-driven-development/scripts/下三个脚本定义了新接口当前仓库中三者均已落地脚本签名默认输出位置sdd-workspacesdd-workspace PLAN_FILE打印repo-root/.superpowers/sdd/plan-slug/绝对路径task-brieftask-brief PLAN_FILE N [OUTFILE]workspace/task-N-brief.mdreview-packagereview-package PLAN_FILE BASE HEAD [OUTFILE]workspace/review-base7..head7.difftask-brief的签名不变只是默认 OUTFILE 经由sdd-workspace落到本计划的目录下它用 awk 按Task N标题从计划文件中抽取该任务全文保证实现者一次读取就能拿到完整需求任务文本不必穿过控制器上下文。review-package则新增了 PLAN_FILE 作为第一参数这是向后不兼容的签名变化生成包含提交列表、--stat摘要和-U10完整 diff 的评审包并按提交范围命名使修复轮次的再评审天然得到不同的文件。规格明确声明不为旧的扁平布局保留兼容路径。理由是脚本与 SKILL.md 在同一个插件版本中一起发布且没有别的东西调用这些脚本——这一点在规格中被标注为已明确确认无向后兼容处理。设计二账本首行显式写明所属计划手工账本的兜底目录隔离防住了走脚本的控制器但现实中存在不跑脚本、手工写账本的控制器在 serf 的 ask_user 会话中被实际观察到。因此账本文件workspace/progress.md在创建时的第一行必须是# SDD ledger — plan: docs/superpowers/plans/plan-file.md相应地SKILL.md 的启动检查被改写为计划作用域 条件守卫。当前 SKILL.md 的 Setup 一节约 L122–L140的实际表述是正向的配方式指令而非禁令技能启动时运行scripts/sdd-workspace PLAN_FILE打印出本计划的 git 忽略目录它是本计划全部产物账本、brief、报告、评审包的家另一个计划的目录永远轮不到你读或写。检查workspace/progress.md首行写明你的计划文件的账本中带Task N: complete行的任务是 DONE不要重新派发最后一个任务是修复轮次的则说明卡在修复循环中间从下一轮恢复。首行写明的是另一个计划文件、或残留在旧扁平路径.superpowers/sdd/progress.md的账本——那是别的计划的进度原地保留自己新开一份。这个守卫恰好覆盖两类情况绕过脚本手工记账的控制器以及升级前遗留在旧扁平路径上的脏数据。规格还保留了一条方法论约束守卫的具体措辞服从评估结果见下文 Evaluation只为 RED 基线中真实观测到的失败追加计数器不做臆防。设计三工作区生命周期终点是卫生问题不是正确性问题规格刻意区分了正确性与卫生目录隔离已经保证了正确性删除只是收尾。时机是最终整分支评审干净、且其修复波次如有已合并——在移交给finishing-a-development-branch技能之前——控制器删除自己计划的工作区目录rm -rf $WORKSPACE。理由工作的记录此刻已经在 git 历史里账本的存在意义计划中途的压缩恢复已经用尽。SKILL.md 的 Finish 一节约 L416–L421落地了这一条当最终整分支评审干净且修复已合并删除本计划的工作区——记录现在在 git 里。兄弟目录属于其他计划不要动。这条不碰兄弟目录规则同样保护了被观察到的一类人为留存物跨计划交接文件如WAVE1-HANDOFF.md直接放在.superpowers/sdd/根下不属于任何计划的清理范围。设计四SKILL.md 的触点清单规格列出了 SKILL.md 中需要改动的位置当前仓库中均已体现Durable Progress / Setup工作区解析走sdd-workspace PLAN_FILE账本检查限定在本计划工作区内账本创建格式含计划身份首行失配守卫完成时删除git clean -fdx危险提示更新为新路径工作区是 git 忽略的临时区被git clean -fdx清掉后从git log恢复。Handling Implementer Status / Constructing Reviewer Prompts / File Handoffs / Red Flags / Example Workflow脚本调用全部更新为新签名review-package PLAN_FILE BASE HEAD。SKILL.md 的 Example Workflow 一节现在演示了完整链路sdd-workspace解析 →task-brief生成 →review-package PLAN_FILE BASE HEAD出包 → 账本记账 → 最终删除工作区。规格验证过 implementer-prompt.md 与 task-reviewer-prompt.md 不含任何工作区路径无需改动。Red Flags 表格只在 RED 基线显示出结构修复 守卫文本都关不掉的失败时才追加。明确不做的事Out of scope规格用一整节划定了边界避免范围蔓延不改动finishing-a-development-branch或任何其他技能除现有的父级.gitignore外不引入针对.superpowers/提交的其他 git 级防护不回头清理 serf 仓库的历史污染单独立项跟进不做旧布局迁移或回退读取。确定性测试test-sdd-workspace.sh规格要求扩展 tests/claude-code/test-sdd-workspace.sh当前该文件已实现全部断言并在临时目录中的干净 git 仓库上运行覆盖参数校验sdd-workspace无参数、或缺失计划文件均以 exit 2 报错每计划解析plan-a.md与plan-b.md解析到repo/.superpowers/sdd/plan-a与plan-b两个互不相同的已存在目录自忽略验证.superpowers/sdd/.gitignore内容为*写入artifact.md后git status --porcelain不出现.superpowersgit add -A之后暂存区里也没有它产物落位task-brief plan-a.md 1的输出路径必须是repo/.superpowers/sdd/plan-a/task-1-brief.mdreview-package新签名review-package plan-a.md HEAD~1 HEAD写出repo/.superpowers/sdd/plan-a/review-*.diff不带 PLAN_FILE 的旧调用方式以 exit 2 报错显式 OUTFILE 参数被尊重链接工作树隔离git worktree add出的第二个工作树解析出自己根下的.superpowers/sdd/plan-a与主工作树不同路径且同样对git status不可见——这条断言重新锚定到新布局上确认每工作树、每计划的双维度隔离。规格还要求对既有的test-subagent-driven-development.sh/-integration.sh做旧路径期望审计初次 grep 未发现审计本身是任务门禁。RED → GREEN 评估为什么结构修复在没有复现假设失败的情况下仍然值得发布这部分是本规格最有方法论价值的内容结果完整记录在 2026-07-06-sdd-plan-scoped-workspace-eval-results.md。方法压力场景以全新 sonnet 子代理会话跑在临时目录中的夹具仓库上绝不在本工作树内采用压缩后恢复的会话框架每次重复人工评分被测输出是控制器的恢复决策不真正派发实现者。RED 基线意外假设的失败没有复现最初假设的失败——控制器盲目把陈旧的外部账本当作自己的进度——没有复现跨三种会话框架新会话、可能已恢复、带技能信任账本指令的忠实压缩后恢复共 25/25 次重复控制器都通过法证手段核对了账本引用的提交与 git 历史及计划文件拒绝外部账本并从 Task 1 开始——代价是每次恢复花 6–13 次工具调用做跨计划法证。为诚实证明这一点烧掉了两代夹具v1伪造哈希被一眼识破、v2桩实现被判定为虚假的评审通过记录S2 对照组两次都失败。因此规格重新界定re-scope了主张改动凭结构性记录冲突、临时旁路命名、被覆盖的 brief、git 污染——都来自 serf 仓库加上实测的鉴别成本发布由维护者签核代替 writing-skills 方法论中失败基线的要求。重新界定后的门禁S1 GREEN要求 5/5夹具同时存在旧扁平账本残留和计划 A 的已完成计划级工作区升级后最坏情况恢复中的控制器在计划 B 上直接解析自己的计划级工作区并从 Task 1 开始每次重复记录tool_uses与 RED 基线7/13/9/10/6对比成本差。S2 RED 对照要求 ≥4/5与 S2 GREEN要求 5/5使用诚实的 v3 夹具引用的提交真实实现了各任务的规格、轮换作者、时间戳分散验证合法的同计划恢复——识别任务 1–2 已完成、派发 Task 3。这一条保护的是账本的原始用途修复不能破坏它对照组同时验证夹具本身的可信度。实际结果评估文档的结果表组被测文本夹具结果S1 RED发布版v1v2probe三种框架15/15 拒绝误采平均 9.0 次工具调用做跨计划法证S1 GREEN本分支v3 scoped5/5全部经结构判定工作区 身份首行无一靠提交内容法证S2 RED对照发布版v3 flat5/5验证夹具有效S2 GREEN本分支v3 scoped5/5合法恢复未被破坏评估文档对成本对比的处理值得注意S1 GREEN 的原始工具调用数均值 9.6并没有低于 RED probe均值 9.0文档对此做了诚实披露——GREEN 夹具含有更多陈旧物三处账本位置且判定方式的本质区别在于probe 轮的控制器必须靠跨计划提交/计划文件法证来断定账本是谁的GREEN 轮的控制器按结构判定解析自己的工作区、核对身份首行误归因在新布局下从机制上不可能发生。这才是承重结论而非调用数下降。评估还发现并披露了夹具生成器自身的 bugci计数器在命令替换子shell中被自增导致不生效使所有提交塌缩到同一作者、同一时间戳——恰好是使 v2 对照组失效的夹具制造的历史破绽被计划文本中 Step 1 的自检门禁引用哈希可解析 两个作者跨两天在场景运行前抓住用把计数器持久化到文件的一行级修复解决。风险与接受理由规格对三类已知风险给出了明确处置不同目录下同名计划文件的 slug 冲突接受。计划文件名按惯例带日期前缀实践中同 basename 即同一计划此时恢复正是期望行为。控制器完全绕过脚本、全手工记账缓解手段是账本身份首行守卫S1 评估测量文本指令是否真正约束行为。计划完成后工作区残留、又从头重跑同一计划账本合法地属于同一计划恢复而非重启就是设计行为分叉场景由既有的git log交叉核对技能原文已有覆盖。参考文件路径内容docs/superpowers/specs/2026-07-06-sdd-plan-scoped-workspace.md本文主体设计规格问题、根因、四层设计、边界、测试与风险docs/superpowers/specs/2026-07-06-sdd-plan-scoped-workspace-eval-results.mdRED→GREEN 评估完整记录夹具迭代、逐字回复引用、成本表docs/superpowers/plans/2026-07-06-sdd-plan-scoped-workspace.md该设计的实施计划skills/subagent-driven-development/scripts/sdd-workspace工作区解析脚本唯一事实来源skills/subagent-driven-development/scripts/task-brief任务 brief 抽取脚本skills/subagent-driven-development/scripts/review-package评审包生成脚本新签名skills/subagent-driven-development/SKILL.mdSDD 技能定义含新守卫文本与 Example Workflowtests/claude-code/test-sdd-workspace.sh工作区脚本的确定性 shell 测试套件这套设计给出的通用启示是当持久化状态会被多个逻辑实体此处是计划共享时身份必须编码在路径结构里并由文件首行自证清理策略只能作为卫生手段而非正确性前提同时一个无法复现的假设失败并不妨碍基于真实结构性事故和可测量成本发布改动——前提是像本规格这样用对照组守住原机制仍有效的回归线。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考