---
type: daily
project: fidelity
date: 2026-04-17
focus: [ao-discourse, consumer-integration, rest-migration]
work-items: [pdiap-15765, pdiap-15838]
blockers: [xflowviewmaker-code-owner-approval]
updated: 2026-04-17
tags:
  - daily
  - fidelity
---
# 2026-04-17

## Standup Draft Clarification

- David clarified that the XFlowViewMaker follow-up work for `PDIAP-15765` is further along than the earlier summary implied.
- The XFlowViewMaker PR is already open and has some approvals.
- One FTFrameworks code-owner approval is still required before the PR can merge.
- After that approval, the remaining work is to run the pipeline and update Fid4 so the XFlow `2.8.48` change propagates through the consumer path.
- `PDIAP-15838` remains the next story after the `PDIAP-15765` propagation steps are in a good place.
- David's current plan is to ping Tauf for that remaining approval.

## Standup Wording Feedback

- 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.
- David clarified that Tauf's full name is `Taufiqur Ashrafy`; he is often referred to informally as `Tauf`.
- David also noted that Fidelity Teams may display people in surname-first order, which can make person matching less obvious across tools.