# XFlow Debugging

## Goal

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

---

## Stable Patterns

- 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.

---

## Investigation Rules

- 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 Signals From Slack

- 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.