claude-mem 三发布分支策略main / core-dev / community-edge 的规划、落地与源码运行指南【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem本篇技术文章基于 claude-mem 仓库中的分支策略规划文档 plans/2026-07-05-three-release-branches.md完整还原该项目如何把三个一次性 PR 升级为三条长期发布线stable / core-dev / community-edge包括四条发布线对照表、变更流向设计、四个执行阶段建分支、写文档、接导航与 README、终验的具体命令与验证方式并结合 package.json 中的真实 npm scripts 与 scripts/sync-marketplace.cjs 源码讲清npm run build-and-sync如何在本地把非稳定分支装进 Claude Code 插件市场并重启 worker。读完你能掌握一条单维护者、低仪式的多发布线 Git 策略的完整落地路径以及从源码运行 claude-mem 非稳定分支的可复制命令链。一、规划背景为什么需要三条长期发布线claude-mem 是运行在 Claude Code 等 Agent 之上的持久记忆系统安装形态是npx claude-mem发布的 npm 包。规划文档开头明确了它的 Owner 与目标Owner: solo maintainer。Goal: turn the three plan PRs into three permanent release lines, document the strategy in one place, and give clone/run instructions for the non-stable lines.也就是说仓库里同时存在三个计划型 PR它们原本都是朝着main合入的一次性 PR维护者决定不合入main而是把其中两个 PR 的内容沉淀为两条永久分支再加上main本身构成三条长期发布线。这个决策针对的是典型的单维护者solo maintainer仓库治理问题既要有稳定的对外发布面又要有承载根因级可靠性修复和社区集成前沿的试验田且不能引入 CI 门禁、强制评审等重流程规划原文明确 No gates, no required reviewers — solo maintainer discretion。三条线对照表规划的 source of truth规划文档给出的核心表格是整篇文章的主干LineBranchForPublished to npm?StablemainEveryone. Thenpx claude-meminstall.Yes唯一发布线Core Devcore-devMaintainer testers wanting root-cause fixesNo — run from sourceCommunity Edgecommunity-edgeBleeding edge, integrated community PRsNo — run from source这张表定义了各条线的服务对象和分发方式后面所有阶段建分支、写文档、README 提示都是围绕它展开的。二、规划时已核实的事实基线Facts, verified 2026-07-05规划文档在动手前记录了一批已核实事实这是执行类文档的重要部分它让后续阶段的所有命令都有据可依PR #3141plan/stable-working-buildf6c7f51— basemain是 STABLE 的落点PR #3143plan/root-cause-holistic-fixesc81acee— 将成为core-dev分支PR #3142plan/community-bleeding-edgea20d1ac— 将成为community-edge分支当时 origin 上尚不存在core-dev/community-edge分支文档侧docs/public/*.mdx导航位于 docs/public/docs.json 的 Configuration Development 分组规划时约在第 79 行README 贡献章节约在第 374 行非稳定线的运行路径 clone git checkout branchnpm installnpm run build-and-sync。其中非稳定线运行路径这条事实可以直接在 package.json 中验证build-and-sync是一个真实存在的 script其定义为build: node scripts/sync-plugin-manifests.js node scripts/build-hooks.js node scripts/gen-plugin-lockfile.cjs, build-and-sync: npm run build npm run sync-marketplace node scripts/restart-marketplace-worker.cjs可见build-and-sync恰好串联了三步构建产物 → 同步到本地插件市场 → 重启市场 worker与规划文档中builds syncs to local marketplace restarts worker的注释完全对应。而规划文档特别要求不得虚构 npm script只允许引用真实存在的build-and-sync、release、release:patch|minor|major这些脚本在 package.json 中均可一一对应找到release: np、release:patch: np patch --no-cleanup等。三、Phase 0 决策点两个 PR 的命运执行前规划文档提出了一个关键决策PR #3143 和 #3142 本是合入main的 PR但现在它们的内容将变成永久分支合入就失去意义两个 PR 因此冗余。规划给出的推荐方案是从 PR head 创建分支推送后关闭这两个 PR并附一条重定向评论——Promoted to long-lived branchcore-dev/community-edge; this is now a permanent release line, not a merge-to-main.同时保持 PR #3141stable landing打开或按原计划合入。这一步体现了发布线策略中PR 与分支各司其职的边界stable 走 PR 合入流程edge 线走分支常驻流程。四、Phase 1创建并推送两条 edge 分支规划的 Phase 1 给出了精确到 SHA 的命令# 1. 从 PR #3143 head 创建 core-dev git branch core-dev c81acee39a771848bd30ee26e3c52ec26d713cd1 git push origin core-dev # 2. 从 PR #3142 head 创建 community-edge git branch community-edge a20d1ac44144d4749acfd68faceda2794f3187f0 git push origin community-edge # 3.按前述决策关闭 #3143 和 #3142附重定向评论验证方式也写明git ls-remote --heads origin | grep -E core-dev|community-edge确认两个 ref 都在期望的 SHA 上。这条验证命令的意义在于分支策略一旦发布分支存在于远端且指向正确 commit就是对外承诺的锚点之后所有从源码运行的操作都以远端 ref 为准。五、Phase 2编写分支策略文档 branches.mdxPhase 2 要求创建docs/public/branches.mdx并逐节规定了文档骨架copy this structure, dont inventFrontmattertitle: Release Branches加一行 descriptionThe three lines即上文三线对照表How changes flow规划原文的流向是——三条线都从main起步main向前forward-merge到core-dev与community-edge保持其新鲜度经过验证的修复通过普通 PR向后promote back down回到main。一句话流向、零流程仪式Which one should I use?普通使用选 stable想提前测试根因级可靠性修复选core-dev要最新社区集成且能接受粗糙边缘选community-edgeRun a non-stable line locally给出 clone → checkout →npm install→npm run build-and-sync的命令块并注明只有main发布到 npm所以npx claude-memlatest永远等于 stable回到 stable 的方法是git checkout main npm run build-and-syncReleasing维护者视角发布npm run release、tag、publish只从main发起edge 线永远从源码运行、永不发布。这一阶段最终在仓库中落地的成品即 docs/public/branches.mdx。对照规划可以看到两点演进其一成品文档把变更如何流动改写为向上晋升的表述——New runtime work enters as a PR tocore-devorcommunity-edge, notmain流向为community-edge - core-dev - main即运行时代码不再直接落main而是从 edge 逐级向上晋升规划稿中main 前向合并 修复向后晋升的描述是初始设计仓库中的最终文档以成品为准。其二成品文档还补充了两处规划中未展开的实操细节纯文档类变更可以放在updates/docs分支暂存就绪后合入main该分支不是运行时发布线Published Versions一节区分了 GitHub release/tag 与 npm publish 两件事GitHub tag 只是让源码归档可见真正让npx claude-memversion可解析的是 npm publish未来若引入 npm channel应使用core-dev、community-edge之类的 dist-tags在那之前非稳定分支一律从源码运行。六、非稳定线从源码运行的机制build-and-sync 拆解规划文档反复强调的运行命令是npm run build-and-sync它为什么能让checkout 某分支这件事真正生效结合仓库源码可以看清完整链路。6.1 sync-marketplace把当前分支镜像进插件市场scripts/sync-marketplace.cjs 的核心逻辑是把仓库根目录镜像mirror到本机 Claude Code 的插件市场目录~/.claude/plugins/marketplaces/thedotmack再镜像plugin/到版本缓存目录~/.claude/plugins/cache/thedotmack/claude-mem/version两处各执行一次bun install。由于镜像的源就是当前 checkout 出的分支插件运行目录里的代码随之变成该分支的代码——这就是从源码运行某条线的落点。脚本里还有一段与分支策略直接相关的防护逻辑scripts/sync-marketplace.cjs、L72-L83它读取已安装市场目录中的 git 分支名如果已安装插件处于非main分支即 beta 线直接sync-marketplace会拒绝并退出提示三个选项在 worker 端口对应的 UI 中更新 beta、先切回 stable 再同步、或显式使用npm run sync-marketplace:force强制覆盖。这段防误覆盖检查与规划中edge 线与 stable 共存于同一台机器的场景完全对应——同一台机器既跑 stable 又跑 edge 线时必须防止 stable 的同步动作把 beta 代码冲掉。镜像时排除的条目由 scripts/sync-marketplace.cjs 的BASE_EXCLUDES加上.gitignore行共同构成node_modules、lockfile、/workers等保证同步的是可直接运行的插件产物而非整个仓库。6.2 restart-marketplace-worker让运行中的插件切到新分支scripts/restart-marketplace-worker.cjs 很短确认市场目录存在否则提示先跑npm run sync-marketplace然后在~/.claude/plugins/marketplaces/thedotmack下执行npm run worker:restart。对应 package.json 中的worker:restart: bun plugin/scripts/worker-service.cjs restart。worker 是 claude-mem 的常驻后台进程负责转录监听、上下文生成等重启后加载的正是刚同步过去的分支代码checkout 分支 → 运行该分支的闭环至此完成。6.3 完整的非稳定线运行命令综合规划与 docs/public/branches.mdx可复制的命令序列为git clone https://gitcode.com/GitHub_Trending/cl/claude-mem.git cd claude-mem git checkout core-dev # 或 community-edge npm install npm run build-and-sync # 构建 同步到本地插件市场 重启 worker回到 stablegit checkout main npm run build-and-sync # 或直接重装已发布构建 npx claude-memlatest install运行环境前提以 package.json 的engines与 docs/public/branches.mdx 为准Node20.12.0、Bun1.0.0sync-marketplace在目标目录中执行的是bun install且本机已有 Claude Code 插件市场安装基础否则restart-marketplace-worker会因市场目录缺失而报错退出。七、Phase 3接入文档导航与 READMEPhase 3 要求在两处暴露分支策略的入口docs/public/docs.json在 Configuration Development 分组的pages数组中development之后加入branches并保持 JSON 合法。当前仓库中该分组页面数组已包含development后的branches条目docs/public/docs.json与规划一致README 贡献章节加一行指向 Release Branches 文档的说明。仓库中的 README.md 实际上有两处对应内容一是文档索引中的 Release Branches — Stable, core-dev, and community-edge branch flowREADME.md二是贡献章节中的 Claude-Mem ships from three branches:main(stable),core-dev, andcommunity-edge. Onlymainis published to npm; the others are run from source.README.md。验证方式同样具体node -e JSON.parse(require(fs).readFileSync(docs/public/docs.json,utf8))能干净退出README 链接可正常渲染。八、Phase 4终验清单与红线规划的收尾是一份可勾选的验证清单两条分支已推送且 SHA 正确git ls-remote验证docs.json可解析branches.mdx存在且已进导航README 已更新若已决策#3143、#3142 已附重定向评论关闭#3141 状态未变红线不要手改 CHANGELOG——CHANGELOG.md是自动生成的package.json 中有changelog:generate: node scripts/generate-changelog.js发布流程末尾会重新生成。这条红线在仓库中可以得到旁证CHANGELOG.md 中存在社区 edge 线的独立版本记录如## [13.10.3-community-edge.0] - 2026-07-09Community edge release for integrated batches 4-9以及13.10.2条目中 New Release Branches guide (main / core-dev / community-edge) with instructions for running the non-stable lines locally 的文档变更记录。这说明规划落地后edge 线的发布确实以独立 changelog 条目 源码运行的形态存在与edge 线永不发布 npm、只从源码运行的策略吻合。九、策略要点小结从这份规划文档与其落地痕迹可以提炼出几条对单维护者项目有直接参考价值的做法PR 升格为分支是低成本的多线发布手段不引入 release 分支保护规则、不打 CI 门禁靠分支名 npm 是否发布两个维度区分发布线对外承诺只有一行npx claude-memlatest恒等于main其余一切 edge 体验都通过checkout build-and-sync自助完成用户的回退成本是一条命令git checkout main npm run build-and-sync工具链把策略写进了代码scripts/sync-marketplace.cjs 中已装 beta 分支时拒绝非 force 同步的检查把stable 与 edge 线不能互相覆盖这条规则做成了运行时护栏而不是仅停留在文档约定每阶段都有机器可验证的验收命令git ls-remote过滤、JSON.parse校验、导航条目存在性使策略文档可被审计而不是只靠叙述。需要说明的适用边界上述分支流向、PR 编号与 SHA 均出自 2026-07-05 的规划快照其中main 前向合并到 edge 线的初始设计在最终发布的 docs/public/branches.mdx 中已演进为edge → core-dev → main 向上晋升的表述引用该策略时请以仓库中的 branches.mdx 为现行文档、以 package.json 的 scripts 为可执行事实。【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 claude-mem 三发布分支策略：main / core-dev / community-edge 的规划、落地与源码运行指南
claude-mem 三发布分支策略main / core-dev / community-edge 的规划、落地与源码运行指南【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem本篇技术文章基于 claude-mem 仓库中的分支策略规划文档 plans/2026-07-05-three-release-branches.md完整还原该项目如何把三个一次性 PR 升级为三条长期发布线stable / core-dev / community-edge包括四条发布线对照表、变更流向设计、四个执行阶段建分支、写文档、接导航与 README、终验的具体命令与验证方式并结合 package.json 中的真实 npm scripts 与 scripts/sync-marketplace.cjs 源码讲清npm run build-and-sync如何在本地把非稳定分支装进 Claude Code 插件市场并重启 worker。读完你能掌握一条单维护者、低仪式的多发布线 Git 策略的完整落地路径以及从源码运行 claude-mem 非稳定分支的可复制命令链。一、规划背景为什么需要三条长期发布线claude-mem 是运行在 Claude Code 等 Agent 之上的持久记忆系统安装形态是npx claude-mem发布的 npm 包。规划文档开头明确了它的 Owner 与目标Owner: solo maintainer。Goal: turn the three plan PRs into three permanent release lines, document the strategy in one place, and give clone/run instructions for the non-stable lines.也就是说仓库里同时存在三个计划型 PR它们原本都是朝着main合入的一次性 PR维护者决定不合入main而是把其中两个 PR 的内容沉淀为两条永久分支再加上main本身构成三条长期发布线。这个决策针对的是典型的单维护者solo maintainer仓库治理问题既要有稳定的对外发布面又要有承载根因级可靠性修复和社区集成前沿的试验田且不能引入 CI 门禁、强制评审等重流程规划原文明确 No gates, no required reviewers — solo maintainer discretion。三条线对照表规划的 source of truth规划文档给出的核心表格是整篇文章的主干LineBranchForPublished to npm?StablemainEveryone. Thenpx claude-meminstall.Yes唯一发布线Core Devcore-devMaintainer testers wanting root-cause fixesNo — run from sourceCommunity Edgecommunity-edgeBleeding edge, integrated community PRsNo — run from source这张表定义了各条线的服务对象和分发方式后面所有阶段建分支、写文档、README 提示都是围绕它展开的。二、规划时已核实的事实基线Facts, verified 2026-07-05规划文档在动手前记录了一批已核实事实这是执行类文档的重要部分它让后续阶段的所有命令都有据可依PR #3141plan/stable-working-buildf6c7f51— basemain是 STABLE 的落点PR #3143plan/root-cause-holistic-fixesc81acee— 将成为core-dev分支PR #3142plan/community-bleeding-edgea20d1ac— 将成为community-edge分支当时 origin 上尚不存在core-dev/community-edge分支文档侧docs/public/*.mdx导航位于 docs/public/docs.json 的 Configuration Development 分组规划时约在第 79 行README 贡献章节约在第 374 行非稳定线的运行路径 clone git checkout branchnpm installnpm run build-and-sync。其中非稳定线运行路径这条事实可以直接在 package.json 中验证build-and-sync是一个真实存在的 script其定义为build: node scripts/sync-plugin-manifests.js node scripts/build-hooks.js node scripts/gen-plugin-lockfile.cjs, build-and-sync: npm run build npm run sync-marketplace node scripts/restart-marketplace-worker.cjs可见build-and-sync恰好串联了三步构建产物 → 同步到本地插件市场 → 重启市场 worker与规划文档中builds syncs to local marketplace restarts worker的注释完全对应。而规划文档特别要求不得虚构 npm script只允许引用真实存在的build-and-sync、release、release:patch|minor|major这些脚本在 package.json 中均可一一对应找到release: np、release:patch: np patch --no-cleanup等。三、Phase 0 决策点两个 PR 的命运执行前规划文档提出了一个关键决策PR #3143 和 #3142 本是合入main的 PR但现在它们的内容将变成永久分支合入就失去意义两个 PR 因此冗余。规划给出的推荐方案是从 PR head 创建分支推送后关闭这两个 PR并附一条重定向评论——Promoted to long-lived branchcore-dev/community-edge; this is now a permanent release line, not a merge-to-main.同时保持 PR #3141stable landing打开或按原计划合入。这一步体现了发布线策略中PR 与分支各司其职的边界stable 走 PR 合入流程edge 线走分支常驻流程。四、Phase 1创建并推送两条 edge 分支规划的 Phase 1 给出了精确到 SHA 的命令# 1. 从 PR #3143 head 创建 core-dev git branch core-dev c81acee39a771848bd30ee26e3c52ec26d713cd1 git push origin core-dev # 2. 从 PR #3142 head 创建 community-edge git branch community-edge a20d1ac44144d4749acfd68faceda2794f3187f0 git push origin community-edge # 3.按前述决策关闭 #3143 和 #3142附重定向评论验证方式也写明git ls-remote --heads origin | grep -E core-dev|community-edge确认两个 ref 都在期望的 SHA 上。这条验证命令的意义在于分支策略一旦发布分支存在于远端且指向正确 commit就是对外承诺的锚点之后所有从源码运行的操作都以远端 ref 为准。五、Phase 2编写分支策略文档 branches.mdxPhase 2 要求创建docs/public/branches.mdx并逐节规定了文档骨架copy this structure, dont inventFrontmattertitle: Release Branches加一行 descriptionThe three lines即上文三线对照表How changes flow规划原文的流向是——三条线都从main起步main向前forward-merge到core-dev与community-edge保持其新鲜度经过验证的修复通过普通 PR向后promote back down回到main。一句话流向、零流程仪式Which one should I use?普通使用选 stable想提前测试根因级可靠性修复选core-dev要最新社区集成且能接受粗糙边缘选community-edgeRun a non-stable line locally给出 clone → checkout →npm install→npm run build-and-sync的命令块并注明只有main发布到 npm所以npx claude-memlatest永远等于 stable回到 stable 的方法是git checkout main npm run build-and-syncReleasing维护者视角发布npm run release、tag、publish只从main发起edge 线永远从源码运行、永不发布。这一阶段最终在仓库中落地的成品即 docs/public/branches.mdx。对照规划可以看到两点演进其一成品文档把变更如何流动改写为向上晋升的表述——New runtime work enters as a PR tocore-devorcommunity-edge, notmain流向为community-edge - core-dev - main即运行时代码不再直接落main而是从 edge 逐级向上晋升规划稿中main 前向合并 修复向后晋升的描述是初始设计仓库中的最终文档以成品为准。其二成品文档还补充了两处规划中未展开的实操细节纯文档类变更可以放在updates/docs分支暂存就绪后合入main该分支不是运行时发布线Published Versions一节区分了 GitHub release/tag 与 npm publish 两件事GitHub tag 只是让源码归档可见真正让npx claude-memversion可解析的是 npm publish未来若引入 npm channel应使用core-dev、community-edge之类的 dist-tags在那之前非稳定分支一律从源码运行。六、非稳定线从源码运行的机制build-and-sync 拆解规划文档反复强调的运行命令是npm run build-and-sync它为什么能让checkout 某分支这件事真正生效结合仓库源码可以看清完整链路。6.1 sync-marketplace把当前分支镜像进插件市场scripts/sync-marketplace.cjs 的核心逻辑是把仓库根目录镜像mirror到本机 Claude Code 的插件市场目录~/.claude/plugins/marketplaces/thedotmack再镜像plugin/到版本缓存目录~/.claude/plugins/cache/thedotmack/claude-mem/version两处各执行一次bun install。由于镜像的源就是当前 checkout 出的分支插件运行目录里的代码随之变成该分支的代码——这就是从源码运行某条线的落点。脚本里还有一段与分支策略直接相关的防护逻辑scripts/sync-marketplace.cjs、L72-L83它读取已安装市场目录中的 git 分支名如果已安装插件处于非main分支即 beta 线直接sync-marketplace会拒绝并退出提示三个选项在 worker 端口对应的 UI 中更新 beta、先切回 stable 再同步、或显式使用npm run sync-marketplace:force强制覆盖。这段防误覆盖检查与规划中edge 线与 stable 共存于同一台机器的场景完全对应——同一台机器既跑 stable 又跑 edge 线时必须防止 stable 的同步动作把 beta 代码冲掉。镜像时排除的条目由 scripts/sync-marketplace.cjs 的BASE_EXCLUDES加上.gitignore行共同构成node_modules、lockfile、/workers等保证同步的是可直接运行的插件产物而非整个仓库。6.2 restart-marketplace-worker让运行中的插件切到新分支scripts/restart-marketplace-worker.cjs 很短确认市场目录存在否则提示先跑npm run sync-marketplace然后在~/.claude/plugins/marketplaces/thedotmack下执行npm run worker:restart。对应 package.json 中的worker:restart: bun plugin/scripts/worker-service.cjs restart。worker 是 claude-mem 的常驻后台进程负责转录监听、上下文生成等重启后加载的正是刚同步过去的分支代码checkout 分支 → 运行该分支的闭环至此完成。6.3 完整的非稳定线运行命令综合规划与 docs/public/branches.mdx可复制的命令序列为git clone https://gitcode.com/GitHub_Trending/cl/claude-mem.git cd claude-mem git checkout core-dev # 或 community-edge npm install npm run build-and-sync # 构建 同步到本地插件市场 重启 worker回到 stablegit checkout main npm run build-and-sync # 或直接重装已发布构建 npx claude-memlatest install运行环境前提以 package.json 的engines与 docs/public/branches.mdx 为准Node20.12.0、Bun1.0.0sync-marketplace在目标目录中执行的是bun install且本机已有 Claude Code 插件市场安装基础否则restart-marketplace-worker会因市场目录缺失而报错退出。七、Phase 3接入文档导航与 READMEPhase 3 要求在两处暴露分支策略的入口docs/public/docs.json在 Configuration Development 分组的pages数组中development之后加入branches并保持 JSON 合法。当前仓库中该分组页面数组已包含development后的branches条目docs/public/docs.json与规划一致README 贡献章节加一行指向 Release Branches 文档的说明。仓库中的 README.md 实际上有两处对应内容一是文档索引中的 Release Branches — Stable, core-dev, and community-edge branch flowREADME.md二是贡献章节中的 Claude-Mem ships from three branches:main(stable),core-dev, andcommunity-edge. Onlymainis published to npm; the others are run from source.README.md。验证方式同样具体node -e JSON.parse(require(fs).readFileSync(docs/public/docs.json,utf8))能干净退出README 链接可正常渲染。八、Phase 4终验清单与红线规划的收尾是一份可勾选的验证清单两条分支已推送且 SHA 正确git ls-remote验证docs.json可解析branches.mdx存在且已进导航README 已更新若已决策#3143、#3142 已附重定向评论关闭#3141 状态未变红线不要手改 CHANGELOG——CHANGELOG.md是自动生成的package.json 中有changelog:generate: node scripts/generate-changelog.js发布流程末尾会重新生成。这条红线在仓库中可以得到旁证CHANGELOG.md 中存在社区 edge 线的独立版本记录如## [13.10.3-community-edge.0] - 2026-07-09Community edge release for integrated batches 4-9以及13.10.2条目中 New Release Branches guide (main / core-dev / community-edge) with instructions for running the non-stable lines locally 的文档变更记录。这说明规划落地后edge 线的发布确实以独立 changelog 条目 源码运行的形态存在与edge 线永不发布 npm、只从源码运行的策略吻合。九、策略要点小结从这份规划文档与其落地痕迹可以提炼出几条对单维护者项目有直接参考价值的做法PR 升格为分支是低成本的多线发布手段不引入 release 分支保护规则、不打 CI 门禁靠分支名 npm 是否发布两个维度区分发布线对外承诺只有一行npx claude-memlatest恒等于main其余一切 edge 体验都通过checkout build-and-sync自助完成用户的回退成本是一条命令git checkout main npm run build-and-sync工具链把策略写进了代码scripts/sync-marketplace.cjs 中已装 beta 分支时拒绝非 force 同步的检查把stable 与 edge 线不能互相覆盖这条规则做成了运行时护栏而不是仅停留在文档约定每阶段都有机器可验证的验收命令git ls-remote过滤、JSON.parse校验、导航条目存在性使策略文档可被审计而不是只靠叙述。需要说明的适用边界上述分支流向、PR 编号与 SHA 均出自 2026-07-05 的规划快照其中main 前向合并到 edge 线的初始设计在最终发布的 docs/public/branches.mdx 中已演进为edge → core-dev → main 向上晋升的表述引用该策略时请以仓库中的 branches.mdx 为现行文档、以 package.json 的 scripts 为可执行事实。【免费下载链接】claude-memPersistent Context Across Sessions for Every Agent – Captures everything your agent does during sessions, compresses it with AI, and injects relevant context back into future sessions. Works with Claude Code, OpenClaw, Codex, Gemini, Hermes, Copilot, OpenCode More项目地址: https://gitcode.com/GitHub_Trending/cl/claude-mem创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考