Release 0.20.0 review: CHANGELOG wording (OPT-23 headline, CI-15 time, UX-75 quote)

- The OPT-23 headline said a daily-total forecast is now counted right by
  day; OPT-30 (known issue) still over-counts by day. Say what changed.
- CI-15: 16 min was one run; runs took 16 to 24 min.
- UX-75: quote the page text as it reads.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

goodwe_controller/CHANGELOG.md

@@ -1,13 +1,117 @@
 # Changelog
 
+## 0.20.0
+
+**A minor bump: a Forecast tab, a night grid charge sized to what the sun will not give, a kept evening forecast, and no option changes.**
+No option was added, removed or renamed, and no default changed (86 options). It is a minor bump because Leftover solar now buys different amounts from the grid and the night charge keeps its level when the forecast goes quiet; every saved setting still starts.
+**Existing installs need no option change:** options that start 0.19.2 also
+start 0.20.0. The changes below apply with one inverter or two.
+
+**A Forecast tab.** A new tab next to Home and Batteries shows today and tomorrow hour by hour: the solar forecast, the sun measured so far, the house's expected use, and each battery's level with its planned charge and give blocks. It shows what the add-on plans and changes no command.
+
+**Leftover solar buys what the sun will not give.** On a day/night tariff the night grid charge now covers the expensive hours' use less the sun counted for them, where it used to buy for the whole day. A forecast with only a daily total, such as Forecast.Solar, is no longer counted several times over by day, so Leftover solar no longer charges too little because of it.
+
+**The evening forecast is kept for the night.** Forecast.Solar-type sensors stop updating in the evening. The last fresh reading is now kept until 06:00, so the night cheap run is judged with the forecast's price gap and Leftover solar still plans its charge. A newer reading replaces it at once, and a charge that is running keeps its planned level if the figure ends.
+
+**No false peak alarm during the night grid charge.** "Battery stopped limiting the peak", and its notification, no longer appear while the 15-minute period stays within 10 W of the aim.
+
+Contents of this release, in merge order since 0.19.2 (`f1c9733`):
+
+| | |
+|---|---|
+| `a1d0703` | Home now draws a grid charge only where the add-on will take it, with battery modes on or off; before, it could show the rest of a refused cheap run, or a charge after the last dear period. The price texts say "lowest price left" and "highest price left", and no command changes ([[UX-53]], #209) |
+| `f5afb42` | The day planner's hour loop now always ends on the night the clocks go forward. Without time-zone data it could go round forever and freeze the add-on; the add-on's own image has that data ([[SAFETY-123]], #211) |
+| `4a1f6cc` | A new Forecast tab shows today and tomorrow hour by hour: the sun, the house and each battery's level, with the charge and give blocks Home would draw. It shows the plan and changes no command; notes say when a part is not known yet ([[UX-54]], #210) |
+| `6be7e41` | The add-on's test files now run six at a time in the checks, so a check takes about 15 to 25 minutes, where one by one it ran past an hour. No change in behaviour ([[CI-15]], #215) |
+| `b6be312` | The day plan counts the sun right: a forecast with only a daily total is no longer counted several times over. On a day/night tariff the night charge for Leftover solar covers the expensive hours' use less the sun counted for them, shared between batteries by capacity, and the screens say when another battery or the grid covers the rest ([[OPT-23]], [[OPT-28]], #218) |
+| `cc9bbeb` | When a solar forecast sensor stops updating in the evening, the night plan uses its last fresh reading, for the day it is for only. One missed reading no longer drops the forecast at once, and the pages say when a figure is kept ([[OPT-27]], #219) |
+| `deee98d` | The night grid charge under the peak limit no longer raises a false "Battery stopped limiting the peak" alarm when the 15-minute period stays within 10 W of the aim. A real overrun still alarms; a steadily rising load alarms a little later, and with a peak margin under 10 W a period can end up to 10 W over the limit without it ([[SAFETY-126]], #221) |
+| `8afadbd`, `cdafa2c` | The kept evening figure now counts until 06:00, not until 03:00, and a charge that is running keeps its planned level when the figure ends. A newer reading replaces the evening figure at once and for good, so it does not come back later in the night ([[OPT-34]], #222, with its fix #225) |
+| `d4c01da` | Comments and docstrings in the peak guard and the price files were cut to a line and a pointer to the decision notes. No change in behaviour: a check shows the code itself is the same ([[MAINT-20]] part 1, #223) |
+
+The merge that brought 0.19.1 and 0.19.2 into this branch (`f1b7244`, #220) adds nothing else; the Forecast tab uses the same price gap as control since it.
+
+### Known issues
+
+- A false "Battery is not keeping up" can still show when the peak guard pauses a maintenance charge ([[SAFETY-92]]).
+- A battery capped at a low limit with a perfectly flat reading can still trip the stale check ([[SAFETY-74]]).
+- A battery whose reading at rest is beyond about ±175 W is still not caught when it refuses ([[SAFETY-97]]).
+- The peak guard can still back off near the end of a 15-minute period when a meter reading is late, by less than 30 s. This is about the guard's discharge only; a grid charge is cut back since 0.19.2 ([[SAFETY-99]]).
+- Two inverters: the maintenance charge can switch on and off while the house is above the peak aim ([[SAFETY-88]]).
+- Two inverters: the "circulating" figure counts a battery's reading at rest ([[SAFETY-98]]).
+- Two inverters: a drain that starts during a big step in house use can send the other battery to full power, and about 1 kW goes to the grid for about 10 s ([[SAFETY-104]]).
+- Two inverters: when a battery comes back during a maintenance charge, the grid can step by several kW at once ([[SAFETY-101]]).
+- Two inverters: when a battery drops out during a solar surplus, the others can swing by up to 1.5 kW in a simulation ([[SAFETY-105]]).
+- Two inverters: after a drain ends, a change in house use can go unanswered for about 9 s, because some readings are old ([[SAFETY-106]]).
+- Two inverters: when one battery's level is missing, both batteries are held at 0 W, and for about 15 s the last command stays on ([[SAFETY-108]]).
+- Two inverters: if one battery's level stays missing for 12 h, the other battery's cycle can be marked failed, with a 7-day wait and a notice, though it is healthy. This comes from reading the code; it has not been seen on a site ([[MAINT-17]]).
+- When the 15-minute demand forecast sensor counts the battery's own charge, the maintenance charge runs at about half the power the peak limit leaves, so it takes about twice as long. Seen on a site: about 1.2 kW instead of 2.5 kW, and the peak limit was kept ([[SAFETY-111]]).
+- One inverter: after a link drop, the battery's own safety stop to 0 W can be taken as a refusal, and the site stays at 0 W for up to 15 min ([[SAFETY-102]]).
+- After a Home Assistant restart, control still waits until Home Assistant has finished starting, which can take several minutes, though the readings are already there ([[SAFETY-115]]).
+- While Home Assistant is not answering, the page can list inverters as refusing commands and sensors as missing, and send you to Developer Tools, though they are fine ([[UX-37]]).
+- If Home Assistant hangs or stops, the page keeps saying "Waiting for Home Assistant" and never turns into an alarm ([[SAFETY-113]]).
+- Right after Home Assistant has started, the page can say for about 4 s that an inverter cannot be controlled, and the first command can come late ([[SAFETY-114]]).
+- After a Home Assistant restart, the controller status sensor can still say "running" while the add-on cannot control. It was seen once, and the cause is not known ([[SAFETY-116]]).
+- Battery modes on: after a planned top-up from the grid, the Batteries screen can say "Enough sun is forecast" ([[UX-32]]).
+- Battery modes on: the forecast line "we count on" can show more sun than the plan counts, because the plan takes house use off first ([[UX-33]]).
+- Battery modes on: before a planned top-up, the Today list shows a smaller "gives" amount than the plan will use; it grows as the charge happens ([[UX-34]]).
+- Two inverters, battery modes on: while the other battery is in its maintenance charge, a battery's card can say it charges from the grid while it stays at 0 W ([[OPT-18]]).
+- Two inverters, battery modes on: while a battery refuses to charge in a cheap run, the action log on the page gets about 8 lines an hour for its retries, and the page hint says "waiting for a better price" ([[UX-38]]).
+- A battery in a safety stop, or one the add-on cannot reach, can still be started for a cycle, and its drain then waits about 12 h and ends in a failed-cycle notice. This comes from reading the code; it has not been seen on a site ([[MAINT-19]]).
+- On the Settings page, the rows of the solar forecast lists are labelled "Phase 1", "Phase 2" instead of "Sensor 1", "Sensor 2" ([[UX-27]]).
+- In the solar forecast list, a blank or repeated row makes "source 2 of 2" count differently from the rows on the Settings page ([[UX-28]]).
+- The solar forecast message says "has no reading" also when the sensor shows a number that is too old or in the wrong unit ([[UX-29]]).
+- If you use only the forecast lists, two Settings notes sit on the single-sensor field, and one of them tells you to set that field ([[UX-30]]).
+- After a restart during a price outage, the "No prices" message can say "yet" when prices did come in earlier ([[UX-39]]).
+- On the new settings page, you cannot see whether a price service token is set. Check the Configuration tab ([[UX-41]]).
+- On the classic settings page, the first click on Save after editing a field can do nothing. Click again ([[UX-42]]).
+- A steady overload on a 1 s meter can warn, and send the Home Assistant notification, 2 or 3 times at the start of each 15-minute period instead of once. The peak limit is still kept ([[SAFETY-122]]).
+- A fixed tariff is priced once per hour, so a price window that starts or ends at :15, :30 or :45 gets the wrong price for part of that hour. Windows that start and end on the hour are right ([[TARIFF-23]]).
+- Step 6 of the setup wizard stays empty because of an error in the page, in English and in Dutch ([[UX-51]]).
+- On Dutch pages, refusal texts, the last-event line under the Home buttons, the installer details and the trading status sentences are still English, and a few Dutch texts read badly, such as "1 metingen geweigerd" ([[UX-52]]).
+- Some price texts say "hour" where the add-on acts on a 15-minute period, such as "cheapest hour" ([[UX-47]]).
+- After the add-on restarts, the Home price chart shows no price for the earlier part of today, and the setup check can say "12 of 24 hours", though the prices are known ([[UX-48]]).
+- With battery modes on and only batteries on "Leftover solar", the Home price chart can mark a cheap period where no battery charges ([[UX-49]]).
+- On a phone, the bars of the Home price chart are too thin to tap one 15-minute period. The arrow keys work ([[UX-50]]).
+- Control acts on Home Assistant readings that arrive late. With readings 10 s behind, the give run can swing and send up to 1.9 kW to the grid for about 50 s in a rig test; with readings 30 s behind, a battery can charge from the grid in an expensive period. Also in 0.19.2 ([[SAFETY-128]]).
+- In the last second of a 15-minute period, being a few watts over the aim can make the peak guard ask a battery for full power for one second. When a charge ends on a period edge, the last-second give can fade out over about 10 s, and a rig test exported up to 7.4 kW for about 8 s ([[SAFETY-124]]).
+- During the night grid charge, a 15-minute period can end 6 to 14 W over the peak aim, because the battery charges harder than asked. This was seen in simulation; a rig test saw 2 to 8 W ([[OPT-35]]).
+- The test rig could not bring back the false peak alarm that [[SAFETY-126]] fixes, so that fix is shown in simulation only. Watch the notifications for a few nights ([[TEST-35]]).
+- The night cheap run is sized for the batteries' full charging power, not for what the peak limit leaves. Under a tight limit the run can end before the batteries reach their level, and Home can show a level they do not reach (79.9 % against a shown 95 % in a rig test) ([[OPT-25]]).
+- By day, a Leftover solar plan that has only a daily forecast figure counts the sun from now, not from when the figure was read. It counts about 22 % too much for a figure one hour old; the night plan is not affected ([[OPT-30]]).
+- The night charge can buy too much in a house that uses more at night than by day, such as one with a car charger or heat pump, and on a sunny day, because spare sun in one expensive hour does not count for the later ones ([[OPT-31]]).
+- A cheap run that has already started can overlap a new give run after a re-plan, so a battery can charge from the grid at the dearest price for part of an hour. This was seen in a test case, not on a site. Also in 0.19.2 ([[OPT-32]]).
+- If the solar forecast sensors stop updating before 17:00, as in winter or further north, there is no forecast from three hours after their last update until 20:00 ([[OPT-33]]).
+- With a forecast that gives only a daily total, the sun is spread an hour off on the two clock-change days after the change. The day's total is right ([[OPT-24]]).
+- The add-on learns the house's use only once a solar forecast is set, so a site that adds a forecast later waits one more day for its first plan ([[OPT-26]]).
+- Home says "No trading on price yet: no prices have arrived" when every battery is on Solar first, though the prices are shown ([[UX-55]]).
+- The Home plan header can say "Charges in the cheapest hour, gives power in the dearest" when Home draws no charge, and it says "hour" for 15-minute prices ([[UX-56]]).
+- While the peak guard holds back charging, Home hides the rest of the cheap run and gives no reason. The charge starts again when the guard lets go ([[UX-57]]).
+- With battery modes on and selling on, Home can draw a "Sells up to" block when the add-on judges the trade not worth it, and then it will not sell ([[UX-58]]).
+- Home, the plan and the Forecast tab stop drawing a battery's give at the trading floor, though control goes on giving down to the battery's cut-out ([[UX-59]]).
+- During a price outage, the Batteries screen says "Prices differ too little" and Home says "The price gap is too small" ([[UX-60]]).
+- With battery modes on and no meter, or a meter that is a Home Assistant entity, a grid charge is not possible and nothing says so ([[UX-61]]).
+- On the Batteries screen, a charge the add-on refused in a cheap run reads as "Saves its power for ...", for up to 15 minutes ([[UX-62]]).
+- A Leftover solar battery with no capacity set never charges from the grid when a solar forecast is set, and nothing warns about it ([[UX-63]]).
+- The "How the modes work" box on the Batteries screen does not describe Cheap hours only ([[UX-64]]).
+- With battery modes on, Settings still shows "Trade on the price spread", which the modes ignore. A site with modes on and no price source starts, and the Batteries screen says "No prices, so it follows the house" without pointing to Settings ([[UX-65]]).
+- With battery modes off and several equal prices in a row, Home and the Forecast tab draw one price quarter, while the add-on trades every quarter of the run ([[UX-67]]).
+- Late in the day, the Forecast tab's "now" line and last bars sit over the axis labels at the right edge ([[UX-68]]).
+- The Forecast tab's level curve charges at each battery's full rating. Under a peak limit the levels it draws are too high and a charge block can end early (54.6 % shown against 39.7 % in a rig test) ([[UX-70]]).
+- The peak forecast check says maintenance charging is not kept under the peak limit when no peak forecast is set, but since 0.19.2 it is ([[UX-73]]).
+- The peak guard row can show the same figure twice, such as "at this rate 3 500 W, over 3 500 W". Also in 0.19.2 ([[UX-74]]).
+- If the inverter's setpoint entity appears in Home Assistant after the add-on has started, the page keeps saying "Inverter control: not found in Home Assistant" and the batteries say "An alarm stopped control" until a restart, though control runs ([[UX-75]]).
+
+### If you are crossing from a version older than 0.10.0
+
+`## 0.10.0` below can refuse an old config: `slew_w` above its limit, and the
+withdrawn `price_provider` ids `engie_dynamic`, `totalenergies_dynamic` and
+`eneco_eddy`. Read it before you update. Run `tools/predeploy_check.py` with the
+bare options (`jq '.data.options'`) first.
+
 ## 0.19.2
 
-### Not in a release yet
-
-- The night grid charge no longer raises "Battery stopped limiting the peak" when the 15-minute period stays on the aim. A steadily rising load now alarms a little later, and with a peak margin of 0 a period can end up to 10 W over the limit without this alarm ([[SAFETY-126]]).
-- A night grid charge for *Leftover solar* no longer stops at 03:00 when the solar forecast sensors went quiet in the evening. The evening's figure is used until 06:00, and a charge that has started goes on to its level ([[OPT-34]]).
-
-**A patch bump: two fixes, one for charging from the grid under the peak limit and one for the night charge of Leftover solar, and no option changes.**
+**A patch bump: one fix for charging from the grid under the peak limit, and no option changes.**
 No option was added, removed or renamed, and no default changed (86 options).
 **Existing installs need no option change:** options that start 0.19.1 also
 start 0.19.2. The change below applies with one inverter or two.

goodwe_controller/DECISIONS/FCST-03-the-hours-not-yet-published.md

@@ -0,0 +1,109 @@
+# FCST-03 - the hours the feed has not published, and what may not rest on them
+
+**Status: SHIPPED.** Tests: `test_price_forecast.py`, `test_price_history.py`.
+Written down by MAINT-20 from the long module comment of `app/price_forecast.py`.
+Follows specs.md 8.3: "Day-ahead prices arrive once daily. Until they do, unknown
+hours use yesterday's profile and are flagged `provisional: true`, and no
+irreversible action may be taken on a provisional price. Real-time / imbalance
+products are treated as high-volatility: arbitrage thresholds widen." This module
+owns the first two; the widening is in price.py (`Uncertainty`, `widen_factor`,
+`required_spread`), spent by `static_tariff.TariffPlan.arbitrage()` as one more
+refusal on its existing ladder. Persistence of yesterday: [[FCST-04]].
+
+## The flag is never passed through
+
+A carried point and a published one are the same three floats and a bool.
+`PricePoint(..., provisional=y.provisional)` copies yesterday's `False` onto
+today's guess: stale data presented as current (SAFETY-18's defect one layer up).
+So:
+
+- `_carried()` has no parameter for the flag; `provisional=True` is a literal in
+  one place.
+- A published point is passed through by identity (`filled.points[i] is
+  fetched.points[j]`, checked by the test), never copied.
+- `_audit()` re-derives the expected flag for every emitted point from the hours
+  the feed published and raises on a mismatch. It never corrects (a module that
+  quietly fixes its own provenance cannot be trusted).
+- test_price_forecast.py walks this file's AST and fails if any `PricePoint(...)`
+  passes anything but a literal for `provisional`.
+
+"Published" does not mean "firm": 9.3 carries `provisional` per point because a
+real-time product's current-interval print is published AND provisional, so the
+audit's rule for a published point is "whatever the feed said". No shipped
+plugin emits one since [[TARIFF-07]]; the rule is a property of the format and
+weakening it would let the first imbalance feed arrive mispriced and flagged firm.
+
+## The audit is a provenance check, not a completeness check (FCST-05)
+
+Rules: a PUBLISHED point must be one of `published[u]` by identity and be
+emitted once, with the feed's own flag; a CARRIED point's hour must not be in
+`published` at all, flag exactly True, and no second point in that hour. This
+replaced FCST-03's "at most one point per hour" count, which cannot express a
+quarter-hourly feed. FCST-04 claimed two strengthenings; both were false: a
+differential over every published mask on 3 hours crossed with every output of
+length 0-3 found zero divergence either way (OLD raised/NEW accepted 0, OLD
+accepted/NEW raised 0). The one real change is the intended relaxation (several
+distinct published points per hour).
+
+The audit does not check completeness: fed the decimation defect (four points in
+an hour, only the last emitted), two of four, or an empty output, it accepts.
+What stops decimation is the point COUNT and IDENTITY checks in the two test
+files. It cannot be made complete from its arguments: `published` is over the
+whole unwindowed read while the fill emits `[since, until)`, so a published point
+outside the window is legitimately absent. FCST-05 built "every published point
+is emitted" (+162 B) and it took the 1 h, 12 h and 48 h horizon checks red on a
+healthy feed (a real change: the differential scored it 49 cases stronger),
+so the rule as stated is wrong, and
+asserting a completeness the instrument lacks is MUTATION.md habit 16's defect.
+
+## The fill keys on the wall clock
+
+For each whole hour of the horizon the feed has not published, take yesterday's
+value for the SAME BRUSSELS WALL-CLOCK HOUR, not `t - 86400 s`: a 23-hour day has
+no 02:00 and a 25-hour day has two, so a fixed 24 h shifts every carried hour
+across a transition. On a 25-hour day both 02:00s are filled from yesterday's
+single 02:00 (both guesses, both flagged); if yesterday was a 25-hour day, the
+first of its two 02:00 points is used. An hour with no published price and no
+yesterday value is left out, not filled with a neighbour, mean or zero: 11.4
+applies (`Absence`, then the static profile). If nothing can be produced the
+result is `no_data`, not an empty series.
+
+A sub-hourly feed is not decimated: the hourly walk decides which hours need
+filling, never what a published hour may hold. Belgian day-ahead settles per
+quarter since 2025-10-01 (96 points a day), so every published point in the
+window is passed through and a carried one is added only for an hour with no
+published coverage. `{_utc_hour(p.start): p for p in r.points}` reads ordinary
+and keeps the last point of each hour; FCST-04's first caller shipped it, the
+series came out 15 points long, the spread fell from 0.143 to 0.014 EUR/kWh and
+the cheapest "hour" became a `:45` point. `_published_by_hour()` holds a tuple
+per hour for that reason.
+
+The window is whole hours at both ends: `since` floored (the current hour is
+still tradeable) and `until` floored too; with `until` compared raw a 48 h horizon
+asked at 08:17 emitted 49 hours. `yesterday` has no default (a missing yesterday
+and a useless one must not look alike). The fill is idempotent and re-runnable
+(5.4 late publication, 14-16 h CET): published hours win, and the series is
+rebuilt, not patched. TARIFF-11 log line: carried HOURS, total hours and
+published POINTS are three different quantities (a quarter-hourly feed made it
+read "33 of 141 hours" for 48 h).
+
+## AC2: the irreversible-action gate
+
+An irreversible action is a value, `Irreversible`, carrying the hours it commits.
+`price_permits()` looks at exactly those hours and answers with a `Gate` carrying
+evidence on the permitting arm and a reason on the blocking one (the `_Outcome`
+shape). It blocks when the read observed nothing (11.4), an hour has no price, or
+an hour is provisional, and names the hour. The maintenance drain's window is
+derived from `maintenance.DRAIN_TIMEOUT_MIN` / `CHARGE_TIMEOUT_MIN`, so the gate
+and the phase machine cannot drift. `_window_hours()` is separate so the gate and
+its caller agree on "the hours it commits".
+
+What is NOT gated matters more: the maintenance cycle is a calendar obligation
+(12.2: a cycle that silently never fires looks like one not yet due), and a site
+with `price_provider: off` (the default) has no series. Routing every start
+through a gate that blocks on `no_data` would stop the monthly cycle on every
+default install. So `begin_phase()` is the entry point for a start JUSTIFIED BY A
+PRICE; main.py's calendar path is untouched, and OPT-04 / MAINT-05 own which a
+site runs. Reversible actions (self-consumption modulation, the loop) are not
+gated: 6 says absent machinery must not disable the loop. Read this before wiring
+`begin_phase()` in.

goodwe_controller/DECISIONS/FCST-04-the-day-that-is-carried.md

@@ -188,3 +188,64 @@ still raises; so does the same published point emitted twice; and a carried
 point sharing an hour with a real print now raises too, which the count never
 looked at. Each of those three is driven by its own mutation in
 `test_price_forecast.py`.
+
+## 5. Store details (moved here from `app/price_history.py` by MAINT-20)
+
+**Why a file, and which one.** FCST-03 shipped the fill with no caller, so no
+series ever contained a carried point. Without a yesterday that survives a
+restart, the mornings after an operator touched something spend the whole
+window on the truncated series. The cache is `/data/price_history.json`, not
+`/data/state.json`: `Store.set()` rewrites the whole of state.json on each
+write, and the refresh runs every `TARIFF_REFRESH_S` (1800 s), so 48 extra
+rewrites a day would go through the file whose corruption reads as "no
+maintenance ever ran". Separate file, separate blast radius. The directory is
+not created (`tariff.PeakStore`'s rule): `/data` is always mounted, so a
+`makedirs` could only succeed where the durable volume is missing and build a
+cache on the ephemeral layer. "Cannot persist" is one question asked after the
+attempt: see [[FCST-06]]; `self._days` never holds a point the file does not.
+
+**Brussels date, not UTC.** 23:30 UTC in July is already tomorrow in Belgium.
+`_yesterday_of()` subtracts on the local `date`, not the instant: the old
+`brussels(stamp) - timedelta(days=1)` took 24 absolute hours and, at
+2026-03-30T00:30+02:00, returned 2026-03-28 (a two-day-old profile flagged as
+yesterday's). Rows are keyed by instant, not local hour, so the two 02:00s of
+the 25-hour October day both survive and `fill_from_yesterday()`'s own rule is
+the only collapsing rule. The merge key is the validated instant; the old
+string key merged by spelling and sorted the `+01:00` 02:00 before the `+02:00`.
+`KEEP_DAYS` is a sort-order cap, not a horizon: nothing is deleted by arithmetic
+against the clock (a jumped clock, WITNESS-03, would otherwise delete everything
+on the one morning the fill is for), and the two dates `yesterday()` can be
+asked for are pinned on top of the cap, which can only retain.
+
+**One validator (FCST-05, MEDIUM).** The read path was defensive about every
+field and the write path trusted `q["start"]` to be hashable and sortable. An
+int, null, dict or list `start` raised `TypeError` out of `carry()` on the day
+being written; `run_tariff_refresh` caught it, so the add-on stayed up and every
+refresh failed for good (the plan retires after `TARIFF_MAX_AGE_S`, arbitrage and
+the cheap window go off, and `_remember()` raised before `_save()`, so no
+self-heal). `_point_of()` is now the one standard for both paths and returns
+`None` rather than raising.
+
+**A broken cache is a short horizon, never a controller that will not start**
+(6: absent machinery must not disable the loop). `PriceHistory(...)` and `.words`
+are unguarded in `Controller.__init__`. Shipped defects, all fixed:
+
+- `_load()` caught `json.JSONDecodeError` and `OSError` only; one non-UTF-8 byte
+  raised `UnicodeDecodeError` (a `ValueError`, not an `OSError`) and the add-on
+  did not start (FCST-05, HIGH). The handler names the `ValueError` family. The
+  schema version is compared with its type (`1.0 == 1` in Python).
+- `{"days": {"2026-01-14": "oops"}}` loaded as healthy and raised
+  `AttributeError` out of `words`, `yesterday()` and `resolve_tariff()`.
+  `_usable_days()` drops such records, and counts (not drops) malformed rows
+  inside a kept record so the store stops reporting health it lacks.
+- `words` printed `f"{d} ({_n_points(rec)} h)"`: points under the hour's name
+  (`'2026-01-13 (96 h)'` for a 24-hour quarter-hourly day, FCST-05 LOW). Both
+  numbers are printed now; only rows that are points are counted. `words` must
+  never raise, `_held()` is total.
+- A failed merge is undone from a deep copy (a one-level copy shares the day
+  records the merge rebinds).
+
+`NO_HISTORY` is a name, not `None`, so `history=` can be required: `None`
+meaning "skip the fill" is how a caller silently gets the truncated horizon.
+`carry()` records first, then fills, so the filled series exists only as a
+return value that the store never sees again (rule 1).

goodwe_controller/DECISIONS/OPT-34-the-night-charge-keeps-its-level.md

@@ -34,6 +34,13 @@ known, so the add-on does not depend on it.
    midnight, so a 09:05 reading, unusable since 21:05, does not come back for five
    minutes after midnight. Same-day figures and the daytime rule keep 12 h and 3 h.
 4. A fresh figure replaces the kept one at once, as before.
+   *Rig F-1 fix:* once every today sensor has given a fresh reading after
+   midnight, the evening figure is no stand-in for that day any more
+   (`Hold.replaced()`). When that reading goes stale (3 h), it is kept or not
+   as any today reading (OPT-27), so it is "no forecast" at night and the latch
+   keeps the level it set; the older 17:05 figure never comes back. Rig: A
+   stopped at 69.5 % after a brighter 02:00 figure, then charged back to 94.4 %
+   from 05:15 when the 17:05 figure returned. Test: `test_opt34.py` F-1.
 
 **Step 1 alone is enough for the owner's shape, steps 2-3 are still needed.**
 With the window put back to midnight + 3 h the owner's night still ends as a
@@ -59,4 +66,4 @@ A fresh figure that LOWERS the level during a charge still lowers it, as before.
 **Mutants** (all red in `test_opt34.py`): no latch; window back to midnight + 3 h;
 15 h without a limit; no "usable at midnight" rule; the latch without the narrow
 gap, without its save, or not kept through the next run; the window 6 h after
-midnight instead of 06:00 local (DST); 15 h cut to 12 h; the new screen line off or shown without a cheap run; no expiry check; no pruning of a changed mode; no night bound; a left-the-plan battery keeping its level.
+midnight instead of 06:00 local (DST); 15 h cut to 12 h; the new screen line off or shown without a cheap run; no expiry check; no pruning of a changed mode; no night bound; a left-the-plan battery keeping its level; no `replaced()` check (F-1); `replaced()` with one of several today sensors (any, not all).

goodwe_controller/DECISIONS/SAFETY-07-peak-guard.md

@@ -0,0 +1,166 @@
+# SAFETY-07 - the quarter-peak projection guard (with SAFETY-24 and CFG-03)
+
+**Status: SHIPPED.** Tests: `test_peakguard.py`. Written down by MAINT-20 from
+the long module comment in `app/peakguard.py`, so the module can stay short.
+Later changes have their own notes: [[SAFETY-25]], [[SAFETY-32]], [[SAFETY-45]],
+[[SAFETY-79]], [[SAFETY-81]], [[SAFETY-87]], [[SAFETY-90]], [[SAFETY-125]],
+[[SAFETY-126]].
+
+## The hazard
+
+The capacity tariff bills the month's single worst 15-minute average offtake,
+with no averaging and no forgiveness. specs.md:583 records one 4998 W quarter
+that moved a monthly peak from 4832 W to 5013 W and billed the whole month at
+it. SAFETY-18 alarms on a frozen meter (`meter_freeze_s`, 300 s) but a frozen
+meter can rail the command in 75 s (freeze.py's table, `max_w: 5000`, meter at
+3000 W or more), against a 900 s quarter. The guard is the cap on that. It
+reads freeze.py's `looks_frozen()`; it is not a second freeze detector.
+
+## The mechanism: one `lo` limit at `P_PEAK`
+
+specs.md 10.1 row 2 wants pre-emptive discharge near the limit and a hard clamp
+on charging above it; 9.1 says discharge and export are never capped by the
+peak guard. A lower bound on the setpoint is the only shape that does both: a
+floor cannot stop the loop discharging harder (so 9.1 holds by structure), it
+clamps charging when above the standing charge, and it forces discharge when
+above zero.
+
+- `P_PEAK` (50) is above `P_LOOP` (10) and below `P_MAINTENANCE` (60) and
+  `P_SAFETY` (100). arbiter clause 2 applies only limits at or above the
+  winning set's priority, so a P_SAFETY 0 W stop is not pulled off zero.
+- A limit does not out-vote another limit: clause 2 takes the most restrictive
+  with no priority between limits. The floor (`lo >= 0`) and the maintenance
+  charge-only shaping (`hi <= 0`) therefore resolve to `lo > hi`, a
+  contradiction, which the arbiter answers with 0 W (battery parked in the
+  worst quarter). The rule for two crossing limits is suppression, not
+  priority: main.py drops the shaping while the guard is engaged
+  (`shaping_suspended()`). The floor is clamped to `achievable_w` to close the
+  only other crossing pair (the P_SAFETY rating bounds).
+- Arbitrage arrives as a SET below `P_PEAK`, so clause 2 binds it with this
+  floor without any edit here (9.1: peak shaving outranks arbitrage).
+
+## The floor is derived
+
+With `projected = (acc + held * remaining) / 900`, the watts that must come off
+the meter are `excess_w = 900 * (projected - ceiling) / remaining`, and the
+floor is `floor_w = batt_w + excess_w`.
+
+1. The claim is filed while the floor is positive, not while the excess is.
+   `excess` falls to zero as soon as the battery is already removing it, and a
+   guard that released there handed the actuator back and re-engaged next
+   cycle. The first cut did that on 2026-08-20's billed quarter: 17
+   engage/release cycles in 900 s, and the quarter still ended 49 W over.
+   Thresholding `batt_w + excess` (the offtake with the battery at zero, less
+   the level the quarter can afford) decays continuously, so there is no
+   hysteresis constant. 10.2: an EMS that oscillates is worse than none.
+2. The gain 900/remaining is 1.0 at the start of a quarter and grows. The guard
+   is gentlest when its evidence is weakest. No minimum-evidence threshold was
+   added: it would delay the guard on a sustained rail from second zero.
+3. `batt_w` is the measured battery power, not the command. The bill is what
+   flowed, and a floor built on the command winds up to the rail when the
+   inverter cannot follow; one built on the measurement stops rising when
+   delivery does.
+
+## The ceiling
+
+`ceiling_w = max(peak_cap_w, the month's banked peak)`. Once a month's peak
+stands at 5013 W, holding later quarters to 3500 W buys nothing. Only an
+`OBSERVED` reading may raise it; `NO_RECORD` and `NOT_OBSERVED` leave it at
+`peak_cap_w`, so a peak store that cannot be read makes the guard stricter,
+never looser. That is also why the guard does not use `headroom_w()`: a peak
+read as 0 W returns full headroom, which is a guard that is not there.
+SAFETY-79 aims `peak_margin_w` under the ceiling; the ceiling stays the real
+limit for reports and the bill.
+
+## Blindness comes first
+
+The projection is graded only if the quantity under it was measured. Three
+ways it was not, checked before grading:
+
+- No open block: a fresh averager answers an all-zero `Projection`, which sits
+  under every ceiling. That is "no quarter", not "the quarter is fine".
+- Coverage: a meter gap longer than `max_hold_s` leaves seconds the averager
+  does not accumulate (holding a dead meter's value forward is how a fabricated
+  peak gets onto a permanent record), so the projection reads low. The
+  threshold is `max_hold_s`, not a new number. SAFETY-90 fills gaps once
+  readings return.
+- Frozen: samples keep arriving, coverage is perfect and the projection is a
+  confident zero while the real meter is at the rail.
+
+The blind action is `floor_w = 0.0`: no importing while the billed quantity
+cannot be observed. It is one-directional (forbidding charge only lowers
+offtake), so a false blindness costs a charge and never pack energy.
+
+## Why it trips where SAFETY-18 only notifies
+
+The healthy-day false-engagement rate is zero (2026-08-23, 95 quarters;
+test_peakguard.py re-measures it from the committed capture). The action is
+level-triggered and unlatched: it is re-derived each cycle and releases when the
+projection drops, so a false engagement costs one cycle, not a parked battery.
+It is a limit, so every safety stop outranks it. It is the only guard whose
+trigger is the billed quantity itself.
+
+## Saturation is reported, not alarmed as a bug
+
+10.3 treats an out-of-range setpoint as a bug (SAFETY-03). A peak floor above
+the inverter rating is not: it is a 5900 W house on a 5000 W inverter (2026-08-20
+15:45). The floor is clamped to `achievable_w`, the decision carries
+`saturated`, and main.py raises one notification.
+
+## SAFETY-24: the energy backstop the guard shipped without
+
+The graded branch can force discharge (878 Wh in a day on the 2026-08-20 replay)
+and nothing below it consulted the state of charge; the BMS was the only
+backstop, which protects the pack and not the operator. `decide()` now takes
+`soc` and `soc_floor` and `discharge_permitted()` answers.
+
+1. Not a trip. When it binds, the guard stops asking for more discharge and
+   commands nothing; every stop in 11.2 still outranks it.
+2. The action is `floor_w = 0.0` (forbids charging, forbids nothing else). A
+   `lo` limit cannot cap discharge, and a negative floor would destroy that.
+   The loop is not bounded: self-consumption may still drain the pack past the
+   floor. [[SAFETY-25]] measured it (2026-08-20, 19:00-22:00 UTC, 830 W mean:
+   the pack ends at the BMS floor, 10.0 %, whatever `peak_soc_floor` is) and the
+   owner decided on 2026-09-02 that the BMS stays the only backstop for
+   demand-driven discharge, a loop-side reserve being deferred to ALLOC-01.
+3. Graded only after `wanted > 0`, where a forced discharge is asked for.
+4. An unreadable SoC is not a full battery. `soc=None` and `soc_floor=None` are
+   floor-limited. Both arguments are required keyword-only, no default (TEST-14).
+5. Failing to shave is not silent: `floor_limited=True` and one notification.
+   It excludes `saturated`, since it asks for nothing.
+
+The action log says "the peak reserve", not "the SoC floor": `peak_soc_floor`
+(“Peak reserve”) bounds this guard only, and the wider words would contradict
+a loop that is draining the pack at that moment.
+
+## CFG-03: two options, mirrored once
+
+- `peak_soc_floor` is the EMS floor, not `maintenance_soc_floor` (the monthly
+  recalibration's drain target); sharing a key would couple features whose
+  right values differ. Default 20: the reference pack is 300 Ah at 51.2 V,
+  DoD 90, 13.8 kWh usable; the replay's 878 Wh is 6.4 %; a floor 10 points above
+  the 10 % cut-out leaves about 1.6 worst days of room.
+- `bms_soc_floor` is the pack's own cut-out (register 0x0560, 10 on the
+  reference unit). It exists so validate.py rule 8 can refuse a
+  `peak_soc_floor` at or below it.
+- Both defaults live once in `PEAK_OPTION_DEFAULTS` (TARIFF-02's pattern),
+  imported by validate.py and main.py and pinned to config.yaml by the test.
+  The module reads no option itself.
+- `maintenance_soc_floor` is the ambiguous name of the two. Decision: keep it,
+  carry the distinction in DOCS.md; revisit if a third floor appears.
+- SAFETY-07 itself added no option: `peak_cap_w` was already validated
+  `int(500,15000)`, and 14's `capacity_peak_limit_kw` stays declined (a kW key
+  beside a W key is the mismatch trap).
+
+## Per-pack floors (SAFETY-32) and phases
+
+`bms_soc_floor` became a roster key; `pack_floor_pct()` conjoins it with the
+site's EMS floor, and rule 8 names the unit it refuses. `peak_soc_floor` stayed
+one number for the site, so with cut-outs of 10 and 18 the operator sets it
+above 18; the per-pack EMS floor is the open question in [[SAFETY-32]]. The
+`min()` over measured SoC (`Controller.pack_floor_soc`) is still right for the
+site verdict; `pack_permissions()` is the per-pack answer.
+
+Nothing here reads a per-phase quantity: the sum/max/net choice is an open
+owner question, defaulted to NET inside `billed_w()`, so this file does not
+change whichever way it is answered.

goodwe_controller/DECISIONS/TARIFF-02-price-provider-plugins.md

@@ -0,0 +1,273 @@
+# TARIFF-02 - price provider plugins, and the canonical shape (with later additions)
+
+**Status: SHIPPED.** Tests: `test_price.py`, `test_price_service.py`. Written
+down by MAINT-20 from the long comments of `app/price.py` so the module can stay
+short. Related: [[TARIFF-07]], [[TARIFF-09]], [[TARIFF-10]], [[TARIFF-14]],
+[[TARIFF-15]], [[PRICE-01]].
+
+## Where it lives
+
+specs.md 2.2 puts this at `ems/ingest/prices/`; that layout is not being built.
+Owner decision 2026-08-30: everything ships in `goodwe_controller/app/`. The
+behaviour in specs.md 9.3 / 8.3 / 11.4 is unchanged and authoritative.
+
+## The canonical format (9.3)
+
+`{"prices": [{"start": "2026-01-15T00:00:00+01:00", "eur_per_kwh": 0.1834,
+"provisional": false}]}`. `start` is tz-aware at the Brussels offset for that
+instant, the price is EUR/kWh and all-in, `provisional` is per point (8.3: no
+irreversible action on a provisional price). Three fields; a fourth would change
+the wire format every store, fixture and captured body is written against.
+
+## Three rules the module is shaped by
+
+1. **Double-counting markup is refused, given a correct declaration.** A plugin
+   returns `RawPoint`s with the figure its source published and declares in
+   `capabilities().sources` which of {ENERGY, MARKUP, TAXES} it already holds.
+   `assemble()` (framework only) adds the complement from `price_markup_eur_kwh`
+   / `price_taxes_eur_kwh`. A plugin cannot reach those two numbers by any route:
+   `PluginOptions` raises `FrameworkOption`, and review of PR #16 wrote a
+   double-counting plugin three more ways (`opts._o`, `price_option()`, and the
+   public `PRICE_OPTION_DEFAULTS`), so `register()` also refuses any plugin
+   whose own code mentions a framework key (`code_leaks()`). The guarantee is
+   exactly this: the complement is added once *given a correct `sources`*. A
+   plugin declaring `{ENERGY}` for an all-in feed comes out one markup high and
+   no code can catch that. test_price.py checks that a plugin's docstring lines
+   (`SOURCES:` / `The framework ADDS:`) agree with its declaration, not that
+   either is true. `code_leaks()` strips docstrings before searching (they must
+   name the components) and fails open on missing source (a frozen build must
+   still start; CI asserts source is found for every shipped plugin).
+2. **The product type is declared, not inferred from the id.** `capabilities().
+   product` is a `PriceProduct`, rides on the series, and `volatility_regime()`
+   reads it (8.3: real-time products widen thresholds). A plugin id appears only
+   in `PROVIDERS`, `RETIRED_PROVIDERS` and its own class (AC2). No shipped plugin
+   declares `REALTIME` since [[TARIFF-07]]; `_WIDE`, `Uncertainty.REALTIME_PRODUCT`
+   and `WIDEN_FACTOR`'s 2.5 are kept, and test_price.py section 10 declares
+   REALTIME from a class outside this file to keep them live.
+3. **"No price data" is a type, not an empty list.** 11.4: no data means static
+   profile, provisional plan, no arbitrage; all-zero prices mean arbitrage is
+   merely pointless. `PriceRead.series()` refuses an empty list;
+   `PriceRead.no_data(reason)` carries `.reason` and nothing else, so
+   `min(read.points)`, `for p in read.points` and `.get("points", [])` raise
+   `Absence`; `.match(*, series, no_data)` takes both handlers as required
+   keywords. Same shape as `sim/riglock.py` after TEST-04 (read its `Absence`
+   block before changing this). Two ways past it survive and are not worth code:
+   `vars(read).get("points", [])`, and `bool(read)` being True for both
+   variants (a falsy `no_data` would turn `if read:` into a guard by accident;
+   use `.match`).
+
+## Timezone without `zoneinfo`
+
+The Alpine image has no `tzdata`, so `ZoneInfo("Europe/Brussels")` would raise
+on the client's Pi. Every instant is UTC and rendered at its fixed offset, so
+the October 02:00-03:00 hour that happens twice is two instants (`02:00+02:00`
+and `02:00+01:00`); a naive-local-hour key or a 24-slot array is wrong on both
+transition days (test_price.py counts points on both 2026 transitions). The EU
+rule: CEST from 01:00 UTC on the last Sunday of March to 01:00 UTC on the last
+Sunday of October. Review of PR #16 matched it against `zoneinfo` over 149 040
+hourly instants 2020-2036 with zero mismatches. Residual risk is political (EU
+abolishes the change): one edit in `brussels_offset()`.
+
+## The feed range (TARIFF-09)
+
+`generic_dayahead.fetch()` used to ignore `since`/`until` and request the bare
+URL, so the feed answered ONE Brussels day and 8.3 dropped everything past today
+as provisional: at 09:00 over a 48 h horizon 15 firm and 33 carried, at 23:00 1
+firm and 47 carried. `feed_days()` returns the Brussels calendar days (first,
+last, both inclusive; the API takes dates) that the half-open `[since, until)`
+touches: Brussels, never UTC (22:30 UTC in summer is already tomorrow); `until`
+exclusive, so local midnight belongs to the day before; an empty or inverted
+window collapses to one day. `api.energy-charts.info` capture:
+`scenarios/energy-charts-be-price-2026-09-09_2026-09-10-twoday.json`.
+`dated_feed_url()` refuses a base that already has a query string (appending
+would give `?bzn=BE?bzn=BE&start=...`). An operator's `price_feed_url` override
+is used verbatim and loses the range, on purpose: rewriting an operator's URL
+reorders and re-escapes it, and both providers declare a second host
+(`web-api.tp.entsoe.eu`) whose parameters are not `start`/`end`. The cost is
+logged at fetch time, naming the horizon consequence. The URL rule is shared by
+`generic_dayahead` and `custom_formula` (TARIFF-15), taking `plugin_id` as an
+argument so AC2 holds. The "range is used" promise is not mechanically enforced
+(a rule would be satisfied by an invented parameter name); test_price.py pins
+which plugins consume the range as a literal roster.
+
+## Absence and the covering window
+
+See [[TARIFF-14]] for the cover table: a point covers from its own start to the
+next point's start, never more than an hour; the last point gets the span of the
+one before; sorted at construction. `covers()` delegates to `at()` (a second copy
+of the rule is a second place to be wrong); `window_points()` grades only the
+`start` against `[since, until)` and is not a coverage query. `at()` is a linear
+scan over about 192 entries on the 30 s path; a bisect is not worth a second
+way to be wrong. A duplicated start (not reachable through `load_prices()`)
+gives the earlier entry a zero-width window.
+
+## Taxes components (TARIFF-18)
+
+`price_taxes_eur_kwh`'s default (0.06 before) is the sum of
+`FLEMISH_TAXES_COMPONENTS_EUR_KWH`, each row one line of the Eneco residential
+card for Flanders, September 2026, including 6 % VAT, in EUR/kWh;
+test_price.py section 1b re-adds them. It is per DSO: the distribution row runs
+5,28 c (Midden-Vlaanderen) to 6,70 c (West), so the all-in Flemish total runs
+about 0.117 to 0.131; a site outside Antwerpen types its own. The default sits
+near the low end on purpose: the scalar cancels in `max - min`, and its one
+decision is the 17 negative-price guard in arbitrage.py, which tests the
+absolute all-in sell price. Too high carries a genuinely negative hour above
+zero (export into paid-for disposal); too low only declines a trade that would
+have paid. `energiebijdrage` is a row of zero: from 1 August 2026 it is merged
+into the bijzondere accijns, and the zero row makes the double-count a visible
+decision. Moving a shipped default changes which configs start: TARIFF-17's rung
+in validate.py refuses `price_taxes_profile` together with a non-default scalar,
+comparing against the default (the Supervisor merges every schema key into the
+stored blob, 70 of 71 keys on the reference install, CHANGELOG 0.9.0), so a
+superseded shipped default (0.06) must still read as untouched, and the rung's
+sentence names both figures.
+
+## One in-code mirror of option defaults (CFG-03)
+
+Option defaults live in config.yaml's `options:` and `schema:` and main.py's
+`.get()` fallbacks. `PRICE_OPTION_DEFAULTS` is the single in-code mirror for the
+price options: validate.py imports it, main.py has no `o.get("price_...", X)`
+fallbacks, no dataclass carries a copy, and test_price.py section 1 reads
+config.yaml and asserts equality key for key. `static_profile` (TARIFF-03),
+`price_taxes_profile` (TARIFF-17), `price_formula` (TARIFF-15),
+`price_export_formula` (TARIFF-16) and the OPT-04 keys live there for the same
+reason, not in their own modules (a second dict would be a fourth location).
+Details:
+
+- The tables / formulas are in `FRAMEWORK_KEYS`: a plugin reading one could add
+  taxes a second time per hour, or fold an injection curve into a consumption
+  price. `BANNED_IN_PLUGIN_CODE` derives from that set.
+- `arbitrage_soc_floor` / `arbitrage_soc_ceiling` are not the maintenance keys
+  (a balancing cycle is not a trading reserve).
+- `cycle_cost_threshold_eur` is 0.10 because 10.1's name says so, not because it
+  makes anything trade: on Belgian day/night numbers the static spread is about
+  0.08, so a static-tariff site does not trade at this default (test_arbitrage.py
+  section 7). Whether 0.10, or FCST-03's 2.5 / 1.5, is right is an owner
+  decision.
+- `price_service_token` is a secret (`SECRET_OPTIONS`); `scrub()` removes secret
+  values from any text built from an error.
+
+## Widening (FCST-03)
+
+One path, a set of active uncertainty sources (real-time product 8.3, no weather
+data 11.4). The combination rule is `max`, not a product (2.5 x 1.5 would give a
+threshold nothing on a Belgian tariff clears). The factors are policy defaults,
+not derived (no arbitrage ever ran); they differ so `max`, `sum` and `product`
+are distinguishable in a check. `widen_factor()` refuses a string (a silent 1.0
+would report a widening that is not applied).
+
+## Injection price (AC4, TARIFF-16)
+
+`export_price_eur_kwh()` is a separate scalar. It was said to be so because
+nothing dynamic exists to route; that was false (Eneco publishes `0,1 x BELPEX-H
+- 1,188`, ENGIE `(B x eSpot_15) - A`). The true reason: an injection curve has
+its own coefficients and VAT treatment (injection is VAT-exempt, consumption is
+6 %). TARIFF-16 added `price_export_formula`, read by `export_formula()` through
+the same parser as the consumption leg (`parse_export_formula()` is
+`parse_price_formula()` with its option name moved). `export_price_at()` falls
+through to the scalar and ignores the index, correctly. A negative answer is a
+real answer (Eneco's formula is below zero for any index under 11,88 EUR/MWh);
+nothing floors it. Nothing under `app/` calls either reader to take a decision:
+arbitrage prices the sell side as displaced import. A malformed leg is refused at
+startup by validate.py; `taxes_profile()` and `export_formula()` still handle it
+loudly at run time. `static_tariff` is imported lazily in `taxes_profile()`
+because it imports this module at module scope.
+
+## Taxes at each point's own instant (TARIFF-17)
+
+`taxes_at()` takes a scalar or a period table (duck-typed on `price_at`, because
+price.py must not import static_tariff.py). A non-flat component matters: ORES
+bills `dag 13,27 / nacht 7,39` c, a 5,88 c gap coinciding with the cheap spot
+hours, and flattening it understates the spread. `assemble()` must evaluate it
+per point; hoisting the lookup out of the loop collapses the feature back into a
+level (test_price.py section 24 grades which hour is cheapest, since a
+spread-magnitude assertion passes on the hoisted version). On a scalar, `0.0 +
+markup` is exactly `markup` in IEEE 754, so scalar sites get identical bytes.
+The table wins over the scalar; validate.py refuses configs where both speak.
+
+## Retired providers (TARIFF-07)
+
+`RETIRED_PROVIDERS` exists so `eneco_eddy` and friends are not refused as typos:
+they were shipped, the operator chose them, and every failed fetch fell back
+silently to `static_profile`. No alias to `generic_dayahead`: they published
+retail prices (`B x spot + A`) and it reads wholesale; an alias would invent the
+site's two coefficients (behind the klantenzone login; CREG tariff-card pages
+404, VREG unreachable). Each value is the id-specific half of the refusal (the
+endpoint, what it answered on 2026-09-13, why no replacement can be built);
+validate.py owns the framing. `register()` refuses at import to register a
+retired id again, because `pid in PROVIDERS` going true silences the named
+refusal; re-shipping is a decision recorded by removing it from
+`RETIRED_PROVIDERS` in the same commit. See [[TARIFF-07]].
+
+## Parsers (TARIFF-08)
+
+The only parser is columnar: `https://api.energy-charts.info/price?bzn=BE` gives
+parallel `unix_seconds` / `price` arrays plus `unit`. The earlier row parser read
+`doc["data"]`, a shape no feed ever published, graded by fixtures written from
+the same guess, so every fetch ended `SourceUnavailable` and 11.4 fell back to
+static silently. Two shapes, two functions: a parser that sniffs can decide
+wrong, and a wrong-but-parseable response becomes a price.
+`_points_from_columnar_json()` refuses:
+
+- unequal arrays (`zip()` would truncate the evening peak, and a series missing
+  the expensive hours is traded on while no-data switches arbitrage off);
+- a unit other than the declared one (EUR/kWh under the same keys would be 1000
+  times too small and `MAX_PLAUSIBLE_EUR_KWH` bounds only the large side);
+- naive time: `unix_seconds` are UTC (`fromtimestamp(t, timezone.utc)`).
+  Rendering at the Brussels offset is `assemble()`'s, once, for every plugin.
+
+A `null` price is dropped and logged (the pairing is reliable, the source said
+it published none; `_Series.at()` answers the hole with `Absence`);
+`scenarios/fetch_epex_be.py` dropped 0 nulls in 12 months to 2026-08-31. The
+feed is quarter-hourly since Belgium's 15-minute MTU (2025-10-01); nothing
+assumes either granularity (test_price.py section 2b replays both).
+`_validate_raw()` accepts negative prices (windy-Sunday hours are the year's best
+charging; 17 keeps the regression) and rejects NaN, infinity, an implausible
+magnitude, naive datetimes, and duplicate or out-of-order starts.
+
+## Transport and plugin details
+
+- `check_host()` splits the scheme before parsing the host. The first version
+  stripped `len("https://")`, which on `http://` ate two characters of the host
+  (`pi.energy-charts.info`), so a non-TLS feed failed the allow-list and the check
+  "plain http is refused" passed even with the TLS rule deleted. Found by
+  mutation in review of PR #16.
+- The default transport imports aiohttp lazily so `manual_csv` works with no HTTP
+  stack. With `headers` (price_service only) it answers in the safe words of
+  `status_words()` and follows no redirects (the host is fixed; a redirect would
+  take the token somewhere the allow-list never saw).
+- `manual_csv`: the CSV is all-in (the plugin cannot know what a typed number
+  contains); `load_prices()` warns when markup / taxes are set non-zero under a
+  plugin that sources them. No transport, aiohttp, network or tz database: it is
+  the offline escape hatch and the TEST-01 replay ingest path.
+- `custom_formula` (TARIFF-15) declares `{ENERGY, MARKUP}`, not `ALL_IN`: a
+  card's `Tariefformule` is the energy component only (Eneco tabulates network
+  tariffs separately; ENGIE excludes network, transport, levies, excise), so
+  `ALL_IN` would drop about 12 c/kWh. The risk left is an operator folding
+  network charges into `offset`; the card self-check in custom_formula.py refuses
+  that, and grades the coefficients against the card, not the card against
+  reality. No expression evaluation: the string is settable over HTTP through
+  the ingress config page, so `eval` would be RCE in a root container holding
+  `SUPERVISOR_TOKEN`. It reuses `generic_dayahead`'s feed, URL and parser. It
+  keeps `scale=1.0`, so its `RawPoint`s carry EUR/MWh in a field called
+  `eur_per_kwh`: contained (destructured on the next line, never leaves the
+  method; `_validate_raw()` would refuse an escape).
+- `startup_preview()` is a hook (TARIFF-15), not a line in `load_prices()`: only
+  the plugin knows what went into its arithmetic, and the index beside the
+  all-in figure makes a factor of 1000 obvious. It must not raise into the control
+  path; the id is recorded before the hook runs so a failing preview is not
+  retried every 30 minutes.
+- `load_prices()` returns, never raises, except `FrameworkOption` (a plugin trying
+  to read the markup; turning it into "no price data" would hide the defect).
+- `price_provider_id()` is one spelling of the selected id because the same
+  expression was written at three call sites (TARIFF-10). validate.py keeps its
+  own reader on purpose: it validates the raw blob.
+- `price_provider_selected()` (TARIFF-10): the background refresh used to start
+  only when `arbitrage_enabled` (ships false) was on, so a configured site
+  fetched nothing (40 h soak: zero feed requests, `present: false` on all 802
+  samples). It is not a trading switch: `arbitrage.enabled()` answers that.
+- `price_service` (PRICE-01): `FALLBACKS` and `KEEP_LAST` are empty/False for
+  every earlier plugin, so `price_chain.py` is not used for them.
+  `TOKEN_REFUSED` is the one phrase the fallback chain reads to tell "the owner
+  must act" from "the server is down". `covers` lists complete days only; an hour
+  missing inside a day is a hole, not a free hour.

goodwe_controller/DECISIONS/TARIFF-16-the-injection-leg.md

@@ -0,0 +1,102 @@
+# TARIFF-16 - the injection leg of a dynamic contract (`price_export_formula`)
+
+**Status: SHIPPED.** Tests: `test_price.py` (17 series). Written down by
+MAINT-20 from `app/custom_formula.py` and `app/price.py`. Follows [[TARIFF-15]],
+whose parser it reuses.
+
+## Why a formula, not the scalar
+
+`price.py` modelled injection as one scalar. The market publishes a line a
+scalar cannot hold:
+
+    Eneco Zon & Wind Dynamisch   0,1 x BELPEX-H - 1,188   c EUR/kWh
+    ENGIE Dynamic                (B x eSpot_15) - A
+    Aspiravi (non-dynamic)       0,07 x Belpex - 2
+
+1. Its own factor (Eneco 0,102 on consumption, 0,100 on injection; Aspiravi 0,07
+   against about 0,10): not the consumption `B` with a sign flip.
+2. A negative offset (`- 1,188`, `- 2`); `price_markup_eur_kwh: float(0,1)`
+   cannot express one.
+3. VAT-exempt ("Injectietarieven zijn vrijgesteld van btw") against 6 % on
+   consumption: representable only because `vat_pct` is per spec.
+4. It goes negative with no floor: Eneco's is below zero for any BELPEX-H under
+   11,88 EUR/MWh, the hours a PV household exports in. You can be charged to
+   export.
+
+`price_export_formula` is `custom_formula`'s parser with one argument moved
+(`option`, a row of `_LEGS`), as TARIFF-17 did for `parse_static_profile()`. A
+second parser would be a second `_finite()`, unknown-key rule, unit table and
+`to_resolution()`, diverging first on the 23- and 25-hour days. Every earlier
+call site passes no `option` and reads byte-identical sentences. The flat scalar
+`export_price_eur_kwh()` is untouched and still answers when the option is "".
+
+## What it does not affect
+
+`arbitrage.py` does not read the injection price at all (9.3: near-zero Belgian
+injection; it prices the sell side as displaced import), so no trade today turns
+on this number and it is not a wrong-trade fix. It changes what an operator is
+told and what a future export-aware strategy (OPT-06) rests on.
+
+## The card cannot always grade it
+
+Eneco's injection formula is printed with no price beside it. The `card` block
+is required on the consumption leg and optional here (`FormulaSpec.card_graded`
+is how callers ask; `card_discrepancy()` raises on an ungraded spec rather than
+returning 0.0). The self-check runs wherever a printed estimate exists, and
+validate.py says at startup that a leg is ungraded. Inventing an estimate would
+grade the arithmetic against itself (MUTATION.md habit 4).
+
+## `implausible_injection()`: bounds on the coefficients, not the price
+
+The consumption band (`implausible_all_in()`) cannot be reused: it adds
+`price_taxes_eur_kwh`, a consumption component, and its floor `energy >= 0.02`
+would refuse the real market's negative hours. But that floor catches a whole
+card read 100x too small, which the card check cannot see (it cancels). A band
+spanning zero cannot catch 0.00132 EUR/kWh, so the bound moves onto the
+coefficients, index-free and sign-free:
+
+- pass-through `factor x UNITS[units] / 0.001` (one EUR/MWh is 0.001 EUR/kWh):
+  1.00 for Eneco's injection leg, 0.70 for Aspiravi's; 100x off reads 0.01 or 100;
+- offset magnitude, on the absolute value (1,188 c = 0.01188; a hundredfold error
+  is 1.188 EUR/kWh).
+
+Two rungs can both answer one stimulus, so they are graded on their reasons and
+mutated together (MUTATION.md, TEST-16); test_price.py 17d builds fixtures so
+each is the only one firing. It bounds the shape of the coefficients, never
+their truth.
+
+## The consumption band's asymmetry (`implausible_all_in()`)
+
+The low end is graded on the energy component and the high end on the all-in
+figure. `price_taxes_eur_kwh` ships at 0.11736 (TARIFF-18; 0.06 before), nearly
+six times the low bound, so a card read 100x too small (0.0016 EUR/kWh) is
+carried over the floor by the flat tax addend alone and would pass a band applied
+to the all-in total. Raising the default made the trap wider. The ceiling is on
+the all-in figure because that is what the site is billed. It grades the card's
+own point, not every hour: live EPEX hours may fall outside (a negative hour is
+the best charging opportunity of the year, 17 keeps a regression case). It is
+called from validate.py only, since it reads the framework-owned taxes number.
+
+## Smaller rules
+
+- `CARD_TOLERANCE` is 0.01 in the card's units, the last digit both real cards
+  print (Eneco 15,55 against 15.5471; ENGIE 7,522 against 7.5218). Every error
+  class it exists for is at least two orders of magnitude bigger.
+- The card age warning (about 6 months) is never a refusal: ENGIE freezes a
+  contract's coefficients, so an old card can be exactly right.
+- `units` is required with no default (a default is the factor-1000 class).
+  A zero factor is a fixed tariff in a dynamic one's clothes (every spread 0,
+  arbitrage never fires; 14's warning box), so the operator is pointed at the
+  first-class way to say one price. A negative factor inverts the market (charge
+  into the evening peak). `vat_pct: 0` is legitimate (injection is exempt; some
+  cards are quoted VAT-inclusive); the bound exists for the 106 / 1.06 / 6
+  confusion. An unknown key is refused, not ignored, so a user who types "expr"
+  is not priced on the fields they also typed. A non-finite factor would make
+  every price NaN; `True` is an `int` and would price the day at the index.
+- `to_resolution()`: the bucket is a UTC hour, exact for Belgium (CET and CEST
+  are whole-hour offsets, so keying by UTC cannot collide the two 02:00s). It
+  decides how many points are emitted, not how long one covers ([[TARIFF-14]]). An
+  incomplete hour is averaged over what is there, not dropped or zero-filled.
+- The startup preview prints the index that went in beside the price that came
+  out (`61.96 -> 0.13522`): every error this module refuses is invisible on the
+  status page, and a factor of 1000 is one glance there.

goodwe_controller/app/custom_formula.py

@@ -1,174 +1,18 @@
 """TARIFF-15 - the customer's own tariff card, as two fixed coefficients.
 
-WHAT THIS IS FOR, in one sentence: a Belgian dynamic contract prices energy as
-`B x index + A` with coefficients that exist in exactly one place - the tariff
-card in the customer's klantenzone - so the customer types those two numbers
-and the add-on does every unit conversion and the VAT multiplication itself.
+A Belgian dynamic contract prices energy as `B x index + A` with coefficients
+that exist only on the customer's card. The customer types those two numbers;
+the add-on does every unit conversion and the VAT multiplication. Fixed
+coefficients, no expression evaluation of any kind (the string is settable over
+HTTP, and an expression cannot be graded against the card). An unknown key is
+refused, never ignored. validate.py refuses to start unless the formula
+reproduces the card's printed estimate within CARD_TOLERANCE: that grades the
+coefficients against the card, not the card against reality.
 
-WHY A FORMULA AND NOT FOURTEEN MORE PLUGINS (§9.2, TARIFF-07)
-=============================================================
-There is NO machine-readable source of Belgian tariff coefficients anywhere.
-CREG's consumer tariff-card pages 404, CREG Scan is a JS-only wizard, the
-annual report carries the supplier list and no per-product coefficients, and
-VREG was unreachable. Every coefficient found in research came off a supplier's
-own PDF, one of them image-only. So there is nothing to scrape and a
-per-supplier plugin would have no source for its numbers - fourteen plugins
-would be fourteen copies of the same invention, which is the defect TARIFF-07
-withdrew three plugins for. THE CUSTOMER IS THE ONLY PARTY WHO CAN SEE THEIR
-OWN COEFFICIENTS, and the card they read them from is the only artefact that
-can grade them.
-
-THE SHAPE IS THE MARKET'S PUBLISHED ARITHMETIC, NOT OUR APPROXIMATION
-====================================================================
-Both suppliers whose 2026 cards were readable print the formula, the reference
-index they assumed AND the resulting price, so the arithmetic below is
-reproducible against something they published rather than against our own
-guess:
-
-    Eneco   (0.102 x 133.9905 + 1.00) x 1.06 = 15.5471   card prints  15,55
-    ENGIE   (0.100 x  61.96   + 0.90) x 1.06 =  7.5218   card prints   7,522
-
-Two independent suppliers, reproduced to the last printed digit, in
-c EUR/kWh. test_price.py section 13 runs both through the SHIPPED code.
-
-⚠️ THE DOUBLE-COUNTING MECHANISM, AND WHY THIS DESIGN IS SAFE AT ALL
-====================================================================
-This provider declares `sources = {ENERGY, MARKUP}` and NOT `ALL_IN`. A Belgian
-card's `Tariefformule` line is THE ENERGY COMPONENT ONLY: Eneco puts network
-tariffs in one table and levies in a second, and ENGIE states in so many words
-that the formula "does not include fixed network/distribution costs, transport,
-grid levies, or excise duties". Declaring ALL_IN would lie on behalf of every
-user who typed what their card says, and would silently drop ~12 c EUR/kWh.
-
-price.py already mechanises that a PLUGIN cannot double-count (`PluginOptions`,
-`FRAMEWORK_KEYS`, `code_leaks()`). This provider introduces a risk none of those
-can see, because it is not in the code: THE OPERATOR double-counting, by folding
-their network charges into `offset` while `price_taxes_eur_kwh` carries them as
-well. `code_leaks()` scans code. This is config.
-
-So the card is the grader:
-
-    At startup validate.py computes
-    `(factor x card.index_eur_per_mwh + offset) x (1 + vat_pct/100)` and
-    REFUSES TO START unless it equals `card.expect_incl_vat` to within
-    CARD_TOLERANCE, naming the discrepancy.
-
-An `offset` inflated by network charges CANNOT PASS: the card's printed estimate
-is by construction the energy component alone, so adding ~12 c EUR/kWh moves
-15.55 to ~27 and the add-on refuses. The same check catches VAT omitted, VAT
-applied twice, a transposed digit, and a UNIT MISMATCH BETWEEN THE TWO SIDES -
-coefficients read off the formula line while the expected price is typed in
-another convention, which is the factor-10/100/1000 class as it actually
-happens.
-
-⚠️ THE ONE UNIT ERROR THE CARD CHECK CANNOT SEE IS THE ONE APPLIED TO BOTH
-SIDES AT ONCE, and saying so is the difference between a guard and a slogan:
-scaling the coefficients AND the expected price by the same 100 cancels out of
-a comparison between them. That is what `implausible_all_in()` is for, and it
-is a SEPARATE refusal on a SEPARATE quantity - the card's own point, all-in,
-against the band a Belgian retail tariff can occupy.
-
-⚠️ AND THE LIMIT, IN THE SAME BREATH AS THE CLAIM, exactly as price.py's trap 1
-states its own: THE CHECK GRADES THE COEFFICIENTS AGAINST THE CARD, NOT THE CARD
-AGAINST REALITY. A consistent-but-wrong pair - both numbers copied off the wrong
-product, or off last year's card - reproduces its own printed price perfectly
-and passes. Nothing here or anywhere else can catch that; what is mechanised is
-that the two coefficients and the printed estimate AGREE, which is the whole of
-the unit/VAT/decimal-point class and none of the "wrong contract" class.
-
-⚠️ FIXED COEFFICIENTS. NO EXPRESSION EVALUATION OF ANY KIND.
-============================================================
-All 24 surveyed Belgian products, both injection legs and aWATTar AT fit
-`B x index + A`, so an expression buys nothing the market needs. Against that:
-
-  * the add-on serves `POST config/save` -> `POST /addons/self/options` on its
-    own ingress page, so this string is SETTABLE OVER HTTP. `eval` on it is
-    remote code execution in a root container holding SUPERVISOR_TOKEN, with
-    `homeassistant_api` and `hassio_api`, driving an inverter over RS485.
-    (`eval(s, {"__builtins__": {}})` is not a sandbox and never was.)
-  * ⚠️ AND THE DECIDING ARGUMENT IS NOT SECURITY - AN EXPRESSION IS
-    UNVERIFIABLE. Two coefficients can be graded against the card's printed
-    estimate. An arbitrary expression cannot be graded against anything, so it
-    makes the invisible-wrong-coefficient problem STRICTLY WORSE, which is the
-    exact failure this provider exists to prevent.
-
-Future shapes become NAMED FIELDS - `clamp_lo`, `factor_negative`,
-`offset_bands` - each individually refusable and each individually gradeable
-against a card. Never a grammar. `parse_price_formula()` therefore REFUSES AN
-UNKNOWN KEY rather than ignoring it, so a user who types `"expr"` is told it
-does not exist instead of being silently priced on the fields they also typed.
-test_price.py section 13f walks this module's AST and fails if `eval`, `exec`,
-`compile`, `__import__` or `literal_eval` ever appears in it.
-
-WHERE THE NUMBERS COME FROM AND WHERE THEY GO
-=============================================
-`index` names the reference series. `epex_be` is the EPEX BE day-ahead curve in
-EUR/MWh, which is what `generic_dayahead` already fetches - same feed, same
-`brussels_date_range()` request, same columnar parser, same declared egress
-hosts. No new parser and no new failure mode.
-
-`resolution` says which series the contract is written against:
-
-  * `quarter_hourly` - the 96 points the feed publishes since Belgium's
-    15-minute MTU (2025-10-01), emitted as they are;
-  * `hourly`         - the four quarters of each hour averaged into one point.
-
-⚠️ NEITHER IS AN HOURLY ASSUMPTION IN `_Series.at()`'s SENSE (TARIFF-14). The
-hourly option changes how many POINTS are emitted and their spacing; the window
-each point covers is still derived from its neighbours by `_cover_table()`, and
-nothing here tells anything downstream how long a point lasts. A feed that is
-already hourly averages one member per hour, which is the identity - so the
-option cannot silently assume the granularity it was handed.
-
-`units` is NOT bureaucracy. Two suppliers publish the same shape in different
-units and the market aggregator prints both conventions in one column, so the
-add-on has to be told which one the card is in - and the unit conversion is the
-add-on's job precisely because it is one of the two steps that silently costs a
-factor of 10, 100 or 1000. The other is VAT, which is also the add-on's.
-
-TARIFF-16 - THE SECOND LEG, AND WHY IT IS THIS PARSER AND NOT A SECOND ONE
-==========================================================================
-A Belgian dynamic contract has TWO published lines, not one, and the second is
-what the site is PAID for export:
-
-    Eneco Zon & Wind Dynamisch   0,1 x BELPEX-H - 1,188   c EUR/kWh
-    ENGIE Dynamic                (B x eSpot_15) - A
-    Aspiravi (non-dynamic)       0,07 x Belpex - 2
-
-Same `B x index + A` shape - which is why `price_export_formula` is this
-module's parser with ONE argument moved (`option`), exactly as TARIFF-17 made
-`parse_static_profile()`'s option name a parameter rather than forking the
-period grammar. What differs between the two legs is FOUR numbers and a
-handful of sentences, and all of them are rows of `_LEGS`:
-
-  * its OWN factor - Eneco 0,102 on consumption against 0,100 on injection,
-    Aspiravi 0,07 against ~0,10. NOT the consumption `B` with a sign flip;
-  * a NEGATIVE offset, which `factor`/`offset` already allow and which
-    `price_markup_eur_kwh: float(0,1)` cannot express at all;
-  * `vat_pct: 0` - "Injectietarieven zijn vrijgesteld van btw" - against 6 on
-    consumption, which is a SIX PERCENT ASYMMETRY between the buy leg and the
-    sell leg and is representable only because `vat_pct` is PER SPEC;
-  * a price that goes BELOW ZERO with no floor, in the hours a PV household
-    exports. `implausible_injection()` is the band that accepts that and still
-    refuses an implausible one; `implausible_all_in()` is NOT it, and its
-    docstring says why.
-
-⚠️ AND THE CARD CANNOT ALWAYS GRADE IT. Eneco's injection formula is printed
-with NO price beside it, so on that card there is nothing to reproduce. The
-`card` block is therefore OPTIONAL on this leg and REQUIRED on the other, the
-self-check runs wherever there is a printed estimate, and validate.py says at
-startup when a leg is ungraded. Inventing an estimate to grade against would
-be grading arithmetic against itself, which is the defect MUTATION.md habit 4
-is about; TARIFF-15 demonstrated two tariffs end to end rather than three for
-the same reason.
-
-⚠️ NOTHING TRADES ON THIS TODAY, AND SAYING SO IS PART OF SHIPPING IT.
-`arbitrage.py` does not read `export_price_eur_kwh` at all - its own comment
-says so, citing §9.3's near-zero Belgian injection price - and both hours it
-compares are all-in CONSUMPTION prices. So this is not a wrong-trade defect
-and must not be described as one. What it changes is what an operator is told,
-and what a future export-aware strategy would rest on.
-"""
+The provider declares `{ENERGY, MARKUP}`, never `ALL_IN` (a card's formula is
+the energy component only). TARIFF-16 added the injection leg through this same
+parser. DECISIONS/TARIFF-15-the-card-is-the-grader.md and
+DECISIONS/TARIFF-16-the-injection-leg.md."""
 
 import json
 import math
@@ -183,13 +27,11 @@ class FormulaInvalid(Exception):
     validate.py at startup - never at 03:00 on a fetch."""
 
 
-# --------------------------------------------------------------------------- #
-# The enumerations. Every one of these is a CLOSED set, and that is the point:
-# an unknown value is refused by name rather than guessed at.
-# --------------------------------------------------------------------------- #
+# The enumerations. Each is a CLOSED set: an unknown value is refused by name,
+# not guessed.
 
-# unit -> how many EUR/kWh one of it is. ⚠️ THE WHOLE FACTOR-1000 CLASS LIVES
-# HERE, so the table is tiny, explicit, and has no "default".
+# unit -> EUR/kWh per one of it. The whole factor-1000 class lives here: tiny,
+# explicit, no default.
 UNITS: dict = {
     "c_eur_per_kwh": 0.01,      # eurocent per kWh - Eneco and ENGIE print this
     "eur_per_kwh": 1.0,         # some aggregators print this
@@ -198,54 +40,41 @@ UNITS: dict = {
 
 RESOLUTIONS: tuple = ("hourly", "quarter_hourly")
 
-# index id -> the human name of the series it refers to. One entry today; a
-# second index is a new row here plus a fetch path, not a new grammar.
+# index id -> the series it names. A second index is a new row here plus a
+# fetch path.
 INDEXES: dict = {
     "epex_be": "Belgian day-ahead price, EUR/MWh",
 }
 
-# ⚠️ 0.01 IN THE CARD'S OWN UNITS, WHICH IS THE LAST DIGIT BOTH REAL CARDS
-# PRINT. Eneco prints 15,55 against a computed 15.5471 (0.0029 out) and ENGIE
-# prints 7,522 against a computed 7.5218 (0.0002 out), so the tolerance has to
-# absorb the card's own rounding and nothing more. Every error class this check
-# exists for - a factor of 10, of 100, of 1000, a missing or doubled 1.06, a
-# transposed digit, ~12 c EUR/kWh of network charge folded into `offset` - is
-# at least two orders of magnitude bigger than this.
+# 0.01 in the card's own units, the last digit both real cards print (Eneco
+# 15,55 vs 15.5471; ENGIE 7,522 vs 7.5218): the card's rounding and nothing
+# more. DECISIONS/TARIFF-16-the-injection-leg.md.
 CARD_TOLERANCE = 0.01
 
-# The all-in plausibility band, EUR/kWh. `MAX_PLAUSIBLE_EUR_KWH` in price.py
-# bounds only prices that are too LARGE; this is the other end, and it is the
-# one the factor-1000 error falls off.
+# The all-in plausibility band, EUR/kWh: the low end, where a factor-1000 error
+# falls off.
 PLAUSIBLE_LO_EUR_KWH = 0.02
 PLAUSIBLE_HI_EUR_KWH = 1.00
 
-# ~6 months. ⚠️ A WARNING, NEVER A REFUSAL: ENGIE freezes a contract's
-# coefficients for its duration, so a card two years old can be exactly right
-# and a site refused over one would be a site that cannot start.
+# ~6 months. A WARNING, never a refusal: ENGIE freezes a contract's
+# coefficients.
 CARD_STALE_DAYS = 183
 
 _CARD_KEYS = ("month", "index_eur_per_mwh", "expect_incl_vat")
 _TOP_KEYS = ("index", "resolution", "factor", "offset", "units", "vat_pct",
              "card")
 
-# --------------------------------------------------------------------------- #
 # TARIFF-16 - the SECOND leg, and the one parameter that carries it
-# --------------------------------------------------------------------------- #
 
 EXPORT_FORMULA_OPTION = "price_export_formula"
 
-# ⚠️ THE PASS-THROUGH FRACTION, WHICH IS WHY THE NEXT TWO BOUNDS CAN BE
-# INDEX-FREE. One EUR/MWh IS 0.001 EUR/kWh, so `factor x UNITS[units] / 0.001`
-# is the dimensionless share of the wholesale price the contract passes
-# through - 1.00 for Eneco's injection leg (0,100 c EUR/kWh per EUR/MWh), 0.70
-# for Aspiravi's (0,07). A coefficient typed a hundred times too small or too
-# large moves this by a hundred, whatever the index and whatever the sign of
-# the price.
+# The pass-through fraction, `factor x UNITS[units] / 0.001`: index-free and
+# sign-free, so a coefficient typed 100x off moves it by 100 whatever the
+# price.
 EUR_KWH_PER_EUR_MWH = 0.001
 
-# The two plausibility bounds for an INJECTION leg. ⚠️ NEITHER LOOKS AT THE
-# SIGN OF THE PRICE, AND THAT IS THE WHOLE POINT - see
-# `implausible_injection()`.
+# The two plausibility bounds for an INJECTION leg; neither looks at the sign
+# of the price.
 PASSTHROUGH_LO = 0.10       # 10% of the wholesale price
 PASSTHROUGH_HI = 10.0       # 1000% of it
 INJECTION_OFFSET_MAX_EUR_KWH = 0.20
@@ -254,18 +83,8 @@ INJECTION_OFFSET_MAX_EUR_KWH = 0.20
 @dataclass(frozen=True)
 class _Leg:
     """What ONE option's coefficients price, as sentences its refusals read.
-
-    ⚠️ TARIFF-16 MADE `option` A PARAMETER RATHER THAN FORKING THE PARSER,
-    exactly as TARIFF-17 made `option`/`means` parameters of
-    `parse_static_profile()` rather than forking the period grammar. A second
-    copy of this parser would be a second `_finite()`, a second unknown-key
-    rule, a second unit table and a second `to_resolution()` - and the two
-    would diverge first on the 23- and 25-hour days, where nobody looks.
-    Everything that differs between the consumption leg and the injection leg
-    is a STRING in this table; the arithmetic, the enumerations, the card
-    comparison and the resolution rule are ONE implementation with one set of
-    checks over it.
-    """
+    `option` is a parameter, not a fork of the parser (TARIFF-16, as TARIFF-17 did
+    for `parse_static_profile()`)."""
 
     option: str
     what: str            # "consumption" / "injection", for a sentence
@@ -316,12 +135,8 @@ _LEGS = {
 
 @dataclass(frozen=True)
 class FormulaSpec:
-    """One contract's published arithmetic. SEVEN numbers and no code.
-
-    ⚠️ EVERY FIELD IS A FIXED, NAMED SCALAR. There is deliberately no field
-    that holds an expression, a callable, a lambda or a template, and there is
-    no place to put one: `parse_price_formula()` refuses an unrecognised key.
-    """
+    """One contract's published arithmetic: SEVEN numbers and no code. Every field is
+    a fixed named scalar; `parse_price_formula()` refuses an unrecognised key."""
 
     index: str
     resolution: str
@@ -332,8 +147,8 @@ class FormulaSpec:
     card_month: str = ""            # "YYYY-MM", as the card is dated
     card_index_eur_per_mwh: float = None
     card_expect_incl_vat: float = None   # in `units`, as the card prints it
-    # TARIFF-16. Which OPTION this spec was read from, so a refusal, a log line
-    # and `card_graded` name the leg the operator actually typed.
+    # TARIFF-16. Which OPTION this spec was read from, so refusals name the leg
+    # typed.
     option: str = "price_formula"
 
     @property
@@ -342,24 +157,14 @@ class FormulaSpec:
 
     @property
     def card_graded(self) -> bool:
-        """Is there a printed estimate to grade these coefficients against?
-
-        ⚠️ FALSE IS A REAL, SHIPPED STATE ON THE INJECTION LEG and is reported
-        rather than defaulted: Eneco's injection formula is printed with no
-        price beside it. Never False on `price_formula`, where `_card()`
-        refuses an absent block.
-        """
+        """Is there a printed estimate to grade these coefficients against? False is a
+        real state on the injection leg (Eneco prints none); never False on `price_formula`."""
         return self.card_expect_incl_vat is not None
 
     @property
     def passthrough(self) -> float:
-        """The dimensionless share of the wholesale price this passes through.
-
-        `factor x UNITS[units] / 0.001`. 1.00 for Eneco's injection leg, 0.70
-        for Aspiravi's. ⚠️ INDEX-FREE AND SIGN-FREE, which is what lets
-        `implausible_injection()` bound a leg whose price legitimately goes
-        below zero.
-        """
+        """The dimensionless share of the wholesale price this passes through. Index-free
+        and sign-free, which lets `implausible_injection()` bound a leg that goes negative."""
         return self.factor * self.unit_to_eur_kwh / EUR_KWH_PER_EUR_MWH
 
     @property
@@ -368,46 +173,27 @@ class FormulaSpec:
         return self.offset * self.unit_to_eur_kwh
 
 
-# --------------------------------------------------------------------------- #
 # The arithmetic. Two functions, and the SECOND one is the contract.
-# --------------------------------------------------------------------------- #
 
 def in_card_units(spec: FormulaSpec, index_eur_per_mwh: float) -> float:
-    """`(factor x index + offset) x (1 + vat_pct/100)`, in the card's units.
-
-    This is the line the card prints, spelled exactly as the card spells it,
-    and it is the only place the coefficients are combined. The card
-    self-check and the price path both go through here, so a mutation to it
-    cannot move the price without also moving the self-check.
-    """
+    """`(factor x index + offset) x (1 + vat_pct/100)`, in the card's units: the line
+    the card prints. The only place the coefficients are combined, so the card
+    check and the price path cannot diverge."""
     return ((spec.factor * float(index_eur_per_mwh) + spec.offset)
             * (1.0 + spec.vat_pct / 100.0))
 
 
 def price_eur_kwh(spec: FormulaSpec, index_eur_per_mwh: float) -> float:
-    """The energy+markup price for one index value, in EUR/kWh.
-
-    ⚠️ THE UNIT CONVERSION IS THE ADD-ON'S JOB AND IT HAPPENS HERE, ONCE. The
-    user types what their card prints, in the card's own units; every step
-    from there to EUR/kWh is code, because those steps are exactly the ones
-    that silently cost a factor of 10, 100 or 1000 when a human does them.
-    """
+    """The energy+markup price for one index value, in EUR/kWh. The unit conversion
+    happens here, once: those steps are the ones that cost a factor of 10, 100 or 1000."""
     return in_card_units(spec, index_eur_per_mwh) * spec.unit_to_eur_kwh
 
 
 def card_discrepancy(spec: FormulaSpec) -> float:
-    """How far the coefficients land from the card's own printed estimate.
-
-    In the card's units, signed: positive means the formula computes MORE than
-    the card prints, which is the direction an `offset` carrying network
-    charges moves it.
-
-    ⚠️ RAISES ON A SPEC WITH NO CARD RATHER THAN RETURNING 0.0 (TARIFF-16). An
-    ungraded injection leg has no printed estimate, and a discrepancy of zero
-    is exactly what "the coefficients reproduce the card" looks like - so a
-    silent zero here would report the strongest possible result for the one
-    state in which nothing was compared at all.
-    """
+    """How far the coefficients land from the card's printed estimate, in the card's
+    units, signed: positive means MORE than the card prints (the direction an
+    `offset` carrying network charges moves it). Raises on a spec with no card
+    rather than returning 0.0 (TARIFF-16)."""
     if not spec.card_graded:
         raise FormulaInvalid(
             f"{spec.option} has no card block, so there is no printed "
@@ -417,18 +203,10 @@ def card_discrepancy(spec: FormulaSpec) -> float:
         - spec.card_expect_incl_vat
 
 
-# --------------------------------------------------------------------------- #
 # Reading the option
-# --------------------------------------------------------------------------- #
 
 def _finite(value, field: str, option: str = "price_formula") -> float:
-    """A real, finite number - or a refusal naming the field.
-
-    ⚠️ SAME CLASS AS `_validate_raw()`'s NaN RULE, one layer earlier. A NaN
-    factor makes every price NaN, every comparison False, and an arbitrage
-    strategy that silently never fires; `True` is an `int` in Python and would
-    price the whole day at the index.
-    """
+    """A real, finite number, or a refusal naming the field (NaN would price every hour NaN; `True` is an `int`)."""
     if isinstance(value, bool) or not isinstance(value, (int, float)):
         raise FormulaInvalid(
             f"{option}.{field} is {value!r}, which is not a number. Write a "
@@ -441,15 +219,9 @@ def _finite(value, field: str, option: str = "price_formula") -> float:
 
 
 def _card(raw, leg: _Leg = None) -> tuple:
-    """The `card` block: the estimate the coefficients are graded against.
-
-    ⚠️ REQUIRED ON THE CONSUMPTION LEG AND OPTIONAL ON THE INJECTION ONE, and
-    the asymmetry is a fact about the CARDS rather than a relaxed rule. See
-    `_LEGS[EXPORT_FORMULA_OPTION].card_note`: Eneco's injection formula is
-    printed with no price beside it, so on that card there is nothing to grade
-    against. `("", None, None)` is the ungraded answer and
-    `FormulaSpec.card_graded` is how every caller asks.
-    """
+    """The `card` block: the estimate the coefficients are graded against. Required on
+    the consumption leg, optional on the injection one because Eneco prints none
+    (`("", None, None)`; `FormulaSpec.card_graded`)."""
     if leg is None:
         leg = _LEGS["price_formula"]
     if raw is None:
@@ -491,31 +263,8 @@ def _month_date(month: str):
 
 
 def parse_price_formula(value, *, option: str = "price_formula"):
-    """`price_formula` -> a `FormulaSpec`, or None when unset.
-
-    ⚠️ `option` IS TARIFF-16'S WHOLE REUSE, and it is TARIFF-17's move. It
-    selects a row of `_LEGS` and nothing else: the enumerations, the
-    arithmetic, `to_resolution()`, the unknown-key rule and the card
-    comparison are shared, and every pre-existing call site - which passes no
-    `option` at all - lands on the consumption row and reads byte-identical
-    sentences. `parse_export_formula()` is a two-line wrapper, not a fork.
-
-    Accepts what the option can actually arrive as, exactly as
-    `parse_static_profile()` does:
-
-      * `None` / `""` / `"null"`   - unset.
-      * a JSON string              - what config.yaml's flat `str?` option
-                                     carries on a Supervisor install.
-      * a dict                     - already parsed, from a future nested
-                                     schema, from sim/inject.py, or a check.
-
-    Raises `FormulaInvalid`; never returns a half-built spec.
-
-    ⚠️ THE CARD SELF-CHECK IS PART OF PARSING, not a separate step a caller
-    may forget. Both callers - validate.py's startup gate and the plugin's own
-    fetch - go through this one function, so there is no route to a price that
-    has not been graded against the card.
-    """
+    """`price_formula` -> a `FormulaSpec`, or None when unset. `option` selects a row of
+    `_LEGS`; everything else is shared, so `parse_export_formula()` is a wrapper."""
     leg = _LEGS[option]
     if value is None:
         return None
@@ -534,12 +283,8 @@ def parse_price_formula(value, *, option: str = "price_formula"):
             f"{option} is {type(value).__name__}, not a JSON object with "
             f"{', '.join(_TOP_KEYS)}.")
 
-    # ⚠️ AN UNKNOWN KEY IS REFUSED, NOT IGNORED, AND THIS IS THE HALF THAT
-    # KEEPS THE "NEVER A GRAMMAR" PROMISE HONEST. A future shape is a NAMED
-    # field - clamp_lo, factor_negative, offset_bands - added here and
-    # refusable on its own. Ignoring unknown keys would mean a user who typed
-    # "expr" or "formula" gets priced on the fields they also typed, with the
-    # one they believed in dropped in silence.
+    # An unknown key is refused, not ignored: a future shape is a NAMED field,
+    # never a grammar.
     unknown = sorted(set(value) - set(_TOP_KEYS))
     if unknown:
         raise FormulaInvalid(
@@ -559,10 +304,8 @@ def parse_price_formula(value, *, option: str = "price_formula"):
             f"{option}.resolution is {value.get('resolution')!r}. Choose one "
             f"of {list(RESOLUTIONS)}, as your tariff card says.")
 
-    # ⚠️ `units` IS REQUIRED AND HAS NO DEFAULT. A default here would be the
-    # factor-1000 class with a friendly face: the add-on would silently assume
-    # a convention the card never stated, and the card self-check would then
-    # be graded in units nobody chose.
+    # `units` is required with no default: a default is the factor-1000 class
+    # with a friendly face.
     units = str(value.get("units", "") or "").strip()
     if units not in UNITS:
         raise FormulaInvalid(
@@ -573,29 +316,22 @@ def parse_price_formula(value, *, option: str = "price_formula"):
     offset = _finite(value.get("offset"), "offset", option)
     vat_pct = _finite(value.get("vat_pct"), "vat_pct", option)
 
-    # ⚠️ ZERO IS NOT "NO INDEXATION", IT IS A FIXED TARIFF WEARING A DYNAMIC
-    # ONE'S CLOTHES. Every hour comes out at the same price, so every spread is
-    # 0, arbitrage can never clear any threshold, and a strategy that never
-    # fires is indistinguishable from one that is switched off (§14's warning
-    # box). The add-on already has a first-class way to say "one price": point
-    # the operator at it rather than let them build it by accident.
+    # Zero is a fixed tariff in a dynamic one's clothes (arbitrage never
+    # fires); point the operator at the first-class fixed price.
     if factor == 0.0:
         raise FormulaInvalid(
             f"{option}.factor is 0, so every hour gets the same {leg.what} "
             f"price{leg.zero_factor}. For one flat price, {leg.flat}.")
 
-    # ⚠️ A NEGATIVE FACTOR INVERTS THE MARKET, and the direction is the danger:
-    # the dearest hour becomes the cheapest one, so the battery is told to
-    # charge into the evening peak and to discharge at 03:00. That is not a
-    # mispriced site, it is a site actively trading against itself.
+    # A negative factor inverts the market: charge into the evening peak,
+    # discharge at 03:00.
     if factor < 0.0:
         raise FormulaInvalid(
             f"{option}.factor is {factor:g}, which turns the market upside "
             f"down. {leg.neg_factor}.")
 
-    # ⚠️ 0 IS LEGITIMATE AND MUST STAY SO: injection is VAT-exempt in Belgium,
-    # and some cards are already quoted VAT-inclusive. The bound exists for the
-    # 106 / 1.06 / 6 confusion, not to make VAT compulsory.
+    # 0 is legitimate (injection is VAT-exempt; some cards are VAT-inclusive);
+    # the bound is for the 106 / 1.06 / 6 confusion.
     if not 0.0 <= vat_pct <= 30.0:
         raise FormulaInvalid(
             f"{option}.vat_pct is {vat_pct:g}. Write a percentage between 0 "
@@ -607,13 +343,9 @@ def parse_price_formula(value, *, option: str = "price_formula"):
                        card_month=month, card_index_eur_per_mwh=card_index,
                        card_expect_incl_vat=card_expect, option=option)
 
-    # ⚠️ THE CARD SELF-CHECK STILL RUNS WHEREVER THERE IS A CARD TO RUN IT
-    # AGAINST, on either leg, with the same tolerance. What TARIFF-16 adds is
-    # the honest answer for the leg where the card prints no estimate: NOT a
-    # weakened comparison and NOT an estimate computed here, but two bounds on
-    # the COEFFICIENTS that need no printed price - see
-    # `implausible_injection()` - and a startup line saying the leg is
-    # ungraded.
+    # The card self-check still runs wherever there is a card, with the same
+    # tolerance. Where the card prints no estimate, `implausible_injection()`
+    # bounds the coefficients and a startup line says the leg is ungraded.
     if spec.card_graded:
         delta = card_discrepancy(spec)
         if abs(delta) > CARD_TOLERANCE:
@@ -626,60 +358,15 @@ def parse_price_formula(value, *, option: str = "price_formula"):
 
 
 def parse_export_formula(value):
-    """`price_export_formula` -> the INJECTION leg's `FormulaSpec`, or None.
-
-    TARIFF-16. THE DEFECT THIS EXISTS TO CLOSE: `price.py` modelled injection
-    as ONE scalar, and the market publishes a line with four properties a
-    scalar cannot hold. Verbatim off the cards:
-
-        Eneco Zon & Wind Dynamisch   0,1 x BELPEX-H - 1,188   c EUR/kWh
-            "Het injectietarief is dynamisch en kan per uur wijzigen"
-            - identical on the January and the September 2026 cards
-        ENGIE Dynamic                (B x eSpot_15) - A       c EUR/kWh
-        Aspiravi (non-dynamic)       0,07 x Belpex - 2
-
-      1. ITS OWN FACTOR. Eneco uses 0,102 on consumption and 0,100 on
-         injection; Aspiravi 0,07 against ~0,10 on its consumption leg. It is
-         NOT the consumption `B` with a sign flip.
-      2. A NEGATIVE OFFSET - `- 1,188`, `- 2`. Note that
-         `price_markup_eur_kwh: float(0,1)` cannot express a negative markup
-         at all, so the offset has no home on the consumption side either.
-      3. VAT-EXEMPT. "Injectietarieven zijn vrijgesteld van btw", while
-         consumption is at 6% - a SIX PERCENT ASYMMETRY between the buy leg
-         and the sell leg, which a single scalar cannot even state.
-      4. IT GOES NEGATIVE, WITH NO FLOOR. Eneco's injection price is negative
-         for any BELPEX-H below 11,88 EUR/MWh, and a PV household exports
-         precisely in the hours most likely to be negative. You can be charged
-         to export.
-
-    ⚠️ AND WHAT THIS DOES **NOT** AFFECT TODAY, SAID HERE SO NOBODY READS THE
-    ABOVE AS A TRADING BUG. `arbitrage.py` does not read
-    `export_price_eur_kwh` at all - its own comment says so, and gives §9.3's
-    near-zero Belgian injection price as the reason the economically sound
-    trade on this market is charge-cheap-to-displace-expensive-IMPORT. Both
-    hours it compares are all-in CONSUMPTION prices. So no trade the add-on
-    takes today is decided by this number, and this card is not a correction
-    of a wrong trade. What it changes is what an operator is told, and what
-    any future export-aware strategy would rest on: OPT-06 and any export
-    logic would otherwise inherit a scalar that cannot represent the market,
-    and the 6% VAT asymmetry would be invisible in the arithmetic.
-
-    ⚠️ THE SCALAR IS NOT REPLACED. `export_price_eur_kwh()` is untouched and
-    still answers for every site with a flat injection price, which is every
-    site that exists today; this option ships "". That is `price.py`'s own
-    prediction coming true rather than a new design - "when it does land, an
-    injection curve gets a `PriceProvider` of its own and this scalar becomes
-    its FIXED-product default; the seam is already the right shape for that."
-    """
+    """`price_export_formula` -> the INJECTION leg's `FormulaSpec`, or None (TARIFF-16).
+    Same parser with `option` moved; the flat `export_price_eur_kwh()` still answers
+    when unset. Nothing trades on it today. DECISIONS/TARIFF-16-the-injection-leg.md."""
     return parse_price_formula(value, option=EXPORT_FORMULA_OPTION)
 
 
 def card_refusal(spec: FormulaSpec, delta: float) -> str:
-    """The sentence an operator reads when their formula misses its own card.
-
-    It names both numbers and what to check. The usual causes are in DOCS.md,
-    because each of these errors looks like a working tariff on the status page.
-    """
+    """The sentence an operator reads when their formula misses its own card: both
+    numbers and what to check (causes are in DOCS.md)."""
     got = in_card_units(spec, spec.card_index_eur_per_mwh)
     leg = _LEGS[spec.option]
     return (
@@ -688,53 +375,14 @@ def card_refusal(spec: FormulaSpec, delta: float) -> str:
         f"{spec.card_expect_incl_vat:g}. Check {leg.card_causes}.")
 
 
-# --------------------------------------------------------------------------- #
 # The two questions the PLUGIN cannot ask, because they need framework numbers
-# --------------------------------------------------------------------------- #
 
 def implausible_all_in(spec: FormulaSpec, taxes_eur_kwh: float):
-    """The card's own point, if its LEVEL cannot be a Belgian retail price.
-
-    Returns a refusal sentence or None. ⚠️ CALLED FROM validate.py AND FROM
-    NOWHERE ELSE, because it reads a FRAMEWORK-owned number: a plugin that
-    could see `taxes` could add it a second time, which is price.py's trap 1.
-
-    ⚠️ THE LOW END IS GRADED ON THE ENERGY COMPONENT AND THE HIGH END ON THE
-    ALL-IN FIGURE, AND THAT ASYMMETRY IS THE CHECK RATHER THAN AN OVERSIGHT.
-    `price_taxes_eur_kwh` ships at 0.11736 (TARIFF-18; it was 0.06 before, and
-    the argument was already decisive at that figure), which is nearly SIX
-    times the low bound - so a card read a HUNDRED times too small comes out at
-    0.0016 EUR/kWh of energy, is carried over the floor by the flat tax addend
-    alone, and passes a band applied to the all-in total. The hundredfold error
-    is precisely what this exists to catch, so the floor is applied where it
-    can still see it. ⚠️ Raising the default made this trap WIDER, not
-    narrower: the addend that does the carrying got bigger. The ceiling is
-    applied to the all-in figure because that is the number the site is really
-    billed at, and taxes only push it up.
-
-    ⚠️ AND THE LIMIT, WITH THE CLAIM. This grades the CARD'S OWN POINT - one
-    price, at the monthly index the card assumed - and not every hour of every
-    day. A live EPEX hour can and should fall outside this band (a negative
-    hour is the best charging opportunity of the year, and §17 keeps a
-    regression case for it), so the band is deliberately NOT applied to the
-    fetched series. What it catches is a formula whose whole LEVEL is wrong,
-    which is the factor-of-1000 class arriving from the end
-    `MAX_PLAUSIBLE_EUR_KWH` does not bound.
-
-    ⚠️ AND IT IS THE CONSUMPTION LEG'S BAND ONLY - TARIFF-16 DELIBERATELY DID
-    NOT POINT IT AT THE INJECTION LEG. Two reasons, and the second is an
-    acceptance criterion rather than a preference:
-
-      * it adds `taxes_eur_kwh`, and `price_taxes_eur_kwh` is a CONSUMPTION
-        component. Nothing is added to what a site is PAID for export, so the
-        `all_in` half would be adding a number the injection leg never carries;
-      * its floor is `energy >= 0.02 EUR/kWh`, and a REAL Eneco injection price
-        is negative for any BELPEX-H below 11,88 EUR/MWh - the hours a PV
-        household actually exports in. Applied to injection this floor would
-        refuse the market, and refuse it hardest in the hours where knowing the
-        number matters most. `implausible_injection()` is the injection band
-        and it is deliberately NOT this function with a lower floor.
-    """
+    """The card's own point, if its LEVEL cannot be a Belgian retail price. Refusal
+    sentence or None. Called from validate.py only (it reads the framework-owned
+    taxes). The low end is graded on the energy component and the high end on the
+    all-in figure; the consumption leg's band only. It grades the card's own point,
+    not the fetched series. DECISIONS/TARIFF-16-the-injection-leg.md."""
     energy = price_eur_kwh(spec, spec.card_index_eur_per_mwh)
     all_in = energy + float(taxes_eur_kwh)
     if energy >= PLAUSIBLE_LO_EUR_KWH and all_in <= PLAUSIBLE_HI_EUR_KWH:
@@ -747,49 +395,10 @@ def implausible_all_in(spec: FormulaSpec, taxes_eur_kwh: float):
 
 
 def implausible_injection(spec: FormulaSpec):
-    """The INJECTION leg's plausibility band. Returns a refusal or None.
-
-    ⚠️ A NEGATIVE INJECTION PRICE IS ACCEPTED, NOT REFUSED, AND NEITHER RUNG
-    BELOW LOOKS AT THE SIGN OR THE LEVEL OF A PRICE. Eneco's published line
-    `0,1 x BELPEX-H - 1,188` is negative for any BELPEX-H under 11,88 EUR/MWh;
-    those are the midday hours a PV household exports in, so a band with a
-    floor above zero - which is what `implausible_all_in()` has, for the
-    consumption leg's own good reasons - would refuse the real market and
-    would hide it in exactly the hours it costs money. You CAN be charged to
-    export. The add-on says so rather than declining to represent it.
-
-    THE PROBLEM THAT LEAVES, STATED BEFORE THE SOLUTION. The consumption
-    floor was not decoration: it is what catches a whole card read a hundred
-    times too small, the one unit error the card self-check cannot see because
-    it cancels out of a comparison between the two sides. A band that spans
-    zero cannot catch it - 0.00132 EUR/kWh is inside any interval that
-    contains -0.03. So the bound moves OFF the price and ONTO the
-    coefficients, where it is index-free and sign-free:
-
-      * PASS-THROUGH. `factor x UNITS[units] / 0.001` is the dimensionless
-        share of the wholesale price the contract passes through, because one
-        EUR/MWh IS 0.001 EUR/kWh. Eneco's injection leg is 1.00 and Aspiravi's
-        is 0.70. A factor typed 100x too small reads 0.01 and 100x too large
-        reads 100, whatever the index and whatever the sign of the result.
-      * OFFSET MAGNITUDE. Eneco's is 1,188 c EUR/kWh = 0.01188 EUR/kWh and
-        Aspiravi's is 2 c = 0.02. A hundredfold error is 1.188 EUR/kWh, which
-        is not an injection tariff in any direction. The bound is on the
-        ABSOLUTE value, so a negative offset of a believable size passes and
-        that is the normal case on this leg.
-
-    ⚠️ TWO RUNGS THAT CAN BOTH ANSWER ONE STIMULUS, SO THEY ARE GRADED ON
-    THEIR REASONS AND MUTATED TOGETHER (MUTATION.md, TEST-16). A whole card
-    read 100x too large trips both. The fixtures in test_price.py 17d are
-    built so that each rung is the ONLY one that fires on its own stimulus.
-
-    ⚠️ AND WHAT THIS CANNOT SEE, WITH THE CLAIM (habit 13). It bounds the
-    SHAPE of the coefficients, never their truth: a contract really written
-    against a different index, or last year's coefficients, passes both rungs
-    and reproduces any card typed beside them. Where a card DOES print an
-    estimate the self-check grades the pair against it; where it does not -
-    which is Eneco's injection line - these two bounds are the whole of what
-    is mechanised, and validate.py says so at startup.
-    """
+    """The INJECTION leg's plausibility band. Refusal or None. A negative price is
+    accepted; the bounds are on the coefficients (pass-through and offset
+    magnitude), since a band spanning zero cannot catch a card 100x too small. It
+    bounds the shape, not the truth. DECISIONS/TARIFF-16-the-injection-leg.md."""
     if not PASSTHROUGH_LO <= spec.passthrough <= PASSTHROUGH_HI:
         return (
             f"{spec.option}.factor passes through {spec.passthrough:.4g}x the "
@@ -806,10 +415,7 @@ def implausible_injection(spec: FormulaSpec):
 
 
 def stale_card(spec: FormulaSpec, today=None):
-    """A warning when the card is older than ~6 months, or None. NEVER a
-    refusal: ENGIE freezes a contract's coefficients for its duration, so an
-    old card can be exactly right and refusing one would stop the add-on on a
-    correctly configured site."""
+    """A warning when the card is older than ~6 months, or None. Never a refusal (ENGIE freezes coefficients)."""
     dated = _month_date(spec.card_month)
     now = today or datetime.now(timezone.utc).date()
     if dated is None or (now - dated).days <= CARD_STALE_DAYS:
@@ -820,36 +426,14 @@ def stale_card(spec: FormulaSpec, today=None):
         f"contract changed since, copy the new figures from your supplier.")
 
 
-# --------------------------------------------------------------------------- #
 # Resolution
-# --------------------------------------------------------------------------- #
 
 def to_resolution(pairs, resolution: str) -> list:
     """`[(instant, index EUR/MWh)]` -> the series the CONTRACT is written on.
-
-    `quarter_hourly` hands the feed's own points back, ascending.
-    `hourly` averages each hour's members into one point AT THE TOP OF THE
-    HOUR.
-
-    ⚠️ THE BUCKET IS A UTC HOUR AND THAT IS EXACT FOR BELGIUM, not an
-    approximation: CET and CEST are both WHOLE-hour offsets, so a Brussels hour
-    and a UTC hour start at the same instant on every day of the year including
-    both transition days. Keying by a naive local hour is what collides the two
-    02:00s in October; keying by the UTC instant cannot.
-
-    ⚠️ AND THIS IS NOT `_Series.at()`'s HOURLY ASSUMPTION COMING BACK
-    (TARIFF-14). It decides how many points are EMITTED, not how long one
-    covers - the coverage window is still derived from the neighbours in
-    `_cover_table()`. A feed that already publishes hourly points averages one
-    member per hour, i.e. the identity, so this cannot silently assume the
-    granularity it was handed.
-
-    ⚠️ AN INCOMPLETE HOUR IS AVERAGED OVER WHAT IS THERE rather than dropped or
-    zero-filled. A horizon that starts at 09:20 has two quarters in its first
-    hour; their mean is the best statement available about that hour, and
-    dropping it would leave a hole `at()` answers with `Absence` for an hour
-    the feed did publish.
-    """
+    `quarter_hourly` returns the feed's points, `hourly` averages each UTC hour
+    (exact for Belgium: whole-hour offsets) at the top of the hour. An incomplete
+    hour is averaged over what is there. It sets how many points are emitted, not
+    how long one covers (TARIFF-14)."""
     ordered = sorted(pairs, key=lambda r: r[0].astimezone(timezone.utc))
     if resolution == "quarter_hourly":
         return list(ordered)
@@ -863,28 +447,16 @@ def to_resolution(pairs, resolution: str) -> list:
     return [(k, sum(v) / len(v)) for k, v in sorted(buckets.items())]
 
 
-# --------------------------------------------------------------------------- #
 # The startup preview
-# --------------------------------------------------------------------------- #
 
 PREVIEW_HOURS = 24
 PREVIEW_MAX_ROWS = 24
 
 
 def preview_lines(spec: FormulaSpec, rows) -> list:
-    """`[(instant, index EUR/MWh, all-in EUR/kWh)]` -> lines for the log.
-
-    THE DEFECT THIS EXISTS TO MAKE VISIBLE: every error this module refuses is
-    one the operator cannot see from the status page, and the two numbers that
-    would have shown it - the index that went IN and the price that came OUT -
-    are never printed beside each other anywhere else. A factor of 1000 is
-    obvious in one line of `61.96 -> 0.13522` and invisible in a plan.
-
-    ⚠️ IT PRINTS A BOUNDED NUMBER OF ROWS AND SAYS SO. At `quarter_hourly` the
-    next 24 h is 96 points; the cap is a row COUNT rather than "every fourth
-    point", because sampling every fourth point would assume the granularity
-    TARIFF-14 spent a card removing the assumption of.
-    """
+    """`[(instant, index EUR/MWh, all-in EUR/kWh)]` -> lines for the log: the index
+    that went IN beside the price that came OUT. Prints a bounded row COUNT, not
+    every fourth point (that would assume the granularity)."""
     if not rows:
         return []
     shown = rows[:PREVIEW_MAX_ROWS]

goodwe_controller/app/price_chain.py

@@ -1,27 +1,15 @@
 """PRICE-01 - where the prices come from when the first source does not answer.
 
-A provider that names `FALLBACKS` (app/price.py) is read through this module
-instead of straight from `load_prices()`. The order is fixed:
+A provider that names `FALLBACKS` (app/price.py) is read through here: first the
+provider (the owner's price server), then each id in `FALLBACKS`, then the
+prices the history store kept from the last fetch that worked. A step counts
+only if its answer holds a price for NOW (a server answering 200 with
+yesterday's prices is as useless as one that is down). Other providers never
+come here (`uses_chain()` is False).
 
-    1. the provider itself (the owner's price server)
-    2. each id in its `FALLBACKS` (energy-charts.info)
-    3. the prices the history store kept from the last fetch that worked
-
-A step counts only if its answer holds a price for NOW. A server that answers
-200 with yesterday's prices is as useless to a battery as one that is down, so
-it is skipped, with the same log line.
-
-Every other provider never comes here (`uses_chain()` is False for it), so
-`generic_dayahead`, `manual_csv`, `custom_formula` and `off` take the road they
-always took.
-
-THE GATE. `gate_for()` is the maintenance charge rule for a site on such a
-provider: the current 15-minute price is at or below today's average. It is the
-rule the Home Assistant pair (`price_now_entity`, `price_avg_entity`) gave, read
-from the provider's own prices, so moving a site from the pair to the provider
-does not change WHEN the charge runs. DECISIONS/PRICE-01-own-price-server.md
-says how equal, and where it is not.
-"""
+`gate_for()` is the maintenance charge rule for such a site: the current
+15-minute price is at or below today's average, as the Home Assistant pair gave.
+DECISIONS/PRICE-01-own-price-server.md says how equal, and where it is not."""
 
 import logging
 from dataclasses import dataclass
@@ -74,13 +62,8 @@ class Resolved:
 
 
 class PriceWatch:
-    """Which step the prices come from, and one log line per change of it.
-
-    The line is written when the step CHANGES and not before. Nothing repeats
-    while a source stays down, and nothing is written for a refresh that
-    changes nothing. The reasons (a status code, a timeout) go on a DEBUG line
-    beside it, with the token taken out.
-    """
+    """Which step the prices come from, and one log line per change of it (nothing
+    repeats while a source stays down). Reasons go on a DEBUG line, token removed."""
 
     def __init__(self):
         self.step = None
@@ -123,20 +106,14 @@ async def resolve(opts: dict, since: datetime, until: datetime, transport,
                   history, stamp: datetime, watch: PriceWatch,
                   load) -> Resolved:
     """Walk the chain and return the first step that has a price for `stamp`.
-
-    `load` is the caller's `load_prices`, passed in so that `static_tariff.py`
-    stays the one module that fetches prices. Never raises
-    for a source condition: a read that gets nowhere is a `no_data` whose
-    reason names every step, so the §11.4 row applies exactly as for a single
-    provider that failed.
-    """
+    `load` is the caller's `load_prices`, so static_tariff.py stays the one module
+    that fetches. Never raises for a source condition: `no_data` names every step."""
     pid = provider_id(opts)
     cls = PROVIDERS[pid]
     reasons = []
     for step, sid in enumerate((pid,) + tuple(cls.FALLBACKS)):
-        # A fallback is asked for ITS OWN feed. The operator's feed override is
-        # for the first provider and would send energy-charts' request to a
-        # URL it was never meant for.
+        # A fallback is asked for ITS OWN feed; the operator's override is for
+        # the first provider.
         o = opts if step == 0 else dict(opts, price_provider=sid,
                                         price_feed_url="")
         read = await load(o, since, until, transport)
@@ -158,8 +135,8 @@ async def resolve(opts: dict, since: datetime, until: datetime, transport,
             series=lambda r: "price_history: it has no price for now",
             no_data=lambda r: r.reason))
     watch.note(STEP_NONE, reasons, opts)
-    # The reason is short on purpose: it is printed on the status page and in
-    # a WARNING every refresh. What each step said is on the DEBUG line.
+    # Short on purpose: it is on the status page and in a WARNING every
+    # refresh.
     return Resolved(PriceRead.no_data(
         "no price source has a price for now"), STEP_NONE,
         tuple(scrub(r, opts) for r in reasons))
@@ -171,13 +148,9 @@ async def resolve(opts: dict, since: datetime, until: datetime, transport,
 
 @dataclass(frozen=True)
 class Gate:
-    """What the 30 s tick takes from the standing plan.
-
-    `covered` is whether a published price covers now. When it is False,
-    `cheap` is False and the charge waits: no price is not a cheap price.
-    `since` is when the cover ended, for the status line, or None when nothing
-    was ever published.
-    """
+    """What the 30 s tick takes from the standing plan. `covered` False means `cheap`
+    is False and the charge waits (no price is not a cheap price). `since` is when
+    the cover ended, or None."""
 
     cheap: bool
     covered: bool
@@ -189,24 +162,16 @@ NO_PLAN = Gate(False, False, None, "No prices yet")
 
 
 def _round5(value: float) -> float:
-    # The Home Assistant template rounded the average to 5 decimals, and a
-    # price to 5 as well. Both sides are compared as it did, so a quarter that
-    # sits within 0.00001 EUR/kWh of the average gets the same answer.
+    # The Home Assistant template rounded both sides to 5 decimals; so do we,
+    # for the same answer.
     return round(float(value), 5)
 
 
 def gate_for(published, now: datetime) -> Gate:
-    """The charge gate for `now`, from the series the chain published.
-
-    THE RULE (owner's decision, PRICE-01): the current 15-minute price is at or
-    below the average of today's prices, today being the Brussels day. This is
-    what `now_p <= avg_p` was on the Home Assistant pair. It is NOT
-    `TariffPlan.cheap_now()`, which is strictly below the mean of the firm
-    hours of the whole plan, and it is not meant to be.
-
-    `published` is a series or None. With no price for now there is no gate
-    answer: the charge waits.
-    """
+    """The charge gate for `now`, from the series the chain published: the current
+    15-minute price is at or below the average of today's (Brussels day) prices,
+    as `now_p <= avg_p` was on the HA pair (owner, PRICE-01). Not
+    `TariffPlan.cheap_now()`. With no price for now the charge waits."""
     if published is None:
         return NO_PLAN
     if not published.covers(now):

goodwe_controller/app/price_forecast.py

@@ -1,163 +1,16 @@
 """FCST-03 - the hours the feed has not published yet, and what may not rest on them.
 
-WHERE THIS LIVES. specs.md §2.2 puts price ingest under `ems/ingest/prices/`.
-That layout does not exist and is not being built; the product owner's decision
-of 2026-08-30 is that everything ships in `goodwe_controller/app/`. The
-BEHAVIOUR §8.3 describes is unchanged and still authoritative - only the path
-moved. Read `ems/...` as `app/...`.
-
-§8.3, in full, because every line below is one clause of it:
-
-    "Day-ahead prices arrive once daily. Until they do, unknown hours use
-     yesterday's profile and are flagged `provisional: true` - and NO
-     IRREVERSIBLE ACTION MAY BE TAKEN ON A PROVISIONAL PRICE. Real-time /
-     imbalance products are treated as high-volatility: arbitrage thresholds
-     widen."
-
-Three separate things, and this module owns the first two. The third - the
-widening arithmetic - lives in price.py beside the product enum it is derived
-from (`Uncertainty`, `widen_factor`, `required_spread`), and is spent by
-`static_tariff.TariffPlan.arbitrage()`, because that is where the verdict this
-repo already refuses to hand out casually is produced. FCST-03 added a refusal
-to that existing ladder rather than a second mechanism beside it.
-
-
-THE DEFECT THIS MODULE IS SHAPED BY: A COPY THAT KEEPS THE WRONG FLAG
-=====================================================================
-A point filled from yesterday and a point published this morning are the SAME
-SHAPE. Three floats and a bool; only the bool tells them apart. And the natural
-way to write a carry-forward fill is:
-
-    PricePoint(start=t, eur_per_kwh=y.eur_per_kwh, provisional=y.provisional)
-                                                                ^^^^^^^^^^^^^
-
-which copies yesterday's `False` onto today's guess and produces exactly the
-thing the ticket exists to prevent: STALE DATA PRESENTED AS CURRENT. It reads
-fine, it type-checks, it round-trips through §9.3's JSON, and every price on
-the status page looks like a price. This is the meter-side SAFETY-18 defect one
-layer up: the reading arrives on time, looks fresh, and is wrong - and a
-freshness check that only asks "did something arrive" cannot see it.
-
-So the flag is not passed through anywhere in this file:
-
-  * A CARRIED POINT IS BUILT BY `_carried()`, WHICH HAS NO PARAMETER FOR THE
-    FLAG. `provisional=True` is a literal in one place. There is no argument a
-    caller can pass, no keyword to forget, and no variable that could hold
-    yesterday's value at the moment the point is constructed.
-  * A PUBLISHED POINT IS NEVER COPIED AT ALL. It is passed through BY IDENTITY -
-    the object the provider produced is the object in the output series - so
-    there is no copy that could lose or gain a flag. `filled.points[i] is
-    fetched.points[j]` is a checkable property, and test_price_forecast.py
-    checks it. EVERY published point in the window is passed through, not one
-    per hour: see the sub-hourly note below.
-  * `_audit()` RE-DERIVES the expected flag for every output point from the set
-    of hours the feed actually published, and RAISES if any point disagrees.
-    It is a post-condition, not a filter: it never fixes a flag, because a
-    module that quietly corrects its own provenance is one whose provenance
-    cannot be trusted.
-
-    ⚠️ IT GRADES THE POINTS THAT ARE EMITTED AND NOTHING ABOUT THE ONES THAT
-    ARE NOT (FCST-05). `_audit()` is a provenance check, NOT a completeness
-    check: fed FCST-04's own decimation defect - four published points in an
-    hour, only the last emitted - it ACCEPTS, and it accepts an empty output
-    too. Measured, and the FCST-03 audit it replaced was equally blind, so
-    this is a limit rather than a regression. What actually guards against a
-    decimated series is the point COUNT and the pass-through IDENTITY checks
-    in `test_price_forecast.py` (section on the quarter-hourly feed) and
-    `test_price_history.py`; see `_audit()`'s own docstring for why the
-    completeness rule is not expressible from its two arguments.
-  * and test_price_forecast.py walks THIS FILE'S AST and fails if any
-    `PricePoint(...)` in it passes anything but a literal for `provisional`, so
-    the pass-through idiom cannot come back in a later edit and pass review by
-    looking ordinary.
-
-⚠️ "PUBLISHED" DOES NOT MEAN "FIRM". §9.3's canonical format carries
-`provisional` PER POINT, not per series, precisely because a real-time /
-imbalance product's current-interval print is settled after the fact and is
-genuinely provisional while it is published. Such a point is published AND
-provisional, and the audit's rule for a published point is "the flag is
-whatever the feed said", never "False". A provenance check that forced
-published points to False would be a bug that looks like a guarantee.
-
-⚠️ NO SHIPPED PLUGIN EMITS ONE TODAY (TARIFF-07 withdrew the only declarer of
-`PriceProduct.REALTIME`), and that is exactly why this paragraph stays. The
-rule is a property of the FORMAT, not of any supplier; weakening it to
-"published implies False" while nothing exercises it is how the first real
-imbalance feed would arrive mispriced and flagged firm.
-
-
-THE FILL, AND WHY IT KEYS ON THE WALL CLOCK
-===========================================
-For every whole hour in the requested horizon that the feed has not published,
-take yesterday's value for THE SAME BRUSSELS WALL-CLOCK HOUR - not `t - 86400
-s`. On the two days a year that matter those are different instants, and the
-difference is not academic: a 23-hour day has no 02:00 at all and a 25-hour day
-has two, so a fill that subtracts a fixed 24 h shifts every carried hour by one
-across a transition and misprices the whole day in a way nothing reports.
-
-On the 25-hour day the two 02:00 hours - `02:00+02:00` and `02:00+01:00` - both
-key to local hour 2 and are BOTH filled from yesterday's single 02:00 value.
-That is deliberate: they are both guesses, they are both flagged, and nothing
-irreversible may rest on either. If yesterday itself was a 25-hour day, the
-first of its two 02:00 points is the one used, deterministically.
-
-An hour with no published price AND no yesterday value is LEFT OUT of the
-series. It is not filled with a neighbour, a mean, or a zero. §11.4 applies to
-that hour - `_Series.at()` raises `Absence` for it - and the caller that wanted
-a tariff for the whole horizon falls back to the static profile (TARIFF-03),
-which is the row the spec actually writes for "no price data". If NOTHING can
-be produced, the result is `PriceRead.no_data(reason)` and not an empty series,
-because an empty series is not constructible on purpose (price.py trap 3).
-
-⚠️ A SUB-HOURLY FEED IS NOT DECIMATED TO ONE POINT AN HOUR, and the hourly walk
-below is about WHICH HOURS NEED FILLING - never about what a published hour is
-allowed to contain. BELGIAN DAY-AHEAD ITSELF SETTLES PER QUARTER since the
-15-minute MTU took effect on 2025-10-01 - `generic_dayahead` reads 96 points a
-day, not 24 - `_validate_raw()` accepts any strictly-increasing spacing, and a
-published hour may therefore hold four points. So EVERY published point inside
-the window is passed through, in order, and a carried point is added only for a
-whole hour with NO published coverage at all.
-
-The alternative was measured rather than reasoned about, because FCST-04's
-first caller shipped it: keying the published set as `{_utc_hour(p.start): p
-for p in r.points}` reads perfectly ordinary and keeps the LAST point of each
-hour, dropping the other three. On a 96-point quarter-hourly feed - all firm,
-fully published, nothing to carry - the series came out 15 points long, the
-arbitrage spread collapsed from 0.143 to 0.014 EUR/kWh, and the cheapest
-"hour" became a `:45` point whose `at()` window runs into the next hour. A feed
-losing 84 % of its own prints is not a windowing effect and is not something a
-provisional flag would ever have reported.
-
-
-AC2: THE IRREVERSIBLE-ACTION GATE
-=================================
-"The distinction should be an explicit property of the action, not a judgement
-call at each call site" - so an irreversible action is a value, `Irreversible`,
-carrying the number of hours it COMMITS. `price_permits()` looks at exactly
-those hours and answers with a `Gate` variant that carries the evidence on the
-permitting arm and a reason on the blocking one, the `_Outcome` shape price.py
-borrowed from `sim/riglock.py`.
-
-The shipped example is the maintenance drain (§12): starting one commits hours
-of forced discharge that cannot be undone if the price turns out to have been
-yesterday's. Its commitment window is DERIVED from `maintenance.DRAIN_TIMEOUT_MIN`
-rather than typed here, so the gate and the phase machine cannot drift apart.
-
-⚠️ WHAT DOES NOT GO THROUGH THIS GATE, AND WHY THAT MATTERS MORE THAN WHAT
-DOES. The maintenance cycle is a CALENDAR obligation (§12.2: a cycle that
-silently never fires is indistinguishable from one that is not due yet), and a
-site with `price_provider: off` - the shipped default - has no price series at
-all. Routing every maintenance start through a gate that blocks on `no_data`
-would stop the monthly cycle on every default install, permanently and
-silently: the exact failure §12 opens by naming. So `begin_phase()` is the
-entry point for a start that is being JUSTIFIED BY A PRICE, main.py's existing
-calendar path is untouched by this ticket, and OPT-04/MAINT-05 own the decision
-of which one a site runs. Nothing here disables anything that runs today.
-
-Reversible actions - ordinary self-consumption modulation, the loop that
-actually holds the grid at zero - are not gated at all and cannot be: §6 says
-absent machinery must not disable the loop.
-"""
+specs.md 8.3: unknown hours use yesterday's profile and are flagged
+`provisional: true`, and no irreversible action may be taken on a provisional
+price. This module owns the fill and the gate; the widening arithmetic is in
+price.py. The flag is never passed through: a carried point is built only by
+`_carried()` (no flag parameter), a published point is passed by identity, and
+`_audit()` raises on a mismatch. The fill keys on the Brussels wall-clock hour,
+and a sub-hourly feed is never decimated. An hour with neither a published
+price nor a yesterday value is left out, never filled (`at()` raises `Absence`,
+11.4 applies). `begin_phase()` is the price-justified entry point only; the
+calendar path is untouched. All of it:
+DECISIONS/FCST-03-the-hours-not-yet-published.md."""
 
 import logging
 from dataclasses import dataclass
@@ -172,13 +25,8 @@ _LOG = logging.getLogger("goodwe.price.forecast")
 
 
 class Provenance(Enum):
-    """Where a point in a filled series came from. INTERNAL - §9.3's wire format
-    carries the boolean and nothing else, so this never leaves the module.
-
-    It exists so `_audit()` has a vocabulary to state its post-condition in, and
-    so the two cases have names in the log rather than being "the ones with the
-    flag" and "the others".
-    """
+    """Where a point in a filled series came from. INTERNAL: the wire format carries
+    only the boolean. It gives `_audit()` and the log names for the two cases."""
     PUBLISHED = "published"    # the provider printed this hour. Flag: the
                                # feed's own - a real-time print may be
                                # published AND provisional (§9.2).
@@ -186,9 +34,7 @@ class Provenance(Enum):
                                # Flag: ALWAYS True, by construction.
 
 
-# --------------------------------------------------------------------------- #
 # The fill
-# --------------------------------------------------------------------------- #
 
 def _utc_hour(instant: datetime) -> datetime:
     u = instant.astimezone(timezone.utc)
@@ -196,16 +42,9 @@ def _utc_hour(instant: datetime) -> datetime:
 
 
 def _published_by_hour(read: PriceRead) -> dict:
-    """UTC hour -> the provider's OWN points that start inside it, in order.
-
-    ⚠️ A TUPLE PER HOUR, NOT A POINT, AND THAT IS THE WHOLE OF THE SUB-HOURLY
-    RULE. `{_utc_hour(p.start): p for p in r.points}` reads identically, is one
-    character shorter, and silently keeps one point per hour - the last one
-    written. The mapping answers two DIFFERENT questions here: "does this hour
-    need filling at all?" is `u in published`, and "what does the output carry
-    for it?" is all of `published[u]`. Collapsing them is how a quarter-hourly
-    feed loses three quarters of its prints.
-    """
+    """UTC hour -> the provider's OWN points that start inside it, in order. A tuple
+    per hour, not a point: a dict of `{hour: p}` silently keeps the last one and
+    decimates a quarter-hourly feed."""
     out: dict = {}
     read.match(
         series=lambda r: [out.setdefault(_utc_hour(p.start), []).append(p)
@@ -215,13 +54,8 @@ def _published_by_hour(read: PriceRead) -> dict:
 
 
 def _carried(start_utc: datetime, eur_per_kwh: float) -> PricePoint:
-    """A point filled from yesterday's profile. §8.3: ALWAYS provisional.
-
-    ⚠️ THERE IS NO `provisional` PARAMETER, AND THAT IS THE MECHANISM. This is
-    the only constructor of a carried point, the flag is a literal, and no
-    caller - including a future one editing in a hurry - has anything to pass,
-    default, or copy from the point being carried.
-    """
+    """A point filled from yesterday's profile. 8.3: ALWAYS provisional. There is no
+    `provisional` parameter: the flag is a literal, nothing to pass or copy."""
     return PricePoint(start=brussels(start_utc),
                       eur_per_kwh=round(float(eur_per_kwh), 6),
                       provisional=True)
@@ -230,88 +64,15 @@ def _carried(start_utc: datetime, eur_per_kwh: float) -> PricePoint:
 def _audit(points, published) -> None:
     """Post-condition: every flag matches the point's TRUE provenance (AC1).
 
-    `published` maps a UTC hour to the TUPLE of points the provider produced
-    for it (`_published_by_hour()`). An hour ABSENT from that mapping is an hour
-    the feed did not print, and a carried point is the only thing that may
-    stand in it.
+    `published` maps a UTC hour to the TUPLE of points the provider produced for it.
+    PUBLISHED: the point must be one of `published[u]` by identity, emitted once,
+    flag whatever the feed said (never forced to False). CARRIED: the hour must not
+    be in `published`, the flag exactly True, no second point in that hour.
 
-    The rule, in the two forms an output point can take:
-
-      * PUBLISHED - the point must BE one of `published[u]`, by identity, and
-        may be emitted only once. Its flag is whatever the feed said, never
-        forced to False: an imbalance print is published AND provisional (§9.2,
-        TARIFF-02), and a check that "corrected" it would be a bug wearing a
-        guarantee.
-      * CARRIED - the hour must not appear in `published` AT ALL, the flag must
-        be exactly True, and that hour may hold no second point.
-
-    ⚠️ WHAT REPLACED "AT MOST ONE POINT PER HOUR", AND WHAT THAT DID AND DID
-    NOT CHANGE. This audit began as FCST-03's `seen` set: any repeated
-    `_utc_hour` raised, beside an identity rule `p is not src`. A bare hour
-    count cannot express a quarter-hourly feed, where four distinct published
-    points share one hour legitimately - so the count was replaced by the two
-    rules above, which subsume it.
-
-    ⚠️ AND IT IS NOT STRICTER. FCST-04's version of this paragraph claimed two
-    strengthenings and BOTH WERE FALSE; FCST-05 measured it. A differential
-    over the whole domain this audit can express - every published mask over 3
-    hours crossed with every output series of length 0-3 drawn from
-    {published, published-provisional, carried, carried-unflagged,
-    copy-of-published} - found ZERO divergence in EITHER direction:
-
-        OLD raised, NEW accepted (WEAKER):   0
-        OLD accepted, NEW raised (STRONGER): 0
-
-    The two specific claims, one at a time:
-
-      * "so does the same published point emitted twice" - the OLD `seen`
-        count already raised on that, because emitting one point twice is one
-        HOUR twice. Preserved by the identity/`emitted` rules, not added.
-      * "a carried point may no longer share an hour with a published one,
-        which the count never checked at all" - true of the COUNT, and the old
-        IDENTITY rule raised on it anyway: a carried point in a published hour
-        took the `else` branch and failed `p is not src`. The message was about
-        a copy rather than about a carry, which is the only thing that moved.
-
-    The one real behavioural change is the intended RELAXATION - several
-    distinct published points in one hour, which the old audit could not
-    express at all and refused. That relaxation is why this was rewritten, and
-    it stays. A right decision with a fabricated reason is still a defect here.
-
-    ⚠️ AND THE REAL LIMIT, WHICH IS NOT A REGRESSION AND IS NOT SMALL: THIS
-    AUDIT DOES NOT CHECK COMPLETENESS. It grades every point that IS emitted
-    and says nothing about the ones that are not. Fed the H1 decimation
-    directly - four published points in an hour, output emitting only the last
-    - it ACCEPTS; so does two of four, and so does an EMPTY output. So `_audit`
-    is NOT what stops H1 recurring. What stops it is the point COUNT and the
-    IDENTITY checks in `test_price_history.py` and `test_price_forecast.py`,
-    which compare the emitted series against the feed's own prints.
-
-    It is not made complete here, and the reason is structural rather than
-    effort: `published` is `_published_by_hour(read)` over the WHOLE read,
-    unwindowed, while `fill_from_yesterday()` emits only [since, until). A
-    published point outside the window is legitimately absent, so "every
-    published point appears" is not a true post-condition of these two
-    arguments - it would need the window passed in, which is a different
-    signature and a different check.
-
-    ⚠️ AND THAT IS MEASURED, NOT ASSUMED. FCST-05 built the rule - raise unless
-    every point of every `published[u]` is emitted, +162 B - and ran it. It
-    takes the 1 h, 12 h and 48 h HORIZON checks in test_price_forecast.py RED,
-    on the shipped fill and a healthy feed: at an off-the-hour instant the
-    feed's already-elapsed prints are outside [since, until) and are correctly
-    dropped, and the rule calls that a provenance failure. (The differential
-    beside those checks scores the same rule as 49 STRONGER cases, so it is a
-    real change of behaviour and not a no-op.) The rule as stated is therefore
-    not merely unimplemented, it is WRONG - and stating a false post-condition
-    is MUTATION.md habit 16's defect: an instrument that asserts a completeness
-    it does not have is worse than no instrument.
-
-    ⚠️ RAISES, NEVER REPAIRS. A module that silently corrects its own
-    provenance is one whose provenance means nothing; the only safe response to
-    "this point's flag disagrees with where it came from" is to refuse to emit
-    the series at all.
-    """
+    Provenance, NOT completeness: it accepts a decimated or empty output, because
+    `published` is unwindowed while the fill emits [since, until). The point count
+    and identity checks in the tests guard that. Raises, never repairs.
+    DECISIONS/FCST-03-the-hours-not-yet-published.md."""
     carried_hours = set()
     emitted = set()
     for p in points:
@@ -351,37 +112,12 @@ def _audit(points, published) -> None:
 def fill_from_yesterday(read: PriceRead, *, yesterday: PriceRead,
                         since: datetime, until: datetime,
                         stamp: datetime) -> PriceRead:
-    """§8.3: fill the hours the feed has not published with yesterday's profile.
+    """8.3: fill the hours the feed has not published with yesterday's profile.
 
-    Every argument is required and keyword-only past the first. In particular
-    `yesterday` has NO DEFAULT: a fill with no yesterday to fill from is a
-    different situation from a fill that found nothing useful in one, and a
-    default `None` would make the two arrive looking identical.
-
-    Returns a `PriceRead`:
-
-      * a series, carrying the provider's own objects - ALL of them, which on
-        a quarter-hourly feed is four inside one hour - for the hours it
-        published, and one `_carried()` point for each remaining whole hour,
-        ordered by instant;
-      * `no_data` when neither source can produce a single hour - never an
-        empty series, which is not constructible (price.py trap 3).
-
-    ⚠️ THE WINDOW IS WHOLE HOURS AT BOTH ENDS. `since` is floored to the hour
-    that CONTAINS it, because the current hour is still a tradeable hour; and
-    so is `until`, which is the half FCST-04's first draft left out. With
-    `since` floored and `until` compared raw, a 48 h horizon asked for at 08:17
-    emitted 49 hours - the hour of `until` was still `< until` - and the count
-    was one too many for every `now` that is not exactly on the hour, which is
-    every `now` a running controller has.
-
-    ⚠️ IDEMPOTENT AND RE-RUNNABLE, WHICH IS THE §5.4 LATE-PUBLICATION CONTRACT.
-    Day-ahead publication at 14-16 h CET can be late or fail, so the fetcher
-    retries and this runs again against the fresher read. Published hours always
-    win over carried ones, so a re-run REPLACES a carried point with the real
-    print and the hour becomes firm - the flag and the number move together
-    because the whole series is rebuilt rather than patched in place.
-    """
+    `yesterday` has no default. Returns a series (every published point, by
+    identity, plus one `_carried()` point per remaining whole hour) or `no_data`,
+    never an empty series. The window is whole hours at both ends. Idempotent and
+    re-runnable (5.4): published hours win and the series is rebuilt."""
     for name, value in (("since", since), ("until", until), ("stamp", stamp)):
         if value.tzinfo is None or value.utcoffset() is None:
             raise ValueError(f"{name} must be tz-aware; a naive instant is "
@@ -390,7 +126,7 @@ def fill_from_yesterday(read: PriceRead, *, yesterday: PriceRead,
     published = _published_by_hour(read)
 
     # Yesterday's profile, keyed by BRUSSELS WALL-CLOCK HOUR. First point wins
-    # when yesterday itself was a 25-hour day and printed local hour 2 twice.
+    # when yesterday itself was a 25-hour day.
     by_local_hour = {}
     yesterday.match(
         series=lambda r: [by_local_hour.setdefault(brussels(p.start).hour, p)
@@ -424,14 +160,8 @@ def fill_from_yesterday(read: PriceRead, *, yesterday: PriceRead,
     _audit(out, published)
     carried = sum(1 for p in out if _utc_hour(p.start) not in published)
     if carried:
-        # ⚠️ THREE QUANTITIES, THREE NAMES (TARIFF-11). This line read
-        # "%d of %d hours ... ; %d published" with `carried` (a count of
-        # carried HOURS - the fill emits exactly one point per unpublished
-        # hour) over `len(out)` (a count of POINTS, four per hour wherever the
-        # feed printed) and `len(out) - carried` (POINTS again) under the same
-        # noun. On the Belgian quarter-hourly feed that reads "33 of 141
-        # hours" about a 48-hour horizon. The fill's unit is the HOUR and the
-        # feed's is the POINT; nothing derived from one answers for the other.
+        # TARIFF-11: carried hours, total hours and published points are three
+        # different quantities.
         total_h = len({_utc_hour(p.start) for p in out})
         _LOG.info("%d of %s use yesterday's prices, marked as estimated. "
                   "The feed published %s over the other %s.",
@@ -446,17 +176,12 @@ def fill_from_yesterday(read: PriceRead, *, yesterday: PriceRead,
     return PriceRead.series(out, product, provider, stamp)
 
 
-# --------------------------------------------------------------------------- #
 # AC2: irreversibility as a property of the ACTION, and the gate that reads it
-# --------------------------------------------------------------------------- #
 
 @dataclass(frozen=True)
 class Irreversible:
-    """An action that cannot be undone once started, and how far it commits.
-
-    `commits_h` is the horizon the action ties up - the hours whose prices must
-    therefore be firm before it may be justified by a price at all.
-    """
+    """An action that cannot be undone once started. `commits_h` is the horizon it
+    ties up: those hours must be firm before a price may justify it."""
 
     name: str            # the §10.2 reason code
     commits_h: float
@@ -473,25 +198,16 @@ class Irreversible:
                 f"reversible one and does not belong here.")
 
 
-# ⚠️ DERIVED FROM THE PHASE MACHINE'S OWN BOUNDS, NOT TYPED HERE. maintenance.py
-# already states how long each phase may run before it is a fault; a second copy
-# of those numbers here would be a place for them to drift apart, and the drift
-# would show up as a gate that checked the wrong hours.
+# Derived from the phase machine's own bounds, not typed here, so the gate
+# cannot drift from it.
 MAINTENANCE_DRAIN = Irreversible("MAINTENANCE_DRAIN", DRAIN_TIMEOUT_MIN / 60.0)
 MAINTENANCE_CHARGE = Irreversible("MAINTENANCE_CHARGE", CHARGE_TIMEOUT_MIN / 60.0)
 
 
 class Gate(_Outcome):
     """May an irreversible action proceed on the price evidence available?
-
-      * `permitted` - carries `.action` and `.hours`, the firm points that were
-                      actually checked. The evidence exists only on this arm.
-      * `blocked`   - carries `.reason`. Nothing else; `.hours` raises `Absence`.
-
-    No `__bool__`, both `match()` arms required and keyword-only, for the reason
-    price.py's `_Outcome` gives: `if gate:` must not look like a guard while
-    being none.
-    """
+    `permitted` carries `.action` and `.hours` (the firm points checked); `blocked`
+    carries `.reason` only. No `__bool__`; both `match()` arms are required."""
 
     def match(self, *, permitted, blocked):
         return {"permitted": permitted, "blocked": blocked}[self.kind](self)
@@ -541,12 +257,7 @@ class _Blocked(Gate):
 
 
 def committed_hours(now: datetime, action: Irreversible) -> tuple:
-    """The whole hours `action` started at `now` would run through.
-
-    Split out because the gate and its caller must agree on what "the hours it
-    commits" means, and because a window that quietly excluded the last hour
-    would be a gate that permits an action on an hour it never looked at.
-    """
+    """The whole hours `action` started at `now` would run through (the gate and its caller must agree)."""
     if not isinstance(action, Irreversible):
         raise TypeError(f"action must be an Irreversible, not {action!r}")
     if now.tzinfo is None or now.utcoffset() is None:
@@ -562,13 +273,9 @@ def committed_hours(now: datetime, action: Irreversible) -> tuple:
 
 def price_permits(read: PriceRead, now: datetime,
                   action: Irreversible) -> Gate:
-    """§8.3's rule, as a value: may this irreversible action rest on this price?
-
-    Blocks when the read observed nothing (§11.4 - an action justified by a
-    price nobody has is an action justified by nothing), when any hour it
-    commits has no price at all, and when any of those hours is provisional.
-    Names the offending hour, so an operator reading the log knows which one.
-    """
+    """8.3's rule as a value: may this irreversible action rest on this price?
+    Blocks on no data (11.4), an hour with no price, or a provisional hour, and
+    names the offending hour."""
     hours = committed_hours(now, action)
     return read.match(
         series=lambda r: _walk(r, hours, action),
@@ -600,18 +307,10 @@ def _walk(series, hours, action) -> Gate:
 
 def begin_phase(maint, now: datetime, read: PriceRead,
                 action: Irreversible) -> Gate:
-    """Start a maintenance phase BECAUSE OF A PRICE, or refuse and say why.
-
-    The AC2 example made real: `maint.force_start(now)` - the call that moves
-    the phase machine out of `idle` and commits the pack to hours of forced
-    discharge - happens on the permitting arm and cannot happen on the other
-    one, because the blocking arm has no code path to it.
-
-    ⚠️ READ THE MODULE DOCSTRING'S LAST WARNING BEFORE WIRING THIS IN. This is
-    the price-justified entry point, not the calendar one; a site with no price
-    provider must keep starting its monthly cycle the way it does today, or
-    §12's opening sentence comes true - a cycle that silently never fires.
-    """
+    """Start a maintenance phase BECAUSE OF A PRICE, or refuse and say why. The
+    price-justified entry point, not the calendar one: a site with no provider must
+    keep starting its monthly cycle as today (12). The blocking arm has no path to
+    `maint.force_start(now)`."""
     gate = price_permits(read, now, action)
     return gate.match(permitted=lambda g: _go(maint, now, g),
                       blocked=lambda g: _no(g))

goodwe_controller/app/price_history.py

@@ -1,185 +1,24 @@
-"""FCST-04 - the day the carry-forward carries, kept somewhere a restart cannot reach.
+"""FCST-04 - the day the carry-forward carries, kept where a restart cannot reach.
 
-WHAT WAS MISSING, AND WHY IT WAS INVISIBLE. FCST-03 shipped
-`price_forecast.fill_from_yesterday()` complete and checked, and shipped the
-consumers that were written to expect it - `TariffPlan.firm_points()`,
-`cheap_now()`'s refusal of a provisional hour, and `arbitrage()`'s refusal 3,
-which drops provisional hours from the trade set instead of refusing the whole
-series. Every one of those was live. The FILL ITSELF HAD NO CALLER: nothing in
-`app/` referenced `fill_from_yesterday`, so no series ever contained a carried
-point and every one of those consumers was exercising its all-firm branch.
+`price_forecast.fill_from_yesterday()` needs a yesterday that survives a
+restart; this module is that store and the one caller of the fill. Four rules:
 
-The defect that produced is not an error anywhere. `load_prices()` returns
-whatever the feed published and nothing widens it to the requested horizon, so
-on a dynamic site between midnight and the 14-16 h CET day-ahead publication
-the series covers the rest of TODAY and nothing more - typically 10-24 of the
-48 hours `price_horizon_h` asked for. `TariffPlan.arbitrage()` then computes
-`max - min` over that truncated window and reports a spread. The number is
-real, the window is half the one the operator configured, and NOTHING SAYS SO:
-tomorrow evening's peak - the hour a morning charge would be sold into - is
-simply not in the series, so the spread it would have created cannot clear a
-threshold it was never compared against. A missing hour is not a wrong price;
-it is an hour the optimiser never learns exists.
+1. It records what the PROVIDER published, never what the fill produced
+   (feeding a fill back in rots the numbers behind a true `provisional` flag).
+   `carry()` is the only public entry point and `_remember()` has exactly one
+   caller; test_price_history.py parses every shipped module for the name and
+   grades the order by driving it.
+2. "Yesterday" is the Brussels day before the instant asked about, not the
+   newest record; any other date is `no_data` naming both dates.
+3. A store that cannot answer says so in the type: `yesterday()` returns a
+   `PriceRead`, never an empty series.
+4. Hours accumulate within a day (merge by instant, the newer price wins), so a
+   feed that serves only the remaining hours cannot overwrite a full day.
 
-So this module is the half FCST-03 left out, and it is deliberately the SMALL
-half: the fill's arithmetic, its DST rule and its provenance audit all stay in
-`price_forecast.py`, untouched. What lives here is the one thing that
-arithmetic needs and could not have: A YESTERDAY THAT SURVIVES A RESTART.
-
-
-WHY PERSISTENCE, AND NOT A VARIABLE ON THE REFRESH TASK
-======================================================
-An in-memory "the last full day I saw" costs nothing and is wrong exactly when
-it matters. The window the fill exists for is midnight -> publication; an
-add-on restarted at 08:00 - a config change, an HA update, a power cut - would
-come up with no yesterday at all and spend that whole window on the truncated
-series, which is the pre-FCST-03 behaviour arriving silently on the mornings
-after an operator touched something. The fill's own value is a function of
-surviving a restart, so the day it carries has to.
-
-⚠️ AND NOT IN `/data/state.json`. That file holds the maintenance history and
-SAFETY-02's sign latch, and `Store.set()` rewrites the whole of it on every
-write. The tariff refresh runs every `TARIFF_REFRESH_S` (1800 s), so folding a
-price cache into it would put 48 extra whole-file rewrites a day through the
-file whose corruption reads as "no maintenance ever ran" and "never tripped".
-The cache is worth having; it is not worth putting anywhere near that. Separate
-file, separate blast radius.
-
-⚠️ AND THE DIRECTORY IS NOT CREATED, which is `tariff.PeakStore`'s rule and its
-reason applies unchanged: `/data` is mounted by the Supervisor and always
-exists on a real install, so `makedirs` here could only ever succeed where the
-durable volume is MISSING - manufacturing a cache on the container's ephemeral
-layer that writes fine, reads fine, and is thrown away on the next restart.
-That is a yesterday that silently forgets, which is worse than one that says it
-cannot answer.
-
-⚠️ AND THAT RULE IS CARRIED OUT IN `_remember()`, NOT ONLY IN `_save()`. FCST-04
-first shipped it half-done: `_save()` short-circuited on `not self.ok` while
-`_remember()` filled `self._days` anyway, so a store with no durable volume
-answered `words` = "unavailable" and `yesterday()` = A SERIES - an in-memory
-yesterday that works all day and is gone on the next restart, which is exactly
-the silently-forgetting cache this rule exists to refuse. A store that cannot
-persist now records nothing, and both of its answers say the same thing.
-
-⚠️ AND "CANNOT PERSIST" IS ONE QUESTION, ASKED ONCE, ABOUT THE OUTCOME -
-FCST-06. The paragraph above enforced that rule against `not self.ok`, which is
-one SYMPTOM of not persisting: the durable volume is missing. There is a second,
-and FCST-06 measured it. With `ok=True` and the directory present, `_save()` can
-still fail - a read-only remount (`[Errno 30] Read-only file system`), a full
-volume (`[Errno 28] No space left on device`) - and it logs, records
-`last_error` and returns. `_remember()` had already populated `self._days`, so
-`words` read `'2026-01-14 (24 points over 24 h); 2026-01-15 (24 points over
-24 h) [could not write (...)]'` while the file on disk held `{}`, and
-`yesterday()` answered 24 REAL POINTS for the rest of the process's life. Gone
-on the next restart, and nothing said it would be - the same silently-forgetting
-cache, reached by the condition the rule did not name.
-
-⚠️ SO IT IS NOT TWO RULES, AND IT IS DELIBERATELY NOT TWO TESTS. "Can this
-store persist?" CANNOT BE ANSWERED BEFORE THE ATTEMPT - a directory that existed
-and was writable a moment ago is not a write that completed - so it is answered
-AFTER it, once, by the only thing holding the evidence: `_save()` returns
-whether the file now holds what memory holds. A missing volume is one of its
-False cases and an `OSError` from the write is another, and `_remember()` KEEPS
-ONLY WHAT THAT ONE ANSWER SAYS WAS KEPT. There is no `not self.ok` test in
-`_remember()` any more, because there is nothing left for a second test to add -
-and a third symptom nobody has thought of is how this defect arrived both times.
-
-⚠️ AND WHAT IS KEPT IS THE LAST STATE THAT IS ON DISK, NOT AN EMPTY ONE. The
-MERGE is undone, not the store. A site whose volume fills at 14:00 goes on
-answering the yesterday it wrote at 13:30 - that record survives a restart, so
-answering it is not a promise the store cannot keep. What it stops doing is
-adding to it. The invariant the rule was always describing, stated once:
-`self._days` NEVER HOLDS A POINT THE FILE DOES NOT. (Not "mirrors the file" -
-`_usable_days()` drops records the file still holds. The only direction that can
-invent a yesterday is the one named.)
-
-
-THE FOUR RULES THIS FILE IS SHAPED BY
-=====================================
-
-1. IT RECORDS WHAT THE PROVIDER PUBLISHED, NEVER WHAT THE FILL PRODUCED.
-   Feeding a filled series back in is the defect that makes the whole mechanism
-   rot: day 2 carries day 1's guesses, day 3 carries day 2's carry of them, and
-   after a week of a dead feed the "yesterday" being carried forward is a
-   fossil of the last real publication with nothing anywhere reporting its age.
-   Every point still carries `provisional=True`, so the flag never lies - what
-   decays is the NUMBER, silently, behind a flag that is telling the truth.
-
-   ⚠️ NO VALUE-LEVEL CHECK CAN CATCH THAT, and saying so is more useful than a
-   guarantee that would not hold. A carried point and a published-provisional
-   point (a real-time product's current interval, §9.2) are the same three
-   fields with
-   the same flag; the difference is provenance, and provenance is not in the
-   value. So the mechanism is ORDERING, not validation: `carry()` is the only
-   public entry point, it remembers the argument and returns the fill, and the
-   filled series exists only as a return value that `carry()` itself never
-   sees again. `_remember()` is private, is called from exactly one place, and
-   `test_price_history.py` PARSES every shipped module under `app/`, `tools/`,
-   `scenarios/` and `estop/` and fails if any of them uses the NAME - an
-   attribute, a bare name, a def, or the string constant a `getattr` needs. By
-   name rather than by substring, so a comment about the rule does not fail it
-   and a call from `tools/` cannot pass unseen.
-
-   ⚠️ AND THE ORDER IS GRADED BY DRIVING IT, NOT BY READING THE SOURCE. The
-   first version of that check compared positions in `ast.walk`, which is
-   breadth-first: `self._remember(...)` is a statement and `self.yesterday(...)`
-   is an ARGUMENT of the fill, one level deeper, so `_remember` came out first
-   whichever statement was written first - shipped and reversed scored the
-   same. What grades it now is the behaviour: a feed carrying yesterday
-   alongside today, into an EMPTY store, must fill the whole horizon, and
-   reversed it fills nothing.
-
-2. "YESTERDAY" MEANS YESTERDAY, NOT "THE NEWEST DAY I HAVE".
-   `newest()` is the natural accessor and it is the one that decays: an add-on
-   down from Friday to Monday would answer Friday's prices to a fill that flags
-   them as one day old. The lookup is BY DATE - the Brussels day before the
-   Brussels day of the instant asked about - and a record for any other date is
-   NO_RECORD with a reason naming both dates. A three-day-old profile is not a
-   worse yesterday; it is not a yesterday.
-
-3. A STORE THAT CANNOT ANSWER SAYS SO, IN THE TYPE.
-   `yesterday()` returns a `PriceRead`: a `series` when a full record exists,
-   `no_data(reason)` for every other outcome - no file, no record for that
-   date, an unreadable file, a record that parses to nothing. There is no
-   empty-series answer and no `.get(..., [])`-shaped accessor, for
-   `price.py`'s reason: an empty series is how "the cache is broken" gets to
-   wear the shape of "yesterday was free". `fill_from_yesterday()` takes a
-   `PriceRead` and handles `no_data` on its own, so the degraded case needs no
-   branch at the call site - it fills nothing and the horizon stays short,
-   which is exactly the behaviour that shipped before this ticket.
-
-4. HOURS ACCUMULATE WITHIN A DAY; THEY DO NOT REPLACE IT.
-   A feed that serves only the REMAINING hours of the day (a legitimate shape -
-   nothing in the plugin contract promises a whole day) would, under
-   replace-the-record, overwrite a complete 24-hour profile with the two points
-   left at 22:00 and hand the next morning a yesterday with two hours in it. So
-   a record is MERGED by instant: a later read updates the hours it carries and
-   leaves the rest, and a revised price for an hour already held wins because
-   it is the newer statement about the same hour.
-
-⚠️ KEYED BY INSTANT, NOT BY LOCAL HOUR, AND THAT IS THE DST DECISION. Storing
-`hour -> price` would collapse the two 02:00s of a 25-hour October day into
-one, inventing a second and different collapsing rule beside the one
-`fill_from_yesterday()` already documents ("the first of its two 02:00 points
-is the one used, deterministically"). Storing the instants keeps both, in
-order, and lets the fill's own rule be the only one in the system.
-
-WHAT THIS DOES NOT DO, ON PURPOSE
-=================================
-It does not extend the fill to a feed that published NOTHING. `resolve_tariff()`
-applies `carry()` only on a `series` read; a `no_data` read still falls to
-`_degrade()` and §11.4's row - "No price data -> fall back to the static
-profile, mark the plan provisional, no arbitrage" - which is the fallback the
-operator configured `static_profile` FOR. Preferring yesterday's feed over it
-would change a documented degradation without being asked, and it would buy
-nothing measurable: a fully-carried series is 100 % provisional, so
-`arbitrage()` finds fewer than two firm hours and refuses, and `cheap_now()` is
-False, exactly as on the §11.4 fallback. The two differ only in which numbers
-the status page shows. `fill_from_yesterday()` handles a `no_data` read anyway,
-and that branch is therefore not reached from production - it stays checked,
-and turning it on is a product decision, not a wiring one. See
-DECISIONS/FCST-04-the-day-that-is-carried.md.
-"""
+Rows are keyed by instant, not local hour (the DST rule stays in the fill). A
+store that cannot persist records nothing (FCST-06). It does not extend the fill
+to a feed that published nothing: that stays 11.4's static fallback.
+DECISIONS/FCST-04-the-day-that-is-carried.md (section 5 has the store details)."""
 
 import copy
 import json
@@ -194,89 +33,31 @@ from .price_forecast import fill_from_yesterday
 
 _LOG = logging.getLogger("goodwe.price.history")
 
-# How many Brussels days of published prices the SORT-ORDER cap keeps. The fill
-# needs exactly one - yesterday - and rule 2 refuses anything older, so this is
-# not a horizon: it is the number of days a record may sit unused before
-# pruning removes it, and it is small because a bigger cache would only hold
-# days no lookup can ask for. Three covers today, yesterday, and the day a
-# fetch spanning midnight writes ahead of itself.
-#
-# ⚠️ IT IS A CAP, NOT THE RETENTION RULE, AND THREE HAS NO SLACK. The steady
-# state is already {yesterday, today, tomorrow}; a feed that publishes to D+2,
-# or ONE stray point in the wrong year - which sorts LAST and is therefore
-# immortal under a newest-N cap - pushes yesterday out of a three-slot store
-# and keeps it out, permanently and silently. So `_prune()` PINS the two days a
-# lookup can actually ask for on top of the cap; see its docstring. The store
-# is then bounded at KEEP_DAYS + 2 records rather than at KEEP_DAYS.
+# Brussels days kept: a sort-order cap, not a horizon (the fill needs only
+# yesterday).
 KEEP_DAYS = 3
 
 SCHEMA = 1
 
 
 def _bdate(instant: datetime) -> str:
-    """The Brussels calendar date of an instant, as `YYYY-MM-DD`.
-
-    ⚠️ BRUSSELS, NOT UTC. 23:30 UTC in July is already tomorrow in Belgium, and
-    a cache keyed on the UTC date would file the last 90-120 minutes of every
-    day under the wrong one - so a lookup on the following morning would find a
-    "yesterday" missing its own evening hours, which are the expensive ones.
-    """
+    """The Brussels calendar date of an instant, as `YYYY-MM-DD` (not UTC: 23:30 UTC in July is tomorrow)."""
     return brussels(instant).strftime("%Y-%m-%d")
 
 
 def _yesterday_of(instant: datetime) -> str:
     """The Brussels date of the day BEFORE `instant`'s Brussels day.
-
-    ⚠️ THE ARITHMETIC IS ON THE LOCAL DATE, NOT ON THE INSTANT, AND THAT IS A
-    DST DEFECT THIS FILE SHIPPED. `brussels()` renders at the FIXED offset in
-    force at that instant, so `brussels(stamp) - timedelta(days=1)` subtracts 24
-    ABSOLUTE hours from a wall clock - and the Brussels day before a
-    spring-forward is 23 hours long. Measured at 2026-03-30T00:30+02:00, the
-    first hour of the morning after the March transition: it returned
-    2026-03-28, so the fill carried a TWO-DAY-OLD profile flagged as yesterday's
-    (or, with only the last three days held, answered `no_data` naming a date
-    that is not yesterday).
-
-    A calendar day minus one day is `date` arithmetic, and a `date` has no
-    offset to lose. The 25-hour October day is right for the same reason.
-    """
+    Arithmetic on the local `date`, not the instant: subtracting 24 absolute hours
+    was wrong after the spring-forward. DECISIONS/FCST-04-the-day-that-is-carried.md."""
     return (brussels(instant).date() - timedelta(days=1)).strftime("%Y-%m-%d")
 
 
 def _point_of(row):
     """One stored row -> a `PricePoint`, or `None` if the row is not one.
 
-    THE ONE VALIDATOR, AND THE ASYMMETRY IT CLOSES (FCST-05's MEDIUM). This
-    file used to hold TWO standards for what a stored point is. The READ path
-    (`_parse_points()`) was properly defensive - every field checked, a
-    malformed row dropped and reported. The WRITE path was
-    `{q["start"]: q for q in raw if isinstance(q, dict) and "start" in q}`
-    followed by `sorted(..., key=lambda q: q["start"])`, which trusts
-    `q["start"]` to be a hashable, sortable string it never checked. Measured,
-    with the malformed row under the day the feed is currently writing to:
-
-        start is an int   -> TypeError: '<' not supported between instances
-                             of 'str' and 'int'
-        start is a dict   -> TypeError: cannot use 'dict' as a dict key
-        start is null     -> TypeError: '<' not supported between 'str' and
-                             'NoneType'
-        start is a list   -> TypeError: cannot use 'list' as a dict key
-
-    ⚠️ AND THE BLAST RADIUS IS PERMANENT, WHICH IS WHY IT IS NOT MERELY UNTIDY.
-    `_remember()` is reached through `carry()` -> `resolve_tariff()` ->
-    `run_tariff_refresh`, which catches `Exception` - so the add-on stays UP
-    and EVERY refresh raises forever. The plan retires after
-    `TARIFF_MAX_AGE_S`, and arbitrage and the cheap window are off from then
-    on. There is no self-heal, because `_remember()` raises before it reaches
-    `_save()`. `_usable_days()` only required `rec["points"]` to be a LIST; the
-    elements were unchecked on the write path, and the existing fixture put its
-    malformed row under a day the feed was NOT writing to, so `_remember()`
-    never touched it.
-
-    So both paths call this, and neither of them has a standard of its own.
-    Returning `None` rather than raising is the contract: a caller decides
-    whether a bad row is dropped (both of them do) and how it is reported.
-    """
+    The one validator for both the read and the write path (FCST-05): a malformed
+    row used to raise out of `carry()` and fail every refresh for good. Returns
+    `None` rather than raising; the caller decides how a bad row is reported."""
     if not isinstance(row, dict):
         return None
     try:
@@ -293,33 +74,8 @@ def _point_of(row):
 
 def _held(rec) -> tuple:
     """`(points, whole hours they cover)` for a day record. `(0, 0)` otherwise.
-
-    ⚠️ POINTS AND HOURS ARE TWO NUMBERS, AND FCST-04's STATUS ROW PRINTED THE
-    FIRST UNDER THE SECOND'S NAME. The row was `f"{d} ({_n_points(rec)} h)"`,
-    which counts POINTS: on the quarter-hourly feed this add-on already
-    supports it read `'2026-01-13 (96 h)'` - 96 "h" for a 24-hour day. That is
-    the points/hours conflation H1 was raised for, on the row H1's own ticket
-    shipped. Both numbers are reported now, so an operator can see a day that
-    is 24 points over 24 h and a day that is 96 points over 24 h and tell them
-    apart, and neither number is wearing the other's unit.
-
-    ⚠️ TOLERANT, AND IT IS THE SECOND LINE OF DEFENCE, NOT THE FIRST. `_load()`
-    drops a malformed day record and says so, so this should never see one. It
-    is written this way because `words` is read from `Controller.__init__` and
-    from every status render: a status LINE that raises takes the add-on down,
-    and "the cache is broken" must never be able to mean "the controller does
-    not start". That is exactly what FCST-04 shipped - `{"days": {"2026-01-14":
-    "oops"}}` gave `ok=True`, `last_error=None`, and an `AttributeError` out of
-    `words`, `yesterday()` and `resolve_tariff()` alike, with no self-heal
-    because `_remember()` raised before it could rewrite the file.
-
-    ⚠️ AND IT COUNTS ONLY ROWS THAT ARE POINTS. A row `_point_of()` refuses is
-    not held prices, and a row count that included it would report a store as
-    healthier than it is - which is the second half of FCST-05's MEDIUM: the
-    status row said `'2026-01-15 (1 h)'` about a record whose single row was
-    killing every tariff refresh. What is dropped is named in `last_error`, and
-    `words` prints that beside the counts.
-    """
+    Two numbers, each in its own unit (96 points over 24 h on a quarter-hourly
+    feed). Total, and counts only rows that are points."""
     if not isinstance(rec, dict):
         return (0, 0)
     raw = rec.get("points")
@@ -337,15 +93,7 @@ def _held(rec) -> tuple:
 
 
 def _row_of(day: str, points: int, hours: int) -> str:
-    """One day's cell of the status row: what is held, in BOTH of its units.
-
-    ⚠️ THE UNIT IS SPELT OUT ON EACH NUMBER. FCST-04's cell was
-    `f"{day} ({points} h)"` - the point count wearing the hour's name, which on
-    a quarter-hourly feed reads `'2026-01-13 (96 h)'` for a 24-hour day. What
-    an operator needs from this row is whether tomorrow morning's fill has a
-    whole day to carry, and that is the HOUR figure; the point count says how
-    finely it is priced. Neither answers for the other.
-    """
+    """One day's cell of the status row, with the unit spelt out on each number."""
     # UX-10: the day as the page writes dates ("26 Sep"), not ISO.
     return (f"{points} price{'' if points == 1 else 's'} over {hours} "
             f"hour{'' if hours == 1 else 's'} for {day_words(day)}")
@@ -373,21 +121,8 @@ def _bad_rows(rec) -> int:
 
 class PriceHistory:
     """The published price series of the last few Brussels days, in /data.
-
-    ⚠️ `ok` IS ABOUT THE FILE, NOT ABOUT THE DATA. A healthy store with no
-    record for yesterday is `ok` and answers `no_data` - a normal state on a
-    site's first day, and a different thing from a store that could not be
-    opened. Both are visible: `ok`/`last_error` describe the file, and
-    `yesterday()`'s reason describes the answer.
-
-    ⚠️ AND `ok` IS NOT "CAN PERSIST" (FCST-06). It says the directory was
-    there when the store opened, which a full volume and a read-only remount
-    both leave true. The one thing that answers "can this store persist" is
-    `_save()`'s return value, and `self._days` NEVER HOLDS A POINT THE FILE DOES
-    NOT, because `_remember()` undoes a merge that answer refused. That is what
-    makes `words` and `yesterday()` describe the same store in EVERY degraded
-    state rather than only in the ones somebody enumerated.
-    """
+    `ok` is about the file, not the data: a healthy store with no record for
+    yesterday is `ok` and answers `no_data`. `ok`/`last_error` describe the file."""
 
     def __init__(self, path: str = "/data/price_history.json"):
         self.path = path
@@ -396,15 +131,14 @@ class PriceHistory:
         self._days: dict = {}
         self._open()
 
-    # -- the file ------------------------------------------------------------
+    # the file
     def _open(self) -> None:
         parent = os.path.dirname(self.path)
-        # See the module note: NOT created. A cache on the ephemeral layer is
-        # one that forgets without saying so.
+        # NOT created (see FCST-04 section 5): a cache on the ephemeral layer
+        # forgets silently.
         if parent and not os.path.isdir(parent):
             self.last_error = f"no durable volume at {parent}"
-            # INFO, not ERROR: on a dev host or in a test container there is no
-            # /data and nothing is wrong.
+            # INFO, not ERROR: a dev host or test container has no /data.
             _LOG.info("No price history is kept (%s), so missing hours are "
                       "not filled from yesterday's prices.", self.last_error)
             return
@@ -421,32 +155,11 @@ class PriceHistory:
                       "after that", self.path)
             return
         except (ValueError, OSError) as err:
-            # A corrupt cache must not stop the controller, and must not be
-            # silently re-created either: the record is discarded, the reason
-            # is kept, and `yesterday()` reports it rather than answering
-            # "no record", which would read as a normal first day.
-            #
-            # ⚠️ `ValueError`, NOT `json.JSONDecodeError`, AND THAT IS
-            # FCST-05's HIGH. Reading this file has two failure families: the
-            # BYTES (`OSError`) and the CONTENT - and the content family has at
-            # least two members, because `open(..., encoding="utf-8")` decodes
-            # before `json` ever sees a character. `UnicodeDecodeError` is
-            # `ValueError -> UnicodeError -> UnicodeDecodeError`; it is NOT a
-            # `json.JSONDecodeError` and it is NOT an `OSError`
-            # (`issubclass(UnicodeDecodeError, OSError)` is False). So ONE
-            # non-UTF-8 byte in /data/price_history.json escaped `_load()` ->
-            # `_open()` -> `PriceHistory.__init__`, which is unguarded at
-            # main.py's `Controller.__init__`, AND THE ADD-ON DID NOT START.
-            # Measured: `UnicodeDecodeError: 'utf-8' codec can't decode byte
-            # 0xff in position 39`. Valid-UTF-8-invalid-JSON, a UTF-8 BOM and a
-            # non-dict day record all degraded correctly - it was the one byte
-            # class left uncovered, which is the same class as the defect the
-            # `_usable_days()` rework was raised for.
-            #
-            # The tuple names the FAMILY rather than the two members known
-            # today, because "the file's content is not readable as JSON" is
-            # exactly what this handler says, and a third `ValueError` subclass
-            # nobody has thought of is how this defect arrived the first time.
+            # A corrupt cache must not stop the controller nor be silently re-
+            # created: the record is discarded and the reason kept, so
+            # `yesterday()` reports it. `ValueError` is the family caught, not
+            # `json.JSONDecodeError` (one non-UTF-8 byte raised
+            # `UnicodeDecodeError` and the add-on did not start, FCST-05).
             self.last_error = f"unreadable ({err})"
             _LOG.warning("Price history at %s is %s, so it starts empty. "
                          "Missing hours cannot be filled in until a full day "
@@ -454,10 +167,7 @@ class PriceHistory:
                          self.path, self.last_error)
             return
         found = blob.get("version") if isinstance(blob, dict) else None
-        # ⚠️ THE TYPE IS PART OF THE VERSION. `1.0 == 1` in Python, so a float
-        # written by some other tool would pass a bare `!=` and be read as
-        # schema 1 - a version check that cannot tell 1 from 1.0 is one that
-        # would not notice a writer this build has never met.
+        # The type is part of the version: `1.0 == 1` in Python.
         if not isinstance(blob, dict) or isinstance(found, bool) \
                 or not isinstance(found, int) or found != SCHEMA:
             self.last_error = f"version {found!r}, not {SCHEMA}"
@@ -474,35 +184,8 @@ class PriceHistory:
 
     def _usable_days(self, days: dict) -> dict:
         """The day records that are shaped like day records. The rest are dropped.
-
-        ⚠️ THE ASYMMETRY THAT PRODUCED THE DEFECT: `_parse_points()` below is
-        carefully defensive about every field of a POINT, and `_load()` was not
-        defensive about the record holding them at all. `{"version": 1, "days":
-        {"2026-01-14": "oops"}}` therefore loaded as `ok=True`,
-        `last_error=None` - and then `rec.get(...)` raised `AttributeError` out
-        of `words`, `yesterday()` and `resolve_tariff()`. `PriceHistory(...)`
-        and `.words` are both unguarded in `Controller.__init__`, so THE ADD-ON
-        DID NOT START; and it never self-healed, because `_remember()` raised on
-        the same record before it could reach `_save()`.
-
-        A broken cache is a short horizon. It is not a controller that will not
-        regulate a battery, and §6's rule - absent machinery must not disable
-        the loop - does not stop applying because the machinery is a JSON file.
-
-        Dropped, not repaired: an unusable record has nothing in it to keep, and
-        the next `_remember()` writes a fresh one under that date.
-
-        ⚠️ AND THE ROWS INSIDE A KEPT RECORD ARE COUNTED, NOT ONLY THE RECORD
-        (FCST-05). This checked that `rec["points"]` is a LIST and stopped
-        there, so a record holding one row with a `start` of `7` loaded as
-        healthy: `last_error=None`, and `words` said `'2026-01-15 (1 h)'` about
-        a store whose next `_remember()` would raise on that row and go on
-        raising forever. The rows are NOT dropped here - `_parse_points()` is
-        the read path's one filter and stays so - but they are COUNTED, so the
-        store stops reporting health it does not have from the moment it is
-        opened. `_remember()` drops them on the next refresh and `_save()`
-        rewrites the file, after which a restart clears the note.
-        """
+        A broken cache is a short horizon, never a controller that will not start.
+        Rows inside a kept record are counted, not dropped (`_parse_points()` filters)."""
         kept, dropped, malformed = {}, [], {}
         for key, rec in days.items():
             if not isinstance(key, str) or not isinstance(rec, dict) \
@@ -524,9 +207,8 @@ class PriceHistory:
                 + ", ".join(f"{day_words(d)} ({n})"
                             for d, n in sorted(malformed.items())))
         if notes:
-            # Recorded, not silent: `yesterday()` and `words` both report
-            # `last_error`, and a cache that quietly discards half a file reads
-            # to an operator exactly like a normal first day.
+            # Recorded, not silent: a cache that quietly discards half a file
+            # reads like a first day.
             self.last_error = " and ".join(notes)
             _LOG.warning("Price history at %s: %s. The add-on starts anyway, "
                          "and fills in only what the rest holds.",
@@ -535,27 +217,7 @@ class PriceHistory:
 
     def _save(self) -> bool:
         """Write `self._days` out. True only if the file now holds it.
-
-        ⚠️ THE RETURN VALUE IS THE "CAN THIS STORE PERSIST?" PREDICATE, AND
-        IT IS THE ONLY ONE (FCST-06). Both ways of not persisting end here and
-        are the same answer: no durable volume returns False without touching
-        the disk, an `OSError` out of the write returns False after recording
-        why. `_remember()` acts on that one answer, so the second place that
-        used to test the first symptom on its own - and missed the second - has
-        nothing left to test. See the module docstring's fifth warning.
-
-        ⚠️ AND IT REPORTS, IT DOES NOT RAISE. §6 and this module's opening: a
-        broken cache must not be a broken controller. An add-on that will not
-        start because /data filled up is a worse defect than the one FCST-06
-        fixed, so a failed write is logged, kept in `last_error` - where `words`
-        and `yesterday()` both read it - and RETURNED, never thrown.
-
-        ⚠️ THE TEMP FILE IS REMOVED ON EVERY FAILING PATH. A write that dies
-        between `mkstemp` and `os.replace` used to leave its temp behind, and
-        the refresh task runs 48 times a day: a persistent write failure - a
-        full volume being the likeliest cause - leaked 48 inodes a day onto the
-        volume that was already the problem.
-        """
+        The one "can this store persist?" answer (FCST-06), asked after the attempt."""
         if not self.ok:
             return False
         tmp = None
@@ -563,8 +225,7 @@ class PriceHistory:
             fd, tmp = tempfile.mkstemp(dir=os.path.dirname(self.path))
             with os.fdopen(fd, "w", encoding="utf-8") as fh:
                 json.dump({"version": SCHEMA, "days": self._days}, fh, indent=1)
-            # Atomic: a power cut mid-write must not leave a truncated file
-            # that parses as an empty day.
+            # Atomic: a power cut mid-write must not leave a truncated file.
             os.replace(tmp, self.path)
             tmp = None                      # it IS the file now; do not unlink
         except OSError as err:
@@ -579,45 +240,24 @@ class PriceHistory:
                     pass                    # failed cleanup is not a fault
         return True
 
-    # -- the one public entry point -----------------------------------------
+    # the one public entry point
     def carry(self, read: PriceRead, *, since: datetime, until: datetime,
               stamp: datetime, remember: bool = True) -> PriceRead:
-        """Remember what this read published, then §8.3-fill the missing hours.
-
-        THE ORDER IS DELIBERATE AND IS THE POINT OF THE METHOD. The read is
-        recorded FIRST, so a feed that hands back yesterday alongside today
-        refreshes yesterday's record from live data before it is consumed as
-        the profile; and the filled series - the one thing that must never be
-        recorded - exists only as this method's return value, which this object
-        never sees again. See rule 1, including how that order is graded.
-
-        Returns whatever `fill_from_yesterday()` returns: a series over the
-        whole hours of [since, until), carrying EVERY point the provider
-        published inside it - by identity, and four of them in one hour on a
-        quarter-hourly feed - plus one carried point for each remaining whole
-        hour FOR WHICH YESTERDAY HELD THAT WALL-CLOCK HOUR. An hour neither
-        source can price is left out (§11.4 for that hour), and `no_data` comes
-        back when that is every hour.
-        """
+        """Remember what this read published, then 8.3-fill the missing hours.
+        Recorded FIRST, so the filled series exists only as the return value (rule 1).
+        Returns `fill_from_yesterday()`'s series, or `no_data` when no hour can be priced."""
         if remember:
-            # PRICE-01: False only for a read that CAME FROM this store
-            # (`stored()`), which is already filed; filing it again would
-            # rewrite the same file for nothing, and nothing else may pass it.
+            # PRICE-01: False only for a read that came from this store,
+            # already filed.
             self._remember(read, stamp)
         return fill_from_yesterday(read, yesterday=self.yesterday(stamp),
                                    since=since, until=until, stamp=stamp)
 
-    # -- the halves, private because rule 1 is an ordering ------------------
+    # the halves, private because rule 1 is an ordering
     def _remember(self, read: PriceRead, stamp: datetime) -> None:
         """File a provider read's points under their own Brussels days.
-
-        ⚠️ PRIVATE, AND CALLED FROM EXACTLY ONE PLACE. A caller that can reach
-        this can record a filled series, which is the decay in rule 1. There is
-        no value-level defence against that - a carried point and a published
-        provisional point are the same three fields - so the defence is that
-        nothing outside this file names it, and `test_price_history.py` checks
-        the tree for that rather than trusting the underscore.
-        """
+        Private, called from exactly one place: no value-level defence can tell a
+        carried point from a published-provisional one, so the defence is the ordering."""
         points = read.match(series=lambda r: r.points, no_data=lambda _r: ())
         if not points:
             return
@@ -626,23 +266,9 @@ class PriceHistory:
         provider = read.match(series=lambda r: r.provider,
                               no_data=lambda _r: None)
 
-        # ⚠️ THE STATE THIS READ STARTED FROM, KEPT SO IT CAN BE PUT BACK
-        # (FCST-06). Everything below merges into `self._days` IN PLACE, and
-        # whether any of it may be KEPT is not knowable until `_save()` has
-        # tried - so the merge runs, and it is undone if the file did not take
-        # it. There is no `not self.ok` branch above any more: a store with no
-        # durable volume is one of the answers `_save()` gives, not a separate
-        # symptom with a test of its own. Module docstring, fifth warning.
-        #
-        # ⚠️ DEEP, NOT `dict(self._days)`. A one-level copy shares the day
-        # RECORDS, and the loop below rebinds keys on the ones it touches - so
-        # the "previous" state would hand back records the merge had already
-        # edited, and a store with a good yesterday on disk would go on
-        # answering the merge of it that never reached the file. It would also
-        # be right only for as long as nobody makes this loop mutate a `points`
-        # list or a row in place. A copy that is right by construction outlives
-        # that, and the store holds at most KEEP_DAYS + 2 records, 48 times a
-        # day.
+        # The state this read started from, kept so it can be put back
+        # (FCST-06): the merge runs in place and is undone if `_save()` did not
+        # take it. Deep copy, since the loop rebinds the day records.
         before = copy.deepcopy(self._days)
 
         touched = set()
@@ -651,29 +277,11 @@ class PriceHistory:
             day = _bdate(p.start)
             rec = self._days.setdefault(
                 day, {"product": product, "provider": provider, "points": []})
-            # Rule 4: MERGE by instant. A later read updates the hours it
-            # carries and leaves the rest; a revised price for an hour already
-            # held wins, because it is the newer statement about that hour.
-            #
-            # ⚠️ EVERY HELD ROW GOES THROUGH `_point_of()` (FCST-05's MEDIUM).
-            # This was `{q["start"]: q for q in raw if isinstance(q, dict) and
-            # "start" in q}` sorted by `q["start"]` - a key and a sort key that
-            # trusted a value read off disk to be a hashable, sortable string.
-            # An `int`, `null`, a `dict` or a `list` there raised `TypeError`
-            # out of `carry()` on the day the feed was writing to, and
-            # `run_tariff_refresh` caught it, so the add-on stayed up while
-            # EVERY refresh failed for good. A row that is not a point is now
-            # dropped and reported here, exactly as the read path drops it, and
-            # `_save()` below writes the record back clean - which is the
-            # self-heal the raising version could never reach.
-            #
-            # ⚠️ AND THE MERGE KEY IS THE VALIDATED INSTANT, NOT ITS SPELLING.
-            # Aware datetimes hash and compare by instant, so this is rule 4 as
-            # rule 4 is written. The old string key merged by SPELLING, and the
-            # old lexicographic sort put the second 02:00 of the 25-hour
-            # October day (`+01:00`) BEFORE the first (`+02:00`). Only the
-            # stored order was affected - `_parse_points()` re-sorts by instant
-            # on the way out - but the store now holds what it says it holds.
+            # Rule 4: MERGE by instant; a later read updates the hours it
+            # carries. Every held row goes through `_point_of()` and the key is
+            # the validated instant, not its spelling (FCST-05). A row that is
+            # not a point is dropped and reported, and `_save()` writes the
+            # record back clean.
             raw = rec.get("points")
             held = {}
             for q in (raw if isinstance(raw, list) else ()):
@@ -689,13 +297,8 @@ class PriceHistory:
             touched.add(day)
 
         if junked:
-            # Said, not swallowed. `words` prints `last_error`, so a store that
-            # has just discarded rows off disk stops reporting plain health -
-            # and after `_save()` below the file is clean, so a restart clears
-            # this. `_save()` overwrites it if the write itself fails, which is
-            # the more urgent fact of the two - and on that path the drop is
-            # undone with the rest of the merge, so those rows are still in the
-            # file and the next write that completes drops them again.
+            # Said, not swallowed: `words` prints `last_error`. A failed
+            # `_save()` overwrites it and undoes the drop.
             self.last_error = (
                 f"{messages.count(sum(junked.values()), 'bad price')} dropped "
                 f"from " + ", ".join(f"{day_words(d)} ({n})"
@@ -705,48 +308,19 @@ class PriceHistory:
                          self.path, self.last_error)
         self._prune(stamp)
         if not self._save():
-            # ⚠️ A STORE THAT CANNOT PERSIST RECORDS NOTHING - the rule, asked
-            # ONCE as a question about the outcome instead of tested twice
-            # against two symptoms of it. Keeping the merge here is exactly the
-            # cache the module docstring refuses: `yesterday()` would answer a
-            # series the file does not contain, all day, until a restart
-            # dropped it without a word - and `words` and `yesterday()` would
-            # be describing two different stores. The reason is already in
-            # `last_error` (from `_save()`, or from `_open()` when there is no
-            # volume at all), so both answers now describe what is on disk.
-            #
-            # It does NOT raise, and §6 is why: a broken cache must not be a
-            # broken controller. `carry()` still returns the fill, the horizon
-            # is as short as the feed makes it, and the add-on regulates.
+            # A store that cannot persist records nothing (FCST-06):
+            # `_save()`'s answer decides what is kept, so `yesterday()` never
+            # answers a series the file does not hold.
             self._days = before
             return
         _LOG.debug("price history: %d point(s) filed under %s; %d day(s) held",
                    len(points), ", ".join(sorted(touched)), len(self._days))
 
     def _prune(self, stamp: datetime) -> None:
-        """Drop records no lookup can reach. A sort-order cap, plus two pins.
-
-        ⚠️ NOTHING IS DELETED BY ARITHMETIC AGAINST THE CLOCK. A clock that
-        jumped - the failure mode WITNESS-03 spent a session on - would
-        otherwise delete every record in one pass and leave the fill with
-        nothing on the morning after, which is the one morning it is for.
-        Deleting on a bad clock is unrecoverable; holding a few days too many
-        is not, so the cap is `sorted(...)[-KEEP_DAYS:]` and stays that way.
-
-        ⚠️ AND A CAP ALONE IS DEFEATED BY ONE POINT IN THE WRONG YEAR. Sorting
-        is lexicographic on the date string, so a stray far-future record sorts
-        LAST and is immortal - it consumes a slot for good, and with the steady
-        state already {yesterday, today, tomorrow} filling all three, yesterday
-        is what falls out. A feed that publishes to D+2 does the same thing
-        without any stray at all. So the two days `yesterday()` can ACTUALLY be
-        asked for are pinned on top of the cap.
-
-        `stamp` is READ here, which it was not before: the pin is the only use
-        of it, and it is additive. Pinning can only RETAIN a record, never
-        delete one, so a jumped `stamp` pins two dates that are not held and
-        changes nothing - the WITNESS-03 property is preserved by construction
-        rather than by remembering to check it.
-        """
+        """Drop records no lookup can reach: a sort-order cap plus two pins. Nothing is
+        deleted by arithmetic against the clock (a jumped clock would delete everything,
+        WITNESS-03). The pin of the two dates `yesterday()` can be asked for only
+        retains, so a far-future record cannot push yesterday out."""
         if len(self._days) <= KEEP_DAYS:
             return
         keep = set(sorted(self._days)[-KEEP_DAYS:])
@@ -756,11 +330,7 @@ class PriceHistory:
 
     def yesterday(self, stamp: datetime) -> PriceRead:
         """The published series of the Brussels day BEFORE `stamp`'s, or no_data.
-
-        ⚠️ THE DATE IS COMPUTED, NOT LOOKED UP. See rule 2: `newest()` would
-        answer Friday's prices to a Monday fill, and the fill would flag them as
-        one day old because that is the only thing its flag can say.
-        """
+        Computed, not looked up (rule 2)."""
         if stamp.tzinfo is None or stamp.utcoffset() is None:
             raise ValueError(
                 f"yesterday({stamp!r}): a naive datetime is not an instant, "
@@ -803,19 +373,9 @@ class PriceHistory:
                                 stamp)
 
     def stored(self, stamp: datetime) -> PriceRead:
-        """PRICE-01: every price this store holds, as one series, or no_data.
-
-        This is the LAST step of the price server's fallback (price_chain.py):
-        the answer of the last fetch that worked, kept on disk, so a site can
-        plan for as long as the days it holds last. It is a read of what was
-        PUBLISHED and filed, in the order they happened, and it is never the
-        carried fill (rule 1 holds: `carry(..., remember=False)` is how this
-        read is filled, and it is not filed again).
-
-        The prices are the all-in ones stored when they were fetched. They are
-        not worked out again, so a change of markup or taxes shows from the
-        next fetch that works, not in these.
-        """
+        """PRICE-01: every price this store holds, as one series, or no_data. The last
+        step of the price server's fallback (price_chain.py): what was PUBLISHED and
+        filed, never what a fill produced."""
         if stamp.tzinfo is None or stamp.utcoffset() is None:
             raise ValueError(f"stored({stamp!r}): a naive datetime is not an "
                              f"instant")
@@ -833,25 +393,12 @@ class PriceHistory:
         return PriceRead.series(points, PriceProduct.DAY_AHEAD,
                                 "price_history", stamp)
 
-    # -- observability -------------------------------------------------------
+    # observability
     @property
     def words(self) -> str:
         """One line for the status page. Says what is held, or why nothing is.
-
-        ⚠️ THIS MUST NOT RAISE, EVER. It is read once from `Controller.__init__`
-        and again on every status render, and neither call site guards it - so
-        an exception here is an add-on that does not start. It went out that
-        way: a day record that was a string instead of a dict raised
-        `AttributeError` from the `len(...)` below. `_load()` now drops such a
-        record and `_held()` is total, so this has two independent reasons not
-        to fail on a broken file.
-
-        ⚠️ AND IT COUNTED POINTS AND CALLED THEM HOURS (FCST-05's LOW). The row
-        was `f"{d} ({_n_points(rec)} h)"`; on the quarter-hourly feed this
-        add-on already supports that reads `'2026-01-13 (96 h)'` for a 24-hour
-        day. Both numbers are printed now - see `_held()` - because they are
-        two different facts and only one of them was ever being shown.
-        """
+        Must not raise, ever: it runs from `Controller.__init__` and every status
+        render, unguarded. Prints points and hours separately (FCST-05)."""
         if not self.ok:
             return f"unavailable - {self.last_error}"
         if not self._days:
@@ -859,26 +406,20 @@ class PriceHistory:
             return f"empty{why} - nothing to carry forward yet"
         held = ", ".join(_row_of(d, *_held(self._days[d]))
                          for d in sorted(self._days, key=str))
-        # A file that PARTLY loaded says so, or the dropped days read as days
-        # that were simply never written.
+        # A file that partly loaded says so, or dropped days read as never
+        # written.
         return held + (f" [{self.last_error}]" if self.last_error else "")
 
 
 def _parse_points(raw) -> tuple:
-    """Canonical dicts -> PricePoints, and a phrase naming what was dropped.
-
-    ⚠️ A MALFORMED POINT IS DROPPED, NOT DEFAULTED, and the drop is reported.
-    `float(row.get("eur_per_kwh", 0))` is the shape of the whole family of
-    defects this repo has been removing: a cache that lost a field would answer
-    "that hour was free" to a fill that flags it as an ordinary guess.
-    """
+    """Canonical dicts -> PricePoints, and a phrase naming what was dropped. A
+    malformed point is dropped, not defaulted: a lost field must not read as a free hour."""
     if not isinstance(raw, list):
         return (), "the `points` field is not a list"
     out, dropped = [], 0
     for row in raw:
-        # ⚠️ `_point_of()` IS THE ONE VALIDATOR, and this loop used to BE it.
-        # The write path had its own, weaker standard; see `_point_of()` for
-        # what that cost. One standard, two callers, no asymmetry to re-open.
+        # `_point_of()` is the one validator; this loop used to be a weaker
+        # one.
         pt = _point_of(row)
         if pt is None:
             dropped += 1
@@ -889,20 +430,8 @@ def _parse_points(raw) -> tuple:
 
 
 class NoHistory:
-    """The explicit "this caller keeps no history" - a NAME, not a `None`.
-
-    ⚠️ IT EXISTS SO THE PARAMETER CAN BE REQUIRED. `history=None` meaning "skip
-    the fill" is the shape this repo keeps removing: a caller who forgets the
-    argument gets the truncated-horizon behaviour of the bug this ticket is
-    about, silently, and the code reads as though the fill is happening. With
-    no default there is nothing to forget, and a caller with no durable volume
-    - a check, a replay harness - has to say `NoHistory()` and be visible in
-    the diff.
-
-    It carries out the ordering faithfully: it records nothing and carries
-    nothing, so `carry()` returns the provider's read unchanged and the plan is
-    exactly what it was before FCST-04.
-    """
+    """The explicit "this caller keeps no history": a NAME, not `None`, so the
+    parameter can be required. It records nothing and carries nothing."""
 
     ok = False
     last_error = "no history is kept by this caller"

goodwe_controller/app/solarfc.py

@@ -38,7 +38,8 @@ midnight, if it is at most `KEPT_MAX_AGE_S` old when used.
 Never beyond that, and never for another day: a today figure is only today's,
 a tomorrow figure is tomorrow's until midnight and then, until the bell starts
 (`BELL_FROM_H`, 06:00 local), today's (OPT-34: at most `KEPT_MORNING_MAX_AGE_S`
-old, and it must have been usable at midnight).
+old, it must have been usable at midnight, and no fresh today reading may
+have replaced it since).
 DECISIONS/OPT-27-last-fresh-forecast-for-the-night.md,
 DECISIONS/OPT-34-the-night-charge-keeps-its-level.md.
 
@@ -351,6 +352,13 @@ class Hold:
         evening = _local_hour(now) >= BELL_TO_H and now < _bounds(day0)[1]
         return (day, at, True) if evening else None
 
+    def replaced(self, entities, day0) -> bool:
+        """OPT-34 F-1: every today sensor has given a fresh reading for
+        `day0` (so after midnight, newer than any evening figure). The
+        evening's tomorrow figure is then no stand-in for today any more,
+        also once those readings are stale."""
+        return all(("today", e, day0) in self._r for e in entities)
+
     def dump(self) -> dict:
         return {"v": 1, "r": [
             [kind, ent, d.day0.isoformat(), d.kwh, at.isoformat(),
@@ -492,7 +500,8 @@ def read_sum(today, tomorrow, now: datetime, hold: Hold | None = None):
     where `Hold.stand_in()` allows it (the forecast then has `kept` set when
     that took a reading older than `FRESH_S`). After midnight, if the today
     side is still short, the tomorrow figures read before midnight are
-    today's, until the bell starts (`stand_in()`). Without a `hold` this is
+    today's, until the bell starts (`stand_in()`), unless fresh today
+    readings have replaced them (`Hold.replaced()`). Without a `hold` this is
     exactly as before."""
     if not today:
         return None, NOT_SET, ()
@@ -537,7 +546,8 @@ def read_sum(today, tomorrow, now: datetime, hold: Hold | None = None):
         # day; all of them are needed, as for any sum.
         subs = [hold.stand_in("tomorrow", ent, day0, now, as_today=True)
                 for ent, _st in tomorrow]
-        if all(r is not None for r in subs):
+        if all(r is not None for r in subs) and not hold.replaced(
+                [ent for ent, _st in today], day0):
             days = [r[0] for r in subs]
             ats = [r[1] for r in subs]
             gaps = [g for g in gaps if g[0] != "today"]

goodwe_controller/config.yaml

@@ -1,5 +1,5 @@
 name: GoodWe RS485 Controller
-version: "0.19.2"
+version: "0.20.0"
 slug: goodwe_controller
 description: >-
   Drives a GoodWe ES/BP battery inverter over its RS485 EMS port by sending it a

goodwe_controller/test_opt34.py

@@ -36,6 +36,8 @@ DECISIONS note and the dev report.
       and before a charge has started, up and down;
    e. the last hour, after the kept figure has ended at 06:00: the charge under
       way goes on to its level, also over a restart; the screens say so.
+   f. F-1 (rig): one fresh reading at 02:00, then silent again: when it is
+      stale (05:00) the 17:05 figure it replaced does not come back.
 3. The text, EN and NL.
 4. `_latch_charge()` alone: a battery that leaves the plan leaves the latch.
 """
@@ -193,6 +195,47 @@ for label, now in (("01:00", at(4, 1, 0)), ("04:00", at(4, 4, 0))):
           "17:05 figure again", fr is not None and fr.kept
           and fr.today.kwh == 12.0 and fr.at == at(3, 17, 5))
 
+# F-1 (rig): a fresh today reading at 02:00 replaces the 17:05 figure; once
+# that reading is stale (05:00) the 17:05 figure must not come back.
+for label, kwh in (("brighter", 40.0), ("darker", 1.0)):
+    hn = hold_of(at(3, 17, 5))
+    f2 = rs(st(kwh, at(4, 2, 0)), st(kwh, at(4, 2, 0)), at(4, 2, 1), hn)[0]
+    f4 = rs(GONE, GONE, at(4, 4, 59), hn)[0]
+    snap = json.loads(json.dumps(hn.dump()))
+    f5 = [rs(GONE, GONE, t, hn)[0] for t in (at(4, 5, 1), at(4, 5, 59))]
+    f5s = [rs(st(kwh, at(4, 2, 0)), st(12.0, at(3, 17, 5)), t, hn)[0]
+           for t in (at(4, 5, 1), at(4, 5, 30))]
+    check(f"F-1 {label} 02:00 reading: used fresh at 02:01 and kept for "
+          "a missing sensor to 04:59 (3 h)",
+          f2 is not None and not f2.kept and f2.today.kwh == kwh
+          and f4 is not None and f4.today.kwh == kwh and not f4.kept)
+    check("... and from 05:01 (stale) to 05:59: no forecast, never the "
+          "17:05 figure (sensors gone, or showing their old readings)",
+          all(x is None for x in f5 + f5s))
+    back = solarfc.Hold(snap)
+    check("... also after a restart at 03:00 (the saved hold keeps the "
+          "02:00 reading)", rs(GONE, GONE, at(4, 3, 0), back)[0] is not None
+          and rs(GONE, GONE, at(4, 5, 1), back)[0] is None)
+# Two today sensors, only one read fresh: the sum never had a fresh figure,
+# so the evening one still stands in (as before).
+h2 = solarfc.Hold()
+td2 = [("sensor.t1", st(0.2, at(3, 17, 5))),
+       ("sensor.t2", st(0.2, at(3, 17, 5)))]
+tm2 = [("sensor.m1", st(6.0, at(3, 17, 5))),
+       ("sensor.m2", st(6.0, at(3, 17, 5)))]
+gone2 = [(e, GONE) for e, _s in td2], [(e, GONE) for e, _s in tm2]
+solarfc.read_sum(td2, tm2, at(3, 17, 10), h2)
+solarfc.read_sum([("sensor.t1", st(9.0, at(4, 2, 0))), td2[1]], tm2,
+                 at(4, 2, 1), h2)
+g5 = solarfc.read_sum(*gone2, at(4, 5, 1), h2)[0]
+check("two today sensors, only one read fresh at 02:00: the evening sum "
+      "(12.0) still stands in at 05:01", g5 is not None and g5.kept
+      and g5.today.kwh == 12.0)
+solarfc.read_sum([td2[0], ("sensor.t2", st(9.0, at(4, 2, 10)))], tm2,
+                 at(4, 2, 11), h2)
+check("... and once both have read fresh, it does not",
+      solarfc.read_sum(*gone2, at(4, 5, 20), h2)[0] is None)
+
 # DST: the 25 h autumn day and the 23 h spring day. The window ends at 06:00
 # LOCAL, not 6 h after midnight.
 for (y, mo, d), label in (((2026, 10, 25), "25 h day 2026-10-25"),
@@ -431,6 +474,19 @@ SCEN = {
                        soc={"a": 65.0, "b": 95.0},
                        marks=[at(4, 5, 50), at(4, 6, 10), at(4, 6, 45)]),
 }
+# F-1 (rig 4v): silent from 17:05, one fresh reading at 02:00, silent again.
+# It is stale at 05:00, before the 06:00 bell: the 17:05 figure it replaced
+# must not come back. Brighter (A's level drops), with a restart at 03:00,
+# and darker (the level rises).
+F1_MARKS = [at(4, 1, 55)] + [at(4, 2, 15) + timedelta(minutes=15 * i)
+                             for i in range(19)]
+for k, kwh, rst, hw in (("f1_bright", 30.0, (), 700.0),
+                        ("f1_bright_rs", 30.0, (at(4, 3, 0),), 700.0),
+                        ("f1_dark", 1.0, (), 500.0)):
+    SCEN[k] = dict(start=at(4, 1, 30), hours=5.5, house_w=hw,
+                   soc={"a": 50.0, "b": 50.0}, fresh_from=at(4, 2, 0),
+                   fresh_until=at(4, 2, 0), fresh=(kwh, kwh),
+                   restarts=list(rst), marks=F1_MARKS)
 t0 = time.time()
 with ProcessPoolExecutor(max_workers=min(6, os.cpu_count() or 2),
                          mp_context=get_context("fork")) as pool:
@@ -563,6 +619,45 @@ check("(control: the same latch, still valid until tomorrow 07:15, does "
       f"charge both: A {sl_['soc'][0]:.1f}, B {sl_['soc'][1]:.1f} %)",
       sl_["soc"][0] > 11.0 and sl_["soc"][1] > 11.0
       and sl_["marks"]["22:20"]["state"] == "latched")
+for k in ("f1_bright", "f1_bright_rs"):
+    fb = R[k]
+    mk = fb["marks"]
+    lo_t = mk["02:15"]["target_a"]
+    after = [mk[h] for h in sorted(mk) if h >= "02:15"]
+    print(f"    {k}: A level 01:55 {mk['01:55']['target_a']} -> 02:15 "
+          f"{lo_t}; A {fb['soc_at']['02:15'][0]:.1f} % at 02:15, "
+          f"{fb['soc_at']['06:55'][0]:.1f} % at 06:55; lines "
+          + " | ".join(sorted({x['line'] for x in after})))
+    check(f"F-1 {k}: a brighter fresh figure at 02:00 lowers A's level "
+          "below its SoC and A stops",
+          lo_t is not None and mk["01:55"]["target_a"] is not None
+          and lo_t < mk["01:55"]["target_a"] - 10.0
+          and lo_t < mk["02:15"]["soc_a"])
+    check(f"... after 02:00 the screen never says 'read 17:05' and from "
+          "05:15 there is no forecast, with the LOWERED level",
+          all("17:05" not in x["line"] and not (x["kept"] and
+                                                 not x["fc_none"])
+              for x in after)
+          and all(mk[h]["fc_none"] and near(mk[h]["target_a"], lo_t, 0.5)
+                  for h in mk if "05:15" <= h < "07:00"))
+    check(f"... so A stays at its lowered level to 07:00 "
+          f"({fb['soc_at']['02:30'][0]:.1f} -> "
+          f"{fb['soc_at']['06:55'][0]:.1f} %)",
+          fb["soc_at"]["06:55"][0] < fb["soc_at"]["02:30"][0] + 1.0)
+fd = R["f1_dark"]
+md = fd["marks"]
+print(f"    f1_dark: A level 01:55 {md['01:55']['target_a']} -> 02:15 "
+      f"{md['02:15']['target_a']}; A {fd['soc_at']['06:55'][0]:.1f} % "
+      "at 06:55")
+check("F-1 darker fresh figure at 02:00: the level rises, is held after "
+      "05:00 with no forecast (never 'read 17:05'), and A charges to it",
+      md["02:15"]["target_a"] is not None
+      and md["01:55"]["target_a"] is not None
+      and md["02:15"]["target_a"] > md["01:55"]["target_a"] + 3.0
+      and all("17:05" not in md[h]["line"] for h in md if h >= "02:15")
+      and all(md[h]["fc_none"] for h in md if "05:15" <= h < "07:00")
+      and near(fd["soc_at"]["06:55"][0], md["02:15"]["target_a"], 1.5))
+
 tb = R["tail_bfull"]
 check("B full: the run ends at 06:33 before A is at its level, so the next "
       "slice is only A's, planned after the figure has ended with A's "

goodwe_controller/tools/maint20_same_code.py

@@ -0,0 +1,83 @@
+#!/usr/bin/env python3
+"""MAINT-20: prove a comment/docstring cut changed no code, and show the ratio.
+
+    python3 goodwe_controller/tools/maint20_same_code.py [BASE_REF] [FILE ...]
+
+For each FILE (default: every goodwe_controller/app/*.py that differs from
+BASE_REF, default release/1.0) the ast.dump() of the tree with docstrings
+removed must be identical at BASE_REF and in the working tree. Also prints
+code lines vs comment-only + docstring lines (whole lines, via tokenize) before
+and after. Run from the repository root. Exit 1 on any code difference.
+"""
+import ast
+import io
+import subprocess
+import sys
+import tokenize
+
+SCOPES = (ast.Module, ast.FunctionDef, ast.AsyncFunctionDef, ast.ClassDef)
+
+
+def docstring(n):
+    if isinstance(n, SCOPES) and n.body:
+        e = n.body[0]
+        if (isinstance(e, ast.Expr) and isinstance(e.value, ast.Constant)
+                and isinstance(e.value.value, str)):
+            return e
+    return None
+
+
+def dump(src):
+    tree = ast.parse(src)
+    for n in ast.walk(tree):
+        if docstring(n) is not None:
+            n.body = n.body[1:] or [ast.Pass()]
+    return ast.dump(tree)
+
+
+def counts(src):
+    doc = set()
+    for n in ast.walk(ast.parse(src)):
+        e = docstring(n)
+        if e is not None:
+            doc.update(range(e.lineno, e.end_lineno + 1))
+    skip = (tokenize.NL, tokenize.NEWLINE, tokenize.INDENT, tokenize.DEDENT,
+            tokenize.ENDMARKER, tokenize.COMMENT)
+    code, com = set(), set()
+    for tk in tokenize.generate_tokens(io.StringIO(src).readline):
+        if tk.type == tokenize.COMMENT:
+            com.add(tk.start[0])
+        elif tk.type not in skip:
+            code.update(range(tk.start[0], tk.end[0] + 1))
+    code -= doc
+    return len(code), len(doc) + len(com - code - doc)
+
+
+def git(*a):
+    return subprocess.run(["git", *a], check=True, capture_output=True,
+                          text=True).stdout
+
+
+def main(argv):
+    base = argv[0] if argv else "release/1.0"
+    files = argv[1:] or [
+        f for f in git("diff", "--name-only", base, "--",
+                       "goodwe_controller/app").split()
+        if f.endswith(".py")]
+    bad = 0
+    print(f"base {base} = {git('rev-parse', base).strip()}")
+    for f in files:
+        old = git("show", f"{base}:{f}")
+        new = open(f, encoding="utf-8").read()
+        same = dump(old) == dump(new)
+        (c0, m0), (c1, m1) = counts(old), counts(new)
+        print(f"{'SAME CODE' if same else 'CODE DIFFERS'}  {f}  "
+              f"code {c0}->{c1}  comment+doc {m0}->{m1}  "
+              f"ratio {m0 / c0:.2f}->{m1 / c1:.2f}")
+        bad += not same
+    print("OK: no code change" if not bad else f"FAIL: {bad} file(s) differ")
+    return 1 if bad else 0
+
+
+if __name__ == "__main__":
+    sys.exit(main(sys.argv[1:]))