Force-directed graph · particle-1

Let me write the index.html.

Design:
- 40 nodes, IDs 0-39. Clusters: 0-9, 10-19, 20-29, 30-39. Ring within each cluster. Links between 0,10,20,30 in a ring.
- Force simulation with links, charge, center, cluster forces.
- SVG with <g id="viewport"> transformed by zoom.
- Drag node: d3.drag updating fx/fy with container coordinate conversion (use zoom transform invert).
- Pan background: zoom on svg with filter to exclude nodes.
- Zoom wheel: same zoom behavior.
- Hover: highlight node, neighbors, links; dim rest.
- Reset view button restoring initial transform.

Initial framing: fit graph in view. I'll compute initial transform (identity scale 1 with centering) and store it. Maybe apply a scale to fit. Simplest: use viewBox on SVG matching width/height, but svg size responsive. Use SVG with width 100%, height 100%, and rely on client dims. Let's set SVG viewBox to fixed 1000x700? Then zoom transform in viewBox coordinates. Reset resets to d3.zoomIdentity. Initial graph positioned around center (500,350) via forces. That keeps it in view. Zoom scale extent 0.3-3.

For node dragging with zoom: use event coordinates relative to svg in viewBox units. Simpler: set svg with width/height matching container and no viewBox — but resizing. I'll use viewBox with preserveAspectRatio and convert client coords to viewBox coords via SVG point transform... d3.pointer(event, svgElement) — with viewBox, d3.pointer uses getScreenCTM inverse, so it returns viewBox coords. Good. Then invert zoom transform: d3.zoomTransform(g.node()).invert(d3.pointer(event, svg)). Hmm, d3.pointer(event, gNode) already accounts for the g's transform (getScreenCTM includes transform). Actually yes — d3.pointer(event, node) uses node.getScreenCTM().inverse(), which includes the zoom transform on the g. So pointer relative to the g node directly gives graph coordinates. That's easiest.

So drag handlers: on start, d3.pointer(event, gNode) → fx/fy. But careful: while dragging, the g transform changes if panning simultaneously — shouldn't happen.

Use d3.drag on node groups with container = svg. event.x/event.y are from drag subject default... For circles, d3.drag default subject uses pointer relative to parent (g). Since g has transform, event.x is in graph coords. Good. I'll set fx = event.x, fy = event.y.

Zoom: svg.call(zoom) with scaleExtent [0.35, 3.5]. Apply transform to g. Filter: if event target is a node, ignore (`.filter(e => !e.target.closest('.node'))`). Wheel always allowed? Drag pan on background only per requirement, but wheel zoom anywhere is fine.

Hover: build adjacency sets. On node mouseenter, add classes: .dim to all nodes/links not in highlight. Use classes on svg root: nodes get 'faded' if not in set; links 'faded'. Keep hovered node 'hovered'.

Also label visibility.

Reset view button: transition zoom transform back to initial (identity) — reset camera. Also maybe reset simulation? Spec: restore initial camera framing without replacing graph data. Just reset zoom transform with transition.

Cluster forces: use forceX/forceY towards cluster centers (quadrants) weak strength, plus link force, charge. Also a radial? Use forceX/Y strength 0.06 with cluster centers offset from center.

Colors: four colors, e.g. #4f8cff, #ff6b6b, #ffd166? Let's use a modern palette: ["#5b8def", "#f46d6d", "#3ecf8e", "#f5b942"].

Dark background with subtle gradient? Let's do dark theme, nice.

Let me also add a zoom percentage readout maybe. Keep it simple but polished.

Node drag check: repairs links automatically since simulation ticks redraw.

Also add a "spread" of cluster centers: center (0,0) at svg center 500,350; cluster centers at ±150 offsets. With ring radius ~70 for each cluster and link force among 0,10,20,30.

Cluster ring links: for each cluster base b in [0,10,20,30], links (b+i, b+(i+1)%10) for i 0..9.
Cross links: 0-10, 10-20, 20-30, 30-0.

Link distance varying: intra-cluster 42, cross 170. Set link.distance(l => l.value? ) I'll store d.dist.

Simulation tick: link lines x1..y2, node groups translate.

Label text: id centered.

Hover dimming: links default stroke opacity 0.5, faded 0.06.

Initial fit: compute bounds after simulation settles? Spec says keep initial graph within view. With cluster centers ±150 and center 500,350 in viewBox 1000x650, should fit. Let's set viewBox "0 0 1000 640" and cluster centers at (500±170, 320±130) roughly. Ring radius 62, link forces keep tight-ish. Should fit.

Actually forceCenter vs forceX: I'll set simulation.force('center', d3.forceCenter(500,320)) and per-node forceX/forceY towards cluster center with strength 0.05, links distance 40. Charge -90? Let me tune: 40 nodes, links within clusters. charge -120, link distance 45, cluster forceX strength 0.08. Should stay within bounds ~120 radius per cluster.

Also zoom-to-fit initial: to be safe, after simulation cools compute bounding box and set initial transform to fit with padding. But then reset must restore that transform. That's fine and guarantees within view. But drag test wants camera stays in place; fine.

However computing fit after settle then applying a transition on load might be odd. I could compute at ~1.5s and set transform. Simpler: initial transform identity, and ensure the layout fits. I'll do a fit calculation on first settle and store as initialTransform, applying it without transition (only if scale <1 needed). Eh — risk of visible jump. Alternative: compute fit continuously? Let's just do: after 300 ticks (simulation.tick manually before drawing?) — Actually we can run simulation.tick(300) upfront synchronously to precompute positions, then fit the camera, then start the simulation with the nodes where they are (still warm for animation). Pre-ticking 300 puts nodes at equilibrium; then start simulation with alpha 0.3 for gentle settling. Initial framing computed from pre-ticked positions, guaranteed in view. 

But dragging matters: pre-ticked positions with forceSimulation warm. Let's do:

sim = d3.forceSimulation(nodes)...stop(); sim.tick(300); then compute bounds, set initialTransform = fit; then sim.alpha(0.6).restart()? Restarting causes movement but small. Maybe skip restart — but then hover/drag works with simulation reheat on drag. Actually drag handler calls sim.alphaTarget(0.3).restart(). Nice: the graph loads static in equilibrium, and drag animates. But a gentle continuous motion looks nice. I'll restart with low alpha 0.25 so it breathes briefly then stops.

Fit transform: scale = min(1, min(W/w, H/h)*0.85), translate to center bbox. Apply via zoom.transform to g, store as initial.

Hmm, but with zoom, the g transform: translate then scale. d3.zoomTransform consistent.

Reset: svg.transition().duration(600).call(zoom.transform, initialTransform).

Let me write code.

Pointer events: node groups with circle r=13 and text. Use pointer-events for label too but dragging on label should work.

For zoom filter, d3.zoom default filter ignores right click etc. Set .filter(e => e.type === 'wheel' || !e.target.closest || !e.target.closest('.node')) — careful: e.target may not have closest for svg root (SVGElement has closest). Use e.target.closest?.('.node') — fine.

Dragging a node: d3.drag on the node group; must stop zoom from panning — because zoom filter excludes nodes, drag works. But node drag also needs to not trigger zoom's dblclick? fine.

Also disable text selection via CSS user-select none.

Dim logic: on mouseover of node:
- neighbors = set of node ids connected.
- nodeSel.classed('faded', d => d.id !== hoverId && !neighbors.has(d.id)) and classed('hovered', d => d.id===hoverId), classed('neighbor', neighbors)
- linkSel.classed('faded', l => source.id!==hoverId && target.id!==hoverId), classed('highlight', ...).
On mouseout: clear.

Use pointerenter/pointerleave on node groups.

Add legend of clusters and a reset button + hint text.

Also status showing zoom level.

Let me write the file.

