From 0ea4e2caec4648fc679af0e2ecda1672cba76a0a Mon Sep 17 00:00:00 2001
From: Ben Gregg <ben10gregg@gmail.com>
Date: Wed, 10 Jun 2026 23:33:39 -0500
Subject: [PATCH 1/3] Clean up .claude config: fix broken paths, dedupe tool
 docs, sync livetools skill

- Fix static-analyzer agent pointing at .claude/rules/tool-catalog.md
  (actual location is .claude/references/tool-catalog.md)
- Add missing livetools commands to the dynamic-analysis skill:
  dipcnt, memwatch, vishook, gamectl, mem alloc
- Make each tool list single-source: inline allowlist lives in
  tool-dispatch.md, DX script table in tool-catalog.md, livetools
  syntax in the dynamic-analysis skill; other docs point instead of copy
- Rewrite both skill descriptions as trigger-only (no workflow summary)
- Add shared .claude/settings.json permission allowlist; untrack and
  gitignore settings.local.json
---
 .claude/CLAUDE.md                        | 14 +---
 .claude/agents/static-analyzer.md        |  2 +-
 .claude/references/tool-catalog.md       | 25 +-------
 .claude/rules/tool-dispatch.md           | 33 +++-------
 .claude/settings.json                    | 20 ++++++
 .claude/settings.local.json              | 10 ---
 .claude/skills/dx9-ffp-port/SKILL.md     |  2 +-
 .claude/skills/dynamic-analysis/SKILL.md | 81 ++++++++++++++++++++++--
 .gitignore                               |  3 +
 9 files changed, 115 insertions(+), 75 deletions(-)
 create mode 100644 .claude/settings.json
 delete mode 100644 .claude/settings.local.json

diff --git a/.claude/CLAUDE.md b/.claude/CLAUDE.md
index 0aa41178..a929532f 100644
--- a/.claude/CLAUDE.md
+++ b/.claude/CLAUDE.md
@@ -18,13 +18,7 @@ Shared tooling can be modified to improve the tools themselves — just not for
 
 ## Delegation Rule
 
-**Never run static analysis tools directly.** Delegate to a `static-analyzer` subagent. Only exceptions — run these inline:
-- `sigdb.py identify` / `fingerprint` (single-function ID, <5s)
-- `context.py assemble` / `postprocess` (context gathering, <5s; use `--no-dataflow` on large functions)
-- `dataflow.py --constants` / `--slice` (single-function analysis, <5s)
-- `readmem.py` (single typed read from PE, <5s)
-- `asi_patcher.py build` (build step, not analysis)
-- `pyghidra_backend.py status` (project existence check, <1s)
+**Never run static analysis tools directly.** Delegate to a `static-analyzer` subagent. The only inline exceptions are the fast (<5s) commands in the "Run Directly" section of `.claude/rules/tool-dispatch.md` (auto-loaded below).
 
 If you're about to run a second retools command in the same turn, you should have delegated.
 
@@ -90,11 +84,7 @@ Each file reads as if it was always designed this way. Comments guide the next d
 
 ## DX9 FFP Porting
 
-When working on any of the following — invoke the **`dx9-ffp-port` skill** immediately before starting:
-- Editing `renderer.cpp`, `ffp_state.cpp`, `remix-comp-proxy.ini`, or draw routing logic
-- Porting a game for RTX Remix / fixed-function pipeline
-- Diagnosing VS constant registers, vertex declarations, matrix mapping, skinning
-- Building, deploying, or iterating on a remix-comp-proxy patch (`build.bat`, `diagnostics.log`, ImGui F4)
+Invoke the **`dx9-ffp-port` skill** before editing `renderer.cpp`, `ffp_state.cpp`, `remix-comp-proxy.ini`, or draw routing; porting a game for RTX Remix; diagnosing VS constants, vertex declarations, matrix mapping, or skinning; or building/deploying a remix-comp-proxy patch.
 
 ---
 
diff --git a/.claude/agents/static-analyzer.md b/.claude/agents/static-analyzer.md
index 1ea4c4b6..6c855591 100644
--- a/.claude/agents/static-analyzer.md
+++ b/.claude/agents/static-analyzer.md
@@ -10,7 +10,7 @@ You are a reverse engineering analyst specializing in static analysis of PE bina
 
 ## Setup
 
-On first invocation, read the full tool catalog at `.claude/rules/tool-catalog.md` in the working directory. It contains exact syntax, flags, and caveats for every tool.
+On first invocation, read the full tool catalog at `.claude/references/tool-catalog.md` in the working directory. It contains exact syntax, flags, and caveats for every tool.
 
 ## Pre-flight Checks
 
diff --git a/.claude/references/tool-catalog.md b/.claude/references/tool-catalog.md
index 8ad32b64..aeb1a743 100644
--- a/.claude/references/tool-catalog.md
+++ b/.claude/references/tool-catalog.md
@@ -159,30 +159,7 @@ These are fast first-pass scanners — they surface candidate addresses. Follow
 
 ## Dynamic Analysis (`livetools/`) -- Frida-based, attaches to running process
 
-```
-python -m livetools attach <process>                    # attach to running process by name or PID
-python -m livetools attach "C:/Games/game.exe" --spawn  # launch + instrument before init code runs
-python -m livetools detach                              # end session
-python -m livetools status                              # check connection
-```
-
-| Command | Purpose |
-|---------|---------|
-| `trace $VA` | Non-blocking: log N hits with register/memory reads |
-| `steptrace $VA` | Instruction-level trace (Stalker) with call depth control |
-| `collect $VA [$VA2...]` | Multi-address hit counting over duration |
-| `bp add/del/list $VA` | Breakpoints (stops target) |
-| `watch` | Wait for breakpoint hit |
-| `regs` / `stack` / `bt` | Inspect registers, stack, backtrace at break |
-| `mem read $VA $SIZE` | Read live process memory (supports --as float32) |
-| `mem write $VA $HEX` | Write live process memory |
-| `disasm [$VA]` | Disassemble from live process |
-| `scan $PATTERN` | Search process memory for byte pattern |
-| `modules` | List loaded modules with base addresses |
-| `dipcnt on/off/read` | D3D9 DrawIndexedPrimitive call counter |
-| `dipcnt callers [N]` | Sample N DIP calls and histogram return addresses |
-| `memwatch start/stop/read` | Memory write watchpoint with backtrace |
-| `analyze $FILE` | Offline analysis of collected .jsonl trace data |
+Main-agent only (requires a live process; static-analyzer subagents must not use these). Canonical command reference with syntax, read-spec format, and recipes: the `/dynamic-analysis` skill (`.claude/skills/dynamic-analysis/SKILL.md`). Covers attach/spawn, breakpoints, trace/steptrace/collect, mem read/write/alloc, scan, disasm, modules, dipcnt, memwatch, vishook, gamectl, and offline `analyze`.
 
 **NOTE**: Some processes require their window to be focused for traces to capture data.
 
diff --git a/.claude/rules/tool-dispatch.md b/.claude/rules/tool-dispatch.md
index 4f9ea296..72f8521e 100644
--- a/.claude/rules/tool-dispatch.md
+++ b/.claude/rules/tool-dispatch.md
@@ -18,6 +18,7 @@ Run all tools from repo root via `python -m <module>`. **ALWAYS pass `--types pa
 - `python -m retools.dataflow $B $VA --constants` — forward constant propagation
 - `python -m retools.dataflow $B $VA --slice TARGET_VA:REG` — backward register slice
 - `python -m retools.asi_patcher build spec.json` — build ASI patch DLL
+- `python retools/pyghidra_backend.py status $B --project $P` — Ghidra project existence check
 
 ## Delegate to `static-analyzer`
 
@@ -29,36 +30,22 @@ Everything else in `retools`. Tell it WHAT you need, not HOW. D3D9-specific ques
 
 ## Live tools (main agent, attached process)
 
+Full syntax and recipes: the `/dynamic-analysis` skill (canonical livetools reference).
+
 - `livetools attach <name_or_pid>` — attach to running process
 - `livetools attach <path> --spawn` — launch exe suspended, instrument, resume (catches init code)
-- `livetools trace` / `collect` — hit logging, register reads
+- `livetools trace` / `steptrace` / `collect` — hit logging, register reads, instruction traces
 - `livetools bp` / `watch` / `regs` / `stack` / `bt` — breakpoints + inspection
-- `livetools mem read/write` / `scan` — memory ops
-- `livetools dipcnt` / `memwatch` — D3D9 counters, write watchpoints
+- `livetools mem read/write/alloc` / `scan` — memory ops
+- `livetools dipcnt` / `memwatch` — D3D9 draw counters, write watchpoints
+- `livetools vishook` — selective visibility override via code cave
+- `livetools gamectl` — send keys/clicks to game window (no focus steal)
 - `livetools modules` — loaded module list
+- `livetools analyze <jsonl>` — offline trace aggregation
 
 ## DX analysis scripts (main agent, fast first-pass)
 
-Under `rtx_remix_tools/dx/scripts/`. Use BEFORE retools for D3D9 questions. Run as `python rtx_remix_tools/dx/scripts/<script> <args>`.
-
-- `find_d3d_calls.py $B` — D3D9/D3DX imports + call sites
-- `find_vs_constants.py $B` — SetVertexShaderConstantF sites with register/count
-- `find_ps_constants.py $B` — SetPixelShaderConstantF/I/B sites with register/count
-- `find_device_calls.py $B` — device vtable call patterns
-- `find_vtable_calls.py $B` — D3DX CTAB + D3D9 vtable calls
-- `find_render_states.py $B` — SetRenderState arguments with enum decoding
-- `find_texture_ops.py $B` — texture pipeline: stages, TSS ops, sampler states
-- `find_transforms.py $B` — SetTransform types (World, View, Projection, Texture)
-- `find_surface_formats.py $B` — CreateTexture/RT/DS format extraction
-- `find_stateblocks.py $B` — state block creation/recording/apply patterns
-- `decode_fvf.py $B` — FVF bitfield decode from SetFVF calls
-- `decode_vtx_decls.py $B --scan` — vertex declaration formats
-- `find_shader_bytecode.py $B` — embedded shader bytecode extraction
-- `classify_draws.py $B` — draw call classification (FFP/shader/hybrid)
-- `find_matrix_registers.py $B` — identify View/Proj/World matrix registers (CTAB + frequency)
-- `find_skinning.py $B` — consolidated skinning analysis (decls, bone palettes, blend states, INI suggestion)
-- `find_blend_states.py $B` — D3DRS_VERTEXBLEND / INDEXEDVERTEXBLENDENABLE + WORLDMATRIX transforms
-- `scan_d3d_region.py $B 0xSTART 0xEND` — D3D calls in code region
+Targeted D3D9 scanners under `rtx_remix_tools/dx/scripts/` — use BEFORE retools for D3D9 questions (imports, VS/PS constants, render states, texture pipeline, transforms, FVF/vertex decls, draw classification, matrix registers, skinning, shader bytecode). Run as `python rtx_remix_tools/dx/scripts/<script> $B`. Full script table with examples: `.claude/references/tool-catalog.md`.
 
 ## dx9tracer
 
diff --git a/.claude/settings.json b/.claude/settings.json
new file mode 100644
index 00000000..102e2044
--- /dev/null
+++ b/.claude/settings.json
@@ -0,0 +1,20 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(git checkout:*)",
+      "Bash(git branch:*)",
+      "Bash(git rebase:*)",
+      "Bash(git add:*)",
+      "Bash(python verify_install.py:*)",
+      "Bash(python -m retools.sigdb:*)",
+      "Bash(python -m retools.context:*)",
+      "Bash(python -m retools.dataflow:*)",
+      "Bash(python -m retools.readmem:*)",
+      "Bash(python -m retools.asi_patcher:*)",
+      "Bash(python retools/pyghidra_backend.py status:*)",
+      "Bash(python -m livetools:*)",
+      "Bash(python -m graphics.directx.dx9.tracer:*)",
+      "Bash(python rtx_remix_tools/dx/scripts/:*)"
+    ]
+  }
+}
diff --git a/.claude/settings.local.json b/.claude/settings.local.json
deleted file mode 100644
index 4c592433..00000000
--- a/.claude/settings.local.json
+++ /dev/null
@@ -1,10 +0,0 @@
-{
-  "permissions": {
-    "allow": [
-      "Bash(git checkout:*)",
-      "Bash(git branch:*)",
-      "Bash(git rebase:*)",
-      "Bash(git add:*)"
-    ]
-  }
-}
diff --git a/.claude/skills/dx9-ffp-port/SKILL.md b/.claude/skills/dx9-ffp-port/SKILL.md
index 3daacd51..8a8dcbb6 100644
--- a/.claude/skills/dx9-ffp-port/SKILL.md
+++ b/.claude/skills/dx9-ffp-port/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: dx9-ffp-port
-description: DX9 FFP Proxy -- Game Porting. TRIGGER when: user mentions porting a game for RTX Remix, working on renderer.cpp / ffp_state / remix-comp-proxy.ini / draw routing / VS constants / vertex declarations / matrix mapping / skinning, building or deploying a remix-comp-proxy patch, or diagnosing rendering issues in a patched game (white geometry, missing objects, wrong transforms, ImGui F4, diagnostics.log). Covers full workflow: static analysis, VS constant discovery, draw routing, INI config, build/deploy, pitfall diagnosis.
+description: Use when porting a game for RTX Remix or to the fixed-function pipeline, working on renderer.cpp / ffp_state / remix-comp-proxy.ini / draw routing / VS constants / vertex declarations / matrix mapping / skinning, building or deploying a remix-comp-proxy patch, or diagnosing rendering issues in a patched game (white geometry, missing objects, wrong transforms, ImGui F4, diagnostics.log).
 ---
 
 # DX9 FFP Proxy -- Game Porting
diff --git a/.claude/skills/dynamic-analysis/SKILL.md b/.claude/skills/dynamic-analysis/SKILL.md
index 4e87f5e6..5f6b5fb2 100644
--- a/.claude/skills/dynamic-analysis/SKILL.md
+++ b/.claude/skills/dynamic-analysis/SKILL.md
@@ -1,11 +1,11 @@
 ---
 name: dynamic-analysis
-description: Frida-based live process analysis toolkit for reverse engineering. Use when attaching to a running process, setting breakpoints, tracing functions, collecting execution data, inspecting registers/memory/stack at runtime, stepping through code, patching live memory, analyzing JSONL trace dumps, or performing any dynamic analysis task. Provides blocking breakpoints, non-blocking function tracing, Stalker-based instruction recording, interval-aware data collection, offline aggregation, and module enumeration.
+description: Use when attaching to or spawning a process for live analysis, setting breakpoints, tracing functions, collecting execution data, inspecting registers/memory/stack at runtime, stepping through code, patching live memory, catching who writes to an address, counting D3D9 draw calls, sending keystrokes or clicks to a game window, analyzing JSONL trace dumps, or performing any dynamic analysis task.
 ---
 
 # Dynamic Analysis with livetools
 
-For DX9 FFP proxy porting and RTX Remix compatibility, see also: @dx9-ffp-port
+For DX9 FFP proxy porting and RTX Remix compatibility, invoke the `dx9-ffp-port` skill.
 
 A live analysis toolkit for running processes. Attach, trace functions, collect data, inspect state, step through code, patch memory, analyze offline -- composable tools that chain naturally for any RE scenario.
 
@@ -54,10 +54,35 @@ python -m livetools resume                    # unfreeze target
 ### Patch + Scan (anytime)
 ```
 python -m livetools mem write <addr> <hex>    # write bytes to live memory
+python -m livetools mem alloc <size>          # allocate rwx memory in target (for code caves)
 python -m livetools scan <pattern> --range START:SIZE
 ```
 
-### Non-blocking Tracing (NEW)
+### Memory Write Watchpoint
+```
+python -m livetools memwatch start <addr> [--size N] [--max-hits N]   # catch who writes (IP + backtrace per hit)
+python -m livetools memwatch read             # show captured hits
+python -m livetools memwatch stop
+```
+
+### D3D9 Draw Counter
+```
+python -m livetools dipcnt on <dev_ptr>       # hook DrawIndexedPrimitive via global IDirect3DDevice9* address
+python -m livetools dipcnt read               # current count + delta since last read
+python -m livetools dipcnt callers [N]        # sample N DIP calls, histogram return addresses (default 200)
+python -m livetools dipcnt off
+```
+
+### Game Window Input (no Frida, no focus steal)
+```
+python -m livetools gamectl --exe <game.exe> info
+python -m livetools gamectl --exe <game.exe> key RETURN
+python -m livetools gamectl --exe <game.exe> keys "DOWN DOWN RETURN WAIT:1000 RETURN"
+python -m livetools gamectl --exe <game.exe> click <x> <y>
+python -m livetools gamectl --exe <game.exe> macro <name> --macro-file patches/<game>/macros.json
+```
+
+### Non-blocking Tracing
 ```
 python -m livetools trace <addr> [--count N] [--read SPEC] [--read-leave SPEC] [--filter EXPR] [--timeout T] [--output FILE]
 python -m livetools steptrace <addr> [--max-insn N] [--call-depth D] [--detail LEVEL] [--timeout T] [--output FILE]
@@ -183,11 +208,59 @@ Output: JSONL in `patches/<exe_name>/traces/` by default (gitignored).
 ```bash
 python -m livetools modules
 python -m livetools modules --filter kernel
-python -m livetools modules --filter kernel
 ```
 
 Returns name, base address, size, and full path for every loaded module. Essential for finding DLL bases for vtable hooks.
 
+### memwatch -- Hardware memory write watchpoint
+
+Uses Frida's MemoryAccessMonitor to catch writes to an address range, capturing the writing instruction pointer and a backtrace per hit. The runtime complement to static `datarefs.py` — catches writes through pointers computed at runtime.
+
+```bash
+python -m livetools memwatch start 0x7A0000 --size 48 --max-hits 20
+python -m livetools memwatch read
+python -m livetools memwatch stop
+```
+
+One active watchpoint at a time. Auto-stops after `--max-hits` (default 20).
+
+### dipcnt -- D3D9 DrawIndexedPrimitive counter
+
+Hooks DIP through the device vtable, given the address of the game's global `IDirect3DDevice9*` pointer. Use to measure draw call volume or find render-loop callers without a full trace.
+
+```bash
+python -m livetools dipcnt on 0x7C5548     # address of the global device pointer
+python -m livetools dipcnt read            # count + delta since last read
+python -m livetools dipcnt callers 200     # sample 200 calls, histogram return addresses
+python -m livetools dipcnt off
+```
+
+`callers` is the fast way to locate the main render loop: the dominant return address is the draw dispatcher.
+
+### gamectl -- Send input to the game window
+
+Posts WM_KEYDOWN/WM_KEYUP/clicks directly to the target window handle — no Frida, no focus stealing, works with the game in the background. Use to navigate menus or trigger in-game actions during long traces.
+
+```bash
+python -m livetools gamectl --exe game.exe info                      # show hwnd, title, pid
+python -m livetools gamectl --exe game.exe key RETURN [--hold-ms 50]
+python -m livetools gamectl --exe game.exe keys "DOWN DOWN RETURN WAIT:1000 RETURN" [--delay-ms 200]
+python -m livetools gamectl --exe game.exe click 400 300             # client-area coordinates
+python -m livetools gamectl --exe game.exe macro navigate_menu --macro-file patches/<game>/macros.json
+```
+
+Key names: `RETURN`, `ESCAPE`, `SPACE`, arrows, `TAB`, `F1`-`F12`, `A`-`Z`, `0`-`9`, `NUMPAD0`-`9`, `SHIFT`, `CTRL`, `ALT`. Sequence tokens: `WAIT:N` (pause N ms), `HOLD:KEY:N` (hold key N ms). Window lookup: `--exe` (preferred) or `--window <title substring>`.
+
+### vishook -- Selective visibility override via code cave
+
+Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`.
+
+```bash
+python -m livetools vishook on <jmp_site> <orig_target> [--threshold 500000]
+python -m livetools vishook stats     # override vs passthrough call counts
+python -m livetools vishook off       # restore original jmp
+```
+
 ### analyze -- Offline JSONL aggregation (no Frida needed)
 
 Pure Python. Reads JSONL from `collect` or `trace --output`. Deterministic, non-hallucinated aggregation.
diff --git a/.gitignore b/.gitignore
index 0ecdde58..0aa13fef 100644
--- a/.gitignore
+++ b/.gitignore
@@ -64,3 +64,6 @@ compass_artifact_*
 
 # Superpowers specs/plans (session artifacts)
 docs/
+
+# Claude Code local (per-machine) settings
+.claude/settings.local.json

From dfb2325a789f230a18bed8766edc53ef78bab59f Mon Sep 17 00:00:00 2001
From: Ben Gregg <ben10gregg@gmail.com>
Date: Wed, 10 Jun 2026 23:43:17 -0500
Subject: [PATCH 2/3] Sync IDE instruction trees per CODE_REVIEW checklist

Apply the .claude config fixes to the parallel .cursor, .kiro, and
.github instruction trees, and back-port improvements that only
existed there:

- Fix broken tool-catalog path in .kiro and .github static-analyzer
  agents (pointed at nonexistent .claude/rules/tool-catalog.md; now
  point at their own tree's catalog)
- Back-port into the canonical .claude dynamic-analysis skill:
  hook-address verification recipe, address rebasing guidance,
  'hook the game's CALL, not the DLL function' and 'zero hits =
  diagnose' patterns, and the Anti-Patterns section
- Propagate the canonical skill bodies (dynamic-analysis,
  dx9-ffp-port) to .cursor skills, .kiro powers, and .github skills;
  the dx9-ffp-port copies predated the template-copy workflow
- Add missing livetools commands (vishook, gamectl, mem alloc) to all
  IDE tool catalogs and decision guides
- Rebuild the .github tool catalog from the current content (it
  predated the pyghidra backend entirely)
- Fix stale ffp_proxy.log references (actual path is
  rtx_comp/diagnostics.log) and note the INI lives in assets/
---
 .claude/references/tool-catalog.md            |   2 +
 .claude/skills/dx9-ffp-port/SKILL.md          |   2 +-
 .claude/skills/dynamic-analysis/SKILL.md      |  24 +-
 .cursor/rules/dx9-ffp-port.mdc                |   4 +-
 .cursor/rules/tool-catalog.mdc                |   5 +
 .cursor/skills/dx9-ffp-port/SKILL.md          | 363 +++++++++---------
 .../references/remix-comp-context.md          |  58 +++
 .cursor/skills/dynamic-analysis/SKILL.md      |  81 +++-
 .github/agents/static-analyzer.agent.md       |   2 +-
 .../instructions/ffp-proxy.instructions.md    |   4 +-
 .../instructions/tool-catalog.instructions.md |  75 +++-
 .github/prompts/dx9-ffp-port.prompt.md        |   4 +-
 .github/skills/dx9-ffp-port/SKILL.md          | 344 ++++++++++-------
 .../references/remix-comp-context.md          |  58 +++
 .github/skills/dynamic-analysis/SKILL.md      |  88 ++++-
 .kiro/agents/static-analyzer.md               |   2 +-
 .kiro/powers/dx9-ffp-port/POWER.md            | 362 ++++++++---------
 .../references/remix-comp-context.md          |  58 +++
 .kiro/powers/dynamic-analysis/POWER.md        |  83 +++-
 .kiro/steering/dx9-ffp-port.md                |   4 +-
 .kiro/steering/tool-catalog.md                |   5 +
 21 files changed, 1084 insertions(+), 544 deletions(-)
 create mode 100644 .cursor/skills/dx9-ffp-port/references/remix-comp-context.md
 create mode 100644 .github/skills/dx9-ffp-port/references/remix-comp-context.md
 create mode 100644 .kiro/powers/dx9-ffp-port/references/remix-comp-context.md

diff --git a/.claude/references/tool-catalog.md b/.claude/references/tool-catalog.md
index aeb1a743..ca27fde5 100644
--- a/.claude/references/tool-catalog.md
+++ b/.claude/references/tool-catalog.md
@@ -26,6 +26,7 @@ These are fast (<5s) and allowed inline:
 - "What constant flows into this register?" → `python -m retools.dataflow $B $VA --constants`
 - "Trace where this value comes from" → `python -m retools.dataflow $B $VA --slice TARGET_VA:REG`
 - "Build an ASI patch DLL" → `python -m retools.asi_patcher build spec.json`
+- "Does a Ghidra project exist for this binary?" → `python retools/pyghidra_backend.py status $B --project $P`
 
 ### Delegate to `static-analyzer` subagent
 
@@ -58,6 +59,7 @@ Everything else. Tell the subagent WHAT you need, not HOW to run it — it has t
 - "What are the actual register values?" → `livetools trace --read` or `bp` + `regs`
 - "How many draw calls happen?" → `livetools dipcnt`
 - "Who writes to this memory address?" → `livetools memwatch`
+- "Send keys/clicks to the game window?" → `livetools gamectl`
 
 ### DX analysis scripts (main agent, fast first-pass)
 
diff --git a/.claude/skills/dx9-ffp-port/SKILL.md b/.claude/skills/dx9-ffp-port/SKILL.md
index 8a8dcbb6..32e54f1d 100644
--- a/.claude/skills/dx9-ffp-port/SKILL.md
+++ b/.claude/skills/dx9-ffp-port/SKILL.md
@@ -60,7 +60,7 @@ Each game folder under `patches/<GameName>/` is a self-contained remix-comp-prox
 | `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4) with FFP tab |
 | `src/comp/game/game.cpp` | Per-game address init (patterns, hooks) |
 | `src/comp/game/game.hpp` | Per-game variables and function typedefs |
-| `remix-comp-proxy.ini` | Runtime config: albedo stage, skinning toggle, diagnostics, DLL chain |
+| `remix-comp-proxy.ini` (in `assets/`) | Runtime config: albedo stage, skinning toggle, diagnostics, DLL chain |
 | `build.bat` | Build script: outputs d3d9.dll proxy. `build.bat [release\|debug] [--name Name]` |
 
 **`rtx_remix_tools/dx/remix-comp-proxy/` is the TEMPLATE.** Each game gets a full copy under `patches/<GameName>/` — the entire folder is self-contained and can be distributed as a standalone repo. Edit `src/comp/` directly in the game's copy.
diff --git a/.claude/skills/dynamic-analysis/SKILL.md b/.claude/skills/dynamic-analysis/SKILL.md
index 5f6b5fb2..d8709909 100644
--- a/.claude/skills/dynamic-analysis/SKILL.md
+++ b/.claude/skills/dynamic-analysis/SKILL.md
@@ -381,13 +381,15 @@ python -m livetools analyze trace.jsonl --compare-intervals 10 50
 python -m livetools analyze trace.jsonl --histogram "enter.reads.0.value.0"
 ```
 
-### Recipe 4: Find DLL base for vtable hooks (modules)
+### Recipe 4: Verify a hook address is correct
 
+Before hooking, confirm the address contains real code in the live process:
 ```
