Round 3 outcome — refine/perfect (Jun 7-8, 2026)

Honest result: round 3’s two algorithmic changes did not survive the full-helix sign-off and were reverted. The best config is the round-2-equivalent on current code: startup 90 + no blend (full helix: coverage 0.998, p_e p99 0.379, z_e p99 0.0114, nu_e p99 0.675). Final report: logs/logs_Jun08_26/full_control_run/.../ (startup 90, no blend).

What was tried, and why each was reverted

• TASK_10 — startup.time 90 -> 15. Looked good on the 200s gate (reclaim a “dead” window). The full helix showed it regressed coverage 0.998 -> 0.775 (−22%). The startup window is not dead: it buys base-attitude settle time before targeting, which pays off as effective FOV marking across the whole helix. Reverted to 90.
• TASK_11 — smoothstep pointing blend. Looked like a clear win on the 200s gate (z_e 0.0176 -> 0.0112, nu_e −27%). The full-helix clean A/B at startup 90 showed it makes p_e (0.379 -> 0.460), z_e (0.0114 -> 0.0175), AND nu_e all WORSE — the gate’s tracking effect flipped sign vs the helix. Also the position-blend variant failed earlier (ref_jerk 15x). Reverted (code + config).
• TASK_12 — controller tuning for p_e. Proven that p_e p99 < 0.15 is architectural, not tunable: arm position K is non-monotonic/destabilizing (excites the base-arm breve mode), desired_twist.v_max is inert (not binding), raw-velocity feedforward is worse (amplifies reselect jerk), and match_com_velocity was dead config. There’s a fundamental smoothness-vs-lag tradeoff and the existing filtered feedforward sits near its optimum.

The throughline lesson: the 200s gate was misleading

The short refine_gate window misled on BOTH axes — coverage (orbit-phase-confounded) and tracking (the blend’s effect flipped sign between the 200s/startup-15 window and the full 30-rev helix). A short window is not representative of a pole-to-pole helix. Validate refinement changes on the full helix (or a multi-rev window), not a 200s slice. The full-helix sign-off is what caught both regressions before they shipped.

What survives round 3 (the real value)

• validation/refine_gate.py — the in-process gate harness (use at full duration, not 200s).
• Diagnosis: p_e<0.15 is architectural — the next lever is a continuous surface-waypoint trajectory (a target that glides along the surface so there’s no reselect jerk to filter -> no lag), or a controller restructure for bandwidth without the breve resonance. Not a tuning round.
• Cleanups: removed match_com_velocity dead config; fixed target_finder.py:35 load_parameters(staging=True) -> load_parameters() (latent TypeError).
• The user’s target_finder refactor improved targeting on its own: at startup 90 + no blend, current code gives z_e p99 0.0114 (vs round-2 pre-refactor 0.027) and p_e 0.379 (vs 0.404) — near the z_e target without any blend.

Where this leaves the round-2 goals

z_e p99 is now ~0.011 (near the 0.01 target, from the refactor — no blend needed). p_e p99 ~0.38 and the <0.15 target remain a research item (architectural). Coverage stays ~1.0; effort gentle.