Skip to content
KN-86 Deckline

Capability Shapes — grammar or mini-game

1. The statement

Section titled “1. The statement”

When the Mission Runner enters a cart capability via (load-capability …), that capability presents the operator with one of two shapes:

  • Grammar capability — the operator works the cart’s Tier-2 verb-tools (verb-partition.md): select a noun, pick a verb-tool, CONS to combine, EVAL to fire. It lives on the Mission Runner’s Lisp surface, so it is inspectable, scriptable, and automatable (lambdas in Lambda Slots). Examples: Black Ledger’s predicate/forensic queries; Cipher Garden’s substitution solve; The Vault’s research.
  • Mini-game capability — a self-contained, usually real-time gameplay loop drawn straight to the framebuffer, with its own bespoke mechanic — not verb-noun. Examples: ICE BREAKER’s OODA netrun; a maze-under-timer; a snake-eats-data extraction.

Both are first-class. The dialectic is simply: the framework gives every cart a universal grammar, and each cart spends its capability budget on grammar depth, bespoke mini-games, or both.

2. The shared contract (why the engine doesn’t care which)

Section titled “2. The shared contract (why the engine doesn’t care which)”

Whichever shape a capability takes, it honors the same contract — which is what lets the Mission Runner sequence capabilities without knowing or caring about their shape:

  • Both are (load-capability …) targets (ADR-0029).
  • Both run to completion and return the same result struct — {:outcome :trace :extracted :turns :bonuses} (ADR-0029).
  • Both flip objective-graph goals through the same goal verbs (goal-complete / goal-reveal / goal-choose / goal-fail, ADR-0043).
  • The call is opaque to the runner (ADR-0029): the runner sequences between capabilities; the shape lives inside the call.

So a mission’s phase chain can hand off grammar → mini-game → grammar and the orchestration code is identical at each seam.

3. Cart chooses; missions mix; the console always overlays

Section titled “3. Cart chooses; missions mix; the console always overlays”
  • The cart chooses the shape, per capability (and a domain may offer different shapes for different capabilities).
  • A mission may mix shapes across phases — e.g. a grammar recon phase, then a mini-game breach phase, then a grammar forensic phase.
  • A mini-game never walls off the grammar. The REPL/console is always reachable (the TERM-key dropdown, DeckRunner §8) — so even inside a real-time mini-game the operator can drop to the console. “Mini-game” means the primary surface is bespoke, not that the Lisp surface is gone.

4. Why both shapes exist

Section titled “4. Why both shapes exist”
  • Grammar is the platform’s identity: composable, scriptable, accessible (the floor — select-and-fire; the ceiling — lambdas). It is where the deck’s Lisp soul lives, and where automation and planning are the fun.
  • Mini-game is the fantasy-console texture (DeckRunner §2): arcade feel, dexterity, real-time tempo. It is where execution is the fun.

One platform hosts both a netrun OODA loop and a forensic predicate query without two engines, because the shape is a cart-side choice behind a shared contract — not an engine fork.

5. Authoring guidance

Section titled “5. Authoring guidance”
Pick…when the fun is in…e.g.
Grammarcomposition, planning, automation, inspectionforensics, market, territory, research, cryptanalysis
Mini-gamereal-time execution, dexterity, tempo, spatial playnetrun, maze, arcade-extraction, sonar-chase
Mix across phasesa run that wants both a planning beat and an execution beatrecon (grammar) → breach (mini-game) → audit (grammar)

6. Open / deferred

Section titled “6. Open / deferred”
  • Mid-mini-game grammar handoff — the precise UX of dropping to the console during a real-time loop (pause semantics, whether the loop keeps ticking). Minor; tuning-level.
  • Result-struct shape-specifics — whether a mini-game vs. grammar capability wants any shape-specific result fields beyond the shared struct (currently: no — the shared struct holds).