@woosh/meep-engine 2.168.1 → 2.169.0

package/src/REVIEW_2026_08_06/view.md

@@ -0,0 +1,667 @@
+# Correctness review — `meep/src/view/`
+
+Scope: all 111 non-spec source files under `H:/git/moh/app/src/mir-engine/meep/src/view/`.
+Excluded: `editor/`, `prototype*.js`, `*.spec.js`, `.d.ts`.
+
+Notes on evidence used while reviewing:
+- `View.unlink()` **clears the `Linked` flag before dispatching `on.unlinked`** (`View.js:325` then `:347`). Several
+  findings below depend on that ordering.
+- `Signal` keeps handlers in a `Map` keyed by the handler function; iteration is insertion-ordered, and a handler
+  removed mid-dispatch by an earlier handler is **not** invoked (`core/events/signal/Signal.js:378-425`).
+- `Vector1`/`ObservedInteger` extend `Number` and implement `valueOf()`, so arithmetic directly on them is valid.
+- `segment2_segment_compute_intersection_array_2d` leaves `result` **untouched** and returns `false` on a miss.
+
+---
+
+### VIEW-1 `DomTooltipObserver.unlink()` never actually detaches, because the view is already unlinked
+- **Severity**: CRITICAL
+- **File**: `src/view/tooltip/DomTooltipObserver.js:156-165`, driven from `src/view/tooltip/DomTooltipManager.js:109-117,178-194`
+- **Defect**: `unlink()` only runs `__handleViewUnlinked()` `if (view.isLinked)`. On the `manage()` path the call
+  arrives from inside the `view.on.unlinked` dispatch, at which point `View.unlink()` has already cleared the
+  `Linked` flag — so the guard is always false and the teardown is skipped entirely. The observer's own
+  `on.unlinked` handler cannot compensate: `manage()`'s handler was subscribed first, and it calls
+  `observer.unlink()`, which does `view.on.unlinked.remove(this.__handleViewUnlinked, this)` mid-dispatch, deleting
+  the not-yet-visited Map entry so it never fires.
+- **Failure scenario**: `gui.viewTooltips.manage(button, factory)` (used in ~20 places, e.g.
+  `interaction/createInterfaceCommandButton.js:106`, `view/game/scene/strategy/shop/ItemShopView.js:185`). Link the
+  panel, then unlink it. `mouseenter`/`mouseleave` listeners stay on `button.el`, and the 4 `SignalBinding`s on
+  `view.position.onChanged`, `view.size.onChanged` and the `DomSizeObserver` stay linked forever. Re-open the panel
+  and `manage()`'s linked handler calls `add()` again, creating a *second* observer with a second pair of DOM
+  listeners on the same element. Ten open/close cycles leave ten live observers per button. Worse: hover a button,
+  and inside the 128 ms `requestShow` delay close the panel — `remove()` calls `hide()` (no-op, tip not added yet),
+  the observer teardown is skipped so nothing calls `cancelShowRequest()`, the timeout fires, `tipManager.add(tip)`
+  builds a tooltip for a detached view, and because the element no longer receives mouse events nothing will ever
+  fire `on.exited` → the tooltip is stuck on screen for the rest of the session.
+- **Fix**: drop the `view.isLinked` guard in `unlink()` and make `__handleViewUnlinked()` idempotent (track an
+  internal `#attached` boolean set in `__handleViewLinked`), and remove the `view.on.*` handlers *before* calling
+  `__handleViewUnlinked()`. Additionally call `this.cancelShowRequest()` in `DomTooltipManager.remove()`.
+- **Confidence**: Confirmed
+
+### VIEW-2 `SvgImageView` cannot be imported and crashes on every `link()`
+- **Severity**: CRITICAL
+- **File**: `src/view/elements/image/SvgImageView.js:1,64-73`
+- **Defect**: Two independent hard errors. (a) `import AABB2 from "../../../core/geom/AABB2.js"` — that file does not
+  exist; the real path is `core/geom/2d/aabb/AABB2.js`, so the module fails to resolve. (b) `update()` is a class
+  method but its body references `resize` and `self`, which are `const`/`let` bindings local to the *constructor*.
+  `link()` calls `this.update()` unconditionally.
+- **Failure scenario**: any module that does `import SvgImageView from '.../SvgImageView.js'` fails at bundle/resolve
+  time. If the import path is fixed, `new SvgImageView(url, {assetManager}); parent.addChild(v)` on a linked parent →
+  `link()` → `update()` → `ReferenceError: resize is not defined` (caught by Signal only if it were dispatched from a
+  signal; here it propagates out of `addChild`).
+- **Fix**: correct the import path; promote `resize` and the icon element to instance state (`#resize()` reading
+  `this.#elIcon`, `this.size`) so `update()` can reach them.
+- **Confidence**: Confirmed
+
+### VIEW-3 `MinimapMarkerView` throws on construction — `this` used before `super()`
+- **Severity**: CRITICAL
+- **File**: `src/view/minimap/dom/MinimapMarkerView.js:17,51-64`
+- **Defect**: `super(entity, this.marker, this.transform, this.worldScale)` dereferences `this` before the base
+  constructor has run, which is a `ReferenceError` in every ES2015+ engine. Even past that, the three handler methods
+  reference `setPosition` and `size`, which are constructor-local bindings, and they are bound via `bindSignal(...)`
+  **without a context argument**, so `this` inside them would be `undefined`.
+- **Failure scenario**: `new MinimapMarkerView(entity, marker, transform, worldScale)` →
+  `ReferenceError: Must call super constructor in derived class before accessing 'this'`. The class is unusable.
+- **Fix**: `super()` with no arguments; move `setPosition` to a method and pass `this` as the context to every
+  `bindSignal` call; read `this.size` instead of the free `size`.
+- **Confidence**: Confirmed
+
+### VIEW-4 `MinimapTerrainView.__setTerrain` references an undefined identifier and has no context
+- **Severity**: CRITICAL
+- **File**: `src/view/minimap/dom/MinimapTerrainView.js:126,133-143`
+- **Defect**: `this.terrain.onChanged.add(this.__setTerrain)` subscribes a *method* with no context, and the method
+  body calls `updatePreview()` — a function declared inside the constructor and therefore not in scope. It also
+  dereferences `terrain.preview` with no null check even though `ObservedValue(null)` is the initial state and
+  `set(null)` is a legal transition.
+- **Failure scenario**: `minimapTerrainView.terrain.set(someTerrain)` → `__setTerrain` runs →
+  `ReferenceError: updatePreview is not defined` (swallowed by Signal's try/catch and logged) → the terrain preview
+  image is never set, the view renders an empty `<img>`. `terrain.set(null)` →
+  `TypeError: Cannot read properties of null (reading 'preview')`.
+- **Fix**: make `updatePreview`/`setPreview` instance methods, subscribe with `add(this.__setTerrain, this)`, and
+  guard the `terrain === null` case.
+- **Confidence**: Confirmed
+
+### VIEW-5 `ViewGroup.remove()` calls a non-existent `Set.remove`; `disconnect()` adds instead of removes
+- **Severity**: CRITICAL
+- **File**: `src/view/ViewGroup.js:34,74-89`
+- **Defect**: `this.elements` is a `Set`; `Set` has `delete`, not `remove`. Separately, `disconnect()` iterates every
+  member and calls `this.container.addChild(view)` where the whole point of the method is to detach them.
+- **Failure scenario**: `group.remove(view)` → `TypeError: this.elements.remove is not a function`.
+  `group.connect(a); group.connect(b)` → `connect` calls `disconnect()`, which re-adds every view to container `a`
+  (pushing a duplicate entry into `a.children` and re-appending the DOM node), sets `this.container = null`, then
+  `connect` adds them all to `b`. Container `a` is left with duplicate `children` entries pointing at views whose
+  DOM nodes now live under `b`; a later `a.removeAllChildren()` calls `a.el.removeChild(child.el)` on a node that is
+  no longer its child → `NotFoundError` DOMException.
+- **Fix**: `this.elements.delete(view)`; `disconnect()` must call `this.container.removeChild(view)`.
+- **Confidence**: Confirmed
+
+### VIEW-6 `MinimapView.clear()` adds children instead of removing them
+- **Severity**: CRITICAL
+- **File**: `src/view/minimap/Minimap.js:183-188` (called from `unlink()` at `:236`)
+- **Defect**: The method is documented "remove all existing markers" / "clear out all camera views" but its body is
+  `this.__worldView.addChild(v)` for each camera view — the views are already children, so each `unlink()` pushes a
+  duplicate entry into `__worldView.children`.
+- **Failure scenario**: Open the minimap, close it, open it again (each cycle = one link/unlink pair). After N
+  cycles `__worldView.children` holds each `MinimapCameraView` N+1 times. Now the camera entity is destroyed:
+  `cameraRemoved` → `__worldView.removeChild(cameraView)` splices out *one* entry and detaches the DOM node, leaving
+  stale duplicates. On the next `unlink()`, `clear()` runs `addChild` on that stale duplicate, which does
+  `this.el.appendChild(child.el)` — re-inserting the frustum polygon of a camera that no longer exists back into the
+  minimap, and re-linking it on the next `link()` so it keeps updating against a dead `Transform`.
+- **Fix**: `this.__worldView.removeChild(v)` and iterate a copy (or iterate backwards) since `removeChild` mutates.
+- **Confidence**: Confirmed
+
+### VIEW-7 `TaskProgressView` displays progress where remaining time belongs
+- **Severity**: MAJOR
+- **File**: `src/view/task/TaskProgressView.js:127-131`
+- **Defect**: `const estimate = Number.isNaN(computedEstimate) ? 0 : computedProgressValue;` — the non-NaN branch uses
+  `computedProgressValue` (the 0..1 progress fraction) instead of `computedEstimate` (the estimator's output). The
+  computed estimate is discarded.
+- **Failure scenario**: A 60-second load at 20% progress. `remainingTimeEstimator.estimate()` returns ~48, but the
+  `.remaining-time` label is fed `0.2` and formatted with `toFixed(0)` → it reads `0`. The loading screen shows
+  "0 seconds remaining" for the entire load, then jumps to "1" at completion.
+- **Fix**: `const estimate = Number.isNaN(computedEstimate) ? 0 : computedEstimate;`
+- **Confidence**: Confirmed
+
+### VIEW-8 `ColorPickerView` unsubscribes from the new colour instead of the old one
+- **Severity**: MAJOR
+- **File**: `src/view/elements/ColorPickerView.js:282-294`
+- **Defect**:
+  ```js
+  this.model.onChanged.add(function (v, _v) {
+      if (v !== null) { modelValueChanged(...); v.onChanged.add(modelValueChanged); }
+      if (_v !== null) { v.onChanged.remove(modelValueChanged); }   // <-- v, should be _v
+  });
+  ```
+  The removal targets the *new* value. The old value keeps the listener forever, and the new value gets `add`
+  immediately followed by `remove`.
+- **Failure scenario**: `picker.model.set(colorA)` then `picker.model.set(colorB)`. Afterwards, changing `colorB`
+  externally does not move the H/S/L/A gauges (its listener was removed), while changing `colorA` — which the picker
+  no longer edits — does move them. Additionally `picker.model.set(null)` after having a colour executes
+  `null.onChanged.remove(...)` → `TypeError: Cannot read properties of null (reading 'onChanged')`.
+- **Fix**: `if (_v !== null) { _v.onChanged.remove(modelValueChanged); }`, and perform the removal before the add.
+- **Confidence**: Confirmed
+
+### VIEW-9 `ColorPickerView` value-channel write lock uses a key that does not exist
+- **Severity**: MAJOR
+- **File**: `src/view/elements/ColorPickerView.js:156-161,214,224,229,257,266`
+- **Defect**: `writeLocks` is declared with keys `h, s, l, a`. The `colorV` handler checks and sets `writeLocks.v`
+  (undefined key), while `modelValueChanged` checks `writeLocks.l`. The lock protecting the value/lightness channel
+  therefore never engages in either direction.
+- **Failure scenario**: Pick a saturated red (h≈0, s=1, v=1), then drag the **L** gauge to 0. `colorV.onChanged` runs
+  unguarded (`writeLocks.v` is `undefined`), writes rgb `(0,0,0)` into the model, which dispatches
+  `modelValueChanged`; that handler's guard reads `writeLocks.l` — also never set by the V handler — so it proceeds
+  and pushes `rgb2hsv(0,0,0)` back into the gauges, snapping H and S to 0. The user's hue and saturation are
+  destroyed by moving the lightness slider, and cannot be recovered by dragging L back up.
+- **Fix**: use one consistent key (`v`) in the declaration, the `colorV` handler, and `modelValueChanged`.
+- **Confidence**: Confirmed
+
+### VIEW-10 `Vector1Control` binds the write-back handler to the model's change signal
+- **Severity**: MAJOR
+- **File**: `src/view/controller/controls/Vector1Control.js:61-81`
+- **Defect**: `subscribe(v1)` does `v1.onChanged.add(writeBack)`. `writeBack` is the *controller → model* direction
+  (`vector1.set(v)`); the *model → controller* direction is `syncForward`, which is only ever called once, inside
+  `subscribe`. `unsubscribe` symmetrically removes `writeBack`, so the mismatch is consistent and silent.
+- **Failure scenario**: Bind a `Vector1Control` to a `Vector1` that some other system writes (e.g. an animated
+  property). The number field shows the value present at subscribe time and never updates again: each external change
+  invokes `writeBack(newValue)` which writes `newValue` straight back into the same vector (a no-op) instead of
+  refreshing `cNumber.value`.
+- **Fix**: `v1.onChanged.add(syncForward)` in `subscribe` and `v1.onChanged.remove(syncForward)` in `unsubscribe`;
+  keep `lockForward` to break the echo.
+- **Confidence**: Confirmed
+
+### VIEW-11 `ListController` removes the wrong view, so deleted rows stay on screen
+- **Severity**: MAJOR
+- **File**: `src/view/controller/controls/ListController.js:48-74`
+- **Defect**: `handleItemAdded` wraps `guiControl` in a `vElementContainer` and adds *that* to `vContainer`.
+  `handleItemRemoved` then calls `vContainer.removeChild(guiControl)` — `guiControl` is a child of
+  `vElementContainer`, not of `vContainer`, so `children.indexOf()` returns `-1` and `removeChild` returns `false`
+  without doing anything.
+- **Failure scenario**: Click the `.close` button next to a list item. The item leaves the model
+  (`list.removeOneOf(item)`), `elementControllers` drops the entry, `guiControl.model.set(null)` blanks the control —
+  but the row (control + close button) remains in the DOM permanently. Clicking its close button again calls
+  `list.removeOneOf(item)` on an item that is no longer present. Rebinding the controller to a different list via
+  `detachList` leaves every old row visible on top of the new ones.
+- **Fix**: keep a `Map<item, vElementContainer>` (or store the wrapper on the control) and remove the wrapper.
+- **Confidence**: Confirmed
+
+### VIEW-12 `HTMLElementCacheKey.initializeFromElement` wipes the styles it just read (shadowed loop variable)
+- **Severity**: MAJOR
+- **File**: `src/view/common/HTMLElementCacheKey.js:189-217`
+- **Defect**:
+  ```js
+  let i = 0;
+  ...
+  for (let i = 0; i < styleCount; i++) { ... this.style[i] = pair; }  // inner `i` shadows outer
+  this.style.splice(i, this.style.length - i);                        // outer i is still 0
+  ```
+  The truncation call meant to drop leftover entries instead removes the entire array. (The attribute loop below uses
+  `for (i = 0; ...)` without `let`, so it truncates correctly — proving the intent.) The key therefore always reports
+  "no inline styles", while `hash()`/`equals()` treat that as a real property of the element.
+- **Failure scenario**: `imageViewA.css({ filter: 'grayscale(1)' })` on an `<img src="x.png" class="icon">`, then
+  `imageViewA.destroy()` → `key.initializeFromElement(el)` records the tag and attributes but **not** the filter →
+  the element is pooled under a key that claims no styles. Later `new ImageView('x.png', {classList:['icon']})`
+  builds a style-less key, `view_pool.get(key)` matches, and the recycled element is returned still carrying
+  `filter: grayscale(1)` → the new image renders greyed out.
+- **Fix**: rename the inner loop variable (or hoist it) so the splice truncates from `styleCount`.
+- **Confidence**: Confirmed
+
+### VIEW-13 `TabbedView` never attaches its toggle and panel containers — it renders nothing
+- **Severity**: MAJOR
+- **File**: `src/view/common/TabbedView.js:49-57`
+- **Defect**: The constructor creates `this.el`, then `this.__panelContainer` and `this.__toggleContainer`, but never
+  calls `this.addChild(...)` on either, and neither does `link()`. Every toggle and panel is added to a container
+  that is not in the view tree.
+- **Failure scenario**: `const t = new TabbedView({tabs}); parent.addChild(t);` → a bare empty `<div>`. Tab toggles
+  and the active panel exist as detached DOM and are never linked (so their signal bindings never activate either).
+- **Fix**: `this.addChild(this.__toggleContainer); this.addChild(this.__panelContainer);` in the constructor.
+- **Confidence**: Confirmed
+
+### VIEW-14 `MinimapFogOfWar.enforceAspectRatio` computes the wrong growth in the "too wide" branch
+- **Severity**: MAJOR
+- **File**: `src/view/minimap/gl/MinimapFogOfWar.js:16-38`
+- **Defect**: When `aspectRatioDelta <= 0` the code grows the width by `-aabbWidth * aspectRatioDelta`. Solving,
+  the resulting ratio is `aabbHeight / (aabbWidth * (1 + aAR - vAR))`, which only equals `vAR` by coincidence. The
+  height branch is correct (`aabbWidth * delta` yields exactly `aabbWidth * vAR`); the width branch is not the
+  mirror of it.
+- **Failure scenario**: minimap viewport 200×100 (`vAR = 0.5`), revealed fog region a 100×100 square (`aAR = 1`).
+  `delta = -0.5`, `d = 50`, new bounds 150×100 → ratio 0.667, not 0.5. `focusArea` is set to that region and drives
+  the orthographic camera in `MinimapWorldGL.updateCameraFocus`, so the minimap world is squashed horizontally by
+  ~33%: terrain, entity markers and the camera frustum polygon (which are positioned from `worldScale`) no longer
+  line up with the fog-of-war overlay.
+- **Fix**: `const d = aabbHeight / viewportAspectRatio - aabbWidth;` (equivalently grow to `aabbHeight / vAR`).
+- **Confidence**: Confirmed
+
+### VIEW-15 `ListView.insertOne` dereferences an undefined sibling view when a filter is in play
+- **Severity**: MAJOR
+- **File**: `src/view/common/ListView.js:182-197`
+- **Defect**: For a non-terminal insert it looks up `this.model.get(index + 1)` and calls `nextChild.el` without
+  checking that a view exists for it. `getChildByElement` returns `undefined` whenever the next element was skipped
+  by `this.filter` (or when the list contains duplicate elements — `viewMapping` is keyed by element identity, so a
+  duplicate overwrites the previous entry).
+- **Failure scenario**: `new ListView(model, {elementFactory, filter: e => e.visible})`. Model is `[A(visible),
+  C(hidden)]`; insert `B(visible)` at index 1. `insertOne` creates B's view, sees `model.length (3) !== index+1 (2)`,
+  fetches `C`, `getChildByElement(C)` → `undefined` → `TypeError: Cannot read properties of undefined (reading 'el')`
+  inside the `model.on.added` dispatch. Signal logs it and swallows it, so the symptom is a silently mis-ordered list
+  (B stays appended at the end) plus a console error on every filtered insert.
+- **Fix**: scan forward from `index + 1` for the first element that has a view; if none, leave the child appended.
+- **Confidence**: Confirmed
+
+### VIEW-16 `DomSizeObserver.attach()` unobserves the new element and never observes it
+- **Severity**: MAJOR
+- **File**: `src/view/util/DomSizeObserver.js:147-153`
+- **Defect**:
+  ```js
+  attach(element) {
+      this.element = element;                                   // old reference already lost
+      if (this.running) { this.__dom_resize_observer.unobserve(this.element); }  // unobserves the NEW element
+  }
+  ```
+  The old element is never unobserved (it stays in the `ResizeObserver`), and the new element is never observed
+  because `attach` only ever calls `unobserve`.
+- **Failure scenario**: `o.attach(elA); o.start();` then `o.attach(elB)` while running. `unobserve(elB)` is a no-op
+  (B was never observed), A remains observed. Resizing B produces no callback at all — `o.dimensions` goes stale.
+  Resizing A *does* fire the callback, which then measures **B** via `resizeAABB2ToFitBoundingClientRect(this.element…)`
+  for the position but takes `rect.width/height` from **A's** `contentRect` → `dimensions` is a mix of two elements.
+- **Fix**: capture the previous element, `unobserve(previous)` if running, assign, then `observe(element)` if running.
+- **Confidence**: Confirmed
+
+### VIEW-17 `SimpleWindowView` resize handler accumulates the full drag delta on every pointer move
+- **Severity**: MAJOR
+- **File**: `src/view/elements/SimpleWindow.js:47-73`
+- **Defect**: `anchor` is captured once on pointer-down and never advanced, yet the move handler does
+  `view.size.add(position - anchor)` — an *incremental* mutation fed an *absolute* delta. Compare
+  `BottomLeftResizeHandleView` (`elements/BottomLeftResizeHandleView.js:31-40`), which correctly does
+  `lastPosition.copy(position)` each move.
+- **Failure scenario**: `new SimpleWindowView(content, {resizable: true})`. Grab the bottom-right 10 px corner and
+  drag 10 px right over 5 pointer-move events (deltas 2, 4, 6, 8, 10 relative to the fixed anchor) → the width grows
+  by 30 px instead of 10. A slow 200 px drag over 100 events grows the window by ~10 000 px; the window runs away
+  from the cursor and cannot be resized back down.
+- **Fix**: either update `anchor` to `position` at the end of each move, or capture `originalSize` on pointer-down and
+  use `view.size.copy(originalSize).add(delta)`.
+- **Confidence**: Confirmed
+
+### VIEW-18 `ToastLogView` registers every notification twice in `children`
+- **Severity**: MAJOR
+- **File**: `src/view/elements/notify/ToastLogView.js:47,72-88`
+- **Defect**: The constructor reassigns `this.children = []` (shadowing the base `View.children` array), and `addOne`
+  then does **both** `self.addChild(childView)` — which pushes onto `this.children` — **and**
+  `self.children.push(childView)`. Every toast appears twice in the array. `removeChildView` splices out one
+  occurrence and bypasses `View.removeChild`, so the second entry survives with its DOM node already detached.
+- **Failure scenario**: Two notifications A then B. `children` = `[A, A, B, B]`, so `updatePositions` computes
+  `maxIndex = 3`: A ends at `-(3-1)*24 = -48 px` and B at `0`, instead of `-24` and `0` → a 24 px gap opens between
+  the two toasts and the stack floats one row too high. After A's fade-out, `children` = `[A, B, B]` and A's stale
+  entry keeps skewing every subsequent layout. If the view is ever destroyed, `View.destroy`/`removeAllChildren`
+  walks the duplicates and calls `this.el.removeChild(A.el)` on an already-detached node → `NotFoundError`.
+- **Fix**: delete the `this.children = []` reassignment and the manual `push`; use `View.removeChild` in
+  `removeChildView`. Also cancel the pending `setTimeout` handles on unlink and unsubscribe
+  `model.elements.on.added` (currently a permanent subscription, `:90`).
+- **Confidence**: Confirmed
+
+### VIEW-19 `RadialProgressView` subscribes to its external model permanently
+- **Severity**: MAJOR
+- **File**: `src/view/elements/radial/RadialProgressView.js:55-68`
+- **Defect**: `model.on.changed.add(update)` / `model[0].onChanged.add(redraw)` / `model[1].onChanged.add(redraw)` are
+  raw subscriptions on caller-owned objects, made in the constructor and never removed — the class has no `unlink()`
+  or `destroy()` override, and does not use `bindSignal`.
+- **Failure scenario**: `view/units/UnitRadialPreview.js:23` builds
+  `new RadialProgressView([unit.healthCurrent, unit.stats.healthMax], …)`. The unit outlives the preview widget
+  (health is model state). Every time a unit preview is created and discarded, the unit's `healthCurrent` signal
+  retains `redraw`, which closes over the view, its SVG element and its `thickness` observable — the whole widget is
+  unreclaimable, and every health tick redraws N dead widgets. Cycling a roster panel a few hundred times leaks
+  hundreds of SVG subtrees.
+- **Fix**: route all three through `this.bindSignal(...)` so they follow the view's link lifecycle.
+- **Confidence**: Confirmed
+
+### VIEW-20 `createInterfaceCommandButton` subscribes to the command's feature signals twice, one of them forever
+- **Severity**: MAJOR
+- **File**: `src/view/interaction/createInterfaceCommandButton.js:91-99`
+- **Defect**:
+  ```js
+  if (interaction.features !== undefined) {
+      interaction.features.on.added.add(addCommandFeature);        // permanent
+      interaction.features.on.removed.add(removeCommandFeature);   // permanent
+  }
+  button.bindSignal(interaction.features.on.added, addCommandFeature);      // link-scoped (correct)
+  button.bindSignal(interaction.features.on.removed, removeCommandFeature); // link-scoped (correct)
+  ```
+  `InteractionCommand` always constructs `this.features = new List(features)` (`interaction/InteractionCommand.js:40`),
+  so the `if` is always taken and the first pair is always added. Nothing ever removes them.
+- **Failure scenario**: `InteractionCommand` instances are long-lived and shared — `InteractionCommandSet` keys them
+  by id. A command bar that is rebuilt on every selection change produces a new `ButtonView` per command each time;
+  each one permanently registers two closures on the shared command's feature list. After 100 selection changes,
+  `interaction.setFeature('highlighted', true)` invokes `addCommandFeature` on 100 discarded buttons, and all 100
+  button subtrees are unreclaimable.
+- **Fix**: delete the raw `on.added`/`on.removed` subscriptions; the `bindSignal` pair already covers the live case
+  and `button.on.linked` already replays the current features.
+- **Confidence**: Confirmed
+
+### VIEW-21 `MeshPreview` multiplies its pointer handlers on every link, and dereferences a null camera
+- **Severity**: MAJOR
+- **File**: `src/view/elements/MeshPreview.js:204-234`
+- **Defect**: (a) `link()` attaches a fresh `self.pContents.then(...)` continuation each time. Because `pContents` is
+  already settled after the first load, every subsequent link immediately runs `__addInteraction`, which creates a
+  **new** `PointerDevice`, calls `start()` on it, and adds another `dragStart`/`drag` pair that mutates
+  `contents.group.rotation` — none of which is ever stopped in `unlink()`. (b) `__update_renderer_size` guards on
+  `this.renderer !== null` but then touches `this.camera.aspect`; `camera` is only assigned in the asset callback.
+- **Failure scenario (a)**: Open a unit-detail panel containing a `MeshPreview`, close it, open it again. Two
+  `PointerDevice`s are now live on the pooled canvas; one drag rotates the model twice as fast. After ten cycles the
+  model spins ~10× per pixel of drag. (b): `preview.size.set(256, 256)` after linking but before the glTF resolves —
+  the bound `size.onChanged` fires with `renderer` set and `camera` still `null` →
+  `TypeError: Cannot set properties of null (setting 'aspect')`.
+- **Fix**: attach the `pContents` continuation once in the constructor and have it store `contents.group`; create the
+  `PointerDevice` once and `start()`/`stop()` it from `link`/`unlink`. Guard `__update_renderer_size` on
+  `this.camera !== null` as well (it is genuinely null until the async load lands).
+- **Confidence**: Confirmed
+
+### VIEW-22 `renderModel` caches the caller's live `size`/`focus` objects, so resizes return the stale image
+- **Severity**: MAJOR
+- **File**: `src/view/renderModel.js:15-29,85-92`
+- **Defect**: The cache entry stores `size: size` and `focus: focus` by reference, and `findInCache` compares with
+  `piece.size.equals(size)` / component-wise on `focus`. When the caller passes a mutable vector, the cached entry's
+  key mutates in lockstep with the query, so the comparison always succeeds.
+- **Failure scenario**: `MeshView.render()` (`common/MeshView.js:61`) passes `this.size` and `this.focus` straight
+  through. Render a mesh preview at 50×50 — cached with `piece.size === view.size`. Resize the view to 200×200:
+  `update()` sees the change and calls `render()`, `findInCache(url, this.size, this.focus)` compares `this.size`
+  against itself → hit → the 50×50 `dataURL` is returned and stretched to 200×200 (blurry), and no re-render is ever
+  scheduled. The cache also has no eviction (`cache.push` only), so it grows without bound.
+- **Fix**: store `size.clone()` and a copied `AABB2` in the cache entry; add an eviction policy (the codebase already
+  has `core/cache/Cache`).
+- **Confidence**: Confirmed
+
+### VIEW-23 `MeshView` never reacts to its own model
+- **Severity**: MAJOR
+- **File**: `src/view/common/MeshView.js:72-92`
+- **Defect**: The view observes `this.size` only. `update()`'s change test compares `size` and `focus` against
+  `renderedParams` and ignores the model entirely, so even an explicit `update()` after a model change does nothing.
+  `this.model.onChanged` is never bound.
+- **Failure scenario**: `meshView.model.set('models/sword.gltf')` on a linked `MeshView` currently showing
+  `models/axe.gltf` → nothing happens; a manual `meshView.update()` also short-circuits on "no change". The view keeps
+  displaying the axe until the element is resized.
+- **Fix**: `this.bindSignal(this.model.onChanged, this.render, this)`, and include the rendered URL in
+  `renderedParams` so `update()` detects it.
+- **Confidence**: Confirmed
+
+### VIEW-24 `RectangularPieProgressView` assumes a square element; on any other aspect the path becomes invalid
+- **Severity**: MAJOR
+- **File**: `src/view/elements/progress/RectangularPieProgressView.js:77-107`
+- **Defect**: The fraction thresholds `.125 / .375 / .625 / .875` place the corner transitions at 45°, which is only
+  where the corners are for a square. For a non-square element the sweep ray exits through a different edge than the
+  branch tests, `segment2_segment_compute_intersection_array_2d` returns `false` and leaves `p` empty, and the path
+  string is built from `p[0]`/`p[1]` === `undefined`.
+- **Failure scenario**: `v.size.set(100, 50); v.model.set(13); v.max.set(100)` (fraction 0.13 → branch 2, which tests
+  the **right** edge). `angle ≈ 43°` from the centre `(50,25)`: reaching `x = 100` needs `Δy = -47`, i.e. `y = -22`,
+  outside the edge segment — the ray actually exits through the **top** edge at `x ≈ 76.6`. No intersection is
+  written, so `d` becomes `"M 50 0 L 50 25 L undefined undefined L 100 50 L 0 50 L 0 0 Z"`. Browsers reject the whole
+  `d` attribute → the cooldown overlay disappears entirely for that fraction range.
+  (In-repo the only caller, `view/units/ability/CombatAbilityView.js:30`, sizes it 64×64, so the game path is safe —
+  but this is a public class with a `size` the caller controls.)
+- **Fix**: compute the corner fractions from the actual aspect (`atan2(size_y, size_x)` etc.) instead of hard-coded
+  eighths, or pick the edge by testing all four and taking whichever intersects.
+- **Confidence**: Confirmed
+
+### VIEW-25 `EmptyView.absolute` nests the caller's CSS instead of spreading it
+- **Severity**: MAJOR
+- **File**: `src/view/elements/EmptyView.js:54-72`
+- **Defect**:
+  ```js
+  css: {
+      css,                          // shorthand -> a property literally named "css"
+      ...CSS_ABSOLUTE_POSITIONING
+  }
+  ```
+  The intent is clearly `...css`. `View.css(hash)` then executes `this.el.style['css'] = {…}`, which the CSSOM
+  ignores.
+- **Failure scenario**: `EmptyView.absolute({ css: { width: '100px', backgroundColor: 'red' } })` produces an element
+  with only `position/top/left` applied; width and background are silently dropped, so the element collapses to zero
+  size. No error is raised anywhere.
+- **Fix**: `css: { ...css, ...CSS_ABSOLUTE_POSITIONING }`.
+- **Confidence**: Confirmed
+
+### VIEW-26 `TileGridView` subscribes to the model and the DnD context outside the view lifecycle
+- **Severity**: MAJOR
+- **File**: `src/view/elements/tiles2d/TileGrid.js:135-136,301-338,411-419`
+- **Defect**: `model.tiles.on.added.add(this.addTile, this)` and `.on.removed.add(this.removeTile, this)` are raw
+  subscriptions (not `bindSignal`) with no counterpart anywhere. Likewise every slot registers a `DropTarget` into
+  `this.__dragAndDropContext` via `addTarget` (which immediately `link()`s DOM listeners) and every tile registers a
+  `Draggable` via `addElement`; neither `removeTarget` nor `removeElement` is ever called, and the context is a
+  constructor parameter, i.e. typically shared across grids.
+- **Failure scenario**: An inventory panel builds a 10×6 `TileGridView` against a shared `DragAndDropContext` each
+  time it opens. Every open/close cycle permanently adds 60 `DropTarget`s (each with 4 DOM listeners) and one
+  `Draggable` per item to `context.targets`/`context.elements`, and leaves the grid subscribed to `model.tiles`. After
+  20 cycles, `DragAndDropContext.finalizeDrag` iterates 1200+ targets on every drop, `getElementById` scans hundreds
+  of dead draggables, and adding an item to the inventory while all panels are closed calls `addTile` on 20 detached
+  grids. Removing an item calls `removeTile` on grids where `findTileView` returns `undefined`, so
+  `this.__hookTileRemoved(undefined, tile)` fires with an undefined view.
+- **Fix**: route the two model subscriptions through `bindSignal`; add an `unlink()` that calls
+  `context.removeTarget(slotView)` for each slot and `context.removeElement(draggable)` for each tile, and rebuild on
+  `link()`.
+- **Confidence**: Confirmed
+
+### VIEW-27 `LocalizedLabelView.update()` dereferences a null localization outside the try
+- **Severity**: MAJOR
+- **File**: `src/view/common/LocalizedLabelView.js:122-154`
+- **Defect**: `localization = null` is the constructor default and the class explicitly tests for it at `:60`, so it
+  is an anticipated state. `update()` wraps only `localization.getString(...)` in `try/catch`; line 143
+  (`this.__localeKey = localization.locale.getValue()`) and the `$el.text(value)` fallback that follows are outside
+  it. The throw at 143 skips the fallback text.
+- **Failure scenario**: `new TaskProgressView({ task })` — `localization` defaults to `null`
+  (`task/TaskProgressView.js:20,29-33`) — then link. The `on.linked` handler calls `update()`, `getString` throws,
+  the catch sets `value = "failed to localize @…"`, then line 143 throws `TypeError: Cannot read properties of null
+  (reading 'locale')` before the text is written. Signal's dispatch try/catch swallows it, so the loading screen's
+  task-name label renders completely blank with two console errors per link.
+- **Fix**: return early (writing the raw `@id` fallback) when `localization === null`, and move the `__localeKey`
+  assignment after a successful `getString`.
+- **Confidence**: Confirmed
+
+### VIEW-28 `MarkerGL` leaks atlas patch references acquired across shutdown / rapid icon changes
+- **Severity**: MAJOR
+- **File**: `src/view/minimap/gl/MarkerGL.js:57-87,109-118`
+- **Defect**: `updateIcon` releases the *current* `this.patch`, then awaits `atlasManager.acquire(newURL)`. The
+  continuation assigns `this.patch = patch` and then bails on `!this.active` — but the freshly acquired reference is
+  never released on that path. Similarly, two `updateIcon` calls in flight both release `Reference.NULL` up front and
+  the first resolved patch is overwritten (and leaked) by the second.
+- **Failure scenario**: A unit with a minimap marker is killed while its icon texture is still being fetched
+  (`MinimapMarkersGL.removeElement` → `markerGL.shutdown()` → `active = false`, releases `Reference.NULL`). The
+  `acquire` promise then resolves, stores the patch on the dead marker and returns without releasing it → the
+  `ManagedAtlas` never frees that icon's slot. Repeated over a battle with many short-lived markers, the atlas fills
+  up and later markers fail to get a patch.
+- **Fix**: in the continuation, if `!this.active`, call `patch.release()` before returning; also release the previous
+  `this.patch` when overwriting it rather than at call time.
+- **Confidence**: Confirmed
+
+### VIEW-29 `DropTarget` drag-enter tracking has no dedup and splices with `-1`
+- **Severity**: MAJOR
+- **File**: `src/view/common/dnd/DropTarget.js:72-92,212-236`
+- **Defect**: `handleDragEnter` pushes into `isInState_ENTER` unconditionally, and
+  `attachDropValidityIndicators.handleDragEnter` unconditionally appends a `{draggable, bindings}` record with a fresh
+  `SignalBinding` on `draggable.on.dragFinalized`. `removeDraggable` removes exactly one record per call.
+  `handleDragLeave` additionally does `isInState_ENTER.splice(indexOf(e), 1)` without checking for `-1`, and
+  `splice(-1, 1)` removes the *last* element.
+- **Failure scenario**: `Draggable.link()` explicitly routes `dragenter` to the parent drop target
+  (`common/dnd/Draggable.js:103-106`) *and* the event bubbles to the drop target's own listener — so dragging an item
+  over another item inside the same slot fires `handleDragEnter` twice for one enter. `current` gains two records and
+  two live bindings. On drop, `dragFinalized` fires once, `removeDraggable` clears one record, and `update()` still
+  sees a non-empty `current` → the slot keeps its `drop-target-hover-valid` class permanently after the drag ends,
+  and each further hover leaks another `SignalBinding` on the draggable.
+- **Fix**: dedup on enter (skip if the draggable is already tracked), loop `removeDraggable` until it returns false on
+  finalize, and guard the `indexOf === -1` case before splicing.
+- **Confidence**: Likely
+
+### VIEW-30 A throwing tooltip factory disables tooltips globally for the rest of the session
+- **Severity**: MAJOR
+- **File**: `src/view/tooltip/TooltipManager.js:129-138`
+- **Defect**:
+  ```js
+  gml.pushState();
+  gml.setTooltipsEnabled(false);
+  const factoryProduct = tip.factory.call(tip.factoryContext);   // may throw
+  gml.popState();
+  ```
+  There is no `try/finally`. `GMLEngine.compile`/`compileAsText` both use `try { … } finally { this.popState(); }`
+  (`tooltip/gml/GMLEngine.js:481-493,512-525`), so the omission here is clearly unintended.
+- **Failure scenario**: A single tooltip factory throws (e.g. an item tooltip for an item whose data row is missing).
+  `popState()` is skipped, so `__tooltipsEnabled` stays `false` and one orphan frame stays on `__contextStack`. Every
+  reference compiler that consults `gml.getTooltipsEnabled()` from then on sees `false` → nested tooltips stop being
+  attached anywhere in the UI until reload.
+- **Fix**: wrap the factory call in `try { … } finally { gml.popState(); }`.
+- **Confidence**: Confirmed
+
+### VIEW-31 `RadialMenu.init()` leaves the previous element views attached, and shared icon views get stolen
+- **Severity**: MAJOR
+- **File**: `src/view/elements/radial/RadialMenu.js:194-223`, `src/view/elements/radial/RadialMenuElement.js:70`
+- **Defect**: `init()` resets `this.elements = []` but never removes the previously created `RadialMenuElement`
+  children from `this.vElementContainer`. Separately, `RadialMenuElement`'s constructor does
+  `this.addChild(description.iconView)` — the icon `View` lives on the caller-owned
+  `RadialMenuElementDefinition`, and `View.addChild` re-parents it (`child.parent = this; this.el.appendChild(child.el)`).
+- **Failure scenario**: (a) `menu.init(newItems)` on an existing menu — the old wedges, labels and icons stay in the
+  DOM underneath the new ones, and `selectByAngle`/`render` only touch the new set, so the stale wedges are frozen in
+  place and never highlight. (b) Building two `RadialMenu`s from the same `items` array (definitions are plain data
+  objects that are easy to reuse) — the second menu's `addChild` moves every `iconView`'s DOM node out of the first
+  menu, leaving the first menu iconless while both `children` arrays still list it.
+- **Fix**: `this.vElementContainer.removeAllChildren()` at the top of `init()`; and either clone the icon view per
+  element or document/enforce one definition per menu.
+- **Confidence**: Confirmed
+
+### VIEW-32 `ConfirmationDialogView` builds a class name that can contain a space
+- **Severity**: MAJOR
+- **File**: `src/view/elements/ConfirmationDialogView.js:38`
+- **Defect**: `"button-" + option.name.replace(' ', '-')` — `String.replace` with a string pattern replaces only the
+  **first** occurrence. The result is handed to `ButtonView`'s `classList`, which reaches `DOMTokenList.add()`.
+- **Failure scenario**: `new ConfirmationDialogView(content, [{name: 'cancel all now', displayName: 'Cancel', …}])`
+  → class token `"button-cancel-all now"` → `classList.add` throws
+  `InvalidCharacterError: The string contains invalid characters`, aborting the whole dialog construction so no
+  confirmation dialog is shown at all.
+- **Fix**: `option.name.replace(/\s+/g, '-')`, or reuse `string_tag_to_css_class_name`.
+- **Confidence**: Confirmed
+
+### VIEW-33 `VirtualListView` disables the scrollbar one row too early, and `AlignmentOption.Center` does nothing
+- **Severity**: MINOR
+- **File**: `src/view/common/VirtualListView.js:181-196`
+- **Defect**: The "everything fits" test is
+  `row_height * (last_visible_line - first_visible_line) < this.size.y`, i.e. it measures `n-1` rows instead of `n`.
+  Separately, `AlignmentOption.Center` is exported and accepted as `verticalAlignment` but the offset block only
+  handles `End`, so `Center` silently behaves like `Start`.
+- **Failure scenario**: `lineSize = 20, lineSpacing = 0`, 5 elements, `size.y = 90` (content 100 px). `l0 = 0`,
+  `l1 = 4 = numTotalElements - 1`, and `20 * (4 - 0) = 80 < 90` → `__setScrollBar(false)` and `rowWidth` is not
+  reduced. The list declares itself fully visible while the 5th row is clipped by 10 px and cannot be scrolled to.
+- **Fix**: compare `row_height * (last - first + 1) <= this.size.y`; implement the `Center` branch
+  (`line_offset_y = (this.size.y - total_lines_height) / 2`).
+- **Confidence**: Confirmed
+
+### VIEW-34 `DropDownSelectionView.setSelectedValue` uses the model index against always-appended options
+- **Severity**: MINOR
+- **File**: `src/view/elements/DropDownSelectionView.js:55-68,141-143`
+- **Defect**: `handleAdded(el, index)` ignores `index` and always `appendChild`s, while `setSelectedValue` does
+  `this.el.selectedIndex = this.model.indexOf(v)`. The two orderings only agree when elements are appended.
+  (`getSelectedValue` correctly resolves through the id map, so the two accessors disagree.) `handleRemoved` also
+  never deletes the entry from `this.mapping`.
+- **Failure scenario**: `model.insert(0, x)` on a populated list — `x`'s `<option>` lands last while `model.indexOf(x)`
+  is `0`, so `setSelectedValue(x)` selects whatever element was originally first.
+- **Fix**: honour `index` in `handleAdded` (`insertBefore` the option at `index`), and delete the mapping entry in
+  `handleRemoved`.
+- **Confidence**: Confirmed
+
+### VIEW-35 `MinimapCameraView.castTerrainRay` jitters an origin it never uses
+- **Severity**: MINOR
+- **File**: `src/view/minimap/dom/MinimapCameraView.js:99-117`
+- **Defect**: The retry loop perturbs `oX/oY/oZ` but calls
+  `terrain.raycastFirstSync(rayContact, originX, originY, originZ, …)` with the *unperturbed* origin every iteration.
+  `oX/oY/oZ` are written and never read.
+- **Failure scenario**: A frustum corner ray that lands exactly on a terrain triangle edge misses. The stated purpose
+  of the loop — "jitter origin in case of mathematical error at polygon edges" — never happens; instead the identical
+  raycast runs 10 times and then falls back to the flat `y = 0` plane. On elevated terrain that corner of the minimap
+  camera-frustum polygon is drawn at the ground-plane intersection instead of the terrain surface, so the frustum
+  outline visibly snaps outward for that corner.
+- **Fix**: pass `oX, oY, oZ` to `raycastFirstSync`.
+- **Confidence**: Confirmed
+
+### VIEW-36 `DOM.prototype.clear()` does not remove text nodes
+- **Severity**: MINOR
+- **File**: `src/view/DOM.js:131-137`
+- **Defect**: The loop iterates `el.children` (elements only), so text nodes survive a method documented as
+  "removes all children".
+- **Failure scenario**: `const d = domify('div'); d.text('Loading…'); d.clear(); d.append(other);` → the element still
+  reads "Loading…" followed by the appended content. This is reachable through
+  `LocalizedLabelView.update()` (`$el.text(value)` on the non-GML path) followed by a switch to a GML-compiled value,
+  which calls `removeAllChildren()` and then appends compiled views next to the leftover text node; also
+  `MinimapView.link()` (`minimap/Minimap.js:217-219`) relies on `clear()` before appending the WebGL canvas.
+- **Fix**: `while (el.firstChild) el.removeChild(el.firstChild);`
+- **Confidence**: Confirmed
+
+### VIEW-37 `setElementTransform.js` exports nothing
+- **Severity**: MINOR
+- **File**: `src/view/setElementTransform.js:13`
+- **Defect**: The module declares `function setElementTransform(...)` with no `export` and no default export, so the
+  file's only purpose is unreachable.
+- **Failure scenario**: `import { setElementTransform } from '.../setElementTransform.js'` →
+  `SyntaxError: The requested module does not provide an export named 'setElementTransform'` at build time.
+- **Fix**: `export function setElementTransform(...)`.
+- **Confidence**: Confirmed
+
+### VIEW-38 `DatGuiUtils.makeDatController` references an undeclared `p` in its cycle branch
+- **Severity**: MINOR
+- **File**: `src/view/controller/dat/DatGuiUtils.js:377-380`
+- **Defect**: ``console.warn(`Detected cycle at "${p}" …`)`` — `p` is the loop variable of `makeDatControllerForObject`,
+  not of this function. Modules are strict-mode, so this is a `ReferenceError`, not `undefined`. The intended
+  identifier is `propertyName`.
+- **Failure scenario**: `makeDatController` is exported (`:451`). A direct call
+  `makeDatController(gui, obj, 'child', pathContainingObjChild)` hits the cycle branch and throws
+  `ReferenceError: p is not defined` instead of warning and returning `0`, aborting the whole controller build.
+- **Fix**: use `${propertyName}`.
+- **Confidence**: Confirmed
+
+### VIEW-39 `GroupView.remove()` leaves the removed child linked; `update()` calls a method `View` does not have
+- **Severity**: MINOR
+- **File**: `src/view/elements/Group.js:8,11-30`
+- **Defect**: `add`/`remove` bypass `View.addChild`/`View.removeChild`: `child.parent` is never set and `remove` never
+  calls `child.unlink()`. `update()` invokes `c.update()` on each child, but `View` defines no `update`.
+- **Failure scenario**: `group.add(labelView); group.link(); group.remove(labelView);` — the label's DOM node is
+  detached but the view stays linked, so its `bindSignal` subscriptions keep firing and keep writing to a node that is
+  no longer in the document. `group.update()` with any plain `EmptyView` child →
+  `TypeError: c.update is not a function`.
+- **Fix**: delegate to `View.addChild`/`View.removeChild` (and drop the `this.children = []` reassignment); remove
+  `update()` or make it guard on the method existing.
+- **Confidence**: Confirmed
+
+### VIEW-40 `WindRoseDiagram` sizes itself for icons that may not exist, and re-registers tooltips on every draw
+- **Severity**: MINOR
+- **File**: `src/view/elements/windrose/WindRoseDiagram.js:90-94,197-336`
+- **Defect**: (a) `const has_icons = axes.some(isDefined)` tests whether each *axis object* is defined, not whether it
+  has an `icon`; for any non-empty `axes` array this is always `true`. (b) `draw_canvas()` calls
+  `container.removeAllChildren()` and rebuilds every label/icon, then calls `this.__tooltips.add(view, …)` for each —
+  `DomTooltipManager.add` links a `DomTooltipObserver` immediately and is never paired with `remove`.
+- **Failure scenario**: (a) `new WindRoseDiagram({axes: [{name:'a'},{name:'b'},{name:'c'}], radius_outer: 100,
+  icon_size: 32})` (no icons at all) → `size = 200 + 32*1.207*2 ≈ 277` instead of `200`; the widget claims 77 px more
+  in both axes than it draws, pushing neighbours around in a flex row. (b) `draw()` runs on every `on.linked`; after
+  10 open/close cycles each axis label has 10 live `DomTooltipObserver`s with `mouseenter`/`mouseleave` listeners on
+  detached elements.
+- **Fix**: `axes.some(a => a.icon !== undefined)`; use `tooltips.manage(view, …)` (which self-registers on
+  link/unlink) rather than `add`.
+- **Confidence**: Confirmed
+
+### VIEW-41 `ImageView`/`VideoView` never re-apply an observed URL on link
+- **Severity**: MINOR
+- **File**: `src/view/elements/image/ImageView.js:65-71`, `src/view/elements/video/VideoView.js:77-83`
+- **Defect**: The `src` is baked into the cache key at construction and thereafter only updated by the
+  `url.onChanged` → `__setSource` binding, which is a `bindSignal` and therefore inactive while unlinked. There is no
+  `on.linked` initial-apply.
+- **Failure scenario**: An `ImageView` bound to an `ObservedString` icon URL sits in a panel. Close the panel (view
+  unlinks, binding detaches), the underlying model swaps the icon (equip a different item), reopen the panel — the
+  binding re-links but is never invoked, so the `<img>` still shows the previous icon until the URL happens to change
+  again while the panel is open.
+- **Fix**: add `this.on.linked.add(() => this.__setSource(url.getValue()), this)` in the observed-URL branch (mirroring
+  `LabelView.link()`, which re-runs `updateTransform()`).
+- **Confidence**: Confirmed
+
+### VIEW-42 `ButtonView` never applies its initial enabled/disabled class
+- **Severity**: MINOR
+- **File**: `src/view/elements/button/ButtonView.js:94,101-110`
+- **Defect**: `__enabled` is initialised by direct field assignment, bypassing the setter, and the setter early-returns
+  when the value is unchanged. A button that is enabled from birth therefore carries **neither** `.enabled` nor
+  `.disabled`.
+- **Failure scenario**: `.ui-button-view.disabled { opacity: .4 }` + `.ui-button-view.enabled { cursor: pointer }`
+  style rules — a freshly created enabled button matches neither. `createInterfaceCommandButton` masks this because
+  its `on.linked` handler calls `updateEnableStatus()`, but that only helps when the command's `enabled` differs from
+  `true`; a permanently-enabled command's button never gets the class.
+- **Fix**: set the class explicitly at the end of the constructor (`this.setClass('enabled', true);
+  this.setClass('disabled', false);`) rather than relying on the setter's change detection.
+- **Confidence**: Likely