Context
bash/tests/test-pre-push-scan-timeout.sh verifies run_bounded (git/hooks/pre-push's Semgrep timeout wrapper, addressing #251). It's deliberately expensive: every case runs twice (GNU timeout path and watchdog fallback), and several cases need real sleep/kill timing to assert on (over-budget commands, SIGKILL escalation, grace-period honoring). By its own case design this totals roughly 30-40s of real sleeps.
As of smartwatermelon/claude-config#470, Protocol 3 no longer forces this file to run on every commit — only on changes that touch git/hooks/pre-push, and at push time (where dotfiles' .project-hooks/pre-push already runs the full suite). The decision at the time was to leave the test's internals unchanged: its cost was judged inherent to testing real timeout behavior, and its sleep margins were deliberately sized against flakiness (per its own comments, referencing dotfiles#262, #266, #268, #279).
Ask
Revisit that call in a few weeks, once there's real signal from actual pre-push runs (not just the isolated/sandboxed timing used to make the original call):
Not a commitment to change anything — a scheduled check on whether the earlier judgment holds up.
Context
bash/tests/test-pre-push-scan-timeout.shverifiesrun_bounded(git/hooks/pre-push's Semgrep timeout wrapper, addressing #251). It's deliberately expensive: every case runs twice (GNUtimeoutpath and watchdog fallback), and several cases need real sleep/kill timing to assert on (over-budget commands, SIGKILL escalation, grace-period honoring). By its own case design this totals roughly 30-40s of real sleeps.As of
smartwatermelon/claude-config#470, Protocol 3 no longer forces this file to run on every commit — only on changes that touchgit/hooks/pre-push, and at push time (where dotfiles'.project-hooks/pre-pushalready runs the full suite). The decision at the time was to leave the test's internals unchanged: its cost was judged inherent to testing real timeout behavior, and its sleep margins were deliberately sized against flakiness (per its own comments, referencing dotfiles#262, #266, #268, #279).Ask
Revisit that call in a few weeks, once there's real signal from actual pre-push runs (not just the isolated/sandboxed timing used to make the original call):
sleep/signal delivery) that wouldn't reintroduce the coverage gaps the current design exists to close (Non-blocking review findings from pre-push review (2) #262, Non-blocking review findings from PR #257 (1) #266, Non-blocking review findings from pre-push review (1) #268, Non-blocking review findings from pre-push review (3) #279) — or is real-timing testing simply the right tool here?Not a commitment to change anything — a scheduled check on whether the earlier judgment holds up.