XFlow Debugging

Goal

Debug backend-driven flows without losing track of dynamic dependencies or misclassifying integration behavior.

XFlow screens are backend-driven, so UI can change without local code changes.
Reproduction depends on:
- entry point
- authentication state
- backend configuration
- consumer integration path
Not all entry points are reachable from visible UI; some require exploratory validation.

Confirm the entry point before comparing behavior.
Separate service-driven behavior from client regressions.
Confirm whether the issue reproduces in:
- sample app
- XFlow-only environment
- Fid4 / flagship
- authenticated vs non-authenticated state
If a fix appears correct in the SDK but not in consumer validation, inspect the release chain before reopening root cause assumptions.
When validating service/configuration changes, check the active flow-definition version in Cogstore before assuming a change is live in QA or Production.
Do not assume a flow ID will exist in both Cogstore and Slate; verify which config system actually owns the flow you are inspecting.

Historical debugging covered Next-button visibility, markdown modal analytics, modal presentation, slot updates, and SwiftUI lifecycle behavior.
Multiple pipeline or dependency problems looked like XFlow issues until the build chain or consumer integration path was inspected more carefully.