WIP-332 品牌配置真闭环 · 联调 MATRIX（一号 328 侧）

署名：扣子一号 · 2026-09-14 · 契约先行（config-governance-v1 冻结）

定位：328（品牌配置页，一号）+ 329（版本管理页，二号）同单协作。本文件只覆盖一号 328 侧闭环与断点暴露，329 侧由二号自定义。

零、结论（先看）

✅ 328 前端已 100% 接真：fetchBrand→GET /api/miniapp/config/site，saveBrand→PUT /api/miniapp/config/site/brand，业务代码无任何 mock/fixture，saveBrand 内置 URL/必填校验（brand.ts validateBrand）。
✅ 最短闭环「页面直写→C 端生效」已在 328 交付时生产实证：GET /config/site 返回 5 品牌字段全在顶层（brandName/slogan/tibetanText/logoUrl/heroBgUrl），与 saveBrand PUT 打平映射一一对位。
🔴 发现发布阻断级断点（需后端补联动或波波矩阵裁决）：治理 POST /admin/config/publish、POST /admin/config/rollback 只写 site_config_versions 版本表，未联动写 C 端读源 site_config.brand。而 C 端 GET /config/site 读的是 site_config.brand（miniapp_site.py）。⇒ 治理发布/回滚后 C 端显示不生效，「c 端显示生效」「按契约回退核对」两环在纯治理路径上无法成立。

端点	前端（admin-console/src）	后端（323，小冈 R11 入库）
GET `/admin/config/versions`	二号 ConfigVersion	✅ 已在
POST `/admin/config/publish`	二号 ConfigVersion	✅ 已在（仅写版本表）
POST `/admin/config/rollback`	二号 ConfigVersion	✅ 已在（仅写版本表）
GET `/admin/config/current`	二号 ConfigVersion	✅ 已在
GET `/api/miniapp/config/site`	一号 328 fetchBrand	✅ 已在（读 site_config.brand 打平）
PUT `/api/miniapp/config/site/brand`	一号 328 saveBrand	✅ 已在

#	环节	前端实现	后端实证	结论
1	页面读取品牌回填	fetchBrand GET /config/site，取顶层 5 字段	生产 GET 实测 5 字段在顶层	✅
2	页面保存品牌	saveBrand PUT /config/site/brand body {value:{...}}	端点已挂载（假 token 返回非 404，L3 待机位真 token）	✅（L3 待跑）
3	保存前校验	validateBrand：必填+logoUrl 协议校验，11 条非法样例 fixture 全 PASS	—	✅
4	改品牌→C 端生效	直写 site.brand，C 端读同源	—	✅ 最短闭环
5	治理发布→C 端生效	依赖 publish 联动 site.brand	publish 未写 site.brand	🔴 断点
6	治理回退→C 端核对	依赖 rollback 还原 site.brand	rollback 未写 site.brand	🔴 断点

建议 A（后端补联动，推荐）：manager config_governance 的 publish/rollback 完成后，把快照品牌 5 字段（brandName/slogan/tibetanText/logoUrl/heroBgUrl，themePrimary 不入 site.brand 因无需前端消费亦可保留）写回 site_config.brand。这样「治理发布→C 端生效→回退核对」闭合成真闭环。属后端改动（backend 域）。
建议 B（前端双写）：329 页面 publish/rollback 成功后再调一号 328 的 saveBrand 直写 site.brand。不依赖后端，但前端需两次请求强一致（rollback 的旧快照字段需带全）。属二号 329 加固，非 328。
本单（328）立场：328 不代做 A/B（A 是后端域、B 是 329 域）；328 保证「页面→C 端」最短闭环已真，断点如实上报。

脚本：staging-l3.sh（staging 100.64.1.230:8089 绑 localhost，需 Tailscale 机位以员工 token 代跑，覆盖 1-5 步含断点验证）。
前置：staging 已部署 323 治理 4 端点 + 328 直写端点。
期望：step 3（直写→c 端生效）应 PASS；step 4（publish→c 端生效）预期 FAIL=证实断点，供后端/矩阵决策。

main miniapp_config_governance.py：新增 _sync_brand(pool, snap)，INSERT ... ON CONFLICT (key) DO UPDATE 原子 upsert site_config(key=''brand'')。
publish L126 await _sync_brand(pool, req.snapshot)；rollback L143 await _sync_brand(pool, snap)——两动作均原子回写 c 端读源。
修复提交已入 main（义父：T0，smoke 26/26）。第三节 P0-A/P0-B 断点 代码级核销。

内置员工登录（默认沿用历史冒烟账号 13020000001/test123456，可用 TEST_PHONE/TEST_PASSWORD 覆盖）；
契约对齐真后端：信封 {ok,data}、rollback 入参 toVersion（修正早期误写 versionId）、登录取 data.token、snapshot 6 字段含 themePrimary；
6 环节自动 PASS/FAIL：登录→current 基线→publish 校验版本号+1→c端匿名 GET 核对 brandName/slogan 生效→versions.current 一致→rollback 回退基线版本→c端核对还原；
退出码 0=全绿，断点直接 FAIL 不造假。

结果 8/8 全绿：版本 v1→v2 +1 ✅；c端 brandName/slogan 生效 ✅；versions.current=2 ✅；rollback 生成 v3 ✅；c端还原基线品牌名 ✅。

已穷尽沙箱通道：staging 100.64.1.230:8089 HTTP=000、PG:5432 closed、无 ssh 二进制、无 docker；生产治理端点 404（生产人工部署铁律，未上线）。
机位一键命令（Tailscale 可达 staging 的机器）：

```bash

bash docs/delivery/evidence/c1/332/staging-l3.sh

# 默认 http://100.64.1.230:8089，冒烟账号已内置；输出末行 [smoke] N/N

```

复用 /tmp/mock332.py（内存态 mock，publish/rollback 均联动 _sync_brand 写 site.brand，SETDB=统一契约）对最终版脚本全链路复跑：
终版脚本 8/8 全绿（退出码 0）：登录取token→current v1→publish v2(+1)→c端 brandName/slogan 双生效→versions.current=2→rollback v3→c端还原基线品牌名。
性质仍为脚本/契约判定逻辑验证；真实运行时 L3 需机位代跑。
机位一键命令（Tailscale 可达 100.64.1.230）：

TEST_PHONE=<staging员工号> TEST_PASSWORD=<pwd> bash docs/delivery/evidence/c1/332/staging-l3.sh

或传入 BASE_URL 指定 staging。默认内置冒烟员工号 13020000001。

沙箱无任何可达 staging 通道（Http timed out/PG closed/无 ssh/tailscale/docker），物理不可达，由机位代跑取证。