合仓后仓库优化 —— 阶段 4 及尾项交接

本文件只装交接 prompt，不是第二份方案。方案与判据的唯一真相源 = post-merge-repo-optimization-plan.md （台账在它的 §1，任务正文在 §3）。这里只回答一件事：下一个会话该拿什么开工。
状态以那份计划的 §1 台账为准（本文件写作时 9/13；2026-08-30 会话 A 做完 T4-4/T4-1/T4-3 后为 12/13，只剩 T4-2，commit cbb7855f / 9f07d693 / ad92ec4a）。修改时间以 git log -1 -- docs/plans/post-merge-phase4-handoff.md 为准。
用完即弃：阶段 4 做完后本文件随主计划一起归档进 docs/plans/archive/。
✅ 2026-08-30 已归档（会话 B 做完 T4-2，13/13 全绿）。本文件与主计划同批移入 archive/。 ⚠️ 会话 B 的实际结果与下面第 3 节写的 prompt 不同：T4-2 改判为不重写 git 历史，走 docs-governance-plan.md P5 自带的降级出口（仅工作树删除 + archive README 标注）。理由（ROI 从 10% 掉到 2.3% + 两处 P5 没算的代价）见主计划 §3 T4-2 的完成记录。下面各节是交接当时的 prompt 原文，保留不改。

1. 会话怎么分

会话隔离规则（CLAUDE.md §9）在这里一条都不触发 —— 四项都不需要 Flutter，验收全是根侧脚本。拆会话的理由只有两条：风险隔离（T4-2）与上下文预算。

会话	内容	为什么这么分
A ✅ 2026-08-30	T4-4 → T4-1 → T4-3	三项同质（文档卫生）、同一套验收（`check-doc-links`）、互不依赖。顺序由小到大，前两项会先把 `docs/README.md` 的耦合暴露出来
B	只做 T4-2	重写 git 历史 + 双远端强推，计划明令「不与任何改动同批」。做完所有旧 clone 都要重拉，故排在 A 之后
C	阶段 3 尾巴四条（登记在台账 T3-1 结论段，非独立编号）	全是 CI 设计题，不阻塞任何东西，最低优先

2. 开工前要先定的四件事（2026-08-30 从两件扩到四件）

rvh/pubspec.lock 那处与本计划无关的既有改动 —— B 的前置是「工作树干净」，它必须先提交或丢弃。A 会话已照旧绕开它（git commit <pathspec>），到 B 这里绕不过去了。

🔴 T4-2 的第一步不是执行，是重做 ROI 决策（2026-08-30 实测后新增，排在下面第 3 条之前）。 P5 的算式是「.git 共 72 MB，删 7.6 MB 回收约 10%」，分母已经不成立：

	P5 写的（2026-08-14）	2026-08-30 实测
`.git` 总量	72 MB	328 MB（pack 151.13 MiB + 松散 175.65 MiB / 4884 对象，未 gc）
目标文件 pack 后	7.6 MB	7,941,186 B（属实；全历史仅 1 个 distinct blob）
回收比例	约 10%	约 2.3%（对 gc 后的 pack 也只有 ~5%）
真正的大头	「预装词库单个 blob 16 MB」	预装库 98 个 distinct blob，pack 后合计 88.9 MB —— 合仓把 RVH 的历史一并带了进来

P5 自己留了逃生口：「若届时觉得 10% 不值这个风险，可降级为仅从工作树删除 + archive README 标注，前四个阶段完全不受影响」。在 2.3% 这个数上，那个逃生口从备选变成主选。 B 会话必须把两条路摆给用户选，不许默认执行重写。

