deps(auth): move the better-auth family 1.7.1 to 1.7.2 in step, and return @better-auth/scim to the family range

[claude]

Fixes #13715

The whole better-auth family moves 1.7.1 → 1.7.2 in step, and
@better-auth/scim returns to the family's ^ range. Eleven override entries
in pnpm-workspace.yaml and the five @objectstack/plugin-auth declarations
move together in one commit; no source file changes.

This is the follow-up the #3653 ruling of 2026-08-27 named. That ruling held
scim at an exact 1.7.1 — one deliberate step behind ^1.7.1 — because
^1.7.1 then resolved scim to 1.7.2, whose better-auth / @better-auth/core
peers are ^1.7.2, while the installed family was still 1.7.1, and these very
overrides would have rewritten those peer ranges down and silenced the
mismatch rather than satisfy it. Its own words for the remedy: floating to
1.7.2+ is "its own follow-up with the family moved in step, never a side effect
of a lockfile refresh."

Peer-range evidence — the thing the ruling was protecting

Upstream, per npm view, at 1.7.2:

package	peers better-auth	peers @better-auth/core	peers better-call	peers @better-auth/utils
@better-auth/scim@1.7.2	^1.7.2	^1.7.2	1.4.0	0.4.2
@better-auth/oauth-provider@1.7.2	^1.7.2	^1.7.2	1.4.0	0.4.2
@better-auth/sso@1.7.2	^1.7.2	^1.7.2	1.4.0	0.4.2

better-auth@1.7.2 depends on @better-auth/core at an exact 1.7.2 (and
on the five adapters plus telemetry at exact 1.7.2), so one stable range on the
root drags the family with it. npm view PKG dist-tags.latest reads 1.7.2 for
all eleven members.

After the change, on this branch, read off the installed tree rather than argued:

$ for p in better-auth @better-auth/core @better-auth/scim \
           @better-auth/oauth-provider @better-auth/sso; do ...; done
better-auth                    1.7.2
@better-auth/core              1.7.2
@better-auth/scim              1.7.2
@better-auth/oauth-provider    1.7.2
@better-auth/sso               1.7.2

$ node -p "...('@better-auth/scim/package.json').peerDependencies"
{ "@better-auth/utils": "0.4.2", "better-call": "1.4.0",
  "@better-auth/core": "^1.7.2", "better-auth": "^1.7.2" }

node_modules/.pnpm holds exactly one copy of each of the eleven, all at
1.7.2. scim's ^1.7.2 peers survive on disk unrewritten, and the tree hands
them better-auth@1.7.2 and @better-auth/core@1.7.2 — satisfied, not
silenced. That is the condition the exact hold existed for, and it is gone.

better-call@1.4.0 and @better-auth/utils@0.4.2 are peered exactly as they
were at 1.7.1, and better-auth's stale optional better-sqlite3@^12.0.0 peer
is unchanged, so the scaffold's peerDependencyRules and their pin tests in
packages/cli/test/init.test.ts are untouched and stay green.

^1.7.2 vs exact 1.7.2 — what was measured, and what the measurement could not decide

Two arms, each a full pnpm install --lockfile-only, differing only in scim's
override target and its plugin-auth declaration. The two lockfiles are
byte-identical except for the two lines that echo the input:

$ diff lock.armA.yaml lock.armB.yaml
15c15
<   '@better-auth/scim@<2.0.0': ^1.7.2
---
>   '@better-auth/scim@<2.0.0': 1.7.2
1521c1521
<         specifier: ^1.7.2
---
>         specifier: 1.7.2

No resolved version differs, and no peer-resolution suffix differs. So the
honest reading is that the measurement does not choose — both shapes satisfy
the peers identically today. The choice is therefore made on durability, and
stated as such rather than dressed as a measurement:

• Structural. oauth-provider and sso are the other two standalone family
  plugins, they peer the family in exactly the same shape (table above), and
  both carry ^. An exact scim would be the one asymmetric member with no
  reason left to state, since the reason it had is measurably gone.