-python -m livetools modules --filter kernel
+python -m livetools modules --filter <game_name>
+python -m livetools disasm <target_addr> -n 5
 ```
 
-Use the base address to compute vtable entry addresses.
+If `disasm` shows garbage or errors, the address is wrong at runtime. For DLLs, rebase from `modules` output. For game .exe code, most x86 games load at preferred base — static addresses work directly.
 
 ### Recipe 5: Register inspection at a breakpoint
 
@@ -464,6 +466,20 @@ python -m livetools analyze scene.jsonl --export-csv scene.csv
 
 6. **Cross-reference with static analysis.** Match live register values and call sites against static disassembly from `retools` to identify struct offsets, vtable slots, and data pointers.
 
-7. **Use modules to find DLL bases.** Before hooking a DLL function (e.g. D3D9 vtable), use `modules` to find the actual loaded base address.
+7. **Verify addresses before hooking.** Most 32-bit game .exe files load at their preferred base (no ASLR), so static addresses from `retools` work directly. For DLLs or ASLR binaries, run `modules --filter <name>` and rebase: `runtime_addr = runtime_base + (static_addr - preferred_base)`. When in doubt, `modules` is one command — run it.
 
 8. **Composable pipeline.** `trace` captures raw records. `collect` streams them to disk. `analyze` aggregates offline. Chain them for any investigation.
+
+9. **Hook the game's CALL instruction, not the DLL function.** To trace a D3D9 method (or any API call), find the `call [reg+offset]` or `call <addr>` instruction *in the game's code* via `xrefs.py` or `vtable.py calls`. Hook THAT address. Do NOT compute the target address inside d3d9.dll and hook there — the arguments are arranged at the caller, and the DLL entry point is shared across all callers.
+
+10. **Zero hits means something is wrong — diagnose, don't give up.** If trace/collect returns 0 samples: (a) Ask the user: is the game window focused and actively rendering? (b) Verify the address: `disasm <addr>` in livetools — confirm real code exists there. (c) Try a known-hot address: `dipcnt callers 10` finds confirmed active call sites; trace one to prove the hook pipeline works. (d) Only after all three pass should you reconsider whether the original address is actually called during gameplay.
+
+---
+
+## Anti-Patterns
+
+**Do NOT chase the "real" device pointer.** When working with D3D9, do NOT: read a device pointer from a global, dereference its vtable, compute `d3d9.dll_base + slot_offset`, and hook that address. This hooks inside the DLL where arguments are not in the expected layout and proxy/wrapper DLLs break the vtable chain. Hook the game's CALL instruction instead (pattern #9).
+
+**Do NOT explain away zero data.** If a trace returns 0 samples, the answer is "I got no data and need to troubleshoot" — not "the game doesn't appear to use this code path." Follow the escalation in pattern #10.
+
+**Do NOT pass DLL-internal addresses to trace/bp.** Addresses from a DLL's export table or vtable layout belong to the DLL's code. Hooking them gives you the wrong context. Always prefer hooking in the game's own .text section.
diff --git a/.cursor/rules/dx9-ffp-port.mdc b/.cursor/rules/dx9-ffp-port.mdc
index 5c198494..1c006da1 100644
--- a/.cursor/rules/dx9-ffp-port.mdc
+++ b/.cursor/rules/dx9-ffp-port.mdc
@@ -39,7 +39,7 @@ Each game's remix-comp-proxy folder is a C++20 compatibility mod based on remix-
 | `src/comp/modules/d3d9ex.hpp` | D3D9 hook declarations |
 | `src/comp/modules/skinning.cpp` | Skinning module (vertex expansion, bone upload, FFP blending) |
 | `src/comp/modules/skinning.hpp` | Skinning class interface |
-| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `ffp_proxy.log` |
+| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `rtx_comp/diagnostics.log` |
 | `src/comp/modules/diagnostics.hpp` | Diagnostics class interface |
 | `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4 toggle) |
 | `src/shared/common/ffp_state.cpp` | FFP state tracker -- engage/disengage, matrix transforms, texture stages |
@@ -156,7 +156,7 @@ Deploy to game directory: `d3d9.dll` + `remix-comp-proxy.ini`. If using Remix, a
 
 ### Step 5: Diagnose with Log and ImGui
 
-The proxy writes `ffp_proxy.log` in the game directory. After a configurable delay (default 50 seconds via `[Diagnostics] DelayMs`), it logs frames of detailed draw call data:
+The proxy writes `rtx_comp/diagnostics.log` in the game directory. After a configurable delay (default 50 seconds via `[Diagnostics] DelayMs`), it logs frames of detailed draw call data:
 
 - **VS regs written**: shows which constant registers the game actually fills
 - **Vertex declarations**: what vertex elements each draw uses (POSITION, NORMAL, TEXCOORD, BLENDWEIGHT, etc.)
diff --git a/.cursor/rules/tool-catalog.mdc b/.cursor/rules/tool-catalog.mdc
index fad29303..650f0828 100644
--- a/.cursor/rules/tool-catalog.mdc
+++ b/.cursor/rules/tool-catalog.mdc
@@ -27,6 +27,7 @@ These are fast (<5s) and allowed inline:
 - "What constant flows into this register?" → `python -m retools.dataflow $B $VA --constants`
 - "Trace where this value comes from" → `python -m retools.dataflow $B $VA --slice TARGET_VA:REG`
 - "Build an ASI patch DLL" → `python -m retools.asi_patcher build spec.json`
+- "Does a Ghidra project exist for this binary?" → `python retools/pyghidra_backend.py status $B --project $P`
 
 ### Delegate to `static-analyzer` subagent
 
@@ -59,6 +60,7 @@ Everything else. Tell the subagent WHAT you need, not HOW to run it — it has t
 - "What are the actual register values?" → `livetools trace --read` or `bp` + `regs`
 - "How many draw calls happen?" → `livetools dipcnt`
 - "Who writes to this memory address?" → `livetools memwatch`
+- "Send keys/clicks to the game window?" → `livetools gamectl`
 
 ### DX analysis scripts (main agent, fast first-pass)
 
@@ -177,12 +179,15 @@ python -m livetools status                              # check connection
 | `regs` / `stack` / `bt` | Inspect registers, stack, backtrace at break |
 | `mem read $VA $SIZE` | Read live process memory (supports --as float32) |
 | `mem write $VA $HEX` | Write live process memory |
+| `mem alloc $SIZE` | Allocate rwx memory in target (for code caves) |
 | `disasm [$VA]` | Disassemble from live process |
 | `scan $PATTERN` | Search process memory for byte pattern |
 | `modules` | List loaded modules with base addresses |
 | `dipcnt on/off/read` | D3D9 DrawIndexedPrimitive call counter |
 | `dipcnt callers [N]` | Sample N DIP calls and histogram return addresses |
 | `memwatch start/stop/read` | Memory write watchpoint with backtrace |
+| `vishook on/off/stats` | Selective visibility override via code cave (forces visible above caller threshold) |
+| `gamectl key/keys/click/macro` | Send keys/clicks to game window (no Frida, no focus steal) |
 | `analyze $FILE` | Offline analysis of collected .jsonl trace data |
 
 **NOTE**: Some processes require their window to be focused for traces to capture data.
diff --git a/.cursor/skills/dx9-ffp-port/SKILL.md b/.cursor/skills/dx9-ffp-port/SKILL.md
index 6d602b72..f7a42da8 100644
--- a/.cursor/skills/dx9-ffp-port/SKILL.md
+++ b/.cursor/skills/dx9-ffp-port/SKILL.md
@@ -1,51 +1,72 @@
 ---
 name: 'dx9-ffp-port'
-description: 'DX9 shader-to-FFP proxy porting for RTX Remix compatibility. Use when porting a DX9 shader-based game to the fixed-function pipeline. Covers static analysis, VS constant register discovery, proxy build/deploy, and iteration.'
+description: 'Use when porting a game for RTX Remix or to the fixed-function pipeline, working on renderer.cpp / ffp_state / remix-comp-proxy.ini / draw routing / VS constants / vertex declarations / matrix mapping / skinning, building or deploying a remix-comp-proxy patch, or diagnosing rendering issues in a patched game (white geometry, missing objects, wrong transforms, ImGui F4, diagnostics.log).'
 user-invocable: true
 ---
 
-# DX9 FFP Proxy — Game Porting
+# DX9 FFP Proxy -- Game Porting
 
 Port a DX9 shader-based game to fixed-function pipeline (FFP) for RTX Remix compatibility. Remix requires FFP geometry to inject path-traced lighting and replaceable assets.
 
-**SKINNING IS OFF BY DEFAULT.** Do NOT enable skinning, modify skinning code, or discuss skinning infrastructure unless the user explicitly asks for character model / bone / skeletal animation support. When requested, read `src/comp/modules/skinning.hpp` and `src/comp/modules/skinning.cpp` for the full implementation.
+**NEVER MODIFY TEMPLATE CODE.** The following directories are read-only templates:
+- `rtx_remix_tools/dx/remix-comp-proxy/` — remix-comp-proxy framework template
 
-**SKINNING APPROACH: FFP indexed vertex blending, NOT CPU matrix math.** When skinning is enabled, keep BLENDINDICES and BLENDWEIGHT in the vertex declaration and buffer, upload bone matrices via `SetTransform(D3DTS_WORLDMATRIX(n), &boneMatrix[n])`, enable `D3DRS_INDEXEDVERTEXBLENDENABLE = TRUE`, and set `D3DRS_VERTEXBLEND` to the weight count. CPU-side vertex skinning is a **last resort** -- it is extremely expensive and tanks frame rate. Always prefer the hardware path.
+To create a game patch, **copy** the template to `patches/<GameName>/` and edit the copy. If the user asks you to edit remix-comp-proxy code, always confirm whether they mean the template or a game-specific copy under `patches/`. Only modify the template if the user **explicitly** says to change the template itself.
+
+**SKINNING IS OFF BY DEFAULT.** Do NOT enable skinning in `remix-comp-proxy.ini`, modify skinning code, or discuss skinning infrastructure unless the user explicitly asks for character model / bone / skeletal animation support. When requested, read `src/comp/modules/skinning.hpp` and `src/comp/modules/skinning.cpp` for the full implementation.
+
+**SKINNING APPROACH: FFP indexed vertex blending, NOT CPU matrix math.** When skinning is enabled, the correct approach is:
+1. Keep BLENDINDICES and BLENDWEIGHT elements in the vertex declaration and vertex buffer
+2. Upload bone matrices via `SetTransform(D3DTS_WORLDMATRIX(n), &boneMatrix[n])` for each bone
+3. Enable `D3DRS_INDEXEDVERTEXBLENDENABLE = TRUE`
+4. Set `D3DRS_VERTEXBLEND` to the appropriate weight count (e.g. `D3DVBF_3WEIGHTS`)
+5. Let the FFP hardware pipeline do the blending
+
+CPU-side vertex skinning (manually multiplying vertices by bone matrices) is a **last resort only**. It is extremely expensive, tanks frame rate, and should only be considered when FFP indexed vertex blending is not feasible. Always prefer the hardware path above.
 
 ---
 
 ## What remix-comp-proxy Does
 
-The codebase (`rtx_remix_tools/dx/remix-comp-proxy/`) is a C++20 compatibility mod based on remix-comp-base that:
+Each game folder under `patches/<GameName>/` is a self-contained remix-comp-proxy project (copied from `rtx_remix_tools/dx/remix-comp-proxy/`). It is a d3d9.dll proxy that:
 
-1. Captures VS constants (View, Projection, World matrices) from `SetVertexShaderConstantF`
-2. Parses `SetVertexDeclaration` to detect BLENDWEIGHT+BLENDINDICES (skinned), POSITIONT (screen-space), NORMAL presence, and per-element byte offsets
-3. Routes `DrawIndexedPrimitive`:
+1. Captures VS constants (View, Projection, World matrices) from `SetVertexShaderConstantF` via `ffp_state::on_set_vs_const_f`
+2. Parses `SetVertexDeclaration` via `ffp_state::on_set_vertex_declaration` to detect BLENDWEIGHT+BLENDINDICES (skinned), POSITIONT (screen-space), NORMAL presence, and per-element byte offsets
+3. Routes `DrawIndexedPrimitive` via `renderer::on_draw_indexed_prim`:
    - No NORMAL -> HUD/UI pass-through
-   - Skinned + skinning module enabled -> FFP indexed vertex blending
+   - Skinned + skinning module enabled -> `skinning::draw_skinned_dip()`
    - Rigid 3D (has NORMAL) -> NULLs shaders, applies FFP transforms
-4. Routes `DrawPrimitive`: world-space (has decl, no POSITIONT, not skinned) -> FFP; otherwise pass-through
-5. Applies captured matrices via `SetTransform`
+4. Routes `DrawPrimitive` via `renderer::on_draw_primitive`: world-space (has decl, no POSITIONT, not skinned) -> FFP; otherwise pass-through
+5. Applies captured matrices via `ffp_state::apply_transforms` -> `SetTransform`
 6. Sets up texture stages and lighting for FFP rendering
-7. Chain-loads RTX Remix (`d3d9_remix.dll`)
+7. Loads the real d3d9 chain (RTX Remix `d3d9_remix.dll` or system d3d9) via d3d9_proxy
 
-## Source File Map
+## Codebase File Map
 
 | File | Role |
 |------|------|
-| `src/comp/main.cpp` | DLL entry, module loading, initialization |
-| `src/comp/modules/renderer.cpp` | Draw call routing -- `on_draw_indexed_prim()` and `on_draw_primitive()` |
-| `src/comp/modules/d3d9ex.cpp` | `IDirect3DDevice9` hook layer -- intercepts all 119 methods |
-| `src/comp/modules/skinning.cpp` | Skinning module (vertex expansion, bone upload, FFP blending) |
-| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `ffp_proxy.log` |
-| `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4 toggle) |
-| `src/shared/common/ffp_state.cpp` | FFP state tracker -- engage/disengage, matrix transforms, texture stages |
-| `src/shared/common/ffp_state.hpp` | `ffp_state` class with all state accessors |
-| `src/shared/common/config.hpp` | Config structures: `ffp_settings`, `skinning_settings`, etc. |
-| `remix-comp-proxy.ini` (in `assets/`) | Runtime config: `[FFP]`, `[Skinning]`, `[Diagnostics]`, `[Remix]`, `[Chain]` |
-| `build.bat` | Build script: outputs d3d9.dll proxy |
-
-Per-game setup: copy the entire `rtx_remix_tools/dx/remix-comp-proxy/` folder to `patches/<GameName>/`, then edit `src/comp/` directly.
+| `src/comp/modules/renderer.cpp` | Draw routing -- `on_draw_indexed_prim()` and `on_draw_primitive()` |
+| `src/comp/modules/renderer.hpp` | `drawcall_mod_context` for save/restore state around draws |
+| `src/shared/common/ffp_state.cpp` | Core FFP state tracker -- engage/disengage, transforms, texture stages |
+| `src/shared/common/ffp_state.hpp` | FFP state class with all accessors |
+| `src/shared/common/config.hpp` | Config structure parsed from `remix-comp-proxy.ini` |
+| `src/comp/main.cpp` | DLL entry, d3d9 proxy init, window finder, config loading |
+| `src/comp/comp.cpp` | Module init: registers renderer, diagnostics, skinning, imgui |
+| `src/comp/d3d9_proxy.cpp` | Loads real d3d9 chain, DLL pre/post-load, forwarded exports |
+| `src/comp/modules/d3d9ex.cpp` | `IDirect3DDevice9` / `IDirect3D9` wrapper + exported Direct3DCreate9 |
+| `src/comp/modules/d3d9ex.hpp` | D3D9 wrapper class declarations |
+| `src/comp/modules/diagnostics.cpp` | 50-sec delay, 3-frame diagnostic log to `rtx_comp/diagnostics.log` |
+| `src/comp/modules/skinning.cpp` | Optional skinning module (vertex expansion + bone upload) |
+| `src/comp/modules/skinning.hpp` | Skinning class declaration |
+| `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4) with FFP tab |
+| `src/comp/game/game.cpp` | Per-game address init (patterns, hooks) |
+| `src/comp/game/game.hpp` | Per-game variables and function typedefs |
+| `remix-comp-proxy.ini` (in `assets/`) | Runtime config: albedo stage, skinning toggle, diagnostics, DLL chain |
+| `build.bat` | Build script: outputs d3d9.dll proxy. `build.bat [release\|debug] [--name Name]` |
+
+**`rtx_remix_tools/dx/remix-comp-proxy/` is the TEMPLATE.** Each game gets a full copy under `patches/<GameName>/` — the entire folder is self-contained and can be distributed as a standalone repo. Edit `src/comp/` directly in the game's copy.
+
+**Before reading remix-comp-proxy source files**, read [references/remix-comp-context.md](references/remix-comp-context.md) for a skip-list of boilerplate files (~7,000 lines) you should never open, with summaries of what they do. It also lists the ~1,200 lines of files that actually matter for per-game work.
 
 ---
 
@@ -53,18 +74,34 @@ Per-game setup: copy the entire `rtx_remix_tools/dx/remix-comp-proxy/` folder to
 
 ### Step 1: Static Analysis
 
-Run ALL of the analysis scripts on the game binary. These are purpose-built for FFP porting -- they surface D3D9-specific patterns (VS constant call sites, vertex declarations, device vtable usage) that would take many individual retools commands to find manually:
+Run the analysis scripts to understand the game's D3D9 usage:
 
 ```bash
+# Core discovery
 python rtx_remix_tools/dx/scripts/find_d3d_calls.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_device_calls.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/classify_draws.py "<game.exe>"
+
+# Shader constants and vertex formats
 python rtx_remix_tools/dx/scripts/find_vs_constants.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_ps_constants.py "<game.exe>"
 python rtx_remix_tools/dx/scripts/decode_vtx_decls.py "<game.exe>" --scan
-python rtx_remix_tools/dx/scripts/find_device_calls.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/decode_fvf.py "<game.exe>"
+
+# Skinning analysis (bone palettes, blend weights, suggested INI)
 python rtx_remix_tools/dx/scripts/find_skinning.py "<game.exe>"
 python rtx_remix_tools/dx/scripts/find_blend_states.py "<game.exe>"
+
+# Render state and texture pipeline
+python rtx_remix_tools/dx/scripts/find_render_states.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_texture_ops.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_transforms.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_surface_formats.py "<game.exe>"
 ```
 
-Use the script output to guide deeper analysis with `retools` (decompile specific call sites) and `livetools` (trace live values).
+Scripts are fast first-pass scanners -- surface candidate addresses only. Always follow up with `retools` and `livetools` for deep analysis.
+
+**Alternative: DX9 Tracer capture.** Deploy the tracer proxy (`graphics/directx/dx9/tracer/`) to capture a full frame, then analyze with `--matrix-flow`, `--vtx-formats`, `--shader-map`, and `--const-provenance` to discover the register layout without reverse engineering the binary.
 
 Key things to find:
 - How the game obtains its D3D device (Direct3DCreate9 -> CreateDevice)
@@ -72,29 +109,17 @@ Key things to find:
 - What vertex declaration formats are used (BLENDWEIGHT/BLENDINDICES = skinning)
 - Where the main render loop / draw calls live
 
-### Step 1b: Capture with the DX9 Tracer (Before Live Analysis)
+### Step 2: Discover VS Constant Register Layout
+
+This is the **most critical** step. Determine which VS constant registers hold View, Projection, and World matrices.
 
-Before jumping to livetools for manual tracing, deploy the D3D9 frame tracer -- it answers most FFP questions from a single capture.
+**Remix REQUIRES separate World, View, and Projection matrices.** A concatenated WorldViewProj (WVP) or ViewProj (VP) matrix will NOT work -- Remix needs individual matrices to apply its own camera and per-object transforms. If the game uploads a pre-multiplied WVP, the proxy must intercept the individual W, V, P matrices *before* the game concatenates them. This is the #1 source of broken Remix ports.
 
-1. Deploy `graphics/directx/dx9/tracer/bin/d3d9.dll` + `proxy.ini` to the game directory
-2. Launch the game, get to gameplay with visible geometry
-3. Trigger: `python -m graphics.directx.dx9.tracer trigger --game-dir <GAME_DIR>`
-4. Analyze:
+**Start with the matrix register finder:**
 ```bash
-python -m graphics.directx.dx9.tracer analyze <JSONL> --shader-map          # CTAB register names
-python -m graphics.directx.dx9.tracer analyze <JSONL> --const-provenance    # which code set each constant
-python -m graphics.directx.dx9.tracer analyze <JSONL> --vtx-formats         # vertex declarations
-python -m graphics.directx.dx9.tracer analyze <JSONL> --render-passes       # render target grouping
-python -m graphics.directx.dx9.tracer analyze <JSONL> --pipeline-diagram    # mermaid pipeline flowchart
+python rtx_remix_tools/dx/scripts/find_matrix_registers.py "<game.exe>"
 ```
-
-`--shader-map` includes CTAB headers with named parameters (e.g. `WorldViewProj c0 4`). This often answers "which registers hold which matrices" directly without manual RE.
-
-If the tracer gives you the register layout, skip the dynamic approach in Step 2 and go straight to Step 3. Use livetools only to fill gaps the tracer didn't cover. If the game crashes with the tracer proxy, fall back to Step 2's dynamic approach.
-
-### Step 2: Discover VS Constant Register Layout
-
-This is the **most critical** step. Determine which VS constant registers hold View, Projection, and World matrices.
+This cross-references SVSCF call patterns, shader CTAB names, and frequency analysis to suggest a register layout. Always verify its output with runtime data.
 
 **Static approach:** Decompile call sites:
 ```bash
@@ -108,196 +133,180 @@ python -m livetools trace <call_addr> --count 50 \
 ```
 Captures: startRegister, Vector4fCount, and the first 4 vec4 constants of actual float data.
 
+**DX9 Tracer approach:** Capture a frame and analyze:
+```bash
+python -m graphics.directx.dx9.tracer analyze <JSONL> --const-provenance
+python -m graphics.directx.dx9.tracer analyze <JSONL> --matrix-flow
+python -m graphics.directx.dx9.tracer analyze <JSONL> --shader-map
+```
+
 **How to identify matrices:**
 - View matrix: changes with camera movement; contains camera orientation
 - Projection matrix: contains aspect ratio and FOV; rarely changes
 - World matrix: changes per object; contains position/rotation/scale
 - Look for 4x4 matrices (16 floats = 4 registers). Row 3 often has `[0, 0, 0, 1]` for affine transforms.
+- **Watch for concatenated matrices:** If the game only uploads one matrix per draw (e.g. WVP at c0-c3), the individual W/V/P are being multiplied before upload. Trace back to find where the multiplication happens -- you need to capture W, V, P separately before that point.
 
-### Step 3: Copy comp/ and Configure
+### Step 3: Set Up Per-Game Project
 
-Copy the entire `rtx_remix_tools/dx/remix-comp-proxy/` folder to `patches/<GameName>/` (excluding `build/`). The game folder is now self-contained. Edit files directly:
+**IMPORTANT:** `rtx_remix_tools/dx/remix-comp-proxy/` is the **template**. NEVER edit it directly. Each game gets a full copy of the framework.
 
-1. Edit register layout defaults in `src/shared/common/ffp_state.hpp`
-2. Edit `src/comp/main.cpp`: set `WINDOW_CLASS_NAME` to the game's window class
-3. Customize `src/comp/modules/renderer.cpp` draw routing if needed
-4. Customize `src/comp/game/game.cpp` with game-specific hooks
-5. Update `kb.h` with discovered function signatures, structs, and globals
+1. Copy the entire `rtx_remix_tools/dx/remix-comp-proxy/` folder to `patches/<GameName>/` (excluding `build/`)
+2. Edit `src/comp/` directly in the game's copy — this is the per-game customization layer
+3. Edit register layout defaults in `src/shared/common/ffp_state.hpp` (see Register Layout section below)
+4. Edit `src/comp/main.cpp`: set `WINDOW_CLASS_NAME` to the game's window class
+5. Customize `src/comp/modules/renderer.cpp` draw routing if needed (see Decision Trees below)
+6. Customize `src/comp/game/game.cpp` with game-specific address init if hooks are needed
+7. Update `kb.h` with discovered function signatures, structs, and globals
+
+The game folder is now fully self-contained and can be distributed as a standalone git repo.
 
 ### Step 4: Build and Deploy
 
+From the game folder:
 ```bash
 cd patches/<GameName>
 build.bat release --name <GameName>
 ```
 
-Deploy to game directory: `d3d9.dll` + `remix-comp-proxy.ini`. Place `d3d9_remix.dll` there if using Remix.
+The build produces `d3d9.dll` in `patches/<GameName>/build/bin/release/`. Deploy:
+- `d3d9.dll` to the game directory (the game loads this as its d3d9 proxy)
+- `remix-comp-proxy.ini` to the game directory
+- `d3d9_remix.dll` to the game directory if using Remix
 
 ### Step 5: Diagnose with Log and ImGui
 
-The proxy writes `ffp_proxy.log` in the game directory after a configurable delay (default 50 seconds via `[Diagnostics] DelayMs`), then logs frames of detailed draw call data:
+**rtx_comp/diagnostics.log:** Written to the `rtx_comp/` subfolder of the game directory after a configurable delay (default 50 seconds), then logs 3 frames of detailed draw call data:
 
 - **VS regs written**: which constant registers the game actually fills
 - **Vertex declarations**: what vertex elements each draw uses
 - **Draw calls**: primitive type, vertex count, index count, textures per stage
 - **Matrices**: actual View/Proj/World values being applied
-
-Press **F4** to open the ImGui debug overlay with live draw call stats and FFP conversion info.
+- **Raw vertex bytes**: hex dump of first vertices for early draw calls
 
 Do not change the logging delay unless the user asks -- it ensures the user gets into the game with real geometry before logging begins.
 
+**ImGui overlay (F4):** Press F4 to toggle the debug overlay. The FFP tab shows real-time draw call stats, VS constant register write history, and enables a fake camera for testing transforms.
+
 **Tell the user when you need them to interact with the game** for logging or hooking purposes. They must be in-game with geometry visible for the log to be useful.
 
 ---
 
-## Game-Specific Configuration
+## Register Layout (`ffp_state.hpp`)
 
-The VS constant register layout is defined in `src/shared/common/ffp_state.hpp` as member defaults. Edit these when porting, then rebuild:
+The VS constant register layout is defined as member defaults in `src/shared/common/ffp_state.hpp`. Edit these when porting a new game:
 
 ```cpp
-int vs_reg_view_start_ = 0;    int vs_reg_view_end_ = 4;
-int vs_reg_proj_start_ = 4;    int vs_reg_proj_end_ = 8;
-int vs_reg_world_start_ = 16;  int vs_reg_world_end_ = 20;
-int vs_reg_bone_threshold_ = 20;   // first register treated as bone palette
-int vs_regs_per_bone_ = 3;        // 3 = 4x3 packed, 4 = full 4x4
-int vs_bone_min_regs_ = 3;        // min count to qualify as bone upload
+// In ffp_state.hpp — private members with game-specific defaults
+int vs_reg_view_start_ = 0;
+int vs_reg_view_end_ = 4;
+int vs_reg_proj_start_ = 4;
+int vs_reg_proj_end_ = 8;
+int vs_reg_world_start_ = 16;
+int vs_reg_world_end_ = 20;
+int vs_reg_bone_threshold_ = 20;  // only matters when [Skinning] Enabled=1
+int vs_regs_per_bone_ = 3;        // 3 = 4x3 packed bones (most common), 4 = full 4x4
+int vs_bone_min_regs_ = 3;        // minimum register count to qualify as bone upload
 ```
 
-**Bone config:** Run `find_skinning.py` to determine bone start register and upload pattern. Some games upload all bones at once; others upload in groups until hitting a max (e.g., groups of 15, max 75). If grouped, lower `vs_bone_min_regs_`. If bone uploads overlap with non-bone constants, raise `vs_reg_bone_threshold_`.
+Each matrix occupies 4 consecutive vec4 registers (= 16 floats). After changing defaults, rebuild with `build.bat`.
 