选了重写之后，才轮到补方案。 T4-2 正文写着「重写历史会让所有 tag 的 SHA 变化，红线 #11 的 shipped_migrations.txt 真相源是发布 tag，动手前必须确认这一点已被 P5 覆盖；该方案写了就照做，没写就先补上再动」。 2026-08-30 已核实：docs-governance-plan.md P5 没有 tag 那一段 （只有 filter-repo 命令 + remote 重加）。所以 B 会话先补 P5，再执行。
⚠️ P5 的「git-filter-repo 未安装」也已过期 —— 2026-08-30 实测已装在 /usr/local/bin/git-filter-repo，前置少一条。

3. 交接 prompt（复制即用）

会话 A —— T4-4 / T4-1 / T4-3

接手 docs/plans/post-merge-repo-optimization-plan.md 的阶段 4，本次做三项：
T4-4（归档 mcp-primer.md）→ T4-1（了结 docs-governance-plan.md）→ T4-3（两份 backlog 分片）。
T4-2 不在本次范围——它要重写 git 历史，计划明令必须单独做。

先读该计划的 §2 冷启动开工指引 + §1 台账 + 阶段 4 前言 + T4-4 / T4-1 / T4-3 三节正文。
阶段 0/1/2/3 已全部完成（台账 9/13），三项均无前置。

【顺序写死】每项：做完 → 跑验收 → 回写 §1 台账 → 单独提交，之后才开下一项。
三项【绝不能同一个 commit】。

四个容易翻车的点：

① 计划里的数字是 2026-08-29 快照，【现场重数】。已知已经漂了的：
   - mcp-primer.md 正文写「全仓只有 1 处引用且在归档件里」——现在是【3 处】，
     因为 2026-08-29 新建的 docs/README.md 引用了它（下面 ② 就是这条的后果）。
   - 根 backlog 现在 255,267 B / 72 个顶层条目 / 只有 4 条 `## ✅`（正文写 5+）。
   - rvh/docs/plans/backlog.md 114,644 B / 35 条，其中【18 条是 ✅】——
     清理面比正文描述的大得多，正文只盯了根侧。
   - rvh/docs/plans/ 仍是 29 份 plan、无 archive/ 目录（与正文一致）。

② 【新增耦合，计划里没写】：2026-08-29 新建了 docs/README.md（根层文档索引）与
   scripts/README.md。T4-4 把 mcp-primer.md 移走之后必须回来改 docs/README.md：
   标题与 §1 的「13 份」要变 12 份、删掉那一行、子目录表里 archive/ 那行可提一句。
   T4-3 分片 backlog 之后，docs/README.md §2 里「两份 backlog」的说法也要跟着改。
   不改就是索引说假话——那正是这份索引本身要治的病。

③ T4-1 归档 docs-governance-plan.md 会【当场造悬挂引用】：post-merge 计划自己
   在 T4-2/T4-3 里引用它（docs-governance-plan.md 的 P5 / P1.5）。归档后这些指针
   要补 archive/ 前缀，否则 check-doc-links 直接红。归档前先 grep 一遍引用点。

④ T4-3 动作④「跨端条目定一个单一落点」是【决策不是搬运】，做之前先把根侧
   backlog 里标着「RVH 新会话」的条目列出来给我看，再决定落点。别默默搬。

验收（每项做完各跑一次）：
- node scripts/check-doc-links.mjs 绿
- node scripts/check-claude-md-paths.mjs docs/README.md scripts/README.md 绿
  （这两份没进 package.json 的 check:claude-paths 清单，是刻意的，别加进去）
- T4-3 额外：两份 backlog 里 `## ✅` 条目数为 0
- T4-4 额外：docs/archive/README.md 有新条目

三条纪律：
① 工作树里 rvh/pubspec.lock 有一处与本任务无关的既有改动，别带走；
   提交一律用 git commit <pathspec> 绕过 index。
② 本计划刻意不含红线锁标记（/arch-check S28 基线 = 4），别往里加。
③ 不要改 docs/plans/archive/ 与 docs/cross-end/ 里的历史记述。

省 token：全程走 Bash（sed / python3 heredoc）读写文件，别用 Read / Edit。

会话 B —— T4-2（独占，A 已完成，等工作树干净）

