Fireworks · laguna-s-2.1

Let me analyze the task:

1. Build an interactive fireworks display on a full-screen canvas
2. Write it to index.html in current directory
3. Inline CSS and JS
4. No external resources
5. Required behavior:
   - Clicking the sky launches a visible shell upward from bottom toward clicked location
   - Shell explodes into radial burst of colored particles
   - Burst particles fall under gravity, fade over time, removed after lifetime
   - Support overlapping shells and bursts
   - Launch one demonstration shell automatically on load
   - Provide Clear button to remove active shells, particles, trails
   - Controls usable after resizing
   - Procedural drawing only
   - Launch-to-burst sequence visible

Let me build this. I'll create a complete index.html file with the fireworks simulation.

Let me think about the implementation:

- Canvas that fills the screen
- Fireworks logic:
  - Shell object: has position, velocity, target, exploded flag
  - On update: shell moves toward target (with some arc/gravity effect), when it reaches target it explodes
  - Explosion: creates particles moving radially
  - Particles: have position, velocity, gravity, lifetime, color
  - Trails: draw line segments or fade trail behind shell

- Demo shell on load
- Click handler to launch shells
- Clear button

Let me write this carefully.

I'll structure the code:
1. HTML structure
2. CSS for full screen, canvas, controls
3. JS for the physics and rendering

Let me write the full file.

For the shell ascent, I'll make the shell travel upward toward the clicked location (which is above the bottom of the screen). The shell starts at the bottom center (or bottom near where it's clicked?).

Actually, re-reading: "launches a visible shell upward from the bottom of the scene toward the clicked location". So shell launches from the bottom of the scene toward the clicked point. The clicked point is somewhere in the sky.

Let me make the launch point at the bottom of the canvas (y = canvas height), with x being somewhere. Maybe x follows the click too, or maybe just launches from bottom center. The task says "from the bottom of the scene toward the clicked location". So target is the clicked location, launch is from bottom.

I think launch point x could be the click x, launched from bottom. That seems natural - click determines where it goes, launched from bottom.

Let me make launch point = (clickX, canvasHeight).

For trails: I'll draw a fading trail. One approach is to use a semi-transparent overlay that fades the canvas each frame (motion blur trail style). But if I do that, particles fade naturally too. Let me think.

Actually a common approach: each frame, draw a semi-transparent black rectangle over the whole canvas to create fade trails. This means everything fades over time. But Clear should reset.

Let me use that approach - it gives nice fading trails.

Let me code it up.

```js
const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');

let shells = [];
let particles = [];

function resize() {
  canvas.width = window.innerWidth;
  canvas.height = window.innerHeight;
}

window.addEventListener('resize', resize);
resize();

let trailAlpha = 0.15;

function launchShell(x, y) {
  const start = { x: x, y: canvas.height };
  // velocity toward target with some upward boost
  const target = { x, y };
  const dx = target.x - start.x;
  const dy = target.y - start.y;
  const dist = Math.hypot(dx, dy);
  const speed = Math.min(Math.max(dist * 0.02, 200), 600);
  const vx = (dx / dist) * speed;
  const vy = (dy / dist) * speed;
  shells.push({
    x: start.x,
    y: start.y,
    vx,
    vy,
    targetX: target.x,
    targetY: target.y,
    exploded: false,
    hue: Math.floor(Math.random() * 360)
  });
}

let lastTime = 0;
let dt = 0.016;

function update(time) {
  if (!lastTime) lastTime = time;
  dt = (time - lastTime) / 1000;
  dt = Math.min(dt, 0.05);
  lastTime = time;
  
  // update shells
  for (let i = shells.length - 1; i >= 0; i--) {
    const s = shells[i];
    if (!s.exploded) {
      s.vy += 900 * dt; // gravity
      s.x += s.vx * dt;
      s.y += s.vy * dt;
      // check if reached target (above)
      if (s.y <= s.targetY) {
        explode(s);
        shells.splice(i, 1);
      }
    }
  }
  
  // update particles
  for (let i = particles.length - 1; i >= 0; i--) {
    const p = particles[i];
    p.vx += p.ax * dt;
    p.vy += 900 * dt;
    p.x += p.vx * dt;
    p.y += p.vy * dt;
    p.life -= p.decay * dt;
    if (p.life <= 0) {
      particles.splice(i, 1);
    }
  }
}

function explode(s) {
  const count = 40 + Math.floor(Math.random() * 30);
  for (let i = 0; i < count; i++) {
    const angle = (i / count) * Math.PI * 2;
    const speed = 100 + Math.random() * 200;
    particles.push({
      x: s.x,
      y: s.y,
      vx: Math.cos(angle) * speed,
      vy: Math.sin(angle) * speed,
      ax: 0,
      life: 1,
      decay: 0.5 + Math.random() * 0.5,
      hue: s.hue + (Math.random() - 0.5) * 30,
      size: 3 + Math.random() * 3
    });
  }
}

function draw() {
  // fade trail
  ctx.fillStyle = `rgba(0,0,0,${trailAlpha})`;
  ctx.fillRect(0, 0, canvas.width, canvas.height);
  
  // draw shells
  for (const s of shells) {
    ctx.beginPath();
    ctx.arc(s.x, s.y, 4, 0, Math.PI * 2);
    ctx.fillStyle = `hsl(${s.hue}, 80%, 60%)`;
    ctx.fill();
  }
  
  // draw particles
  ctx.lineCap = 'round';
  for (const p of particles) {
    ctx.beginPath();
    ctx.arc(p.x, p.y, p.size * p.life, 0, Math.PI * 2);
    ctx.fillStyle = `hsla(${p.hue}, 80%, 60%, ${p.life})`;
    ctx.fill();
  }
}

function loop(time) {
  update(time);
  draw();
  requestAnimationFrame(loop);
}

canvas.addEventListener('click', (e) => {
  const rect = canvas.getBoundingClientRect();
  const x = e.clientX - rect.left;
  const y = e.clientY - rect.top;
  // only launch if click target is above a threshold (in the sky)
  if (y < canvas.height - 50) {
    launchShell(x, y);
  }
});

document.getElementById('clear').addEventListener('click', () => {
  shells = [];
  particles = [];
});

// demo
setTimeout(() => launchShell(canvas.width / 2, canvas.height * 0.3), 500);

requestAnimationFrame(loop);
```

