【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本文基于 GSD Core 仓库归档的 changeset.changeset/archived/sunny-ibex-wave.md展开讲解gsd-intel-updater代码情报代理如何通过「正向框架仓库门控」移除在普通用户项目上的无用布局检测输出并深入其实现、回归测试与周边 intel 子系统。读完你不仅能复述这次变更还能掌握 GSD Core 中「框架仓库专用逻辑必须显式门控」的工程范式以及gsd-tools intel子命令的完整工作流。变更概览一条 Removed 类型的归档变更记录归档文件 .changeset/archived/sunny-ibex-wave.md 的 frontmatter 只有两个字段--- type: Removed pr: 3299 ---正文是一句精确的变更描述原文语义gsd-intel-updater不再在非 GSD 框架项目上输出一条残留的 Layout detection returned unknown 提示—— 布局检测的 bash 块现在被一个正向的框架仓库检查门控package.json的 name 字段匹配框架包名普通用户项目会静默跳过该步骤。这属于仓库 changeset 体系中的Removed类型它不是新增功能而是删除一段多余行为。归档目录意味着该变更已经合入并被移出待发布队列它描述的是一个已经生效的修复。问题本质一段死代码但会发声的 bash 块要理解这次修复需要先还原修复前的行为。根据回归测试 tests/intel.test.cjs 中的注释该测试由tests/bug-3290-intel-updater-layout-block.test.cjs折叠而来对应 consolidation epic #1969gsd-intel-updater.md中的 Runtime layout detection 块此前在每个被分析的项目上无条件执行它会在普通用户项目上打印Layout detection returned unknown — this project is not a GSD-system installation (no .claude/gsd-core/ or .kilo/ runtime root).问题在于这个判定结果在非 GSD 项目上根本不会被后续的 Step 2–6 使用。布局检测的唯一目的是当被分析的项目正是 GSD 框架仓库自身时检测运行时根目录.kilo/或.claude/gsd-core/从而在标准布局与.kilo布局之间选择规范路径。对普通用户项目而言该块是死代码verdict 无人消费但它会产生噪音输出vestigial line污染每次代码情报更新的日志。测试注释里把这种状态精确定义为dead-but-noisy死了但还在吵并给出了两种可接受的修复方向方案 A门控用框架仓库检查包裹检测块使其只在分析 GSD 框架仓库自身时运行方案 B删除若确认没有任何下游消费者则直接删除整个块。修复落地正向框架仓库门控Option A当前仓库采用方案 A。在 agents/gsd-intel-updater.md 的 Project Scope 一节布局检测块被一条 HTML 注释和一个if门控包裹# Only run layout detection when analysing the GSD framework repo itself. if [[ $(jq -r .name // package.json 2/dev/null) opengsd/gsd-core ]]; then ls -d .kilo 2/dev/null echo kilo || (ls -d .claude/gsd-core 2/dev/null echo claude) || echo unknown fi门控逻辑拆解组成含义jq -r .name // package.json从package.json提取包名缺省时回退为空字符串避免 jq 报错中断脚本2/dev/null静默吞掉 jq 不存在或 package.json 缺失时的错误 opengsd/gsd-core正向信号仅当包名恰好等于框架包名时才继续ls -d .kilo echo kilo检测.kilo运行时根目录优先级最高(ls -d .claude/gsd-core echo claude)回退检测标准.claude运行时根目录|| echo unknown兜底输出但在门控内发生不会污染普通项目值得注意的是归档 changeset 中描述的包名是get-shit-done-cc而当前源码门控值是opengsd/gsd-core。这并不矛盾——根据 docs/RELEASE-NOTES-LEGACY.mdget-shit-done-cc以及后来的opengsd/get-shit-done-redux是项目更名前的旧包名当前 package.json 中name: opengsd/gsd-core。即门控始终检查当前包名是否为框架本身只是包名随项目演进更新了。这正是正向门控设计的关键——它锚定身份标识而不是枚举非框架的否定条件。布局检测的适用边界只有框架仓库自身需要门控之上代理文档用一句注释明确了适用边界agents/gsd-intel-updater.mdLayout detection: only meaningful when analysing the GSD frameworks own repo (#3290).当被分析项目是GSD 框架仓库时检测到的运行时根目录决定所有规范路径的解析布局差异如下表Source typeStandard.claudelayout.kilolayoutAgent filesagents/*.md.kilo/agents/*.mdCommand filescommands/gsd/*.md.kilo/command/*.mdCLI toolinggsd-core/bin/.kilo/gsd-core/bin/Workflow filesgsd-core/workflows/.kilo/gsd-core/workflows/Reference docsgsd-core/references/.kilo/gsd-core/references/Hook fileshooks/*.js.kilo/hooks/*.js文档同时强调检测到.kilo根后只能用.kilo布局路径不要回退标准布局路径——否则统计组件数量stack.json、arch-decisions.json中的 counts时会拿到空目录产出语义为空的情报。这解释了为什么布局检测必须在门控内运行它在普通项目上没有任何正确路径可选提前静默跳过是唯一合理行为。回归测试两组契约守卫修复不被回退修复伴随的回归测试被折叠进 tests/intel.test.cjs分为两组恰好对应问题的两个侧面Group A —— 门控契约断言裸的无条件检测调用不存在。测试用正则定位缺陷签名const bareDetectionPattern /ls -d \.kilo\b.*\|\|.*echo ?unknown?/;若该签名仍存在说明块没被删则继续断言必须存在框架门控信号opengsd/gsd-core、Only run、framework repo等任一命中。两种合法状态——块被完全删除或块被门控包裹——都能通过测试。Group B —— 无孤儿消费者递归扫描agents/、commands/gsd/、gsd-core/workflows/三个目录下的所有 Markdown断言没有任何文件包含噪音短语Layout detection returned除生产者gsd-intel-updater.md自身外没有任何代理或工作流指令去读取unknown/claude/kilo判定结果。Group B 的存在很有工程意义它验证了这个 verdict 没有下游消费者从而证明方案 A 的门控而非保留一个仍被引用的输出是正确选择。测试注释还给出了明确指引如果将来出现消费者就采用 Option A门控而不是 Option B删除。周边上下文intel 子系统与代理工作流gsd-intel-updater不是孤立脚本它处于 GSD 的 intel代码情报子系统内。这次静默化改动可以放在这个更大的上下文中理解能力注册capabilities/intel/capability.json 将 intel 描述为供代码库查询、diff、快照与 API 面提取的情报存储暴露gsd-tools intel子命令query、status、update、diff、snapshot、patch-meta、validate、extract-exports、api-surface并支撑/gsd-map-codebase命令与gsd-intel-updater代理。激活门控该能力由intel.enabled配置键激活activationKey字段与gsd-intel-updater代理文档中 Config Gate 一节呼应——/gsd:map-codebase --query已确认intel.enabled为 true 才派发该代理。三态解析src/intel.cts 实现了一个三态解析器installed surfaced intel.enabled配置键未激活时返回 Intel system disabled. Set intel.enabledtrue in config.json to activate.这揭示了 GSD Core 的一贯风格每个可能只对特定环境有意义的行为都必须有显式的正向门控——框架仓库布局检测如此intel 能力激活如此运行时身份校验runtime-identity见 docs/FEATURES.md 中关于gsd-tools二进制冲突的记录也是如此。对用户与下游 Agent 的实际影响对普通用户项目绝大多数情况布局检测步骤静默跳过不再产生任何 Layout detection returned ... 提示代理直接进入 Step 1Orientation行为与修复前完全一致——因为 verdict 本来就没被消费唯一可见差异是日志更干净、输出预算更省。对GSD 框架仓库自身如本仓库门控判定通过布局检测照常运行.kilo/与.claude/gsd-core/根目录的区分逻辑不受影响stack.json、arch-decisions.json中的组件计数仍按检测出的规范路径由Glob实时统计agents/gsd-intel-updater.md 明确要求计数必须来自 Glob不能凭记忆或 CLAUDE.md。小结一个可复用的删除噪音工程范式这次变更虽然只有一句话背后是完整的工程闭环识别 dead-but-noisy 行为——输出无人消费却污染每个普通项目确认无下游消费者Group B 测试或补上正向门控Group A 测试用身份锚定门控——package.json的name等于框架包名而非枚举排除条件归档 changeset 并折叠回归测试让修复可追溯、可防回退。gsd-intel-updater的这次静默化是代码情报代理只对自身框架仓库做特殊处理对普通项目保持安静这一设计原则的典型样本。如果你在维护类似的代码情报/代码分析代理这套正向门控 无消费者断言 归档变更记录的组合可以直接复用。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐gsd-core Codex 适配器 TEXT_MODE 回退机制在 request_user_input 不可用时消除静默默认选择gsd core Codex 适配器 TEXT_MODE 回退机制在 request_user_input 不可用时消除静默默认选择 本文围绕 GSD Corwordfreq颠覆性的40语言词频分析专业级解决方案wordfreq颠覆性的40语言词频分析专业级解决方案 你是否曾在多语言文本处理中为词频数据而烦恼面对不同语言、不同数据源的词频信息如何获取准确可靠的统NLPget-shit-done Changeset 实战解析 sunny-ibex-wave 片段与 gsd-intel-updater 布局检测门控修复3290get shit done Changeset 实战解析 sunny ibex wave 片段与 gsd intel updater 布局检测门控修复 32人工智能AI 应用提示工程开发工具工作流自动化AI Agent上一篇AgentScope 自定义模型集成拆解基类契约与 4 个真实翻车点下一篇探索多租户管理新境界K3K —— Kubernetes中的Kubernetes神器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考