Skip to content
KN-86 Deckline

ADR-0042: First-Party On-Device Programs — the canonical thirteen

Context

Section titled “Context”

Three kinds of software run on this device — and only one of them was ever counted

Section titled “Three kinds of software run on this device — and only one of them was ever counted”

The KN-86 runs three distinct categories of software, and conflating them is what produced the “only four apps” misreading this ADR corrects:

  1. Carts — third-party-shaped capability modules on removable SD media (ADR-0019). The launch set is five titles. Carts are the content extension surface; there is no fixed ceiling on how many can ever exist.
  2. Mission capability baselines — the System tier of the Capability Registry (ADR-0030). These are mission generators, not programs: TERMINAL / GRID / AUDIT / SONAR, one per launch-cart domain, each bounded by design and superseded by its cart. ADR-0030’s no-precedent rule fixes this set at exactly four, forever, and that is correct — a baseline exists only to give a cart’s domain a playable floor before the cart arrives.
  3. First-party on-device programs — the tools the operator uses: navigate a filesystem, write Lisp, read network traffic, build a target dossier, manage keys, message a handler. These are not mission generators and not removable content. They ship in the system image, on DeckRunner’s Content tier, and are always present regardless of what cart is in slot.

ADR-0030 spoke only to category 2. Its “only four” rule has nonetheless been read as a cap on category 3 — as if the device’s entire first-party software identity were the four mission baselines plus the board. It is not, and Josh has decided it is not. The hacker-operator deck is defined as much by its toolkit as by its missions: REPL and nEmacs already exist as first-party programs with their own ADRs; CONDUIT, AmberCalc, and DOSSIER are already named as data destinations in missions under design. The set was always larger than four; it was simply never enumerated.

Forcing functions

Section titled “Forcing functions”
  • Mission authoring is ahead of the spec. Multiple missions in design drop artifacts into named programs — audit output into AmberCalc, exfiltrated files into Kinoshita Kommander, cross-mission intel into DOSSIER. The programs must be canonically named before that authoring can reference them safely.
  • The screen router needs a closed set. DeckRunner (ADR-0040 §3) routes between surfaces. “The system apps” is currently an informal, incomplete list in the companion spec; the router needs an authoritative roster.
  • The “only four” reading needs an explicit correction. Leaving ADR-0030’s rule to be silently over-applied keeps the device’s software identity artificially narrow. This is a deliberate scope decision and belongs in an ADR, not in prose.

Constraints

Section titled “Constraints”
  • No new hardware or display contract. All thirteen render on the canonical 128×75 primary grid — Rows 1–73 for content, Row 0 (status) and Row 74 (action bar) firmware-reserved (see CLAUDE.md Canonical Hardware Specification). CIPHER voice remains OLED-exclusive (ADR-0015); Keyring does main-grid key operations but never paints CIPHER glyphs on the main grid.
  • Programs are not baselines and not carts. They have no Capability Registry presence, no cartridge_history entry, and are never superseded by a cart. A cart may enrich a program’s data (BLACK LEDGER feeds AmberCalc; ICE BREAKER drives a CONDUIT session) but never gates access to it.
  • Charter, not implementation. This ADR fixes the roster and the rules. Per-program design docs and engineering are non-blocking follow-ons. Stub programs are acceptable at launch; unchartered programs are not.

Decision

Section titled “Decision”

The KN-86 Deckline ships thirteen first-party on-device programs. They are canonical, named, part of the system image, authored in KEC Lisp on DeckRunner’s Content tier, and owned by the screen router. They are neither mission capability baselines nor carts.

The canonical roster, ordered by operator-workflow centrality:

