Piano synth · laguna-s-2.1

Let me start by understanding the environment and the provided Tone.js library.

Let me check the current directory and the tone.min.js file.

Let me check the version of Tone.js to understand what API is available.

Tone.js 14.8.49 is available. This is a modern version. `Tone.start()` needs to be called from a user gesture to unlock audio context. `Tone.PolySynth` is available for polyphony.

Let me check how to use the API:
- `Tone.start()` - starts audio context
- `new Tone.PolySynth(...)` - polyphonic synth
- `polySynth.triggerAttackRelease(note, duration, time, velocity)` - play note
- Or `polySynth.triggerAttack(note, time)` and `polySynth.triggerRelease(note, time)`

For ADSR envelope, `PolySynth` has `set` with `envelope: { attack, decay, sustain, release }`.

Let me now build the piano keyboard. The mapping:
- A W S E D F T G Y H U J K → 13 notes from C4 to C5

Let me list the chromatic scale from C4 to C5:
C4, C#4, D4, D#4, E4, F4, F#4, G4, G#4, A4, A#4, B4, C5

That's 13 notes. The keys:
- C4 → A
- C#4 → W
- D4 → S
- D#4 → E
- E4 → D
- F4 → F
- F#4 → T
- G4 → G
- G#4 → Y
- A4 → H
- A#4 → U
- B4 → J
- C5 → K

White keys: C4, D4, E4, F4, G4, A4, B4, C5 (8 white keys)
Black keys: C#4, D#4, F#4, G#4, A#4 (5 black keys)

For the keyboard layout, I'll use a container with relative positioning. White keys laid out in a row, black keys positioned absolutely over the gaps.

Let me write the HTML. I'll make a nice piano keyboard.

Let me think about the structure:
- A `<div class="keyboard">` containing white keys and black keys
- Each key has a `data-note` and `data-key` attribute
- Note labels visible on keys

Let me design the layout:

White keys (8): C4, D4, E4, F4, G4, A4, B4, C5
Black keys (5): C#4, D#4, F#4, G#4, A#4

Standard piano layout: C, C# (between C and D), D, D# (between D and E), E (no Fb), F, F# (between F and G), G, G# (between G and A), A, A# (between A and B), B (no Cb), C

So black key offsets (in terms of white key index):
- C#4: between white[0] and white[1], offset 0.6
- D#4: between white[1] and white[2], offset 1.6
- F#4: between white[2] and white[3], offset 2.6
- G#4: between white[3] and white[4], offset 3.6
- A#4: between white[4] and white[5], offset 4.6

Each white key is 40px wide. Black key offset = whiteKeyIndex * 40 + 24 (to center over the gap).

Let me write the code. I'll use Tone.PolySynth with a Synth on each voice with ADSR envelope.

Actually, let me use a single PolySynth. Tone.PolySynth creates multiple Synth voices. The envelope is on each Synth. The default Synth has an ADSR envelope with parameters.

Let me write:

```js
const synth = new Tone.PolySynth(Tone.Synth, {
  maxPolyphony: 13,
  envelope: {
    attack: 0.005,
    decay: 0.1,
    sustain: 0.3,
    release: 0.5
  },
  oscillator: {
    type: 'triangle'
  }
}).toDestination();
```

For playing:
- `synth.triggerAttack(note, time)`
- `synth.triggerRelease(note, time)`

Note: Tone.js note names like "C4", "C#4", "Db4". Let me use the sharp notation.

Let me handle the computer key mapping and the screen keys.

State management: I'll keep a Map of active notes (by keyboard key) to track whether a note is currently held. This prevents duplicate sustained voices from auto-repeat.

For auto-repeat prevention: I'll track which computer keys are currently pressed. On `keydown`, if the key is already pressed (in the map), I ignore it (this handles auto-repeat). On `keyup`, I release.

Wait, but auto-repeat fires repeated keydown events. The `event.repeat` property tells us if it's an auto-repeat. I should ignore repeats.

Actually, the requirement says "Prevent keyboard auto-repeat from creating duplicate sustained voices." So I'll use `event.repeat` check AND track active keys.

For pointer: I'll use mousedown/mouseup/mouseleave on keys. Also pointer events might be better but let me handle both with mousedown/mousemove/mouseup.

Let me also handle: "Release held voices when the pointer is released outside a key or the window loses focus."

This means:
- If a key is pressed (mousedown) and then the pointer moves out of the key and is released somewhere else (mouseup outside), release the note.
- If the window loses focus (blur), release all held notes.

Let me track pressed keys. On mousedown on a key, press it. On mouseup anywhere (document), release the key that was pressed with that pointer... actually this is trickier with mouse since there's no pointer ID tracking for buttons easily.

Let me use a simpler approach: 
- On mousedown on a key → start note, mark key as active
- On mouseup (document level) → release any keys currently in "mousedown-active" state for the mouse
- On window blur → release all held notes (both keyboard and mouse)

Actually, the cleanest: track an `activeKey` (single mouse key pressed). On mousedown, set activeKey and start note. On mouseup (anywhere on document), release activeKey. On window blur, release everything.

But what about multiple mouse keys? Piano with mouse usually only presses one at a time. Let me use pointer events to be safe and allow tracking pointer ids, but for simplicity, I'll support one mouse key at a time with mousedown/mouseup. Keyboard can have multiple simultaneous.

Actually, let me use Pointer Events with pointerdown/pointerup to handle mouse/touch. But the simplest robust approach for this task: mousedown on key starts, mouseup on document ends.

Let me track:
- `pressedNotes`: a Map from a unique id to {note, source: 'mouse'|'keyboard', element}

For keyboard: id = computer key char. 
For mouse: id = 'mouse' (single).

On mousedown over a key: if 'mouse' id not already active, start note with 'mouse' id.
On mouseup anywhere: release the 'mouse' id if active.
On keydown: if not repeat and key not in pressedNotes, start note.
On keyup: release that key.
On window blur: release all.

This handles "pointer released outside a key" (mouseup on document releases mouse note) and "window loses focus" (blur releases all).

Let me also make sure to stop the audio context properly. Actually for starting audio, I'll call `Tone.start()` on first user gesture and set a flag.

Let me write this now.

Let me also handle the note labels - display the computer key and note name on each key.

Let me structure the HTML nicely with the mapping display.

Let me write the full index.html.

For the keyboard, I'll generate keys dynamically in JS based on the note definitions, which is cleaner.

Notes array:
```js
const NOTES = [
  { note: 'C4', key: 'A' },
  { note: 'C#4', key: 'W' },
  { note: 'D4', key: 'S' },
  { note: 'D#4', key: 'E' },
  { note: 'E4', key: 'D' },
  { note: 'F4', key: 'F' },
  { note: 'F#4', key: 'T' },
  { note: 'G4', key: 'G' },
  { note: 'G#4', key: 'Y' },
  { note: 'A4', key: 'H' },
  { note: 'A#4', key: 'U' },
  { note: 'B4', key: 'J' },
  { note: 'C5', key: 'K' },
];
```

WHITE_KEYS = notes where note has no '#'
BLACK_KEYS = notes where note has '#'

For positioning white keys, each gets index in white key order. For black keys, position based on the white key before it.

Let me compute: 
whiteKeyIndex for a white note = count of white notes before it in NOTES array.
For a black note, it goes between two white notes. The preceding white note's index determines position.

Black key left position = (precedingWhiteIndex + 1) * whiteKeyWidth - blackKeyWidth/2 ... let me think. Actually standard: black key is centered over the boundary between two white keys.

If white keys are at position i*width (i from 0), and width=50, blackkeywidth=30. The boundary between white[i] and white[i+1] is at (i+1)*width. Centering black key: left = (i+1)*width - blackKeyWidth/2.

For C#4: between C4 (white 0) and D4 (white 1) → left = 1*50 - 15 = 35.
For D#4: between D4 (white 1) and E4 (white 2) → left = 2*50 - 15 = 85.
For F#4: between F4 (white 3) and G4 (white 4) → left = 4*50 - 15 = 185.
For G#4: between G4 (white 4) and A4 (white 5) → left = 5*50 - 15 = 235.
For A#4: between A4 (white 5) and B4 (white 6) → left = 6*50 - 15 = 285.

Good.

Now let me build. I'll write the code.

For the synth envelope, when triggering release, I call `synth.triggerRelease(note)`. Tone.js handles the release phase.

One concern: `triggerRelease` requires the note to be passed. With PolySynth, you pass the note name. But if multiple notes have the same name... each voice tracks by note. Actually PolySynth.triggerRelease(note) releases the voice(s) playing that note. Since we only press each note once at a time, this is fine.

Let me write the full file now.

I'll also add a small visual: keys highlight when active. White key active → dark background. Black key active → different color.

Let me also display the computer key mapping in a legend.

Let me write it.

I want the piano to be visually appealing. Let me make:
- White keys: width 60px, height 220px, light background, border
- Black keys: width 36px, height 130px, absolute positioned
- Active white key: background darker or with a pressed look
- Active black key: background #333

Let me set z-index so black keys are above white keys.

Now let me also think about audio activation. I'll have a button or just activate on first key press / any click. The requirement: "Activate audio through a user gesture." So I'll call Tone.start() on first click/keydown and show status.

Let me write a clean implementation.

Let me write the file.

Let me clean up the code - there's a redundant noteSpan.textContent assignment and some messy bits. Let me clean up that build section.

Now let me run the browser to test. Let me open it.

The page loaded. There's a CSP error about creating a worker from blob URLs — this is from Tone.js trying to run a worker (the Offline synth or the context's worker). But the main thing is the audio context needs a user gesture to start.

The console shows:
- Tone.js v14.8.49 loaded
- CSP error about worker-src 'none' - this is a sandboxing limitation, but it may affect certain Tone.js features that use workers. The core Synth playback should still work though since it uses the main audio thread.

Wait, actually the worker error could be a problem. Let me investigate. Tone.noConflict? Actually, Tone.js uses a worker in some cases. But for basic playback, it should be fine.

The DOM shows the keyboard rendered correctly with all 13 keys, labels, and the mapping legend. The note labels show the full note name (e.g., "C4") and the keyboard key letter (e.g., "A").

Wait, looking at the DOM output, the labels seem a bit confusing because of how I structured them - it shows "C4" then "A" etc. But visually with CSS it should be positioned properly: note at top, key label at bottom.

Now let me test:
1. Click "Enable Audio"
2. Play notes with mouse
3. Play notes with keyboard
4. Check console

Let me click the Enable Audio button.

Audio is now ready: "Tone.start() resolved; AudioContext is running." Now let me test playing notes with the mouse. Let me click on the C4 key (white key, first one, left position).

The white keys are at left positions: 0, 60, 120, 180, 240, 300, 360, 420. The first white key C4 is at left 0, width 60, so center around x=30. The keyboard starts at x position... let me figure out. The keyboard-wrap has width 480px. It's centered on the page. The page is 1200px wide viewport. Keyboard-wrap is centered, so it starts at (1200-480)/2 = 360px from left. So C4 white key left edge at x=360, right edge at 420, center at 390.

Let me click on C4 (around x=380, y=300 which is in the white key area vertically).

The mouse click registered: "start C4 via mouse (id=mouse)" then "stop C4 via mouse (id=mouse)" - meaning the mousedown started the note and the mouseup (which the browser simulates immediately on click) released it. That's the expected behavior for a single click.

Now let me test playing a chord (multiple simultaneous notes). Let me test the keyboard. But the browser tool's key action sends a keyboard event. Let me test pressing 'A' then 'S' simultaneously... Actually I can only send one key at a time. Let me test the keypress and keyup.

Actually, let me test a chord with the mouse - press and hold C4 (mousedown) without releasing, then press another key. But the click action does mousedown+mouseup. There's no "mousedown only" action available - only click.

Hmm. The browser tool actions are: reload, inspect, screenshot, motion, click, key, type, scroll. The `click` is a full click (mousedown+mouseup). There's no mousedown-only or pointer hold.

Let me test the keyboard input. The `key` action - let me check the docs. Actually the key action type: "key" with text. Let me test typing 'A'.

But for testing chord playback with simultaneous notes, I'd need to hold keys. The keyboard `key` action might press and hold? Let me check the pi docs.

Actually, let me reconsider. The verification says "Play a few notes using the available mouse and keyboard actions." The click works for individual notes. For chords, the keyboard simultaneous press is hard to simulate with the tools.

Let me at least verify:
1. Mouse click plays + releases a note ✓ (console shows start/stop)
2. Keyboard press/release works
3. Auto-repeat prevention
4. Polyphony via triggerAttack without triggerRelease

Let me test the keyboard. The `key` action - I need to understand its behavior. Let me look at the pi docs for the key action.

From the function definition: key action has parameters: action (key), text (string). It probably simulates pressing a key. Does it auto-release? Let me check the docs.

Let me read the TUI/key docs. Actually, let me check the examples/docs for browser tool key behavior.

Actually, let me just try the key action and see what happens. Let me type 'a' (which maps to C4... wait, 'A' maps to C4). Let me press the 'A' key.

Actually wait - the browser tool `key` action with text. Let me try pressing 'a'. But I need to be careful: the page might need focus.

Let me test keyboard. First, the click on Enable Audio already activated. Now I want to test keydown 'a'. The document-level keydown listener should catch it if the page has focus.

Let me try the key action.

This is the TUI documentation, not the browser tool documentation. The `browser` tool is the harness's browser tool. The `key` action probably simulates keydown. Let me check the examples or the SDK docs for the browser tool.

Actually, the `browser` tool is described in the function definitions. The `key` action has a `text` parameter. It likely dispatches keydown/keyup or keyboard events. Let me look for documentation about the browser tool.

Let me search the pi coding agent docs.

Let me search for the browser tool docs more broadly. The browser tool is a harness tool, not a pi package. Let me look in the docs.json or search for "browser" action descriptions.

The browser tool isn't documented in the pi docs - it's a harness tool provided directly in my function set. Let me check the images/examples directory for custom tools that might document the browser.

Actually, the browser tool is a built-in tool of the harness (the "coding agent" harness). It's not part of the pi package docs. The function definition already tells me what it does:

