A report answers for a period as a single total. Asking "which day was expensive" means running it once per day and comparing by hand.
What exists
report --from … --to … and report --days N resolve to two absolute days and produce one set of figures, broken down three ways: by_step, by_model, by_tool. A month is one number.
Every stored record already carries event_timestamp — the moment the work ran, deliberately distinct from the day file it was appended to, so a session read a week late still lands on the day it happened. The grouping this needs is over data that is already there and already correct.
Why it is worth its own row
The three breakdowns that exist answer where consumption went. None answers when. A month's total tells someone what they spent; a day-by-day line tells them which day changed, which is the question that leads anywhere.
It also makes a spike legible. Today an unusual week is invisible inside a month's total, and the only way to find it is to bisect by hand with repeated invocations.
Done when
- A report can break its period down by day, and the days sum to the period's total exactly.
- A day on which nothing ran reads as such, and is never omitted — a gap in a series is a fact, and a missing row would be read as continuity.
- The same holds in the machine-readable envelope, under a version that says the shape changed.
Cheap, and not free
The data is present and correct, so this is a grouping rather than a measurement. What needs care is the empty day above, and that a long period does not print one line per day to a terminal without being asked — a year is 365 rows.
Not this
Any coarser bucket. Weeks and months are the same grouping with a different key, and adding one before anyone asks for it is inventing a requirement.
A report answers for a period as a single total. Asking "which day was expensive" means running it once per day and comparing by hand.
What exists
report --from … --to …andreport --days Nresolve to two absolute days and produce one set of figures, broken down three ways:by_step,by_model,by_tool. A month is one number.Every stored record already carries
event_timestamp— the moment the work ran, deliberately distinct from the day file it was appended to, so a session read a week late still lands on the day it happened. The grouping this needs is over data that is already there and already correct.Why it is worth its own row
The three breakdowns that exist answer where consumption went. None answers when. A month's total tells someone what they spent; a day-by-day line tells them which day changed, which is the question that leads anywhere.
It also makes a spike legible. Today an unusual week is invisible inside a month's total, and the only way to find it is to bisect by hand with repeated invocations.
Done when
Cheap, and not free
The data is present and correct, so this is a grouping rather than a measurement. What needs care is the empty day above, and that a long period does not print one line per day to a terminal without being asked — a year is 365 rows.
Not this
Any coarser bucket. Weeks and months are the same grouping with a different key, and adding one before anyone asks for it is inventing a requirement.