Problem
The default ledger can be weeks out of date with no signal to the user. During the 2026-07-30 fleet spend forensics, the default ledger's last write was weeks prior to the report being generated — every read and report ran silently against stale data, with nothing distinguishing that from a fresh, complete ledger.
Why it matters
Any command that reads the default ledger (summary, hotspots, findings, sessions list, etc.) currently has no way to tell the caller "this data is old, re-ingest before trusting it." That makes it easy to draw conclusions (or file findings) from a snapshot that silently excludes weeks of activity, with no error, warning, or exit-code signal.
Fix
On read/report, compare the ledger's last-write timestamp against wall-clock time and surface a warning (stderr for CLI, a flagged field for SDK/MCP consumers) when it exceeds a threshold (e.g. configurable, default on the order of a day). Should apply uniformly across summary, hotspots, findings, and sessions list.
Problem
The default ledger can be weeks out of date with no signal to the user. During the 2026-07-30 fleet spend forensics, the default ledger's last write was weeks prior to the report being generated — every read and report ran silently against stale data, with nothing distinguishing that from a fresh, complete ledger.
Why it matters
Any command that reads the default ledger (
summary,hotspots,findings,sessions list, etc.) currently has no way to tell the caller "this data is old, re-ingest before trusting it." That makes it easy to draw conclusions (or file findings) from a snapshot that silently excludes weeks of activity, with no error, warning, or exit-code signal.Fix
On read/report, compare the ledger's last-write timestamp against wall-clock time and surface a warning (stderr for CLI, a flagged field for SDK/MCP consumers) when it exceeds a threshold (e.g. configurable, default on the order of a day). Should apply uniformly across
summary,hotspots,findings, andsessions list.