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