TEST-10: max_w and LIVE_MAX_W are unpinned beside the key TEST-06 pinned
TEST-06 pinned meter_freeze_s; the keys either side, max_w and the LIVE_MAX_W literal beside it, were not. Measured survivors before this
fix: max_w: 2000 -> 4500 in config.yaml left every check in test_freeze.py and test_tariff.py GREEN, and LIVE_MAX_W = 5000.0
was a bare literal silently disagreeing with the shipped max_w (2000)
with nothing saying so. For contrast, deadband_w: 15 -> 5 already went
RED 2 + 1, so the technique works where it's applied.
What changed
AC 1 - test_freeze.py gained a check comparing Tuning()'s code
default (control.py, 2000.0) against SHIPPED_MAX_W, read from config.yaml by extending the existing _cfg_default() regex reader.
AC 2 - LIVE_MAX_W renamed LIVE_INSTALL_MAX_W in both files,
each with a comment stating plainly it's the live install's own
override (5000), not config.yaml's shipped max_w (2000).
AC 3 - PINNED_KEYS = ("meter_freeze_s", "deadband_w", "max_w")
added to test_freeze.py as the single statement of which config keys
this suite pins. maintenance_* deliberately excluded - CFG-03
already gave those a single source of truth in app/maintenance.py.
AC 4 - verified by breaking what the new check watches: bumping max_w 2000 -> 4500 in config.yaml fails exactly one new check
("the code default and the shipped default agree on max_w too") and
nothing else in either file; reverting returns both to all-green.
Base branch note
This branch was rebased onto release/1.0 after CFG-03 (#34) merged.
Nothing this ticket touches (meter_freeze_s, deadband_w, max_w)
overlaps CFG-03's maintenance_* changes; the merge was a clean
fast-forward.
Verification
Full 17-file suite green under goodwe-addon-ci after the merge.
CHANGELOG.md updated under Unreleased.
## TEST-10: max_w and LIVE_MAX_W are unpinned beside the key TEST-06 pinned
TEST-06 pinned `meter_freeze_s`; the keys either side, `max_w` and the
`LIVE_MAX_W` literal beside it, were not. Measured survivors before this
fix: `max_w: 2000 -> 4500` in `config.yaml` left every check in
`test_freeze.py` and `test_tariff.py` GREEN, and `LIVE_MAX_W = 5000.0`
was a bare literal silently disagreeing with the shipped `max_w` (2000)
with nothing saying so. For contrast, `deadband_w: 15 -> 5` already went
RED 2 + 1, so the technique works where it's applied.
### What changed
1. **AC 1** - `test_freeze.py` gained a check comparing `Tuning()`'s code
default (`control.py`, 2000.0) against `SHIPPED_MAX_W`, read from
`config.yaml` by extending the existing `_cfg_default()` regex reader.
2. **AC 2** - `LIVE_MAX_W` renamed `LIVE_INSTALL_MAX_W` in both files,
each with a comment stating plainly it's the live install's own
override (5000), not config.yaml's shipped `max_w` (2000).
3. **AC 3** - `PINNED_KEYS = ("meter_freeze_s", "deadband_w", "max_w")`
added to test_freeze.py as the single statement of which config keys
this suite pins. `maintenance_*` deliberately excluded - CFG-03
already gave those a single source of truth in `app/maintenance.py`.
4. **AC 4** - verified by breaking what the new check watches: bumping
`max_w` 2000 -> 4500 in `config.yaml` fails exactly one new check
("the code default and the shipped default agree on max_w too") and
nothing else in either file; reverting returns both to all-green.
### Base branch note
This branch was rebased onto `release/1.0` after CFG-03 (#34) merged.
Nothing this ticket touches (`meter_freeze_s`, `deadband_w`, `max_w`)
overlaps CFG-03's `maintenance_*` changes; the merge was a clean
fast-forward.
### Verification
Full 17-file suite green under `goodwe-addon-ci` after the merge.
CHANGELOG.md updated under Unreleased.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
max_w and the LIVE_MAX_W literal beside it were the two survivors left
after TEST-06 pinned meter_freeze_s: changing max_w 2000 -> 4500 in
config.yaml passed every check in test_freeze.py and test_tariff.py
GREEN, and LIVE_MAX_W = 5000.0 was a bare literal that silently
disagreed with the shipped max_w (2000) with nothing in the file
saying so. For contrast, deadband_w 15 -> 5 already went RED 2 + 1,
so the pinning technique was known to work - it just was not applied
to the key either side of it.
Three changes, each measured:
1. test_freeze.py gains a check comparing Tuning()'s code default
(control.py, 2000.0) against SHIPPED_MAX_W, read from config.yaml
by extending the file's existing _cfg_default() regex reader
rather than reimplementing test_arbitrage.py's _shipped. Broken
and confirmed red: max_w: 2000 -> 4500 in config.yaml now fails
exactly "the code default and the shipped default agree on max_w
too" and nothing else in either file; reverting returns both files
to all-green. (AC 1, AC 4)
2. LIVE_MAX_W is renamed LIVE_INSTALL_MAX_W in both test_freeze.py
and test_tariff.py, each with a comment stating plainly that 5000
is the live install's own override, not config.yaml's shipped
max_w (2000) - the defect was a literal that could be misread as
the shipped default, not the number itself. (AC 2)
3. test_freeze.py states PINNED_KEYS = ("meter_freeze_s", "deadband_w",
"max_w") in one place as the complete set of config keys this
suite pins. Deliberately excludes maintenance_* - CFG-03 (merged
into release/1.0 since this branch started, merged in here) gave
those keys a separate single source of truth in app/maintenance.py
and this ticket has no reason to duplicate that pin. Not every key
in config.yaml is pinned here on purpose: meter_freeze_s,
deadband_w and max_w are the three this file's mutual-exclusion
arithmetic (section 2b) actually reasons about together. (AC 3)
Full 17-file suite run green under goodwe-addon-ci after the merge
with release/1.0 (f630ed9, CFG-03). CHANGELOG.md updated under
Unreleased.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
admin
merged commit e8fb596b99 into release/1.02026-09-01 07:00:03 +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.
TEST-10: max_w and LIVE_MAX_W are unpinned beside the key TEST-06 pinned
TEST-06 pinned
meter_freeze_s; the keys either side,max_wand theLIVE_MAX_Wliteral beside it, were not. Measured survivors before thisfix:
max_w: 2000 -> 4500inconfig.yamlleft every check intest_freeze.pyandtest_tariff.pyGREEN, andLIVE_MAX_W = 5000.0was a bare literal silently disagreeing with the shipped
max_w(2000)with nothing saying so. For contrast,
deadband_w: 15 -> 5already wentRED 2 + 1, so the technique works where it's applied.
What changed
test_freeze.pygained a check comparingTuning()'s codedefault (
control.py, 2000.0) againstSHIPPED_MAX_W, read fromconfig.yamlby extending the existing_cfg_default()regex reader.LIVE_MAX_WrenamedLIVE_INSTALL_MAX_Win both files,each with a comment stating plainly it's the live install's own
override (5000), not config.yaml's shipped
max_w(2000).PINNED_KEYS = ("meter_freeze_s", "deadband_w", "max_w")added to test_freeze.py as the single statement of which config keys
this suite pins.
maintenance_*deliberately excluded - CFG-03already gave those a single source of truth in
app/maintenance.py.max_w2000 -> 4500 inconfig.yamlfails exactly one new check("the code default and the shipped default agree on max_w too") and
nothing else in either file; reverting returns both to all-green.
Base branch note
This branch was rebased onto
release/1.0after CFG-03 (#34) merged.Nothing this ticket touches (
meter_freeze_s,deadband_w,max_w)overlaps CFG-03's
maintenance_*changes; the merge was a cleanfast-forward.
Verification
Full 17-file suite green under
goodwe-addon-ciafter the merge.CHANGELOG.md updated under Unreleased.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
max_w and the LIVE_MAX_W literal beside it were the two survivors left after TEST-06 pinned meter_freeze_s: changing max_w 2000 -> 4500 in config.yaml passed every check in test_freeze.py and test_tariff.py GREEN, and LIVE_MAX_W = 5000.0 was a bare literal that silently disagreed with the shipped max_w (2000) with nothing in the file saying so. For contrast, deadband_w 15 -> 5 already went RED 2 + 1, so the pinning technique was known to work - it just was not applied to the key either side of it. Three changes, each measured: 1. test_freeze.py gains a check comparing Tuning()'s code default (control.py, 2000.0) against SHIPPED_MAX_W, read from config.yaml by extending the file's existing _cfg_default() regex reader rather than reimplementing test_arbitrage.py's _shipped. Broken and confirmed red: max_w: 2000 -> 4500 in config.yaml now fails exactly "the code default and the shipped default agree on max_w too" and nothing else in either file; reverting returns both files to all-green. (AC 1, AC 4) 2. LIVE_MAX_W is renamed LIVE_INSTALL_MAX_W in both test_freeze.py and test_tariff.py, each with a comment stating plainly that 5000 is the live install's own override, not config.yaml's shipped max_w (2000) - the defect was a literal that could be misread as the shipped default, not the number itself. (AC 2) 3. test_freeze.py states PINNED_KEYS = ("meter_freeze_s", "deadband_w", "max_w") in one place as the complete set of config keys this suite pins. Deliberately excludes maintenance_* - CFG-03 (merged into release/1.0 since this branch started, merged in here) gave those keys a separate single source of truth in app/maintenance.py and this ticket has no reason to duplicate that pin. Not every key in config.yaml is pinned here on purpose: meter_freeze_s, deadband_w and max_w are the three this file's mutual-exclusion arithmetic (section 2b) actually reasons about together. (AC 3) Full 17-file suite run green under goodwe-addon-ci after the merge with release/1.0 (f630ed9, CFG-03). CHANGELOG.md updated under Unreleased. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>