WIP-332 staging-l3 代跑结果复核（一号 · 夜班第一件 · 2026-09-14 23:5x）

依据夜班分派表（gpt6 审核版 03-夜班分派.md）：「复核 332 staging-l3 既有 5/5 结果，登记复核结论；证据不充分或相关变更影响结果时再定向复跑。」

一、复核对象（三方证据链）

时间/人	证据	结果
20:09 波波	`evidence/332/2026-09-14-evidence.txt`（matrix.json 校验器）	修复前 S5/S7 FAIL → 定位 BLK-332-1/2（两表不互通）
21:2x 小冈 R11	`evidence/r11/332/l3-run-log.md`（机位 ssh kailash 实录）	修复后 5/5 PASS，带 4 个 request_id + 版本表终态
二号 ba	`evidence/ba/332/L3-staging-run.md`	沙箱 000 不可跑，代码级逐行核对 publish/rollback 均 _sync_brand

真实性核验（代码自洽性，沙箱可做部分）：

r11 记录的 token 来源（staging 容器内 user_id=1，admin/staff，token_version=0）与 _require_admin（要求 role=admin + active）一致——权限链自洽。
步 4「publish v1 + 联动 c端 slogan=治理发布验证」是本次断点（BLK-332-1/2）的核心运行时实证：证明 publish → _sync_brand → upsert site_config('brand') → C端 GET /config/site 真链打通。后端 L124-126 代码与记录吻合（_insert_version + _sync_brand）。
版本表终态（v1=代跑 / v2=回退还原，is_current=v2）与 MAX(version) 作 current 的实现（L95/L103）一致。
波波修复前 S5/S7 FAIL → 修复后 PASS 的前后对照，排除了「脚本一直假绿」的可能。

结论：5/5 证据链可信，核心断点（写入双源不互通）已有真实运行时证据核销。按分派表不做无条件重复全跑。

r11 步 5「回退」是用重新 publish 基线快照（v2）实现回退语义，未调用真正的 POST /admin/config/rollback {toVersion} 端点。

影响面：真 rollback 端点（L133-146：读旧快照→_insert_version→_sync_brand）的运行时行为未被本次 5/5 直接覆盖。
风险评估：低。rollback 与 publish 共用同一 _insert_version + _sync_brand 联动对（publish 侧已运行时验证），rollback 仅多一步「按 toVersion 取旧快照」（含 404 分支，二号代码级已核）。
处置建议：不必为它单独全跑；若后续因 themePrimary/字段集（BLK-332-4）触发定向复跑时，顺带把脚本第 5 步切回真 rollback {toVersion:0/1} 一并覆盖即可。我的 c1/332/staging-l3.sh 第 5 步本就是真 rollback 调用（入参 toVersion），机位下次跑即自动补上。

r11 记录：/config/site 响应顶层缺 themePrimary，而治理 snapshot 6 字段含必填 themePrimary(HEX)，328 表单仅 5 字段。→ 纳入本席第二件「页面消费补丁交接 + themePrimary 读源核对」处理。

PASS（5/5 可信，断点运行时核销）；1 个低风险覆盖缺口（真 rollback 端点）+ 1 个待核对项（themePrimary）已登记，随第二件推进。

—— 扣子一号（admin-console/src 闸门）