FCST-05: one byte stops stopping the add-on, and the write path gets the read path's standard

HIGH - a non-UTF-8 byte in /data/price_history.json stopped the add-on
from starting. `_load()` caught `(json.JSONDecodeError, OSError)`.
`UnicodeDecodeError` is `ValueError -> UnicodeError -> UnicodeDecodeError`:
neither of those, and `issubclass(UnicodeDecodeError, OSError)` is False. So
it escaped `_load()` -> `_open()` -> `PriceHistory.__init__`, which
`Controller.__init__` does not guard - breaking `_load()`'s own stated
contract, "a corrupt cache must not stop the controller". The handler now
names the ValueError FAMILY (the file's content) beside OSError (its bytes),
because a third subclass nobody has thought of is how this arrived the first
time. The suite could not see it: its "unreadable file" fixture writes
"{ this is not json", which is valid UTF-8 and fails one step later, in
`json`. A fixture holding a genuinely undecodable byte is now beside it,
with the difference between the two asserted as a precondition.

MEDIUM - a malformed `start` under the day the feed is writing to killed the
tariff plan permanently. `_remember()` merged with `{q["start"]: q ...}` and
sorted on `q["start"]`, trusting a value read off /data to be a hashable,
sortable string. An int, null, a dict or a list raised TypeError out of
`carry()` -> `resolve_tariff()` -> `run_tariff_refresh`, which catches
Exception - so the add-on stayed UP while every refresh raised forever, the
plan retiring after TARIFF_MAX_AGE_S with arbitrage and the cheap window off
for good, and no self-heal because `_remember()` raised before `_save()`.
The read path was properly defensive throughout, which is why `yesterday()`
survived and the existing fixture passed - it files its malformed rows under
a day the feed is NOT writing to. Both paths now share one validator,
`_point_of()`. A row that is not a point is dropped, reported, and written
back out clean.

...and the status row said the store was healthy while the plan was dead:
`words` read '2026-01-15 (1 h)'. `_load()` now counts the rows inside a kept
record as well as the record itself, so the store stops reporting plain
health from the moment it is opened; the note names what was FOUND at open
and what was DROPPED by the refresh, and clears once the file is rewritten.

...and the merge key is the validated INSTANT rather than its spelling,
which is what rule 4 already said. The lexicographic sort beside the string
key also put the second 02:00 of the 25-hour October day (+01:00) before the
first (+02:00); stored order only, since `_parse_points()` re-sorts.

LOW - the status row counted POINTS and printed them under the HOUR's name:
'2026-01-13 (96 h)' for a 24-hour day on the quarter-hourly feed this add-on
already supports. It is now '96 points over 24 h' - two facts, each under
its own unit.

LOW - two stated reasons were false. `_audit`'s "WHY IT IS STRICTER" claimed
the rework refused the same published point emitted twice and a carried
point sharing a published hour, "which the old count never looked at". A
differential over the whole domain the audit can express finds ZERO
divergence in both directions: the old `seen` count already refused the
first (one point twice is one hour twice) and the old IDENTITY rule already
refused the second. The reworked audit is EQUAL to FCST-03's, not stronger;
the only behavioural change is the intended relaxation, and it stays. The
differential is committed as a check rather than left as prose.

...and the audit's real limit is named: it does not check COMPLETENESS. Fed
the decimation defect FCST-04 was raised for it ACCEPTS, and it accepts an
empty output. So `_audit` is not what stops that recurring - the count and
identity checks are, and the text now points at them. Not made complete:
`published` is the whole read while the fill emits only [since, until), so
the rule as stated is wrong, and building it takes the 1/12/48 h horizon
checks red on a healthy feed. Measured, not assumed.

12 mutations, purged tree, every one RED, no survivors. All 29 test files
green. Nothing deployed; no option added; config.yaml untouched.

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

goodwe_controller/CHANGELOG.md

@@ -13,6 +13,89 @@ if it has, it needs 0.10.0. Whoever deploys decides.
 | | |
 |---|---|
 | _this branch_ | FCST-04 - the carry-forward fill reaches the plan, and the day it carries survives a restart |
+| _this branch_ | FCST-05 - one byte stops stopping the add-on, and the write path gets the read path's standard |
+
+### FCST-05 - what FCST-04's own contract still did not hold
+
+**A single non-UTF-8 byte in `/data/price_history.json` stopped the add-on from
+starting.** `_load()` caught `(json.JSONDecodeError, OSError)`.
+`UnicodeDecodeError` is `ValueError -> UnicodeError -> UnicodeDecodeError` -
+neither of those, and `issubclass(UnicodeDecodeError, OSError)` is **False** -
+so it escaped `_load()` -> `_open()` -> `PriceHistory.__init__`, which
+`Controller.__init__` does not guard. Reproduced: `UnicodeDecodeError: 'utf-8'
+codec can't decode byte 0xff`, and **the controller did not come up**. That is the same class as the day-record defect the store was reworked
+for, in the one byte class the rework left uncovered: valid-UTF-8-invalid-JSON,
+a UTF-8 BOM and a non-dict day record all degraded correctly. The suite could
+not see it because its "unreadable file" fixture writes `"{ this is not json"`,
+which is **valid UTF-8**. The handler now names the `ValueError` family - the
+file's CONTENT - beside `OSError`, the file's BYTES, and a fixture holding a
+genuinely undecodable byte is in `test_price_history.py` section 5.
+
+**A malformed `start` under the day the feed is writing to killed the tariff
+plan permanently.** `_remember()` merged a day's points with
+`{q["start"]: q ...}` and sorted on `q["start"]`, trusting a value read off
+`/data` to be a hashable, sortable string. An `int`, `null`, a `dict` or a
+`list` there raised `TypeError`; `run_tariff_refresh` catches `Exception`, so
+the add-on stayed **up** while **every refresh raised, forever** - the plan
+retiring after `TARIFF_MAX_AGE_S` and arbitrage and the cheap window off for
+good, with no self-heal because `_remember()` raised before reaching `_save()`.
+The read path (`_parse_points()`) was properly defensive throughout, which is
+why `yesterday()` survived and the existing fixture passed: it files its
+malformed rows under a day the feed is **not** writing to, so `_remember()`
+never opened that record. **The two paths now share one validator**,
+`_point_of()`, and neither has a standard of its own. A row that is not a point
+is dropped and reported, and `_save()` rewrites the record clean.
+
+⚠️ **AND THE STATUS ROW SAID THE STORE WAS HEALTHY WHILE THE PLAN WAS DEAD.**
+`words` read `'2026-01-15 (1 h)'` about the record that was killing every
+refresh. `_load()` now counts the rows inside a kept record as well as the
+record itself, so the store stops reporting plain health from the moment it is
+opened; the note names what was **found** at open and what was **dropped** by
+the refresh, and clears itself once the file has been rewritten.
+
+⚠️ **AND THE ROW COUNTED POINTS AND CALLED THEM HOURS.** `f"{d} ({_n_points(d)}
+h)"` on the quarter-hourly feed this add-on already supports reads
+`'2026-01-13 (96 h)'` for a 24-hour day - the same points/hours conflation the
+sub-hourly defect above was about, on the row that defect's own card shipped.
+The cell is now `2026-01-13 (96 points over 24 h)`: two facts, each under its
+own unit, and the hour figure is the one that says whether tomorrow morning's
+fill has a whole day to carry.
+
+⚠️ **AND THE MERGE KEY IS THE INSTANT RATHER THAN ITS SPELLING**, which is what
+rule 4 already said. Aware datetimes hash and compare by instant. The string
+key merged by spelling, and the lexicographic sort beside it put the second
+02:00 of the 25-hour October day (`+01:00`) **before** the first (`+02:00`);
+only the stored order was affected, because `_parse_points()` re-sorts by
+instant on the way out.
+
+⚠️ **TWO STATED REASONS WERE FALSE, AND THIS REPOSITORY TREATS THAT AS A
+DEFECT.** `price_forecast._audit()`'s "WHY IT IS STRICTER" section claimed the
+rework refused two things FCST-03's audit did not. A differential over the
+whole domain the audit can express - every published mask over 3 hours crossed
+with every output series of length 0-3 - found **zero divergence in both
+directions**: the reworked audit is exactly **EQUAL** to FCST-03's, not
+stronger. The old `seen` count already refused the same published point emitted
+twice (one point twice is one hour twice), and the old **identity** rule
+already refused a carried point sharing a published hour. The only behavioural
+change is the intended **relaxation** - several distinct published points in
+one hour - and that stays. The docstring and the two check texts now say what
+is true, and the differential is committed as a check in
+`test_price_forecast.py` rather than left as prose.
+
+⚠️ **AND `_audit` IS NOT WHAT STOPS THE DECIMATION DEFECT RECURRING.** It does
+not check **completeness**: fed the decimation directly - four published points
+in an hour, output emitting only the last - it **accepts**, and it accepts an
+empty output. That is a limit, not a regression, and the module docstring said
+otherwise by presenting the audit as the post-condition guarding provenance.
+What actually guards it is the point **count** and the pass-through **identity**
+checks in `test_price_forecast.py` and `test_price_history.py`, and the text now
+points at them. It is **not** made complete: `published` is the whole read while
+the fill emits only `[since, until)`, so "every published point appears" is not
+a true post-condition of those two arguments. Measured - the rule as stated
+takes the 1 h, 12 h and 48 h horizon checks red on legitimate series.
+
+**No option was added, `config.yaml` is untouched, and nothing was deployed.**
+
 
 **FCST-03 shipped the fill and no caller.** `price_forecast.fill_from_yesterday()`
 was complete and checked, and so were the consumers written for it -
@@ -58,8 +141,9 @@ spread it would have created was never compared against anything.
   no durable volume passes the explicit `NoHistory()`. A default of `None`
   meaning "skip the fill" would hand a caller who forgot the argument exactly
   the truncated horizon this card removes, silently.
-* A new status row, **Price history**, names the days held and their hour
-  counts.
+* A new status row, **Price history**, names the days held, how many points
+  each holds and how many whole hours they cover (see FCST-05: it shipped
+  counting points and printing them under the hour's name).
 
 ⚠️ **ONE CHANGE HERE MOVES ENERGY, AND IT IS NOT THE ONE THE CARD IS NAMED FOR.**
 Carried hours are provisional, so §8.3 keeps them out of the trade set: the fill