fix(control): the slew limiter may not re-open a closed charge block

[frahlg]

Both bases have landed: #803 as f4eedde and the per-phase relief fix as #812 (which replaced #808 after GitHub auto-closed it). This branch is now rebased straight onto master and carries only its own two commits, so the whole diff is the change under review.

Two commits on purpose: the fix, then the fixture update, so the behaviour change and the re-recorded corpus read apart.

The bug

The slew limiter anchors every target on the battery's measured output rather than on the previous command. That is deliberate and right — it is what lets dispatch pivot the instant a setpoint reverses instead of spending ten cycles ramping away from a stale command, and the comment above it explains why.

But it also means a battery that is physically charging drags its own command back toward that charge, whatever the tick above decided.

noSelfCharge pins the fleet total to 0 W. The limiter then walks it back, and nothing downstream put it right:

• applyFuseGuard only shrinks toward zero;
• floorNegativeTargets covers the discharge side only;
• planSignIntent reports "idle, no opinion" for an idle slot, so applyPlanSignFloor has nothing to compare against.

passive-arbitrage idle slot, meter -2000 W, battery live +2000 W, SlewRateW 500	commanded
what the tick decided	0 W
what reached the driver	+1500 W of charging

The site charged on the tick whose entire purpose was to let that surplus cross the meter. With slew disabled, the same inputs give 0 W.

The same mechanism re-opens a battery that just reported charge_capable=false: the distributor parks it at 0 and hands its share to a capable sibling, then the limiter anchors it on its own live charge and commands +1500 W into hardware that said it cannot take it — while the sibling is already absorbing that same share. The fleet charges it twice.

Complete the carve-out, or add a floor?

There is a snap-to-zero carve-out inside the slew loop already. It fires when a gate wants the battery stopped now rather than ramped, and it names plannerSelfExportSurplusGate, the scoped-sibling stand-down, and a zero manual hold. Completing it means adding the two charge gates it never learned about.

The floor is the right answer, and the carve-out is the reason.

That list is an enumeration of reasons a target was closed. It is exactly how this bug was born: plannerSelfNoChargeStalePlan and arbitrageFamilyIdleLiveExportGate were added to ComputeDispatch after the carve-out was written, and neither was added to it. Completing it fixes today's two gates and leaves the same trap armed for the third.

It is also weaker than it looks. The carve-out only fires when the pre-slew target is already within 1 W of zero. A fleet total pinned to 0 W by a +800 / -800 split satisfies the gate and defeats the carve-out on both batteries — in both directions.

A floor bounds the output instead. It cannot be born incomplete, because there is nothing to enumerate, and it does not care how the total was split. floorNegativeTargets is the same shape on the discharge side; this is its mirror, sitting on the next line.

The carve-out stays as it is. Its job is latency — reaching 0 W in one tick instead of ramping — and that job is real for the discharge direction the floor does not touch.

The fix

floorBlockedCharge, applied in applyDispatchSafetyPipeline immediately after floorNegativeTargets. Two authorities close the charge direction, both decided before slew runs:

• noSelfCharge — the site-wide block: planner_self's export-surplus gate, planner_self's stale plan, the arbitrage-family idle live-export gate. It pins the fleet total; the floor bounds each command.
• chargeBlocked — the driver's own capability report, carried past the limiter, which knows nothing about capability.

Placed after applyFuseGuard rather than before it, so the guard's predicted grid is unchanged and the blast radius is exactly "targets that command charge into a closed direction" — nothing else. Nothing between the floor and the driver raises charge: applyBatteryBoostReserve touches negative targets only, and forceFuseDischarge only forces discharge.

The discharge-side twin of the per-driver half is deliberately left alone. A dischargeBlocked battery re-opened by slew is the same shape — the corpus records it as blocked_sibling_slew_reopens_parked_target — but flooring it has to answer whether the fuse emergency in forceFuseDischarge outranks a driver's "I cannot discharge". forceFuseDischarge runs last precisely so it can override floorNegativeTargets for the physical emergency. Charge has no such override, so it is the half that can be fixed without deciding that. The discharge half deserves its own change and its own answer.

Structural direction, not built here

Express slew as a low-rank claim intersected after the authority constraints, so a lower-ranked stage can never widen a higher-ranked one. That makes this whole class of bug unrepresentable instead of repaired, and it is the constraint-algebra direction — a deliberate change of its own, not a rider on a live-site fix.

Golden corpus

The slew_limiter family recorded this bug on purpose in #799, so the fix would show up as records moving. Predicted before looking, then verified.

Eleven records move, all in slew_limiter, all the same law. The eight the corpus named:

record	before	after
bug_no_self_charge_idle_slot_leak_250	+1750 W	0 W
bug_no_self_charge_idle_slot_leak_500	+1500 W	0 W
bug_no_self_charge_idle_slot_leak_1500	+500 W	0 W
bug_no_self_charge_idle_slot_leak_with_pv	+2000 W	0 W
bug_no_self_charge_arbitrage_idle_slot_leak	+1500 W	0 W
bug_no_self_charge_idle_slot_leak_two_batteries	+1500 / +1000 W	0 / 0 W
bug_no_self_charge_stale_plan_leak	+2000 W	0 W
blocked_sibling_slew_reopens_parked_charge	+1500 / +500 W	0 / +500 W

