---
type: current
project: fidelity
status: active
updated: 2026-05-14
tags:
  - current-work
  - fidelity
---
# Current Work

## Focus

- Keep Fidelity context current from daily work performed on another machine
- Track REST migration findings
- Debug Discourse and AO issues
- Prepare better updates for the current manager or stakeholder through Mattermost
- Follow up on active tickets through `workspaces/fidelity/project-knowledge/02-work-items/`, especially branch maintenance for `PDIAP-15838` and implementation planning for `PDIAP-15836` / `PDIAP-12284`
- `PDIAP-15765` is done and `PDIAP-14859` is also done
- `PDIAP-15838` is Done from a Jira/status perspective after external review feedback was addressed, but its draft PR must remain unmerged and kept current with `main` until REST backend production readiness and the required REST-toggle consumer validation window allow merge
- `PDIAP-15836` has moved to In Progress. David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, but Jeff directed David to do the `PDIAP-15836` dismissal/lifecycle work and `PDIAP-12284` UIKit-removal work in the same branch because both are disruptive enough to require consumer testing.
- `PDIAP-12284` remains paired with `PDIAP-15836`; plan the branch as combined UIKit-removal / SwiftUI lifecycle work rather than splitting the dismissal sequencing into an independently merged path unless direction changes.
- Current `PDIAP-12284` implementation direction is to explore XFlowViewMaker-owned global host-mode resolution rather than Fid4-owned per-flow host-mode mapping: SwiftUI host should remain the default, missing/unknown feature configuration should also default to SwiftUI, and `UIHostingController` should be selected only through an explicit temporary fallback flag.
- Keep host-mode resolution decoupled from XFlowSDK and app-specific LaunchDarkly/Flagship clients; XFlowSDK should consume a resolved host-mode decision, while Copilot/code inspection should confirm whether XFlowViewMaker can use existing `FeatureEnabling` / `Featuring` abstractions or needs a small dependency-injection path.
- May 12 implementation pass for `PDIAP-12284` / `PDIAP-15836` indicates the host-mode API is branch-local/new, keeps two enum types to preserve the XFlowViewMaker/XFlowSDK boundary, uses neutral `swiftUIHost` / `uiKitHost` cases, sets the feature flag key to `iOS-XflowUIKitHostEnabled`, defaults missing/false/unavailable values to SwiftUI, and removes `AnyView` from `buildFlow` internals while leaving it only at the existing public `FlowViewMaker` boundary.
- Current compile validation blocker for that branch appears to be dependency alignment: XFlowViewMaker's podspec resolves `XFlowSDK 2.8.48`, which does not expose the new host-mode API; XFlowSDK SwiftPM validation is also blocked in the current environment by missing `fidelity-src` registry configuration.
- After manual dependency/build handling, Fid4 now compiles with the latest `FlowViewBuilder` shape. Next validation should be runtime log evidence: confirm a representative flow selects the default SwiftUI host path, then simulate/force `iOS-XflowUIKitHostEnabled == true` to confirm the temporary UIKit host path and dismissal-completion behavior.
- `PDIAP-12284` moved to In Progress on May 12. Quy confirmed on May 13 that `PDIAP-12284` and `PDIAP-15836` can both remain In Progress together, so no immediate Jira restructuring is required.
- Latest `PDIAP-12284` / `PDIAP-15836` simulator log review suggests the SwiftUI-host dismissal sequence is firing in the intended order for the tested run: host disappearance is confirmed before `fireEndActivityDelegates`, delegate callbacks, and `activitySession` cleanup. Treat this as a promising validation run, not final story closure.
- May 13 AccountLink runtime validation looks good in both host modes: SwiftUI-default and forced UIKit-host paths selected the expected host branch and preserved dismissal sequencing, with delegate/session teardown after confirmed dismissal. Before push, clean temporary debug prints and consider moving dismissal-specific helper types out of `XFlowManager.swift` into a dedicated dismissal file.
- Follow-up SampleApp validation found a likely branch-introduced dismissal regression caused by host-mode mismatch: SampleApp uses `initialViewController(...)` / UIKit presentation, but the branch defaulted manager host mode to SwiftUI, so `endActivity` can take the SwiftUI subject path without a SwiftUI dismissal host subscriber. Fix direction should preserve existing behavior by keeping `initialViewController(...)` on the UIKit dismiss-completion path and `makeInitialFlowView(...)` on the SwiftUI lifecycle path.
- SampleApp should support explicit validation of both UIKit-host and SwiftUI-host scenarios. XFlowSDK should remain self-aware of which dismissal mechanism to use based on the active integration path, so SampleApp can exercise both paths without relying on stale singleton/default host-mode state.
- May 14 SampleApp iteration: SampleApp was updated to choose between UIKit-host (`initialViewController(...)`) and SwiftUI-host (`makeInitialFlowView(...)`) paths from the existing `Use SwiftUI` setting / feature-toggle path. XFlowSDK entrypoints now prepare the matching dismissal mechanism, and the SampleApp SwiftUI-host rendering was refined to use a `ViewBuilder`/`flowContent` approach rather than storing an `AnyView` in state. Next validation is SampleApp back-to-back host-mode switching plus Fid4 AccountLink revalidation in both host modes.
- Jeff recommended expanding validation beyond AccountLink before PR review: test as many current Fid4 XFlow entry and dismissal points as possible in both default SwiftUI-host and forced UIKit-host modes, with particular attention to AO flows. Use the existing Confluence entry-point list as a starting point, but verify it against current code and temporary logs because some entries may be stale.
- May 20-21 validation: sessions 004, 005, 008, and 009 confirmed full validation for several key entry points:
  - `HybridBloomAccountOpening` (Affiliation-Gated AO Modal): Fully validated in both UIKit host (Session 008) and SwiftUI host (Session 009) with full dismissal/cleanup confirmed. (Requires enabling affiliation flags and manually injecting `affiliation_id` / `branch_affiliation_id` UserDefaults keys in LLDB, then navigating Pre-login -> "Open an account" -> UK Invests -> consent flow).
  - `HybridBrokerageAccountOpening`: Fully validated on both UIKit and SwiftUI hosts with full lifecycle/dismissal confirmed.
  - `HybridYouthAccountOpening`: Fully validated on both UIKit and SwiftUI hosts with full lifecycle/dismissal confirmed, resolving the previous dismissal coverage gap.
