get-shit-done 修复 roadmap update-plan-progress 的零填充不匹配：padded 相位参数如何正确驱动未填充 ROADMAP 进度更新

人工智能AI 应用提示工程开发工具工作流自动化AI Agent【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址https://gitcode.com/GitHub_Trending/getshi/get-shit-done点击查看免费下载导读本文围绕 get-shit-done 仓库中一条type: Fixed的 changeset.changeset/clever-wasps-parade.mdPR #3380展开深入剖析其描述的核心缺陷与修复roadmap.update-plan-progress在收到零填充padded相位参数时此前会静默跳过对未填充unpaddedROADMAP 正文中进度行与复选框的更新。读完本文你将理解该命令的完整行为契约、零填充宽容正则padding-tolerant regex的实现原理、8 个调用点为何会集体“漂移”以及仓库如何用奇偶一致性parity测试守住这条修复不倒退。一、changeset 说了什么一条短小但关键的修复记录.changeset/clever-wasps-parade.md全文仅两段--- type: Fixed pr: 3380 --- roadmap.update-plan-progress now updates unpadded ROADMAP phase rows and checkboxes when called with zero-padded phase arguments.这条 changeset 属于仓库的标准发布说明体系scripts/changeset/下存在完整的解析、渲染、lint 与 GitHub release notes 生成管线配套测试见 tests/changeset-*.test.cjs。它记录了一次“Fixed”级别的缺陷修复关键词有三个命令roadmap.update-plan-progress一个把磁盘上的 PLAN/SUMMARY 计数同步回ROADMAP.md的命令缺陷场景调用方传入了零填充相位参数如02.7修复效果现在能正确更新未填充的 ROADMAP 相位行progress table row与复选框checkbox。要理解这次修复的份量需要先弄清楚这个命令本身是做什么的、它更新哪些内容以及“填充”不一致为什么会让更新静默失效。二、命令定位roadmap update-plan-progress是什么在 get-shit-done 的规划体系中.planning/ROADMAP.md是人与 Agent 共同维护的路标它包含里程碑下的相位列表- [ ] **Phase 2.7: ...**、每个相位的详情小节### Phase 2.7: ...、**Plans:** N plans、计划清单以及进度总表## Progress下的| Phase | Plans | Status | Completed |表格。而真实的执行证据在磁盘上phases/目录中每个相位的NN-01-PLAN.md与对应的NN-01-SUMMARY.md文件。roadmap.update-plan-progress的作用就是以磁盘为事实源回写 ROADMAP 的展示层。它有两种调用形式CLI 形式见 docs/CLI-TOOLS.md 的 Roadmap Commands 一节node gsd-tools.cjs roadmap update-plan-progress NSDK query 形式工作流内统一使用见 get-shit-done/workflows/execute-plan.md 与 get-shit-done/workflows/execute-phase.mdgsd-sdk query roadmap.update-plan-progress ${PHASE}此外命令还兼容--phase N旗标形式以兼容 SDK 参数解析场景对应 CHANGELOG 中 #2796 的修复位置参数解析曾把字面量--phase当作相位值。在查询注册表中该命令被声明为mutation: true、outputMode: json见 sdk/src/query/command-manifest.roadmap.ts路由经由 get-shit-done/bin/lib/roadmap-command-router.cjs 在 CJS 实现与 SDK 实现之间桥接存在GSD_WORKSTREAM或 SDK 不可用时回退到 CJS。三、命令的完整行为契约一次调用改四处CJS 实现位于 get-shit-done/bin/lib/roadmap.cjs 的cmdRoadmapUpdatePlanProgressSDK 移植版位于 sdk/src/query/roadmap-update-plan-progress.ts。两者逻辑一致完整流程如下。3.1 从磁盘统计相位先通过findPhase定位相位目录并统计文件plans为*-PLAN.md或裸PLAN.md文件列表summaries为*-SUMMARY.md或裸SUMMARY.md列表见 sdk/src/query/phase.ts 的getPhaseFileStats。相位不存在时报错Phase ${phaseNum} not found没有计划文件时直接返回{ updated: false, reason: No plans found, plan_count: 0, summary_count: 0 }ROADMAP.md不存在时返回{ updated: false, reason: ROADMAP.md not found, ... }。3.2 判定状态并计算日期const isComplete summaryCount planCount; const status isComplete ? Complete : summaryCount 0 ? In Progress : Planned; const today new Date().toISOString().split(T)[0];状态机为CompleteSUMMARY 数 ≥ PLAN 数、In Progress有部分 SUMMARY、Planned尚无 SUMMARY。3.3 四处 ROADMAP 突变在 CJS 中以withPlanningLock包裹整个读-改-写防并发写坏SDK 中对应readModifyWriteRoadmapMd的原子写。共四处修改进度表行匹配以相位号开头的表格行支持 4 列Phase | Plans | Status | Completed与 5 列多出 Milestone 列两种形态分别更新 Plans 列summaryCount/planCount、Status 列status.padEnd(11)保持对齐与 Completed 列完成时写入YYYY-MM-DD否则留空。详情小节**Plans:**行在### Phase N:小节内定位**Plans:**替换为N/N plans complete完成或N/N plans executed进行中。注意这里使用了[ \t]*而非\s*——CHANGELOG 记录了 #2728 的教训\s*会跨换行匹配导致**Plans:**单独成行时误吞下一行计划复选框同时用小节边界前瞻防止越界改到下一个相位的**Plans:**。相位总复选框相位完成时把总览清单里的- [ ] **Phase N: ...**翻转为- [x] **Phase N: ...** (completed YYYY-MM-DD)。计划级复选框遍历每个 SUMMARY 文件把对应的- [ ] 50-01-PLAN.md、- [ ] 50-01:、- [ ] **50-01**等形态翻转为- [x]正则(-\\s*\\[) (\\]\\s*(?:\\*\\*)?planId(?:\\*\\*)?)。成功后返回{ updated: true, phase: phaseNum, plan_count: 3, summary_count: 3, status: Complete, complete: true }CLI 的非 raw 输出还会附带一行人类可读提示如3/3 Complete。3.4 工作流中的实际使用该命令是执行流水线的“追踪写入点”get-shit-done/workflows/execute-plan.md 的update_roadmap步骤每个计划完成后同步一次仅非 worktree 模式worktree 模式下各工作树各自持有 ROADMAP由编排者统一合并避免兄弟工作树写分叉——即 #2661 的单写者契约get-shit-done/workflows/execute-phase.md 的 5.7 节每波 worktree 合并后对每个完成计划调用gsd-sdk query roadmap.update-plan-progress ${PHASE_NUMBER} ${plan_id} complete且仅当TEST_EXIT为 0测试通过才更新追踪文件——测试失败或超时124时保留计划为进行中状态并把ROADMAP.md/STATE.md的变更用commit --files提交。四、缺陷根源padded 参数 vs unpadded 正文#3537为什么“传入零填充参数”会导致更新失败问题出在正则匹配上。get-shit-done 的技能层在解析出相位目录后倾向于把填充后的形态如02.7因为磁盘目录统一零填充为01-name、02.7-...样式传给命令而人类手写的 ROADMAP 正文约定俗成使用未填充形态### Phase 2.7:、- [ ] **Phase 2.7:**。若正则片段是escapeRegex(phaseNum)精确转义那么02.7永远匹配不到2.7命令“报告成功、文件却毫无变化”——静默空转silent no-op。回归测试 tests/bug-3537-padded-id-against-unpadded-roadmap.test.cjs 的头部注释精确记录了漂移过程v1.42.1 addedphaseMarkdownRegexSource()which renders0*integer...— padding-tolerant on both sides — but wired it into only 1 of 8 call sites. The other 7 used rawescapeRegex(phaseNum)or0*${escapeRegex(...)}(tolerated extra padding, not missing), so passing the padded form silently no-opd and the verbs returned success while ROADMAP.md was unchanged.即0*${escapeRegex(...)}只能容忍“多出的填充”2能匹配02不能容忍“缺失的填充”02匹配不到2。修复只接进了 1 个调用点其余 7 个继续漂移。本次 changesetPR #3380所记录的正是把宽容两侧填充的正则源接入roadmap.update-plan-progress相关调用点的完整落地使“padded 参数 → unpadded 正文”也能产生真实的突变。五、修复机制phaseMarkdownRegexSource的宽容匹配原理核心工具函数位于 get-shit-done/bin/lib/core.cjs 的phaseMarkdownRegexSourcefunction phaseMarkdownRegexSource(phaseNum) { const stripped String(phaseNum).replace(/^[A-Z]{1,6}-(?\d)/i, ); const match stripped.match(/^0*(\d)([A-Z])?((?:\.\d)*)$/i); if (!match) return escapeRegex(phaseNum); const integer match[1].replace(/^0/, ) || 0; const letter match[2] ? escapeRegex(match[2]) : ; const decimal match[3] ? escapeRegex(match[3]) : ; return 0*${escapeRegex(integer)}${letter}${decimal}; }原理三步剥离项目码前缀^[A-Z]{1,6}-(?\d)去掉CK-这类前缀目录CK-02.7-...→ 相位号02.7解析数字结构把0*的整数部分、可选字母后缀12A中的A、可选的十进制段.7、.1.2拆开重排为宽容片段整数部分去掉前导零后前面补0*。于是02.7生成0*2\.7既能匹配2.7也能匹配02.7甚至002.7。对非数字的自定义 ID如PROJ-42则回退为精确转义保证调用点可以无条件替换使用。配套函数phaseMarkdownRegexSourceExact#3599处理项目码前缀形态PROJ-42需先精确匹配### Phase PROJ-42:再回退到数字宽容形态避免与恰好共享尾号的裸### Phase 42:交叉误匹配。从当前 get-shit-done/bin/lib/roadmap.cjs 的调用点可见修复已全面落地roadmap analyze的复选框检测第 270 行、update-plan-progress的表行/Plans/复选框正则第 374 行以及annotate-dependencies第 535 行均使用phaseMarkdownRegexSourcephase.cjs的精确形态调用点则使用phaseMarkdownRegexSourceExact第 151 行。测试文件注释中还披露了一个边界同一份 ROADMAP 内混合填充是合法且真实存在的因此“heading 用2.7、总结区复选框用02.7”也必须同时可匹配。六、测试防线奇偶一致性断言这次修复最值得借鉴的是测试方法论。tests/bug-3537-padded-id-against-unpadded-roadmap.test.cjs构造了一个精确复刻 #3537 报告的 fixture项目码CK、填充目录CK-02.7-meta-lead-ads/、未填充正文Phase 2.7然后对同一 fixture 分别用 padded 与 unpadded 参数各跑一遍断言两个结果 ROADMAP 的字节完全一致expectParity。其核心思想是非空洞通过non-vacuous pass除了断言两者相等还断言- [x] **Phase 2.7:确实发生了翻转——否则“两边都静默空转”也能通过等值断言测试就失去了意义覆盖所有受影响动词phase complete、roadmap get-phase--raw、phase next-decimal、phase insert、roadmap annotate-dependencies、roadmap update-plan-progress反向回归phase next-decimal中额外断言“不能因为扫描失败就跳过已存在的2.7而错误提议02.1”。SDK 侧的单测 sdk/src/query/roadmap-update-plan-progress.test.ts 则用更细粒度断言锁住四处突变padded 参数03驱动 unpaddedPhase 3的复选框翻转、**Plans:** 1/1 plans complete、表格行| 3. build | 1/1 | Complete | 2026-..-.. |、计划复选框- [x] 03-01-PLAN.md并回归 #2728 的两个坑**Plans:**单独成行时不得覆盖其后的计划列表且不得越界改写下一个相位Phase 8/Phase 10的**Plans:**行。七、结论与使用建议roadmap.update-plan-progress是 get-shit-done“磁盘即事实源、ROADMAP 即展示层”设计的关键同步器。本次 changeset 修复的实质是把相位号匹配从“精确形态”升级为“任意填充形态”无论调用方传2.7还是02.7无论 ROADMAP 正文写作Phase 2.7还是Phase 02.7命令都应产生字节一致的突变结果。给使用者的建议调用时可放心传 padded 形态如技能层解析出的02.7命令已能正确回写未填充正文不必再手动归一化相位号利用--raw输出调试CLI 的 raw 模式直接输出 JSON 载荷便于确认updated、status、complete字段是否符合预期留意失败语义No plans found/ROADMAP.md not found会返回updated: false而非报错工作流编排时应检查该字段保持 fixture 覆盖若未来新增任何解析 ROADMAP 相位号的调用点应复用phaseMarkdownRegexSource并补一条“padded 与 unpadded 奇偶一致”测试防止下一个调用点重新漂移——这正是 #3537 用 8 个调用点漂移换来的教训。相关参考docs/CLI-TOOLS.md命令速查、CHANGELOG.md#2728、#2796 等相邻修复、sdk/src/query/QUERY-HANDLERS.mdquery 注册表。赞分享人工智能AI 应用提示工程开发工具工作流自动化AI Agent【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址https://gitcode.com/GitHub_Trending/getshi/get-shit-done点击查看免费下载相关推荐gsd-core 修复详解零填充 Phase 参数如何正确更新未填充的 ROADMAP 进度表gsd core 修复详解零填充 Phase 参数如何正确更新未填充的 ROADMAP 进度表 导读 本文剖析 gsd coreGit. Ship. Donget-shit-done 修复 3599 深度解析roadmap get-phase 如何正确命中 project-code 前缀阶段 IDget shit done 修复 3599 深度解析roadmap get phase 如何正确命中 project code 前缀阶段 ID 本文基于仓库中人工智能AI 应用提示工程开发工具工作流自动化AI Agentget-shit-done 阶段正则扇出修复让 02.7 与 2.7 双向匹配的 ROADMAP 解析机制get shit done 阶段正则扇出修复让 02.7 与 2.7 双向匹配的 ROADMAP 解析机制 本文基于仓库中 .changeset/3537 p人工智能AI 应用提示工程开发工具工作流自动化AI Agent上一篇can2040项目安装与使用指南下一篇IDM-VTON快速入门指南5分钟学会使用AI虚拟试穿技术创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考