Module flow_staging 

Postgres flow-staging inherent methods (Wave 4i).

Mirrors the ingress-layer Lua FCALLs that the Valkey backend ships under ff-server::Server — these are not EngineBackend trait methods. The Valkey shape is:

• ff_create_flow — INSERT flow_core
• ff_add_execution_to_flow — stamp exec.flow_id + bump counters
• ff_stage_dependency_edge — CAS graph_revision + INSERT edge
• ff_apply_dependency_to_child — mark edge applied + bump edge_group

Wave 4c already covers the read surface and cancel_flow. This module adds the mutating ingress operations so flow-DAG construction works on Postgres end-to-end. Wave 5a owns the completion-cascade dispatch that consumes what apply_dependency_to_child writes.

Storage convention

Matches Wave 4c’s decoder in flow.rs:

• Flow-level extras (flow_kind, namespace, node_count, edge_count, last_mutation_at_ms) live in ff_flow_core.raw_fields jsonb.
• Edge-level extras (dependency_kind, data_passing_ref, staged_at_ms, applied_at_ms, edge_state, created_at_ms, created_by, satisfaction_condition) live in ff_edge.policy jsonb (the only jsonb slot on that row).

No schema migration is required — every new field fits in the existing jsonb columns. This keeps Wave 4c’s decoder and the dispatch queries (which select on typed columns only) unchanged.

Membership

ff_add_execution_to_flow / ff_stage_dependency_edge treat membership as ff_exec_core.flow_id = flow_id — the same back- pointer that Wave 4c’s cancel_flow already queries. No separate member table is introduced; RFC-011 flow/exec co-location makes the back-pointer authoritative on the flow’s partition.

Functions

add_execution_to_flow

ff_add_execution_to_flow — stamp exec.flow_id + bump flow counters.

apply_dependency_to_child

ff_apply_dependency_to_child — mark an edge applied + bump the downstream’s edge-group aggregate.

create_flow

ff_create_flow — idempotent INSERT into ff_flow_core.

stage_dependency_edge

ff_stage_dependency_edge — CAS on graph_revision + INSERT into ff_edge.