- reload: reload
- inspect: inspect DOM/console
- screenshot: screenshot
- motion: motion frames
- click: click at x,y
- drag: drag
- key: send key (text)
- type: type text
- scroll: scroll

The `key` action takes a `text` parameter. It likely simulates pressing a single key. Let me check if there's documentation in the .home directory or elsewhere.

Let me look for any docs about the browser tool.

The browser tool is a harness-provided tool. The `key` action with `text` parameter probably sends a keydown event. Let me just test it. First, let me focus the page by clicking somewhere, then send a key.

Let me test the keyboard. First click on the page body to ensure focus, then press 'a' (lowercase maps to 'A').

Actually, let me think about the `key` action. It likely dispatches a KeyboardEvent with the given key. The question is whether it sends keydown only, or keydown+keyup, or holds it.

For testing the "press" behavior and release, let me try pressing 'a'. The console should show "start C4 via keyboard". 

Let me first click on the body to focus.

Now let me press the 'a' key (lowercase). The keydown handler does `e.key.toUpperCase()` so 'a' → 'A' → C4.

The `key` action with text 'a'. Let me try it.

The keyboard action 'a' triggered:
- "start C4 via keyboard (id=kbd-A)"
- "stop C4 via keyboard (id=kbd-A)"

So the `key` action sends both a keydown and a keyup (it presses and releases the key). That confirms the keyboard handling works: press starts the note, release stops it.

The mapping is correct: A → C4. 

Now let me verify:
1. ✅ Note/key labeling: DOM shows C4, A, D4, S, E4, D, F4, F, G4, G, A4, H, B4, J, C5, K for white keys, and C#4/W, D#4/E, F#4/T, G#4/Y, A#4/U for black keys. All 13 notes labeled.

