david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Clarify integration model for Fid4 and XFlowViewMaker, emphasizing its role in the propagation path

Browse Source
This commit is contained in:
David Delagneau
2026-04-17 11:54:33 -06:00
parent 9b019953f7
commit 4ea188739d
1 changed files with 2 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
vault/03-context/workstreams/consumer-integration.md
View File

@@ -39,7 +39,8 @@ Capture the durable release and validation path between XFlow changes and real c
- downstream consumer release then determines when the change reaches the App Store build
- A code fix in XFlowSDK is not ready for Fid4 validation until that full dependency chain has propagated.
- In practice, the release effort often includes dependency bump work, PR approvals, protected-branch/code-owner requirements, Jenkins publishing, and local consumer dependency refresh steps.
- Fid4 currently consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
- In the current integration model, Fid4 consumes XFlow through XFlowViewMaker only, not by depending on XFlowSDK directly.
- For current-state reasoning and communication, treat XFlowViewMaker as a required part of the Fid4 propagation path, not as an optional or "usually" present layer.
- Other frameworks also consume XFlow through XFlowViewMaker, especially `FTAccountOpen` and `FTTransfer`.
- For Account Opening paths, the practical consumer route is currently understood to run through `FTAccountOpen`.