SVG sizing: use width/height 100% with viewBox "0 0 1000 640" preserveAspectRatio="xMidYMid meet"? If preserveAspectRatio meet with letterboxing, d3.pointer still works via CTM. Fine. But background rect inside SVG for pan hit area — zoom filter needs a target that isn't a node; the svg root click works if pointer-events. Put a transparent rect covering viewBox? With viewBox and letterbox, panning outside viewBox area on the svg root still triggers zoom.pan? d3.zoom attaches to svg element; pointer events on svg element itself happen where there's content. Add a rect x=0 y=0 w=1000 h=640 fill transparent — better to make it big, e.g. -5000..5000, to allow panning. But that scales... fine, rect x=-4000 y=-4000 width=9000 height=9000 fill="transparent" pointer-events="all"? That could block? It's the first child so nodes drawn above. Good.

Hmm, transparent fill with pointer-events all works.

Also allow panning by dragging anywhere including background beyond rect (svg itself has no fill). Use CSS svg { background: ... } — background doesn't capture pointer events. So the big rect handles it.

Let's write.

Tick function: use node groups with transform translate, links with x1... Simpler with selections.

Add arrow: no.

Code:

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Force-Directed Cluster Graph</title>
<style>...</style>
</head>
<body>
<div id="app">
  <header>
    <h1>Force-Directed Graph</h1>
    <div class="sub">40 nodes · 4 clusters · drag nodes · pan &amp; zoom</div>
  </header>
  <div id="stage">
    <svg id="graph" viewBox="0 0 1000 640" preserveAspectRatio="xMidYMid meet" role="img" aria-label="Force directed graph of 40 nodes">
      <rect class="bg-hit" x="-4000" y="-4000" width="9000" height="9000"></rect>
      <g id="viewport">
        <g id="links"></g>
        <g id="nodes"></g>
      </g>
    </svg>
    <div class="panel">
      <button id="reset" type="button">Reset view</button>
      <div id="zoomLabel">100%</div>
      <div class="legend">...</div>
    </div>
    <div class="hint">Drag a node · drag background to pan · scroll to zoom · hover to focus</div>
  </div>
</div>
<script src="d3.min.js"></script>
<script> ... </script>
```

Wait: CSS background of svg fill; better set rect fill to a color. The rect covers everything behind nodes.

Actually with viewBox 1000x640 and rect from -4000 to 5000, at scale 1 the visible area is only viewBox — rect fill dark fills whole visible. Good.

But when zooming out to 0.35, the rect will still cover visible area. Good.

Now JS:

```js
const W=1000,H=640;
const clusterColors=['#5b8dfa','#f2708c','#39cfa0','#f0b33c'];
const nodes=[];
for(let i=0;i<40;i++){
  const cluster=Math.floor(i/10);
  nodes.push({id:i, cluster});
}
const links=[];
for(let b=0;b<40;b+=10){
  for(let k=0;k<10;k++){
    links.push({source:b+k, target:b+(k+1)%10, kind:'ring', distance:44});
  }
}
const hubs=[0,10,20,30];
for(let k=0;k<4;k++) links.push({source:hubs[k],target:hubs[(k+1)%4],kind:'bridge',distance:180});
```

Cluster centers:
```js
const cx = [W/2-165, W/2+165, W/2-165, W/2+165];
```
Hmm need ring of 4 cluster centers so bridge links nice: place clusters in quadrants: 
```js
const clusterCenters=[[W/2-170,H/2-115],[W/2+170,H/2-115],[W/2+170,H/2+115],[W/2-170,H/2+115]];
```
But then bridge links 0-10,10-20,20-30,30-0 cross the middle. Fine.

Cluster radius ~ ring of 10 nodes distance 44 → circumference 440 → radius ~70. Plus cluster force centers them; total extent per cluster ~90. So clusters at ±170,±115 don't overlap much (gap 340-180=160 horizontally). Good.

Forces:
```js
sim = d3.forceSimulation(nodes)
 .force('link', d3.forceLink(links).id(d=>d.id).distance(d=>d.distance).strength(d=>d.kind==='bridge'?0.06:0.55))
 .force('charge', d3.forceManyBody().strength(-110))
 .force('x', d3.forceX(d=>clusterCenters[d.cluster][0]).strength(0.09))
 .force('y', d3.forceY(d=>clusterCenters[d.cluster][1]).strength(0.09))
 .force('collide', d3.forceCollide(16))
 .stop();
sim.tick(400);
```
400 ticks maybe slow-ish but fine (40 nodes). ok.

Then compute bounds and fit:

```js
function bounds(){
 let x0=Infinity,y0=Infinity,x1=-Infinity,y1=-Infinity;
 nodes.forEach(n=>{x0=Math.min(x0,n.x);x1=Math.max(x1,n.x);y0=Math.min(y0,n.y);y1=Math.max(y1,n.y);});
 return {x0,y0,x1,y1};
}
function fitTransform(){
 const b=bounds(), pad=70;
 const w=b.x1-b.x0+pad*2, h=b.y1-b.y0+pad*2;
 const k=Math.min(1, W/w, H/h);
 const tx = W/2 - k*(b.x0+b.x1)/2;
 const ty = H/2 - k*(b.y0+b.y1)/2;
 return d3.zoomIdentity.translate(tx,ty).scale(k);
}
```
Careful: d3.zoomIdentity.translate(tx,ty).scale(k) gives transform x=tx,y=ty,k=k → screen = k*point + t. Point center maps to k*center+tx = W/2 ✓.

zoom interaction:
```js
const zoom = d3.zoom().scaleExtent([0.3,4])
 .filter(e=> e.type==='wheel' ? true : (!e.button && !(e.target.closest && e.target.closest('.node'))))
 .on('zoom', e=>{ viewport.attr('transform', e.transform); zoomLabel.textContent = Math.round(e.transform.k*100)+'%';});
svg.call(zoom);
const initialTransform = fitTransform();
svg.call(zoom.transform, initialTransform);
```
Note: filter for touch/wheel; for wheel we allow over nodes too (zoom everywhere) — okay.

draw:
```js
const linkSel = linksG.selectAll('line').data(links).join('line')...
linkSel.attr('stroke', d=> color of source cluster?) Use gradient? Use cluster color of source node. Both same cluster for ring, different for bridge. Use source cluster color with opacity.
```
For bridge links color maybe neutral. Use stroke from source cluster color, opacity .55.

Nodes:
```js
const nodeSel = nodesG.selectAll('g.node').data(nodes,d=>d.id).join('g').attr('class','node').attr('data-id',d=>d.id);
nodeSel.append('circle').attr('r',12).attr('fill',d=>SU[superclusters[d.super]].color).attr('fill',...)
```
Add ring stroke. Text label centered.

Drag:
```js
function drag(sim){
 return d3.drag()
  .on('start',(e,d)=>{ if(!e.active) sim.alphaTarget(0.25).restart(); d.fx=d.x; d.fy=d.y; nodeSel.classed('dragging', n=>n===d); })
  .on('drag',(e,d)=>{ d.fx=e.x; d.fy=e.y; })
  .on('end',(e,d)=>{ if(!e.active) sim.alphaTarget(0); d.fx=null; d.fy=null; })
}
```
event.x/y in parent coordinate. Parent of node <g> is nodesG inside viewport with zoom transform. d3.drag's default container is parentNode → pointer relative to parent's CTM, so coordinates are graph coords, correct including zoom. Actually default container = this.parentNode, and pointer uses getScreenCTM of the container which includes viewport transform, so yes.

Hover:
```js
const adj = new Map(); nodes.forEach(n=>adj.set(n.id,new Set()));
links.forEach(l=>{ const s=id(l.source), t=id(l.target); adj.get(s).add(t); adj.get(t).add(s); });
```
Since forceLink mutates source/target to objects, use .id getter: l.source.id.

mouseenter handler:
```js
nodeSel.on('pointerenter', (e,d)=>{ setHover(d); })
nodeSel.on('pointerleave', ()=>{ setHover(null); })
```
Also pointerleave when leaving svg? Should be fine.

setHover(d):
```js
if(!d){ nodeSel.classed('faded',false).classed('focused',false).classed('neighbor',false);
 linkSel.classed('faded',false).classed('focused',false); return; }
