Deep audit on b435d25be found a third post-B1b bug in same class as
the slot 63 overload: experience_env_step writes cf_reward_weighted
(= w_cf × cf_reward, post-controller-weight) to reward_components_
per_sample[+1] at line ~3696. SP4's reward_component_ema_kernel EMAs
this into ISV slot 64 (REWARD_CF_EMA_INDEX) which the SP11 mag-ratio
canary reads as ratio[1] = slot[64] / Σ.
Self-reinforcing loop:
high w_cf → high cf_reward_weighted → high slot 64 →
high ratio[1] → controller raises w_cf → tighter loop
Until mean=1 normalization saturates other components to floor.
The other 5 component slots correctly write RAW pre-weight values:
- rc[+0] = total_reward (intentional, PopArt input — post-composition)
- rc[+2..+5] = r_trail / r_micro / r_opp_cost / r_bonus (all raw, pre-Σ)
- Slot 360 (popart-component) fed by `popart_component_per_sample`
which receives `r_popart` raw
Only rc[+1] was wrong. Fixed: write raw cf_reward to rc[+1] so the
canary tracks intrinsic cf magnitude. The replay-buffer cf-tuple
reward (out_rewards[cf_off]) still uses cf_reward_weighted — that's
correct, loss kernels train on controller-weighted signal.
This was the third bug in a class — pre-SP11 invariants exposed by
post-decomposition semantic. Trio: (1) slot 63 overload (5e16b67ca),
(2) stale rc[] init + cf_flip ordering (b435d25be), (3) cf-component
feedback loop (this commit).
cargo check + build clean; 6/6 SP11 GPU tests + 14/14 contract tests
still pass. After this fix-up, all known SP11 reward-system bugs
identified by deep audit are resolved. L40S smoke validates empirical
sharpe recovery.
61b2fa962b