-Other game-specific INI settings:
-- `[FFP] AlbedoStage=0` -- which texture stage holds the diffuse/albedo
-- `[Skinning] Enabled=0` -- only set to 1 after rigid FFP works
-- `[Remix] Enabled=1` -- set to 0 to test without Remix
+### Bone Configuration for Skinning
 
----
+Before enabling skinning, run `find_skinning.py` to determine the bone start register (`vs_reg_bone_threshold_`) and upload pattern. Some games upload all bones in one call; others upload in groups until hitting a max (e.g., groups of 15, max 75). If the game uses grouped uploads, lower `vs_bone_min_regs_` so the proxy doesn't reject the smaller batches. If bone uploads overlap with non-bone constants, raise `vs_reg_bone_threshold_`.
 
-## Architecture: What to Edit vs What to Leave Alone
+## INI Config (`remix-comp-proxy.ini`)
 
-| File / Section | Edit Per-Game? |
-|----------------|----------------|
-| `ffp_state.hpp` register layout defaults | **YES** |
-| `remix-comp-proxy.ini` `[FFP] AlbedoStage` | **YES** |
-| `remix-comp-proxy.ini` `[Skinning] Enabled` | **YES** (after rigid works) |
-| `renderer.cpp` `on_draw_indexed_prim()` | **YES** -- main draw routing |
-| `renderer.cpp` `on_draw_primitive()` | **YES** -- draw routing |
-| `ffp_state.cpp` `setup_lighting()`, `setup_texture_stages()`, `apply_transforms()` | MAYBE |
-| `ffp_state.cpp` `on_set_vs_const_f()` | MAYBE -- dirty tracking |
-| `ffp_state.cpp` `on_set_vertex_declaration()` | MAYBE -- element parsing |
-| `d3d9ex.cpp` hooks | NO -- infrastructure |
-| `ffp_state.cpp` `engage()` / `disengage()` | NO |
-| `skinning.cpp` | NO -- infrastructure |
-| `diagnostics.cpp` | NO -- logging |
-| `imgui.cpp` | NO -- debug overlay |
+Runtime settings that don't require recompile:
 
-### DrawIndexedPrimitive Decision Tree
+```ini
+[FFP]
+Enabled=1
+AlbedoStage=0
+; Albedo texture stage (0-7). Set to whichever stage the game binds the diffuse texture.
 
-```
-viewProjValid?
-+-- NO  -> shader passthrough
-+-- YES
-    +-- curDeclIsSkinned?
-    |   +-- YES + skinning module -> skinning::draw_skinned_dip()
-    |   +-- YES + no skinning     -> shader passthrough
-    +-- NOT skinned
-        +-- !curDeclHasNormal -> shader passthrough (HUD/UI)
-        +-- hasNormal -> ffp_state::engage + rigid FFP draw
-```
+[Skinning]
+Enabled=0
+; Only set to 1 after rigid FFP works correctly.
+; Run find_skinning.py to determine bone register layout before enabling.
 
-**Common per-game changes:**
-- World geometry omits NORMAL -> remove or change `!cur_decl_has_normal()` filter
-- Special passes (shadow, reflection) -> filter by shader pointer, render target, or vertex count
-- UI drawn with DrawIndexedPrimitive + NORMAL -> add a filter (e.g. check stride or texture)
+[Diagnostics]
+Enabled=1
+DelayMs=50000
+LogFrames=3
 
-### DrawPrimitive Decision Tree
+[Remix]
+Enabled=1
+DLLName=d3d9_remix.dll
 
-```
-viewProjValid AND lastDecl AND !curDeclHasPosT AND !curDeclIsSkinned?
-+-- YES -> ffp_state::engage (world-space particles / non-indexed geometry)
-+-- NO  -> shader passthrough (screen-space UI, POSITIONT, no decl, skinned)
+[Chain]
+PreLoad=
+PostLoad=
+; Semicolon-separated DLLs/ASIs to load before/after the d3d9 chain.
+; Example: PreLoad=patch.dll;fix.asi
 ```
 
 ---
 
-## Analysis Scripts Reference
-
-| Script | What it surfaces |
-|--------|-----------------|
-| `python rtx_remix_tools/dx/scripts/find_d3d_calls.py <game.exe>` | D3D9/D3DX imports and call sites |
-| `python rtx_remix_tools/dx/scripts/find_vs_constants.py <game.exe>` | `SetVertexShaderConstantF` call sites and register/count args |
-| `python rtx_remix_tools/dx/scripts/find_device_calls.py <game.exe>` | Device vtable call patterns and device pointer refs |
-| `python rtx_remix_tools/dx/scripts/find_vtable_calls.py <game.exe>` | D3DX constant table usage and D3D9 vtable calls |
-| `python rtx_remix_tools/dx/scripts/decode_vtx_decls.py <game.exe> --scan` | Vertex declaration formats (BLENDWEIGHT/BLENDINDICES -> skinning) |
-| `python rtx_remix_tools/dx/scripts/find_skinning.py <game.exe>` | Consolidated skinning analysis: skinned decls, bone palettes, blend states, suggested INI |
-| `python rtx_remix_tools/dx/scripts/find_blend_states.py <game.exe>` | D3DRS_VERTEXBLEND + INDEXEDVERTEXBLENDENABLE + WORLDMATRIX transforms |
-| `python rtx_remix_tools/dx/scripts/scan_d3d_region.py <game.exe> 0xSTART 0xEND` | Map all D3D9 vtable calls in a code region |
-
----
+## Architecture: What to Edit vs What to Leave Alone
 
-## RE Tool Workflows for FFP Porting
+Each game folder under `patches/<GameName>/` is a **self-contained** copy of the full remix-comp-proxy framework. Edit files directly in the game's copy.
+
+| Component (in `patches/<GameName>/`) | Edit Per-Game? |
+|-----------|----------------|
+| `ffp_state.hpp` register layout defaults | **YES** — rebuild after changing |
+| `remix-comp-proxy.ini` albedo stage, diagnostics, chain | **YES** |
+| `src/comp/main.cpp` WINDOW_CLASS_NAME | **YES** |
+| `src/comp/modules/renderer.cpp` draw routing | **YES** -- main draw routing |
+| `src/comp/game/game.cpp` address init and hooks | **YES** -- per-game hooks |
+| `src/comp/game/structs.hpp` game structs | **YES** -- per-game data structures |
+| `src/shared/common/ffp_state.cpp` engage/disengage/transforms | MAYBE -- only for unusual FFP needs |
+| `src/shared/common/config.hpp` | MAYBE -- add new INI sections if needed |
+| `src/comp/modules/d3d9ex.cpp` | NO -- forwards all 119 methods |
+| `src/comp/modules/diagnostics.cpp` | NO -- generic frame logger |
+| `src/comp/modules/imgui.cpp` | NO -- debug overlay |
+| `src/shared/` everything else | NO -- framework code |
 
-### Find all SetVertexShaderConstantF call sites
-```bash
-python -m retools.xrefs <game.exe> <iat_addr> -t call
-```
+### DrawIndexedPrimitive Decision Tree
 
-### Decompile a VS constant setup function
-```bash
-python -m retools.decompiler <game.exe> <func_addr> --types patches/<project>/kb.h
 ```
-
-### Trace live VS constant writes
-```bash
-python -m livetools trace <SetVSConstF_call_addr> --count 50 \
-    --read "[esp+8]:4:uint32; [esp+10]:4:uint32; *[esp+c]:64:float32"
+ffp.is_enabled() AND ffp.view_proj_valid()?
++-- NO  -> passthrough with shaders
++-- YES
+    +-- ffp.cur_decl_is_skinned()?
+    |   +-- YES + skinning module -> skinning::draw_skinned_dip()
+    |   +-- YES + no skinning     -> passthrough with shaders
+    +-- !ffp.cur_decl_has_normal()?
+    |   +-- passthrough (HUD/UI)
+    |   GAME-SPECIFIC: remove this filter if world geometry lacks NORMAL
+    +-- else (rigid 3D mesh)
+        +-- ffp.engage() + draw + restore
 ```
 
-**The `<SetVSConstF_call_addr>` is the CALL instruction in the game's .exe** (from `find_vs_constants.py` or `xrefs.py`), NOT an address inside d3d9.dll. Hook the caller, not the callee.
-
-### Count draw calls and find callers
-```bash
-python -m livetools dipcnt on
-# wait in-game
-python -m livetools dipcnt read
-python -m livetools dipcnt callers 100
-```
+**Common per-game changes:**
+- World geometry omits NORMAL -> remove or change `!ffp.cur_decl_has_normal()` filter
+- Special passes (shadow, reflection) -> filter by shader pointer, render target, or vertex count
+- UI drawn with DrawIndexedPrimitive + NORMAL -> add a filter (e.g. check stride or texture)
 
-### Understand render path depth
-```bash
-python -m retools.callgraph <game.exe> <render_func_addr> --down 3
-```
+### DrawPrimitive Decision Tree
 
-### Understand a specific draw call path
-```bash
-python -m livetools steptrace <draw_func_addr> --max-insn 1000 --call-depth 1 --detail branches
 ```
-
-### Find vertex declaration setup
-```bash
-python -m retools.search <game.exe> strings -f "vertex,decl,shader" --xrefs
+ffp.is_enabled() AND ffp.view_proj_valid() AND ffp.last_decl()
+AND !ffp.cur_decl_has_pos_t() AND !ffp.cur_decl_is_skinned()?
++-- YES -> ffp.engage() (world-space particles / non-indexed geometry)
++-- NO  -> passthrough (screen-space UI, POSITIONT, no decl, skinned)
 ```
 
 ---
 
 ## Common Pitfalls
 
-- **Matrices look wrong**: D3D9 FFP `SetTransform` expects row-major. The proxy transposes. If the game stores matrices row-major in VS constants (uncommon), remove the transpose in `ffp_state::apply_transforms()`.
-- **Everything is white/black**: Albedo texture is on stage 1+, not stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini` `[FFP]` section, or trace `SetTexture` calls to find the correct stage.
-- **Some objects render, others don't**: Check whether missing geometry has NORMAL in its vertex decl. Check `view_proj_valid()` is true at draw time. `on_draw_primitive()` routes on decl presence + no POSITIONT + not skinned.
-- **Skinned meshes invisible**: Enable `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Verify bone count is non-zero in diagnostic log entries.
-- **Bones mixed up between NPCs**: Stale WORLDMATRIX slots from a previous object. If broken, the game may need a game-specific reset hook.
-- **Game crashes on startup**: Set `Enabled=0` in `remix-comp-proxy.ini` `[Remix]` to test without Remix.
-- **Geometry at origin / piled up**: World matrix register mapping wrong. Re-examine VS constant writes via `livetools trace`.
-- **World geometry shifts after skinned draws**: `WORLDMATRIX(0)` clobbered by bone[0]. The proxy re-applies via world dirty tracking. If still broken, check for bone register overlap with world matrix range.
-
-### Skinning Stability: Finding Game-Specific Hook Points
-
-The proxy's generic heuristics handle most games. If bones still leak between objects, the game needs a hook at a per-object boundary function -- one that's called once per skinned object, before its bones are uploaded.
-
-**Finding the per-object function:**
-
-1. **Capture** 2+ frames with the D3D9 tracer while multiple skinned NPCs are on screen
-2. **Hotpaths**: `--hotpaths --resolve-addrs <game.exe>` -- look at callers of bone-range `SetVertexShaderConstantF` writes
-3. **Caller histogram**: `--callers SetVertexShaderConstantF` -- the function that appears N times per frame (N = number of skinned objects) is the per-object boundary
-4. **Live confirm**: `livetools trace <candidate_addr> --count 50` -- with 3 NPCs, expect ~3 hits/frame
-5. **Static context**: `callgraph.py --up` + `decompiler.py` on the caller -- confirm it loops over objects
+- **Concatenated WVP/VP instead of separate matrices**: This is the **#1 Remix porting mistake**. Remix requires separate World, View, and Projection matrices passed via `SetTransform`. If the game uploads a pre-multiplied WorldViewProj or ViewProj to a single register range, the proxy gets a combined matrix it can't decompose. **Fix**: find where the game multiplies W*V*P (or V*P) and hook that function to capture the individual matrices *before* concatenation. Use `find_matrix_registers.py` to detect this -- if CTAB shows "WorldViewProj" or only one matrix register is uploaded per draw, you have this problem.
+- **Matrices look wrong**: D3D9 FFP `SetTransform` expects row-major. `ffp_state::apply_transforms` transposes column-major VS constants. If the game stores matrices row-major in VS constants (uncommon), remove the transpose in `ffp_state::apply_transforms`.
+- **Everything is white/black**: Albedo texture is on stage 1+, not stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini`, or trace `SetTexture` calls to find the correct stage.
+- **Some objects render, others don't**: Check whether missing geometry has NORMAL in its vertex decl. Check `ffp.view_proj_valid()` is true at draw time. DrawPrimitive routes on decl presence + no POSITIONT + not skinned.
+- **Skinned meshes invisible**: Set `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Check log for skinning errors. Verify `bone_start_reg` and `num_bones` are non-zero in the log.
+- **Game crashes on startup**: Set `[Remix] Enabled=0` in `remix-comp-proxy.ini` to test without Remix. Check `WINDOW_CLASS_NAME` in `comp/main.cpp`.
+- **Geometry at origin / piled up**: World matrix register mapping wrong. Re-examine VS constant writes via `livetools trace` or DX9 tracer `--const-provenance`.
+- **World geometry shifts after skinned draws**: `WORLDMATRIX(0)` clobbered by bone[0]. The proxy tracks `world_dirty_` for re-application. If still broken, check for bone register overlap with world matrix range in `ffp_state.hpp`.
+- **ImGui overlay not appearing**: Press F4. Check that `WINDOW_CLASS_NAME` is correct and the window was found (console output). Check for DirectInput hook conflicts.
diff --git a/.cursor/skills/dx9-ffp-port/references/remix-comp-context.md b/.cursor/skills/dx9-ffp-port/references/remix-comp-context.md
new file mode 100644
index 00000000..63be154a
--- /dev/null
+++ b/.cursor/skills/dx9-ffp-port/references/remix-comp-context.md
@@ -0,0 +1,58 @@
+# remix-comp-proxy: Context Guide
+
+**`rtx_remix_tools/dx/remix-comp-proxy/` is the READ-ONLY TEMPLATE.** Never modify it unless explicitly asked. Per-game work goes in `patches/<GameName>/`.
+
+Each game folder under `patches/<Game>/` is a self-contained remix-comp-proxy project. All paths below are relative to the game folder root (e.g. `patches/FNV/`) or to the framework template at `rtx_remix_tools/dx/remix-comp-proxy/`.
+
+## Do Not Read
+
+These are infrastructure files. Use the summaries below instead of opening them.
+
+### Auto-generated
+- `src/comp/modules/tracer_dispatch.inc` — 119 inline `trace_XXX()` functions generated by `graphics/directx/dx9/tracer/d3d9_methods.py`. Each wraps `tracer::record_begin/arg/end`.
+
+### D3D9 passthrough proxy
+- `src/comp/modules/drawcall_mod_context.cpp` — `drawcall_mod_context` save/restore method implementations. Never needs to be read; the API is in `renderer.hpp`.
+- `src/comp/modules/d3d9ex.cpp` — `IDirect3DDevice9` wrapper + exported `Direct3DCreate9`/`Direct3DCreate9Ex`. ~80 of 119 methods are trivial 1-line forwards. The ~12 methods with logic dispatch to renderer/ffp_state/imgui/tracer modules.
+- `src/comp/modules/d3d9ex.hpp` — D3D9Device, _d3d9, and _d3d9ex wrapper class declarations.
+- `src/comp/d3d9_proxy.cpp` + `d3d9_proxy.hpp` — d3d9.dll proxy: loads real d3d9 chain (Remix bridge or system), DLL pre/post-load chains, forwarded D3DPERF/debug exports.
+
+### Shared library (framework, never edited per-game)
+- `src/shared/utils/hooking.cpp/hpp` — MinHook wrapper + vtable patching.
+- `src/shared/utils/vector.hpp` — SIMD float2/float3/float4 math.
+- `src/shared/common/remix_api.cpp/hpp` — RTX Remix runtime bridge (load d3d9_remix.dll, init API, submit lights).
+- `src/shared/common/console.hpp` — Debug console allocation/output.
+- `src/shared/common/imgui_helper.cpp/hpp` — ImGui setup/teardown utilities.
+- `src/shared/utils/memory.cpp/hpp` — Pattern scanning and memory allocation.
+- `src/shared/utils/utils.cpp/hpp` — String/path/module utilities.
+- `src/shared/common/dinput_hook_v1.cpp/hpp` — DirectInput8 hook (input capture).
+- `src/shared/common/dinput_hook_v2.cpp/hpp` — Alternate DirectInput hook.
+- `src/shared/common/loader.cpp/hpp` — Module loader/registry.
+- `src/shared/common/flags.cpp/hpp` — Command-line flag parsing.
+- `src/shared/common/shader_cache.hpp` — Shader handle cache.
+- `src/shared/globals.cpp/hpp` — Global state (device pointer, module handle).
+- `src/shared/structs.hpp`, `src/shared/std_include.*`, `src/comp/std_include.*` — Precompiled headers, forward declarations.
+
+## Read These Instead
+
+The files that matter for per-game FFP porting work:
+
+| File | Role |
+|------|------|
+| `src/comp/modules/renderer.cpp` | **Draw call routing — THE main edit target** |
+| `src/comp/modules/renderer.hpp` | `drawcall_mod_context` API + `renderer` class declaration |
+| `src/shared/common/ffp_state.cpp` | FFP state tracker: engage/disengage, transforms, textures |
+| `src/shared/common/ffp_state.hpp` | ffp_state class with all accessors |
+| `src/shared/common/config.cpp` | INI config loader |
+| `src/shared/common/config.hpp` | Config structures |
+| `src/comp/main.cpp` | DLL entry, WINDOW_CLASS_NAME, module init |
+| `src/comp/comp.cpp` | Module registration order |
+| `src/comp/game/game.cpp` | Per-game address patterns and hooks |
+| `src/comp/game/game.hpp` | Per-game variables and typedefs |
+| `src/comp/game/structs.hpp` | Per-game data structures |
+
+### Read only when relevant
+- `src/comp/modules/diagnostics.cpp/hpp` — Frame logger to `rtx_comp/diagnostics.log`. Read when debugging log output.
+- `src/comp/modules/skinning.cpp/hpp` — Skinned mesh FFP conversion. Read only if user asks about skinning.
+- `src/comp/modules/imgui.cpp/hpp` — Debug overlay (F4). Read only if debugging ImGui.
+- `src/comp/modules/tracer.cpp/hpp` — JSONL D3D9 call recorder. Read only if working on tracer features.
diff --git a/.cursor/skills/dynamic-analysis/SKILL.md b/.cursor/skills/dynamic-analysis/SKILL.md
index 2b185406..d8709909 100644
--- a/.cursor/skills/dynamic-analysis/SKILL.md
+++ b/.cursor/skills/dynamic-analysis/SKILL.md
@@ -1,11 +1,11 @@
 ---
 name: dynamic-analysis
-description: Frida-based live process analysis toolkit for reverse engineering. Use when attaching to a running process, setting breakpoints, tracing functions, collecting execution data, inspecting registers/memory/stack at runtime, stepping through code, patching live memory, analyzing JSONL trace dumps, or performing any dynamic analysis task. Provides blocking breakpoints, non-blocking function tracing, Stalker-based instruction recording, interval-aware data collection, offline aggregation, and module enumeration.
+description: Use when attaching to or spawning a process for live analysis, setting breakpoints, tracing functions, collecting execution data, inspecting registers/memory/stack at runtime, stepping through code, patching live memory, catching who writes to an address, counting D3D9 draw calls, sending keystrokes or clicks to a game window, analyzing JSONL trace dumps, or performing any dynamic analysis task.
 ---
 
 # Dynamic Analysis with livetools
 
-For DX9 FFP proxy porting and RTX Remix compatibility, see also: @dx9-ffp-port
+For DX9 FFP proxy porting and RTX Remix compatibility, invoke the `dx9-ffp-port` skill.
 
 A live analysis toolkit for running processes. Attach, trace functions, collect data, inspect state, step through code, patch memory, analyze offline -- composable tools that chain naturally for any RE scenario.
 
@@ -54,10 +54,35 @@ python -m livetools resume                    # unfreeze target
 ### Patch + Scan (anytime)
 ```
 python -m livetools mem write <addr> <hex>    # write bytes to live memory
+python -m livetools mem alloc <size>          # allocate rwx memory in target (for code caves)
 python -m livetools scan <pattern> --range START:SIZE
 ```
 
-### Non-blocking Tracing (NEW)
+### Memory Write Watchpoint
+```
+python -m livetools memwatch start <addr> [--size N] [--max-hits N]   # catch who writes (IP + backtrace per hit)
+python -m livetools memwatch read             # show captured hits
+python -m livetools memwatch stop
+```
+
+### D3D9 Draw Counter
+```
+python -m livetools dipcnt on <dev_ptr>       # hook DrawIndexedPrimitive via global IDirect3DDevice9* address
+python -m livetools dipcnt read               # current count + delta since last read
+python -m livetools dipcnt callers [N]        # sample N DIP calls, histogram return addresses (default 200)
+python -m livetools dipcnt off
+```
+
+### Game Window Input (no Frida, no focus steal)
+```
+python -m livetools gamectl --exe <game.exe> info
+python -m livetools gamectl --exe <game.exe> key RETURN
+python -m livetools gamectl --exe <game.exe> keys "DOWN DOWN RETURN WAIT:1000 RETURN"
+python -m livetools gamectl --exe <game.exe> click <x> <y>
+python -m livetools gamectl --exe <game.exe> macro <name> --macro-file patches/<game>/macros.json
+```
+
+### Non-blocking Tracing
 ```
 python -m livetools trace <addr> [--count N] [--read SPEC] [--read-leave SPEC] [--filter EXPR] [--timeout T] [--output FILE]
 python -m livetools steptrace <addr> [--max-insn N] [--call-depth D] [--detail LEVEL] [--timeout T] [--output FILE]
@@ -183,11 +208,59 @@ Output: JSONL in `patches/<exe_name>/traces/` by default (gitignored).
 ```bash
 python -m livetools modules
 python -m livetools modules --filter kernel
-python -m livetools modules --filter kernel
 ```
 
 Returns name, base address, size, and full path for every loaded module. Essential for finding DLL bases for vtable hooks.
 
+### memwatch -- Hardware memory write watchpoint
+
+Uses Frida's MemoryAccessMonitor to catch writes to an address range, capturing the writing instruction pointer and a backtrace per hit. The runtime complement to static `datarefs.py` — catches writes through pointers computed at runtime.
+
+```bash
+python -m livetools memwatch start 0x7A0000 --size 48 --max-hits 20
+python -m livetools memwatch read
+python -m livetools memwatch stop
+```
+
+One active watchpoint at a time. Auto-stops after `--max-hits` (default 20).
+
+### dipcnt -- D3D9 DrawIndexedPrimitive counter
+
+Hooks DIP through the device vtable, given the address of the game's global `IDirect3DDevice9*` pointer. Use to measure draw call volume or find render-loop callers without a full trace.
+
+```bash
+python -m livetools dipcnt on 0x7C5548     # address of the global device pointer
+python -m livetools dipcnt read            # count + delta since last read
+python -m livetools dipcnt callers 200     # sample 200 calls, histogram return addresses
+python -m livetools dipcnt off
+```
+
+`callers` is the fast way to locate the main render loop: the dominant return address is the draw dispatcher.
+
+### gamectl -- Send input to the game window
+
+Posts WM_KEYDOWN/WM_KEYUP/clicks directly to the target window handle — no Frida, no focus stealing, works with the game in the background. Use to navigate menus or trigger in-game actions during long traces.
+
+```bash
+python -m livetools gamectl --exe game.exe info                      # show hwnd, title, pid
+python -m livetools gamectl --exe game.exe key RETURN [--hold-ms 50]
+python -m livetools gamectl --exe game.exe keys "DOWN DOWN RETURN WAIT:1000 RETURN" [--delay-ms 200]
+python -m livetools gamectl --exe game.exe click 400 300             # client-area coordinates
+python -m livetools gamectl --exe game.exe macro navigate_menu --macro-file patches/<game>/macros.json
+```
+
+Key names: `RETURN`, `ESCAPE`, `SPACE`, arrows, `TAB`, `F1`-`F12`, `A`-`Z`, `0`-`9`, `NUMPAD0`-`9`, `SHIFT`, `CTRL`, `ALT`. Sequence tokens: `WAIT:N` (pause N ms), `HOLD:KEY:N` (hold key N ms). Window lookup: `--exe` (preferred) or `--window <title substring>`.
+
+### vishook -- Selective visibility override via code cave
+
+Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`.
+
+```bash
+python -m livetools vishook on <jmp_site> <orig_target> [--threshold 500000]
+python -m livetools vishook stats     # override vs passthrough call counts
+python -m livetools vishook off       # restore original jmp
+```
+
 ### analyze -- Offline JSONL aggregation (no Frida needed)
 
 Pure Python. Reads JSONL from `collect` or `trace --output`. Deterministic, non-hallucinated aggregation.
diff --git a/.github/agents/static-analyzer.agent.md b/.github/agents/static-analyzer.agent.md
index 95d55770..9fed1660 100644
--- a/.github/agents/static-analyzer.agent.md
+++ b/.github/agents/static-analyzer.agent.md
@@ -9,7 +9,7 @@ You are a reverse engineering analyst specializing in static analysis of PE bina
 
 ## Setup
 
-On first invocation, read the full tool catalog at `.claude/rules/tool-catalog.md` in the working directory. It contains exact syntax, flags, and caveats for every tool.
+On first invocation, read the full tool catalog at `.github/instructions/tool-catalog.instructions.md` in the working directory. It contains exact syntax, flags, and caveats for every tool.
 
 ## Pre-flight Checks
 
diff --git a/.github/instructions/ffp-proxy.instructions.md b/.github/instructions/ffp-proxy.instructions.md
index 00ebf06f..97cb93d2 100644
--- a/.github/instructions/ffp-proxy.instructions.md
+++ b/.github/instructions/ffp-proxy.instructions.md
@@ -18,7 +18,7 @@ Each game folder under `patches/<GameName>/` is a self-contained remix-comp-prox
 | `src/comp/modules/renderer.cpp` | Draw call routing -- `on_draw_indexed_prim()` and `on_draw_primitive()` |
 | `src/comp/modules/d3d9ex.cpp` | `IDirect3DDevice9` hook layer -- intercepts all 119 methods |
 | `src/comp/modules/skinning.cpp` | Skinning module (vertex expansion, bone upload, FFP blending) |
-| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `ffp_proxy.log` |
+| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `rtx_comp/diagnostics.log` |
 | `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4 toggle) |
 | `src/shared/common/ffp_state.cpp` | FFP state tracker -- engage/disengage, matrix transforms, texture stages |
 | `src/shared/common/ffp_state.hpp` | `ffp_state` class with all state accessors |