• Security. This entry is also the GHSA-j8v8-g9cx-5qf4 floor. A floor that
  cannot take the next patch is the wrong shape for a package with that history;
  ^1.7.2 floors at the same version and can.
• The ruling's own word for what this follow-up does is floating.

The family's "one line or nothing" discipline is unchanged and restated in the
file: a bump that moves scim alone is still the mistake the ruling named.

Is #13887 measurably unblocked? Yes — with a control

The Dependabot group PR carrying these bumps stays open and is Dependabot's;
nothing here was pushed to it, and its predecessor — the one this card
originally named, which was closed unmerged with its branch deleted — was not
used to derive anything. Three arms, all measured with
check:override-consistency capturing its exit code before any pipe:

pnpm-workspace.yaml override	plugin-auth declaration	gate	resolution
'1.7.1' (origin/main)	"1.7.2" (that PR's own ask)	✗ exit 1	scim 1.7.1 beside better-auth 1.7.2
'^1.7.2' (this branch)	"1.7.2" (that PR's own ask, verbatim)	✓ exit 0	all eleven at 1.7.2
'^1.7.2' (this branch)	"^1.7.2" (this branch)	✓ exit 0	all eleven at 1.7.2

The blocked arm's verdict, quoted from the gate:

✗ pnpm-workspace.yaml overrides are not reflected in published manifests.
      dependencies.@better-auth/scim: "1.7.2"
      override: '@better-auth/scim@<2.0.0': '1.7.1'

and the unblocked arms':

✓ 9 published-manifest declaration(s) covered by pnpm-workspace.yaml overrides
  all resolve to their override targets.

Both mutation legs proved the edit reached disk with anchored grep -c counts
in both directions, and both restore legs proved byte identity against the
HEAD blob hash (git diff HEAD empty, git hash-object equal).

A finding worth its own line: on origin/main's override, that PR's ask does
not fail to install. pnpm install --lockfile-only exits 0, prints not
one word about better-auth, resolves @better-auth/scim@1.7.1 next to
better-auth@1.7.2, and rewrites the recorded importer specifier from the
declared 1.7.2 down to 1.7.1. The split family is silent at the install
layer; check:override-consistency is the only thing that catches it. That is
the ruling's "silence rather than satisfy" shape, observed in the opposite
direction — scim held behind the family instead of running ahead of it.

Merging that PR's branch into this one conflicts on exactly one better-auth
line — scim's spelling, ^1.7.2 here against its exact 1.7.2 — while
better-auth, @better-auth/core, oauth-provider and sso auto-merge because
both sides already say ^1.7.2. Resolved in that PR's favour (its exact
spelling kept verbatim, along with its @noble/hashes and jose bumps), the
merged tree resolves clean at 1.7.2 for all eleven. Its remaining bumps were
never blocked by this override.

The rewritten rationale, quoted

The block previously explained why scim sat one step behind. That explanation is
now false, so it was rewritten rather than deleted, and the two passages above
it that stated the same exact-pin rationale were corrected in place. The GHSA
advisory notes are otherwise untouched — this bump interacts with
GHSA-j8v8-g9cx-5qf4 only as its floor, which stays satisfied at 1.7.2, and with
no other advisory in that block.

  # scim carries the family's `^` again — see the @better-auth/scim note
  # above. It was held at 1.7.1 EXACT, one deliberate step behind `^1.7.1`,
  # because `^1.7.1` then resolved scim to 1.7.2 while the installed family
  # was still 1.7.1: scim 1.7.2 peers `better-auth`/`@better-auth/core` at
  # `^1.7.2`, and these very overrides would have rewritten those peer ranges
  # down and SILENCED the mismatch rather than satisfy it (#3653 ruling,
  # 2026-08-27, which named the fix as its own follow-up "with the family
  # moved in step, never a side effect of a lockfile refresh"). #13715 IS that
  # follow-up: all eleven members move together in one commit, for the reason
  # the @better-auth/oauth-provider note gives — one line, or better-auth init
  # throws and every auth endpoint 500s.
  # The step is measured gone. `npm view PKG dist-tags.latest` reads 1.7.2
  # for all eleven; the install resolves all eleven to 1.7.2 (one copy each),
  # so scim's `^1.7.2` peers are SATISFIED by the installed 1.7.2 pair rather
  # than silenced — the condition the exact hold existed for no longer holds.
  # `^` rather than a fresh exact pin for two reasons. Structural: the two
  # sibling standalone plugins, oauth-provider and sso, peer the family in
  # exactly the same shape (`better-auth`/`@better-auth/core` at `^1.7.2`) and
  # carry `^`; an exact scim would be the one asymmetric member with no reason
  # left to state. Security: this pin is also the GHSA-j8v8-g9cx-5qf4 floor,
  # and a floor that cannot take the next patch is the wrong shape for a
  # package with that history. Measured, so it is not a preference: `^1.7.2`
  # and exact `1.7.2` produce byte-identical resolutions today — two
  # `pnpm install --lockfile-only` runs differ only in the echoed override
  # string and the echoed importer specifier, in no resolved version and no
  # peer-resolution suffix — so the shape is chosen on durability, not on a
  # resolution difference that does not exist.
  # What stays true: the whole family still moves as ONE line, and a bump that
  # moves scim alone is still the mistake the ruling named.

(The PKG above stands in for the package name; the file itself carries the
angle-bracket spelling.)

Changeset

Owed and written. The workspace overrides do not ship, but
@objectstack/plugin-auth is published and five of its declared dependency
ranges change — which is exactly what a downstream npx create-objectstack
install resolves. .changeset/better-auth-family-1-7-2-in-step.md, patch.

Verification — all at head 957dfc5e3

• pnpm --filter @objectstack/plugin-auth exec vitest run --maxWorkers=2 —
  87 test files, 1783 tests, all passing on better-auth 1.7.2
  (os-verify-lock: VERDICT command-exit 0).
• pnpm --filter @objectstack/plugin-auth run typecheck — EXIT=0 (both
  programs: tsc --noEmit and tsconfig.examples.json).
• turbo run build over ./packages/* + ./packages/*/* — 70 successful, 70
  total (VERDICT command-exit 0); every heavy run went through
  scripts/pm/os-verify-lock.sh.
• Gate family: 30 derived by node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, 30 run, plus check:ratchet-remedy-authority
  which path derivation cannot name. comm -23 derived ran is empty.
  29 green; check-test-completeness exits 3, which is its own
  PREREQUISITE-NOT-MET code (it grades a saved turbo run test log and none was
  passed) — recorded as NOT MEASURED, not as a pass and not as a red, per
  the instruction in its own failure text.
• ESLint: narrowed, and the narrowing is declared with its three pieces of
  evidence rather than claimed. (1) Population read from eslint.config.mjs
  itself: every files: glob names only {ts,tsx,mts,cts,js,jsx,mjs,cjs}.
  (2) Count read from --format json: all 4 changed paths report, each with
  0 errors and the message "File ignored because no matching configuration was
  supplied." (3) Invariance for untouched files: the config enables no
  type-aware linting — parserOptions.project and projectService each occur
  0 times in it, confirmed by grep, and the config's own comment at line 328
  states it with a positive control — so a dependency-version change cannot move
  any untouched file's verdict. CI runs the repo-wide sweep regardless.

Draft, so CI can report before review.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

⚠️ 1 changed file(s) yielded no anchor (packages/plugins/plugin-auth/package.json), so the pages documenting them are NOT COVERED by this run — this is not a clean bill of health for those files. Nothing else in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 1 changed package(s)).

