Struct PlanContext 

pub struct PlanContext<'a> {
    pub input: &'a NormalizedInput,
    pub step_seq: WireU64,
    pub previous_head: Option<&'a Digest>,
    pub config: &'a ResolvedOperationConfig,
    pub resolving: Option<&'a KernelEffect>,
    pub pending: &'a [KernelEffect],
}

What the planner is given. Everything it needs to decide, and nothing that would let it depend on the host’s wall clock or on a default that may drift between binaries: config is the configuration this operation froze in its genesis record.

Fields

input: &'a NormalizedInput

step_seq: WireU64

previous_head: Option<&'a Digest>

config: &'a ResolvedOperationConfig

resolving: Option<&'a KernelEffect>

The pending effect a ResolveEffect input answers — the very effect this kernel published, already checked against §15.3 (still pending, kind matches the outcome, not a conflicting duplicate). None for every other input class.

The planner needs it because a failure outcome carries no kind: §7.9’s cross-effect HostEffectFailure is deliberately kind-agnostic, so the one policy decision DEC-5 allows has to be looked up from what the kernel asked for, never from what the host echoed back.

pending: &'a [KernelEffect]

The effects that stay pending after this input settles the one it answers: the §5k answer of “what does this kernel still have outstanding”. A step that resolves one effect of a multi-effect batch (or that shares its turn with still-running children) must not resume the loop — the provider call it would emit would outrun work the host still owes.

Trait Implementations

impl<'a> Debug for PlanContext<'a>

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.