From 27b86158a687686aa76f9d42bd5fcaf4a4b5a25e Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Fri, 17 Apr 2026 09:32:08 -0600 Subject: [PATCH] feat: Update work items and documentation for improved release propagation clarity and system dependencies --- vault/01-current/work-items.md | 2 +- vault/02-work-items/pdiap-15765.md | 11 ++-- vault/03-context/systems/fid4.md | 13 ++++- vault/03-context/systems/ftframeworks.md | 7 ++- vault/03-context/systems/xflowsdk.md | 13 ++++- vault/03-context/systems/xflowviewmaker.md | 22 +++++++- .../workstreams/consumer-integration.md | 56 ++++++++++++++++++- vault/04-people/index.md | 5 +- vault/04-people/tauf.md | 40 +++++++++++++ vault/06-daily/2026-04-17.md | 13 +++++ 10 files changed, 164 insertions(+), 18 deletions(-) create mode 100644 vault/04-people/tauf.md diff --git a/vault/01-current/work-items.md b/vault/01-current/work-items.md index b86142d..147681a 100644 --- a/vault/01-current/work-items.md +++ b/vault/01-current/work-items.md @@ -32,4 +32,4 @@ Update the per-ticket files first when scope, status, sequencing, or communicati - `PDIAP-15765` - AO DOB field error not showing investigation Detail: `vault/02-work-items/pdiap-15765.md` - Current note: the small XFlowSDK iOS `birthDate` fallback was merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up PR is open and partially approved but still needs one FTFrameworks code-owner approval before merge, then the pipeline and Fid4 update still need to happen. + Current note: the small XFlowSDK iOS `birthDate` compatibility fix was merged and released in XFlow `2.8.48`; the XFlowViewMaker follow-up PR is open and partially approved but still needs one FTFrameworks code-owner approval before merge. After that, `publish-XFlowViewMaker` must release the adapter, then Fid4 must update its Podfile and merge the consumer PR so the change propagates through the real app path. diff --git a/vault/02-work-items/pdiap-15765.md b/vault/02-work-items/pdiap-15765.md index 6707baf..7e3b509 100644 --- a/vault/02-work-items/pdiap-15765.md +++ b/vault/02-work-items/pdiap-15765.md @@ -4,10 +4,10 @@ project: fidelity status: active ticket: PDIAP-15765 title: "AO DOB field error not showing investigation" -systems: [xflowsdk, fid4, cogstore] -workstreams: [ao-discourse, xflow-debugging] +systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4, cogstore] +workstreams: [ao-discourse, xflow-debugging, consumer-integration] people: [jeff-dewitte, gurram-santosh, raj-sundararaj] -related: [] +related: [pdiap-15838] updated: 2026-04-17 tags: - work-item @@ -71,7 +71,8 @@ tags: ## Next Step - Get the remaining FTFrameworks code-owner approval on the XFlowViewMaker follow-up PR. -- Run the remaining pipeline/release steps after the PR merges. -- Update Fid4 so the released XFlow `2.8.48` change propagates through the consumer path. +- After merge, let `publish-XFlowViewMaker` release the updated adapter version. +- Update the Fid4 Podfile in `ap010981-ios-flagship-app`, run `tuist generate -n` and `pod install --repo-update`, then open the consumer PR. +- 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/fid4.md b/vault/03-context/systems/fid4.md index a085f8a..380e360 100644 --- a/vault/03-context/systems/fid4.md +++ b/vault/03-context/systems/fid4.md @@ -3,8 +3,8 @@ type: system project: fidelity status: active workstreams: [consumer-integration, xflow-debugging, ao-discourse, xflow-swiftui-migration] -related: [xflowsdk, xflowviewmaker, ftframeworks, cogstore] -updated: 2026-04-16 +related: [xflowsdk, xflowviewmaker, ftframeworks, cogstore, consumer-integration] +updated: 2026-04-17 tags: - system - fidelity @@ -23,6 +23,7 @@ Fid4 is the main Fidelity consumer iOS app and the most important environment fo - Validation in Fid4 often reveals issues that do not appear in XFlowSDK isolation or sample apps. - Historical Slack context shows that some tickets were incorrectly scoped until behavior was checked in Fid4 or flagship. - Real consumer testing in Fid4 matters for modal presentation, validation messaging, and backend-driven flow behavior. +- Fid4 currently consumes XFlow through XFlowViewMaker rather than depending on XFlowSDK directly. --- @@ -31,6 +32,14 @@ Fid4 is the main Fidelity consumer iOS app and the most important environment fo - If an issue depends on real flow behavior, do not assume XFlow-only validation is sufficient. - When a story touches presentation, entry points, or consumer behavior, check whether Fid4 is required to confirm scope. - Build or startup instability in Fid4 can slow validation and should be treated as a practical investigation constraint. +- Fid4 currently adopts XFlow changes through the app repo `ap010981-ios-flagship-app` after XFlowViewMaker has been published. +- The common update path is: + - modify the Podfile to the new XFlowViewMaker version + - run `tuist generate -n` + - run `pod install --repo-update` + - open and merge a PR + - wait for the consumer team to carry the change forward in their normal App Store release flow +- `Podfile.lock` is currently ignored in the Fid4 repo, so version verification often depends on Podfile references or published pipeline artifacts instead of Git-tracked lockfiles. --- diff --git a/vault/03-context/systems/ftframeworks.md b/vault/03-context/systems/ftframeworks.md index caae646..2fa0d8e 100644 --- a/vault/03-context/systems/ftframeworks.md +++ b/vault/03-context/systems/ftframeworks.md @@ -3,8 +3,8 @@ type: system project: fidelity status: active workstreams: [consumer-integration, xflow-swiftui-migration] -related: [fid4, xflowsdk, xflowviewmaker, pdiap-14859, pdiap-15836] -updated: 2026-04-16 +related: [fid4, xflowsdk, xflowviewmaker, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836] +updated: 2026-04-17 tags: - system - fidelity @@ -22,6 +22,8 @@ FTFrameworks contains consumer-side feature modules such as FTAccountOpen, FTTra - FTFrameworks is often part of the real validation and release chain, not just a downstream detail. - Historical Slack context shows pinned FT module versions repeatedly blocking adoption of newer XFlow or XFlowViewMaker changes in Fid4. - Changes to XFlow often needed corresponding FTAccountOpen or FTTransfer updates before end-to-end testing was realistic. +- `FTAccountOpen` and `FTTransfer` consume XFlow through XFlowViewMaker rather than directly from XFlowSDK. +- For Account Opening flows, the current path is understood to go through `FTAccountOpen`. --- @@ -34,6 +36,7 @@ FTFrameworks contains consumer-side feature modules such as FTAccountOpen, FTTra - FTAccountOpen / FTTransfer - 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. --- diff --git a/vault/03-context/systems/xflowsdk.md b/vault/03-context/systems/xflowsdk.md index f871790..50b9bfd 100644 --- a/vault/03-context/systems/xflowsdk.md +++ b/vault/03-context/systems/xflowsdk.md @@ -3,8 +3,8 @@ type: system project: fidelity status: active workstreams: [rest-migration, ao-discourse, xflow-debugging, xflow-swiftui-migration, consumer-integration] -related: [fid4, xflowviewmaker, ftframeworks, cogstore, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838] -updated: 2026-04-16 +related: [fid4, xflowviewmaker, ftframeworks, cogstore, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838] +updated: 2026-04-17 tags: - system - fidelity @@ -21,6 +21,7 @@ XFlowSDK is the backend-driven UI engine that renders Fidelity flows from servic - XFlow behavior depends on backend rules, entry point, and authentication state. - SwiftUI migration work introduced recurring behavior questions that were not just visual; many were contract or lifecycle issues. +- XFlowSDK is developed in the dedicated repository `pr100660-xflow-for-ios`. - Historical Slack patterns show recurring topics around: - component type expansion in SwiftUI - Next-button visibility rules @@ -30,6 +31,14 @@ XFlowSDK is the backend-driven UI engine that renders Fidelity flows from servic --- +## Release Mechanics + +- XFlowSDK publishing currently uses the Jenkins pipeline `xflow-for-ios-publish`. +- The publish flow builds the XCFramework, publishes it to internal Fidelity Artifactory at `artifactory.fmr.com`, and publishes the podspec to `ap010981-ios_podspecs_3x`. +- Once published, the new SDK version can be adopted downstream through `pod install` or `pod update`, but consumer validation still depends on XFlowViewMaker and Fid4 propagation. + +--- + ## Debugging Implications - Do not treat XFlow output as static UI; backend configuration can change the result. diff --git a/vault/03-context/systems/xflowviewmaker.md b/vault/03-context/systems/xflowviewmaker.md index 555561d..618f9b1 100644 --- a/vault/03-context/systems/xflowviewmaker.md +++ b/vault/03-context/systems/xflowviewmaker.md @@ -3,8 +3,8 @@ type: system project: fidelity status: active workstreams: [consumer-integration, xflow-swiftui-migration] -related: [xflowsdk, fid4, ftframeworks, pdiap-14859, pdiap-15836] -updated: 2026-04-16 +related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836] +updated: 2026-04-17 tags: - system - fidelity @@ -22,6 +22,23 @@ XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework - Historical release work often required bumping XFlowViewMaker alongside XFlowSDK before consumer validation was possible. - XFlowViewMaker was a recurring source of coupling between XFlow changes and Fid4 or flagship rollout. - Historical Slack evidence shows that version bumps through XFlowViewMaker were often blocked by external pipeline or dependency issues rather than pure feature regressions. +- XFlowViewMaker currently lives in the monorepo `PR100660-ios-frameworks` under `Adapters/XFlowViewMaker`. + +--- + +## Release Mechanics + +- When XFlowSDK releases a new version, XFlowViewMaker usually needs a follow-up dependency bump before Fid4 can consume the change. +- The common release flow is: + - update the XFlowViewMaker podspec to the new XFlowSDK version + - run `tuist generate -n` + - run `pod install` + - open a PR + - wait for required approvals, including protected-branch/code-owner approval when applicable + - merge, often through automerge once approvals are complete + - let the Jenkins pipeline `publish-XFlowViewMaker` publish the adapter release +- `publish-XFlowViewMaker` usually auto-detects the next version and commonly increments the minor version automatically. +- The publish flow distributes the new adapter version through Artifactory/podspec channels and updates the XFlowViewMaker version on `main`. --- @@ -29,6 +46,7 @@ XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework - When a fix exists in XFlowSDK but is not visible in consumer validation, check whether XFlowViewMaker or downstream pinned versions are blocking adoption. - If the issue involves version propagation into Fid4, treat XFlowViewMaker as part of the release path unless direct-consumption work has replaced it. +- Current understanding is that Fid4 does not consume XFlowSDK directly; XFlowViewMaker remains the required integration layer for Fid4 and for other consumers such as `FTAccountOpen` and `FTTransfer`. - Questions about removing or collapsing the layer should be evaluated against current consumer integration patterns, not just local SDK behavior. --- diff --git a/vault/03-context/workstreams/consumer-integration.md b/vault/03-context/workstreams/consumer-integration.md index 3b8b52c..3bb2984 100644 --- a/vault/03-context/workstreams/consumer-integration.md +++ b/vault/03-context/workstreams/consumer-integration.md @@ -3,9 +3,9 @@ type: workstream project: fidelity status: active systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4] -work-items: [pdiap-14859, pdiap-15836] -related: [xflow-swiftui-migration, xflow-debugging] -updated: 2026-04-16 +work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838] +related: [xflow-swiftui-migration, xflow-debugging, xflowsdk, xflowviewmaker, ftframeworks, fid4] +updated: 2026-04-17 tags: - workstream - fidelity @@ -30,15 +30,65 @@ Capture the durable release and validation path between XFlow changes and real c --- +## Current Release Propagation Model + +- The current release path is usually: + - `pr100660-xflow-for-ios` releases XFlowSDK + - `PR100660-ios-frameworks/Adapters/XFlowViewMaker` updates to that XFlowSDK version and publishes a new XFlowViewMaker release + - `ap010981-ios-flagship-app` updates Fid4 to the new XFlowViewMaker version + - 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. +- 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`. + +--- + +## Step-By-Step Propagation + +1. Release XFlowSDK from `pr100660-xflow-for-ios`. + - Jenkins pipeline: `xflow-for-ios-publish` + - Produces the XCFramework artifact + - Publishes to internal Fidelity Artifactory at `artifactory.fmr.com` + - Publishes the podspec to the dedicated podspec repo `ap010981-ios_podspecs_3x` + - After publication, consumers can adopt the new SDK version through CocoaPods +2. Update and release XFlowViewMaker from `PR100660-ios-frameworks`. + - XFlowViewMaker lives in `Adapters/XFlowViewMaker` + - Update the XFlowViewMaker podspec to the new XFlowSDK version + - Run `tuist generate -n` + - Run `pod install` + - Open a PR and get required approvals + - Ping code owners when protected-branch approval is the remaining blocker + - After merge, the `publish-XFlowViewMaker` Jenkins pipeline publishes the adapter + - That pipeline usually auto-detects the next release and commonly auto-increments the minor version, for example `0.5.0` -> `0.6.0` + - Publication updates Artifactory/podspec distribution and also updates the XFlowViewMaker version on `main` +3. Update Fid4 in `ap010981-ios-flagship-app`. + - Modify the Podfile to consume the new XFlowViewMaker version + - Run `tuist generate -n` + - Run `pod install --repo-update` + - Open a PR and get approvals + - After merge, the consumer team owns the final application release to the App Store + +--- + ## Investigation Rules - Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream. +- When the question is specifically about Account Opening, verify the path through `FTAccountOpen` before assuming a direct Fid4-only dependency view is sufficient. - Separate these failure modes: - SDK bug - adapter/version propagation issue + - protected-branch or code-owner approval delay + - publish pipeline failure or auto-versioning surprise - FT module publish/test issue - consumer app setup or pipeline issue - Consumer validation constraints should shape story scope and estimates because they can dominate the real effort. +- Version verification in Fid4 is not always straightforward because `Podfile.lock` is currently ignored in the app repo. +- The fastest reliable signals are: + - fixed version references in the Podfile when present + - archived pipeline artifacts such as `xcarchive` outputs and captured `Podfile.lock` files +- Even those checks are not perfect guarantees because the podspec repo can be edited after publication. --- diff --git a/vault/04-people/index.md b/vault/04-people/index.md index e47250d..69aa36e 100644 --- a/vault/04-people/index.md +++ b/vault/04-people/index.md @@ -1,7 +1,7 @@ --- type: people-index project: fidelity -updated: 2026-04-16 +updated: 2026-04-17 tags: - people - map @@ -50,6 +50,9 @@ tags: - [derian-cordoba.md](./derian-cordoba.md) Historical collaborator in pipeline and documentation work, especially around CI/CD support and operational notes. +- [tauf.md](./tauf.md) + CI/Jenkins support contact who helps with release-pipeline troubleshooting and related publication issues. + ## Usage When a person appears repeatedly in project communication, create or update their file here so the agent can reuse: diff --git a/vault/04-people/tauf.md b/vault/04-people/tauf.md new file mode 100644 index 0000000..013b93c --- /dev/null +++ b/vault/04-people/tauf.md @@ -0,0 +1,40 @@ +--- +type: person +project: fidelity +role: CI and Jenkins support +status: active +teams: [ci-cd, ios-frameworks] +topics: [jenkins, pipelines, podspec-publication, release-support] +related: [consumer-integration, pdiap-15765] +tags: + - person + - fidelity +updated: 2026-04-17 +--- + +# Tauf + +## Role + +- CI / Jenkins support contact who helps unblock pipeline and publication issues. + +--- + +## Collaboration Pattern + +- David reaches out to Tauf when Jenkins or release-pipeline steps need support, especially around XFlowViewMaker publication or approval/pipeline follow-through. +- Tauf has been specifically relevant to the `PDIAP-15765` propagation work because David planned to ping him about the remaining XFlowViewMaker approval path. + +--- + +## Communication Notes + +- Useful contact for operational release and pipeline troubleshooting. +- David has seen podspec-repo edits happen after publication and specifically called out Tauf as someone involved in CI support around that ecosystem. + +--- + +## Related Context + +- `vault/03-context/workstreams/consumer-integration.md` +- `vault/02-work-items/pdiap-15765.md` diff --git a/vault/06-daily/2026-04-17.md b/vault/06-daily/2026-04-17.md index 1b6144b..1c7d100 100644 --- a/vault/06-daily/2026-04-17.md +++ b/vault/06-daily/2026-04-17.md @@ -26,3 +26,16 @@ tags: - Jeff said not to use `fallback` in the standup wording because a broader audience will not understand that term without extra context; prefer plain outcome wording like `Got the PR approved`. - Jeff clarified that when `PDIAP-15765` is waiting on approvals or pipeline movement, the standup should explicitly say David is returning to GraphQL removal work rather than sounding like the day is blocked on waiting. - David updated the standup wording with those changes and sent the final version. + +## Learning Session - Release Propagation + +- David clarified the current release propagation chain for XFlow changes. +- XFlowSDK is released from `pr100660-xflow-for-ios` through Jenkins pipeline `xflow-for-ios-publish`, which builds the XCFramework, publishes it to `artifactory.fmr.com`, and publishes the podspec to `ap010981-ios_podspecs_3x`. +- XFlowViewMaker lives in `PR100660-ios-frameworks/Adapters/XFlowViewMaker`; after an XFlowSDK release, its podspec must be updated, then `tuist generate -n`, `pod install`, PR review, protected-branch/code-owner approval, merge, and `publish-XFlowViewMaker` publication are required. +- The XFlowViewMaker publish pipeline usually auto-detects the next release and commonly auto-increments the minor version. +- Fid4 then consumes the new XFlowViewMaker version from `ap010981-ios-flagship-app` by updating the Podfile, running `tuist generate -n` and `pod install --repo-update`, opening a PR, and merging it before the downstream app release process carries the change to users. +- This release chain is durable context for understanding why an XFlowSDK fix can be merged and released but still not be visible yet in Fid4. +- David clarified that Fid4 consumes XFlow only through XFlowViewMaker, not directly through XFlowSDK. +- David also clarified that other frameworks such as `FTAccountOpen` and `FTTransfer` use XFlowViewMaker, and the practical Account Opening path is currently understood to go through `FTAccountOpen`. +- Version verification in Fid4 is imperfect because `Podfile.lock` is ignored in the repo; fixed Podfile references and pipeline artifacts can help verify released versions, but podspec-repo edits can still change what gets resolved later. +- Tauf was identified as a CI/Jenkins support contact who has helped with pipeline issues in the past.