Retain and recover pending publication #97

New Issue

2026-09-27T20:01:04Z

xavierk commented

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

Parent

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

What to build

When valid acquired observations cannot be derived, retain them privately as pending publication in the same observation store. Make the collection run fail visibly, leave both TUI and CLI on the last coherent published history and retry pending work in order on the next scheduled collection. Invalid observations still write nothing; a store fault is not disguised as recoverable pending work.

Acceptance criteria

Actually inject a non-invariant derivation failure through normal collection; valid acquired evidence survives restart in private staging and the public sample, identity, summary, drive facts, freshness and usage-adjusted theoretical lifespan remain unchanged.
TUI and CLI explain pending publication while showing published evidence; newer-schema and store-fault refusal plus independent native monitoring state remain truthful.
A later collection first replays outstanding work in order, then publishes new evidence only if dependencies allow it; repeated recovery or crash/restart never counts an interval twice or skips an older observation.
Invariant violations write no newly acquired invalid sample, proposed segment or monitoring-period change; failures produce unsuccessful collection outcomes without silently succeeding.
Use real temporary SQLite and ordinary read paths for the main tests; focused interrupted-transaction and concurrent-reader probes verify atomic public visibility. Do not introduce another store or process.

Blocked by

#96 Give collection one publication transaction.

## Parent [Deepen observation-history publication, local-day evidence, and activity selection](https://git.bongbetic.com/xavierk/Fenris/issues/95). ## What to build When valid acquired observations cannot be derived, retain them privately as pending publication in the same observation store. Make the collection run fail visibly, leave both TUI and CLI on the last coherent published history and retry pending work in order on the next scheduled collection. Invalid observations still write nothing; a store fault is not disguised as recoverable pending work. ## Acceptance criteria - [ ] Actually inject a non-invariant derivation failure through normal collection; valid acquired evidence survives restart in private staging and the public sample, identity, summary, drive facts, freshness and usage-adjusted theoretical lifespan remain unchanged. - [ ] TUI and CLI explain pending publication while showing published evidence; newer-schema and store-fault refusal plus independent native monitoring state remain truthful. - [ ] A later collection first replays outstanding work in order, then publishes new evidence only if dependencies allow it; repeated recovery or crash/restart never counts an interval twice or skips an older observation. - [ ] Invariant violations write no newly acquired invalid sample, proposed segment or monitoring-period change; failures produce unsuccessful collection outcomes without silently succeeding. - [ ] Use real temporary SQLite and ordinary read paths for the main tests; focused interrupted-transaction and concurrent-reader probes verify atomic public visibility. Do not introduce another store or process. ## Blocked by - [#96 Give collection one publication transaction](https://git.bongbetic.com/xavierk/Fenris/issues/96).

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

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

#96 Give collection one publication transaction

xavierk referenced this issue

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

Conserve local-day evidence #98

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

#98 Conserve local-day evidence

xavierk referenced this issue

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

Bound pending admission before acquisition #101

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