Wait, there's an issue with the shell ascent logic. With gravity vy becomes positive downward quickly, so the shell might not reach the target if target is high. Let me reconsider.

The shell needs to travel upward toward the clicked target. If target Y is above the bottom, that means target Y < canvas height (since y decreases going up). So s.y starts at canvas.height (bottom) and targetY < canvas.height.

I set vy initially to a value that propels upward (negative). Then gravity pulls it down. The shell should reach target before gravity reverses it. With speed computed based on distance, it should be fine.

But the condition `s.y <= s.targetY` - if targetY is small (high up), shell travels far up. If target is near bottom, shell barely goes up. Let me make sure the initial vy is negative (upward) when target is above.

dy = target.y - start.y = targetY - canvas.height, which is negative (since targetY < canvasHeight). So vy is negative, good, shell moves up.

With speed high enough, it'll reach. Let me increase speed a bit. Actually, gravity 900 might be too strong relative to speed. Let me think: if speed is 600 px/s upward, gravity 900 px/s² means it decelerates and reaches max height at t = 600/900 ≈ 0.67s, height gained = 600*0.67 - 0.5*900*0.67² = 400 - 202 = ~200px. So if target is 500px up, it won't reach.

I need the speed to be sufficient. Let me compute speed more generously, or reduce gravity during ascent, or add propulsion.

Better approach: make the shell always reach its target by computing required velocity. Actually, let me use a homing approach where the shell accelerates toward target, or just set velocity high enough.

Alternative: Use projectile motion. To reach target at height h above launch with gravity g, launch speed v at angle... but here direction is toward target.

Let me just boost the speed. Compute speed = distance / desiredTime. If desiredTime = 1.5s and gravity... actually let me just make the shell's velocity large enough to always reach the target even against gravity.

Required: initial upward velocity v0, gravity g, target at height deltaH = canvasHeight - targetY (positive, height to climb).
We need the shell to reach height deltaH with v0. Using vy_final² = v0² - 2*g*deltaH. If we want it to reach with some velocity remaining, v0² >= 2*g*deltaH.

But the shell also has horizontal velocity. Let me decompose: the total speed should be enough.

Let me set v0 = sqrt(2 * g * deltaH) + extra, where deltaH = canvasHeight - targetY, and apply it in the direction toward target. Actually that's not quite projectile motion but close enough for a visual effect.

Simpler: let me just make gravity a smaller value and speed larger so it visually reaches. Or, better, make the shell "guided" - accelerate toward target each frame. That guarantees reaching.

Let me use guided homing with a max speed:

```js
const dx = target.x - s.x;
const dy = target.y - s.y;
const dist = Math.hypot(dx, dy);
const speed = Math.min(800, dist * 1.5 + 200);
// but this won't account for gravity pulling down
```

