Show trustworthy local-day activity totals #90

New Issue

2026-09-17T10:33:42Z

xavierk commented

2026-09-17 10:33:42 +00:00

Parent

Implement live daily drive activity, keyboard date navigation, and an endurance outlook

What to build

Show today's read and write volumes using actual local calendar boundaries, labelled as totals so far when appropriate. Carry the observations through durable local-day summaries and the normal reader into the dashboard, while retaining the UTC evidence used for endurance. Establish the shared local-day evidence contract used by later browsing and forecast slices. This slice includes safe schema introduction and future summary publication; extended aged-history browsing and retention proof belong to the retention slice.

All behavior follows the parent specification, including its precedence over conflicting earlier TUI requirements. The approved proof uses controlled acquisition and time through a real observation store into public TUI/CLI results; preserve the existing collector/reader ownership and no-fabrication rules.

Acceptance criteria

The dashboard exposes separate measured read/write totals for the actual local day, with the timezone, partial/completeness state, and unallocated boundary evidence visible. Do not simply relabel a UTC aggregate.
Add the minimum versioned observation-store extension needed for local date, recorded timezone, UTC day boundaries, controller context, read/write volumes, and evidence state. The collector durably publishes these summaries before source evidence can be pruned.
Migration preserves existing observation history, runs transactionally, is safe to reopen/retry, and retains newer-schema refusal. Derive local summaries from surviving evidence only; older coarse UTC history cannot become an exact local total through migration.
An interval wholly attributable to a day contributes its measured volume once. A midnight-spanning interval with unknown split is retained once as shared/unallocated evidence, with incomplete affected totals rather than proportional allocation or double counting.
Verify Asia/Kolkata local midnight, 23-hour and 25-hour daylight-saving days, and repeated local clock labels through collection, persistence, and visible results.
A system-timezone change uses the new timezone for new observations while preserving the recorded timezone and boundaries of historical summaries. The UI must not blend differently bounded days into an apparently exact total.
The existing UTC hour/day aggregates and projection windows retain their established meaning. Local-day rendering does not alter controller identity, monitoring-period, coverage, or endurance accounting.
Use the shared local-day evidence result to distinguish a completed calendar day with usable observations from a partial first day, a deliberately disabled span, or a day without usable evidence; expose this through the existing read ownership for the later forecast gate without adding a new service.
Verify both daily totals and evidence labels through the normal dashboard at common and constrained terminal sizes. Include schema/concurrent-reader checks only where the primary collection-to-visible-result path cannot prove the required invariant.

Blocked by

Publish consistent measured drive activity

## Parent [Implement live daily drive activity, keyboard date navigation, and an endurance outlook](https://git.bongbetic.com/xavierk/Fenris/issues/88) ## What to build Show today's read and write volumes using actual local calendar boundaries, labelled as totals so far when appropriate. Carry the observations through durable local-day summaries and the normal reader into the dashboard, while retaining the UTC evidence used for endurance. Establish the shared local-day evidence contract used by later browsing and forecast slices. This slice includes safe schema introduction and future summary publication; extended aged-history browsing and retention proof belong to the retention slice. All behavior follows the parent specification, including its precedence over conflicting earlier TUI requirements. The approved proof uses controlled acquisition and time through a real observation store into public TUI/CLI results; preserve the existing collector/reader ownership and no-fabrication rules. ## Acceptance criteria - [ ] The dashboard exposes separate measured read/write totals for the actual local day, with the timezone, partial/completeness state, and unallocated boundary evidence visible. Do not simply relabel a UTC aggregate. - [ ] Add the minimum versioned observation-store extension needed for local date, recorded timezone, UTC day boundaries, controller context, read/write volumes, and evidence state. The collector durably publishes these summaries before source evidence can be pruned. - [ ] Migration preserves existing observation history, runs transactionally, is safe to reopen/retry, and retains newer-schema refusal. Derive local summaries from surviving evidence only; older coarse UTC history cannot become an exact local total through migration. - [ ] An interval wholly attributable to a day contributes its measured volume once. A midnight-spanning interval with unknown split is retained once as shared/unallocated evidence, with incomplete affected totals rather than proportional allocation or double counting. - [ ] Verify Asia/Kolkata local midnight, 23-hour and 25-hour daylight-saving days, and repeated local clock labels through collection, persistence, and visible results. - [ ] A system-timezone change uses the new timezone for new observations while preserving the recorded timezone and boundaries of historical summaries. The UI must not blend differently bounded days into an apparently exact total. - [ ] The existing UTC hour/day aggregates and projection windows retain their established meaning. Local-day rendering does not alter controller identity, monitoring-period, coverage, or endurance accounting. - [ ] Use the shared local-day evidence result to distinguish a completed calendar day with usable observations from a partial first day, a deliberately disabled span, or a day without usable evidence; expose this through the existing read ownership for the later forecast gate without adding a new service. - [ ] Verify both daily totals and evidence labels through the normal dashboard at common and constrained terminal sizes. Include schema/concurrent-reader checks only where the primary collection-to-visible-result path cannot prove the required invariant. ## Blocked by - [Publish consistent measured drive activity](https://git.bongbetic.com/xavierk/Fenris/issues/89)

xavierk added the ready-for-agent label 2026-09-17 10:33:42 +00:00

xavierk referenced this issue

2026-09-17 10:33:43 +00:00

Plot live drive activity every three minutes #91

xavierk referenced this issue

2026-09-17 10:33:44 +00:00

Keep local-day history trustworthy after detail expires #93

xavierk referenced this issue

2026-09-17 10:33:45 +00:00

Show an endurance outlook after a complete observation day #94

xavierk added a new dependency 2026-09-17 10:34:06 +00:00

#89 Publish consistent measured drive activity