[Decision] Where the shared Company Core ontology lives: an app package in the objectstack monorepo, its own repository, platform-objects sys_* objects, or no shared core? #26582

Filing gate ③ (maintainer-directed). The maintainer in this session, 2026-10-27, verbatim: 「Company Core 共享本体放 objectstack 单仓。创建 issue 决策卡」 and 「你应该使用 pm-dispatch 技能创建issue」. The card records the options the maintainer's wording leans against, with premises and re-checks, so the ruling exists once on the board rather than as a chat line.

Filed by session_01J8VVAjRKqdoEYQ4hXxtBuf on the maintainer's instruction. ⛔ Not a claim. No domain:* label: triage routes the execution cards after the ruling (candidate lanes: domain:server for the package; domain:spec only if a namespace rule changes).

Business reason. Three downstream apps each define "a company we deal with" on their own: HotCRM crm_account / crm_contact, HotCLM clm_party, ATS ats_employer. A customer who installs two of them gets two unrelated customer tables, and an agent operating across them has no shared meaning of "this counterparty". A shared Company Core (party, contact, legal entity, department, address, currency, document, task, approval contract) is the base package every functional app would depend on (ADR-0141). Where that package lives decides its release cadence, who gates changes to it, and whether a platform PR can break every app at once without noticing.

维护者速读

• 一句话问题：所有业务应用共用的基础本体（往来单位与联系人、法人实体与部门、地址、币种、文档、任务、审批契约）放在哪里开发与发版。
• 谁撞上了（实测）：hotcrm、hotclm、ats 三个仓各自定义了"公司/联系人"对象（crm_account、clm_party、ats_employer），同装两个应用即两张互不相通的客户表。
• 选项：A 平台单仓内作为独立 App 工件、随平台发版；B 独立仓 objectstack-ai/company-core；C 并入 platform-objects 作 sys_* 常驻对象；D 不建共享核心，各应用自带、靠 ADR-0141 依赖 HotCRM。
• 推荐 A。 回退 B。
• 请回：A / B / C / D，并一并裁定命名空间（见「After the ruling」第 1 条）。

Background

• The marketplace survey of 2026-10-27 (this session) found the only v18-current listed app is HotCRM; HotCLM, ATS, Duly and the templates repository each pin an older platform and each model the counterparty independently. Readings on objectstack-ai/hotcrm@9464673, objectstack-ai/hotclm@3b7364f, objectstack-ai/ats (head of 2026-09-09), objectstack-ai/duly (head of 2026-10-26), this repository at c3fb185a.
• ADR-0141 D7 names the first dependency consumer: a HotCRM module shipping on its own. A Company Core package is the second shape of the same mechanism: a base that many apps declare.
• Nothing in the platform defines a business party today. sys_organization is the tenant organization (ADR-0029 D2's identity hub), not a customer or supplier.

Governing text

• ADR-0029 D2: "Core-mandatory — referenced by (almost) everything and has no meaningful 'disabled' state: the identity/org hub (sys_user, sys_organization) and the metadata store … Capability — has a coherent on/off boundary … Independently installable/disablable; each owns its sys_* objects." Re-check: git grep -n "Small core; everything else is a capability plugin" origin/main -- docs/adr.
• ADR-0029 D4: "a scope:'project' / type:'app' package attempting to own/define an object in a reserved kernel namespace is rejected (the sys_-prefix exemption becomes a prohibition for apps). Apps may still extend kernel objects." Re-check: git grep -n "apps reference but cannot define kernel objects" origin/main -- docs/adr.
• ADR-0019 D2: "Only type: app is consumer-installable; everything else is invisible." Re-check: git grep -n "is consumer-installable; everything else is invisible" origin/main -- docs/adr.
• ADR-0141 D1 / D2 / D5: dependencies are declared in ManifestSchema.dependencies, checked once before install, and "A declared dependency is namespace co-ownership, one-way". Re-check: git grep -n "A declared dependency is namespace co-ownership" origin/main -- docs/adr.
• AGENTS.md Prime Directive Migrate from npm to pnpm #6: "For module prefixes, embed in the name (sys_user, ai_conversations)"; ADR-0129: an object name carries its module prefix literally.
• packages/spec/src/kernel/manifest.zod.ts lines 531–532: "Platform-reserved namespaces: "base", "system", "sys". Object names starting with sys_ are reserved for the platform". Re-check: git grep -n "Platform-reserved namespaces" origin/main -- packages/spec/src/kernel/manifest.zod.ts.
• pm-dispatch references/decision-analysis.md 〈应用仓推荐序特例〉: 「能力先建在平台(spec、objectstack 运行时、objectui 渲染器);应用仓(cloud、hotcrm)不自建替代。」

Protocol statement. No spec key changes under A, B or D. C changes what sys_* means (ADR-0029 D2 would gain a third tier) and needs an ADR amendment first. Under A, B or D the core's namespace is an ordinary app namespace and cannot be sys, base or system (reserved); the ruling should name it (candidate: core, objects core_party, core_contact, core_legal_entity, …), because ADR-0129 makes the prefix literal and permanent.

Premises (each with a re-check)

1. No platform object models a business party. Re-check: git grep -n -i "counterparty\|core_party\|business party" origin/main -- packages/platform-objects/src (expected 0 hits).
2. Three downstream apps each own a party-like object. Re-check: ls hotcrm/src/*/objects | grep -E "account|contact"; ls hotclm/src/objects | grep party; ls ats/src/objects | grep employer.
3. The ADR-0141 D2 pre-install dependency check is live, so a base package can be declared and its absence refused. Re-check: git grep -n "checkDeclaredDependencies" origin/main -- packages/cloud-connection/src.
4. A metadata app package in this monorepo is an existing shape (packages/apps/setup, packages/apps/studio, packages/apps/account are manifest packages; examples/app-multi-package builds two packages in one artifact). Re-check: ls packages/apps examples/app-multi-package/src.
5. Apps must not define sys_* objects (ADR-0029 D4). Re-check: git grep -n "RESERVED_NAMESPACES" origin/main -- packages/objectql/src/registry.ts (the set currently holds base and system; the enforcement site of the sys prohibition for apps is not re-verified here).

Options

In business terms.

• A: one shared address book, shipped and tested with the platform, installed as an app.
• B: the same address book kept by a separate team with its own release calendar.
• C: the address book is part of the operating system; you cannot not have it.
• D: no shared address book; every app copies the CRM's or keeps its own.

四维分析(业务立场)

• 项目长远合理性(领起)。 两年后的样子：一家公司在平台上的"往来单位、法人、地址、币种"只有一份定义，每个职能应用声明依赖它（ADR-0141），对应 Salesforce 的 Account/Contact 标准对象、SAP 的业务伙伴（Business Partner）、Palantir 的共享本体。A 与 B 都到达这个终态，差别只在谁为它的契约负责：A 把它放在平台 PR 的 CI 半径内，契约与 spec 同级受护，缩小特例；B 多一个仓与一条异步金丝雀，破坏在平台合并之后才被看见。C 把业务本体塞进 sys_*，违反 ADR-0029 D2/D4 的两层划分（身份枢纽 + 能力插件），是永久特例。D 让"客户"永久等于 CRM 的账户，CLM、采购、GRC 都要先装 CRM，契约随 CRM 的产品节奏漂移。
• 实际业务拉动。 有实测拉动：hotcrm crm_account、hotclm clm_party、ats ats_employer 三份互不相通的"公司"定义；hotclm DESIGN 已为"相对方"单独建模，并把 CRM 交接做成一条同步流程（F15）。有拉动 ⇒ 一次付清长远形态。
• 防 AI 犯错。 出错时谁看到什么：A/B 下，写 CLM 元数据的 AI 引用 core_party 而核心未装时，在安装门被响亮拒绝（ADR-0141 D2）；C 下对象常驻，无法拒绝"没装核心"，也无法卸载；D 下 AI 要在每个应用里重写一遍 party，批量犯错的面最大。A 比 B 多一道门：平台 PR 改坏核心时 CI 当场红，而非金丝雀事后红。
• 创业阶段不扩散。 A 不加新门禁、不加协议键，复用现有 manifest 包与 dependencies；B 多一个仓的运营成本；C 要改 ADR（Tier H）并让每个环境背一张用不到的表；D 零工作量但把扩散推给每个新应用。

os-decision-facets

• ① 项目长远合理性：A 缩小特例（一份业务本体，契约在平台 CI 半径内，合 ADR-0029 两层划分与 ADR-0141 依赖）；B 同终态但契约护栏异步；C 扩大 sys_* 的含义，违 ADR-0029 D2/D4；D 让"客户"永久等于 CRM 账户。
• ② 实际业务拉动：今天 hotcrm、hotclm、ats 各自定义公司对象（crm_account、clm_party、ats_employer），hotclm 还为此写了一条 CRM 交接流程。
• ③ 防 AI 犯错：A/B 缺核心时安装门响亮拒绝；C 无法拒绝也无法卸载；D 每个应用重写一遍 party，错面最大。
• ④ 创业阶段不扩散：A 无新门禁无新键；B 多一仓；C 需改 ADR 且每环境常驻一表；D 零工作量但扩散后置。

Prior rulings read: "shared base objects party organization person company core package every app depends" → 1 hit (#26131, an unrelated console check, closed); "company core ontology master data counterparty vendor customer same object across apps" → 1 hit (#14599, multi-package artifact attribution defect, closed); ADR-0141 D7, ADR-0029 D2/D4; thread: none.

Recommendation

• A, fallback B.
• 只看①选 A；②③④ 是否翻转：否。
• Confidence gap: (i) whether a type: 'app' metadata package under packages/ is published as its own marketplace artifact by the existing release workflow was not measured (premise 4 shows the package shape exists, not the publish leg); (ii) the enforcement site of the sys prohibition for apps (ADR-0029 D4) was not re-verified, which matters only for C; (iii) the object roster of the core is a proposal from the 2026-10-27 survey, not a ruled list — this card asks only where it lives; the roster is a follow-up card.

After the ruling

1. The ruling names the namespace and manifest id in the same breath (candidate core / com.objectstack.core); sys, base and system are reserved and not candidates.
2. A: triage files one domain:server card: the package skeleton under packages/ with manifest, namespace, one anchor-safe default permission set (ADR-0090 D5), build and publish wiring, and a CI leg that installs it on every platform PR; a second card for the object roster, filed after the maintainer reviews the proposed list.
3. B: triage files a cross-repo coordination parent: a new repository from the app-repo kit, a canary workflow in this repository, the same roster card.
4. C: an ADR amending 0029 D2/D4 first (Tier H), then the package work.
5. D: close this card not_planned; the HotCRM module split (ADR-0141 D7) continues as the only dependency route.
6. HotCRM, HotCLM and ATS each get a follow-up card to re-point their party objects at the core once it is published; those cards are filed in their own repositories.

Related

ADR-0019, ADR-0029, ADR-0129, ADR-0130, ADR-0141 (D7), #25403 (the dependency rulings), #25747 (e-sign connector, a cross-app consumer), #25098.

Generated by Claude Code