Skip to content
KN-86 Deckline

ADR-0050: Mission Board visual — a hero → feed → peek reader, and the ui/peek pattern

Builds on: ADR-0036 (the renderer this draws with), ADR-0028 (Mission Control — the engine the board renders), ADR-0040 (the screen router) Behavior docs (unchanged): mission-control.md, orchestration.md — these gain a render cross-reference, not a behavior change.

Context

Section titled “Context”

The Mission Board’s appearance had diverged across three artifacts (the shipped two-column board.lsp, a draft spec, and a single-column demo mockup), and the shipped two-column render had a real defect — the contract rows overflowed their fixed left column into the ops panels. Rather than reconcile onto the cramped two-column look, the design was reworked (GWP-648, with Josh): the board is fundamentally a feed reader — a list of contracts you scroll, select, and open — so it should be built like one (the Emacs elfeed lineage: a search/list view + an entry view), not as a bespoke fixed-panel screen.

Decision

Section titled “Decision”

The Mission Board is a three-state feed-reader (design “E”):

  1. LANDING — a hero: the scale-5 CONTRACTS headline + the scale-4 T-MINUS countdown. The “you have arrived” screen.
  2. LIST — CDR opens the board: the hero shrinks to a thin band that keeps the countdown visible, and a full-width columnar contract feed (THREAT · PAYOUT · DOMAIN) fills the body with an inverted column header — the elfeed *elfeed-search* pattern. The cursor row inverts (§4/§8.2). Full width means the rows cannot overflow — the old two-column defect is gone by construction.
  3. PEEK — INFO on a row opens a Notion-style detail panel docked to the right: the list stays visible on the left, the detail rides on top. EVAL accepts, NIL closes.

BACK/TERM remain the router-owned screen-exit edges.

ui/peek — a reusable overlay pattern (not a board one-off)

Section titled “ui/peek — a reusable overlay pattern (not a board one-off)”

The right-docked detail panel is a general component, ui/peek (ui/ui/compositing.lsp), built on the existing ui/modal composition (clear interior → drop shadow → double-line cbox with the §6.1 title cutout → body thunk). It is an overlay (no full scrim), so the list reads through to its left; the double-line frame is the §6 “on top / focused” cue. Any screen or program with a list + a per-item detail mounts the same side peek (a program’s record view, a search-result entry). This is the repeatable pattern the redesign establishes; for a dimmed full-takeover, callers scrim first and use ui/modal directly.

No new C, no data-source change

Section titled “No new C, no data-source change”

The feed reuses the existing (board/contract-at) rows and the peek reuses the (board/detail) string from the board_screen.c seam — zero C changes. The seam’s stub DeckState → live SystemState UDS wiring remains a separate task; it does not affect the look.

Consequences

Section titled “Consequences”
  • Positive: one decided, built, tested look; the contract-row overflow is structurally eliminated; the deck gains a reusable side-peek overlay (ui/peek); the board’s interaction now matches the feed-reader model the rest of the program tier uses.
  • Costs: the live filter line implied by the elfeed model is not yet wired — the feed is columnar + selectable but not yet filterable (a follow-on). The board is implemented as a deck/register-screen system screen drawing the feed-reader states, not (yet) a formal knEmacs define-major-mode; promoting it to a mode is a possible later refactor, not required for the look.
  • Superseded: the two-column ledger render and the single-column expand mockup (design/mockups/kn86-demo-site/screens/08-mission-board.png) are no longer the board’s look.

Captured render

Section titled “Captured render”

demos/board.gif (+ still demos/board.png), recorded through the live screen router with kn86rec --screen board (GWP-605); script runtime/tools/kn86rec/demos/board.rec.

Mission Board — the right-docked peek over the contract feed

Documentation Updates (REQUIRED — Spec Hygiene Rule 3)

Section titled “Documentation Updates (REQUIRED — Spec Hygiene Rule 3)”

No Canonical Hardware Specification value changes. The board honors 1024×600 / 128×75, amber-on-black, Row 0 + Row 74 firmware-owned.