- Remaining validation gaps on the combined PDIAP-12284 / PDIAP-15836 branch include:
  - `accountlink` (P2P Transfer Flow): UIKit host validation is pending (SwiftUI host and dismissal are validated).
  - `AODeeplinkLaunchView` (AO Deep-Link with Native/Web Toggle): untested on both branches (Native ON/OFF) and dismissal.
  - Fid4 surface attribution for launch wrappers and common-launch flows.
- Draft PRs were opened for XFlowSDK and XFlowViewMaker on May 20 while validation continues.
- Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there
- Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers
- Thoroughly verify current `ApexBridgingAddressComponent` / rule-loading usage before describing it as inactive or dead code
- Reconcile the old UIKit address-rule path with the current SwiftUI handling path through the adapter/view-model layer before reporting final ownership or replacement guidance
- The ApexKitV3 risk write-up for Quy has been published and sent; use that research as the current high-level framing for dependency-removal risk
- Investigate the current XFlow dependency surface on `ApexKitV3`, including the `23` build errors on removal and the remaining `13` errors when swapping to `ApexKitSwiftUI`
- The process-oriented rollout document for the UIKit-removal spike is approved and ready to publish for spike closure
- The rollout document should frame the work as a more deliberate migration phase toward the SwiftUI-only path, not as a correction to a prior failed attempt
- The rollout document uses a global feature-flag rollout model with broad XQ1 validation before production enablement
- The rollout document should use the new flag name `xflow-swiftui-container-enabled` and note that the flag will be added later during implementation
- Re-check the authenticated AO validation issue with scenario-specific evidence: the `HybridYouthAccountOpening` / `TeenIdentityCheck` path currently points to an iOS-only decoding gap, while a separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` case reproduces on both platforms
- The immediate Youth issue was fixed on the service side for the Youth-flow `TeenIdentityCheck` path after the payload moved from `birthDate` to `validations`; local Fid4 validation also confirmed it. The XFlowSDK-side fallback PR should still ship in the next release
- Jeff later decided the iOS fallback PR should be treated as the primary fix path for the Youth issue rather than relying on a separate service rollout; the QA-side service change has since been rolled back and Fid4 validation still passed with the PR in place
- When describing the XFlowSDK fallback PR, frame it as a compatibility improvement for similar future `birthDate` payloads, not as a fix for the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue
- The Youth / `TeenIdentityCheck` issue was iOS-only; do not describe it as reproducing on both platforms
- The service-side payload update and the XFlowSDK fallback PR address the same Youth / `TeenIdentityCheck` issue; do not split them into separate Youth issues when summarizing scope
- The `PDIAP-15765` compatibility fix is now fully closed out and the story is in Done
- A new urgent consumer report says REST calls fail on iOS when the toggle is enabled, but current local validation says REST works on both `main` and `release/4.30`; treat version/flag mismatch as the leading explanation until broader evidence says otherwise
- David has now confirmed the production build already contains the commit that added the LaunchDarkly flag, so the current investigation should focus more on LaunchDarkly evaluation context, targeting, initialization timing, and any additional transport-selection gating on iOS
- Jeff explicitly wants the REST-flag investigation to stay ahead of Adam's separate service-side flow report for now and wants faster visible progress on that path
- Jeff suggested broadening the investigation support path while direct Flagship LaunchDarkly access is still missing: monitor the Tauf thread, follow up with Jeffrey O'Leary, package the scenario for the AI tool with build settings and tool details, and ask Aylwing for a quick perspective if available
- The Fidelity-side AI tool Jeff referenced for this investigation is GitHub Copilot
- Jeff later relayed that Adam says the latest build is now activating REST correctly, so David should switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles
- For the upcoming REST-layer validation meeting, David prepared Fid4 `4.32` in a separate folder on the release branch, aligned it with the published/internal build `Podfile.lock` from iOSInstaller, and verified the project builds. Current XQ1 behavior appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST; `Open an account` is the simplest non-authenticated entry point for quick XFlow validation.
- Jeff confirmed May 11 that the REST back end has now been deployed, and a validation meeting is scheduled for May 12 with the team lead and Bruce. They will toggle the REST flag during the meeting and test both states. Jeff asked David to smoke-test Fid4 `4.32` non-REST flows ahead of the meeting.
- REST detection for the meeting: use Charles Proxy to check `/xflow/api` endpoints and inspect `mobile.launchdarkly.com` bulk payloads for the raw evaluated flag value.
- Production testing: Raj is trying to get approval to test in production, or they may flip the toggle directly in production. A production test account will be needed; currently only Bruce is known to have one. David found a way to force the production environment from the simulator if needed.
- May 12 REST validation nuance: pointing Fid4 at production through the plist by itself still showed GraphQL, but the fuller meeting result was successful iOS REST validation after Raj enabled the production LaunchDarkly toggle with specific targeting for the production test user's context, specifically the MID for the account tested with Bruce. The accurate framing is not simply "production still used GraphQL"; the key difference was production LD targeting for the specific user context.
- Jeff confirmed the feature flag strategy (host-mode resolution centralized in XFlowViewMaker) is in scope for the current `PDIAP-12284` / `PDIAP-15836` branch and asked David to implement it there.
- `PDIAP-15838` draft PR has reached external review; Bruce left minor feedback, David addressed it, and Jeff directed David to move the ticket to Done while holding the merge
- Do not merge the GraphQL/Apollo removal PR until REST backend is live in production and the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for at least 30 days without issues
- Current `PDIAP-15838` follow-up centers on the `PicoSDK` update in `SampleApp`: the newer Pico path removes the remaining transitive Apollo dependency, re-enables FGO and FidFolios testing in `SampleApp`, and aligns the sample implementation with current Fid4 usage
- The `PicoSDK` update affects `SampleApp`, not the `XFlowSDK` production runtime directly
- The new Discourse / FTTransfer AccountLink issue is under investigation; Zachary believes it may come from XFlow, but current evidence shows it reproduces in `FTTransferPlayground` with Zachary's account and does not reproduce in `Fid4` with the same account
- Current Discourse / FTTransfer findings point to the `BankInformationView` path rather than XFlow directly: XFlow appears to finish before `BankInformationView` takes over, and the web-view reload looks like a SwiftUI recomposition/state issue in the playground path
- Continue the Discourse / FTTransfer investigation to verify root cause and any remaining relationship to XFlowViewMaker before assigning ownership or creating a story
- Jeff asked David to try to resolve the Discourse consumer issue by end of day on April 30 if possible
- Deeper Discourse / FTTransfer analysis now points to presentation-layer SwiftUI identity/lifecycle churn around `BankInformationView` and `BankSetupWebView`: XFlow eventing appears to set shared consumer-observed state, but current evidence does not show it directly mutating view identity, host lifecycle, or alert state.
- The working non-XFlow route appears to avoid the issue because it bypasses the extra XFlow destination presentation layer and associated state-coupling surface, while the failing playground path keeps the alert/popup transition and cover lifecycle coupled in the same reactive chain.
- The next implementation direction for the Discourse / FTTransfer issue is a pure SwiftUI fix that decouples alert state from the cover identity chain, avoiding unnecessary UIKit dependencies
- `PDIAP-16167 - AccountLink - XFlow causing web view rewrites investigation` was created for the FTTransfer AccountLink investigation and root-cause report
- Include in the `PDIAP-16167` report that the issue persists when rolling back `XFlowSDK` to `v0.1.0`, predating REST and modern architecture changes; Jeff explicitly asked David to include this in the document
- `PDIAP-16167` is Done: the Confluence report was published, findings were sent to Zachary / Jira / Discourse, and future references should describe the root cause as a consumer-side SwiftUI presentation-topology issue in `BankInformationView`, not an XFlow/XFlowViewMaker regression
- `PDIAP-12284` is the original UIKit-wrapping removal story reopened after rollback; track `PDIAP-15836` as blocked by `PDIAP-12284` unless further validation proves the lifecycle fix can be implemented independently on the SwiftUI path
- After `PDIAP-15836` / `PDIAP-12284` implementation, expect a long-lived branch: Jeff's current planning assumption is that the GraphQL-removal branch merges first after the REST validation period, then that is merged into the UIKit-removal/lifecycle branch, with `PDIAP-15836` / `PDIAP-12284` merge around 90-100 days from 2026-05-05 unless Fidelity shortens the review periods
- Backlog triage found future/reference items: `PDIAP-11962` has earlier secret-scanning closure evidence but two Google API Key alerts remain; `PDIAP-11961` is the related unassigned rotation/invalidation story for those alerts; `PDIAP-11562` concerns XFlow podspec/Fid4 debug-build configuration; Sparta items `PDIAP-12226`, `PDIAP-12227`, and `PDIAP-12228` are lower-priority until XFlow backlog items that can be closed are handled
- Before closing out the AO thread, send one more working-group Teams reply that summarizes the original iOS issue, links the Jira comment, Discourse comment, and PR, and separates the remaining `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue
- The `HybridBrokerageAccountOpening` / `JointIdentityCheck` rule-content issue appears unchanged between QA and Production in Cogstore and should be treated as the remaining service-side follow-up

