--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
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
Hardcoding /usr/local/share/locked-shutdown-schedule.conf broke once the
hosts/shutdown-schedule file-guard instances moved to guard-lib's own
canonical-path layout. Resolve it at runtime via `guardctl file-guard
canonical-path` instead, and fail loudly if the guard-lib instance isn't
installed rather than silently reading/writing the wrong path.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AFNiYQQgSLAkiBXswyimPq
