fix(plugin-hono-server): resolve the /auth/me/localization regional defaults instead of answering null

The handler read `currency` / `timezone` off the request ExecutionContext,
citing ADR-0053 — but `makeExecutionContextResolver`, the resolver that serves
this surface, is a hand-rolled envelope that assigns neither. Both were
therefore `undefined` on every request and the `?? null` answered `null` to
every authenticated caller, whatever the `localization` settings said.

All three values now come from ONE reading of `resolveLocalizationContext`,
the same cascade the dispatcher's shared assembler fills `execCtx` from, so
the two faces agree by construction rather than by comment. `locale` keeps its
three #14788 rungs and its answers are unchanged; what changed underneath is
that the cascade is read even when rung 1 or 2 wins, because the other two
values need it whichever rung answers the language. The identity read and the
settings read are independent and now run concurrently — the console races
this endpoint against a 500 ms budget on a first visit.

The #14788 pin asserted `timezone: null` as the contract; it was pinning the
defect, and it now asserts the corrected one. `currency: null` in that fixture
is UNCHANGED and still correct: the cascade gives `timezone` a floor (`UTC`)
and `currency` none. The platform checklist's "nulls legal" clause is
rewritten to that asymmetry.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

Author: claude

.changeset/great-clouds-repair.md

@@ -0,0 +1,7 @@
+---
+'@objectstack/plugin-hono-server': patch
+---
+
+`GET /auth/me/localization` answers the deployment's resolved `currency` and `timezone` instead of `null`
+
+The handler read both off the request `ExecutionContext`, citing ADR-0053, but the resolver serving this surface is a hand-rolled envelope that never carried them — so every authenticated caller was answered `currency: null, timezone: null` whatever the `localization` settings said, and the console's regional-formatting seed was fed nulls. All three values now come from one reading of the same `resolveLocalizationContext` cascade the dispatcher's shared assembler uses. `locale` resolution is unchanged. `timezone` now always answers (cascade floor `UTC`); `currency` still answers `null` when the deployment configures none — that value has no floor.

docs/qa/platform-checklist/areas/access-security.json

@@ -2572,9 +2572,9 @@
           "evidence": "the probe trace"
         },
         {
-          "clause": "localization rides the ExecutionContext without a setup gate: an ordinary member's /auth/me/localization answers 200 with currency/locale/timezone keys (nulls legal) — the SETTINGS surface is setup-gated, the resolved defaults deliberately are not",
+          "clause": "localization is RESOLVED without a setup gate: an ordinary member's /auth/me/localization answers 200 with currency/locale/timezone keys carrying the deployment cascade's own answers — the SETTINGS surface is setup-gated, the resolved defaults deliberately are not. \"Nulls legal\" no longer holds for all three (#15387, which repaired a resolver that carried none of them and made the endpoint answer null for currency AND timezone to every authenticated caller): locale and timezone ALWAYS answer, on cascade floors en-US / UTC, so a null for either is a FAIL and a regression of that repair. currency is the one key with no floor — null there is legal, and only when the deployment configures no localization.currency",
           "oracle": "api",
-          "verify": "member trace carries authenticated:true plus the three keys",
+          "verify": "member trace carries authenticated:true plus the three keys, with timezone and locale non-null; configure localization.currency and localization.timezone and re-trace — both must move to the configured values (an unmoved trace is the #15387 defect, not a pass)",
           "evidence": "the trace"
         }
       ],

packages/plugins/plugin-hono-server/src/current-user-endpoints-localization.test.ts

@@ -20,13 +20,30 @@
 // served" clause; the narrowed-rule case is the "no second parser" clause
 // (the answer moves with the registry's rule, not with a built-in regex).
 //
-// Before this card the resolver behind these endpoints assembled NO
-// localization at all — `execCtx.locale` here was always `undefined` and the
-// endpoint answered `locale: null` for every authenticated caller — so the
-// rung-3 cases are also the first pins that this surface answers a language
-// at all. `currency` / `timezone` are deliberately untouched by the ruling and
-// still come off that resolver (i.e. `null` in these fixtures); the response
-// SHAPE objectui reads is pinned unchanged.
+// Before #14788 the resolver behind these endpoints assembled NO localization
+// at all — `execCtx.locale` here was always `undefined` and the endpoint
+// answered `locale: null` for every authenticated caller — so the rung-3 cases
+// are also the first pins that this surface answers a language at all.
+//
+// #15387 — WHAT THIS FILE PINS CHANGED, deliberately and not silently.
+// `currency` / `timezone` were out of #14788's scope and kept coming off that
+// same resolver, so the rung-1 case below asserted `timezone: null` as the
+// contract. It was pinning the DEFECT: the endpoint answered null for both to
+// every authenticated caller whatever the deployment configured. The
+// assertion is now the corrected contract, and the `#15387` block at the foot
+// of this file is what makes the two values falsifiable rather than merely
+// present:
+//
+//   * `timezone` — the deployment cascade's answer, floor `UTC`. An
+//     authenticated caller can no longer be answered `null` for it, which is
+//     why the rung-1 fixture (which configures no time zone) now reads `UTC`.
+//   * `currency` — the deployment cascade's answer, and the one value with NO
+//     floor. `null` there is still legal and still correct for a deployment
+//     that configures no currency, so the rung-1 expectation for it is
+//     UNCHANGED. Keeping that asymmetry visible is the point: the two keys do
+//     not have the same nullability contract.
+//
+// The response SHAPE objectui reads is unchanged — same four keys.
 
 import { describe, it, expect } from 'vitest';
 import { Hono } from 'hono';
