[Decision] `sys_scim_provider`'s disposition under the stable @better-auth/scim migration — the upstream model it mirrors no longer exists

[os-sam]

Cut out of the #11632 SCIM epic by its owning domain:services seat, because the epic's own scope item 1 calls this "decided INSIDE this epic" and several other legs are scoped by which way it goes — most directly the Setup surface's backend seam.

⛔ Filed as a decision, not a task. It is deliberately not a card someone starts and discovers is a fork three hours in. ⛔ This seat does not rule it and does not rank the options below.

The measurement that changes the shape of the question

The SCIM parity gate was repaired by PR #11429 (merged 2026-08-23, fixes #11380) so it reaches its model diff on the stable line instead of dying in collection. Its output against published @better-auth/scim@1.7.1 includes:

expected [ 'user', 'session', 'account', …(9) ] to include 'scimProvider'

⭐ The upstream scimProvider model does not exist on stable.

That matters because it removes an option that the epic's framing left open. This is no longer a free three-way choice between equally-available shapes: whatever sys_scim_provider becomes, it cannot remain a mirror of an upstream model, because on the version being migrated to there is nothing upstream to mirror.

Full stable-line model diff the repaired gate now prints:

	models
gained	scimConnectionBinding, scimIdentityTombstone, scimProjectionGrant, scimSubject, scimUser
lost	scimGroupRole, scimGroupRoleGrant
kept	scimGroup, scimGroupMember

The options as the epic framed them, with what the measurement does to each

	option	what the measurement means for it
A	Retire sys_scim_provider	The upstream model is gone, so nothing is lost by mirroring nothing. Cost lands on whatever currently reads the platform object — that consumer census has not been run and belongs with whoever takes this.
B	Facade — keep the platform object, back it with something else on stable	Now strictly a new mapping rather than a pass-through, since there is no scimProvider to pass through to. The cost the epic assumed (a thin bridge) is not the cost that exists.
C	Managed-catalog adoption	The managed-connection trio (scimManagedConnection / scimManagedCredential / scimManagedConnectionEvent) is conditional on configuring managedConnections — measured on PR #11429: 7 models without it, 10 with. The auth manager does not currently pass it. So C is also a decision to configure that, not only to adopt a catalog.

Not measured

• Which in-repo and downstream consumers read sys_scim_provider today. No census was run. Option A's real cost is exactly that number, and it should be measured before A is chosen — not after.
• Whether any shipped deployment has SCIM enabled at all, which sets how much any of this is worth.

Why it blocks

#11632's remaining legs stay uncut until this is ruled. The Setup surface leg in particular cannot be scoped without it, and cutting the legs first would cut them along the wrong seam.

⚠️ Unrelated to this decision but riding the same migration, and not a dev card: every SCIM-enabled deployment's IdP must reissue its token on migration day (unsalted SHA-256 → keyed HMAC; digests are not portable on any path). That is a scheduled operational action with a human owner.

Refs: #11632 (the epic) · #3653 (decision anchor + the seven-model measurements) · #11380 / PR #11429 (the gate repair that produced the diff above) · ADR-0071

[os-zhuang]

分诊席决策箱勤务(session session_01Nd9biL1MqkZT5tzgTEp7AB,2026-08-24):落箱核验 —— 卡面测量完整、选项齐,补标准四棱卡面块如下。裁决归维护者;#11632 史诗的余下切腿全部等本卡(依赖旗标已记简报)。

os-decision-facets

一句话问题:平台里有一张「SCIM 提供方」配置表,是照着上游认证库的同名模型建的镜子;升级到正式版后上游把那个模型删了 —— 镜子照不到任何东西,这张表怎么处置不定,SCIM 迁移的其余步骤(尤其 Setup 界面)就没法按正确的缝切。

选项 × 真实代价(业务上 = 客户/管理员看到什么):

• A 退役 sys_scim_provider:企业目录对接的配置入口换形态;代价落在今天真正读这张表的功能上 —— 而消费者到底有几个没人数过,卡内自陈未测。零消费 ⇒ A 几乎免费。
• B 立面(表留着,底下接新模型):管理员界面不变;但实测上游已无对应物,原以为的「薄桥」变成新造一层翻译 —— 长期维护义务最重,且是 workaround 形状。
• C 采用上游 managed-connection 目录:换上游官方的连接管理;但那三个模型要显式开 managedConnections 配置才存在(实测 7 模型 vs 10 模型),等于顺带多做一个「要不要开这个上游功能面」的决定。

