交付出件箱

发生产待办清单 · MR 名单自推结果 · 2026-08-20

云机环境 · 非验收证据。这份清单是从 git 合并记录推出来的,不需要 Codeup 令牌。
用途:sudo release-to-prod 必须逐个点名 MR,本文给出候选名单供长官挑选。

一、结论:待发 77 个 MR(不是交接件说的"六十多个")

口径	数字
test 有、main 没有的合并记录	240 条
其中带 MR 编号的	95 个
已发过生产的(从 main 的 `release/mr-*` 分支名解析)	18 个
真正待发	77 个
MR 号范围	375 → 476

🔴 为什么必须剔除"已发":发生产走 cherry-pick 到 release/* 隔离分支,
SHA 与 test 上的原提交不同 ⇒ 已发过的 MR 照样出现在 main..test 差集里。
直接拿差集当待发名单会重复发布。(实例:#379 已由 release/mr-379-20260819165251 发过,
但仍出现在差集中。)

二、待发清单(按功能分支归类 · 长官挑选的单位)

个数	MR 号范围	功能分支	备注
28	392~419	`feature/wechatpay-pay-core`	微信支付核心
16	456~475	`feature/signup-v3-prepay-first`	8-19 那 25 件
9	420~428	`feature/refund-status-and-dup-pay-guard`	退款状态+重复支付守门
7	385~391	`feature/price-management`	价格管理(批 A)
6	432~441	`feature/batch-e3-store-wxpay`	批 E-3 门店拉微信
3	429~431	`feature/batch-e-auto-provision`	批 E-1/E-2 自动开通
2	382~384	`feature/store-uploads-hint-fix`
1	476	`feature/org-search-by-experience-store`	核心侧
1	442	`feat/phase73-care-pathway-router`	核心侧
1	383	`fix/jsx-syntax-error`
1	381	`feature/store-signup-uploads-optional`
1	378	`feature/cleanup-orphan-tests`
1	375	`feature/release-test-automerge`

逐个 MR 号(可直接拼命令)

wechatpay-pay-core:        392 393 394 395 396 397 398 399 400 401 402 403 404 405
                           406 407 408 409 410 411 412 413 414 415 416 417 418 419
signup-v3-prepay-first:    456 457 458 459 462 464 465 466 467 468 469 471 472 473 474 475
refund-status-dup-pay:     420 421 422 423 424 425 426 427 428
price-management:          385 386 387 388 389 390 391
batch-e3-store-wxpay:      432 433 436 438 440 441
batch-e-auto-provision:    429 430 431
store-uploads-hint-fix:    382 384
其余单个:                   375 378 381 383 442 476

⚠️ 本名单只是候选,不是"应该全发"。发多少由长官定;
工具会打印每个 MR 的 commit_ids + changed_files,合并前必须逐个核对无夹带。

三、🔴 部署后必须做的一件事(台账门禁 · 谁也记不住)

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

$ git diff --name-only origin/main origin/test -- 'settlement/deploy/nginx*'
settlement/deploy/nginx-settlement.conf          ← 命中 1
（对照组:同目录 docker-compose.prod.yml 也在差异里,证明查法有效）

⇒ 按台账 2026-08-17 立的门禁:部署链只同步文件、不重载 nginx。
部署完必须请 root 在生产服务器跑:

nginx -t && nginx -s reload

不 reload = 改动物理无效(test 实测坐实:发版后 40 并发探针 10 个 503,reload 后 0 个)。

四、改动面(供评估风险)

侧	差异文件数
结算 `settlement/`	136
核心 `app/`	6
核心 `web/`	20

核心侧涉及:席位页/登录页/菜单/价格页/微信 OAuth/find_similar/internal_settlement。

五、这份清单怎么来的(可复现)

# ① test 有 main 无的合并记录 → 提取 /change/<MR号>
git log origin/main..origin/test --merges --pretty=format:%s | grep -oE '/change/[0-9]+'

# ② main 上已发生产的 → 从 release/mr-<号>-<时间戳> 分支名解析
git log origin/main --merges --pretty=format:%s | grep -oE 'release/mr-[0-9-]+'

# ③ 待发 = ① - ②

脚本存于 /tmp/pending.py(一次性,未入库)。

六、我没验的

这 77 个 MR 在 Codeup 上的当前状态(是否已关闭/已撤销)—— 无 MR 权限
MR 之间的依赖关系(某个 MR 是否依赖未列出的 MR)—— 工具会在 cherry-pick 时暴露冲突
是否有不带 MR 号的合并被漏掉(240 条合并中 145 条无 /change/ 标记,多为分支间同步)

云机环境 · 非验收证据。