# Extensions All the Way Down


kli runs inside its own live SBCL image. The boot kernel knows only how to install,
switch, and roll back protocols. The extension system is itself a protocol installed on
that kernel, and every contribution carries a retractor, so retraction drains exactly
what it added. Extensions all the way down.

That sentence is the whole design. The kernel is small on purpose (see
[The live image](/kli/concepts/the-live-image)); everything you interact with is a
contribution installed against a protocol, paired with a retractor that undoes it. The
kind vocabulary the contributions are written in is contributed the same way, which is
where "all the way down" stops being a slogan (see
[Defining a contribution kind](/kli/extend/lisp-extensions/defining-a-contribution-kind)).

The arrangement buys three things. Each is the same install/retract mechanism seen at a
different reach into the running program.

## Specialize the running program.

A `:method` contribution adds a method to any generic function in the live image; its
retractor is `remove-method`. You change the
program's own dispatch and roll it back, with no rebuild. The kind compiler turns the
clause into a `make-method-contribution` carrying the generic-function name, qualifiers,
specializers, and body; install adds the method, retract removes that exact method. This
is the mechanism at its sharpest: the unit you install and drain is a method on kli's own
code.

## Rewrite without restarting, keep the state.

A hot patch swaps a function's code while keeping its closed-over state, so the session
keeps its buffers and its scrollback across the change. cairn does this in tree: its
context effect calls `recode-context-transform-policy` to splice live task context into
every turn, saving the previous `extra-messages-fn` and handing its retractor the saved
value to restore. The recode is reversible because the contribution recorded what it
replaced, not merely what
it added. It runs behind the capability and fault-barrier machinery (see
[Capabilities and fault barriers](/kli/concepts/capabilities-and-fault-barriers)), so a
hot-patched function that throws degrades rather than killing the session.

## Switch the whole world, safely.

A protocol switch validates, smoke-tests, swaps, and rolls back on any error. This sits
at the kernel altitude, not the extension-authoring one. kli's control plane exposes
`control-install-protocol`, `control-switch-protocol`, and `control-rollback-protocol`,
each gated on its own capability (`:protocol/create`, `:protocol/switch`,
`:protocol/rollback`). An extension does not
switch the world; the kernel does. What an extension supplies is the retractor that makes
a switch clean: because every contribution drains exactly what it added, the kernel can
tear down one protocol and stand up another with no residue. The safety of the switch is
the reversibility of the pillars beneath it, used by the kernel.

## Where this goes

The pillars are the *why*. The mechanics of writing and installing the contributions
behind them are the *how*:

- [Lisp extension anatomy](/kli/extend/lisp-extensions/anatomy) — `defextension`, the
  manifest as a value, install as a recorded transaction.
- [Defining a contribution kind](/kli/extend/lisp-extensions/defining-a-contribution-kind)
  — how the kernel defines `:method`, `:effect`, and the rest, and how you add a kind.
- [Recoding live](/kli/extend/lisp-extensions/recoding-live) — the hot-patch path behind
  the second pillar.
- [The live image](/kli/concepts/the-live-image) — the running-image mechanism all three
  pillars rest on.