Fireworks · qwen3.8-flash

Let me build the app and test it with the browser tools.

Let me check the working directory first.

Let me write the index.html file. I'll design a nice fireworks display:

- Full-screen canvas, dark night sky gradient, stars, maybe city silhouette at bottom.
- Click launches a shell from bottom (near the clicked x, or from a launcher base) upward toward the clicked location; explodes at target.
- Physics: gravity, drag, fade, lifetime removal.
- Trails: use fading composite layer (fillRect with low alpha) for trail effect, plus per-particle trail history.
- Controls: Clear button, plus maybe toggles (auto-show, trails). Keep controls usable after resize — fixed-position HTML overlay UI (DOM buttons), so resizing doesn't break.
- DPR handling on resize.

Implementation details:

Canvas rendering with 'lighter' composite for glow. Trails via offscreen "glow" canvas that we fade each frame by drawing a semi-transparent black rect (globalCompositeOperation='destination-out' with alpha) — better: keep a trail canvas and apply destination-out fade so trails persist but fade. Then main canvas clears each frame and draws background, then trail canvas composited with 'lighter'.

Simpler approach: single canvas, each frame draw background gradient with alpha 0.18 (so old pixels fade toward background) — this creates trails naturally. But background stars would smear... Actually redrawing background with low alpha repeatedly lets stars stay crisp if redrawn at full alpha each frame — no, that would cover trails.

Best: two canvases layered via CSS:
1. Background canvas (or CSS gradient + stars drawn on a static canvas) — redrawn rarely.
2. FX canvas with trail fade: each frame, ctx.globalCompositeOperation='destination-out'; fillStyle='rgba(0,0,0,fadeAmount)'; fillRect → fades existing pixels. Then draw with 'lighter'.

FX canvas is transparent, showing background canvas beneath. destination-out fade reduces alpha → trails fade out revealing background. That works nicely.

Also give particles explicit trail history for streaks? The composite trail is enough, plus shells get a bright streak.

Shell physics: launch from ground at x near click (offset), with velocity aimed so it reaches target. Compute: to reach apex at target height with gravity g: vy = -sqrt(2*g*rise). vx = (targetX - startX)/timeToApex. Explode when particle reaches apex (vy >= 0) or when within small distance of target, or lifetime expired. That keeps launch-to-burst visible.

Burst types: peony (radial), chrysanthemum with trailing sparks, ring (flat ellipse), willow (long life, heavy gravity), crackle/strobe. Include secondary bursts for some shells (multi-break). Colors: palette of hues, plus gold/white.

Also add: sparkle crackle particles, glitter flicker.

Auto demo shell on load: schedule a launch at initial load (e.g., 400ms after load) targeting near center-upper sky. Requirement says "Launch one demonstration shell automatically on initial load" — do exactly one immediately-ish; plus optional "Auto show" toggle default off? Hmm, an auto-show toggle that runs periodic shells could be default off to keep "one demonstration shell" literal. I'll make default auto-show ON but the first one fires at load immediately... Risk: verification checks "one demonstration shell automatically on initial load". Either is fine as long as a shell appears without interaction. I'll have: single scripted demo shell at ~600ms after load; and an "Auto show" checkbox (default off) that launches random shells periodically for ambience. Keep default off so the initial state is clearly the demo shell.

Controls: Clear (removes shells, particles, and clears trail canvas), Auto show toggle, Trails toggle maybe, Sound? no. Keep: Clear, Auto show, and a hint text. Also "Burst size"? Keep simple: Clear + Auto show + maybe "Sky trace" fade slider. I'll do Clear, Auto show checkbox, Trail length slider.

Show counts (shells/particles) for verification feedback — useful.

Also touch support (pointerdown).

Let's write the code.

Key structure:

```js
const fx = canvas.getContext('2d');
let W,H,DPR;
resize();
addEventListener('resize', resize) // keeps controls usable (CSS fixed positioning), resizes canvases, re-renders background
```

Particles array; shells array.

Physics constants in CSS pixels per second, use dt clamped.

g = 900 px/s²? For a 800px tall screen, launch to apex ~ at 0.55H: rise = 440 → vy = sqrt(2*900*440)= ~890 px/s, time = ~1.0s. Reasonable (flight ~1s visible).

Air drag: particles velocity decay: v *= (1 - drag*dt), drag ~0.9 for burst sparks; gravity applied.

Trail canvas fade: each frame apply destination-out with alpha = 1 - Math.exp(-dt * fadeRate) where fadeRate ~ 2.5 (trail length).

Particle rendering: draw as small radial glow + bright core, using 'lighter'.

For efficiency, precompute sprites per color? Simpler: use shadowBlur? shadowBlur is slow. Use a cached sprite canvas of a radial glow (white), drawn with globalCompositeOperation='lighter' and tinted... tinting requires per-color sprites. Alternative: draw circles with fillStyle rgba and a couple of layered circles (outer big low alpha, inner small high alpha) — cheap enough for ~2000 particles. Let's cache glow sprites for a palette of hues: build 32 hue-sprite canvases at 32px. Then drawImage with globalAlpha and scale. That's fast and glowy. I'll do hue sprites.

Sprite creation: for hue h (0-360 step 15 → 24 sprites), create 64x64 with radial gradient: center white-ish (hsl(h,100%,88%)) → hsl(h,100%,55%) → transparent.

Plus a white/gold sprite for sparks.

Particle types:
- 'spark': main colored particle, radial burst velocity.
- 'glitter': slow, flickers on/off.
- 'trailhead': shell.
- 'crackle': strobing white flecks, appear after delay.

Implement particle: {x,y,vx,vy,life,maxLife,size,hue,sat,lite,type,drag,fadePow, flickerSeed, delay}.

Also secondary "multi-break": at burst, small chance the shell spawns a mini-shell that flies a short distance and bursts again — could be nice but adds complexity; instead a fraction of fast particles that explode after delay (comet children). Let's include: type 'bomb' particle which after delay spawns small burst. Nice touch.

Background: static canvas: vertical gradient deep navy → near black; stars (random, some twinkle—static ok), moon glow, distant city skyline silhouette with a few lit windows, ground/hill, and haze at horizon. Redrawn on resize only.

Also reflection? Skip.

Let me also add a subtle "sky glow" flash on burst: draw radial flash on fx canvas at burst.

UI: top-left panel with title, buttons. Bottom-center hint "Click the sky to launch". Keyboard: Space = random shell, C = clear.

Now write it.

Also fps-independent dt loop with requestAnimationFrame and dt clamp 1/30.

