community-sweep

社区清理

通过吸纳更多人来壮大 claude-mem 社区。每项有价值的贡献都会以贡献者的名义合入：由他们提交 PR，并在 main 上将他们列为提交作者。PR 只有部分正确时，就在贡献者的分支上完善，而不是拒绝。Issue 也同样处理：报告 Bug 的人和修复 Bug 的人都会收到通知，并注明姓名。

本流程源自 2026-09-30 的开放 PR 集中处理：将 257 个开放 PR 减至 46 个，并合入 87 位作者的 143 个贡献者 PR，同时保留其作者署名。将流程记录下来，是为了让后续每批 PR 和 Issue 都按同样的方式处理。

所有者的合并理念

1. 尽可能合入有价值的贡献。 这比 Merge Clinic（#3372，docs/merge-rubric.md）的标准宽松。欢迎可选功能、可扩展性（提供商、宿主、钩子、设置选项），以及任何能减少 Token 消耗的改进（限制上限、批处理、去重、过滤）。
2. 完善，不拒绝。 如果意图正确，但修复不完整或有 Bug，就在贡献者的分支上完善，或者只合入其中的增补部分（精简）。无论哪种方式，功劳都归贡献者。
3. 不打补丁止痛，但也不放任问题恶化。 修复应追溯问题并解决根因。只有在附有书面后续计划、明确说明根因跟进工作且细化到可执行的情况下，才能发布用于制止当前用户受损的权宜修复。
4. 贡献者就是作者。 如果合并别人的工作时把维护者列为作者，这次合并就不合格。
5. 尊重托管服务的边界（步骤 2）。PR 不得改变 cmem.ai 云同步或网关登录和试用流程的行为。由你决定：精简或重做这部分并合入其余内容，或者说明理由后拒绝。
6. 安全和隐私方面的回归会阻止合并。 包括日志中的密钥、发送给第三方的数据，以及注入问题。
7. 关键 Bug 修复立即发布。 如果 PR 修复了用户正在遇到的问题，就应立即发布，不能让任何人的服务持续中断：登录或激活报错、worker 无法启动、钩子失效、采集或搜索停止工作、数据丢失。此类 PR 要在本轮处理中优先合入，随后发布补丁版本（步骤 3）。绝不能等待所有者，包括故障路径涉及 cmem.ai 登录、同步或网关的情况。步骤 2 的边界约束的是这些路径行为的变更，而非让它们恢复正常的修复。2026-11-07，#5455 修复每次安装时 Pro 登录都返回 500 的问题，却被错误地提交给所有者处理。
8. 没有任何事情需要所有者处理。 所有者于 2026-11-07 设定了这条规则。你要为每轮处理中的每个 PR 和 Issue 做出决定并跟进到底：合并、关闭、发布、发布 X 帖子。报告要说明你做了什么决定以及原因。绝不向所有者提问，也不列出供他们决定的事项。

统计真人，不统计工具。使用 Claude、Codex、Cursor 或 Copilot 编写的 PR，归功于提交 PR 的真人。机器人 PR（PostHog、Copilot agent、Dependabot）可根据实际价值合入，但绝不列入贡献者名单。

私有状态：绝不提交，绝不上传

运行状态保存在主检出目录中被 Git 忽略的 .scratch/ 下，因此所有工作树都共享此状态：

MAIN_CHECKOUT="$(cd "$(git rev-parse --git-common-dir)/.." && pwd)"
STATE="$MAIN_CHECKOUT/.scratch/community"
RUN_ID="CS-$(date -u +%F)"; RUN="$STATE/runs/$RUN_ID"; mkdir -p "$RUN"

文件	内容
$STATE/ledger.tsv	每个结果占一行。同一编号以最后一行为准。这是已发生事项的唯一可信来源；如果其中显示某个编号已完成，绝不要重做。
$STATE/ROSTER.md	所有提交已合并 PR 或获得共同作者署名的人员名单，供所有者联系使用。文件中包含电子邮件，因此绝不要提交、上传或引用它。
$RUN/	本次运行的快照、分诊报告、测试基线和 REPORT.md。

追加一行记录（以制表符分隔；PR 和 issue 编号共用同一编号空间）：

