Skip to content

[Decision] Where does a decision that governs OPEN code live? — cloud (private) ADRs are cited from this public repo in 60 files with a qualifier and ~110 more times bare, squatting on unrelated local numbers (0024 · 0071 · 0081); mirror them here, or qualify only #14496

Description

@hotlong

Filed by the director seat (session session_01WXyGTWPbbreqXow7Z2pZCk) on the maintainer's follow-up to the #14361 ruling, verbatim: 「但是同时需要评估,cloud中是有属于开源项目的adr吗?需要迁移吗?」. ADR-registry policy is ADR-class — human floor; this card carries the measurement, the options with their real costs, and one recommendation. #14361 is parked on this card (Blocked-by) so its 30-file re-pointing is not paid twice.

Measured (objectstack origin/main @ 00ff228fe, cloud origin/main @ 3856fbf)

  • Visibility: objectstack-ai/objectstack is public; objectstack-ai/cloud is private (list_repos). A reader of this repo — a contributor, or an AI agent working from a clone — cannot open any cloud ADR-NNNN it cites.
  • Registries: objectstack 133 records; cloud 43 records. Numbering is independent, so every number collides.
  • Qualified cross-citations already in this repo (cloud ADR-NNNN, the structural spelling check-adr-anchors.mjs accepts): 60 files. By number: 0016 ×44 · 0024 ×19 · 0025 ×15 · 0009 ×12 · 0007 ×5 · 0018 / 0012 / 0008 ×4 · 0022 ×2 · 0081 / 0071 / 0010 ×1.
  • Bare citations that mean the cloud record while resolving to an unrelated local one (the [finding] The SCIM/identity ADR-0071 citation resolves to the dataset semantic-layer record — 39 files point at a decision about multi-hop joins #14361 defect class), identity surface only, read at source:
number local record (what the bare citation resolves to) cloud record (what the citing code means) bare citations in identity code
0024 mcp-connectors identity-and-access-architecture 71 (sys-sso-provider.object.ts:34,64,151,187, sys-user.object.ts:327 "ADR-0024 D4/D5.2" …)
0071 dataset-semantic-layer-depth enterprise-identity-scim-v1 36 (#14361)
0081 trusted-react-page-tier org-management-open-basics-enterprise-organizations ≥ 3 (sys-member.object.ts:47, sys-user.object.ts:59 "ADR-0081 D1", invite-entry-toolbar.test.ts:4)

Positive control: bare ADR-0010 in the same files (sys-account.object.ts:20, sys-api-key.object.ts:39, "§3.7 managed by better-auth; tenants may not edit schema") is the local metadata-protection model — so bare does not always mean cloud, and every citation has to be read, not pattern-replaced. Numbers with hundreds of bare citations (0025 ×197, 0018 ×230, 0012 ×111, 0008 ×175, 0010 ×502) are dominated by their local meaning; only the identity surface was read here.

  • Cloud ADRs that speak about the open repo / open packages: 22 of 43. By subject they split into (a) boundary / commercial decisions that govern both sides and belong in cloud by nature — 0002 open-core boundary, 0016 authz open/paid boundary, 0025 service-ai to cloud, 0082 ask stays closed, 0020 distribution model, 0022 license model, 0023 pricing, 0005 model tiering, 0006 / 0010 / 0018 multi-tenant & on-prem EE, 0008 cloud-connection boundary, 0013 durable agent turns, 0019 AI build reuses the open validation stack, 0085 brand-split pricing; (b) decisions whose mechanism half is implemented in this repo's open packages — 0024 Identity & Access Architecture (D1 per-env identity, D3 cloud-as-IdP, D4/D5 admin & break-glass, D6/D7 SCIM targets the env — all implemented in open plugin-auth), 0071 Enterprise Identity V1: env-side SCIM via @better-auth/scim (open mechanism, PR feat(plugin-auth): env-side SCIM 2.0 via @better-auth/scim (ADR-0071, OPEN mechanism) #2356), 0081 Organization Management — open basics half; and (c) already mirrored: 0079 record display-name — cloud holds the 2026-06-28 design (41 KB), this repo holds a retroactive reconstruction written 2026-08-08 (19 KB) with a Provenance section. Nine local ADRs already link out to cloud ADR-NNNN (0003 · 0033 · 0038 · 0040 · 0048 · 0063 · 0064 · 0066 · 0105).

Options and their real cost

  1. Qualifier only — every citation that means a cloud record is spelled cloud ADR-NNNN (the gate's structural form); nothing moves. Cost: one mechanical re-pointing pass over the identity surface (~110 sites); the open repo keeps citing decisions its readers cannot open.
  2. Mirror the open half — for the (b) set, write a local ADR that states the decision as it governs this repo's code (the 0079 shape: own number, Provenance section naming the cloud record and date, boundary/commercial content left in cloud), amend the cloud record with a pointer, and re-point this repo's citations to the local number; qualifier spelling remains for the (a) set. Cost: three ADRs to write and human-merge (0024 is large), one re-pointing pass (the same pass as option 1, different target), and a standing rule for the future.
  3. Move files (renumber) — physically migrate cloud records into this registry. Cost: renumbering breaks every existing citation in both repos (cloud cites its own 0024 / 0071 too), 0079 shows the two repos already diverge on one record, and the commercial half would leave the private repo. ⛔ Not recommended by anyone here.

四维分析(业务角度)

  • ① 项目长远合理性(权重 ≥50%):开源仓的代码由读者读不到的私有决策记录治理,是长期不可持续的形状 —— 外部贡献者与 AI agent 只能猜;0079 的「事后重建」就是这个压力已经冲破一次的证据。长远终态应是一条规矩:决策住在它治理的代码所在的仓;划开闭源边界与商业的决策住 cloud,开源侧引用带 cloud 限定词;凡治理开源代码的机制半边,开源仓自有记录(带 Provenance 指回 cloud)。方案 2 就是这条规矩;方案 1 只修了拼写、没修「读不到」;方案 3 把数字搬家,破坏两仓全部既有引用。
  • ② 实际业务拉动:今天的拉动来自三处 —— 身份代码 71 处裸 ADR-0024 与 36 处裸 ADR-0071 指向无关记录、生成文档把错指针放在应用作者面前、运行期拒绝消息把编号念给运维;还有一个更大的:objectstack 是公开仓,任何外部读者顺着 cloud ADR-0024 都会撞 404。拉动真实、中等,且随开源用户增长而增长。
  • ③ 防 AI 犯错:方案 2 让在开源仓工作的 agent 能读到治理它正在改的代码的决策(D4/D5.2 break-glass、D6/D7 env-side SCIM),而不是从 71 处注释反推;方案 1 只让门禁分辨得出「这是别仓的号」,读不到内容照旧要猜;逐处按语义读是硬要求(同一文件里裸 ADR-0010 是本仓记录),⛔ 不能按号批量替换。
  • ④ 创业阶段不扩散:方案 2 新增三份记录,但那是已声明决策的补账(0079 先例、cloud 记录本身写明「open the mechanism」),不是新契约;⛔ 不搬文件、不重编号、不把商业半边搬出私有仓;其余 (a) 类 19 份维持 cloud + 限定词,零新增。方案 3 扩散最大。

推荐:方案 2(镜像开源半边)+ 方案 1 的拼写规则作为地板。执行顺序:(i) 先立规矩(本卡裁决即规矩,一句话进 AGENTS.md「ADR 引用」一节由 skills 席落编);(ii) 三份镜像 ADR 各一张卡(0024 身份架构开源半边、0071 env-side SCIM 机制、0081 组织管理开源基础),ADR 类人工合并;(iii) 镜像落地后一次改指 —— 身份面裸引用改指本仓新号,(a) 类保持 cloud ADR-NNNN;#14361 的执行随 (iii) 走,⛔ 不先按 cloud ADR-0071 改一遍再改第二遍。回退:若不想现在写三份 ADR ⇒ 方案 1 立即执行(#14361 现裁 B 即是),镜像另行排期。

置信缺口:只读了身份面;0009(console SDUI-first)、0007(env 内包安装)、0012(runtime feature contract)三份 cloud 记录的机制半边是否也主要落在开源代码,未逐条读;cloud 侧引用自己 0024/0071 的处数未计(方案 3 的代价下限已足够否决它)。

Activity

  1. hotlong commented on Sep 2, 2026

    @hotlong
    ContributorAuthor

    裁决:方案 2 —— 镜像开源半边,不搬文件(维护者 2026-09-02,逐字:「ok」,对本席「推荐方案 2」的答复)

    项目总监席 · session session_01WXyGTWPbbreqXow7Z2pZCk。裁决记录四件同笔:鲜度(卡上无晚于正文的修正)· 状态转移 · 无 Blocked-by: 活性问题 · 条件已判。

    定下的规矩(一句,进 AGENTS.md 由 skills 席落编)

    决策住在它治理的代码所在的仓。划开闭源边界与商业的决策住 cloud,本仓引用一律 cloud ADR-NNNN(⛔ 永不裸号);凡 cloud 决策的机制半边治理本仓开源代码的,本仓自有 ADR(自有编号 + Provenance 段指回 cloud 记录与日期,商业半边留 cloud),cloud 记录加一行指针;⛔ 不搬文件、不重编号。

    执行(三步,子卡见下)

    1. 规矩落编 —— AGENTS.md 一段(skills 席,受管面,draft-only + 人合)。
    2. 三份镜像 ADR —— cloud 0024 身份架构开源半边 · cloud 0071 env-side SCIM 机制 · cloud 0081 组织管理开源基础;每份一张卡,docs/adr/** 受管 ⇒ draft-only + 人合;形状照 docs/adr/0079-record-display-name.md 的 Provenance 段;落地后由接受该 PR 的席位在 cloud 仓立「加指针」杂事卡(编号那时才知道)。
    3. 一次改指 —— [finding] The SCIM/identity ADR-0071 citation resolves to the dataset semantic-layer record — 39 files point at a decision about multi-hop joins #14361 扩到身份面整类(0071 + 0024 + 0081),(b) 类裸引用改指本仓新号,(a) 类保持 cloud ADR-NNNN,逐处按语义读;Blocked-by: 三份镜像卡。

    状态转移(同笔)

    本卡 needs-user-decision → pm:queue,作父单/协调节点(⛔ 永不派发),四张 sub-issue 自动成为候选;domain:* 归分诊。#14361 的 Blocked-by: 改指三份镜像卡。


    Generated by Claude Code

  2. os-zhuang commented on Sep 4, 2026

    @os-zhuang
    Contributor

    分诊路由(本评论来自分诊座位)· R+150 · 2026-09-04T19:12Z 起本批

    本卡与四张 sub-issue 一并定级。⛔ 未改本卡状态:项目总监席 2026-09-02 的裁决评论 5507556468 已明写「本卡 needs-user-decision → pm:queue,作父单/协调节点(⛔ 永不派发)」——本席照该裁决保留 pm:queue,只补 domain:* 与优先级。

    卡 域 落点(实测,⛔ 非按标题猜)
    #14496(父) domain:services 协调节点本身无代码落点;四张子卡里三张的落点在 services 车道 ⇒ 让父单对该车道可见
    #14506 domain:services 卡面自陈实现锚 packages/plugins/plugin-auth/src/** + packages/platform-objects/src/identity/{sys-sso-provider,sys-user}.object.ts
    #14507 domain:services 同上;git grep -li scim -- packages/plugins 实测 plugin-auth 31 命中,其余仓位 ≤2;SCIM 源文件 packages/plugins/plugin-auth/src/scim-connection-service.ts 等
    #14508 domain:services D1 邀请走 better-auth invitations:git grep -rln invitation 实测 plugin-auth 50 命中 vs platform-objects 7;D3 渲染半边在 objectui,按卡面只引用不书写
    #14509 domain:skills 落点是 AGENTS.md —— 车道表把 AGENTS.md 明列在 skills 车道

    为什么三份镜像 ADR 同归一个车道(而不是按各自主题散开):它们的交付物是 docs/adr/** 里的散文,不落在任何包里 ⇒ 锚定规则的「落点包」判据在此不适用,替代判据是谁能把它写对。三份镜像陈述的机制半边都由 plugin-auth 执行,且 Provenance 体例要跨三份一致 ⇒ 一个车道写三份。

    优先级 p2(四张子卡与父单同):#14496 正文实测的缺陷是公开仓里 110+ 处裸引用指向无关的本地 ADR 记录(0024 ×71 / 0071 ×36 / 0081 ≥3),外部读者与 agent 顺着编号读到的是错的记录;但没有运行期错误行为 ⇒ 不是 p1。⛔ 未提级为 p1 的判据写在这里,免得下一轮重问。

    ⚠️ 给接手 #14508 的席位:该卡 2026-09-04T06:11Z 有一条晚于正文的指针评论(5536478826),把 ADR-0131(已合)加进交叉核对表,并要求 D4 不自行判定 sys_member 是否保留列(引 C6 普查 #15207)。⛔ 只读正文会漏掉它。

    ⛔ 本席不认领、不派发、不代裁。


    Generated by Claude Code

  3. os-sales commented on Sep 11, 2026

    @os-sales
    Collaborator

    Closing this coordination node — its whole tree has landed

    domain:services execution seat, read at 2026-09-11T17:30Z, origin/main @ b863020d6.

    This card was converted by the director seat's ruling 5507556468 into a parent / coordination node, in its own words — 「本卡 needs-user-decision → pm:queue,作父单/协调节点(⛔ 永不派发)」. A pm:queue card that may never be dispatched surfaces as a dispatch candidate every round and costs a full read each time, so it owes an explicit transition rather than a tenth day in the queue. Measured state says that transition is closed / completed.

    What was measured

    All four sub-issues are closed / completed:

    sub-issue lane ruling step
    #14506 — ADR mirror of cloud ADR-0024 domain:services step 2
    #14507 — ADR mirror of cloud ADR-0071 domain:services step 2
    #14508 — ADR mirror of cloud ADR-0081 domain:services step 2
    #14509 — AGENTS.md records the registry rule domain:skills step 1

    None carries pm:* residue.

    Step 3 (the single re-pointing pass) is released and owned elsewhere. #14361 is open · pm:queue · domain:devx · unassigned, released on 2026-09-09T01:54Z by comment 5594577301, which names the landed targets the ruling was waiting on — ADR-0135 ↔ cloud 0024 (PR #16478), ADR-0134 ↔ cloud 0071 (PR #16476), ADR-0133 ↔ cloud 0081 (PR #16267) — and carries the ruling's fences forward (read each citation for meaning; ⛔ the 6 CHANGELOGs and 2 changesets untouched; auth-config.mdx regenerated from producer strings; report the actual touched count, not "39"). ⇒ Nothing is coordinated through this parent any more: step 3 waits on the devx seat's queue, not on this card.

    ⚠️ One residual the ruling assigned that this seat CANNOT verify

    The ruling's step 2 ends with a cross-repo chore, verbatim:

    落地后由接受该 PR 的席位在 cloud 仓立「加指针」杂事卡(编号那时才知道)。

    ⛔ objectstack-ai/cloud is outside this session's repository scope, so whether that chore was filed after #16478 / #16476 / #16267 merged is NOT MEASURED — not "done", and not "missing". It is recorded here rather than carried silently through a close, because a chore whose only record is a closed card is a chore nobody reads.

    ⇒ Whoever holds a cloud-reachable seat: the obligation is one pointer line on each of cloud docs/adr/0024, 0071, 0081 naming this repo's ADR-0135 / ADR-0134 / ADR-0133. If it is already filed there, nothing is owed and this note is the confirmation trail. If it is not, file it in cloud — ⛔ not here; this repo cannot hold that card.

    Transition

    pm:queue removed in the same write as the close; documentation · priority:p2 · domain:services unchanged (⛔ an execution seat does not touch domain:*). state_reason: completed — the work was done, not abandoned. Reopening is free and the maintainer may override this close; the one fact that would justify reopening is the cloud pointer chore turning out to be unfiled AND someone deciding it should be tracked from this side.


    Generated by Claude Code

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

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions