9 Commits

Include renames

Author	SHA1	Message	Date
glenn schrooyenandClaude Opus 5	65cddf35f1	MAINT-05 fix round: grade the migration against the ROSTER, not against the name it was handed ... REJECTED because a survivor undoes AC 5, and it survived for the recurring reason: two fixture values that must be distinguishable were EQUAL. THE SURVIVOR. app/main.py:282 mutated from `self.inverters[0].name` to `UNIT_A` left the full 19-file suite green. `inverter.UNIT_A == "inverter-a"`, and every two-pack fixture in test_maintenance.py named its first roster entry "inverter-a" - so the two expressions were the same string in every check that existed. main.py's own comment made the distinction load-bearing and nothing in the repository could see whether that comment was true. THE FAILURE IS REAL. `build_roster()` names a declared roster's entries from the config and numbers a nameless one POSITIONALLY (`inverter-1`), so "inverter-a" is not even the fallback. On ["garage","shed"] with a flat last_completed of 2026-08-07 the mutant migrates into unit/inverter-a/, pack 0 reads back None, and both packs come up believing they have never been recalibrated. AND IT FAILED SILENTLY, which was the worse half: `_verify_moves()` read back the keys it had just WRITTEN, under the namespace it had just been HANDED, was satisfied, and MAINT_SCHEMA_KEY was stamped - so the next start skipped the migration too. A postcondition that reads back the namespace it was handed cannot detect being handed the wrong one. WHAT CHANGED 1. THE POSTCONDITION IS GRADED AGAINST THE ROSTER. `_verify_moves()` takes the names the MACHINES read and reports a namespace that is not among them as `misdirected` - a new, differently-named failure from `lost`: * `lost` is "the store took the write and dropped it" - a storage fault, with a harmless-default case (a dropped `last_completed: None` loses nothing, because absent and never-recalibrated are the same statement); * `misdirected` is "the store did exactly as it was told, by a caller that was wrong". There is no harmless-default version of it - a write nobody reads is not information whatever its value - so it fails `ok` alone. `ok` gates the marker, so a misdirected migration is NOT stamped and the next start re-runs it. Asymmetric on purpose: a re-run is recoverable (rule 1 makes it a no-op, rule 2 left the flat keys to recover from), a silent skip is not. Part 9b MEASURES the recovery rather than asserting it. 2. `migrate_maint_keys()` TAKES THE ROSTER IN PLACE OF AN `n_units` COUNT. The count was `len(self.inverters)` at the only call site, so the roster carries it, and a count beside the names is a second opinion about how many packs there are. 3. THE FIXTURES CAN NOW REACH THE FAILURE THEY NAME. Parts 9 and 11 run on ["garage","shed"], each behind a PRECONDITION check that the first name is not UNIT_A - so an edit that makes them equal again goes red instead of making the claims vacuous. Part 11's fixture date is relative to `now`, not a literal, so "history preserved" and "history lost" cannot converge as the file ages past `interval_days`. MUTATION LEDGER - all red, purged tree, none at +0 B, full detail on the PR: M1 main.py inverters[0].name -> UNIT_A -16 B 4 checks red M2 store.py drop `roster=names` from _verify_moves -14 B 5 checks red M3 store.py drop the misdirected.append -37 B 5 checks red M4 store.py ok: drop `and not self.misdirected` -25 B 3 checks red M5 fixture garage -> inverter-a (the trap itself) +4 B 5 checks red M6 store.py parts[1] -> parts[-1] +1 B 1 check red FOUND AND NOT FIXED - `migrate_unit_keys()` HAS THE SAME HOLE AND IT IS A LATCH. It runs BEFORE `build_roster()` (each Inverter restores its latch in its constructor), so it is handed the constant UNIT_A with no roster to grade against. On a declared roster a pre-DEV-02 `sign_tripped: true` lands under unit/inverter-a/sign_tripped, which no unit reads - and `_grade_store_migration()`, whose whole job is to re-arm exactly this, is DEFEATED BY THE KEY THE DEFECT WROTE: its "is anything namespaced latched" test is satisfied by the misdirected value itself. Measured, with the flat-config counterfactual, and pinned as a running check (test_maintenance.py part 13) whose assertions state the WRONG behaviour on purpose. It wants its own card: the remedy is in inverter.py and SAFETY-02's semantics, and a silent expansion into a safety latch is how a rejected PR becomes a broken one. Suite: 19/19 PASS, purged tree, bind-mounted :ro in goodwe-addon-ci. No hardware was touched; every fixture here is SIMULATED and pack B's 3000 W remains a marked hypothesis. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-04 16:18:34 +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	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	acbdf41248	TEST-13: grade record_block()'s policy argument, and the two import spellings SAFETY-20's check could not see ... Two survivors from TARIFF-01's review, closed in test_tariff.py only. app/ is untouched and no shipped behaviour changes. Two further items on the card were already closed in shipped code and are struck rather than re-implemented. ITEM 1 - the per-phase reduction's PLUMBING was unobservable. Mutating PeakStore.record_block()'s `billed_w(block, policy)` to `billed_w(block, POLICY_NET)` (+4 B) leaves all 17 suites green. Measured three times now: by TARIFF-01's reviewer, re-run through TEST-15's purge harness this session, and re-run again here on a clean uncontended tree. The product code is correct - tariff.py:363 really is `def record_block(self, block, policy: str = POLICY_NET)` and it really does forward the argument. What was missing is any check that could tell that apart from a hardcoded call, and the reason is the third instance of one shape: A STIMULUS EVALUATED WHERE THE QUANTITY IT GRADES IS DEGENERATE, after WITNESS-02's span normalisation and TARIFF-01's own DST window. billed_w() short-circuits to block.offtake_avg_w whenever per_phase_offtake_avg_w is absent. Every block reaching a store anywhere in the suite was single-phase or built as _CB(..., None) - so NET, SUM and MAX collapsed onto one number and the argument could not be observed at the call site. Section 7 grades the FUNCTION on an unbalanced fixture and says nothing about its CALLER. So section 7's own (3000, 500, -200) W block - whose three reductions are 3300 / 3500 / 3000 W, asserted distinct three lines above - is now round-tripped THROUGH the store under each policy and read back from both tables (peak() and recompute_month(), so both writes in that single transaction are graded). record_block() with no policy is checked to bank the NET figure. An anti-degeneracy pin is stated over the three BANKED numbers, not over vals, because it is the banked ones this triple is made of. Direction, which is why this is worth plumbing-testing: NET is the SMALLEST of the three here, because the exporting phase nets off. A store that quietly billed NET while asked for MAX would UNDER-record the month's peak, and an under-recorded peak is maximum headroom for SAFETY-07 - the same under-guarding direction as the getattr(..., 0.0) default SAFETY-07 already removed from project(). ITEM 2 - the SAFETY-20 import grader claimed more than it checked. It collected `m.module for m in walk(tree) if isinstance(m, ImportFrom)` and matched a literal list of six spellings. That is blind to two of Python's three import forms: * `from . import arbiter as _ab` is an ImportFrom whose .module is None - the dots are in .level and the module name is in .names - so it collected "" and matched nothing; * `import app.arbiter` is an ast.Import node the walk filtered out entirely. Both were added to app/tariff.py and the shipped suite stayed GREEN, with the _names half not firing either (an alias import creates no Name node). Low severity: any USE of either alias still produces an Attribute the _names half catches. But the printed sentence "it imports nothing from arbiter, clamp or control" was false for two forms out of three, and a check that overclaims is worse than one that claims less, because the next reader stops looking. _imported_modules() now walks Import as well as ImportFrom and joins `from . import X` onto its base. _forbidden_imports() matches per dotted SEGMENT, not by substring: `app.arbiter` must not hide behind a package prefix, and `clamps` / `arbiters` / `controller` must not be falsely flagged - `controller` is not hypothetical, this package is goodwe_controller. Five evasion spellings and eight innocent ones grade the grader itself, and both the name half and the import half are shown non-vacuous against main.py, which carries all three import forms and really does import all three modules. ITEMS 3 AND 4 - ALREADY CLOSED. STRUCK, NOT RE-IMPLEMENTED. Item 3: app/tariff.py:266-267 is `def is_observed(self): return self.state == OBSERVED`, already false for NO_RECORD. Nothing to do. Item 4: app/tariff.py:672-680 reads `held = max(averager.held_net_w, 0.0)` with NO getattr default, and carries a comment naming TEST-13 item 4. Fixed by SAFETY-07 in 616b62d; held_net_w is a documented public property on QuarterAverager (p1.py:290), so a rename raises AttributeError on the first cycle instead of crediting 0 W held. A projection crediting 0 W held reads LOW, which is the under-guarding direction for SAFETY-07's floor. Restoring a default would re-open a money guard. And the recorded NON-finding stays a non-finding: removing clear_partial() is still green and that is a PASS. quarter_start is the PRIMARY KEY and the upsert carries `ON CONFLICT ... WHERE excluded.offtake_avg_w > quarter_blocks.offtake_avg_w`, so a replay is a structural no-op. That demonstrates TARIFF-01's "double counting is answered structurally, not by care" claim rather than contradicting it. EVIDENCE - all through tools/mutation_run.sh (recursive __pycache__ purge, python3 -B, tree re-read from disk, mutated line grepped off disk, byte delta recorded), in the goodwe-addon-ci image against a :ro mount. baseline, 17 suites, before any edit ............................ 17 PASS baseline, 17 suites, final tree ................................. 17 PASS A1 billed_w(block, policy) -> billed_w(block, POLICY_NET) +4 B 5 RED the 'sum' and 'max' round-trips, both tiers, and the distinctness pin A2 billed_w(block, policy) -> billed_w(block, POLICY_MAX) +4 B 6 RED the 'net' and 'sum' round-trips, both tiers, the default, and the pin B1 add `from . import arbiter as _ab` to app/tariff.py +29 B 1 RED the import sentence. SHIPPED suite on the same tree: GREEN - the hole. B2 add `import app.arbiter` to app/tariff.py +19 B 1 RED the import sentence. SHIPPED suite on the same tree: GREEN - the hole. B3 add `from .control import compute` (the form the OLD grader DID catch, as a regression control) 1 RED C1 delete the ast.Import branch from _imported_modules() 1 RED names the two spellings it MISSED, so the grader-grader is live C2 segment match -> substring match (`any(f in m for f in ...)`) 1 RED names clamps / arbiters / controller as falsely flagged CONTROL, and the point of the whole ticket: A1 graded by the SHIPPED test_tariff.py is green, and A1 graded by all 17 SHIPPED suites on a clean uncontended run is 17 PASS, rc=0. The survivor is real and it is now closed. ONE THING THE REVIEWER SHOULD KNOW. During the first (contended - two docker containers at once) run of that 17-suite survivor sweep, test_peakguard.py reported FAIL once. It has passed 8 times since on the identical tree, including three concurrent runs and one clean uncontended full sweep, and its tail was lost to a grep so I cannot say which check it was. I believe it is a timing-sensitive check under CPU contention and NOT related to this change - this commit touches no product code and no peakguard fixture - but I could not reproduce it, so I am recording it rather than asserting it away. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 08:40:09 +02:00
glenn schrooyenandClaude Opus 5	20f9f4969d	TEST-16: pin the two one-sided arbitrage rungs, and un-mask them from each other ... SAFETY-26's AC4 gave the same tolerance mutation to every price and quantity boundary in arbitrage.py and static_tariff.py. Everything in arbitrage.py went red - `price < 0`, `soc <= floor_pct`, `soc >= ceiling_pct` are each red under +/-5. Two survived, both in static_tariff.py, and this card closes them. D `spread == 0.0` (:912) weakened to `spread <= 0.001` SURVIVED at +2 B. F `len(firm) < 2` (:901) weakened to `len(firm) < 1` SURVIVED at +0 B - the delta MUTATION.md names as the risky one. THE DEFECT IS NOT EITHER ROW, IT IS THE INTERACTION. D and F MASK EACH OTHER. A single firm hour also has a spread of 0.0, so with F weakened the flat rung refuses the stimulus anyway; with D weakened the small-but-real spread is still refused, only for a lie. Each rung's failure is absorbed by the other, so BOTH can be weakened together and a suite grading `kind == "refused"` reports nothing. That is structurally invisible to single-mutation testing, which is how this pair came through four rounds of review on TARIFF-03 and FCST-03 - and it is the arrangement in which the next edit to either rung opens a real hole with nothing to report it. D is not cosmetic either. With the tolerance in place a series priced 0.20000 / 0.20050 - a REAL 0.0005 EUR/kWh spread - flips ALLOWED to REFUSED at min_spread_eur_kwh=0.0, a value arbitrage()'s own docstring documents ("pass 0.0 to mean any positive spread, explicitly") and its validator at :861 accepts on purpose. At a shipped threshold the outcome does not move, but the operator reads the false sentence "the tariff is flat - every one of the 2 firm hours costs 0.2000 EUR/kWh" about a tariff that is not flat. WHAT WAS ADDED. test_static_tariff.py section 9, and the shape of it is the argument: * THE REASON IS GRADED, NOT THE VERDICT. The masked case refuses CORRECTLY while reporting the wrong sentence, so a check asserting only "refused" passes on a broken tree. A `rung9()` helper names which refusal answered, from the sentence the operator would read; an unrecognised refusal reports itself as UNATTRIBUTED rather than quietly matching nothing. * EACH RUNG IS GIVEN A STIMULUS THE OTHER CANNOT ABSORB, or the pinning is circular. The flat rung gets a THREE-firm-hour flat series, which no `len(firm) < N` a person would write can reach. The firm-pair rung gets a ONE-FIRM-HOUR series, which the flat rung CAN reach - so its attribution is the whole check, and that is why it is written as a rung name rather than a verdict. * AC1 is a sweep of small-but-real spreads (0.0005 down to 0.000001) all ALLOWED at min_spread_eur_kwh=0.0, with the exactly flat series on the other side still refused BY THE FLAT RUNG - without that mirror the sweep would also pass for a rung deleted outright. 1e-6 is the floor because the shipped line rounds the spread to 6 decimals; that quantisation is graded in the open as its own row rather than left unstated. * AC3 is a five-row table graded on rung attribution, which denies the masking from both sides at once. * The firm-pair count is also pinned from ABOVE (`< 3`) and BELOW (`< 0`), which the criteria do not ask for but which is what stops this section being one-sided in exactly the way it was written to fix. EVIDENCE. Eight rounds through TEST-15's tools/mutation_run.sh, used UNCHANGED: recursive __pycache__ purge before each run, python3 -B, the tree re-copied FROM DISK between rounds, the mutated line grepped out of the file before the run, byte delta printed, test_static_tariff.py and test_arbitrage.py graded each time. Baseline green. baseline, shipped +0 B PASS D1 `spread == 0.0` -> `<= 0.001` +2 B RED, 3 checks D2 `spread == 0.0` -> `<= 0.000001` +5 B RED, AC1 alone D3 `spread == 0.0` -> `< 0.0` (rung gone) +0 B RED (section 2 as well) F1 `len(firm) < 2` -> `< 1` +0 B RED, 3 checks F2 `len(firm) < 2` -> `< 3` +0 B RED, 6 checks F3 `len(firm) < 2` -> `< 0` (rung gone) +0 B RED (ValueError) D1+F1 BOTH AT ONCE - THE TICKET +2 B RED, 5 checks Four of the seven are +0 B, the delta MUTATION.md names as the one stale bytecode can hide. All are REDS, the direction that defect cannot fabricate - but they were run under the purge anyway, because "it went red so the cache cannot have lied" is a conclusion and not a procedure. NO SHIPPED BEHAVIOUR CHANGED. app/ is untouched; both rungs were correct all along, and the card is explicit that a rung found actually wrong is a stop-and- report rather than an edit. Also updated: MUTATION.md gains a short section on masking as a SECOND way a survivor lies, with the two rules that fall out of it (grade the reason, and mutate suspected pairs together); and test_arbitrage.py's SAFETY-26 AC4 note is marked closed rather than left reading as an open finding. UNSURE ABOUT. The 5e-7 row asserts the shipped `round(spread, 6)` quantisation. That is a real property of the line and worth stating, but it does pin a rounding the ticket never named - if a reviewer would rather that stayed unpinned, it is one check to drop and nothing else depends on it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 07:37:19 +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
glenn schrooyenandClaude Opus 5	7b4877d56d	TEST-15: purge the bytecode cache before a mutation run, not after ... FCST-03's developer reverted `self.provisional` to `here.provisional`, re-ran, and reported the mutation as a survivor. It was not one. CPython validates a cached `.pyc` on (source size, source mtime truncated to whole seconds), and that edit moved neither number - same length, same second - so the interpreter loaded the bytecode it already had. Disassembly settled it at the time: the source read `here`, the running code loaded `self`. A mutation run had graded code that was not there, with no error and exit status 0. This does not make the results already on the record wrong. It makes them UNVERIFIED, and that distinction is the whole card - so nothing here re-runs a campaign and nothing here quietly assumes the old numbers hold. REPRODUCED, THEN CLOSED. test_bytecode.py builds a real package whose two return values are the same length, imports it in a real subprocess, rewrites it inside the same second (retrying until both writes land in one whole second - milliseconds, no sleep) and reads back which value ran. Part 1 shows the interpreter running SELF off a file that says HERE. AND THE TWO OBVIOUS MITIGATIONS DO NOT WORK. Measured, not read off documentation: `python3 -B` and PYTHONDONTWRITEBYTECODE=1 are write-side only. Neither stops an EXISTING stale .pyc being read, and a mutation run always has one, because the previous run wrote it. Part 2 grades both still running the old code. The advice in test_control.py's coverage audit led with `-B`; it is corrected here - the purge is the half that works, and `-B` earns its place by keeping THIS run from leaving a cache for the NEXT edit to inherit. NO SLEEP ANYWHERE. One-second mtime resolution is the mechanism, not the enemy. Waiting it out would slow every run down and would still only cover the edit somebody remembered to slow down. THE HARNESS. tools/mutation_run.sh purges, prints a sha256/byte fingerprint of every app/*.py it is about to grade - so a mutation report can say WHICH source produced it, which is the reviewer's addition to this card - runs each suite under `python3 -B`, refuses a tree with no test_*.py (CI-01's rule, for CI-01's reason), and fails if a cache appears during the run. It takes the tree as an argument so the infra repo's replay harnesses can call it without being moved. WHERE IT IS SAID (AC 2). MUTATION.md carries the mechanism, the measurement, the reporting rules and the survey, and every one of the 16 suites now points at it from its docstring. That list is DERIVED FROM THE TREE by test_bytecode.py part 5, so a new suite that joins this directory without the pointer is red - the same failure shape CI-01's file glob exists to prevent. CI WAS ALREADY IMMUNE, AND IS DESCRIBED THAT WAY (AC 4). Verified rather than reasoned: with the checkout bind mounted `-v "$WS:/w:ro"` the interpreter writes no __pycache__ into the tree at all, and it fails SILENTLY - no error, exit status 0 - while the same probe on a writable mount produces one. Each job also rm -rf's its workspace and clones afresh, so nothing crosses between jobs on the shared runner. PYTHONDONTWRITEBYTECODE=1 is added as belt and braces only: the `:ro` is one character wide and the next person debugging a write will be tempted by it. Part 6 grades both ON THE DOCKER COMMAND LINE rather than on the file - the first draft searched the whole workflow and stayed green after the flag was deleted, because the comment explaining it still named it. THE SHIPPED ADD-ON IS NOT AFFECTED and the question is closed: goodwe_controller/Dockerfile has set PYTHONDONTWRITEBYTECODE=1 since it was written. There is no deploy-side finding. THE SURVEY (AC 3), in MUTATION.md, scoped BY THE PROPERTY. The defect is one-directional - a mutation that never took leaves the suite green, so stale bytecode manufactures SURVIVORS and cannot manufacture a red - which puts every "all red, no survivors" claim in the window out of scope, along with mutations executed in-process (SAFETY-07's B1/B2/B3, test_peakguard parts 7 and 10, where no source file is edited) and everything run after the purge discipline landed on 2026-08-31 (SAFETY-24, SAFETY-26, OPT-04, FCST-03's re-run). What is left is the recorded SURVIVORS from source-edit runs before that date. Two were re-run here under the harness and both still stand: TARIFF-01's record_block() ignoring its policy argument, and SAFETY-03's abs() on the clamp limit - 15 suites green each, on the tree as it stood. The rest are labelled still-unverified rather than assumed or re-run; each is one harness run to close, and the moment to spend it is when somebody next touches that module. OUT OF SCOPE AND RECORDED: the infra repo's sim/ replay harnesses import the add-on and write bytecode into both trees (goodwe/sim/__pycache__ exists today), so SAFETY-02's headline replay carries the same exposure. mutation_run.sh takes a tree argument for exactly that, but the change belongs in that repo and some of those harnesses want the rig. RED AND GREEN. Every new check was broken and watched fail: the purge commented out of the harness turns part 4 red (and its non-vacuity probe already proves the fixture would mis-grade without it); one docstring pointer removed turns part 5 red naming the file; `:ro` and the `-e` flag removed from the workflow turn part 6 red. Full suite green, 16 files, in the CI image on a read-only mount - the shape the runner uses. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 02:07:09 +02:00