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); 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).

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), 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 — defextension, the manifest as a value, install as a recorded transaction.
• Defining a contribution kind — how the kernel defines :method, :effect, and the rest, and how you add a kind.
• Recoding live — the hot-patch path behind the second pillar.
• The live image — the running-image mechanism all three pillars rest on.