3 Commits

Include renames

Author	SHA1	Message	Date
adminandClaude Opus 5	cb3f686555	PKG-14: cut 0.10.0, and say what an upgrade from 0.7.0 crosses ... `config.yaml` 0.9.0 -> 0.10.0, and the top `## Unreleased` block is closed into `## 0.10.0` with a preamble that names the backward-incompatible changes and who they reach. MINOR, and NOT because eighteen tickets landed. A stored options blob the previous version started on is REFUSED on this one: * TARIFF-07 retires three `price_provider` ids; a site set to one is refused BY NAME at startup. Measured on the reference blob, with a control on an accepted id so the refusals are about the ID. * TARIFF-18 moves `price_taxes_eur_kwh` 0.06 -> 0.11736. A site that STORED 0.06 is untouched, and - the non-obvious half - a taxes period table beside that stored 0.06 does NOT become a startup refusal on upgrade, because `SUPERSEDED_TAXES_DEFAULTS_EUR_KWH` reads it as untouched. Measured, with the counterfactual that the rung is not weakened (ORES's 0.1198 is still refused). * SAFETY-10 adds `shadow_mode`, shipped `auto`. An existing CONTROLLING install does not change by one watt and a FRESH one comes up observing. Measured cross-revision, 8f82dd4 -> e6da478, same stimulus through the shipped `Controller.cycle()`: byte-identical write streams, 13/13/25 writes. Positive control: the same driver at `shadow_mode: on` gets 13 writes to 5000 W on the older tree and one 0 W write on the newer. And the one a reader of the newest section alone would miss: `ha addons update` does not walk the versions, so a 0.7.0 install meets 0.8.0's and 0.9.0's rules at the same moment as 0.10.0's. Of those, SAFETY-39's rule 10 refuses 0.7.0's OWN shipped default `slew_w: 1000` against a 555.6 W ceiling on a 5000 W rail. Measured red on this tree; the reference install's `slew_w: 400` is measured green. SCOPE, and it is drawn honestly rather than tidily. The top block's 18 entries all merged after the 0.9.0 bump `86bdf49`, so the block is closed as-is and its `_this branch_` placeholders are resolved to merge shas. ⚠️ 0.10.0 SHIPS THREE MORE RUNTIME TICKETS THAT ARE NOT IN THAT TABLE - SAFETY-43, TEST-21 and SAFETY-44 - and they are NAMED in the preamble rather than moved, because re-filing this file's misplaced entries is PKG-08. SAFETY-44 (`app/main.py`, `app/store.py`) is in the changelog nowhere at all; that is said in both places. The second `## Unreleased` block below `## 0.9.0` is ANNOTATED, not rewritten or emptied - UX-02 in it shipped in 0.9.0, the other three in 0.10.0. No released section is rewritten. `test_version_gate.py` gains part 11: the bump and the closed section are one act. PKG-09 refuses a deploy whose version did not move; nothing graded the mirror failure, in which the version moves and the block is never closed. Two sides from two files, a slicer with a synthetic positive control run on every invocation, the retired ids read off `app/price.py` by AST rather than transcribed, and the count of still-misfiled blocks frozen so it can only shrink. Mutations, all purged, tree bind-mounted :ro, backups at mktemp paths and the revert fingerprinted: M1 `## 0.10.0` -> `## Unreleased` +4 B RED 2 M2 version 0.10.0 -> 0.10.1 +0 B RED 1 (ZERO-BYTE) M3 an id stripped from the NEWEST +10 B RED 1 section only, left below M4 a 4th retired provider in price.py +62 B RED 1 here, 4 in test_price.py M5 `## 0.9.0` heading lost -3 B RED 1 M6 a 2nd `## Unreleased` left standing +27 B RED 1 M7 the slicer never closes -32 B RED 3 M8 SUPERSEDED_TAXES... emptied -5 B RED 2 on the evidence instrument, plus test_validate/test_price ⚠️ M5 WAS A SURVIVOR ON THE FIRST DRAFT. The slicer control was a sentinel (`## 0.8.0`) that only a slicer running to EOF could reach, and deleting one heading never gets there - ARCH-02's fifteenth instance, in a fresh costume. 11a now asserts the invariant instead: exactly one contents table per section, which is what a lost heading breaks. 29/29 test files green. `tools/predeploy_check.py --deployed-version 0.7.0 --options <live blob>` CLEARED, exit 0, before and after. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-16 02:48:27 +02:00
glenn schrooyenandClaude Opus 5	0b653c35a6	PKG-13: the no-op half of the pre-deploy check has never run as documented ... ⚠️ THE INVOCATION ON PKG-09's CARD AND IN THE TOOL'S OWN DOCSTRING RUNS ONLY HALF THE CHECK. The container runs as uid 0 against a checkout owned by the operator, and git refuses that: fatal: detected dubious ownership in repository at '/w/goodwe-addon' `_git` returned non-zero, `last_version_change()` returned None, and the silent-no-op check - THE REASON PKG-09 EXISTS - reported SKIPPED. Measured, on the documented command against release/1.0: ⚠️ SKIPPED: could not ask git what changed since the last bump; the no-op check is INCONCLUSIVE, not clean NOT CLEARED and with `--user $(id -u):$(id -g)`, unchanged otherwise: no runtime change since the last bump - nothing to deploy CLEARED for deploy. ⚠️ THE TWO HALVES WERE MUTUALLY EXCLUSIVE ACROSS THE TWO DOCUMENTED ENVIRONMENTS. In the container the validator ran and git skipped; on a bare host git ran and the validator skipped on aiohttp. NEITHER DOCUMENTED COMMAND RAN BOTH. The pre-0.9.0 clearance was sound only because it happened to be driven as two separate invocations. ⚠️ AND IT WAS INVISIBLE IN THE ONLY CASE ANYONE HAD RUN. `main()` consults the git result only when `shipped == deployed`; every real run so far compared 0.7.0 against 0.9.0 and printed its verdict without ever needing git. FIXED IN `_git()` WITH `safe.directory`, NOT BY DOCUMENTING `--user`. The tool should be correct however it is invoked rather than requiring every future caller to remember a flag; the read is read-only, on a repository the operator is about to deploy from. ⚠️ WHY THE TESTS COULD NOT SEE IT, WHICH IS THE FINDING BEHIND THE FINDING. `test_version_gate.py` invokes the gate with `sys.executable` against fixtures it creates as its own uid, so no fixture could ever meet an ownership mismatch. MUTATION.md habit 4 in a fourth shape, inside the file written to prevent it - after the pickaxe bug, after the one-bump history, after the filter-only survivor. Two fixtures added: - a directory that is NOT a git repository, so the lookup genuinely fails: the gate must exit 2 saying INCONCLUSIVE and must NOT say CLEARED. - ⚠️ THE EXIT CODES PINNED BY VALUE, NOT BY TRUTHINESS. `returncode != 0` is satisfied by collapsing NOT-CLEARED into REFUSED, which review found the earlier draft could not tell apart. 1 says "this deploy is wrong"; 2 says "nobody checked". Driven: collapsing 2 into 1 now goes red on exactly that check. Suite: 26 files, all pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-07 17:02:01 +02:00
glenn schrooyenandClaude Opus 5	04b3330def	PKG-09: refuse a deploy that would be a no-op, or that the add-on would reject ... Two ways a deploy of this add-on has gone wrong, and the Supervisor reports both as success. THE SILENT NO-OP. The Supervisor keys the built image by `version:`, so `ha apps update` against an unchanged version installs nothing and says it worked. PKG-06 recorded this on 2026-09-05 with six merges behind an unbumped version; PKG-07 recorded it again on 2026-09-06 with six. Both times a human noticed. Nothing else was going to. THE REFUSED CONFIG. A config the shipped validator rejects is SystemExit(78) - the add-on does not start. ⚠️ AND THE INGRESS PANEL GOES WITH IT, because the add-on serving it is not running, so recovery means the Supervisor UI. ⚠️ IT CAUGHT A LIVE ONE ON ITS OWN PULL REQUEST. Run against release/1.0 while this branch was in review: version 0.8.0 on both sides with UX-02's and OPT-09's runtime commits already merged behind it. The class this exists to catch had recurred, the same day, unnoticed - which is the argument for PKG-10, a non-required post-merge check, since this script only helps someone who remembers to run it. ⚠️ THE FIRST VERSION WAS BROKEN ON EVERY REAL REPOSITORY AND ITS TESTS COULD NOT SEE IT. The "when did the version last change" lookup was `git log -S`, the pickaxe, which finds commits that change the COUNT of a literal string. A bump edits the line IN PLACE, so the count never moves and it returned only the commit that first INTRODUCED the line. Measured here: -S -> 0a1e61d 2026-08-23 Packaged as a Home Assistant add-on -G -> 06661c5 2026-09-06 PKG-07: bump 0.7.0 -> 0.8.0 so a correctly bumped tree was reported as 87 COMMITS BEHIND AN UNBUMPED VERSION, PKG-06's and PKG-07's own bump commits among the offenders. A tool whose whole purpose is to be trusted cried wolf on every run. ⚠️ AND `-G` IS NOT THE FIX EITHER, ONLY A BETTER FILTER - it matches a reformat, a quote change, a comment moved onto the line. `-G` narrows the candidates and the VALUE is then compared against the parent's. ⚠️ THREE DISTINCT SHAPES OF HABIT 4 IN ONE FILE, each found by a different means, which is the honest record of how this landed: 1. Fixtures built fresh repositories whose version line is introduced once and never edited - the one shape in which `-S` looks correct. Found by review. Answered with a three-state history; the old lookup goes red on 4 checks. 2. That three-state history still could not tell "value-compared" from "filtered-only": review swapped in `-G`'s newest raw hit and THE WHOLE SUITE STAYED GREEN, so the docstring's central claim was pinned by nothing. Answered with a cosmetic touch of the version line - `-G` matches it, the value comparison does not. That mutant now goes red on 3 checks. 3. The counts below were claimed fixed and two of them had not landed at all. Two git shapes it still gets wrong are recorded in the docstring rather than fixed - a bump resolved inside a merge commit (false refusal) and a bump reverted while the work is kept (false clearance, the dangerous direction). Neither has ever occurred here; both were constructed in review. Card PKG-11. ⚠️ AND THE PROSE COUNTS, WHICH I REPORTED AS FIXED WHEN THEY WERE NOT. Round 1 found "PKG-06 ... four merges" (its own commit message says six) and "recorded eleven times" (MUTATION.md:550 says TWELFTH). I replaced them without asserting the replacement matched, said "all applied", and round 2 found both still in the tree - one fixed in DOCS.md but not in the script, one not fixed anywhere. A claim that a correction landed is itself a claim that needs checking, and this is PROC-01's tenth instance. WHAT IT DOES NOT DO. It does not read the live box: the options blob needs the Supervisor API. Without --options the validator half SKIPS - loudly, exit 2 - and never pretends. On a bare host `app/validate.py` needs aiohttp, so that half skips too and names the container to re-run in. A missing or malformed --options file is a REFUSAL with a sentence, not a traceback. EXIT CODES: 0 cleared, 1 REFUSED, 2 NOT CLEARED. ⚠️ 2 IS NOT A PASS. Suite: 26 files, all pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU	2026-09-06 23:57:51 +02:00