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>§Fase 68.b — the step’s declared MODEL CAPABILITY requirement: the
context window (in tokens) the cognitive act needs. The §68.c resolver
maps it to the smallest concrete model that satisfies it (per the
resolved backend’s §68.a catalog); None → the backend default
(back-compat). Declare the NEED, not the vendor SKU (D68.1).
now_tz: Option<String>§Fase 91.a — 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 §71 doctrine
applied to cognition). Format-checked at compile time (axon-T892);
full IANA membership is the runtime’s job (chrono-tz, §91.b).
Overrides a bound context’s now: for this step. None → no
temporal injection (back-compat).
guards: Vec<StepGuardNode>§Fase 119 (D119.4) — the governance applications declared in this step’s body, in source order. Empty for every pre-§119 program.
pix_ops: Vec<FlowStep>§Fase 119.f — 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 §119.c gave lambda/ots: dispatch runs them BEFORE the step’s
generation. Reusing the flow-level node types (no new AST shapes) is
the D119.4 doctrine — one concept, two positions.
stream: Option<Box<StreamBlock>>§Fase 119.n — 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>§Fase 120 — the perform Op(args) statements written in THIS step’s
body, in source order.
A THIRD position, and for the same reason §119.n needed a second one.
fase_23 §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