Why it ships with a reader, and would not ship without one
A log nobody reads is a data graveyard — and that argument has been used in this project to decline things, so it could not be waved away here. The reader landed in the same change as the writer. It answers questions that were previously archaeology:
That last row is the one that earns its cost. A hand-edit of the state file shows up as a revision no recorded event accounts for — the failure mode this project has repeatedly found and repeatedly had to dig for.
The detail that makes that section signal rather than noise: events carry a revision range, not a single number. An ordinary update writes twice — once for the change, once for the re-render — so single-number events would flag every normal write as an out-of-band one, and the section would be pure noise on day one.
Bounded by design
A log that grows without limit in every repository is a papercut every user inherits, so the limits are part of the feature rather than a later addition:- Segmented files named by timestamp, so “since when” and “how old” are answerable from the filename without opening anything.
- A per-project cap, pruned oldest-first at a rotation boundary — and never down to zero segments.
purge-logsrefuses twice: nothing without a selector, and nothing without an explicit confirmation flag. A--dry-runshows what would go.- The log directory is git-ignored automatically, so it never becomes a permanently untracked file in your working tree.
set-activity-log on is a deliberate choice, and off stops it without removing what was already recorded.