Force-directed graph · hy4

We need build index.html self-contained with local d3.min.js script tag. Need inspect cwd files, maybe d3 exists. Need use browser tools brief checks. Need design implementation robust and testable. Let's inspect.

Need create index.html. Need figure D3 version maybe v? Could inspect head.

We'll implement SVG responsive, camera transform group, force simulation. Need initial graph within view, initial camera framing without replacing graph data. We need think carefully about initial framing semantics. Could center simulation coordinates around SVG center and use fixed camera identity; reset restores identity and perhaps fit graph zoom? Requirement "Restore the initial camera framing". Could pre-tick simulation, calculate bounding box, fit transform, store it, reset to that. Need also preserve node positions / graph data. Initial graph fully within view. Also zoom/pan behaviors. Need use d3.zoom on SVG and drag nodes. Need distinguish background drag; drag on nodes should not trigger zoom pan (d3 drag and zoom filter). Need likely attach zoom to SVG with filter that ignores events originating on nodes or if defaultPrevented? d3.drag normally stops propagation? Need robust.

Need labels IDs. Four clusters color-coded with ring links and inter-cluster ring. 40 nodes, 40 intra ring links (each cluster 10) plus 4 inter links. Node IDs exactly 0-39. Need hover highlight node + neighbors + connecting links, dim unrelated. Need interpret connecting links: links from hovered node to its neighbors, likely highlight those; maybe also links between neighbors? Standard "focus" highlights adjacent links; requirement "it, its directly connected neighbors, and their connecting links" likely links connecting hovered node and neighbors. Could highlight direct links. Maybe a common implementation highlights node, neighbors, links where source or target hovered. Dim unrelated. Need visually obvious. Maybe use CSS classes and opacity changes. Could also animate stroke widths. Need avoid conflict with dragging.

Need force simulation with d3.forceLink etc. Need keep graph in viewport initially. Need use simulation coords around center. Could have forceCenter width/2 height/2 and forceManyBody, link distance, collide, cluster forces perhaps. Need make clusters visually separated and ring shapes. Use forceX/forceY cluster centers at quadrants; forceLink ring edges short; forceCollide. Perhaps custom radial cluster layout. Need initial deterministic positions perhaps assign nodes around ring cluster centers so pre-ticked simulation nicely laid out. Need fit camera based on bounding box after simulation settle. We can pre-run simulation e.g. 250 ticks synchronously then stop, fit to view using d3.zoomIdentity translate/scale. Then simulation alpha maybe restart? Requirement "use force simulation to position nodes and draw their links." We can run simulation to settle pre-display. Then keep simulation running with low alpha or on drag. Could call simulation.tick(300) without starting, then set alpha? Actually simulation.tick() doesn't dispatch tick events, so need manually render. After pre-tick, set alpha(0.3).restart() maybe simulation continues. But initial positions would move slightly; initial camera framing capture after initial tick. It's okay if graph stays within view with margin due to fit. Need preserve initial camera transform. Better pre-tick 400, fit based on node positions, set simulation.alpha(0).stop()? Then on drag call alphaTarget(0.3).restart(), rendering through tick. Hover no need simulation. This is a force simulation used to compute layout; acceptable. But requirement "release lets simulation settle" implies drag needs restart and alpha decay. We can do that.

Need "Reset view to restore the initial camera framing without replacing graph data" - define initialTransform from fit; zoom.transform transition maybe. It should not reset node data or positions (unless after drag? wording specifically initial camera framing, not graph layout). Reset only camera. Good.

Need maybe optional "fit graph" reset. But initial framing should be stored from geometry, preserving after resize? Need responsive handling. Maybe fixed width/height from viewport and camera transform calculated on load. On resize, need recalc? Could use SVG viewBox with fixed 1200x800 coordinate system and responsive preserveAspectRatio. Then browser viewport coordinates via SVG CTM? d3.zoom pointer uses SVG coords if attached to svg? d3.pointer(event, svg.node()) gives screen-to-svg. If SVG has viewBox and CSS width 100%, d3.zoom works respecting CTM. We can set viewBox `0 0 1200 800`, full viewport. Use fixed width=1200, height=800 internal. Browser runner viewport likely 1200x800. Could use `svg.attr("viewBox", [0,0,W,H])` and preserveAspectRatio xMidYMid meet. In screenshot likely matching. Need maybe handle dimensions via clientWidth? Better use dynamic W,H from window.innerWidth/innerHeight, no viewBox perhaps; but reset framing can be recalculated at resize. For simple consistent camera and test, fixed viewBox 1200x800 is fine and CSS width/height 100%; internal coords scale to viewport.

Need consider browser tool click and drag coordinates: likely based on 1200x800 viewport. Our SVG may have a top toolbar overlay. Need graph centered perhaps around 600x440. Need nodes coordinates predictable for drag test. Could expose maybe JavaScript globals for automated checks? Not required but useful. We can add specific data attributes and maybe window debug object. Browser tool can inspect DOM and console. We can implement and test with DOM eval? Browser tool "inspect" maybe returns DOM snapshot; click/drag can interact. Need see capabilities. Maybe tool describe? It has actions only. We can use browser inspect to get DOM maybe console. Could possibly use browser key/type etc. No arbitrary JS eval tool here. But maybe browser inspect returns selected DOM data and console. Could use console.log from app to report state. Need can calculate transform from DOM attributes via inspect. We can add on-screen status / info to help checks, perhaps debug HUD showing camera transform, dragged node coordinates, hover focus. But visual styling choice. Could include small status panel with `camera: x,y,k` and maybe drag/hover state, which helps verify via screenshots / inspect. Need not overcomplicate.

Need perhaps use browser tool to test drag, pan, zoom, reset. Browser actions available: drag x,y -> toX,toY; scroll; click; key; etc. Need likely use coordinates of node; perhaps inspect screenshot to know. We can assign deterministic initial positions and fit transform such that node positions known. Could display node coordinates in a status panel maybe. Need drag one node and check connected links follow while camera stays in place. We can define nodes near center and know one node screen coordinate. Need perhaps add test hooks via DOM attributes: each node in `<g class="node">` with transform translate(x,y), data-id, data-x/y; links with x1 etc. Camera group transform. Browser inspect might show DOM details. We can use screenshots before/after and motion frames. Need use browser tool call with actions. There may be no general JS eval but perhaps `browser inspect` gives full DOM/console. Let's first build.

Let's plan code:

