13 Commits

Include renames

Author	SHA1	Message	Date
glenn schrooyenandClaude Opus 5.5	770988c902	TEST-26: a missing value in a check is a named FAIL, not a traceback ... Checks and prints that indexed an empty list, exhausted next(), or formatted None killed the rest of their file (FCST-06). Read them through the new named_absence.py (nth/first/field/given/present) and conjoin a presence term. - every site in the brief, plus the family the new scan and a sweep found - test_named_absence.py: scans every test_*.py for unguarded filtered-list indexing, next() without a default and numeric formats on maybe-None names; proven to bite; prints what it cannot see, counted - test_price.py 16a: the `_T17_CAPS is _T17_CAPS` tautology now grades the two assemble() calls' arguments - test_control.py: coverage table re-measured on runs graded to the end Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-25 00:06:58 +02:00
glenn schrooyenandClaude Opus 5	e3ccd9f6ea	SAFETY-47: what a shadow run can show, and the watts on its status row ... Not a leak and not a write-path defect. Shadow mode's safety is intact - the substitution, the re-seed, the authorisation gate and the clamp are untouched. What was wrong is what three merged documents SAY a shadow run can show you, and a number on the status row that can be 6.61x what a live controller would command. SHADOW MODE CANNOT SURFACE A CLOSED-LOOP DEFECT, AND THE DOCUMENTS NOW SAY SO. The battery is held at 0 W and the carried command is re-seeded to it, so every measured input - the meter, the billed-quarter accumulator behind it, the battery power, the SoC - describes a plant that did not respond. A closed-loop defect is one whose stimulus IS that response. This is the same property that makes shadow mode safe, so it is not a gap to close later: the closed-loop answer comes from the closed-loop rig or from a live run. SAFETY-10 §5 already conceded this for the grid-following loop. It was never the loop leg's limitation; it is the general case. THE "STRATEGIES ARE UNAFFECTED" EXEMPTION WAS TRUE UNTIL SAFETY-45 MERGED, ONE COMMIT EARLIER. That card sizes the buy leg as min(asked, headroom) with headroom = (900/remaining) x (ceiling - projected), and `projected` reads the open quarter's accumulator - the meter - which is a function of what the battery did earlier in that quarter. Measured on TEST-23 stage 3 at peak_cap_w 1500 / house 1200 / max_w 2000, one hour at 5 s: SAFETY-45's limit cycle NOT visible. 28 onsets live vs 1; grid -455.5..+3200.0 W vs flat at the 1200 W house; guard engaged 410/720 cycles vs 0/720. SAFETY-46's SoC churn NOT visible. The SoC moves 0.000000000 pp. TARIFF-14's wrong hour VISIBLE, and it is the only one: which hour, at what price, clearing what spread - identical on 720 of 720 charging cycles at a binding cap. The exemption narrows to exactly what survives: WHICH hour a strategy picks and WHY are unaffected; HOW HARD it trades is not. The peak guard's ceiling and reasons are worth reading from a shadow run; its ENGAGEMENTS are not. THE NUMBER IS CAVEATED, NOT RE-COMPUTED, AND THAT IS THE DECISION. The arithmetic is not wrong - 900/remaining is correct for a meter genuinely under the ceiling, and in shadow the meter genuinely is. It is the right answer to a question nobody asked. Both surfaces now introduce the watts as what would have been commanded ON THIS CYCLE, in every state, and carry shadow.SIZED_FROM_METER whenever a measured billed quarter sized them. Rejected, and recorded in the decision doc: re-computing it (the recorded decision would no longer be the decision the shipped path reached, while the arbiter, clamp, SAFETY-28 gate, log and MQTT all ran on the real one - a second controller everywhere except the wire); recording nothing (blanks the row exactly when arbitrage is trading, and the log's edge key is the watts); and recording the unsized ask beside it (a second number, no warning, and at the shipped 3500/2000 both figures read 2000 W). "UPPER BOUND" AND NOT "SMALLER", AND THE DIFFERENCE WAS MEASURED. Charging only adds offtake, so the shadow size is >= the live size with EQUALITY at the start of every quarter. Pairwise over 3600 charging cycles in five configurations: 0 below, 730 exactly equal. The first draft said "smaller", which would have been false on every one of those 730. AND THE PREDICATE IS NOT KEYED ON WHETHER THE TRADE WAS CAPPED. arbitrage's own sentence says "SIZED BY THE CAPACITY-TARIFF GUARD" only when the headroom came out below the ask - in a shadow run, the START of the quarter, where the two runs agree to the float. By the end, 900/remaining has multiplied the headroom past the ask, the trade is not capped, the sentence is silent, and the record is at its most wrong. A caveat keyed on it would be quietest exactly where it is needed loudest. SAFETY-10 §6's COMMITTED EVIDENCE COULD NEVER HAVE FAILED, FOR TWO INDEPENDENT REASONS, AND CLOSING EITHER ALONE CLOSES NOTHING. Its fixture is peak_cap_w 15000 against a 350 W house, so the guard never engages and the sizing is inert - the harness's own comment says so. AND every identity row reads the FIRST charging sample, where at elapsed=0 the projection IS the held level and the two runs agree to the float even at a cap that does bind. Measured: widening the fixture alone leaves that comparison passing. That second reason is a new shape for MUTATION.md's habit-4 list - an INDEX, not a fixture - and it is recorded there as the twelfth instance. §6 is re-taken at a binding cap across the whole run: 716 of 720 charging cycles differ, headroom 300.0..54000.0 W in shadow against 299.9..307.8 W live, recorded -2000.0 W against a live -302.4 W. THE GRADER IS test_arbitrage.py PART 3d, beside SAFETY-45's own closed-loop regression and built on the same s45_loop() harness, so the runs differ in one argument. Three lines stand in for _write_unit()'s substitution and _shadow_settle()'s record and re-seed, marked as a transcription; test_clamp.py part 8 remains the check on the shipped placement. The section carries its own precondition into every check: a mutation that stopped either run trading made it raise on its first min(), kill the file and report ZERO reds - FCST-06's shape, driven rather than imagined. AND THE FIX'S OWN FIRST DRAFT CARRIED THE SAME DEFECT. Deleting the caveat from the action-log line left all 29 files green, because the sentence was an f-string inside _shadow_settle() and the only suite that drives it uses a meter_source:off fixture where no arbitrage decision exists. It is shadow.log_line() now, for the reason words() is a function. 14 mutations, no survivors; M13 and M14 are +0 B and were confirmed on disk by sha256 with every run purged. M14's first form was aimed at the wrong direction and correctly survived - min->max makes the shadow record larger, which is still an upper bound. All 29 check files green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-15 01:26:57 +02:00
glenn schrooyenandClaude Opus 5	e1b9254626	SAFETY-45: a price-driven charge is SIZED by the capacity guard, not switched by it ... With arbitrage armed at the shipped defaults, arbitrage and the capacity-tariff guard drove each other in a sustained limit cycle. Re-measured on TEST-23 stage 3's closed rig against 478ba93, metrics recomputed rather than taken from the card: `peak_cap_w` 1500 / 1200 W house -> 28 charge onsets an hour, mean period 131.1 s, the grid swinging -455.5 to +3200.0 W; at the SHIPPED `peak_cap_w: 3500` with an 1800 W house -> 8/h, with a 3000 W house -> 32/h. The bite rule is `load + max_w > peak_cap_w`, i.e. any house over 1500 W in the cheapest quarter. §10.2: "an EMS that oscillates is worse than no EMS, both for hardware wear and - per §9.1 - for the peak it is trying to avoid." And it was losing the argument it was having: EVERY billed quarter in the three affected configurations finished OVER the cap. ⚠️ THE CARD'S STATED MECHANISM IS WRONG AND THE CORRECTION IS ON THE RECORD. The card, and .cache/s45.md before it, say the loop is the quarter boundary resetting the projection and arbitrage re-arming at full power. It is not. Of the 27 gaps between the 28 onsets, 23 are 90-120 s (mean 111.5 s) and lie ENTIRELY INSIDE one quarter; the four long gaps - 230, 240, 250, 255 s - are exactly the four that SPAN a boundary, so the boundary LENGTHENS the interval rather than causing an onset. The real cycle, off the recorded fields: the trade charges at max_w while `wanted = batt_w + excess` is negative and the guard files NOTHING; `wanted` crosses zero; the guard engages on a floor of 5.3 W; that flips `arbitrage.guard_state()`, which cancels the WHOLE trade; the grid-following loop - which targets grid = 0, not grid = ceiling - takes the actuator and discharges to +1870 W, exporting 420 W; the projection collapses; the guard releases; the trade re-arms at max_w. A binary interlock keyed on a continuous quantity. A fix aimed at the boundary would have removed four of twenty-eight onsets. THE FIX IS A SHAPE THIS ADD-ON ALREADY HAD. `control.maintenance_charge_floor()` caps a MAINTENANCE charge at "the headroom left under the site's cap", because "a maintenance charge is the only thing this system does that is big enough and long enough to set that peak". ⚠️ That sentence stopped being true when OPT-04 landed. `peakguard.charge_headroom_w()` publishes the same quantity off the MEASURED guard rather than off the optional `peak_forecast_entity` - the hole SAFETY-25 had to close in `shaping_suspended()` - and `arbitrage.decide()` sizes its BUY leg to it, keyword-only and with no default. NO NEW ARITHMETIC AND NO NEW CONSTANT. The number is `wanted_w` read in the other direction: `decide()` already computes the DISCHARGE that lands the quarter on the ceiling, and a negative one is a permitted CHARGE of `-wanted`. ⚠️ `peakguard.decide()` IS UNCHANGED - sha256(decide) = 200090d0835a3a55, 7252 B on this branch and on 478ba93 - so 2026-08-20's anti-bang-bang rung is exactly where it was, and tools/replay_ac3.py reproduces 190/190 guarded quarters, 110 engaged cycles, 5 blind and 878 Wh on both trees. TWO PROPERTIES MAKE IT SAFE TO HAND A STRATEGY, BOTH SWEPT RATHER THAN ARGUED. It is INVARIANT IN THE BATTERY - raise the charge by dW, the meter rises by dW, so `excess` rises by dW while `batt_w` falls by dW and `wanted` does not move: 1350.0 W at every point across batt_w -5000..+2000 W on one banked quarter, while the `excess` those runs see takes six distinct values. It is feed-forward, so consuming it adds no feedback path around the plant. And HOLDING IMPLIES ZERO OR UNKNOWN: across 1080 swept combinations not one ENGAGED decision answers a positive headroom. AFTER, same rig, same command. 1500/1200: 28 onsets -> 1, grid swing 3655.5 -> 282.0 W, energy bought 180.0 -> 285.2 Wh (+58%, because a continuous 300 W trade beats a 2000 W trade cancelled for 57% of the hour), billed quarters 1490/1497/1509 -> 1500.0/1500.0/1500.0. 3500/1800: 8 -> 1, 3511/3536/3559 -> 3500/3500/3500. 3500/3000: 32 -> 1, 3519/3542/3557 -> 3500/3500/3500. The two shipped-default rows buy 2.2% and 1.6% LESS energy and in exchange the worst quarter goes from 59 W over the cap to zero - which is the ordering §10.1 asks for, since the capacity tariff bills the month's single worst quarter. ⚠️ AND THE NEGATIVE CONTROL: at peak_cap_w 5000 with a 1200 W house, where `load + max_w` never reaches the cap, the two runs are BIT-IDENTICAL. ⚠️ A NEGATIVE `lo` WAS CONSIDERED AND REJECTED, AND THE REASON IS IN THE CODE. Deleting `decide()`'s `wanted <= 0` gate and filing `lo = wanted` is the tidier answer arithmetically. It creates a new `lo > hi` CONTRADICTION against main.py's cheap-window maintenance shaping, which files a NEGATIVE `hi`; arbiter.py clause 2 has no notion of one limit out-ranking another, so it resolves to 0 W - the battery PARKED in the quarter that sets the bill - and the only way to close that suspends the maintenance charge shaping PERMANENTLY on every site this card is about. A backoff or cooldown in arbitrage was rejected too: both modules' design notes say no timer is invented, and the trade now re-arms at `ceiling - load` rather than at max_w, which is what learning from a refusal means when the refusal is a measurement. THE REGRESSION IS THE LOOP SETTLING, NOT A UNIT TEST ON decide(). test_arbitrage.py 3c closes the loop over the shipped guard, strategy, arbiter, control law and QuarterAverager with a modelled plant, and asserts BOTH directions: unsized it must run away (24 onsets, -414..+3200 W, a quarter over the cap) and sized it must settle (1 onset, 303 W swing, three quarters at exactly 1500.0 W). The two runs differ in one argument. A third pair asserts the card is INERT where the defect is inert. Evidence: 29/29 green. 14 mutations, every one RED on a named check, no survivors; two are ZERO BYTES - `min()` -> `max()` on the sizing, and the sized-trade sentence's two operands transposed - and both are red. M13 reverts the 2026-08-20 rung and is red on EIGHT named checks in test_peakguard and three in test_arbitrage. Every revert verified by a tree fingerprint AFTER the revert, which is how a defect in the battery's own harness was found: two edits to one file, restored in list order, left the first one on disk (MUTATION.md habit 18). test_peakguard.py part 1 also gained a None-safe format, because the mutation it exists to catch made it raise TypeError one line later and ABORT the file - parts 2-13 were ungraded and M13's recorded coverage was one check instead of eight. Not fixed, and named: TEST-23 finding 1's export overshoot at the END of a trade (356-938 W, ~0.37 x max_w) is a different card; a house whose load ALONE exceeds the cap still has the trade refused outright and the loop drive to grid = 0 rather than to the ceiling, and no swept pair reaches that regime; the container leg (hadrive.py) was not re-run because test23s3-addon is deliberately stopped as a second writer on the setpoint entity. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-14 16:10:34 +02:00
glenn schrooyenandClaude Opus 5	9c65ac2cf8	TARIFF-18: price_taxes_eur_kwh stops shipping at half the real figure ... `price_taxes_eur_kwh` shipped at 0.06 EUR/kWh with no recorded provenance - no card, no date, no component list - and roughly HALF the true Flemish all-in non-energy figure. It now ships at 0.11736, and the rows it is made of are in the code rather than in this message: Fluvius distribution (Antwerpen) 5,35 c EUR/kWh Bijzondere accijns, "Alle verbruik" 4,876 Bijdrage groene stroom en WKK Vlaanderen 1,51 Energiebijdrage (0 EUR/MWh since 2026-08-01) 0 ------ 11,736 c EUR/kWh = 0.11736 Eneco residential card for Flanders, September 2026, incl. 6 % VAT. `app/price.py`'s FLEMISH_TAXES_COMPONENTS_EUR_KWH carries the rows and test_price.py section 1b re-adds them - and also compares the total against the card's own figures typed in the test file, so an edit that moved the rows and the default together is still caught. WHAT THIS IS NOT. It is not an arbitrage-correctness fix and it cannot be. This scalar is a LEVEL component: an additive constant cancels exactly in `max - min` and leaves the argmin where it was. TARIFF-17 shipped that proof and it is unchanged - test_price.py 16b drives six flat scalars spanning and exceeding the whole per-DSO range and gets the identical cheapest hour and the identical spread to the last digit. DOCS and the CHANGELOG say so in those words. WHAT IT IS. A display and guard fix: * every number an operator reads, which at half the true value made the add-on look considerably better than it is; and * §17's negative-price guard in arbitrage.py - the one rung that tests an ABSOLUTE all-in price rather than a difference. It fires when `spot < -(markup + taxes)`, so its boundary moves -0.09 -> -0.14736 EUR/kWh of spot. test_arbitrage.py section 2c drives both sides through the shipped decide() and pins the boundary from below as well. The default is Antwerpen's real row, near the LOW end of the 0.117-0.131 per-DSO band, and that is deliberate: the error directions are not symmetric. Too high carries a genuinely negative hour above zero and the add-on exports into paid-for disposal - §17's own case. Too low only declines a discharge that would have paid. TARIFF-17's INTERACTION, WHICH HAD TO BE DECIDED. Nothing in that rung hardcoded 0.06; it read PRICE_OPTION_DEFAULTS, so moving the default moves what it refuses. The Supervisor sets `App.options = deepmerge(config.yaml defaults, stored options)`, so a saved blob carries the key whether it was typed or not - every stored 0.06 became "non-default" with nobody editing anything, and a working Walloon or Brussels site with a taxes table would have met SystemExit(78) on the upgrade over an inert number. price.py now carries SUPERSEDED_TAXES_DEFAULTS_EUR_KWH = (0.06,) and validate.py reads a superseded default as untouched too. The rung is NOT weakened: 0.1198 beside a table is still refused by name, and the refusal now names both figures. config.yaml and PRICE_OPTION_DEFAULTS moved together; CFG-03's tripwire (test_price.py section 1, test_defaults_pin.py) stayed green by agreeing. test_price.py section 0's fourth check was REWRITTEN rather than re-pointed: it used to justify the file's own grading constants by observing that the shipped pair was degenerate (0.06 is exactly twice 0.03). TARIFF-18 ends that coincidence, so the sentence is no longer true and is not kept. 29/29 test files green. Mutation ledger on the PR. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-13 16:24:56 +02:00
glenn schrooyenandClaude Opus 5	028c3e53fb	Merge release/1.0 (TARIFF-12) into TARIFF-14 ... Second base move while this card was open: 559f0eb -> a6e64fb. Only CHANGELOG.md conflicted; test_arbitrage.py auto-merged (TARIFF-12 used section 8b, this card uses 10, so the two do not collide). CHANGELOG: both entries under the single ## Unreleased in MERGE ORDER - TARIFF-12's row and section precede this branch's, because it landed first. No version number is picked; PKG-06/07's note stands untouched. WHAT TARIFF-12 CHANGES FOR THIS CARD - written out in decision note §8 rather than left silent, because the question is a fair one. A served plan can now be up to TARIFF_MAX_AGE_S = 3 * TARIFF_REFRESH_S = 5400 s old, where before it was at most one refresh interval, and at() is what answers "what does it cost right now" out of that older plan. * PER-POINT SPAN: unaffected, structurally. Every window is derived from the neighbours' ABSOLUTE start instants - datetimes in a frozen dataclass in a tuple, which cannot move - and _cover_table() runs once at construction over data that cannot change. A plan's AGE is a property of fetched_at/tariff_at, never of a window. The index cannot go stale, which is a small positive under TARIFF-12: a kept plan now lives longer and there is nothing in it that needed recomputing. * ONE-HOUR CAP: unaffected. It bites only at a hole; walking further into a series crosses more windows, each resolved on its own neighbours. * THE TAIL: reachable for the first time, and §2's choice survives it. At the shipped 48 h horizon the tail is ~46.5 h beyond anything a 90-minute-stale plan can be asked about. But price_horizon_h is int(1,72), so a 1 h horizon is a SUPPORTED configuration, and a 90-minute serve-stale window against a 1 h series puts `now` past the end. Under the chosen rule a quarter-hourly 1 h series ends at :45, its window closes on the hour, at() raises Absence, _act() idles and §11.4 sends the site to the static profile. Under the REJECTED flat one-hour tail the same stale plan would have traded against the :45 print for up to 45 minutes after the interval it describes had ended. So TARIFF-12 does not weaken the decision - it is the first thing that makes it reachable, and it selects the same answer. The rule should be re-read if TARIFF_MAX_AGE_S is ever widened again. * TariffPlan.from_feed is a pure predicate on `origin` and TARIFF-12 keeps or replaces a WHOLE PLAN OBJECT. It never splices two reads into one series, so it cannot hand at() an unsorted or duplicated point list. RE-GRADED ON THIS BASE, not carried over: all 29 test files green; app/price.py byte-identical to the TARIFF-10 merge (90d8ca31f7c0109d, 85953 B) because TARIFF-12 does not touch it; M1 re-driven at +68 B, red on the same 24 named checks across both files; M3 re-driven at ZERO BYTES, red on the same 4. Each purged before the run and reverted with the fingerprint re-checked, from a card-specific harness at /home/homelab/.cache/t14-mut/ with a mktemp backup inside it. This branch contributes zero diff to app/main.py and app/static_tariff.py. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-13 01:47:17 +02:00
Claude	f5ea39784d	Merge release/1.0 (TARIFF-10) into TARIFF-12 ... CHANGELOG.md was the only conflict: both entries belong under the same `## Unreleased` heading, TARIFF-10's first because it merged first. No version number picked. app/main.py auto-merged, and was re-read because of it. TARIFF-10 changed WHICH installs run `run_tariff_refresh()` (`arbitrage.enabled(opts)` -> `tariff_refresh_wanted(opts)`); this card changed what that task does on a failed fetch. Nothing in the keep/replace reasoning changed, and the two newly reachable configurations are now DRIVEN in test_arbitrage.py 8b rather than reasoned about: * a provider configured with trading DISARMED is the case the guard was designed for, and needs no second fixture because nothing on this path reads `arbitrage_enabled` at all - asserted over the AST's symbols and non-docstring constants, after two drafts of that check went red on a CORRECT tree for matching the word "arbitrage" in a docstring and in a log line; * `price_provider: off` + a `static_profile` resolves to the CONFIGURED product (`origin: "static"`), so `standing.from_feed` is false on every refresh and the guard never latches - driven twice in a row, because a guard that latched there would freeze a static site's plan at its first window for the life of the install. Also: the kept-plan log line said "arbitrage stops with it", which after TARIFF-10 is false on a site that fetches without trading; it now says "arbitrage, where it is armed, stops with it". The keep decision is strictly downstream of `resolve_tariff()`, so the §8.3 carry into price_history - TARIFF-10's whole point - is unaffected either way. All 29 suites green on the merged tree, including TARIFF-10's new test_price.py section 13. All eleven mutations RE-DRIVEN on the merged tree rather than carried over: eleven red, no survivors, every revert fingerprinted. M11 is new - making the guard conditional on `arbitrage.enabled(self.o)` (+86 B) is red on five named checks. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-12 21:31:27 +02:00
glenn schrooyenandClaude Opus 5	7f2c4e20e1	TARIFF-14: the point whose own interval covers the instant ... `_Series.at()` asked `s <= u < s + 1 h` of every point IN LIST ORDER and returned the FIRST match. On the hourly shape every fixture in this repository carried before TARIFF-08 that is right by accident. Belgium moved to a 15-minute MTU on 2025-10-01 and the live day-ahead feed returns 96 points at 900 s, where it is wrong twice over - measured against the shipped code at 5059e28: series: 02:00=0.10 02:15=0.11 02:30=0.12 02:45=0.13 03:00=0.14 ask +15min -> 02:00 0.10 <-- WRONG (wanted 02:15) ask +60min -> 02:15 0.11 <-- WRONG (wanted 03:00) ask +75min -> 02:30 0.12 <-- WRONG (wanted 03:15) Inside the first hour the :00 point wins because its hour has not run out. From the second hour on the answer is not even the top of the hour - the first point still inside its own hour wins - so the error compounds with depth into the series. `arbitrage._act()` tests `here.start == v.cheapest.start` / `== v.dearest.start` to decide whether this interval is the buy one or the sell one. That identity almost never held, so the strategy idled through exactly the interval it exists to trade, and read §8.3's `here.provisional` and §17's `price < 0` off the same wrong point. `static_tariff.py` emits hourly points, so static sites were never affected; this is reachable only down the dynamic path TARIFF-08/09 made work. THE RULE: a point covers from its own start until the next point's start, and never more than one hour. Quarter-hourly takes 900 s, hourly is unchanged, and a MIXED series - FCST-04's carry-forward puts hourly carried points beside quarter-hourly firm ones, spacing [900, 3600] in 70 % of soak samples - takes each point's OWN gap. The one-hour cap is load-bearing: FCST-04 leaves an hour OUT when nothing published it and yesterday has no value, and `at()` raising Absence for it is what sends the caller to the static profile (§11.4). Uncapped, "until the next point's start" would stretch the point before a three-hour hole across the whole hole and answer every instant in it with a stale price. THE LAST POINT is given the same span as the point before it (one hour when it is the only point). A flat one-hour tail would answer 00:30 TOMORROW with today's 23:45 price. The cost - a mixed series ending at the firm/carried seam loses its last 45 minutes to Absence - is argued in DECISIONS/TARIFF-14-the-window-a-point-covers.md §2 rather than buried; the direction is the safe one. `at()` now reads a point's NEIGHBOURS, so it would depend on sortedness. It establishes that itself: the lookup index is sorted by UTC start once, at construction, so no caller's list order reaches it. A series handed its 96 points in reverse answers identically, and that is a check. `covers()` shared the defect exactly - it has no rule of its own, it asks `at()` - and is fixed by the same change; `window()` did not, and its docstring now says why. Nothing about §9.3 or a point's `start` changed. PricePoint still has three fields; the span is derived from the neighbours, never stored. Graded by test_price.py section 13 (900 s, 3600 s, mixed, holes, the tail, caller order, duplicate starts, covers()/window(), the no-data contract) and end to end by test_arbitrage.py section 10, which drives decide() over a 96-point quarter-hourly day whose cheapest and dearest quarters are deliberately NOT on a whole hour, plus §17, §8.3 and the mixed series. Eight mutations, all red, including a ZERO-BYTE one on the tail rule; byte deltas and what the arbitrage file could not see are in the decision note §6. All 29 test files green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-12 21:22:28 +02:00
Claude	c81289527f	TARIFF-12: a returned degradation is not a refresh ... `run_tariff_refresh()` promised in its own docstring that "a failure does not clear the plan", and enforced it with `except Exception` - a branch a supplier outage never reaches. `load_prices()` states the reason in its own words: it "RETURNS, NEVER RAISES, for every failure a site can actually have", because a degradation arriving as a traceback into the planning tick would stop the controller regulating over an expired certificate. So a dead feed RETURNS a §11.4 plan, the `try` succeeds, and the assignment below it overwrote the good plan unconditionally. With `static_profile` unset - the shipped default, and the normal state of a dynamic-tariff site - `_degrade()` returns `TariffPlan(no_data, None, "none")`: a complete 48-hour plan replaced by nothing, at the FIRST failed fetch, ~27 minutes after the last good one. `TARIFF_MAX_AGE_S` (5400 s) never governed anything and there was no serve-stale window at all. Fourth card in one family: FCST-04's M4 (`not ok` only), FCST-05's HIGH (`(JSONDecodeError, OSError)` only), FCST-06 (`not self.ok` only), and now `except Exception` only, for a path that never raises. The question is now asked once, after the attempt, from the evidence that exists - FCST-06's answer, one module over. The evidence is `TariffPlan.from_feed` (did this resolution observe the configured feed) and the shipped `fresh_tariff_plan()`, reused rather than transcribed. A degradation replaces a standing observation only once that observation has aged out, so `TARIFF_MAX_AGE_S` is now the serve-stale window it reads like. A §11.4 static fallback does not replace a fresh provider plan either, although it carries real prices: every point `_degrade()` builds is `provisional=True`, so `firm_points()` is empty, `arbitrage()` refuses and `cheap_now()` is False - everything a consumer may act on is already off - while a day-ahead price for a given hour does not change once published. The rule is deliberately not symmetrical: a standing plan that is itself a degradation IS replaced, or an outage would freeze the operator's static profile at the window it was first generated for. `tariff_at` does not move on a kept plan. It is the moment of the fetch that produced the plan standing, `fresh_tariff_plan()` judges the age from it, and an unmoved timestamp is the only thing that tells a kept plan from a freshly fetched one. test_arbitrage.py section 8b drives the whole chain with nothing stubbed but the socket: the transport raises the way aiohttp does, load_prices() returns no_data, _degrade() builds the §11.4 plan, and the shipped run_tariff_refresh() decides. A check that patched resolve_tariff to RAISE would have passed against the defect. Ten mutations, ten reds, no survivors; 29/29 suites green. Out of scope and unchanged: the persisted price store still does not back the plan during an outage (FCST-03), and the status banner and the Arbitrage row's lag are separately carded. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-12 21:06:45 +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	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	d57122ec74	DATA-02: a real Belgian price year, so AC4 stops being unmeetable ... OPT-04 reported AC4 - "net-positive across 12 months of replayed prices" - as NOT MET and replayed a synthetic year, because scenarios/ held only P1 meter captures. Right call, wrong diagnosis: the criterion was being carried beside a 30-day METER criterion as though both needed waiting. EPEX BE day-ahead is public data, not a capture. It needed a fetch. 8760 hourly points, 2025-09-01 to 2026-09-01 Brussels-local, canonical three fields. Licence checked BEFORE committing: Energy-Charts publishes the BE zone under CC BY 4.0 from Bundesnetzagentur | SMARD.de and other zones under private-use-only terms, so this one is redistributable with attribution. The fetcher refuses to write a file whose per-response license_info stops saying so. Cross-checked against SMARD's own 4996/DE: 96 of 96 quarter-hours, max difference 0.00 EUR/MWh. Raw wholesale, and the file says so. all_in: false, with the markup/tax assumption carried as numbers to APPLY rather than numbers applied - TARIFF-02's trap in data form. Section 7B applies it in one visible place and asserts arithmetically that its additive terms cancel out of every daily spread, so the trade count turns on the VAT multiplier alone; the raw replay is run too, so how much rests on the guess is reported (110 vs 88). DST by construction: iterate in UTC, render through price.brussels(). 2025-10-26 is 25 points, 2026-03-29 is 23, verified by counting per Brussels day rather than asserting 24, and by checking October's 02:00 appears twice at two offsets with two prices while March's never appears. Both bugs the point-and-gap accounting caught were real: a UTC-bounded window made the first day 22 hours, and an inclusive-end off-by-one dropped the last day silently. A day nobody asked for is not a day with no prices. THE RESULT, AT THE SHIPPED DEFAULT, WHATEVER IT IS. At 0.10 widened 1.5x to 0.1500: 110 round trips, +24.88 EUR net of the cycle cost. Unwidened, 173. Nothing tuned - the threshold and the 2.5/1.5 factors are untouched. And what the owner's decision now has under it: the four reports that a static ~0.0840 spread does not clear 0.10 all STAND. What was missing is that a dynamic site clears the widened requirement on 121 of 365 days, median all-in spread 0.1130, so a median day would clear at 0.0754 - 156 trips, +35.42 EUR. Reported, not applied. The synthetic year stays, because the real one cannot grade section 17: not one of 365 days has a negative DEAREST hour, so a zero there counts something that could not happen. 7B asserts that degeneracy rather than reporting the zero. Size measured, not assumed: 893 KB plain but 74.6 KB as a git object against 56.5 KB gzipped. Git already compresses; 18 KB is not worth making the provenance block - the licence claim a reviewer must check - unreadable in a diff. Nothing wired into the add-on; generic_dayahead is still the live path. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 11:01:42 +02:00
glenn schrooyenandClaude Opus 5	2b8b8cb97f	SAFETY-26: pin the negative-price refusal from below, not only from above ... OPT-04's reviewer weakened `if price < 0` to `if price < -0.001` and every suite stayed green while a -0.0005 EUR/kWh sell hour discharged. The shipped code was right the whole time; the CHECK could not tell correct from nearly-correct. The only probe near the boundary sat at 0.0000, which catches a `<=` and says nothing about a tolerance invented on the other side - and a tolerance on the other side is §17's named regression walking through with the suite passing. A dearest hour at -0.0005 is an ordinary Belgian day-ahead print, not a fuzz value. `app/` IS NOT TOUCHED. `if price < 0` is already correct and changing it would be the defect; this card closes the check, not the behaviour. The 0.0000 probe stays and is now labelled as the half that pins the boundary from above. The new probe is a SWEEP rather than a point, because one probe at -0.0005 closes `-0.001` and nothing else - a mutation reaching for `-0.01` would be the identical defect one decimal further out. Five prices span four orders of magnitude down to -0.000001, the last place the canonical six-decimal format can express; each is asserted to survive that rounding as strictly negative, to still be the DEAREST hour, and to still clear the widened threshold, so §17 is the only rung that can refuse. The same five magnitudes with the sign flipped all discharge, so this is a boundary at exactly zero rather than a refusal of small numbers. AC4, the look: every price/quantity boundary in arbitrage.py and static_tariff.py was given the same tolerance mutation, both directions where both exist. Two survive, both in static_tariff.py and both NAMED RATHER THAN FIXED - they are TARIFF-03's rungs and want probes in its own file. `spread == 0.0` loosened to `<= 0.001` flips a real 0.0005 spread from allowed to refused at min_spread_eur_kwh=0.0, a documented supported value, and otherwise prints a false reason about a tariff that is not flat. `len(firm) < 2` loosened to `< 1` survives at +0 bytes - TEST-15's risky delta - and is masked only by the flat rung, so the two mask each other and a later edit to either opens a hole nothing reports. Mutation verified under `python -B` with a recursive __pycache__ purge, byte delta printed (+5 B), the mutated line asserted changed, and - per the reviewer's addition to TEST-15 - the tree re-read from disk and asserted to be the tree that was mutated before each run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 02:07:56 +02:00
glenn schrooyenandClaude Opus 5	bdd7f18a54	OPT-04: charge cheap, discharge expensive - and only when it pays ... Four cards built the price stack and nothing traded on it. app/arbitrage.py is §10.1's priority 3, and it consumes all four rather than re-deciding anything: whether a trade is permitted at all, on which two hours, against which widened threshold is TariffPlan.arbitrage()'s answer, and that answer cannot be obtained without first saying whether the peak guard is holding. §9.1's "peak shaving outranks arbitrage" is therefore honoured structurally - there is no path to a spread that skips the question - and again in the arbiter, where P_PEAK (50) clamps a claim filed at P_ARBITRAGE (30). A guard that never ran is not a guard that is clear. On meter_source off the peak guard is never evaluated; that third state is carried as None and refuses, because charging at the rail creates the billed quantity while nothing measures the quarter. validate.py refuses that configuration too, along with arbitrage armed with no price source and a SoC floor at or above the ceiling. §17: never export into a negative price. The guard is on the hour being sold into, not on the spread - a day priced -0.30 .. -0.05 clears any threshold and its dearest hour is still negative. Buying in a negative hour stays allowed. resolve_tariff() may open an HTTPS connection and the tick feeds the ESP32 heartbeat, so the fetch runs in its own task at a 30 min cadence and the tick reads an attribute and an age bound. test_arbitrage.py section 8 asserts that structurally on the shipped AST: a fetch put back on cycle() is red. AC4 is NOT met and is not restated - this repository holds no price history. Section 7 replays a synthetic year and asserts the property that does not need real prices: every executed round trip cleared its own widened requirement, and zero discharges landed in the 522 negative-priced hours. At the shipped 0.10 EUR/kWh threshold a realistic Belgian day/night site does not trade at all. Reported, not tuned: that number and FCST-03's widening factors are one product decision and it is the owner's. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015VXjA3LWccN1rJsk3okyPC	2026-08-31 01:36:09 +02:00