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

feat: Update work items and documentation for improved release propagation clarity and system dependencies

Browse Source
This commit is contained in:
David Delagneau
2026-04-17 09:32:08 -06:00
parent e604115335
commit 27b86158a6
10 changed files with 164 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
vault/01-current/work-items.md
View File

@@ -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 - `PDIAP-15765` - AO DOB field error not showing investigation
Detail: `vault/02-work-items/pdiap-15765.md` 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.

11
vault/02-work-items/pdiap-15765.md
View File

@@ -4,10 +4,10 @@ project: fidelity
status: active status: active
ticket: PDIAP-15765 ticket: PDIAP-15765
title: "AO DOB field error not showing investigation" title: "AO DOB field error not showing investigation"
systems: [xflowsdk, fid4, cogstore] systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4, cogstore]
workstreams: [ao-discourse, xflow-debugging] workstreams: [ao-discourse, xflow-debugging, consumer-integration]
people: [jeff-dewitte, gurram-santosh, raj-sundararaj] people: [jeff-dewitte, gurram-santosh, raj-sundararaj]
related: [] related: [pdiap-15838]
updated: 2026-04-17 updated: 2026-04-17
tags: tags:
- work-item - work-item
@@ -71,7 +71,8 @@ tags:
## Next Step ## Next Step
- Get the remaining FTFrameworks code-owner approval on the XFlowViewMaker follow-up PR. - Get the remaining FTFrameworks code-owner approval on the XFlowViewMaker follow-up PR.
- Run the remaining pipeline/release steps after the PR merges. - After merge, let `publish-XFlowViewMaker` release the updated adapter version.
- Update Fid4 so the released XFlow `2.8.48` change propagates through the consumer path. - 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. - 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. - Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after consumer confirmation.

13
vault/03-context/systems/fid4.md
View File

@@ -3,8 +3,8 @@ type: system
project: fidelity project: fidelity
status: active status: active
workstreams: [consumer-integration, xflow-debugging, ao-discourse, xflow-swiftui-migration] workstreams: [consumer-integration, xflow-debugging, ao-discourse, xflow-swiftui-migration]
related: [xflowsdk, xflowviewmaker, ftframeworks, cogstore] related: [xflowsdk, xflowviewmaker, ftframeworks, cogstore, consumer-integration]
updated: 2026-04-16 updated: 2026-04-17
tags: tags:
- system - system
- fidelity - 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. - 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. - 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. - 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. - 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. - 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. - 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.
--- ---

7
vault/03-context/systems/ftframeworks.md
View File

@@ -3,8 +3,8 @@ type: system
project: fidelity project: fidelity
status: active status: active
workstreams: [consumer-integration, xflow-swiftui-migration] workstreams: [consumer-integration, xflow-swiftui-migration]
related: [fid4, xflowsdk, xflowviewmaker, pdiap-14859, pdiap-15836] related: [fid4, xflowsdk, xflowviewmaker, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
updated: 2026-04-16 updated: 2026-04-17
tags: tags:
- system - system
- fidelity - 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. - 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. - 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. - 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 - FTAccountOpen / FTTransfer
- Fid4 - Fid4
- Test failures or publishing issues in FT modules can delay consumer validation even when the core XFlow change is ready. - 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.
--- ---

13
vault/03-context/systems/xflowsdk.md
View File

@@ -3,8 +3,8 @@ type: system
project: fidelity project: fidelity
status: active status: active
workstreams: [rest-migration, ao-discourse, xflow-debugging, xflow-swiftui-migration, consumer-integration] 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] related: [fid4, xflowviewmaker, ftframeworks, cogstore, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
updated: 2026-04-16 updated: 2026-04-17
tags: tags:
- system - system
- fidelity - 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. - 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. - 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: - Historical Slack patterns show recurring topics around:
- component type expansion in SwiftUI - component type expansion in SwiftUI
- Next-button visibility rules - 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 ## Debugging Implications
- Do not treat XFlow output as static UI; backend configuration can change the result. - Do not treat XFlow output as static UI; backend configuration can change the result.

22
vault/03-context/systems/xflowviewmaker.md
View File

@@ -3,8 +3,8 @@ type: system
project: fidelity project: fidelity
status: active status: active
workstreams: [consumer-integration, xflow-swiftui-migration] workstreams: [consumer-integration, xflow-swiftui-migration]
related: [xflowsdk, fid4, ftframeworks, pdiap-14859, pdiap-15836] related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
updated: 2026-04-16 updated: 2026-04-17
tags: tags:
- system - system
- fidelity - 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. - 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. - 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. - 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. - 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. - 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. - Questions about removing or collapsing the layer should be evaluated against current consumer integration patterns, not just local SDK behavior.
--- ---

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

@@ -3,9 +3,9 @@ type: workstream
project: fidelity project: fidelity
status: active status: active
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4] systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
work-items: [pdiap-14859, pdiap-15836] work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
related: [xflow-swiftui-migration, xflow-debugging] related: [xflow-swiftui-migration, xflow-debugging, xflowsdk, xflowviewmaker, ftframeworks, fid4]
updated: 2026-04-16 updated: 2026-04-17
tags: tags:
- workstream - workstream
- fidelity - 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 ## Investigation Rules
- Before concluding a fix is absent in Fid4, check whether the right version actually propagated downstream. - 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: - Separate these failure modes:
- SDK bug - SDK bug
- adapter/version propagation issue - adapter/version propagation issue
- protected-branch or code-owner approval delay
- publish pipeline failure or auto-versioning surprise
- FT module publish/test issue - FT module publish/test issue
- consumer app setup or pipeline issue - consumer app setup or pipeline issue
- Consumer validation constraints should shape story scope and estimates because they can dominate the real effort. - 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.
--- ---

5
vault/04-people/index.md
View File

@@ -1,7 +1,7 @@
--- ---
type: people-index type: people-index
project: fidelity project: fidelity
updated: 2026-04-16 updated: 2026-04-17
tags: tags:
- people - people
- map - map
@@ -50,6 +50,9 @@ tags:
- [derian-cordoba.md](./derian-cordoba.md) - [derian-cordoba.md](./derian-cordoba.md)
Historical collaborator in pipeline and documentation work, especially around CI/CD support and operational notes. 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 ## Usage
When a person appears repeatedly in project communication, create or update their file here so the agent can reuse: When a person appears repeatedly in project communication, create or update their file here so the agent can reuse:

40
vault/04-people/tauf.md Normal file
View File

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

13
vault/06-daily/2026-04-17.md
View File

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