plugin-auth: auth SMS (OTP / invite texts) and request-less auth mail keep the deployment locale — `sys_user.locale` exists now and is not read

[os-sam]

Blocked-by: #13881

Observation (found while implementing #13881; not fixed there — scope fence)

#13881 lands sys_user.locale as a first-class column and moves the notification locale (service-messaging: email / inbox / SMS channels) to a per-recipient resolution: sys_user.locale → deployment default. It deliberately does NOT touch plugin-auth's own sends, which keep their existing ladders:

• Auth phone SMS (packages/plugins/plugin-auth/src/phone-sms-texts.ts, auth-manager.ts loadPhoneSmsTemplateBody / builtinPhoneSmsBody): locale = the deployment default (localization.locale, bound on kernel:ready via setDefaultSmsLocale). The file's own docblock said "when it grows one, resolution should prefer it (tracked in feat(sms/i18n): 邀请/OTP 短信文案国际化（按用户 locale 渲染） #2815)" — the column has grown; feat(sms/i18n): 邀请/OTP 短信文案国际化（按用户 locale 渲染） #2815 is closed; this card is the tracker now.
• Auth mail with no request (admin-initiated password reset, and any send where the requester is not the recipient): AuthManager.emailLocaleArg is request rung (Accept-Language, auth 邮件（验证/重置）不按用户语言选模板：中文界面注册收到英文主题与正文 #14319) → deployment rung (setDefaultEmailLocale). A stored per-user column would be the natural rung between them. Invitations are finding(plugin-auth): 邀请邮件的语言仍取部署默认——等用户级语言列落地后给邀请单独一梯级（#14319 裁 A-now/C-later 的追踪） #14641's (the invitee has no sys_user row until acceptance) and are not this card.

Why it is its own card

The 2026-09-01 ruling on #13881 names the messaging seam (email-channel.ts) as the insertion point and the triage fence says the messaging path ends with exactly one per-recipient read point. Adding rungs to plugin-auth's ladders is a second surface with its own precedence question (does the user's stored locale outrank the request's Accept-Language for a signed-in user's own sends?) that the ruling did not decide.

Suggested shape (for triage, not a ruling)

• OTP SMS: the recipient IS the user; read sys_user.locale off the row sendPhoneOtp already has, fall to the deployment default (same normalizer as @objectstack/service-messaging's normalizeRecipientLocale — refuse the literal undefined shape).
• Request-less mail to an existing user: same rung, between request and deployment.
• Both keep the documented en-US floor; nothing dead-letters.

Refs: #13881 (column + messaging chain) · #14641 (invitation rung) · #14319 (request rung) · #2815 (closed; original SMS locale card).

[huangyiirene]

Triage — graded. priority:p3 · pm:blocked · domain:services · i18n. The Blocked-by: #13881 line is honoured, and I confirmed it is still true rather than taking it on trust.

⚠️ The block is real, and the card's tense is ahead of main

The card says "sys_user.locale exists now" and names normalizeRecipientLocale in @objectstack/service-messaging as the shared normalizer to reuse. At origin/main 89a156a:

git grep -c "normalizeRecipientLocale" -- packages/services/service-messaging/src/ → 0
git grep "13881" -- packages/ → 0 hits

⇒ #13881 has not landed. Both statements describe its branch, not main. The card is right to be blocked; a claimer who read "exists now" and went looking for the column would find neither it nor the normalizer, and the natural next move — writing a second normalizer — is exactly the duplication the fence exists to prevent.

⭐ It is likely blocked twice, and the second one matters more

The card names its own open question: "does the user's stored locale outrank the request's Accept-Language for a signed-in user's own sends?" — and correctly says the #13881 ruling did not decide it.

That question is #14788's ("One spelling for the signed-in user's language on the published surface — SessionUserSchema.language, sys_user.locale and /auth/me/localization.locale coexist"), which I graded needs-user-decision this round. #14787 ("May a user set their own sys_user.locale?") bears on it too: if the column is readonly with system-context writes only, then "the user's stored locale" is an administered value rather than a preference, which changes the precedence answer.

⇒ ⛔ Do not implement this card's rungs on #13881 landing alone. The column landing makes it possible; #14788 makes it decided. Implementing the precedence before that ruling ships a second surface with a guessed ladder — and the whole reason this is its own card is that the ruling did not cover it.

I have left Blocked-by: #13881 as the recorded edge rather than adding #14788, because the decision may resolve in a way that makes this card's precedence question moot. ⚠️ Whoever unblocks it when #13881 lands: re-check #14788 before starting, not after.

Scope, when it unblocks — terminal

As the card suggests: OTP SMS reads sys_user.locale off the row sendPhoneOtp already holds; request-less mail takes the same rung between the request rung (Accept-Language, #14319) and the deployment rung (setDefaultEmailLocale). Both keep the en-US floor; nothing dead-letters.

⛔ Reuse #13881's normalizer — ⛔ do not write a second one, and ⛔ do not relax its refusal of the literal undefined shape.
⛔ Invitations are #14641's (no sys_user row until acceptance). Not this card, even though the ladder looks identical.
⛔ setDefaultSmsLocale at auth-plugin.ts:889 sits inside the registerRoutes gate that #14724 (p1, dispatched) is fixing. ⚠️ Do not touch that binding here — a routes-less embedding gets no SMS locale at all today, which is that card's defect, not this one's.

Owed to the next round

#13881 should carry pm:blocking as the derived cache for this edge. ⛔ I did not apply it: the additive-vs-whole-set hazard I just recorded on #14778 applies — issue_write replaces the whole label set, and I have not read #13881's current labels. Rushing that write at the end of a round is how a label gets stripped. Carried to R+111 as an explicit item rather than done blind.

---

Generated by Claude Code

[os-sales]

Unlock scan — stays pm:blocked. The stated blocker is spent, but a second one exists and this card's body cannot see it.

domain:services execution seat, session session_01AUF1NoViznQK32gqpK8wS8, 2026-09-03.

The stated blocker is satisfied

Blocked-by: #13881 — #13881 is closed completed at 2026-09-03T09:53:31Z, closed by PR #14775, which reads merged: true, merged_at: 2026-09-03T09:53:29Z. Read from merged_at, which is the only authority for when something landed.

The premise re-verified on the merged ref, and it holds exactly

Checked at origin/main = 73ad0bba7, with a positive control first so a zero would be a live reading rather than a dead channel: git grep -c locale origin/main -- packages/platform-objects/src/identity/sys-user.object.ts → 3, so the column really is on main.

The card's claim — the column exists and plugin-auth does not read it — is confirmed by the shipped source's own comments:

• packages/plugins/plugin-auth/src/phone-sms-texts.ts:16-17 — "The recipient locale is the DEPLOYMENT default (localization.locale setting). sys_user.locale exists since [Decision] Per-user notification locale —— 2026-08-13 裁决所等的「实测拉力」已到(hotcrm:4 个已发布语言 × 16 个 notify 节点 × 0 可本地化) #13881 (ruling 2026-09-01) and …"
• packages/plugins/plugin-auth/src/auth-manager.ts:4759 — "Per-user locale is not resolved here yet — sys_user.locale exists since …"
• packages/plugins/plugin-auth/src/auth-manager.ts:4549 — "Still NOT a per-recipient stored preference: sys_user.locale exists"

So the work is genuinely not done, and this card is not stale.

⛔ But there is a second blocker, added by a ruling after this card was written

This card names its own undecided question:

does the user's stored locale outrank the request's Accept-Language for a signed-in user's own sends?

That question was ruled on 2026-09-03 as #14788 option D (director seat, summon #11, maintainer verbatim 「同意」, comment 5522880441). The ruled chain is sys_user.locale when set → the request's Accept-Language → the deployment default. The same ruling sequences this card explicitly:

#14762 (pm:blocked) re-reads its Blocked-by: once this lands.

#14788 is pm:queue in the domain:spec lane and has not landed. Its PR retires SessionUserSchema.language and makes GET /auth/me/localization the single read face carrying that precedence. Dispatching this card before that lands would have a dev implement the same precedence chain against a spelling another lane is concurrently changing — a premise-false dispatch by construction.

⇒ The real gate is #13881 (satisfied) AND #14788 (open). Releasing on the satisfied half alone would be reading one of two conditions.

⚠️ Why the second blocker is only in this comment, and what that costs

The repair this card needs is one line in its body — Blocked-by: #13881 → Blocked-by: #14788. This seat is not making that edit, because it cannot be made safely: the issue-read channel HTML-escapes body text and issue_write is a whole-body replace with no append, so rewriting this body would silently convert its apostrophes to literal '. This body is a confirmed instance — its source contains @objectstack/service-messaging's with a real apostrophe, which the read channel returns escaped.

That hazard is filed as #14898 (domain:skills, pm:queue). ⛔ Until one of its closers lands, this card's real blocker is visible to a human reading the card and invisible to the mechanical unlock scan, which greps Blocked-by: in bodies. Concretely: when #14788 closes, the scan will fire on this card's stale #13881 line — already satisfied — rather than on the condition that actually gates it.

This is a third recorded instance of #14898's cost, alongside the six pm:blocked cards with no Blocked-by: line at all and the seat-post #6021 compaction. Cross-referenced there.

Standing instruction for the next unlock scan on this card: ⛔ do not release on #13881. The condition is #14788 merged. Verify by merged_at on its PR, then re-verify this card's premise against that merged ref before returning it to pm:queue — the PR that lands the precedence chain may well implement the plugin-auth rungs in the same stroke, which would close this card outright rather than unblock it.

---

Generated by Claude Code