Module cone 

Cone-level JIT inside the interpreter kernel (engines.md §2, §8).

At assembly time, maximal cones of JIT-eligible nodes with scalar boundaries collapse into one synthetic JitConeNode each, compiled to native code by the P3 codegen. The cone node is an ordinary PolydatNode: the walker, scope chains, shared cells, None propagation, node_clean caching, and the enrich-and-re-raise panic contract all see a plain node.

Boundary marshalling covers every one-slot immediate and every Ref2 kind, borrowed into its pair for the call and copied out after it; interior fusion follows whatever the P3 classifier accepts. Extraction is recoverable: member nodes move into the cone only after codegen succeeds, so a cone whose code generation fails leaves its members exactly as the interpreter would have compiled them. Under JitMode::Auto the failure is recorded on the tree’s CompileLedger and the compile goes on; under JitMode::Force it fails the compile (engines.md §2.1).

A component that is not convex is first split into the convex pieces native code and pure native code form from it (fusion_units::convex_pieces, engines.md §8). A cone reads at most MAX_CONE_INPUTS distinct boundary inputs, and a convex piece that reads more is cut into pieces within the bound, each compiled on its own (engines.md §2.2).

Enums

JitMode

How much of the interpreter’s graph is fused into native cones: the interpreter engine’s one knob, carried by Engine::Interpreter and settable per assembler with set_jit_mode. It is a property of the kernel being built, never of the process: two hosts in one process compiling under different modes get the kernels they each asked for.

Constants

MAX_CONE_INPUTS

The most distinct boundary inputs one cone piece reads: an implementation bound on each piece, not on the component it is cut from. A component over it is cut into pieces within it, and a single node over it stays on the interpreter and is recorded on the ledger (engines.md §2.2).