feat: Document resolution process for Fid4 dependency conflict and clarify XFlowViewMaker versioning in podspec repo

vault/02-work-items/pdiap-15765.md

@@ -71,9 +71,10 @@ tags:
 ## Next Step
 
 - The XFlowViewMaker approval and publish step are now complete.
-- Resolve the new Fid4 dependency conflict caused by downstream `FTAccountOpen` / `FTTransfer` constraints that do not yet accept the published XFlowViewMaker version.
-- Ask Tauf to remind David of the exact podspec-constraint fix path used in similar cases, then document that process for future reuse.
-- After the dependency constraint issue is resolved, update the Fid4 Podfile in `ap010981-ios-flagship-app`, run `tuist generate -n` and `pod install --repo-update`, then open the consumer PR.
+- Resolve the Fid4 dependency conflict through the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
+- The podspec-repo PR was sent to Tauf and approved.
+- After that merge, `pod install --repo-update` in Fid4 worked because the published podspecs no longer restricted the XFlowViewMaker version.
+- Continue with the consumer PR/update path now that dependency resolution is unblocked.
 - After the Fid4 PR merges, treat the app release as the final downstream step before broader user visibility.
 - Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of the client-fix scope unless later evidence proves it is part of the same issue.
 - Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after consumer confirmation.

vault/03-context/systems/ftframeworks.md

@@ -37,6 +37,8 @@ FTFrameworks contains consumer-side feature modules such as FTAccountOpen, FTTra
   - Fid4
 - Test failures or publishing issues in FT modules can delay consumer validation even when the core XFlow change is ready.
 - FTFrameworks code-owner approval can also be a practical gate when the XFlowViewMaker update PR lives inside the shared `PR100660-ios-frameworks` monorepo.
+- In the current XFlowViewMaker propagation pattern, effective downstream constraints may be enforced in the podspec repo rather than the FTFrameworks source repo itself.
+- A successful Fid4 upgrade required removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs in the podspec repo, then rerunning `pod install --repo-update`.
 
 ---
 

vault/03-context/workstreams/consumer-integration.md

@@ -91,6 +91,10 @@ Capture the durable release and validation path between XFlow changes and real c
 - Even those checks are not perfect guarantees because the podspec repo can be edited after publication.
 - A newly published XFlowViewMaker version can still be blocked in Fid4 if downstream podspec constraints in `FTAccountOpen` or `FTTransfer` do not yet accept the new adapter version.
 - Historical/current evidence suggests Tauf has resolved similar propagation blocks by updating the relevant constraint directly in the podspec repo.
+- Current evidence suggests the effective constraint may live in the podspec repo layer rather than in the FTFrameworks source repo itself.
+- For the current XFlowViewMaker propagation issue, the practical fix was made in the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
+- After that podspec-repo PR was merged, `pod install --repo-update` in Fid4 resolved successfully because those podspecs no longer constrained the XFlowViewMaker version.
+- `FTAccountOpen` and `FTTransfer` do not appear to hold a direct XFlowViewMaker version reference in their checked FTFrameworks source podspec files; the effective resolution is managed through the published podspec layer and `ftAdapter` behavior.
 
 ---
 

vault/04-people/tauf.md

@@ -34,6 +34,7 @@ updated: 2026-04-17
 - David has seen podspec-repo edits happen after publication and specifically called out Tauf as someone involved in CI support around that ecosystem.
 - Often referred to informally as `Tauf`.
 - Fidelity Teams may show names in a surname-first style, so this person may appear under a different display order there.
+- In the current XFlowViewMaker propagation issue, Tauf clarified that the needed fix belongs in the podspec repo rather than FTFrameworks source, and pointed David toward removing the XFlowViewMaker version constraint for `ftaccountopen`.
 
 ---
 

vault/06-daily/2026-04-17.md

@@ -52,6 +52,13 @@ tags:
 - The conflict appears to come from `FTAccountOpen` and `FTTransfer` depending on XFlowViewMaker with constraints that do not yet allow the new version.
 - David noted that Tauf has handled similar cases before by updating the constraint directly in the podspec repo.
 - Jeff asked David to message Tauf, ask him to remind David what he does in this case, and then document the process for future reference.
+- Follow-up Teams evidence from Tauf clarified the practical fix path:
+- first try `pod install`
+- if resolution still does not move to the latest XFlowViewMaker version, the change belongs in the podspec repo, not in FTFrameworks
+- `FTAccountOpen` and `FTTransfer` do not appear to hold a direct XFlowViewMaker version reference in their FTFrameworks source podspec files; the effective versioning is handled through the published podspec layer and the `ftAdapter` function
+- David later clarified the actual fix: in the podspec repo PR, he removed the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs
+- Tauf approved that podspec-repo PR
+- After that merge, `pod install --repo-update` worked in Fid4 because the published podspecs no longer constrained the XFlowViewMaker version
 
 ## Communication Correction