@@ -104,7 +104,7 @@ Deploy: `d3d9.dll` + `remix-comp-proxy.ini` to game directory. Place `d3d9_remix
 
 ### Step 5: Diagnose with Log and ImGui
 
-The proxy writes `ffp_proxy.log` after a configurable delay (default 50 seconds) -- do not change the delay. Check VS regs written, vertex declarations, matrix values. Press **F4** for ImGui debug overlay.
+The proxy writes `rtx_comp/diagnostics.log` after a configurable delay (default 50 seconds) -- do not change the delay. Check VS regs written, vertex declarations, matrix values. Press **F4** for ImGui debug overlay.
 
 The user must be in-game with geometry visible when captures are needed.
 
diff --git a/.github/instructions/tool-catalog.instructions.md b/.github/instructions/tool-catalog.instructions.md
index a9257db2..182d1d97 100644
--- a/.github/instructions/tool-catalog.instructions.md
+++ b/.github/instructions/tool-catalog.instructions.md
@@ -4,7 +4,7 @@ applyTo: "retools/**,livetools/**,graphics/**,tools/**,patches/**"
 
 # Tool Catalog
 
-**BEFORE FIRST USE**: Run `python verify_install.py` from the repo root. Do NOT proceed with any tool until every check passes. Common failures: missing `git lfs pull` (LFS pointer stubs instead of binaries), missing `pip install -r requirements.txt`.
+**BEFORE FIRST USE**: Run `python verify_install.py` from the repo root. Do NOT proceed with any tool until every required check passes. If pyghidra/Ghidra shows as WARN, run `python verify_install.py --setup` to auto-download JDK 21 + Ghidra + pyghidra. Common failures: missing `git lfs pull` (LFS pointer stubs instead of binaries), missing `pip install -r requirements.txt`.
 
 All tools work on PE binaries (`.exe` and `.dll`). `$B` = path to binary, `$VA` = hex address, `$D` = path to minidump `.dmp` file. Check tools help command for more info on usage.
 Always consult this catalog before making any move to take the best decision on what to use with best bang for your buck.
@@ -14,26 +14,32 @@ IMPORTANT: Collecting MORE INFORMATION per command run is encouraged over minor
 
 ## Decision Guide
 
-### Run Directly (fast, <5s)
+### Run Directly (main agent)
 
-These are fast and can be run inline without delegation:
+These are fast (<5s) and allowed inline:
 
 - "What compiler built this?" → `python -m retools.sigdb fingerprint $B`
 - "Is this a known library function?" → `python -m retools.sigdb identify $B $VA`
 - "Get full context before reasoning about a function" → `python -m retools.context assemble $B $VA --project $P`
 - "Clean up decompiler output with known names" → pipe through `python -m retools.context postprocess`
 - "Read a typed value from the PE file" → `python -m retools.readmem $B $VA $TYPE`
+- "What constant flows into this register?" → `python -m retools.dataflow $B $VA --constants`
+- "Trace where this value comes from" → `python -m retools.dataflow $B $VA --slice TARGET_VA:REG`
 - "Build an ASI patch DLL" → `python -m retools.asi_patcher build spec.json`
+- "Does a Ghidra project exist for this binary?" → `python retools/pyghidra_backend.py status $B --project $P`
 
-### Delegate to the static-analyzer agent
+### Delegate to `static-analyzer` subagent
 
-Everything else. Specify WHAT you need, not HOW to run it — the agent has the full tool catalog.
+Everything else. Tell the subagent WHAT you need, not HOW to run it — it has the full tool catalog.
 
 **D3D9-specific questions?** Check the DX analysis scripts section below first — they're faster and more targeted than general retools for D3D API usage, device calls, shader constants, and vertex formats.
 
-- "What does this function do?" → decompile + callgraph + xrefs
+- "What does this function do?" → decompile + callgraph + xrefs + dataflow --constants
 - "Who calls this function?" → xrefs or callgraph --up
-- "What does this function call?" → callgraph --down
+- "What does this function call?" → callgraph --down (add --indirect for vtable calls)
+- "Who calls this virtual method?" → xrefs --indirect + filter by vtable slot offset
+- "What constant reaches this call?" → dataflow --constants or --slice VA:REG
+- "Resolve a switch/jump table" → cfg (auto-resolves MSVC switch patterns)
 - "Find a string and who uses it" → string search with xrefs
 - "Where is this global read/written?" → datarefs
 - "Where is struct field +0x54 used?" → structrefs
@@ -43,18 +49,19 @@ Everything else. Specify WHAT you need, not HOW to run it — the agent has the
 - "Find instructions using a specific constant" → instruction search
 - "What crashed and what was the error message?" → dump diagnosis + throwmap
 - "Map all throw sites to error strings" → throwmap list
-- "First time analyzing a binary?" → bootstrap (2-5 min)
+- "First time analyzing a binary?" → bootstrap (2-5 min) + pyghidra analyze (5-15 min) in parallel
 - "Bulk signature scan" → sigdb scan (1-3 min)
 - Any combination of the above
 
-### Live tools (requires attached process)
+### Live tools (main agent, requires attached process)
 
 - "Is this function reached at runtime?" → `livetools trace` or `collect`
 - "What are the actual register values?" → `livetools trace --read` or `bp` + `regs`
 - "How many draw calls happen?" → `livetools dipcnt`
 - "Who writes to this memory address?" → `livetools memwatch`
+- "Send keys/clicks to the game window?" → `livetools gamectl`
 
-### DX analysis scripts (fast first-pass)
+### DX analysis scripts (main agent, fast first-pass)
 
 These are targeted D3D9 scanners under `rtx_remix_tools/dx/scripts/`. They run in seconds and surface D3D-specific patterns that general-purpose retools would take longer to find. **Use these BEFORE retools** when the question is about D3D9 API usage, device calls, shaders, or vertex formats. Run as `python rtx_remix_tools/dx/scripts/<script> <args>`.
 
@@ -79,10 +86,10 @@ These are targeted D3D9 scanners under `rtx_remix_tools/dx/scripts/`. They run i
 
 These are fast first-pass scanners — they surface candidate addresses. Follow up with `retools` (decompiler, xrefs) and `livetools` (trace, bp) for deep analysis of the addresses they find.
 
-### dx9tracer (capture inline, delegate analysis)
+### dx9tracer (main agent for capture, delegate analysis)
 
-- "Trigger a frame capture" → `python -m graphics.directx.dx9.tracer trigger`
-- "Analyze captured frames" → delegate to the static-analyzer agent: summary, render-passes, shader-map, etc.
+- "Trigger a frame capture" → main agent: `python -m graphics.directx.dx9.tracer trigger`
+- "Analyze captured frames" → delegate to `static-analyzer`: summary, render-passes, shader-map, etc.
 
 ## Static Analysis (`retools/`) -- offline, on-disk PE files
 
@@ -91,11 +98,15 @@ These are fast first-pass scanners — they surface candidate addresses. Follow
 | Tool | Purpose | Example |
 |------|---------|---------|
 | `disasm.py $B $VA` | Disassemble N instructions at VA | `disasm.py binary.exe 0x401000 -n 50` |
-| `decompiler.py $B $VA --types` | **Ghidra-quality C decompilation** with knowledge base | `python -m retools.decompiler binary.exe 0x401000 --types patches/proj/kb.h` |
+| `decompiler.py $B $VA --types --project` | **C decompilation** -- pyghidra (if project exists) or r2ghidra | `python -m retools.decompiler binary.exe 0x401000 --types patches/proj/kb.h --project patches/proj` |
+| `pyghidra_backend.py analyze $B --project $P` | **Full Ghidra analysis** -- one-time, saves reusable project | `pyghidra_backend.py analyze game.exe --project patches/MyGame` |
+| `pyghidra_backend.py decompile $B $VA --project $P` | Decompile via saved Ghidra project | `pyghidra_backend.py decompile game.exe 0x401000 --project patches/MyGame` |
+| `pyghidra_backend.py status $B --project $P` | Check if Ghidra project exists | `pyghidra_backend.py status game.exe --project patches/MyGame` |
 | `funcinfo.py $B $VA` | Find function start/end, rets, calling convention, callees | `funcinfo.py binary.exe 0x401000` |
-| `cfg.py $B $VA` | Control flow graph (basic blocks + edges, text or mermaid) | `cfg.py binary.exe 0x401000 --format mermaid` |
-| `callgraph.py $B $VA` | Caller/callee tree (multi-level, --up/--down N) | `callgraph.py binary.exe 0x401000 --up 3` |
-| `xrefs.py $B $VA` | Find all calls/jumps TO an address | `xrefs.py binary.exe 0x401000 -t call` |
+| `cfg.py $B $VA` | Control flow graph (basic blocks + edges, text or mermaid). Resolves MSVC switch/jump tables automatically. `--switch-details` shows table info | `cfg.py binary.exe 0x401000 --format mermaid` |
+| `callgraph.py $B $VA` | Caller/callee tree (multi-level, --up/--down N). `--indirect` adds vtable/fptr calls to --down trees | `callgraph.py binary.exe 0x401000 --down 2 --indirect` |
+| `xrefs.py $B $VA` | Find all calls/jumps TO an address. `--indirect` also scans for `call [reg+offset]`, `call [reg]`, `call [addr]` | `xrefs.py binary.exe 0x401000 --indirect` |
+| `dataflow.py $B $VA` | Forward constant propagation (`--constants`) or backward register slice (`--slice VA:REG`) within a function | `dataflow.py binary.exe 0x401000 --constants` |
 | `datarefs.py $B $VA` | Find instructions that reference a global address (mem deref + `--imm` for push/mov constants) | `datarefs.py binary.exe 0x7A0000 --imm` |
 | `structrefs.py $B $OFF` | Find all `[reg+offset]` accesses (struct field usage) | `structrefs.py binary.exe 0x54 --base esi` |
 | `structrefs.py $B --aggregate` | Reconstruct C struct from all field accesses in a function | `structrefs.py binary.exe --aggregate --fn 0x401000 --base esi` |
@@ -116,7 +127,7 @@ These are fast first-pass scanners — they surface candidate addresses. Follow
 | `sigdb.py scan $B` | Bulk signature scan against DB | `sigdb.py scan game.exe` |
 | `sigdb.py identify $B $VA` | Single function signature lookup (multi-tier) | `sigdb.py identify game.exe 0x401200` |
 | `sigdb.py fingerprint $B` | Identify compiler version (Rich header + markers + imports) | `sigdb.py fingerprint game.exe` |
-| `context.py assemble $B $VA --project $P` | Gather full analysis context for a function. Includes forward constant propagation by default (`--no-dataflow` to skip on large functions) | `context.py assemble game.exe 0x401500 --project Warband` |
+| `context.py assemble $B $VA --project $P` | Gather full analysis context for a function. Includes forward constant propagation by default (`--no-dataflow` to skip) | `context.py assemble game.exe 0x401500 --project Warband` |
 | `context.py postprocess $B $VA --project $P` | Mechanically rename/annotate decompiler output (pipe) | `decompiler.py ... \| context.py postprocess ...` |
 | `sigdb.py build $MANIFEST` | Build/extend signature DB from manifest | `sigdb.py build sources.json` |
 | `sigdb.py pull` | Download signature DB from HuggingFace | `sigdb.py pull` or `sigdb.py pull --sources` |
@@ -151,9 +162,10 @@ These are fast first-pass scanners — they surface candidate addresses. Follow
 ## Dynamic Analysis (`livetools/`) -- Frida-based, attaches to running process
 
 ```
-python -m livetools attach <process>    # start session
-python -m livetools detach              # end session
-python -m livetools status              # check connection
+python -m livetools attach <process>                    # attach to running process by name or PID
+python -m livetools attach "C:/Games/game.exe" --spawn  # launch + instrument before init code runs
+python -m livetools detach                              # end session
+python -m livetools status                              # check connection
 ```
 
 | Command | Purpose |
@@ -166,12 +178,15 @@ python -m livetools status              # check connection
 | `regs` / `stack` / `bt` | Inspect registers, stack, backtrace at break |
 | `mem read $VA $SIZE` | Read live process memory (supports --as float32) |
 | `mem write $VA $HEX` | Write live process memory |
+| `mem alloc $SIZE` | Allocate rwx memory in target (for code caves) |
 | `disasm [$VA]` | Disassemble from live process |
 | `scan $PATTERN` | Search process memory for byte pattern |
 | `modules` | List loaded modules with base addresses |
 | `dipcnt on/off/read` | D3D9 DrawIndexedPrimitive call counter |
 | `dipcnt callers [N]` | Sample N DIP calls and histogram return addresses |
 | `memwatch start/stop/read` | Memory write watchpoint with backtrace |
+| `vishook on/off/stats` | Selective visibility override via code cave (forces visible above caller threshold) |
+| `gamectl key/keys/click/macro` | Send keys/clicks to game window (no Frida, no focus steal) |
 | `analyze $FILE` | Offline analysis of collected .jsonl trace data |
 
 **NOTE**: Some processes require their window to be focused for traces to capture data.
@@ -237,9 +252,19 @@ Targeted first-pass scanners for D3D9 games. Run from repo root. Output is candi
 |--------|-----------------|---------|
 | `find_d3d_calls.py $B` | D3D9/D3DX imports and call sites | `python rtx_remix_tools/dx/scripts/find_d3d_calls.py game.exe` |
 | `find_vs_constants.py $B` | `SetVertexShaderConstantF` call sites with register/count args | `python rtx_remix_tools/dx/scripts/find_vs_constants.py game.exe` |
+| `find_ps_constants.py $B` | `SetPixelShaderConstantF/I/B` call sites with register/count args | `python rtx_remix_tools/dx/scripts/find_ps_constants.py game.exe` |
 | `find_device_calls.py $B` | Device vtable call patterns and device pointer refs | `python rtx_remix_tools/dx/scripts/find_device_calls.py game.exe` |
+| `find_render_states.py $B` | SetRenderState arguments decoded by category (culling, blending, depth, fog) | `python rtx_remix_tools/dx/scripts/find_render_states.py game.exe` |
+| `find_texture_ops.py $B` | Texture pipeline: SetTexture stages, TSS color/alpha ops, sampler states | `python rtx_remix_tools/dx/scripts/find_texture_ops.py game.exe` |
+| `find_transforms.py $B` | SetTransform/MultiplyTransform types (World, View, Projection, Texture) | `python rtx_remix_tools/dx/scripts/find_transforms.py game.exe` |
+| `find_surface_formats.py $B` | CreateTexture/RenderTarget/DepthStencil D3DFMT extraction | `python rtx_remix_tools/dx/scripts/find_surface_formats.py game.exe` |
+| `find_stateblocks.py $B` | State block creation, recording, and apply patterns | `python rtx_remix_tools/dx/scripts/find_stateblocks.py game.exe` |
+| `decode_fvf.py $B` | FVF bitfield decode from SetFVF calls (or `--decode 0xNNN` manual) | `python rtx_remix_tools/dx/scripts/decode_fvf.py game.exe` |
 | `find_vtable_calls.py $B` | D3DX constant table usage and D3D9 vtable calls | `python rtx_remix_tools/dx/scripts/find_vtable_calls.py game.exe` |
 | `decode_vtx_decls.py $B --scan` | Vertex declaration formats (BLENDWEIGHT/BLENDINDICES = skinning) | `python rtx_remix_tools/dx/scripts/decode_vtx_decls.py game.exe --scan` |
+| `find_shader_bytecode.py $B` | Embedded shader bytecode extraction (version, size, `--dump-dir`) | `python rtx_remix_tools/dx/scripts/find_shader_bytecode.py game.exe` |
+| `classify_draws.py $B` | Draw call classification by state context (FFP/shader/hybrid %) | `python rtx_remix_tools/dx/scripts/classify_draws.py game.exe` |
+| `find_matrix_registers.py $B` | Identify View/Proj/World registers (CTAB + frequency + layout suggestion) | `python rtx_remix_tools/dx/scripts/find_matrix_registers.py game.exe` |
 | `find_skinning.py $B` | Consolidated skinning analysis: skinned decls, bone palettes, blend states, suggested INI | `python rtx_remix_tools/dx/scripts/find_skinning.py game.exe` |
 | `find_blend_states.py $B` | D3DRS_VERTEXBLEND + INDEXEDVERTEXBLENDENABLE + WORLDMATRIX transforms | `python rtx_remix_tools/dx/scripts/find_blend_states.py game.exe` |
 | `scan_d3d_region.py $B 0xSTART 0xEND` | Map all D3D9 vtable calls in a code region | `python rtx_remix_tools/dx/scripts/scan_d3d_region.py game.exe 0x401000 0x500000` |
@@ -290,6 +315,14 @@ Minidumps vary in how much data they capture depending on `MiniDumpWriteDump` fl
 
 These tools find references via absolute memory operands, immediate values (with `--imm` flag), and RIP-relative addressing. If you suspect a reference exists but the tool doesn't find it, the address might be computed at runtime. Try `search.py pattern` with the address bytes directly, or use `livetools memwatch`.
 
+### `pyghidra_backend.py` -- requires Ghidra installation
+
+Requires Ghidra 11.x+ installed and `GHIDRA_INSTALL_DIR` environment variable set. **Optional** -- the toolkit works without it (r2ghidra remains the fallback).
+
+**Disk usage**: Ghidra projects are ~10-20x the binary size. A 30MB game exe produces a ~300-600MB `.rep/` directory under `patches/<project>/ghidra/`. This directory is already covered by `.gitignore` (the `patches/` exclusion).
+
+**First-time analysis** takes 5-15 minutes depending on binary size. Subsequent decompilation from the saved project is instant (<1s plus ~3s JVM startup per process).
+
 ### `livetools` -- static vs runtime addresses
 
 **x86 games without ASLR** (most 32-bit games): the PE preferred base matches the runtime load address. Addresses from `retools` can be passed directly to `livetools`.
diff --git a/.github/prompts/dx9-ffp-port.prompt.md b/.github/prompts/dx9-ffp-port.prompt.md
index 2715d67c..de1e3dd4 100644
--- a/.github/prompts/dx9-ffp-port.prompt.md
+++ b/.github/prompts/dx9-ffp-port.prompt.md
@@ -18,7 +18,7 @@ The remix-comp-proxy codebase (`rtx_remix_tools/dx/remix-comp-proxy/`) is a d3d9
 | `src/comp/modules/renderer.cpp` | Draw call routing -- `on_draw_indexed_prim()` and `on_draw_primitive()` |
 | `src/comp/modules/d3d9ex.cpp` | `IDirect3DDevice9` hook layer -- intercepts all 119 methods |
 | `src/comp/modules/skinning.cpp` | Skinning module (vertex expansion, bone upload, FFP blending) |
-| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `ffp_proxy.log` |
+| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `rtx_comp/diagnostics.log` |
 | `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4 toggle) |
 | `src/shared/common/ffp_state.cpp` | FFP state tracker -- engage/disengage, matrix transforms, texture stages |
 | `src/shared/common/ffp_state.hpp` | `ffp_state` class with all state accessors |
@@ -100,7 +100,7 @@ Deploy: `d3d9.dll` + `remix-comp-proxy.ini` to game directory. Place `d3d9_remix
 
 ### Step 5: Diagnose with Log and ImGui
 
-The proxy writes `ffp_proxy.log` after a configurable delay (default 50 seconds) -- do not change the delay. Check VS regs written, vertex declarations, matrix values. Press **F4** for ImGui debug overlay.
+The proxy writes `rtx_comp/diagnostics.log` after a configurable delay (default 50 seconds) -- do not change the delay. Check VS regs written, vertex declarations, matrix values. Press **F4** for ImGui debug overlay.
 
 The user must be in-game with geometry visible when captures are needed.
 
diff --git a/.github/skills/dx9-ffp-port/SKILL.md b/.github/skills/dx9-ffp-port/SKILL.md
index 01082070..1f53e708 100644
--- a/.github/skills/dx9-ffp-port/SKILL.md
+++ b/.github/skills/dx9-ffp-port/SKILL.md
@@ -4,74 +4,74 @@ description: 'Port a DX9 shader-based game to fixed-function pipeline for RTX Re
 argument-hint: '<game.exe path>'
 ---
 
-# DX9 FFP Proxy — Game Porting Prompt
+# DX9 FFP Proxy -- Game Porting
 
-You are helping a user port a DX9 shader-based game to the fixed-function pipeline using the `rtx_remix_tools/dx/remix-comp-proxy/` codebase in this workspace. The goal is RTX Remix compatibility: Remix requires FFP geometry to inject path-traced lighting and replaceable assets. Also use the Vibe RE tools (retools, livetools) for static and dynamic analysis to assist with developing this wrapper. They are meant to be used together.
+Port a DX9 shader-based game to fixed-function pipeline (FFP) for RTX Remix compatibility. Remix requires FFP geometry to inject path-traced lighting and replaceable assets.
 
-**SKINNING IS OFF BY DEFAULT.** Do NOT enable skinning, modify skinning code, or discuss skinning infrastructure unless the user explicitly asks for character model / bone / skeletal animation support. Until then, treat skinning as non-existent. When the user does request it, read `src/comp/modules/skinning.hpp` and `src/comp/modules/skinning.cpp` for the full implementation.
+**NEVER MODIFY TEMPLATE CODE.** The following directories are read-only templates:
+- `rtx_remix_tools/dx/remix-comp-proxy/` — remix-comp-proxy framework template
 
-**SKINNING APPROACH: FFP indexed vertex blending, NOT CPU matrix math.** When skinning is enabled, keep BLENDINDICES and BLENDWEIGHT in the vertex declaration and buffer, upload bone matrices via `SetTransform(D3DTS_WORLDMATRIX(n), &boneMatrix[n])`, enable `D3DRS_INDEXEDVERTEXBLENDENABLE = TRUE`, and set `D3DRS_VERTEXBLEND` to the weight count. CPU-side vertex skinning is a **last resort** -- it is extremely expensive and tanks frame rate. Always prefer the hardware path.
+To create a game patch, **copy** the template to `patches/<GameName>/` and edit the copy. If the user asks you to edit remix-comp-proxy code, always confirm whether they mean the template or a game-specific copy under `patches/`. Only modify the template if the user **explicitly** says to change the template itself.
+
+**SKINNING IS OFF BY DEFAULT.** Do NOT enable skinning in `remix-comp-proxy.ini`, modify skinning code, or discuss skinning infrastructure unless the user explicitly asks for character model / bone / skeletal animation support. When requested, read `src/comp/modules/skinning.hpp` and `src/comp/modules/skinning.cpp` for the full implementation.
+
+**SKINNING APPROACH: FFP indexed vertex blending, NOT CPU matrix math.** When skinning is enabled, the correct approach is:
+1. Keep BLENDINDICES and BLENDWEIGHT elements in the vertex declaration and vertex buffer
+2. Upload bone matrices via `SetTransform(D3DTS_WORLDMATRIX(n), &boneMatrix[n])` for each bone
+3. Enable `D3DRS_INDEXEDVERTEXBLENDENABLE = TRUE`
+4. Set `D3DRS_VERTEXBLEND` to the appropriate weight count (e.g. `D3DVBF_3WEIGHTS`)
+5. Let the FFP hardware pipeline do the blending
+
+CPU-side vertex skinning (manually multiplying vertices by bone matrices) is a **last resort only**. It is extremely expensive, tanks frame rate, and should only be considered when FFP indexed vertex blending is not feasible. Always prefer the hardware path above.
 
 ---
 
 ## What remix-comp-proxy Does
 
-The codebase is a d3d9.dll proxy based on remix-comp-base that intercepts `IDirect3DDevice9` and:
+Each game folder under `patches/<GameName>/` is a self-contained remix-comp-proxy project (copied from `rtx_remix_tools/dx/remix-comp-proxy/`). It is a d3d9.dll proxy that:
 
-1. Captures vertex shader constants (View, Projection, World matrices) from `SetVertexShaderConstantF`
-2. Parses `SetVertexDeclaration` to detect per-element attributes: BLENDWEIGHT+BLENDINDICES (skinned), POSITIONT (screen-space), NORMAL presence, and per-element byte offsets and types
-3. Routes `DrawIndexedPrimitive` by vertex layout:
-   - No NORMAL -> HUD/UI pass-through (uses different VS constant layout than world geometry)
-   - Skinned with skinning module enabled -> expands vertices to a fixed FLOAT layout, then draws with FFP indexed vertex blending
-   - Rigid 3D (has NORMAL) -> NULLs shaders, applies FFP transforms, draws
-4. Routes `DrawPrimitive` by declaration state: world-space draws (have decl, no POSITIONT, not skinned) engage FFP; screen-space and no-decl draws pass through
-5. Applies captured matrices via `SetTransform` (FFP)
-6. Sets up texture stages and lighting for FFP rendering (stages 1-7 disabled to prevent stale auxiliary textures reaching Remix)
-7. Chain-loads RTX Remix (`d3d9_remix.dll`)
+1. Captures VS constants (View, Projection, World matrices) from `SetVertexShaderConstantF` via `ffp_state::on_set_vs_const_f`
+2. Parses `SetVertexDeclaration` via `ffp_state::on_set_vertex_declaration` to detect BLENDWEIGHT+BLENDINDICES (skinned), POSITIONT (screen-space), NORMAL presence, and per-element byte offsets
+3. Routes `DrawIndexedPrimitive` via `renderer::on_draw_indexed_prim`:
+   - No NORMAL -> HUD/UI pass-through
+   - Skinned + skinning module enabled -> `skinning::draw_skinned_dip()`
+   - Rigid 3D (has NORMAL) -> NULLs shaders, applies FFP transforms
+4. Routes `DrawPrimitive` via `renderer::on_draw_primitive`: world-space (has decl, no POSITIONT, not skinned) -> FFP; otherwise pass-through
+5. Applies captured matrices via `ffp_state::apply_transforms` -> `SetTransform`
+6. Sets up texture stages and lighting for FFP rendering
+7. Loads the real d3d9 chain (RTX Remix `d3d9_remix.dll` or system d3d9) via d3d9_proxy
 
-## Source File Map
+## Codebase File Map
 
 | File | Role |
 |------|------|
-| `src/comp/main.cpp` | DLL entry, module loading, initialization |
-| `src/comp/modules/renderer.cpp` | Draw call routing -- `on_draw_indexed_prim()` and `on_draw_primitive()` |
-| `src/comp/modules/d3d9ex.cpp` | `IDirect3DDevice9` hook layer -- intercepts all 119 methods |
-| `src/comp/modules/skinning.cpp` | Skinning module (vertex expansion, bone upload, FFP blending) |
-| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `ffp_proxy.log` |
-| `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4 toggle) |
-| `src/shared/common/ffp_state.cpp` | FFP state tracker -- engage/disengage, matrix transforms, texture stages |
-| `src/shared/common/ffp_state.hpp` | `ffp_state` class with all state accessors |
-| `src/shared/common/config.hpp` | Config structures: `ffp_settings`, `skinning_settings`, etc. |
-| `remix-comp-proxy.ini` (in `assets/`) | Runtime config: `[FFP]`, `[Skinning]`, `[Diagnostics]`, `[Remix]`, `[Chain]` |
-| `build.bat` | Build script: outputs d3d9.dll proxy |
-
-The codebase is C++20, uses build.bat for builds, component module system for extensibility.
-
-## What Needs to Change Per Game
-
-The VS constant register layout is defined in `src/shared/common/ffp_state.hpp` as member defaults. Edit these when porting a new game, then rebuild:
+| `src/comp/modules/renderer.cpp` | Draw routing -- `on_draw_indexed_prim()` and `on_draw_primitive()` |
+| `src/comp/modules/renderer.hpp` | `drawcall_mod_context` for save/restore state around draws |
+| `src/shared/common/ffp_state.cpp` | Core FFP state tracker -- engage/disengage, transforms, texture stages |
+| `src/shared/common/ffp_state.hpp` | FFP state class with all accessors |
+| `src/shared/common/config.hpp` | Config structure parsed from `remix-comp-proxy.ini` |
+| `src/comp/main.cpp` | DLL entry, d3d9 proxy init, window finder, config loading |
+| `src/comp/comp.cpp` | Module init: registers renderer, diagnostics, skinning, imgui |
+| `src/comp/d3d9_proxy.cpp` | Loads real d3d9 chain, DLL pre/post-load, forwarded exports |
+| `src/comp/modules/d3d9ex.cpp` | `IDirect3DDevice9` / `IDirect3D9` wrapper + exported Direct3DCreate9 |
+| `src/comp/modules/d3d9ex.hpp` | D3D9 wrapper class declarations |
+| `src/comp/modules/diagnostics.cpp` | 50-sec delay, 3-frame diagnostic log to `rtx_comp/diagnostics.log` |
+| `src/comp/modules/skinning.cpp` | Optional skinning module (vertex expansion + bone upload) |
+| `src/comp/modules/skinning.hpp` | Skinning class declaration |
+| `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4) with FFP tab |
+| `src/comp/game/game.cpp` | Per-game address init (patterns, hooks) |
+| `src/comp/game/game.hpp` | Per-game variables and function typedefs |
+| `remix-comp-proxy.ini` (in `assets/`) | Runtime config: albedo stage, skinning toggle, diagnostics, DLL chain |
+| `build.bat` | Build script: outputs d3d9.dll proxy. `build.bat [release\|debug] [--name Name]` |
+
+**`rtx_remix_tools/dx/remix-comp-proxy/` is the TEMPLATE.** Each game gets a full copy under `patches/<GameName>/` — the entire folder is self-contained and can be distributed as a standalone repo. Edit `src/comp/` directly in the game's copy.
+
+**Before reading remix-comp-proxy source files**, read [references/remix-comp-context.md](references/remix-comp-context.md) for a skip-list of boilerplate files (~7,000 lines) you should never open, with summaries of what they do. It also lists the ~1,200 lines of files that actually matter for per-game work.
 
-```cpp
-int vs_reg_view_start_ = 0;    int vs_reg_view_end_ = 4;
-int vs_reg_proj_start_ = 4;    int vs_reg_proj_end_ = 8;
-int vs_reg_world_start_ = 16;  int vs_reg_world_end_ = 20;
-int vs_reg_bone_threshold_ = 20;   // first register treated as bone palette
-int vs_regs_per_bone_ = 3;        // 3 = 4x3 packed, 4 = full 4x4
-int vs_bone_min_regs_ = 3;        // min count to qualify as bone upload
-```
-
-**Bone config:** Run `find_skinning.py` to determine bone start register and upload pattern. Some games upload all bones at once; others upload in groups until hitting a max (e.g., groups of 15, max 75). If grouped, lower `vs_bone_min_regs_`. If bone uploads overlap with non-bone constants, raise `vs_reg_bone_threshold_`.
-
-Beyond the INI config, users may need to modify:
-- `renderer.cpp` `on_draw_indexed_prim()` -- draw call routing (which draws get FFP vs shader pass-through)
-- `renderer.cpp` `on_draw_primitive()` -- UI/particle handling
-- `ffp_state.cpp` `setup_lighting()`, `setup_texture_stages()`, `apply_transforms()` -- FFP render state and matrix configuration
-- `AlbedoStage` in `remix-comp-proxy.ini` `[FFP]` section -- which texture stage holds the diffuse/albedo
+---
 
 ## Porting Workflow
 
-Follow these steps in order for ideal results. Each step depends on the previous. Be sure to use the Vibe Reverse Engineering tools (retools, livetools) for static and dynamic analysis as well. You do not need to strictly follow the order laid out here.
-
 ### Step 1: Static Analysis
 
 Run the analysis scripts to understand the game's D3D9 usage:
@@ -99,148 +99,214 @@ python rtx_remix_tools/dx/scripts/find_transforms.py "<game.exe>"
 python rtx_remix_tools/dx/scripts/find_surface_formats.py "<game.exe>"
 ```
 
