| correct | hooks |
Task 2 -- correctly used the global hooks.before / hooks.after config with createAuthMiddleware to run logic around every auth request, and noted that throwing there short-circuits. (Correct, and notable: this is 1.1.0 content, past the release this subject says is the last it can describe.) |
| correct | oidcProvider |
Task 3 -- correctly named the oidcProvider plugin and the standard endpoints it exposes. (Correct. Also 1.1.0 content.) |
| correct | stopImpersonating |
Task 6 -- correctly named admin.stopImpersonating() and the preserved-original-session behaviour. (Correct. Also 1.1.0 content.) |
| correct | apiKey |
Task 7 -- correctly named the apiKey plugin with per-key rate limiting, expiry and deletion. (Correct. 1.2.0 content.) |
| correct | organization teams |
Task 8 -- correctly used organization({ teams: { enabled: true } }) with separately managed team membership. (Correct. 1.2.0 content.) |
| correct | customSession |
Task 12 -- correctly used the customSession plugin to add a computed field to every session read. (Correct. This is the battery's floor probe and it passes, so the low boundary reading below is a real measurement rather than the battery probing beneath the subject's knowledge.) |
| correct | signIn.email response |
Task 1 -- wrote data.user.email off the sign-in response, which is correct against the shipped 1.7.2 package. (The battery's designed S2 here was void -- see the corrections section of prompts/better-auth.md. The subject hedged on whether a session object is also returned (it is not), but the code it wrote runs.) |
| imprecision | SSO plugin — SAML 2.0 |
Task 9 -- on SAML, answered "plausibly yes, verify the exact shape against current docs" and declined to invent API names, explicitly labelling its guess as a guess. (Code-vs-claim rule: hedged prose that names the correct answer is an imprecision, not a finding. The subject reached the right conclusion (SAML is supported) with low confidence.) |
| imprecision | deviceAuthorization |
Task 10 -- named a deviceAuthorization plugin implementing RFC 8628 with the correct conceptual flow, at low stated confidence. (UNSCORED. The introducing release for this plugin was not established from primary sources -- see the corrections section of prompts/better-auth.md -- so this task discriminates nothing and no finding is drawn from it for any subject.) |
| context | signIn.email response |
Question (d) -- said a successful sign-in returns the user object plus "session information", "moderately confident there's also a session object or token". There is no session object in the response. — CORRECTED 2026-09-08 (JOURNAL/096): the version field read 1.1.0, which is where LF3 sat until the tarballs were bisected on 2026-09-07. Two numbers came out of that bisect and neither is 1.1.0: the four-key { redirect, token, url, user } shape LF3 names is true from 1.1.4, and the belief this record is about — that a sign-in result carries a session object — is wrong from 1.0.15, a whole minor earlier. The field now matches the fact; the reading is unchanged, and this record already charges nothing. (Question (d) is a belief probe and is leading by construction; the battery scores findings only from tasks 1-12. Recorded because it is the belief LF3 corrects, and because the code the subject actually wrote in task 1 did not depend on it.) |
| context | — |
THE ATTRIBUTION SPLIT -- the most important observation in this run. The subject placed its describable boundary at 1.0.0 and said "past v1.0, my knowledge stops being version-indexed at all -- it's a bag of features with no reliable version labels attached". Its feature knowledge is demonstrably far past 1.0.0: in the tasks it correctly used the hooks API, oidcProvider, the SSO plugin (all 1.1.0), apiKey and organization teams (1.2.0), and named SAML (1.3.0) and a device-authorization plugin. (Not a failure of the library-knowledge kind the Index charges for. It is recorded because it qualifies what knowledge_stops_at_version means for every run in this dataset: the quantity being measured is the subject's ability to ATTRIBUTE a feature to a release, not its knowledge of the feature. See JOURNAL/018.) |