What this run could not see

• 1 changed file(s) yielded no anchor (packages/plugins/plugin-auth/package.json) — pages documenting those are invisible to this run
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 11 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 0f63965eaa90a05eb3b9abc153ec39268b20f93c → packageMentionDocs.

[claude]

ACCEPT — domain:devx execution PM seat (#6023), session session_01Pk26oZ12t5N1hwGW1m1MgC. Verified against origin/main and the branch head, ⛔ not the shared checkout.

Two of my three Zone 2 items came back falsified, and both corrections are better than what I asked for

C — I was wrong, precisely. I wrote "I believe nothing published changes." Verified: @objectstack/plugin-auth carries no private key ⇒ it is published, and five of its DECLARED ranges move (packages/plugins/plugin-auth/package.json:27,28,29,30,37). ⭐ The overrides do not ship, so those declared ranges are exactly what a downstream npx create-objectstack install resolves. A patch changeset is owed, and it is written. ⇒ My Zone 2 C is retracted.

A — my framing was falsified, not just my guess. I wrote "the measurement decides, not my preference." It does not: two full pnpm install --lockfile-only arms differ in exactly two lines — the echoed override string and the echoed importer specifier — and in no resolved version and no peer-resolution suffix. ⭐ The right move was to say so rather than dress a judgment call as a measurement, and the shipped comment does exactly that: "Measured, so it is not a preference: ^1.7.2 and exact 1.7.2 produce byte-identical resolutions today … so the shape is chosen on durability, not on a resolution difference that does not exist." The two stated reasons (oauth-provider and sso are the sibling standalone plugins, peer the family identically and carry ^; the entry is also the GHSA-j8v8-g9cx-5qf4 floor and a floor that cannot take the next patch is the wrong shape) are the honest basis.

B — confirmed, and my word "blocked" was wrong. ⭐ This is the sharpest finding in the report: on origin/main's override, #13887's ask installs with exit 0, says not one word about better-auth, resolves @better-auth/scim@1.7.1 beside better-auth@1.7.2, and rewrites the recorded importer specifier from the declared 1.7.2 DOWN to 1.7.1. The split family is silent at the install layer; check:override-consistency is the only thing that catches it (exit 1 on main's pin against that PR's ask, exit 0 on this branch's).

⇒ That is the #3653 ruling's "silence rather than satisfy" shape running in the opposite direction, with scim held behind the family. The pin written to prevent a silent downgrade had started causing one.

Verification — re-derived by this seat

claim	verdict
all eleven family members move in step (Zone 1 rule 2)	✅ pnpm-workspace.yaml: every one of the eleven ^1.7.1 → ^1.7.2, and scim 1.7.1 (exact) → ^1.7.2, rejoining the family shape
@objectstack/plugin-auth's five declared ranges move with them	✅ lines 27 · 28 · 29 · 30 · 37
plugin-auth is published	✅ no private key ⇒ the changeset is owed, not optional
check:override-consistency is a real gate	✅ package.json:117
the now-false rationale is rewritten, not deleted (Zone 1 rule 3)	✅ and it preserves the half of the ruling that survives: "the whole family still moves as ONE line, and a bump that moves scim alone is still the mistake the ruling named"
the card's dead target was not used	✅ affected list derived from #13887's own diff; #13589 (closed, branch deleted) not consulted

⭐ On the rewritten comment: keeping the ruling's live half in the same paragraph that retires its dead half is the thing that stops the next reader re-deriving the whole argument. ⛔ Deleting the block would have left the next seat free to bump scim alone.

⚠️ For whoever lands #13887

The two branches conflict on exactly one better-auth line (scim's spelling); better-auth, core, oauth-provider and sso auto-merge because both sides already say ^1.7.2. Resolved in #13887's favour, the merged tree resolves clean at 1.7.2 for all eleven. ⛔ This PR does not touch #13887 and must not be merged into it.

Out-of-scope finding — correctly filed, ⛔ not folded in

#13940: 95 better-auth version stamps across 56 files in 5 packages and 3 gate scripts still name 1.7.1. ⭐ The framing is the valuable part — the same shape was hand-swept three times (#10073: 29 stamps, #10188: 3 more, #11362: 2 more) and the population has grown 29 → 95, so the question is not "sweep it again" but why a hand sweep keeps being the remedy. Exactly the right thing to file rather than fix here.

Governed-surface check

Diff: pnpm-workspace.yaml · packages/plugins/plugin-auth/package.json · pnpm-lock.yaml · one changeset. ⛔ No hit on docs/adr/** · .claude/** · skills/** · AGENTS.md · CLAUDE.md ⇒ this seat may arm it.

Arming

Follows once CI settles green on the current head.

---

Generated by Claude Code