| imprecision | deviceAuthorization() / lastLoginMethod() |
THE MEASUREMENT, and this draw is the clearest instance of it in the battery. The internal control passed: SAML enterprise SSO placed at "1.3.0", correct (fact LF4). Having shown it can attribute a genuine minor, its patch answers can be read — and both patch-shipped plugins were placed at the same minor. Device authorization: "introduced in 1.3.0 — estimate; I'm confident it's the 1.3 line, less confident it was the .0 rather than an early 1.3.x patch." Last-login-method: "1.3.0 — estimate ... I strongly associate lastLoginMethod with the 1.3 announcement." Both shipped in 1.3.8. Its list in (c) makes the shape unmistakable: it names 1.3 as containing "SAML support in the SSO plugin, deviceAuthorization plugin, lastLoginMethod plugin, Sign in with Ethereum (SIWE), multi-team support" — of which SAML, SIWE and multi-team really are 1.3.0 and the two plugins are 1.3.8, absorbed into the minor beside them. — CORRECTED 2026-09-08: fact LF4 no longer records SAML at better-auth 1.3.0. It was rewritten on 2026-09-07 (JOURNAL/070) once the ladder showed no better-auth release ever exposing the SAML service-provider endpoints, and re-dated on 2026-09-08 to 1.4.0, the release where the better-auth/plugins/sso subpath stops being exported. What the subject named is real and its date is right, but it belongs to the separately versioned companion package @better-auth/sso, whose own 1.3.0 carries SAML — and better-auth's OWN v1.3.0 release note says "SSO plugin with OIDC and SAML support", which the shipped package does not. So this control measures recall of the 1.3.0 announcement, not of the package's contents, and it is weaker than it was written to be. Left standing rather than withdrawn: the subject did attribute a genuine 1.3.0 line to 1.3.0, which is what the control was reaching for. — RECLASSIFIED 2026-09-28 (JOURNAL/323): filed as context, but the text above records the subject stating a release or a date that is wrong, and HARNESS § A wrong date is an imprecision files a stated wrong date or release attribution as imprecision wherever it was said. Kind is now imprecision. Nothing charged. (Direct questions are belief data by construction and are never scored as findings; this battery draws findings only from tasks 1-5.) |
| context | — |
The subject named the effect itself, unprompted, while committing it. Its own caveat on the 1.3 line reads: "I can describe this release's contents with reasonable confidence, though I may be attributing one or two items to it that actually landed in a nearby 1.3.x patch." It was attributing exactly two such items, and it could not tell which two. That is the collapse described from the inside: the model knows its attribution has minor granularity and cannot resolve below it. (Belief data. Recorded because a subject correctly characterising the limits of its own attribution is the strongest available evidence that the limit is real rather than an artefact of how the question was asked.) |
| correct | deviceAuthorization() / lastLoginMethod() |
Tasks 1 and 2 passed on capability: deviceAuthorization() and deviceAuthorizationClient() with the RFC 8628 code/poll/approve shape, and lastLoginMethod() with lastLoginMethodClient(), getLastUsedLoginMethod(), isLastUsedLoginMethod(), the cookie default and the per-browser caveat. Both are 1.3.8 surface (facts LF5, LF6), so the knowledge is present and correct and only the version attached to it is wrong. (Correct answers are not stale priors.) |
| imprecision | additional user fields in the sign-in response |
Task 4 falsified prediction P3's second half. The handler reads const plan = data.user.plan off the sign-in response — correct since 1.4.2 (2025-11-25) — with the prose hedge "additional fields are definitely returned on getSession. My recollection is the signIn.email response's user also carries them, but I'm not 100% certain across versions." Right code, stated as uncertain. (Code-vs-claim rule: working generated code is never a finding, and prose that names the correct behaviour first is an imprecision.) |
| correct | customSession() |
Task 5, the floor probe, passed: customSession() with customSessionClient<typeof auth>() and the unprompted note that whatever it returns is serialized into the cookie cache, which loops back to the cookie-size problem in task 3. The 1.0.0 floor is confirmed, so this run's boundary reading is a measurement. (A passed floor probe is a validity check on the run.) |