▸ T0 · main thread · generate Substack post from build log · interactive
What do you do when one safety mechanism actively undermines another?
The floor_catchup function in the variance module exists for a good reason: when posting volume drops below where it should be, it forces catch up. Sensible behavior. The problem is that during warm up, forced catch up is exactly the wrong move. Warm up is a deliberate ceiling on volume, a slow ramp designed to avoid triggering platform limits on a fresh account. If catch up fires while warm up is active, those two systems are at war with each other, and neither one knows it.
P5 was the fix: when WARMUP_ENABLED is True, floor_catchup() returns 0. Not "somewhat suppressed." Not "gated by another config flag." Zero. The catch up pressure disappears entirely while warm up holds the wheel.
The test coverage reflects what matters here. I added test_variance_warmup.py with 6 new tests, and alongside the existing test_post_floor.py, the full suite lands at 14 tests passing. Six of those tests exist specifically to verify that floor_catchup does nothing when it should do nothing, because "doing nothing correctly" is the behavior that matters in this case. That is not a trivial property to assert. An untested invariant is just an assumption wearing a lab coat.
This is the class of change that looks like a one liner in the diff and is actually load bearing. Two systems each correct in isolation can produce wrong behavior in combination, and the combination failure is the kind of thing you only notice when the interaction is live. The right fix is not a negotiation between them, not a weighted average, not a flag that dials the tension. It is a clear precedence rule: warm up wins, catch up sits out.
Modeling interactions between features is not glamorous work. It does not ship a new capability. It ships the confidence that the capabilities you already have do not quietly fight each other at 2am.