尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

gsd-core 更新检查缓存按包隔离与 get-shit-done-cc 遗留物自动清理实战指南

发布时间:2026/9/26 9:33:29

资讯中心
01
ARTICLE

gsd-core 更新检查缓存按包隔离与 get-shit-done-cc 遗留物自动清理实战指南

gsd-core 更新检查缓存按包隔离与 get-shit-done-cc 遗留物自动清理实战指南
【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载本篇指南聚焦 gsd-core 项目Git. Ship. Done — Core在包重命名迁移后的一项关键修复更新检查缓存从多包共享改为按包隔离 血缘lineage校验同时安装器内置了对旧包get-shit-done-cc遗留物残留 hooks、commands、skills 与过期缓存的自动检测与清理。读完本文你将理解永久性⬆ /gsd:update假升级提示的成因与修复原理掌握通过--dry-run安全预览清理计划、执行自动清理或手动回退的完整操作流程并能从源码与测试层面验证这一机制的可靠性。本文以仓库中该变更的 changeset 记录.changeset/archived/nimble-eagles-romp.md与配套操作文档 docs/cleanup-get-shit-done-cc.md 为主体结合 hooks/gsd-check-update.js、gsd-core/bin/lib/legacy-cleanup.cjs 等源码与 tests/legacy-cleanup.test.cjs 测试展开。背景包重命名引发的假升级问题从get-shit-done-cc到opengsd/gsd-coregsd-core 的前身包名为get-shit-done-cc。在包重命名为opengsd/gsd-core时仓库 issue #607版本计数器被重置旧包get-shit-done-cc已经发布到1.42.x而新包opengsd/gsd-core从1.2.0重新开始计数。这种版本号断崖本身没问题但它与旧的更新检查机制叠加后产生了一个长期困扰用户的 bug如果旧包仍以任何形式残留在某个运行时的配置目录中例如~/.gemini旧包的更新检查进程会把一个更高的latest版本写入所有包共享的更新缓存文件~/.cache/gsd/gsd-update-check.json而旧版本的新工具会无条件信任这份缓存中的写入。结果就是状态栏statusline永久显示一个并不存在的升级提示⬆ /gsd:update——用户明明已经安装了最新版opengsd/gsd-core却永远被告知有更新。问题机理共享缓存为何能被投毒从当前源码可以还原出旧机制的脆弱点更新检查由 SessionStart 钩子触发hooks/gsd-check-update.js 中定义缓存文件名并通过环境变量把缓存路径传给后台工作进程 hooks/gsd-check-update-worker.js。缓存目录是工具无关的共享目录~/.cache/gsd源码注释明确说明这是为了规避多运行时解析不一致——statusline 从一个运行时的缓存读、check-update 写到另一个运行时缓存的问题#1421。旧机制下缓存文件名固定gsd-update-check.json且缓存内容不携带写入者身份。任何安装在该机器上的、旧包的更新检查进程都可以往同一个文件里写读取端statusline、banner无法区分这条记录是哪个包写的于是一份来自get-shit-done-cc的高版本号记录被新包读取产生假升级提示。修复一更新检查缓存按包隔离并携带血缘字段这次变更PR #611对更新检查机制做了两处根治按包隔离的缓存文件名缓存文件名从固定的gsd-update-check.json改为按包命名的文件名。包身份的单一事实来源是 gsd-core/bin/lib/package-identity.cjs由 scripts/generate-package-identity.cjs 从package.json生成issue #498const cacheSlug opengsd-gsd-core; const updateCacheFileName gsd-update-check-opengsd-gsd-core.json;即当前包的缓存文件名是gsd-update-check-opengsd-gsd-core.json而旧包的gsd-update-check.json不再被新包读取。写入与读取两端都通过require(../gsd-core/bin/lib/package-identity.cjs)拿到同一个文件名常量保证写方与读方一致。变更前的 changeset 原文将这一点表述为per-package filenamegsd-update-check-slug.jsoncarrying apackage_namelineage field。值得注意的一个工程细节在插件市场直装 / git clone 后未执行构建的场景下package-identity.cjs作为 tsc 构建产物可能不存在#3582因此 hooks/gsd-check-update.js 与 hooks/gsd-check-update-worker.js 都做了降级处理——先尝试ensureRuntimeBuild()自建产物失败则回退到通用文件名gsd-update-check.json并保持写读两端一致而不是让 SessionStart 钩子崩溃。缓存记录携带package_name血缘字段读取端校验后台工作进程 hooks/gsd-check-update-worker.js 写入的缓存记录结构如下const result { update_available: latest isSemverNewer(latest, installed), installed, latest: latest || unknown, checked: Math.floor(Date.now() / 1000), stale_hooks: staleHooks.length 0 ? staleHooks : undefined, package_name: PACKAGE_NAME, };package_name字段即血缘标识。读取端不再盲目信任缓存而是先做校验。以可选的 SessionStart 横幅钩子 hooks/gsd-update-banner.js 为例// Lineage guard: package_name must be present and match this package. // Absent package_name means the cache predates lineage tracking — treat as untrusted. if (!cache.package_name || cache.package_name ! PACKAGE_NAME) return null;缓存中package_name缺失缓存早于血缘追踪机制产生→ 视为不可信不输出任何提示package_name存在但与当前包不匹配例如来自旧包get-shit-done-cc的记录→ 同样拒绝。这样一来任何其他包包括旧包get-shit-done-cc都无法再污染当前包的升级提示同时多运行时可见性得到保留同一个包在 15 个受支持运行时之间仍然共享同一份按包隔离的缓存。原子写入避免撕裂读由于缓存文件按包共享、可能被多个运行时的 statusline/banner 读取端并发解析工作进程在写入时采用原子发布#4091先写唯一同目录临时文件cacheFile.tmp-pid再renameSync到位——读者只会看到旧记录或新记录绝不会看到写了一半的撕裂内容。/gsd:update命令则会清空全部 15 个受支持运行时的缓存即删除按包命名的缓存文件让下一次会话重新评估。修复二安装器自动检测并清理旧包遗留物与缓存隔离配套安装器现在在每次安装时自动检测并移除旧包get-shit-done-cc遗留的构件。核心实现位于 gsd-core/bin/lib/legacy-cleanup.cjs设计遵循纯扫描函数 薄 IO 应用层的风格并通过opts.fs/opts.logger注入点实现无真实文件系统触碰的单元测试issue #607。扫描范围与判定规则planLegacyCleanup(configDirs, opts)对每个运行时配置目录执行三类扫描1.hooks/与commands/子树的内容引用扫描content-references-old-package仅扫描扩展名为.js/.cjs/.mjs/.sh的代码文件CODE_EXTENSIONS判定条件是文件内容包含旧包名字符串信号gsd-core-cc刻意排除Markdown、JSON、TOML、YAML 等文档/配置文件——因为它们可能在历史与引用语境中合法地提及旧包名例如 CHANGELOG.md扫描它们曾导致安装器误删刚安装好的gsd-core/CHANGELOG.md破坏安装同时刻意排除gsd-core/子树本身——当前包自己的基础设施CHANGELOG.md、本文件等就存放在那里安装时本就会被覆盖扫描它会造成自我删除误判。2.skills/gsd-*目录的过期路径引用扫描stale-get-shit-done-path旧版安装写出的 SKILL.md 文件中内嵌了指向旧运行时配置目录的路径例如$HOME/.codex/get-shit-done/workflows/docs-update.md#1453重命名后正确路径应为$HOME/.codex/gsd-core/workflows/docs-update.md残留的过期技能文件会被运行时错误拾取、破坏会话该扫描仅针对gsd-*前缀的 GSD 托管技能目录中的.md文件判定其内容包含/legacy/路径片段非gsd-前缀的用户技能目录一律不触碰。3. 旧共享缓存文件legacy-shared-cache即旧包写出的固定名缓存~/.cache/gsd/gsd-update-check.json在--config-dir重定向安装场景下扫描根改为重定向的 scope 根而非默认 home#3799避免误删仍在服役的安装的缓存。扫描结果按路径去重、确定性排序返回{ path, reason }[]计划。三处判定规则的源码注释还记录了数据丢失回归测试对应的历史教训见下文测试佐证。用户资产保护清理设计上有一条硬边界用户自有资产绝不触碰。isDevPreferencesPath()保证任何路径段为dev-preferences或文件名为dev-preferences.md的文件一律跳过用户自定义的 agents、非gsd-前缀的技能目录、以及任何不由 GSD 托管的文件都不在清理计划内。这与 docs/manual-update.md 中安装器仅干净地替换 GSD 托管目录的行为一致自定义 agent、commands/gsd/之外的命令、CLAUDE.md、自定义 hooks 均被保留。三步实操从预览到应用下面完整给出官方操作文档 docs/cleanup-get-shit-done-cc.md 的流程。适用场景状态栏持续显示⬆ /gsd:update提示而opengsd/gsd-core实际已是最新——即怀疑旧包遗留物仍在投毒更新提示。第一步预览清理计划--dry-run执行安装器并附加--dry-run即可看到将要发生的全部变更而不修改任何文件npx -y --packageopengsd/gsd-corelatest -- gsd-core --claude --global --dry-run命令会打印移除计划——每个文件路径及其删除原因——并列明将清除的过期更新缓存文件然后直接退出。从 bin/install.js 的 CLI 分发逻辑看--dry-run模式下cleanupLegacyGsdCc({ dryRun: true })是预览唯一事实来源它同时覆盖旧共享缓存与按包缓存两条路径的预览且--dry-run只预览遗留清理不预览--uninstall源码中有明确提示文案。若你使用的不是 Claude Code把--claude换成对应运行时的旗标即可完整旗标表见 docs/manual-update.md下表为该文档原文继承RuntimeFlagClaude Code--claudeOpenCode--opencodeKilo--kiloCodex--codexCopilot--copilotCursor--cursorWindsurf--windsurfAugment--augmentAll runtimes--all项目级安装请把--global换成--local。第二步执行自动清理确认预览结果无误后去掉--dry-run重跑同一命令npx -y --packageopengsd/gsd-corelatest -- gsd-core --claude --global安装器将依次完成在所有运行时配置目录~/.claude、~/.gemini、~/.codex、~/.config/opencode、~/.kilo等中检测旧包遗留构件移除孤儿 hooks、commands以及任何引用旧包名的代码文件判定规则见上文legacy-cleanup.cjs的CODE_EXTENSIONS与内容信号扫描移除skills/gsd-*下内嵌旧路径的技能文件stale-get-shit-done-path清除过期的共享更新缓存旧包写出的gsd-update-check.json同时清除当前包的按包缓存gsd-update-check-opengsd-gsd-core.json即updateCacheFileName使下次会话重新评估钩子版本保留用户自有资产dev-preferences.md、自定义 agents、以及任何不由 GSD 托管的文件。实现层面对删除操作也做了健壮性处理applyLegacyCleanup在 Windows 平台遇到EBUSY/EPERM常见于 Defender 扫描时最多重试 3 次、每次同步等待 100ms其余平台与非重试错误则立即停止gsd-core/bin/lib/legacy-cleanup.cjs。清理失败绝不会中止安装——安装器只记录警告并继续bin/install.js 中cleanupLegacyGsdCc的调用被 try/catch 包裹。第三步手动回退方案如果安装器在你的环境中无法解析get-shit-done-cc或你更倾向于手工清理可按以下步骤操作继承自 docs/cleanup-get-shit-done-cc.md逐个检查运行时配置目录中旧包留下的gsd-core/子树ls ~/.claude/gsd-core/ ls ~/.gemini/gsd-core/ ls ~/.codex/gsd-core/ ls ~/.config/opencode/gsd-core/ ls ~/.kilo/gsd-core/新包安装在相同路径下因此仅当该运行时尚未运行过新安装器时才删除这些由get-shit-done-cc写入的目录。卸载旧包若它仍然可解析npx get-shit-done-cc --uninstall删除过期的共享缓存rm -f ~/.cache/gsd/gsd-update-check.json说明以上命令属于用户在自己机器上的运维操作仓库本身为只读本文仅介绍查看与配置方式。第四步验证打开一个新终端会话或重启你的 AI 运行时状态栏中的⬆ /gsd:update提示应不再出现。可进一步确认安装版本npx opengsd/gsd-corelatest -- gsd-core --version注意在非 npm 安装 / 源码仓库直用的场景下官方手册 docs/manual-update.md 还提供了手工更新流程git pull --rebase→node scripts/build-hooks.js→node bin/install.js --claude --global→ 清除更新缓存其中第 4 步清除更新缓存使状态栏指示器复位与本文主题直接相关——新版安装器含按包缓存清理运行后这一手工步骤通常不再需要。源码与测试佐证关键的代码锚点关注点位置按包缓存文件名常量gsd-core/bin/lib/package-identity.cjsupdateCacheFileName、cacheSlug缓存写入端package_name血缘字段、原子写入hooks/gsd-check-update-worker.js缓存读取端血缘校验lineage guardhooks/gsd-update-banner.js多运行时配置目录检测hooks/gsd-check-update.js遗留清理扫描与应用gsd-core/bin/lib/legacy-cleanup.cjs安装器--dry-run分发与清理接入bin/install.js测试如何锁定行为tests/legacy-cleanup.test.cjs 使用真实临时目录端到端验证清理逻辑其中几个关键回归测试直接对应本变更的工程质量内容信号扫描hooks/下内容包含旧包信号的钩子文件被标记content-references-old-package内容干净的同名文件不被标记数据丢失回归#607用户自定义gsd-*.js/gsd-*.sh钩子只要不包含旧包内容就绝不进入清理计划——此前按名称匹配孤儿钩子的规则会误删用户钩子这是本次变更修复的核心数据丢失风险自我删除回归#607gsd-core/子树内的代码文件即使包含信号字符串也不被标记子树不扫描防止安装器自删Markdown 永不标记文档/配置文件合法引用旧包名时不得被删除防止误删新装的 CHANGELOG.md。此外tests/package-identity.test.cjs、tests/gsd-check-update-worker-platform-gate.test.cjs、tests/installer-migration-report.test.cjs 等测试分别覆盖包身份常量一致性、工作进程降级路径与安装器迁移报告输出共同构成对这一修复的守护网。小结gsd-core在 PR #611 中的这项变更从两个层面根治了包重命名带来的永久假升级问题更新检查缓存按包隔离并携带package_name血缘字段、读取端严格校验杜绝跨包投毒安装器内置旧包遗留物扫描清理并提供--dry-run预览让迁移残留自动、安全、可预期地被清除。对用户而言遇到⬆ /gsd:update假提示时一条带--dry-run的安装命令即可预览清理计划随后去掉--dry-run一键完成清理对开发者而言planLegacyCleanup/applyLegacyCleanup的纯函数 薄 IO 分层、明确的扫描边界与用户资产保护、以及针对历史数据丢失事故的回归测试都是可复用的工程范式。赞分享【免费下载链接】gsd-coreGit. Ship. Done - Core项目地址https://gitcode.com/gh_mirrors/ge/gsd-core点击查看免费下载相关推荐GSD Core 安装器迁移 003升级时安全清理遗留 get-shit-done/ 运行时目录的完整实现解析GSD Core 安装器迁移 003升级时安全清理遗留 get shit done/ 运行时目录的完整实现解析 GSD Coreopengsd/gsd cget-shit-done (GSD) Skill Surface 剪枝机制修复applySurface 在集群禁用时清除 ~/.claude/skills 下遗留的 gsd-*/ 目录get shit done GSD Skill Surface 剪枝机制修复applySurface 在集群禁用时清除 ~/.claude/skills 下遗人工智能AI 应用提示工程开发工具工作流自动化AI Agentgsd-core 工作流安装兜底提示迁移从废弃的 get-shit-done-cc 切换到 opengsd/get-shit-done-redux 安装命令gsd core 工作流安装兜底提示迁移从废弃的 get shit done cc 切换到 opengsd/get shit done redux 安装命令上一篇redis-py 的 Redis 模块命令使用指南Bloom、JSON、Search 与 TimeSeries 一站式实践下一篇Presentation创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

◈

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

◐

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

▲

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。