Run the cross-cutting acceptance sweep #32
Notifications
Due Date
No due date set.
Depends on
#28 Build the Panes TUI
xavierk/Fenris
Reference: xavierk/Fenris#32
Reference in New Issue
Block a user
Parent
Implement the Fenris persistent TUI monitoring redesign
Canonical contracts: fenris-redesign spec · acceptance criteria — criterion IDs cited below live in the register.
What to build
The final green gate across everything the earlier tickets built. From synthetic observation stores, the TUI and
fenris statusrender every realizable combination of confidence state × freshness grade × endurance-baseline tier exactly as the rule table and freshness constants dictate — headline number present only when the rules allow it, contributing facts always, never a percentage. Every TUI action has a CLI twin with identical outcomes and wording. The prohibition set holds as automated checks: single acquisition path, one-key configuration, no alerting or notification machinery anywhere, no/runsurface, no stored projections, no partial interpretation of newer-schema stores, no synthetic baselines, polkit authorizing exactly one binary. The fixed user-facing phrases and the six disclosures audit clean in both views.Acceptance criteria
statusrender every confidence-state × freshness × baseline-tier combination per the rule table and constants — headline only when allowed, facts always, never a percentage (CI-1)Blocked by