Boids flocking · mimo-v2.6-flash

Let me build the file. Single file index.html with canvas flocking sim.

Then verify with browser tools: screenshot, inspect, motion frames, click to pause etc.

Let me write the code carefully.

Key features:
- 150 boids, oriented triangles.
- separation, alignment, cohesion.
- max speed, max force steering.
- wrap edges.
- cursor influence radius visible/documented — draw a ring around pointer.
- Pause/Resume and Reset buttons.
- responsive canvas resize.

Let me write it.

Boid drawing: triangle pointing along velocity direction. Color maybe by... simple.

Verification: sample flock at moments — I can use browser inspect to run JS checks, e.g., read a global function that returns boids and compute alignment between heading and velocity, and check coordinated movement (average heading coherence). I'll expose `window.__boids` or a debug API.

Let's write the file.

Plan code:

```js
const canvas, ctx
let boids = []
let paused = false
const mouse = {x,y,active:false}
const RADIUS = {sep:24, ali:50, coh:60, mouse:140}
params: maxSpeed 4? Let's use pixels per second with dt, or per-frame fixed. Use dt-based with clamp.
```

Use fixed timestep simulation with dt clamped. Simpler: use frame dt normalized to 60fps factor.

Steering: force accumulate:
- separation: steer away sum of (pos-other)/dist weighted by 1/dist, normalized to maxSpeed minus velocity -> limited maxForce.
- alignment: avg neighbor velocity -> desired - velocity.
- cohesion: avg neighbor position -> desired direction - velocity.

Weights.

Mouse: if dist < mouseRadius, desired = away direction * maxSpeed, minus velocity, limit force stronger.

Wrap: wrap x across width.

Draw: filled triangle with maybe a tail; color varies slightly. Also draw mouse radius ring when active.

Controls: HTML buttons top-left overlay.

Resize: canvas.width = innerWidth * dpr etc.

Debug API for verification: window.flock = {get boids, sample()} returning metrics: mean speed, mean alignment (cos of angle between velocity and avg neighbor heading), fraction whose triangle heading matches velocity (by construction identical — the triangle is drawn along velocity so trivially true; but check that drawing angle equals velocity angle: report mean |angleDiff|). Also check coordination: mean resultant length of headings (0-1), and change over time.

Write file now.

Let me build the single-file index.html. Then run it in the browser, sample, interact.

Let me write the file.

Let me start by understanding the task. I need to build a full-screen canvas flocking simulation with 150 boids drawn as oriented triangles, all in a single self-contained index.html file.

Let me plan the implementation:

1. Full-screen canvas that fits viewport and handles resizing
2. 150 boids as oriented triangles
3. Flocking: separation, alignment, cohesion
4. Bounded speed and steering (max force, max speed)
5. Wrap-around edges
6. Cursor influence radius - boids steer away from pointer
7. Pause/Resume and Reset buttons
8. Controls usable after resizing

Then I need to verify by running it in the browser, sampling the flock at several moments to check coordinated movement and triangles pointing along travel direction, trying cursor interaction, pause and resume.

Let me check the current directory first, then write the file.

Let me write a solid implementation:

