get-shit-done v1.39.0-rc.4 技术解读：`--minimal` 瘦身安装与 Codex `config.toml` 防损坏修复-二趣网

get-shit-done v1.39.0-rc.4 技术解读：`--minimal`瘦身安装与 Codex`config.toml`防损坏修复

【免费下载链接】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

本指南以 docs/RELEASE-v1.39.0-rc.4.md 为骨架，面向需要在本地小上下文窗口大模型上运行 GSD（get-shit-done，基于 Claude Code 的元提示词 / 上下文工程 / 规格驱动开发系统）的开发者，深入讲解 v1.39.0-rc.4 两个关键改动：用于压缩冷启动系统提示词开销的--minimal安装模式，以及让 Codex 安装不再破坏~/.codex/config.toml的四层防御修复。读完你将掌握如何针对自身模型上下文窗口选择合适的安装模式、如何在 minimal/full 之间无损切换，以及 GSD 安装器如何通过"原子写 + 结构校验 + 快照回滚"保护既有 TOML 配置。

版本定位：npm`next`标签下的预发布候选

v1.39.0-rc.4 是发布候选（Release Candidate），发布在 npm 的nextdist-tag 下。它包含两项核心内容：

新增：--minimal安装开关（别名--core-only，issue #2762）；
修复：Codex 安装不再损坏~/.codex/config.toml（issue #2760）。

同一仓库的后续文档（如 docs/RELEASE-v1.39.0-rc.5.md、docs/RELEASE-v1.39.0-rc.7.md）会持续追踪该版本分支上的修复进展，可对照阅读以了解完整演进脉络。

安装预发布版本

RC 版本只发布到next标签，因此安装命令必须显式带上@next：

# npm 全局安装 npm install -g get-shit-done-cc@next # npx 一次性执行 npx get-shit-done-cc@next

如需精确定位到本 RC，可锁定完整版本号：

npm install -g get-shit-done-cc@1.39.0-rc.4

特性一：`--minimal`/`--core-only`瘦身安装模式（#2762）

它解决什么问题

安装器默认写入 GSD 的全量技能面（full skill surface）。问题是：Claude Code、opencode 等运行时每一轮都会把所有已安装技能的描述枚举进<available_skills>，即"技能即常驻提示词 token"。技能与子代理越多，冷启动系统提示词开销越大，甚至在小上下文窗口中挤占真正可用的推理空间。

从 get-shit-done/bin/lib/install-profiles.cjs 的源码注释可看到量级背景：当插件叠加到 66 个技能 + 33 个子代理时，仅技能描述列表就会消耗默认的 1% 上下文技能预算中的约 60%，导致技能被运行时丢弃。这正是本版本引入瘦身安装模式的根本动机。

`--minimal`安装了什么

--minimal（别名--core-only）只写入支撑主工作流闭环所需的少量核心技能，不安装任何gsd-*子代理：

new-project、discuss-phase、plan-phase、execute-phase、help、update

该模式的收益在冷启动系统提示词开销上有数量级差异：

模式	冷启动系统提示词开销
full（默认）	约 12k tokens
minimal	约 700 tokens

适用场景与默认值取舍

本地大模型用户（32K–128K 上下文窗口）：minimal 模式是明显更合适的选择，把上下文预算留给真正的项目讨论与规划内容；
云端模型用户（Sonnet / Opus 系列）：上下文窗口充足，full 全量技能面才是正确默认，无需使用--minimal。

源码视角：标志解析与清单记录

在安装器入口 bin/install.js 中，两个开关被统一识别，并归一到同一个内部模式：

const hasMinimal = args.includes('--minimal') || args.includes('--core-only'); // --profile=<name> 或 --profile=<n1>,<n2>（可组合）；与 --minimal 互斥 // 1. --minimal / --core-only → 'core'（向后兼容别名）

安装清单会记录本次安装的模式（mode: "minimal" | "full"），落盘逻辑见 bin/install.js：

mode: options.mode === 'minimal' ? 'minimal' : 'full',

演进提示：六技能到八技能的仓库现状

需要注意一个"版本漂移"事实：rc.4 发布说明中列出的 core 技能是六个，而本仓库当前代码中的--minimal已被重构为--profile=core的向后兼容别名，技能集由PROFILES.core定义（见 get-shit-done/bin/lib/install-profiles.cjs），目前共八个技能：

const PROFILES = Object.freeze({ core: Object.freeze([ 'new-project', 'discuss-phase', 'plan-phase', 'execute-phase', 'phase', 'help', 'update', 'surface', ]), ... });

即在new-project、discuss-phase、plan-phase、execute-phase、help、update之上，后来的重构（技能表面预算，见 docs/adr/0011-skill-surface-budget-module.md 与 docs/research/2026-05-12-skill-surface-budget.md）又纳入了phase与surface。测试 tests/install-minimal-hooks.test.cjs 通过assert.deepStrictEqual精确锁定了这 8 个技能、0 个代理的契约：

assert.deepStrictEqual( [...MINIMAL_SKILL_ALLOWLIST].sort(), ['discuss-phase', 'execute-phase', 'help', 'new-project', 'phase', 'plan-phase', 'surface', 'update'], );

因此，在实际使用中以当前仓库/发布版本的实际清单为准；rc.4 文档中的 12k/700 token 对比是当时的测量口径，用来评估收益量级仍是有效的。

从 minimal 回到 full

minimal 不是单向门。安装清单记录了模式后，随时可以扩容：

