Bumps 0.8.0 -> 0.9.0 so the five runtime commits behind it can actually ship. ha apps update against an unchanged version installs nothing and reports success.
Minor for new functionality, NOT for a break — and that was checked
PKG-07 was minor because a config that started on 0.7.0 could be refused on 0.8.0. Nothing of that kind is true here:
options: and schema: hold 71 top-level keys on both 06661c5 and HEAD. The one schema addition is a per-entry key, capacity_kwh: float(0.1,200)? — the trailing ? makes it optional.
An unmodified 0.8.0-era config validates clean on 0.9.0 — measured through the shipped validator on the flat single-inverter shape the reference install runs and an N=2 roster with no capacity_kwh: 0 problems each.
OPT-09's two new refusals fire only on configs that use the new key. Neither can reach a config written before the key existed.
PKG-07's first draft justified its bump with an invented compatibility break and review caught it. This one states what was measured.
Contents since 0.8.0
3d29993 UX-02 · fdb3b69 OPT-09 · fcaa724 PKG-09
The changelog carries OPT-09's disclosed N=2 detection regression (a wedged unit goes from named on 199/200 cycles to 0/200; N=1 unaffected, closure is SAFETY-43) and points at PKG-09's pre-deploy check.
⚠️ Third recurrence in three days
PKG-06 six merges, PKG-07 six, this one five — and this time PKG-09's own tool caught it during PKG-09's review, not a person. PKG-10 carries the post-merge alarm.
⚠️ Still not done, and not doable from here
The live options have not been checked against this version's validator. The gate reports exit 2 — NOT CLEARED rather than clearing, which is correct. Export the options and re-run before ha apps update.
Bumps `0.8.0` -> `0.9.0` so the five runtime commits behind it can actually ship. `ha apps update` against an unchanged version installs nothing and reports success.
## Minor for new functionality, NOT for a break — and that was checked
PKG-07 was minor because a config that started on 0.7.0 could be **refused** on 0.8.0. Nothing of that kind is true here:
- `options:` and `schema:` hold **71 top-level keys** on both `06661c5` and HEAD. The one schema addition is a per-entry key, `capacity_kwh: float(0.1,200)?` — **the trailing `?` makes it optional**.
- An unmodified 0.8.0-era config validates clean on 0.9.0 — measured through the shipped validator on the flat single-inverter shape the reference install runs *and* an N=2 roster with no `capacity_kwh`: **0 problems each**.
- OPT-09's two new refusals fire only on configs that **use** the new key. Neither can reach a config written before the key existed.
PKG-07's first draft justified its bump with an invented compatibility break and review caught it. This one states what was measured.
## Contents since 0.8.0
`3d29993` UX-02 · `fdb3b69` OPT-09 · `fcaa724` PKG-09
The changelog carries OPT-09's **disclosed N=2 detection regression** (a wedged unit goes from named on 199/200 cycles to 0/200; N=1 unaffected, closure is SAFETY-43) and points at PKG-09's pre-deploy check.
## ⚠️ Third recurrence in three days
PKG-06 six merges, PKG-07 six, this one five — and this time **PKG-09's own tool caught it during PKG-09's review**, not a person. PKG-10 carries the post-merge alarm.
## ⚠️ Still not done, and not doable from here
The live options have not been checked against this version's validator. The gate reports **exit 2 — NOT CLEARED** rather than clearing, which is correct. Export the options and re-run before `ha apps update`.
Suite: **26 files, all pass**.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
⚠️ MINOR FOR NEW FUNCTIONALITY, NOT FOR A BREAK, AND THAT DISTINCTION IS
CHECKED RATHER THAN ASSERTED. PKG-07 was minor because a config that started on
0.7.0 could be REFUSED on 0.8.0. Nothing of that kind is true here:
- `options:` and `schema:` hold 71 top-level keys on both 06661c5 and HEAD.
The one schema addition is a PER-ENTRY key, `capacity_kwh: float(0.1,200)?`,
and the trailing `?` makes it OPTIONAL.
- An unmodified 0.8.0-era config validates clean on 0.9.0. Measured through
the shipped validator on both the flat single-inverter shape the reference
install runs and an N=2 roster with no `capacity_kwh` on any entry: 0
problems each.
- OPT-09's two new refusals fire only on configs that USE the new key - an
unparseable value, or the key stated on one entry and left empty on another.
Neither can reach a config written before the key existed.
PKG-07's first draft justified its bump with an invented compatibility break and
review caught it. This one states what was measured, and the measurement says
existing installs upgrade untouched.
Contents since 0.8.0 (`06661c5`): UX-02 (`3d29993`), OPT-09 (`fdb3b69`),
PKG-09 (`fcaa724`).
⚠️ THE VERSION WENT UNBUMPED FOR THE THIRD TIME IN THREE DAYS - PKG-06 six
merges, PKG-07 six, this one five - and this time PKG-09's own tool caught it
during PKG-09's review rather than a person. The changelog carries OPT-09's
disclosed N=2 detection regression and points at the pre-deploy check.
⚠️ STILL NOT DONE, AND STILL NOT DOABLE FROM HERE: the live options have not
been checked against this version's validator. The gate reports exit 2 - NOT
CLEARED - rather than clearing, which is correct. Export the options from the
Supervisor and re-run before `ha apps update`.
Suite: 26 files, all pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
Review approved the bump and, in doing so, dated one of its own paragraphs.
When this section was written the pre-deploy check had not been run and the
changelog said so, correctly. The owner then exported the reference install's
options and the check cleared, which makes the shipped sentence false in the
release notes an operator reads at the hardware.
Replaced with what was measured, twice:
stored blob as-is exit 0, CLEARED
effective post-upgrade config exit 0, CLEARED
(the 70 stored keys merged OVER 0.9.0's
71 config.yaml defaults)
max_w 5000, slew_w 400, rule-10 ceiling 555.6 W.
⚠️ AND THE SECOND CHECK IS NOT CEREMONY. The stored blob has 70 keys, not 71:
`delivery_hold_s` arrived with SAFETY-42 in 0.8.0, so a box running 0.7.0 has
never stored it, and it is REQUIRED in the schema with no trailing `?` - the
exact shape that becomes exit 78. It resolves to its `options:` default of 185
because the Supervisor sets `App.options = deepmerge(defaults, stored)`, which
`tools/supervisor_selfapi_probe.py` §D pins against a real Supervisor image.
Review re-derived that independently rather than taking the reasoning on trust.
"Your saved settings are valid" and "what the box will actually run is valid"
are different questions, and only the second one is the one being asked before
a deploy.
Suite: 26 files, all pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
admin
merged commit d0633665c9 into release/1.02026-09-07 00:53:45 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Bumps
0.8.0->0.9.0so the five runtime commits behind it can actually ship.ha apps updateagainst an unchanged version installs nothing and reports success.Minor for new functionality, NOT for a break — and that was checked
PKG-07 was minor because a config that started on 0.7.0 could be refused on 0.8.0. Nothing of that kind is true here:
options:andschema:hold 71 top-level keys on both06661c5and HEAD. The one schema addition is a per-entry key,capacity_kwh: float(0.1,200)?— the trailing?makes it optional.capacity_kwh: 0 problems each.PKG-07's first draft justified its bump with an invented compatibility break and review caught it. This one states what was measured.
Contents since 0.8.0
3d29993UX-02 ·fdb3b69OPT-09 ·fcaa724PKG-09The changelog carries OPT-09's disclosed N=2 detection regression (a wedged unit goes from named on 199/200 cycles to 0/200; N=1 unaffected, closure is SAFETY-43) and points at PKG-09's pre-deploy check.
⚠️ Third recurrence in three days
PKG-06 six merges, PKG-07 six, this one five — and this time PKG-09's own tool caught it during PKG-09's review, not a person. PKG-10 carries the post-merge alarm.
⚠️ Still not done, and not doable from here
The live options have not been checked against this version's validator. The gate reports exit 2 — NOT CLEARED rather than clearing, which is correct. Export the options and re-run before
ha apps update.Suite: 26 files, all pass.
🤖 Generated with Claude Code
https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU
Review approved the bump and, in doing so, dated one of its own paragraphs. When this section was written the pre-deploy check had not been run and the changelog said so, correctly. The owner then exported the reference install's options and the check cleared, which makes the shipped sentence false in the release notes an operator reads at the hardware. Replaced with what was measured, twice: stored blob as-is exit 0, CLEARED effective post-upgrade config exit 0, CLEARED (the 70 stored keys merged OVER 0.9.0's 71 config.yaml defaults) max_w 5000, slew_w 400, rule-10 ceiling 555.6 W. ⚠️ AND THE SECOND CHECK IS NOT CEREMONY. The stored blob has 70 keys, not 71: `delivery_hold_s` arrived with SAFETY-42 in 0.8.0, so a box running 0.7.0 has never stored it, and it is REQUIRED in the schema with no trailing `?` - the exact shape that becomes exit 78. It resolves to its `options:` default of 185 because the Supervisor sets `App.options = deepmerge(defaults, stored)`, which `tools/supervisor_selfapi_probe.py` §D pins against a real Supervisor image. Review re-derived that independently rather than taking the reasoning on trust. "Your saved settings are valid" and "what the box will actually run is valid" are different questions, and only the second one is the one being asked before a deploy. Suite: 26 files, all pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU