Found while sweeping #8224 (PR #10072). Observation-class: nothing is broken today — every one of these may still be factually correct. The point is that none of them has been checked since the pin moved, and their wording asserts otherwise. Filed unassigned, no pm:queue, for the record. Measured, not inferred.
The premise
#8224's generalizable lesson, in its own words:
Anywhere a comment says "verified against X", the pinned version drifting past X should be treated as an unverified claim, not a stale note.
#3002 (closed today via PR #9869) moved the better-auth family from 1.7.0-rc.2 to ^1.7.1. That bump is exactly the drift the lesson describes, and it fired on every such comment in plugin-auth/src at once. PR #10072 sweeps only the @better-auth/ssoschema-option sentence that #8224 scoped; the rest are untouched and out of that card's surface.
Measured
Installed versions read from node_modules on 2026-08-19: better-auth@1.7.1, @better-auth/sso@1.7.1, @better-auth/scim@1.7.0-rc.1.
29 lines across 21 files in packages/plugins/plugin-auth/src still name 1.7.0-rc.2 or 1.6.20, after excluding PR #10072's own corrections and the sites whose wording is explicitly historical.
Not all 29 are defects — the class splits, and that split is the actual work:
(a) Live attestations about the CURRENT pin — these read false today. The wording claims to describe the version the package pins, and it no longer does:
session-tombstone.ts:34 — Verified against better-auth 1.7.0-rc.2, the version this package pins (the relative clause is now simply untrue)sso-client-secret.ts:24 — @better-auth/sso at the pinned 1.7.0-rc.2 has NO secret-at-rest optionremove-member-permission-guard.ts:10 — pinned vendor. better-auth 1.7.0-rc.2register-sso-provider.ts:130 — is a z.strictObject in @better-auth/sso@1.7.0-rc.2revoke-session-match-guard.ts:11, impersonation-bearer-rotation.ts:11, auth-manager.ts:3582, session-tombstone.ts:83, managed-extension-fields.test.ts:186 and :906 (at the pinned version — better-auth 1.7.0-rc.2)
(b) Deliberately historical, and correct as written — leave alone. e.g. admin-user-endpoints.ts:70 (accountId is the STABLE 1.7 spelling; 1.7.0-rc.2 briefly called it …) and objectql-adapter.test.ts:92. These contrast an old version with the current one on purpose; rewriting them would destroy the information.
(c) One that is a different claim entirely, noted because it is the same shape: auth-schema-config.ts:917 — Mirrors @better-auth/sso@1.6.20's BaseSSOProvider. That is a field-surface claim about a version two minors old; whether the mapping still mirrors 1.7.1's BaseSSOProvider was not measured here.
Why this might matter
The 1.6.20-stamped schema-option sentence #8224 is about was not wrong when written — it decayed, silently, with every gate green, and was only caught because an unrelated card (#8193) happened to read the same file. Category (a) is that same shape, already in the same state, spread across 10+ sites. Category (b) proves a blanket find-and-replace would be the wrong fix.
Why it is NOT being changed in PR #10072
Out of that card's scope and surface. #8224 scopes one dependency fact — whether @better-auth/sso accepts a schema option — across the files that carry it. Re-verifying ten unrelated behavioural claims about session GC, bearer rotation, permission guards and secret-at-rest against 1.7.1 is a different piece of work with a different verification burden: each one needs the behaviour re-measured, not the string re-typed.
Suggested shape, if this is ever picked up
Re-measure each category-(a) site against the installed version and re-stamp with version and date (the form PR #10072 uses), or drop the version stamp where the claim does not actually depend on one. ⛔ Do not batch-rewrite: category (b) is correct as written, and category (c) needs a real measurement rather than a stamp refresh.
Worth considering alongside it: a gate could make this class mechanically visible — a check that every better-auth@<version> mention in a comment matches the current package.json pin would have caught all of this the moment #9869 merged. That is a bigger proposal than the sweep and is why this is filed as an observation rather than queued.
Backlink: found during #8224 / PR #10072.
Generated by Claude Code
Found while sweeping #8224 (PR #10072). Observation-class: nothing is broken today — every one of these may still be factually correct. The point is that none of them has been checked since the pin moved, and their wording asserts otherwise. Filed unassigned, no
pm:queue, for the record. Measured, not inferred.The premise
#8224's generalizable lesson, in its own words:
#3002 (closed today via PR #9869) moved the better-auth family from
1.7.0-rc.2to^1.7.1. That bump is exactly the drift the lesson describes, and it fired on every such comment inplugin-auth/srcat once. PR #10072 sweeps only the@better-auth/ssoschema-option sentence that #8224 scoped; the rest are untouched and out of that card's surface.Measured
Installed versions read from
node_moduleson 2026-08-19:better-auth@1.7.1,@better-auth/sso@1.7.1,@better-auth/scim@1.7.0-rc.1.29 lines across 21 files in
packages/plugins/plugin-auth/srcstill name1.7.0-rc.2or1.6.20, after excluding PR #10072's own corrections and the sites whose wording is explicitly historical.Not all 29 are defects — the class splits, and that split is the actual work:
(a) Live attestations about the CURRENT pin — these read false today. The wording claims to describe the version the package pins, and it no longer does:
session-tombstone.ts:34—Verified against better-auth 1.7.0-rc.2, the version this package pins(the relative clause is now simply untrue)sso-client-secret.ts:24—@better-auth/sso at the pinned 1.7.0-rc.2 has NO secret-at-rest optionremove-member-permission-guard.ts:10—pinned vendor. better-auth 1.7.0-rc.2register-sso-provider.ts:130—is a z.strictObject in @better-auth/sso@1.7.0-rc.2revoke-session-match-guard.ts:11,impersonation-bearer-rotation.ts:11,auth-manager.ts:3582,session-tombstone.ts:83,managed-extension-fields.test.ts:186and:906(at the pinned version — better-auth 1.7.0-rc.2)(b) Deliberately historical, and correct as written — leave alone. e.g.
admin-user-endpoints.ts:70(accountIdis the STABLE 1.7 spelling;1.7.0-rc.2briefly called it …) andobjectql-adapter.test.ts:92. These contrast an old version with the current one on purpose; rewriting them would destroy the information.(c) One that is a different claim entirely, noted because it is the same shape:
auth-schema-config.ts:917—Mirrors @better-auth/sso@1.6.20's BaseSSOProvider. That is a field-surface claim about a version two minors old; whether the mapping still mirrors1.7.1'sBaseSSOProviderwas not measured here.Why this might matter
The
1.6.20-stampedschema-option sentence #8224 is about was not wrong when written — it decayed, silently, with every gate green, and was only caught because an unrelated card (#8193) happened to read the same file. Category (a) is that same shape, already in the same state, spread across 10+ sites. Category (b) proves a blanket find-and-replace would be the wrong fix.Why it is NOT being changed in PR #10072
Out of that card's scope and surface. #8224 scopes one dependency fact — whether
@better-auth/ssoaccepts aschemaoption — across the files that carry it. Re-verifying ten unrelated behavioural claims about session GC, bearer rotation, permission guards and secret-at-rest against1.7.1is a different piece of work with a different verification burden: each one needs the behaviour re-measured, not the string re-typed.Suggested shape, if this is ever picked up
Re-measure each category-(a) site against the installed version and re-stamp with version and date (the form PR #10072 uses), or drop the version stamp where the claim does not actually depend on one. ⛔ Do not batch-rewrite: category (b) is correct as written, and category (c) needs a real measurement rather than a stamp refresh.
Worth considering alongside it: a gate could make this class mechanically visible — a check that every
better-auth@<version>mention in a comment matches the currentpackage.jsonpin would have caught all of this the moment #9869 merged. That is a bigger proposal than the sweep and is why this is filed as an observation rather than queued.Backlink: found during #8224 / PR #10072.
Generated by Claude Code