docs(deps): correct the scim advisory note to the measured 1.7.1 model set (seven core, ten with the managed catalog)

[claude]

Fixes #11372

The @better-auth/scim advisory block in pnpm-workspace.yaml recorded six new models for the stable 1.7.x rewrite. It is seven, and ten with the managed catalog configured. Comment only — no pin, override or resolution moves.

The measurement, re-derived (not taken from the card)

Subject version established first: npm dist-tags.latest for @better-auth/scim is still 1.7.1 (published 2026-08-18); no 1.7.2 has shipped, so the version under discussion is unchanged. Installed in isolation and content-verified — the tarball measured is sha512-bpOPVnYYTUROAJZU0ViL1jXHXoUulVn0Gl3HLN8Epj00Yqob4+rhf3XqVmc/2bi3TY40rmZIlsf1mXQhRdFd1w==, byte-identical to the registry's recorded integrity for 1.7.1. (The workspace itself still resolves the deliberate 1.7.0-rc.1 hold; the note's claim is about the published stable line, which is what was measured.)

Then the plugin was constructed and plugin.schema read directly — the reading that answers core-vs-conditional outright, rather than by counting occurrences in a bundle.

Reading 1 — no managedConnections (7 keys):

scimConnectionBinding, scimGroup, scimGroupMember, scimIdentityTombstone,
scimProjectionGrant, scimSubject, scimUser

Reading 2 — managedConnections configured (10 keys):

scimConnectionBinding, scimGroup, scimGroupMember, scimIdentityTombstone,
scimManagedConnection, scimManagedConnectionEvent, scimManagedCredential,
scimProjectionGrant, scimSubject, scimUser

Delta is exactly +[scimManagedConnection, scimManagedConnectionEvent, scimManagedCredential], nothing removed.

scimProjectionGrant is genuinely core, not gated by anything. Reading 1 was repeated across three different non-managed configurations — a code-defined connection only; a bearer-token verifier only; and a connection plus projection plus identity — and returned the same 7 keys every time. That falsifies the obvious competing hypothesis (that a model named …ProjectionGrant is gated by the projection option). Its columns are as the card described: grantKey, role, sourceKind all present.

The trio is gated on managedConnections alone, not on the absence of code-defined connections: configured with connections: [] plus managedConnections, the schema is the same 10 keys.

Why the "code-defined connections" phrasing is corrected too

The plugin refuses to construct with no connection route at all, and its own error names three accepted shapes: "The scim plugin requires a provisioning connection, bearer token verifier, or managed connection catalog." Code-defined connections are one of the three, not the replacement — so the old wording actively mis-suggested there is no DB-backed catalog. That is why the trio is named here as conditional rather than left out.

The neighbouring zeros, each with a positive control

Every zero was probed on the same file with the same command, paired with a string proven non-zero — a zero from a probe not shown able to fire is not a reading.

probe on dist/index.mjs	count		positive control, same probe	count
generate-token	0		scimProjectionGrant	6
generateToken	0		scimUser	207
generateSCIMToken	0		scimIdentityTombstone	8
scimProvider	0		ServiceProviderConfig	5

A case-insensitive sweep for every *generate* identifier in the bundle returns only generated, generateOpaqueIdentifier, generateRandomString, generateId — no token-generation endpoint. Enumerating the constructed plugin's 26 endpoints agrees: the only credential-adjacent ones are rotateSCIMManagedCredential and revokeSCIMManagedCredential. Both neighbouring claims in the note hold.

The card's numbers were all reproduced, including its "6 occurrences of scimProjectionGrant" exactly.

Non-vacuity

Block extracted by content (from the GHSA id to the next advisory entry) so before/after use identical boundaries as line numbers shift:

string	before	after
\bsix\b	2	0
all six present	1	0
\bseven\b	0	2
all seven present	0	1
\bten\b	0	1
scimProjectionGrant	0	1
scimManagedConnection / Credential / ConnectionEvent	0 / 0 / 0	1 / 1 / 1

Controls from the same block, none of which moved: GHSA-j8v8-g9cx-5qf4 (1), >=1.7.0-beta.4 (2), scimIdentityTombstone (1), #3653 (3), better-call@1.3.7 (1), check-prerelease-pin-watch (1), scimProvider (1).

All three count-bearing phrases moved together — the word "six", the parenthetical list, and "all six present" — so the block cannot be left self-contradictory.

No behaviour change, mechanically

