交付出件箱

回 root · 三步反馈 + 两个问题 · 2026-08-20

标注:【实测】= 本机命令跑出来的;【推断】= 逻辑推的。

1️⃣ 结算待发 MR 清单 —— 已核实:69 个,#381 → #475

跟你的数对一下

	你的	我核实的
个数	71	69
起点	#372	#381

【实测】#372~#377 逐个核过(不用分支名,用内容):

#372 phase72 结算导入  → main 已有 settlement/.env.example 等文件      = 已发 ✅
#374 settlement-guard  → core_readonly.py / env.py 与 main 逐字节一致  = 已发 ✅
#373 #376 #377         → 已发 ✅
#375                   → **未发**(纯核心 feature/release-test-automerge,不动结算,不影响本清单)

⚠️ 更正:你说的「#372-377 已发」里 #375 其实没发。它是纯核心,不进结算清单,
但如果后面要发核心侧,别把它当已发漏掉。

🔴 另一处你的判断对结算不成立

你说「#434-451(8-18)已发」—— 那批已发的是核心侧的 4l 视力报告
(fix/4l-hyperopia-focus)。同区间里动结算的 6 个一个都没发:

#432 #433 #436 #438 #440 #441   ← 批 E-3/E-5/E-6,全部待发

【实测】终裁证据(#438 争议最大,单独钉):

platform_views_left    main=0  test=3   → main 没有 = 未发
provision_error        main=0  test=4   → main 没有 = 未发
对照组 StoreServiceOrder  main=23 test=31  → 查法有效

⚠️ 我一开始也误判过 #438「已发」:因为 credential_views_left 在 main 有 4 处
—— 那是更早的 MR 引入的,不是 #438 的。指纹法有假阳性,别用。

我怎么定的(三重,前两种都出过错,如实说)

迁移锚点(最硬):main 结算停在 phase66_000_zero_guarantee,缺 phase67_000,
而后者由 MR#385 引入 ⇒ #385 及之后全部未发
旧痕迹法(定 #381~#384):MR#381 删掉的注释「四类资料缺一不可,别因为是平台操作
就放行空档案」在 main 上还在 ⇒ 未发
独有标识符(定有争议的):见上面 #438

⚠️ 我自己踩的坑(跟你踩的是同一类,记录下来)

坑一:按 release/mr-* 分支名解析已发清单 → 得出 77 个待发。分支名不可靠,漏记 MR 号。
坑二:合并标题有两种格式,我只认了一种:
格式A ... Code review Link: .../change/476(95 条)
格式B Merge #252 into test from xxx(138 条)← 一开始漏了
【实测】重数后:格式B 里动结算的只有 #372、#374 两个,而这两个你已确认发过
⇒ 69 个的结论不受影响,但这个漏洞值得记账。

清单(可直接拼命令)

门店资料非必填     --mr 381 --mr 382 --mr 383 --mr 384
价格管理(批A)      --mr 385 --mr 386 --mr 387 --mr 388 --mr 389 --mr 391
微信支付核心       --mr 392 ... --mr 419        (28 个连号)
退款+重复支付守门  --mr 420 ... --mr 428        (9 个连号)
批E 自动开通       --mr 429 --mr 430
批E-3 门店拉微信   --mr 432 --mr 433 --mr 436 --mr 438 --mr 440 --mr 441
签约v3 先付款      --mr 456 --mr 457 --mr 462 --mr 464 --mr 465 --mr 466 --mr 467
                   --mr 468 --mr 469 --mr 471 --mr 472 --mr 473 --mr 474 --mr 475

⚠️ 核心侧待发数我没有可靠核实(别引用下面的数当结论)

我一开始写「另有 8 个纯核心待发」——那个数是错的,只数了格式A、还用了不可靠的分支名过滤。
【实测】重数:

差集里纯核心(不动结算)的合并:  格式A 26 个 + 格式B 136 个(号段 172~373) = 162 个候选
两种格式都不是的合并:          7 条(未计入)

格式B 那 136 条多是老号段,大概率绝大部分已发,但我没有可靠办法逐个核实
(分支名不可靠 · 指纹有假阳性 · 逐个内容比对 162 次成本太高)。

⇒ 本次只发结算那 69 个;核心侧要发的话,清单得另外单独核,我不拿这个数当结论。

2️⃣ 并核心 alembic 多头 —— 方案已定,我来做

一个你没提到的情况

【实测】main 是双头,test 是三头:

main: phase70_001 + store_poster_demo_flag                    (2 头)
test: phase70_001 + store_poster_demo_flag + phase66_001      (3 头)

多出来的 phase66_001_peer_axial_flag 由 MR#252(核心侧 feat/tongkuan-haizi-demo)带进 test,
main 上没有。

所以我只并 main 上那两个头,不并第三个

理由:合并迁移如果引用 phase66_001,而发生产时没点 #252,
alembic 会报「找不到该版本」—— 比多头更糟。

并完 main 变单头 ⇒ 你要的效果达成,流水线不再红
test 仍是 2 头,但【实测】test 流水线 run#527 是 SUCCESS ⇒ test 能吃多头,不影响

做法:新建功能分支 → alembic merge 生成纯合并节点(不动任何表)→ 本地真库验 → 发 test → 随本批进 main。

3️⃣ 发 main —— 等你回下面两个问题就开跑

❓ 需要你回的两个问题

问题一:#470 是什么?

结算清单里 #470 号断了 —— 我在 test 的合并记录里完全找不到它。
可能被撤销、或没合进 test。【实测】我无 MR 权限,查不了。
麻烦你在 Codeup 上确认它是什么,别漏发也别错发。

(同理断号的 390/431/458/459 我已确认是纯核心、不动结算。)

问题二:nginx 还要不要动?

你这次回复只提了流水线源和 rsync 路径,没提 nginx。但:

【实测】本批改动包含 settlement/deploy/nginx-settlement.conf:

$ git diff --name-only origin/main origin/test -- 'settlement/deploy/nginx*'
settlement/deploy/nginx-settlement.conf

按台账 8-17 立的门禁:部署链只同步文件、不重载 nginx,不 reload = 改动物理无效
(test 实测坐实:发版后 40 并发探针 10 个 503,reload 后 0 个)。

所以想跟你确认两件:
1. 之前说的「生产 nginx 切流」还需不需要做?(你这次没提,不确定是已做还是不需要了)
2. settle-prod 跑完后,是否需要你在生产机手动 nginx -t && nginx -s reload?

已收到并确认的

✅ settle-prod 源已切统一仓 / 分支 main / 过滤 ^main$ / rsync 源改 settlement/
✅ 只保存未运行,生产未动(容器 Up 9 days)
✅ 顺序铁律:先发进 main,再跑 settle-prod(main 结算落后 136 文件,反了会退版)

云机环境 · 非验收证据。v2(自检修订):更正 #375 未发、更正核心侧待发数不可靠、补 #372/#374 内容验证证据。