Hmm. Let me combine: apply a thrust/acceleration toward target plus gravity.

```js
s.ax = (dx/dist) * thrust;
s.ay = (dy/dist) * thrust - gravity;
s.vx += s.ax * dt;
s.vy += s.ay * dt;
s.x += s.vx * dt;
s.y += s.vy * dt;
```

With thrust large enough, shell accelerates toward target and reaches it. Let me use thrust = 600, gravity = 300. The shell accelerates upward toward target.

Actually, to make ascent look natural (accelerating, slowing as it approaches), homing works well. And it handles all cases. Let me also cap velocity.

Let me also check: condition to explode - dist to target < some threshold (like 10-20px) OR s.y <= targetY and moving. With homing, dist threshold is cleanest.

Let me also limit: don't explode until the shell has gotten close enough to target. Use threshold of ~15px.

Let me refine. I'll write the full file now.

For trails: I want a nice trail behind the ascending shell. The fade approach (semi-transparent black fill) gives a ghostly trail for the shell and particles. That works and is simple. But maybe I want a brighter trail for the shell.

I could draw a line from previous position to current position for the shell (a bright streak). Let me keep both: the fade overlay for general fading, plus a line trail for the shell. Actually the fade overlay alone might make the shell trail dim. Let me add a line connecting previous shell positions for a proper rocket trail.

Hmm, but each shell is separate. I can draw a line from last frame's position to current. Let me store lastX/lastY on the shell.

Actually, let me keep it simpler and use the fade overlay approach which naturally creates trails for both shell and particles. For a brighter shell trail, I'll also draw a line. Let me do both.

Actually, let me reconsider the whole rendering. Let me use:
- A persistent canvas that gets faded each frame (semi-transparent black rect) - this creates motion trails/fade for particles.
- Draw shell as a bright point + connecting line for streak.

Let me just go with the fade overlay and bright particles. The shell streak emerges from the fading. Good enough and clean.

But wait - if I fade everything with black overlay, the background becomes gray-ish over time when there's lots of activity. That's a common firework look though, and Clear resets it. Actually the fade is toward black, so it stays dark. Good.

Let me write the final version. Let me make it nice with good colors.

Let me also add a subtle night sky gradient background that gets cleared on Clear. Actually with the fade overlay, if I draw background each frame after fade, the background gets redrawn. Let me draw background at full opacity on Clear, then fade overlay on subsequent frames (which darkens but keeps a gradient base). Hmm, the fade overlay is semi-transparent black over whatever's there. If I draw a starry gradient once and then only fade, stars would fade away. 

Let me just draw the night background (gradient + stars) every frame before fading, OR draw it every frame fully and use the fade only for particles. 

Cleanest: 
1. Each frame: draw night background (gradient + stars) fully opaque.
2. Then fade overlay? No - if background is redrawn opaque, there's no fade.

Let me reconsider. Two canvas layers? That complicates things but is clean:
- Background canvas: gradient + stars, drawn once (and on resize/clear).
- Foreground canvas: fireworks, with fade overlay.

Let me use two canvases stacked. Background is static, foreground has the fade trail effect. Clear clears foreground only (or both?). The task says Clear removes shells, particles, trails - so clear foreground. Background can stay (nice constant starfield) or also clear. I'll keep background constant, clear foreground.

Actually, let me keep it simpler with one canvas but manage it:
- Keep a list of stars (static positions) and draw them each frame as background.
- Draw night gradient each frame.
- Then draw fade overlay (semi-transparent black) - but this would darken background too.

The fade overlay darkens everything including background. To keep background constant, draw background fully opaque each frame BEFORE adding fireworks, but then fireworks don't fade between frames (they'd persist fully until cleared). That breaks the particle fade.

Two canvases is the clean solution. Let me do that.

Foreground canvas: 
- Each frame: fill with semi-transparent black (fade), then draw shells and particles.
- This creates trails and particle fading.

Background canvas:
- Night gradient + stars, drawn once on init/resize/clear.

Let me write it.

Actually, I realize for simplicity and since the grader uses browser tool to inspect, let me just use ONE canvas and redraw the background (gradient + stars) every frame at full opacity, then fade overlay ONLY affects... no.

OK two canvases, it's not much more code. Let me do it.

Let me write the complete file.

