交付出件箱

← 返回出件箱

门店手机端视光档案线 · 发生产 MR 清单(调查稿 · 未发版 · v2 已按长官补的三条要求修订)

调查时间:2026-09-17
调查范围:origin/test / origin/main 全部真实 git 历史 + sudo db-prod 只读查生产库 +
scripts/release_main.py status/plan 只读子命令真跑(不写 Git/Codeup)
调查人:执行层(sonnet)· 只调查整理,未执行任何发版/写操作

v2 修订说明:长官补了三条要求 —— ①清单只放 feature/store-mobile-refractive-archive
自己的 MR,root 的 #698 单独标"依赖项"不混进清单,但要 verify 会不会带别人提交 ②对照历史发版
经验逐条排查 ③把 root 9-16 口信要点对进清单。本版已按此重写第1、4节,新增第5、6两节。

1 · test MR 全清单(仅 feature/store-mobile-refractive-archive 自己这条线)

查法:git log --merges origin/test --grep="store-mobile-refractive" -i,命中 11 条,其中 1 条是
Merge remote-tracking branch 'origin/test' into feature/...(把 test 合回功能分支的反向合并,
不是 MR,已排除),剩 10 个真实 MR,按合并时间升序:

这 10 个是本次发版清单的全部主体,共 34 个非 merge commit(release_main.py plan 实跑核实,
见第5节)。

🔴 依赖项(不属于本清单,但发布时必须一并点名)