#ProgramWhat it is
1Mission BoardContract discovery and acceptance — the operator-facing face of Mission Control (ADR-0028). The default landing surface.
2Deck HubUniversal Deck State, loadout, and Lambda-slot management — the operator’s “character screen” as a terminal utility. Also the Blank Slate Deck onboarding surface.
3REPLThe always-present read-eval-print loop over the KEC Lisp VM. Reached by the TERM key from any surface; doubles as the device’s Lisp tutorial. (ADR-0002, ADR-0016)
4nEmacsThe structural editor for authoring and editing Lisp over s-expression trees on-device. (ADR-0008, ADR-0016)
5CONDUITMulti-protocol network client — SSH / Telnet / FTP / raw TCP. The primary intrusion interface for live terminal access to a target.
6Kinoshita KommanderTwo-panel Norton Commander-style filesystem navigator. Where exfiltrated data lands and is staged; moves files between device SD, cart SD, and network targets.
7AmberCalcColumnar spreadsheet. Forensic and audit missions (BLACK LEDGER domain) drop transaction data into its views — rows, calculated columns, filter/sort, export to DOSSIER.
8RIPSAWFast dual-panel tree / LDAP navigator — org charts, offshore account topology, corporate directory walking. Amber-on-black, “rips with the grain.”
9KeyringMain-grid key operations — generate, revoke, inspect, crack. The CIPHER voice (cryptographic personality) stays OLED-exclusive; Keyring is the main-grid operations surface.
10kn9 (Kinoshita K9)Encrypted operator comms and relay — handler messages, dead drops, intel from linked decks. Threaded message/mail client, Mutt-style.
11DOSSIERCross-mission intel aggregation — a persistent profile of targets, persons, and accounts that missions contribute to. A workspace that outlives any single session or cart.
12bzbxBundled network-diagnostic toolkit: ping, traceroute, nslookup, telnet, wget, nc, plus a packet/signal capture viewer — applets inside one program. The “read the wire” tool.
13knSALKThe deck’s own defense bundle — firewall (block inbound), antivirus (scan and neutralize hostile payloads), and internal ICE (active countermeasures when an intrusion is already underway against the operator’s deck). The defensive counterpart to the offensive toolkit (CONDUIT / RIPSAW / Keyring): the shield against enemy trace programs and counter-intrusion during contracts. Name: Salk → vaccine → immunization.

Specific commitments:

  1. This list is the canonical first-party program roster. Adding a first-party program requires a successor ADR or an amendment to this one — not just a doc. The roster is closed by decision, open by ADR.

  2. Programs are a distinct category from carts and baselines. No Capability Registry presence, no cartridge_history entry, never superseded by a cart. They are always available, including with no cart in slot — they are part of the bare-deck experience, alongside (not inside) Mission Control’s bare-deck bounty pool and the four mission baselines.

  3. ADR-0030’s no-precedent rule is preserved, scoped to mission baselines. The System tier still holds exactly four baselines (TERMINAL / GRID / AUDIT / SONAR), and no future cart domain earns one. That rule governs mission generation. It does not govern the program roster, and never did.

  4. DeckRunner’s screen router owns program lifecycle. Each program is a routable surface alongside the Mission Board. A new NoshAPI primitive, (launch-app :program-id …), is the sanctioned launch verb from cart and mission Lisp (e.g., BLACK LEDGER phase 3 routes audit output into AmberCalc). This requires an ADR-0005 amendment (Documentation Updates).

  5. Programs live in runtime/programs/ in the kn-86 monorepo, one subdirectory each: mission-board/ deck-hub/ repl/ nemacs/ conduit/ kommander/ ambercalc/ ripsaw/ keyring/ kn9/ dossier/ bzbx/ knsalk/. Already-implemented programs (REPL, nEmacs, Mission Board) reorganize into this layout as part of the terminology/topology sweep — not a gate for this ADR.

  6. Program design docs consolidate under docs/software/programs/. REPL and nEmacs move there from docs/software/runtime/. The remaining ten get design docs as non-blocking follow-ons. (The implementer-facing editor reference stays in docs/software/api-reference/editor-tools/ — a different tier; the program docs link to it.)

Options Considered

Section titled “Options Considered”

Option A: Charter the thirteen as the canonical roster by ADR. (ACCEPTED)

Section titled “Option A: Charter the thirteen as the canonical roster by ADR. (ACCEPTED)”

Name the programs, fix the three-way taxonomy (cart / baseline / program), give them a home on the Content tier and in the screen router, and explicitly scope ADR-0030’s “only four” rule back to mission baselines.

Chosen because mission authoring already references unnamed programs; the router needs a closed set; and the device’s tool identity is a deliberate product decision that deserves an explicit, durable record. The cost — ten outstanding design docs — is real, but the design debt was already accruing informally; naming it makes it trackable.

Option B: Keep the informal enumeration; add programs as their specs land.

Section titled “Option B: Keep the informal enumeration; add programs as their specs land.”

Leave the scattered references in the companion spec and individual ADRs; formalize a program only when its design doc is written.

Rejected because authoring is ahead of the specs. DOSSIER, AmberCalc, and CONDUIT appear in mission designs today with no program doc. A roster ADR lets the references stand and the specs follow in any order — the opposite ordering blocks mission design on program design for no reason.

