PHASE 351

SVR Poker Website Development Roadmap

This sequence separates completed web systems, current acceptance work, infrastructure blockers, native-app blockers, and the future Unity migration.

Current release truth

MERGEDGame runtime through Phase 350
ACTIVEPhase 351 profile 3D showroom and dressing-room identity
BLOCKEDProduction account and presence databases until approved HTTPS backends are deployed
BLOCKEDAPK RC2 until the original wrapper and signing identity are restored

Completed foundation

  • Responsive public website and Matrix-rain visual system
  • Android, Quest/PC, and Camera 3 routes
  • Authoritative local poker ledger and full local hand flow
  • Single Android controller authority and visible table cards
  • Account/profile client with labeled demo fallback
  • Avatar creator, saved outfits, and in-game local avatar
  • Presence and seat-lease contracts
  • Canonical site navigation audit
  • Manual-only APK update policy

Phase 351 — Profile 3D Showroom

  1. Replace the small portrait with a full in-game-style room.
  2. Load the same Eric/Claudia body and saved outfit used by the game.
  3. Add orbit, zoom, rotation, reset, fullscreen, and dressing-room controls.
  4. Keep a visible fallback if WebGL, Three.js, or FBX loading fails.
  5. Preserve profile, rewards, balance, and account controls.

Next infrastructure milestone

Phase 352 — Production Account Deployment

  1. Deploy the Phase 345 account API to an approved HTTPS host.
  2. Run the Azure SQL player migration.
  3. Configure secrets outside GitHub.
  4. Add email verification, password reset, device sessions, privacy controls, and account deletion.
  5. Verify login across Android, Quest, PC, and the profile showroom.

Social milestone

Phase 353 — Live Presence and Social Lobby

  1. Deploy the Phase 349 presence API and seat migration.
  2. Test multiple authenticated devices in one room.
  3. Add friends, invitations, private-room codes, mute, block, and report.
  4. Show online, offline, and reconnecting state.
  5. Keep Camera 3 spectator-only.

Commerce and content

Phase 354 — Store, Inventory, and Publishing

  1. Connect store catalog and cart to approved services.
  2. Populate avatar clothing inventory from database records.
  3. Add news, schedules, promotions, sponsor placements, and donation reporting.
  4. Replace placeholder content with approved production copy.

Game authority

Phase 355 — Server-Authoritative Poker Rooms

  1. Move deck, cards, turns, bets, pots, and winners to secure server authority.
  2. Add reconnectable table snapshots and action logs.
  3. Prevent client-side balance manipulation.
  4. Run multi-device hand and disconnect tests.

Native Android release

Phase 356 — APK RC2

  1. Restore the exact RC1 wrapper source.
  2. Recover the original signing identity securely.
  3. Build and test version code 2 as an in-place upgrade.
  4. Publish checksum and approved download URL.
  5. Enable only the optional update menu during the approved release window.

Unity migration

Phase 357 — Shared Production Blueprint

  1. Freeze APIs for accounts, profiles, inventory, presence, rooms, and poker.
  2. Convert approved FBX assets to optimized GLB and Unity-ready formats.
  3. Define Unity scenes, prefabs, networking authority, input adapters, and budgets.
  4. Reuse the same identity and avatar records.

Release decision rules

  • No feature is production-ready until CI and device/browser acceptance pass.
  • No database secret, signing key, private key, or password is committed to GitHub.
  • No APK update is visible until a signed package, checksum, and upgrade test exist.
  • No local simulation is described as internet multiplayer.
  • Canonical navigation failures block deployment.