Two games, no players.
A plan to 31 December 2026.

P0 · 18–31 Aug Be findable, and be measured

• Own domain for both the client and the WebSocket, with its own certificate — off vercel.app and off duel.sudoky.net.
• Server-rendered or prerendered HTML for the landing page and for each game's page, carrying real Russian text: what the game is, how it is played here, why this table is fair.
• The sitemap lists only URLs that render content.
• Yandex Metrika installed. Today we cannot tell whether anyone visits at all.
• CI that runs typecheck and test on every push.

Exit: curl on /, /games/durak and /games/checkers each return ≥1,500 characters of body text with distinct titles; the domain serves the client over HTTPS and the socket over WSS; Metrika reports a nonzero session count; a red test blocks a push.

1–20 Sep P1 · The zero-liquidity funnel

• From a cold landing, one click starts a match against a visibly labelled bot — no account, no lobby wait, both games.
• An invite link opens a private room and seats the second player, on mobile, without an account.
• A dropped socket restores the same seat in the same match rather than forfeiting.

Exit: from a cold visit, first move against a bot inside 10 seconds; an invite link opened in a second browser seats that player; killing the socket mid-match and reconnecting restores the seat with the position intact — demonstrated, not asserted.

Corrected 17 Aug, after reading the client instead of the health endpoint. Most of this phase is already built: App.tsx offers practice, private and quick modes, private tables already mint an invite link with a copy button and a room code read from the query string, and useRealtime.ts already persists a resume token and rejoins an active match. I had scoped this phase from the docs and the health payload, and it was wrong to assume the mechanics were missing.
What the real gap turned out to be: the prominent button on the lobby is «Играть с людьми», which at zero liquidity is a queue nobody will ever fill, while the one action that works today — the labelled bot — is the quieter one below it. So this phase is not "build bot play"; it is making the path that functions the default, and giving the queue an honest exit that offers a bot explicitly rather than substituting one silently. Briefed 17 Aug.

21 Sep – 15 Oct P2 · Keep the fairness promise

• 128-bit seed from a CSPRNG, replacing the 31-bit integer.
• A commitment (hash of seed plus deck) published to both players before the deal.
• The seed revealed at match end, with a public verifier page that re-derives the deal from the published data.

Exit: a third party, given only what the match published, can confirm the deal was fixed before play began; a test asserts commitment and reveal agree; the claim «играем по-честному» links to the verifier. If this slips, the claim comes off the page until it ships.

Shipped 17 Aug, ahead of schedule — and the scope is narrower than this phase assumed. The server side is done and verified (commits 8a073d8, 817a5f0): a 128-bit CSPRNG seed, a deal_commitment published before any hand state, a deal_reveal released only once the match phase is over, and a test that re-derives every hand, the remaining deck and the trump from the revealed seed. It fails if the server deals from a seed it did not commit to — verified independently by mutation, not taken on report.
What that does and does not let a player claim. From the wire, a player can verify their own hand and the trump after the reveal. Nobody can yet audit a whole match from outside, because no end-of-match transcript publishes every initial hand and the draw order. That is acceptable for the promise we actually want to make — «проверьте свою раздачу», verify the deal you were dealt — and the full transcript is deferred to P5. The copy must say the narrower thing. Claiming auditability we do not have would be the same failure as the unbacked title tag this phase existed to fix.

16 Oct – 15 Nov P3 · Yandex Games

• SDK integrated; progress persisted through it; language auto-detected; sound suspended on tab switch and during ads; zero JS errors in the console.
• Both games submitted, with two moderation rejection cycles budgeted.

Exit: both games reachable from their own Yandex Games catalogue URLs, and the first session from that channel visible in Metrika.

Re-planned 17 Aug and pulled forward — checkers first, and without an external host. Yandex Games declares external hosts separately, reviews them, refuses a host that carries most of the game data, and will not accept a bare IP or a port. Our socket lives on duel.sudoky.net, which belongs to another product and which the repo already wants to leave. So a submission that depends on it is gated on the domain.
It does not have to be. packages/checkers-engine exports chooseBotMove(state, playerId, difficulty, random) with all three levels, so Russian checkers runs entirely in the browser — rules, bot, mandatory capture, promotion — with no socket, no declared host and no review of someone else's hostname. Дурак cannot follow yet: its bot lives in realtime.gateway.ts, server side, so an offline Дурак needs that logic lifted into durak-engine first. That is a later task, not a blocker.
So the channel opens on checkers alone, and it is blocked on nothing. Briefed 17 Aug: an offline checkers build with the SDK, progress persistence, language auto-detection and the sound rules, packaged by a reproducible command. Submission itself needs the operator's Developer Console account.

16 Nov – 15 Dec P4 · Depth, gated on a number

Two candidates, and the choice is made by data rather than by preference:

• If ≥25% of visitors who finish a match return within 7 days — build нарды (113,231/mo). Retention says the format works and breadth compounds.
• If not — do not add a game. Add Дурак variants (переводной, классический) to match the incumbent's three, and fix whatever the funnel data says is leaking. A second game with no retention only splits an empty lobby.

Exit: the decision is recorded with the number that drove it, and the chosen work ships.

16–31 Dec P5 · Durability and the year-end read

• Either matches survive a worker restart, or the limit is stated honestly in the product.
• A load test against the documented ceilings (1,000 sockets, 500 rooms, 128 MB heap).
• A written read of the numbers: sessions, matches, completion rate, 7-day return, channel mix.

Exit: the load test's actual figures are published in docs/MULTIPLAYER.md, and the year-end read exists as a document.