Aquarium breach · deepseek-v4.1-flash

Let me build this. It's a fairly complex simulation. Let me plan carefully and write a single index.html.

Let me think about the design:

- Canvas 1200x800.
- Tank: rectangle glass panel, say x from 300 to 900, y from 150 to 650. Water inside with waterline at y=250 initially.
- User drags a visible crack vertically on one side (left or right) below waterline. Actually "drag a visible crack vertically on one side below the initial waterline" — so the user drags on a side wall to create a crack. The crack is a vertical segment on the side wall. Dragging defines its extent.
- Press Breach: panel breaks around selected opening.
- Water exits as gravity-curved jet, waterline falls. Outflow weakens as water level approaches opening top, stops when water no longer reaches it.
- Puddle spreads, constrained by floor and room walls.
- Objects: rocks (sink), toy (floats), plants (bend/drift), fish (swim against current then swept).
- Objects fitting opening can be carried out.
- Leaving water → gravity, collide floor.
- Glass fragments rotate, collide, resistance in water.

Let me implement a particle-based water for the jet/puddle, plus a tank water volume model.

Simpler: represent water as a set of particles for outflow and puddle; tank water as a rectangular volume with waterline. Plus maybe particles inside tank for current visualization. Hmm.

Let me do:
- Tank water: level (y). Volume = width * (bottom - level).
- Opening: vertical segment on side at x=wallX, yTop..yBottom.
- Flow rate proportional to submerged height of opening and sqrt-ish. Outflow = clamp based on how much of opening is below waterline.
- Spawn water particles at opening with horizontal velocity, gravity applied. They fall, hit floor, spread.
- Puddle: particle system with simple floor collision and wall constraint; or a separate puddle height field. Particles simpler and looks good. But "spreading puddle constrained by floor and room walls" — particles with friction spreading works.

To make puddle not vanish, particles settle. Use many particles, but cap. Actually the total water leaving tank can be represented by particles; could be thousands. Cap at maybe 4000 particles and when capped, still lower waterline but don't spawn (or spawn as puddle heightfield). Hmm, to keep consistent, maybe maintain a puddle as a height-field grid instead: array of columns across room width with water height. That's efficient and gives nice spread. Plus a few particles for splash/jet visuals.

Let me use a hybrid:
- Tank waterline level.
- Jet: rendered as a stream of small circles (particles) with gravity, spawned at the opening. When they hit the floor or puddle surface, they add volume to the puddle grid and disappear.
- Puddle: heightfield of columns (say 4px wide) across room floor. Each column has height h. Simulate flow between columns based on height difference (shallow water / cellular automata). Constrained by walls. This spreads nicely.

That's a good, consistent approach.

Also water inside tank: current. As water flows out, objects near opening get pushed. Fish swim against current. Current strength depends on flow rate and distance to opening.

Objects physics:
- Rocks: circles with high density, sink to tank bottom, rest. In current, can be pushed if small. If they fit opening and get near, they can be carried out.
- Toy: low density, floats at waterline, bobs, drifts with current, can exit.
- Plants: anchored at bottom, bend with current (drawn as bezier). 
- Fish: have AI: swim around; when current strong, they swim against it (apply force toward upstream), but strong flow can sweep them.
- Glass fragments: created on breach from panel around opening. Rectangles/triangles with rotation, collide with floor/walls, resistance in water.

Object leaving water: when outside tank (x beyond wall) and above puddle or in air, gravity applies, collide floor.

Let me define room coordinates: room floor y = 700. Room walls x=0 and x=1200. Tank sits on... Actually tank bottom at y=650, and room floor at 700? Then water falls from opening and lands on floor at 700. Tank is a table-top tank? Let's put tank bottom at y=680 and floor at y=720. Hmm, simpler: tank bottom on the floor. Room floor y = 680. Tank from x=300..900, y=140..680. Waterline initially y=240. Room walls at x=20 and x=1180.

Actually if tank bottom is on floor, escaping water lands on floor right next to tank. Fine.

Let me set:
- Room: floorY = 680, leftWall = 20, rightWall = 1180.
- Tank interior: x 320..880, bottom 660 (glass has thickness). Let's just make tank outer rect x=300..900, y=140..680, glass thickness 10. Interior x=310..890, y=150..670.
- Waterline initial = 250. Water fills interior from 250 to 670.

Opening on left wall (or right). User drags on either side wall. Let's allow both but detection based on which side. The crack is a vertical segment at x = wall interior.

Crack: user drags from a start point on/near a side wall below waterline to an end point. Constrain x to the wall, y between waterline+ and bottom. The crack length defines opening height. If drag too small, minimum size.

Breach: glass fragments spawn around opening. Opening becomes active. Water exits.

Let me now think about rendering:
- Background room with floor.
- Tank glass with highlights.
- Water in tank as translucent blue rect from level to bottom, with slight wave on surface.
- Puddle columns rendered as filled path.
- Jet particles.
- Objects.

Physics loop with fixed dt (1/60), maybe substeps.

Let me write code.

Key state:
```
const state = {
  breached: false,
  waterLevel: 250,
  crack: null, // {side:'left'|'right', y1, y2}
  objects: [],
  fragments: [],
  jetParticles: [],
  puddle: Float32Array(cols),
  ...
}
```

Puddle heightfield:
- columns of width CW=8, from leftWall to rightWall => ncols.
- h[i] in pixels of water height.
- flow: for each pair, transfer = k*(h[i]-h[i+1]); clamp.
- Also add volume from jet particles landing.
- Rendering: fill from floorY-h to floorY per column.

Water volume conservation between tank and puddle: when tank water level drops, volume released. Actually let's make jet spawn proportional to outflow rate, and puddle gets volume when particles land. Tank level drops based on outflow rate. That's consistent enough.

Outflow model:
- openingTop, openingBottom in world y.
- submerged = clamp(waterLevel.. opening) overlap: overlapTop = max(waterLevel, openingTop); overlapBottom = min(tankBottom, openingBottom). submergedHeight = max(0, overlapBottom - overlapTop).
- if submergedHeight <= 0: outflow = 0.
- flow rate Q = C * submergedHeight * sqrt(2*g*head) where head = depth below waterline at opening center = (overlapCenter - waterLevel). Simplify Q = C * submergedHeight * sqrt(max(0,head)+1).
- Actually as water approaches opening, head→0, Q→0 naturally. Good.
- Tank level falls: dV = Q*dt; area of tank = width; dLevel = dV/width.

Spawn jet particles: number = Q scaled. Each particle carries volume = dV/n. Particle velocity: horizontal vx = jetSpeed * side (outward), vy small random. jetSpeed ~ sqrt(2*g*head) scaled.

Let me just tune constants.

Objects:
Each object: {x,y,vx,vy, type, radius, mass, density, inWater, angle,...}

Buoyancy: for object in water, buoyant force = volume * waterDensity * g upward; weight = mass*g down. net = (buoyForce - weight). Rocks density > water → sink. Toy density < water → float. Fish density ~ water, they swim.

Drag: F = -k * v * (inWater? big : small). Add current force: current velocity at object position; force = k*(current - v).

Current field: inside tank, current flows toward opening. Magnitude proportional to Q and proximity. Direction: toward the opening. Also downward? Water flows toward opening then out. Let's compute for each object in tank water: vector from object to opening center, normalized, times currentStrength * (1 - dist/maxDist). Actually flow toward opening mostly horizontal near opening. Simplify: direction mostly horizontal toward opening side, with strength decreasing with distance. Also add slight downward.

Fish AI: fish target velocity based on wander; when current strong, add swim force opposite to current (upstream). If current force exceeds fish max force, fish gets swept.

Plants: anchored at bottom point, segments; bend angle depends on current. Draw as curved stalk with leaves.

Toy: floats, so its equilibrium is at waterline. Since buoyancy handles it, but to be stable we need damping. Also toy should stay at waterline even as level changes. Buoyancy proportional to submerged fraction. Compute submerged depth based on y and radius. Buoyant force = densityWater * submergedVolume * g. That gives float equilibrium. Good, but need enough damping. Alternatively special-case: apply spring to waterline for toy. Let's use proper buoyancy with submerged fraction, plus strong drag.

Rocks: high density, sink, rest on bottom with friction. Small rocks can be carried by current if current strong and rock near opening.

"Movable objects that fit the opening can be carried out by the flow." Need objects small enough (radius*2 < opening height) to pass. When object center crosses the wall plane at opening, if fits, it's out; else it collides with wall.

