Deck Hub — operator state, loadout & Lambda slots

v3.0 | 2026-07-18

First-party on-device program #2 (ADR-0042). Tier 2 is the GWP-710 operator spec (merged PR #134); Tier 3 is the detailed-design pass it owed, folding in the GWP-709 SUPPLY skeleton and the 2026-07-18 rulings.

Tier 2 describes what the operator sees, does, and chooses. Tier 3 carries the layouts, key maps, cell architecture, and behavior tables. Where this spec and ADR-0040 disagree, the ADR wins. See the program roster.

Tier 2 — Operator spec

Identity

Deck Hub is the operator’s character screen as a terminal utility: the one surface where the deck’s persistent identity (handle, credits, standing, cartridge history) is presented in full and where the loadout (the Lambda slots of ADR-0040 §12) is managed. It is also the Blank Slate Deck surface: the guided first-boot flow a freshly provisioned deck runs before anything else.

Deck Hub is where the operator answers two questions between runs:

Who am I on this deck? The career: identity, wallet, standing, history.
What am I carrying into the next run? The loadout: which enhanced capabilities and scripted lambdas occupy the limited slots.

Like every first-party program it ships in the system image, is always available with or without a cart in slot, and is never superseded by a cart.

Reaching Deck Hub

Deck Hub is a routed surface like the other twelve programs. Two arrivals are canonical:

First boot. A deck with no operator handle boots directly into Deck Hub’s Blank Slate flow (below). This is the only time the deck lands an operator anywhere before the bare-deck HUD.
Deliberate visit. The operator opens Deck Hub between runs to review the career or change the loadout. The concrete entry gesture was a routing decision deferred to the Tier-3 pass; resolved: launched from the PROGS tab (ADR-0059; Tier 3 §3.2). That supersedes the 2026-07-18 digit-6 ruling, whose digit map never matched the shipping deck. Deck Hub is reachable from the bare deck and from between mission phases, and unreachable from inside a run’s challenge loop (a run is played with the loadout it committed; see Loadout).

The character sheet

The read face of Deck Hub. Everything here comes from Universal Deck State and is presented for reflection and planning. Deck Hub displays this state; changing it happens only through the sanctioned paths named per item below.

Element	What the operator sees	Where it changes
Handle	The chosen alias, as it appears on boot, in link handshakes, and in provenance records.	Set once during Blank Slate; renamed via the SYS operator section (renames carry provenance consequences and stay a settings action).
Credits	The wallet: one pooled balance, the only spendable element. Shown with recent direction (earned/spent since last visit).	Mission resolution and purchases, per the economy model. Deck Hub renders the balance; it hosts no faucet.
Standing (reputation)	Cumulative career standing, with the current tier and the distance to the next gate. Standing gates which offers appear on the board; it is never spendable.	Mission resolution only.
Cartridge history	The career ledger across capability modules: which carts have ever registered on this deck, first-registration order, and career totals (contracts completed, credits earned, standing gained) aggregated per cart and across the whole career.	Cart first-load and mission resolution.
Phase chain	Any suspended multi-phase contract: phase position and the capability the next phase needs. Presented here as career context; the board owns acting on it.	The runtime, at contract acceptance and phase transitions.

The sheet is the trophy-case view of a career, one level deeper than any live readout: trajectories and totals across the whole history. The current tick belongs to the STATUS tab; see “Division of labor with the bare-deck STATUS tab” for the boundary.

The loadout — Lambda slots

The management face of Deck Hub, and the reason the program exists. The model is fixed by ADR-0040 §12 and its companion spec §12; this section restates it from the operator’s chair.

What a slot is

A Lambda slot holds one equipped enhancement. The deck has a limited number of slots, and slot count is a progression unlock: a new deck has few, a veteran deck has more. Two kinds of thing can occupy a slot:

Enhanced verb-tools — the cart-deepened capabilities (the full forensic suite over the basic spreadsheet, full netrun over basic blackhat) acquired through the acquisition loop of the economy model.
Scripted lambdas — operator-authored automation: recorded key sequences and written Lisp, promoted into the loadout so they ride along on a run.

The one rule: full swap

Equipping into an occupied slot swaps: the incoming enhancement replaces the outgoing one (full swap, confirmed per ADR-0040 §16). The limit is what makes the loadout a strategic layer: the operator cannot carry everything, so choosing the loadout means choosing the gaps.

Never fully bare

An empty slot costs capability only; the domain stays accessible. Unslotted, the operator falls back to the shallow first-party baseline for that domain: slower, louder, always available. Baselines are the floor; the loadout gates the ceiling.

When swapping happens, and what it costs

In Deck Hub, between runs: rearranging the loadout is free deliberation. The operator reviews the upcoming contract’s phase arc and commits a loadout against it. Sequencing the loadout against the obstacle order is the run, planned here.
Mid-run: a swap carries the coupled time ↔ exposure cost of ADR-0040 §12: the delay and the heat feed each other, and which dominates depends on the capability and the moment. The mid-run swap happens in the run’s own surface under the run’s own pressure. Deck Hub’s contribution is the cost preview: when the operator inspects a slot or plans a loadout, Deck Hub shows what swapping that enhancement mid-run tends to cost, so the plan is made with eyes open. Concrete numbers are balancing variables owned by the career simulators (economy model), deferred with the rest of the swap-currency design.