- Boid class with position, velocity, acceleration
- maxSpeed, maxForce
- flock() applies three rules with neighbor search (for 150 boids, O(n²) = 22500 checks per frame, that's fine)
- Pointer repulsion within radius
- Draw triangle pointing in direction of velocity
- Wrap edges with modulo
- Pause/resume: stop animation updates but keep rendering (or just stop updating)
- Reset: regenerate 150 boids with random positions/velocities
- Resize handling: fit canvas to viewport with devicePixelRatio

For verification of "triangles pointing along travel direction", I can sample in browser via inspect/evaluate. The browser tool has actions: reload, inspect, screenshot, motion, click, drag, key, scroll, type, x/y coordinates. Hmm, there's no direct "evaluate JS" action listed, but "inspect" probably returns DOM/console info. Let me try it.

Actually, to make verification easy, I could expose some debug info on window, e.g., window.__boids and a function to compute alignment between heading and velocity. The inspect action might give me console logs. Let me design: log to console occasionally, e.g., every 2 seconds, average dot product of heading vs velocity direction. Actually triangles are drawn pointing in direction of velocity directly, so by construction they point along travel. But to "sample the flock at several moments", I can log diagnostics.

Let me write the file.

Design details:

```js
const BoidCount = 150;
class Boid {
  constructor(x, y) {
    this.pos = {x, y};
    const angle = Math.random() * Math.PI * 2;
    const speed = maxSpeed * (0.5 + Math.random()*0.5);
    this.vel = {x: cos*speed, y: sin*speed};
    this.acc = {x:0, y:0};
    this.r = 6; // triangle size
  }
}
```

Flocking forces:

- separation: for neighbors within separationRadius (e.g., 30), steer away weighted by 1/distance
- alignment: average velocity of neighbors within alignmentRadius (e.g., 60), steer toward desired velocity = normalized avg * maxSpeed
- cohesion: average position of neighbors within cohesionRadius (e.g., 80), steer toward target

Weights: separation 1.6, alignment 1.0, cohesion 1.0 or so.

Perception: use squared distances for speed.

Pointer influence: radius e.g., 140 px (documented in UI), force steering away, magnitude scaled by (1 - dist/radius), limited by maxForce... Actually to make it strong, scale up.

Steering: `steer = desired - vel`, limit magnitude to maxForce. Then acc += steer * weight. Then vel += acc; limit speed between minSpeed and maxSpeed; pos += vel. Reset acc each frame.

Edge wrapping: if pos.x < 0 → pos.x += width, etc. To avoid jumpy perception across wrap... it's fine for simplicity, but boids near edges wrapping will pop — that's expected ("Wrap boids across screen edges").

For neighbor search across wrap, simplest is no toroidal distance — fine.

Canvas sizing: use devicePixelRatio for crispness, CSS size = viewport. On resize, keep boids positions (clamp/wrap into new bounds).

Pause: `paused` flag; animation loop still runs (rAF) but doesn't update. Alternatively cancel rAF. Better: keep loop, skip update when paused, so resume continues seamlessly. Render still happens (unchanged state). Also should the pointer indicator still render while paused? Fine either way — draw pointer ring always when pointer active.

Reset: create fresh 150 boids, random positions across current viewport, random velocities; reset pointer maybe keep.

Controls: overlay buttons top-left (or top-right), with a hint about radius. Use pointer-events: auto on controls; canvas listens on window pointermove so moving over buttons still influences? The requirement: "Boids within a visible or documented cursor-influence radius steer away from the pointer." I'll draw a faint circle around cursor showing radius, and document radius in a HUD text.

Pointer tracking: use pointermove on window; hide on pointerleave (pointerout when leaving window). Also touch support: pointermove works for touch; on touch, prevent scroll? Use touch-action: none on canvas.

Also HUD: show boid count, FPS maybe, paused state.

Verification plan:
1. Write index.html
2. Reload in browser, screenshot
3. inspect for console logs — I'll log periodic diagnostics: e.g., every ~120 frames, log average speed, average |dot(heading, velocityDir)| (should be 1), average nearest-neighbor distance decreasing over time (cohesion), heading coherence (mean of normalized velocities dot).
4. Use motion action to capture motion frames to see movement.
5. Click pause button, take screenshot twice to compare frozen state (or motion with no change), click resume, verify movement continues.
6. Move pointer — I can use `click`? There's no explicit hover/move action... Actions include click, drag, scroll, key, type. Drag with from/to could simulate pointer movement: drag from center to another point generates pointermove events? A drag typically involves mousedown, mousemove, mouseup — pointermove events fire. Hmm, but the requirement says "Try the cursor interaction with available pointer actions". Maybe `type`/`click` at coordinates produce pointermove? Click at a coordinate typically moves the mouse there first (Playwright-style click moves mouse to element then clicks, generating pointermove). So clicking within canvas will move pointer to that location, triggering pointermove → pointer influence activates.

I could also expose diagnostics showing how many boids are within pointer radius and their average outward radial velocity component.

Let me expose `window.__sim` with diagnostics function for verification:

```js
window.__sim = {
  getState: () => ({count, paused, avgSpeed, ...}),
  pointer: {...}
};
```

And log to console periodically maybe not too noisy. Console logs via inspect action hopefully captured.

Let me think about what `inspect` returns — probably DOM summary, console messages, maybe page errors. I'll try.

Let's write the code carefully.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Boid Flocking Simulation</title>
<style> ... </style>
</head>
<body>
<canvas id="canvas"></canvas>
<div id="hud">
  <div class="row">
    <button id="pauseBtn">Pause</button>
    <button id="resetBtn">Reset</button>
  </div>
  <div class="stats">
    <span id="countLabel">Boids: 150</span>
    <span id="statusLabel">Running</span>
  </div>
  <div class="hint">Move the pointer near the flock: boids within <b id="radiusLabel">140 px</b> steer away from it.</div>
</div>
<script> ... </script>
</body>
</html>
```

CSS: full screen, canvas fixed inset 0, hud fixed top-left with backdrop blur, buttons styled, pointer-events none on hud container but auto on buttons? If hud has pointer-events none and buttons auto, clicking buttons still works, and pointer over hud region still influences boids (good — pointer events pass to window listener anyway since window pointermove fires regardless of target).

Wait — window pointermove fires regardless of pointer-events? Yes, pointermove events bubble to window regardless of pointer-events on target... Actually if an element has pointer-events: none, events pass through to element below. Either way, window gets the event. So influence works everywhere.

Key handling: space toggles pause (nice extra), R resets. Careful: space might scroll — preventDefault when not focused on button? Buttons: space activates focused button. I'll handle keydown on window, if key === ' ' preventDefault and toggle pause. But if focus is on a button, space would also trigger button click → double toggle. Solution: blur buttons after click (btn.blur()), or check document.activeElement. I'll blur after click.

Also make canvas aria labels? Not necessary.

Physics tuning for nice flocking with 150 boids:

- maxSpeed = 4 (px/frame at 60fps... but I should use delta-time normalization? Simpler: fixed update per frame assuming ~60fps. Browser tools may run at odd rates but fine. Actually smoother: use dt clamped and scale forces by dt. Many implementations ignore dt. I'll do a simple dt-based integration with dt clamped to e.g. 1/30 max, base 1/60, scaling velocities in px/sec? Hmm, mixing units complicates tuning. Let me use per-frame semantics with dt scaling: treat speeds in px per (1/60 s) frame; compute frames = dt / (1/60), clamp to [0, 3]. Then pos += vel * frames; forces applied scaled appropriately: acc scaled by frames... For simplicity: 

```
const dt = Math.min(now - last, 50) / (1000/60); // normalized frames, ~1 at 60fps
vel += acc * dt... 
```

Hmm, force integration: vel += acc * dt (acc in px/frame²). pos += vel * dt. That's correct Euler for variable dt approximately. Steering limit maxForce in px/frame². OK.

But when paused and resumed, dt shouldn't jump — I reset `last` each frame regardless, so fine (we keep updating `last` always).

Distances/perception radii in px: separation 34, alignment 70, cohesion 75. Actually typical: separation smaller than alignment/cohesion.

Neighbor loop O(n²) = 150*149/2 ≈ 11k pairs per frame — trivial. I'll do full O(n²) with squared distance checks.

Weights and clamping: compute each rule as steering force limited to maxForce, then combine with weights.

Let me write the boid update:

```js
function flock(boid, neighbors... ) 
```

Simplify: for each boid i, iterate all j ≠ i, accumulate per-rule.

Separation: 
```
if d2 < sepR2 && d2 > 0:
  diff = pos_i - pos_j, normalized / d (or / d2 for stronger near)
  sepSum += diff / d  (steer away, closer → larger)
  sepCount++
```
Then desired = normalize(sepSum) * maxSpeed; steer = desired - vel; limit maxForce.

Alignment:
```
if d2 < aliR2: avgVel += vel_j; count
```
desired = normalize(avgVel) * maxSpeed; steer = desired - vel; limit.

Cohesion:
```
if d2 < cohR2: avgPos += pos_j
```
desired = normalize(avgPos - pos) * maxSpeed; steer = limit(desired - vel, maxForce).

Pointer: if pointer active and d < pointerRadius: 
```
away = pos - pointer; dist
strength = (1 - dist/pointerRadius)
desired = normalize(away) * maxSpeed * (1 + 1.5*strength)?? 
```
Simpler: steer = normalize(away) * maxForce * 3 * strength, limit to maxForce*3. Strong push. Let me just do: force = awayNormalized * maxForce * (0.4 + 2.2 * strength), and add directly to acc (not velocity-difference based), limited in magnitude. That gives smooth push. Actually smoother steering: desired = awayNormalized * maxSpeed * strength... hmm at far edge strength→0 so no force near boundary; that's smooth. steer = desired - ... no, for repulsion it's easier to add force directly.

I'll do: 
```
const desiredMag = maxSpeed * (0.35 + 0.65*strength) — hmm
```
Let me think: I want boids to flee, accelerating away. Force magnitude f = maxForce * 4 * strength (strength ∈ (0,1]). Limit combined force magnitude overall to some cap to prevent teleporting: after summing all forces, limit total acc magnitude to maxForce * 6 maybe. Then speed bounded anyway, so no teleporting.

Speed bounds: clamp speed to [minSpeed= maxSpeed*0.35, maxSpeed]. Actually maintaining min speed keeps flock moving (boids shouldn't stall). But separation crowding might want slow... fine, keep min speed modest.

maxSpeed = 4.5 px/frame ≈ 270 px/s. Reasonable.

Also add slight random jitter wander? Not required; flocking naturally creates motion. Small jitter can prevent lock-up. I'll add tiny random walk force (±0.02 * maxForce... small). Optional — keep it subtle: random accel of magnitude 0.03.

Heading rendering: triangle drawn rotated to atan2(vy, vx). Since we might have min speed > 0, velocity never zero → direction well-defined. Triangle: nose at r*1.4 forward, base corners at -r*0.9 ± r*0.75 perpendicular. Slight color variation by heading direction (hue based on angle) for visual appeal — nice but keep it tasteful. I'll color by speed or angle: hue = angle in degrees mapped, with moderate saturation/lightness on dark background. Or keep single accent color with alpha trails? Trails: draw semi-transparent background rect each frame instead of clearing → motion streaks. But trails could obscure "triangle pointing" verification? It still shows triangles clearly with alpha ~0.35 background. Hmm, trails make screenshots show movement paths, which helps verification of coordinated movement. But trails can accumulate messiness. I'll use a light trail: fill background with rgba(10,12,18,0.45) each frame. Triangles drawn fully opaque on top. Actually with 0.45 alpha, old frames fade quickly — subtle trails. Good.

Wait: when paused, we still render each frame — filling with rgba 0.45 repeatedly would fade the frozen image to black! Need care: when paused, either don't re-render, or render with full clear. Solution: only render when updated (skip render when paused) — but then resize while paused needs re-render. Simplest: track `needsRender`; on pause, render once with full opaque background? Let's structure:

- Each frame: if not paused → step simulation; then render.
- Render: use opaque clear + no trails? Trails require accumulation.

Alternative: keep trails but when paused, skip rendering entirely (canvas retains last frame — it's a retained surface, so frozen image stays). On resize, re-render (would fade trail but that's fine — do a full clear render on resize).

Actually fading issue: when running, each render does fillRect alpha 0.45 → trails. When paused, skip render → frozen image persists. On resume, continues fading. 

But resizing canvas clears it anyway (canvas resize resets bitmap). On resize we render fresh (fill opaque, then draw boids — trails restart). Fine.

Hmm, but there's a subtlety: when paused, rendering skipped means pointer ring also frozen — acceptable.

Simpler alternative: no trails at all — opaque background each frame. Then rendering while paused is harmless (identical output). Verification of movement via screenshots at different times still works (boids at different positions). Trails are nice visually though. I'll go with trails + skip render when paused, but ensure resize/resize render works.

Actually let me reconsider: is skipping render while paused risky? If something else clears the canvas (e.g., screenshot?), no. Canvas bitmap persists. OK.

Edge case: pausing immediately after resume before any update — fine.

Let me also handle devicePixelRatio scaling properly:

```js
function resize() {
  const dpr = Math.min(window.devicePixelRatio || 1, 2);
  W = window.innerWidth; H = window.innerHeight;
  canvas.width = Math.round(W * dpr);
  canvas.height = Math.round(H * dpr);
  canvas.style.width = W + 'px';
  canvas.style.height = H + 'px';
  ctx.setTransform(dpr, 0, 0, dpr, 0, 0);
  // wrap boids into new bounds
  for (b of boids) { b.pos.x = ((b.pos.x % W) + W) % W; ... }
  render(true /*forceOpaque*/);
}
```

Note: ctx.setTransform resets after canvas resize (resize resets context state), so set transform each resize. fillRect(0,0,W,H) in CSS pixels covers all.

Controls HTML/CSS: top-left panel, glass style, buttons with hover states, radius legend, count/status. Keep it compact and always visible (z-index above canvas).

HUD content:
- Title "Flocking · 150 boids"
- Buttons: Pause/Resume (toggles label), Reset
- Stats: FPS? count, state
- Hint: "Pointer influence radius: 140 px — boids inside the ring steer away."

Also draw pointer influence ring on canvas (visible radius): circle of radius 140, dashed, semi-transparent, plus small center dot. When pointer inactive (left window), hide.

Pointer activation: pointermove sets pointer.active = true, x, y. pointerleave on document / pointerout with relatedTarget null → active = false. Also on window blur → false. Also if pointer hasn't moved for a long time? Keep it active until it leaves — simpler and predictable. Hmm, "Boids resume flocking after the pointer moves away" — means spatially away (outside radius) → force → 0 naturally. Good.

Diagnostics for verification — expose:

```js
window.__sim = {
  boids, // array
  paused: () => paused,
  stats() { ... returns {count, avgSpeed, headingCoherence, avgTurnRate?, pointerActive, influenced, radialOutflow} },
  setPaused, reset, movePointer(x,y), clearPointer
};
```

I'll also console.log a stats line every 120 frames so inspect can capture: e.g. `[flock] t=2.0s count=150 avgSpeed=3.9 coherence=0.62 avgSep=...`.

Metrics:
- avgSpeed
- coherence: |mean(unit(v))| ∈ [0,1] — high = coordinated movement
- turn: average |angle between previous heading and current| — should be small (smooth steering, not teleporting)
- alignment avg neighbor heading agreement
- pointer stats: influenced count, mean radial velocity component (positive = moving away)

To detect smoothness, I can track per-frame max displacement: max |pos delta| per frame ≤ maxSpeed*dt... I'll compute in stats from prevPos stored each frame? Simpler: track `maxStep` each frame in update (max distance moved by any boid per frame), log it. Should stay ≤ maxSpeed * ~2.

Also to verify triangles point along travel: compute for each boid the angle of velocity and compare to drawn rotation — by construction same variable. But I can store b.heading = atan2(vy,vx) used for drawing, and stats reports mean cos difference between heading and velocity angle = 1. It's trivially true; better verification: screenshot inspection. I'll do screenshots and eyeball that triangles align with motion (compare consecutive motion frames). The `motion` action might give frames.

Let me now write the whole file.

For reset: fresh population — new random positions and velocities (also randomize hues per boid maybe based on index). Keep boid count 150.

Perf: 150 boids, O(n²) fine.

Also add "cohesion/alignment/separation" weights documented in HUD? The requirement says "visible or documented cursor-influence radius" — only radius needs documenting. I'll show radius in hint and draw ring.

Let me write the JS now, carefully.

```js
(function () {
  'use strict';

  const canvas = document.getElementById('sim');
  const ctx = canvas.getContext('2d', { alpha: false }); // alpha:false — background opaque
  ...
```

Hmm, with alpha:false, background fill is opaque anyway. Fine.

Colors: dark navy background `#0b0f17`, boids colored by heading hue: `hsl(${(angleDeg+360)%360}, 70%, 62%)`. Bright enough. Pointer ring: `rgba(255,196,80,.5)`.

Trail approach with alpha:false: fillRect with rgba works fine (composites onto opaque canvas).

Wait, one issue: if trails use alpha fill and boids drawn opaque, paused render skip keeps image. Good.

Actually — do I even want trails? For verification "sample the flock at several moments to check coordinated movement" — screenshots at moments show positions; motion frames show movement. Trails add visual appeal and make movement obvious. I'll use moderate alpha 0.5.

Hmm, but with trails, when I pause and screenshot, then resume... fine.

Actually a concern: subtle trails with 150 bright triangles on dark bg at alpha 0.5 fade in ~10 frames. Nice.

Let me be careful with rendering when paused first frame: we render at least once after each update. Sequence: frame loop runs always; if (!paused) { step; render; } else { /* skip */ }. But initial render before first step: canvas starts transparent/black — call render once at init with opaque fill.

Resize while paused: render(true) with opaque clear (avoid ghost trails from misaligned old bitmap — actually resize clears bitmap anyway). Just call render(true).

render(forceOpaque): if forceOpaque → fillRect full alpha 1, else alpha 0.5 trail fill. Then draw pointer ring, then boids.

Hmm wait: when forceOpaque on resize, trails wiped — fine.

FPS display: compute smoothed fps.

Keyboard: Space → toggle pause, R → reset, also 'p'? Keep space and r. Prevent default for space.

Buttons: pauseBtn text toggles "Pause"/"Resume"; add class .paused styling.

Accessibility: aria-pressed on pause button.

Now, one more requirement detail: "Use bounded speed and steering so motion changes smoothly instead of teleporting." — maxForce limiting + speed clamp. I'll also clamp total acceleration magnitude.

"Wrap boids across screen edges" — modulo wrap. When wrapping, to avoid rendering a triangle half... it just pops to other side; standard. Could draw wrapped copies near edges for continuity, but not required. Keep simple pop (it's "wrap"). Actually trails + pop look fine.

Let me write stats function:

```js
function stats() {
  let speedSum = 0, cx = 0, cy = 0, maxStep = 0;
  let sx = 0, sy = 0; // sum of unit velocities
  let headingErr = 0;
  let infl = 0, radial = 0;
  for (const b of boids) {
    const s = Math.hypot(b.vx, b.vy);
    speedSum += s;
    sx += b.vx / s; sy += b.vy / s;
    const h = Math.atan2(b.vy, b.vx);
    headingErr = Math.max(headingErr, Math.abs(Math.cos(b.heading - h))); // ~1 if aligned
    const dx = b.x - (b.px ?? b.x), dy = ...
    ...
  }
}
```

For heading check: heading is set to atan2(vy,vx) right before drawing; and drawing happens after step. So cos(heading - velAngle) = 1 always after render. It's still a valid check that triangles are drawn oriented along velocity (i.e., that we didn't draw them at a fixed angle). But cos would be 1 even if heading = -velAngle (cos even function). Use absolute angle difference instead: wrap difference to [-π, π], should be 0.

For "previous position step": store b.px, b.py at start of step (before integrating), then maxStep = max distance. With dt-normalized frames: maxStep ≤ maxSpeed * dtFrames (approx, plus wrap pops — exclude wrapped steps by checking if distance > W/2 skip). Wrap detection: if dx² > (W/2)² skip.

Let me now also compute nearest-neighbor average distance to show grouping? Could show "mean neighbor dist" decreasing over time indicates flock forms. Include in logged stats — nice for verification of "form moving groups".

Log every ~90 frames:

```
console.log(`[flock] t=${...}s n=150 paused=false avgSpd=3.87 coherence=0.71 turn=0.9°/frame maxStep=4.4px nn=42px ptr(active, infl=12, radial=+2.1)`)
```

Console logging — inspect action hopefully captures console. If not, I can expose window.__sim.stats() and... can inspect evaluate? Unknown. Let's see what inspect gives. If inspect can't run code, I could add a debug overlay div showing stats (visible on screen), then screenshot it! That's robust: HUD shows live stats (avg speed, coherence, influenced count). I'll include a compact stats line in HUD — helps verification via screenshots regardless of console access.

HUD stats line: `spd 3.9 · coh 0.7 · infl 12` updated ~4/s. Plus when pointer active show radial outflow? Keep it: `away +2.3` maybe. Let me design HUD:

```
[Pause] [Reset]
150 boids · running · 60 fps
spd 3.8 · flock 0.72 · near ptr 12
Pointer radius 140 px — boids inside the ring flee the cursor.
```

Hmm keep tidy. "flock" = heading coherence. Let me label: `speed`, `coherence`, `fleeing`.

I'll update HUD text 5×/sec.

Now write the file. Also handle `visibilitychange` to avoid dt spikes (dt clamp handles it).

Pointer ring drawn only when active. Ring radius 140 (constant POINTER_RADIUS = 140). On small screens maybe scale: min(140, min(W,H)*0.25)? Keep 140 but clamp to e.g. Math.min(140, Math.max(70, Math.min(W,H)*0.3)). Hmm — if radius varies, HUD label should show it. Compute radius in resize: `pointerRadius = Math.max(80, Math.min(160, Math.min(W,H) * 0.28))`. At 1200×800: min=800*0.28=224 → clamped 160. Hmm, I'd rather fixed 140 unless tiny screen: `pointerRadius = Math.min(140, Math.min(W,H)*0.3)`. At 800 → 140. At 400 height → 120. Fine, and HUD updates label on resize.

Touch: pointermove on touch — add `touch-action: none` on canvas to prevent scrolling interfering.

Prevent text selection when dragging: user-select none on body.

Now — verification steps in browser:
1. reload, screenshot initial
2. wait, screenshot again → compare positions (movement)
3. motion action maybe
4. click on canvas center (pointer influence) → screenshot showing ring + boids fleeing; check HUD "fleeing" count > 0 and rising
5. click Pause button → screenshot; wait; screenshot again → identical (frozen). Check via pixel diff? I can compare screenshots visually, or better: HUD shows "paused". Also inspect console for logs stopping.
6. Click Resume → movement continues (positions change between screenshots).
7. Reset → count still 150, positions change.
8. Resize: browser tool doesn't have resize action explicitly... viewport is 1200×800 fixed ("Coordinates use a 1200×800 viewport"). Maybe resize not possible; I can at least check code handles it and simulate via JS? Can't eval. Hmm — maybe `inspect` allows arbitrary JS? Unknown. I'll note resize as unverified-by-interaction unless possible.

Actually maybe I can dispatch resize by... no eval tool. Possibly the browser `type` action into address bar? No. I'll rely on code review for resize, and mention it.

Let me check environment first, then write the file.

One more thing: pixel-level comparison of screenshots to check frozen state — I could take screenshots and compare bytes? Screenshots returned as images to me; I can eyeball. Or use bash: can't access browser screenshots via bash... Screenshots come as attachments in the tool output, presumably. I'll eyeball.

Alternative rigorous check: HUD could show a "frame counter" / "sim time" that increments only when unpaused — visible in screenshots: same sim time while paused, increasing after resume. Great idea: show `t=12.4s` in HUD. When paused, time frozen → two screenshots show identical t and identical boid positions. 

Let me write the code now.

Also ensure exactly 150 boids after reset — count label.

Writing the full file:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Boids — Flocking Simulation</title>
<style>
  :root { color-scheme: dark; }
  * { box-sizing: border-box; }
  html, body { margin:0; padding:0; width:100%; height:100%; overflow:hidden; background:#0a0e16; }
  body { font-family: ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; color:#e8eefc; user-select:none; -webkit-user-select:none; }
  #sim { position:fixed; inset:0; display:block; touch-action:none; cursor:crosshair; }
  #hud { position:fixed; top:14px; left:14px; z-index:10; width:min(320px, calc(100vw - 28px)); background:rgba(14,19,30,.78); border:1px solid rgba(255,255,255,.12); border-radius:14px; padding:12px 14px 11px; backdrop-filter: blur(8px); box-shadow: 0 10px 30px rgba(0,0,0,.35); }
  ...
</style>
```

Buttons: 

```css
.controls { display:flex; gap:8px; }
button { flex:1; font:600 13px/1 inherit; padding:9px 10px; border-radius:9px; border:1px solid rgba(255,255,255,.16); background:linear-gradient(180deg,#22304a,#1a2438); color:#eaf1ff; cursor:pointer; transition: transform .08s, background .15s; }
button:hover { background: linear-gradient(180deg,#2b3d5e,#212e49); }
button:active { transform: translateY(1px); }
button.primary { background: linear-gradient(180deg,#2f6fed,#2459c8); border-color: rgba(120,170,255,.5); }
button.primary.paused { background: linear-gradient(180deg,#1f9d62,#17804e); border-color: rgba(120,255,190,.4); }
```

Stats: monospace small.

Let me finalize the JS logic in my head once more and then write it in one go.

```js
const CFG = {
  count: 150,
  maxSpeed: 4.6,
  minSpeed: 1.6,
  maxForce: 0.14,   // px/frame^2
  sepR: 32,
  aliR: 68,
  cohR: 76,
  wSep: 1.7, wAli: 1.0, wCoh: 0.9,
  fleeForce: 5.5,   // multiplier of maxForce
  size: 7,          // triangle radius px
};
```

Hmm maxForce 0.14 px/frame² — turning rate: vel change per frame ≤ 0.14*weight... With dt scaling ~1 at 60fps. Steering to align: desired - vel magnitude up to ~2*maxSpeed... limited to 0.14 → takes ~33 frames (0.55s) to fully turn from opposite. Reasonable smoothness. Combined forces: separation weight 1.7*0.14 = 0.24/frame. OK.

Flee force: multiplier 5.5 → 0.77 px/frame² → boid accelerates quickly away, speed clamp at 4.6 prevents teleport (max step 4.6px/frame + wrap). Good.

Total acc clamp: sum of weighted forces could reach e.g. (1.7+1+0.9)*0.14 + flee 0.77 ≈ 1.3 px/frame². Velocity clamp to maxSpeed anyway. No teleporting. Fine, no extra clamp needed, but I'll clamp anyway to be safe? Speed clamp suffices.

Integration order per frame (dtFrames):
```
for b: b.px=b.x; b.py=b.y  (store for step metric)
compute forces (using positions/velocities from previous frame — all boids read prev state? If I update in place, later boids see updated earlier boids — Gauss-Seidel; acceptable but let's compute accelerations first for all, then integrate. Cleaner.)
step 1: for each boid compute acc (flocking + flee + jitter) from current state
step 2: for each boid: vel += acc*dt; clamp speed; pos += vel*dt; wrap; heading = atan2
```

Two-pass is cleaner and symmetric. 

Jitter: `acc.x += (Math.random()-0.5)*0.03;` tiny. Actually with trails and smoothness metrics, jitter of 0.03 px/frame² negligible for turn metric. Include for liveliness.

Heading: set during draw (after step) — but stats computed between frames uses current vel angle; heading stored = atan2 at end of step. Set heading in step 2: b.heading = Math.atan2(b.vy, b.vx). Draw uses b.heading. Then heading ≡ velocity angle exactly. Fine.

Wait — is that "cheating" for verification? The check "triangles point in direction of travel" is about drawing orientation matching velocity. Since drawn angle = atan2(vy,vx), it's satisfied by construction, and screenshot eyeballing confirms visually. Good.

Flocking forces computation:

```js
function computeForces() {
  const n = boids.length;
  const sepR2 = CFG.sepR ** 2, aliR2 = ..., cohR2 = ...;
  for (let i = 0; i < n; i++) {
    const b = boids[i];
    let sepX=0, sepY=0, sepN=0;
    let aliX=0, aliY=0, aliN=0;
    let cohX=0, cohY=0, cohN=0;
    for (let j = 0; j < n; j++) {
      if (i === j) continue;
      const o = boids[j];
      const dx = o.x - b.x, dy = o.y - b.y;
      const d2 = dx*dx + dy*dy;
      if (d2 > cohR2 || d2 === 0) continue; // beyond all radii (cohR largest)
      const d = Math.sqrt(d2);
      if (d2 < sepR2) {
        // push away, weight by 1/d
        sepX -= dx / d; sepY -= dy / d;  // wait: separation direction = from neighbor to self = -(o - b) normalized... 
```

boids[j] - b = dx,dy points from b to neighbor. Steer away: direction = -that, normalized: (-dx/d, -dy/d). Weighted stronger when close: multiply by (1 - d/sepR) or by 1/d. I'll do `w = 1 / d` → sum += (-dx/d) * w = -dx/d². Hmm units: sum has magnitude ~1/d. Then desired = normalize(sum)*maxSpeed. The weighting by 1/d only affects direction relative contributions. Use w = (sepR - d)/sepR (linear falloff) → good.

```
      if (d2 < sepR2) {
        const w = 1 - d / CFG.sepR;
        sepX += (-dx / d) * w; sepY += (-dy / d) * w; sepN++;
      }
      if (d2 < aliR2) { aliX += o.vx; aliY += o.vy; aliN++; }
      if (d2 < cohR2) { cohX += o.x; cohY += o.y; cohN++; }
    }
    // forces
    let ax = 0, ay = 0;
    if (sepN > 0) {
      // desired velocity = normalize(sep) * maxSpeed; steer = desired - vel; limit maxForce
      const [sx, sy] = steer(sepX, sepY, b.vx, b.vy, ...);
      ax += sx * CFG.wSep; ...
```

Helper:
```js
function limitVec(x, y, max) { const m = Math.hypot(x,y); if (m > max && m > 0) { const s = max/m; return [x*s, y*s]; } return [x,y]; }

function seekSteer(b, targetX, targetY, normalizeTarget) {
  // desired direction * maxSpeed minus vel, limited to maxForce
}
```

I'll write inline for clarity:

```js
// separation
if (sepN) {
  const m = Math.hypot(sepX, sepY) || 1;
  const dxs = (sepX / m) * CFG.maxSpeed - b.vx;
  const dys = (sepY / m) * CFG.maxSpeed - b.vy;
  const [tx, ty] = limitVec(dxs, dys, CFG.maxForce);
  ax += tx * CFG.wSep; ay += ty * CFG.wSep;
}
// alignment: average velocity → desired = normalize(avg) * maxSpeed
if (aliN) {
  const axv = aliX / aliN, ayv = aliY / aliN;
  const m = Math.hypot(axv, ayv) || 1;
  const sx = (axv / m) * CFG.maxSpeed - b.vx;
  ...
}
// cohesion: average position → desired = direction to center * maxSpeed
if (cohN) {
  const cx = cohX / cohN - b.x, cy = cohY / cohN - b.y;
  const m = Math.hypot(cx, cy) || 1;
  const sx = (cx/m)*maxSpeed - b.vx; ...
}
// flee
if (pointer.active) {
  const dx = b.x - pointer.x, dy = b.y - pointer.y;
  const d = Math.hypot(dx, dy);
  if (d < pointerRadius && d > 0.0001) {
    const strength = 1 - d / pointerRadius; // 0..1
    const f = CFG.maxForce * CFG.fleeForce * (0.25 + 0.75 * strength);
    ax += (dx/d) * f; ay += (dy/d) * f;
    b.fleeing = true (set in reset each frame)
  }
}
// jitter
ax += (Math.random() - 0.5) * 0.05; ay += ...
```

fleeing flag: reset for all at start of computeForces, set true when fleeing. Count for HUD.

Step metric: track maxStep per frame; skip wrap jumps:
```js
let dxs = b.x - b.px, dys = b.y - b.py;
if (dxs*dxs < (W*W)/4 && dys*dys < (H*H)/4) maxStep = Math.max(maxStep, Math.hypot(dxs,dys));
```

Coherence: mean of unit velocities magnitude.

Nearest neighbor mean: O(n²) again in stats — compute stats at 5Hz only. Or reuse? Fine, stats called 5×/s.

Sim time: accumulate dtFrames / 60 seconds while unpaused.

HUD update every 200ms.

Console log every 2 seconds with full stats.

Loop:

```js
let last = performance.now();
function frame(now) {
  const rawDt = now - last; last = now;
  const dt = clamp(rawDt / (1000/60), 0, 3);
  if (!paused) {
    simTime += (rawDt/1000) clamped...
    computeForces();
    integrate(dt);
    render(false);
    frames++;
  } else {
    // frozen: keep canvas as-is
  }
  // hud update regardless (shows paused state)
  requestAnimationFrame(frame);
}
```

simTime should advance with real time while running: simTime += Math.min(rawDt, 50)/1000. HUD t=…s frozen when paused. 

Wait: when paused, HUD fps should show "paused". Show fps from running frames.

Edge: at first frame after resume, `last` was updated every frame during pause (we set last = now always) → no dt jump. Good.

Reset while paused: should reset boids and... remain paused? Requirement: "Reset restores a fresh population of 150 boids." I'll make Reset also resume? Better keep pause state as-is but re-render fresh state (needs render even when paused: call render(true) after reset). Actually fresh population while paused → user sees frozen new population, presses Resume. Hmm, slightly odd but consistent: "Pause freezes simulation state". I'll make Reset unpause? Many sims keep state. I think nicer: Reset resets population and keeps current pause state, rendering immediately. Let me keep pause state (predictable), render once (opaque to clear trails from old population... actually trails of old population + new boids drawn on top = messy ghosts. Render with opaque clear after reset). I'll add `render(true)` after reset.

Hmm, but if running, next frame renders with alpha 0.5 trail fill over the opaque-reset frame — fine.

Resize: render(true).

Now the ring drawing:

```js
if (pointer.active) {
  ctx.save();
  ctx.setLineDash([6, 8]);
  ctx.lineWidth = 1.5;
  ctx.strokeStyle = 'rgba(255,190,90,0.55)';
  ctx.beginPath(); ctx.arc(pointer.x, pointer.y, pointerRadius, 0, Math.PI*2); ctx.stroke();
  ctx.setLineDash([]);
  ctx.fillStyle = 'rgba(255,200,110,0.9)';
  ctx.beginPath(); ctx.arc(pointer.x, pointer.y, 3, 0, Math.PI*2); ctx.fill();
  ctx.restore();
}
```

Draw ring before boids so boids overlay it (ring subtle). Either way.

Boid drawing:

```js
function drawBoid(b) {
  const s = Math.hypot(b.vx, b.vy) || 1;
  const ang = b.heading;
  // color by heading
  const hue = ((ang * 180 / Math.PI) + 360) % 360;
  ctx.fillStyle = `hsl(${hue} 75% 64%)`;
  ctx.save();
  ctx.translate(b.x, b.y);
  ctx.rotate(ang);
  ctx.beginPath();
  ctx.moveTo(r * 1.5, 0);
  ctx.lineTo(-r * 0.9, r * 0.78);
  ctx.lineTo(-r * 0.45, 0);
  ctx.lineTo(-r * 0.9, -r * 0.78);
  ctx.closePath();
  ctx.fill();
  ctx.restore();
}
```

Dart shape with notch looks nice; simple triangle also fine: moveTo(1.5r,0) lineTo(-0.9r, 0.78r) lineTo(-0.9r, -0.78r). I'll use the dart (looks oriented clearly).

Per-boid hue variance: hue base from heading ± b.hueOff (small random ±20). Brightness slightly varies. Nice.

Performance: 150 fill+save/restore per frame OK. Could batch path per hue bucket but unnecessary.

Optionally stroke thin outline for crispness: strokeStyle rgba(0,0,0,.35), lineWidth 1 — adds definition on trails. Might cost; fine.

Actually simpler: fill with slight shadow? Skip shadows (slow).

Wrapping: after integrating:
```js
if (b.x < -r) b.x += W + 2r?? 
```
Standard: if (b.x < 0) b.x += W; if (b.x > W) b.x -= W;. But with margin so triangle fully visible: use `if (b.x < -m) b.x += W + 2m` where m = size*1.5? That creates gap band of 2m where boid invisible... Actually boid only jumps when fully off-screen with margin m: appears on other side at W+m-... hmm.

Let's do simple: wrap when center crosses edge: x<0 → x+=W. Triangle partially clipped at edge for a moment — normal and fine ("wrap across screen edges"). Simplicity wins. But with trails, a boid drawing half-off-edge: canvas clips it; on other side appears half. Acceptable, standard.

Hmm, but dt > 1 frames: pos += vel*dt could overshoot: `if (b.x < 0) b.x += W` only handles one wrap if overshoot < W — with maxSpeed 4.6*3 = 14px, fine. Use modulo anyway:
```js
b.x = ((b.x % W) + W) % W;
b.y = ((b.y % H) + H) % H;
```
Modulo robust.

Pointer events:

```js
window.addEventListener('pointermove', e => { pointer.x = e.clientX; pointer.y = e.clientY; pointer.active = true; });
window.addEventListener('pointerdown', e => { same }) // click moves? pointerdown sets too
document.addEventListener('pointerleave', () => pointer.active = false); // document doesn't fire pointerleave? use document.documentElement mouseleave / window blur
window.addEventListener('blur', () => pointer.active = false);
document.addEventListener('pointerout', e => { if (!e.relatedTarget) pointer.active = false; });
```

Also `mouseleave` on document.documentElement → active false. I'll add `document.addEventListener('mouseleave', ...)` — mouseleave doesn't fire for pointer? pointerleave does: `document.addEventListener('pointerleave', ...)`. Hmm, pointerleave on document fires when leaving window (for mouse). Add both pointerleave on documentElement and blur.

Buttons:

```js
pauseBtn.addEventListener('click', () => { setPaused(!paused); pauseBtn.blur(); });
```

`setPaused(p)`: updates paused, button label/class, aria-pressed, status text. If unpausing, `last = performance.now()` — not needed since last updated each frame regardless. But if rAF still running, fine.

Keyboard:
```js
window.addEventListener('keydown', e => {
  if (e.code === 'Space') { e.preventDefault(); setPaused(!paused); document.activeElement?.blur?.(); }
  else if (e.key === 'r' || e.key === 'R') { reset(); document.activeElement?.blur?.(); }
});
```

If focus is on button and user presses space: keydown handler toggles, and button's click activation... Button space activation happens on keyup (click event fires on keyup for space on buttons). So both would fire → double toggle. Blur active element on button click fixes typical flow; also in keydown for space I blur activeElement BEFORE? The click fires on keyup — if I blur during keydown, the keyup goes to body → no button activation. Order: keydown (we blur + toggle) → keyup (button not focused → no click). So blurring in keydown prevents double-toggle. But wait, if focus is on the Pause button and user presses space: keydown → we blur and toggle once. keyup → target is body → no activation. Single toggle. 

If focus on Reset button, space: we toggle pause (keydown) — hmm user expected space to activate focused Reset button. Minor: I'll skip global handling when activeElement is a button (let the button handle it):
```js
if (e.code === 'Space') { if (document.activeElement && document.activeElement.tagName === 'BUTTON') return; ... }
```
Then focused button handles space itself (click). And normal case (no focus) global toggles. Clean.

HUD elements ids: pauseBtn, resetBtn, statusEl, countEl, fpsEl, timeEl, metricsEl, radiusEl.

Let me write metrics line: `speed 3.9 · flock 0.71 · nearest 41 px` and second line `fleeing 14 of 150 · radius 140 px`.

I'll structure HUD:

```
<div class="title">Flocking <span class="dot"></span></div>
<div class="controls"><button id="pauseBtn" class="primary">Pause</button><button id="resetBtn">Reset</button></div>
<div class="stats">
  <div><span id="stateEl">Running</span> · <span id="countEl">150 boids</span> · <span id="timeEl">t 0.0 s</span></div>
  <div class="mono" id="metricsEl">…</div>
</div>
<div class="hint">Move the pointer near the flock: boids within <b id="radiusEl">140 px</b> steer away from the cursor (dashed ring) and resume flocking outside it.</div>
```

Now write it. After writing, open in browser.

Let me also consider: `ctx = canvas.getContext('2d', {alpha:false})` — with alpha false, initial bitmap is black. Good.

Resize handler: use `window.addEventListener('resize', resize)` plus maybe visualViewport? Keep window resize + orientationchange.

Init: resize() → boids = create 150 → render(true).

Careful: resize() references boids for wrapping — guard if boids empty.

Let me write out the file now.

Also stats logging: I want console logs with metrics every 2s: `console.log('[flock]', {...})` — object form may be captured by inspect. I'll use a single formatted string to be safe.

Now — writing the final code.

```js
// ---------- configuration ----------
const CFG = {
  count: 150,
  maxSpeed: 4.6,      // px per 60fps-frame
  minSpeed: 1.7,
  maxForce: 0.15,     // px per frame^2
  sepR: 32, aliR: 68, cohR: 78,
  wSep: 1.8, wAli: 1.0, wCoh: 0.85,
  fleeMul: 6.0,
  size: 7,
  trail: 0.5          // background alpha per frame (1 = no trails)
};
```

Hmm trail alpha 0.5: old frame at 50% each frame → visible streak ~4-5 frames. OK.

Wait, actually with alpha:false context, fillStyle rgba with alpha works via source-over compositing — yes.

Reset function:

```js
function reset() {
  boids = [];
  for (let i = 0; i < CFG.count; i++) {
    const ang = Math.random() * Math.PI * 2;
    const spd = CFG.minSpeed + Math.random() * (CFG.maxSpeed - CFG.minSpeed);
    boids.push({
      x: Math.random() * W, y: Math.random() * H,
      vx: Math.cos(ang) * spd, vy: Math.sin(ang) * spd,
      ax: 0, ay: 0,
      heading: ang,
      hueOff: Math.random() * 26 - 13,
      fleeing: false
    });
  }
  simTime = 0;
  countEl.textContent = `${boids.length} boids`;
  render(true);
}
```

Wait — should Reset zero simTime? "Reset restores a fresh population" — resetting time is fine and makes verification clear (t resets to 0).

create initial: call reset() at init.

integrate(dt):
```js
function integrate(dt) {
  let maxStep = 0;
  for (const b of boids) {
    b.px = b.x; b.py = b.y;
    b.vx += b.ax * dt; b.vy += b.ay * dt;
    let sp = Math.hypot(b.vx, b.vy);
    if (sp > CFG.maxSpeed) { const k = CFG.maxSpeed/sp; b.vx*=k; b.vy*=k; sp = CFG.maxSpeed; }
    else if (sp < CFG.minSpeed && sp > 0.0001) { const k = CFG.minSpeed/sp; b.vx*=k; b.vy*=k; sp = CFG.minSpeed; }
    b.x += b.vx * dt; b.y += b.vy * dt;
    // wrap
    if (b.x < 0) b.x += W; else if (b.x >= W) b.x -= W;
    if (b.y < 0) b.y += H; else if (b.y >= H) b.y -= H;
    b.heading = Math.atan2(b.vy, b.vx);
    // step metric (ignore wrap jumps)
    const dx = b.x - b.px, dy = b.y - b.py;
    if (Math.abs(dx) < W/2 && Math.abs(dy) < H/2) { const st = Math.hypot(dx,dy); if (st > maxStep) maxStep = st; }
  }
  frameMaxStep = maxStep;
}
```

Wait px/py must be set BEFORE position changes but AFTER previous position — b.px = b.x at start of integrate (before adding velocity) — correct as written (set first). Good.

Hmm but I set b.px = b.x at top of loop for that boid, then modify — fine.

Stats:

```js
function stats() {
  let spdSum=0, sx=0, sy=0, nnSum=0, fleeing=0;
  let headingErr = 0, maxStep = frameMaxStep;
  for (const b of boids) {
    const sp = Math.hypot(b.vx, b.vy);
    spdSum += sp;
    if (sp > 0) { sx += b.vx/sp; sy += b.vy/sp; }
    if (b.fleeing) fleeing++;
    // heading vs velocity angle
    const va = Math.atan2(b.vy, b.vx);
    let dA = b.heading - va; while (dA > Math.PI) dA -= 2*Math.PI; while (dA < -Math.PI) dA += 2*Math.PI;
    const err = Math.abs(dA); if (err > headingErr) headingErr = err;
  }
  const n = boids.length || 1;
  // nearest neighbour mean (sample every other boid to keep cheap)
  ...
}
```

Nearest neighbor: full O(n²) at 5Hz — 22.5k ops, negligible. Include.

coherence = Math.hypot(sx,sy)/n.

metrics string: `speed 3.87 · flock 0.72 · nearest 41 px · max step 4.5 px`.

fleeing count in second line with radius.

Console log every 2s:
`[flock] t=12.4s n=150 running fps=60 speed=3.87 flock=0.72 nearest=41px maxStep=4.5px headingErr=0.00rad fleeing=14 radius=140`

headingErr=0 verifies triangles aligned with velocity direction. fleeing verifies pointer interaction. flock verifies coordinated movement (coherence). maxStep bounded verifies no teleporting.

Also log initial state at t=0.

For "resume flocking after pointer moves away" — verified by fleeing→0 when pointer moved outside... but my pointer stays where last moved. To verify spatially: HUD fleeing count = number within radius; when pointer near edge... The click at some point gives fleeing>0; then to check resume, I'd need pointer inactive (leave window) — can't easily leave window with browser tool. Hmm. Alternatively the fleeing count depends on radius only, so a boid outside radius isn't fleeing — that's the mechanism. To demonstrate "resume after pointer moves away", clicking at a far corner moves the pointer there; boids previously fleeing (near old point) stop fleeing. I can check via screenshot: click at center → fleeing high; then click at corner → HUD fleeing changes; boids near old center resume flocking (visible coherence again). Two clicks also both test pointermove.

Actually wait — does the browser tool's `click` action dispatch pointermove to the target first? In Playwright, `page.mouse.click(x,y)` moves the mouse there → pointermove fires. Likely harness uses CDP Input.dispatchMouseEvent mouseMoved first. I'll verify empirically via HUD fleeing count after clicking.

Also `drag` would produce many pointermoves — good for testing "pointer moves away" across the screen. I'll do a drag from center to corner (pointerdown at center, moves, up at corner) — that moves the influence around.

Also possible: the `scroll` action might not move mouse. Fine.

Now, one risk: if `click` dispatches only a click event without pointermove, pointer influence won't activate from clicks. Fallback: expose `window.__sim.movePointer(x,y)` — but I can't eval JS... unless inspect supports eval. I'll check inspect capabilities. If clicks don't move the pointer, I could add a canvas `pointerdown`/`pointermove` listener — same events. Alternatively, add `click` on canvas → set pointer position from click coordinates as a fallback (pointerdown handler sets pointer.x/y/active). Even if no pointermove fires, pointerdown/click gives coordinates → influence activates. I'll set pointer on pointerdown AND pointermove. That guarantees click-based testing works.

Let me write the file now. I'll aim for clean, well-commented code.

Also — requirement "Fit the canvas to the viewport": canvas CSS 100% fixed, backing store scaled by DPR, resize listener re-fits. Also `100dvh`? Using window.innerWidth/Height with position fixed inset 0 handles mobile too. Fine.

Let me write it.

After writing: browser reload, screenshot, inspect console, wait, screenshot, click pause, screenshot, wait, screenshot (compare), resume, click canvas for pointer, screenshot, HUD check.

Time budget: 15 min. Let's go.

One more consideration about `motion` action: it probably captures frames over time to show animation. I'll use it once to check movement.

Write the file.

I need to write index.html now, quickly, then do a brief verification. Let me write the complete file in one go.

Now run in browser and check. Reload, screenshot, inspect console.

The simulation is running. Boids are triangles with trails pointing along direction of travel (trails show direction of motion — triangle nose leads the trail). Initial flock coherence 0.12 (random start), that will increase.

Interesting: the console shows "pointer on" with fleeing 3 at t=0.2 — the reload placed pointer somewhere? Probably mouse at default position. Screenshot HUD says "pointer off", "fleeing 0". The DOM text in inspect was captured slightly later maybe... Actually the inspect output shows "pointer on ... fleeing 3" but the screenshot shows "pointer off ... fleeing 0". Screenshot may be taken after pointerleave. Whatever.

Wait — screenshot shows "t 0.0 s" but inspect showed "t 0.2 s". Timing differences.

Now let me wait and check flock metrics increasing (coordinated movement), then verify pointer interaction, pause/resume.

Let me sample at a later moment via inspect.

Excellent! The flock has formed moving groups: coherence rose from 0.12 → 0.50 → 0.77 → 0.87. Nearest neighbor distance dropped 41 → 29-32 px. Triangles clearly point along their trails (direction of travel). headingErr = 0.0000 rad confirms drawn heading matches velocity exactly. maxStep ≈ 4.55 px ≤ maxSpeed 4.6 → no teleporting.

Now test pointer interaction: click in the middle of the canvas (e.g., 600, 400) and check fleeing count rises, dashed ring visible.

The pointer ring is visible at the click position (600,400), the area inside the ring has been cleared of boids (boids fled — you can see an empty circle where the flock was pushed away, with boids on the rim moving outward). HUD shows "fleeing 6 of 150 · pointer on". Earlier log at t=8.0 shows fleeing=4.

Wait — at t=8.0 fleeing=4 and now the circle is mostly empty of boids. The pointer stayed at (600,400) from the click, and boids fled the region. Good.

Hmm, but "fleeing 6" — only 6 boids are within radius because the area is cleared. The screenshot clearly shows the empty circle. 

Also "flock 0.96" — high coherence means the whole screen is one big group moving in the same direction. That's coordinated movement. But high coherence 0.96-0.98 means nearly everything moves same direction — maybe too aligned (the whole flock becomes one stream). It's fine — "form moving groups". Actually the screenshot shows multiple streams/groups (teal group, some at top). It looks good.

Hmm, one consideration: flock ~0.98 nearly everything same direction — could be seen as less "groups". But multiple visual clusters exist. It's acceptable.

Now test pause: click Pause button, screenshot; wait, screenshot again — positions should be identical, and sim time frozen. Then Resume, verify movement continues.

Let me click Pause.

Pause worked: button says "Resume" (green), status "Paused (frozen) · t 27.3 s · —". Now I need to verify it's actually frozen: take another screenshot after some time — positions and t should be unchanged. The `inspect` above already shows the paused DOM. Let me wait by doing another inspect (which takes time) and compare — but inspect runs immediately. There's no "wait" action. I can do a screenshot now, then another screenshot — but time between tool calls is short (~1s?). Still, if frozen, t stays 27.3 and positions identical.

Let me take two screenshots in sequence and compare visually. Actually each action call takes some wall time. Let me do: screenshot, then inspect (checks t frozen). If t remains 27.3 across calls, freeze confirmed.

The screenshot is pixel-identical to the previous one (same boid positions, t 27.3 s, no new console logs after t=26.1). Freeze confirmed — no updates, no rendering changes, sim time frozen at 27.3.

Now click Resume and verify movement continues (t increases, positions change, new logs).

Resume works: button back to "Pause", status "Running · 60 fps", and the boids have visibly advanced from the frozen positions (positions changed, trails cleared). Interesting: the pointer ring disappeared — because clicking the Resume button... wait, HUD says "pointer on". The ring isn't visible in this screenshot... hmm, actually the ring was drawn at (600,400) but this screenshot shows no ring. Wait — on resume I called render(true) which clears trails opaque; the ring should be drawn since pointer.active. But the screenshot shows no dashed ring... Actually looking closely, HUD says "pointer on". Hmm, the ring might have been drawn but... the screenshot was taken right at resume; render(true) draws ring + boids. Ring at (600,400) not visible in image. Odd.

Wait, maybe the screenshot timing: render happens in the rAF frame after resume. The click → setPaused(false) → render(true) called synchronously in setPaused (I call render(true) when unpausing). That draws ring. So ring should be there.

Hmm, but look at the screenshot: no ring visible, and boid positions moved compared to paused frame (they've advanced). Also t still 27.3 (first update at 200ms interval hasn't fired yet). The positions in the resumed shot differ from frozen shot — e.g., left group shifted down-right slightly. So frames are being rendered.

Why no ring? Possibly pointer became inactive at the moment of render, then HUD updated later... no, HUD says "pointer on" — but HUD updates at 200ms intervals; the DOM text was captured in the same call right after click, showing old text from before? The previous DOM also said "pointer on".

Hmm wait, actually let me reconsider: maybe the ring IS drawn but the trails alpha... no, ring is drawn every render when active.

Let me think: after resume, each frame: fillRect rgba(10,14,22,0.5) — the ring drawn with alpha 0.55 stroke gets partially erased each frame by the trail fill, but re-drawn fresh each frame on top. It should be visible with full 0.55 alpha... Actually no! Order per frame: first background fill (fades everything incl. previous ring), then draw ring, then boids. So ring drawn at 0.55 alpha each frame — visible. Unless pointer.active is false.

Possibility: the click on Resume button (at 100,71) — Playwright moved mouse there, generating pointermove → pointer at (100,71), active. Ring at (100,71) would be mostly hidden behind HUD panel (HUD spans x 14-346, y 14-246). The ring center (100,71) is under the HUD! That's why it's not visible — it's behind the panel (z-index 10, opaque-ish 0.8 background). And fleeing 3 near that point also hidden behind panel. Makes sense!

But wait — in the paused screenshot the pointer was still at (600,400) from the canvas click... Actually no: clicking Pause at (100,71) moved the pointer there too (pointermove to 100,71). But the paused screenshot showed the ring at (600,400)! Because when paused, render is skipped — the canvas retained the last rendered frame with ring at (600,400). Pointer state had changed to (100,71) but no re-render happened while frozen. That's consistent.

After resume, render(true) drew ring at (100,71) — behind HUD panel. OK, mystery solved — everything works correctly.

So resume works and movement continues. Now test Reset: click Reset, check count=150 and t back to 0, fresh positions. Then maybe move pointer back onto canvas via a click and check fleeing again after reset... Already tested pointer.

Also should verify wrapping — hard to observe directly in short time; code uses modulo-ish clamp wrap. It's fine.

Let me click Reset.

Reset works: fresh random population (t back to 0.0 s, flock 0.04 = random headings, 150 boids, colors now varied since heading angles are random). Boids are scattered randomly across the screen.

Note: the ring edge is visible at top (dashed arc at ~(400,0)) — pointer was moved... the click at (253,71) is behind HUD; ring partially visible top edge. Fine.

Also I notice the pointer ring drawn at (253,71) behind the panel — visible dashed arc peeking at top around x=390? Hmm the arc at top center-left. Whatever — pointer influence works.

Wait, one thing: after reset the pointer influence should be re-tested? Already verified. Also "resume flocking after pointer moves away" — when pointer moves behind HUD panel to (253,71), fleeing count varies 0-9 (boids near that point flee); earlier at center it cleared a circle. And logs show fleeing returning to 0 when pointer region empty/leaves window. Good enough.

The reset screenshot shows boids with varied colors — heading-based hue. Triangles point in direction of travel (their trails will show it as they move).

Everything works. Console has no errors. Population 150. 

Remaining unverified: actual viewport resize (no resize tool available). Code handles resize via window resize listener; I reviewed it. Could I simulate? No eval. I'll note it.

One small thing: after reset, trails were cleared (opaque render) — good, no ghost trails visible.

Let me do a final quick check that there are no console errors (console array shows only logs, no errors) — confirmed.

Also confirm file saved — yes, 16771 bytes.

I think we're done. Maybe one more motion check post-reset to confirm flocking reforms? Not necessary; earlier run showed it from same initial conditions (flock 0.04 → 0.87 over 6s).

Actually, let me do one final quick check: a screenshot after some time to confirm groups reform after reset AND that triangles point along travel (trails). The previous full run already demonstrated that. But that was pre-reset state. It's the same code. I'll do one quick inspect to see t advanced and flock rising — cheap.

Time budget: used ~? Started ~05:49 dir listing, file written 06:03... The 10-minute warning came before I wrote the file. I should finish now. One last quick verification then report.