docs(research): portability audit of DrussGT 3.1.4159

Measured hazard counts for a Java->Nim port, with the correction that only
22 of 28 top-level classes ship source (6 do not: 5 in the gun package plus
dMove/Scan), so a full port would need a decompiler while a shim would not
care at all.

Real traps: 193 float / 35 casts / 147 literals / 60 float[] in the movement
closure (the danger histogram is float[171] -- porting 32-bit Java floats to
Nim's default float64 diverges silently); ~68 non-final statics; and 4 Java
single-& sites with side effects, which break under Nim's short-circuiting
'and'. Non-issues, correcting earlier assumptions: 0 sites of %-on-negative
(angle normalisation is floor-based) and FastTrig has no lookup tables, it is
7 coefficient-exact polynomials.

Movement scoping: 5007 LOC across 14 files, ~4.8-6.1k Nim LOC, 4-8 focused
agent-days to first-compiles. It can be ported WITHOUT the gun (data flows
movement->gun only), but the harness never routes HitByBullet into movement
modules, so the danger bins would never train -- that plumbing is the real
blocker, not the translation.

docs/research/drussgt-port-audit.md

@@ -0,0 +1,720 @@
+# DrussGT 3.1.4159 → Nim portability audit
+
+**Issue:** N/A (read-only portability audit requested by orchestrator)
+**Date:** 2026-09-20
+**Subject:** DrussGT 3.1.4159 (Java, classic Robocode), `public class DrussGT extends AdvancedRobot`
+**Source analysed:** `/tmp/drussgt/src` → copied to `/tmp/portaudit/src` before analysis (so the
+analysis could not collide with any other agent). 22 `.java` files, **7372 lines** total.
+Entry point `jk/mega/DrussGT.java`.
+
+**Method / legend.**
+- `[MEASURED]` = a count I actually took in the source (grep/script over `/tmp/portaudit/src`); every
+  such row carries a `file:line` witness or names the exact command.
+- `[ESTIMATE]` = engineering judgment, explicitly labelled. Never presented as measured.
+- `[EXTERNAL]` = depends on classic-Robocode library semantics that are **not** in this source tree
+  and cannot be verified offline from the supplied input (e.g. `robocode.util.Utils`).
+- Per the task constraints I did **not** build, run nim/nimble, or download anything. The
+  Robocode/DrussGT jars already present in `/tmp/robocode/` were only *listed*.
+
+Where this report quotes DrussGT, it quotes `/tmp/portaudit/src/jk/...`.
+
+---
+
+## 0. Verdict in one paragraph
+
+A **behaviourally exact** port is impossible for the reasons already established (different engine
+tick ordering and physics: classic Robocode is `setAhead`-distance-based, Tank Royale's harness is
+`speed`/`turnRate`-based; see §A.3). An **algorithmically faithful** port of the movement subsystem
+is achievable and is the right first target, because the movement is self-contained: it consumes
+engine state + hit events and exports future-position data *to* the gun, never the reverse
+(§A.4). It is **large** — the mandatory movement file set is **5007 lines of Java** [MEASURED]
+(§A.1), of which ~2100 lines are the `DrussMoveGT` core. The dominant fidelity risk is not `%`
+or reflection; it is **`float` (32-bit) state** (193 `float` occurrences in movement, 35 `(float)`
+casts there; 195/37 tree-wide) and
+**table-exact data** (`BufferManager`: ~240 hand-written buffer-set rows / 22 slice tables [MEASURED])
+plus a **~5000-line KNN/wave-danger engine** that must be ported rather than replaced (stylistically
+similar to the existing `common_libs/guns/knn_gun.nim`, which already reimplements a reduced version
+of the DC gun). No reflection, threads, lambdas, anonymous classes, JNI or serialization stand in the
+way. Recommended validation is a **hybrid**: golden-value unit tests on the trap-prone pure functions
+(cheapest) **plus** replay of the already-captured classic-Robocode DrussGT fixtures
+(`tools/fixtures/`) to compare decisions, not trajectories.
+
+---
+
+## 1. Source inventory `[MEASURED]`
+
+`find /tmp/portaudit/src -name '*.java' -exec wc -l {} +` and per-file `wc -l`:
+
+| File | Lines | Role |
+|---|---:|---|
+| `jk/mega/dMove/DrussMoveGT.java` | 2283 | **movement core** (wave surfer, KNN buffer orchestration) |
+| `jk/mega/dGun/DrussGunDC.java` | 1352 | gun |
+| `jk/mega/BufferManager.java` | 652 | movement stat/flattener buffers + feature slice tables |
+| `jk/tree/KDTree.java` | 617 | KD-tree (used by gun **and** movement enemy model) |
+| `jk/precise/EnergyDomeWorker.java` | 462 | "EnergyDome" anti-gun shield (optional subsystem) |
+| `jk/mega/dGun/PreciseMinMaxGFs.java` | 266 | precise MEA geometry — **used by movement** |
+| `jk/mega/EnemyMoves.java` | 264 | enemy-movement predictor (KD-tree of motion chains) |
+| `jk/mega/dMove/EnemyWave.java` | 236 | enemy bullet wave, shadows, GF factor index |
+| `jk/mega/dMove/MovePredictor.java` | 228 | our own tick-by-tick movement simulator |
+| `jk/math/FastTrig.java` | 193 | polynomial trig (no tables) |
+| `jk/mega/Insulter.java` | 162 | random insults (cosmetic) |
+| `jk/precise/util/PreciseUtils.java` | 155 | circle/rect intersection for precise waves |
+| `jk/melee/MeleeRadar.java` | 94 | radar |
+| `jk/mega/BulletPowerPredictor.java` | 50 | KD-tree bullet-power predictor |
+| `jk/mega/dMove/PredictionStatus.java` | 27 | prediction result struct |
+| `jk/mega/dMove/PlaceTime.java` | 18 | (place,time,danger) struct |
+| `jk/mega/dMove/BulletTracker.java` | 12 | our-bullet tracking for shadows |
+| `jk/mega/DataToGun.java` | 11 | movement→gun struct |
+| `jk/mega/dGun/GFRange.java` | 8 | gun helper (duplicated in `DrussGunDC.java:729`) |
+| `jk/mega/dGun/Indice.java` | 9 | gun helper (duplicated in `DrussGunDC.java:1207`) |
+| `jk/precise/util/PreciseWave.java` | 6 | precise wave struct |
+| `jk/mega/DrussGT.java` | 267 | bot entry / event dispatch |
+| **Total** | **7372** | |
+
+Comment/blank lines: **1718 / 7372 (23%)** [MEASURED]; `DrussMoveGT.java` alone is **564 comment/blank
+of 2283 (25%)** [MEASURED].
+
+**Decompilation artefact / incomplete-gun warning `[MEASURED]`.** The tree also contains `.class`
+files. `DrussMoveGT.java` ends with a second top-level class `Scan` (line 2187) and `DrussGunDC.java`
+declares `DCRobotState`/`GFRange`/`StoreScan`/`DCWave`/`Indice`/`NormalDistribution`/`JKDCUtils`
+inline (lines 587/729/737/745/1207/1216/1222). Consequently `GFRange.java` and `Indice.java` are
+**duplicate class definitions** — the tree does **not** compile as-is. This affects the gun only:
+movement's required files all exist (movement references only `DataToGun`, `PreciseMinMaxGFs` and
+never `JKDCUtils`/`DCWave`/`StoreScan`/`DCRobotState`, per
+`grep -rnE 'JKDCUtils|DCRobotState|DCWave|StoreScan|NormalDistribution' --include='*.java' | grep -v DrussGunDC` → no hits outside `DrussGunDC.java`).
+
+---
+
+## 2. Hazard counts table (the summary the task asked for)
+
+| # | Hazard | Count `[MEASURED]` | Where | Severity for DrussGT |
+|---|---|---|---:|---|
+| 1 | `float` occurrences (movement only) | **193** (115 `DrussMoveGT`, 67 `BufferManager`, 9 `EnemyWave`, 1 `PlaceTime`, 1 `BulletPowerPredictor`) | see §3.1 | **HIGH (fatal for exactness)** |
+| 1b | `(float)` casts (movement) | **35** (31 `DrussMoveGT`, 4 `EnemyWave`) | §3.1 | HIGH |
+| 1c | `float[]` / `float[][]` / `float[][][]` decls | **60 / 10 / 9** | §3.1 | HIGH |
+| 1d | `float` literals (whole tree) | **147** (133 `BufferManager`, 13 `DrussMoveGT`, 1 `FastTrig`) | §3.1 | HIGH |
+| 1e | `double` occurrences (whole tree) | 685 lines | — | baseline: >3× float |
+| 2 | `%` modulo total | **7** (4 arithmetic, 3 string-format) | §3.2 | **LOW** |
+| 2b | `%` on possibly-negative operands | **0** | §3.2 | none |
+| 2c | `Math.floor`-based angle normalisers | 2 functions (`FastTrig.normalRelativeAngle`/`normalAbsoluteAngle`, many call sites) | §3.2 | LOW — already floor-mod semantics |
+| 3 | `static` non-`final` fields | **~68** total; **27** in `DrussMoveGT` | §3.3 | MEDIUM |
+| 3b | `static final` primitives/constants | many (harmless) | §3.3 | none |
+| 3c | `static final` **arrays with mutable contents** | 2 (`narrowprofile`, `wideprofile`) | §3.3 | LOW-MED |
+| 4 | Table-driven math (`FastTrig`) | **0 tables** — 7 polynomial/rational approximations (sin/cos/tan/asin/acos/atan + Chebyshev) | §3.4 | **HIGH** (must be coefficient-exact) |
+| 4b | Hand-written data tables (`BufferManager`) | 22 slice tables / ~240 buffer-set rows | §3.4 | HIGH (must be data-exact) |
+| 5 | `>>>` unsigned shift | **1** (`KDTree.java:545`, non-negative operands) | §3.5 | LOW |
+| 5b | `<<`, `>>`, `^` | 0 / 0 / 0 | §3.5 | none |
+| 5c | single `&` / single `|` (non-short-circuit boolean) | **34 / 11** | §3.5 | MEDIUM (see side-effect sites) |
+| 5d | `&`/`|` operands with side effects (`--`, `--`) | **4** | §3.5 | **MEDIUM-HIGH trap** |
+| 5e | `(int)` casts | **137** | §3.5 | LOW-MED |
+| 6 | `java.util`: `ArrayList` occurrences | 136 | §3.6 | LOW (→ `seq`) |
+| 6b | `Hashtable` / `Vector` | 2 / 1 (`MeleeRadar`, `onDeath`) | §3.6 | LOW |
+| 6c | `HashMap`/`TreeMap`/`HashSet`/`TreeSet`/`LinkedList` | **0** | §3.6 | none |
+| 6d | `Collections.sort` / `Arrays.*` | 2 / 6 | §3.6 | LOW |
+| 6e | `Comparable` / `Comparator` impls | 5 / 1 | §3.6 | LOW |
+| 6f | anonymous classes / lambdas | **0 / 0** | §3.6 | none |
+| 6g | `java.awt.geom.Point2D` / `Rectangle2D` | 268 / 7 | §3.6 | LOW |
+| 6h | `java.io` active persistence | 2 sites, both best-effort error logging (`logData=false`) | §3.6 | LOW |
+| 7 | reflection / JNI / `System.load` / serialization / dynamic class loading | **0** | §3.7 | none |
+| 7b | threads / `synchronized` | 1 (`DrussGT.java:79 Thread.sleep(0,1000)`) | §3.7 | LOW |
+| 7c | `SkippedTurnEvent` reliance | 1 method, prints only | §3.7 | LOW |
+| 7d | engine-timing semantics (`getTime`, gun-cooling rate, `getOthers`) | pervasive | §3.7 | MEDIUM |
+
+---
+
+## 3. Hazard-by-hazard detail
+
+### 3.1 `float` vs `double` — **the single biggest fidelity risk** `[MEASURED]`
+
+Counts (occurrences, not lines), from `grep -oE '\bfloat\b' | wc -l` per file:
+
+| File | `float` tokens | `(float)` casts | `float` literals |
+|---|---:|---:|---:|
+| `jk/mega/dMove/DrussMoveGT.java` | 115 | 31 | 13 |
+| `jk/mega/BufferManager.java` | 67 | 0 | 133 |
+| `jk/mega/dMove/EnemyWave.java` | 9 | 4 | 0 |
+| `jk/mega/BulletPowerPredictor.java` | 1 | 0 | 0 |
+| `jk/mega/dMove/PlaceTime.java` | 1 | 0 | 0 |
+| `jk/mega/dGun/DrussGunDC.java` | 2 | 2 | 0 |
+| `jk/math/FastTrig.java` | 0 | 0 | 1 |
+| **Total** | **195** | **37** | **147** |
+
+Array declarations: `float[]` × 60, `float[][]` × 10, `float[][][]` × 9 [MEASURED].
+
+Why this is potentially fatal for a wave surfer: the **entire danger histogram and the KNN feature
+vector are 32-bit**.
+
+- `EnemyWave.BINS = 171`, `MIDDLE_BIN = 85` (`EnemyWave.java:41-42`). `bestBins` and `binCleared`
+  are `float[171]` (`EnemyWave.java:20-21`).
+- `DrussMoveGT.getDanger(...)` returns `float` (`DrussMoveGT.java:1509`); `PlaceTime.danger` is
+  `float` (`PlaceTime.java:13`) and the candidate sort orders by it (`PlaceTime.java:16-17`).
+- The KNN features are built as `float` and looked up against `float[]` slice boundaries:
+  `lastLatVel`, `advVel`, `BFT`, `tsdirchange`, `accel`, `tsvchange`, `dl10`, `forwardWall`,
+  `reverseWall` (`DrussMoveGT.java:320-357`, duplicated for the imaginary/flattener waves at
+  453-490 and 574-611) → `BufferManager.getIndexes(...)` (`BufferManager.java:452`) →
+  `getIndex(float[] slices, float value)` with `value >= slices[index]` (`BufferManager.java:513-517`).
+- `BufferManager` holds 22 `static final float[]` slice tables with 147 float literals
+  (`BufferManager.java:10-38`), and each `StatBuffer` is a 9-dimensional `SingleBuffer` array built
+  from those slices (`BufferManager.java:541-600`).
+
+Consequence: a value that lands *exactly* on a slice boundary (e.g. `BFT == 20f`) can fall into a
+different bucket if computed in binary64. Over thousands of ticks this silently reshapes the danger
+histogram. Nim defaults to `float64`; the port must use `float32` (`float32`/`array[... , float32]`)
+for every one of these fields, casts and literals to preserve rounding — or accept documented
+divergence. **Do not port `float` → Nim `float` (64-bit) silently.**
+
+Full site list for the casts is in §A.1; the `(float)` casts are concentrated at
+`DrussMoveGT.java:320-357, 432, 453-490, 574-611, 1506, 1558` and
+`EnemyWave.java:108,110,188,190`.
+
+### 3.2 `%` remainder on angles / negatives — **LOW, and mostly a non-issue** `[MEASURED]`
+
+All `%` sites (`grep -rnE '%' --include='*.java'` minus comments):
+
+| Site | Operand | Negative possible? | Correct Nim |
+|---|---|---|---|
+| `KDTree.java:103` `nodeSize % _bucketSize == 0` | `nodeSize` = point count | No | `mod` |
+| `BufferManager.java:535` `hits = (hits+1)%bins.length` | counter | No | `mod` |
+| `EnergyDomeWorker.java:154` `bullets%2` | counter | No | `mod` |
+| `EnergyDomeWorker.java:158` `maxIndex%(OPTIONS/3)` | index | No | `mod` |
+| `DrussGunDC.java:44`, `DrussMoveGT.java:101,658` | string `"%"` format | n/a | n/a |
+
+There are **zero `%`-on-negative** sites in the source. Angle normalisation never uses `%`: it uses
+`FastTrig.normalRelativeAngle` / `normalAbsoluteAngle`, which are **floor-based**
+(`FastTrig.java:183-193`: `i = Math.floor(d*(1/(2π))); d -= i*(2π)`), i.e. exactly Nim's `floorMod`
+behaviour, not Java `%`. The correct Nim construct already exists — reimplement these two functions
+verbatim. The classic `((x+180) % 360) - 180` idiom does **not** appear.
+
+The one caveat is `[EXTERNAL]` `robocode.util.Utils.normalRelativeAngle` / `normalAbsoluteAngle`,
+called at `MeleeRadar.java:55,60` and `EnemyMoves.java:58,123`. Those are the engine's functions,
+not DrussGT's; their exact semantics are not in this tree and should be pinned against Robocode
+source before porting (they are used by the enemy-movement feature, so they affect movement).
+
+### 3.3 `static` mutable state — **~68 non-final static fields; 27 in movement** `[MEASURED]`
+
+`static final` primitives (e.g. `DrussMoveGT.VCS`, `DrussMoveGT.WALKING_STICK`, `WALL_MARGIN`,
+`WALL_STICK`, `EnemyWave.BINS`, `EnergyDomeWorker.OPTIONS`) are harmless constants. The hazard is the
+**non-final static** fields, which are shared across instances and have initialisation-order issues:
+
+`DrussMoveGT.java` (27 fields):
+- 4 buffer lists: `statBuffers:19`, `flattenerBuffers:20`, `ABSBuffers:21`, `flattenerTickBuffers:22`
+- 4 KD-trees: `surfBufferTree:25`, `flatBufferTree:26`, `ABSBufferTree:27`, `tickBufferTree:28`
+- 6 scan-history lists: `_distances:36`, `_lateralVelocitys:37`, `_advancingVelocitys:38`,
+  `_flattenerTickWaves:41`, `_surfDirections:42`, `_surfAbsBearings:43`
+- scalars: `BULLET_POWER:45`, `lateralDirection:47`, `_fieldRect:58`, `WALL_STICK:62`,
+  `totalEnemyDamage:64`, `weightedEnemyFirerate`+`weightedEnemyHitrate:65`, `totalMyDamage:66`,
+  `bestDistance:70`, `flattenerEnabled`+`flattenerStarted:71`, `waveCounter:86`
+
+Other files:
+- `DrussGunDC.java`: `dataToLog:16`, `myLocation`+`myNextLocation:19`, `BULLET_POWER:20`,
+  `waveList`+`removeList:24`, `bulletsShot:27`, `bulletsPassed:28`, `bulletsHit:29`,
+  `currentGF:31`, `enemyName:34`, `paintPoints:746`, `DCHits/actualHits/DCASHits:748`,
+  `randomHits:749`, `targetLocation:750`, `targetHeading:751`, `GUN:752`, `heapTree/ASTree:766`,
+  `currentTime:769` (plus mutable `S/W/N/E/HALF_PI/WALL_MARGIN:1294-1299`).
+- `PreciseMinMaxGFs.java`: `MARGIN:11`, `WIDTH:12`, `HEIGHT:13` — note this is **used by movement's
+  enemy model** and hard-codes 800×600 (see §A.3).
+- `EnergyDomeWorker.java`: `optionScores:13`, `offsetCounts:14`, `offsets:15`, `dirOffsets:16`,
+  `unmatchedEnemyDamage:30`, `enemyDamage:31`, `myDamage:32`.
+- `DrussGT.java`: `bulletPowerPredictor:18`, `shieldEnabled:19`.
+- `EnemyMoves.java`: `tree:46`.
+
+Plus **2 `static final` arrays with mutable contents** filled in a static initializer:
+`narrowprofile`/`wideprofile` (`DrussMoveGT.java:1250-1256`). Porting hazard: Nim has no mutable
+global state shared the same way across module instances unless declared `var` at module scope;
+the natural Nim translation is object fields, but then the cross-round persistence that the Java
+relies on (e.g. `statBuffers` populated only when `getRoundNum()==0`, `DrussMoveGT.java:105-129`;
+`statBuffers.clear()` at end of match, `DrussMoveGT.java:660-663`) must be explicitly modelled.
+Initialisation order matters: `surfBufferTree`/`flatBufferTree` etc. are initialised at class-load
+time *before* the constructor runs (`DrussMoveGT.java:25-28`).
+
+### 3.4 Lookup-table / approximate math — **`FastTrig` is NOT a table; `BufferManager` is** `[MEASURED]`
+
+`jk/math/FastTrig.java` (193 lines) contains **no arrays and no lookup tables**. It is pure
+polynomial approximation:
+- `sin`/`sinInBounds`: degree-13 odd polynomial, coefficients `-2.0534...e-08 … 9.99999707...e-01`
+  (`FastTrig.java:30-46`, `64-73`).
+- `cos`/`cosInBounds`: degree-12 even polynomial (`FastTrig.java:48-62`, `75-87`).
+- `tan`: Chebyshev rational (`FastTrig.java:89-110`).
+- `atan`: Chebyshev on `[0,1]` (`chebyshev_atan`, `FastTrig.java:147-153`), `atan2` built from it
+  (`FastTrig.java:155-180`).
+- `asin = HALF_PI - acos` (`FastTrig.java:121`); `acos` is a cubic sqrt approximation with
+  hard-coded coefficients `a=1.570758334, b=-0.212875075, c=0.076897503, d=-0.020892330`
+  (`FastTrig.java:126-131`).
+- `sqrt` just forwards to `Math.sqrt` (`FastTrig.java:171-173`).
+
+What must be ported **coefficient-exact**: all of the above. Replacing `FastTrig.sin/cos/atan2/asin`
+with `std.math` `sin/cos/arctan2/arcsin` will change the last 6–7 decimal digits and, through the
+`float` bin boundaries of §3.1, occasionally flip a bucket. The tables size is therefore **zero
+arrays**; the "table" is ~30 scalar coefficients. `[EXTERNAL]` `asin` uses the approximated `acos`
+(not libm), so `EnemyWave.maxEscapeAngle()` (`EnemyWave.java:217`) and `smoothWest`/`distanceWest`
+(`DrussMoveGT.java:1954-1986`) inherit that approximation.
+
+The genuine **table-driven** data is in `BufferManager.java`:
+- 22 `static final float[]` slice tables (`BufferManager.java:10-38`), **128 scalar entries**, 147
+  float literals.
+- 4 set-builders (`getStatBuffers:40`, `getFlattenerBuffers:218`, `getABSBuffers:278`,
+  `getFlattenerTickBuffers:317`, plus `putBuffersInto:358`) whose 3-D `float[][][]` literals encode
+  ~**130 + 50 + 30 + 30 = ~240 buffer-set rows** (measured by counting rows starting with `{` in
+  each builder's line range) [MEASURED]. Each row is a 9-slice feature selection; each becomes a
+  `StatBuffer` with a 9-D array of `SingleBuffer`s (`BufferManager.java:541-600`). This is not
+  "approximate math" but it is **hand-tuned data that must be reproduced exactly**, and it is the
+  largest single body of raw transcription in the port (§A.1).
+
+Also table-like: `Scan.location()` / `Scan.ASLocation()` (`DrussMoveGT.java:2252-2281`) and
+`EnemyMoves.Locator.getLocation()` (`EnemyMoves.java:238-253`) contain 10–16 hard-coded feature
+weights; and `narrowprofile`/`wideprofile` are generated (`DrussMoveGT.java:1250-1256`).
+
+### 3.5 Integer arithmetic / bit manipulation — **LOW** `[MEASURED]`
+
+- `>>>` appears exactly **once**: `KDTree.java:545 int index = (i+j) >>> 1;` in the binary search.
+  Operands are non-negative stack indices; `(i+j) shr 1` is faithful. No `<<`, `>>` or `^` anywhere
+  (the only `>>` is commented-out Quake inverse-sqrt at `FastTrig.java:181`).
+- `(int)` casts: **137** [MEASURED], overwhelmingly `(int)Math.round(...)` on bin indices
+  (e.g. `DrussMoveGT.java:1531-1532`, `EnemyWave` factor-index rounding at `DrussMoveGT.java:850`,
+  `BufferManager` indices). Java `Math.round` returns `long`; `(int)` truncates. Nim
+  `int(round(x))` matches for the ranges here. `(long)` casts: 6. `(double)` casts: 6.
+- No integer-overflow-dependent algorithm found (no hashing, no packing). `int` is 32-bit in Java
+  and 64-bit in Nim; the only place width matters is `hits = (hits+1)%bins.length`
+  (`BufferManager.java:535`, tiny) and `bins/hits` bookkeeping — safe.
+- **Non-short-circuit boolean operators**: Java uses single `&` (34 sites) and `|` (11 sites)
+  instead of `&&` (82) / `||` (37). On pure operands these are behaviourally equivalent to Nim
+  `and`/`or`, but **4 sites carry a side effect in the right operand**, where Nim's short-circuit
+  `and` would change behaviour:
+  - `MovePredictor.java:175` `… & --counter != 0;`
+  - `MovePredictor.java:179` `… & --counter != 0;`
+  - `DrussMoveGT.java:1807` `… & count-- > 0);`
+  - `DrussMoveGT.java:1813` `… & count-- > 0);`
+  These must be rewritten (evaluate the decrement unconditionally, then combine) — a classic
+  Java→Nim trap. (`MovePredictor.java:100` and `PreciseMinMaxGFs.java:117,175` use `&&` with a
+  side effect and are therefore *correctly* short-circuit; do not "fix" those.)
+
+### 3.6 Java library dependencies requiring real work `[MEASURED]`
+
+- **Collections**: `ArrayList` × 136 occurrences — by far the main one, maps to `seq[T]`. No
+  `HashMap`/`TreeMap`/`HashSet`/`TreeSet`/`LinkedList` at all. `Hashtable` × 2 and `Vector` × 1
+  only: `MeleeRadar.java:13` (`Hashtable<String,EnemyInfo>`) and `DrussMoveGT.java:698`
+  (`bot.getAllEvents()` on death).
+- **Sorting/comparators**: `Collections.sort` × 2 (`DrussMoveGT.java:1169` with `TimeComparator`,
+  `:1349` on `PlaceTime implements Comparable`). `Comparable` implementations: `PlaceTime`,
+  `GFRange`, `Indice`, `NormalDistribution` (plus the duplicate `GFRange.java`/`Indice.java`).
+  `Comparator`: `DrussMoveGT.TimeComparator` (`DrussMoveGT.java:1152`), which casts
+  `KDTree.SearchResult` payloads. `Arrays.*`: 6 (`KDTree` fill/copy, `DrussGunDC:1044 Arrays.sort`,
+  `EnergyDomeWorker:64 Arrays.toString`).
+- **Iterators**: `Iterator` × 12, `Enumeration` × 1 (`MeleeRadar.java:45`). All become `for` loops.
+- **Anonymous classes / lambdas: ZERO.** `grep` for `new X(){`, `->`, `::` found none (the only
+  `->` is inside a comment at `KDTree.java:527`). This removes the usual Nim closure/`proc`-object
+  rewrite burden. The only inner types are named static/non-static classes
+  (`TimeComparator`, `Scan`, `PointChain`, `Locator`, `EnemyInfo`, `DetectWave`,
+  `SingleBuffer`, `StatBuffer`, `SearchResult`, `Node`, `PrioQueue`, etc.), each a plain `object`.
+- **Boxed generics**: the movement's scan history uses untyped `ArrayList` holding
+  `Integer`/`Double` (`_surfDirections`, `_lateralVelocitys`, `_advancingVelocitys`,
+  `_distances` — `DrussMoveGT.java:36-43`, accessed with `.intValue()`/`.doubleValue()` and cast),
+  and `BulletPowerPredictor` uses `KDTree<Float>`. These need concrete `seq[int]`/`seq[float]`/
+  `seq[float32]` in Nim. `KDTree` is generic (`KDTree<T>`); Nim generics cover it.
+- **`java.awt.geom`**: `Point2D` × 268, `Rectangle2D` × 7. Movement uses `Point2D.Double` as its
+  universal 2-D point (`DrussMoveGT.project`, `_myLocation`, `_enemyLocation`, `PlaceTime.place`,
+  `PredictionStatus.endPoint`, …) and `Rectangle2D.Double` for `_fieldRect.contains`
+  (`DrussMoveGT.java:58`, `1510`, `1805`). A Nim `Vec2`/`(x,y: float)` plus a `contains` helper is
+  a mechanical replacement. `Graphics2D`/`Color` appear only in `onPaint` (`DrussMoveGT.java:2030`,
+  157 lines; `DrussGunDC.java:477`; `MeleeRadar`), which can be dropped for a headless port.
+- **`java.io`**: only two sites, both best-effort diagnostics — `DrussGT.contain()` writes
+  `getDataFile((int)(Math.random()*100)+".error")` via `RobocodeFileOutputStream`
+  (`DrussGT.java:259`), and `DrussGunDC` has a `PrintStream`/`RobocodeFileOutputStream` logger
+  gated by `final static boolean logData = false` (`DrussGunDC.java:15, 565-567`). **No learned
+  data is persisted between battles** — the bot relearns every match. Persistence is effectively a
+  no-op for a port; skip it. No `Serializable`.
+- **Randomness**: `Math.random()` in `Insulter` (3×) and the error-file name
+  (`DrussGT.java:259`); `Math.random()` in the gun's random shot (`DrussGunDC.java:1148`). Movement
+  has no RNG. Port with `std/random`.
+
+### 3.7 Infeasibility blockers — **none found** `[MEASURED]`
+
+- **Reflection / dynamic class loading / JNI / `System.load` / serialization: none.**
+  `grep -rnE 'Class.forName|getDeclared|getMethod|reflect|\bnative\b|System\.load|Runtime\.'` → 0.
+- **Threads/concurrency: none real.** The only match is `Thread.sleep(0,1000)` in the main loop
+  (`DrussGT.java:79`) — a classic-Robocode pacing/busy-wait idiom to let the engine deliver events,
+  not a worker thread. No `synchronized`.
+- **`SkippedTurnEvent`**: overridden once (`DrussMoveGT.java:717`) and only `System.out.println`s
+  timing. It is **not** used to make decisions. Engine no longer emits it in modern Robocode anyway.
+- **Undocumented engine internals: none.** Movement only uses the documented `AdvancedRobot` API.
+- **Engine-timing semantics that DO matter** (MEDIUM): `bot.getTime()` as an absolute tick
+  (`DrussMoveGT.java:698,717,757,1291,1321…`), `bot.getGunCoolingRate()` (used to track enemy gun
+  heat: `DrussMoveGT.java:156-157,203-204,304,309,426,680`; classic value is 0.1 — the harness
+  `gunheat_tracker.nim` already hard-codes `GunCoolingRate = 0.1`), `bot.getOthers()`
+  (`DrussMoveGT.java:149,680,789,809,…`) and `ScannedRobotEvent` delivery order. These are
+  mappable to `WorldState` / a hard-coded cooling rate, but they are the reason a *bit-exact*
+  trajectory match is impossible (see §C).
+
+### 3.8 The 10 largest methods `[MEASURED]`
+
+Measured with a brace-matching script (`/tmp/portaudit/methods.py`), sorted by body line count:
+
+| # | Lines | file:line | Method | What it is |
+|---:|---:|---|---|---|
+| 1 | 234 | `DrussMoveGT.java:1258` | `getBestPoint(EnemyWave,EnemyWave,EnemyWave)` | **Algorithmic core**: builds danger bins, predicts safe points for up to 3 waves, scores/sorts them, picks the safest. |
+| 2 | 224 | `EnergyDomeWorker.java:85` | `onScannedRobot(ScannedRobotEvent)` | Shield subsystem (optional, not movement). |
+| 3 | 178 | `BufferManager.java:40` | `getStatBuffers()` | **Data table** — ~130 hand-written 9-slice buffer sets. |
+| 4 | 155 | `DrussMoveGT.java:2030` | `onPaint(Graphics2D)` | Debug drawing — **droppable**. |
+| 5 | 132 | `DrussGunDC.java:787` | `test(…)` | Gun wave scoring / virtual-bullet resolution. |
+| 6 | 130 | `DrussMoveGT.java:420` | `addWave(double)` | Build wave from energy drop; compute the 9 KNN features; fetch stats. |
+| 7 | 116 | `DrussMoveGT.java:303` | `addImaginaryWave()` | Same features for a predicted enemy shot. |
+| 8 | 103 | `DrussMoveGT.java:550` | `addFlattenerTickWave()` | Same features for the "flattener" anti-pattern-matcher. |
+| 9 | 98 | `DrussGunDC.java:968` | `getBearing(KDTree,…)` | Gun KNN density peak (gun core). |
+| 10 | 94 | `BufferManager.java:358` | `putBuffersInto(float[][][],ArrayList)` | Data-table → `StatBuffer` construction. |
+
+**The algorithmic core is `DrussMoveGT.getBestPoint` + the wave/feature pipeline
+(`addWave`/`addImaginaryWave`/`addFlattenerTickWave`) + `getBins`/`getDanger`/`predictPositions`.**
+Note `addWave`, `addImaginaryWave` and `addFlattenerTickWave` are near-duplicates of the same ~100
+lines of feature extraction (a candidate for de-duplication in the port, but de-duplication must
+preserve the tiny differences: `addWave` indexes history at offset 2, `addImaginaryWave` at offset 0,
+`addFlattenerTickWave` at offset 2 with `flattenerStarted` gating).
+
+---
+
+## Deliverable A — the movement subsystem, precisely scoped
+
+### A.0 The ACTUAL harness interface `[MEASURED]`
+
+**`common_libs/movement_harness/movement_interface.nim:8-20`** (quoted verbatim):
+
+```nim
+type
+  MoveCommand* = tuple[speed: float, turnRate: float]
+    ## speed: target speed in px/tick, clamped to ±8 by bot API
+    ## turnRate: body turn rate in degrees/tick
+
+## MovementModule concept — any type T implementing computeMove is valid.
+template isMovementModule*(T: typedesc): bool =
+  compiles(
+    block:
+      var m: T
+      let ws = WorldState()
+      let cmd: MoveCommand = m.computeMove(ws)
+  )
+```
+
+`WorldState` is defined in **`common_libs/gun_harness/gun_interface.nim:12-31`** (the movement
+harness re-exports it: `export gun_interface.WorldState`):
+
+```nim
+type
+  EnemyInfo* = object
+    id*:                      int
+    x*, y*:                   float
+    heading*, speed*, energy*: float
+
+  WorldState* = object
+    enemyX*, enemyY*:         float
+    enemySpeed*, enemyHeading*: float
+    selfX*, selfY*:           float
+    selfSpeed*, selfHeading*: float
+    selfRadarHeading*:        float
+    selfEnergy*:              float
+    enemyEnergy*:             float
+    arenaWidth*, arenaHeight*: float
+    tick*:                    int
+    enemies*:                 seq[EnemyInfo]
+```
+
+A movement module is therefore a type with `proc computeMove*(m: var T, ws: WorldState): MoveCommand`.
+By convention the real modules also expose `initX*()`, `resetRound*(m)`, `clearGraphics*(m)`, and
+`removeBulletNear*(m, x, y)` (e.g. `common_libs/movements/the_floor_is_lava.nim:76-105`,
+`phantom_meteor.nim:194-197`), and `ModularBot_garage/src/ModularBot.nim:545-548` calls
+`computeMove` every tick and routes `onHitByBullet` into a separate `VirtualBodyTracker`
+(`ModularBot.nim:296-309`), **not** into the movement module. Note the harness's own physics
+(`common_libs/movement_harness/virtual_bodies.nim:75-90`) uses Tank Royale
+`maxTurn = 10 - 0.75*|speed|`, speed ramp ±1, clamp to arena.
+
+### A.1 (a) Exact file list for a movement-only port
+
+Mandatory set (transitive closure of `DrussMoveGT`'s dependencies), measured LOC:
+
+| File | Lines | Difficulty | Why it is needed |
+|---|---:|---|---|
+| `jk/mega/dMove/DrussMoveGT.java` | 2283 (2126 excl. `onPaint`) | **Very hard** | The movement core. |
+| `jk/mega/BufferManager.java` | 652 | Medium (mechanical) + hard index logic | Stat/flattener/ABS/tick buffers + slice tables. |
+| `jk/tree/KDTree.java` | 617 | Hard | Used by `EnemyMoves` **and** `BulletPowerPredictor`. Generic; exact split/tie behaviour. |
+| `jk/mega/dGun/PreciseMinMaxGFs.java` | 266 | Medium-hard | **In a gun package but required by movement**: `EnemyMoves` calls `getPreciseMEAs` (`EnemyMoves.java:94`). Three mini-simulators. |
+| `jk/mega/EnemyMoves.java` | 264 | Hard | Enemy movement predictor (KD-tree of `PointChain`s). |
+| `jk/mega/dMove/EnemyWave.java` | 236 | Medium-hard | Wave + `binCleared` shadows + `getFactorIndex`. |
+| `jk/mega/dMove/MovePredictor.java` | 228 | Medium-hard | Our own tick simulator + classic `getNewVelocity`. |
+| `jk/math/FastTrig.java` | 193 | Easy (must be exact) | All trig for movement. |
+| `jk/precise/util/PreciseUtils.java` | 155 | Medium | Circle/line intersection used by `EnemyWave.logShadow` / `MovePredictor`. |
+| `jk/mega/BulletPowerPredictor.java` | 50 | Easy-medium | Predict enemy bullet power (KD-tree KNN). |
+| `jk/mega/dMove/PredictionStatus.java` | 27 | Trivial | Result struct. |
+| `jk/mega/dMove/PlaceTime.java` | 18 | Trivial | (place,time,danger) struct, `Comparable`. |
+| `jk/mega/dMove/BulletTracker.java` | 12 | Trivial | Our-bullet tracking. |
+| `jk/precise/util/PreciseWave.java` | 6 | Trivial | Struct. |
+| **Mandatory total** | **5007** | | |
+
+Optional / droppable:
+- `jk/mega/DataToGun.java` (11) — only needed if `getGunInfo()` is kept (it exports to the gun).
+- `jk/mega/Insulter.java` (162) — cosmetic taunt at end of round.
+- `DrussMoveGT.onPaint` (157 lines) — headless port can drop it.
+- `Scan` class (84 lines, end of `DrussMoveGT.java`) — **dead under `VCS=true`** (`DrussMoveGT.java:17`).
+
+`static final boolean VCS = true` (`DrussMoveGT.java:17`) means the **entire KD-tree surf path is
+dead**: `getBins` uses `extractIntoBins(wave.allStats, …)` (`DrussMoveGT.java:1199-1201`) and never
+`surfBufferTree`. But `KDTree` is still required because `EnemyMoves` (`EnemyMoves.java:46`) and
+`BulletPowerPredictor` (`BulletPowerPredictor.java:6`) use it. A port could substitute a brute-force
+KNN for `BulletPowerPredictor` (50 lines, tiny tree) but **should not** for `EnemyMoves`, whose
+prediction quality depends on nearest-neighbour selection over motion chains.
+
+### A.2 (b) Gap analysis — what the harness does NOT provide
+
+DrussGT's movement is written against `AdvancedRobot` and consumes data the `WorldState`/`MoveCommand`
+interface does not carry. Concretely:
+
+| DrussGT expects | Source witness | Harness status | Impact / workaround |
+|---|---|---|---|
+| `setAhead(distance)` + `setTurnRightRadians(angle)` | `DrussMoveGT.java:1821` (`doSurfing` fallback), `1872-1873` (`goTo`) | Harness wants `(speed, turnRate)` | **Physics-model mismatch.** Must convert desired heading/distance to speed+turn (and the port's own predictor uses classic accel=1/decel=2, `DrussMoveGT.java:1075`; harness `virtual_bodies` ramps ±1). |
+| `bot.getDistanceRemaining()` | `DrussMoveGT.java:1291` (`now.distanceRemaining = …`) and `goTo` terminal logic `1836-1852` | **Absent** | Cannot faithfully seed `PredictionStatus.distanceRemaining` from tick-driven `WorldState`. Either track remaining ourselves from `MoveCommand` or approximate. |
+| `bot.getGunCoolingRate()` / `getGunHeat()` | `DrussMoveGT.java:156-157,186,203-204,309,426` | **Absent** | Hard-code 0.1 (matches harness `gunheat_tracker.GunCoolingRate`). `getGunHeat()` only used to init on first scan (`:186`); fake with `3.0`. |
+| `bot.getOthers()` | `DrussMoveGT.java:149,680,789,809,758` | `ws.enemies.len` | Direct. |
+| `bot.getRoundNum()` / `getNumRounds()` | `DrussMoveGT.java:98,105,223,229,237,654` | **Absent** | Used for flattener gating + round-0 buffer init. Add `round`/`numRounds` to `WorldState` or a module-level counter. |
+| `ScannedRobotEvent` (bearing, distance, heading, velocity, energy, name) | `DrussMoveGT.onScannedRobot`, `EnemyMoves.onScannedRobot` | `WorldState` has the fields but **event-driven scan cadence is gone** | DrussGT creates waves/features *per scan*; the harness calls `computeMove` *per tick*. The port must decide when a "new scan" happened (e.g. on enemy state change). |
+| `HitByBulletEvent`, `BulletHitBulletEvent`, `BulletHitEvent`, `HitRobotEvent`, `RobotDeathEvent` | `DrussMoveGT.java:667-722`, `935-1030` | **Not passed to `computeMove` at all** | **Biggest gap.** Danger bins only improve when `logHit`/`logFlattener`/`logABS` fire (`DrussMoveGT.java:860-928`). Without hit-event routing the KNN never learns and the surfer degenerates to its priors. Requires harness extension (route hit events into the module) or a new optional `onHit*` on the module concept. |
+| our fired `Bullet` objects (`getX/Y/HeadingRadians/Velocity/isActive`) | `DrussMoveGT.java:287-300, 731-745, 859-905` | `movement_harness/bullet_shadows.nim` exists but is **harness-internal** (`ShadowTracker`), not given to modules | Bullet-shadow ("flattener"/ABS) features need our bullet trajectories. `flattenerStarted` only turns on once enemy hit-rate >8-9% (`DrussMoveGT.java:229-239`), so **a first port can run with `flattenerStarted=false` and skip shadows**. |
+| `bot.getAllEvents()` | `DrussMoveGT.java:698` (`onDeath`) | Absent | Cosmetic (replays `HitByBulletEvent`s into `onHitByBullet`). Can call the same handler directly. |
+| `bot.getBattleFieldWidth/Height()` | `DrussMoveGT.java:128-129` | `ws.arenaWidth/Height` | Direct. |
+| `e.getBearingRadians()/getHeadingRadians()` | `DrussMoveGT.java:190-214` | `ws.enemy*` gives absolute x/y/heading | Derivable, but **bearing sign conventions differ** (classic 0=N clockwise vs Tank Royale 0=E CCW) — the capture tooling already documents the exact conversion (`tools/fixtures/DRUSSGT_FIXTURES.md`). |
+| enemy gun-heat model + `BulletPowerPredictor` | `DrussMoveGT.java:303-361` | none | Must be ported (it is inside movement). |
+
+Additional **hard-coded-arena** hazard inside the would-be movement dependency: `PreciseMinMaxGFs`
+uses `static double MARGIN=18, WIDTH=800, HEIGHT=600` (`PreciseMinMaxGFs.java:11-13`) and never
+updates them, while `DrussMoveGT._fieldRect` is rebuilt for the real field size
+(`DrussMoveGT.java:128`). For a Tank Royale port the 800×600 assumption must be parameterised.
+
+### A.3 (c) Can the movement work WITHOUT porting the gun? — **YES** `[MEASURED]`
+
+Direction of data flow is one-way: `DrussMoveGT.getGunInfo()` (`DrussMoveGT.java:249-286`) builds a
+`DataToGun` (our safest future point/heading/velocity/time) and hands it to `DrussGunDC`. The gun
+*consumes* movement output; movement never consumes gun output. Verified: the only `dGun` references
+inside movement are `DataToGun` (a plain struct, `DataToGun.java`) and `PreciseMinMaxGFs`
+(geometry), per the grep in §1.
+
+The movement **does** predict:
+1. **Enemy bullet power** (`bpp.predictBulletPower`, `DrussMoveGT.java:281,307,556`) — via its own
+   `BulletPowerPredictor` (KD-tree over `[myEnergy, enemyEnergy, distance]`), not the gun.
+2. **Enemy movement** (`EnemyMoves.predict`, `DrussMoveGT.java:221,1287`) — via its own KD-tree of
+   observed motion chains.
+3. **Enemy bullet danger (GF histogram)** — learned from our own hit events, not from the gun.
+
+It does **not** predict the enemy's gun bearing directly; that is the gun's job and is irrelevant
+to evasion. So a standalone movement module is coherent **provided hit events and (optionally) our
+bullet tracks are routed to it** (§A.2). A first, reduced version can run with flattener/ABS waves
+disabled (`flattenerStarted=false`) and still be a genuine wave surfer.
+
+---
+
+## Deliverable B — defensible effort estimate
+
+**Estimation basis.** All "L" figures are **measured Java LOC** [MEASURED] from §1. The "Nim LOC to
+write" and durations are `[ESTIMATE]` derived from the Java LOC with an explicit, stated
+Nim-expansion factor. Basis for the factor:
+- The repo already contains a *reduced* KNN port of the DC gun: `common_libs/guns/knn_gun.nim` is
+  **305 lines** and its header explicitly says it is "inspired by DrussGT's DC gun"
+  (`knn_gun.nim:1`) with "Inverse-distance weights, Gaussian (same as DrussGT getBearingGaussian)"
+  (`knn_gun.nim:242`). Full `DrussGunDC` is 1352 Java lines, i.e. the existing partial port is
+  ≈23% of a full one. This is direct evidence that 1 Java line does **not** shrink dramatically in
+  Nim, and that feature/table transcription dominates.
+- Nim is generally *more* verbose than Java for: generic containers, `Comparable`/`Comparator`
+  (→ `sort` with a closure or `system.cmp`), and object construction.
+- Conversely Nim removes: getters/setters, boxed generics, `Iterator` boilerplate, `Class` casts.
+
+I use a **Nim LOC ≈ 0.85–1.15 × Java LOC** for the algorithmic code, and note that the
+`BufferManager` data tables transcribe ~1:1 (they are data). Therefore Nim LOC ranges below are
+roughly the Java LOC; the effort is dominated by *fidelity review*, not typing.
+
+Subsystems (measured Java LOC → `[ESTIMATE]` Nim LOC / effort):
+
+| Subsystem | Measured Java LOC | `[ESTIMATE]` Nim LOC | Kind of work | Risk |
+|---|---:|---:|---|---|
+| **Utils** (`FastTrig`, `KDTree`, `PreciseUtils`, `PreciseWave`) | 971 | 900–1100 | Coefficient-exact trig; generic KD-tree; circle/line intersection. Pure, unit-testable. | High (exactness) |
+| **Movement** (`DrussMoveGT` core + `EnemyWave` + `MovePredictor` + structs) | 2804 (2647 excl. paint) | 2600–3200 | The heart: wave pipeline, danger scoring, wall-smoothing, 3-wave lookahead, classic velocity rules. | Very high |
+| **Enemy-modeling** (`EnemyMoves`, `BufferManager`, `BulletPowerPredictor`) | 966 | 1000–1300 | KD-tree motion chains; ~240 hand-copied buffer sets × 9 slices; power KNN. Mostly transcription + index correctness. | High |
+| **Movement package extras** (`PreciseMinMaxGFs`) | 266 | 250–350 | Three mini-simulators for precise MEA; used by enemy model. | Medium |
+| **Gun** (`DrussGunDC` + inline `DCWave`/`StoreScan`/`JKDCUtils`/`NormDist`) | 1352 (+ ~5 classes that only exist as `.class`) | 1400–2000 | KD-tree of scans, MEA geometry, virtual-bullet scoring, DC/DCAS/random selection. Movement can be ported first. | Very high (and source-incomplete) |
+| **Radar** (`MeleeRadar`) | 94 | 90–140 | Trivial state machine + melee scan. | Low |
+| **Persistence** (error log + gun logger) | ~10 active | 0–40 | Skip (best-effort diagnostics; `logData=false`). | None |
+| **Shield** (`EnergyDomeWorker`) | 462 | 500–700 | Optional subsystem; not needed for the movement target. | Medium |
+| **Cosmetic** (`Insulter`, `DataToGun`) | 173 | 100–160 | Optional. | None |
+
+**Movement-only first milestone: `[ESTIMATE]` ≈ 4,800–6,100 Nim LOC** across the 14 mandatory
+files, plus the harness extension for hit-event routing. **`[ESTIMATE]` elapsed: 4–8 focused
+agent-days** for "compiles and runs a battle", of which at least half is fidelity review of the
+`float`/table/index logic (not typing).
+
+### Shortest path to a **first compiling version**
+
+1. **`FastTrig`** (193) — standalone, no deps.
+2. **`KDTree`** (617) — standalone generic; port `Manhattan`/`Euclidean`, `addPoint`,
+   `nearestNeighbours`.
+3. **`BufferManager`** (652) — pure data + index math; depends on nothing but `ArrayList`.
+4. **`BulletPowerPredictor`** (50) — depends on `KDTree`.
+5. **`PreciseUtils` + `PreciseWave`** (161) — pure geometry.
+6. **`EnemyMoves`** (264) — depends on `KDTree`, `FastTrig`, `PreciseMinMaxGFs`.
+7. **`PreciseMinMaxGFs`** (266) — depends on `FastTrig`.
+8. **Structs**: `PlaceTime`, `PredictionStatus`, `BulletTracker`, `DataToGun` (68).
+9. **`EnemyWave`** (236) — depends on `PreciseUtils`, `FastTrig`.
+10. **`MovePredictor`** (228) — depends on `PreciseUtils`, `FastTrig`.
+11. **`DrussMoveGT`** (2283) — the big one; stitch it all, replace `AdvancedRobot` calls with
+    `WorldState`, drop `onPaint`, drop `Scan` (VCS path).
+12. **Adapter module** implementing `computeMove*(m: var DrussMove, ws: WorldState): MoveCommand`,
+    mapping DrussGT's chosen `(heading, distance)` to `(speed, turnRate)`.
+13. **Harness extension**: feed `HitByBullet` (and optionally our-bullet) events to the module.
+
+At step 13 this *compiles and moves*, but the danger bins are untrained until events are routed.
+
+### Shortest path to a **first behaviourally-debugged version**
+
+After the above, in order of value:
+1. **Golden-value tests** for `FastTrig` (all functions on a grid, values captured from Java),
+   `normalRelativeAngle`/`normalAbsoluteAngle`, and `EnemyWave.getFactorIndex`/`maxEscapeAngle`.
+2. **Golden-value tests** for `BufferManager.getIndex`/`getIndexes`/`extractIntoBins` against
+   captured Java outputs on a fixed input vector.
+3. **Golden-value tests** for `DrussMoveGT.getDanger`/`getBins` on captured `EnemyWave` state.
+4. **Replay test** using the already-captured fixtures (`tools/fixtures/drussgt_*.jsonl`): feed
+   recorded per-tick `WorldState` into the port and compare the chosen movement direction and
+   (if the gun is later ported) gun angle within tolerance.
+5. **Full battle**: run the ported module in `ModularBot` and compare win rate / hit-rate against
+   the baseline surfer (`wave_surfer.nim`), accepting that trajectories diverge.
+
+Steps 1–3 are cheap and are where the porting traps are caught; step 4 is the strongest feasible
+validation; step 5 only sanity-checks.
+
+---
+
+## Deliverable C — validation strategy
+
+**The fundamental problem is real and cannot be engineered away:** classic Robocode and Tank Royale
+run different physics and tick pipelines, so once the port is dropped into a Tank Royale battle its
+trajectory diverges from the original after the first decision, no matter how faithful the code.
+Comparing *trajectories* is therefore invalid; only comparing *decisions given identical inputs*
+(or comparing pure-function outputs) is meaningful. Evaluating the three options:
+
+### (i) Faithful classic-Robocode physics/replay simulator in Nim
+Build a simulator that reproduces classic Robocode turning/acceleration and feeds the port the same
+per-tick state as the original. Compare decisions (heading, dodge direction, gun angle within X°).
+- **Cost: HIGH.** Classic physics is *distance-based* (`setAhead`), with decel=2 / accel=1
+  (`DrussMoveGT.java:1075`), and the predictor already encodes it; but building a simulator that
+  matches the engine's event ordering (scan cadence, bullet resolution, winner tie-breaks) is a
+  large project in itself. The repo's `virtual_bodies.nim` is **Tank Royale** physics, not classic,
+  so it cannot be reused as-is.
+- **Trustworthiness: HIGHEST** *if* the simulator is itself correct; otherwise it launders
+  simulator bugs as port bugs.
+
+### (ii) Unit-test individual pure functions against captured Java outputs
+Capture outputs from a running, instrumented Java DrussGT for: `FastTrig.*`,
+`normalRelativeAngle`/`normalAbsoluteAngle`, `BufferManager.getIndex(es)`,
+`extractIntoBins`, `EnemyWave.getFactorIndex`/`maxEscapeAngle`/`getDanger`, `DrussMoveGT.getBins`,
+and the `MovePredictor` tick loop. Freeze them as golden values; assert the Nim port matches exactly
+(or within a documented epsilon for float32).
+- **Cost: LOW.** The hard part — running classic Robocode headlessly — **is already solved in this
+  repo**: `tools/robocode_fixture_capture/Capture.java` + `capture.sh` run classic Robocode 1.9.5.5
+  headlessly and dump per-turn JSONL (`tools/fixtures/DRUSSGT_FIXTURES.md`). An instrumented
+  DrussGT can be compiled against the same install to emit intermediate values.
+- **Trustworthiness: HIGH for the traps** (float32 rounding, bin boundaries, polynomial coeffs,
+  angle normalisation), **LOW for end-to-end behaviour** (it cannot tell you whether the *surfing
+  policy* is right, only that the sub-computations are right).
+
+### (iii) Accept no validation; judge only by win rate
+- **Cost: LOWEST to start.** Run the ported module in `ModularBot` and compare win rate against
+  `wave_surfer.nim`/`the_floor_is_lava.nim`.
+- **Trustworthiness: LOWEST.** A win-rate result cannot distinguish "faithful port" from "different
+  bot that happens to surf", and Tank Royale opponents differ from classic ones. It is a
+  *product* metric, not a *fidelity* metric.
+
+### Recommendation
+**Hybrid, in this order: (ii) first, then a decision-replay harness that is "half of (i)".**
+
+1. **Primary = option (ii), golden-value tests.** It is the cheapest, directly targets the
+   measured fidelity traps (`float32`, table indices, polynomial coefficients, floor-based angle
+   normalisation), and the Java-side capture infrastructure already exists. Requires compiling an
+   *instrumented copy* of DrussGT (print/trap the intermediate values) against `/tmp/robocode/install`.
+2. **Secondary = decision replay on the existing fixtures.** `tools/fixtures/drussgt_*.jsonl`
+   already record true per-tick state (position/heading/speed/energy) for real DrussGT vs
+   SpinBot/RamFire/Crazy/Corners/DrussGT. Extend the capture to also log **DrussGT's own decisions**
+   (chosen move direction / ahead distance) and **enemy bullet fire + hit events**, then drive the
+   Nim port tick-by-tick from the recorded state and compare decisions. This exercises the whole
+   policy without needing a physics simulator, because positions are recorded. This is the most
+   trustworthy feasible end-to-end check and is far cheaper than a full simulator.
+3. **Do not build full option (i) unless a physics bug is suspected** — it is the only path to
+   *trajectory* matching, but the stated premise (different engines) means trajectory matching is
+   not the goal.
+4. **Use option (iii) only as a final smoke test**, never as evidence of fidelity.
+
+**Cheapest: (iii) < (ii) < (i). Most trustworthy: (i) > (ii) > (iii). Recommended: (ii) + fixture
+replay, ≈80–90% of (i)'s trustworthiness at a small fraction of its cost.**
+
+---
+
+## Deliverable D — a smaller first target
+
+The goal is to shake out the Java→Nim traps (float32, `%`-on-negatives, float-vs-int, collections)
+before touching DrussGT's 5007-line movement.
+
+**Availability note.** I could not verify new downloads (no network per task constraints). However,
+the *locally present* classic Robocode install (`/tmp/robocode/install/robots/`, listed read-only)
+contains the full official sample-bot source set. Measured:
+
+| Candidate (locally available, `[MEASURED]` LOC) | float | `%` | collections | Exercises |
+|---|---:|---:|---|---|
+| `samplesentry/BorderGuard.java` (716) | 0 | 4† | `LinkedHashMap`, `ArrayList`, `Iterator`, `Point2D`, `Math.sqrt` quadratic | collections, generics, `Utils.normalRelativeAngle`, engine API mapping |
+| `sample/Walls.java` (94) | 0 | 1 (`getHeading()%90`) | 0 | `%` on degrees (non-negative), wall geometry |
+| `sample/Corners.java` (140) | 0 | 0 | 0 | `Utils.normalRelativeAngleDegrees` |
+| `sample/Crazy.java` (103), `RamFire.java` (86), `SpinBot.java` (70) | 0 | 0 | 0 | movement patterns / physics |
+
+† BorderGuard's four `%` matches are `Color(0x00,0xFF,…)` alpha bytes, not modulo; only
+`Walls.java:50` is a real modulo. **None of the locally available samples uses `float` at all**, so
+none exercises the single biggest DrussGT trap.
+
+**Recommendation.**
+1. **Immediate canary: `samplesentry/BorderGuard.java` (716 lines).** It is small, locally
+   available, and exercises the *collection / generics / engine-API-mapping* traps end to end
+   (`LinkedHashMap` with access-order LRU, `ArrayList`, `Iterator`, `Point2D`, `Math.sqrt`
+   quadratic, `Utils.normalRelativeAngle`). It deliberately does **not** cover float32.
+2. **For float32 specifically, do not rely on a found bot — build the fixture first.** Use the
+   existing `tools/robocode_fixture_capture/` infrastructure to instrument a tiny Java class and
+   capture `float` arithmetic outputs (e.g. the exact Java result of
+   `(20-3*1.9)`-style computations and `FastTrig` on a grid), then port the *pure functions*
+   (`FastTrig`, angle normalisation, `BufferManager.getIndex`) and assert equality. This converts
+   the float32 risk into a mechanical, testable diff and is cheaper than acquiring a third-party
+   wave-surfer.
+3. **If a genuine small wave-surfer is to be used as the canary**, it must meet these criteria
+   (I cannot verify availability of a specific one offline):
+   - Single-threaded, plain Java, **no reflection / JNI / dynamic loading**;
+   - ≤ ~1500 LOC and ≤ ~10 source files;
+   - **uses `float`** (KNN/neural/buffer bots do; simple pattern-matchers do not);
+   - contains `%` on a value that can be **negative** (angle normalisation) — this is the trap the
+     samples miss entirely;
+   - uses at least one non-trivial collection (`ArrayList`/`HashMap`) and a `Comparable`/`Comparator`;
+   - consumes `ScannedRobotEvent` + `HitByBulletEvent` so the event-routing gap is surfaced early;
+   - source obtainable under a redistributable licence (the Robocode archive bots are third-party —
+     keep the source out of the repo as `tools/fixtures/DRUSSGT_FIXTURES.md` already does for the jar).
+
+---
+
+## Bottom line for the orchestrator
+
+- **Hazard counts:** 193 `float` occurrences / 35 casts / 147 float literals / 60 `float[]` in the
+  movement dependency closure; **0 `%`-on-negative** sites (angle normalisation is already
+  floor-based); **~68 static non-final fields** (27 in `DrussMoveGT`); **no infeasibility blockers**
+  (no reflection/threads/JNI/lambdas/anonymous classes/serialization). The real risks are float32
+  fidelity, coefficient-exact `FastTrig`, and ~240 hand-written buffer-table rows.
+- **Movement scoping:** mandatory **5007 Java LOC** across 14 files (`DrussMoveGT` 2283 →
+  `BufferManager` 652 → `KDTree` 617 → `PreciseMinMaxGFs` 266 → `EnemyMoves` 264 → `EnemyWave` 236
+  → `MovePredictor` 228 → `FastTrig` 193 → `PreciseUtils` 155 → `BulletPowerPredictor` 50 → four
+  structs), interface = `computeMove(m: var T, ws: WorldState): MoveCommand`. **Movement can be
+  ported without the gun** (data flows movement→gun only). The critical missing harness piece is
+  **hit-event routing into the module**; the missing state is `getDistanceRemaining`/`getGunHeat`/
+  `getRoundNum`, all approximable.
+- **Effort:** `[ESTIMATE]` ≈ 4.8k–6.1k Nim LOC for movement-only, 4–8 focused agent-days to
+  first-compiles; gun is a further ≈1.4k–2k LOC and its source is **incomplete** (5 classes exist
+  only as `.class`).
+- **Validation:** cheapest = pure-function golden tests (option ii); most trustworthy = full
+  classic simulator (option i) but cost-prohibitive; **recommended = (ii) golden tests on the traps
+  plus decision-replay of the already-captured `tools/fixtures/` data**.
+- **First bot:** use the locally-available `samplesentry/BorderGuard.java` (716 lines) to shake out
+  collections/engine-mapping, and build float32 fixture tests from the existing capture tooling
+  rather than hunting a small wave-surfer.