ADR-0105 D10: layered master data needs its follow-up ADR — the one remaining Phase 2 framework design item

[os-zhuang]

Successor tracking for the D10 line of #3541, which closed 2026-07-30 with D10 still open. A closed umbrella cannot carry live work, so the item moves here — same discipline as restarting a branch after its PR merges.

What D10 is

ADR-0105 reserves (Decision D10, concept only) the SAP material-master / 用友-金蝶 distribution shape for group deployments:

an object may declare layered governance — group-level template rows (platform-global or group-org-owned, read-shared) plus per-org override rows linked to the template, with a resolution rule (org override wins).

The motivating business shape: a group publishes a canonical material/customer/vendor master; plants consume it, optionally overriding fields locally; the group chooses per object how much local freedom exists (集团统管 / 分级 / 自由).

Status: blocked on a follow-up ADR that does not exist yet

The ADR explicitly defers mechanics "to a follow-up ADR; this ADR reserves the concept and its place in Phase 2." Per #3541's closing re-evaluation, none of ADR-0106…0113 is that ADR. Nothing here is implementable until it exists — this issue tracks the design debt, and the first deliverable is the ADR, not code.

What the follow-up ADR must decide

From the reserved text plus what Phase 1/2 shipped since (constraints the original reservation could not have known):

1. Linkage — how an override row names its template row (a dedicated lookup field? the ADR-0092 extension-field whitelist route on shared objects?).
2. Resolution point — read path vs a view layer. This now interacts with machinery that did not exist when D10 was reserved: the D2 union wall (organization_id IN accessible_org_ids) and driver-level DriverOptions.tenantIds (fix(authz): widen the driver's native tenant scope to the group membership union — ADR-0105 D2 reaches the wire (#3623) #3631). A group member's union read can see BOTH the template row and an org's override — the resolution rule has to decide what a union reader sees, not just what a plant reader sees.
3. Distribution policies — 集团统管 / 分级 / 自由 as declarable per-object governance, and what each means for write authority on template vs override rows (D5 stamping already forces every row to carry one organization_id; a "group-owned, read-shared" template row is exactly the shape the wall exists to prevent — it needs a principled opening, not an exception).
4. The open/commercial line (ADR-0016 铁律): presumably resolution mechanics open (they are enforcement), distribution management (publish/sync tooling, policy UI) commercial — that is how cloud#874 already lists it ("Master-data distribution management … mechanics pending a follow-up framework ADR"). The ADR should say so explicitly rather than inherit it by analogy.
5. Grouping-metadata dependency — D6's parent_organization_id tree defines "the group"; D9 (feat(approvals): cross-organization approver targeting (ADR-0105 D9) #3824) already established "shares a root" as the group-boundary predicate and $root/$parent as portable symbols. D10 should reuse that vocabulary, not mint a parallel one.

Downstream

• cloud#874's "Master-data distribution management" item is blocked on this.
• Related prior art worth reading before drafting: cloud security(authz): 多组织下伪造 organization_id 的 insert 可越租户墙 — Layer 0 未门控 insert post-image #2937 (cross-org mirroring contract, the isolated-posture analogue), the per-org seed/config replay machinery (cloud#881/fix: defer AuthPlugin route registration to kernel:ready hook #884) — distribution and seed-replay overlap in the "same rows, many orgs" problem.

Refs: ADR-0105 (D10, D2, D5, D6), #3541 (closed umbrella; see its 07-30 re-evaluation), cloud#874, cloud ADR-0016, ADR-0092, #3631, #3824.