WIP-363② · R5 回归面加宽：多端点回归矩阵（草案 v1 + 首轮试点实测）

目的：R5 修复后，回归面只有 admin/merchants 单端点、写端点零覆盖 ⇒ 补一张可复用的多端点矩阵，并先跑一轮试点验证矩阵可用。

本岗边界：方案/验收检测岗，不改任何后端代码；实测只走拒绝侧（不产生业务数据变更，探针副作用见 §五）。

四态口径引用剧本 §7；证据五要素引用 §8。

一、矩阵设计（覆盖度底数）

静态盘点（backend/app/routers/*.py，按「函数内出现 resolve_destination」计数）：

类	数量	说明
消费点总行数	79	含同一函数内多次调用
GET（读）	34	跨目的地应 403
POST	16	写端点
PUT	3	写端点
DELETE	4	写端点
未归属到装饰器（helper/其它）	22	需人工分派

写端点函数清单（23 个，去重后）：admin_backend（create/update/delete cms_post、sign_merchant、update_merchant_status、intervene_order、create/update/delete product、add/delete component、admin_execute_refund）／admin_distribution（risk_ruling、admin_generate_bills）／admin_ops（create_merchant、create_temple、delete_temple）／miniapp_pay（prepay）／miniapp_workbench_redeem（redeem_arrival）／safety（trigger_sos、cancel_sos、submit_assessment、submit_health_check）。

二、矩阵判据（三条，可直接当门禁）

组	用例	判据	安全等级
R-1 读·跨目的地	受限 JWT(dest=1) + `?destination_id=3`	403（200 ⇒ FAIL：串租户或未接线）	安全（只读）
R-2 读·同目的地	受限 JWT(dest=1) + `?destination_id=1`	200（非 200 ⇒ 端点路径错或未接线）	安全（只读）
W-1 写·拒绝侧	受限 JWT(dest=1) + `?destination_id=3` + 最小合法体	非 2xx，且数据库计数零变更	拒绝侧不落库 ⇒ 不产生业务数据变更；若返回 2xx 立即停跑并报残留

W-1 的安全依据是既有判据：「越权硬断言＝拒绝时数据库零变更」。故写端点无需造业务数据即可实测。

三、首轮试点（2026-09-16 11:36，staging `100.64.1.230:8089`）

#	端点	用例	期望	实测	判
A1	`/api/miniapp/admin/merchants`	跨=3／自=1	403／200	403／200	✅ PASS
A2	`/api/admin/cms/posts`	跨=3／自=1	403／200	403／200	✅ PASS
A3	`/api/miniapp/admin/content/pois`	跨=3／自=1	403／200	200／200	🔴 FAIL
A4	`/api/admin/stats/overview`	跨=3／自=1	403／200	403／200	✅ PASS
A5	`/api/miniapp/admin/orders`	跨=3／自=1	403／200	404／404	⚪ 用例错（端点路径不存在，非缺陷）
B1	`POST /api/admin/cms/posts`	跨=3	403 + 零变更	403	✅ PASS
B2	`POST /api/miniapp/admin/merchants`	跨=3	403 + 零变更	🔴 200（落库一行）	🔴 FAIL
B3	`POST /api/miniapp/admin/content/pois`	跨=3	403 + 零变更	🔴 200（落库一行）	🔴 FAIL
B4	`POST /api/admin/products`	跨=3	403 + 零变更	403	✅ PASS

数据库快照：cms_posts=0,merchants=31,pois=8 → cms_posts=0,merchants=32,pois=9（+2 行＝探针副作用，见 §五）。

四、三类根因（静态定位 + 实测交叉）

F-1 🔴 写端点「请求侧目的地被静默忽略」——`admin_ops.py:109`

ctx = await resolve_destination(user, requested=None)   # ← requested 写死 None
row = await conn.fetchrow("INSERT INTO merchants (…) VALUES (…,$5) …", ctx.destination_id)

实证：请求 ?destination_id=3，新建商户 id=30 实际落到 destination_id=1（SQL 直查确认）。
性质：不是「越权写入他人目的地」，而是调用方传的目的地参数被完全忽略、按凭证锚定落库 —— 调用方以为写进 3、实际写进 1，不报错（比 403 更隐蔽的数据错位）。
与 352 Q2 批2 / R5 是同族第四次发作（「声明点 vs 消费点」：函数声明了目的地解析，但请求侧消费点缺失）。
影响面已机械比对（本轮补做，纯静态零风险）：写端点调用点 23 个中——
requested=None 硬编码 5 个：admin_distribution.risk_ruling、admin_distribution.admin_generate_bills、admin_ops.admin_create_merchant、admin_ops.admin_create_temple、admin_ops.admin_delete_temple；
不传参 6 个（resolve_destination(user)，而签名 requested: int | None = None ⇒ 等价 None）：miniapp_pay.prepay、miniapp_workbench_redeem.redeem_arrival、safety.{trigger_sos, cancel_sos, submit_assessment, submit_health_check}；
正常传 requested=destination_id 的 12 个（admin_backend 全部 12 个）；

⇒ 🔴 11/23（48%）写端点不消费请求侧目的地。其中 miniapp_pay.prepay（支付下单）与 safety.*（SOS/安全上报）属高敏写端点，建议优先定性：是「产品本就按凭证锚定」还是「漏接校验」。

F-2 🔴 POI 端点完全未接线（content.py 不在消费清单内）

实证：dest=1／dest=3／不带参 均返回同一份 9 条 ⇒ 跨租户读全量；
写也落到默认目的地（pois 表有 destination_id 列，故具备接线条件，属漏接而非无列）。
content.py 未出现在 resolve_destination 的 20 个文件清单中 ⇒ 该域整块未接。

F-3 ⚪ 用例设计错误（自纠）

/api/miniapp/admin/orders 不存在（404/404）⇒ 属本岗用例路径写错，不是产品缺陷；已在矩阵中标注替换端点。

五、探针副作用与清理请求（本岗认账）

对象	位置	状态	处理
merchants `id=30` name=`363regression-probe`	dest=1	仍在库	无 DELETE 端点 ⇒ 请小齐清理
pois `id=9` name=`363regression-probe`	dest=1	仍在库（DELETE 返回 200 但未真删，疑软删）	请小齐清理

教训：即便只跑「拒绝侧」，一旦隔离失效就一定会落库 ⇒ 后续跑 W-1 组必须：①每次跑前先按名字 363regression-probe 查残留 ②优先选有 DELETE 端点且能真删的对象 ③确认删除后复查计数。

六、结论与建议

R5 红线未复发：受限凭证跨目的地读在已接线端点上全部 403；未发生跨目的地写入（两例落库均落在凭证锚定的 dest=1）。
🔴 但暴露两类中危：F-1 参数静默忽略（写端点）、F-2 整域未接线（POI 读写串租户）。两者都不在 R5 的覆盖范围内 ⇒ 证明「单端点回归」确实不够，矩阵必须常态化。
建议派工岗把 R-1/R-2/W-1 三组接入 335 第五幕与日常门禁；判据＝退出码，矩阵文件即判据载体。
建议 F-1 的 23 个写端点逐个查 requested= 传参（机械比对，本岗可接，属读操作无风险）。

署名：波波 2026-09-16 11:4x（WIP-363② · 多端点回归矩阵草案 + 首轮试点）