Expand description
Engine bootstrap state — consolidated owner of every bootstrap field the engine reads during install + poll.
Host-driven: install records targets on install_order +
module_bootstraps but leaves pending disarmed. The host arms
the queue via crate::node::Node::run_bootstrap (which calls
[Self::arm_install_order] + Engine::seed_bootstrap_call) or
by staging a BootstrapRequest (which arms via
[Self::enqueue_request]).
§Field roles
install_order— append-only target-name sequence the install path stamps when amodule_phase = bootstrapFunctionProto lands. Drives the seeder front-to-back so multi-target installs surface one BootstrapComplete per target in the order the host supplied tobytesandbrains::install.module_bootstraps— per-target metadata (function key + touch set) keyed on the target name. The touch set is the closure of everyComponentRefreferenced by the bootstrap function body (slot-id NodeProtos + transitive FunctionCalls); the install path stamps it viaEngine::compute_touch_setso the host-driven driver can pre-acquire bound components without re-walking the program at run time.component_bootstraps— per-slot Component bootstrap registry.pending_requests— host-suppliedBootstrapRequests awaiting validation + staging.in_flight— currently executing bootstraps (Module or Component). Today at most one entry — the currently seeded module bootstrap. The Vec shape readies the host-driven path for concurrent Component bootstraps.waiting— validated + stagedQueuedBootstraps ready to fire once the in-flight set drains. Empty today; F4 populates.next_idx— seed pointer intoinstall_order. Bumps each timeEngine::maybe_complete_bootstrapobserves a phase drained.Engine::seed_bootstrap_callreads it to pick the next target once the host kicks the queue.pending— coarse “queue still has work” flag the body-op gatemaybe_complete_bootstrapconsult. Armed byarm_install_order(host kick) orenqueue_request(stagedBootstrapRequest), cleared once every queued phase drains.
Structs§
- Bootstrap
Request - Host-supplied bootstrap input staging request — borrowed shape per
the F5 host-driven bootstrap spec
(
docs/internal/superpowers/specs/2026-06-25-host-driven-bootstrap.md§3.1). The host hands the engine atargetname plus an ordered(input_name, value_bytes)slice; the engine validates against the target’s declared formal input ports and runs the Principle 1a copy (cap-check →try_reserve_exact→extend_from_slice) so the caller’s borrowed buffers can drop the momentcrate::engine::core::Engine::enqueue_bootstrap_requestreturns. - Component
Bootstrap - Per-slot Component bootstrap metadata. Stamped into the engine
bootstrap state when a Component registers a
BootstrapContract impl. Empty today; F5 wires the registration path. - InFlight
Bootstrap - Currently executing bootstrap. The host-driven seeder
(
Engine::seed_bootstrap_call) pops one Module target per phase and pushes it here; the Vec shape supports concurrent disjoint Component bootstraps fired through the conflict-queue path. - Module
Bootstrap - Per-target Module bootstrap metadata. Stamped into the engine
bootstrap state when the install path sees a
module_phase = bootstrapFunctionProto. - Owned
Bootstrap Request - Owned-form bootstrap input request used by the engine’s internal
conflict-queue path (
BootstrapState::pending_requests). The host- facing borrowedBootstrapRequestis the canonical staging shape; this owned mirror exists so the conflict queue can keep parked requests alive across poll cycles. Kept internal-ish to the engine — the [BootstrapState::enqueue_request] consumer is exercised by sibling tests only. - Queued
Bootstrap - Validated + staged bootstrap awaiting an in-flight slot. F4
drains
waitingoncein_flightclears. Empty today. - Ready
Bootstrap - Validated + staged bootstrap that cleared the touch-set conflict
check and is ready for the engine to assign an ExecId + push its
body onto the frontier. The conflict queue
(
BootstrapState::process_pending_requests/on_bootstrap_drained) emitsReadyBootstraps back to the engine instead of mutating in-flight state directly so the seed step (ExecId allocation, frontier population) stays on the engine side where the OpRef tables live.
Enums§
- Bootstrap
Kind - Discriminator for the two bootstrap dispatch kinds the engine drives. Module bootstraps splice into the FunctionCall path under a fresh ExecId; Component bootstraps invoke a Contract method on the bound runtime impl directly.
- Bootstrap
Status - Host-facing bootstrap lifecycle status. Returned by
Node::bootstrap_statusso the caller can decide whether to keep polling or surface a “wait for input” prompt. F3 fills the observable surface.