@@ -9,6 +9,22 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Changed
+
+- **Folded the real wasm frontend build into `v0.8.0 "Instrumentation"`'s scope, per explicit
+  direction.** The user compared RustySNES's live Pages demo against RustyNES's working one and
+  found it renders a blank page — root-caused to `crates/rustysnes-frontend/src/wasm.rs` being
+  an explicitly-labeled scaffold stub since `v0.1.0` (installs a panic hook, logs one message,
+  returns — never builds the app or creates a canvas). Every prior "wasm demo is live"
+  verification (`v0.1.0`-`v0.6.0`) checked only HTTP-level liveness, never that the app actually
+  renders. Scoped as two stages ported from RustyNES's own proven shape (`wasm.rs`/
+  `wasm_winit.rs`, confirmed by reading the source directly): a `wasm-canvas` MVP first (canvas-2D
+  blit, no `wgpu`/`egui`, ships a real working demo fast), then `wasm-winit` unification (routes
+  wasm through the same `App` native uses — requires un-gating `app.rs`/`audio.rs` from their
+  current `wasm32` exclusion, a real architectural gap, not just plumbing).
+  `to-dos/VERSION-PLAN.md`'s `v0.8.0` section, `to-dos/phase-8-reach/overview.md`, and
+  `sprint-1-instrumentation.md` (two new tickets, T-81-005/T-81-006) updated accordingly.
+
 ### Fixed
 
 - **`crates/rustysnes-frontend/web/index.html`: added the missing link to `/api/` on the live
 
@@ -402,13 +402,15 @@ established discipline:
   opportunistic posture already established across four prior releases; don't gate a rung on
   finding ROMs that may never become available.
 
-### v0.8.0 "Instrumentation" — debugger, scripting/TAS, cheats
+### v0.8.0 "Instrumentation" — debugger, scripting/TAS, cheats, the real wasm frontend
 
 One coherent theme: tooling that inspects and manipulates emulator state, all sharing the same
