Flow logic, process mining, and breaking-change graph

These checks build one graph of every flow, subflow, Apex action and field reference in the project, and flag broken automation and changes with a wide blast radius.

VULKRO_SF_HYGIENE=1 vulkro-sf scan ./force-app
vulkro-sf flowmap ./force-app      # the automation graph itself
vulkro-sf impact Region__c ./force-app  # what breaks if a field, class or flow is deleted

These checks are off by default; VULKRO_SF_HYGIENE=1 turns them on. They are correctness and change-risk findings, not exploits. Static source cannot see managed-package callers, dynamic SOQL or org-only wiring, so each finding is a candidate and counts are a lower bound.

Checks

Rule ID	What it finds	Fix
SF-FLOW-LOGIC-001	A subflow call to a flow missing from the project or marked inactive. The branch fails or never runs.	Retrieve or activate the called flow, or remove the call.
SF-FLOW-LOGIC-002	A flow references a custom field that no other surface uses, so the flow is its only consumer.	Wire up the missing producer or consumer, or retire the field and the branch.
SF-PROCESS-MINE-001	An orphan flow: no trigger, no parent, never called as a subflow or from Apex.	Confirm there is no dynamic launch path, then retire it.
SF-PROCESS-MINE-002	A hub flow with high fan-in (a single point of failure).	Treat it as an interface: pin inputs and outputs, test every caller.
SF-PROCESS-MINE-003	Informational automation inventory: each flow with trigger type, version state, callers and the objects and fields it touches.	None. Use it to brief reviewers.
SF-BREAKING-001	A custom field, Apex class or flow with many inbound references, so a delete or rename is high-risk. Lists the dependents by type.	Update every dependent in the same change, or stage the change behind a deprecation window.

Each finding carries the node API name, type and inbound and outbound edge counts. JSON output includes graph node IDs.

Checks​

Checks