finding: cloud 的 runtime-config 生产端会下发 `features.scim`,而 app-shell 的 `RuntimeFeatures` 没有这个键(objectui 全仓零消费)

[os-zhuang]

观察类发现,顺路撞见,未在任何 PR 中修改 —— 记录而非认领。

观察

packages/app-shell/src/runtime-config.ts 的 RuntimeFeatures 声明了两个「可选商用位」——
customDomain? 与 sso?,注释写明它们由服务端按 plan entitlements 推导、自建/vanilla 运行时上缺席。

cloud 仓 main 上,推导这两个位的那段代码在同一个对象字面量里还推导了第三个位 scim:
packages/objectos-runtime/src/cloud-runtime-config-plugin.ts 的 resolveFeatures 在拿到 plan 时返回
{ aiStudio, autoPublishAiBuilds, customDomain, sso, scim }。framework 侧的 @objectstack/cloud-connection
按 ADR-0012 只搬运一张不透明的 feature map,所以这个键会原样到达 SPA。

本仓实测,带对照:

probe	result
grep -rn '\bscim\b' --include='*.ts' --include='*.tsx' packages/ apps/	零命中(退出码 1)
对照 —— 同一形状的 sso 在 runtime-config.ts 内	3 处(接口声明 + 默认值 + 注释)

对照是让这个「零」成为读数而不是 grep 写错的原因:同一条命令对姊妹键 sso 有命中。

为什么记一笔

这是声明面与消费面对不齐的一处:生产端按 plan 推了一个能力位,消费端既没在 RuntimeFeatures 里声明它,
也没有任何地方读它。两种收敛方向都成立,选哪个是产品判断,不是实现判断:

• SPA 本就该按 features.scim 门控某个 SCIM 相关入口(那么本仓欠一个声明 + 一个读取点);
• 或者 SCIM 根本不需要 SPA 侧的 affordance(那么 cloud 侧下发的是一个零消费的键,按「已发布零消费的能力
  不因沉没成本获得豁免」应在生产端处置)。

严重度留给分诊定级;⛔ 未打 pm:queue。

发现语境

在实现 objectui#5206(runtime-config.ts 的 "Server-side: see" 指针重锚)时读生产端代码撞见 ——
那张卡的修复正是把这条注释指向 @objectstack/objectos-runtime 的 RuntimeConfigPlugin,而这个键就在那里。

[claude]

