Skip to content

nOSh BARE DECK — Terminal HUD

nOSh-Runtime-Level Experience — KN-86 Deckline Without Cartridge

Version 1.5 | Status: Playtest Design | Date: 2026-04-10 (last revised 2026-07-27)

CIPHER-LINE revision note (2026-04-24, scope corrected 2026-07-27): Live Cipher voice renders on the CIPHER-LINE OLED above the keyboard and never on the main grid (see docs/software/runtime/cipher-voice.md and adr/ADR-0015-cipher-line-auxiliary-display.md). This note originally read as deleting the CIPHER tab and reducing the HUD to four tabs; that was over-applied. The shipping deck registers a CIPHER tab as a main-grid metadata and captured-echo log view, which paints no live Cipher glyphs and so is fully compatible with OLED exclusivity. The live HUD is seven tabs (see “HUD Architecture”). The Null cartridge is the one sanctioned exception where Cipher glyphs appear on the main grid, via the cipher-main-grid-escape capability (ADR-0015 §3a); no nOSh runtime tab and no other cartridge may render Cipher on the main grid.


The KN-86 Deckline is an operational terminal FIRST, a cartridge platform second. The bare deck—the runtime-level HUD that appears when the device powers on with no capability module inserted—is genuinely useful and complete in itself. It is not a splash screen, not a loading state, not a menu waiting for real software. It is a pocket terminal that teaches the Deckline’s grammar, maintains the operator’s universal deck state, runs runtime-level bounties, hosts deck-to-deck interactions, and remains the transition layer when cartridges are swapped. The Cipher voice accompanies bare-deck sessions continuously on CIPHER-LINE; it does not appear on the main grid.

An operator who has never loaded a cartridge can still:

  • Boot a fresh deck and establish their identity
  • Earn credits through runtime bounties
  • Record and playback macros
  • Connect deck-to-deck via the Link protocol
  • Hear the Cipher voice ambiently on CIPHER-LINE
  • Manage system settings

The bare deck is where cartridge-less operators choose to stay, and where every other operator continuously returns to reorient between missions.


Universal Deck State is the operator’s permanent record: the identity, wallet and history that outlive every cartridge and every power cycle. The bare deck displays it; the nOSh runtime owns it.

Do not copy a DeckState listing into this doc. The struct is runtime/src/types.h and it has grown well past what earlier revisions of this section showed. That revision claimed “64 bytes of SRAM” and listed eight fields; the struct is now several kilobytes across a dozen, including the snippet library, the CIPHER persistence blob, REPL history, the Keyring keystore and the PROGS last-used table. A duplicated listing here went stale immediately and stayed stale.

Two properties the rest of this document depends on:

  • It is a file on the microSD (deck.state, written by deck.c). Nothing about it is battery-backed or volatile, whatever this section used to say.
  • It grows by appending, and a version bump migrates the file. An older file’s payload is a byte-prefix of the newer struct, so an upgrade copies what both layouts share and zero-fills the rest. The operator keeps their deck across a firmware update (ADR-0059; deck.c).

Superseded (2026-07-17, ADR-0042 / GWP-710): first boot is the Blank Slate flow of Deck Hub (first-party program #2). The canonical sequence (greeting, handle entry, the empty character sheet, the granted starter loadout, hand-off) lives in ../programs/deck-hub.md §“Blank Slate”. Handle entry uses numpad multi-tap text entry per ADR-0016 §6; the CAR/CDR letter-cycling entry mode this section previously described is retired. As built (2026-07-18): the runtime still routes to the standalone oobe char-picker screen (runtime/system-image/lib/deck/aux.lsp); the Blank Slate pass and the multi-tap rewire are unbuilt (implementation notes in the Deck Hub spec’s as-built callout).

Power on → nOSh runtime initializes display and audio → reads the operator handle field → handle is empty → the runtime routes to Deck Hub’s Blank Slate flow. On completion (identity established: handle recorded, credits and reputation zeroed, cipher seed initialized), the deck auto-lands on the STATUS tab and the HUD below takes over.

Power on → nOSh runtime initializes → reads operator handle from SRAM → handle exists.

  1. Kinoshita header (2 lines)
  2. Cipher greeting: Contextual text based on deck state (different every boot). Examples:
    • “OPERATOR GHOSTWIRE. WELCOME BACK.” (fresh session, known operator)
    • “GHOSTWIRE. 47 REPUTATION. THE BOARD IS WAITING.” (experienced operator)
    • “OPERATION SUSPENDED. AWAITING BLACK LEDGER. PHASE 2/3.” (mid-contract state)
  3. Auto-land on STATUS tab: Displays current deck state.

The bare deck uses the same navigation grammar as cartridges:

  • CDR: Cycle through tabs (left to right, wraps)
  • CAR: Enter the current tab’s interactive mode
  • BACK: Return to the tab strip from interactive mode
  • Tab indicator: Tab strip on Row 1 (ui/tab-bar), showing every tab name; the current tab is inverted

The seven nOSh-runtime-owned tabs, in registration (left-to-right) order:

  1. STATUS: identity and universal state summary
  2. CIPHER: metadata and captured-echo log (never live glyphs; ADR-0015)
  3. LAMBDA: macro recorder and executor
  4. LINK: deck-to-deck protocol and runtime bounties
  5. SYS: system settings, diagnostics, and operator management
  6. MISSIONS: router to the merged board system screen
  7. PROGS: the program launcher (ADR-0059)

Cipher voice runs continuously on CIPHER-LINE across all seven tabs and never paints the main grid. The CIPHER tab is a main-grid metadata and log view, which is a different thing.

In addition to CDR-cycling, the right-half digit keys jump directly to a tab. This is the NetWatch / octoscope digit-tab pattern (see docs/influences/synthesis.md §3 item 6), mapped onto the Ferris Sweep right-half digit cluster (1-2-3 / 4-5-6 / 7-8-9 per ADR-0031 §4.3). It is a convenience accelerator, not a replacement: CDR still cycles, and every digit jump lands the operator on the named tab exactly as if they had CDR’d to it.

DigitTabNotes
1STATUSIdentity / universal state summary
2CIPHERCIPHER metadata + captured-echo log. Never paints live CIPHER glyphs on the main grid (ADR-0015); see bare-deck-content-brief.md §4.
3LAMBDAMacro recorder and executor
4LINKDeck-to-deck protocol and runtime bounties
5SYSSystem settings, diagnostics, operator management, including the Aesthetic Mode picker (per ADR-0034). Digit 5 selects the SYS tab; the aesthetic picker lives inside SYS and is reached by CDR-ing to its row, not by a top-level digit.
6MISSIONSRoutes to the merged board system screen. The tab’s content area is a one-line hint; EVAL hands off.
7PROGSThe program launcher (ADR-0059, spec progs-launcher.md). Lists all fourteen k_programs[] entries flat; EVAL or APPLY launches the selected one.

Digit map corrected to as-built (2026-07-27, v1.5). This table previously described a four-tab HUD (1=STATUS, 2=LAMBDA, 3=LINK, 4=SYS) with digit 5 reserved for a future MISSIONS tab and digit 6 routing to the Deck Hub program. The shipping deck has not matched that for some time: runtime/system-image/lib/deck/deck.lsp registers STATUS, CIPHER, LAMBDA, LINK, SYS, MISSIONS, and ADR-0059 appends PROGS as the seventh. The CIPHER tab is a main-grid metadata and log view, which is compatible with CIPHER voice being OLED-exclusive (ADR-0015, canonical-spec.md Spec Hygiene Rule 6); the two are different things and the v1.1 note that removed the tab was over-applied. Deck Hub is reached from PROGS.

Behavior contract:

  • A digit jump is equivalent to CDR- cycling to the target tab: the runtime calls the leaving tab’s exit path and the arriving tab’s enter path, lands at tab level (the tab strip, not an interactive mode), and the arriving tab auto-refreshes its deck-state read.
  • Digit jumps are honored only at tab level. If the operator is inside a tab’s interactive mode (after CAR), digits are consumed by that mode as data entry (LFSR predictions, contrast/volume, handle characters, etc.) per each tab’s interaction table — they do not jump tabs. Press BACK to return to tab level first; then digits jump again. This keeps the “digits are data first” invariant (input-dispatch §3D / §9 invariant 8) intact: tab-jump is a tab-level affordance, data entry is a mode-level affordance, and the two never collide.
  • The jump set is STATUS-anchored: digit 1 always means STATUS regardless of which tab is current. There is no relative addressing.
  • Tab-jump is a Bare-Deck-only affordance. The moment a cartridge is inserted and its tabs appear at positions 5+, digit dispatch is governed by the reservation rule in input-dispatch.md §3D.1 — a loaded cart may reclaim digits 1-7 via the :override-digit-dispatch capability, in which case digit keys flow to the cart’s on_numpad handler and the operator uses CDR to cycle tabs.

The digit-jump tone is the same melodic tab-transition tone used by CDR (pitch tracks the destination tab index), so the audio feedback is consistent whether the operator cycled or jumped.


The identity screen. This is where the bare deck boots, where every operator lands between cartridge sessions, and where the fiction becomes personal.

The capability roster surfaces the four tier model from mission-control.md §2.2. System tier (the four runtime baselines TERMINAL / GRID / AUDIT / SONAR per ADR-0030) is rendered separately from cart-tier registry entries. System entries have no provenance, no last-seen timestamp, and no [INSERT TO RESTORE] affordance — they are always present.

Row 0: ┌─ STATUS • LAMBDA • LINK • SYS ────────────────────────┐
Row 1: └────────────────────────────────────────────────────────┘
Row 2: OPERATOR: GHOSTWIRE
Row 3: REPUTATION: ████████░░ 47 CREDITS: 2,840 ¤
Row 4: ────────────────────────────────────────────────────────
Row 5: SYSTEM CAPABILITIES (always-on, runtime-shipped):
Row 6: [◆] TERMINAL — :penetrate threat 1-2
Row 7: [◆] GRID — :grid-calibration threat 1
Row 8: [◆] AUDIT — :audit-trace threat 1-2
Row 9: [◆] SONAR — :sonar-sweep threat 1-2
Row 10: ────────────────────────────────────────────────────────
Row 11: CARTRIDGE REGISTRY:
Row 12: [■] ICE BREAKER INSERTED threat 1-6 (supersedes TERMINAL)
Row 13: [▣] BLACK LEDGER Recent (12d) threat 2-5 (supersedes AUDIT)
Row 14: [□] NEONGRID Historical [INSERT TO RESTORE]
Row 15: [ ] DEPTHCHARGE — (never registered)
Row 16: ────────────────────────────────────────────────────────
Row 17: PHASE CHAIN:
Row 18: Phase 2/3: EXTRACTION → AUDIT (awaiting BLACK LEDGER)
Row 19: ────────────────────────────────────────────────────────
Row 20: LAMBDA SLOTS:
Row 21: λ1: [■■■■░░░░] 14 steps λ5: [░░░░░░░░] empty
Row 22: λ2: [■■░░░░░░] 8 steps λ6: [░░░░░░░░] empty
Row 23: RUNTIME: nOSh v2.4 | UPTIME: 00:14:32 | CIPHER: ONLINE
Row 24: [INFO: details EVAL: refresh CAR: drill BACK: ↑]

Glyph key:

  • [◆] — System tier (always present; never decays; no cart relationship recorded here — see software/runtime/baselines/<name>.md for each baseline’s spec)
  • [■] — Inserted (cart in slot right now)
  • [▣] — Recent (within decay window; not currently inserted)
  • [□] — Historical (aged out of decay window; visible as memorial; insert restores)
  • [ ] — Never registered (cart never loaded into this deck)

Supersedes annotation. When a cart in any non-System tier declares :supersedes :baseline, the cart’s row carries a (supersedes BASELINE) annotation. The corresponding System row’s selection weight is internally at 5% but the row remains rendered — System entries don’t disappear when superseded; their gameplay role just shifts to variety floor (per mission-control.md §3.2.3).

Fresh Deck (First Boot After Handle Entry)

Section titled “Fresh Deck (First Boot After Handle Entry)”
Row 2: OPERATOR: GHOSTWIRE (just entered)
Row 3: REPUTATION: ░░░░░░░░░░ 0 CREDITS: 0 ¤
Row 5: SYSTEM CAPABILITIES (always-on, runtime-shipped):
Row 6: [◆] TERMINAL — :penetrate threat 1-2
Row 7: [◆] GRID — :grid-calibration threat 1
Row 8: [◆] AUDIT — :audit-trace threat 1-2
Row 9: [◆] SONAR — :sonar-sweep threat 1-2
Row 11: CARTRIDGE REGISTRY:
Row 12: [ ] ──────── — (no carts ever registered)
Row 18: PHASE CHAIN: NONE
Row 21: LAMBDA SLOTS: ALL EMPTY

A fresh deck out of the box has the four System-tier baselines and nothing else. The mission board immediately offers training-tier contracts across all four domains (per ADR-0030).

  • CAR: Enter capability roster — drill into a registered module’s contract history. For System entries, drills into the baseline’s spec (verb mechanics, pattern library, defcontract-schema forms). For cart entries, drills into the cart’s contract history (total contracts completed, cumulative credits earned from that module, reputation threshold met).
  • INFO: Toggle between summary (above) and detailed breakdown. Double-tap for deep diagnostics: RAM usage, SRAM CRC, cartridge history bitfield displayed in binary.
  • EVAL: Refresh deck state (re-read SRAM from hardware, useful after a cartridge session).
  • CDR: Cycle to LAMBDA tab.
  • BACK: (Already at tab level; no-op.)

Macro recorder and executor. nOSh-runtime-level recorded key sequences that persist in SRAM across all cartridges.

Naming unified (2026-07-18, Josh; v1.4): a recorded macro is one kind of Lambda-slot occupant in the ADR-0040 §12 loadout: one system, one name. This tab is the authoring surface (record, edit, merge, compare, name); equipping a recorded lambda into a Lambda slot happens in Deck Hub (../programs/deck-hub.md Tier 3 §3.1). The eight 32-step recording positions on this tab are the macro library; text below (and the STATUS summary) that calls them “lambda slots” reads as the library, and there is no second slot system.

An operator can record up to 8 macros, 32 steps each. Steps are key names (not decoded input; the nOSh runtime records which key was pressed). On playback, the nOSh runtime re-executes those key presses in sequence with 200ms delays between steps.

Lambda macros are nOSh-runtime-owned, not cartridge-owned. They survive cartridge swaps. An operator can record a boot-check macro on the bare deck and replay it inside an ICE BREAKER contract.

Row 0: ┌─ STATUS • LAMBDA • LINK • SYS ────────────────────────┐
Row 1: └────────────────────────────────────────────────────────┘
Row 2: LAMBDA EDITOR
Row 3: ────────────────────────────────────────────────────────
Row 4: SLOT 1: ████████████████░░░░░░░░░░░░░░░░ 14/32 steps
Row 5: 01: INFO 02: CDR 03: CDR 04: CAR 05: EVAL
Row 6: 06: BACK 07: CDR 08: CAR 09: APPLY 10: EVAL
Row 7: 11: BACK 12: BACK 13: QUOTE 14: EVAL
Row 8: ────────────────────────────────────────────────────────
Row 9: SLOT 2: ████████░░░░░░░░░░░░░░░░░░░░░░░░ 8/32 steps
Row 10: 01: CDR 02: CDR 03: CDR 04: CDR 05: CDR
Row 11: 06: CAR 07: INFO 08: BACK
Row 12: ────────────────────────────────────────────────────────
Row 13-20: [Slots 3–8, same format; most likely empty]
Row 21: ────────────────────────────────────────────────────────
Row 22: MODE: VIEW | SELECTED: SLOT 1 | RECORDING: OFF
Row 23: ────────────────────────────────────────────────────────
Row 24: [LAMBDA: record EVAL: playback NIL: clear CONS: merge]

Tab Navigation:

  • CDR: Cycle through slots 1–8 (in VIEW mode).
  • CAR: Select current slot for editing (enters EDIT mode, shows step-by-step breakdown).

View Mode (default):

  • LAMBDA: Start recording into selected slot. Display changes to “RECORDING: ON”. All subsequent key presses (except BACK, which is reserved for abort) are captured as steps. Maximum 32 steps. Press LAMBDA again to stop recording. Progress bar updates in real-time.
  • EVAL: Playback selected slot’s macro sequence. The nOSh runtime executes each step with 200ms delays. Can be interrupted by pressing BACK.
  • NIL: Clear selected slot (confirmation required: press EVAL to confirm, any other key to abort).
  • CONS: Merge two slots. Enter EDIT mode for slot A. Press CONS. Then CDR to slot B. Press CONS again to confirm. The nOSh runtime concatenates A + B (up to 32 steps total; excess steps are truncated) and writes the result to the next available slot. If all slots are full, merge fails (show error: “ALL SLOTS FULL”).
  • ATOM: Test whether selected slot is empty. Returns a visual indicator (hollow bar for empty, filled bar for occupied).
  • EQ: Compare two slots side-by-side. CDR to select slot A. Press EQ. CDR to slot B. Press EQ to confirm. Display shows a diff view: step-by-step comparison. Highlights differences (useful for debugging macros).

Edit Mode (after CAR on a slot):

  • CDR: Cycle through individual steps in the macro. Display shows the current step number and key name.
  • EVAL: Toggle the current step. If the step is populated, mark it for deletion (shown as ”────” in the list). If empty, skip to the next populated step.
  • BACK: Exit EDIT mode, return to VIEW mode.

Lambda macros teach:

  • Repetition: An operator records a tab-cycling sequence and plays it back 10 times. The device obeys. The operator learns that the Deckline responds to patterns.
  • Composition: The CONS operator allows merging, building complex macros from simple ones.
  • Testing: EQ allows side-by-side comparison, teaching operators to debug their own recorded sequences.

Deck-to-deck protocol interface. The 3.5mm TRRS serial port connects two KN-86 units at 9,600 baud using a simple framing protocol (nOSh LINK v1).

The bare deck hosts three types of Link interactions: connection diagnostics, operator challenges (runtime bounties), and deck state comparison.

Note (2026-05-03): The solo and cooperative bounties listed below (DIAGNOSTIC, LFSR EXERCISE, LFSR SYNC, ECHO TEST, DECK COMPARE) are themselves Mission Control schemas registered by the runtime — not LINK-specific specials. They surface here because the LINK tab is their natural entry point, but they flow through the same defcontract-schema / TTL / payout-formula machinery as cartridge-registered contracts. See mission-control.md §2 (the runtime registers :bare-deck capabilities at boot) and §3 (schema model). The board on the MISSIONS tab and the bounties listed here are two views over the same registry.

Row 0: ┌─ STATUS • LAMBDA • LINK • SYS ────────────────────────┐
Row 1: └────────────────────────────────────────────────────────┘
Row 2: LINK PROTOCOL
Row 3: ────────────────────────────────────────────────────────
Row 4: STATUS: NO CONNECTION
Row 5: PORT: 3.5mm TRRS | BAUD: 9600 | PROTOCOL: nOSh LINK v1
Row 6: ────────────────────────────────────────────────────────
Row 7: LINK HISTORY:
Row 8: Last connected: OPERATOR SIGNAL | 2 days ago
Row 9: Total links: 14 | Unique operators: 3
Row 10: ────────────────────────────────────────────────────────
Row 11: NOSH RUNTIME CHALLENGES (solo):
Row 12: [!] DIAGNOSTIC (5¤) — Verify hardware systems
Row 13: [!] LFSR EXERCISE (5¤) — Predict LFSR sequence
Row 14: ────────────────────────────────────────────────────────
Row 15: LINK CHALLENGES (cooperative):
Row 16: [ ] LFSR SYNC — timing puzzle (10¤ each, when linked)
Row 17: [ ] ECHO TEST — latency race (5¤ winner, when linked)
Row 18: ────────────────────────────────────────────────────────
Row 19: SOLO BOUNTY BALANCE: 10¤ available
Row 20: ────────────────────────────────────────────────────────
Row 24: [LINK: ping EVAL: accept INFO: details BACK: ↑]
Row 4: STATUS: CONNECTED — OPERATOR SIGNAL (latency: 12ms)
Row 5: PORT: ACTIVE | SIGNAL STRENGTH: ████████░░
Row 6: ────────────────────────────────────────────────────────
Row 7: REMOTE DECK STATE:
Row 8: OPERATOR: SIGNAL | REP: 23 | CR: 1,200¤ | RUNTIME: v2.4
Row 9: CAPABILITIES: ICE BREAKER, DEPTHCHARGE
Row 10: ────────────────────────────────────────────────────────
Row 11: LINK CHALLENGES (available now):
Row 12: [!] LFSR SYNC — cooperative timing puzzle (10¤ each)
Row 13: [!] ECHO TEST — competitive latency race (5¤ winner)
Row 14: [ ] DECK COMPARE — state diff analysis (0¤ diagnostic)
Row 15: ────────────────────────────────────────────────────────
Row 16: COMBINED BOUNTY POOL: 25¤ available
Row 20: ────────────────────────────────────────────────────────
Row 24: [LINK: ping EVAL: start EQ: compare INFO: details]

No Connection:

  • LINK: Ping (send handshake packet on the serial port). If another KN-86 is connected and listening, it responds. Display updates to show connection.
  • CAR: Enter a solo challenge’s detail view (show rules and payout).
  • EVAL: Accept and start a solo challenge.
  • INFO: Show port diagnostics (baud rate verification, packet error rate, signal strength if connected).

Connected:

  • LINK: Send a keepalive ping. Display updates latency.
  • CAR: Enter a challenge’s detail view.
  • EVAL: Accept and start a cooperative challenge (or initiate a competitive challenge).
  • EQ: Initiate deck state comparison (side-by-side view of both operators’ deck state).
  • INFO: Show remote deck state details (full operator stats, capability list).

These bounties can be completed on any deck, without Link:

DIAGNOSTIC (5¤, once per boot cycle)

  • The nOSh runtime prompts the operator to press each of the 31 keys in sequence.
  • After all keys are pressed, the nOSh runtime verifies:
    • Display renders correctly (changes color briefly per key).
    • Audio response: each key triggers a subtle tone (3 different tones in sequence per key press).
    • SRAM read/write: a test pattern is written and read back.
  • On completion: “HARDWARE VERIFIED. DIAGNOSTIC COMPLETE.” Operator earns 5¤.
  • Useful as a health-check on power-up.

LFSR EXERCISE (5¤, repeatable, ~3 min, difficulty scales with reputation)

  • The nOSh runtime displays a number sequence at row 2: “SEQUENCE: 42 → 17 → 68 → 34 → ?”
  • The sequence is derived from the deck’s LFSR (4 visible transitions).
  • Operator enters the predicted next value via numpad (0–999, 3 digits) + EVAL.
  • Difficulty: at rep 0–10, sequences are simple (always increment/decrement). At rep 35+, sequences use XOR patterns (harder to predict).
  • On success: “+5¤”. A new sequence is offered.
  • Tests pattern recognition and LFSR literacy.

These require two KN-86 units connected via Link:

LFSR SYNC (10¤ per operator, cooperative, ~2 min)

  • Both decks display a scrolling 4-digit number sequence (derived from each deck’s LFSR).
  • The sequences are deterministic but initially out of sync.
  • Operators must press EVAL simultaneously when the sequences align (match the same value).
  • The nOSh runtime uses latency measurement to determine if presses were within ~100ms of each other.
  • On success (both pressed within window): both decks display “SYNC CONFIRMED. +10¤ EACH”. Both operators earn 10¤.
  • On failure (one press too early or late): “SYNC FAILED. TRY AGAIN.”
  • Teaches: timing coordination, LFSR observation, cooperative gameplay.

ECHO TEST (5¤ winner, competitive, ~1 min)

  • The nOSh runtime on one deck (randomly selected) plays a distinct tone (500Hz + 1000Hz harmonics, 200ms).
  • The other operator must press EVAL as quickly as possible after hearing the tone.
  • Latency is measured (time from tone playback to EVAL press).
  • Display shows: “LATENCY: 245ms. OPPONENT LATENCY: 310ms. YOU WIN. +5¤”
  • Loser sees: “LATENCY: 310ms. OPPONENT LATENCY: 245ms. YOU LOSE. +0¤”
  • Tests audio response and reflexes. Teaches audio feedback importance.

DECK COMPARE (0¤, diagnostic, ~2 min)

  • Displays a side-by-side table of both decks’ state:
    FIELD | YOUR DECK | SIGNAL'S DECK
    ─────────────────────────────────────────────────
    OPERATOR | GHOSTWIRE | SIGNAL
    REPUTATION | 47 | 23
    CREDITS | 2,840¤ | 1,200¤
    CAPABILITIES (4) | ICE/NEO/BLK | ICE/DEP
    ACTIVE PHASE | 2/3 (BLACK) | NONE
    LAMBDA SLOTS (3) | YES | YES
    LFSR SEED | 0xA7F3 | 0x2C84
  • Not a bounty (0¤ payout). Used for diagnostics, reputation comparison, and friendly rivalry.
  • Teaches: competitive context-awareness.

System management, settings, and diagnostics.

Row 0: ┌─ STATUS • LAMBDA • LINK • SYS ────────────────────────┐
Row 1: └────────────────────────────────────────────────────────┘
Row 2: SYSTEM
Row 3: ────────────────────────────────────────────────────────
Row 4: DISPLAY
Row 5: Contrast: ████████░░ 80% [numpad +/- to adjust]
Row 6: Backlight: ON [toggle with EVAL]
Row 7: Aesthetic Mode: AMBER [EVAL: cycle]
Row 8: ────────────────────────────────────────────────────────
Row 9: AUDIO
Row 10: Volume: ██████░░░░ 60% [numpad +/- to adjust]
Row 11: PSG: YM2149F (3-voice + noise) [EVAL: test tone]
Row 12: Key Click: ON [toggle with EVAL]
Row 13: ────────────────────────────────────────────────────────
Row 14: OPERATOR
Row 15: Handle: GHOSTWIRE [CAR: edit]
Row 16: First Boot: 2026-03-15 [info only]
Row 17: Sessions: 47 [info only]
Row 18: ────────────────────────────────────────────────────────
Row 19: NOSH RUNTIME
Row 20: Version: nOSh v2.4 [info only]
Row 21: Target: PICO2 | Build: 2026-04-01
Row 22: SRAM: 64/64 bytes used | CRC: OK
Row 23: FACTORY RESET: [hold NIL + EVAL + SYS for 3s]
Row 24: [CAR: edit field +/-: adjust EVAL: test/toggle BACK: ↑]

Tab Navigation:

  • CDR: Cycle through sections (DISPLAY → AUDIO → OPERATOR → RUNTIME → DISPLAY).
  • INFO: Show detailed help for the current section.

Numeric Adjustment (Contrast & Volume):

  • Numpad +: Increase (contrast 0–100%, volume 0–100%).
  • Numpad −: Decrease.
  • Display updates in real-time.
  • Changes persist in SRAM after EVAL is pressed (commit).

Toggles (Backlight, Key Click):

  • EVAL: Toggle the current field on/off.
  • Display updates immediately.
  • Persists in SRAM.

Aesthetic Mode Cycler (DISPLAY → Aesthetic Mode row):

Picker contract per ADR-0034. The roster is runtime-locked to three modes: AMBER (default), AMBER (warmer), CIPHER (desaturated for reading). The picker is a single-axis cycler on one row — modeled on PulseDeck / NetWatch / AetherTune t-cycle pattern (not on the os-models-4.png full-editor save-row pattern, which is over-scoped for a single-axis choice).

  • CDR: Navigate to the Aesthetic Mode row.
  • EVAL: Cycle the active mode AMBER → WHITE → GREEN → AMBER. Each press:
    1. Writes the new mode to nosh-config.toml [aesthetic].mode immediately (no separate “save” affordance).
    2. Triggers a full-screen redraw with the new mode’s rendering deltas (glyph treatment per ADR-0014 F1, CIPHER-LINE cadence, scanline/ghost overlay floor) applied in-place.
    3. The row label updates to the new mode name on the next redraw tick.
  • INFO: Show per-mode detail — name, role description, rendering deltas, and the “AMBER applies a Low overlay regardless of user setting” note (per ADR-0034 §4.3 risk).
  • No live-preview hover. The mode changes on EVAL; there is no separate “preview then commit” two-step. The picker’s whole job is the single press.
  • No carts may change the mode. (get-aesthetic-mode) is the cart-readable surface (ADR-0034 §5); there is no set-aesthetic-mode primitive in any FFI tier. The operator owns the mode.

Persistence: The active mode is read from /home/shared/nosh-config.toml at boot (cached in SystemState); writes happen on picker-confirm. Missing-or-invalid value falls back to AMBER with a one-line warning to the firmware-status row. The mode does not persist in Universal Deck State — UDS is reserved for cartridge-agnostic operator identity (handle / credits / reputation / cartridge history / phase chain / cipher seed), not device-configuration settings (ADR-0034 §2).

Operator Handle Edit:

  • Navigate to OPERATOR section.
  • CAR: Enter handle editor (numpad multi-tap text entry per ADR-0016 §6, the same input method as first-boot handle entry in Deck Hub’s Blank Slate flow; EVAL confirms).
  • New handle is written to SRAM immediately.

Audio Test:

  • Navigate to AUDIO section.
  • EVAL: Plays a test tone (harmonic sweep: 440Hz → 880Hz → 1760Hz, 200ms each).
  • All three YM2149 voices play in sequence, confirming PSG operation.

Factory Reset:

  • Navigate to bottom (row 23).
  • Simultaneously hold: NIL + EVAL + SYS for 3 seconds.
  • nOSh runtime modal warning on the main grid: “THIS WILL ERASE YOUR IDENTITY. ARE YOU CERTAIN?” (CIPHER-LINE fragment in parallel: erase. are you sure.).
  • EVAL: Confirm reset. SRAM is wiped. Deck returns to first-boot state (handle prompt).
  • Any other key: Cancel. Return to SYS tab.

Every key on the Deckline has a runtime-level function on the bare deck. There are no “dead” keys (except when a key is context-irrelevant).

KeyBare Deck Function
CAREnter current tab’s interactive mode / cycle letters in text edit
CDRCycle to next tab / cycle letters in text edit (opposite direction of CAR)
BACKReturn to tab strip from interactive mode / cancel text entry
EVALContext-dependent confirm: refresh, generate passage, accept challenge, toggle setting, test audio
INFOContext-dependent inspect: show details, statistics, diagnostics (double-tap for deep view)
QUOTEBookmark: seed-capture the current CIPHER-LINE fragment, save deck state snapshot (creates quote slot entry)
LAMBDAStart/stop macro recording (2s hold to begin) / play recorded macro from current slot
CONSMerge two lambda slots / combine quote references
NILClear/discard: empty a lambda slot, clear a bookmark, initiate factory reset
ATOMTest emptiness: is this lambda slot used? is this field populated?
EQCompare: two lambda slots side-by-side, two deck states via link
APPLYLaunches the selected program on the PROGS tab (ADR-0059); inert on the other six tabs. APPLY deploys tools, and PROGS is the deck’s own toolkit.
LINKPing: initiate or check Link connection / send Link protocol packet
SYSJump directly to SYS tab from anywhere / hold 2s for power menu (sleep, shutdown)
Numpad 1–7 (at tab level)Direct tab jump: 1=STATUS, 2=CIPHER, 3=LAMBDA, 4=LINK, 5=SYS, 6=MISSIONS, 7=PROGS (see “Numbered-Tab Navigation”). At tab level only; inside an interactive mode, digits are data.
Numpad 0–9, . , ENTData entry in text edit, number input, challenge responses, adjustment (digit tab-jump applies only at tab level)
+, −Increment/decrement (volume, contrast, etc.)

Key insight (revised 2026-07-27, v1.5). APPLY was previously the one key with no bare-deck function, on the reasoning that APPLY deploys tools and an empty deck has none. ADR-0059 closes that gap in the one place where it is fictionally correct: the PROGS tab is the deck’s toolkit, so APPLY deploys there. It stays inert on the other six tabs, so the “APPLY needs something to deploy” lesson survives; what changed is that the bare deck turned out to carry tools of its own.


When a cartridge is physically inserted into the SPI slot:

  1. Hardware detect pin goes high. The nOSh runtime polls this pin every 100ms.
  2. Cipher voice: “MODULE DETECTED. READING HEADER.”
  3. SPI read sequence (1–2 seconds): The nOSh runtime reads the 256-byte cartridge header from flash.
  4. Display transition: Amber flash. Cartridge name, class, and version appear center-screen.
  5. Cipher greeting: Contextual, based on cartridge + deck state. Example (ICE BREAKER, first insertion): “ICE BREAKER LOADED. YOUR FIRST INTRUSION AWAITS.” Example (BLACK LEDGER, mid-career): “WELCOME BACK TO THE LEDGER. PHASE 2 AWAITS.”
  6. Tab expansion: The four nOSh runtime tabs (STATUS, LAMBDA, LINK, SYS) remain at positions 1–4. Cartridge-specific tabs appear at positions 5+. CDR past the last cartridge tab wraps back to STATUS (the nOSh runtime tabs are always accessible).
  7. Auto-land: The nOSh runtime lands on the cartridge’s first tab (usually a mission board or operation summary).

When a cartridge is physically removed:

  1. Hardware detect pin goes low.
  2. If mid-mission: Phase chain state is saved to SRAM (if the cartridge is cooperative). Cipher voice: “MODULE REMOVED. PHASE STATE PRESERVED.” (or “MODULE REMOVED. NO ACTIVE PHASE.” if no mission was running).
  3. Cartridge-specific tabs vanish.
  4. Immediate return to bare deck: STATUS tab appears.
  5. Cipher reflection: “AWAITING MODULE. YOUR PHASE CHAIN ENDURES.” (if a phase was suspended) or “MODULE SLOT EMPTY.” (if cartridge was idle).

This is the hot-swap mechanic: the bare deck is the transition state. An operator swaps from ICE BREAKER to BLACK LEDGER mid-contract by removing one and inserting the other. The phase chain persists. The operator returns to the bare deck for 2–3 seconds, then loads the next cartridge.


An operator who spends 10 minutes on the bare deck before loading their first cartridge has already internalized the complete Deckline grammar:

Grammar ElementLearned on Bare DeckLater Applied in Cartridges
CDR traversalTab cycling (4 nOSh runtime tabs)Mission board navigation, roster traversal
CAR entryInteractive mode (settings, macros)Cartridge-specific operations, tool selection
BACK returnExit interactive modeUndo/retreat in cartridge contexts
EVAL confirmRefresh, generate, acceptExecute mission phase, deploy tool
INFO inspectDetails, statisticsMission briefs, intel reports
QUOTE bookmarkSeed-capture CIPHER-LINE fragmentMark critical intel, flag objectives
LAMBDA recordMacro recording(Remains runtime-level; works in cartridges)
CONS combineMerge macros(Future: combine cartridge tools or merge mission chains)
NIL discardClear slots, factory resetAbandon mission, reset phase
ATOM testCheck slot occupancyTest mission status, verify inventory
EQ compareLambda comparison, deck-state diffCompare two mission objectives, parallel analysis
APPLY deploy(Inactive; no tools)Primary cartridge action: deploy hacking tools, intrusion vectors, audit routines
LINK contactDeck-to-deck ping, challengesMulti-operator missions (future cartridges)
SYS systemSettings, diagnosticsEmergency override, system settings within cartridge context

The bare deck teaches OODA: Observe (display state), Orient (understand meaning), Decide (navigate and select), Act (press keys). An operator cycles through this loop hundreds of times before a cartridge ever loads.


The YM2149 PSG is active and audible at all times:

  • Boot chord: Distinctive harmonic power-up sound (three voices: C, E, G at 440Hz register, 300ms).
  • Key clicks: Subtle 8-bit tone on every key press (voice 1, 1000Hz, 50ms, ADSR envelope).
  • Tab transition: Short melodic tone when CDR cycles (pitch rises as you cycle through tabs).
  • Cipher generation: Soft ambient tone while Cipher renders a fragment on CIPHER-LINE (voice 2, low-frequency drone, 100–200Hz).
  • Passage matched/complete: Resolution chord (three voices, major third interval, 200ms).
  • Error/failure: Descending tone (voice 3, two-step minor descent, 100ms).
  • Link ping: Distinctive bi-frequency ping (voice 1 + voice 2, 440Hz + 554Hz, 150ms).
  • Bounty earned: Satisfying ascending resolution (voices 1+2+3, arpeggio, 400ms).

The bare deck’s audio is quieter and more ambient than cartridge operation. Cartridges may use the PSG for dialogue, alarm tones, or intense music. The bare deck uses it for ambient feedback and confirmation.


  1. Power on → first-boot sequence → enter handle “ROGUE”
  2. Boot into STATUS tab → see all zeros. CIPHER-LINE OLED above the keyboard lights with a first-boot greeting.
  3. CDR to LAMBDA → record a 3-step macro: CDR, CDR, CDR (tab cycling). Play it back. It works.
  4. CDR to LINK → press LINK (ping). No connection. See solo challenges.
  5. Press EVAL on DIAGNOSTIC challenge. Verify all 31 keys. Earn 5¤. New balance: 5¤.
  6. Return to bare deck. STATUS tab shows: CREDITS: 5¤. CIPHER-LINE murmurs a clipped reflection.
  7. CDR to SYS → adjust volume. Exit.
  8. Insert ICE BREAKER cartridge. Cipher voice greets on CIPHER-LINE. New tabs appear on the main grid. Begin first mission.

What the operator learned: Navigate (CDR), enter (CAR), record (LAMBDA), earn (bounties), explore (LINK). They haven’t loaded a cartridge yet, but they understand the device.

  1. Power on → auto-land on STATUS tab. CIPHER-LINE whispers a rep-tier reflection.
  2. See active phase chain: “Phase 2/3: EXTRACTION → AUDIT”
  3. Reputation: 47. Credits: 2,840¤. Three cartridges registered.
  4. A CIPHER-LINE fragment drifts past: “the last cartridge awaits.” They catch it in their peripheral vision and use QUOTE to seed-capture it.
  5. CDR to LAMBDA → review custom macros (one for “boot check”, one for “extraction sequence”).
  6. CDR to LINK → connected to another operator. Start LFSR SYNC challenge. Both earn 10¤.
  7. Return to bare deck. Remove cartridge. Insert BLACK LEDGER. Phase chain resumes. CIPHER-LINE marks the swap.

What the operator experienced: The bare deck is home. It tracks their progress, celebrates their history, and mediates their tool changes.


The bare deck is not a loading screen. It is:

  1. A genuine operational terminal: All four nOSh runtime tabs are useful, playable, and progress the operator’s reputation and credits.
  2. The operator’s identity anchor: The STATUS tab is their deck. Their handle, their reputation, their history.
  3. The fiction layer: The Cipher is the device’s voice. It speaks to them personally on CIPHER-LINE and evolves as they do.
  4. The grammar teacher: Every key except APPLY has a clear, consistent function. New operators learn rapidly.
  5. The hot-swap hub: When cartridges are swapped, the bare deck is the transition state. Phase chain state persists. The operator always returns here between missions.
  6. The economy foundation: nOSh runtime bounties keep the deck alive and generate credits even without a cartridge.
  7. A test of hardware: The DIAGNOSTIC challenge verifies that the device is functioning correctly.

The bare deck is where the KN-86 becomes personal.


VersionDateNotes
1.02026-04-10Playtest specification. Five-tab HUD, runtime bounties, hot-swap mechanics, onboarding grammar.
1.12026-04-24CIPHER-LINE reconciliation: CIPHER tab removed from main grid; HUD is now four tabs (STATUS, LAMBDA, LINK, SYS). CIPHER CALIBRATION and CIPHER RELAY bounties dropped. Cipher voice now exclusively on CIPHER-LINE OLED (see ADR-0015).
1.22026-06-07Numbered-tab navigation (NetWatch pattern, synthesis §3 item 6): right-half digits jump directly to tabs (1=STATUS, 2=LAMBDA, 3=LINK, 4=SYS) at tab level; digit 5 reserved for a future MISSIONS tab. Digit jumps honored only at tab level; inside interactive modes digits remain data. Cart override governed by :override-digit-dispatch (input-dispatch §3D.1). Corrected the stale “1-5 → STATUS/CIPHER/…” reference list (CIPHER is OLED-exclusive post-v1.1).
1.32026-07-17First-boot supersession (ADR-0042 / GWP-710): the first-boot sequence is Deck Hub’s Blank Slate flow (../programs/deck-hub.md); handle entry is numpad multi-tap per ADR-0016 §6, retiring the CAR/CDR letter-cycling entry mode here and in the SYS handle editor.
1.52026-07-27Seven-tab HUD reconciled with as-built (ADR-0059). Corrected the digit map, which described four tabs against the six that shipped: live order is STATUS / CIPHER / LAMBDA / LINK / SYS / MISSIONS, plus PROGS appended at 7. APPLY gains a bare-deck function on PROGS only. Deck Hub is reached from PROGS. Spec: progs-launcher.md.
1.42026-07-18Two Josh rulings (GWP-710 Tier 3): digit 6 routes to Deck Hub at tab level (digit map extended; 5 stays reserved for MISSIONS; a program route, so the HUD stays four tabs), and Lambda naming unified with the ADR-0040 §12 loadout: a recorded macro is a Lambda-slot occupant, this doc’s LAMBDA tab is the authoring surface, its eight recording positions are the macro library.

These are legacy passage templates showing the Cipher’s voice identity by reputation tier. They predate the CIPHER-LINE reconciliation and read as multi-line passages; on the current device the Cipher engine selects individual clipped fragments from this space and renders them to CIPHER-LINE, one fragment at a time. The templates below are preserved as a reference for tone and vocabulary. See docs/software/runtime/cipher-voice.md for the canonical clipped-fragment production grammar.

Tier 0 (0–9 reputation): Potential & Instruction

EMPTY SLOTS. CLEAN REPUTATION. / EVERYTHING AHEAD OF YOU. / THE BOARD IS QUIET. / INSERT A MODULE TO BEGIN OPERATIONS.

FIRST SESSION. YOU ARE LEARNING. / EACH CARTRIDGE TEACHES SOMETHING NEW. / THE LFSR WILL SPEAK TO YOU LATER.

WELCOME, OPERATOR. / THE SLOT ACCEPTS ONLY VERIFIED MODULES. / KINOSHITA ELECTRONICS CONSORTIUM. SINCE 1997.

Tier 1 (10–34 reputation): Reflection & Caution

YOU RAN EXTRACTION CONTRACTS. YOU UNDERSTAND INTRUSION. / THE GRID TEACHES PATTERNS. / REPUTATION FOLLOWS COMPETENCE.

PHASE CHAIN ACTIVE. MULTI-PHASE OPERATION DETECTED. / YOUR PERSISTENCE IS NOTED. / FINISH WHAT YOU STARTED.

FOURTEEN CONTACTS VIA LINK. YOU ARE NOT ALONE. / THE NETWORK REMAMBERS YOU.

Tier 2 (35+ reputation): Philosophy & Lore

FORTY-SEVEN REPUTATION. THE CONSORTIUM REMAMBERS YOU. / THERE ARE PATTERNS IN THE LFSR I HAVEN’T SHOWN YOU YET.

YOU ARE READY FOR THE LAST CARTRIDGE. / ASK ME ABOUT THE FOUNDING.

THE DEVICE WAS BUILT BY THOSE WHO BELIEVED IN OPERATORS LIKE YOU.


LEFT HAND (Function Keys): RIGHT HAND (Phone-layout Numeric + Lisp Punctuation):
┌─────────────────────┐ ┌──────────────────┐
│ QUOTE CONS NIL FN │ 1 2 3 / │
│ INFO CAR APPLY SYS │ 4 5 6 ; │
│ LINK BACK CDR ATOM │ 7 8 9 - │
│ ╔════════ EVAL ════════╗ EQ │ * 0 # ENT│
└─────────────────────┘ └──────────────────┘

Data grid is phone layout (1-2-3 top, 0 bottom-center) per ADR-0016 §5; right-column primaries (/, ;, -) and bottom-row outer keys (*, #) are finalized per ADR-0022. Shift secondaries (", :, +, (, )) and the 1-key backtick shift are documented in ADR-0022 §2. The FN keycap is the printed legend for the canonical LAMBDA key (cosmetic alias only). See docs/software/runtime/input-dispatch.md §1.

The EVAL key is a 1.75U-wide confirm bar; TERM is a 1.5U key. All other keys are 1U.


End of specification.