get-shit-done #3571 解析配置清单的安装副本与双路径解析机制【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done本文围绕 changeset 3571-configuration-manifest-install-layout.mdPR #3572展开讲解 get-shit-done 中运行时安装后gsd-tools.cjs加载配置清单失败这一缺陷的成因与修复方案安装流程如何将config-defaults.manifest.json与config-schema.manifest.json复制到get-shit-done/bin/shared/以及 configuration.generated.cjs 如何先解析安装路径、再回退源码路径。读完后你能理解该项目配置模块Configuration Module的单一数据源设计、清单文件的双布局解析逻辑以及如何用回归测试验证安装布局下的模块可加载性。问题背景单一数据源与两种运行布局该 changeset 的 frontmatter 声明了修复类型与关联 PRtype: Fixed pr: 3572正文一句话概括了修复内容运行时安装现在会把config-defaults.manifest.json和config-schema.manifest.json复制进get-shit-done/bin/shared/configuration.generated.cjs会优先解析该同位co-located安装路径再回退到源码检出source checkout的sdk/shared/路径从而防止在没有兄弟目录sdk/检出时直接调用已安装的 CJS 抛出MODULE_NOT_FOUND。要理解这个问题的严重性需要先看配置模块的数据流。get-shit-done 的 CJS 侧不再内联任何配置字面量而是全部来自清单。见 config-schema.cjs 头部注释/** * Thin adapter — sources schema data from the manifest via the generated * Configuration Module. All inline literals have been removed; the manifest * at sdk/shared/config-schema.manifest.json is the single source of truth. * * Imported by: * - config.cjs (isValidConfigKey validator) * - tests/config-schema-docs-parity.test.cjs (CI drift guard) * - tests/config-schema-sdk-parity.test.cjs (CJS↔SDK parity guard) */也就是说config-defaults.manifest.json 和 config-schema.manifest.json 是配置默认值与合法键集合的唯一事实来源single source of truth而 config.cjs、core.cjs 等运行时模块都依赖 configuration.generated.cjs 间接加载它们。但仓库存在两种布局源码检出布局get-shit-done/bin/lib/configuration.generated.cjs向上三级可到达sdk/shared/安装后布局安装器只复制get-shit-done/目录到运行时目录如~/.codex/get-shit-done/并不复制sdk/目录。此时向上三级的sdk/shared/路径指向一个不存在的位置require()直接抛MODULE_NOT_FOUND。修复一loadConfigurationManifest 的双候选路径解析修复后的核心实现位于 configuration.generated.cjs// ─── Manifest requires ─────────────────────────────────────────────────────── function loadConfigurationManifest(fileName) { const candidates [ // Installed runtime layout: get-shit-done/bin/shared/*.manifest.json join(__dirname, .., shared, fileName), // Source-repo dev layout: sdk/shared/*.manifest.json join(__dirname, .., .., .., sdk, shared, fileName), ]; let lastErr null; for (const candidate of candidates) { try { return require(candidate); } catch (err) { const isMissingCandidate err err.code MODULE_NOT_FOUND String(err.message || ).includes(candidate); if (!isMissingCandidate) throw err; lastErr err; } } throw new Error( ${fileName} not found. Tried:\n${candidates.map((p) ${p}).join(\n)}\nLast error: ${lastErr?.message} ); } const CONFIG_DEFAULTS loadConfigurationManifest(config-defaults.manifest.json); const SCHEMA_MANIFEST loadConfigurationManifest(config-schema.manifest.json);这段实现有几个值得注意的设计点候选路径有序遍历第一个候选join(__dirname, .., shared, fileName)对应安装运行时布局get-shit-done/bin/shared/因为本文件位于bin/lib/..即bin/第二个候选join(__dirname, .., .., .., sdk, shared, fileName)对应源码检出布局。安装路径排在首位保证安装环境优先命中同位清单。区分候选缺失与真实错误只有err.code MODULE_NOT_FOUND且错误信息中包含该候选路径时才继续尝试下一个候选其他异常如 JSON 语法错误会原样抛出不会被静默吞掉。失败时给出可诊断的错误信息两个候选都失败时抛出的错误逐行列出尝试过的路径和最后一次错误原因便于排查安装不完整的问题。加载后的清单随即派生出配置模块的三个核心键集合见 configuration.generated.cjsconst VALID_CONFIG_KEYS new Set(SCHEMA_MANIFEST.validKeys); const RUNTIME_STATE_KEYS new Set(SCHEMA_MANIFEST.runtimeStateKeys); const DYNAMIC_KEY_PATTERNS SCHEMA_MANIFEST.dynamicKeyPatterns.map((p) { const pattern new RegExp(p.source); return { ...p, test: (key) { pattern.lastIndex 0; return pattern.test(key); } }; });清单中还保存了正则的source字符串CJS 侧在运行时用new RegExp(source)重建.test函数——这与清单注释中runtimeStateKeysmirrorsRUNTIME_STATE_KEYS、dynamicKeyPatterns在运行时从source重建.test的描述一致。修复二安装流程把清单复制进安装负载仅有回退路径还不够——安装布局下回退路径sdk/shared/根本不存在。因此修复的另一半在 install.js 中安装器在复制get-shit-done/技能目录之后显式把sdk/shared/下的共享文件复制到 CJS 模块首先解析的同位路径// #3288 / #3571 — Copy sdk/shared manifests into the get-shit-done payload // at the co-located path that CJS modules resolve first: // get-shit-done/bin/shared/*.json // // The install copies get-shit-done/ but NOT sdk/ — CJS modules legacy // source-repo paths (3 levels up → sdk/shared/) therefore resolve to a // non-existent location in every post-install layout. Copying these shared // files alongside the CJS files ensures require() succeeds without needing // sdk/ to exist. const sharedPayloadFiles [ model-catalog.json, config-defaults.manifest.json, config-schema.manifest.json, ]; for (const fileName of sharedPayloadFiles) { const sharedSrc path.join(src, sdk, shared, fileName); const sharedDest path.join(skillDest, bin, shared, fileName); const displayPath get-shit-done/bin/shared/${fileName}; if (fs.existsSync(sharedSrc)) { fs.mkdirSync(path.dirname(sharedDest), { recursive: true }); fs.copyFileSync(sharedSrc, sharedDest); if (verifyFileInstalled(sharedDest, displayPath)) { console.log( ${green}✓${reset} Installed ${displayPath}); } else { failures.push(displayPath); } } else { failures.push(sdk/shared/${fileName} (source missing)); } }注意三点复制清单是model-catalog.json#3288 已加入与本修复新增的两个配置清单统一落到skillDest/bin/shared/即安装目录下的get-shit-done/bin/shared/每个文件复制后调用verifyFileInstalled校验失败会记入failures数组使安装报告能如实反映缺失若源端sdk/shared/file在发行包中缺失则显式记为sdk/shared/file (source missing)而不是静默跳过。由此形成两侧互补的完整闭环安装器保证安装布局下bin/shared/清单存在运行时保证源码布局下sdk/shared/清单可用无论哪种布局require()都能成功。两个清单的内容默认值与合法键集合修复对象是清单文件本身这里简要说明它们的结构与消费方式。config-defaults.manifest.json规范化默认值sdk/shared/config-defaults.manifest.json 是配置模块的规范化CONFIG_DEFAULTS其头部注释即说明嵌套形状为规范形态CJS 侧的扁平键如branching_strategy、sub_repos由消费方在边界处处理安全键security_enforcement、security_asvs_level、security_block_on与post_planning_gaps的规范位置在workflow.*下。主要默认值摘录如下配置键默认值说明model_profilebalanced模型档位commit_docstrue文档是否随代码提交parallelizationtrue计划并行执行search_gitignoredfalse搜索是否包含被 git 忽略的内容brave_search/firecrawl/exa_search均为false外部搜索 API 默认关闭运行时检测到 API 键时才启用见_commentcontext_window200000上下文窗口 token 数phase_namingsequential阶段命名策略modeinteractive运行模式claude_md_path./CLAUDE.mdCLAUDE.md 路径git.branching_strategynone分支策略规范嵌套位置git.create_tagtrue里程碑打 taggit.phase_branch_templategsd/phase-{phase}-{slug}阶段分支模板git.milestone_branch_templategsd/{milestone}-{slug}里程碑分支模板workflow.research/plan_check/verifier/nyquist_validationtrue计划/校验类开关workflow.tdd_modefalseTDD 模式workflow.human_verify_modeend-of-phase人工验证时机workflow.auto_advancefalse阶段自动推进workflow.node_repair/node_repair_budgettrue/2节点修复及其预算workflow.ui_safety_gatetrueUI 安全门禁workflow.discuss_mode/skip_discuss/max_discuss_passesdiscuss/false/3讨论模式相关workflow.subagent_timeout300000子代理超时毫秒workflow.code_review/code_review_depthtrue/standard代码评审及深度workflow.security_enforcement/security_asvs_level/security_block_ontrue/1/high安全强制与 ASVS 等级planning.granularitystandard规划粒度hooks.context_warnings/workflow_guardtrue/falseHook 开关graphify.auto_updatefalse依赖图自动更新这些默认值在加载时如何生效可见 configuration.generated.cjs 中的mergeDefaults与loadConfigloadConfig读取.planning/config.json存在 workstream 时为.planning/workstreams/name/config.json文件缺失或为空时直接返回mergeDefaults({})——即深拷贝默认值后叠加用户配置对象按深合并deepMergeConfig处理。同一文件中还实现了遗留键规范化normalizeLegacyKeys如顶层branching_strategy→git.branching_strategy、顶层depth→granularity和磁盘迁移migrateOnDisk这些逻辑都依赖清单提供的CONFIG_DEFAULTS。config-schema.manifest.json合法键集合sdk/shared/config-schema.manifest.json 的头部注释说明其来源约束validKeys是 CJS 侧config-schema.cjs与 SDK 侧query/config-schema.ts键集合的并集两者由 config-schema-sdk-parity.test.cjs 强制集合相等dynamicKeyPatterns保存 SDK 中规范的正则source字符串运行时重建.test。键集合包含如mode、granularity、parallelization、commit_docs、model_profile、workflow.research、workflow.plan_check、workflow.code_review_depth等规范路径。CJS 侧的消费入口是 config-schema.cjs 的isValidConfigKey先查VALID_CONFIG_KEYS精确集合再查RUNTIME_STATE_KEYS运行时状态键如workflow._auto_chain_active最后逐一匹配DYNAMIC_KEY_PATTERNS动态模式。这套校验被 config.cjs 用于config set等命令的键合法性检查并有 config-schema-docs-parity.test.cjs 作为文档漂移守卫。生成管线configuration.generated.cjs 从哪来configuration.generated.cjs 头部明确标注为生成文件* GENERATED FILE — DO NOT EDIT. * Source: sdk/src/configuration/index.ts * Regenerate: cd sdk npm run gen:configuration对应生成器 sdk/scripts/gen-configuration.mjs它要求requiresdk/shared/下的两个 JSON 清单输出到get-shit-done/bin/lib/configuration.generated.cjs见 gen-configuration.mjs 的outPath并把双候选路径注释直接写进生成产物gen-configuration.mjs 中的两处布局注释。因此 #3571 的路径解析修复是在生成器层面落地的——重新生成后所有发行版本都会携带同位路径优先的解析逻辑而不是在某个已安装副本上打补丁。清单新鲜度另有 sdk/scripts/check-configuration-fresh.mjs 在 CI 中把关防止手写清单与生成产物漂移。回归测试验证安装布局下的可加载性本修复的回归测试为 tests/bug-3571-configuration-manifest-install-path.test.cjs文件头注释直接复述了缺陷configuration.generated.cjs之前只用源码检出的sdk/shared路径导致已安装的gsd-tools.cjs损坏因为运行时安装复制get-shit-done/但不复制sdk/。测试包含两个用例用例一同位清单让模块无需sdk/shared即可加载L71-L96。在临时目录构造安装布局~/.codex/get-shit-done/bin/{lib,shared}把仓库中的configuration.generated.cjs与两个清单复制进去然后require该安装副本断言不抛异常并验证键集合内容assert.doesNotThrow(() { mod require(installedCjs); }, installed configuration.generated.cjs must not require ~/.codex/sdk/shared); assert.ok(mod.VALID_CONFIG_KEYS.has(workflow.plan_review_convergence));用例二完整安装后清单落在同位bin/shared/L98-L128。将HOME指向临时目录后调用真实的install(true, codex)来自 bin/install.js随后断言~/.codex/get-shit-done/bin/shared/下两个清单都存在、是合法 JSON且安装后的configuration.generated.cjs能直接从同位清单加载const sharedDir path.join(tmpRoot, .codex, get-shit-done, bin, shared); for (const fileName of [config-defaults.manifest.json, config-schema.manifest.json]) { const installedManifest path.join(sharedDir, fileName); assert.ok(fs.existsSync(installedManifest), ${fileName} must be copied to ${sharedDir}); assert.doesNotThrow(() { JSON.parse(fs.readFileSync(installedManifest, utf8)); }, ${fileName} must be valid JSON); }这两个用例分别覆盖解析器逻辑与安装器行为正好对应 #3571 修复的两个组成部分形成端到端验证。影响范围与验证方式从仓库证据看该修复的影响面与验证方式如下修复范围直接受益方是安装布局下直接调用 CJS 工具链的场景如gsd-tools.cjs的子命令。清单加载被 core.cjs、config.cjs 等基础模块间接依赖修复前这类调用在安装布局下会整体失效文档记录RELEASE-v1.42.3.md 的发布说明中记录了该条目指出 configuration.generated.cjs会查找已安装的 [路径]对应 #3571 / PR #3572可自查的安装布局修复后一次完整安装应在get-shit-done/bin/shared/下看到model-catalog.json、config-defaults.manifest.json、config-schema.manifest.json三个文件前两者即 #3571 新增复制项源码检出布局则依赖仓库根目录的sdk/shared/当前仓库中该目录包含这三个文件配套守卫测试除本修复的回归测试外config-schema-sdk-parity.test.cjs 保证 CJS 与 SDK 的键集合一致config-schema-docs-parity.test.cjs 防止文档漂移configuration-generator.test.cjs 与 feat-3598-generator-correctness.test.cjs 覆盖生成器正确性feat-3210-fallow-integration.test.cjs 等也引用了清单路径——改动清单或生成逻辑时这批测试构成回归边界。小结#3571 是一个典型的发布布局与开发布局不一致引发的运行时缺陷配置数据被集中到sdk/shared/的 JSON 清单作为单一事实源但安装器只分发get-shit-done/而不分发sdk/导致已安装 CJS 的require()落空。修复由两半构成——安装器把清单复制到 CJS 优先解析的同位目录get-shit-done/bin/shared/bin/install.js生成器在产物中写入安装路径优先、源码路径回退的loadConfigurationManifest解析逻辑get-shit-done/bin/lib/configuration.generated.cjs。tests/bug-3571-configuration-manifest-install-path.test.cjs 以模拟安装布局 require 不抛错和真实 install() 后清单就位两个用例锁定了这一行为。对维护者的启示是当数据源集中在仓库某个子目录、而发行负载只复制另一个子目录时要么在安装时补齐共享文件要么在解析时提供可诊断的多候选回退——本案例两者兼用并用端到端测试把安装器行为与解析器逻辑分别钉住。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
get-shit-done 3571 解析：配置清单的安装副本与双路径解析机制
get-shit-done #3571 解析配置清单的安装副本与双路径解析机制【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done本文围绕 changeset 3571-configuration-manifest-install-layout.mdPR #3572展开讲解 get-shit-done 中运行时安装后gsd-tools.cjs加载配置清单失败这一缺陷的成因与修复方案安装流程如何将config-defaults.manifest.json与config-schema.manifest.json复制到get-shit-done/bin/shared/以及 configuration.generated.cjs 如何先解析安装路径、再回退源码路径。读完后你能理解该项目配置模块Configuration Module的单一数据源设计、清单文件的双布局解析逻辑以及如何用回归测试验证安装布局下的模块可加载性。问题背景单一数据源与两种运行布局该 changeset 的 frontmatter 声明了修复类型与关联 PRtype: Fixed pr: 3572正文一句话概括了修复内容运行时安装现在会把config-defaults.manifest.json和config-schema.manifest.json复制进get-shit-done/bin/shared/configuration.generated.cjs会优先解析该同位co-located安装路径再回退到源码检出source checkout的sdk/shared/路径从而防止在没有兄弟目录sdk/检出时直接调用已安装的 CJS 抛出MODULE_NOT_FOUND。要理解这个问题的严重性需要先看配置模块的数据流。get-shit-done 的 CJS 侧不再内联任何配置字面量而是全部来自清单。见 config-schema.cjs 头部注释/** * Thin adapter — sources schema data from the manifest via the generated * Configuration Module. All inline literals have been removed; the manifest * at sdk/shared/config-schema.manifest.json is the single source of truth. * * Imported by: * - config.cjs (isValidConfigKey validator) * - tests/config-schema-docs-parity.test.cjs (CI drift guard) * - tests/config-schema-sdk-parity.test.cjs (CJS↔SDK parity guard) */也就是说config-defaults.manifest.json 和 config-schema.manifest.json 是配置默认值与合法键集合的唯一事实来源single source of truth而 config.cjs、core.cjs 等运行时模块都依赖 configuration.generated.cjs 间接加载它们。但仓库存在两种布局源码检出布局get-shit-done/bin/lib/configuration.generated.cjs向上三级可到达sdk/shared/安装后布局安装器只复制get-shit-done/目录到运行时目录如~/.codex/get-shit-done/并不复制sdk/目录。此时向上三级的sdk/shared/路径指向一个不存在的位置require()直接抛MODULE_NOT_FOUND。修复一loadConfigurationManifest 的双候选路径解析修复后的核心实现位于 configuration.generated.cjs// ─── Manifest requires ─────────────────────────────────────────────────────── function loadConfigurationManifest(fileName) { const candidates [ // Installed runtime layout: get-shit-done/bin/shared/*.manifest.json join(__dirname, .., shared, fileName), // Source-repo dev layout: sdk/shared/*.manifest.json join(__dirname, .., .., .., sdk, shared, fileName), ]; let lastErr null; for (const candidate of candidates) { try { return require(candidate); } catch (err) { const isMissingCandidate err err.code MODULE_NOT_FOUND String(err.message || ).includes(candidate); if (!isMissingCandidate) throw err; lastErr err; } } throw new Error( ${fileName} not found. Tried:\n${candidates.map((p) ${p}).join(\n)}\nLast error: ${lastErr?.message} ); } const CONFIG_DEFAULTS loadConfigurationManifest(config-defaults.manifest.json); const SCHEMA_MANIFEST loadConfigurationManifest(config-schema.manifest.json);这段实现有几个值得注意的设计点候选路径有序遍历第一个候选join(__dirname, .., shared, fileName)对应安装运行时布局get-shit-done/bin/shared/因为本文件位于bin/lib/..即bin/第二个候选join(__dirname, .., .., .., sdk, shared, fileName)对应源码检出布局。安装路径排在首位保证安装环境优先命中同位清单。区分候选缺失与真实错误只有err.code MODULE_NOT_FOUND且错误信息中包含该候选路径时才继续尝试下一个候选其他异常如 JSON 语法错误会原样抛出不会被静默吞掉。失败时给出可诊断的错误信息两个候选都失败时抛出的错误逐行列出尝试过的路径和最后一次错误原因便于排查安装不完整的问题。加载后的清单随即派生出配置模块的三个核心键集合见 configuration.generated.cjsconst VALID_CONFIG_KEYS new Set(SCHEMA_MANIFEST.validKeys); const RUNTIME_STATE_KEYS new Set(SCHEMA_MANIFEST.runtimeStateKeys); const DYNAMIC_KEY_PATTERNS SCHEMA_MANIFEST.dynamicKeyPatterns.map((p) { const pattern new RegExp(p.source); return { ...p, test: (key) { pattern.lastIndex 0; return pattern.test(key); } }; });清单中还保存了正则的source字符串CJS 侧在运行时用new RegExp(source)重建.test函数——这与清单注释中runtimeStateKeysmirrorsRUNTIME_STATE_KEYS、dynamicKeyPatterns在运行时从source重建.test的描述一致。修复二安装流程把清单复制进安装负载仅有回退路径还不够——安装布局下回退路径sdk/shared/根本不存在。因此修复的另一半在 install.js 中安装器在复制get-shit-done/技能目录之后显式把sdk/shared/下的共享文件复制到 CJS 模块首先解析的同位路径// #3288 / #3571 — Copy sdk/shared manifests into the get-shit-done payload // at the co-located path that CJS modules resolve first: // get-shit-done/bin/shared/*.json // // The install copies get-shit-done/ but NOT sdk/ — CJS modules legacy // source-repo paths (3 levels up → sdk/shared/) therefore resolve to a // non-existent location in every post-install layout. Copying these shared // files alongside the CJS files ensures require() succeeds without needing // sdk/ to exist. const sharedPayloadFiles [ model-catalog.json, config-defaults.manifest.json, config-schema.manifest.json, ]; for (const fileName of sharedPayloadFiles) { const sharedSrc path.join(src, sdk, shared, fileName); const sharedDest path.join(skillDest, bin, shared, fileName); const displayPath get-shit-done/bin/shared/${fileName}; if (fs.existsSync(sharedSrc)) { fs.mkdirSync(path.dirname(sharedDest), { recursive: true }); fs.copyFileSync(sharedSrc, sharedDest); if (verifyFileInstalled(sharedDest, displayPath)) { console.log( ${green}✓${reset} Installed ${displayPath}); } else { failures.push(displayPath); } } else { failures.push(sdk/shared/${fileName} (source missing)); } }注意三点复制清单是model-catalog.json#3288 已加入与本修复新增的两个配置清单统一落到skillDest/bin/shared/即安装目录下的get-shit-done/bin/shared/每个文件复制后调用verifyFileInstalled校验失败会记入failures数组使安装报告能如实反映缺失若源端sdk/shared/file在发行包中缺失则显式记为sdk/shared/file (source missing)而不是静默跳过。由此形成两侧互补的完整闭环安装器保证安装布局下bin/shared/清单存在运行时保证源码布局下sdk/shared/清单可用无论哪种布局require()都能成功。两个清单的内容默认值与合法键集合修复对象是清单文件本身这里简要说明它们的结构与消费方式。config-defaults.manifest.json规范化默认值sdk/shared/config-defaults.manifest.json 是配置模块的规范化CONFIG_DEFAULTS其头部注释即说明嵌套形状为规范形态CJS 侧的扁平键如branching_strategy、sub_repos由消费方在边界处处理安全键security_enforcement、security_asvs_level、security_block_on与post_planning_gaps的规范位置在workflow.*下。主要默认值摘录如下配置键默认值说明model_profilebalanced模型档位commit_docstrue文档是否随代码提交parallelizationtrue计划并行执行search_gitignoredfalse搜索是否包含被 git 忽略的内容brave_search/firecrawl/exa_search均为false外部搜索 API 默认关闭运行时检测到 API 键时才启用见_commentcontext_window200000上下文窗口 token 数phase_namingsequential阶段命名策略modeinteractive运行模式claude_md_path./CLAUDE.mdCLAUDE.md 路径git.branching_strategynone分支策略规范嵌套位置git.create_tagtrue里程碑打 taggit.phase_branch_templategsd/phase-{phase}-{slug}阶段分支模板git.milestone_branch_templategsd/{milestone}-{slug}里程碑分支模板workflow.research/plan_check/verifier/nyquist_validationtrue计划/校验类开关workflow.tdd_modefalseTDD 模式workflow.human_verify_modeend-of-phase人工验证时机workflow.auto_advancefalse阶段自动推进workflow.node_repair/node_repair_budgettrue/2节点修复及其预算workflow.ui_safety_gatetrueUI 安全门禁workflow.discuss_mode/skip_discuss/max_discuss_passesdiscuss/false/3讨论模式相关workflow.subagent_timeout300000子代理超时毫秒workflow.code_review/code_review_depthtrue/standard代码评审及深度workflow.security_enforcement/security_asvs_level/security_block_ontrue/1/high安全强制与 ASVS 等级planning.granularitystandard规划粒度hooks.context_warnings/workflow_guardtrue/falseHook 开关graphify.auto_updatefalse依赖图自动更新这些默认值在加载时如何生效可见 configuration.generated.cjs 中的mergeDefaults与loadConfigloadConfig读取.planning/config.json存在 workstream 时为.planning/workstreams/name/config.json文件缺失或为空时直接返回mergeDefaults({})——即深拷贝默认值后叠加用户配置对象按深合并deepMergeConfig处理。同一文件中还实现了遗留键规范化normalizeLegacyKeys如顶层branching_strategy→git.branching_strategy、顶层depth→granularity和磁盘迁移migrateOnDisk这些逻辑都依赖清单提供的CONFIG_DEFAULTS。config-schema.manifest.json合法键集合sdk/shared/config-schema.manifest.json 的头部注释说明其来源约束validKeys是 CJS 侧config-schema.cjs与 SDK 侧query/config-schema.ts键集合的并集两者由 config-schema-sdk-parity.test.cjs 强制集合相等dynamicKeyPatterns保存 SDK 中规范的正则source字符串运行时重建.test。键集合包含如mode、granularity、parallelization、commit_docs、model_profile、workflow.research、workflow.plan_check、workflow.code_review_depth等规范路径。CJS 侧的消费入口是 config-schema.cjs 的isValidConfigKey先查VALID_CONFIG_KEYS精确集合再查RUNTIME_STATE_KEYS运行时状态键如workflow._auto_chain_active最后逐一匹配DYNAMIC_KEY_PATTERNS动态模式。这套校验被 config.cjs 用于config set等命令的键合法性检查并有 config-schema-docs-parity.test.cjs 作为文档漂移守卫。生成管线configuration.generated.cjs 从哪来configuration.generated.cjs 头部明确标注为生成文件* GENERATED FILE — DO NOT EDIT. * Source: sdk/src/configuration/index.ts * Regenerate: cd sdk npm run gen:configuration对应生成器 sdk/scripts/gen-configuration.mjs它要求requiresdk/shared/下的两个 JSON 清单输出到get-shit-done/bin/lib/configuration.generated.cjs见 gen-configuration.mjs 的outPath并把双候选路径注释直接写进生成产物gen-configuration.mjs 中的两处布局注释。因此 #3571 的路径解析修复是在生成器层面落地的——重新生成后所有发行版本都会携带同位路径优先的解析逻辑而不是在某个已安装副本上打补丁。清单新鲜度另有 sdk/scripts/check-configuration-fresh.mjs 在 CI 中把关防止手写清单与生成产物漂移。回归测试验证安装布局下的可加载性本修复的回归测试为 tests/bug-3571-configuration-manifest-install-path.test.cjs文件头注释直接复述了缺陷configuration.generated.cjs之前只用源码检出的sdk/shared路径导致已安装的gsd-tools.cjs损坏因为运行时安装复制get-shit-done/但不复制sdk/。测试包含两个用例用例一同位清单让模块无需sdk/shared即可加载L71-L96。在临时目录构造安装布局~/.codex/get-shit-done/bin/{lib,shared}把仓库中的configuration.generated.cjs与两个清单复制进去然后require该安装副本断言不抛异常并验证键集合内容assert.doesNotThrow(() { mod require(installedCjs); }, installed configuration.generated.cjs must not require ~/.codex/sdk/shared); assert.ok(mod.VALID_CONFIG_KEYS.has(workflow.plan_review_convergence));用例二完整安装后清单落在同位bin/shared/L98-L128。将HOME指向临时目录后调用真实的install(true, codex)来自 bin/install.js随后断言~/.codex/get-shit-done/bin/shared/下两个清单都存在、是合法 JSON且安装后的configuration.generated.cjs能直接从同位清单加载const sharedDir path.join(tmpRoot, .codex, get-shit-done, bin, shared); for (const fileName of [config-defaults.manifest.json, config-schema.manifest.json]) { const installedManifest path.join(sharedDir, fileName); assert.ok(fs.existsSync(installedManifest), ${fileName} must be copied to ${sharedDir}); assert.doesNotThrow(() { JSON.parse(fs.readFileSync(installedManifest, utf8)); }, ${fileName} must be valid JSON); }这两个用例分别覆盖解析器逻辑与安装器行为正好对应 #3571 修复的两个组成部分形成端到端验证。影响范围与验证方式从仓库证据看该修复的影响面与验证方式如下修复范围直接受益方是安装布局下直接调用 CJS 工具链的场景如gsd-tools.cjs的子命令。清单加载被 core.cjs、config.cjs 等基础模块间接依赖修复前这类调用在安装布局下会整体失效文档记录RELEASE-v1.42.3.md 的发布说明中记录了该条目指出 configuration.generated.cjs会查找已安装的 [路径]对应 #3571 / PR #3572可自查的安装布局修复后一次完整安装应在get-shit-done/bin/shared/下看到model-catalog.json、config-defaults.manifest.json、config-schema.manifest.json三个文件前两者即 #3571 新增复制项源码检出布局则依赖仓库根目录的sdk/shared/当前仓库中该目录包含这三个文件配套守卫测试除本修复的回归测试外config-schema-sdk-parity.test.cjs 保证 CJS 与 SDK 的键集合一致config-schema-docs-parity.test.cjs 防止文档漂移configuration-generator.test.cjs 与 feat-3598-generator-correctness.test.cjs 覆盖生成器正确性feat-3210-fallow-integration.test.cjs 等也引用了清单路径——改动清单或生成逻辑时这批测试构成回归边界。小结#3571 是一个典型的发布布局与开发布局不一致引发的运行时缺陷配置数据被集中到sdk/shared/的 JSON 清单作为单一事实源但安装器只分发get-shit-done/而不分发sdk/导致已安装 CJS 的require()落空。修复由两半构成——安装器把清单复制到 CJS 优先解析的同位目录get-shit-done/bin/shared/bin/install.js生成器在产物中写入安装路径优先、源码路径回退的loadConfigurationManifest解析逻辑get-shit-done/bin/lib/configuration.generated.cjs。tests/bug-3571-configuration-manifest-install-path.test.cjs 以模拟安装布局 require 不抛错和真实 install() 后清单就位两个用例锁定了这一行为。对维护者的启示是当数据源集中在仓库某个子目录、而发行负载只复制另一个子目录时要么在安装时补齐共享文件要么在解析时提供可诊断的多候选回退——本案例两者兼用并用端到端测试把安装器行为与解析器逻辑分别钉住。【免费下载链接】get-shit-doneA light-weight and powerful meta-prompting, context engineering and spec-driven development system for Claude Code by TÂCHES.项目地址: https://gitcode.com/GitHub_Trending/getshi/get-shit-done创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考