A 2-3 minute walkthrough of BugSmasher's gameplay, architecture, and testing strategy. Video recording pending — script ready in demo-scripts/bugsmasher-demo-script.md
Server-authoritative leaderboards: Client never writes scores directly — all competitive writes go through Firebase callable paths with one-time session tokens. Quality gates in CI: tests and coverage are tracked in repo docs/STATUS.md — the project is not currently certified. Accessibility as gameplay: Keyboard-first, reduced-motion, colorblind modes built-in. Offline-first PWA: Cloud sync via Firebase, works without network.
01 The challenge
Browser arcade games are easy to demo and hard to trust. Two problems dominate: competitive integrity (a client-side score is trivially forgeable) and quality confidence (fast-moving game code rots without a test net).
BugSmasher set out to be an actively hardened project, not a throwaway demo. That meant treating the leaderboard as a security surface and treating the codebase as something that must prove itself on every change — while keeping the game genuinely fun and accessible.
02 Server-authoritative leaderboards
The core anti-cheat decision: the client never writes a score directly. All competitive writes go through server-authoritative Firebase callable paths.
- Authenticated writes only — score submission requires a signed-in user; anonymous or forged submissions are rejected.
- One-time session tokens — the server issues a score session token that is user-bound, expires, and is atomically consumed on use.
- Replay-proof — because each token can be consumed exactly once, a captured submission cannot be replayed to inflate a score.
- Schema validation + server checksums + rate limiting — payloads are validated server-side and throttled to blunt automated abuse.
Firebase emulator tests explicitly cover the attack paths: replay, token expiry, cross-user token use, and score plausibility checks.
This is strong baseline protection, not a claim of perfect anti-cheat. Authoritative gameplay-run summaries and full replay verification remain future hardening if competitive integrity demands them.
03 A verification baseline you can audit
Quality is enforced through layered gates in CI, not by vibes. The numbers below are the documented baseline in docs/STATUS.md (2026-08-30, main @ bbc7250) — not a live certification.
| Signal | Result |
|---|---|
| Certification | NOT CERTIFIED 10/10 |
| TypeScript | PASS |
| ESLint | PASS — 0 errors / 910 warnings |
| Functions build + unit tests | PASS (6/6) |
| Frontend tests | 752/752 PASS (40 files) |
| Coverage | 81.70% lines / 85.99% functions (floors enforced) |
| Firebase emulator | PASS (26/26) |
| Production build | PASS |
| Playwright E2E | PASS (5/5) |
| npm audit (prod deps) | 0 vulnerabilities |
Older “651 tests / failing emulator / Playwright skipped” figures (2026-08-26 snapshot) are superseded. Fresh counts live in the repo ledger.
04 Accessibility & performance
An arcade game should be playable by everyone, on any device, without melting a low-end phone.
- Keyboard-first navigation with ARIA support throughout the UI.
- Player-controlled difficulty, reduced-motion, and colorblind modes — accessibility as gameplay options, not an afterthought.
- Adaptive rendering & VFX controls plus mobile-aware canvas scaling for performance headroom.
Full WCAG 2.2 AA evidence-backed verification is still underway. The foundations are in place; the final certification gate is on the roadmap rather than claimed as done.
05 Architecture & supply-chain hygiene
- Modular systems — combat/bug behavior, audio, and typed renderers are extracted behind clean dependency seams.
- AI-assisted engineering workflow — agent rules and skills documented in AGENTS.md and .agents/.
- Dependency security — Dependabot and CodeQL configured, plus a blocking npm audit --audit-level=high workflow for root and Functions dependencies.
- Deep documentation — architecture, deployment, security model, changelog, and a task board to 10/10 all live in the repo.
Canvas 2D Renderer
WebAudio SFX
Firestore Persistence
Offline Queue
Cloud Functions
Firestore Rules
System architecture: frontend → state → backend
06 What is deliberately not done yet
A credible case study names its gaps. Until real providers and operational/legal controls are in place, these remain intentionally out of scope:
- Paid monetization / payment processing
- Advertising
- Production analytics & telemetry consent
- Crash reporting and runtime alerting
- Final WCAG 2.2 AA evidence gate
- Final 80/80/75/70 coverage gate
The project does not claim these capabilities are live merely because integration stubs exist in the source tree.