What the loadout view shows

Per slot: the occupant (or empty), its kind (verb-tool or scripted lambda), the domain it deepens, and the mid-run swap-cost preview. Around the slots: the slot count, the next slot-unlock condition, and the bench (owned-but-unequipped enhancements, eligible to swap in). The bench lists only what the operator already owns; how unowned items become owned is the shop’s concern (see “Shop home”).

Blank Slate — the first-boot flow

A freshly provisioned deck has no handle, zero credits, zero standing, an empty cartridge history, and an empty loadout. On first power-up the deck runs Deck Hub’s Blank Slate flow before the bare-deck HUD ever appears.

Blank Slate is Deck Hub’s empty state plus a one-time guided pass over it. There is no separate onboarding program and no distinct mode to exit: the flow walks the operator through the same surfaces this spec already defines, rendered in their empty state, and ends by routing to the bare-deck STATUS tab. (This resolves the charter stub’s open question 2.)

As built (2026-07-18): the shipped first boot is not yet this flow. A handle-less deck routes to a standalone oobe router screen (char-picker handle entry: runtime/system-image/lib/deck/aux.lsp over the deck/oobe-* FFI in runtime/src/deck_aux.h), then a one-time WELCOME screen, then the bare-deck HUD; the first-boot REPL tutorial (GWP-224/231) runs separately. Of the pass below, only the greeting and handle entry exist. Handle entry does not yet use multi-tap, though the state machine already ships for nEmacs/REPL literal entry (runtime/src/nokia.c); rewiring OOBE onto it is a tracked engineering follow-on, and the guided pass (steps 3–5) lands with the Deck Hub implementation.

The pass, in order:

Greeting. The Kinoshita header on the main grid; a first-boot CIPHER fragment on the CIPHER-LINE OLED (CIPHER stays OLED-exclusive per ADR-0015 throughout).
Handle entry. The operator enters a handle on the numpad using multi-tap text entry (the GWP-440 input method, per ADR-0016 §6 and input-dispatch; this spec references that flow and does not restate its mechanics). Confirming the entry establishes the deck’s identity: handle recorded, wallet and standing zeroed, cipher seed initialized.
The sheet, empty. The character sheet renders with everything at zero: the shape of the career before the career. Each element gets one line of explanation on first render (what credits are, what standing gates, what the history will hold).
The loadout, granted. The starter kit (the granted channel of the economy model) arrives: the initial slot or slots, with the starter grants equipped or offered for the operator’s first equip action, so the equip gesture is exercised once under guidance.
Hand-off. The flow closes by routing to the bare-deck STATUS tab, where the four-tab HUD and its runtime bounties take over onboarding (per the bare-deck content brief). Deck Hub remains reachable thereafter as an ordinary program.

The bare-deck spec’s first-boot section (bare-deck-terminal.md §Boot Sequence) predates ADR-0042 and described handle entry as a bare-runtime text mode with letter cycling; per ADR-0042 the Blank Slate surface is Deck Hub’s, and the entry method is multi-tap. That section now points here (its v1.3 revision, in this change). As built, the runtime’s first-boot screen uses this method: GWP-725 rewired the OOBE surface from its interim char-picker onto the nokia.c multi-tap machine, with the in-progress echo on CIPHER-LINE Row 4 per ADR-0016 §6.

Division of labor with the bare-deck STATUS tab

The bare-deck STATUS tab (bare-deck-terminal.md, content brief §3) already renders live readouts: handle, standing bar, credits, the capability registry roster with tier glyphs, phase-chain line, macro-slot summary. Deck Hub duplicates none of that role. The boundary:

	STATUS tab	Deck Hub
Job	Glanceable now: the live readout the operator lands on between sessions.	Depth and management: the career over time, and the loadout.
Mutation	None. STATUS reads and refreshes; its drills open read-only detail.	The loadout: equip, swap, bench. The one place loadout changes happen outside a run.
Capability registry	Owns the roster presentation and the per-capability contract-history drill.	Presents career aggregates (totals, trajectory) across the whole history; links the registry story together without re-rendering the roster.
Tenure	Always resident in the tab strip; position 1; digit-jump 1.	A routed program, visited deliberately; launched from PROGS.

Rule of thumb for future design work: if a piece of deck state needs to be seen at a glance, it belongs on STATUS; if it needs to be acted on or studied, it belongs in Deck Hub. When both need it (handle, credits, standing), STATUS shows the value and Deck Hub shows the value in context.

Shop home (decided: the SUPPLY view; ADR-0057)

GWP-709 placed the shop in Deck Hub (ADR-0057): one additional view, SUPPLY, reached from the loadout view (the bench’s natural extension: from “what I own” to “what is on offer”). The character sheet, loadout, and Blank Slate flows above are unchanged. The seam contracts hold as written: purchases resolve through the sanctioned economy path and land as owned items, which the bench then lists; the wallet readout is the balance SUPPLY spends against. The view’s full design is Tier 3 §3.7–§3.8 (the GWP-709 skeleton folded in, 2026-07-18); deck-hub-supply.md remains as a pointer so ADR-0057’s links keep resolving.

