Aquarium breach · step-5-preview

Let me build an interactive aquarium breach simulation. This is a big single-file HTML with canvas. Let me plan the design.

Key requirements:
1. Canvas 2D aquarium.
2. Initial scene: intact glass tank with water, fish, rocks, plants, floating toy. User drags a visible crack vertically on one side below the initial waterline, then press Breach. Reset button.
3. On Breach: panel breaks around the selected opening (show a hole/gap in the glass). Water exits in a gravity-affected jet. Waterline falls continuously. Outflow weakens as water level approaches the opening and stops when water no longer reaches it.
4. Escaped water forms a spreading puddle constrained by floor and room walls.
5. Distinct behaviors for buoyancy, drag, current:
   - rocks sink
   - toy floats
   - plants bend
   - fish swim against the current
6. Objects leaving the water transition to gravity-driven motion and collide with the floor.
7. Glass fragments rotate, collide, and experience resistance in water.

Plus a velocity-based jet on the outside puddle that spreads but is constrained by walls.

Animation/update loop for objects in air too: they should follow projectiles and land.

Let me write the code carefully.

Design ~900 lines of JS/CSS/HTML.

Let me think through all the pieces:

### Constants / layout
- Canvas logical size W=1200, H=800.
- Room: full canvas, walls at x=0, W; floor at y=H.
- Tank: left region. Glass rect from TX0=90 to TX1=620, TY0=120 (tank top) to TY1=700 (tank bottom sits on some base). Tank wall thickness 6.
- Inside floor: at y=FLOOR=Y1. Let's set tank bottom inner y = 700, tank sits on a stand/floor at y=700? Simpler: tank bottom inner floor at y=690; the "room floor" is y=760 with sand in tank at 690.

Let's define:
- Room floor: y = 780 (bottom of canvas area).
- Tank outer: left=80, right=660, top=140, bottom=720. Inner: left+tw, etc. The tank bottom is at 720, and room floor 780 means there's a gap 780-720=60 for the puddle to spread under... Actually puddle spreads on room floor which is at y=780; tank sits on floor. Let tank bottom = 760, room floor = 760, so puddle spreads at floor level y=760 and the tank occupies above. Water splashing out lands on the floor and spreads horizontally. The tank right wall at x=660 - water piles on floor. Good.

So:
- FLOOR_Y = 760 (room floor, also tank bottom inner = 760).
- Tank: TX_L = 90, TX_R = 640, TY_T = 130 (tank top/rim), TY_B = 760 (bottom).
- Wall thickness TW = 7.
- Sand layer at bottom inside: from y=730 to 760.

### Water representation
Water is stored as a level (waterY) with flat surface. Volume check:
- filledHeight = (760 - waterY) * innerWidth. Max 630 * 543 ≈ 342k. Drain 0.35%/ms → 1200/s → to empty from 630 → 525ms? Wait 342000 * 0.0035 = 1197 px³/s → in ~285ms empty. Hmm earlier I said 525ms; recomputing: 630/1197*1000 = 526ms. Right (1197/s vs 630 depth). OK ~0.53s. Very fast. Hmm 0.0035 might be too fast. Let's use 0.0025 → 855/s → 737ms. Use 0.0028 → ~660ms. Fine, make it 0.0022 → ~1100ms, nicer. I'll pick 0.0022.

Actually "waterline falls continuously" — a couple seconds is fine. Use 0.002.

Inflow rate formula:
```
let h = clamp((BOTTOM_INNER - sim.water.y)/(BOTTOM_INNER-sim.water.surface),0,1);
let open = sim.breached;
let rate = open ? sim.water.inflow/h * 0.5 * ... 
```
Hmm, need care: inflow formula for drain below waterline. Let me define inflow = maxRate * f where f = clamp((waterY - opening.y)/spread, 0,1) * sqrt? Using sqrt((h - 0.2)/0.8)? Let's simply:
```
if(breached){ 
  const depth = clamp((sim.water.y - opening.y)/(sim.water.spread*2),0,1); // 0 at open → 1 when 2 spreads above
  const cap = opening.w ... 
  sim.water.inflow = MAXRATE * depth * cap;
}
```
Actually depth factor: linear from 0 at water==open to 1 at water==open+2*spread above (spread 50 → 100px above). Linear fine.

