Fireworks · mimo-v2.6-flash

Let me build the file. I'll write index.html with canvas, controls (Clear button), auto demo shell on load.

Let me write it.

Let me build a single-file fireworks display. I'll write index.html with canvas, click-to-launch, auto demo shell, Clear button.

Design: full-screen canvas, shells launched from bottom toward clicked location, ascending with trail, explode into radial burst particles with gravity and fade, plus lingering trails (maybe draw with fading composite 'lighter' and semi-transparent fill for motion trails).

Controls: Clear button (and maybe a Launch button). Controls must remain usable after resizing — position fixed, responsive.

Verification: I can use a browser tool? I have only read/bash/edit/write tools. The addendum says "Run the application in the browser and inspect the initial output and console" — but I don't have browser tools here. Available tools: read, bash, edit, write. So I can verify via headless means — maybe node isn't available? Let me check. I can at least do a syntax check with node if available, and simulate the physics logic.

Let me write the file carefully.

Plan:
- Canvas full screen, DPR scaling, resize handler.
- Scene objects: shells (x, y, vx, vy or target-based), particles.
- Shell: launched from bottom (random x near target x maybe, or bottom of screen), travels toward target with velocity, when reaches target (or vy crosses) explodes.
- Trail: shells emit small spark particles; also store trail points drawn as fading line.
- Burst: N particles radial with random speed, color from palette, gravity, drag, life; twinkle near end; drawn with 'lighter' composite.
- Background fade: instead of clearing fully, fill with rgba dark to leave motion trails. But Clear must empty scene — also clear the canvas fully.
- Auto demo shell on load (and maybe on resize keep controls).
- Clear button: remove all shells/particles, clear canvas.

Physics determinism for verification: I'll add a small hook maybe — not needed. But for verification I could add a debug function window.__fw with state accessors to check ascent/burst/particle fall, and window.__fw.clear(). That helps scripted verification if a browser existed. Since no browser tool, I'll verify with node by extracting the script and running the simulation headlessly (stub canvas). That's doable: write the JS so core simulation is testable.

Approach for testability: separate pure simulation functions from rendering. In node, I can load index.html, extract script, stub minimal DOM (document.getElementById returning fake canvas with getContext returning proxy that records ops), requestAnimationFrame, then drive frames and inspect state.

Let me write code where state is accessible: `const state = {shells:[], particles:[]}` and expose `window.__fireworks = {state, launch, clear, step}` — but core loop uses rAF with time delta; for headless I can expose `tick(dt)` used by the loop.

Let me structure:

```js
const canvas = ..., ctx = canvas.getContext('2d');
let W, H, DPR;
const state = { shells: [], particles: [], t: 0 };
function resize(){...}
function launch(targetX, targetY){...}
function explode(x,y,color,count){...}
function step(dt){ update shells, particles }
function render(){ fade bg; draw }
function frame(now){ dt; step(dt); render(); raf }
clear(){ state... ; ctx.clearRect }
```

Shell launch: origin at bottom: originX = targetX + random offset (or clamp), originY = H + 10. Compute velocity so shell reaches target: use time-of-flight T, vx=(tx-ox)/T, vy=(ty-oy)/T, plus gravity compensation: vy = (ty-oy)/T - 0.5*g*T? With drag it's complicated. Simpler: shell moves with constant speed along direction to target, and explode when distance small or when vy >= 0 after apex near target. Use gravity on shell too but choose initial velocity solving projectile: with gravity g and flight time T: vx=(tx-ox)/T, vy=(ty-oy)/T - 0.5*g*T. Choose T ~ 1.1s. That guarantees exact arrival at target time T. Nice — deterministic arrival. Explosion at t=T exactly at target. 

But dragging/damping: skip drag for shells, use pure gravity — exact.

Shell rendering: glowing dot + trail particles emitted each frame (small sparks with short life) — those are particles too (kind 'spark').

Also draw shell trail as stored points polyline for a smooth streak.

Burst particles: for a shell, at explode create particles: count ~ 70-110, speed = base * (0.2..1 random) with some ring structure; color palette. Optionally inner/outer shells. Each particle: x,y,vx,vy,life,maxLife,color,size,drag, flicker.

Update particle: vy += g*dt; vx*=drag; vy*=drag; x+=vx*dt; y+=vy*dt; life-=dt; alpha = (life/maxLife) with flicker near end: alpha *= (life<... random twinkle). Remove when life<=0. Also remove if y > H+50 (fall below screen) — but "removed after their lifetime" primary.

Render: composite 'lighter', draw glow via radial gradient? Gradient per particle is costly. Use small circle with alpha plus bigger faint circle. Or draw with shadowBlur (slow). Use two circles: core white-ish and colored halo. Fine.

Background trails: fill rgba(6,8,16,0.18) each frame → motion trails. Clear button: fill solid bg + clear arrays.

