【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本篇技术指南围绕 GSD CoreGit. Ship. Done - Core的里程碑完成/gsd:complete-milestone自动化能力深入讲解新增配置项git.create_tag它用于控制 GSD 是否在里程碑完成时自动创建git tag -a v[X.Y]发布标签。阅读完本文你将掌握该配置的默认行为、两种设置方式/gsd:settings与gsd config-set、其底层解析与门控实现原理以及如何为自带发布流程的项目关闭自动打 Tag、避免重跑里程碑关闭时因 Tag 冲突而静默失败。一、功能背景为什么需要可关闭的里程碑 Tag在 GSD Core 的规划流程中每个里程碑milestone完成时工作流默认会执行一次发布打标操作对仓库创建形如v1.0、v1.1、v2.0的注解式 Git 标签annotated tag作为版本发布的历史记录点。这一步对大多数项目是合理的默认行为但对于已有独立发布/Release 自动化流程例如 CI/CD 平台自动打 Tag、npm/pypi 发布流程自带版本标记的项目GSD 再创建一个本地 Tag 反而会造成重复或干扰。为此GSD Core 引入了布尔配置项git.create_tag默认true保持向后兼容让这类项目可以显式关闭 GSD 在里程碑完成时自动执行git tag -a v[X.Y]的行为同时新增 Tag 冲突预检防止在重跑里程碑关闭时因 Tag 已存在而静默失败对应 PR #3508配套测试与文档落地于 #3086、#2994 等系列改动。二、配置项速览配置键类型默认值作用git.create_tagbooleantrue控制里程碑完成时是否自动创建 git tagv[X.Y]。设为false后GSD 跳过 Tag 创建但仍然执行里程碑归档、状态更新等其余步骤默认值来源三处一致该默认值在仓库中由多处共同维护保证“缺省即true”这一向后兼容语义配置 Schema 默认表 src/config.cts#L106-L113SCHEMA_DEFAULTS中注册git.create_tag: true当config-get查询时键缺失也返回true而非 “Key not found”配置对象内置默认 src/config.cts#L361-L367git分组下硬编码create_tag: true项目配置模板 gsd-core/templates/config.json#L32-L34新项目初始化时写入git: { create_tag: true }。在文档侧docs/CONFIGURATION.md#L1264 的配置参考表中亦有对应描述git.create_tagboolean默认true——在里程碑完成时创建 git tagv[X.Y]自带发布流程的项目可设为false。三、两种设置方式与验证配置存放在项目级文件.planning/config.json项目的规划配置中。设置git.create_tag有两种方式方式一通过/gsd:settings交互命令在支持 GSD 的 AI 编程环境中直接运行/gsd:settings在设置界面中定位git.create_tag并切换为关闭。该命令会回写项目配置文件适合不想记忆 CLI 参数的使用者。相关设置流程可参考 gsd-core/workflows/settings.md。方式二通过gsd config-set命令行在仓库根目录执行gsd为 GSD Core 的 CLI 入口# 关闭里程碑自动打 Tag gsd config-set git.create_tag false # 重新开启默认值 gsd config-set git.create_tag true校验是否生效gsd config-get git.create_tag # 关闭后输出false # 默认/开启时输出true取值约束git.create_tag只接受布尔值。配置校验器在 src/config.cts#L958-L963 中对git.create_tag做了专门校验对应 Issue #3086传入非布尔值如字符串maybe会直接报错Invalid git.create_tag maybe. Must be a boolean (true or false).四、底层原理fail-open 解析与 config-gate 提升从源码结构看git.create_tag的解析经历了两次演进演进前#2994 之前工作流文件complete-milestone.md的git_tag步骤顶部内嵌了一个config-check子标签内部通过 shell 兜底解析gsd-tools.cjs query config-get git.create_tag 2/dev/null || echo true即以“查询失败也输出true”的方式实现 fail-open缺失即创建 Tag。但这样做的缺陷是步骤自身的开关由该步骤自己计算的同一个事实来决定职责耦合在流程文档里难以被测试与复用。演进后#2994解析被提升hoist到源码层职责分离解析函数detectGitCreateTagsrc/init.cts#L665-L678读取项目配置function detectGitCreateTag(cwd: string): boolean { return readConfigJsonValue(cwd, [git, create_tag]) ! false; }注意这里的判定是! false而不是 true这正是 fail-open 语义的代码化只要键缺失或未设置为字面量false结果就是“创建 Tag”与旧 shell 兜底|| echo true的行为完全一致。源码注释明确说明这是刻意与 fail-closed 默认值相反的极性对照detectFallowConfig。专用 init 入口cmdInitCompleteMilestonesrc/init.cts#L3329-L3408把该事实作为git_create_tag字段输出并同时输出section_manifest——它不再携带任何阶段列举逻辑唯一职责就是为git_tag步骤提供配置门控事实。这一提升保证了“配置事实”与“工作流消费事实”同源且可以被 CLI 直接查询与测试见第六节。五、工作流门控section 机制与 Tag 冲突预检5.1 用 gsd:section 门控整个 git-tag 步骤在 gsd-core/workflows/complete-milestone.md#L633-L635git_tag步骤不再内嵌config-check而是被一个节标记包裹!-- gsd:section idgit-tag whenstate:git-create-tag --其语义为当section_manifest为null未启用分段或git-tag位于其included列表时读取并执行gsd-core/workflows/complete-milestone/steps/git-tag.md否则跳过整个步骤文件直接进入git_commit_milestone。也就是说关闭git.create_tag后工作流会连git-tag步骤文件都不再读取从而保证“禁用 Tag 创建不会跳过里程碑归档”对应需求 REQ-MILESTONE-TAG-03。工作流成功标准清单也同步标注了该条件性gsd-core/workflows/complete-milestone.md#L722 中“Git tag created (v[X.Y])”一项注明(if git.create_tag enabled)。5.2 git-tag 步骤本身冲突预检与注解式 Taggsd-core/workflows/complete-milestone/steps/git-tag.md 中的git_tag步骤是实际打 Tag 的执行体。它首先进行Tag 冲突预检对应需求 REQ-MILESTONE-TAG-02防止重跑里程碑关闭时静默失败# Pre-check: skip if tag already exists (prevents silent failure on retry) if git rev-parse v[X.Y] /dev/null 21; then echo Tag v[X.Y] already exists, skipping; exit 0; fi git tag -a v[X.Y] -m v[X.Y] [Name] Delivered: [One sentence] Key accomplishments: - [Item 1] - [Item 2] - [Item 3] See .planning/MILESTONES.md for full details.随后确认输出Tagged: v[X.Y]并询问用户是否推送远端git push origin v[X.Y]此前#3508 之前若 Tag 已存在git tag -a会直接报fatal: tag v[X.Y] already exists而工作流不一定能把这次失败显式呈现给用户——这正是“静默失败”场景。引入预检后重跑里程碑关闭会明确打印Tag v[X.Y] already exists, skipping并干净退出。六、验证与测试行为如何被锁定该功能的回归测试位于 tests/config.test.cjs#L2113-L2222对应 Issue #3086覆盖四个维度用例验证内容A全新项目执行config-get git.create_tag返回默认值true向后兼容Bconfig-set git.create_tag false后config-get返回falseC非法取值如maybe被 Schema 校验器拒绝命令失败D工作流complete-milestone.md必须包含gsd:section idgit-tag whenstate:git-create-tag门控标记且指向steps/git-tag.md步骤文件必须含step namegit_tag与git tag -a打标逻辑D2行为级验证detectGitCreateTag分别设false/true后运行init complete-milestone其输出字段git_create_tag必须随之翻转其中 D2 用例#3508 引入刻意不读取init.cts源码文本而是通过真实 CLI 驱动配置键两种取值来观察init complete-milestone的git_create_tag输出字段从而证明解析函数确实绑定的是git.create_tag这一配置键本身。同时 tests/resolver-hoist-guard.test.cjs#L83 还记录了state:git-create-tag与git.create_tag之间的映射关系防止解析器被意外改动。七、行为约束与边界情况综合 docs/features/milestone-tag-creation-toggle.mdFeature id 141与上述源码git.create_tag的行为约束可归纳为三条需求REQ-MILESTONE-TAG-01配置缺失必须保持默认行为。未配置或键缺失等价于truefail-open老项目升级后行为不变REQ-MILESTONE-TAG-02已存在的 Tag 冲突必须显式失败而非覆盖。通过git rev-parse预检提前发现冲突并明确跳过REQ-MILESTONE-TAG-03关闭 Tag 创建不得跳过里程碑归档。归档milestones/v[X.Y]-ROADMAP.md、milestones/v[X.Y]-REQUIREMENTS.md、MILESTONES.md 条目、STATE.md 更新等由milestone.completeCLI 负责与git-tag步骤相互独立关闭打 Tag 只影响 Tag 这一项。典型使用场景自带 Release 自动化CI/CD 已接管打 Tag 与发布将git.create_tag设为false避免本地产生多余的注解 Tag 与远端推送重复多工作流共享仓库不希望每个子项目/工作流的里程碑关闭都创建全局 Tag 时按项目关闭该能力重跑里程碑关闭启用预检后重复执行/gsd:complete-milestone遇到已存在的v[X.Y]会得到明确的 skip 提示而非底层 git 报错。需要注意该配置作用域是项目级.planning/config.json影响的是当前项目内所有里程碑完成操作关闭后 GSD 不再询问“Push tag to remote?”但其余归档、审计、回顾、分支处理等步骤照常执行。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐gsd-core 里程碑归档目录解析修复getActiveMilestoneArchiveDir 的 null 语义与 W007 误报消除gsd core 里程碑归档目录解析修复getActiveMilestoneArchiveDir 的 null 语义与 W007 误报消除 本文聚焦 gsdgsd-core 里程碑进度修复body-only 更新不再重建 progress 块percent 取 plan/phase 分数较小值gsd core 里程碑进度修复body only 更新不再重建 progress 块percent 取 plan/phase 分数较小值 本指南讲解 gsApache Arrow发展历程深度解析10个关键里程碑节点Apache Arrow发展历程深度解析10个关键里程碑节点 Apache Arrow 是一个多语言工具集专为加速数据交换和内存处理而设计已成为现代数据处数据工程数据分析大数据上一篇gpt-oss MCP Server 实践指南把 Python 执行与浏览器检索工具接入 MCP 并自动构造 Harmony 系统提示词下一篇探索未来AI艺术创作新境界 —— Denoising Diffusion Policy Optimization深度解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