-memory-watch/introspection substrate. This is the first rung of the breadth pass — RustySNES's
-own crate manifest already anticipated it (`crates/rustysnes-frontend/Cargo.toml`'s `debug-hooks`/
-`scripting` flags, present since the frontend's first cut, "mirroring the RustyNES feature
-surface so the chip-implementation phase can switch them on without restructuring the manifest").
+memory-watch/introspection substrate — plus the wasm frontend build, folded in here per explicit
+direction after the live demo page was found rendering blank (see below). This is the first rung
+of the breadth pass — RustySNES's own crate manifest already anticipated the tooling half
+(`crates/rustysnes-frontend/Cargo.toml`'s `debug-hooks`/`scripting` flags, present since the
+frontend's first cut, "mirroring the RustyNES feature surface so the chip-implementation phase
+can switch them on without restructuring the manifest").
 
 - **Debugger overlay** — fills in `ui_shell.rs`'s already-wired 65C816/PPU/APU/Cart panels
   (currently `"TODO(impl-phase)"` placeholders) behind the existing `debug-hooks` flag; the
@@ -426,6 +428,43 @@ surface so the chip-implementation phase can switch them on without restructurin
   fundamentally memory-watch/poke tooling, the same substrate as the debugger's memory panel —
   grouped here rather than with netplay/RetroAchievements for that reason. Adds a new `cheats`
   feature flag matching the existing naming convention.
+- **The real wasm frontend** — `crates/rustysnes-frontend/src/wasm.rs` has been an explicitly-
+  labeled scaffold stub since `v0.1.0` (installs a panic hook, logs one message, returns — never
+  builds the `App`, creates a wgpu canvas surface, or drives a render loop), making the live
+  `https://doublegate.github.io/RustySNES/` demo a blank page despite every prior "wasm demo is
+  live" CHANGELOG claim (`v0.1.0`-`v0.6.0`) being true only at the HTTP level (200 status,
+  correct content-types) — found live by direct comparison against RustyNES's own working wasm
+  deployment, not by CI (`pages.yml` only asserts the build/deploy steps succeed, never that the
+  resulting app actually renders). `rustysnes-frontend/Cargo.toml`'s `wasm-winit` (default) /
+  `wasm-canvas` feature split already anticipated exactly the two-stage build RustyNES itself
+  used to reach a working wasm frontend (confirmed by reading RustyNES's `wasm.rs`/`wasm_winit.rs`
+  source directly, not inferred): a `wasm-canvas` MVP first (a `CanvasRenderingContext2d`
+  `putImageData` blit of the RGBA8 framebuffer + a `requestAnimationFrame` loop + keyboard via DOM
+  events + ROM load via `<input type="file">` — no `wgpu`/`egui`, ~500 lines in RustyNES's
+  `wasm.rs`), then `wasm-winit` unification as a larger follow-up (routes wasm through the *same*
+  `App`/`ApplicationHandler` native already uses, via
+  `winit::platform::web::EventLoopExtWebSys::spawn_app` + an `EventLoopProxy` delivering
+  `RomLoaded`/`GfxReady`-style events in from JS — RustyNES's own `app.rs` states "the `ApplicationHandler` impl serves both
+  native and wasm32," proving this reuse is architecturally sound, not aspirational). **Real,
+  confirmed gap, not just plumbing:** RustySNES's `app.rs` and `audio.rs` are currently
+  `#[cfg(not(target_arch = "wasm32"))]` — entirely excluded from the wasm build today, not merely
+  unused; `gfx.rs` has zero `wasm32`/`web_sys`/canvas references yet. Un-gating and adapting them
+  (swapping `cpal` for Web Audio behind a conditional path, gating out native-only deps like
+  `gilrs`/`directories`) is the same real work RustyNES needed for its own `wasm_winit.rs`
+  follow-up, not a small addition. Minimal wasm-canvas-MVP subsystem list, RustyNES file
+  (line count) → RustySNES port target: canvas-2D entry (`wasm.rs`, 538) → replaces the current
+  stub; audio (`wasm_audio.rs`, 456) → AudioWorklet primary + ScriptProcessorNode fallback, no
+  `SharedArrayBuffer` since GitHub Pages can't send COOP/COEP headers, reuses the same DRC/
+  resampler logic already in native `audio.rs`; gamepad (`wasm_gamepad.rs`, 64) → trivial,
+  `navigator.getGamepads()` polled from JS + one bridge fn; file I/O (`wasm_io.rs`, 345) → the
+  `<input type="file">` + generic save-file-with-fallback helper. **Explicitly out of scope for
+  this rung** (RustyNES's own Phase-8-equivalent reach features, needed only once RustySNES's
+  native equivalents exist, not as a wasm-specific prerequisite): `wasm_idb.rs` (IndexedDB
+  save-state persistence — native save-states already work, can defer), `wasm_save_states.rs`,
+  `wasm_touch.rs` (mobile touch overlay), `wasm_lobby.rs`/`wasm_netplay.rs` (netplay lobby UI —
+  belongs with `v0.9.0`'s netplay work instead), `wasm_script.rs`/`wasm_cheevos.rs` (wire once
+  this rung's own native scripting/`v0.9.0`'s cheevos land), `wasm_share.rs` (settings
+  share-links).
 - **Recurring gate, starting here:** a byte-identical-with-all-flags-off CI check (every new
   flag landed on this ladder must leave the default build unchanged) — re-verify after `v0.9.0`
   and `v1.0.0` too. Use explicit feature combos in CI, never `--all-features`.
 
@@ -13,6 +13,13 @@ RustyNES front-loaded this exact breadth into its own v1.0.0, and matching that
 stay genuinely post-`v1.0.0` Reach — polish items with no accuracy-adjacency, matching how
 RustyNES itself treated them.
 
+**Folded in after `v0.7.0`, per explicit direction:** the real wasm frontend build.
+`crates/rustysnes-frontend/src/wasm.rs` has been a scaffold stub since `v0.1.0` — it never
+builds the actual app, so the live Pages demo renders blank despite every prior "wasm demo is
+live" claim being true only at the HTTP level. Found live by direct comparison against
+RustyNES's own working wasm deployment, not by CI. Ported from RustyNES's proven two-stage
+shape (`wasm-canvas` MVP, then `wasm-winit` unification) — see Sprint 1 below.
+
 ## Exit criteria
 
 - [ ] Debugger overlay (65C816/PPU/APU/Cart panels, including SA-1/Super FX coprocessor state
@@ -25,6 +32,11 @@ RustyNES itself treated them.
       full-snapshot design is fast enough for a real rollback window.
 - [ ] RetroAchievements (opt-in, native FFI, the `RustySNES/<ver> rcheevos/<ver>` User-Agent
       pattern).
+- [ ] The real wasm frontend: a `wasm-canvas` MVP (canvas-2D blit, `requestAnimationFrame`,
+      keyboard, ROM load) landed first for a fast working demo, then `wasm-winit` unification
+      (the same `App` native uses, via `EventLoopExtWebSys::spawn_app`) — both ported from
+      RustyNES's proven shape, verified by a real headless-browser render check, not just an
+      HTTP status check.
 - [ ] Every feature off by default; with all off, builds are byte-identical (a CI gate proves
       it, re-verified after each sprint below).
 - [ ] All sprints complete; `v1.0.0` cut prerequisites met (`to-dos/VERSION-PLAN.md`'s v1.0.0
@@ -35,8 +47,14 @@ RustyNES itself treated them.
 In-scope:
 
 - The five breadth feature families above, each default-off and byte-identical-when-off.
+- The real wasm frontend build (two stages — `wasm-canvas` MVP, then `wasm-winit`
+  unification), which requires un-gating `app.rs`/`audio.rs` from their current
+  `#[cfg(not(target_arch = "wasm32"))]` exclusion — a real, confirmed architectural gap, not
+  just plumbing (see Sprint 1's T-81-005/T-81-006 for the full breakdown).
 - The `Board: Send` fix `emu-thread` needs (a prerequisite for `v1.0.0`'s dedicated emulation
   thread, tracked here since it's discovered/fixed alongside this phase's instrumentation work).
+  Unrelated to the wasm-winit unification above — `emu-thread` is a native-only, single-player
+  dedicated-thread feature; wasm's own event loop is a separate concern.
 
 Out-of-scope (post-`v1.0.0` Reach, `to-dos/VERSION-PLAN.md`):
 
@@ -47,8 +65,8 @@ Out-of-scope (post-`v1.0.0` Reach, `to-dos/VERSION-PLAN.md`):
 
 ## Sprints
 
-- [Sprint 1 — Instrumentation](sprint-1-instrumentation.md) — debugger, scripting/TAS, cheats.
-  Maps to `v0.8.0 "Instrumentation"`.
+- [Sprint 1 — Instrumentation](sprint-1-instrumentation.md) — debugger, scripting/TAS, cheats,
+  the real wasm frontend (two stages). Maps to `v0.8.0 "Instrumentation"`.
 - [Sprint 2 — Community](sprint-2-community.md) — rollback netplay, RetroAchievements. Maps to
   `v0.9.0 "Community"`.
 
@@ -81,6 +99,12 @@ Phase 5 (the frontend + the exercised determinism contract); Phases 1–4 featur
   frontend-orchestrated resimulation model. Mitigate by keeping the two mutually exclusive by
   session type (a netplay session uses its own rollback-aware loop, never the generic
   `emu-thread` pacer) rather than trying to unify them.
+- **The wasm frontend shipping unverified again** — the root cause of the original stub going
+  unnoticed since `v0.1.0` was that every prior check (`pages.yml`, this project's own CHANGELOG
+  claims) only asserted the build/deploy pipeline succeeds, never that the resulting page
+  actually renders. Mitigate by requiring a real headless-browser render check (Playwright/
+  Chromium: assert a canvas exists and receives non-zero pixel data) as an explicit acceptance
+  criterion for both T-81-005 and T-81-006, not just a build-success check.
 
 ## Reference docs
 
 
@@ -2,8 +2,9 @@
 
 **Phase:** Phase 8 — Instrumentation + Community
 **Sprint goal:** the debugger overlay, Lua scripting + TAS movie API, and cheat-code support
-ship behind default-off feature flags, each byte-identical with the feature off.
-**Estimated duration:** 3 weeks
+ship behind default-off feature flags, each byte-identical with the feature off; the wasm
+frontend goes from a scaffold stub to a genuinely working demo.
+**Estimated duration:** 3 weeks (native tooling) + 2-3 weeks (wasm frontend, two stages)
 **Release mapping:** `v0.8.0 "Instrumentation"` (`to-dos/VERSION-PLAN.md`)
 
 ## Tickets
@@ -94,8 +95,79 @@ feature combo (never `--all-features`).
 
 ---
 
+### T-81-005 — The real wasm frontend, stage 1: `wasm-canvas` MVP
+
+**Description:** replace `crates/rustysnes-frontend/src/wasm.rs`'s scaffold stub (panic hook +
+one log line, never renders anything) with a working canvas-2D MVP behind the existing
+`wasm-canvas` flag, porting RustyNES's proven shape
+(`../RustyNES/crates/rustynes-frontend/src/wasm.rs`, not inventing a new approach): a
+`CanvasRenderingContext2d.putImageData` blit of the existing RGBA8 framebuffer
+(`emu.rs::framebuffer()` already produces this — no PPU/core changes needed), a
+`requestAnimationFrame` loop, keyboard input via DOM `keydown`/`keyup` events, ROM loading via
+`<input type="file">`, and audio via `AudioWorklet`/`ScriptProcessorNode` (ported from RustyNES's
+`wasm_audio.rs`, reusing the native DRC/resampler core — see the acceptance criteria below). No
+`wgpu`/`egui` — this stage proves a real, visible, playable demo exists fast, without needing
+`app.rs`/`audio.rs` un-gated for wasm32 yet. Ships to the live Pages deployment as soon as it
+lands, closing the actual user-facing gap (a blank demo page) even before stage 2 (T-81-006) is
+ready.
+
+**Acceptance criteria:**
+
+- [ ] The live demo shows a real picture and accepts keyboard input for a loaded ROM.
+- [ ] Audio plays via `AudioWorklet` (primary) with a `ScriptProcessorNode` fallback — no
+      `SharedArrayBuffer` (GitHub Pages can't send COOP/COEP headers), reusing the same DRC/
+      resampler logic `audio.rs` already has for native.
+- [ ] Verified with a real headless-browser load (e.g. Playwright/Chromium), not just an HTTP
+      200 check — assert a canvas element exists and receives non-zero pixel data after loading
+      a ROM. `pages.yml`'s existing verification only checks the build/deploy steps succeed;
+      this is the gap that let the stub ship unnoticed since `v0.1.0`.
+- [ ] `pages.yml` updated if the trunk build target/feature selection needs to change.
+
+**Dependencies:** none beyond what already exists (`emu.rs::framebuffer()`, existing keyboard/
+ROM-load native code as the porting reference)
+**Reference:** `../RustyNES/crates/rustynes-frontend/src/wasm.rs` (538 lines, the port source);
+`docs/frontend.md` §wasm
+**Estimated complexity:** L
+
+---
+
+### T-81-006 — The real wasm frontend, stage 2: `wasm-winit` unification
+
+**Description:** route the wasm build through the *same* `App`/`ApplicationHandler` native
+already uses, replacing the stage-1 canvas-2D path as the default (`wasm-winit` is already the
+default feature in `Cargo.toml`), via `winit::platform::web::EventLoopExtWebSys::spawn_app` +
+an `EventLoopProxy` delivering `RomLoaded`/`GfxReady`-style events in from JS — the exact shape
+RustyNES's `wasm_winit.rs` (254 lines) already proves works, ported not invented. Requires
+un-gating `app.rs` and `audio.rs` from their current `#[cfg(not(target_arch = "wasm32"))]`
+exclusion and adapting them for wasm32 (swap `cpal` for Web Audio behind a conditional path,
+gate out native-only deps — `gilrs`, `directories`, direct `std::fs`). This is the real work;
+stage 1 (T-81-005) deliberately avoids needing it so a working demo ships sooner.
+
+**Acceptance criteria:**
+
+- [ ] The same `App`/egui UI (menu bar, Settings, debugger panels once T-81-001 lands) renders
+      in the browser via wgpu, not just the stage-1 canvas blit.
+- [ ] `app.rs`/`audio.rs` compile and run for both native and `wasm32` targets from the same
+      source, matching RustyNES's own "`ApplicationHandler` impl serves both native and wasm32"
+      pattern.
+- [ ] Verified with the same real headless-browser check as T-81-005, re-run against the
+      winit/wgpu path.
+- [ ] With `wasm-canvas` (not `wasm-winit`) selected instead, the stage-1 MVP still builds and
+      works — the two paths stay independently functional, matching the manifest's existing
+      "exactly one is compiled" comment.
+
+**Dependencies:** T-81-005 (ships the interim working demo first); `Board: Send` is NOT required
+here (that's `v1.0.0`'s native `emu-thread` prerequisite, a separate, unrelated flag)
+**Reference:** `../RustyNES/crates/rustynes-frontend/src/wasm_winit.rs` (254 lines, the port
+source); `../RustyNES/crates/rustynes-frontend/src/app.rs`'s `ApplicationHandler` doc comment
+**Estimated complexity:** L
+
+---
+
 ## Sprint review checklist
 
 - [ ] All tickets checked off or explicitly deferred (with reason).
 - [ ] Every instrumentation feature is off by default + byte-identical when off.
+- [ ] The live wasm demo actually renders and is playable, verified by a real headless-browser
+      check, not just an HTTP status check.
 - [ ] CHANGELOG.md updated.