printf '%s\t%s\t%s\t%s\t%s\t%s\t%s\t%s\n' "$(date -u +%FT%TZ)" <number> "$RUN_ID" <action> <merge_sha|-> <author> <coauthors|-> "<one-line note>" >> "$STATE/ledger.tsv"

• PR 的操作：merged、closed、blocked、skipped；对于所有者的 PR，还包括 experimental 和 approved，其中 approved 由所有者写入，表示将 PR 移出实验状态。较早的运行也会写入 held，以及用于所有者签字确认的 approved。
• issue 的操作：issue-closed、issue-answered、issue-routed。较早的运行也会写入 issue-held。
• **新建记录文件：**如果 ledger.tsv 不存在，创建该文件，并添加表头 ts pr phase action merge_sha pr_author coauthors note（以制表符分隔）。

1. 盘点

gh pr list --repo thedotmack/claude-mem --state open --limit 500 --json number,title,author,isDraft,createdAt,updatedAt,mergeable,mergeStateStatus,maintainerCanModify,headRefName,headRepositoryOwner,baseRefName,additions,deletions > "$RUN/open-prs.json"
gh issue list --repo thedotmack/claude-mem --state open --limit 500 --json number,title,author,createdAt,updatedAt,labels,comments > "$RUN/open-issues.json"

根据最后一条记录，将每个开放的 PR 恰好归入一个类别。使用第一个符合条件的类别：

类别	规则	操作
实验中	这是所有者的 PR，最后一条记录为 experimental	暂不处理。报告任何新动态。
暂缓	最后一条记录为 held（在 2026-11-07 之前写入）	本次从头开始分诊，并像处理新 PR 一样自行处理完毕。
已批准	最后一条记录为 approved（所有者将其移出实验状态，或较早的运行记录了所有者的签字确认）	本次从头开始分诊，像处理新 PR 一样处理。
已阻止	最后一条记录为 blocked	仅在作者于该记录之后推送了更改或回复时重新分诊。
已完成	最后一条记录为 merged 或 closed	它不应处于开放状态，因此查明原因。
新建	没有记录	对其进行分诊（步骤 2）。

对于 issue，跳过由维护者创建的 issue：[plan-NN] 主 issue 和 Merge Clinic。对其他所有开放的 issue 进行分诊，包括：

• 没有记录的 issue，无论其存在多久（提前停止的运行会遗留这些 issue）；
• 最后一条记录为 issue-held（在 2026-11-07 之前写入）的 issue：本次从头开始分诊，像处理暂缓的 PR 一样处理；
• 在其最后一条记录之后有更新的 issue。

首次运行时，所有开放的 issue 都属于此范围。

测试基线。 每次运行只获取一次，并且要在合并任何内容之前获取。使用干净的 origin/main 工作树，并使用与 CI 相同的 Bun（bun-version: latest），因为较旧的本地 Bun 可能无法通过 CI 能通过的子进程测试。如果本地 Bun 版本落后，请在本次运行中的每个测试套件（基线、每个 PR 和门禁）中使用 npx -y bun@<latest> test …。npm view bun version 可查询最新版本。

npm install --no-audit --no-fund && npm run build
env -u CLAUDE_MEM_LLM_TIMEOUT_MS bun test tests > "$RUN/baseline-suite.log" 2>&1; echo "suite exit $?"
grep -E '^\(fail\)' "$RUN/baseline-suite.log" | sed -E 's/ \[[0-9.]+m?s\]$//' | sort -u > "$RUN/baseline-failures.txt"
tail -n 40 "$RUN/baseline-suite.log" | grep -E '^ *[0-9]+ pass$|^ *[0-9]+ fail$|^Ran [0-9]+ tests across'

最后一条命令必须输出测试套件自身的摘要：N pass、N fail 和 Ran N tests across M files，其中 M 应接近测试文件数量。如果没有任何输出，说明运行在完成前中断了（崩溃、超时、缺少依赖）；此时即使 baseline-failures.txt 为空，也不代表没有失败。请停止运行，修复原因，然后重新获取基线；绝不要基于不完整的基线合并 PR。单凭退出码非零并不代表上述情况：测试失败会导致非零退出，而且某些 Bun 版本会在打印摘要后于退出时崩溃。sed 会移除每项失败的耗时信息，使列表能够逐行比较。

