From 4ea188739d772929bf3a4e121f40852b6f9b6815 Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Fri, 17 Apr 2026 11:54:33 -0600 Subject: [PATCH] feat: Clarify integration model for Fid4 and XFlowViewMaker, emphasizing its role in the propagation path --- vault/03-context/workstreams/consumer-integration.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/vault/03-context/workstreams/consumer-integration.md b/vault/03-context/workstreams/consumer-integration.md index acf6dfe..34e7fc1 100644 --- a/vault/03-context/workstreams/consumer-integration.md +++ b/vault/03-context/workstreams/consumer-integration.md @@ -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`.