【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载导读本篇文章聚焦 gsd-core 中 TDD 模式下的RED 提交门控RED-commit gate修复——该修复PR #4715issue #4379解决了 Go、Ruby、Elixir、Python 项目中每个行为添加任务都会误触发TDD GATE TRIPPED: missing RED commit的问题同时补上了仓库根目录测试文件不可见的缺陷。读完本文你将掌握TDD 门控在 gsd-core 中的运行机制、RED 提交 pathspec 的精确构成与设计权衡、各语言测试约定如何被识别、以及 Rust 场景为何被明确记录为已知缺口。一、问题背景JS/TS 单一约定的 RED 门控如何拖垮多语言项目在 gsd-core 的 TDD 流水线模式中workflow.tdd_mode配置开启后默认false见 docs/CONFIGURATION.md执行器会对所有type: tdd计划强制施加 RED → GREEN → REFACTOR 门序列。其中 RED 门要求任何行为添加behavior-adding任务在实现代码提交之前必须存在一条先行提交的失败测试提交。修复前的 RED 门控存在两个致命缺陷见 tests/safe-resume-gate-anchoring.test.cjs 的复现描述路径限定只认识*.test.*、*.spec.*和tests/这些约定覆盖的是 JS/TS 及其同构生态。对于 Go 项目一个提交如果只添加了foo_test.gogit pathspec 根本匹配不到门控视为没有 RED 提交于是每个行为添加任务都会以TDD GATE TRIPPED: missing RED commit硬性中止。**/前缀不匹配根目录路径即使是在原本就支持的 JS/TS 中位于仓库根目录的foo.test.js也会因为**/通配符不匹配无目录层级的路径而不可见——这是 issue #4379 中未被报告的另一半问题见测试第 203-211 行。而这一切发生的背景更令人困惑gsd-core 的 TDD 参考文档 gsd-core/references/tdd.md 一直宣传go test ./...、pytest、cargo test等语言均受支持门控却只能看见 JS/TS 约定——文档契约与运行时行为出现了严重漂移。二、修复方案#4379 的跨语言 pathspec 重构修复的核心思路实现在 gsd-core/workflows/execute-phase.md 的RED_COMMIT探测命令中是将 pathspec 从窄到只认识 JS/TS改为宽到覆盖所有主流语言约定同时绝不扩大到普通源码。修复后的 pathspec 由下列裸 glob 组成裸 glob 在 git 中匹配任意深度天然覆盖根目录约定模式覆盖语言/生态说明*.test.*JS/TS 及共享该约定的生态源码旁放置的测试文件如foo.test.js*.spec.*JS/TS 及共享该约定的生态如foo.spec.tstests/通用目录约定仓库根目录的tests/目录__tests__/JS 生态Jest 等专门的测试目录*_test.goGoGo 标准测试命名如foo_test.go、pkg/bar_test.gotest_*.py/*_test.pyPython在tests/之外也识别 pytest 风格的前缀/后缀命名*_test.exsElixirExUnit 约定*_spec.rb/*_test.rbRubyRSpec 与 Minitest 约定完整命令保留注释中的设计决策RED_COMMIT$(git log --oneline -E ${TDD_MILESTONE_BASE:$TDD_MILESTONE_BASE..HEAD} \ --grep${PLAN_SCOPE_RE} \ -- *.test.* *.spec.* tests/ __tests__/ *_test.go test_*.py *_test.py *_test.exs *_spec.rb *_test.rb \ | head -1)需要注意pathspec 本身就是该门控对什么是测试文件的定义。测试 tests/safe-resume-gate-anchoring.test.cjs 特意从已发布的工作流文件中提取真实 pathspec 来驱动测试而不是在测试里重写一份副本——确保被测试的是真正上线的东西而非与其平行的字符串拷贝。三、源码级验证测试如何证明修复有效tests/safe-resume-gate-anchoring.test.cjs 的#4379 — the TDD RED pathspec is language-agnostic描述块第 151-236 行用真实的临时 git 仓库执行验证四个用例分别钉住所有约定可见第 191-201 行种子仓库一次性提交foo_test.go、pkg/bar_test.go、test_mod.py、mod_test.py、lib_spec.rb、x_test.exs断言全部满足 RED 探测器。根目录不再不可见第 203-211 行root.test.js与根级foo_test.go必须命中——这正是旧 pathspec**/前缀的盲区。既有 JS/TS 约定无回归第 213-219 行src/a.test.ts、tests/c.py、__tests__/d.js在拓宽后依然命中。实现文件永不匹配第 221-235 行src/impl.go、src/lib.rs必须不命中——这是门控仍然有能力触发的前提。src/lib.rs不命中直接导向 Rust 缺口的必然性见下文。四、设计权衡为什么接受*.spec.*的误报而不收窄拓宽 pathspec 并非没有代价。*.spec.*可能匹配到恰好含 spec 字样的非测试文件——例如api.spec.json、openapi.spec.yaml——这意味着一个只改动此类文件的提交也能让 RED 门通过。gsd-core 在 gsd-core/references/tdd.md 明确记录了这一取舍这不是新问题旧的**/*.spec.*已经会在任意嵌套路径匹配这些文件去掉**/前缀只是把同一类误报扩展到仓库根目录选择接受而非收窄因为收窄是对当前已支持用例的行为变更且不属于让其他语言可见这个修复目标的一部分。与之相对Rust 是被有意排除的。#[test]在 Rust 中通常与实现同处src/*.rs文件内一个 Rust RED 提交触碰的只有普通源码任何基于路径的门控都无法将其与普通源码区分。如果为了覆盖 Rust 而把 pathspec 扩大到*.rs就等价于匹配所有源码门控将失去意义参考 gsd-core/references/tdd.md 与测试第 221-235 行的关联论证。因此在 Rust 项目中使用workflow.tdd_mode时RED提交门控仍会触发——cargo test本身完全可用受限于的只是基于路径的提交级门控这是被记录在案而非试图修复的缺口。五、门控运行机制从 TDD_MODE 到 RED_COMMIT 的完整链路5.1 门控的激活条件门控内联于执行阶段的每个实现步骤之前gsd-core/workflows/execute-phase.md。自 #4011 起门控仅以TDD_MODE为准不再与产品级MVP_MODE耦合——旧逻辑把纪律门控绑在非 MVP 阶段上会导致其在所有非 MVP 阶段静默失效违背了workflow.tdd_mode对所有type: tdd计划生效的契约。MVP 模式可以隐含 TDD但 TDD 不再要求 MVP。完整激活链参考 gsd-core/references/execute-mvp-tdd.mdTDD_MODE解析为true优先级--tddCLI 标志 →workflow.tdd_mode配置当前任务的taskfrontmatter 中tddtrue任务的behavior块至少列出一条预期行为。三者任一为假门控即不激活执行正常进行。5.2 行为添加任务的精确定义一个任务被视为行为添加需要同时满足gsd-core/references/execute-mvp-tdd.mdfrontmatter 中tddtruebehavior块至少命名一个用户可见的结果排除纯配置/纯文档任务files列表至少包含一个源文件排除仅含*.md、*.json、*.test.*、*.spec.*、*.yml、*.yaml、*.toml、*.ini、.env*等的任务。纯文档、纯配置或纯测试任务即使两个模式都开启也会被门控跳过。5.3 门控探测与触发if [ $TDD_MODE true ]; then IS_BEHAVIOR_ADDING$(gsd_run query task.is-behavior-adding $TASK_FILE --pick is_behavior_adding) if [ $IS_BEHAVIOR_ADDING true ]; then # #4003同一锚定作用域与里程碑边界零填充字面量 grep 会在正确的非填充 RED 提交上硬性中止 # #4619PHASE_NUMBER 可为小数/N 段仅对前导整数段去零 # #4748PHASE_NUMBER 可带字母后缀03A在第一个非数字处切分 PHASE_INT${PHASE_NUMBER%%[!0-9]*}; PHASE_REST${PHASE_NUMBER#$PHASE_INT} PHASE_N$((10#$PHASE_INT))${PHASE_REST//./\\.} PLAN_N$((10#${PLAN_ID})) PLAN_SCOPE_RE^[a-z]\((0*${PHASE_N})-(0*${PLAN_N})\): TDD_MILESTONE_BASE$(git describe --tags --abbrev0 2/dev/null || echo ) RED_COMMIT$(git log --oneline -E ${TDD_MILESTONE_BASE:$TDD_MILESTONE_BASE..HEAD} \ --grep${PLAN_SCOPE_RE} \ -- *.test.* *.spec.* tests/ __tests__/ *_test.go test_*.py *_test.py *_test.exs *_spec.rb *_test.rb \ | head -1) if [ -z $RED_COMMIT ]; then gsd_run query state.update last_gate_trip ${PLAN_ID}/${TASK_ID} || true echo TDD GATE TRIPPED: missing RED commit for ${PLAN_ID}/${TASK_ID} exit 1 fi fi fi门控的提交搜索遵循与safe_resume_gate相同的纪律锚定作用域正则^[a-z]\((0*${PHASE_N})-(0*${PLAN_N})\):只匹配提交作用域位置上的test(phase-plan):形式正文中提及相同编号的提交不会被误命中由 tests/safe-resume-gate-anchoring.test.cjs 的行为测试覆盖里程碑边界git describe --tags --abbrev0得到的最近可达标签作为基线防止更早里程碑中同作用域的旧提交冒充当前计划的 RED 提交零填充容忍提交协议承诺不填充零#4003因此PHASE_N/PLAN_N会先做零剥离再以可容忍0*的 ERE 匹配——填充的字面量 grep 会在正确的非填充提交上硬性中止。5.4 触发后的行为门控触发时执行器必须在运行任务的实现步骤之前中止gsd-core/references/execute-mvp-tdd.md输出结构化中止报告### TDD GATE TRIPPED — Plan {plan_id}, Task {task_id}将last_gate_trip状态写入state.update供后续排障引用。六、RED 证据校验check tdd-red-evidence与 INVALID_RED修复 pathspec 只是让 RED提交可见而提交里的测试是否真正地、故意地失败则由 RED证据校验把关issue #3770 引入。执行器在 RED 阶段运行测试命令后持久化证据记录命令、退出码、失败测试、预期结果、实际结果并校验gsd_run check tdd-red-evidence record.json --raw核心实现位于 src/tdd-red-evidence.cts分类逻辑classifyRedEvidence第 172-258 行严格 fail-closed判定reason含义RED_EVIDENCE_OKtarget_test_failed目标测试以真实断言失败——唯一授权进入 GREEN 的判定INVALID_REDunexpected_greenRED 阶段退出码为 0功能可能已存在或测试写错INVALID_REDzero_tests_discovered发现模式/固件未匹配到任何测试运行未执行任何内容INVALID_REDnonzero_exit_without_test_failure非零退出但报告无失败测试harness/解析器崩溃INVALID_REDfixture_or_load_failure所有失败条目都以目标文件命名加载期崩溃如 throw-on-require、语法错误、ENOENTINVALID_REDno_target_test_failure真实测试运行且失败但失败的不是计划指定的目标测试INVALID_REDinvalid_record/unreadable_record记录缺失或不可读值得注意的是#4724check tdd-red-evidence还支持 Maven Surefire/Failsafe 的 XML 摘要解析采用标签边界扫描而非惰性正则避免通过用例自闭合testcase /标签吞掉中间所有用例的经典陷阱且 CDATA 内容如System.out回显不会被误扫为失败标签src/tdd-red-evidence.cts。提交消息中的RED:前缀或(RED)标签本身不构成充分证据——只有check tdd-red-evidence返回RED_EVIDENCE_OK才能放行。七、变更影响与使用建议7.1 对现有工作流的影响Go / Ruby / Elixir / Python 项目行为添加任务不再因foo_test.go、*_spec.rb、*_test.exs、test_*.py不可见而误触发门控——这是本次修复的核心收益根目录测试文件root.test.js、根级*_test.go等位于仓库根的文件重新可见JS/TS 既有约定*.test.*、*.spec.*、tests/、__tests__/全部保持命中无回归Rust 项目行为不变RED 提交门控仍会触发已知缺口见下。7.2 落地建议多语言仓库优先使用本修复后的默认 pathspec它比 gsd-core/references/tdd.md 的框架检测步骤枚举的项目类型更宽——识别一个 onboarding 流程尚未自动检测的约定成本为零而使用了该约定的项目的 RED 提交不应被漏看Rust 项目启用workflow.tdd_mode前需预期门控触发cargo test正常可用但#[test]内嵌实现文件路径门控无法区分可将其视为记录在案的约束而非缺陷理解*.spec.*的误报面api.spec.json之类的文件会让 RED 门通过纯规范文件提交这是有意的取舍与旧行为同类的既有误报的根目录延伸不应在未评估行为变更的情况下擅自收窄门控纪律不因 pathspec 变宽而放松pathspec 只负责提交可见测试是否真的失败仍由check tdd-red-evidence的RED_EVIDENCE_OK判定把关。八、延伸阅读TDD 计划结构与执行周期gsd-core/references/tdd.md门控运行时规范中止报告格式gsd-core/references/execute-mvp-tdd.md执行阶段工作流门控内联位置gsd-core/workflows/execute-phase.mdRED 证据分类实现src/tdd-red-evidence.cts跨语言 pathspec 的回归测试tests/safe-resume-gate-anchoring.test.cjsTDD 流水线模式需求与配置docs/features/tdd-pipeline-mode.md、docs/CONFIGURATION.md赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐gsd-core 的 TDD Audit用 gate-status 提交尾注把逐提交 TDD 门禁足迹带进 PR Body 与 squash-mergegsd core 的 TDD Audit用 gate status 提交尾注把逐提交 TDD 门禁足迹带进 PR Body 与 squash merge /ggsd-core 修复gap-analysis 现在正确识别 padded-prefix 约定的 CONTEXT.md 决策文件gsd core 修复gap analysis 现在正确识别 padded prefix 约定的 CONTEXT.md 决策文件 导读 本文围绕 gsd cogsd-core 嵌套 Git 仓库检测修复解析/gsd-new-project 与 /gsd-ingest-docs 如何通过 git rev-parse 语义避免误建 .gitgsd core 嵌套 Git 仓库检测修复解析 /gsd new project 与 /gsd ingest docs 如何通过 git rev parse上一篇Android列表动画进阶UltimateRecyclerView自定义动画下一篇Maltrail学术论文引用在网络安全研究中的应用案例创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考