@woosh/meep-engine 3.0.2 → 3.2.0

package/src/REVIEW_2026_08_06/engine-input.md

@@ -1,197 +1,197 @@
-# Correctness review — `engine/input/` + `engine/control/`
-
-Scope: every non-spec source file under
-`H:/git/moh/app/src/mir-engine/meep/src/engine/input/` and
-`H:/git/moh/app/src/mir-engine/meep/src/engine/control/`.
-
-Excluded per brief: `editor/`, `prototype*.js`, `*.spec.js` (read as evidence only), `.d.ts`.
-Already-fixed / already-captured / known-good items are not re-reported.
-
-Two findings (INPUT-3, INPUT-4) were **empirically confirmed** with a throw-away
-full-pipeline harness (physics + sensors + controller + WallRun/WallJump, modelled on
-`WallRunScenarios.spec.js`); the harness was deleted afterwards. Observed output is
-quoted inline.
-
----
-
-### INPUT-1 `TopDownCameraControllerHelper` throws on every call — geometry classes never imported
-- **Severity**: CRITICAL
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/ecs/util/TopDownCameraControllerHelper.js:45`
-- **Defect**: The module imports only `Group`, `Matrix4`, `Mesh`, `MeshLambertMaterial` from `three`, but the factory body constructs `new CylinderGeometry(...)` (line 45) and `new SphereGeometry(...)` (line 46). Both are unresolved free identifiers in an ES-module scope.
-- **Failure scenario**: `TopDownCameraControllerHelper(topDownController, targetTransform, 1)` → first statement of the function body → `ReferenceError: CylinderGeometry is not defined`. There is no code path through the function that avoids it; the helper is 100% dead on arrival for any library consumer.
-- **Fix**: add `CylinderGeometry`, `SphereGeometry` to the `three` import list (aliased in the local style, e.g. `CylinderGeometry as ThreeCylinderGeometry`) and use the aliases at lines 45–46.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-2 Pointer "down" state can never be cleared — no `pointercancel`, no blur recovery, `stop()` leaves the drag live
-- **Severity**: CRITICAL
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/PointerDevice.js:483` (`start`), `:499` (`stop`)
-- **Defect**: `start()` subscribes only to `pointermove` / `pointerup` / `pointerdown` / `wheel` / `contextmenu`. `PointerEvents.Cancel` is defined in `events/PointerEvents.js:13` but never subscribed, and there is no `window` `blur` handler (the sibling `KeyboardDevice` has one and documents exactly this hazard). Additionally `stop()` removes the listeners but leaves `buttons[i].is_down === true` and leaves `observeDrag`'s `handleDrag` / `handleDragEnd` registered on `on.move` / `#globalUp`. The only thing that ever calls `InputDeviceSwitch.release()` for the pointer is `#eventHandlerGlobalPointerUp`, and the only thing that ends a drag is `#globalUp` firing.
-- **Failure scenario** (touch, needs no API call): finger down on the canvas → `pointerdown` → `buttons[0].press()`, `observeDrag.handleDown` arms `noDrag` + `handleDragStart`. Finger moves → `pointermove` → `handleDragStart` fires `on.dragStart` and registers `handleDrag` on `on.move` and `handleDragEnd` on `#globalUp`. The browser now claims the gesture (pull-to-refresh / two-finger pan / palm rejection) and dispatches **`pointercancel`**; per spec no `pointerup` follows. Result: `pointer.mouseButtonLeft.is_down` stays `true` forever, `on.dragEnd` is never sent, and `handleDrag` stays subscribed — so the *next* pointer that merely hovers/moves over the element (second finger, stylus, mouse) makes `on.drag` fire with the stale `origin`, swinging the camera with no button held.
-  Second reachable path with no touch at all: `pointerDevice.domElement = otherEl` (public setter, `:431`) internally does `stop()` then `start()`; performed while the left button is held it produces the same stuck `is_down` + live drag.
-- **Fix**: subscribe `#eventHandlerGlobalPointerUp` to `PointerEvents.Cancel` on `window` as well (release the button and dispatch `#globalUp` so `handleDragEnd` runs), add a `window` `blur` handler that does the same for every pressed button, and have `stop()` release all `buttons[i]` and dispatch `#globalUp` once so any in-flight drag is torn down before the listeners go away.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-3 `InputControllerSystem` proxy mutates its binding array mid-dispatch — crashes or skips listeners
-- **Severity**: CRITICAL
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/ecs/systems/InputControllerSystem.js:62` (`Proxy.handler`), `:98` (`registerBinding`), `:132` (`remove`)
-- **Defect**: `handler()` caches `const l = bindings.length` and then indexes `bindings[i]` for `i < l`, while `add()` (→ `registerBinding`, which `push`es **and re-`sort`s**) and `remove()` (which `splice`s) both mutate that same array synchronously. The `running` flag and the `deferred` queue that were clearly meant to guard this are dead code — `running` is never set to `true`, so `add()` always takes the immediate path and `__processDeferred()` always drains an empty list.
-- **Failure scenario**: entities A and B both have an `InputController` bound to `pointer/on/down`, so the proxy holds `bindings = [A, B]`. A's listener destroys B's entity (a perfectly ordinary "click closes the panel" handler) → `ecd.removeEntity(B)` → `InputControllerSystem.unlink(B)` → `removeBindings` → `proxy.remove(bindingB)` → `bindings.splice(1,1)` → `bindings = [A]`. Control returns to `handler()`, which continues with `l === 2`: `i = 1` → `bindings[1] === undefined` → `const listener = binding.listener` → **`TypeError: Cannot read properties of undefined (reading 'listener')`**. (Signal's `try/catch` swallows it into `console.error`, so the remaining bindings on that path are silently dropped for that event.)
-  Non-crashing variant, same root cause: A's listener builds a new entity whose `InputController` binds the same path with a higher priority; `registerBinding` re-sorts the live array under the running loop, so an as-yet-unvisited sibling binding is skipped for that event and the freshly-created binding is invoked for the very event that created it.
-- **Fix**: iterate a snapshot (`const list = bindings.slice()`), or re-read `bindings.length` each iteration and iterate over a stable copy; alternatively finish the intended design — set `this.running = true` around the dispatch loop, route `add()`/`remove()` through `deferred` while running, and drain in `__processDeferred()`.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-4 `runtime.prevJumpHeld` is frozen while an ability owns motion — wall-jump silently dies mid wall-run
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/abilities/WallRun.js:114` (`tick`), `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/FirstPersonPlayerControllerSystem.js:1115`
-- **Defect**: `runtime.prevJumpHeld = intent.jump` is written only in `_advanceJumpFsm`, which runs exclusively inside `_runBaseLocomotion` — i.e. only on ticks where **no** ability owns motion. `Slide.tick` (`Slide.js:126`) and `ScrambleUp.tick` (`ScrambleUp.js:158`) explicitly maintain it themselves; `WallRun.tick` does not. `WallJump.canActivate` (`WallJump.js:50`) rejects when `runtime.prevJumpHeld` is true, so a stale `true` makes the ability permanently unreachable.
-- **Failure scenario**: sprint at a wall and jump into it **keeping the jump button held** (the natural input). Base locomotion latches `prevJumpHeld = true`; wall-run engages while it is still held, so base stops running and `prevJumpHeld` is frozen at `true`. The player then releases jump and presses it again to kick off the wall — `WallJump.canActivate` sees `prevJumpHeld === true`, returns `false`, and no wall-jump ever fires for the remainder of the wall-run. The canonical wall-run → wall-jump chain is lost; the player just rides the wall until the 2 s timer.
-  Harness output (full physics + sensors pipeline, jump held across wall-run entry at tick 24, released at 34, re-pressed at 37):
-  ```
-  { "wallRunStart": 24, "releasedAt": 34, "repressedAt": 37, "kicked": false,
-    "window": [ {"i":34,"act":"WallRun","prevJumpHeld":true,"jump":false,"vx":0},
-                ...
-                {"i":37,"act":"WallRun","prevJumpHeld":true,"jump":true,"vx":0},
-                {"i":40,"act":"WallRun","prevJumpHeld":true,"jump":true,"vx":0} ] }
-  ```
-  `vx` never leaves 0 — the body is never kicked off the wall. `WallRunScenarios.spec.js:193` passes only because its driver releases jump at tick 18, *before* wall-run engages at ~24.
-- **Fix**: make the jump-edge bookkeeping unconditional — move `runtime.prevJumpHeld = intent.jump` out of `_advanceJumpFsm` and into `_tickEntity` (after the ability layer, alongside `_resolveCrouchHeld`, which already does exactly this for crouch), and drop the per-ability copies in `Slide`/`ScrambleUp`/`WallJump`/`LedgeGrab` that exist only to work around the gap.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-5 Ability activation costs a whole fixed step of motion — nothing integrates on the activation tick
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/abilities/AbilitySet.js:123` (step 3), `:146` (return)
-- **Defect**: `AbilitySet.tick` returns `this.active === null`. On the tick where step 3 (or step 2) *activates* an ability it returns `false`, so `_tickEntity` skips `_runBaseLocomotion` (`FirstPersonPlayerControllerSystem.js:737`) — but the newly activated ability's own `tick()` is not called until the next fixed step (only `onActivate` ran). No layer moves the body: no gravity, no `_resolveMotion`, no ground categorisation, no `airborneTime`/`timeSinceGrounded` advance. The class docstring for step 1 explicitly claims "no wasted frame"; activation is exactly that wasted frame.
-- **Failure scenario**: sprint into a wall-run at ~7 m/s. Harness output for the activation tick (deltas of `transform.position` and `velocityY` across one `fixedUpdate`):
-  ```
-  {"i":22,"act":null,     "dx":-0.04276,"dy":0.08163,"dz":0.11748,"dvy":-0.97959}
-  {"i":23,"act":null,     "dx":-0.04276,"dy":0.06531,"dz":0.11748,"dvy":-0.97959}
-  {"i":24,"act":"WallRun","dx":0,       "dy":0,      "dz":0,      "dvy":0       }   <-- activation tick
-  {"i":25,"act":"WallRun","dx":0,       "dy":0.06327,"dz":0.11748,"dvy":-0.12245}
-  ```
-  The body is frozen for a full 16.7 ms — ~12 cm of lost travel and one skipped gravity step — on every slide entry, wall-run entry, scramble, ledge-grab and mantle. Visible as a one-frame hitch at each ability transition.
-- **Fix**: after activating in step 2/step 3, tick the newly activated ability in the same call (mirroring step 1's fall-through), and use its return value to decide the final `this.active`/`return` — i.e. hoist step 1's "tick then maybe release" into a small loop so a freshly activated ability owns motion on the tick it takes control.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-6 `KeyboardDevice.stop()` leaves held keys latched down
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/KeyboardDevice.js:214`
-- **Defect**: `stop()` unsubscribes all four listeners (element keydown/keyup, window keyup, window blur) but never releases the switches. The class docstring commits to the invariant for window blur ("any 'pressed' keys are forcibly released with the appropriate signal") — `#handleWindowBlurEvent` implements it, `stop()` does not, even though stopping guarantees the release can never be observed.
-- **Failure scenario**: hold `W`; the host calls `keyboard.stop()` (pausing input for a cutscene / modal / settings screen); release `W`; call `keyboard.start()`. `keys.w.is_down` is still `true` and no `keys.w.up` was ever dispatched. Every polling consumer (`keyboard.keys.w.is_down`) reads "held", and every edge consumer stays latched — e.g. `KeyboardCameraController` (`ecs/controllers/KeyboardCameraController.js:57`) sets `controls.panUp = false` only on `keys/w/up`, so the camera pans forward indefinitely after input resumes. It only clears when the player happens to press and release `W` again.
-- **Fix**: in `stop()`, run the same loop `#handleWindowBlurEvent` uses — `for (let keyName in KeyCodes) this.keys[keyName].release();` — so the switches and their `up` signals are consistent with "we can no longer observe releases".
-- **Confidence**: Confirmed
-
----
-
-### INPUT-7 `FirstPersonPlayerControllerConfig` drops `scrambleUp` on clone / copy / serialize, and `equals()` ignores it
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/FirstPersonPlayerControllerConfig.js:589` (`toJSON`), `:618` (`fromJSON`)
-- **Defect**: `scrambleUp` is declared as a config block (`:187`) and read by `ScrambleUp` (`abilities/ScrambleUp.js:67,86,126`), but it is absent from both `toJSON()`'s output object and `fromJSON()`'s assignment chain. `copy(other)` is implemented as `this.fromJSON(other.toJSON())` (`:658`), and `FirstPersonPlayerController.equals` (`FirstPersonPlayerController.js:201`) compares `JSON.stringify(config.toJSON())`.
-- **Failure scenario**: a designer tunes `controller.config.scrambleUp.maxJumpForce = 3000` (a deliberately weak climb). The controller component is cloned or round-tripped — `FirstPersonPlayerController.clone()` → `copy()` → `fromJSON(toJSON())` — as happens on prefab instantiation or a save/load. The clone silently reverts to the default `7200 N`, so the same character now scrambles roughly `√(7200/3000) ≈ 1.55×` faster off the wall and climbs ~2.4× higher. Separately, two controllers differing *only* in `scrambleUp` compare `equals() === true`, so change detection / dedup treats the retuned config as unchanged.
-- **Fix**: add `scrambleUp: { ...this.scrambleUp }` to `toJSON()` and `if (json.scrambleUp) Object.assign(this.scrambleUp, json.scrambleUp);` to `fromJSON()`.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-8 Jump buffer is decremented before it is tested — effective buffer is `bufferTime − dt`, and `bufferTime ≤ dt` disables jumping entirely
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/FirstPersonPlayerControllerSystem.js:1117`
-- **Defect**:
-  ```js
-  if (jumpPressedEdge) { state.jumpBufferRemaining = cfg.jump.bufferTime; }
-  state.jumpBufferRemaining = Math.max(0, state.jumpBufferRemaining - dt);   // decays on the press tick too
-  const canJumpNow = (...) && state.jumpBufferRemaining > 0 && ...;
-  ```
-  The freshly-armed buffer is aged by one full `dt` before it is ever tested, so the buffer is always one step shorter than configured and a buffer of one step or less is consumed before the gate reads it.
-- **Failure scenario**: a designer sets `cfg.jump.bufferTime = 0` to turn jump buffering off (the natural way to express "no buffering — jump only on the exact press"). Player stands on flat ground and presses jump: `jumpBufferRemaining = 0` → `max(0, 0 − 0.0167) = 0` → `canJumpNow` is `false` on the press tick, and there is no later tick with a rising edge, so **the player can never jump**. Same total failure at a 30 Hz fixed step (`dt = 0.0333`) with any `bufferTime ≤ 0.0333`.
-- **Fix**: age the buffer *before* re-arming it, i.e. `state.jumpBufferRemaining = Math.max(0, state.jumpBufferRemaining - dt); if (jumpPressedEdge) state.jumpBufferRemaining = cfg.jump.bufferTime;` — the press tick then always sees the full window.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-9 Stride-timing mastery curves are missing the closing keyframe — the last quarter of the gait cycle returns the peak bonus
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/mastery/StrideTimingJumpEvaluator.js:19`, `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/mastery/SlideInitiationTimingEvaluator.js:22`
-- **Defect**: Both curves are keyed at `0.00, 0.25, 0.50, 0.75` only, and are evaluated with a cyclic input (`controller.state.stridePhase ∈ [0,1)`). `AnimationCurve.evaluate` clamps past the last key (`engine/animation/curve/AnimationCurve.js:280-283`: `if (i >= key_count - 1) return keys[key_count - 1].value;`), so the whole interval `[0.75, 1.0)` returns the *peak* value instead of ramping back down toward the footfall trough at phase 1.0 ≡ 0.0. `BreathRhythmEvaluator` (`mastery/BreathRhythmEvaluator.js:30`) shows the intended pattern — it closes the loop with `Keyframe.from(1.00, 1.0)`.
-- **Failure scenario**: player is sprinting with `state.stridePhase = 0.95` (a fifth of a stride before the R-foot footfall, which the file's own comment marks as the `0.96` penalty region) and presses jump. `StrideTimingJumpEvaluator.evaluate` → `curve.evaluate(0.95)` → clamps to `keys[3].value = 1.12` → the jump impulse gets the full **+12 % midstance bonus** instead of the ≈ −4 % footfall penalty — a 17 % swing in the wrong direction, over 25 % of every gait cycle. Identical error for slide entry velocity (`1.06` instead of `≈0.97`).
-- **Fix**: append `Keyframe.from(1.00, 0.96)` to `makeDefaultStrideTimingJumpCurve()` and `Keyframe.from(1.00, 0.97)` to `makeDefaultSlideInitiationTimingCurve()`, matching the phase-0 value so the curve is continuous across the wrap.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-10 `observePinch` mixes client-space and element-space coordinates; `TouchDevice` cannot satisfy its device contract
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/touch/observePinch.js:52`
-- **Defect**: `computeTouchRadius` derives `center` from `getTouchCenter` (`touch/getTouchCenter.js:20` — raw `clientX`/`clientY`, no bounding-rect subtraction) but derives each per-touch position via `device.readPointerPositionFromEvent` (`PointerDevice.js:464` → `readPositionFromMouseEvent`, which **does** subtract `getBoundingClientRect().top/left`). Line 63 then computes `v2.sub(center)` across the two different frames. Separately, `TouchDevice` passes itself as `device` (`touch/TouchDevice.js:45`) but implements no `readPointerPositionFromEvent`, so the call is a `TypeError`.
-- **Failure scenario** (the JSDoc-sanctioned use, `@param {PointerDevice} device`): canvas whose bounding rect starts at `(100, 50)`. Two fingers 100 px apart horizontally, centred at `clientX = 300`. `center` = `(300, y)` in client space; each touch's `v2` = `(250 − 100, …) = (150, …)` and `(350 − 100, …) = (250, …)` in element space. `v2.sub(center).abs()` yields `150` and `50`, averaging to a pinch radius of **100 px** where the true half-extent is **50 px** — off by the element's left offset, and it changes with where the canvas sits on the page. Every `pinch`/`pinchStart` payload is therefore wrong, and pinch-zoom scales by a page-layout-dependent factor.
-  With `device` being a `TouchDevice` (the only in-repo wiring), `handlePinchStart` throws `TypeError: device.readPointerPositionFromEvent is not a function`; Signal's `try/catch` logs it, leaves `pinchActive === true`, and `pinchStart`/`pinch` never fire while `pinchEnd` still fires on lift.
-- **Fix**: compute the centre in the same frame as the samples — replace `getTouchCenter(touchList, center)` with an average of `device.readPointerPositionFromEvent(...)` over the touch list (or subtract the bounds once from the `getTouchCenter` result). Give `TouchDevice` a `readPointerPositionFromEvent(result, touch)` that delegates to `readPositionFromMouseEvent` with its own element.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-11 Key-up `preventDefault` is gated on the wrong signal
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/KeyboardDevice.js:142`
-- **Defect**: `#handlerKeyUp` decides whether to suppress the browser default with `if (button.down.hasHandlers())` — the *press* signal — instead of `button.up.hasHandlers()`. Copy-paste from `#handlerKeyDown:112`.
-- **Failure scenario**: the bound element carries `tabindex` (required by the constructor) and the game subscribes only to `keys.space.up` (a "release to throw" binding) with no `keys.space.down` handler. Pressing and releasing Space: `keydown` is not prevented (no `down` handler — correct), and `keyup` is *also* not prevented because the check reads `down.hasHandlers() === false` — so the browser's default Space-on-keyup activation (page scroll / activation of the focused control) fires alongside the game action. The mirror case also misfires: a binding with only a `down` handler needlessly suppresses the `keyup` default.
-- **Fix**: `if (button.up.hasHandlers()) { should_prevent_default = true; }`.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-12 Window blur releases keys without dispatching the aggregate `on.up` signal
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/KeyboardDevice.js:187`
-- **Defect**: `#handleWindowBlurEvent` calls `this.keys[keyName].release()` for every key but never calls `this.on.up.send1(...)`. `#handlerWindowKeyUp:178` does dispatch `on.up` alongside the same `release()`, so the two recovery paths disagree. `on.up` is a documented public signal and a legal binding path (`"keyboard/on/up"` resolves through `resolvePath` in both `InputSystem` and `InputControllerSystem`).
-- **Failure scenario**: a binding is registered on the path `keyboard/on/up` (e.g. a generic "any key released" handler that stops a charged action). The player holds the key and Alt-Tabs away. The per-key switch releases (so `keys.x.is_down` is correct) but `on.up` never fires, so the aggregate-bound listener never sees the release and the charged action stays engaged after the player returns.
-- **Fix**: dispatch a release notification from the blur handler for each key that was actually down — either synthesise the `on.up` send per released key, or restructure so both recovery paths funnel through one "force release key" helper that owns both the switch and `on.up`.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-13 `eventToSourceIdentifier` throws where `TouchEvent` is not a global
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/events/eventToSourceIdentifier.js:17`
-- **Defect**: `event instanceof TouchEvent` references the bare global. `TouchEvent` is undefined on desktop Safari and on Firefox builds with `dom.w3c_touch_events.enabled = 0`. The sibling `devices/isHTMLElementFocusable.js:7` guards precisely this case (`if (typeof klass !== "function") return false;`), so the codebase already knows the hazard.
-- **Failure scenario**: on desktop Safari, calling `eventToSourceIdentifier(keyboardEvent)` (or any event that is not a `MouseEvent`/`PointerEvent`/`WheelEvent`) skips the first branch and evaluates `instanceof TouchEvent` → `ReferenceError: Can't find variable: TouchEvent`. Mouse-family events are unaffected because they short-circuit on the first branch, which is why this survives testing on Chrome.
-- **Fix**: guard with `typeof TouchEvent === "function" && event instanceof TouchEvent`, or reuse the `isInstanceOf` helper pattern from `isHTMLElementFocusable.js`.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-14 `pose.postureAmount` saturates to 1 during a crouch→stand transition, then snaps to 0
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/FirstPersonPlayerControllerSystem.js:1697`
-- **Defect**: `postureSpan = Math.max(cfg.body.height - postureTargetH, 1e-3)`. For `Stand` (and `Hang`) `postureTargetH === cfg.body.height`, so the span collapses to the `1e-3` floor and `postureAmount = clamp((height - eyeHeight) / 1e-3, 0, 1)` is a step function on a 1 mm threshold rather than a blend weight.
-- **Failure scenario**: the player releases crouch. `state.posture` becomes `Stand` on that tick, but `eyeHeightSpring` needs `crouch.transitionTime = 0.18 s` to climb from `0.8` to `1.8`. Throughout that ~11-tick window `(1.8 − eyeHeight)` is ≫ 1e-3, so `pose.postureAmount` publishes a hard **1.0** (documented as "fully in the posture's target shape") while `pose.posture` says `Stand`; the instant the spring lands within 1 mm it drops to **0.0**. A rig blending its Stand track by `postureAmount` gets full weight for the entire stand-up and a single-frame pop at the end.
-- **Fix**: when the posture's target height equals the standing height (Stand, Hang), publish `postureAmount` from that posture's own semantics rather than dividing by a degenerate span — e.g. `postureAmount = 0` for `Stand`, and for `Hang` a dedicated channel (or reuse `crouchAmount`'s span) instead of the `1e-3` floor.
-- **Confidence**: Confirmed
-
----
-
-### INPUT-15 `TouchDevice` never refreshes its move anchor on touch end — first move after lifting a finger reports a bogus delta
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/touch/TouchDevice.js:62`
-- **Defect**: `#eventHandlerTouchStart` seeds `#anchor_touch_last` and `#eventHandlerTouchMove` advances it, but `#eventHandlerTouchEnd` recomputes `this.position` from the *remaining* `event.touches` without updating `#anchor_touch_last`. The next `touchmove` therefore differences the new (single-finger) centroid against the stale (multi-finger) centroid.
-- **Failure scenario**: two-finger pan with fingers at `clientX = 100` and `clientX = 500` — centroid `300`, anchor `300`. Lift the right finger: `touchend` sets `position` to `100` but leaves the anchor at `300`. The very next `touchmove` emits `delta = (100 + ε) − 300 ≈ −200 px` in a single frame, so a pan/camera consumer jumps 200 px sideways when the user merely lifts one finger.
-  (Note: `TouchDevice`'s handlers are never attached to a DOM target — the separately-captured `TouchDevice.js:53` finding — so this is currently only reachable through the class as public library surface. It is a distinct defect that will survive fixing the attachment.)
-- **Fix**: `this.#anchor_touch_last.copy(this.position);` at the end of `#eventHandlerTouchEnd` (and in a `touchcancel` handler), matching what `#eventHandlerTouchStart` already does.
-- **Confidence**: Confirmed
-
----
-
-## Notes requested by the brief
-
-**`phaseCrossed` exactly-on-boundary landing** (`FirstPersonPlayerControllerSystem.js:2019`) — the no-wrap branch's `prev < boundary` still excludes a phase that is already sitting exactly on the boundary, so the condition is unchanged; in practice it is benign, because the only way the phase reaches a boundary is the crossing that already fired, and a phase landing exactly *on* a boundary from below is caught by `next >= boundary`. The one genuine miss (`next === prev` after an exact full-cycle advance in one step) needs `strideFreq·0.5·dt === 1.0` exactly and is unreachable at sane frequencies.
-
-**`WallRunScenarios.spec.js`** — the suite is green and no longer documents any unimplemented behaviour: all eight tests assert real, currently-implemented outcomes (four "happy" paths including the wall-kick chain, four "unhappy" refusals). It does, however, only exercise the wall-kick with the jump button *released before* wall-run engages, which is exactly why INPUT-4 is invisible to it.
+# Correctness review — `engine/input/` + `engine/control/`
+
+Scope: every non-spec source file under
+`H:/git/moh/app/src/mir-engine/meep/src/engine/input/` and
+`H:/git/moh/app/src/mir-engine/meep/src/engine/control/`.
+
+Excluded per brief: `editor/`, `prototype*.js`, `*.spec.js` (read as evidence only), `.d.ts`.
+Already-fixed / already-captured / known-good items are not re-reported.
+
+Two findings (INPUT-3, INPUT-4) were **empirically confirmed** with a throw-away
+full-pipeline harness (physics + sensors + controller + WallRun/WallJump, modelled on
+`WallRunScenarios.spec.js`); the harness was deleted afterwards. Observed output is
+quoted inline.
+
+---
+
+### INPUT-1 `TopDownCameraControllerHelper` throws on every call — geometry classes never imported
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/ecs/util/TopDownCameraControllerHelper.js:45`
+- **Defect**: The module imports only `Group`, `Matrix4`, `Mesh`, `MeshLambertMaterial` from `three`, but the factory body constructs `new CylinderGeometry(...)` (line 45) and `new SphereGeometry(...)` (line 46). Both are unresolved free identifiers in an ES-module scope.
+- **Failure scenario**: `TopDownCameraControllerHelper(topDownController, targetTransform, 1)` → first statement of the function body → `ReferenceError: CylinderGeometry is not defined`. There is no code path through the function that avoids it; the helper is 100% dead on arrival for any library consumer.
+- **Fix**: add `CylinderGeometry`, `SphereGeometry` to the `three` import list (aliased in the local style, e.g. `CylinderGeometry as ThreeCylinderGeometry`) and use the aliases at lines 45–46.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-2 Pointer "down" state can never be cleared — no `pointercancel`, no blur recovery, `stop()` leaves the drag live
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/PointerDevice.js:483` (`start`), `:499` (`stop`)
+- **Defect**: `start()` subscribes only to `pointermove` / `pointerup` / `pointerdown` / `wheel` / `contextmenu`. `PointerEvents.Cancel` is defined in `events/PointerEvents.js:13` but never subscribed, and there is no `window` `blur` handler (the sibling `KeyboardDevice` has one and documents exactly this hazard). Additionally `stop()` removes the listeners but leaves `buttons[i].is_down === true` and leaves `observeDrag`'s `handleDrag` / `handleDragEnd` registered on `on.move` / `#globalUp`. The only thing that ever calls `InputDeviceSwitch.release()` for the pointer is `#eventHandlerGlobalPointerUp`, and the only thing that ends a drag is `#globalUp` firing.
+- **Failure scenario** (touch, needs no API call): finger down on the canvas → `pointerdown` → `buttons[0].press()`, `observeDrag.handleDown` arms `noDrag` + `handleDragStart`. Finger moves → `pointermove` → `handleDragStart` fires `on.dragStart` and registers `handleDrag` on `on.move` and `handleDragEnd` on `#globalUp`. The browser now claims the gesture (pull-to-refresh / two-finger pan / palm rejection) and dispatches **`pointercancel`**; per spec no `pointerup` follows. Result: `pointer.mouseButtonLeft.is_down` stays `true` forever, `on.dragEnd` is never sent, and `handleDrag` stays subscribed — so the *next* pointer that merely hovers/moves over the element (second finger, stylus, mouse) makes `on.drag` fire with the stale `origin`, swinging the camera with no button held.
+  Second reachable path with no touch at all: `pointerDevice.domElement = otherEl` (public setter, `:431`) internally does `stop()` then `start()`; performed while the left button is held it produces the same stuck `is_down` + live drag.
+- **Fix**: subscribe `#eventHandlerGlobalPointerUp` to `PointerEvents.Cancel` on `window` as well (release the button and dispatch `#globalUp` so `handleDragEnd` runs), add a `window` `blur` handler that does the same for every pressed button, and have `stop()` release all `buttons[i]` and dispatch `#globalUp` once so any in-flight drag is torn down before the listeners go away.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-3 `InputControllerSystem` proxy mutates its binding array mid-dispatch — crashes or skips listeners
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/ecs/systems/InputControllerSystem.js:62` (`Proxy.handler`), `:98` (`registerBinding`), `:132` (`remove`)
+- **Defect**: `handler()` caches `const l = bindings.length` and then indexes `bindings[i]` for `i < l`, while `add()` (→ `registerBinding`, which `push`es **and re-`sort`s**) and `remove()` (which `splice`s) both mutate that same array synchronously. The `running` flag and the `deferred` queue that were clearly meant to guard this are dead code — `running` is never set to `true`, so `add()` always takes the immediate path and `__processDeferred()` always drains an empty list.
+- **Failure scenario**: entities A and B both have an `InputController` bound to `pointer/on/down`, so the proxy holds `bindings = [A, B]`. A's listener destroys B's entity (a perfectly ordinary "click closes the panel" handler) → `ecd.removeEntity(B)` → `InputControllerSystem.unlink(B)` → `removeBindings` → `proxy.remove(bindingB)` → `bindings.splice(1,1)` → `bindings = [A]`. Control returns to `handler()`, which continues with `l === 2`: `i = 1` → `bindings[1] === undefined` → `const listener = binding.listener` → **`TypeError: Cannot read properties of undefined (reading 'listener')`**. (Signal's `try/catch` swallows it into `console.error`, so the remaining bindings on that path are silently dropped for that event.)
+  Non-crashing variant, same root cause: A's listener builds a new entity whose `InputController` binds the same path with a higher priority; `registerBinding` re-sorts the live array under the running loop, so an as-yet-unvisited sibling binding is skipped for that event and the freshly-created binding is invoked for the very event that created it.
+- **Fix**: iterate a snapshot (`const list = bindings.slice()`), or re-read `bindings.length` each iteration and iterate over a stable copy; alternatively finish the intended design — set `this.running = true` around the dispatch loop, route `add()`/`remove()` through `deferred` while running, and drain in `__processDeferred()`.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-4 `runtime.prevJumpHeld` is frozen while an ability owns motion — wall-jump silently dies mid wall-run
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/abilities/WallRun.js:114` (`tick`), `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/FirstPersonPlayerControllerSystem.js:1115`
+- **Defect**: `runtime.prevJumpHeld = intent.jump` is written only in `_advanceJumpFsm`, which runs exclusively inside `_runBaseLocomotion` — i.e. only on ticks where **no** ability owns motion. `Slide.tick` (`Slide.js:126`) and `ScrambleUp.tick` (`ScrambleUp.js:158`) explicitly maintain it themselves; `WallRun.tick` does not. `WallJump.canActivate` (`WallJump.js:50`) rejects when `runtime.prevJumpHeld` is true, so a stale `true` makes the ability permanently unreachable.
+- **Failure scenario**: sprint at a wall and jump into it **keeping the jump button held** (the natural input). Base locomotion latches `prevJumpHeld = true`; wall-run engages while it is still held, so base stops running and `prevJumpHeld` is frozen at `true`. The player then releases jump and presses it again to kick off the wall — `WallJump.canActivate` sees `prevJumpHeld === true`, returns `false`, and no wall-jump ever fires for the remainder of the wall-run. The canonical wall-run → wall-jump chain is lost; the player just rides the wall until the 2 s timer.
+  Harness output (full physics + sensors pipeline, jump held across wall-run entry at tick 24, released at 34, re-pressed at 37):
+  ```
+  { "wallRunStart": 24, "releasedAt": 34, "repressedAt": 37, "kicked": false,
+    "window": [ {"i":34,"act":"WallRun","prevJumpHeld":true,"jump":false,"vx":0},
+                ...
+                {"i":37,"act":"WallRun","prevJumpHeld":true,"jump":true,"vx":0},
+                {"i":40,"act":"WallRun","prevJumpHeld":true,"jump":true,"vx":0} ] }
+  ```
+  `vx` never leaves 0 — the body is never kicked off the wall. `WallRunScenarios.spec.js:193` passes only because its driver releases jump at tick 18, *before* wall-run engages at ~24.
+- **Fix**: make the jump-edge bookkeeping unconditional — move `runtime.prevJumpHeld = intent.jump` out of `_advanceJumpFsm` and into `_tickEntity` (after the ability layer, alongside `_resolveCrouchHeld`, which already does exactly this for crouch), and drop the per-ability copies in `Slide`/`ScrambleUp`/`WallJump`/`LedgeGrab` that exist only to work around the gap.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-5 Ability activation costs a whole fixed step of motion — nothing integrates on the activation tick
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/abilities/AbilitySet.js:123` (step 3), `:146` (return)
+- **Defect**: `AbilitySet.tick` returns `this.active === null`. On the tick where step 3 (or step 2) *activates* an ability it returns `false`, so `_tickEntity` skips `_runBaseLocomotion` (`FirstPersonPlayerControllerSystem.js:737`) — but the newly activated ability's own `tick()` is not called until the next fixed step (only `onActivate` ran). No layer moves the body: no gravity, no `_resolveMotion`, no ground categorisation, no `airborneTime`/`timeSinceGrounded` advance. The class docstring for step 1 explicitly claims "no wasted frame"; activation is exactly that wasted frame.
+- **Failure scenario**: sprint into a wall-run at ~7 m/s. Harness output for the activation tick (deltas of `transform.position` and `velocityY` across one `fixedUpdate`):
+  ```
+  {"i":22,"act":null,     "dx":-0.04276,"dy":0.08163,"dz":0.11748,"dvy":-0.97959}
+  {"i":23,"act":null,     "dx":-0.04276,"dy":0.06531,"dz":0.11748,"dvy":-0.97959}
+  {"i":24,"act":"WallRun","dx":0,       "dy":0,      "dz":0,      "dvy":0       }   <-- activation tick
+  {"i":25,"act":"WallRun","dx":0,       "dy":0.06327,"dz":0.11748,"dvy":-0.12245}
+  ```
+  The body is frozen for a full 16.7 ms — ~12 cm of lost travel and one skipped gravity step — on every slide entry, wall-run entry, scramble, ledge-grab and mantle. Visible as a one-frame hitch at each ability transition.
+- **Fix**: after activating in step 2/step 3, tick the newly activated ability in the same call (mirroring step 1's fall-through), and use its return value to decide the final `this.active`/`return` — i.e. hoist step 1's "tick then maybe release" into a small loop so a freshly activated ability owns motion on the tick it takes control.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-6 `KeyboardDevice.stop()` leaves held keys latched down
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/KeyboardDevice.js:214`
+- **Defect**: `stop()` unsubscribes all four listeners (element keydown/keyup, window keyup, window blur) but never releases the switches. The class docstring commits to the invariant for window blur ("any 'pressed' keys are forcibly released with the appropriate signal") — `#handleWindowBlurEvent` implements it, `stop()` does not, even though stopping guarantees the release can never be observed.
+- **Failure scenario**: hold `W`; the host calls `keyboard.stop()` (pausing input for a cutscene / modal / settings screen); release `W`; call `keyboard.start()`. `keys.w.is_down` is still `true` and no `keys.w.up` was ever dispatched. Every polling consumer (`keyboard.keys.w.is_down`) reads "held", and every edge consumer stays latched — e.g. `KeyboardCameraController` (`ecs/controllers/KeyboardCameraController.js:57`) sets `controls.panUp = false` only on `keys/w/up`, so the camera pans forward indefinitely after input resumes. It only clears when the player happens to press and release `W` again.
+- **Fix**: in `stop()`, run the same loop `#handleWindowBlurEvent` uses — `for (let keyName in KeyCodes) this.keys[keyName].release();` — so the switches and their `up` signals are consistent with "we can no longer observe releases".
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-7 `FirstPersonPlayerControllerConfig` drops `scrambleUp` on clone / copy / serialize, and `equals()` ignores it
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/FirstPersonPlayerControllerConfig.js:589` (`toJSON`), `:618` (`fromJSON`)
+- **Defect**: `scrambleUp` is declared as a config block (`:187`) and read by `ScrambleUp` (`abilities/ScrambleUp.js:67,86,126`), but it is absent from both `toJSON()`'s output object and `fromJSON()`'s assignment chain. `copy(other)` is implemented as `this.fromJSON(other.toJSON())` (`:658`), and `FirstPersonPlayerController.equals` (`FirstPersonPlayerController.js:201`) compares `JSON.stringify(config.toJSON())`.
+- **Failure scenario**: a designer tunes `controller.config.scrambleUp.maxJumpForce = 3000` (a deliberately weak climb). The controller component is cloned or round-tripped — `FirstPersonPlayerController.clone()` → `copy()` → `fromJSON(toJSON())` — as happens on prefab instantiation or a save/load. The clone silently reverts to the default `7200 N`, so the same character now scrambles roughly `√(7200/3000) ≈ 1.55×` faster off the wall and climbs ~2.4× higher. Separately, two controllers differing *only* in `scrambleUp` compare `equals() === true`, so change detection / dedup treats the retuned config as unchanged.
+- **Fix**: add `scrambleUp: { ...this.scrambleUp }` to `toJSON()` and `if (json.scrambleUp) Object.assign(this.scrambleUp, json.scrambleUp);` to `fromJSON()`.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-8 Jump buffer is decremented before it is tested — effective buffer is `bufferTime − dt`, and `bufferTime ≤ dt` disables jumping entirely
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/FirstPersonPlayerControllerSystem.js:1117`
+- **Defect**:
+  ```js
+  if (jumpPressedEdge) { state.jumpBufferRemaining = cfg.jump.bufferTime; }
+  state.jumpBufferRemaining = Math.max(0, state.jumpBufferRemaining - dt);   // decays on the press tick too
+  const canJumpNow = (...) && state.jumpBufferRemaining > 0 && ...;
+  ```
+  The freshly-armed buffer is aged by one full `dt` before it is ever tested, so the buffer is always one step shorter than configured and a buffer of one step or less is consumed before the gate reads it.
+- **Failure scenario**: a designer sets `cfg.jump.bufferTime = 0` to turn jump buffering off (the natural way to express "no buffering — jump only on the exact press"). Player stands on flat ground and presses jump: `jumpBufferRemaining = 0` → `max(0, 0 − 0.0167) = 0` → `canJumpNow` is `false` on the press tick, and there is no later tick with a rising edge, so **the player can never jump**. Same total failure at a 30 Hz fixed step (`dt = 0.0333`) with any `bufferTime ≤ 0.0333`.
+- **Fix**: age the buffer *before* re-arming it, i.e. `state.jumpBufferRemaining = Math.max(0, state.jumpBufferRemaining - dt); if (jumpPressedEdge) state.jumpBufferRemaining = cfg.jump.bufferTime;` — the press tick then always sees the full window.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-9 Stride-timing mastery curves are missing the closing keyframe — the last quarter of the gait cycle returns the peak bonus
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/mastery/StrideTimingJumpEvaluator.js:19`, `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/mastery/SlideInitiationTimingEvaluator.js:22`
+- **Defect**: Both curves are keyed at `0.00, 0.25, 0.50, 0.75` only, and are evaluated with a cyclic input (`controller.state.stridePhase ∈ [0,1)`). `AnimationCurve.evaluate` clamps past the last key (`engine/animation/curve/AnimationCurve.js:280-283`: `if (i >= key_count - 1) return keys[key_count - 1].value;`), so the whole interval `[0.75, 1.0)` returns the *peak* value instead of ramping back down toward the footfall trough at phase 1.0 ≡ 0.0. `BreathRhythmEvaluator` (`mastery/BreathRhythmEvaluator.js:30`) shows the intended pattern — it closes the loop with `Keyframe.from(1.00, 1.0)`.
+- **Failure scenario**: player is sprinting with `state.stridePhase = 0.95` (a fifth of a stride before the R-foot footfall, which the file's own comment marks as the `0.96` penalty region) and presses jump. `StrideTimingJumpEvaluator.evaluate` → `curve.evaluate(0.95)` → clamps to `keys[3].value = 1.12` → the jump impulse gets the full **+12 % midstance bonus** instead of the ≈ −4 % footfall penalty — a 17 % swing in the wrong direction, over 25 % of every gait cycle. Identical error for slide entry velocity (`1.06` instead of `≈0.97`).
+- **Fix**: append `Keyframe.from(1.00, 0.96)` to `makeDefaultStrideTimingJumpCurve()` and `Keyframe.from(1.00, 0.97)` to `makeDefaultSlideInitiationTimingCurve()`, matching the phase-0 value so the curve is continuous across the wrap.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-10 `observePinch` mixes client-space and element-space coordinates; `TouchDevice` cannot satisfy its device contract
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/touch/observePinch.js:52`
+- **Defect**: `computeTouchRadius` derives `center` from `getTouchCenter` (`touch/getTouchCenter.js:20` — raw `clientX`/`clientY`, no bounding-rect subtraction) but derives each per-touch position via `device.readPointerPositionFromEvent` (`PointerDevice.js:464` → `readPositionFromMouseEvent`, which **does** subtract `getBoundingClientRect().top/left`). Line 63 then computes `v2.sub(center)` across the two different frames. Separately, `TouchDevice` passes itself as `device` (`touch/TouchDevice.js:45`) but implements no `readPointerPositionFromEvent`, so the call is a `TypeError`.
+- **Failure scenario** (the JSDoc-sanctioned use, `@param {PointerDevice} device`): canvas whose bounding rect starts at `(100, 50)`. Two fingers 100 px apart horizontally, centred at `clientX = 300`. `center` = `(300, y)` in client space; each touch's `v2` = `(250 − 100, …) = (150, …)` and `(350 − 100, …) = (250, …)` in element space. `v2.sub(center).abs()` yields `150` and `50`, averaging to a pinch radius of **100 px** where the true half-extent is **50 px** — off by the element's left offset, and it changes with where the canvas sits on the page. Every `pinch`/`pinchStart` payload is therefore wrong, and pinch-zoom scales by a page-layout-dependent factor.
+  With `device` being a `TouchDevice` (the only in-repo wiring), `handlePinchStart` throws `TypeError: device.readPointerPositionFromEvent is not a function`; Signal's `try/catch` logs it, leaves `pinchActive === true`, and `pinchStart`/`pinch` never fire while `pinchEnd` still fires on lift.
+- **Fix**: compute the centre in the same frame as the samples — replace `getTouchCenter(touchList, center)` with an average of `device.readPointerPositionFromEvent(...)` over the touch list (or subtract the bounds once from the `getTouchCenter` result). Give `TouchDevice` a `readPointerPositionFromEvent(result, touch)` that delegates to `readPositionFromMouseEvent` with its own element.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-11 Key-up `preventDefault` is gated on the wrong signal
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/KeyboardDevice.js:142`
+- **Defect**: `#handlerKeyUp` decides whether to suppress the browser default with `if (button.down.hasHandlers())` — the *press* signal — instead of `button.up.hasHandlers()`. Copy-paste from `#handlerKeyDown:112`.
+- **Failure scenario**: the bound element carries `tabindex` (required by the constructor) and the game subscribes only to `keys.space.up` (a "release to throw" binding) with no `keys.space.down` handler. Pressing and releasing Space: `keydown` is not prevented (no `down` handler — correct), and `keyup` is *also* not prevented because the check reads `down.hasHandlers() === false` — so the browser's default Space-on-keyup activation (page scroll / activation of the focused control) fires alongside the game action. The mirror case also misfires: a binding with only a `down` handler needlessly suppresses the `keyup` default.
+- **Fix**: `if (button.up.hasHandlers()) { should_prevent_default = true; }`.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-12 Window blur releases keys without dispatching the aggregate `on.up` signal
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/KeyboardDevice.js:187`
+- **Defect**: `#handleWindowBlurEvent` calls `this.keys[keyName].release()` for every key but never calls `this.on.up.send1(...)`. `#handlerWindowKeyUp:178` does dispatch `on.up` alongside the same `release()`, so the two recovery paths disagree. `on.up` is a documented public signal and a legal binding path (`"keyboard/on/up"` resolves through `resolvePath` in both `InputSystem` and `InputControllerSystem`).
+- **Failure scenario**: a binding is registered on the path `keyboard/on/up` (e.g. a generic "any key released" handler that stops a charged action). The player holds the key and Alt-Tabs away. The per-key switch releases (so `keys.x.is_down` is correct) but `on.up` never fires, so the aggregate-bound listener never sees the release and the charged action stays engaged after the player returns.
+- **Fix**: dispatch a release notification from the blur handler for each key that was actually down — either synthesise the `on.up` send per released key, or restructure so both recovery paths funnel through one "force release key" helper that owns both the switch and `on.up`.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-13 `eventToSourceIdentifier` throws where `TouchEvent` is not a global
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/events/eventToSourceIdentifier.js:17`
+- **Defect**: `event instanceof TouchEvent` references the bare global. `TouchEvent` is undefined on desktop Safari and on Firefox builds with `dom.w3c_touch_events.enabled = 0`. The sibling `devices/isHTMLElementFocusable.js:7` guards precisely this case (`if (typeof klass !== "function") return false;`), so the codebase already knows the hazard.
+- **Failure scenario**: on desktop Safari, calling `eventToSourceIdentifier(keyboardEvent)` (or any event that is not a `MouseEvent`/`PointerEvent`/`WheelEvent`) skips the first branch and evaluates `instanceof TouchEvent` → `ReferenceError: Can't find variable: TouchEvent`. Mouse-family events are unaffected because they short-circuit on the first branch, which is why this survives testing on Chrome.
+- **Fix**: guard with `typeof TouchEvent === "function" && event instanceof TouchEvent`, or reuse the `isInstanceOf` helper pattern from `isHTMLElementFocusable.js`.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-14 `pose.postureAmount` saturates to 1 during a crouch→stand transition, then snaps to 0
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/control/first-person/FirstPersonPlayerControllerSystem.js:1697`
+- **Defect**: `postureSpan = Math.max(cfg.body.height - postureTargetH, 1e-3)`. For `Stand` (and `Hang`) `postureTargetH === cfg.body.height`, so the span collapses to the `1e-3` floor and `postureAmount = clamp((height - eyeHeight) / 1e-3, 0, 1)` is a step function on a 1 mm threshold rather than a blend weight.
+- **Failure scenario**: the player releases crouch. `state.posture` becomes `Stand` on that tick, but `eyeHeightSpring` needs `crouch.transitionTime = 0.18 s` to climb from `0.8` to `1.8`. Throughout that ~11-tick window `(1.8 − eyeHeight)` is ≫ 1e-3, so `pose.postureAmount` publishes a hard **1.0** (documented as "fully in the posture's target shape") while `pose.posture` says `Stand`; the instant the spring lands within 1 mm it drops to **0.0**. A rig blending its Stand track by `postureAmount` gets full weight for the entire stand-up and a single-frame pop at the end.
+- **Fix**: when the posture's target height equals the standing height (Stand, Hang), publish `postureAmount` from that posture's own semantics rather than dividing by a degenerate span — e.g. `postureAmount = 0` for `Stand`, and for `Hang` a dedicated channel (or reuse `crouchAmount`'s span) instead of the `1e-3` floor.
+- **Confidence**: Confirmed
+
+---
+
+### INPUT-15 `TouchDevice` never refreshes its move anchor on touch end — first move after lifting a finger reports a bogus delta
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/engine/input/devices/touch/TouchDevice.js:62`
+- **Defect**: `#eventHandlerTouchStart` seeds `#anchor_touch_last` and `#eventHandlerTouchMove` advances it, but `#eventHandlerTouchEnd` recomputes `this.position` from the *remaining* `event.touches` without updating `#anchor_touch_last`. The next `touchmove` therefore differences the new (single-finger) centroid against the stale (multi-finger) centroid.
+- **Failure scenario**: two-finger pan with fingers at `clientX = 100` and `clientX = 500` — centroid `300`, anchor `300`. Lift the right finger: `touchend` sets `position` to `100` but leaves the anchor at `300`. The very next `touchmove` emits `delta = (100 + ε) − 300 ≈ −200 px` in a single frame, so a pan/camera consumer jumps 200 px sideways when the user merely lifts one finger.
+  (Note: `TouchDevice`'s handlers are never attached to a DOM target — the separately-captured `TouchDevice.js:53` finding — so this is currently only reachable through the class as public library surface. It is a distinct defect that will survive fixing the attachment.)
+- **Fix**: `this.#anchor_touch_last.copy(this.position);` at the end of `#eventHandlerTouchEnd` (and in a `touchcancel` handler), matching what `#eventHandlerTouchStart` already does.
+- **Confidence**: Confirmed
+
+---
+
+## Notes requested by the brief
+
+**`phaseCrossed` exactly-on-boundary landing** (`FirstPersonPlayerControllerSystem.js:2019`) — the no-wrap branch's `prev < boundary` still excludes a phase that is already sitting exactly on the boundary, so the condition is unchanged; in practice it is benign, because the only way the phase reaches a boundary is the crossing that already fired, and a phase landing exactly *on* a boundary from below is caught by `next >= boundary`. The one genuine miss (`next === prev` after an exact full-cycle advance in one step) needs `strideFreq·0.5·dt === 1.0` exactly and is unreachable at sane frequencies.
+
+**`WallRunScenarios.spec.js`** — the suite is green and no longer documents any unimplemented behaviour: all eight tests assert real, currently-implemented outcomes (four "happy" paths including the wall-kick chain, four "unhappy" refusals). It does, however, only exercise the wall-kick with the jump button *released before* wall-run engages, which is exactly why INPUT-4 is invisible to it.