SAFETY-30: grade each inverter against its own power, and the site's total against the meter #46

Merged

admin merged 3 commits from SAFETY-30 into release/1.0 2026-09-04 12:28:44 +02:00

Conversation 1 Commits 3 Files Changed 14

+2279 -89

3 Commits

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
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