Let me handle wall collisions for objects: tank interior left/right walls. If object is at wall and not at opening (or doesn't fit), bounce. If at opening and fits, allow to pass. Once outside, it's in the room, gravity + floor collision + puddle.

Fragments: spawn from the glass around opening. Represent as small polygons with position, velocity, angular velocity, angle. In water: drag + buoyancy (glass sinks). Collide with floor, walls, tank bottom. Rotate.

Now the crack drag interaction:
- pointerdown near a side wall (within some distance of interior wall x) and below waterline and above bottom → start crack. Or allow drag anywhere and snap to nearest wall. Let's detect if pointer within e.g. 40px of left interior wall or right interior wall, y between waterLevel+5 and bottom-5.
- While dragging, set crack y1=start, y2=current clamped. Draw a jagged crack line.
- On pointerup, crack finalized. Show hint.
- Breach button enabled when crack exists.
- Reset restores initial state.

Breach:
- mark breached, spawn fragments around opening (from wall segment).
- The panel "breaks around the selected opening": visually remove glass near opening, leave jagged edges. We'll render the glass wall with a gap.

Let me write the glass wall rendering: The tank walls are drawn as lines/rects. For the breached side, draw the wall in two segments (above opening and below opening) plus jagged edges. Fragments fly.

Let me now write the code. I'll aim for clean but complete.

Let me think about canvas size 1200x800. Use fixed internal resolution and CSS scale to fit.

Let me write helper functions.

Global constants:
```
const W=1200,H=800;
const FLOOR=680;
const LEFT_WALL=20, RIGHT_WALL=1180;
const TANK={x:300,y:140,w:600,h:540}; // outer
const GLASS=10;
const interior left = TANK.x+GLASS=310, right=TANK.x+TANK.w-GLASS=890, top=TANK.y+GLASS=150, bottom=TANK.y+TANK.h-GLASS=670.
```
Wait floor is 680, tank bottom 670 interior, outer bottom 680. Good, tank sits on floor.

Initial waterLevel = 250. Water from 250 to 670.

Puddle grid: ncols = (RIGHT_WALL-LEFT_WALL)/8 ≈ 145. col width 8. col i center x = LEFT_WALL + (i+0.5)*8.

Puddle simulation:
```
for i in 0..n-2:
  diff = h[i]-h[i+1]
  flow = diff*0.25
  flow = clamp(flow, -maxflow, maxflow)
  h[i]-=flow; h[i+1]+=flow
```
Also apply slight evaporation? No.

Actually to keep it stable, use transfer limited so heights don't go negative.

Also water should spread on floor: initial h=0. Jet particles landing add volume to nearest column. Volume to height: add v/(colWidth).

Let me also add friction/limit so puddle stays.

Now jet particles: each has x,y,vx,vy,vol. Update: vy += g*dt; drag small; x+=vx*dt; y+=vy*dt. If y >= floorY - puddleHeightAt(x): deposit vol, remove. Also if x<leftWall or >rightWall, clamp/bounce.

Actually puddle surface y = floorY - h. Particle hits when y>=surface. Deposit.

Rendering jet as circles with radius ~ sqrt(vol)*something. Let's make particles radius 2-3.

Number of particles: cap 3000. If exceeded, deposit directly to puddle? To conserve, just cap spawning but still subtract tank volume... better: if cap reached, deposit particle's volume directly to puddle at opening base? That'd be weird. Let's just make vol per particle larger when many. Actually simpler: make particles carry volume; cap at 4000; at 60fps spawning maybe 5-30 per frame → 1800/s, lifetime ~1s, so ~2000 alive. Fine.

Let me tune outflow: Q in px^2/s? Volume units px^2 (2D). Tank area = width*height = 580 * 420. Let's say Q = 8000 * submergedFactor * sqrt(head/100). Hmm.

Let me think: dLevel = Q/area. If Q=20000 px^2/s, area=580*420=243600, dLevel=0.082 px/s — too slow. We want water to drain in ~10-20 seconds. Total volume = 580*420=243600. Over 15s → Q~16000 average. Hmm that gives dLevel 0.066 px/s... wait that's per second, over 15s = 1 px? No: dLevel = Q/area = 16000/243600 = 0.0657 px/s. That drains 420px in 6400s. That's wrong because area is huge.

Wait total volume 243600 px^2, Q=16000 px^2/s → time = 15.2s. dLevel = Q/width (not area!) because level drop dLevel * width = volume. Width=580. dLevel=16000/580=27.6 px/s. Right, area of water surface = width * 1 (2D). So dV = width * dLevel. Yes.

So Q ~ 16000 px^2/s average gives ~15s drain. Good. Let's set base C such that Q = C * submergedHeight * sqrt(head). With submergedHeight ~ 40, head ~ 300: sqrt=17.3, product=692. C=23 → Q=16000. Let's use C=25.

But near end, submergedHeight shrinks and head shrinks, so it slows. Good.

Actually opening height maybe 40-100 depending on drag. Fine.

Particle volume: total dV per frame = Q*dt. Split into N particles, each vol=dV/N. N = clamp(round(dV/  volumePerParticle)). Let's say each particle vol ~ 30 px^2. dV at Q=16000, dt=1/60 → 266. N~9. Good. Cap N at 30.

Particle radius: sqrt(vol/π) ~ 3. ok.

Now puddle total volume: eventually all tank water (~243600 px^2) spread over room width 1160 → average height 210px. That's huge, nearly to tank bottom. Hmm, floor at 680, tank bottom 670, so puddle 210 high would reach y=470. That's fine visually — a big flood. But maybe too much. The room is 1200 wide, puddle constrained. Realistically water would spread. 210px high puddle is a lot but plausible for the volume. Actually tank 600 wide 420 tall vs room 1160 wide → depth 420*600/1160 = 217. Yes. So flood ~217px deep. That's dramatic and fine. But objects would float in it. Ok.

Hmm but it might cover the tank's lower portion. Fine.

Maybe reduce tank height or water volume. Let's keep. Actually the puddle should be constrained by walls so it rises. Good.

Let me reduce initial water to make it less extreme: waterLevel=250, bottom=670 → 420 tall. Could raise bottom? Keep.

Now let me code object types.

Rocks: 5-6 rocks, radius 10-18, density 2.6 (water=1). Positioned on tank bottom. They mostly stay. Small ones might be swept.

Toy: a duck/ball radius 16, density 0.3. Floats. Starts at waterline somewhere.

Fish: 5 fish, radius 10, density 1.0. Swim. Represent as {x,y,vx,vy,angle,phase,wanderAngle}.

Plants: 4 plants anchored at bottom, height 80-140. Draw curved. Sway with current.

Fragments: spawn ~14 shards.

Let me write the physics update.

Water helpers:
```
function inTankWater(x,y){
  return x>IL && x<IR && y> waterLevel && y<IB;
}
function inPuddle(x,y){
  const h = puddleHeightAt(x);
  return y > FLOOR - h && y <= FLOOR;
}
function inWater(x,y){ return inTankWater(x,y) || inPuddle(x,y); }
```
But for objects, tank water only when inside tank. Outside tank, puddle.

Buoyancy for object with radius r:
- submergedFraction: approximate by circle vs water. Simplify: if center y > surface, fully submerged-ish. Use:
  - surfaceY = waterSurfaceAt(x) (tank waterLevel or puddle surface).
  - submergedDepth = clamp((y + r) - surfaceY, 0, 2r); fraction = submergedDepth/(2r).
- buoyant force = fraction * volume * rhoWater * g, volume = π r^2.
- weight = mass*g = rhoObj*volume*g.
- net vertical accel = g*(rhoWater/rhoObj * fraction - 1). Let's use per-object density directly.

Actually simpler: acceleration from buoyancy = g * (rhoWater*fraction - rhoObj)/rhoObj. For rock rho=2.6: net = g*(1*fraction - 2.6)/2.6 → negative (sinks). For toy rho=0.3: g*(fraction-0.3)/0.3 → at fraction=0.3 equilibrium. Good.

Drag: in water, a = -k*v (k~3). In air, k~0.1.

Current: only in tank water. Compute current at position:
- opening center (ox, oy).
- if in tank water and breached and Q>0:
  dir = normalize(openingCenter - pos). But flow is toward opening; near the wall it's horizontal.
- strength = Q/ (some normalization) * falloff. Let's do strength = clamp(Q/20000,0,1.5) * (1 - dist/tankDiag) maybe. Actually all water moves toward opening, stronger near it.
- currentVel = dir * strength * 120.
Add acceleration = k*(currentVel - v).

Hmm for fish swimming against current, we want them to feel it.

Let me just implement:
```
function currentAt(x,y){
  if(!breached||!crack||Q<=0) return {x:0,y:0};
  if(!inTankWater(x,y)) return {x:0,y:0};
  const o = openingCenter();
  let dx=o.x-x, dy=o.y-y;
  const d=Math.hypot(dx,dy)+1;
  dx/=d; dy/=d;
  // flow magnitude: stronger near opening
  const mag = 140 * clamp(Q/18000,0,1.4) * (1/(1+d/220));
  return {x:dx*mag, y:dy*mag*0.5};
}
```

Objects update:
```
for obj:
  const w = waterInfo(obj.x,obj.y);
  const inW = w.inWater;
  const surf = w.surfaceY;
  let fraction = 0;
  if(inW){ fraction = clamp((obj.y+obj.r - surf)/(2*obj.r),0,1); }
  // gravity
  obj.vy += G*dt;
  // buoyancy
  if(fraction>0){
     obj.vy -= G*(RHO_W/obj.density)*fraction*dt; // this is accel = g*rhoW*fraction/rhoObj upward
     // Wait: buoyant accel = g * rhoW*fraction/rhoObj. weight accel=g. net = g - g*rhoW*fraction/rhoObj.
  }
```
Let me write: obj.vy += G*dt - G*(RHO_W/obj.density)*fraction*dt. Yes.

Drag:
```
const dragK = inW? 3.5 : 0.15;
obj.vx -= obj.vx*dragK*dt;
obj.vy -= obj.vy*dragK*dt;
```
Current (only tank water):
```
const cur = currentAt(obj.x,obj.y);
if(inW && (cur.x||cur.y)){
  obj.vx += (cur.x-obj.vx)*1.5*dt;
  obj.vy += (cur.y-obj.vy)*1.5*dt;
}
```

Fish AI adds swim force:
```
if(type==='fish'){
  // desired direction: wander
  obj.wander += (Math.random()-0.5)*... 
  let ax = Math.cos(obj.wander)*swimSpeed, ay=Math.sin(obj.wander)*swimSpeed;
  // swim against current
  if(cur strength high){ ax -= cur.x*2; ay -= cur.y*2; }
  // steer toward target velocity
  obj.vx += (ax-obj.vx)*2*dt; ...
  // keep inside tank when not breached or try to avoid opening
}
```
Fish also should not leave through opening normally but "some are swept through". If swept, they pass.

Fish boundary: if fish near walls, steer away. But if current pushes through opening, allow.

Actually simpler: fish steer toward a target point inside tank; when outside tank (swept), they flail with gravity.

Let me handle tank wall collisions for objects generally, with opening allowance.

Collision function for object with tank walls:
- If obj inside tank region (x between IL and IR, y between IT and IB):
  - left wall: if obj.x - r < IL: if opening active on left and fits and obj.y within opening y-range: allow (do nothing, maybe push out). else obj.x = IL+r; obj.vx*=-0.4.
  - similarly right.
  - bottom: if obj.y + r > IB: obj.y = IB-r; obj.vy*=-0.2; friction.
  - top: if obj.y - r < IT: clamp.
- If obj outside tank (x<IL or x>IR): treat room floor/walls.

But when passing through opening, need continuity. Let's define: if obj.x < IL (left of tank) and not in tank water... Actually let's just check wall crossing only when the object is within the y-range of tank interior. Hmm.

Simplify with a "fits" check: opening height = oy2-oy1. Object fits if 2*r <= openingHeight*0.9.

When object's x is within r of wall from inside, and y within opening range, and fits, allow it to move to outside. Once x < IL - r, it's outside.

Let me just do: 
```
if(obj.y > IT && obj.y < IB){ // at tank height
  // left wall
  if(obj.x < IL + obj.r){
     if(breached && crack.side==='left' && fits && obj.y>crack.y1-... ) { /* allow */ }
     else { obj.x = IL+obj.r; obj.vx=Math.abs(obj.vx)*0.3; }
  }
  ...
}
```
But if outside tank and obj.x < IL, then obj.x < IL+r triggers wall from outside, pushing it back in! Need to only apply when object came from inside. Track obj.outside flag. Once it exits, set outside=true and never re-enter (or allow re-enter? no).

Let's set: when object passes x<IL and fits and at opening → obj.escaped=true. If escaped, skip tank wall collisions.

Actually object could be outside tank entirely (like fragments spawned outside? no). Let's use escaped flag.

Also objects can be in puddle outside.

For fish, prevent escaping unless strong current: fish swim force counteracts. Fine.

Now the toy floats at waterline. But if it escapes with water, it lands in puddle and floats there. Good.

Plants: anchored; not free objects. They just render with bend. But "plants bend or drift" — maybe one plant can be uprooted? Keep anchored bending. Could add a small "floating leaf" that drifts. Let's just bend.

Let me define plant: {x, baseY, height, sway, segments}. Bend direction from current at mid height. Draw quadratic curve.

Let me also add bubbles? optional.

Rendering order:
1. background gradient, floor.
2. tank back wall / water body (inside tank) — draw water rect with surface.
3. plants (behind objects).
4. puddle (outside).
5. rocks, toy, fish.
6. fragments.
7. jet particles.
8. tank glass frame on top, crack, opening gap.
9. UI text.

Actually puddle should be drawn on floor, before objects. Tank water before objects inside.

Let me draw tank water only inside interior region. Water from waterLevel to IB. Use clipping.

Let me now write the file. I'll be careful with syntax.

Let me structure:

```html
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Aquarium Breach</title>
<style>...</style>
</head>
<body>
<div id="wrap">
  <canvas id="c" width="1200" height="800"></canvas>
  <div id="ui">... buttons ...</div>
</div>
<script>
...
</script>
</body>
</html>
```

Wait, addendum says use browser tools. The browser tool runs index.html. Buttons should be HTML overlay or drawn on canvas with click handling. I'll use HTML buttons positioned over canvas for reliability, or canvas-drawn buttons. HTML buttons easier for browser tool clicking? Browser click uses coordinates on the page. Overlay divs positioned absolutely relative to canvas. Let me make canvas responsive but with fixed 1200x800 CSS pixels? The viewport is 1200x800. Canvas at 1200x800 would exactly fit, but buttons overlay. Let me make canvas fill and scale via CSS to fit while keeping aspect. Simpler: canvas width=1200 height=800, style width:100vw;height:100vh maybe distorts. Let me use CSS to fit inside viewport with letterboxing, and position UI relative to canvas using a wrapper with fixed aspect.

Simplest for testing: canvas CSS width 1200px, height 800px, no scaling, wrapper position relative. Body margin 0, overflow hidden. Buttons absolutely positioned over canvas. That should work at 1200x800 viewport (canvas exactly fills). Might have scrollbars but ok.

Actually 1200x800 viewport minus nothing → fits exactly. Good.

UI: top bar with title/instructions, and buttons "Breach" and "Reset". Place at top center over canvas.

Pointer events: attach to canvas. Convert client coords to canvas coords using getBoundingClientRect and scale.

Let me write the code now.

I'll define everything in one script.

```js
const cv = document.getElementById('c');
const ctx = cv.getContext('2d');
const W=1200,H=800;

const FLOOR=680, ROOM_L=20, ROOM_R=1180;
const TANK={x:300,y:140,w:600,h:540};
const GLASS=12;
const IL=TANK.x+GLASS, IR=TANK.x+TANK.w-GLASS, IT=TANK.y+GLASS, IB=TANK.y+TANK.h-GLASS;
const RHO_W=1;
const G=900; // px/s^2
```

Initial water level:
```
const INIT_LEVEL=250;
```

Globals:
```
let waterLevel=INIT_LEVEL;
let breached=false;
let crack=null;
let Q=0;
let jet=[], frags=[], objs=[], plants=[];
let puddleH, PCOL=8, PNC=Math.ceil((ROOM_R-ROOM_L)/PCOL);
let time=0;
let dragging=false, dragStart=null, dragCur=null;
```

Reset function builds scene.

```js
function reset(){
  waterLevel=INIT_LEVEL;
  breached=false; crack=null; Q=0;
  jet=[]; frags=[];
  puddleH=new Float32Array(PNC);
  objs=[]; plants=[];
  // rocks
  addRock(430, IB-16, 16);
  ...
}
```

Rocks positions relative. IB=670. Rock radius r, y=IB-r.

Let me place:
- rock 1: x=380, r=18
- rock 2: x=430, r=12
- rock 3: x=470, r=15
- rock 4: x=760, r=20
- rock 5: x=810, r=11
- small pebbles maybe.

Toy: x=700, y=INIT_LEVEL-8, r=15, density 0.25.

Fish: 6 fish at various positions below waterline.
```
for i: x=400+i*80, y=300+ (i%3)*70, angle random.
```

Plants: x=350, 520, 620, 850; baseY=IB; height 90-150.

Let me now write update(dt).

Q computation:
```
function opening(){ if(!crack) return null;
  const x = crack.side==='left'? IL: IR;
  const y1=crack.y1, y2=crack.y2;
  return {x,y1,y2,cy:(y1+y2)/2,h:y2-y1, side:crack.side};
}
```

```
function computeQ(){
  if(!breached||!crack){Q=0;return;}
  const o=opening();
  const top=Math.max(waterLevel,o.y1);
  const bot=Math.min(IB,o.y2);
  const sub=bot-top;
  if(sub<=0){Q=0;return;}
  const head=Math.max(0,(top+bot)/2 - waterLevel);
  Q = 30 * sub * Math.sqrt(head+4);
  // maybe cap
}
```
Hmm with sub~50, head~ (opening center - waterLevel). If opening at y 500-560, center 530, waterLevel 250 → head 280, sqrt=16.7, Q=30*50*16.7=25000. Good.

Drain: waterLevel += Q*dt / (IR-IL).

Spawn jet particles:
```
const dV = Q*dt;
if(dV>0){
  const volPer=28;
  let n=Math.min(40,Math.max(1,Math.round(dV/volPer)));
  const each=dV/n;
  const o=opening();
  for(i){
    const y = o.y1 + Math.random()*o.h;
    const dir = o.side==='left'? -1: 1;
    const speed = 90 + Math.random()*90;
    jet.push({x:o.x, y, vx: dir*speed, vy: 20*Math.random(), vol: each, r: 2+Math.random()*1.5});
  }
}
```
Wait, water should exit mostly horizontally then curve down. Good.

Update jet:
```
for each p: p.vy += G*0.9*dt; p.x+=p.vx*dt; p.y+=p.vy*dt;
// deposit when reaching puddle surface or floor
const surf = FLOOR - puddleAt(p.x);
if(p.y>=surf){ addPuddle(p.x, p.vol); remove; }
else if(p.x<ROOM_L||p.x>ROOM_R){ remove/add }
```

puddleAt(x): column index clamp, return puddleH[i].

addPuddle(x, vol): i=clamp(floor((x-ROOM_L)/PCOL),0,PNC-1); puddleH[i]+= vol/PCOL. Actually volume spread over a column width. Adding vol/PCOL height. But if column already tall, maybe distribute to neighbors. Keep simple.

Puddle flow update:
```
for(let i=0;i<PNC-1;i++){
  const d=puddleH[i]-puddleH[i+1];
  let f=d*0.2;
  f=Math.max(-maxf,Math.min(maxf,f));
  if(f>0){ const t=Math.min(f,puddleH[i]); puddleH[i]-=t; puddleH[i+1]+=t; }
  else { const t=Math.min(-f,puddleH[i+1]); puddleH[i+1]-=t; puddleH[i]+=t; }
}
```
maxf maybe 3. Actually need units: heights px, flow px per step. With dt substeps. Use f = d*0.5*dt*60? Let's just tune. We'll run at fixed dt and do a few iterations.

Hmm, puddle spreading speed: water should spread. Use iterations 2 per frame, factor 0.25.

But volume conservation with column width constant → sum h * PCOL = volume. Good.

Puddle rendering: for each column, rect from FLOOR-h to FLOOR, width PCOL. Fill blue. Could draw path for smoothness; rects fine.

Now object update. Let me write function updateObject(o, dt).

waterSurfaceAt(x): if x between IL and IR and (inside tank region) return waterLevel; else return FLOOR - puddleAt(x). But an object inside tank at y>IB? not.

Actually determine region by x: if x>=IL && x<=IR → tank surface = waterLevel (if y within tank), else puddle. But escaped objects outside x<IL use puddle.

```
function surfaceAt(x){
  if(!o.escaped && x>IL && x<IR) return waterLevel;
  return FLOOR - puddleAt(x);
}
```
But escaped object could still be at x between IL and IR (e.g., on top of tank? no). Use o.escaped flag.

Actually fragments spawned near opening outside tank → escaped=true.

Let me define per-object `outside` boolean: true if it's in the room (not inside tank). For objects initially inside, false. When passes through opening, set true. For fragments, true.

Water info:
```
function waterInfo(o){
  const surf = o.outside ? (FLOOR - puddleAt(o.x)) : waterLevel;
  const inWater = o.y + o.r > surf && o.y < FLOOR+50; // submerged partially
  return {surf, inWater};
}
```
Also for tank objects, if waterLevel > o.y+... they're submerged.

Compute fraction submerged = clamp((o.y+o.r - surf)/(2*o.r),0,1). If surf below floor etc. Good enough.

Current: only for non-outside objects in tank water. currentAt returns 0 if !inTank.

Now let's handle collisions:

```
function collideWalls(o){
  // room walls
  if(o.x-o.r<ROOM_L){o.x=ROOM_L+o.r;o.vx=Math.abs(o.vx)*0.3;}
  if(o.x+o.r>ROOM_R){o.x=ROOM_R-o.r;o.vx=-Math.abs(o.vx)*0.3;}
  // floor
  if(o.y+o.r>FLOOR){o.y=FLOOR-o.r; if(o.vy>0){o.vy*=-0.25;} o.vx*=0.85;}
  // tank walls for non-outside
  if(!o.outside){
    if(o.y>IT && o.y<IB){
      if(o.x-o.r<IL && !(canExit(o,'left'))){o.x=IL+o.r;o.vx=Math.abs(o.vx)*0.3;}
      if(o.x+o.r>IR && !(canExit(o,'right'))){o.x=IR-o.r;o.vx=-Math.abs(o.vx)*0.3;}
    }
    if(o.y+o.r>IB){o.y=IB-o.r; if(o.vy>0)o.vy*=-0.2; o.vx*=0.9;}
    if(o.y-o.r<IT){o.y=IT+o.r; if(o.vy<0)o.vy*=-0.2;}
  }
  // tank outer side walls for outside objects (they can't go back in)
  if(o.outside){
    // colliding with tank exterior? tank sits on floor, objects outside may hit tank outer wall
    // Actually if object is beside tank, tank wall blocks it.
  }
}
```

Hmm outside objects: tank occupies x 300..900, y 140..680. If water escapes to the left, it lands left of tank. Objects there could slide under? Tank is on floor so no. An escaped object at x<IL will just be in room. But the tank exterior wall at x=TANK.x=300 might block movement toward tank. Since it's on the floor and object radius, if o.x+o.r > TANK.x and o.y > TANK.y and o.outside and o.y+... then clamp. Let's add:
```
if(o.outside){
  // left exterior
  if(o.x < TANK.x && o.x+o.r>TANK.x && o.y>TANK.y-o.r){ o.x=TANK.x-o.r; o.vx=-Math.abs(o.vx)*0.3; }
  if(o.x > TANK.x+TANK.w && o.x-o.r<TANK.x+TANK.w && o.y>TANK.y-o.r){ o.x=TANK.x+TANK.w+o.r; o.vx=Math.abs(o.vx)*0.3; }
}
```
But an object that just exited through the opening is at x slightly less than IL (310) but TANK.x=300. If r=10, o.x=300 would be inside tank wall region... Actually opening is at IL=312 (inner wall). Tank glass from 300 to 312. When object exits, it passes through glass thickness to x<300. During transit o.x in [300,312] with outside=true, the exterior clamp would push it. Hmm. Let's set outside=true only when o.x < TANK.x - o.r (fully outside). Until then, allow passing.

Better: track a state: 'inside', 'exiting', 'outside'. When exiting through opening, once o.x passes IL, set exiting. While exiting, skip tank wall collisions and skip exterior collision. When o.x < TANK.x - o.r or > TANK.x+TANK.w+o.r, set outside.

Let me just use o.outside boolean and set it when crossing outer boundary. During transit (between IL and TANK.x) still !outside so tank wall collision might push back. So I need canExit to allow while at opening.

canExit(o, side): 
```
if(!breached||!crack||crack.side!==side) return false;
const o2=opening();
const fits = (2*o.r) <= (o2.h)*0.95;
const withinY = o.y > o2.y1+o.r*0.3 && o.y < o2.y2-o.r*0.3;
return fits && withinY;
```
Then in collideWalls, if canExit, don't clamp, and set a flag o.exiting=true. When o.x < TANK.x - o.r → outside=true, exiting=false.

For exterior collision skip if o.exiting.

Let me implement:
```
if(!o.outside){
   ... inner wall checks with canExit ...
   if(o.exiting && (o.x < TANK.x - o.r || o.x > TANK.x+TANK.w+o.r)){ o.outside=true; o.exiting=false; }
}
if(o.outside && !o.exiting){ exterior checks }
```

But while !outside and o.x < IL, the inner wall check `o.x-o.r<IL` with canExit true won't clamp. Good. Once outside, skip.

Also once fully outside, exterior collision prevents going back into tank. Good.

Fish: they're inside; to avoid escaping they steer, but if they fit opening they might exit. Fine.

Now fish AI update separately before physics.

Let me write update:
```
function step(dt){
  time+=dt;
  computeQ();
  // drain
  if(Q>0){ waterLevel += Q*dt/(IR-IL); if(waterLevel>IB)waterLevel=IB; }
  spawnJet(dt);
  updateJet(dt);
  updatePuddle(dt);
  for(const p of plants) updatePlant(p,dt);
  for(const o of objs) updateObj(o,dt);
  for(const f of frags) updateFrag(f,dt);
}
```

Wait waterLevel increasing? It should fall (y increases downward). Yes waterLevel += positive, y increases = lower. Good.

updateObj:
```
function updateObj(o,dt){
  if(o.type==='fish') fishAI(o,dt);
  const wi = waterInfo(o);
  let fraction=0;
  if(wi.inWater) fraction=clamp((o.y+o.r - wi.surf)/(2*o.r),0,1);
  // gravity
  o.vy += G*dt;
  // buoyancy
  o.vy -= G*(RHO_W/o.density)*fraction*dt;
  // drag
  const dk = wi.inWater?3.0:0.2;
  o.vx -= o.vx*dk*dt; o.vy -= o.vy*dk*dt;
  // current
  if(!o.outside){
    const cur=currentAt(o.x,o.y);
    if(cur.mag>0){ o.vx += (cur.x-o.vx)*1.2*dt; o.vy += (cur.y-o.vy)*1.2*dt; }
  }
  // fish swim (extra) handled in fishAI
  o.x+=o.vx*dt; o.y+=o.vy*dt;
  collideWalls(o);
  // clamp velocity
}
```

Hmm buoyancy fraction uses surf which for outside is puddle surface. If object outside in puddle, floats. Good.

But `waterInfo.inWater` condition: I wrote `o.y+o.r > surf`. Also need object not above. Fine.

Wait there's a bug: if object is on the floor outside and there's no puddle, surf = FLOOR, o.y+r > FLOOR is false (o.y+r = FLOOR), so not in water. Good.

But if o.y+r > surf with surf=FLOOR and o.y+r==FLOOR exactly, not in water. Good.

Now fish AI:
```
function fishAI(o,dt){
  o.wander += (Math.random()-0.5)*2*dt*3;
  let tx=Math.cos(o.wander)*o.swim, ty=Math.sin(o.wander)*o.swim*0.5;
  const cur=currentAt(o.x,o.y);
  if(cur.mag>5){
    // swim against current
    tx -= cur.x*1.6; ty -= cur.y*1.6;
  }
  // avoid walls / stay in tank when not breached strongly
  if(!o.outside){
    if(o.x<IL+40) tx+=60;
    if(o.x>IR-40) tx-=60;
    if(o.y<waterLevel+20) ty+=40;
    if(o.y>IB-30) ty-=40;
  }
  const steer=2.5;
  o.vx += (tx-o.vx)*steer*dt;
  o.vy += (ty-o.vy)*steer*dt;
  o.angle = Math.atan2(o.vy,o.vx);
}
```
swim ~ 90.

Fish density 1.0 so neutral buoyancy.

Fragments:
```
function updateFrag(f,dt){
  const wi = waterInfo(f); // treat as object
  const frac = wi.inWater? clamp((f.y+f.r - wi.surf)/(2*f.r),0,1):0;
  f.vy += G*dt;
  f.vy -= G*(RHO_W/2.5)*frac*dt; // glass sinks
  const dk = wi.inWater?4.0:0.1;
  f.vx -= f.vx*dk*dt; f.vy -= f.vy*dk*dt;
  if(!f.outside){ current... }
  f.x+=f.vx*dt; f.y+=f.vy*dt;
  f.angle += f.av*dt;
  f.av *= (wi.inWater?0.97:0.995);
  collideWalls(f);
}
```
Fragments have r ~4-9.

Now rendering. Let me write draw().

```
function draw(){
  ctx.clearRect(0,0,W,H);
  // room bg
  grad sky
  // floor
  // tank water (behind)
  drawTankWater();
  // puddle
  drawPuddle();
  // plants
  // objects
  // fragments
  // jet
  // tank glass frame
  // crack & opening
  // UI hints
}
```

Order: tank water should be behind objects. Puddle also behind objects. Let's draw puddle then tank water then plants then objects.

Actually tank water inside tank; puddle outside. Draw both.

drawTankWater: clip to interior rect, fill from waterLevel to IB. Add surface wave line. Add some subtle current streaks maybe.

drawPuddle: build path along columns, fill gradient.

Tank glass: draw outer rect stroke thick with translucent glass color; draw inner highlight lines. For breached side, leave gap at opening: draw wall segments above/below opening with jagged edges.

Let me draw the tank as 4 walls each a rectangle of GLASS thickness:
- left wall rect x=TANK.x..IL, y=TANK.y..TANK.y+TANK.h
- right similarly
- top, bottom.

For left wall if breached & crack.side left: draw only above y1 and below y2, with jagged edges near gap. Fragments already flown.

Simplest: use ctx.save(); clip out the opening region? We can draw the full wall then clear a gap region. Use globalCompositeOperation='destination-out'? That would clear background too. Better draw wall segments.

I'll write drawWall(side).

Let me just draw walls as filled rects, and for the breached side draw two rects (top part and bottom part) plus jagged triangle edges.

```
function drawGlass(){
  ctx.save();
  ctx.fillStyle='rgba(170,215,235,0.18)';
  ctx.strokeStyle='rgba(220,245,255,0.75)';
  ctx.lineWidth=2;
  // top
  roundRectFill(TANK.x,TANK.y,TANK.w,GLASS);
  // bottom
  roundRectFill(TANK.x,TANK.y+TANK.h-GLASS,TANK.w,GLASS);
  // left
  drawSideWall('left');
  drawSideWall('right');
  // highlights
  ctx.restore();
}
```

drawSideWall(side):
```
const x = side==='left'? TANK.x : TANK.x+TANK.w-GLASS;
if(breached&&crack&&crack.side===side){
  // top segment from TANK.y to crack.y1
  fillRect(x,TANK.y,GLASS,crack.y1-TANK.y);
  fillRect(x,crack.y2,GLASS,TANK.y+TANK.h-crack.y2);
  // jagged edges: draw small triangles
} else fillRect(x,TANK.y,GLASS,TANK.h);
```

Add jagged edge triangles at crack.y1 and crack.y2 pointing into gap. I'll draw a few random-ish triangles (deterministic based on crack) to look broken.

Now crack rendering before breach: draw a jagged dark line on the wall between y1 and y2, plus small branches. Use a seeded pattern.

Let me precompute crack jagged points when crack finalized.

Interaction:
- pointerdown: check if near left or right wall (within 30px of TANK.x or TANK.x+TANK.w) and y between waterLevel+8 and TANK.y+TANK.h-8, and not breached. Start drag. Record side, startY = clamp(y).
- pointermove: update curY. Show preview.
- pointerup: finalize crack if |curY-startY|>=20. Else maybe make min 40 centered? Let's require min 24; if too small, expand to 40 centered on start.
- Actually "drag a visible crack vertically" — we should show crack while dragging.

Also allow starting drag directly on the crack line. But simplest: near wall.

Let me set crack = {side, y1, y2, jags:[...]}. y1<y2, clamped within (waterLevel+8, IB-4). Actually crack should be below initial waterline. Since waterLevel changes after breach, use initial? "below the initial waterline" — clamp to INIT_LEVEL. But we only create crack before breach, so waterLevel=INIT_LEVEL. Good. Clamp y to [INIT_LEVEL+10, IB-6].

Also ensure crack on wall and its y range within wall.

Buttons: Breach enabled if crack && !breached. Reset always.

Add instruction text overlay.

Now, "show the panel breaking around the selected opening" — on breach spawn fragments and mark. Also maybe a brief flash/shake.

Let me write fragments spawn:
```
function spawnFragments(){
  const o=opening();
  const n=Math.floor(o.h/6)+8;
  for(i){
    const y=o.y1+Math.random()*o.h;
    const dir=o.side==='left'?-1:1;
    frags.push({x:o.x+Math.random()*8*dir, y, vx:dir*(60+Math.random()*180), vy:-120+Math.random()*180, r:3+Math.random()*5, angle:Math.random()*6.28, av:(Math.random()-0.5)*10, outside:false, density:2.5, type:'frag', poly: makePoly()});
  }
}
```

Fragments inside water near opening then flow out.

Now let me consider performance: jet particles maybe up to 2000, objects ~20, fragments ~20. Fine.

Let me also make the jet visually a stream: draw particles as circles with alpha.

Let me now write the actual code. I'll be thorough.

One more: "nearby objects respond to the current" — rocks small may shift, toy drifts toward opening, fish swim against, plants bend. Good.

Let me make sure rocks don't all get swept. Rocks density 2.6, on bottom, drag high. Current force via velocity steering might move them. We apply current as `o.vx += (cur.x-o.vx)*1.2*dt`. For heavy rock we should scale by buoyancy/inertia? Actually current force should be mass-independent-ish in terms of drag, but heavier objects accelerate less. Let's scale current steering by (RHO_W/o.density). For rock 1/2.6=0.38, toy 1/0.25=4 (very responsive), fish 1. Good. That gives distinct responses. Let me incorporate: current steering factor = 1.5 * (RHO_W/o.density) but cap.

Also drag: heavier objects still experience drag but we use same k. For rocks resting on floor, friction. Add floor friction: if on bottom and in tank, vx *= 0.8.

Let me code rock resting: in collideWalls bottom clamp, set vx*=0.7 each frame when in contact.

Now the "fits opening" for rocks: only small rocks (r<=~8) fit. Most rocks r>=11 won't. Maybe add 2-3 small pebbles r=6-8 that can be swept out. Good, satisfies "movable objects that fit the opening can be carried out."

Also the toy r=15: if opening height > ~32, toy can exit. Since crack length user controls, likely 40-100, so toy can exit. Good.

Fish r=10: opening >21 → can exit. Good.

Let me write.

Also need to handle the case where water level drops below opening top → Q=0 → jet stops. "stops when water no longer reaches it." Good.

Let me also stop puddle spread eventually. Fine.

Let me write the HTML now.

I'll be careful about `ctx.roundRect` support — it's available in modern browsers. To be safe, use plain fillRect.

Let me write code.

For the water surface wave, use sin.

Let me write plants: 
```
function makePlant(x,h){
  return {x, baseY:IB, h, phase:Math.random()*6.28, bend:0, n:6};
}
function updatePlant(p,dt){
  const cur=currentAt(p.x, IB-p.h*0.5);
  const target = cur.x*0.004;
  p.bend += (target-p.bend)*2*dt;
  p.phase += dt*1.5;
}
```
Draw: for i segments, compute sway = sin(time*1.5+p.phase+i*0.5)*3 + bend*i*i. x offset accumulates. Draw stem as line segments with leaves.

Actually bend should make plant lean toward flow direction (downstream). cur.x points toward opening. So plant tips bend toward opening. Good.

Let me now write full code.

I'll now produce index.html.

Let me write carefully.

```js
// ---- helpers
const clamp=(v,a,b)=>v<a?a:(v>b?b:v);
const lerp=(a,b,t)=>a+(b-a)*t;
const rand=(a,b)=>a+Math.random()*(b-a);
```

Let me define everything.

For puddleAt:
```
function puddleAt(x){
  const i=clamp(Math.floor((x-ROOM_L)/PCOL),0,PNC-1);
  return puddleH[i];
}
```

addPuddle:
```
function addPuddle(x,vol){
  let i=clamp(Math.floor((x-ROOM_L)/PCOL),0,PNC-1);
  puddleH[i]+=vol/PCOL;
}
```
But if a column gets huge and neighbors low, flow spreads. Good.

Potential issue: jet particles landing at same spot create spike. Flow smooths.

Puddle update with substeps:
```
function updatePuddle(dt){
  const iters=3;
  for(let k=0;k<iters;k++){
    for(let i=0;i<PNC-1;i++){
      const d=puddleH[i]-puddleH[i+1];
      let f=d*0.22;
      if(f>0){ const t=Math.min(f,puddleH[i]); puddleH[i]-=t; puddleH[i+1]+=t; }
      else { const t=Math.min(-f,puddleH[i+1]); puddleH[i+1]-=t; puddleH[i]+=t; }
    }
  }
}
```

Volume conservation holds.

Now let's consider the puddle may become extremely tall (210 avg) and spread to walls. Fine.

Rendering puddle: for each column, draw rect. To smooth, build path:
```
ctx.beginPath();
ctx.moveTo(ROOM_L, FLOOR);
for(i) { x=ROOM_L+i*PCOL; ctx.lineTo(x, FLOOR-puddleH[i]); ctx.lineTo(x+PCOL, FLOOR-puddleH[i]); }
ctx.lineTo(ROOM_R, FLOOR);
ctx.closePath();
ctx.fill();
```
This creates steps. Fine. Or use quadratic smoothing. Keep steps but maybe reduce PCOL to 6.

Let me use PCOL=6 → PNC ~ 194. Fine.

Now tank water: draw with clip.

```
ctx.save();
ctx.beginPath();
ctx.rect(IL,IT,IR-IL,IB-IT);
ctx.clip();
const g=ctx.createLinearGradient(0,waterLevel,0,IB);
g.addColorStop(0,'rgba(70,160,220,0.55)');
g.addColorStop(1,'rgba(20,80,150,0.75)');
ctx.fillStyle=g;
ctx.fillRect(IL,waterLevel,IR-IL,IB-waterLevel);
// surface
ctx.strokeStyle='rgba(180,230,255,0.8)';ctx.lineWidth=2;
ctx.beginPath();
for(x=IL;x<=IR;x+=6){ y=waterLevel+Math.sin((x*0.05)+time*2)*2; if(x===IL)moveTo else lineTo }
ctx.stroke();
ctx.restore();
```

Also draw current streaks inside water maybe.

Now tank glass.

Let me also draw the tank background behind water: a light rect.

Let me write the draw order:
1. room background + floor.
2. tank inner background (glass back).
3. tank water.
4. puddle.
5. plants.
6. objects (rocks, toy, fish).
7. fragments.
8. jet.
9. tank frame/walls.
10. crack.
11. HUD text.

Wait jet should be drawn maybe before glass so it appears to come through opening; either way fine. Draw jet after objects.

Now writing the code fully.

Let me also handle mouse coordinate scaling since canvas may be scaled by CSS. I'll set canvas style width/height to fit viewport while preserving aspect using JS on resize, and compute scale in pointer handler.

Actually simpler: set CSS `canvas{width:100%;height:100%}` inside a wrapper that maintains 3:2 aspect. Let me do:
```
#stage{position:relative;width:min(100vw,150vh);height:min(66.67vw,100vh);}
canvas{width:100%;height:100%;display:block;}
```
Wait aspect 1200:800 = 3:2. width = min(100vw, 1.5*100vh) = min(100vw,150vh). height = width*2/3 = min(66.67vw,100vh). Good.

Pointer: rect=cv.getBoundingClientRect(); x=(e.clientX-rect.left)*(W/rect.width).

Buttons overlay in #stage with absolute positioning.

Let me write the HTML/CSS/JS.

Now let me be careful with the "Breach" button disabled state and labels.

Let me code it.

I'll write the whole file now.

One concern: fish AI uses waterLevel and current; when breached and current strong, fish swim against. But currentAt direction points from fish to opening, so "against" means subtract cur → fish swims away from opening. Good.

However if fish is close to opening and gets swept, it exits. Good.

Now, the toy: density 0.25, equilibrium fraction=0.25 → submerged depth 0.5*r? (o.y+r-surf)/(2r)=0.25 → o.y = surf - r + 0.5r = surf-0.5r. So center slightly above waterline. Good.

But as water level drops, toy follows. Buoyancy force with strong damping. k=3 should be okay. Might oscillate; add vertical damping stronger for toy. Actually drag dk=3 for water. Let's see natural frequency: a = g*(1/0.25)*fraction = 4g*fraction... for small displacement fraction changes by dy/(2r), a ≈ 4g*dy/(2r)=2g dy/r. ω=sqrt(2*900/15)=sqrt(120)=11 rad/s. Damping 3/s, underdamped (critical ~22). Might bob a lot. Increase water drag for toy to 6. Or set density 0.35. Let's use dk=4.5 in water and it'll be okay-ish; bobbing looks fine for a toy.

Rocks: density 2.6, fraction=1 when submerged → a = g(1-1/2.6*1)... wait formula: vy += G*dt - G*(RHO_W/density)*fraction*dt = G(1 - fraction/2.6)dt. When fully submerged fraction=1 → a = G(1-0.385)=0.615G downward. Good, sinks.

Glass density 2.5 similar.

Now let me write it all.

I need to double check the buoyancy sign: upward accel = G*(RHO_W/objDensity)*fraction. For toy density 0.25, fraction=1 → upward accel = 4G, net = -3G (rises). Yes.

Alright.

Also need to prevent objects from being numerically unstable when fully submerged and fraction computed with surf above. Fine.

Let me write.

For collideWalls exterior collision, tank outer x from TANK.x to TANK.x+TANK.w.

Let me write final code now.

Also handle window pointer events for drag continuation outside canvas.

Let me produce the file.

I'll write the script with an init() and animation loop using requestAnimationFrame with fixed timestep accumulator.

Let me write now.

Also add a "hint" text drawn on canvas: "Drag on a side wall below the waterline to make a crack" until crack exists.

Let me write.

Potential bug: canExit uses opening().h and o.r. If object is fish r=10 and opening h=50, fits. withinY check.

Also when object exits, we should let it pass even if partially. Good.

Let me also ensure objects spawned outside (fragments) have outside=true so they use puddle surface and exterior collisions. But fragments spawned at opening are at x=o.x which for left is IL. With outside=true and exterior collision, they'd be pushed to TANK.x-o.r immediately. That's a jump. Let me spawn fragments with outside=false and exiting=true, then they flow out. Actually they're glass from the wall, at x around TANK.x..IL. Let's spawn at x = o.x + dir*(random*6) where for left dir=-1 so x in [IL-6, IL] i.e., [304,310]. They're in the wall region. Set outside=false, exiting=true. Then update moves them out; when x<TANK.x-r set outside. But exiting=true skips inner wall clamp via canExit (fits likely). Good.

But wait, `if(o.y+o.r>IB)` bottom check and `o.y-o.r<IT` top still apply, fine.

Also `if(o.y>IT && o.y<IB)` condition for wall clamp — fragment y within opening, yes.

Hmm but if fragment is at x=304 (<IL) and !outside, the inner left wall check `o.x-o.r<IL` with canExit true → no clamp. Good. Once x<TANK.x-r → outside.

Let me set fragment.outside=false, fragment.exiting=true initially.

Now write.

For objects passing out, similarly set exiting=true in collideWalls when canExit triggers and object crossing. Let me detect: in collideWalls, if !o.outside and o.x-o.r<IL and canExit → o.exiting=true. Then no clamp. Good.

Let me code canExit to be checked in collideWalls.

Also for the right side.

Let me write.

Let me now write the file in one go.

Also, puddle volume can get huge; drawing rect from FLOOR-h. h up to ~250. Fine.

Let me also cap puddle height to not exceed tank bottom? No, water would just rise. But it can't exceed because volume limited.

Actually total water ~243600 px². Room width 1160, but tank occupies 600 width sitting on floor, so available floor width = 1160-600=560 on the sides? Wait puddle columns span full room width including under the tank? The tank occupies from x=300 to 900 on the floor, so water can't be there. But my puddle grid spans ROOM_L..ROOM_R including under tank. That means puddle height would appear under the tank, which is hidden behind tank anyway (tank drawn on top). But volume would be distributed over 1160 width instead of 560, giving lower height. And water would appear to be inside the tank area. Since tank is drawn over, the puddle under tank is hidden. But physically water can't go under the tank. For correctness, we should block puddle columns under the tank. Let's add a mask: columns whose x is within [TANK.x, TANK.x+TANK.w] are blocked (height forced 0, no flow into them). Then puddle spreads only on sides. But then water from left side can't reach right side (blocked by tank). That's fine and realistic.

But then total floor width for puddle = 560, height ~435. That's tall, nearly reaching tank top? floor 680-435=245. That's above tank bottom, and would overflow... but walls contain it. It would be a deep flood on both sides. Since tank divides, each side gets its share. If all water exits one side (crack side), that side gets 243600/280 ≈ 870px tall — taller than the room! That's unphysical; water would reach ceiling. Hmm.

Maybe tank is smaller / water volume less. Let's reduce tank size or accept overflow. Real aquariums are large; a 600x540 tank with 420 depth holds a lot. A room 1200 wide with tank 600 wide leaves 560 total (280 each side). Water 243600/280=870. Too much.

Options: make room wider (canvas 1200 fixed). Make tank smaller: e.g., tank width 360, height 340, water depth 280. Volume = (360-24)*(280) ≈ 94000. Sides each 420 wide → 94000/420=224. Reasonable. Let's shrink tank.

New tank: x=420, y=300, w=360, h=380? floor 680 → y+h=680. h=380, y=300. Glass 12. Interior x 432..768, y 312..668. Water initial level y=340 → depth 328. Volume = 336*328=110208. Sides width: left 20..420=400, right 780..1180=400. 110208/400=275. Puddle ~275 tall → surface y=405. Reasonable flood.

Hmm but a 360-wide tank with 5 fish is small. That's okay, aquarium.

Alternatively keep tank 600 wide but reduce water depth to 200 and make room floor at 760? Canvas 800 tall. Let's just shrink tank moderately.

Let me choose:
- TANK x=380, y=300, w=440, h=380 (bottom 680).
- GLASS=12.
- Interior IL=392, IR=808, IT=312, IB=668.
- INIT_LEVEL=350 → depth 318.
- Water volume = 416*318=132288.
- Side widths: left 20..380=360, right 820..1180=360. 132288/360=367. Puddle surface y=313. That's high but ok (tank top 300). Hmm 367 tall flood.

Maybe reduce water depth to 220: INIT_LEVEL=448, depth 220. Volume=416*220=91520 → /360=254. Surface y=426. Good.

Let's set INIT_LEVEL=440, depth 228 → volume 94848 → /360=263. surface 417. Fine.

Tank interior height 356, water 228 from 440 to 668.

Fish need room: water region x 392..808 (416 wide), y 440..668 (228 tall). 5 fish fine.

Rocks on bottom y=668.

Toy at y~440.

Opening crack between y=470 and 640 (below waterline 440). Good.

Let me finalize:
```
TANK={x:380,y:300,w:440,h:380};
GLASS=12;
IL=392,IR=808,IT=312,IB=668;
INIT_LEVEL=440;
```
Room floor 680, so tank sits with outer bottom at 680, glass bottom interior 668.

Crack clamp: y in [INIT_LEVEL+15, IB-8] = [455, 660].

Good.

Rocks: x within 392..808. Let's place:
- r18 at x=450, y=668-18=650
- r13 at x=500
- r10 at x=540
- r16 at x=720
- r7 at x=680 (small, can fit if opening>14)
- r6 at x=760

Toy at x=600, y=INIT_LEVEL-6.

Fish: x 430, 490, 560, 650, 730; y 470-620.

Plants at x=410, 470, 700, 780.

Opening crack user-drawn on left or right wall.

Jet from opening at x=392 (left) or 808 (right). Falls to floor, spreads.

Now puddle under tank blocked: columns with x in [TANK.x, TANK.x+TANK.w] = [380,820]. So left puddle region x 20..380, right 820..1180.

But water exiting left at x=392 lands around x=392-... with vx leftward. It will land near x=300-380, good (left region). Some might land at x>380 (under tank) — blocked; deposit into nearest allowed column. Let me make addPuddle push to nearest non-blocked column. Simpler: puddleAt returns 0 for blocked columns; addPuddle: if blocked, redirect to nearest allowed.

Actually jet particles at x in [380,820] with y reaching floor: they'd hit surf=FLOOR (h=0) and deposit but column blocked → lost. Better to redirect. Let me in addPuddle: find nearest allowed column.

Let me precompute blocked set: i where colX in [TANK.x-?, TANK.x+TANK.w]. Use [380,820].

But water falling right at x=820+ lands in right region. Good.

Also objects outside on the floor: puddleAt returns 0 under tank so they'd sink to floor under tank region, but tank occupies that space physically — exterior collision prevents objects from being under tank (they'd collide with tank side walls). Since tank bottom is at floor, an object can't be under it. Good.

