diff --git a/plans/001-fix-cancel-load-all-cancelfn.md b/plans/001-fix-cancel-load-all-cancelfn.md
new file mode 100644
index 0000000000..53c46be67d
--- /dev/null
+++ b/plans/001-fix-cancel-load-all-cancelfn.md
@@ -0,0 +1,169 @@
+# Plan 001: Make `cancelLoadAll()` actually cancel in-flight loads (`cancel` → `cancelFn`)
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- packages/core/src/loaders/imageLoader.ts`
+> If the file changed since this plan was written, compare the "Current state"
+> excerpts against the live code before proceeding; on a mismatch, treat it as
+> a STOP condition.
+
+## Status
+
+- **Priority**: P1
+- **Effort**: S
+- **Risk**: LOW
+- **Depends on**: none
+- **Category**: bug
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+`cancelLoadAll()` is the public API applications call to abort every queued and
+in-flight image/volume load (e.g. when tearing down a study). It calls
+`loadObject.cancel()`, but the load-object contract only defines `cancelFn`.
+So the moment it finds any in-flight load, it throws `TypeError:
+loadObject.cancel is not a function`, which aborts the surrounding loop and
+leaves the remaining in-flight requests un-cancelled. Every other call site in
+the codebase uses `cancelFn`.
+
+## Current state
+
+- `packages/core/src/loaders/imageLoader.ts` — image loading API; `cancelLoadAll` is near the bottom (~line 650–680).
+- `packages/core/src/types/ILoadObject.ts` — the contract: both `IImageLoadObject` and `IVolumeLoadObject` declare `cancelFn?: () => void` and `decache?: () => void`; there is **no** `cancel` property.
+
+The broken code (`packages/core/src/loaders/imageLoader.ts:662-673`):
+
+```ts
+      if (imageId) {
+        loadObject = cache.getImageLoadObject(imageId);
+      } else if (volumeId) {
+        loadObject = cache.getVolumeLoadObject(volumeId);
+      }
+      if (loadObject) {
+        loadObject.cancel();
+      }
+```
+
+The correct pattern, from `cancelLoadImage` in the same file
+(`packages/core/src/loaders/imageLoader.ts:622-626`):
+
+```ts
+  const imageLoadObject = cache.getImageLoadObject(imageId);
+
+  if (imageLoadObject) {
+    imageLoadObject.cancelFn();
+```
+
+Note that `cancelFn` is optional on the type; `cache.ts` guards it
+(`if (imageLoadObject?.cancelFn) { imageLoadObject.cancelFn(); }` at
+`packages/core/src/cache/cache.ts:178-179`). Match the guarded style.
+
+Repo conventions: TypeScript, no semicolonless style, prettier-formatted.
+Unit tests are jest files named `*.jest.js` under `packages/core/test/`
+(karma tests are `*_test.js` in the same directory — do not add a karma test
+here).
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Typecheck/build core | `pnpm --filter @cornerstonejs/core run build:esm` | exit 0 |
+| Unit tests (all) | `pnpm run test:unit:no-coverage` | all pass |
+| Unit test (this file) | `pnpm run test:unit:no-coverage -- cancelLoadAll` | new tests pass |
+| Lint | `pnpm run lint` | exit 0 |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `packages/core/src/loaders/imageLoader.ts` (the `cancelLoadAll` function only)
+- `packages/core/test/imageLoader_cancelLoadAll.jest.js` (create)
+
+**Out of scope** (do NOT touch, even though they look related):
+- `packages/core/src/types/ILoadObject.ts` — do not add a `cancel` alias; the contract is correct, the call site is wrong.
+- `packages/core/src/cache/cache.ts` — its cancel paths are already correct.
+- The `// TODO: Clear retrieval and decoding queues as well` in `cancelLoadAll` — known deferred work, not this plan.
+
+## Git workflow
+
+- Branch: `advisor/001-fix-cancel-load-all`
+- Commit message style: conventional commits, e.g. `fix(core): use cancelFn in cancelLoadAll so in-flight loads are cancelled`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Fix the call
+
+In `cancelLoadAll` in `packages/core/src/loaders/imageLoader.ts`, replace:
+
+```ts
+      if (loadObject) {
+        loadObject.cancel();
+      }
+```
+
+with:
+
+```ts
+      if (loadObject?.cancelFn) {
+        loadObject.cancelFn();
+      }
+```
+
+**Verify**: `pnpm --filter @cornerstonejs/core run build:esm` → exit 0.
+
+### Step 2: Add a regression test
+
+Create `packages/core/test/imageLoader_cancelLoadAll.jest.js`. Model the file
+structure (imports, module reset) on an existing jest test such as
+`packages/core/test/stackViewport_node_render.jest.js` (read it first for the
+import style; you likely only need `imageLoader`, `imageLoadPoolManager`, and
+`cache` from `packages/core/src`).
+
+Test cases:
+1. Register a fake image loader whose load object exposes a jest.fn `cancelFn`,
+   start a load via `imageLoader.loadAndCacheImage(...)` so the load object is
+   in the cache, call `cancelLoadAll()`, and assert `cancelFn` was called and
+   no exception was thrown.
+2. A load object **without** `cancelFn` (property absent): `cancelLoadAll()`
+   must not throw.
+
+If wiring a real request through `imageLoadPoolManager` proves too indirect,
+it is acceptable to test at the cache level: put a load object via
+`cache.putImageLoadObject(imageId, { promise, cancelFn })`, enqueue a request
+with `additionalDetails.imageId`, then call `cancelLoadAll()`.
+
+**Verify**: `pnpm run test:unit:no-coverage -- cancelLoadAll` → the new tests pass.
+
+## Test plan
+
+Covered by Step 2: happy path (cancelFn invoked), and the guard path (no
+cancelFn present, no throw). The bug itself (old code throwing `TypeError`) is
+demonstrated by test 1 failing if the fix is reverted.
+
+## Done criteria
+
+- [ ] `grep -n "loadObject.cancel()" packages/core/src/loaders/imageLoader.ts` returns no matches
+- [ ] `pnpm --filter @cornerstonejs/core run build:esm` exits 0
+- [ ] `pnpm run test:unit:no-coverage -- cancelLoadAll` passes with 2 new tests
+- [ ] `pnpm run lint` exits 0
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- `cancelLoadAll` in the live file does not contain `loadObject.cancel();` (drift).
+- A `cancel` property actually exists on `IImageLoadObject`/`IVolumeLoadObject` in `packages/core/src/types/ILoadObject.ts` (would mean the contract changed and this plan's premise is wrong).
+- The jest test cannot import `packages/core/src` modules at all (project config issue beyond this plan).
+
+## Maintenance notes
+
+- Reviewer should confirm only the one call site changed and the guard style matches `cache.ts:178`.
+- Deferred (pre-existing TODO in the same function): also cancelling retrieval/decoding queues, and calling `decache()` on cancelled entries — worth a follow-up finding if cancellation memory usage matters.
diff --git a/plans/002-fix-get-volume-containing-image-id.md b/plans/002-fix-get-volume-containing-image-id.md
new file mode 100644
index 0000000000..86101fc172
--- /dev/null
+++ b/plans/002-fix-get-volume-containing-image-id.md
@@ -0,0 +1,174 @@
+# Plan 002: Fix `getVolumeContainingImageId` aborting its search on the first empty/unloaded volume
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- packages/core/src/cache/cache.ts`
+> If the file changed since this plan was written, compare the "Current state"
+> excerpts against the live code before proceeding; on a mismatch, treat it as
+> a STOP condition.
+
+## Status
+
+- **Priority**: P1
+- **Effort**: S
+- **Risk**: LOW
+- **Depends on**: none
+- **Category**: bug
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+`cache.getVolumeContainingImageId(imageId)` answers "which cached volume owns
+this image?" — used by tools and segmentation code to resolve an image back to
+its volume. The lookup loop uses `return` where it means `continue`: the first
+volume that is missing or has zero `imageIds` ends the whole search, so a
+matching volume iterated later is never found. It also destructures `volume`
+from the cached entry without a guard — a volume that is cached but not yet
+loaded (`volume === undefined`) makes the function throw `TypeError` instead of
+skipping. Both failure modes only appear with 2+ volumes in the cache, which is
+exactly the MPR/fusion scenario.
+
+## Current state
+
+- `packages/core/src/cache/cache.ts` — the singleton cache class; `getVolumeContainingImageId` at ~lines 615–642.
+
+The broken loop (`packages/core/src/cache/cache.ts:622-641`):
+
+```ts
+    for (const volumeId of volumeIds) {
+      const cachedVolume = this._volumeCache.get(volumeId);
+
+      if (!cachedVolume) {
+        return;
+      }
+
+      const { volume } = cachedVolume;
+
+      if (!volume.imageIds.length) {
+        return;
+      }
+
+      const imageIdIndex = volume.getImageURIIndex(imageIdToUse);
+
+      if (imageIdIndex > -1) {
+        return { volume, imageIdIndex };
+      }
+    }
+```
+
+Repo conventions: TypeScript, prettier-formatted. Jest unit tests live in
+`packages/core/test/*.jest.js` (karma tests are `*_test.js` — don't add karma).
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Typecheck/build core | `pnpm --filter @cornerstonejs/core run build:esm` | exit 0 |
+| Unit test (this fix) | `pnpm run test:unit:no-coverage -- getVolumeContainingImageId` | new tests pass |
+| Lint | `pnpm run lint` | exit 0 |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `packages/core/src/cache/cache.ts` (only the `getVolumeContainingImageId` method)
+- `packages/core/test/cache_getVolumeContainingImageId.jest.js` (create)
+
+**Out of scope** (do NOT touch, even though they look related):
+- Any other method of `cache.ts` (eviction, purge, size accounting — plan 007 covers geometry sizing separately).
+- `getImageURIIndex` / `imageIdToURI` implementations.
+
+## Git workflow
+
+- Branch: `advisor/002-fix-get-volume-containing-image-id`
+- Commit message style: conventional commits, e.g. `fix(core): continue past empty or unloaded volumes in getVolumeContainingImageId`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Replace the early returns with skips and guard the unloaded case
+
+Target shape:
+
+```ts
+    for (const volumeId of volumeIds) {
+      const cachedVolume = this._volumeCache.get(volumeId);
+
+      if (!cachedVolume) {
+        continue;
+      }
+
+      const { volume } = cachedVolume;
+
+      if (!volume?.imageIds?.length) {
+        continue;
+      }
+
+      const imageIdIndex = volume.getImageURIIndex(imageIdToUse);
+
+      if (imageIdIndex > -1) {
+        return { volume, imageIdIndex };
+      }
+    }
+```
+
+**Verify**: `pnpm --filter @cornerstonejs/core run build:esm` → exit 0.
+
+### Step 2: Add regression tests
+
+Create `packages/core/test/cache_getVolumeContainingImageId.jest.js`. Import
+`cache` from `packages/core/src/cache/cache` (or via the package index — match
+the import style of an existing jest test in `packages/core/test/`). You can
+seed `_volumeCache` through the public API (`cache.putVolumeLoadObject`) or,
+if that requires too much volume scaffolding, construct minimal fake volume
+objects with `imageIds` and a `getImageURIIndex(uri)` method and insert them
+via `putVolumeLoadObject(volumeId, { promise: Promise.resolve(fake) })`
+followed by awaiting the promise — read how `putVolumeLoadObject` stores
+`volume` on the cached entry in `cache.ts` before choosing the seeding approach.
+
+Cases:
+1. Two volumes cached; the FIRST has `imageIds: []`, the SECOND contains the
+   target imageId → function returns the second volume + index (fails on the
+   old code, which returned `undefined`).
+2. First cached entry has no `volume` yet (load object whose promise has not
+   resolved) → function does not throw and still finds the match in the
+   second volume.
+3. No volume contains the imageId → returns `undefined`.
+
+Call `cache.purgeCache()` (and purge volumes) in `afterEach` so state doesn't
+leak between tests — `cache` is a singleton.
+
+**Verify**: `pnpm run test:unit:no-coverage -- getVolumeContainingImageId` → 3 new tests pass.
+
+## Test plan
+
+Covered in Step 2 (regression, unloaded-volume guard, miss path). Pattern
+file: any existing `packages/core/test/*.jest.js`.
+
+## Done criteria
+
+- [ ] In `getVolumeContainingImageId`, `grep -A3 'if (!cachedVolume)'` shows `continue`, not `return`
+- [ ] `pnpm --filter @cornerstonejs/core run build:esm` exits 0
+- [ ] `pnpm run test:unit:no-coverage -- getVolumeContainingImageId` passes (3 new tests)
+- [ ] `pnpm run lint` exits 0
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- The live method no longer matches the excerpt (drift).
+- You find call sites that *depend* on the early-return behavior (search
+  `getVolumeContainingImageId` usages first: `grep -rn getVolumeContainingImageId packages/*/src`); if any caller's comment/logic assumes "undefined means first volume was empty", report it.
+- Seeding the singleton cache in jest proves impossible without touching production code.
+
+## Maintenance notes
+
+- Reviewer: confirm the `volume?.imageIds?.length` guard — an unloaded volume must be skipped, not treated as a match failure for the whole cache.
+- Related but separate: geometry cache accounting bugs in the same file are handled by plan 007.
diff --git a/plans/003-fix-stackviewport-cpu-load-promise.md b/plans/003-fix-stackviewport-cpu-load-promise.md
new file mode 100644
index 0000000000..09d4831a19
--- /dev/null
+++ b/plans/003-fix-stackviewport-cpu-load-promise.md
@@ -0,0 +1,196 @@
+# Plan 003: Make StackViewport's CPU load promise always settle when a load is superseded by scrolling
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- packages/core/src/RenderingEngine/StackViewport.ts`
+> If the file changed since this plan was written, compare the "Current state"
+> excerpts against the live code before proceeding; on a mismatch, treat it as
+> a STOP condition.
+
+## Status
+
+- **Priority**: P1
+- **Effort**: S
+- **Risk**: LOW
+- **Depends on**: none
+- **Category**: bug
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+On the CPU rendering path, `StackViewport.setImageIdIndex()` returns a promise
+that is awaited internally and by applications. When the user scrolls to a new
+image while an older image is still loading, the older load's success callback
+detects it was superseded and returns early — **without resolving or rejecting
+the promise**. Every `await viewport.setImageIdIndex(...)` for a superseded
+load hangs forever, leaking pending promises and stalling any caller logic
+chained on it (scroll loops, prefetch orchestration, app-level `await`s).
+
+## Current state
+
+- `packages/core/src/RenderingEngine/StackViewport.ts` — the stack viewport; CPU load path `_loadAndDisplayImageCPU` at ~lines 2140–2270; `_setImageIdIndex` at ~2759+.
+
+The promise executor and the early return
+(`packages/core/src/RenderingEngine/StackViewport.ts:2140-2157`):
+
+```ts
+  private _loadAndDisplayImageCPU(
+    imageId: string,
+    imageIdIndex: number
+  ): Promise<string> {
+    return new Promise((resolve, reject) => {
+      // 1. Load the image using the Image Loader
+      function successCallback(
+        image: IImage,
+        imageIdIndex: number,
+        imageId: string
+      ) {
+        // Perform this check after the image has finished loading
+        // in case the user has already scrolled away to another image.
+        // In that case, do not render this image.
+        if (this.currentImageIdIndex !== imageIdIndex) {
+          return;
+        }
+```
+
+`resolve(imageId)` is only reached at the end of `successCallback`
+(`StackViewport.ts:2245`), and `reject(error)` in `errorCallback`
+(`StackViewport.ts:2263`). The supersession happens because `_setImageIdIndex`
+sets `this.currentImageIdIndex = imageIdIndex` **before** awaiting
+(`StackViewport.ts:2765`):
+
+```ts
+    // Update the state of the viewport to the new imageIdIndex;
+    this.currentImageIdIndex = imageIdIndex;
+    this.hasPixelSpacing = true;
+    this.viewportStatus = ViewportStatus.PRE_RENDER;
+    ...
+    const imageId = await this._loadAndDisplayImage(
+      this.imageIds[imageIdIndex],
+      imageIdIndex
+    );
+```
+
+Note `_loadAndDisplayImage` (`StackViewport.ts:2131-2138`) dispatches to
+`_loadAndDisplayImageCPU` or `_loadAndDisplayImageGPU` based on
+`this.useCPURendering`. **Check the GPU path too**: read
+`_loadAndDisplayImageGPU` and, if it contains the same
+early-return-without-resolve pattern, apply the identical fix there (same
+in-scope file).
+
+Repo conventions: TypeScript, prettier. Jest tests in
+`packages/core/test/*.jest.js`; there is an existing StackViewport jest test
+(`packages/core/test/stackViewport_node_render.jest.js`) to use as scaffolding
+reference for constructing a viewport in tests.
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Typecheck/build core | `pnpm --filter @cornerstonejs/core run build:esm` | exit 0 |
+| Unit test | `pnpm run test:unit:no-coverage -- stackViewport` | all pass |
+| Lint | `pnpm run lint` | exit 0 |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `packages/core/src/RenderingEngine/StackViewport.ts` (only `_loadAndDisplayImageCPU`, and `_loadAndDisplayImageGPU` if it has the same pattern)
+- `packages/core/test/stackViewport_supersededLoad.jest.js` (create — only if viewport scaffolding from the existing node-render test makes this feasible; see Test plan)
+
+**Out of scope** (do NOT touch, even though they look related):
+- `_setImageIdIndex`'s ordering (setting `currentImageIdIndex` before awaiting is intentional — it is what makes supersession detectable). Do not "fix" by reordering; that changes scroll semantics.
+- The render/CPU fallback pipeline invoked inside `successCallback`.
+- `packages/core/src/RenderingEngine/helpers/cpuFallback/**`.
+
+## Git workflow
+
+- Branch: `advisor/003-fix-stackviewport-cpu-load-promise`
+- Commit message style: `fix(core): resolve superseded StackViewport CPU image loads instead of hanging`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Settle the promise in the superseded branch
+
+In `successCallback` inside `_loadAndDisplayImageCPU`, change:
+
+```ts
+        if (this.currentImageIdIndex !== imageIdIndex) {
+          return;
+        }
+```
+
+to resolve with the imageId that WAS requested (callers get a settled promise;
+resolving — not rejecting — is the right call because supersession is normal
+behavior during scrolling, not an error):
+
+```ts
+        if (this.currentImageIdIndex !== imageIdIndex) {
+          resolve(imageId);
+          return;
+        }
+```
+
+`resolve` is in scope: `successCallback` is a `function` declaration inside the
+`new Promise((resolve, reject) => { ... })` executor, and it is invoked with
+`.call(this, ...)` so `this` remains the viewport.
+
+**Verify**: `pnpm --filter @cornerstonejs/core run build:esm` → exit 0.
+
+### Step 2: Check and, if needed, fix the GPU path
+
+Read `_loadAndDisplayImageGPU` in the same file. If its success callback has
+the same `if (this.currentImageIdIndex !== imageIdIndex) { return; }` guard
+inside a promise executor without settling, apply the same one-line fix.
+If the GPU path uses a different mechanism (no unsettled early return), leave
+it untouched and note that in your report.
+
+**Verify**: `pnpm --filter @cornerstonejs/core run build:esm` → exit 0.
+
+### Step 3: Confirm no existing test depended on the hang
+
+**Verify**: `pnpm run test:unit:no-coverage -- stackViewport` → all pass.
+
+## Test plan
+
+Ideal test (attempt it, but see the escape hatch): in
+`packages/core/test/stackViewport_supersededLoad.jest.js`, scaffold a stack
+viewport following `packages/core/test/stackViewport_node_render.jest.js`,
+register a fake image loader with controllable resolution timing, call
+`setImageIdIndex(0)` (don't await), immediately call `setImageIdIndex(1)`,
+then resolve both fake loads and assert the first promise settles (use
+`Promise.race([firstPromise, timeout(2000)])` and assert the race is won by
+the promise, not the timeout).
+
+Escape hatch: if the existing node-render scaffolding cannot force the CPU
+path (`useCPURendering`) in jest, skip the new test file, rely on Step 3's
+suite, and state in your report that the fix is verified by build + review
+only. Do not invent a canvas/WebGL mock stack for this.
+
+## Done criteria
+
+- [ ] In `_loadAndDisplayImageCPU`, the superseded branch contains `resolve(imageId);` before `return;`
+- [ ] `pnpm --filter @cornerstonejs/core run build:esm` exits 0
+- [ ] `pnpm run test:unit:no-coverage -- stackViewport` passes
+- [ ] `pnpm run lint` exits 0
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- The excerpt no longer matches (drift).
+- `resolve` is NOT lexically in scope at the early-return site (would mean the promise structure changed).
+- You find call sites that intentionally rely on the promise never settling for superseded loads (search for comments near `setImageIdIndex` awaits in `packages/core/src` and `packages/tools/src`).
+
+## Maintenance notes
+
+- Reviewer: the choice to `resolve` (vs reject with a cancellation sentinel) means callers cannot distinguish "rendered" from "superseded" by the promise alone; they can compare `viewport.getCurrentImageId()` if they care. If a future caller needs the distinction, introduce a typed `SupersededError` — deferred deliberately.
+- If the GPU path has the same bug and was fixed in Step 2, mention both sites in the PR description.
diff --git a/plans/004-fix-videoviewport-disabled-handler.md b/plans/004-fix-videoviewport-disabled-handler.md
new file mode 100644
index 0000000000..09213c7c3d
--- /dev/null
+++ b/plans/004-fix-videoviewport-disabled-handler.md
@@ -0,0 +1,155 @@
+# Plan 004: Fix VideoViewport's unbound ELEMENT_DISABLED handler so teardown actually runs
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- packages/core/src/RenderingEngine/VideoViewport.ts`
+> If the file changed since this plan was written, compare the "Current state"
+> excerpts against the live code before proceeding; on a mismatch, treat it as
+> a STOP condition.
+
+## Status
+
+- **Priority**: P1
+- **Effort**: S
+- **Risk**: LOW
+- **Depends on**: none
+- **Category**: bug
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+`VideoViewport` registers `this.elementDisabledHandler` as a DOM event
+listener without binding it. When `ELEMENT_DISABLED` fires, `this` inside the
+handler is the **canvas element**, not the viewport, so
+`this.removeEventListeners()` is `undefined` and the handler throws. The
+consequences: the listener is never removed, the `<video>` element is never
+removed from the DOM, and the video keeps decoding (and potentially fetching)
+in the background after the viewport is disabled — a listener, DOM, and
+network/CPU resource leak on every video viewport teardown.
+
+## Current state
+
+- `packages/core/src/RenderingEngine/VideoViewport.ts` — video viewport; the constructor calls `this.addEventListeners()` at line 143.
+
+The buggy trio (`packages/core/src/RenderingEngine/VideoViewport.ts:151-168`):
+
+```ts
+  private addEventListeners() {
+    this.canvas.addEventListener(
+      EVENTS.ELEMENT_DISABLED,
+      this.elementDisabledHandler
+    );
+  }
+
+  private removeEventListeners() {
+    this.canvas.removeEventListener(
+      EVENTS.ELEMENT_DISABLED,
+      this.elementDisabledHandler
+    );
+  }
+
+  private elementDisabledHandler() {
+    this.removeEventListeners();
+    this.videoElement.remove();
+  }
+```
+
+`elementDisabledHandler` is a plain method — passed as a listener it loses
+`this`. The repo's established convention for this exact situation is arrow-
+function class fields; the same file already uses one elsewhere and so does
+`packages/tools/src/store/SynchronizerManager/Synchronizer.ts:307`
+(`private _onEvent = (evt: Event): void => {...}`). Match that convention.
+
+Also note the viewport has a `pause()` method (search `public async pause` in
+the same file) — teardown should pause the video before removing it so the
+media element stops decoding immediately.
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Typecheck/build core | `pnpm --filter @cornerstonejs/core run build:esm` | exit 0 |
+| Unit tests | `pnpm run test:unit:no-coverage` | all pass |
+| Lint | `pnpm run lint` | exit 0 |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `packages/core/src/RenderingEngine/VideoViewport.ts` (only `elementDisabledHandler` and, if needed, its two call sites in `addEventListeners`/`removeEventListeners`)
+
+**Out of scope** (do NOT touch, even though they look related):
+- The `seeked` listener add/remove pairs later in the file (lines ~370–430) — they use locally-scoped named functions and are correct.
+- `VideoViewport`'s public API and the `EVENTS.ELEMENT_DISABLED` dispatch site.
+- Whether the disabled event should be listened for on `this.canvas` vs `this.element` — leave the target as-is.
+
+## Git workflow
+
+- Branch: `advisor/004-fix-videoviewport-disabled-handler`
+- Commit message style: `fix(core): bind VideoViewport elementDisabledHandler so video teardown runs`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Convert the handler to an arrow-function class field and pause the video
+
+Replace the method with a class-field arrow function (keep it `private`, keep
+the same name so `addEventListeners`/`removeEventListeners` are unchanged):
+
+```ts
+  private elementDisabledHandler = () => {
+    this.pause();
+    this.removeEventListeners();
+    this.videoElement?.remove();
+  };
+```
+
+Check `pause()`'s signature first: if it is async, calling it without await
+here is fine (fire-and-forget teardown), but if it can throw synchronously
+when no video is loaded, guard with `this.videoElement &&` or a try/catch —
+read the method body and pick the minimal safe form.
+
+Class-field ordering: TypeScript initializes fields in declaration order
+against the constructor; since the handler only runs on events (never during
+construction), placing the field where the method currently sits is fine.
+
+**Verify**: `pnpm --filter @cornerstonejs/core run build:esm` → exit 0.
+
+### Step 2: Full unit suite
+
+**Verify**: `pnpm run test:unit:no-coverage` → all pass. Also `pnpm run lint` → exit 0.
+
+## Test plan
+
+No practical jest coverage exists for VideoViewport (it needs a real
+`<video>`/canvas stack); do not build one for this fix. Verification is
+build + suite + the mechanical nature of the change. If a karma test file for
+video viewports exists (`ls packages/core/test | grep -i video`), read it and
+add an assertion there only if it already constructs a VideoViewport.
+
+## Done criteria
+
+- [ ] `grep -n "private elementDisabledHandler = () =>" packages/core/src/RenderingEngine/VideoViewport.ts` matches
+- [ ] `pnpm --filter @cornerstonejs/core run build:esm` exits 0
+- [ ] `pnpm run test:unit:no-coverage` passes
+- [ ] `pnpm run lint` exits 0
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- The excerpt no longer matches (drift).
+- `pause()` does not exist on the class (search `pause` in the file) — then just bind the handler without the pause call and note it.
+- The build surfaces a field-initialization-order error (would indicate the class relies on method hoisting elsewhere).
+
+## Maintenance notes
+
+- Reviewer: confirm the handler is a class field (identity-stable), since `removeEventListeners` removes by reference.
+- The same unbound-method-as-listener pattern is worth grepping for in future reviews: `addEventListener(\n?.*this\.[a-zA-Z]+Handler\b` where the handler is declared as a plain method.
diff --git a/plans/005-fix-synchronizer-listener-leaks.md b/plans/005-fix-synchronizer-listener-leaks.md
new file mode 100644
index 0000000000..593ad7a166
--- /dev/null
+++ b/plans/005-fix-synchronizer-listener-leaks.md
@@ -0,0 +1,270 @@
+# Plan 005: Fix Synchronizer's mismatched add/removeEventListener references (two listener leaks)
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- packages/tools/src/store/SynchronizerManager/Synchronizer.ts`
+> If the file changed since this plan was written, compare the "Current state"
+> excerpts against the live code before proceeding; on a mismatch, treat it as
+> a STOP condition.
+
+## Status
+
+- **Priority**: P1
+- **Effort**: M
+- **Risk**: LOW
+- **Depends on**: none
+- **Category**: bug
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+`Synchronizer` (camera sync, VOI sync, slice sync across viewports) has two
+independent listener-management bugs, both of the same species: the function
+reference passed to `removeEventListener` is not the one passed to
+`addEventListener`, so removal silently no-ops.
+
+1. **Main/auxiliary events**: `addSource` registers `this._onEvent.bind(this)`
+   (a fresh function per call), but `removeSource`/`removeTarget` remove
+   `this._eventHandler` — a *completely different function* (the sync callback
+   given to the constructor). Two `@ts-ignore` comments at the removal sites
+   are suppressing exactly the type error that would have caught this.
+2. **ELEMENT_DISABLED auto-cleanup**: `_updateDisableHandlers` creates a new
+   `disableHandler` closure on every call and does remove-then-add with it;
+   the remove never matches the previously-added closure, so handlers
+   accumulate unboundedly (one per add/remove of any source/target). Worse,
+   the handler passes a raw DOM element into `remove(...)`, which expects a
+   `{ renderingEngineId, viewportId }` object, so it also never actually
+   removes the viewport.
+
+Net effect: every viewport that ever participated in a synchronizer keeps its
+listeners for the life of the page; disabled viewports keep firing into
+synchronizers; each layout change stacks more handlers. Note that
+`packages/tools/src/store/removeEnabledElement.ts:82-84` independently calls
+`synchronizer.remove(...)` with a proper viewport-info object — that working
+path is why these bugs have gone unnoticed, and it must keep working.
+
+## Current state
+
+- `packages/tools/src/store/SynchronizerManager/Synchronizer.ts` — the whole class (~400 lines). Key members:
+  - `_eventHandler: ISynchronizerEventHandler` — constructor-provided sync callback (line 38, set at 55). NOT a DOM listener.
+  - `_onEvent = (evt: Event): void => {...}` — arrow-field DOM listener (line 307); calls `_eventHandler` internally (line 280).
+  - `getEventSource(viewportInfo): EventTarget` (line 381) — resolves element vs global `eventTarget`.
+
+Bug 1 — add side (`Synchronizer.ts:133-139`):
+
+```ts
+    eventSource.addEventListener(this._eventName, this._onEvent.bind(this));
+
+    // Use a default source of 'element' if not provided just like we do for the main event.
+    this._auxiliaryEvents.forEach(({ name, source = 'element' }) => {
+      const target = source === 'element' ? viewport.element : eventTarget;
+      target.addEventListener(name, this._onEvent.bind(this));
+    });
+```
+
+Bug 1 — remove side (`Synchronizer.ts:203-218`, inside `removeSource`; a
+similar block exists in `removeTarget` — find it):
+
+```ts
+    //@ts-ignore
+    eventSource.removeEventListener(this._eventName, this._eventHandler);
+
+    this._auxiliaryEvents.forEach(({ name, source }) => {
+      const target =
+        source === 'element'
+          ? this.getViewportElement(viewportInfo)
+          : eventTarget;
+      //@ts-ignore
+      target.removeEventListener(name, this._eventHandler);
+    });
+```
+
+Bug 2 (`Synchronizer.ts:352-377`):
+
+```ts
+  private _updateDisableHandlers(): void {
+    const viewports = _getUniqueViewports(
+      this._sourceViewports,
+      this._targetViewports
+    );
+    const _remove = this.remove.bind(this);
+    const disableHandler = (elementDisabledEvent) => {
+      _remove(elementDisabledEvent.detail.element);
+    };
+
+    viewports.forEach((vp) => {
+      const eventSource = this.getEventSource(vp);
+
+      if (!eventSource) {
+        return;
+      }
+
+      eventSource.removeEventListener(
+        Enums.Events.ELEMENT_DISABLED,
+        disableHandler
+      );
+      eventSource.addEventListener(
+        Enums.Events.ELEMENT_DISABLED,
+        disableHandler
+      );
+    });
+  }
+```
+
+Key fact for the fix: `_onEvent` is ALREADY an identity-stable arrow-function
+class field (line 307). The `.bind(this)` calls at the add sites are
+unnecessary — `this._onEvent` itself is the stable reference to use on both
+sides.
+
+Repo conventions: TypeScript, prettier, arrow-function class fields for
+listeners. Jest tests: `packages/tools/jest.config.js` picks up
+`packages/tools/**/*.jest.js` AND `src/**/*.spec.ts`; `@cornerstonejs/core`
+is module-mapped to core's `src`, so importing core in tests works.
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Build core then tools | `pnpm --filter @cornerstonejs/core run build:esm && pnpm --filter @cornerstonejs/tools run build:esm` | exit 0 |
+| Unit test (this fix) | `pnpm run test:unit:no-coverage -- Synchronizer` | new tests pass |
+| Lint | `pnpm run lint` | exit 0 |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `packages/tools/src/store/SynchronizerManager/Synchronizer.ts`
+- `packages/tools/test/Synchronizer_listeners.jest.js` (create)
+
+**Out of scope** (do NOT touch, even though they look related):
+- `packages/tools/src/store/removeEnabledElement.ts` — its `synchronizer.remove(enabledElement)` call is correct and must keep working unchanged.
+- `SynchronizerManager/createSynchronizer.ts`, `destroy.ts`, and the synchronizer factory functions in `packages/tools/src/synchronizers/` — behavior consumers, not part of the bug.
+- The `fireEvent` / `_ignoreFiredEvents` loop-prevention logic — intentional, leave alone.
+
+## Git workflow
+
+- Branch: `advisor/005-fix-synchronizer-listener-leaks`
+- Commit message style: `fix(tools): remove the same listener references Synchronizer adds`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Use the stable `_onEvent` reference on both add and remove sides
+
+- In `addSource` (and check `addTarget` — read it; at this commit only
+  `addSource` attaches listeners, but verify): replace both
+  `this._onEvent.bind(this)` occurrences with `this._onEvent`.
+- In `removeSource` AND `removeTarget`: replace both
+  `this._eventHandler` occurrences in `removeEventListener` calls with
+  `this._onEvent`, and delete the now-unneeded `//@ts-ignore` comments above
+  them. If the `@ts-ignore` was ALSO masking an EventTarget-signature
+  complaint (it may be, since `_onEvent` takes `Event`), fix the typing
+  properly (e.g. `this._onEvent as EventListener`) rather than re-adding
+  `@ts-ignore`.
+- In `removeSource`/`removeTarget`, the auxiliary-events removal uses
+  `source === 'element'` without the `= 'element'` default that the add side
+  uses (`{ name, source = 'element' }`). Make the default consistent on the
+  remove side too, otherwise an auxiliary event declared without `source`
+  is added to the element but removed from `eventTarget`.
+
+**Verify**: `pnpm --filter @cornerstonejs/tools run build:esm` → exit 0, and
+`grep -c '@ts-ignore' packages/tools/src/store/SynchronizerManager/Synchronizer.ts` → 0.
+
+### Step 2: Make the disable handler identity-stable and pass the right argument
+
+Replace the per-call closure with a class field (place near `_onEvent`):
+
+```ts
+  private _disableHandler = (elementDisabledEvent) => {
+    const { element } = elementDisabledEvent.detail;
+    const enabledElement = getEnabledElement(element);
+    if (!enabledElement) {
+      return;
+    }
+    const { viewportId, renderingEngineId } = enabledElement;
+    this.remove({ viewportId, renderingEngineId });
+  };
+```
+
+Caveat: by the time `ELEMENT_DISABLED` fires, `getEnabledElement(element)` may
+already return `undefined` (the element is being torn down). Read the event's
+payload first: `grep -rn "ELEMENT_DISABLED" packages/core/src/RenderingEngine/BaseRenderingEngine.ts packages/core/src/RenderingEngine/*.ts | head` and find
+where the event detail is constructed — if the detail already carries
+`viewportId` / `renderingEngineId` (it typically does), prefer reading them
+directly from `elementDisabledEvent.detail` and fall back to
+`getEnabledElement` only if absent. `getEnabledElement` is already imported at
+the top of Synchronizer.ts.
+
+Then in `_updateDisableHandlers`, delete the local `_remove`/`disableHandler`
+declarations and use `this._disableHandler` in both the remove and add calls.
+The remove-then-add idiom now correctly dedupes (adding the same reference
+twice is a no-op per DOM spec, but keep the explicit remove for clarity).
+
+**Verify**: `pnpm --filter @cornerstonejs/tools run build:esm` → exit 0.
+
+### Step 3: Regression tests
+
+Create `packages/tools/test/Synchronizer_listeners.jest.js` (model imports on
+an existing `packages/tools/test/*.jest.js` file — list the directory first).
+The Synchronizer can be constructed directly: `new Synchronizer(id, eventName,
+handlerFn, options)` — but it resolves viewports via
+`getEnabledElementByViewportId`/`getRenderingEngine`, so the cleanest jest
+approach is to test the listener bookkeeping with the global `eventTarget`
+source: construct with `options = { eventSource: 'eventTarget' }`, spy on
+`eventTarget.addEventListener` / `removeEventListener` (import `eventTarget`
+from `@cornerstonejs/core`), and stub `getEnabledElementByViewportId` — if
+that import proves unstubbable, use jest module mocking for
+`@cornerstonejs/core` with the real module spread plus overridden lookup
+functions.
+
+Cases:
+1. After `addSource(vpInfo)` then `removeSource(vpInfo)`: every
+   `removeEventListener` call received the **same function reference** as a
+   prior `addEventListener` call for the same event name (assert
+   `removeSpy.mock.calls` references are all present in
+   `addSpy.mock.calls` references).
+2. Auxiliary event without an explicit `source`: added and removed on the
+   same target.
+3. Calling `addSource` twice then `removeSource` twice does not leave the
+   `ELEMENT_DISABLED` listener count growing (assert add/remove call counts
+   for `ELEMENT_DISABLED` balance out to ≤ 1 net listener).
+
+**Verify**: `pnpm run test:unit:no-coverage -- Synchronizer` → new tests pass.
+
+## Test plan
+
+Covered in Step 3. The identity assertions (same-reference add/remove) are the
+regression guard for both bugs; they fail on the current code.
+
+## Done criteria
+
+- [ ] `grep -n '_onEvent.bind' packages/tools/src/store/SynchronizerManager/Synchronizer.ts` returns no matches
+- [ ] `grep -n 'removeEventListener' packages/tools/src/store/SynchronizerManager/Synchronizer.ts` shows only `this._onEvent` / `this._disableHandler` references
+- [ ] `grep -c '@ts-ignore' packages/tools/src/store/SynchronizerManager/Synchronizer.ts` → 0
+- [ ] `pnpm --filter @cornerstonejs/tools run build:esm` exits 0
+- [ ] `pnpm run test:unit:no-coverage -- Synchronizer` passes with the new tests
+- [ ] `pnpm run lint` exits 0
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- The excerpts no longer match the live file (drift).
+- Existing tests fail after Step 1 in a way that suggests something *depended*
+  on listeners surviving `removeSource` (i.e. sync still firing after removal).
+- The `ELEMENT_DISABLED` event detail contains neither element nor
+  viewportId/renderingEngineId — the payload assumption is wrong.
+- Stubbing core lookups in jest requires modifying production code.
+
+## Maintenance notes
+
+- Reviewer: check `removeTarget` got the same treatment as `removeSource`, and that the auxiliary-event `source` default is now symmetric.
+- Behavior change to be aware of: disabled viewports will now actually stop receiving/driving sync events (previously they kept syncing via the leaked listener). If any downstream app accidentally relied on that, it surfaces as "sync stops after re-layout" — expected and correct.
+- Deferred: `_updateDisableHandlers` is called from add/remove but never removes handlers from viewports that left the set; with the stable reference this is now a bounded no-op, but a cleaner design would track per-viewport disable listeners explicitly.
diff --git a/plans/006-fix-volumecropping-listener-leak.md b/plans/006-fix-volumecropping-listener-leak.md
new file mode 100644
index 0000000000..084ea78ea1
--- /dev/null
+++ b/plans/006-fix-volumecropping-listener-leak.md
@@ -0,0 +1,179 @@
+# Plan 006: Remove VolumeCroppingTool's leaked global eventTarget listener on disable
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- packages/tools/src/tools/VolumeCroppingTool.ts`
+> If the file changed since this plan was written, compare the "Current state"
+> excerpts against the live code before proceeding; on a mismatch, treat it as
+> a STOP condition.
+
+## Status
+
+- **Priority**: P2
+- **Effort**: S
+- **Risk**: LOW
+- **Depends on**: none
+- **Category**: bug
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+`VolumeCroppingTool` listens on the **global** `eventTarget` for
+`VOLUMECROPPINGCONTROL_TOOL_CHANGED` using an anonymous arrow function, and
+never stores the reference. `onSetToolDisabled` cleans up resize observers and
+another listener but cannot remove this one. Every activation/setup cycle adds
+another permanent global listener holding a closure over the tool instance:
+control-tool changes get handled N times, and old tool instances can never be
+garbage collected.
+
+## Current state
+
+- `packages/tools/src/tools/VolumeCroppingTool.ts` — 3D volume-cropping tool (~1400+ lines).
+
+The leak (`packages/tools/src/tools/VolumeCroppingTool.ts:1349-1354`, inside
+the actor/clipping-plane setup method — locate it by grepping for
+`VOLUMECROPPINGCONTROL_TOOL_CHANGED`):
+
+```ts
+    eventTarget.addEventListener(
+      Events.VOLUMECROPPINGCONTROL_TOOL_CHANGED,
+      (evt) => {
+        this._onControlToolChange(evt);
+      }
+    );
+```
+
+`_onControlToolChange` is ALREADY an identity-stable arrow-function class
+field (`VolumeCroppingTool.ts:937`: `_onControlToolChange = (evt) => {`), so
+the anonymous wrapper is pointless — the fix is to pass the field directly and
+remove it on disable.
+
+The cleanup method that must gain the removal
+(`packages/tools/src/tools/VolumeCroppingTool.ts:362-379`):
+
+```ts
+  onSetToolDisabled() {
+    // Disconnect all resize observers
+    this._resizeObservers.forEach((resizeObserver, viewportId) => {
+      resizeObserver.disconnect();
+      this._resizeObservers.delete(viewportId);
+    });
+
+    if (this._viewportAddedListener) {
+      eventTarget.removeEventListener(
+        Events.TOOLGROUP_VIEWPORT_ADDED,
+        this._viewportAddedListener
+      );
+      this._viewportAddedListener = null; // Clear the reference to the listener
+    }
+
+    const viewportsInfo = this._getViewportsInfo();
+    this._unsubscribeToViewportNewVolumeSet(viewportsInfo);
+  }
+```
+
+The `_viewportAddedListener` block above is the exemplar pattern to match.
+
+Beware: the setup method containing the `addEventListener` may run once per
+viewport/volume initialization, so even with a stable reference you can add
+the listener multiple times — DOM `addEventListener` dedupes identical
+(type, listener) pairs on real EventTargets, and cornerstone's `eventTarget`
+(`packages/core/src/eventTarget.ts`) is a CustomEventTarget — check whether
+its `addEventListener` dedupes; if it does not, guard with a boolean or
+remove-before-add.
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Build tools | `pnpm --filter @cornerstonejs/tools run build:esm` | exit 0 |
+| Unit tests | `pnpm run test:unit:no-coverage` | all pass |
+| Lint | `pnpm run lint` | exit 0 |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `packages/tools/src/tools/VolumeCroppingTool.ts`
+
+**Out of scope** (do NOT touch, even though they look related):
+- `packages/tools/src/tools/VolumeCroppingControlTool.ts` (the counterpart tool) — audit it separately if desired; not this plan.
+- The resize-observer and sphere/actor logic in the same file.
+- `packages/core/src/eventTarget.ts` — read-only reference for dedupe semantics.
+
+## Git workflow
+
+- Branch: `advisor/006-fix-volumecropping-listener-leak`
+- Commit message style: `fix(tools): remove VolumeCroppingTool control-change listener on disable`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Register the stable reference instead of an anonymous wrapper
+
+At the add site, replace the anonymous arrow with the existing class field,
+using remove-before-add to stay idempotent regardless of CustomEventTarget
+dedupe semantics:
+
+```ts
+    eventTarget.removeEventListener(
+      Events.VOLUMECROPPINGCONTROL_TOOL_CHANGED,
+      this._onControlToolChange
+    );
+    eventTarget.addEventListener(
+      Events.VOLUMECROPPINGCONTROL_TOOL_CHANGED,
+      this._onControlToolChange
+    );
+```
+
+**Verify**: `pnpm --filter @cornerstonejs/tools run build:esm` → exit 0.
+
+### Step 2: Remove it on disable
+
+In `onSetToolDisabled`, after the `_viewportAddedListener` block, add:
+
+```ts
+    eventTarget.removeEventListener(
+      Events.VOLUMECROPPINGCONTROL_TOOL_CHANGED,
+      this._onControlToolChange
+    );
+```
+
+**Verify**: `pnpm --filter @cornerstonejs/tools run build:esm` → exit 0, then
+`pnpm run test:unit:no-coverage` → all pass, `pnpm run lint` → exit 0.
+
+## Test plan
+
+No existing unit scaffolding constructs this tool (it needs vtk actors). Do
+not build one. Verification: build + suite + the two greps in Done criteria.
+Optional manual check if the operator asks: run the `volumeCroppingTool`
+example (`pnpm run example volumeCropping` — find the exact example name with
+`ls utils/ExampleRunner` guidance or `grep -ril volumecropping packages/tools/examples`) and confirm dragging control spheres still updates cropping planes.
+
+## Done criteria
+
+- [ ] `grep -n "_onControlToolChange(evt)" packages/tools/src/tools/VolumeCroppingTool.ts` shows no anonymous-wrapper registration (only the class-field definition and direct references remain)
+- [ ] `grep -c "removeEventListener(\s*$" packages/tools/src/tools/VolumeCroppingTool.ts` — manual check: `onSetToolDisabled` contains a `VOLUMECROPPINGCONTROL_TOOL_CHANGED` removal
+- [ ] `pnpm --filter @cornerstonejs/tools run build:esm` exits 0
+- [ ] `pnpm run test:unit:no-coverage` passes
+- [ ] `pnpm run lint` exits 0
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- The add site or `onSetToolDisabled` no longer match the excerpts (drift).
+- `_onControlToolChange` is no longer an arrow-function class field (identity would not be stable and the plan's core assumption fails).
+- The setup method intentionally registers per-viewport distinct handlers (evidence: the closure uses per-viewport state beyond `this`) — it does not at this commit, but verify.
+
+## Maintenance notes
+
+- Reviewer: check idempotency — enable → disable → enable must end with exactly one live listener.
+- Sibling cleanup opportunity (deferred, separate finding): `OrientationControllerTool` has untracked `setTimeout`s that outlive disable (`OrientationControllerTool.ts:252-255,363-366,433-446`); same review lens, different mechanism.
diff --git a/plans/007-geometry-cache-budget.md b/plans/007-geometry-cache-budget.md
new file mode 100644
index 0000000000..571ce920d4
--- /dev/null
+++ b/plans/007-geometry-cache-budget.md
@@ -0,0 +1,226 @@
+# Plan 007: Count geometry in the cache budget and purge it in `purgeCache()`
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- packages/core/src/cache/cache.ts`
+> If the file changed since this plan was written, compare the "Current state"
+> excerpts against the live code before proceeding; on a mismatch, treat it as
+> a STOP condition.
+
+## Status
+
+- **Priority**: P2
+- **Effort**: M
+- **Risk**: MED (changes eviction/purge behavior)
+- **Depends on**: plans/002-fix-get-volume-containing-image-id.md (same file — land 002 first to avoid conflicts)
+- **Category**: bug
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+The cache enforces `maxCacheSize` (tuned to browser memory limits) via
+`getCacheSize()` / `getBytesAvailable()`, but `getCacheSize()` returns only
+`_imageCacheSize`. Geometry memory (contour sets, surfaces, meshes — which get
+large with segmentations) is tracked in `_geometryCacheSize` yet never counted
+against the budget, so total memory can exceed `maxCacheSize` and crash the
+tab. Additionally, `purgeCache()` — the "free everything" API — purges volumes
+and images but never touches `_geometryCache`, silently retaining all geometry.
+
+## Current state
+
+- `packages/core/src/cache/cache.ts` — singleton cache. Key members:
+  - `_geometryCache = new Map<string, ICachedGeometry>()` (line 43); `_geometryCacheSize = 0` (line 47)
+  - `getCacheSize` (line ~138), `getBytesAvailable` (~144)
+  - `purgeCache` (~242), `purgeVolumeCache` (~266)
+  - `removeGeometryLoadObject` (~1060–1080), `putGeometryLoadObject` (~933)
+  - `incrementGeometryCacheSize` / `decrementGeometryCacheSize` (~1087–1096)
+
+Excerpts (verified at the planned-at commit):
+
+```ts
+  // cache.ts:138
+  public getCacheSize = (): number => this._imageCacheSize;
+
+  // cache.ts:144-146
+  public getBytesAvailable(): number {
+    return this.getMaxCacheSize() - this.getCacheSize();
+  }
+
+  // cache.ts:242-261 (abridged)
+  public purgeCache = (): void => {
+    const imageIterator = this._imageCache.keys();
+    // need to purge volume cache first to avoid issues with image cache
+    // shared cache keys
+    this.purgeVolumeCache();
+    while (true) {
+      const { value: imageId, done } = imageIterator.next();
+      if (done) { break; }
+      this.removeImageLoadObject(imageId, { force: true });
+      triggerEvent(eventTarget, Events.IMAGE_CACHE_IMAGE_REMOVED, { imageId });
+    }
+  };
+
+  // cache.ts:1087-1096
+  public incrementGeometryCacheSize = (increment: number) => {
+    this._geometryCacheSize += increment;
+  };
+  public decrementGeometryCacheSize = (decrement: number) => {
+    this._geometryCacheSize -= decrement;
+  };
+```
+
+Design caution (why this is MED risk): `getCacheSize()` is public API. Some
+callers may use it specifically to mean "image bytes" (e.g. eviction math in
+`decacheIfNecessaryUntilBytesAvailable`, external apps like OHIF reading cache
+stats). Before changing its return, enumerate callers:
+`grep -rn "getCacheSize\|getBytesAvailable" packages/*/src | grep -v test`.
+The recommended shape below keeps per-category accessors and folds geometry
+into the *budget math* rather than redefining `_imageCacheSize`.
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Build core | `pnpm --filter @cornerstonejs/core run build:esm` | exit 0 |
+| Build tools (downstream compile check) | `pnpm --filter @cornerstonejs/tools run build:esm` | exit 0 |
+| Unit test (this fix) | `pnpm run test:unit:no-coverage -- cache_geometry` | new tests pass |
+| Full unit suite | `pnpm run test:unit:no-coverage` | all pass |
+| Karma suite (cache has karma coverage) | `pnpm run test:ci` | all pass |
+| Lint | `pnpm run lint` | exit 0 |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `packages/core/src/cache/cache.ts`
+- `packages/core/test/cache_geometry_budget.jest.js` (create)
+
+**Out of scope** (do NOT touch, even though they look related):
+- `packages/core/src/cache/classes/*` (ImageVolume etc.) — geometry size computation at insert time is out of scope; this plan only wires the ALREADY-tracked size into budget/purge.
+- Eviction *policy* (LRU ordering, which entries to evict first) — do not make geometry evictable by `decacheIfNecessaryUntilBytesAvailable`; that needs a design decision about whether geometries are safe to auto-evict (they are often derived state that tools hold references to). Budget counting and manual purge only.
+- Public API renames.
+
+## Git workflow
+
+- Branch: `advisor/007-geometry-cache-budget`
+- Commit message style: `fix(core): include geometry in cache size accounting and purgeCache`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Enumerate callers of `getCacheSize` / `getBytesAvailable`
+
+Run `grep -rn "getCacheSize\|getBytesAvailable" packages/*/src`. Record the
+call sites in your report. If any caller demonstrably needs image-only
+semantics (e.g. computes image eviction byte targets from it), keep
+`getCacheSize` image-only and instead add the geometry term inside
+`getBytesAvailable`. Otherwise (the expected case), proceed with Step 2's
+combined accessor.
+
+**Verify**: caller list captured in your notes; no code changed yet.
+
+### Step 2: Add geometry to the budget math
+
+Preferred shape (adjust per Step 1's findings):
+
+```ts
+  /** Total bytes tracked by the cache (images + geometry). */
+  public getCacheSize = (): number =>
+    this._imageCacheSize + this._geometryCacheSize;
+
+  /** Bytes used by cached images only. */
+  public getImageCacheSize = (): number => this._imageCacheSize;
+
+  /** Bytes used by cached geometries only. */
+  public getGeometryCacheSize = (): number => this._geometryCacheSize;
+```
+
+`getBytesAvailable()` needs no change if `getCacheSize()` becomes combined.
+Also check `isCacheable` (search it in the file) uses `getBytesAvailable` and
+therefore picks up the fix automatically.
+
+**Verify**: `pnpm --filter @cornerstonejs/core run build:esm && pnpm --filter @cornerstonejs/tools run build:esm` → both exit 0.
+
+### Step 3: Purge geometry in `purgeCache`
+
+Add geometry purging after the image loop, iterating a snapshot of keys and
+going through the existing removal path so size decrements and `decache()`
+hooks run:
+
+```ts
+    const geometryIds = Array.from(this._geometryCache.keys());
+    geometryIds.forEach((geometryId) => {
+      this.removeGeometryLoadObject(geometryId);
+    });
+```
+
+Read `removeGeometryLoadObject` (~line 1060) first: confirm it decrements
+`_geometryCacheSize` and calls the load object's `decache`. If it does NOT
+decrement the size, add the decrement there (that is part of this bug). If
+there is an event like `GEOMETRY_CACHE_GEOMETRY_REMOVED` in
+`packages/core/src/enums/Events.ts`, trigger it to mirror the image path; if
+no such event exists, do not invent one.
+
+**Verify**: `pnpm --filter @cornerstonejs/core run build:esm` → exit 0.
+
+### Step 4: Regression tests
+
+Create `packages/core/test/cache_geometry_budget.jest.js` (model on an
+existing `packages/core/test/*.jest.js`). Seed geometry via the public API:
+`cache.putGeometryLoadObject(geometryId, { promise })` with a minimal fake
+geometry, then `cache.incrementGeometryCacheSize(nBytes)` (this mirrors how
+production code accounts geometry — confirm by grepping
+`incrementGeometryCacheSize` callers in `packages/*/src`).
+
+Cases:
+1. After incrementing geometry size by N: `getCacheSize()` includes N and
+   `getBytesAvailable()` shrinks by N.
+2. `purgeCache()` empties the geometry cache (`cache.getGeometry(geometryId)`
+   → undefined) and geometry size returns to 0.
+3. Image-only accounting unchanged: putting an image load object still
+   reflects in `getImageCacheSize()`.
+
+Reset the singleton in `afterEach` (`cache.purgeCache()` and restore
+`setMaxCacheSize` if you changed it).
+
+**Verify**: `pnpm run test:unit:no-coverage -- cache_geometry` → 3 new tests pass; then run the full `pnpm run test:unit:no-coverage` and `pnpm run test:ci` (karma has cache specs) → all pass.
+
+## Test plan
+
+Covered in Step 4. Pattern: existing core jest tests. The karma run in the
+commands table is required because `cache` has browser-test coverage that
+exercises eviction paths the jest suite doesn't.
+
+## Done criteria
+
+- [ ] `getCacheSize()` (or `getBytesAvailable()`, per Step 1 decision) includes `_geometryCacheSize`
+- [ ] `purgeCache` iterates `_geometryCache` via `removeGeometryLoadObject`
+- [ ] `pnpm --filter @cornerstonejs/core run build:esm` and `...tools run build:esm` exit 0
+- [ ] `pnpm run test:unit:no-coverage` passes incl. 3 new tests; `pnpm run test:ci` passes
+- [ ] `pnpm run lint` exits 0
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated (include the Step 1 caller list in the PR/report)
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- Step 1 reveals a caller that would change behavior dangerously with a
+  combined `getCacheSize` AND image-only semantics can't be preserved via
+  `getImageCacheSize` — report the caller and wait for a decision.
+- `removeGeometryLoadObject` has side effects beyond decache/size (e.g.
+  releasing vtk objects referenced by live actors) that make purge-on-demand
+  unsafe — report instead of purging.
+- Karma cache specs fail in a way related to eviction thresholds — the budget
+  change may need `maxCacheSize` headroom adjustments in tests; report before
+  editing test constants.
+
+## Maintenance notes
+
+- Reviewer: this makes `isCacheable` stricter (geometry now consumes budget) — watch for downstream apps that ran near the cache limit; they may start seeing eviction earlier. That is the correct behavior, but call it out in the changelog.
+- Deferred: making geometry evictable by the automatic eviction loop (needs a design decision about live references from segmentation representations); volume scalar-buffer accounting (intentionally shared-key design per existing comments).
diff --git a/plans/008-bound-segmentation-stats-payload.md b/plans/008-bound-segmentation-stats-payload.md
new file mode 100644
index 0000000000..c5113803ec
--- /dev/null
+++ b/plans/008-bound-segmentation-stats-payload.md
@@ -0,0 +1,210 @@
+# Plan 008: Bound segmentation-statistics worker payloads to the segment's bounding box
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- packages/tools/src/utilities/segmentation/getStatistics.ts packages/tools/src/utilities/segmentation/computeMetabolicStats.ts packages/tools/src/workers/`
+> If any in-scope file changed since this plan was written, compare the
+> "Current state" excerpts against the live code before proceeding; on a
+> mismatch, treat it as a STOP condition.
+
+## Status
+
+- **Priority**: P2
+- **Effort**: M
+- **Risk**: MED (IJK/index math between main thread and worker)
+- **Depends on**: none
+- **Category**: perf
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+Computing statistics for a segment currently materializes the ENTIRE
+segmentation volume and the ENTIRE reference image volume as flat typed arrays
+(`getCompleteScalarDataArray()`) and ships both to the compute worker — even
+when the segment occupies a few thousand voxels of a multi-hundred-MB CT/PET
+volume. The segment's bounding box (`boundsIJK`) is already computed and
+available at the call site but unused for payload bounding. Cost: two
+full-volume allocations + copies + a structured-clone/transfer per stats call,
+plus a full-volume scan in the worker. Bounding the payload makes stats cost
+scale with segment size instead of volume size.
+
+## Current state
+
+- `packages/tools/src/utilities/segmentation/getStatistics.ts` — main entry; volume path builds `segmentationInfo`/`imageInfo` around lines 110–175.
+- `packages/tools/src/utilities/segmentation/computeMetabolicStats.ts` — same full-volume pattern at lines ~71 and ~88.
+- The worker task: `getWebWorkerManager().executeTask('compute', 'calculateSegmentsStatisticsVolume', { segmentationInfo, imageInfo, indices, unit, mode })` (`getStatistics.ts:142-151`). Find the worker implementation with `grep -rn "calculateSegmentsStatisticsVolume" packages/tools/src` (expected under `packages/tools/src/workers/`).
+- `packages/core/src/utilities/VoxelManager.ts` — voxel access layer: `getCompleteScalarDataArray?` (line 58), `getBoundsIJK()` (~line 264), `forEach(callback, { boundsIJK })` (~line 296+) which iterates only within bounds.
+
+Verified excerpt (`getStatistics.ts:114-136`, abridged):
+
+```ts
+  const { boundsIJK: boundsOrig } = segmentationVoxelManager;
+  if (!boundsOrig) {
+    return VolumetricCalculator.getStatistics({ spacing });
+  }
+
+  const segmentationScalarData =
+    segmentationVoxelManager.getCompleteScalarDataArray();
+
+  const segmentationInfo = {
+    scalarData: segmentationScalarData,
+    dimensions: segmentationImageData.getDimensions(),
+    spacing: segmentationImageData.getSpacing(),
+    origin: segmentationImageData.getOrigin(),
+    direction: segmentationImageData.getDirection(),
+  };
+
+  const imageInfo = {
+    scalarData: imageVoxelManager.getCompleteScalarDataArray(),
+    dimensions: imageData.getDimensions(),
+    ...
+  };
+```
+
+Design target: extract a sub-volume covering the segment's `boundsIJK`
+(optionally padded by 1 voxel), ship `{ scalarData: subArray, dimensions:
+subDims, origin: shiftedOrigin, spacing, direction, boundsOrigin: [i0,j0,k0] }`
+for both segmentation and image, and have the worker compute over the
+sub-volume. Statistics that depend on world coordinates (center of mass, SUV
+peak sphere, etc.) must use the SHIFTED origin so world math stays correct —
+`shiftedOrigin = origin + direction * (spacing ∘ [i0,j0,k0])` (compute with
+`vec3`/matrix helpers already used in the file's neighborhood; check how the
+worker converts IJK→world before choosing where to apply the shift).
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Build core+tools | `pnpm --filter @cornerstonejs/core run build:esm && pnpm --filter @cornerstonejs/tools run build:esm` | exit 0 |
+| Unit tests | `pnpm run test:unit:no-coverage` | all pass |
+| Karma suite (segmentation stats have browser specs — check `packages/tools/test` for `*stat*`) | `pnpm run test:ci` | all pass |
+| Lint | `pnpm run lint` | exit 0 |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `packages/tools/src/utilities/segmentation/getStatistics.ts`
+- `packages/tools/src/utilities/segmentation/computeMetabolicStats.ts`
+- The worker file implementing `calculateSegmentsStatisticsVolume` (and `calculateMetabolicStats` if separate) under `packages/tools/src/workers/`
+- A new shared helper, e.g. `packages/tools/src/utilities/segmentation/extractBoundedSubVolume.ts` (create)
+- New jest test `packages/tools/test/extractBoundedSubVolume.jest.js` (create)
+
+**Out of scope** (do NOT touch, even though they look related):
+- `packages/tools/src/utilities/segmentation/utilsForWorker.ts` growcut paths — same smell, but growcut correctness is riskier; leave for a follow-up.
+- `VoxelManager` internals in core — consume its public API only.
+- The stack (per-image) statistics path in `getStatistics.ts` — this plan is the volume path only.
+- Statistics algorithms themselves (`VolumetricCalculator`, `processSegmentationStatistics`).
+
+## Git workflow
+
+- Branch: `advisor/008-bound-segmentation-stats-payload`
+- Commit message style: `perf(tools): bound segmentation statistics payloads to segment boundsIJK`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Read the worker and inventory world-coordinate dependencies
+
+Locate the worker via `grep -rn "calculateSegmentsStatisticsVolume" packages/tools/src`.
+Read it end-to-end. List every place it uses `dimensions`, `origin`,
+`direction`, or absolute voxel indices. This list drives Step 3. If the worker
+computes world coordinates from `origin + ijk * spacing * direction`, the
+shifted-origin approach works transparently.
+
+**Verify**: written inventory in your working notes (include in final report).
+
+### Step 2: Implement `extractBoundedSubVolume`
+
+New helper taking `(voxelManager, imageData, boundsIJK, pad = 1)` and
+returning `{ scalarData, dimensions, origin, spacing, direction, boundsOrigin }`
+where `scalarData` is a newly-allocated typed array (same constructor as the
+source: use `scalarData.constructor`) filled by iterating k/j/i within the
+clamped, padded bounds. Clamp bounds to `[0, dim-1]`. Prefer row-wise
+`TypedArray.prototype.set` on `subarray` slices per (j,k) row for speed over
+per-voxel loops when the source is a flat array; fall back to
+`voxelManager.forEach` with `boundsIJK` if no flat array is available.
+
+**Verify**: `pnpm --filter @cornerstonejs/tools run build:esm` → exit 0, plus the unit test in Step 5.
+
+### Step 3: Switch `getStatistics.ts` volume path to bounded payloads
+
+Replace the two `getCompleteScalarDataArray()` payloads with helper output for
+(a) segmentation using `segmentationVoxelManager.getBoundsIJK()` and (b) the
+image using the SAME bounds (both sub-volumes must be index-aligned). Apply the
+Step 1 inventory: adjust the worker so all world-coordinate math uses the
+passed (shifted) origin — if it already does, no worker change is needed.
+Mode note: when `indices` covers multiple segments in `individual` mode, the
+bounds must cover ALL requested segments — if `segmentationVoxelManager.getBoundsIJK()`
+reflects only overall modified bounds, verify it covers every requested
+segment's voxels (it tracks the full modified extent, so it does; state this
+check in your report).
+
+**Verify**: `pnpm run test:ci` → segmentation-statistics specs pass (find them: `ls packages/tools/test | grep -i stat`).
+
+### Step 4: Same change in `computeMetabolicStats.ts`
+
+Mirror Step 3 for the metabolic-stats payloads (lines ~71/88) and its worker
+task (find via the task name string used in that file).
+
+**Verify**: build + `pnpm run test:ci` again.
+
+### Step 5: Unit-test the helper
+
+`packages/tools/test/extractBoundedSubVolume.jest.js` — pure-math tests, no
+DOM: construct a small 4×4×4 Uint8 flat volume with known values, bounds
+covering a 2×2×2 corner, assert extracted dimensions, values, and shifted
+origin (identity direction and a non-identity spacing case).
+
+**Verify**: `pnpm run test:unit:no-coverage -- extractBoundedSubVolume` → pass.
+
+### Step 6: Numerical equivalence check (the real gate)
+
+Before/after comparison: pick an existing karma/playwright statistics test
+(e.g. anything asserting mean/max/volume values). If none asserts numeric
+values, write a temporary script comparison: run `getStatistics` on a
+synthetic volume twice — once with the helper forced to full-volume bounds,
+once with tight bounds — and assert identical outputs (this can live inside
+the new jest file if `getStatistics`'s dependencies can be constructed in
+jest; otherwise do it in a karma spec alongside existing segmentation specs).
+
+**Verify**: identical statistics (exact equality for counts/min/max; 1e-6
+tolerance for means/world coordinates).
+
+## Test plan
+
+Steps 5 and 6. Regression risk is entirely "stats numbers changed" — the
+equivalence check is mandatory, not optional.
+
+## Done criteria
+
+- [ ] `grep -n "getCompleteScalarDataArray" packages/tools/src/utilities/segmentation/getStatistics.ts packages/tools/src/utilities/segmentation/computeMetabolicStats.ts` returns no matches in the volume paths (stack path in getStatistics may retain its own access pattern)
+- [ ] New helper + jest tests pass; equivalence check passes
+- [ ] `pnpm --filter @cornerstonejs/tools run build:esm` exits 0; `pnpm run test:unit:no-coverage` and `pnpm run test:ci` pass
+- [ ] `pnpm run lint` exits 0
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- The worker computes statistics that structurally require full-volume context
+  (e.g. anything windowed against the whole image histogram) — list them and stop.
+- `segmentationVoxelManager.getBoundsIJK()` turns out NOT to cover all
+  segment voxels in some path (e.g. bounds reset after certain operations) —
+  the correctness premise fails.
+- Equivalence check (Step 6) disagrees after one debugging pass.
+- The sub-volume path is measurably SLOWER for near-full-volume segments and
+  you'd need a heuristic switch — implement `if subVolumeVoxels > 0.5 * totalVoxels: send full` only if trivial; otherwise report.
+
+## Maintenance notes
+
+- Reviewer: scrutinize the origin shift and the index-alignment of the two sub-volumes; that's where silent wrongness lives. Check `individual` vs `collective` mode both tested.
+- Follow-up (deferred): the same full-volume pattern exists in `utilsForWorker.ts:120` (growcut prep) and in `WholeBodySegmentTool` (plan 009 handles the latter).
+- Future interaction: if VoxelManager gains a native "extract sub-volume" API, replace the helper with it.
diff --git a/plans/009-wholebody-island-scan-bounds.md b/plans/009-wholebody-island-scan-bounds.md
new file mode 100644
index 0000000000..d6af1f62ef
--- /dev/null
+++ b/plans/009-wholebody-island-scan-bounds.md
@@ -0,0 +1,191 @@
+# Plan 009: Stop WholeBodySegmentTool from scanning the full volume on the main thread
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- packages/tools/src/tools/annotation/WholeBodySegmentTool.ts`
+> If the file changed since this plan was written, compare the "Current state"
+> excerpts against the live code before proceeding; on a mismatch, treat it as
+> a STOP condition.
+
+## Status
+
+- **Priority**: P2
+- **Effort**: M
+- **Risk**: MED
+- **Depends on**: plans/008-bound-segmentation-stats-payload.md (reuses its `extractBoundedSubVolume` mindset/helper if applicable; can proceed independently if 008 is not done)
+- **Category**: perf
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+`WholeBodySegmentTool.getRemoveIslandData()` runs inside an interactive
+segmentation flow. It materializes BOTH the reference volume and the labelmap
+volume as complete flat arrays and then loops over every voxel of the labelmap
+— synchronously, on the main thread. For a whole-body CT that is two
+multi-hundred-MB allocations plus a full linear scan per gesture, freezing
+rendering and input. The grow-cut segmentation this tool just ran was bounded
+to a box; the island scan can be bounded the same way.
+
+## Current state
+
+- `packages/tools/src/tools/annotation/WholeBodySegmentTool.ts` — the tool. `getRemoveIslandData()` at lines ~239–280; upstream, `runGrowCutForBoundingBox` is invoked with a `boundingBoxInfo` built from `ijkTopLeft`/`ijkBottomRight` (lines ~215–237).
+
+Verified excerpt (`WholeBodySegmentTool.ts:239-272`, abridged):
+
+```ts
+  protected getRemoveIslandData(): RemoveIslandData {
+    const {
+      segmentation: { segmentIndex, referencedVolumeId, labelmapVolumeId },
+    } = this.growCutData;
+    const referencedVolume = cache.getVolume(referencedVolumeId);
+    const labelmapVolume = cache.getVolume(labelmapVolumeId);
+    const referencedVolumeData =
+      referencedVolume.voxelManager.getCompleteScalarDataArray();
+    const labelmapData =
+      labelmapVolume.voxelManager.getCompleteScalarDataArray();
+    const { islandPixelRange } = this.configuration.islandRemoval;
+    const islandPointIndexes = [];
+
+    // ... comment block ...
+    // TODO: improve how it looks for pixels in the islands that need to be segmented
+    for (let i = 0, len = labelmapData.length; i < len; i++) {
+      if (labelmapData[i] !== segmentIndex) {
+        continue;
+      }
+      const pixelValue = referencedVolumeData[i];
+      if (
+        pixelValue >= islandPixelRange[0] &&
+        pixelValue <= islandPixelRange[1]
+      ) {
+        islandPointIndexes.push(i);
+      }
+    }
+```
+
+Available API (`packages/core/src/utilities/VoxelManager.ts`):
+- `voxelManager.getBoundsIJK()` (~line 264) — modified-voxel bounds.
+- `voxelManager.forEach(callback, { boundsIJK })` (~line 296+) — iterates only
+  within bounds; the callback receives an object including the flat `index`
+  and `value` (read the `forEach` implementation to confirm the exact callback
+  signature before coding).
+- `voxelManager.getAtIndex(index)` — random access without materializing the
+  full array.
+
+Also read what consumes `RemoveIslandData` (`grep -rn "RemoveIslandData\|getRemoveIslandData\|islandPointIndexes" packages/tools/src`) — the returned
+`islandPointIndexes` are flat indexes into the FULL volume; the fix must keep
+that contract (bounded ITERATION, unchanged index space).
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Build tools | `pnpm --filter @cornerstonejs/tools run build:esm` | exit 0 |
+| Unit tests | `pnpm run test:unit:no-coverage` | all pass |
+| Karma | `pnpm run test:ci` | all pass |
+| Lint | `pnpm run lint` | exit 0 |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `packages/tools/src/tools/annotation/WholeBodySegmentTool.ts` (only `getRemoveIslandData`)
+
+**Out of scope** (do NOT touch, even though they look related):
+- `growCut.runGrowCutForBoundingBox` and the growcut utilities.
+- The island-removal consumer (`removeIslands` logic, wherever `RemoveIslandData` flows) — contract stays identical.
+- Moving this to a web worker — bigger refactor; bounding the iteration removes ~all of the cost because the growcut bounding box is small relative to the volume. Worker offload is explicitly deferred.
+- `islandPixelRange` semantics / the TODO about smarter island detection.
+
+## Git workflow
+
+- Branch: `advisor/009-wholebody-island-scan-bounds`
+- Commit message style: `perf(tools): bound WholeBodySegmentTool island scan to labelmap boundsIJK`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Replace full-array materialization + full scan with bounded iteration
+
+Target shape (adapt to the actual `forEach` callback signature you confirmed):
+
+```ts
+    const labelmapVoxelManager = labelmapVolume.voxelManager;
+    const referencedVoxelManager = referencedVolume.voxelManager;
+    const islandPointIndexes = [];
+
+    labelmapVoxelManager.forEach(
+      ({ value, index }) => {
+        if (value !== segmentIndex) {
+          return;
+        }
+        const pixelValue = referencedVoxelManager.getAtIndex(index) as number;
+        if (
+          pixelValue >= islandPixelRange[0] &&
+          pixelValue <= islandPixelRange[1]
+        ) {
+          islandPointIndexes.push(index);
+        }
+      },
+      { boundsIJK: labelmapVoxelManager.getBoundsIJK() }
+    );
+```
+
+Delete the two `getCompleteScalarDataArray()` calls. Keep everything else in
+the method (including the return shape) unchanged.
+
+Correctness argument to verify while implementing: the loop only *keeps*
+indexes where `labelmapData[i] === segmentIndex`; voxels with the segment
+value can only exist where the labelmap was written, which is inside
+`getBoundsIJK()` (the modified-voxel bounds). If you find that
+`getBoundsIJK()` returns full-volume bounds when nothing was tracked, that is
+the safe degenerate case (same behavior as today, minus the allocations).
+
+**Verify**: `pnpm --filter @cornerstonejs/tools run build:esm` → exit 0.
+
+### Step 2: Suite + behavioral check
+
+**Verify**: `pnpm run test:unit:no-coverage` and `pnpm run test:ci` → all pass;
+`pnpm run lint` → exit 0.
+
+If a Playwright example covers this tool (`grep -ril wholeBody tests/ packages/tools/examples | head`), run that single spec:
+`npx playwright test <spec> --project=chromium` and confirm it passes.
+
+## Test plan
+
+No new unit file: the method needs cached volumes and growcut state that only
+the browser stack constructs. Rely on the karma/playwright segmentation suites
+plus the bounded-iteration correctness argument in Step 1 (restate it in the
+PR description). If `packages/tools/test` contains an existing
+WholeBodySegment or islandRemoval spec (check `ls packages/tools/test | grep -i -e island -e wholebody`), extend it with a case asserting
+`islandPointIndexes` equality between old and new implementations on a small
+synthetic volume — only if the scaffolding already exists.
+
+## Done criteria
+
+- [ ] `grep -n "getCompleteScalarDataArray" packages/tools/src/tools/annotation/WholeBodySegmentTool.ts` returns no matches
+- [ ] `pnpm --filter @cornerstonejs/tools run build:esm` exits 0
+- [ ] `pnpm run test:unit:no-coverage` and `pnpm run test:ci` pass
+- [ ] `pnpm run lint` exits 0
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- `voxelManager.forEach`'s callback does not provide a flat `index` compatible
+  with the full-volume index space the consumer expects.
+- The labelmap volume's voxel manager type in this path lacks
+  `getBoundsIJK`/`forEach` (e.g. it's a plain flat-array manager without bounds
+  tracking) — report what type it actually is.
+- Any segmentation karma/playwright spec fails after the change.
+
+## Maintenance notes
+
+- Reviewer: the contract is "same `islandPointIndexes`, same order not guaranteed" — check the consumer doesn't depend on ascending order (the bounded k/j/i iteration is still ascending in flat index if `forEach` iterates k-major; confirm and note it).
+- Deferred explicitly: worker offload of the island scan, and the pre-existing TODO about smarter island detection.
diff --git a/plans/010-ci-typecheck-gate.md b/plans/010-ci-typecheck-gate.md
new file mode 100644
index 0000000000..aefebcc70c
--- /dev/null
+++ b/plans/010-ci-typecheck-gate.md
@@ -0,0 +1,159 @@
+# Plan 010: Add a typecheck + api-check gate to CI
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- .github/workflows package.json`
+> If these changed since this plan was written, compare the "Current state"
+> excerpts against the live files before proceeding; on a mismatch, treat it
+> as a STOP condition.
+
+## Status
+
+- **Priority**: P1
+- **Effort**: S
+- **Risk**: LOW
+- **Depends on**: none
+- **Category**: dx
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+No CI workflow runs a TypeScript typecheck. PR gates are: jest+karma
+(`test.yml`), Playwright screenshots, oxlint+prettier (`format-check.yml`),
+CodeQL, and packaging validation (`validate-packaging.yml`, which runs
+`pnpm run build` — the only implicit type validation, and only on packaging-
+related triggers). Each package also defines an `api-check` script
+(api-extractor) that no workflow invokes, so public-API drift is unenforced.
+A dedicated, always-on PR job makes type errors and API-surface changes fail
+fast instead of surfacing at build/publish time. This also unblocks the other
+plans in this set — it is the missing verification baseline for refactors.
+
+## Current state
+
+- `.github/workflows/test.yml` — PR-triggered; steps: checkout → pnpm/action-setup → setup-node (`node-version: '24.15.0'`, `cache: 'pnpm'`) → `pnpm install --frozen-lockfile` → `pnpm run test:unit` → `pnpm run test:ci`. This is the structural exemplar for the new job.
+- Root `package.json` scripts (verified):
+  - `"api-check": "pnpm -r --filter=!docs run api-check"`
+  - `"build": "pnpm -r --filter=!docs run build && pnpm --filter @cornerstonejs/dicom-image-loader run build:loader"`
+  - `"build:esm": "pnpm -r --filter=!docs run build:esm"`
+  - There is NO `typecheck` script at root or in any package.
+- Per-package `build:esm` runs `tsc --project ./tsconfig.json` plus tsc-alias and a dist-package-json writer — i.e. the repo's real typecheck IS the tsc in `build:esm`; packages likely depend on each other's built `dist` (workspace deps), so a bare `tsc --noEmit` per package may fail on unresolved workspace imports unless upstream packages are built first. Simplest reliable gate: `pnpm run build:esm` at root (recursive, dependency-ordered by pnpm).
+- `api-check` per package: `api-extractor --debug run` (e.g. `packages/core/package.json:83`). api-extractor consumes built type declarations, so it must run AFTER the build.
+- Existing workflows use concurrency groups (see `format-check.yml`): copy that block.
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Typecheck (the gate itself) | `pnpm run build:esm` | exit 0 |
+| API check | `pnpm run api-check` | exit 0 |
+| Workflow syntax check | `gh workflow list` after push, or `actionlint .github/workflows/typecheck.yml` if actionlint is available; otherwise YAML-parse: `python3 -c "import yaml,sys;yaml.safe_load(open('.github/workflows/typecheck.yml'))"` | no errors |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `.github/workflows/typecheck.yml` (create)
+
+**Out of scope** (do NOT touch, even though they look related):
+- Adding `tsc --noEmit` scripts to every package — nice-to-have, but redundant with `build:esm` and 12 packages of churn; deferred.
+- `.husky/pre-commit` / lint-staged — local-hook changes are a separate decision (they slow every commit).
+- Existing workflows (`test.yml`, `format-check.yml`, `validate-packaging.yml`) — do not fold the new job into them; a separate workflow keeps failure signals distinct.
+- `.oxlintrc.json` (plan 011).
+
+## Git workflow
+
+- Branch: `advisor/010-ci-typecheck-gate`
+- Commit message style: `ci: add typecheck and api-check gate on PRs`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Verify the gate commands pass locally on a clean tree
+
+Run `pnpm install --frozen-lockfile`, then `pnpm run build:esm`, then
+`pnpm run api-check`. All three must exit 0 BEFORE you add the workflow — if
+`api-check` fails on the current main (stale api-extractor baselines), record
+which packages fail and add only the build step to the workflow, noting
+api-check as blocked in your report (do NOT regenerate api baselines yourself).
+
+**Verify**: exit codes captured; decision recorded (both steps vs build-only).
+
+### Step 2: Create the workflow
+
+`.github/workflows/typecheck.yml`, modeled exactly on `test.yml`'s setup steps
+(same action versions — read them from `test.yml` at execution time and reuse:
+currently `actions/checkout@v6.0.3`, `pnpm/action-setup@v6.0.8`,
+`actions/setup-node@v6.4.0` with `node-version: '24.15.0'` and `cache: 'pnpm'`),
+plus the concurrency block from `format-check.yml`:
+
+```yaml
+name: Typecheck
+
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+on:
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  typecheck:
+    timeout-minutes: 30
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v6.0.3
+      - uses: pnpm/action-setup@v6.0.8
+      - uses: actions/setup-node@v6.4.0
+        with:
+          node-version: '24.15.0'
+          cache: 'pnpm'
+      - name: Install dependencies
+        run: pnpm install --frozen-lockfile
+      - name: Typecheck (tsc via build:esm)
+        run: pnpm run build:esm
+        env:
+          NODE_OPTIONS: --max_old_space_size=8192
+      - name: API surface check
+        run: pnpm run api-check
+```
+
+Drop the last step if Step 1 said api-check is currently red.
+
+**Verify**: the YAML-parse command from the table → no errors.
+
+## Test plan
+
+CI workflows are verified by execution: after the operator pushes the branch /
+opens a PR, confirm the `Typecheck` check appears and is green. Locally, the
+Step 1 command runs are the test.
+
+## Done criteria
+
+- [ ] `.github/workflows/typecheck.yml` exists, YAML-valid, mirrors repo action versions
+- [ ] `pnpm run build:esm` exits 0 locally
+- [ ] `pnpm run api-check` exits 0 locally OR its exclusion is documented in the report and the plans/README.md row
+- [ ] `git status` shows no modified files outside the in-scope list
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- `pnpm run build:esm` fails on the untouched checkout — main is broken or the
+  environment is missing something (node 24 required: check `node --version`);
+  report the error verbatim.
+- `api-check` failures look like real API regressions rather than stale
+  baselines — report, don't "fix" baselines.
+- Build takes > 25 minutes locally — the CI timeout needs adjusting; report timing.
+
+## Maintenance notes
+
+- Reviewer: confirm the job runs on `pull_request` with no branch filter (matching `test.yml`).
+- Follow-up candidates (deferred): per-package `typecheck` scripts using `tsc --noEmit` with project references for faster incremental gating; wiring `api-check` into `release.yml` so publishes are also gated; GitHub Actions cache for the tsc build.
+- Interaction: plans 001–009 all use `build:esm` as their local verification — once this lands, their CI story is automatic.
diff --git a/plans/011-expand-oxlint-rules.md b/plans/011-expand-oxlint-rules.md
new file mode 100644
index 0000000000..4e71baee42
--- /dev/null
+++ b/plans/011-expand-oxlint-rules.md
@@ -0,0 +1,175 @@
+# Plan 011: Expand oxlint from 2 rules to the `correctness` category (ratcheted)
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- .oxlintrc.json package.json`
+> On drift, compare the "Current state" excerpts against the live files; on a
+> mismatch, treat it as a STOP condition.
+
+## Status
+
+- **Priority**: P2
+- **Effort**: M
+- **Risk**: MED (rule expansion surfaces existing violations that must be fixed or explicitly allowed)
+- **Depends on**: none (010 recommended first so type errors are separable from lint errors)
+- **Category**: dx
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+The lint gate runs in CI (`format-check.yml` → `pnpm run lint`) but enforces
+exactly two rules, so it passes on nearly any real defect. oxlint's
+`correctness` category catches the exact bug classes this audit found by hand
+(mismatched listener references, unreachable code, invalid typeof, unsafe
+negations). Turning it on — fixing or explicitly waiving what it finds — makes
+the existing CI lane earn its keep at near-zero runtime cost (oxlint is fast).
+
+## Current state
+
+- `.oxlintrc.json` (entire file, verified):
+
+```json
+{
+  "plugins": ["typescript", "import"],
+  "ignorePatterns": [
+    "utils/**",
+    "**/examples/**",
+    "packages/dicomImageLoader/src/types/codec*"
+  ],
+  "rules": {
+    "typescript/no-explicit-any": "error",
+    "import/no-cycle": "error"
+  }
+}
+```
+
+- Root `package.json:58`: `"lint": "oxlint packages/**/src --quiet"`.
+- oxlint version: `1.9.0` (root devDependencies). In oxlint, rule categories
+  are enabled via the `categories` config key (e.g. `"categories": {
+  "correctness": "error" }`) or CLI flags; check `pnpm exec oxlint --help` for
+  the 1.9 syntax before writing config.
+- `lint-staged` (root `package.json:175-180`) also runs `oxlint` on staged
+  files — it picks up `.oxlintrc.json` automatically, so config changes apply
+  to both paths.
+- CI: `format-check.yml` runs `pnpm run lint` on every PR.
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install | `pnpm install --frozen-lockfile` | exit 0 |
+| Lint | `pnpm run lint` | exit 0 |
+| Lint verbose (triage) | `pnpm exec oxlint packages/**/src` | violation list with rule names |
+| Build (post-fix sanity) | `pnpm run build:esm` | exit 0 |
+| Unit tests (post-fix sanity) | `pnpm run test:unit:no-coverage` | all pass |
+
+## Scope
+
+**In scope**:
+- `.oxlintrc.json`
+- Source files with `correctness` violations — mechanical fixes only (see Step 3's rules of engagement)
+
+**Out of scope** (do NOT touch):
+- Enabling `suspicious`/`pedantic`/`style` categories — one category per pass; those are follow-ups.
+- The existing two rules and existing ignorePatterns — keep them.
+- `format-check.yml` — no workflow change needed; it already runs `pnpm run lint`.
+- Any fix that changes behavior (see STOP conditions) — this plan must be a no-op at runtime.
+
+## Git workflow
+
+- Branch: `advisor/011-expand-oxlint-rules`
+- Commit style: `chore(lint): enable oxlint correctness category` — one commit for config, separate commits per package for fixes (e.g. `chore(lint): fix correctness violations in core`).
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Measure the blast radius
+
+Add the category to `.oxlintrc.json`:
+
+```json
+  "categories": {
+    "correctness": "error"
+  },
+```
+
+(Confirm the key name against `pnpm exec oxlint --help`; oxlint 1.x supports
+`categories` in config.) Then run `pnpm exec oxlint packages/**/src` (WITHOUT
+`--quiet`) and save the output. Count violations per rule:
+`pnpm exec oxlint packages/**/src 2>&1 | grep -oE 'eslint\([a-z-]+\)|oxc\([a-z-]+\)|[a-z-]+/[a-z-]+' | sort | uniq -c | sort -rn` (adjust the extraction to the actual output format you see).
+
+**Verify**: a per-rule violation count table exists in your notes.
+
+### Step 2: Decide per rule — fix, or allow with a comment
+
+For each rule with violations:
+- **≤ ~25 mechanical violations** → fix them (Step 3).
+- **Large or judgment-heavy** (would require restructuring code) → set that
+  specific rule to `"allow"` in `.oxlintrc.json` under `rules`, with a JSON-
+  adjacent note in the plans/README report listing the count (JSON has no
+  comments — record the rationale in your final report and the commit message).
+
+The end state must be: `pnpm run lint` exits 0 with the category ON and an
+explicit, minimal allow-list.
+
+**Verify**: `.oxlintrc.json` updated; decision table in notes.
+
+### Step 3: Fix the mechanical violations
+
+Rules of engagement:
+- Only make fixes whose runtime behavior is provably identical (remove
+  unused labels, fix `typeof` typos, delete unreachable code AFTER confirming
+  it is genuinely unreachable, correct bad comparison operators ONLY when the
+  intent is unambiguous from context).
+- If a violation looks like a REAL BUG (the fix would change behavior), do NOT
+  fix it silently: set the rule to `allow` if needed to keep lint green, and
+  list the site in your report under "probable real bugs found by lint" —
+  those become new findings, not drive-by changes.
+- Use `pnpm exec oxlint --fix` only for rules documented as auto-fixable, and
+  review the diff hunk-by-hunk.
+
+**Verify** after each package's fixes: `pnpm run lint` (should be improving), and at the end: `pnpm run build:esm` → exit 0, `pnpm run test:unit:no-coverage` → all pass.
+
+### Step 4: Confirm CI parity
+
+`pnpm run lint` (the exact CI command) → exit 0.
+
+**Verify**: exit 0.
+
+## Test plan
+
+No new tests. The gates are: lint exits 0 with the category enabled; build and
+the unit suites still pass (proves the fixes were behavior-preserving).
+`pnpm run test:ci` (karma) additionally if any fix touched
+`packages/core/src` or `packages/tools/src` non-trivially.
+
+## Done criteria
+
+- [ ] `.oxlintrc.json` contains `"categories": { "correctness": "error" }` (or the 1.9-equivalent syntax)
+- [ ] `pnpm run lint` exits 0
+- [ ] Allowed-rule list + per-rule counts + "probable real bugs" list are in the final report
+- [ ] `pnpm run build:esm` exits 0 and `pnpm run test:unit:no-coverage` passes
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- Total violations exceed ~300 — the triage itself needs operator
+  prioritization; deliver the per-rule count table and stop.
+- oxlint 1.9.0 does not support category enabling via config — report the
+  actual supported syntax options rather than upgrading oxlint (a version bump
+  is a separate decision).
+- Any single fix requires touching files in `packages/core/src/RenderingEngine/GenericViewport/**` in a non-mechanical way (active migration area — coordinate first).
+- A "fix" would change behavior and you cannot allow-list around it.
+
+## Maintenance notes
+
+- Reviewer: the diff should be config + mechanical fixes only; anything that reads like a logic change is out of contract.
+- Follow-ups (deferred): `suspicious` category next, then `perf`; consider `no-floating-promises`-equivalent once oxlint supports type-aware rules (needs typed linting — heavier).
+- The "probable real bugs" list from Step 3 feeds the next audit round.
diff --git a/plans/012-decompress-advisory-override.md b/plans/012-decompress-advisory-override.md
new file mode 100644
index 0000000000..145e106578
--- /dev/null
+++ b/plans/012-decompress-advisory-override.md
@@ -0,0 +1,152 @@
+# Plan 012: Neutralize the critical `decompress` advisory in labelmap-interpolation's dependency tree
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- pnpm-workspace.yaml packages/labelmap-interpolation/package.json pnpm-lock.yaml`
+> On drift, re-run `pnpm audit --prod` first — the advisory may already be
+> resolved; if so, mark this plan REJECTED in `plans/README.md` and stop.
+
+## Status
+
+- **Priority**: P2
+- **Effort**: S
+- **Risk**: LOW
+- **Depends on**: none
+- **Category**: security (defensive maintenance)
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+`pnpm audit --prod` reports one **critical** advisory: `decompress <= 4.2.1`
+(archive extraction can write files/links outside the target directory —
+GHSA advisory, patched in >= 4.2.2). It is reachable through the PRODUCTION
+dependency chain
+`@cornerstonejs/labelmap-interpolation > @itk-wasm/morphological-contour-interpolation > itk-wasm > @itk-wasm/dam > decompress`.
+Exposure assessment (from the audit): `decompress` is used by itk-wasm's
+Node-side artifact-download path, so browser runtime is unaffected — but the
+package ships in the published dependency tree, meaning every downstream
+consumer's `npm audit` flags critical on install, and any Node/SSR usage of
+the chain carries real exposure. The cheap, honest fix is a workspace override
+to the patched version (same major, published specifically as the security
+patch), plus verifying the package still works.
+
+## Current state
+
+- `packages/labelmap-interpolation/package.json:56-57` (verified):
+  - `"@itk-wasm/morphological-contour-interpolation": "1.1.0"`
+  - `"itk-wasm": "1.0.0-b.165"`
+- `pnpm-workspace.yaml:24+` already has an `overrides:` block (exemplar to extend):
+
+```yaml
+overrides:
+  '@babel/helper-create-class-features-plugin': 7.28.3
+  '@babel/helper-compilation-targets': 7.29.7
+  caniuse-lite: 1.0.30001767
+  axios: 1.16.1
+  buffer: 6.0.3
+  node-forge: 1.4.0
+  canvas: 3.2.0
+  tar-fs: 2.1.4
+```
+
+- The repo uses pnpm 11.5.2 (`packageManager` field); overrides in
+  `pnpm-workspace.yaml` are the established convention here (NOT package.json
+  `pnpm.overrides`).
+- Audit context: 23 total vulns (2 low / 20 moderate / 1 critical). This plan
+  addresses only the critical; the moderates are mostly transitive dev-tooling
+  (vtk.js's babel chain etc.) and are explicitly out of scope.
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Update lockfile | `pnpm install --no-frozen-lockfile` | exit 0, lockfile updated |
+| Audit | `pnpm audit --prod` | zero CRITICAL advisories |
+| Confirm resolution | `pnpm why decompress` | shows decompress >= 4.2.2 (or absent) |
+| Build the affected package | `pnpm --filter @cornerstonejs/labelmap-interpolation run build:esm` | exit 0 |
+| Unit tests | `pnpm run test:unit:no-coverage` | all pass |
+
+## Scope
+
+**In scope** (the only files you should modify):
+- `pnpm-workspace.yaml` (overrides block)
+- `pnpm-lock.yaml` (regenerated by pnpm — do not hand-edit)
+
+**Out of scope** (do NOT touch):
+- Bumping `itk-wasm` / `@itk-wasm/morphological-contour-interpolation` majors — behavioral risk in WASM pipelines; separate decision.
+- The 20 moderate advisories — mostly transitive dev tooling; not this plan.
+- `packages/labelmap-interpolation/src/**`.
+
+## Git workflow
+
+- Branch: `advisor/012-decompress-advisory-override`
+- Commit message style: `chore(deps): override decompress to >=4.2.2 (GHSA critical, path traversal)`
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Add the override
+
+In `pnpm-workspace.yaml`'s existing `overrides:` block, add:
+
+```yaml
+  decompress: 4.2.2
+```
+
+(Only if 4.2.2 does not exist on the registry — check `pnpm view decompress versions` — use the smallest published version `>= 4.2.2`.)
+
+**Verify**: `pnpm install --no-frozen-lockfile` → exit 0.
+
+### Step 2: Confirm the advisory is gone and nothing broke
+
+Run `pnpm audit --prod` → the decompress critical no longer appears.
+Run `pnpm why decompress` → resolved version >= 4.2.2 everywhere (or no
+longer present).
+Run `pnpm --filter @cornerstonejs/labelmap-interpolation run build:esm` and
+`pnpm run test:unit:no-coverage` → pass.
+
+Note: labelmap-interpolation has no unit tests of its own (known gap), so the
+functional check is the build plus — if quick — the labelmap-interpolation
+Playwright/karma spec if one exists (`ls tests | grep -i interpolation`; found
+at plan time: `tests/interpolationContourSegmentation.spec.ts`, which covers
+contour interpolation — run it only if the operator's environment has the
+Playwright stack ready: `npx playwright test interpolationContourSegmentation --project=chromium`).
+
+**Verify**: commands above with expected outputs.
+
+## Test plan
+
+Covered in Step 2. decompress sits in itk-wasm's Node-side download path;
+runtime browser behavior should be provably unchanged (patch release of a leaf
+utility).
+
+## Done criteria
+
+- [ ] `pnpm audit --prod` reports 0 critical advisories
+- [ ] `pnpm why decompress` shows only versions >= 4.2.2 (or none)
+- [ ] `pnpm --filter @cornerstonejs/labelmap-interpolation run build:esm` exits 0
+- [ ] `pnpm run test:unit:no-coverage` passes
+- [ ] Only `pnpm-workspace.yaml` + `pnpm-lock.yaml` modified (`git status`)
+- [ ] `plans/README.md` status row updated
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- The override does not take effect (pnpm why still shows <= 4.2.1) — the
+  dependency may pin an exact range the override can't satisfy; report the
+  resolution chain.
+- `pnpm install` fails with peer/engine conflicts caused by the override.
+- No `decompress` version >= 4.2.2 exists on the registry (then the fix is an
+  itk-wasm bump — out of scope; report).
+
+## Maintenance notes
+
+- Reviewer: overrides are global — confirm `pnpm why decompress` shows no OTHER consumer that needs the old version (at plan time the itk-wasm chain is the only path).
+- Follow-up (deferred): bumping `itk-wasm` off the beta pin `1.0.0-b.165` would remove the need for the override; the 20 moderate advisories deserve a periodic sweep, most will clear with dev-tooling updates.
+- Remove the override when itk-wasm ships with a patched decompress.
diff --git a/plans/013-ci-cross-browser-lane.md b/plans/013-ci-cross-browser-lane.md
new file mode 100644
index 0000000000..41b28b96b3
--- /dev/null
+++ b/plans/013-ci-cross-browser-lane.md
@@ -0,0 +1,148 @@
+# Plan 013: Add a non-blocking Firefox/WebKit Playwright lane to CI
+
+> **Executor instructions**: Follow this plan step by step. Run every
+> verification command and confirm the expected result before moving to the
+> next step. If anything in the "STOP conditions" section occurs, stop and
+> report — do not improvise. When done, update the status row for this plan
+> in `plans/README.md` — unless a reviewer dispatched you and told you they
+> maintain the index.
+>
+> **Drift check (run first)**: `git diff --stat b4c094e92..HEAD -- .github/workflows/playwright.yml playwright.config.ts scripts/run-playright.sh`
+> On drift, compare the "Current state" excerpts against the live files; on a
+> mismatch, treat it as a STOP condition.
+
+## Status
+
+- **Priority**: P3
+- **Effort**: M
+- **Risk**: MED (cross-browser screenshot baselines will surface diffs)
+- **Depends on**: none
+- **Category**: tests
+- **Planned at**: commit `b4c094e92`, 2026-07-07
+
+## Why this matters
+
+Cornerstone3D is a WebGL/canvas rendering library, yet CI exercises exactly one
+engine: karma runs ChromeHeadless only, and all three Playwright matrix lanes
+(legacy / compatibility / next) pass `--project=chromium` and install only
+chromium. `playwright.config.ts` already defines `firefox` and `webkit`
+projects — the infrastructure exists, it is just never run. Firefox/Safari
+rendering regressions (WebGL context behavior, texture formats, canvas
+readback) currently ship blind. A scheduled, initially non-blocking lane
+surfaces them without destabilizing PR CI while baselines are triaged.
+
+## Current state
+
+- `.github/workflows/playwright.yml` (verified): PR-triggered, `runs-on: [nashua]` (self-hosted), matrix of 3 modes, each `run_args: '... --project=chromium'`, browser install step `pnpm exec playwright install chromium`, runs `./scripts/run-playright.sh` wrapped in `scripts/ci/with-nashua-lock.sh`, 120-minute timeout, `NODE_OPTIONS=--max_old_space_size=10192`.
+- `playwright.config.ts` defines `firefox` and `webkit` projects (~lines 85–90 — read the exact project blocks before starting; note any device settings).
+- `scripts/run-playright.sh` — the runner; forwards `--project=...` args. Read it to confirm arbitrary `--project` values pass through.
+- Screenshot baselines: Playwright snapshots are stored per-browser by default (`*-chromium-linux.png` etc. under `tests/*-snapshots/`) — check `ls tests | grep -i snapshots | head` and one snapshot dir to see the naming convention actually in use. Firefox/webkit will need NEW baselines generated (`--update-snapshots`), which is the bulk of this plan's effort and must be done on the SAME runner class that CI uses (self-hosted `nashua`), or baselines won't match.
+
+## Commands you will need
+
+| Purpose | Command | Expected on success |
+|---|---|---|
+| Install browsers | `pnpm exec playwright install firefox webkit` | exit 0 |
+| Run one spec x-browser | `npx playwright test volumeBasic --project=firefox` | pass or produce triage-able diffs |
+| Generate baselines | `./scripts/run-playright.sh --project=firefox --update-snapshots` (confirm flag pass-through in the script first) | snapshots written |
+| YAML validity | `python3 -c "import yaml;yaml.safe_load(open('.github/workflows/playwright-crossbrowser.yml'))"` | no errors |
+
+## Scope
+
+**In scope**:
+- `.github/workflows/playwright-crossbrowser.yml` (create — a separate workflow, NOT an edit of the PR-blocking `playwright.yml`)
+- New per-browser snapshot baseline files under `tests/**-snapshots/` (generated, firefox/webkit only)
+- Possibly small allowances in `playwright.config.ts` (e.g. per-project `maxDiffPixelRatio`) — only if a handful of specs have minor antialiasing diffs; any threshold change must be per-project, never loosening chromium.
+
+**Out of scope** (do NOT touch):
+- `playwright.yml` (the PR gate stays chromium-only and blocking).
+- karma browser matrix (Firefox karma lane is a separate, lower-value change).
+- Test spec logic — if a spec fundamentally can't run on a browser, mark it with Playwright's per-project `skip` annotation rather than editing its assertions; keep a list.
+- WebGL workarounds in library source code — cross-browser FAILURES found by the new lane are findings to report, not to fix in this plan.
+
+## Git workflow
+
+- Branch: `advisor/013-ci-cross-browser-lane`
+- Commit style: `ci: add scheduled firefox/webkit playwright lane` (workflow) + `test: add firefox/webkit screenshot baselines` (snapshots)
+- Do NOT push or open a PR unless the operator instructed it.
+
+## Steps
+
+### Step 1: Local (or runner-side) feasibility probe
+
+Install firefox+webkit browsers and run a small representative set on firefox:
+`npx playwright test stackBasic volumeBasic --project=firefox` (pick 2–3 specs
+that exist — `ls tests/*.spec.ts | head`). Triage outcomes:
+- Pass → proceed.
+- Screenshot-mismatch only → baselines needed, proceed.
+- Hard failures (context creation, timeouts) → record which specs; they get
+  per-project skips with a tracking list in the workflow file header comment.
+
+WebKit on Linux may need system deps (`pnpm exec playwright install-deps webkit`) — on the self-hosted runner this may require operator action; if so, scope the new lane to firefox only and note webkit as blocked.
+
+**Verify**: a written pass/diff/fail triage table for the probe set.
+
+### Step 2: Create the scheduled workflow
+
+`.github/workflows/playwright-crossbrowser.yml`, modeled on `playwright.yml`'s
+steps (same checkout/pnpm/node action versions, nashua lock wrapper, artifact
+upload), with these differences:
+
+```yaml
+on:
+  schedule:
+    - cron: '0 6 * * 1-5'   # weekday nightly; adjust to team preference
+  workflow_dispatch:
+```
+
+- Matrix: `browser: [firefox, webkit]` (or firefox-only per Step 1), single
+  mode (`legacy`, no `--compat/--next`), `run_args: '--project=${{ matrix.browser }}'`.
+- Browser install: `pnpm exec playwright install ${{ matrix.browser }}` (plus `install-deps` if Step 1 needed it).
+- `continue-on-error: true` at the job level initially (non-blocking by design), and always-upload the report artifact.
+
+**Verify**: YAML-parse → no errors.
+
+### Step 3: Generate baselines for the passing spec set
+
+Run the suite per browser with `--update-snapshots` (via
+`scripts/run-playright.sh` if it forwards the flag; otherwise
+`npx playwright test --project=firefox --update-snapshots`), commit the new
+`*-firefox-linux.png` / `*-webkit-linux.png` files. Specs from Step 1's
+hard-failure list get per-project skips instead.
+
+IMPORTANT: baselines must be generated on the same platform CI runs on. If
+your environment is not the `nashua` runner class (linux), generate what you
+can, mark the lane `continue-on-error`, and state in the report that first CI
+runs will need `--update-snapshots` from the runner (the
+`test:e2e:update`-style flow).
+
+**Verify**: `npx playwright test --project=firefox` (no update flag) → green for the non-skipped set, locally or on the runner.
+
+## Test plan
+
+The plan IS test infrastructure. Success = the scheduled workflow exists,
+parses, and a firefox run is reproducibly green (or has a documented skip
+list) wherever baselines were generated.
+
+## Done criteria
+
+- [ ] `.github/workflows/playwright-crossbrowser.yml` exists, YAML-valid, scheduled + manually dispatchable, non-blocking
+- [ ] Firefox (± webkit) baselines committed for the passing set; skip list documented in the workflow header comment
+- [ ] `npx playwright test --project=firefox` green on the baseline-generation machine
+- [ ] `git status` clean outside in-scope paths
+- [ ] `plans/README.md` status row updated (including the skip list and any webkit blockage)
+
+## STOP conditions
+
+Stop and report back (do not improvise) if:
+
+- `scripts/run-playright.sh` hardcodes chromium assumptions that `--project` can't override.
+- More than ~30% of probed specs hard-fail on firefox — the lane needs library-side work first; deliver the failure list as findings.
+- Baseline generation requires the self-hosted runner and you have no access — deliver the workflow + skip-list scaffolding and mark the plan BLOCKED (runner access) in `plans/README.md`.
+- Snapshot naming in this repo turns out NOT to be per-browser (custom `snapshotPathTemplate` without browser tokens) — adding browsers would clobber chromium baselines; report before generating anything.
+
+## Maintenance notes
+
+- Reviewer: verify chromium baselines and thresholds are untouched (`git diff --stat` should show only new files + the workflow).
+- Graduation path (deferred): once the lane is stably green for ~2 weeks, drop `continue-on-error` and consider adding it to PRs for a critical-spec subset.
+- Karma Firefox lane and vitest-browser multi-engine runs were considered and deferred — the Playwright screenshot suite is where cross-browser rendering regressions actually surface.
diff --git a/plans/README.md b/plans/README.md
new file mode 100644
index 0000000000..8c4ac133cc
--- /dev/null
+++ b/plans/README.md
@@ -0,0 +1,72 @@
+# Implementation Plans
+
+Generated by the improve skill on 2026-07-07, from a standard-depth audit of
+the repo at commit `b4c094e92`. Execute in the order below unless dependencies
+say otherwise. Each executor: read the plan fully before starting, honor its
+STOP conditions, and update your row when done.
+
+Scope note: the audit covered `packages/core`, `packages/tools`,
+`packages/dicomImageLoader` source plus repo-wide test/CI/dependency posture.
+`packages/core/src/RenderingEngine/GenericViewport/**` was deliberately
+excluded (separately deep-reviewed in `GENERIC_VIEWPORT_ARCHITECTURE_REVIEW.md`
+on branch cornerstoneBetterGenericViewport). `adapters`, `ai`,
+`nifti-volume-loader`, `metadata` internals were not audited beyond test
+coverage.
+
+## Execution order & status
+
+| Plan | Title | Priority | Effort | Depends on | Status |
+|------|-------|----------|--------|------------|--------|
+| 010 | CI typecheck + api-check gate | P1 | S | — | TODO |
+| 001 | Fix `cancelLoadAll` (`cancel` → `cancelFn`) | P1 | S | — | TODO |
+| 002 | Fix `getVolumeContainingImageId` early return | P1 | S | — | TODO |
+| 003 | Settle superseded StackViewport CPU load promise | P1 | S | — | TODO |
+| 004 | Bind VideoViewport ELEMENT_DISABLED handler | P1 | S | — | TODO |
+| 005 | Fix Synchronizer listener leaks (2 bugs) | P1 | M | — | TODO |
+| 006 | Remove VolumeCroppingTool leaked global listener | P2 | S | — | TODO |
+| 012 | Override `decompress` critical advisory | P2 | S | — | TODO |
+| 007 | Geometry in cache budget + purge | P2 | M | 002 (same file) | TODO |
+| 011 | Expand oxlint to `correctness` category | P2 | M | 010 (recommended) | TODO |
+| 008 | Bound segmentation-stats worker payloads | P2 | M | — | TODO |
+| 009 | Bound WholeBodySegmentTool island scan | P2 | M | 008 (soft — shared approach) | TODO |
+| 013 | Scheduled Firefox/WebKit Playwright lane | P3 | M | — | TODO |
+
+Status values: TODO | IN PROGRESS | DONE | BLOCKED (with one-line reason) | REJECTED (with one-line rationale)
+
+## Dependency notes
+
+- 010 first: it is the missing verification baseline; every other plan uses `pnpm run build:esm` as its typecheck gate.
+- 007 after 002: both edit `packages/core/src/cache/cache.ts`; landing 002 first avoids conflicts.
+- 011 after 010 (recommended): keeps lint failures separable from type failures during the ratchet.
+- 009 references 008's bounded-extraction approach but can proceed independently.
+- 001–006 are mutually independent; safe to run in parallel worktrees.
+
+## Findings confirmed but not planned (available on request)
+
+- OrientationControllerTool untracked `setTimeout`s outlive disable (`packages/tools/src/tools/OrientationControllerTool.ts:252-255,363-366,433-446`) — orphaned actors/listeners on fast enable/disable cycles.
+- `extractMultipart` drops 3 trailing bytes on partial multipart reads (`packages/dicomImageLoader/src/imageLoader/wadors/extractMultipart.ts:58-83`, `slice(offset, endIndex - 2)` when `endIndex === -1`).
+- Test-baseline group (declined this round): false-green `"test": "jest"` scripts in ai / polymorphic-segmentation / labelmap-interpolation (zero test files); no jest config for dicomImageLoader (119 src files).
+- Annotation render loop invokes every enabled tool per frame (`packages/tools/src/stateManagement/annotation/AnnotationRenderingEngine.ts:189-212`).
+- `getSegmentIndexAtWorldPoint` stack fallback returns raw label value, can return `undefined` despite `number` type (`packages/tools/src/utilities/segmentation/getSegmentIndexAtWorldPoint.ts:161-174`).
+- `fillCircle` ellipse predicate divides by zero on degenerate brushes → silent no-op paint (`packages/tools/src/tools/segmentation/strategies/fillCircle.ts:321-393`).
+- Unguarded `imagePlaneModule` deref in `createAndCacheDerivedImage` (`packages/core/src/loaders/imageLoader.ts:282-287,350-357`).
+- Null guards missing in `removeEnabledElement._removeSvgNode` (`packages/tools/src/store/removeEnabledElement.ts:123-128`) and `VolumeCroppingTool.onCameraModified` (`:381-388`).
+- README uses `yarn` commands in a pnpm-pinned repo (`README.md:206,214`); no root CLAUDE.md/AGENTS.md; `@types/node` 20 vs `engines: node >=24`; missing READMEs in 4 published packages; three bundlers (webpack+rspack+rollup 3); Karma+Jasmine EOL runner with puppeteer 13; flat 126-entry `core/utilities` barrel.
+
+## Direction options (maintainer's call; design-spike plans on request)
+
+- `@cornerstonejs/ai`: published but embryonic (7 files, one model, no tests) — define the model-adapter interface and add a second model behind it.
+- `QuadraticSpline`: fully stubbed abstract class, nothing subclasses it — implement or delete.
+- `TODO(next)` MPR/oblique-reformat cluster in `CrosshairsTool.ts:1680,2274`.
+
+## Findings considered and rejected
+
+- XSS via annotation labels: not a finding — all SVG text rendering goes through `textContent` (`drawTextBox.ts:96,196`); repo-wide grep found no HTML sinks in core/tools.
+- Secrets / prompt-injection content: none found in audited scope.
+- vtk.js / comlink / gl-matrix version drift across workspace: none — pinned consistently; vtk.js 35.x is current.
+- Legacy viewport god classes & legacy↔GenericViewport duplication: by design — in-progress migration, separately reviewed.
+- `requestPoolManager.sendRequests` counter leak: checked, correct (non-promise branch decrements).
+- Playwright volume-test slowness: already planned in `VOLUME_TEST_SLICE_LIMIT_PLAN.md` (repo root) — decided work, not re-planned.
+- `Synchronizer.fireEvent` async `_ignoreFiredEvents` gating: intentional loop prevention, not a race.
+- drawTextBox stale `tspan`s when line count shrinks: cosmetic only (blanked to '').
+- TypeScript 5.5 → 5.9 bump: no concrete cost surfaced; not worth standalone churn.