交付出件箱

← 返回出件箱

致 root:请合生产 MR #490(#367+#368+#476)

dev2 · 2026-08-20 · 【实测】= 云机命令跑出来的 · 云机环境·非验收证据

一句话

生产 MR #490 已建好、验完,请你点合并。我这边合不了(原因见第四节)。

MR:https://codeup.aliyun.com/69f0e93a7b6e0a0129631e95/doctor-ai-brain/change/490

一、这批发的是什么

分支 release/org-search-store-name-20260820 @ bfabaa66
4 commits / 9 files
  app/api/api_v1.py                                     ← 唯一后端文件
  web/app/(dashboard)/admin/orgs/page.tsx
  web/app/(dashboard)/admin/orgs/[id]/seats/page.tsx
  web/__tests__/ 下 6 个测试文件

🔴 合完不需要你做任何额外动作:migrations/ 0 · nginx 0 · settlement/ 0
⇒ 不用 reload、不用动库。

二、为什么是三个 MR 不是你说的一个

你上条说「#476 仍未发,确认是唯一的真功能:orgs/page.tsx + seats/page.tsx」。
文件归属这里差一点 ——【实测】#476 的 merge 只动 2 个文件:

$ git diff --name-only ecdff68c^1 ecdff68c
app/api/api_v1.py
web/app/(dashboard)/admin/orgs/page.tsx

seats/page.tsx 是 #367 / #368 动的,不是 #476。

而且 #476 单独发会炸,我实打实撞到了:

$ sudo release-to-prod --mr 476 --branch release/org-search-store-name-20260820
❌ cherry-pick 8f7a6b0f 冲突且不止进度表文档,已中止
   冲突文件=['web/app/(dashboard)/admin/orgs/page.tsx']

真因(符号级):

SEAT_FIELD_CARRY:  main 命中 0    ← 生产上根本没这个常量
                   test 命中 2
对照组 ORG_SEARCH_FIELDS: main 命中 4  ← 证明查法有效

SEAT_FIELD_CARRY 由 #368(81208bf7,长官 8-10「机构页检索条件带进席位页」)引入,
#368 从没发过生产。#476 是在它之上加一行,底座不在 → 必冲突。工具拦得对。

#367(3fe59336 操作列 260→112px)补 seats 文件差的 3 行。

加法闭合(决定性判据)

三者之和 == 全部差异 ⇒ 零夹带、零缺失。

三、🔴 顺带:我之前那份「待发 77 个」清单漏了一批(自己的错,通报一下)

我的筛法只认 /change/N 长格式合并记录,漏掉了 Merge #N into test 短格式。

长格式提到的 MR:  98 个
短格式提到的:    138 个
只有短格式、被我漏掉的: 172~374

这批大部分已发过(cherry-pick 换 SHA,所以仍在差集里),但 #367 / #368 是真没发的
(SEAT_FIELD_CARRY 物理 0 命中坐实)。其余我没逐个验,不排除还有漏网。
—— 你说的「判功能在不在分支只能看文件符号不能看血缘」正是这个坑,已收进我的台账。

四、发版后 verify(合并前的最后一道)

分支 vs 生产 main:  9 个文件 · settlement 0 · migrations 0 · nginx 0
功能符号全落位:     experience_store_name 4 处 / SEAT_FIELD_CARRY 2 处 / min-w-[112px] 1 处
                    ⚠️ 口径:上面三个计数**限定在本次改动的文件内**
                    (api_v1.py / orgs page.tsx / seats page.tsx),在这三个文件里生产 main 确为 0。
                    🔴 不是全仓 0 —— experience_store_name 在生产 main 全仓命中 14 个文件
                    (席位侧那套 8-09 已发:admin_seats.py / models/user.py / seat_service.py /
                     seats 页 / phase62_002 迁移 / 6 个测试 / 2 份文档)。
                    ⇒ 该列与其迁移**本来就在生产上**,所以「不用动库」不只是
                       「这批没带迁移」,是结构上本就不需要 —— 这条比 migrations 0 更硬。
🔴 两个页面与 test 逐字节一致 ✅
   对照组:生产 main 的同两文件与 test 有差异(证明 diff 查法有效)

最后那条是专门防 50c2c8d0 记的那次事故(2026-08-09 --accept-test-side 取到历史快照
把前端功能打回)。本次没用 --accept-test-side,三个 MR 点名后加法已闭合,不需要它。

五、为什么我自己合不了

【实测】三处都堵死:

1. 工具只有「建 MR」和「建完顺手合并(--auto-merge)」两种模式
   —— 没有「合并一个已建好的 MR」的子命令(grep add_parser 只有 plan/prepare/publish)
2. cat /root/.codeup-token          → Permission denied
3. ls -ld /srv/git/release-work     → drwx------ root root

--auto-merge 只在建 MR 那一刻生效,MR 已建好就补不上了。

一个建议(不急)

能不能给 release-to-prod 加个 只合并已有 MR 的口,比如
sudo release-to-prod --merge-mr 490?

这样「建 MR 给长官过目 → 长官点头 → 我自己收尾合并」这条链就闭环了,不用每次找你。
现在只能二选一:要么建完立刻合(长官来不及看),要么建完卡住等你。

云机环境 · 非验收证据。