# j160 — PRE-REGISTRATION: the energy-reserve ram policy (floor + exhaustion)

**Written and committed BEFORE any battle of this experiment ran. Nothing below
the divider has data in it, and none of it will unless the owner approves.**

## What was built (both default-OFF, both default = today's behaviour)

| knob | default | effect when set |
|---|---|---|
| `TR_RAM_FLOOR_ENERGY` | **0.0 = off** | at/below this self energy we do not start a NEW shot |
| `TR_RAM_ENEMY_ENERGY` | **0.0 = off** | last-scanned enemy energy <= this -> ram mode |

Mechanics that justify the design (all read from source, not assumed):
energy has **no cap and no regeneration**; the only gain in the game is
`+3 * power` per bullet hit **landed** (`server/rules/rules.kt`). Not firing
therefore denies the enemy its only refill *and* preserves our ram reserve —
the floor and the exhaustion trigger are the same bet, not two ideas.

`RAM_DAMAGE 0.6` is applied to **both** bots on every contact tick, so a
head-on contact is a symmetric bleed decided by who entered with the surplus.
The exhaustion trigger deliberately **keeps** the shipped finisher's
`selfEnergy > enemyEnergy` guard for that reason.

**Composition when they conflict: RAMMING WINS.** Once ram mode is engaged the
duel is over and the reserve is being *spent*, not held, so the floor is
bypassed. The floor therefore can never deadlock the ram it exists to enable.
The floor blocks only NEW shots: a bullet already in the air has `gunHeat > 0`
and `shouldFire` already gates on `gunHeat <= 0.0`, so no committed shot is
suppressed or cancelled.

Guards: `common_libs/tests/test_tfil_commit_env.nim` **136 -> 147 checks**, all
green. Eleven new checks cover default parity on both knobs (the exhaustion arm
is unreachable at 0.0 and the old finisher/desperation verdicts are unchanged
over 210 input combinations), the floor firing at exactly the threshold and not
one tick above it, the floor never blocking healthy energy in any configuration,
the trigger switching to ram exactly at the tolerance, and the composition.

## The open-loop measurement (`common_libs/tests/measure_ramfloor_energy`)

Recorded closed-loop corpus, **8149 recordings / 29871 rounds / 33.8M ticks**,
state only, no counterfactual replay (the offline harness scored 0/6 on
closed-loop questions, `docs/offline_harness_trust.md`).

**The owner's premise ("both low, nobody firing") is TRUE and COMMON — but it is
not the situation he thinks it is.** Both bots below 25 energy happens on
**15.1% of ticks**; below 20, **10.4%**; below 10, **2.9%**. Self energy is
below 20 on **23.5%** of ticks with a median continuous run of **131 ticks**.

**Neither side goes low first — it is a coin flip.** The enemy crosses 20 first
in 52.7% of rounds, we do in 47.3%. The premise that the *enemy* is the one
that runs dry is not supported; half the time we are the exhausted one, and
then there is nothing to ram *into* safely.

**The specific trigger the owner described — "so low that it doesn't fire
anywhere more" — is rare.** The server rejects a shot when `energy <= power`, so
a p=1.95 opponent (DrussGT) stops firing below **2.0 energy**: **2.5% of ticks**,
and only **1.1%** while we are healthy. Below 3.0: 3.2%. An exhaustion tolerance
sized to the literal premise (`TR_RAM_ENEMY_ENERGY` ~2) therefore acts on about
1% of ticks.

A looser tolerance is available and is what an A/B would actually sweep:
enemy <= 20 while we are above 20 is **7.1% of ticks**, enemy <= 30 is 13.2%.

Gun-heat note: a 0.1-power shot adds 1.02 heat and the gun cools 0.1/tick, so a
floor suppresses roughly one shot per 11 ticks. This is a *lost opportunity
rate*, not a lost-damage estimate, and no counterfactual damage number is
produced here.

## Arms

Both: `TR_MOVEMENT` pinned, one frozen binary built once from `git archive` of
the j160 branch, per-arm `TR_ENV_FILE` in this job's own outdir, and every
run's `[env]` boot report checked against its arm before any number is read
(same contamination control as j159 — the owner's personal `.env` gives the
FILE priority and would silently void arm A).

| arm | env | role |
|---|---|---|
| `A_off` | both knobs unset | **REFERENCE** — the shipped behaviour |
| `B_floor` | `TR_RAM_FLOOR_ENERGY=5` | the reserve half alone |
| `C_exhaust` | `TR_RAM_ENEMY_ENERGY=20` | the exhaustion half alone |
| `D_both` | `TR_RAM_FLOOR_ENERGY=5 TR_RAM_ENEMY_ENERGY=20` | the owner's full policy |

Four arms, not two, because the two mechanisms are separable: the floor can
plausibly help on its own (it is the only part whose premise the data supports)
while the exhaustion trigger acts on 1-7% of ticks. A two-arm A+B run could not
tell a win from one half.

## Design

* Harness: `tools/ab/tournament_run.sh` + `tools/ab/tournament_analyze.py`,
  unmodified. Panel: `tools/ab/panel_movement.txt`, the frozen 15-opponent
  movement panel. Unit of evidence is the opponent, not the battle.
* 15 opponents x 4 arms x **10 runs** x 3 rounds = **600 battles**, serialised
  (`--wait-arena 45`). ~1.5 h.

### Primary metrics (pre-registered, fixed)

1. **damage/run**
2. **round-win rate**

### Mechanism metrics (reported, never a verdict) — specific to this one

* **self energy at death** (the floor's entire claim is about the reserve we
  hold when it matters);
* **ram-kill count** and ram-contact count (the exhaustion trigger's channel);
* shots fired/run (the floor's direct cost).

### Statistical treatment

Per-opponent paired deltas (arm − reference), mean, SD, SE, 95% CI, sign test,
sign-flip permutation test, Wilcoxon as a cross-check, plus the MDE the
analyzer prints. **Direction is pre-registered as two-sided**: a regression is
as interesting as a win, and the offline literature (`docs/ramming_negative_
result.md`: proactive straight-line ramming converted 0/59) makes a regression
entirely plausible.

### MDE — large, stated now

At **10 runs/arm** the design resolves roughly **0.3 wins/run** and the
corresponding damage/run figure. Resolving 0.1 wins/run would need ~3x the
battles. **A null is the likely outcome — this would be the fifth consecutive
mechanism-positive / outcome-null result in this campaign.**

Consequences recorded before any data:
* a null **excludes only a large effect**; it does not show the knobs do nothing;
* if `B_floor` is null and `C_exhaust` is null, the *pair* still leaves the
  combined policy untested, and `D_both` is the arm that would be shipped.

### Verdict rule (fixed now, not re-read later)

* **Adopt** only if BOTH primaries move in the arm's favour with
  `p(sign-flip) < 0.05` and the effect is at or above the reported MDE.
* Otherwise **do not ship**; the knobs stay default `off`.
* Mechanism numbers are reported as measured, with no vote in the verdict.
* No subsetting, no dropping opponents, no re-running to chase a p-value. A
  clean null is a fully acceptable result.

---

## MEASURED

*(appended after the battles — everything above was committed first. Nothing
below exists yet: **no battle, server, GUI or A/B was started for this job**.)*