2. 分类处理每个新 PR（只读）

gh pr view <N> --repo thedotmack/claude-mem --json title,body,author,headRefOid,headRefName,headRepositoryOwner,maintainerCanModify,mergeable,mergeStateStatus,isDraft,closingIssuesReferences,commits,files
gh pr diff <N> --repo thedotmack/claude-mem
gh pr checks <N> --repo thedotmack/claude-mem
gh api repos/thedotmack/claude-mem/pulls/<N>/comments --paginate   # inline review findings (Greptile, Cursor Bugbot, CodeRabbit)
gh api repos/thedotmack/claude-mem/issues/<N>/comments --paginate  # the conversation

使用 git show origin/main:<path> 阅读 main 中的代码。评估差异大小时，不要计入生成的 bundle（列表见第 3 步）；它们只会造成干扰，并会在合并时被剔除。如果 PR 对应某个计划主文档（plans/NN-*.md），请先阅读相应章节。实现主文档预期修复的 PR 是强有力的候选项。与主文档相矛盾的 PR 必须说明理由。

每个 PR 的证据：

• **事实：**作者、草稿状态、mergeable、maintainerCanModify、CI 状态、非 bundle 差异大小、关联的问题。
• **CI：**如果某项失败也出现在 main 最近的运行中（gh run list --repo thedotmack/claude-mem --branch main --limit 5），就不应归咎于该 PR。
• **根本原因和变更：**用一两行说明根本原因，以及 PR 做了哪些改动。
• **main 上是否仍需要？**引用 file:line 或提交作为证据。
• **审查发现：**尚未解决的机器人和维护者审查意见（P0/P1/P2），以及贡献者是否已处理。
• **质量：**添加的测试，以及这些改动是否只是权宜之计。
• 边界标记。
• **重叠：**同一领域的其他 PR，包括维护者的 PR。
• 结论和置信度。

结论（每个 PR 必须且只能选一个）：

结论	含义	后续处理
MERGE	正确、完整且方向一致；现在即可合并，或只需机械地将 main 合并进来	合并（第 3 步）。
MERGE+POSTPLAN	能缓解实际问题，但没有从根本上解决	合并，并在报告中写明后续计划。
REWORK	方向正确，但不完整、有缺陷或只是权宜之计	将编号列出的缺口作为规格说明。在贡献者的分支上完成修复（第 4 步），然后合并。
TRIM	只有部分改动属于增量贡献	在贡献者的分支上保留这部分，并以原 PR 合并。说明舍弃了哪些内容以及原因。
CONSOLIDATE→#M	与 #M 重叠	优先将增量部分作为独立的精简 PR 合并。否则，将其折入 #M 并注明贡献者（第 4 步）。
SUPERSEDED	main 已经解决了该问题	引用提交或 file:line。明确注明贡献后关闭。
BOUNDARY	按当前写法跨越了托管服务边界	在贡献者的分支上精简或重做，移除越界部分并合并其余内容；如果没有剩余内容，则说明原因并拒绝。
DECLINE	方向错误、有害、不值得完成，或没有实际改动（空操作）	亲自说明原因并致谢后关闭。绝不要把是否合并无用改动的决定交给提交者。
SPAM / EMPTY	与 claude-mem 无关，或没有代码。包括用他人信息重写 SECURITY.md、README 或 LICENSE，以及用工具生成的内容替换 CLAUDE.md 或 AGENTS.md	用一句中性的话关闭。

所有者自己的 PR（作者为 thedotmack）

所有者的 PR 与其他人的 PR 一样进行分类处理和合并。

• **实验性。**所有者会在台账中将 PR 标记为 experimental。在所有者通过写入 approved 行将其移出实验状态并归入 Approved 类别之前，该 PR 不纳入本轮处理；每次运行时，列出该 PR 上的任何新动态。
• 所有者自己的 PR 中的边界变更体现了所有者的意图，因此不会仅因这一点而被精简。检查它是否与 main 上已有的边界变更冲突，并自行解决任何冲突。
• **不发送感谢评论。**合并后，只有在我们做了改动时才发布 1–3 条要点，说明改了什么以及原因。不要将所有者添加到名单中。

托管服务边界（裁定 BOUNDARY）

