【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本篇文章围绕 gsd-core 中一次针对phase remove命令的破坏性数据丢失缺陷修复对应 issue #3601展开剖析 ROADMAP.md 中整数阶段 十进制子阶段两级编号模型下段落删除边界为何会越过同层级的### Phase 2.1:标题并静默吞掉整个十进制阶段。文章以updateRoadmapAfterPhaseRemoval的修复实现为主线结合 deleteSection 段落删除原语、阶段编号正则源与完整回归测试用例给出可复现的缺陷场景、修复后的边界判定规则以及整条phase remove调用链的源码级说明帮助读者理解 gsd-core 是如何用深度感知替代文本形状匹配来根治这一类 Markdown 段落误删问题的。背景phase remove在 ROADMAP 中的两级编号模型gsd-core 的规划工作区.planning/以ROADMAP.md为阶段清单的事实来源标题形如### Phase 2: Parent **Goal:** RemoveMeGoal ### Phase 2.1: Follow-up **Goal:** PreserveDecimalGoal ### Phase 3: Trailing **Goal:** PreserveTrailingGoal这里存在两类阶段整数阶段integer phasePhase 2、Phase 3对应磁盘目录02-parent、03-trailing十进制阶段decimal phase / decimal sub-phasePhase 2.1是挂在整数阶段之下的同级同深度补充阶段对应目录02.1-follow-up。phase remove的语义见 CLI 文档# Remove phase, renumber subsequent node gsd-tools.cjs phase remove phase [--force]即删除指定阶段并把其后所有同轨阶段的编号顺延前移Phase 3→Phase 2。命令行入口在 src/phase-command-router.cts 的remove分支中完成参数解析只接受恰好一个位置参数阶段号可选--force跳过保护检查、--raw输出原始 JSON其余--开头的参数一律按非法参数拒绝。问题在于Phase 2.1和Phase 2是同一深度同是###三级标题的兄弟阶段而删除Phase 2时顺延重编号的边界必须精确停在Phase 2.1之前——一旦边界判定错误Phase 2.1就会作为Phase 2段落的一部分被一并删除造成不可恢复的数据丢失。Bug 剖析为什么旧的文本形状 lookahead会吞掉Phase 2.1修复前的实现使用手写正则完成整段删除其停止边界依赖一个文本形状的 lookahead要求下一个标题的数字部分后面紧跟\s*:即必须是Phase N:这种形态才把该标题当作段落终点。在 src/phase.cts 中对旧实现的代码注释可以还原这条缺陷链删除### Phase 2:时正则以惰性匹配[\s\S]*?扫描段落内容希望在下一次出现Phase N:处停下扫描到### Phase 2.1: Follow-up时lookahead 检验的是2后面是否紧跟\s*:——但这里紧跟的是.1:.1使匹配失败lookahead 因此继续向后扫描直到遇见### Phase 3:才停下于是Phase 2.1整段标题 Goal 正文被当作Phase 2的段落内容一并删除更糟的情况是若被删阶段是 ROADMAP 中最后一个阶段后面不再存在任何Phase N:形状的标题惰性扫描会一直跑到文件末尾EOF连结尾的## Progress标题及其进度表一起被扫走。也就是说缺陷的本质是用下一个标题的文字长什么样来界定段落边界而不是用下一个标题的层级结构来界定段落边界。Phase 2.1:之所以被误伤恰恰因为它的十进制编号.1破坏了旧 lookahead 对N:形状的假设而一个真正的子阶段#### Phase 27.1:四级标题挂在### Phase 27:之下则会被正常删除——修复目标正是要区分这两种长得一样但层级不同的十进制标题。修复方案深度感知的 end-of-section lookahead修复的核心是让段落删除的停止条件从文本形状改为标题深度。changeset 原文描述为updateRoadmapAfterPhaseRemoval现在使用一个 depth-aware 的 end-of-section lookahead先捕获被删标题自身的 hash 数量标题级别然后只在遇到同一深度SAME depth的后续标题时才停下。具体实现落在 updateRoadmapAfterPhaseRemoval它不再手写扫描而是调用 Markdown 章节切分原语deleteSection见 markdown-sectionizer.ctsconst phaseHeadingRe new RegExp( ^Phase\\s${padTolerant}${OPTIONAL_PHASE_TAG_SOURCE}\\s*:, i, ); content deleteSection( content, (h) h.level 2 h.level 4 phaseHeadingRe.test(h.text), );其中deleteSection先用tokenizeHeadings把全文解析成带层级level与行号的标题 token定位目标标题后按levelBounded规则确定停止行删除范围从目标标题自身起始直到下一个 level 小于等于目标 level 的标题为止next.level target.levellevel 数值越小层级越高对### Phase 2level 3而言下一个### Phase 2.1同样是 level 3满足3 3因此立即成为停止边界——Phase 2.1被保留且无论它文本长什么样哪怕将来是Phase 2.XYZ都不影响判定对### Phase 27level 3下的#### Phase 27.1level 4而言4 3不成立Phase 27.1仍是Phase 27段落的一部分删除Phase 27时照常一并删除——与修复目标完全一致。padTolerant前缀0*${escaped}保证了编号对零填充不敏感phase insert 1写出的### Phase 01.1:与用户输入的未填充1.1都能命中同时0*2仍不会错误匹配Phase 12:token 被锚定在Phase\s与:/空白/行尾之间。OPTIONAL_PHASE_TAG_SOURCE(?:\s*\([^)\n]{0,200}\))?则容忍标题冒号前可能存在的括号标签。deleteSection还顺带修复了旧正则的另一个同类缺陷删除范围以同层或更高层标题为界而非特定文本形状因此最后一个阶段的段落也能干净地止于文件末尾或后续的## Progress标题不再出现扫到 EOF 的越界删除。回归测试两个场景锁死 peer-depth 保留行为仓库在 tests/phase.test.cjs 中为该修复固化了完整的回归测试bug #3601: phase remove preserves peer-depth decimal sections通过真实 CLIrunGsdTools([phase, remove, ...], tmpDir)驱动验证场景一单 peer-depth 十进制阶段构造 ROADMAP 含### Phase 2、### Phase 2.1、### Phase 3三段执行phase remove 2后断言Phase 2.1仍然存在phase_name为Follow-up、goal为PreserveDecimalGoalPhase 2.1 deleted alongside Phase 2 的断言被明确标记为回归红线Phase 3被重编号为Phase 2且其 Goal 内容PreserveTrailingGoal完整迁移被删的Phase 2的 GoalRemoveMeGoal不会残留在任何新标题之下。场景二多个 peer-depth 十进制阶段ROADMAP 含### Phase 5、### Phase 5.1、### Phase 5.2、### Phase 6执行phase remove 5后断言Phase 5.1与Phase 5.2双双保留Goal 分别为ChildAGoal/ChildBGoalPhase 6重编号为Phase 5并携带TailGoal。两个用例共同确认了修复的边界语义peer-depth 的十进制兄弟全部保留child-depth 的十进制子阶段仍随父级删除。测试中还使用roadmap get-phase --json在删除后反查阶段内容验证的是磁盘目录 ROADMAP 段落 STATE.md三处状态的一致性而非单纯的正则字符串比对。纵深phase remove的完整调用链与配套修复#3601 的修复并非孤立的正则改动而是整条删除链路的一部分。梳理 cmdPhaseRemove 的实现一次phase remove会依次完成目录解析与歧义拒绝matchPhaseDirs解析目标阶段目录若多个目录匹配同一阶段号直接拒绝执行——这是破坏性路径绝不允许从多个候选里静默选第一个见 src/phase.ctsSUMMARY 保护目标阶段若存在已执行的 Plan 摘要文件除非显式--force否则拒绝删除删除磁盘目录fs.rmSync递归删除目标阶段目录重命名后续目录十进制删除走renameDecimalPhases整数删除走renameIntegerPhases把后续阶段目录顺延改名中途失败会大声报错而不是静默吞掉避免 ROADMAP 与磁盘目录永久失同步更新 ROADMAP.md即本次修复的函数段落删除deleteSection 清单行清理 ## Progress表行删除deleteTableRow限定在## Progress小节内避免误伤文件前面同名结构的无关表格 后续整数阶段重编号decrementRoadmapPhaseToken见 src/phase.cts且会连同阶段号前的括号标签、Prose 中的 slugged Plan/Summary 引用如07-01-cherry-pick-foundation-PLAN.md一并重编号——后者对应配套修复 #3602同样有完整回归测试同步 STATE.md更新Total Phases等字段并重建 frontmatter带Math.max(0, ...)下限保护避免陈旧计数被递减成-1#3572。其中第 5 步对整数删除与十进制删除采用不同策略删除整数阶段时后续整数的标题、清单行与进度表序数会顺延减一而形如2.5的十进制序数phaseCellShapeRe /^(\d)(\.\s)/不匹配紧凑形态保持不动删除十进制阶段本身时则只删该十进制阶段、重编号后续十进制兄弟不触碰整数阶段。编号 token 的统一语法由 phase-id.cts 的phaseMarkdownRegexSource提供渲染为0*integerletterdecimal并有 lint-phase-id-drift.cjs 在 CI 中防止各调用点文字派生漂移。小结用结构而非文本形状界定段落边界#3601 的修复给出了一个可推广的工程结论在 Markdown 文档上做破坏性段落删除时停止边界应由标题的层级结构hash 深度决定而不是由下一个标题的文字是否匹配某种形状决定。前者对任意标题文本都稳定成立后者则会在Phase 2.1:这类合法但形状意外的标题上产生越界扫描轻则误删同级兄弟重则一路吞到 EOF。gsd-core 将这一语义沉淀为deleteSection原语markdown-sectionizer.cts并通过tokenizeHeadings level-bounded 停止规则在 ROADMAP、State 文档等多个写入路径上复用配合 #3601/#3602 的回归测试矩阵tests/phase.test.cjs使删除一个阶段绝不误伤同层兄弟成为可持续验证的契约。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐get-shit-done 的 phase remove 深度保真修复3601 如何用深度感知 Lookahead 防止误删同级小数阶段get shit done 的 phase remove 深度保真修复 3601 如何用深度感知 Lookahead 防止误删同级小数阶段 导读 在 get人工智能AI 应用提示工程开发工具工作流自动化AI Agentgsd-core 阶段移除重编号修复phase remove --force 如何避免 ROADMAP 折叠gsd core 阶段移除重编号修复 phase remove force 如何避免 ROADMAP 折叠 导读 本篇文章讲解 gsd core 中 phasget-shit-done 阶段删除深度解析修复 phase remove --force 旗标位置敏感问题Bug 3409get shit done 阶段删除深度解析修复 phase remove force 旗标位置敏感问题Bug 3409 本文围绕 changeset 记人工智能AI 应用提示工程开发工具工作流自动化AI Agent上一篇30 秒装好 obsidian-skills让 OpenCode 接管你的 Obsidian 知识库下一篇终极Android开发提速指南Cube-SDK让图片加载与网络请求变得前所未有的简单创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考