```html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Fireworks</title>
<style>
html,body{margin:0;padding:0;height:100%;overflow:hidden;background:#000}
#bgCanvas,#fwCanvas{position:fixed;top:0;left:0;width:100%;height:100%;pointer-events:none}
#fwCanvas{pointer-events:auto;cursor:crosshair}
.controls{position:fixed;top:10px;left:10px;z-index:10}
button{background:#222;color:#fff;border:1px solid #555;padding:8px 14px;border-radius:4px;font-size:14px;cursor:pointer}
button:hover{background:#333}
</style>
</head>
<body>
<canvas id="bgCanvas"></canvas>
<canvas id="fwCanvas"></canvas>
<div class="controls"><button id="clear">Clear</button></div>
<script>
const bgCanvas=document.getElementById('bgCanvas');
const fwCanvas=document.getElementById('fwCanvas');
const ctx=fwCanvas.getContext('2d');
const bctx=bgCanvas.getContext('2d');
let W=fwCanvas.width, H=fwCanvas.height;

function resize(){
  W=innerWidth;H=innerHeight;
  fwCanvas.width=W;fwCanvas.height=H;
  bgCanvas.width=W;bgCanvas.height=H;
  drawBackground();
}
window.addEventListener('resize',resize);
resize();

const stars=[];
function drawBackground(){
  bctx.clearRect(0,0,W,H);
  const g=bctx.createLinearGradient(0,0,0,H);
  g.addColorStop(0,'#0b0c2a');
  g.addColorStop(1,'#020310');
  bctx.fillStyle=g;
  bctx.fillRect(0,0,W,H);
  // stars
  bctx.fillStyle='#fff';
  for(const s of stars){
    bctx.globalAlpha=s.a;
    bctx.fillRect(s.x,s.y,s.r,s.r);
  }
  bctx.globalAlpha=1;
}
// init stars
for(let i=0;i<120;i++){
  stars.push({x:Math.random()*W,y:Math.random()*H,r:Math.random()*1.5+0.3,a:Math.random()*0.6+0.2});
}

let shells=[];
let particles=[];
let trailParticles=[]; // for rocket trail puffs

const GRAVITY=900;
const THRUST=1200;

function launchShell(x,y){
  const startx=x;
  const starty=H;
  const dx=x-startx; // 0
  const dy=y-starty;
  const dist=Math.hypot(dx,dy);
  const hue=Math.floor(Math.random()*360);
  shells.push({
    x:startx,y:starty,
    vx:0,vy:0,
    targetX:x,targetY:y,
    thrust:THRUST,
    hue:hue,
    lastX:startx,lastY:starty,
    trailTimer:0
  });
}

let lastTime=0;
function update(dt){
  // update shells
  for(let i=shells.length-1;i>=0;i--){
    const s=shells[i];
    const dx=s.targetX-s.x;
    const dy=s.targetY-s.y;
    const dist=Math.hypot(dx,dy);
    if(dist<15 || s.y<=s.targetY-5){
      explode(s);
      shells.splice(i,1);
      continue;
    }
    // homing acceleration
    const ux=dx/dist;
    const uy=dy/dist;
    s.vx+=ux*s.thrust*dt;
    s.vy+=uy*s.thrust*dt-GRAVITY*dt;
    // cap speed
    const sp=Math.hypot(s.vx,s.vy);
    if(sp>800){s.vx=s.vx/sp*800;s.vy=s.vy/sp*800;}
    s.lastX=s.x; s.lastY=s.y;
    s.x+=s.vx*dt;
    s.y+=s.vy*dt;
  }
  // add trail puffs
  for(const s of shells){
    s.trailTimer-=dt;
    if(s.trailTimer<=0){
      s.trailTimer=0.04+Math.random()*0.04;
      trailParticles.push({
        x:s.x+ (Math.random()-0.5)*4,
        y:s.y+ (Math.random()-0.5)*4,
        vx:(Math.random()-0.5)*20,
        vy:Math.abs(s.vy)*0.3+20+Math.random()*20,
        life:0.4+Math.random()*0.3,
        maxLife:0.7,
        hue:s.hue
      });
    }
  }
  // update trail particles
  for(let i=trailParticles.length-1;i>=0;i--){
    const p=trailParticles[i];
    p.vy+=GRAVITY*0.3*dt;
    p.x+=p.vx*dt;
    p.y+=p.vy*dt;
    p.life-=dt;
    if(p.life<=0) trailParticles.splice(i,1);
  }
  // update particles
  for(let i=particles.length-1;i>=0;i--){
    const p=particles[i];
    p.vx+=p.ax*dt;
    p.vy+=GRAVITY*dt;
    p.x+=p.vx*dt;
    p.y+=p.vy*dt;
    p.life-=p.decay*dt;
    if(p.life<=0) particles.splice(i,1);
  }
}

function explode(s){
  const count=30+Math.floor(Math.random()*20);
  const hue=s.hue;
  for(let i=0;i<count;i++){
    const angle=(i/count)*Math.PI*2 + (Math.random()-0.5)*0.3;
    const speed=150+Math.random()*250;
    const spread=0.15+Math.random()*0.1;
    particles.push({
      x:s.x,y:s.y,
      vx:Math.cos(angle)*speed,
      vy:Math.sin(angle)*speed,
      ax:0,
      life:1,
      decay:0.8+Math.random()*0.6,
      hue:hue,
      size:2+Math.random()*3
    });
  }
}

function draw(){
  // fade
  ctx.fillStyle=`rgba(0,0,0,0.18)`;
  ctx.fillRect(0,0,W,H);
  
  // trail particles
  for(const p of trailParticles){
    ctx.beginPath();
    ctx.arc(p.x,p.y,p.size*p.life,0,Math.PI*2);
    ctx.fillStyle=`hsla(${p.hue},90%,70%,${p.life})`;
    ctx.fill();
  }
  
  // shells
  for(const s of shells){
    ctx.beginPath();
    ctx.moveTo(s.lastX,s.lastY);
    ctx.lineTo(s.x,s.y);
    ctx.strokeStyle=`hsla(${s.hue},90%,70%,0.8)`;
    ctx.lineWidth=3;
    ctx.stroke();
    ctx.beginPath();
    ctx.arc(s.x,s.y,5,0,Math.PI*2);
    ctx.fillStyle='#fff';
    ctx.fill();
  }
  
  // particles
  ctx.lineCap='round';
  for(const p of particles){
    ctx.beginPath();
    ctx.arc(p.x,p.y,p.size*p.life,0,Math.PI*2);
    ctx.fillStyle=`hsla(${p.hue},90%,60%,${p.life})`;
    ctx.fill();
  }
}

let then=0;
function loop(time){
  const dt=Math.min((time-then)/1000,0.04);
  then=time;
  update(dt);
  draw();
  requestAnimationFrame(loop);
}
requestAnimationFrame(loop);

setTimeout(()=>launchShell(W*0.5, H*0.35),600);

fwCanvas.addEventListener('click',(e)=>{
  const rect=fwCanvas.getBoundingClientRect();
  const x=e.clientX-rect.left;
  const y=e.clientY-rect.top;
  if(y<H-60) launchShell(x,y);
});

document.getElementById('clear').addEventListener('click',()=>{
  shells=[];particles=[];trailParticles=[];
  // clear foreground canvas fully
  ctx.clearRect(0,0,W,H);
});

// keep controls above, fixed
</script>
</body>
</html>
```

