【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载phase complete是 GSDGit. Ship. Done核心流程中负责推进阶段Phase的关键命令。当项目以乱序方式补完一个重新打开的阶段即编号更靠后的阶段早已勾选 [x]时旧逻辑会把数值上紧随其后的已完成阶段误判为下一个阶段并持久化进STATE.md的current_phase字段导致进度状态与 ROADMAP 实际勾选情况脱节。本文以 changeset 记录.changeset/daring-finches-zip.mdtype: FixedPR 4820对应 issue #4699为核心结合 src/phase.cts、src/init.cts、src/roadmap.cts 的源码与 tests/phase.test.cjs 的回归测试完整还原该缺陷的产生原因、修复方案、三层 next-phase 解析级联及其验证方式帮助读者理解 GSD 中ROADMAP 顺序即前沿这一核心一致性规则。一、缺陷背景乱序完成out-of-order completion为何会污染 current_phase在 GSD 的规划模型中一个里程碑Milestone内的阶段由ROADMAP.md定义每个阶段对应一个复选框条目如- [ ] **Phase 2: Two**phase complete完成某个阶段时会将该复选框改写为[x]。阶段目录.planning/phases/按NN-slug命名但目录是惰性创建的——只有真正执行过的阶段才会有目录因此磁盘上有哪些目录并不能可靠地代表下一个未完成的阶段是谁。在修复前phase complete的 next-phase 扫描存在两个未考虑完成状态的问题磁盘目录扫描stage 1和 ROADMAP 条目扫描stage 2都以数值上严格大于 N 的最小阶段号作为候选从不检查该阶段的复选框是否已经是[x]一旦选中该结果会通过completePhaseCore状态转换src/state-transition.cts与syncAndPreserveStateMd写回STATE.md的current_phase/current_phase_name字段造成持久化的错误状态。典型受害场景里程碑包含 Phase 14Phase 3、4 已按序完成并勾选[x]随后 Phase 2 被重新打开并补完此时 Phase 3、4 依旧保持[x]。旧逻辑在完成 Phase 2 后数值上最小的大于 2的阶段是 Phase 3于是把已完成的 Phase 3 写为current_phase——而roadmap analyze与init progress却正确地报告 Phase 4 才是下一个可执行阶段三方输出互相矛盾。这正是 changeset 所描述的回归现象picked the numerically-next phase even when its checkbox was already ticked, persisting it to STATE.md as current_phase。二、修复核心以 ROADMAP 复选框[x]作为完成判据2.1 完成的定义复选框即完成修复的根基是一条早已确立的规则一个阶段是否完成由 ROADMAP 中该阶段复选框是否为[x]决定源码注释引用 #2028A phase is complete iff its roadmap checkbox is[x]见 src/phase.cts。phase complete在完成某阶段时正是通过改写该复选框来标记完成状态src/phase.cts 附近的复选框改写逻辑写入$1x$2 (completed ${today})。2.2 收集已完成阶段集合roadmapCompleteNums修复在src/phase.cts的 next-phase 解析入口约 L4364-L4393新增了已完成阶段集合的收集逻辑通过extractCurrentMilestone(roadmapContent, cwd)提取当前里程碑文本用正则-\s*\[[xX]\]\s*(?:\*\*|__)?\s*Phase\s(PHASE_NUMBER_TOKEN_SOURCE)匹配所有复选框已勾选大小写不敏感兼容[x]与[X]的阶段行跳过哨兵阶段 IDisSentinelPhaseId对应SENTINEL_RANGES [0, 999]的 0.x 草稿与 999.x 积压阶段通过comparePhaseNum去重——这样02与2会被视为同一阶段保证零填充zero-padding写法不会造成集合成员重复该收集是 best-effort若ROADMAP.md不存在或无法解析集合为空扫描行为与修复前完全一致fail-open。最终得到谓词isCompletePhaseNum(num)供两路扫描共用。2.3 两路扫描同时加闸修复对 stage 1 与 stage 2 做了对称的拦截磁盘目录扫描src/phase.cts遍历listMilestonePhaseDirs返回的阶段目录时若roadmapContent ! null isCompletePhaseNum(dm[1])则continueROADMAP 条目扫描src/phase.cts匹配到 heading 或 checkbox 形式的阶段行后同样对已完成阶段continue。两路都保留数值最小优先numeric MINIMUM above N而非首个命中的选择语义并用comparePhaseNum统一比较。由于该谓词基于comparePhaseNum去重磁盘上的03-three目录与 ROADMAP 中的Phase 3会被视为同一个已完成阶段不会漏网。三、三层 next-phase 解析级联修复在其中的位置要理解本次修复的边界需要先看清phase complete的 next-phase 解析是一个三级级联源码注释将其称为 3-stage cascading fallback见 src/phase.cts阶段数据来源规则关联 issueStage 1.planning/phases/磁盘目录数值上严格大于 N 的最小目录#2245、#3185、#3701Stage 2ROADMAP.md当前里程碑的 heading 与 checkbox 行数值上严格大于 N 的最小阶段行#1591、#1729、#4078、#3701Stage 3ROADMAP.md的复选框状态#2028 最低未完成覆盖若存在编号更低且复选框未勾选[x]的阶段则把它选为 next#2028、#2949、#3350本次 #4699 修复针对的是Stage 1 与 Stage 2 的共同盲区它们只问谁数值更大不问谁还没完成。而 Stage 3 恰好相反——它专门寻找编号更低但未勾选的阶段防止phase complete在乱序完成编号最高的阶段时错误地宣告里程碑结束。修复后三个 stage 在复选框[x]即完成这一判据上达成一致若某阶段已[x]Stage 1/2 不再选它Stage 3 的最低未完成覆盖逻辑保持原样因为[x]的完成判据本来就与它一致。解析顺序与优先级保持roadmap wins on identity; the disk wins on spellingsrc/phase.cts两路都找到时以 ROADMAP 的身份为准仅当二者指向同一阶段时才采纳磁盘的零填充拼写如03或 slug 名称。四、与 roadmap analyze / init progress 的一致性changeset 强调修复后next_phase与roadmap.analyze、init.progress保持agreeing。src/roadmap.ctscmdRoadmapAnalyze输出next_phase: nextPhase ? nextPhase.number : null其 next-phase 推导同样基于未完成阶段src/init.ctsinit.progress明确注释了 #3581: the frontier is ROADMAP ORDER, not artifact presence——从排序后的阶段并集重新推导前沿第一个状态为pending/not_started且roadmap_complete ! true的阶段即为 next_phase。也就是说这两个命令从一开始就以ROADMAP 未完成为唯一判据从未被磁盘目录误导#4699 修复正是把phase complete拉回同一判据从而消除三者间的分歧。五、回归测试验证tests/phase.test.cjs 为本次修复新增了完整的 describe 块phase complete skips already-complete phases as next_phase (#4699)共 5 个用例覆盖了修复的全部行为面测试用例场景断言completing phase 2 out of order skips the already-complete phase 3Phase 1[x]、Phase 3[x]完成 Phase 2next_phase 4、is_last_phase false且STATE.md中current_phase不匹配3all later phases already [x] completes the milestone tailPhase 3、4 均[x]完成 Phase 2is_last_phase true、next_phase null里程碑尾部uppercase [X] checkboxes are recognized as completePhase 3 写作[X]next_phase 4大小写不敏感checkbox completion matches phase numbers across zero-paddingROADMAP 写Phase 3、目录写03-threenext_phase 4comparePhaseNum去重生效an outstanding phase 3 (unchecked) is still selected — negative controlPhase 3 为[ ]next_phase 03未完成阶段仍是合法候选且磁盘拼写胜出其中第一例直接断言了 #4699 的实际危害——持久化污染STATE.md不得再携带已完成阶段作为current_phase。第五例作为阴性对照negative control确保修复没有过度收紧只要阶段 3 的复选框未勾选它依然是合法候选且输出沿用磁盘的零填充拼写03。六、适用前提与使用建议修复生效的前提是项目存在可解析的ROADMAP.md且阶段行使用复选框语法- [x] **Phase N: Name**或 heading 复选框组合。若 ROADMAP 缺失、不可读或仅有 heading 而无复选框roadmapCompleteNums集合为空行为退化为修复前的纯数值扫描fail-open 设计。若需在命令行查看修复后的行为可运行gsd phase complete N并检查 JSON 输出中的next_phase/next_phase_name/is_last_phase字段相关输出字段定义见 src/phase.cts 附近的completed_phase/next_phase/next_phase_name组装只读探查进度可运行gsd roadmap analyze或gsd init progress对比next_phase结果。阶段复选框是全局完成判据的唯一权威来源手工编辑 ROADMAP 勾选状态会影响phase complete、roadmap analyze、init progress三者的一致性请保持ROADMAP.md的复选框与阶段实际完成情况同步。七、小结#4699 是一次典型的一致性修复phase complete的 next-phase 选择长期只依赖数值次序忽略复选框完成状态导致乱序完成场景下STATE.md的current_phase被污染为已完成的阶段。修复在磁盘扫描与 ROADMAP 扫描两路同时引入roadmapCompleteNums完成集合过滤使next_phase与roadmap.analyze、init.progress在ROADMAP 顺序即前沿的规则下完全对齐并以 5 个回归测试锁定行为。这一修复同时印证了 GSD 的核心设计原则阶段目录只是执行痕迹ROADMAP 复选框才是进度真相。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐探索与研究阶段已完成探索与研究阶段已完成 我已经完整阅读了关联文档 packages/mermaid/src/docs/syntax/gitgraph.md https://lin图表库前端数据可视化gsd-core 修复解读3381 修复 —— /gsd-verify-work --ws 通过 SDK 解析工作流阶段gsd core 修复解读 3381 修复 —— /gsd verify work ws 通过 SDK 解析工作流阶段 本篇文章基于 .changeset/agsd-core 验证门禁修复human_needed 状态不再放行阶段完成与 Ship 预检gsd core 验证门禁修复human_needed 状态不再放行阶段完成与 Ship 预检 导读 本文基于 gsd core 仓库的变更记录 fix 3上一篇智慧树自动刷课神器Autovisor完整使用指南下一篇如何让经典Flash内容在现代电脑上重获新生CefFlashBrowser完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考