+Scripts are fast first-pass scanners -- surface candidate addresses only. Always follow up with `retools` and `livetools` for deep analysis.
+
+**Alternative: DX9 Tracer capture.** Deploy the tracer proxy (`graphics/directx/dx9/tracer/`) to capture a full frame, then analyze with `--matrix-flow`, `--vtx-formats`, `--shader-map`, and `--const-provenance` to discover the register layout without reverse engineering the binary.
+
 Key things to find:
-- How the game obtains its D3D device (Direct3DCreate9 call site -> CreateDevice call)
+- How the game obtains its D3D device (Direct3DCreate9 -> CreateDevice)
 - Which functions call `SetVertexShaderConstantF` and with what register/count patterns
-- What vertex declaration formats the game uses (BLENDWEIGHT/BLENDINDICES = skinning)
-- Where the main rendering loop/draw calls live
+- What vertex declaration formats are used (BLENDWEIGHT/BLENDINDICES = skinning)
+- Where the main render loop / draw calls live
+
+### Step 2: Discover VS Constant Register Layout
 
-### Step 2: Discover VS Constant Layout
+This is the **most critical** step. Determine which VS constant registers hold View, Projection, and World matrices.
 
-This is the **most critical** step. You must determine which VS constant registers hold View, Projection, and World matrices.
+**Remix REQUIRES separate World, View, and Projection matrices.** A concatenated WorldViewProj (WVP) or ViewProj (VP) matrix will NOT work -- Remix needs individual matrices to apply its own camera and per-object transforms. If the game uploads a pre-multiplied WVP, the proxy must intercept the individual W, V, P matrices *before* the game concatenates them. This is the #1 source of broken Remix ports.
 
-**Remix REQUIRES separate World, View, and Projection matrices.** A concatenated WorldViewProj (WVP) or ViewProj (VP) will NOT work -- Remix needs individual matrices for its own camera and per-object transforms. If the game uploads a pre-multiplied WVP, the proxy must intercept the individual matrices *before* concatenation. This is the #1 source of broken Remix ports. Use `find_matrix_registers.py` to detect this pattern.
+**Start with the matrix register finder:**
+```bash
+python rtx_remix_tools/dx/scripts/find_matrix_registers.py "<game.exe>"
+```
+This cross-references SVSCF call patterns, shader CTAB names, and frequency analysis to suggest a register layout. Always verify its output with runtime data.
 
-**Static approach:** Decompile functions that call `SetVertexShaderConstantF`:
+**Static approach:** Decompile call sites:
 ```bash
 python -m retools.decompiler <game.exe> <call_site_addr> --types patches/<project>/kb.h
 ```
 
-**Dynamic approach:** Trace `SetVertexShaderConstantF` calls live:
+**Dynamic approach:** Trace `SetVertexShaderConstantF` live:
 ```bash
 python -m livetools trace <call_addr> --count 50 \
     --read "[esp+8]:4:uint32; [esp+10]:4:uint32; *[esp+c]:64:float32"
 ```
-This captures: startRegister, Vector4fCount, and the actual float data (first 4 vec4 constants, dereferenced from `pConstantData`).
+Captures: startRegister, Vector4fCount, and the first 4 vec4 constants of actual float data.
+
+**DX9 Tracer approach:** Capture a frame and analyze:
+```bash
+python -m graphics.directx.dx9.tracer analyze <JSONL> --const-provenance
+python -m graphics.directx.dx9.tracer analyze <JSONL> --matrix-flow
+python -m graphics.directx.dx9.tracer analyze <JSONL> --shader-map
+```
 
 **How to identify matrices:**
-- View matrix: changes with camera movement, contains camera orientation
-- Projection matrix: contains aspect ratio and FOV, rarely changes
-- World matrix: changes per object, contains position/rotation/scale
+- View matrix: changes with camera movement; contains camera orientation
+- Projection matrix: contains aspect ratio and FOV; rarely changes
+- World matrix: changes per object; contains position/rotation/scale
 - Look for 4x4 matrices (16 floats = 4 registers). Row 3 often has `[0, 0, 0, 1]` for affine transforms.
+- **Watch for concatenated matrices:** If the game only uploads one matrix per draw (e.g. WVP at c0-c3), the individual W/V/P are being multiplied before upload. Trace back to find where the multiplication happens -- you need to capture W, V, P separately before that point.
+
+### Step 3: Set Up Per-Game Project
 
-### Step 3: Copy comp/ and Configure
+**IMPORTANT:** `rtx_remix_tools/dx/remix-comp-proxy/` is the **template**. NEVER edit it directly. Each game gets a full copy of the framework.
 
-1. Copy `rtx_remix_tools/dx/remix-comp-proxy/src/comp/` to `patches/<GameName>/proxy/comp/`
-2. Copy `remix-comp-proxy.ini` from `assets/` to `patches/<GameName>/proxy/`
-3. Edit register layout defaults in `src/shared/common/ffp_state.hpp`
-4. Use `build.bat` for the game-specific build
-5. Update `kb.h` with any function signatures, structs, or globals discovered
+1. Copy the entire `rtx_remix_tools/dx/remix-comp-proxy/` folder to `patches/<GameName>/` (excluding `build/`)
+2. Edit `src/comp/` directly in the game's copy — this is the per-game customization layer
+3. Edit register layout defaults in `src/shared/common/ffp_state.hpp` (see Register Layout section below)
+4. Edit `src/comp/main.cpp`: set `WINDOW_CLASS_NAME` to the game's window class
+5. Customize `src/comp/modules/renderer.cpp` draw routing if needed (see Decision Trees below)
+6. Customize `src/comp/game/game.cpp` with game-specific address init if hooks are needed
+7. Update `kb.h` with discovered function signatures, structs, and globals
+
+The game folder is now fully self-contained and can be distributed as a standalone git repo.
 
 ### Step 4: Build and Deploy
 
+From the game folder:
 ```bash
 cd patches/<GameName>
 build.bat release --name <GameName>
 ```
 
-Deploy: `d3d9.dll` + `remix-comp-proxy.ini` to game directory. Place `d3d9_remix.dll` there if using Remix.
+The build produces `d3d9.dll` in `patches/<GameName>/build/bin/release/`. Deploy:
+- `d3d9.dll` to the game directory (the game loads this as its d3d9 proxy)
+- `remix-comp-proxy.ini` to the game directory
+- `d3d9_remix.dll` to the game directory if using Remix
 
 ### Step 5: Diagnose with Log and ImGui
 
-The proxy writes `ffp_proxy.log` in the game directory. After a configurable delay (default 50 seconds via `[Diagnostics] DelayMs`), it logs frames of detailed draw call data:
+**rtx_comp/diagnostics.log:** Written to the `rtx_comp/` subfolder of the game directory after a configurable delay (default 50 seconds), then logs 3 frames of detailed draw call data:
 
-- **VS regs written**: shows which constant registers the game actually fills
-- **Vertex declarations**: what vertex elements each draw uses (POSITION, NORMAL, TEXCOORD, BLENDWEIGHT, etc.)
-- **Draw calls**: primitive type, vertex count, index count, textures bound per stage
+- **VS regs written**: which constant registers the game actually fills
+- **Vertex declarations**: what vertex elements each draw uses
+- **Draw calls**: primitive type, vertex count, index count, textures per stage
 - **Matrices**: actual View/Proj/World values being applied
+- **Raw vertex bytes**: hex dump of first vertices for early draw calls
 
-Press **F4** to open the ImGui debug overlay with live draw call stats and FFP conversion info.
-
-Use this to iterate: wrong matrices -> re-check register mapping. Missing textures -> adjust AlbedoStage. Objects at wrong positions -> world matrix register is wrong.
+Do not change the logging delay unless the user asks -- it ensures the user gets into the game with real geometry before logging begins.
 
-## Architecture Details for Editing
+**ImGui overlay (F4):** Press F4 to toggle the debug overlay. The FFP tab shows real-time draw call stats, VS constant register write history, and enables a fake camera for testing transforms.
 
-### Code Map: Edit vs Do-Not-Touch
+**Tell the user when you need them to interact with the game** for logging or hooking purposes. They must be in-game with geometry visible for the log to be useful.
 
-| File / Section | Edit Per-Game? |
-|----------------|----------------|
-| `ffp_state.hpp` register layout defaults | **YES** -- rebuild required |
-| `remix-comp-proxy.ini` `[Skinning] Enabled=` | **YES** -- only after rigid FFP works |
-| `renderer.cpp` `on_draw_indexed_prim()` | **YES** -- main draw routing |
-| `renderer.cpp` `on_draw_primitive()` | **YES** -- draw routing for non-indexed draws |
-| `ffp_state.cpp` `setup_lighting()`, `setup_texture_stages()`, `apply_transforms()` | MAYBE -- tweak if game needs different FFP state |
-| `ffp_state.cpp` `on_set_vs_const_f()` | MAYBE -- dirty tracking |
-| `ffp_state.cpp` `on_set_vertex_declaration()` | MAYBE -- element parsing |
-| `d3d9ex.cpp` hooks, `skinning.cpp`, `diagnostics.cpp`, `imgui.cpp` | NO -- infrastructure |
-| `ffp_state.cpp` `engage()` / `disengage()` | NO |
+---
 
-### DrawIndexedPrimitive Decision Tree
+## Register Layout (`ffp_state.hpp`)
 
-This is the routing logic in `renderer.cpp` `on_draw_indexed_prim()`:
+The VS constant register layout is defined as member defaults in `src/shared/common/ffp_state.hpp`. Edit these when porting a new game:
 
-```
-viewProjValid?
-+-- NO  -> shader passthrough (transforms not captured yet)
-+-- YES
-    +-- curDeclIsSkinned?
-    |   +-- YES + skinning module -> skinning::draw_skinned_dip()
-    |   +-- YES + no skinning     -> shader passthrough
-    +-- NOT skinned
-        +-- !curDeclHasNormal -> shader passthrough (HUD/UI)
-        +-- hasNormal -> ffp_state::engage + rigid FFP draw
+```cpp
+// In ffp_state.hpp — private members with game-specific defaults
+int vs_reg_view_start_ = 0;
+int vs_reg_view_end_ = 4;
+int vs_reg_proj_start_ = 4;
+int vs_reg_proj_end_ = 8;
+int vs_reg_world_start_ = 16;
+int vs_reg_world_end_ = 20;
+int vs_reg_bone_threshold_ = 20;  // only matters when [Skinning] Enabled=1
+int vs_regs_per_bone_ = 3;        // 3 = 4x3 packed bones (most common), 4 = full 4x4
+int vs_bone_min_regs_ = 3;        // minimum register count to qualify as bone upload
 ```
 
-**Common per-game changes to this tree:**
-- Game's world geometry omits NORMAL -> remove or change the `!cur_decl_has_normal()` filter
-- Game has special passes (shadow, reflection) -> filter by shader pointer, render target, or vertex count
-- Game draws UI with DrawIndexedPrimitive + NORMAL -> add a filter (e.g. check stride or texture)
+Each matrix occupies 4 consecutive vec4 registers (= 16 floats). After changing defaults, rebuild with `build.bat`.
 
-### DrawPrimitive Decision Tree
+### Bone Configuration for Skinning
 
-```
-viewProjValid AND lastDecl AND !curDeclHasPosT AND !curDeclIsSkinned?
-+-- YES -> ffp_state::engage (world-space particles, non-indexed geometry)
-+-- NO  -> shader passthrough (screen-space UI, POSITIONT, no decl, skinned)
-```
+Before enabling skinning, run `find_skinning.py` to determine the bone start register (`vs_reg_bone_threshold_`) and upload pattern. Some games upload all bones in one call; others upload in groups until hitting a max (e.g., groups of 15, max 75). If the game uses grouped uploads, lower `vs_bone_min_regs_` so the proxy doesn't reject the smaller batches. If bone uploads overlap with non-bone constants, raise `vs_reg_bone_threshold_`.
+
+## INI Config (`remix-comp-proxy.ini`)
 
-### Skinning Data Flow
+Runtime settings that don't require recompile:
 
-When skinning is enabled via `[Skinning] Enabled=1` in `remix-comp-proxy.ini`:
+```ini
+[FFP]
+Enabled=1
+AlbedoStage=0
+; Albedo texture stage (0-7). Set to whichever stage the game binds the diffuse texture.
 
-1. **`ffp_state::on_set_vertex_declaration()`** -- Parses `D3DVERTEXELEMENT9` array. If both BLENDWEIGHT and BLENDINDICES are present, sets `cur_decl_is_skinned_` and captures per-element byte offsets and types.
+[Skinning]
+Enabled=0
+; Only set to 1 after rigid FFP works correctly.
+; Run find_skinning.py to determine bone register layout before enabling.
 
-2. **`ffp_state::on_set_vs_const_f()`** -- When a write hits registers >= `BoneThreshold` with count >= `BoneMinRegs` and divisible by `RegsPerBone`, stores `bone_start_reg_` and `num_bones_`.
+[Diagnostics]
+Enabled=1
+DelayMs=50000
+LogFrames=3
 
-3. **`skinning::draw_skinned_dip()`** -- Locks the game's source vertex buffer, calls `expand_skin_vertex()` per vertex, caches results by hash key.
+[Remix]
+Enabled=1
+DLLName=d3d9_remix.dll
 
-4. **`skinning::upload_bones()`** -- Reads bone matrices from VS constants, transposes, uploads via `SetTransform(WORLDMATRIX(i))`. Sets `D3DRS_VERTEXBLEND` and `D3DRS_INDEXEDVERTEXBLENDENABLE`.
+[Chain]
+PreLoad=
+PostLoad=
+; Semicolon-separated DLLs/ASIs to load before/after the d3d9 chain.
+; Example: PreLoad=patch.dll;fix.asi
+```
 
-5. **Draw** -- The expanded VB + shared declaration are bound, draw executes with FFP indexed vertex blending. After the draw, original VB/decl/textures are restored.
+---
 
-All of this is infrastructure (no per-game edits). The only game-specific parts are the `ffp_state.hpp` bone register settings and `[Skinning] Enabled=` toggle.
+## Architecture: What to Edit vs What to Leave Alone
+
+Each game folder under `patches/<GameName>/` is a **self-contained** copy of the full remix-comp-proxy framework. Edit files directly in the game's copy.
+
+| Component (in `patches/<GameName>/`) | Edit Per-Game? |
+|-----------|----------------|
+| `ffp_state.hpp` register layout defaults | **YES** — rebuild after changing |
+| `remix-comp-proxy.ini` albedo stage, diagnostics, chain | **YES** |
+| `src/comp/main.cpp` WINDOW_CLASS_NAME | **YES** |
+| `src/comp/modules/renderer.cpp` draw routing | **YES** -- main draw routing |
+| `src/comp/game/game.cpp` address init and hooks | **YES** -- per-game hooks |
+| `src/comp/game/structs.hpp` game structs | **YES** -- per-game data structures |
+| `src/shared/common/ffp_state.cpp` engage/disengage/transforms | MAYBE -- only for unusual FFP needs |
+| `src/shared/common/config.hpp` | MAYBE -- add new INI sections if needed |
+| `src/comp/modules/d3d9ex.cpp` | NO -- forwards all 119 methods |
+| `src/comp/modules/diagnostics.cpp` | NO -- generic frame logger |
+| `src/comp/modules/imgui.cpp` | NO -- debug overlay |
+| `src/shared/` everything else | NO -- framework code |
 
-## Common Pitfalls
+### DrawIndexedPrimitive Decision Tree
+
+```
+ffp.is_enabled() AND ffp.view_proj_valid()?
++-- NO  -> passthrough with shaders
++-- YES
+    +-- ffp.cur_decl_is_skinned()?
+    |   +-- YES + skinning module -> skinning::draw_skinned_dip()
+    |   +-- YES + no skinning     -> passthrough with shaders
+    +-- !ffp.cur_decl_has_normal()?
+    |   +-- passthrough (HUD/UI)
+    |   GAME-SPECIFIC: remove this filter if world geometry lacks NORMAL
+    +-- else (rigid 3D mesh)
+        +-- ffp.engage() + draw + restore
+```
 
-- **Matrices look wrong**: D3D9 FFP `SetTransform` expects row-major matrices. The proxy transposes them. If the game stores matrices column-major in VS constants (the common case), the transpose is correct. If the game is already row-major, remove the transpose in `ffp_state::apply_transforms()`.
-- **Everything is white/black**: The game's albedo texture might be on stage 1+ instead of stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini` `[FFP]`, or trace `SetTexture` calls to find the pattern.
-- **Some objects render, others don't**: `on_draw_primitive()` routes by vertex declaration -- world-space draws (have decl, no POSITIONT, not skinned) engage FFP; screen-space/no-decl pass through. `on_draw_indexed_prim()` additionally filters out draws without NORMAL as likely HUD/UI. If world geometry is missing, check whether its vertex decl has NORMAL and whether `view_proj_valid()` is true when those draws happen.
-- **Skinned meshes are invisible**: Enable skinning with `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Check the diagnostic log for bone count and declaration issues.
-- **Game crashes on startup**: The chain-loaded Remix DLL might not be present. Set `Enabled=0` in `remix-comp-proxy.ini` `[Remix]` section to test without Remix first.
-- **Geometry at origin / piled up**: World matrix register mapping is wrong. Every object gets identity world transform. Re-examine VS constant writes.
-- **Characters' world geometry shifts after a skinned draw**: After uploading bone matrices, WORLDMATRIX(0) is clobbered by bone[0]. The proxy tracks world dirty state so `apply_transforms()` re-applies the world matrix on the next rigid draw. If this still causes issues, the bone threshold register may overlap with the world matrix register range.
+**Common per-game changes:**
+- World geometry omits NORMAL -> remove or change `!ffp.cur_decl_has_normal()` filter
+- Special passes (shadow, reflection) -> filter by shader pointer, render target, or vertex count
+- UI drawn with DrawIndexedPrimitive + NORMAL -> add a filter (e.g. check stride or texture)
 
-## Using the RE Tools
+### DrawPrimitive Decision Tree
+
+```
+ffp.is_enabled() AND ffp.view_proj_valid() AND ffp.last_decl()
+AND !ffp.cur_decl_has_pos_t() AND !ffp.cur_decl_is_skinned()?
++-- YES -> ffp.engage() (world-space particles / non-indexed geometry)
++-- NO  -> passthrough (screen-space UI, POSITIONT, no decl, skinned)
+```
 
-All the Vibe RE tools described in the workspace instructions (retools, livetools) are available. Key workflows for FFP porting:
+---
 
-- `retools.decompiler` with `--types kb.h` for decompiling rendering functions
-- `livetools trace` on `SetVertexShaderConstantF` to see register + data patterns
-- `livetools trace` on `DrawIndexedPrimitive` to see call frequency and arguments
-- `livetools steptrace` on a rendering function to understand control flow
-- `retools.search strings --xrefs` to find error messages or shader-related strings
-- `retools.xrefs` / `retools.callgraph --up` to find who calls rendering functions
+## Common Pitfalls
 
-## Notes
-- Do not change the time frame of the logging (unless specified by the user). The delay is important to ensure the user is able to get into the game with actual geometry being drawn before the logs start, otherwise they may get lost in the initial burst of draw calls during loading.
-- Tell the user when you want to launch a game and have them interact with it for logging or hooking purposes. They MUST interact with the game to have this task be useful.
+- **Concatenated WVP/VP instead of separate matrices**: This is the **#1 Remix porting mistake**. Remix requires separate World, View, and Projection matrices passed via `SetTransform`. If the game uploads a pre-multiplied WorldViewProj or ViewProj to a single register range, the proxy gets a combined matrix it can't decompose. **Fix**: find where the game multiplies W*V*P (or V*P) and hook that function to capture the individual matrices *before* concatenation. Use `find_matrix_registers.py` to detect this -- if CTAB shows "WorldViewProj" or only one matrix register is uploaded per draw, you have this problem.
+- **Matrices look wrong**: D3D9 FFP `SetTransform` expects row-major. `ffp_state::apply_transforms` transposes column-major VS constants. If the game stores matrices row-major in VS constants (uncommon), remove the transpose in `ffp_state::apply_transforms`.
+- **Everything is white/black**: Albedo texture is on stage 1+, not stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini`, or trace `SetTexture` calls to find the correct stage.
+- **Some objects render, others don't**: Check whether missing geometry has NORMAL in its vertex decl. Check `ffp.view_proj_valid()` is true at draw time. DrawPrimitive routes on decl presence + no POSITIONT + not skinned.
+- **Skinned meshes invisible**: Set `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Check log for skinning errors. Verify `bone_start_reg` and `num_bones` are non-zero in the log.
+- **Game crashes on startup**: Set `[Remix] Enabled=0` in `remix-comp-proxy.ini` to test without Remix. Check `WINDOW_CLASS_NAME` in `comp/main.cpp`.
+- **Geometry at origin / piled up**: World matrix register mapping wrong. Re-examine VS constant writes via `livetools trace` or DX9 tracer `--const-provenance`.
+- **World geometry shifts after skinned draws**: `WORLDMATRIX(0)` clobbered by bone[0]. The proxy tracks `world_dirty_` for re-application. If still broken, check for bone register overlap with world matrix range in `ffp_state.hpp`.
+- **ImGui overlay not appearing**: Press F4. Check that `WINDOW_CLASS_NAME` is correct and the window was found (console output). Check for DirectInput hook conflicts.
diff --git a/.github/skills/dx9-ffp-port/references/remix-comp-context.md b/.github/skills/dx9-ffp-port/references/remix-comp-context.md
new file mode 100644
index 00000000..63be154a
--- /dev/null
+++ b/.github/skills/dx9-ffp-port/references/remix-comp-context.md
@@ -0,0 +1,58 @@
+# remix-comp-proxy: Context Guide
+
+**`rtx_remix_tools/dx/remix-comp-proxy/` is the READ-ONLY TEMPLATE.** Never modify it unless explicitly asked. Per-game work goes in `patches/<GameName>/`.
+
+Each game folder under `patches/<Game>/` is a self-contained remix-comp-proxy project. All paths below are relative to the game folder root (e.g. `patches/FNV/`) or to the framework template at `rtx_remix_tools/dx/remix-comp-proxy/`.
+
+## Do Not Read
+
+These are infrastructure files. Use the summaries below instead of opening them.
+
+### Auto-generated
+- `src/comp/modules/tracer_dispatch.inc` — 119 inline `trace_XXX()` functions generated by `graphics/directx/dx9/tracer/d3d9_methods.py`. Each wraps `tracer::record_begin/arg/end`.
+
+### D3D9 passthrough proxy
+- `src/comp/modules/drawcall_mod_context.cpp` — `drawcall_mod_context` save/restore method implementations. Never needs to be read; the API is in `renderer.hpp`.
+- `src/comp/modules/d3d9ex.cpp` — `IDirect3DDevice9` wrapper + exported `Direct3DCreate9`/`Direct3DCreate9Ex`. ~80 of 119 methods are trivial 1-line forwards. The ~12 methods with logic dispatch to renderer/ffp_state/imgui/tracer modules.
+- `src/comp/modules/d3d9ex.hpp` — D3D9Device, _d3d9, and _d3d9ex wrapper class declarations.
+- `src/comp/d3d9_proxy.cpp` + `d3d9_proxy.hpp` — d3d9.dll proxy: loads real d3d9 chain (Remix bridge or system), DLL pre/post-load chains, forwarded D3DPERF/debug exports.
+
+### Shared library (framework, never edited per-game)
+- `src/shared/utils/hooking.cpp/hpp` — MinHook wrapper + vtable patching.
+- `src/shared/utils/vector.hpp` — SIMD float2/float3/float4 math.
+- `src/shared/common/remix_api.cpp/hpp` — RTX Remix runtime bridge (load d3d9_remix.dll, init API, submit lights).
+- `src/shared/common/console.hpp` — Debug console allocation/output.
+- `src/shared/common/imgui_helper.cpp/hpp` — ImGui setup/teardown utilities.
+- `src/shared/utils/memory.cpp/hpp` — Pattern scanning and memory allocation.
+- `src/shared/utils/utils.cpp/hpp` — String/path/module utilities.
+- `src/shared/common/dinput_hook_v1.cpp/hpp` — DirectInput8 hook (input capture).
+- `src/shared/common/dinput_hook_v2.cpp/hpp` — Alternate DirectInput hook.
+- `src/shared/common/loader.cpp/hpp` — Module loader/registry.
+- `src/shared/common/flags.cpp/hpp` — Command-line flag parsing.
+- `src/shared/common/shader_cache.hpp` — Shader handle cache.
+- `src/shared/globals.cpp/hpp` — Global state (device pointer, module handle).
+- `src/shared/structs.hpp`, `src/shared/std_include.*`, `src/comp/std_include.*` — Precompiled headers, forward declarations.
+
+## Read These Instead
+
+The files that matter for per-game FFP porting work:
+
+| File | Role |
+|------|------|
+| `src/comp/modules/renderer.cpp` | **Draw call routing — THE main edit target** |
+| `src/comp/modules/renderer.hpp` | `drawcall_mod_context` API + `renderer` class declaration |
+| `src/shared/common/ffp_state.cpp` | FFP state tracker: engage/disengage, transforms, textures |
+| `src/shared/common/ffp_state.hpp` | ffp_state class with all accessors |
+| `src/shared/common/config.cpp` | INI config loader |
+| `src/shared/common/config.hpp` | Config structures |
+| `src/comp/main.cpp` | DLL entry, WINDOW_CLASS_NAME, module init |
+| `src/comp/comp.cpp` | Module registration order |
+| `src/comp/game/game.cpp` | Per-game address patterns and hooks |
+| `src/comp/game/game.hpp` | Per-game variables and typedefs |
+| `src/comp/game/structs.hpp` | Per-game data structures |
+
+### Read only when relevant
+- `src/comp/modules/diagnostics.cpp/hpp` — Frame logger to `rtx_comp/diagnostics.log`. Read when debugging log output.
+- `src/comp/modules/skinning.cpp/hpp` — Skinned mesh FFP conversion. Read only if user asks about skinning.
+- `src/comp/modules/imgui.cpp/hpp` — Debug overlay (F4). Read only if debugging ImGui.
+- `src/comp/modules/tracer.cpp/hpp` — JSONL D3D9 call recorder. Read only if working on tracer features.
diff --git a/.github/skills/dynamic-analysis/SKILL.md b/.github/skills/dynamic-analysis/SKILL.md
index b7dd169e..203ecd3c 100644
--- a/.github/skills/dynamic-analysis/SKILL.md
+++ b/.github/skills/dynamic-analysis/SKILL.md
@@ -1,12 +1,12 @@
 ---
 name: 'dynamic-analysis'
-description: 'Frida-based live process analysis toolkit. Use when attaching to a running process, tracing functions, collecting execution data, inspecting registers/memory/stack, stepping through code, patching live memory, or analyzing JSONL trace dumps.'
+description: 'Frida-based live process analysis. Use when attaching to or spawning a process, setting breakpoints, tracing functions, collecting execution data, inspecting registers/memory/stack at runtime, stepping through code, patching live memory, catching who writes to an address, counting D3D9 draw calls, sending keystrokes to a game window, or analyzing JSONL trace dumps.'
 user-invocable: true
 ---
 
 # Dynamic Analysis with livetools
 
-For DX9 FFP proxy porting and RTX Remix compatibility, see also: @dx9-ffp-port
+For DX9 FFP proxy porting and RTX Remix compatibility, invoke the `dx9-ffp-port` skill.
 
 A live analysis toolkit for running processes. Attach, trace functions, collect data, inspect state, step through code, patch memory, analyze offline -- composable tools that chain naturally for any RE scenario.
 
@@ -16,9 +16,10 @@ All commands: `python -m livetools <command> [args]`
 
 ### Session
 ```
