[manager]

The UX Core bias page reads biases and UXCG questions for its own locale only (biases[locale], uxcgLocalizedData[locale], getAdjacentBiasTitles(locale, ...)) but shipped all three locales of both. This sends the current locale only, with an empty-list fallback.

Measured by applying the same trim to a live payload (/uxcore/1-availability-heuristics): page data 1.70 MB -> 0.59 MB. tsc --noEmit clean.

Authorized by Wolf on 2026-10-15.

🤖 Generated with Claude Code

[github-actions]

Claude finished @manager's task in 20s —— View job

---

Review of PR #255: ship only the current locale on bias pages

Verdict: looks correct, no blocking issues.

• Read the diff and the consumers of biases and uxcgLocalizedData

What I checked

• In src/pages/uxcore/[slug].tsx, the page only reads uxcgLocalizedData?.[locale] (line 55), biases[locale] (lines 181 and 183), and getAdjacentBiasTitles(locale, biases, …).
• getAdjacentBiasTitles (src/uxcore/lib/helpers.ts:475) also only indexes biases[locale]. It returns { next: null, prev: null } when the list is empty.
• getStaticProps runs per locale, so a client-side language switch gets fresh props for the new locale. Nothing needs the other locales' data at runtime.
• The ?? [] fallback keeps the shape the page expects. An empty array is truthy, so the biases[locale] ? <UXCoreLayout/> guard behaves as before.
• currentModalData is still built from the merged three-locale data, so SEO fields and languageSwitchSlugs are unaffected.
• The change touches no UX Core bias data, slugs or schema. It only trims what is serialized into page props.
• { [locale]: … } types as string-keyed, which matches the Record<string, …> props. The new code adds no any.

Minor, optional

• The locale as 'en' | 'ru' | 'hy' cast now appears three times in getStaticProps. A local const loc = locale as 'en' | 'ru' | 'hy' would tidy it. This is not required.
• I did not run the build or tsc myself. I'm relying on the PR's stated tsc --noEmit result and the 1.70 MB to 0.59 MB measurement.

Release process

• This is a prod-bound PR. Per CLAUDE.md it needs Wolf's direct go before merge to main. The description says it was authorized on 2026-10-15.