ADR-0117 D1 执行面:applySystemFields 的 wantOwner 由排除式翻为正面清单 + 注入 owning_business_unit_id

[os-zhuang]

Blocked-by: #5675(ADR-0117 scoped 接受 —— 协议决定与规范名登记)

ADR-0117 已按 Accepted (D1/D3 scoped) 落地名字面(#4611 / PR #5675):SystemFieldName.OWNING_BUSINESS_UNIT_ID 已登记并标注「open-core 暂不注入」,同时进入公开表单拒收名单。本单是它的执行面。

为什么必须先动引擎,而不是先加枚举

packages/objectql/src/registry.ts:359-363 的 wantOwner 是排除式判定:

const ownership = schema.ownership;
const wantOwner =
  ownership !== 'org' &&
  ownership !== 'none' &&
  !(schema as any).managedBy &&
  !schema.name.startsWith('sys_');

只有 org / none 被排除。因此任何第四个枚举值都会落进默认分支并被注入 owner_id —— 与 ADR-0117 D1 表格(business_unit 档 owner_id ❌、owning_business_unit_id ✅)恰好相反。#4611 上已用一次性探针实测确认:

AssertionError: ADR-0117 D1: business_unit tier must NOT get owner_id:
  expected { type: 'lookup', …(6) } to be undefined
+ Received: { type: "lookup", reference: "sys_user", label: "Owner", … }

这就是为什么 PR #5675 刻意没有扩展枚举:只加值不动引擎,等于声明一个语义相反的档位(ADR-0049「spec 不得声明运行时不执行的东西」)。完整选项分析(A/B/C/D 四路及其代价)记录在 #4611 的复核评论中。

工作面

1. wantOwner 翻为正面清单 —— ownership === undefined || ownership === 'user'。对现有三个值行为完全不变(org/none 仍排除,undefined 仍默认注入),但新值不再默认落入注入分支。这是本单的关键单点:翻面之后,枚举扩展才是安全的。
2. 注入 owning_business_unit_id 列 —— 比照同函数内 organization_id 的注入形态(lookup → sys_business_unit、system: true、可空)。按 D1 表格,user 与 business_unit 两档都得到该列,org / none 不得。
3. conformance 归类迁移 —— packages/objectql/src/system-managed-fields-conformance.test.ts 中该名目前在 documented-reserved 组;列注入落地后必须移入 Group A(actively-injected),否则会以 stray entry 失败(该组由实时代码推导,测试内已写明这一步)。
4. SystemFieldName.OWNING_BUSINESS_UNIT_ID 的 JSDoc 从「NOT injected by open-core」翻为 INJECTED,并同步 packages/spec/src/data/object.zod.ts 中 systemFields 段落对注入列清单的描述。

不在本单范围

• D2 盖章策略(pinned / follow_owner / transferable)及其默认值 —— ADR-0117 未决问题,尚未裁定,不得在本单顺手选一个;
• D3 不变量的运行时校验、D4 写入守卫、D8 回填与启用门;
• D6 契约变更(resolveOwnerIds → resolveScope)—— 破坏性,需与企业版层级解析器同步发布;
• D13 promotion 工具(cloud#874)。

若实现中发现 D2 的默认值无法回避(例如列的 required 语义取决于策略),停下回报 needs_decision,不要自行选定 —— 它是 ADR-0117 明确提交评审的四项之一。

验收

• 新增 registry 测试:ownership: 'business_unit' 不注入 owner_id、注入 owning_business_unit_id;'user' 两列都有;'org'/'none' 两列都无;
• 既有 registry.test.ts:716(org/none opt-out)保持绿,证明翻面未改变既有语义;
• conformance 测试在归类迁移后绿。

[os-zhuang]

解锁(spec 车道 PM 代跨座位流转,session_018fxLGQdatPbBUvCgiVxg6D,2026-08-06):Blocked-by: #5675 已 MERGED(ADR-0117 scoped 接受生效),摘 pm:blocked 转 pm:queue,归 domain:engine-core 座位队列自扫。提醒接手者:验收标准含 conformance 分类从 reserved 迁 injected(#5675 在测试注释里埋了该陷阱说明);D2 盖章策略若被迫依赖,停手回报(ADR 四项未裁之一);下游 #5678(spec 枚举声明)等本单,须同 PR 或严格在后。

---

Generated by Claude Code

[os-zhuang]

认领(PM 会话 session_01V7WetGmnfoXNn8cLieKKmx,domain:engine-core 车道):pm:queue → pm:dispatched,即将派发 os-dev。

• 分支:claude/issue-5677-want-owner-positive-list
• worktree:../objectstack-5677
• 范围 = 工作面第 1-3 项(全落 packages/objectql):wantOwner 翻正面清单(ownership === undefined || ownership === 'user')、注入 owning_business_unit_id(比照 organization_id 形态)、conformance 归类迁移(documented-reserved → Group A)。
• 第 4 项(spec JSDoc + object.zod.ts 描述)已按车道边界转办 [spec] ADR-0117 D1 执行面落地后的声明同步:OWNING_BUSINESS_UNIT_ID JSDoc 翻面 + object.zod.ts systemFields 注入清单描述 #5767(domain:spec,Blocked-by 本单实现 PR)。⛔ 本单 dev 不碰 packages/spec。单合并窗口的文档滞后已在 [spec] ADR-0117 D1 执行面落地后的声明同步:OWNING_BUSINESS_UNIT_ID JSDoc 翻面 + object.zod.ts systemFields 注入清单描述 #5767 记录并论证可接受(方向为「运行时多于声明」,非 ADR-0049 形状)。
• 解锁 sweep 依据:Blocked-by feat(spec): ADR-0117 scoped 接受 —— owning_business_unit_id 规范名进入登记处 (#4611) #5675 已通过 PR feat(spec): ADR-0117 scoped 接受 —— owning_business_unit_id 规范名进入登记处 (#4611) #5675 落地(名字面 + 表单拒收名单)。
• 文件面:packages/objectql/src/registry.ts + packages/objectql/src/system-managed-fields-conformance.test.ts(+ 同包测试 + changeset);与在飞 finding(objectql): hook 层自带的 logger 接口把 error 声明成 (msg, meta?),与 Logger 契约的第二参是 Error 相反 —— 三处调用点在任何忠于契约的 Logger 下都会丢掉 meta #5637(hook-*)同包不同文件,不相交。
• 险点照单:若发现 D2 默认值无法回避(如 required 语义取决于策略),停下回报 needs_decision,不得自行选定——ADR-0117 明确提交评审的四项之一。

竞态复查与派发随后。

---

Generated by Claude Code