Blocked-by: #5677 (引擎侧 wantOwner 翻正面清单 + 列注入)Blocked-by: #5675 (ADR-0117 scoped 接受)
ADR-0117 已按 Accepted (D1/D3 scoped) 落地名字面(#4611 / PR #5675 ),owning_business_unit_id 的规范名已登记。本单补上 D1 的作者可见声明面 :ownership 枚举的第四档 'business_unit'。
⛔ 顺序约束(本单存在的唯一理由)
本单不得先于 #5677 落地,也不建议与之分开。 packages/objectql/src/registry.ts 的 wantOwner 是排除式判定,在它翻成正面清单之前,新增的 'business_unit' 会被照常注入 owner_id —— 与 ADR-0117 D1 表格相反,属 ADR-0049 禁止的「声明而不执行」。PR #5675 正是因此刻意没有扩展枚举;#4611 上有实测证据。
最稳妥的落地方式是与 #5677 合并为同一个 PR ;若确要分开,本单必须严格后置,且合并前需确认 #5677 已在 main 上。
工作面
packages/spec/src/data/object.zod.ts:1152 —— z.enum(['user', 'org', 'none']) 扩展为四值,并同步其 error 文案与 describe()(两处都逐字列出了合法值)。同文件 ownership 的 JSDoc 与 systemFields 段落 —— 补上新档位与 owning_business_unit_id 的注入规则。
改写 packages/spec/src/data/object.test.ts 中的 #4611 pin 。该 pin 目前钉住「business_unit 被拒绝且错误信息列出三个合法值」,并在注释里写明:它失败正是本单到来的预期信号,应改写而非删除 ——改成断言新值被接受、且第五个非法值仍被拒绝并列出四个合法值。CLI 消费半径 (易漏,PR fix(lint): 收敛 validate-expressions / validate-security-posture 的 spec 不声明键 ?? 别名读法 (#5017) #5046 packages/cli/test/commands.test.ts:83 断言 os explain object 的类型串 token 集合恰好等于 {'user','org','none'}(explain: os explain object documents ownership as "own" | "extend" — real values are user | org | none #3244 packages/cli 红 —— 一个只扫 packages/spec 的改动看不见它。生成物走生成器:ownership 是 authorable 键,packages/spec/authorable-surface.base.json:3590 有其条目,新增枚举值可能合法移动 authorable-surface / spec-changes。逐行解释每处生成物 diff 与本改动的对应关系(check:authorable-surface 在 --check 模式下也会重写 authorable-surface.base.json —— 一次纯核验会改工作区,且任何无关 PR 都能因此静默推进删除门的锚点 #5358
changeset:@objectstack/spec minor(新增枚举成员,作者可见)。
不在本单范围
D2 盖章策略与其默认值、D3 运行时校验、D4 守卫、D8 迁移与启用门、D6 契约变更 —— 均为 ADR-0117 的未决或后续项,其中 D2 默认值 / D5 / D8 粒度 / D4 权限位这四项尚未裁定 ,不得在本单顺手选定。
Blocked-by: #5677(引擎侧
wantOwner翻正面清单 + 列注入)Blocked-by: #5675(ADR-0117 scoped 接受)
ADR-0117 已按
Accepted (D1/D3 scoped)落地名字面(#4611 / PR #5675),owning_business_unit_id的规范名已登记。本单补上 D1 的作者可见声明面:ownership枚举的第四档'business_unit'。⛔ 顺序约束(本单存在的唯一理由)
本单不得先于 #5677 落地,也不建议与之分开。
packages/objectql/src/registry.ts的wantOwner是排除式判定,在它翻成正面清单之前,新增的'business_unit'会被照常注入owner_id—— 与 ADR-0117 D1 表格相反,属 ADR-0049 禁止的「声明而不执行」。PR #5675 正是因此刻意没有扩展枚举;#4611 上有实测证据。最稳妥的落地方式是与 #5677 合并为同一个 PR;若确要分开,本单必须严格后置,且合并前需确认 #5677 已在
main上。工作面
packages/spec/src/data/object.zod.ts:1152——z.enum(['user', 'org', 'none'])扩展为四值,并同步其error文案与describe()(两处都逐字列出了合法值)。ownership的 JSDoc 与systemFields段落 —— 补上新档位与owning_business_unit_id的注入规则。packages/spec/src/data/object.test.ts中的#4611pin。该 pin 目前钉住「business_unit被拒绝且错误信息列出三个合法值」,并在注释里写明:它失败正是本单到来的预期信号,应改写而非删除——改成断言新值被接受、且第五个非法值仍被拒绝并列出四个合法值。??别名读法 (#5017) #5046 同型教训):packages/cli/test/commands.test.ts:83断言os explain object的类型串 token 集合恰好等于{'user','org','none'}(explain:os explain objectdocumentsownershipas "own" | "extend" — real values are user | org | none #3244 的目录精度钉子)。枚举扩展必须同步该断言,否则 CI 在packages/cli红 —— 一个只扫packages/spec的改动看不见它。ownership是 authorable 键,packages/spec/authorable-surface.base.json:3590有其条目,新增枚举值可能合法移动 authorable-surface / spec-changes。逐行解释每处生成物 diff 与本改动的对应关系(check:authorable-surface在--check模式下也会重写authorable-surface.base.json—— 一次纯核验会改工作区,且任何无关 PR 都能因此静默推进删除门的锚点 #5358 纪律)。@objectstack/specminor(新增枚举成员,作者可见)。不在本单范围
D2 盖章策略与其默认值、D3 运行时校验、D4 守卫、D8 迁移与启用门、D6 契约变更 —— 均为 ADR-0117 的未决或后续项,其中 D2 默认值 / D5 / D8 粒度 / D4 权限位这四项尚未裁定,不得在本单顺手选定。