Flow Implementation
For service responsibilities and dependencies, see NICo Flow. Operator contracts live in Flow Operations.
Layers
Planning and persistence
Operation-run creation calls the planner and saves the run plus all materialized targets in one store transaction. The planner resolves candidate scope, applies exclusions and selection, orders targets, assigns phases, and freezes component execution sets. Later phases read the saved targets rather than re-planning from inventory.
The operation-run manager owns manual lifecycle changes. The dispatcher owns reconciliation, safety-gate evaluation, target claims, and submission. Refer to manual controls and dispatcher implementation when changing pause, resume, phase advance, cancellation, or recovery behavior.
Task schedules use a separate dispatcher. The internal job scheduler is a third mechanism; its overlap policies and lifecycle do not define the user-facing schedule API.
Database definitions are in migrations and models. See rule versioning for rule-format development notes and rule execution for activity and workflow boundaries.
Interfaces and configuration
The Flow protobuf is the API source. Generated Markdown and generated HTML remain owned by the Flow Makefile’s gen-doc target.
Use Flow Component Managers for configuration precedence and defaults. Local service startup and build instructions remain in the Flow README.