claude-mem 是开源项目。cmem.ai 是托管服务：云同步，以及带有登录和试用期的推理网关。PR 不得按原样包含以下任何内容。删除或重做相关部分后合并其余内容，或者拒绝该 PR：

1. 更改安装程序的提供商界面或默认设置、让某个提供商免于登录，或更改 cmem.ai 的登录、试用期或激活步骤（src/npx-cli/commands/install.ts、src/npx-cli/cmem-memory-credentials.ts、src/npx-cli/cmem-pro-costs.ts）。
2. 让 cmem.ai 记忆密钥发送到网关以外的任何主机，或放宽网关检测（src/shared/cmem-gateway.ts、keysForEndpoint 锁定规则）。
3. 在网关自身的试用期到期回退机制运行之前，将网关的配额或密钥错误转给其他提供商（src/services/worker/provider-dispatch.ts）。
4. 删除、隐藏或默认关闭 cmem.ai 通知或链接：安装程序后续步骤、会话开始提示、上下文横幅、查看器标题，或续订通知。相关文案位于 src/shared/pro-promo.ts。
5. 增加其他同步、备份或远程记忆目标，或提供服务器运行时的一键式托管部署版本。
6. 更改云同步语义：造成数据丢失、弱化确认契约，或在没有授权的情况下同步（src/services/sync/、services/sync-api/）。
7. 增加默认启用且会消耗模型令牌的新路径，例如额外的观察器调用、回填或新的数据导入。相同功能若为默认关闭的可选项，则没有问题。

以下情况不属于冲突，应按其价值评判：选择启用的自带提供商、优先使用网关路径的主机和设置项；令牌消耗优化；对我们自己的同步客户端进行正确修复；IDE 和主机集成；以及对可自托管服务器运行时的修复。支持新的 IDE 或主机绝不是产品决策：目标是支持所有 IDE，因此新的适配器或 install --ide <host> 应按其价值评判，提出相关需求的问题也应予以肯定。新的提供商预设不得排在 cmem.ai 之上，也不得修改安装程序、登录或费用相关文件。修复损坏的边界路径（登录返回 500、同步停滞、网关调用崩溃）并不算更改边界：这是关键修复（理念 7），应予合并。如果修复也改变了该路径的行为（步骤、默认设置、通知或授权不同），则合并修复，并删除这些改动。如有疑问，应按不改变 cmem.ai 路径的方式理解并合并，同时在报告中说明你的决定。

仅限实时的观察器规则（绝不可按原样 MERGE）

本地观察器仅处理实时工作。所有者于 2026-11-03 确定了这条规则，main 分支上的 AGENTS.md 和 docs/architecture/observer-lifecycle.md 中包含完整约定。对涉及捕获、钩子暂存队列、SessionMessageBuffer、GeneratorExitHandler、getResumableSessionIds、中止类别、恢复计时器或提供商冷却时间的任何 PR 进行分流前，必须阅读这两份文档。

• 如果 PR 在配额不足、身份验证失败、停滞、服务中断或重启后保留、持久化、重新排队或自动恢复观察器推理任务，就违反了这条规则。这也包括根据“恢复证明”恢复任务，例如之后一次成功的存储操作、登录或配额重置。裁定为 REWORK，通过 discardBufferedWork 丢弃这些任务；如果没有其他内容，则裁定为 DECLINE。无论测试多么完善，都绝不可按原样 MERGE。
• 证明队列已清空的测试不算数。PR 必须证明服务中断不会导致之后发生无人要求的推理开销。
• 如果 main 分支上的代码与 AGENTS.md 矛盾，则不能以 main 分支的代码为准。仍留在 main 分支上的保留并恢复代码是待移除的缺陷。这不是扣留所有者移除该代码的 PR 的理由。#5383 于 2026-11-05 在违反此规则的情况下合并；2026-11-06，所有者的修复 #5347 又被错误地以“已被后续改动取代”为由扣留。

3. 以贡献者身份合并

在你自己的工作树中操作，绝不要使用用户当前的工作树：使用设置了 isolation: "worktree" 的 Agent，或运行 git worktree add --detach "$MAIN_CHECKOUT/.claude/worktrees/community-<name>" origin/main。然后运行 npm install --no-audit --no-fund。

