Assemble the implementation-ready specification #17

New Issue

2026-08-31T17:33:58Z

xavierk commented

2026-08-31 17:33:58 +00:00

Parent map: Chart Fenris's persistent TUI monitoring redesign

Question

How is the implementation-ready specification assembled from ADRs 0001–0006 and the accepted criteria — document shape, ordering, and handoff? Verify ADR→criterion traceability completeness (both slots now filled) as part of assembly before declaring the way to the destination clear.

Parent map: [Chart Fenris's persistent TUI monitoring redesign](https://git.bongbetic.com/xavierk/Fenris/issues/1) ## Question How is the implementation-ready specification assembled from ADRs 0001–0006 and [the accepted criteria](https://git.bongbetic.com/xavierk/Fenris/src/branch/main/docs/spec/acceptance-criteria.md) — document shape, ordering, and handoff? Verify ADR→criterion traceability completeness (both slots now filled) as part of assembly before declaring the way to the destination clear.

xavierk added this to the Wayfinder: Fenris persistent TUI monitoring redesign milestone 2026-08-31 17:33:58 +00:00

xavierk added the wayfinder:grilling label 2026-08-31 17:33:58 +00:00

xavierk self-assigned this 2026-08-31 17:36:20 +00:00

xavierk referenced this issue

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

Write the Fenris redesign specification and close the map #18

xavierk referenced this issue

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

Write the Fenris redesign specification and close the map #19

xavierk commented

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

Resolution — HITL grilling; the human accepted all seven recommendations verbatim.

1. Artifact shape. One specification document, docs/spec/fenris-redesign.md. ADRs 0001–0006 remain the immutable rationale records; docs/spec/acceptance-criteria.md remains the single register of testable statements. The spec cites both and adopts neither's role.

2. Stand-alone contracts. The spec normatively restates every operative contract — the what (schema column sets, constants, rule tables, unit definitions, TUI layout) — so an implementer never needs Wayfinder-ticket access. The why stays in the ADRs, cited per section; the traceability matrix keeps the deliberate contract duplication honest.

3. Ordering. Data-flow order: system context → collector acquisition → observation store → controller identity & segmentation → hour/day derivation → projection & confidence → Panes TUI → service lifecycle & sanctioned toggle → failure & recovery → installation. Each section opens with its ADR links and criterion-ID block.

4. TUI authority. The Panes IA is restated in the spec as normative requirements; the prototype branch is cited as visual reference only.

5. Traceability verification. A two-way matrix (every ADR section → at least one criterion ID; every criterion → its ADR/ticket citation) is an appendix of the spec, and building it is assembly's first step. Decided-but-uncritered gaps are filled inline in the criteria register, each citing its ADR; genuinely undecided behavior escalates as a new blocking ticket before assembly proceeds.

6. Execution. Assembly is delegated to one AFK wayfinder:task ticket — mechanical now that these decisions are fixed; its resolution comment carries the matrix result and the spec commit.

7. Handoff and closure. The spec is written implementer-agnostic: spec + criteria register + ADRs + CONTEXT.md vocabulary form the complete handoff. The task ticket closes the map once the spec is committed, the matrix is clean, and no tickets remain.

Follow-up: Write the Fenris redesign specification and close the map

**Resolution** — HITL grilling; the human accepted all seven recommendations verbatim. **1. Artifact shape.** One specification document, `docs/spec/fenris-redesign.md`. ADRs 0001–0006 remain the immutable rationale records; `docs/spec/acceptance-criteria.md` remains the single register of testable statements. The spec cites both and adopts neither's role. **2. Stand-alone contracts.** The spec normatively restates every operative contract — the *what* (schema column sets, constants, rule tables, unit definitions, TUI layout) — so an implementer never needs Wayfinder-ticket access. The *why* stays in the ADRs, cited per section; the traceability matrix keeps the deliberate contract duplication honest. **3. Ordering.** Data-flow order: system context → collector acquisition → observation store → controller identity & segmentation → hour/day derivation → projection & confidence → Panes TUI → service lifecycle & sanctioned toggle → failure & recovery → installation. Each section opens with its ADR links and criterion-ID block. **4. TUI authority.** The Panes IA is restated in the spec as normative requirements; the prototype branch is cited as visual reference only. **5. Traceability verification.** A two-way matrix (every ADR section → at least one criterion ID; every criterion → its ADR/ticket citation) is an appendix of the spec, and building it is assembly's **first** step. Decided-but-uncritered gaps are filled inline in the criteria register, each citing its ADR; genuinely undecided behavior escalates as a new blocking ticket before assembly proceeds. **6. Execution.** Assembly is delegated to one AFK `wayfinder:task` ticket — mechanical now that these decisions are fixed; its resolution comment carries the matrix result and the spec commit. **7. Handoff and closure.** The spec is written implementer-agnostic: spec + criteria register + ADRs + `CONTEXT.md` vocabulary form the complete handoff. The task ticket closes the map once the spec is committed, the matrix is clean, and no tickets remain. Follow-up: [Write the Fenris redesign specification and close the map](https://git.bongbetic.com/xavierk/Fenris/issues/19)

xavierk closed this issue

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

xavierk referenced this issue

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

Chart Fenris’s persistent TUI monitoring redesign #1

xavierk referenced this issue

2026-08-31 18:13:48 +00:00

Write the Fenris redesign specification and close the map #19

Sign in to join this conversation.