Wait, there's an issue with the shell ascent condition. `s.y<=s.targetY-5` - this checks if shell passed the target vertically. But with homing, the shell approaches target directly, so `dist<15` should trigger. Good. But the shell might pass the target if it overshoots due to velocity. With homing acceleration, as it approaches, ux,uy still point toward target but it keeps momentum. The dist<15 check handles it. But if it overshoots before dist<15 (fast speed), it might pass through. Let me add: if the shell was approaching and passed target, explode. 

Actually with thrust and speed cap at 800, and target distance large, by the time it's near target it's moving fast (up to 800px/s). dist<15 means within 15px - it'll trigger as it passes near. Should be fine. But to be safe, let me check if dist is increasing from last frame and > some value, meaning it overshot - then explode. Let me track closest approach.

Simpler robust approach: track if shell has crossed the target line going upward. Since it launches from bottom going up, target is above. Condition: if s.y <= s.targetY. This means shell reached the target's vertical level. That's reliable for "reached target height". But if target is low (y near bottom, like y=H-100), shell barely rises - that's fine, it explodes low.

Actually if user clicks very low (just under the threshold H-60), the shell rises a tiny bit and explodes. That's acceptable.

But what about dist - if click is near the bottom, dist is small, shell explodes quickly. Fine.

Let me use: `if (s.y <= s.targetY || dist < 20)`. Actually let me reconsider - targetY is click y which is above H (since y<H-60 and H is bottom). starty=H. So targetY < H, meaning shell must rise. s.y starts at H and decreases toward targetY. Condition s.y <= targetY means reached. Good. But also handle overshoot where shell might go past if velocity carries it - s.y could go below targetY. The condition `<=` catches reaching or passing. Good.

