screen-locker

--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

test_adjust_shutdown_schedule.sh

Cap --restore at 23:00 so it is a reward, not an off switch

2026-08-28 19:59:43 +02:00