-python -m livetools attach <name_or_pid>     # start daemon, attach Frida
-python -m livetools detach                    # release target, stop daemon
-python -m livetools status                    # check state
+python -m livetools attach <name_or_pid>             # attach to running process
+python -m livetools attach <exe_path> --spawn        # launch + instrument before init code runs
+python -m livetools detach                            # release target, stop daemon
+python -m livetools status                            # check state
 ```
 
 ### Breakpoints (blocking)
@@ -54,10 +55,35 @@ python -m livetools resume                    # unfreeze target
 ### Patch + Scan (anytime)
 ```
 python -m livetools mem write <addr> <hex>    # write bytes to live memory
+python -m livetools mem alloc <size>          # allocate rwx memory in target (for code caves)
 python -m livetools scan <pattern> --range START:SIZE
 ```
 
-### Non-blocking Tracing (NEW)
+### Memory Write Watchpoint
+```
+python -m livetools memwatch start <addr> [--size N] [--max-hits N]   # catch who writes (IP + backtrace per hit)
+python -m livetools memwatch read             # show captured hits
+python -m livetools memwatch stop
+```
+
+### D3D9 Draw Counter
+```
+python -m livetools dipcnt on <dev_ptr>       # hook DrawIndexedPrimitive via global IDirect3DDevice9* address
+python -m livetools dipcnt read               # current count + delta since last read
+python -m livetools dipcnt callers [N]        # sample N DIP calls, histogram return addresses (default 200)
+python -m livetools dipcnt off
+```
+
+### Game Window Input (no Frida, no focus steal)
+```
+python -m livetools gamectl --exe <game.exe> info
+python -m livetools gamectl --exe <game.exe> key RETURN
+python -m livetools gamectl --exe <game.exe> keys "DOWN DOWN RETURN WAIT:1000 RETURN"
+python -m livetools gamectl --exe <game.exe> click <x> <y>
+python -m livetools gamectl --exe <game.exe> macro <name> --macro-file patches/<game>/macros.json
+```
+
+### Non-blocking Tracing
 ```
 python -m livetools trace <addr> [--count N] [--read SPEC] [--read-leave SPEC] [--filter EXPR] [--timeout T] [--output FILE]
 python -m livetools steptrace <addr> [--max-insn N] [--call-depth D] [--detail LEVEL] [--timeout T] [--output FILE]
@@ -183,11 +209,59 @@ Output: JSONL in `patches/<exe_name>/traces/` by default (gitignored).
 ```bash
 python -m livetools modules
 python -m livetools modules --filter kernel
-python -m livetools modules --filter kernel
 ```
 
 Returns name, base address, size, and full path for every loaded module. Essential for finding DLL bases for vtable hooks.
 
+### memwatch -- Hardware memory write watchpoint
+
+Uses Frida's MemoryAccessMonitor to catch writes to an address range, capturing the writing instruction pointer and a backtrace per hit. The runtime complement to static `datarefs.py` — catches writes through pointers computed at runtime.
+
+```bash
+python -m livetools memwatch start 0x7A0000 --size 48 --max-hits 20
+python -m livetools memwatch read
+python -m livetools memwatch stop
+```
+
+One active watchpoint at a time. Auto-stops after `--max-hits` (default 20).
+
+### dipcnt -- D3D9 DrawIndexedPrimitive counter
+
+Hooks DIP through the device vtable, given the address of the game's global `IDirect3DDevice9*` pointer. Use to measure draw call volume or find render-loop callers without a full trace.
+
+```bash
+python -m livetools dipcnt on 0x7C5548     # address of the global device pointer
+python -m livetools dipcnt read            # count + delta since last read
+python -m livetools dipcnt callers 200     # sample 200 calls, histogram return addresses
+python -m livetools dipcnt off
+```
+
+`callers` is the fast way to locate the main render loop: the dominant return address is the draw dispatcher.
+
+### gamectl -- Send input to the game window
+
+Posts WM_KEYDOWN/WM_KEYUP/clicks directly to the target window handle — no Frida, no focus stealing, works with the game in the background. Use to navigate menus or trigger in-game actions during long traces.
+
+```bash
+python -m livetools gamectl --exe game.exe info                      # show hwnd, title, pid
+python -m livetools gamectl --exe game.exe key RETURN [--hold-ms 50]
+python -m livetools gamectl --exe game.exe keys "DOWN DOWN RETURN WAIT:1000 RETURN" [--delay-ms 200]
+python -m livetools gamectl --exe game.exe click 400 300             # client-area coordinates
+python -m livetools gamectl --exe game.exe macro navigate_menu --macro-file patches/<game>/macros.json
+```
+
+Key names: `RETURN`, `ESCAPE`, `SPACE`, arrows, `TAB`, `F1`-`F12`, `A`-`Z`, `0`-`9`, `NUMPAD0`-`9`, `SHIFT`, `CTRL`, `ALT`. Sequence tokens: `WAIT:N` (pause N ms), `HOLD:KEY:N` (hold key N ms). Window lookup: `--exe` (preferred) or `--window <title substring>`.
+
+### vishook -- Selective visibility override via code cave
+
+Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`.
+
+```bash
+python -m livetools vishook on <jmp_site> <orig_target> [--threshold 500000]
+python -m livetools vishook stats     # override vs passthrough call counts
+python -m livetools vishook off       # restore original jmp
+```
+
 ### analyze -- Offline JSONL aggregation (no Frida needed)
 
 Pure Python. Reads JSONL from `collect` or `trace --output`. Deterministic, non-hallucinated aggregation.
diff --git a/.kiro/agents/static-analyzer.md b/.kiro/agents/static-analyzer.md
index 5919ae56..ab56370d 100644
--- a/.kiro/agents/static-analyzer.md
+++ b/.kiro/agents/static-analyzer.md
@@ -9,7 +9,7 @@ You are a reverse engineering analyst specializing in static analysis of PE bina
 
 ## Setup
 
-On first invocation, read the full tool catalog at `.claude/rules/tool-catalog.md` in the working directory. It contains exact syntax, flags, and caveats for every tool.
+On first invocation, read the full tool catalog at `.kiro/steering/tool-catalog.md` in the working directory. It contains exact syntax, flags, and caveats for every tool.
 
 ## Pre-flight Checks
 
diff --git a/.kiro/powers/dx9-ffp-port/POWER.md b/.kiro/powers/dx9-ffp-port/POWER.md
index 47674fe9..1dd635d2 100644
--- a/.kiro/powers/dx9-ffp-port/POWER.md
+++ b/.kiro/powers/dx9-ffp-port/POWER.md
@@ -1,53 +1,74 @@
 ---
 name: "dx9-ffp-port"
 displayName: "DX9 FFP Port"
-description: "DX9 shader-to-FFP proxy porting for RTX Remix compatibility. Covers the full workflow: static analysis, VS constant register discovery, dynamic live tracing, proxy build/deploy, and iteration. Includes draw call routing logic, common pitfalls, and skinning guidance."
+description: "Use when porting a game for RTX Remix or to the fixed-function pipeline, working on renderer.cpp / ffp_state / remix-comp-proxy.ini / draw routing / VS constants / vertex declarations / matrix mapping / skinning, building or deploying a remix-comp-proxy patch, or diagnosing rendering issues in a patched game."
 keywords: ["dx9", "directx", "ffp", "rtx-remix", "d3d9", "proxy", "shader", "fixed-function"]
 author: "workspace"
 ---
 
-# DX9 FFP Proxy — Game Porting
+# DX9 FFP Proxy -- Game Porting
 
 Port a DX9 shader-based game to fixed-function pipeline (FFP) for RTX Remix compatibility. Remix requires FFP geometry to inject path-traced lighting and replaceable assets.
 
-**SKINNING IS OFF BY DEFAULT.** Do NOT enable skinning, modify skinning code, or discuss skinning infrastructure unless the user explicitly asks for character model / bone / skeletal animation support. When requested, read `src/comp/modules/skinning.hpp` and `src/comp/modules/skinning.cpp` for the full implementation.
+**NEVER MODIFY TEMPLATE CODE.** The following directories are read-only templates:
+- `rtx_remix_tools/dx/remix-comp-proxy/` — remix-comp-proxy framework template
 
-**SKINNING APPROACH: FFP indexed vertex blending, NOT CPU matrix math.** When skinning is enabled, keep BLENDINDICES and BLENDWEIGHT in the vertex declaration and buffer, upload bone matrices via `SetTransform(D3DTS_WORLDMATRIX(n), &boneMatrix[n])`, enable `D3DRS_INDEXEDVERTEXBLENDENABLE = TRUE`, and set `D3DRS_VERTEXBLEND` to the weight count. CPU-side vertex skinning is a **last resort** -- it is extremely expensive and tanks frame rate. Always prefer the hardware path.
+To create a game patch, **copy** the template to `patches/<GameName>/` and edit the copy. If the user asks you to edit remix-comp-proxy code, always confirm whether they mean the template or a game-specific copy under `patches/`. Only modify the template if the user **explicitly** says to change the template itself.
+
+**SKINNING IS OFF BY DEFAULT.** Do NOT enable skinning in `remix-comp-proxy.ini`, modify skinning code, or discuss skinning infrastructure unless the user explicitly asks for character model / bone / skeletal animation support. When requested, read `src/comp/modules/skinning.hpp` and `src/comp/modules/skinning.cpp` for the full implementation.
+
+**SKINNING APPROACH: FFP indexed vertex blending, NOT CPU matrix math.** When skinning is enabled, the correct approach is:
+1. Keep BLENDINDICES and BLENDWEIGHT elements in the vertex declaration and vertex buffer
+2. Upload bone matrices via `SetTransform(D3DTS_WORLDMATRIX(n), &boneMatrix[n])` for each bone
+3. Enable `D3DRS_INDEXEDVERTEXBLENDENABLE = TRUE`
+4. Set `D3DRS_VERTEXBLEND` to the appropriate weight count (e.g. `D3DVBF_3WEIGHTS`)
+5. Let the FFP hardware pipeline do the blending
+
+CPU-side vertex skinning (manually multiplying vertices by bone matrices) is a **last resort only**. It is extremely expensive, tanks frame rate, and should only be considered when FFP indexed vertex blending is not feasible. Always prefer the hardware path above.
 
 ---
 
 ## What remix-comp-proxy Does
 
-Each game folder under `patches/<GameName>/` is a self-contained remix-comp-proxy project (copied from `rtx_remix_tools/dx/remix-comp-proxy/`). It is a C++20 compatibility mod that:
+Each game folder under `patches/<GameName>/` is a self-contained remix-comp-proxy project (copied from `rtx_remix_tools/dx/remix-comp-proxy/`). It is a d3d9.dll proxy that:
 
-1. Captures VS constants (View, Projection, World matrices) from `SetVertexShaderConstantF`
-2. Parses `SetVertexDeclaration` to detect BLENDWEIGHT+BLENDINDICES (skinned), POSITIONT (screen-space), NORMAL presence, and per-element byte offsets
-3. Routes `DrawIndexedPrimitive`:
+1. Captures VS constants (View, Projection, World matrices) from `SetVertexShaderConstantF` via `ffp_state::on_set_vs_const_f`
+2. Parses `SetVertexDeclaration` via `ffp_state::on_set_vertex_declaration` to detect BLENDWEIGHT+BLENDINDICES (skinned), POSITIONT (screen-space), NORMAL presence, and per-element byte offsets
+3. Routes `DrawIndexedPrimitive` via `renderer::on_draw_indexed_prim`:
    - No NORMAL -> HUD/UI pass-through
-   - Skinned + skinning module enabled -> FFP indexed vertex blending
+   - Skinned + skinning module enabled -> `skinning::draw_skinned_dip()`
    - Rigid 3D (has NORMAL) -> NULLs shaders, applies FFP transforms
-4. Routes `DrawPrimitive`: world-space (has decl, no POSITIONT, not skinned) -> FFP; otherwise pass-through
-5. Applies captured matrices via `SetTransform`
+4. Routes `DrawPrimitive` via `renderer::on_draw_primitive`: world-space (has decl, no POSITIONT, not skinned) -> FFP; otherwise pass-through
+5. Applies captured matrices via `ffp_state::apply_transforms` -> `SetTransform`
 6. Sets up texture stages and lighting for FFP rendering
-7. Chain-loads RTX Remix (`d3d9_remix.dll`)
+7. Loads the real d3d9 chain (RTX Remix `d3d9_remix.dll` or system d3d9) via d3d9_proxy
 
-## Source File Map
+## Codebase File Map
 
 | File | Role |
 |------|------|
-| `src/comp/main.cpp` | DLL entry, module loading, initialization |
-| `src/comp/modules/renderer.cpp` | Draw call routing -- `on_draw_indexed_prim()` and `on_draw_primitive()` |
-| `src/comp/modules/d3d9ex.cpp` | `IDirect3DDevice9` hook layer -- intercepts all 119 methods |
-| `src/comp/modules/skinning.cpp` | Skinning module (vertex expansion, bone upload, FFP blending) |
-| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `ffp_proxy.log` |
-| `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4 toggle) |
-| `src/shared/common/ffp_state.cpp` | FFP state tracker -- engage/disengage, matrix transforms, texture stages |
-| `src/shared/common/ffp_state.hpp` | `ffp_state` class with all state accessors |
-| `src/shared/common/config.hpp` | Config structures: `ffp_settings`, `skinning_settings`, etc. |
-| `remix-comp-proxy.ini` (in `assets/`) | Runtime config: `[FFP]`, `[Skinning]`, `[Diagnostics]`, `[Remix]`, `[Chain]` |
-| `build.bat` | Build script: outputs d3d9.dll proxy |
-
-Per-game setup: copy the entire `rtx_remix_tools/dx/remix-comp-proxy/` folder to `patches/<GameName>/`, then edit `src/comp/` directly.
+| `src/comp/modules/renderer.cpp` | Draw routing -- `on_draw_indexed_prim()` and `on_draw_primitive()` |
+| `src/comp/modules/renderer.hpp` | `drawcall_mod_context` for save/restore state around draws |
+| `src/shared/common/ffp_state.cpp` | Core FFP state tracker -- engage/disengage, transforms, texture stages |
+| `src/shared/common/ffp_state.hpp` | FFP state class with all accessors |
+| `src/shared/common/config.hpp` | Config structure parsed from `remix-comp-proxy.ini` |
+| `src/comp/main.cpp` | DLL entry, d3d9 proxy init, window finder, config loading |
+| `src/comp/comp.cpp` | Module init: registers renderer, diagnostics, skinning, imgui |
+| `src/comp/d3d9_proxy.cpp` | Loads real d3d9 chain, DLL pre/post-load, forwarded exports |
+| `src/comp/modules/d3d9ex.cpp` | `IDirect3DDevice9` / `IDirect3D9` wrapper + exported Direct3DCreate9 |
+| `src/comp/modules/d3d9ex.hpp` | D3D9 wrapper class declarations |
+| `src/comp/modules/diagnostics.cpp` | 50-sec delay, 3-frame diagnostic log to `rtx_comp/diagnostics.log` |
+| `src/comp/modules/skinning.cpp` | Optional skinning module (vertex expansion + bone upload) |
+| `src/comp/modules/skinning.hpp` | Skinning class declaration |
+| `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4) with FFP tab |
+| `src/comp/game/game.cpp` | Per-game address init (patterns, hooks) |
+| `src/comp/game/game.hpp` | Per-game variables and function typedefs |
+| `remix-comp-proxy.ini` (in `assets/`) | Runtime config: albedo stage, skinning toggle, diagnostics, DLL chain |
+| `build.bat` | Build script: outputs d3d9.dll proxy. `build.bat [release\|debug] [--name Name]` |
+
+**`rtx_remix_tools/dx/remix-comp-proxy/` is the TEMPLATE.** Each game gets a full copy under `patches/<GameName>/` — the entire folder is self-contained and can be distributed as a standalone repo. Edit `src/comp/` directly in the game's copy.
+
+**Before reading remix-comp-proxy source files**, read [references/remix-comp-context.md](references/remix-comp-context.md) for a skip-list of boilerplate files (~7,000 lines) you should never open, with summaries of what they do. It also lists the ~1,200 lines of files that actually matter for per-game work.
 
 ---
 
@@ -55,18 +76,34 @@ Per-game setup: copy the entire `rtx_remix_tools/dx/remix-comp-proxy/` folder to
 
 ### Step 1: Static Analysis
 
-Run ALL of the analysis scripts on the game binary. These are purpose-built for FFP porting -- they surface D3D9-specific patterns (VS constant call sites, vertex declarations, device vtable usage) that would take many individual retools commands to find manually:
+Run the analysis scripts to understand the game's D3D9 usage:
 
 ```bash
+# Core discovery
 python rtx_remix_tools/dx/scripts/find_d3d_calls.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_device_calls.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/classify_draws.py "<game.exe>"
+
+# Shader constants and vertex formats
 python rtx_remix_tools/dx/scripts/find_vs_constants.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_ps_constants.py "<game.exe>"
 python rtx_remix_tools/dx/scripts/decode_vtx_decls.py "<game.exe>" --scan
-python rtx_remix_tools/dx/scripts/find_device_calls.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/decode_fvf.py "<game.exe>"
+
+# Skinning analysis (bone palettes, blend weights, suggested INI)
 python rtx_remix_tools/dx/scripts/find_skinning.py "<game.exe>"
 python rtx_remix_tools/dx/scripts/find_blend_states.py "<game.exe>"
+
+# Render state and texture pipeline
+python rtx_remix_tools/dx/scripts/find_render_states.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_texture_ops.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_transforms.py "<game.exe>"
+python rtx_remix_tools/dx/scripts/find_surface_formats.py "<game.exe>"
 ```
 
-Use the script output to guide deeper analysis with `retools` (decompile specific call sites) and `livetools` (trace live values).
+Scripts are fast first-pass scanners -- surface candidate addresses only. Always follow up with `retools` and `livetools` for deep analysis.
+
+**Alternative: DX9 Tracer capture.** Deploy the tracer proxy (`graphics/directx/dx9/tracer/`) to capture a full frame, then analyze with `--matrix-flow`, `--vtx-formats`, `--shader-map`, and `--const-provenance` to discover the register layout without reverse engineering the binary.
 
 Key things to find:
 - How the game obtains its D3D device (Direct3DCreate9 -> CreateDevice)
@@ -74,29 +111,17 @@ Key things to find:
 - What vertex declaration formats are used (BLENDWEIGHT/BLENDINDICES = skinning)
 - Where the main render loop / draw calls live
 
-### Step 1b: Capture with the DX9 Tracer (Before Live Analysis)
+### Step 2: Discover VS Constant Register Layout
+
+This is the **most critical** step. Determine which VS constant registers hold View, Projection, and World matrices.
 
-Before jumping to livetools for manual tracing, deploy the D3D9 frame tracer -- it answers most FFP questions from a single capture.
+**Remix REQUIRES separate World, View, and Projection matrices.** A concatenated WorldViewProj (WVP) or ViewProj (VP) matrix will NOT work -- Remix needs individual matrices to apply its own camera and per-object transforms. If the game uploads a pre-multiplied WVP, the proxy must intercept the individual W, V, P matrices *before* the game concatenates them. This is the #1 source of broken Remix ports.
 
-1. Deploy `graphics/directx/dx9/tracer/bin/d3d9.dll` + `proxy.ini` to the game directory
-2. Launch the game, get to gameplay with visible geometry
-3. Trigger: `python -m graphics.directx.dx9.tracer trigger --game-dir <GAME_DIR>`
-4. Analyze:
+**Start with the matrix register finder:**
 ```bash
-python -m graphics.directx.dx9.tracer analyze <JSONL> --shader-map          # CTAB register names
-python -m graphics.directx.dx9.tracer analyze <JSONL> --const-provenance    # which code set each constant
-python -m graphics.directx.dx9.tracer analyze <JSONL> --vtx-formats         # vertex declarations
-python -m graphics.directx.dx9.tracer analyze <JSONL> --render-passes       # render target grouping
-python -m graphics.directx.dx9.tracer analyze <JSONL> --pipeline-diagram    # mermaid pipeline flowchart
+python rtx_remix_tools/dx/scripts/find_matrix_registers.py "<game.exe>"
 ```
-
-`--shader-map` includes CTAB headers with named parameters (e.g. `WorldViewProj c0 4`). This often answers "which registers hold which matrices" directly without manual RE.
-
-If the tracer gives you the register layout, skip the dynamic approach in Step 2 and go straight to Step 3. Use livetools only to fill gaps the tracer didn't cover. If the game crashes with the tracer proxy, fall back to Step 2's dynamic approach.
-
-### Step 2: Discover VS Constant Register Layout
-
-This is the **most critical** step. Determine which VS constant registers hold View, Projection, and World matrices.
+This cross-references SVSCF call patterns, shader CTAB names, and frequency analysis to suggest a register layout. Always verify its output with runtime data.
 
 **Static approach:** Decompile call sites:
 ```bash
