Module error 

Shared error types for Pureflow runtime-facing APIs.

Fragment: error-taxonomy

The foundation layer uses one shared error enum because downstream crates already need a consistent contract, but the taxonomy is still kept narrow: validation, execution, cancellation, lifecycle observation, and metadata collection. That is enough to remove stringly-typed errors without inventing categories the runtime has not earned yet.

Fragment: error-code-stability

Error codes are explicit instead of being derived from enum names so logs, tests, and future CLI or API surfaces can depend on stable identifiers even if wording changes. The code surface is intentionally small and can grow only when a new externally meaningful error condition appears.

Fragment: error-visibility-and-retry

Visibility and retry guidance live next to the error variants because they are part of the policy, not just formatting. A validation failure should be safe to show and not worth retrying, while an execution or lifecycle failure is mostly diagnostic until the runtime grows more concrete recovery rules.

Fragment: asupersync-error-boundary

asupersync errors are runtime substrate details. The shared Pureflow error model maps them into cancellation or execution failures at the boundary so downstream node and workflow APIs do not grow a public dependency on raw channel or task error types.

Structs

CancellationError

Cancellation observed at the runtime boundary.

ExecutionError

Runtime execution failure from a node.

LifecycleError

Failure while recording or reacting to a lifecycle event.

MetadataError

Failure while collecting runtime metadata.

Enums

ErrorCode

Stable machine-readable code for one Pureflow error condition.

ErrorVisibility

Whether an error should be surfaced directly to a human.

PureflowError

Shared runtime-facing error for the Pureflow foundation layer.

RetryDisposition

Retry guidance for one error condition.

ValidationError

Validation error exposed through the shared runtime-facing error model.