<!DOCTYPE html>
<html lang=en>
<head>
<meta charset=utf-8>...
<style>
:root ...
html, body { margin:0; width:100%; height:100%; overflow:hidden; background:#0b1020; font-family... }
#app { position:relative; width:100vw; height:100vh; }
svg { width:100%; height:100%; display:block; cursor:grab; touch-action:none; }
svg:active { cursor:grabbing; }
.controls { position:absolute; top:16px; left:16px; ... pointer? }
button reset...
.legend...
.status...
.links line { stroke:#7f8da8; stroke-opacity:0.55; stroke-width:1.5; transition: opacity .16s...; vector-effect: non-scaling-stroke maybe. }
.node circle { stroke:#fff; stroke-opacity:.75; stroke-width:1.5; cursor:pointer; transition:...; }
.node text { fill:#f8fbff; font-size:10px; font-weight:700; text-anchor:middle; dominant-baseline:middle; pointer-events:none; paint-order:stroke; stroke:rgba(...); stroke-width:2px; }
maybe node group transform set.
.node.focus circle { stroke:#fff; stroke-width:3; filter? }
.node.neighbor circle etc.
.dimmed classes on svg / groups. Could set inline opacity; easier to apply class to groups: `svg.classList.add("has-focus")`, then `.has-focus .node:not(.is-focused)` etc but CSS `:not(.is-focused)` where class "focus" maybe. Use classes:
svg.is-focused .node { opacity:0.16; }
svg.is-focused .node.is-active { opacity:1; }
svg.is-focused .link { opacity:0.08; }
svg.is-focused .link.is-active { opacity:1; stroke:#f8fbff; stroke-width:3; }
`.node.is-hovered circle { ... }`
`.node.is-neighbor circle ...`.
Need both focused and neighbor classes; define active applied to hovered and neighbors, CSS. Could label dim too. Need hover highlight cluster? Colors remain.

Could use CSS variable styles. Need ensure pointer events on node group; circles and maybe text. Add drag to node group. Labels pointer-events:none so circle captures. Maybe use invisible larger hit circle? Add circle r=16 fill=transparent? A visible node radius 10-12. Drag handler on group with event handlers. Use `d3.drag().container(...)` maybe coordinate conversion.

Camera structure:
const svg = d3.select("#graph");
const g = svg.append("g").attr("class","camera");
const linkLayer = g.append("g").attr("class","links");
const nodeLayer = g.append("g").attr("class","nodes");
const zoom = d3.zoom().scaleExtent([0.25,4]).filter(event => {
   // Prevent zoom from origin node drag and only left button / wheel
   if (event.type === "wheel") return !event.ctrlKey? true; // all wheel
   if (event.button !== 0 && event.type !== "wheel") return false;
   // If event target is within .node, skip; d3 drag handles it.
   return !event.target.closest(".node");
}).on("zoom", (event) => {
   g.attr("transform", event.transform);
   updateCameraReadout(event.transform);
});
svg.call(zoom).on("dblclick.zoom", null);
Maybe `event.target.closest` works for SVG elements in modern browsers yes. For wheel over node should zoom still; task says mouse wheel zooms. If filter rejects target .node for wheel, then wheel over node won't zoom. Need allow wheel over any target. Better:
if (event.type === "wheel") return true;
if (event.button) return false;
return !event.target.closest(".node");
But d3.drag on node may stop propagation, so okay. For mousedown on node, zoom filter rejects. On background, zoom handles pan. Need avoid zoom on controls which are HTML siblings not inside svg.
Need set `svg.call(zoom).on("dblclick.zoom", null)` perhaps optional.

Drag:
const drag = d3.drag()
 .subject((event,d)=>d) maybe.
 .on("start", (event,d) => {
   if(!event.active) sim.alphaTarget(0.3).restart();
   d.fx=d.x; d.fy=d.y;
   d3.select(this)... maybe event.sourceEvent.stopPropagation();
 })
 .on("drag", (event,d) => {
   // event.x/event.y are in coordinate system of container; by default parent node = nodeLayer. But camera group has transform; d3.drag uses d3.pointer(event, container) where container is this.parentNode by default = nodeLayer, and d3.pointer calculates coordinates in local coordinates of that SVG element accounting CTM including camera transforms. Good. However d3.drag's subject default x,y maybe. Need set `.container(() => nodeLayer.node())` or `g.node()`? The nodes' parent is nodeLayer; d3.pointer on nodeLayer should map screen to camera-transformed coords. So event.x/y are simulation coords. Fine.
   d.fx=event.x; d.fy=event.y; 
   // update DOM immediately perhaps simulation tick will happen via timer; drag event is fast. We can call render() directly to ensure links follow. But simulation tick also calls render.
 })
 .on("end", (event,d) => {
   if(!event.active) sim.alphaTarget(0);
   d.fx=null; d.fy=null;
 });
Need maybe hold dragged node pinned during drag and fixed coords. Could set fx/fy on start, update on drag, release on end. Good.
Need stop propagation on mousedown: d3.drag automatically calls `event.stopImmediatePropagation()`? D3-drag source uses `nopropagation(event)` on mousedown start, yes likely. But zoom filter also rejects target .node. Good.

Rendering:
let link = linkLayer.selectAll("line").data(links).join("line")...
let node = nodeLayer.selectAll("g.node").data(nodes)... append circle radius maybe 12 fill cluster color, append text etc.
function render() {
 link.attr("x1",d=>d.source.x)...;
 node.attr("transform",d=>`translate(${d.x},${d.y})`).attr("data-x",d=>d.x.toFixed(2))...;
}
Need links data object source/target resolved by d3.forceLink from numeric IDs to node objects. Build with `links.push({source:i,target:j,kind:"intra"/"bridge"})`; forceLink(links).id(d=>d.id).distance etc. After simulation init, source/target become object. Good. Need identify neighbors map from raw ids before forceLink mutates; create map from link definitions with `source` as numbers. Could create after mutation via typeof. Need robust neighbor map:
const neighbors = new Map(nodes.map(n=>[n.id,new Set()]));
rawLinks.forEach(l => { neighbors.get(l.source).add(l.target); neighbors.get(l.target).add(l.source);}); Use a separate `edgeSpecs` unchanged, and `links = edgeSpecs.map(...)` with source numeric passed to forceLink. Actually forceLink will mutate `links` objects; edgeSpecs remain maybe distinct if map copies. Do:
const edgeSpecs = [];
...
const links = edgeSpecs.map(d=>({...d}));
const linkForce = d3.forceLink(links).id(d=>d.id)...
const neighbors = new Map...
edgeSpecs.forEach...
Need set classes kind. Link highlight predicate:
function isConnectedToHover(l, id) { const s = l.source.id ?? l.source; const t = ...; return s===id || t===id; }
"their connecting links" maybe highlight links from hovered node to neighbors only, not all links among unrelated nodes. Could also highlight links between the highlighted neighbor set (including hovered) to emphasize local subgraph; but that might include ring edges between neighboring nodes around hovered node; reasonable. Yet typical requirement expects connected links. Could highlight `s===id || t===id`, sufficient. Need maybe line stroke color dependent on bridge dashed? Inter-cluster bridges maybe distinct. Could style `.link.bridge { stroke:#d5b36a; stroke-width:2.3; stroke-dasharray:6 3; }` but background maybe. Colors of nodes clusters. Need color-coded clusters: four distinct colors, legend.

For hover:
node.on("mouseenter", (event,d)=>setFocus(d.id))
 .on("mouseleave", ()=>clearFocus());
Maybe focus remains while dragging? fine. Need on mouseenter when pointer enters group circle; text pointer-events none. Need maybe handle focusable via keyboard? Not required, but can add `tabindex=0` and focus/blur maybe. But D3 drag may need touch. Not necessary. Could add aria labels.

setFocus(id):
svg.classed("is-focused",true);
node.classed("is-active", n=>n.id===id || neighbors.get(id).has(n.id))
 .classed("is-hovered", n=>n.id===id)
 .classed("is-neighbor", n=>neighbors.get(id).has(n.id));
link.classed("is-active", l => (l.source.id===id || l.target.id===id))
 maybe `.classed("is-muted",...)` not needed since global class handles dim.
update status readout `focus: node 3 · 2/4 neighbors`
clearFocus: svg.classed false; classes false; status...
Need ensure opacity from CSS on node group doesn't affect event handlers? If dimmed node still pointer events but can hover; okay. Unrelated nodes dim but still interactive. Need perhaps set pointer-events none on dimmed nodes to prevent weird transitions? no.
Could update link stroke color on active differently; CSS `.is-focused .link.is-active { stroke: #fff; stroke-opacity:1; stroke-width:3; }`; if dash array bridge still visible. Need perhaps use `stroke-width` vector-effect non-scaling-stroke so zoom doesn't thicken; no issue.

Camera framing:
- After simulation pre-tick, compute bounds from node positions including radius/labels (maybe bounding):
const padding=90;
const minX = d3.min(nodes,d=>d.x)-50; maxX...
const graphW = maxX-minX; graphH...
const k = Math.min((W-2*padding)/graphW, (H-2*padding-topbar?)/graphH, 1.2?) Maybe initial should fit; if graph is small, zoom >1 might be nice. Need "keep initial graph within view". Use k = Math.min((W - 2*margin)/graphW, (H - 2*margin)/graphH, 1.15); perhaps no lower bound; graph could be around 700x500, k around 1.2. Need account top-left controls overlay; use margin 100. 
tx = W/2 - k*(minX+maxX)/2;
ty = H/2 - k*(minY+maxY)/2;
initialTransform = d3.zoomIdentity.translate(tx,ty).scale(k);
svg.call(zoom.transform, initialTransform); // fires zoom event and sets g transform.
Need store transform. But initial fit computed from simulation coords that may be centered around W/2,H/2. If forceCenter center W/2,H/2 and cluster forces around W/2±130, H/2±110, graph spread maybe 450x400. k maybe min(1000/450=2.2, 600/400=1.5, 1.15)=1.15. That fills 520x460. Good.
Could instead set `k = Math.min(..., 1.25)` maybe ensure no >1.25. Need preserve graph within view after slight simulation movement. We set simulation.alpha(0).stop() after pre-ticks. Drag restarts and can move nodes around; reset view camera only, node positions may be outside initial viewport if dragged far. But requirement "Reset view and confirm graph returns to its initial framing." They likely will drag node modestly, pan/zoom, reset; graph should mostly return to initial framing but node may have moved. The camera returns to initial transform; nodes might still be moved due to force simulation, possibly slightly changed. Could preserve exact graph positions on drag release? Requirement says release lets simulation settle, so positions can change. But for test, maybe check camera transform resets. We could add initial node positions and on Reset maybe camera only (explicitly without replacing graph data). We shouldn't reset positions. Fine.

Need maybe define initial camera as fit after simulation settle. Could expose `window.__graphDebug` with nodes positions, initialTransform, currentTransform, etc. Browser inspect might not show directly, but console.log can. Maybe add status panel readout camera values. That makes visual verification easier. E.g. bottom-left `.hud`: `Camera k=1.15 x=... y=...`; maybe show "Camera x / y / zoom" and "Drag node ...". Required control only Reset view; status allowed. Keep unobtrusive. Could also show cluster legend. Need ensure no external network. All CSS JS inline, local script src="d3.min.js". Good.

Need maybe use `window.addEventListener("resize", ...)`? With fixed viewBox no need. If want reset responsive, could set W=svg.node().clientWidth/H, but viewBox dynamic should preserve. Let's define fixed `const W=1200,H=800;` and `viewBox`. Fullscreen app. On browser viewport 1200x800 exact. If runner has different viewport (e.g., 1440x900), preserveAspectRatio fits, and d3.zoom pointer uses viewBox coordinates correctly? Need check d3.pointer with SVG and viewBox: it uses `getScreenCTM()` inverse, so yes coordinates map to viewBox. For zoom behavior, `d3.zoom` uses d3.pointer to currentTarget SVG; getScreenCTM includes viewBox scale, so works. Need avoid width differences weirdness. Good.

Maybe browsers use `viewBox` and CSS width/height 100% with preserveAspectRatio. d3.zoom's extent default uses SVG clientWidth/clientHeight? Let's recall d3.zoom `defaultExtent(element)`: if element is SVG, returns [[0,0],[element.width.baseVal.value, element.height.baseVal.value]] if width/height attributes exist; else clientWidth/clientHeight. If we set `viewBox` but not width/height attrs, default extent might be client dims (CSS pixels) while pointer coords are viewBox coords. This mismatch affects translateExtent not critical; zoom uses pointer coords and extent maybe for wheel clamping? Could set explicit `width="1200" height="800"` attributes and CSS width/height 100%; then default extent uses those values, matching viewBox. Good. But CSS scaling means `width.baseVal.value` =1200. Do that. Need maybe `preserveAspectRatio="xMidYMid meet"`. The SVG drawing fills container with letterbox maybe if aspect ratio differs. d3.pointer maps correctly. Good.

Need handle wheel zoom on background and nodes. `zoom.filter` should be careful: d3.zoom default filter: `!event.ctrlKey && !event.button`. For wheel with ctrlKey (pinch) often zoom; if we return true for all wheel, ctrl wheel also works. Good. Need perhaps prevent page scroll on wheel; d3.zoom does. Also touch pan on nodes? not needed.

Need maybe show camera staying same on node drag. `zoom.transform` event only on pan/zoom; node drag filter rejects and no camera change. Good. Status camera readout will remain. Need check drag event coordinate mapping under camera transform. Let's reason D3 drag behavior: `d3.drag().container(function() { return this.parentNode; })`, where `this` is the element (g.node) and parent is nodeLayer. It calls `pointer(event, container)`, which maps to container's local coordinate system. The nodeLayer is inside camera group with transform. `getScreenCTM()` of nodeLayer includes camera transform, so inverse maps screen to simulation coordinates. Good. But when using `subject(d)` default: `subject = d == null ? {x: event.x, y: event.y} : d;` with event.x in container coordinates. We don't need custom subject maybe. In drag start, `dx = subject.x - p[0]`, etc. If we set d.fx = d.x and drag event.x from subject + movement, which should match node coords. To avoid jump, defaults fine. We can set `.subject((event,d)=>d)`. Need ensure d3.drag callbacks `this` context and arrow function not use this. Use normal function for mouseenter maybe. Need no `this` needed.

Need potential problem with d3.drag's event.sourceEvent pointer and zoom on svg: D3 drag calls `nopropagation(event)` at mousedown and `yesdrag(view, event.touches...)`? Let's inspect minified? In d3-drag source: mousedowned(event,d) checks filter, gets subject, container, pointer, then `nopropagation(event); ...` yes. So zoom won't see mousedown. Fine.

Need simulation initialization. Let's design deterministic initial positions. Four cluster centers:
const centers = [
  {x: W/2 - 170, y: H/2 - 120},
  {x: W/2 + 170, y: H/2 - 120},
  {x: W/2 - 170, y: H/2 + 120},
  {x: W/2 + 170, y: H/2 + 120}
];
colors: ["#4cc9f0","#f72585","#ffc857","#80ed99"] maybe on dark background. Need good contrast. Use ring starts at index `cluster*10`. Initial position centers + radius 65 * [cos(2π j/10 - π/2), sin...]. Need maybe bridge nodes 0,10,20,30 at top of each ring (`j=0`) so cross-cluster links between top nodes. But cluster ring connecting hubs maybe those at outer corners would be better. Could choose angle offset based on cluster to position hub near central cross. For each cluster, hub j=0 could be at angle:
cluster0 (top-left) hub to lower-right angle 45°,
cluster1 (top-right) hub lower-left 135°,
cluster2 (bottom-left) hub upper-right -45°,
cluster3 (bottom-right) hub upper-left -135°.
Set angle offset for cluster c: [Math.PI/4, 3*Math.PI/4, -Math.PI/4, -3*Math.PI/4], maybe using cos/sin. Then hub faces center, intercluster ring links cross around center. Ring other nodes positioned around cluster. Use formulas cos(angle + j*2π/10), sin(...). Need choose centers maybe W/2±210, H/2±145; ring radius 65; hubs toward center. Inter-hub links cross center ring, nice. Force layout may distort due to link distances; cluster force.

For force simulation:
const simulation = d3.forceSimulation(nodes)
 .force("link", d3.forceLink(links).id(d=>d.id).distance(d=> d.kind==="bridge"? 180: 42).strength(d=> d.kind==="bridge"?0.12:0.65))
 .force("charge", d3.forceManyBody().strength(d => ... maybe -90 or -120))
 .force("collide", d3.forceCollide(20).strength(1).iterations(2))
 .force("x", d3.forceX(d => centers[d.cluster].x).strength(0.08))
 .force("y", d3.forceY(d => centers[d.cluster].y).strength(0.08))
 .force("center", d3.forceCenter(W/2,H/2).strength? forceCenter has no strength parameter? v7 maybe `.strength`; but avoid.)
 .alphaDecay(0.035)
 .velocityDecay(0.4)
 .stop();
Then `for(let i=0;i<300;i++) simulation.tick();`
Need check forceCenter strength? In v7 `forceCenter(x,y)` has `.strength`. But we won't call. forceCenter could shift all nodes to center each tick; cluster forces keep positions. Fine.
Maybe use custom cluster force to pull each node to its ring position? Could make layout stable and aesthetically pleasing. But force simulation with link/charge/collide/cluster should produce nice clusters. We can use forceRadial around cluster centers to keep rings:
.force("radial", d3.forceRadial(d => d.ringIndex === 0? maybe 50:65, d=>centers[d.cluster].x, d=>centers[d.cluster].y).strength(0.08))
But d3.forceRadial has x,y accessors and radius; can produce rings. Combined with link edges might be nice. However hub nodes should be at central-facing directions; forceRadial doesn't preserve angles. Could use initial positions and x/y to cluster centers, not exact ring. Requirement only define connections, not visual ring. Fine.

Potential issue with `forceLink` distance for bridge 180 while centers distance 420 diagonal, so bridge links pull clusters inward significantly; with forceX 0.08 perhaps hubs move toward center and clusters distort. Could set bridge distance 300 and low strength 0.05. Need keep four clusters separated. Maybe centers ±190,±130; diagonal distance between top-left and top-right 380, vertical 260 etc. Inter-hub ring links connecting 0-10 (top width), 10-30 (right diagonal?), 30-20 (bottom), 20-0 (left). Actually the ring 0→10→20→30→0 forms a bow-tie/cross: top-left to top-right, top-right to bottom-left (diagonal), bottom-left to bottom-right, bottom-right to top-left (diagonal). Crossing links. Could choose inter-cluster links 0→10→30→20→0 to make rectangle perimeter rather than crossing. But requirement "connect nodes 0, 10, 20, and 30 in a ring" ambiguous ordering; likely ring between those IDs in sequence 0-10, 10-20, 20-30, 30-0. That's bow-tie. Need exact likely expected data. Use that. Could perhaps place clusters in diamond order so ring doesn't cross: cluster centers top, right, bottom, left. Then 0→10→20→30→0 forms perimeter diamond. That might be more intuitive! Four cluster colors, arranged around center compass positions:
cluster0 top (W/2,H/2-180)
cluster1 right (W/2+230,H/2)
cluster2 bottom (W/2,H/2+180)
cluster3 left (W/2-230,H/2)
Ring inter-hub edges around perimeter; hubs need face center? Actually inter-hub ring connects all hubs; if hubs are central-facing edges, they make an inner diamond near center; if outer-facing edges, they make outer diamond. Could arrange hub positions to make inter-cluster ring around central area. Better centers diamond and hub j=0 at angle toward next cluster? Let's think.

Could define cluster centers:
0: (W/2 - 190, H/2 - 130) NW
1: (W/2 + 190, H/2 - 130) NE
2: (W/2 + 190, H/2 + 130) SE
3: (W/2 - 190, H/2 + 130) SW
Then ring sequence 0→10 (top), 10→20 (right), 20→30 (bottom), 30→0 (left) if clusters arranged clockwise in that order! Wait cluster2 is SE, cluster3 SW; yes sequence 0 NW, 1 NE, 2 SE, 3 SW forms perimeter rectangle. Good. Use that. Earlier I had cluster2 bottom-left, cluster3 bottom-right based on quadrants row-major; instead use winding order. Need ring links connect 0->10, 10->20, 20->30, 30->0. Great. Set centers accordingly. Hub positions for each cluster should face adjacent hubs. Could set all hub j=0 at a fixed angle relative to cluster center toward center? For NW hub 0 needs connect to NE hub 10 (east) and SW hub 30 (south): place hub near SE corner of NW cluster. NE hub 10 needs connect NW (west) and SE (south): SW corner. SE hub 20 needs connect NE (north) and SW (west): NW corner. SW hub 30 needs connect SE (east) and NW (north): NE corner. These are all toward center, so hubs form inner rectangle; links run roughly along quadrants. Use angle offsets:
cluster0 NW: SE angle ~π/4
cluster1 NE: SW angle ~3π/4
cluster2 SE: NW angle ~5π/4 (or -3π/4)
cluster3 SW: NE angle ~-π/4 (or 7π/4).
Actually sequence ring around cluster centers. Set `angleOffset = [Math.PI/4, 3*Math.PI/4, 5*Math.PI/4, 7*Math.PI/4]`; hub j=0 at those angles. Other nodes around ring. Good.
Cluster centers maybe ±200,±130; ring radius 62; hubs around (W/2-156,H/2-86), (W/2+156,H/2-86), (W/2+156,H/2+86), (W/2-156,H/2+86). Bridge distances ~312 horizontally, 172 vertically, diagonal? Actually 10→20 vertical ~172, 20→30 horizontal 312, 30→0 vertical 172. Unequal but okay. Could set centers ±180,±180 so inner rectangle ±136, giving equal-ish horizontal/vertical 272. Use square diamond corners: centers NW (W/2-190,H/2-150), NE (W/2+190,H/2-150), SE (+190,+150), SW (-190,+150). Ring radius ~55 at 45° gives inner offsets ±39, so hub rectangle x ±151, y ±111. Bridge width 302, height 222. Fine. Fit will show nice layout.

Could use bridge distance 260, strength 0.06. Intra ring distance 45, strength 0.6. ForceManyBody -55. forceX/Y cluster centers strength 0.12. forceCollide radius 18. Need keep clusters from merging. Use maybe forceX/Y .strength(0.12), charge -70, link 45, bridge 260. Pre-tick 400 might converge. Need inspect screenshot.

Need maybe make cluster colors accessible and legend. Colors:
0 cyan `#38bdf8`
1 pink `#f472b6`
2 amber `#fbbf24`
3 green `#4ade80`
Dark background with grid perhaps purely CSS radial gradient. Node circle fill cluster color, stroke #0b1020 maybe, plus white outer ring on hover. Need labels black on bright circles maybe fill #08101d; with dark stroke? If node fill bright, dark text good. Use `.node text { fill:#08111f; stroke:none; font-size:10.5px; }`. For dimming, opacity group. Good.

Need draw background maybe `<rect class="zoom-surface" width=1200 height=800 fill="transparent">` as first child of svg to capture background events. But SVG itself captures events if pointer-events on blank areas? In SVG, the root `<svg>` element receives pointer events if no painted element? I think SVG root's background is not painted, but pointer events on the SVG viewport itself? Usually d3.zoom attaches to svg and works anywhere, but to be safe add a `<rect class="surface" ...>` appended directly to svg (before camera group) with `fill="transparent"` or `fill="url(#grid)"`. Need ensure no `pointer-events:none`. This rect is not inside camera, so panning works. If it's inside camera and zoom transform, background moves too but doesn't matter. Add underlay `svg.append("rect").attr("class","surface").attr("width", W).attr("height",H).attr("fill","transparent");`. However if transparent fill, pointer events do target it. Good. Need maybe draw a subtle grid via CSS or SVG pattern. Could add `<defs><pattern id=grid>...` and fill surface `url(#grid)`. Need no external. But if surface fill pattern, events target surface. Fine. Could define pattern with subtle lines. Need perhaps use CSS background on body instead and surface transparent. easier. A pattern gives depth. Need not overcomplicate.

Need consider zoom transform applied to camera group; surface remains fixed, so background panning fine. Need zoom transform on camera group only; wheel zoom centered on pointer correctly via d3.zoom's internal transform. d3.zoom doesn't know what we do with event.transform, but uses pointer to update pan/scale. Good.

Need initial fit transformation call:
let initialTransform;
function computeFraming() { ... }
function applyInitialFraming() {
  const bounds = ...
  const scale = Math.min(1.25, (W-2*margin)/width, (H-2*margin)/height);
  initialTransform = d3.zoomIdentity.translate(...).scale(scale);
  svg.call(zoom.transform, initialTransform);
}
Need maybe `scale` could be >1.25; cap 1.25. If graph is very large, scale <1. Need ensure no negative. Use Math.max(0.3, ...). Good.
Need maybe margin = 110; controls top-left and legend top-right; HUD bottom etc. Graph might occupy center and not overlap controls if margin 120. Good.
Could set initial transform captured after call. Need `currentTransform = initialTransform` via zoom event. Need custom status update in zoom handler. Maybe script event transform object from d3 has x,y,k; readout. Use `toFixed(2)`. Could include `dataset.camera` on svg for inspect: `svg.attr("data-camera", `${x},${y},${k}`)`. Nice! Then browser inspect can read. Also set `data-initial-camera`. Helps tests. Add node groups data-x/data-y updated; link line x1 etc. Need inspect likely shows DOM attributes. Great.

Need maybe add debug log of initial layout and transform. Could console.log on load:
console.log("Force graph ready:", {nodes:nodes.length, links:links.length, initialTransform:{x,y,k}});
Need no errors. Could also log camera updates only on end? Too noisy. Maybe `zoom.on("end", ...)` logs camera. But browser inspect console can show. Need avoid console spam from wheel. Could set a status panel instead. We can add `status` text with camera and interaction. Maybe `summary` shows "40 nodes · 44 links". Need enough.

Need define 40 nodes "inline". We can generate loop in JS inline; requirement likely means data defined inline not loaded externally. IDs 0-39 divided into clusters of ten. We can make explicit array via d3.range(40).map, that's inline. Might validate data by code. Fine. Could also make explicit nodes array literal? 40 lines perhaps, but loop is acceptable "Define 40 nodes inline". To be safe, create explicit array via Array.from({length:40},(_,id)=>...). This defines data inline. Cluster = Math.floor(id/10). Great.

Need maybe link ring:
for (let c=0;c<4;c++) {
 for (let j=0;j<10;j++) edgeSpecs.push({source:c*10+j,target:c*10+(j+1)%10,kind:"intra"});
}
const hubs=[0,10,20,30];
for(let i=0;i<hubs.length;i++) edgeSpecs.push({source:hubs[i],target:hubs[(i+1)%hubs.length],kind:"bridge"});
Total 44. Good.

Need maybe line link IDs to ease check: `.attr("data-link", d => `${source.id}-${target.id}`)`, but source/target not objects until after simulation initialized. We can set after forceLink. Need set `.attr("data-source", d=>d.source.id)` etc. Nice. Need browser inspect / screenshot. Need maybe represent lines as `<line>` with class, but force simulation updates x1 etc. Need could use direct line elements.

Need ensure hover highlight works with camera transform and dimming. Add CSS:
.link { stroke:#8ea0bd; stroke-opacity:.48; stroke-width:1.6; }
.link.bridge { stroke:#cbd5e1; stroke-opacity:.72; stroke-width:2.3; stroke-dasharray:6 4; }
.node circle { fill: ...; stroke:#dbeafe; stroke-opacity:.85; stroke-width:1.5; }
.node text { ... }
svg.has-focus .link { opacity:.08; }
svg.has-focus .link.is-active { opacity:1; stroke:#ffffff; stroke-opacity:1; stroke-width:3; filter:drop-shadow(0 0 5px rgba(...)); }
svg.has-focus .node { opacity:.15; }
svg.has-focus .node.is-active { opacity:1; }
svg.has-focus .node.is-hovered circle { stroke:#fff; stroke-width:3.5; filter:drop-shadow(...); }
svg.has-focus .node.is-neighbor circle { stroke:#fff; stroke-width:2.5; }
Need applying `filter: drop-shadow` on SVG circle may work. Could avoid to keep performance.

Need maybe related nodes include hub neighbors from bridge and two ring neighbors; 4 neighbors for hubs, 2 or 3 for others? For non-hub, 2 neighbors; for hub, 4 (two ring + two bridge). Need status show count. Need update class based on `neighborSet`. For links active direct links. Could also add a subtle halo circle behind nodes? Maybe create circle `.halo` r=18 fill none and show on focus. But simple stroke is enough. Need maybe highlight neighbor nodes even if dim opacity? active class set. Good.

Need maybe "directly connected neighbors, and their connecting links" could mean links among highlighted nodes, not just direct links. But direct links are connecting links. Could include all edges where both endpoints are in active set; this highlights ring edges between neighbors and hovered, plus bridge links. Let's parse: "Hovering a node highlights it, its directly connected neighbors, and their connecting links while dimming unrelated elements." Usually highlight node + neighbors + links connecting them. This often means all links that have hovered node as source or target. If highlighting links among neighbors (neighbor-neighbor) they are not directly connected to hovered node and not "their connecting links"; likely unnecessary. We'll highlight direct links only. Maybe add the active node set and links between active nodes? Could accidentally highlight 2 ring edges that connect neighbors to other non-neighbor nodes? Let's see: for a non-hub node j, neighbors j-1,j+1; edge j-1→j-2 would not both active; edge j+1→j+2 not both; no neighbor-neighbor ring edge (except cluster size 3). So same as direct links. For hub, neighbors include ring ±1 and two bridge hubs; edge between neighboring hubs? The hub ring has direct edges from hub to two other hubs, both active; no edge between ring neighbors and bridge hubs. So same. Fine. Use direct links.

Need maybe handle pointer hover with event `mouseenter`/`mouseleave` on group; D3 drag may capture. Fine.
Potential issue: zoom filter rejects any mousedown on `.node`, including node label; if event target is text with pointer-events:none it will be circle; okay.
Potential issue: zoom filter uses `event.target.closest`, but `event.target` might be SVG root or rect; closest exists on Element. Fine.
Potential issue: wheel zoom over node triggers zoom; `event.type==="wheel"` true. Good.
Potential issue: reset button click might bubble to background? It's HTML overlay outside svg, so no.
Potential issue: zoom transform call `svg.call(zoom.transform, initialTransform)` with d3.zoom attached to svg can trigger a zoom event and set currentTransform. Good. Need maybe ensure `zoom` internal state uses initial transform, so subsequent pan/wheel starts from it. yes.
Potential issue: `zoom.scaleExtent([0.3,3.5])`; initial k maybe 1.25, within. Good.
Potential issue: `d3.zoom().filter` must return true for touch events? event.button undefined; check:
if (event.type === "wheel") return true;
if (event.type === "mousedown" && event.button !== 0) return false;
if (event.ctrlKey && event.type !== "wheel") return false;
return !event.target.closest(".node");
For touchstart, event.button undefined, event.ctrlKey maybe false, target not node => true. But dragging node via touch? d3.drag also handles touch, zoom filter rejects node. Good.
Need maybe disable double-click zoom to avoid accidental transform? Could leave; not harmful. But dblclick on node might zoom if filter doesn't reject? event.type dblclick, button 0, target .node → false; background dblclick would zoom. Fine. Could disable to avoid confusion. Not required.

Need maybe add instructions overlay:
Controls: "Drag nodes · Drag background to pan · Scroll to zoom · Hover to focus". Nice.
Cluster legend with four swatches. Could position top-right. Need maybe initial graph not behind overlay. Use margin 120. Good.
Reset button at top-left. Could maybe set `id=reset-view`. Good for browser click. Need add `aria-label`.
Need maybe status HUD bottom-left with camera values. Too much UI? Fine.
Maybe display cluster labels near each cluster? Not required. Could add text labels in camera group? If graph moves, could clutter. Legend enough.

Need maybe calculations / transform dataset:
function formatTransform(t) { return `${t.x.toFixed(2)},${t.y.toFixed(2)},${t.k.toFixed(3)}`; }
function updateCamera(t) {
 currentTransform=t;
 svg.attr("data-camera", formatTransform(t));
 d3.select("#camera-readout").text(`x ${t.x.toFixed(0)} · y ${t.y.toFixed(0)} · zoom ${t.k.toFixed(2)}×`);
}
Need no external assets.
Maybe add `window.graphState = {nodes, links, simulation, zoom, svg, getCamera:()=>currentTransform, initialTransform:()=>initialTransform, resetView}`; This is a debug hook that can help but perhaps not needed. Could expose to satisfy automated tests? Might be beneficial. Need avoid polluting? Fine. Use `window.graphApp = Object.freeze({nodes, links, simulation, zoom, get transform(){return currentTransform;}, get initialTransform(){return initialTransform;}, resetView, focusNode, clearFocus});` but `Object.freeze` with getter okay. But no need. Browser inspect might not run JS. Could add data attributes.

Need perhaps `Reset view` restore initial camera with transition:
function resetView() {
 svg.transition().duration(450).ease(d3.easeCubicOut).call(zoom.transform, initialTransform);
}
This calls zoom event multiple times, updates readout. On click might need verify after animation; browser tool perhaps immediately screenshot/inspect, could see intermediate. Better use immediate transform no transition for test reliability. Or transition 250ms and browser tool can wait? Better immediate. Requirement no animation needed. Use `svg.call(zoom.transform, initialTransform);` exactly. Add visual feedback button class maybe. Simpler and robust. Could add `button.blur()`. Need not replace data. Good.

Need perhaps initial camera frame after resize? Since fixed viewBox, initial transform still fine. Good.

Need potential use of `d3.forceCenter` with pre-ticking and stop. Let's tune to avoid simulation drift after initial drag. On drag start `simulation.alphaTarget(0.25).restart();` and on end `alphaTarget(0);` simulation will continue until alphaMin (0.001) with decay 0.035 ~ 150 ticks. All nodes may rearrange slightly but stay near cluster centers. Camera unchanged. Fine. Need maybe on drag release node returns near its cluster due to forces, but connected links follow. Great.
Need maybe when dragging node, `d.fx=event.x`, `d.fy=event.y`, and render() on each drag. Since simulation timer may be running, but direct render ensures line endpoints for dragged node and maybe other nodes. Need update coordinates maybe call `updatePositions()`.
Need when simulation tick, render.
Need when drag end `d.fx=null; d.fy=null;` then simulation settles. Could set `d.fx=null` release; yes.
Need maybe preserve node's dragged position at release? Forces will pull it but that's intended.
Need maybe if drag start on node while simulation is stopped with alpha=0, `if (!event.active) simulation.alphaTarget(0.3).restart();` Need d3.forceSimulation.restart() restarts timer but alpha remains 0? If alphaTarget set to 0.3, does alpha increase? In d3-force, simulation alpha doesn't immediately increase just because target changed? Actually `alphaTarget` sets target, restart just restarts timer; on tick alpha += (alphaTarget - alpha)*alphaDecay, so from 0 to ~0.01 first tick, slowly toward 0.3. That works but slow maybe. Better on drag start explicitly `simulation.alpha(Math.max(simulation.alpha(),0.35)).alphaTarget(0.3).restart();` Then responds. On end `.alphaTarget(0);`. Good. Need perhaps add `.alphaDecay(0.035)`.
Could set `.alpha(0)` after pre-tick? The `tick(400)` doesn't change alpha; initial alpha=1, I think `simulation.tick(iterations)` manually advances but doesn't change alpha? Let's check d3-force source: `tick(iterations) { for (...) { alpha += (alphaTarget - alpha) * alphaDecay; forces.each(...); ... } return simulation; }`. Actually yes it updates alpha each tick if iterations given. After 400 ticks alpha decays to near 0. Need then `.alpha(0).stop()` to be explicit. But force simulation initialized with timer running by default; call `.stop()` immediately, then `.tick(400)` while stopped. Need order:
const simulation = d3.forceSimulation(nodes)
 .force(...)
 .alphaDecay(...)
 .velocityDecay(...)
 .stop();
for(let i=0;i<400;i++) simulation.tick();
simulation.alpha(0).alphaTarget(0);
This decays alpha. Great.
Need maybe forceCenter on simulation calls initialize and shifts nodes; okay.

Need maybe use `forceLink` pre-tick with fixed link distances and strength. Let's maybe plot positions with node.js using d3 library? Could run headless Node? d3.min.js is UMD, can require maybe. We can use browser screenshot anyway. Let's create first version then inspect.

Need build full index.html. Let's write with carefully formatted code. Need no external resources. Need maybe inline CSS uses system fonts only. `@media` for small viewport controls. Could include simple.

Let's draft.

HTML:
<body>
<div id="app">
 <svg id="graph" width="1200" height="800" viewBox="0 0 1200 800" preserveAspectRatio="xMidYMid meet" role="img" aria-label=...>
  <defs> pattern...
 </defs>
</svg>
 <div class="toolbar" aria-label...>
   <button id="reset-view" type="button">↺ Reset view</button>
   <div class="hint">Drag nodes ...</div>
 </div>
 <div class="legend" ...>
 ...
 </div>
 <div class="hud">
  <div><strong>40 nodes</strong> · <strong>44 links</strong></div>
  <div id="camera-readout">Camera ...</div>
  <div id="focus-readout">Hover a node to focus its neighborhood</div>
 </div>
</div>
<script src="d3.min.js"></script>
<script>
(() => {
 'use strict';
 const W=1200,H=800;
 const colors = [...]
 const clusterNames = ["Cluster 0", ...];
 const svg = d3.select("#graph");
 // surface should be added before camera group? Since svg currently contains defs only. Append rect then g.
 svg.append("rect").attr("class","surface")...
 const camera = svg.append("g").attr("class","camera");
 const linkLayer = camera.append("g").attr("class","links");
 const nodeLayer = camera.append("g").attr("class","nodes");
 // maybe subtle crosshair? not needed
 // data
 const centers = [...]
 const hubAngles = [...]
 const nodes = Array.from({length:40}, (_,id)=> { ... });
 const edgeSpecs = [];
 ...
 const links=edgeSpecs.map(e=>({...e}));
 const neighborsById = new Map(nodes.map(n=>[n.id,new Set()]));
 edgeSpecs.forEach(e=>{...});
 const linkForce = d3.forceLink(links).id(d=>d.id)...
 const simulation = ...
 for (let i=0;i<360;i++) simulation.tick();
 simulation.alpha(0).alphaTarget(0);
 // selections
 const link = linkLayer.selectAll("line").data(links).join("line")
  .attr("class",d=>`link ${d.kind}`)
  .attr("data-source",d=>d.source.id)
  .attr("data-target",d=>d.target.id)
  .attr("data-link",d=>`${d.source.id}-${d.target.id}`)
...
 const node = nodeLayer.selectAll("g").data(nodes).join("g")
  .attr("class", "node")
  .attr("data-id",d=>d.id)
  .attr("data-cluster",d=>d.cluster)
  .attr("tabindex",0)
  .attr("role","button")
  .attr("aria-label",d=>`Node ${d.id}, ${clusterNames[d.cluster]}`)
  .call(drag)
  .on("mouseenter", ...)
 ...
 node.append("circle") ...
 node.append("text")...
But order: if we call drag before circles appended, drag handlers on empty g still okay; but pointer events only have child circles. Better append children first then call drag. Need append first.
 const node = ...join("g");
 node.append("circle")...
 node.append("text")...
 node.call(drag).on(...).
Need set `node` selection contains g with children. Good.
Need maybe circle r based hub? Could make hub nodes slightly larger perhaps (r=13 vs 11). But IDs 0,10,20,30 are bridges; maybe highlight with extra stroke. Not required but nice. Use `r = d.id%10===0?13:11`; text center. Need maybe radius field for bounding. Use `d.r`.
Need perhaps node circle fill via `.attr("fill",d=>colors[d.cluster])`.
Need maybe add title element for accessibility: node.append("title").text(...). Could then tooltips. Fine.
Need link title? no.

Need define `render` before simulation tick? If simulation.on("tick", render), and then sim.tick(360) while stopped, on tick event doesn't fire (manual ticks don't dispatch events), so need call render after. We can define selections before simulation initialization maybe. Let's order:
1 data/edge specs/neighbors.
2 selections (links resolved? forceLink not initialized yet; `d.source` is numeric; need attr data-source from edgeSpecs maybe. Could use raw numeric values from `links` before initialization, but later they'll become objects. We can set data attributes using `edgeSpecs` via index? Better after simulation forceLink init. Need create link force first, then selection. Could define simulation but not tick, then selections after forceLink has resolved source/target. In d3.forceSimulation(nodes).force("link", linkForce) calls initialize on force and resolves links immediately. Good.
3 simulation creation with `.stop()` after forces.
4 selections; then pre-tick; render.
5 simulation.on("tick", render) maybe can set before pre-tick; manual ticks don't emit events. Fine.
6 fit camera.
Need ring force maybe custom:
.force("clusterX", d3.forceX(d=>centers[d.cluster].x).strength(0.11))
.force("clusterY", d3.forceY(d=>centers[d.cluster].y).strength(0.11))
.force("radial", d3.forceRadial(d=>d.id%10===0?62:66, d=>centers[d.cluster].x, d=>centers[d.cluster].y).strength(0.08)) Could use forceRadial to maintain ring shape; but forceLink edges can pull ring into a chain shape. Need maybe avoid forceRadial due to hubs need specific angles; with forceLink intra rings and charge, ring shape emerges. Could use `forceX/Y` to initial ring positions instead of cluster centers: `d3.forceX(d=>d.anchorX).strength(0.08)`, `d3.forceY(d=>d.anchorY).strength(0.08)`. This keeps initial ring arrangement (anchors), creating clean rings. That's a simulation but with positional anchors. Great! Store `anchorX`, `anchorY` from initial ring positions; use forceX/forceY anchor with strength 0.08. Link force adds edges; charge/collide avoid overlap. The layout will remain close to four rings, clear visual. Need maybe forceCenter too. We can set:
.force("x", d3.forceX(d=>d.anchorX).strength(0.055))
.force("y", d3.forceY(d=>d.anchorY).strength(0.055))
.force("charge", d3.forceManyBody().strength(-38))
.force("collide", d3.forceCollide(d=>d.r+6).strength(0.9).iterations(2))
.force("link", ... distance intra 45, bridge maybe 1? If anchors define positions, link force should be moderate to avoid distortion. Set distance d=>d.kind==="bridge"? 260:45, strength d=>d.kind==="bridge"?0.035:0.25. Then ring edges mostly stable. Need forceCenter maybe no need. This is still force-directed; forces position nodes, though anchor forces. Might be seen as less force-directed? We can still use forceLink, manyBody, collide, and forceX/Y. Fine.
Maybe no anchors, just cluster centers and forceRadial gives ring-ish. But to verify connected graph shape, rings might be chaotic. We can inspect and tune.

Let's consider requirement likely automated checking data, simulation presence, drag/zoom/hover/reset. A visually nice layout matters. Anchors are okay.

Need perhaps preserve exact initial positions after pre-tick. If link/charge forces distort, still fine.
Need maybe link distances for bridge based on anchor distance; compute from anchors per edge to set exact distance. Could define distance generic. But `d3.forceLink().distance(d => d.kind==="bridge" ? Math.hypot(target.anchorX-source.anchorX,...)*0.7 : 44)`. At initialization source/target are objects when distance called? forceLink initialize resolves then `initializeStrengthDistance()` calls distance per link, yes. We can use objects. But simpler numbers. Need avoid using `d.source.anchorX` if source numeric? At distance accessor call after resolve, likely object. Fine but could avoid by precomputed `desired` in edgeSpecs. Compute `distance` based on raw IDs and nodes array at creation, then store. For each edgeSpec, compute from anchor positions. Then forceLink distance(d=>d.kind==="bridge" ? d.distance * 0.75 : 44). Could add target. But unnecessary.
Need choose bridge link strength low to avoid hubs drifting.
Need maybe `forceManyBody` with distanceMax(200) to local repulsion. `.distanceMax(180)`. Good.
Need link force intra 0.35, bridge 0.05.
Need anchor force 0.12.
Need collision 18.
Need alpha decay etc.
Need maybe forceCenter(W/2,H/2) to ensure center. Anchors already centered. Could omit.

Let's choose:
const centers [
 {x: W/2 - 205, y: H/2 - 145}, NW (395,255)
 {x: W/2 + 205, y: H/2 - 145}, NE (805,255)
 {x: W/2 + 205, y: H/2 + 145}, SE (805,545)
 {x: W/2 - 205, y: H/2 + 145}, SW (395,545)
]
ring radius 66
hub angles [π/4, 3π/4, 5π/4, 7π/4]
Hub positions:
0: (441.7,301.7)
10: (758.3,301.7)
20: (758.3,498.3)
30: (441.7,498.3)
Great inner rectangle 316x196.6.
Other nodes around each ring radius 66. Graph extent from center x 395±66=329 to 871; y 255±66=189 to 611. So graph ~542x422. margins ~110 gives k min(980/542=1.81, 580/422=1.37, 1.25)=1.25. Graph screen 678x528, centered; from x=600±339=261..939, y=400±264=136..664. Controls top-left at 16.. maybe no overlap. Legend top-right perhaps x ~980..1184, no overlap. Good. Initial graph nicely fills center. Need include node radius/labels in bounds; add 26. Graph ~594x474; k min 980/594=1.65,580/474=1.22 ->1.22. Fine. Cap 1.25. Good.

Need maybe initial camera transform computed with bounds including r+20. Need define margin 100? With controls overlay top-left, graph from x~250, y~130, controls top-left ~16-300, y16-90; no overlap. Legend top-right ~950..1184,y16-100, no overlap with graph ending x~950 maybe slight. Use margin=120. k min((1200-240)/594=1.62,(800-240)/474=1.18,1.25)=1.18. Graph from x~249..951, y~120..680. HUD bottom-left y~740 so no overlap. Good.

Need perhaps zoom scale extent [0.35,3]. Nice.

Need dynamic status on hover:
focusReadout.textContent = `Node ${id} · ${neighborsById.get(id).size} neighbor${...} · ${activeLinks} link${...} highlighted`;
Need calculate active links via link.filter maybe. Could use links.filter. Fine.
Need clear focus at mouseleave. But when moving from circle to text (pointer-events:none), no issue. When moving from node to another, `mouseleave` clears then `mouseenter` sets again. Fine.
Need maybe focus on keyboard `focus` and `blur` for accessibility, but D3 `.on("focus", ...)` works. Need if dragging and focus etc. Could add.
Need maybe `mouseenter` doesn't bubble in D3? D3 on supports mouseenter. yes.

Need drag status:
on start: `svg.attr("data-dragging", d.id); focusReadout.textContent = \`Dragging node ${d.id}...\`; d3.select("#focus-readout")...`; But if focus due hover, might be overwritten. On end maybe clearFocus? Need not. Could update status via separate `interaction-readout`. Simpler use focus status only for hover, and add `data-dragging` attribute for inspect. Maybe `dragReadout` element? Could show "Drag: node 3" in HUD. Might be useful. Let's add a small line `#interaction-readout`, initially "Hover a node to focus its neighborhood". And separate `#focus-readout`? Too much. Could combine:
- `#state-readout` with hover/drag state.
- `#camera-readout`.
Need maybe hidden `data-dragging` on root.
During drag, set `state-readout = "Dragging node X · links follow in simulation space"`.
On end, if hovered focus still? Could set based on currentFocusId (we track). Good.
Need track `let focusedId=null;`.
setFocus(id) sets focusedId=id and classes; `state-readout`.
clearFocus sets null and resets state.
During drag start set draggingId=d.id and state text. During end set draggingId=null; if (focusedId!==null) update readout focus else idle. But if mouse leaves during drag, mouseleave might clear focus; release maybe idle. Fine.
Need maybe call setFocus on drag start to highlight dragged node neighborhood? Not required; hover likely already active. Could setFocus(d.id) automatically during drag to make links clear. But then "release lets simulation settle"; leaving node should restore. If setFocus persists after drag and pointer not on node, could leave highlight stuck. Need careful. Don't set programmatically.
Need maybe when drag starts, source node is under pointer so mouseenter likely already fired. Good.

Need camera readout update on zoom event. Need maybe `#camera-readout` with `text-content`.
Need maybe `svg.attr("data-initial-camera", ...)` after fit; `data-camera` updates. Need maybe `data-focus` and `data-dragging` on svg for inspect.
Need maybe `data-node-count=40 data-link-count=44`.
Need maybe show initial camera in button title? no.

Need maybe style tooltip legend etc. Need ensure controls don't cover graph coordinates we'll use for drag. We need choose a node near center or known location. Could perhaps node 0 hub at around x=442,y=302 in simulation coords; after fit k~1.18, tx = 600 -1.18*600 = -108, ty =400 -1.18*400=-72 (since center graph exactly 600,400). Screen x=442*1.18-108=413.6; y=302*1.18-72=284.4. Could drag from (414,284). Need node circle radius ~13*1.18=15px. Great. But simulation forces may move it. Could expose node screen positions via data attributes? `data-x`, `data-y` simulation coords. Need map with transform from root data-camera. Can calculate manually. Could maybe set `data-screen-x/y` on node groups from d.x*k+t.x each render. Then browser inspect can show exact coordinate to drag. That's useful! Add function `render()` updates `data-screen-x` and `data-screen-y` using currentTransform. But camera can change; render only on simulation tick, not on zoom events. Need update on zoom too. Could define `updateScreenCoordinates()` called from render and zoom. Then data-screen attributes reflect current screen/viewBox coordinates. Add `data-x`, `data-y`, `data-screen-x`,`data-screen-y`. This helps automated test / our browser tool. Need no visible effect. Fine.
When camera transform changes via zoom, call `updateScreenCoordinates()`; nodes remain same simulation coords. Need currentTransform defined maybe d3.zoomIdentity before initial fit. define `let currentTransform=d3.zoomIdentity; let initialTransform=d3.zoomIdentity;`.
`function updateScreenCoordinates(){ node.attr("data-screen-x", d => (currentTransform.applyX(d.x)).toFixed(1)) ... }` D3 zoom transform has `.applyX`. Good. Need call `render()` after initial transform? render updates positions and screen coords using currentTransform. During zoom event, call updateScreenCoordinates. Need avoid before `node` selection initialized; set after.
Need maybe link endpoints data not needed, but can set data endpoint positions. Fine.
Need maybe order:
- Define `let currentTransform = d3.zoomIdentity; let initialTransform = ...`.
- create selections and render.
- define zoom behavior with handler that sets currentTransform and calls `camera.attr("transform", ...)`, updateCameraReadout, updateScreenCoordinates. But `node` selection already defined. Good.
- fit initial. Need simulation pre-tick before fit. Need zoom behavior before `svg.call(zoom.transform, initialTransform)`.
Need define drag behavior before node call. It uses simulation and render; okay. Need currentTransform maybe.

Let's organize script:
(() => {
 constants, selections, data, neighbors, simulation, selections, render, interactions, zoom, fit, reset, expose.
})();
Need ensure `drag` defined before node call; `render` defined before drag; `node` is const declared before drag? drag references node only maybe for class? Could set class via d3.select(event.sourceEvent.target.closest(".node"))? simpler avoid. Need `render` references `node` selection. Define `render` after `node`. Need drag references `render`, simulation. Can define drag after render. Then call `node.call(drag)`. Good.

Pseudo:
const data...
const link = ...
const node = ...
function render() {...}
const drag = d3.drag()...
node.call(drag).on("mouseenter",...).on(...);
function setFocus... etc. But drag handlers call `setInteraction` maybe defined later; function declarations hoisted. Fine.

Potential problem: drag handlers call `render()` which uses `currentTransform` declared later? `let currentTransform = d3.zoomIdentity;` should be declared before render to avoid temporal dead zone at call time (not at definition). We'll declare near top before render.

Need zoom behavior after setFocus maybe.
Need fit camera after zoom behavior. Need pre-tick simulation before fit. We can pre-tick before selections or after. Let's sequence:
- data and simulation setup with `.stop()`.
- pre-tick 320.
- set alpha 0.
- build selections (source/target resolved).
- `let currentTransform...` earlier.
- render function, render() call.
- set up interactions and zoom.
- fit and apply transform.
Need simulation.on("tick", render) set after render defined, but before drag start. e.g. after function definition: `simulation.on("tick", render);`. Pre-tick already happened; no events.
Need fit uses current node positions. Good.

Need d3.forceLink distance accessor perhaps use anchor positions from nodes. Let's implement `edgeSpecs` with desired distance:
function anchorFor(id) { ... } can't call before nodes? build nodes first. edgeSpecs then compute:
edgeSpecs.push({source:a,target:b,kind:"intra"});
after loops:
edgeSpecs.forEach(e=>{
 const a = nodes[e.source], b=nodes[e.target];
 e.restLength = Math.hypot(a.anchorX-b.anchorX,a.anchorY-b.anchorY);
});
const links = edgeSpecs.map(e=>({...e}));
Then forceLink distance(d => d.kind==="bridge" ? d.restLength*0.9 : d.restLength*0.85); But if we set exact anchor distances, link force won't distort much. strength bridge 0.045, intra 0.35. Good. Need perhaps inter-links desired ~316 and 197 (unequal). If exact rest lengths, okay.
Anchor positions already form rings; forceX/Y to anchors keeps them. ForceManyBody pushes out, links pull in. Fine.
Need maybe `d3.forceRadial` not needed.
Need maybe force center to avoid drift: `.force("center", d3.forceCenter(W/2,H/2))` could shift all nodes to center but anchors already centered; no harm. Need note center force may continuously offset all to centroid; okay.
Need perhaps anchor force strength too strong making graph too static but still responds to drag via link force. Need maybe 0.06. Drag release node returns to anchor; connected links follow. Let's choose 0.08. ForceManyBody -45, link strength intra 0.32, bridge 0.06, collide 20. Pre-tick 280. Need check positions. We can use browser screenshot.

Could make simulation more "force-directed" with forceX/Y cluster centers instead of exact anchors; ring shapes emerge from link force and charge. But exact anchors might be considered pre-layout. Still force simulation with multiple forces positions nodes. Fine.

Need maybe `nodes` initial x,y set to anchors plus deterministic jitter? To show simulation, set x=anchorX+(id%5-2)*4, y=...; then simulation settles to near anchors. Good. Need initial ring clear. Force simulation positions from these. Could set deterministic jitter using trig; not random to ensure reproducible. E.g. `x: anchorX + Math.sin(id*2.1)*9`, `y: anchorY + Math.cos(id*1.7)*9`. Then force pre-tick. Good.
Need maybe `vx=0,vy=0` not needed.
Need `cluster`, `ringIndex`, `anchorX`, `anchorY`, `r`.
Need maybe `hubAngles` and node angle = hubAngles[c] + ringIndex*2π/10. For cluster2, hub angle 5π/4 (225°) which is NW? Wait coordinate system y positive downward. Need recalc based on screen y:
- NW cluster center (395,255); hub should be SE (down-right), angle +45° (cos+, sin+) yes π/4.
- NE center (805,255); hub should be SW (down-left), angle 135° (cos-, sin+) yes 3π/4.
- SE center (805,545); hub should be NW (up-left), angle 225° (cos-, sin-) yes 5π/4.
- SW center (395,545); hub should be NE (up-right), angle 315° (cos+, sin-) yes 7π/4.
Good. Ring links from hub j=0 to j=1 and j=9 continue around circle. Fine.

Need maybe cluster centers order uses id clusters 0 NW,1 NE,2 SE,3 SW. Legend accordingly.

Need perhaps transform scaling and viewBox issue with pointer coordinates. Let's confirm d3.zoom defaultExtent when width/height attrs set to 1200/800. It uses `element.width.baseVal.value` if `viewBox`? Let's recall d3-zoom/src/zoom.js defaultExtent:
function defaultExtent() {
  var e = this;
  if (e instanceof SVGElement) {
    e = e.ownerSVGElement || e;
    if (e.hasAttribute("viewBox")) {
      e = e.viewBox.baseVal;
      return [[e.x, e.y], [e.x + e.width, e.y + e.height]];
    }
    return [[0, 0], [e.width.baseVal.value, e.height.baseVal.value]];
  }
  return [[0,0],[e.clientWidth,e.clientHeight]];
}
Actually likely uses viewBox. Fine.

Need maybe on wheel with ctrlKey, d3.zoom may use different delta? fine.
Need maybe pan background with mouse drag; if starting on surface rect, filter true. Need ensure root `<svg>` zoom event listener receives mousedown from surface via bubbling; yes.
Need maybe if starting on a link line in camera group, filter target closest(".node") false → zoom handles pan. Good.
Need maybe if starting on text label (pointer-events:none) it passes to circle? maybe. Need node group itself no fill; pointer target circle. fine.
Need maybe if starting on node circle, filter false. d3.drag mousedown listener attached to g handles. yes.
Need maybe CSS `cursor: grab` on svg; node circle cursor grab. But if zoom active background grabbing. Need maybe `.node { cursor: grab; }`.
Need maybe during drag set `.is-dragging` class on node; not needed.
Need maybe halos / line highlighting use CSS with `opacity` but note link SVG line has `stroke-opacity` and group `opacity`; CSS `.has-focus .link { opacity: .08; }`, active `.link.is-active { opacity:1; stroke...}`. Good.

Need maybe bridge dashed style overridden by active stroke dasharray remains; okay.
Need maybe `vector-effect: non-scaling-stroke` on links/circles to prevent scaling stroke with zoom. Could be nice. But with camera transform zoom, line strokes should remain consistent. Add in CSS `vector-effect: non-scaling-stroke;` for line/circle. Circle radius will scale though. Fine.
Need labels with `font-size:11px` scale with zoom; okay.
Need maybe set `text-rendering: geometricPrecision`.
Need maybe `shape-rendering` etc. Fine.

Need maybe grid pattern:
svg.append("defs").append("pattern").attr("id","grid").attr("width",40)... etc. Add rect fill "url(#grid)" with opacity 0.45. Could style body radial gradient. Need no external.
Pattern:
<pattern id="grid" width="40" height="40" patternUnits="userSpaceOnUse"><path d="M 40 0 L 0 0 0 40" fill="none" stroke="#1c2945" stroke-width="1"/></pattern>
Then background rect fill url(#grid) opacity .6. Need with viewBox and zoom, surface fixed. Good.

Need maybe camera transform group includes a subtle center? no.

Need perhaps add cluster labels next to each cluster? Could help color-coded clusters. But legend enough. Could add text at cluster centers? That might overlap nodes. Not needed.

Need maybe `Reset view` button has accessible focus and hover styles. Good.

Need maybe with no external network, all inline. Script src local exact filename. Good.

Let's write file.

Need run browser and inspect initial output/console. Use `browser reload` maybe automatically loads index.html. Then inspect/screenshot.

Initial looks excellent. Need inspect DOM/console maybe need find node screen coords. Use browser inspect perhaps returns details? Need maybe use screenshot only. Need use browser tool perhaps `inspect` action with x/y? No parameters maybe generic DOM. Could use `browser inspect` and get DOM dump maybe attributes. Let's call.

Need test interactions. We can use drag at node 0 visible around (441,305) in screenshot. Need check if browser coords exactly viewport 1200x800; screenshot shown 1200x800. Use drag from (441,305) to (500,360) maybe. Need capture before/after camera readout and line endpoints. Browser tool drag likely does synthetic pointer events. Let's call.

Interesting after drag, screenshot shows node 0 moved to ~506,359, links follow, camera same. Hover focus active due perhaps mouse still over node after drag; dim unrelated, direct links highlighted. Good. But note status "Dragging node 0" changed to "Node 0 focused..." after drag end. Good. Need ensure node 0 maybe at (506,359) and camera same. Great.

Need perhaps check after release simulation settles and node returns maybe slightly. Use browser motion maybe captures frames. Let's call motion perhaps.

Hmm motion frames show graph returned to initial layout and node 0 has focus outline (keyboard focus) perhaps from drag. Wait these motion images show node 0 at original center (~442,315) with white rectangular outline around it (browser focus ring?) and all graph normal, not dim. But status says "Hover a node to focus its neighborhood" normal. Node 0 has a white rectangle around it—browser focus ring from tabindex=0 due drag focus? Actually maybe browser tool click/drag focused node g (tabindex=0), and default focus outline drawn around node group bounding box. That's ugly. Need remove default outline or style focus-visible on nodes. Also concerning: after drag, graph settled and node returned to anchor exactly. That's okay. But our earlier drag screenshot showed moved node 0 at (506,359), likely during drag, and camera unchanged. Need test release via motion. Good.

Need handle focus outline: CSS `.node:focus { outline: none; } .node:focus-visible circle { stroke:#fff; stroke-width:3; }` perhaps. But keyboard focus should show focus ring via circle. Need avoid CSS outline on SVG g. Add `.node:focus { outline:none; }` and `.node:focus-visible circle { stroke:#fff; stroke-width:3; }`. However browser tool may mark focus-visible false for pointer drag? The white rectangle might be default outline from `g[tabindex]` focus. Add. Need also maybe pointer drag focuses SVG group automatically; then `focus` event calls setFocus, but our focus handler sets hover focus. After mouseleave, clearFocus resets. But keyboard focus ring remains unless CSS. Need fix.

Need inspect hover behavior directly (not just drag focus). Need browser mouse move? Available actions: click maybe point, drag; no "move" action. Could use `click` on node to trigger? That may focus and maybe pointerenter? Browser click likely moves pointer and triggers mouseenter. Need maybe use `browser click` at node coordinates. But focus might set classes via focus handler. Need can inspect screenshot to see dimming. Let's do after adding CSS fix maybe reload. Also need test pan and zoom/reset. Need get precise camera transformations via DOM text after interactions. Browser tool DOM output shows camera readout. Great.

Need perhaps use browser drag background at e.g. (600,700) to (700,650), then camera readout changes. Need zoom via scroll at center. Need click reset. Need verify camera returns to initial. Need maybe the starting focus outline doesn't matter. Need maybe ensure panning starting on background not a node/link. Choose (600,730) maybe within HUD? HUD bottom-left x16-296,y705-784. (600,730) blank background below graph? graph bottom ~640; yes blank. Need drag from (600,700) to (700,640). Need ensure no node at target? starting background okay, target can be link or node? Zoom drag behavior pan handles all, no issue. Need camera x/y change. Use `browser drag`.
Need scroll zoom at center perhaps (600,400), but there may be bridge lines crossing; wheel zoom target any. Use `browser scroll x y delta`. Need know sign; positive delta maybe zoom out? likely. Need check. Need use `scroll` with delta e.g. -300 at (600,400), perhaps zoom in. Need camera readout change. Need then click reset at (78,44). Need check camera returns to x -55 y -37 1.09. Need maybe graph returns framing. Good.

But before interactions, fix focus outline. Need maybe also adjust drag status and hover interactions after drag: On motion frames, node 0 remains outlined white box and graph not dimmed. That is default focus outline. Add CSS.

Need maybe consider that `focus` handler on node group sets focus and class when clicked/dragged, but after mouseleave clears focus even though keyboard focus remains. This means for keyboard navigation, focusing via Tab calls setFocus; moving focus to next node triggers blur clear then focus set; okay. But clicking a node triggers focus and mouseenter both setFocus; then mouseleave clears focus even though focused, but that's fine for hover semantics. However a keyboard-focused node might lose highlight if mouse moves elsewhere? Mouseleave on unrelated node could clear when focus remains. Minor. Could avoid by combining hover and focus state, but not required. Need perhaps remove `tabindex` entirely to avoid focus outline and focus handlers? Accessibility not required. But keyboard focus highlight is nice. Could simply remove `tabindex`, `role`, and focus/blur handlers, keeping mouse interactions. Then no focus outline. But perhaps a11y not needed. Better to preserve with CSS. Need maybe focus event from pointer drag calls setFocus and then mouseleave clears; fine. But browser focus ring remains due `g:focus`. Add CSS.

Need perhaps use `:focus-visible` on SVG g? CSS works. Add:
.node:focus { outline: none; }
.node:focus-visible circle { stroke: #fff; stroke-width: 3.4; }
But since pointer drag focus may be considered focus-visible? Usually mouse focus doesn't match focus-visible. no outline. Good.
Need maybe if keyboard Tab focus, circle highlight visible. Fine.

Need maybe initial graph after reload no focus outline. Let's edit.

Need reload and run checks. But before browser, maybe think about requirement "Hovering a node highlights it, its directly connected neighbors, and their connecting links while dimming unrelated elements. Leaving the node restores normal appearance." Need explicitly verify hover and leave. Browser tool doesn't have mousemove/hover action but click likely triggers mouseenter and maybe stays until moving to background. Could `browser click` at node then screenshot; then click background to leave and screenshot. Need use. Note click on node will focus it; after click background, focus event may remain on node? Clicking background may blur; okay. Need maybe test with screenshot. Let's reload first.

Initial graph within view and nice. Need check hover. `browser click` at node 0 center approx (442,305) now. Need click likely triggers pointer move then mousedown/up. use click.

Hover highlight works: node 0, neighbors 1,9,10,30, four links highlighted; others dim. Need leave restore. Click background maybe at (600,700); but that might cause focus blur. Need use `browser click` at (600,700) maybe background, but could also start pan? click no drag. Then screenshot.

Hmm leaving node restored normal appearance (dimming gone) but node 0, 1,9,10,30 still have white outlines/glow; links still white/dashed bright. Why? Because `clearFocus` removed `.is-active` classes? status says normal, class `has-focus` false. But CSS reveals node circles with white stroke and bridging links dashed - actually those are hub nodes with perhaps focus-visible circle on node 0 (white glow) and neighbors with white rings? Wait compare initial screenshot: node 0 had no white glow; bridge links were tan dashes. After click background, node 0 has glow, nodes 1,9,10,30 have white rings, bridge links are white. Could be that focus still set on node 0 from keyboard (`focus-visible circle`) and maybe mouseenter on a different node? Let's inspect: status says "Hover a node..." and `data-focus=none`. Yet active classes might still be present because `clearFocus` called but maybe then `focus` event fires again? Need understand.

Actually screenshot after clicking background: hub nodes 1,9,10,30 circles have white outline and bridge links are white. Could simply be CSS hover on line? No. Wait initial screenshot: bridge links dashed tan. In screenshot after click, all four bridge links are bright white dashed. That's exactly `.is-active` styling from focus; but `has-focus` false means `.has-focus .link.is-active` doesn't apply! Unless our CSS selector specifically `#graph.has-focus .link.is-active`, so if `has-focus` removed, active link styling shouldn't apply. But maybe screenshot is transient from transition (120ms) at frame +0ms; `clearFocus` just happened, CSS transitions are midway. Yes! Browser screenshot at +0ms may capture intermediate state while opacity/stroke transitions from active to normal. Status DOM updated instantly, but opacity animating. That's likely. Need wait via screenshot or motion to see final. Let's call screenshot after some time.

Great normal appearance restored. Need now test pan and zoom. Need maybe not need reload; current state initial. Let's pan background. Choose starting (600,700) to (700,650). Need avoid HUD (x16-296) and legend. That's blank except grid. Use drag.

Pan works: x -55→45 (+100), y -37→-87 (-50), zoom same. Need zoom via scroll. Use `browser scroll` at center maybe (600,400), delta -300. Need check semantics. Let's do.

Zoom works, zoom from 1.09 to 1.66, camera x/y changed accordingly. Need click reset. Button at approx (78,44). Use browser click.

Reset works exactly. Need maybe node drag check after reload with focus outline fixed and camera stays. We already saw earlier before CSS fix. We should recheck affected behavior after CSS fix maybe node drag still works. Need drag node 0 again and see camera readout unchanged and links follow. Use (442,305) to (510,365). Need maybe after drag end, simulation settles; screenshot at +0ms shows drag position. Need camera unchanged. Let's do.

This screenshot at drag end? Node 0 moved from (442,305) to (506,359), yes. Connected links to 1,9,10,30 follow. Camera unchanged. Great. But status says "Node 0 focused..." rather than dragging, because drag end happened and pointer still over node. That's fine. Need maybe check release simulation settle and graph returns; earlier motion did. Need maybe potential issue: after drag release, the node returns almost exactly to anchor; that's simulation settling. Need perhaps verify linked lines follow while node dragged, which screenshot shows. Good.

Need maybe check there is no focus outline after dragging. Screenshot shows no white rectangle. Good.

Need maybe check `has-focus` highlight and reset after leaving node. We verified. Need maybe check pan/zoom with reset after node drag? Requirement: "Drag one node and check that connected links follow it while camera stays in place. Pan background and zoom to check camera movement, then use Reset view and confirm graph returns to initial framing." We did these sequentially but node drag after reset, not before pan. Need maybe final sequence in current state: node drag has happened, simulation settling, need pan then zoom then reset. We already did pan/zoom/reset before node drag; but to fully simulate task sequence maybe need do pan/zoom/reset now after node drag. Could do quick. Also need ensure graph data unchanged after reset (node positions settle). Need maybe check node drag release settling with motion to get graph back. Then pan/zoom/reset. Let's do a brief combined check. Need perhaps check camera readout after drag stays initial and after simulation settles. Use motion.

Motion frames show graph fully settled back to initial layout; camera unchanged. Good. Need maybe verify pan/zoom/reset after drag specifically. Let's do quickly.

Pan shows graph moved +100,-50. Need zoom.

Zoom works; some nodes offscreen, expected. Need reset.

Everything works. Need maybe consider potential unmet requirement: "connect nodes 0,10,20,30 in a ring to link the clusters." We used edges 0-10,10-20,20-30,30-0. Yes.

Need maybe check no external requests. Only local d3.min.js. CSS no imports. Good.

Need maybe check `index.html` present. yes. Need perhaps final report concise with what checked and unverified. Need mention initial console ready, no errors; graph layout; node drag links follow/camera unchanged; hover/leave; pan/zoom/reset. Need mention unverified e.g. touch gestures, non-1200×800 responsive viewport, keyboard accessibility not explicitly tested. Need avoid claiming things not checked. Need maybe include file path clearly. Should we do final file check via bash maybe verify no external URLs? Could grep quickly. Need maybe check script tag exactly `<script src="d3.min.js"></script>`. Need maybe ensure no `http` references. We can run quick grep. Also maybe check HTML syntax with no errors. Browser console had no errors. Need maybe no separate files. Let's run quick.

Need maybe check no external URLs in CSS? grep found none. Good.

Need perhaps discuss we fixed focus outline issue. Not necessary but can mention no console errors. Need final answer with path and checks, unverified. Desired concise. Need mention reporter and remaining unverified behaviors. Could say:

"Created `/tmp/job-S0llHO/index.html` as single self-contained page with inline CSS/JS and local `<script src="d3.min.js">`. It defines 40 nodes etc.

Browser checks: initial load console only "Force graph ready", all 40 IDs/labels and four colored rings plus hub ring visible; dragged node 0 from ~... connected links followed, camera readout stayed x -55,y -37,1.09×; release simulation settled; hover node 0 highlighted four neighbors/four links and dimmed rest, leaving restored; background pan changed camera to x45,y-87; wheel zoom to 1.66×; Reset view returned to x -55,y -37,1.09× and initial framing without replacing graph data.

Remaining unverified: touch/pinch, viewport resizing/non-1200x800 aspect ratios, keyboard-only focus behavior."

Need be careful "graph data unchanged" we didn't programmatically compare data arrays, but code reset only camera and status says; we saw graph still present and nodes. Could say "verified visually / camera readout". Could maybe mention "the reset handler only calls zoom.transform, no data replacement" from code; that's code-level, not runtime. Fine.

Need perhaps note initial graph within view. Yes.

Need maybe final file present. Need no more tool calls. Use final.