扩容：运行gsd update（不带--minimal）即可扩展到完整技能集；
降级/切换：以--minimal重装会清掉此前的gsd-*代理与技能残留，但保留用户自建的代理与技能——测试 tests/install-minimal-hooks.test.cjs 明确断言 full → minimal 降级后my-custom-agent.md这类用户文件仍然存在，而所有gsd-*残留被移除。

从实现上看，minimal 安装会先把源commands/gsd/目录按白名单暂存（stage）到一个临时目录再做拷贝（见 get-shit-done/bin/lib/install-profiles.cjs 中stageSkillsForProfile与stageAgentsForProfile），并注册了进程退出与 SIGINT/SIGTERM/SIGHUP 清理钩子，避免中途中断留下垃圾目录；测试还覆盖了"拷贝中途磁盘写满"时删除半成品暂存目录并重新抛错的场景。这种"先暂存、后落盘、失败即清理"的设计，保证了瘦身安装本身不会污染源目录。

特性二：Codex 安装不再损坏`~/.codex/config.toml`（#2760）

问题背景

此前有四位用户确认了同一类故障：旧版安装器把~/.codex/config.toml改写成 Codex 启动即拒绝的状态，唯一的自救手段是手动清理文件。rc.4 从源头重构了 Codex 配置的写入路径，采用如下策略组合。

修复一：无条件剥离两类非法`agents`块

当前 Codex TOML schema 只接受[agents.<name>]（struct 表单）结构。旧版安装器曾先后写入过单括号的[agents]与数组序列形式的[[agents]]——无论文件里有没有 GSD 标记，这两类块在现行 schema 下都是非法且会导致 Codex 启动失败的。因此安装器现在无条件剥离它们，使重装具备"自愈"能力，覆盖到标记被第三方工具改掉或从未写过的文件。相关回归测试见 tests/bug-2760-codex-install-defensive.test.cjs（如"strips bare[agents]single-bracket block (no GSD marker)"与"strips[[agents]]sequence-form block"两条用例），并验证了用户的[model]、[projects."/tmp/x"]等无关段落在剥离后结构完整保留。

修复二：按用户既有形态写出 GSD Hook

安装器会先探测用户配置里已存在的 Hook 写法，再决定自己用哪种形态落地：

若已有任何 Hook 使用带事件命名空间的[[hooks.<Event>]]（数组表单），则 GSD 跟随使用[[hooks.<Event>]]形式共存；
否则退回顶层[[hooks]]形式；
写入过程中，把旧的[hooks.<Event>]（map 表单）迁移为[[hooks.<Event>]]（数组表单）。

检测逻辑对应实现中的hasUserNamespacedAotHooks等辅助函数（可从 bin/install.js 导出并直接在 tests/bug-2760-codex-install-defensive.test.cjs 中单测）。需要说明的是，后续 Codex 0.124.0+ 进一步要求两层嵌套的[[hooks.SessionStart.hooks]]结构，这部分迁移加固被记录在 rc.5（见 docs/RELEASE-v1.39.0-rc.5.md），并同样落在 tests/bug-2760-codex-install-defensive.test.cjs 的用例集中——这也展示了"每个 Schema 修正都必须配回归测试"的工程纪律。

修复三：临时文件 +`renameSync`的原子写

写入不再直接覆盖config.toml，而是先写<target>.tmp-<pid>-<n>临时文件，再renameSync原子替换（实现见 bin/install.js）。原子写的意义在于：即使进程在写入中途崩溃或被杀，目标文件要么是旧内容、要么是新内容，绝不会出现半截截断的中间态。

修复四：写后严格 TOML 校验 + 快照回滚

落盘之后，安装器用自研的严格 TOML 解析器（parseTomlToObject，见 bin/install.js）对最终字节做结构校验，会拒绝：

重复 key；
重复的表头 / 形状冲突的表头（如先[[arr]]再[arr]）；
值之后的尾随垃圾字节；
不支持的取值类型。

关键语义变化是：任何写前或写时失败都不再"警告后继续"，而是：

恢复写前快照（restoreCodexSnapshot会把config.toml、hooks.json、skills/agents 目录中gsd-*内容还原到安装前字节级状态，并清理本次新建的目录）；
以清晰的错误中止安装，绝不打印Done!成功横幅。

这一点在 tests/bug-2760-codex-install-defensive.test.cjs 中有完整故障注入验证：分别模拟fs.renameSync抛错、临时文件写入抛错、以及校验器返回失败/抛错四种场景，逐字节断言用户安装前的[model] name = "o3"内容被原样恢复、无 GSD 块泄漏、无.tmp-*残留、且安装进程确实抛出异常。

给你的实操建议

如果你正在使用 Codex 且此前装过 GSD 旧版，rc.4 之后重跑一次安装即可触发上述"剥离 + 迁移 + 校验"的自愈路径；若遇到异常中止，请保留错误输出（其中会包含校验失败原因），并确认~/.codex/config.toml已被回滚到安装前状态——这正是新语义所保证的行为。

版本计划：rc 之后如何推进

按 rc.4 的发布计划：

若在最终定稿前仍有修复落地，会基于 release 分支再出 rc.5（后续实际发生，见 docs/RELEASE-v1.39.0-rc.5.md）；
当 RC 稳定后，执行发布工作流的finalize，把1.39.0提升到latest标签。

RC 序列本身就是 GSD 发布流程的一部分，社区用户可通过@next提前验证上述瘦身安装与 Codex 修复，再决定是否等待latest。

企业官网建设流程全解析