What Deck Hub does NOT own

Mission acceptance and the board. Contracts are discovered and accepted on the Mission Board; Deck Hub shows the phase chain as context only.
Macro recording. Recording and editing key-sequence macros stays on the bare-deck LAMBDA tab; Deck Hub deals with recorded lambdas only at the equip boundary. A recorded lambda is a candidate loadout occupant; the naming is unified per open question 1’s resolution (Tier 3 §3.1).
Settings and rename. Contrast, volume, aesthetic mode, and handle rename stay in SYS.
Economy mutation. Credits and standing change only through mission resolution and purchases. The SUPPLY view initiates purchases (ADR-0057), but the debit and the ownership deposit execute in the engine through the sanctioned path (ADR-0055 tiering, ADR-0056 ownership_commit); Deck Hub never writes the wallet or the ledger directly.
The in-run swap. The mid-run swap gesture, its confirmation, and its cost application belong to the run’s surface; Deck Hub supplies the preview beforehand. (Position taken on stub question 3; flagged below for review.)

Decisions taken in this spec

Blank Slate is Deck Hub’s empty state plus a one-time guided pass, ending at the bare-deck STATUS tab. No separate mode or program. (Closes stub Q2.)
Deck Hub is the between-runs loadout surface; the in-run swap belongs to the run’s surface, with Deck Hub providing the cost preview. (Closes stub Q3 at Tier 2; the confirmation UX itself is designed with the run surfaces.)
The character sheet aggregates; STATUS enumerates. Career totals and trajectory live here; the registry roster and per-capability drill stay on STATUS.
Handle rename stays in SYS. First entry is Deck Hub’s (Blank Slate); renames remain a settings action with provenance consequences.

These land with this PR; Josh’s review of the PR is the acceptance.

Open design questions

The “Lambda slot” naming collision. Resolved (Josh, 2026-07-18): unified, one system. A recorded macro is one kind of loadout occupant; the LAMBDA tab is the authoring surface, Deck Hub is the equipping surface, and “Lambda slot” means one thing everywhere. Design in Tier 3 §3.1; the bare-deck docs that described the eight macro slots as a separate system are updated in the same change (bare-deck-terminal.md v1.4, content brief §5).
Loadout management vs the opaque capability-load boundary. ADR-0029 treats a capability load as opaque to the Mission Runner; where the slot/swap boundary sits relative to that call is the standing ADR-0040 §16 reconciliation. Carried forward (Tier 3 §3.11); the Tier-3 surface is written to survive either resolution.
The entry gesture. Resolved (Josh, 2026-07-18): digit 6. The bare-deck digit map extends: 5 stays reserved for the future MISSIONS tab, 6 routes to Deck Hub. Design in Tier 3 §3.2; bare-deck-terminal.md’s digit-map section carries the matching v1.4 note.
Slot-count progression. The design half is closed: the initial count is granted at Blank Slate and every further slot is a bought rig item in SUPPLY (Tier 3 §3.9 names the knobs). The values stay balancing variables in the career simulators, where they are not yet modeled.

Tier 3 — Detailed design

Gate: draft (this PR). The layouts, key maps, cell architecture, and behavior tables the Tier-2 spec owed, plus the folded SUPPLY contract (GWP-709). Technical nouns appear behind seam markers per the documentation standard. Layout geometry follows the row contract of screen-design-rules §1 on the canvas of the Canonical Hardware Specification; hardware values are referenced, never restated.

3.1 The unified Lambda-slot model (ruling, Josh 2026-07-18)

One system, one name. “Lambda slot” means a loadout slot (ADR-0040 §12) everywhere on the deck. A slot’s occupant is either:

an enhanced verb-tool: a cart-deepened capability, bought through SUPPLY; or
a scripted lambda: a recorded macro (authored on the bare-deck LAMBDA tab) or written Lisp (authored in the REPL / nEmacs and promoted).

The bare-deck LAMBDA tab is the authoring surface: it records, edits, merges, compares, and names macros. Deck Hub is the equipping surface: the loadout view is the one place an authored lambda enters or leaves a Lambda slot outside a run. The eight 32-step recording positions on the LAMBDA tab are the macro library (storage for candidates); earlier bare-deck text calling those positions “lambda slots” reads as the library.

Term	Means	Where
Lambda slot	One loadout position; limited count; progression-unlocked (§3.9)	Deck Hub loadout view (equip/unequip); the run surface (mid-run swap)
Recorded lambda	A named 32-step macro; a candidate occupant	Authored on the LAMBDA tab; stored in the macro library
Macro library	The eight recording positions	The LAMBDA tab
Bench	Owned, slot-eligible, unequipped items (verb-tools and lambdas)	Deck Hub loadout view

Implementation seam (GWP-710): the macro library is the lambda_slots[256] field of deck-state.md (eight 32-step recordings, SRAM-volatile today) plus the slot names in BareDeckState (content brief §5). The loadout itself is new durable state; its UDS home and the durability of an equipped recording are open (§3.12).

