get-shit-done 配置键白名单机制解析workflow._auto_chain_active 为何不再被 config-set 拒绝【免费下载链接】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本文以 get-shit-doneGSD的一个 changeset 修复PR #3197为主体讲解gsd-tools config-set workflow._auto_chain_active从被拒绝到被接受的完整过程一个内部运行时状态键RUNTIME_STATE_KEYS因 SDK 与 CJS 双端 schema 未同步而报出 Unknown config key以及修复如何通过三层校验、manifest 单一事实源和 CI 一致性断言从根本上杜绝此类漂移。读完后你能定位 GSD 配置键校验的调用链、理解双端 schema 的同步机制并复现/验证这一回归测试。问题背景一个内部运行时状态键被 config-set 拒绝workflow._auto_chain_active是 GSD 的内部运行时状态键runtime-state key用于追踪「自主链式执行autonomous chaining」是否处于激活状态。它在 GSD 的多个工作流执行链中被反复读写在get-shit-done/references/planning-config.md第 268 行中它被登记为键类型默认值取值说明workflow._auto_chain_activebooleanfalsetrue,falseInternal: tracks whether autonomous chaining is active写入方来自多个 workflow。例如get-shit-done/workflows/discuss-phase/modes/chain.md中的链式推进步骤会执行gsd-sdk query config-set workflow._auto_chain_active true/... false执行器 agent 也会在 执行器定义 中读取它AUTO_CHAIN$(gsd-sdk query config-get workflow._auto_chain_active 2/dev/null || echo false)。它参与检查点checkpoint的自动放行逻辑如get-shit-done/references/checkpoints.md第 11 行所述当workflow._auto_chain_active或workflow.auto_advance为true时human-verify 会自动批准、decision 自动选中第一个选项而 human-action 仍会停止认证门控无法自动化。关键问题在于这类键以下划线前缀_auto_chain_active标记为「内部状态」用户并不期望手动设置它但它必须能被config-set合法写入——否则工作流自身执行到该步骤时就会失败。这正是 PR #3197 要修复的场景。changeset.changeset/fix-3197-gsd-tools-config-whitelist.md记录了缺陷gsd-tools config-set workflow._auto_chain_activeno longer rejected—workflow._auto_chain_activeis an internal runtime-state key written by plan-phase, execute-phase, discuss-phase, and transition workflows. PR #3162 added it toRUNTIME_STATE_KEYSin the SDKsconfig-schema.tsbut did not mirror the change to the CJSconfig-schema.cjsused bygsd-tools.cjs. Users routed throughgsd-tools.cjscontinued to see Unknown config key (#3033).也就是说#3162 在 SDK 侧把该键加入了RUNTIME_STATE_KEYS但没有同步到 CJS 侧的config-schema.cjs于是走gsd-tools.cjs入口的用户仍然撞上 Unknown config key原始缺陷报告为 #3033。配置键校验的三道关卡GSD 对config-set key.path value的校验并非「非黑即白」而是由三个集合依次判定。以最典型的 CJS 校验器为例get-shit-done/bin/lib/config-schema.cjsfunction isValidConfigKey(keyPath) { if (VALID_CONFIG_KEYS.has(keyPath)) return true; // 1. 静态合法键精确匹配 if (RUNTIME_STATE_KEYS.has(keyPath)) return true; // 2. 运行时状态键#3197 新增的判断 return DYNAMIC_KEY_PATTERNS.some((p) p.test(keyPath)); // 3. 动态键正则模式 }三层语义分别是VALID_CONFIG_KEYS— 用户可配置的静态键精确字符串匹配如workflow.auto_advance、git.create_tag、model_profile。RUNTIME_STATE_KEYS— 内部运行时状态键通常不由用户手设但工作流需要config-set写入。当前集合只有workflow._auto_chain_active一项。DYNAMIC_KEY_PATTERNS— 带命名空间的动态键用正则匹配例如agent_skills.agent-type、review.models.cli-name、features.feature_name等。这三个集合的真实取值都来自单一 manifest sdk/shared/config-schema.manifest.json。其中runtimeStateKeys段第 101–103 行为runtimeStateKeys: [ workflow._auto_chain_active ]dynamicKeyPatterns段则列出了agent_skills、review.models、features、claude_md_assembly.blocks、model_profile_overrides、models、dynamic_routing、model_overrides、review.max_prompt_tokens_per_reviewer等正则模式。当isValidConfigKey全部落空时CJS/SDK 侧会抛出Unknown config key: key并附带基于「最长公共前缀」的键名纠错建议见 sdk/src/query/config-mutation.ts 的isValidConfigKey其中CONFIG_KEY_SUGGESTIONS先于 LCP 兜底提供更精确的提示。缺陷的本质就是workflow._auto_chain_active落在第二关RUNTIME_STATE_KEYS应当命中但 CJS 侧的RUNTIME_STATE_KEYS是空的于是掉进了Unknown config key分支。根因SDK 与 CJS 双端 schema 漂移GSD 存在两条config-set的执行路径历史上各自维护一份 schema 字面量路径入口校验器schema 来源#3197 时期CJSget-shit-done/bin/gsd-tools.cjsget-shit-done/bin/lib/config.cjs 调isValidConfigKeyconfig-schema.cjs内联SDKgsd-sdk query config-setsdk/src/query/config-mutation.ts 的configSetconfig-schema.ts内联CJS 路径gsd-tools.cjs→config.cjs的cmdConfigSet第 410 行if (!isValidConfigKey(keyPath))→config-schema.cjs的isValidConfigKey。SDK 路径config-mutation.ts的configSet第 281 行const validation isValidConfigKey(keyPath)→config-schema.ts的isValidConfigKeyPath。PR #3162 只改了 SDK 侧config-schema.ts把workflow._auto_chain_active加进了RUNTIME_STATE_KEYSCJS 侧的config-schema.cjs没有跟随。结果就是同一句config-set workflow._auto_chain_active true走 SDK 入口能成功走gsd-tools.cjs入口却报 Unknown config key——这就是 #3033 的现象也是双端 schema 字面量「漂移」的典型后果。修复方案把 RUNTIME_STATE_KEYS 纳入 CJS 校验changeset 明确列出了 #3197 的四处改动均可在仓库源码中一一对应给config-schema.cjs增加RUNTIME_STATE_KEYS并与VALID_CONFIG_KEYS一同导出get-shit-done/bin/lib/config-schema.cjsmodule.exports { VALID_CONFIG_KEYS, RUNTIME_STATE_KEYS, DYNAMIC_KEY_PATTERNS, isValidConfigKey };更新isValidConfigKey()接受运行时状态键——即在VALID_CONFIG_KEYS命中之后、DYNAMIC_KEY_PATTERNS之前插入if (RUNTIME_STATE_KEYS.has(keyPath)) return true;第 27 行。SDK 的config-mutation.ts改为导入并校验同一集合sdk/src/query/config-mutation.ts 从./config-schema.js导入RUNTIME_STATE_KEYS并在isValidConfigKey第 165 行做RUNTIME_STATE_KEYS.has(keyPath)判断使双端判定逻辑对齐。新增 CI 一致性断言确保两侧的RUNTIME_STATE_KEYS集合保持同步见下节。修复后config-set成功写入的返回值形如config-mutation.ts 第 446–454 行{ data: { updated: true, key: workflow._auto_chain_active, value: true } }值得强调的是取值语义true/false会被parseConfigValue第 208–216 行强制转换为原生布尔避免把字符串true写进config.json。纵深manifest 单一事实源与结构性防漂移#3536changeset 描述的 #3197 是「立即修复」而当前仓库的源码结构显示随后一次重构Phase 2 Cycle 5#3536把这种漂移从「需要 CI 拦截」升级成了「结构上不可能发生」。从当前源码结构看manifest 成为唯一事实源。sdk/shared/config-schema.manifest.json 同时承载validKeys、runtimeStateKeys、dynamicKeyPatterns三份数据其_comment字段说明validKeys是 CJS 与 SDK 两侧并集二者由tests/config-schema-sdk-parity.test.cjs强制集合相等。SDK 侧sdk/src/configuration/index.ts 直接从 manifest 读出VALID_CONFIG_KEYS与RUNTIME_STATE_KEYSexport const VALID_CONFIG_KEYS: ReadonlySetstring new Set(_schemaManifest.validKeys); export const RUNTIME_STATE_KEYS: ReadonlySetstring new Set(_schemaManifest.runtimeStateKeys);而 sdk/src/query/config-schema.ts 已变成一个「薄重导出适配器」不再含任何内联键字面量。CJS 侧get-shit-done/bin/lib/configuration.generated.cjs 是「GENERATED FILE — DO NOT EDIT」同样从 manifest 装载const SCHEMA_MANIFEST loadConfigurationManifest(config-schema.manifest.json); const VALID_CONFIG_KEYS new Set(SCHEMA_MANIFEST.validKeys); const RUNTIME_STATE_KEYS new Set(SCHEMA_MANIFEST.runtimeStateKeys);get-shit-done/bin/lib/config-schema.cjs 则只是require这个生成文件把三个集合透传出去。这样一来#3197 要防的「SDK 加了、CJS 没加」在结构上被消除——两侧都从同一份 manifest 派生不存在两份可独立漂移的字面量。CI 断言tests/config-schema-sdk-parity.test.cjs 的「CJS RUNTIME_STATE_KEYS matches manifest runtimeStateKeys exactly」退化为「确保没人和 manifest 脱钩」的守卫。这也是从源码结构可以推断出的设计意图与其让每个修复去追平两端不如把两端收敛到一个数据源。回归测试与验证针对本次修复的回归测试是 tests/bug-3197-gsd-tools-config-whitelist.test.cjs共三条用例走的是真实的gsd-tools.cjsCJS 路径// 用例 1通过 CJS 路径设置 workflow._auto_chain_activetrue 成功 const result runGsdTools([config-set, workflow._auto_chain_active, true], tmpDir); assert.ok(result.success, config-set workflow._auto_chain_active true should succeed, got:...); // 用例 2/3设置 true / false 后断言 .planning/config.json 中 // config.workflow._auto_chain_active 的确切布尔值三条用例分别验证(1) 不再被拒绝result.success为真(2) 设置true后磁盘config.json中workflow._auto_chain_active true(3) 设置false后为false。测试注释直接点明根因——「RUNTIME_STATE_KEYSwas added to sdk/…/config-schema.ts in #3162 but not to get-shit-done/bin/lib/config-schema.cjs」与上文根因分析一致。配套的一致性守卫 tests/config-schema-sdk-parity.test.cjs 则从 manifest 出发断言CJS 的VALID_CONFIG_KEYS、RUNTIME_STATE_KEYS、DYNAMIC_KEY_PATTERNS与 manifest 完全相等且 SDK 的config-schema.ts是「重导出壳」而非「重新声明的 Set」。相关代码路径速查关注点路径说明本次修复的 changeset.changeset/fix-3197-gsd-tools-config-whitelist.md主体文档PR #3197CJS 入口get-shit-done/bin/gsd-tools.cjsconfig-set命令入口CJS 校验器get-shit-done/bin/lib/config.cjs / config-schema.cjscmdConfigSet调isValidConfigKeyCJS 生成源get-shit-done/bin/lib/configuration.generated.cjs从 manifest 装载三个集合SDK 校验器sdk/src/query/config-mutation.tsconfigSet与isValidConfigKeySDK schema 适配器sdk/src/query/config-schema.ts重导出 isValidConfigKeyPath单一事实源 manifestsdk/shared/config-schema.manifest.jsonruntimeStateKeys在此键的登记与语义get-shit-done/references/planning-config.md / checkpoints.md类型/默认值/自动放行逻辑写入方示例agents/gsd-executor.md / workflows/discuss-phase/modes/chain.md谁在读写该键回归测试tests/bug-3197-gsd-tools-config-whitelist.test.cjs三条用例走 CJS 路径一致性守卫tests/config-schema-sdk-parity.test.cjs双端集合与 manifest 相等版本记录CHANGELOG.md / docs/RELEASE-v1.41.0.md#3197 于 v1.41.0 随版发布小结缺陷workflow._auto_chain_active内部运行时状态键在 #3162 只被加入 SDK 侧RUNTIME_STATE_KEYS未同步到 CJS 侧导致走gsd-tools.cjs的config-set报 Unknown config key#3033。修复#3197CJS 侧config-schema.cjs增加并导出RUNTIME_STATE_KEYSisValidConfigKey()新增运行时状态键判定SDKconfig-mutation.ts对齐校验新增 CI 一致性断言。结构演进#3536sdk/shared/config-schema.manifest.json成为 SDK 与 CJS 双端共同的单一事实源双端集合由其派生从结构上消除了这类「加一端忘另一端」的漂移。验证tests/bug-3197-gsd-tools-config-whitelist.test.cjs功能回归与tests/config-schema-sdk-parity.test.cjs集合一致性共同保证修复不被回退。【免费下载链接】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 配置键白名单机制解析workflow._auto_chain_active 为何不再被 config-set 拒绝【免费下载链接】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本文以 get-shit-doneGSD的一个 changeset 修复PR #3197为主体讲解gsd-tools config-set workflow._auto_chain_active从被拒绝到被接受的完整过程一个内部运行时状态键RUNTIME_STATE_KEYS因 SDK 与 CJS 双端 schema 未同步而报出 Unknown config key以及修复如何通过三层校验、manifest 单一事实源和 CI 一致性断言从根本上杜绝此类漂移。读完后你能定位 GSD 配置键校验的调用链、理解双端 schema 的同步机制并复现/验证这一回归测试。问题背景一个内部运行时状态键被 config-set 拒绝workflow._auto_chain_active是 GSD 的内部运行时状态键runtime-state key用于追踪「自主链式执行autonomous chaining」是否处于激活状态。它在 GSD 的多个工作流执行链中被反复读写在get-shit-done/references/planning-config.md第 268 行中它被登记为键类型默认值取值说明workflow._auto_chain_activebooleanfalsetrue,falseInternal: tracks whether autonomous chaining is active写入方来自多个 workflow。例如get-shit-done/workflows/discuss-phase/modes/chain.md中的链式推进步骤会执行gsd-sdk query config-set workflow._auto_chain_active true/... false执行器 agent 也会在 执行器定义 中读取它AUTO_CHAIN$(gsd-sdk query config-get workflow._auto_chain_active 2/dev/null || echo false)。它参与检查点checkpoint的自动放行逻辑如get-shit-done/references/checkpoints.md第 11 行所述当workflow._auto_chain_active或workflow.auto_advance为true时human-verify 会自动批准、decision 自动选中第一个选项而 human-action 仍会停止认证门控无法自动化。关键问题在于这类键以下划线前缀_auto_chain_active标记为「内部状态」用户并不期望手动设置它但它必须能被config-set合法写入——否则工作流自身执行到该步骤时就会失败。这正是 PR #3197 要修复的场景。changeset.changeset/fix-3197-gsd-tools-config-whitelist.md记录了缺陷gsd-tools config-set workflow._auto_chain_activeno longer rejected—workflow._auto_chain_activeis an internal runtime-state key written by plan-phase, execute-phase, discuss-phase, and transition workflows. PR #3162 added it toRUNTIME_STATE_KEYSin the SDKsconfig-schema.tsbut did not mirror the change to the CJSconfig-schema.cjsused bygsd-tools.cjs. Users routed throughgsd-tools.cjscontinued to see Unknown config key (#3033).也就是说#3162 在 SDK 侧把该键加入了RUNTIME_STATE_KEYS但没有同步到 CJS 侧的config-schema.cjs于是走gsd-tools.cjs入口的用户仍然撞上 Unknown config key原始缺陷报告为 #3033。配置键校验的三道关卡GSD 对config-set key.path value的校验并非「非黑即白」而是由三个集合依次判定。以最典型的 CJS 校验器为例get-shit-done/bin/lib/config-schema.cjsfunction isValidConfigKey(keyPath) { if (VALID_CONFIG_KEYS.has(keyPath)) return true; // 1. 静态合法键精确匹配 if (RUNTIME_STATE_KEYS.has(keyPath)) return true; // 2. 运行时状态键#3197 新增的判断 return DYNAMIC_KEY_PATTERNS.some((p) p.test(keyPath)); // 3. 动态键正则模式 }三层语义分别是VALID_CONFIG_KEYS— 用户可配置的静态键精确字符串匹配如workflow.auto_advance、git.create_tag、model_profile。RUNTIME_STATE_KEYS— 内部运行时状态键通常不由用户手设但工作流需要config-set写入。当前集合只有workflow._auto_chain_active一项。DYNAMIC_KEY_PATTERNS— 带命名空间的动态键用正则匹配例如agent_skills.agent-type、review.models.cli-name、features.feature_name等。这三个集合的真实取值都来自单一 manifest sdk/shared/config-schema.manifest.json。其中runtimeStateKeys段第 101–103 行为runtimeStateKeys: [ workflow._auto_chain_active ]dynamicKeyPatterns段则列出了agent_skills、review.models、features、claude_md_assembly.blocks、model_profile_overrides、models、dynamic_routing、model_overrides、review.max_prompt_tokens_per_reviewer等正则模式。当isValidConfigKey全部落空时CJS/SDK 侧会抛出Unknown config key: key并附带基于「最长公共前缀」的键名纠错建议见 sdk/src/query/config-mutation.ts 的isValidConfigKey其中CONFIG_KEY_SUGGESTIONS先于 LCP 兜底提供更精确的提示。缺陷的本质就是workflow._auto_chain_active落在第二关RUNTIME_STATE_KEYS应当命中但 CJS 侧的RUNTIME_STATE_KEYS是空的于是掉进了Unknown config key分支。根因SDK 与 CJS 双端 schema 漂移GSD 存在两条config-set的执行路径历史上各自维护一份 schema 字面量路径入口校验器schema 来源#3197 时期CJSget-shit-done/bin/gsd-tools.cjsget-shit-done/bin/lib/config.cjs 调isValidConfigKeyconfig-schema.cjs内联SDKgsd-sdk query config-setsdk/src/query/config-mutation.ts 的configSetconfig-schema.ts内联CJS 路径gsd-tools.cjs→config.cjs的cmdConfigSet第 410 行if (!isValidConfigKey(keyPath))→config-schema.cjs的isValidConfigKey。SDK 路径config-mutation.ts的configSet第 281 行const validation isValidConfigKey(keyPath)→config-schema.ts的isValidConfigKeyPath。PR #3162 只改了 SDK 侧config-schema.ts把workflow._auto_chain_active加进了RUNTIME_STATE_KEYSCJS 侧的config-schema.cjs没有跟随。结果就是同一句config-set workflow._auto_chain_active true走 SDK 入口能成功走gsd-tools.cjs入口却报 Unknown config key——这就是 #3033 的现象也是双端 schema 字面量「漂移」的典型后果。修复方案把 RUNTIME_STATE_KEYS 纳入 CJS 校验changeset 明确列出了 #3197 的四处改动均可在仓库源码中一一对应给config-schema.cjs增加RUNTIME_STATE_KEYS并与VALID_CONFIG_KEYS一同导出get-shit-done/bin/lib/config-schema.cjsmodule.exports { VALID_CONFIG_KEYS, RUNTIME_STATE_KEYS, DYNAMIC_KEY_PATTERNS, isValidConfigKey };更新isValidConfigKey()接受运行时状态键——即在VALID_CONFIG_KEYS命中之后、DYNAMIC_KEY_PATTERNS之前插入if (RUNTIME_STATE_KEYS.has(keyPath)) return true;第 27 行。SDK 的config-mutation.ts改为导入并校验同一集合sdk/src/query/config-mutation.ts 从./config-schema.js导入RUNTIME_STATE_KEYS并在isValidConfigKey第 165 行做RUNTIME_STATE_KEYS.has(keyPath)判断使双端判定逻辑对齐。新增 CI 一致性断言确保两侧的RUNTIME_STATE_KEYS集合保持同步见下节。修复后config-set成功写入的返回值形如config-mutation.ts 第 446–454 行{ data: { updated: true, key: workflow._auto_chain_active, value: true } }值得强调的是取值语义true/false会被parseConfigValue第 208–216 行强制转换为原生布尔避免把字符串true写进config.json。纵深manifest 单一事实源与结构性防漂移#3536changeset 描述的 #3197 是「立即修复」而当前仓库的源码结构显示随后一次重构Phase 2 Cycle 5#3536把这种漂移从「需要 CI 拦截」升级成了「结构上不可能发生」。从当前源码结构看manifest 成为唯一事实源。sdk/shared/config-schema.manifest.json 同时承载validKeys、runtimeStateKeys、dynamicKeyPatterns三份数据其_comment字段说明validKeys是 CJS 与 SDK 两侧并集二者由tests/config-schema-sdk-parity.test.cjs强制集合相等。SDK 侧sdk/src/configuration/index.ts 直接从 manifest 读出VALID_CONFIG_KEYS与RUNTIME_STATE_KEYSexport const VALID_CONFIG_KEYS: ReadonlySetstring new Set(_schemaManifest.validKeys); export const RUNTIME_STATE_KEYS: ReadonlySetstring new Set(_schemaManifest.runtimeStateKeys);而 sdk/src/query/config-schema.ts 已变成一个「薄重导出适配器」不再含任何内联键字面量。CJS 侧get-shit-done/bin/lib/configuration.generated.cjs 是「GENERATED FILE — DO NOT EDIT」同样从 manifest 装载const SCHEMA_MANIFEST loadConfigurationManifest(config-schema.manifest.json); const VALID_CONFIG_KEYS new Set(SCHEMA_MANIFEST.validKeys); const RUNTIME_STATE_KEYS new Set(SCHEMA_MANIFEST.runtimeStateKeys);get-shit-done/bin/lib/config-schema.cjs 则只是require这个生成文件把三个集合透传出去。这样一来#3197 要防的「SDK 加了、CJS 没加」在结构上被消除——两侧都从同一份 manifest 派生不存在两份可独立漂移的字面量。CI 断言tests/config-schema-sdk-parity.test.cjs 的「CJS RUNTIME_STATE_KEYS matches manifest runtimeStateKeys exactly」退化为「确保没人和 manifest 脱钩」的守卫。这也是从源码结构可以推断出的设计意图与其让每个修复去追平两端不如把两端收敛到一个数据源。回归测试与验证针对本次修复的回归测试是 tests/bug-3197-gsd-tools-config-whitelist.test.cjs共三条用例走的是真实的gsd-tools.cjsCJS 路径// 用例 1通过 CJS 路径设置 workflow._auto_chain_activetrue 成功 const result runGsdTools([config-set, workflow._auto_chain_active, true], tmpDir); assert.ok(result.success, config-set workflow._auto_chain_active true should succeed, got:...); // 用例 2/3设置 true / false 后断言 .planning/config.json 中 // config.workflow._auto_chain_active 的确切布尔值三条用例分别验证(1) 不再被拒绝result.success为真(2) 设置true后磁盘config.json中workflow._auto_chain_active true(3) 设置false后为false。测试注释直接点明根因——「RUNTIME_STATE_KEYSwas added to sdk/…/config-schema.ts in #3162 but not to get-shit-done/bin/lib/config-schema.cjs」与上文根因分析一致。配套的一致性守卫 tests/config-schema-sdk-parity.test.cjs 则从 manifest 出发断言CJS 的VALID_CONFIG_KEYS、RUNTIME_STATE_KEYS、DYNAMIC_KEY_PATTERNS与 manifest 完全相等且 SDK 的config-schema.ts是「重导出壳」而非「重新声明的 Set」。相关代码路径速查关注点路径说明本次修复的 changeset.changeset/fix-3197-gsd-tools-config-whitelist.md主体文档PR #3197CJS 入口get-shit-done/bin/gsd-tools.cjsconfig-set命令入口CJS 校验器get-shit-done/bin/lib/config.cjs / config-schema.cjscmdConfigSet调isValidConfigKeyCJS 生成源get-shit-done/bin/lib/configuration.generated.cjs从 manifest 装载三个集合SDK 校验器sdk/src/query/config-mutation.tsconfigSet与isValidConfigKeySDK schema 适配器sdk/src/query/config-schema.ts重导出 isValidConfigKeyPath单一事实源 manifestsdk/shared/config-schema.manifest.jsonruntimeStateKeys在此键的登记与语义get-shit-done/references/planning-config.md / checkpoints.md类型/默认值/自动放行逻辑写入方示例agents/gsd-executor.md / workflows/discuss-phase/modes/chain.md谁在读写该键回归测试tests/bug-3197-gsd-tools-config-whitelist.test.cjs三条用例走 CJS 路径一致性守卫tests/config-schema-sdk-parity.test.cjs双端集合与 manifest 相等版本记录CHANGELOG.md / docs/RELEASE-v1.41.0.md#3197 于 v1.41.0 随版发布小结缺陷workflow._auto_chain_active内部运行时状态键在 #3162 只被加入 SDK 侧RUNTIME_STATE_KEYS未同步到 CJS 侧导致走gsd-tools.cjs的config-set报 Unknown config key#3033。修复#3197CJS 侧config-schema.cjs增加并导出RUNTIME_STATE_KEYSisValidConfigKey()新增运行时状态键判定SDKconfig-mutation.ts对齐校验新增 CI 一致性断言。结构演进#3536sdk/shared/config-schema.manifest.json成为 SDK 与 CJS 双端共同的单一事实源双端集合由其派生从结构上消除了这类「加一端忘另一端」的漂移。验证tests/bug-3197-gsd-tools-config-whitelist.test.cjs功能回归与tests/config-schema-sdk-parity.test.cjs集合一致性共同保证修复不被回退。【免费下载链接】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），仅供参考
