7 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	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
glenn schrooyenandClaude Opus 5	753f700539	DEV-02: merge release/1.0, and close the two review blockers ... PR #43 was rejected on two findings and had gone unmergeable behind SAFETY-28 and the ALLOC-01 fix. This is the merge commit; the conflict resolution and both fixes are below, because a merge that also changes behaviour has to say so. THE MERGE, AND WHAT IT COST =========================== Two conflicts in main.py, both where SAFETY-28 and this card touched the same method: * `write_setpoint()` split into a site entry point plus a per-unit `_write_unit()` here, while SAFETY-28 put its record gate in the old single-unit body. `write_refusal()` now takes the INVERTER it is about. Asking it with `self.unit` - as release/1.0 does - would authorise A's share on B's wire, and would also trip test_inverter.py part 1's AST scan, which goes red on any read of a Controller N=1 view inside Controller. * the SAFETY-28 gate sits above the clamp and below the non-finite coercion, exactly where release/1.0 put it, and is now asked about `inv`. Fallout the merge produced in the checks, re-aimed rather than relaxed: * every fixture that calls `write_setpoint()` DIRECTLY - the clamp probe, the hung-heartbeat experiment and its serialised counterfactual, the split deadline probe - now arms a real allocation record first. test_inverter.py grows an `arm()` built through the shipped `resolve()`, the same shape test_clamp.py's is: the per-unit envelopes are filed as real `supervised` claims and the site target is their sum, so the water-fill has exactly one answer and the fixture cannot quietly become its own allocator. * test_clamp.py's two-unit failsafe fixture assigned `c.units`, which DEV-02 made a derived property with no setter. It appends a real `Inverter`. BLOCKER 1 - AC 4's ARBITER-BOUND EVIDENCE WAS VACUOUS ===================================================== test_peakguard.py claimed "each unit's `supervised` bound is ITS OWN `max_w` - give inverter B a different rating and the claim filed on inverter B moves with it", and compared B's bound against `_b2.max_w`. `second_inverter()` DEFAULTED B's rating to `LIVE_MAX_W`, which is A's. IT COMPARED (-5000, 5000) AGAINST (-5000, 5000): a number against itself, unable to observe the failure it named. Reproduced: filing the per-unit `device`/`supervised` claims from `self.inverters[0]`'s numbers while leaving `actuator=self.actuator_of(..., inv)` alone left ALL 19 FILES GREEN. At a roster of two with A=5000/B=3000 that makes inverter B's planned envelope (-5000, 5000) instead of (-3000, 3000) - a 2000 W over-command the arbiter believes is supervised. It is a DIFFERENT defect from the actuator variant the static routing pin catches, and only the actuator variant was in the mutation table. * `second_inverter()` gives B 3000 W - a hypothesis, marked as one - for every fixture in the file, so no check there can compare B against A by accident. * the claim is asserted against LITERAL numbers rather than against an expression that can read the same object twice, for `supervised` AND for `device` (whose `dev` had the same defect), plus the envelope the ARBITER RESOLVED for B - a claim filed right and resolved wrong is the same defect one layer down. * a PRECONDITION check fails if the two ratings are ever made equal again. * the BOUND mutation is in the table, beside the actuator one, and was observed RED (3 checks in test_peakguard.py) via tools/mutation_run.sh. ⚠️ THIRD INSTANCE THIS SESSION of a check whose DATA cannot reach the failure it names - ARB-03's call-site scan saw 3 of 8 appends, ALLOC-01's replay generator saw 0 escapes where a widened one saw 39,991. MUTATION.md gains a section for it beside the stale-bytecode and masking ones, and the rule is written at the line: ANY CHECK ASSERTING "X DIFFERS FROM Y" MUST BE RUN ONCE WITH X AND Y ACTUALLY MADE DIFFERENT. BLOCKER 2 - THE LATCH WAS SILENTLY DISARMED BY THE ROLLBACK ROUND TRIP ====================================================================== store.py's rule 2 keeps the flat keys "so a rollback still finds its latch". The operator path that rule contemplates is a ROUND TRIP, and this card lost the latch on it: 1. install migrates -> schema_version=1, unit/inverter-a/... = False 2. operator DOWNGRADES; SAFETY-02 trips inside the downgrade window and the old add-on writes only the flat `sign_tripped: true` 3. operator upgrades again -> `rep.ran` is False, so `_grade_store_migration()` returned early, and `Inverter.__init__` read the namespaced key: False Observed: the controller came up with `sign_wd.tripped = False` while /data/state.json said `sign_tripped: true`. That is store.py's own header sentence - "the file still says sign_tripped: true, the banner is green, and the controller resumes driving the wrong way" - rebuilt by the version marker. A firmware version change with a rollback path was performed on this site on 2026-09-02, so this is not hypothetical. Three changes, each graded by a mutation observed RED: * THE OPERATOR'S CLEAR CLEARS BOTH SPELLINGS. That is what removes the "re-arm forever" objection the `rep.ran` gate existed to answer: with the fossil cleared, `flat True + namespaced False` is unambiguously a downgrade-window latch. * A TRIP MIRRORS THE FLAT PAIR. Rule 2 only ever covered the latch present AT MIGRATION TIME - nothing flat was written for a trip taken afterwards, so an operator who downgraded found `sign_tripped: false` and came up DRIVING. store.py claimed the staleness could only fail toward a SPURIOUS latch. It could not; that sentence is corrected rather than left standing. * THE GUARD RUNS ON EVERY START, and asks the STORE - not the roster - whether anything namespaced is latched. A mirrored trip on B must not re-arm a healthy A, and the store is the right place to ask because it holds every `unit/*/sign_tripped` this install has written, including one belonging to a unit that is not in today's roster. Graded by the three-step scenario itself, run end to end in test_inverter.py part 2, with all three preconditions asserted - including that the catching start did NOT migrate anything, which is what used to skip the guard. Part 2's idempotence check now PRESSES the button instead of hand-writing the store, because the state it used to construct is not one the shipped clear path can produce. Part 3 grades the mirror and the clear on a real roster of two. test_watchdog.py's "the flat key is NOT written" assertion is re-aimed rather than deleted: its argument was right about the READ and wrong about the WRITE. Nothing at runtime reads that key, and the one thing that does ignores it whenever any namespaced latch is set - which a sibling's trip always leaves. What its absence actually cost was the rollback. HANDOVER.md and DOCS.md said the flat key "is never read again", which was the instruction an operator clearing a trip by hand would follow. Both corrected: it is a maintained rollback view, it IS read on every start, and clearing a trip by hand means clearing both spellings. MUTATIONS THIS ROUND, each applied on a purged tree via tools/mutation_run.sh and observed RED: * per-unit `device`/`supervised` BOUNDS from `self.inverters[0]`, actuator left correct -> test_peakguard.py 10g * `_grade_store_migration()` gated on `rep.ran` -> test_inverter.py part 2 * the operator's clear leaving the flat keys set -> test_inverter.py part 2/3 * a trip not mirroring the flat pair -> test_inverter.py part 3 * the guard asking only `self.inverters[0]` -> test_inverter.py part 3 19/19 files green on the merged tree. No hardware was touched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-03 23:37:23 +02:00
glenn schrooyenandClaude Opus 5	e941bf7f62	DEV-02: zero every unit's target when the operator stops, not just the site's ... A hazard THIS CARD CREATED, found by re-reading the operator paths rather than by a failing check - so a check now exists for it. Before DEV-02 the heartbeat re-emitted `self.target`, so the stop button zeroing that one scalar was enough: the next refresh carried the zero. The heartbeat now re-emits `inv.target` - it has to, or it would put the SITE number on every inverter, which is the ARCH-01 broadcast fault arriving once every `heartbeat_s` on a path with no allocator in it. So a stop that zeroed only `self.target` left each unit's LAST SHARE standing. No cycle has run yet at that moment, so nothing else would have cleared it, and the very next heartbeat - up to `heartbeat_s` later - would put it back on the wire. The operator presses stop, watches the inverter go to zero, and sees it resume seconds later. `command_site_zero()` moves both together and carries the reason. It is one method rather than two lines at three call sites precisely because the two lines have to stay together: shutdown(), the stop button and maint_abort all mean the same thing, and 0 W is the one value that may legitimately be written site-wide. test_inverter.py part 6 presses stop with 995/995 standing and then runs the SHIPPED `send_heartbeats()` before any cycle, which is the racing refresh. The mutation that zeroes the site target alone takes it red. 19 files green. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-02 14:58:54 +02:00
glenn schrooyenandClaude Opus 5	e306c74cb8	DEV-02: per-instance inverter objects, so nothing is graded against a sibling ... Every piece of per-device state in the Controller was a scalar, and several of them are safety inputs. app/inverter.py introduces an `Inverter` that owns its entities, its rating, its device range, its SignWatchdog, its last_write and its last_beat, under store keys namespaced by unit name. The Controller holds a list of them and keeps only what is genuinely site-level: the P1 reading, the site integrator, and the tariff quarter. WHAT THE SCALARS WERE SILENTLY ASSERTING dev_min/dev_max one pair, read from one setpoint_entity. A second inverter's rating was NEVER READ AT ALL, so its clamp, its freeze rail and the peak guard's achievable_w were the first one's numbers. soc one reading into the maintenance FSM, SAFETY-24's pack floor and arbitrage's bounds. An average lets the emptier pack be driven below its own floor. sign_wd ONE SignWatchdog, whose own docstring says "one instance per actuator", latched under FLAT store keys - so a trip caused by B latched A across restarts and one operator press cleared both. last_beat one deadline and one serialised hass.call(), so a hung write to A ate B's 30 s layer-1 budget. actual_w BECAME SITE LEVEL WHILE THE READINGS BECAME PER-INSTANCE, and those are opposite directions on purpose. compute()'s anti-windup test is `abs(prev_w - actual_w) > saturation_w` with prev_w the SITE target, so feeding it one inverter's power compares a site number against a unit number, trips the saturation freeze permanently and leaves a standing grid error. Measured on admin/goodwe's two-master rig (tools/alloc_sim.py --splits, 2 kW load, 40 cycles), worst |delta| between splits at the meter: gain one unit's power the site sum 0.2 510 W 0 W 0.4 250 W 0 W 0.6 50 W 0 W That was ALLOC-01's disclosed finding; test_alloc.py part 8 kept its stimulus and now grades the other row. THE STORE MIGRATION IS GRADED, NOT MERELY PERFORMED. sign_tripped/sign_reason move to unit/<name>/... once, verified by READING BACK what was written, and the version marker is set only when nothing that carried state was lost. The flat keys stay in the file so a rollback still finds its latch. And __init__ compares the pre-migration flat latch against what unit A actually came up with: if the latch did not survive it is RE-ARMED from the legacy value and shouted about. A latch that silently fails to migrate is a disarmed safety guard on an install whose state file says it is protected - which is strictly worse than never persisting it, because now there is evidence saying it is fine. test_inverter.py part 2 breaks the migration and watches the guard fire. HEARTBEATS ARE INDEPENDENT AND THE BUDGET IS DERIVED. Each inverter owns its deadline, the refreshes go out concurrently, and each write is bounded by WRITE_BUDGET_S = 4 s. The inequality is graded rather than asserted: 4 + heartbeat_s's schema maximum of 25 < 30, validate.FIRMWARE_INGEST_VETO_S. Verified by injecting a transport that accepts and never answers. live_units() ANSWERS HONESTLY. A unit whose every write has been rejected for a whole layer-1 window is not commandable; the allocator drops it, the survivors carry its share, the action log names it, and the dropped unit is commanded 0 W rather than left standing on its last share. A roster entry with NO setpoint_entity is deliberately not handled there - that is a configuration that cannot be delivered, and it reaches main.py's refusal branch, which is how that branch keeps a live trigger after this card removed its old one. AT N=1 NOTHING MOVES. The removed scalars survive as read/write properties of the sole inverter, so every existing replay runs unmodified - and they REFUSE at N>=2 rather than answering for the first inverter, which is the tripwire on a consumer that was never made per-instance. EVIDENCE. 19 files green. test_inverter.py is new (82 checks). Eighteen mutations were applied to the shipped modules on a purged tree via tools/mutation_run.sh and each was observed RED. Two of them SURVIVED first time and the checks were changed rather than the table: the serialised dispatch and the shared last_beat both passed while part 6 gathered its own writes and computed its own `due` list. send_heartbeats() was extracted from run_control() so the shipped dispatch is reachable by a check at all. INVERTER B STILL DOES NOT EXIST. build_roster() returns exactly one inverter from the flat options and is the one function CFG-04 changes; every two-unit figure here is architecture, and the second rating in the checks is marked a hypothesis. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-02 14:50:43 +02:00