Motivation
The by-agent dashboard view aggregates session data to daily totals, losing the shape of an individual day. A scrubbable timeline that replays a day's sessions as cost accumulates would make the archive's session-level detail (SessionRecord) visible and add a distinctive "burn down" visual (cost ticking up like a fuse) matching the app's identity.
Proposal
A per-day timeline view: pick a date, scrub/play through that day's sessions in chronological order (by lastActivity), with an animated running total and per-session markers.
Feasibility notes
- Session-level data already exists in the archive (
sessions/*.json, monthly-sharded, keyed by sessionId) but isn't currently exposed to the dashboard beyond the by-agent daily aggregation — this needs a new IPC-exposed query (e.g. archive:get-day-sessions) and a corresponding derive.ts/store.ts read path, which is more backend work than the other dashboard ideas.
- Note the existing documented approximation: sessions are attributed to their
lastActivity day, so a single session's timeline may not perfectly reflect when tokens were actually spent within that session — worth flagging as a known limitation in the UI rather than hiding it.
Acceptance criteria
Motivation
The by-agent dashboard view aggregates session data to daily totals, losing the shape of an individual day. A scrubbable timeline that replays a day's sessions as cost accumulates would make the archive's session-level detail (
SessionRecord) visible and add a distinctive "burn down" visual (cost ticking up like a fuse) matching the app's identity.Proposal
A per-day timeline view: pick a date, scrub/play through that day's sessions in chronological order (by
lastActivity), with an animated running total and per-session markers.Feasibility notes
sessions/*.json, monthly-sharded, keyed bysessionId) but isn't currently exposed to the dashboard beyond the by-agent daily aggregation — this needs a new IPC-exposed query (e.g.archive:get-day-sessions) and a correspondingderive.ts/store.tsread path, which is more backend work than the other dashboard ideas.lastActivityday, so a single session's timeline may not perfectly reflect when tokens were actually spent within that session — worth flagging as a known limitation in the UI rather than hiding it.Acceptance criteria
lastActivity-day-bucketing approximation where relevant.