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

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.