@@ -110,195 +135,180 @@ python -m livetools trace <call_addr> --count 50 \
 ```
 Captures: startRegister, Vector4fCount, and the first 4 vec4 constants of actual float data.
 
+**DX9 Tracer approach:** Capture a frame and analyze:
+```bash
+python -m graphics.directx.dx9.tracer analyze <JSONL> --const-provenance
+python -m graphics.directx.dx9.tracer analyze <JSONL> --matrix-flow
+python -m graphics.directx.dx9.tracer analyze <JSONL> --shader-map
+```
+
 **How to identify matrices:**
 - View matrix: changes with camera movement; contains camera orientation
 - Projection matrix: contains aspect ratio and FOV; rarely changes
 - World matrix: changes per object; contains position/rotation/scale
 - Look for 4x4 matrices (16 floats = 4 registers). Row 3 often has `[0, 0, 0, 1]` for affine transforms.
+- **Watch for concatenated matrices:** If the game only uploads one matrix per draw (e.g. WVP at c0-c3), the individual W/V/P are being multiplied before upload. Trace back to find where the multiplication happens -- you need to capture W, V, P separately before that point.
 
-### Step 3: Copy comp/ and Configure
+### Step 3: Set Up Per-Game Project
 
-Copy the entire `rtx_remix_tools/dx/remix-comp/` folder to `patches/<GameName>/` (excluding `build/`). Edit files directly:
+**IMPORTANT:** `rtx_remix_tools/dx/remix-comp-proxy/` is the **template**. NEVER edit it directly. Each game gets a full copy of the framework.
 
-1. Edit register layout defaults in `src/shared/common/ffp_state.hpp`
-2. Edit `src/comp/main.cpp`: set `WINDOW_CLASS_NAME`
-3. Customize `src/comp/modules/renderer.cpp` and `src/comp/game/game.cpp`
-4. Update `kb.h` with discovered function signatures, structs, and globals
+1. Copy the entire `rtx_remix_tools/dx/remix-comp-proxy/` folder to `patches/<GameName>/` (excluding `build/`)
+2. Edit `src/comp/` directly in the game's copy — this is the per-game customization layer
+3. Edit register layout defaults in `src/shared/common/ffp_state.hpp` (see Register Layout section below)
+4. Edit `src/comp/main.cpp`: set `WINDOW_CLASS_NAME` to the game's window class
+5. Customize `src/comp/modules/renderer.cpp` draw routing if needed (see Decision Trees below)
+6. Customize `src/comp/game/game.cpp` with game-specific address init if hooks are needed
+7. Update `kb.h` with discovered function signatures, structs, and globals
+
+The game folder is now fully self-contained and can be distributed as a standalone git repo.
 
 ### Step 4: Build and Deploy
 
+From the game folder:
 ```bash
 cd patches/<GameName>
 build.bat release --name <GameName>
 ```
 
-Deploy to game directory: `d3d9.dll` + `remix-comp-proxy.ini`. Place `d3d9_remix.dll` there if using Remix.
+The build produces `d3d9.dll` in `patches/<GameName>/build/bin/release/`. Deploy:
+- `d3d9.dll` to the game directory (the game loads this as its d3d9 proxy)
+- `remix-comp-proxy.ini` to the game directory
+- `d3d9_remix.dll` to the game directory if using Remix
 
 ### Step 5: Diagnose with Log and ImGui
 
-The proxy writes `ffp_proxy.log` in the game directory after a configurable delay (default 50 seconds via `[Diagnostics] DelayMs`), then logs frames of detailed draw call data:
+**rtx_comp/diagnostics.log:** Written to the `rtx_comp/` subfolder of the game directory after a configurable delay (default 50 seconds), then logs 3 frames of detailed draw call data:
 
 - **VS regs written**: which constant registers the game actually fills
 - **Vertex declarations**: what vertex elements each draw uses
 - **Draw calls**: primitive type, vertex count, index count, textures per stage
 - **Matrices**: actual View/Proj/World values being applied
-
-Press **F4** to open the ImGui debug overlay with live draw call stats and FFP conversion info.
+- **Raw vertex bytes**: hex dump of first vertices for early draw calls
 
 Do not change the logging delay unless the user asks -- it ensures the user gets into the game with real geometry before logging begins.
 
+**ImGui overlay (F4):** Press F4 to toggle the debug overlay. The FFP tab shows real-time draw call stats, VS constant register write history, and enables a fake camera for testing transforms.
+
 **Tell the user when you need them to interact with the game** for logging or hooking purposes. They must be in-game with geometry visible for the log to be useful.
 
 ---
 
-## Game-Specific Configuration
+## Register Layout (`ffp_state.hpp`)
 
-The VS constant register layout is defined in `src/shared/common/ffp_state.hpp` as member defaults. Edit these when porting, then rebuild:
+The VS constant register layout is defined as member defaults in `src/shared/common/ffp_state.hpp`. Edit these when porting a new game:
 
 ```cpp
-int vs_reg_view_start_ = 0;    int vs_reg_view_end_ = 4;
-int vs_reg_proj_start_ = 4;    int vs_reg_proj_end_ = 8;
-int vs_reg_world_start_ = 16;  int vs_reg_world_end_ = 20;
-int vs_reg_bone_threshold_ = 20;   // first register treated as bone palette
-int vs_regs_per_bone_ = 3;        // 3 = 4x3 packed, 4 = full 4x4
-int vs_bone_min_regs_ = 3;        // min count to qualify as bone upload
+// In ffp_state.hpp — private members with game-specific defaults
+int vs_reg_view_start_ = 0;
+int vs_reg_view_end_ = 4;
+int vs_reg_proj_start_ = 4;
+int vs_reg_proj_end_ = 8;
+int vs_reg_world_start_ = 16;
+int vs_reg_world_end_ = 20;
+int vs_reg_bone_threshold_ = 20;  // only matters when [Skinning] Enabled=1
+int vs_regs_per_bone_ = 3;        // 3 = 4x3 packed bones (most common), 4 = full 4x4
+int vs_bone_min_regs_ = 3;        // minimum register count to qualify as bone upload
 ```
 
-**Bone config:** Run `find_skinning.py` to determine bone start register and upload pattern. Some games upload all bones at once; others upload in groups until hitting a max (e.g., groups of 15, max 75). If grouped, lower `vs_bone_min_regs_`. If bone uploads overlap with non-bone constants, raise `vs_reg_bone_threshold_`.
+Each matrix occupies 4 consecutive vec4 registers (= 16 floats). After changing defaults, rebuild with `build.bat`.
 
-Other game-specific INI settings:
-- `[FFP] AlbedoStage=0` -- which texture stage holds the diffuse/albedo
-- `[Skinning] Enabled=0` -- only set to 1 after rigid FFP works
-- `[Remix] Enabled=1` -- set to 0 to test without Remix
+### Bone Configuration for Skinning
 
----
+Before enabling skinning, run `find_skinning.py` to determine the bone start register (`vs_reg_bone_threshold_`) and upload pattern. Some games upload all bones in one call; others upload in groups until hitting a max (e.g., groups of 15, max 75). If the game uses grouped uploads, lower `vs_bone_min_regs_` so the proxy doesn't reject the smaller batches. If bone uploads overlap with non-bone constants, raise `vs_reg_bone_threshold_`.
 
-## Architecture: What to Edit vs What to Leave Alone
+## INI Config (`remix-comp-proxy.ini`)
 
-| File / Section | Edit Per-Game? |
-|----------------|----------------|
-| `ffp_state.hpp` register layout defaults | **YES** |
-| `remix-comp-proxy.ini` `[FFP] AlbedoStage` | **YES** |
-| `remix-comp-proxy.ini` `[Skinning] Enabled` | **YES** (after rigid works) |
-| `renderer.cpp` `on_draw_indexed_prim()` | **YES** -- main draw routing |
-| `renderer.cpp` `on_draw_primitive()` | **YES** -- draw routing |
-| `ffp_state.cpp` `setup_lighting()`, `setup_texture_stages()`, `apply_transforms()` | MAYBE |
-| `ffp_state.cpp` `on_set_vs_const_f()` | MAYBE -- dirty tracking |
-| `ffp_state.cpp` `on_set_vertex_declaration()` | MAYBE -- element parsing |
-| `d3d9ex.cpp` hooks | NO -- infrastructure |
-| `ffp_state.cpp` `engage()` / `disengage()` | NO |
-| `skinning.cpp` | NO -- infrastructure |
-| `diagnostics.cpp` | NO -- logging |
-| `imgui.cpp` | NO -- debug overlay |
+Runtime settings that don't require recompile:
 
-### DrawIndexedPrimitive Decision Tree
+```ini
+[FFP]
+Enabled=1
+AlbedoStage=0
+; Albedo texture stage (0-7). Set to whichever stage the game binds the diffuse texture.
 
-```
-viewProjValid?
-+-- NO  -> shader passthrough
-+-- YES
-    +-- curDeclIsSkinned?
-    |   +-- YES + skinning module -> skinning::draw_skinned_dip()
-    |   +-- YES + no skinning     -> shader passthrough
-    +-- NOT skinned
-        +-- !curDeclHasNormal -> shader passthrough (HUD/UI)
-        +-- hasNormal -> ffp_state::engage + rigid FFP draw
-```
+[Skinning]
+Enabled=0
+; Only set to 1 after rigid FFP works correctly.
+; Run find_skinning.py to determine bone register layout before enabling.
 
-**Common per-game changes:**
-- World geometry omits NORMAL -> remove or change `!cur_decl_has_normal()` filter
-- Special passes (shadow, reflection) -> filter by shader pointer, render target, or vertex count
-- UI drawn with DrawIndexedPrimitive + NORMAL -> add a filter (e.g. check stride or texture)
+[Diagnostics]
+Enabled=1
+DelayMs=50000
+LogFrames=3
 
-### DrawPrimitive Decision Tree
+[Remix]
+Enabled=1
+DLLName=d3d9_remix.dll
 
-```
-viewProjValid AND lastDecl AND !curDeclHasPosT AND !curDeclIsSkinned?
-+-- YES -> ffp_state::engage (world-space particles / non-indexed geometry)
-+-- NO  -> shader passthrough (screen-space UI, POSITIONT, no decl, skinned)
+[Chain]
+PreLoad=
+PostLoad=
+; Semicolon-separated DLLs/ASIs to load before/after the d3d9 chain.
+; Example: PreLoad=patch.dll;fix.asi
 ```
 
 ---
 
-## Analysis Scripts Reference
-
-| Script | What it surfaces |
-|--------|-----------------|
-| `python rtx_remix_tools/dx/scripts/find_d3d_calls.py <game.exe>` | D3D9/D3DX imports and call sites |
-| `python rtx_remix_tools/dx/scripts/find_vs_constants.py <game.exe>` | `SetVertexShaderConstantF` call sites and register/count args |
-| `python rtx_remix_tools/dx/scripts/find_device_calls.py <game.exe>` | Device vtable call patterns and device pointer refs |
-| `python rtx_remix_tools/dx/scripts/find_vtable_calls.py <game.exe>` | D3DX constant table usage and D3D9 vtable calls |
-| `python rtx_remix_tools/dx/scripts/decode_vtx_decls.py <game.exe> --scan` | Vertex declaration formats (BLENDWEIGHT/BLENDINDICES -> skinning) |
-| `python rtx_remix_tools/dx/scripts/find_skinning.py <game.exe>` | Consolidated skinning analysis: skinned decls, bone palettes, blend states, suggested INI |
-| `python rtx_remix_tools/dx/scripts/find_blend_states.py <game.exe>` | D3DRS_VERTEXBLEND + INDEXEDVERTEXBLENDENABLE + WORLDMATRIX transforms |
-| `python rtx_remix_tools/dx/scripts/scan_d3d_region.py <game.exe> 0xSTART 0xEND` | Map all D3D9 vtable calls in a code region |
-
----
+## Architecture: What to Edit vs What to Leave Alone
 
-## RE Tool Workflows for FFP Porting
+Each game folder under `patches/<GameName>/` is a **self-contained** copy of the full remix-comp-proxy framework. Edit files directly in the game's copy.
+
+| Component (in `patches/<GameName>/`) | Edit Per-Game? |
+|-----------|----------------|
+| `ffp_state.hpp` register layout defaults | **YES** — rebuild after changing |
+| `remix-comp-proxy.ini` albedo stage, diagnostics, chain | **YES** |
+| `src/comp/main.cpp` WINDOW_CLASS_NAME | **YES** |
+| `src/comp/modules/renderer.cpp` draw routing | **YES** -- main draw routing |
+| `src/comp/game/game.cpp` address init and hooks | **YES** -- per-game hooks |
+| `src/comp/game/structs.hpp` game structs | **YES** -- per-game data structures |
+| `src/shared/common/ffp_state.cpp` engage/disengage/transforms | MAYBE -- only for unusual FFP needs |
+| `src/shared/common/config.hpp` | MAYBE -- add new INI sections if needed |
+| `src/comp/modules/d3d9ex.cpp` | NO -- forwards all 119 methods |
+| `src/comp/modules/diagnostics.cpp` | NO -- generic frame logger |
+| `src/comp/modules/imgui.cpp` | NO -- debug overlay |
+| `src/shared/` everything else | NO -- framework code |
 
-### Find all SetVertexShaderConstantF call sites
-```bash
-python -m retools.xrefs <game.exe> <iat_addr> -t call
-```
+### DrawIndexedPrimitive Decision Tree
 
-### Decompile a VS constant setup function
-```bash
-python -m retools.decompiler <game.exe> <func_addr> --types patches/<project>/kb.h
 ```
-
-### Trace live VS constant writes
-```bash
-python -m livetools trace <SetVSConstF_call_addr> --count 50 \
-    --read "[esp+8]:4:uint32; [esp+10]:4:uint32; *[esp+c]:64:float32"
+ffp.is_enabled() AND ffp.view_proj_valid()?
++-- NO  -> passthrough with shaders
++-- YES
+    +-- ffp.cur_decl_is_skinned()?
+    |   +-- YES + skinning module -> skinning::draw_skinned_dip()
+    |   +-- YES + no skinning     -> passthrough with shaders
+    +-- !ffp.cur_decl_has_normal()?
+    |   +-- passthrough (HUD/UI)
+    |   GAME-SPECIFIC: remove this filter if world geometry lacks NORMAL
+    +-- else (rigid 3D mesh)
+        +-- ffp.engage() + draw + restore
 ```
 
-**The `<SetVSConstF_call_addr>` is the CALL instruction in the game's .exe** (from `find_vs_constants.py` or `xrefs.py`), NOT an address inside d3d9.dll. Hook the caller, not the callee.
-
-### Count draw calls and find callers
-```bash
-python -m livetools dipcnt on
-# wait in-game
-python -m livetools dipcnt read
-python -m livetools dipcnt callers 100
-```
+**Common per-game changes:**
+- World geometry omits NORMAL -> remove or change `!ffp.cur_decl_has_normal()` filter
+- Special passes (shadow, reflection) -> filter by shader pointer, render target, or vertex count
+- UI drawn with DrawIndexedPrimitive + NORMAL -> add a filter (e.g. check stride or texture)
 
-### Understand render path depth
-```bash
-python -m retools.callgraph <game.exe> <render_func_addr> --down 3
-```
+### DrawPrimitive Decision Tree
 
-### Understand a specific draw call path
-```bash
-python -m livetools steptrace <draw_func_addr> --max-insn 1000 --call-depth 1 --detail branches
 ```
-
-### Find vertex declaration setup
-```bash
-python -m retools.search <game.exe> strings -f "vertex,decl,shader" --xrefs
+ffp.is_enabled() AND ffp.view_proj_valid() AND ffp.last_decl()
+AND !ffp.cur_decl_has_pos_t() AND !ffp.cur_decl_is_skinned()?
++-- YES -> ffp.engage() (world-space particles / non-indexed geometry)
++-- NO  -> passthrough (screen-space UI, POSITIONT, no decl, skinned)
 ```
 
 ---
 
 ## Common Pitfalls
 
-- **Matrices look wrong**: D3D9 FFP `SetTransform` expects row-major. The proxy transposes. If the game stores matrices row-major in VS constants (uncommon), remove the transpose in `ffp_state::apply_transforms()`.
-- **Everything is white/black**: Albedo texture is on stage 1+, not stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini` `[FFP]` section, or trace `SetTexture` calls to find the correct stage.
-- **Some objects render, others don't**: Check whether missing geometry has NORMAL in its vertex decl. Check `view_proj_valid()` is true at draw time. `on_draw_primitive()` routes on decl presence + no POSITIONT + not skinned.
-- **Skinned meshes invisible**: Enable `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Verify bone count is non-zero in diagnostic log entries.
-- **Bones mixed up between NPCs**: Stale WORLDMATRIX slots from a previous object. If still broken, the game may need a game-specific reset hook.
-- **Game crashes on startup**: Set `Enabled=0` in `remix-comp-proxy.ini` `[Remix]` to test without Remix.
-- **Geometry at origin / piled up**: World matrix register mapping wrong. Re-examine VS constant writes via `livetools trace`.
-- **World geometry shifts after skinned draws**: `WORLDMATRIX(0)` clobbered by bone[0]. The proxy re-applies via world dirty tracking. If still broken, check for bone register overlap with world matrix range.
-
-### Skinning Stability: Finding Game-Specific Hook Points
-
-The proxy's generic heuristics handle most games. If bones still leak between objects, the game needs a hook at a per-object boundary function -- one that's called once per skinned object, before its bones are uploaded.
-
-**Finding the per-object function:**
-
-1. **Capture** 2+ frames with the D3D9 tracer while multiple skinned NPCs are on screen
-2. **Hotpaths**: `--hotpaths --resolve-addrs <game.exe>` -- look at callers of bone-range `SetVertexShaderConstantF` writes
-3. **Caller histogram**: `--callers SetVertexShaderConstantF` -- the function that appears N times per frame (N = number of skinned objects) is the per-object boundary
-4. **Live confirm**: `livetools trace <candidate_addr> --count 50` -- with 3 NPCs, expect ~3 hits/frame
-5. **Static context**: `callgraph.py --up` + `decompiler.py` on the caller -- confirm it loops over objects
+- **Concatenated WVP/VP instead of separate matrices**: This is the **#1 Remix porting mistake**. Remix requires separate World, View, and Projection matrices passed via `SetTransform`. If the game uploads a pre-multiplied WorldViewProj or ViewProj to a single register range, the proxy gets a combined matrix it can't decompose. **Fix**: find where the game multiplies W*V*P (or V*P) and hook that function to capture the individual matrices *before* concatenation. Use `find_matrix_registers.py` to detect this -- if CTAB shows "WorldViewProj" or only one matrix register is uploaded per draw, you have this problem.
+- **Matrices look wrong**: D3D9 FFP `SetTransform` expects row-major. `ffp_state::apply_transforms` transposes column-major VS constants. If the game stores matrices row-major in VS constants (uncommon), remove the transpose in `ffp_state::apply_transforms`.
+- **Everything is white/black**: Albedo texture is on stage 1+, not stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini`, or trace `SetTexture` calls to find the correct stage.
+- **Some objects render, others don't**: Check whether missing geometry has NORMAL in its vertex decl. Check `ffp.view_proj_valid()` is true at draw time. DrawPrimitive routes on decl presence + no POSITIONT + not skinned.
+- **Skinned meshes invisible**: Set `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Check log for skinning errors. Verify `bone_start_reg` and `num_bones` are non-zero in the log.
+- **Game crashes on startup**: Set `[Remix] Enabled=0` in `remix-comp-proxy.ini` to test without Remix. Check `WINDOW_CLASS_NAME` in `comp/main.cpp`.
+- **Geometry at origin / piled up**: World matrix register mapping wrong. Re-examine VS constant writes via `livetools trace` or DX9 tracer `--const-provenance`.
+- **World geometry shifts after skinned draws**: `WORLDMATRIX(0)` clobbered by bone[0]. The proxy tracks `world_dirty_` for re-application. If still broken, check for bone register overlap with world matrix range in `ffp_state.hpp`.
+- **ImGui overlay not appearing**: Press F4. Check that `WINDOW_CLASS_NAME` is correct and the window was found (console output). Check for DirectInput hook conflicts.
diff --git a/.kiro/powers/dx9-ffp-port/references/remix-comp-context.md b/.kiro/powers/dx9-ffp-port/references/remix-comp-context.md
new file mode 100644
index 00000000..63be154a
--- /dev/null
+++ b/.kiro/powers/dx9-ffp-port/references/remix-comp-context.md
@@ -0,0 +1,58 @@
+# remix-comp-proxy: Context Guide
+
+**`rtx_remix_tools/dx/remix-comp-proxy/` is the READ-ONLY TEMPLATE.** Never modify it unless explicitly asked. Per-game work goes in `patches/<GameName>/`.
+
+Each game folder under `patches/<Game>/` is a self-contained remix-comp-proxy project. All paths below are relative to the game folder root (e.g. `patches/FNV/`) or to the framework template at `rtx_remix_tools/dx/remix-comp-proxy/`.
+
+## Do Not Read
+
+These are infrastructure files. Use the summaries below instead of opening them.
+
+### Auto-generated
+- `src/comp/modules/tracer_dispatch.inc` — 119 inline `trace_XXX()` functions generated by `graphics/directx/dx9/tracer/d3d9_methods.py`. Each wraps `tracer::record_begin/arg/end`.
+
+### D3D9 passthrough proxy
+- `src/comp/modules/drawcall_mod_context.cpp` — `drawcall_mod_context` save/restore method implementations. Never needs to be read; the API is in `renderer.hpp`.
+- `src/comp/modules/d3d9ex.cpp` — `IDirect3DDevice9` wrapper + exported `Direct3DCreate9`/`Direct3DCreate9Ex`. ~80 of 119 methods are trivial 1-line forwards. The ~12 methods with logic dispatch to renderer/ffp_state/imgui/tracer modules.
+- `src/comp/modules/d3d9ex.hpp` — D3D9Device, _d3d9, and _d3d9ex wrapper class declarations.
+- `src/comp/d3d9_proxy.cpp` + `d3d9_proxy.hpp` — d3d9.dll proxy: loads real d3d9 chain (Remix bridge or system), DLL pre/post-load chains, forwarded D3DPERF/debug exports.
+
+### Shared library (framework, never edited per-game)
+- `src/shared/utils/hooking.cpp/hpp` — MinHook wrapper + vtable patching.
+- `src/shared/utils/vector.hpp` — SIMD float2/float3/float4 math.
+- `src/shared/common/remix_api.cpp/hpp` — RTX Remix runtime bridge (load d3d9_remix.dll, init API, submit lights).
+- `src/shared/common/console.hpp` — Debug console allocation/output.
+- `src/shared/common/imgui_helper.cpp/hpp` — ImGui setup/teardown utilities.
+- `src/shared/utils/memory.cpp/hpp` — Pattern scanning and memory allocation.
+- `src/shared/utils/utils.cpp/hpp` — String/path/module utilities.
+- `src/shared/common/dinput_hook_v1.cpp/hpp` — DirectInput8 hook (input capture).
+- `src/shared/common/dinput_hook_v2.cpp/hpp` — Alternate DirectInput hook.
+- `src/shared/common/loader.cpp/hpp` — Module loader/registry.
+- `src/shared/common/flags.cpp/hpp` — Command-line flag parsing.
+- `src/shared/common/shader_cache.hpp` — Shader handle cache.
+- `src/shared/globals.cpp/hpp` — Global state (device pointer, module handle).
+- `src/shared/structs.hpp`, `src/shared/std_include.*`, `src/comp/std_include.*` — Precompiled headers, forward declarations.
+
+## Read These Instead
+
+The files that matter for per-game FFP porting work:
+
+| File | Role |
+|------|------|
+| `src/comp/modules/renderer.cpp` | **Draw call routing — THE main edit target** |
+| `src/comp/modules/renderer.hpp` | `drawcall_mod_context` API + `renderer` class declaration |
+| `src/shared/common/ffp_state.cpp` | FFP state tracker: engage/disengage, transforms, textures |
+| `src/shared/common/ffp_state.hpp` | ffp_state class with all accessors |
+| `src/shared/common/config.cpp` | INI config loader |
+| `src/shared/common/config.hpp` | Config structures |
+| `src/comp/main.cpp` | DLL entry, WINDOW_CLASS_NAME, module init |
+| `src/comp/comp.cpp` | Module registration order |
+| `src/comp/game/game.cpp` | Per-game address patterns and hooks |
+| `src/comp/game/game.hpp` | Per-game variables and typedefs |
+| `src/comp/game/structs.hpp` | Per-game data structures |
+
+### Read only when relevant
+- `src/comp/modules/diagnostics.cpp/hpp` — Frame logger to `rtx_comp/diagnostics.log`. Read when debugging log output.
+- `src/comp/modules/skinning.cpp/hpp` — Skinned mesh FFP conversion. Read only if user asks about skinning.
+- `src/comp/modules/imgui.cpp/hpp` — Debug overlay (F4). Read only if debugging ImGui.
+- `src/comp/modules/tracer.cpp/hpp` — JSONL D3D9 call recorder. Read only if working on tracer features.
diff --git a/.kiro/powers/dynamic-analysis/POWER.md b/.kiro/powers/dynamic-analysis/POWER.md
index 2c9f1c9c..bff69103 100644
--- a/.kiro/powers/dynamic-analysis/POWER.md
+++ b/.kiro/powers/dynamic-analysis/POWER.md
@@ -1,14 +1,14 @@
 ---
 name: "dynamic-analysis"
 displayName: "Dynamic Analysis"
-description: "Frida-based live process analysis toolkit for reverse engineering. Use when attaching to a running process, tracing functions, collecting execution data, inspecting registers/memory/stack at runtime, stepping through code, patching live memory, or analyzing JSONL trace dumps."
+description: "Frida-based live process analysis. Use when attaching to or spawning a process, setting breakpoints, tracing functions, collecting execution data, inspecting registers/memory/stack at runtime, stepping through code, patching live memory, catching who writes to an address, counting D3D9 draw calls, sending keystrokes to a game window, or analyzing JSONL trace dumps."
 keywords: ["frida", "dynamic-analysis", "reverse-engineering", "tracing", "breakpoints", "memory", "livetools"]
 author: "workspace"
 ---
 
 # Dynamic Analysis with livetools
 
-For DX9 FFP proxy porting and RTX Remix compatibility, see also: @dx9-ffp-port
+For DX9 FFP proxy porting and RTX Remix compatibility, invoke the `dx9-ffp-port` skill.
 
 A live analysis toolkit for running processes. Attach, trace functions, collect data, inspect state, step through code, patch memory, analyze offline -- composable tools that chain naturally for any RE scenario.
 
@@ -57,10 +57,35 @@ python -m livetools resume                    # unfreeze target
 ### Patch + Scan (anytime)
 ```
 python -m livetools mem write <addr> <hex>    # write bytes to live memory
+python -m livetools mem alloc <size>          # allocate rwx memory in target (for code caves)
 python -m livetools scan <pattern> --range START:SIZE
 ```
 
-### Non-blocking Tracing (NEW)
+### Memory Write Watchpoint
+```
+python -m livetools memwatch start <addr> [--size N] [--max-hits N]   # catch who writes (IP + backtrace per hit)
+python -m livetools memwatch read             # show captured hits
+python -m livetools memwatch stop
+```
+
+### D3D9 Draw Counter
+```
+python -m livetools dipcnt on <dev_ptr>       # hook DrawIndexedPrimitive via global IDirect3DDevice9* address
+python -m livetools dipcnt read               # current count + delta since last read
+python -m livetools dipcnt callers [N]        # sample N DIP calls, histogram return addresses (default 200)
+python -m livetools dipcnt off
+```
+
+### Game Window Input (no Frida, no focus steal)
+```
+python -m livetools gamectl --exe <game.exe> info
+python -m livetools gamectl --exe <game.exe> key RETURN
+python -m livetools gamectl --exe <game.exe> keys "DOWN DOWN RETURN WAIT:1000 RETURN"
+python -m livetools gamectl --exe <game.exe> click <x> <y>
+python -m livetools gamectl --exe <game.exe> macro <name> --macro-file patches/<game>/macros.json
+```
+
+### Non-blocking Tracing
 ```
 python -m livetools trace <addr> [--count N] [--read SPEC] [--read-leave SPEC] [--filter EXPR] [--timeout T] [--output FILE]
 python -m livetools steptrace <addr> [--max-insn N] [--call-depth D] [--detail LEVEL] [--timeout T] [--output FILE]
@@ -186,11 +211,59 @@ Output: JSONL in `patches/<exe_name>/traces/` by default (gitignored).
 ```bash
 python -m livetools modules
 python -m livetools modules --filter kernel
