Approve the Fenris TUI polish specification and handoff #70
Notifications
Due Date
No due date set.
Depends on
#67 Define monitoring signals and honest warm-up estimates
xavierk/Fenris
#68 Choose daily graph encoding and hourly drill-down
xavierk/Fenris
#69 Approve titlebox, health layout and colour presets
xavierk/Fenris
#71 Reconcile unallocated usage with UTC projection evidence
xavierk/Fenris
Reference: xavierk/Fenris#70
Reference in New Issue
Block a user
Parent map: Fenris TUI polish and hourly history
Question
Does the companion specification faithfully integrate every resolved decision and provide an implementation-ready, human-approved handoff with no hidden choices?
HITL grilling + domain-modeling; final approval requires live human review. Wait for all decision/prototype tickets and any graduated blockers. Re-read the map and authoritative resolution comments; do not restate competing decisions in the map.
Review a linked companion-spec asset and acceptance amendments covering top branding/wolf fallback, status/blink/text truthfulness, sample-to-hour/day history availability, hourly default and chosen daily encoding, keyboard/mouse drill-down, presets, vendor wear placement, and conditional warm-up/empty-counter messaging. Preserve confidence math, gaps, resets, deliberate-disable semantics, CLI parity, auth and quit behavior. Include direct observable proof examples for future implementation, not just a build checklist.
Explicitly identify superseded branding/placement clauses in prior dashboard clarity versus requirements preserved unchanged, and handoff relationship to the open prior implementation umbrella. Keep
docs/spec/fenris-redesign.mdfrozen. No production changes or release work.Resolution is the human's approval (or changes requested) of the linked specification and acceptance contract. Approval may close the map only after all in-scope fog and child questions are settled. Execution is a separate effort.
Specification asset ready for live review — not a resolution
I claimed Approve the Fenris TUI polish specification and handoff and re-read Fenris TUI polish and hourly history, the closed decision comments,
CONTEXT.md,docs/agents/domain.md, the relevant ADRs, and the existing spec files.Draft asset branch: wayfinder/tui-polish-hourly-history-spec
The draft keeps
docs/spec/fenris-redesign.mdfrozen. It explicitly supersedes only the old dashboard-clarity header/credit placement, preserves the continuity/pause/quit/auth/release-notes requirements, and treats Implement dashboard clarity and release notes as currently closed rather than as an open umbrella to rewrite.Mechanical proof performed on the asset branch:
git diff --check, plus direct greps for the titlebox, TPH criteria, and glossary terms. No production code, release work, package changes, or runtime diagnosis.Live review prompt for the human: approve this as the implementation-ready companion specification and acceptance contract, or name the changes required before approval.
Resolution — approved companion specification and handoff
Human approval received in live review: "approved". This approves the linked asset branch as the implementation-ready companion specification and acceptance contract for this Wayfinder map.
Approved handoff assets:
Approved commit:
d894ae2on branch wayfinder/tui-polish-hourly-history-spec.The handoff keeps
docs/spec/fenris-redesign.mdfrozen. It explicitly supersedes only the old dashboard-clarity header/credit placement and preserves the continuity, paused-state, quit rail, polkit-auth, TUI/CLI parity, and release-notes requirements. The prior implementation issue Implement dashboard clarity and release notes is treated as already closed; this approval is a new follow-on handoff, not a rewrite of that shipped umbrella.Acceptance amendments TPH-1–TPH-11 cover the titlebox/wolf fallback, status lattice and blink/reduced-motion truthfulness, collector-owned sample-to-hour/day publication, UTC projection accounting, warm-up/withheld-estimate messaging, writes-only daily bars with hourly drill-down, keyboard/mouse interaction, presets and persistence, vendor-wear placement, constrained-terminal behavior, and direct observable proof paths.
No production code, release gate, package, installation change, or runtime diagnosis is part of this resolution. Execution is a separate effort. No new fog or follow-on decision tickets are required; after this ticket closes, the parent map's destination is reached.