Decay the 3D aircraft oracle's step and reset the 3D floors to resolution

[YannBerthelot]

Sixth per-plant upgrade from the oracle audit. The 3D aircraft oracle's step decays over each solve, and the four 3D tasks move to -v3 with their floors at the instrument resolutions (approved).

The 3D aircraft planner took normalised gradient steps of a fixed 0.05,
which is also its resolution: it left steady offsets, 4.1 to 4.5 m of
altitude and 14.3 to 15.5 m of path on the circle. The step now decays
from 0.05 to 0.002 over each solve, over 200 iterations on all four
tasks, from a settings table in plane3d/experts.py (in the four tasks'
baseline fingerprint). Under the earlier floors the oracle audit
measured the protocol cost falling from 5.05 to 0.380 (heading), 9.84 to
0.123 (circle) and 2.10 to 0.031 (figure-8) at 200 iterations, and 7.04
to 1.49 (racetrack) at 50.

The oracle then holds below the 1 m altimeter and 3 m GPS resolutions,
so the floors are reset to them: altitude 1.44 / 4.06 / 1.39 m to 1 m,
path 8.12 / 6.17 / 14.6 m to 3 m. Those were an earlier oracle's holds,
except the circle's 8.12 m path floor, which was labelled one but equals
2 x 4.06 m (the recorded hold was 14.3 m). failure_cost follows. The
reward changes, so all four tasks are -v3. The heading's floors are set
in its registry test_params, not in the PlaneParams3D defaults, which
patrol inherits; patrol's stamps do not move.

The racetrack was first shipped at 50 iterations. Measured under the -v3
floors on protocol seeds 0 to 2, 200 iterations cost 1.07 (0.960, 1.29,
0.962) against 4.58 (2.23, 7.54, 3.97), zero trips either way, so it
runs 200 too; its holds were re-measured with it and its -v3 stamp
re-stamped in place with a note, since only rho_floor moved.

Re-measured under the new floors (they weight the planner's objective):
lowest per-seed holds 0.67 / 0.67 / 0.68 m of altitude, 2.1e-5 rad of
heading, 0.45 / 0.47 / 1.29 m of path. rho_floor = rho_floor_tracking
follows them: 0.454, 0.466, 0.487, 0.184 (from 1.0, 2, 2, 1). The
planner does not read rho_floor_tracking (done_value is never applied,
checked: identical actions under two values), so no second measurement
was needed. Protocol cost under -v3: 0.726, 1.93, 1.07, 0.770, zero
trips. The heading and racetrack land below the audit's trajectories
rescored at the new floors; the figure-8 is 3% above (0.770 against
0.744) and the circle 21% (1.93 against 1.60). The 10-seed baselines
have the MPC ahead on 10/10 seeds on all four, zero trips. The oracle
takes 0.9 to 1.3 s per step on the four in the recorded protocol rows
(about 8 min a seed on the figure-8, 10 on the racetrack).

Also: reward-shaping.md no longer lists the aircraft and patrol among
the undisturbed plants, and benchmark.py counts six aircraft tasks whose
test params are the task itself.

Checks

• The full fast suite passes on the branch before the merge from main: 1910 passed.
• After merging main (wind), the conflicts in CHANGELOG, docs/baselines.md and the record timestamp were resolved, and the generated docs regenerated. Every docs check, mkdocs build --strict, and the contract, registry, version and docs tests then pass on the merged tree (324 passed).
• An adversarial review found no defect in the oracle. It did find that the racetrack had shipped at 50 iterations without a comparison to 200. That was measured: 200 is better on every seed (4.58 -> 1.07), so the racetrack now uses 200 and its rows were re-recorded. Re-recording the other three tasks gave bit-identical numbers. The review's docs findings are fixed too; among them, the circle's 8.12 m path floor was never an oracle's hold, and the docs now say so.

Disclosed

• The circle costs 1.93 per step under the new floors, against 1.60 for the audit's trajectories rescored at those floors. The new weights make the planner trade path for altitude. The step sizes were not re-tuned for the new scale.
• Compute: 0.9 to 1.3 s per step, so about 8 to 10 minutes per protocol seed on the figure-8 and racetrack.
• Expect a conflict with the patrol PR in the GradientMPC count (it becomes 9 once both are in) and in CHANGELOG. It will be resolved on this branch.

🤖 Generated with Claude Code