---

## Active Concerns

- Authenticated vs non-authenticated behavior
- Reproducibility across entry points
- Backend-driven inconsistencies in XFlow
- Distinguishing external issues from true regressions
- Preserving accurate context when summarizing work from another machine
- Validating dismissal sequencing changes across SwiftUI flows
- Keeping REST deprecation scope explicit while GraphQL fallback still exists
- Current LaunchDarkly access does not include Flagship LD projects; only the sample app LD project is available from David's side
- David does not yet know where the iOS app assembles or identifies the LaunchDarkly context attributes, but can inspect source code and use Charles Proxy during investigation
- Current local evidence shows the LaunchDarkly boolean evaluating to `true`, with payload and context present from the iOS side, so the remaining uncertainty is around production-side context interpretation, timing, caching, or additional downstream gating
- The urgent REST-activation investigation is no longer the immediate blocker after Adam reported the latest build working, but the earlier context/timing uncertainty remains useful background if the issue reappears
- Adam reported the earlier REST activation problem, and he or his team validate behavior on real devices rather than simulator-only paths
- Avoid treating GitHub Copilot or LaunchDarkly as story-specific tools; both are broader Fidelity workflow tools that happened to matter in this investigation
- Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
- Current Fid4 validation logs include duplicate Objective-C class warnings for `Secure` / `DeviceRisk` symbols loaded from both `SecureDocV.framework` and `Fid4.debug.dylib`; treat this as environment/integration noise unless runtime behavior points to a validation blocker, and redact raw device-token prints before sharing logs.
- Keep Apollo-removal / REST-migration cleanup grounded in production readiness: source-level cleanup can continue, but merge/release timing depends on the prior REST-toggle implementation being QA-tested and stable in production for the agreed window
- Keep the GraphQL/Apollo removal branch and the future `PDIAP-15836` / `PDIAP-12284` branch current with `main`; if conflict resolution looks non-trivial, flag it so a 1-2 point branch-maintenance story can be created
- Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope
- Avoiding assumptions about legacy Apex/ApexKit paths; breakpoint evidence and helper usage both need to be reconciled before reporting ownership or replacement guidance
- When ownership is still uncertain under production pressure, prefer rollback-plus-investigation framing over confident blame assignment to consumers
- Swift 6 migration risk is now time-sensitive because external dependency removal could break XFlow before the planned `26Q3` work
- The write-up for Quy should remain the reference framing for moderate effort, medium risk, and required consumer validation while deeper implementation details are still being researched
- Remaining Google API Key alerts should not be framed as newly introduced REST-story secrets unless evidence changes; current evidence ties them to older April 18, 2025 work and a separate backend/rotation support path

---

## Communication Priorities

- Standups should reflect the latest technical state, not generic progress
- Standups should prefer updates directly tied to active work items over one-off memory refreshes or side questions
- Standups should include story titles whenever a reported update maps to a Jira item
- Standups should use bullet points for each item, but avoid dash-separated title formatting inside the sentence body
- When one Jira item has multiple concrete updates, prefer one top-level Jira bullet with indented sub-bullets rather than repeating the same Jira line multiple times
- When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas
- For Friday standups that may also be sent to Teams, prefer plain language over internal implementation terms; avoid words like `fallback` unless the meaning is obvious to the audience
- For standups that may also be sent to Teams, keep the update concise, omit internal review-feedback details, and avoid phrasing like `confirmed` when the audience lacks the internal context for what was confirmed
- When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone
- Standups should omit side questions or manager-only context refreshes unless they materially changed story work
- For `PDIAP-16167` standups after May 1, do not report story creation as previous-day work unless the previous-workday evidence explicitly says the story was created that day; focus on report publication, findings shared, closure, or remaining follow-up instead
- For `PDIAP-15838` standups, focus on Apollo-removal progress and the `PicoSDK` transitive dependency work; omit extra exploratory asks unless they directly changed the story outcome or created a blocker
- If a root cause document or other documentation update directly supports a story, it should be reported under that story instead of as a separate standalone item
- Standups should omit items not tied to a story unless they are real blockers
- If a new request is important work but not directly tied to a Jira item, include it as a standalone bullet instead of forcing it under a story
- Manager updates should be short, precise, and natural in English
- Mattermost messages should make scope and next action explicit
- When root cause is not fully isolated, do not position framework conclusions as authoritative consumer-side fault
- Standups should be written as David's external progress report and should not mention Jeff by name
- Standups should never mention Mattermost because it is internal-only communication

---

## Notes

- REST remains behind a feature flag
- Validate against main before calling something a regression
- This workspace is the context source for communication, not the source of product code changes