Verification: I'll use browser tool: screenshot, then click at coordinates, then inspect state via console? The browser tool has actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. `inspect` presumably returns DOM/console. I can use console.log in the app and read console via inspect. To sample ascent/burst/fall I can expose a debug hook: window.__fw = {stats, launch(x,y)} and log events. I can read console through inspect. Let's add a debug global `window.fireworks` exposing launch and counts, and console.log on burst events (only in a lightweight way — maybe log shell lifecycle when `?debug`... Simpler: expose object, and log events always but concise: `[fw] shell #3 exploded at (x,y) -> 180 particles`. Console messages are fine for a demo, but too noisy for production feel. I'll gate detailed logs behind a `debug` flag set true when URL contains debug or when window.__FWDEBUG set... The sandbox may not allow me to set globals? The browser tool has no evaluate action, only click/key/etc. Hmm. I can rely on console.log from the app itself — always log lifecycle events. That's acceptable and helps verification. Keep it modest: log on burst with counts, and on clear.

Actually to sample ascent/burst/fall I'd like a time series. I can add periodic debug logs from the app: a setInterval every ~250ms while debug enabled... but no way to toggle. Alternative: take multiple screenshots over time (screenshot action after clicks) and visually check. Also I can use `motion` action to capture frames over time — that gives a sequence of frames which is exactly what I want for sampling ascent, burst, and fall.

Plan: reload, screenshot initial (demo shell should be ascending/exploding), motion capture over ~1.5s to see burst, click somewhere, motion again, then check DOM stats via inspect (the HUD shows counts — inspect returns DOM so I can read counters). Then click Clear, inspect HUD to confirm 0 shells/0 particles, screenshot to confirm empty scene.

Let me write the file with a HUD showing "shells: n · particles: m" so inspect gives me numbers. Good.

Console: log demo launch, launch on click, burst events, clear. Keep them.

Let's write code carefully.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=no">
<title>Nocturne — Fireworks</title>
<style>...</style>
</head>
<body>
<canvas id="sky"></canvas>
<canvas id="fx"></canvas>
<div class="vignette"></div>
<div id="ui"> ... </div>
<div id="hint">Click the sky to launch a shell</div>
<script>...</script>
</body>
</html>
```

CSS: html,body{height:100%;margin:0;overflow:hidden;background:#04060f}; canvases position:fixed inset 0 width100% height100%; #fx z-index 2; ui z-index 5 with pointer-events auto on panel; hint bottom center fading.

Panel style: glassy dark, blur, rounded, small caps typography, buttons with hover.

Now JS.

```js
const skyC = document.getElementById('sky'), fxC = document.getElementById('fx');
const sky = skyC.getContext('2d'), fx = fxC.getContext('2d');
let W=0,H=0,DPR=1;
const rand=(a,b)=>a+Math.random()*(b-a);
const pick=a=>a[(Math.random()*a.length)|0];
```

Sprinkles: stars drawn into background with slight glow.

resize(): DPR = min(devicePixelRatio||1, 2); W=innerWidth; H=innerHeight; set both canvases width/height = W*DPR; style handled by CSS 100%; setTransform(DPR,0,0,DPR,0,0). Then paintBackground(); also clear fx (resize resets fx canvas automatically). Note: setTransform for sky after resize (resize clears).

Gravity constants scale with H: G = Math.max(600, H*1.05) px/s²? For H=800: 840. fine. Recompute on resize.

Shell:
```js
class Shell{
 constructor(tx,ty){
  this.x = clamp(tx + rand(-40,40), 20, W-20);
  const startX = this.x;
  const rise = Math.max(60, this.startY - ty) // startY = H - groundY
  ...
 }
}
```
Launch from bottom: y0 = H - 8 (ground). rise = y0 - ty. vy0 = -Math.sqrt(2*G*rise). time = -vy0/G (apex time). vx = (tx - x0)/time.

Start x: I want the shell to rise "from the bottom of the scene toward the clicked location" — launch position slightly offset from target x for a nice arc, or straight up from below the click. Let's launch from x0 = clamp(tx + rand(-120,120)) but also bias toward a ground launcher position. Actually a mild arc looks better and clearly shows the trajectory toward the clicked location. Use offset = rand(-0.16, 0.16)*W*? Keep: offset = tx<W*0.5? +rand(30,140) : -rand(30,140)? Simpler: x0 = clamp(tx - rand(-1,1)*Math.min(160, rise*0.35), ...). Let me pick x0 = tx + rand(-1,1)*Math.min(140, rise*0.25) clamped to [16, W-16]. So the shell travels up and over toward the click. Good, and target still = click.

Explode when: apex reached (vy >= -20) OR distance traveled time >= flightTime OR y <= ty (passed target). Use: this.t += dt; if (this.t >= this.flight || this.vy >= 0) explode. Since flight is exact time to apex, use this.t >= this.flight.

Also cap flight so short clicks near ground explode quickly: rise min 60.

Shell rendering: bright head with sprite (hue from shell color), plus ember trail particles emitted each frame (small, short-lived, drifting down). The fx trail-fade handles the streak.

Burst: create particles by pattern:
patterns: 'peony','chrys','ring','willow','palm','crackle','double'.

Base: N = 90..170 sparks at speed rand(0.25,1)*burstSpeed, slightly biased spherical with random speed distribution → ring-ish look? For peony: uniform speed up to max with sqrt distribution for even disc. Use angle uniform, speed = maxSpeed*Math.sqrt(Math.random()) for disc; for shell-like hollow sphere look: speed = maxSpeed*rand(0.75,1).

Color: hue base + variants; some shells two-tone.

Willow: fewer, longer life, higher drag, gravity dominant, gold hue ~45, sat .5, sparkle.

Ring: velocity in ellipse: angle uniform, speed = maxSpeed*(0.95 + small noise), with slight vy scaling 0.5 to look like ring in 2D; hue cyan/white.

Palm: 12 thick comets with trailing sparks.

Crackle: after main burst, add 'crackle' particles with delay 0.25-0.6 that flash white.

Multi-break: some bursts spawn 'child' bursts at delay: particle type 'bomb' with timer, on explode create small burst at its position and add flash.

Glitter: for willow/palm add 40 glitter particles with flicker.

Particle update:
```js
p.t += dt;
if (p.t < p.delay) continue-ish (but still move? crackles: hold position w/ velocity zero) 
p.vx *= (1 - p.drag*dt) ... use factor = Math.exp(-p.drag*dt)
p.vy = p.vy*factor + G*p.grav*dt  // apply gravity
p.x += p.vx*dt; p.y += p.vy*dt;
const k = 1 - p.t/p.life; alpha = k^p.fade (k*k maybe)
```
Kill when p.t >= p.life or (p.y > groundY && p.life left small) — let particles die at ground with fade.

Render particle: size = p.size * (0.4+0.6*k); alpha; use sprite drawImage:
```js
const s = size* (p.hard? ...); fx.globalAlpha = alpha; fx.drawImage(spr, p.x-s/2, p.y-s/2, s, s);
```
Composite 'lighter'.

Sprite per hue index: sprIndex = ((hue/12)|0)%30 for 30 hues at 12° steps. Sprite size 64 with glow radius.

Also draw a bright core: for alpha>0.5 draw small white dot via fillRect(1-2px) with 'lighter' — cheap.

Trail fade per frame on fx:
```js
fx.globalCompositeOperation='destination-out';
fx.fillStyle = `rgba(0,0,0,${fadeA})`; fx.fillRect(0,0,W,H);
fx.globalCompositeOperation='lighter';
```
fadeA = 1 - Math.exp(-dt*trailRate); trailRate from slider (1.2 slow → long trails, 6 short).

Hmm: destination-out with alpha a reduces alpha by factor (1-a) each frame — geometric fade. Good.

Flashes: on burst draw radial white glow (sprite big, low alpha) — it fades with trail.

Auto demo: on load, after fonts, launch 1 demo shell: target (W*0.5, H*0.32). Also a couple extra? Requirement: "Launch one demonstration shell automatically on initial load". I'll launch exactly one demo shell on load; if "auto show" is on, keep launching random ones every ~900-1600ms (default off). Hmm, a fireworks display with auto show default off looks static between clicks but that's fine and matches spec. Maybe default auto show ON is more delightful... The spec's "subsequent shells respond to clicks" implies demo then clicks. I'll default autoShow = false but add it as toggle clearly labeled. Actually let's default it ON? Risky for "one demonstration shell on load" check? The check just needs visible effect before interaction. Extra shells don't hurt. But auto shells could make Clear verification noisier — Clear + autoShow on would immediately repopulate. Better default OFF so Clear leaves empty scene. Yes: default off.

Clear(): shells=[], particles=[], flashes cleared; fade fx canvas fully (clearRect); log "[fw] cleared — removed N particles".

Stats HUD updated every frame (throttled 6/s): shells, particles, fps.

Pointer handling: pointerdown on window; ignore if event target inside UI panel (check e.target.closest('#panel')). Launch toward (x, y) but clamp y to < H*0.78 so bursts happen in sky; if clicked low, target y = min(y, H*0.72). Also show a click marker? add small ground flash at launcher point.

Also add a "launcher" glow at the launch base each launch, brief.

Keyboard: Space → launch random target; C → clear; A → toggle auto.

Prefers-reduced-motion? Not required.

Let me write it now. Careful with syntax.

Sprite generation:

```js
function makeSprite(hue, sat, lite){
  const S=64, c=document.createElement('canvas'); c.width=c.height=S;
  const g=c.getContext('2d');
  const grd=g.createRadialGradient(S/2,S/2,0,S/2,S/2,S/2);
  grd.addColorStop(0,`hsla(${hue},${sat}%,${Math.min(97,lite+32)}%,1)`);
  grd.addColorStop(0.25,`hsla(${hue},${sat}%,${lite}%,0.95)`);
  grd.addColorStop(0.55,`hsla(${hue},${sat}%,${lite-10}%,0.35)`);
  grd.addColorStop(1,`hsla(${hue},${sat}%,${lite-20}%,0)`);
  g.fillStyle=grd; g.fillRect(0,0,S,S);
  return c;
}
```
Store SPR array of 30 hues (0..348 step 12), all sat 100, lite 60. Plus a gold sprite at hue 45 sat 90 lite 62 (covered by index 45/12=3.75 → 36 or 48). Fine.

Background painting:

```js
function paintBackground(){
  const g=sky.createLinearGradient(0,0,0,H);
  g.addColorStop(0,'#04061a'); ... '#02030a'
  sky.fillStyle=g; sky.fillRect(0,0,W,H);
  // milky way band? subtle
  // stars
  for(i<count) draw 1px..2px with alpha; some with tiny glow
  // horizon glow (city light pollution)
  // skyline silhouette: buildings from seeded random so stable across resizes? use seeded PRNG.
  // windows
  // ground
}
```
Use seeded rand for stars/buildings so they don't flicker on resize: mulberry32 with fixed seed, re-seeded each paint.

Let me write skyline: base = H*0.86 ground line; buildings widths 30-90, heights 20-160 above base, colors near black '#05070f' with slight purple rim; windows tiny 2x3 rects in warm '#ffd27a' alpha .5 sparsely.

Then a hill/ground: fill from base to H with '#03040a', plus a thin reflective line.

Also draw the launch pad area? The shells launch from y = groundBase (H*0.9?) Let's set GROUND = H - Math.max(10, H*0.04) — near bottom.

OK write the file.

Sizing: keep code tidy, ~400 lines. Let's produce it.

Additional: cap particles at ~4000, remove oldest if exceeded.

Let me write.

There's a leftover weird line: `if(autoShow){ autoTimer -= dt; if(autoShowTimer() ) {} }` — let me clean that up. Also `const k = 1;` unused in shell draw. Let me fix these before running.

Also in particle loop: `if(p.t >= p.life){ if(p.brk){...} ... }` — leftover odd logic; the brk should trigger before life ends (it does at t >= delay+life*0.55). Let me simplify: remove the empty if.

Also `p.y > GROUND+8 && a<0.4 continue` — fine (culls faded ground particles visually but they still exist; they die at life end). Ok.

Let's fix those lines.

Also `autoTimer = 0.15` in the auto checkbox change handler - fine since loop decrements.

Now the `emitter` function: `const hue2 = o.hue2 !== undefined ? o.hue2 : (pal.h + rnd(-10,10));` — for burst() we pass hue2: undefined → random second color. Good.

Now syntax check with node. Extract the script and run `node --check`.

grep exit 1 means no matches — good (no leftover references). Now run in browser.

The backdrop looks good. Now I need to verify the demo shell. The reload happened at t=0; the demo shell launches at 450ms. The screenshot was taken presumably immediately. Let me capture motion frames to see the demo shell ascent and burst. But motion likely captures starting now, ~seconds after reload, so the demo shell is gone. Let me reload then immediately do motion.

Let me check the motion action parameters — it probably captures a sequence of frames. Let's try: reload, then motion.

Now capture motion frames right after reload to see the demo shell (launch at 450ms, apex ~1s later).

Found the bug: `emitLaunch is not defined` — a leftover call in the Shell constructor. The Shell constructor throws, so no shells ever launch. Remove that line.

Also note the animation loop seems to have stopped? fps showed 58/60 so loop is running. Good.

Fix: delete `emitLaunch(this);`.

Also the `p.brk` logic: `if(p.brk && f >= p.life*0.0 && p.t >= p.delay + p.life*0.55 && !p.done)` — `f >= 0` always true; simplify but harmless. Let me clean it: `if(p.brk && !p.done && p.t >= p.delay + p.life*0.55)`.

Also `void rot;` leftover — harmless but clean it.

Let me also double check `emitter` uses `pal` variable unused when hue2 given — fine.

Apply small cleanups then reload.

Now `f` variable in particle loop is used for flick: `const f = p.t - p.delay` — still used in flick calc. Good.

Reload and capture motion to see demo shell ascent + burst.

Now capture motion — but the demo shell launched at 450ms after load; motion starts now (maybe a second later). The chrys burst life 1.5-2.5s so we may catch it. Let's do motion immediately.

Problem: The console logs show launch and burst happened, but the visuals show only faint trail streaks — the particles themselves are barely visible, and the HUD says "shells 0 particles 0" (stale HUD? no, hud() is called every frame now... it says 0 particles at the time of inspect, which is after everything died? Actually the motion frames span 1.8s, and the burst happened at ~1.06s after launch. Hmm the HUD text in the result is from the end of capture — particles should still be alive at 1.8s after burst (life 1.5-2.5s). But it says 0.

Wait — big issue: the frames show a huge dim blue circle (the flash!) and faint streaks. The particles appear nearly invisible. Why?

Possible cause: `fx.globalCompositeOperation = 'lighter'` set at start of frame; then drawImage of sprites should add light. But the giant circle is a flash with radius min(420, n*2.2)=255... Actually the circle looks ~250px radius centered near (600,250). Yes, that's the flash. It's drawn with radial gradient 'rgba(255,250,235,.5)' at center → should be bright white-ish, but it appears dim blue. Because globalAlpha 0.5*q.a and gradient... hmm it looks washed.

But the particles: they should be bright dots. They're not visible at all in frames 2-4. And the trail streaks are visible (faint). So the particles' drawImage is producing very little light? Or the particles are being removed immediately (parts.splice when p.t >= p.life — life is 1.5-2.5s, fine).

Wait — HUD says particles 0 at the end of the capture. So particles ARE gone. Let me think: In the loop, `p.t += dt; if(p.t >= p.life) splice`. life ~ rnd(1.5,2.5). The burst happened at frame... The motion capture started ~? Reload then motion: reload happened, then the motion call maybe ~1-2s after reload. Launch at 450ms, burst at ~1.5s. So motion frame 1 might be at ~1.5s. Hmm, frame 1 shows the streaks already faded and the big flash circle... Actually the flash circle is present in all frames, which is odd since flashes decay in ~160ms.

Unless... the animation loop stopped! The persistent flash circle and static streaks across frames suggests the canvas is frozen — the last rendered state persists, and the trail fade isn't progressing. But the trail streaks are still visible at all (they'd fade).

Wait, the HUD in the inspect result shows "particles 0" and fps 58/60 — so the loop IS running (fps updates). Hmm, but if the loop is running and particles are 0, then the flash circle shouldn't persist either (flashes decay fast).

Unless the flash circle is not a flash but... the "trail" residue of the burst particles' glow? No, that would spread.

Hmm, look again: the big circle is centered around (600, 250) with radius ~250 — exactly the flash radius (min(420, 116*2.2)=255). And it's blue-ish dim. And the streaks going down from the burst region to the ground... those are the falling particle trails! Yes! The streaks radiate downward from the burst — that's the particle trails, but the particle heads are invisible.

So the particles are rendering their trails (via the destination-out fade leaving residue) but the heads are invisible. Why? Because... `fx.drawImage(spr(p.hue), p.x-s, p.y-s, s*2, s*2)` with globalAlpha a. Hmm.

Oh! I see the bug. In the shell draw loop and particle draw loop, `fx.globalCompositeOperation` is 'lighter' — fine. But wait, the flashes loop sets `fx.fillStyle = g` — fine.

Hmm, why would heads be invisible but trails visible? Trails ARE made by the heads' pixels fading gradually. If heads were invisible, no trails. Unless the trails come from the wisp sub-particles... The chrys pattern has wisp, which spawns small particles. Those create the streaks.

Actually maybe the issue: the streaks are the *shell's ascent trail*? No, they fan out from the burst point downward.

Let me reconsider: maybe the frames are showing a state where particles have mostly died (life 1.5-2.5s with fade^1.8 → alpha drops quickly), and the residue trails are what remains, and the flash circle... hmm the flash circle in all 4 frames identical means the canvas isn't being updated — i.e., the rAF loop might be paused while screenshots happen? No, motion captures at intervals.

Actually! Key insight: the flash circle persists because the *trail fade* is slow (rate = 0.6 + (1-0.62)*7.5 = 3.4/s → alpha decays e^-3.4t; after 1.8s, factor e^-6 = 0.0025 — nearly gone). So a static circle persisting over 1.8s contradicts the fade... unless the flash is being redrawn each frame — meaning flashes array has entries with a decaying slowly? q.a -= dt*6.5 → gone in 0.15s.

Hmm, alternatively the circle is drawn by `paintSky`? No, that's the sky canvas — the milky band loop draws 26 radial gradients of radius max(W,H)*0.11 = 132... those are on the sky canvas. Not it.

Wait — maybe it IS on the sky canvas: the moon glow? No, that's at (1008,120).

Let me look at the first screenshot (initial reload, before motion): no circle. Then after motion, the circle appears. So it's from the burst.

Possibility: the flash gradient is drawn with `createRadialGradient` and `rgba(255,250,235,.5)` center... on the fx canvas with 'lighter'. Then it persists in the trail buffer and decays. Over 1.8s at rate 3.4/s it should be invisible. Unless the fade isn't working as expected: destination-out with fillStyle rgba(0,0,0,alpha) reduces alpha of destination. Yes that works.

BUT: I set `fx.globalCompositeOperation='destination-out'` then fillRect, then set back to 'lighter'. Hmm, but there's a subtlety: after resize, setTransform is applied; fillRect(0,0,W,H) covers the whole canvas in CSS px — correct with the DPR transform.

OK, rather than theorize, let me add a debug hook and inspect actual state. But I can't evaluate JS in the page... I can only read console logs. So let me add periodic diagnostic logging of counts (e.g., every 500ms log shells/particles/flashes) temporarily, plus log in frame whether particles are drawn. Actually the HUD already shows particles count — and it showed 0 at the end. Let me capture motion right after reload with less delay, and also check the HUD text at each frame — the motion output only gives one DOM snapshot (at the end, presumably).

Better plan: add a temporary debug interval that logs counts every 300ms for 3 seconds. Then reload + motion and read the console. Let me instead make it permanent but lightweight? No — I'll add temporarily and remove after.

Actually, there's another explanation for the giant circle: `flash(x,y,Math.min(420, n*2.2),'rgba(255,250,235,.5)')` — n=116 → 255. And second flash radius min(260, n*1.3)=150 with hsla hue 200 (blue!). The visible circle is blue-ish and radius ~250. So both flashes. They'd decay.

Unless... `q.a -= dt*6.5` and I draw with `globalAlpha = clamp(q.a,0,1)*0.5` — that's fine.

Hmm, what if the frame loop is throwing an error each frame after the burst, so the canvas freezes with the last drawn state (the flash) and the trail fade stops? But fps updates... Actually the HUD showed fps 58/60 both in the frozen case? If the loop threw, hud() wouldn't update and fps would stay at 60 initial. The inspect showed "fps 58" in the first motion run and "fps 60" in this one. Hmm, in run 1 (error case) fps 58 — the loop was running fine (error was in Shell constructor, outside the loop).

In this run, the console shows no errors. But maybe an error occurs during burst() — e.g., inside emitter for 'chrys'... no error logged though. Console errors would appear in the console list. The list shows launch + burst logs, no errors. So the loop is running.

So why does the circle persist? Let me reconsider: maybe the circle is NOT persisting — maybe each of the 4 frames captured a different moment and I'm misreading. All 4 frames show a similar circle. If frames are 0, 608, 1220, 1815 ms apart, and the burst occurred before frame 1... then the circle should be gone by frame 2. Unless the burst occurred at frame 3-4 time. Hmm, but the circle is in frame 1 too.

Wait, maybe the "circle" is the shell's ascent trail... no.

Alternatively, maybe the trail fade is broken: `1-Math.exp(-dt*rate)` — if dt is 0 (two rAF in same ms) → alpha 0 → no fade. Fine normally.

Hmm, what if `fx.fillRect` with 'destination-out' isn't fading because... Actually! I know. `fx.globalCompositeOperation = 'lighter'` is set at the start of each frame AFTER the fade. But in the *flashes* loop I create gradients and fill; those pixels are added. Then next frame fade removes them. Should work.

Let me test empirically: add a debug log every 400ms with counts, and also log fade alpha. Let me do a quick instrumented run.

Actually, a simpler hypothesis that explains everything: **the particles are drawn but with globalAlpha ~0** because of the fade exponent... no, then no trails.

Hold on. Look at the streaks: they radiate downward and are quite long and *static* across frames — consistent with a frozen canvas (no fade). And the circle static too. So the fx canvas IS frozen. That means the rAF loop stopped rendering to fx, but the HUD updated (fps 58/60, particles 0)... 

Unless the HUD "particles 0" is from the last hud() call before the loop stopped. But then fps would be stale too.

Hmm, what if the loop is running but extremely slowly (e.g., 1 fps due to huge particle count?) — no, particles 0.

What if an exception is thrown inside frame() after the flash drawing... The console list might only capture errors that reach window.onerror — an exception inside a rAF callback DOES produce an uncaught error in console. The motion console list showed no such error. But maybe the console capture only records up to some point, or dedupes?

Let me just add explicit diagnostics. I'll add a temporary `dbg` logging in the loop: every 500ms log counts and whether fade ran. Then reload and read.

Another thought: `if(p.y > GROUND + 8 && a < 0.4) continue;` — irrelevant.

Also: in the particle draw, `fx.drawImage(spr(p.hue), ...)` where `spr(hue)` returns SPR[index]. p.hue could be NaN? `hue: Math.random()<0.72 ? hue : hue2` — hue from shell 200 ± ... fine. `spr()` with NaN → SPR[NaN] → undefined → drawImage(undefined) throws TypeError! For chrys, hue2 = pal.h + rnd → defined. Not NaN.

Hmm but for 'ring' pattern: `hue: hue + Math.sin(a)*10` fine.

OK let me instrument. I'll add a debug block at the end of frame():

```js
if(window.__FWDBG && now - lastDbg > 400) console.log(...)
```
No, can't set globals. Just add temporary unconditional logging and remove later.

Let me add: every 400ms: console.log('[dbg] shells='+shells.length+' parts='+parts.length+' flash='+flashes.length+' fadeA='+...+' W='+W+' H='+H).

Also wrap the frame body in try/catch to log errors: `catch(e){ console.log('[fw] frame error: '+e.message) }` — that would reveal a thrown error. Actually, better: add a window.onerror handler that logs. Let me add temporarily.

Let me do it.

Note: `hud()` is inside the try now, and `rate` is defined earlier in the function — but `rate` is declared with const inside the frame function before use, so accessible. Yes, `const rate` is declared in the fade block at top of frame. Good.

Reload + motion.

Now the motion capture: I want to catch the ascent. The demo shell launches 450ms after load. The reload tool returns immediately; the motion call happens after. There may be a delay of ~1s between calls (tool overhead). Let's try motion now and read the debug logs.

Now I have real data:
- Physics/lifecycle works: shells 1 → burst → parts 494 → decays to 0.
- Rendering: the fx canvas is NOT being cleared/faded between frames (frames 2,3,4 look identical even though particle counts changed drastically; and the huge circle persists). The screenshots show the *sky canvas* plus... hmm.

Key: the trail residue persists and the images are identical → the fx canvas isn't updating visually, OR the screenshots are cached/stale? Frame 1 differs slightly (particles 134 in HUD vs 0). So frame 1 was captured at a different time. Frames 2-4 identical even though particles went 494 → 0.

So the fx canvas appears frozen after the burst. And the visible "circle" is a burst flash that stays forever. And the streaks are the falling-particle trails that stay forever.

Why would the fade not work? `fadeA=0.056` is logged — the fade is being computed. But wait: the fade uses 'destination-out' fillRect. That should reduce alpha. Unless... `fx.globalCompositeOperation = 'destination-out'` then fillRect... then I set it back to 'lighter'.

Hmm! I bet the problem is the flash drawing: `fx.fillStyle = g` with a radial gradient — but I never reset... no.

Oh! I see it! The **flashes are drawn with 'lighter'** and each frame the flash is drawn at decreasing alpha, but the residue stays because the fade isn't actually clearing. Let's test the fade hypothesis: if fade worked, the streaks (drawn once when particles passed) would decay with e^{-3.4t}: after 1s → 0.03. They persist over 1.7s+. So the fade is definitely NOT removing pixels.

Why? Because of `fx.globalAlpha`? No — I logged op=1 at end of frame. But the fade fillRect happens at the START of the frame, where globalAlpha might be... let's trace: at end of frame I set `fx.globalAlpha = 1`. Then in the fade block, globalAlpha is 1. OK.

Hmm, what about `fx.fillStyle = 'rgba(0,0,0,0.056)'` with destination-out: destination-out multiplies dest alpha by (1 - source alpha). That should fade.

Unless... **the canvas has an opaque backdrop?** No, destination-out works on alpha regardless.

Wait. What about the DPR transform and fillRect(0,0,W,H) — that covers the whole canvas. Yes.

Hmm, but what if the *drawing* is happening to a different surface than what's displayed? Like the screenshots show a composited result... 

Let me reconsider: maybe the fade IS working, but each frame the particles redraw at nearly the same positions (they fall slowly?) so trails persist? No — particles die (parts=0) yet the image persists identically.

So the canvas is frozen. Which means... the fx canvas is not being repainted at all after some point? But then how did the burst get drawn?

AH WAIT. I think I understand! The screenshots might be showing the *page* but the canvas content is fine — maybe the browser tool's screenshot is taken from a stale paint? Unlikely for 3 different frames.

Let me think about "identical frames" differently: maybe the page's rAF is throttled/paused (e.g., the tab is not visible → rAF stops). But then the DBG logs wouldn't appear... they appear at ~400ms intervals, and dt clamped to 1/20. Notice: parts went 494 → 383 → 256 → 261 → 208 → 98 → 0 over ~2.8s of logs. That's consistent with real time.

Hmm, but if rAF ran, the fade would run too.

Unless... the fade alpha per frame is computed with `dt` which is clamped to 1/20 = 0.05 → fadeA = 1-exp(-0.05*3.4)=0.157. But the log says fadeA=0.056, which corresponds to rate 3.4 and dt=0.0167 (60fps). So dt is normal, ~60fps. So the fade runs at 0.056 per frame → after 1.7s (100 frames) → 0.944^100 ≈ 0.003. So residue should be gone.

Therefore the displayed image must NOT be reflecting the fx canvas... OR the residue we see is being *re-drawn every frame* by something. What could re-draw the circle and streaks? `paintSky()` — the sky canvas! Is the circle part of the sky canvas? The streaks fan out from the burst point... they wouldn't be in paintSky.

Hmm, but wait: what if the *sky* canvas is what's frozen and the fx canvas is being properly faded/cleared? The initial screenshot (before any burst) shows a clean sky. The circle appeared after the burst. paintSky draws the milky band gradients and moon glow — no big circle at (600,250).

So the circle must be on fx. And it persists → fx isn't fading.

Unless the fade fillRect is a no-op because `fx.fillStyle` string with 'rgba(0,0,0,0.056)' — valid.

Hmm, hold on! What about `fx.globalCompositeOperation` being reset? I set 'destination-out', fillRect, then 'lighter'. But what if the *canvas context state* has `filter`? No.

Let me reconsider the possibility that the screenshot tool captures only the FIRST canvas or composites oddly... The HUD "particles 134" in frame 1 vs 0 in later frames shows the DOM updates, so screenshots are live.

OK here's another idea: **the fx canvas is being resized every frame?** No.

What if `fx.setTransform(DPR,0,0,DPR,0,0)` combined with... no.

Wait wait. Critical: `fx.globalCompositeOperation = 'lighter'` — with 'lighter', drawing black rgba(0,0,0,0.056)... no, the fade uses destination-out, set BEFORE.

Hmm, let me look at my code order again:

```js
fx.globalCompositeOperation = 'destination-out';
const rate = trailOn ? (0.6 + (1-trailLen)*7.5) : 22;
fx.fillStyle = 'rgba(0,0,0,'+(1-Math.exp(-dt*rate)).toFixed(4)+')';
fx.fillRect(0,0,W,H);
fx.globalCompositeOperation = 'lighter';
```

That looks right. Unless `trailLen` is 0.62 → rate 3.4. Yes.

So... why frozen? Let me test by disabling trails (the "Trails" checkbox) → clearAll(true) → then the fade rate becomes 22/s (fast). If the visuals still persist, the fade is broken.

Actually! I wonder whether the issue is that the browser tool's screenshots are of a *paused* rendering — e.g., the harness throttles rAF during capture but the canvas keeps accumulating? No, that would produce identical frames with accumulated content — which is exactly what we see! The screenshots at 565ms intervals show identical content, and the content includes trails from the whole burst.

Hmm, alternatively: **the page is in a background tab and rAF is throttled to near-zero, but the logs continue?** The logs come from within frame() — they're at 400ms intervals consistently, so frame() runs at ~60fps.

So frame() runs, fade runs, particles draw... but the visible result doesn't change. Contradiction unless the drawn content is identical each frame. Which would be the case if... the particles are drawn at the same positions each frame? No, they fall.

Unless the visible thing IS being redrawn each frame identically: the circle = flash? flashes=0 in later logs. So no.

Hmm, so what in the scene is drawn every frame and would look like a big soft circle plus downward fanning streaks? 

OH!!! I bet it's the **trail particles from the shell's ascent + the wisp particles**... no.

Let me reconsider the streaks: they fan downward from around the burst center, and they're *dotted/dashed* (like a series of small dots). That looks like a *rendered particle trail with gaps* — i.e., the residue of particles that fell. The dotted pattern = per-frame positions. So this is residue, not live drawing.

And the big circle = residue of the flash. So the fx canvas is accumulating and NOT fading.

So the fade must be failing. Why? ... 

**Because `fx.globalAlpha` is not 1 at the time of the fade?** I log op=1 at the END of the frame, after the flashes loop sets `fx.globalAlpha = 1`. Hmm, at the start of the next frame, globalAlpha = 1. OK.

**Because destination-out with a source that has alpha 0.056 removes 5.6% of dest alpha per frame.** Yes that's the intent.

Unless the canvas is *not premultiplied/has no alpha channel*! If the fx canvas context was created with `alpha: false`, then destination-out can't reduce alpha (the buffer is opaque) — pixels would only darken toward black... but we'd see black rects covering the sky. Hmm, we didn't pass alpha:false. Default is alpha:true.

Wait, actually: with alpha:true and destination-out, the residue fades. That's standard.

Hmm, let me look at the actual rendered image again: the circle is *bluish-white haze* over the sky, and the sky (stars, moon, buildings) is visible *through* it. If the fx canvas were opaque black, we'd see black. So fx is transparent-ish with faint additive content. And that content isn't fading.

New hypothesis: **the fade IS working, and the content we see is being re-added every frame by the flashes... no, flashes=0.**

Alternatively the content we see is on the SKY canvas: is paintSky() being called every frame? No, only on resize. But wait — `resize` is being called repeatedly? If something triggers resize each frame, paintSky runs, and `c.width = ...` resets the fx canvas (clearing it). That would clear trails, not persist them. And the log would show repeated "resized" messages — only one.

Hmm, what if the screenshots are just... stale because the harness screenshots a *different* frame? Let me test directly: click Clear (which does fx.clearRect) and screenshot. If the image doesn't change, the screenshots are stale or the fx canvas isn't displayed. That's a decisive test.

Let me click somewhere first (to create visible content), then screenshot, then Clear, then screenshot.

Actually better: click at (300, 200) → wait → screenshot. Then click Clear → screenshot.

Let me do: click at (900, 250), then screenshot.

Now I can see: the click launched a shell (visible bright head with dotted ascent trail at x≈935 near ground). So rendering works. The old residue from the previous burst has faded (mostly). The huge circle is gone now. 

So the earlier "frozen" appearance was actually... hmm, interesting: the earlier frames 2-4 were identical. But now the residue from the demo burst faded away. Wait, in this click screenshot, faint streaks remain near the bottom. So the fade works, but very slowly? The rate 3.4/s means 0.056 per frame at 60fps → after 2s, 0.056*120 = ... (1-0.056)^120 = e^{-120*0.0576} = e^{-6.9} = 0.001. Fast.

But the earlier motion frames showed the residue persisting for 1.7s. Hmm, unless the screenshots during `motion` are taken while the page's rAF is throttled/paused (the harness may block the main thread between captures, or the page renders only when... ). Actually during motion capture, the tool might capture via CDP screenshots which are fast. But maybe rAF is throttled because the page isn't focused/visible during capture? The DBG logs in the last output show ~100 logs at 400ms intervals over ~40s of real time... consistent.

Actually wait, look at the DBG logs: they're all `parts=0` and the fadeA is 0.056 — the loop runs. The identical motion frames might be because the *browser tab is not visible* and the compositor... no.

Hmm, one clue: during the motion capture, the residue persisted. Right after (this click), the residue is gone. Between those, ~100 frames of fade ran. So during motion capture, the fade did NOT run (or ran very little) — meaning rAF was throttled during the motion capture, but the DBG logs continued... Actually the DBG logs during motion showed a steady progression of parts counts (494→383→256→...→0), so frame() ran. And fade ran. So the canvas should have faded.

Unless the screenshots during motion are cached/stale frames of the *compositor* while the canvas is offscreen... Possibly the tool captures the page in a headless way where the canvas layer is stale.

Hmm, whatever the cause, the important thing: the last screenshot shows the shell head and dotted ascent trail rendering correctly, and the previous residue faded. But the *visual brightness* of the burst was poor — in the motion frames, the burst particles were barely visible; we mostly saw the flash circle and faint streaks. That suggests particles are too dim. Let me examine: the flash circle dominated (a huge soft blue-white disc). That's ugly. And particles' heads: with 'lighter' and sprite alpha ~0.5, size s=4.5-8.5 (drawn as s*2 = 9-17px), alpha decaying as k^1.8. They should be visible... In the motion frame 1, particles=134 and I saw no bright dots, only the circle. That's suspicious.

Wait, maybe the issue is the sprite: `spr(p.hue)` — SPR[0] is hue 0 (red) with white center. drawImage with 'lighter' → adds light. Should be bright.

Unless... `fx.globalAlpha = clamp(a,0,1)` where a = k^1.8 and k = 1 - t/life. For a particle at t=0.5*life, a = 0.29. Hmm, that's dim. With fade exponent 1.8, alpha drops fast. Plus the sprite's own alpha profile. So mid-life particles are at ~30% alpha of a sprite whose center is bright. Should still be visible against dark sky.

But the screenshot during motion showed the HUD "particles 134" and no dots. And in the click screenshot, the ascent trail dots ARE visible (bright cyan/white dots). So particles render.

Hmm — during motion, the burst particles were hue 200 (azure) with the chrys pattern... they'd be blue-ish, dimmer. And the huge flash washes out the region.

I think the real problem is: (1) the flash is way too large/dominant and long-lasting (it's drawn on the trail layer so it smears into that big circle), and (2) particles are too dim/small. Let me improve:

- Reduce flash radius drastically (e.g., 60-110 px) and draw it with a fast decay (a -= dt*14) and lower alpha. Also draw flashes on a *separate* non-trail pass so they don't smear? The trail layer smears them into a big disc. Better: draw the flash directly each frame with small radius; since it decays in ~70ms, the smear will be minor. But the fade residue of a bright flash still lingers as a disc. Use smaller radius + lower alpha.

Alternative approach: render flashes and particles on the fx canvas, but draw the flash with 'lighter' at low alpha and small size (r ~ 90) — fine.

- Make particles brighter: increase alpha (use fade exponent ~1.2 and add a minimum), increase core brightness, and increase size slightly. Also, the shell head trail looked good.

Also: the ascent trail looked "dotted" — because the shell emits ember particles at intervals; that's actually charming (like a comet). But dotted trails come from the trail-fade residue of discrete draws. Fine.

Let me also reconsider the trail fade: with trails ON, the residue is what makes the "streaks". The streaks from the previous burst persisted long enough to appear in 4 consecutive motion frames — with rate 3.4/s they should fade in ~1s. The slider at 62 gives rate 3.4. Hmm, they persisted ≥1.7s. Maybe because the motion capture stalls rAF (each screenshot blocks). Whatever.

To be safe, make the max trail rate higher: rate = 1.2 + (1-trailLen)*9 → at 0.62: 4.6/s. Slightly faster fade.

Now, another important issue: the demo burst particles were nearly invisible in the screenshots, which is a verification problem ("particles visibly spread and fade"). Let me boost brightness significantly:
- alpha = pow(k, 1.2) * 1.0, and draw with two layers (glow sprite + white core) always (core alpha = a).
- Increase base size: sparks 5-10.
- Increase count slightly? 90-150 is fine.

Also, the flash circle: reduce to r = 70-120 and alpha 0.35 with fast decay.

Let me also add a slight "smoke" residue? No.

Another thought on the huge circle: `flash(x,y,Math.min(420, n*2.2),'rgba(255,250,235,.5)')` → radius 255 at alpha 0.5*0.5=0.25 globalAlpha with 'lighter' — that's a LOT of added light over a big area, and the trail layer keeps it for ~1s. Definitely the culprit for the washed-out disc. Fix: radius ~ min(140, 40+n*0.5) ≈ 96, alpha lower.

Let me restructure the flash to be short and punchy:
```js
function flash(x,y,r,color,a){ flashes.push({x,y,r,c:color,a:a||1}); }
// decay: q.a -= dt*10
// draw: globalAlpha = q.a*q.a*0.35
```

Also the shell's per-frame `flash(this.x,this.y,12*size,...)` creates a moving dot that smears — that's fine (it's the comet trail) but 12px at 0.5 alpha each frame adds up. Keep small.

Also: I should make the burst particles' initial speed look right — the spread in the screenshot: the streaks fanned downward over ~500px, good.

Let me now also reconsider: should particles be drawn on the trail layer (fx) — yes.

Another improvement: draw a "hard" bright dot for particles using fillRect/arc for crispness plus the glow sprite. Let me add: 
```js
fx.globalAlpha = a;
fx.drawImage(glow, ...);
// crisp core
fx.globalAlpha = Math.min(1, a*1.3);
fx.fillStyle = 'hsl(hue,100%,85%)';
fx.beginPath(); fx.arc(p.x,p.y, Math.max(0.6, p.size*0.18), 0, 7); fx.fill();
```
That's an extra fill per particle — 500 particles fine.

Actually simpler: use SPR[0] white core as I do; but SPR[0] is hue 0 (red-tinted). I should build a dedicated white/gold sprite. Let me add SPRW (white core sprite).

Let me rewrite the rendering bits and remove the debug logging. Then verify with click + motion.

Plan of edits:
1. Sprites: add `const SPRW = makeWhite()` — a white-hot core sprite.
2. flash(): smaller default radius, faster decay.
3. burst(): flash radii ~ 90 and 60, alpha lower.
4. Shell.step: flash radius 8.
5. Particle draw: brighter alpha curve (fade exponent default lower), add crisp core with SPRW.
6. trail rate formula tweak.
7. Remove debug logging + try/catch (keep try/catch? Remove for cleanliness; keep window error handler? Remove).

Let me write these edits.

For the alpha curve: `let a = Math.pow(k, p.fade)` with fade ~1.8 → I'll change to `a = Math.pow(k, p.fade*0.75)` and multiply by an intensity factor: `a = clamp(a*1.25,0,1)`.

Let me implement.

Also remove the leftover `let dbgT = 0;` line (harmless but unused) — let me remove it. And `const r = 18;` for the shell head is fine.

Also, one thing: with 'lighter' composite and the flash drawn each frame, fine.

Let me remove dbgT and check syntax.

python3 not found, so the replace didn't happen; but grep -c "DBG" index.html returned 0 → wait, grep found 0 matches so exit code 1 for grep. Hmm, but "dbgT" is lowercase, so "DBG" (uppercase) count 0 — the window error listener line was removed? No, that had "[fw][DBG]" strings which I removed in the edit. Let me check dbgT still exists.

Now let me re-run and verify. The demo shell launches 450ms after load. I'll reload then click at a specific location and capture motion to see ascent/burst/fall.

Note: motion frames are ~600ms apart, and the shell flight is ~1.05s. To sample the ascent I should click and immediately do motion. Let's do: reload → click at (850, 180) → motion.

Actually, the click and motion are separate tool calls with overhead; the flight is ~1s so I might catch the burst. Let me increase the flight time a bit? A ~1s ascent is realistic and visible. Fine.

Let's proceed.

Now wait for the demo shell. Let me capture motion to sample the demo burst (it should be around now-ish). Then do a click test.

Actually let me do the click test first with motion, since the demo already may have exploded. I'll click at (850,170) then motion.

The click launched shell #2 targeting (850,170) — visible as the small bright dot at bottom right (~730,727) ascending. The demo burst residue (dome of streaks) is visible from burst #1 — that's the falling willow-like trails.

But I notice: the burst from the demo (126 particles) shows only as faint streaks now (they've faded, ~2s later). The dome-shaped streak pattern looks nice actually.

Hmm, but the concern: particles look dim. The streaks are visible but the particle heads aren't bright at this late stage (they've faded). Let me capture motion right after a burst to see the peak brightness.

Let me now run motion to catch shell #2's burst (it launches at apex 1.13s after click; the click happened ~1s ago maybe).

Very suspicious: 4 motion frames are essentially identical (frozen), showing only trail residue, no live particles — even though burst #2 happened during this window and particle counts were 260.

This strongly suggests that during the `motion` capture the page's rAF loop is NOT running (frozen canvas), while the screenshots show the last painted state. But the console logs burst #2 during motion... and the residue shown is from burst #1 (dome over center-left) plus burst #2's? Actually the dome is centered around x≈850 in these frames (the fan radiates from ~(850,180)). Hmm, and the earlier click screenshot showed a dome from burst #1 at x≈600. In these frames, the fan appears centered around 850 — that's burst #2's residue. So the canvas HAS been updated after burst #2, and then froze.

So the frames are frozen at the moment of burst #2 (or slightly after), and all 4 frames show the same image. Conclusion: the motion capture takes screenshots while the page is throttled/paused — likely the tool captures frames but the page only renders when the tool "yields". Actually more likely: the browser tool's motion capture blocks the main thread (e.g., via CDP screenshots that stall rAF), so the canvas is stuck at the state when the capture began... but the state includes burst 2 which happened during the capture.

Alternatively — and I think this is the key — the harness may run the page with rAF throttled when the tab is not "visible"/focused, and only paints on certain events. But the earlier per-frame DBG logs showed frame() running at 60fps even during motion... Those logs were from the motion run: parts counts progressed 494→383→256→...→0 across the capture, so the simulation ran. And with the fade running, the residue should have disappeared. Yet the frames show the residue static.

Unless... the *screenshots* are of a stale compositor surface. I bet the harness screenshots via `page.screenshot()` in a headless browser where the canvas is composited but the frame updates stall... Hmm, but the DOM HUD updates in screenshots? In the click screenshot, the HUD showed "shells 1 particles 22" — live. In the motion frames, HUD shows 0/0 — which is the end state. So the DOM in the screenshots is live/current, but the canvas looks stale/frozen.

Wait — maybe the canvas is NOT stale. Maybe what I see is genuinely the current state: all particles dead (0), and the residue is what remains. But residue should fade with the trail rate... unless the fade isn't working and residue is permanent until Clear!

That's consistent with everything: the fade (destination-out) might not be removing pixels as expected. Hmm, but why?

AH. I think I've got it: `fx.fillRect(0,0,W,H)` with `globalCompositeOperation='destination-out'` — this DOES fade. BUT, `createRadialGradient`... no.

Let me test the fade hypothesis directly: turn trails OFF (checkbox) — that calls clearAll(true) and sets rate=24 → residue gone in ~40ms. If after that, screenshots show a clean canvas with a live burst (bright dots, no long streaks), then the fade works but is slow at rate 4.

Hmm, but the residue in these frames is from ~1.7s ago at rate = 1.1+0.38*8.2 = 4.2/s → e^{-4.2*1.7} = 0.08 → 8% remaining. Faint! And indeed the residue IS faint (a subtle dome). So maybe the fade IS working correctly and what I see is 8% residue.

So then the frames are consistent: particles all dead (parts=0 at the end of the capture, and by frame 1 of motion, ~1.7s after burst #2? no...).

Hmm, wait. Timeline: click → shell #2 launched, apex at 1.13s. Then motion capture started (tool overhead maybe 1-2s later), so burst #2 happened right at the start of the motion capture (log appears in the motion output). The 4 frames span 1.75s. At frame 1 (t≈0 after burst), particles=260 alive and bright — but frame 1 shows NO bright particles, only faint residue. That contradicts.

Unless the screenshots are captured at the END of the motion sequence (all showing the final state). That would explain identical frames! The tool says "Frame 1, +0ms / Frame 2, +590ms..." but the images may all be from the same final paint... Actually all 4 images ARE nearly pixel-identical, which suggests the tool captured the same surface 4 times (stale).

So the motion tool likely can't capture true animation frames in this environment (canvas is double-buffered/composited oddly). The DOM HUD text differs between calls though.

Given that, I should verify the live rendering differently: use single `screenshot` calls immediately after a click (each tool call = fresh paint). The click screenshot earlier DID show the ascending shell head clearly. So single screenshots work.

So the plan: click, then immediately screenshot (to catch ascent), then screenshot again (burst/fall). The overhead between calls is ~1s, so I can catch different phases.

Let me do that: click at (400, 200), then screenshot.

But there's a catch: if the page only paints when the tool interacts... The click screenshot showed a live shell, so painting happens.

Also note the burst at 1.13s after click. Let me click and then take 2-3 screenshots in sequence.

Actually, better: I can slow things down to make verification easier? No, keep the physics natural.

Let me click and screenshot repeatedly.

Shell #3 ascending from x≈389 with a bright head and dotted trail. Previous residue has faded (confirming the fade works). 

Now screenshot again to catch the burst (~1.15s flight; the click was ~1s ago).

The HUD says "shells 0 particles 0" even though burst #3 just happened (139 particles). And the screenshot shows only faint residue — no live particles.

This is the smoking gun: the screenshot is taken at a moment when the simulation has already ended, OR... hmm, the burst log says total 139 particles and the HUD says 0 particles. The HUD updates every frame. So at the time of the DOM read, particles were 0 — meaning ~3+ seconds after the burst (willow lives 2.4-3.6s). So the tool call overhead is several seconds. That explains everything: the screenshots are taken seconds after the burst, when only residue remains.

So the app is fine; my verification timing is the issue. The tool call latency is ~2-4s.

Strategy: use the "Salvo" button (3 shells staggered) or click and then take screenshots repeatedly — eventually one lands during the burst window. Alternatively, temporarily slow down time? I could add a URL param or... Actually I can make the burst window easier to catch by launching several shells at once via Salvo (3 shells over 0.7s + long bursts). Or use auto show to keep things going and take a screenshot — a random moment will catch live particles.

Simplest: enable Auto show (click the checkbox), then take a screenshot — there will almost certainly be live shells/particles. That also verifies overlapping shells/bursts.

Let me click the AUTO SHOW checkbox at approximately (40,105) then screenshot.

Also note: the residue dome from the willow burst looks nice.

Let me do it.

Auto show is on (checkbox checked). The hint should have disappeared? No, the hint only hides on sky click. Note: clicking the panel doesn't hide the hint — correct.

Now take a screenshot to catch live shells.

Now we see live fireworks: a purple/magenta palm burst with drooping falling trails, a green ascending shell with dotted trail, and residue from other bursts. Overlapping shells/bursts confirmed. Particles fall under gravity (the drooping arcs), spread radially, and fade.

Observations for polish:
1. The particles' heads look somewhat dim/soft; the trails are strong. Actually it looks quite good — like long-exposure photography. Nice.
2. The residue from previous bursts accumulates into a big hazy dome (the long trails). With trail slider at 62 it's a bit heavy but looks atmospheric. Maybe reduce default trail to 50 to cut the haze.
3. The burst center is a bit dim — the flash is now subtle. Could be slightly brighter at the core.

Also the particles look "dotted" (dashed trails) rather than continuous — that's because the fade rate is slower than the particle draw spacing... Actually the dotted look comes from the destination-out fade interacting with additive drawing at 60fps: each frame adds a dot; the dots are ~4px apart at 250px/s → 4px per frame, and the sprite is ~8-16px so should overlap. The dotted appearance is likely a JPEG-ish artifact of the screenshot. Fine.

Let me take one more screenshot to see a fresh frame (different phase), then test Clear, then resize behavior.

Actually, let me lower the default trail to 50 and slightly boost the flash for a punchier burst core. Small tweak.

Also, I should verify the click affects the launch target: the log shows "launch shell #3 from (389,764) → target (420,150)" for a click at (420,150) — exact match. And burst #3 at (420,162) — burst at the target. 

Now: Clear test. Click Clear, then screenshot + inspect HUD (should be shells 0, particles 0) and canvas empty. But auto show is on, so it will relaunch within ~1s. Let me turn auto show off first, then Clear.

Let me do the small visual tweak first, then reload and run the final verification sequence:
1. Reload → screenshot (demo shell visible).
2. Click sky at a known point → check console log target matches.
3. Screenshot during burst (may need a couple of tries).
4. Turn auto show on → screenshot to see overlapping bursts (already verified).
5. Turn off, Clear → screenshot empty + HUD 0/0.
6. Resize check: the browser tool has scroll but no resize... I can't resize the viewport with the available actions. Hmm. "Keep controls usable after resizing" — I can verify by CSS/design reasoning: the panel is fixed-position DOM, the canvases resize with the resize handler and repaint. I can't easily test a viewport resize since the viewport is fixed at 1200x800. I could note it as unverified. Actually — maybe I can trigger a resize by... no. I'll note it.

Let me make the tweaks: trail default 50, and boost burst flash slightly.

Also one more consideration: `parts.splice(0, parts.length-MAX_PARTS)` when exceeding 5200 — fine.

Let me finalize the file with small tweaks and remove the console.log noise? The logs are useful for verification and are reasonable for a demo (they document launch/burst/clear). I'll keep them but make them concise. Keep.

One more: the hint text stays visible during auto show; it hides after first sky click. Fine.

Tweaks:
- `<input type="range" id="len" ... value="62">` → 50, and `#lenv` → 50, and trailLen = 0.50 default. I'll set trailLen from the DOM value at init to keep them in sync. Let me just change the initial value in JS: `trailLen = 0.5` and HTML value 50.

Let me apply.

Also, the flash decay `q.a -= dt*11` with globalAlpha = a*a*0.30 — with a slightly bigger flash it's still short (90ms). Good.

Now reload and verify:
1. Initial screenshot (demo shell ascending).
2. Click at a specific point → log check.
3. Screenshot to catch burst.
4. Clear → verify empty.

Let me reload and immediately screenshot to catch the demo ascent (demo launches at 450ms; the screenshot happens after tool overhead ~1s → shell at apex/just burst). Let's see.

Clean initial state, auto show off, trail 50. Now click the sky at (700, 220) to test click targeting, then screenshot quickly to catch the burst.

Click at (700,220) → "launch shell #2 from (780,764) → target (700,220)" — exact target match. The shell is visible ascending at bottom (x≈780, near ground) with the launch flash. The demo burst residue dome is visible.

Now screenshot to catch the burst of shell #2 (palm at ~700,220).

Burst #2 at (699,230) — matches the click target (700,220) within the apex tolerance. By the time of the screenshot, particles had all expired (HUD 0). The residue shows the fan of falling trails from the burst — good evidence of radial spread + gravity fall + fade.

I already captured a live burst earlier (the purple palm). Let me do one more attempt to catch a live burst right at the moment: use the Salvo button which launches 3 shells staggered 230ms apart, giving a longer window; then screenshot. Actually the window is ~1.3s of bursts + 2s of particle life = decent.

Let me click Salvo then immediately screenshot.

Salvo launched shell #3 (from 147,764 → 231,169); visible ascending at bottom-left. The other two salvo shells are launched via setTimeout (230ms, 460ms) — they'll come.

Now screenshot to catch the overlapping bursts.

Three overlapping bursts logged (bursts #3, #4, #5 at different x positions), particles 58 remaining. The screenshot shows the falling-trail fans from all three bursts (left, center, right) — clear evidence of radial spread + gravity + fade. Live particle heads are dim in this shot because we're at the tail end again.

I already have one great screenshot with bright live particles (the purple palm). Good enough.

Now test Clear: click CLEAR button, then screenshot + inspect HUD.

Clear worked: the scene is empty (all residue gone), HUD shows shells 0 / particles 0.

Note the log said "removed 0 shells, 0 particles, 0 flashes" — because by the time I clicked, everything had already expired naturally. I should verify Clear actually removes live particles. Let me click Salvo, then immediately click Clear (while shells are ascending), and check the log reports nonzero removals.

Tool overhead is ~2-4s per call; shell flight ~1.1s, particles live 1.5-3.5s. So after Salvo, particles will be alive for a couple of seconds. Let me click Salvo then Clear right away.

Shell #6 ascending (visible cyan head at bottom-left, x≈200,y≈742), HUD: shells 1, particles 20. Now immediately click CLEAR to verify it removes live shells/particles.

Clear worked again — scene emptied, HUD 0/0. But the log says "removed 0 shells, 0 particles, 0 flashes" even though 3 bursts had just happened (491 particles). That's because by the time my click landed, particles had expired... Hmm, burst #8 at 491 particles; the clear log says 0 removed. The tool overhead is ~4s, and peony/chrys particles live 1.1-2.5s, so plausible they all expired.

But wait — there's a real possibility of a bug: `clearAll()` reads `shells.length` and `parts.length` BEFORE clearing... yes:
```js
const ns = shells.length, np = parts.length, nf = flashes.length;
shells.length = 0; ...
```
That's correct order.

Hmm, but the HUD at the previous screenshot showed "shells 1 particles 28" and after the salvo, 3 bursts with 491 particles. The clear happened after all expired. It's plausible given ~4-5s of latency between the two clicks (each tool call takes seconds).

To be certain Clear removes live content, let me do a decisive test: click Salvo, then click CLEAR as fast as possible (two calls back-to-back). The salvo's first shell bursts at ~1.15s and particles live ~2s. Between two tool calls there's maybe 2-4s... risky.

Alternative decisive test: use the keyboard 'C' key? Same latency issue.

Better: verify logically + with a targeted test where particles are long-lived: willow particles live 2.4-3.6s. Or simply: click Salvo and then immediately CLEAR — if the log shows nonzero, great; if 0 again, I'll accept the HUD evidence (the previous screenshot showed a fully empty scene right after a period when residue existed → clearRect works).

Actually here's a cleaner check I already have evidence for: the screenshot before the Clear click showed the scene with residue from 3 bursts (in the earlier test, the frame with fans). After Clear, the residue vanished instantly (compare: the "cleared" screenshot is pristine vs. the previous one with visible fans). That proves clearRect on the trail layer works. And the counts: the log's "removed 0" only reflects natural expiry.

Let me do one fast back-to-back test anyway to try to catch live particles: click sky (launch), then immediately click Clear.

Shell #9 ascending from (536,764) toward (600,160) — visible bright head with ember trail. HUD: shells 1, particles 30. Now Clear immediately.

Scene is empty after Clear (HUD 0/0, canvas pristine). But the log again says "removed 0 shells, 0 particles, 0 flashes" even though burst #9 (+99 particles) happened just before. That's suspicious — the tool latency is ~4-5s per call, and peony particles live 1.2-2.0s, so they could have expired. But it says 0 shells too — and shells only exist for 1.15s.

Hmm, but there's a possible bug: `clearAll` is defined inside the IIFE and references `shells`/`parts` — the counts captured before clearing. Let me re-read:

```js
function clearAll(silent){
  const ns = shells.length, np = parts.length, nf = flashes.length;
  shells.length = 0; parts.length = 0; flashes.length = 0;
```
Correct.

So the 0s mean everything had already expired by the time the click landed. The burst #9 log line appears immediately before the cleared line in the console, but console ordering only tells us burst #9 preceded the clear — the gap could be 3+ seconds.

To be really sure Clear nukes live content, I can use the keyboard shortcut 'C' right after a screenshot shows live particles... same latency.

Alternative: make the test deterministic by lengthening particle life? No.

Actually there's a neat trick: the HUD in the screenshot taken right after the "launch" click showed "shells 1 particles 30" — live. If the very next click (Clear) reports 0 removed, then between those two calls everything died: the shell would have burst (log confirms burst #9 happened) and the peony particles (1.2-2.0s) expired. The gap between two tool calls is evidently ~4s. Consistent, no bug.

I'm reasonably confident. But let me do one extra safety check on the code path: `clearAll` sets `fx.globalCompositeOperation='source-over'` then clearRect then back to 'lighter'. Fine.

One more thing worth verifying: resize behavior. I can't resize the viewport with the given actions. However, I can check the panel's responsiveness via the CSS (fixed, max-width) — and the resize handler repaints the backdrop. I'll note it as unverified via tooling but implemented.

Actually — wait. I could test resize indirectly: the `scroll` action won't resize. There's no viewport resize action. Skip.

Let me do a final review of the file for leftovers and make sure the demo/first-load behavior is right, plus check for any remaining issues:
1. `const r = 18;` for shell head — fine.
2. `hud()` called every frame now (cheap DOM writes at 60fps — acceptable, but let me keep the throttled version? I call hud() in the fps block AND every frame. Every-frame DOM text updates are fine for 3 nodes.)
3. The `p.brk` child-burst: for 'double' pattern — verified? Burst #7 was 'ring', #6 'peony'... double appeared as shell #6 earlier? In an earlier run, pattern=double appeared (shell #6 in the auto-show run) and the total particle counts grew. Fine.
4. Check the unused variable `f` — used in flick. `k` used. OK.
5. `const pal = pick(PALETTE);` inside emitter is computed per call even when hue2 given — harmless.
6. `MAX_PARTS` splice — fine.

One last look at the whole file to be sure nothing is broken, then final report. Let me view a few key regions.

The file is complete and verified. One essential thing: the trails checkbox unchecking calls clearAll(true) which wipes everything — that's a bit aggressive but acceptable (it clears trails). Fine.

Let me do a final syntax check and confirm the file exists, then report.

grep -c "http" returned 0 matches (exit 1) → no external URLs. File is self-contained.

Final quick browser check that the page still loads cleanly after the last edits (the current loaded version is the same as the file — I edited before the reload, and all tests were on that version). Yes, the last reload happened after the trail/flash tweaks, so the tested build == the saved file.

Done. Report.