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

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

Browse Source
This commit is contained in:
David Delagneau
2026-04-17 11:22:22 -06:00
parent 01f0a6bd33
commit 926433aa13
5 changed files with 18 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

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