Hmm, but actually there's subtlety: with gravity, vy might not go negative enough if target is very high and thrust limited. Let me make thrust high (1200) and gravity 900. Net upward accel when pointing up = 1200-900 = 300 initially, but velocity builds up capped at 800. Time to reach 800 with 300 accel = 2.67s, but gravity reduces effective... 

Actually the homing always points toward target (upward), so net acceleration along trajectory = thrust - gravity component. Since target is straight up (dx small, dy negative), uy ≈ -1, so ay = -thrust - gravity... wait:

s.vy += uy*s.thrust*dt - GRAVITY*dt
uy is negative (target above), so uy*thrust is negative (upward), minus gravity (positive, downward). So vy = negative + negative... both make vy more negative (upward). Good, shell accelerates upward strongly.

Wait: uy = dy/dist where dy = targetY - s.y. targetY < s.y (above), so dy negative, uy negative. uy*thrust*dt = negative contribution to vy (upward). Then -GRAVITY*dt is also negative contribution (since we subtract gravity, gravity adds positive to vy/downward... let me be careful).

vy += uy*thrust*dt  (negative, upward)
vy -= GRAVITY*dt    → vy += -GRAVITY*dt  (negative? no)

Wait, s.vy += uy*s.thrust*dt - GRAVITY*dt. The term -GRAVITY*dt is negative (since GRAVITY=900 positive, dt positive). So vy += negative, meaning vy decreases (more negative, upward). 

Hmm that's wrong! Gravity should pull downward (positive vy, since y increases down), i.e., vy should INCREASE (toward positive). 

Let me fix: gravity should add positive to vy (downward). So:
s.vy += uy*s.thrust*dt + GRAVITY*dt   ... but uy is negative (upward thrust). 

Wait, thrust direction: we want thrust to push the shell toward target, which is upward, so thrust contributes negative to vy. Gravity pulls downward, positive to vy.

Correct:
s.vx += ux * s.thrust * dt;
s.vy += uy * s.thrust * dt + GRAVITY * dt;

Since uy < 0 (upward), uy*thrust is negative (upward push). GRAVITY*dt is positive (downward). These compete. Net: thrust upward vs gravity downward. 

But in my explosion particles, I wrote `p.vy += GRAVITY*dt` and initially vy = Math.sin(angle)*speed where for upward particles sin is negative. That's correct - gravity pulls them down.

So in my shell code, I had `s.vy += uy*s.thrust*dt - GRAVITY*dt` which is WRONG (gravity direction flipped). Let me fix to `+ GRAVITY*dt`.

Hmm wait, but then upward thrust (negative vy) vs gravity (positive vy). If thrust > gravity along vertical, shell goes up. With thrust=1200 and gravity=900, net ≈ 300 upward along vertical minus... actually the shell is pointed at target which is nearly straight up, so ux≈0, uy≈-1. vy += -1200*dt + 900*dt = -300*dt. So vy stays negative (upward), shell rises, accelerating. Good. As it approaches target, it might still be rising fast and overshoot - the dist<20 / y<=targetY check handles explosion.

But with speed cap 800, it won't be too crazy. Good.

Let me fix that gravity sign bug. Also in the trail particles I had `p.vy+=GRAVITY*0.3*dt` - correct.

Let me also reconsider: with the homing approach, the rocket trails and bright head look good. 

Now, another consideration: the explosion particles use `p.ax=0` and `p.vy += GRAVITY*dt`. Initial vy = sin(angle)*speed. For downward angles sin positive (falls), for upward sin negative (goes up then falls). Gravity makes them fall. Good. They spread radially and arc downward. 

Let me also add some outward acceleration variation and maybe a secondary effect. Keep it clean.

Let me also double check the trail: trail particles spawned with vy positive (downward, since Math.abs(s.vy)*0.3+20+...). Wait they should emit backward/downward from the rocket (rocket goes up, trail goes down behind it). s.vy is negative (upward), Math.abs(s.vy) positive, so p.vy is positive (downward). Good, trail puffs drift downward and fall. 

Now let me also make sure particles fade visibly. decay 0.8-1.4, life starts 1. With dt~0.016, life drops ~0.02 per frame, lasting ~0.7-1.25s. Good.

The size: p.size*p.life shrinks over time. Nice.

Let me also ensure the demo shell launches. setTimeout 600ms. Good. Actually requestAnimationFrame may not have started loop with proper `then`. First frame time=performance.now() large, dt = (time-0)/1000 huge, capped at 0.04. Fine.