MR #698(root · feat/phase81-refractive-4l-grounding 分支 · 09-16 17:41:54 合并 502764dd,
标题「Phase 81.8 示范档案 4L 新口径冻结迁移 + 平板 UAT 截图存证」)——只带一个纯数据迁移
phase81_001_demo_profile_refresh.py(冻结示范档案6条AI分析文案为4L新口径)+ 文档/截图,
不含任何业务代码改动。它被夹在我们的 #697 和 #700 之间,原因是我们 #700 里的
demo_profile_data_fix3 迁移的 down_revision 改挂到了 phase81_001(见 #700 那行的"迁移链修正")
—— 这条依赖关系是我们自己代码里写死的,不是 root 强加的。

时间窗内 root 同一分支还有 #692(09-16 00:54)和 #696(09-16 16:36)两个 MR,均无迁移文件、
纯代码/prompt 改动 —— 这两个不在依赖链上,不需要跟着发(第6节详述 root 口信落点)。

2 · 迁移文件落在哪个 MR(逐条 git merge-base --is-ancestor 验证,非凭印象)

先物理确认迁移链的 revision/down_revision(注意 revision 标识与文件名不完全一致,root 9-16 提醒
过这个坑:文件名 batch7a_conclusion_read_receipt.py 但 revision 是 batch7a_read_receipt):

migrations/versions/batch7a_conclusion_read_receipt.py   revision=batch7a_read_receipt      down_revision=demo_profile_data_fix1
migrations/versions/demo_profile_data_fix2.py             revision=demo_profile_data_fix2    down_revision=batch7a_read_receipt
migrations/versions/phase81_001_demo_profile_refresh.py   revision=phase81_001               down_revision=demo_profile_data_fix2
migrations/versions/demo_profile_data_fix3.py              revision=demo_profile_data_fix3    down_revision=phase81_001

链是单线不分叉(已用 grep -rl 'down_revision = "xxx"' 逐个反查,每个 revision 只有唯一下游,
demo_profile_data_fix3 是当前链尾,无人以它为 down_revision)。

用 git merge-base --is-ancestor <引入迁移的 commit> <各 MR 合并提交> 逐个验证「首次落在哪个 MR」:

3 · 生产现状核对

3.1 迁移文件是否已在 origin/main

查法:git grep -l '^revision = "<id>"' origin/main -- migrations/(锚定行首,避免误命中其他文件的
down_revision 引用同名字符串——root 明确提醒过"别用文件名 cat-file 猜"这个坑)。

对照组(证明查法有效):demo_profile_data_fix1 已知在 main(它是上一轮 MR#687 发布内容),
查询返回 origin/main:migrations/versions/demo_profile_data_fix1.py,命中 → 查法有效。

3.2 生产库真实 alembic 版本(sudo db-prod 只读查)

SELECT version_num FROM alembic_version;
      version_num
------------------------
 demo_profile_data_fix1
(1 row)

与 git 层面核对完全一致:生产真实停在 demo_profile_data_fix1,下一环正是
batch7a_read_receipt,链条无缺环、无需要跳过的中间版本。这也印证了 root 口信里
"代码新、数据旧"的说法(见第6节)——生产的 alembic 版本号确实还没往前走一步。

3.3 内容层面追加核对(#698 迁移安全性)

phase81_001_demo_profile_refresh.py 及另外三条迁移全部只用 op.execute 操作物理表,
grep -n "^import app\|^from app" 对四个文件均 0 命中——不依赖任何业务代码运行时。
这意味着即便 root 那条分支的代码改动(#692/#696)是否已完整上生产存疑,也不影响
phase81_001 这条纯数据迁移的可发布性——它只改 6 行示范档案的 ai_analysis_text,
幂等 + 三重 WHERE 限定(固定 UUID + is_sample=true + 值不同才更新)。

4 · 最终发版清单 + 风险提示

4.1 要点名的 MR 编号(按合并时间升序;工具 9-15 起会自动按 test 合入顺序重排,书写顺序不敏感)

--mr 693 --mr 694 --mr 695 --mr 697 --mr 698 --mr 700 --mr 701 --mr 702 --mr 703 --mr 704 --mr 705

共 11 个 MR(本线10个「见第1节」 + root 依赖项 #698「见第1节末尾」)。

4.2 会不会把别人夹在 test 里的提交带上生产?—— 已 verify,结论:不会

结论先行:用真实 release_main.py plan(只读,不写 Git/Codeup)对这 11 个 MR 号跑了一遍,
逐 MR 的 commit_ids 与 source_branch 精确对应各自的分支和提交,没有出现属于第三方分支的
提交或文件。理由分三层:

① 时间窗地毯式核查:git log --merges origin/test --since="2026-09-15 23:00" --until="2026-09-17 01:00"
把这个时间段内所有合入 test 的 merge 全部列出(不限定分支关键词),结果只有两条分支活跃:
我们的 feature/store-mobile-refractive-archive(10个MR)和 root 的
feat/phase81-refractive-4l-grounding(#692/#696/#698 三个MR)。没有第三个会话的 MR 夹在这个窗口里。

② 工具机制本身按 MR 隔离,不按时间/分支整体拉平:读了 scripts/release_main.py 源码
(build_release_plan 函数),它对每个点名 MR 只取
git rev-list --no-merges <该MR合并提交的第一父>..<该MR合并提交的第二父>——即“合并前的 test 状态”
到“功能分支尖端”之间的非合并提交,天然排除了已经在 test_parent 里的所有其他人的提交。
且工具显式检测“嵌套合并”(功能分支中途合回 test 解冲突产生的 merge):只有当该嵌套合并的所有
非首父提交都是 test_parent 的祖先时才放行展开,否则直接 ReleaseGuardError 中止——这道判定专门
防"合并回 test 时顺带夹带了外来提交"。我们的 #700 范围内确实有一个
Merge remote-tracking branch 'origin/test' into feature/store-mobile-refractive-archive
(67593559,09-16 18:16),已验证它合入的 origin/test 内容(含 #698)在 #700 合并时已经是
test_parent 的祖先,没有触发 foreign_merges 报错。

③ 真跑 plan 子命令拿到的实证(只读,build_release_plan 不写 Git/Codeup):

$ python3 scripts/release_main.py plan --repo <worktree> --test-ref origin/test --main-ref origin/main \
    --mr 693 --mr 694 --mr 695 --mr 697 --mr 698 --mr 700 --mr 701 --mr 702 --mr 703 --mr 704 --mr 705 --json

mr count: 11
commit count: 39
changed files count: 47
migration files: [batch7a_conclusion_read_receipt.py, demo_profile_data_fix2.py,
                   demo_profile_data_fix3.py, phase81_001_demo_profile_refresh.py]
693 → feature/store-mobile-refractive-archive
694 → feature/store-mobile-refractive-archive
695 → feature/store-mobile-refractive-archive
697 → feature/store-mobile-refractive-archive
698 → feat/phase81-refractive-4l-grounding    ← 与 root 说法一致,且工具自动认出这不是同一分支
700 → feature/store-mobile-refractive-archive
701 → feature/store-mobile-refractive-archive
702 → feature/store-mobile-refractive-archive
703 → feature/store-mobile-refractive-archive
704 → feature/store-mobile-refractive-archive
705 → feature/store-mobile-refractive-archive

旁证(证明"漏掉依赖项会被拦,不是理论推演"):把 #698 从点名列表里去掉重跑 plan,
结果 仍然 exit 0(plan 本身不校验迁移祖先链,只是纯计算),但 migration files 变成只有
3 个(phase81_001_demo_profile_refresh.py 消失),而 demo_profile_data_fix3.py
(down_revision = phase81_001)依然在列——这正是 assert_migration_ancestors_on_main
设计要拦的场景。该守门只在 publish 阶段(建 release 分支/MR 之前)才会触发,plan/status
阶段不会报错,发布前必须靠人工核对迁移链(已在第2节做完),不能只跑 plan 看 exit code 就放心。

4.3 历史经验对照 → 本次是否适用(逐条,详见第5节完整表格)

• 判断"是否已发生产"没有用 main..test 比对法或裸内容 diff(两者都被 memory 标记为易误判),
  改用「revision 锚点行首 grep + sudo db-prod 查真实 alembic_version」双重交叉验证 —— 详见第3节。
• 已用地毯式时间窗扫描核实"功能是否跨多分支",避免只查一个分支关键词漏掉 root 的依赖分支。
• 全程未用 git show --name-only <merge> 判断合并提交带了什么文件(该写法对 merge commit 返回假0),
  改用 ^1..^2 区间或 plan 工具输出。
• MR 数量 11 个,接近"超过约15个必须显式 --branch"的阈值,建议真正发版时主动带
  --branch release/store-mobile-vf-20260917(或更短命名),不要等 500 才加。

4.4 其余风险提示

1. #698 不属于本功能线分支,必须与本线 10 个 MR 一并点名,否则 demo_profile_data_fix3
   建分支阶段会被 assert_migration_ancestors_on_main 拦下(已用第4.2节的"去掉#698重跑"实测坐实)。

2. root 同一分支的 #692、#696 不在本清单里,原因见第6节——它们与本次迁移链无依赖关系,
   是否需要跟着发属于另一条决策,不能默认"发了我们这11个就等于把 root 那条线发全了"。

3. git log origin/main 的实际 HEAD(d0428e78,MR#699"release: MR 696 选择性晋级 main",
   合并时间 09-16 18:09:56)与本任务开始时的 worktree 快照信息里的旧 HEAD(b282c143,MR#687)
   不一致 —— origin/main 已经比对话开始时的快照更新,发版前请以 git fetch 后的 origin/main
   为准。

4. MR#699 用的是"选择性晋级"(cherry-pick 到新 release/* 分支),产生的是新 commit SHA,
   不是原 origin/test 上 96638b64 的祖先 —— 用 git merge-base --is-ancestor 直接查原始
   合并提交会误判为"不在 main"(本次已验证到这个坑,改用文件内容 diff 比对绕过,见第6节)。

5. 生产部署每轮跑 alembic upgrade heads(复数),会把 main 上所有头待跑的迁移一并执行 ——
   本次点名的 11 个 MR 只带 4 个迁移且构成单线链(第2节已验证无分叉),没有夹带其他游离头的风险。

5 · 历史经验对照表(逐条读 memory · 判断本次是否适用)

6 · root 口信落点(9-16 · 逐条对我们清单的影响)

附:关键命令留痕(供复核)

# 1. 找本线 MR
git log --merges origin/test --grep="store-mobile-refractive" -i --pretty=format:"%H|%ad|%s" --date=iso

# 2. 时间窗地毯式扫描(不限分支关键词,核实无第三方MR夹带)
git log --merges origin/test --since="2026-09-15 23:00" --until="2026-09-17 01:00" --pretty=format:"%H|%ad|%s" --date=iso

# 3. 迁移落点(以 demo_profile_data_fix2 为例)
git merge-base --is-ancestor e21ea8b3947cce602c2882ec0f74eebe53125de4 ad3bfdfdbd9428f3fc7205ebdabaa7b1fa5b34b1  # 对 #697,exit 0=真

# 4. 生产现状(锚定行首 + 对照组)
git grep -l '^revision = "demo_profile_data_fix1"' origin/main -- migrations/   # 对照组,命中
git grep -l '^revision = "batch7a_read_receipt"' origin/main -- migrations/    # 目标,未命中

# 5. 生产库真实版本
sudo db-prod "SELECT version_num FROM alembic_version"

# 6. 只读发版计划(不写 Git/Codeup)—— 验证"不带别人提交"
python3 scripts/release_main.py plan --repo <worktree> --test-ref origin/test --main-ref origin/main \
  --mr 693 --mr 694 --mr 695 --mr 697 --mr 698 --mr 700 --mr 701 --mr 702 --mr 703 --mr 704 --mr 705 --json

# 7. 只读待发状态(不写 Git/Codeup)
python3 scripts/release_main.py status --repo <worktree> --test-ref origin/test --main-ref origin/main \
  --mr 693 --mr 694 --mr 695 --mr 697 --mr 698 --mr 700 --mr 701 --mr 702 --mr 703 --mr 704 --mr 705

# 8. 版本/漂移自查
grep -c "_API_MERGE_SUBJECT_RE" scripts/release_main.py     # 期望非0 = 新版
md5sum scripts/release_main.py /usr/local/lib/release/release_main.py  # 期望一致 = 无漂移

本报告只调查整理,未执行任何 release-to-prod / git 写操作 / 生产库写操作。