3 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
Claude Opus 5	fef6ef20a4	UX-01: translate the add-on config, and order it by task ... The add-on had NO translations/ directory, so Home Assistant fell back to rendering the raw option KEYS. An operator opening Configuration read `unit_sign_disagree_w`, `saturation_cycles`, `integrator_max_w` - seventy of them, in file order, with no description and no way to tell a constant derived from 1890 closed-loop test runs from their own inverter's rating. ⚠️ PRESENTATION ONLY. Not one default, not one schema range and not one line of behaviour moved. The 175 non-comment lines of config.yaml are byte-identical to release/1.0's, reordered; the only comment lines that changed are the group banners and five sentences whose "above"/"below" the reorder made false. * translations/en.yaml and translations/nl.yaml: a name and a description for all 70 options and all 7 per-entry keys of the `inverters:` repeatable section. The Dutch is written for a Flemish homeowner - afname/injectie, kwartierpiek, capaciteitstarief - not transliterated from the English. * ⭐ Every derived constant says WHERE IT CAME FROM and whether to touch it. `unit_sign_disagree_s` cites its 1890 closed-loop runs (SAFETY-30); `circulation_w` its 924 runs and the measured 400 W knee (SAFETY-31); `meter_freeze_s` its 2399 s capture (SAFETY-18); `bms_soc_floor` register 0x0560. The two numbers that are the operator's - max_w and peak_cap_w - say "THIS IS YOUR NUMBER". `cycle_cost_threshold_eur`, which is neither, says it is an open product question (OPT-08). * config.yaml reordered into task order in BOTH halves, comments carried with their keys: hardware -> meter -> ratings and limits -> tariff -> maintenance -> safety -> advanced. ⚠️ test_inverter.py:1788's trap is PRESERVED: the nested per-entry `max_w:` still precedes the flat one under `schema:`, and `inverters: []` still ships in the `options:` half. Moving the nested block below the flat one is a 1-byte edit; it was run and goes red in test_inverter.py and test_translations.py. * tools/supervisor_shape_probe.py section F MEASURES the result against ghcr.io/home-assistant/amd64-hassio-supervisor:2026.08.0 - Supervisor's own _read_app_translations(), its own UiOptions, and the frontend's label resolution transcribed from the shipped bundle - and prints every rendered row in both languages. `all cases passed`, exit 0. * ⚠️ ONE MEASURED NEGATIVE RESULT, NOT GLOSSED: the per-entry keys inside the `inverters:` section still render RAW on frontend 20250925.1, because a list-of-objects goes to ha-selector-object and the converter sets no `label` and no `translation_key`. The `fields:` translations are shipped and validated - that is Supervisor's own shape for this - but this card does not claim they reach the screen. The `inverters` label and description do. * test_translations.py: a translation naming a non-existent option, or an option with no translation, fails CI - both directions, both languages, top level and per entry. Mutation-tested BOTH WAYS: eleven in-process mutations each required to NAME the key they broke, plus a negative control; six more run on disk through the purge-and-re-read protocol. Two of the eleven are the ones that cost the WHOLE FILE rather than one label - an unrecognised top-level block, and a `network:` value that is not a string. Supervisor drops a file that fails SCHEMA_APP_TRANSLATIONS with only a log warning, so those silently return the entire tab to raw keys; neither is reachable through the `configuration:` coverage, which is why they were hunted for and closed. * tools/translations_lint.py is the hand parser CI needs (no PyYAML in the add-on image) and the probe grades it, key by key and string by string, against Supervisor's own loader. It is strict and RAISES rather than skipping; nine malformed shapes prove it. Full 20-file suite green (19 existing + test_translations.py). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-05 12:02:56 +02:00
Claude	591c35ed01	SAFETY-28: gate the write path on the allocation record, not on key count ... specs §1.5 makes "any configuration in which two writers can reach one actuator" a non-goal. That non-goal was enforced by counting config keys: validate.py's ACTUATOR_WRITE_KEYS = ("setpoint_entity",), consumed at rule 1, with a comment stating the guarantee outright - "there is exactly one such key, so a second writer is not expressible in the options schema at all". That was true and it graded THE SHAPE OF THE OPTIONS SCHEMA, not the writes. Add CFG-04's per-inverter config - a roster of inverters each with its own setpoint_entity - and there are two real writers with len() of that tuple still equal to 1. The check stays green while the property it protects is gone. sim/inject.py's two_writers scenario asserted on the same tuple, so it went green too. That is this repository's named failure mode: a check that observes something other than what it claims to observe. Demonstrated rather than argued. test_validate.py part 2 now constructs the hazardous per-inverter config, asserts that the OLD proxy is still green on it, and then asserts the new check refuses it. Against release/1.0's validator the updated sim scenario reports: "validate_startup_config() ACCEPTED a configuration in which 3 declarations reach the ONE actuator number.goodwe_setpoint ... the old proxy reports 1 write key(s) on this same config and is therefore GREEN on it". THE WRITE PATH IS NOW GATED ON THE RECORD ========================================= Controller.write_refusal() asks Allocation.authorises() whether the single allocator placed exactly this number, for this unit, on this tick. write_setpoint() refuses anything else. A second writer with arithmetic of its own cannot satisfy that - its number appears in no record - so it has to file a Claim and go through resolve(), which is the one allocator. "Exactly one allocator per shared resource" stops being a convention somebody can forget and becomes something the write path checks. The refusal is a SUBSTITUTION, not a return: 0 W goes on the wire in place of the number nothing stands behind. Returning would leave the inverter latched on its last command with the ESP32 heartbeat still being fed - holding an unauthorised setpoint quietly, which is the outcome the gate exists to stop. AC 1 is "refused at the write path, not merely logged", and test_clamp.py part 7a grades the device's writes, not the log. The gate sits BELOW the non-finite coercion and ABOVE the clamp. Below, because a nan is loss of input and rule 1 has already turned it into 0 W. Above, because the question is who chose this number, and the answer is only meaningful about the number that was asked for - gating the CLAMPED value would refuse exactly the cycles SAFETY-03 exists for, since a clamped write differs from the allocator's share by construction. Mutation M7 moves the gate below the clamp and turns nine checks red, part 6c among them. A STALE RECORD CANNOT BE REPLAYED ================================= Every Allocation now carries the `tick` it was made for. It is handed IN by the caller - plan(..., tick=) - rather than counted inside the allocator, because test_alloc.py part 10 grades that the module holds no state at all, and a serial number incremented in there would be the cached-across-ticks thing the envelope rule forbids wearing a different hat. Controller.alloc_tick advances ONCE PER RESOLUTION, not once per loop iteration, and both halves are load-bearing: * a new allocation makes the previous record stale immediately, so a record whose envelopes have moved cannot authorise a write. That is the replay half (AC 2), graded by capturing a real record, running another real cycle, putting the old one back and observing refusal. * the "inputs missing, not yet stale" hold returns BEFORE the allocator runs, exactly so one dropped meter reading does not zero the inverter, and the heartbeat re-affirms self.target through this same gate while it does. A tick incremented per loop iteration would refuse that heartbeat and turn the hold into the outage it exists to prevent. Graded. An UNSTAMPED record (tick None) authorises nothing: "I cannot say when I was made" fails closed rather than reading as tick zero. THE FAILSAFE CANNOT DEADLOCK BEHIND THE GATE, AND HERE IS WHY ============================================================= write_setpoint() is also how layer 2 commands 0 W. cycle()'s two refusal branches substitute a 0 W failsafe and write it like any other cycle; shutdown() and the operator's stop button do the same. EVERY ONE OF THOSE RUNS WHILE THE ALLOCATOR HAS REFUSED - ok is False and there are no shares - so a gate that asked the allocator's permission to command zero would block the safety write behind the very component whose failure the safety write answers. A gate that can do that is worse than the hole it closes. Resolved by authorising 0 W unconditionally, and on the VALUE rather than on a failsafe=True flag: a flag is an assertion by the caller, which is exactly what a second writer would pass; the value is a fact about what will be written. The argument that this is safe and not merely convenient is that the hazard §1.5 names is N-times loop gain from BROADCAST - handing every inverter the same target so each supplies it in full (allocator.py's opening argument; TEST-19 measured a permanent 4000 W p2p limit cycle at gain 1.0 with no guard firing). At S = 0 the broadcast and the correct allocation COINCIDE: a_i = 1 for every unit gives every unit 0 W, which is exactly its share. There is no over-command to make at zero. Said at the line, in write_refusal(). test_clamp.py part 7c drives it end to end through the real cycle() and the real REFUSE_EMPTY branch: the allocator refuses every tick, the device still sees 0 W, and the action log says ARBITER: REFUSED rather than WRITE REFUSED so the two failures stay distinguishable to whoever has to debug them. unmet_w IS STILL NOT ok ======================= The gate reads ok and the unit's share and never unmet_w. allocator.py:179 says why: an allocation that could not place every watt is still safe to write, and fusing them would let one saturated inverter park the whole site. Graded on a record with 3800 W unmet and every share legal - mutation M5 adds `or self.unmet_w` to the gate and that check goes red. THE CONFIG CHECK, REPLACED RATHER THAN DELETED ============================================== actuator_writers() counts WRITERS PER ACTUATOR instead of option keys. It walks the options TREE rather than looking for a container called `inverters`, because CFG-04 has not chosen that name yet and a census that guessed wrong would go green while two writers existed - the same defect one step along. Entity ids are folded to lower case so a second writer cannot be smuggled in as Number.X versus number.x. Two inverters with two entities are ACCEPTED - that is what the per-inverter roster is for, and a validator that refuses the feature it guards is one somebody switches off. Two declarations aimed at ONE entity are refused, naming the actuator and every writer pointed at it. That includes the case an author will meet first - keeping setpoint_entity as A's and listing A again - because "they happen to be the same entity, so it is fine" is precisely the reasoning that makes two writers invisible. ACTUATOR_WRITE_KEYS survives ONLY as the enumeration a census needs, with its guarantee comment deleted; nothing asserts on its length any more. Keeping the name is also what stops admin/goodwe's current two_writers scenario failing on an AttributeError between the two merges. WHAT NEITHER CHECK OBSERVES, SAID OUT LOUD ========================================== The census sees CONFIGURED writers. A second write path added in CODE - a hass.set_number() call next to some new strategy - declares nothing and is invisible to it, exactly as it was invisible to the tuple. That half is not closed at startup and cannot be; it is closed at runtime by the record gate, which does not care what the options look like or who called the method. The two checks are deliberately different kinds, and only the runtime one survives a schema this file has not seen yet. EVIDENCE ======== * Full 18-file suite green on a purged tree (tools/mutation_run.sh). * Verified by breaking it - seven mutations, each on a purged tree, each reverted and re-verified: M1 remove the gate -> test_clamp red (4 checks) M2 make the zero exit an amnesty -> test_clamp red (12 checks) M3 drop the tick comparison -> test_clamp red (5 checks) M4 delete the census refusal -> test_validate red (3 checks) M5 fuse unmet_w into ok -> test_clamp red (1 check) M6 freeze the tick on the live path -> test_clamp red (2 checks) M7 move the gate below the clamp -> test_clamp red (9 checks) * AC 5: no existing check was weakened. The two edits to test_clamp.py are fixtures, not assertions - parts 5 and 6c call write_setpoint() directly with a number nothing allocated, which is now refused, so they say where their number came from. Every assertion in both parts is unchanged, and part 7f asserts that across part 3's sixty real cycles the gate refused zero writes. * admin/goodwe's TEST-19 norig scenarios (planner_binding, two_master_plant, two_master_broadcast) still pass against this tree - they import the add-on's control law across the repo boundary. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-02 13:56:48 +02:00
Claude	b68f288fef	TEST-11: pin the clamp guard to the write it reads ... check_output_clamp() sits one line below `await self.write_setpoint(self.target)` in cycle(), and moving it above the write left test_clamp.py, test_freeze.py and test_loop.py ALL GREEN. Measured on the move itself before this commit; measured again after, where test_clamp.py part 6 goes red and the other two are still green - the gap was real and it was only ever in this file. WHAT IS ACTUALLY LOST. The guard has two evidence sources. `self.loop_clamped` is set from the Decision well above the write and survives the move, and on the 10.3 runaway replay it is the source of every engagement the alarm reports (0 write-path engagements against 2 loop-side ones) - which is exactly what makes the move nearly invisible. `self.clamp_last` is assigned by write_setpoint() and by nothing else, is None until it has run, and is what `engaged_write` reads at main.py:856. Moved above the write, that consumer goes quietly false and a DEVICE-bound clamp - max_w above the inverter's own rating, SAFETY-20's install - is reported by nothing. A guard whose second evidence source can be silently disconnected is one refactor from being half a guard. WHAT THE CHECK PINS, AND WHAT IT DELIBERATELY DOES NOT. Not the position: the comment at that line warns against tidying SAFETY-03's ordering and SAFETY-18's into one rule, and a check a rename breaks is worse than none. It pins the CONSEQUENCE - what `self.clamp_last` held each time the guard consulted the watchdog - using a spy subclassed from the shipped ClampWatchdog over a slew-limited ramp where every cycle's command is a different number, so "this cycle's evidence" and "last cycle's" are distinguishable at all. The spy hooks `clamp_wd.note()`, the consumer, rather than the guard's name: that is what keeps a rename legitimate. The same assertions are re-run through a controller whose guard is renamed and whose write lives in a helper, and were verified against main.py itself - renaming the method throughout AND moving both calls into a new `_emit_and_guard()` helper keeps part 6 green; swapping the two calls turns it red on a line that names clamp_last. WHY AC 3 NEEDED A NEW STIMULUS, AND WHY IT IS NOT DRIVEN THROUGH cycle(). Through the real cycle() the write-path half cannot engage: the arbiter files the device range and max_w as P_SAFETY LIMIT claims, so resolution.target_w is already inside both bounds before write_setpoint() re-applies them. That duplication is deliberate defence in depth; part 6 now MEASURES the zero engagements rather than leaving it as a claim in a comment, and then drives the write path directly at max_w 5000 against a +-2500 W device - the wire carries 2500 W, every loop-side flag stays clean, and the alarm fires on clamp_last alone. With the two calls swapped the same stimulus clamps the same value and the alarm is silent, which is the ticket in one pair of runs. main.py gains one comment sentence naming the check, mirroring the one SAFETY-18's block already carries for test_freeze.py part 5. No behaviour changes. Full suite: 17/17 green in goodwe-addon-ci. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-01 07:31:26 +02:00