measure: 企业版 Middleware A 的 organization_id stamper 缺口——「调用点没带租户上下文」是否 ≠「行落 NULL」?(定 #13178 修复族伤害等级的唯一输入) #13497

由维护者 2026-08-30 决裁批 #9 对 #13491 的裁定(verbatim「同意」)同笔立卡。

任务(纯测量,不改代码)

#13178 普查测出 24 个应用面写调用点真没带租户上下文,其中 4 处半修复已入队(#13178)。伤害等级未定,取决于一个未测事实:

企业版 Middleware A(树外)在围墙(walled)部署上会 stamp organization_id——若它对这 24 个站点的写入路径全部生效,则「调用点没带」≠「行落 NULL」,伤害降为 p3(卫生问题);若存在绕过 stamper 的路径(非 HTTP 入口、后台任务、迁移脚本等),则对应站点是真实的 NULL 租户行风险,维持 p1。

产出:

1. Middleware A 的 stamp 生效条件与覆盖面(哪些入口路径经过它,哪些不经过);
2. 24 个站点逐个归类:stamper 覆盖 / 不覆盖 / 判不了(判不了的说明为什么);
3. 据此给 tenant-audit: the "write without tenantId" signal is a throttled log warn gated on multi-tenant posture, so it cannot fire in any environment where code is exercised #13178 修复族与 design: isSystem 写入是否在租户审计控制范围内?——#13178 类级装置(A/B/C)的共同前置,从未被裁过 #13491 已裁 scoping 的伤害等级建议,落卡评论——定级本身回批次呈报,⛔ 本卡不改优先级标签。

回头条款(#13491 裁定原文承接)

若测量发现系统(isSystem)写入也存在落 NULL 租户行的真实路径,#13491 的「isSystem 出范围」裁定回决策箱重裁。

Refs: #13178(普查与 4 处半修复)· #13491(scoping 裁定)。