9 Commits

Include renames

Author	SHA1	Message	Date
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	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
glenn schrooyenandClaude Opus 5	d5b1ef19b3	CFG-03: give maintenance option defaults one source of truth ... Option defaults for the maintenance cycle were declared in three places that could disagree, and MAINT-04 proved they already did. config.yaml shipped `maintenance_charge_w: 2000`; main.py carried TWO `opts.get(..., 2500)` fallbacks; MaintConfig's dataclass carried a third `2500.0`. So an options dict with the key ABSENT was ACCEPTED by validate.py's rule 6 - which read 2000 - and then built by main.py at 2500, against a 2000 W ceiling: options dict with maintenance_charge_w ABSENT, max_w=2000 validate_startup_config -> [] (accepted, no problems) MaintConfig().charge_w -> 2500.0 arbiter.resolve() -> 0.0 W, contradiction=True That is the bug rule 6 exists to refuse, passing rule 6. It is unreachable on a Supervisor install, which always supplies every key from config.yaml, and fully reachable from sim/inject.py and from the test suite - which is where anyone debugging maintenance actually works. MAINT-04 shipped a TRIPWIRE and said so: test_validate.py pinned all three literals and asserted the consequence through the real arbiter, so the divergence could not silently widen or be half-closed. Its PASSING CONDITION WAS THE BUG. Both it and validate.py's comment said to delete each other when the divergence was closed. It is closed, so both are deleted. THE DIVERGENCE WAS WIDER THAN ONE KEY. `maintenance_discharge_w` had the identical three-way split (config.yaml 2000, MaintConfig 2500) and the card named only the charge side. Closing one and leaving its twin would have satisfied the numbers and left three sources of truth one line down, which is the state that produced the bug. Both are closed, and so is the whole family: all eight `maintenance_*` keys go through the same mechanism. WHAT THE SINGLE SOURCE IS. config.yaml's `options:` block - it is what the Supervisor reads and what the operator edits, so it wins by definition. There is now exactly one in-code copy, `maintenance.MAINT_OPTION_DEFAULTS`, which is TARIFF-02's `PRICE_OPTION_DEFAULTS` and SAFETY-24's `PEAK_OPTION_DEFAULTS` pattern applied to the family that named the card - validate.py's rule 8 comment already called that "CFG-03 read as a rule rather than as a complaint", so this makes the rule hold where it was first broken rather than inventing a fourth mechanism for one option family. A MIRROR RATHER THAN A RUNTIME READ, and the reason is mechanical: the Dockerfile copies `app/` and `run.sh` into the image and NOT config.yaml. The running add-on cannot open the file it is configured by, so there is nothing to read at 03:00 on a client's Pi, and a YAML-subset parser that could fail at import is a new way for the add-on not to start. What makes the copy safe is that test_maintenance.py pins every entry by READING the shipped file - drift is a CI failure, not a comment. EVERY OTHER SITE NOW DERIVES FROM IT OR HAS CEASED TO EXIST: * MaintConfig's eight dataclass defaults are indexed out of the mirror. No numeric literal survives in the class that held the third opinion. * `MaintConfig.from_options()` is the ONLY place in the add-on that reads a `maintenance_*` option. main.py's eight inline `opts.get(key, <literal>)` calls are gone: moving the read next to the mirror means the fallback cannot be anything but the mirror, because there is no literal in sight of it to disagree with. It uses `key in opts` rather than truthiness, so a shipped `false` or `0` is honoured instead of being quietly replaced by the default - this card's own bug in a different costume. * main.py's SECOND fallback site - the cheap-window charge floor at the P_MAINT_SHAPE claim - reads `self.maint.cfg.charge_w` instead of re-opening the options dict with its own literal. The Controller had already parsed this once in __init__; asking the object that owns it cannot drift from it, and the rate the shaping asks for can no longer be a different number from the rate the state machine drains at on the same install. * validate.py's rule 6 and its `maintenance_discharge_w` warning take their fallbacks from the mirror. WHERE THE RANGE LIVES, STATED AND CHECKED. config.yaml's `schema:` block carries `maintenance_charge_w: int(500,5000)` - a fourth declaration site of a different kind. It is a BOUND, not a default, so it is not this bug; but leaving the question open is how a fifth site arrives. The decision recorded in config.yaml and in maintenance.py is: bounds live in the schema block ONLY, because the Supervisor is what enforces them and the Supervisor reads only that file, so a Python copy of `int(500,5000)` would be a place to disagree and nothing else. test_maintenance.py checks both halves of that: every mirrored key must have a schema entry - without one the Supervisor drops the option and the add-on silently runs on the mirror instead of the operator's value - and every shipped default must lie INSIDE its own range, since a default the schema rejects is a config that cannot be re-entered once it is edited. What the schema grammar cannot express is a relation BETWEEN keys (`maintenance_charge_w` against `max_w`), which is exactly why rule 6 is written in Python and why it does not belong in the mirror either. THE REPLACEMENT CHECKS, AND HOW THEY WERE VERIFIED. test_validate.py's new section exercises the same four consumers the defect ran through, the same way: the validator ACCEPTS a dict with every maintenance key missing; a REAL Controller built from that same dict holds 2000 W (through main.py, not through a regex over its source); `MaintConfig()` answers 2000 W with no dict at all; and the real arbiter emits `-2000 W, limited by supervised(max_w)` instead of `0 W, contradiction=True`. test_maintenance.py pins the mirror to config.yaml in both directions - equal values, and full coverage of every `maintenance_*` key the file ships, so a ninth key cannot arrive unmirrored - and asserts the consumers move as a RELATION rather than against numbers, reading MaintConfig's defaults back out of `dataclasses.fields()`. Each new check was verified by BREAKING the thing it watches and observing red, this project's rule: 1. config.yaml -> 1500, mirror left at 2000: test_maintenance 1 FAILED, test_validate 4 FAILED. 2. config.yaml AND the mirror -> 1500: green again, and every consumer moved together - MaintConfig() 1500 W, the Controller 1500 W, and the arbiter `-1500 W, limited by maintenance(cheap-window charge)` where it had said `-2000 W, limited by supervised(max_w)`. That is AC4: change the single source and watch the consumers follow. 3. `charge_w: float = 2500.0` retyped into the dataclass: 2 FAILED in each of the two files. 4. `opts.get("maintenance_charge_w", 2500)` restored in main.py: 1 FAILED, naming the file and the literal it found. 5. `maintenance_hold_min` deleted from config.yaml's options block: 3 FAILED. Full suite 17/17 in goodwe-addon-ci, twice, once under parallel load. Stale prose that asserted the now-closed divergence as current is corrected in app/watchdog.py, test_watchdog.py and test_peakguard.py - watchdog.py's example still uses 1500 W, but because the point of the example is a charge strictly inside the ceiling, not because 2500 is what ships. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 06:16:54 +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
glenn schrooyenandClaude Opus 5	c040aac4b8	SAFETY-03: alarm when a computed setpoint exceeds the rating, do not just clip it ... The clamp was never the missing half. specs.md 10.3 records an unclamped integrator climbing ~130 W per 4 s past 10 kW and reporting 14 768 W pinned at the 5 kW rail; clipped silently that is a flat, legal-looking 5000 W hold and nothing says the loop asked for three times it. write_setpoint() - the one path every write takes - now clamps to the VALIDATED max_w and reports whether the raw value differed; check_output_clamp() raises OUTPUT_CLAMP as a notification, an ERROR, an event row and a red status banner. Not a trip: the clamped value is written and the loop keeps running. The rating is max_w and nothing is min()ed at runtime - CFG-01 already refuses a max_w outside the device range at startup. The device range is applied second as defence in depth; it cannot bite after a successful validation, so if it ever does it alarms too and names the bound. No new config key. Decision grew i_clamped / clamped booleans, and that is the load-bearing part: `reason` is one string that slew-limiting and the saturation freeze overwrite, so an alarm keyed on it is silent on exactly the cycles a winding loop produces. Mutating main.py back onto the string drops the 10.3 replay from 2 engagements to 0. Distinct from saturation by construction - no shared reason code, notification id, status row or counter - and checked in the negative, after first asserting the saturation freeze really did engage. Two things found by running it rather than by reading it: a row per engagement flushed the 40-row event log and evicted SAFETY-18's own METER FROZEN? row (now coalesced per episode with an exact count), and a naive clamp turns a nan into a command at the full rating because every comparison against nan is False. test_clamp.py is new: assert-based, no framework. Six author mutations reproduced red, including "clamp kept, alarm deleted". Two of the check's own hypotheses about the freeze/clamp interaction were refused by its sweep and rewritten to what it measured. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 15:22:22 +02:00
glenn schrooyenandClaude Opus 5	878a6ce452	MAINT-04: refuse a maintenance charge the ceiling cannot deliver ... config.yaml shipped max_w 2000 against maintenance_charge_w 2500. The cheap-window shaping files Claim.limit(hi = -maintenance_charge_w) against the supervised SAFETY limit's lo = -max_w, so lo > hi - the arbiter's clause 3, correctly resolved to 0 W and logged as a CONTRADICTION. Maintenance silently never charged in a cheap window on a default install, and the only evidence read like a bug in the arbiter rather than like the two numbers the operator set. validate_startup_config() now refuses maintenance_charge_w > max_w, the same shape as CFG-01's sign_disagree_w >= max_w. Equality is reachable (-max_w is a single valid point) and is not refused. Demonstrated by starting the add-on on the pre-fix pair: exit 78 and the refusal banner. maintenance_discharge_w was checked rather than assumed and is NOT the same case: the drain phase OWNS the actuator (Claim.set at P_MAINTENANCE), so the ceiling clamps it to +2000 W and the arbiter's explain() names the clamp every cycle. Loud, and it still moves energy - warned, not refused. The shipped maintenance rates drop to 2000 so the defaults pass the rule; max_w was deliberately not raised, because it is the supervised safety ceiling. test_validate.py now reads config.yaml itself, so a default the validator refuses cannot ship again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-30 02:28:09 +02:00
glenn schrooyenandClaude Opus 5	e40eb0768d	SAFETY-02: the P_PEAK assertion was pinning the test's copy of the gate ... Review finding 2, and it is the same duplication `disagrees()` just removed, so it gets the same fix rather than a follow-up card. `following_from()` in test_watchdog.py was a TRANSCRIPTION of the gate in main.py, carrying "keep the two in step" as an instruction - which is exactly the arrangement that does not keep two things in step. Measured: editing the shipped gate alone to `winner in ("loop", "peak")` left every suite green while the watchdog went blind for the duration of every peak event. The row whose whole job is to force whoever lands peak shaving to come and change an expectation did not do that. The expression is now `watchdog.loop_is_following()`, called by main.py and by the test. One definition, two callers, same reasoning as `disagrees()`: the copy that drifts is always the one in the harness doing the grading. ⚠️ AND EXTRACTING IT WAS NOT SUFFICIENT - the drift proof still came out green after the extraction, which is why it was worth running rather than assuming. The realistic P_PEAK row has peak shaving asking for MORE than the loop, so the magnitude term rejects it whatever `winner` says and masks the term under test. A second row with peak asking for LESS makes `winner` the only deciding term. With that row, widening the shipped gate fails two checks; without it, none. Also enforcing the write ordering that was documented and not asserted: swapping the two `store.set` calls passed everything. A store that fails the second write now proves the property the ordering exists for - a crash mid-trip leaves a reason with no latch, never a latch with no explanation. Swapping them now turns that check red. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 22:59:46 +02:00
glenn schrooyenandClaude Opus 5	cc4e88490b	SAFETY-02 review: a latch that a restart clears is not a latch ... BLOCKER. `auto` was persisted and `sign_wd.tripped` was not, so reconstructing the Controller against the same store - which is what a container restart does - brought it back ARMED, into the same fault, unattended: tripped=False, banner back to NOT READY, and it resumed commanding -1000 then -2000 W before re-tripping 180 s later. "Restart the add-on" is the first thing an operator looking at a FAILSAFE banner and a 0 W inverter will try, and under a supervisor that restarts a crashed add-on it is a loop of three-minute wrong-direction bursts. DOCS.md's "it does not clear itself" was false across a restart. `sign_tripped` and `sign_reason` are Store keys now, beside the maintenance state and for the reason store.py's own docstring gives. Written the moment the trip happens - reason first, flag second, so a crash between the two can never persist a latch with no explanation - restored in Controller.__init__, cleared only by the operator's start. The regression is covered: reverting the restore fails seven checks in test_watchdog.py. Review follow-ups, no behaviour change: - The arming gate is tested against the REAL arbiter. It is the decision the ticket turns on and it was asserted in three comment blocks and verified by nothing - every case passed `following` in as a literal. Twelve claim configurations now derive it from resolve(), including the redirect case `winner == "loop"` alone would have got wrong and the `lo` limit that raises magnitude without flipping sign. - The MQTT `status: "failsafe"` value is tested. The check that claimed to cover it restated the line above it and never touched the payload. - The worked example described a config that does not ship: at the defaults maintenance_charge_w 2500 against max_w 2000 is an arbiter contradiction and 0 W, not a -2500 W charge. Rewritten at 1500 W. The contradiction is a real pre-existing bug - a default cheap-window maintenance charge silently never happens - filed separately and deliberately not fixed here. - Forward hazard recorded at the gate: `winner == "loop"` disarms the watchdog under any higher-priority SET, and a peak-shaving strategy at P_PEAK IS grid-following in sign, so it would blind this for every peak event. - disagrees() is public so the replay harness stops carrying its own copy of the predicate it grades. - held_s takes the clock instead of reading one. - The two limits are now each stated in both places rather than one each. - The no-false-positive argument is tied to control.py's freeze permitting the command to cross zero; under the shrink-only encoding control.py records as rejected, this would false-trip on a load step. - Measured figures corrected: 93.4 % / 4212 of 17280, per-cluster 0.3/0.9/10.5/0.0, and the near-circularity of those figures is now stated rather than leaned on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 22:33:15 +02:00
glenn schrooyenandClaude Opus 5	9aed43990b	SAFETY-02: a loop can be fresh, tracking and inside its rating and still push the wrong way ... The stale-input watchdog asks whether the meter is still talking. The saturation freeze asks whether the inverter can follow. The output clamp asks whether the number is too big. A loop can pass all three while charging the battery out of the grid, because the only thing wrong is the sign. On 2026-08-20 a commercial controller did exactly that four times in one day, for up to 77 minutes at a stretch, reaching a commanded -14 768 W against a ±5000 W inverter. app/watchdog.py compares the emitted setpoint against the authoritative P1 figure and, when they oppose each other with both over 300 W for 180 s continuously, files a failsafe SET claim at P_SAFETY, commands 0 W and latches there until an operator starts control again. Validated against that day rather than against an argument: sim/replay_sign.py in the infra repo drives this module over the committed captures of both 2026-08-20 and the healthy 2026-08-23 and reaches 18 trips on the fault day - every one inside a window NOTES.md §4.7 accounts for - and 0 on the healthy day. The four episodes do share one signature: 0.3 / 0.9 / 10.5 / 0.0 % sign agreement inside them against 92.9 % healthy. Three decisions the ticket could not make: - It is DISARMED whenever the grid-following loop is not what is driving. Sign agreement is a property of a loop that follows the meter, and a maintenance grid charge opposes the meter by design - 2500 W of charge into a house drawing 500 W is +3000 W on the meter against a -2500 W command, for hours. The gate tests the emitted number, not the winning claim's name, because a limit claim can let the loop "win" and still replace its value. - The trip LATCHES. Commanding 0 W removes the command side of the comparison, so the disagreement always clears the moment the trip works. - sign_disagree_w at or above max_w is refused at startup. The arbiter never lets a command exceed max_w, so such a threshold leaves the watchdog incapable of firing while the status page still reports it armed. What it does not catch, said out loud: an inverter that ACTS opposite to its command moves the meter further the same way, leaving command and meter in agreement. That is the saturation freeze's job. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Du77usMj8XNKNFZGmUiWDa	2026-08-28 21:51:35 +02:00