Now, room walls at x=20 and 1180. Puddle constrained there.

Let me set PCOL=6, PNC=Math.ceil(1160/6)=194.

Now let me write.

Also for puddle rendering, blocked columns have h=0, so path dips to floor under tank (hidden by tank anyway).

Let me finalize and write.

Let me now write the code text.

I'll include a simple HUD drawn in HTML overlay.

Let me write the file.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Aquarium Breach</title>
<style>
  html,body{margin:0;padding:0;background:#0a0d12;overflow:hidden;font-family:system-ui,sans-serif;}
  #stage{position:absolute;left:50%;top:50%;transform:translate(-50%,-50%);
         width:min(100vw,150vh);height:min(66.6667vw,100vh);}
  canvas{width:100%;height:100%;display:block;border-radius:6px;}
  #hud{position:absolute;left:0;top:0;width:100%;padding:10px 16px;box-sizing:border-box;
       display:flex;align-items:center;gap:12px;pointer-events:none;}
  #hud .title{color:#dff3ff;font-weight:700;font-size:16px;letter-spacing:.5px;
       text-shadow:0 1px 4px #000;}
  #hud .hint{color:#9fc4dc;font-size:13px;margin-left:auto;text-shadow:0 1px 4px #000;}
  .btn{pointer-events:auto;cursor:pointer;border:1px solid #4fb3e8;background:rgba(20,60,90,.85);
       color:#e8f7ff;padding:8px 18px;border-radius:8px;font-size:14px;font-weight:600;
       transition:.15s;}
  .btn:hover{background:rgba(40,110,160,.95);}
  .btn:disabled{opacity:.4;cursor:default;border-color:#345;}
  #breachBtn{border-color:#ff6b5e;background:rgba(120,30,25,.85);}
  #breachBtn:hover:not(:disabled){background:rgba(180,50,40,.95);}
</style>
</head>
<body>
<div id="stage">
  <canvas id="c" width="1200" height="800"></canvas>
  <div id="hud">
    <span class="title">🐠 Aquarium Breach</span>
    <button id="breachBtn" class="btn" disabled>Breach</button>
    <button id="resetBtn" class="btn">Reset</button>
    <span class="hint" id="hint">Drag vertically on a side wall below the waterline to create a crack</span>
  </div>
</div>
<script> ... </script>
</body>
</html>
```

Now the JS.

Let me write it out fully and carefully.

I'll now write.

Note: I must double-check that `puddleAt` for blocked returns 0.

Let me define blocked array:
```
const BLOCKED = new Uint8Array(PNC);
for i: x=ROOM_L+(i+0.5)*PCOL; if(x>TANK.x-2 && x<TANK.x+TANK.w+2) BLOCKED[i]=1;
```

addPuddle redirect:
```
function addPuddle(x,vol){
  let i=clamp(Math.floor((x-ROOM_L)/PCOL),0,PNC-1);
  if(BLOCKED[i]){
    // find nearest non-blocked
    let best=i,bd=1e9;
    for(let j=0;j<PNC;j++) if(!BLOCKED[j]){const d=Math.abs(j-i); if(d<bd){bd=d;best=j;}}
    i=best;
  }
  puddleH[i]+=vol/PCOL;
}
```
This loop could be slow if called often. Precompute nearest allowed for each i at init. Let me do that:
```
const NEAREST=new Int16Array(PNC);
... 
```

Fine.

puddleAt for blocked returns 0.

Now jet particle deposit uses puddleAt(x) which returns 0 for blocked, so particle continues to floor then deposits via addPuddle redirect. But if puddleAt=0 under tank, surf=FLOOR, particle reaches floor and deposits. Good.

Now let me also handle jet particles hitting room walls: if p.x<ROOM_L, set x=ROOM_L, vx*=-0.3; if >ROOM_R similar.

Now writing updateJet:
```
for(let k=jet.length-1;k>=0;k--){
  const p=jet[k];
  p.vy += G*0.85*dt;
  p.x += p.vx*dt; p.y += p.vy*dt;
  if(p.x<ROOM_L){p.x=ROOM_L;p.vx*=-0.3;}
  if(p.x>ROOM_R){p.x=ROOM_R;p.vx*=-0.3;}
  const surf=FLOOR-puddleAt(p.x);
  if(p.y>=surf){ addPuddle(p.x,p.vol); jet.splice(k,1); continue; }
}
```

Good.

Now let me write drawing of jet as blue circles.

Also add some splash particles? Not necessary.

Now let me write everything.

Let me consider the water level fall rate again with new tank. Interior width 416. Q = 30*sub*sqrt(head+4). Opening h=60, center y=540, waterLevel=440 → head=100, sqrt=10.2, sub=60 → Q=30*60*10.2=18360. dLevel=18360/416=44 px/s. That's fast; tank depth 228 drains in ~5-10s. Maybe a bit fast but dramatic. Let's reduce C to 12 → Q=7344, dLevel=17.6 px/s → ~13s. Good. Use C=12.

Particle spawn: dV=7344/60=122 px² per frame, volPer=28 → n=4.4→4. Each carries ~30. Fine.

Let me use C=14.

Also as waterLevel approaches opening top (540-30=510), sub shrinks, head shrinks, Q→0. Actually when waterLevel reaches opening top y1=510, sub=0 → stop. Wait opening top y1 is upper edge. If crack y1=510,y2=570, center 540. Water level falls to 510 → sub = min(IB,570)-max(510,510)=60? No: top=max(waterLevel,o.y1)=510, bot=min(IB,o.y2)=570, sub=60 still! Because opening is fully above? No wait waterLevel=510 means water surface at y=510, water occupies y>510. Opening spans 510..570 which is below water surface, so still submerged. sub=60. head=center-waterLevel=540-510=30. Q=14*60*sqrt(34)=14*60*5.8=4890. Still flowing.

When waterLevel reaches y2=570 (bottom of opening), top=570,bot=570, sub=0 → stop. So water stops when surface drops below the opening bottom. Correct: "stops when water no longer reaches it." Actually water reaches the opening as long as surface above opening bottom. Right.

But then remaining water below 570 stays? No — water below the opening can't flow out once surface is below opening bottom? Actually if surface is at 570 (bottom edge), there's no water above opening. Water below opening bottom... the opening is above the remaining water, so it can't flow. Correct physically. So a bit of water remains at bottom. Fine.

Good.

Now, waterLevel max is IB. Fine.

Let me write final.

For fish escaping: fish r=10, opening h maybe 60 → fits. When swept to opening, canExit true. Good.

Let me also make fish less likely to escape early by strong upstream swim. Some escape eventually.

Now writing.

I'll also add gentle "breach flash" using a screen shake? Skip.

Let me write the code.

Actually one more: objects' `outside` initial for rocks/toy/fish = false.

`exiting` initial false.

Let me code collideWalls carefully.

```
function collideWalls(o){
  // room bounds
  if(o.x-o.r<ROOM_L){o.x=ROOM_L+o.r; if(o.vx<0)o.vx=-o.vx*0.3;}
  if(o.x+o.r>ROOM_R){o.x=ROOM_R-o.r; if(o.vx>0)o.vx=-o.vx*0.3;}
  if(o.y+o.r>FLOOR){o.y=FLOOR-o.r; if(o.vy>0)o.vy=-o.vy*0.25; o.vx*=0.9;}

  if(!o.outside){
    // tank inner walls
    if(o.y>IT && o.y<IB){
      if(o.x-o.r<IL){
        if(canExit(o,'left')){o.exiting=true;}
        else {o.x=IL+o.r; if(o.vx<0)o.vx=-o.vx*0.3;}
      }
      if(o.x+o.r>IR){
        if(canExit(o,'right')){o.exiting=true;}
        else {o.x=IR-o.r; if(o.vx>0)o.vx=-o.vx*0.3;}
      }
    }
    // top/bottom
    if(o.y+o.r>IB){o.y=IB-o.r; if(o.vy>0)o.vy=-o.vy*0.2; o.vx*=0.85;}
    if(o.y-o.r<IT){o.y=IT+o.r; if(o.vy<0)o.vy=-o.vy*0.2;}
    if(o.exiting && (o.x < TANK.x-o.r || o.x > TANK.x+TANK.w+o.r)){
      o.outside=true; o.exiting=false;
    }
  } else {
    // exterior tank walls (can't go back in)
    if(o.y> TANK.y-o.r){
      if(o.x < TANK.x && o.x+o.r>TANK.x){o.x=TANK.x-o.r; if(o.vx>0)o.vx=-o.vx*0.3;}
      if(o.x > TANK.x+TANK.w && o.x-o.r<TANK.x+TANK.w){o.x=TANK.x+TANK.w+o.r; if(o.vx<0)o.vx=-o.vx*0.3;}
    }
  }
}
```

Hmm the exterior condition `o.x < TANK.x && o.x+o.r>TANK.x` clamps to TANK.x-o.r. But an object far left (x=100) won't be affected. Good. An object at x=350 (left of tank 380) with r=15: o.x+r=365<380, fine. If it moves right to 370: o.x+r=385>380 → clamp to 365. Good.

But wait, the object is on the floor and tank outer wall spans y 300..680. The condition o.y>TANK.y-o.r ensures at tank height. Good.

Now canExit:
```
function canExit(o,side){
  if(!breached||!crack||crack.side!==side) return false;
  const oo=opening();
  if(o.r*2 > oo.h*0.92) return false;
  return (o.y > oo.y1+o.r*0.4 && o.y < oo.y2-o.r*0.4);
}
```

Good.

Now for fragments, `outside=false, exiting=true` initially, so first collideWalls call: !outside branch; if y within opening, canExit true (if fits) sets exiting. Then check x<TANK.x-r. For left, fragment x ~304, TANK.x-r ~380-4=376, 304<376 true → outside=true. Good, immediately outside. But then exterior collision would clamp it back to 376! Because outside and o.x<TANK.x and o.x+r>TANK.x → clamp. That's wrong; fragment is already left of tank and should stay.

The exterior clamp should only prevent crossing from outside toward tank, i.e., object on the left side moving right into tank. If o.x < TANK.x, clamp only if o.x > TANK.x - o.r... Actually the clamp `o.x = TANK.x - o.r` is correct for an object on the left pressed against tank: its center must be <= TANK.x - r. If fragment center is 304 and r=4, TANK.x-r=376, so it's way left, condition o.x+o.r>TANK.x → 308>380 false. So no clamp! I misread. Condition requires o.x+r>TANK.x. 304+4=308 < 380 → false. Good. The earlier concern was wrong. 

But during transit when fragment at x=370, r=4: o.x+r=374<380 false. At x=378: 382>380 true → clamp to 376. But that's during exiting before outside set. Since exiting flag set in same call then outside check uses x<TANK.x-r=376; at x=378 not outside, next frame clamped. Hmm could get stuck. But fragments have high vx and move fast, likely jump past. Also we set exiting true and skip? No, the exterior branch only runs if o.outside. So while !outside, no exterior clamp. The inner wall check with canExit true doesn't clamp. So it passes. Once x<376 → outside. Good. The exterior clamp only in subsequent frames when outside; if outside and x<380, condition o.x+r>380 false (since x<376, x+r<380). Fine. So no issue.

For objects exiting right similarly.

Good.

Now let me also ensure that when !outside and y not in (IT,IB), e.g., object above tank top? Not possible.

Now fishAI uses waterLevel; when waterLevel drops, fish near surface might be above water and get gravity. Fine.

Let me write final code.

I also want the toy to be visually a rubber duck or ball. I'll draw a ball with a little duck-ish shape? Keep a ball with a highlight and maybe a duck silhouette. Simple: circle yellow with orange beak triangle. Cute.

Rocks: irregular polygons, gray.

Fish: ellipse body + tail triangle, color varies.

Plants: green stalks with leaves.

Fragments: light blue polygons.

Let me write.

I'll now write the entire file.

For fish colors, assign random hue per fish.

Let me code draw functions.

Now, about `opening()` being called many times; fine.

Let me write the script.

Let me make sure to compute `Q` before spawning jet and before object update.

Also compute currentAt uses Q.

Let me write.

Final code below. I'll write it and then test with browser.

Let me also add pointer cursor change when near wall.

Let me write the code.

I'll now create the file.

Let me run the browser and inspect initial output/console.

Initial scene looks good. Tank intact, water, fish, rocks, plants, floating toy. Now let me test the breach via the hook: set a crack and breach, then sample state over time.

Let me use browser inspect? The browser tool has actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. No direct eval. Hmm. I need to trigger breach. I can use drag to create crack then click Breach. Let me do that.

The tank left wall in canvas coords x=380. Canvas displayed at ~1200x800 mapped to stage. The screenshot is 1200x800 so 1:1. Left wall at x=380, waterline y=440, bottom interior 668. Let me drag from (380, 480) to (380, 580). Then click Breach button at approx (218,28).

Let me use drag.

Crack visible on left wall from y~480 to ~580. Breach button enabled. Now click Breach.

The breach happened; fragments visible around the opening. But I see no jet of water yet, and the water level hasn't visibly dropped in this frame. The screenshot is captured at +0ms after click, so maybe not enough time. Let me capture a motion or screenshot after some delay. The browser tool "motion" gives frames. Let me use motion.

Actually the issue: after click, only 0ms elapsed. Let me wait via motion or screenshot again. Let me take a screenshot.

Hmm. There are issues:

1. The waterline inside the tank doesn't seem to fall — it stays at y~530 (the surface). Wait, the initial waterline was 440, and after breach the water surface is at ~530 in frame 2? Actually looking at frame 2, the surface is around y=520. Initial was 440. So it dropped. Good. But by frame 4 (1.9s) it's around y=530, only slightly lower. Hmm, actually the water level should drop faster. Let me check: crack was y1=480,y2=580. Wait drag from 480 to 580. But looking at screenshot, the crack appears to be around y=480-580, and the water surface dropped to ~525. When surface reaches 580 (opening bottom), flow stops. So water stops at ~580. But in frame 2 the surface looks ~520, frame 4 ~530. It's slowly approaching 580? That seems slow.

Wait, actually the water volume calculation: Q = 14 * sub * sqrt(head+4). At waterLevel=440, opening y1=480,y2=580. sub = min(668,580)-max(440,480)=580-480=100. head = (480+580)/2 - 440 = 530-440=90. sqrt(94)=9.7. Q=14*100*9.7=13580. dLevel = 13580/416 = 32.6 px/s. So in 2s should drop ~65px to 505. Hmm frame 4 at 1.9s shows ~530, so dropped only 90? Wait initial 440, now 530 = 90px in 1.9s = 47px/s. Close-ish. Actually as it drops, sub stays 100 until waterLevel passes 480, then sub decreases. At waterLevel=530, sub=580-530=50, head=530-530=0 → sqrt(4)=2, Q=14*50*2=1400, dLevel=3.4 px/s. So it slows dramatically near the opening center, and effectively stops when surface reaches ~580.

Wait but head is computed as center - waterLevel. At waterLevel=530 (center), head=0. So flow nearly stops at surface=530, not 580. Hmm. That's because head→0 at center. That means water stops flowing when surface reaches opening center, leaving lower half of opening submerged but no head? Actually physically head should be measured from water surface to the opening, and the flow should continue while water is above the opening bottom. Using head=0 at center is wrong; the pressure head varies over the opening. But "outflow weakens as the water level approaches the opening and stops when water no longer reaches it" — our behavior stops around center, a bit early but arguably "approaches". 

Actually the requirement says stops when water no longer reaches it. Our Q→0 at center, which is before it stops reaching (bottom). Let me improve: use head based on top of opening (the highest submerged point) or use head = waterLevel to opening bottom? Better: head = max(0, waterLevel ... ) hmm.

Actually a cleaner model: flow ∝ integral over submerged opening of sqrt(2g*depth). Approximate by using depth at the centroid of the submerged portion. The submerged portion spans from waterLevel (if above y1) to y2 (or IB). Its centroid depth = (waterLevel + min(y2,IB))/2 - waterLevel = (min(y2,IB) - waterLevel)/2. So head = (bot - waterLevel)/2 where bot = min(y2,IB). Then head→0 only when waterLevel reaches bot. That matches "stops when water no longer reaches it."

And sub = bot - max(waterLevel,y1). Let me use head = max(0, (bot - waterLevel)/2). Actually when waterLevel below y1 (surface within opening), bot-waterLevel is still positive until bot. And sub = bot - waterLevel in that case. Good.

Let me change computeQ: head = max(0, (bot - waterLevel)*0.5). Then Q = FLOW_C * sub * sqrt(head+4).

At waterLevel=440: bot=580, head=(580-440)/2=70, sqrt(74)=8.6, sub=100, Q=14*100*8.6=12040. Good. At waterLevel=570: head=5, sqrt9=3, sub=10, Q=420. At 580: head=0, sub=0, stop. 

2. Bigger issue: The puddle forms a tall triangular pile against the tank's left exterior rather than spreading flat. It looks like a sand dune. The puddle height field at the left region is blocked at x in [380,820]. The water exits at x=392 and lands... wait, jet spawns at o.x=IL=392. But puddle columns from 380 to 820 are blocked! So addPuddle redirects to nearest free column. Nearest free to i for x=392: x=392 is blocked (since 380<392<820). Nearest free column is at x just below 380, i.e., around 377. So all water deposits at the left edge of the free region (right against the tank). Then puddle flows left but slowly. It forms a tall pile near the tank. That's the dune shape.

The problem: the opening is at IL=392, but the tank outer wall is at 380. Water exiting the opening falls right next to the tank at x~380. The puddle free region is x<380. So deposition at 377 is correct-ish, but the puddle flow rate is too slow relative to deposit rate, causing a tall pile. Also the pile height 200+ looks like a dune.

Actually more fundamentally, water falling from the opening at x=392 would fall along the tank wall (x=380) to the floor. So a pile against the wall is physically plausible, but water should spread out and level off. The flow factor 0.22 with 3 iterations should spread. But the deposit is concentrated at one column every frame, and flow spreads ~. Let me increase flow iterations/rate and widen deposit distribution.

Also the puddle surface appears smooth/curved, actually it looks like a nice dune. But it should be more level. Let me improve puddle spreading: use more iterations (say 6) and larger factor, and distribute deposited volume over a few columns. Also the blocked region: the tank is on the floor, so water can't go under it, correct. But the left region width is only 360px, and total water 132288 → depth 367. So the puddle will eventually be ~367 tall. Currently the pile is ~220 at the wall and tapering. It needs to spread to fill the left region at ~367 uniform. That's a lot. Actually 367 tall means surface y=313, near tank top. That's a huge flood. The screenshot shows the pile reaching y~420 at wall. It's still filling.

Hmm, maybe the water volume is too large for the room. It will look like the room floods to 367px depth on the left side, which is half the room height. That's dramatic but maybe okay. But the "dune" look is because spread is slow.

Actually, wait: the puddle is only on the left side because the tank blocks the middle. The right side gets nothing (opening on left). So all 132288 volume goes to the 360px left region → 367px depth. That's a wall of water. It's fine physically (a flooded room), but visually a 367px deep puddle is a lot. Let me reduce water volume to make it more reasonable. Options: reduce tank width or water depth. Let's reduce tank interior width and initial water depth.

Current tank interior width 416, water depth 228 (440..668) → 94848... wait 416*228=94848. Hmm earlier I said 132288 with depth 318 but INIT_LEVEL=440 gives depth 668-440=228. So volume=94848. Left region 360 wide → depth 263. Surface y=417. That's more reasonable. The screenshot pile reaches ~420 at wall, consistent with 260 depth. So total ~263. Good, that's actually correct! The pile at the wall is ~260 and tapers to 0 at far left — it just hasn't spread fully. It will eventually level to 263 across.

So the main fix is faster spreading. Let me increase iterations to 8 and factor to 0.3. But careful with stability. The flow factor f=d*0.3; with many columns this is a diffusion; stability requires factor <= 0.5. 0.3 fine. 8 iterations per frame at 120Hz physics... that's 8*194 = 1552 ops per step, 120 steps/s = 186k/s. Fine.

Actually step runs at FIXED=1/120, so updatePuddle called 120/s. 3 iterations each. Let me bump to 6.

3. The jet: I don't see a clear water jet in the frames. There are a few particles near the opening. The jet seems weak/short. Looking at frame 2, near the opening there's a small cluster of light dots. The jet should arc out. The particles spawn with vx=-80..-190, then gravity. They should arc. But they deposit quickly into the puddle which is high near the wall (the pile), so they hit the puddle surface almost immediately. As the pile grows, particles land right away. That's why no visible arc.

To show a gravity-curved jet, the puddle near the wall should be lower, or particles should be spawned with more horizontal velocity so they arc over. Also the jet is drawn behind the tank frame? No, drawJet after objects, before frame. It's visible.

Let me increase jet speed and reduce deposit concentration. Also the puddle pile should spread. With better spreading, the near-wall puddle is lower and the jet arcs further.

Actually the jet particles travel from x=392 leftward; puddle surface near x=380 is high, so they hit quickly. But there's the tank wall region x 380-392 blocked, so puddleAt returns 0 for x in blocked → surf=FLOOR=680. So particles over blocked region fall to floor. They only deposit when they cross x<380. With vx~-100, crossing 12px takes 0.12s, then they're at x<380 where puddle is high. So they arc a little.

Let me increase initial vx to 120-260 and reduce puddle pile. Also maybe the opening x for left should be TANK.x (outer) rather than IL, so particles start at the outer wall and deposit into free region immediately. Actually visually the jet should emanate from the crack on the wall. The crack is on the glass at x=380..392. Fine.

Let me improve:
- computeQ head fix.
- puddle spreading more iterations.
- distribute deposited volume over a Gaussian width.
- increase jet speed.

4. The waterline fall: currently after ~2s only dropped ~90px. With the head fix, it'll drop faster and continue to ~580. Let me verify with a longer observation.

Also I notice the fish seem to have moved toward the opening (frame 3 fish near left). Good, current response.

5. Fragments: visible as white shards at bottom left. They fell to the floor. Good. They rotated.

Let me also check the right side crack maybe.

Let me make the fixes.

Also potential issue: puddle flow skips blocked columns, creating a discontinuity; that's fine.

Another issue: the puddle rendering has a vertical step at the blocked boundary, showing a wall of water at x=380. That's the pile.

Let me implement improvements.

For addPuddle distribution:
```
function addPuddle(x,vol){
  let i = clamp(...);
  if(BLOCKED[i]) i=NEAREST[i];
  // spread over 3 columns
  const spread=[0.25,0.5,0.25];
  for(let k=-1;k<=1;k++){
    let j=clamp(i+k,0,PNC-1);
    if(BLOCKED[j]) j=NEAREST[j];
    puddleH[j]+=vol*spread[k+1]/PCOL;
  }
}
```
Good.

Puddle flow: increase iterations to 5 and factor 0.3.

Jet speed: speed = 130 + random*130 + Q*0.002.

Also to make the jet arc nicely, spawn at o.x with dir. Fine.

Let me also reduce FLOW_C? No, keep.

Let me also consider: when waterLevel is high and opening deep, jet is strong. Good.

Let me apply edits.

Also the "head" fix.

Let me edit computeQ and updatePuddle and spawnJet and addPuddle.

Now reload and test again. Reset then set crack and breach.

Let me reload, then use the JS hook? I can't eval. But I can drag and click again.

Actually I can reload, then drag on left wall, click breach, then motion.

Let me do reload then drag.

Reset works. Now drag crack and breach. Let me drag on left wall from 480 to 580 again.

Now the jet is visible as a cloud of particles arcing out. But it still looks like a blob near the opening rather than a smooth jet arc. The particles seem to be spawned in a dense cloud and fall. Actually the motion frames show a spray cloud. It's acceptable but I'd like a clearer arc. The issue is the puddle near the tank is already high (~200), so particles hit quickly. Also the jet cloud is very dense near the opening.

Hmm wait — the puddle surface at x~380 is now high, so particles land quickly. The jet arcs over but the puddle is high. The overall scene: waterline dropped to ~510 by frame 4 (1.75s) from 440 = 70px. Good.

But the puddle still forms a big pile at the wall and doesn't level. It's spreading but the near-wall height ~230 vs far ~30. The total is 263, so it should eventually level to 263. The diffusion is still slow relative to the concentrated deposit. Actually now with 6 iterations it should be faster. In the frames, the pile at wall ~230 and at far left ~30, over 360px. Diffusion time ~ L²/D. With factor 0.3 per iteration, D~0.3, 6 iters/frame at 120fps = 720 iterations/s → D_eff=0.3*720=216 px²/s? Actually each iteration is a diffusion step with coefficient 0.3 in units of columns². Over 1.75s, 1260 iterations, diffusion length ~ sqrt(0.3*1260)=19 columns = 116px. So it's only spread 116px. Needs ~360px → ~10x more time (~10s). So it will level over ~15s. That's okay-ish but visually the pile is prominent.

To speed up, I could increase iterations, but that's compute. Or increase factor to 0.45 and iterations to 8. Let's do factor 0.4, 8 iterations → D_eff = 0.4*960=384. length sqrt(0.4*1260*? )... per second iterations=8*120=960, over 1.75s=1680, length=sqrt(0.4*1680)=26 cols=156px. Better.

Actually simpler: reduce the deposit concentration further (spread over 5 columns) and make the initial jet velocity higher so particles land farther from the wall. With vx ~200, from x=392 to landing at puddle surface... they arc maybe 100px left. Good.

Let me increase spread width and iterations. Also the puddle pile will remain tall because volume is large. Physically correct though.

Actually, maybe reduce the water volume so the flood isn't so deep. The room flooding to 263px on one side is a lot. Let me reduce tank interior width or water depth. If I set INIT_LEVEL=490 (depth 178), volume=416*178=74048, /360=206. Still deep. If depth 150: 62400/360=173. Hmm.

Alternatively make the room floor area on each side larger by shrinking the tank. But tank is 440 wide; room 1160. Left region 360. If tank narrower (say 360), left region 420+ and right 420. Volume with width 336 and depth 200 = 67200 /420 = 160. Better.

But changing tank geometry affects layout. It's fine. Let me shrink tank to w=380: TANK.x=410, w=380 → interior 422..788 (366 wide). Left region 20..410 = 390, right 810..1180=370. Water depth: INIT_LEVEL=460, IB=668 → 208. Volume=366*208=76128 /390=195. Surface y=485. Reasonable.

Hmm, this is a fair amount of re-tuning. The current look is actually acceptable — a dramatic flood. The requirement just says puddle constrained by floor and walls. It is. I'll keep geometry but improve spread.

Let me not over-engineer. The main remaining concern: does the jet visibly curve downward? The particles do arc (spawn horizontal, gravity pulls down). In the frames, the cloud near the opening has an arc shape. Good enough.

Let me increase spread and iterations a bit, then do a final check: reset restores intact state, water stops flowing when level drops below opening.

Also I should verify that after a long time water stops and puddle settles. Let me do a longer observation. The motion only gives ~2s. I can call motion multiple times.

Let me also double check: the water inside the tank should stop draining when waterLevel passes 580. The crack is 480-580. At frame 4 (1.75s) waterLevel ~510. It'll reach 580 in a few more seconds.

Let me improve spread then run a longer test.

Edit: spread [0.1,0.2,0.4,0.2,0.1], iterations 8, factor 0.4.

Also I realize a subtle issue: the puddle flow skips blocked pairs, so the boundary columns at i where BLOCKED[i+1] are not connected to the blocked region (correct). But the deposit redirect for blocked columns maps to NEAREST which is the same boundary column for all blocked x near the tank, concentrating. That's fine.

Let me apply.

Now reload, reset test, and a longer breach. Let me reload and set crack/breach again, then run several motion calls to observe ~8s.

Actually, to speed up testing, I could use the exposed hook but I can't eval. Let me just do the drag/click again.

Let me reload.

Let me create a crack and breach, then run several motions to observe ~8 seconds and confirm water stops and puddle levels.

To save time, let me use a smaller crack lower down, e.g. 520-600, so water stops at 600 quickly. Actually I want to see the arc. Let me use 470-570.

Drag then click then multiple motion calls.

The waterline is dropping: frame2 ~495, frame3 ~505, frame4 ~515. It's approaching the opening bottom 575. The puddle is spreading and leveling more now (frame 4 surface is fairly level ~600 at wall to ~630 far). Good.

The jet is a spray cloud arcing out and down. It's a bit blobby but clearly gravity-curved (particles go out then down). Acceptable.

Let me run more motion to confirm water stops and check objects (toy floating, fish, rocks). Also confirm puddle spreads across floor. Let me do another motion.

Now over ~3.6s more, the waterline has dropped to ~545 and the jet is weakening (fewer particles). The puddle has leveled nicely to ~150 deep on the left, spreading to the left wall. Good. Waterline approaches opening bottom 575.

Observations:
- Toy floats at waterline, follows it down. Good.
- Fish: several near left/opening. Some may have been swept? I see fish still inside. The green fish near bottom right. Hmm, the small rocks near bottom left seem to have moved? The rocks at x~450,500 still there. 
- The jet is weakening and the waterline still falls.

I want to confirm water stops eventually and that objects can be carried out. Let me continue motion a couple more times. Also check the puddle reaching the left wall (it appears to reach x=20). Good, constrained by wall.

Let me do one more motion to see near-stop.

Now waterline ~550 and jet is weak/small. It will stop when level reaches ~575. The puddle has spread across the left region evenly at ~150 and reached the left wall. Good.

I notice one concern: the puddle is only on the left. Objects that get swept out land on the left floor. Fine.

The water level seems to have plateaued around 550-555 — because Q becomes tiny near the opening center? No, with the head fix Q should be nonzero until 575. At level 550, bot=575, head=(575-550)/2=12.5, sqrt(16.5)=4.06, sub=575-550=25, Q=14*25*4.06=1421, dLevel=3.4 px/s. So still falling slowly. Over the last 1.8s it dropped maybe 5px. So it's slowing dramatically. Eventually reaches 575 and stops. Fine.

But wait — the opening bottom is 575, and the crack y2 was 575. So it will stop at 575. Good.

Now, one issue: the waterline is falling but the jet is very weak. That's expected as water approaches opening. Good.

Now let me verify Reset returns to intact initial state. Click Reset.

Also I should verify objects swept out. I haven't clearly seen any fish/toy exit. The toy is still at the waterline inside. Fish are inside. Given the opening is 105px tall (470-575), the toy (r15, needs 30) fits and fish (r10) fit. But the current maybe not strong enough to carry them out, or they swim against it. The requirement says "fish initially swim against the current before some are swept through the breach" and "movable objects that fit the opening can be carried out". It's okay if it takes longer, but let me check if the toy ever exits. The toy floats at the surface; as water level drops to ~575, the toy is at surface ~560, which is within the opening (470-575). The current pushes it toward opening. Toy density 0.28 → current steering k = 1.4/0.28 = 5 capped at 4. So it's very responsive to current and should drift toward the opening. But it's at x=600, far from opening (392). The current magnitude falls with distance. It may drift slowly.

Let me wait more. Actually the water flow will stop soon, so objects won't be carried. Hmm. Maybe I should increase current reach/strength so the toy drifts. Let me check: currentAt mag = 150 * clamp(Q/9000,0,1.5) * 1/(1+d/200). At Q~1400, clamp=0.156, mag=150*0.156/(1+d/200). At d=200, mag=23.4/2=11.7. That's weak. Toy vx approaches current ~11 px/s. Over 10s → 110px. Not enough to reach opening from x=600 (208px away).

But earlier when Q was large (12000), clamp=1.33, mag=200/(1+d/200); at d=200 → 100 px/s. Toy would move. But the toy is buoyant and floats; current steering for toy is strong. Yet in the screenshots the toy stayed near center. Hmm, why? Because the current direction is from toy toward opening, which for toy at x=600 and opening at x=392 is leftward. It should drift left. But the toy also has fish AI? No. Maybe the drag reduces. Let me check: current steering applied as o.vx += (cur.x - o.vx)*k*dt with k up to 4. So vx approaches cur.x ~ 100. Over 2s moves 200px. But screenshots show toy roughly at x=600 still. Wait, in frame 4 of the last motion, the toy is at ~600. Hmm.

Oh! The currentAt requires `x > IL && x < IR && y > waterLevel && y < IB`. The toy center y = surf - 0.5r ≈ waterLevel - 7, which is ABOVE waterLevel (y < waterLevel). So currentAt returns 0! The toy floats at the surface, just above waterline, so it gets no current. That's why it doesn't drift.

I should make the current field apply near/at the surface too, or lower the toy so it's submerged. Physically a floating object is pushed by surface currents. Let me adjust currentAt to include a small band above the waterline, e.g. y > waterLevel - 20. Or better, check `y > waterLevel - o.r`. Simpler: change condition to y > waterLevel - 15.

But currentAt is generic. Let me just allow y > waterLevel - 18.

Also for the toy, maybe reduce its buoyancy so it sits lower (density 0.4). Let's set toy density 0.45, so equilibrium fraction 0.45, center = surf - r + 0.9r = surf - 0.1r, still near surface. Hmm. Equilibrium submerged fraction = density = 0.45, so submerged depth = 0.9r, center y = surf - r + 0.9r = surf - 0.1r. Still slightly above. With band -18 it's covered.

Let me change currentAt threshold to `y > waterLevel - 20`.

Also increase current strength a bit and range so objects further away respond. Let me change mag formula: 150 * clamp(Q/9000,0,1.5) * (1/(1+d/260)). And maybe base 170.

Also, I want some fish to be swept. Fish swim against current with force tx -= cur.x*1.8. If current mag > ~ swim force, they get pushed. Fish swim ~90. cur.x up to ~200 at high Q near opening. So near opening fish get swept. Far fish swim normally. Good.

But the toy needs to reach the opening. With band fix, toy at x=600, Q high initially. cur.x at d=208: 150*1.33/(1+208/260)=200/1.8=111 px/s leftward. Toy vx approaches 111, moves ~200px in 2s. But it also might be slowed by... nothing else. So toy should drift to opening and exit within a few seconds. In previous screenshots toy didn't move, confirming band issue. Let me fix.

Let me also verify the toy doesn't get stuck at the wall: it floats at surface; as water level drops below opening bottom, current stops. If toy reaches opening before, it exits.

Also there's a subtlety: once the toy is at the opening (x near IL) and floating at surface, canExit requires o.y between y1+0.4r and y2-0.4r. Toy y ~ waterLevel-7. At waterLevel 500, opening 470-575, y=493 → within. Fits. So exits.

Let me apply the currentAt fix and bump strength.

Also, I want to make the water jet more visually continuous. It's a spray of dots. Maybe draw connecting segments? It's okay.

Another issue: the waterline surface inside the tank is drawn only when waterLevel < IB. Good.

Let me apply the current fix and toy density.

Also "plants bend or drift": plants bend. Good.

Let me make the edits.

Now reload and test: reset, crack, breach, observe a few seconds to see toy drift and maybe exit.

Let me reload.

Now drag a crack that fits the toy. Opening 470-575 gives 105px, toy fits. Let me use a bigger opening: 465-590. Drag from 465 to 590.

Then breach and observe.

Now the toy is drifting left toward the opening (frame 2 at x~455, frame 3 at ~440, frame 4 at ~410). It's being carried by the current. Good. The fish also moved left and are bunching near the opening. Great — the current response is visible.

The toy at frame 4 is at x~410, approaching the opening at IL=392. It should exit soon. Let me run one more motion to see it exit and land in puddle.

Also note the toy is now floating at the waterline which has dropped to ~530. Opening 465-595. Toy y ~520, within. Fits (r15, needs 30 < 130*0.92). So it should exit.

Let me motion again.

The toy has reached the opening (x~400) and is sitting right at the wall in the opening. It's not exiting though. Why? It's at x~398, and the opening inner wall is at IL=392. The toy is floating at the waterline. canExit requires o.y between y1+0.4r and y2-0.4r. Waterline ~520, opening 465-595. y=~513 (toy center = surf-0.1r ≈ 520-1.5=518.5). Within. Fits. So canExit true when o.x-o.r < IL → 398-15=383 < 392, yes. So exiting=true. Then it should move out. But its vx is small and current pushes it. It seems stuck at the boundary.

Wait, maybe the toy is resting against the inner wall because the current isn't strong enough to push it fully out, and the tank wall check: if canExit true, no clamp, so it can move. But it's floating and current at x near IL: currentAt requires x>IL, so at x=398>392, yes. Direction toward opening (left). mag at d small (opening center x=392, y=530; toy at 398,518, d~14) → mag=170*clamp(Q/9000)*1/(1+14/280) ≈ 170*0.1*0.95 ≈ 16. Weak because Q is small now. So toy barely moves.

The water level is now ~520 and dropping; Q small. So toy is stuck near the opening but current too weak to push it through. Hmm.

In the frames, the toy stays at x~398. It's touching the opening. To make objects actually get carried out, I could reduce the tank wall resistance or give the toy a nudge when exiting. Or increase current near the opening. The current is strongest near the opening (1/(1+d/280)) but Q is small late.

Earlier, when Q was high, the toy was moving but from far away. By the time it reached the opening, Q had dropped. Maybe increase the toy's drift earlier by making the current stronger overall, or start the toy closer.

Alternatively, the requirement says "Movable objects that fit the opening can be carried out by the flow" — this is a capability. We demonstrated the toy drifting to the opening. It's plausibly stuck due to weakening flow. But ideally at least some object exits.

Let me increase current strength and reduce the head loss so Q stays higher longer, and maybe give exiting objects a small outward impulse when they pass the inner wall.

Actually a cleaner fix: when an object is within the opening and canExit, add a strong outward "push" (the flow through the opening) proportional to Q. That's physically sensible — flow velocity through the aperture. Let me add in updateObj: if !outside and canExit(o, side) and Q>0, add outward acceleration.

Actually simpler: in currentAt, when very close to opening, boost. But currentAt only for tank water x in (IL,IR). Let me add in updateObj after current:
```
if(!o.outside && breached && crack){
  const side=crack.side;
  const nearWall = side==='left' ? o.x < IL+o.r*2.2 : o.x > IR-o.r*2.2;
  if(nearWall && canExit(o,side) && Q>200){
    const dir = side==='left'?-1:1;
    o.vx += dir*260*dt;   // flow acceleration through aperture
  }
}
```
That will push fitting objects out. For rocks that don't fit, canExit false, so they stay. Good. For fish, they'd get pushed but also swim; some escape. Good.

Let me add that. Also increase current base a bit.

Let me also reconsider: the toy is currently at the opening with Q~? At level 520, bot=595, head=(595-520)/2=37.5, sqrt=41.5, sub=75, Q=14*75*41.5=43575?? Wait that's huge. Hmm, that contradicts. Let me recompute: sub = min(IB,y2)-max(level,y1) = min(668,595)-max(520,465)=595-520=75. head=(bot-level)/2=(595-520)/2=37.5. sqrt(41.5)=6.44. Q=14*75*6.44=6762. dLevel=6762/416=16.3 px/s. So Q is still substantial. Then current mag = 170*clamp(6762/9000,0,1.5)=170*0.75=128, *0.95=121. That's strong. So why isn't the toy moving out?

Wait, the toy in frame 4 is at x~398. Its vx should be ~ -121. But maybe the buoyancy/floating means it's at the surface and currentAt requires y > waterLevel-22. Toy y=518, waterLevel=520 → 518 > 498 true. So current applies. Hmm.

Maybe the toy is colliding with the tank wall from the outside? No, outside=false.

Wait, maybe canExit returns false because of the fits check: o.r*2=30 > oo.h*0.92. oo.h=595-465=130, *0.92=119.6. 30<119.6 true. withinY: o.y > y1+0.4r = 465+6=471, and o.y < y2-6=589. 518 ok. So canExit true.

Then in collideWalls, `if(o.x-o.r<IL)` with canExit true → exiting=true, no clamp. So it should pass. But the toy is at x~398, o.x-o.r=383<392. So it's already past the inner wall. Then exiting=true; check `o.exiting && (o.x < TANK.x-o.r ...)` → 398 < 380-15=365? No. So not yet outside. It keeps moving left with vx=-121, should cross in 0.1s. But frames show it stuck at ~398 for 1.8s.

Unless... the toy is being pushed back right by something. What could push it right? The buoyancy is vertical. The current is left. Hmm. Oh! The `collideWalls` exterior branch doesn't apply. 

Wait, maybe the toy's x isn't 398. Let me look more carefully. In frame 1 the toy is at ~400. Actually maybe it IS exiting but the rendering... no.

Let me reconsider: maybe the toy is not at 398 but at ~400 and the waterline dropped so the toy is now above the opening top? No, opening top 465, toy at 518.

Hold on — could `canExit` be false because `breached` and `crack.side` — crack.side is 'left'. yes.

Hmm, maybe the issue is the toy is oscillating: current pushes left, it enters the wall region, but then the `if(o.y+o.r>IB)` etc. no. 

Actually wait: maybe the toy is blocked by the crack's jagged edge rendering only, not physics. Let me check the actual x by reading the state. I can't eval directly... but the browser inspect action might give DOM only. Hmm.

Let me think about the currentAt direction. The opening center is at (392, 530). The toy at (400, 518). dx = 392-400 = -8, dy = 530-518=12. Normalized: dx=-0.55, dy=0.83. So current.x = -0.55*121 = -66, current.y = 0.83*121*0.45=45 downward. So the toy is pushed left and DOWN. Downward current pushes it below the surface, buoyancy pushes it back up. Net horizontal -66. Should still move left.

But the toy might be getting pushed down and then the currentAt y condition... no.

Actually, maybe the toy has already exited and what I see at x~400 is the toy in the puddle? No, it's at the waterline inside.

Let me look again at the last frame: the toy (orange circle) is at x≈400, y≈565? Actually in frame 4 the toy is at roughly x=400, y=565. The waterline is at ~570. Hmm the toy is lower now. Opening bottom 595. Still within.

I think the toy might be oscillating at the lip because the current has a downward component and the buoyancy creates a spring, and the horizontal push is balanced by... Actually, there might be a bug: once `exiting=true`, the code in collideWalls still runs the inner-wall `if(o.x-o.r<IL)` branch which sets exiting=true again (fine). But also the top/bottom checks. Fine.

Wait — is `o.outside` ever set? Condition `o.x < TANK.x-o.r` = 365. The toy needs to reach x<365. It's at 398. With vx=-66, it should get there in 0.5s. Unless the current reverses. Hmm.

OH. I bet the issue is that as the toy moves left and down, it goes below waterLevel? No, below means y increases, still > waterLevel, fine.

Let me just add the aperture push and also reduce the toy radius so it fits more easily. And add debug via the exposed hook? I can't call it.

Actually, wait. Let me reconsider the rendering: maybe the toy IS at x=400 because the current pushes it left but the fish AI? No, toy has no AI. 

Let me check: could the toy be colliding with the tank's exterior because `o.outside` became true prematurely? If outside=true and o.x=398 (<TANK.x=380? no, 398>380). The exterior branch: o.x < TANK.x && o.x+o.r>TANK.x → 398<380 false. o.x > TANK.x+TANK.w? no. So nothing.

Hmm. Let me just add the aperture acceleration; that will definitely push it through. Also I'll widen the opening test. Let me implement and test.

Actually, I realize the likely culprit: the toy floats such that its center is slightly ABOVE the waterline. currentAt allows y > waterLevel-22. But as the toy gets pushed down by the downward current component, buoyancy pushes it back. The net vertical could cause it to bob. Horizontal current -66. But also, the toy's `waterInfo` fraction and buoyancy... 

Wait, maybe the toy's horizontal velocity is being killed by drag? In water, drag dk=4.5. The current steering term: o.vx += (cur.x - o.vx)*k*dt with k=4. This drives vx→cur.x=-66. Drag also -vx*4.5. Combined, equilibrium: the steering adds (cur.x-vx)*4 and drag -vx*4.5 → 0 = (cur.x-vx)*4 - vx*4.5 → 4cur.x = 8.5 vx → vx=0.47*cur.x = -31. So horizontal velocity ~-31. Still should move.

Unless the toy is at the wall lip where the current direction points more downward than left, so horizontal is small. As toy gets to x=398, dx=-6,dy=12 → mostly down. So current.x ~ -0.45*121=-54... 

Hmm I'm not sure. Let me just add the aperture push to guarantee escape, and also add a small outward push in currentAt when close to the wall.

Let me implement in updateObj:
```
if(!o.outside && breached && crack && Q>150){
  const side = crack.side;
  const dir = side==='left'?-1:1;
  const distToWall = side==='left' ? (o.x - IL) : (IR - o.x);
  if(distToWall < o.r*2.5 && canExit(o,side)){
    o.vx += dir*(200 + Math.min(400,Q*0.05))*dt;
  }
}
```
This gives ~200-600 accel; over 0.5s vx gains 100-300 leftward. Should push it out.

Let me add.

Also for fish being swept: this helps.

Let me also make the toy start a bit closer, x=560, so it reaches earlier. Not necessary.

Let me add the aperture push.

Now reload, test again, and verify reset. Let me reload and do the drag/breach, then motion twice.

Actually, time budget. Let me be efficient. Reload, drag, click, motion, motion. Then reset check.

Let me reload.

Now the toy is at the opening lip (x~340 in frame 4, which is outside IL=392, actually left of the tank exterior 380!). In frame 4 the toy is at x~340, which is outside the tank and now in the puddle region, floating on the puddle at y~545. The puddle surface there is ~545. So the toy successfully exited and is now floating on the puddle! 

Also fish are bunching near the opening on the left. Good.

Wait, frame 4: the toy (orange) at x~340, y~545. Yes it's out, on the puddle. 

Now the fish: two fish at the right edge (pink at x~795) seem stuck against the right wall? That's fine, they're swimming. Actually fish at right edge appear to be pressed against the right wall — maybe the current is pushing them? Current pushes toward opening (left), so they should move left. Hmm, but those fish are at the right; they might just be avoiding the left wall. Actually wait, the fish at right edge look like they're vertically stacked at the wall. Could be they swam there. Fine.

Now let me verify Reset. Click Reset.

Also I should double check that water stops flowing. Let me first click Reset to verify, then maybe do a longer run. Actually let me check water stops by continuing motion once more, then reset.

Let me do one more motion to confirm water stops and toy floats on puddle, then reset.

Time budget: I've used a fair amount. Let me be efficient: click Reset and screenshot, confirm intact. Then one final check perhaps.

Actually the reset is the key remaining verification. Let me click Reset.

Reset restored the intact tank: full water level, toy floating, fish, rocks, plants, no puddle, no crack, Breach disabled, hint reset. 

Now let me confirm water stops flowing when the level drops below the opening. Let me do a quick run with a lower opening so it stops quickly. Actually I already saw the jet weaken. Let me do a final quick check: set a crack low (e.g., 620-660) so it drains fast to the opening and stops. But time.

Actually I'm fairly confident. Let me do one more motion check to confirm no runtime errors and that things settle. But the reset check already shows no console errors (only the sandbox warning).

Let me verify the right-side crack works too, briefly. Actually the requirement says "one side" — left works. Right likely works symmetric.

Let me do a quick test of the right side: drag on right wall. Right wall inner IR=808, outer 820. Drag from (820,470) to (820,570). Then breach. But that costs time. Given left works, right should be symmetric. I'll skip.

One more concern: the water level should stop when it no longer reaches the opening. Let me quickly verify with a motion after a breach on a low opening. Actually let me just do a final run: drag low crack 600-660, breach, wait, and check jet stops. But time budget ~ maybe 4 min used. Let me do it quickly.

Actually, I'm at a good point. Let me verify the water stopping behavior to be thorough since it's a required behavior. Let me drag crack at 600-660 (below water 440), breach, and run two motions. Water should drop to 660 and stop; the jet should cease.

Let me do it.

The crack is drawn at y~600-662 on the left wall. Wait, in the screenshot the crack appears around y=600-660, near the bottom. Good. The hint says "Crack set on the left wall — press Breach". 

Now click Breach and run two motions.

The water drained completely to the opening level (surface at ~645, opening bottom 662). The toy was carried out and floats on the puddle. A fish (red) also escaped to the left and is in the puddle. Fish inside are swimming in the shallow remaining water. The jet has stopped (no particles). Fragments on the floor. 

This confirms:
- Water stops when it no longer reaches the opening. ✓
- Toy and a fish were carried out. ✓
- Puddle constrained by floor and walls. ✓

The remaining water inside is shallow (below opening). Good.

Everything looks good. The only minor visual issue: the water inside the tank at the very bottom shows a wave line; fine.

Let me do a final reset to leave the app in initial state? Not required, but the final file is what matters. The file is saved.

Let me do a final check of the file for any obvious issues (e.g., the `drawJaggedEdge` uses rand each frame which causes flickering jagged edges — minor). Actually `drawJaggedEdge` calls rand() every frame, so the broken edges jitter. That's a small visual artifact. Also `buildJags` used for the pre-breach crack is deterministic (stored), good. The post-breach jagged edge jitters. Let me fix by precomputing the jagged edges when breached. Minor but easy.

Actually, let me leave it — it might look like shimmering glass, arguably fine. But flickering every frame at 120fps could look like noise. Let me fix quickly by caching.

I'll add a `brokenEdges` array computed in doBreach. But simpler: make drawJaggedEdge use a deterministic pattern based on index and crack coords (no rand). Let me replace rand with a sine-based pseudo-random.

In drawJaggedEdge:
```
const yy = y + dir*(Math.sin(t*Math.PI)*7 + Math.abs(Math.sin(i*12.9898 + y))*3);
```
That's deterministic. Let me edit.

Also drawCrackLine uses rand for branches each frame while dragging — that flickers too. The branches are drawn from c.jags with rand offsets. Let me precompute branch offsets in makeCrack. Or use deterministic. Let me make it deterministic with sin.

Let me fix both for polish.

Also, the crack's jags are rebuilt on every pointermove (makeCrack called each move), so while dragging the crack jitters — that's actually fine/expected for a drag.

Let me make the branch and jagged edge deterministic.

Edit drawJaggedEdge and drawCrackLine.

Let me do a final reload and confirm no console errors and initial render still fine.

Everything works. The file is saved at /tmp/job-xyAVqC/index.html. No console errors (only the sandbox warning which is from the test harness).

Let me write a brief report.

Actually let me double check the file exists and is complete.