-python -m livetools modules --filter kernel
 ```
 
 Returns name, base address, size, and full path for every loaded module. Essential for finding DLL bases for vtable hooks.
 
+### memwatch -- Hardware memory write watchpoint
+
+Uses Frida's MemoryAccessMonitor to catch writes to an address range, capturing the writing instruction pointer and a backtrace per hit. The runtime complement to static `datarefs.py` — catches writes through pointers computed at runtime.
+
+```bash
+python -m livetools memwatch start 0x7A0000 --size 48 --max-hits 20
+python -m livetools memwatch read
+python -m livetools memwatch stop
+```
+
+One active watchpoint at a time. Auto-stops after `--max-hits` (default 20).
+
+### dipcnt -- D3D9 DrawIndexedPrimitive counter
+
+Hooks DIP through the device vtable, given the address of the game's global `IDirect3DDevice9*` pointer. Use to measure draw call volume or find render-loop callers without a full trace.
+
+```bash
+python -m livetools dipcnt on 0x7C5548     # address of the global device pointer
+python -m livetools dipcnt read            # count + delta since last read
+python -m livetools dipcnt callers 200     # sample 200 calls, histogram return addresses
+python -m livetools dipcnt off
+```
+
+`callers` is the fast way to locate the main render loop: the dominant return address is the draw dispatcher.
+
+### gamectl -- Send input to the game window
+
+Posts WM_KEYDOWN/WM_KEYUP/clicks directly to the target window handle — no Frida, no focus stealing, works with the game in the background. Use to navigate menus or trigger in-game actions during long traces.
+
+```bash
+python -m livetools gamectl --exe game.exe info                      # show hwnd, title, pid
+python -m livetools gamectl --exe game.exe key RETURN [--hold-ms 50]
+python -m livetools gamectl --exe game.exe keys "DOWN DOWN RETURN WAIT:1000 RETURN" [--delay-ms 200]
+python -m livetools gamectl --exe game.exe click 400 300             # client-area coordinates
+python -m livetools gamectl --exe game.exe macro navigate_menu --macro-file patches/<game>/macros.json
+```
+
+Key names: `RETURN`, `ESCAPE`, `SPACE`, arrows, `TAB`, `F1`-`F12`, `A`-`Z`, `0`-`9`, `NUMPAD0`-`9`, `SHIFT`, `CTRL`, `ALT`. Sequence tokens: `WAIT:N` (pause N ms), `HOLD:KEY:N` (hold key N ms). Window lookup: `--exe` (preferred) or `--window <title substring>`.
+
+### vishook -- Selective visibility override via code cave
+
+Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`.
+
+```bash
+python -m livetools vishook on <jmp_site> <orig_target> [--threshold 500000]
+python -m livetools vishook stats     # override vs passthrough call counts
+python -m livetools vishook off       # restore original jmp
+```
+
 ### analyze -- Offline JSONL aggregation (no Frida needed)
 
 Pure Python. Reads JSONL from `collect` or `trace --output`. Deterministic, non-hallucinated aggregation.
@@ -402,7 +475,7 @@ python -m livetools analyze scene.jsonl --export-csv scene.csv
 
 9. **Hook the game's CALL instruction, not the DLL function.** To trace a D3D9 method (or any API call), find the `call [reg+offset]` or `call <addr>` instruction *in the game's code* via `xrefs.py` or `vtable.py calls`. Hook THAT address. Do NOT compute the target address inside d3d9.dll and hook there — the arguments are arranged at the caller, and the DLL entry point is shared across all callers.
 
-10. **Zero hits means something is wrong — diagnose, don't give up.** If trace/collect returns 0 samples: (a) Ask the user: is the game window focused and actively rendering? (b) Verify the address: `disasm <addr>` in livetools -- confirm real code exists there. (c) Try a known-hot address: `dipcnt callers 10` finds confirmed active call sites; trace one to prove the hook pipeline works. (d) Only after all three pass should you reconsider whether the original address is actually called during gameplay.
+10. **Zero hits means something is wrong — diagnose, don't give up.** If trace/collect returns 0 samples: (a) Ask the user: is the game window focused and actively rendering? (b) Verify the address: `disasm <addr>` in livetools — confirm real code exists there. (c) Try a known-hot address: `dipcnt callers 10` finds confirmed active call sites; trace one to prove the hook pipeline works. (d) Only after all three pass should you reconsider whether the original address is actually called during gameplay.
 
 ---
 
diff --git a/.kiro/steering/dx9-ffp-port.md b/.kiro/steering/dx9-ffp-port.md
index 1bb150a3..55b43bdb 100644
--- a/.kiro/steering/dx9-ffp-port.md
+++ b/.kiro/steering/dx9-ffp-port.md
@@ -20,7 +20,7 @@ Each game folder under `patches/<GameName>/` is a self-contained remix-comp-prox
 | `src/comp/modules/renderer.cpp` | Draw call routing -- `on_draw_indexed_prim()` and `on_draw_primitive()` |
 | `src/comp/modules/d3d9ex.cpp` | `IDirect3DDevice9` hook layer -- intercepts all 119 methods |
 | `src/comp/modules/skinning.cpp` | Skinning module (vertex expansion, bone upload, FFP blending) |
-| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `ffp_proxy.log` |
+| `src/comp/modules/diagnostics.cpp` | Diagnostic logging to `rtx_comp/diagnostics.log` |
 | `src/comp/modules/imgui.cpp` | ImGui debug overlay (F4 toggle) |
 | `src/shared/common/ffp_state.cpp` | FFP state tracker -- engage/disengage, matrix transforms, texture stages |
 | `src/shared/common/ffp_state.hpp` | `ffp_state` class with all state accessors |
@@ -106,7 +106,7 @@ Deploy: `d3d9.dll` + `remix-comp-proxy.ini` to game directory. Place `d3d9_remix
 
 ### Step 5: Diagnose with Log and ImGui
 
-The proxy writes `ffp_proxy.log` after a configurable delay (default 50 seconds) -- do not change the delay. Check VS regs written, vertex declarations, matrix values. Press **F4** for ImGui debug overlay.
+The proxy writes `rtx_comp/diagnostics.log` after a configurable delay (default 50 seconds) -- do not change the delay. Check VS regs written, vertex declarations, matrix values. Press **F4** for ImGui debug overlay.
 
 The user must be in-game with geometry visible when captures are needed.
 
diff --git a/.kiro/steering/tool-catalog.md b/.kiro/steering/tool-catalog.md
index 4fde1403..1882aa1c 100644
--- a/.kiro/steering/tool-catalog.md
+++ b/.kiro/steering/tool-catalog.md
@@ -27,6 +27,7 @@ These are fast (<5s) and allowed inline:
 - "What constant flows into this register?" → `python -m retools.dataflow $B $VA --constants`
 - "Trace where this value comes from" → `python -m retools.dataflow $B $VA --slice TARGET_VA:REG`
 - "Build an ASI patch DLL" → `python -m retools.asi_patcher build spec.json`
+- "Does a Ghidra project exist for this binary?" → `python retools/pyghidra_backend.py status $B --project $P`
 
 ### Delegate to `static-analyzer` subagent
 
@@ -59,6 +60,7 @@ Everything else. Tell the subagent WHAT you need, not HOW to run it — it has t
 - "What are the actual register values?" → `livetools trace --read` or `bp` + `regs`
 - "How many draw calls happen?" → `livetools dipcnt`
 - "Who writes to this memory address?" → `livetools memwatch`
+- "Send keys/clicks to the game window?" → `livetools gamectl`
 
 ### DX analysis scripts (main agent, fast first-pass)
 
@@ -177,12 +179,15 @@ python -m livetools status                              # check connection
 | `regs` / `stack` / `bt` | Inspect registers, stack, backtrace at break |
 | `mem read $VA $SIZE` | Read live process memory (supports --as float32) |
 | `mem write $VA $HEX` | Write live process memory |
+| `mem alloc $SIZE` | Allocate rwx memory in target (for code caves) |
 | `disasm [$VA]` | Disassemble from live process |
 | `scan $PATTERN` | Search process memory for byte pattern |
 | `modules` | List loaded modules with base addresses |
 | `dipcnt on/off/read` | D3D9 DrawIndexedPrimitive call counter |
 | `dipcnt callers [N]` | Sample N DIP calls and histogram return addresses |
 | `memwatch start/stop/read` | Memory write watchpoint with backtrace |
+| `vishook on/off/stats` | Selective visibility override via code cave (forces visible above caller threshold) |
+| `gamectl key/keys/click/macro` | Send keys/clicks to game window (no Frida, no focus steal) |
 | `analyze $FILE` | Offline analysis of collected .jsonl trace data |
 
 **NOTE**: Some processes require their window to be focused for traces to capture data.

From 2bee974009d9008924ee8d9fe9afef750e4b9865 Mon Sep 17 00:00:00 2001
From: Ben Gregg <ben10gregg@gmail.com>
Date: Thu, 11 Jun 2026 00:02:32 -0500
Subject: [PATCH 3/3] Restore skinning content dropped by skill sync; document
 vishook hex threshold

Review fixes for this PR:

- Back-port content the dx9-ffp-port sync deleted from the .cursor/.kiro/
  .github copies without first folding it into the canonical .claude skill:
  the "Skinning Stability: Finding Game-Specific Hook Points" workflow, the
  "Bones mixed up between NPCs" pitfall, and the stages 1-7 disabling detail
  (verified against ffp_state.cpp). Propagated to all four trees; bodies
  remain identical across trees.
- Note in all four dynamic-analysis skills that vishook --threshold is
  parsed as hex (agent.js parseInt(..., 16)): default 500000 = 0x500000.
- Update .github dx9-ffp-port frontmatter description to the trigger-style
  wording used by the other trees.
---
 .claude/skills/dx9-ffp-port/SKILL.md     | 15 ++++++++++++++-
 .claude/skills/dynamic-analysis/SKILL.md |  2 +-
 .cursor/skills/dx9-ffp-port/SKILL.md     | 15 ++++++++++++++-
 .cursor/skills/dynamic-analysis/SKILL.md |  2 +-
 .github/skills/dx9-ffp-port/SKILL.md     | 17 +++++++++++++++--
 .github/skills/dynamic-analysis/SKILL.md |  2 +-
 .kiro/powers/dx9-ffp-port/POWER.md       | 15 ++++++++++++++-
 .kiro/powers/dynamic-analysis/POWER.md   |  2 +-
 8 files changed, 61 insertions(+), 9 deletions(-)

diff --git a/.claude/skills/dx9-ffp-port/SKILL.md b/.claude/skills/dx9-ffp-port/SKILL.md
index 32e54f1d..7d140f30 100644
--- a/.claude/skills/dx9-ffp-port/SKILL.md
+++ b/.claude/skills/dx9-ffp-port/SKILL.md
@@ -37,7 +37,7 @@ Each game folder under `patches/<GameName>/` is a self-contained remix-comp-prox
    - Rigid 3D (has NORMAL) -> NULLs shaders, applies FFP transforms
 4. Routes `DrawPrimitive` via `renderer::on_draw_primitive`: world-space (has decl, no POSITIONT, not skinned) -> FFP; otherwise pass-through
 5. Applies captured matrices via `ffp_state::apply_transforms` -> `SetTransform`
-6. Sets up texture stages and lighting for FFP rendering
+6. Sets up texture stages and lighting for FFP rendering (stages 1-7 disabled to prevent stale auxiliary textures reaching Remix)
 7. Loads the real d3d9 chain (RTX Remix `d3d9_remix.dll` or system d3d9) via d3d9_proxy
 
 ## Codebase File Map
@@ -305,7 +305,20 @@ AND !ffp.cur_decl_has_pos_t() AND !ffp.cur_decl_is_skinned()?
 - **Everything is white/black**: Albedo texture is on stage 1+, not stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini`, or trace `SetTexture` calls to find the correct stage.
 - **Some objects render, others don't**: Check whether missing geometry has NORMAL in its vertex decl. Check `ffp.view_proj_valid()` is true at draw time. DrawPrimitive routes on decl presence + no POSITIONT + not skinned.
 - **Skinned meshes invisible**: Set `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Check log for skinning errors. Verify `bone_start_reg` and `num_bones` are non-zero in the log.
+- **Bones mixed up between NPCs**: Stale WORLDMATRIX slots from a previous object. The game may need a game-specific reset hook at a per-object boundary -- see Skinning Stability below.
 - **Game crashes on startup**: Set `[Remix] Enabled=0` in `remix-comp-proxy.ini` to test without Remix. Check `WINDOW_CLASS_NAME` in `comp/main.cpp`.
 - **Geometry at origin / piled up**: World matrix register mapping wrong. Re-examine VS constant writes via `livetools trace` or DX9 tracer `--const-provenance`.
 - **World geometry shifts after skinned draws**: `WORLDMATRIX(0)` clobbered by bone[0]. The proxy tracks `world_dirty_` for re-application. If still broken, check for bone register overlap with world matrix range in `ffp_state.hpp`.
 - **ImGui overlay not appearing**: Press F4. Check that `WINDOW_CLASS_NAME` is correct and the window was found (console output). Check for DirectInput hook conflicts.
+
+### Skinning Stability: Finding Game-Specific Hook Points
+
+The proxy's generic heuristics handle most games. If bones still leak between objects, the game needs a hook at a per-object boundary function -- one that's called once per skinned object, before its bones are uploaded.
+
+**Finding the per-object function:**
+
+1. **Capture** 2+ frames with the D3D9 tracer while multiple skinned NPCs are on screen
+2. **Hotpaths**: `--hotpaths --resolve-addrs <game.exe>` -- look at callers of bone-range `SetVertexShaderConstantF` writes
+3. **Caller histogram**: `--callers SetVertexShaderConstantF` -- the function that appears N times per frame (N = number of skinned objects) is the per-object boundary
+4. **Live confirm**: `livetools trace <candidate_addr> --count 50` -- with 3 NPCs, expect ~3 hits/frame
+5. **Static context**: `callgraph.py --up` + `decompiler.py` on the caller -- confirm it loops over objects
diff --git a/.claude/skills/dynamic-analysis/SKILL.md b/.claude/skills/dynamic-analysis/SKILL.md
index d8709909..38255d66 100644
--- a/.claude/skills/dynamic-analysis/SKILL.md
+++ b/.claude/skills/dynamic-analysis/SKILL.md
@@ -253,7 +253,7 @@ Key names: `RETURN`, `ESCAPE`, `SPACE`, arrows, `TAB`, `F1`-`F12`, `A`-`Z`, `0`-
 
 ### vishook -- Selective visibility override via code cave
 
-Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`.
+Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`. The `--threshold` value is parsed as hex: the default `500000` means 0x500000.
 
 ```bash
 python -m livetools vishook on <jmp_site> <orig_target> [--threshold 500000]
diff --git a/.cursor/skills/dx9-ffp-port/SKILL.md b/.cursor/skills/dx9-ffp-port/SKILL.md
index f7a42da8..a8411851 100644
--- a/.cursor/skills/dx9-ffp-port/SKILL.md
+++ b/.cursor/skills/dx9-ffp-port/SKILL.md
@@ -38,7 +38,7 @@ Each game folder under `patches/<GameName>/` is a self-contained remix-comp-prox
    - Rigid 3D (has NORMAL) -> NULLs shaders, applies FFP transforms
 4. Routes `DrawPrimitive` via `renderer::on_draw_primitive`: world-space (has decl, no POSITIONT, not skinned) -> FFP; otherwise pass-through
 5. Applies captured matrices via `ffp_state::apply_transforms` -> `SetTransform`
-6. Sets up texture stages and lighting for FFP rendering
+6. Sets up texture stages and lighting for FFP rendering (stages 1-7 disabled to prevent stale auxiliary textures reaching Remix)
 7. Loads the real d3d9 chain (RTX Remix `d3d9_remix.dll` or system d3d9) via d3d9_proxy
 
 ## Codebase File Map
@@ -306,7 +306,20 @@ AND !ffp.cur_decl_has_pos_t() AND !ffp.cur_decl_is_skinned()?
 - **Everything is white/black**: Albedo texture is on stage 1+, not stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini`, or trace `SetTexture` calls to find the correct stage.
 - **Some objects render, others don't**: Check whether missing geometry has NORMAL in its vertex decl. Check `ffp.view_proj_valid()` is true at draw time. DrawPrimitive routes on decl presence + no POSITIONT + not skinned.
 - **Skinned meshes invisible**: Set `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Check log for skinning errors. Verify `bone_start_reg` and `num_bones` are non-zero in the log.
+- **Bones mixed up between NPCs**: Stale WORLDMATRIX slots from a previous object. The game may need a game-specific reset hook at a per-object boundary -- see Skinning Stability below.
 - **Game crashes on startup**: Set `[Remix] Enabled=0` in `remix-comp-proxy.ini` to test without Remix. Check `WINDOW_CLASS_NAME` in `comp/main.cpp`.
 - **Geometry at origin / piled up**: World matrix register mapping wrong. Re-examine VS constant writes via `livetools trace` or DX9 tracer `--const-provenance`.
 - **World geometry shifts after skinned draws**: `WORLDMATRIX(0)` clobbered by bone[0]. The proxy tracks `world_dirty_` for re-application. If still broken, check for bone register overlap with world matrix range in `ffp_state.hpp`.
 - **ImGui overlay not appearing**: Press F4. Check that `WINDOW_CLASS_NAME` is correct and the window was found (console output). Check for DirectInput hook conflicts.
+
+### Skinning Stability: Finding Game-Specific Hook Points
+
+The proxy's generic heuristics handle most games. If bones still leak between objects, the game needs a hook at a per-object boundary function -- one that's called once per skinned object, before its bones are uploaded.
+
+**Finding the per-object function:**
+
+1. **Capture** 2+ frames with the D3D9 tracer while multiple skinned NPCs are on screen
+2. **Hotpaths**: `--hotpaths --resolve-addrs <game.exe>` -- look at callers of bone-range `SetVertexShaderConstantF` writes
+3. **Caller histogram**: `--callers SetVertexShaderConstantF` -- the function that appears N times per frame (N = number of skinned objects) is the per-object boundary
+4. **Live confirm**: `livetools trace <candidate_addr> --count 50` -- with 3 NPCs, expect ~3 hits/frame
+5. **Static context**: `callgraph.py --up` + `decompiler.py` on the caller -- confirm it loops over objects
diff --git a/.cursor/skills/dynamic-analysis/SKILL.md b/.cursor/skills/dynamic-analysis/SKILL.md
index d8709909..38255d66 100644
--- a/.cursor/skills/dynamic-analysis/SKILL.md
+++ b/.cursor/skills/dynamic-analysis/SKILL.md
@@ -253,7 +253,7 @@ Key names: `RETURN`, `ESCAPE`, `SPACE`, arrows, `TAB`, `F1`-`F12`, `A`-`Z`, `0`-
 
 ### vishook -- Selective visibility override via code cave
 
-Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`.
+Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`. The `--threshold` value is parsed as hex: the default `500000` means 0x500000.
 
 ```bash
 python -m livetools vishook on <jmp_site> <orig_target> [--threshold 500000]
diff --git a/.github/skills/dx9-ffp-port/SKILL.md b/.github/skills/dx9-ffp-port/SKILL.md
index 1f53e708..647be5d4 100644
--- a/.github/skills/dx9-ffp-port/SKILL.md
+++ b/.github/skills/dx9-ffp-port/SKILL.md
@@ -1,6 +1,6 @@
 ---
 name: 'DX9 FFP Port'
-description: 'Port a DX9 shader-based game to fixed-function pipeline for RTX Remix compatibility'
+description: 'Use when porting a game for RTX Remix or to the fixed-function pipeline, working on renderer.cpp / ffp_state / remix-comp-proxy.ini / draw routing / VS constants / vertex declarations / matrix mapping / skinning, building or deploying a remix-comp-proxy patch, or diagnosing rendering issues in a patched game.'
 argument-hint: '<game.exe path>'
 ---
 
@@ -38,7 +38,7 @@ Each game folder under `patches/<GameName>/` is a self-contained remix-comp-prox
    - Rigid 3D (has NORMAL) -> NULLs shaders, applies FFP transforms
 4. Routes `DrawPrimitive` via `renderer::on_draw_primitive`: world-space (has decl, no POSITIONT, not skinned) -> FFP; otherwise pass-through
 5. Applies captured matrices via `ffp_state::apply_transforms` -> `SetTransform`
-6. Sets up texture stages and lighting for FFP rendering
+6. Sets up texture stages and lighting for FFP rendering (stages 1-7 disabled to prevent stale auxiliary textures reaching Remix)
 7. Loads the real d3d9 chain (RTX Remix `d3d9_remix.dll` or system d3d9) via d3d9_proxy
 
 ## Codebase File Map
@@ -306,7 +306,20 @@ AND !ffp.cur_decl_has_pos_t() AND !ffp.cur_decl_is_skinned()?
 - **Everything is white/black**: Albedo texture is on stage 1+, not stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini`, or trace `SetTexture` calls to find the correct stage.
 - **Some objects render, others don't**: Check whether missing geometry has NORMAL in its vertex decl. Check `ffp.view_proj_valid()` is true at draw time. DrawPrimitive routes on decl presence + no POSITIONT + not skinned.
 - **Skinned meshes invisible**: Set `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Check log for skinning errors. Verify `bone_start_reg` and `num_bones` are non-zero in the log.
+- **Bones mixed up between NPCs**: Stale WORLDMATRIX slots from a previous object. The game may need a game-specific reset hook at a per-object boundary -- see Skinning Stability below.
 - **Game crashes on startup**: Set `[Remix] Enabled=0` in `remix-comp-proxy.ini` to test without Remix. Check `WINDOW_CLASS_NAME` in `comp/main.cpp`.
 - **Geometry at origin / piled up**: World matrix register mapping wrong. Re-examine VS constant writes via `livetools trace` or DX9 tracer `--const-provenance`.
 - **World geometry shifts after skinned draws**: `WORLDMATRIX(0)` clobbered by bone[0]. The proxy tracks `world_dirty_` for re-application. If still broken, check for bone register overlap with world matrix range in `ffp_state.hpp`.
 - **ImGui overlay not appearing**: Press F4. Check that `WINDOW_CLASS_NAME` is correct and the window was found (console output). Check for DirectInput hook conflicts.
+
+### Skinning Stability: Finding Game-Specific Hook Points
+
+The proxy's generic heuristics handle most games. If bones still leak between objects, the game needs a hook at a per-object boundary function -- one that's called once per skinned object, before its bones are uploaded.
+
+**Finding the per-object function:**
+
+1. **Capture** 2+ frames with the D3D9 tracer while multiple skinned NPCs are on screen
+2. **Hotpaths**: `--hotpaths --resolve-addrs <game.exe>` -- look at callers of bone-range `SetVertexShaderConstantF` writes
+3. **Caller histogram**: `--callers SetVertexShaderConstantF` -- the function that appears N times per frame (N = number of skinned objects) is the per-object boundary
+4. **Live confirm**: `livetools trace <candidate_addr> --count 50` -- with 3 NPCs, expect ~3 hits/frame
+5. **Static context**: `callgraph.py --up` + `decompiler.py` on the caller -- confirm it loops over objects
diff --git a/.github/skills/dynamic-analysis/SKILL.md b/.github/skills/dynamic-analysis/SKILL.md
index 203ecd3c..2e72c824 100644
--- a/.github/skills/dynamic-analysis/SKILL.md
+++ b/.github/skills/dynamic-analysis/SKILL.md
@@ -254,7 +254,7 @@ Key names: `RETURN`, `ESCAPE`, `SPACE`, arrows, `TAB`, `F1`-`F12`, `A`-`Z`, `0`-
 
 ### vishook -- Selective visibility override via code cave
 
-Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`.
+Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`. The `--threshold` value is parsed as hex: the default `500000` means 0x500000.
 
 ```bash
 python -m livetools vishook on <jmp_site> <orig_target> [--threshold 500000]
diff --git a/.kiro/powers/dx9-ffp-port/POWER.md b/.kiro/powers/dx9-ffp-port/POWER.md
index 1dd635d2..08a7f236 100644
--- a/.kiro/powers/dx9-ffp-port/POWER.md
+++ b/.kiro/powers/dx9-ffp-port/POWER.md
@@ -40,7 +40,7 @@ Each game folder under `patches/<GameName>/` is a self-contained remix-comp-prox
    - Rigid 3D (has NORMAL) -> NULLs shaders, applies FFP transforms
 4. Routes `DrawPrimitive` via `renderer::on_draw_primitive`: world-space (has decl, no POSITIONT, not skinned) -> FFP; otherwise pass-through
 5. Applies captured matrices via `ffp_state::apply_transforms` -> `SetTransform`
-6. Sets up texture stages and lighting for FFP rendering
+6. Sets up texture stages and lighting for FFP rendering (stages 1-7 disabled to prevent stale auxiliary textures reaching Remix)
 7. Loads the real d3d9 chain (RTX Remix `d3d9_remix.dll` or system d3d9) via d3d9_proxy
 
 ## Codebase File Map
@@ -308,7 +308,20 @@ AND !ffp.cur_decl_has_pos_t() AND !ffp.cur_decl_is_skinned()?
 - **Everything is white/black**: Albedo texture is on stage 1+, not stage 0. Set `AlbedoStage` in `remix-comp-proxy.ini`, or trace `SetTexture` calls to find the correct stage.
 - **Some objects render, others don't**: Check whether missing geometry has NORMAL in its vertex decl. Check `ffp.view_proj_valid()` is true at draw time. DrawPrimitive routes on decl presence + no POSITIONT + not skinned.
 - **Skinned meshes invisible**: Set `[Skinning] Enabled=1` in `remix-comp-proxy.ini`. Check log for skinning errors. Verify `bone_start_reg` and `num_bones` are non-zero in the log.
+- **Bones mixed up between NPCs**: Stale WORLDMATRIX slots from a previous object. The game may need a game-specific reset hook at a per-object boundary -- see Skinning Stability below.
 - **Game crashes on startup**: Set `[Remix] Enabled=0` in `remix-comp-proxy.ini` to test without Remix. Check `WINDOW_CLASS_NAME` in `comp/main.cpp`.
 - **Geometry at origin / piled up**: World matrix register mapping wrong. Re-examine VS constant writes via `livetools trace` or DX9 tracer `--const-provenance`.
 - **World geometry shifts after skinned draws**: `WORLDMATRIX(0)` clobbered by bone[0]. The proxy tracks `world_dirty_` for re-application. If still broken, check for bone register overlap with world matrix range in `ffp_state.hpp`.
 - **ImGui overlay not appearing**: Press F4. Check that `WINDOW_CLASS_NAME` is correct and the window was found (console output). Check for DirectInput hook conflicts.
+
+### Skinning Stability: Finding Game-Specific Hook Points
+
+The proxy's generic heuristics handle most games. If bones still leak between objects, the game needs a hook at a per-object boundary function -- one that's called once per skinned object, before its bones are uploaded.
+
+**Finding the per-object function:**
+
+1. **Capture** 2+ frames with the D3D9 tracer while multiple skinned NPCs are on screen
+2. **Hotpaths**: `--hotpaths --resolve-addrs <game.exe>` -- look at callers of bone-range `SetVertexShaderConstantF` writes
+3. **Caller histogram**: `--callers SetVertexShaderConstantF` -- the function that appears N times per frame (N = number of skinned objects) is the per-object boundary
+4. **Live confirm**: `livetools trace <candidate_addr> --count 50` -- with 3 NPCs, expect ~3 hits/frame
+5. **Static context**: `callgraph.py --up` + `decompiler.py` on the caller -- confirm it loops over objects
diff --git a/.kiro/powers/dynamic-analysis/POWER.md b/.kiro/powers/dynamic-analysis/POWER.md
index bff69103..d28327ce 100644
--- a/.kiro/powers/dynamic-analysis/POWER.md
+++ b/.kiro/powers/dynamic-analysis/POWER.md
@@ -256,7 +256,7 @@ Key names: `RETURN`, `ESCAPE`, `SPACE`, arrows, `TAB`, `F1`-`F12`, `A`-`Z`, `0`-
 
 ### vishook -- Selective visibility override via code cave
 
-Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`.
+Patches a jmp trampoline to route through a code cave that forces a "visible" result (st0 = 102400.0, optional byte out = 1) for callers at/above a threshold address, while callers below it run the original function. Designed for `__thiscall` visibility checks returning float on st(0) with `ret 0x10`. The `--threshold` value is parsed as hex: the default `500000` means 0x500000.
 
 ```bash
 python -m livetools vishook on <jmp_site> <orig_target> [--threshold 500000]