From 926433aa132b61e6030fc1fa3d05ebef870034b8 Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Fri, 17 Apr 2026 11:22:22 -0600 Subject: [PATCH] feat: Document resolution process for Fid4 dependency conflict and clarify XFlowViewMaker versioning in podspec repo --- vault/02-work-items/pdiap-15765.md | 7 ++++--- vault/03-context/systems/ftframeworks.md | 2 ++ vault/03-context/workstreams/consumer-integration.md | 4 ++++ vault/04-people/tauf.md | 1 + vault/06-daily/2026-04-17.md | 7 +++++++ 5 files changed, 18 insertions(+), 3 deletions(-) diff --git a/vault/02-work-items/pdiap-15765.md b/vault/02-work-items/pdiap-15765.md index da526e2..84e9c6d 100644 --- a/vault/02-work-items/pdiap-15765.md +++ b/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. diff --git a/vault/03-context/systems/ftframeworks.md b/vault/03-context/systems/ftframeworks.md index 2fa0d8e..fe77ccd 100644 --- a/vault/03-context/systems/ftframeworks.md +++ b/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`. --- diff --git a/vault/03-context/workstreams/consumer-integration.md b/vault/03-context/workstreams/consumer-integration.md index 7a24fd0..0d832d7 100644 --- a/vault/03-context/workstreams/consumer-integration.md +++ b/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. --- diff --git a/vault/04-people/tauf.md b/vault/04-people/tauf.md index bb21820..6a5d559 100644 --- a/vault/04-people/tauf.md +++ b/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`. --- diff --git a/vault/06-daily/2026-04-17.md b/vault/06-daily/2026-04-17.md index 059d992..ebda28d 100644 --- a/vault/06-daily/2026-04-17.md +++ b/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