### Rendering order
1. Room background (walls gradient, floor plank).
2. Sand inside tank.
3. Plants (behind waterline? draw plants after water they look submerged; but plants move to sides... draw plants before water but they should be under water; it's fine because tint overlays).
Actually better order: sand, plants, rocks, glass fragments in-tank, fish, toy, then water body, then out-of-water objects (flying things), then puddle, then cracks, then smoke.

Wait—puddle should be under things landing on floor. Yes puddle after tank things. Puddle drawn at floor level; objects sitting on puddle (rocks in puddle) drawn after puddle? Objects are either inside tank or outside; outside objects rest at floorY which is same as puddle. Draw puddle first, then outside objects, fine.

But fish inside drawn before water tint (looks submerged). Since fish that escape become outOfWater and should draw after water - they're handled by the same fish array but flag. Sort: draw fish with !outOfWater before water, outOfWater after puddle. Manageable.

### Water body drawing
- Path along inner tank left/right walls from top rim down to waterY, close at waterY line. Fill with translucent blue gradient.
- Air-space above: fine.
- Refraction lines: draw a few horizontal wavy lines near surface.
- Add caustics: subtle moving sine curves.
- Damaged side glass: after drawing water body fill, fill the cracked side above the waterline with a lighter glass tint? The cracked side above water—draw a "glass shard" trapezoid to indicate the gap is empty. Actually the missing panel: when breached and waterY < opening.y + opening.h, the region inside the tank at that y-range near the right wall is open to outside — visually the water surface inside ends there. Since flat water, if waterY < opening.y+opening.h, then at the panel's vertical extent, water is either below it or above it. The gap region: draw a "hole" (dark) in the tank wall. Perhaps simply: during breach, draw a black-ish notch in the right wall spanning opening y-range with jagged edges. Simple and clear.

Also when water level is above opening, water flows through the notch; draw notch and stream starting at notch.

### Jet
Bezier + wobble. Also draw droplets. Stream drawn with lerp of widths:
```
ctx.moveTo(ox, oy-topW/2); ctx.quadraticCurveTo(mx, my-topW/2, ex, ey-endW/2) ... 
```
Draw as a filled shape: two quadratic curves forming a closed ribbon, fill light blue. Nice.

On impact at ex,ey spawn a splash of droplets upward and add puddle volume.

### Puddle
Collection of blobs: {x,y,r} base spots that spread up to target radius. Simulate: each blob grows toward targetRadius over time (ease), and blobs merge visually with metallic-ish gradient. Simpler: maintain list of "sources" (landing positions) and single puddle polygon? Let's do: puddle volume → spilled radius = sqrt(vol/π / depth?) Eh.

Simplest robust approach: puddle = set of circles; each water source adds a circle at (x, FLOOR_Y) with radius growing to Rmax; circles' growth limited by neighbors (stop when overlapping enough). Also decays when water dries? Not required to dry. Draw them all.

Volume → area: totalArea = spilled / DEPTH_PUDDLE (e.g., 8px). Distribute new area as growing radius on existing circles until sum area = budget → then new circles. I'll implement per-source: each source has targetR; Rmax = sqrt(DEPTH-based area) hmm.

Alternative cleaner: maintain `spilled` volume. Puddle is drawn as an ellipse strip: 
- puddleCenterX, puddleRightX. Let spread = width; area = spilled/6 (depth 6). If water spreads in a band of width Wb centered on impact x, then Wb = area/6? Eh messy near walls.

I'll go with blob approach; it's fine, internal consistency only needs to look plausible.

Blob update:
```
if(blob.r < blob.maxR){ blob.r += (blob.maxR-blob.r)*0.04; }
```
maxR set when created = 26; and blobs added on each splash. Additionally, when new blob added near existing, we can just add. Spread constrained: new landing x clamped to [4, W-4]; also add "slither" spreading: every so often, a blob spawns at the edge that pushes further with maxR 20 - simulates spreading within wall constraints. When hitting wall, don't spawn beyond.

Let's implement puddle as list; puddle spawn 1 blob per 8 volume; blob growth toward maxR.

Also puddle should be drawn as dark reflective with animated highlight. Fine.

### Sand
Draw wavy tan.

### Plants
Draw as N strands; each strand base at x, with segments; sway by current; if grabbed → carried.

Implementation: plant object {x, baseY(top of sand), height, segs, phase, hue, vx(actual horizontal shift of top), grabbed:false, out:false}
Update when !out and in water:
- external flow: flow = currentAt(x, plant top y) etc.
- sway = sin(t*speed + phase) * baseAmp + flowAtPlant * 4.
- velocity integrates: p.vx += (sway - p.vx)*drag.
- For drift: p.x += p.vx * dt normalized; clamp x between inner left+10 and inner right-10; base anchored.
- If grabbed: currentForce = flowFromCurrentAtPlant(p) * 22; direction sign rng; p.vx += force*dt... then out when |p.top| near wall x and water level low → flip to projectile.

Simplify plant grab: when plant's top region within capture zone (see above) and rng per frame → p.grabbed = true, p.out=false, p.vx = (flowVel.x*2, flowVel.y*0.6). In out mode treat as simple projectile with slight wobble, rotating. On landing, rest on floor/puddle (vx damped by 0.9, collision).

Then if water level drops below plant's base, plant remains standing on sand, bending less.

### Fish
{baseX, baseY, size, hue, fleeDir, targetDir, speed, wPhase, grabbed}
Update: 
- if out: projectile (vx, vy, a=-g), rotate toward velocity, flap animation stops; on hit floor → rest, wiggle on side; when landed set vx damp 0.85.
- else:
  - current = currentAt(x, y) (flow in water)
  - if !grabbed: swim: target = a direction = sum of: wander (perlin-ish via sin), avoid walls, flee from breach (if breach visible ahead — the breach is a dark/hole; fish avoid: compute distance to breach point and if near, direction away), plus current compensation: fish wants to stay put: desired = -current * K (K~40) mixed.
  Actually "swim against the current": fish orient upstream. Implement: upstream = -normalize(current). Fish velocity = upstream * speed + wander + escape. When current strong (> threshold), fish can't hold and drifts downstream toward breach.
  - acceleration toward desired heading: fish.dir += (desiredDir - fish.dir)*0.06; speed adjusts toward desiredSpeed.
  - pos += dir*speed*dt*... + current*0.35*dt (current pushes).
  - if pos within capture zone and rng → grabbed: set out=true, vx = current.x*1.8, vy=current.y*1.8.
- collision with tank bounds: bounce.

Fish shapes: body ellipse + tail triangle that wiggles; eye.

### Toy (float)
Box with stripes, floats on waterline. Draw at waterY, y=waterY-6, half-submerged. It drifts with current horizontally and rotates slightly; clamp within inner. If water drains, toy descends with waterline, ends at bottom.

### Glass fragments
When breach occurs, create ~14 shards around the opening: positions around opening, velocities outward (both into tank and out), rotation. Update: 
- If in water (inside tank and y > waterY): strong drag, slow, slight buoyant lift if above water... glass is denser than water → sinks in water: vy += g*0.25; drag heavy.
- Out of water: gravity, bounce on floor with damping, friction; collide with room walls.
- Collide with each other (simple circles) - "experience resistance in water": heavy drag when in water.
Draw as jagged triangles with cyan tint and highlight.

Also shards stay inside tank if not flung out.

### Crack UI
- Initial: show a "hint crack" at default position on right wall below waterline: e.g. y = waterY + 60, x = TX_R (right wall) → drag handle.
- Draw: dashed line with glow, a small rhombus handle at center; instructions "Drag crack" text near.
- Dragging: pointerdown near crack (within 40px of x=TX_R and ±(h/2+20)) → move along y only, clamp between waterY+30 and bottom-40; also maybe can be on left wall? Keep right wall only. Actually allow on either side? Keep right wall for simplicity but maybe allow left too — spec says "one side". Keep right.
- Crack has limited vertical length (opening.h ~ 90). The drag sets center. The panel opening = that band.
- Press Breach button or keyboard B: apply breach: create hole at (TX_R, cy) size w=holeW, h; glass fragments; water.inflow set >0.

### UI Controls
- Buttons: Breach, Reset. Also maybe "water flow" slider? Not needed. Add small readout of water level %, time.
- Style: dark background, panel top-left with buttons.

### Sizing
CSS: canvas responsive with fixed internal resolution 1200x800, scaled to fit width. Use devicePixelRatio? Keep simple: set canvas width/height attrs 1200x800, CSS width:100%, max-width 1200.

### Water level decline and stopping
- inflow>0 & breached: volume -= rate; also inflate jet when inflow high.
- If waterY <= opening.y + something → inflow = 0, jet stops; but water below opening remains, no more outflow. Also when level above opening: rate factor = f (depth). So as level approaches opening, outflow weakens (factor → 0) and stops. ✓

Also when water level < opening.y + holeH, water drains only until it reaches opening.y. So it stops naturally. ✓

### Objects remaining in tank when water low
Rocks on sand stay. Need water body to shrink. Rocks drawn after water would show above water incorrectly — draw rocks before water (they're on the sand, water covers them). ✓ Order: sand, plants, rocks, frags(in tank), fish(in), water body, toy(on surface), jet, then puddle, then out-of-water objects, cracks/smoke.

Toy must be drawn after water since it sits on surface. If out of water? Toy stays floating; when water < sand, toy sits on sand, draw after water anyway.

### verify checks
Need "sample the early outflow" — I'll add a debug readout maybe. I can expose window.__sim for console inspection. Add window.__sim = sim. Then verify via inspect.

Let me now write the file. I'll be systematic and moderately sized. Also include a requestAnimationFrame loop with fixed dt clamp.

Let me write the code.

Key physics helpers:
- currentAt(x,y): flow field inside/outside tank.
  ```
  function currentAt(x,y){
    // room current: none (still air) → zero
    if(x<TX_R) { // inside tank region
      if(sim.water.y===null || y<sim.water.y) return {x:0,y:0}; // above water
      const t = (y - sim.water.y)/(BOTTOM_INNER - sim.water.y); // 0 at surface, 1 at bottom
      return {x: FLOW_TANK.x*(0.25+0.75*t), y: 0.05};
    } else {
      return {x:0,y:0};
    }
  }
  ```
- flowVelAtPoint(x,y): integrate tank current + jet velocity at that point (piecewise quadratic from sampled arc). Use for pulling objects out. Implement with precomputed arc sample array (N=24) filled when inflow>0; velocity via derivative finite difference. Out of water: no current.

Capture zone: outside tank within x in [TX_R+4, TX_R+30] and y within [open.y-20, open.y+open.h+20], OR in-side pulling near wall. Simplified: capture zone is the "opening band" extended slightly on both sides.

Point-in-water-in-tank: inside inner rect and y>=waterY.

Let me define opening as {cx: TX_R, cy, w: 34, h: 92} set on breach from crack.

Now splash: when jet lands (impact point ~ TX_R + jetLen, FLOOR_Y), each spawn interval add puddle volume & blobs; also spawn droplets flying back (visual), and small ripple.

Also when current sweeps fish out, they follow ballistic arcs.

Let me write the code now, carefully but not overly long. I'll aim for a decent, working implementation.

One more requirement: "Objects leaving the water transition to gravity-driven motion and collide with the floor." ✓ projectile mode for fish/rocks/plants/frags.

"Glass fragments rotate, collide, and experience resistance in water." ✓

Let me write.

I'll write the HTML file with structure:

```html
<!DOCTYPE html>
<html>
<head><meta charset="utf-8"><title>Aquarium Breach</title><style>...</style></head>
<body>
<div class="wrap">
  <div class="hud">
    <div class="title">Aquarium Breach Simulation</div>
    <div class="controls">
      <button id="breach">Breach</button>
      <button id="reset">Reset</button>
      <span id="level">Water level: 100%</span>
      <span id="status">Intact</span>
    </div>
  </div>
  <canvas id="cv" width="1200" height="800"></canvas>
  <div class="hint">Drag the glowing crack on the right wall, then press Breach.</div>
</div>
<script> ... </script>
</body></html>
```

JS outline:

```js
const cv = document.getElementById('cv'), ctx = cv.getContext('2d');
const W=1200,H=800;
const FLOOR_Y=762;
const TX_L=90, TX_R=660, TY_T=120, TY_B=760, TW=7;
const BOTTOM_INNER=760, SAND_TOP=736;
const INNER_L=TX_L+TW, INNER_R=TX_R-TW;
const INNER_W=INNER_R-INNER_L;
const WATER_TOP=170, WATER_INIT=170;
const FLOW_TANK={x:4.5,y:0.4};
const HOLE_W=40, HOLE_H=104;
let rng=...;
```

Use a seeded RNG for reset determinism.

Sim object:
```js
let sim;
function makeSim(){
 const r = mulberry32(1234);
 sim={
   t:0, breached:false, breachT:0, impactT:0,
   water:{y:WATER_INIT, surface:WATER_INIT, depth:WATER_INIT, vol:null, inflow:0, spilled:0},
   crack:{cy: 430, dragging:false, alive:true},
   open:{x:TX_R,y:0,h:HOLE_H},
   objects:[], puddle:[], droplets:[], fish:[], plants:[], rocks:[], frags:[], ripples:[],
   waterInScene:true, spawnedCounts:{}
 };
 sim.water.vol = (BOTTOM_INNER-SAND_TOP)*(INNER_W) ... 
```
Hmm water fills from waterY down to BOTTOM_INNER (760) but sand occupies 736..760, so full water depth is 760-170=590. Keep water level down to 760 (below sand top? fine, waterline at bottom of tank). Let's clamp waterY min to 758.

Rocks: 5 rocks placed on sand (y base 736) sizes; density.
Plants: 4-6.
Fish: 5.
Toy: floating.

Init function builds each with deterministic-ish random via seeded rng.

Object list: I'll store all "movable" in arrays and iterate.

Let me write update functions.

```js
function update(dt){
  sim.t+=dt; sim.breachT+= sqrt(dt*0.001); // for jet strength curve? 
  const before = sim.water.y;
  updateFlow();
  updateWater(dt);
  updateObjects(dt, before);
  updatePuddle(dt);
  updateDroplets(dt);
}
```

updateFlow: 
```js
function updateFlow(){
  const before = sim.water.y, after = sim.water.y;
  const before = sim.water.y;
  // compute level drop this frame
}
```
I'll do: in updateWater compute newY and delta, then updateFlow uses that. Then objects use FLOW (current) computed from before/after. Order: 
1. compute water new level (store drop = before-after)
2. compute flow field from before→after (surface interpolated)
3. move objects with drop × flow, capture checks.

Let me code updateWater:
```js
function updateWater(dt){
  const w=sim.water;
  if(w.vol<=0){ w.inflow=0; }
  if(sim.breached && w.inflow>0){
    const d = Math.min(w.inflow*dt, w.vol);
    w.vol-=d; w.spilled+=d;
    w.level = BOTTOM_INNER - w.vol/INNER_W;
    w.depth = w.level - (INIT_LEVEL - INIT_DEPTH);
  } else { w.inflow=0; }
  // inflow update
}
```
Hmm I conflated. Let me simplify to a single scalar: level (water surface y). Volume only needed for inflow formula. Let me define:

```js
const INIT_LEVEL = 170, INIT_DEPTH = BOTTOM_INNER - INIT_LEVEL; // 590
sim.water = {level:INIT_LEVEL, depth:INIT_DEPTH, inflow:0, spilled:0};
function computeInflow(){
  if(!sim.breached) return 0;
  const o=sim.open;
  const w=sim.water;
  if(w.level <= o.y) return 0;             // no water at opening
  const h = clamp((w.level - o.y)/(INIT_DEPTH),0,1); // relative depth at opening
  return MAXRATE * h;   // linear weakening as level → oy
}
```
Where MAXRATE in px/s: initial full = INIT_DEPTH * INNER_W = 320k. say MAXRATE=5.5e5/s → drain time 0.6s. With h linearly → stops smoothly. Make MAXRATE 4e5 → 0.8s. OK.

Then:
```js
function updateWater(dt){
  const w=sim.water;
  w.inflow = computeInflow();
  const before=w.level;
  if(w.inflow>0){
    const dVol = w.inflow*dt;
    w.depth -= dVol/INNER_W;
    w.level = BOTTOM_INNER - w.depth;
    if(w.depth<=0){w.depth=0;w.level=BOTTOM_INNER;w.inflow=0;}
  }
  // spawn splash/puddle
  if(w.inflow>0 && sim.breachT<1.5) spawnSplash(w.inflow*dt*0.05) ... 
}
```
Splash puddle: add volume each frame: puddle.spilled += w.inflow*dt*0.6 (some water also stays as spray). and spawn droplets.

Flow field: compute drop:
```js
function updateFlow(){
  const drop = sim.water.prevLevel - sim.water.level;
  // store in FLOW
  const dy = drop;
  FLOW_TANK.x = FLOOR_TANK.x + (drop*dt*?) ...
```
Hmm current should be a velocity (px/s) — but simplest: current = drop_speed (px/s) flowing to the breach, meaning objects get pushed toward opening at that speed. I'll define current in water as {x: vx, y: vy} where vx is speed toward breach (px/s). vx = dropSpeed ≈ (before-after)/dt. But that's decreasing to 0 as level nears opening... that's fine (flow weakens as expected). But early flow speed should be significant: level falls at ~ (MAXRATE/INNER_W) = 4e5/563 = 710 px/s early. That's huge. Fish speed ~90 px/s. Overwhelming. So scale down factor for object push: use factor 0.3 → 200px/s. That's the "sweeping" behavior. Should be tunable. I'll add `CURRENT_GAIN = 0.35`.

Actually careful: if fish only pushed by 0.35*flowspeed = 250 px/s, they'd be swept in ~ 0.5 s. Reasonable drama.

Alternatively make MAXRATE smaller so drain is slower (2s) and gain higher. Let's set MAXRATE = 2.2e5 → full drain 1.45s; dropSpeed ~ 390 px/s early; gain 0.28 → 110px/s.

Also flow direction inside tank horizontal toward opening: vx magnitude ~ dropSpeed*gain. And outside water jet current: computed from jet velocity (up to 700 px/s?) scaled gain 0.5.

For the jet, also outside current: at points along jet, speed high (500-900 px/s) → gain 0.35 → 175 px/s. Objects in jet get pulled toward exit. OK.

Now capture zone check for objects: 
```js
function capturedByBreach(o){
  const op=sim.open, cx=TX_R;
  const y0=op.y - 6, y1=op.y+op.h+6;
  const nearIn = o.x > INNER_R-30 && o.x < cx+2 && o.y>y0 && o.y<y1;
  const nearOut = o.x>cx-2 && o.x<cx+op.w+40 && o.y>y0-20 && o.y<y1+20;
  return nearIn||nearOut;
}
```
Probability depends on flow strength; add randomness.

Now writing everything. Also I need "the waterline falls continuously" ✓.

Objects "sink/floating": buoyancy:
```js
const b = o.buoy; // -1 sinks..1 floats
vy += (G*(1-b*0.5) - drag*vy*|vy|*inWaterFactor)*dt
```
Simplify: inWater = (x< INNER_R && y>level) || (x>=INNER_R && y>FLOOR? ) — outside puddle region: water on floor is shallow; treat outside as out-of-water except inside puddle. Keep simple: in-water only inside tank below level.

In water:
- if buoy>0: buoyant lift balancing gravity → neutral float; drift with current.
- if buoy<0: sink to sand/floor.
Out of water: gravity, drag small, collide floor.

Projectile:
```js
o.vx += windx; o.vy += GRAV*dt;
o.x += o.vx*dt; o.y += o.vy*dt;
if(o.y>FLOOR_Y-o.r){ bounce: o.y=FLOOR_Y-o.r; o.vy*=-0.35; o.vx*=0.7; o.spin*=0.6; if(small) rest }
```
For fish, on landing, wiggle on side (rotate 90°, flop). Fine.

Water resistance for fragments in water: strong damping: vx*=0.98^... use `v *= Math.pow(0.02, dt)` (i.e., per second factor 0.02) → very strong. Plus slight buoyancy (glass ~ neutral/sink slowly).

Collision between fragments: O(n²) with radii - fine for n<20. Resolve with simple elastic-ish.

Rock behavior in water: sinks with slight drag → sits on sand or floor.
Toy: buoy 1, rides waterline; follows water surface, bobs; when water low, lands on sand/floor.

Plants: base anchored to sand top (y=SAND_TOP). Segments with spring; sway by current; if fully lifted by flow → out of water → gravity + floor collide; on floor → rest with bend.

Fish: swim mode + carried mode.

Let me define constants:
GRAV = 900 px/s².

Now flow sampling for jet velocity at point: compute jet blend at x:
```
function jetAtX(x){
  if(!sim.breached||sim.water.inflow<=0) return null;
  const stiff = clamp(sim.breachT/JET_STIFF_TIME,0,1);
  const jetLen = (sim.water.inflow/MAXRATE)*INIT_DEPTH*0.55*stiff; // px
  const op=sim.open, cx=TX_R;
  const dx = x-(cx+6);
  if(dx<0||dx>jetLen) return {x:0,y:0};
  const u=dx/Math.max(jetLen,1);
  return {x: jetLen*0.55*(1-u), y: BOTTOM- (op.y+op.h/2) ... }
```
Actually velocity vector: direction along derivative. Use v = (dx, dy) scaled by strength. I'll approximate: vx = 0.6*jetLen*(1-u), vy = (FLOOR-(op.y+op.h/2))/jetLen * ... Meh. Let me just define velocity along tangent with magnitude M = inflow/INNER_W (fall speed, early ~390) → out jet speed = M*1.6 ≈ 620 px/s early. Since M is the drop speed, early jet fast, later weak → matches "outflow weakens". Use magnitude ∝ M.

Compute:
```js
function jetVelocityAt(x,y){
  // bezier paramization
  const op=sim.open, sx=TX_R+8, sy=op.y+op.h/2;
  const stiff=..., jetLen..., cy=...
  const mx=(sx+cx)/2, my=(sy+cy)/2;
  // find t such that bx(t)=x; solve quadratic
  ...
  // derivative
}
```
That's more accurate. Implement quadratic solve for t (bx is quadratic in t). Then derivative → tangent, magnitude = 1.5*M*stiff. Return.

Good, use this for both drawing (shape already) and pulling objects.

But capturing objects: I'll use the simple capture zone (cubic band) rather than field, less error-prone.

Actually to keep it manageable: capture zones:
1. Opening cubic exit zone: x in [TX_R+4, TX_R+HOLE_W-2], y in [open.y-8, open.y+open.h+8], and object must be in water OR in air (air objects also entering? fish flying might fall into hole — allow out objects to fall into puddle instead, fine).
2. Jet tunnel: x in [TX_R+HOLE_W, TX_R+HOLE_W+jetLen], y in jet band (y between opening center and FLOOR at that x, band width ±(18+ u*30)). Compute y along jet at x = jetY(x). Use approximation via quadratic.

Objects crossing get carried: velocity set to jet velocity * small factor (carried by flow), and they continue out (they're out of water already or become out).

Let me have a helper `jetYAt(x)`.

For simplicity, define jet params function:
```js
function jetGeom(){
  const op=sim.open, sx=TX_R+8, sy=op.y+op.h*0.5, cy=cy=FLOOR_Y-6;
  ...
}
```
Let me just write it.

Jet geometry function:
```js
function jetParams(){
  const op=sim.open;
  const sx=TX_R+6, sy=op.y+op.h*0.5;
  const stiff=clamp(sim.breachT/JET_STIFF_TIME,0,1);
  const mag=(sim.water.inflow/MAXRATE); // 0..1
  const speed=mag*1.5; // multiplier on drop speed units
  // drop speed in px/s:
  const ds = sim.water.inflow/INNER_W; // px/s
  const rev = ds*0.42*stiff; // horizontal reach
  const blast = ds*0.30*stiff; // vertical extent below opening
  const ex=sx+rev, ey=sy+blast+ (op.h*0.0);
  // clamp ey above floor
  ...
}
```
Careful: cy should reach the floor when flow high. Let's scale so that full flow: rev ≈ 300, blast ≈ 250 → lands near floor.

Set:
```js
const ds = sim.water.inflow / INNER_W;       // px/s, early ~390
const rev  = clamp(ds*0.75*stiff, 0, 340);
const blast= clamp(ds*0.6*stiff, 0, 260);
```
Early ds 390 → rev 292, blast 234; opening center y = e.g., 430 → ey = 664 < floor 762. Hmm jet doesn't reach floor; then puddle forms where jet lands (664) — but "puddle constrained by floor". The jet should reach the floor for a splashing puddle. Let me make blast larger: clamp(ds*1.15*stiff,0,330) → 448 → ey=430+448=878 > floor; clamp ey to FLOOR-4, then horizontal distance where it hits floor... Since it's a quadratic bezier, I can solve for t where by=floor. Let's do that in drawing: find t where y reaches floor, use as end point. Good idea.

So jet: from (sx,sy) control (mx,my) to end at floor: solve t_end. Compute length param.

Implementation:
```js
function jetGeom(){
 const op=sim.open, sx=TX_R+6, sy=op.y+op.h*0.5;
 const stiff=clamp(sim.breachT/1.4,0,1);
 const ds=sim.water.inflow/INNER_W;
 const rev=clamp(ds*0.8*stiff,0,360);
 const blast=clamp(ds*1.3*stiff,0,360);
 let bx=sx, by=sy;
 const cx=sx+rev, cy=sy;
 let ex=sx+rev*2, ey=sy+blast;
 if(ey>FLOOR_Y-8){ ey=FLOOR_Y-8; }
 const mx=(bx+ex)/2, my=(by+ey)/2 - 24; // slight upward curve then falls
 return {bx,by,ex,ey,mx,my};
}
```
Solve t for y=FLOOR by quadratic: by(t)= (1-t)^2 by + 2(1-t)t my + t^2 ey. Set equal to FLOOR target and solve smallest root; use t≤1.

Then sampling: function jetPoint(t) returns {x,y}, and jetTangent(t) normalized.

Then for object capture in jet: compute t from x by solving quadratic x(t)=x, then y at t, band width.

This is a nice consistent jet. Objects entering the jet get velocity along tangent with magnitude ~ min(speed, something).

Also outflow visual: jet thickness ∝ mag and opening.y level factor. Plus wobble with sin(t*20).

OK. Time is limited; let me write the code now, then test, then iterate.

Also present a small legend/readout: water level %, outflow rate, status.

Let me write it out. I'll aim for correctness over decoration, but include decent visuals.

Now writing the code.

```js
'use strict';
const cv=document.getElementById('cv'), ctx=cv.getContext('2d');
const W=1200,H=800;
const FLOOR_Y=762, SAND_TOP=730;
const TX_L=92,TX_R=658,TY_T=118,TY_B=760,TW=8;
const INNER_L=TX_L+TW, INNER_R=TX_R-TW, INNER_W=INNER_R-INNER_L;
const BOTTOM_INNER=TY_B-TW/0? -> use 754
```
Let me set inner bottom = TY_B - 2 = 758. Keep BOTTOM_INNER=758.

WATER_INIT_LEVEL=180 → depth=578.
MAXRATE: volume = 578*550=318k; at 2.2e5/s → 1.45s.

Plants base y = SAND_TOP=730.

Let me write functions for drawing each element. Since it's long, I'll write carefully.

Let me define `clamp`, `mulberry32`, `rnd(a,b)`.

Init:
```js
function init(){
 const rnd=mulberry32(20240607);
 const s=sim={t:0,breached:false,breachT:0,time:0,
  water:{level:180,inflow:0,spilled:0},
  open:{x:TX_R,y:330,w:44,h:110},
  crack:{alive:true,cy:380,hover:false,drag:false},
  flow:{x:0,y:0}, puddle:[], sprays:[], bubbles:[], splash:[], smoke:[], status:'Intact'};
 // rocks
 s.rocks=[]; for(let i=0;i<5;i++){...}
 s.plants=[]; for(i<6)
 s.fish=[]; for(i<5)
 s.toy=...
 s.frags=[];
 return s;
}
```

Rock: {x,y,r,vy,vx,spin,rot,mode:'rest'|'water'|'air',bent}
Rock y = SAND_TOP - r*0.6 (resting on sand).
Plant: {x,segs:[{len}], phase, target, hue, vx, h (height), mode}
Fish: {}
Toy: {}

Update:
```js
function step(dt){
 sim.t+=dt;
 if(sim.breached) sim.breachT+=dt;
 const prevLevel=sim.water.level;
 updateWater(dt);
 // flow from drop
 const drop=(prevLevel-sim.water.level);
 const ds=drop/Math.max(dt,1e-4);
 sim.flow.x = ds*CURRENT_GAIN;
 ...
```
Actually flow should be continuous; using per-frame drop speed is fine but jittery. Use smoothed: `sim.flowSpeed += (ds - sim.flowSpeed)*0.2`. Then flow.x = flowSpeed*GAIN.

Objects use currentAt(x,y) = {x: sim.flow.x*(depthFactor), y: small}.

For penetration into jet zone: use jetGeom to compute captured objects velocity.

Let me now write the whole thing in one go, then debug.

Also "nearby objects respond to the current": when breach happens, plants sway, fish dart, rocks may shift slightly. Provide visible reaction. Rocks are heavy: they jostle/vibrate a bit. I'll add small horizontal wobble to rocks and rocks that are near the breach get pushed toward it slightly.

Let me write.

For drawing water body:
```js
function drawWater(){
 const y=sim.water.level;
 if(y>=BOTTOM_INNER) { /* full */ }
 const g=ctx.createLinearGradient(0,y,0,BOTTOM_INNER);
 ...fill rect from INNER_L..INNER_R, y..BOTTOM_INNER with alpha gradient
 // surface line
 // wavy surface highlight
}
```
Also if breached and water above opening: the right wall is open at opening; water body should still fill (it leaks) - fine, water inside is flat, seepage out is the jet.

Also add "damage" indication: draw jagged dark gap in right wall at opening when breached, plus remaining cracks from crack.

Crack drawing (pre-breach): draw jagged white line with glow along right wall from cy-h/2 to cy+h/2, plus small star cracks; drag handle (a circled dot).

Let me write the final code. Also there's smoke: when breach, brief white puff at opening — visual feedback.

Buttons: #breach triggers `doBreach()`:
```js
function doBreach(){
 if(sim.breached) return;
 sim.breached=true; sim.breachT=0;
 const o=sim.open; o.y=sim.crack.cy-o.h/2; o.x=TX_R;
 // spawn glass fragments
 for(let i=0;i<14;i++){...}
 // smoke puff
}
```

Reset: `sim=init()` (rebuild everything) - simplest & guarantees identical scene.

Also key: 'b' breach, 'r' reset.

Now, I must ensure the "waterline falls continuously" and "outflow weakens as level approaches opening and stops when water no longer reaches it" — my computeInflow does that.

Let me write the code file now. I'll keep the JS organized.

Detailed object update pseudo:

```js
function updateObjects(dt){
 const L=sim.water.level, inWater=(o)=> (o.x>INNER_L&&o.x<INNER_R&&o.y>L)
```
For rocks:
```js
for(const r of sim.rocks){
  const w = r.x>INNER_L&&r.x<INNER_R&&r.y>L;
  if(w){
    r.vx += sim.flow.x*0.35*dt*(r.buoy<0?1:0); // rocks don't drift much horizontally; slight
    r.vy += GRAV*(1-Math.abs(r.buoy))*dt*0.25;
    r.vx*=Math.pow(0.02,dt); r.vy*=Math.pow(0.02,dt);
    if(r.y> SAND_TOP - r.r*0.7){ r.y=SAND_TOP-r.r*0.7; r.vy=0; r.vx*=0.9; }
    r.x+=r.vx*dt; r.y+=r.vy*dt;
    r.rot+=r.spin*dt;
  } else if (r.mode==='out'){
    // air
    r.vy+=GRAV*dt; r.x+=r.vx*dt; r.y+=r.vy*dt; r.rot+=r.spin*dt;
    if(r.y>FLOOR_Y-r.r*0.7){ r.y=FLOOR_Y-r.r*0.7; r.vy*=-0.3; if(Math.abs(r.vy)<40) r.vy=0; r.vx*=0.72; r.spin*=0.5;}
    // wall
    if(r.x<8){r.x=8;r.vx*=-0.5} ...
  } else { r.x+=r.vx*dt; r.y+=r.vy*dt; r.vx*=Math.pow(0.1,dt); }
  // capture check
  if(sim.breached && r.mode==='rest' && inCapture(r) && Math.random()<0.4) { r.mode='out'; r.vx=...+jetvel; }
}
```
Hmm rocks on sand shouldn't be lifted easily. Allow only near-opening rocks pulled if hole low. Let's allow the rock nearest opening & r < opening.w*0.8 to be swept out. Simple: if capture && Math.random() < (0.5) → swept with jet velocity. Only "movable objects that fit the opening" carried out. Fine — add condition r.r*2 < o.w.

Fish:
```js
for(const f of sim.fish){
  if(f.out){ projectile... }
  else {
    // swim
    const cur=currentAt(f.x,f.y);
    let dx=0,dy=0;
    // wander
    f.wt+=dt; 
    const ang = Math.sin(f.wt*1.7+f.seed)*Math.PI + Math.cos(f.wt*1.1+f.seed*2)*0.6;
    let tx=Math.cos(ang), ty=Math.sin(ang);
    // avoid walls
    if(f.x<INNER_L+40) tx+=1.2; if(f.x>INNER_R-40) tx-=1.2;
    if(f.y<L+40) ty+=0.8; if(f.y>BOTTOM_INNER-50) ty-=0.8;
    // flee breach
    if(sim.breached){
      const bx=TX_R, by=sim.open.y+sim.open.h/2;
      const d=Math.hypot(f.x-bx,f.y-by);
      if(d<130){ tx -= (bx-f.x)/d*2.5; ty-=(by-f.y)/d*2.5; }
    }
    // resist current: add upstream component proportional to flow
    tx -= Math.sign(sim.flow.x)*Math.min(2.5, sim.flow.x/45);
    normalize; 
    f.dirLerp...
    f.x += (tx*f.speed + cur.x*0.55)*dt;
    f.y += (ty*f.speed + cur.y*0.55)*dt;
    // capture
    if(sim.breached && inCapture(f) && Math.random()<0.25){ f.out=true; f.vx=jetv.x*0.5+...; f.vy=jetv.y*0.5; }
  }
}
```
Fish that are out and land on floor: rest & flop.

Plants: 
```js
for(const p of sim.plants){
  const w = p.x>INNER_L&&p.x<INNER_R && (p.baseY > L); // plant submerged if base below level
  if(!p.out){
    // sway
    const cur=currentAt(p.x, L+20);
    const target = Math.sin(sim.t*1.6+p.phase)*0.5 + cur.x*0.12;
    p.vx += (target*40 - p.vx)*Math.min(1,dt*3);
    p.bend += (target - p.bend)*Math.min(1,dt*4);
    p.x += p.vx*dt*0.5; // drift
    // keep anchored
    p.x=clamp(p.x,INNER_L+12,INNER_R-12);
    if(sim.breached && (p.x>INNER_R-60) && Math.random()<0.12){ // pulled out
       p.out=true; p.vx=...; p.vy=...;
    }
  } else {
    p.vy+=GRAV*dt; p.x+=p.vx*dt; p.y+=p.vy*dt; p.bend*=0.98;
    if(p.y>FLOOR_Y-4){ ... settle: p.out=false? keep drawing flat on floor }
  }
}
```
For plant drawing I need a position for the whole plant when out (root point moves). I'll give plant: baseX, baseY (on sand) and when out, baseY becomes free y and root moves.

Let me define plant: {x, y (root), h, segs: [len...], phase, hue, bend, vx, vy, out:boolean, restY:null}

Draw: from root, segments angled with cumulative angle = bend * (i/segments)^1.5, length h/segs each.

Toy:
```js
toy: {x, y, vx, rot, size}
float: y = level - 4; but clamp to >= SAND_TOP-10.
y = max(SAND_TOP+6, level-6) and lerp for smoothness; drift x with flow.
```

Fragments: update as described with collisions.

Now collisions among frags: simple O(n²), if dist < r1+r2 push apart and exchange some velocity; in water, high damping.

OK, writing now. Also add small bubbles rising inside water while draining (visual).

Puddle blobs: 
```js
function addSpill(vol){
  // convert volume to blobs
  while(vol>0){
    const take=Math.min(vol, 900);
    vol-=take;
    // blob radius so area ~ take/DEPTH_PUDDLE
    const area=take/5; // depth 5 px
    const r=Math.sqrt(area/Math.PI);
    sim.puddle.push({x:... choose landing point near jet end, y:FLOOR_Y, r:r, cr:r});
  }
}
```
Hmm blob spawn position: at jet end x ± random. And spread: blobs slowly expand to maxR and drift? Let me do simpler: puddle is a single "polygon strip" built from blobs: spawn a blob at landing point with r = something; blobs grow toward cr; new blobs trigger merge drawing. It'll look like a puddle.

But "spreading puddle constrained by floor and room walls": we need spread from the impact point across the floor to the walls. Add a spread mechanic: every 0.15s, try to spawn a new blob at the extreme left or right edge of existing blobs (within wall limits) with small radius. This makes the puddle spread outward over time until hitting walls. Implement:

```js
function spreadPuddle(dt){
  sim.spreadT-=dt;
  if(sim.spreadT>0) return; sim.spreadT=0.12;
  if(sim.puddle.length===0) return;
  // find extremes
  let minX=1e9,maxX=-1e9;
  for(const b of sim.puddle){minX=Math.min(minX,b.x-b.r);maxX=Math.max(maxX,b.x+b.r);}
  const add=(x)=>{ if(x>10&&x<W-10) sim.puddle.push({x,y:FLOOR_Y,r:6,cr:14}); };
  if(minX>14) add(minX-14);
  if(maxX<W-14) add(maxX+14);
}
```
Blobs grow toward cr*1.2 but limited by wall clamp. Good enough, visibly spreads.

Also the puddle should be under the tank? The tank sits on the floor, so water can't go under the tank; puddle on the right side (floor to the right of tank) plus possibly spreading left is blocked by tank bottom... The tank occupies x from 92 to 658, down to 760 (floor). So puddle can only exist to the right of TX_R. So constrain puddle x >= TX_R+6. Let me set the wall constraint for puddle: x in [TX_R+8, W-8]. And jet lands near floor to the right of the tank. Good — simpler and correct. Spawn landing x near ex.

Let me force blob spawn near jet end: x = ex + rnd(-20,20), clamped to [TX_R+8, W-8].

OK now finally write. Also droplet sprays at impact: particles that arc up and fall, adding to puddle when landing. Nice.

Let me write the file.

I'll write code with reasonable length. Let's go.

Also note: water inside tank when breached below opening: water stops at opening bottom? The water surface is flat; water below the opening stays. ✓ (nothing drains). But visually, there might be some residual water clinging... skip.

One more: "Water exits in a gravity-curved jet" ✓ jet is a bezier curving down.

"waterline falls continuously" ✓.

Now code.

I'll also add a subtle vignette/room, a light, and a label "GLASS AQUARIUM". Not necessary.

Write the file now.

For fish tail wiggle: draw body ellipse rotated to heading, tail triangle oscillating sin(t*20).

Let me produce the code.

Note on the `currentAt` for outside jet: pulling objects. Let me implement jet capture zones as described.

Time to write. I'll write the entire file in one write call.

Let me be careful with the capture zone for fish near the hole: fish near right wall inside tank will be pulled toward the hole when level above hole; the flow.x pushes them right. When a fish's x exceeds INNER_R-6 and its y in opening band, it goes out. Good.

Also fish "initially swim against the current before some are swept through the breach": fish resist and swim left; flow pushes right; eventually if the flow speed (0.35*ds) > fish speed ~ 110*? Let's tune: fish swim speed 95 px/s. flow.x = ds*0.35 early 390*0.35=136 px/s right, applied as cur.x*0.55 → 75 px/s. Fish upstream swim at 95 left → net -20 → they hold station initially, but as ds decreases... hmm then eventually water stops. We want some swept. The capture randomness (25% per frame chance when in zone) plus flow pushes them right; when they reach the wall zone they may get pushed out. Add: when fish x > INNER_R - 25, flow.x*0.55 = 75 while fish swim left 95 → hmm they can hold. To ensure some get swept, add a "suction" toward hole when within 60px: extra force proportional. Let me use: cur.x*0.9 inside tank (instead of 0.55) → 122 vs 95 → slightly net rightward → they drift toward hole and get captured. And some fish are weak/small (speed 70) → swept quickly. Good: give each fish a strength var.

Also fish flee from hole (avoid) which fights: they swim away from hole when near, adding leftward. That's "swim against the current". Then as they tire? Simplest: with the current stronger than their swim, they get swept eventually. Add randomness in capture so a few escape.

Let's set currentAt tank x factor 0.85 and fish speed 85-115 and flow ds early 390 → flow.x = 331; applied at 0.85 → 282?? Too strong. Hmm I conflated: sim.flow.x already = ds*CURRENT_GAIN. Let's define sim.flow.x = ds (raw drop speed). Then currentAt returns {x: sim.flow.x*0.35*depthFactor}. In fish update, applied directly (not *0.55). So force = 390*0.35=136 vs fish 85-115 → some swept. Plants sway ~ uses same. OK: currentAt(x,y) = {x: sim.flow.x*0.35*(0.25+0.75*t), y:0}. Where t = depth fraction (0 surface →1 bottom). Near opening mid-depth, t≈0.5 → factor 0.65 → 130.

Fine. Tune numbers by observation later.

For rocks: current pushes them slightly; add drag; they mostly stay but jostle.

Let's write.

Also need smoke: when breach, spawn smoke puffs near opening that expand & fade — indicates explosion.

Let me write the code now for real.

I'll also add "bubbles" rising in water, spawn while draining near the bottom.

Enough planning. Writing.

Regarding the impact splash & droplets: 
```js
function spawnSpray(x,y,n,spd){ for... sim.sprays.push({x,y,vx:rnd,vy:-rnd,life:1}) }
update: vy+=GRAV*0.5*dt; pos; life-=dt; when y>FLOOR → add to puddle (small) & remove.
```
Adding to puddle: addSpill(small volume) occasionally.

Now final code.

Let me estimate lines: ~700. Fine.

Write it.

Empty dir. Write index.html.

There's a bug: in doBreach I define `o()` function used before definition but function declarations hoist — `function o()` is hoisted, fine. But I used `o().w` in the loop after `const oy` — ok.

Wait, `sim.open.y = sim.crack.cy - sim.open.h/2` — but the crack cy validation clamps min to LEVEL0+26+limit, so the opening will always be below the waterline. Good. But after water drains the level drops below the opening; the opening stays where the crack was. Good.

However the constraint "Drag the crack below the initial waterline" — the opening top = cy - h/2 >= LEVEL0+26 (since cy >= LEVEL0+26+limit where limit = h/2+14 → cy-h/2 >= LEVEL0+26+14... wait: limit = crack.h/2+14, cy_min = LEVEL0+26+limit → cy_min - open.h/2 = LEVEL0+26+limit - crack.h/2 = LEVEL0 + 26 + 14 = LEVEL0+40 (since limit includes crack.h/2 and open.h == crack.h). Good, opening top always ≥ level0+40. ✓

Also drag should be allowed below the waterline but as the water drains the crack default stays. Fine.

Now let me run it in the browser and check for errors.

Also potential issue: `drawJet` uses quadraticCurveTo for the ribbon - fine.

Another issue: in the fish update, `f.dir` lerp and `flip` computed from cd. When out, drawFish rotates by f.dir + PI/2 which is odd; when out we already integrate rot via f.rot but don't use it. Let me simplify: when out, rotate by atan2(vy,vx) — better to use velocity direction. Let me fix drawFish for out case: rotate to velocity angle, and if landed, rotate ~PI/2 (flopping on side).

Let me fix that and then test.

Also `f.rot` unused. Let me change drawFish:

```js
if (f.out) {
  const a = Math.atan2(f.vy, f.vx);
  ctx.rotate(a);
  if (f.landed) ctx.rotate(0.6); // on its side
} else ctx.rotate(f.dir);
```
And flip unnecessary. Remove flip scaling for out.

Let me apply the edit and then test in the browser.

Wait, the script uses `document` etc., but new Function only parses, not executes. Good — syntax OK.

Now run in the browser.

The scene looks good. The crack handle is not visible! The crack should be visible on the right wall. Wait — drawCrack draws at x=TX_R-1 with y=cy = LEVEL0+150 = 332. But I don't see it in the screenshot... Actually looking at the right wall, there's no visible crack. Let me check: drawCrack is called after drawTankShell. It draws a circle at TX_R-1, cy=332 with 'DRAG' text. Hmm, in the screenshot at around y=330 on the right wall... I see nothing obvious. Maybe it's there but faint? The crop region: the image shows tank right wall at ~x=658/1200*width. At y≈332 in canvas → image y ≈ 118*? Hard to tell.

Also plants: some plants appear bent oddly - the tall plants have leaves at top that look fine but the ones on the left are bent flat with the leaf at ground level pointing left. Hmm, two plants on the left look like they're lying down. Actually the plant drawing: bend is applied initially random -0.4..0.4, and bends further. The ones on the left at bottom appear to be lying flat with leaf near the base — that looks wrong. Let me look: at bottom-left there are two curved lines with a leaf blob at the left end near the ground. That suggests bend is very large, maybe ~ -1.5 rad per segment * 0.3 incremental, accumulating to a horizontal orientation. The angle increment per segment is p.bend*0.30, and the base angle is -PI/2 + bend. With bend=-0.4 → base angle -1.97 rad, plus increments of -0.12 each → after 9 segments total ~ -1.97-0.96 = -2.93 rad ≈ pointing right-down... hmm that would be more horizontal. Over 9 segments the total turning is 2.7 rad ≈ 155°, so the plant curls over. That's why they look bent over.

I should reduce the bend effect: make the incremental bend smaller, e.g. bend*0.12, and the initial bend range smaller, and make the base angle include bend*0.6. Let's tune so plants stand mostly upright with a lean.

Also the fish look decent. The toy is floating mid-water though! The toy is at y=level-5... The screenshot shows the toy at around mid-height of the tank, well below the waterline. Wait: toy.y is initialized to LEVEL0=182, and set toward `surf-5`. That should place it at the surface. But in the image the toy appears mid-tank. Hmm, look at the image: the striped toy is at about y=310 in image coordinates... the waterline is at ~y=130 in image coords (tank from ~118 to 762 canvas → image y 118*0.66≈78? The canvas is 1200x800 scaled to about 780x520 in the image). Tank top in image ≈ 78, waterline at canvas y=182 → image y ≈ 120. The toy in the image is at ~y=210 → canvas y ≈ 320. That's below the waterline!

Wait, that means the water level dropped? No... the sim state. Hmm, maybe `t.y` lerp target `surf-5` where surf = max(SAND_TOP-2, L) = 182 → target 177. t.y starts at 182 and lerps to 177. So the toy should be at the surface.

Unless... the image I'm looking at: there's a "waterline" label at the top left of the tank at image y≈120, and the toy at image y ≈ 210. So canvas y ≈ (210/520)*800 = 323. Hmm that's a big discrepancy. Unless the image is bigger than I think: the screenshot is 1200x800? The attached image looks like it's ~1150x700. The canvas element in the page is width:100% of a 1220-max container minus padding ≈ 1192 → so nearly 1:1 with canvas internal 1200x800, but height auto → 1192*(800/1200) = 795. So the image is about 1200x795, nearly 1:1. So waterline at canvas y=182 → image y ~182*0.95 ≈ 173. And the toy at image y≈210 → canvas ≈ 221. Hmm that's 40px below the surface.

Hmm wait, actually is the toy's y correct? Let me check the toy update: 
```
const targetX = clamp(t.x + c.x*dt*0.9, ...)
```
fine. `t.y += (surf - 5 - t.y) * min(1, dt*4)`. surf = max(SAND_TOP-2, L). L=182 → target = 177. So t.y should converge to 177. But at image the toy is lower... 

Actually maybe the top part of the image (HUD ~90px) is included. The screenshot includes the HUD bar above the canvas (~100px tall). So image y=210 → canvas y≈110?? No wait — the tank top rim in the image is at ~y=95, canvas TY_T=118 → image 95 means offset ~ -23? The canvas starts at image y≈65. So image y=210 → canvas y = 145. And the waterline label at image y≈120 → canvas y ≈ 55?? That can't be, the label is drawn at canvas L=182 → image y ≈ 65+182*0.99 ≈ 245. But the "waterline" text in the image appears at ~y=120, well above the toy.

I'm confusing myself. Let me just query the DOM state via evaluate... but there's no eval tool; I have `inspect` which gives DOM. Let me use console inspection instead: I can't run arbitrary JS... Hmm, actually the browser tool's `inspect` shows DOM. But I exposed window.__aquarium. There's no JS execution tool available.

Let me check via the motion/screenshot tools differently: take a screenshot after breach to see the dynamics, and rely on visual inspection.

Actually, I realize the toy in the screenshot IS at the waterline: looking again, the "waterline" dashed label text is at the far left OUTSIDE the tank at x<INNER_L (I draw it at INNER_L-38 which is inside the room wall area left of the tank). The dashed line spans INNER_L-34 to INNER_L-4, which is left of the tank's inner left edge, in the glass/room area. That's at the y of the waterline. In the image, the label "waterline" is at around y=120 which is above the toy at y=210. Hmm.

Hold on, maybe the water level actually fell because... `updateWater` is only draining if breached. Not breached. So no.

OH WAIT. I see it. The caveat: in `initScene` the toy y=LEVEL0=182, fine. But in `updateHUD` water shows 100%. So level is 182.

Let me measure more carefully using the image: The tank outer box: top rim (dark strip) visible at image y≈92, and its inner top at ~100. Canvas TY_T=118 → so image→canvas scale ≈ (100-118)... negative. That suggests the canvas in the image starts above y=0? The screenshot may have scrolled. The HUD ends at image y≈62; the canvas top edge (border) is at image y≈70. So canvas y_c = (image_y - 70) * (800/795) ≈ image_y - 70.

Waterline label at image y≈120 → canvas ≈ 50?? But the label is drawn at canvas y = L+4 = 186. That doesn't match at all.

Hmm, so maybe what I think is the "waterline" label is something else. Looking at the image again: at the left, above the tank top, there's a gray dashed line with "waterline" text at image y≈115, which is above the tank! That's odd — unless the tank top is much lower. Actually the tank's top rim: I see a horizontal dark bar at image y≈92-100 spanning the tank width, and the "waterline" text is just below it at y≈115, and the water surface (lighter line) at y≈125.

So canvas waterline ≈ 125-70 = 55?? That contradicts.

Unless... the canvas is scaled: the canvas element CSS width is 100% of the container. The container is max-width 1220 with padding 14 → content width ≈ 1192. So the canvas is 1192 wide and 795 tall, displayed at scale 0.993. So canvas y=182 → image y = 70 + 182*0.993 = 251.

So the water surface should be at image y≈251 and the toy at ≈246. But the image shows the water surface around y=125 and the toy at y≈210.

Something IS off. Unless the image I'm seeing is scaled down in the attachment (the screenshot might be rendered at a smaller size, e.g., 1200x800 viewport screenshot but the figure shown to me might be scaled). The attached image dimensions: it says coordinates use a 1200×800 viewport. The screenshot is probably 1200x800 of the viewport (not full page). With the HUD taking ~110px and the canvas 1192x795... but the viewport is only 800 tall! So the page is scrolled or the canvas is clipped. The screenshot shows the canvas top at y≈70 and the canvas bottom at... the image bottom is ~800, so we see only the top ~730px of the canvas. That's consistent with the canvas being clipped by the viewport! And the whole thing is at scale ~1.

So the water surface in the image at y≈125 → canvas y = 55. Hmm, still inconsistent.

Wait, maybe the page is scrolled down? If the viewport shows the canvas from its top, then image y=70 → canvas 0.

Hmm, let me look at the image again very carefully:
- A dark bar at y≈92 spans the tank width — that's the tank stand/rim at TY_T-12=106... canvas 106 → image 176 if offset 70. Doesn't match 92.

So maybe the offset is 70-? Let's use the sand: SAND_TOP=726 → image y would be ~796 if offset 70 — near the bottom, and indeed the sand appears at the bottom edge of the image (~y=780). Yes! The sand is visible at the bottom of the image. So the scale is ~1 and the canvas bottom is around image y≈800.

So with sand at canvas 726 → image 780: offset = 780-726 = 54, scale 1.0. Then canvas waterline 182 → image y = 236. And the tank top rim (canvas 106) → image 160. But the image shows the rim bar at ~92 and the "waterline" label at ~115 and the water surface at ~125.

That means the actual water level is much higher than 182?? No... 

Unless the image is displayed to me scaled down (e.g., the screenshot is 1200x800 but the attached image is resized to fit). The sand at the image bottom (~y=790 of the image) and the tank rim at 92... ratio: (790-92) = 698 for canvas (760-106)=654 → scale ≈ 1.07 with offset -12: canvas = (image +12)/1.07. Water surface at image 125 → canvas 128. Waterline label text at image 115 → canvas 118?! The label is drawn at canvas L+4 = 186... 

Hmm, that means the waterline is at canvas y≈128, not 186. That would mean the water level is 128?? But HUD says 100%.

OK wait. Maybe the screenshot is of the whole page (full-page capture) rather than the viewport, i.e., taller. The image is 1200x800 given in the tool spec, but the attachment might be scaled. The ratio sand(790)/rim(92) suggests full page height ~1000px scaled to 800 → scale 0.8, offset: canvas 106 → image 92 → offset = 92 - 106*0.8 = 7.2; check sand: 726*0.8+7.2 = 588, not 790. Inconsistent.

I'm burning time on pixel forensics. Let me instead use the `motion`/`screenshot` tool after actions and check states numerically through... hmm.

Actually, there's a much better approach: I can add a tiny debug overlay drawn on the canvas (text showing water level, toy y, etc.). Then a screenshot reveals numbers. Let me add a debug readout in the corner of the canvas, temporarily (or keep it—it's fine, it's informative). Actually I'll draw a small debug line in the HUD area... but HUD is DOM, already shows water%.

Better: I'll draw a small canvas overlay with key values (waterline y, toy y, fish count out, frag count, inflow). Keep it small and toggleable. Then screenshot.

Let me add it.

Actually first, let me reason about whether the toy is at the surface. There is a real possible bug: `updateObjects` uses `const L = sim.water.level;` and for the toy: `const surf = Math.max(SAND_TOP - 2, L); t.y += (surf - 5 - t.y) * ...`. That's right.

Hmm, but wait — in the screenshot, is the striped object the toy? Yes, it's the striped yellow/red box. Is it at the water surface? In the image, the water surface line (light) is at y≈125 and the toy at y≈210. That's 85px below. 

OH. I bet the issue is the screenshot was taken while... no, the sim is static until breach.

Hmm! Actually maybe I misidentified: maybe the "lighter horizontal line at y≈125" is the top of the water fill (the water gradient top edge) — that IS the waterline at canvas 182 → image y = ? If offset 54 and scale 1 → 236. The line at 125 would be canvas 71.

Unless the canvas is rendered at 2x devicePixelRatio... no, canvas attr width=1200.

You know what? Let me just take a screenshot with a debug overlay showing exact numbers. That settles it fast.

Let me add a debug draw with: water level, toy.x/y, fish out count, puddle blobs, frag count.

The debug panel isn't visible in this screenshot... it's at (8,60) in canvas coords, which should be top-left of the canvas. The canvas top in the image is ~70. Canvas y=60 → image y≈130. But I see nothing there. Left area at image y 130 is dark blue (the room wall / tank glass). Hmm, the box is 210x92 px wide, drawn at x=8..218 → the tank starts at canvas x=92, so the debug box overlaps the room wall area and the tank glass at x 92-218. It should be visible as a dark box.

But the screenshot looks IDENTICAL to before (fish in the same positions). Suspicious — maybe the page didn't reload. The `browser reload` command earlier ran `cd /tmp/job-EeXrMA && browser reload` in bash, which is not the tool call! `browser` is a tool, not a shell command. So the reload never happened. I need to call the browser tool with action reload.

Let me reload properly via the tool.

Now I can see the debug overlay. Water level = 182.0, opening y = 332..444, toy y = 412. So the toy IS at y=412, but the water surface is at 182?! The toy should float at 177.

Wait — the toy y is 412 in a full tank? That means `t.y` lerped toward `surf - 5` = 177... unless `L` used in updateObjects is stale? No: `const L = sim.water.level;` = 182.

Hmm, the toy target: `const surf = Math.max(SAND_TOP - 2, L);` → 726-2=724 vs 182 → max is 724! I wrote Math.max instead of Math.min! SAND_TOP-2 = 724 > L. So the toy sits at 724-5=719?? But it reports 412 — converging slowly (dt*4 per frame, ~0.07/frame, slow approach). Yeah, it's slowly sinking to the sand. Bug: should be Math.min.

Fix: `const surf = Math.min(SAND_TOP + 8, L)` — actually we want the toy at the water surface, but when water drains below the sand level... the water can't go below BOTTOM_INNER=752, and SAND_TOP=726, so water surface min = 752 > SAND_TOP. So the toy can just always sit at L-5, clamped so it doesn't go below sand: `surf = Math.min(SAND_TOP + 10, L)` — wait if L > SAND_TOP+10 (normal), use L. If L < SAND_TOP+10 (water nearly empty, L up to 752), then clamp. Since L max = 752 > 736, use min(SAND_TOP+10=736, L). Good: surf = Math.min(SAND_TOP + 10, L).

Also the toy's drawing: the toy is drawn after the water body but the water body is drawn from L to BOTTOM_INNER, so the toy at the surface is fine.

Second issue: plants on the left are lying flat. Fix bend scaling.

Third: the crack. I still don't see the glowing crack handle on the right wall! Opening y is 332..444, so the crack should be at canvas y=388 near x=657. In the image at canvas (657, 388) → image x ≈ 657, y ≈ 388 + ~70 = 458. Looking at the right wall of the tank around y=450 in the image... I see nothing. Hmm! Let me look at the right glass wall — the image shows the tank's right edge at image x ≈ 658ish. Around y=458 there's just glass.

Why isn't drawCrack drawing? `if (sim.breached || !sim.crack.alive) return;` — sim.crack.alive is true (never set false). sim.breached false. So it should draw.

drawCrack draws with shadowBlur... it should be visible. Unless... `ctx.shadowColor`/`shadowBlur` are set, then restored at the end. Yes `ctx.restore()`.

Hmm, is drawCrack even called? In draw(): drawTankShell(); drawCrack(); drawJet(); drawBreachHole(); — yes.

Wait, maybe the issue is that the fish/debug overlay show, and the crack is drawn but at a place I'm mis-measuring. Let me compute the image→canvas mapping precisely using the debug box: the debug box is at canvas (8,60) to (218,152). In the image, the box's top-left appears at about image (75,88) and its bottom (218+... ) The text "water level 182.0" is the first line at canvas y=78 → image y ≈ 88+ (78-60)*0.99 ≈ 106. Yes the text is at image y≈106. And the box bottom at canvas 152 → image ≈ 178.

So canvas y = (image y - 88) / 0.99 + 60 ≈ image_y - 28.

Crack at canvas y=388 → image y ≈ 416. Let me look at image y≈416 on the tank's right wall (image x ≈ 657+... canvas x = image x - 47? canvas x=8 → image 75 → canvas x = image x - 67). So canvas x=657 → image x = 724. But the image is only ~1150 wide, and the tank right wall is at image x ≈ 700. Let me check: canvas x = image_x - 67 → image 700 → canvas 633. The tank inner right is 650, outer right 658. So the right wall in the image is at image x ≈ 658+67 = 725.

Is there anything at image (725, 416)? Scanning the right wall of the tank in the image at that height... The image shows the tank right edge as a vertical light line around x=725. I don't see a glowing crack.

Hmm! Unless the crack IS drawn but hidden behind... no, drawn after the shell.

Let me test by checking whether the code path has an error. Actually — I bet there IS an error thrown inside drawCrack, which would break the whole draw loop! But the debug overlay IS drawn (it's last), and the fish are drawn. So the loop works.

Wait, actually — the debug overlay is drawn after drawCrack, so if drawCrack threw, we'd never reach drawDebug. So drawCrack completes.

Hmm, so where is it? Let me re-read drawCrack... 

`const pts = []; for (let i=0;i<=6;i++){...}` then `pts.forEach((p,i)=> i ? ctx.lineTo : ctx.moveTo)`. Fine.

Then `ctx.fillText('DRAG', hx+2, hy-13)`.

It should be visible. Unless... hmm, `ctx.shadowBlur = 10` with `shadowColor` set. Fine.

OH WAIT. I see it now! In `draw()` I call `drawCrack()` — but is `drawCrack` defined AFTER `draw()`? Yes but function declarations are hoisted. Fine.

Hmm, let me look at the screenshot again very carefully around the right wall... 

Actually, maybe I should look at the pixel region. Let me take a screenshot with a marker: I'll temporarily draw a big red X at the crack location to confirm mapping, or better: check the mapping using the toy: the toy is at canvas y=412 (per debug) and in the image it's at y≈440 (image y - 28 = 412). Yes! The toy in the image is at ~y=440. Great, so the mapping canvas_y = image_y - 28 is right, and canvas x = image_x - 67.

So the crack at canvas (657, 388) → image (724, 416). Looking at the image around (724,416): the tank's right glass wall. I see... the image at x≈724, y≈416 — there's a vertical light-gray line (the tank wall) and nothing else.

Hmm hold on, is the tank right wall at image x=724? Canvas x=658 → image x = 658+67 = 725. And the tank's left outer at 92 → image 159. The tank inner left at 100 → image 167. In the image, the tank's left glass line is at ~x=160. ✓.

So the crack should be at image (725, 416) and it's not there.

Let me verify by adding to the debug a line "crack cy" and "crack.drag" — but more useful: let me check if maybe `sim.crack.cy` changed. The debug shows opening y 332..444, which is derived from sim.open.y which is set at init to LEVEL0+150 = 332 (init value, unchanged since not breached). And sim.crack.cy = LEVEL0+150 = 388 too. OK.

Hmm, wait... is `drawCrack` perhaps being called but the shadow... Let me try a different tack: temporarily make drawCrack draw a big red rectangle. Then screenshot. If I see the red box, the geometry is fine and the issue is styling; if not, something else.

Actually — I wonder: could the issue be that `cv.setPointerCapture` ... no.

Let me just test with a big obvious marker.

Actually hold on. Let me reconsider: is the visible "toy" in the image actually at image y≈440? The toy box appears at image y ≈ 440-470 (the striped box). The debug says toy y=412 → image 440. ✓ matches (the top of the toy box at 440).

OK so where's the crack? Let me test with a marker.

Actually wait. I just realized: maybe the crack IS there but drawn UNDER the water/jet... no.

Let me recheck the order in draw():
```
drawRoom(); drawSand(); plants; rocks; fish; frags; drawWaterBody(); drawToy(); drawTankShell(); drawCrack(); drawJet(); drawBreachHole(); drawPuddle(); out-objects; waterline label; drawDebug();
```
Yes drawCrack after shell.

Hmm, one thought: `ctx.shadowColor = sim.crack.drag ? ... : 'rgba(150,220,255,.8)'` and shadowBlur=10 — with shadow applied to the stroke, fine.

Let me just add a temporary loud marker.

The red marker appears at the crack position (visible in the image as a red rectangle on the tank wall). And the toy is now at the surface (toy y = 180, at the waterline). 

So the crack geometry IS at that location. The red marker is clearly visible. So why wasn't the original crack rendering? The difference: the original code had `if (sim.breached || !sim.crack.alive) return;` — sim.crack.alive is true... 

OH! I see it! The marker is drawn where TX_R-26..TX_R+14 — the tank right wall. The red rect is visible. And the original crack stroke drew at x = TX_R-1 ± small offsets, with lineWidth 2.2, color rgba(190,235,255,.8) — should be visible.

Hmm, unless... the crack WAS visible and I just missed it in the screenshots! Looking at the first screenshot again: at the tank's right wall around y=416 there might be a small glow. Actually in the very first screenshot I recall seeing nothing, but the crack is thin (2.2px) and semi-transparent with a subtle glow — easy to miss in a compressed screenshot. The handle circle is 7px radius with 'DRAG' text at 11px — that should be noticeable though. In the second screenshot at canvas (659, 375) I'd expect a small circle + "DRAG" text. The image region image (726, 375)... I don't see it.

Hmm wait, maybe the issue: `ctx.fillText('DRAG', hx + 2, hy - 13)` with `ctx.textAlign='center'` — text at y=375, x=659. In the image that's around (726, 403). Nothing visible there.

So why? Let me check: does drawCrack's early return trigger? `sim.crack.alive` — set in initScene as `crack: { cy:..., h:..., drag:false, hover:false }` — I DIDN'T set `alive: true`! So `sim.crack.alive` is undefined → `!sim.crack.alive` is true → return! That's the bug. 

Fix: set alive: true in initScene, and remove the debug marker.

Also fix the plants' bending.

Let me now remove the marker and fix.

Plant bending: currently `ang = -PI/2 + p.bend` and increments `p.bend*0.30` per segment. With 9 segments that's too much curl. Let me change to increments `p.bend * 0.10` and base angle `-PI/2 + p.bend*0.8`. With bend range -0.45..0.45 the max total turn = 0.45*0.8 + 9*0.45*0.10 = 0.36+0.4 = 0.76 rad — a nice lean. When the current pushes, sway = c.x*0.035 with c.x up to ~130 → 4.5?? That's huge. c.x*0.035 → 4.6 → bend would go to ±4.6 → plant flattened. Hmm, need to scale: sway = c.x * 0.012 → 1.5 rad max → strongly bent but not flat. And `p.vx += (sway*46 - p.vx)`.

Let's use: `const sway = Math.sin(...)*0.35 + c.x * 0.010;` (c.x max ~130 → 1.3).

Then the plant lean with a strong current is ~1.3 rad ≈ 75° — good, "bend with the current".

Also plant drift `p.x += p.vx*dt*0.55` where vx target = sway*46 → up to 60 px/s. That's a fast drift; reduce to sway*22 → up to 28 px/s. And plants near the breach get pulled out with 3.2/s probability.

Also the initial bend: r(-0.35, 0.35).

Let me apply all these fixes.

The earlier multi-edit failed atomically? It says "Could not find edits[4]" — but did edits 0-3 apply? The error suggests the whole call failed. grep shows line 371 still has `sway * 46` and line 755 has the marker fillRect. So the entire edit call was rejected (atomic). Let me redo them one at a time carefully.

Now the toy floats at the surface, the plants stand upright and look natural, and the crack is now visible on the right wall (I can see the glowing white crack mark with "DRAG" text). 

Now let's test the breach. I'll press Breach via the tool click on the button. The button is at approximately... The HUD is at the top. "Breach" button: roughly x=215, y=25 in the screenshot. Let me click it.

Then take screenshots over time to check the jet, falling waterline, puddle, objects.

The click didn't trigger the breach — state is still Intact and outflow 0. Maybe the click coordinates were off (the button might be at a different position), or the click was intercepted. Let me look at the screenshot: the "Breach" button is at approximately x=210..265, y=20..40. My click at (215,26) should be inside. But the state didn't change.

Hmm, maybe the click didn't register on the button because the canvas... no, the button is in the HUD div. Possibly the browser tool's click needs the element coordinates in the 1200x800 viewport; the HUD button at y≈26 might be right. It seems the click did nothing.

Wait, maybe the click DID happen but `doBreach` set breached=true... no, the debug shows water level 182 and outflow 0, fishOut 0/6, and the crack "DRAG" is still visible (drawCrack only draws when !breached). So breached=false.

Let me try clicking again with a slightly different position, or use keyboard 'b'. The key action might work better.

The breach happened: the state shows "Drained", the glass has a hole with shards (visible), and the opening is at y 276..380. But the water level is 182.0 and outflow is 0! The water should be draining since level 182 > opening y 276? No wait — the opening is at y 276..380, and the water level is at 182. Water surface y=182 is ABOVE the opening top y=276. So water should flow!

Wait, my condition: `if (w.level > o.y)` → 182 > 276 is FALSE. I mixed up the direction! In canvas coordinates, smaller y = higher. Water level y=182 means the surface is at 182; the opening at y=276 is BELOW the surface. Water reaches the opening if the surface is above it, i.e., level.y < opening.y. I had the inequality backwards!

So it never drains. Also "State Drained" is displayed because inflow<=0.

Fix: `if (w.level < o.y)` → water surface above the opening top.

Also `inBreathZone` and capture checks use `o.y > op.y - 14 && o.y < op.y+op.h+14` — fine.

Also the crack clamp: `cy = clamp(p.y, LEVEL0 + 26 + limit, TY_B - 40)` ensures the opening is below the waterline (cy - h/2 >= LEVEL0+40), so o.y >= LEVEL0+40 > level. Good, so after the fix, water always reaches the opening initially.

Also `drawBreachHole`'s sheen: `if (sim.water.level > y0)` → should be `sim.water.level < y0` (surface above the opening top means level.y < y0). Let me fix that too.

Also the head computation: `head = clamp((w.level - o.y)/DEPTH0,0,1)` → with the corrected understanding, head should be (o.y - w.level)/DEPTH0 → how far below the surface the opening is. Let me fix: `head = clamp((o.y - w.level) / DEPTH0, 0, 1)`.

Let me also double check the jet geometry: the jet starts at sy = o.y + o.h*0.5 = (276+380)/2 = 328, which is below the water surface (182) — correct, water exits through the hole and falls.

Let me fix these three places.

Another thing: the fish and plant responses happened (fish gathered near the breach at the right; plants bent toward the right). Good signs — the flowSpeed was 0 though (outflow 0). Hmm, fishOut=0/6 and fish are near the hole... but flowSpeed 0. So they moved there by their "avoid breach" steering? That moves them AWAY. Actually in the screenshot fish are clustered at the right near the breach. With flow 0, they shouldn't be pushed. Maybe their wander + wall avoidance brought them there. Whatever — let's fix the drain and re-check.

Also note the smoke/shards look good.

Let me apply the fixes.

Good, reset to the initial state (toy at 180, crack visible). Now press "b" to breach and take a screenshot immediately to sample the early outflow.

The `motion` tool may capture frames; but let me just press the key and screenshot. Note the key press and screenshot are separate tool calls, so time passes between them. The screenshot may be taken after the water drains (drain takes ~1.4s). To sample the early outflow, I should screenshot right after the keypress. Each tool call involves latency (maybe 100-500ms). Risky but let's try: press b, then screenshot immediately.

Now it's flowing: outflow 335 u/s, water level 186.1 (started at 182 — it fell 4px), puddle blobs 5, smoke puffs at the hole. The waterline is starting to fall.

But I don't see the water jet in this screenshot! The hole is visible with shards and smoke, but the jet isn't visible. Hmm. Also, the water surface line appears at 186 (just below 182). 

Wait — where's the jet? `drawJet` requires `sim.water.inflow > 0` (true) and uses jetParams. The jet should be drawn from J.sx = TX_R+8 = 666 to J.ex. With ds = inflow/INNER_W = 33500/550 = 61 px/s... wait, outflow shown is 335 u/s = 33500 px³/s. ds = 33500/550 = 61 px/s. reach = 61*0.95*stiff. stiff = breachT/1.1 → at breachT=0.05, stiff=0.045 → reach = 2.6px. So the jet is tiny at the very start. It grows as breachT increases. That's why it's not visible yet.

Hmm, the stiff ramp means the jet takes 1.1s to reach full strength, but the water drains in ~1.4s total. That's a reasonable ramp but makes early outflow look weak. Also I should make the jet width not depend too tiny. Let me reduce JET_STIFF_TIME to 0.35 so the jet develops quickly, since the drain is fast.

Also, the jet's `stiff` factor combined with the falling head means the jet is short-lived. Let me reconsider the timing: MAXRATE 2.1e5, volume 318k → 1.5s total drain. That's quite fast — the user may barely see it. Let me slow it down a bit: MAXRATE = 1.2e5 → 2.6s. And the initial ds = 120000/550 = 218 px/s → reach = 218*0.95 = 207, blast = 218*1.45 = 316 → ey = 328+316 = 644... clamped? FLOOR_Y-6 = 756, so no clamp; jet ends at 644, 110px above the floor. Hmm, I want the jet to reach the floor to form a puddle at floor level. With the current head-dependent strength it lands mid-air and the water "falls" from there (which is fine physically — the puddle forms where it lands, and droplets continue below? My sprays are spawned at impact and fall with gravity, adding puddle when they reach the floor).

Actually the jet's blast is fixed by ds at the start; as the level drops, ds decreases → the jet gets shorter. But the water must still reach the floor. Physically, with a fixed hole height above the floor, water always falls to the floor (gravity) — the horizontal reach is what varies. My current param ties blast to ds too, which is wrong: the jet should always reach the floor (it falls), while the horizontal reach varies with flow.

Let me restructure the jet: 
- sy = opening center
- ey = FLOOR_Y - 6 (always lands on the floor)
- ex = sx + reach, where reach ∝ ds (horizontal reach varies)
- Control points: mx = sx + reach*0.6, my = sy - 20 (slight upward then falling) — a gravity-curved trajectory.

For the "stiffness" ramp: keep a short stiff ramp (0.3s) so the jet appears immediately on breach.

Then the vertical drop is fixed (from the opening to the floor) and the jet always lands on the floor, forming a puddle there, with the horizontal spread varying with the outflow. That's more physically sensible: the water exits horizontally-ish and falls under gravity.

Hmm, but "gravity-curved jet" - yes, the parabola from the hole to the floor.

Let me also compute the jet thickness proportional to head/flow.

Also for the velocity in the jet (for carrying objects): ds-based magnitude, direction along the tangent. The tangent is now dominated by the vertical fall (since it always lands at the floor). Fine.

Let me rewrite jetParams:

```js
function jetParams(){
  const o = sim.open;
  const sx = TX_R + 8, sy = o.y + o.h*0.5;
  const stiff = clamp(sim.breachT/0.35, 0, 1);
  const ds = sim.water.inflow/INNER_W;
  const reach = clamp(ds*1.05*stiff, 6, 300);
  let ex = sx + reach, ey = FLOOR_Y - 8;
  const mx = sx + reach*0.62, my = sy - 26;
  // curve: control point above start, end on floor => downward arc
  return {sx,sy,ex,ey,mx,my};
}
```
With ey fixed at the floor, the bezier from (sx,sy) with control (mx,my) above sy, ending at (ex,754): it rises a bit then falls — nice arc.

But careful: `jetTAtX` solves x(t)=x with the quadratic; if reach is small, the jet spans only a few px horizontally, and objects in the tank near the wall get carried out by the tank current anyway.

Also with ey = floor, midW/endW fine.

One more consideration: the initial jet strength. ds = 218 px/s at full head. That's the "fall speed" of the waterline, which for a 550px-wide tank and a 46x112 hole is modest but it's a simplified model. Objects: tankCurrent = flowSpeed*0.36*(...) ≈ 78 px/s early, decreasing to 0 as the level approaches the opening. Fish speeds 78-122 → some resist, some get swept. Good.

Also with MAXRATE=1.2e5, drain time = 318000/120000 = 2.65s. Good for observation.

Let me also double check the "outflow weakens as the water level approaches the opening and stops when water no longer reaches it" — head = (o.y - level)/DEPTH0 → as level → o.y from above, head → 0 → inflow → 0. When level >= o.y (surface at/below the opening top), inflow = 0. ✓

Now also the puddle: water lands at (ex, FLOOR). The puddle spreads from there. Good. But the impact x = J.ex varies with the flow — the puddle blobs spawn near the current impact point, so the puddle forms a band around it, spreading both directions. Fine.

Let me now apply:
1. MAXRATE 1.2e5
2. jetParams rewrite (fixed floor landing, quick stiff ramp)

Also, `drawJet` wobble uses J.mx/my with offsets — fine.

Additionally, the initial `wob` in drawJet modifies mx/my locally but jetParams uses the canonical ones — fine (visual only).

Let me apply the edits.

The jet ribbon drawing is fine. Now, since the jet always reaches the floor, the jet's exit point at the tank wall (J.sx, J.sy ± h/2) and the impact at the floor. Good.

Now let's reload and test the full breach sequence. I'll take a screenshot right after pressing b, and also check a later state (drained + puddle + objects).

Note: after breach, the jet starts. Let me also monitor over time. Let me press b then screenshot.

Now the jet is visible! Water exits the opening and curves down to the floor (visible as a white/blue stream on the right). The waterline has dropped slightly to 185.5. Shards fly out. flowSpeed -12 (negative — the level went UP from 182 to 185.5? Interesting: the initial `w.level` is 182 and it shows 185.5. Why did the level rise?

Ah — because the toy... no. Hmm, water level 185.5 > 182. The drain only decreases depth. Let me check: `w.depth -= inflow*dt/INNER_W; w.level = BOTTOM_INNER - w.depth;` — BOTTOM_INNER=752, depth0 = 752-182 = 570. So level = 752 - depth. If depth decreases, level increases! 

BUG: in canvas coords, a larger level = lower surface. When water drains, the surface moves DOWN, so level.y should INCREASE. But I wrote `w.level = BOTTOM_INNER - w.depth` which decreases as depth drains. Wrong sign!

Wait: level = BOTTOM_INNER - depth means when depth is large (full), level = 752-570 = 182 (high up, correct since y=182 is near the top). When depth decreases (draining), level = 752 - smaller = larger y = lower on screen. That IS correct! 752 - 565 = 187. So level=185.5 means the surface moved DOWN by 3.5px. Correct! The surface should move down. 

So the waterline falls = level.y increases. Good, that's exactly right. I confused myself earlier: "water level falls" → y increases. And my HUD % uses w.depth/DEPTH0 → 99%. ✓.

And flowSpeed = -12 (negative because drop = prev - level = 182 - 185.5 = -3.5 → negative). So flowSpeed is negative, meaning tankCurrent.x is negative → objects get pushed LEFT instead of right! Bug: I need the flow toward the breach = +x. The drop sign convention is inverted.

Fix: in updateWater, `const drop = w.level - prev;` (positive when the surface moves down/draining). Then flowSpeed positive → current toward +x (toward the right wall breach). 

Let me fix that.

Also I should double check the jet direction is unaffected — yes.

Let me fix the sign and then check the full sequence: fish swept, puddle spreading, etc.

Now flowSpeed = +12 (correct direction toward the breach). The fish are now on the right side of the tank (they moved right — pushed by the current), and the plants are bending to the right (I can see the plants leaning right now vs. before). The jet is visible curving down to the floor. The puddle is forming (6 blobs) — I see a thin white line at the floor right of the tank (the puddle is very thin/small at 6 blobs).

Wait, the jet appears to go straight down rather than a visible arc — because reach is small (flowSpeed 12 → early ds ~... let me compute: inflow=19200, INNER_W=550 → ds=35 px/s, reach = 35*1.05 = 37px. So the jet exits and falls nearly straight down 37px to the right. The arc is subtle. As the flow increases... but the head is at max at t=0 (head = (o.y-level)/DEPTH0 = (276-182)/570 = 0.165!). Hmm — the opening is only 94px below the surface, so the head is small (0.165), giving inflow = 1.2e5*0.165 = 19800. That matches the observed 19200. And the drain time: the level falls from 182 to 276 (94px) → time = 94*550/19800 ≈ 2.6s. OK.

But the jet is weak because the hole is near the top of the water. That's physically sensible: a hole near the surface has little head. But the visual would be more dramatic if the crack/opening were deeper. The default crack position is at cy = LEVEL0+150 = 332, opening 276..388. It's 94px below the surface — a "shallow" breach. That's fine but the jet is weak (35 px/s fall speed).

To make it more dramatic, I could:
1. Increase MAXRATE so the drain is faster, but that doesn't increase the head at the opening... Actually the head factor `(o.y - level)/DEPTH0` limits the flow. A deeper hole gives more flow.

Let me reconsider: for the default position, the jet reach = ds*1.05 where ds = inflow/INNER_W. If I scale MAXRATE up by 2, the drain is faster and the jet is stronger. But the "head" factor is the key limiter. 

Physically, Torricelli: v = sqrt(2*g*h) where h = depth of the hole below the surface = 94px → v = sqrt(2*900*94) = 411 px/s. Flow rate = v * hole area = 411 * (46*112) = 2.1e6 px³/s. Hmm, that's 10x my MAXRATE. My model is much more conservative.

For visuals, I'd like the jet to arc noticeably (reach 150-250px). Let me boost the jet parameters: reach = ds * 3.0 clamped to 300. With ds=35 → reach = 105. With a deeper hole (user drags lower, say o.y-level = 300px): head = 0.53 → inflow = 63000 → ds = 115 → reach = 345 (clamped 300). Good, dramatic.

Also the object current: tankCurrent = flowSpeed*0.36*(0.25+0.75t). With flowSpeed=35 → 12 px/s. Fish speed ~100. That's too weak to sweep anything. Hmm. The "some fish are swept" requirement needs a strong enough current.

Options: increase CURRENT_GAIN for objects, e.g. 1.2, so the effective current = ds*1.2 = 42 px/s at the opening depth... still weaker than fish speed.

Better: make the current speed relate to the jet speed rather than the waterline fall speed. Physically, the current in the tank toward the hole is much faster than the surface descent (because the hole is small). The continuity equation: v_inlet * A_tank_section ≈ v_hole * A_hole. So the tank current = (hole area / tank cross-section) * jet speed = (46*112)/(550*?)... For the surface-fall speed ds: inflow = ds * INNER_W = v_hole * A_hole → v_hole = ds*INNER_W/A_hole. With ds=35: 35*550/5152 = 3.7 px/s?? That's wrong — wait, inflow = ds*INNER_W means ds = inflow/INNER_W = 35 px/s is the surface fall speed, and the hole velocity = inflow/A_hole = 19200/5152 = 3.7 px/s. So the hole velocity is slower than the surface fall?! That's because I treat the jet "magnitude" as ds*1.15 = 40 px/s, which is inconsistent but visually fine (simplified physics).

The real relationship: the jet exit velocity should be the larger one. Let me make the jet/current speeds consistent by defining a "jet speed" v_j = inflow / A_hole = inflow/(HOLE_W*HOLE_H) and use that for the jet magnitude and the tank current (scaled by continuity: the tank current ≈ v_j * A_hole / A_tank... this gets complicated).

Simplest consistent approach: 
- v_j = inflow / (HOLE_W * HOLE_H) (exit velocity, px/s)
- Tank current toward the hole: v_t = inflow / (INNER_W) = ds (the surface fall speed)... which is small.

Hmm, the surface fall speed IS the tank-wide average current. At 35 px/s that's actually a decent drift speed — comparable to a slow fish. If I want fish swept, the current needs to be ~ fish speed or more. Let me increase the effective flow magnitude by boosting MAXRATE (faster drain) — with a deeper opening it gets much stronger.

Let me reconsider the numbers for a good experience:
- Default opening: 94px below the surface. head factor = (o.y - level)/DEPTH0. Let me instead use head relative to a "reference depth" of ~250px: head = clamp((o.y-level)/250, 0, 1) → 94/250 = 0.376 → inflow = 0.376*MAXRATE. This gives more flow for a shallow hole, and the drain time = 94*550/(0.376*MAXRATE).
- Set MAXRATE = 3.0e5 → inflow = 113000, drain time = 51700/113000 = 0.46s. Too fast!

Hmm. There's a fundamental tension: the drain time = (surface-to-opening distance)*INNER_W/inflow. For a nice 2.5s drain with a 94px distance: inflow = 94*550/2.5 = 20680. So inflow ≈ 20000 for the default position, and ds = 37 px/s. So the tank current is inherently ~37 px/s (that's the waterline fall speed!). Fish speed 78-122 → the flow can't overpower fish unless I make the current gain > 1.

Since the water in the tank must move toward the hole faster than the surface descends (converging flow), a gain of ~2-3 is physically justified. So: tankCurrent = flowSpeed * 2.2 * depthFactor. With flowSpeed=37 → 81 px/s near the bottom, 20 px/s near the surface. Fish near the hole (mid-depth, t~0.5) → factor 0.625*2.2 = 1.375 → 51 px/s. Still less than fish speed (~100). Some fish will resist (stronger ones), weaker ones (78) will be swept. That's exactly the desired behavior: "fish initially swim against the current before some are swept through the breach."

Let me set CURRENT_GAIN = 2.2 (renamed conceptually). Then the catch probability and the jet sweep do the rest.

And the jet: the exit velocity = inflow/(HOLE_W*HOLE_H) = 20000/5152 = 3.9 px/s — that's way too slow for a jet that arcs to the floor. My jet uses ds*1.15 = 42 px/s which is better visually. Hmm, but the jet must visually span from the hole to the floor (~350px vertically). With exit velocity 42 px/s and gravity 900, the time to fall 350px = sqrt(2*350/900) = 0.88s, horizontal reach = 42*0.88 = 37px. That's the "nearly straight down" jet I saw.

For a dramatic arc (reach 150-250px), the exit velocity should be ~200-300 px/s. Physically, Torricelli for h=94px: v = sqrt(2*g*h) = 411 px/s. So the jet exit speed should be ~400 px/s — much larger than the surface fall speed. That's consistent with continuity IF the hole area is much smaller than the tank cross-section... but my hole (46x112 = 5152) vs tank cross-section (550 x depth) — for a 94px deep water column above the hole, the cross section is 550*94 = 51700, so v_tank = 411 * 5152/51700 = 41 px/s. Yes! So the tank current is ~41 px/s and the jet is ~411 px/s. That's a consistent model!

So: jet exit speed should be sqrt(2*g*h) where h = the depth of the opening below the surface. And the tank current = jet_speed * A_hole/A_section = jet_speed * HOLE_W*HOLE_H / (INNER_W * h).

This is internally consistent and gives a dramatic jet while keeping the tank current moderate. Let me implement:

```js
function flowMagnitudes(){
  const o = sim.open, L = sim.water.level;
  const h = Math.max(1, o.y - L);            // head: depth of opening below the surface
  const vJet = Math.sqrt(2*GRAV*h);           // Torricelli
  const area = HOLE_W*o.h;
  const section = INNER_W*h;
  const vTank = vJet * area/section;          // average bulk current toward the hole
  return {vJet, vTank, head:h};
}
```
With h=94: vJet = 411, vTank = 411*5152/(550*94) = 40 px/s. 

Current near the hole is faster than the average (converging), so use a gain of ~1.6 on vTank for objects near the hole: tankCurrent.x = vTank * 1.6 * depthFactor. = 64 px/s near mid-depth. Good.

Then the jet drawn from the hole with initial velocity vJet horizontally + gravity → a nice arc to the floor. Let me compute the jet end where it hits the floor:
- sy = o.y + o.h/2 (the opening center)
- vy0 = small (say +vJet*0.05, slightly downward)
- time to fall to the floor: solve sy + vy0*t + 0.5*g*t² = FLOOR_Y → t = sqrt(2*(FLOOR_Y-sy)/g) with vy0 small.
- ex = sx + vJet*t*0.85 (some drag slows the horizontal spread).

This gives a physically-consistent gravity-curved jet! And I can draw the jet as an actual parabola (rather than a bezier). Even better for the "gravity-curved jet" requirement, and the jet velocity along the arc can be computed analytically for object carrying.

Let me implement jetParams as a projectile:
```js
function jetParams(){
  const o=sim.open, L=sim.water.level;
  const h=Math.max(2, o.y - L);
  const stiff=clamp(sim.breachT/0.25,0,1);
  const v = Math.sqrt(2*GRAV*h)*0.5*stiff;   // scaled for visual drama
  ...
}
```
Hmm, I need to relate v to the outflow rate reported. Let's keep the inflow/MAXRATE as the "drain rate" model (it controls how fast the waterline falls) and derive the jet from Torricelli. But then they're decoupled: the jet strength from Torricelli, the waterline fall from inflow. For consistency, set inflow = vJet * A_hole... that would give inflow = 411*5152 = 2.1e6, and the drain time = 94*550/2.1e6 = 0.025s — way too fast!

So there's a real inconsistency in a simplified model: with Torricelli's velocity through a 46x112 hole, the tank would empty in 25ms. Real aquariums have this problem too (that's why a big crack empties fast!). To have a slow, watchable drain, I need to throttle the outflow. I'll keep the throttle (MAXRATE) for the waterline, and use a scaled-down jet speed for visuals: vJet_visual = vJet * k where k makes the arc look right but the waterline falls slowly. This is "simplified, internally consistent physics is sufficient" — but the jet speed vs drain rate being inconsistent is a visible artifact only if someone computes it. I'll instead define:

- The exit speed is derived from the same "head" but scaled: vJet = C*sqrt(2*g*h) with C=0.35 → 144 px/s for h=94 → reach = 144*t; t = sqrt(2*(754-328)/900) = 0.92s → reach ≈ 132px. Nice arc.
- The tank current = vJet * A_hole/A_section * convergence (1.6).
- The waterline fall rate = inflow/INNER_W where inflow = MAXRATE*head_factor — decoupled but both driven by the head. I'll accept it; the visual story is coherent: the jet arcs, the level falls, the current pushes objects.

Actually, I can make them consistent-ish by defining the drain rate from the jet: inflow_vol = vJet_visual * A_hole, and then the drain time = vol/inflow_vol. With vJet=144 px/s and A=5152 → inflow = 742k → drain = 51700/742k = 0.07s. Too fast again.

The fundamental issue: any model where water exits at a decent speed through a big hole drains fast. Real life: it drains in a fraction of a second. Since we want a watchable simulation, I'll throttle the drain (a "resistance/turbulence" factor) and keep the jet speed from Torricelli. It's a stylized simulation — fine. I'll note the throttling as an intentional simplification.

Hmm, but there's a subtle issue: as the level approaches the opening, h → 0 → vJet → 0 → the jet weakens and stops. ✓ Consistent with "outflow weakens as the water level approaches the opening and stops when water no longer reaches it."

So let me derive BOTH the inflow and the jet from the head h:
- inflow = K1 * h (throttled), where K1 chosen so the default drains in ~2.5s: h goes 94 → 0; time = ∫... with inflow = K1*h, dh/dt = -K1*h/INNER_W → h decays exponentially with time constant INNER_W/K1. For a ~2.5s visible drain, K1 = 550/2.5 = 220 → inflow at h=94 = 20680 px³/s. OK so K1 = 220 (units px²/s).

So: `inflow = 220 * h` where h = o.y - level. Let me just implement inflow = FLOW_K * h with FLOW_K = 220, and the jet speed = 0.35*sqrt(2*GRAV*h).

Both weaken as h→0. 

Tank current: v = 0.35*sqrt(2*GRAV*h) * (A_hole/A_section) * conv, with A_section = INNER_W*h → v = 0.35*sqrt(2*900*h)*5152/(550*h) = 0.35*sqrt(1800h)*9.37/h = 0.35*42.4*sqrt(h)*9.37/h = 138.9/sqrt(h). At h=94: 14.3 px/s. Hmm, that's weak. The convergence factor near the hole can be larger (3-4x) → ~50 px/s. Fine — I'll use a gain factor.

Hmm, but this makes the current speed DECREASE with larger h, which is backwards. The bulk current should be larger for a deeper hole. Let me not over-engineer: I'll use the continuity result v_tank = vJet*A_hole/(INNER_W*h) and multiply by a convergence gain of 4 near the hole. At h=94: vJet=144, v_tank = 144*5152/(550*94) = 14.3, *4 = 57 px/s. At h=300 (deep crack): vJet = 0.35*sqrt(2*900*300) = 257, v_tank = 257*5152/(550*300) = 8, *4 = 32. Still smaller than at h=94. 

The issue: for a deeper hole the water column above it is deeper, so the average current is smaller, but near the hole the local current is faster. Whatever — the flow direction and the presence of a strong current near the hole is what matters. I'll simplify: 

current.nearHole = vJet * 0.35 (a direct fraction of the jet speed, representing the converging flow near the opening). At h=94: 50 px/s. At h=300: 90 px/s. Increasing with depth. 

And the waterline fall = inflow/INNER_W where inflow = FLOW_K*h. At h=94: 37 px/s (independent of the jet). Fine — these are two different "views" of the same event in a stylized model.

Let me now restructure the code:

```js
const FLOW_K = 220;          // px^2/s  outflow volume coefficient (throttled for a watchable drain)
function headDepth(){ return Math.max(0, sim.open.y - sim.water.level); }
function jetSpeed(){ return 0.35*Math.sqrt(2*GRAV*headDepth()); }
```
- inflow = FLOW_K * head (only when breached and head>0)
- jetParams: v = jetSpeed()*stiff; sy = o.y+o.h/2; sx = TX_R+8; vy0 = 0.12*v; 
  tFloor = solve for the floor; ex = sx + v*tFloor*0.9; ey = FLOOR_Y-8.
  For drawing, I'll draw a parabola sampled as points (nice gravity curve), and compute the tangent for velocity.
  Also clamp ex to ROOM_R-10.

Since the jet is now a sampled parabola, I'll change jetTAtX/jetPoint/jetVelAt to use the parabola. Let me store the sampled points in jetParams (e.g., 16 samples) and interpolate.

Implementation:
```js
function jetParams(){
  const o=sim.open;
  const sx=TX_R+8, sy=o.y+o.h*0.5;
  const stiff=clamp(sim.breachT/0.25,0,1);
  const v=jetSpeed()*stiff;
  const vy0=v*0.12;
  // time to reach floor
  const dy=FLOOR_Y-8-sy;
  let t=(-vy0+Math.sqrt(vy0*vy0+2*GRAV*dy))/GRAV; if(!isFinite(t)||t<=0) t=0.3;
  let ex=sx+v*t*0.92;
  if(ex>ROOM_R-8) ex=ROOM_R-8;
  const pts=[]; const N=18;
  for(let i=0;i<=N;i++){const tt=t*i/N; pts.push({x:sx+v*tt*0.92, y:sy+vy0*tt+0.5*GRAV*tt*tt});}
  return {sx,sy,ex,ey:FLOOR_Y-8,v,vy0,t,pts,stiff};
}
```
Velocity at t: (v*0.92, vy0+GRAV*t). Magnitude ~ sqrt(v² + (vy0+g t)²). At the end, the vertical speed = vy0+900*0.92 ≈ 830 px/s — very fast, but that's the falling water. For carrying objects I'll use a capped velocity (e.g. min(mag, 520)).

Drawing: a ribbon along the polyline with a width that tapers. Let me implement using the sampled points with offset normals — a thick stroked polyline with a gradient would be simplest: stroke the polyline with lineWidth = thickness and round caps, twice (a darker under-stroke and a lighter over-stroke). That looks like a water jet. 

Let me do: 
```js
ctx.lineCap='round'; ctx.lineJoin='round';
ctx.strokeStyle=grad; ctx.lineWidth=w; stroke path; then a thin white core line.
```
That's much simpler than the bezier ribbon and looks good.

Then jetTAtX/jetPoint use the sampled polyline: find the segment where x crosses, interpolate. jetVelAt(x) from the local slope.

Let me now rewrite those functions. Also update drawJet, and the object capture in `inBreathZone` (uses jetTAtX/jetPoint — keep the same API).

Let me write the new code.

Also `jetVelAtPoint` used in sweepOut — keep.

Note: `sim.water.inflow` is still used for the HUD and puff/splash rates and `drawJet`'s strength. Keep inflow = FLOW_K*head.

Let me rewrite the relevant block of code. I'll replace from "function jetParams()" through "function isInPuddle" and also drawJet, and updateWater's inflow computation.

Let me view the current code around there.

MAXRATE is still referenced in the debug? No, only the definition at line 88 and no usage now (drawJet uses headDepth now). Let me verify no remaining references to MAXRATE in code that would break. grep shows only line 88 (definition). Good — it's unused now, harmless but let me remove it to keep clean. Actually time is short; it's harmless. But let me quickly remove and test.

Let me reload and test the breach quickly.

The jet now arcs from the opening down to the floor (visible as a curved bright stream on the right, curving to the right and down). The fish are being pushed toward the right (fish moved right, plants bending right). The waterline has fallen slightly (183.9). Shards fly out.

Now let me check a later state: after a couple of seconds — the puddle spreading, fish being swept out, the toy descending, and the flow stopping. Let me wait and take a screenshot. I'll use `motion` perhaps, or just take another screenshot after a pause. Let me do a screenshot (time passes between tool calls).

Actually, let me check the puddle and swept objects by waiting. I'll take a screenshot now (about 1-2s later).

Excellent! Now:
- Water level 273.4, down from 182 (84%). The waterline has fallen visibly (the surface is now near the opening top at 276).
- Outflow has weakened to 6 u/s as the level approaches the opening — exactly the required behavior.
- 1 fish has been swept out (fishOut 1/6) — I can see a fish on the floor outside the tank on the right (there's a green fish near the bottom right outside the tank, and fish near the opening inside).
- The puddle has 630 blobs spreading along the floor to the right (I can see the wet floor area spreading to the right of the tank).
- The jet is now thin/weak, arcing to the floor.
- The toy descends with the waterline (toy y 268, at the surface at 273).
- Plants on the right bend toward the breach.
- Smoke puffs fading at the hole.

Everything works. Now let me verify Reset restores the initial state. Let me press 'r' and screenshot.

Note: puddle blobs 630 is a lot — each is an ellipse; performance could suffer but it's fine (630 ellipses per frame is OK).

Let me test Reset.

Reset restores the exact initial state: water 100%, level 182, outflow 0, fishOut 0, puddle 0, intact glass with the crack visible, toy at the surface.

Everything is verified. Let me do one final check: drag the crack vertically (the required interaction). Let me drag on the right wall at the crack position. The crack is at canvas (657, 388) → image coords: need the canvas offset. From the debug box mapping earlier: canvas (8,60) → image (75,88); so image = canvas + (67, 28). So canvas (657, 388) → image (724, 416). Let me drag from (724,416) to (724,560) — moving the crack down. Then press b and check that the opening is lower (opening y should be larger, e.g. ~560-56=504..616).

The drag tool: browser drag with fromX/fromY to toX/toY. Let's do it. Note the pointerdown requires being within 40px of TX_R (canvas x 657 → image x 724). Good.

After the drag, I'll press b and screenshot to check the opening position.

Hmm, the debug still shows opening y 332..444 — but note that `sim.open.y` is only updated at breach time (doBreach sets `sim.open.y = sim.crack.cy - sim.open.h/2`). So the debug "opening y" shows the initial value until breached. The crack handle did move down (I can see the DRAG handle lower on the wall in the image, around image y=575 → canvas y=547). So the drag worked.

Now let me breach and confirm the opening is where the crack was dragged (the hole should appear lower, near y≈547).

Time is short (about 3 minutes). Let me press b and screenshot.

Hmm! The debug still shows "opening y 276 .. 388" and the breach hole appears at the TOP of the tank (near image y=280, i.e. canvas y≈276) — not at the dragged position (canvas y≈547).

Wait, the hole in the image appears around image y = 280 → canvas y = 252? Let me compute: canvas = image - 28 for y. The hole is at image y≈270-300 → canvas y ≈ 242-272. And the debug says opening 276..388. So the hole is at 276..388, meaning the crack drag did NOT take effect.

Why? The drag happened, then I pressed 'b'. But maybe the drag didn't actually move the crack — the handle in the previous screenshot appeared at image y≈575 → canvas 547. Hmm, but let me check: was it really the handle, or the smoke? The previous screenshot showed "DRAG" text at around image y=575. Actually looking at the earlier screenshot (after drag), I see "DRAG" text at around image y = 560-580, and the crack glow below it. So the crack did move to canvas y≈550.

But then doBreach sets `sim.open.y = sim.crack.cy - sim.open.h/2`. If crack.cy = 550, open.y = 494. But the debug shows open.y = 276.

Unless... the debug line 'opening y' prints sim.open.y which IS updated in doBreach. It shows 276. So sim.crack.cy - 56 = 276 → crack.cy = 332, the original. So the drag didn't move the crack.

Why not? Possibly the drag tool's pointerdown didn't register on the canvas because `cv.setPointerCapture(ev.pointerId)` requires the pointer to be down; or the drag tool dispatches mousedown/mousemove/mouseup rather than pointer events? The browser tool's drag likely uses mouse events (mousedown, mousemove, mouseup). My handlers use pointerdown/pointermove, which are also fired by mouse interactions in browsers (pointer events fire for mouse input). So it should work.

Alternatively, the drag start point (724,416) might not be within 40px of TX_R in canvas coords. Let me recompute the image→canvas mapping more carefully using this very screenshot: the debug box top-left is at canvas (8,60). In the image, the box's top-left corner is at approximately (75, 88) and its bottom-right at (283, 180). So canvas x = image_x - 67, canvas y = image_y - 28.

TX_R = 658 → image x = 725. The crack drag started at image (724,416) → canvas (657, 388). |657-658| = 1 < 40 ✓, |388-388| = 0 < 56+26 ✓. So nearCrack should be true and the drag should work.

Hmm, but wait: my mapping estimate might be off, and if the actual canvas y for image y=416 is different... Let me verify with the debug box more precisely. The box is 210x92 at canvas (8,60)-(218,152). In the image, the box appears to span from about (75,88) to (285,182). So canvas = image - (67,28). OK.

Alternatively, maybe the issue is that the pointermove handler needs the pointer to be captured, and `cv.setPointerCapture(ev.pointerId)` with ev.pointerId undefined (for synthetic mouse events, pointerId is set for pointer events; if the tool dispatches raw MouseEvents, no pointer events fire at all).

If the tool dispatches MouseEvent (mousedown/mousemove), my pointerdown/pointermove listeners would NOT fire at all (they're distinct event types). That's likely the issue!

To be safe, I should also handle mouse events (mousedown/mousemove/mouseup) in addition to pointer events. Many test harnesses dispatch mouse events. Let me add mouse event listeners as a fallback.

I have ~2-3 minutes. Let me add mouse handlers quickly, sharing the same logic.

I'll add:
```js
function onDown(ev){ const p=pointerPos(ev); if(nearCrack(p)){ sim.crack.drag=true; draggingId=ev.pointerId!==undefined?ev.pointerId:-1; ev.preventDefault(); } }
```
Simplest: add separate listeners for mousedown/mousemove/mouseup that call the same functions. Since pointer events already cover modern browsers, adding mouse listeners could double-fire but that's harmless (idempotent: setting drag=true twice, and moving the crack to the same position).

Let me restructure minimally:

```js
cv.addEventListener('pointerdown', onDown);
window.addEventListener('pointermove', onMove);
window.addEventListener('pointerup', onUp);
cv.addEventListener('mousedown', onDown);
window.addEventListener('mousemove', onMove);
window.addEventListener('mouseup', onUp);
```
And change pointermove from cv to window so dragging outside the canvas still tracks. But then `cv.style.cursor` updates only matter over the canvas — fine.

onMove uses ev.clientX/Y which both event types have. pointerPos works for both.

Careful: with both mouse and pointer events firing, onMove would run twice per move — harmless.

Let me implement now, then quickly verify with a drag + breach.

Now the crack handle moved down to around image y=470 → canvas y ≈ 442 (the "DRAG" label is at canvas y = crack.cy - 13 ≈ 429). The drag works now with the mouse handlers.

Now press b to breach and verify the opening is at the dragged position (canvas y ≈ 442 → opening y ≈ 386..498).

The debug still shows "opening y 276 .. 388" and the breach hole appears at image y≈300 → canvas 272, i.e. at 276..388 — still the TOP position, not the dragged position.

So sim.open.y is 276 even though crack.cy was dragged to ~442. Hmm. But wait — the drag moved the handle (I saw it in the screenshot at a lower position). Let me reconsider: in the screenshot after the drag, "DRAG" text was at image y≈465 → canvas 437. So crack.cy ≈ 450.

Then doBreach sets sim.open.y = sim.crack.cy - 56 = 394. But the debug says 276.

Unless the drag moved the crack but then... the `key` action 'b' triggers doBreach which uses the current crack.cy. Hmm.

Wait — maybe the screenshot after the drag was taken BEFORE the drag completed? No, the drag tool returns after completing.

Hmm, but maybe the issue is the coordinate mapping: my drag started at image (724,416) and ended at (724,575). If the canvas mapping is different from my estimate, the crack may have moved to a different canvas y. Let's compute what canvas y would produce the observed "DRAG" label position. In the post-drag screenshot, the DRAG label is at image y≈465 (the text appears just below the mid-right area). canvas y = 465-28 = 437. And 'DRAG' is drawn at hy-13 where hy = crack.cy → crack.cy = 450.

And doBreach would set open.y = 394 → the hole would be at 394..506 → in image y 422..534. But the hole appears at image y≈300 → canvas 272.

So either doBreach didn't use the dragged cy, or the drag didn't persist... 

OH WAIT. I see it! The `key` action pressed 'b' — but before that, did the page reload? No. Hmm.

Let me look again at the debug: 'opening y 276 .. 388'. In the FIRST breach test (before any drag), the debug showed 'opening y 276 .. 380' — 380 vs 388! Interesting: now it's 388. open.h = 112, so open.y + 112 = 388 → open.y = 276. In the first test, the debug showed 'opening y 276 .. 380' → open.y = 268?? That was before... Hmm, at the first breach the debug readout was 'opening y 276 .. 380'. Now it's '276 .. 388'.

Wait, in the first breach screenshot, the debug line was "opening y 276 .. 380". That's odd: 276+112 = 388, not 380. Unless the readout happened between frames... no, the readout is `s.open.y.toFixed(0) + ' .. ' + (s.open.y + s.open.h)`. If open.y = 276, then the end is 388. So in the first screenshot it must have been 268..380 (open.y=268)? But I read "276 .. 380"... Actually the first breach screenshot showed "opening y 276 .. 380" — hmm, that can't be with h=112 unless open.y was 268 and I misread. Let me not worry.

The key issue: open.y is 276 now = crack.cy(332) - 56. So crack.cy = 332 → the crack was NOT dragged when 'b' was pressed. But the screenshot clearly showed the DRAG handle lower...

Unless the screenshot I saw after the drag was stale (the drag tool's screenshot might have been captured before the drag?). Hmm, the drag action returned a screenshot. In that screenshot, the fish had also MOVED (they're in different positions than the initial shot — e.g. the fish cluster at the right). The fish move continuously via wander, so the screenshot is fresh (not the initial frame). So the drag screenshot was taken after the drag, showing the DRAG handle lower.

So the crack DID move. But then 'b' shows open.y = 276?!

OH NO. I bet I know: `window.addEventListener('mouseup', onUp)` — when the drag tool does mousedown → mousemove(s) → mouseup, the final position is applied. But `drag` in the harness may do: mousedown at (x,y), then mousemove to the target, then mouseup. The last mousemove sets crack.cy = clamp(p.y, ...). That should be the final.

Hmm, unless the harness's drag dispatches mouseup at the START point? Or it dispatches mousemove with the ORIGINAL coordinates then to the target? Either way the last move wins.

Wait... maybe the harness dispatches events on the element at the coordinates, and `mousedown` at (724,416) hits the CANVAS (good) — but `mousemove` events are dispatched to the element under the cursor, which is the canvas (good), and they bubble to window (my listener is on window, fine).

Hmm, so why? Let me check `pointerPos`: it uses `cv.getBoundingClientRect()` and scales by W/r.width. If the canvas is displayed at a different size than 1200 wide (e.g. 1192), the scale is 1.0067 — negligible.

So p.y for image y=575: rect.top = 88 (canvas top in image coords) → p.y = (575-88)*(800/795) = 490. Hmm! I forgot the vertical scaling: the canvas is 795 tall in image coords for 800 internal → scale 1.0063. So p.y = (575 - 88)*1.0063 = 490. And the clamp: `clamp(p.y, LEVEL0+26+limit, TY_B-40)` = clamp(490, 182+26+70, 720) = 490. So crack.cy = 490 → open.y = 434.

Then the debug would show '434 .. 546'. But it shows 276..388.

So something reset sim between the drag and the keypress! What could reset? `window.addEventListener('mouseup', onUp)` — no. 

AH WAIT. I know! The `key` action with text 'b' — the browser tool might send the key to the page, and my keydown handler calls doBreach. But before that... no reset happens.

Hmm, but what about the earlier drag attempt (the first one, before I added mouse handlers)? That was on the OLD page. Then I reloaded. Then dragged (new handlers) — the screenshot after the drag showed the crack lower. Then pressed 'b'.

Unless the reload happened again between? The drag tool returned a screenshot with the crack lower and the fish moved. So no reload.

Hmm, is it possible that the drag screenshot showed the crack at the ORIGINAL position and I misread? Let me re-examine that screenshot. The image showed "DRAG" text at around y=465 and the crack glow below it... Actually, in that screenshot I see "DRAG" text at image y ≈ 465 and a glowing crack mark below-left of it. The canvas y for image 465 = 437. Hmm, but in the INITIAL screenshot, where is the DRAG text? canvas y = 332-13 = 319 → image y = 319+88 = 407. In the post-drag screenshot, the DRAG text appears at ~465, which is ~58px lower. That's consistent with a drag to canvas cy ≈ 390... but not 490.

I'm running low on time. Let me take a decisive measurement: reload, drag to a specific far position (e.g. image y=700), and take a screenshot to see where the DRAG label ends up, computing the mapping precisely. Actually better: let me use the debug readout itself! I'll add a line to drawDebug showing crack.cy. Then a screenshot after the drag tells me exactly what crack.cy became. And after breaching, whether open.y follows.

Let me add 'crack cy' to the debug lines, reload, drag, screenshot, breach, screenshot. That's 4 tool calls — about 1-2 minutes. Let's go fast.

The debug shows `crack cy 332` — unchanged after the drag to image y=700! But visually the DRAG handle appears at image y≈330 now (higher than before?). Hmm, the DRAG text in this screenshot is at image y≈330 → canvas 242?? That contradicts crack cy=332 (text at 319 → image 407).

Hmm wait, looking at this screenshot, the "DRAG" text is at approximately image y=330, and the glow circle below it at ~350. So the handle is HIGHER than the initial (407). So the drag DID move the crack — upward by ~75px?? I dragged DOWN (416 → 700). 

Unless... the mapping is inverted, or the coordinates are interpreted differently: maybe the drag tool's `toX/toY` are relative, or the drag started at the wrong point and the pointerdown didn't hit the crack, then a mousemove with `sim.crack.drag` false → no move. But the crack clearly moved.

Hmm, and the debug says crack cy 332 (unchanged). But the handle visually moved. Contradiction... unless the handle I'm seeing is drawn at the OLD position and something else moved. Wait — could the visual "DRAG" be at a different place than I think? Let me look at the initial screenshot: the "DRAG" text at image y ≈ 407 (canvas 319). In this new screenshot: "DRAG" at image y ≈ 330 (canvas 242)? Let me look more carefully.

In the new screenshot, I see "DRAG" text around y=330-340, and the glowing circle right below/around it at y≈350. Hmm, and a vertical crack line below it.

Hmm, but the debug says crack.cy = 332. If crack.cy = 332, the circle center is at canvas 332 → image 420, and the text at 319 → image 407. In the new screenshot, is the circle at image y≈420? Looking at the image, the glowing circle with the cross/star appears around y=350-370... 

Honestly, my pixel reading is unreliable. The DEBUG readout is authoritative: crack cy = 332, unchanged.

But earlier (in the post-drag screenshot 2 steps ago, before I added 'crack cy'), the fish were in different positions and I thought the DRAG moved. Let me trust the debug: the drag does NOT update crack.cy.

Why? Possibilities:
1. The drag tool dispatches events that my handlers don't catch (e.g., it uses CDP Input.dispatchMouseEvent which produces real mouse events → my mousedown/mousemove/mouseup should fire).
2. `nearCrack(p)` returns false at the mousedown position because the mapping is off — then drag never starts, and no movement happens. But then the crack wouldn't move at all. The debug says it didn't move (332). Consistent!

So the issue is that `nearCrack` fails at the mousedown point, OR the mousedown doesn't reach the canvas.

The mapping: if the canvas rect in the document is different from my assumption, the pointer could land elsewhere. Let me compute from the debug box: the box is drawn at canvas (8,60)-(218,152). In the initial screenshot the box spans image y≈88 to 180 and x≈75 to 285. So rect.top ≈ 88, rect.left ≈ 67, height ≈ 92*(795/800)... 

Hmm wait, that gives canvas y = (image_y - 88)*800/795. For image y=416: canvas y = 330. And crack.cy=332 — that's exactly where I pressed! And |p.x - TX_R|: canvas x = (image_x - 67)*1200/1192 = 658 for image x=724. TX_R=658. So nearCrack should be TRUE at the mousedown point.

Unless the canvas is NOT 1192 wide. Let me reconsider: maybe the page is rendered with a wider viewport and the canvas is scaled down. If the screenshot is 1200 wide (the viewport) and the canvas CSS width is, say, 1192 → the canvas spans image x from 4 to 1196. The tank left outer at canvas x=92 → image x = 4 + 92*0.993 = 95. In the screenshot the tank's left glass line is at ~x=160? Hmm, earlier I estimated the tank left at image x≈159.

If the tank left (canvas 92) is at image 159, then the canvas left edge (canvas 0) is at image 159 - 92*scale. With scale s: canvas0 = 159 - 92s. And TX_R (canvas 658) at image 159 + 566s. If s = 0.993: canvas0 = 67.6, TX_R at 159+562 = 721. So image x=724 → canvas x = (724-67.6)/0.993 = 661. |661-658| = 3 < 40 ✓.

OK so nearCrack should pass. So the mousedown must not be reaching the canvas... 

OH WAIT!!! I know! The `.hint` div and the canvas... no. Hmm, what about the HUD? No, the drag is at y=416 which is on the canvas.

Hmm, hold on: maybe the issue is that the browser tool's drag dispatches mousedown at (x,y) but the page's `mousedown` handler on the canvas... my handler is `cv.addEventListener('mousedown', onDown)`. Fine.

Unless the harness dispatches `pointerdown` with `isPrimary` and my cv.setPointerCapture throws... I wrapped it in try/catch. Fine.

Wait — maybe the drag DID work but then something reset crack.cy to 332! What resets? `doReset()` → initScene(). Is a reset triggered? The `key` action 'r'... no, I didn't press r.

Hmm, but the drag tool... no.

Hmm, what about the `mouseup` handler on window: `onUp` sets drag=false. Fine.

Let me test differently: use the `click` action on the canvas at a position, then check if... no, click doesn't move the crack.

Let me try `type` or... Actually, let me check if the mouse events even reach the page: I'll add a temporary console.log/counter in onDown and onMove, and print it in the debug overlay. Then drag and read the debug.

Time is nearly up (I have ~2 min). Let me do this efficiently: add counters 'down: N move: M' to the debug, reload, drag, screenshot. If the counters stay 0, the events aren't reaching the page (harness limitation). If the counters increase but crack.cy doesn't change, then nearCrack fails at mousedown.

Actually — better idea: I can make the drag work regardless of the exact hit position by allowing a drag start anywhere on the right wall region (x > TX_R-60) with y anywhere in the tank. That's more forgiving. But if events don't arrive at all, that won't help.

Let me add the counters AND make nearCrack more forgiving at the same time, then test once. If it works, great; if not, I'll note the limitation (the keyboard/button path works fine, and the crack can also be repositioned... hmm).

Actually, thinking about it more: the earlier drag (2 steps ago, before adding 'crack cy' to debug) showed the fish in different positions — that's just the wander animation over time, not evidence of a drag. And I "saw" the DRAG handle lower, which was probably a misreading.

So most likely the mouse events never reach the canvas, OR nearCrack fails. Let me add the counters to find out. One test cycle: edit (add counters + looser hit test), reload, drag, screenshot, and read. That's ~4 calls; I have time for maybe 3-4. Let me be efficient and do the edit with both changes now.

The debug shows `ev:1/0` — one mousedown fired (so the event DOES reach the page), and crack cy is still 332. So `nearCrack(p)` returned FALSE at the mousedown, or `pointerPos` is wrong.

`window.__last` would tell me the computed pointer position, but I didn't print it. Let me print `__last` in the debug. But I'm almost out of time.

Quick reasoning: `ev:1/0` means one down, zero moves (my counter only counts downs; I never counted moves — I set `window.__ev = down + '/0'`). So no info about moves.

But the key insight: down fired, and crack.cy stayed 332. Since nearCrack is now very forgiving (x within 60 of TX_R, x > INNER_L, y between TY_T and TY_B-20), the only way it fails is if p.x is far from 658 (or p.y out of range).

Let me print `__last` (the raw pointer coords) in the debug to see. One more cycle: edit the debug line to include __last, reload, drag, screenshot. I have ~1.5 min of budget. Risky but this is the last required feature ("drag the crack vertically").

Actually, alternative faster approach: make the mousedown ALWAYS start a drag (regardless of position) — but then clicking anywhere would move the crack, which is acceptable-ish but sloppy. Better: accept the drag if the pointer is anywhere on the canvas vertically within the tank and horizontally in the right half of the tank (x > INNER_L + INNER_W*0.75). This is very forgiving and would work regardless of the mapping error. Plus print __last for diagnosis.

Hmm, but if p.x is way off (e.g. the harness gives coordinates in a different space), the drag start might not be forgiving enough. Let me instead make it maximally forgiving: any mousedown on the canvas with x > 400 (right half) starts a drag. And the crack moves to p.y clamped. Also print __last.

And since `ev:1/0` shows the down event fires on the canvas, the canvas listener works. Let me do this final edit and test. If it still doesn't move, I'll print __last and finish.