🔄 2026-08-30 重写：原稿的三个事实已过期（git-filter-repo 未安装 / .git 72 MB / 回收 10%），照原稿开工会按一个不成立的 ROI 直接动手重写历史。现场实测见 §2 第 2 条。

接手 docs/plans/post-merge-repo-optimization-plan.md 的 T4-2 —— 阶段 4 最后一项，
也是全计划唯一剩下的 ⬜（12/13 已完成）。【本次只做这一项】，计划明令它不与任何改动同批。

先读 §2 冷启动开工指引 + 阶段 4 前言 + T4-2 正文 +
docs/plans/archive/docs-governance-plan.md 的 P5（完整步骤在 P5，T4-2 只是执行它
——别在 T4-2 里重写第二份方案。注意该文件 2026-08-30 已归档，在 archive/ 下）。

【第一步不是执行，是重做决策】。P5 的 ROI 算式基于「.git 共 72 MB，删 7.6 MB
回收约 10%」，而 2026-08-30 实测已经不成立：
  - .git 现 328 MB（pack 151.13 MiB + 松散 175.65 MiB / 4884 对象，未 gc）
  - 目标文件 docs/archive/rvh-schema-export/04-vocabulary-data.sql
    raw 22,289,665 B，全历史仅 1 个 distinct blob，pack 后 7,941,186 B
  - 真正的大头是预装库：98 个 distinct blob，pack 后合计 88.9 MB（合仓把 RVH
    的历史也带进来了），而那是红线 #10 要求保留的必需资产
  ⇒ 实际回收约 2.3%（对 gc 后的 pack 也只有 ~5%），不是 10%。
P5 自己写着「若届时觉得 10% 不值这个风险，可降级为【仅从工作树删除 + archive
README 标注】，前四个阶段完全不受影响」。请先把这两条路摆出来给我选，别默认执行
重写。代价一侧照 P5 原文：全部 commit SHA 重写 + 双远端强推 + 任何已有 clone 作废。

【如果我选了执行重写，第二步仍是补方案不是动手】：T4-2 正文写着「重写历史会让所有
tag 的 SHA 变化，红线 #11 的 shipped_migrations.txt 真相源是发布 tag，动手前必须
确认这一点已被 P5 覆盖；写了就照做，没写就先补上再动」。
2026-08-30 已核实：【P5 没有写 tag 那一段】（只有 filter-repo 命令 + remote 重加）。
补的那段至少要回答：
  - filter-repo 会不会一并改写 tag、tag 名是否保留（本仓 11 个 tag，含
    pre-rvh-merge / v0.1.0-dev.9 / v0.1.0-dev.10）；
  - 双远端的 tag 怎么强制同步（github=git@github.com:ttfishnet/lampio.git，
    origin=https://gitee.com/ttfishnet/lampio.git）；
  - 补完跑一次 bash scripts/migration-verify.sh 验 D4 —— D4（第 189 行起）就是拿
    发布 tag 当「野外真实存在什么」的真相源，是这条风险的现成探针。
补进 P5（archive/docs-governance-plan.md），不要写在 T4-2 里。

前置（逐条确认，缺一不做）：
- 双远端已同步。⚠️ 2026-08-30 会话 A 结束时本地有 4 个未推送 commit
  （HEAD=55dd9402，github/main=origin/main=44d09363）——现数一次，若仍未推，
  先 git push github main && git push origin main 再往下走。
- git status 干净。⚠️ rvh/pubspec.lock 有一处与本计划无关的既有改动 —— 它必须先
  被处理掉（提交或还原，问我），因为 filter-repo 要求工作树干净，这次绕不过去。
- 无其他会话在动这个仓：git worktree list（2026-08-30 时只有主树）。
- git-filter-repo 【已安装】在 /usr/local/bin/git-filter-repo，P5 写的「未安装」已过期。