@@ -144,7 +161,9 @@ describe('/auth/me/localization — the signed-in user\'s language, three rungs
         const { status, body } = await get('ja-JP,ja;q=0.9,en;q=0.8');
         expect(status).toBe(200);
         // The SHAPE objectui reads (`json?.locale`, plus `currency`) — unchanged.
-        expect(body).toEqual({ authenticated: true, currency: null, locale: 'zh-CN', timezone: null });
+        // `timezone: 'UTC'` is the cascade floor for a fixture that configures
+        // no time zone (#15387); `currency: null` is the no-floor value.
+        expect(body).toEqual({ authenticated: true, currency: null, locale: 'zh-CN', timezone: 'UTC' });
         // The identity row is read under a SYSTEM context by the caller's own
         // id (the `tryFind` shape core uses for the same row) — never routed
         // through the caller's own RLS wall.

packages/plugins/plugin-hono-server/src/current-user-endpoints.ts

@@ -716,7 +716,7 @@ async function storedSignedInUserLocale(
     return rules.every((re) => re.test(value)) ? value : undefined;
 }
 
-/** Input of {@link resolveSignedInUserLocale}. */
+/** Input of {@link resolveCurrentUserLocalization} and {@link resolveSignedInUserLocale}. */
 export interface ResolveSignedInUserLocaleInput {
     /** The locator of the kernel that OWNS the request (see `withRequestContext`). */
     ctx: CurrentUserEndpointsContext;
@@ -728,9 +728,28 @@ export interface ResolveSignedInUserLocaleInput {
     acceptLanguage?: string | null;
 }
 
+/** Everything `/auth/me/localization` answers a signed-in caller. */
+interface CurrentUserLocalization {
+    /**
+     * The reference currency, or `undefined` when the deployment configures
+     * none. The ONE value here with no floor, deliberately: a deployment that
+     * has stated no currency has none, and inventing one would be a WRONG
+     * answer where `undefined` is merely a missing one (the renderer's
+     * documented degradation is a plain number).
+     */
+    currency?: string;
+    /** The signed-in user's language. Always a string — rung 3 has a floor. */
+    locale: string;
+    /** The reference time zone. Always a string — the cascade's floor is `UTC`. */
+    timezone: string;
+}
+
 /**
- * The signed-in user's language — the ONE read face (#14788, maintainer
- * ruling 2026-09-03, option D):
+ * The endpoint's whole answer, resolved from ONE reading of the deployment
+ * cascade (#15387).
+ *
+ * `locale` keeps the three rungs of #14788 (maintainer ruling 2026-09-03,
+ * option D):
  *
  *   1. `sys_user.locale` when set and shaped like the column's own rule says
  *      ({@link storedSignedInUserLocale});
@@ -742,24 +761,62 @@ export interface ResolveSignedInUserLocaleInput {
  *      `execCtx.locale` already derives from on the dispatcher
  *      (`localization.locale` settings → tenant `sys_setting` rows → `en-US`).
  *
- * Always answers a string for an authenticated caller: rung 3 has a floor.
- * Exported for the serverless host path that composes the resolver directly
- * (cloud#924) and for the pin that asserts the precedence.
+ * `currency` and `timezone` come off that same cascade reading, which is the
+ * repair #15387 names: they used to be read off the request
+ * `ExecutionContext`, and the resolver serving THIS surface
+ * ({@link makeExecutionContextResolver}) is a hand-rolled envelope that never
+ * carried them — so the endpoint answered `null` for both to every
+ * authenticated caller, whatever the `localization` settings said. The
+ * dispatcher's shared assembler fills them from this very function
+ * (`core/security/assemble-execution-context.ts` ⇒ `resolveLocalizationContext`),
+ * so reading the cascade here makes the two faces agree by construction
+ * instead of by comment.
+ *
+ * ONE reading, not two: rungs 1–2 no longer short-circuit it, because
+ * `currency` / `timezone` are needed whichever rung answers the language. That
+ * is one `sys_setting` read added to the requests where the caller's own
+ * column or header already decided the locale, and it replaces the second
+ * reading the obvious alternative (resolve again for the other two values)
+ * would have cost on every request. The two reads it does issue are
+ * INDEPENDENT — the caller's identity row and the deployment's settings — and
+ * run concurrently: the console races this endpoint against a 500 ms budget on
+ * a device's first visit (objectui `seedTenantLanguage`), so a needless serial
+ * round-trip here is a language flash there. Neither read throws by its own
+ * documented contract, which is what makes the concurrent form safe.
  */
-export async function resolveSignedInUserLocale(input: ResolveSignedInUserLocaleInput): Promise<string> {
+async function resolveCurrentUserLocalization(
+    input: ResolveSignedInUserLocaleInput,
+): Promise<CurrentUserLocalization> {
     const { ctx, userId, tenantId } = input;
     const ql = (() => {
         try { return ctx.getService<IDataEngine>('objectql'); } catch { return undefined; }
     })();
-    const stored = await storedSignedInUserLocale(ql, userId, ctx.logger);
-    if (stored) return stored;
-    const requested = preferredLocaleFromHeader(input.acceptLanguage);
-    if (requested) return requested;
     const settings = (() => {
         try { return ctx.getService<unknown>('settings'); } catch { return undefined; }
     })();
-    const localization = await resolveLocalizationContext({ ql, settings, tenantId, userId });
-    return localization.locale;
+    const [stored, deployment] = await Promise.all([
+        storedSignedInUserLocale(ql, userId, ctx.logger),
+        resolveLocalizationContext({ ql, settings, tenantId, userId }),
+    ]);
+    return {
+        currency: deployment.currency,
+        locale: stored ?? preferredLocaleFromHeader(input.acceptLanguage) ?? deployment.locale,
+        timezone: deployment.timezone,
+    };
+}
+
+/**
+ * The signed-in user's language — the ONE read face (#14788), the `locale`
+ * rung of {@link resolveCurrentUserLocalization} on its own.
+ *
+ * Always answers a string for an authenticated caller: rung 3 has a floor.
+ * Exported for the serverless host path that composes the resolver directly
+ * (cloud#924) and for the pin that asserts the precedence. Its ANSWER is
+ * unchanged by #15387; what changed underneath is that the deployment cascade
+ * is now read even when rung 1 or 2 wins (see above).
+ */
+export async function resolveSignedInUserLocale(input: ResolveSignedInUserLocaleInput): Promise<string> {
+    return (await resolveCurrentUserLocalization(input)).locale;
 }
 
 /**
@@ -1002,8 +1059,7 @@ export function registerCurrentUserEndpoints(
     // language (`locale`), exposed to EVERY authenticated user. The
     // `localization` SETTINGS are gated to `setup.access`, but the resolved
     // defaults are needed by every renderer to format currency/dates/numbers —
-    // so they ride on the request ExecutionContext (ADR-0053) and are surfaced
-    // here without that gate.
+    // so they are surfaced here without that gate.
     //
     // [#14788] `locale` is the ONE read face for "this user's language"
     // (maintainer ruling 2026-09-03, option D, which also retired the dead
@@ -1014,24 +1070,31 @@ export function registerCurrentUserEndpoints(
     //   2. the request's `Accept-Language` preference;
     //   3. the deployment default (`localization.locale`, the same cascade
     //      that feeds `execCtx.locale` on the dispatcher).
-    // See {@link resolveSignedInUserLocale}. `currency` / `timezone` and the
-    // unauthenticated answer are unchanged by that ruling.
+    //
+    // [#15387] All three come from {@link resolveCurrentUserLocalization} —
+    // ONE reading of that same cascade. `currency` / `timezone` used to be read
+    // off `execCtx` instead, citing ADR-0053; the resolver this surface uses
+    // ({@link makeExecutionContextResolver}) never carried them, so the
+    // endpoint answered `null` for both to every authenticated caller no matter
+    // what the deployment had configured. The `?? null` on `currency` is not
+    // that fallback returning: it is the cascade's own shape, which gives
+    // `timezone` a floor and `currency` none.
     rawApp.get(`${prefix}/auth/me/localization`, withRequestContext(async (c, ctx, resolveCtx) => {
         const execCtx = await resolveCtx(c);
         if (!execCtx?.userId) {
             return c.json({ authenticated: false });
         }
-        const locale = await resolveSignedInUserLocale({
+        const localization = await resolveCurrentUserLocalization({
             ctx,
             userId: execCtx.userId,
             tenantId: execCtx.tenantId ?? undefined,
             acceptLanguage: c.req.raw?.headers?.get?.('accept-language') ?? undefined,
         });
         return c.json({
             authenticated: true,
-            currency: execCtx.currency ?? null,
-            locale,
-            timezone: execCtx.timezone ?? null,
+            currency: localization.currency ?? null,
+            locale: localization.locale,
+            timezone: localization.timezone,
         });
     }));