3.2 Entry: from PROGS

Superseded (2026-07-27, ADR-0059). This section described a digit-6 jump to Deck Hub (ruling Josh 2026-07-18), on a digit map where 1–4 jumped tabs and 5 was reserved for MISSIONS. That map never matched the shipping deck: MISSIONS had already landed at digit 6, and ADR-0059 appended PROGS at 7. Digit 6 selects the MISSIONS tab.

Deck Hub is reached from the PROGS tab, the bare deck’s program launcher: it is one of the fourteen k_programs[] entries, so it appears in both the LIST and ICON views and launches on EVAL or APPLY like any other program. Behaviour contract:

The launch is a route: the leaving surface’s exit path runs, Deck Hub opens at view level on the character sheet, and BACK returns to PROGS with Deck Hub still selected, so run / leave / run-next is one loop.
Inside Deck Hub, digits are data (multi-tap letters during handle entry, nothing elsewhere in v1).
Digits reach a program only once a tab has entered an interactive mode; at tab level they stay STATUS-anchored tab jumps. See progs-launcher.md §7 for how the shell enforces that.

Other arrivals: first boot auto-routes a handle-less deck into the Blank Slate pass (§3.4, Screens 5–6); between phases of a multi-phase contract the bare deck is the active surface, so the same digit works there. The matching digit-map update is bare-deck-terminal.md v1.4.

3.3 The view ring

Deck Hub is three views on one ring, rendered in the Row-1 strip:

SHEET ⇄ LOADOUT ⇄ SUPPLY ⇄ (wraps)

Two levels, mirroring the bare-deck tab-level / mode-level convention:

View level. CDR cycles the ring; CAR enters the focused view’s rows; BACK exits Deck Hub.
Row level. CDR cycles rows, CAR inspects or drills the focused row, EVAL acts (equip, swap, buy, confirm), NIL clears or backs out per view, INFO cycles the view’s secondary lens, BACK returns to view level.

The full key map is §3.5; per-view EVAL/NIL semantics are in the screen sections below.

3.4 Screen layouts

All wireframes obey the row contract: Row 0 = firmware status bar, Rows 1–73 = program content, Row 74 = firmware action bar (drawn as the bracketed key-hint line). Columns are abbreviated to ~96 of the 128 for legibility. Density modes per screen-design-rules §7: Structured (SHEET, LOADOUT), Dense (SUPPLY), Narrative (Blank Slate). CIPHER renders on the OLED throughout (ADR-0015); no Deck Hub screen draws Cipher text.

Screen 1 — Character sheet (SHEET)

Row 0  [firmware status bar]
Row 1  DECK HUB · ▸SHEET · LOADOUT · SUPPLY
Row 2  ────────────────────────────────────────────────────────────────────────────
Row 3   OPERATOR   GHOSTWIRE
Row 4   CREDITS    ¤ 4,210        ↑ 1,340 earned · ↓ 600 spent since last visit
Row 5   STANDING   ▓▓▓▓▓▓░░░░ 47 · tier 3 · next gate at 60
Row 6  ────────────────────────────────────────────────────────────────────────────
Row 7   CAREER     38 contracts · ¤ 21,450 earned · 51 standing gained
Row 8
Row 9  CARTRIDGE HISTORY (first-registration order)
Row 10 ▸ 01  ICE BREAKER     14 contracts    ¤ 9,100    +21
Row 11   02  BLACK LEDGER     9 contracts    ¤ 6,800    +17
Row 12   03  NEONGRID         6 contracts    ¤ 3,200    +8
Row 13   04  DEPTHCHARGE      3 contracts    ¤ 1,400    +5
Row 14
Row 15 PHASE CHAIN
Row 16  Phase 2/3 · EXTRACTION → AUDIT · next capability: BLACK LEDGER
Row 17  (context only; act on it from the Mission Board)
…
Row 73
Row 74 [ CDR next · CAR drill · INFO detail · BACK ↑ ]

Row 4 is the Tier-2 “recent direction” readout; the since-last-visit window resets when Deck Hub closes.
CAR on a history row drills to that cart’s career aggregate (totals and trajectory). The per-capability contract-history drill stays on the STATUS tab (division-of-labor table); the drill here links across and never re-renders the roster.
INFO toggles a detail lens over the same rows: per-cart completion ratio, largest single payout, standing per cart.
Numbers right-align per column (screen-design-rules §6); the sheet mutates nothing.

Screen 2 — Loadout (LOADOUT)

Row 0  [firmware status bar]
Row 1  DECK HUB · SHEET · ▸LOADOUT · SUPPLY
Row 2  ────────────────────────────────────────────────────────────────────────────
Row 3  LAMBDA SLOTS · 3 of 4 equipped         next slot: LAMBDA SLOT +1 · in SUPPLY
Row 4  ────────────────────────────────────────────────────────────────────────────
Row 5  ▸ [1]  FULL NETRUN       verb-tool   ICEB       mid-run swap: slow · loud
Row 6    [2]  FORENSIC SUITE    verb-tool   BL         mid-run swap: slow
Row 7    [3]  BOOT-CHECK        lambda      library    mid-run swap: quick
Row 8    [4]  ── empty ──       (baseline fallback covers the domain)
Row 9  ────────────────────────────────────────────────────────────────────────────
Row 10 BENCH (owned · unequipped)
Row 11   KASISKI            verb-tool   CIPHGDN
Row 12   EXTRACTION-SEQ     lambda      library
Row 13   (buy capability in SUPPLY; record lambdas on the LAMBDA tab)
…
Row 73
Row 74 [ CDR next · CAR inspect · EVAL equip/swap · NIL unequip · BACK ↑ ]

