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

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

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

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.

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