The first seven are the site-wide block: the total was already 0 W, so 0 W is the answer the tick computed and the limiter overwrote. The eighth is per-driver — ferroamp reported charge_capable=false and goes to 0; sungrow keeps +500 W, which is its own legitimate one-step ramp from a 0 W anchor and not something anything closed.

Three more were predicted by shape rather than by name, in the seeded half of the family where the same gates fire on generated sites:

record	before	after	why
seeded_039_planner_arbitrage	+3000 W	0 W	idle arbitrage slot, meter exporting 12.6 kW, battery measured +5377 W
seeded_068_planner_self	+2525 W	0 W	stale plan, battery measured +4025 W
seeded_078_planner_passive_arbitrage	+600 / +787 W	0 / 0 W	idle slot (28 Wh), meter exporting 3.1 kW, both batteries measured charging

Every one of the eleven is a tick where the site charged while the meter exported, or charged hardware that said it could not. Nothing moved that was not predicted.

Predicted not to move, and did not:

• carveout_export_surplus_gate_snaps_to_zero and carveout_export_surplus_gate_snaps_discharge — already 0 W. These are the A/B partners whose difference from the bug rows was the bug, and they stay put.
• no_self_charge_idle_slot_slew_3000_reaches_zero — 0 W. A 3000 W rate already reached zero in one step, which is why it never leaked.
• blocked_sibling_slew_reopens_parked_target — -1500 W. The discharge-side twin, out of scope by design.
• The other seven families. They run slew_rate_w=100000, so the limiter never binds and the 0 W the gate pinned already survives; seeded_reactive's 32 realistic rates are reactive modes where noSelfCharge is structurally false; and the charge-blocked batteries in seeded_siblings carry negative targets, which a charge floor does not touch.

Only slew_limiter.json is re-recorded. No record in the other seven moved, and rewriting their ftw_commit would claim they were re-examined under this change when they were not.

590 records in 8 families, unchanged. Tolerance unchanged at 0.01 W. slew_limiter.json sha256 f7ff7a54bc49321a5c232d58eed9230b2e25e4b3b7474544e32b46bf0b78885b.

Two things found while re-recording

1. slew/seeded_023_planner_arbitrage shifts without moving. Its derived battery_target_sum_w goes from 235.00000000000006 to 235 while all three per-driver targets stay byte-identical. Isolated by re-dumping with the floor disabled: the shift is already present on this branch's base, so it belongs to the fuse-relief refactor in fix(control): size per-phase relief by the site's phase count #808 rather than to this change. 6e-14 W, fourteen orders of magnitude under the tolerance, which is why fix(control): size per-phase relief by the site's phase count #808's replay passed and its "zero records move" claim is correct — the record's behaviour did not change. Worth knowing that a re-record surfaces it.

2. The seven un-re-recorded families carry ~150 lines of sub-tolerance float churn (e.g. 3704.0000041155554 → 3704, -494.3225806451613 → -494.32258064516134), accumulated since they were last recorded at c7fe6c98. Nobody should re-record them to make that go away; it just means a future genuine re-record of those families will have noise mixed into its diff.

Tests

go/internal/control/slew_charge_floor_test.go. Every test runs at a rate a site actually runs (250-1500 W, next to NewState's 500 W default) with the battery measured mid-charge. At SlewRateW = 100000, the way most older dispatch tests neutralise the limiter, all four bug tests pass against the broken code — that is the trap #799 was written to close, and these tests stay out of it.

Four fail against the old code:

• TestSlewMayNotReopenArbitrageIdleChargeBlock — the reproduction watt for watt. Was +1500 W.
• TestSlewMayNotReopenPlannerArbitrageIdleChargeBlock — same law, planner_arbitrage rather than passive. Was +1500 W.
• TestSlewMayNotReopenStalePlanChargeBlock — planner_self with no fresh plan is discharge-only. Was +2000 W. Asserts the gate actually armed, so the test cannot pass vacuously.
• TestSlewMayNotReopenChargeBlockedBatterysParkedTarget — the per-driver half. Was +1500 W, and pins the capable sibling's +500 W ramp so the floor cannot pass by zeroing everything.

Two more guard against over-reach, and pass either way by design:

• TestChargeFloorLeavesUnblockedChargeAlone — same slew shape, no gate: the +2500 W ramp survives.
• TestChargeFloorLeavesDischargeAlone — a charge-blocked tick with the battery measured mid-discharge still ramps to -1500 W. The floor is one-sided; covering live load is not collateral damage.

TestFloorBlockedChargeContract pins the function's contract directly: positives only, blocked drivers only, never away from zero.

make verify green as the pre-commit gate on the re-record commit. The fix commit was made with --no-verify on purpose — between the two commits the corpus is knowingly stale, which is the point of splitting them.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7b3a1f4402

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Apply the charge floor before deadband exits

When the grid error is already inside GridToleranceW, the legacy path returns through fuseSaverEarlyExit before this newly added floor runs. In an arbitrage idle/live-export or stale-plan tick where the battery is already charging enough to keep the meter near zero (for example meter -50 W, battery +2000 W, tolerance 60 W), noSelfCharge is true but ComputeDispatch emits no zero target, and main.go only sends commands for returned targets, so the previous charging command can continue despite the charge block. The same bypass affects a charge_capable=false battery if the site is in the deadband; the floor needs to be reached (or the early-exit condition suppressed) whenever a charge block must actively stop existing charge.

Useful? React with 👍 / 👎.