8 Commits

Author	SHA1	Message	Date
Ilia Denisov	de2f1432be	chore(ui): surface caught boot errors on the diagnostic panel ... The es2019 + conditional core-js fixes let the module mount on the Chromium 66 in-app WebView, but the lobby then shows a white screen and a generic "something went wrong" toast — a caught error that never reaches window.onerror, so the diagnostic ERRORS panel stayed empty and could not name the cause. Mirror console.error / console.warn into the panel, and add a temporary, mock-gated console.error of the raw error (with stack) in handleError, so the on-device panel shows exactly what threw and whether it is one error or several. Expected: a ReferenceError from the 64-bit FlatBuffers timestamp decode (BigInt, absent on Chrome 66 and not polyfillable by core-js) — to be confirmed on-device before deciding the support floor. Temporary — both hunks revert together with the index.html BOOT-DIAG block.	2026-07-04 17:40:31 +02:00
Ilia Denisov	4a0c296bbb	fix(ui): conditionally load core-js polyfills for old Android WebViews ... The es2019 down-level fixed the parse error, but the Chromium 66 in-app WebView (Android 9) then threw "Uncaught ReferenceError: globalThis is not defined" — esbuild lowers syntax, not the es2020+ runtime globals the bundle and its deps reference (globalThis, structuredClone, Array.at, Object.hasOwn, Promise.allSettled, …), so the module still failed to evaluate and the SPA stayed a white screen. Load core-js only where it is actually missing. A permanent ES5 gate in index.html feature-detects the engine and, on an old one, document.writes a parser-blocking <script src=polyfills.js> before the deferred module runs; a modern engine matches none of the checks and downloads nothing. document.write is used deliberately — it is the only way to inject a script guaranteed to run before a deferred module — with a static literal argument (no interpolation, no injection surface). vite.config emitPolyfills writes dist/polyfills.js from the prebuilt core-js-bundle and keeps it out of the module graph, so the bundle-size budget is unaffected (app entry still 108.8 / 110 KB gzip). pnpm-workspace denies core-js-bundle's install script (the package ships a prebuilt minified.js we only read at build time; its script is a funding banner). svelte-check and the mock e2e (Chromium + WebKit) are green and the size gate still passes. The on-device re-test on the Chromium 66 emulator is pending.	2026-07-04 17:03:49 +02:00
Ilia Denisov	6dfd5203d7	fix(ui): down-level build target to es2019 for old Android WebViews ... The es2022 build target shipped optional chaining / nullish coalescing verbatim (esbuild does not down-level syntax below the configured target), so an old Android System WebView — captured as Chromium 66 in the Telegram/VK in-app WebView on Android 9, via the boot diagnostic — rejected the bundle with "Uncaught SyntaxError: Unexpected token ?" at main-*.js:2, the module never ran (no .app-shell, #app empty) and the SPA showed a white screen. Firefox/Gecko on the same device, which ships its own current engine, rendered the SPA fine. Lower build.target to es2019 so esbuild down-levels the es2020+ syntax the old engine cannot parse (?., ??, private fields, static blocks, numeric separators). Verified the emitted main bundle no longer contains ?./?? and the mock e2e (Chromium + WebKit) still passes. The boot-diagnostic JS-SYNTAX header is relabelled accordingly. esbuild lowers syntax only, not runtime APIs; the app's own production source uses none beyond this floor (mock-only helpers are tree-shaken). A graceful "update your WebView" fallback and any runtime-API polyfills follow once the on-device re-test confirms the parse fix (and @vitejs/plugin-legacy stays in reserve for even older engines).	2026-07-04 12:58:57 +02:00
Ilia Denisov	8c55b2d239	chore(ui): temporary on-device boot diagnostic for the Android WebView white screen ... Add a classic ES5 <script> to index.html, before the ES2022 module bundle, that renders an on-screen diagnostic overlay. It runs and paints even when the bundle fails to parse on an old Android System WebView (the Telegram/VK in-app case we are chasing: Firefox/Gecko renders the SPA on the same device, the in-app WebView shows only a white screen). The overlay installs error capture first (so a module SyntaxError / load failure / unhandled rejection is printed), then reports the engine (userAgent + Chromium version), the JS syntax and Web API support the es2022 bundle needs — each row dated by the Chrome version that shipped it, so the first failing row dates the engine — and whether the module ran (<html> gets .app-shell) and Svelte mounted (#app has children). A verdict flags the likely cause; a Copy button exports the report. vite.config.ts strip-boot-diag removes the whole BOOT-DIAG block from every non-production build, so the mock e2e (whose first taps a full-screen overlay would intercept) and the dev server stay clear; only the production build shipped to the test contour carries it. Temporary: revert this commit (the index.html block and the plugin) after the diagnosis. It must never reach master / production.	2026-07-04 12:30:47 +02:00
Ilia Denisov	1ed624eaf1	feat(landing): Russian default + SEO head, icons and OG card ... The landing now always opens in Russian (saved 🌐 choice still wins) — browser-language detection made the indexed content nondeterministic (Googlebot renders with en-US). landing.html gains the static Russian SEO head: title/description, canonical pinned to the production origin, Open Graph card (Telegram/VK link previews), twitter:card, JSON-LD, theme-color and the favicon set; the SPA shell turns noindex and its tab title becomes «Эрудит (Скрэббл)». New assets/icons generator (same tile design as the VK loader) produces favicon.svg/ico, apple-touch-icon.png and og-image.png into ui/public/, plus robots.txt.	2026-07-02 01:25:19 +02:00
Ilia Denisov	ae5090b851	fix(ui): load telegram-web-app.js dynamically with a timeout ... The Telegram SDK was a render-blocking <script src="telegram.org/..."> in the shared index.html shell, so it ran on every entry (/telegram/, /app/, native). On a network that blocks telegram.org — common where Telegram itself reaches users only over a proxy — the script hangs forever, stranding the whole page, including the launch-diagnostic screen meant to surface exactly this failure. This is the likely root cause of the Android "won't open" reports (all launch methods fail identically; iOS on a different network works). Remove the head <script> and load the SDK dynamically (lib/telegram.ts loadTelegramSDK) with a 10s timeout, only on a Telegram entry (the /telegram/ path or a tgWebApp launch fragment). The SPA — served from our own reachable origin — boots first and controls the load: on a block/error it falls through to the diagnostic screen (reporting sdk: no) instead of hanging, and Retry re-attempts. /app/ and the native build no longer touch telegram.org. Pin the SDK to the version the official page recommends (?62) for the newer client features the app already uses (fullscreen, safe areas, swipe guard). Tests: loadTelegramSDK unit tests (present / error / timeout); an e2e that aborts the script fetch and asserts the diagnostic still renders.	2026-06-23 09:59:24 +02:00
Ilia Denisov	cf66ed7e26	Stage 9: Telegram integration (connector side-service, Mini App, out-of-app push) ... New platform/telegram connector (own container, bot token only there): - go-telegram/bot long-poll loop: /start deep-links + Mini App launch button. - gRPC API pkg/proto/telegram/v1 (Telegram service): ValidateInitData, Notify (renders a localized message + deep-link button), SendToUser/SendToGameChannel (admin, wired in Stage 10). Generic methods are platform-agnostic (external_id). - Bot API base override for Telegram's test environment; Dockerfile + compose (VPN sidecar, no public ingress); README. Gateway: - initData validation relocated from the gateway into the connector; the gateway calls ValidateInitData over gRPC (GATEWAY_CONNECTOR_ADDR), drops the bot token, and deletes internal/auth. - Out-of-app push: runPushPump routes events whose recipient has no live in-app stream to connector.Notify, gated by /internal/push-target + the in-app-only flag (race-free de-dup); HasSubscribers added to the push hub. Backend: - Migration 00007 accounts.notifications_in_app_only (default true) + jetgen. - ProvisionTelegram seeds a new account's language/display name from the launch fields; IdentityExternalID reverse lookup; /internal/push-target handler. UI: - Telegram Mini App launch: detect initData, apply themeParams, authTelegram, route the deep-link start_param (g/i/f); /telegram/ guard redirects outside Telegram. Vite relative base + telegram-web-app.js. In-app-only profile toggle; share-to-Telegram link for a friend code. Vitest + Playwright coverage. Wire/docs/CI: fbs Profile/UpdateProfileRequest gain notifications_in_app_only (Go + TS); go.work uses ./platform/telegram; go-unit.yaml covers it; PLAN, ARCHITECTURE, FUNCTIONAL (+ru), UI_DESIGN, READMEs updated.	2026-06-04 07:10:21 +02:00
Ilia Denisov	453ddc5e94	Stage 7 (wip): UI shell, libs, mock transport, screens (lobby->game), e2e smoke ... - plain Svelte 5 + TS + Vite (no SvelteKit); CSS-token design system (Telegram-ready), hash router, IndexedDB session - pure libs: domain model, premium/value maps ported from solver, board replay, placement state machine, i18n en/ru - in-memory mock transport + seed data; pnpm start runs lobby->active game->board with no backend - board: pointer-drag + tap placement, MakeMove (popup / 1s-hold commit), two-state zoom, blank chooser, exchange, hint, word-check, chat - Playwright smoke (mock) green; svelte-check clean; mock bundle ~37 KB gzip	2026-06-03 00:32:50 +02:00