fix(plugin-auth): bind the auth email locale to the workspace language, not the build-time default

[hotlong]

Part of #14319

Deliberately Part of and not a closing keyword. This PR lands the half the standing
2026-08-13 ruling permits — the deployment default, resolved from the workspace language
the platform already has. The half the card actually asks for, selecting per registration
request or per user, is barred by that same ruling and belongs to the maintainer, so the
card must stay open for that decision rather than be closed by this merge.

The card's premise did not survive verification against main — two thirds of it

The issue asks for three things. Two already exist on main, and the third is barred
by a standing maintainer ruling. What is left is a real defect of the same class, and
that is what this PR fixes.

1. "Add Chinese templates" — they already ship.auth-templates.ts carries six auth
templates in four locales each: en-US, zh-CN, ja-JP, es-ES. Six times four is
twenty-four, which is exactly the seeded 24 template row(s) the issue quotes as its
evidence that the rows are missing. That log line is the localized set, not an English one.
The Chinese verification subject already exists and already reads naturally, and
plugin-email/src/auth-templates-locales.test.ts pins both.

2. "sendVerificationEmail does not select by locale" — it has since #8195. All five
auth sends spread a locale into sendTemplate, and plugin-auth/src/auth-email-locale.test.ts
drives every one of them to prove it.

3. "Select by the registration request's locale, or by sys_user.language" — both are
ruled out. The 2026-08-13 maintainer ruling, quoted in auth-manager.ts, makes the
recipient locale the deployment default, rejects Accept-Language (auth mail is routinely
sent outside the triggering request — invitations, admin-initiated resets — so a per-device
header is the wrong authority), and defers a per-user locale column until there is measured
pull. Verified rather than assumed: sys_user.object.ts has no locale and no language
field. Implementing the card as literally written would reverse that ruling, so this PR
does not.

The defect that IS there

"The deployment default" has two producers, and auth email was reading the weaker one.

	source	when it is set	reader
