fix(ladder): tranche status is never updated, so in-flight netting grows and planning silently stops #118

Reviewed commit: be11bdcb5. Note: origin/main moved to 3e9660d06 during the review; re-verify against current main before changing code, since a finding may have been fixed or moved.

Where

• internal/config/store_postgres_ladder.go:378-390 - GetInFlightLadderCommitUSDHr, WHERE config_id = $1 AND status = $2 with ladder.TrancheStatusScheduled
• Rows written at internal/config/store_postgres_ladder.go:296-313
• Status assigned by the planner at pkg/ladder/ladder.go:308 (Status: TrancheStatusScheduled for every tranche)
• Consumer: internal/server/handler_ladder.go:323
• Executor absence documented at internal/server/handler.go:66

What

GetInFlightLadderCommitUSDHr sums amount_usd_hr over tranches in status scheduled, and the caller subtracts that from the allocation gap.

Every tranche is inserted as scheduled, and there is no UPDATE of ladder_tranches.status anywhere in the repository. git grep "UPDATE ladder_tranches" over origin/main returns nothing, and the tranche-firing executor does not exist yet. internal/server/handler.go:66 says so explicitly:

persists the ladder_run and ladder_tranches rows ... and stops. No purchases ... Execution arrives in a later PR

So scheduled is a terminal state in practice. The sum is cumulative over the config's entire history rather than a measure of what is actually in flight.

Failure scenario

A ladder config with cadence = weekly and a $2/hr gap plans 4 tranches of $0.50/hr in week 1.

Week 2's run calls GetInFlightLadderCommitUSDHr, which returns $2.00 (week 1's tranches, still scheduled, none of which ever fired), and subtracts it. The recomputed gap is about $0, so the run plans nothing. Week 3 and every week after behave the same.

The ladder silently stops producing plans after its first run and reports no error. The failure is indistinguishable from "the target coverage is already met", which is the one state an operator would never investigate.

Once the execution phase lands, the same sum will also be double-counted against the provider-reported ExistingUSDPerHour that the docstring says already contains fired and completed tranches, so the netting is wrong in both directions.

Fix direction

Either restrict the sum to un-fired tranches with a not-yet-elapsed scheduled_date (plus a per-run recency window), or land the status lifecycle transition in the same change that introduced the netting so scheduled stops being terminal. The second is the real fix; the first is a stopgap that keeps planning alive until the executor exists.

Related

• LeanerCloud/cloud-commitments-cli#1398 (ladder: buy-now ramp steps escape netting) covers the opposite direction on the same query: amounts that should be counted but are not, because AfterDays == 0 steps never become tranche rows. It also raises the read/append serialization gap. Neither item covers this one: that scheduled never transitions, so everything ever planned stays counted forever. Both need fixing before the netting is correct, and fixing only LeanerCloud/cloud-commitments-cli#1398 leaves this defect intact.
• fix(ladder): net in-flight tranches and use append-only persistence to converge to target coverage cloud-commitments-cli#1397 introduced the L5 tranche-netting convergence this query belongs to.