Let me also handle the `then` initial: then=0, first frame dt = (time-0)/1000 = large, capped 0.04. OK.

One more: clearing. ctx.clearRect clears foreground. But background stars remain (static). Good - Clear removes shells/particles/trails. The task says "Clear to remove active shells, particles, and trails" - trails are the fading overlay, cleared by clearRect. Good. Background staying is fine (it's just the night sky).

Hmm, but maybe user expects black background after Clear. With static stars it still looks like night. Fine. Actually let me make Clear also redraw background? No, stars are fine. The clearRect removes the fade trails. Good.

Let me also make the crosshair cursor and allow click anywhere above bottom region. Good.

Let me also reconsider: should clicking near bottom still launch? I set `if(y<H-60)`. Clicking in the bottom 60px doesn't launch. Reasonable to avoid too-low explosions. Actually, let me allow clicking most of the sky. Keep threshold but smaller, like H-30. Or launch from bottom toward click regardless. Let me keep y < H-60.

Wait, actually re-reading: "Clicking the sky launches a visible shell upward from the bottom of the scene toward the clicked location." So the launch is always from the bottom. The clicked location is the target. So even clicking lower should launch to that point. But clicking right at the bottom would make a tiny launch. Let me allow any click but clamp target y to be at most H-50 (so shell always rises at least a bit). Actually let me just allow clicks in the upper portion. Keep H-60 threshold.

Let me finalize and write the file. Let me also add a subtle label or keep minimal. I'll keep minimal.

Let me write it out properly now and test in browser.

Let me refine the code once more and write the file.

Actually, let me reduce gravity a touch or increase thrust so shells clearly reach high targets. thrust=1400, gravity=900. Net upward when aimed up = 500. Should easily reach. Fine. Let me keep thrust 1400.

Also for very high targets (near top), the shell needs to travel ~H distance. With acceleration it'll get there. Speed cap 800 means max time ~H/800 ≈ 0.75s for 600px. With acceleration from 0, takes longer but reaches. Fine.

Let me write final file.

Let me also add sparkles / muzzle flash at launch. Optional. I'll add a few puffs at start maybe. Keep trail only.

Let me write it.

I'll also make sure the line width for shell streak looks good and fades. Since the fade overlay applies, the streak fades too. Good.

Let me write the file now.

Now let me run it in the browser and inspect.

The iframe sandbox warning is just about the harness iframe, not my code. The DOM shows "Clear" (the button). Let me take a screenshot to see the visual output. The model doesn't support images though. Let me try a screenshot to see the fireworks.

Actually "images":"model does not support images" means I can't see screenshots. But the inspector shows the DOM has "Clear" button. Let me check console more - the only console message is the iframe warning, no errors from my code. Good, no JS errors.

Let me interact with the canvas to test clicking. Let me click somewhere in the sky and observe.

Let me try a motion capture or screenshot. Since images not supported, let me instead check console after interactions, and verify the dom state.

Actually, let me try clicking to trigger shells and see if there are errors.

Let me wait a bit and take a screenshot to see the visual state. But images not supported. Let me try motion capture which might give frames.

Actually let me try a screenshot - maybe the tool returns it even if model doesn't support images, the harness might still process. Let me just try motion.

Let me think about what I can verify without images. I can:
- Check console for errors after clicking
- Check DOM for the Clear button still present and usable
- Verify resize keeps controls usable

Let me test clicking Clear and re-check DOM, and test a resize scenario isn't easy. Let me verify the click target logic by reviewing code - click at (400,200) with H~800, y=200 < 760, launches shell toward (400,200). Good.

Let me also verify there are no errors and the scene animates. Let me wait and check console again, and maybe capture motion frames.

Let me try screenshot once to see if it works.

Images aren't supported. So I can't visually inspect. But no JS errors appear in console. Let me try a motion capture to see if anything renders.

Actually, the model not supporting images means the vision check is limited. But I can still verify behavior through code reasoning and the DOM inspection.

Let me verify a few things by reasoning about the code and maybe testing edge cases:

1. Click affects launch target - yes, launchShell uses click coordinates.
2. Particles spread and fade - yes, radial velocity, gravity, life decay.
3. Clear empties scene - yes, empties arrays and clears canvas.

Let me test the Clear button by clicking it, then verify DOM still has Clear and no errors. Let me also test clicking multiple times to ensure overlapping shells work without errors.

Let me click the Clear button (top-left around x=70, y=40) and also test more clicks.

Actually, let me verify the scene is animating by checking console after some time. Let me do a few clicks then check.

No errors. Now let me test the Clear button. It's in the controls div at top-left. The button text is "Clear". Let me click where it should be. The button padding is 9px 16px, font 14px, positioned at top:12px, left:12px. So it's around x=12 to ~120, y=12 to ~40. Let me click around (70, 30).

Actually, let me click directly on the button text. Let me click at x=70, y=32.

Clear clicked, no errors. The DOM still shows "Clear" button (usable after). 

Let me verify the resize behavior keeps controls usable. I can't directly resize the browser window with the tools easily, but resize event handling is in place and tested via code review. Let me think if there's a way to trigger a resize.

Actually, I can't resize the viewport with the given tools. But the resize handler is straightforward and re-establishes canvases and stars. The Clear button is position:fixed so it stays put. Controls remain usable.

Let me do a final review of potential bugs:

1. Shell ascent: thrust pushes toward target, gravity pulls down. For high targets (small y), dy is very negative, uy≈-1, vy accelerates upward strongly (thrust 1500 up vs gravity 950 down = net 550 up). Reaches target. Good.

2. But wait - there's a subtle issue. The condition to explode: `dist<14 || (s.y<=s.targetY && s.vy<=30)`. Consider a click near the bottom but above H-40, e.g., y=H-50. targetY = H-50. Shell starts at y=H, rises to H-50 (only 50px). With net upward accel, vy becomes negative quickly, reaches target. s.y<=targetY triggers explosion. Good. But the `s.vy<=30` condition: vy is negative (upward) when crossing, so s.vy<=30 is true (negative<30). Good, explodes. Also if shell somehow moving down fast when passing (shouldn't happen going up). Fine.

