pub struct StepNode {Show 15 fields
pub name: String,
pub persona_ref: String,
pub given: String,
pub ask: String,
pub output_type: String,
pub confidence_floor: Option<f64>,
pub navigate_ref: String,
pub apply_ref: String,
pub requires_context: Option<u32>,
pub now_tz: Option<String>,
pub guards: Vec<StepGuardNode>,
pub pix_ops: Vec<FlowStep>,
pub stream: Option<Box<StreamBlock>>,
pub performs: Vec<PerformStep>,
pub loc: Loc,
}Fields§
§name: String§persona_ref: String§given: String§ask: String§output_type: String§confidence_floor: Option<f64>§apply_ref: String§requires_context: Option<u32>v2.22.0 — the step’s declared MODEL CAPABILITY requirement: the
context window (in tokens) the cognitive act needs. The v2.22.0 resolver
maps it to the smallest concrete model that satisfies it (per the
resolved backend’s v2.22.0 catalog); None → the backend default
(back-compat). Declare the NEED, not the vendor SKU.
now_tz: Option<String>v2.46.0 — the step’s declared cognitive timezone: an IANA name
("America/Bogota", "UTC"). When present, the runtime injects the
run’s captured instant — rendered in THIS zone — into the step’s
cognitive context (time_is_an_explicit_input, the v2.27.0 doctrine
applied to cognition). Format-checked at compile time (axon-T892);
full IANA membership is the runtime’s job (chrono-tz, v2.46.0).
Overrides a bound context’s now: for this step. None → no
temporal injection (back-compat).
guards: Vec<StepGuardNode>v2.83.0 — the governance applications declared in this step’s body, in source order. Empty for every pre-v2.83.0 program.
pix_ops: Vec<FlowStep>v2.83.0 — the STATEMENTS written in this step’s body, in source
order: the PIX verbs (navigate / drill / trail / validate)
and the step-scoped invocations (probe … for […], use_tool … with …, a bare <Agent>(args) call, par { … }).
README’s pix/corpus family writes them exactly here, with a braceless
field list, and each produces a binding (as: relevant_sections) the
step’s own ask: then interpolates. So they are ELEVATIONS, the same
shape v2.83.0 gave lambda/ots: dispatch runs them BEFORE the step’s
generation. Reusing the flow-level node types (no new AST shapes) is
the the design decision doctrine — one concept, two positions.
stream: Option<Box<StreamBlock>>v2.83.0 — a stream<T> { … } written in THIS step’s body.
Deliberately NOT a Self::pix_ops entry, and the distinction is the
whole design. Every pix_ops statement is an ELEVATION: dispatch runs it
BEFORE the step generates, so its binding is available to the step’s
ask:. A stream handler is the opposite — on_chunk runs DURING the
step’s own output, once per chunk, and there is nothing to elevate.
Filing it under pix_ops would also have produced a specific, silent
bug: README block 15’s step Stream declares no ask: at all, so
run_step would have run the handlers as an elevation and then fallen
through to the LLM path with an EMPTY prompt — a real upstream call, made
on nothing, once per run. The field is what tells the dispatcher this
step’s output IS the stream.
performs: Vec<PerformStep>v2.87.0 — the perform Op(args) statements written in THIS step’s
body, in source order.
A THIRD position, and for the same reason v2.83.0 needed a second one.
the design plan section 3.1 publishes:
step generate {
given: prompt
let response = ask "Generate response"
perform Emit(response.token)
perform Done()
}The performed argument IS the step’s own output. Filing these under
Self::pix_ops would run them BEFORE generation, so response.token
would resolve against a binding that does not exist yet — the handler
would receive an unresolved symbol and the wire would carry a name where
the adopter expected a token. Dispatch runs performs AFTER the step
generates, with the step’s output in scope.
loc: Loc