gh pr view <N> --repo thedotmack/claude-mem --json state,isDraft,mergeable,baseRefName,headRefName,maintainerCanModify   # merged or closed meanwhile? ledger it `skipped`
gh pr edit <N> --repo thedotmack/claude-mem --base main          # only if the base isn't main
gh pr checkout <N> --repo thedotmack/claude-mem --branch pr-<N>  # sets the push remote to their fork
git merge --no-edit origin/main                                   # a merge commit; never rebase their commits

PR 绝不能提交生成的 bundle；它们会在发布时重新构建。生成文件集由 scripts/build-hooks.js 和 scripts/build-viewer.js 写入。如果下面的列表看起来已过时，请重新查看这两个脚本：

• plugin/scripts/{worker-service,server-service,mcp-server,context-generator,context-read-worker,work-view-read-worker,transcript-watcher,claude-mem-launcher,ensure-launcher}.cjs 及其 .map 文件；
• plugin/sqlite/**；
• plugin/ui/viewer-bundle.js、plugin/ui/viewer.html、plugin/ui/tv.html、plugin/ui/work-view/**（src/ui/my-work 的 Vite 构建产物），以及复制到 plugin/ui/ 的字体和图标；
• plugin/package.json；
• plugin/skills/request-progress/scripts/request-groups.mjs。

如果 PR 修改了其中任何文件，请使用 git checkout origin/main -- <paths> 将其还原（或对 PR 新增的文件运行 git rm），然后提交 chore: drop generated bundles (rebuilt at release)。如果 PR 只编辑了某个副本（例如 plugin/ui/viewer.html），请将修改移到 src/ 下对应的源文件中。plugin/ 下手写的文件保留：plugin/scripts/{bun-runner.js,statusline-counts.js,version-check.js,worker-wrapper.cjs,qoder-hook-launcher.cjs}、hooks、skills、modes 和 manifests。

落实评审结论。 MERGE 无需处理。对于 REWORK 和 TRIM，请按照差距列表（步骤 4）处理。我们的提交使用 conventional 提交消息，并以你的会话指定的署名 trailer 结尾。

在你将要合并的确切提交上进行验证：

1. 运行 npm run typecheck。
2. 先提交所有内容。然后运行 npm run build（bundle 大小防护检查），并保留其输出，供步骤 3–5 使用，以确保加载已构建 bundle 的测试运行的是 PR 代码，而不是 main 的代码。
3. 运行 PR 的定向测试。
4. 对于任何非简单变更，运行 env -u CLAUDE_MEM_LLM_TIMEOUT_MS bun test tests，并与 $RUN/baseline-failures.txt 对比。对于基线中没有的失败，先单独重新运行对应文件。如果单独运行和在 CI 中都通过，则说明是并行测试套件造成的负载问题。如果仍然失败，就由 PR 负责修复。
5. 如果涉及 openclaw/，运行 bun test openclaw。
6. 然后运行 git checkout -- plugin/ 和 git clean -fd -- plugin/，确保构建产物不会被提交。此操作也必须在之后进行任何提交前执行。仅运行 checkout 会留下未跟踪的产物，例如 plugin/scripts/work-view-read-worker.cjs 和 plugin/ui/work-view/assets/*。按文件名暂存文件，不要使用 git add -A。
7. 新增 SessionStore 迁移的 PR 应使用合并时 main 上下一个可用的 schema 版本。此次审查期间有两个 PR 抢用了同一个版本。

推送到他们的分支，但仅在你解决合并 main 时的冲突或添加了提交后才需要推送。绝不要强制推送。

remote=$(git config branch.pr-<N>.pushRemote || git config branch.pr-<N>.remote)
head=$(git config branch.pr-<N>.merge); head=${head#refs/heads/}
git push "$remote" "HEAD:$head"    # a bare `git push` is refused: the local name pr-<N> differs from their branch

如果推送因非快进而被拒绝，说明他们期间推送了新提交。运行 git pull --no-rebase "$remote" "$head"，重新验证并再次推送。如果他们的新提交已经包含了你的修改，请丢弃你的提交。

CI。

• 首次贡献者的运行会停留在 action_required 状态。请完整查看所有会在 CI 中执行的变更，包括工作流、package 脚本、postinstall，以及会调用 shell 的测试。然后批准该 PR head 上所有等待中的运行，但 Claude Code 除外：始终批准 CI 和 Windows；如果 PR 的路径会触发，还要批准 Media native runtime 和 Native ODS integration。请按 head SHA 查找：gh run list --branch 不会显示 fork PR。

  sha=$(gh pr view <N> --repo thedotmack/claude-mem --json headRefOid --jq .headRefOid)
  gh api "repos/thedotmack/claude-mem/actions/runs?head_sha=$sha" --jq '.workflow_runs[] | select(.conclusion=="action_required" and .name!="Claude Code") | "\(.id) \(.name)"'
  gh api -X POST repos/thedotmack/claude-mem/actions/runs/<id>/approve   # once per id listed
  

• 绝不要批准 SPAM 或 DECLINE 的 CI。

• 绝不要批准 “Claude Code” 运行。它们是 @claude 响应程序（.github/workflows/claude.yml）；它们会使用密钥，且合并不需要它们。

• 使用 gh pr checks <N> --repo thedotmack/claude-mem --watch --interval 60 监控。

• 对偶发失败重跑一次（gh run rerun <id> --failed）。修复真实失败。

• 如果草稿 PR 根据你的评审结论已准备就绪，运行 gh pr ready <N>。 每次合并一个 PR：

1. 运行 git fetch origin。

2. 如果 main 有更新，在本地试运行 git merge --no-edit origin/main，然后重新运行类型检查和该 PR 的目标测试。只有在合并需要解决冲突时才推送。

3. 合并：

   gh pr merge <N> --repo thedotmack/claude-mem --squash        # NEVER --admin, --body or --author-email
   git fetch origin && git log -1 --format='%H | %an <%ae> | %s' origin/main
   

   只有当 PR 标题可能造成误解时（例如 PR 经过精简或重新调整范围），才添加 --subject "<type>(<scope>): <summary> (#<N>)"。

main 上的作者必须是贡献者。如果不是，请停止合并，并在报告中将其记录为事故。然后发表评论（第 6 步），在台账中记录合并及完整 SHA，并关闭该 PR 修复但 GitHub 未自动关闭的任何问题（第 5 步）。

发布关键修复。 关键修复（理念 7）合并且 main 的 CI 通过后，使用 claude-mem:release 技能发布补丁版本。从 main 的全新工作树运行它（git fetch origin，然后运行 git worktree add --detach "$MAIN_CHECKOUT/.claude/worktrees/community-release" origin/main），绝不要在 PR 落地工作树中运行，因为其 HEAD 是 PR 分支。从 fetch 开始，直到发布提交和标签推送完成，一直持有 merge.lock，确保发布期间没有合并进入；之后释放锁并移除工作树。这是唯一允许持有超过 5 分钟的情况。不要等待运行结束或负责人回应。如果同一次运行中还有更多关键修复正在落地，请在最后一个修复合并后再发布一次。发布内容包括来自 @Claude_Memory 的 X 帖子（版本更新步骤 12）。可在任何时间发布，无需征求同意。发布后继续运行 claude-mem:childhood，直到已发布的软件包包含该修复。告知报告者哪个版本包含该修复（第 5 步）。非关键合并随下一次发布一起上线。

4. 帮助尚未就绪的 PR

• 在其分支上返工。 差距清单就是规格。在修复前会失败、修复后会通过的测试。推送时，在 PR 下发表评论，用 1–3 条要点说明更改内容及原因（“合并了 main；因为 Z，将 X 移到 Y；为 W 添加了测试”）。如果返工需要重新设计，不要只做一半就合并。发布友好的审查评论，说明具体计划，在台账中标记为 blocked，然后继续处理其他事项。
• 无编辑权限（maintainerCanModify=false）。发布审查评论，列出所需的具体更改，请对方启用“允许维护者编辑”，并在台账中标记为 blocked。
• 重新托管。 仅当没有编辑权限且 PR 无法按原样合并时：使用 git cherry-pick -x 将他们的提交挑选到 thedotmack/claude-mem 的一个分支上（这样可以保留他们的作者身份）。创建 <title> (rehost #<N>)，注明 @author，使用 gh pr merge --rebase 合并，并在原 PR 下致谢并附上链接后将其关闭。
• 纳入其他贡献者的工作。
  • 优先将重复内容作为独立的精简 PR 合并。只有在没有任何新增内容时才关闭 PR。
  • 如果确实要纳入，请运行 git fetch origin pull/<M>/head:pr-<M> 和 git cherry-pick -x <sha>。这样可以保留他们的作者身份，GitHub 还会在 squash 提交中添加 Co-authored-by。
  • 对于部分采纳，请在我们的提交说明中添加 Co-authored-by: <Name> <email from their commit>。
• 作者已重新联系的受阻 PR。 根据新的 head 重新进行完整分诊。

5. 问题

gh issue view <N> --repo thedotmack/claude-mem --json title,body,author,comments,labels,createdAt
gh pr list --repo thedotmack/claude-mem --state all --search "<N>" --json number,title,state,author,mergedAt
git log origin/main --oneline --grep="#<N>\b"

判定	测试	操作
FIXED	已合并的 PR 已修复该问题。在 main 上用 file:line 证明。	留言，然后运行 gh issue close <N> --reason completed。即使合并时已自动关闭，也要留言，因为自动关闭并不能说明任何情况。
HAS-PR	有一个未关闭的 PR 正在处理该问题。	本轮对该 PR 进行分流并合并，然后将问题标记为 FIXED 并关闭。如果 PR 暂时无法合并，留言一次附上链接，让报告者可以尝试处理。
PLAN	这是某个未关闭计划主问题的症状。	使用 oh-my-issues 技能的模式 2 进行分流：在主问题上留言 Round-N，然后按标准方式重定向。
CONFIRMED	main 上存在真实错误，且没有 PR。	回复根本原因（main 上的 file:line），并邀请对方提交 PR（“很乐意帮忙合并”）。或者，在我们自己的 PR 中修复并注明报告者。若问题中断服务（理念 7），不要等待贡献者：本轮就在我们自己的 PR 中修复并发布。
NEEDS-INFO	无法根据报告复现问题或确定其位置。	仅询问一次，明确指出缺少什么：版本、操作系统或日志行。
DUPLICATE→#M	与 #M 是同一个缺陷。	留言“Duplicate of #M”，然后以不纳入计划为由关闭。
PRODUCT	与计费、cmem.ai、路线图或产品有关的问题。cmem.ai 流程（例如登录后返回 500）中断不属于此类：这属于 CONFIRMED 或 HAS-PR，应作为关键修复处理。	根据文档、代码和记忆中所有者过往的决定自行回答，或将其转交给对应的计划主问题。
SPAM	与 claude-mem 无关。	留下一句中性的留言后关闭。

发布前，先核对各方说法。如果 PR 的分流结果与问题的分流结果对于如何修复问题意见不一（例如 project= 与 projects=），请自行阅读 main。切勿把功劳归给错误的人。

发布状态对报告者很重要。git tag --contains <sha> --sort=v:refname | head -1 会给出包含该修复的首个版本。如果没有标签包含它，请说“修复已在 main 上，将随下一个版本发布”。切勿承诺日期。

6. 留言

留言要热情、具体、简短：称呼对方，并用通俗易懂的话说明用户方面有什么变化。不要使用营销用语，也绝不要提及任何奖励、拓展联系或商业理由。以下是真实示例：

• 合并：“已合并，谢谢你 @Screddyice！Codex 钩子事件现在会保留 tool_use_id、agent_id 和 agent_type，因此工具调用可以正确去重，子 Agent 的捕获设置也同样适用于 Codex。我合并了 main，并没有加入 README 段落；README 仍作为面向用户的概览。”
  • 如果我们推送了更改，请说明改了什么以及原因。
  • 在确实如此时，具体称赞值得肯定之处：在 main 上失败的测试、实时测量结果或事先披露。
• **已推送返工：**用 1–3 个要点说明改了什么以及原因。
• **关闭（已被取代、合并或拒绝）：**感谢对方并链接已合并的内容。准确说明贡献归属（“你的提交已作为共同作者列入 #M”，或“main 已在 <sha> (#X) 中修复此问题”），并邀请对方继续贡献。
• 问题已修复：“已由 #4162 (6cec29395) 修复：SDK 子进程现在会保留 CLAUDE_CODE_TMPDIR，因此将其指向私有目录后，Observer 也可以正常工作。感谢 @reporter 提交报告，也感谢 @fixer 修复问题。”
• 垃圾内容：“正在关闭——此内容与 claude-mem 无关。”
• **所有者的 PR：**不必致谢。只需留言说明我们推送了什么。

7. 记录并报告

1. 台账。 每发生一次合并、关闭、暂缓、阻止、跳过或 issue 操作，就添加一行记录。

2. 名册。 将新合并的人类作者添加到 $STATE/ROSTER.md：登录名、公开姓名（squash commit 的作者）、PR 和短 SHA。添加来自 Co-authored-by trailers 的仅共同作者署名，然后重新统计总数。一个人可能有两个 git 身份；将它们映射到同一个登录名。

3. 门禁。 本轮最后一次合并后，在全新的 origin/main worktree 中验证：

   • 对照基线运行类型检查、构建和完整测试套件；
   • git log <run-start>..origin/main --format='%h %an %s' -- 'plugin/scripts/*.cjs' 'plugin/scripts/*.map' plugin/sqlite plugin/ui plugin/package.json plugin/skills/request-progress/scripts/request-groups.mjs CHANGELOG.md 中没有贡献者 PR。手写的 .cjs（如 worker-wrapper.cjs）可以，自有 UI 构建也可以。
   • git log <run-start>..origin/main --format='%an' | sort | uniq -c 显示有贡献者，而不只有维护者。

   若出现回归，先编写测试，再通过我们自己的 PR 向前修复。

4. 报告。 编写 $RUN/REPORT.md，然后在聊天中发布简短版本：

   • 一张结果表：| # | author | verdict | outcome | merge SHA | author on main | note |；
   • issue 操作；
   • 决策内容： 每项边界或产品决策，并用一行说明原因，以及实验性 PR 上的新动态；
   • 尚待履行的后续计划、跟进事项、事故；
   • 名册变更（新作者、新 PR、总数）。

扩大规模（PR 数量超过约 8 个）

• 使用只读子 Agent 并行进行分类，每个约处理 5 个 PR，并按领域分组。向每个子 Agent 提供此技能的第 2 步及其 PR 列表。它唯一可写的文件是 $RUN/triage/<group>.md，并应返回简洁的表格：| # | author | verdict | conf | one-line reason | canModify | mergeable | CI |。

• 使用执行子 Agent（isolation: "worktree"）按组并行落地，每组一个。合并到 main 时，必须通过锁串行执行：

  until mkdir "$STATE/merge.lock" 2>/dev/null; do sleep 20; done
  echo "<executor> #<N> $(date -u +%FT%TZ)" > "$STATE/merge.lock/owner"
  # … fetch, trial merge, gh pr merge, confirm author …
  rm -f "$STATE/merge.lock/owner"; rmdir "$STATE/merge.lock"
  

  锁最多持有 5 分钟（紧急修复发布除外，见第 3 步）。绝不要破坏他人的锁；如果锁已持有超过 20 分钟，告知协调者。

• GitHub API 配额共享： REST 和 GraphQL 的每小时配额均为 5,000 次请求。CI 轮询间隔不得短于 60 秒，将字段合并到一次 --json 调用中；遇到速率限制错误时，等待配额重置（gh api rate_limit），不要重试。

• 辅助脚本放在每个执行器自己的子目录中。 扫描期间，放在公共根目录的共享辅助脚本曾被其他执行器覆盖。

• 达到费用或使用量限制时，妥善停止： 释放锁，停止更改，并报告正在进行的事项。

• 留意磁盘空间： 每个 worktree 的 node_modules 约占 1 GB。运行结束后删除本轮的 worktree。

禁止事项

• 强制推送、rebase，或改写贡献者的 commit。
• 覆盖 squash 作者或正文：不得使用 --admin、--body 或 --author-email。
• 不要提交 PR 生成的 bundle 或 CHANGELOG.md。只能通过发布技能（第 3 步）升级版本或发布。
• 不要向所有者提问或把决策交给他们。自行决策、执行并报告。
• 不要在没有书面后续计划的情况下合并权宜修复。
• 不要批准自己尚未阅读过 diff 的 CI。
• 关闭 PR 时，必须准确说明其作者将如何获得署名。
• 不要在公开场合提及任何贡献者奖励或联络，也不要引用名册。