[maidulcu]

Our own privacy-safe bug tracking and usage counts for the online edition (instead of Sentry or any third-party tracker). The free GitHub Pages edition sends nothing.

What it does

• Daily counts, not people: POST /api/events adds 1 to day counters such as visits by device/OS/browser family, game version, mode, and features used (Play Together, Bit, Photo Mode, courses, quests, circuits, accounts…). Each is counted at most once per browser session.

• Problem reports: POST /api/errors keeps three kinds:

  • 💥 error: uncaught errors and unhandled promise rejections;
  • 🧊 freeze: the game stopped drawing for more than 5 s while on screen (hidden-tab pauses are ignored);
  • 🙋 report: the new 🐞 Report a problem menu button, with a fixed list of categories (no typing).

  Each keeps the message, place, game version, browser/device family, screen size and the last 12 game steps (e.g. opened Bit's panel → Bit run). Identical reports are grouped per day and deleted after 90 days.

• Stats page: stats.html (noindex, kept out of robots.txt) asks for the key and shows totals, devices, systems, browsers, modes, features, versions, visits per day and the problem list with steps.

Privacy

• No cookies, no IDs, no fingerprinting, no IP addresses stored (held in memory for one minute for rate limiting).
• Same-origin only, rate-limited, input whitelisted and length-capped.
• GET /api/stats needs Authorization: Bearer $STATS_TOKEN. Without the token it's closed.
• Only runs when site-config.json has "online": true and "insights": true. The copy in Git doesn't, so GitHub Pages never sends anything.
• Privacy Policy: new section 6, "Anonymous usage counts and problem reports (online edition)", plus a line in the kids' summary. Version date unchanged (2026-11-10, same day). The Terms didn't change, so TERMS_VERSION is untouched.

Also: fix the iPhone freeze when launching Bit

Cause: iOS Safari has no Pointer Lock API, so document.exitPointerLock is undefined there. openRobotPanel() called it bare from inside the frame loop. The TypeError stopped frame() before it asked for the next frame, so the whole game froze and Bit sat at "Running… step 0". Trading with a villager and fainting in survival had the same bare call inside the loop.

Fix:

• exitLock() guards every call.
• frame() now asks for the next frame first, so one error can never stop the game.
• New smoke check: no bare exitPointerLock() in src/.
• sw.js → minicrafter-v29.

Reproduced and verified with Playwright WebKit, iPhone 13 (landscape) emulation and ?touch=1 against the dev server: place Bit, tap it, tap ▶ Run. Before the fix: the TypeError above and the game stuck at step 0. After it: Bit runs all 16 steps to "All done!".

Other changes

• tools/deploy-site.sh uploads stats.html and the "insights": true config.
• server/docker-compose.yml passes STATS_TOKEN; server/Dockerfile copies stats.mjs; server/README.md documents insights.

Testing

• SMOKE_CHANNEL=chrome node tests/smoke.mjs: all checks pass, including the new ones:
  • a visit and a problem report (with steps) reach the dev server, and /api/stats refuses access without the key;
  • insights stay off in the free edition.
• By hand against node server/dev.mjs: visit counts, a thrown error, a forced 6 s freeze and a "Bit isn't working" report all showed up with steps on stats.html (key dev). The free copy made no /api requests.
• Already deployed to the online edition: /api/events returns 204 (403 from another origin), /api/stats returns 401 without the key and 200 with it, and a real visit landed in the counters.

🤖 Generated with Claude Code