SAFETY-24: an energy floor under the peak guard's forced discharge

SAFETY-07 can command a discharge to hold a billed quarter down, and
nothing below it consulted the state of charge. On the 2026-08-20 replay
it asks for 878 Wh in a day. Relying on the BMS is not absurd - it is a
real floor and it works - but it is the pack's protection rather than the
operator's, and a month of aggressive quarters leaves the battery
repeatedly at that cut-out with no EMS-side record of why. The first
symptom is a pack never available when wanted, which is indistinguishable
from the SoC drift MAINT-01 exists to correct.

decide() now takes soc and soc_floor, both required and neither
defaulted, and discharge_permitted() is the one place the question is
answered. Above the floor nothing changes. At or below it the guard files
a 0 W floor instead of a sized one - one-directional, so charging stays
blocked and no discharge is capped - and reports floor_limited with the
reason it bound. It is not a trip: every stop in 11.2's table still
outranks the claim, and the floor is never negative, so 9.1's asymmetry
survives as a property of the object (0 negative floors over 1296 swept
combinations, SoC included).

The SoC is graded only after `wanted > 0` is established, so it is never
evaluated where it governs nothing. An unreadable SoC is floor-limited,
not a full battery - a full battery is exactly the value that would
disarm the floor, and this project shipped that defaulting once already.

Failing to shave is not silent: one notification per episode
(goodwe_peak_soc_floor), distinct from the saturation alarm because the
two ask for opposite operator actions, plus its own status row and an
action-log line.

Verified by replay. The 2026-08-20 capture is driven against a modelled
pack sized from the day's own measured appetite, so it genuinely
exhausts: without the floor it reaches the BMS cut-out and holds there
for 1227 guard cycles; with it the pack stops at 20.0 % and never touches
the BMS. The energy withheld equals the energy between the two floors to
within one cycle at the rail. The honest half is reported too - the worst
quarter goes 4338 W -> 5030 W, because a floor-limited guard shaves less
on purpose.

