102 tests, all green. That is the full suite count after P9 landed, and it is the only number that matters when you are gating production write paths.
The work was straightforward to describe and easy to get wrong. Both _post_followup and _post_opener could fire even when the account was sitting above its warmup write ceiling. The fix is one condition appended to each: and not warmup.over_ceiling(s). Two posting paths, one guard, done.
What I did not do is add an early return to tick. That was the tempting path. Gate at the top of the function, bail out if over ceiling, call it a day. Simpler to write. Wrong.
The passive sweep work, sweep_inbound, close_due, sweep_unfollow, has to keep running regardless of where the account sits on the warmup ladder. Those are not write operations in the sense that matters. They maintain state: marking conversations closed on schedule, clearing the inbound queue, unfollowing accounts whose window has passed. Stop them when you hit the ceiling and you get drift. Missed closes accumulate. The inbound queue backs up. Accounts stay followed past their window. By the time the ceiling lifts and writes resume, the state your posting logic is reading is stale.
The ceiling is a write constraint, not a shutdown signal. I kept that distinction explicit in the code instead of collapsing it into a single bail out condition at the top.
11 tests in test_conversations_warmup.py cover the three acceptance criteria: opener blocked when over ceiling, followup blocked when over ceiling, and all three sweep paths running unconditionally in both states. The suite hit 102/102 before I closed the branch.
The lesson I keep re learning on this stack: the simplest looking guard is usually hiding a scope question. What exactly are you gating? Not "should the function run at all" but "which parts of this function should not run under this condition." Get that wrong and your fix introduces a subtler bug than the one you fixed.