Publish consistent measured drive activity #89

Closed
opened 2026-09-17 10:33:42 +00:00 by xavierk · 0 comments
Owner

Parent

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

What to build

Make each successful collection visible as correct read/write activity through the existing observation store and dashboard. Repair the narrow collection-to-display path first, including necessary consolidation inside its existing owners, so later local-day and live views consume trustworthy measurements. Demonstrate this in the current history/readout: show read and write figures separately and explicitly retain UTC labels until the local-day slice lands. This slice does not introduce the new graph or alter the collection cadence.

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

  • Drive successive controlled acquisition readings through the public collector into a real temporary observation store, then verify the normal reader and visible dashboard report correct read/write deltas and existing hour/day evidence without a manual repair pass.
  • A successful run publishes mutually consistent sample, affected summary, and required boundary evidence; an interrupted or failed derivation cannot leave a successful outcome with stale derived views. Use the existing transaction and concurrent-reader patterns, and verify a separate reader sees a consistent result.
  • Repeated same-hour collections accumulate both reads and writes correctly. Repeated refresh, restart, and supported repair/re-derivation do not duplicate measured bytes.
  • Cross-hour and cross-UTC-day measurements are conserved exactly once. Preserve uncertain boundary allocation as evidence rather than duplicating the full delta across dates or estimating a split; legacy summaries remain at their actual precision.
  • The first reading is an anchor; a compatible second reading yields a measured interval. Visible awaiting-data, measured zero, unknown/gap, and partial states remain distinct.
  • Counter resets, controller identity changes, deliberate disables, and missed runs retain the existing segment and monitoring-period invariants. No invalid cross-boundary delta or invented zero is displayed.
  • Both daily figures are labelled with the actual timezone of the existing UTC aggregates. Store faults/newer schemas produce the established visible unavailable state; no missing read counter is converted into a known zero.
  • Use the approved collector-to-store-to-visible-result proof, with acquisition fixtures and injected time rather than mocked derivation results. Source findings are regression targets to reproduce and verify, not assumptions to encode into expected values.
  • Keep any prefactoring within the responsible existing collection/derivation/read modules and complete it before dependent behavior. Preserve the single privileged writer, read-only TUI, existing monitoring actions, and green unrelated tests.

Blocked by

  • None (can start immediately).
## Parent [Implement live daily drive activity, keyboard date navigation, and an endurance outlook](https://git.bongbetic.com/xavierk/Fenris/issues/88) ## What to build Make each successful collection visible as correct read/write activity through the existing observation store and dashboard. Repair the narrow collection-to-display path first, including necessary consolidation inside its existing owners, so later local-day and live views consume trustworthy measurements. Demonstrate this in the current history/readout: show read and write figures separately and explicitly retain UTC labels until the local-day slice lands. This slice does not introduce the new graph or alter the collection cadence. 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 - [ ] Drive successive controlled acquisition readings through the public collector into a real temporary observation store, then verify the normal reader and visible dashboard report correct read/write deltas and existing hour/day evidence without a manual repair pass. - [ ] A successful run publishes mutually consistent sample, affected summary, and required boundary evidence; an interrupted or failed derivation cannot leave a successful outcome with stale derived views. Use the existing transaction and concurrent-reader patterns, and verify a separate reader sees a consistent result. - [ ] Repeated same-hour collections accumulate both reads and writes correctly. Repeated refresh, restart, and supported repair/re-derivation do not duplicate measured bytes. - [ ] Cross-hour and cross-UTC-day measurements are conserved exactly once. Preserve uncertain boundary allocation as evidence rather than duplicating the full delta across dates or estimating a split; legacy summaries remain at their actual precision. - [ ] The first reading is an anchor; a compatible second reading yields a measured interval. Visible awaiting-data, measured zero, unknown/gap, and partial states remain distinct. - [ ] Counter resets, controller identity changes, deliberate disables, and missed runs retain the existing segment and monitoring-period invariants. No invalid cross-boundary delta or invented zero is displayed. - [ ] Both daily figures are labelled with the actual timezone of the existing UTC aggregates. Store faults/newer schemas produce the established visible unavailable state; no missing read counter is converted into a known zero. - [ ] Use the approved collector-to-store-to-visible-result proof, with acquisition fixtures and injected time rather than mocked derivation results. Source findings are regression targets to reproduce and verify, not assumptions to encode into expected values. - [ ] Keep any prefactoring within the responsible existing collection/derivation/read modules and complete it before dependent behavior. Preserve the single privileged writer, read-only TUI, existing monitoring actions, and green unrelated tests. ## Blocked by - None (can start immediately).
xavierk added the ready-for-agent label 2026-09-17 10:33:42 +00:00
xavierk added a new dependency 2026-09-17 10:34:06 +00:00
xavierk self-assigned this 2026-09-17 11:30:31 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Reference: xavierk/Fenris#89