const nb=adj.get(d.id);
nodeSel.classed('focused', n=>n.id===d.id).classed('neighbor', n=>nb.has(n.id)).classed('faded', n=>n.id!==d.id&&!nb.has(n.id));
linkSel.classed('focused', l=>l.source.id===d.id||l.target.id===d.id).classed('faded', l=>!(l.source.id===d.id||l.target.id===d.id));
```

CSS:
node circle default; .node.faded circle { opacity .12 } .node.faded text{opacity:.08}; .node.neighbor circle {stroke-width:3} .node.focused circle{r?} maybe filter glow via CSS drop-shadow. Use classes with transitions.

Links: line stroke-opacity .45; .faded {stroke-opacity:.05}; .focused{stroke-opacity:1;stroke-width:3}.

Add .link transitions.

Reset button: 
```js
d3.select('#reset').on('click', ()=>{ svg.transition().duration(650).ease(d3.easeCubicOut).call(zoom.transform, initialTransform); });
```

Also restart sim? Not needed. But if nodes were displaced, they settle.

Also set initial transform before first draw — the transform applies anyway.

Legend with 4 swatches.

Also make labels non-selectable, and for zoom label update with initial transform applied through `svg.call(zoom.transform, initialTransform)` triggers zoom event? Yes, calling zoom.transform programmatically dispatches zoom event → label updates.

Let's write the file now. Also should handle resize? viewBox handles it.

Edge: dragging background pans — with big rect. The rect should have pointer-events all and maybe cursor grab. But zoom on svg: d3.zoom's pointerdown listener is on svg and handles events bubbling from rect. Fine.

Potential issue: d3.zoom's default filter rejects non-left button and wheel with ctrl? default filter: (!event.ctrlKey || event.type === 'wheel') && !event.button. I'll use custom filter for nodes only.

For touch support fine.

Text labels: font-size 11, fill white-ish, pointer-events none.

Let's write.

Hover also raise focused node to front? Not necessary.

Also initial alpha restart: after 400 ticks, sim.alpha(0.15).restart()? That gives gentle motion. But positions could drift slightly beyond fit? small. Let's do sim.alpha(0.12).restart() to look alive. Hmm, initial framing test: "keep the initial graph within view" — with slight settle, fine.

Actually a subtle issue: pre-ticked simulation moves nodes; then when restarting, alpha 0.12 motion. Fine.

Let me create the file.

The graph renders. Notice nodes with hover focus styling on node 0? Node 0 appears highlighted (white stroke) — probably because mouse position defaults at 0,0? Actually screenshot shows node 0 with white outline and crosshair-like neighbors? Look at node 0: white ring. And nodes 3,4 text slightly bigger? It seems hover is active on node 0 possibly due to pointer at that position during screenshot. Hmm, the browser tool's mouse may be at center 600,400 which is empty background. Node 0 has white stroke - that's `.near` or focus? Its radius looks same. Node 0 stroke white = "near" classed. Hmm, but that requires hovered somewhere.

Wait — aria tabindex=0 could give focus? No, only one element. Actually node 0's circle stroke white and text larger... nodes 3? Look closely: node 0 white outline, nodes 3 and 4 have slightly bigger text? unclear.

Maybe an initial focus event fired via `.on("focus")` when tabindex applied? No.

Alternatively the screenshot's cursor is at 0's position (approximate) at (390, 220)? The viewport center is (600,400). Hmm.

Could be hover triggered by the browser tool leaving the mouse at some position after reload? Let me check DOM classes to verify. Also cluster placement: clusters are quite spread and the graph uses most of the view — good.

Also dashed bridge links look nice. But the "hot" class is applied? Node 0 stroke white plus dashes... let me inspect via JS eval. Does the tool allow evaluating? Only inspect action gives DOM/console. I could use d3 via... there's no eval tool. I can add a temporary debug element? Alternatively inspect DOM shows classes? "dom" output was text only.

I can test interactions with clicks/drag and screenshots. Let's first check node 0 hover issue: move mouse to a neutral spot with a click? click action might toggle. Let me just take a screenshot after moving pointer... browser tool doesn't have a move action, but click/drag does. Let's do a drag on the background to test pan, which also moves the pointer.

Let me test node drag: drag node 0 from (390,220) to (300,450) and check links follow.

Node 0 was dragged to a new position and its links follow (the ring links to 1,2,3,4,5,6,7,8,9? Actually links to 0 from ring: 0-1, 9-0, 0-10 (bridge), 0-30 (bridge)). The links follow. Camera stayed at zoom 100% and layout unchanged otherwise. Good.

But the graph shows a big "halo" box around node 0? There's a square outline around node 0 — that's the focus outline? `.node:focus-visible`? I didn't style it but browser default focus ring on the g element (tabindex=0) gives a square outline. Since drag focuses the element. That square is ugly. Add CSS to suppress outline on .node:focus and instead perhaps hide default outline but keep keyboard accessibility with custom ring on circle. Set `.node:focus{outline:none}` and use `:focus-visible` to add halo. Since I handle focus/blur events for hover highlighting, keyboard users get the highlight. Add:

```css
.node:focus, .node:focus-visible { outline:none; }
```
and maybe `.node:focus-visible circle.halo{stroke-opacity:.9}`. Since I set focus class via JS, that's fine.

Also the drag position: node 0 dragged ended at y=470 which overlaps the Omega cluster slightly, fine.

Now the initial render had node 0 highlighted. Wait in the first screenshot node 0 had white stroke. In this screenshot after drag, node 0 has focus ring because of keyboard focus. Possibly in the first screenshot, the mouse pointer from the runner happened to be over node 0? The initial layout put node 0 at (390,220) which matches a default pointer position maybe at (600,400)? no. Hmm. Maybe when reloaded, the pointer was left at (390,220) from a previous session? Unclear. Let's check hover separately by moving mouse to a node with click? Click would trigger pointerenter first. I'll do a click on node 12 at (825,150) and screenshot.

But first fix the outline CSS.

Now test hover. Reload then click on a node's location (after reload, layout is pre-ticked deterministic? d3 simulation uses Math.random for jiggle, so layout differs each reload slightly. I'll screenshot after reload to know positions, then click a node.

Also test pan+zoom and reset.

Let's reload.

Again node 0 has a white outline at (391,221) with no dimming. That is the "near" styling? `.near circle.core{stroke:#f4f8ff; stroke-width:3}` and halo .55. It looks like a white ring on node 0 only. Hmm, and neighbours are not highlighted. So maybe hovered is set but the dim classes not applied? But if focused=node 0, dim would apply to others.

Actually maybe it's a circle.halo with stroke-opacity .55? That would be a thin ring at r=20, but the white ring here is at r=13ish tight.

Wait — maybe the pointer is at (391,221)? The runner's mouse default may be at 0,0 though. Hmm. But could node 0 receive `focus` event? SVG g with tabindex... no autofocus.

Let's figure out: is the white stroke the "dragging" style? No.

Alternatively, node 0's core is rendered with stroke from... `.node.near` applies when neighbour of hovered. If hovered node were, e.g., node 1 at (385,163), then node 0 would be near (white stroke) but also node 1 would be focused (glow). Looking at node 1: it has a slightly white-ish ring? Node 1 at (385,163) appears to have lighter stroke maybe. And node 2 also appears brighter stroke? Hard to tell.

If hover is on node 1, then neighbours: 0,2 and its ring neighbours 0 and 2 → nodes 0 and 2 highlighted white; others dimmed. But others clearly aren't dimmed.

So likely `near` class applied to all nodes? No... `.near` requires nb.has(n.id).

Hmm, maybe it's the `near` class on... Let me actually inspect the SVG via a debug: I can add a temporary script that writes hover info into the DOM/title. Easier: use `inspect`? The inspect output shown is just text. Maybe inspect provides classes info? Let me try inspect action.

Now node 0 no longer has a white ring (this is a re-render). So the earlier "highlight" on node 0 was the browser pointer hovering at (391,221)! It's the runner's default mouse position? Hmm, in this inspect frame node 0 normal.

Wait, earlier screenshot: node 0 white ring plus its links to 1..9 looked... Actually the ring at node 0 with white stroke = near? Let's test hover deliberately: move pointer over a node using click at its center and screenshot. Click will trigger pointerenter and set hover (mouse remains). Let's click node 12 at (825,150).

But clicking might also cause dblclick zoom if double clicked; a single click just focuses. Let's do it.

Hover isn't triggering with click? Nothing dimmed. Node 12 at (824,150) — the click was at (824,150), which should be right on it. Hmm, maybe the click doesn't generate pointerenter (the harness may synthesize mouse events only, without pointer events). But hover in real browsers works with mouse. Requirement mentions "hovering". Real mouse movement fires pointerenter. However if the grader uses mouse events (mousemove) without pointer events, hover would fail. Safer: use mouseenter/mouseleave in addition to pointerenter/pointerleave. Since mouse events are typically synthesized by test harnesses (Playwright dispatches real input, which fires both). But the click here didn't set hover, suggesting the harness's click moves the mouse? Playwright click moves mouse to coordinates → mousemove → pointerenter should fire. Unless the coordinate mapping in the harness differs from screenshot pixels? The screenshot is 1200x860 while viewport is 1200x800. Ah — the screenshots are 1200x860 tall? The image seems 1200x860. The browser tool says coordinates use a 1200×800 viewport. The screenshot includes extra height? The image displayed is 1200x860 maybe scaled. So my y coordinate mapping might be off by a factor.

Actually the screenshot appears 1200x860 in dimensions, indicating device pixel ratio or the page is taller than the viewport... The tool says 1200x800 viewport. If image is 860 tall, there's a mismatch ~1.075 factor. Node 12's y in image = 150 → in viewport coords ≈ 150*800/860 = 139.5. x = 824*1200/1200 = 824. Close enough to hit a 13px-radius circle? A 10px miss might still be within the node in view (r=13 in viewBox units; the SVG is scaled ~1170/1000 = 1.17, so r ≈ 15px). y off by 10 is borderline.

Let me try clicking closer with corrected mapping: node 12 at image (824,150) → page (824, 139). Try click (824,140).

Also earlier the "highlight" on node 0 at image (391,221) → page y≈206, suggests the pointer was at (391,206)? Coincidence unlikely; probably the pointer default is somewhere and node 0 happened... Anyway.

Let me test hover with mouse move? The tool has no move. Click at corrected coords.

Also add mouseenter/mouseleave handlers for robustness.

Hover works: node 12 focused with glow, neighbors 11,13 highlighted, connecting links bright, everything else dimmed. 

One issue: hover also caused node 12 to gain keyboard focus (since tabindex) but that's fine. However, this hover state stays after the click - the pointer is still over node 12. Good.

Note: the dimming also affected the links to the neighboring hub? Fine.

Now test pan and zoom, then reset. Pan: drag background from e.g. (600,700) to (700,650)? Need page coords. Background at image (600,700) → page y = 700*800/860 ≈ 651. Let's drag from (600,520) image → page (600,484). Use drag from (600, 480) to (720, 400). Then check zoom label / screenshot showing shifted view. Then wheel scroll with delta negative at (600,400) to zoom in, then reset button click at (86, 82*800/860 ≈ 76) → (86,76).

Careful: drag starting at page y=480 might land on a node? At image (600,480) - that's empty background between clusters. In page coords, (600, 446) is empty too. Good, use drag (600,470)→(700,400).

First move pointer away to avoid hover affecting visuals; dragging background moves pointer anyway.

Pan worked: the graph shifted right/down (bottom nodes clipped, header still shows Zoom 100%). But the zoom label shows "Zoom 100%" — that's fine since pan doesn't change scale. Good, and camera moved while graph stayed same. Note the pan label doesn't indicate panning, okay.

Also note the label at bottom "Zoom 100%" shows. Fine.

Now hover got cleared when dragging background? Yes since the pointer left node 12.

Now wheel zoom. Use scroll with delta -400 at (600,400).

Zoom works: 179%. Now click Reset view. Button at image (86,82) → page y ≈ 76.

The click at (86,75) didn't hit the button (label still 179%). The button in image at (86,82) with height ~30 (y from ~67 to ~97). Page coordinate = image y * 800/860 = 75 → 82*0.93 = 76. Hmm, that should have hit. Unless the image is exactly 800 tall and displayed at 860? Let me check the image dims: it says 1200x860 in the rendering. Hmm.

Maybe the transform is: the screenshot is 1200x860 because the viewport is 1200x860? The tool description says 1200x800. But the click at (824,139) hit node 12 at image y=150, meaning there's a scale factor of ~0.93 (860→800). So button at image y 82 → page y 76. Click at 75 should hit within button (image 67-97 → page 62-90).

Unless the "click" action in the harness doesn't dispatch mouse events at all? But earlier click on node 12 did trigger hover/focus... Hmm, node 12 got focus (a focus ring / glow appeared). Actually the focus ring shown could be from hover only.

Wait — after the background drag, hover cleared. The click at (824,139) then showed node 12 highlighted — so click did move pointer and fire mouseenter. So clicks work.

Why didn't reset work? Maybe the button click happened but transition takes 700ms and the screenshot was taken too early? The frame appears immediate. The label still 179% and same view. Possibly transition hasn't finished. Let's take a screenshot now to see if it reset.

Reset view works — returns to Zoom 100% and initial framing. But note the layout has shifted slightly from the pre-reset pan screenshot because nodes settled after earlier drag/hover? Actually the node positions look similar to the initial view but appear expanded (nodes bigger? no). Compare first screenshot: nodes at same positions roughly. Fine.

However, an issue: the initial framing leaves a lot of empty space on left/top — fitTransform computed bounds including cluster extents, but the graph occupies the whole 640 height. Looks reasonable.

Also note the reset result differs slightly from load because the initialTransform was computed after pre-tick. Good.

One remaining concern: initial framing shows nodes near the bottom (node 33 at y~690 in image → within stage). Fine, within view.

Also the requirement "keep the initial graph within view" ✓.

Additional check: dragging a node while zoomed — drag coordinates use container CTM. Let me test: zoom in, then drag a node and see if it follows the cursor. This is a subtle bug risk (event.x from d3.drag with container=parentNode uses the g's CTM → correct). Let's verify quickly.

Also with zoom, d3.drag's default container is parentNode, and it calls d3.pointer(event, container) which uses getScreenCTM inverse of the container → includes zoom transform. Good.

Let me do a zoom-in then node drag check.

The scroll didn't zoom this time — label still 100%. Why? Earlier the scroll worked (179%). Perhaps the mouse was at (450,300) over a node? No, filter allows wheel anywhere. Hmm, maybe this scroll event landed while the previous transition was still running? No, plenty of time.

Possibility: the scroll delta positive vs. negative: earlier I used -420 and got 179%. Now -300 with no change. Odd. Maybe the sandbox's scroll synthesizes a wheel event at a location, and d3.zoom requires the wheel event's deltaMode etc. Should work.

Maybe the pointer was over node 0 at (393, 224) → image; page (393, 208)? My scroll at (450,300) — not on a node. Hmm.

Could it be that the reset transition is still "sticky" — d3 transitions on zoom... no, finished.

Let me retry scroll.

Still 100%. So wheel zoom stopped working after reset? Interesting — that would be a real bug: after `svg.transition().call(zoom.transform, initialTransform)`, d3.zoom's wheel handler should still work. But wait — the earlier successful zoom was before the reset. Hmm.

Possibility: d3.zoom on a transition marks `wheel` interrupt? No.

Another possibility: the scroll events sent by the harness are dispatched at the document level and d3.zoom's wheel listener is on svg only; the first scroll worked though.

Alternatively the scroll events target the element under the pointer; at (600,500) page → image y=537. That's inside svg. Hmm.

Wait: after the reset transition, maybe the transition left `__zoom` in an odd state... no.

More likely explanation: my scroll at (600,500) page coordinate maps to the stage but maybe the pointer is over the hint text (pointer-events:none, so fine).

Actually, could the issue be that the scroll goes to a different scroll container? The first successful scroll was at (600,400) before any click. After failing, the label persists 100%.

Hmm, maybe d3's zoom wheel handler ignores events when `event.deltaY` is 0 with deltaMode? The harness may deliver deltaY based on `delta` but if page has nothing scrollable it still dispatches.

Let me test whether a pan still works after reset (drag background). If pan works, zoom internals are fine and just wheel delivery differs.

Also maybe scroll needs the pointer to have been moved (mousemove) to that location first, and the harness scroll targets previously known mouse position? Possibly the harness scrolls at (0,0) or current mouse pos. The first scroll at (600,400) worked... maybe the mouse was at (600,400) from a prior drag (drag ended at 760,560 though). Hmm, the drag start was (600,470); after the drag the mouse is at (760,560). Then scroll at (600,400) worked → so scroll positions are honored.

Unless... the scroll at (600,400) worked because zoom was NOT reset then. Now after reset, something breaks wheel. Let me check: d3.zoom's `zoom.transform` invoked on a transition sets `gesture.zoom`? No. There is a known issue: `zoom.transform` during transition sets `this.__zoom`, and `wheel` still works.

Hmm, but there's a subtle issue in d3.zoom: after a transition-based transform, when the transition ends it calls `interrupt`... no.

Let's debug: maybe the wheel handler is fine but the d3 wheel listener requires the event to be cancelable & not passive. Same as before.

Let me test pan first.

Pan still works after reset (graph shifted up-left). So zoom's pointer handling is alive; only wheel isn't. Why did the earlier wheel work?

Hypothesis: the earlier successful wheel followed a `drag` interaction in the stage — maybe the harness's scroll only dispatches when the mouse position is "inside" a scrollable? Eh.

Alternative: d3.zoom's wheel is prevented by the page having `overflow:hidden`? That doesn't matter.

Wait... maybe both scroll actions did work but then a `click`/`screenshot` reset? No, label stayed 100%.

Another thought: The wheel event may require the SVG to have `pointer-events`. The svg has cursor grab by CSS and no pointer-events none.

Hmm, but maybe wheel zoom happened and then immediately got reset by something? The reset transition sets zoom to identity — that's what we saw before clicking. In the failed attempts, the value stayed at 100% and the view was the initial framing, which would also be the case if zoom snapped back. Is there anything resetting? No.

Hmm — the reset click: I clicked the button at (86,75) but the Zoom label only changed to 100% later in the following screenshot. That suggests the click did happen and transition ran. Fine.

Maybe the harness `scroll` action sends a wheel event without deltaY? First time it worked with delta -420 at (600,400) → 179% (0.3^? : d3 scale factor). That's a large zoom: k = 2^0.002*delta... d3 uses -deltaY * 0.002 → 420*0.002 = 0.84 → k = 2^0.84 = 1.79. Yes matches.

Now -300 should give 1.0*2^0.6=1.52. Status stayed 100%... so nothing.

Could pointer position matter: second and third attempts at (450,300) and (600,500). Between them, pan worked at (600,440)-(520,400). So the wheel at (600,500) before pan should work.

Is it possible that the wheel listener was removed by d3.zoom during the transition? In d3-zoom, `zoom.transform` when called on a transition: schedule with `gesture.end`? Looking at d3-zoom source: `zoom.transform = function(collection, transform, point, event)` → it sets `this.__zoom` and if selection is a transition, `schedule(selection, ...)` with `wheel.zoom` interrupt? There's `interrupt` handling: the schedule function's end handler calls `gesture.end()`? No, that's only for gesture.

Actually in d3-zoom, the `schedule` function for transitions does:
```js
function schedule(transition, transform, point, event) {
  transition.on("start.zoom", function() { gesture(this, arguments).event(event).start(); })
    .on("interrupt.zoom end.zoom", function() { gesture(this, arguments).event(event).end(); })
    .tween("zoom", ...)
```
Then `gesture.start()` and `.end()`... `gesture.end()` calls `this.that.__zoom = transform` etc. During gesture end, `wheel.zoom` listener? No.

Hmm, but something notable: `gesture()` looks up `this.__zoom`... It's fine.

Wait — one important detail: `zoom.end` on transition end calls `gesture.end()` which invokes `nodrag`, `noevent`... and also `this.that.__zooming = false`? Not relevant to wheel.

So likely wheel works fine in a real browser, and the harness scroll action is finicky (maybe it dispatches wheel only when the pointer is over the element AND the event is not consumed, or it uses the last known mouse position from a preceding click/move). Actually the successful scroll happened right after a drag that ended at (760,560). Then I scrolled at (600,400). So position not from pointer either.

Hmm, maybe the harness's scroll requires the target element to be scrollable and it scrolls the window/document; when the document has no scrollable content, no wheel event is generated — but the first one worked... unless the first one worked because the page had focus/pointer over the svg from the drag that ended there (pointer capture?). Ah — that could be it: after a drag ending at (760,560) over the svg, the harness's subsequent scroll targeted the element under the pointer... but (600,400) also over svg.

Hmm, maybe the difference: the first scroll came after a real pointer-down/up sequence over the SVG; mouse hover state was set on the SVG. The later scrolls came after a click on the button (focus on the button, mouse over the top-left). When scroll is dispatched, maybe Playwright's mouse position is the button area (outside svg) — wheel events don't bubble to svg from outside. That explains failures: after clicking the Reset button, the mouse is at the button location; the harness's scroll(x,y) may not move the mouse first.

So to test wheel now, move the mouse into the stage via a click on background (which also gives pointer position), then scroll. Let's click at (600,650) page (empty background) then scroll.

Actually clicking background could cause dblclick zoom? Single click is harmless.

Let's do click at (350,600) page (background, under the Delta cluster? image y=645; x=350 - empty-ish). Then scroll.

Wait — the view is back to the initial framing and the previous pan was undone?! I clicked background at (400,640) and the view returned to initial framing. That's suspicious: clicking pan?? No... unless my earlier "reset" transition was still running and the pan appeared, then it continued? No.

More likely: a click on the background triggers a zoom "click" → d3.zoom's dblclick handler zooms, single click no-op. Hmm.

But the view looks exactly like the initial framing and zoom is 100%. Before this click, the view was panned up-left ~ -80,-40. After the click it returned. That means `svg.call(zoom.transform, initialTransform)` was re-run — but only the Reset button calls it. Did my click at (400,640) hit the Reset button? No, the button is top-left.

Hmm... unless the click was registered at the button coordinates due to some coordinate mapping issue. Unlikely.

Alternative explanation: d3.zoom's click handling — `zoom` has a `click`-related behavior? d3.zoom has `dblclick.zoom` only. Single click no-op.

Wait, maybe the earlier drag panned and then the sim re-settled, and my perception of shift was due to the layout moving, not the camera. Compare the two screenshots before/after drag: Before drag (after failed scroll): node 0 at (393,224). After drag: node 0 at (312,183). That's a shift of (-80,-40)... and node labels stay the same size. Camera unchanged (100%). The whole graph moved by (-80,-40) — consistent with pan. But could it be the simulation re-layout after dragging? No node drag occurred there. Hmm, but hmm—the pan drag was at (600,440)→(520,400), delta (-80,-40). Exactly matches. That confirms pan.

So now a background click restored the framing?! That would mean d3.zoom's dblclick handler fired? A double-click zoom sets k*2 and centers at pointer, not restoring initial transform. Yet the label reads 100% and framing is initial.

OK here's another thought: `svg.call(zoom.transform, initialTransform)` — maybe a transition still pending from the reset that restarts? The transition was 700ms and long finished (several tool calls).

Hmm, what about my click at (400,640) landing on... page y=640 → image y=688 which is inside the stage (background). Nothing.

Wait, unless the click was a "double click" because the harness's previous click at (86,75) on the Reset button plus... no, different positions.

Let me directly verify zoom transform state. I could add a temporary overlay reading `d3.zoomTransform(svg.node())`. Better: use the `dom` output? I can append a hidden element with the current transform updated on zoom; then inspect's DOM shows it. Actually, add a status pill already: label shows zoom only. Let me add the transform translation to the label? That might be useful anyway — display zoom % only is fine, but for debugging I'll temporarily append data attributes to the SVG, e.g. `svg.attr('data-zoom', [k,x,y].join(','))`, which will show in inspect's DOM? The inspect output only shows text content, not attributes. Hmm.

Add a temporary debug div with text of transform, then inspect shows it. Let's do that, test scroll and click, then remove.

Actually simpler test: perform a pan again, screenshot, then click background, screenshot. If click restores framing, that's a bug — but caused by what? Could it be that clicking triggers `focus` on an SVG parent... no.

OH WAIT. I see it. `.on("focus", ...)` on node groups... no.

Hmm, what about d3.drag on the big background rect? No.

Another candidate: the `<rect class="bg-hit">` covers x=-5000..6000 and my click at (400,640) is on it. Clicking there is fine.

What about the hint text? pointer-events none.

Could the "click" action in the harness dispatch mousedown/mouseup and also a simulated dblclick because of timing with the previous drag? A dblclick on the svg at (400,640) would zoom to 200% centered there, not reset.

Unless... x/y I passed as page coords get scaled and the harness clicked at the Reset button again?! If the harness interprets coordinates in image space (1200x860) but the actual viewport is larger (e.g., 1200x860), then (400,640) image = page (400,640). Reset button is at (46-132, 66-100). Nope.

Let me stop speculating and add debugging text to the page, then run a fresh reload and carefully test: pan → check, wheel → check, reset → check, all with screenshots. Possibly my earlier reading is wrong — maybe the pan screenshot was mid-transition of the reset (the reset transition interpolates camera; after drag it showed a partially-restored state, and then it finished). Timeline: click reset (t), screenshot showed 100% — hmm, that was already final.

Actually no! Look at the sequence: I clicked Reset, screenshot showed 100% with initial framing. Then scroll (no effect), scroll (no effect), then drag pan (shifted), then click background (back to initial). 

Hmm, alternatively: the drag pan moved the graph because the drag was interpreted as a *node* drag?? No, the graph shape stayed rigid.

Let me consider that the pan did nothing and the graph moved because of simulation re-heating — after reset, no reheat. But the shift was exactly the drag delta; unlikely coincidence... although the simulation had been reheated by node drag/hover earlier; could shift by tens of px.

Ugh. Let's instrument. I'll add a debug status showing transform k,x,y, replacing zoom pill content (useful anyway: "Zoom 100%"). I can show pan too? Keep the pill as zoom and add `data-*` attribute to the stage plus include in DOM via a hidden pre? The inspect DOM text extraction may include hidden text. Let me add a `<pre id="dbg" style="position:absolute;bottom:0;right:0;font-size:10px;opacity:.5">` showing transform. Then inspect shows text.

Let me implement and test.

The debug text overlaps the legend (I'll remove it later). Initial transform: translate(0.39, 4.03) scale(1) — so k=1 and centered.

Now scroll test without touching the button: scroll at (600,400).

Scroll produced no zoom. Hmm. And the graph moved slightly (node 0 from (392,224) to (401,232)) — simulation still settling (alpha decay). So earlier "pan" delta may partly be simulation, but the whole-graph rigid shift of exactly 80,40... whatever.

Why doesn't wheel work now? Earlier it worked once. Maybe d3's wheel handler is attached to the svg and the harness scroll targets document at coordinates that don't matter... but the first wheel worked, right after the drag. Hmm, after dragging, d3.drag may have applied pointer capture...?

Key difference: after a drag interaction on the svg, the svg element holds focus? Or d3.zoom's `wheel` listener works only when `this.__zooming` false and requires `event.ctrlKey`? No.

Actually! Maybe the issue is that d3.zoom's wheel handler is registered with `{passive: false}` via `d3.select(window).on(...)`. It first checks `if (event.type === "wheel") ... zoombegins?` Let me recall d3-zoom source:

```js
function wheeled(event) {
  if (!filter.apply(this, arguments)) return;
  ...
}
```
And `defaultFilter`:
```js
function defaultFilter(event) {
  return (!event.ctrlKey || event.type === 'wheel') && !event.button;
}
```
My custom filter handles wheel returning true.

Then `if (g.zooming || event.deltaY ... )`. Hmm, in d3-zoom 3:
```js
function wheeled(event) {
  if (!filter.apply(this, arguments)) return;
  var g = gesture(this, args).event(event),
      t = this.__zoom,
      k = Math.max(extent[0][0]... )
```
Nothing blocks.

Perhaps the harness's scroll action dispatches a wheel on the element found by document.elementFromPoint, but it could be hitting `.bg-hit` rect inside... still bubbles to svg. Unless it dispatches on the document root without bubbling? Then the first success is inexplicable.

Wait, maybe the first success wasn't a wheel: the screenshot after scroll showed "Zoom 179%" and much larger graph. That was definitely wheel.

Difference between then and now: NOW there's a `<pre id="dbg">` overlay. Irrelevant.

Hmm, and the previous failing attempts came after clicking the Reset button; the successful one came before any button click. Is the Reset button stealing something? No...

Actually! Maybe wheel zoom *is* working but gets reset immediately by an *active transition* from the reset? No, the reset was long done.

Hold on. Look at the DOM order of `#zoomLabel` etc. Not relevant.

Let me think about d3.zoom's `wheel` implementation more carefully — it uses `d3.pointer(event, this)` etc. It also has:

```js
function wheeled(event) {
  if (!filter.apply(this, arguments)) return;
  var g = gesture(this, arguments).event(event), ...
```
and gesture() sets `that.__zoom` etc, and `g.wheel` ... ends with:
```js
  if (g.wheel) { g.mouse = [p[0], p[1]]; interrupt(this); g.wheel = null; }
```
Wait, that's in `wheeled`: `if (g.wheel) { ... }`? Let me actually read the d3 source in the file.

Let me grep d3.min.js for the wheel handler.

Let me find the wheel handler T function in d3.min.js. Search around `"wheel.zoom"`.

Now find function T definition. Search for `function T(` maybe with different formatting... The minified uses function T(t){...}? Let me search "w(this,arguments)" occurrences or `function T`.

The zoom wheel handler is in the d3-zoom bundle; but this d3.min.js seems to include d3-drag too. The wheel handler T must be defined inside `t.zoom=function(){...}`. Let me extract that region and examine T.

Key line in `T` (wheel):

```js
if(e.wheel) e.mouse[...] ...
else { if(i.k===u) return; ... }
```

If the scale doesn't change (u===i.k), it returns early. u = clamp(k * 2^a) where a = -deltaY*0.002 for deltaMode 0. If the harness's wheel event has deltaY == 0 (maybe it dispatches wheel with only `deltaX`? or deltaY computed differently), then u===i.k → early return, but also e.wheel isn't set, so no updates. That explains no zoom!

But earlier one worked with delta -420. Hmm, maybe deltaScroll is delivered as a wheel with deltaY but the harness may deliver delta in pixels only sometimes. Wait, the first successful scroll used delta -420 and gave exactly k = 2^0.84, which implies deltaY = -420, deltaMode 0. So deltaY was passed. Then at delta -300, expected k=1.516; status showed 100%. Weird.

Unless... after the first wheel, zoom got reset by clicking something. The successful wheel was before I clicked Reset. Then I clicked Reset. All subsequent wheels failed. Is it possible that `svg.call(zoom.transform, initialTransform)` inside a *transition* leaves `g.wheel` untouched but leaves `__zooming` true?! Look at the transition scheduling:

```
t.on("start.zoom", () => w(...).event(r).start())
 .on("interrupt.zoom end.zoom", () => w(...).event(r).end())
```

`w(t, n, e)` returns `!e && t.__zooming || new M(t,n)`. During transition start, w() creates a new gesture M and `.start()` sets `this.that.__zooming = this` (probably) and active = 1. On end, `.end()` sets `__zooming = null` if active... The `start()` sets `this.active = 1`? In d3-zoom's M methods:

```js
M.prototype = {
  event: function(event) { ... },
  start: function() { if (++this.active === 1) this.that.__zooming = this, this.emit("start"); return this; },
  end: function() { if (--this.active === 0) delete this.that.__zooming, this.emit("end"); return this; },
  zoom: ...
}
```

Both start and end are called on the transition, so balanced.

Hmm, so after the reset transition, `__zooming` should be deleted. Unless the transition was interrupted (`interrupt.zoom`) without end? No.

Then why would wheel fail? Actually, wait: maybe wheel didn't fail. Maybe the wheel *did* zoom but the `zoom` handler updated the label... it showed 100%. The debug pre showed the same transform. So no.

Another thought: `Gi(this)` in the wheel handler — Gi likely is `interrupt(this)` which interrupts transitions. Not relevant.

Maybe the harness's scroll action targets the element under the mouse *without* moving the mouse first, so it uses the last click position. After clicking Reset at (86,75), the wheel would be dispatched over the button (outside svg) — but wheel events on the button don't reach svg, so nothing. That fits perfectly! And the successful scroll: prior action was a drag in the stage, so the pointer was in the stage.

Then my later scrolls at (600,500)/(600,400) failed because the pointer was still at the Reset button. And the click at (400,640) then moved the pointer into the stage → later scrolls should work! But I scrolled at (600,400) after the reload+? Sequence: reload (pointer unknown), scroll at (600,400) failed. Hmm, after reload the pointer may be at the previous location (the reset button). Then drag pan at (600,440) → pointer in stage. Then click background at (400,640) → in stage. Then reload → pointer stays at (400,640)? Then scroll at (600,400) → should work but failed.

Unless the scroll uses the element under its *own* coordinates. Hmm.

Let's just test now: click in background at (400, 620) (pointer there), then scroll at same coordinates. Earlier after the reload I did scroll without a preceding click, and it failed.

Actually here's a stronger hypothesis: the harness scroll moves the wheel over the given coordinates, but d3.zoom's wheel listener is bound to the SVG with `{passive:false}`. If the target is the `rect.bg-hit` inside the svg, the event bubbles. Fine.

Hmm, but note: after reload the scroll failed at (600,400). Before the reload it failed too (after reset). The one success was the first wheel ever. Then maybe *something* broke permanently for the page load: after a `zoom.transform` transition, maybe d3 sets `svg.__zoom` and the wheel works fine...

Test directly: reload (fresh) and scroll immediately without clicking anything, comparing to the very first time (where I dragged node 0, dragged view? sequence: reload, drag node 0, reload, inspect, click node, reload?, ...). Actually the first successful wheel came after: reload → drag node → reload → inspect → click node(824,150) → click(824,139) → drag background → scroll -420 (SUCCESS).

So the successful wheel followed a drag on the background.

Current state: last actions were scroll fails after reload with no drag. Then drag pan (worked), click background, then scroll failed.

Hmm, contradiction. Unless the "click" at (400,640) with page coords is actually clicking the Reset button (if coordinates map differently!). If the mapping were such that (400,640) → some other point... no, pan worked at (600,440).

Wait, maybe the background click triggered d3.zoom's dblclick? Not with a single click.

Let me test right now an explicit sequence: drag background 20px then scroll at the drag end point.

Actually, maybe the issue is the overlay `<pre id="dbg">` at bottom-right? It's small.

I'll try scroll at (600,400) now.

Still no zoom. So wheel is broken on this page state. Let's test if wheel works after a fresh reload without any prior click: reload then scroll.

But before that — maybe my custom `filter` function is causing the problem due to `event.target.closest` on `wheel`? In my filter I return true for wheel first. That's fine.

Wait... maybe the problem is `d3.zoom().filter(...)` receives the wheel event, returns true, but `ne(t)` (pointer) works... fine.

Hmm, another thought: the harness's `scroll` maybe dispatches wheel on `document.elementFromPoint(x,y)` where coordinates are interpreted in CSS pixels of the final scaled screenshot. Since the screenshot is 1200x860 but viewport 1200x800, a 1.075 scale. Not relevant for hit testing inside the stage.

BUT: if the wheel is dispatched at page coords (600,400) → that's inside svg. Bubbles. Works.

Unless the wheel event's deltaY is `-260` but d3 computes Cw(t) = -deltaY*(deltaMode===1?0.05:deltaMode?1:0.002)*(ctrlKey?10:1) = 260*0.002 = 0.52 → k = 2^0.52 = 1.43. Should change.

So the event isn't reaching d3. Maybe the harness's scroll sends `wheel` events with `bubbles:false`? Then svg listener not triggered... but the first scroll worked.

Hmm hold on, did the first scroll actually trigger wheel? Maybe the harness's scroll action performed a keyboard/other mechanism? It reported Zoom 179% exactly matching -420 delta. So yes.

Difference: the successful scroll happened while the mouse was still over the SVG from a drag (i.e., the "hovered element" was inside svg). Now maybe the wheel is dispatched to the previously hovered element from the last click = the svg background at (400,640)... also inside.

Grr. Let me try scrolling with much bigger delta and different coordinates, e.g. over a node at (900,160). Also try a positive delta to zoom out (maybe zoom-out works?). Let's try.

No zoom at all. Since d3's wheel logic depends on `__zoom`, and `svg.call(zoom.transform, initialTransform)` sets `__zoom` — this happens on the SVG element. Fine.

Wait... maybe multiple zoom behaviors are attached? No.

Hmm, important: `svg.call(zoom)` attaches listeners to #graph. `svg.call(zoom.transform, initialTransform)` sets __zoom.

Let me check the wheel handler condition again:

```js
function T(t,...n){ if(r.apply(this,arguments)){ var e=w(this,n).event(t), i=this.__zoom, u=clamp(i.k*2^a(...)), s=ne(t);
```

`w(this, n)` = `!e && t.__zooming || new M(t,n)`. Here `e` = third arg undefined → `!undefined && t.__zooming` → `t.__zooming`. If `__zooming` is left set from the reset transition, then each wheel gets the same stale gesture... but that wouldn't block it; the transform would still update. The debug shows no change at all.

Hmm, so the wheel event is not reaching the handler at all. Which means the harness's scroll doesn't dispatch a wheel to this element. But it did once.

What differs between that moment and now? At that moment the SVG had an active "hover" on node 12 (mouse over node). Also, critically, `reset` had not been clicked. After clicking reset, wheel events never worked.

Wait... unless the button retains focus, and the scroll action scrolls the focused element? Nah.

Alternatively, maybe the harness scroll sends `page.mouse.wheel` at the current mouse position, ignoring x/y! That would explain everything: after the background drag the mouse was at (760,560) → wheel worked. After clicking Reset, mouse at (86,75) → wheel over the button, outside svg → ignored (page not scrollable). Then later clicks at (400,640)... mouse inside the stage... Yet subsequent scroll failed. Hmm, unless clicks don't move the mouse (they use elementFromPoint at coords). Ugh.

But wait: the click at (824,139) *did* trigger hover on node 12, so it moved the mouse (or hovered at that point). And the "pan" drag definitely uses coordinates.

Hmm, so after clicking the background at (400,640), the mouse should be in the stage. Then scroll failed. Contradiction.

Unless the click at (400,640) didn't register in the stage at all (perhaps it hit the hint area? no, that's pointer-events none, so hits svg).

Hmm, let me test differently: drag background by 5px (mouse end inside stage), then immediately scroll at the same end point, and see.

Pan moved transform to translate(17.8, 12.7) — note it's not the cumulative expected value (initial 0.39 + 20 = 20.4, 4.03+10=14.03) — close enough with scaling factor. Camera panned. Good, so page coords ≈ 0.93*image.

Also note the graph layout keeps changing between screenshots (nodes drifting), meaning the simulation is still running with alpha never fully stopping? `sim.alpha(0.16).restart()` cools to alphaMin (0.001) after ~300 ticks ≈ 5 s. But layouts differ across screenshots minutes apart, e.g., node 20 moved. That suggests the simulation keeps restarting or alpha target stays > 0? Hover doesn't reheat. Drag end sets alphaTarget(0). Hmm, but the alpha transition: `sim.alpha(0.16).restart()` → decays.

Compare: before drag node 0 at (404,237); after drag node 0 at (416,236) — shifted by +(12,-1) while camera +(17.4,8.7). So the layout is still settling? Actually maybe the screenshots are taken at different times and the sim is long done; then positions should be identical given same camera shift: expected (421,246). Observed (416,236) — close but not exact... whatever, likely layout still moving slightly due to ongoing alpha (sim.time advances slowly since ticks are throttled in headless? maybe).

Now immediately scroll.

Wheel zoom works (143%). So the earlier failures were an artifact of the harness scroll targeting the last hover position, likely outside the SVG or over the button. Good — wheel functionality is fine.

Now, one visual issue in this zoomed state: the legend overlaps nodes, fine.

Next: test Reset after zoom — click Reset at page (86,75). Then verify transform back to initial.

Also I should verify node dragging while zoomed so links follow. Let's do it: drag node 0 currently at page coords ≈ image(326,175) * 0.93 → (303,163). Drag to (400,300) and check links follow and camera unchanged.

Then reset.

Hmm — the camera panned during this drag (translate changed from -199,-102 to -114,17) instead of dragging the node. The node 0 did not move to (400,300); the whole view shifted by about +85,+120 — exactly the drag delta (97,138 scaled). So the drag panned the camera instead of dragging node 0.

Why? Because my drag start coordinate (303,162) was slightly off the node (node 0 image center is (426,312) → page (396,290)!). I misread the screenshot: node 0 is at image (426,312), so page ≈ (396,290). I used (303,162) which was node... that's near nothing (empty). So the background pan happened. My coordinate mapping was misread; the zoomed view shifted.

So drag node 0: image (426,312) → page (396,290). Let's drag from there to (500,430) page.

Kill two birds: verify link following while zoomed and camera unchanged (transform stays translate(-114.5,17.5) scale(1.434)).

Again the camera panned (translate changed by +108,+130), not the node. So the node drag isn't catching. Hmm! The transform change matches the drag delta, so pan handled it, meaning the drag started on background, not node 0. But node 0's circle at image (551,466)... wait in this new screenshot node 0 is at (551,466). Before the drag, node 0 was at (426,312) in that screenshot. I dragged from image-equivalent (426,312)→page(396,290).

Hmm, was the node at (426,312)? Yes in the previous screenshot node 0 was at (426,312). Page coord = (396,290) with the 0.93 y factor and x 1.0? But wait — maybe x also needs scaling! The screenshot is 1200 wide and viewport 1200 wide, so x maps 1:1. Node at x=426 → page x=426, not 396. I used x=396 → off by 30px, missing the node (r≈19 at zoom 1.43). And y: 312*0.93 = 290 ✓. So x was off.

Let me redo: node 0 is now at image (551,466) → page (551,434). Drag from (551,434) to (650,540).

Camera currently translate(-6.6,148). Expect camera unchanged after node drag.

Now node 0 was dragged: it moved to the new position, its links follow (bright blue lines fanning to 1,2,3,4,9, bridge to 10 and 30), and the camera transform is unchanged (-6.57,148.1). Hover/focus ring on node 0 with neighbors 1,9,10 highlighted. 

Note the "near" links look bright-ish (the hot links are the ones connected to 0 — indeed links 0-1,0-2,0-3,0-4,0-9,0-10,0-30 are bright, others normal-ish but not dimmed? Actually links not connected to 0 appear dimmer (0-5 etc.), and nodes not neighbors are dimmed. Good.

Hover was triggered by the mouse being at the drag end point over node 0 — good.

Now click Reset view (page 86,75) and verify transform returns to translate(0.39,4.03) scale(1).

The reset transition started (transform mid-way, 143% still). Need another screenshot after 700ms to verify completion. Also node 0 released and simulation relaxed back into the ring.

Let me screenshot again.

Reset restored to the exact initial transform translate(0.39,4.03) scale(1), and the layout has re-arranged into four clean clusters (clusters moved after the drag). Graph is fully in view. 

Issues to fix:
1. Remove the debug `<pre>` overlay (it overlaps the legend).
2. Cluster positions: the top-left cluster ended up near the top-left but the Gamma cluster at bottom-left — fine, but now confirmed a nice layout.
3. Deselect hover state after reset? Not needed.

One thing: after the reset, the graph is positioned a bit right/low relative to stage center — the fit was computed at the initial pre-tick state, and clusters shifted later. The graph is still fully in view with margins. Fine.

Also check: node drag doesn't set hover stuck after release? Already handled by pointerleave.

Another improvement: the requirement "Dragging a node moves it while the graph responds; release lets the simulation settle." ✓.

Let me remove the debug element and its JS. Also maybe stop the ongoing sim motion earlier so layout is stable — fine.

One more check: the visible legend "Alpha·0–9" etc. Good, colors distinct.

Also the header mentions clusters.

Let's remove debug and do a final reload + quick console check + screenshot. Also verify that the initial graph is fully within the stage after the fresh load.

Clean initial view, all 40 nodes in view, four color-coded clusters, hub ring dashed. Console empty.

Small tweak: the graph is positioned slightly right-of-center in the stage horizontally (stage spans ~24–1176 px; graph spans 240–950). It's because the fit used pre-tick positions and clusters moved. Acceptable — but I could improve the initial centering by continuing the simulation a bit and re-centering once at the first settle without moving camera... it would shift nodes. It's fine.

One more: I could tighten the initial "Zoom 100%" pill. Fine.

Everything verified: node drag with links following and camera fixed, pan, wheel zoom, reset, hover. Console clean.

Done. Report.