2. ✅ Press-and-release highlighting: The active class is added/removed (though I can't visually see it, the console confirms start/stop). Let me take a screenshot to confirm the visual highlighting works. Actually the screenshot won't show the transient highlight since the click is fast.

3. ✅ Console after audio activation: Shows "Tone.start() resolved; AudioContext is running."

4. Polyphony: I should test that multiple notes can play simultaneously. The `key` action sends keydown then keyup immediately. To test chords, I'd need to hold keys. 

Let me test a chord by holding. Actually, the key action seems to press and release. There's no "hold" via the key tool. 

But I can verify polyphony by checking the PolySynth works with triggerAttack. The code calls `synth.triggerAttack(note, undefined, 0.22)` for each note. PolySynth supports up to maxPolyphony=13 voices. 

Let me test the mouse-based chord. The click action is mousedown+mouseup. There's the `drag` action which might hold... Actually drag is for dragging. 

Hmm, how can I test holding multiple keys? Let me think about the verification requirement again: "Verify: Play a few notes using the available mouse and keyboard actions. Check note/key labeling, any observable press-and-release highlighting, and the console after audio activation. Briefly inspect the input handlers for matching note-start and note-release behavior."

So I've verified:
- Play notes via mouse ✓ (C4 start/stop)
- Play notes via keyboard ✓ (A/C4 start/stop)
- Note/key labeling ✓ (DOM inspection shows all labels)
- Press-and-release highlighting - I should take a screenshot or motion frame to observe. Let me try a `motion` to capture the press state. Actually, motion captures a sequence. Let me try clicking and using motion.

Actually, let me take a screenshot to see the static layout, and try motion to capture the highlight during a click.

Wait, but the highlight is transient (the click releases immediately). The `motion` action captures motion frames - it might capture the press state. Let me try a motion during/after a click. Actually motion probably captures what happens visually over time.

Let me try: do a `motion` action which might simulate a press and hold? No, motion is for recording.

Actually, let me reconsider. The `drag` action with hold might keep a press. But that's complex.

Let me verify the visual highlighting differently. Let me modify the approach: I can't easily hold a key with these tools. But the code correctness is verifiable by inspection.

Actually, let me re-examine: maybe I should test that the highlight visually appears. Let me take a screenshot first to see the static appearance of the keyboard. Then for highlighting, I'll trust the console logs (active class added/removed) which I've confirmed via the start/stop logs.

Actually, I realize I can test the "hold" visually. Let me think... The `motion` action captures motion frames (a short video/GIF sequence). If I do a click, the motion might capture the brief highlight. But clicks are too fast.

Alternatively, I could temporarily make the release slower to observe, but that changes behavior.

Let me just take a screenshot to confirm the keyboard layout visually looks right (labels positioned correctly).

Let me also double check the black key positioning is correct - the DOM shows black keys C#4, D#4, F#4, G#4, A#4 with their positions. Let me verify the math in the screenshot.

Actually wait - I want to verify the black key positions are correct. There's a potential bug: I compute prevWhite using `NOTES.indexOf(n)` inside the loop. Let me re-check that code:

```js
if (isBlack) {
  let prevWhite = 0;
  for (let i = 0; i < NOTES.indexOf(n); i++) {
    if (!NOTES[i].note.includes('#')) prevWhite = NOTES[i].whiteIndex;
  }
  const left = (prevWhite + 1) * WK - BK / 2;
```

Wait, this is buggy! `NOTES[i].whiteIndex` is the whiteIndex of NOTES[i], and I'm assigning it to `prevWhite` each time I find a white note before n. So prevWhite ends up being the whiteIndex of the LAST white note before n. That's correct actually.

Let me trace for C#4 (index 1):
- i=0: NOTES[0]=C4 (white), whiteIndex=0, prevWhite=0. Loop ends (i < 1, so i=0 only).
- left = (0+1)*60 - 18 = 60 - 18 = 42. 

Hmm, that's the boundary between white key 0 (C4) and white key 1 (D4). Boundary is at 60. Centering black key: 60 - 18 = 42. So black key spans 42 to 78. The gap between C4 (0-60) and D4 (60-120) is around 60. Black key centered at 60 → 42-78. Correct! ✓

For D#4 (index 3):
- i ranges 0,1,2
- i=0: C4 white, whiteIndex=0, prevWhite=0
- i=1: C#4 black, skip
- i=2: D4 white, whiteIndex=1, prevWhite=1
- left = (1+1)*60 - 18 = 120 - 18 = 102. Boundary between D4 (60-120) and E4 (120-180) is 120. Center 120 → 102-138. Correct! ✓

For F#4 (index 5):
- i=0:C4(0), i=1:C#4, i=2:D4(1), i=3:D#4, i=4:E4(2)
- prevWhite = 2 (E4)
- left = (2+1)*60 - 18 = 180-18 = 162. Boundary between E4(120-180) and F4(180-240) = 180. Center → 162-198. Correct! ✓

For G#4 (index 7):
- prevWhite: i=0:C4(0),2:D4(1),4:E4(2),5:F4(3)
- prevWhite=3 (F4)
- left = (3+1)*60-18 = 240-18 = 222. Boundary F4(180-240)/G4(240-300)=240. Center→222-258. Correct! ✓

For A#4 (index 9):
- prevWhite: 0:C4(0),2:D4(1),4:E4(2),6:F4(3),7:G4(4)
- prevWhite=4 (G4)
- left = (4+1)*60-18 = 300-18=282. Boundary G4(240-300)/A4(300-360)=300. Center→282-318. Correct! ✓

Great, the positioning is correct.

Now let me take a screenshot to verify the visual layout.

The screenshot tool returned no image (the model doesn't support images here). Let me try `motion` to capture a sequence - but that also returns images. The harness says "model does not support images" so I can't view visuals.

Let me rely on DOM inspection and console logs. The DOM shows all the labels are present. Let me try the `inspect` action to see the full DOM state, and try `motion` to capture key highlighting.

Actually, since images aren't supported, I can't visually verify. Let me verify via DOM inspection that the active class actually gets applied during a press. 

The challenge: a click is mousedown+mouseup, so the active class is added then immediately removed. By the time I inspect, it's already removed.

Let me try `motion` - it might capture frames including the pressed state. But the result is images which I can't see.

Alternatively, I can verify the highlighting behavior is wired by inspecting that the active class logic exists in code (it does). And the console confirms start/stop timing.

Let me think about whether I can capture the highlight. The `motion` action "motion frames" - probably captures a short animation. If I trigger a click during motion... but I can't sequence actions easily.

Let me try a different approach to verify the highlight visually persists: I can do a mouse-down that holds. But the only press action is `click` (which is mousedown+mouseup).

Hmm, actually, maybe I should test the hold scenario differently. Let me reconsider the task: "Highlight keys while held." 

I've confirmed via console that start/stop happens. The `active` class is toggled in startNote/stopNote. The CSS applies the highlight. I'm confident this works.

But to be thorough about "press-and-release highlighting" verification, let me try the `motion` action which might capture the pressed frame. Let me try it - if it returns image data I can't view, at least the console might show something.

Actually, let me reconsider. Let me try to capture the highlight by doing a `motion` and the click in a way... no, the tools are separate calls.

Let me try the `inspect` action after a fast click - won't catch the highlight.

Alternative: Let me temporarily add a way to test. Actually, I shouldn't over-engineer. The console logs definitively show the start/stop lifecycle which maps 1:1 to add/remove active class. 

Let me instead verify the polyphony/chord behavior and the "stuck note" prevention more rigorously, since those are harder to visually confirm but are required behaviors.

For polyphony: PolySynth with maxPolyphony=13 supports up to 13 simultaneous. The code uses triggerAttack per note. ✓

For "Release held voices when the pointer is released outside a key": My mouseup listener is on `document`, so releasing anywhere (outside a key) releases the mouse note. ✓

For "window loses focus": window blur → stopAll(). ✓

For "Prevent keyboard auto-repeat": e.repeat check + active Map guard. ✓

Let me verify the auto-repeat prevention and chord behavior with a more targeted test. 

Actually, I realize I can test holding with the `motion` tool perhaps combined with... no.

Let me test a scenario: What if I click (mousedown) on a key, then while held move the pointer out and mouseup outside. With the `click` tool that's one atomic action.

Let me try the `drag` action - it does mousedown, drag, then mouseup. If I drag from a key to outside and release, that tests "pointer released outside a key". Let me try a drag from C4 key to outside.

The C4 key is at viewport x from 360 to 420 (center 390), y from ~120 to ~340 (the keyboard is in the middle vertically). Let me check the layout positions. The body is flex column centered. There's the title (h1), subtitle, keyboard, status, button, mapping. 

Let me estimate vertical positions. With 1200x800 viewport:
- h1 + subtitle ~ 60px top
- keyboard-wrap (height 220px) 
- status, button, mapping ~ 80px

If everything is centered vertically in 800px with ~400px total content, keyboard-wrap top is around (800-400)/2 + 60 ≈ 280ish. Actually let me just inspect to find coordinates. The click on C4 at (380, 320) worked, so C4 is around y=280-340 region, x=360-420.

Let me test the "release outside" via drag: drag from (390, 310) on C4 to (700, 310) outside, then mouseup. This should start C4 on mousedown, then stop C4 on mouseup outside.

Actually, the drag action - let me check: "drag" with x, y, toX, toY. It does mousedown at (x,y), drag to (toX,toY), mouseup. So a drag from C4 to outside would: mousedown on C4 (start C4), drag (mousemove), mouseup outside (stop C4). That tests release-outside! 

Let me do that. First, let me re-activate audio with a click (since the drag might need audio ready, but audio is already ready from before). Actually audio is already running. Let me do the drag.

Wait, but the drag's mousedown on C4 will start C4 and the mouseup at toX/toY will release it. That confirms release-outside works for the mouse. Let me do it.

Actually, I want to also confirm the highlight. During a drag, the key stays "active" (highlighted) while held, then released. The console will show start on mousedown and stop on mouseup. Let me do the drag and check console.

Let me drag from C4 (x~390, y~310) to outside (x=700, y=310).

The drag from C4 to outside (720, 310) shows:
- "start C4 via mouse (id=mouse)" — mousedown on C4
- "stop C4 via mouse (id=mouse)" — mouseup at outside location

This confirms: when the pointer is released outside a key, the note is released. ✓

Now, the highlight while held: during the drag, the C4 key should have been highlighted (active class) between mousedown and mouseup. I can't visually confirm since images aren't supported, but the active class toggle is confirmed by the start/stop logs, and the mouseup-on-document handler correctly clears it.

Wait, there's a subtle issue with the drag. During the drag, the mousemove events happen. My code doesn't handle mousemove for changing notes (which is fine for this piano - you press one note and release). But the key question: did the highlight persist during the drag? 

Actually, there's a potential concern: during mousemove while dragging over OTHER keys, should I switch notes? For a simple piano, typically you'd want the note to follow the pointer, but that's not required here. The requirement is just "Pressing a screen key or its computer key starts the note; releasing it starts the envelope's release phase." My implementation: mousedown starts, mouseup (anywhere) releases. The drag tested this: pressed C4, dragged out, released out → released C4. ✓

Now let me verify the highlight is observable. Since I can't see images, let me add a brief temporary test: I'll verify by inspecting the DOM during a held state. But clicks/drags are atomic.

Hmm. Let me think about whether the active class actually gets applied. In startNote, I do `if (el) el.classList.add('active')`. In stopNote, `el.classList.remove('active')`. This is definitely wired. The CSS `.white-key.active { background: #dfe0f0; ... }` exists. So highlighting works.

To actually OBSERVE the highlight, I'd need a held state visible at inspection time. Let me think of a way...

One option: use the `key` action? No, it's atomic too.

Actually, maybe I can verify via `inspect` that the CSS rules are present and the class exists. But that won't show the transient state.

Let me try a different approach: temporarily test holding by leveraging the fact that the keyboard `key` action might support holding. Let me re-read the function spec for `key`:

"action": "key", "text": string (max 2000)

It just takes text. It probably fires keydown+keyup. No hold.

OK here's another idea: I could verify the highlight by doing an `inspect` immediately after triggering something that holds. But there's no hold-triggering action.

Alternatively — let me reconsider. Maybe I should just trust the implementation and the console logs. The verification criteria say "any observable press-and-release highlighting". The console shows the start/stop lifecycle clearly. The CSS and classList manipulation is clearly wired. 

But let me make the highlight MORE observable/verifiable by also inspecting the DOM to confirm the active class logic and CSS. Let me do an `inspect` to see the full current DOM which will show the key elements and their classes.

Actually, the DOM output already shows the structure. The active class won't be present in a resting state. 

Let me make one improvement to allow visual verification of highlighting: I could add a brief test where I hold via a longer mechanism. 

Actually, you know what — let me reconsider the whole "hold" testing. The `motion` action "motion frames" likely captures a sequence of frames over a short duration, possibly including a user interaction. But I can't see the result.

Given the constraints, let me make the highlight verification as strong as possible by:
1. Inspecting the DOM to confirm key elements have correct structure, classes, data attributes.
2. Relying on console start/stop logs as proof of the lifecycle.

Let me do an `inspect` to get the detailed DOM and confirm everything's wired. Actually the inspect was already done implicitly. Let me re-inspect now to see current state.

Actually, I think a better verification approach: Let me make the active highlight detectable. I'll do a quick test where I trigger a note that stays active. 

Hmm, what about this: the `key` action on 'a' — does it really send keyup? What if I press 'a' and it stays? No, the console showed start then stop, so keyup was sent.

Let me try yet another approach to observe the highlight: temporarily modify the code so that pressing a key also sets a persistent visual marker I can inspect. No — that changes behavior and isn't clean.

I think the cleanest verification is: the console logs prove start→active class added, stop→active class removed. Let me just confirm via inspect that the CSS and class manipulation are present in the final file, and accept that I can't visually screenshot but the behavior is verified by logs.

Actually, let me reconsider — maybe I CAN observe highlighting by using `motion` which captures motion frames. The motion action might capture frames and the "images" field would contain them. But "model does not support images" — meaning I (the model) can't process image outputs. So even if motion captured frames, I can't view them.

So visual confirmation is impossible for me. I'll rely on logs + code inspection.

Let me now do a final code review of the file to make sure the input handlers have matching start/release behavior, and check for any bugs.

Let me re-read the full file.

The code looks correct. Let me verify the final part (blur handling and pointer handlers). Let me read from 305.

Actually, I already saw the full structure. The handlers are:
- mousedown on each key → startNote(MOUSE_ID, ...)
- document mouseup → stopNote(MOUSE_ID)
- window blur → stopAll()
- keydown (no repeat) → startNote('kbd-...', ...)
- keyup → stopNote('kbd-...')

All start/release pairs match. The startNote/stopNote have matching active-map logic. The active class is added/removed consistently. 

One thing I want to verify: the highlight is actually visible. Since I can't see images, let me at least confirm the CSS rule exists (it does: `.white-key.active` and `.black-key.active`).

Now, there's a subtle concern about the highlight being observable during a held note. With the available tools, clicks/drags are atomic, so I can't easily inspect the held state. But the console logs prove the lifecycle, and the CSS + classList wiring is confirmed in code.

Let me think about whether there might be an issue with the highlight timing. When I click C4, startNote adds 'active' (highlight on) then immediately stopNote removes it (highlight off) — too fast to see. That's expected for a single click. The highlight WOULD be visible if a key is held (e.g., pressing and holding the physical 'A' key on a real keyboard, or mousedown and holding without releasing). The code supports this correctly.

To actually demonstrate a sustained hold with these tools, I could use the keyboard 'key' action which sends keydown+keyup — but that's also atomic.

Hmm, wait. Let me reconsider the `key` action. Maybe it sends ONLY keydown (a press) without keyup, allowing a held state? Let me re-examine: when I pressed 'a', the console showed BOTH "start" and "stop" for kbd-A. So the key action sent both keydown and keyup. It's atomic.

Is there any tool that can hold? The `type` action types text (sends keydown for each char + keyup). The `drag` sends mousedown+drag+mouseup.

So I cannot sustain a note with these tools. But that's fine — the requirement is that the app SUPPORTS holding (highlight while held), which it does via the active class. The verification via tools is limited to atomic presses, which I've done for several notes.

Let me make the highlight more observable for verification purposes without changing core behavior. Actually, I have an idea: I can verify the highlight via the DOM — after a mousedown that I then inspect before mouseup. But the click tool is atomic.

Alternatively, I could add a tiny feature: a "test mode" no, that's over-engineering.

Let me reconsider: Is there value in confirming the active class is applied? I could write a quick test by temporarily holding a note via a script. But that's not clean.

Actually, the simplest robust verification: Let me modify the code slightly so that I can demonstrate a sustained note. No — the task says don't change behavior unnecessarily.

I'm confident the implementation is correct. Let me do final verification steps:
1. ✅ One chromatic octave C4-C5 with correct black/white placement and visible note labels — verified via DOM (all 13 notes present: C4, C#4, D4, D#4, E4, F4, F#4, G4, G#4, A4, A#4, B4, C5) and correct keyboard-letter labels.
2. ✅ Computer key mapping A W S E D F T G Y H U J K → 13 notes — verified (A→C4, W→C#4, etc., confirmed in console and DOM).
3. ✅ Press screen key or computer key starts note; release starts release phase — verified (mouse click: start/stop; keyboard: start/stop).
4. ✅ Synthesized voice with ADSR envelope — PolySynth(Tone.Synth) with envelope {attack,decay,sustain,release}.
5. ✅ At least 3 simultaneous notes — PolySynth maxPolyphony=13. (Can't test simultaneity with tools, but PolySynth guarantees it.)
6. ✅ Highlight keys while held — active class + CSS. Wiring verified; can't visually confirm transient state but lifecycle is logged.
7. ✅ Prevent auto-repeat duplicates — e.repeat check + active Map guard.
8. ✅ Release held voices when pointer released outside a key — verified via drag (mousedown outside→mouseup→release).
9. ✅ Release on window blur — stopAll().
10. ✅ Activate audio via user gesture — goBtn click + first keydown/mousedown; verified "Tone.start() resolved".
11. ✅ No audio files; synthesized.
12. ✅ Display computer-key mapping — legend rendered.
13. ✅ Inline CSS/JS, single index.html, tone.min.js via script tag, no external resources.

Let me verify the "3 simultaneous notes" more concretely. I can't press 3 keys simultaneously with the tools. But I can verify the PolySynth supports it by code inspection. Actually, let me test a workaround: I could test chord playback by temporarily... no.

Hmm, actually, let me reconsider whether I can test polyphony. What if I use the `type` action to type a sequence very fast? No, type sends keydown+keyup sequentially.

Let me think about whether the auto-repeat prevention is testable. If I hold 'A' on a real keyboard, the OS fires repeated keydown events with e.repeat=true. My code ignores e.repeat and the active Map guard prevents duplicate triggerAttack. To test, I'd need to send keydown without keyup repeatedly. But the key action sends both. I can't easily test holding with repeat.

Given tool limitations, I've verified what's feasible. Let me also double-check one thing: the worker/buffer error. There's a CSP error: "Creating a worker from 'blob:...' violates worker-src 'none'". This is from Tone.js trying to create a Web Worker (likely for the OfflineScheduler or buffer loading). This might affect some scheduling. But for real-time playback with triggerAttack, Tone.js uses the AudioWorklet / audio thread directly, not the worker for the main context. Let me verify playback actually produces sound.

I can't hear audio through the browser tool. But the console shows "AudioContext is running" and triggerAttack was called. The worker error is non-fatal for this use case (it's about a background worker that Tone.js uses for some scheduling optimization; the main audio still works).

Actually, let me double-check: does Tone.js 14 need the worker for playback? The error appears at load time (when Tone.js module loads and registers). The playback uses Tone.Transport or direct note scheduling on the AudioContext. PolySynth.triggerAttack schedules on the audio context timeline directly. So audio should work without the worker.

Let me verify there are no other errors. The worker error is the only one. The audio warnings about "AudioContext was not allowed to start" appeared before I clicked Enable Audio (expected — audio can't start without gesture). After clicking, it resolved.

I'm fairly confident audio works. But let me make sure the PolySynth actually creates audio nodes on triggerAttack. Let me test by triggering a note and checking there are no runtime errors. The console after the drag showed no errors related to triggerAttack, so playback scheduling works.

Actually, I realize I should double check: when I did the keyboard 'a' press, did the synth actually play? I can't hear it, but no errors were thrown, which means triggerAttack ran. If there were no audio being produced, there'd still be no error necessarily. 

Let me verify the master output is connected. `.toDestination()` connects to Tone.Destination which is the audio output. Good.

Let me also confirm: is there an issue where the worker error prevents Tone.Context from working? Let me check the timing — the worker error appears once at module load, before I created the synth. When I create the PolySynth and call triggerAttack, no errors. So it's fine.

I think the implementation is solid. Let me make one improvement for observability: I'll verify the active class gets applied by doing an inspection that catches the highlight. 

Actually, here's a clean way to verify the highlight: I can use the `key` action but it's atomic. 

Wait — I have an idea. Let me test whether the highlight appears by checking the DOM state during a held key. I can't, because all input actions are atomic.

Let me just accept this and confirm everything else is solid. Actually, let me reconsider — maybe I'm wrong about the `key` action. Let me test: what if I send a `key` action and the note stays sustained (key held)? Let me test by pressing 'a' and then in parallel... no, separate calls.

OK, let me instead verify the highlight logic is sound by a slightly different method: I'll temporarily add a debug to confirm. No.

Actually, the cleanest verification of highlighting that I CAN do: after a `drag` that holds C4 (mousedown) and releases outside (mouseup), the highlight was on during the hold. The console shows start→stop, matching highlight-on→highlight-off. The CSS class exists. This is sufficient evidence.

Let me do a final inspect to confirm the rendered DOM structure of the keyboard with proper key elements, and confirm no obvious issues. Then I'll report.

Actually, let me reconsider one potential issue: In the DOM output, the note label and key label are both shown as separate text lines because they're block/inline elements. Let me check the visual positioning. The `.note` is positioned absolute top, `.label` absolute bottom. So visually: note name at top of key, key letter at bottom. That's correct and visible.

But wait — for white keys, the note at the TOP would be near the top of the key, but white keys have black keys overlapping the top portion! So the note label "C4" at the top of the white key would be hidden underneath the black key C#4. Let me check: black keys are at the top (top: 0, height 130px) overlapping white keys' top ~130px. The white key's `.note` is at `top: 8px` — that's under the black key! So C4's note label would be obscured by C#4.

Hmm, that's a visual issue — the note name on white keys at the top gets covered by black keys. Let me fix: put the note label at the BOTTOM of white keys instead of top, OR position it lower.

Actually, let me reconsider the layout. On a real piano, note names (if any) are usually at the bottom of white keys, below the black keys. Let me move the note label to the bottom for white keys, and keep it... for black keys, the note is small at top.

Wait, currently:
- White key `.note` at top: 8px
- White key `.label` (key letter) at bottom: 8px

Let me swap: note at bottom, label... actually I want both visible. Let me put:
- White key: note name at top-left area but below the black key overlap, OR just at bottom. 

Simplest: For white keys, show the note name at the BOTTOM (below the label would conflict). Hmm.

Let me redesign labels:
- White key: note name (e.g., "C4") at the TOP but positioned in a way not covered. Since black keys cover top ~130px and white key is 220px tall, the uncovered top of white key is only the very top (0-... no wait, black keys start at top:0 with height 130, so they cover white key from top down to 130px). So white key's visible part is from 130px to 220px (bottom 90px). The note label should go in the visible bottom region.

Actually the white key note `.note` at top:8px is covered by black keys. Let me move white key note label to bottom area too, but then it conflicts with the keyboard letter label.

Let me restructure: 
- White key: keyboard letter (A, S, D...) at TOP (visible, near top-left, in the covered region but at the very top edge... no, covered).

Hmm, this is getting complicated. Let me reconsider the design:

The black keys sit on top (z-index 4), covering the upper portion of white keys. So on white keys, only the bottom ~60-90px is visible above the black key overlap region... no. White key height 220px. Black key height 130px positioned at top. So black keys cover white key region from y=0 to y=130 (within the keyboard). The white key visible below black keys is from y=130 to y=220.

So for white keys, labels in the visible region (y=130-220, bottom) are safe. The current `.label` at bottom:8px is in this visible region — good, the keyboard letter is visible. But `.note` at top:8px is covered by black keys — bad, note name hidden.

Solution: Move the white key note name to the bottom too, OR make it small and place near the top but it'll be covered.

Best design: 
- White keys: show note name at top-left, but since it's covered... Actually, real piano labels are tiny and at the bottom corner. Let me put BOTH pieces of info at the bottom of white keys: note name at top-left of the visible-bottom region, key letter... 

Let me simplify the visual:
- White key: at the TOP (covered region), nothing. 
- White key visible bottom region: show the note name (e.g., "C4") at top of that region (just below where black keys end) — actually let me put note name at bottom-left and key letter at bottom-right. Or stack them.

Hmm, let me reconsider. Maybe a cleaner approach: put the keyboard letter on the key (bottom right or bottom center) and the note name... Actually the requirement says "visible note labels". So note names must be visible. The keyboard letter is part of "Display the computer-key mapping" (could be the legend, but also nice on keys).

Let me redesign:
- White keys: note name at the TOP but in the visible portion. Since the black keys only cover the top ~60% (130 of 220), actually no — black keys cover from y=0 to 130, which is the top 130px. White key total 220px. So 130/220 = 59% covered. The bottom 90px is visible.

Wait, that means the note at top:8px (y=8, in covered region) is hidden. Let me move note labels to be visible.

New plan for white keys:
- `.note` (note name) → position at bottom: 8px, left: 8px (bottom-left, visible region)
- `.label` (key letter) → position at bottom: 8px, right: 8px (bottom-right)
This way both visible in the bottom region, no overlap.

For black keys (height 130, not covered by anything):
- `.note` (note name) → top: 6px (visible, at top of black key)
- `.label` (key letter) → bottom: 6px (visible, at bottom of black key)

Wait, but black keys at bottom near y=130 are adjacent to white keys' top... no, black keys are above white keys' visible region. Black key spans y=0 to 130. Its bottom (y=110-130) is visible. Good.

Hmm, but actually let me reconsider: is it cleaner to just put note names on the keys and rely on the legend for key letters? The requirement: "Display the computer-key mapping" — this is satisfied by the legend. And "visible note labels" — note names on keys.

But showing the key letter on each key is also helpful. Let me keep both but position them properly.

Let me also reconsider: maybe it's simplest to put the key LETTER at the bottom of each key (visible region) and the NOTE name... For white keys the note name needs to be visible too. Let me put note name at bottom-left, key letter at bottom-right for white keys.

Actually, let me simplify even further and make it look clean:
- Each key shows the NOTE NAME at top.
- Each key shows the KEY LETTER at bottom.
- For white keys, since top is covered by black keys, move note name to a visible spot.

Ugh, the black-key-overlap issue is real. Let me just reposition.

Let me update the CSS and the label logic. I'll restructure:
- White key: note name positioned at `bottom: 6px; left: 6px` (visible), key letter at `bottom: 6px; right: 6px`.
- Black key: note name at `top: 4px; left: 50%; transform: translateX(-50%)` (top, visible), key letter at `bottom: 4px; left: 50%; transform: translateX(-50%)`.

Wait, but that duplicates. Let me just keep it clean:

For ALL keys:
- `.note` = note name, positioned at bottom (safe for both, since black keys' bottom is visible and white keys' bottom is visible).

Actually for black keys, bottom is near y=110-130 which is fine and visible. For white keys bottom is y=~130-220, visible. So putting note name at bottom works for both!

But then key letter... I want the keyboard letter visible too. Let me put:
- `.note` (note name) at top of key
- `.label` (key letter) at bottom of key

For white keys: note at top is covered by black keys. Problem persists.

OK let me just do: 
- White keys: note name at bottom-left, key letter at bottom-right (both in visible bottom region). 
- Black keys: note name at top-center, key letter at bottom-center.

Let me rewrite the CSS and DOM building accordingly.

Actually, the simplest and cleanest fix that keeps the current structure: just move the white key's `.note` from `top` to the visible region. Let me change white key note to `bottom: 34px` (above the label at bottom:8px) or stack them.

Let me restructure the spans and CSS to be clean. I'll rewrite the key-building CSS and the span appending.

Let me update:
- White key: 
  - `.note` { position absolute; top: 8px; left: 8px; } → move to bottom: 36px; left: 8px; font-size: 12px; color: #5a5d73;
  - Actually, I'll put note at bottom-left and label at bottom-right.

Hmm, let me reconsider — actually the very cleanest: put the note name at the bottom of white keys and the key letter also at the bottom. They might overlap if both bottom-centered. Let me position note at bottom-left and key at bottom-right.

Let me rewrite the CSS for labels:

```css
.white-key .note { position: absolute; bottom: 8px; left: 6px; font-size: 12px; color: #5a5d73; text-shadow: 0 1px 0 rgba(0,0,0,.1); }
.white-key .label { position: absolute; bottom: 8px; right: 6px; font-size: 13px; color: #5a5d73; }
.white-key.active .note, .white-key.active .label { color: var(--accent); }
.black-key .note { position: absolute; top: 4px; left: 50%; transform: translateX(-50%); font-size: 10px; color: #c9ccd8; }
.black-key .label { position: absolute; bottom: 4px; left: 50%; transform: translateX(-50%); font-size: 12px; }
```

This way:
- White key: note name at bottom-left, key letter at bottom-right — both visible (bottom region not covered by black keys).
- Black key: note name at top-center, key letter at bottom-center — both visible.

This is clean. Let me update the file.

Let me make these edits. I'll edit the CSS section and the span creation (the spans already have classes note/label, good). I just need to update CSS positioning.

Let me find the exact CSS text to replace.

Current CSS:
```css
  .white-key .note { position: absolute; top: 8px; left: 50%; transform: translateX(-50%); font-size: 11px; color: #8a8db8; }
  .white-key .label { position: absolute; bottom: 8px; left: 50%; transform: translateX(-50%); }
```

Wait, there are two `.note` rules? Let me check. In my original:
```css
  .white-key .note { position: absolute; top: 8px; left: 50%; transform: translateX(-50%); font-size: 11px; color: #8a8db8; }
  .white-key .label { position: absolute; bottom: 8px; left: 50%; transform: translateX(-50%); }
```

and 
```css
  .black-key .note { position: absolute; top: 6px; left: 50%; transform: translateX(-50%); font-size: 10px; color: #c9ccd8; }
  .black-key .label { position: absolute; bottom: 6px; left: 50%; transform: translateX(-50%); font-size: 12px; }
```

Let me update the white-key note to bottom-left and label to bottom-right.

Actually, let me reconsider the whole thing once more. The current DOM shows for white keys "C4" then "A" — these are the note and label. With my new CSS, note at bottom-left "C4" and label at bottom-right "A". Good.

Let me make the edits.

Also, I should double check: when a white key is active (highlighted, background #dfe0f0), the note/label colors should switch to accent (var(--accent) = #6c5ce5) for visibility on the light-bg... actually #dfe0f0 is still light, so dark text is fine. The active rule doesn't change note/label color for white keys currently. Let me keep dark colors for white key active (they're visible). Actually the active white key has `color: var(--accent)` set on `.white-key.active` which inherits to children. So note/label become accent purple. That's fine visually.

Let me make the CSS edit now.

Let me also reconsider: should the black key note name really be at top? Black keys are short (130px). Note at top (4px) and letter at bottom (4px) both fit. Good.

Let me apply the edits.

Now the black key: note at top (6px), label at bottom (6px). That's fine - both visible since black keys aren't overlapped. But wait, the black key bottom (6px from bottom, y~118-130) is right where the white key top is — but black keys have higher z-index so they're on top. The note at top of black key is fine. Good.

Now let me reload and re-test to make sure nothing broke and the labels are now visible in the right places.

Good, reloaded cleanly. Now let me test a black key and a white key interaction, and a keyboard chord attempt. Let me click a black key to make sure those work too.

Black keys positions (left, width 36):
- C#4: left=42, center ~60. x in keyboard-wrap. Keyboard-wrap left edge = viewport (1200-480)/2 = 360. So C#4 center at 360+42+18 = 420. y top area ~280-340.
- D#4: left=102, center 360+102+18=480.
- F#4: left=162, center 360+162+18=540.
- G#4: left=222, center 360+222+18=600.
- A#4: left=282, center 360+282+18=660.

Let me click F#4 (center ~540, y~320). First need to enable audio. Let me click Enable Audio, then click F#4.

Actually, the previous reload reset audio. Let me enable audio then test a black key.

Hmm, the F#4 black key click did NOT register a start/stop in the console! The console didn't show "start F#4 via mouse". That's a problem.

Why? The black keys are positioned absolutely at their `left` offsets. The black key F#4 is at left=162 within keyboard-wrap which starts at viewport x=360. So F#4 left edge at 360+162=522, right edge at 522+36=558, center at 540. I clicked at x=540, y=330. That should be on the F#4 black key.

Wait, but maybe the keyboard-wrap is not at x=360. Let me reconsider the layout. The page is flex column centered. The content might be wider... no, keyboard-wrap is 480px wide. But the `.subtitle` and `.mapping` might be wider than 480? The mapping is `max-width: 480px`. The h1 and subtitle are full width text (could be wider than 480 but centered). Actually the `.piano` div contains centered content. The keyboard-wrap is 480px.

But wait — is the keyboard actually centered at viewport x=360? The body is flex with align-items:center and justify-content:center (column). The piano div is centered. So yes keyboard-wrap center at 360-840... no. keyboard width 480, centered in 1200-wide viewport → left edge at (1200-480)/2 = 360. So x=540 → 540-360=180 within keyboard. F#4 left=162, so x=180 within keyboard is within 162-198. ✓. y=330 — need to check vertical position of keyboard.

Hmm, but the click didn't register. Let me reconsider — maybe the black key at y=330. The keyboard-wrap top position: the piano div stacks h1, subtitle, keyboard-wrap (220px tall), status, button, mapping vertically, all centered. Total height maybe ~400px. Centered in 800 → top ~200. keyboard-wrap (220 tall) from ~200 to ~420. So y=330 is within the keyboard. That should hit the black key.

Wait — maybe the issue is that the black keys have `touch-action: none` on parent but that shouldn't block clicks. Or maybe pointer-events? No.

Actually, wait. Let me reconsider: maybe the click DID hit a black key but the mousedown handler... let me check. Each black key has a mousedown listener added in `NOTES.forEach`. The black key elements ARE in the DOM. 

Hmm, but the console shows NO start/stop for F#4. Let me reconsider whether my click coordinates hit the black key.

Actually, maybe the problem is that the black key F#4 is at left=162 but I need to recompute. Let me recompute black key positions given WK=60, BK=36.

Wait, I changed nothing about positioning in the CSS edit — only label positions. The left offsets were computed in JS with WK=60, BK=36. F#4: between F4 (white index 3) and G4 (white index 4). prevWhite=3. left = (3+1)*60 - 36/2 = 240 - 18 = 222. 

Wait, I miscalculated earlier! Let me redo:
- WK = 60, BK = 36. BK/2 = 18.
- left = (prevWhite + 1) * WK - BK/2

For F#4 (between F4 whiteIdx=3 and G4 whiteIdx=4): prevWhite=3. left = (3+1)*60 - 18 = 240 - 18 = 222. Center = 222 + 18 = 240. Viewport x = 360 + 240 = 600.

I clicked at x=540. That's viewport 540, within keyboard = 540-360 = 180. F#4 spans left 222 to 258. 180 is NOT within 222-258! So I missed F#4 — I clicked at the D#4/F#4 gap region.

Wait let me recompute all black key centers within keyboard (viewport - 360):
- C#4: prevWhite=0, left=(1)*60-18=42, center=42+18=60 → viewport 420
- D#4: prevWhite=1, left=2*60-18=102, center=102+18=120 → viewport 480
- F#4: prevWhite=3, left=4*60-18=222, center=222+18=240 → viewport 600
- G#4: prevWhite=4, left=5*60-18=282, center=282+18=300 → viewport 660
- A#4: prevWhite=5, left=6*60-18=342, center=342+18=360 → viewport 720

Wait, I made an arithmetic error earlier in my head. Let me recompute D#4: between D4 (whiteIdx 1) and E4 (whiteIdx 2). prevWhite=1. left=(1+1)*60-18 = 120-18=102. center=102+18=120 → viewport 480.

Hmm wait, that doesn't seem right. D#4 should be between D4 and E4. White key D4 is at whiteIdx 1 → left = 1*60 = 60. E4 at whiteIdx 2 → left=120. Boundary at 120. D#4 centered at 120 → left = 120-18 = 102, center 120. viewport = 360+120 = 480. 

So actually F#4 center is at viewport 600, not 540. I clicked at 540 which is between D#4 (480) and F#4 (600) — that's the E4/F4 white-key gap with no black key. So I missed! No black key there (correct — there's no E#/Fb in this octave... wait E4 to F4 has no black key, correct).

So my click at x=540, y=330 landed on the white key E4 or F4, OR on the gap. Actually x=540 → within keyboard 180. White keys: F4 at whiteIdx 3 → left 180, spans 180-240. E4 at whiteIdx 2 → left 120, spans 120-180. So x=180 is the boundary E4/F4. y=330 — the white key bottom region should catch a click. But no start/stop was logged!

Hmm, that's strange. If I clicked on F4 (white key), it should have logged "start F4 via mouse". But nothing logged.

Wait — maybe the click hit the `black-keys` container div which is empty in that region (no black key element there), and the container itself has no click handler but maybe captures the event? No, an empty container div wouldn't capture mousedown from a child... actually mousedown on an empty area of a div fires on the div itself (the parent), not a child. The `.black-keys` container div spans the full keyboard area (inset:0). So clicking in empty black-key space hits the `.black-keys` div, which has no mousedown handler. The white-key click handler is on white key elements only. So clicking on the `.black-keys` container (where there's no actual black key element) does nothing!

That's the bug: the `.black-keys` container is a full-area div, so clicks on empty areas (between black keys, on the white keys' top which is covered) hit the container, not the white key below. The black keys have z-index 4 and the white keys z-index 2. The `.black-keys` div is z-index... not set, default. The white keys are inside `.white-keys` div.

Wait, the structure:
```
.keyboard-wrap (relative)
  .white-keys (absolute, inset 0) — contains white key divs
  .black-keys (absolute, inset 0) — contains black key divs
```

The `.black-keys` div (parent) has default z-index (auto/0). Its child black key divs have z-index:4. The `.white-keys` div has default z-index. So:
- The `.black-keys` parent div (empty background, no background set → transparent) covers the entire keyboard area.
- Even though invisible, does a transparent div with no background receive pointer events? YES, by default any element receives pointer events even if transparent (unlike visibility:hidden or pointer-events:none).

So clicks anywhere in the keyboard area that don't hit an actual black-key element hit the `.black-keys` parent div (transparent), which has no handler. Clicks on white keys in the bottom region — wait, the white keys are in `.white-keys` which is BEHIND `.black-keys` in stacking? Both `.white-keys` and `.black-keys` have z-index auto. They're siblings; the later one in DOM order wins. `.black-keys` is appended after `.white-keys`, so `.black-keys` parent is on top of `.white-keys` parent across the whole area. So ALL mouse events over the keyboard hit `.black-keys` first — but its children (the actual black key divs) are hit-test targets. Where there's no black key div, the event hits the `.black-keys` parent div.

Wait, but the black key divs only cover their small areas. The `.black-keys` parent div covers everything (inset:0). Pointer events hit the topmost element under the cursor. If cursor is over empty `.black-keys` area (no child), the event target is the `.black-keys` parent div. If cursor is over a white key area (bottom region) — the white key is at z-index 2 IN ITS PARENT, but relative to the `.black-keys` parent... stacking is across the whole stacking context. Both `.white-keys` and `.black-keys` are in the same stacking context (root). `.black-keys` parent (z-index auto) comes AFTER `.white-keys` parent (z-index auto) in DOM → `.black-keys` parent paints on top. So white keys are obscured by the transparent `.black-keys` parent for hit testing!

This means: clicking white keys in the bottom region would hit the `.black-keys` parent div (transparent, no handler), NOT the white key div. So white key clicks DON'T work either!

But wait — earlier my click on C4 at (380, 320) DID log "start C4 via mouse". So that worked. Why? 

Hmm. Let me reconsider. Maybe z-index:auto siblings don't stack that way. Actually, for positioned elements with z-index:auto, they form a stacking context only if... no. The painting order for positioned elements in a stacking context: the stacking context paints descendants in order, but positioned descendants with z-index:auto are painted in document order within the "positioned descendants with z-index: auto" layer, AFTER in-flow... 

Actually the rule: within a stacking context, the painting order is:
1. Root background
2. Block-level descendants in normal flow (painted in order)
3. Floating descendants
4. In-flow inline descendants
5. Positioned descendants with z-index:auto AND negative? No...

The full order within a stacking context:
1. If the element is a block, list, etc: the background and borders
2. Block-level boxes...
3. Negative z-index positioned descendants
4. In-flow, non-inline, non-positioned descendants
5. Non-positioned floats
6. In-flow inline descendants
7. Positioned descendants with z-index: auto or 0 (and positive? no) — these paint in document order
...

Hmm, the key point: positioned descendants (z-index auto/0) are painted after non-positioned content but the order among them follows document order. So `.white-keys` (positioned, z-index auto) and `.black-keys` (positioned, z-index auto) — both are positioned. `.black-keys` comes after `.white-keys` in DOM, so `.black-keys` paints ON TOP of `.white-keys`. 

But `.black-keys` has no background, so it's transparent — you can SEE through it visually to the white keys. BUT for hit-testing, pointer events go to the topmost element that has a background? NO — pointer events go to the topmost element in the hit-test order regardless of visibility/transparency (unless pointer-events:none or the element is fully transparent to pointer events).

Wait, actually, hit testing in CSS: an element is considered for pointer events if it's NOT `pointer-events: none` and it has some "presence". A transparent element still receives events. BUT — there's a subtlety: an element with `background: transparent` and no content/dimensions... 

Actually the real rule: A point is "inside" an element for hit testing if the element has a background, border, padding, content, or other properties making it a target. A parent that is transparent and has no padding/border/content but has positioned children — does it capture events in its empty area?

Hmm, the CSS hit testing: an element can be the target of a click if the point is within its padding edge (or content + padding) AND it's not excluded. Actually, the rule is about whether the element is "visible" / has "area". A div with `position:absolute; inset:0` but no background and no content — its padding edge is the full inset area. So yes, it captures hits in its entire area.

But actually, there's the detail: an element with `background: transparent` and no explicit dimensions still establishes a "content box" of zero size, but `inset:0` sets its position but the SIZE is determined by width/height. `inset:0` = top/right/bottom/left:0, which makes the element stretch to fill the containing block ONLY if width/height are auto. For a positioned element with inset:0 and auto width/height, it stretches. So `.black-keys` with `position:absolute; inset:0` stretches to fill `.keyboard-wrap` → full area. So it captures all hits.

So why did my C4 click at (380,320) work? Let me reconsider...

Oh wait! Maybe it did NOT actually hit the white key. Let me reconsider the C4 click. At x=380 (keyboard-local 20), y=320. If y=320 is in the bottom region of the keyboard where the white key is visible, the `.black-keys` parent covers it (transparent) and would intercept... unless the white key is ABOVE the black-keys parent.

Hmm, but I set white keys z-index:2 and black keys z-index:4. These z-indexes are on the INDIVIDUAL key divs, but they're within their parent divs (`.white-keys` and `.black-keys`). The parents are z-index auto. 

Wait — does setting z-index:2 on a child create a stacking context relative to... no. z-index on the child only matters within its parent's stacking context. The parents `.white-keys` (z-index auto) and `.black-keys` (z-index auto) are siblings in `.keyboard-wrap`'s stacking context. Their painting order is document order (both z-index auto → painted in DOM order, `.white-keys` first, `.black-keys` last → black-keys parent on top).

So the `.black-keys` PARENT (transparent, full area) is painted/on-top-of `.white-keys` parent. The individual black-key divs (z-index:4) within `.black-keys` are on top of everything within their parent. But in the EMPTY areas of `.black-keys` (where no black-key child exists), the `.black-keys` parent's transparent area is what's "hit". 

Now, the white-key divs are inside `.white-keys` parent, which is BEHIND `.black-keys` parent. So a hit on empty `.black-keys` area → target is `.black-keys` parent, NOT the white key.

So clicking white keys should NOT have worked... but it DID (C4 click logged start/stop).

Let me reconsider. Maybe I'm wrong about stacking. Let me reconsider: is `.black-keys` parent really intercepting? 

Actually — KEY INSIGHT: A positioned element with no background, no border, no padding, and `inset:0` creating a stretched box — does it really establish a hit target across its whole area? 

The spec: For pointer events, the "topmost" element under the point. An element is a candidate if "the element is not the html element" and it's not display:none, visibility:hidden, and (pointer-events not none). For determining which element is topmost, you walk from front to back. A fully transparent element that has no content — actually the question is whether its "bounding box" for hit testing includes the stretched area.

Yes — `inset:0` with auto width/height on a positioned element makes it fill the containing block, creating a box that IS a hit target across the full area. So `.black-keys` parent captures events in its whole area.

So why did C4 work? 

Let me reconsider the actual DOM/stacking. Maybe I'm wrong and `.white-keys` is on top. Let me reconsider: Actually, the issue might be that the white key click at y=320 was actually hitting... hmm.

Wait, actually, maybe both clicks hit the `.black-keys` parent, and the `.black-keys` parent ALSO has mousedown? No, I only added mousedown to the key elements, not the parent.

Wait, let me re-examine. The C4 click DID log. So either:
(a) The white key div was actually the target (stacking puts white-keys on top), OR
(b) Something else.

Let me reconsider CSS stacking more carefully. Actually, I recall: when two sibling elements are both `position: absolute` with `z-index: auto` (the default), they do NOT create a stacking context themselves (z-index:auto does NOT create a stacking context for non-flex/grid/root... actually z-index:auto with position other than static... no).

The rule: an element with `position` set to something other than `static` and `z-index: auto` does NOT create a stacking context (unless it's the root). Wait, that's not right either. Let me recall precisely:

A stacking context is created by (among others):
- root element
- position:fixed/relative/absolute AND z-index is NOT auto (i.e., a specific value) — wait, z-index:0 vs auto.

Actually: `z-index: <integer>` (including 0 and 'auto' is different). An element creates a stacking context if it is the root, OR if it is positioned (position not static) AND z-index is not 'auto'. Wait no — for z-index:0, it DOES create a stacking context. For z-index:auto with position, it does NOT create a stacking context.

So `.white-keys` and `.black-keys` are `position:absolute` (well, `.white-keys` is `position:absolute`? Let me check my CSS: `.white-keys, .black-keys { position: absolute; inset: 0; }` — yes both absolute, z-index auto).

For z-index:auto positioned elements: they do NOT create stacking contexts. So their painting order relative to each other, within the parent `.keyboard-wrap` stacking context, follows the painting order for positioned descendants with z-index:auto, which is document order. `.white-keys` comes first, `.black-keys` comes second → `.black-keys` paints AFTER (on top of) `.white-keys`.

So `.black-keys` parent is on top. Confirmed. So white key clicks should be intercepted... 

BUT, the white key divs themselves have z-index:2 and black key divs have z-index:4. z-index:2 (a specific integer, not auto) on `.white-key` CREATEs a stacking context. Similarly z-index:4 on `.black-key` creates one. But within `.white-keys` parent (which itself isn't a stacking context since z-index auto), the `.white-key` children (z-index:2, creating their own contexts) paint in document order within `.white-keys`... 

The `.white-keys` parent paints its content. The children `.white-key` (z-index:2) — since z-index:2 creates stacking contexts, they're painted in the "positive z-index" layer of `.white-keys`. But `.white-keys` itself, as a positioned z-index-auto element, paints in the `.keyboard-wrap` stacking context AFTER in-flow/normal content.

OK this is getting deep. The empirical result: C4 white key click WORKED. So in practice, the white key was the target. 

Hmm, wait. Let me reconsider. Maybe the `.black-keys` parent, despite stretching via inset:0, does NOT capture events because it has no background and the children are the actual targets. Actually — here's the thing — for hit testing, the browser walks the stacking order from topmost to bottommost. The topmost painted box under the cursor: if the cursor is over the white-key region (y in bottom 90px of keyboard, x over a white key), the topmost box there...

The `.black-keys` parent box occupies the full area (topmost in stacking order among the two parents). So a point over white-key-bottom-region: the topmost element is `.black-keys` parent (transparent, full-area). Does a transparent stretched div intercept?

YES, it intercepts, UNLESS... hmm. Actually there IS a special rule: the hit-testing algorithm considers an element. For a div with no background and no content, stretched via inset:0 — its "content" box... Actually `inset:0` resolves to top:0,right:0,bottom:0,left:0 which for an absolutely positioned element with auto width/height means it shrinks to... no. For absolutely positioned elements, if both left and right are specified (not auto), width is computed (overrides auto). With left:0 and right:0, width = containing block width. Similarly top:0/bottom:0 → height = containing block height. So `.black-keys` is full-sized. It's a hit target.

So I maintain it should intercept. But empirically C4 worked. 

Let me just TEST this directly. The F#4 "miss" — did it miss because of the stacking (hitting `.black-keys` empty parent) or because I miscalculated coordinates? I calculated F#4 center at viewport x=600, but I clicked x=540 (viewport). 540 = keyboard-local 180 = boundary of F4. That's not where F#4 is. So I simply MISSED F#4's location by clicking in empty space between black keys / on the white-key-top region (covered).

But if I clicked in empty `.black-keys` space, no log. If I clicked on white-key-bottom region (visible), should log the white key. At x=540viewport (local 180, on F4 white key boundary), y=330. If y=330 is in the visible bottom region of the white key, it should hit F4 white key → log "start F4". But NO log appeared. So either y=330 is NOT in the keyboard's vertical span, OR the `.black-keys` parent intercepted.

Hmm. This suggests the `.black-keys` parent IS intercepting white-key clicks. But then how did the C4 click at (380,320) work?

Let me reconsider C4: x=380 viewport = local 20 (within C4 white key 0-60). y=320. 
F#4 miss: x=540 viewport = local 180 (F4 boundary), y=330.

If `.black-keys` parent intercepts white keys, then C4 click should ALSO have been intercepted (no log). But it logged. Contradiction.

Unless... the C4 click at y=320 vs F4-click-at-540 y=330 — different y, but the keyboard vertical span is the same. Both should be in the keyboard.

Wait, maybe y=330 is BELOW the keyboard (in the status/button/mapping area), so the click hit a non-keyboard element. And the F4-click actually... no, it would hit the mapping or button which also have no piano handler → no log. That's consistent with "no log"!

So maybe my y coordinate 330 was below the keyboard wrap. Let me figure out the actual vertical layout.

Actually, let me reconsider. The keyboard-wrap height is 220px. If the total piano content height is H, centered: keyboard top = (800 - H)/2 + (title/subtitle height ~50) ... 

Earlier, C4 click at y=320 worked and hit C4 (white key, bottom region). For C4 to be hit at y=320, the keyboard must span such that y=320 is within its white-key-visible-bottom region. White keys visible bottom is from (black key height 130) to 220, i.e., y within keyboard-local 130-220. If keyboard top is at viewport Y0, then visible white region is Y0+130 to Y0+220. For y=320 to be in [Y0+130, Y0+220]: Y0+130 ≤ 320 ≤ Y0+220 → Y0 ∈ [100, 190]. So keyboard top around 100-190.

Then F4 click at y=330: if keyboard top ~190, visible white region is 190+130=320 to 190+220=410. y=330 is in visible white region. So clicking F4 white key at (local 180, y=330) should hit F4 → log "start F4". But NO log. 

Contradiction again. Unless the click at x=540 local 180, y=330 hit the `.black-keys` parent (transparent) intercepting, NOT F4.

So the `.black-keys` parent IS intercepting white-key clicks in some cases but not others? That doesn't make sense unless the black key elements themselves are the issue.

Hold on. Let me reconsider. For C4 at (local 20, viewport y 320): The `.black-keys` parent covers the full area. The black KEY CHILDREN are only at their specific positions (e.g., C#4 at local x 42-78). At local x=20, there's no black key child → the `.black-keys` parent (transparent) is the topmost at that point. So C4 click should hit `.black-keys` parent → no handler → no log. But it LOGGED. 

This is really contradictory. Let me just empirically test with a more careful coordinate and also do an inspect to see the actual DOM/positions. Let me inspect the keyboard element to get exact bounding rects.

Actually, the simplest fix for the "transparent parent intercepts" issue (IF it's happening) is to set `pointer-events: none` on the `.black-keys` parent (and `.white-keys` parent) so clicks pass through to the actual key children. OR set `pointer-events: auto` on the key children. That's a common piano pattern.

But first, let me determine if there's actually a bug. The C4 click worked but the F4-region click didn't. Let me test clicking F4 explicitly at a clear position, and click C#4 (black key) at its correct position.

Let me recompute black key centers precisely and click one:
- C#4: local center 60 → viewport 420. y should be in black key vertical span (top region 0-130 of keyboard, i.e., viewport Y0 to Y0+130).
- Let me click C#4 at viewport (420, 260) assuming keyboard top ~190 → black key region y 190-320. y=260 in range.

And white key C4 at viewport (380, 320) worked (y in visible white region 320-410... if Y0=190, visible white region 320-410, y=320 borderline).

Hmm, let me just inspect first to get exact positions, then click precisely.

Let me do an inspect to find element positions. Actually inspect gives the DOM tree. Let me use it and also I realize I should add `pointer-events: none` to the container parents to be safe. This is the standard pattern for overlaid piano keys and removes any ambiguity.

Let me make that robustness fix: set `pointer-events: none` on `.white-keys` and `.black-keys` wrapper divs, and `pointer-events: auto` on the individual `.key` elements. This ensures clicks always reach the actual key divs regardless of stacking/transparency issues, and the transparent empty areas pass through to white keys below.

This is actually the correct, robust fix. Let me apply it.

Now let me reload and inspect the actual bounding box of the keyboard to get exact coordinates. Let me reload, enable audio, then click precise black-key and white-key positions.

Let me reload first.

The inspect returned the same DOM (text only). I can't get bounding rects from this. Let me write a tiny inline script via... no, I can't inject scripts. 

Let me just reason about coordinates from the previous successful clicks:
- C4 worked at (380, 320) → local (20, ?). So keyboard-local x=20 → C4 (0-60). Good.
- Keyboard-wrap: viewport-local x offset = 380-20 = 360. So keyboard left edge at viewport x=360. (Matches (1200-480)/2=360.)
- C4 click at y=320 worked (hit white key visible bottom).

Black key centers (keyboard-local x):
- C#4: center 60 → viewport 420
- D#4: center 120 → viewport 480
- F#4: center 240 → viewport 600
- G#4: center 300 → viewport 660
- A#4: center 360 → viewport 720

Wait, A#4 center at viewport 720, but keyboard right edge at 360+480=840. 720 is keyboard-local 360 (A#4 left=342..378, center 360). OK.

For black keys, the y range: keyboard top to top+130. The black key click I tried at y=330 — but C4 white key click worked at y=320, meaning keyboard bottom region (visible white) includes y=320. Black keys occupy the TOP portion of the keyboard (top to top+130). If keyboard top is Y0, black keys y-span = [Y0, Y0+130].

C4 white-key visible region = [Y0+130, Y0+220]. C4 click worked at y=320 ∈ [Y0+130, Y0+220]. So Y0+130 ≤ 320 → Y0 ≤ 190. And 320 ≤ Y0+220 → Y0 ≥ 100. So Y0 ∈ [100,190].

For black keys, I should click at y around Y0 + 65 (middle of black key). If Y0 ≈ 190 (from earlier estimate), black key middle at y≈255. But Y0 is uncertain.

The previous successful C4 click at y=320 gives Y0 ∈ [100,190]. If Y0 is lower, say 130, black key middle ~195.

This is too uncertain. Let me instead click black keys at a y that's clearly in the black-key region AND verify. Better: let me just enable audio and click a black key (say C#4 at viewport 420, and try a range of y values).

Actually, the issue earlier: my F#4 click at (540, 330) failed. 540 viewport = local 180 = F4 white-key boundary (white key, not black key location). I never clicked a black key at its correct x! Let me click C#4 at (420, y) with y in the black region.

Let me enable audio first (click the button at ~615,470), then click C#4 black key. But I need the right y. Let me try y=250 first (assuming Y0~190, black key middle ~255).

Actually, let me get the button and keyboard positions more precisely. The DOM text output doesn't give coordinates. 

Alternative robust approach: Let me add a temporary debug to print bounding rects to console, reload, inspect console, then remove debug. But I can't easily inject.

Hmm, actually I CAN add temporary console.log in the JS that prints element.getBoundingClientRect(), reload, and read the console. That would give me exact positions. Let me do that temporarily.

Let me add a debug log after building the keyboard.

Actually, simpler: let me just reason and click black keys at multiple y if needed. But I want to be efficient.

Let me add a temporary debug line that logs the bounding rect of the keyboard wrap and a couple black keys. I'll add it, reload, click Enable Audio (to get console), then read inspect console. Then remove the debug.

Actually the console is captured on every tool call's return. So if I add a debug log that runs at page load, the next reload's response will include it in console. Let me add it.

Now I have exact positions. The keyboard-wrap is at x=360, y=266.84, width 480, height 220. So the keyboard spans:
- x: 360 to 840
- y: 266.84 to 486.84

Black keys are at y=266.84, height 130 → span y 266.84 to 396.84 (top portion).
White keys visible bottom: y 396.84 to 486.84.

Black key positions:
- C#4: x 402-438, y 266.84-396.84
- D#4: x 462-498, y 266.84-396.84
- F#4: x 582-618, y 266.84-396.84
- G#4: x 642-678, y 266.84-396.84
- A#4: x 702-738, y 266.84-396.84

White key positions (full 220 height, but top covered by black keys):
- C4: x 360-420
- D4: x 420-480
- E4: x 480-540
- F4: x 540-600
- G4: x 600-660
- A4: x 660-720
- B4: x 720-780
- C5: x 780-840

Note: white key heights show 220 but y increasing by 220 each log line (486, 706, 926...) — that's a bug in my debug! The getBoundingClientRect for D4, E4 etc. shows y=486, 706, 926, 1146... That's wrong — they should all be at y=266.84.

Wait, why does each white key have a different y increasing by ~220? That means the white keys are STACKED vertically, not in a row! 

Oh no. The `.white-keys` container has `position: absolute; inset: 0` and the white key children have `position: relative; left: ...; width: 60px; height: 100%`. But `.white-keys` doesn't have `display: flex`! So the white keys, being `position: relative` (not absolute), are laid out in normal flow — flowing vertically (block-level, since .key has display:flex which makes them block-level-flex). So they stack vertically down the page!

That's the bug. The white keys are not in a row — they're each on their own line, stretching the page vertically. The y values 266, 486, 706, 926, 1146, 1366, 1586, 1806 = increasing by 220 (the key height). So the keyboard is actually a vertical column of 8 white keys stacked, each 220px tall!

This happened because I removed the flex layout or never set `.white-keys` to flex. Let me check my CSS. Original: `.white-keys, .black-keys { position: absolute; inset: 0; }` — no display:flex. And `.white-key` has `position: relative; left: ...; width: 60; height: 100%`. Without flex, `left` on a relative-positioned element offsets it from its normal position, but they still flow in normal document flow (vertically).

Wait, but the FIRST white key C4 is at y=266.84 with height 220 (correct, matches keyboard top). D4 at y 486 = 266+220. So yes, they're stacking vertically.

This is a major layout bug. I need `.white-keys` to use flexbox (display:flex) so white keys sit in a row. The `left` positioning I set via inline style (n.whiteIndex * WK) would then be redundant/ignored since flex handles it. Actually with `position: relative` and `left`, the relative positioning still applies ON TOP of flex layout, which would shift them incorrectly.

Let me fix: Make `.white-keys` display:flex. Remove the inline `left` style for white keys (let flex position them). Keep width and height.

Actually, I set `el.style.left = (n.whiteIndex * WK) + 'px'` for white keys. With flex, I should remove that and let flex handle the row layout (no gap). And remove `position: relative`? The `.white-key` has `position: relative` — with flex it's fine, but the `left` inline style would offset. Let me remove the inline left for white keys.

For black keys: they're absolutely positioned within `.black-keys` (position absolute, inset:0). The inline `left` is correct (absolute positioning). Keep those.

Let me fix:
1. CSS: `.white-keys { display: flex; }` (and black-keys pointer-events none already set).
2. White key: remove inline `left` style. Keep width, height 100%.
3. `.white-key` should probably not be `position: relative` with a left offset. Make it `position: relative` is fine for the active transform (translateY). Actually transform works on positioned or flex items. Let me keep `position: relative` but remove the `left` inline.

Wait, the `.key` base has `transition: transform`. The white-key active uses `transform: translateY(2px)`. For transform to work, the element needs `position` (relative is fine) or be a flex item. As a flex item, transform works without position. But I'll keep position: relative for the .note/.label absolute positioning (they're position:absolute relative to .white-key).

Let me restructure:

CSS:
```css
.white-keys { position: absolute; inset: 0; display: flex; pointer-events: none; }
.black-keys { position: absolute; inset: 0; pointer-events: none; }
.white-key { position: relative; width: 60px; height: 100%; ... }
```

White key building: remove `el.style.left`. Keep width and height.

Let me also reconsider: with flex on .white-keys and the white key width 60px, 8 keys = 480px = keyboard width. 

Black keys absolute positioning: left = (prevWhite+1)*60 - 18, within .black-keys (480 wide). C#4 left=42, etc. These are correct. Good.

Let me make these edits.

Also, the debug rect logging showed the white keys stacking — confirming the bug. Let me fix and remove debug.

Let me edit:
1. Remove the temp debug block.
2. Change `.white-keys, .black-keys` to add `display: flex` for white-keys specifically. Actually they share the rule. Let me split: 
   `.white-keys { position: absolute; inset: 0; display: flex; pointer-events: none; }`
   `.black-keys { position: absolute; inset: 0; pointer-events: none; }`
3. White key building: remove `el.style.left = ...`.

Let me look at the current code for white key style setting.

In the build:
```js
} else {
  el.style.width = WK + 'px';
  el.style.height = '100%';
  el.style.left = (n.whiteIndex * WK) + 'px';
  whiteContainer.appendChild(el);
}
```

Remove the `el.style.left` line.

Let me make all edits.

The edit tool requires the key "edits" with "oldText"/"newText". I used new_text/old_text instead. Let me fix.

Now remove the temp debug block.

Debug block removed (no more [debug] logs). Now let me re-add a quick debug to confirm white keys are in a row, OR just test clicking. Let me re-add the debug temporarily. Actually, let me just test clicking a white key and a black key at computed positions.

From the previous debug, keyboard-wrap was at x=360, y=266.84, height 220. Black keys at y 266.84 (height 130, so y 266.84-396.84). White key visible bottom y 396.84-486.84.

The keyboard-wrap position depends on total content height. Now that white keys are in a row (480px wide, 220 tall), the piano content is narrower/taller differently. Let me just re-add debug to get exact positions, then click precisely, then remove debug.

Actually, let me be efficient. Let me re-add debug, reload, read positions.

Now all white keys are at y=267 with proper x positions in a row:
- C4: x 360-420
- D4: x 420-480
- E4: x 480-540
- F4: x 540-600
- G4: x 600-660
- A4: x 660-720
- B4: x 720-780
- C5: x 780-840

Black keys (y 267-397, top region):
- C#4: x 402-438 (between C4 and D4) ✓
- D#4: x 462-498 (between D4 and E4) ✓
- F#4: x 582-618 (between F4 and G4) ✓
- G#4: x 642-678 (between G4 and A4) ✓
- A#4: x 702-738 (between A4 and B4) ✓

The layout is now correct: 8 white keys in a row, 5 black keys correctly positioned over the gaps (no black key between E-F or B-C). 

Now let me enable audio and test:
1. Click a black key (e.g., F#4 at center x≈600, y≈300)
2. Click a white key
3. Keyboard test

The Go button is at the bottom. From earlier, the button was around viewport (615, 470). Let me enable audio by clicking the button. The button position might have changed since layout changed (keyboard now shorter? no, keyboard is 220 tall same, but white keys in a row means piano content height is less, so button is higher). Let me click Enable Audio — I'll click near where it was but let me recompute. Actually the status/button/mapping are below the keyboard. Keyboard bottom = 267+220 = 487. So button is below 487. Let me click around (600, 520) for the button.

Actually, let me just click and observe. Let me enable audio first.

Audio enabled. Now let me click the F#4 black key at center x=600, y=300 (in the black key region y 267-397).

Now the F#4 black key click registered: "start F#4 via mouse (id=mouse)" then "stop F#4 via mouse (id=mouse)". 

So the pointer-events fix made black keys clickable. Now both white and black keys work.

Now let me test a keyboard chord. Since the `key` action is atomic (keydown+keyup), I can't hold multiple. But let me test a few different keys to confirm the mapping across the range:
- 'a' → C4 already tested
- Let me test 'k' → C5 (the last key)
- 'w' → C#4 (black key via computer)
- 'd' → E4

Let me test 'k' (C5) and 'w' (C#4) separately. But each is atomic. Let me at least confirm a couple.

Actually, I already confirmed 'a'→C4 works fully. Let me test 'k'→C5 to confirm the end of the range, and 'w'→C#4 to confirm a black-key computer mapping.

Let me test 'w'.

`w` → C#4 via keyboard, start/stop confirmed. Now let me test 'k' → C5.

`k` → C5 confirmed. The full range works from C4 (A) to C5 (K).

Now let me test the chord/polyphony and the "release outside" more rigorously. The `drag` action tested release-outside already (mousedown on C4, drag out, mouseup → release). Let me test a drag starting on a black key.

Actually, I already verified release-outside via the earlier drag (before the flexbox fix). Let me re-verify it now with the fixed layout. Let me drag from a white key to outside.

Actually, let me test holding: the `drag` action does mousedown→drag→mouseup. Let me drag from C4 (x 390, y 440 visible white region) to outside (x 900, y 440). This starts C4 on mousedown, drags, releases outside → should release C4.

But wait, during the drag, mousemove events fire over various elements. My mousemove handler? I don't have one. So the note stays C4 throughout, then mouseup releases it. Good.

Let me do the drag from C4 to outside.

C4 visible bottom region: x 360-420, y 397-487. Center ~ (390, 440). Drag to (900, 440) which is outside (keyboard right edge 840).

Let me do this drag.

The drag from C4 (mousedown at 390,440) to outside (900,440) shows:
- "start C4 via mouse (id=mouse)" — mousedown on C4 started the note
- "stop C4 via mouse (id=mouse)" — mouseup outside (at 900,440, which is outside keyboard right edge 840) released the note

This confirms release-when-pointer-released-outside works. 

Now I've verified all the key behaviors:
1. ✅ Layout: 8 white keys in a row, 5 black keys correctly placed with no black keys at E-F/B-C gaps, correct x positions.
2. ✅ Labels: all 13 notes with note names + computer key letters visible.
3. ✅ Mouse press/release: C4 (white), F#4 (black), C4-drag-outside all work.
4. ✅ Keyboard press/release: w→C#4, k→C5, a→C4 all work.
5. ✅ Audio activation via user gesture (Enable Audio button + fallback on first keydown/mousedown), Tone.start() resolved.
6. ✅ ADSR envelope via PolySynth(Tone.Synth) with envelope {attack, decay, sustain, release}.
7. ✅ Polyphony: PolySynth maxPolyphony=13 (≥3 simultaneous supported by design).
8. ✅ Auto-repeat prevention: e.repeat check + active Map guard.
9. ✅ Release on blur: stopAll().
10. ✅ Release on pointer-up-outside: document mouseup listener.
11. ✅ No external resources, inline CSS/JS, tone.min.js local.
12. ✅ Computer-key mapping legend displayed.

The only things I could NOT directly verify due to tool limitations:
- Visual highlighting (active class appearance) — can't see screenshots (model doesn't support images). But the active toggle is wired in code and the start/stop lifecycle is logged.
- Simultaneous chord playback (3+ notes at once) — the `key`/`click` tools are atomic (press+release immediately), so I can't hold 3 keys simultaneously. But PolySynth with maxPolyphony=13 guarantees this capability by design, and triggerAttack is called per-note without conflicting.
- Audio actually being audible — can't hear through the tool, but no runtime errors on triggerAttack and AudioContext is running.

Now let me remove the temporary debug block and finalize the file.

Let me remove the debug console.log block.

Now let me do a final reload to confirm the file is clean (no debug logs) and everything still works, then do a final read of the complete file to verify correctness.

The debug block is removed. The console is clean now (only the standard notes/keyboard map logs). Let me do one final verification - enable audio and play a couple notes to confirm the cleaned file works, then read the final file.

Let me click Enable Audio then click a key.

Confirmed: F#4 still works after cleanup. Audio activation and note playback all good.

Now let me read the complete final file to do a final review.

The file looks good. Let me review for any final issues:

1. There's a redundant comment in the blur handler: "Release all held voices so notes can never get stuck on focus loss." is fine.

2. The `whiteCount` variable is unused. Let me check — `const whiteCount = whiteIdx; // 8`. It's not used anywhere. Minor, but harmless. Let me leave it or remove it. Actually let me remove it to keep clean. Actually, it's harmless and could be considered documentation. I'll leave it — no, let me remove unused var to be clean. Actually, it doesn't hurt. Let me leave it; removing requires another edit. Actually, let me just leave it — it's documentation of the count. Minor.

Hmm, actually there's a potential issue. Let me reconsider the blur handler: when window blurs, I call stopAll(). But stopAll calls stopNote for each active voice. For keyboard voices, this calls synth.triggerRelease(note). For mouse voice, stopNote(MOUSE_ID). Good.

But there's a subtle issue: when the page itself is clicked to re-enable focus, the blur might fire. Actually that's fine — releasing all notes on blur is the desired "stuck note prevention".

3. One thing: the `key` action in tests sends keydown+keyup. But on a REAL keyboard, if you hold 'A', you get keydown once (repeat=false), then auto-repeat keydown events (repeat=true, ignored), then keyup. My code: keydown with repeat ignored after first, active Map prevents duplicates. keyup releases. Good.

4. Potential issue: if a keyboard key is pressed and then the window blurs, blur releases it. Then the user might not have released physically — but on focus back, the key may still be physically held and the browser will fire keyup eventually OR another keydown. If keydown fires again after blur-released, active.has('kbd-A') is false (since stopNote deleted it), so it re-triggers attack. That's acceptable behavior.

5. The PolySynth.triggerAttack with velocity 0.22 — fine.

6. Note: `Tone.start()` — in Tone 14, this unlocks/creates the audio context. Good. Called once on gesture.

7. There's a concern: I attach `document.body.addEventListener('keydown', ... once)` and mousedown once for audio activation. But these fire before the main keydown/keyup handlers. The `activateAudio` on first keydown — but then the main keydown handler ALSO fires (it's a separate listener on `document`). So first keydown: activateAudio() (creates synth, calls Tone.start() which is async) AND startNote (but synth was just created synchronously, so triggerAttack may be called before audio is ready — Tone.start() is async). 

This is a minor race: on the very first keypress, Tone.start() hasn't resolved yet (it's async), so synth.triggerAttack is called on a PolySynth whose AudioContext is still suspended. Will triggerAttack work before context is running? In Tone 14, scheduling with triggerAttack queues the note; if the context isn't running, the note might not play. But Tone.start() resolves quickly (synchronous-ish in modern browsers). Actually there can be a race.

To be safe, I could guard startNote to only play if audioCtxReady. But the requirement says "Activate audio through a user gesture" — the user gesture IS the first keydown. If I block playback until Tone.start resolves, the first note might be missed.

Hmm. Let me reconsider. Actually, in my testing, the first keyboard 'a' after enabling audio worked because audio was already enabled via the button. But the scenario where the FIRST interaction is a keypress (no button click): activateAudio called (Tone.start async), startNote called immediately (synth.triggerAttack). Since Tone.start() is async and the context isn't resumed yet, the note likely won't play (or might play if the context auto-resumes).

To handle this robustly, let me make startNote guard on audioCtxReady: only call triggerAttack if audioCtxReady.val is true; otherwise the note won't sound but the key will still highlight, and when audio becomes ready... hmm that's bad too.

Actually, the cleaner approach: don't auto-activate on keydown/mousedown separately. Just rely on the button OR call Tone.start() on the gesture. Actually, the issue is the once-listeners AND the main handlers both fire on the same event.

Wait, actually there's a subtlety: the `once` listeners and the main `document.addEventListener('keydown')` listener — both fire on the same keydown event. Order: the body listener (once) fires first (event bubbles from target to body... actually keydown on body — if the event.target is body, listeners on body fire in order of registration; document listeners fire during bubble phase after body). Hmm, this is getting complicated.

Simplest robust fix: Remove the "activate on first keydown/mousedown" auto-activation, and instead just ensure that triggerAttack works. Actually, the cleanest: keep auto-activation but make startNote queue the note if not yet ready.

Actually, let me reconsider. In modern browsers, `audioContext.resume()` (what Tone.start does) returns a promise that resolves quickly. The first keydown → activateAudio → Tone.start() returns promise (pending). Then startNote → synth.triggerAttack. At this moment, AudioContext.state is still 'suspended' (resume hasn't completed). triggerAttack schedules a note at the current time on a suspended context → the note won't play.

So the FIRST keypress without prior button click would play no sound (silent note, but key highlights). That's a poor experience but matches "activate through gesture" partially.

Better approach: Make the audio activation synchronous-ish. Actually Tone.start() internally calls `this._context.resume()`. The resume is async but completes on the next microtask. 

The robust solution: On first interaction, call Tone.start(), and ALSO ensure notes scheduled. Actually, the simplest: gate startNote on audio ready, and if not ready, still highlight + schedule. But the schedule won't fire...

Alternative clean solution: Don't use the body-level once-listeners for activation. Instead, since the button is clearly visible and required ("Display..."), just use the button. But the requirement says "Activate audio through a user gesture" — a button click IS a user gesture. So I could rely solely on the button. But auto-activating on first keypress is a nice bonus.

Hmm, but if a user just starts typing without clicking the button, audio won't be active and notes won't play. To be safe and correct, let me keep auto-activation but handle the race: in activateAudio, since Tone.start() is async, I should defer note-playing until ready.

Actually, the cleanest fix: make startNote check if ready; if not ready, don't play but remember to play on ready. That's complex.

Simplest pragmatic fix: Keep the button as the primary activation. The auto-activate-on-first-keypress listeners are a bonus. To avoid the silent-first-note race, I can make the activation synchronous by checking: actually, Tone.start() in v14 resolves quickly. In my actual browser testing, when I clicked the button first, then pressed keys, it worked. The race only matters for the no-button path.

Let me reconsider: do I even need the body once-listeners? They could cause issues. The task says "Activate audio through a user gesture" — the button satisfies this. But a user might expect to just start typing. 

Let me keep both but fix the race properly: I'll make startNote/play only happen when audioCtxReady.val is true, AND make activateAudio synchronous enough. Actually, the real fix: call Tone.start() and have the startNote check happen. 

Let me think about what actually happens in Chrome: `AudioContext.resume()` is async, resolves within a few ms. The keydown handler calls activateAudio (fires Tone.start, returns pending promise) and then startNote triggers attack on a suspended context = no sound.

To avoid this, I can make the first keypress not immediately play but wait for Tone.start. OR: I can simply NOT auto-play on the gesture that also activates; instead, require the user to click Enable Audio first (button), which is clearly displayed and is itself a user gesture. Then all subsequent notes play fine.

Actually, the cleanest and most robust: Remove the body once-listeners for auto-activation. Keep the button. This guarantees the AudioContext is resumed (and promise resolved, since button click → activateAudio → Tone.start().then sets audioCtxReady.val=true) before any note. Since the user must click the button first, all notes work.

But what if a user presses a key before clicking the button? Then audio not ready, note won't play (startNote still highlights the key though, since highlight doesn't depend on audio). That's acceptable — the status says "Click Enable Audio to start."

Hmm, but it's nicer to auto-activate. Let me keep auto-activation but fix the race so the first key still sounds. The fix: in startNote, if not audioCtxReady, schedule the note's attack to happen after Tone.start resolves. 

Actually, the simplest correct approach: Make activateAudio synchronous and reliable. I can't make Tone.start synchronous. But I can restructure: on first keydown, call Tone.start(); then in the same tick, the context isn't ready. 

You know what, let me just test the actual behavior: does pressing a key BEFORE clicking the button still produce sound? In my tests I always clicked the button first. Let me not over-engineer — the requirement is "Activate audio through a user gesture and synthesize all sound without audio files." The button click is the gesture. Auto-activation is a bonus that may have a race. 

But actually, I can make it robust cheaply: In startNote, only play the synth note if audioCtxReady.val. And keep the auto-activate-on-first-interaction. If the first interaction is a key that also activates, the note won't play (audio not ready yet) — but that's an edge case.

Actually, the BEST fix for the race: when activateAudio is called from a keydown, the keydown ALSO triggers startNote in the same event loop. The activateAudio calls Tone.start() (async). startNote runs triggerAttack immediately. To make the first note play, I'd need to defer triggerAttack until the promise resolves.

Let me implement a small ready-gate: 
- Maintain a flag and a queue of pending note starts if not ready.
- Actually simpler: store a "pending play" — when startNote is called and not ready, set a flag; when audioCtxReady becomes true, we can't retroactively play because the key might still be held... 

This is getting complicated. Let me step back. The realistic user flow: they see "Click Enable Audio to start" and click it (clear, displayed). Then they play. Audio is ready. All good. The auto-activate-on-keypress is a graceful bonus that handles the case where they start typing immediately — and in that case, even if the very first note is slightly delayed, subsequent notes work. Actually no, if first keypress triggers activation but doesn't play, the note is silent but the key highlights, and on keyup stopNote is called — fine. The next keypress works.

Actually, wait — will the first note really be silent? Let me reconsider. In Chrome, `audioContext.resume()` — the resume happens. triggerAttack schedules at Tone's internal time. If context is suspended when triggerAttack is called, Tone might still queue it... Actually Tone.js schedules using `context.currentTime` and the scheduled time. If the context is suspended, the scheduled time might be in the past or the node creation might fail.

Let me just test this empirically: reload, and WITHOUT clicking the button, press 'a'. See if it plays (console will show "start C4 via keyboard" and possibly synth creation). Then I'll know if the race causes silence. But I can't hear audio, only see console. The console would show "start C4" regardless. I can't tell if audio played.

Hmm. Without audio verification, I can't tell if the first note is silent. 

Given the uncertainty, the safest approach to GUARANTEE all notes play: remove the body once-listeners for auto-activation and rely on the button (clearly displayed, satisfies "user gesture"). When the button is clicked, Tone.start().then sets the ready flag. Subsequent notes play reliably.

But then if user presses a key before clicking button, the key highlights (startNote adds active class regardless of audio) but no sound. That's a minor edge. Actually, to be cleaner, if not audio ready, I could still highlight + show status. But the note won't sound.

Actually, let me reconsider keeping auto-activation but making it robust. The cleanest robust pattern: keep the once-listeners, but in startNote, if audio isn't ready, still add the active class and set the active map, but DON'T call triggerAttack yet — and when audio becomes ready, IF the voice is still active, triggerAttack. This way the first held note sounds once audio activates.

That's a bit more code but robust. Let me implement:

```js
function startNote(id, note, type) {
  if (active.has(id)) return;
  active.set(id, { note, type, played: false });
  const el = keyElByNote[note];
  if (el) el.classList.add('active');
  playIfReady(id);
}

function playIfReady(id) {
  const v = active.get(id);
  if (!v || v.played || !synth) return;
  if (audioCtxReady.val) {
    synth.triggerAttack(v.note, undefined, 0.22);
    v.played = true;
  }
}
```

And in activateAudio's success callback, after setting audioCtxReady.val=true, loop over active voices and playIfReady each.

This way: first keypress (before button) → startNote highlights + sets active, playIfReady finds audio not ready, doesn't play. Then audio activates (via the once-listener calling activateAudio on that same first keypress) → on resolve, plays all active voices (including the held one). 

But there's still a timing issue: the once-listener calls activateAudio which is async; startNote already ran (sync) before the promise resolves. When promise resolves, we play pending. Good — this works!

And stopNote: should only triggerRelease if it was actually played (v.played). Let me guard:

```js
function stopNote(id) {
  const v = active.get(id);
  if (!v) return;
  if (synth && v.played) {
    synth.triggerRelease(v.note);
  }
  const el = keyElByNote[v.note];
  if (el) el.classList.remove('active');
  active.delete(id);
}
```

This is robust. Let me implement this. It handles the race properly: notes pressed before/during audio activation still get recorded and play once ready, and release only triggers if actually played.

Actually, wait — is this over-engineering? The task is time-boxed (15 min). But correctness matters. The race scenario (pressing a key before clicking Enable Audio) is a real user flow. Let me implement the robust version since it's not much code.

Hmm, but actually — let me reconsider. Is there actually a race problem? Let me reconsider the once-listener approach. With `document.body.addEventListener('keydown', activateAudio, {once:true})`, on the first keypress, activateAudio is called. But ALSO `document.addEventListener('keydown', mainHandler)` fires startNote. Both in the same event dispatch. activateAudio calls Tone.start() (async, returns pending promise immediately, doesn't block). Then mainHandler's startNote runs triggerAttack on suspended context.

Actually, the order of listener calls: for the SAME event, listeners fire in registration order. The body listener is registered first (during init), then the document listener. For a keydown on body (event target body), capture phase: none. Target phase: body listeners fire (once-listener activateAudio), then bubble... document is not an ancestor of body in the capture sense — actually document IS an ancestor of body. During bubble phase, event bubbles from body → html → document. So body's listeners fire first (target phase), then document's (bubble phase). So activateAudio fires BEFORE startNote. activateAudio calls Tone.start() (async, returns promise, non-blocking), then startNote fires triggerAttack synchronously. So yes, race: triggerAttack before Tone.start resolves.

OK so the race is real. Let me implement the robust version. It's worth it.

Actually, let me reconsider even simpler: just DON'T auto-activate on keypress. Only the button triggers activation. This avoids the race entirely. When user presses a key before clicking button: startNote runs, audio not ready, triggerAttack on suspended context → note silently fails (or no sound), but active class shows. Then they click button, audio activates. Subsequent notes work. The first note is lost but that's acceptable and the UI clearly instructed them to click Enable Audio.

But losing the first note is a minor UX wart. The robust version (play pending on ready) is better. Let me implement the robust version. It's ~10 lines.

Let me also reconsider: maybe I'm overthinking and Chrome's AudioContext.resume() is fast enough that triggerAttack works. But I can't verify audio. The robust version guarantees correctness regardless. Let me implement it.

Let me rewrite the synth/active section.

Current:
```js
function startNote(id, note, type) {
  if (active.has(id)) return; // already held -> prevents auto-repeat duplicates
  active.set(id, { note, type });
  if (synth) {
    synth.triggerAttack(note, undefined, 0.22);
  }
  const el = keyElByNote[note];
  if (el) el.classList.add('active');
  console.log(`[piano] start ${note} via ${type} (id=${id})`);
}

function stopNote(id) {
  const v = active.get(id);
  if (!v) return;
  if (synth) {
    synth.triggerRelease(v.note);
  }
  const el = keyElByNote[v.note];
  if (el) el.classList.remove('active');
  active.delete(id);
  console.log(`[piano] stop  ${v.note} via ${v.type} (id=${id})`);
}
```

New:
```js
function schedulePlay(id) {
  const v = active.get(id);
  if (!v || v.played || !synth) return;
  if (audioCtxReady.val) {
    synth.triggerAttack(v.note, undefined, 0.22);
    v.played = true;
    console.log(`[piano] start ${v.note} via ${v.type} (id=${id})`);
  }
}

function startNote(id, note, type) {
  if (active.has(id)) return; // already held -> prevents auto-repeat duplicates
  active.set(id, { note, type, played: false });
  const el = keyElByNote[note];
  if (el) el.classList.add('active');
  schedulePlay(id);
}

function stopNote(id) {
  const v = active.get(id);
  if (!v) return;
  if (synth && v.played) {
    synth.triggerRelease(v.note);
  }
  const el = keyElByNote[v.note];
  if (el) el.classList.remove('active');
  active.delete(id);
  console.log(`[piano] stop  ${v.note} via ${v.type} (id=${id})`);
}
```

And in activateAudio success callback, after setting audioCtxReady.val = true, schedule all active:
```js
audioCtxReady.val = true;
for (const id of Array.from(active.keys())) schedulePlay(id);
```

This way, notes pressed before audio activation get played once audio is ready. And release only triggers for played notes.

Let me make these edits. Let me update startNote, stopNote, and add schedulePlay, and update activateAudio.

Let me also reconsider: the `console.log` for start was before. Now I moved it into schedulePlay. But if audio isn't ready, the "start" log won't appear until scheduled. For debugging, that's slightly less informative but fine. Actually, let me log start when the note is registered (in startNote) AND log that playback was scheduled. Hmm, simpler: keep the start log in startNote (registration), and schedulePlay handles the actual sound. But then the log doesn't reflect actual sound. 

For clarity in logs, let me log "start" at registration and if not scheduled, note "waiting for audio". Actually, let me keep it simple: log start in startNote, and schedulePlay. If audio not ready, the log says start but sound waits. That's fine for the console inspection.

Actually, cleaner: log in startNote "start (registered)" and in schedulePlay when actually triggering, the sound happens. Let me just keep startNote logging "start" and stopNote logging "stop". The schedulePlay is silent about timing. Good enough.

Wait, but if audio isn't ready, stopNote won't triggerRelease (since !played), but it still logs "stop". And start logged "start" but no sound. The logs would show start/stop without sound for that note. That's a bit misleading but acceptable. In practice, for the test flow (button first, then keys), audio is always ready, so all notes play normally.

Let me implement. Let me update the code.

Actually, let me reconsider whether to even bother. The test verification will click the button FIRST (as I did), so audio is ready before any note. The robust version helps only the edge case of pressing before the button. Given time constraints and that it's a correctness improvement, let me add it — it's clean and robust.

Let me make the edits.

Now let me reload and test again to make sure the refactored code works. Let me click Enable Audio, then play a note via mouse and keyboard.

Audio activated. Now let me play a white key (C4 at viewport 390, 440) and a black key (F#4 at viewport 600, 300).

C4 white key: "start C4 via mouse (id=mouse) [sound on]" → "stop C4 via mouse (id=mouse)". Works with the new "[sound on]" log confirming triggerAttack fired.

Now let me test the keyboard with the new flow. Let me press 'g' → G4, and 'k' → C5. Let me do 'g'.

Actually, I've verified white mouse, black mouse, and several keyboard keys. The refactor keeps everything working. Let me do one more keyboard test to be thorough, then I'm done.

Let me test 'g' → G4.

`g` → G4: "start G4 via keyboard (id=kbd-G) [sound on]" → "stop G4 via keyboard (id=kbd-G)". Works.

Everything is confirmed working. The file is complete and self-contained.

Let me do a final check that the file is present and there are no leftover debug lines.

No debug remnants. The file is clean. Both index.html and tone.min.js are present.

Let me do a final review of the complete file to make sure everything is correct and self-contained. Let me read the JS portion once more to confirm.

Actually, I've already reviewed the whole file. The implementation is complete and tested. Let me write the final summary report.

Let me verify the final JS section once more to be sure the edits applied cleanly (especially the activateAudio and schedulePlay).

The code looks clean and correct. Everything is wired properly:
- createSynth: PolySynth with ADSR envelope, maxPolyphony 13
- schedulePlay: only plays when audio ready, marks played
- startNote: guard against duplicates (auto-repeat), adds active class, schedules play
- stopNote: only releases if played, removes active class, deletes from map
- stopAll: releases all
- activateAudio: Tone.start() gesture, replays pending notes on resolve
- keydown: e.repeat guard, startNote
- keyup: stopNote
- mousedown on keys + document mouseup (release outside)
- window blur → stopAll

The file is complete, self-contained (single index.html with inline CSS/JS + local tone.min.js), no external resources.

I've verified via browser:
- Audio activation via button → "Tone.start() resolved; AudioContext is running."
- Mouse click C4 (white) → start/stop logged, [sound on]
- Mouse click F#4 (black) → start/stop logged
- Drag C4→outside → start then stop (release outside) ✓
- Keyboard 'a'→C4, 'w'→C#4, 'g'→G4, 'k'→C5 → all start/stop logged with [sound on]
- Note/key labeling: DOM confirmed all 13 notes with note names + key letters
- Mapping legend displayed
- Black keys correctly placed (no black keys at E-F, B-C gaps) — verified via rect positions
- Layout fixed (white keys in a row via flexbox)
- Console clean after debug removal

Unverified (due to tool constraints):
- Visual highlight appearance (can't view screenshots — model has no image support), but active class toggle is wired and confirmed via lifecycle logs
- Simultaneous 3+ note chords (tools' click/key are atomic press+release, can't hold multiple), but PolySynth maxPolyphony=13 + per-note triggerAttack guarantees this by design
- Audibility of sound (can't hear through tool), but AudioContext is running, triggerAttack executes without error, [sound on] log fires

The task is complete. Let me write the final summary.

Wait — I should double-check the worker CSP error doesn't actually break playback. The error: "Creating a worker from 'blob:...' violates worker-src 'none'". This is from Tone.js at load. Tone.js uses a Web Worker for some features (e.g., the Offline context / certain schedulers). However, for real-time PolySynth playback, Tone uses the AudioContext directly (AudioWorklets are registered via blob URLs too — "worklet" not "worker"!).

Wait — actually this might be an AudioWorklet issue. Tone.js 14 registers AudioWorklets via blob: URLs for the ToneAudioBuffers and some synth worklets? Actually, the default Synth in Tone 14 uses a standard OscillatorNode and GainNode (AudioParam), not a worklet. The worklet is used for things like Tone.AMSynth, FMSynth... Actually the basic Tone.Synth uses OscillatorNode with a WaveShaper or just GainNode, scheduled via the context. No worklet needed for basic Synth.

But the worker error appeared at module load (before synth creation). Let me check: is it blocking? My tests showed triggerAttack ran with [sound on] log and no error. So the basic synth path works without the worker. The worker is likely Tone's `Tone.Transport` or context scheduler enhancement that gracefully degrades.

Actually, the worker might be for `Tone.Context`'s offline scheduling or the `BufferSource` preloading. Since I got "AudioContext is running" and triggerAttack with no errors, playback should work. The worker error is non-fatal for my use case.

Actually, let me reconsider — is it possible the AudioWorklet registration failure would cause the synth voices to not actually produce audio? In Tone 14, Tone.Synth = Tone.Monophonic built on Tone.DuplexEffect? No. Let me recall: Tone.Synth in v14 extends Tone.MonoSynth? No. Tone.Synth creates an oscillator, amplitude envelope via GainNode + setTargetAtTime/exponentialRamp. The envelope uses standard Web Audio GainNode automation — no worklet required.

The PolySynth wraps multiple Synth (voice) instances. triggerAttack/Release on each. So no worklet needed. The worker error is benign here.

But to be SURE audio actually plays, I'd want to hear it. I can't. However, the absence of runtime errors after triggerAttack, plus "AudioContext is running", strongly indicates the audio graph is functional. The Tone.js startup message ("%c * Tone.js v14.8.49 *") confirms it loaded.

Actually, wait — let me reconsider the worker error more carefully. It says "Creating a worker from 'blob:...url...' violates worker-src 'none'. The action has been blocked." This means Tone.js tried to create a Worker and the CSP blocked it. If Tone.js needs that worker for the audio context's scheduling, audio might not work.

But Tone.AudioContext (base) — in v14, the default offline/audio context... The main Tone.Context uses the real AudioContext. The worker might be for Tone.Offline() (offline rendering). For live playback, no worker needed.

Hmm, but actually Tone 14.8.49 — let me check if PolySynth/Synth requires the worklet or worker for anything. Let me grep tone.min.js for the worker creation to confirm it's optional.

Let me check by grepping for "worker" / "Offline" in tone.min.js, and check if there's a fallback. Actually, the key question: does triggerAttack produce audible output? Let me verify by a different means — I can check if the AudioContext has nodes. But I can't inspect audio.

Actually, let me reconsider — maybe I can verify audio works by checking Tone.Destination's output. Let me not over-think. The most reliable verification: write a tiny test that creates a buffer source or checks context.state. Actually, I already have "AudioContext is running".

Let me try a more direct test: does the page produce audio when I play? I can't hear. But let me check if there's a way to infer. 

Alternative: Let me verify by checking if Tone.Offline or the worklet is essential. Let me grep tone.min.js.

Actually, the worker error might be from Tone's use of `Tone.Worker` which Tone uses internally for... hmm. But many apps use Tone.Synth without workers fine. The CSP blocking a worker is common in sandboxed iframes and Tone degrades gracefully.

Let me just confirm playback works by checking that no error occurs during triggerAttack (which I did — [sound on] logged after triggerAttack with no error). If triggerAttack threw or the context was suspended, there'd be an error. The AudioContext is "running" (resumed). So playback should be audible.

Actually, let me make doubly sure the worker error isn't fatal. Let me check whether Tone.js falls back. Let me grep.

The worker is `Tone.Worker` which is used internally by some Tone.js scheduling features (like the Transport or context's offline scheduler). The single `new Worker` is in a generic Worker class. The `AudioWorklet` references (29) are for audio processing. The CSP blocks the `Worker` (not worklet — worker-src blocks Worker, AudioWorklet uses worklet-src typically, but here it says worker-src 'none').

Actually the error says "worker-src 'none'" which blocks `new Worker`. The `AudioWorklet` uses `worklet-src` directive, not `worker-src`, so AudioWorklet registration might still work OR fail with a different error. I didn't see a worklet error in the console, only the worker error. So AudioWorklets (if any) registered fine, and only the generic Worker (Tone.Worker) was blocked.

Tone.Worker is used by Tone.Transport for high-precision scheduling, and by some envelope/scheduling. But for direct `PolySynth.triggerAttack` which uses the AudioContext's `currentTime` and standard Web Audio node scheduling (GainNode.setValueAtTime / setTargetAtTime), NO worker is needed. The Synth's ADSR envelope uses GainNode automation.

So playback works without the worker. The worker is only for Transport-based scheduling (which I don't use — I call triggerAttack directly with absolute time).

Good — playback is functional. The [sound on] log confirms triggerAttack executed successfully after AudioContext became running, with no errors.

I'm confident the implementation is complete and working. Let me finalize. The file is already saved (I've been editing it). Let me just confirm it's the final version and present it.

The task: "End with index.html present." It is present. Let me do a final verification that the file on disk is the final version (it is — I've been writing to it).

I have ~4 minutes left. Let me not over-test. The implementation is complete. Let me provide the final report.

Actually, let me reconsider one thing: I should make sure the final file on disk has all my latest edits (the schedulePlay refactor, pointer-events fix, flexbox fix, label repositioning). I've confirmed via reload that the latest version works (the 'g'→G4 test showed "[sound on]" which is from the refactored schedulePlay). So the file is current.

The task is complete. Let me write the final report.

Let me also reconsider: are there any remaining "essential issues" I should fix? Let me think:
1. The worker CSP error is non-fatal (playback works via direct triggerAttack). Not essential to fix.
2. Visual highlighting: can't verify visually but wired correctly.
3. Polyphony/chords: can't test holding multiple keys with atomic tools, but PolySynth guarantees it.

One thing I could improve for observability of highlighting without being able to see images: the highlight is wired. It's fine.

I'm done. Let me finalize with a report. The file is saved.

Actually, let me reconsider whether I should verify the file is truly the final version one more time with a quick grep for the key markers.