3. What if click is at very top (y=60)? targetY=60. Shell travels from H to 60, full height. thrust carries it. Good. With speed cap 900 and distance H≈800, it reaches. The homing keeps accelerating until dist<14. Could overshoot if velocity large near target - but dist<14 triggers at closest. Actually if moving fast (900) and only checks when within 14px, it might overshoot past in one frame (900*0.016=14.4px per frame > 14). So it could pass through without triggering dist<14! That's a bug - shell flies past target without exploding.

Let me fix: track if we're close enough, or detect crossing. Better: explode when s.y <= s.targetY (reached target height) OR dist is minimal. Since target is above, s.y decreasing. Once s.y <= targetY, explode. But if shell overshoots targetY going up... it can't go above target without y crossing targetY first. So checking s.y<=targetY catches it at the boundary. But if velocity is high, one frame s.y is above target, next frame below - the `<=` catches the frame where it's below. Good. But the shell continues moving up past target before update runs again - negligible (one frame). So let me make the primary condition `s.y <= s.targetY`.

But also need dist check for cases where horizontal target differs. Since launch x = click x and targetX = click x, dx=0 always, so it's purely vertical. So s.y<=targetY is sufficient and reliable. Let me simplify condition to: if dist < 20 OR s.y <= s.targetY. Actually just s.y <= s.targetY works since x matches. But to be safe against the overshoot-one-frame, combine. Let me use: explode when the shell reaches/passes target height. 

Let me change condition to:
```
if (s.y <= s.targetY || dist < 20) { explode; remove }
```
The dist<20 is a fallback. The main reliable one is s.y<=targetY. With one-frame overshoot the shell is ~14px past - fine visually, explodes immediately next check.

Actually wait, the explosion happens in the same update frame when condition met, so no extra frame delay. Good. Let me update the condition.

4. Particle gravity: vy += GRAVITY*dt, initial vy = sin(angle)*speed. Correct, particles arc down. Good.

5. Trails: emit downward, fade. Good.

6. Clear: empties arrays, clears canvas. The fade overlay is gone (canvas cleared). Good. Background (stars) remains - that's fine, it's the night sky.

Let me also reconsider: after clear, the demo shell - only one demo on load. Good.

Let me fix the explosion condition bug and also slightly reduce speed cap or increase detection to be safe. Let me update.

Also, I realize there might be an issue: with the fade overlay at 0.22 alpha, the ascending shell streak and particles fade. The shell itself is redrawn each frame as a line from lastX to x, so it's continuous. Good.

Let me make the edit to fix the explosion condition.

Now let me reload and verify it still works without errors, and do a final check of the demo shell and a click.

Everything works without errors. The only console message is the iframe sandbox warning which is harness-level (it appears even with empty iframe), not from my code.

Let me do a final review of the file to make sure everything is correct and complete.

The code looks good. Let me verify the file ends properly and confirm the demo shell and remaining handlers.