ComponentStore and NgRx Store: Cross-Feature Workflow State Boundary

Teams building Angular features with NgRx often need to manage workflow state that spans multiple concerns, such as form progression, validation state, or UI flags that interact with domain data. The interoperability between @ngrx/store and @ngrx/component-store offers a path to separate local UI state from shared domain state, but the appropriate boundary for cross-feature workflow state remains an open design decision.

ComponentStore state is scoped to the lifecycle of its declaring provider; providing it at component level resets state on navigation away, whereas global Store slices persist for the application lifetime. NgRx version matters: recent releases have introduced SignalStore and signal-based APIs that shift recommended patterns for state declaration and effect registration. The documentation does not prescribe a single rule for where cross-feature workflow state should live, leaving teams to establish their own conventions.

• Where should cross-feature workflow state reside to avoid divergence from global domain state while minimizing boilerplate?
• What conventions prevent ComponentStore local state from drifting out of sync with corresponding global Store selectors?
• Does the NgRx version in use (e.g., 16.x versus a SignalStore‑based 17.x) influence the recommended boundary for cross-feature workflow state?