Two new options, mirrored once in peakguard.PEAK_OPTION_DEFAULTS
(TARIFF-02's pattern), imported by validate.py and main.py rather than
typed as literals and pinned to config.yaml by a check that reads the
file - so CFG-03 still tracks three places. validate.py rule 8 refuses
peak_soc_floor <= bms_soc_floor at startup, in CFG-01/MAINT-04's manner.
maintenance_soc_floor is deliberately not reused and not renamed: it is a
drain target, not a spend limit, and the rename is recorded as a decision
to revisit if a third floor appears.

Eleven mutations of the shipped source were run against the checks; all
eleven go red and there are no survivors.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC

goodwe_controller/DOCS.md

@@ -420,7 +420,7 @@ help - see "Why the tuning is what it is".
 | `maintenance_start_hour` | 10 | Hour of day a due cycle begins |
 | `maintenance_discharge_w` | 2000 | Drain rate (exports the surplus). Above `max_w` it is **clamped** to `max_w` — the drain phase SETs the setpoint and the arbiter bounds it, saying so on the status page (`limited by supervised(max_w)`). Warned about, not refused: the cycle still completes, just slower |
 | `maintenance_charge_w` | 2000 | Charge ceiling, capped again by peak headroom. Must stay **at or below `max_w`** or the cheap-window shaping (`hi = -maintenance_charge_w`) contradicts the supervised limit (`lo = -max_w`), the arbiter resolves it to **0 W**, and maintenance silently never charges in a cheap window — **the add-on refuses to start** |
-| `maintenance_soc_floor` | 11 | Drain target — stay just above the inverter's own floor |
+| `maintenance_soc_floor` | 11 | Drain target — stay just above the inverter's own floor. ⚠️ **This is not `peak_soc_floor`.** It is the depth the monthly recalibration deliberately goes to, once, on purpose; `peak_soc_floor` is the depth a money-saving discharge may never reach on any day. The right values differ (11 vs 20 as shipped), which is why they are two keys |
 | `maintenance_soc_target` | 99 | Charge target |
 | `maintenance_hold_min` | 120 | Hold at full so the BMS can balance |
 
@@ -430,6 +430,8 @@ help - see "Why the tuning is what it is".
 |---|---|
 | `peak_forecast_entity` | Quarter-hour demand forecast, for capacity-tariff markets. Empty = no cap |
 | `peak_cap_w` | The site's capacity-tariff target |
+| `peak_soc_floor` (20) | **The percent below which the capacity-peak guard will not discharge the battery.** Not optional and not the same thing as `maintenance_soc_floor` — see below |
+| `bms_soc_floor` (10) | The pack's **own** cut-out percent, the number the BMS enforces whatever you set above. `peak_soc_floor` must be **strictly above** it or the add-on refuses to start |
 | `price_now_entity`, `price_avg_entity` | Dynamic tariff. Empty = never force a paid grid top-up |
 
 On a capacity-tariff site the maintenance charge is capped by the headroom left
@@ -530,11 +532,46 @@ projected over — raises one notification (`goodwe_peak_saturated`), because th
 is the one state where the money will be spent and shedding load is the only
 thing left that changes the bill.
 
-**No new option.** The ceiling is `peak_cap_w`, which already shipped. The
+**No new option for the CEILING.** It is `peak_cap_w`, which already shipped. The
 coverage threshold is `meter_max_age_s`, the freeze predicate is
 `meter_freeze_s`, and the achievable discharge comes from `max_w` and the device
 rating — every one of them a key that already exists.
 
+#### The energy floor under the forced discharge (`peak_soc_floor`)
+
+The guard above can **command a discharge**, and until SAFETY-24 nothing in the
+add-on bounded how far down it took the pack — the BMS was the only backstop.
+On the 2026-08-20 replay the guard asks for **878 Wh in a day**.
+
+That is not absurd: the BMS floor is real and it works. But it is *the pack's*
+protection, not *yours*. A month of aggressive quarters can leave the battery
+repeatedly parked at that cut-out with no record on this side of why, and the
+first symptom — a battery that is never available when you want it — looks
+exactly like the SoC drift the monthly maintenance cycle exists to correct.
+
+- **`peak_soc_floor` (20 %)** is where the forced discharge stops. Below it the
+  guard files a **0 W** floor instead of a sized one: charging stays blocked
+  (that can only ever lower your offtake), and no further discharge is asked for.
+- **It does not stop the ordinary self-consumption loop.** That loop still has no
+  SoC guard of its own. This bounds what the *peak guard* spends for money.
+- **When it binds you are told**, once per episode, with notification
+  `goodwe_peak_soc_floor` and a status-page row reading `PEAK GUARD
+  FLOOR-LIMITED`: the quarter **will** go over the ceiling, so shedding load is
+  the only thing left that changes the bill. Failing to shave is never silent —
+  the euro figure is the whole point of the guard.
+- **An unreadable SoC is treated as floor-limited, not as a full battery.** A
+  full battery is exactly the value that would disarm this floor.
+- **`bms_soc_floor` (10 %)** is the pack's own cut-out — register `0x0560` on the
+  reference GW5000S-BP, consistent with DoD 90. It exists so the add-on can
+  **refuse to start** when `peak_soc_floor` is at or below it: such a floor can
+  never be the thing that stops the discharge, and a guard that advertises a
+  backstop it does not have is the one thing this project will not ship. Equal is
+  refused too — equal buys zero margin.
+
+Why 20 %: the reference pack is 13.8 kWh usable, so 10 points of margin over the
+BMS cut-out is about 1.6× the guard's worst measured day. If your pack is
+smaller, or your quarters are worse, raise it.
+
 ### The winding-loop alarm (the output clamp)
 
 Every setpoint this add-on writes is clamped to `max_w` before it leaves the