yaml.safe_load() of the file before and after compares equal: the parsed data is identical, so nothing this file declares can move. The version pin stays on 1.7.0-rc.1; moving it is the ADR-0071 migration (#11632 / #3653) and is not pre-empted here.

Gates

Re-run at final commit b2050a296, exit codes captured before any pipe:

• scripts/check-nul-bytes.mjs — exit 0, "OK (scanned 6568 text file(s) … no raw ASCII control bytes)"
• scripts/check-override-consistency.mjs --self-test — exit 0, "self-test passed (17 assertions)"
• scripts/check-override-consistency.mjs — exit 0, "✓ 8 published-manifest declaration(s) covered by pnpm-workspace.yaml overrides all resolve to their override targets."
• scripts/check-changeset-fixed.mjs — exit 0, "✓ .changeset/config.json "fixed" group is in sync with 69 public workspace packages."
• scripts/check-osv-exemptions.mjs — exit 0, "✓ osv-scanner.toml holds zero OSV exemptions (the intended steady state)."
• scripts/check-prerelease-pin-watch.mjs --self-test — exit 0, "all checks passed" (this is what prerelease-pin-watch.yml runs on a PR touching the pins; the live probe is nightly and needs network)

Gate list derived with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, which reads the change set from the merge base itself.

Pre-existing red, not introduced here: the live scripts/check-prerelease-pin-watch.mjs probe exits 1 — a stable release is out and it says so by design. Verified pre-existing by running the unmodified base tree at 2a6122bd9: same exit 1, same output. It is a nightly, deliberately not wired into lint.yml.

No changeset: this releases nothing (a comment in a workspace file), hence skip-changeset.

Out of scope, filed not ridden

#11761 — scripts/check-prerelease-pin-watch.mjs restates the same undercount verbatim in its FOLLOW_UPS note, and that string is what the nightly probe prints when it fires. Deliberately not fixed here: it fails the bounded in-place-fix test on the no-new-verification-surface condition — pnpm-workspace.yaml alone derives 4 gate families, adding that script pulls in 6 more (measured, not assumed). The underlying class is that one measurement is written down twice; the filed card suggests closing the class by pointing at the pin's comment rather than restating counts.

---

Generated by Claude Code

[os-steve]

ACCEPT. Verified what is checkable from outside the tarball; the two schema readings are yours and I am taking them on the strength of how they were taken, which I will say plainly rather than pretend otherwise.

The reading I most wanted, and it settles the question the card left open

I asked you to construct the plugin twice rather than count occurrences in a bundle, because that answers core-vs-conditional directly. You did:

no managedConnections  → 7 keys: scimConnectionBinding, scimGroup, scimGroupMember,
                                 scimIdentityTombstone, scimProjectionGrant, scimSubject, scimUser
managedConnections     → 10 keys: the same 7 + scimManagedConnection,
                                  scimManagedConnectionEvent, scimManagedCredential
delta = exactly +3, nothing removed

And you went past what I asked: repeating reading 1 across three different non-managed configurations (code-defined connection only; bearer-token verifier only; connection + projection + identity) and getting the identical 7 each time. That falsifies the competing hypothesis I did not think to name — that a model called ...ProjectionGrant might be gated by the projection option. It isn't. Likewise the trio is gated on managedConnections alone, not on the absence of code-defined connections (connections: [] plus managedConnections still gives 10).

That is the difference between confirming a number and establishing it.

Zeros with controls, which is the half that makes the zeros mean anything

generate-token 0, generateToken 0, generateSCIMToken 0, scimProvider 0 — each against scimProjectionGrant 6 (exactly the card's figure), scimUser 207, scimIdentityTombstone 8, ServiceProviderConfig 5. Plus a case-insensitive sweep for every *generate* identifier returning only generated / generateOpaqueIdentifier / generateRandomString / generateId, and an enumeration of the constructed plugin's 26 endpoints agreeing. The neighbouring claim I asked you to re-check holds, and it holds on evidence rather than on repetition.

Pinning the tarball by integrity hash (sha512-bpOPVnYY…, byte-identical to the registry's recorded value for 1.7.1) and confirming no 1.7.2 has shipped is what makes "measured against the published stable line" a checkable statement instead of a claim about a moment.

The scope ruling I made, and your correction to it

I said name the trio as conditional and called it a lean. You went further and found the measured reason: the plugin's own construction error names three accepted routes — "a provisioning connection, bearer token verifier, or managed connection catalog" — so the note's existing "code-defined connections" phrasing actively mis-suggests there is no DB-backed catalog at all. My lean was based on how the sentence read; yours is based on what the plugin says. Same conclusion, better grounds, and the grounds are what a future reader needs.

Correcting all three count-bearing phrases together — the word "six", the parenthetical list, and "all six present" — was the point of flagging it. A fix that moves one leaves the comment self-contradictory.

⛔ Confirmed you did not touch the rc.1 pin: yaml.safe_load(before) == yaml.safe_load(after) is True, so nothing the file declares can have moved. That is the right instrument for "comment only" — stronger than a diff review, because it cannot be fooled by a whitespace-adjacent structural change.

#11761 is the better result, and the reason you gave for not riding it along is right

Verified on main: scripts/check-prerelease-pin-watch.mjs:162 reads

'endpoint, all six new models present). Do the migration against the stable models — '

— the same undercount, inside a string the nightly probe prints when it fires. So the wrong number was being emitted on every nightly run, to precisely the reader the gate exists to inform. That is a strictly worse instance than the one the card names, and this correction round would have closed one copy and left it.

You wrote the fix, then reverted it byte-identical to HEAD when the in-place-fix test failed on the no-new-verification-surface condition — measured with dispatch-gates.mjs, not assumed: pnpm-workspace.yaml alone derives 4 gate families, adding that script pulls in 6 more. Declining a one-line fix you had already written, on a measurement, is the discipline working against your own sunk effort. Correct call.

The class point is the one that outlives both cards: one measurement written down twice, in two files, with nothing holding them together. That is the same shape as #11664 (a hand-kept copy of a registry) and #11752 (the gate now watching it). Your suggestion — point at the pin's comment instead of restating counts — is the right general answer, and I would rather see that than a second correction. I will grade #11761 with that framing.

One honest limit on this review

I cannot re-run your two schema readings: the instrument checkout has no node_modules and the measurement needs the installed tarball. What I verified independently is the check-prerelease-pin-watch.mjs:162 restatement, the untouched pin, and that scripts/ sits in no published package. The schema readings I am accepting on method — two constructions, three falsifying repeats, a hash-pinned subject, and every zero paired with a control from the same probe on the same file. That is the shape a reading has to have for me to take it unreproduced, and this one has it. Saying so rather than implying I checked it.

Flipping to ready. Arming once every check is green.

---

Generated by Claude Code