Controls: top bar with title, Clear button, maybe "Launch" button. Ensure pointer events on canvas only (controls above canvas with z-index, and canvas click handler on canvas element itself so button clicks don't launch — use canvas.addEventListener('pointerdown')). Also keyboard? Not required.

Also show hint text that fades.

Multiple overlapping shells: allow.

Now verification in headless node: extract script between <script> tags, run in a vm with stubs. Let me write the code so it works with stubs: document.getElementById('sky') returns stub canvas with getContext returning stub ctx (all methods no-ops, measure properties). window addEventListener, requestAnimationFrame stub that we control manually. performance.now stub.

Actually simpler: write a node test harness file (temp, not in final dir? It's fine to create then delete). I'll create test.js in /tmp maybe to keep cwd clean? The requirement: end with index.html present. Extra files probably okay but better keep clean — put harness in /tmp.

Let me write index.html now.

Details for visuals:
- Palette: ['#ff4d6d','#ffd166','#4cc9f0','#7cf57c','#c77dff','#ff9f1c','#fffd82','#f72585'].
- Sky gradient background drawn once on resize (dark navy → black) — but per-frame fade fill would wash the gradient... Using solid rgba fade means background converges to uniform color; gradient gets erased over time. Solution: CSS gradient on body, canvas transparent, and per-frame fill with rgba of near-black low alpha won't fully erase... actually fill with semi-transparent black over transparent canvas accumulates black, hiding CSS gradient. Alternative: use canvas with globalCompositeOperation 'destination-out' fill rgba(0,0,0,alpha) to fade trails by erasing alpha — this keeps canvas transparent so CSS background shows through. That's the classic trick. Yes: ctx.globalCompositeOperation='destination-out'; ctx.fillStyle='rgba(0,0,0,0.16)'; fillRect; then 'lighter' for drawing. 

Clear: ctx.clearRect(0,0,W,H) plus arrays emptied.

Stars: CSS/canvas background static — draw stars on a separate background? Could draw stars as CSS radial-gradients or a background canvas layer. Simplest: draw stars in the CSS body via multiple radial-gradients? Tedious. Alternative: put starfield in the fade? Stars would be erased. Use a second layer: draw stars with a repeating pattern... Simpler: keep body gradient plus a few CSS-generated stars using box-shadow? Or draw stars into a separate offscreen canvas element behind (id="bg") — but "procedural drawing only" fine. Could just skip stars or generate with JS on a background canvas that never gets cleared except on resize. I'll add a background canvas layer for stars — draws with plain ops, procedural. Actually one canvas is required "full-screen canvas" — extra background canvas is fine but adds complexity. Alternative: draw stars as part of the CSS using a JS-generated data... no, no external but data URI generated inline is allowed. Hmm, simplest: one canvas; on each frame after destination-out fade, redraw nothing for bg; instead set canvas CSS background via style with radial gradients generated in JS? That's CSS. Eh.

I'll just do: body has CSS gradient (deep navy to near-black), plus a second full-screen canvas #stars behind with procedural stars drawn on resize. Two canvases, both inline, procedural. That's clean. Or skip stars entirely — visual design free. I'll add stars, it's cheap and looks better. But "full-screen canvas" singular... The main canvas is still full-screen. Fine.

Actually simpler: skip separate star canvas, draw stars as part of body background using CSS box-shadow star field generated by JS: create a .stars div and set its box-shadow to many points. Cheap and no second canvas. Let's do: JS generates 140 star positions → element with box-shadow list "Xpx Ypx 0 0 #fff, ..." sized 1px. On resize, regenerate if dimensions change (throttle: only when size changes). Fine.

Hmm box-shadow with 140 shadows on one 1px element — fine perf.

Controls UI: top-left panel: title "Fireworks", subtitle; buttons: "Clear", maybe "Launch demo". Required only Clear. I'll include Clear and "Demo shell" (nice extra). Keep usable after resizing: fixed positioning, flex, media query for small screens.

Click behavior: clicking sky launches shell from bottom toward click. Ignore clicks on controls (they're separate elements above canvas; canvas listener only fires for canvas hits).

Also clicking below? If click near bottom, target close to bottom → shell quickly explodes; ensure minimum: if target y > H-120, still works (short hop). Fine, but ensure explosion visible: clamp target y to at most H-40? Let's clamp target within [40, H-60].

Trajectory: originX = clamp(targetX + (rand-0.5)*W*0.25, 60, W-60), originY = H + 20.

Flight time T = clamp(map distance), e.g., T = 0.9 + 0.5 * (dist / maxDist)... Let's compute T based on distance: T = 0.85 + 0.9 * (dist / Math.hypot(W, H)) → range ~0.85–1.75s. Then vx, vy as solved. Gravity g = 520 px/s² maybe. With T up to 1.75 and g=520: vy correction 0.5*520*1.75 = 455 px/s. Initial vy = (ty-oy)/T - 0.5*g*T. For ty-oy = -600 (H=800), T=1.5: vy = -400 - 390 = -790. Apex height reached... apex t = -vy/g = 1.52s > T, so it doesn't overshoot much. Trajectory passes through target at exactly T. Good.

But shell might rise above target then come back? Apex at t=1.52 vs arrival 1.5 — near apex at arrival, nice (bursts near top of arc). Good physics look.

Shell also emits sparks while ascending: each frame push spark particle at shell pos with small random velocity, short life (0.3-0.6s), color gold/white.

Also draw a fading trail polyline: store shell.trail points (max ~24), draw with gradient stroke width 3 alpha.

Burst: two variants: peony (uniform ring-ish) and willow? Keep: for each particle, angle random full circle, speed = maxSpeed * (0.55 + 0.45*pow(rand,0.5))... Ring look: speed mostly near max with jitter. I'll do speed = maxSpeed*(0.35 + 0.65*Math.pow(Math.random(),0.35)) → biased to outer. count = 80 + rand*50. maxLife = 1.2 + rand*1.1. gravity 260, drag 0.985^(dt*60)... apply per frame: v *= Math.pow(drag, dt*60) with drag=0.986.

Twinkle: when life < 0.35*maxLife, alpha *= (0.6 + 0.4*Math.sin(t*30 + seed)) or random flicker each frame.

Particle draw: alpha computed; ctx.globalAlpha = alpha; fillStyle = color; arc radius r = size*(0.6+0.4*alphaLife). Draw core: also draw white core for bright center: fillStyle '#fff' with alpha*0.5 smaller radius. To reduce state changes, batch: draw halo for all, then core? Grouping by color would help but fine at ~600 particles.

Also secondary sparkle particles on drag "crackle"? skip.

dt clamp: max 1/30 to avoid jumps.

Auto demo on load: setTimeout or immediately at first frame: launch(targetX = W*(0.35..0.65), H*0.3). Also maybe auto-launch second one after 700ms? Requirement: one demonstration shell. I'll do one at load (maybe two for spectacle? spec says "one demonstration shell" — launch one). I'll launch exactly one at load.

Visibility: pause when tab hidden? Optional.

Resize: update W,H, DPR, canvas size; also reposition? Not needed. Controls remain usable (CSS fixed).

Also handle pointer events: use 'pointerdown' on canvas; prevent default touch scrolling via touch-action:none on canvas.

Now headless verification harness: extract script, run with stubs.

Stub needs: document.getElementById returning objects; canvas stub: getContext returns Proxy with functions no-op and settable props; addEventListener no-op (we call launch/clear directly). window/globalThis: define requestAnimationFrame capturing callback; performance.now; setTimeout exists in node. Device pixel ratio: window.devicePixelRatio.

The script likely uses `window.addEventListener('resize'...)`. In vm context, provide window = globalThis-ish object.

Then simulate: call __fw.launch(tx,ty); step frames with fixed dt via exposed tick? I'll expose API: window.__fw = {state, launch, explode, clear, tick(dt) { step(dt); render(); }, stats()}. The rAF loop uses tick internally. In harness, stub requestAnimationFrame to no-op (don't auto-run), then manually tick.

Verification steps:
1. launch at (400,200) with H=800: check shell created, target recorded matches; after some ticks, shell position moves upward (y decreasing); shell.exploded false; at t≈T, exploded true, shell removed, particles created >0; particles spread: max distance from origin grows over first 0.3s; then positions fall (vy>0 eventually, y increases); alphas decrease; after lifetime all particles removed (empty arrays).
2. Overlapping: launch 3 → shells length 3.
3. clear() → arrays empty.
4. Multiple clicks different targets → targets differ.

Also verify no console errors: run script in vm, catch exceptions.

Let me write the HTML now.

CSS structure:

```css
*{box-sizing:border-box}
html,body{margin:0;height:100%;overflow:hidden;background:#05060f;font-family:...}
body{background:radial-gradient(ellipse at 50% 120%, #10214a 0%, #070a1a 55%, #03040c 100%);}
#stars{position:fixed;inset:0;pointer-events:none;box-shadow...} — element is a 1px dot with huge box-shadows; set left:0;top:0;width:1px;height:1px.
#sky{position:fixed;inset:0;width:100%;height:100%;display:block;touch-action:none;cursor:crosshair;}
#ui{position:fixed;top:0;left:0;right:0;padding:14px 16px;display:flex;gap:12px;align-items:flex-start;justify-content:space-between;pointer-events:none; z-index:5; color...}
.panel{pointer-events:auto; background:rgba(9,12,26,.55); backdrop-filter: blur(8px); border:1px solid rgba(255,255,255,.12); border-radius:14px; padding:10px 14px; display:flex; gap:10px; align-items:center;}
button{...}
.hint{...} fade after first click: class .gone {opacity:0}
footer hint bottom center.
```

Buttons: Clear (primary), "Demo" (secondary launches demo shell). Also show counters (shells/particles)? Nice: a stat readout. Keep simple: shells count / particles count in panel — helps verification visually. I'll add small stats span.

Media query for narrow screens: stack panel.

Now write file.

Script outline:

```js
(() => {
'use strict';
const canvas = document.getElementById('sky');
const ctx = canvas.getContext('2d');
let W=0,H=0,DPR=1;

const PALETTE = [...];
const G_SHELL = 520, G_PART = 240, DRAG = 0.986;

const state = { shells: [], particles: [], time: 0, clicks: 0 };

function resize(){
  DPR = Math.min(window.devicePixelRatio||1, 2);
  W = window.innerWidth; H = window.innerHeight;
  canvas.width = Math.floor(W*DPR); canvas.height = Math.floor(H*DPR);
  canvas.style.width = W+'px'; canvas.style.height=H+'px';
  ctx.setTransform(DPR,0,0,DPR,0,0);
  ctx.clearRect(0,0,W,H);
  buildStars();
}
```

Note setTransform resets; after clear, arrays unaffected (shells positions relative to new W — fine).

launch(tx,ty):
```js
function launch(targetX, targetY, opts={}){
  const tx = clamp(targetX, 40, Math.max(41, W-40));
  const ty = clamp(targetY, 50, Math.max(51, H-90));
  const spread = (Math.random()-0.5) * Math.min(W*0.5, 420);
  let ox = clamp(tx + spread, 60, Math.max(61, W-60));
  const oy = H + 24;
  const dist = Math.hypot(tx-ox, ty-oy);
  const T = 0.75 + 1.0 * (dist / Math.hypot(W,H) ... 
```

Hmm dist could be small when spread small. Use T = 0.8 + 1.1*(dist/Math.max(1,Math.hypot(W, H*0.9))) clamped [0.8, 2.0].

vx = (tx-ox)/T; vy = (ty-oy)/T - 0.5*G_SHELL*T.

Shell object: {ox,oy,x:ox,y:oy,vx,vy,tx,ty,T,age:0,color,trail:[],seed}.

step:
```js
function step(dt){
  state.time += dt;
  // shells
  for (let i=state.shells.length-1;i>=0;i--){
    const s = state.shells[i];
    s.age += dt;
    s.vy += G_SHELL*dt;
    s.x += s.vx*dt; s.y += s.vy*dt;
    s.trail.push({x:s.x,y:s.y}); if(s.trail.length>26) s.trail.shift();
    // sparks
    emitSparks(s, dt);
    if (s.age >= s.T || Math.hypot(s.x-s.tx, s.y-s.ty) < 14 && s.age >= s.T*0.6 ...) explode
```

Since exact arrival at age==T, use `if (s.age >= s.T)` explode at target position (use s.tx,s.ty for clean burst center). Good.

Cap dt step inside loop? dt already clamped in tick.

Sparks: emit with rate: accumulate s.sparkAcc += dt*rate; while >=1 push spark.

explode(x,y,color):
```js
function explode(x,y,hueColor){
  const count = 70 + (Math.random()*50|0);
  const maxSpeed = Math.min(W,H) * (0.55 + Math.random()*0.25); // px/s? For H=800 → 440-660. particles travel v/g... 
```

Range of particle: with drag, distance ≈ v * tau where tau ≈ 1/(k*60)... drag 0.986 per frame → per-second factor 0.986^60 ≈ 0.434, so decay rate k = -ln(0.434) ≈ 0.835 /s. Distance ≈ v/k * (1-e^-kt) ≈ 1.2*v over 2s. For nice spread of ~250px radius, v ≈ 200 px/s... hmm that gives 240px. Let's set maxSpeed = min(W,H)*0.32 ≈ 256 for 800 → spread ~300px radius. Plus gravity fall. Good. I'll tune: maxSpeed = Math.min(W,H)*0.34.

Add color variety: pick base color, maybe secondary accent color for some particles.

Also add a bright flash at explosion: particle kind 'flash' big, life 0.25, radius 60 shrinking — nice.

Particle fields: x,y,vx,vy,life,max,color,size,dragMul,grav,flicker.

step particles:
```js
for i reverse: p.life -= dt; if (p.life<=0) remove; 
 p.vy += (p.grav||G_PART)*dt; const d = Math.pow(p.drag, dt*60); p.vx*=d; p.vy*=d; p.x+=..., p.y+=...;
 if (p.y > H + 60) remove? — particles falling below screen could still have life; remove to save. Actually they'd be invisible anyway; removing ok. But requirement: removed after lifetime — normal ones do. Extra culling fine.
```

render:
```js
function render(){
  ctx.globalCompositeOperation = 'destination-out';
  ctx.fillStyle = 'rgba(0,0,0,0.22)';
  ctx.fillRect(0,0,W,H);
  ctx.globalCompositeOperation = 'lighter';
  ctx.globalAlpha = 1;
  // shells trails
  for shells: draw trail polyline, glow dot
  // particles
  for particles: draw
  ctx.globalCompositeOperation='source-over';
}
```

Trail polyline: multiple strokes with decreasing alpha/width: iterate points. Cheap enough: 26 segments * ~4 shells.

Glow: radial gradient per shell each frame — small count, ok. Or two arcs. I'll use arc with color and a white core, plus arcs of increasing radius decreasing alpha (3 circles) — cheap.

Particle drawing: 
```js
ctx.globalAlpha = a; ctx.fillStyle = p.color; ctx.beginPath(); ctx.arc(p.x,p.y,p.size,0,TAU); ctx.fill();
```
begin/arc/fill per particle ~600/frame — acceptable. Add core: skip white core per particle; instead occasionally (flicker) draw bigger. Simpler: draw halo circle at size*1.8 with alpha*0.25 and core at size with alpha — two draws. 1200 ops maybe fine on modern browsers at 60fps? Probably ok for demo. Alternative optimization: use path batching per color: group particles by color into paths. Let's do: build map color → path? globalAlpha differs per particle though. Use ctx.globalAlpha per particle anyway. I'll keep simple two-pass: first pass halo (same fillStyle batching by grouping is complex). I'll just do single circle per particle with 'lighter' composite, size scaled by alpha, plus a tiny white center only when alpha>0.75. Fine.

Actually with 'lighter', single circles look decent with the trail fade.

Stats update every ~200ms: set textContent.

Clear function:
```js
function clearScene(){
  state.shells.length=0; state.particles.length=0;
  ctx.setTransform(DPR,0,0,DPR,0,0);
  ctx.globalCompositeOperation='source-over'; ctx.globalAlpha=1;
  ctx.clearRect(0,0,W,H);
}
```

Auto demo: on load after slight delay 350ms: launch(W*0.5 + jitter, H*0.32). Use setTimeout, but guard: launch uses W,H which are set by resize called first. Also re-launch demo if user clicks "Demo".

Hint: bottom center text "Click anywhere in the sky to launch a shell" — fade out after first click.

Loop:
```js
let last = performance.now();
function frame(now){
  const dt = Math.min(0.033, Math.max(0.001,(now-last)/1000)); last=now;
  tick(dt);
  requestAnimationFrame(frame);
}
requestAnimationFrame(frame);
```

Pause when document.hidden: skip heavy work? If hidden, rAF stops anyway.

Expose API:
```js
window.__fw = { state, launch, clear: clearScene, explode, tick, get dims(){return {W,H}} };
```

tick(dt){ step(dt); render(); }

Now the harness. Extract script: read index.html, get content between `<script>` and `</script>` (last script). Run via node vm with a context containing document, window, performance, requestAnimationFrame (stub that doesn't auto-run... but the script calls requestAnimationFrame(frame) at end — if stub records but doesn't call, loop never runs; then I manually call tick. Good — but `performance.now()` used for `last`; provide {now:()=>Date.now()}.

document.getElementById: return canvas stub for 'sky', element stub for others (textContent settable, classList add/remove, addEventListener). Also document.addEventListener maybe.

window stub: innerWidth/innerHeight, devicePixelRatio, addEventListener. In script I may use `window` explicitly or bare globals. In vm context I'll set globalThis.window = globalThis-ish proxy. Easiest: create context object ctx with window referring to the same context object (vm.createContext returns contextified object; set window = that object? can't easily self-reference before creation — actually you can: const sandbox = {...}; sandbox.window = sandbox; vm.createContext(sandbox). Yes! Works).

canvas stub: {width,height, style:{}, getContext:()=>ctxStub, addEventListener(){}, getBoundingClientRect...}. ctxStub: Proxy: get(target, prop) → if prop in target return; else return ()=>{} (function) — but properties like fillStyle are set (set trap allows) and read... a function returned for fillStyle read is fine since we don't branch on it. But `ctx.globalCompositeOperation` read? We don't read. `ctx.setTransform` function ok. Also `ctx.canvas`? not used. Proxy with get returning ()=>{} works but `ctx.beginPath()` etc fine. Careful: Proxy get returning function for everything also means e.g. `ctx.fillStyle` returns function — fine.

Better: explicit stub object with methods list, and a Proxy fallback. I'll do Proxy.

Measure calls count optionally to verify render drew particles: count 'arc' calls.

Then tests:
1. run script (auto demo scheduled via setTimeout — in node it will fire after 350ms real time; to control, I'll make the demo launch happen on first frame instead: `let demoLaunched=false; in frame/tick: if(!demoLaunched && ...)`. Hmm but if using setTimeout in browser it's fine; in harness rAF never runs so tick never called unless I call it. If demo launches inside tick on first call, I control it in harness. But then demo launches on first animation frame — good ("on initial load"). I'll implement: in the rAF frame function, before stepping: if(!state.demoDone){state.demoDone=true; launch(demoTarget())}. That guarantees visible-at-load behavior and is harness-controllable.

Actually initial launch immediately at script end also fine and simpler to reason: call schedule: `requestAnimationFrame(()=>launch(...))`? Keep in frame — first frame.

Test plan in harness:
- sandbox window.innerWidth=1200, innerHeight=800.
- run script. Check no throw. Check __fw exists, arrays empty.
- tick(0.016) → demo shell exists (length 1) with target y ≈ H*0.3ish and recorded target.
- Launch explicit: __fw.launch(400,250). shells length 2. Check new shell target tx≈400 (within clamp) ty≈250.
- Step until shell explodes: loop tick(1/60) up to 400 frames tracking: assert shell y decreases during ascent (min y < start y - 50). Record first frames positions.
- After explosion: shells contains other shell maybe; check particles count > 50; check particles' distances from burst origin increase between t+0.1 and t+0.3 (spread). Check alpha/life decreasing: sample average life decreasing. Check some particle y increases later (gravity): run further frames until some particle vy>0 and y increased.
- Run many frames (e.g., 60*8) until all particles from that burst die → arrays eventually: demo burst also dies; after enough ticks shells and particles empty → confirms removal after lifetime.
- clear test: launch 3 shells + explode some particles, call __fw.clear() → both arrays empty.
- resize test: change innerWidth/Height, call resize (dispatch resize handler registered via window.addEventListener('resize', ...) — capture handlers in stub) → W/H updated, canvas.width updated; then launch still works and controls (buttons) still have handlers — that's DOM, check button element exists and had addEventListener called with 'click' (record listeners in stub).

Also check console errors: wrap run in try/catch and collect.

Let me now write index.html fully.

Also make sure clicking the sky works: canvas 'pointerdown' → compute rect → launch. In harness, simulate by invoking captured canvas listener with a fake event {clientX, clientY, pointerId, preventDefault} — getBoundingClientRect stub returns {left:0,top:0,width:1200,height:800}. Then check a shell with target ≈ clicked point. 

Also ensure clicks on UI don't launch: UI panel is a separate element above canvas; since listener is on canvas, clicks on panel don't hit canvas (pointer-events on panel auto, canvas underneath). The #ui container has pointer-events:none so clicks pass through except panel/buttons. Good.

Write the file.

Star field: buildStars() creates element '#stars' style.boxShadow with many shadows; regenerate on resize only if size changed significantly (else skip to avoid cost). I'll store lastStarW/H; regenerate when |W-last|>40 || |H-last|>40 (or first).

Star shadow string: `${x}px ${y}px 0 ${r}px rgba(...)` — box-shadow with spread creates square? With 0 blur and spread r on a 1px box, you get a square of size 1+2r — acceptable tiny dots; better use blur: `${x}px ${y}px ${r}px ${r/2}px rgba(255,255,255,${a})`. Use blur for round glow.

Number of stars ~120, string length ok.

Twinkle stars: could animate via CSS animation on the container (opacity pulse) — cheap: two layers? Skip; add a subtle CSS animation `twinkle` on #stars with varying opacity 0.75↔1 over 6s. Single element pulsing all stars together — acceptable-ish. Two star layers with different phases would be better; I'll create two divs? Keep one, with CSS animation; fine.

Hint fade: after first user click, add class 'hidden'.

Let me also handle 'resize' listener and orientation.

Buttons: 
- Clear → clearScene()
- Demo → launch demo shell (also counts as interaction, hides hint).

Stats: `#stats` span: `${state.shells.length} shells · ${state.particles.length} sparks` updated in frame every ~150ms.

Now write it.

Code for particle spawn details:

```js
function explode(x, y, color){
  const scale = Math.min(W, H);
  const flash = {x,y,vx:0,vy:0,life:0.32,max:0.32,color:'#ffffff',size:scale*0.06,grav:0,drag:1,flash:true};
  ...
  const n = 78 + Math.floor(Math.random()*46);
  const speed = scale * (0.30 + Math.random()*0.12);
  const color2 = pick(PALETTE);
  for(let i=0;i<n;i++){
    const a = (i/n)*TAU + Math.random()*0.18;   // even ring
    const sp = speed * (0.45 + 0.55*Math.pow(Math.random(),0.6)) * (0.85+0.3*Math.random());
    ...
```

Hmm, mixing: for peony, even angles with jitter gives nice radial burst. Use angle = i/n*TAU + jitter.

Also add a few "comet" particles with longer life and bigger size (10% chance).

Particle colors: 70% base color, 30% second color, 8% white.

Life: 1.1 + Math.random()*1.2 (seconds); comets 1.8+.

grav: 210; drag: 0.986.

Flicker: in render, if p.life < p.max*0.4: alpha *= 0.55 + 0.45*Math.sin(state.time*24 + p.seed*10) — could go near zero sometimes → nice twinkle.

Alpha base: (p.life/p.max) eased: Math.pow(lifeRatio, 0.75) maybe for slower fade start. Use pow 0.8.

Flash particle: alpha = life/max, size shrink from scale*0.07 to 0, drawn as radial gradient? Use arc with white and globalAlpha — with 'lighter' a white circle looks like a blob; better radial gradient for flash. One gradient per explosion per frame for ~0.3s — fine: create gradient in render when p.flash.

Also explosion could add a brief shockwave ring: p.kind='ring', radius grows, stroke width shrinks, alpha fades. Nice touch, cheap: draw arc stroke. I'll add ring particle: life 0.45, r = ease-out to scale*0.16, lineWidth = 3*(1-t)+0.5, color base.

OK, write.

Shell drawing: trail via line segments:
```js
function drawShell(s){
  const t = s.trail;
  if(t.length>1){
    ctx.lineCap='round'; ctx.lineJoin='round';
    for(let i=1;i<t.length;i++){
      const k = i/t.length;
      ctx.strokeStyle = s.color; ctx.globalAlpha = 0.5*k;
      ctx.lineWidth = 1 + 3*k;
      ctx.beginPath(); ctx.moveTo(t[i-1].x,t[i-1].y); ctx.lineTo(t[i].x,t[i].y); ctx.stroke();
    }
  }
  // head glow
  ctx.globalAlpha=0.9; ctx.fillStyle=s.color; arc r=4.5
  ctx.globalAlpha=1; ctx.fillStyle='#fff'; arc r=2
}
```
That's 26 strokes/shell — fine.

Also shell head glow gradient: skip.

Now, canvas fade with destination-out at 0.22 — trails last ~ frames. Good.

One caveat: destination-out fillRect with alpha 0.22 requires the canvas to accumulate; drawing with 'lighter' adds color+alpha. Fine.

Clear: also reset hint? no.

Edge: pointerdown on canvas at coordinates; use e.clientX - rect.left. On high-DPR we set transform so drawing in CSS px — correct.

Let me write the file now. Then harness.

Also should I worry that `performance.now` may not exist? Browser fine.

Write index.html.

Let me write carefully and completely.

Also add `aria` labels? not needed.

Writing now.

Also handle pointer events: 'pointerdown' on canvas.

Now write a headless harness in /tmp to verify: extract script, stub DOM, run, simulate frames, and assert behaviors:
- demo shell launches on first tick
- pointerdown launches toward click target
- shell ascends, bursts at target
- particles spread, fall, fade, removed after lifetime
- overlapping shells supported
- clear empties scene
- resize keeps W/H and buttons wired

Let me write /tmp/fw_test.js.

Wait, there's an issue: `setTimeout: (fn) => {}` stub won't fire — fine.

Also `makeEl` function is defined but unused with broken classList referencing `el.classes` — it's never called, fine (defined but not used). Actually it may throw at definition? No, function body not executed. Fine.

Potential issue: my clear test expects demoDone flag — tick() sets demoDone on first tick and launches demo. In test [6] I check after Clear that shells.length===0 — but demoDone was already set on first tick so no relaunch. Good.

But careful: in test [5] I run(6) — during that, particles expire. Then test [6]: launch 3 shells, run(1.4). T up to ~2.1s so shells may still exist plus particles. Check sum > 20 — likely.

Test [2]: pointerdown with clientX=400, clientY=250. In onSkyPointer, rect from getBoundingClientRect uses sandbox.innerWidth... width=1200, W=1200. Fine.

Test [3]: burst loop breaks when shell removed. But note clicked shell might be index... `fw.state.shells.indexOf(clicked) === -1`. Note demo shell also explodes during that loop; fine.

Also minY check: minY < py + 40 = 290. Target ty=250, ballistic passes through exactly at T, and continues past (apex near arrival). minY would be near 250 maybe slightly above due to passing beyond target. Actually the shell passes through target at exactly T then we explode immediately at age>=T, so it stops at ~250. minY ≈ 250 < 290. Good.

startY: clicked.y at launch = H+24 = 824. minY < 824-100. Good.

Test arcCalls for shell trail draws too: `arcCalls >= particles.length` — shells drawn with arc too, so >= holds.

Test [4] draw call check: `fw.tick(DT)` — but that also might relaunch? demoDone set already. Fine.

One concern: in step(), I use `var retain = Math.pow;` and `retain(p.drag, dt*60)` — fine.

flash/ring particles: life decreases in step before the `continue` — yes, life -= dt first, then if <=0 remove, then if flash/ring continue. Good.

Potential issue: `alphaOf` for flash uses p.max — set in addParticle. Good.

updateStats uses performance.now() — stub exists.

In frame(), first rAF passes t; we set last = t then frame(t): dt = 0 → `!(dt>0)` → dt=1/60. Good.

One more: canvas.addEventListener exists on element stub. Yes.

hintEl.classList.add('gone') — stub has classList.add. In test, `elements.hint.classList.contains('gone')` — my stub classList has contains. Good.

Note the unused broken `makeEl` — it defines classList.add referencing `el.classes` where `el` is the other function... never executed, harmless, but sloppy; remove it. Actually `el` refers to the second function declaration (hoisted), so `el.classes` would be undefined at runtime — never called though. Let me clean it up before running? It's test-only; leave but harmless. Actually better remove to avoid confusion — quick edit.

Let's run.

Two issues:
1. The syntax-check via process substitution failed (harness limitation, not code).
2. The ctx stub's `createRadialGradient` returns `() => {}` (a function, not gradient object) → `.addColorStop` undefined. That's a stub deficiency, not app bug — but I should verify. Fix stub: make Proxy return for `createRadialGradient`/`createLinearGradient` a function returning `{addColorStop(){}}`.

Also `arc` special case handled. Let me update the proxy get: if prop === 'createRadialGradient' return () => ({addColorStop(){}}).

Also I should do a proper syntax check: extract to temp file.

Wait, my edit changed the arc stub body — `return () => { arcCalls++; };` became `return () => { arcCalls++;\n      };` — that's still fine (syntax ok, arrow with block body). Actually let me check: newText was:

```
    if (prop === 'arc') return () => { arcCalls++;
      };
    if (prop === 'createRadialGradient' || prop === 'createLinearGradient') return () => ({ addColorStop() {} });
```

Valid JS. OK.

Now run with a proper syntax check first.

One failure: "particles spread outward (avg radius 102.7 → 84.3px)". Why did the average radius shrink over 0.15s? Because sample includes particles from the *demo* burst? No — sample is taken from fw.state.particles filtered !p.kind at time after the burst of the clicked shell... but wait, at that point the demo shell already exploded earlier (it started at same time? demo launched on first tick, T similar). Actually particles at that moment include demo's sparks and clicked shell's burst sparks (shell sparks are !p.kind too).

But shrinking avg radius: shell sparks (emitted near bottom, rising) have vy = s.vy*0.10 — s.vy is large negative initially (~-790), so sparks get upward velocity... those rise toward... hmm.

More importantly: particles in `sample` are drawn from the *beginning* of state.particles array. The array order: demo sparks first, then demo burst, then clicked shell sparks, then clicked burst. sample = first 40 non-kind particles → these are demo shell's early sparks (launched at bottom, moving up) and demo burst particles.

Actually the real reason avg shrank: sample includes particles that are near the top decelerating/turning around? Radius from (ox,oy) = clicked burst center. Demo particles are at a different location...

Hmm wait — clicked burst happens at (400,250). Demo burst happens at random ~ (600, 240). Particles from demo that are close... 

Let me think again: the key issue is measuring spread correctly. Better test: measure radius over time for particles created by that specific burst. I can tag particles with burst id. Alternatively measure max radius growth, or filter particles near burst center within 200px at t0 and track those same ones.

Actually a plausible physical reason for shrink: after 0.15s, drag reduces velocity but radius from origin still grows monotonically... unless particles reverse direction (they don't reverse; drag only slows, gravity adds downward). Radius from burst origin: particle moving upward-fast decelerates... position still increases along its velocity direction until velocity rotates. A particle moving straight up with drag: y decreases (upward) still, radius grows. A particle launched downward: gravity accelerates it downward, radius grows. Radius can shrink only if velocity direction reverses past the origin direction — for a particle moving up-left... no reversal of position along the axis unless velocity flips sign, which drag+gravity never does for upward-moving (gravity reduces vy toward positive, can flip from negative to positive — that moves it back down through... wait, upward-moving particle: vy negative, gravity makes vy less negative → still moving up until vy=0 then down. Position y decreases then increases. Its distance from origin: it went up, then comes back down — passes back through origin point? Only if it returns. Over 0.15s unlikely.

So the shrink must be from mixing in unrelated particles (demo burst particles moving away from demo center, whose distance to clicked center happens to decrease), or from shell sparks still being emitted (near bottom, moving up toward... no, sparks are at y~800, far below, radius large ~550, and moving up → radius shrinks!). Yes! Shell sparks: emitted at shell position along ascent; after clicked burst the shell is gone so no new sparks. But demo's... hmm at that sample time, are shells still present? Both shells burst around the same time (T~1.26 vs demo T). The sample includes shell-sparks from both shells (located along ascent path at various heights). Shell sparks near the top of ascent are close to burst origin; their motion after burst... those sparks have vy = s.vy*0.10 ± jitter; near burst time s.vy ≈ ~0 (apex) so jitter small; they drift. Sparks below the origin moving upward → radius shrinks.

Also gravity on sparks (120) slows their upward motion.

So the measurement is contaminated. Fix test: filter particles within 250px of burst center AND tag. Better: tag burst particles in explode() with `burst` id? I could add `p.burstId` for testability — harmless. Or in the test, snapshot which particle object identities exist at burst time and only track those that are within radius and have speed > threshold... Shell sparks also qualify.

Cleanest: record particles created by this burst: in the test, before the burst happens note particles.length... we know burst time. Instead: filter by size/speed — burst particles have |v| > 100 initially; shell sparks have small speeds? Shell sparks: vx = s.vx*0.12 ± 26 → small; vy = s.vy*0.10 ± 18 → up to ~80. Burst speeds: scale*0.30.. = min(1200,800)*0.43 ≈ 344 max, min 0.35*240=84... overlapping ranges.

Simplest robust approach: tag particles with a burst counter. In explode(): `burstSeq++` and set `burst: burstSeq` on each particle; sparks get `burst: 0`. Test: record burstSeq value of clicked burst... test can read `state.burstSeq`. Add to state: state.burstSeq = 0; in explode increment and tag. Also flash/ring get the tag (kind filter excludes them).

That's a small, harmless addition for testability. Let's add:

In explode: `state.burstSeq = (state.burstSeq || 0) + 1; var bid = state.burstSeq;` and add `burst: bid` to each particle added there.

Then test: after burst detected, bid = state.burstSeq; sample = particles.filter(p => p.burst === bid && !p.kind); d0 measured right after burst (a couple frames), then run 0.15 → d1.

Wait: d0 measured immediately after burst includes the first-frame positions (all at origin → radius ~0), so avg0 small, avg1 larger. Good.

Also might keep a "radius growth over multiple samples" check.

Let me implement.

Also, one more consideration on visual check: I can't run a real browser (no browser tool available in this environment? The tools list only has read/bash/edit/write — the browser tool is mentioned in the tool descriptions at top but not in my function list. Let me check: functions available: read, bash, edit, write. The system message describes browser tool in tool schemas... Actually the <functions> block lists read, bash, edit, write only. The addendum mentions browser tools but they aren't available. So headless verification via node is the best I can do. I could also render frames to PNG using a pure-JS canvas implementation — not available without deps (no network). 

Alternative visual check: I could implement a tiny software rasterizer in the harness? Overkill. But I could at least capture drawing commands (arc positions/colors/alphas per frame) and verify visually plausible distribution — e.g., render an ASCII/PNG map of drawn particle positions! I can write a PPM/PNG manually: track arc calls with x,y,r,color,alpha from the stub (I can record fillStyle and globalAlpha at time of arc call). Then rasterize simple filled circles into an RGB buffer and write a PNG (need zlib — node has zlib built-in! I can write a minimal PNG encoder using zlib.deflateSync). That's quite feasible and gives a real visual check of ascent/burst/fall frames.

Let's do it: in the ctx stub, track current fillStyle/globalAlpha; on arc(x,y,r) record; on fill(), emit a "dot" into framebuffer with additive blending (approximating 'lighter') and radial alpha falloff. Also handle stroke for trails/rings (record arcs with stroke — draw ring outline). Also fillRect for fade (destination-out — skip, or approximate by multiplying framebuffer alpha by 0.8 — actually for a still frame per snapshot, we can just render particles as they appear that frame).

Simpler: build frames as snapshots of drawn primitives each tick, then rasterize: for each frame, accumulate additive color over black background + dark navy gradient, write PNG at a few timestamps (ascent mid, just after burst, mid-fall, post-clear). Then I can view them with the read tool (images supported!). read supports png images. 

Let's do that — good verification of the visual.

Implementation details in harness:
- ctx stub: track props via set trap (fillStyle, globalAlpha, strokeStyle, lineWidth, globalCompositeOperation).
- record ops: on arc push {type:'arc', x,y,r, fill: currentMode?}. Determine mode by whether next call is fill or stroke: keep pending arc; on fill() → emit disc; on stroke() → emit ring.
- Also 'flash' uses gradient fill with arc: fillStyle is a gradient object? In app, for flash: ctx.fillStyle = g where g is result of createRadialGradient → in stub returns {addColorStop(){}} object. Then fill after arc → we'd emit disc with fillStyle being an object → handle: if fillStyle is object (gradient) → use warm white color.
- destination-out fillRect (fade): globalCompositeOperation === 'destination-out' and fillRect → skip (we build each frame fresh) — or multiply buffer by 0.8 to mimic trails. For stills, skipping is fine; but trails are part of the look. I'll multiply existing buffer by 0.82 when destination-out fillRect seen — that mimics fade. Then 'lighter' fills add color. Background: initialize each frame? If we never clear, buffer persists across frames — but I snapshot per frame anyway: I'll keep a persistent buffer to accumulate trails across the run (accurately mimicking the canvas!), and snapshot copies at chosen times. 

Nice: buffer persists; each tick: apply fade on fillRect destination-out (multiply rgb by 0.8), draw ops additively. clearRect → clear buffer. That exactly emulates the real canvas behavior. Then at chosen sim times, deep-copy buffer → write PNG.

Frames: write PNGs at: t=0.6s (demo shell mid-ascent), t=1.4s (just after demo burst ~0.15s after), t=2.0s (falling + second shell), t=2.6s (second burst), then clear → t=2.7 (empty), etc. I'll instrument: run in small increments and snapshot at specific times.

PNG encoder: 8-bit RGB, zlib deflate, CRC32. Write helper.

Rasterization: additive with radial falloff: for disc radius r: loop bounding box, d = dist, alpha = max(0, 1 - d/r) (or smooth), color = hex→rgb * alpha * globalAlpha. For ring: alpha based on |d-r| < lineWidth.

Sizes are small (r ~1-5 px, rings up to ~140px) — cheap. Canvas buffer at full 1200x800*3 bytes = 2.8MB, fine.

Let's write this improved harness. I'll rewrite /tmp/fw_test.js keeping existing checks, fixing the spread check with burst tagging, and adding PNG snapshot output.

Also need to add burst tagging to index.html.

Edits to index.html:
1. state: add `burstSeq: 0`.
2. explode: increment and tag particles.

Also should I double check one visual issue: particle colors under 'lighter' additive — fine.

Another check: at 233 particles for one burst + 90 sparks/s shell... fine.

Let me edit index.html.

Now rewrite the harness with: fixed spread check (filter p.burst === bid), plus PNG rasterizer snapshots.

PNG encoder helper:

```js
const zlib = require('zlib');
function crc32(buf){...}
function png(rgb, w, h){
  // rgb: Buffer w*h*3
  const raw = Buffer.alloc((w*3+1)*h);
  for(let y=0;y<h;y++){ raw[y*(w*3+1)] = 0; rgb.copy(raw, y*(w*3+1)+1, y*w*3, (y+1)*w*3); }
  const idat = zlib.deflateSync(raw);
  function chunk(type, data){
    const len = Buffer.alloc(4); len.writeUInt32BE(data.length);
    const t = Buffer.from(type); const crcBuf = Buffer.concat([t, data]);
    const crc = Buffer.alloc(4); crc.writeUInt32BE(crc32(crcBuf)>>>0);
    return Buffer.concat([len,t,data,crc]);
  }
  const ihdr = Buffer.alloc(13); ihdr.writeUInt32BE(w,0); ihdr.writeUInt32BE(h,4); ihdr[8]=8; ihdr[9]=2; // 8-bit RGB
  return Buffer.concat([Buffer.from([137,80,78,71,13,10,26,10]), chunk('IHDR',ihdr), chunk('IDAT',idat), chunk('IEND',Buffer.alloc(0))]);
}
```

crc32 table implementation.

Frame buffer: Float or Uint8Array w*h*3. Since we do additive and multiply-fade, use Float32Array for precision, convert to Uint8 on snapshot (clamp 0-255, maybe gamma). Background: start with sky gradient (radial dark navy) as base? The canvas is transparent over CSS gradient. For PNG, composite over CSS background: base = gradient color computed per pixel, plus buffer content (canvas drawn 'lighter' onto it... real compositing: canvas pixels have premultiplied color added over CSS bg). So out = bg + buffer (additive-ish since 'lighter' within canvas; canvas over bg = bg*(1-a) + c*a — approximately bg + c for bright content). Use bg + buffer, clamp.

CSS bg: radial-gradient(ellipse 120% 90% at 50% 115%, #16264f 0%, #0a1130 42%, #05070f 75%, #03040a 100%). Approximate: compute simple radial distance from (0.5W, 1.15H) with radii 1.2W, 0.9H, mix stops. Good enough.

Also stars: draw a few dots from #stars boxShadow? The stars element exists with boxShadow string; I can parse it and draw points. Let's parse "Xpx Ypx Rpx Bpx rgba(...)" — doable with regex. Nice touch: adds realism to snapshot. I'll include, tolerant to failure.

Resize handling for buffer: recreate on resize (my test resizes later; handle by recreating buffer and clearing).

Ops recording per tick is transient — I'll process ops immediately during tick? Ops happen inside tick calls, but ctx stub doesn't know the framebuffer... it can: shared `fb` object with draw functions. So ctx stub's fill()/stroke() operate directly on fb using current state. 

Frame buffer ops:
- set props via set trap: fillStyle (string or object), strokeStyle, lineWidth, globalAlpha, globalCompositeOperation.
- fillRect(x,y,w,h): if gco==='destination-out' → multiply region by (1 - alpha*fillAlpha?) — real behavior: dst *= (1 - srcAlpha). srcAlpha from fillStyle 'rgba(0,0,0,0.20)' → parse alpha 0.20, and globalAlpha. So fb *= 0.8 across region. If gco==='lighter' or source-over → treat as additive rect with color (used only for fade though; sky clear uses clearRect).
- clearRect → zero region.
- arc(x,y,r) → push pending arc {x,y,r}.
- fill() → if pending arc: disc fill with current fillStyle color & globalAlpha; else fillRect pending? Only arcs are filled in app besides fillRect. Also gradient fillStyle object → warm white radial.
- stroke() → ring with strokeStyle, lineWidth.
- beginPath() → reset pending.
- moveTo/lineTo → segments for shell trails: record points; stroke() with pending polyline → draw line segments with lineWidth. Implement: keep `path = {type:'line', pts:[...]}` when moveTo/lineTo used, arc resets.
- setTransform → ignore (identity assumed).
- createRadialGradient → object with stops; store as {stops:[[offset,rgba]]} and when used as fillStyle in disc fill, sample: approximate radial: inner color at center to transparent at edge using stops — I'll approximate with two-stop handling: color0 with alpha0 at center scaled, fade to 0 at edge. Simpler: treat gradient fill disc as: for each pixel, t=d/r; a = lerp of stop colors... I'll implement basic: find stops sorted, interpolate rgba by t, multiply by globalAlpha.

That's enough fidelity.

Colors: parse '#rrggbb' and 'rgba(r,g,b,a)'.

Let's write the draw helpers on fb:

```js
function addDisc(x,y,r,color,alpha,falloff=1)
function addRing(x,y,r,color,alpha,width)
function addSeg(x0,y0,x1,y1,color,alpha,width)
function fadeAll(k)
```

Rasterization cost: ring for burst: r up to 136, width 3 → area ~2πr*width ≈ 2500px fine. Disc flashes r~80 → 20000 px fine. Particles hundreds of small discs fine.

Snapshot at times: use loop with manual time accumulation.

Test flow with snapshots:
- t=0.55 (demo mid-ascent) → shot1
- continue to t≈1.45 (0.15 after demo burst at ~1.3?) demo burst time = demo.T ≈ 1.2-1.3. I'll snapshot when demo shell disappears + 0.12s → shot2 (burst spread)
- launch clicked shell (400,250) at that time; snapshot mid-ascent t+0.6 → shot3
- after clicked burst +0.25 → shot4 (spread + early fall)
- run +1.2 → shot5 (falling/fading)
- clear → shot6 (empty)

Then read the PNGs.

Since PNG snapshots need specific times, I'll write `runUntil(pred)` ticking and checking.

For the burst spread check: filter by p.burst === bid.

Alright, rewrite /tmp/fw_test.js fully.

Note: My current test [3] loop breaks when shell removed, using state.burstSeq to identify bid: bid = fw.state.burstSeq after burst.

Careful: demo shell may explode in the same tick as clicked shell? Different T likely. Anyway filter by bid.

Also I need hexToRgb parser handling '#rgb'? we only produce 6-digit hex and rgba strings.

globalAlpha default 1.

Also 'destination-out' fade: fillStyle 'rgba(0,0,0,0.20)' → dst *= (1 - 0.20*globalAlpha) = 0.8.

Implement fade region = whole canvas (fillRect 0,0,W,H).

One catch: my ctx stub's `fillRect` when gco is 'source-over' — after clearScene, clearRect called with gco source-over → zero. Fine.

Also drawShell uses lineCap etc — ignore unknown props (set trap stores).

Now, the app also does ctx.setTransform — stub no-op.

Buffers on resize: I'll expose resize callback in harness: when sandbox.innerWidth changes and resize handler called, recreate fb. fb module-level with function `setSize(w,h)`.

Let me write it.

For reading PNGs with the read tool — yes, read supports png images.

Snapshot dimensions: full 1200x800 PNG — fine.

Let me also make sure I only snapshot at times meaningful.

Time control: my run(seconds) ticks DT. Track simulated time variable in harness (tSim) incremented each tick; I'll manage manually.

Write the file.

Wait — issue in [3]: I reference minY_true() before... function declaration hoisted, fine. But `minY` variable unused; ok.

Also demo.age: after shell removed, s.age was incremented to >= T in that tick before splice — demo.age ≈ T. But demo object retains last values. age check |age - T| < 0.05: age = T + up to dt overshoot (dt=1/60=0.0167). fine.

Potential issue: in [3], during `until(...)` the demo might burst; but the click in [2] happened before, so both shells ascend. Also note in [4], `d0` sampled right after `until` returns — burst just happened this tick; particles at radius ~0..small. d0 avg maybe ~10. After 0.2s, avg should be much larger.

Wait — potential problem: shells sparks have burst: undefined → filtered out since p.burst === bid fails for undefined. Good.

Another: `snapshot()` uses FB.buf indexed with FB dimensions; when resized I call FB.setSize before running resize handler — order fine.

`FB.buf.every(v => v === 0)` — Float32Array.every exists. Good.

In [7] I call FB.clear() manually after click — but clearScene in app calls ctx.clearRect which my stub already clears FB. So manual clear redundant; fine.

But careful: after Clear, snapshot shot4 uses stars/gradient → not zero; that's composited output. The `emptyShot` check uses FB.buf directly. Good.

In [4]: `check(minY_true(), ...)` — minY_true returns a number like 263 → truthy always. Weak check; make it numeric comparison: return Math.min(...)... Let me improve: I'll instead track minY during ascent properly. But demo object is gone; I can't re-simulate. Simplest: track minY while running `until` loop. Let me restructure: instead of `until`, loop manually recording minY.

Let me fix that section: replace `const gone = until(...)` with a manual loop that records minY.

Edit the test file.

Wait — there's an ordering problem: in [2] the click happens before the demo shell bursts, and in [3] I loop until demo bursts while tracking minY of demo. Fine.

But there's a subtlety: `demo.trail` — during [1] I ran 0.55s already. Fine.

Also [1] check `fw.state.shells[0].y < demo.oy - 150` — after 0.55s+1 tick, y should be way above 824-150=674. With T~1.3, after 0.55s... vy0 ≈ -(600)/1.3 - 0.5*540*1.3 ≈ -461-351 = -812; y(t)=824 -812t +270t² → at t=0.55: 824 - 446 + 81 = 459 < 674 ✓.

Hmm but `demo` const reference: shells[1] later. In [1] shells[0] is demo. ok.

Run it.

Three failures — all appear to be test-metric issues, not app bugs:

1. "shell visibly rose (y 479 → 295)" — startY was demo.y *after* the initial 0.55s run (y=479), and threshold is startY-200 = 279, minY=295 > 279. Test bug: startY should be captured at launch (oy=811). Fix threshold: use demo.oy as reference or capture startY at test start. Fix: `check(minY < demo.oy - 300, ...)`.

2. "lifetimes tick down (fade): total life 164.8 → 278.6s" — the clicked shell (launched in [2]) bursts during this 0.5s run, adding ~112 particles with fresh lives, so total life increased. Test bug: compare per-burst particle lives, or count only particles of bid. Fix: sum life of particles with burst===bid.

Wait, when did the clicked shell burst? Demo burst at ~1.23s+0.55 ≈ t=1.79. Clicked shell launched at t≈0.56, T for (400,250) from bottom: dist ≈ hypot(~100ish, 574) ≈ 580; T = 0.75+1.25*580/1442 ≈ 1.25 → bursts at t≈1.81. So yes overlapping burst during [4]. That's expected overlap (good!). Fix metric: filter bid.

3. "overlapping bursts coexist (3 shells, 93 sparks)" — threshold >100 total: 3 shells + 93 = 96 < 100. Also the 3 shells launched at t≈end of [5]; after run(1.0) some shells still in flight (T up to 2.1s) and particles from... wait, at that point all prior particles expired ([5] ran 6s). So 3 shells ascending with sparks only — no burst yet since T~1.2-1.7 > 1.0. So "overlapping bursts" wasn't actually tested! Fix: run longer (until bursts happen) e.g. run(2.0) then check shells + particles > 100 and that particles belong to ≥2 distinct burst ids.

Let me improve [6]: launch 3, run 2.2s so all burst, then check distinct burst ids among particles >= 2, and count > 100.

Also note [4] "drawn each frame 286 primitives >= particles*0.8" passed.

Let me fix these three test metrics.

Wait: [7] Clear test follows [6]; after run(2.3), particles present. Good.

Also unused `until` and `startY` vars remain — harmless (startY still used in minY init). `until` unused now — fine.

Run again.

All 40 checks pass. Now let's look at the rendered PNG snapshots to visually verify the launch-to-burst sequence looks right.

The ascent frame looks great: bright shell with trail rising diagonally from bottom. The burst frame shows a radial starburst with flash core, shockwave rings, and the ascending trail below, plus the second shell starting. 

Issue visible in shot2: there are MANY concentric rings (I only add ONE ring particle per burst). Why multiple rings? Because... hmm. Look: ~10 concentric rings. Each burst creates 1 ring. At snapshot time there were... demo burst (1 ring) + maybe shell sparks? No. Actually maybe the ring persists over frames and my framebuffer accumulates trails (fade 0.8 per frame) — so the ring from previous frames留下 ghosts! Each frame the ring radius grows slightly; older rings persist faintly in the accumulated buffer → concentric rings effect. That's actually what happens in the real browser too! The real canvas does the same accumulation (fade 0.20 per frame). So the real visual would show a "ripple" trail of the expanding ring — that could actually look cool (like a shockwave with trail), but 10 rings might look busy... In reality the fade is 0.20/frame → older rings fade by 0.8^n: after 10 frames 0.107 — visible but faint. The snapshot shows them fairly dim (dark green). It's plausibly attractive in motion — a shockwave ripple.

Hmm, but wait — is it really accumulation? Ring life 0.45s = 27 frames; radius grows ease-out so early frames change fast. The image shows ~12 rings with increasing spacing — consistent with ease-out radius growth + accumulation. In a real browser this will look like an expanding ripple that fades — looks fine, maybe even nice.

But actually the ring might be too prominent/large: size scale*0.17 = 136px, lineWidth 3.4. Multiple ripples could look like a "water ripple" effect. It's a stylistic choice; acceptable.

Let me also check shot3 (fall) and shot4 (cleared).

Shot3 shows particles falling with downward-drifting dotted trails — gravity visible, fading (dimmer than burst). Note: no stars visible in snapshots — my star parsing regex may have failed, or boxShadow not built? buildStars ran at resize → starsEl.style.boxShadow set. The regex: shadows are like `123px 45px 1.50px 0.80px rgba(255,255,255,0.50)` — my regex `^(-?\d+)px (-?\d+)px ([\d.]+)px ([\d.]+)px rgba?\(([^)]+)\)$` should match. Hmm but no stars visible in shots — maybe they're there but very dim (alpha 0.25-0.85, radius 0.5-1.6px, additive over bg ~ near-black top → should be faintly visible). Looking at shot1/shot3, top area is quite dark; maybe a few faint dots exist but not noticeable at this scale. Not important — but let me verify stars got set. Quick check: does elements.stars.style.boxShadow have content? It's set in buildStars. My snapshot parsing might fail on space format... Let me quickly debug in node: run a snippet. Actually the regex requires exactly that order and my generated string is `x + 'px ' + y + 'px ' + r + 'px ' + blur + 'px ' + tint` = "123px 45px 1.50px 1.30px rgba(255,255,255,0.50)". Matches. So stars likely rendered but faint (radius small, additive contribution tiny — e.g. alpha 0.5 * (1-d/r) over ~3px → adds maybe 100 to red at center... visible as a dot). Hmm, in shot3 I don't see obvious stars. Whatever — minor cosmetic; stars are drawn by CSS in the real browser anyway (my snapshot approximates).

Wait, actually there might be an issue: stars are barely visible because in real browser box-shadow with 0-ish blur on a 1px element — that works (common trick). Fine.

Shot3: burst looks good — particles spreading/falling with trails, dimmer (fading). Note the upper part is quite dark — that's because the burst has been falling and trails faded. Looks right.

Shot4: completely empty scene with just sky gradient — Clear verified visually. 

One thing about shot3: the overall image is quite dark — alpha fade is working (particles dimmer than shot2).

Remaining concerns:
1. The shockwave ring ripples (multiple concentric rings) — that's accumulated trail of a single expanding ring; acceptable, looks like a shock ripple. In shot2 it looks a bit like target rings, slightly artificial. Could reduce by increasing ring fade or decreasing ring lifetime/width. I think it looks fine and intentional-ish, but 12 rings is busy. In real browser, the fade is 0.20/frame so rings persist ~10 frames visibly. I could make the ring softer: reduce alpha (0.55 → 0.4) and make it expand faster (shorter life 0.35). Minor tweak — let's do it for aesthetics? It's fine either way. I'll slightly tune: ring life 0.35, alpha a*0.45.

Actually careful — changing life for ring doesn't affect tests (ring excluded from burst spread checks; lifetime cleanup fine).

2. UI not verified visually (buttons, panels) since no browser. The harness confirms handlers attached. CSS layout untested — mention in report.

3. One more potential real-browser issue: `performance.now()` in updateStats — fine.

4. `window.setTimeout` used for orientationchange — fine.

5. Backdrop-filter unsupported in some browsers — degrades gracefully.

6. Potential issue: pointerdown on canvas — clicking also triggers on UI? UI container has pointer-events:none, panel has auto → panel absorbs clicks, canvas doesn't get them (they're separate DOM elements, not children of canvas). Good.

7. Resize while particles exist: particles positions unchanged, fine.

8. devicePixelRatio capped at 2.

Let me make the small ring aesthetic tweak, then rerun tests to confirm nothing broke.

Actually, also consider: should stars be visible? Let me quickly verify star boxShadow generation works by checking in harness output. Quick node check appended? Let me just add a quick inline node -e run that loads script and prints elements... I don't export elements. Skip — but I can check via vm quickly with a tiny script. It's cheap: run harness portion? Simpler: after tests, print elements.stars.style.boxShadow length. Let me add a check to the test: `check((elements.stars.style.boxShadow||'').split(',').length > 40, 'star field generated')`. Good idea — it validates buildStars ran.

Let me apply: ring tweak in index.html + star check in test, rerun.

Run the final test to confirm everything passes, then finish.

All 41 checks pass, syntax OK, file saved. Finalize with a report. index.html is present in cwd (17.5KB, self-contained, no external resources).