Option C: Ship the utilities as carts; keep the system image minimal.

Section titled “Option C: Ship the utilities as carts; keep the system image minimal.”

Make each first-party tool a standard .kn86 cartridge rather than a system-image program.

Rejected because Mission Board, REPL, and nEmacs must work with no cart in slot — they are the bare deck. A cart-only model forces a mandatory “system cart,” exactly the dependency ADR-0030 was written to avoid. The line between “ships in the image” and “lives on removable media” is both architecturally correct and operator-felt.

Trade-off Analysis

Section titled “Trade-off Analysis”
DimensionA — charter the thirteen (chosen)B — informal / as-you-goC — programs as carts
Mission authoring can reference programs safely✓✗ refs precede specs✗ needs a “system cart”
Screen router has a closed, routable set✓✗ open-ended◐
Program identity first-class vs. carts✓◐ scattered✗ submerged into cart model
Bare-deck experience (board/REPL, no cart)✓✓ (incidental)✗
Corrects the “only four” misreading explicitly✓✗ left implicitN/A
Outstanding design-doc debt✗ 9 named, unwritten◐ deferred, still accrues✗ same

Accepted cost: ten program design documents are outstanding. They are tracked below, owned by Gameplay Design, and non-blocking for this charter.

Consequences

Section titled “Consequences”

Positive

Section titled “Positive”
  • Mission authoring gains thirteen stable program names to target as contract destinations and data sinks.
  • DeckRunner’s screen router has a closed, enumerated surface set.
  • The three-way taxonomy (cart / mission baseline / first-party program) is now explicit, ending the “only four apps” conflation.
  • ADR-0030’s baseline rule is clarified and preserved — it governs mission generation, not the toolkit.
  • New first-party programs now require an ADR — no silent scope creep, in either direction.

Negative / Accepted costs

Section titled “Negative / Accepted costs”
  • Ten programs (Deck Hub, CONDUIT, Kinoshita Kommander, AmberCalc, RIPSAW, Keyring, kn9, DOSSIER, bzbx, knSALK) have no design docs yet.
  • (launch-app …) is a new NoshAPI primitive needing an ADR-0005 amendment before it is implementable.
  • A runtime/programs/ subtree must be scaffolded and the existing REPL / nEmacs / board implementations reorganized into it (topology sweep).
  • The companion spec’s informal list and several runtime cross-links must be repointed to docs/software/programs/.

Follow-on work this ADR creates

Section titled “Follow-on work this ADR creates”

Design documents (Gameplay Design; non-blocking on ship): conduit.md, kommander.md, ambercalc.md, ripsaw.md, keyring.md, kn9.md, dossier.md, bzbx.md, knsalk.md, deck-hub.md — all under docs/software/programs/.

Engineering: (launch-app …) FFI primitive → ADR-0005 amendment · runtime/programs/ scaffold (reorganize REPL / nEmacs / board) · screen router registers thirteen program ids.

Documentation Updates (REQUIRED — Spec Hygiene Rule 3)

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

ADRs are immutable once accepted (README); ADR-0027/0028/0029 reference docs/software/runtime/repl.md at its prior path as point-in-time records. Those references are left as-is (house precedent: see ADR-0040/0041 phase-gated sweeps); the live, canonical referrers are repointed above.

Narrative

Section titled “Narrative”

ADR-0030 made the right call for mission baselines: only the four launch-cart domains get a System-tier floor, and that floor is bounded by design. But a rule written for mission generation quietly became a ceiling on the device’s whole first-party software identity — as if the deck were nothing but a mission board and four training stubs. It never was. A hacker-operator’s deck is its toolkit: the editor you write Lisp in, the navigator where stolen files pile up, the spreadsheet an audit pours into, the dossier that remembers every target you’ve touched, the client your handler messages you through — and the shield that keeps an enemy’s ICE off your own deck while you work. REPL and nEmacs already shipped as first-party programs; most of the rest were already named in mission briefs before anyone wrote their specs, and knSALK completes the set by giving the operator a defense to match the offense. This ADR draws the line that was missing — cart, mission baseline, and first-party program are three different things — names all thirteen programs, fixes ADR-0030’s rule to the four baselines it was always about, and gives mission authors, the screen router, and the FFI surface stable names to build against. The programs were always more than four. Now they’re written down.