Module dag 

Typechecking a node graph: topological order, fan-in composition via InputExpr, cycle rejection (unless marked repeat_until), and branch-exclusivity analysis for conditional dispatch.

See docs/superpowers/specs/2026-08-03-dag-core-design.md for the full design. This module’s check_graph is the graph-shaped analogue of crate::pipeline::check — same idea (typecheck seams before anything runs), different shape (a graph of named nodes instead of a Vec).

Structs

BranchExclusivity

Which branch decision + label a node is exclusive to — a node is only executed when this decision’s chosen route matches label. Carrying decision (not just label) is what lets two independent branches decisions that happen to reuse the same label string coexist without being confused for a conflict.

CheckedGraph

A whole graph, typechecked and topologically ordered.

CheckedNode

One checked node, ready to execute.

Enums

DagError

Why a graph was rejected.

Functions

check_graph

Typecheck a graph. resolved must already contain one entry per node in graph.nodes, in the same order — building that mapping (via pipeline::resolve_and_load, one call per node) is the caller’s job (a later task), same division of responsibility pipeline::check already has.

fanout_collection_ty

What a fan-out node presents to the nodes downstream of it.

graph_fingerprint

A stable fingerprint of a checked graph’s shape and contents — every node’s name and declared signature, joined and hashed. Two graphs with the same fingerprint are the same, for resume-safety purposes; this isn’t a security boundary, just a “did the loaded spec actually change” guard, so a simple SHA-256 (already a workspace dependency, same crate the catalog’s own content-hashing uses) is all this needs.