Module substrate 

The Substrate trait — the one provider seam (ARCHITECTURE.md §8).

Core never names a substrate; providers implement this trait and the binary registers them by name. Everything per-substrate flows through here: validation, capabilities, defaults, and the resource operations the lifecycle engine drives (execute / observe / destroy). Adding a provider must require zero changes to the engine or state modules.

Structs

ServiceLog

One service’s recent logs as a substrate retrieved them, for the logs verb. The substrate owns where the lines come from (a cloud API, a local file); the CLI only renders them.

SpendInfo

Structured spend data for cloud --json envelopes (§4).

StepContext

Everything a substrate gets to execute one step.

StepResource

What execute hands back for the journal: the resource the step created (or re-affirmed), recorded before the engine proceeds.

SubstrateFault

A substrate failure, flattened at the trait boundary so the §2 error contract (stable code + remediation) crosses it intact whatever error enum the provider uses internally.

Enums

NamespacePurpose

Which env resolution path is building a namespace.

Observation

What a recorded resource looks like when re-checked against the substrate (invariant 4: the manifest says where to look, the substrate says what’s true).

Constants

ACTION_RESOURCE_KIND

Steps that perform work but create no destructible resource (hooks, health gates) record this kind; teardown drops their checkpoints without a destroy/observe round-trip.

Traits

Substrate

Functions

action_resource

present_or_gone