The swap-cost preview column renders qualitative bands (quick/slow, quiet/loud). Bands are display formatting over the simulator-owned swap-cost variables (ADR-0040 §12); this spec sets no numbers.
EVAL (equip): cursor on a bench row, EVAL equips into the first empty slot. With no empty slot, EVAL arms a swap: the slot list highlights, CDR picks the outgoing occupant, EVAL commits the full swap (ADR-0040 §16), any other key disarms. The displaced occupant lands on the bench.
NIL (unequip): cursor on a filled slot, NIL arms; EVAL confirms; any other key aborts (the same arm/confirm pattern as the LAMBDA tab’s NIL-clear). The occupant returns to the bench and the slot empties to the baseline fallback.
Between runs only: with a run’s challenge loop active Deck Hub is unreachable (Tier 2). The mid-run swap belongs to the run surface; these preview values are what the operator planned against.
Cursor order: slots first, then bench rows (one CDR sequence top to bottom, wrapping).

Screen 3 — SUPPLY

Row 0  [firmware status bar]
Row 1  DECK HUB · SHEET · LOADOUT · ▸SUPPLY
Row 2  ────────────────────────────────────────────────────────────────────────────
Row 3  FILTER: ALL                                                        ¤ 4,210
Row 4  ────────────────────────────────────────────────────────────────────────────
Row 5  VERB
Row 6  ▸  SPIKE             ICEB       ¤   600    NEW
Row 7     GHOST             ICEB       ¤   900
Row 8     KASISKI           CIPHGDN    ¤   750
Row 9     ICEBERG           SYNFNC    (¤ 1,100)
Row 10 EQUIPMENT
Row 11    SALVAGE WINCH     DPTHCHG    ¤ 1,200
Row 12 PROGRAM
Row 13    RIPSAW            SYSTEM     ¤ 3,000
Row 14 PROGRAM TIER
Row 15    AMBERCALC T2      SYSTEM     ¤ 1,500
Row 16 RIG
Row 17    LAMBDA SLOT +1    DECK      (¤ 4,500)
Row 18 CONSUMABLE
Row 19    PANIC FLARE       ×2 HELD    ¤   250
…
Row 73
Row 74 [ CDR next · CAR inspect · EVAL buy · INFO filter · NIL ↑ ]

Item names are illustrative (the census is GWP-713); class rows and bands are the simulators’ catalog_classes knob. Classes render in the catalog-taxonomy §1 order.
A parenthesized price marks an item the current balance cannot cover (metadata weight per the visual-hierarchy ladder). EVAL on it refuses before any write and shows the shortfall.
NEW is the new-stock marker (§3.8 ruling 2); ×2 HELD is a consumable’s held count.
Owned items leave the list; consumables stay. Hidden items never appear: no price, no mention (GWP-712 §3). Locked prerequisites read as requirements (“requires AMBERCALC” on a tier row), never as absences.

Screen 4 — SUPPLY item inspect (CAR)

Row 0  [firmware status bar]
Row 1  DECK HUB · SUPPLY · INSPECT
Row 2  ────────────────────────────────────────────────────────────────────────────
Row 3   SPIKE                                              VERB · ICE BREAKER
Row 4   ¤ 600 · balance ¤ 4,210
Row 5  ────────────────────────────────────────────────────────────────────────────
Row 6   Tier-2 core verb-tool. Widens the CONS matrix: buying this core
Row 7   unlocks its declared composites (SPIKE + CLOAK = PHANTOM).
Row 8   Exposed by: teaching debrief, contract #38.
…
Row 73
Row 74 [ EVAL buy · NIL back ]

The detail block per class: what the item unlocks (composites for a verb, the deepened interface for a program tier, the stat for a rig), its provider, its price, and the shortfall when the balance is short.
For the high-band classes (rig; the capstone) Row 74 reads [ EVAL arm · NIL back ] and the purchase takes the two-step confirm of §3.8 ruling 1.

Screens 5–6 — Blank Slate pass

The pass is Tier 2’s five steps rendered through the same views in their empty state. Narrative density. Steps 1–2 (greeting, handle entry):

Row 0  [firmware status bar]
Row 1
Row 3       KINOSHITA ELECTRONICS CONSORTIUM              (headline scale)
Row 6       KN-86 DECKLINE
Row 9  ────────────────────────────────────────────────────────────────────────────
Row 11  This deck has no operator.
Row 13  HANDLE: GHOSTW▮
Row 15  (multi-tap entry per ADR-0016 §6 · 2=ABC · 3=DEF · …)
…
Row 73
Row 74 [ EVAL confirm · NIL clear ]

Step 3 (the sheet, empty, one explanation line per element on first render):

Row 0  [firmware status bar]
Row 1  DECK HUB · ▸SHEET · LOADOUT · SUPPLY
Row 2  ────────────────────────────────────────────────────────────────────────────
Row 3   OPERATOR   GHOSTWIRE       the name on boot, handshakes, provenance
Row 4   CREDITS    ¤ 0             contracts pay here; SUPPLY spends from here
Row 5   STANDING   ░░░░░░░░░░ 0    gates which offers reach the board; never spent
Row 6   CARTRIDGE HISTORY          empty; carts register on first load
Row 7   PHASE CHAIN                none
…
Row 74 [ EVAL continue ]

Step 4 (the loadout, granted; the guided first equip):

Row 0  [firmware status bar]
Row 1  DECK HUB · SHEET · ▸LOADOUT · SUPPLY
Row 2  ────────────────────────────────────────────────────────────────────────────
Row 3  LAMBDA SLOTS · 0 of N equipped              (N = the granted initial count)
Row 4  ────────────────────────────────────────────────────────────────────────────
Row 5  ▸ [1]  ── empty ──
Row 6  ────────────────────────────────────────────────────────────────────────────
Row 7  BENCH · starter grant
Row 8    <starter verb-tool>     verb-tool   granted
Row 10  CDR to the bench row · EVAL equips it. One equip, guided; the gesture
Row 11  is the lesson.
…
Row 74 [ CDR next · CAR inspect · EVAL equip ]

Step 5 routes to the bare-deck STATUS tab; it has no screen of its own. During the pass, BACK is a no-op bounce (there is no surface behind first boot) and the pass completes forward only. The as-built state is the Tier-2 callout: today only the greeting and handle entry exist (the standalone oobe char-picker); these layouts are the target the Deck Hub implementation replaces that flow with, and the multi-tap rewire is a separate in-flight engineering task.

3.5 Key map

Board grammar throughout; every binding reuses a canonical key with its deck-wide meaning.

Key	View level	SHEET	LOADOUT	SUPPLY	Blank Slate
CDR	cycle the view ring	next row	next row (slots, then bench)	next item	next bench row (step 4)
CAR	enter the focused view	drill the focused row	inspect occupant / bench item	inspect item (Screen 4)	inspect bench item (step 4)
EVAL	(no-op)	(no-op)	equip / arm swap / commit	buy / arm high-band / commit	confirm step
NIL	(no-op)	(no-op)	unequip (arm; EVAL confirms)	back to view level	clear handle entry
INFO	(no-op)	detail lens	(no-op)	cycle filter ALL → NEW → AFFORDABLE	(no-op)
BACK	exit Deck Hub	to view level	to view level (disarms first)	to view level (disarms first)	no-op bounce
Digits	data only (6 is inert inside)	—	—	—	multi-tap letters (handle step)

Binding rationale, one line per key: CDR cycles because it cycles everywhere; CAR inspects (the head of the focused thing); EVAL is the act key across the deck, and a purchase or an equip is the act that converts deliberation into commitment; NIL empties or discards, its bare-deck meaning; INFO is the sideways lens; BACK ascends. APPLY stays inactive here as on the bare deck: Deck Hub manages tools between runs and deploys none.

3.6 Cell architecture

Cell type	Role	Keys it handles
`hub-ring`	The Row-1 view strip; owns view-level dispatch and exit	CDR, CAR, BACK
`sheet-row`	One character-sheet element or cartridge-history row	CAR, INFO
`loadout-slot`	One Lambda slot (occupant or empty)	CAR, EVAL, NIL
`bench-row`	One owned, unequipped, slot-eligible item	CAR, EVAL
`supply-row`	One exposed catalog item	CAR, EVAL
`supply-inspect`	Full-surface item detail (Screen 4)	EVAL, NIL
`slate-step`	One Blank Slate step surface	EVAL, NIL, numpad

State machine (the arm/confirm pattern shared by the three guarded acts):

State	Entered by	EVAL	Any other key
`browse`	default	act (equip / buy) or arm (swap, unequip, high-band buy)	per key map
`armed-swap`	EVAL on a bench row, no empty slot	commit the full swap	disarm to `browse`
`armed-unequip`	NIL on a filled slot	commit the unequip	disarm to `browse`
`armed-buy`	EVAL on a high-band item (rig, capstone)	commit the purchase	disarm to `browse`
`refused`	EVAL with a short balance	(shortfall shown; next key returns to `browse`)	to `browse`

Implementation seam (GWP-710): Deck Hub is a System-tier program lib under runtime/programs/ (ADR-0042 charter, router-registered); loading it may need the screen router’s lockstep arena bump. Handlers are Lisp lambdas over the tagged-union cell contract; key dispatch uses a static (key . thunk) alist (the Fe GC-stack rule). Reads: UDS via the deck seam (wallet, standing, history, phase chain), the ownership ledger via ADR-0056’s read queries, the exposure ledger (run-state), the macro library. Writes: only the purchase transaction (§3.7) and the loadout mutations; the loadout’s durable home is open (§3.12).

3.7 The SUPPLY view (folded from the GWP-709 skeleton)

SUPPLY is one Deck Hub view beside the character sheet and the loadout: the catalog of exposed items, priced in credits. It lists what the operator could own; the bench beside it lists what they do. Buying moves an item from one list to the other.

Ownership registers to the deck (ADR-0057 Decision 4): the ledger is deck-durable state, and whoever operates the deck exercises it. The operator, in turn, is fixed to the deck until the capstone: changing the deck’s operator requires owning the synthetic identity (ADR-0057 amendment, Josh 2026-07-18). One handle per deck for the whole career; the career-length purchase is the way out.

What the operator sees (rendered per Screen 3):

Exposed catalog items, grouped by class (GWP-712’s six: verb, equipment, program, program tier, rig, consumable), each with its symbolic name, provider, and price.
A new-stock marker on items exposed since the view was last opened (the persistent half of the debrief advert; the OLED line is the ephemeral half). Persistence per §3.8 ruling 2.
The wallet balance (Deck Hub’s existing readout) and, per item, whether it is affordable.
Owned items leave the list (consumables stay, with a held count). Hidden items never appear: no price, no mention (GWP-712 §3).
Locked prerequisites read as requirements, never as absences (own-before-upgrade for program tiers).

Per class, what “upgrade” concretely means (names drawn from the module specs and the verb-taxonomy map; the per-item census is GWP-713):

verb: a cart’s Tier-2 CORE tool bought into the palette. ICE BREAKER ships a starter subset of its six archetypes (CRACK / MIRROR / SPIKE / CLOAK / SIPHON / GHOST); buying the rest widens the CONS matrix, so each bought core also unlocks its declared composites (SPIKE + CLOAK = PHANTOM). The :discoverable composites (REWRITE / SHADOW / LAUNDER) are never on the shelf. Same pattern per taxonomy: CRYPTANALYSIS sells KASISKI and SUBSTITUTE, MARKET sells ICEBERG and ARB, DEFENDER sells BAIT and FORGE-LOG.
equipment: cart-domain hardware in the fiction (salvage winch, jammer coil, credential blanks); the late exclusive band is the pre-capstone drain.
program: a locked ADR-0042 roster entry (the sims model 5 granted at boot, 8 bought).
program tier: a program’s deepening (AmberCalc’s full forensic suite over the basic spreadsheet, CONDUIT’s protocol set beyond telnet, knSALK’s firewall → antivirus → active-ICE ladder).
rig: a permanent deck stat; the first is the Lambda-slot count (§3.9). The other five are unnamed; census work.
consumable: panic gear and fee-payers (retries, re-seeds), bought repeatedly.

Verbs and keys, board grammar reused: CDR cycles items, CAR inspects (full item detail: class, provider, what it unlocks, price), EVAL buys, NIL backs out to the Deck Hub view ring. Binding rationale: EVAL is the act key across the deck (OODA: act); a purchase is the act that converts a felt gap into capability. A buy on EVAL is refused, with the shortfall shown, when credits are insufficient; the high-band classes additionally take the arm/commit confirm (§3.8 ruling 1).

The purchase transaction:

Implementation seam (GWP-709, carried verbatim from the skeleton):

Refuse if credit_balance < price (no writes).

Debit the wallet through the evented setters (GWP-718); System-tier only, per ADR-0055.

Deposit ownership via ownership_commit (ADR-0056); consumables increment their count.

The bench reflects the item on next render; the exposure ledger marks it owned.

The board does not regenerate (ADR-0057 Decision 3; the UDS_CREDIT_CHANGED dirty subscription is removed from mission_board.c).

Inputs: the catalog registry runtime/system-image/lib/deck/catalog.lsp (GWP-712 §4, the data-only record table); the exposure ledger (run-state, regenerable, ADR-0056 Decision 6; flips hidden → exposed on teaching debrief or reputation floor, GWP-712 §3); the ownership ledger (the UDS blob, ADR-0056, via its read queries).

What SUPPLY does not own:

Pricing authority. Prices come from the catalog registry; award pricing is the engine’s (ADR-0055).
Exposure generation. Which item a teaching mission advertises is the teaching-mission generator’s (GWP-714). SUPPLY renders the ledger’s current stage.
The ledger layout. ADR-0056’s.
The advert copy. CIPHER’s, on the OLED, per the style guide.

3.8 SUPPLY rulings (the skeleton’s open questions, resolved)

