2 Commits

Author	SHA1	Message	Date
kuhy	5d0c4d0e3a	Cap --restore at 23:00 so it is a reward, not an off switch ... --restore exists so the workout bonus can push shutdown later, and it had no upper bound at all: `sudo adjust_shutdown_schedule.sh --restore 24 24 0` from any shell undid the entire ratchet, with nothing written down. It is now clamped to a ceiling and every restore is recorded. Clamped rather than refused, so the reward path keeps working: the bonus asks for up to 24 and simply lands on 23. Ceiling chosen by kuhy as today's earned state -- base is 21, live was 23. Two corrections to the previous commit, both found by reading the callers: - It tightened validation from 0-24 to 0-23 on the grounds that the error message said 0-23. That was backwards. 24 is a real, documented value: _adjust_shutdown_time_by caps at 24 to mean midnight, and day-specific-shutdown-check.sh catches it through the morning-window condition. The message was what was wrong, so the message is what changed. - The audit line does NOT go in /etc/shutdown-schedule-overrides.conf, which was the original plan. That file is parsed by day-specific-shutdown-check.sh as start|end|created|reason, and a line covering the current time makes it exit 0 and SKIP the shutdown. An audit trail written there would have suppressed the very curfew it documented. It goes to /var/log/shutdown-restore.log, and a test asserts the conf stays empty. The log write says so on stderr when it fails, per this repo's no-silent- failures rule; it is not fatal, because refusing an earned reward over an unwritable log file would be the worse failure. 29 shell cases and 1146 python tests pass. Verified in a vmbox sandbox as root against a real /etc and a real chattr: 24 clamps to 23 and is logged, the overrides conf is untouched, and 25 is still refused. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B5jMviyk15MKw1PqW1pzKr	2026-08-28 19:59:43 +02:00
kuhy	2bc31cf587	Ratchet MORNING_END_HOUR, in the direction it actually runs ... adjust_shutdown_schedule.sh compared only $1 and $2, so the third value passed through unchecked in both directions: the morning shutdown window could be shortened at will while the two evening hours were guarded. The fix is not the obvious one. day-specific-shutdown-check.sh shuts down while the clock is BELOW morning_end_minutes, so a LARGER MORNING_END_HOUR means a longer shutdown window -- stricter. Copying the evening hours' `-gt` comparison would have ratcheted it backwards and blessed exactly the loosening it was meant to stop. The guard is `-lt`, and the inversion is now stated in the header rather than left to be rediscovered. Two smaller fixes in the same path: validation accepted 24 while its own error message said 0-23, and the config is now unset before being sourced so an unreadable file falls back to the documented loosest defaults instead of inheriting whatever those names last held. --restore is deliberately unchanged. It looks like a bypass, and it is one, but it is load-bearing: shutdown_base.json says 21 while the live config is 23, because the workout reward pushes the schedule later THROUGH --restore. Bounding it at the base -- as was originally proposed -- would have capped the reward at 21 and broken a daily flow. Bounding it needs a policy ceiling, which is a decision, not a refactor. The script is now sourceable, with the config path overridable, so the ratchet has tests at all: 20 cases covering both directions, the source-clobber trap, and the missing/unreadable config fallbacks. A ratchet with no test is how the $3 gap survived for months. Verified in a vmbox sandbox as root against a real /etc and a real chattr (the immutable flag genuinely applied, which a tmpfs cannot do): a stricter write lands, a looser evening hour is refused, a shortened morning window is refused with the reason, and --restore still loosens. Not exercised against the host's own /etc/shutdown-schedule.conf, deliberately. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01B5jMviyk15MKw1PqW1pzKr	2026-08-28 19:28:06 +02:00