Write the Fenris redesign specification and close the map #18

New Issue

2026-08-31T18:01:50Z

xavierk commented

2026-08-31 18:01:50 +00:00

Parent map: Chart Fenris's persistent TUI monitoring redesign

Question

The assembly decisions are settled on Assemble the implementation-ready specification (all seven recommendations accepted). Execute them:

Verify first. Build the two-way ADR↔criterion traceability matrix — every ADR 0001–0006 section maps to at least one criterion ID; every criterion cites its ADR or ticket. Fill decided-but-uncritered gaps inline in docs/spec/acceptance-criteria.md, each new criterion citing its ADR. Escalate genuinely undecided behavior as a new blocking ticket before proceeding.
Write docs/spec/fenris-redesign.md. Single document, data-flow ordered: system context → collector acquisition → observation store → controller identity & segmentation → hour/day derivation → projection & confidence → Panes TUI → service lifecycle & sanctioned toggle → failure & recovery → installation. Normatively restate every operative contract (the what); rationale (the why) stays in ADRs 0001–0006, cited per section. Restate the Panes TUI layout as normative requirements; the prototype branch is visual reference only. Each section opens with its ADR links and criterion-ID block. Status header links this map and the assembly decision. The traceability matrix is an appendix. docs/spec/acceptance-criteria.md and the ADRs remain canonical; the spec never restates criteria as criteria.
Commit to main and post the resolution comment with the matrix result and the commit link.
Close the map. Re-fetch the map, append this ticket to Decisions so far, and close it — the destination is reached when the spec is committed, the matrix is clean, and no tickets remain.

AFK: the agent drives this alone; no human input required.

Parent map: [Chart Fenris's persistent TUI monitoring redesign](https://git.bongbetic.com/xavierk/Fenris/issues/1) ## Question The assembly decisions are settled on [Assemble the implementation-ready specification](https://git.bongbetic.com/xavierk/Fenris/issues/17) (all seven recommendations accepted). Execute them: 1. **Verify first.** Build the two-way ADR↔criterion traceability matrix — every ADR 0001–0006 section maps to at least one criterion ID; every criterion cites its ADR or ticket. Fill decided-but-uncritered gaps inline in `docs/spec/acceptance-criteria.md`, each new criterion citing its ADR. Escalate genuinely undecided behavior as a new blocking ticket before proceeding. 2. **Write `docs/spec/fenris-redesign.md`.** Single document, data-flow ordered: system context → collector acquisition → observation store → controller identity & segmentation → hour/day derivation → projection & confidence → Panes TUI → service lifecycle & sanctioned toggle → failure & recovery → installation. Normatively restate every operative contract (the *what*); rationale (the *why*) stays in ADRs 0001–0006, cited per section. Restate the Panes TUI layout as normative requirements; the prototype branch is visual reference only. Each section opens with its ADR links and criterion-ID block. Status header links this map and the assembly decision. The traceability matrix is an appendix. `docs/spec/acceptance-criteria.md` and the ADRs remain canonical; the spec never restates criteria as criteria. 3. **Commit to `main`** and post the resolution comment with the matrix result and the commit link. 4. **Close the map.** Re-fetch [the map](https://git.bongbetic.com/xavierk/Fenris/issues/1), append this ticket to Decisions so far, and close it — the destination is reached when the spec is committed, the matrix is clean, and no tickets remain. AFK: the agent drives this alone; no human input required.

xavierk commented

2026-08-31 18:02:31 +00:00

Accidental duplicate of #19 created by a failed --output json flag on tea issues create; no work happened here. Closed as duplicate.

xavierk closed this issue

2026-08-31 18:02:32 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: xavierk/Fenris#18