16 Commits

Author	SHA1	Message	Date
Ilia Denisov	e3c2e80a0a	feat(payments): report income to «Мой налог» ... The direct rail runs on НПД, where the provider neither files with the tax service nor issues a receipt — so nobody was doing it. This registers each rouble purchase, annuls its receipt on a refund, and hands the buyer the receipt by email. Two properties of the (unofficial) lknpd API shape the design. Registering an income takes no idempotency key, so an error does not mean nothing happened: the service name is frozen before the call and carries a marker from the tail of the order id, and after a failure the taxpayer's income list is searched for that exact name. Found means filed; not found halts the queue for a human, because declaring an income twice is as wrong as not declaring it. And faults are classified rather than logged: a token is renewed silently, a throttle backs off, an outage retries, but three unfixable rejections take the rail out of service — a changed format must not become thousands of requests overnight. The console button and the worker share one RunBatch. Automatic mode is armed from the console, not from configuration, so the operator can watch a run go through by hand first. A daily watchdog runs whether or not it is armed, since the case it exists for is the export being off. An idle queue issues no call at all — not even an authentication. No payment path changed: the purchase letter rides the existing payment-event outbox on its own cursor, the receipt and annulment letters ride the export row. Decisions D53-D60.	2026-07-28 15:40:36 +02:00
Ilia Denisov	e3961fe4ca	fix(payments): a console refund that its own notification beat is not a repeat ... Refunding from /_gm reported "Already refunded" for a refund that had just succeeded, which reads as "you clicked twice". The two recording paths race. YooKassa fires refund.succeeded the moment POST /v3/refunds returns, so the notification handler often writes the reversal before the console's own write lands. Both name the same refund id, so the ledger's idempotency index rejects the second — which is the mechanism working exactly as intended: on the contour the money moved once, one refund row was written, the balance is right and no abuse flag was raised. Only the message was wrong about why. The console now reports success on that path, and the notification's log line no longer claims the refund was "issued outside the console" when it may well have come from it. Covered by an integration test that lands the notification first and then refunds from the console, asserting the operator is told it succeeded and that exactly one refund row exists.	2026-07-28 12:15:59 +02:00
Ilia Denisov	4cac09c9f3	fix(payments): drop the notification sender-IP gate; re-check on its own cadence ... A real test payment on the contour exposed both problems at once. YooKassa delivered the notification five times; all five were rejected because the backend saw the sender as 10.77.0.1 — the contour sits behind a tunnel and cannot observe real client addresses, the same reason the IP bans in this repository are prod-only. The chips were not lost (the reconcile sweep would have credited them), but the primary path was dead and the customer was left watching an unchanged balance. The address check is removed rather than made conditional. It never was the security boundary — the confirming GET /v3/payments/{id} is — and the one thing it bought is already bought earlier and far more tightly: the order is resolved from the notification's metadata *before* any provider call, so a notification naming no known order costs a single indexed read and stops there. Guessing a live order id means guessing a uuid. Against that, an address check adds nothing and breaks every deployment that cannot see real client addresses, while turning any future change to YooKassa's published ranges into a silent degradation. The second problem was mine. The reconcile threshold was keyed off the order lifetime, so a lost notification cost the customer the full 30-minute TTL before the chips landed. Those are different questions: the lifetime governs how long a customer may take to pay, the re-check governs how soon we notice a lost callback. Split apart — `payments.ReconcileAfter`, one minute, swept on every reaper tick. The bound D49 was chosen for survives: the calls one order can cause are still its lifetime divided by the sweep interval, a handful, not an open-ended poll. Worst case for a failed notification drops from ~30 minutes to ~5; an order the customer is still paying for is left alone. Tests: the foreign-sender test is replaced by the two properties that now carry the load — a notification naming an unknown order makes no provider call at all, and a genuine notification is honoured whatever address it appears to come from. Plus one pinning that a seconds-old order is not polled. The shared bundle budget goes 31 -> 32 KB, with the reason recorded in the script header: every user-visible string lands in that chunk and it had been sitting 40 bytes under the cap. Decisions D48 and D49 revised.	2026-07-28 12:00:03 +02:00
Ilia Denisov	12e616ceae	feat(payments): send no fiscal receipt; keep the code switchable ... The merchant accepts payments as a sole proprietor on НПД, which is outside 54-ФЗ: there is no online cash register, YooKassa does not serve receipts for that regime at all (checked with their support), and each operation is reported by the merchant to «Мой налог», which issues the чек. So no `receipt` is sent with a payment or a refund. This also removes a failure class rather than just code: a malformed receipt was an API error at payment creation, which broke the purchase outright. The fiscal code is kept dormant rather than deleted. All of it now sits behind one switch, `BACKEND_YOOKASSA_VAT_CODE`: unset — the default — builds and sends nothing; a 54-ФЗ rate code turns «Чеки от ЮKassa» back on unchanged. The return is foreseeable, which is why the switch exists: НПД carries an annual income ceiling, and losing the regime puts 54-ФЗ back in force, at which point this is a deploy-variable edit instead of writing the integration again. The D36 email anchor still gates a direct purchase. It had two justifications — a recovery anchor and the receipt address — and only the second is gone; without an email a paying customer who loses the account loses the chips with it. What was missing is that the rule was enforced but never communicated: the wallet showed the packs to a player signed in through VK or Telegram in a browser, and tapping Buy produced a bare "something went wrong". It now says "add an email in your profile" in the buy tab instead, linking to the profile; spending already-earned chips is untouched. The predicate is a pure function so it is covered by the node-env unit tests rather than needing a browser. Tests: the receipt-off default is pinned by an integration test asserting a purchase carries no receipt, and the dormant path by one that switches a VAT code on and checks the receipt reappears with the right fiscal attributes; plus unit coverage for the enable predicate and the wallet's email rule. A note for whoever runs the numbers next: the shared (svelte + i18n) chunk is now 40 bytes under its 31 KB gzip budget. Decision D51 revised.	2026-07-28 11:40:59 +02:00
Ilia Denisov	395a307eca	feat(payments): reverse refunds issued outside the console ... Two holes on the refund path, both found by asking what happens when a refund does not come from our own `/_gm` button. The merchant cabinet is a second entry point. An operator can refund there, and such a refund never passes through our API — so the money went back while the chips stayed credited, silently. Handle `refund.succeeded`: the refund is re-read from the API (the notification body is no more evidence here than it is for a payment), bound back to its order through the payment id recorded when the payment was minted, and reversed through the same engine. It is idempotent on (provider, refund id), so the event for a refund the console already recorded reverses nothing twice. The reversal engine is full-refund-only by design — it revokes exactly what the pack funded and rejects any other amount — so a partial refund is recorded as nothing at all and logged loudly for an operator. There is no non-arbitrary way to decide how many chips a part-refund costs, and guessing would be worse than asking a human. Second hole: a refund can still be canceled while pending, and the ledger is append-only. Recording on any non-empty refund id therefore risked revoking a customer's chips for money that stayed with us, with no way to take the row back. The console now records only a `succeeded` refund and tells the operator to press again otherwise — the idempotency key returns the same refund rather than paying twice. Tests: unit (GetRefund, the refund notification envelope, a non-final status surfaced to the caller); integration (a cabinet refund is reversed once and a redelivery is a no-op, the event after a console refund changes nothing, a partial refund records nothing, an unconfirmed refund reverses nothing, a pending refund records nothing until it settles and then does). The suite shares one database and the ledger dedupes refunds globally, so the fake provider now mints a refund id per payment — a constant id made one test's refund look like another's duplicate. Decisions D50 (amended) and D52; the notification subscription list in the deploy docs gains refund.succeeded.	2026-07-28 09:18:19 +02:00
Ilia Denisov	92ba527575	feat(payments): settle the direct rail through YooKassa ... Replace Robokassa with YooKassa as the RUB direct-rail provider. The wallet model is untouched: one `direct` segment, the same spend wall, the same per-channel merchant shops (D42) and `shop` on the order (D44). The two providers are not shaped alike, and that drives the change: - Opening a purchase is now an outbound API call (`POST /v3/payments`, single-stage capture, redirect confirmation). The order id is both the `Idempotence-Key` and `metadata.order_id`, so a retried create cannot mint a second payment and a notification always resolves to its order. - YooKassa does NOT sign notifications, so the body is never evidence: it only names a payment, which is re-read with `GET /v3/payments/{id}`, and only that answer is acted on. Two guards ride on it — the payment's metadata must name the order, and its `test` flag must match the shop's, so a test-shop payment can never credit real chips. The sender address is checked against YooKassa's published ranges first, which stops a forger turning each fabricated notification into an outbound call of ours. - A notification lost for good would leave the money taken and the chips unowed, silently. The existing pending-order reaper now asks the provider about each order that reached its expiry age carrying a payment id, and credits the ones really paid — one request per order over its whole life, not polling. - `payment.canceled` records a `failed` event, so a declined payment is finally surfaced to the customer as PAYMENTS.md §9 already specified. - The admin refund moves the money through `POST /v3/refunds` before recording anything; a failed call records nothing, so the ledger cannot claim a refund that did not happen, and the recorded id is the provider's own. - YooKassa has no cabinet-side generic receipt: «Чеки от ЮKassa» registers one only if the request carries it, so every payment and refund now sends an itemized `receipt` to the D36 confirmed email. The VAT rate code is a deploy variable; the settlement subject and method are constants. Robokassa is retired, not deleted: the direct rail falls back to it when no YooKassa shop is configured and no deployment sets its credentials, so reviving it is a credentials change rather than a code change. Its variables are removed from compose, .env.example, write-prod-env.sh and the three workflows, and recorded in backend/internal/robokassa/README.md together with the cabinet configuration and the revival steps. Ledger rows keep `provider = 'robokassa'`; that literal is load-bearing for the idempotency index. No migration and no wire change: `orders.provider_payment_id` already existed, and the client is rail-agnostic. Decisions D47-D51 (revising D41) and stage E12 are baked into the docs.	2026-07-28 08:51:31 +02:00
Ilia Denisov	f3c08e031e	fix(rules): case-fold the played words, so the rule fires online too ... The no-repeat-words rule never fired in an online game. The move preview builds its set of already-used words from the history the client holds, and the codec upper-cases those words for display, while the evaluator decodes the candidate word to lower — so "БРА" was never found to equal "бра" and every repeat scored as an ordinary play, right up to the server refusing it. Offline was unaffected: that engine compares alphabet-index keys taken from its own journal, which carry no case at all. The tests missed it because they hand-built the played set in the form the server sends rather than deriving it the way the game screen does. They now go through playedWordsFromHistory with history records shaped as the codec produces them — upper-cased words and all — which is the path that was broken; three of the five fail without this fix.	2026-07-27 19:37:34 +02:00
Ilia Denisov	5be8116607	docs(agent): note the UI job's bundle-size gate as a local pre-push step	2026-07-27 19:21:20 +02:00
Ilia Denisov	f60327c1ce	fix(payments): reject HTML-special chars in product titles (VK payment guard) ... A product title containing & < > " ' silently breaks VK purchases: VK HTML-escapes the character in its order_status_change payment-callback echo (e.g. " -> &quot;) but signs the notification over a different form, so the gateway's signature check no longer matches ("vk callback: bad signature") and the purchase never confirms — while get_item (whose request carries no title) still passes. validateProduct now rejects those characters at the admin catalog editor — the single write path for CreateProduct/UpdateProduct/SetProductActive — so a title can't reintroduce the break. Reject, not transform: the operator retypes a clean title (« » guillemets, not straight quotes), so the stored value stays identical everywhere (storefront, wallet, VK box). Docs: docs/PAYMENTS.md §7 + agent field notes; Go Doc on validateProduct. Test: validateProduct HTML-special-char cases. No wire/schema change.	2026-07-16 20:57:04 +02:00
Ilia Denisov	a067a2fd01	chore(android): de-anchor ANDROID_PLAN.md from the docs, re-enable the APK workflow ... Reword every code comment and doc that referenced ANDROID_PLAN.md or its stage anchors (§E, G-step-0, O1) so the living docs no longer depend on the plan file: .claude/CLAUDE.md, deploy/README.md, docs/ARCHITECTURE.md, docs/TESTING.md, ui/README.md, ui/android/.gitignore, ui/e2e/native.spec.ts, ui/src/lib/netstate.ts. Re-enable the manual signed-APK workflow (android-build.yaml.disabled -> android-build.yaml; the CI host already has the Android SDK; workflow_dispatch-only, so it does not auto-run on this PR). Add docs/ICONS.md — the single-master icon/logo format reference (web, PWA, Android, future iOS, store listings).	2026-07-13 14:05:43 +02:00
Ilia Denisov	49c53794f4	fix(ui): native header top safe-area under edge-to-edge ... The earlier safe-area fix reached the bottom bars (they apply --tg-safe-bottom) but not the header: its top inset lived only in a Telegram-fullscreen-scoped rule, so on the native build the header .bar had just 5px top padding and its content sat under the status bar (measured: the title at y=11px behind the 54px bar; the back button untappable). Give .bar a top inset from the SystemBars plugin's --safe-area-inset-top (native-only via the plugin var; unset -> 0 on web/PWA/Telegram/VK, so no regression; tg-fullscreen still overrides via specificity). Verified on-device (Pixel_10 / API 37): the title moved from y=11 to y=65, clear of the status bar.	2026-07-12 19:22:12 +02:00
Ilia Denisov	4a0689a4ac	fix(ui): native safe-area under Android 15+ edge-to-edge (WebView < 140) ... targetSdk 36 forces edge-to-edge, so the WebView draws behind the system bars. On Android WebView < 140, env(safe-area-inset-*) wrongly reports 0, so the app chrome (which only read env()) drew under the status bar (top nav untappable) and the gesture-nav home indicator (the game's centre Hint button intercepted; side buttons fine). Capacitor 8's SystemBars core plugin (built into @capacitor/core, insetsHandling:'css' by default) injects the correct --safe-area-inset-* values on every WebView; consume them ahead of env(): --tg-safe-*: var(--safe-area-inset-*, env(safe-area-inset-*, 0px)) Web / PWA / Telegram / VK are unchanged (--safe-area-inset-* is unset there, so it falls back to env()). Verified on-device (Pixel_10 / API 37) via the injected var — the emulator's auto-updated WebView 149 hides the env() bug, so the visual alone won't reproduce it.	2026-07-12 18:58:07 +02:00
Ilia Denisov	e077258567	feat(ui): offline-first native boot + lazy server-guest reconciliation ... Native (Capacitor) cold boot with no cached session now enters as a device-local guest in auto-offline mode and lands straight in the lobby (never /login), so the app opens and plays local vs_ai / hotseat with the APK's bundled dictionaries and zero network. When the gateway becomes reachable, reconcileServerGuest silently mints + adopts a server guest and clears the auto-offline, lighting up online features. Web / PWA / Telegram / VK are byte-for-byte unchanged. - transport: exec gains { silent, allowOffline } so background reconciliation bypasses the offline kill switch (like the reachability probe) and never raises the terminal update overlay (a too-old client stays a local guest); new authGuestSilent on the client interface, the real transport and the mock. - app: native no-session boot branch; reconcileServerGuest fired at boot, by the recovery poll and the online event; the poll routes the session-less guest through reconciliation, since checkReachable needs a token it lacks. - native: initNativeShell tolerates a missing Capacitor bridge. - e2e: new native.spec.ts (inject window.androidBridge; boot -> offline lobby, local vs_ai move, reconcile -> online, hotseat start) + playwright.config bundles the dawgs into dist-e2e/dict for the loader's bundled tier.	2026-07-12 18:03:52 +02:00
Ilia Denisov	de003e862a	feat(android): resolve gateway origin on native, skip SW, hide MVP purchases ... Make the web SPA behave correctly inside the Capacitor native shell, where the bundle loads from a local origin: - New lib/origin.ts gatewayOrigin(): absolute URLs resolve to VITE_GATEWAY_URL on native (the finished-game export/share URL in Game.svelte and the Wallet site-root link), falling back to the page origin on web. transport.ts already resolved via VITE_GATEWAY_URL and is left as-is. - Skip the PWA service worker on the native channel (the assets are already local; a worker would risk serving stale content across store updates). - Hide the money-purchase UI in the MVP: new distribution.purchasesHidden() folds VITE_PAYMENTS_DISABLED and the Google Play flag. The Wallet "buy" tab shows a neutral, pointer-free note (wallet.purchasesSoon) for the RuStore MVP and keeps the RuStore stub Google-Play-only. A ?nopay mock force mirrors ?gp for the e2e. - Native env types in vite-env.d.ts. Client-only, contour-safe: no wire/proto/schema change; web/VK/Telegram unchanged. Tests: origin + purchasesHidden unit tests, a ?nopay wallet e2e. svelte-check clean, vitest green, web + native vite build clean.	2026-07-12 14:58:35 +02:00
Ilia Denisov	53b33073ac	docs(android): fix plan (dict source, Capacitor 8 / SDK 36 / JDK 21) and record scaffolding progress + native-build notes ... Correct ANDROID_PLAN.md: bundled offline dictionaries come from the scrabble-dictionary release (DICT_VERSION), not scrabble-solver; pin the toolchain to Capacitor 8 (compileSdk/targetSdk 36, minSdk 24, JDK 21 — @capacitor/android compiles at Java 21). Add a Progress section marking the scaffolding milestone done, and capture the native-Android build recipe + toolchain gotchas in .claude/CLAUDE.md so a fresh session resumes without re-deriving them. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-12 01:34:25 +02:00
Ilia Denisov	0c5e40c509	docs: capture agent field notes; drop RuStore-steering for the GP variant	2026-07-11 22:53:26 +02:00