普查:plugin-auth 之外还有 6 处把被降级的 OS_MULTI_ORG_ENABLED 当「是不是多组织」在读 —— 只设 OS_TENANCY_POSTURE 的部署会静默走错分支

[os-zhuang]

#5233 修的是 plugin-auth 里的两个站点(org-create 闸门 + /auth/config 的 fallback)。那个 issue 同时要求「普查其它读该布尔当作『是不是多组织』的站点」。普查做完了,列在这里;#5233 的 PR 一处都没改(文件面被限定在 packages/plugins/plugin-auth/** + packages/types 的一条注释),所以单独归档。

共同的缺陷形状

ADR-0105 D1 把 OS_MULTI_ORG_ENABLED 降级成 resolveTenancyPosture() 的回落输入,OS_TENANCY_POSTURE 才是权威 knob。于是任何用 resolveMultiOrgEnabled() 回答「本部署是不是多组织」的站点,在一台只设权威 knob(OS_TENANCY_POSTURE=isolated|group,遗留布尔不设)的部署上都会读到 false,走单组织分支 —— 而 serve.ts 挂的是完整的组织墙。已知同形状前案:cloud#1020、#5233。

正确读法是 postureEnforcesWall(resolveTenancyPosture())(@objectstack/spec/security),或在 kernel 内读 tenancy 服务。

站点清单(按后果排序,行号以本 issue 建档时的 main 为准,按内容核对)

#	站点	现在做什么	只设 posture 时的后果
1	packages/objectql/src/registry.ts SchemaRegistry 构造函数(this.multiTenant = resolveMultiOrgEnabled())	决定是否自动注入多租户系统字段	multiTenant=false → 组织墙要用的列/注入按单租户走,而 SecurityPlugin 那边 posture 是 isolated。两层对同一事实的口径分叉,优先级最高
2	packages/plugins/plugin-dev/src/dev-plugin.ts(const multiTenant = resolveMultiOrgEnabled())	决定是否加载企业 @objectstack/organizations	只设 posture 的 dev 栈根本不加载 OrganizationsPlugin → 直接掉进 ADR-0093 D5 降级态
3	packages/runtime/src/app-plugin.ts seeder(const multiTenant = resolveMultiOrgEnabled())	多租户下跳过 inline seed,交给 per-org replay	有墙部署仍然 inline seed,写出一批 NULL-org 行(注释自己说了这正是要避免的)
4	packages/runtime/src/app-plugin.ts registerHotReloadSeeder(if (resolveMultiOrgEnabled()) return;)	多租户下不装热重载 seeder	同上,有墙部署装上了本不该装的 seeder
5	packages/plugins/driver-sql/src/sql-driver.ts isMultiTenantMode()	门控 tenant-audit 告警	有墙部署收不到 tenant-audit 告警。另外它把结果缓存进 _multiTenantMode,即 AGENTS.md「启动期登记表读数不要记成判决」那一条的形状
6	packages/cli/src/commands/verify.ts(flags['multi-tenant'] || resolveMultiOrgEnabled())	verify 跑不跑多租户套件	只设 posture 的部署上 os verify 静默跳过多租户校验

另有 packages/cloud-connection/src/marketplace-install-local-plugin.ts 两处,需要各自判一下是「问 posture」还是「真的就想要那个遗留输入」。

边界

resolveTenancyPosture() 自己的回落必须原样保留 —— 它是遗留布尔唯一正当的消费者,back-compat 全靠它。同理,任何刻意要回显「操作者到底打了什么」的报告面(banner、诊断)读遗留布尔是对的,这个清单不包括它们。

packages/types/src/env.ts 上那句「every site … MUST call this」的注释已在 #5233 里订正为反向指引(明确写了别拿它当闸门),所以新代码不会再被它带偏;上面这 6 处是注释订正之前写下的存量。

不指派 —— 按 Prime Directive #10 归档。建议一处一处改并各自带测试,别打成一个大 PR:1 和 2 后果最重,值得先做。

出处:#5233 的开发(会话 session_015W6nhsDrz6zWQc8je12a1t)。

[claude]

⛔ 认领:session_015W6nhsDrz6zWQc8je12a1t(objectstack:identity 车道 PM),分支 claude/issue-5262-posture-misreads,os-dev 单点派发。

维护者 2026-08-04 裁定:本条进 v17。理由:v17 发版说明把 posture 故事当头条在讲(ADR-0105 D1、多组织重新成为 entitlement、bootStack({multiTenant:true}) 改为请求 isolated),若 GA 就这么发,一台照着 v17 自己的文档只设权威 knob 的部署会在 6 处静默走单组织分支——站点 1(objectql/src/registry.ts)更是数据形状层面的分叉。这是 cloud#1020 → #5233 之后同一缺陷形状的第三次复发。

