Define cross-cutting acceptance criteria #13

New Issue

2026-08-31T11:45:31Z

xavierk commented

2026-08-31 11:45:31 +00:00

Parent map: Chart Fenris’s persistent TUI monitoring redesign

Question

What cross-cutting acceptance criteria must the implementation-ready specification state so the finished redesign can be judged done — behavioral gates spanning the observation store and its legacy migration, the collector lifecycle and privilege boundaries, the projection contract and its confidence states, and the adopted Panes TUI — including failure-path expectations?

Parent map: [Chart Fenris’s persistent TUI monitoring redesign](https://git.bongbetic.com/xavierk/Fenris/issues/1) ## Question What cross-cutting acceptance criteria must the implementation-ready specification state so the finished redesign can be judged done — behavioral gates spanning the observation store and its legacy migration, the collector lifecycle and privilege boundaries, the projection contract and its confidence states, and the adopted Panes TUI — including failure-path expectations?

xavierk added the wayfinder:grilling label 2026-08-31 11:45:42 +00:00

xavierk added this to the Wayfinder: Fenris persistent TUI monitoring redesign milestone 2026-08-31 11:45:43 +00:00

xavierk added a new dependency 2026-08-31 11:45:44 +00:00

#9 Define installation, upgrade, and removal behavior

xavierk added a new dependency 2026-08-31 11:45:44 +00:00

#11 Verify the controller identity that segments observation history

xavierk added a new dependency 2026-08-31 11:45:44 +00:00

#12 Define endurance-baseline provenance and validation

xavierk added a new dependency 2026-08-31 11:45:44 +00:00

#10 Define failure and recovery behavior

xavierk added a new dependency 2026-08-31 15:16:07 +00:00

#16 Choose the collector's NVMe acquisition path

xavierk added a new dependency 2026-08-31 15:16:07 +00:00

#14 Decide controller-segment metadata columns

xavierk added a new dependency 2026-08-31 15:16:07 +00:00

#15 Decide how degraded identity affects projection confidence

xavierk self-assigned this 2026-08-31 16:35:41 +00:00

xavierk commented

2026-08-31 16:43:46 +00:00

Resolution

Converged by grilling over two rounds (all recommendations accepted):

Venue and form: the criteria are an input section of the implementation-ready specification — one testable statement per criterion, grouped by subsystem, each traceable to its ADR. Given/When/Then test specs are downstream implementation work, not part of this effort.
Evidence standard: every criterion carries exactly one class — A (automated), P (scripted system probe), M (manual, only where a fixture cannot capture the interaction, e.g. live polkit prompts); whatever can be automated must be.
Traceability-only: no criterion introduces anything an ADR or ticket did not already fix; undecided demands become new tickets, never criteria.
Open siblings: criteria for decided behavior land now; SLOT-A (Decide how degraded identity affects projection confidence) and SLOT-B (Choose the collector's NVMe acquisition path) are labeled placeholders filled by those resolutions.
Headline gate: a fixture-driven exhaustive state matrix — confidence state × freshness grade × baseline tier — rendered from both the TUI and fenris status (pins the ADR 0002 rule table and ADR 0003 freshness constants in one place).
Parity gate: an explicit TUI/CLI twin matrix (pause, resume, collect-now, baseline set/clear, status facts).
Prohibition set: fixed never-rules — device access only via fenris-collect, polkit scope limited to fenris-monitor, no backfill, no alerting machinery, one-key configuration, no synthetic baselines, no partial interpretation of a newer-schema store, projections never stored.
Migration gates: single-transaction interruption safety (scripted kill, class P), idempotent marker no-op, rename-after-commit, malformed-line quarantine counts, hourly.jsonl distrust, installer import counts.
Coverage: all decided areas including installation lifecycle (ADR 0004) and CLI compatibility (ADR 0003 §9), not only the four named in the ticket.
Spec-document done-ness (traceability matrix complete, zero unfilled slots) is deferred to the spec-assembly fog patch, not judged here.
Artifact: committed to main as docs/spec/acceptance-criteria.md — same practice as the ADRs; no separate ADR, the doc is the artifact of this decision.

Asset: docs/spec/acceptance-criteria.md

## Resolution Converged by grilling over two rounds (all recommendations accepted): 1. **Venue and form**: the criteria are an input section of the implementation-ready specification — one testable statement per criterion, grouped by subsystem, each traceable to its ADR. Given/When/Then test specs are downstream implementation work, not part of this effort. 2. **Evidence standard**: every criterion carries exactly one class — A (automated), P (scripted system probe), M (manual, only where a fixture cannot capture the interaction, e.g. live polkit prompts); whatever can be automated must be. 3. **Traceability-only**: no criterion introduces anything an ADR or ticket did not already fix; undecided demands become new tickets, never criteria. 4. **Open siblings**: criteria for decided behavior land now; SLOT-A ([Decide how degraded identity affects projection confidence](https://git.bongbetic.com/xavierk/Fenris/issues/15)) and SLOT-B ([Choose the collector's NVMe acquisition path](https://git.bongbetic.com/xavierk/Fenris/issues/16)) are labeled placeholders filled by those resolutions. 5. **Headline gate**: a fixture-driven exhaustive state matrix — confidence state × freshness grade × baseline tier — rendered from both the TUI and `fenris status` (pins the ADR 0002 rule table and ADR 0003 freshness constants in one place). 6. **Parity gate**: an explicit TUI/CLI twin matrix (pause, resume, collect-now, baseline set/clear, status facts). 7. **Prohibition set**: fixed never-rules — device access only via `fenris-collect`, polkit scope limited to `fenris-monitor`, no backfill, no alerting machinery, one-key configuration, no synthetic baselines, no partial interpretation of a newer-schema store, projections never stored. 8. **Migration gates**: single-transaction interruption safety (scripted kill, class P), idempotent marker no-op, rename-after-commit, malformed-line quarantine counts, `hourly.jsonl` distrust, installer import counts. 9. **Coverage**: all decided areas including installation lifecycle (ADR 0004) and CLI compatibility (ADR 0003 §9), not only the four named in the ticket. 10. **Spec-document done-ness** (traceability matrix complete, zero unfilled slots) is deferred to the spec-assembly fog patch, not judged here. 11. **Artifact**: committed to `main` as [docs/spec/acceptance-criteria.md](https://git.bongbetic.com/xavierk/Fenris/src/branch/main/docs/spec/acceptance-criteria.md) — same practice as the ADRs; no separate ADR, the doc is the artifact of this decision. Asset: [docs/spec/acceptance-criteria.md](https://git.bongbetic.com/xavierk/Fenris/src/branch/main/docs/spec/acceptance-criteria.md)

xavierk removed a dependency 2026-08-31 16:44:30 +00:00

#15 Decide how degraded identity affects projection confidence

xavierk removed a dependency 2026-08-31 16:44:30 +00:00

#16 Choose the collector's NVMe acquisition path

xavierk closed this issue

2026-08-31 16:44:31 +00:00

xavierk referenced this issue

2026-08-31 16:44:32 +00:00

Chart Fenris’s persistent TUI monitoring redesign #1

xavierk referenced this issue

2026-08-31 16:44:33 +00:00

Choose the collector's NVMe acquisition path #16