[frahlg]

Problem

#1816 by @segran2 holds two reproductions of a battery ending fuse relief too fast. We plan to close #1816 because master's keepEndingDischarge (#1847) covers the same case while a car charges. Its tests should not be lost.

No rig seed comes from #1816 itself. The same class of fault shows on the random rig as C3 in the 27 Oct triage (seeds 207530, 207533).

Change

One new test file, go/internal/control/battery_relief_pending_test.go. No code change and no changeset.

The two reproductions, adapted to master's capBatteryCharge and clampEVBatteryHeadroom:

• Pending rise. A 25 A site with a 1 A margin, phases at 22.3/12.3/12.3 A, leaving 1173 W. The battery measures -2000 W, and our newer -1000 W order may not show yet. Ending the relief at once would take L1 to 25.2 A. The battery must keep -827 W, so L1 lands on 24 A. A table at capBatteryCharge covers settled, room for both, blocked, bounded and no-relief cases.
• Shared relief. Two batteries end -1000 W and -2000 W of relief, and 1827 W must stay. When the first cannot keep its share (at its SoC floor, or bounded to 300 W), the second keeps the rest. fix(control): reserve pending battery rises before releasing relief #1816's old head gave the second only 1218 W, so L1 reached 24.88 A. Both target orders are tested, and a table covers too little supply, no prior relief and a pending rise past supply.

Changes from #1816's tests:

• They use master's helpers (evSplitFixture, sent, batteryReading).
• Bounds pass in as lowest, the lowest order each battery may receive.
• fitBatteryRisesToFuse comes from fix(control): fuse protection as one function #1789 and does not exist on master, so the allocation layer is gone.
• Export cases are dropped. Master's keepEndingDischarge handles import only, and nothing else on master holds the export case (see Risk).

The file header names both no-car gaps. An earlier version said master left export to the fuse pipeline; that was wrong.

Tests

• New tests pass on master (09ebd42).
• Mutation checks on ev_battery_headroom.go, each reverted afterwards:
  • Without the keepEndingDischarge call, all four tests fail.
  • With pendingW removed from the shortfall, the pending-rise cases fail.
  • With the shares split across all lost relief and bounds applied afterwards (fix(control): reserve pending battery rises before releasing relief #1816's old head), the shared-relief cases fail with the second battery at -1218 W, the same number as fix(control): reserve pending battery rises before releasing relief #1816.
  • Review found one more: with the share uncapped (share := shortW / keepW), only these new tests fail. No older master test catches it.
• go test -race -count=1 ./internal/control passes at f5da511.
• make verify steps passed on the first commit: tests, vet, build and boundary checks. Docker steps were skipped because no Docker daemon was running. The follow-up commit changes only a test comment.

Risk

Test only. Two gaps stay open, and these tests cover neither. On master, keepEndingDischarge runs only inside clampEVBatteryHeadroom, which returns early when no EV demand is active. I ran #1816's pending-rise scenario through ComputeDispatch with no EV, in Idle and with a manual 0 W hold, in both directions:

Direction	master	master + #1891
Import (battery discharging -2000 W, order -1000 W)	0 W, L1 imports 25.2 A	-827 W, L1 imports 24.0 A
Export (battery charging +2000 W, order +1000 W)	0 W, L1 exports 25.2 A	0 W, L1 exports 25.2 A

• No-car import gap. Open on master. fix(control): battery fuse guard reads each phase with its direction #1891 (phaseFuseReliefW, C3) closes it in this scenario.
• No-car export gap. Open on master and still open with fix(control): battery fuse guard reads each phase with its direction #1891. No open PR covers it that I know of.

So #1847 matches #1816 only when a car charges, and only on import. The note that closes #1816 must name both gaps.

Stack and merge order

• Based on master. No stack. Can merge in any order with the PRs below.
• Open PRs on nearby files:
  • fix(control): car and battery work to the fuse rating (fuse stack #1910, #1891, #1913, #1923, #1924, #1925, #1926, #1914) #1910 changes evBatteryPhaseSpareW to use fuseLineA(). These tests set SiteFuseSafetyA = 1 explicitly, so the line stays at 24 A either way. Review test-merged fix(control): car and battery work to the fuse rating (fuse stack #1910, #1891, #1913, #1923, #1924, #1925, #1926, #1914) #1910, fix(control): battery fuse cut lands on the line, not half a margin below #1913, fix(config): fuse safety_margin_a defaults to 0 #1914, fix(control): no discharge at or under the SoC floor #1916, fix(control): one SoC floor for the stale-plan fallback, fuse relief and the hourly import limit #1878 and fix(control): battery fuse guard reads each phase with its direction #1891 into this branch; each merged cleanly and these tests pass.
  • fix(control): battery fuse guard reads each phase with its direction #1891 changes the battery fuse guard (see Risk). It does not touch this file.
  • fix(control): fuse protection as one function #1789 conflicts. It does not touch this test file, but it deletes go/internal/control/ev_battery_headroom.go, which holds clampEVBatteryHeadroom and keepEndingDischarge, and moves capBatteryCharge to fuse_phase.go with a new signature. These tests call both, so they would not build on fix(control): fuse protection as one function #1789. fix(control): reserve pending battery rises before releasing relief #1816 is based on fix(control): fuse protection as one function #1789's branch (fix/fuse-one-function) and patches fix(control): fuse protection as one function #1789's fitBatteryRisesToFuse. Closing fix(control): reserve pending battery rises before releasing relief #1816 is safe only if fix(control): fuse protection as one function #1789, a conflicting draft, is dropped or rebuilt on master. If fix(control): fuse protection as one function #1789 comes back, it must port these tests. The note that closes fix(control): reserve pending battery rises before releasing relief #1816 should say so.

Credit to @segran2 for both reproductions (Co-authored-by in the commit).

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-27T18:41:55.606928Z	3ed607a	PR opened

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.