回滚准备（动手前必须做，照合仓 T3-1 的做法）：
  git bundle create ~/Backups/lampio-prefilter-$(date +%Y%m%d).bundle --all
  并【实际 clone 一次验证它能还原完整历史】，再打一个 pre-filter-repo tag。

验收：P5 自带清单 + git log --oneline | wc -l 前后一致 + git fsck 无错 +
.git 体积前后对比（记得先 git gc，否则 175 MiB 松散对象会让对比失真）+
bash scripts/migration-verify.sh 的 D4 绿。
做完回写 §1 台账（写清 filter-repo 前后的 .git 体积与 HEAD SHA），
阶段 4 全绿后按计划把 post-merge-repo-optimization-plan.md 与本文件
一起归档进 docs/plans/archive/。

三条纪律：
① 本计划刻意不含红线锁标记（/arch-check S28 基线不变），别往里加。
② 不要改 docs/plans/archive/ 与 docs/cross-end/ 里的历史记述 ——
   例外只有 P5 那一段补充（T4-2 正文明令要补进 P5）。
③ 提交一律用 git commit <pathspec> 绕过 index。

省 token：全程走 Bash（sed / python3 heredoc）读写文件，别用 Read / Edit。

会话 C —— 阶段 3 尾巴（最低优先，随时）

接手 docs/plans/post-merge-repo-optimization-plan.md 阶段 3 留下的四条尾巴，
它们登记在 §1 台账的 T3-1 结论段里（不是独立编号任务）。按性价比排序，可只做前两条：

1. release-verify.sh 拆网络段与静态段。现状：它静态检查处数最多，但 SKIP 数是
   网络可达性的函数（同机同码连跑两次 SKIP = 4 / 11），钉任何 --max-skip 基线都会
   得到一道随网络天气变红的门。R1-R4 那批是零网络的，拆出来才谈得上接 ci-verify.yml。
   它的 --max-skip 支持与「RB_PROXY= 空串 = 直连」修复【已经就位】，别重做。
2. 给 ci-verify.yml 配 paths 触发面。T3-1 刻意没配（免得与 T3-3 的触发效果混在一起），
   T3-3 已完成，现在可以配了。参照 ci-cross-end.yml 的写法。
3. privacy-verify.sh 改走 schedule（定时任务）而不是 commit 触发。理由已实测：
   它无凭据时那 7 条 PASS（P8-P13）全是打 admin.lampio.app 的线上 HTTP，
   验的是「已部署的站点」不是「这次改动」；按 commit 触发 = 让第三方 uptime 决定 CI 红绿。
4. check:readme-paths：docs/README.md 与 scripts/README.md 的路径校验目前只能手工跑，
   刻意没掺进 check:claude-paths（那条命令的语义是「CLAUDE.md 家族」）。
   要常态化需要一条新命令，或让 check-claude-md-paths.mjs 支持第二个文件集。

硬要求：任何新接的闸门都必须带防全 SKIP 假绿机制（--max-skip=N），且
   【反向注入实测】——故意注入一个缺陷要能让它变红，本机就能做，不依赖 push。
硬要求：量「哪些检查不依赖凭据」时必须【先把 gitignored 的 admin/.env.local 藏起来】。
   脚本会 set -a; . 它（里面有 service_role + anon key），不藏的话本机沙箱里
   一大片「看起来是静态」的检查其实在拿本机凭据读线上库——2026-08-29 就因此
   把 ops-verify 误判成最佳候选（藏前 PASS=19，藏后 PASS=0）。
   同理要剥掉 psql / gh / Keychain(security) 与 $HOME。

合仓后仓库优化 —— 阶段 4 及尾项交接 ​

1. 会话怎么分 ​

2. 开工前要先定的四件事（2026-08-30 从两件扩到四件） ​

3. 交接 prompt（复制即用） ​

会话 A —— T4-4 / T4-1 / T4-3 ​

会话 B —— T4-2（独占，A 已完成，等工作树干净） ​