Finding concentration round (triage seat, session session_01Kktexqp6uVuFMztvvTMf3V, 2026-08-24, maintainer-invoked): promoted → pm:queue (domain:ui), Task (S). Declare scim?: boolean on RuntimeFeatures mirroring its two commercial siblings (customDomain?/sso? — same producer object in cloud's resolveFeatures), with the same "server-derived, absent on vanilla" comment. Declaration documents the wire a shipped producer already emits; any actual SCIM UI gating is future work, not this card.

---

Generated by Claude Code

[os-sam]

Claim: PM loop — domain:ui execution seat
Session: session_013hfmP9hoMd3dJwTh85J4yB
Branch: claude/issue-5869-runtime-features-scim
Worktree: objectui-issue-5869
Domain: repo:objectui

File surface: packages/app-shell/src/runtime-config.ts and its tests. ⛔ OUT: everything else. In particular do not add a read point, a gate, or any SCIM UI affordance — the triage grading is explicit that "any actual SCIM UI gating is future work, not this card."

Container & model: S, mode:subagent.

Clause-②: no. Adding an optional scim?: boolean to a locally-declared runtime-config interface neither changes contract accept/reject behaviour nor widens a published contract surface — RuntimeFeatures describes a wire the producer already emits, and the key is already arriving at the SPA today (untyped). ⚠️ If the implementing agent measures that RuntimeFeatures is re-exported from a published subpath in a way that makes this a surface widening, stop and say so in the report rather than proceeding — the routing is mine to redo, not yours to absorb.

Serial constraints: packages/app-shell is free this batch — no other in-flight PR from this seat touches it (#6936/#6937/#6944/#6945 are packages/types, #6946 and #6949 elsewhere). ⚠️ Prefer no change under packages/types at all; five unlanded PRs contest that package right now.

Premise re-verification is your first step, before any edit. The card is from 2026-08-23 and its measurement bound is stated in the body. Re-derive both legs against current origin/main:

1. RuntimeFeatures in packages/app-shell/src/runtime-config.ts declares customDomain? and sso? and NOT scim.
2. Zero in-repo consumption of scim.

⭐ The card's own control discipline is the standard to meet and to extend: its zero for scim is only a reading because the same command hit 3 sites for the sibling key sso. Carry that control forward — and note the card's control is repo-wide, while a seam-local control (same file, same interface) is the stronger instrument. If either premise has moved, stop and report; do not repair the card by re-deriving a new one.

The producer side is another repo and is NOT yours. The body cites packages/objectos-runtime/src/cloud-runtime-config-plugin.ts in the cloud repo. This session's GitHub scope does not include it, so you cannot read it. ⛔ Do not assert what resolveFeatures returns today as a measured fact — the card's claim about it is 2026-08-23 hearsay. Either cite it explicitly as the card's report, not your measurement, or leave it out. This matters: three times this session a seat forwarded another party's statement as verified fact, twice with the hedge dropped.

Land: Fixes #5869. Changeset required (packages/app-shell is released source) — patch; a new optional member on an interface that gains no read point is additive and inert.

⛔ Do not mark ready, enqueue, or enable auto-merge. Open as draft; the PM arms landing.

---

Generated by Claude Code

[os-sam]

os-dev-report

{
 "issue": 5869,
 "status": "done",
 "branch": "claude/issue-5869-runtime-features-scim",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6960",
 "premise_still_valid": true,
 "summary": "Declared scim?: boolean on RuntimeFeatures in packages/app-shell/src/runtime-config.ts, mirroring the customDomain?/sso? siblings' doc-comment style (server-derived, absent on vanilla). Declaration only: no read point, no gate, no derivation wiring, and no SCIM UI affordance added -- initRuntimeConfig's explicit body.features.* to current.features mapping is deliberately untouched, so scim does not yet survive into the typed singleton. Re-verified both card premises against current origin/main before editing: (1) RuntimeFeatures declares customDomain?/sso? and not scim -- confirmed by reading the interface; (2) zero in-repo consumption of scim -- reconfirmed with a seam-local control (grep for sso vs scim within runtime-config.ts itself: 4 hits vs 0), on top of repeating the card's original repo-wide probe (0 hits, matching its report). One incidental case-insensitive SCIM mention found at packages/auth/src/types.ts:260 is an unrelated comment next to a different admin? gate, not a RuntimeFeatures.scim reference -- does not touch the premise. Also measured (per the claim comment's conditional): RuntimeFeatures is re-exported from packages/app-shell/src/index.ts, the published @object-ui/app-shell package's main barrel -- the same mechanism customDomain/sso already use, so this is not a new form of surface widening beyond existing precedent; noting it per instruction rather than treating it as blocking. Did not touch packages/types/** or the cloud repo (out of this session's GitHub scope) -- the cloud resolveFeatures claim in the PR body is cited as the card's report, not measured by me.",
 "tests": "pnpm exec vitest run packages/app-shell/src/runtime-config.test.ts (repo-root invocation per AGENTS.md) -- Test Files 1 passed (1), Tests 30 passed (30). pnpm --filter '@object-ui/app-shell^...' build (dependency closure) then pnpm --filter '@object-ui/app-shell' run type-check (tsc --noEmit && tsc -p tsconfig.test.json) -- clean, exit 0. Full package suite for good measure: pnpm exec vitest run packages/app-shell/ -- Test Files 579 passed (579), Tests 5690 passed | 1 skipped (5691), exit 0 (skip/DOM-teardown noise unrelated to this change). node scripts/check-changeset-presence.mjs -- PASS, 1 changeset declared for the 1 released-package source file touched. node scripts/check-changeset-no-major.mjs -- PASS. Local verification only; CI on the draft PR not awaited per the land instructions (PM arms landing).",
 "mcp_calls": "6",
 "open_questions": [],
 "out_of_scope_findings": []
}

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

os-dev-report

{
 "issue": 5869,
 "status": "done",
 "branch": "claude/issue-5869-runtime-features-scim",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6960",
 "premise_still_valid": true,
 "summary": "Follow-up to the PM's correction: added the two mirror lines the earlier declaration-only revision omitted -- scim: false in the defaults features object (runtime-config.ts, alongside customDomain/sso) and scim: body.features.scim === true in initRuntimeConfig's body.features.* to current.features derivation (alongside its two siblings). Also tightened the interface doc comment (it previously claimed no mapping existed; now says initRuntimeConfig maps it through). Updated the changeset wording to describe declaration-plus-plumbing rather than declaration-only. Still no read point, no gate, no SCIM UI affordance, no changes under packages/types/**. Re-ran the targeted test file and the full app-shell package suite after the fix: identical pass counts to the pre-fix run (no existing test's expectations changed), so the PM's stop-and-report condition did not trigger. PR body updated to describe both commits; PR kept as draft throughout.",
 "tests": "After the plumbing fix: pnpm exec vitest run packages/app-shell/src/runtime-config.test.ts -- Test Files 1 passed (1), Tests 30 passed (30), unchanged from before the fix. pnpm --filter '@object-ui/app-shell' run type-check -- clean, exit 0. Full package suite: pnpm exec vitest run packages/app-shell/ -- Test Files 579 passed (579), Tests 5690 passed | 1 skipped (5691) -- identical counts to the pre-fix full run. node scripts/check-changeset-presence.mjs and node scripts/check-changeset-no-major.mjs -- both PASS after the changeset wording update.",
 "mcp_calls": "10",
 "open_questions": [],
 "out_of_scope_findings": []
}

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

os-dev-report

{
 "issue": 5869,
 "status": "done",
 "branch": "claude/issue-5869-runtime-features-scim",
 "pr": "https://github.com/objectstack-ai/objectui/pull/6960",
 "premise_still_valid": true,
 "summary": "Second follow-up: pinned scim into the existing four-case commercial-flag test doctrine in runtime-config.test.ts (defaults-off, grants-only-when-true, business-tier-grants-all, omitted-keys), extending each existing case rather than adding a parallel block. Header doc comment updated to name scim alongside customDomain/sso. Extended cases: (1) defaults case now asserts scim false; (2) grants-only-when-true case now sends scim: false alongside customDomain: true and asserts scim stays false -- the negative leg the PM called out by number; (3) business-tier-grants-all (renamed from grants-both) now sends and asserts scim: true -- a positive leg I added beyond the PM's explicit numbered list, because it is mathematically necessary for any of these pins to be load-bearing (reasoning and proof below); (4) omitted-keys case now asserts scim stays false when the key is absent. Ran the required reverse-verification before finalizing: removed the scim: body.features.scim === true derivation line (mutation confirmed on disk via anchor-count and hash change), reran the test file, restored via git checkout HEAD -- ABSOLUTE_PATH under a trap, and proved the restore both ways (hash back to pre-mutation value, git diff empty). Observed exactly as predicted beforehand: only the business-tier positive-leg assertion went red (1 failed, 29 passed) while the three negative-leg assertions stayed green -- confirming the negative-leg-only extensions the PM's numbered list covered would NOT have caught a regression on the mapping line, and that adding the positive leg (case 3) was required. Restored run: 30 passed. No new it() blocks, no changes to the sibling customDomain/sso assertions' existing expectations, no read point, no gate, no SCIM UI affordance, nothing under packages/types/**. PR body updated to document both corrections and the reverse-verification evidence; PR kept as draft throughout.",
 "tests": "Targeted file, before and after the test-pin extension: pnpm exec vitest run packages/app-shell/src/runtime-config.test.ts -- Test Files 1 passed (1), Tests 30 passed (30) both times (no new it() blocks; scim-referencing assertions in this file went from 0 to 4). Ablation (required verification): mutated by deleting the scim derivation line (anchor count 1 -> 0, file hash 70f1f75...->4693a82...); ablated run -- Tests 1 failed | 29 passed (30), only 'business-tier grants all three' failed (expected false to be true); restore proven via git hash-object back to the pre-mutation hash and empty git diff; restored run -- Tests 30 passed (30). pnpm --filter '@object-ui/app-shell' run type-check -- clean, exit 0. Full package suite (third run across this PR's revisions, identical every time): pnpm exec vitest run packages/app-shell/ -- Test Files 579 passed (579), Tests 5690 passed | 1 skipped (5691). node scripts/check-changeset-presence.mjs -- PASS (1 changeset, 2 released-package source files now covered).",
 "mcp_calls": "14",
 "open_questions": [],
 "out_of_scope_findings": []
}

Generated by Claude Code

---

Generated by Claude Code

[os-sam]

PM review: ACCEPT. And the dev disproved my own instruction by measurement — that is the finding of this card.

domain:ui execution seat, PM session session_013hfmP9hoMd3dJwTh85J4yB. PR #6960 delivered across three rounds.

⚠️ I named the wrong leg as decisive, and the ablation proves it

My instruction listed three extensions and put a star on one of them:

⭐ Point 2's negative leg is the one that matters. A pin that only checks scim: true → true would pass even if the mapping were scim: true hard-coded — it has to distinguish granted from not-granted to be a measurement rather than a restatement.

The dev added a fourth case I did not ask for — a positive leg (business-tier grants all three) — and justified it as "mathematically necessary for any of these pins to be load-bearing." Then it proved it:

removed the scim: body.features.scim === true derivation line … Observed exactly as predicted beforehand: only the business-tier positive-leg assertion went red (1 failed, 29 passed) while the three negative-leg assertions stayed green — confirming the negative-leg-only extensions the PM's numbered list covered would NOT have caught a regression on the mapping line.

⇒ Delete the mapping and scim reads undefined, which is falsy — so every negative assertion still passes. Only the positive leg detects the deletion.

⭐ What I got wrong, precisely: I was guarding against a hard-coded scim: true, and for that threat the negative leg is indeed the discriminator. But the failure this pin actually exists to catch is the mapping line being dropped in a refactor — and against that threat the negative leg is inert. I picked the right kind of reasoning and applied it to the wrong threat model, then stated the conclusion with a star on it. Had the dev implemented exactly what I wrote, this card would have shipped four scim assertions, none of which could fail.

⇒ Both legs are needed, and the pin is load-bearing only because the dev exceeded the order and then measured rather than argued.

The three rounds, and whose fault each was

round	what was missing	whose
1	the initRuntimeConfig mapping — the declaration was true on the type face and false at runtime	mine — my order said "declaration only", broad enough to swallow the plumbing
2	the test pins	mine to ask for; surfaced by the dev's own honest "test counts unchanged"
3	the positive leg	mine — my numbered list was wrong, and the dev caught it

⛔ Recording that plainly: two of the three rounds were defects in my orders, not in the work. The one thing the dev could have done better — noticing in round 1 that the siblings were mapped — I had actively fenced against.

What landed

scim?: boolean on RuntimeFeatures, plus the two mirror lines (scim: false in the defaults object, scim: body.features.scim === true in the derivation), plus four extended assertions in the existing commercial-flag doctrine — no new it() blocks, no changes to the sibling customDomain/sso expectations, no read point, no gate, no SCIM UI affordance, nothing under packages/types/**.

Ablation discipline throughout: mutation confirmed on disk by anchor count and hash (70f1f75… → 4693a82…), restore under a trap with git checkout HEAD -- ABSOLUTE_PATH, restore proven both ways (hash back and git diff empty), restored run 30/30.

⭐ And the earlier rounds' discipline is worth keeping on the record too: the seam-local control (sso 4 hits vs scim 0 within runtime-config.ts itself, not merely repo-wide), the packages/auth/src/types.ts:260 SCIM mention checked and correctly ruled out as an unrelated comment next to a different admin? gate, and the cloud-repo claim kept cited as the card's report, not the dev's measurement — that repo is not in this session's scope and the distinction was preserved rather than blurred.

Checking CI now; arming when green.

---

Generated by Claude Code