The user wants me to build a single-page web app in one self-contained HTML file named `index.html`. It should use d3.min.js (already present in the current directory) to render an interactive force-directed graph with approximately 40 nodes in several clusters, draggable nodes, hover highlighting of neighbors, and zoom/pan. I need to define sample nodes and links inline.

Let me start by checking the current directory and confirming the d3.min.js file exists.

Let me check the d3 version to know which API to use.

D3 v7.9.0. So I should use the modern d3-force API. Let me write an index.html that:

1. Loads d3.min.js via `<script src="d3.min.js"></script>`
2. Has inline CSS in a `<style>` tag
3. Has JS in a `<script>` tag
4. Renders a force-directed graph with ~40 nodes in several clusters
5. Draggable nodes
6. Hover highlighting of neighbors
7. Zoom/pan

Let me design the data: ~40 nodes across several clusters (say 4-5 clusters). Each node has an id, a cluster/group, and maybe a label. Links between nodes, denser within clusters.

Let me write the code carefully using d3 v7 APIs:

- `d3.forceSimulation(nodes)`
- `.force("link", d3.forceLink(links).id(d => d.id))`
- `.force("charge", d3.forceManyBody())`
- `.force("center", d3.forceCenter(width/2, height/2))`
- `.force("x", d3.forceX())` and `.force("y", d3.forceY())` for clustering

- Drag: `d3.drag().on("start", ...).on("drag", ...).on("end", ...)`
- Zoom/pan: `d3.zoom().on("zoom", ...)` applied to the SVG via `d3.zoomTransform`

- Hover highlighting: on node mouseover, dim non-neighbors.

Let me build the nodes and links inline in JS.

I'll create clusters: Cluster 0 (Dev), Cluster 1 (Infra), Cluster 2 (Data), Cluster 3 (UX), Cluster 4 (Ops). Let me make about 40 nodes.

Let me create a helper to generate clusters.

Actually, let me just hardcode the data inline as arrays for clarity, but it's a lot. I could generate it programmatically in the JS, which is fine and still "defined inline".

Let me write a script that generates clusters and links. I'll create a deterministic dataset.

Let me plan the structure:

```js
const clusters = [
  { name: "Development", color: "#e6194b" },
  { name: "Infrastructure", color: "#3cb44b" },
  { name: "Data", color: "#4363d8" },
  { name: "UX/UI", color: "#f58231" },
  { name: "Operations", color: "#911eb4" }
];

const nodeNames = {
  Development: ["Frontend", "Backend", "API Gateway", "Auth Service", ...],
  ...
};
```

Let me just generate nodes with a function. I'll create 40 nodes distributed across clusters, plus links.

I want links denser within cluster, sparser between clusters.

Let me write it.

I'll produce the full HTML file now.

Let me make the design nice with a legend, title, etc.

Key implementation details for zoom/pan combined with drag:

- The SVG has a background rect that captures zoom events.
- We apply `d3.zoom()` to the svg's `g` container (the "stage").
- Drag on nodes: in dragstarted, set `d.fx` and `d.fy` to the current position (taking into account zoom transform? Actually the drag coordinates are in screen space; we need to invert the zoom transform). 

Handling drag + zoom together: the drag events give screen coordinates (event.x, event.y). Since zoom applies a transform to the container, the simulation's internal coordinates need to be in the same space as where the nodes are positioned. A common approach: apply zoom transform to the container group, and in drag handlers, invert the transform to get simulation coordinates.

Let me implement that properly.

In d3 v7, `d3.zoom().on("zoom", (event) => { svg.attr("transform", event.transform); })` where svg is the g container. Wait, but the drag uses `event.x` and `event.y` which are already adjusted for the zoom transform if the zoom is applied on the same element? Actually, d3-drag and d3-zoom interaction: when you use zoom on an element and drag on child elements, the drag's `event.x`/`event.y` is in the local coordinate system of the dragged element, which is the screen coordinates. Since the zoom transform is applied to the parent, d3 automatically handles the coordinate mapping for drag? Let me recall.

Actually, d3-zoom automatically transforms the coordinate system for drag and selection events that occur within the zoomed element. From the d3-zoom docs: "The zoom event properties are: ... If the zoom behavior is applied to a selection, the zoom transform is applied to the selection. The drag behavior will be transformed too, so that the drag's x and y coordinates are in the local coordinate system."

Hmm, let me recall more precisely. From d3-zoom documentation:

> The zoom behavior also handles drag- and zoom-related events on the same element. For example, you can combine zoom and pan. ... If a zoom behavior is applied to the same element as a drag behavior, the zoom behavior's transform is applied to the drag coordinates.

Actually, the key detail: d3-zoom will automatically adjust the coordinates of any drag events on descendants (or the same element) so that `event.x` and `event.y` are in the transformed (post-zoom) coordinate space. This means I can treat them as simulation coordinates directly. 

Wait, is that right? Let me think. The d3-zoom source: when you call `d3.zoom().on("zoom", ...)`, and the zoom is on the container, the drag behavior on children... Actually the behavior that handles this is: d3-zoom installs a "transform" on the container via `attr("transform", ...)`. For drag events, d3-drag uses `d3.pointer(event, ...)` or `d3.mouse`/`d3.drag`. 

Actually the cleanest approach: don't rely on automatic coordination. Instead, in the zoom handler apply transform to container. In the drag handler, compute the simulation-space coordinates by inverting the transform:

```js
function dragstarted(event, d) {
  if (!event.active) {
    event.active = { ... };
  }
  // freeze velocity
  d.fx = d.x;
  d.fy = d.y;
}

function dragged(event, d) {
  // invert zoom transform
  const t = d3.zoomTransform(svg.node()); // or the container
  const pos = t.apply([d.x, d.y]); // actually we want to invert
  ...
}
```

Hmm, `t.invert([event.x, event.y])` gives the simulation coordinates from screen coordinates. But wait — is event.x/y in screen (zoomed) space or in the container's untransformed space?

Let me reconsider. When d3-zoom is applied to the container g and it transforms it, the drag on child elements... d3-drag computes coordinates via `d3.pointers` or `d3.pointer`. These coordinates are in the local coordinate system of the event target's parent? Actually `d3.pointer(event)` returns coordinates relative to the target element. Since the target (the node circle) is inside the transformed g, the coordinates returned by `d3.pointer` already account for the transform? No — SVG transforms affect rendering, not the DOM layout. `d3.pointer` uses `getScreenCTM`-like methods through `svg.createSVGPoint()`... Actually `d3.pointer` calls `eventTarget`... Let me just recall the practical fact.

The practical, well-known approach: When combining d3-zoom and d3-drag where zoom is applied to a parent `g`, you should set the drag coordinates properly. The simplest robust method:

In the drag handler:
```js
function dragged(event, d) {
  d.fx = event.x;  // this works if zoom transform is applied to container
  d.fy = event.y;
}
```

But there's a subtlety: `event.x`/`event.y` from d3-drag are in the coordinate space of the *parent* of the dragged element at the time of the event. Actually d3-drag's `event.x` and `event.y` are computed via `d3.pointer` of the drag container... 

OK let me look this up more carefully from memory of d3-zoom source code. In d3-zoom, there's this in the `zoom` behavior: when a `transform` is being applied and a `drag` or `wheel` or `touch` happens, the source event coordinates may be re-mapped. Specifically, d3-zoom, when attached, overrides the coordinate computation using `d3.touches`/`d3.mouse`. 

The d3-zoom documentation explicitly states:

> Note that the zoom behavior also intercepts pointer events on the zoomed element, transforming them so that they are suitable for use with d3-drag. This allows you to combine pan and zoom with drag and drop.

Hmm, actually I recall this being true: d3-zoom automatically applies the inverse transform to the coordinates reported by drag events, so that `event.x`/`event.y` are in the *untransformed* (simulation) coordinate space. This is exactly what you want: the simulation coordinates are in the untransformed space (the g's local coordinates before the zoom transform). So `d.fx = event.x` works directly when zoom is applied to the same g that holds the nodes.

Wait, let me double check. Actually I'm fairly confident: when you apply `d3.zoom()` to the container `g` (the same g that contains nodes and where you set the transform), the drag on node children will have `event.x`/`event.y` in the simulation coordinate space because d3-zoom transforms the event coordinates. Yes — this is the canonical pattern.

Hmm, but there's actually a subtlety: the transform must be applied to the SAME element that the zoom behavior is registered on, AND that element must be the parent of the dragged elements. Then d3-zoom's coordinate transform (via `d3.zoomTransform`) and the pointer-event interception work together.

Actually wait. Let me reconsider whether d3-zoom intercepts drag coordinates automatically. I think the automatic behavior is: d3-zoom, when the zoomed element is not the same as the drag target, will transform the coordinate space. Let me recall the implementation.

In d3-zoom's source (zoom.js), there's:
```js
function zoomListenerListener... 
```

And it registers, on the zoomed element, a handler for "mousedown"/"touchstart" etc. But for drag on *child* elements, the zoom behavior doesn't directly intercept.

Hmm, actually, the real mechanism: d3-zoom applies the transform to the selection via `selection.attr("transform", ...)`. The drag on children uses `d3.pointer(event, node)` which, in an SVG, returns coordinates in the local coordinate system of the parent (which is the g with the transform). So `d3.pointer` accounts for the SVG transform automatically because it uses `getScreenCTM` / `getCTM` inverse!

`d3.pointer(event, node)` returns the position of the pointer relative to `node`, computed via `node.getScreenCTM()` to transform from screen to local. So if the node is inside a transformed g, `d3.pointer` already gives untransformed (simulation) coordinates! That's the magic of SVG — `getScreenCTM` inverts the transform.

But wait, d3-drag's `event.x`/`event.y` — does d3-drag use `d3.pointer` relative to the parent or relative to the element? In d3-drag source, `event.x` and `event.y` are computed relative to the *dragging target* using `pointers` or relative to a "container" which defaults to the parent node. Let me recall:

```js
function dragstarted(event, subject) {
  ...
  const point = svg.createSVGPoint ? ... 
  const [originX, originY] = ... 
}
```

Hmm. Actually d3-drag computes `event.x` and `event.y` relative to the *subject's parent* using `d3.pointer(event, node.parentNode)`. And since `d3.pointer` uses the local CTM, it's automatically in untransformed space. So `event.x`/`event.y` ARE in the untransformed coordinate space when using an SVG transform.

But wait — the simulation positions (`d.x`, `d.y`) are in the coordinate space of the g *before* applying the zoom transform. So if `event.x`/`event.y` are in that same untransformed space (because they account for the transform via CTM), then `d.fx = event.x` works. 

So the pattern is:
```js
const svg = d3.select("svg");
const g = svg.append("g");  // container for zoom

svg.call(d3.zoom().on("zoom", (event) => {
  g.attr("transform", event.transform);
}));

// nodes are appended to g
function dragged(event, d) {
  d.fx = event.x;
  d.fy = event.y;
}
```

But actually there's a subtlety: d3-zoom, when applied to `svg` (the root svg element), the pointer events on `svg` — the zoom uses `d3.brush`... no. Let me reconsider: should I apply zoom to the `svg` root or to the inner `g`?

If I apply `d3.zoom()` to the `svg` (the root element), then I should transform the inner `g`. If I apply zoom to the `g` directly, then zoom and any content transform combine.

Common pattern: 
```js
svg.call(zoom);  // zoom on the svg root
function zoomed(event) {
  g.attr("transform", event.transform);
}
```

But here's the catch: when you apply zoom to the `svg` root element and use drag on child circles inside `g`, d3-drag's coordinates... d3-drag uses `d3.pointer(event, parentNode)`. The parentNode is `g`. `d3.pointer` computes relative to `g`, accounting for `g`'s transform. But `g`'s transform is set by the zoom handler to `event.transform`. So at the moment of the drag event, `g.getScreenCTM()` includes the zoom transform. `d3.pointer` inverts it → gives untransformed (simulation) coordinates. 

So yes, `d.fx = event.x` works correctly with zoom applied to svg root transforming inner g. This is the canonical, robust pattern.

Hold on, but I should double-check that d3-zoom doesn't ALSO try to transform event coordinates when it's on the svg root. When zoom is on `svg` (root), and drag is on circles inside `g`, the zoom behavior's "pointer" handling: d3-zoom listens on `svg` for its own gestures. It would interfere with drag if both try to capture. But typically you don't drag the svg itself; you drag circles. Since the circles are not the zoomed element, zoom's gesture handling is on svg only for pan/zoom gestures. 

Hmm, but actually there can be a conflict: d3-zoom on svg captures mousedown/mousemove/touch for zooming on the svg. d3-drag on circles captures mousedown for dragging circles. Since they target different elements and both use the same pointer, the bubbling means: mousedown on circle → bubbled to svg → both drag and zoom start? That would be a problem.

Actually d3-zoom, when attached to svg, calls `d3.drag`... no. Let me recall: d3-zoom handles "mousedown", "touchstart", "wheel" etc. on the zoomed element. d3-drag on circles handles "mousedown" etc. on the circles. The event would trigger both behaviors since it bubbles. Hmm, but in practice the well-known recipe for combining zoom and drag is:

> Apply the zoom to the svg element. Use drag on the nodes. To prevent both from activating simultaneously, in the dragstarted handler, stop the event's propagation or call `event.sourceEvent.stopPropagation()`.

Actually, the canonical d3 recipe (from d3-zoom's "Zoom and Pan" example combined with draggable nodes in force layouts) does:
- `svg.call(zoom)`
- node drag handlers with `event.sourceEvent.stopPropagation()` maybe not needed.

Hmm, but there IS a known issue: when you zoom on the svg and drag nodes, the zoom and drag conflict. Let me recall the standard solution.

Actually, the most robust and commonly used pattern I've seen in d3 force + zoom + drag examples:

```js
svg.call(d3.zoom().on("zoom", zoomed));

function zoomed(event) {
  g.attr("transform", event.transform);
}

function dragstarted(event, d) {
  if (!event.active) event.active = {};
  // ...
  d.fx = d.x;
  d.fy = d.y;
}
```

And to handle the conflict between zoom (on svg) and drag (on circles), the trick is: the drag behavior on circles, on `dragstart`, does `event.sourceEvent.stopPropagation()`. Because the mousedown on the circle bubbles to svg (triggering zoom's pan start), but stopPropagation prevents that. Wait but then panning via dragging empty space still works because those mousedowns aren't on circles.

Hmm, actually I recall: d3-zoom's gesture on the svg uses pointer events; if the pointer is on a circle, the mousedown goes to the circle first (drag starts), then bubbles to svg (zoom's mousedown handler also fires → could start a pan/zoom). The conflict causes both. To avoid, `stopPropagation` in the drag handler stops it reaching the svg's zoom handler. But some implementations put zoom on the g instead to avoid this.

Alternatively, the cleanest: apply zoom directly to the `g` container (the same g holding nodes):
```js
g.call(d3.zoom().on("zoom", (event) => {
  g.attr("transform", event.transform);
}));
```
This makes g the zoom element AND the transform target. Then drag on children of g: d3-drag's coordinates are relative to g, and g's transform is the zoom transform, so CTM inversion gives simulation coordinates. The conflict between zoom-on-g and drag-on-children: same bubbling issue. The d3-zoom docs example "Combined Zoom & Pan" and force examples...

OK, I'm overthinking. Let me recall the EXACT canonical recipe from d3's own force-directed graph with zoom example (the famous one). 

The d3 zoom + force graph gallery example (by Mike Bostock / bl.ocks) typically:
- applies zoom to the SVG root via `svg.call(d3.zoom()...)`
- in the zoom callback sets the transform on the inner `g`
- for drag, uses standard dragstarted/dragged/dragended
- and crucially, in `dragstarted`, calls `event.sourceEvent.stopPropagation()` to prevent the zoom behavior from also grabbing the drag.

Actually wait, I've also seen it without stopPropagation working fine because... let me think about whether they actually conflict.

Let me reconsider: d3-zoom attaches a `mousedown` listener (and touch/wheel) to the zoomed element. When you mousedown on a circle that has a `mousedown` listener (from d3-drag on the circle), both listeners fire (capture/bubble). Both `event.target` is the circle, both get the event. So zoom would start a pan AND drag would start moving the node. This is the conflict.

To prevent zoom from starting when dragging a node, you call `event.sourceEvent.stopPropagation()` in the dragstarted / dragged handlers. But stopPropagation on a bubbled event that the zoom listener already received... timing: listeners on the target (circle) fire before listeners on ancestors (svg) in the bubble phase. So if the circle's mousedown handler calls stopPropagation, the svg's mousedown listener won't fire. 

So in dragstarted: `event.sourceEvent.stopPropagation()` — this stops the mousedown from propagating to the svg, preventing zoom's mousedown from triggering. Good. But then the zoom's mousedown never fires, so zoom won't start during a node drag. 

But there's a subtlety: d3-zoom might also use pointer events or handle the drag itself. Let me check: modern d3-zoom (v7) uses "mousedown", "touchstart", "wheel" and pointer events via `d3.pointer`. Actually d3-zoom's internal uses `on("mousedown", ...)` etc via `selection.on`. Hmm wait it might use pointer events now? Let me check. d3-zoom v7: it listens to `"mousedown"`, `"touchstart"`, `"wheel"`, `"keydown"`, `"keyup"` plus pointer events `"pointerdown"`, etc? Actually I believe d3-zoom uses `pointer` events and `wheel`. Let me not over-analyze.

The practical solution that definitely works: 
- Apply zoom to the **inner g** (same g as nodes), so zoom transform and node positions are in the same element → no coordinate inversion surprises.
- Use `event.sourceEvent.stopPropagation()` in dragstarted to prevent g's own zoom from also grabbing.

Hmm, but if zoom is applied to g and drag is on children of g, stopPropagation stops the pointerdown from bubbling to g, so zoom won't start during node drag. And empty-space drags (mousedown directly on g or svg) trigger zoom. 

Wait, if zoom is on g and the background rect is a child of g, then mousedown on the background rect bubbles to g → zoom starts. Good for panning. And mousedown on a node circle (child of g) → drag handler fires, stopPropagation → stops reaching g → zoom doesn't start. 

So the plan: 
- `svg` holds everything; inside svg, append a `g` (the stage/container).
- Add background rect to g (for click/zoom capture? Actually the background rect should be before zoom... hmm if zoom is on g, the background rect inside g would be caught by both drag and zoom? No, background has no drag handler, so only zoom starts).

Hmm, actually I realize there might be a cleaner well-tested approach. Let me just go with the canonical d3 recipe that I'm confident about, using zoom on the svg root and transform on inner g, plus stopPropagation in drag start. This is the recipe from countless working force-zoom examples (e.g., Observable notebooks "Force-Directed Graph with Zoom" by Mike Bostock).

Let me recall one specific widely-used example: "Interactive Force Graph with zoom and drag" — the pattern:
```js
const svg = d3.select("svg");
const g = svg.append("g");

svg.call(d3.zoom().on("zoom", (event) => {
  g.attr("transform", event.transform);
}));

function dragstarted(event, d) {
  if (!event.active) {
    event.active = {};
    event.on("inactive", ... ); // no-op
  }
  event.active = true;
  d3.select(event.sourceEvent.target).raise().classed("active", true);
  // fix position
  d.fx = d.x;
  d.fy = d.y;
}

function dragged(event, d) {
  d.fx = event.x;
  d.fy = event.y;
}

function dragended(event, d) {
  d.fx = null;
  d.fy = null;
}
```

And in `dragstarted`, no stopPropagation typically because in that example the zoom is on the svg root and drag is on circles; I've seen it work without stopPropagation. But to be safe and avoid the double-gesture conflict, I'll include `event.sourceEvent.stopPropagation()` in dragstarted. Actually, hmm, but if I stopPropagation, does zoom ever get re-enabled for subsequent gestures? Yes — stopPropagation only affects that one event; subsequent clicks on empty space still propagate normally. 

Wait, actually there's a concern: if I stopPropagation on mousedown of the node, the zoom behavior's mousedown on svg doesn't fire, so zoom doesn't initialize its pan. Good. Then on mouseup (dragend), fine. Subsequent mousedown on background triggers zoom normally. Good.

But actually, will the lack of zoom mousedown cause issues with the zoom's "active" state during the drag? Since zoom didn't start, no. Fine.

OK so I'm confident:
- `svg.call(zoom)` on root svg.
- transform inner `g`.
- `dragstarted` does `event.sourceEvent.stopPropagation()` plus sets d.fx/d.fy.
- coordinates: `d.fx = event.x` works because d3-pointer accounting for the g's SVG transform via CTM inversion. Wait — is the event.x/y in screen or simulation space?

Let me re-examine this carefully because it's the crux. When `g` has a `transform` attribute set (the zoom transform), and I mousedown on a circle inside g and drag, `event.x`/`event.y` from d3-drag... 

d3-drag v7 source: it computes coordinates via `d3.pointers` → uses `d3.pointer(event, node)` where node is the dragged element. `d3.pointer` computes: 
```js
function pointer(event, node) {
  ... 
  const svg = node.ownerSVGElement;
  const point = svg.createSVGPoint();
  point.x = ...; point.y = ...;
  point = point.matrixTransform(svg.getScreenCTM().inverse()); // relative to svg
  // then relative to node's CTM
  ...
}
```
Actually `d3.pointer(event, node)` returns coordinates relative to `node`, accounting for all ancestor transforms (because it uses the node's CTM). So if g is transformed, `d3.pointer` returns coordinates in g's *untransformed* local space (i.e., simulation space). 

d3-drag uses `d3.pointers` for multitouch but for single-pointer it uses coordinates relative to the **parent of the dragged node**? Or relative to the dragged node itself? Let me recall. In d3-drag's dragended/drag behavior, `event.x` and `event.y` are "the x and y coordinates of the pointer relative to the dragged element" — no wait.

From d3-drag docs:
> event.x - the x coordinate of the pointer relative to the dragged element's containing element (its parent node).

Hmm. Actually: "x, y: the coordinates of the pointer relative to the drag behavior's container node." The container node defaults to the dragged element's parent (the `g`).

So `event.x`/`event.y` relative to the parent `g`, accounting for g's transform → untransformed (simulation) coordinates. 

Therefore `d.fx = event.x; d.fy = event.y;` gives simulation coordinates, consistent with where the simulation places nodes (simulation coordinates = untransformed g local coords). 

So with zoom on svg root transforming inner g, `d.fx = event.x` works and is the widely-used pattern. With stopPropagation added, it's robust. I'm now confident. But let me ALSO double check the alternative I worried about: do I even need stopPropagation? Many examples omit it and work. The reason it works without stopPropagation: d3-drag calls `event.sourceEvent.preventDefault()` or `stopImmediatePropagation`? Hmm. Actually d3-drag on start calls `event.sourceEvent.target`-matching... 

Actually, I recall now: d3-drag and d3-zoom DO coordinate automatically in a specific way. When you apply BOTH a drag and a zoom to elements where zoom is on an ancestor, d3-zoom's "wheel" is the only thing that might conflict; but d3-zoom specifically checks `d3.drag` and if the pointer is on a draggable element, it... no.

I'll just include stopPropagation to be safe — it's harmless and prevents the conflict definitively. Actually, wait: there's a known subtlety where calling stopPropagation can break text selection or the zoom's "click" detection. But for a graph with no text selection needs, it's fine.

Hmm, but actually, if I stopPropagation on the mousedown of a node, and the node is inside g which is inside svg, the zoom behavior on svg never sees the mousedown → zoom doesn't engage → good, the node is dragged without inadvertent zoom. 

Let me also handle: the simulation should keep running after drag (set d.fx/d.fy on drag, release on dragend, and keep `simulation.alpha(0.3).restart()` during dragstarted so it keeps the layout active).

Now hover highlighting of neighbors:
- On node mouseover: select the node, add a "hovered" class; find its linked neighbors (direct links only, optionally 2-hop), dim everything else (reduce opacity), highlight neighbors.
- Implementation: build an adjacency or iterate links. With ~40 nodes it's cheap to just compute on hover: for a given node id, find links where source or target is that node → get neighbor ids. Then select all nodes, set opacity: neighbors and self = 1, others = 0.15. Set all links opacity: links touching hovered set = 1, others = 0.1.

Actually simpler and robust: iterate `linkGroup.selectAll(...)` and check. Let me precompute adjacency map for neighbor lookup (faster).

Let me precompute a `const neighbors = d3.group(... )` or an adjacency object. I'll build `adjacency` Map: id → Set of neighbor ids (from links, both directions). Also keep `neighbors2` maybe not needed.

On hover, compute neighbor set = adjacency.get(d.id) ∪ {d.id}. Then:
- nodes: opacity 1 for those in set, 0.1 else; maybe increase stroke.
- links: opacity 1 for links where both endpoints... no, where source or target in set; else 0.05. Actually highlight links that connect hovered node to its neighbors (source or target == hovered id), and also maybe links among neighbors. Keep simple: highlight links where source==hovered or target==hovered.

On mouseout: restore to default opacities.

I'll store default opacities in variables.

Now clusters: use `forceX`/`forceY` per cluster? Or a clustering force. Standard approach: each node has a cluster; use `d3.forceX(clusterCenterX[cluster]).strength(p)` or separate forces. Actually a clean way: assign each node `group`; use `forceX` with strength pointing to cluster center, and `forceY` similarly. But all nodes share the same x/y forces? forceX centers all x toward a single value (the mean of... actually forceX pulls each node toward `forceX.x()` constant). If I want clusters separated, I can add a separate forceX for each cluster via `forceX(id => clusterX[d.group])`? 

Actually `d3.forceX()` lets you pass a function `(node) => x` so each node can be pulled toward a different target x. So:
```js
.force("x", d3.forceX().x(d => clusterCenterX[d.group]).strength(0.2))
.force("y", d3.forceY().y(d => clusterCenterY[d.group]).strength(0.2))
```
where clusterCenterX/Y are arrays keyed by group index. This draws clusters to their anchor points. Combined with link forces (denser intra-cluster) and a charge/repulsion, clusters separate nicely. Good.

Let me define cluster center positions spread across the svg:
```js
const clusterCenters = [
  {x: width*0.22, y: height*0.3},
  {x: width*0.78, y: height*0.25},
  {x: width*0.3, y: height*0.78},
  {x: width*0.75, y: height*0.78},
  {x: width*0.5, y: height*0.5}, // optional 5th
];
```
5 clusters. 40 nodes / 5 = 8 per cluster.

Let me name clusters:
1. "Platform" (purple)
2. "Services" (teal)
3. "Analytics" (amber)
4. "Frontend" (red)
5. "DevOps" (green) — center.

Node names per cluster. Let me just generate names like cluster + index, or give real-ish names. I'll give descriptive names for flavor.

Let me define data inline. I'll write a small generator but keep the arrays explicit enough to be clear. Actually, to satisfy "Define the sample nodes and links inline", I'll just write the arrays directly. With 40 nodes that's a lot but doable. Alternatively, generate programmatically within the JS (still inline). I'll do a hybrid: define cluster definitions (names + members) and generate nodes, then generate links with a seeded random function for connectivity. This keeps the file reasonable and the data "defined inline" in JS.

Hmm, but deterministic random without a library: I'll write a small seeded LCG so the layout is reproducible. Good idea — deterministic so it looks consistent.

Let me write the data generation:
- 5 clusters, each with ~8 named nodes.
- For links: connect each node to ~2-3 within-cluster neighbors randomly, plus a few inter-cluster bridges (so zoom/pan and highlighting make sense).

Let me code a seeded RNG:
```js
function mulberry32(a) {
  return function() {
    a |= 0; a = a + 0x6D2B79F5 | 0;
    let t = Math.imul(a ^ a >>> 15, 1 | a);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296;
  }
}
const rng = mulberry32(12345);
```

Then generate nodes and links.

Let me write the whole thing now. I'll make it visually polished: dark theme, node labels, cluster legend, link arrows? Force graphs sometimes use arrow markers for directed links. I'll make links undirected but could add arrows. Keep undirected for simplicity; maybe add a subtle arrow. Actually to imply relationships, I'll keep bidirectional-looking links (lines). I'll add a marker for directional flavor? Undirected is cleaner. I'll skip arrows.

Node rendering: circle + label. Hover enlarges node and changes stroke. Link as path or line. With zoom/pan I should use a `g` for links too so the transform applies uniformly. Actually I'll put everything (links, nodes, labels) in the single stage `g`, transformed by zoom. Then nodes and labels scale? With d3-zoom, the container is transformed, and the circles inside scale too (their radius attribute is in user space? No—circle r in SVG scales with transform, which makes them grow under zoom, often undesirable). 

Common approach: use screen-space-fixed elements. To keep node circles from scaling with zoom, you can counteract by dividing r by the transform scale, OR place nodes/labels in a separate non-scaled overlay. The simplest visually-acceptable approach for a demo: let everything scale, OR fix sizes. 

I'll make node radius scale-corrected so circles stay readable: set `r` based on `event.transform.k`: 
```js
// in zoom handler:
const k = event.transform.k;
node.attr("r", baseR / k);
link.attr("stroke-width", baseStroke / k);
label.attr("font-size", baseFont / k);
```
This keeps visual sizes roughly constant as you zoom, which looks professional. But it adds complexity; alternatively just scale everything (circles get bigger when zoomed in—also fine but looks odd). I'll implement the scale-correction for a polished feel. Actually, that can be a bit janky. Let me think about the simplest robust choice.

Given it's a demo and the requirement is "interactive force-directed graph with zoom/pan", letting elements scale is acceptable and common (many d3 examples scale everything). However, having the label text and circles scale makes them hard to read when zoomed out. I think scale-correction is nicer. I'll do it but keep it simple: update r, stroke-width, font-size in the zoom handler using current k. I'll keep references to node/ link/ label selections.

Actually, there's a subtlety: the zoom transform is applied to the `g` containing nodes/links/labels. If I then also scale r by 1/k, the effective screen size of circles stays constant. Good. But during the drag-zoom gesture, the handler fires on every frame, updating r — fine.

Hmm, one issue: links. If links are paths/lines in the same g, their stroke-width scales with transform; dividing by k keeps them visually constant. Good. But the link *geometry* (endpoints) is in simulation coords (transformed), correct.

Wait, but if zoom is applied to the svg root (not g)... let me apply zoom to svg root and transform g. Then in the zoom handler I also update node r etc with k. That works since I have selections. Let me do that.

Actually, applying the per-element scale correction requires storing base values and recomputing each zoom frame. Let me store `node` selection globally (module-level in the script) so the zoom handler can access. Since everything is in one script tag, I'll use module-ish closures with `let`/`const` at top.

Let me structure the script:

```html
<script src="d3.min.js"></script>
<script>
  // dimensions
  const width = 960, height = 700;
  const svg = d3.select("body").append("svg")
    .attr("viewBox", [0,0,width,height])
    .attr("font-family", "system-ui, sans-serif");

  // stage group (transformed by zoom)
  const g = svg.append("g");

  // data generation (inline)
  ...

  // link / node groups
  const link = g.append("g").attr("class","links");
  const node = g.append("g").attr("class","nodes");

  // simulation
  const simulation = d3.forceSimulation(graph.nodes)
    .force("link", d3.forceLink(graph.links).id(d=>d.id).distance(...).strength(...))
    .force("charge", d3.forceManyBody().strength(-...))
    .force("collide", d3.forceCollide().radius(...))
    .force("center", d3.forceCenter(width/2, height/2))
    .force("x", d3.forceX().x(d=>centers[d.group]).strength(...))
    .force("y", d3.forceY().y(d=>centers[d.group]).strength(...));

  // draw links
  const linkSel = link.selectAll("line")
    .data(graph.links).enter().append("line")
    ...;

  // draw nodes
  const nodeSel = node.selectAll("circle")...;
  // label group
  const label = node.append("g")...  // hmm circles and labels

  // Actually use a group per node: <g class="node"><circle/><text/></g> for drag/raise
```

Common pattern: each node is a `<g>` containing a circle and text, so raising the whole group on hover works and drag applies to the group. But dragging a group: `dragstarted(d)` sets d.fx/d.fy and raises. The dragged handler moves via d.fx=d.fy (simulation handles position). That works with circles inside g positioned via transform, OR circles with cx/cy bound. 

If node is a g with transform set from simulation ticks (i.e., `node.attr("transform", d => `translate(${d.x},${d.y})`)`, then dragging moves by setting d.fx/d.fy (simulation updates d.x/d.y, tick updates transform). And hover highlighting changes opacity/stroke of the circle child. This is clean. The `zoom` transform is on the outer `g` (stage), and node transforms are translations within — combined (zoom transform * node transform). 

But there's a concern with `event.x`/`event.y` coordinate space & zoom when node is a g positioned by translate: the translate is applied as the node's own transform; `d3.pointer` accounting for g's translate + stage's zoom still yields simulation coords. Good.

Hmm, but if zoom scales (k != 1), the stage g transform is `translate(tx,ty) scale(k)`. The node g's translate is in simulation coords. `d3.pointer(event, node)` returns coords relative to node accounting for both transforms → simulation coords. 

So dragging works. Good. Using a `<g>` per node with a translate is the cleanest because raising/hover affects both circle and label together.

Let me go with per-node `<g>`.

Tick handler:
```js
function ticked() {
  linkSel.attr("x1", d=>d.source.x).attr("y1", d=>d.source.y)
         .attr("x2", d=>d.target.x).attr("y2", d=>d.target.y);
  nodeSel.attr("transform", d=>`translate(${d.x},${d.y})`);
}
```

Zoom handler:
```js
function zoomed(event) {
  g.attr("transform", event.transform);
  // scale-correct visuals
  const k = event.transform.k;
  nodeSel.selectAll("circle").attr("r", R/k);
  linkSel.attr("stroke-width", lw/k);
  label... font-size
}
```

But node circles are inside per-node g; selecting `nodeSel.selectAll("circle")` works. Let me keep `circle` radius constant in screen space by r = R/k. Hmm but R/k when k<1 (zoomed out) → larger circles; when k>1 → smaller. That keeps screen size ~constant. Reasonable. But maybe I don't need scale correction; it's extra. Let me include a mild version to keep labels readable. Actually, let me keep it simpler and just set base sizes and not scale-correct, to reduce code complexity and bugs. Hmm. But then zoomed-out = tiny labels. 

Decision: I'll include scale correction for stroke-width and font-size and circle radius, it's not much code and looks much better. I'll store references.

Actually, reconsider: if I scale-correct radius with R/k but the node g also gets scaled by k (since it's inside zoomed stage), the net circle radius in screen = (R/k)*k = R (constant). Good. For stroke-width lw/k → net screen = lw. Good. font-size fs/k → net = fs. Good. All constant. 

But careful: `nodeSel.selectAll("circle").attr("r", ...)` sets r in the node's local user units; since node g itself is scaled by k (from stage zoom) plus translated, the rendered r in screen = r_attr * k = (R/k)*k = R. 

Now zoom on svg root, transform g (stage). nodeSel inside stage g. All good.

Let me also make sure the background for pan is captured. I'll add a transparent rect covering viewBox on the svg (below the stage g) so mouse wheel / drag on empty space pans. Actually, d3-zoom attaches to the svg element and captures pointer/wheel events on the svg regardless of children; the svg element spans the whole area, so pan on empty svg area works. A background rect helps capture clicks but not strictly needed for wheel. I'll add a background rect in the svg (first child) for safety and visual.

Wait, if I apply zoom to the `<svg>` element and the background rect is a child, mousedown on background rect → bubbles to svg → zoom starts pan. Good for panning empty space.

But node drag: mousedown on node circle (child of stage g, child of svg) → bubbles to svg (zoom) AND fires drag on circle. I'll stopPropagation in dragstarted to avoid zoom grabbing. Good.

Hold on, if zoom is on the svg and stage transforms g, then a "pan" via dragging empty svg area: zoom's gesture computes pointer position in svg coords, applies translate to g. Good. And the scale-corrected visuals update. Good.

One more: when zoomed and you click-drag a node, after releasing, the simulation continues. Good.

Let me also center the layout: forceCenter at width/2,height/2 plus cluster forces. With cluster forces pulling toward center, plus center force, clusters spread in a rough grid (since I set cluster anchor positions). Actually forceCenter pulls everything to one point; combined with per-cluster forceX/forceY, the cluster anchors win. The center force just nudges. Fine. Actually to avoid conflict, I might drop forceCenter and rely on cluster anchors; but forceCenter keeps the whole graph roughly centered initially. I'll keep cluster forces strong and center weak/zero. Let me use forceCenter with low? Hmm. I'll keep forceCenter at center and cluster forces moderate; should be fine because cluster forces are per-node toward cluster anchors which are spread across the canvas, dominating. Initial positions will jitter from center; fine after running.

Actually the classic cluster-force layout doesn't use forceCenter; it uses forceX/Y per-cluster (the "cluster" of forces approach). I'll follow that: no forceCenter; each node pulled to its cluster anchor x/y. Plus charge + link + collide. Good—clusters form around anchors.

Let me pick strengths:
- link strength: 0.6, distance: ~60-80
- charge -220
- collide radius ~18 (node radius ~12 + padding). But if I scale-correct r by /k, collide radius in sim units should be base ~18.
- x/y cluster strength ~0.25

Initial simulation alpha 1.0 (default) until settled; I'll let it run. Maybe start with `simulation.alpha(1).restart()`.

Now node labels: text element with node id/name. With scale correction font-size. Place at y = -r-4 (above circle). With per-node g transform, text positioned at translate(-?) Actually I'll place text at x=0,y=-(R+6) so it sits above the circle. Good.

Hover: on node (g) mouseover, raise and highlight; change circle stroke & maybe scale? I'll add class "hover" via attr/styling. Since text and circle share the node g, I'll target the circle child: `d3.select(this).select("circle")`.

Let me set node base radius R = 11, stroke-width 2.5.

Coloring by cluster.

Legend: list clusters with color swatches.

Let me also add a subtle glow filter on hovered nodes? CSS filter on circle via `filter: url(#glow)`. I can define an SVG filter `glow` and apply on hover. Nice touch. I'll add `<filter id="glow">`.

Let me also dim: on hover of node, set all links/nodes opacity low except neighbors.

Implementation of neighbor highlight:
- Build adjacency: `const adj = d3.group(links, d=>d.source.id)` no. I'll build a Map id->Set of neighbor ids.
```js
const adj = new Map(graph.nodes.map(n=>[n.id, new Set()]));
for(const l of graph.links){
  adj.get(l.source).add(l.target);
  adj.get(l.target).add(l.source);
}
```
But links' source/target are objects not ids (d3 forceLink stores the actual node references after initialization, and ids as .id). When building adjacency from graph.links (the raw data), source/target are ids (strings) if I store them as strings. To avoid confusion, I'll store links with source/target as node id strings in the raw data, build adjacency from ids, then pass to forceLink with `.id(d=>d.id)`. forceLink matches by id to node objects. Good—adjacency on ids is consistent.

Highlight:
```js
function highlight(d) {
  const nb = adj.get(d.id);
  nb.add(d.id);
  // neighbors 2-hop? optional. keep 1-hop + self.
  nodeSel.selectAll("circle").attr("opacity", n => nb.has(n.id)?1:0.15);
  linkSel.attr("opacity", l => (nb.has(l.source)||nb.has(l.target))?0.6:0.08);
}
function unhighlight(){
  nodeSel.selectAll("circle").attr("opacity",1);
  linkSel.attr("opacity", l=>l.opacity||0.4);
}
```
But link opacity varies by cluster maybe; I'll set link base opacity to 0.4 and selected to full. Simpler: store base link opacity 0.5. On unhover restore to 0.5.

Hmm, but the per-link color might encode clusters; let me color links by source cluster color with low opacity base 0.4, and highlight to 1 for incident links. 

Let me set link stroke = color(source cluster). Base opacity 0.4; on hover of node, incident links to 1, circles: self+neighbors 1, rest 0.2.

For the "hovered" node itself, also grow it / add glow.

Let me code it.

I need base radii stored so that unhighlight restores default radius (since highlight might grow hovered node). I'll grow hovered node radius to R*1.5 (scale corrected by /k? radius attr = (R*1.5)/k; but if k changes the hovered node's attr computed at zoom-time... Actually if I change r attribute on hover, the zoom handler later overwrites r to R/k for all, resetting the hover growth. That's a conflict. To avoid, keep separate state: use a class and CSS? With attr r approach the zoom handler clobbers.

Option: Apply zoom scale correction via CSS transform on a wrapper? Complex. Alternative: don't scale-correct; instead keep constant r in sim units and accept that zoom scales them (simpler, fewer bugs). Then hover growth via attr r works across zoom because zoom doesn't touch r. Hmm but then zoomed-out labels tiny.

Let me reconsider the scale correction. Maybe it's more trouble. Let me choose: **No scale correction** — let the zoom transform scale everything uniformly, including circles and text. This is simple, robust, and visually acceptable (it's literally how the classic d3 force-zoom examples look). When zoomed out, elements shrink (still visible), when zoomed in they enlarge (still fine). Node drag, hover, highlight all purely on attr/style, no conflict with zoom. 

The classic d3.force + zoom example (Mike Bostock's "Zoomable Force-Directed Graph") actually does NOT scale-correct; it just transforms g and updates translate in ticks. Labels are small when zoomed out but that's the standard look. Many users accept it. For polish I could scale-correct but the conflict with hover-growth is annoying. 

Compromise: scale-correct ONLY via zoom handler using a stored "highlighted growth factor" multiplier per node — i.e., radius attr = (baseR * growthFactor)/k where growthFactor stored on node data (1 normally, 1.6 when hovered). The zoom handler reads `d.growth` from bound data (but circles don't have data... the per-node g has data d). Hmm, the circle is inside node g; I can do `nodeSel.each(d => ...)` and within set circle r. Actually I can store growth factor on the node datum: `d.growth = 1.6` on hover. In ticked/zoomed, compute `nodeSel.selectAll("circle").attr("r", d => { let n = d; ... })`. But the circle's data is the node datum? If I bind node data to the circle (or to the node g), then `.selectAll("circle").attr("r", d => baseR * d.growth / k)` where d is the node. But the circle is inside node g; binding data to node g and using `nodeSel` references the g; `nodeSel.selectAll("circle")` — the circles' data would be... I'd need to bind data to circles too. 

This is getting complicated. Let me simplify: I will scale-correct in zoom handler by storing the hovered-node's scale factor in a per-node datum property `d.hovered` (boolean), and radius = `baseR * (d.hovered?1.5:1) / k`. The tick handler (separate from zoom) sets the node transform translation. Zoom handler sets r/font-size/stroke-width. Both use the node data which I can access: in zoom, `nodeSel.selectAll("circle").attr("r", d => ...)`. For this, circles must have the node datum bound. 

If each node is a `<g>` (nodeSel) with datum d, and contains a circle, then `nodeSel.selectAll("circle")` returns circles but their data is NOT bound (only the g has data). I can re-bind: `nodeSel.selectAll("circle").data(d => [d])`. Or simpler, select the circle within each node g via `nodeSel.select("circle").attr("r", d => ...)`. Since nodeSel is bound to nodes, `nodeSel.select("circle")` for each node selects its circle child, and the datum is the node d (selection.select propagates the bound datum? Actually `.select` within a selection: the child selection inherits the datum of the parent? No — d3's `.select` returns children; the datum of each element in the subselection defaults to the datum of the corresponding parent element IF not explicitly set. Yes: "when you select a child, the child inherits the parent's datum." Actually, the subselection's data() — the datum of a subselection element is the datum of its parent (the element it was selected from) until you call `.data()`. So `nodeSel.select("circle").attr("r", d => d.hovered ? ... )` — here d is the node's datum (inherited). Yes! `.select` propagates the parent's bound datum to the child. Great. So I can do `nodeSel.select("circle").attr("r", d => baseR * (d.hovered?1.6:1) / k)`.

Similarly `nodeSel.select("text")` inherits datum.

So scale correction with hover growth is doable:
- zoom handler: 
```js
const k = event.transform.k;
nodeSel.select("circle").attr("r", d => baseR * (d.hovered?1.6:1) / k);
linkSel.attr("stroke-width", lw / k);
nodeSel.select("text").attr("font-size", fs / k);
```
where nodeSel is the g per node with datum.

But `nodeSel.select("circle")` only selects the FIRST circle per node (there's one) — fine. And it gives one element per node with the datum inherited. 

And tick handler sets translation: `nodeSel.attr("transform", d => `translate(${d.x},${d.y})`)`.

This works and looks polished. Let me go with scale correction. 

But wait, when k changes mid-hover, r updates correctly since it uses d.hovered. Good. On hover start, set d.hovered=true and immediately update r (call a refresh function). On hover end, d.hovered=false and refresh.

Let me make a `updateNodeStyles(k)` function used in zoom and hover. And the zoom transform k may be 1 initially. At start k=1 so r=baseR. Good.

Let me define `let currentK = 1;` updated in zoomed; hover handler calls updateNodeStyles(currentK).

OK. Now, the d3-drag coordinates with zoom scaling: As analyzed, `event.x`/`event.y` from d3-drag give simulation coords (CTM-inverse accounting). With per-node g positioned by translate inside stage g (which has zoom transform), this holds. Let me double-check that d3-drag uses `d3.pointer` relative to the parent of the dragged element (the stage g), and that accounts for the node g's translate AND stage g's zoom transform. `d3.pointer` uses the dragged element's `ownerSVGElement` and the node's own CTM? Actually `d3.pointer(event, node)` where node is the dragged element → returns coords relative to that element's local space, inverting element.parentNode... hmm.

Let me get precise. d3-drag: the `x`/`y` of the drag event are computed as the pointer position relative to the **container** (the parent of the subject). It uses `d3.pointers(event, container)` then for single pointer uses the first. `d3.pointers(event, container)` returns coordinates of all pointers relative to `container`. And `d3.pointer(event, container)` returns coords relative to container accounting for container's CTM and the SVG root CTM. 

So for a node g dragged (its parent is stage g), container = stage g. `d3.pointer` returns coords relative to stage g, accounting for stage g's transform (zoom!). So it inverts the zoom transform → simulation coords. 

Wait, does `d3.pointer(event, container)` account for container's own transform? `d3.pointer` computes coordinates relative to the given node by using that node's CTM (getCTM includes the node itself + ancestors). Coordinates relative to the node's local space = invert node's CTM. But here "relative to container" means relative to container's top-left in container's local coords, which inverts container's CTM (which includes zoom). So yes, event.x/y are in the container's local (simulation) space, zoom-inverted. 

Therefore d.fx = event.x gives the correct simulation coordinate. Confirmed. Great, scale correction + drag works.

But one more subtlety: d3-drag sets the container to `d3.select(node).node().parentNode` — the parentNode. For a circle inside node g, parentNode is the node g; but I'm dragging the node g itself, whose parentNode is stage g. So container = stage g. Good — event.x/y relative to stage g, zoom-inverted → simulation coords. 

Now let me also confirm: does d3-zoom on the svg root set stage g's transform such that `d3.pointer` inversion is correct? d3.zoom applies `g.attr("transform", event.transform)` where transform is a d3 zoom transform (scale+translate in svg's coordinate space). d3.pointer uses getCTM which reads the actual transform attribute → correct. 

Alright, I'm confident. Let me also ensure that the zoom gesture on svg does not break dragging: With stopPropagation in dragstarted on the mousedown of node, svg's zoom won't start, so k doesn't change mid-drag. Fine. If user pans (empty space) while not dragging, k may change; next node drag uses correct inversion. Good.

Edge: after a pan that changes k, the node radii scale-corrected via zoom handler already updated to R/k. Good.

Now let me write the HTML. I'll make width/height responsive-ish with viewBox 960x700 and height via CSS to fill. Use a centered container.

Let me write the full file now.

I'll also add a small instruction overlay (tooltip) — optional. Keep minimal: maybe a caption "Drag nodes • Scroll to zoom • Hover for neighbors".

Let me write data: clusters with names and colors, members (named), and generate links.

Let me define cluster color palette (distinct, colorblind-friendly enough):
1 Platform: #4e79a7 (blue)
2 Services: #59a14f (green)
3 Analytics: #f28e2b (orange)
4 Frontend: #e15759 (red)
5 DevOps: #b07aa1 (purple)
(plus maybe a 6th neutral? keep 5.)

40 nodes: 8 per cluster = 40. 

Names per cluster (8 each). Let me list:
Platform: "API Gateway", "Auth Service", "User Service", "Billing", "Payments", "Notifications", "Rate Limiter", "Load Balancer"
Services: "Search", "Recommendations", "Geo Lookup", "Image Resizer", "Email Worker", "Queue Broker", "Session Store", "Config Service"
Frontend: "Web App", "Mobile App", "Admin Dashboard", "Landing Page", "Checkout UI", "Profile UI", "Analytics Dashboard", "Docs Portal"
Analytics: "Event Tracker", "ETL Pipeline", "Warehouse", "Metric Store", "Alert Engine", "Funnel Analyzer", "Report Builder", "Data Catalog"
DevOps: "CI Runner", "Deploy Bot", "Log Aggregator", "Health Monitor", "Feature Flags", "Secrets Vault", "Cache Cluster", "DB Proxy"

Links: 
- Within each cluster: connect in a chain + a few random to give density. 
- Between clusters: a handful of bridges (e.g., API Gateway ↔ Auth, Frontend ↔ API Gateway, Analytics Warehouse ↔ Data Catalog... already same cluster; bridge to Search, etc.)

I'll generate links with the seeded RNG: for each cluster, take its nodes; connect node i to node (i+1) mod n (chain), plus each node connects to 1-2 random within-cluster nodes; plus inter-cluster bridges added explicitly via list.

Let me just generate within-cluster edges: for each pair in cluster, add link with prob p. That could be many edges; keep p ~ 0.25 → ~8*7/2*0.25 ≈ 14 edges per cluster *5 = 70 links, plus bridges ~6. That's a reasonable dense graph. Good for neighbor highlighting.

Actually 8 nodes fully connected would be 28 pairs; p=0.25 → ~7 per cluster. *5 = 35 links + bridges ~6 = ~41 links. Fine. Maybe bump to p=0.3 → ~45. Let me pick p=0.3.

Inter-cluster bridges (explicit pairs):
- API Gateway (Platform) ↔ Web App (Frontend)
- Auth Service (Platform) ↔ Mobile App (Frontend)
- Search (Services) ↔ Event Tracker (Analytics)
- Email Worker (Services) ↔ Alert Engine (Analytics)
- Config Service (Services) ↔ Feature Flags (DevOps)
- Health Monitor (DevOps) ↔ Alert Engine (Analytics)
- DB Proxy (DevOps) ↔ Warehouse (Analytics)
- Queue Broker (Services) ↔ ETL Pipeline (Analytics)
- Log Aggregator (DevOps) ↔ Log? 
A few more to make cross-links visible. Let me add ~8 explicit bridges.

I'll store node names; assign id = name (unique). group = cluster index 0-4. Build nodes array and links by name.

Implementation steps in code:
```js
const clusters = [
  {name:"Platform", color:"#4e79a7"},
  {name:"Services", color:"#59a14f"},
  {name:"Frontend", color:"#e15759"},
  {name:"Analytics", color:"#f28e2b"},
  {name:"DevOps", color:"#b07aa1"}
];
const members = { Platform:[...], Services:[...], ... }; // 8 each
// build nodes
const nodes = [];
clusters.forEach((c,i)=>{ members[c.name].forEach(nm=>{ nodes.push({id:nm, name:nm, group:i}); });});
// within links
const seen = new Set();
function addLink(a,b){ const k=a+"|"+b; if(seen.has(k))return; seen.add(k); graphLinks.push({source:a,target:b}); }
// within-cluster random
...
// bridges
bridges.forEach(d=>addLink(d[0],d[1]));
```

forceLink with .id(d=>d.id). Good.

Now let me also make link distance adaptive: maybe cluster nodes closer. Use link.distance(70) and strength 0.5. charge -240. collide radius ~16.

Cluster anchor positions: 5 positions. Let me compute:
centers for group i spread in a circle or grid. I'll just hardcode:
group0 (Platform): (width*0.22, height*0.32)
group1 (Services): (width*0.78, height*0.30)
group2 (Frontend): (width*0.20, height*0.75)
group3 (Analytics): (width*0.80, height*0.78)
group4 (DevOps): (width*0.50, height*0.52)
Good, spread across.

Now write CSS for body (dark bg #0d1117), svg full width. Legend positioned absolute.

Let me write the file.

For d3.select("body") vs a container div. I'll select body. Use `d3.select(document.body)`. Append svg.

Let me also handle window resize? Not necessary; viewBox scales with width 100%.

Let me make the svg width 100% of a container, height 700 via viewBox.

I'll write it.

Let me carefully write the zoom handler with scale correction and ensure `currentK` is in scope.

Also the simulation tick updates the per-node g transform and link line coords. On zoom, update radii. Both independent. On drag, simulation updates x/y → tick redraws.

Drag handlers:
```js
function dragstarted(event, d) {
  event.sourceEvent.stopPropagation();
  if (!event.active) {
    event.active = true;
    // keep simulation warm
  }
  simulation.alpha(0.3).restart();
  d.fx = d.x;
  d.fy = d.y;
  d3.select(event.sourceEvent.target.closest("g")).raise().classed("dragging",true);
}
function dragged(event, d) {
  d.fx = event.x;
  d.fy = event.y;
}
function dragended(event, d) {
  d.fx = null;
  d.fy = null;
  d3.select(event.sourceEvent.target.closest("g")).classed("dragging",false);
  if (!event.active) event.active = false;
  // simulation.alphaTarget maybe 0
}
```
Note event.sourceEvent.target is the circle (since drag attached to node g but pointer target is the circle touched). I attach drag to nodeSel (the g). The mousedown target could be the circle or text inside. `event.sourceEvent.target.closest("g")` gives the node g. Good.

`raise()` moves node g to end of parent so it's on top. But raising changes DOM order; since links are in a separate group (link) that's after? I must put `node` group AFTER `link` group in DOM so nodes render above links, but raising nodes to top of node group is fine. Actually `raise()` moves within its parent (the stage g), to last child — within node group. Links are in a separate child g (link group) which I place before node group, so links always behind nodes. Good. But `raise()` within node group moves g to end of node group (still behind nothing problematic). Fine. Actually I want dragged node on top of other nodes → raise within node group. Good.

Wait, but the per-node g has class; raising sibling gs inside node group works. Good.

Now hover highlighting interacts with raise? On hover I'll also raise. Fine.

Let me also ensure text labels don't overlap (overlap is inherent; with zoom scale correction and modest count it's acceptable). Could add collision but no.

Let me finalize and write the file.

I'll add a subtle drop shadow filter for nodes and glow for hover.

CSS:
```css
html,body{margin:0;height:100%;background:#0d1117;color:#c9d1d9;font-family:system-ui,Arial,sans-serif}
svg{display:block;width:100%;height:100%;cursor:grab}
svg.zooming{cursor:grabbing}
.link{stroke:#444;stroke-opacity:0.45}
.node circle{fill:#fff;stroke:#fff;stroke-width:2.5;cursor:pointer;transition:stroke-width .15s}
.node text{fill:#c9d1d9;font-size:11px;pointer-events:none}
.node:hover circle{stroke-width:3}
.legend{...}
```
Wait CSS transitions on stroke-width conflict with JS zoom scale-corrected r? r is attr (JS), stroke-width is CSS (for .node circle stroke-width?). Actually circle stroke-width I'll set via attr in JS for scale correction. The hover stroke-width change—I can do via JS setting on hover or CSS. To avoid conflict with scale-correction (which sets stroke-width attr too), I'll manage stroke on hover via JS as well, multiplying. Hmm. Let me manage stroke-width via attr in JS and on hover set a higher value; the zoom handler recomputes attr each frame using d.hovered. So define base stroke = 2.5, hover stroke = 3.5. In zoom handler: `nodeSel.select("circle").attr("stroke-width", d => (d.hovered?3.5:2.5)/k)`. And on hover set d.hovered and call zoom-reflow. 

Actually simpler: keep stroke-width constant (no scale correction for stroke), only scale-correct r and font-size. Stroke-width of /k makes strokes thin when zoomed out; maybe leave stroke-width constant at 2.5 — but then when zoomed in, strokes get thick (scaled by k) → 2.5*k thick. Hmm. To look good scale-correct everything. I'll scale-correct stroke-width too, with hover factor. Fine, it's just one more attr.

Let me define functions:
```js
function applyZoomScales(k){
  linkSel.attr("stroke-width", LINK_W/k);
  nodeSel.select("circle").attr("r", d=>BASE_R*(d.hovered?1.6:1)/k).attr("stroke-width", d=> (d.hovered?HOVER_STROKE:BASE_STROKE)/k);
  nodeSel.select("text").attr("font-size", FONTSIZE/k);
  currentK = k;
}
```
Call applyZoomScales(event.transform.k) in zoomed. On hover, set d.hovered and call applyZoomScales(currentK) to refresh radii.

But calling applyZoomScales on every hover for all nodes is O(n) fine for 40.

Actually nodeSel.select("circle").attr("r", d=>...) — does nodeSel.select("circle") return one circle per node with inherited datum? Yes. Good.

Now tick:
```js
function ticked(){
  linkSel.attr("x1",d=>d.source.x).attr("y1",d=>d.source.y).attr("x2",d=>d.target.x).attr("y2",d=>d.target.y);
  nodeSel.attr("transform", d=>`translate(${d.x},${d.y})`);
}
```

Good.

Now let me write final data and code. Let me write the file.

I'll include a caption and legend.

Let me write everything.

Check: `d3.forceLink(graph.links).id(d => d.id)`. The links have source/target as id strings. Good.

For adjacency highlight, source/target in graph.links are strings (ids). Good.

Let me also set link color by source cluster: `linkSel.attr("stroke", d => color(d.source.group))`? After forceLink initializes, link.source is the node object (not id), so link.source.group works. Good. I'll color by source cluster with base opacity.

Let me set link opacity base 0.5 (instead of 0.45). On unhighlight restore to 0.5.

Alright, writing now.

Let me make sure to call `simulation.on("tick", ticked)` and start.

Also set `simulation.alpha(0.5).restart()` initially maybe, so it animates. Default alphaDecay. Fine.

Let me also disable right-click context menu? Not needed.

Let me write the file content.

One more: viewBox with preserveAspectRatio. Set `svg.attr("viewBox","0 0 960 700")`.

For the background rect (to capture pan / set bg): append to svg a rect 0 0 960 700 fill #0d1117, send to back (append first). Good.

Also I want node group to render above links; stage g is transformed; within stage: append link group first, then node group. Good.

Now let me write.

Let me also add a small "active simulation" via alphaTarget 0 so it cools.

Write final HTML.

Let me carefully write the JS for data and run.

I'll compute bridge list referencing member names.

Bridges (sourceName, targetName):
["API Gateway","Web App"],
["Auth Service","Mobile App"],
["Load Balancer","Admin Dashboard"],
["Search","Event Tracker"],
["Image Resizer","Analytics Dashboard"],
["Email Worker","Alert Engine"],
["Queue Broker","ETL Pipeline"],
["Config Service","Feature Flags"],
["Log Aggregator","Health Monitor"],
["DB Proxy","Warehouse"],
["Session Store","Profile UI"],
["Geo Lookup","Data Catalog"]

That's 12 cross-cluster edges. Good connectivity.

Within-cluster edges via RNG p=0.35.

Let me write code that builds links deterministically (seeded). Good.

Now writing the file.

Let me ensure node id uniqueness: all names unique across clusters? "Email Worker" only in Services, "Alert Engine" only Analytics, etc. "Health Monitor" DevOps, "Log Aggregator" DevOps. All unique. Good.

Let me also add "group" to nodes = cluster index, used for color and cluster anchors.

Now, cluster anchor map by group index:
const centers = [
 [width*0.22, height*0.30],
 [width*0.78, height*0.30],
 [width*0.20, height*0.78],
 [width*0.80, height*0.78],
 [width*0.50, height*0.52]
];
forceX().x(d=>centers[d.group][0]).strength(0.2)
forceY().y(d=>centers[d.group][1]).strength(0.2)

Good.

Let me write it all now. I'll keep the code compact but readable.

Final note: d3-force link.distance default 30; set distance(90) maybe so clusters spread. Let me set distance 90, strength 0.4. charge strength -260. collide radius 18 (BASE_R*scale 1 = ~12 -> collide a bit bigger 18). 

Actually collide radius in sim units: nodes radius ~12 (BASE_R). Collide 16. 

Let me set BASE_R=11, HOVER scale 1.7.

Link distance 90, strength 0.5. 
charge -280.
collide 16.
x/y strength 0.25.

Fine.

Write.

The grep didn't return. Let me just proceed; I know it's v7.9.0 from the file header.

Now let me write index.html.

Let me verify the file exists and do a quick sanity check. Let me also reconsider a couple of potential issues:

1. In `nodeSel.append("circle").attr("fill", d => "url(#nodeGrad)")` and then later in `refreshHoverScale` I set `attr("r")` and `attr("stroke-width")`. Good.

2. `nodeSel.select("circle")` returns one circle per node g (the first circle child). Datum inherited = node d. Good. So `.attr("r", d => ...)` receives node d with `d.hovered`. Good.

3. `nodeSel.select("text")` for font-size — text has class "lab". Good.

4. In `highlightNeighbors`, `nodeSel.classed("dim", n => !nb.has(n.id))` — nodeSel are g.nodes, n.id available. Good. `nodeSel.select("circle").classed("glow", d2 => d2.id === d.id)` — d2 is inherited node datum, has id. Good.

5. Drag subject uses `event.subject` — for drag on a g, subject needs to be set. d3.drag without subject defaults subject to the dragged element's... actually default subject is the active pointer's coordinates, not the node. When dragging nodes, the `subject` should be the node's position. Since I set `.subject(event => ({x: event.subject.x, y: event.subject.y}))` but event.subject in subject fn is... circular. Actually the default subject function returns `{x: event.x, y: event.y}` (the pointer position). To set the correct drag origin, I should provide subject = the node's current position. The standard pattern: `.subject(d => d)` — but subject receives the datum? No, subject is called with the source event, not datum. Hmm.

Let me reconsider. d3-drag's `.subject` is invoked with `(event)` and should return an object with x,y giving the drag's starting point in the same coordinate system as the drag coordinates. For a node positioned by transform (translate), the natural subject is the node's position: `{x: d.x, y: d.y}`. But in the subject function you don't get `d` directly. However, you can access the dragged element's bound datum via `d3.select(this).datum()`. 

Actually, the common d3.force draggable node pattern does NOT set a custom subject; the default subject is the pointer's current position, and the drag just sets d.fx/d.fy = event.x/event.y each frame, with the initial d.fx/d.fy set in dragstarted to d.x/d.y. That works fine without a custom subject. The subject is only used to compute the drag's starting "origin" for `event.dx`/`event.dy` relative coordinates, but since we directly use event.x/event.y (absolute) and set d.fx/d.fy absolute, the subject default to pointer position is fine. The dragged handler sets absolute position, so no need for dx/dy. So I can drop the `.subject(...)` call. Let me check: with default subject = pointer position at drag start, `event.x`/`event.y` in dragged are absolute pointer coords (zoom-corrected to sim space). Setting d.fx = event.x absolute works. 

But wait — does d3-drag's default subject cause an initial jump? The first dragged event: event.x = current pointer position (sim space). d.fx set to that. The node was at d.x/d.y. If pointer is exactly on the node center, no jump; otherwise small jump to pointer. Acceptable. The default d3 force-drag examples use d.fx/d.fy = event.x directly and accept the pointer grabs the node where clicked. Fine. I'll remove the `.subject` to avoid the circular reference (event.subject referencing itself). Actually `event.subject` is not defined when subject fn runs (chicken-egg). The default subject uses `d3.pointers`? The default is `event => ({x: event.x, y: event.y})`. Hmm wait the docs: "the default subject is the drag's origin, which is the pointer's position at the start." So removing .subject gives default. Let me remove it to be safe. 

Actually, setting the subject to the node center prevents a jump when clicking off-center. Let me implement subject properly via `this`:
```js
.subject(function(event) { return { x: event.subject ? event.subject.x : ... } })
```
No. Proper: `.subject(function(event) { return { x: d3.select(this).datum().x, y: d3.select(this).datum().y }; })`. But `this` in subject context is the dragged element (the group). `d3.select(this).datum()` gives the node datum. That returns node position as subject origin. This prevents the initial jump. Good. Let me use that.

But there's subtlety: when subject is the node position and the pointer clicked off-center, the first absolute event.x is the pointer location (sim space), so d.fx becomes pointer location → small jump to pointer. To truly prevent jump, you'd need to keep offset = pointer - node. With absolute d.fx = event.x, you always jump to pointer. To avoid, use dx/dy: `d.fx = event.subject.x + event.dx`. Hmm. This is the classic "drag with fixed offset" approach.

For simplicity and standard behavior, I'll just set d.fx = event.x absolute (the node jumps to the cursor, which is normal for force-graph drags — actually the classic d3 force example sets `d.fx = event.x; d.fy = event.y;` and it works, with a small jump if clicked off-center, but usually fine). The famous d3 force-directed drag example uses exactly `d.fx = event.x`. I'll match that. Remove custom subject.

So drop `.subject`. 

6. `scrollPreventFix` — I referenced a function `scrollPreventFix(e)` that doesn't exist. Let me remove that line `svg.on("wheel", (e)=>e.code && scrollPreventFix(e));`. It's broken. Remove it. Actually I intended to prevent page scroll; but the svg with viewBox and wheel handled by d3-zoom: d3.zoom calls preventDefault on wheel/touch by default? d3-zoom's wheel handler calls `event.preventDefault()` if the event is a wheel (it does). So page won't scroll. Remove the broken line.

7. The `svg.classed("busy", true)` toggles cursor. On drag start I set false; on end true. But "busy" class sets cursor grab. Fine. Actually while dragging a node, the node has cursor:grab via CSS; fine.

8. `d3.select(event.target).raise()` — event.target is the circle or text (since mousedown lands on circle). `.raise()` moves that element to end of its parent (the node g). That's not ideal — it raises the circle within the node g, but I want the whole node g raised. I used `event.target` (the circle), raise() raises circle within node g. Better: raise the node g. Let me use `d3.select(event.target.parentNode)` or store the node g. Actually the drag is attached to nodeSel (the g), but the mousedown target is a child (circle/text). So `event.target` = circle. To raise the node g, I should select the parent. Let me use `d3.select(event.target.closest('g.node'))` → closest g.node. Or `nodeSel.filter(d=>d===event.subject)`? Hmm. Let me use `d3.select(event.target).classed("dragging",true)` for styling but for raising use the node g: `nodeSel.filter(d => d === d3.select(event.target).datum())`? The datum of circle is inherited (the node). So `d3.select(event.target).datum()` = node d. Then `nodeSel.filter(nd => nd === d).raise()`. But in dragstarted I have `d` (the datum) as second arg. So:
```js
nodeSel.filter(n => n === d).raise().classed("dragging", true);
```
That raises the node g. Good. Let me use that instead of `event.target`.

But `event.target` also used for `d3.select(event.target).raise()` — replace.

Let me update dragstarted/dragended:
```js
function dragstarted(event, d) {
  event.sourceEvent && event.sourceEvent.stopPropagation();
  if (!event.active) { event.active = true; }
  nodeSel.filter(n => n === d).raise().classed("dragging", true);
  if (simulation.alpha() < 0.2) simulation.alpha(0.25).restart();
  d.fx = d.x; d.fy = d.y;
  d.hovered = true; refreshHoverScale();
}
function dragended(event, d) {
  event.active = false;
  nodeSel.filter(n => n === d).classed("dragging", false);
  d.hovered = false; refreshHoverScale();
}
```

9. `d3.rgb(colorOf(d)).brighter(1.2)` for stroke color. colorOf returns a hex string like "#4e79a7". d3.rgb parses it. Good. But stroke is set once at node creation; on hover I use CSS `.node:hover circle { stroke-width: 3.5 }` and glow filter. Actually I also set stroke in CSS? I set stroke via attr at creation. Hover only changes stroke-width via CSS and glow via class. The base stroke color stays the cluster-bright color. Good. Fine.

Wait, but `.node:hover circle` requires hover on the g to apply to the circle. The tooltip onmouseover is on nodeSel (g). The CSS `:hover` also applies on g:hover. Both fine. But CSS hover won't capture pointer on text? text is child of g, hovering text hovers g. Fine.

10. Potential issue: `nodeSel` is created with `.enter().append("g").attr("class","node").call(drag())`. The drag is attached after class set; good. Then I append circle/text to nodeSel. Order in DOM: circle then text — circle first (drawn under text) which is desired. Good.

11. `nodeSel.select("circle").attr("r", BASE_R)` at creation, then refreshHoverScale/zoom override. Fine.

12. The glow filter `feGaussianBlur` with `in="SourceGraphic"` and edgeMode duplicate creates a blur glow but no color spread — it blurs the white fill, not a colored glow. Acceptable; it'll look like a white halo. Fine. Could set stdDeviation 4.

13. `linkSel.classed("link-dim", l => !nb.has(l.source) || !nb.has(l.target))` — l.source is node object; nb is Set of ids; l.source is an object not id. BUG: nb.has(l.source) where l.source is an object → false always. So link-dim would be true for all links (since l.source object not in set). Need l.source.id. Let me fix: `!nb.has(l.source.id) || !nb.has(l.target.id)`. But during graph building, links have source/target as strings (ids). But after d3.forceLink initializes, the link objects are mutated: source/target become the node objects (with .id, .group, etc.). So in highlight (called after simulation starts), l.source is a node object with .id. Use l.source.id. Good. Fix that.

Similarly `link-hi` condition: `nb.has(l.source) && nb.has(l.target)` → use .id. Fix.

Let me fix both.

14. `neighborSet(d.id)` returns adjacency set of neighbor ids (strings). nb.add(d.id) adds self. Then `nb.has(n.id)` for nodes n (string ids) works. Good. For links use l.source.id. Fix.

15. Tooltip: `d3.pointer(event, svg.node())` computes pointer in svg coords but I don't use it (I use pageX/pageY for tooltip position). Remove unused var to avoid confusion. Actually I declared `const [x,y]=...` unused. Remove. 

16. The `scrollPreventFix` and `scrolled` function — remove the broken svg.on("wheel") line. The `scrolled` function is unused; remove.

17. `svg.classed("panning", ...)` on mousedown/up of svg — but mousedown on a node circle also reaches svg (bubbles) unless stopPropagation. Since dragstarted stops propagation, svg's mousedown won't fire during node drag → panning class won't wrongly show. For empty-space mousedown, svg mousedown fires → panning class while panning (zoom behavior handles drag). Fine. Actually when panning empty space, the zoom behavior's drag fires, not svg mousedown directly... the mousedown on svg (empty area) fires once at start → sets panning class true; mouseup sets false. Good visual.

But wait: mousedown on empty svg area — the rect background is a child of svg; mousedown on rect bubbles to svg → svg mousedown handler fires → panning true. Good. And zoom behavior starts pan. Good. On mouseup → panning false. Good.

18. Does d3.zoom conflict with d3-drag on the same svg? The zoom is on svg. Node drag stopPropagation prevents zoom's mousedown from firing when a node is clicked. Good. But what about the zoom's own mousedown on empty area — it fires normally. Good.

19. One concern: `event.sourceEvent.stopPropagation()` stops the mousedown from bubbling to svg. But d3-zoom listens on svg for "mousedown"/"pointerdown". If the node drag stops propagation, zoom doesn't start → good. But does the node drag itself still work? Yes, drag handler fired on the node (target phase at circle). Good.

But actually, there's a subtlety: d3-zoom v7 uses pointer events and might attach listeners that capture. And d3-drag uses mousedown/touch. If both use pointerdown... d3-drag v7 uses pointer events too! d3-drag in v7 uses "pointerdown" etc. And d3-zoom also uses pointer events? Let me check: d3-zoom v7 listens to "mousedown", "touchstart", "pointerdown", "wheel". d3-drag v7 listens to "pointerdown". Both listen to pointerdown on their respective elements. A pointerdown on the circle bubbles to svg. Both handlers fire (zoom's pointerdown on svg, drag's pointerdown on circle). stopPropagation in dragstarted (which runs during the circle's pointerdown handling) would stop propagation to svg's pointerdown? 

d3-drag's dragstarted fires on the "start" event which is triggered at pointerdown on the circle. If inside dragstarted I call `event.sourceEvent.stopPropagation()`, the sourceEvent is the pointerdown event at the circle target; stopPropagation prevents it from bubbling to svg → d3-zoom's pointerdown on svg never fires. 

But wait: order of listener execution. Both listeners are in bubble phase at their own level. The circle's pointerdown listener (d3-drag) executes; it calls start → my dragstarted runs stopPropagation. At that moment, has svg's pointerdown listener already executed? In event flow, the target's listeners execute first (target phase), THEN bubbles up. The circle IS the target of pointerdown. svg is an ancestor — its listener fires in the bubble phase AFTER the target's listeners. So my stopPropagation during the circle's target-phase handling prevents subsequent bubble-phase listeners (svg's zoom) from firing. 

So zoom won't start when dragging a node. 

But d3-zoom might also have a "wheel" zoom that still works independently (wheel on a node? wheel on svg area). Fine.

This should work. The stopPropagation approach is the documented d3 recipe for combining zoom + drag.

20. Potential issue: d3-drag's pointerdown on circle stops propagation; but does d3-zoom need to "capture" pointer for its own pan on empty space? Empty-space pointerdown goes to the background rect or svg directly (not stopped) → zoom starts. Good.

21. Let me reconsider: is there a simpler conflict? Many examples simply do `svg.call(zoom)` + node drag WITHOUT stopPropagation and it works because d3-zoom ignores the gesture if a drag subject is active? Actually d3-zoom and d3-drag DO coordinate via the "wheel" + "pointer". Hmm. But to be safe I keep stopPropagation. It's a well-known pattern (e.g., in d3 force zoom examples, they call `event.sourceEvent.stopPropagation()` in dragstarted). Good.

22. The `.subject` removal: with default subject (pointer position), dragged sets d.fx = event.x absolute. Fine.

Wait, actually I realize the default subject for d3-drag is `function() { return {x: event.x, y: event.y} }`? No. The default subject returns the pointer's position at start (origin), used to compute event.dx/dy. Since I use absolute event.x (not dx), subject is irrelevant to positioning. The only effect: if subject origin differs from pointer, the first event.dx would be nonzero but I don't use dx. So fine. Remove .subject.

Let me also double check `event.active` toggling: I set event.active = true in dragstarted if !active; in dragended set false. This is the alpha-target pattern to keep simulation warm. Actually `event.active` is the drag's active state; using it to gate alpha is the d3 example pattern: 
```js
if (!event.active) { event.active = true; ... }
```
and in dragended:
```js
if (!event.active) { event.active = false; }
```
This is fine. I set simulation.alpha(0.25) while dragging. Good.

23. Let me reconsider the `nodeSel.filter(n => n === d)` — at the time dragattached via .call(drag()), nodeSel is the selection of g.node. In dragstarted, `d` is that node's datum. filter(n=>n===d) returns the matching g. `.raise()` moves it. Good.

24. Edge case: after I raise a node, DOM order changes; the tick still updates transform by datum so position correct regardless of order. Good.

25. Labels overlapping when zoomed out — acceptable.

26. `viewBox` 960x700 with width 100% height 100% on svg in main (flex child). main has flex:1. svg height:100% → fills main. Good.

27. Check the `hint` row of kbd keys includes a `;;` weird. Let me fix labels: "Drag a node", "Scroll/drag to zoom & pan", "Hover to highlight neighbors". Fine; remove the weird kbd chars or keep simple. I'll simplify kbd text.

28. CSS `.node:hover circle` and `.node.dragging circle` set stroke-width 3.5, but JS also sets stroke-width via attr (zoom/hover). The CSS rule would override? CSS stroke-width applies to circle; attr stroke-width also applies; CSS wins (presentation attribute is lower specificity than CSS). So `.node:hover circle { stroke-width: 3.5 }` always 3.5 on hover regardless of zoom k scaling — that breaks scale correction (stroke won't thin on zoom out). Hmm. To be consistent, maybe remove CSS stroke-width hover rule and handle via JS class instead. 

I already handle hover stroke via JS `refreshHoverScale` using d.hovered. So I don't need the CSS `.node:hover circle {stroke-width:3.5}`. But raising on hover via CSS? CSS can't raise. I raise on hover via JS? I didn't raise on hover (only on drag). It's fine. Let me remove the CSS hover stroke-width and dragging stroke-width rules to avoid conflict, since JS manages stroke-width scale-corrected. Keep `.node.dragging` maybe for nothing. Let me remove those CSS stroke rules and rely on JS. But JS sets stroke-width each zoom/hover; that's enough. 

However, the glow filter and dim classes are CSS. Fine.

Let me remove:
```css
.node:hover circle, .node.dragging circle { stroke-width: 3.5; }
```
Replace with maybe a glow on hover too. Actually JS adds glow class on hover (nodeSel.select("circle").classed("glow", ...)). Good. So CSS hover stroke-width not needed. Remove it.

But then dragging node stroke-width change: JS sets via refreshHoverScale (d.hovered true, includes stroke-width). On drag, I set d.hovered=true and call refreshHoverScale → stroke-width becomes HOVER_STROKE. Good. Remove CSS rule.

29. `.node circle { transition: stroke-width .12s }` — with JS attr setting stroke-width directly, transition applies. Fine. But during zoom (continuous attr change) transition would animate stroke-width? Attr changes during rapid zoom would trigger transition each? transitions don't apply to attrs that change rapidly if a new transition overrides. Could cause lag. Remove the CSS transition to avoid jitter during zoom. Actually transitions on attr (r) set by JS: d3 sets attr directly (not transition), CSS transition applies to presentation? CSS `transition` applies to CSS properties, not SVG presentation attributes unless they're animatable and set via style. r as presentation attribute: CSS transition does apply to presentation attributes for SVG properties? Generally CSS transitions don't animate SVG presentation attributes; you need to set via style. Hmm. Actually CSS `transition` on SVG presentation attributes works in some browsers via the `r` property being a CSS property for SVG. For `<circle>`, `r` is a presentation attribute mapped to CSS property `r`. Transitions may apply. To avoid jank, I'll drop the `transition` CSS rule. Simpler. Remove transitions.

Let me remove `transition` from `.node circle`.

30. The `.dim` class sets `opacity:.28` on circle/text; but circles already have r scale-corrected; opacity fine. On node g.dim, circle opacity .28 and text opacity .28. The lab text also .dim .lab opacity .18 — redundant. Fine. Actually I set `fill` of text via CSS `fill: var(--text)`. The dim `.dim text { opacity:.28 }`. Good.

But note: highlighted node (self) should NOT be dim. nodeSel.classed("dim", n=>!nb.has(n.id)) → self not dim (nb has self). Good. And self gets glow. Good.

31. Tooltip: I use both `event.pageX` and `d3.pointer`. I'll remove the unused pointer line. Tooltip follows mouse; shows node name + cluster. Good. On mouseout hide. But if moving from node to tooltip there's no gap; fine.

Potential flicker: tooltip.show on hover, hide on mouseout. If moving mouse fast, hide triggers. Fine.

33. Let me ensure `nodeSel` is defined before drag() is called. In my code: `nodeSel = nodeG.selectAll(...).enter().append("g")... .call(drag())`. But `drag()` function references `nodeSel` inside (closure). `nodeSel` is assigned the result of `.call(drag())`? The `.call(drag())` runs drag() which returns a drag behavior; then .call(behavior) applies drag to nodeSel (the entering selection). Inside drag's event handlers, `nodeSel` is referenced at event time (later), by which point nodeSel variable is assigned. Since handlers run on interaction (later), nodeSel will be defined. But there's a closure: `drag()` is called during nodeSel creation; inside drag's returned handlers, `nodeSel` refers to the outer const. At creation time nodeSel isn't fully assigned yet, but handlers only execute later. JS closures capture the variable, not value, so it's fine — nodeSel will be assigned by the time handlers run. Good.

But `drag()` function is defined at top-level (function declaration) referencing nodeSel — fine.

Wait, `drag()` is a function declaration hoisted; nodeSel is a const declared later. Inside drag's handlers, referencing nodeSel at call time is fine due to closure (const must be initialized before handlers run, which it is). Good.

34. `nodeSel.classed("dim", n => !nb.has(n.id))` — nodeSel elements are g.node with datum n (id). Good.

35. The `linkSel` strokes: set via attr at creation `attr("stroke", d => colorOf(d.source))`. At creation time (enter), d.source is still the id string (links not yet initialized). WAIT — at selection creation, graph.links source/target are strings (ids from my data). d3.forceSimulation will later mutate link.source to node objects, but the initial `attr("stroke", d => colorOf(d.source))` is computed with d.source being a string at the time of `.append().attr(...)`. colorOf expects d.group — a string has no .group → colorOf returns undefined → stroke undefined. BUG.

I computed link stroke at node/link creation time, BEFORE simulation initializes links. So d.source is the id string. colorOf(d.source) fails. I need to set link stroke after simulation initializes links, OR color by looking up the node by id.

Options:
- After simulation starts (links mutated to objects), update link stroke. But attr set once stays. I can set stroke after a tick or after simulation init. 
- Or compute color from the id string by finding the node: `colorOf(nodes.find(n=>n.id===d.source))`. But simpler: set link stroke in the ticked function or after simulation init.

Cleanest: after creating the simulation (which immediately begins initializing on next tick?), actually forceSimulation initializes link.source/target lazily on the first tick or when .nodes() is set. The link objects get .source/.target replaced with node objects during `initialize()` which is called at creation of the simulation. Let me check: `d3.forceSimulation(nodes)` calls initialize() which sets node.index and initializes forces; forceLink.initialize is called when? forceLink.initialize runs when the force is added via `.force("link", ...)`? Actually forces' initialize is called within simulation's initialize if the force defines initialize. forceLink.initialize(graph) replaces link.source/target from ids to nodes. So by the time I create the simulation with `.force("link", d3.forceLink(graph.links).id(d=>d.id))`, the links' source/target become node objects (initialize called). 

So AFTER `d3.forceSimulation(...)` assignment, graph.links have node objects as source/target. So if I set link stroke AFTER creating the simulation, d.source is a node object. 

But in my code, I append links and set `attr("stroke", d => colorOf(d.source))` BEFORE creating the simulation. At that point link.source is a string. So stroke is undefined. 

Fix: either set stroke after simulation creation, or set stroke inside ticked (every tick re-set — fine, cheap) or set once after simulation init. Let me set link stroke color in a step after simulation creation, e.g., right after `const simulation = ...`:
```js
linkSel.attr("stroke", d => colorOf(d.source));
```
At that point links are initialized → d.source is node object → colorOf works. Good. Let me move the stroke attr to after simulation creation. Actually I set it in the enter chain; I'll remove from there and add after simulation. Or keep fill? Lines have no fill. Just stroke and stroke-width. I'll set stroke after simulation init. Let me set stroke-width too there (LINK_W). 

Simplify: create links without stroke, then after simulation creation do:
```js
linkSel.merge(linkSel)... // actually linkSel is the enter selection appended; selections only contain entering. I stored linkSel = linkG.selectAll(...).data(...).enter().append("line"). So linkSel has all 41 lines. Good. Set attrs after simulation.
```

Let me restructure: build linkSel append lines, then after simulation init, set stroke/stroke-width. And in ticked set x1/y1/... already. Actually I can set stroke/stroke-width right after creating linkSel (since data is objects, colorOf by id? no). Hmm, but I can color by looking up nodes with the id string using a map id->node. Let me build `const byId = new Map(nodes.map(n=>[n.id,n]))`. Then stroke = colorOf(byId.get(d.source)) where d.source is id string (before init) OR node (after init). If d.source is a node object, byId.get(object) → undefined. So not robust.

Simplest: set link stroke color AFTER simulation creation (links are objects). Do that. I'll set:
```js
linkSel.attr("class","link")
       .attr("stroke", d => colorOf(d.source))
       .attr("stroke-width", LINK_W)
       .attr("stroke-linecap","round");
```
after `const simulation = ...`. But I also need stroke-width scale-corrected on zoom — the zoomed() sets `linkSel.attr("stroke-width", LINK_W/k)`. It overrides the static LINK_W. Fine, zoomed() runs once initially? zoomed() is called on zoom events; initial scale k=1, but zoomed() doesn't run at start unless I call it. So initially stroke-width = LINK_W (good). I'll set base and also call a reflow at start. Actually I should initialize scales at k=1. Let me call `zoomed({transform: d3.zoomIdentity})` after setup so initial r/stroke/font set to base. That's clean. d3.zoomIdentity has .k=1, .x=0, .y=0. Good. I'll call that once.

Let me reorganize code: create simulation, then set link attrs, then call an init that sets zoomIdentity scales.

36. Also `nodeSel` circle `fill` uses `url(#nodeGrad)` set at creation with d (node) — colorOf not used for fill (fill is gradient). stroke at creation: `.attr("stroke", d => d3.rgb(colorOf(d)).brighter(1.2))` — d is node with group → colorOf(d) = cluster color. Good, set at creation with node datum. Fine.

37. So the only bug is link stroke set before init. Fix by moving after simulation. Let me also ensure linkSel is defined (it is) before moving attrs there.

Let me also reconsider: setting `.attr("stroke", d=>colorOf(d.source))` after simulation init — d.source is node object with .group → colorOf works. 

38. Now `ticked` sets link x1... using d.source.x/y (node objects have x/y after init/tick). Good.

39. Initial call to apply zoom identity: `zoomed({transform: d3.zoomIdentity})`. But zoomed() also sets `stage.attr("transform", identity)` → fine. And sets link stroke-width LINK_W/1. node r BASE_R/1. Good. Then simulation alpha 0.6 restarts and ticks update positions. 

But careful: calling zoomed manually with a fake event object; d3.zoomIdentity is a transform. `event.transform` accessed. Good. Let me call after attaching everything.

40. Tooltip uses `clusters[d.group].name` and colorOf(d) — d is node, group present. Good.

41. Remove unused `scrolled`, `scrollPreventFix`, `between`, `randBelow`, `adj` (I built adjacency Map directly; the `d3.group` line `const adj = d3.group(...)` is unused; remove to avoid confusion). Let me remove `const adj = d3.group(...)`.

42. `neighborSet` defined. Good.

Let me now also reconsider whether `nodeSel.select("circle").classed("glow", ...)` correctly targets — nodeSel is g.node; .select("circle") gets first circle per node. classed glow adds filter glow. Good.

43. The dim opacities: base opacity of circles is 1 (not set). On dim set to .28. On clear remove dim class → opacity back to 1 (default). Good. But links: base opacity from CSS `.link { stroke-opacity:.5 }`. On link-dim class `.link-dim { opacity:.12 }`. Wait CSS `.link-dim { opacity:.12 }` sets the line's opacity (the whole element opacity), and `.link-hi { opacity:1 }`. But `.link` has `stroke-opacity:.5`. Using element `opacity` + `stroke-opacity` multiply. On dim, opacity .12 makes it very faint. On hi, opacity 1 → stroke-opacity .5 → 50% visible. Maybe I want incident links fully visible. Let me set link base stroke-opacity .45 and on hi stroke-opacity 1. Use class to set stroke-opacity. Let me define CSS `.link { stroke-opacity:.45 } .link-hi { stroke-opacity:1 } .link-dim { stroke-opacity:.08 }`. Cleaner. Remove element opacity to avoid double. Let me rewrite link CSS:
```css
.link { stroke-opacity: .45; }
.link-dim { stroke-opacity: .08; }
.link-hi { stroke-opacity: 1; }
```
And in JS classed accordingly. Good. Update.

44. node base: no opacity set. `.dim circle { opacity:.28 }` and `.dim text { opacity:.28 }`. `.dim .lab { opacity:.15 }`. On clear remove dim → opacity auto 1. Good. But the highlighted node should be full; it's not dim (nb has self). Good.

45. hovered node glow: `nodeSel.select("circle").classed("glow", d2=>d2.id===d.id)` adds glow filter. Good. But hovered node also not dim. Good.

Let me now also ensure I handle the case `event.sourceEvent` undefined (some events). Guard with &&. Done.

46. Re-examine drag subject removal: I had `.subject(...)`. Remove it. Then dragged uses absolute event.x. Good.

Let me rewrite the file with all fixes. I'll regenerate the whole file to be safe and clean.

Let me also reduce the kbd weirdness.

Also, the `svg.on("wheel",...)` broken line and `scrolled` function removed.

Also the `defs` radialGradient uses selected stops; fine.

Let me also make sure `d3.select("main").append("svg")` — main exists in DOM (parsed before script). Since script is at end of body (after main), main exists. Good. Actually the script tag is after `<main>`. Good. But `#legend` and `#tooltip` and `.hint` exist before script too. Good.

Let me also double check `nodeSel` is accessible in `drag()` and `highlightNeighbors` — yes, top-level const defined before use at runtime.

Now, ordering issue: I define `nodeSel` via chain that `.call(drag())` at creation. `drag()` references `nodeSel` and `simulation` inside handlers (runtime). Fine. But `drag()` as a function declaration is hoisted; calling it during `nodeSel` chain is fine; the returned behavior is stored. Handlers run later. Good.

Also `linkSel` used in `zoomed`/`highlightNeighbors` — defined before simulation? I define linkSel before simulation. Good. hovered/zoomed use linkSel at runtime. Fine.

Let me also ensure I set link stroke after simulation creation. I'll place link attr setting right after simulation const.

Let me rewrite cleanly now.

Also reconsider charge/collide: with 40 nodes and clusters, forceCollide radius COLLIDE+2 = 20. Nodes base r 11, so collide ~20 leaves small gaps. Good. charge -280 spreads. link distance 90. cluster pull 0.26. Should form nice clusters. Might be a bit tight; fine.

Let me write final file.

Also, I realize the background rect fill `#0d1117` equals body; stage has no background; empty space shows bg. Good.

Let me also add a subtle grid/axis? Not needed.

Let me write.

Also need to make sure `viewBox` and `pointer-events` on svg: I set `pointer-events` all on svg. The rect background covers; good. Nodes clickable.

One more: when zooming with wheel, d3-zoom calls preventDefault on wheel by default (yes, `zoom.wheelEnabled` true and it does `event.preventDefault()` for wheel? Actually d3-zoom's wheel handler calls `event.preventDefault()` when the wheel delta would change scale and it's inside the viewport). Fine. Page won't scroll.

Also touch pinch zoom works via d3-zoom touch support. Good.

Let me finalize. I'll rewrite the file entirely.

Also fix `nodeSel.append("text").attr("dy", -(BASE_R+6))` — sets label offset above circle in node local coords (before zoom scale correction of font-size). dy in user units = -(BASE_R+6) = -17. That's in sim units (node g local). Good, label sits above circle. Under zoom the text scales (font-size scaled by 1/k) so label stays readable. dy stays -17 in sim units → under zoom the label's distance in screen = 17*k pixels, growing when zoomed in. Slightly grows but acceptable. Could scale dy too but fine.

Now write final.

I noticed a typo: `color: "#b07aa1" ]` — there's a stray `]` after the color. Let me check the clusters array. I wrote:

```
{ id: 4, name: "DevOps",    color: "#b07aa1" ]
```

That `]` is wrong — should be `}`. This is a syntax error. Let me fix it.

Let me view that line.

Now let me do a syntax check by extracting the JS and parsing it. I can use node to check syntax. Let me extract the script content (the part between the script tags in the body) and parse with node --check. Actually there are two script blocks: the one loading d3, and the inline one. The inline JS uses d3 global (browser). For syntax checking I can strip it and node --check, but it references d3, document, etc., which node won't have — but --check only checks syntax, not runtime. Let me extract the inline script and run `node --check`.

Let me extract using grep/sed. Actually easier: use a quick node script to read the file, pull the inline script, and check syntax.

The regex matched the FIRST `<script>...</script>` which is `<script src="d3.min.js"></script>` — that has no content, but my regex `<script>(([\s\S])*?)<\/script>` with non-greedy would match the shortest, i.e., the d3 loader script tag `<script src="d3.min.js"></script>` → content = "" (empty), and the match group captures src? Actually `<script src="d3.min.js"></script>` — the regex `<script>...</script>` would match from `<script src="d3.min.js">` to `</script>`? The regex is `<script>((.*))</script>` — `<script>` literal must match exactly `<script>` but the loader is `<script src="d3.min.js">` which starts with `<script src` not `<script>`. So the regex `<script>` wouldn't match the loader line (it requires `<script>` followed by `>`). So it matches the inline script. But the error is at line 21 `];` unexpected `]`. That's the clusters array — meaning my edit didn't apply? But I did fix it. Let me check: the extracted content line 21 is `];`. Let me look at the extracted file. Maybe the regex captured the loader as content? Let me check /tmp/_check.js.

Actually wait, the regex `<script>` requires literal `<script>`. The loader line `<script src="d3.min.js"></script>` contains `<script src` — does `<script>` match a substring? `<script>` is 8 chars `<script>`. The loader has `<script src...` so after `<script` comes a space, not `>`. So `<script>` (with closing `>`) does NOT match within `<script src=...>`. Good. So regex matched the inline script block. But the error points at `];` after the clusters array — i.e., the clusters array still has the `]`. Did my edit not save? Let me re-read the file around clusters.

Wait, maybe the extracted _check.js includes MORE than the inline script — the regex matched from the first `<script>` (inline one) but `(([\s\S])*?)` non-greedy to the first `</script>`. The inline script has no nested `</script>`, so it captures the whole inline script up to `</script>`. That ends with `}</script>`. Should be fine. Line 21 of _check.js — but the inline script starts after `<script>` on its own line. The file structure: the inline script is preceded by blank lines etc. The extraction captured from `<script>` (the inline). Line 1 of _check.js = first line of inline script content. Line 21 = `];`?? The clusters array ends with `];` on its 7th line. So if _check.js line 21 is `];`, that's odd — only if extraction includes other content before. Hmm, maybe the regex actually matched the loader `<script src=...>`? No. Let me just read _check.js head.

The edit is applied. The clusters array is fine now. So why the syntax error at `];`? The `];` at line 21 of _check.js — line 21 is `];` after the DevOps array. That's valid JS (`];` closes members array destructuring... no wait). Let me look: line 21 is `];` which is the end of the `members = { ... }` — no. Let me recount _check.js lines:
1 "use strict"
2 blank
3 // comment
4 // comment
5 // comment
6 const clusters = [
7 {id0},
8 {id1},
9 {id2},
10 {id3},
11 {id4 DevOps}
12 ];
13 blank
14 const members = {
15 Platform: [
16 ...
17 ...
18 ...
19 ...
20 DevOps: [...]
21 ];
That `];` on line 21 closes... wait the members is `{ }` not `[ ]`. So `];` would be the end of the DevTools array? No. Let me recount: members = { Platform:[...8 items], ... } — actually each cluster's array literal. The DevOps array spans one line (line 20). Then line 21 `];`?? That doesn't match — members object should close with `}`.

Hmm wait, maybe extraction offset is off because the FIRST `<script>` matched is actually the loader `<script src="d3.min.js"></script>`? But I argued it wouldn't match. Yet the extracted content starts with `"use strict";` which is the inline script's first line — so it matched the inline script correctly. Good.

So why `];` at line 21? Let me actually look at lines 14-21 of _check.js.

The members object is closed with `];` instead of `}`. That's the bug. In my source, I wrote:

```
const members = {
  Platform:  [...],
  ...
  DevOps:    [...]
];
```

I mistakenly closed the object literal with `]` instead of `}`. Let me fix that.

Syntax is OK now. Let me also do a runtime smoke test by simulating the critical data operations in node without d3 (since d3 isn't a CommonJS module in node directly). I can test the data generation logic and adjacency and neighbor highlight logic. But the drag/zoom/ticked require d3 and DOM. 

Let me at least verify the data generation produces 40 nodes and the links count, and adjacency works. I can extract just the data portion. But simpler: trust it. However, let me double-check a couple of logic concerns:

1. In `highlightNeighbors`, `nb = neighborSet(d.id)` returns the Set of neighbor ids (not including self). `nb.add(d.id)` adds self. Then for links: `link-dim` if `!nb.has(l.source.id) || !nb.has(l.target.id)` — note operator precedence: `!nb.has(...) || !nb.has(...)` → (link dimmed if either endpoint not in neighbor set). `link-hi` if `nb.has(l.source.id) && nb.has(l.target.id)` (both endpoints are the hovered node or its neighbors). Good. But there's a subtle issue: links NOT involving the hovered node but connecting two neighbors would be highlighted too (both endpoints neighbors). That's a nice "show connections among neighbors" effect. Fine.

But `link-dim` for a link where source is hovered and target is not a neighbor: dimmed (opacity .09). Good. And `link-hi` for link where both endpoints are neighbors (including the hovered) → full. Good. A link where both endpoints are non-neighbors and non-hovered → `link-dim` true (dimmed), `link-hi` false. But `link-dim` CSS overrides `link-hi`? Both classes on same element: link-dim opacity .09, link-hi opacity 1. CSS specificity equal (both single class) → last declared wins. In CSS I declared `.link-hi { stroke-opacity: 1 }` after `.link-dim`. So link-hi wins. But a link can't be both link-dim and link-hi simultaneously here: link-hi requires both in nb; link-dim requires at least one NOT in nb. They're mutually exclusive. Good. So no conflict.

2. `nodeSel.classed("dim", n => !nb.has(n.id))` — dim nodes not in nb. The hovered node and neighbors stay full. Good.

3. The `nodeSel.select("circle").classed("glow", n => n.id === d.id)` — glow only on hovered node's circle. Good. But after drag, d.hovered set true then false; glow via this is separate (only on hover). Fine.

4. Potential issue: when hovering, `nodeSel.filter(n => n === d).raise()` not called on hover (only on drag). That's fine; hover doesn't need raise. But the dimmed siblings behind might cover? nodes are circles radius ~11, labels above; z-order by DOM. Hovered node stays in place; fine.

5. `refreshHoverScale` called on hover/mousemove? Only on mouseover and mouseout. On mousemove while hovering, d.hovered stays true so no change needed. Good. But if zoom happens while hovering a node, zoomed() sets r using d.hovered (correct). Good.

6. The `d3.pointer(event, svg.node())` unused var `x,y` — harmless but let me remove to keep clean. Actually it's fine; minor. I'll leave or remove. Let me remove to avoid lint noise. Minor; I'll remove.

7. `svg.on("mousedown",...)` sets panning class on any mousedown on svg including when a node is being dragged? When dragging a node, the pointerdown on the node is stopped from propagating (stopPropagation) → svg mousedown won't fire. Good. So panning class only on empty-area mousedown. On mouseup → false. But during a node drag, mouseup happens on the circle (target), bubbles; svg's mouseup? The mousedown was stopped, but mouseup is a separate event not stopped. mouseup on circle bubbles to svg → svg mouseup fires → panning false (already false). Fine. Actually during node drag, is panning false? Yes. Fine.

8. Does `svg.classed("grab",true)` and CSS `.grab {cursor:grab}` — when panning class added `.panning {cursor:grabbing}`. Good.

9. Initial `zoomed({transform: d3.zoomIdentity})` sets stage transform to identity (none), scales to base. Good. But I also called `svg.call(zoom)` which may set an initial transform? d3.zoom doesn't auto-transform until user interacts. So stage stays at identity until zoom. Good.

10. `simulation.alpha(0.6).restart()` — starts. On tick, positions set. Good. Links initially have x1 etc from first tick. Good.

11. `nodeSel.append("circle").attr("r", BASE_R)` then zoomed sets r = BASE_R/k. At init k=1 → BASE_R. Good. stroke set via attr at creation `d => d3.rgb(colorOf(d)).brighter(1.3)` — colorOf(d)=hex, d3.rgb parses, .brighter returns rgb string? d3.rgb returns an rgb object; setting as attr stroke expects a string; d3 will serialize? Actually `.attr("stroke", rgbObj)` — d3 coerces via String()? An rgb object toString() returns "rgb(r,g,b)". Should work. Good. Then refreshed stroke-width via JS. stroke color stays. On hover, glow filter applied. Good.

12. Link stroke set after simulation: `linkSel.attr("stroke", d => colorOf(d.source))` — d.source is node object with group. Good. stroke-width LINK_W (then zoomed divides by k). Good.

13. Force collide radius COLLIDE+2 = 22, while BASE_R=11; collide prevents overlap with some breathing. But nodes of radius 11 collide at 22 apart — they won't overlap. Good. But links distance 92 may fight collide; fine.

14. `forceLink` default distance 30, I set 92. With 40 nodes in clusters, links ~92 apart, clusters spread via centers. Good.

15. One concern: `d3.forceLink(graph.links).id(d=>d.id)` mutates graph.links entries' source/target from strings to node objects. This happens in forceLink.initialize called by simulation.initialize (during simulation creation). After `const simulation = ...`, links are objects. I set link stroke after that. Good ordering: I create simulation (links initialized), THEN set linkSel stroke. In code: `const simulation = d3.forceSimulation(...)` then `.force("link", d3.forceLink(graph.links)...)` — forceLink is added during simulation creation; its initialize runs during simulation's initialize (which runs at creation end? Actually simulation.initialize is called at the end of the constructor). So after the `const simulation = ...` line, links are initialized. Then my `linkSel.attr("stroke",...)` runs. Good.

Wait, does forceLink.initialize get called when added via .force()? `.force(name, force)` calls force.initialize?.initialize(simulation) if defined. forceLink defines initialize. So yes, during .force("link",...) the initialize runs, setting link.source/target to nodes. But at that moment, does the simulation's nodes have .index set? forceLink.initialize uses simulation.nodes() to map ids. The nodes are set in the simulation constructor before forces? Let me recall: d3.forceSimulation constructor: stores nodes, calls initialize() after setting forces? The flow: `d3.forceSimulation = function(nodes) { ... var simulation = create(); simulation.nodes(nodes); ... }` and `simulation.nodes` sets `_nodes` and calls `force.initialize` for each force? Actually `nodes()` calls initialize() which iterates forces and calls force.initialize(simulation). And forces added later via .force() also call force.initialize immediately if simulation already initialized. 

In my chain I do `d3.forceSimulation(graph.nodes).force("link", ...)`. The constructor calls nodes() which initializes forces already added (none yet). Then .force("link",...) adds force and calls force.initialize. At that point nodes are set, so forceLink maps ids→nodes correctly. Good. After the whole `const simulation = ...` line (which is one chained expression), links are initialized. Then linkSel.attr stroke. 

16. The `nodeSel` selection includes the drag behavior already applied; later `nodeSel.on("mouseover"...)` adds handlers. Good. And `nodeSel.classed("dim",...)` works on the g. Good.

17. `tick` updates link coords and node transforms. Good. Labels move with node g transform. Good.

18. Tooltip uses `event.pageX`/`pageY` for position — page-relative; since svg is positioned in main, pageX = viewport x. Good for positioning tooltip near cursor. Fine.

19. Unused `between`, `randBelow` removed earlier? I removed them in rewrite? Let me check — in the rewrite I removed the between/randBelow usage. Yes I define only mulberry32 and rng. Good. The `x` from d3.pointer unused — minor; remove.

Let me remove the unused pointer line to be tidy.

20. Check the CSS `.node circle` no `fill`? I set fill via attr `url(#nodeGrad)`. CSS `.node circle { fill: url(#nodeGrad) }` — wait in my rewrite CSS `.node circle { fill: url(#nodeGrad); stroke:#fff; cursor:grab }`. But in JS I also set `attr("fill", ... )`? In the rewrite, nodeSel.append("circle").attr("r",BASE_R).attr("stroke",...) — I did NOT set fill attr; CSS sets fill to url(#nodeGrad). Good, consistent. stroke via attr (cluster color) plus CSS stroke:#fff would conflict? CSS `.node circle { stroke: #fff }` sets white stroke for ALL nodes, but JS sets stroke attr per node cluster color. CSS vs presentation attribute: CSS wins (stroke:#fff). So all strokes would be white, losing cluster color! 

Hmm. I want node stroke = cluster color (brighter). The CSS rule `stroke: #fff` overrides. So I must NOT set stroke in CSS, or use a different property. Let me remove `stroke: #fff` from CSS `.node circle` and rely on the attr set in JS. Actually wait, I want a consistent stroke. Let me set stroke in JS per node and remove CSS stroke. But the glow/hover? stroke-width via JS. Let me remove `stroke: #fff` from CSS. 

Actually, having node stroke = cluster color bright is nice. Let me set in JS: `.attr("stroke", d => d3.rgb(colorOf(d)).brighter(1.5))`. And remove CSS stroke. Let me check the CSS in rewrite: `.node circle { fill: url(#nodeGrad); stroke: #fff; cursor: grab; }`. I'll change to remove stroke. 

But the nodeGrad fill is white-ish (light glow). Stroke cluster-color bright makes a nice colored halo. Good. Let me update.

Let me also reconsider: I set `attr("stroke-width",...)` never at creation; only via refreshHoverScale/zoomed. At init, zoomed() called with identity sets stroke-width = BASE_STROKE/k=2.6. Good. So creation doesn't need stroke-width. Good.

Let me make these edits:
- CSS: remove `stroke: #fff;` from `.node circle`.
- Remove unused `const [x,y]=...` line in tooltip mouseover (or keep harmless). I'll remove for cleanliness.

21. Also CSS `.node:hover circle` — I removed the stroke-width hover rule in rewrite (I don't see it). Good. But is there a hover stroke? No, JS handles. Good. But CSS has no hover styling for circle except glow (via JS class). Fine. Actually I'd like a hover cue; the glow + radius growth (via JS) provides that. Good.

22. `.dim circle { opacity:.28 }` and `.dim .lab { opacity:.15 }`. When dimmed, circle opacity .28. The highlighted node not dim → full. Good.

23. Check `.link` CSS stroke-opacity .45; on dim `.link-dim` stroke-opacity .09; `.link-hi` stroke-opacity 1. Good.

24. The `defs` filter glow applied to circle via `.glow circle { filter: url(#glow) }`. Good. The glow blurs the white-ish fill. Fine.

Let me apply the two edits.

25. Also verify: `nodeSel.select("circle")` in highlight adds class glow — but nodeSel.select returns the circle; classed("glow") toggles filter. Good. But note `.glow circle { filter: url(#glow) }` requires the g to have class glow (`n.id===d.id` adds glow to nodeSel.select("circle") — the circle itself, not the g!). Wait `nodeSel.select("circle").classed("glow", n => n.id === d.id)` adds class "glow" to the CIRCLE element, not the g. CSS is `.glow circle` (descendant: g.glow circle) — that targets a circle whose ancestor g has class glow. But I'm putting glow on the circle directly, not the g. Mismatch! 

I need either: add class "glow" to the node g (`.node.glow circle`), or change CSS to `.glow { filter... }` on circle directly. Let me add the class to the node g instead, and CSS `.node.glow circle { filter: url(#glow) }`. Or simpler: set the filter attr directly via JS on the circle: `.attr("filter", ... )`. 

Let me change approach: in highlight, do `nodeSel.classed("glow", n => n.id === d.id)` (adds glow class to the g), and CSS `.node.glow circle { filter: url(#glow) }`. And clearHighlight removes glow class from nodeSel. That's cleaner. Let me update both highlight/clear and CSS.

Actually currently I have:
- highlightNeighbors: `nodeSel.select("circle").classed("glow", n => n.id === d.id);`
- clearHighlight: `nodeSel.select("circle").classed("glow", false);`
- CSS: `.glow circle { filter: url(#glow) }`

The `.glow` class is on the circle; CSS `.glow circle` would require a descendant circle of a .glow element — but the circle itself has .glow, and `.glow circle` selects a circle INSIDE .glow — the circle has no child circle. So filter never applies. Bug.

Fix: change CSS to `.glow { filter: url(#glow) }` (apply filter to the element with class glow). But `.glow` class is on the circle → filter on circle. Good. But `.glow` might also match other elements? Only circles get glow class. Fine. But also `.dim` circle uses opacity; a dimmed circle could also have glow if it's the hovered self — but hovered self isn't dim. Fine.

Alternatively add glow to node g and CSS `.node.glow circle`. I'll just change CSS `.glow circle` → `.glow { filter: url(#glow) }` and keep adding glow class to the circle. That's minimal. But wait, the circle already has filter? No. Setting filter via CSS `.glow` on the circle element. Good.

Hold on, but the hover growth uses d.hovered to scale r; and glow via class. Both fine. Let me change CSS `.glow circle { filter: url(#glow) }` to `.glow { filter: url(#glow) }`.

Hmm, but actually adding glow class to the circle and CSS `.glow` — the circle is the element with class. `.glow { filter }` applies. Good.

Let me make these edits:
1. CSS `.node circle`: remove `stroke: #fff;` (so cluster stroke color from attr shows). Keep `cursor: grab`.
   Actually, do I still want a default stroke? JS sets stroke per node. Good. Remove CSS stroke.
2. CSS `.glow circle` → `.glow`.
3. Remove unused pointer line.

Let me also double check `fill: url(#nodeGrad)` in CSS and not in JS — I didn't set fill attr, CSS does. Good. But on hover dim, `.dim circle { opacity:.28 }` — opacity affects fill. Fine.

Let me also reconsider node stroke width: CSS no longer sets stroke-width; JS sets via attr (scaled). At creation I didn't set stroke-width attr; zoomed() at init sets it. Good. But `nodeSel.append("circle").attr("r",BASE_R)` only sets r; stroke-width set later by zoomed init. Fine.

Let me apply edits.

Actually, also the CSS originally `.node circle { ... stroke: #fff; ... }` — let me view exact current CSS to edit.

Let me make the fixes:

1. Remove `stroke: #fff;` from `.node circle` so the per-node cluster stroke attr shows.
2. Change `.glow circle { filter: url(#glow) }` → `.glow { filter: url(#glow) }` (since glow class is on the circle).
3. Remove unused `const [x, y] = d3.pointer(...)` line.
4. In highlightNeighbors/clearHighlight, ensure glow class is added to circle (already is). With CSS `.glow` (not `.glow circle`), applying to circle works.

Let me view lines 64-72 and 410-420.