【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载/gsd:audit-milestone是 gsd-core 里程碑生命周期的审计编排命令orchestrator它在归档前读取各阶段在 execute-phase 中已生成的VERIFICATION.md聚合技术债与延期缺口再派出集成检查子代理核验跨阶段接线最终产出一份结构化审计报告v{version}-MILESTONE-AUDIT.md并依据审计结论引导你进入「完成里程碑 / 内联补缺口 / 偿还技术债」三条后续路径。读完本文你将掌握审计的完整执行流程与命令行用法、需求覆盖的三源交叉验证矩阵、Nyquist 合规发现、审计报告 YAML 结构与状态路由规则以及如何结合仓库源码工作流定义、子代理定义、回归测试验证每一步的落地行为。一、命令定位为什么里程碑需要一次独立审计在 gsd-core 的阶段循环中每个阶段由 execute-phase 执行、由 verify-phase 产出NN-VERIFICATION.md。但「每个阶段各自通过」不等于「整个里程碑达成了原始意图」——组件存在不等于被导入API 路由存在不等于有消费者。因此/gsd:audit-milestone承担三件核心校验DoDdefinition of done达成验证检查需求覆盖requirements coverage跨阶段集成检查核验阶段之间的接线cross-phase wiring与端到端流程技术债与延期缺口聚合把各阶段遗留的非关键缺口汇总成可行动的清单。命令定义见 commands/gsd/audit-milestone.md其 objective 明确写道Verify milestone achieved its definition of done. Check requirements coverage, cross-phase integration, and end-to-end flows. 命令允许的工具集为Read / Glob / Grep / Bash / Agent / Write并要求前置条件requires: [execute-phase]——即必须先完成阶段执行与验证审计才有内容可读。在 gsd-core 的功能需求docs/features/milestone-management.md中审计命令对应三条硬性需求REQ-MILE-01审计必须验证所有里程碑需求已满足REQ-MILE-02审计必须检测 stub、占位实现与未测试代码REQ-MILE-03审计必须检查各阶段的 Nyquist 验证合规性。审计通过后自然的下一个命令是/gsd:complete-milestone归档并打 git tag若存在缺口则在审计输出的指引下用/gsd:phase --insert N插入闭环节点。整条链路见 docs/how-to/verify-and-ship.md 的 Closing a milestone 一节。二、命令用法与参数/gsd:audit-milestone [version]参数可选arguments块为空时默认审计当前里程碑从ROADMAP.md检测版本参数生效方式命令通过init milestone-op初始化里程碑上下文解析出milestone_version、milestone_name、phase_count、completed_phases、commit_docs等字段工作区支持支持--ws name指定 workstreamgsd_run query init.milestone-op --wsname核心规划文件按需加载工作流内通过init milestone-op解析不预先读取整个规划目录。命令加载的执行上下文为 gsd-core/workflows/audit-milestone.md即完整的 7 步 5.5 步工作流并先读取 gsd-core/references/response-language-directive.md 作为语言指令。安装到用户目录后同一工作流文件也会被技能清单 skills/gsd-audit-milestone/SKILL.md 引用。三、执行流程从初始化到结果路由工作流把审计拆成 7 个显式步骤每一步都是可保留的 gatescope determination → verification reading → integration check → requirements coverage → routing。0. 初始化里程碑上下文工作流第一步先解析 gsd-tools 运行时gsd-tools.cjs的定位与身份校验含runtime-identity --raw包名白名单校验然后执行GSD_WS$(echo $ARGUMENTS | sed -nE s/.* --ws ([A-Za-z0-9][A-Za-z0-9._-]*).*/--ws \1/p | head -n 1) INIT$(gsd_run query init.milestone-op ${GSD_WS:--ws${GSD_WS##* }}) if [[ $INIT file:* ]]; then INIT$(cat ${INIT#file:}); fi AGENT_SKILLS_CHECKER$(gsd_run query agent-skills gsd-integration-checker ${GSD_WS:--ws${GSD_WS##* }})从initJSON 中提取milestone_version / milestone_name / phase_count / completed_phases / commit_docs再解析集成检查子代理的模型integration_checker_model$(gsd_run query resolve-model gsd-integration-checker --raw)1. 确定里程碑范围Scope Determinationgsd_run query phases.list从参数解析版本或在无参数时从ROADMAP.md检测当前里程碑识别范围内所有阶段目录数字排序支持小数版本号从ROADMAP.md提取里程碑的 DoD从REQUIREMENTS.md提取映射到本里程碑的需求。2. 读取所有阶段验证报告对每个阶段目录读取其VERIFICATION.md使用find-phase解析目录可处理已归档阶段PHASE_INFO$(gsd_run query find-phase 01 --raw)从每份VERIFICATION.md提取五类信息字段取值含义Statuspassed/gaps_found阶段验证结论Critical gaps—阻断性缺口blockerNon-critical gaps—技术债、延期项、警告Anti-patterns—TODO、stub、占位实现Requirements coverage—哪些需求满足 / 被阻断关键 gate若某个阶段缺失VERIFICATION.md标记为 unverified phase——这是阻断项blocker。3. 派出集成检查子代理从REQUIREMENTS.md的可追溯性表提取MILESTONE_REQ_IDS分配给本里程碑阶段的所有 REQ-ID然后派发gsd-integration-checker。派发前会打印提示Spawning integration checker (runs in a subagent — no output until it returns, ~1–5 min; expected, not a freeze)防止用户误以为卡死。派发调用省略了model时的规则见下Agent( promptCheck cross-phase integration and E2E flows. Phases: {phase_dirs} Phase exports: {from SUMMARYs} API routes: {routes created} Milestone Requirements: {MILESTONE_REQ_IDS — list each REQ-ID with description and assigned phase} MUST map each integration finding to affected requirement IDs where applicable. Verify cross-phase wiring and E2E user flows. ${AGENT_SKILLS_CHECKER}, subagent_typegsd-integration-checker, model{integration_model} )两条重要的运行时规则模型省略#2517当integration_checker_model为inherit或空值时完全省略model参数。空值在无原生 tier 别名的运行时非 Claude 运行时的默认情况会 404省略则继承编排者模型。详见 gsd-core/references/model-profile-resolution.md。运行时感知派发#2508 Phase 4在仅内置子代理的运行时如 kimi-code 只有三个内置角色先用gsd_run query resolve-dispatch-type --requested role --raw把角色解析为内置角色在具名派发运行时Claude/OpenCode 等角色原样返回。persona 始终由${AGENT_SKILLS_ROLE}携带。详见 gsd-core/references/runtime-aware-dispatch.md。编排者规则CODEX 运行时调用Agent()之后必须立即停止本任务的工作不得继续读文件、改代码或跑测试等待子代理返回。这是为了防止重复劳动、冲突编辑与上下文浪费。集成检查子代理的完整对抗式检查流程定义在 agents/gsd-integration-checker.md它采用FORCE 立场Assume every cross-phase connection is broken until a grep or trace proves the link exists end-to-end并按Exports → Imports、APIs → Consumers、Forms → Handlers、Data → Display四类连接逐项验证产出wiring / flows / Requirements Integration Map三类结构化结果。4. 汇总结果合并两路输入各阶段的缺口与技术债来自步骤 2集成检查器的报告接线缺口、断裂流程。5. 需求覆盖检查三源交叉验证这是审计的核心 gate要求对每个 REQ-ID交叉核对三个独立来源。5a. 解析 REQUIREMENTS.md 可追溯性表提取映射到本里程碑阶段的 REQ-IDID、描述、指派阶段、当前状态、[x]/[ ]勾选状态。5b. 解析各阶段 VERIFICATION.md 的需求表提取Requirement | Source Plan | Description | Status | Evidence并把每条映射回 REQ-ID。5c. 提取 SUMMARY.md frontmatter 交叉核对从每个阶段的*-SUMMARY.mdYAML frontmatter 提取requirements-completed。注意 shell 可移植性——#2962的注释指出 zsh 会在未匹配的 for-list glob 上中止块nomatchbash 则透传因此必须同时开启 nullglobshopt -s nullglob 2/dev/null; setopt NULL_GLOB 2/dev/null for summary in .planning/phases/*-*/*-SUMMARY.md; do [ -e $summary ] || continue gsd_run query summary-extract $summary --fields requirements_completed --pick requirements_completed done5d. 状态判定矩阵VERIFICATION.md StatusSUMMARY FrontmatterREQUIREMENTS.md→ 最终状态passedlisted[x]satisfiedpassedlisted[ ]satisfied更新复选框passedmissinganypartial人工复核gaps_foundanyanyunsatisfiedmissinglistedanypartial验证缺口missingmissinganyunsatisfied5e. FAIL Gate 与孤儿检测REQUIRED任何unsatisfied需求必须强制里程碑审计状态为gaps_found孤儿检测出现在 REQUIREMENTS.md 可追溯性表、但未出现在任何阶段 VERIFICATION.md中的需求标记为 orphaned按unsatisfied处理——它们被指派了却从未被任何阶段验证。5.5. Nyquist 合规发现条件执行Nyquist 能力未激活时跳过。激活时VERIFY_POST_HOOKS_JSON$(gsd_run loop render-hooks verify:post --raw)解析VERIFY_POST_HOOKS_JSON中kind step且ref.skill validate-phase的活动步骤钩子若不存在活动的 validate-phase 步骤钩子则整体跳过。对每个阶段目录检查*-VALIDATION.md解析 frontmatterstatus、nyquist_compliant、wave_0_complete分类条件COMPLIANTstatus: validated且nyquist_compliant: true且所有任务绿色PARTIALstatus: validated且nyquist_compliant: false或有红色/待处理项NOT-VALIDATEDstatus: draft或缺失——validate-phase 尚未调和该文件#2117MISSING无 VALIDATION.md关键区分#2117status: draft可能是「plan-phase 播种后 validate-phase 从未调和」也可能是「文件早于status字段引入#2117 之前写入的一律保持 draft」。两种情况都不是合规失败而是覆盖 TODOrun validate-phase。只有status: validatednyquist_compliant: false才是真正的 PARTIAL。审计只做发现discovery绝不自动调用/gsd:validate-phase。最终把nyquist: { compliant_phases, partial_phases, not_validated_phases, missing_phases, overall }追加进审计 YAML。6. 聚合生成 v{version}-MILESTONE-AUDIT.md创建.planning/v{version}-MILESTONE-AUDIT.mdYAML frontmatter 结构--- milestone: {version} audited: {timestamp} status: passed | gaps_found | tech_debt scores: requirements: N/M phases: N/M integration: N/M flows: N/M gaps: # Critical blockers requirements: - id: {REQ-ID} status: unsatisfied | partial | orphaned phase: {assigned phase} claimed_by_plans: [{plan files that reference this requirement}] completed_by_plans: [{plan files whose SUMMARY marks it complete}] verification_status: passed | gaps_found | missing | orphaned evidence: {specific evidence or lack thereof} integration: [...] flows: [...] tech_debt: # Non-critical, deferred - phase: 01-auth items: - TODO: add rate limiting - Warning: no password strength validation - phase: 03-dashboard items: - Deferred: mobile responsive layout ---frontmatter 之后是完整 Markdown 报告包含需求、阶段、集成、技术债四张表格。三种状态值状态判定passed所有需求满足、无关键缺口、技术债极少gaps_found存在关键阻断项tech_debt无阻断项但累积的延期项需要评审7. 展示结果按状态路由到三种输出模板之一见下文作为命令的最终回复直接输出非代码块。四、结果路由与后续行动状态一passed审计通过## ✓ Milestone {version} — Audit Passed **Score:** {N}/{M} requirements satisfied **Report:** .planning/v{version}-MILESTONE-AUDIT.md后续动作为归档打 tag/clear后运行/gsd:complete-milestone {version}。状态二gaps_found存在缺口输出 Unsatisfied Requirements、Cross-Phase Issues、Broken Flows、Nyquist Coverage 四张清单。缺口闭环节点在此内联插入——每个缺口或相关缺口组插入一个闭环节点使用标准阶段链/clear then: /gsd:phase --insert N Close gap: REQ-ID — description /gsd:discuss-phase N /gsd:plan-phase N /gsd:execute-phase N对 Nyquist 覆盖缺口优先对每个被标记阶段运行/gsd:validate-phase N若 SECURITY.md 被标记则加跑/gsd:secure-phase N——它们可能追溯性地关闭缺口而不需要新阶段。其他可用项cat .planning/v{version}-MILESTONE-AUDIT.md查看完整报告/gsd:complete-milestone {version}接受技术债继续推进。状态三tech_debt无阻断但有累积债务## ⚡ Milestone {version} — Tech Debt Review提供两个选项A. 接受债务/gsd:complete-milestone {version}债务转入 backlog 跟踪B. 规划清理阶段同样插入闭环节点——/gsd:phase --insert N Address tech debt: area后接标准阶段链。五、成功标准success criteria工作流末尾以清单形式给出审计完成的定义这也是命令自检与测试的依据里程碑范围已识别所有阶段VERIFICATION.md已读取每个阶段SUMMARY.md的requirements-completedfrontmatter 已提取REQUIREMENTS.md可追溯性表已解析全部里程碑 REQ-ID三源交叉验证完成VERIFICATION SUMMARY traceability孤儿需求已检测在可追溯性表中但不在任何 VERIFICATION 中技术债与延期缺口已聚合集成检查器已携带里程碑需求 ID 派出v{version}-MILESTONE-AUDIT.md已创建并含结构化需求缺口对象FAIL gate 已强制——任何 unsatisfied 需求迫使状态为 gaps_found若启用已扫描全部里程碑阶段的 Nyquist 合规性缺失VALIDATION.md的阶段已标记 validate-phase 建议结果已携带可行动的下一步展示。六、源码级佐证审计报告文件名契约审计工作流的输出文件名并非随意约定而是有专门回归测试锁定的契约。tests/audit-milestone-filename-guard.test.cjs 针对 issue #3796 编写当时写入端创建了.planning/v{version}-v{version}-MILESTONE-AUDIT.md版本段重复而步骤标题、报告指针、cat命令、完成清单等所有下游读取方读的都是v{version}-MILESTONE-AUDIT.md导致报告落在任何读者都不会查看的路径。测试直接对 gsd-core/workflows/audit-milestone.md 做字节级结构扫描the bytes ARE what the runtime loadsassert.ok(!md.includes(v{version}-v{version}), no doubled version segment); assert.ok(writer.test(md), writer must create exactly .planning/v{version}-MILESTONE-AUDIT.md); const readers md.match(/v\{version\}-MILESTONE-AUDIT\.md/g) || []; assert.ok(readers.length 5, single-version readers must remain);这体现了该仓库的工程惯例工作流文本即契约读取端与写入端必须一致——你在自定义或迁移该工作流时务必保持文件名单版本段否则审计报告将无人能读到。七、与相邻命令的关系命令角色/gsd:execute-phase前置条件产生 SUMMARY.md 与 VERIFICATION.md/gsd:verify-work单阶段 UAT 验证审计读取其产出/gsd:validate-phaseNyquist 校验审计只发现不触发/gsd:complete-milestone审计 passed / 接受债务后归档打 tag/gsd:phase --insert Ngaps_found / tech_debt 时插入闭环节点完整命令清单见 docs/COMMANDS.md规划工件SUMMARY.md、VERIFICATION.md、VALIDATION.md的字段规格见 docs/reference/planning-artifacts.md。小结/gsd:audit-milestone把「里程碑是否真的完成」这个模糊问题转化为一个可重复、可测试、可路由的审计管线三源交叉验证需求覆盖、对抗式子代理核验跨阶段接线、条件性扫描 Nyquist 合规最后以结构化报告和三条行动路径收尾。理解其工作流gsd-core/workflows/audit-milestone.md、子代理立场agents/gsd-integration-checker.md与文件名契约tests/audit-milestone-filename-guard.test.cjs你就能在归档前把住最后一道质量闸门。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐gsd-core 跨阶段集成审计gsd-integration-checker 如何验证阶段真的连上了gsd core 跨阶段集成审计gsd integration checker 如何验证阶段真的连上了 GSD CoreGit. Ship. Donegsd-core 里程碑完成与归档实战从 /gsd:complete-milestone 到 git tag 的完整流程与源码解析gsd core 里程碑完成与归档实战从 /gsd:complete milestone 到 git tag 的完整流程与源码解析 本文以 gsd coreGSD-Core 修复 total_phases 误计非阶段章节标题不再污染里程碑阶段计数GSD Core 修复 total_phases 误计非阶段章节标题不再污染里程碑阶段计数 本篇文章聚焦 GSD Core 中一个极具代表性的计数一致性修复上一篇突破海外镜像壁垒DaoCloud公开镜像仓库新增Planka项目镜像支持的技术解析下一篇3行代码修复HashMap哈希冲突从理论到实战的性能优化指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考