Conserve local-day evidence #98

New Issue

2026-09-27T20:01:06Z

xavierk commented

2026-09-27 20:01:06 +00:00

Parent

Deepen observation-history publication, local-day evidence, and activity selection.

What to build

Give drive owners honest local-day read/write evidence through collection and the visible activity views. Derive known volume from compatible measured intervals inside recorded local boundaries, retain a local-midnight-spanning measurement once as shared local-day evidence, and show known amounts explicitly as incomplete when allocation is ambiguous or evidence is missing. Keep UTC projection evidence distinct.

Acceptance criteria

A measured read/write interval crossing a UTC-hour boundary but wholly inside one local day contributes its full measured amount to that day's known activity; include the reproduced 5,120,000-byte write case.
An actual measured interval crossing Asia/Kolkata local midnight produces one shared evidence item, not full known volume in both adjacent days; a synthetic 100-byte case demonstrates conservation independently of display rounding.
TUI daily totals and selected activity use the recorded local date and show known writes/reads and shared volume separately, with incomplete/so-far/zero/unavailable states that cannot be mistaken for a complete day. CLI/status facts agree where they display activity.
Verify 23-/25-hour local days, non-whole-hour offsets, timezone changes, repeated local clock labels, controller segments and monitoring periods; no fabricated interpolation or regression in established UTC projection rules.
Tests cross controlled acquisition and clock, temporary observation store and ordinary reader paths, with focused evidence-invariant checks only where necessary.

Blocked by

#97 Retain and recover pending publication.

## Parent [Deepen observation-history publication, local-day evidence, and activity selection](https://git.bongbetic.com/xavierk/Fenris/issues/95). ## What to build Give drive owners honest local-day read/write evidence through collection and the visible activity views. Derive known volume from compatible measured intervals inside recorded local boundaries, retain a local-midnight-spanning measurement once as shared local-day evidence, and show known amounts explicitly as incomplete when allocation is ambiguous or evidence is missing. Keep UTC projection evidence distinct. ## Acceptance criteria - [ ] A measured read/write interval crossing a UTC-hour boundary but wholly inside one local day contributes its full measured amount to that day's known activity; include the reproduced 5,120,000-byte write case. - [ ] An actual measured interval crossing Asia/Kolkata local midnight produces one shared evidence item, not full known volume in both adjacent days; a synthetic 100-byte case demonstrates conservation independently of display rounding. - [ ] TUI daily totals and selected activity use the recorded local date and show known writes/reads and shared volume separately, with incomplete/so-far/zero/unavailable states that cannot be mistaken for a complete day. CLI/status facts agree where they display activity. - [ ] Verify 23-/25-hour local days, non-whole-hour offsets, timezone changes, repeated local clock labels, controller segments and monitoring periods; no fabricated interpolation or regression in established UTC projection rules. - [ ] Tests cross controlled acquisition and clock, temporary observation store and ordinary reader paths, with focused evidence-invariant checks only where necessary. ## Blocked by - [#97 Retain and recover pending publication](https://git.bongbetic.com/xavierk/Fenris/issues/97).

xavierk added the ready-for-agent label 2026-09-27 20:01:06 +00:00

xavierk added a new dependency 2026-09-27 20:01:07 +00:00

#97 Retain and recover pending publication

xavierk referenced this issue

2026-09-27 20:01:09 +00:00

Make historical local-day evidence trustworthy #99

xavierk added a new dependency 2026-09-27 20:01:10 +00:00

#99 Make historical local-day evidence trustworthy

xavierk closed this issue

2026-09-28 05:00:35 +00:00

Sign in to join this conversation.