Pass 2 of the pre-release audit, continued. #479, #310/#311 and #309 each pass the revert check with existing guards -- reverting them fails 3, 1 and 1 test respectively. #302 does not: deleting the DST end-time cap in _groups_to_tou_intervals leaves all 1714 fast tests green. What Frank-Leysen reported was a runtime 500 from HA's select_option while setting tou_time_1_end. The DST fall-back day has 25 hours, so the schedule carries 100 quarterly periods and the final one converts to hour 24 -- a time no TOU register can hold. Measured on today's code with the cap removed, the interval is emitted as "24:59". So the fix works and has worked since #314, but it had no guard at all: a future refactor of the interval builder could drop it and every suite would stay green until the next DST changeover put it in front of a user. That is the exact failure mode this audit exists to find, and it is the first one found on the TOU side rather than VPP. Asserts the emitted interval's start_time/end_time are valid wall-clock values, i.e. what actually reaches hardware, rather than asserting the capping branch was taken. Verified discriminating: removing the cap fails it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SYRyY3MYjN4dnFEWnxbGyW

Wrote tou while running vpp #310

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions