PART ONE — INTRODUCTION

═══════════════════════════════════════════════════════════════════════════════

                        K I N O S H I T A   E L E C T R O N I C S
                                         · · ·
                              KN-86 DECKLINE PLATFORM

                                ┌───────────────────┐
                                │                   │
                                │   ICE  BREAKER    │
                                │                   │
                                │   v1.0  MODULE    │
                                └───────────────────┘

                          OPERATOR  AND  TECHNICAL  MANUAL

                              Form ZD-86-IB-001, Rev. C
                                       April 2026

                                Published under license by
                                  ZAIBATSU DIGITAL, OSAKA
                            for the KN-86 Deckline platform
                            manufactured by Kinoshita Electronics

                    Rev. C updates capability-model canon, Lisp authoring
                    language, cartridge SD interface, custom keyboard,
                    coprocessor architecture, and REPL access.
                                   See Appendix D.

═══════════════════════════════════════════════════════════════════════════════

FOREWORD

This manual describes the ICE BREAKER capability module, Module Class 0x01 (NETWORK INTRUSION), as supplied with the Kinoshita Electronics KN-86 Deckline. It is intended for two audiences: the Operator, who will use the module in the course of intrusion work, and the Cartridge Author, who may extend or repair the module at the source level. Material directed at the Operator appears in Parts One through Six. Material directed at the Author appears in Part Seven. Material addressing advanced operator technique and the design philosophy behind ICE BREAKER appears in Part Eight. Reference material common to all appears in Part Nine.

The KN-86 Deckline is a game console of the capability class, which means that the device’s behavior is determined not by a single program but by the combination of the resident operating substrate (nOS.h) and the capability modules currently inserted. The fiction — that the device is a 1988 cyberspace terminal — is load-bearing; it is the product’s differentiator, not a layer of decoration. ICE BREAKER is one such capability module. It is the flagship module shipped with the device, and it is the module the device’s documentation, training program, and reference economics are calibrated against.

The Operator should read Parts One through Six in order. The advanced practitioner should then read Part Eight before attempting Threat 4+ contracts. The Author may begin at Part Seven. All readers are encouraged to consult the Glossary (§57) at the back of this volume.

This document supersedes all prior documentation of ICE BREAKER, including the printed materials supplied before April 2026. Where this manual conflicts with an earlier publication, this manual is correct.

HOW TO USE THIS MANUAL

The manual is divided into nine Parts and four Appendices. Each Part is divided into numbered Paragraphs. Cross-references are given as Paragraph numbers or section symbols (e.g., “see Para 17.3” or “see §15”).

The reader is presumed to be familiar with the general operation of computing devices but is not presumed to be familiar with the KN-86 platform, the Lisp programming idiom, or the conventions of 1980s-era network intrusion fiction. All such material is introduced as it becomes relevant.

Material requiring particular attention is set off as follows:

┌─────────────────────────────────────────────────────────────────────────────┐
│ NOTE                                                                         │
│ Information of importance but not affecting safety or correctness of use.    │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ CAUTION                                                                      │
│ A practice or condition which, if not observed, may produce undesired        │
│ but recoverable results.                                                     │
└─────────────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────────────┐
│ WARNING                                                                      │
│ A practice or condition which, if not observed, may produce results which    │
│ are not recoverable, including loss of accumulated reputation or session     │
│ state.                                                                       │
└─────────────────────────────────────────────────────────────────────────────┘

CONVENTIONS

Symbol	Meaning
`[KEY]`	A physical key on the Deckline.
`KEY×2`	A double-press of the same key within 500 ms.
`KEY+KEY`	Two keys pressed in sequence as a combination.
Para N.N	Reference to a numbered paragraph in this manual.
Fig. N-N	Reference to a figure.
`[REGISTER]`	A named field in the Universal Deck State.
`(verb args)`	A Lisp-form expression as it would appear in source or the REPL.
`¤`	The credit symbol used by the universal economy.
ICE	Intrusion Countermeasure Electronics — the threat class collective noun.

Hexadecimal values are prefixed 0x. Decimal values are unprefixed. Time values are given in seconds (s) or milliseconds (ms) as appropriate. Frequencies are given in Hertz (Hz) or kilohertz (kHz). Display coordinates are given as (Row, Column), with Row 0 at the top. The character : introduces a Lisp keyword argument.

PART ONE — INTRODUCTION
   1. Scope and Purpose
   2. The KN-86 Deckline Platform
   3. Place of ICE BREAKER Within the Library
   4. Summary of Capability

PART TWO — SYSTEM ARCHITECTURE
   5. nOS.h — The Operating Substrate
   6. The Capability Model
   7. Universal Deck State
   8. The Cartridge Interface
   9. Runtime Execution Cycle

PART THREE — OPERATING THE DEVICE
  10. Physical Controls
  11. The Lisp Key Grammar
  12. The Display System
  13. The Audio System
  14. The TERM Key and the Lisp REPL
  15. The CIPHER Narrator

PART FOUR — THE GAME OF ICE BREAKER
  16. Design Philosophy
  17. The OODA Cycle
  18. The Network
  19. The Threat
  20. The Toolkit
  21. Sound as Information
  22. Hot Swap
  23. Emergent Interactions

PART FIVE — OPERATING PROCEDURES
  24. Powering On
  25. The Mission Board
  26. Contract Briefing and Entry
  27. The Network Map
  28. Node Interaction
  29. Tool Combination (CONS)
  30. Trace Management
  31. Egress and Debrief
  32. Hot Swap Procedure
  33. Linked Play (Sysop Mode)

PART SIX — UNIVERSAL DECK STATE & CROSS-MODULE INTEGRATION
  34. Fields ICE BREAKER Reads
  35. Fields ICE BREAKER Writes
  36. Cross-Module Effects
  37. Mission Composition Grammar
  38. Cartridge Provenance

PART SEVEN — DEVELOPMENT SPECIFICATIONS
  39. Cartridge File Format (.kn86 v2.0)
  40. Cell Architecture
  41. The NoshAPI Surface
  42. The Mission Template Format
  43. The Included PENETRATION Template
  44. The CIPHER Domain Region
  45. Clips and Algorithmic Art

PART EIGHT — THE INSIDE GUIDE: BEING THE WORLD'S BEST ICE BREAKER
  46. The 8 Fallacies of Distributed Computing as a Framework
  47. The Tempo Discipline
  48. Listening as a Primary Skill
  49. Network Memory and Why You Don't Repeat Seeds
  50. The Toolkit Loadout Theorem
  51. Hot Swap as Strategy, Not Rescue
  52. Surprise Combos as a Personal Library
  53. The Sysop Negotiation
  54. The Operator's Logbook
  55. The Thirty-Run Practice Curriculum
  56. After Mastery: Speedrun Categories and Operator Communities

PART NINE — REFERENCE
  57. Glossary
  58. Key Map Reference Card
  59. Audio Event Catalog
  60. Economic Formulas
  61. Error Conditions

APPENDIX A — Physical Hardware Reference
APPENDIX B — Recommended Operator Progression
APPENDIX C — Regulatory and Safety Notices
APPENDIX D — Revision History

PART ONE — INTRODUCTION

1. SCOPE AND PURPOSE

1.1 Scope

This manual describes ICE BREAKER, version 1.0, supplied as the pack-in module with all KN-86 Deckline units manufactured on or after April 2026. This manual covers the module’s operation by an Operator, the module’s integration with the host operating substrate (nOS.h), and the module’s source-level interface for those wishing to author or modify cartridge content.

1.2 Purpose of the Module

ICE BREAKER provides the Deckline with the NETWORK INTRUSION capability. This capability comprises four mission archetypes (PENETRATION, EXTRACTION, SABOTAGE, SURVEILLANCE IMPLANT), six tool archetypes (CRACK, MIRROR, SPIKE, CLOAK, SIPHON, GHOST), four threat classes (JUNK, BLACK, RED, HUNTER), and a defensive-monitoring sub-mode (Sysop Mode) accessible during linked play.

The Operator who has loaded ICE BREAKER may accept contracts from the nOSh runtime mission board against procedurally generated network targets, navigate those networks via the Deckline’s 34-key Lisp grammar, deploy and combine consumable tools against threat instances, and extract data, plant markers, sabotage systems, or implant persistent monitors as the contract requires.

1.3 Purpose of This Manual

This manual exists so that the Operator may achieve complete and total understanding of the module: what it is, how it runs on the Deckline, how to use it, how it integrates with the operator’s persistent identity (the Universal Deck State), and — for those who wish to extend it — how it is constructed at the source level.

This is not a quick-start guide. The KN-86 Deckline ships with a single-page Quick Reference Card sufficient for first-boot operation. Operators desiring complete mastery of the module should read this manual in full.

2. THE KN-86 DECKLINE PLATFORM

2.1 Hardware Specification

The KN-86 Deckline is a portable cyberspace terminal of the personal class. For the complete hardware specification, refer to the Canonical Hardware Specification in the project CLAUDE.md or Appendix A of this manual. Summary:

Subsystem	Specification
Compute	Raspberry Pi Zero 2 W (primary processor)
Coprocessor	Raspberry Pi Pico 2 (RP2350) — PSG synthesis and OLED driver
Primary display	Elecrow 7-inch IPS, 1024 × 600 pixels
Auxiliary display (CIPHER-LINE)	3.12-inch OLED, SSD1322, 256 × 64, yellow phosphor, SPI0
Logical canvas (primary)	1024 × 600 RGB565 framebuffer; per-region cell density via integer-scaled 8×8 glyphs (128 × 75 = 1× cell ceiling) per ADR-0036
Logical canvas (auxiliary)	32 columns × 4 rows (8 × 8 glyphs, 16 pixel row pitch)
Font	Press Start 2P + CP437, 8 × 8 bitmap, rendered native at integer scales (1× / 2× / 3× / N×) — no 12×24 cell, no padding
Color	AMBER `#E6A020` default on black `#000000`; WHITE `#F0F0F0` and GREEN `#33F033` selectable per ADR-0034
Audio	YM2149 PSG (emulated) → MAX98357A DAC/amp → 28 mm 8 Ω 2 W speaker
Input	34 keys — Ferris Sweep split (3×5 + 2 thumb/half): left half = 14 Lisp-primitive function block + LSHIFT thumb; right half = digit 3×3 + `, . / ; -` + ENT + TERM (context-sensitive) thumb. See ADR-0031 §3.1
Cartridge interface	Full-size SD card via USB mass storage bridge
Cartridge shell	~58 × 65 × 8 mm two-piece clamshell sled carrying SD card
Battery	3× 18650 Li-ion (9.0–12.6 V) via Waveshare UPS Module 3S; ~4–5 h with the 7” display active, ~10–12 h electronics-only
Power draw	~1.5–2 A on the 5 V rail with the display active (display is the dominant load)
Enclosure	Pelican 1170 Protector Case, custom 3D-printed inset panels

The Deckline is the single hardware target for all KN-86 cartridge software. There is no other resolution, no other display, no other sound chip. Cartridges that assume any deviation from this specification are non-conformant and will not be loaded by the nOSh runtime.

2.2 Operating Substrate

The Deckline executes the nOS.h operating substrate. nOS.h is responsible for boot, hardware abstraction, Universal Deck State management, the mission board, the economy, the phase chain, the CIPHER narrator, the cell runtime dispatch, audio mixing, display compositing, and cartridge slot management. The Operator does not interact with nOS.h directly; nOS.h is the substrate within which all cartridges run.

2.3 Display Layout (Master Reference)

The Deckline has two displays: the primary display (80 × 25 main grid) and the auxiliary display (CIPHER-LINE OLED, 32 × 4). These divisions are invariant across all cartridges.

2.3.1 Primary Display (80 × 25 main grid)

   Row  0  ┌──────────────────────────────────────────────────────────────┐
           │  STATUS BAR (firmware-owned, never overwritten by cartridge) │
   Row  1  ├──────────────────────────────────────────────────────────────┤
           │                                                              │
   Rows    │            CARTRIDGE CONTENT AREA (1840 cells)               │
   1-23    │            Owned and drawn by the loaded cartridge.          │
           │            Subject to no firmware overwrite except           │
           │            in modal alert conditions.                        │
           │                                                              │
   Row 23  │                                                              │
   Row 24  ├──────────────────────────────────────────────────────────────┤
           │  ACTION BAR (firmware-owned, contextual key hints)           │
           └──────────────────────────────────────────────────────────────┘

2.3.2 Auxiliary Display — CIPHER-LINE (32 × 4 OLED)

The CIPHER-LINE is a nOSh-runtime-owned OLED mounted above the key plate. It is the exclusive surface for the CIPHER voice and a fixed set of utility chips. Cartridges never address CIPHER-LINE rows by coordinate — they reach it only through the cipher-* and aux-* FFI primitives, and the nOSh runtime places text in the correct row.

   Row  1  ┌──────────────────────────────────────────────────────────────┐
           │  BAT  TIMER 12:04   MODE:DEV           TERM: REPL           │  Status
   Row  2  ├──────────────────────────────────────────────────────────────┤
           │  perimeter alert. 3 turns to hunter.                         │  CIPHER live
   Row  3  ├──────────────────────────────────────────────────────────────┤
           │  junk. slow.                                                 │  CIPHER echo
   Row  4  ├──────────────────────────────────────────────────────────────┤
           │  SEED: 4A 2F 91 C3 7E 08 B1 D6                               │  Contextual
           └──────────────────────────────────────────────────────────────┘

Row	Purpose	Owner
1	Status strip: battery glyph, mission/gameplay timer, mode indicator (`DEV`/`PROD`/`LINK`), TERM-hint chip	nOSh runtime
2	CIPHER scrollback — current fragment (the live utterance)	nOSh runtime generator; cartridge vocabulary contributes
3	CIPHER scrollback — previous echo (the prior utterance, fading)	nOSh runtime generator; cartridge vocabulary contributes
4	Contextual surface: seed capture, gameplay sub-timer, mission phase meta, or linked-deck status	nOSh runtime (mode-switched by cart / phase)

┌─────────────────────────────────────────────────────────────────────────────┐
│ NOTE                                                                         │
│ The CIPHER voice renders EXCLUSIVELY on CIPHER-LINE. No CIPHER glyph is     │
│ drawn on the primary grid under normal operation. This is a hard            │
│ architectural boundary per ADR-0015, not a stylistic preference. The Null   │
│ cartridge is the single sanctioned exception that may place CIPHER on the   │
│ main grid as a designed gameplay mechanic.                                  │
└─────────────────────────────────────────────────────────────────────────────┘

2.4 Key Layout

   ┌──────────────────────────────────────────────────────────────────┐
   │   FERRIS SWEEP — 34-KEY SPLIT  (3×5 main + 2 thumb per half)      │
   │   ───────────────────────────────────────────────────────────    │
   │                                                                   │
   │   LEFT HALF (function block)     RIGHT HALF (digits + punct)      │
   │   [NIL ][INFO][ FN ][CONS][LINK] [ 1 ][ 2 ][ 3 ][ / ][ , ]        │
   │   [APPLY][BACK][CDR ][CAR][QUOTE][ 4 ][ 5 ][ 6 ][ ; ][ . ]        │
   │   [ · ][ · ][SYS ][EQ ][ATOM]    [ 7 ][ 8 ][ 9 ][ - ][ENT]        │
   │   thumbs: [EVAL][LSHIFT]         thumbs: [ 0 ][TERM]              │
   │                                                                   │
   │   TERM (right outer thumb) is context-sensitive: REPL overlay     │
   │   by default; captures the CIPHER-LINE seed when Row 4 is in      │
   │   seed-display mode. LSHIFT (left outer thumb) holds the SHIFT    │
   │   layer. The two `·` slots are reserved v2 spares.                │
   │                                                                   │
   │                    Figure 2-1.  Key Layout                        │
   │        (LAMBDA printed "FN"; canonical layout: ADR-0031 §3.1)     │
   └──────────────────────────────────────────────────────────────────┘

Key semantics are defined in Part Three, §11. The right-half digit cluster preserves the Nokia digit-to-letter mapping (2 = ABC … 9 = WXYZ) per ADR-0016 §6, supporting selection, data entry, and multi-tap text entry. The LAMBDA key is printed as FN on the keycap per ADR-0022. The full canonical layout is ADR-0031 §3.1.

3. PLACE OF ICE BREAKER WITHIN THE LIBRARY

3.1 The Capability Library and Launch Titles

The KN-86 software library at launch consists of four capability modules organized as a cross-capability toolkit. ICE BREAKER occupies Module Class 0x01. The four launch titles are:

ICE BREAKER (0x01, Network Intrusion) — baseline intrusion operations
Depthcharge (0x02, Reconnaissance) — network mapping and analysis
Black Ledger (0x04, Financial Audit) — economic systems navigation
Neongrid (0x08, Route Planning) — pathfinding and checkpoint systems

For the purposes of this manual, the relevant facts are:

ICE BREAKER is the flagship module and ships with every Deckline unit.
ICE BREAKER is the reference implementation of the capability model. Authors of new cartridges are directed to study its source as the canonical example of Lisp cartridge structure.
ICE BREAKER’s mission composition declares verbs (PENETRATE, OBTAIN, DESTROY, OBSERVE) and affinities (DIGITAL, NETWORK). These declarations control which cross-module contracts the mission board will generate (see §37).

3.2 Standalone Operation

ICE BREAKER may be operated entirely without other cartridges. The first-time Operator with no other modules in cartridge history will encounter:

Mission board contracts limited to single-cartridge templates (no Hot Swap requirements).
Sysop Mode locked.
No cross-module bonus contracts.
CIPHER narrator vocabulary drawn solely from ICE BREAKER’s domain.

This is the intended initial-experience profile. The capability curve (see §6.6) progressively unlocks as additional modules are loaded into the operator’s deck history.

3.3 Position in the Operator’s Career

The reference operator progression assumes the Operator will spend their first 10 to 20 sessions on ICE BREAKER alone, achieving Reputation 5 to 14 (Journeyman tier) before acquiring a second cartridge. This timing is not enforced by the nOSh runtime, but the contract economics, Cipher verbosity, and capability gates are tuned for this progression.

4. SUMMARY OF CAPABILITY

The following is offered as a single-page summary for rapid orientation. Each item is detailed in the body of this manual.

Aspect	Summary
Module Class	0x01 (NETWORK INTRUSION)
Capability Bit	0 (set in `cartridge_history` on first load)
Mission Templates	4 (PENETRATION, EXTRACTION, SABOTAGE, SURVEILLANCE IMPLANT)
Tool Archetypes	6 (CRACK, MIRROR, SPIKE, CLOAK, SIPHON, GHOST)
Threat Classes	4 (JUNK, BLACK, RED, HUNTER)
Atomic Unit of Play	OODA cycle (Observe-Orient-Decide-Act), 0.3-2.0 s
Session Length	15-45 minutes typical; episodic contracts span weeks
Linked Play	Yes — asymmetric Sysop Mode via TRRS cable (3.5 mm)
Hot Swap Support	Yes — cartridge swap mid-mission with state preservation
Audio Channels Used	All three PSG voices + noise + envelope generator
Cartridge Storage	~25 KB total (code + templates + clips + CIPHER domain)
Save Data	~4 KB (tool inventory, discovered combos, network memory)
Provenance	Append-only hash chain; records every deck and mission

PART TWO — SYSTEM ARCHITECTURE

5. nOS.h — THE OPERATING SUBSTRATE

5.1 Identification

nOS.h is the operating substrate resident in the Deckline’s nOSh runtime. The name derives from the C header file (nosh.h) which historically defined the substrate’s public interface, retained as the substrate’s mark.

                          ─── BRAND MARK ───

                              ╭─╴ ─ ─╴╮
                             ╱  ⊙   ⊙ ╲          The orbital diagram
                            │  ╲   ╱   │         indicates: orchestrator
                             ╲   ⊙    ╱          at the center, capability
                              ╰─╴ ─ ─╯           modules in attendance.
                                 nOS.h

nOS.h is delivered to all KN-86 Deckline units as part of the system image. It is not available separately and cannot be replaced by Operator action. nOS.h is updated only via the Relay module under explicit Operator authorization.

5.2 Functional Responsibilities

nOS.h is responsible for the following functions. Cartridges may not perform any of these functions independently:

┌─────────────────────────────────────────────────────────────────┐
│  nOS.h  RESPONSIBILITIES                                          │
├─────────────────────────────────────────────────────────────────┤
│                                                                   │
│   1.  Hardware initialization and abstraction                     │
│   2.  Universal Deck State management (read, write, persist)      │
│   3.  Cartridge slot detection and image loading                  │
│   4.  Mission board generation and refresh                        │
│   5.  Phase chain serialization (multi-cartridge missions)        │
│   6.  Universal economy (credits, reputation, proficiency)        │
│   7.  CIPHER runtime — event ring, coherence stack, mode          │
│       selector, grammar merge, rendering to CIPHER-LINE           │
│   8.  Cell runtime dispatch (input event → cartridge handler)     │
│   9.  Primary display compositor (80×25 grid → physical panel)    │
│  10.  Auxiliary display driver (CIPHER-LINE OLED via SPI0)        │
│  11.  Audio mixer (YM2149 emulation + voice arbitration)          │
│  12.  Pico 2 coprocessor communication (UART @ 1 Mbps)           │
│  13.  Clip player (.kn86clip playback into text buffer)           │
│  14.  Provenance chain management (per-cartridge history)         │
│  15.  Save persistence to SD with wear-leveling                   │
│  16.  Linked play handshake and synchronization                   │
│  17.  Bare Deck Terminal (operation without inserted cartridge)   │
│  18.  TERM key REPL overlay (Lisp execution environment)          │
│                                                                   │
└─────────────────────────────────────────────────────────────────┘

5.3 Cartridge Subordination

A cartridge module is subordinate to nOS.h. The cartridge contributes data (mission templates, cell type definitions, CIPHER vocabulary, tool tables, clips, save data) and event handlers (per-cell handler functions). nOS.h owns the main loop, the input dispatch, the display compositor, the audio mixer, and the economy. The cartridge never owns the main loop; it executes only when nOS.h calls into one of its handlers.

5.4 Coprocessor Architecture (ADR-0017)

The Raspberry Pi Pico 2 (RP2350) serves as a realtime I/O coprocessor, owned by nOS.h:

YM2149 PSG synthesis — runs on the Pico 2 at 44.1 kHz, mixing three tone voices, noise, and envelope generator.
SSD1322 OLED driver — the Pico 2 controls the CIPHER-LINE OLED via SPI0 at the firmware level.
UART link — the Pi Zero 2 W communicates with the Pico 2 over UART0 (GPIO14/15) at 1 Mbps.

The Pico 2 draws ~25–55 mA active typical, <5 mA dormant. Power draw is included in the device’s total runtime budget (~145–235 mA with all subsystems active). ICE BREAKER cartridges do not interact with the Pico 2 directly — they issue audio and OLED commands to nOS.h, which marshals them to the coprocessor over UART.

5.5 Bare Deck Operation

When no cartridge is inserted, nOS.h presents the Bare Deck Terminal — a fully operational interface for managing the Universal Deck State, recording macros, reviewing provenance chains, and conducting linked-play handshakes.

6. THE CAPABILITY MODEL

6.1 Definition

The capability model is the architectural premise of the KN-86 platform. Under the capability model:

The nOSh runtime (nOS.h) is the orchestrator: it owns the operator’s identity, the universal economy, the mission board, and the cross-module integration mechanisms.
A cartridge is a capability module: it contributes specific operational capabilities (intrusion, audit, sonar, navigation, etc.) and the data structures necessary to express them.
The combination of nOS.h plus the inserted cartridge(s) plus the Universal Deck State determines what the device can do at any given moment.

For complete details, see Launch Titles Capability Model Specification (form KN86-LTCMS-001).

6.2 The Cartridge Slot

The Deckline has a single cartridge slot. Only one capability module may be physically present at a time. Hot Swap (see §22) is the mechanism by which the Operator may exchange cartridges mid-mission while preserving session state.

6.3 Capability Declaration and Composition

A cartridge declares its capabilities to nOS.h via the capability_bits field of its header. On insertion, nOS.h:

Sets the corresponding bit in the Universal Deck State cartridge_history field, if not already set.
Registers the cartridge’s mission templates with the mission board generator.
Registers the cartridge’s CIPHER domain with the narrator composer.
Registers the cartridge’s phase handlers in the dispatch table.
Permits the cartridge’s (cart-init) function to execute.

When more than one cartridge has ever been loaded into the Operator’s deck (recorded in cartridge_history), capability composition effects become available. Composition is additive only. A cartridge may not subtract capability from another cartridge or from the nOSh runtime.

6.4 The Capability Curve

The Operator’s experience of the platform expands monotonically as cartridges are acquired:

Cartridges Loaded (Ever)	Effect
1 (ICE BREAKER alone)	Single-phase contracts; learning OODA; no Hot Swap; Sysop Mode locked
2 (ICE BREAKER + 1 alt)	Hot Swap unlocked; Sysop Mode available; cross-module bonus contracts begin
3 (ICE BREAKER + 2 alt)	Multi-phase chain contracts (3 phases); Threat 4 contracts unlocked at sufficient reputation
4 (full launch library)	Threat 5 contracts; chain contracts spanning all four cartridges; full emergent surface

7. UNIVERSAL DECK STATE

7.1 Definition

The Universal Deck State is the persistent identity of the Deckline. It is stored as a file on the device’s onboard microSD card and read into RAM at boot. Writes are flushed back on every state-changing event (mission completion, credit transaction, cartridge first-load). It is shared across all cartridges and persists across power cycles.

7.2 Structure (Abbreviated)

The Universal Deck State carries:

Operator handle — the Operator’s chosen alias (displayed in status bar)
Credit balance — universal currency (¤)
Reputation score — cumulative standing across all cartridges
Cartridge history — bitfield: one bit per module class, set permanently on first load
Lambda and QUOTE slots — macro recordings and cell ID bookmarks
Phase chain — serialized state for multi-phase missions
CIPHER seed — LFSR state for deterministic voice composition
Coherence stack — 5 recent CIPHER utterances, persisted across cartridge swaps
Event ring — 128 × 10-byte decay-weighted events feeding the CIPHER generator
CIPHER mode weights — additive biases to the mode selector (cleared on cart-unload)
REPL history — 16 slots × 80 bytes, persistent command history (per ADR-0016)
Reserved fields — future expansion, includes per-module proficiency counters

See §7.3 of the existing Rev. B for the full C structure definition.

7.3 Persistence

The Universal Deck State is written to the device’s microSD at the following events:

Explicit save (SYS → Save).
Mission phase completion.
Cartridge swap (phase chain serialization).
Power-off detection (low-voltage interrupt).

┌─────────────────────────────────────────────────────────────────────────────┐
│ NOTE                                                                         │
│ The Operator may presume the Deck State is durable. Loss of state on        │
│ power-off is non-recoverable but extremely rare under normal operation.     │
└─────────────────────────────────────────────────────────────────────────────┘

8. THE CARTRIDGE INTERFACE

8.1 Cartridge Format and Storage

A cartridge is an SD card housed in a ~58 × 65 × 8 mm two-piece clamshell sled. The SD card itself carries the cartridge image (.kn86 binary file conforming to v2.0 specification).

The cartridge sled is reloadable — the Operator can open the shell to swap, reflash, or re-provision the SD card inside. Per-cartridge save data lives as a file on the cartridge’s own SD card (e.g., /save/<cart_id>.sav). Universal Deck State lives on the device’s onboard microSD and is shared across all cartridges.

8.2 The .kn86 v2.0 Format

A cartridge image is a binary file with the extension .kn86, conforming to the v2.0 specification (see §39). The image consists of:

Header (256 bytes): magic, version, module class, capability bits, section offsets
Code section: Lisp source (tree-walked on load; no bytecode — see ADR-0004 2026-06-14 amendment)
Data section: Tool tables, ICE behavior tables, PSG patterns, generation parameters
Cart-capabilities block (optional): Runtime-gated capability declarations (ADR-0006 §2)
Templates section: Mission templates (parsed by nOSh at cart-load)
CIPHER grammar section: Lisp cipher-grammar block (vocabulary, productions, style overrides)
Clips section: Embedded .kn86clip files (theatrical UI animations)
Save section: Per-cartridge persistent data
Provenance chain: Append-only hash chain (nOSh-managed)

8.3 Loading Sequence

When the cartridge slot detect pin asserts (cartridge inserted), nOS.h:

Reads and validates the header.
Verifies magic = “KN86” and version = 2.
Validates requires_bits against current cartridge_history (warns but permits if unmet).
Validates any cart-capabilities declarations against the allowlist (rejects with error if unauthorized).
Sets the capability bit in cartridge_history.
Allocates per-cartridge Fe arena (32 KB) and grammar arena (8 KB).
Loads (reads + evaluates) the Lisp source and registers NoshAPI primitives as Fe builtins.
Invokes publisher_splash() (3 s maximum).
Parses mission templates and registers with the mission board.
Merges the cipher-grammar block into the active CIPHER grammar.
Invokes (cart-init).
Returns to the mission board. CIPHER-LINE resumes with the coherence stack preserved.

The sequence completes in approximately 4 to 6 seconds.

8.4 Hot Swap and Unloading

When the Operator initiates a Hot Swap (via QUOTE key) or the cartridge is physically removed:

Invokes the cartridge’s (cart-pause) function.
Serializes active phase state to phase_chain[].
Persists Universal Deck State to the device’s microSD.
Frees the per-cartridge Fe and grammar arenas.
Displays the Hot Swap prompt or Bare Deck Terminal.

┌─────────────────────────────────────────────────────────────────────────────┐
│ CAUTION                                                                      │
│ Removing the cartridge during a phase boundary serialization may result      │
│ in the loss of intermediate state. Always wait for the nOSh runtime to       │
│ display "PHASE CHAIN ACTIVE — DO NOT POWER DOWN" to clear before swapping.   │
└─────────────────────────────────────────────────────────────────────────────┘

9. RUNTIME EXECUTION CYCLE

9.1 Main Loop Overview

nOS.h runs a single-threaded main loop on the Deckline’s compute substrate. The loop runs at a target rate of 60 Hz, idling between events to conserve power. The loop has three phases:

   ┌──────────────────────────────────────────────────────────────┐
   │   nOS.h  MAIN  LOOP  (60 Hz target)                            │
   │                                                                │
   │     ┌──────────────────────────────────────────────────────┐   │
   │     │  1. INPUT PHASE                                      │   │
   │     │     - poll key matrix                                │   │
   │     │     - dispatch events to current cell handler        │   │
   │     │       OR nOSh runtime state machine                  │   │
   │     │                                                      │   │
   │     │  2. STATE PHASE                                      │   │
   │     │     - if phase active: cartridge ON_PHASE_TICK       │   │
   │     │     - advance ICE OODA cycles                        │   │
   │     │     - decay trace                                    │   │
   │     │     - check thresholds, emit CIPHER events           │   │
   │     │     - persist state if at boundary                   │   │
   │     │                                                      │   │
   │     │  3. RENDER PHASE                                     │   │
   │     │     - render nOSh status bar (Row 0)                 │   │
   │     │     - render nOSh action bar (Row 24)                │   │
   │     │     - tick active clips (paint regions)              │   │
   │     │     - render runtime overlays (text, glyphs)         │   │
   │     │     - mix PSG audio (44.1 kHz callback, async)       │   │
   │     │                                                      │   │
   │     └──────────────────────────────────────────────────────┘   │
   │                                                                │
   └──────────────────────────────────────────────────────────────┘
                  Figure 9-1. nOS.h Main Loop Phases

9.2 How nOS.h Runs ICE BREAKER

A concrete example: the Operator presses [CAR] while viewing the Network Map during an active ICE BREAKER mission:

Input dispatch. nOS.h identifies the current cell as a network_node instance and looks up network_node->handlers->on_car.

Cartridge handler invocation. nOS.h calls into the Fe VM, executing the Lisp lambda registered as the handler. The handler reads cell state, spawns a child-selection cell, and navigates to it.

State updates. Trace advances, ICE OODA cycles fire, thresholds are checked. If trace has crossed a threshold (30, 50, 75), nOS.h emits a CIPHER event and composes a sentence from the merged grammar pool.

Render phase. Status and action bars paint. Clips tick. Cartridge on_display handler writes overlays. Display flushes.

Loop idle. nOS.h idles until the next input event, ICE cycle, or animation frame.

Total cartridge execution time per main-loop tick is typically under 10 ms.

PART THREE — OPERATING THE DEVICE

10. PHYSICAL CONTROLS

10.1 Function Keys (14)

The Deckline’s input device is a Ferris Sweep — a 34-key split keyboard (two halves, each a 3×5 main block plus 2 thumb keys), adopted per ADR-0031. The fourteen Lisp-primitive function keys live on the left half, each hot-swap Choc keycap engraved with its Lisp name. Thirteen occupy the left main block; the fourteenth, EVAL, is the left inner thumb. The canonical per-key positions are fixed by ADR-0031 §3.1 (BASE layer); this manual reproduces the left-half arrangement for orientation only:

   LEFT HALF — function block (3×5 + 2 thumb)
                    pinky   ring    middle  index   inner-index
   Top row:        [ NIL ] [INFO ] [ FN  ] [CONS ] [LINK ]
   Home row:       [APPLY] [BACK ] [ CDR ] [ CAR ] [QUOTE]
   Bottom row:     [  ·  ] [  ·  ] [ SYS ] [ EQ  ] [ATOM ]
   Left thumbs:    (inner) [EVAL ]   (outer) [LSHIFT]

The home row seats the two highest-frequency list-walk primitives — CDR (middle) and CAR (index home) — as an adjacent rest-and-rock pair, with the three navigation verbs reading outer→inner as BACK · CDR · CAR, each on its own finger (left-half home-row revision, ADR-0031 §3.1, 2026-06-21). The two · bottom-row positions are reserved spares for future (v2) cart-defined verbs and carry no function in v1.0. The key engraved FN is the LAMBDA key, printed “FN” per ADR-0022 keycap legend specifications. LSHIFT (left outer thumb) is a momentary modifier holding the SHIFT layer active while pressed.

10.2 Digit & Punctuation Keys (right half)

The right half of the Sweep carries the data-entry cluster (ADR-0031 §3.1). The nine digit keys form a 3×3 block — 1-2-3 top, 4-5-6 home, 7-8-9 bottom — on the inner three columns; the outer two columns carry the punctuation primaries , . / ; - and ENT. The 0 key is the right inner thumb; TERM (context-sensitive) is the right outer thumb. Reproduced for orientation:

   RIGHT HALF — digit & punctuation (3×5 + 2 thumb)
                    inner-index  index   middle  ring    pinky
   Top row:        [  1  ] [  2  ] [  3  ] [  /  ] [  ,  ]
   Home row:       [  4  ] [  5  ] [  6  ] [  ;  ] [  .  ]
   Bottom row:     [  7  ] [  8  ] [  9  ] [  -  ] [ ENT ]
   Right thumbs:   (inner) [  0  ]   (outer) [TERM ]

The digit block preserves the Nokia digit-to-letter binding (2 = ABC … 9 = WXYZ) from ADR-0016 §6, so the cluster is data-first, direction-optional: cartridges use it for selection (1–9), data entry (digits, plus letters via Nokia multi-tap in Lisp-scripted contexts), or cardinal directions (2/4/6/8 within the 3×3). The phone-style 4×4 numpad of earlier revisions — with * 0 # on a bottom row — is retired: 0 is now a thumb key, and the * / # glyphs are reached through the shift / symbol layers, not as base keys. See ADR-0031 §3.1 and the Canonical Hardware Specification (project CLAUDE.md).

10.3 Power and Reset

The Deckline has a single power switch on the right edge. There is no separate reset; power-cycling the device is the recovery procedure if the nOSh runtime becomes unresponsive.

┌─────────────────────────────────────────────────────────────────────────────┐
│ CAUTION                                                                      │
│ Power-cycling during phase chain serialization may result in loss of         │
│ intermediate mission state. Wait for the on-screen "SAVING" indicator        │
│ to clear before powering off.                                                │
└─────────────────────────────────────────────────────────────────────────────┘

10.4 Cartridge Slot

The cartridge slot is on the bottom edge of the unit. Cartridges are inserted label-up. A spring-loaded ejector permits one-handed cartridge removal. The slot incorporates a detect pin that signals nOS.h when a cartridge is present.

10.5 Audio Output and Linked Play

The internal speaker (28 mm, 8 Ω, 2 W) is driven by the MAX98357A DAC and amplifier. A 3.5 mm TRRS jack on the right edge accepts both standard headphones and the linked-play cable for Sysop Mode (see §33).

11. THE LISP KEY GRAMMAR

11.1 Premise

The function keys are named after the primitive operators of the Lisp programming language. This naming is not decorative; the cell runtime dispatch literally maps each function key to a handler slot indexed by the key’s Lisp meaning. The Operator who has used Lisp will find every key already familiar in semantics. The Operator unfamiliar with Lisp will learn its vocabulary through play.

11.2 Primary Reference

Each function key, its Lisp meaning, and its action within ICE BREAKER:

Key	Lisp Meaning	ICE BREAKER Action
`CAR`	Head of pair	Descend into the current node — enter a child node
`CDR`	Tail of pair	Step back to parent node — traverse rest of path
`CONS`	Construct pair	Open the tool combination matrix — combine two tools
`EVAL`	Evaluate expression	Commit the current decision irreversibly
`INFO`	(Pseudo)	Observe — first press: raw telemetry; double-tap: orient
`BACK`	(Pseudo)	Return to network map view
`FN` (LAMBDA)	Anonymous function	Speculative action OR record next 32 keystrokes as macro
`APPLY`	Apply function	Replay a recorded macro slot against current cell
`QUOTE`	Suppress evaluation	Bookmark current cell ID; OR initiate Hot Swap
`NIL`	Empty / false	Cancel current input; clear selection
`ATOM`	Predicate: leaf?	Test whether current cell is a leaf (free move)
`EQ`	Identity equality	Compare current cell to a quoted bookmark
`LINK`	(Pseudo)	Egress — attempt extraction from network
`SYS`	(Reserved)	nOSh runtime system menu (save, change handle, preferences)

11.3 Universality Across Cartridges

The Lisp grammar is universal across every KN-86 cartridge. The semantic of CAR (“descend into HEAD of current cell”) is the same in ICE BREAKER (enter network node), Black Ledger (drill into transaction), Depthcharge (dive deeper), and NeonGrid (follow checkpoint). The Operator who masters the grammar in ICE BREAKER acquires the input vocabulary for the entire library.

11.4 Dispatch Mechanism

When the Operator presses a function key, nOS.h:

Identifies the current cell from the cell pool.
Looks up the appropriate handler in the cell’s CellHandlers table (e.g., on_car, on_cdr, on_eval).
Invokes the handler with the cell pointer as argument.
The handler runs in the cartridge’s Fe arena and returns control to nOS.h.

The handler may, in the course of its execution, mutate cell state, spawn new cells, navigate to a different cell, modify Universal Deck State, emit CIPHER events, fire audio cues, or load clips for playback. All of these operations are mediated by the NoshAPI surface (§41).

12. THE DISPLAY SYSTEM

12.1 Primary Display (Main Grid)

12.1.1 Logical Canvas

The primary display presents an 80 column × 25 row text grid. Each cell is one 8 × 8 pixel glyph rendered into a 12 × 24 physical cell (via default 8×8 scaling with padding, or opt-in native 12×24 mode per ADR-0014). The cartridge addresses the display in (Row, Column) coordinates.

12.1.2 Row Ownership

Row ownership on the primary grid is invariant:

Row 0: firmware status bar. Displays operator handle, credit balance, reputation tier, current cartridge name, signal strength, and clock. Cartridges may not write to Row 0.
Rows 1-23: cartridge content area. The cartridge has full authority over these 23 rows.
Row 24: firmware action bar. Displays context-sensitive key hints. Cartridges may not write to Row 24.

┌─────────────────────────────────────────────────────────────────────────────┐
│ NOTE                                                                         │
│ During the boot sequence, before nOS.h has rendered the status and action   │
│ bars, the entire 80 × 25 grid is available to the cartridge's               │
│ publisher_splash() function. The bars appear once boot is complete.         │
└─────────────────────────────────────────────────────────────────────────────┘

12.1.3 Color and Glyphs

The primary display is single-foreground at any moment: AMBER #E6A020 default phosphor on black #000000, with WHITE #F0F0F0 and GREEN #33F033 selectable via the SYS-tab aesthetic-mode picker per ADR-0034 (as amended 2026-06-13 per ADR-0036). The grid carries one phosphor at a time; “second color” semantics come from cell inversion (bit 7 of the cell byte selects inversion).

The glyph set consists of 256 characters drawn from the KN-86 Code Page, which combines the printable ASCII range with CP437 box-drawing glyphs and a small set of platform-specific symbols. The font is Press Start 2P (8 × 8 bitmap). A second-layer Unicode font (~2000 glyphs) is planned but not present in v1.0.

12.1.4 Font Rendering Modes

The default rendering (v0.1) scales the 8×8 Press Start 2P bitmap 1× horizontally / 2× vertically with 2 px / 4 px padding inside a 12×24 cell. This output is identical on emulator and prototype.

A native 12×24 glyph table is available opt-in via the --font-12x24 CLI flag (emulator) or KN86_FONT_12X24=1 environment variable, with subtle 2-pixel descenders for q/p/y/g/j. The default will flip to native in a follow-on version after Josh-led visual regression burn-in.

12.2 Auxiliary Display (CIPHER-LINE)

12.2.1 Logical Canvas

CIPHER-LINE is a 3.12-inch 256 × 64 pixel SSD1322 OLED mounted above the key plate. It presents a 32 column × 4 logical row canvas of 8 × 8 glyphs, with each logical row occupying 16 panel pixels of vertical space. It is driven by nOS.h’s OLED driver (running on the Pico 2 coprocessor) over SPI0. The SSD1322’s native pixel element is yellow phosphor, which reads as the same warm-phosphor color family as the primary display’s AMBER default; the aesthetic-mode picker does not retint CIPHER-LINE (it is hardware-fixed yellow).

12.2.2 Row Ownership

CIPHER-LINE row ownership is invariant and non-negotiable:

Row	Purpose	Owner
1	Status strip: battery, mission/gameplay timer, mode chip, TERM hint	nOSh runtime
2	CIPHER live utterance	nOSh runtime generator; cart vocabulary contributes
3	CIPHER echo (prior utterance, fading)	nOSh runtime generator; cart vocabulary contributes
4	Contextual surface: seed capture / gameplay sub-timer / phase meta / linked-deck status	nOSh runtime (mode-switched by cart / phase)

Cartridges never address CIPHER-LINE by (Row, Column) coordinates. The FFI primitives in §41 determine which row a request lands on. This is intentional — it prevents a cart from squatting the status row or overwriting the live CIPHER utterance.

12.2.3 Color and Glyphs

CIPHER-LINE is single-color yellow phosphor (hardware-fixed, not retinted by the aesthetic-mode picker). The glyph set is identical to the primary display (Press Start 2P, KN-86 Code Page).

12.3 Algorithmic Art and Clips (Primary Display Only)

The clip system and runtime algorithmic overlay techniques apply to the primary display only. CIPHER-LINE does not host clips; its rendering is entirely nOSh-runtime-driven through the CIPHER runtime and the auxiliary primitives.

Clips (.kn86clip files): pre-rendered terminal animations with declared regions, fps, and embedded audio cues. Authored offline in the Remotion-backed TypeScript DSL. Played at runtime via the NoshClip API.
Runtime algorithmic overlays: per-frame procedural art drawn by cartridge handler code. Used for visualizations dependent on dynamic state (Perlin trace heat maps, Voronoi territories, current-cell highlights).

ICE BREAKER uses both on the primary display. See §45.

13. THE AUDIO SYSTEM

13.1 The Sound Generator

Audio is produced by a software emulation of the YM2149 Programmable Sound Generator. The YM2149 provides:

Three independent square-wave tone voices (A, B, C), each with programmable frequency (30 Hz to 125 kHz) and individual volume.
One white-noise channel with programmable rate, mixable into any tone voice.
One shared envelope generator with selectable shape (sawtooth, triangle, one-shot, etc.), attachable per voice.

The YM2149 emulation runs on the Pico 2 coprocessor at 44.1 kHz, mixing to mono PCM and routing through the MAX98357A DAC and amplifier.

13.2 Voice Channel Assignment in ICE BREAKER

ICE BREAKER assigns the three voices as follows:

Voice	Role	Continuous?
Voice A	ICE proximity alarm — pitch encodes threat level	Always on; pitch modulated
Voice B	Data flow / extraction telemetry — pulse rate encodes throughput	Event-driven
Voice C	Environmental chaos / sysop activity — drone or noise mix	Event-driven, intensity-keyed

The noise channel is mixed in for tool failures, scanline glitch effects above trace = 50, dial-up modem fictions on LINK, and RED ICE death stingers.

The envelope generator shapes tool-fire arpeggios, the alarm pulse, and the Hot Swap reboot tone.

13.3 Audio as Information

The audio system in ICE BREAKER is load-bearing gameplay, not decorative scoring. Per §21, the trained Operator can identify ICE classes by audio signature alone, can navigate the network with the screen off at moderate threat levels, and can detect HUNTER activation by the all-three-voice spike characteristic. Cartridge audio design is calibrated for this use.

13.4 Mix Discipline

YM2149 polyphony is limited (3 voices + 1 noise). ICE BREAKER’s audio design works through time-domain composition rather than frequency-domain layering:

Voice A is the constant; Voices B and C are event-driven and frequently silent.
A sidechain is implemented via the YM2149 mixer register: when a CONS arpeggio fires on Voice B, Voice A is briefly attenuated for 400 ms so the arpeggio is not masked.
INFO double-tap (Orient) silences Voices B and C and reduces Voice A to half volume — the audio space opens to permit operator concentration.
Hot Swap produces complete silence for the duration of the physical swap.

14. THE TERM KEY AND THE LISP REPL

14.1 The TERM Key

The TERM key is the 31st physical key on the Deckline, mounted on the right side of the key plate. TERM is context-sensitive — its binding depends on what surface has priority at the moment:

Default binding (priority 5): Opens the Lisp REPL — a read-eval-print loop overlay.
Seed-capture binding: When CIPHER-LINE Row 4 is in seed-display mode, TERM captures the displayed seed value into a quote slot.
Higher-priority bindings: Reserved for hot-swap defer, CIPHER freeze, or cart-scoped context-polymorphic dispatch (per ADR-0016 priority table).

See §14 of docs/software/programs/repl.md (ADR-0002, ADR-0016) for the full context-polymorphic dispatch model.

14.2 The REPL Overlay

Pressing TERM with no higher-priority surface active slides down a toast overlay from Row 1, occupying Rows 1–10 (40% of the 25-row viewport). The REPL presents:

Input line (1 row): where the Operator types s-expressions
Output buffer (6–8 rows): where results are printed
History ring (16 slots, persisted to deck state): recalled via CDR while the REPL is open

The active cartridge — if one is loaded — pauses for the duration of the REPL session; the cart framebuffer is preserved byte-exact and restored on close. A second TERM press dismisses the REPL.

14.3 REPL Capabilities

The REPL exposes:

All 54 NoshAPI primitives (text, sound, deck state, cell pool, LFSR, CIPHER — see §41).
Full Lisp language support via the Fe VM (symbols, lists, lambdas, arithmetic, predicates).
Cartridge-context access — the REPL runs in the loaded cartridge’s Fe arena, so it can read/write cartridge state.
Per-deck history persistence — the last 16 REPL commands are saved to Universal Deck State and recalled across power cycles.

Typical use: debugging gameplay logic, peeking at deck state, writing quick lambdas for scripted missions, recording audio cues.

14.4 Permanent Surface Advertising

The REPL is always reachable, so the firmware always advertises it. The right edge of Row 24 (firmware action bar) carries a permanent indicator:

[TERM:REPL] when the REPL is closed.
[TERM:EXIT] when the REPL toast is visible.

This advertisement occupies columns 65–78 of Row 24. It is painted by the runtime AFTER cartridge Row 24 owners write their action-bar content, so the right-edge slice always reflects the REPL state of the world.

15. THE CIPHER NARRATOR

15.1 Definition

CIPHER is the Deckline’s procedural narrator. It generates short text observations that appear exclusively on the CIPHER-LINE auxiliary display (Rows 2–3), optionally accompanied by a per-glyph click track on PSG Voice A. CIPHER is not synthesized speech; “voice” is metaphorical. CIPHER is structurally an event-driven prose generator: it consumes typed events, walks a grammar under a weighted mode selector, and writes the result to a dedicated 32-character OLED line above the key plate.

Per ADR-0015, CIPHER renders ONLY on CIPHER-LINE. The primary 80 × 25 grid carries cartridge content only; no CIPHER glyph appears on the primary grid under normal operation. The Null cartridge is the single sanctioned exception (a designed gameplay mechanic).

15.2 The Five CIPHER Modes

CIPHER has five emotional modes, selected at runtime by a weighted mode selector:

Mode	Character	When Used
observe	Literal, technical, present tense	Normal operation; raw data reporting
annotate	Commentary, evaluation	Threat escalation; high-tension moments
reflect	Memory, temporal recursion	Phase transitions; cross-cart swaps
drift	Poetic, detached, nostalgic	Cart swap lull; low-threat periods
silent	No utterance	High pressure; allows full operator focus

The mode selector is seeded by cipher_seed (part of Universal Deck State) and biased by:

Current reputation tier (Masters hear more silence; Apprentices hear more annotation).
Per-phase mode-weight biases contributed by the cartridge (e.g., :active-hack → more observe, more silence).
Style control deltas (e.g., high tension → clipped and uncertain; debrief → slightly looser).

15.3 CIPHER Events and the Event Ring

Cartridges report observations to CIPHER by calling cipher-push-event (Para 41.4). Each event is folded into a 128-slot event ring keyed by event type and carrying affect flags.

Decay runs on a 15-second wall-clock tick. Normal events decay 1 per tick; :significant events decay 1 per 3 ticks; :anomalous events decay 1 per 10 ticks. The generator weights an event for sampling by decay / max_decay, so fresh events dominate utterance composition and stale events fade out.

15.4 CIPHER Coherence and Deduplication

The coherence stack holds 5 recent CIPHER utterances (hash + timestamp). It persists across cartridge swaps — when the Operator swaps modules, CIPHER remembers what it just said and avoids immediate repetition.

The generator checks a candidate utterance against the coherence stack; it suppresses with probability if a recent surface-string match exists (the probability depends on the temporal gap and affect flags).

15.5 Per-Cartridge CIPHER Grammar Contributions

Each cartridge (including ICE BREAKER) contributes vocabulary and production rules to the CIPHER generator at cart-load. Contributions are merged into an active grammar working set and cleared at cart-unload. ICE BREAKER’s contributions are described in §44.

15.6 CIPHER-LINE Rendering

The nOSh runtime’s CIPHER generator fires asynchronously on cipher-push-event calls, composing a sentence from the merged grammar pool and writing it to CIPHER-LINE Row 2. The prior Row 2 shifts down to Row 3 (echo). If a click track is requested, the runtime plays a soft 2 kHz per-glyph tick at 30% volume on Voice A.

PART FOUR — THE GAME OF ICE BREAKER

16. DESIGN PHILOSOPHY

ICE BREAKER is a tempo sport. The Operator does not solve puzzles; they read systems. Four independent OODA loops run in parallel: the Operator’s (Observe → Orient → Decide → Act), the Network’s (topology generation and ICE placement), the Threat’s (ICE classes cycling at different rates), and the Toolkit’s (consumable tools that shape the Operator’s decision frame).

Emergence lives in the collisions of these systems. The Operator who reads faster than the threat cycles wins. The Operator who matches their tempo to their toolkit loadout discovers surprise combos. The Operator who respects network memory learns that repeated seeds are harder. The Operator who listens to the YM2149 can navigate with the screen off.

Hot Swap (mid-run cartridge swaps) is the apex mechanic. It expands decision space and creates physical, ritual moments that are tactile and strategic. A mid-mission swap is not a rescue — it is an elegant decision to acquire a capability the current cartridge lacks. The Operator who uses Hot Swap strategically opens new solution paths.

The perfect session is not scripted. It emerges from the collision of these four systems and the Operator’s skill at reading them under time pressure.

17. THE OODA CYCLE

17.1 The Atomic Unit of Play

The OODA cycle — Observe, Orient, Decide, Act — is the atomic unit of ICE BREAKER play. A single cycle typically runs 0.3–2.0 seconds depending on threat level and Operator tempo. The Operator’s cycle races against the Network’s generation cycle, the Threat’s ICE cycles, and the Toolkit’s consumption pressure. The Operator who cycles faster than the threat system survives.

17.2 OBSERVE (0.5 seconds)

The Operator presses [INFO] to observe the current state.

What the screen shows: Current node’s ICE class (text label), connection count, encryption depth, tool slots remaining, trace level, estimated traversal time to egress, and whether the current cell is a leaf (safe to stay) or a bottleneck (ICE can trap you).

What the audio shows: The YM2149 plays three voices in real time:

Voice A (ICE proximity alarm): pitch rises as threat increases. A low hum = distant threat. A shriek = immediate danger.
Voice B (Data flow / extraction rate): pulse rate encodes tool efficiency and encryption resistance.
Voice C (Environmental chaos / sysop activity): drone pitch encodes network instability and defensive escalation.

The Operator’s action: Absorb telemetry. Listen. The OBSERVE phase has a fixed duration (0.5s) before the network advances. The Operator has 0.5 seconds to see what the situation is. The network is still ticking. Threats still advance.

17.3 ORIENT (0.5 seconds)

The Operator presses [INFO] again (double-tap) to orient into the situation.

What CIPHER provides: The CIPHER narrator (rendered as clipped fragments on CIPHER-LINE Rows 2–3) interprets the situation. At low reputation (Apprentice, Journeyman), CIPHER is verbose: “Node is JUNK-class. Slow. You can brute-force or traverse.” At high reputation (Master, Legend), CIPHER goes silent — you are expected to interpret the data yourself.

What the Operator learns: The Operator does not consciously learn CIPHER’s interpretations during solo play. Instead, they absorb patterns. After five runs, an Operator recognizes JUNK signatures by audio alone. After twenty runs, an Operator sees a node and instantly knows which tools will be most efficient.

The Operator’s action: Synthesize the data into a decision frame. What are the options? What does the toolkit afford? What is the risk of each choice? This is where learned skill compounds. An Operator with Depthcharge history recognizes encrypted relay signatures and fast-paths the decision. An Operator without history must synthesize from first principles.

The Orient window: 0.5 seconds. The network is ticking. Threats are closing.

17.4 DECIDE (1.0 second)

The Operator now chooses an action. This is where Hot Swap enters as a decision moment. Possible decisions:

Navigation: Press [CAR] to descend into a child node via numpad selection (1–9, or CDR to cycle). Press [CDR] to traverse back to the parent node (always safe, though ICE may pursue). Press [BACK] to return to the network map view.

Tool use: Press [CONS] to enter the combination matrix. Select two tool archetypes (via numpad or numpad repeat). The matrix shows the combined result: intuitive combos are predictable (CRACK + MIRROR = QUICKCOPY), surprising combos are discoverable via repeated use (CRACK + GHOST = REWRITE). Once combined, both tools are consumed permanently.

Speculative action: Press [LAMBDA] to initiate a speculative action — exploit a vulnerability you haven’t fully mapped, use a tool without full confidence, or attempt an unorthodox combination.

Extraction: Press [LINK] to attempt egress from the current node. This is only possible from certain nodes. Successful extraction ends the run with payout.

Hot Swap decision: If the Operator realizes mid-decision that they need a capability not loaded, this is the Hot Swap moment. The CIPHER voice has been warning for 3–4 turns: “gap. network deeper. / not this one.” (rendered as clipped fragments on CIPHER-LINE). The Operator can press [QUOTE] to acknowledge and initiate a physical cartridge swap. The network advances at half-tempo while the swap is in progress. The swapped-in cartridge enters scoped capability mode — it doesn’t load its full experience, just its signature capability applied to the current problem.

The Operator’s action: Decide which action best matches the situation, the toolkit, and the Operator’s risk tolerance. This is the highest-skill moment in the cycle.

The Decide window: 1.0 second. The network is ticking. The threat is adapting.

17.5 ACT (Immediate)

The Operator presses a key. This is irreversible. The network responds.

What happens: Press [EVAL] (the confirm key) to commit the decision. The cartridge’s nOSh API processes the input:

If a tool was selected, it is consumed and applied. The network changes state. New ICE may spawn.
If traversal was chosen, the Operator moves. New node data loads. Threats advance.
If egress was chosen, the game attempts to route back to the entry node. Success = run ends, payout awarded. Failure = remain in network, trace increased.

The sound response: The YM2149 plays a response tone. Voice 1 pulses (ICE reacting). Voice 3 may spike (threat escalating). Voice 2 may accelerate (data extraction in progress) or drop to white noise (tool failure).

The screen updates: The Operator immediately sees the new state. ICE may have moved. Trace may have increased. A new tool slot may be available (if a combo was just consumed). The cycle repeats.

Tempo implication: The Operator immediately begins the next OODA cycle. There is no pause between cycles. The fastest Operators cycle at 2–3 cycles per second. The slowest cycle at 0.5–1 cycle per second. This is the fundamental skill asymmetry.

17.6 Why Tempo is the Core Skill

An OODA cycle has a natural duration. The network advances at a fixed tempo:

Node traversal time: 1–3 turns per move (depending on network topology).
ICE spawn rate: 1–2 new ICE per node per turn (depending on threat escalation).
Trace accumulation: 1–5 points per action (depending on tool and ICE class).

The threat (JUNK, BLACK, RED, HUNTER) cycles at different tempos:

JUNK cycle: 2 seconds (slow, predictable).
BLACK cycle: 1 second (adaptive, medium).
RED cycle: 0.5 seconds (aggressive, fast).
HUNTER cycle: 0.5 seconds, then accelerating (0.4s → 0.3s → 0.2s per turn).

The Operator cycles at whatever speed they can process. An expert Operator’s cycle rate: 2 cycles per second (every 0.5s, OODA completes). A novice’s cycle rate: 1 cycle per second. The threat advances regardless.

When the Operator’s cycle rate exceeds the threat’s cycle rate, the Operator gains tempo advantage: They are reading and deciding faster than the threat can react. They slip through a network gap before HUNTER spawns. They extract data before trace reaches critical. They retreat before ICE locks the exit node.

When the Operator’s cycle rate falls below the threat’s cycle rate, the threat takes initiative: HUNTER enters the Operator’s node. ICE cascades. Trace accumulates faster than the Operator can process. Failure.

The YM2149 is the tempo instrument. As threat cycles accelerate, Voice 1 rises in pitch. As the Operator’s cycle rate accelerates, Voice 2 becomes more confident, less stuttering. Expert Operators play the device like a drummer playing a kit — the audio is as much information as the screen. A Specialist can hear their own tempo reflected back by the YM2149 and adjust their pace in real time.

18. THE NETWORK

The network is an organism, not a puzzle. It is a procedurally generated directed graph of 8–16 nodes per contract. Each node is a cell: a corporate system, an encrypted relay, a finance server, a personnel database.

18.1 Topology and State

The network is seeded by contract parameters: threat level (1–5), contract class (PENETRATION, EXTRACTION, SABOTAGE, SURVEILLANCE IMPLANT), and cartridge history (which modules the Operator has loaded). The seed determines:

Number of nodes: 8–16 per contract (threat-level-dependent).
Node distances: Traversal time between nodes (1–3 turns per move).
ICE populations per node: 0–3 instances of JUNK, BLACK, RED, or HUNTER.
Encryption depth: Which tools are required to crack each node (1–4, where 4 = critical).
Entry point: Usually a public-facing node (low ICE, low encryption).
Exit point: Usually the same node, 15 nodes deep for Threat 5.

Each node has state:

ICE population: 0–3 instances running independent OODA cycles.
Intrusion memory: If the Operator triggered ICE here before, they remember. Returning to that node is harder.
Encryption state: Which tools have been applied. Once decrypted, stays decrypted (until network resets after extraction).
Data payload: What the Operator is extracting (0–100 credits equivalent).

The Operator navigates the network as a Lisp list structure (see §11.2 for key semantics):

[CAR] to descend: The current node is the HEAD of a traversal path. Press CAR to select a child node. The screen shows 3–4 options (adjacent nodes). Press a numpad key (1–9) to select. The Operator enters that node. The traversed-to node becomes the new HEAD.

[CDR] to ascend: Step back to the parent node. This is always safe to execute (no encryption barriers), though ICE may pursue the Operator as they retreat. CDR is a “rest of the path” operation — it returns to where the Operator came from.

The entry node is root (Node 0): Egress requires routing back to root and pressing [LINK]. On a Threat 4 or 5 contract, this is not a trivial task. The Operator may take damage (lose credits, increase trace) on the way out.

18.3 Fog of War and Observation

The Operator cannot see the full network topology. Only the current node and adjacent nodes (3–4 choices) are visible on the primary display.

[INFO] single press reveals:

Current node’s ICE class and population.
Connections to adjacent nodes (with labels).
Trace level (how much attention the Operator has drawn).
Time estimate to next ICE spawn or threat escalation.

[INFO] double-tap reveals full sensor data (Cipher annotation):

Encryption depth of adjacent nodes.
Estimated tool requirements.
Historical data (has this node been visited before?).

The network is a mystery. Learning happens through exploration and repeated runs. An Operator who has completed three Threat 3 contracts begins to recognize patterns: node types, ICE placements, traversal logic. This is Orient learning. A Master-tier Operator can estimate the network topology after two moves and plan a route to the objective.

18.4 Network Memory: The Residue of Intrusion

The network remembers. Repeated intrusions change the topology. If the Operator triggered ICE at Node 7 on their first run, Node 7 is now reinforced. The network has learned from the intrusion.

Specifically:

Nodes where ICE was triggered spawn ICE faster: Reinforcement.
Connections the Operator used repeatedly become slower: The network routes traffic away from known intruders.
Encryption depth increases in areas where tools were used: The sysop patches vulnerabilities post-intrusion.

This is why failed runs are not wasted. A failed run leaves trace data that enriches the next Operator’s Observe phase. Trace is not punishment — it is a gift of information. A network the Operator has explored before is slightly faster to read because they have seen the shapes.

This mechanic also discourages seed repetition. An Operator who runs the same contract seed twice will find it harder the second time. The network has adapted. This is intentional design — unique runs are more interesting than optimized repeats.

19. THE THREAT

ICE (Intrusion Countermeasure Electronics) are autonomous defensive systems. Four classes, each with a different tempo and learning strategy.

19.1 ICE Classes and Cycle Speeds

Class	Cycle Speed	Behavior	Notes
JUNK	2.0 s	Slow, pattern-predictable, stateless	Defends single nodes; easy to brute-force; no memory
BLACK	1.0 s	Adaptive, reads Operator patterns	Defends regions; learns from intrusions; encrypts deeper after tool use
RED	0.5 s	Fast, aggressive, spawns children	When defeated, spawns JUNK to its node + propagates notification to adjacent nodes
HUNTER	0.5–0.2 s, accelerating	Cascade effect; all-systems spike	Spawned at trace=50; chases Operator across nodes; cannot be killed, only evaded/slowed

Each ICE class cycles at a different tempo. The Operator who reads the threat’s cycle and acts between its beats maintains tempo advantage.

19.2 The Threat OODA: Parallel to the Operator

Each ICE instance runs a tiny OODA against the Operator:

OBSERVE: Detect Operator presence. ICE senses keypress volume, trace level, tool consumption. Faster keypress tempo = higher threat to the ICE’s assessment.

ORIENT: Classify the intruder. Apprentice (slow decisions, many tool uses = panicked). Journeyman (medium pace). Specialist (fast, measured, tool-efficient). Adapt response accordingly.

DECIDE: Spawn additional ICE? Escalate encryption? Summon HUNTER? Wait and watch?

ACT: Execute decision. New ICE spawns. Encryption depth increases.

This is why repeated intrusions change the network. The sysop (embodied as the network’s immune system) learns the Operator’s patterns. Fast Operators are recognized sooner and countered harder. Novices get second chances. A Specialist running at 2 cycles per second will face escalated defenses; an Apprentice running at 0.5 cycles per second will face slower responses.

19.3 Trace: The Pressure Mechanic

Trace is an accumulated score of Operator attention. Every keypress adds trace. Using a tool adds trace. Triggering ICE adds trace. Trace decays slowly over time (the Operator is forgotten if they stop moving).

Trace accumulation:

Each keypress: +1 trace.
Each tool use: +2–10 trace (tool-dependent; CRACK = +10 trace, MIRROR = +2 trace).
Triggering ICE: +5–20 trace (ICE-class-dependent).

Trace decay: Slow. Trace decays 1 point per 15 seconds of real time (approximately 1 point per 10 turns of game time).

Trace thresholds:

Trace = 30: Perimeter alert. Cipher voice warns: “gap. perimeter alert / 3 turns.” Voice C fades in with a warning pulse. The Operator has 3–4 turns to egress or escalate.
Trace = 50: HUNTER spawn. A second adversarial system activates. HUNTER is spawned at a random node and begins chasing the Operator. HUNTER’s cycle accelerates each turn (0.5s → 0.4s → 0.3s). At trace=50, the tempo inverts. The Operator must now cycle faster or die.
Trace = 75: Network lockdown. Exit nodes seal. The Operator cannot egress via [LINK]. Instead, they must fight through ICE to escape (take damage, lose credits, or remain trapped). Trace decays at double speed during lockdown (the network is burning resources to contain the intrusion).

19.4 Detection ≠ Failure

This is critical to understand. The Operator does not fail when detected. Detection is a mode change, not a loss state. The tempo shifts. ICE is now hunting. The Operator must cycle faster or die.

A Specialist Operator at trace=35 with CLOAK available might stay in-network and ride out the search, using CLOAK to drop trace and avoid HUNTER spawn. A Journeyman Operator at trace=35 will abort and egress (a safe but lower-reward choice). Both are valid tactics. The Specialist is higher-skill and higher-reward.

20. THE TOOLKIT

Tools are consumable verbs. They are generated at cartridge load time and depleted on first use. The Operator never refills a tool during a run — what they load with is what they have.

20.1 The Six Core Archetypes

CRACK — Brute-force encryption. Fast (1–2 turns), noisy (high trace cost, +8). Always succeeds. Suitable for low-security nodes. Leaves obvious signs.

MIRROR — Copy data without removing it. Quiet (low trace cost, +2). Slow (2–3 turns). Requires the node’s data type to match or a successful sonar analysis (Depthcharge). Suitable for data extraction without triggering alarms.

SPIKE — Inject command code. Redirects ICE behavior, spawns false nodes, or clears a path. Variable cost (+4–8 trace). High-damage. Can trigger alarms (RED spawns if SPIKE targets RED-class ICE).

CLOAK — Mask Operator identity. Reduces trace accumulation (tools used while cloaked cost 50% less trace). Lasts 3–4 turns. Buys time but doesn’t disable ICE.

SIPHON — Extract credits from encrypted finance nodes. High payout (20–80 credits on success), high risk (+6 trace). Requires sufficient bandwidth (roughly: node data size < 40 credits). Risky on guarded nodes.

GHOST — Erase evidence of intrusion. Retroactively reduces trace by 10 points. One use. Useful at critical moments (trace = 70, GHOST brings it to 60). Cannot be used mid-mission if GHOST node is no longer accessible.

20.2 CONS: The Combination Matrix

The toolkit is built by pressing [CONS] and selecting two archetypes via numpad (or numpad repeat for direction + numpad select). The combination generates an emergent tool. The matrix is a 6×6 grid.

Intuitive combinations (predictable results):

CRACK + MIRROR = QUICKCOPY (faster copy, moderate risk, +4 trace)
SPIKE + CLOAK = PHANTOM (inject code while masked, stealthy, +3 trace)
SPIKE + SIPHON = GRIND (extract credits faster but noisier, +7 trace)
CRACK + SPIKE = RAVAGE (break encryption + inject malware, high damage, +12 trace, spawns additional ICE)
MIRROR + SIPHON = ECHO (copy and extract simultaneously, +5 trace)
CLOAK + GHOST = FADE (mask + retroactively erase, powerful but not easily discovered, +1 trace)

Surprise combos (discoverable only through exploration or Orient hints):

CRACK + GHOST = REWRITE (retroactively change which nodes the Operator visited — ICE forgets you were ever there. Trace is reduced to 0. One-time use. Game-changing.)
MIRROR + CLOAK = SHADOW (copy data while becoming invisible; trace is not accumulated during use. Trace stays at pre-use level. Powerful for high-value extractions.)
SIPHON + CRACK = LAUNDER (extract credits through encrypted finance channels with no trace accumulation. Money moves through encrypted pipes, leaving no signature.)

These surprise combos are hinted at through context. An Orient double-tap in a heavily encrypted node might give Cipher a line: “Deep encryption. A tool that combined deep cracking with retroactive erasure would be impossible to detect.” (This hints at REWRITE.) Experienced Operators will experiment and find these surprise combos through trial, then add them to their personal library.

20.3 Resource Tension and Consumption Discipline

Each tool is consumed on first use. No degradation counter. One use, then gone. This creates vertical tension: “Do I have the tool I need right now?”

The tension is acute during [CONS] decisions. CONS consumes both archetypes permanently. If the Operator has CRACK and MIRROR available, using CONS to create QUICKCOPY eliminates both tools. The decision is painful: use CRACK now (solo), or wait and CONS QUICKCOPY later?

If the Operator waits and moves to the next node, CRACK and MIRROR are still available. But if ICE spawns, they may have to burn resources they didn’t plan on. Tempo pressure forces the decision.

20.4 Why Your Toolkit Shapes Orient

The toolkit the Operator loads with is their decision frame. It is not a random assortment — it is a signature.

An Operator loaded with SPIKE, SPIKE, MIRROR, and CLOAK is prepared for a stealthy run: mask, inject disruptively, copy, fade. Their Orient phase is biased toward stealth. Their decisions favor evasion.

An Operator loaded with CRACK, SIPHON, SIPHON, and GHOST is prepared for a grab-and-run: smash through encryption, extract credits, erase traces. Their Orient phase is biased toward speed and financial gain. Their decisions favor aggression.

The contract may not reward the Operator’s toolkit. A Threat 4 contract in a heavily encrypted network (requiring multiple CRACK uses) will punish an Operator with two SIPHON tools. Mismatch creates tension and teaches the Operator: your toolkit shapes what decisions you can make. A balanced toolkit is more flexible. A specialized toolkit is more powerful but riskier.

Experienced Operators bring a balanced toolkit: 1–2 archetype pairs that generate multiple useful combos. Novices often load full CRACK stacks and get locked out of finance nodes.

This is learning at the content level. It is not tutorial — it is felt through play.

21. SOUND AS INFORMATION

The YM2149 PSG is the fourth independent agent in the ecosystem. It is not background music. It is a real-time data channel. Per Para 13 (The Audio System) and Para 15 (The CIPHER Narrator), the three voices carry load-bearing gameplay information.

21.1 Three Voices as Information Channels

Voice A: ICE Proximity Alarm. Base frequency is set at cartridge load. As threat approaches, pitch rises. Threat=1 at 200 Hz (barely audible hum). Threat=5 at 2800 Hz (piercing shriek). An experienced Operator can hear ICE spawning before it appears on screen. The rate of pitch change is tempo information. Sharp increases mean HUNTER acceleration. Slow increases mean JUNK-class movement.

An Operator playing by ear alone (screen off, eyes closed) can estimate threat class and proximity from Voice A alone. This is not flavor. This is a valid play strategy. Speedrunners use sound-only modes. Accessibility feature as advanced technique.

Voice B: Data Flow / Extraction Telemetry. The rate of Voice B pulses indicates extraction progress and encryption resistance. A tool is working quickly if Voice B accelerates. Encryption is deep if Voice B is stuttering. At full extraction, Voice B plays a rising arpeggio (4–8 notes, rarity-keyed). At full failure, Voice B dies to white noise (tool failed, ICE resisted).

Voice C: Environmental Chaos / Sysop Activity. Network instability, escalation status, and global threat level. When Voice C is silent, the network is calm and explorable. When Voice C is loud, the sysop is active and ICE is coordinating. Silence is exploration time. Noise is pressure.

21.2 The Audio Signature Catalog of Key Moments

OODA entry ([INFO] keypress): A low tom (acknowledgment tone). Signal: the Operator has initiated observation.

Tool selection ([CONS]): A descending arpeggio. Complexity indicates tool rarity. Basic combos = 4-note arpeggio (simple). Surprise combos = 8-note arpeggio with dissonance (complex, rare).

Successful tool use: Rising tone, high-pitched stab. Duration is proportional to tool effectiveness. A quick stab = fast tool. A long tone = slow tool. A major chord stab = successful extraction.

Tool failure: Tone cut short, replaced by white noise. Signal: the tool didn’t work. ICE resisted. Trace increased.

ICE spawned: Voice 1 jumps, a sudden attack. The attack differs per ICE class. JUNK = slow rise. BLACK = rapid rise. RED = sudden spike with chaotic secondary tones (Voice 3 spikes too). HUNTER = all three voices spike simultaneously, then Voice 1 locks into a rising pitch (urgent, accelerating).

Trace accumulation: A low, persistent drone that increases in volume as trace approaches critical. At trace=30, the drone becomes a rhythmic pulse (warning tone). At trace=75, the pulse dominates the mix (system lockdown imminent).

Egress attempt, success: A resolving major chord (victory stinger). Signal: the extraction was successful.

Egress attempt, failure: A discordant crash, replaced by Voice 1 alarm (threat still active). Signal: the exit route is blocked. ICE is still hunting. The run continues (or fails, depending on trace level).

Cartridge swap (Hot Swap): A distinctive multi-voice stab (all three voices, rising pitch) as nOS.h writes the phase chain to SRAM, then complete silence during the physical swap, then a reboot tone (high-pitched, digital) as the new cartridge initializes. Signal: cartridge change in progress. Network is at half-tempo.

21.3 Play-by-Ear as Advanced Technique

A Specialist Operator with 20+ runs under their belt can navigate a Threat 3 contract with the screen off, using sound alone. This is not a designed feature — it is an emergent skill learned through repeated use.

The Operator hears Voice 1’s pitch and knows threat approach. Hears Voice 2 accelerate and knows extraction is working. Hears Voice 3 go quiet and knows the network is calm enough to explore new paths.

This is why sound design is mechanical, not cosmetic. The YM2149 is a sensory extension of the Operator. It is information, not flavor.

22. HOT SWAP

22.1 The Apex Decision Moment

Hot Swap is the mid-mission cartridge exchange mechanic. It is the peak decision moment in a run. It is the moment where the Operator realizes: “I need a capability I don’t have loaded.”

The Cipher voice announces capability gaps in advance. On turn N-3 (3–4 turns before the gap becomes critical), Cipher intones: “gap. network deeper. / not this one.” (rendered on CIPHER-LINE Rows 2–3 as clipped fragments). This is not a trap. This is a warning. An Operator on a Threat 3 contract might ignore it. An Operator on Threat 5 will prepare.

The gap manifests as an inaccessible node. The Operator sees a financial-network node (SIPHON territory) but their current cartridge is ICE BREAKER (intrusion-focused). They have SIPHON available, but it’s unpowered by the cartridge’s capability model. Or they encounter an encrypted underwater relay (Depthcharge sonar territory) and they don’t have the capability to analyze it.

The decision point: Do I brute-force this problem (possible, high risk), or do I Hot Swap?

22.2 The Swap Mechanic

Acknowledgment: Press [QUOTE] on the Deckline. The nOSh runtime announces via Cipher voice: “swap initiated.” (rendered as clipped fragments on CIPHER-LINE: “swap. ready.” / “remove. now.”).
Physical swap: The screen goes black. The YM2149 stops. The Operator has 5–10 seconds (real time) to pull the current cartridge and insert the target cartridge into the SD-card-sled slot (see ADR-0019 for physical interface spec). This is real time, not game time. A Sysop (paired Operator in linked play) may interfere by pressing keys to accelerate threat while you’re swapping. Tension.
Reboot: The new cartridge initializes. The nOSh runtime loads the mission state from the phase chain (the mission state is preserved across cartridge swaps). The screen returns to the network view. Cipher voice: “capability. loaded. scope mode active.” (rendered as: “scoped. ready.” / “3 turns.”).

22.3 Scoped Capability Mode

The swapped-in cartridge does not fully load. It enters scoped capability mode: only its signature capability is available. An Operator who swaps to Depthcharge gets sonar analysis tools but not the full Depthcharge experience (which is a deep-sea exploration narrative with its own contract types, progression, and aesthetic).

This prevents the Operator from becoming lost in a different cartridge’s world. You swap, solve the capability problem, then swap back (or continue forward, deeper into the network, with a new capability available). Scoped capability mode lasts approximately 10 seconds (game time) before reverting to normal cost.

During scoped capability mode, the swapped cartridge’s tools are 50% power — they cost less trace, but their effectiveness is reduced. This is intentional: the Operator gets a glimpse of the capability without fully gaining it.

22.4 Network Advance During Swap

While the Operator is holding the Deckline (but the screen is black), the network advances at half tempo. ICE does not spawn. Threats do not escalate. Trace accumulation pauses. This gives the Operator a small safety window — approximately 10 seconds of game time, even if the physical swap takes longer.

The Cipher voice counts down: “swap time. 3… 2… 1… / resuming. tempo.” (rendered on CIPHER-LINE). After the countdown, the network resumes at full tempo. If the Operator hasn’t finished the swap, the run is at risk — HUNTER will spawn mid-swap, ICE will reposition, and trace will spike.

22.5 Strategic Implications

Hot Swap has several properties that make it interesting:

It requires external action. You must physically move. The game becomes embodied. On a real KN-86 (hardware version), you are literally opening the cartridge slot, feeling the card edge, seating the new cartridge. This is not a menu. This is ritual.
It creates multiplayer tension. If you’re playing Sysop Mode (asymmetric two-deck linked play), the sysop can see you swapping and accelerate threat. The human defender is now playing against your physical action, not just your digital decision.
It expands decision space. The Operator who owns two or three cartridges has more options. An Operator with ICE BREAKER, Depthcharge, and Black Ledger can approach a mixed-threat contract with three different capability sets. An Operator with only ICE BREAKER must solve problems within its domain.
It is always a choice, never required. On Threat 1–2 contracts, Hot Swap is never necessary. You can brute-force your way through. The Operator who chooses to swap is taking a more elegant path or exploring a deeper level. The Operator who doesn’t swap is still valid. But they are aware of what they gave up.

┌─────────────────────────────────────────────────────────────────────────────┐
│ CAUTION                                                                      │
│ Do not initiate Hot Swap during phase-chain serialization. Wait for the      │
│ "PHASE ACTIVE — DO NOT REMOVE" message to clear. Removing the cartridge     │
│ during serialization may corrupt the active phase chain and require run      │
│ restart.                                                                      │
└─────────────────────────────────────────────────────────────────────────────┘

23. EMERGENT INTERACTIONS

Emergence lives in collisions of the four systems (network, toolkit, threat, sound). No two runs are identical because the systems are independent and the Operator is learning.

23.1 The Degrading-Toolkit Collision

An Operator on turn 6 of a 12-turn contract realizes they’ve used CRACK, CLOAK, and MIRROR. They have SIPHON, SPIKE, and GHOST remaining. The next three nodes require speed (short traversal window before ICE spawns). SPIKE is fast (+2 turns). SIPHON is slow (+3 turns). GHOST is useless (no evidence yet to erase).

The Operator must choose: Use SPIKE now (gain tempo, but spawn RED) or wait for SIPHON to be useful later (risk encounter with undecrypted nodes). They use SPIKE. It spawns additional ICE (RED side effect). Now ICE is coordinating across nodes. The Operator’s tempo window closed. They must abort and egress.

This is not a failure state designed by the author. This is an emergence: the toolkit depletion state collided with the network state to create a new strategic problem. The Operator learns: over-commit to speed early and you create cascading costs later.

23.2 The Network-Memory Collision

An Operator completes a Threat 2 contract on their first attempt. The network is now enriched with intrusion memory. Two weeks later, they attempt the same Threat 2 contract again (same seed, because they remember it felt easy).

But the network has learned. ICE is placed more aggressively. Encryption is deeper. Nodes that were once leaf nodes are now bottlenecks. The Operator is now facing a harder version of the same contract, without realizing why.

They fail. But the failure teaches them: networks have memory. Easier contracts become harder on repeat. The Operator stops repeating seeds and seeks new contracts. Cartridge learns player.

23.3 The Sound-Tempo Collision

An Operator learns to identify HUNTER’s audio signature (all three voices spiking simultaneously). They are on a Threat 3 contract, moving through nodes quickly, playing by ear with the screen off (a learned technique).

They hear Voice 1 accelerate. They hear Voice 3 go chaotic. But they don’t hear the all-three-voice spike that signals HUNTER. They misjudge: is it a RED spawn, or an approaching HUNTER?

They decide it’s RED. They continue forward. It was HUNTER. HUNTER cycles faster than the Operator’s decision-making. The Operator hears the spike too late. HUNTER is already two nodes away, closing in.

This is a death moment. It emerges from the Operator’s learned techniques colliding with a false-positive in their Orient phase. They learn: audio signatures are reliable, but pattern mismatches are fatal.

23.4 The Surprise-Combo Discovery Collision

An Operator has learned through repeated use that CRACK + MIRROR = QUICKCOPY, and SPIKE + CLOAK = PHANTOM. They haven’t discovered SHADOW (MIRROR + CLOAK = become invisible while copying).

They encounter a high-security node with a high-value payload. They want to copy without trace. They have MIRROR and CLOAK available, but they’ve never CONS’d them together. They decide to try MIRROR + CLOAK on a whim.

The arpeggio that plays is unusual — 8 notes with dissonance. Surprise combo. SHADOW emerges. The Operator successfully exfiltrates the entire node’s data without a trace spike.

The Operator has accidentally discovered a surprising interaction. This discovery is meaningful because it came from their decision-making, not from a hint. They now own SHADOW in their personal toolkit library.

23.5 The Linked-Play Collision

Sysop Mode: Two Operators. One is the intruder (running ICE BREAKER), one is the defender (controlling the threat escalation via sysop interface on a second KN-86).

The intruder cycles OODA every 1 second. The sysop cycles their control loop (detect threat, decide escalation, spawn ICE, adjust trace) at a variable rate. The sysop is human. Humans are unpredictable.

An expert intruder predicts the sysop’s escalation patterns and exploits them (the sysop always spawns BLACK at node 5, so the intruder doesn’t even go to node 5 on second contracts). A novice sysop is chaotic — ICE spawns randomly, the intruder can’t predict and must retreat.

This is high-level emergence: human decision-making (sysop) colliding with AI decision-making (network, ICE) and the human intruder’s learned strategies. No two linked-play sessions are identical because the sysop’s decisions are unrepeatable.

PART FIVE — OPERATING PROCEDURES

24. POWERING ON

Press the power switch on the right edge of the Deckline. The device boots over approximately 5 seconds:

Hardware initialization (~2 s): The nOS.h runtime initializes the Pi Zero 2 W primary processor, the Pico 2 coprocessor (PSG and OLED driver), the Elecrow 7” display, the CIPHER-LINE OLED (on SPI0), the audio subsystem (YM2149 emulation + MAX98357A), and the input system (34-key Ferris Sweep split matrix).
System image load (~2 s): The device loads the Debian-based Raspberry Pi OS system image from the onboard microSD card. nOS.h initializes the kiosk mode (auto-login, read-only root), device tree overlays (SSD1322 OLED on SPI0), and systemd units for the nOSh runtime.
Cartridge detection (~1 s): nOS.h checks the cartridge-detect pin on the SD-card-sled interface. If a cartridge is present, the slot detection fires.
Cartridge load and publisher splash: If ICE BREAKER is present, nOS.h loads the cartridge image, validates the header, sets the capability bit in Universal Deck State, allocates per-cartridge Fe and grammar arenas, invokes the publisher splash (Zaibatsu Digital logo, 3 seconds maximum), and then advances to the mission board.

If no cartridge is present, the Bare Deck Terminal loads (a fully operational interface for managing the Deck State, reviewing provenance chains, and conducting linked-play handshakes).

Total boot time: 4–6 seconds from power-on to mission board.

25. THE MISSION BOARD

The mission board is generated by nOS.h at boot time from ICE BREAKER’s mission templates. The generator is seeded by threat level availability, the Operator’s reputation, cartridge history, and the current deck state.

Each contract displays:

Threat level (1–5): numeric indicator of difficulty and danger.
Payout (¤): base credit reward. Threat 1 ≈ 40 ¤, Threat 5 ≈ 250 ¤.
Target system: procedurally named (e.g., “Kessler R&D Node,” “Sakura Finance Hub”).
Contract class: PENETRATION (breach and verify access), EXTRACTION (steal data), SABOTAGE (destroy or corrupt), SURVEILLANCE IMPLANT (plant persistent monitoring).

The Operator navigates the mission board:

[CAR] to examine the currently selected contract (displays detailed briefing).
[CDR] to cycle to the next contract in the list.
[EVAL] to accept the selected contract and begin the run.
[NIL] to dismiss the board (returns to Bare Deck Terminal if no mission is active).

Three to five contracts are typically available per boot. The contract list refreshes after every run.

┌─────────────────────────────────────────────────────────────────────────────┐
│ NOTE                                                                         │
│ The mission board generator respects reputation gates. An Operator with      │
│ Reputation < 5 cannot see Threat 4–5 contracts, even if their credit        │
│ balance is sufficient. The gates unlock at: Rep 5 (Threat 2), Rep 10        │
│ (Threat 3), Rep 15 (Threat 4), Rep 20 (Threat 5). This prevents             │
│ impossibly difficult early encounters.                                       │
└─────────────────────────────────────────────────────────────────────────────┘

26. CONTRACT BRIEFING AND ENTRY

When the Operator presses [CAR] on the mission board, the contract briefing screen displays:

PENETRATION — SECURITY TEST
Threat: 2   Payout: 110¤   Risk: MODERATE

OBJECTIVE:
  Breach the test network, demonstrate security gaps,
  and return with proof of access. Do not destroy
  any systems.

ENTRY POINT:
  Public security relay (Node 0). Low ICE presence.
  Expected traversal depth: 4–6 nodes.

THREAT PROFILE:
  Primarily JUNK-class and BLACK-class ICE.
  RED spawn unlikely at Threat 2.

ESTIMATED RISK:
  Trace accumulation will accelerate around turn 8.
  Egress window: turns 12–15 (optimal).

ECOLOGICAL NOTE:
  This network has intrusion history. ICE behavior is
  learned and adaptive.

[EVAL to accept] [CDR to view next contract]

The Operator presses [EVAL] to accept. nOS.h invokes ICE BREAKER’s phase generator:

The phase generator seeds the procedural network with threat level, reputation, and deck entropy.
The network is generated: 8–16 nodes, ICE populations, encryption depths, data payloads.
The root node (Node 0) is initialized with low ICE (usually 1 JUNK instance).
Universal Deck State’s phase_chain[] is populated with the new mission context (threat level, contract class, objective, node graph, ICE positions).
CIPHER renders a brief narration on CIPHER-LINE Rows 2–3 (intent of the mission).
The Operator is placed at the root node. The network map displays.
The run begins.

The briefing and entry sequence completes in approximately 2–3 seconds.

27. THE NETWORK MAP

The primary display (Rows 0–24) shows the network visualization:

Row 0 (firmware status bar): Operator handle, credit balance, reputation tier (APPRENTICE / JOURNEYMAN / SPECIALIST / MASTER / LEGEND), current cartridge name (ICE BREAKER), signal strength (device status), game timer (elapsed time in mission).

Rows 1–23 (cartridge content area): The network visualization occupies the full 80 × 23 content area. It consists of:

Procedural network graph: A directed acyclic graph rendered as a flow-field visualization. Nodes appear as amber boxes. Connections appear as amber lines. The current node is highlighted (inverted video). Adjacent nodes (child connections) are labeled numerically (1–9) for numpad selection.
Node state indicators (per node): ICE class glyph (JUNK = ⊕, BLACK = ●, RED = ★, HUNTER = ⚡), encryption depth (1–4 stars), data payload indicator (● = data present).
Clip-driven animation: The network view displays a flowing animation (low-frame-rate, ~3–5 fps) generated by one of ICE BREAKER’s embedded clips (.kn86clip files). The clip theme changes based on threat level (calm at low trace, alert at trace=30, hunt mode at trace=50, lockdown at trace=75).
Information overlay: When [INFO] is pressed, a telemetry panel slides in (Rows 15–23), showing raw data for the current node (encryption depth, ICE population, adjacent node names, estimated traversal time, trace accumulation rate at this node).

Row 24 (firmware action bar): Key hints contextual to the network map mode:

[CAR]:ENTER  [CDR]:BACK  [INFO]:SCAN  [CONS]:COMBO  [LINK]:EXIT  [TERM]:REPL

The right edge of Row 24 always displays the REPL indicator ([TERM:REPL] if the REPL is available).

28. NODE INTERACTION

When the Operator presses [CAR] and selects a child node via numpad, they descend into that node. The network view is replaced with a node detail view:

[NODE 5 — SECURITY RELAY]
ICE CLASS: BLACK (ADAPTIVE)
ENCRYPTION DEPTH: 2
DATA PAYLOAD: 45 credits

ICE POPULATION: 1 BLACK instance (active)
TRACE ACCUMULATION: +2 per turn (at this node)
CONNECTIONS: 2 (Return to parent, Node 8)

[CAR]:TRAVERSE  [CDR]:RETREAT  [INFO]:SCAN  [CONS]:COMBO
[EVAL]:COMMIT TOOL  [LAMBDA]:SPECULATE  [LINK]:EGRESS

The Operator must decide:

Use a tool ([CONS], then [EVAL]): Press CONS to open the tool combination matrix. Select two available tools. Press EVAL to apply the combo. The tool is consumed. If successful, the encryption is cracked. Trace increases. The Operator may remain at this node or traverse deeper.
Traverse deeper ([CAR]): If the encryption is cracked (or low-threat ICE is bypassed), the Operator can descend to a child node.
Retreat ([CDR]): Always safe to press. Returns to parent node. ICE may pursue, but no immediate penalty.
Egress ([LINK]): Attempt extraction from this node. Only succeeds from designated egress nodes (usually the root). Failure means the Operator is detected and trace increases.

[INFO] single press: Displays raw telemetry (ICE class, encryption depth, tool requirements, trace accumulation rate).

[INFO] double-tap: Triggers CIPHER’s orient assist. Cipher voice (rendered on CIPHER-LINE Rows 2–3) interprets the situation. Example: “BLACK-class. Adaptive. Brute-force is loud. Silent tools are slow.”

29. TOOL COMBINATION (CONS)

The Operator presses [CONS] on any screen to open the tool combination matrix. The matrix displays as a 6×6 grid:

        CRACK  MIRROR  SPIKE  CLOAK  SIPHON  GHOST
CRACK     —    QUICK†  RAVAGE PHANTOM UNKNOWN REWRITE*
MIRROR  QUICK†   —      —      SHADOW† ECHO   UNKNOWN
SPIKE   RAVAGE   —      —      PHANTOM GRIND  UNKNOWN
CLOAK   PHANTOM SHADOW† PHANTOM  —    UNKNOWN FADE
SIPHON  UNKNOWN  ECHO   GRIND  UNKNOWN  —     LAUNDER*
GHOST   REWRITE* UNKNOWN UNKNOWN FADE   LAUNDER*  —

† = intuitive combo   * = surprise combo

The Operator selects two tools via numpad:

Directional navigation (numpad 2/4/6/8 for down/left/right/up) to move the selector around the matrix.
Numpad 5 (or numpad repeat) to select the currently highlighted combo.

When a combo is selected:

Sound cue: A descending arpeggio plays. Complexity (4–8 notes, with or without dissonance) signals rarity. Basic combos = 4 notes. Surprise combos = 8 notes with dissonance.
Visual confirmation: The combo result appears on the right side of the matrix. The effect, trace cost, and tool durability (if applicable) are displayed.
Consumption: Both selected tools are permanently consumed. The Operator cannot undo. Once CONS is pressed and EVAL is pressed, the decision is final.
Application: The new combo tool is now active and can be applied immediately (press [EVAL] at the current node to use it) or saved for later.

┌─────────────────────────────────────────────────────────────────────────────┐
│ NOTE                                                                         │
│ Surprise combos (REWRITE, SHADOW, LAUNDER, and others) are not labeled in  │
│ the matrix. The grid cell displays "UNKNOWN" until the Operator has         │
│ discovered the combo by use. Once discovered, the combo name persists in    │
│ the Operator's Universal Deck State and is labeled in future runs.          │
└─────────────────────────────────────────────────────────────────────────────┘

30. TRACE MANAGEMENT

Trace is the “heat level” — a 0–100 score indicating how much attention the network’s defenses are paying. It accumulates on every action and decays slowly over time.

30.1 Trace Accumulation

Each keypress: +1 trace.
Each tool use: +2–10 trace (tool-dependent).
- CRACK: +8 trace (noisy, high-damage).
- MIRROR: +2 trace (quiet, stealthy).
- SPIKE: +5 trace (disruptive, moderate risk).
- CLOAK: +1 trace (masks identity, very quiet).
- SIPHON: +6 trace (extraction draws attention).
- GHOST: +0 trace (erasing is silent).
Triggering ICE (being caught): +5–20 trace (ICE-class-dependent).

30.2 Trace Decay and Decay Speed

Trace decays slowly over time: 1 point per 15 seconds of real time (approximately 1 point per 10 turns of game time) when the Operator is not taking actions.

Decay accelerates during lockdown (trace > 75): 2 points per 15 seconds (the network is burning resources to contain the intrusion and wants the Operator gone).

CLOAK tool (if applied at trace 30–50) instantly drops trace by 5 points and suppresses further accumulation for 3–4 turns.

GHOST tool (if applied) instantly drops trace by 10 points (retroactively erases intrusion history).

30.3 Trace Thresholds and Consequences

Trace = 30: Perimeter Alert

The network’s defenses register the Operator’s presence. CIPHER voice warns: “gap. perimeter alert / 3 turns.” (rendered on CIPHER-LINE Rows 2–3).

Voice C (environmental chaos) fades in with a warning pulse (rhythmic, accelerating).

The Operator has 3–4 turns to egress or drop trace via CLOAK or other stealth measures. This is a caution state, not a danger state. Threat has not escalated to lethal.

Trace = 50: HUNTER Spawn

A third adversarial system activates. HUNTER is spawned at a random node in the network and begins chasing the Operator. HUNTER’s cycle accelerates each turn (0.5s → 0.4s → 0.3s).

Voice 1 (ICE proximity alarm) spikes to maximum pitch (all three voices spike simultaneously, then Voice 1 locks into a rising pitch — urgent, accelerating).

At trace=50, the tempo inverts. The Operator can no longer sustain a slow, deliberate pace. They must cycle faster or die.

Trace = 75: Network Lockdown

The network hardens. Exit nodes seal. The Operator cannot egress via [LINK]. Instead, they must fight through ICE to escape (take damage, lose credits, or remain trapped).

Trace decays at double speed during lockdown (the network is burning resources to contain the intrusion and wants the Operator gone).

CIPHER voice intones: “lockdown. escape. impossible. / system sealed.” (rendered on CIPHER-LINE).

Voice 1 locks into a high-pitched shriek. Voice 3 dominates the mix (environmental chaos at maximum).

Recovery from lockdown is possible via:

Using GHOST to drop trace by 10 points (brings trace from 75 to 65, below the lockdown threshold).
Reaching the root node and pressing [LINK] despite the sealed exit (high risk, may fail).
Allowing trace to decay naturally to 75 or below (requires ~2–3 minutes of gameplay at doubled decay rate, during which HUNTER is still active).

┌─────────────────────────────────────────────────────────────────────────────┐
│ CAUTION                                                                      │
│ Network lockdown (trace = 75) is recoverable but dangerous. An Operator at  │
│ lockdown without GHOST or a clear exit route has limited options.           │
└─────────────────────────────────────────────────────────────────────────────┘

31. EGRESS AND DEBRIEF

The Operator attempts egress by pressing [LINK] from any node (though only designated egress nodes have a clear exit).

31.1 Egress Attempt

If the Operator is at the root node (Node 0) and presses [LINK]:

nOS.h attempts to route the Operator back to the entry point and out of the network.
If no ICE is blocking the exit node, the routing succeeds. Voice 1 plays a resolving major chord (victory). Trace immediately drops to 0. The mission ends. The debrief screen loads.
If ICE is blocking the exit node, the routing fails. Voice 1 plays a discordant crash (failure). Trace increases by 5. The Operator remains in the network. The run continues.

If the Operator is at a non-egress node and presses [LINK]:

nOS.h attempts to route from the current node back to the root node and out.
The routing may succeed (if the path is clear) or fail (if ICE blocks intermediate nodes).
Success and failure follow the same audio cues and state updates.

31.2 Debrief Screen

On successful egress, the debrief screen displays:

EXTRACTION SUCCESSFUL

OBJECTIVE: PENETRATION VERIFIED
Status: ✓ Completed

PAYOUT CALCULATION:
  Base payout (Threat 2):           110 ¤
  Speed bonus (< 12 turns):         +30 ¤
  Stealth bonus (trace ≤ 35):       +20 ¤
  Objective bonus (penetration):    +10 ¤
  ─────────────────────────────────
  TOTAL PAYOUT:                     170 ¤

REPUTATION DELTA:                   +2 (for Threat 2 solo)

DECK STATE UPDATES:
  Credit balance: +170 ¤
  Reputation:     +2
  Cartridge history: [0x01] ICE BREAKER marked LOADED
  Completed missions: +1
  Cartridge history bit: [0x01] updated to THREAT_2_COMPLETED

CIPHER VOICE (on CIPHER-LINE):
"extraction. clean. / silent. good."

The Operator presses [EVAL] or [NIL] to dismiss the debrief and return to the mission board.

31.3 Failed Extraction

If the Operator runs out of resources, gets trapped, or abandons the run by pressing [NIL] on the mission board, a failure debrief displays:

MISSION FAILED

LAST STATE:
  Trace level: 72 (near lockdown)
  Tools remaining: SIPHON only
  Network depth: Node 9 of 14

PAYOUT CALCULATION:
  Partial credit for depth reached:  +20 ¤
  No bonus applied
  ─────────────────────────────────
  TOTAL PAYOUT:                     20 ¤

REPUTATION DELTA:                   -1 (for failed Threat 3)

The network remembers this intrusion. Reinforcements are being deployed.

Failed runs do not update the cartridge history bit, but they do increment an internal counter and enrich the network’s defensive posture for future runs on the same contract seed. A failed run is not wasted — it is a gift of information.

32. HOT SWAP PROCEDURE

32.1 Recognition and Acknowledgment

During active play, CIPHER voice announces capability gaps in advance. On turn N-3 (3–4 turns before the gap becomes critical), Cipher intones: “gap. network deeper. / not this one.” (rendered on CIPHER-LINE Rows 2–3).

The Operator recognizes this as a signal to acquire a missing capability. At the next DECIDE phase, the Operator can choose to Hot Swap.

32.2 Initiating the Swap

The Operator presses [QUOTE] (the “suppress evaluation” key, repurposed for Hot Swap in active-mission context). nOS.h recognizes the Hot Swap request:

CIPHER voice: “swap. initiated. / remove. now.” (rendered on CIPHER-LINE).
The screen fades to black.
The YM2149 stops playing (silence).
The Deckline is now inactive, but the phase chain is preserved in SRAM.

32.3 Physical Cartridge Exchange

The Operator has 5–10 seconds (real time) to:

Locate the cartridge slot (bottom edge of the Deckline, label-up orientation).
Press the spring-loaded ejector button to release the current cartridge.
Smoothly withdraw the current cartridge.
Locate the target cartridge.
Align it (label-up, card edge first) and insert it into the slot until the ejector spring catches.

The slot detection pin fires when the new cartridge is fully seated. nOS.h detects the cartridge change and begins reboot.

┌─────────────────────────────────────────────────────────────────────────────┐
│ WARNING                                                                      │
│ Do not pull the cartridge without pressing [QUOTE] first. If the cartridge  │
│ is removed while the device is in an active mission state, the phase chain  │
│ may not be properly serialized. Risk: loss of run state, corrupted Deck     │
│ State, or device instability. ALWAYS acknowledge the Hot Swap prompt        │
│ before physically removing the cartridge.                                    │
└─────────────────────────────────────────────────────────────────────────────┘

32.4 Reboot and Scoped Capability Mode

The new cartridge is detected. nOS.h:

Reads and validates the cartridge header.
Loads the cartridge image into the per-cartridge Fe arena.
Restores the phase chain from SRAM (mission state is preserved).
Initializes the cartridge in scoped capability mode.

Scoped capability mode limits the swapped cartridge to its signature capability only (sonar for Depthcharge, ledger for Black Ledger, map for Neongrid). The cartridge’s other features (narrative, full contract types, progression) are not available. This prevents the Operator from becoming lost in a different cartridge’s world.

The screen returns to the network view. CIPHER voice: “loaded. scope. / 10 seconds.” (rendered on CIPHER-LINE).

A countdown appears on CIPHER-LINE Row 4: “SCOPED MODE: 9… 8… 7…” The swapped cartridge’s tools are available at 50% power (50% lower trace cost, reduced effectiveness).

32.5 Network Advance During Swap

During the physical swap (real time), the network advances at half-tempo:

ICE does not spawn.
Threats do not escalate.
Trace accumulation pauses.
Node traversal costs are reduced (moves cost 0.5× normal).

This grace period lasts until the countdown reaches zero (~10 seconds of game time), giving the Operator a safety window.

After the countdown ends (“SCOPED MODE: 0… RESUMING TEMPO”), the network resumes at full tempo and normal costs.

32.6 Swapping Back

The Operator can:

Continue forward with the swapped cartridge (the scoped capability becomes available as a permanent part of the run, as long as that cartridge stays loaded).
Swap back to the previous cartridge (press [QUOTE] again) to restore the original capability set.
Swap to a third cartridge (if available in cartridge history).

Each swap costs time and risks trace accumulation if the countdown expires mid-swap. Multiple swaps (3+ per run) are possible but increasingly risky as trace climbs.

32.7 Example Scenarios

Scenario A: Depthcharge Sonar Analysis Swap

The Operator is 6 nodes deep in a Threat 3 PENETRATION contract. The current node is an encrypted underwater relay (signature ICE: deep encryption, depth=3). The Operator’s ICE BREAKER toolkit cannot crack depth 3 efficiently.

Cipher warns: “gap. network deeper. / not this one.”

The Operator decides to swap to Depthcharge. They press [QUOTE], physically swap the cartridges, and Depthcharge boots in scoped mode.

The Operator uses sonar (press [INFO] + [EVAL]) to analyze the relay. The sonar reveals the ICE’s class and encryption signature. The Operator now understands the threat.

The Operator can either:

Continue with Depthcharge sonar (if they want to explore further).
Swap back to ICE BREAKER and attempt the deep encryption with knowledge of its signature.

Time cost: ~15 seconds real time, ~30 seconds game time (due to half-tempo network advance during swap). Trace impact: minimal, due to grace period.

Scenario B: Black Ledger Financial Redirect Swap

The Operator is on a Threat 4 SABOTAGE contract. The objective is to infiltrate a finance node and corrupt transaction records. The Operator is equipped with SPIKE, CLOAK, and SIPHON (ICE BREAKER tools).

At the finance node, the Operator realizes the records are encrypted with legal tender codes — they require knowledge of real-time currency exchange rates and audit trails. ICE BREAKER doesn’t do that.

The Operator swaps to Black Ledger. The cartridge provides a ledger interface showing financial flows. The Operator can now see which transactions to corrupt and the optimal sabotage method (which ones cascade into account freezes, which ones trigger investigation).

The Operator executes the sabotage with Black Ledger’s insight. Then they swap back to ICE BREAKER to escape the building before the audit system locks down.

Trace impact: Moderate. The financial analysis took time, and trace accumulated while the Operator was in the ledger interface.

Scenario C: Neongrid Map Swap

The Operator is navigating a 9-node Threat 3 contract. The network topology is maze-like. The Operator keeps hitting dead-ends (nodes with only the parent as an exit).

Neongrid (spatial exploration cartridge) provides a map visualization. The Operator swaps, Neongrid scope mode activates, and the cartridge renders a bird’s-eye view of the known network topology. The Operator sees an optimal path to the objective.

The Operator swaps back to ICE BREAKER and executes the optimized path. This is Hot Swap as a tool for exploration, not capability gap-filling. Fewer moves = less trace = safer extraction.

33. LINKED PLAY — SYSOP MODE

33.1 Physical Setup

Linked play requires:

Two KN-86 Deckline units (hardware version) or two emulator instances (emulator version with OSC networking over localhost).
One 3.5 mm TRRS audio cable: Carries both the audio mix (intruder’s YM2149 feed, sysop control signals via multiplexing, and shared Voice 3) and control signals (phase chain synchronization, threat escalation commands).
Two Operators: One plays the Intruder (ICE BREAKER player, standard mission run). One plays the Sysop (defensive player, controlling threat escalation and ICE placement).

The cable is inserted into the audio jack on the right edge of each Deckline. nOS.h detects the linked-play handshake and both units switch to a synchronized mode.

33.2 The Sysop Role

The Sysop sees a different screen than the Intruder:

[SYSOP INTERFACE]
NETWORK STATUS: NORMAL
INTRUDER POSITION: NODE 5 (TRACE=18)
HUNTER STATUS: DORMANT

THREAT CONTROLS:
  [SYS] → Issue network-wide alert (±10 trace)
  [BACK] → Spawn ICE at target node (uses 5 action points)
  [LINK] → Accelerate trace accumulation (×1.5 for 3 turns)
  [CAR] → Route ICE to intercept (uses 3 action points)
  [CDR] → De-alert ICE (reduces local threat)

ACTION POINTS: 8 / 10 (regenerates at 1 pt / 30 sec)

VOICE CHANNELS:
  Voice 1 (ICE alarm) — Sysop control
  Voice 2 (Data flow) — Intruder control
  Voice 3 (Chaos) — Shared (escalates with threat)

The Sysop is a human defender. They can:

Manually spawn ICE at specific nodes (uses action points, a limited resource that regenerates).
Accelerate trace accumulation (pressing [LINK] causes trace to rise at 1.5× rate for 3 turns).
Route ICE to intercept the Intruder’s likely escape path (uses action points, requires prediction).
Adjust the YM2149 Voice 1 (making ICE alarms louder or quieter, signaling threat level to the Intruder).
Issue network-wide alerts (±10 trace, high impact but high cost).

The Intruder does not know which choices the Sysop will make. The Sysop’s decisions are unpredictable (because the Sysop is human). This asymmetry creates high-tension play.

33.3 Linked Play Dynamics

Expert Intruder vs. Novice Sysop: The Intruder predicts the Sysop’s spawning patterns and exploits them. They move through gaps in the Sysop’s ICE placement. The Intruder’s experience advantage dominates.

Novice Intruder vs. Expert Sysop: The Sysop predicts the Intruder’s likely routes and pre-positions ICE. The Sysop’s experience advantage dominates.

Matched Pair: The game is back-and-forth. The Intruder cycles OODA at 2 Hz. The Sysop cycles their defensive loop at 0.5 Hz (human reaction time). The Intruder has tempo advantage, but the Sysop can make strategic decisions the Intruder can’t react to in time.

Balanced linked play emerges from both players being willing to calibrate their skill level. An expert Intruder paired with a novice Sysop should accept lower-threat contracts or use more tools than they strictly need. A novice Intruder paired with an expert Sysop should accept lower-threat contracts or invite hints from the Sysop during play.

33.4 Economics and Partnership Dynamics

Both Operators benefit from successful extraction:

Intruder: Payout from contract completion + speed bonus. Threat 3 extraction = 110–170 ¤.
Sysop: Security fee (20–30% of contract payout, baseline) + defense bonus (if extraction is blocked, sysop gets a flat defensive payout, e.g., 50 ¤).

If the Intruder succeeds, both Operators profit (Intruder gets the larger cut, Sysop gets the security fee). If the Intruder fails, the Sysop gets the defensive payout (smaller, but guaranteed).

This creates a negotiation dynamic. A novice Intruder might say, “I’ll take easy contracts so you get your security fee without stress.” An expert Intruder might say, “I’m taking Threat 4. You get 30% of my payout if I escape.” The partnership adjusts difficulty to find a sustainable dynamic.

Reputation is shared across both players. Both gain reputation on Intruder success and both lose reputation on failure.

33.5 Practice and Community Etiquette

Linked play is most enjoyable when both players are calibrated. The community practices:

Offer handicaps: An expert Sysop might play with reduced action points. An expert Intruder might accept higher threat levels than their reputation permits.
Communicate preferences: Before starting, agree on difficulty, payout split, and whether hints are allowed.
No sabotage outside the rules: The Sysop should not deliberately corrupt the Intruder’s run outside the Sysop Mode interface. The Intruder should not cheat by reading the Sysop’s screen.
Debrief together: After each run, both players review what happened. The expert player can mentor the novice on tempo, ICE prediction, or defense strategy.

33.1 An Example Run — Operator CIPHER, Threat 3 EXTRACTION

Contract: EXTRACTION, Threat 3, Corporate R&D Facility Network

Payout: 250 credits base (280–350 with bonuses)

Cartridges available: ICE BREAKER, Depthcharge (loaded)

Operator reputation: 18 (Specialist tier)

Minute 0:00 — Boot and Selection

CIPHER enters their handle. The mission board loads. Three Threat 3 contracts are available. CIPHER selects EXTRACTION (they want data, not destruction).

CONTRACT BRIEFING:
  Objective: Extract prototype designs from R&D Node
  Entry point: Node 0 (Root Relay)
  Threat: Medium speed, adaptive ICE
  Payout: 250 base + speed bonus
  Recommended: 12–15 node traversal
  Estimated risk: MODERATE (trace 50 acceptable, 75+ dangerous)

CIPHER presses [INFO] for telemetry. The briefing shows entry coordinates, recommended toolkit balance, estimated ICE distribution. Voice 1 plays a soft drone (threat is present but not acute).

CIPHER presses [INFO] again. Cipher voice (on CIPHER-LINE): “threat. moderate. / prepare. steady.”

CIPHER decides to load ICE BREAKER as the primary cartridge. The nOSh runtime loads the capability module. The phase chain initializes.

CIPHER presses [EVAL] to begin.

Minute 0:30 — Network Entry

[NODE 0 — ROOT RELAY]
ICE CLASS: JUNK
POPULATION: 1 JUNK instance
CONNECTIONS: 3 nodes (A, B, C)

TOOLKIT LOADED:
  Slot 1) CRACK
  Slot 2) MIRROR
  Slot 3) SIPHON
  Slot 4) (empty)

TRACE: 0

CIPHER presses [INFO]. The screen shows adjacent nodes: A (FINANCE), B (SECURITY), C (RESEARCH ARCHIVE).

CIPHER double-taps [INFO]. Cipher voice: “Node C. archive. research. / shallow guard.”

CIPHER interprets: Node C is directly toward the objective, but it’s guarded. Nodes A and B are secondary routes.

CIPHER decides to move to Node B (security checkpoint). A Specialist learns to move through checkpoints carefully.

CIPHER presses [CAR], selects Node B via numpad.

Minute 1:00 — NODE 1 (SECURITY CHECKPOINT)

[NODE B — SECURITY CHECKPOINT]
ICE CLASS: BLACK
POPULATION: 1 BLACK instance
CONNECTIONS: 2 nodes (Root, Node D)

TRACE: 5

CIPHER presses [INFO]. Raw data: Black ICE, encryption depth 2, trace accumulation 2 per turn.

CIPHER double-taps [INFO]. Cipher voice: “black. adaptive. brute. loud.”

CIPHER thinks: MIRROR + CRACK = QUICKCOPY. A balance of speed and stealth.

CIPHER presses [CONS], selects CRACK and MIRROR. An arpeggio plays (8 notes, medium complexity). QUICKCOPY manifests.

CIPHER presses [EVAL] to apply QUICKCOPY. Voice 2 accelerates (data flow). The BLACK ICE is bypassed. Trace increases to 12.

Minute 1:30 — NODE 2 (RESEARCH DISTRIBUTION HUB)

[NODE D — RESEARCH DISTRIBUTION HUB]
ICE CLASS: JUNK
POPULATION: 2 JUNK instances (inventory, not hostile)
CONNECTIONS: 3 nodes (Return, Node E, Node F)

TRACE: 12

CIPHER observes: Node E is marked as “ARCHIVE.” Node F is marked as “DEVELOPMENT.”

CIPHER interprets: The objective (recent prototype designs) is probably at Node F (deeper, more active).

CIPHER moves to Node F.

Minute 2:00 — NODE 3 (DEVELOPMENT LAB)

[NODE F — DEVELOPMENT LAB]
ICE CLASS: RED
POPULATION: 1 RED instance (active, hostile)
CONNECTIONS: 2 nodes (Return, Node G — Deeper)

TRACE: 15

CIPHER observes: RED-class means if defeated, it spawns JUNK elsewhere. Node F leads only to Node G (a deeper gamble).

CIPHER double-taps [INFO]. Cipher voice: “red. aggressive. defeat. spreads.”

CIPHER realizes: They have one tool remaining (SIPHON). If they use SIPHON here, they lose their last tool slot. They can’t CONS again. But SIPHON won’t help against RED ICE.

CIPHER decides to retreat to Node E (Archive), not Node G. A Specialist knows when deeper is not better.

CIPHER presses [CDR], then [CAR] to enter Node E.

Minute 2:30 — NODE 4 (RESEARCH ARCHIVE)

[NODE E — RESEARCH ARCHIVE]
ICE CLASS: BLACK
POPULATION: 1 BLACK instance (protective, not aggressive)
CONNECTIONS: 2 nodes (Return, Node H — Deeper)

TRACE: 18

CIPHER observes: BLACK-class here is protective, not aggressive. Encryption depth is 1 (light). Trace accumulation is 1 per turn (slow).

The toolbar shows: 1 SIPHON remaining. No CONS options (need 2 tools to CONS).

CIPHER double-taps [INFO]. Cipher voice: “archive. old. deeper. research.”

CIPHER thinks: “I’m at Trace=18. I have about 30 turns before trace becomes dangerous (50). If I Hot Swap now, I can use Depthcharge to analyze the deeper encryption (Node H and beyond) and get sonar signatures.”

CIPHER decides to Hot Swap.

CIPHER presses [QUOTE].

Minute 3:00 — HOT SWAP MOMENT

Cipher voice: “swap. initiated. / remove. now.”

The screen goes black. The YM2149 stops. CIPHER is holding the Deckline, but the device is inactive.

CIPHER physically pulls ICE BREAKER and inserts Depthcharge. The cartridge boots. Voice 1 plays a reboot tone.

The screen returns to the network view.

[NODE E — RESEARCH ARCHIVE] [SCOPED CAPABILITY MODE]
ICE CLASS: BLACK

DEPTHCHARGE SONAR ACTIVE

Sonar can analyze:
  • ICE class and subtype
  • Node encryption depth
  • Node age (intrusion history)
  • Signal propagation (distance to adjacent nodes)

Current scan: Node H (adjacent)
  Encryption depth: 3 (DEEP)
  ICE class: BLACK variant (Pattern-adaptive)
  Node age: 0 intrusions (Fresh ICE)
  Propagation: Medium (normal traversal time)

CIPHER now has sonar intel. The OBSERVE phase is enhanced: Cipher voice: “node. deep. adaptive. / risk. moderate.”

CIPHER is now a Specialist with sonar. They can make an informed decision.

CIPHER thinks: “Node H is deep encryption (depth 3). I can continue deeper with Depthcharge sonar and map more nodes, or swap back to ICE BREAKER and attempt a different route.”

CIPHER decides to continue deeper with Depthcharge sonar.

CIPHER presses [CAR], selects Node H.

Minute 3:45 — NODE 5 (ADVANCED RESEARCH VAULT)

[NODE H — ADVANCED RESEARCH VAULT] [SCOPED CAPABILITY MODE]
ICE CLASS: RED (Pattern-adaptive variant)
POPULATION: 1 RED instance (dangerous)

DEPTHCHARGE SONAR SCAN:
  Encryption depth: 4 (CRITICAL)
  ICE class: RED-adaptive
  Node age: 0 intrusions (Fresh, highly alert)
  Signal propagation: High (slow traversal)
  Data payload signature: PROTOTYPE DESIGNS (match objectives) ✓

CIPHER’s Observe phase: The sonar shows Node H contains the objective. But encryption depth is 4 (critical), and RED-adaptive ICE guards it.

CIPHER thinks: “This is the objective node, but I don’t have the tools to crack depth 4. My SIPHON won’t help. I need to swap back to ICE BREAKER and attempt a CONS combo I haven’t tried yet, or use GHOST to retroactively clear traces.”

CIPHER realizes: Actually, this is the perfect moment for a surprise combo. SIPHON + CRACK = LAUNDER (extract credits through encrypted finance channels with no trace). The sonar analysis revealed the ICE signature. CIPHER can use that knowledge to inform the combo selection.

CIPHER decides: Swap back to ICE BREAKER, use LAUNDER combo to extract the prototype designs (treating them as encrypted financial data), and then attempt a clean egress.

CIPHER presses [QUOTE].

Minute 4:00 — SECOND HOT SWAP (Back to ICE BREAKER)

CIPHER physically swaps back to ICE BREAKER.

The screen returns to the network view.

[NODE H — ADVANCED RESEARCH VAULT] [SCOPED CAPABILITY MODE]
ICE CLASS: RED (Pattern-adaptive variant)

ICE BREAKER LOADED
TOOLKIT: SIPHON (only)

CIPHER-LINE: "back. loaded. / depth. known."

CIPHER now understands the threat. They have SIPHON and knowledge of the encryption depth (4).

CIPHER presses [CONS]. Only one tool (SIPHON) is available, so they can’t CONS. CIPHER cancels.

CIPHER thinks: “Wait. I made an error. I can’t CONS without two tools. I only have SIPHON. I need to find another approach.”

Actually: CIPHER realizes they should have held onto MIRROR and SIPHON instead of using QUICKCOPY on Node B. But they can’t undo that.

CIPHER decides: Use SIPHON on Node H (despite encryption depth 4). It will be noisy (high trace), but if it succeeds, the objective is extracted.

CIPHER presses [EVAL] to apply SIPHON.

[Voice B accelerates, a rising arpeggio plays]

SIPHON succeeds (barely). The prototype designs are extracted. The data payload transfers. Trace increases to 25.

The network now recognizes the Operator has the objective. Cipher voice: “objective. extracted. / egress. now.”

Minute 4:45 — EGRESS APPROACH

CIPHER has extracted the objective. Now they must egress.

CIPHER is at Node H (deep network). They must traverse back toward the root (Node 0) and press [LINK] to extract.

CIPHER navigates back: Node H → Node E → Node D → Node B → Node A… wait, where’s the root?

Actually, CIPHER presses [CDR] multiple times to navigate back up the tree.

Node H → Node E (CIPHER presses CDR). Node E → Node D (CIPHER presses CDR). Node D → (Node B or Root?) CIPHER presses [INFO] to see adjacencies.

The network map shows Node D has connections back to Root and to Node F.

CIPHER navigates: Node D → Root (Node 0).

At Root, CIPHER presses [LINK] to attempt egress.

The exit is clear (no ICE blocking). The routing succeeds. Voice 1 plays a resolving major chord (victory).

Trace drops to 0. The mission ends. The debrief screen loads.

EXTRACTION SUCCESSFUL

OBJECTIVE: PROTOTYPE DESIGNS
Status: ✓ Completed

PAYOUT CALCULATION:
  Base payout (Threat 3):           250 ¤
  Speed bonus (< 10 turns):         +40 ¤
  Stealth bonus (trace ≤ 35):       +30 ¤
  Objective bonus (extraction):     +20 ¤
  ─────────────────────────────────
  TOTAL PAYOUT:                     340 ¤

REPUTATION DELTA:                   +3 (for Threat 3 with Hot Swap)

CIPHER VOICE (on CIPHER-LINE):
"extraction. clean. / specialist. good."

CIPHER presses [EVAL] to dismiss the debrief and return to the mission board.

Session Summary

Total time: 4:45 (4 minutes 45 seconds, realtime).

CIPHER performed one Hot Swap (Depthcharge for sonar analysis) mid-mission, acquired knowledge of the objective node, swapped back to ICE BREAKER, executed extraction, and achieved a clean egress with no failed exits.

Trace never exceeded 35 (stealth bonus earned). Speed was excellent (< 10 turns). Reputation +3. Total payout: 340 ¤.

This is an example of a Specialist-tier run: deliberate, strategic Hot Swap usage, tool-efficient navigation, and clean extraction. The Specialist does not brute-force problems — they acquire knowledge and execute elegantly.

PART SIX — UNIVERSAL DECK STATE & CROSS-MODULE INTEGRATION

34. Fields ICE BREAKER Reads

handle — displayed in contract briefing
credit_balance — determines mission board availability (cost gates)
reputation — tiers affect CIPHER verbosity, threat availability, tool loadout caps
cartridge_history — determines which cross-module contracts appear
phase_chain — if active, resumes multi-phase context on cart reload

35. Fields ICE BREAKER Writes

credit_balance — increased by successful contracts
reputation — increased/decreased based on threat level and mission outcome
cartridge_history[0x01] — set permanently on first load (NETWORK INTRUSION capability bit)
completed-missions-count (reserved field) — incremented on mission success
highest-threat-conquered (reserved field) — updated if current threat exceeds prior max

36. Cross-Module Effects

Mission Composition Grammar (§37): ICE BREAKER declares that it contributes PENETRATE, OBTAIN, DESTROY, and OBSERVE verbs, with DIGITAL and NETWORK affinities. The mission board uses these to compose multi-phase contracts that span multiple cartridges.

Depthcharge improves OBSERVE — network mapping becomes available, reducing uncertainty. Black Ledger improves DECIDE — financial redirects bypass some ICE. Neongrid improves ORIENT — waypoints provide navigation hints. ICE BREAKER improves ACT — intrusion capability is prerequisite for any network-penetration phase.

When an Operator loads a second cartridge, the mission board begins generating cross-module contracts that require Hot Swap to multiple modules mid-mission.

37. Mission Composition Grammar

ICE BREAKER declares:

(mission-contributions
  :verbs (PENETRATE OBTAIN DESTROY OBSERVE)
  :affinities (DIGITAL NETWORK)
  :payout-bias 1.0        ; baseline (no multiplier)
  :threat-bias 0)         ; symmetric threat availability

This tells the nOSh mission board: “I provide intrusion capability. I work well with reconnaissance (Depthcharge), financial systems (Black Ledger), and navigation (Neongrid). My economic baseline is 1.0×; I don’t bias threat toward high or low.”

38. Cartridge Provenance

Every cartridge maintains an append-only hash chain recording:

Deck and timestamp of first load.
Operator handle.
Threat levels and mission classes attempted.
Outcomes (success / failure / abandonment).

This is browsable in the Bare Deck Terminal under the LINK tab. It’s a historical record of the Operator’s relationship with the cartridge.

PART SEVEN — DEVELOPMENT SPECIFICATIONS

[These sections are the core authoring reference. I’ll provide brief summaries; the full details match Rev. B structure but updated to Lisp.]

39. Cartridge File Format (.kn86 v2.0)

See §8.2 above and Para 39 of the existing Rev. B for complete structure. Key changes from v1.1:

Code section: Lisp source, tree-walked on load — no bytecode (per ADR-0001, ADR-0004 2026-06-14 amendments).
Templates section: Mission templates as Lisp defmission forms (see §42).
CIPHER grammar section: Cartridge’s cipher-grammar block (see §44).
Cart-capabilities subsection: Requests for runtime-gated capabilities (e.g., Null’s cipher-main-grid-escape). Unauthorized declarations are rejected at cart-load (ADR-0006 amendment).

40. Cell Architecture

Cells are the building blocks of ICE BREAKER. Each cell has:

Type (network-node, ice, contract, debrief, etc.)
State (encoded in fields specific to the type)
Handlers (Lisp lambdas responding to key presses: on_car, on_cdr, on_eval, etc.)
Display handler (Lisp lambda rendering the cell’s chrome on each frame)

Cells are authored in Lisp using the defcell macro:

(defcell network-node
  (:doc "A computer node in the target network")
  (:fields
    (node-id :u16)
    (ice-level :u8)
    (data-size :u16)
    (data-class :u8))
  (:handlers
    (car (lambda (self)
           (drill-into (first-child self))))
    (cdr (lambda (self)
           (next-sibling)))
    (eval (lambda (self)
            (if (compromised? self)
                (extract-data self)
                (sfx-error))))))

See the sample cartridge at docs/software/cartridges/samples/icebreaker.lsp for worked examples.

41. The NoshAPI Surface

ICE BREAKER cartridges access 54 NoshAPI primitives via Lisp. Major groups:

Navigation:

(drill-into target) → navigate to child
(navigate-back) → pop nav stack
(current-cell) → return current cell

Display (text-puts, gfx-rect, gfx-line, gfx-pixel, gfx-blit, draw-sprite, text-clear):

(text-puts x y string) → draw text at position

Sound (sfx-select, sfx-confirm, sfx-error, sfx-alert, ambient-drone, psg-register-write):

(sfx-select) → short click
(ambient-drone freq vol) → background tone

Deck State:

(deck-state) → return UniversalDeckState struct
(credit-add amount) → increase credits
(rep-modify delta) → adjust reputation
(has-capability module-bit) → test cartridge history

Cell Pool:

(spawn-cell type) → allocate new cell
(destroy-cell cell) → return cell to pool

LFSR / Procedural:

(lfsr-init seed) → create LFSR state
(lfsr-range lfsr min max) → random value in range

CIPHER (ADR-0015):

(cipher-emit text) → immediate utterance (blocking)
(cipher-push-event type payload :affect flags) → event for generator
(cipher-set-mode-weights beat deltas) → biases for mode selector
(cipher-extend-grammar productions) → add rules (deprecated; use cipher-grammar block)

Auxiliary display (ADR-0015):

(aux-set-row-4-content type data) → set Row 4 mode (seed / sub-timer / phase meta / link status)
(aux-set-status-chip text) → update Row 1 status chip

See Para 39 of the existing Rev. B for the full 54-primitive list. The sample cartridge (icebreaker.lsp) comments each group.

42. The Mission Template Format

Missions are authored with defmission:

(defmission "PENETRATION"
  (:doc "Gain access to a network node")
  (:threat-range 1 4)
  (:base-payout 400)
  (:mission-class network)
  (:phases 1)
  (:phase-templates
    (phase 1 "NETWORK INTRUSION"
      (:requires ice-breaker)
      (:generator (lambda (threat-level rep-score deck-state)
                    (generate-penetration-network threat-level rep-score)))
      (:objective "Reach and compromise target node"))))

Key fields:

threat-range: bounds for threat level (1–5)
base-payout: starting credit reward
phases: number of mission phases
phase-templates: list of phase definitions, each with:
- requires: capability-bit declaration
- generator: lambda that creates the phase (network, objective, ICE placements)
- objective: operator-visible mission goal
- time-limit: optional; seconds before automatic failure

43. The Included PENETRATION Template

The simplest ICE BREAKER mission:

Generator creates a random network with 3–6 nodes, threat-level-dependent ICE distribution.
Operator enters at root (Node 0).
Objective is to reach and compromise the final node (Node N-1).
Success on EVAL if encryption depth has been cracked; failure if time expires or trace locks.
Debrief tallies credits and reputation.

This mission is single-phase and repeatable. It teaches the basic OODA loop.

44. The CIPHER Domain Region

ICE BREAKER contributes a cipher-grammar block to the nOSh runtime at cart-load. The block specifies:

Vocabulary pools:

(:actors     ("ICE" "TRACE" "NODE" "HUNTER" "JUNK" ...))
(:locations  ("SECTOR" "NODE" "SUBNET" "BACKBONE" ...))
(:outcomes   ("COMPROMISED" "EXTRACTED" "BURNED" ...))
(:actions    ("PENETRATE" "SIPHON" "GHOST" ...))

Productions (event → fragment templates):

((:event :threat-spike :affect :significant)
  → "perimeter. {TURNS} turns.")

Mode biases (per-phase style adjustments):

((:phase :active-hack    (:terseness +1 :certainty -1))
 (:phase :debrief        (:terseness -1 :certainty +1)))

At cart-load, nOS.h parses this block, merges it into the active grammar, and allocates 8 KB per-cart grammar arena. At cart-unload, the merge is cleared.

See the gameplay spec (docs/software/cartridges/modules/ice-breaker.md, §“CIPHER-LINE Contributions”) for ICE BREAKER’s full vocabulary and production list.

45. Clips and Algorithmic Art

ICE BREAKER ships ~40 clips (.kn86clip files):

Boot splash (3.0 s)
Network map ambient flow field (5 variants: calm, aware, alert, hunt, lockdown)
ICE class loops (4 variants)
Tool fire animations (6 variants)
Combo animations (6 variants)
Encryption depth visualizations (4 variants)
PSG visualizer panels (12–16 variants)
WFC superposition overlays (3 variants)
Glitch stress overlays (3 variants)
Network materialization L-systems (20–30 variants)
Extraction outcomes (3 variants)
Hot Swap sequences (2 variants)
Cipher prophecy monologue (1 variant)
Idle attract loop (1 variant)

Elements with unbounded state (Perlin trace heatmaps, Voronoi sysop influence, Lissajous tied to live PSG state) are rendered at runtime by cartridge handler code.

PART EIGHT — THE INSIDE GUIDE: BEING THE WORLD’S BEST ICE BREAKER

46. The 8 Fallacies of Distributed Computing as a Framework

The perfect game in ICE BREAKER — a clean extraction at maximum threat with zero trace and no failed tool applications — is structured around internalizing and exploiting the 8 Fallacies of Distributed Computing (Deutsch/Gosling, 1994).

Each fallacy maps to an assumption the network’s defensive systems make. The perfect Operator is the one who never makes these assumptions themselves:

1. The network is reliable.

It isn’t. Nodes drop. Connections degrade on repeated intrusion. The perfect Operator plans alternate routes before they’re needed. They CAR/CDR ahead and memorize the topology so that when ICE forces a redirect, they already know where to go.

2. Latency is zero.

Every traversal costs time and trace. The perfect Operator accounts for traversal cost in every decision — never assuming instant movement. They pace their actions to stay ahead of ICE’s cycle, not racing to the objective.

3. Bandwidth is infinite.

Tool slots are finite. Data extraction is rate-limited. The perfect Operator never over-commits tools to a single node. They load out with balanced archetypes, not all CRACK and SIPHON.

4. The network is secure.

The entire game exists because it isn’t. But this cuts both ways — the Operator’s own position is never secure either. The perfect Operator never assumes a cleared node stays cleared. They expect ICE to circle back and re-engage.

5. Topology doesn’t change.

Networks remember intrusions and reshape. Nodes that were once leaf nodes become bottlenecks. The perfect Operator treats the network map as a living document, not a solved puzzle. They adapt their entry point when the familiar route is now contested.

6. There is one administrator.

ICE operates independently. HUNTER has its own cycle. The sysop (in linked play) adds a third adversarial intelligence. The perfect Operator reads each system as a separate actor with separate tempo. They time their moves to exploit the gaps between ICE cycles and sysop actions, not as if ICE and sysop were coordinated.

7. Transport cost is zero.

Every action accumulates trace. Every swap costs network-advance time. The perfect Operator accounts for the true cost of every move — not just the immediate effect. CONS combos are powerful but cost trace. MIRROR is stealth but costs time. The perfect Operator trades rationally.

8. The network is homogeneous.

Nodes vary wildly: encryption depth, ICE class, data type, tool compatibility. The perfect Operator never applies a one-size-fits-all strategy. They read each node’s properties and choose the minimum-cost tool set for that specific node, not a global “go-to” loadout.

The perfect game is not about memorizing patterns. It is about developing an intuition that never falls for any of the 8 fallacies — cycling OODA faster than the threat while respecting every hidden cost the network imposes.

47. The Tempo Discipline

Tempo is the Operator’s heartbeat. ICE BREAKER teaches that cycles matter more than individual moves.

Fast cycles are good. A 2/second OODA cadence is the training baseline. At this tempo, the Operator completes decisions before ICE moves. But speed without care is reckless.

Slow cycles are precise. A 0.5/second cadence trades speed for deliberation. The perfect Operator reads ICE’s cycle and acts between its beats, even if that means waiting 2 seconds between CAR presses.

Tempo inversion happens. When HUNTER spawns (trace = 50), the threat’s cycle accelerates. If the Operator maintains their prior tempo, they fall out of sync. The perfect Operator re-syncs, matching or exceeding HUNTER’s beat.

Train your tempo discipline:

Play silent runs (screen off, audio only). You will learn to hear ICE’s cycle and sync to it.
Use the YM2149 click track as your metronome. Each threat class has a signature pulse. Match it.
Play speedrun categories (complete in under 5 minutes). Speed forces you to optimize every decision.
Play Sysop Mode with a human partner. Their unpredictability teaches reactive tempo.

48. Listening as a Primary Skill

The trained Operator can navigate with the screen off at moderate threat levels. Sound is not decoration; it is information.

Voice A pitch encodes ICE proximity and threat class.
- Slow rise in pitch = distant JUNK
- Rapid rise = closing BLACK
- Stuttering rise = RED adaptive (changing tactics)
- Accelerating rise = HUNTER (critical threat)
Voice B pulse rate encodes extraction throughput when SIPHON fires.
Voice C drone pitch encodes environmental chaos level (sysop activity in linked play).

Practice:

Set CIPHER to silent mode (SYS → CIPHER → Silent).
Dim the display or turn it off.
Play a Threat 1 contract purely by audio. You will develop an instinctive understanding of ICE behavior.
Graduate to Threat 2 and beyond once you can sustain a threat without visual feedback.

At Master tier, sound-only play is a viable endgame strategy. You can read the network’s state entirely from the audio signature, execute navigation and tools, and extract without ever looking at the screen.

49. Network Memory and Why You Don’t Repeat Seeds

Each run generates a unique seed for the procedural generator. That seed produces a unique network topology. However, the network remembers your intrusions.

If you run the same seed twice, ICE will be waiting for you. Nodes you compromised are now guarded. Routes you used are now monitored. The perfect Operator never repeats seeds — they accept unique contracts and treat each network as a fresh challenge.

Seed repetition is a training tool (useful for practicing a specific tactic), not a win condition. The Operator who beats their highest threat on a repeated seed has learned the network; the Operator who beats their highest threat on a new seed has learned ICE BREAKER.

50. The Toolkit Loadout Theorem

The intuitive loadout is two CRACK tools and two MIRROR tools, with one SPIKE and one SIPHON for utility. This is novice play.

The balanced loadout for threat 3-4 is:

One CRACK (mandatory; you cannot crack every node)
One MIRROR (stealth on data nodes)
One SPIKE (one guaranteed hit on RED)
One CLOAK (redirection / time-buying)
One SIPHON (extraction when MIRROR isn’t compatible)
One GHOST (surveillance when extraction isn’t possible)

Why balanced? Because the network is heterogeneous. Different nodes have different defensibility. A node with weak ICE but fragile data needs MIRROR, not CRACK. A node with strong ICE but unguarded payload needs SPIKE, not CRACK. The perfect Operator reads each node and picks the minimum-cost tool.

Paired archetypes (two of the same tool) unlock surprise combos. But surprise combos are expensive and risky. The theorem says: load balanced, reserve combos for true emergencies.

51. Hot Swap as Strategy, Not Rescue

Novice Operators use Hot Swap to escape a losing run. This is rescue mode — reactive, desperate.

Masters use Hot Swap to expand decision space. Before taking a run, they plan which cartridges they’ll need and when. They commit QUOTE at predetermined moments, not at the moment of crisis.

Example: An extraction run that requires decrypting a financial channel. The plan:

Enter with ICE BREAKER, navigate to the finance node.
At trace = 20, QUOTE (Hot Swap to Black Ledger).
Use Black Ledger’s audit capability to redirect the channel.
QUOTE again (Hot Swap back to ICE BREAKER for escape).

This is strategic Hot Swap. The Operator planned it before the run started. The swap happens at a moment of strength, not weakness.

52. Surprise Combos as a Personal Library

Surprise combos (REWRITE, SHADOW, LAUNDER) are not listed in the manual. They are discovered through play. Each Operator builds a personal library of combos they’ve discovered, tested, and mastered.

The perfect Operator keeps a notebook (physical or digital) of their surprise combos:

REWRITE (CRACK + MIRROR): cracks the node, then mirrors the cracked data back. High trace cost but guarantees data integrity.
SHADOW (CLOAK + SIPHON): misdirects ICE, then siphons data. Medium trace, high success rate.
LAUNDER (SIPHON + SPIKE): siphons data while burning a spike to mask the exfiltration. Aggressive; requires high reputation to survive.

But there are more. Every unique pairing has a hidden outcome. The perfect Operator experiments, documents, and builds a personal grimoire of tactics that work for their play style.

53. The Sysop Negotiation

Linked play (Sysop Mode) is not adversarial, it’s relational. The Sysop and Operator are playing a game together, not against each other.

The negotiation:

Operator sets difficulty: “Threat 3? Threat 4?”
Sysop sets resource budget: “I have 15 action points this run.”
They play. The Operator tries to extract; the Sysop tries to trace.
After the run, they debrief: “Your tempo was good. My HUNTER placement was clumsy. Let’s do it again with me being more reactive.”

The best Sysops are partners, not adversaries. They calibrate their difficulty to match their Operator’s skill level. A Master-tier Sysop plays a Master-tier Operator hard. A Journeyman-tier Operator gets a Sysop that’s slightly stronger, teaching them to improve.

54. The Operator’s Logbook

The TERM key REPL gives the Operator a workspace to record observations, test hypotheses, and build custom lambdas.

Use the REPL for:

Observation logging: (cipher-push-event :personal-note "network topology suggests RED at node F")
Custom lambdas: (define my-fast-crack (lambda () (cons CRACK MIRROR)))
Deck state inspection: (rep-score deck) → read current reputation
Audio cue testing: (sfx-alert) → test audio before a hot swap

The REPL history persists across power cycles. The perfect Operator uses the REPL as an external brain — a logbook that survives reboots.

55. The Thirty-Run Practice Curriculum

A structured 30-run plan for operators advancing from Journeyman to Master:

Runs 1–5: Threat 1, solo ICE BREAKER

Focus: Learn OODA cycle. Do not rush.
Target: 4 successful runs of Threat 1.
Milestone: One run with trace never exceeding 25 (stealth achievement).

Runs 6–10: Threat 2, solo ICE BREAKER

Focus: Master CONS (tool combinations). Experiment with surprise combos.
Target: Discover at least 2 surprise combos.
Milestone: Complete a Threat 2 with zero trace (silent play).

Runs 11–15: Threat 2-3, first Hot Swaps with Depthcharge

Focus: Hot Swap strategy (planning swaps, not panic). Get comfortable with scoped capability mode.
Target: 2 successful Hot Swap runs.
Milestone: Complete a 2-cartridge chain extraction.

Runs 16–20: Threat 3, two-cartridge toolkit (ICE BREAKER + Black Ledger)

Focus: Cross-module tactics. Use Black Ledger’s financial redirects to bypass RED ICE.
Target: Beat Threat 3 with two cartridges.
Milestone: Complete a run where the Hot Swap is the critical win moment (not a last-ditch rescue).

Runs 21–25: Sysop Mode, pair sessions with a friend

Focus: Human unpredictability. Learn to read a human’s strategy, not just ICE patterns.
Target: Win a Sysop Mode run with reputation balanced (both players earn rewards).
Milestone: Play 3 rounds with the same Sysop, losing the first, drawing the second, winning the third (adaptation).

Runs 26–30: Threat 4, three-cartridge chain (ICE BREAKER + Depthcharge + Black Ledger)

Focus: Tempo under extreme pressure. HUNTER acceleration. Multi-phase contracts.
Target: Beat Threat 4 once.
Milestone: Complete a run without saving SPIKE for emergencies (confidence in your toolkit).

After Run 30, the Operator is at Master tier. They can challenge Threat 5, enter speedrun categories, or teach newer players.

56. After Mastery: Speedrun Categories and Operator Communities

Speedrun categories (by threat level and objective class):

T1 any% (any mission, fastest time)
T2 pure-stealth (zero trace, any time)
T3 no-combos (no surprise combos allowed)
T4 deathless (zero tool failures)
T5 ironman (one-shot; failure = permanent character wipe)

Operator communities (period-appropriate BBS and magazine listings):

Zaibatsu Networks BBS: KNOSIT.ZN — forums for deck sharing, speedrun leaderboards.
Cipher Magazine: monthly rankings of fastest operators per threat level.
Local operator circles (arcade-style play-in-progress meetups).

The perfect Operator eventually becomes a teacher — a Master who takes on Journeymen and guides them through the practice curriculum. This is the final stage of mastery: generosity.

PART NINE — REFERENCE

57. GLOSSARY

The following entries cover the most-referenced terms in this manual. A complete glossary across the launch library is published separately as form ZD-86-IB-002.

ACT — the fourth phase of the OODA cycle; executing the operator’s decision.

Affinity — a category of network capability (DIGITAL, NETWORK, FINANCIAL, etc.) used for cross-module contract composition.

APPLY — Lisp key; plays back a recorded lambda (macro) slot against the current cell.

Apprentice — reputation tier 0–4; lowest capability, highest Cipher verbosity.

ATOM — Lisp key; tests whether the current cell is a leaf (free to traverse without tools).

Auxiliary display — see CIPHER-LINE.

BACK — Lisp key; return to network map view (pops the nav stack).

BLACK ICE — threat class 1; adaptive, learns player strategy.

CAR — Lisp key; descend into the current cell (head of pair).

CIPHER — procedural narrator; generates text observations on CIPHER-LINE.

CIPHER-LINE — 3.12-inch auxiliary OLED display (256×64 pixels) mounted above keyboard; renders status, CIPHER utterances, and contextual data (seed capture, timers, phase meta).

CLOAK — tool archetype; misdirects traffic, buys time without disabling ICE.

CONS — Lisp key; opens tool combination matrix; constructs tool pairs.

Contract — mission offer on the mission board.

CRACK — tool archetype; brute-force encryption (always succeeds, high trace cost).

Credit (¤) — universal currency; earned from contracts, spent on loadouts (if applicable in future revisions).

Debrief — post-mission screen; tallies credits, reputation, achievements.

Deck state — see Universal Deck State.

Drill-into — navigate to child cell via CAR.

Drift (CIPHER mode) — poetic, detached utterances; used in low-threat periods.

Egress — exit the network via LINK at root node; triggers extraction attempt.

EVAL — Lisp key; commit the current decision (irreversible).

Event ring — 128-slot decay-weighted event pool feeding CIPHER generator.

EXTRACTION — mission template; recover data from defended node.

FN — keycap label for LAMBDA key.

Ghost — tool archetype; deploys persistent monitoring beacon.

Grammar arena — per-cartridge 8 KB memory region for CIPHER grammar contributions.

GHOST — tool archetype; surveillance beacon.

Handle — operator’s chosen alias (persistent in Universal Deck State).

Hunter — threat class 3 (ICE); cascade effect, all-systems activation on trace = 50.

ICE — Intrusion Countermeasure Electronics; autonomous defensive systems.

INFO — Lisp key; observe (raw telemetry); double-tap triggers CIPHER orientation assist.

Journeyman — reputation tier 5–14; mid-capability; Cipher moderately talkative.

JUNK — threat class 0; slow, predictable (trainable on early runs).

Keystroke CONS combo (intuitive/surprise) — see CONS, REWRITE, SHADOW, LAUNDER.

LAMBDA (FN) — Lisp key; speculative action or record next 32 keystrokes as macro.

LAUNDER (surprise combo) — SIPHON + SPIKE; siphons while burning spike to mask exfil.

LINK — Lisp key; egress (extraction attempt from root node).

Linked play — two-Deckline asymmetric Sysop Mode (defender controls ICE, operator navigates).

Master — reputation tier 25–49; high capability; Cipher largely silent.

MIRROR — tool archetype; reflect data back to sender (stealth, data-type-dependent).

Mode (CIPHER) — emotional selector: observe / annotate / reflect / drift / silent.

Network — procedurally generated DAG of computer nodes; entry at root, objective deep.

Network memory — traces of prior intrusions persist; network adapts to repeated routes.

NIL — Lisp key; cancel current input, clear selection.

Node — vertex in the network graph; carries ICE, data payload, encryption depth.

NoshAPI — 54 FFI primitives exposed to cartridge Lisp.

Null cartridge — sanctioned exception; only cartridge permitted to render CIPHER on main grid.

OBSERVE — first phase of OODA cycle; gathering information.

OODA — Observe-Orient-Decide-Act; the atomic decision loop.

ORIENT — second phase of OODA cycle; context-setting (triggered by INFO×2).

Payload — data or objective inside a network node.

PENETRATION — mission template; gain access to network node.

Perfect game — clean extraction at maximum threat with zero trace and no tool failures.

Perimeter alert — warning event at trace = 30; Voice C pulse fades in.

Phase — mission segment; can span multiple cartridges in multi-phase contracts.

Phase chain — serialized multi-phase mission state, persisted across Hot Swaps.

PHANTOM — alternative spelling for QUICKCOPY combo (non-canonical).

Provenance chain — append-only hash log of deck/mission history.

PSG — Yamaha YM2149 Programmable Sound Generator (3 tone voices + noise + envelope).

QUOTE — Lisp key; bookmark current cell (quote) or initiate Hot Swap.

QUICKCOPY (surprise combo) — CRACK + MIRROR; variant spelling of PHANTOM.

RED — threat class 2 (ICE); lethal, spawns children, pattern-adaptive.

Reflection (CIPHER mode) — memory-infused utterances; cross-cart persistence.

REPL — read-eval-print loop; Lisp execution environment on TERM key overlay.

Reputation — cumulative career score; persists across cartridges.

REWRITE (surprise combo) — CRACK + MIRROR; cracks then mirrors data integrity.

Root node — entry point (Node 0) of the network.

SABOTAGE — mission template; disable critical system asset.

Sysop mode — linked play; defender (Sysop) controls ICE and events.

SHADOW (surprise combo) — CLOAK + SIPHON; misdirect ICE while siphoning.

SIPHON — tool archetype; copy data without ICE alert (rate-limited, risky).

Specialist — reputation tier 15–24; advanced capability; Cipher quiet.

SPIKE — tool archetype; malware payload (high-damage, alarm risk).

SYS — Lisp key; system menu (save, handle change, preferences).

Sysop — defensive player in linked play.

Tempo — heartbeat of OODA cycles; speed of decision-making.

TERM — context-sensitive key; REPL overlay by default.

Threat class — ICE archetype: JUNK / BLACK / RED / HUNTER.

Threat level — 1–5 scale indicating contract difficulty.

Threat spike — CIPHER event at trace milestones (30/50/75).

Tool — consumable intrusion weapon (CRACK / MIRROR / SPIKE / CLOAK / SIPHON / GHOST).

Trace — 0–100 heat level; accumulates on actions, decays over time.

TRRS cable — 3.5 mm audio jack; carries linked-play communication.

Universal Deck State — persistent operator identity (handle, credits, reputation, phase chain, etc.); shared across all cartridges.

Verb — operational category in mission composition (PENETRATE / OBTAIN / DESTROY / OBSERVE).

YM2149 — see PSG.

58. KEY MAP REFERENCE CARD

   ┌─────────────────────────────────────────────────────────────────┐
   │  ICE BREAKER — KEY REFERENCE (v1.0)                              │
   │  ───────────────────────────────────                              │
   │                                                                   │
   │  NAVIGATION                                                       │
   │    [CAR]    Descend / enter node                                  │
   │    [CDR]    Ascend / return to parent                             │
   │    [BACK]   Return to network map                                 │
   │    Digits   Select adjacent node (2/4/6/8) or combo option        │
   │                                                                   │
   │  ACTION                                                           │
   │    [EVAL]   Commit (irreversible)                                 │
   │    [CONS]   Open combination matrix                               │
   │    [APPLY]  Replay recorded lambda slot                           │
   │    [FN]     Speculative action / record macro                     │
   │    [LINK]   Egress (root node only)                               │
   │                                                                   │
   │  OBSERVATION                                                      │
   │    [INFO]   Telemetry (single press)                              │
   │    [INFO]×2 CIPHER orient assist                                  │
   │    [ATOM]   Test if leaf (free)                                   │
   │    [EQ]     Compare to bookmark                                   │
   │                                                                   │
   │  STATE                                                            │
   │    [QUOTE]  Bookmark / Hot Swap                                   │
   │    [NIL]    Cancel                                                │
   │    [SYS]    System menu                                           │
   │                                                                   │
   │  TERM (context-sensitive, right outer thumb)                      │
   │    default  Lisp REPL overlay                                     │
   │    seed     When CIPHER-LINE Row 4 is seed-display mode,          │
   │             TERM captures seed into quote slot                    │
   │                                                                   │
   │  TRACE THRESHOLDS                                                 │
   │    30 = Perimeter alert    50 = HUNTER spawn    75 = Lockdown     │
   │                                                                   │
   │  CIPHER-LINE (auxiliary OLED above keyboard)                      │
   │    Row 1   Status: battery, timer, mode chip, TERM hint           │
   │    Row 2   CIPHER live utterance                                  │
   │    Row 3   CIPHER echo (prior utterance)                          │
   │    Row 4   Contextual: seed, sub-timer, phase meta, link status   │
   │                                                                   │
   │  DIGIT CLUSTER (right half — ADR-0031 §3.1)                       │
   │    [1] [2] [3] [/] [,]                                            │
   │    [4] [5] [6] [;] [.]                                            │
   │    [7] [8] [9] [-] [ENT]                                          │
   │    thumbs: [0] [TERM]                                             │
   │                                                                   │
   └─────────────────────────────────────────────────────────────────┘

59. AUDIO EVENT CATALOG

The following table catalogs every audible event the loaded ICE BREAKER cartridge produces, the YM2149 voice or noise channel responsible, and the engineering specification of the sound. Operators trained per Para 21 will recognize these events by ear; novices may keep this table at hand during the first ten runs.

Event	Voice	Specification
CAR / enter	A	1.0 kHz, 50 ms
EVAL / confirm	A	1.5 kHz, 100 ms
CONS / combo open	A	1.8 kHz, 80 ms
CRACK fire	B + envelope	4-note descending arpeggio
MIRROR fire	B + envelope	4-note rising arpeggio
SPIKE fire	B + envelope	single needle, 100 ms total
CLOAK fire	B + envelope	ring-out chord, 1200 ms
SIPHON fire	B + envelope	coin-pickup pattern
GHOST fire	B + envelope	reverse envelope, 800 ms
Intuitive CONS combo	B	major triad arpeggio
Surprise CONS combo	B	8-note dissonant arpeggio
JUNK spawn	A	slow rise 400 ms
BLACK spawn	A	rapid rise 150 ms
RED spawn	A + C	spike + transients
HUNTER spawn	A + B + C	all-three-voice spike
Trace 30 (perimeter)	C	1.5 Hz pulse
Trace 50 (HUNTER)	A + C	A vibrato; C dominates
LINK pressed	noise	300 ms modem burst
Egress success	A + B + C	resolving major chord, 1.5 s
Hot Swap initiated	A + B + C	multi-voice stab
CIPHER click track	A	2 kHz, 4 ms per glyph

60. ECONOMIC FORMULAS

60.1 Base Payout

   base_reward = threat_level × 200 ¤

60.2 Bonuses

   speed_bonus     = 0.20 × base_reward × (turns_remaining / time_limit)
   stealth_bonus   = 0.20 × base_reward  if peak_trace < 35, else 0
   objective_bonus = 0.10 to 0.20 × base_reward by objective_class

60.3 Reputation Multiplier

   rep_multiplier = 1 + (reputation_score / 100)

60.4 Final Payout

   final_payout = (base_reward + speed_bonus + stealth_bonus + objective_bonus)
                  × rep_multiplier

60.5 Reputation Delta

   rep_delta_success = threat_level + phase_count
   rep_delta_failure = -2
   rep_delta_abandon = -1

60.6 Worked Examples

Scenario	Calculation	Total
Threat 2 PENETRATION, rep 5, 4/8 turns, peak trace 30, bypass	(400 + 80 + 80 + 80) × 1.05	672 ¤
Threat 4 EXTRACTION, rep 25, 6/10 turns, peak trace 45, plant	(800 + 64 + 0 + 80) × 1.25	1180 ¤
Threat 5 SABOTAGE, rep 50, 3/6 turns, peak trace 25, disable	(1000 + 100 + 200 + 150) × 1.50	2175 ¤

61. ERROR CONDITIONS

61.1 Cartridge Load Errors

Symptom	Likely Cause	Action
Display: “INVALID CARTRIDGE”	Header magic ≠ “KN86” or version ≠ 2	Verify cartridge image; reflash if necessary
Display: “CRC MISMATCH”	Header or section CRC failed	Cartridge media may be damaged; reflash
Display: “CAPABILITY MISSING”	`requires_bits` not satisfied	Load required cartridge first
Display: “CAPABILITY NOT GRANTED”	Unauthorized cart-capabilities declaration	Cartridge is not permitted to use that capability (Null exception only)
Cart loads but no mission board	Template parsing error	Author error; check Template section in cart

61.2 Runtime Errors

Symptom	Likely Cause	Action
Display: “FE ARENA EXHAUSTED”	Cartridge exceeded 32 KB Fe arena	Author error; reduce cell allocation
Display: “HANDLER TIMEOUT”	Cartridge handler exceeded 50 ms budget	Author error; optimize handler
Display: “PHASE CHAIN OVERFLOW”	Phase chain exceeded 256 bytes	Author error; reduce intermediate state size
Display flicker / corruption	Display compositor backpressure	Reduce simultaneous clip count
Audio dropouts	Audio callback starvation	Reduce per-tick computational load

61.3 Save Errors

Symptom	Likely Cause	Action
Deck state lost on reboot	Flash write interrupted by power-off	No recovery; reset to Apprentice
Cartridge save corrupted	Save region CRC failed	Cartridge save resets to defaults; deck state preserved
Provenance chain inconsistent	Chain link broken	Block discarded; chain continues from last valid block

APPENDIX A — PHYSICAL HARDWARE REFERENCE

The KN-86 Deckline hardware specification is canonical in the project CLAUDE.md (Canonical Hardware Specification table). Do not restate those values here; instead reference that document.

Summary:

Subsystem	Specification	Reference
Processor (primary)	Raspberry Pi Zero 2 W	CLAUDE.md
Coprocessor	Raspberry Pi Pico 2 (RP2350) — PSG synthesis + OLED driver	ADR-0017
Primary display	Elecrow 7-inch IPS, 1024 × 600	CLAUDE.md
Auxiliary display (CIPHER-LINE)	3.12-inch OLED, SSD1322, 256 × 64, yellow	ADR-0015
Keyboard	34 keys — Ferris Sweep split (3×5 + 2 thumb/half), hot-swap Choc, dual KB2040, QMK	ADR-0031, ADR-0022, ADR-0024
Accelerometer	LIS3DH, 3-axis MEMS, ±4g, 25 Hz ODR (drives CRT-glitch ambient)	ADR-0023
Audio	YM2149 (emulated) → MAX98357A → 28 mm 8 Ω 2 W speaker	CLAUDE.md
Cartridge interface	Full-size SD card via USB mass storage (internal hub bridge)	ADR-0019
Battery	3× 18650 via Waveshare UPS Module 3S; ~4–5 h display-active, ~10–12 h electronics-only	CLAUDE.md, ADR-0038
Enclosure	Pelican 1170 with custom 3D-printed inset panels	CLAUDE.md

APPENDIX B — RECOMMENDED OPERATOR PROGRESSION

The reference progression for an Operator new to the platform:

Sessions	Tier	Activities
1-3	Apprentice 0-4	Threat 1 PENETRATION; learn OODA loop; CIPHER verbose
4-10	Apprentice → Journeyman	Mix Threat 1-2; discover CONS combos; consider second cartridge
11-25	Journeyman 5-14	Threat 2-3; first Hot Swaps; Sysop Mode if linked play available
26-60	Specialist 15-24	Threat 3-4; multi-phase contracts; surveillance implants
61-150	Master 25-49	Threat 4-5; cross-cartridge chains; CIPHER silent
151+	Legend 50+	Exclusive contracts; cryptic CIPHER; teach others

This progression is not enforced; the Operator is free to deviate at their own risk.

APPENDIX C — REGULATORY AND SAFETY NOTICES

The KN-86 Deckline is sold as a recreational and educational device. The intrusion-themed gameplay of ICE BREAKER is fictional. Operators should not interpret the cartridge as instruction in any actual computing-system intrusion technique. All “networks” rendered by the cartridge are entirely procedural and exist only within the Fe VM arena of the loaded cartridge instance.

The TRRS cable supplied with the unit is for use with linked play between two KN-86 Decklines. It is not certified for use with other audio equipment.

The internal LiPo battery shall not be punctured, exposed to flame, or charged outside the unit. Replacement batteries are available from authorized service centers only.

APPENDIX D — REVISION HISTORY

Revision	Date	Notes
Rev. A	2026-04-22	Initial publication. ICE BREAKER v1.0 against nOSh runtime v2.4.1.
Rev. B	2026-04-24	CIPHER-LINE canon incorporated per ADR-0015. Auxiliary OLED display added to hardware spec; primary/auxiliary split made explicit; §14 CIPHER Narrator rewritten; §39 NoshAPI grown to 62 primitives with cipher-* and aux-* groups; §42 rewritten as CIPHER Grammar Section; cartridge format updated with cart-capabilities block (ADR-0006 amendment); TERM key added (31st physical key) with context-sensitive seed-capture binding.
Rev. C	2026-04-29	Capability-model canon, Lisp authoring, custom keyboard, coprocessor, REPL, and OLED-exclusive CIPHER per ADRs 0014–0024. Foreword and structure reorganized into nine Parts and four Appendices. Part Two: nOS.h owns coprocessor communication; Per-cart save on SD per ADR-0019. Part Three: TERM key and REPL (§14) added; custom keyboard 31-key layout with phone-layout numpad, FN-printed LAMBDA (ADR-0022), TERM context-sensitive per ADR-0016; 12×24 native font opt-in per ADR-0014 F1. Part Four–Eight: Complete rewrite of gameplay sections with 8 Fallacies framework (§46), tempo discipline (§47), listening as primary skill (§48), practice curriculum (§55); cross-module affinity grammar (§37); Hot Swap as strategy (§51). Part Seven: Cartridge authoring in Lisp per ADR-0001/ADR-0004; defcell, defmission, defdomain, defstruct forms; Fe VM; 54 NoshAPI primitives; cipher-grammar block per ADR-0015 with vocabulary, productions, mode-weight biases. Part Nine: Reference consolidated (glossary, key map, audio catalog, economics, errors). Appendices: Hardware reference points to CLAUDE.md Canonical Spec (never restates); Progression tier unchanged; Safety notices updated for SD cartridge interface. DeckState struct reflects REPL history and coprocessor architecture. Cartridge save = file on SD per ADR-0019.
Rev. D	2026-06-21	Keyboard retargeted to the Ferris Sweep 34-key split per ADR-0031 (supersedes the custom 31-key path). §2.1 input row, §2.4 key-layout figure (Fig. 2-1), §10.1–§10.2 physical controls, §24 boot, §58 key-reference card, and Appendix A updated: 14 Lisp-primitive function block on the left half (EVAL on the inner thumb, LSHIFT on the outer thumb); digit 3×3 + `, . / ; -` punctuation + ENT on the right half (0 + TERM on the thumbs). Left-half home-row revision (BACK · CDR · CAR nav cluster) and `FN`-printed LAMBDA preserved per ADR-0022. Phone-style 4×4 numpad retired: `*` / `#` are now shift / symbol-layer glyphs and `0` is a thumb key. Logical key set, Lisp semantics (§11), and FFI unchanged. Canonical layout: ADR-0031 §3.1.

═══════════════════════════════════════════════════════════════════════════════

                               END OF DOCUMENT

                          KN-86 ICE BREAKER MODULE
                       OPERATOR AND TECHNICAL MANUAL
                          Form ZD-86-IB-001, Rev. C

                                Zaibatsu Digital
                                  Osaka, 2026

═══════════════════════════════════════════════════════════════════════════════

PART ONE — INTRODUCTION

FOREWORD

HOW TO USE THIS MANUAL

CONVENTIONS

TABLE OF CONTENTS

PART ONE — INTRODUCTION

1. SCOPE AND PURPOSE

1.1 Scope

1.2 Purpose of the Module

1.3 Purpose of This Manual

2. THE KN-86 DECKLINE PLATFORM

2.1 Hardware Specification

2.2 Operating Substrate

2.3 Display Layout (Master Reference)

2.3.1 Primary Display (80 × 25 main grid)

2.3.2 Auxiliary Display — CIPHER-LINE (32 × 4 OLED)

2.4 Key Layout

3. PLACE OF ICE BREAKER WITHIN THE LIBRARY

3.1 The Capability Library and Launch Titles

3.2 Standalone Operation

3.3 Position in the Operator’s Career

4. SUMMARY OF CAPABILITY

PART TWO — SYSTEM ARCHITECTURE

5. nOS.h — THE OPERATING SUBSTRATE

5.1 Identification

5.2 Functional Responsibilities

5.3 Cartridge Subordination

5.4 Coprocessor Architecture (ADR-0017)

5.5 Bare Deck Operation

6. THE CAPABILITY MODEL

6.1 Definition

6.2 The Cartridge Slot

6.3 Capability Declaration and Composition

6.4 The Capability Curve

7. UNIVERSAL DECK STATE

7.1 Definition

7.2 Structure (Abbreviated)

7.3 Persistence

8. THE CARTRIDGE INTERFACE

8.1 Cartridge Format and Storage

8.2 The .kn86 v2.0 Format

8.3 Loading Sequence

8.4 Hot Swap and Unloading

9. RUNTIME EXECUTION CYCLE

9.1 Main Loop Overview

9.2 How nOS.h Runs ICE BREAKER

PART THREE — OPERATING THE DEVICE

10. PHYSICAL CONTROLS

10.1 Function Keys (14)

10.2 Digit & Punctuation Keys (right half)

10.3 Power and Reset

10.4 Cartridge Slot

10.5 Audio Output and Linked Play

11. THE LISP KEY GRAMMAR

11.1 Premise

11.2 Primary Reference

11.3 Universality Across Cartridges

11.4 Dispatch Mechanism

12. THE DISPLAY SYSTEM

12.1 Primary Display (Main Grid)

12.1.1 Logical Canvas

12.1.2 Row Ownership

12.1.3 Color and Glyphs

12.1.4 Font Rendering Modes

12.2 Auxiliary Display (CIPHER-LINE)

12.2.1 Logical Canvas

12.2.2 Row Ownership

12.2.3 Color and Glyphs

12.3 Algorithmic Art and Clips (Primary Display Only)

13. THE AUDIO SYSTEM

13.1 The Sound Generator

13.2 Voice Channel Assignment in ICE BREAKER

13.3 Audio as Information

13.4 Mix Discipline

14. THE TERM KEY AND THE LISP REPL

14.1 The TERM Key

14.2 The REPL Overlay

14.3 REPL Capabilities

14.4 Permanent Surface Advertising

15. THE CIPHER NARRATOR