Skip to main content

Module bootstrap

Module bootstrap 

Source
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 a module_phase = bootstrap FunctionProto lands. Drives the seeder front-to-back so multi-target installs surface one BootstrapComplete per target in the order the host supplied to bytesandbrains::install.
  • module_bootstraps — per-target metadata (function key + touch set) keyed on the target name. The touch set is the closure of every ComponentRef referenced by the bootstrap function body (slot-id NodeProtos + transitive FunctionCalls); the install path stamps it via Engine::compute_touch_set so 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-supplied BootstrapRequests 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 + staged QueuedBootstraps ready to fire once the in-flight set drains. Empty today; F4 populates.
  • next_idx — seed pointer into install_order. Bumps each time Engine::maybe_complete_bootstrap observes a phase drained. Engine::seed_bootstrap_call reads it to pick the next target once the host kicks the queue.
  • pending — coarse “queue still has work” flag the body-op gate
    • maybe_complete_bootstrap consult. Armed by arm_install_order (host kick) or enqueue_request (staged BootstrapRequest), cleared once every queued phase drains.

Structs§

BootstrapRequest
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 a target name 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_exactextend_from_slice) so the caller’s borrowed buffers can drop the moment crate::engine::core::Engine::enqueue_bootstrap_request returns.
ComponentBootstrap
Per-slot Component bootstrap metadata. Stamped into the engine bootstrap state when a Component registers a Bootstrap Contract impl. Empty today; F5 wires the registration path.
InFlightBootstrap
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.
ModuleBootstrap
Per-target Module bootstrap metadata. Stamped into the engine bootstrap state when the install path sees a module_phase = bootstrap FunctionProto.
OwnedBootstrapRequest
Owned-form bootstrap input request used by the engine’s internal conflict-queue path (BootstrapState::pending_requests). The host- facing borrowed BootstrapRequest is 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.
QueuedBootstrap
Validated + staged bootstrap awaiting an in-flight slot. F4 drains waiting once in_flight clears. Empty today.
ReadyBootstrap
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) emits ReadyBootstraps 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§

BootstrapKind
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.
BootstrapStatus
Host-facing bootstrap lifecycle status. Returned by Node::bootstrap_status so the caller can decide whether to keep polling or surface a “wait for input” prompt. F3 fills the observable surface.