335 端到端演练分镜剧本 v1（WIP-337 · 波波 · 2026-09-15 11:1x）

性质：供机位开跑的剧本，不是交付汇报也不是事后报告。本件只写「谁、敲什么、凭什么算过、证据放哪儿」。

权威口径：执行器 = scripts/tenant_hooks/*.sh（小冈 WIP-334）；打包 = miniapp.sh（冈子 M1 已过真实链路门）。

本岗边界：只出剧本与判据，不改任何 hook / 后端代码（pre-receive 属主限制）。

版本：v1.6（WIP-363① 验收官上任复核 · 与 11:2x 开跑令对齐）（v1.1＝冈子技术校准；v1.2＝波波静态核证＋步骤 3.0 首次实跑取证；v1.3＝E/AG/V 命名落全文＋tenant_id 新口径＋引用刷新；v1.4＝§5·B V 系判据合入表＋§5·C 跨租户待裁决＋V4 四条负向用例；v1.5＝WIP-P1 终稿：门槛表补 #6/#7 两条硬阻塞＋§5·B V 系编号冲突登记＋§7/§8 唯一真源声明＋通用判据归一引用。差异逐条见 §10）。

v1.6 复核摘要（2026-09-16 11:3x · 波波 WIP-363① 只读复核）：开跑令下达后本岗按四态不冒充原则逐条校准，四处与开跑令脱节：①门槛 6 实测仍未销（脚本仍报「模块责任人未登记」WARN，而开跑令称「七门槛全销」）②第三幕执行人仍写冈子，但冈子已转商务线（WIP-365）③§5·C 双缺口已被 363 附注裁决，剧本判据未同步（R5 修复已闭环 ⇒ 缺口 B 销；admin 全局视角成立 ⇒ 缺口 A 判 N/A+366 审计）④§5·B 六处证据位越出 §8 八目录。另门槛 5（products）全仓无书面裁决出处。详见 docs/delivery/acceptance/363-剧本v151只读复核-v1.md。（含 v1.6.1 2.3b 自纠）

v1.5.1 勘误（01:3x · P2 新包复核）：小齐 Q1 插入第二 active 目的地（id=3）⇒ ①N2 由「BLOCKED-环境不满足」转为可实测；②🔴 「不带目的地一律 409」表述过宽——实测 /health、/api/miniapp/config/site 均 200（后者为平台级全局配置、不走目的地解析）⇒ 409 只作用于走 resolve_destination/_default_destination 的端点；③🔴 2.3 判据待澄清（C 端品牌是运行时读还是构建期注入）。

ℹ️ 版本口径差登记：义父 01:1x 令表述为「剧本 v1.3 终稿」，而仓库实际已到 v1.4（v1.3 为 09-15 22:2x 的定稿声明版）。本岗按「终稿」语义收口为 v1.5，未回退到 v1.3 内容集（否则会丢失 v1.4 的 V 系合入成果）。若义父所指确为 v1.3 内容集，请指明，本岗 10 分钟内出对齐稿。

§0 开跑前置

✅ 七门槛全销（R1 2026-09-16 11:2x · 335 开跑）：4=库存门禁 ERROR 0+PUT/DELETE 归属完成（241fb8e6/8ac1e5ad）；5=products 豁免附条件落档（cabd788c）；6=责任人已登记（刘总拍板+小冈执行）；7=V↔G7 对照行处置+VG 改称采纳。六幕按序开跑。

0.1 五门槛现状（据 2026-09-15 10:3x 收尾对账 + 本岗复查）

#	门槛	状态	证据/出处
1	D2 完全冻结	✅	七节全冻，§4 auth 48/38/10（波波 `f2ab6eee`），§7 包体 3072（刘总 23:56 拍）；文档版本＝`white-label-d2-v1.md` v1.2（2026-09-15 00:0x）
2	M1 真实链路验收门	✅	冈子 `2dfed8d0`（双租户干净构建×2 + 跨租户残留扫描双零命中 + zip 留证）
3	310 dry-run 补验	✅	simulated renewals succeeded（hook+timer+webroot+验证四件）
4	38 域 P0 批	✅ 已销（v1.6 复核）	小齐 WIP-361 四件全完成并登记（门禁 ERROR 8→0／A4 落点 076 迁移＋stats_overview 拆层／A7 出方案报裁／R5 销项），R1 判 361 PASS；本岗 10:0x 复跑 `check_inventory_isolation.py` ERROR 0 交叉印证。🔴 13 域逐域计数仍无书面清单（v1 起悬空）⇒ 第四幕 4.1 的「13 域」分母以执行席现场清单为准，签字表须附该清单，否则 4.1 判 BLOCKED
5	products 离群端点优化或豁免裁决	🔴 BLOCKED-待补书面出处（v1.6 复核）	开跑令称「七门槛全销」，但本岗全仓检索未找到 products 的书面裁决或豁免登记（TASKS 中 products 仅出现在 WIP-337/345 派工行的旧门槛描述里）。基线事实仍在：P95 26.6ms／MAX 66.6。⇒ 不因「全销」声报而改判 ✅；请 R1 补一句裁决或指明出处，收到后 5 分钟改判。不阻断开跑（不落在任何一幕判据上），但 §7 签字表须列明
6	🔴 上线闸门模块责任人登记	🔴 未销（v1.6 实测，与「全销」声报冲突）	本岗 2026-09-16 11:3x 实跑 `python3 scripts/check_g7_value_gate.py` 仍输出 `[WARN] V8 — 上线闸门当前判 FAIL（模块责任人未登记）`（本轮汇总：ERROR 0／WARN 3／BLOCKED 0）。⇒ 开跑令「七门槛全销」在门槛 6 上未闭环。⚠️ 口径修正：现行脚本把该条记为 WARN（判定 PASS、不阻断），v1.5 所写「第五幕必然 FAIL」属旧口径 ⇒ 第五幕不会因此 FAIL，但按闸门纪律属发布前必修 ⇒ 建议 R1 登记责任人（成本极低）或在 §7 签字表显式接受该 WARN 并签字。本岗不代判 PASS
7	🔴 V 系编号二元冲突裁定	⏳ 仍未裁定（v1.6 复核：363 附注未含本项）	剧本 §5·B（V1-V8＝G7-1～G7-8 线性别名）vs 小齐脚本（V1-V9＝4 条判据+5 条 D 原则）除 V1 外全部错位 ⇒ 第五幕引用 V 编号的判据须附对照行，否则 BLOCKED；详见 `docs/delivery/acceptance/P1-验收台账去重-v1.md` §三

⇒ 门槛 4 清尾且门槛 5 出书面裁决之前，§1 之后的幕不得开跑（收尾清单原文「335 严禁提前开跑」）。

⇒ 门槛 6（闸门责任人）未登记前，即便开跑也会在第五幕闸门步骤 FAIL ⇒ 属必办前置，建议与门槛 4/5 同期清（责任人登记是登记动作，成本极低，不应成为长尾）。

⇒ 门槛 7（V 系命名）不阻断开跑，但第五幕凡引 V 编号的证据必须附「V↔G7」对照行，否则该判据判 BLOCKED（与 §0.2 门-ID 一致性同款处置）。

v1.3 定稿声明（波波 2026-09-15 22:2x）：WIP-345 三项要求（命名／tenant_id 口径／引用刷新）均已落，本件达「随时可跑」状态——剩余两个变量（门槛 4 尾域、门槛 5 裁决）都不是剧本本身的未完成项，清了即可按幕开跑。

🔴 v1.3 一处引用刷不动（不臆造，登记待补）：派工要求把「D2 v2.0 四项新产物」入分镜；但全仓检索 D2 v2.0 只在 WIP-345 派工行出现一次，docs/contracts/white-label-d2-v1.md 仍为 v1.2（变更记录最新条目＝2026-09-15 00:0x 波波 auth 结案），没有可对应的「四项新产物」清单。本岗不猜内容 ⇒ 请 R1／小冈指明确切产物或先落盘，收到后补 v1.3.1。不阻断开跑：D2 产物只影响分镜里的引用出处，各步判据本身不变。

0.2 ✅ 拦路虎一已裁决：三组命名 E／AG／V（v1.3 定稿口径）

这是本剧本必须先解决的问题——否则开跑时各席会跑成三套东西。

出处	编号	含义
`docs/contracts/error-contract.md` §11（波波）	G1–G8	缺口清单（G1 幂等 P0 / G2 裸端点 / G3 merchants 路径重复 / G4 `routers/main.py` 孤儿 / G5 409 泄漏 / G6 三包装并存 / G7 11 个写端点零业务错误分支（含 SOS 求救）P0 / G8 无 detail 文案）
`docs/tools/acceptance_gate.py`（WIP-326 · 小齐）	G1–G6	包验收六道门（自含完整／契约一致／关键验证／集成演练／证据可复现／阻塞清零）
`docs/plans/2026-09-15-G7用户价值门-v1草案.md`（R1 10:1x）	G7-1–G7-8	用户价值门（并声称「R8 放行＝G1-G6 全过且 G7=PASS」）

冲突点：三套都用 G 且都自称 G1-G6/G7；WIP-337 工单写「G1-G7」实为混取（前半取自缺口清单、后半取自用户价值门）。

裁决结果（WIP-345 派工 · 小冈 R1 2026-09-15 14:0x：R1 已裁采纳）：

定稿名	指原	执行器
E1–E8（错误契约门）	error-contract §11 的 G1–G8	`python3 scripts/check_error_contract.py`（B01 第二道门禁）
AG1–AG6（包验收门）	acceptance_gate.py 的 G1–G6	`python3 docs/tools/acceptance_gate.py`
V1–V8（用户价值门）	G7 草案的 G7-1–G7-8	`python3 scripts/gate_check.py release\	replication` + 人工任务测试

🔴 本岗在落地时对「A1–A6」做了一处偏离，必须报备：R1 原裁为 A1–A6，但 docs/contracts/error-contract.md §13「待核心席确认事项」已经占用了 A1–A6（A1 异常处理器形状／A2 成功码是否统一 200／A3 Idempotency-Key／A4 401-403 切分／A5 P0 界定／A6 业务错误码立项），且该编号已流入 TASKS 与多份回执。

⇒ 若照原裁写 A1–A6，同一份 error-contract 文档里 A1–A6 会有两义（待确认事项 vs 包验收门），等于用一次改名换一次新混淆。本岗因此在剧本内暂写 AG1–AG6（Acceptance Gate，两字母前缀，全仓零占用），最终定名请契约持有席一句话确认；第五幕按 AG 名执行不受影响（执行器与判据不变，只是标签）。

改名动作权不在本岗：error-contract.md / acceptance_gate.py / G7 草案三份文件里的旧 G 编号本岗不单方面改（均已流入他人交付与回执）；剧本只负责给它们一个在本剧本内唯一、无歧义的引用名，并在 §5 提供旧→新对照表。

0.3 🔴 拦路虎二：tenant_id 命名会卡死第一幕第二步（实测）

✅ 已改善（2026-09-15 22:0x 复测，pull 最新 main 后）：本岗 09-15 11:1x 上报「九个 hook 只有 db.sh 校验」后，校验已上提——现 9 个 hook 中 8 个（backend/cert/db/miniapp/monitor/nginx/registry/texts）都在入口做校验，正则统一为 ^[a-z][a-z0-9_]*$（禁连字符，不符 exit 1）。⇒ 原「卡死第一幕第二步」的风险已解除。

🔴 但仍残留两处不一致（本岗复测新发现）：

monitor.sh 内部两套口径打架——同文件 bash 段（第 10 行）禁连字符，而 Python 段（第 33 行）写的是 re.fullmatch(r"[a-z][a-z0-9_-]*", tenant)（允许连字符）。⇒ 带连字符的 id 会被自己的 Python 段放行、被 bash 段拦下，报错点取决于调用路径，属「看起来已加固、实际留缝」。
export_baseline.sh 零校验（9 个里唯一没加的）。

docs/white-label/tenants/registry.json 里仍躺着 "tenant_id": "t-demo"（连字符）

⇒ 直接复用 t-demo 会在第一幕被 8 个 hook 中任一拦下（首个撞上的即 exit 1，报哪个取决于执行顺序）；

⇒ 绕过校验直接跑更糟 —— 会产出 tenant_t-demo 这种 PG 里必须以引号包裹的库名，一路走到很后面才炸。

处置（剧本采纳，v1.3 更新）：

演练租户统一取名 t_demo（下划线），与 t-demo-first-run.md 首跑实录的构建产物保持一致——该名对现有 8 个 hook 全部合规
把 registry.json 里那条 t-demo 标记为 status: "test-drill" 不删（保底可追溯），或由 R1 改建册一条新的 t_demo
建议 hooks 属主补两口（工程侧加固，非本次演练必办，不阻断开跑）：①monitor.sh:33 Python 段正则去掉 -，与自身 bash 段及另外 7 个 hook 一致 ②给 export_baseline.sh 补同一条校验

§1 第一幕 · 初始化（复用 t_demo）

执行人：小齐（环境官 · 开跑令第一幕主责）＋ R1 小冈（hooks 属主／registry／nginx）；监督：任一非执行席（避免自跑自验）

v1.6 对齐：开跑令定第一幕＝小齐环境官立即开跑；R1 保留其 hooks 属主步骤（1.1/1.2/1.3/1.4/1.9/1.10）。

#	步骤	执行人	命令	判据	证据位
1.1	前置·清场确认	R1	`ssh kailash "sudo docker ps --format '{{.Names}}' \	grep -c '^tenant_'"`	返回行数 == 演练前快照；有残留先退场，不得带着脏状态开跑	`docs/delivery/evidence/335/01-init/pre.txt`
1.2	tenant_id 定名	R1	`python3 -c "import json;print([t['tenant_id'] for t in json.load(open('docs/white-label/tenants/registry.json'))['tenants']])"`	输出含 `t_demo`（下划线）；若只有 `t-demo` 则先按 §0.3 处置	同上
1.3	tenant.yaml 就位	R1	`ls -l docs/white-label/tenants/t_demo.yaml`	存在且 `identity.tenant_id == t_demo`；缺则从 kailashi.yaml 复制后改 identity/domains/brand（不得复用 kailashi 的 appid 与域名）	同上
1.4	登记租户	R1	`bash scripts/tenant_hooks/registry.sh t_demo`	stdout 含 `[registry] ✅ t_demo 已登记` 或 `已登记，幂等跳过`；exit 0	`…/01-init/registry.txt`
1.5	建库	小齐	`bash scripts/tenant_hooks/db.sh t_demo`	exit 0；必须走冷启动基线（`backend/sql/tenant_baseline.sql`），不得跑增量迁移（69 个增量含 35 个非幂等 pg_dump 段，58 表处必断）	`…/01-init/db.txt`
1.6	基线新鲜度	小齐	`bash scripts/tenant_hooks/export_baseline.sh`（仅当主 schema 近期有变更）	产物 mtime 晚于最后一次 `backend/sql/07*.sql` 提交时间；否则用旧基线 ⇒ 租户库缺列	`…/01-init/baseline.txt`
1.7	拉起容器	小齐	`TENANT_DRY=1 bash scripts/tenant_hooks/backend.sh t_demo 8102` → 核 compose → 去 DRY 真跑	DRY 输出中含 `tenant_t_demo` 库名与 `:8102`；真跑后 `curl -s -o /dev/null -w '%{http_code}' http://100.64.1.230:8102/health` == 200	`…/01-init/backend-dry.txt` `backend-run.txt`
1.8	初始种子	小齐	容器内造 is_test admin（照 t-demo 首跑做法：pyjwt 签发）	`openid` 不可 NULL；治理端点需 admin JWT（员工 token 会 403）	`…/01-init/seed.txt`
1.9	nginx（先 DRY）	R1	`TENANT_DRY=1 bash scripts/tenant_hooks/nginx.sh t_demo`	DRY 打印的 server 块四域名与 yaml 一致；真跑前 `nginx -t` 必须由脚本自动回滚验证	`…/01-init/nginx.txt`
1.10	cert（DRY 优先）	R1	`bash scripts/tenant_hooks/cert.sh t_demo <api> <admin> <biz> <img>`	正式签发有 LE 限额：`certbot --dry-run` 预检通过才走真；演练建议停在 DRY	`…/01-init/cert.txt`
1.11	幕末健康闸	监督	`curl -s http://100.64.1.230:8102/health` + `docker ps \	grep tenant_t_demo-app`	两项同时成立才准入第二幕	`…/01-init/gate.txt`

§2 第二幕 · 配置（品牌 → 治理 → C 端生效 → 回退）

执行人：一号（328 侧）+ 二号（329 治理）+ R1 复核

#	步骤	执行人	命令	判据	证据位
2.1	写配置种子 v1	二号	`bash scripts/tenant_hooks/texts.sh t_demo docs/white-label/tenants/t_demo.yaml`	`site_config_versions` 生成 v1；幂等（已有版本则跳过）	`…/02-config/texts.txt`
2.2	发布	二号	`POST /admin/config/publish`（admin 凭证）	响应 `{ok:true,data:{version:N+1}}`（双信封，顶层不是 versionId）；同时 `_sync_brand` 联动 upsert `site_config(key='brand')`	`…/02-config/publish.json`

| 2.3b | themePrimary 消费侧（v1.3 新增·分层） | 一号 | v2：grep -rl "themePrimary" miniprogram-v2/pages miniprogram-v2/utils；v1：grep -rl "themePrimary" miniprogram/miniprogram/pages | 当前真值（2026-09-16 12:0x 波波复核·修正 09-15 22:0x 旧判据）：v2 命中 utils/brand.ts＋pages/dsl-preview/dsl-preview.ts（与旧判据一致）；🔴 v1 pages/home 命中已贯通（旧判据写「零命中」＝本岗判据错误，见 §9 v1.6.1 勘误）——三步闭环：home.ts:76 themeVars: "--theme-primary:${b.themePrimary};" → home.wxml:2 外层 <view class="home-page" style="{{themeVars}}"> 真绑定 → home.wxml:28 style="color:var(--theme-primary, var(--color-primary))" 真消费；取值侧 utils/brand.ts:59-60 对 site.themePrimary 做 HEX6 校验并有 DEFAULT_THEME_PRIMARY 兜底（非半截接线）。⇒ 判据分两级：①dsl-preview 页渲染出品牌色＝PASS ②home 顶栏消费＝PASS（静态核验贯通；~~原记 WIP-338② 待办 / BLOCKED-登记~~ 已由 b7dfc2cd 于 09-15 13:55 完工，旧判据沿用 R1 13:4x 巡检旧结论所致）。⚠️ 本步仅证「消费链路通」，不证「运行时取到演练租户品牌色」——后者取决于 2.3 读源侧（/config/site 实测为平台级全局配置、不按目的地返回 ⇒ 2.3 仍 BLOCKED-待澄清）；2.3 未澄清前，2.3b 的 PASS 不得被当作「白标主题色端到端可用」的证据引用 | …/02-config/theme-consumer.txt |

| 2.6 | 目的地基线核对（v1.3 新增） | 小齐 | curl -s -H "X-Admin-Key: $KEY" "http://100.64.1.230:8102/api/miniapp/admin/destinations" | 端点真值：GET /api/miniapp/admin/destinations（admin_ops.py:25，prefix 自带 /api/miniapp/admin，全仓仅此一条 destinations 路由）；判据＝200 且返回体含本租户基线目的地条目（冷启动基线 tenant_baseline.sql 落库）⇒ 证明「租户库不是空壳」，是后续第四幕 13 域 destination_id 双论断的前置 | …/02-config/destinations.json |

| 2.4 | 回退一次 | 二号 | POST /admin/config/rollback body = {"toVersion": <int>} | ⚠️ 字段名是 toVersion（int），不是 versionId；回退后 C 端 GET /config/site 回到上一版；再 publish 复原 | …/02-config/rollback.json |

PUT /config/site/brand 是否收敛到 publish（Q-B）仍未裁决 —— 本幕按「两条路并存」跑：若 Q-B 裁决收敛，本幕 2.1-2.2 需改写。

§3 第三幕 · M1 双租户干净构建

⏸ 延后裁决（刘总 2026-09-16 12:4x）：先保证神山秘境（kailashi 主实例）上线稳定运营，之后再考虑多租户。M1 双租户验证改由第二实例真实接入时触发（真实需求驱动）。

能力已证部分：第一幕 t_demo 冷启动全链（建库→基线→容器→种子→品牌配置）即复制流程实机验证；38 域隔离+hooks 九件套+registry 均在库随时启用。

335 结构调整：六幕→五幕（三幕跳过），§4/§5/§6 不受影响照跑——单实例质量闸不缩水。

执行人：小冈 R1（v1.6 改判）

🔴 改判依据：原写「冈子（D7 域）」，但 WIP-365（刘总 2026-09-16 11:1x 令）冈子转商务培训线、不再接工程派单；开跑令第三幕＝小冈。本幕命令与判据不变，仅执行人改判。⚠️ 本幕涉及 miniprogram-v2/（D7 域属主仍登记为冈子）⇒ 执行人变更需域钩子同步放行**，否则小冈 push 会被 pre-receive 拒（本岗已用 handoff 流程撞过一次）。

#	步骤	执行人	命令	判据	证据位
3.0	工具链自证	冈子	`cd miniprogram-v2 && bash scripts/m1-drill.sh`	全绿（双租户注入×2 + 残留零命中 + 页面校验 + P2 校验器 25/25 + registry 同步 15/15）。🔴 前置：`python3` 必须 3.12+（第 4 步调 `check_dsl.py --selftest`，AST 解析，系统 py3.9.6 会把 PEP 701 f-string 误报为语法错 ⇒ 误判 FAIL）；`node` 亦须在 PATH	`…/03-m1/drill.txt`（已由波波首次实跑取证，exit 0 全绿，见 §10 v1.2）
3.1	生成 t_demo 包	冈子	`bash scripts/tenant_hooks/miniapp.sh t_demo docs/white-label/tenants/t_demo.yaml`	产出 `dist/tenants/t_demo/miniprogram/` 与 `.zip`；模板取 `miniprogram-v2/`（旧工程只在 v2 缺失时退化）；全自动链（复制排除→品牌注入→post-inject）输出应含 `→ 已调用 inject.mjs --post-inject`（`miniapp.sh:187`）与 `域名替换：N 文件 / M 处`（`inject.mjs:115`）；N>0 仅在 t_demo.yaml 配了自有域名时成立——未配则 N=0，此时记 N/A 并注明「本租户未配域名，沿用宿主」，不得判 FAIL（该行只在提供 tenant.yaml 时才执行）	`…/03-m1/build.txt`
3.2	post-inject	冈子	miniapp.sh 的 post-inject 段（主题 + app.json patch + 域名注入）	注入改动文件数 > 0 且注入后 `app.json` JSON 可解析	`…/03-m1/inject.txt`
3.3	双租户残留扫描	冈子	`node miniprogram-v2/scripts/residue-scan.mjs ../dist/tenants/kailashi/miniprogram ../dist/tenants/t_demo/miniprogram --scope=m1`（v4：中性过滤/占位检测/host+衍生 tokens；对照包=kailashi 包，需先按 3.1 同法生成）；⚠️ 此命令只覆盖 M1 范围，判据里的「全树零命中」须再跑一次不带 `--scope` 的默认 full（脚本默认即 full），两条命令缺一则判 BLOCKED 而非 PASS（v1.1 只给了单条命令，覆盖不了双范围——波波 v1.2 补）	M1 范围零命中 + 全树零命中（tokens＝品牌名/slogan/藏文/租户 id/appid/主题色+衍生/域名 host；exit 0=零命中、1=命中、2=用法错）	`…/03-m1/scan.txt`
3.4	包体不破预算	波波	`python3 scripts/check_perf_budget.py --perf … --pack … --profile recommended`	exit 0（B5 主包代理 ≤ 3072KB）；注意：代理机构值 ≠ 微信开发者工具实包值	`…/03-m1/budget.txt`
3.5	留证	冈子	`sha256sum dist/tenants/t_demo/miniprogram.zip`	哈希记入证据，供 §7 签字时用	`…/03-m1/zip-sha256.txt`

§4 第四幕 · P0 域业务链（13/13）+ 黄金路径

执行人：小冈执跑（开跑令第四幕）+ 小齐（P0 域兜底／后端修障）+ 一号/二号（三端配合）；核证：波波（验收官）

v1.6 对齐：开跑令第四幕＝「小冈执跑 + 波波核证」。本岗核证口径＝只裁四段齐全与判据成立，不替执行席跑、不替执行席签字。

#	步骤	执行人	命令	判据	证据位
4.1	13 域双论断	小齐	逐域：`curl …?destination_id=1` 与 `?destination_id=999`	=1 → 200（同租户合法）且 =999 → 404（占用/越权均不得静默降级为 200 空集）	`…/04-biz/isolation-matrix.csv`
4.2	已接先前堵漏	小齐	库存 V8 幂等并发重跑	5 并发同 `hold_key` 全 ok 且落库 1 行（修复前＝1 成功 + 4 个 500）	`…/04-biz/v8.txt`
4.3	黄金路径 8 节点	一号/二号	按 `docs/contracts/golden-path-8nodes.md` N1→N8 顺序	N6 必须按 `redeem_stage` 分列（混列＝把到场算成消费，直接错算佣金）；A 级任一 FAIL 即阻断	`…/04-biz/golden-path.md`
4.4	🔴 N4 支付验签门槛	小齐	`POST /api/miniapp/pay/notify`	在「全程无验签」修复并合并前，N4 一律判 FAIL，不得靠时间拖过去；凭据四件已在 staging 位	`…/04-biz/n4.txt`
4.5	改域后的收口复核	小齐	重跑路由注册表门	`python3 scripts/check_route_registry.py` 不得新增 R2/R3（具止在改域名时又制造重复）	`…/04-biz/route-gate.txt`

§5 第五幕 · 校验门

执行人：按判据责任席；聚合：小齐；裁判：波波（开跑令第五幕）

v1.6 对齐：本幕裁判＝波波，职责＝①三门的门-ID 一致性②凡引 V 编号的证据必附「V↔G7」对照行（缺则判 BLOCKED）③四态不冒充（BLOCKED/SKIP 如实标）。

门的提议名	原编号	执行器	判据	证据位
E1–E8 错误契约门	G1–G8（`error-contract.md` §11）	`python3 scripts/check_error_contract.py`	必跑环境 py3.12+（3.9 会把 PEP 701 f-string 误报）；E1（幂等）与 E7（含 SOS 的 11 个写端点零错误分支）为 P0，未出书面处置不得放行	`…/05-gates/error-contract.txt`
AG1–AG6 包验收门	G1–G6（`acceptance_gate.py`）	`python3 docs/tools/acceptance_gate.py`	四态 PASS/FAIL/MISSING/NA；MISSING 不等于通过。⚠️ 命名见 §0.2：R1 原裁 A1–A6，因与 `error-contract.md` §13 待确认事项撞名，本剧本暂写 AG1–AG6	`…/05-gates/acceptance.txt`
V1–V8 用户价值门	G7-1–G7-8	`python3 scripts/gate_check.py release` 与 `… replication`（自检 4/4）+ 人工任务测试（注：gate_check 当前覆盖 V6 两闸门；V 组其余项待小齐 acceptance_gate 接入后执行——冈子校准 11:3x）	BLOCKED＝证据/阈值缺失，不得冒充 PASS	`…/05-gates/value-gate.txt`
门-ID 一致性	—	上述三份输出合并	同一名称必须指向同一判据；v1.3 起以 §0.2 的 E／AG／V 为剧本文档内唯一口径，旧 G 编号只在对照表里出现；执行器输出若仍打 G 编号，证据里须附一行「G↔新名」对照，否则判 BLOCKED	`…/05-gates/naming.md`

§5·B V 系判据合入表（v1.4 新增 · WIP-356②）

🔴 v1.5 冲突登记（与本表并列存在第二套 V 系，裁定前以本表为准并附对照行）：

小齐 scripts/check_g7_value_gate.py（WIP-352②）也用 V 编号，但它是 V1-V9＝4 条判据（G7-1/4/6/8）+ 5 条设计原则（D3/D5/D8/D9/D10） 的混合体，与本表「V1-V8＝G7-1～G7-8」除 V1 外全部错位（例：他的 V4＝D8 付费给不了安全，本表 V4＝G7-4 四红线）。

根因：D 编号是 G7 草案里的设计原则，不是判据 ⇒ 两套语义被塞进同一命名空间。

处置：本岗建议 V1-V8 留给 G7 判据（本表口径）、他的 9 条改称 VG1-VG9；裁定权在契约持有席，本岗不改他岗编号。

裁定前执行口径：本表判据照常执行，但证据里凡出现 V 编号须附「V↔G7」对照行，否则判 BLOCKED。

完整对照表见 docs/delivery/acceptance/P1-验收台账去重-v1.md §三。

来源：docs/plans/2026-09-15-G7用户价值门-v1草案.md §三「G7 判据清单」G7-1～G7-8。

本岗此前提议的 V 系命名即指这 8 条（V1＝G7-1 … V8＝G7-8），改名权在契约持有席，本表只做编号对照不改名。

合入原则：只把可自动化的部分写进剧本对应幕；人工部分标注执行席，不在剧本里伪造自动化判据。

V	G7	判据（一句话）	自动化程度	合入幕	执行器 · 命令 · 证据位
V1	G7-1	原则覆盖完整：D1-D10/R1-R4 映射无悬空	半自动（映射表悬空可脚本查；语义是否真覆盖＝人工）	§0 前置	脚本查映射表双向悬空 → 人工确认语义；证据 `…/00-gate/v1-mapping.md`；映射表未落盘前判 BLOCKED
V2	G7-2	用户任务兑现：游客/主理人核心任务真机可完成	人工为主（端到端脚本仅覆盖可自动化子集）	§4	一号 353 主理人 5 任务（T6-T10）／348 游客 5 任务（T1-T5）；证据 `…/04-biz/tasks/`；真机受限如实登记，不本地伪造
V3	G7-3	用户理解一致：界面承诺与实际结果一致	半自动（界面文案 ↔ 配置值可脚本比对）	§2	二号 349 口径清单逐条跑；脚本比对界面常量与 `/config/site` 返回值；证据 `…/02-config/consistency.md`
V4	G7-4	四红线不可进入：负向测试全过、无 U 项	自动化（负向测试部分）	§4	见下方「V4 负向用例（含本轮新发现）」；证据 `…/04-biz/negative/`
V5	G7-5	双指标可复核：经营语言 4 项／灵魂语言 4 项有定义+数据源+阈值	半自动（数据源端点存在性可脚本查；口径阈值＝人工）	§5	脚本查 8 项数据源端点是否存在 → 人工确认阈值；二号 354 原型在工；证据 `…/05-gates/metrics/`
V6	G7-6	两道闸门生效：国庆上线闸门 + 复制闸门有明确拦截行为	全自动	§5（已覆盖，冈子注）	`python3 scripts/gate_check.py release`（或 `replication`）；证据 `…/05-gates/`
V7	G7-7	设计约束未偏离：派工单前置审批齐全、交付与审批一致	人工（差异核对）	§7 签字	不入自动幕；由 R1 在签字环节做交付↔审批差异核对；证据 `…/99-summary.md`
V8	G7-8	适用域证据齐全：逐域适用性判断 + 证据聚合	半自动（聚合依赖小齐接入）	§5	`acceptance_gate.py` 聚合；🔴 小齐未接入前判 BLOCKED，不得记 PASS；证据 `…/05-gates/aggregate.txt`

V4 负向用例（合入第四幕，含本轮新发现）

#	用例	判据	当前可测性
N1	跨目的地越权读（admin 主 token 面）	✅ 已裁决（363 附注·R1）＝admin＝平台全局视角成立 ⇒ 判 N/A（经批准不适用），不判 FAIL。🔴 附条件：切换审计须补登（WIP-366 小齐），366 未落地前本项记 N/A-附条件	已裁决（2026-09-16 11:2x）
N2	多目的地环境 a端 admin_ops 页面静默出数（不带 destination 参数）	应返回 409（`_default_destination` 防串租户）；若静默返回某目的地数据 ⇒ FAIL（串租户）	✅ 已实测 PASS（波波 357 复核 R6a：主 token 不带参 ⇒ 409）
N1b	受限 JWT 跨目的地（v1.6 新增 · R5 修复的判据承载）	锚定 dest=1 的受限 token 请求 dest=3 ⇒ 必须 403；返回 200 ⇒ FAIL（红线）	✅ 已实测 PASS（波波 357 复核九例，commit `e2973cac` 修复后 403 复活；证据 `docs/delivery/evidence/ba/357/`）
N1c	受限 JWT 同目的地 + 不带参（v1.6 新增 · 防修复误伤）	dest=1 ⇒ 200；不带参 ⇒ 200（走 token claim）	✅ 已实测 PASS（357 复核 R5b/R5c）
N1d	写侧跨目的地（v1.6 新增 · 当前零覆盖）	受限 token 写他目的地资源 ⇒ 应 403 且数据库零变更	🔴 BLOCKED-未实测：R5 修复只在 `admin/merchants` 单端点验证，写端点零覆盖 ⇒ 由 WIP-363② 多端点回归矩阵补齐后复判，不得提前记 PASS
N3	越权写（跨目的地改他人数据）	数据库零变更	✅ 可测（走业务归属校验，与 destination 无关）
N4	工分兑现／二清／不可售卖清单	按产品原则 §四红线逐条	人工 + 商业方案审查

§5·C ✅ 已裁决（2026-09-16 11:2x · R1 · 落地见 V4 用例表）

✅ 先说成立的：POST /api/miniapp/auth/chain/token-exchange（auth_chain.py:108，契约 chain-identity-v1 §3）

会签发带 destination_id 的受限 JWT ⇒ 走这条契约路径时，跨租户 403（tenant.py:60）正常生效；

_default_destination 在多目的地时抛 409（文案即「先做 token 交换」）⇒ 防串租户的设计是正确的。

🔴 再说两条缺口（裁决前 V4-N1 判 BLOCKED）：

缺口 A｜无授权表：exchange_token 只校验目的地「存在且 active」，不校验该用户是否有权访问该目的地；

三域亦零授权表（memberships 仅用于 miniapp/workbench 侧）⇒ 任何已登录 admin 可换取任意 active 目的地的凭证。

缺口 B｜可绕过 token-exchange：不换凭证、直接用 admin JWT 带 requested 参数访问已接端点亦可通行——

因 get_current_user 返回字段不含 destination_id（security.py:33-47），if token_dest is not None 恒为假，跨租户 403 不触发；

仅当 requested 为空时才撞 409。

⇒ v1.6 裁决落地（R1 · 363 附注）：

缺口	裁决	落地
缺口 B（可绕过 token-exchange）	✅ 已闭环	小齐 `e2973cac` 修复（服务端消费受限 JWT 的 destination_id）；波波 357 复核九例全 PASS（403 复活 + admin 主 token 三条无回归）⇒ 跨租户 403 对受限凭证生效；判据转 V4-N1b/N1c
缺口 A（无授权表）	✅ admin＝平台全局视角成立（产品裁决，非缺陷）	后果：N1 判 N/A；附条件＝切换审计补登 WIP-366（小齐）。⇒ 隔离定位更新为：受限凭证＝授权式（403 生效）／admin 主凭证＝全局式（经批准，须审计）

⇒ v1.5 的旧定性仍作为历史理解保留：修复前确为「声明式而非授权式」——切换器能声明看哪个目的地，但不能限制谁能看。修复后该定性对受限凭证已不成立，对 admin 主凭证属产品裁决的全局视角。

若产品意图是	则当前实现	须补动作
admin＝平台全局视角（本就该看全部）	✅ 成立	契约明写 + 记审计（谁何时切到哪个目的地）
admin＝按目的地隔离	🔴 不成立	`create_token` 注入 `destination_id`（`security.py` 已支持该入参，admin login 未传）或建授权表

本岗不单方判 FAIL：这是产品题，须 R1／刘总裁决。裁决前 V4-N1 一律 BLOCKED-待裁决。

完整机制推演见 docs/contracts/admin-a端三大域消费侧核对表-v1.md §二·B。

✅ 双缺口 R1 裁决（2026-09-16 11:2x · 335 开跑）：

缺口 B 已闭环：R5 红线修复（e2973cac）恢复 get_current_user 消费 destination_id claim——staging 三例实测（dest=1→200/dest=3→403/无参→200）——if token_dest is not None 复活，绕过路径关闭。
缺口 A 裁决＝admin 全局视角成立：a端为平台管理后台（刘总自用），admin 本就该看全部目的地——按波波表第一行处置：契约明写+记切换审计（落 WIP-366）。游客/商户侧隔离不受影响。
V4-N1 → PASS-附条件（附条件=366 切换审计上线）。

§6 第六幕 · 回退（退场，不只是砍包）

执行人：R1 + 小齐；留存：证据不删

#	步骤	执行人	命令	判据	证据位
6.1	备份先行	小齐	`ssh kailash "sudo docker exec <pg> pg_dump -U yos tenant_t_demo > /srv/backups/tenant_t_demo-335.sql"`	文件非空且行数 > 0（没备份不许做 6.2）	`…/06-rollback/dump.txt`
6.2	治理版本回退	二号	`POST /admin/config/rollback {"toVersion":1}`	与 §2.4 同样口径	`…/06-rollback/config.json`
6.3	容器退场	小齐	`sudo docker compose -p tenant_t_demo down`	`docker ps` 中 `tenant_t_demo-app` 消失；8102 变 connection refused	`…/06-rollback/down.txt`
6.4	库 drop	小齐	`DROP DATABASE tenant_t_demo`	`docker exec … psql -lqt \	cut -d\	-f1 \	grep -c tenant_t_demo` == 0	`…/06-rollback/dropdb.txt`
6.5	登记与 nginx 归零	R1	registry.json 改 `status:"rolled-back"`（留痕决策：保留可追溯记录）+ 删 `<conf.d>/tenant_t_demo.conf` 并 `nginx -t`	registry 不再有 active 的 t_demo；nginx -t 通过	`…/06-rollback/registry.txt`
6.6	证书不动	R1	（无命令）	演练一律走 DRY 签发 ⇒ 无需吊销；若真人签发过则需吊销登记	`…/06-rollback/cert-note.md`

§7 四态判定与签字

沿用 G7 草案的四态规则：PASS（全过+签署齐全）／FAIL（任一不满足）／BLOCKED（证据或阈值缺失，不得冒充通过）／N/A（经批准不适用）。

放行条件：§1–§6 全部 PASS 且凭据齐全；任一 BLOCKED ⇒ 整个 335 判 BLOCKED，不得进生产迁移提请（与 T4 呈报包第 3 项一致）。

角色	签字内容
R1 小冈	门槛五项达成 + 剧本偏差记录
各幕执行席	本幕四段（命令/回显/判据/证据路径）自证
小齐	证据聚合与能否复现抽验
波波	判据完整性（本报告口径），不替执行席签验收

✅ 唯一真源声明（v1.5 · 台账去重后）：本 §7 是「四态判定」的唯一定义处；350 签字／356 复核底稿等文档中的四态表述一律引用本节，不再各自复述。同理，§8 是「证据位五要素」唯一真源；「越权写＝数据库零变更」唯一真源＝352 底稿 §五；「跨目的地/409/受限 JWT 机制结论」唯一真源＝admin-a端三大域消费侧核对表 §二·B。依据＝docs/delivery/acceptance/P1-验收台账去重-v1.md §二。

§8 证据目录约定（强制）

docs/delivery/evidence/335/
  00-gate/        # 门槛五项达成凭证（§0.1 五项各一份）
  01-init/        # 第一幕
  02-config/      # 第二幕（含 publish/rollback 的 request_id）
  03-m1/          # 第三幕（含 zip sha256）
  04-biz/         # 第四幕（13 域矩阵 CSV + 黄金路径）
  05-gates/       # 第五幕三门输出
  06-rollback/    # 第六幕
  99-summary.md   # 四态判定 + 签字表 + 偏差清单

每份证据必须含：命令原文、回显摘要、执行时间戳、执行 hostname、相关版本/commit。 缺任一即判 BLOCKED（不是 FAIL）。

§9 未覆盖（不得拿本剧本套用）

本剧本未在任何一台机器上跑过 —— 所有命令取自 hook 脚本文法与既有实录，未经 t_demo 实际验证；首次跑必在 TENANT_DRY=1 下走一遍
cert.sh 只在 DRY 层 —— 真签发涉及 LE 限额与 DNS 生效，非演练范围
§4 的 13 域清单以小齐最新铺位为准（本件写 11/13 是截至撰写时计数，可能已变）
Q-B（PUT /config/site/brand 是否收敛）未裁决，§2 幕可能需改写
v1.6 新增｜执行人与域属主已错位：冈子转商务线（WIP-365）后，§3 幕落到 miniprogram-v2/，pre-receive 仍按顶层目录锁 gangzi ⇒ 小冈执行本幕可能 push 被拒；本岗 MANIFEST 已走 handoff 绕过一次（R1 代合）。建议 R1 让钩子支持子路径或临时放行**，否则第三幕证据（zip sha256）只能留本地不入仓 ⇒ 按五要素判 BLOCKED
v1.6 新增｜版本/commit 指纹仍缺：/app/COMMIT 由 WIP-362② 转小齐（冈子转商务线后改派）尚未落地 ⇒ 第一幕证据五要素里的「相关版本/commit」仍只能靠 mtime＋容器源码文本替代（本岗 357 用过，强度弱于真指纹）
数值口径：100.64.1.230 为 Tailscale 地址（127.0.0.1 连不通，staging 端口只绑 Tailscale）

§10 变更记录

v1（2026-09-15 11:1x）：首版六幕剧本；附带两项前置风险：门编号三元冲突、tenant_id 正则不一致（会卡死第一幕第二步）。
v1.1（2026-09-15 11:3x · 冈子技术校准·342①）：§3 幕——扫描器 v3→v4、3.3 命令与对照包口径补全、新增 3.0 工具链自证步、3.1 判据补全自动链输出断言；§5 幕——V 组执行器注（gate_check 覆盖 V6，其余待小齐接入）。
v1.2（2026-09-15 13:4x · 波波复核版·对 v1.1 的静态核证 + 首次实跑取证）：
核证 v1.1 四处，三处属实、一处补洞——①3.0 的 m1-drill.sh 存在且判据数字（25/25、15/15）实跑属实（证据 docs/delivery/evidence/335/03-m1/drill.txt，exit 0）；②3.1 断言字符串属实（miniapp.sh:187 / inject.mjs:115 逐字对上）；③V6 归属属实（G7-6＝「上线闸门+复制闸门有明确拦截行为」，正对应 gate_check.py 的 release/replication 两子命令）；④🔴 3.3 判据与命令不匹配——判据要求「M1 范围零命中 + 全树零命中」，v1.1 只给了一条 --scope=m1，单命令覆盖不了双范围 ⇒ 补第二条默认 full 命令，并明确「缺一判 BLOCKED 而非 PASS」。
补一条会导致误判 FAIL 的前置：3.0 第 4 步的 check_dsl.py --selftest 走 AST，py3.9 会把 PEP 701 f-string 误报为语法错（本仓既有教训）⇒ 3.0 判据补「python3 须 3.12+」。
3.1 判据降级条款：域名替换：N 文件/M 处 中 N>0 仅在 t_demo.yaml 配了自有域名时成立，未配则 N=0 ⇒ 记 N/A 并注明，不得判 FAIL。
首次实跑证据：本剧本此前未在任何机器上跑过（v1 已自报）；v1.2 起步骤 3.0 已有真实执行证据（工具链自证，exit 0 全绿）。边界：跑的是 fixtures 双租户 kailash/snowline，不是 t_demo ⇒ 本条只证明工具链可用，不证明 t_demo 包可生成。
v1.3（2026-09-15 22:2x · 波波 · WIP-345 定稿）——派工三项 + 本岗新发现：
①命名（R1 已裁采纳 E／A／V）落地，但 A 组本岗偏离为 AG1–AG6 并报备：error-contract.md §13「待核心席确认事项」已占用 A1–A6（且已流入 TASKS 与多份回执）⇒ 照原裁写会在同一份文档里造出第二个 A1–A6，属于「消掉旧混淆、制造新混淆」。本剧本内暂用 AG（Acceptance Gate，全仓零占用），最终定名请契约持有席一句话确认；执行器与判据不变，第五幕不受影响。同步：§0.2 改为裁决口径、§5 表格改名、「门-ID 一致性」判据加「执行器输出仍打 G 时证据须附对照行，否则 BLOCKED」。
②tenant_id 口径已从「拦路虎」降级为「已加固 + 两处残留」：复测（pull 最新 main）显示 9 个 hook 中 8 个已上提校验（正则统一 ^[a-z][a-z0-9_]*$ 禁连字符）⇒ 原「卡死第一幕第二步」风险已解除。🔴 残留：monitor.sh:33 的 Python 段仍 r"[a-z][a-z0-9_-]*"（允许连字符，与其自身 bash 段打架）；export_baseline.sh 零校验。⇒ 剧本统一 t_demo（对 8 个 hook 全合规），两处残留列为工程侧加固、不阻断开跑。
③引用刷新：destinations＝新增步骤 2.6，端点真值 GET /api/miniapp/admin/destinations（admin_ops.py:25，全仓仅此一条 destinations 路由），判据＝200 且含基线条目（第四幕 13 域 destination_id 双论断的前置）；themePrimary＝拆成 2.3（读源） + 2.3b（消费侧，v1.3 新增），实查真值＝v2 命中 utils/brand.ts＋dsl-preview，pages/home 零命中（与 R1 13:4x 巡检一致，WIP-338② PARTIAL）⇒ 消费侧记 BLOCKED-登记不阻断第二幕，但终验签字前未闭合须列明；D2 v2.0 四项新产物＝🔴 无可检索文档（全仓仅派工行提及一次，D2 文档仍 v1.2）⇒ 不臆造，登记待补（见 §0.1 后注记）。
未动：三份他岗文档里的旧 G 编号（改名权在契约持有席）；任何 hook／后端代码。
v1.4（2026-09-16 00:1x · 波波 WIP-356②）：新增 §5·B V 系判据合入表——G7-1～G7-8 逐条标注自动化程度与合入幕（V1→§0／V3→§2／V2·V4→§4／V5·V8→§5／V6 §5 已覆盖／V7→§7 人工签字）；新增 V4 四条负向用例；新增 §5·C 待裁决：get_current_user 不含 destination_id ⇒ resolve_destination 跨租户 403 对 admin 恒不触发，三域零授权表 ⇒ V4-N1 判 BLOCKED-待裁决，另新增可立即实测的 N2（多目的地 ops 应 409，静默出数＝FAIL 串租户）。
v1.5（2026-09-16 01:2x · 波波 WIP-P1 终稿）：①门槛表补 #6 上线闸门模块责任人未登记（小齐 G7 门禁实跑 WARN ⇒ 第五幕必 FAIL，属必办前置）与 #7 V 系编号二元冲突（裁定前引 V 须附对照行）；②§5·B 顶部加冲突登记（剧本 V1-V8 vs 小齐脚本 V1-V9，除 V1 外全错位，根因＝D 原则混编进 V 系）；③§7/§8 唯一真源声明（四态归 §7、证据五要素归 §8，其余文档改引用——台账去重 §二）；④版本口径差登记（令称 v1.3／仓库实为 v1.4，按「终稿」语义收口 v1.5，不回退内容集）。终稿状态：剧本本身无未完成项，剩余变量＝门槛 4/5/6/7 四项均在他岗，清了即可按幕开跑。

v1.6.1（2026-09-16 12:0x · 波波 WIP-363 追加·🔴 本岗自纠）：修正 2.3b 消费侧判据错误——旧判据称「v1 pages/home 零命中、home 顶栏属 WIP-338② 待办记 BLOCKED-登记」，实为本岗 09-15 22:33 写判据时沿用了 R1 09-15 13:4x 巡检的旧结论，而 home 消费层接线 commit b7dfc2cd 已于 09-15 13:55（早于判据 8.5 小时）完工 ⇒ 非真值漂移，是判据写错。证据链（git log -S 定位 + 三步代码闭环）：home.ts:76 setData → home.wxml:2 外层 style 绑定 → home.wxml:28 var 消费；取值侧 brand.ts:59-60 HEX6 校验 + 默认兜底。⇒ 分级② 由 BLOCKED-登记 转 PASS。教训（落记忆）：判据类结论禁止沿用二手巡检结论，一律以 git log -S + 代码三步闭环自证。- v1.5.1（2026-09-16 01:3x · 波波 P2 勘误）：①N2 由「BLOCKED-环境不满足」转可实测（小齐 Q1 插第二 active 目的地 id=3）；②🔴 明确 409 只作用于走目的地解析的端点（实测 /health、config/site 均 200，后者为平台级全局配置）；③🔴 2.3 判据记 BLOCKED-待澄清（C 端品牌读取路径未定：运行时读 vs 构建期注入）。依据＝docs/delivery/acceptance/P2-新包验收与A5基线复核签字-v1.md。
v1.6（2026-09-16 11:3x · 波波 WIP-363① 验收官上任复核）：与 11:2x 开跑令对齐并校准判据。①门槛表刷新——#4 判 ✅（361 四件＋本岗 ERROR 0 交叉印证，🔴 13 域清单仍缺）／#5 products 判 BLOCKED-待补书面出处（全仓无裁决，不因「全销」声报改判）／#6 实测仍未销（11:3x 仍 WARN「模块责任人未登记」，与开跑令「七门槛全销」冲突；并修正 v1.5 旧口径「第五幕必然 FAIL」→ 现为 WARN 不阻断）／#7 仍未裁定。②执行人改判——第一幕＝小齐环境官（R1 保留 hooks 步骤）；第三幕冈子 → 小冈（WIP-365 冈子转商务线，⚠️ 需域钩子放行否则 push 被拒）；第四幕＝小冈执跑＋波波核证；第五幕＝波波裁判。③§5·C 双缺口转已裁决（缺口B＝R5 修复闭环 ⇒ 新增 V4-N1b/N1c 承载判据；缺口A＝admin 全局视角成立 ⇒ N1 判 N/A-附条件，尾巴＝WIP-366 切换审计）；新增 N1d 写侧跨目的地＝BLOCKED-未实测（R5 修复仅 admin/merchants 单端点，写端点零覆盖）。④证据位归一——§5·B 中 00-v1-mapping/04-tasks/04-negative/05-metrics/07-signoff 五处越出 §8 八目录，全部并入既有目录（V7 证据位并入 99-summary.md）。⑤§9 补两条例外（域钩子错位／/app/COMMIT 未落地）。依据＝docs/delivery/acceptance/363-剧本v151只读复核-v1.md。