Found while implementing #339. Pre-existing and unrelated to the source field, but #339's measurements are what make it worth filing now.
Mechanism
SessionStart fires on startup, resume, clear, compact and fork. When past-day staging files exist, the consolidation trigger fires with them, so run-consolidation.sh is spawned again on each of those. Nothing about a compaction changes whether yesterday's staging files need consolidating — the work is the same work, re-launched.
Why now
The reporter on #339 measured compact firing 82 times across 50 sessions, against startup's 180. That reframes this from "a hook occasionally does redundant work at session start" into a path that demonstrably runs dozens of times per session on an auto-compacting user's machine. The spawn cost this repo has been trimming elsewhere (#227 took a hook path from 27 spawns to zero) is being re-paid here on a multiplier nobody had counted.
What is not claimed
I have not measured the wall-clock cost of a redundant consolidation run, nor established whether concurrent runs can interleave destructively — the staging files are the shared resource and that question deserves its own answer rather than an assumption. This is filed as "runs more often than it needs to", not as "corrupts anything".
Fix direction
SESSION_START_SOURCE lands in this file with #339, whitelisted and empty-by-default, so the trigger can be gated on it. As with the handoff counter (filed separately), the judgment is which sources genuinely warrant a fresh consolidation — startup clearly, compact clearly not, resume/clear/fork needing an actual argument rather than a guess.
Found while implementing #339. Pre-existing and unrelated to the
sourcefield, but #339's measurements are what make it worth filing now.Mechanism
SessionStartfires onstartup,resume,clear,compactandfork. When past-day staging files exist, the consolidation trigger fires with them, sorun-consolidation.shis spawned again on each of those. Nothing about a compaction changes whether yesterday's staging files need consolidating — the work is the same work, re-launched.Why now
The reporter on #339 measured
compactfiring 82 times across 50 sessions, againststartup's 180. That reframes this from "a hook occasionally does redundant work at session start" into a path that demonstrably runs dozens of times per session on an auto-compacting user's machine. The spawn cost this repo has been trimming elsewhere (#227 took a hook path from 27 spawns to zero) is being re-paid here on a multiplier nobody had counted.What is not claimed
I have not measured the wall-clock cost of a redundant consolidation run, nor established whether concurrent runs can interleave destructively — the staging files are the shared resource and that question deserves its own answer rather than an assumption. This is filed as "runs more often than it needs to", not as "corrupts anything".
Fix direction
SESSION_START_SOURCElands in this file with #339, whitelisted and empty-by-default, so the trigger can be gated on it. As with the handoff counter (filed separately), the judgment is which sources genuinely warrant a fresh consolidation —startupclearly,compactclearly not,resume/clear/forkneeding an actual argument rather than a guess.