Confirm step: class-gated, arm/commit, for the high bands. Purchases in the rig class and the capstone take a two-step EVAL (first arms, second commits, any other key disarms); every other class buys on a single EVAL, refused with the shortfall when short. Rationale: the model has no resale or refund path (catalog-taxonomy §3, “owned never regresses”), so a slip on a high-band item is unrecoverable at career scale; the arm/commit pattern already exists on the deck (the LAMBDA tab’s NIL-clear); and gating by class keeps the rule structural while every price stays a simulator knob (a credit-threshold gate would hardcode a number this spec is barred from setting). Low and mid classes stay one-press so the first-session purchase (feel target T1) keeps zero friction.
The new-stock marker persists across power cycles, by persisting the seen side. A small Config-tier note (the ADR-0056-sanctioned home) records which exposed item IDs SUPPLY has rendered; the marker shows for exposed-and-unseen items. Rationale: debrief followed by power-off is the ordinary session end, and losing the persistent half of the advert exactly then defeats ADR-0057 Decision 2. Persisting the seen-set leaves the exposure ledger run-state and regenerable per ADR-0056 Decision 6; regeneration can only re-expose, and anything re-exposed but already seen stays unmarked.
Sort and filter at catalog scale: fixed order, subtractive filters, no re-sorting. The list renders in one stable order (class groups in taxonomy §1 order, price-ascending within class); INFO cycles three filters: ALL → NEW → AFFORDABLE. Rationale: an order that reshuffles as the wallet moves is the same reads-shift-under-the-operator failure ADR-0057 Decision 3 closed for the board, so affordability acts only as a filter; at ~135 items in a Dense layout the full catalog is about two screens of CDR travel, which a filter serves without a search surface.
The Row-74 board-to-SUPPLY affordance: wait for on-glass evidence. ADR-0057 Option A names it a contingent mitigation, and the ADR wins. The shape is recorded here so flipping it on later is an action-bar change: a SUPPLY entry in the board’s Row-74 hint line after a debrief that exposed an item, routing into SUPPLY with the cursor on the newly exposed row. Until the two-hop distance shows up as a felt problem in play, the entry does not render.

3.9 Slot-count progression (the knobs)

Slot count is a progression unlock (ADR-0040 §12) with two sources, both already in the model:

the granted initial count, delivered at Blank Slate step 4: the knob slot_count_initial;
bought increments: the rig class’s LAMBDA SLOT +1 items in SUPPLY. How many exist, their prices, and their exposure stages are the rig rows of the catalog_classes knob.

The loadout view’s “next slot” line (Screen 2, Row 3) renders the cheapest unowned slot rig, or nothing once the ladder is exhausted. All values live in the career simulators (tools/economy_sim.py, tools/economy-sim.lsp); this spec names the knobs and sets none of them.

3.10 CIPHER-LINE contributions

Deck Hub adds no vocabulary pools and no mode-weight biases. Two established events reach the OLED while its surfaces are active: the first-boot fragment (Blank Slate step 1) and :catalog-exposed at the debrief beat (ADR-0057 Decision 2), whose persistent counterpart is the SUPPLY new-stock marker. Copy is CIPHER’s, per the style guide; OLED-exclusive per ADR-0015 throughout.

3.11 The ADR-0040 §16 reconciliation, carried forward

This tier does not force the loadout / (load-capability …) resolution. Every loadout write Deck Hub performs happens between runs, outside any capability-load call, so the equip/swap boundary designed here sits upstream of ADR-0029’s opaque call. The one surface that touches the boundary is the mid-run swap, which Tier 2 assigns to the run’s surface. The reconciliation stays open per ADR-0040 §16; whichever way it lands, it shapes the run surfaces and leaves this program’s design intact.

3.12 Open questions (Tier 3)

Recorded-lambda durability once equipped. The macro library is SRAM-volatile across power cycles (deck-state.md) while a loadout must survive them; an equipped recording that evaporates on power-off breaks the loadout contract. Copy-by-value into the loadout record, or making the library durable: both need the UDS-budget ruling below first.
The loadout’s UDS home. Durable equipped-slot state needs bytes in a region at capacity; ADR-0056’s budget discipline applies (a donor field, per its repl_history precedent). Lands with the ADR-0056 / GWP-718 engineering.
The ADR-0040 §16 reconciliation (§3.11), carried.

References

ADR-0042 — the program charter (roster, category rules, Blank Slate assignment).
ADR-0040 + companion spec §11–§12, §16 — the capability model, Lambda-slot loadout, full-swap decision, open reconciliation.
ADR-0057 — the SUPPLY surface decision; ../runtime/acquisition-surface-brief.md — the option analysis behind it.
ADR-0055 / ADR-0056 — wallet-write tiering; the ownership ledger and UDS budget.
../runtime/deck-state.md — Universal Deck State fields and persistence.
../runtime/economy-model.md — credits/standing classes, acquisition channels, balancing variables.
../runtime/catalog-taxonomy.md — classes, stable IDs, exposure stages.
../runtime/bare-deck-terminal.md / ../runtime/bare-deck-content-brief.md — the STATUS tab this program complements; the LAMBDA authoring surface; the digit map.
ADR-0016 §6 + ../runtime/input-dispatch.md — multi-tap text entry; digit reservation (§3D.1).
../cartridges/authoring/screen-design-rules.md — the layout contract Tier 3 designs against.
ADR-0015 — CIPHER voice OLED exclusivity (holds during Blank Slate).
../../_meta/documentation-standard.md — the tier ladder, header block, and seam-marker rules this file follows.

Inspirations

Assigned by Josh in the kn86-inspo workbench. Full map: cart-inspiration-map.md.

Source	Category
NetWatch	dashboard
World Monitor	dashboard
calcure	dashboard
caps-log	dashboard
chronos	dashboard
desktop-tui	dashboard
octoscope	dashboard
tvterm	dashboard