build-time	II18nService.getDefaultLocale()	the app artifact's i18n.defaultLocale, en if undeclared	auth email
runtime	localization.locale (ADR-0053)	Setup, Localization — tenant-scoped, admin-settable	auth SMS (#2815), audit activity summaries (framework#3039)

localization.locale offers exactly four options — en-US, zh-CN, ja-JP, es-ES —
which are exactly AUTH_EMAIL_TEMPLATE_LOCALES. auth-manager.ts even says so: "these are
also the four options the localization.locale setting offers, so the two ends agree by
construction rather than by import." The binding then read the other source anyway.

So a workspace that declared Chinese in Setup received Chinese OTP texts and English
verification mail, from one plugin, on one kernel:ready pass, a dozen lines apart.

The fix

AuthPlugin now prefers localization.locale whenever the operator has explicitly set
it — ResolvedSettingValue.source !== 'default' — which is the same precedence the sibling
branding.workspace_name binding in this file already uses, and for the same reason: get
answers the manifest default (en-US) for an untouched workspace, so taking the value
unconditionally would demote every deployment that declared i18n.defaultLocale down to
en-US. The build-time default stands underneath it. Neither producer answering leaves the
locale unnamed, which is EmailService's documented en-US fallback and the pre-#8195
behaviour. Both channels are now driven from one read, so they can no longer disagree, and
the binding live-rebinds on localization changes exactly as the SMS one does.

The ruling is untouched: the locale is still the deployment default, still resolved at the
plugin layer, Accept-Language still rejected, still no per-user locale.

Answering the dispatch's mechanism question

Template rows carry a locale column, and the platform selects per-locale rows — not
multi-language blocks inside one row. sys_email_template is keyed (name, locale);
createSysEmailTemplateLoader filters on it and pins en-US in the WHERE clause so a driver
that ignores orderBy still answers deterministically (#7731). So the fix belongs entirely
in plugin-auth, at the point that decides which locale to name. No plugin-email file is
touched, and the declared file surface holds.

Tests

New: seven cases in auth-plugin.test.ts, Auth email locale binding (localization.locale).
A zh-CN workspace binds zh-CN on both channels; ja-JP and es-ES likewise; an
untouched workspace keeps the build-time default (the #8195 non-regression); neither producer
speaking names no locale, spelled as an absent key because that is what the ladder's "no
locale means the documented default" contract is written against; no settings service at all
keeps the build-time default; a language switch re-binds live through the subscribe handler;
a failing settings read leaves the build-time default standing and warns.

Reverse verification. With the fix committed at fceba76c0, auth-plugin.ts was restored
to the merge base 5563bfb32 and the suite re-run. Direction: RED, as predicted.
5 of the 7 new cases failed, with the exact expected shape —
expected last "setDefaultEmailLocale" call to have been called with [ 'zh-CN' ] /
Received [ 'en' ] — while the two that do not depend on the settings read stayed green.
Mutation confirmed on disk before the run, by blob hash and by anchor count, not by an editor
exit code: HEAD blob 7826ea6f, mutated blob 8d8137058, applySmsLocale count 3 in the
mutated file and 0 in the fixed one. Restore confirmed after: worktree blob back to
7826ea6f, git diff HEAD empty, git status --porcelain empty. The restore leg ran from a
trap ... EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel.
No rebuild was needed for either leg: both suites import ./auth-plugin as source, so no
dist/ sits between the mutation and the assertion.

Gates — run at 40dc0aff1

Union re-derived after the final commit (dispatch-gates.mjs --repo objectstack-ai/objectstack,
no paths passed, so the script takes its own change set from the merge base).

• pnpm --filter '@objectstack/plugin-auth^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/plugin-auth test — Test Files 90 passed, Tests 1838 passed
• pnpm --filter @objectstack/plugin-auth typecheck — exit 0;
  check:test-typecheck: OK ... 10 file(s) / 94 error(s) / 23 pinned signature(s), ledger unchanged
• node scripts/check-nul-bytes.mjs — OK (scanned 7963 text file(s) ... no raw ASCII control bytes)
• 62 derived families run. The first derivation gave 38; repairing the census below added
  content/docs/** to the diff and the re-derivation returned 62, so the 24 new doc
  families were run too. All green except the four named next.
• pnpm check:type-check-coverage --re-measure — OK — 22 ledger entr(ies) re-measured in 53.8s, 755 raw tsc error(s) total, none above its recorded number
• pnpm check:skill-examples — 262 prose examples type-check across 3 surface(s)
• pnpm check:dual-build-cjs-loads — exit 0, floors held

Three of those needed the workspace closure built first (they refuse rather than answer on an
unbuilt tree, and say so); turbo run build --filter='./packages/*' --filter='./packages/*/*'
ran 70/70 successful, after which all three measured green.

One real gate finding, repaired.check-system-context-census went red on pure line rot:
this PR's edit moved an elevation read in auth-plugin.ts from line 1301 to 1345, orphaning
the anchor on the census page. Repaired with the script's own --fix, which rewrote exactly
one anchor; the gate then reported OK — 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read.

Two families NOT MEASURED locally, by their own verdict text — neither is a red.
check-test-completeness exits 3 asking for a saved turbo run test log, and instructs that
a local family run record it as NOT MEASURED. check-half-states exits 3 as an unread
instrument on this host. Both are CI's to run.

Declared narrowing — verification ran UNLOCKED.scripts/pm/os-verify-lock.sh
could not take the shared verify lock on this host: no usable flock. The shared
verify lock is declared Linux-only (flock is util-linux, and a stock macOS does
not ship it), so the commands above were run directly, without the lock —
a declared narrowing, not a silent one. No serialization guarantee held for these
runs, nor for any sibling agent in this container while they ran.

Repo-wide pnpm lint was not run; it is CI's, and no narrowing of it is claimed here.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/auth-service.mdx(via AuthManager (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via AuthManager (symbol, a top-level class))
• content/docs/permissions/authentication.mdx(via AuthManager (symbol, a top-level class))

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• 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 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c — the merge of head 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 into base 7085f90531e9ab7c9fe07b758287d7dfbe1549b3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c && git checkout ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 && git checkout -B drift-repro 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 && git merge --no-ff 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75
node scripts/docs-audit/affected-docs.mjs --json 7085f90531e9ab7c9fe07b758287d7dfbe1549b3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[hotlong]

Part of #14319

Deliberately Part of and not a closing keyword. This PR lands the half the standing
2026-08-13 ruling permits — the deployment default, resolved from the workspace language
the platform already has. The half the card actually asks for, selecting per registration
request or per user, is barred by that same ruling and belongs to the maintainer, so the
card must stay open for that decision rather than be closed by this merge.

The card's premise did not survive verification against main — two thirds of it

The issue asks for three things. Two already exist on main, and the third is barred
by a standing maintainer ruling. What is left is a real defect of the same class, and
that is what this PR fixes.

1. "Add Chinese templates" — they already ship.auth-templates.ts carries six auth
templates in four locales each: en-US, zh-CN, ja-JP, es-ES. Six times four is
twenty-four, which is exactly the seeded 24 template row(s) the issue quotes as its
evidence that the rows are missing. That log line is the localized set, not an English one.
The Chinese verification subject already exists and already reads naturally, and
plugin-email/src/auth-templates-locales.test.ts pins both.

2. "sendVerificationEmail does not select by locale" — it has since #8195. All five
auth sends spread a locale into sendTemplate, and plugin-auth/src/auth-email-locale.test.ts
drives every one of them to prove it.

3. "Select by the registration request's locale, or by sys_user.language" — both are
ruled out. The 2026-08-13 maintainer ruling, quoted in auth-manager.ts, makes the
recipient locale the deployment default, rejects Accept-Language (auth mail is routinely
sent outside the triggering request — invitations, admin-initiated resets — so a per-device
header is the wrong authority), and defers a per-user locale column until there is measured
pull. Verified rather than assumed: sys_user.object.ts has no locale and no language
field. Implementing the card as literally written would reverse that ruling, so this PR
does not.

The defect that IS there

"The deployment default" has two producers, and auth email was reading the weaker one.

	source	when it is set	reader
build-time	II18nService.getDefaultLocale()	the app artifact's i18n.defaultLocale, en if undeclared	auth email
runtime	localization.locale (ADR-0053)	Setup, Localization — tenant-scoped, admin-settable	auth SMS (#2815), audit activity summaries (framework#3039)

localization.locale offers exactly four options — en-US, zh-CN, ja-JP, es-ES —
which are exactly AUTH_EMAIL_TEMPLATE_LOCALES. auth-manager.ts even says so: "these are
also the four options the localization.locale setting offers, so the two ends agree by
construction rather than by import." The binding then read the other source anyway.

So a workspace that declared Chinese in Setup received Chinese OTP texts and English
verification mail, from one plugin, on one kernel:ready pass, a dozen lines apart.

The fix

AuthPlugin now prefers localization.locale whenever the operator has explicitly set
it — ResolvedSettingValue.source !== 'default' — which is the same precedence the sibling
branding.workspace_name binding in this file already uses, and for the same reason: get
answers the manifest default (en-US) for an untouched workspace, so taking the value
unconditionally would demote every deployment that declared i18n.defaultLocale down to
en-US. The build-time default stands underneath it. Neither producer answering leaves the
locale unnamed, which is EmailService's documented en-US fallback and the pre-#8195
behaviour. Both channels are now driven from one read, so they can no longer disagree, and
the binding live-rebinds on localization changes exactly as the SMS one does.

The ruling is untouched: the locale is still the deployment default, still resolved at the
plugin layer, Accept-Language still rejected, still no per-user locale.

Answering the dispatch's mechanism question

Template rows carry a locale column, and the platform selects per-locale rows — not
multi-language blocks inside one row. sys_email_template is keyed (name, locale);
createSysEmailTemplateLoader filters on it and pins en-US in the WHERE clause so a driver
that ignores orderBy still answers deterministically (#7731). So the fix belongs entirely
in plugin-auth, at the point that decides which locale to name. No plugin-email file is
touched, and the declared file surface holds.

Tests

New: seven cases in auth-plugin.test.ts, Auth email locale binding (localization.locale).
A zh-CN workspace binds zh-CN on both channels; ja-JP and es-ES likewise; an
untouched workspace keeps the build-time default (the #8195 non-regression); neither producer
speaking names no locale, spelled as an absent key because that is what the ladder's "no
locale means the documented default" contract is written against; no settings service at all
keeps the build-time default; a language switch re-binds live through the subscribe handler;
a failing settings read leaves the build-time default standing and warns.

Reverse verification. With the fix committed at fceba76c0, auth-plugin.ts was restored
to the merge base 5563bfb32 and the suite re-run. Direction: RED, as predicted.
5 of the 7 new cases failed, with the exact expected shape —
expected last "setDefaultEmailLocale" call to have been called with [ 'zh-CN' ] /
Received [ 'en' ] — while the two that do not depend on the settings read stayed green.
Mutation confirmed on disk before the run, by blob hash and by anchor count, not by an editor
exit code: HEAD blob 7826ea6f, mutated blob 8d8137058, applySmsLocale count 3 in the
mutated file and 0 in the fixed one. Restore confirmed after: worktree blob back to
7826ea6f, git diff HEAD empty, git status --porcelain empty. The restore leg ran from a
trap ... EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel.
No rebuild was needed for either leg: both suites import ./auth-plugin as source, so no
dist/ sits between the mutation and the assertion.

Gates — run at 40dc0aff1

Union re-derived after the final commit (dispatch-gates.mjs --repo objectstack-ai/objectstack,
no paths passed, so the script takes its own change set from the merge base).

• pnpm --filter '@objectstack/plugin-auth^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/plugin-auth test — Test Files 90 passed, Tests 1838 passed
• pnpm --filter @objectstack/plugin-auth typecheck — exit 0;
  check:test-typecheck: OK ... 10 file(s) / 94 error(s) / 23 pinned signature(s), ledger unchanged
• node scripts/check-nul-bytes.mjs — OK (scanned 7963 text file(s) ... no raw ASCII control bytes)
• 62 derived families run. The first derivation gave 38; repairing the census below added
  content/docs/** to the diff and the re-derivation returned 62, so the 24 new doc
  families were run too. All green except the four named next.
• pnpm check:type-check-coverage --re-measure — OK — 22 ledger entr(ies) re-measured in 53.8s, 755 raw tsc error(s) total, none above its recorded number
• pnpm check:skill-examples — 262 prose examples type-check across 3 surface(s)
• pnpm check:dual-build-cjs-loads — exit 0, floors held

Three of those needed the workspace closure built first (they refuse rather than answer on an
unbuilt tree, and say so); turbo run build --filter='./packages/*' --filter='./packages/*/*'
ran 70/70 successful, after which all three measured green.

One real gate finding, repaired.check-system-context-census went red on pure line rot:
this PR's edit moved an elevation read in auth-plugin.ts from line 1301 to 1345, orphaning
the anchor on the census page. Repaired with the script's own --fix, which rewrote exactly
one anchor; the gate then reported OK — 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read.

Two families NOT MEASURED locally, by their own verdict text — neither is a red.
check-test-completeness exits 3 asking for a saved turbo run test log, and instructs that
a local family run record it as NOT MEASURED. check-half-states exits 3 as an unread
instrument on this host. Both are CI's to run.

Declared narrowing — verification ran UNLOCKED.scripts/pm/os-verify-lock.sh
could not take the shared verify lock on this host: no usable flock. The shared
verify lock is declared Linux-only (flock is util-linux, and a stock macOS does
not ship it), so the commands above were run directly, without the lock —
a declared narrowing, not a silent one. No serialization guarantee held for these
runs, nor for any sibling agent in this container while they ran.

Repo-wide pnpm lint was not run; it is CI's, and no narrowing of it is claimed here.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/auth-service.mdx(via AuthManager (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via AuthManager (symbol, a top-level class))
• content/docs/permissions/authentication.mdx(via AuthManager (symbol, a top-level class))

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• 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 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c — the merge of head 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 into base 7085f90531e9ab7c9fe07b758287d7dfbe1549b3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c && git checkout ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 && git checkout -B drift-repro 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 && git merge --no-ff 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75
node scripts/docs-audit/affected-docs.mjs --json 7085f90531e9ab7c9fe07b758287d7dfbe1549b3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[hotlong]

Part of #14319

Deliberately Part of and not a closing keyword. This PR lands the half the standing
2026-08-13 ruling permits — the deployment default, resolved from the workspace language
the platform already has. The half the card actually asks for, selecting per registration
request or per user, is barred by that same ruling and belongs to the maintainer, so the
card must stay open for that decision rather than be closed by this merge.

The card's premise did not survive verification against main — two thirds of it

The issue asks for three things. Two already exist on main, and the third is barred
by a standing maintainer ruling. What is left is a real defect of the same class, and
that is what this PR fixes.

1. "Add Chinese templates" — they already ship.auth-templates.ts carries six auth
templates in four locales each: en-US, zh-CN, ja-JP, es-ES. Six times four is
twenty-four, which is exactly the seeded 24 template row(s) the issue quotes as its
evidence that the rows are missing. That log line is the localized set, not an English one.
The Chinese verification subject already exists and already reads naturally, and
plugin-email/src/auth-templates-locales.test.ts pins both.

2. "sendVerificationEmail does not select by locale" — it has since #8195. All five
auth sends spread a locale into sendTemplate, and plugin-auth/src/auth-email-locale.test.ts
drives every one of them to prove it.

3. "Select by the registration request's locale, or by sys_user.language" — both are
ruled out. The 2026-08-13 maintainer ruling, quoted in auth-manager.ts, makes the
recipient locale the deployment default, rejects Accept-Language (auth mail is routinely
sent outside the triggering request — invitations, admin-initiated resets — so a per-device
header is the wrong authority), and defers a per-user locale column until there is measured
pull. Verified rather than assumed: sys_user.object.ts has no locale and no language
field. Implementing the card as literally written would reverse that ruling, so this PR
does not.

The defect that IS there

"The deployment default" has two producers, and auth email was reading the weaker one.

	source	when it is set	reader
build-time	II18nService.getDefaultLocale()	the app artifact's i18n.defaultLocale, en if undeclared	auth email
runtime	localization.locale (ADR-0053)	Setup, Localization — tenant-scoped, admin-settable	auth SMS (#2815), audit activity summaries (framework#3039)

localization.locale offers exactly four options — en-US, zh-CN, ja-JP, es-ES —
which are exactly AUTH_EMAIL_TEMPLATE_LOCALES. auth-manager.ts even says so: "these are
also the four options the localization.locale setting offers, so the two ends agree by
construction rather than by import." The binding then read the other source anyway.

So a workspace that declared Chinese in Setup received Chinese OTP texts and English
verification mail, from one plugin, on one kernel:ready pass, a dozen lines apart.

The fix

AuthPlugin now prefers localization.locale whenever the operator has explicitly set
it — ResolvedSettingValue.source !== 'default' — which is the same precedence the sibling
branding.workspace_name binding in this file already uses, and for the same reason: get
answers the manifest default (en-US) for an untouched workspace, so taking the value
unconditionally would demote every deployment that declared i18n.defaultLocale down to
en-US. The build-time default stands underneath it. Neither producer answering leaves the
locale unnamed, which is EmailService's documented en-US fallback and the pre-#8195
behaviour. Both channels are now driven from one read, so they can no longer disagree, and
the binding live-rebinds on localization changes exactly as the SMS one does.

The ruling is untouched: the locale is still the deployment default, still resolved at the
plugin layer, Accept-Language still rejected, still no per-user locale.

Answering the dispatch's mechanism question

Template rows carry a locale column, and the platform selects per-locale rows — not
multi-language blocks inside one row. sys_email_template is keyed (name, locale);
createSysEmailTemplateLoader filters on it and pins en-US in the WHERE clause so a driver
that ignores orderBy still answers deterministically (#7731). So the fix belongs entirely
in plugin-auth, at the point that decides which locale to name. No plugin-email file is
touched, and the declared file surface holds.

Tests

New: seven cases in auth-plugin.test.ts, Auth email locale binding (localization.locale).
A zh-CN workspace binds zh-CN on both channels; ja-JP and es-ES likewise; an
untouched workspace keeps the build-time default (the #8195 non-regression); neither producer
speaking names no locale, spelled as an absent key because that is what the ladder's "no
locale means the documented default" contract is written against; no settings service at all
keeps the build-time default; a language switch re-binds live through the subscribe handler;
a failing settings read leaves the build-time default standing and warns.

Reverse verification. With the fix committed at fceba76c0, auth-plugin.ts was restored
to the merge base 5563bfb32 and the suite re-run. Direction: RED, as predicted.
5 of the 7 new cases failed, with the exact expected shape —
expected last "setDefaultEmailLocale" call to have been called with [ 'zh-CN' ] /
Received [ 'en' ] — while the two that do not depend on the settings read stayed green.
Mutation confirmed on disk before the run, by blob hash and by anchor count, not by an editor
exit code: HEAD blob 7826ea6f, mutated blob 8d8137058, applySmsLocale count 3 in the
mutated file and 0 in the fixed one. Restore confirmed after: worktree blob back to
7826ea6f, git diff HEAD empty, git status --porcelain empty. The restore leg ran from a
trap ... EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel.
No rebuild was needed for either leg: both suites import ./auth-plugin as source, so no
dist/ sits between the mutation and the assertion.

Gates — run at 40dc0aff1

Union re-derived after the final commit (dispatch-gates.mjs --repo objectstack-ai/objectstack,
no paths passed, so the script takes its own change set from the merge base).

• pnpm --filter '@objectstack/plugin-auth^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/plugin-auth test — Test Files 90 passed, Tests 1838 passed
• pnpm --filter @objectstack/plugin-auth typecheck — exit 0;
  check:test-typecheck: OK ... 10 file(s) / 94 error(s) / 23 pinned signature(s), ledger unchanged
• node scripts/check-nul-bytes.mjs — OK (scanned 7963 text file(s) ... no raw ASCII control bytes)
• 62 derived families run. The first derivation gave 38; repairing the census below added
  content/docs/** to the diff and the re-derivation returned 62, so the 24 new doc
  families were run too. All green except the four named next.
• pnpm check:type-check-coverage --re-measure — OK — 22 ledger entr(ies) re-measured in 53.8s, 755 raw tsc error(s) total, none above its recorded number
• pnpm check:skill-examples — 262 prose examples type-check across 3 surface(s)
• pnpm check:dual-build-cjs-loads — exit 0, floors held

Three of those needed the workspace closure built first (they refuse rather than answer on an
unbuilt tree, and say so); turbo run build --filter='./packages/*' --filter='./packages/*/*'
ran 70/70 successful, after which all three measured green.

One real gate finding, repaired.check-system-context-census went red on pure line rot:
this PR's edit moved an elevation read in auth-plugin.ts from line 1301 to 1345, orphaning
the anchor on the census page. Repaired with the script's own --fix, which rewrote exactly
one anchor; the gate then reported OK — 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read.

Two families NOT MEASURED locally, by their own verdict text — neither is a red.
check-test-completeness exits 3 asking for a saved turbo run test log, and instructs that
a local family run record it as NOT MEASURED. check-half-states exits 3 as an unread
instrument on this host. Both are CI's to run.

Declared narrowing — verification ran UNLOCKED.scripts/pm/os-verify-lock.sh
could not take the shared verify lock on this host: no usable flock. The shared
verify lock is declared Linux-only (flock is util-linux, and a stock macOS does
not ship it), so the commands above were run directly, without the lock —
a declared narrowing, not a silent one. No serialization guarantee held for these
runs, nor for any sibling agent in this container while they ran.

Repo-wide pnpm lint was not run; it is CI's, and no narrowing of it is claimed here.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/auth-service.mdx(via AuthManager (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via AuthManager (symbol, a top-level class))
• content/docs/permissions/authentication.mdx(via AuthManager (symbol, a top-level class))

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• 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 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c — the merge of head 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 into base 7085f90531e9ab7c9fe07b758287d7dfbe1549b3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c && git checkout ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 && git checkout -B drift-repro 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 && git merge --no-ff 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75
node scripts/docs-audit/affected-docs.mjs --json 7085f90531e9ab7c9fe07b758287d7dfbe1549b3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[hotlong]

Part of #14319

Deliberately Part of and not a closing keyword. This PR lands the half the standing
2026-08-13 ruling permits — the deployment default, resolved from the workspace language
the platform already has. The half the card actually asks for, selecting per registration
request or per user, is barred by that same ruling and belongs to the maintainer, so the
card must stay open for that decision rather than be closed by this merge.

The card's premise did not survive verification against main — two thirds of it

The issue asks for three things. Two already exist on main, and the third is barred
by a standing maintainer ruling. What is left is a real defect of the same class, and
that is what this PR fixes.

1. "Add Chinese templates" — they already ship.auth-templates.ts carries six auth
templates in four locales each: en-US, zh-CN, ja-JP, es-ES. Six times four is
twenty-four, which is exactly the seeded 24 template row(s) the issue quotes as its
evidence that the rows are missing. That log line is the localized set, not an English one.
The Chinese verification subject already exists and already reads naturally, and
plugin-email/src/auth-templates-locales.test.ts pins both.

2. "sendVerificationEmail does not select by locale" — it has since #8195. All five
auth sends spread a locale into sendTemplate, and plugin-auth/src/auth-email-locale.test.ts
drives every one of them to prove it.

3. "Select by the registration request's locale, or by sys_user.language" — both are
ruled out. The 2026-08-13 maintainer ruling, quoted in auth-manager.ts, makes the
recipient locale the deployment default, rejects Accept-Language (auth mail is routinely
sent outside the triggering request — invitations, admin-initiated resets — so a per-device
header is the wrong authority), and defers a per-user locale column until there is measured
pull. Verified rather than assumed: sys_user.object.ts has no locale and no language
field. Implementing the card as literally written would reverse that ruling, so this PR
does not.

The defect that IS there

"The deployment default" has two producers, and auth email was reading the weaker one.

	source	when it is set	reader
build-time	II18nService.getDefaultLocale()	the app artifact's i18n.defaultLocale, en if undeclared	auth email
runtime	localization.locale (ADR-0053)	Setup, Localization — tenant-scoped, admin-settable	auth SMS (#2815), audit activity summaries (framework#3039)

localization.locale offers exactly four options — en-US, zh-CN, ja-JP, es-ES —
which are exactly AUTH_EMAIL_TEMPLATE_LOCALES. auth-manager.ts even says so: "these are
also the four options the localization.locale setting offers, so the two ends agree by
construction rather than by import." The binding then read the other source anyway.

So a workspace that declared Chinese in Setup received Chinese OTP texts and English
verification mail, from one plugin, on one kernel:ready pass, a dozen lines apart.

The fix

AuthPlugin now prefers localization.locale whenever the operator has explicitly set
it — ResolvedSettingValue.source !== 'default' — which is the same precedence the sibling
branding.workspace_name binding in this file already uses, and for the same reason: get
answers the manifest default (en-US) for an untouched workspace, so taking the value
unconditionally would demote every deployment that declared i18n.defaultLocale down to
en-US. The build-time default stands underneath it. Neither producer answering leaves the
locale unnamed, which is EmailService's documented en-US fallback and the pre-#8195
behaviour. Both channels are now driven from one read, so they can no longer disagree, and
the binding live-rebinds on localization changes exactly as the SMS one does.

The ruling is untouched: the locale is still the deployment default, still resolved at the
plugin layer, Accept-Language still rejected, still no per-user locale.

Answering the dispatch's mechanism question

Template rows carry a locale column, and the platform selects per-locale rows — not
multi-language blocks inside one row. sys_email_template is keyed (name, locale);
createSysEmailTemplateLoader filters on it and pins en-US in the WHERE clause so a driver
that ignores orderBy still answers deterministically (#7731). So the fix belongs entirely
in plugin-auth, at the point that decides which locale to name. No plugin-email file is
touched, and the declared file surface holds.

Tests

New: seven cases in auth-plugin.test.ts, Auth email locale binding (localization.locale).
A zh-CN workspace binds zh-CN on both channels; ja-JP and es-ES likewise; an
untouched workspace keeps the build-time default (the #8195 non-regression); neither producer
speaking names no locale, spelled as an absent key because that is what the ladder's "no
locale means the documented default" contract is written against; no settings service at all
keeps the build-time default; a language switch re-binds live through the subscribe handler;
a failing settings read leaves the build-time default standing and warns.

Reverse verification. With the fix committed at fceba76c0, auth-plugin.ts was restored
to the merge base 5563bfb32 and the suite re-run. Direction: RED, as predicted.
5 of the 7 new cases failed, with the exact expected shape —
expected last "setDefaultEmailLocale" call to have been called with [ 'zh-CN' ] /
Received [ 'en' ] — while the two that do not depend on the settings read stayed green.
Mutation confirmed on disk before the run, by blob hash and by anchor count, not by an editor
exit code: HEAD blob 7826ea6f, mutated blob 8d8137058, applySmsLocale count 3 in the
mutated file and 0 in the fixed one. Restore confirmed after: worktree blob back to
7826ea6f, git diff HEAD empty, git status --porcelain empty. The restore leg ran from a
trap ... EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel.
No rebuild was needed for either leg: both suites import ./auth-plugin as source, so no
dist/ sits between the mutation and the assertion.

Gates — run at 40dc0aff1

Union re-derived after the final commit (dispatch-gates.mjs --repo objectstack-ai/objectstack,
no paths passed, so the script takes its own change set from the merge base).

• pnpm --filter '@objectstack/plugin-auth^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/plugin-auth test — Test Files 90 passed, Tests 1838 passed
• pnpm --filter @objectstack/plugin-auth typecheck — exit 0;
  check:test-typecheck: OK ... 10 file(s) / 94 error(s) / 23 pinned signature(s), ledger unchanged
• node scripts/check-nul-bytes.mjs — OK (scanned 7963 text file(s) ... no raw ASCII control bytes)
• 62 derived families run. The first derivation gave 38; repairing the census below added
  content/docs/** to the diff and the re-derivation returned 62, so the 24 new doc
  families were run too. All green except the four named next.
• pnpm check:type-check-coverage --re-measure — OK — 22 ledger entr(ies) re-measured in 53.8s, 755 raw tsc error(s) total, none above its recorded number
• pnpm check:skill-examples — 262 prose examples type-check across 3 surface(s)
• pnpm check:dual-build-cjs-loads — exit 0, floors held

Three of those needed the workspace closure built first (they refuse rather than answer on an
unbuilt tree, and say so); turbo run build --filter='./packages/*' --filter='./packages/*/*'
ran 70/70 successful, after which all three measured green.

One real gate finding, repaired.check-system-context-census went red on pure line rot:
this PR's edit moved an elevation read in auth-plugin.ts from line 1301 to 1345, orphaning
the anchor on the census page. Repaired with the script's own --fix, which rewrote exactly
one anchor; the gate then reported OK — 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read.

Two families NOT MEASURED locally, by their own verdict text — neither is a red.
check-test-completeness exits 3 asking for a saved turbo run test log, and instructs that
a local family run record it as NOT MEASURED. check-half-states exits 3 as an unread
instrument on this host. Both are CI's to run.

Declared narrowing — verification ran UNLOCKED.scripts/pm/os-verify-lock.sh
could not take the shared verify lock on this host: no usable flock. The shared
verify lock is declared Linux-only (flock is util-linux, and a stock macOS does
not ship it), so the commands above were run directly, without the lock —
a declared narrowing, not a silent one. No serialization guarantee held for these
runs, nor for any sibling agent in this container while they ran.

Repo-wide pnpm lint was not run; it is CI's, and no narrowing of it is claimed here.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/auth-service.mdx(via AuthManager (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via AuthManager (symbol, a top-level class))
• content/docs/permissions/authentication.mdx(via AuthManager (symbol, a top-level class))

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• 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 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c — the merge of head 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 into base 7085f90531e9ab7c9fe07b758287d7dfbe1549b3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c && git checkout ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 && git checkout -B drift-repro 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 && git merge --no-ff 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75
node scripts/docs-audit/affected-docs.mjs --json 7085f90531e9ab7c9fe07b758287d7dfbe1549b3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[hotlong]

Part of #14319

Deliberately Part of and not a closing keyword. This PR lands the half the standing
2026-08-13 ruling permits — the deployment default, resolved from the workspace language
the platform already has. The half the card actually asks for, selecting per registration
request or per user, is barred by that same ruling and belongs to the maintainer, so the
card must stay open for that decision rather than be closed by this merge.

The card's premise did not survive verification against main — two thirds of it

The issue asks for three things. Two already exist on main, and the third is barred
by a standing maintainer ruling. What is left is a real defect of the same class, and
that is what this PR fixes.

1. "Add Chinese templates" — they already ship.auth-templates.ts carries six auth
templates in four locales each: en-US, zh-CN, ja-JP, es-ES. Six times four is
twenty-four, which is exactly the seeded 24 template row(s) the issue quotes as its
evidence that the rows are missing. That log line is the localized set, not an English one.
The Chinese verification subject already exists and already reads naturally, and
plugin-email/src/auth-templates-locales.test.ts pins both.

2. "sendVerificationEmail does not select by locale" — it has since #8195. All five
auth sends spread a locale into sendTemplate, and plugin-auth/src/auth-email-locale.test.ts
drives every one of them to prove it.

3. "Select by the registration request's locale, or by sys_user.language" — both are
ruled out. The 2026-08-13 maintainer ruling, quoted in auth-manager.ts, makes the
recipient locale the deployment default, rejects Accept-Language (auth mail is routinely
sent outside the triggering request — invitations, admin-initiated resets — so a per-device
header is the wrong authority), and defers a per-user locale column until there is measured
pull. Verified rather than assumed: sys_user.object.ts has no locale and no language
field. Implementing the card as literally written would reverse that ruling, so this PR
does not.

The defect that IS there

"The deployment default" has two producers, and auth email was reading the weaker one.

	source	when it is set	reader
build-time	II18nService.getDefaultLocale()	the app artifact's i18n.defaultLocale, en if undeclared	auth email
runtime	localization.locale (ADR-0053)	Setup, Localization — tenant-scoped, admin-settable	auth SMS (#2815), audit activity summaries (framework#3039)

localization.locale offers exactly four options — en-US, zh-CN, ja-JP, es-ES —
which are exactly AUTH_EMAIL_TEMPLATE_LOCALES. auth-manager.ts even says so: "these are
also the four options the localization.locale setting offers, so the two ends agree by
construction rather than by import." The binding then read the other source anyway.

So a workspace that declared Chinese in Setup received Chinese OTP texts and English
verification mail, from one plugin, on one kernel:ready pass, a dozen lines apart.

The fix

AuthPlugin now prefers localization.locale whenever the operator has explicitly set
it — ResolvedSettingValue.source !== 'default' — which is the same precedence the sibling
branding.workspace_name binding in this file already uses, and for the same reason: get
answers the manifest default (en-US) for an untouched workspace, so taking the value
unconditionally would demote every deployment that declared i18n.defaultLocale down to
en-US. The build-time default stands underneath it. Neither producer answering leaves the
locale unnamed, which is EmailService's documented en-US fallback and the pre-#8195
behaviour. Both channels are now driven from one read, so they can no longer disagree, and
the binding live-rebinds on localization changes exactly as the SMS one does.

The ruling is untouched: the locale is still the deployment default, still resolved at the
plugin layer, Accept-Language still rejected, still no per-user locale.

Answering the dispatch's mechanism question

Template rows carry a locale column, and the platform selects per-locale rows — not
multi-language blocks inside one row. sys_email_template is keyed (name, locale);
createSysEmailTemplateLoader filters on it and pins en-US in the WHERE clause so a driver
that ignores orderBy still answers deterministically (#7731). So the fix belongs entirely
in plugin-auth, at the point that decides which locale to name. No plugin-email file is
touched, and the declared file surface holds.

Tests

New: seven cases in auth-plugin.test.ts, Auth email locale binding (localization.locale).
A zh-CN workspace binds zh-CN on both channels; ja-JP and es-ES likewise; an
untouched workspace keeps the build-time default (the #8195 non-regression); neither producer
speaking names no locale, spelled as an absent key because that is what the ladder's "no
locale means the documented default" contract is written against; no settings service at all
keeps the build-time default; a language switch re-binds live through the subscribe handler;
a failing settings read leaves the build-time default standing and warns.

Reverse verification. With the fix committed at fceba76c0, auth-plugin.ts was restored
to the merge base 5563bfb32 and the suite re-run. Direction: RED, as predicted.
5 of the 7 new cases failed, with the exact expected shape —
expected last "setDefaultEmailLocale" call to have been called with [ 'zh-CN' ] /
Received [ 'en' ] — while the two that do not depend on the settings read stayed green.
Mutation confirmed on disk before the run, by blob hash and by anchor count, not by an editor
exit code: HEAD blob 7826ea6f, mutated blob 8d8137058, applySmsLocale count 3 in the
mutated file and 0 in the fixed one. Restore confirmed after: worktree blob back to
7826ea6f, git diff HEAD empty, git status --porcelain empty. The restore leg ran from a
trap ... EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel.
No rebuild was needed for either leg: both suites import ./auth-plugin as source, so no
dist/ sits between the mutation and the assertion.

Gates — run at 40dc0aff1

Union re-derived after the final commit (dispatch-gates.mjs --repo objectstack-ai/objectstack,
no paths passed, so the script takes its own change set from the merge base).

• pnpm --filter '@objectstack/plugin-auth^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/plugin-auth test — Test Files 90 passed, Tests 1838 passed
• pnpm --filter @objectstack/plugin-auth typecheck — exit 0;
  check:test-typecheck: OK ... 10 file(s) / 94 error(s) / 23 pinned signature(s), ledger unchanged
• node scripts/check-nul-bytes.mjs — OK (scanned 7963 text file(s) ... no raw ASCII control bytes)
• 62 derived families run. The first derivation gave 38; repairing the census below added
  content/docs/** to the diff and the re-derivation returned 62, so the 24 new doc
  families were run too. All green except the four named next.
• pnpm check:type-check-coverage --re-measure — OK — 22 ledger entr(ies) re-measured in 53.8s, 755 raw tsc error(s) total, none above its recorded number
• pnpm check:skill-examples — 262 prose examples type-check across 3 surface(s)
• pnpm check:dual-build-cjs-loads — exit 0, floors held

Three of those needed the workspace closure built first (they refuse rather than answer on an
unbuilt tree, and say so); turbo run build --filter='./packages/*' --filter='./packages/*/*'
ran 70/70 successful, after which all three measured green.

One real gate finding, repaired.check-system-context-census went red on pure line rot:
this PR's edit moved an elevation read in auth-plugin.ts from line 1301 to 1345, orphaning
the anchor on the census page. Repaired with the script's own --fix, which rewrote exactly
one anchor; the gate then reported OK — 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read.

Two families NOT MEASURED locally, by their own verdict text — neither is a red.
check-test-completeness exits 3 asking for a saved turbo run test log, and instructs that
a local family run record it as NOT MEASURED. check-half-states exits 3 as an unread
instrument on this host. Both are CI's to run.

Declared narrowing — verification ran UNLOCKED.scripts/pm/os-verify-lock.sh
could not take the shared verify lock on this host: no usable flock. The shared
verify lock is declared Linux-only (flock is util-linux, and a stock macOS does
not ship it), so the commands above were run directly, without the lock —
a declared narrowing, not a silent one. No serialization guarantee held for these
runs, nor for any sibling agent in this container while they ran.

Repo-wide pnpm lint was not run; it is CI's, and no narrowing of it is claimed here.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/auth-service.mdx(via AuthManager (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via AuthManager (symbol, a top-level class))
• content/docs/permissions/authentication.mdx(via AuthManager (symbol, a top-level class))

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• 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 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c — the merge of head 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 into base 7085f90531e9ab7c9fe07b758287d7dfbe1549b3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c && git checkout ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 && git checkout -B drift-repro 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 && git merge --no-ff 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75
node scripts/docs-audit/affected-docs.mjs --json 7085f90531e9ab7c9fe07b758287d7dfbe1549b3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[hotlong]

Part of #14319

Deliberately Part of and not a closing keyword. This PR lands the half the standing
2026-08-13 ruling permits — the deployment default, resolved from the workspace language
the platform already has. The half the card actually asks for, selecting per registration
request or per user, is barred by that same ruling and belongs to the maintainer, so the
card must stay open for that decision rather than be closed by this merge.

The card's premise did not survive verification against main — two thirds of it

The issue asks for three things. Two already exist on main, and the third is barred
by a standing maintainer ruling. What is left is a real defect of the same class, and
that is what this PR fixes.

1. "Add Chinese templates" — they already ship.auth-templates.ts carries six auth
templates in four locales each: en-US, zh-CN, ja-JP, es-ES. Six times four is
twenty-four, which is exactly the seeded 24 template row(s) the issue quotes as its
evidence that the rows are missing. That log line is the localized set, not an English one.
The Chinese verification subject already exists and already reads naturally, and
plugin-email/src/auth-templates-locales.test.ts pins both.

2. "sendVerificationEmail does not select by locale" — it has since #8195. All five
auth sends spread a locale into sendTemplate, and plugin-auth/src/auth-email-locale.test.ts
drives every one of them to prove it.

3. "Select by the registration request's locale, or by sys_user.language" — both are
ruled out. The 2026-08-13 maintainer ruling, quoted in auth-manager.ts, makes the
recipient locale the deployment default, rejects Accept-Language (auth mail is routinely
sent outside the triggering request — invitations, admin-initiated resets — so a per-device
header is the wrong authority), and defers a per-user locale column until there is measured
pull. Verified rather than assumed: sys_user.object.ts has no locale and no language
field. Implementing the card as literally written would reverse that ruling, so this PR
does not.

The defect that IS there

"The deployment default" has two producers, and auth email was reading the weaker one.

	source	when it is set	reader
build-time	II18nService.getDefaultLocale()	the app artifact's i18n.defaultLocale, en if undeclared	auth email
runtime	localization.locale (ADR-0053)	Setup, Localization — tenant-scoped, admin-settable	auth SMS (#2815), audit activity summaries (framework#3039)

localization.locale offers exactly four options — en-US, zh-CN, ja-JP, es-ES —
which are exactly AUTH_EMAIL_TEMPLATE_LOCALES. auth-manager.ts even says so: "these are
also the four options the localization.locale setting offers, so the two ends agree by
construction rather than by import." The binding then read the other source anyway.

So a workspace that declared Chinese in Setup received Chinese OTP texts and English
verification mail, from one plugin, on one kernel:ready pass, a dozen lines apart.

The fix

AuthPlugin now prefers localization.locale whenever the operator has explicitly set
it — ResolvedSettingValue.source !== 'default' — which is the same precedence the sibling
branding.workspace_name binding in this file already uses, and for the same reason: get
answers the manifest default (en-US) for an untouched workspace, so taking the value
unconditionally would demote every deployment that declared i18n.defaultLocale down to
en-US. The build-time default stands underneath it. Neither producer answering leaves the
locale unnamed, which is EmailService's documented en-US fallback and the pre-#8195
behaviour. Both channels are now driven from one read, so they can no longer disagree, and
the binding live-rebinds on localization changes exactly as the SMS one does.

The ruling is untouched: the locale is still the deployment default, still resolved at the
plugin layer, Accept-Language still rejected, still no per-user locale.

Answering the dispatch's mechanism question

Template rows carry a locale column, and the platform selects per-locale rows — not
multi-language blocks inside one row. sys_email_template is keyed (name, locale);
createSysEmailTemplateLoader filters on it and pins en-US in the WHERE clause so a driver
that ignores orderBy still answers deterministically (#7731). So the fix belongs entirely
in plugin-auth, at the point that decides which locale to name. No plugin-email file is
touched, and the declared file surface holds.

Tests

New: seven cases in auth-plugin.test.ts, Auth email locale binding (localization.locale).
A zh-CN workspace binds zh-CN on both channels; ja-JP and es-ES likewise; an
untouched workspace keeps the build-time default (the #8195 non-regression); neither producer
speaking names no locale, spelled as an absent key because that is what the ladder's "no
locale means the documented default" contract is written against; no settings service at all
keeps the build-time default; a language switch re-binds live through the subscribe handler;
a failing settings read leaves the build-time default standing and warns.

Reverse verification. With the fix committed at fceba76c0, auth-plugin.ts was restored
to the merge base 5563bfb32 and the suite re-run. Direction: RED, as predicted.
5 of the 7 new cases failed, with the exact expected shape —
expected last "setDefaultEmailLocale" call to have been called with [ 'zh-CN' ] /
Received [ 'en' ] — while the two that do not depend on the settings read stayed green.
Mutation confirmed on disk before the run, by blob hash and by anchor count, not by an editor
exit code: HEAD blob 7826ea6f, mutated blob 8d8137058, applySmsLocale count 3 in the
mutated file and 0 in the fixed one. Restore confirmed after: worktree blob back to
7826ea6f, git diff HEAD empty, git status --porcelain empty. The restore leg ran from a
trap ... EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel.
No rebuild was needed for either leg: both suites import ./auth-plugin as source, so no
dist/ sits between the mutation and the assertion.

Gates — run at 40dc0aff1

Union re-derived after the final commit (dispatch-gates.mjs --repo objectstack-ai/objectstack,
no paths passed, so the script takes its own change set from the merge base).

• pnpm --filter '@objectstack/plugin-auth^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/plugin-auth test — Test Files 90 passed, Tests 1838 passed
• pnpm --filter @objectstack/plugin-auth typecheck — exit 0;
  check:test-typecheck: OK ... 10 file(s) / 94 error(s) / 23 pinned signature(s), ledger unchanged
• node scripts/check-nul-bytes.mjs — OK (scanned 7963 text file(s) ... no raw ASCII control bytes)
• 62 derived families run. The first derivation gave 38; repairing the census below added
  content/docs/** to the diff and the re-derivation returned 62, so the 24 new doc
  families were run too. All green except the four named next.
• pnpm check:type-check-coverage --re-measure — OK — 22 ledger entr(ies) re-measured in 53.8s, 755 raw tsc error(s) total, none above its recorded number
• pnpm check:skill-examples — 262 prose examples type-check across 3 surface(s)
• pnpm check:dual-build-cjs-loads — exit 0, floors held

Three of those needed the workspace closure built first (they refuse rather than answer on an
unbuilt tree, and say so); turbo run build --filter='./packages/*' --filter='./packages/*/*'
ran 70/70 successful, after which all three measured green.

One real gate finding, repaired.check-system-context-census went red on pure line rot:
this PR's edit moved an elevation read in auth-plugin.ts from line 1301 to 1345, orphaning
the anchor on the census page. Repaired with the script's own --fix, which rewrote exactly
one anchor; the gate then reported OK — 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read.

Two families NOT MEASURED locally, by their own verdict text — neither is a red.
check-test-completeness exits 3 asking for a saved turbo run test log, and instructs that
a local family run record it as NOT MEASURED. check-half-states exits 3 as an unread
instrument on this host. Both are CI's to run.

Declared narrowing — verification ran UNLOCKED.scripts/pm/os-verify-lock.sh
could not take the shared verify lock on this host: no usable flock. The shared
verify lock is declared Linux-only (flock is util-linux, and a stock macOS does
not ship it), so the commands above were run directly, without the lock —
a declared narrowing, not a silent one. No serialization guarantee held for these
runs, nor for any sibling agent in this container while they ran.

Repo-wide pnpm lint was not run; it is CI's, and no narrowing of it is claimed here.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/auth-service.mdx(via AuthManager (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via AuthManager (symbol, a top-level class))
• content/docs/permissions/authentication.mdx(via AuthManager (symbol, a top-level class))

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• 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 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c — the merge of head 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 into base 7085f90531e9ab7c9fe07b758287d7dfbe1549b3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c && git checkout ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 && git checkout -B drift-repro 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 && git merge --no-ff 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75
node scripts/docs-audit/affected-docs.mjs --json 7085f90531e9ab7c9fe07b758287d7dfbe1549b3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[hotlong]

Part of #14319

Deliberately Part of and not a closing keyword. This PR lands the half the standing
2026-08-13 ruling permits — the deployment default, resolved from the workspace language
the platform already has. The half the card actually asks for, selecting per registration
request or per user, is barred by that same ruling and belongs to the maintainer, so the
card must stay open for that decision rather than be closed by this merge.

The card's premise did not survive verification against main — two thirds of it

The issue asks for three things. Two already exist on main, and the third is barred
by a standing maintainer ruling. What is left is a real defect of the same class, and
that is what this PR fixes.

1. "Add Chinese templates" — they already ship.auth-templates.ts carries six auth
templates in four locales each: en-US, zh-CN, ja-JP, es-ES. Six times four is
twenty-four, which is exactly the seeded 24 template row(s) the issue quotes as its
evidence that the rows are missing. That log line is the localized set, not an English one.
The Chinese verification subject already exists and already reads naturally, and
plugin-email/src/auth-templates-locales.test.ts pins both.

2. "sendVerificationEmail does not select by locale" — it has since #8195. All five
auth sends spread a locale into sendTemplate, and plugin-auth/src/auth-email-locale.test.ts
drives every one of them to prove it.

3. "Select by the registration request's locale, or by sys_user.language" — both are
ruled out. The 2026-08-13 maintainer ruling, quoted in auth-manager.ts, makes the
recipient locale the deployment default, rejects Accept-Language (auth mail is routinely
sent outside the triggering request — invitations, admin-initiated resets — so a per-device
header is the wrong authority), and defers a per-user locale column until there is measured
pull. Verified rather than assumed: sys_user.object.ts has no locale and no language
field. Implementing the card as literally written would reverse that ruling, so this PR
does not.

The defect that IS there

"The deployment default" has two producers, and auth email was reading the weaker one.

	source	when it is set	reader
build-time	II18nService.getDefaultLocale()	the app artifact's i18n.defaultLocale, en if undeclared	auth email
runtime	localization.locale (ADR-0053)	Setup, Localization — tenant-scoped, admin-settable	auth SMS (#2815), audit activity summaries (framework#3039)

localization.locale offers exactly four options — en-US, zh-CN, ja-JP, es-ES —
which are exactly AUTH_EMAIL_TEMPLATE_LOCALES. auth-manager.ts even says so: "these are
also the four options the localization.locale setting offers, so the two ends agree by
construction rather than by import." The binding then read the other source anyway.

So a workspace that declared Chinese in Setup received Chinese OTP texts and English
verification mail, from one plugin, on one kernel:ready pass, a dozen lines apart.

The fix

AuthPlugin now prefers localization.locale whenever the operator has explicitly set
it — ResolvedSettingValue.source !== 'default' — which is the same precedence the sibling
branding.workspace_name binding in this file already uses, and for the same reason: get
answers the manifest default (en-US) for an untouched workspace, so taking the value
unconditionally would demote every deployment that declared i18n.defaultLocale down to
en-US. The build-time default stands underneath it. Neither producer answering leaves the
locale unnamed, which is EmailService's documented en-US fallback and the pre-#8195
behaviour. Both channels are now driven from one read, so they can no longer disagree, and
the binding live-rebinds on localization changes exactly as the SMS one does.

The ruling is untouched: the locale is still the deployment default, still resolved at the
plugin layer, Accept-Language still rejected, still no per-user locale.

Answering the dispatch's mechanism question

Template rows carry a locale column, and the platform selects per-locale rows — not
multi-language blocks inside one row. sys_email_template is keyed (name, locale);
createSysEmailTemplateLoader filters on it and pins en-US in the WHERE clause so a driver
that ignores orderBy still answers deterministically (#7731). So the fix belongs entirely
in plugin-auth, at the point that decides which locale to name. No plugin-email file is
touched, and the declared file surface holds.

Tests

New: seven cases in auth-plugin.test.ts, Auth email locale binding (localization.locale).
A zh-CN workspace binds zh-CN on both channels; ja-JP and es-ES likewise; an
untouched workspace keeps the build-time default (the #8195 non-regression); neither producer
speaking names no locale, spelled as an absent key because that is what the ladder's "no
locale means the documented default" contract is written against; no settings service at all
keeps the build-time default; a language switch re-binds live through the subscribe handler;
a failing settings read leaves the build-time default standing and warns.

Reverse verification. With the fix committed at fceba76c0, auth-plugin.ts was restored
to the merge base 5563bfb32 and the suite re-run. Direction: RED, as predicted.
5 of the 7 new cases failed, with the exact expected shape —
expected last "setDefaultEmailLocale" call to have been called with [ 'zh-CN' ] /
Received [ 'en' ] — while the two that do not depend on the settings read stayed green.
Mutation confirmed on disk before the run, by blob hash and by anchor count, not by an editor
exit code: HEAD blob 7826ea6f, mutated blob 8d8137058, applySmsLocale count 3 in the
mutated file and 0 in the fixed one. Restore confirmed after: worktree blob back to
7826ea6f, git diff HEAD empty, git status --porcelain empty. The restore leg ran from a
trap ... EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel.
No rebuild was needed for either leg: both suites import ./auth-plugin as source, so no
dist/ sits between the mutation and the assertion.

Gates — run at 40dc0aff1

Union re-derived after the final commit (dispatch-gates.mjs --repo objectstack-ai/objectstack,
no paths passed, so the script takes its own change set from the merge base).

• pnpm --filter '@objectstack/plugin-auth^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/plugin-auth test — Test Files 90 passed, Tests 1838 passed
• pnpm --filter @objectstack/plugin-auth typecheck — exit 0;
  check:test-typecheck: OK ... 10 file(s) / 94 error(s) / 23 pinned signature(s), ledger unchanged
• node scripts/check-nul-bytes.mjs — OK (scanned 7963 text file(s) ... no raw ASCII control bytes)
• 62 derived families run. The first derivation gave 38; repairing the census below added
  content/docs/** to the diff and the re-derivation returned 62, so the 24 new doc
  families were run too. All green except the four named next.
• pnpm check:type-check-coverage --re-measure — OK — 22 ledger entr(ies) re-measured in 53.8s, 755 raw tsc error(s) total, none above its recorded number
• pnpm check:skill-examples — 262 prose examples type-check across 3 surface(s)
• pnpm check:dual-build-cjs-loads — exit 0, floors held

Three of those needed the workspace closure built first (they refuse rather than answer on an
unbuilt tree, and say so); turbo run build --filter='./packages/*' --filter='./packages/*/*'
ran 70/70 successful, after which all three measured green.

One real gate finding, repaired.check-system-context-census went red on pure line rot:
this PR's edit moved an elevation read in auth-plugin.ts from line 1301 to 1345, orphaning
the anchor on the census page. Repaired with the script's own --fix, which rewrote exactly
one anchor; the gate then reported OK — 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read.

Two families NOT MEASURED locally, by their own verdict text — neither is a red.
check-test-completeness exits 3 asking for a saved turbo run test log, and instructs that
a local family run record it as NOT MEASURED. check-half-states exits 3 as an unread
instrument on this host. Both are CI's to run.

Declared narrowing — verification ran UNLOCKED.scripts/pm/os-verify-lock.sh
could not take the shared verify lock on this host: no usable flock. The shared
verify lock is declared Linux-only (flock is util-linux, and a stock macOS does
not ship it), so the commands above were run directly, without the lock —
a declared narrowing, not a silent one. No serialization guarantee held for these
runs, nor for any sibling agent in this container while they ran.

Repo-wide pnpm lint was not run; it is CI's, and no narrowing of it is claimed here.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/auth-service.mdx(via AuthManager (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via AuthManager (symbol, a top-level class))
• content/docs/permissions/authentication.mdx(via AuthManager (symbol, a top-level class))

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• 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 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c — the merge of head 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 into base 7085f90531e9ab7c9fe07b758287d7dfbe1549b3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c && git checkout ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 && git checkout -B drift-repro 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 && git merge --no-ff 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75
node scripts/docs-audit/affected-docs.mjs --json 7085f90531e9ab7c9fe07b758287d7dfbe1549b3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → pass the list as
args.docs, on the commit named under Which tree this was computed on.

[hotlong]

Part of #14319

Deliberately Part of and not a closing keyword. This PR lands the half the standing
2026-08-13 ruling permits — the deployment default, resolved from the workspace language
the platform already has. The half the card actually asks for, selecting per registration
request or per user, is barred by that same ruling and belongs to the maintainer, so the
card must stay open for that decision rather than be closed by this merge.

The card's premise did not survive verification against main — two thirds of it

The issue asks for three things. Two already exist on main, and the third is barred
by a standing maintainer ruling. What is left is a real defect of the same class, and
that is what this PR fixes.

1. "Add Chinese templates" — they already ship.auth-templates.ts carries six auth
templates in four locales each: en-US, zh-CN, ja-JP, es-ES. Six times four is
twenty-four, which is exactly the seeded 24 template row(s) the issue quotes as its
evidence that the rows are missing. That log line is the localized set, not an English one.
The Chinese verification subject already exists and already reads naturally, and
plugin-email/src/auth-templates-locales.test.ts pins both.

2. "sendVerificationEmail does not select by locale" — it has since #8195. All five
auth sends spread a locale into sendTemplate, and plugin-auth/src/auth-email-locale.test.ts
drives every one of them to prove it.

3. "Select by the registration request's locale, or by sys_user.language" — both are
ruled out. The 2026-08-13 maintainer ruling, quoted in auth-manager.ts, makes the
recipient locale the deployment default, rejects Accept-Language (auth mail is routinely
sent outside the triggering request — invitations, admin-initiated resets — so a per-device
header is the wrong authority), and defers a per-user locale column until there is measured
pull. Verified rather than assumed: sys_user.object.ts has no locale and no language
field. Implementing the card as literally written would reverse that ruling, so this PR
does not.

The defect that IS there

"The deployment default" has two producers, and auth email was reading the weaker one.

	source	when it is set	reader
build-time	II18nService.getDefaultLocale()	the app artifact's i18n.defaultLocale, en if undeclared	auth email
runtime	localization.locale (ADR-0053)	Setup, Localization — tenant-scoped, admin-settable	auth SMS (#2815), audit activity summaries (framework#3039)

localization.locale offers exactly four options — en-US, zh-CN, ja-JP, es-ES —
which are exactly AUTH_EMAIL_TEMPLATE_LOCALES. auth-manager.ts even says so: "these are
also the four options the localization.locale setting offers, so the two ends agree by
construction rather than by import." The binding then read the other source anyway.

So a workspace that declared Chinese in Setup received Chinese OTP texts and English
verification mail, from one plugin, on one kernel:ready pass, a dozen lines apart.

The fix

AuthPlugin now prefers localization.locale whenever the operator has explicitly set
it — ResolvedSettingValue.source !== 'default' — which is the same precedence the sibling
branding.workspace_name binding in this file already uses, and for the same reason: get
answers the manifest default (en-US) for an untouched workspace, so taking the value
unconditionally would demote every deployment that declared i18n.defaultLocale down to
en-US. The build-time default stands underneath it. Neither producer answering leaves the
locale unnamed, which is EmailService's documented en-US fallback and the pre-#8195
behaviour. Both channels are now driven from one read, so they can no longer disagree, and
the binding live-rebinds on localization changes exactly as the SMS one does.

The ruling is untouched: the locale is still the deployment default, still resolved at the
plugin layer, Accept-Language still rejected, still no per-user locale.

Answering the dispatch's mechanism question

Template rows carry a locale column, and the platform selects per-locale rows — not
multi-language blocks inside one row. sys_email_template is keyed (name, locale);
createSysEmailTemplateLoader filters on it and pins en-US in the WHERE clause so a driver
that ignores orderBy still answers deterministically (#7731). So the fix belongs entirely
in plugin-auth, at the point that decides which locale to name. No plugin-email file is
touched, and the declared file surface holds.

Tests

New: seven cases in auth-plugin.test.ts, Auth email locale binding (localization.locale).
A zh-CN workspace binds zh-CN on both channels; ja-JP and es-ES likewise; an
untouched workspace keeps the build-time default (the #8195 non-regression); neither producer
speaking names no locale, spelled as an absent key because that is what the ladder's "no
locale means the documented default" contract is written against; no settings service at all
keeps the build-time default; a language switch re-binds live through the subscribe handler;
a failing settings read leaves the build-time default standing and warns.

Reverse verification. With the fix committed at fceba76c0, auth-plugin.ts was restored
to the merge base 5563bfb32 and the suite re-run. Direction: RED, as predicted.
5 of the 7 new cases failed, with the exact expected shape —
expected last "setDefaultEmailLocale" call to have been called with [ 'zh-CN' ] /
Received [ 'en' ] — while the two that do not depend on the settings read stayed green.
Mutation confirmed on disk before the run, by blob hash and by anchor count, not by an editor
exit code: HEAD blob 7826ea6f, mutated blob 8d8137058, applySmsLocale count 3 in the
mutated file and 0 in the fixed one. Restore confirmed after: worktree blob back to
7826ea6f, git diff HEAD empty, git status --porcelain empty. The restore leg ran from a
trap ... EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel.
No rebuild was needed for either leg: both suites import ./auth-plugin as source, so no
dist/ sits between the mutation and the assertion.

Gates — run at 40dc0aff1

Union re-derived after the final commit (dispatch-gates.mjs --repo objectstack-ai/objectstack,
no paths passed, so the script takes its own change set from the merge base).

• pnpm --filter '@objectstack/plugin-auth^...' build — VERDICT command-exit 0
• pnpm --filter @objectstack/plugin-auth test — Test Files 90 passed, Tests 1838 passed
• pnpm --filter @objectstack/plugin-auth typecheck — exit 0;
  check:test-typecheck: OK ... 10 file(s) / 94 error(s) / 23 pinned signature(s), ledger unchanged
• node scripts/check-nul-bytes.mjs — OK (scanned 7963 text file(s) ... no raw ASCII control bytes)
• 62 derived families run. The first derivation gave 38; repairing the census below added
  content/docs/** to the diff and the re-derivation returned 62, so the 24 new doc
  families were run too. All green except the four named next.
• pnpm check:type-check-coverage --re-measure — OK — 22 ledger entr(ies) re-measured in 53.8s, 755 raw tsc error(s) total, none above its recorded number
• pnpm check:skill-examples — 262 prose examples type-check across 3 surface(s)
• pnpm check:dual-build-cjs-loads — exit 0, floors held

Three of those needed the workspace closure built first (they refuse rather than answer on an
unbuilt tree, and say so); turbo run build --filter='./packages/*' --filter='./packages/*/*'
ran 70/70 successful, after which all three measured green.

One real gate finding, repaired.check-system-context-census went red on pure line rot:
this PR's edit moved an elevation read in auth-plugin.ts from line 1301 to 1345, orphaning
the anchor on the census page. Repaired with the script's own --fix, which rewrote exactly
one anchor; the gate then reported OK — 109 elevation read sites in 20 packages across 45 files, all anchored; 145 anchors resolve, 27 declared non-read.

Two families NOT MEASURED locally, by their own verdict text — neither is a red.
check-test-completeness exits 3 asking for a saved turbo run test log, and instructs that
a local family run record it as NOT MEASURED. check-half-states exits 3 as an unread
instrument on this host. Both are CI's to run.

Declared narrowing — verification ran UNLOCKED.scripts/pm/os-verify-lock.sh
could not take the shared verify lock on this host: no usable flock. The shared
verify lock is declared Linux-only (flock is util-linux, and a stock macOS does
not ship it), so the commands above were run directly, without the lock —
a declared narrowing, not a silent one. No serialization guarantee held for these
runs, nor for any sibling agent in this container while they ran.

Repo-wide pnpm lint was not run; it is CI's, and no narrowing of it is claimed here.

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-auth, touching 1 documentable anchor(s).

3 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/kernel/contracts/auth-service.mdx(via AuthManager (symbol, a top-level class))
• content/docs/kernel/services-checklist.mdx(via AuthManager (symbol, a top-level class))
• content/docs/permissions/authentication.mdx(via AuthManager (symbol, a top-level class))

What this run could not see

• 1 name(s) were too generic to anchor anything (single lowercase words)
• 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 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c — the merge of head 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 into base 7085f90531e9ab7c9fe07b758287d7dfbe1549b3, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c && git checkout ba5c4fc4dae534783bd9f3df1a5a2fcd9d777c5c
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75 && git checkout -B drift-repro 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 && git merge --no-ff 40dc0aff1fa4fb1916b286013d8f2f0c9f4dfc75
node scripts/docs-audit/affected-docs.mjs --json 7085f90531e9ab7c9fe07b758287d7dfbe1549b3

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 7085f90531e9ab7c9fe07b758287d7dfbe1549b3 → pass the list as
args.docs, on the commit named under Which tree this was computed on.