Skip to content

decision: ADR-0131 C5 — allowOrgOverride also decides environment overlays of packaged items. When the per-organization axis retires, does the key split, keep its name with a new meaning, or get renamed? #22007

Closed

Description

@objectstack-fleet

Ruled: 6028809298 · letter C · 2026-10-07T01:23Z

Filing gate: ② a decision only the maintainer can make. Filed by the triage seat (objectstack-wide, seat post #6015, session_01AavokzJ5DndAwitDXvKy4U) at the maintainer's instruction 「需要我决裁的问题,立决策卡」. ⛔ Not a claim. The ruling is recorded on this card and on the parent, then this card closes.

Parent: #15206 (ADR-0131 C5, target:v18). Found by triage's pre-opening re-verification (6018690577).

维护者速读

v18 要取消"按组织定制元数据"这一层,但保留"环境级覆盖"(在 Studio 里改包发布的内容)。现在有一个开关同时管这两件事:它叫"允许组织覆盖",实际上环境级覆盖能不能做也看它。直接关掉,会把要保留的环境级覆盖也一起关掉。

  • A:拆成两个开关。组织级那个从此永远是"关",等于留下一个没用的开关。
  • B:开关名字不变,含义改成"允许环境级覆盖",组织级的代码全部删掉。名字和含义对不上。
  • C:改名成表达"环境级覆盖"的新名字,旧名字在加载时自动转换(v18 是大版本,转换成本低),组织级的代码全部删掉。

推荐 C。回一个字母:A / B / C。

四棱(os-decision-facets)

  • ① 项目长远合理性:C 删掉组织这一层,留下一个名实相符的开关;A 留下一个永远为"关"的开关;B 名不副实。
  • ② 实际业务拉动:视图、仪表盘、报表、翻译、邮件模板这 5 类今天都打开着这个开关,Studio 改包内容都靠它。
  • ③ 防 AI 犯错:B 的名字会让 AI 误以为能做组织级定制;C 的名字直接说清含义。
  • ④ 创业阶段不扩散:C 和 B 不新增长期键(C 是一次改名加转换);A 新增一个永久无用的键。

Prior rulings read: ADR-0131 D6 (the per-organization axis retires; environment overlays stay), D13; ADR-0005 (as amended); ADR-0087 D2 (rename conversions are lossless and run at load); isOverlayAllowed (protocol.ts:15886) → refusePackagedBaseOverride / refusePackagedBaseRemoval; thread: #15206.

一句话问题

退役组织级定制时,同时管着环境级覆盖的那个开关怎么处理?

选项 × 代价

选项 做什么 代价
A 新增环境级开关,旧开关只表示组织级,并从此固定为关 留下一个永久无用的键
B 不改名,只改含义 名字说"组织",实际管"环境",作者和 AI 都会误读
C 改名为表达环境级覆盖的新键,并登记 ADR-0087 D2 转换(旧名在加载时自动改写),删掉组织级路径 一次改名和一条转换;作者无需手改

推荐 + 回退 + 置信缺口

  • 推荐 C。 两年后,元数据类型只声明"能否被环境覆盖"一件事,名字即含义。这与 Salesforce 托管包组件用"可订阅方编辑"标记表达可覆盖性的建模一致。
  • 回退 B。
  • 置信缺口: 新名字由契约审查定。
  • 只看①选 C;②③④ 是否翻转:否。

裁后执行


Generated by Claude Code

Activity

  1. added
    priority:p1High: required for production / M2
    needs-user-decisionBlocked on a maintainer decision — do not dispatch; decision cards only, never on a PR
    domain:specDomain lane — seat card indexed by label:pm:seat
    on Oct 6, 2026
  2. objectstack-fleet commented on Oct 7, 2026

    @objectstack-fleet
    ContributorAuthor

    Ruling: batch #283 item 5 · letter C · maintainer 「其他同意」 2026-10-07T01:18Z

    Director seat, summon #35, session_01VYToj6PQehTEKNrjGM9akg (GitHub os-zhuang; written as objectstack-fleet[bot] via the relay). Batch #283 was presented in chat with this card's options A / B / C; the maintainer answered 「其他同意」 for the four cards of the batch whose recommendation stood, this one among them, which takes C. Freshness gate: the body (no comments) and the parent's thread (#15206: re-verification 6018690577, the batch #282 pointers 6020252365) were re-read before this record; nothing newer exists. Thread-read: none on this card.

    The ruling

    C. When the per-organization axis retires (ADR-0131 D6), allowOrgOverride (packages/spec/src/kernel/metadata-plugin.zod.ts:267, today "Allow per-org overlay writes via runtime metadata API") is renamed to a key that says what it will then mean, "may an environment overlay this packaged item", with an ADR-0087 D2 load-time conversion so an existing manifest naming the old key still loads unchanged, and the per-organization path behind isOverlayAllowed (protocol.ts:15886) is deleted. The new name is fixed by the contract review of the C5 change, not here. ⛔ Not taken: A (a second key, with the organization one frozen at false forever: a permanently dead key) and B (the old name with a new meaning: a key that says "org" and governs environments, which authors and AI read wrong).

    Why C: after the retirement a metadata type declares one thing about overrides, whether an environment may overlay it, and the key's name is its meaning. The conversion is lossless and runs at load, as ADR-0087 D2 prescribes for renames, and v18 is the major that makes it cheap.

    State


    Generated by Claude Code

  3. removed
    needs-user-decisionBlocked on a maintainer decision — do not dispatch; decision cards only, never on a PR
    on Oct 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    domain:specDomain lane — seat card indexed by label:pm:seatpriority:p1High: required for production / M2target:v18

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions