fidelity-ai-workspace/project-knowledge/06-daily/2026-04-17.md

type, project, date, focus, work-items, blockers, updated, tags

type	project	date	focus	work-items	blockers	updated	tags
daily	fidelity	2026-04-17	ao-discourse consumer-integration rest-migration	pdiap-15765 pdiap-15838		2026-04-17	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.
• David clarified that the surname-first display in Fidelity Teams is consistent for everyone.
• David also clarified that Teams and Mattermost represent different social contexts; outside of Jeff, people seen in Teams are generally not the same people David interacts with through Mattermost.
• David corrected current people status: Norman Arauz and Derian Cordoba no longer work with the current All-Win Software / Mattermost / Slack group, and Erik Reynolds previously worked for Fidelity but no longer does.
• David clarified an important working-context rule: Jeff is the only person who regularly communicates with Fidelity-side Teams stakeholders, while David works from the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side.

Mattermost Refresh - Dependency Conflict

• After XFlowViewMaker was published, David hit a dependency conflict while trying to update Fid4.
• The conflict appears to come from FTAccountOpen and FTTransfer depending on XFlowViewMaker with constraints that do not yet allow the new version.
• David noted that Tauf has handled similar cases before by updating the constraint directly in the podspec repo.
• Jeff asked David to message Tauf, ask him to remind David what he does in this case, and then document the process for future reference.
• Follow-up Teams evidence from Tauf clarified the practical fix path:
• first try pod install
• if resolution still does not move to the latest XFlowViewMaker version, the change belongs in the podspec repo, not in FTFrameworks
• FTAccountOpen and FTTransfer do not appear to hold a direct XFlowViewMaker version reference in their FTFrameworks source podspec files; the effective versioning is handled through the published podspec layer and the ftAdapter function
• David later clarified the actual fix: in the podspec repo PR, he removed the XFlowViewMaker version reference from both the latest FTAccountOpen and FTTransfer podspecs
• Tauf approved that podspec-repo PR
• After that merge, pod install --repo-update worked in Fid4 because the published podspecs no longer constrained the XFlowViewMaker version

Mattermost Refresh - Release Progress

• The remaining XFlowViewMaker code-owner approval was obtained from Tauf, allowing the release process to continue.
• The XFlowViewMaker release was published successfully.
• David then opened the Fid4 PR with the latest versions and planned to request reviews from Santosh and Tauf.

Mattermost Refresh - Urgent REST Validation

• Jeff redirected work to an urgent consumer report claiming REST calls were failing on iOS when the toggle was enabled.
• David clarified that David does not have access to Flagship LaunchDarkly projects; only the sample app LD project is available from David's side.
• David tested locally on main and reported that REST loaded correctly with the iOS-XflowRestEnabled flag enabled.
• David also verified that XFlow 2.8.47 already supports that flag and is present in the 4.30 line used for consumer validation.
• David later verified on the release/4.30 branch that the behavior still looked correct there.
• Current working hypothesis: the consumer report may reflect a version mismatch or incorrect flag configuration rather than a reproducible iOS REST failure in current local validation.
• Adam's trunk build reference appears to mean a real-device build platform that can provide downloadable App Store/internal IPAs and a dependency snapshot such as Podfile.lock, even though David cannot run those IPAs on simulators.

Communication Correction

• David corrected a drafting mistake: when proposing a message that David will send directly to a Fidelity-side contact, the wording must not imply Jeff is the sender or that the recipient already knows David through Jeff.
• For this kind of direct outreach, avoid phrases like Jeff mentioned... unless David explicitly wants that framing.
• David made a second correction: if Jeff asked for internal documentation or future-process capture, that should stay internal and should not be surfaced in David's external message unless explicitly requested.

Mattermost Refresh - Dependency Reproduction Caution

• Jeff asked David to compare against the dependency snapshot from the device-oriented trunk build context to reduce uncertainty about the reported REST behavior.
• David noted that downloading the referenced Podfile.lock and running pod install is a useful approximation, but still not a full guarantee if the private podspec repo changed after that build was produced.
• If exact dependency reproduction is required, the stronger path is to also check out the podspec repo at the matching earlier revision instead of relying on Podfile.lock alone.

Learning Correction - Build Inspection Sources

• David clarified that iosinstaller is one of Fidelity's internal apps for inspecting distributed consumer builds.
• iosinstaller can download App Store and internal builds and also expose the corresponding Podfile.lock.
• David also clarified a useful app-store debugging path in the Flagship app pipeline: the artifact appstore/DistributionSummary.plist records the framework versions installed for that build.
• That artifact can be used to confirm which XFlowViewMaker and XFlow versions were actually installed in a specific App Store build.