文件面:packages/objectql/src/registry.ts、packages/plugins/plugin-dev/src/dev-plugin.ts、packages/runtime/src/app-plugin.ts(两处)、packages/plugins/driver-sql/src/sql-driver.ts、packages/cli/src/commands/verify.ts 及各自测试 + changeset。⛔ 不碰 packages/plugins/plugin-auth/**(#5261/#5205 在改)、packages/types/src/env.ts 的 resolveTenancyPosture() 回落链(back-compat 全靠它)、content/docs/releases/。

---

Generated by Claude Code

[claude]

PM 验收(第 19 轮,identity 车道):ACCEPT — PR #5302,CI 绿后合入

覆盖面超出预期:issue 清单 6 处全做,外加 cloud-connection 的 2 处(我在 issue 里写「需各自判一下是不是真的就想要那个遗留输入」——dev 判定两处问的都是「per-org replay 会不会接手」,与 app-plugin 同类,故都改),共 8 处,无遗留。我要求的「不要一刀切、逐站点判断该用哪一种 knob」也做到了,而且理由经得起推敲:

• 读 requested(4 处):registry.ts 构造在 kernel 之下够不到 service registry;plugin-dev 那个分支就是把墙立起来的那件事,问「墙立起来没有」是循环的(与 serve.ts:1772 同构);driver-sql 由连接配置构造,effective posture 在那里不可达;cli/verify 在任何 kernel 存在之前解析 flag。
• 读 effective(4 处):app-plugin 两处与 cloud-connection 两处问的都是「per-org replay 会不会代替我跑」,而那个 replay 是企业包挂在 sys_organization insert 上的 middleware —— D5 降级 boot 里它不存在,按 request 判就是让位给一个永远不会发生的 replay ⇒ 整个栈一行 seed 数据都没有;cloud-connection 那两处更是写路径,判错会让整个 app 的样例数据以 organization_id = NULL 落在自己的墙外面。

这个「问的到底是什么事实」的分法,比按包或按层一刀切正确得多。

⚠️ 我立案时把站点 1 的严重度写错了,dev 订正,我已核实

我写的是「组织墙要用的列/注入按单租户走 …… 两层对同一事实的口径分叉」。不成立。我在 origin/main 上逐行核对了 packages/objectql/src/registry.ts:

• 334 行注释原文:The organization_id COLUMN is provisioned unconditionally (subject only to …);
• multiTenant 唯一的去处是 375 行的 indexed: opts.multiTenant。

所以真实缺陷是:有墙的 posture-only 部署上,Layer 0 墙最热的谓词跑在无索引列上 —— 是执行计划/性能问题,不是数据形状分叉。仍然值得修,但严重度低于我的措辞。dev 只按这条真实事实写测试、没有顺着我更宽的说法写,这是对的:测试该钉住事实,不该钉住 PM 的描述。它还留了一条断言守住这个前提——将来若有人把列重新变成条件性的,误读的爆炸半径就从「慢」变成「墙没有东西可过滤」,那条断言会红。

其余验收要点

• 回落链未动,且清扫做干净了:改完后 resolveMultiOrgEnabled() 在全仓只剩一个调用者(packages/types/src/env.ts:161 的 resolveTenancyPosture() 自身)—— 既是 back-compat 的唯一支点,也是「这轮扫干净了」的可验证证据。env.ts 的注释按要求未改。
• 不对称失败方向选得对:registry.ts 朝「建索引」失败(单组织栈上多一个索引是死重量,有墙栈上少一个索引是全表扫描打在最热谓词上);driver-sql 朝「多打一行告警」失败。两处都是「错了也朝安全的一侧错」。
• 对抗性验证六个包全做,真实执行:objectql 3 红 / runtime 9 红 / plugin-dev 4 红 / driver-sql 6 红 / cloud-connection 7 红 / cli 4 红,修复后全绿。而且它指出每次通过的那几条正是 back-compat / 单组织 / 意图不变的用例——它们本来就该两边都绿,这正是「只订正 knob、不改意图」的证据。这个论证方式我认可。
• 额外的双向证明:把 app-plugin 的 helper 临时改成只读 requested → 恰好只有 3 条 degraded 用例红、其余 17 条全绿,证实了注释里那句声称。这一步没人要求它做,但它把「为什么这个站点必须读 effective」从论述变成了可复现的实验。

CI 绿即合入。

---

Generated by Claude Code

[claude]

PM 补充验收(返工轮):ACCEPT 维持 — PR #5302

Test Core (2/3) 的红是本 PR 引入的真实回归,已修:driver-sqlite-wasm 的 tenant-audit 用例靠 (driver as any)._multiTenantMode = true 直接戳私有 memo 开启多租户,而本 PR 把那个 memo 换成了 live 读 —— 这一戳静悄悄失效,判为单租户,告警不发。dev 独立复核了我的定位并先对未修改的原测试复现出与 CI 逐字一致的断言和行号,再动手。

修法正确:改设真实 OS_TENANCY_POSTURE=isolated + finally 还原。原开法伸手进实现细节,实现一变它就说谎、而用例仍在「运行」;驱动文档化 knob 不会这样过期。全仓 grep 确认没有第三个包戳这个字段。

顺带挖出一条真·空测:同 describe 里的 does not warn when bypassTenantAudit is set 从不设 posture,audit 在多租户门就早退 —— 把 bypassTenantAudit flag 整个删掉它也照样绿,即这条用例在本 PR 之前就什么都没测。补上 posture 后,dev 用「删 flag → 变红」验证了它现在真的生效。这类「绿着的空测」比红测危险得多,值得记一笔。

本轮按要求跑了两个包的完整套件(上轮红正因只跑了 driver-sql):driver-sqlite-wasm 16 files / 232 tests、driver-sql 59 passed+4 skipped / 740 passed+44 skipped,typecheck 与 eslint 均干净。生产代码本轮零改动。

⏳ draft 翻转需 GraphQL,额度当前为 0(约 28 分钟后恢复),恢复即 ready + auto-merge。

---

Generated by Claude Code