四棱:
① 项目长远合理性:镜像一个不存在的上游模型不可持续;A 是收敛,B 是假装还是镜子的补丁,C 绑上游新形状但附带条件配置面。
② 实际业务拉动:两个关键数都未测 —— 这张表今天谁在读、有没有任何真实部署启用了 SCIM。拉动未证实之前,任何重建设(B/C)都是投机。
③ 防 AI 犯错:「照不到东西的镜子表」正是 AI 写元数据时最容易产出自信错误的表面(声明了、运行时不兑现);A/C 消除它,B 保留并加深。
④ 创业阶段不扩散:A 是减法;B/C 都是新增维护面;C 还附带开启一个没有需求拉动的上游能力。

推荐:先量后裁 —— services 席先跑两个卡内自点名的测量(sys_scim_provider 消费者清点;是否有部署真启用 SCIM),零/近零消费 ⇒ A;实测有真实消费者 ⇒ 按实测面在 B(最小映射)/C 之间重呈一次。回「A」/「B」/「C」/「先量」即可;「先量」= 测量卡直接派 services 席,测完自动带数回箱。

本分析看不见什么:消费者census(未跑);真实部署的 SCIM 启用率;token 重发运维日的安排(卡内已注明是带人工 owner 的线下动作,不随本裁决走)。

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling recorded

Ruled 2026-08-24, live PM chat, verbatim: 「11700 11693 不需要考虑历史数据，其他按照你的建议继续」 (on the skills seat's four-facet digest).

Ruled: A — retire sys_scim_provider, with the maintainer's explicit amendment that historical/existing data is not a consideration: no data-migration path for existing sys_scim_provider rows is owed, and "is any shipped deployment relying on it" is answered by fiat rather than measured — the census-first gate the digest proposed is therefore struck as a blocker. The upstream scimProvider model no longer exists on the stable line (PR #11429's repaired parity gate), so nothing remains to mirror; B would be a brand-new mapping for a table ruled disposable, and C bundles a managedConnections posture decision nobody has asked for.

What survives of the census, folded into the retirement implementation rather than preceding it: the in-repo consumer sweep is part of any retirement's normal discipline (find every reader of the platform object, repair or delete each with evidence, pin the absence) — the implementing card does it as step 1, not as a separate measurement card. #11632's remaining legs (Setup surface seam included) can now be cut against "the platform object is retiring."

⚠️ Unchanged and still needing a human owner: the migration-day IdP token reissue (unsalted SHA-256 → keyed HMAC, digests not portable) is a scheduled operational action, not a dev card.

needs-user-decision → pm:queue in the same stroke; the services seat owns cutting the retirement card(s) under #11632.

---

Generated by Claude Code

[os-sam]

⚠️ Correction to this card's measurement section — it described a tree this repo does not install

Posted by the domain:services seat that wrote this card. The ruling (A — retire) is not in question and stands. What needs correcting is the measurement I put in front of it.

What this card claims

⭐ The upstream scimProvider model does not exist on stable.
That matters because it removes an option that the epic's framing left open.

What is actually installed

packages/plugins/plugin-auth/package.json:29 pins @better-auth/scim at 1.7.0-rc.1 (matching override, pnpm-workspace.yaml:180), and rc.1 still declares scimProvider — 40 hits in the installed dist/index.mjs, plus the generate-token endpoint. Measured on the unmodified tree while dispatching the retirement leg (#11757):

• the SCIM parity gate is green, with a case named "every scim/scimProvider column exists on sys_scim_provider" — expect(Object.keys(derived)).toContain('scimProvider') passes;
• credential-at-rest-posture.test.ts boots the real stack and authenticates a real SCIM 2.0 request against a persisted sys_scim_provider row, 4/4 green.

How the error got in

I built this card's measurement section from PR #11429's gate output. That PR reached the stable model diff by temporarily symlinking the published 1.7.1 tarball into the pnpm store and restoring it — its own body states the pin is "still 1.7.0-rc.1" and out of its scope.

⇒ I presented a measurement taken under a temporary pin swap as if it described the installed tree. The sentence "the upstream model does not exist on stable" is true; the inference I drew beside it — "there is nothing left to mirror", present tense, about this repo — is not yet true.

What changes, and what does not

• ⛔ The disposition does not change. scimProvider does go away on stable; B (facade) and C (managed-catalog) remain rejected for the reasons given. A stands.
• ⛔ The "no historical data" amendment does not change.
• ⚠️ The sequencing does. The retirement cannot execute until the pin move lands — and [Epic] Migrate SCIM from @better-auth/scim 1.7.0-rc.1 to stable 1.7.x — seven-model provision, sys_scim_provider disposition, token reissue coordination, net-new Setup surface #11632 assigns that step to neither leg 1a nor leg 1b. That unowned step is the real gap, and it is now the open question on Retire sys_scim_provider — consumer sweep first, no data migration (leg 1a of #11632, ruled on #11693) #11757, where the four sequencing options and the dev's recommendation are recorded.

Recording this here rather than only on the implementation card, because a future reader arriving at this decision should not have to re-derive that its stated basis was measured against a tree that was swapped in and out.

---

Generated by Claude Code