9 Commits

Include renames

Author	SHA1	Message	Date
glenn schrooyenandClaude Opus 5	ae21b71824	Merge release/1.0 into SAFETY-30 ... CFG-04 (#45) merged first and moved the base. Two conflicts, both resolved as the union of the two sides: - app/main.py: an import-block collision. CFG-04 added validate_unit_ranges to the .validate import; SAFETY-30 added AGAINST_METER, AGAINST_OWN_POWER, SIGN_OPTION_DEFAULTS and SignWatchdog to the .watchdog import. Neither side dropped anything, so the resolution keeps both lists whole. - CHANGELOG.md: two adjacent new entries under ## Unreleased. Both kept. Both sides also independently rewrote large parts of test_peakguard.py (60 and 47 insertions against the merge base) and git merged them textually, so the full suite was run on the MERGE RESULT rather than inferred from the two parents: 19 passed, 0 failed, twice. One caveat recorded rather than hidden: test_peakguard.py failed once during the first sequential full-suite run and then passed 10/10 in isolation and in two further full runs on this same tree. It passes on both parents too, so this is the pre-existing flakiness CFG-04 already disclosed, not a merge defect - it is timing- or load-sensitive. It sits on the required CI context and can therefore block an unrelated merge at random, which wants a card of its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-04 12:23:50 +02:00
glenn schrooyenandClaude Opus 5	d5c1577212	SAFETY-30: pin WHICH thresholds each sign detector is armed with, not just what the numbers are ... REVIEW FOUND A MUTATION SURVIVOR THAT UNDOES THE WHOLE PRODUCT OF AC 5, and it is a coverage defect rather than a behaviour one - the shipped code arms the detectors correctly today. In `_arm_sign_watchdogs()`, collapsing inv.sign_wd.arm(self.sign_cfg if one else self.unit_sign_cfg, ...) to `arm(self.sign_cfg, ...)` throws the re-derived 250 W / 85 s per-unit pair away and arms every unit with SAFETY-02's meter-facing 300 W / 180 s - and left ALL 19 FILES GREEN. Reproduced here before fixing anything: fresh per-mutation tree, no __pycache__, mounted :ro, graded through tools/mutation_run.sh; -31 B; 19 pass, 0 fail. WHY NOTHING CAUGHT IT. `grep -rn "sign_wd.cfg" test_*.py` found exactly ONE threshold assertion, part 7's N=1 arm at (300.0, 1.0) - which the mutation PRESERVES. Nothing at a roster of two read `inv.sign_wd.cfg` at all. The ledger mutates the VALUES in SIGN_OPTION_DEFAULTS (M10 250->300, M11 325->180, both correctly red through the config pins) and never the WIRING that delivers them. Part 3's behavioural checks cannot close the gap either, and the comment now says why: B is reversed at ~2000 W with short holds, so it trips under EITHER pair, and a fault big enough and long enough to trip under both thresholds is evidence about neither. THE FIX - test_watchdog.py part 3, on the real two-inverter Controller. Every `inv.sign_wd.cfg` equals the per-unit pair, `site_sign_wd.cfg` equals the site pair, and each detector's `against` is its own instrument. Graded against LITERALS, because `== self.unit_sign_cfg` cannot tell "the per-unit pair" from "whatever this Controller was handed". Both pairs are printed. ⚠️ AND THE FIXTURE HAD TO CHANGE FOR THE PIN TO MEAN ANYTHING - the recursion worth naming, because it is the same defect class as the one being closed. `_sign_site` set `sign_disagree_s`, `unit_sign_disagree_s` AND `site_sign_disagree_s` all to 1 s, with two of the three magnitude gates at 300 W. A bare equality there discriminates on `min_w` alone: a mis-wiring that delivered the right magnitude with the WRONG HOLD compares EQUAL to the pair it was supposed to have. A check comparing two things that happen to be equal cannot see the difference it names (MUTATION.md's third failure mode). The three pairs are now pairwise distinct IN BOTH COORDINATES - 250 W / 1 s per unit, 320 W / 2 s site, 300 W / 3 s shipped - a PRECONDITION asserts that distinctness so a later edit collapsing them goes red rather than quietly vacuous, and a second PRECONDITION asserts the literals are the pairs this Controller actually holds. VERIFIED BY BREAKING IT. Three mutations, each on its own freshly copied tree with no __pycache__, mounted :ro, through tools/mutation_run.sh: M14 arm() handed self.sign_cfg at every roster -31 B RED (was the survivor; the AC 5 WIRING check names the wiring) M15 right min_w, SHIPPED hold - hold-only mis-wire +78 B RED, same pin M16 right min_w, SITE hold - hold-only, and it still trips inside the drive +83 B RED, and the ONLY red in test_watchdog.py M16 is the one that says the hold half of the equality bites on its own. Unmutated tree: 19 pass, 0 fail, purged and fingerprinted. Ledger rows M14-M16 and the write-up in DECISIONS/SAFETY-30-per-unit-sign.md section 5; a CHANGELOG bullet. NOT IN THIS PR, so it gets a card rather than a quiet fix: a stuck per-unit power sensor would false-trip the new per-unit check at N>=2. Already-merged SAFETY-31 has the identical exposure on the same fixture. Pre-existing N>=2 class, unreachable at the deployed roster of one. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-04 11:13:13 +02:00
glenn schrooyenandClaude Opus 5	22c016fadd	CFG-04 fix round: the probe now measures the key it is cited for ... Review blocked this on ONE finding, and it was in the EVIDENCE, not the code. The design and the shipped behaviour are unchanged. THE INSTRUMENT DID NOT MEASURE WHAT FOUR DOCUMENTS SAID IT MEASURED tools/supervisor_shape_probe.py section B validated the RECONSTRUCTED LIVE options blob - which is missing many required keys that have nothing to do with this card. Its refusal therefore named whichever of THOSE the validator reached first: the committed transcript recorded `meter_freeze_s`, the reviewer's run printed `p1_phase_export_entities`, and a run today printed `sign_disagree_w`. The string those documents quoted - `Missing option 'inverters' in root` - was never produced by the instrument. And section B asserted a bare `not ok`. Any refusal at all satisfied it, so deleting `inverters: []` from config.yaml left it printing PASS: the probe could not detect the one regression it is the committed evidence for. THE UNDERLYING CLAIM IS TRUE AND IS NOW MEASURED PROPERLY Section B is an ISOLATED COUNTERFACTUAL now: the full shipped `options:` block (expect accept), and the SAME block with `inverters` removed and nothing else varying (expect refusal). One key differs, so the refusal has nowhere else to come from - and the assertion is on the KEY NAME IN THE REFUSAL STRING, so the line goes red if the refusal is ever about a different key. The probe also exits non-zero when any case fails; without that a transcript is only evidence to someone who reads it. The old live-blob case survives as section B2, relabelled for what it is: an incomplete reconstruction whose RAW half is refused for unrelated missing keys, kept because its MERGED half genuinely demonstrates what App.options is. VERIFIED BY BREAKING IT, WHICH IS THE WHOLE POINT `inverters: []` deleted from config.yaml, probe re-run against ghcr.io/home-assistant/amd64-hassio-supervisor:2026.08.0: == B. THE LOAD-BEARING ONE: an options blob with no `inverters` key == FAIL the shipped `options:` block validates AS IT STANDS - ... Missing option 'inverters' in root in GoodWe RS485 Controller ... == 2 CASE(S) FAILED == exit 1. Key restored, same image, same command: `== all cases passed ==`, exit 0. The transcript in DECISIONS is that restored run, re-run today, not the old one. THE FOUR MIS-CITATIONS DECISIONS/CFG-04-inverter-roster.md section 4's "section B shows both halves" sentence and its line-103 transcript; CHANGELOG.md; test_inverter.py's part-9 comment and its part-12 mutation row; and the PR description. All now attribute the string to section B and say plainly what section B2 does not show. The part-12 row additionally records that the probe was blind to that mutation until review, because a mutation table that lists a defeat nothing catches is the failure this repository keeps finding. MUTATION.md gains it as the sixth instance of "the check's data cannot reach the failure it names" - the first found OUTSIDE the suite, in a committed evidence artifact, because nothing in that document had ever been pointed at tools/. Three habits with it: assert on the CONTENT of a refusal rather than that one happened; vary ONE thing, from an ACCEPTED baseline; and treat a committed transcript as a check subject to the mutation battery. TWO NON-BLOCKING FINDINGS, ALSO FIXED validate.py rules 5 and 6 NAMED THE WRONG INVERTER. `unit_caps()` SKIPS an entry with no usable `max_w`, so caps position i stops being roster position i the moment one entry is malformed - and rule 5 fed `caps.index(weakest)` to `_unit_label()`, which indexes the roster, while rule 6 paired `caps[0]` with a hard-wired `_unit_label(opts, 0)`. Right number, another inverter's name: an operator sent to the wrong device by the message that exists to stop that. New `unit_caps_indexed()` carries the roster index with the cap. It is latent - rule 9(d) refuses such a config in the same pass - but that was a property of today's rule ordering, not of the code, and validate_startup_config() is also sim/inject.py's entry point. Part 10 gains a check that asserts the fixture really does desynchronise the two lists, then that both messages name the right unit, then the counterfactual: the OLD expressions, on that same config, still evaluate to the wrong names. DOCS.md called a downgrade "safe". True of the SCHEMA - the older schema drops the key with a warning - and incomplete about the ADD-ON: rule 9(e) requires the flat `setpoint_entity` be cleared when a roster is declared, so a config that downgrades cleanly is by construction one whose flat actuator is blank, and the older version has nothing to write to. Confirmed by running release/1.0's own validate_startup_config() on that blob: one refusal, naming setpoint_entity. Recoverable and loud, but an outage until a field is refilled. The note says so now, and tells the operator to write the entity down before downgrading. 19/19 green in the goodwe-addon-ci image. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-04 10:33:51 +02:00
adminandClaude Opus 5	f000547518	SAFETY-30: grade each inverter against its own power, and the site's total against the meter ... THE DEFECT, in one line. `inv.sign_wd.evaluate(stood, self.grid, ...)` compared the command THIS controller put on ONE actuator against what the WHOLE SITE is exchanging with the network. At a roster of one those are two views of the same thing - specs.md §6.2's identity - and that is what makes the check sound and what earned it the best record in the safety table (NOTES.md: 93 % agreement while healthy against 4 % during runaway, four observed episodes, zero false positives). At two inverters they are not, and it fails in BOTH directions: FALSE TRIP inverter A commanded -1500 W while the meter reads +1500 W is evidence of nothing when inverter B is discharging 3000 W exactly as told. Nothing is faulty and the highest-value check fires. MISSED the converse, and it is worse. A unit commanded +1500 W and MEASURED at -1500 W, beside a sibling at +1500 W, leaves P1 exactly where a healthy site leaves it. The summation destroys the evidence and no threshold recovers it. DEV-02 had already shipped the per-INSTANCE half - one SignWatchdog per inverter, namespaced latch, a trip on B no longer latching A. What was left was the COMPARISON, and it is two questions rather than one: PER UNIT this unit's standing command against ITS OWN measured power (`Inverter.batt`, holding register 0x0518, per-instance since DEV-02). Conclusion: "the actuator I am driving is not doing what I told it" - a fact about one device, so the remedy stays the per-unit `failsafe` SET that arbiter.CLAIM_SCOPE has classified SCOPE_UNIT from the day it was written. That entry read "the evidence is site-wide and the remedy is not"; the first half is now simply true. SITE the SUM of the standing commands against the meter, as a new `sign_site` SET at P_SAFETY on the site actuator, latched under flat `site_sign_tripped` / `site_sign_reason`. This is the 2026-08-20 fault day and NO per-unit check can see it, because every inverter may be faithfully executing its share of a number that is itself wrong. It stops every inverter and the banner names the site. WHAT IT IS NOT, said here because two guards that overlap without saying so is how a false-alarm generator gets built. It is not SAFETY-31: circulation.py compares the units AGAINST EACH OTHER and catches them pushing power THROUGH each other, which nets to zero at the meter and about which no single command is evidence. This compares each unit against ITS OWN COMMAND. They overlap in exactly one scenario - a unit reversing while its sibling pulls the other way - and test_watchdog.py asserts on that fixture that both fire and what each concludes. It is also not the saturation freeze, which is a MAGNITUDE test (|command - measured| > 500 W) that shapes the loop and fires on a merely saturated unit; this is a DIRECTION test that latches and parks one. THE FOUR NUMBERS, RE-DERIVED AT TWO INVERTERS - one carried with a justification and one refused. 1890 closed-loop runs on admin/goodwe's TEST-19 two-master rig in which NOTHING is faulty, swept over the whole range config.yaml accepts for `gain` and `slew_w`, across load reversals with write staggers and flapping loads, and RUN AT BOTH ROSTERS so the N=1 arm is the control: unit_sign_disagree_w 250 `saturation_w / 2`. The check gates on both sides, opposed, so the smallest gap it can see is 500 W - exactly where compute()'s own anti-windup test already says the inverter is not following. It cannot fire on a divergence the control law calls ordinary tracking. Worst legitimate opposition at 250 W: 10.0 s; the curve is nearly flat, because a unit's own power chases its own command. unit_sign_disagree_s 85 8.5x that 10.0 s, 2.8x the firmware's own 30 s link veto (inverter.LINK_STALE_S), under half the 180 s site hold. site_sign_disagree_w 300 CARRIED. Its argument is the meter's noise floor and the 15 W deadband; the roster touches neither, and the campaign agrees - the gate opens in 994 of 1050 runs at two inverters and 955 of 1050 at one. site_sign_disagree_s 325 NOT CARRIED, and this is the number the card exists to not assume. The worst legitimate crossing at 300 W is 110 s with one inverter and 215 s with TWO, because the command must travel a rail that is the roster sum at a `slew_w` that is not - reachable at gain 0.05, slew_w 50 and a 2.2 kW load reversal, all schema-legal. 180 s would have shipped a false trip. 325 s is 1.51x the measured worst, inside the 900 s billing quarter and inside every episode of the fault day. AT ONE INVERTER NOTHING CHANGES, and "nothing" is asserted rather than assumed. The two questions are the same sentence there, so only the detector that shipped is armed: same comparison against the meter, same 300 W / 180 s, same reason string byte for byte, same namespaced latch and flat rollback mirror, same `failsafe` claim, same banner, same single status row - and the site detector is NEVER CALLED, counted on the object over twelve cycles. VERIFIED BY BREAKING IT. Thirteen mutations on fresh per-mutation trees with no __pycache__, mounted :ro, with the battery refusing to report at all unless the baseline is green. Twelve red on the first pass. M4 - the site half armed at N=1 as well - SURVIVED, because the check read `disagree_since is None` and the unit detector trips first, parks the inverter and leaves the site standing at 0 W: the assertion ran, the sentence was true, and the data could not reach the failure it named. Replaced with a call counter on the object; M4 is red now. Recorded as a survivor in DECISIONS/SAFETY-30-per-unit-sign.md §5, with the first battery's own RED BASELINE - a shared mutation directory read mid-copy - discarded rather than reported. RECORDED, NOT FIXED: the site comparison is defeated by a square-wave load whose half period is about one control cycle, which holds it opposed for ~1000 s. The N=1 control arm is what makes that interpretable - it is identical at the roster this add-on ships, so it is a property of comparing a lagged command against a meter and has nothing to do with the second inverter. It wants an alternation test rather than a number, and a card of its own. SAFETY-24's lo-only asymmetry proof re-run unchanged: 1296 combinations, 0 negative floors, `hi` +inf on every claim, every claim on the SITE actuator. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-04 09:33:20 +02:00
adminandClaude Opus 5	6b85acb0f1	CFG-04: an operator can declare a second inverter, and the shape was measured ... DEV-02 made every per-device value per-instance - rating, SoC, watchdogs, heartbeat, store keys - so the code stopped assuming one inverter. The options schema did not. `build_roster()` returned a list of exactly one and said so in its own docstring, and there was no `inverters:` key for an operator to write, so the roster could only ever be a roster of one. THE SHAPE, AND WHY IT WAS MEASURED RATHER THAN CHOSEN config.yaml had no list-of-objects anywhere, and `static_profile` carries a whole tariff structure as a JSON string in a `str?` precisely because a nested schema was doubted. That is a question about somebody else's software, so it was answered by running it: `tools/supervisor_shape_probe.py` (committed) runs Supervisor 2026.08.0's OWN `AppOptions` validator and `SCHEMA_APP_CONFIG`, out of the release image, against this repository's config.yaml. 2026.08.0 is the version the live install reports. The full transcript and the argument are in DECISIONS/CFG-04-inverter-roster.md. It accepts the list, enforces per-entry types, refuses a missing `name` / `setpoint_entity` / `max_w` BY NAME, renders the option in the UI as a repeatable section, and drops the key with a warning under an older schema - so a downgrade is not the forward trap in reverse. ⚠️ AND THE `inverters: []` DEFAULT IS LOAD-BEARING, WHICH IS THE MEASUREMENT THAT MATTERED MOST. Supervisor answers `Missing option 'inverters' in root` for an options blob that has no such key - which every existing install's has, since the key did not exist when they were written. `App.options` is the shipped `options:` block deep-merged with the operator's stored one, so the empty default is the difference between an upgrade nobody notices and an add-on that cannot start with a schema pinned to the version that would fix it. That is docs/deploy-rollback.md §4's trap in the FORWARD direction, found before it was sprung. The merger was checked too: lists override rather than concatenate, so a non-empty default could not have grown a roster behind the operator's back. NOTHING IS INHERITED, WHICH IS DEV-02 RESTATED AS A CONFIG RULE `name`, `setpoint_entity` and `max_w` are required of every entry. An entry that omits `soc_entity` has no SoC sensor; it does not borrow the flat one. A three-line fallback would have rebuilt the sibling-grading defect DEV-02 spent a card removing, in YAML. Defaults still live in exactly one place (CFG-03): there is no per-entry default anywhere, because there is no optional per-entry number. A flat `setpoint_entity` left set beside a declared roster is refused rather than ignored - it names an actuator nothing will write. TWO PERMISSIVE READERS IN SHIPPED CODE, AND THREE MORE IN THE CHECKS validate.py rules 5 and 6 compared their thresholds against the FLAT `max_w`. At a roster of two 2000 W units with `max_w: 5000` left over from a single-inverter install, `sign_disagree_w: 3000` passed rule 5 while SAFETY-02's watchdog could fire on NEITHER unit - rule 5's own failure mode, reached through rule 5. They read `unit_caps()` now, which at one inverter is `[max_w]` exactly. main.py's `run_control()` re-ran the device-rating check behind `if self.o.get("setpoint_entity")` - the flat key, which a roster leaves blank - so on a two-inverter site no inverter's `max_w` was graded against the device it is written to, and the skip was silent. `validate_unit_ranges()` grades each unit against its own ESPHome and runs unconditionally. test_peakguard.py's `read_option()` and `_schema_bound()` and test_inverter.py's `read_schema_max()` matched a STRIPPED line and took the first hit, so the nested per-inverter `max_w:` began outranking the flat one - silently, and correctly, because the two bounds are the same int(100,5000) today. A reader that is right by coincidence is this project's named failure mode. All three are anchored at exactly two spaces now; the file's two halves disambiguate `peak_cap_w` instead of first-match, and an ambiguous key raises rather than picking one. test_tariff.py's copy of the idiom went with them. THE AUDIT IS A CHECK, NOT A PROMISE test_inverter.py part 11 finds every config.yaml-reading function in the suite - transitively, because two of the readers CFG-04 had to change never name the file - EXECUTES each against a synthetic two-inverter config.yaml whose per-inverter numbers differ from its flat ones, and fails if any answers with the per-inverter value. The table is not maintained by hand: the signature decides, so the eleventh reader is named on its first run. config.yaml declares `inverters:` BEFORE `max_w:` on purpose and part 11 asserts that ordering, so the trap stays baited. SAFETY-28's `actuator_writers()` needed no change - it was already a structural, case-folding census - but until now there was no configuration in which two writers on one actuator could be WRITTEN DOWN. There is now, and it is refused. VERIFIED BY BREAKING IT Ten mutations run through tools/mutation_run.sh and observed red, listed in test_inverter.py part 12 with the check that bites each. Two survived the first run and the CHECKS were changed, not the table: the inheritance check had blank flat keys, so "inherited" and "not inherited" were the same empty string; and the `run_control()` check asserted a SOURCE LINE was present, which re-indenting it does not remove. Both are recorded in MUTATION.md's "the check's data cannot reach the failure it names" section, which now carries two more habits: assert on behaviour rather than on source text, and give a check whose failure mode is a hang a deadline. 19/19 green in the goodwe-addon-ci image. The one-inverter path is byte- identical: the whole existing suite runs unmodified against it. Version bumped to 0.6.0 - the Supervisor keys the built image by `version:`, so a schema change without a bump is a schema nobody reads. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-04 04:29:45 +02:00
adminandClaude Opus 5	7ef3d23245	SAFETY-31: measure circulating power, which nets to zero at the meter ... Inverter A charging at 3 kW while inverter B discharges at 3 kW nets ~0 W at P1. The site reads idle while both packs are cycled through two round-trip conversion losses continuously, for no benefit, and the wear is real. NOTHING EXISTING CAN SEE IT, AND THAT IS STRUCTURAL. Every guard in this add-on is a consumer of the NET figure at the grid connection: SAFETY-02's sign watchdog gates on abs(grid_w) > 300 and the gate never opens at a netted zero; the peak guard and the capacity tariff both bill grid exchange. Circulating power is precisely the component of per-inverter power that the sum destroys, so no threshold on any existing detector could reach it. WHAT ALLOC-01 ALREADY COVERED, AND IS NOT RE-IMPLEMENTED HERE. Its AC 7 shipped the sign-coherence gate (allocator.REFUSE_SIGN, graded by test_alloc.py part 6): an allocation whose shares carry two signs is REFUSED, both units named, no shares returned. That is the COMMAND half - the allocator can no longer command circulating power. This commit is the MEASUREMENT half: circulation the allocator NEVER COMMANDED. app/circulation.py the sensor and the trip main.py site_circulating_w, the evaluation, the claim, the alarm arbiter.py `circulation` classified SCOPE_SITE, with the argument store.py a flat, site-level durable latch mqtt.py sensor.goodwe_circulating_power config.yaml two options, two schema ranges, CFG-03 discipline THE SENSOR: sum(|Bi|) - |sum(Bi)|. Zero when the units pull the same way, 2*min(|Ba|,|Bb|) when they oppose. DERIVED FROM MEASURED PER-INVERTER POWER - Inverter.batt, register 0x0518 - and never from the allocation record. The cheap version would be simpler and worth nothing: ALLOC-01's gate already guarantees the record is sign-coherent, so a record-derived sensor reads zero BY CONSTRUCTION and can only confirm that the allocator agrees with itself, which is the third failure mode MUTATION.md names. What this catches is a unit ignoring or lagging its share, a stale share still being executed, a maintenance or SAFETY-25 pin holding one unit while the loop drives the other, or HW-01's power stage running its last instruction for 6 h 25 m with the comms dead and the allocation record impeccable throughout. batt became per-instance in DEV-02; before that this could not have been written. VERIFIED BY MAKING ONE UNIT IGNORE ITS SHARE, on the TEST-19 two-master rig: S = -2500 W shares a = -1250 W b = -1250 W <- record ok, ONE sign, sums MEASURED A = -1250 W B = +1000 W <- hardware sensor over the RECORD : 0 W sensor over MEASURED power : 2000 W -> trips at 190 s and the card's own scenario, A -3000 W against B +3000 W at zero house load: the meter reads +0 W, the sensor reads 6000 W, and the shipped SignWatchdog's predicate is FALSE on 30 of 30 cycles. WHAT "ACTED ON" MEANS - decided, and recorded in DECISIONS/. The trip files Claim.set("circulation", P_SAFETY, 0.0) on the SITE actuator: every inverter to 0 W, latched. HW-01 established that commanding a wedged inverter achieves nothing, so the remedy is not aimed at it. A circulating loop needs TWO participants and one of them is THIS CONTROLLER, faithfully driving the listening sibling into the one that stopped listening. Stopping (1) halves the loop, which needs no cooperation from the wedged unit, and (2) - the more important half - makes the residue VISIBLE at the meter instead of cancelled at it, where every ordinary guard can finally see it. What it cannot do is stop the wedged unit; the notification says so and names the isolator as the last actuator. SITE-scoped because the quantity is defined over the roster and is identically zero for any one unit - there is no fact of the matter about which of two opposing inverters is the offender, so filing it per-unit would invent an attribution and could park the only unit still listening. THE WINDOW IS FROM THE RIG, NOT A ROUND NUMBER (AC 3). 924 closed-loop runs in which NOTHING is faulty, over both families of legitimate opposition (7 reversals x 5 write staggers; 7 flap periods x 4 amplitudes), swept across the whole range the schema accepts for gain and slew_w. Worst CONTINUOUS legitimate opposition by threshold: 505.0 s at 100 W, 40.0 s at 250 W, 10.0 s at 300 W, 5.0 s at 400 W and above. The knee is 400 W and it is the schema floor - below it, ordinary operation holds the sensor over the line for minutes and no window inside the 900 s billing quarter could tell that from a fault. circulation_w 700 is 1.75x the knee, the headroom bought for inverter B's ramp and lag being PLACEHOLDERS until SPIKE-04 measures them. circulation_hold_s 75 clears three bounds: 15x the worst legitimate episode, 2.5x the firmware's own LINK_STALE_S veto, 12x inside the quarter. A momentary opposition while one unit slews through zero is LEGITIMATE - writes are serialised, so B's number lands up to a cycle after A's - and 0 of the 924 runs trip. THE ALARM SURVIVES AN HA RESTART (SAFETY-34). persistent_notification is in memory, which is exactly how the 2026-09-02 outage went unseen for 6 h 25 m with the detector correct throughout. The latch is persisted to /data as flat site-level keys and the notification is RE-RAISED on the first cycle after every start, through the same code path as a fresh trip - two paths would be two chances for the restart one to rot unnoticed. AT N=1 NOTHING CHANGES (AC 5). |B| - |B| is 0 for every reading including one nobody took, no claim is ever filed, the arbitration is byte-identical, and the status page says n/a rather than claiming to watch something that cannot happen. VERIFIED BY BREAKING IT (AC 4). 18 mutations, all RED on named checks, each on a freshly copied tree with no __pycache__ mounted :ro. M10 - the sensor rewritten to read self.allocation.shares - is the headline: it takes AC 2 red. Three mutations are +0 B, the risky delta, and are marked as such. One equivalent mutant (the max(0.0,...) guard) is ARGUED rather than claimed: searched over 700 000 rosters without a negative. One genuine SURVIVOR was found and closed - publish() turning an unknown into a published 0 W, the sensor's own None rule defeated one layer out. Full ledger in DECISIONS/. arbiter.CLAIM_SCOPE gains its ninth source, so test_peakguard.py's 10f and 10g tripwires and test_arbiter.py's scope table went red on the line the append was written. Updated deliberately, with the argument, as their own comments require. Full 19-file suite green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-04 01:56:23 +02:00
glenn schrooyenandClaude Opus 5	ab6fbe2f9e	SAFETY-25: record the owner's decision - option a, with alloc-01 as the revisit trigger ... The product owner answered SAFETY-25's §1 on 2026-09-02: OPTION A. The BMS cut-out is the DELIBERATE and only backstop for demand-driven discharge on the grid-following loop, and Option B - a loop-side reserve floor - is DEFERRED rather than rejected. Option A is the shipped behaviour, so this is a recording, not a change. `app/` is touched in exactly two places and both are comments that claimed the question was still open (freeze.py's finding, peakguard.py's point 2). No setpoint, no claim, no option, no default moved. The 17-suite run is green on the same numbers as before. WHY DEFERRING IS THE SAFE DIRECTION. Option B's proof - bms_soc_floor < loop_soc_floor <= peak_soc_floor, run through the real arbiter in test_peakguard.py part 10d - has an unstated premise: the reserve predicate and discharge_permitted() read the SAME state of charge. With two packs they read different numbers. The reserve binds on the emptier pack and files hi = 0; the peak guard, reading the other pack or an average, files lo = excess > 0; lo > hi is arbiter clause 3 and the answer is 0 W - the battery parked in the billed quarter, which is the failure the memo itself marks fatal. And no config validator can catch it: it is a runtime divergence between two readings, not a config ordering, so CFG-01's shape of check passes on the exact tree that parks the battery. Option A's cost is energy; Option B's cost built too early is the one quarter of the month that sets the bill. THE REVISIT TRIGGER IS ALLOC-01, recorded in §0c. Under ARCH-01's host-side allocator the two claims stop sharing a list: the loop floor becomes a per-inverter `hi` consumed as an INTERVAL at stage A, while the peak floor stays a site `lo` at stage B. Different claim lists, different stages, structurally unable to cross - a stronger argument than the ordering rule, because it makes the crossing unreachable rather than harmless. That is the shape in which Option B becomes safe to build. WHAT HAS TO BE RE-EARNED AT N=2 is stated plainly in §0d rather than left for someone to discover. SAFETY-27 now names five floors across two packs, so "the SoC" stops being a scalar the config can bound. And part 10f - the pin that made SAFETY-25 mergeable - CANNOT EXPRESS TWO PACKS: its dynamic half is a scalar 0-100 % SoC sweep against a single-series capture, and a two-pack exposure lives in the DIFFERENCE between two readings, which that sweep visits at no resolution. Its static half, the AST scan pinning the eight claim sources, still bites at N=2; the dynamic half goes silent. Merging a two-pack reserve on 10f's current green would be merging on a check that cannot see the failure. The options analysis is kept intact on purpose - §1-§7 stand exactly as written, including §5's "(recommended)" on Option B and §6's recommendation, with a new §0 saying what was decided and §6 marked as answered. A memo that recorded the verdict and deleted the reasoning is the failure this DECISIONS/ directory exists to prevent. Part 10e's check moved with the memo: it used to pin the honest "Status: OPEN" line and now pins that the memo names the option, the date and the trigger AND still carries both options and the recommendation. The tripwire itself stays - a ninth claim source in Controller.cycle() still takes 10f red on the line it is written, and "deferred" is precisely the state in which someone builds Option B by accident. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-02 00:46:54 +02:00
glenn schrooyenandClaude Opus 5	e498dd4c1c	SAFETY-25: pin the claim-source set, so the tripwire is one ... The durability claim this PR shipped was FALSE, and the reviewer of #31 disproved it by building the fix. Part 10 said, in four committed places, that it "goes RED the day a loop-side floor is built, so the exposure cannot change size under a green suite". The reviewer implemented the memo's own recommended Option B in main.py - a `Claim.limit("reserve", P_LOOP, hi=0.0)` filed under a `loop_soc_floor` - and the ENTIRE SUITE STAYED GREEN. Part 10 green. Mutation 13 went on printing "NOTHING PREVENTS IT, ON PURPOSE" and the same 21 % -> 10.0 %, on a tree where something DID prevent it. Pushed to an absurd always-binding 95 % reserve it was caught only by SAFETY-24's pre-existing part 7 wiring checks; part 10 was still green. THE CAUSE IS STRUCTURAL, not a missing assertion. `replay_loop()` hand-builds main.py's claim list as a literal `[supervised, loop, peakguard.claim(...)]`, so it is blind to any claim main.py ADDS - which is exactly where AC 2 would be built. That is this repository's named failure mode: a check that observed something other than what it claimed to observe, shipped as a guarantee inside the document that recommends the change. THE FIX IS 10f: THE CLAIM-SOURCE SET, PINNED, two ways because the two fail differently. * STATICALLY, over `Controller.cycle()`'s own AST. Every `claims.append(...)` in it must be one the scan can read - an unreadable append FAILS rather than counting as nothing, which is how a scan like this goes quietly vacuous - and the sources it can file must be exactly {device, supervised, failsafe, safety, peak, arbitrage, maintenance, loop}. A ninth takes part 10 red on the line it is written, in every configuration, whether or not any fixture here reaches the state that files it. * DYNAMICALLY, through REAL `Controller.cycle()`s with main.py's OWN `resolve` spied - not a list this file built and hoped matched - swept over the WHOLE 0..100 % SoC range in the two states 10a-10c replay. Idle: exactly {device, supervised, loop}. Floor-limited: exactly {device, supervised, loop, peak}. A claim conditioned on a low pack, which is the shape a loop-side floor has, cannot hide from a sweep that visits 0 %. And the fold is checked rather than assumed: main.py's two P_SAFETY rating limits are both symmetric LIMITs, so replay_loop() modelling them as one `supervised` claim at the tighter bound is exact. MEASURED AGAINST THE COUNTEREXAMPLE. Reproduced first on the unfixed tree (green, as reported). On this tree the reviewer's Option B at its recommended default takes part 10 RED on 3 checks, and the 95 % variant on 6. Nine mutations were run in all, each against a freshly copied tree with no `__pycache__` present, mounted `:ro`; all nine red, no survivors, no `+0 B` delta. MUTATION.md records why a second round was needed: the first round's mutations were all aimed at DISARMING the guard, while the claim part 10 actually made was about the guard being FIXED. The four false sentences are replaced with what is now true, and each says WHICH half catches WHICH shape - 10f for an arbiter claim (Options B and C), 10a-10c for a clamp inside control.compute() or the guard (Option D), which the replay drives directly. AC 2 IS STILL OPEN AND NOTHING HERE BUILDS IT. The loop-side floor was a test mutant, reverted before commit. The memo still says "Status: OPEN. This is a memo, not a decision." Also, non-blocking, from the same review: the NOT READY banner had inherited the new scope sentence and become a ~550-character paragraph that the row three lines below repeated verbatim. A checks() row may now carry an optional short `banner` form; the floor-limited row does, and `status_payload()` prefers it. THE ROW IS UNCHANGED - shortening that would have been weakening AC 3 - and rows without the key are unaffected. Graded, and mutated: dropping the short form goes red. Merged origin/release/1.0 first (CI-02), keeping both tickets' CHANGELOG entries. Full suite green: 17/17 in goodwe-addon-ci (test_ci_gate.py needs `git`, which CI-02 added to .gitea/ci/Dockerfile but the local image lacks; run with it installed and it passes). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 05:04:22 +02:00
adminandClaude Opus 5	182102eeaf	SAFETY-25: say what peak_soc_floor bounds, and measure what it does not ... peak_soc_floor reads like a pack-wide reserve and is not one. The grid-following loop has no SoC guard of any kind, so on a sustained-load evening it discharges straight past that number and keeps going until the pack's own BMS cut-out stops it. The gap has now been written down four times without being filed - SAFETY-18's finding (freeze.py:18), SAFETY-24's module note, its PR body, and its honestly-uncaught 13th mutation - and never once measured. It is measured here, on the committed 2026-08-20 capture, driving the SHIPPED control.compute(), peakguard.decide(), peakguard.claim() and the real arbiter.resolve() in main.py's order: 19:00-22:00 UTC, 830 W mean, minimum 701 W, zero export in the window reference pack (300 Ah x 51.2 V x DoD 90) started at 21 %, one point above peak_soc_floor ends at 10.0 % - the bms_soc_floor cut-out 1525 Wh delivered by the LOOP over 587 cycles 549 cycles below peak_soc_floor, 343 of them still discharging 0 cycles on which the peak guard filed any floor at all AND IT IS A BEHAVIOUR, NOT A CONFIG VALUE. The same evening ends at 9.9715 % at peak_soc_floor = 5, 11, 20 and 60 - the shipped value and both ends of the schema range - identical to four decimal places. The option an operator would reach for cannot move the number by any amount at all. On the same day's high-load block the two states coexist: 49 cycles reporting PEAK GUARD FLOOR-LIMITED and, on all 49 of them, the arbiter simultaneously granting the loop up to 2000 W of discharge. WHY SAFETY-24 COULD NOT CLOSE IT. The peak guard files a `lo` limit - a LOWER bound on the setpoint. That asymmetry is exactly what makes it trustworthy: a reviewer proved across 19,800 combinations that it can never lower a target, cap a discharge or contradict the arbiter. The same property makes it structurally incapable of stopping a discharge the loop itself wants. A floor on the guard cannot become a floor on the pack by being raised, and the sweep above is that sentence measured. WHAT THIS COMMIT CHANGES IS THE HONESTY, on the four surfaces an operator actually reads. That half is required whichever way the open question is answered, and it is the real misstatement on the live system today: * config.yaml, beside the option itself - it BOUNDS THE PEAK GUARD ONLY and is NOT A PACK-WIDE RESERVE, with the replayed evening and the sweep; * DOCS.md, in the options table and in a new section carrying the figures; * the STATUS-PAGE ROW for a floor-limited guard. This is the one line a human reads at the moment the guard stops discharging, and read alone it says "the battery is being held at peak_soc_floor" - which the replay shows is false in every cycle that row is rendered; * the PERSISTENT NOTIFICATION, which outlives the page. It now names what has stopped (the guard buying a lower bill) and what has not (the pack being spent). peakguard.py and freeze.py carry the measurement beside the findings they already recorded, so the next reader does not have to take the caveat on trust. THE PRODUCT DECISION IS NOT TAKEN HERE, and must not be. Whether the loop gets a reserve floor of its own decides whether this house's battery may discharge to the BMS floor on a heavy evening; that moves real energy and it is the owner's call. DECISIONS/SAFETY-25-loop-soc-floor.md is the memo AC 1 asks for: the options, what each costs, what each protects, weighed against MAINT-01 (a pack repeatedly at the BMS floor is the SoC-drift condition the maintenance cycle exists to correct, and an over-tight reserve fights it from the other side) and against the fact that this would be the FIFTH SoC key - OPT-04's arbitrage_soc_floor fired SAFETY-24's "revisit if a third floor appears" trigger unremarked, so SAFETY-27's naming decision should land first. It carries a recommendation and says plainly that it is not a decision. It also records a trap found while writing it, and now CHECKED through the real arbiter rather than described: the obvious shape of a loop-side floor is a `hi` limit at P_LOOP, and filed while the peak guard is asking for a positive floor that is `lo > hi` - which arbiter.py resolves to a CONTRADICTION at 0 W, the battery PARKED in the one quarter of the month that sets the bill. It is the same crossing-limits hazard shaping_suspended() already exists to avoid. The ordering `bms_soc_floor < loop_soc_floor <= peak_soc_floor` removes it provably, because wherever the reserve binds the guard is already floor-limited and files lo = 0; both halves are run in part 10d. test_peakguard.py part 10 is a TRIPWIRE, not a guarantee. It records a defect and goes RED the day somebody builds a loop-side floor, so the exposure cannot change size under a green suite and closing it has to be deliberate. Part 11's mutation 13 stays honestly NOT CAUGHT - nothing prevents the loop discharging past this floor - but it now reports a number instead of a sentence. Verified: 16/16 suites green in the CI image. Eight mutations, each against a tree copied fresh with __pycache__ excluded and mounted :ro, so no .pyc existed to go stale (MUTATION.md's structural immunity, the same one it records for CI); byte deltas +61, -8, -465, -430, -1088, -46, file deleted, and -95; none is +0 B. All eight go red on the named check: M1 peakguard.claim() also files hi=floor_w -> 7 red, incl. 10c M2 control.compute() gain forced to 0 -> 6 red, incl. 10a/10b M3 scope sentence removed from the status row -> 10e red M4 scope sentence removed from the notification -> 10e red M5 scope paragraph removed from config.yaml -> 10e red M6 scope bullet weakened in DOCS.md -> 10e red M7 the decision memo deleted -> 10e red M8 arbiter clamps crossing limits instead of reporting a contradiction -> 5 red, incl. 10d AC 2 is left explicitly OPEN, pending the owner's answer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 03:46:43 +02:00