LambdaDelta plugin system + dev design/deploy wizard (minter · provisioner · configurator · harness)

[hyperpolymath]

Summary

A first-class plugin/package system for LambdaDelta (λδ), plus a guided
development design → deploy wizard built from four lifecycle components —
minter, provisioner, configurator, harness — mirroring the pattern used in
PanLL and the BoJ server. The goal is to let the λδ ecosystem
accelerate its own development: packages that extend Nexia-List (and any future
λδ host) can be scaffolded, granted capabilities, configured, tested, and
deployed through one coherent flow.

Design context: ADR-0003
· λδ spec (v0 draft).

The four components (mapped to Nexia-List / λδ)

• Minter — scaffolds a new plugin: generates the package skeleton (manifest,
  entry points, example λδ, tests, docs stub) so authoring starts from a working
  template rather than a blank file.
• Provisioner — resolves and installs a plugin into a notebook/host: declared
  dependencies, the capability grants it requests (which notebook data it may
  read/mutate, which host-functions it may call), and version pinning.
• Configurator — the plugin's settings + capability surface, with a
  user-facing config UI generated from the plugin's declared schema (ties to the
  planned typed-attribute/spec work). Nothing runs with capabilities the user
  hasn't granted.
• Harness — a sandboxed develop/test environment: run the plugin against a
  fixture notebook, with the REPL, assertions, and the λδ evaluation budget +
  capability enforcement, so authors iterate safely and CI can verify plugins.
• Wizard — ties the four into a guided design→deploy flow.

Why this is cheap to build well (architecture note)

Because λδ is homoiconic and implemented in the Rust/WASM core, much of an SDK
falls out for free if we keep a clean seam:

• a pure language kernel (reader · evaluator · values · hygienic macros)
  that knows nothing about notes; and
• host bindings (the notebook builtins) registered through a host-function
  interface.

With that seam, a plugin/SDK is mostly: (1) a package format (.ld source +
a manifest declaring entry points + requested capabilities), (2) the
capability model the provisioner/configurator enforce, and (3) developer
ergonomics (REPL, formatter, linter, test harness, docs generator). Nexia-List
becomes simply the first host; the same kernel can be embedded elsewhere.

Dependencies / sequencing

Mostly post-L0 (needs the λδ interpreter first), but two fundamentals should
be sketched early because they shape the kernel/host seam and the sandbox:

1. Capability model — what a plugin may read/mutate; how grants are declared,
   requested, and enforced.
2. Package format — manifest schema + the .ld interchange form.

Suggested order: L0 kernel (notebook-agnostic) → host-binding/capability layer →
package format → minter/harness (author loop) → provisioner/configurator
(install/config) → wizard (glue).

Open questions

• Align the minter/provisioner/configurator/harness contracts with the existing
  PanLL / BoJ server conventions — reuse their manifest/lifecycle shapes
  where it makes sense rather than reinventing.
• Sandboxing/trust: signing or provenance for shared plugins (estate policy?).
• Where plugins live: in-notebook (travel with the data) vs a shared registry
  vs both.

Filed at the user's request as the tracked home for the plugin/SDK direction;
no code yet — this depends on Phase L0.