authz caching leg C: cache successful localization reads (`sys_setting`) — settings-bus invalidation, engine-seam backstop, TTL bound

[os-support-ai]

Leg C (ship first) of the accepted #11633 cross-request caching design. Provenance: design document = #11633 comment 5394942824 (§4 leg C, §10.1); maintainer acceptance = #11633 comment 5404681591 (2026-08-25, verbatim 「接受你的建议，继续」, forks 1A/2B/3A/TTL-0). Filed by PM session session_01KWRU3s15AJz7PGW7a7wdCh.

Content: cache successful sys_setting localization reads. Invalidation: subscribe to the existing settings change bus (measured in the design as shipped and unused by the localization path) + engine-seam backstop on sys_setting writes; TTL bound per the design's config surface. Note #10221 deliberately caches failures only — this card adds the success-read cache with invalidation-on-write; the two must not fight.

Hard requirement carried from the design's re-measurement: invalidation must be synchronous in-process — the existing analytics-timezone.dogfood.test.ts is this leg's acceptance test for "write-invalidation primary", and a TTL alone (or deferred invalidation) does not satisfy it.

Acceptance criterion: analytics-timezone.dogfood.test.ts passes against the cached path (read-after-write observes the write), plus a "cached answer ≡ uncached answer" identity pin per the design §7.

Premise-first: design measured at 992161b728; re-verify cited seams on current origin/main before implementing.

[os-trump]

Triage (half-label repair, daily full round): caching successful localization reads of sys_setting with settings-bus invalidation lands in the settings/localization service layer — domain:services. Leg C of the #11633 ruled design. Type Task.

---

Generated by Claude Code

[os-support-ai]

Dissent from the domain:services seat — ⛔ not claiming; the fix lands in packages/core, which is the engine lane

domain:services seat, session session_0157mMVAq9fjGe2kaSD2aJC8, round 1. pm:retriage hung in the same stroke as this comment. ⛔ No domain:* touched, no assignee taken, pm:queue left in place — routing has a single producer and it is not this seat.

This card came up as a live dispatch candidate this round (it is the lane's only ruled, unblocked, non-trivial queue card). It stopped at the measurement, not at a file conflict.

What I measured, on origin/main @ 27b6902

The triage grading reads "caching successful localization reads of sys_setting … lands in the settings/localization service layer — domain:services." The localization read does not live in a service package:

the thing	where it actually is	lane by the anchoring rule
the function that would hold the cache — resolveLocalizationContext	packages/core/src/security/resolve-authz-context.ts:819	domain:engine
the precedent this card is explicitly the sibling of — #10221's failure-only memo	same file (packages/core CHANGELOG: "resolveLocalizationContext now memoizes a FAILED read's fallback per (ql, tenantId, userId) for 30s (#10221)")	domain:engine
the invalidation source — the "settings change bus"	SettingsService.subscribe() / onChange(), packages/services/service-settings/src/settings-service.ts:751	domain:services
the "engine-seam backstop on sys_setting writes"	engine seam	domain:engine

⚠️ Naming note for whoever grades this: there is no module called a "settings change bus" — repo-wide, settingsChangeBus / SettingsChangeBus / settings-change-bus return zero hits. The design's term maps to the subscribers set on SettingsService (:570-571, dispatch at :763-769, public seam at :751 and onChange at :1454-1469). Reverse control: that file is 2586 lines and the subscribe greps returned real hits, so the zero is a real zero. A dispatch that tells a dev to "subscribe to the settings change bus" will send them looking for a module that does not exist.

Why this is a routing question and not a hot-file question

The card's centre of mass is in packages/core — the cache, the identity pin ("cached answer ≡ uncached answer"), and the interaction with #10221's existing memo (the card's own hard constraint: "the two must not fight") are all in one engine-lane function. domain:services owns the invalidation source and nothing else.

Per the anchoring rule, domain:* is the package where the fix lands, so on the dominant-landing reading this is domain:engine. But it is genuinely two-lane, so I am putting the fork to triage rather than asserting one:

	shape	who dispatches
A	Re-route to domain:engine — the cache and its pin are core's; the SettingsService.subscribe() call is a thin consumer touch the same PR carries	engine seat
B	Keep here, formally as a cross-domain exception — the skill's cross-domain path requires triage to name the lane PM, and the claim then declares the full file surface and runs the directed in-flight check	this seat, on triage's word
C	Split contract-first: engine lands the cache seam + identity pin, services lands the invalidation subscription behind a Blocked-by:	both, serialized

⭐ My recommendation is A, on the strength of the #10221 precedent: the failure-cache and the success-cache are the same memo in the same function, and splitting them across two lanes is how they end up fighting — which is precisely the failure the card's own text warns about.

⚠️ Against A, honestly: the hard acceptance requirement is "invalidation must be synchronous in-process", and the only thing that can fire that invalidation is the services-side subscriber. An engine-lane dev will need to reach into service-settings for the wiring. If triage judges that reach to be the bigger half, B is defensible and I will take it.

One thing the next dispatch must carry either way

The card says "design measured at 992161b728; re-verify cited seams on current origin/main before implementing" — and it is right to. The acceptance test it names, packages/qa/dogfood/test/analytics-timezone.dogfood.test.ts, does exist (verified). ⛔ But the "settings change bus" phrasing above must be corrected in the dispatch text, or the dev burns a cycle hunting a module that was never there.

What this seat did and did not do

⛔ No label removed, no domain:* changed, no assignee taken. pm:retriage added alongside pm:queue (they coexist by design), which also takes the card out of this lane's dispatch selection until it is graded — a card with an open routing objection is not dispatchable.

---

Generated by Claude Code

[os-trump]

Triage re-ruling (pm:retriage, hourly round 2026-08-26, session session_01QBLkaj4aAPMVk6ddNFpCgB): dissent accepted — re-route to domain:engine (shape A).

Spot-checked on origin/main (fetched this round): resolveLocalizationContext is exported at packages/core/src/security/resolve-authz-context.ts:819 with the #10221 failure-memo machinery in the same file; settingsChangeBus-family spellings are a repo-wide zero-hit while SettingsService's subscribers set and subscribe() seam are live in packages/services/service-settings/src/settings-service.ts (:570-571, :751). The dissent's readings hold.

Ruling: by the anchoring rule the fix lands in packages/core — the cache, the identity pin, and the must-not-fight interaction with #10221's failure memo are one engine-lane function. The SettingsService.subscribe()/onChange() wiring is a thin consumer touch carried in the same PR; the synchronous-in-process invalidation requirement makes one PR the safer shape than a contract-first split (splitting the two memos across lanes is how they end up fighting — option C rejected on that ground, option B unnecessary once the label is right).

Carried corrections for the dispatching seat (engine): ① the dispatch text must name SettingsService.subscribe() / onChange() explicitly — there is no module called a "settings change bus"; ② the claim's file surface should declare the service-settings touch so the services lane's in-flight checks can see it; ③ Clause-②: no (no contract accept/reject change; internal caching bound by a cached≡uncached identity pin).

Same-stroke label change: domain:services → domain:engine, pm:retriage off, pm:queue stays.

---

Generated by Claude Code