Add daily logs and templates for project fidelity
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
This commit is contained in:
@@ -0,0 +1,31 @@
|
||||
- Experiment-driven investigation
|
||||
- Debug print auto added
|
||||
- Iteratively detect now possible debug prints
|
||||
- Structured ticket artifacts with jira, patch, prompts, sessions
|
||||
- Tolerant to pre-experiment fix steps to fix any build error between experiments
|
||||
- Swift skill, specialized to debug prints
|
||||
- Xcode Integration
|
||||
- Xcode logs analysis
|
||||
- Find and read the full Xcode artifacts
|
||||
- Extract relevant logs
|
||||
- Efficient use of xcode commands to build, test, contexted for tuist, cocoapods, sample projects
|
||||
- Execute unit test proficiently, like executing only new tests or related
|
||||
- Auto breakpoint management
|
||||
- UITest integration
|
||||
- IA Investigation
|
||||
- Differences from skills with cli commands vs mcps
|
||||
- Differences of skills vs instructions from vscode copilot
|
||||
- Differences from agents vs skills using agent, what is more general? correct relationship and use
|
||||
- Fidelity
|
||||
- Charles Proxy integration
|
||||
- LaunchDarkly integration
|
||||
- Teams integration
|
||||
- Splunk analyzer
|
||||
- [x] Discourse integration
|
||||
- ServiceNow access
|
||||
- Photo uploader
|
||||
- [x] Multi photos session, copy multiples images in clipboard
|
||||
- [ ] Start as a service
|
||||
- [ ] Auto categorize by context
|
||||
- Swiftlint integration
|
||||
- Auto validator
|
||||
@@ -0,0 +1,25 @@
|
||||
# Work Items
|
||||
|
||||
## Goal
|
||||
|
||||
Keep active Jira-linked work in one canonical place so standups, manager updates, and memory syncs can reference each ticket precisely.
|
||||
|
||||
---
|
||||
|
||||
## Structure
|
||||
|
||||
- `index.md`
|
||||
Active index and quick status view.
|
||||
|
||||
- `<jira-id>.md`
|
||||
Canonical file for a specific ticket.
|
||||
|
||||
---
|
||||
|
||||
## Update Rules
|
||||
|
||||
- Use one file per active or recently relevant Jira item.
|
||||
- Keep titles exact when approved or explicitly confirmed.
|
||||
- If the title is not confirmed, store the Jira ID and current framing without inventing a final title.
|
||||
- Update the ticket file when scope, sequencing, points, status, rollout implications, or reproducibility meaningfully change.
|
||||
- Keep `workspaces/fidelity/project-knowledge/01-current/work-items.md` as a short bridge summary, not the primary source of detailed ticket context.
|
||||
59
workspaces/fidelity/project-knowledge/02-work-items/index.md
Normal file
59
workspaces/fidelity/project-knowledge/02-work-items/index.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: work-item-index
|
||||
project: fidelity
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- map
|
||||
---
|
||||
# Work Item Index
|
||||
|
||||
## Goal
|
||||
|
||||
Provide a quick view of active and recently relevant Jira-linked work while keeping the full detail in one file per ticket.
|
||||
|
||||
---
|
||||
|
||||
## Active
|
||||
|
||||
- [pdiap-15838.md](./pdiap-15838.md)
|
||||
`PDIAP-15838` ticket is Done, but the draft PR remains unmerged and must be kept current with `main` until REST backend production readiness and the required consumer validation window allow merge.
|
||||
|
||||
- [pdiap-15836.md](./pdiap-15836.md)
|
||||
`PDIAP-15836` approved follow-up story for dismissal delegate lifecycle sequencing in pure SwiftUI; paired with `PDIAP-12284` and should not move to In Progress until the next sprint starts.
|
||||
|
||||
- [pdiap-12284.md](./pdiap-12284.md)
|
||||
`PDIAP-12284` reopened original UIKit-wrapping removal story; current blocker/dependency path for `PDIAP-15836`.
|
||||
|
||||
## Backlog / Future Reference
|
||||
|
||||
- [pdiap-11962.md](./pdiap-11962.md)
|
||||
`PDIAP-11962` closure of secret scanning alerts; prior closure was submitted/closed, but two Google API Key alerts remain.
|
||||
|
||||
- [pdiap-11961.md](./pdiap-11961.md)
|
||||
`PDIAP-11961` related unassigned request for remaining Google API Key rotation/invalidation.
|
||||
|
||||
- [pdiap-11562.md](./pdiap-11562.md)
|
||||
`PDIAP-11562` investigate whether XFlow is being built as debug; historical Slack ties this to the `XFlowSDK_Debug` podspec variable and Fid4/Jenkins consumption.
|
||||
|
||||
- [pdiap-12226.md](./pdiap-12226.md), [pdiap-12227.md](./pdiap-12227.md), [pdiap-12228.md](./pdiap-12228.md)
|
||||
Sparta backlog items split across JSON decoding/initialization, grid rendering/core components, and interactive/lifecycle behavior; decoding/rendering are partially complete and interactive components remain blocked by unresolved mobile JavaScript execution.
|
||||
|
||||
## Recently Completed
|
||||
|
||||
- [pdiap-16167.md](./pdiap-16167.md)
|
||||
`PDIAP-16167` AccountLink investigation completed with Confluence/Jira/Discourse/Zachary follow-up; root cause is a consumer-side SwiftUI presentation-topology issue, not XFlow/XFlowViewMaker.
|
||||
|
||||
- [pdiap-15765.md](./pdiap-15765.md)
|
||||
`PDIAP-15765` authenticated-only DOB issue in `HybridYouthAccountOpening` / `TeenIdentityCheck`; completed while keeping the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of scope.
|
||||
|
||||
- [pdiap-14859.md](./pdiap-14859.md)
|
||||
`PDIAP-14859` spike around final UIKit wrapping removal and rollout planning is done.
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
- Read this file first for active ticket context.
|
||||
- Open the specific ticket file when you need exact scope, sequencing, or communication wording.
|
||||
- Update the per-ticket file first when ticket context changes materially.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-review
|
||||
ticket: PDIAP-11562
|
||||
title: "Investigate if XFlow is being built as debug"
|
||||
systems: [xflowsdk, fid4]
|
||||
workstreams: [dependency-management, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: []
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- build
|
||||
---
|
||||
|
||||
# PDIAP-11562 - Investigate if XFlow is being built as debug
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item under review for possible next work.
|
||||
|
||||
---
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- This is related to how the XFlow podspec is configured and how Fid4 consumes it.
|
||||
- It is not currently understood as Sparta-team work.
|
||||
- The concern is whether a debug build configuration or debug-like flag is being used in a dependency-integration context where it should not be.
|
||||
- Next investigation should identify why/how the flag or build configuration is used and whether there is a safer integration approach.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- September 2025 backlog context lists the full title as `Spike: Research/investigate if Xflow is being built as debug in Fid4 and if that’s a concern or intentional.`
|
||||
- November 2025 Slack context says the relevant check is the `XFlowSDK_Debug` variable in the podspec, not a Podfile setting.
|
||||
- David confirmed in November 2025 that the `XFlowSDK_Debug` variable check was still present.
|
||||
- Working interpretation from that thread: Jenkins likely does not set the variable when building the static framework; the `if/else` path may be intended so local development consumes XFlow as a normal library while Jenkins builds/consumes it as an xcframework.
|
||||
- Treat that as a historical hypothesis to verify in current code/build settings, not as a confirmed current production behavior.
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog
|
||||
ticket: PDIAP-11961
|
||||
title: "Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation"
|
||||
systems: [xflowsdk]
|
||||
workstreams: [security, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-11962]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- security
|
||||
---
|
||||
|
||||
# PDIAP-11961 - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item; not assigned yet.
|
||||
- Jeff relayed that this is not a priority yet, but asked David to keep the details noted for future reference.
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- Related to the remaining Google API Key alerts not included in the previous `PDIAP-11962` closure.
|
||||
- If key rotation or invalidation is required, David/XFlow likely needs backend support or clarification because Google API Key rotation is not owned directly by the XFlow iOS side.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- October 2025 Slack context describes `PDIAP-11961` as the request for rotation/invalidation of active exposed Google API keys.
|
||||
- The active Google API keys were documented as still valid/in use by the service, so they were intentionally separated from inactive-secret closure evidence.
|
||||
- `PDIAP-11962` was created as the second-phase closure story to run after `PDIAP-11961` invalidation/rotation work completed.
|
||||
- Earlier investigation noted that the API key appeared in a service response and that GitHub was flagging the old commit where the key had been hard-coded and later removed.
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-review
|
||||
ticket: PDIAP-11962
|
||||
title: "Closure of secret scanning alerts"
|
||||
systems: [xflowsdk]
|
||||
workstreams: [security, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-11961]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- security
|
||||
---
|
||||
|
||||
# PDIAP-11962 - Closure of secret scanning alerts
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item under review for future work.
|
||||
- Earlier alert-closure process appears partially completed, but two Google API Key alerts remain open.
|
||||
|
||||
---
|
||||
|
||||
## Current Findings
|
||||
|
||||
- David found an October 9, 2025 email confirming the prior submission.
|
||||
- Follow-up shows Matthew closed the earlier alerts/story on March 5, 2026.
|
||||
- Two Google API Key alerts remain open and were not part of that closure.
|
||||
- Those alerts appear tied to an old `MockPageViewWithHiddenToggle` commit from April 18, 2025, not newly introduced REST-story work.
|
||||
- Google API Key rotation is not owned by David/XFlow directly; backend support or clarification may be needed if rotation/invalidating is required.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- October 2025 Slack context ties this story to `PDIAP-11573 - Remediate secret scanning alerts in XFlow iOS SDK`.
|
||||
- The intended sequence was:
|
||||
1. report inactive secrets through the SSDLC/AAVD process,
|
||||
2. use `PDIAP-11961` to handle invalidation/rotation of still-active Google API keys,
|
||||
3. use `PDIAP-11962` to close the GitHub alerts after `PDIAP-11961` is completed.
|
||||
- Slack context from October 10, 2025 says inactive secrets were reported in `ESWR-35407`, `PDIAP-11961` was created for active-secret invalidation, and `PDIAP-11962` was created to manage alert closure after invalidation.
|
||||
- Slack context from November 19, 2025 says the secret-remediation alerts were still present and none had been marked resolved at that time.
|
||||
- Treat `PDIAP-11962` as the closure/follow-up story, not the rotation/invalidation story itself.
|
||||
|
||||
---
|
||||
|
||||
## Related Work
|
||||
|
||||
- `PDIAP-11961 - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation` is the related story for the remaining Google API Key alerts and is not assigned yet.
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-partial
|
||||
ticket: PDIAP-12226
|
||||
title: "iOS: Implement SpartaSDK initialization and JSON decoding"
|
||||
systems: [sparta, xflowsdk]
|
||||
workstreams: [sparta, backlog-triage]
|
||||
people: [jeff-dewitte, aylwing-olivas]
|
||||
related: [pdiap-12227, pdiap-12228]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- sparta
|
||||
---
|
||||
|
||||
# PDIAP-12226 - iOS: Implement SpartaSDK initialization and JSON decoding
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item; partially complete.
|
||||
|
||||
---
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- Last known work was a decoding-layer refactor based on internal feedback from Aylwing.
|
||||
- Direction was to make decoding strict so malformed backend responses surface errors to the consumer instead of silently skipping unsupported components.
|
||||
- Earlier approach used a `strict mode` toggle where unsupported components were omitted from rendering.
|
||||
- Refactor is still in progress; if no new component types are added, it may not require much beyond the existing work.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- October 2025 Slack context shows the work started from `PDIAP-11956` / `PDIAP-12066` exploration: dynamic JSON decoding, `SpartaNodeRegistry`, strict-mode behavior, and fallback handling for unknown node types.
|
||||
- By October 21, 2025, decoding tests validated fallback handling and registry lookups in an internal `SwiftUIBuilder` PR.
|
||||
- November 2025 planning split the remaining SpartaSDK work into separate stories; this one became the initialization and JSON-decoding story.
|
||||
- November 20-24, 2025 Slack context says `PDIAP-12226` was moved to a later sprint and David was reviewing whether the current JSON-decoding implementation was ready for a formal PR.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-partial
|
||||
ticket: PDIAP-12227
|
||||
title: "iOS: Render grid-based layout and core visual components"
|
||||
systems: [sparta, xflowsdk]
|
||||
workstreams: [sparta, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-12226, pdiap-12228]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- sparta
|
||||
---
|
||||
|
||||
# PDIAP-12227 - iOS: Render grid-based layout and core visual components
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item; partially complete.
|
||||
|
||||
---
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- There is already a working base that places elements on the grid layout.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- October 2025 Slack context shows rendering work began after the decoding spike, with a SwiftUI renderer/protocol path and initial support for titles, buttons, text, and grid-related components.
|
||||
- The Sparta work uses JSON responses with grid-position attributes; Jeff advised avoiding the term `DSL` in user-facing/sample naming unless the team confirms that language.
|
||||
- November 2025 planning split the work so `PDIAP-12227` covered grid-based layout and core visual components.
|
||||
- November 20, 2025 Slack context says Quy wanted `PDIAP-12226` and `PDIAP-12227` placed into the sprint after next at that time, with the option to pull them in earlier if capacity allowed.
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: backlog-blocked
|
||||
ticket: PDIAP-12228
|
||||
title: "iOS: Implement interactive components and lifecycle behaviors"
|
||||
systems: [sparta, xflowsdk]
|
||||
workstreams: [sparta, backlog-triage]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-12226, pdiap-12227]
|
||||
updated: 2026-05-05
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- sparta
|
||||
---
|
||||
|
||||
# PDIAP-12228 - iOS: Implement interactive components and lifecycle behaviors
|
||||
|
||||
## Status
|
||||
|
||||
- Backlog item; blocked or unresolved.
|
||||
|
||||
---
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- Covers interactive components such as buttons.
|
||||
- Main unresolved question was how to execute JavaScript on mobile.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- November 2025 planning split the SpartaSDK proof-of-concept follow-up into initialization/decoding, rendering, interactive components/lifecycle, and navigation/flow logic tracks.
|
||||
- Earlier Slack updates show buttons and dropdown rendering were already partially explored under foundational SpartaSDK work, but full interactive behavior and lifecycle/navigation behavior were not complete.
|
||||
- Treat JavaScript execution on mobile as the major unresolved blocker for richer interactive behavior unless current project evidence supersedes it.
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: in-progress
|
||||
ticket: PDIAP-12284
|
||||
title: "Remove UIKit wrapping from XFlow"
|
||||
systems: [xflowsdk, xflowviewmaker]
|
||||
workstreams: [xflow-swiftui-migration, consumer-integration]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-15836, pdiap-15838]
|
||||
updated: 2026-05-14
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- swiftui
|
||||
- xflow
|
||||
---
|
||||
|
||||
# PDIAP-12284 - Remove UIKit wrapping from XFlow
|
||||
|
||||
## Status
|
||||
|
||||
- Reopened after rollback and moved to In Progress on May 12.
|
||||
- Jeff directed David to do this UIKit-removal work and `PDIAP-15836` dismissal/lifecycle work in the same branch because both are disruptive enough to require consumer testing.
|
||||
- Current implementation direction is to avoid Fid4-owned per-flow host-mode mapping and evaluate XFlowViewMaker-owned global host-mode resolution.
|
||||
- David continued the implementation/validation loop on May 11; current simulator log review is promising for the SwiftUI-host dismissal sequencing in the tested run.
|
||||
- Jeff confirmed on May 11 that the feature flag strategy (host-mode resolution centralized in XFlowViewMaker) should be implemented as part of this branch's work.
|
||||
- May 12 implementation pass resolved several earlier concerns: host-mode API appears branch-local/new, enum cases were renamed to neutral `swiftUIHost` / `uiKitHost`, the final flag key is `iOS-XflowUIKitHostEnabled`, missing/false/unavailable flag values default to SwiftUI, and `AnyView` was removed from `buildFlow` internals while remaining only at the existing public `FlowViewMaker` boundary.
|
||||
- Current validation blocker appears to be dependency alignment rather than host-mode code correctness: XFlowViewMaker is resolving `XFlowSDK 2.8.48` from its podspec, which does not expose the new host-mode API needed by the branch.
|
||||
- After manual dependency/build handling, Fid4 now compiles with the latest `FlowViewBuilder` shape. Next validation should be runtime evidence: first verify a representative flow selects the default SwiftUI host path, then simulate/force `iOS-XflowUIKitHostEnabled == true` to verify the temporary UIKit host path and dismissal behavior.
|
||||
- Quy confirmed on May 13 that this story and `PDIAP-15836` can both remain In Progress together, so no immediate Jira restructuring is required.
|
||||
- May 13 AccountLink runtime validation looks good in both host modes. The SwiftUI-default path and forced UIKit-host path selected the expected branch and preserved dismissal sequencing; no AccountLink issue was observed in either mode during these runs.
|
||||
- Before push, cleanup should remove temporary `XFlow-DISMISS-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 host-mode mismatch regression introduced by the branch: `initialViewController(...)` still represents the UIKit presentation path, but manager state could remain on SwiftUI host mode and route `endActivity` through the SwiftUI dismissal subject without an active `XFlowDismissalHost`. The minimal fix should preserve existing behavior by forcing/setting UIKit host mode for `initialViewController(...)` and SwiftUI host mode for `makeInitialFlowView(...)`.
|
||||
- SampleApp should be updated to support explicit validation of both UIKit-host and SwiftUI-host modes. The SDK should choose the appropriate dismissal mechanism from the active integration path, not from stale/default host-mode state.
|
||||
- May 14 SampleApp iteration updated the sample to exercise both host scenarios explicitly: UIKit-host through `initialViewController(...)` and SwiftUI-host through `makeInitialFlowView(...)`, selected by the existing `Use SwiftUI` / feature-toggle path. XFlowSDK entrypoints should prepare their own matching dismissal mechanism so `endActivity` cannot route to the SwiftUI subject unless the SwiftUI host is actually active.
|
||||
- The SampleApp SwiftUI-host rendering was refined to avoid storing `AnyView` in state; SwiftUI-host content now lives behind a `ViewBuilder` / `flowContent` rendering path. This keeps local SampleApp code aligned with the branch goal of avoiding unnecessary `AnyView`, while preserving type erasure only at true public boundaries such as the existing XFlowViewMaker boundary if still required.
|
||||
- Jeff recommended expanding validation before 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 prior Confluence entry-point list as a starting point, but verify it against current code and temporary runtime logs before treating it as complete.
|
||||
- May 20-21 status: 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.
|
||||
- `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 gaps: `accountlink` UIKit host, `AODeeplinkLaunchView` (both toggle branches and dismissal), and launch wrappers/common-launch flows. Draft PRs were opened for XFlowSDK and XFlowViewMaker on May 20 while validation continues.
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- This is the original story for removing the UIKit wrapping.
|
||||
- Current relationship to track: `PDIAP-12284` should be handled with `PDIAP-15836` in the same implementation branch. David identified a possible minimal `PDIAP-15836` fix path that does not require removing `UIHostingController`, but Jeff prefers combined branch work because both changes require consumer testing.
|
||||
- Desired host-mode model: SwiftUI host is the default, missing or unknown feature configuration should also default to SwiftUI, and `UIHostingController` should remain only as an explicit temporary fallback while consumers validate the migration.
|
||||
- XFlowSDK should not be coupled directly to LaunchDarkly, Flagship, or app-specific feature-flag clients; it should receive an already-resolved host-mode decision.
|
||||
- If `hostMode` must be passed through `FlowConfig` or a similar object, keep it as adapter/internal plumbing rather than a new consumer-facing per-flow responsibility.
|
||||
- The latest tested run reported the expected dismissal order for the SwiftUI-host path, but the branch still needs review of the shared host-mode routing and any required broader validation before story closure.
|
||||
- Resolved implementation-shape decisions from the May 12 pass: keep two host-mode enum types to preserve the boundary where XFlowViewMaker owns host-selection policy and XFlowSDK owns presentation mechanics, keep the single conversion point in `FlowViewBuilder`, use neutral enum names, and keep SwiftUI as default unless `iOS-XflowUIKitHostEnabled` is explicitly true.
|
||||
- SampleApp-specific rendering should not reintroduce `AnyView` just to switch between validation paths. Prefer view-builder composition plus state that represents the selected host path, plugins, and controller.
|
||||
- Fid4 validation for this branch should go beyond AccountLink: inventory current entry points, confirm which older Confluence-listed entries are still valid, and temporarily log entry path, resolved host mode, dismissal mechanism, delegate callbacks, and session cleanup. Remove those logs before PR publication.
|
||||
|
||||
---
|
||||
|
||||
## Historical Slack Context
|
||||
|
||||
- November 21, 2025 Slack context says David created `PDIAP-12284` and `PDIAP-12285` to cover remaining UIKit-removal work inside XFlow after reviewing open Sendable and XFlowViewMaker-track stories.
|
||||
- That same backlog refinement closed out pending XFlowViewMaker stories that were no longer needed.
|
||||
- Current Mattermost context supersedes the old standalone refinement framing: this story is now reopened after rollback and should be handled together with `PDIAP-15836`.
|
||||
|
||||
---
|
||||
|
||||
## Sequencing
|
||||
|
||||
- Work can begin, but merge/release should wait until the REST-transition consumer-validation window has completed.
|
||||
- Keep the implementation branch up to date with `main` while waiting for approval to work with consumers and merge.
|
||||
- Before implementation is treated as settled, confirm through product-code inspection whether XFlowViewMaker can resolve host mode using existing `FeatureEnabling` / `Featuring` abstractions or whether a small dependency-injection path is needed.
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: done
|
||||
ticket: PDIAP-14859
|
||||
title: "Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation"
|
||||
systems: [xflowsdk, xflowviewmaker, fid4, ftframeworks]
|
||||
workstreams: [xflow-swiftui-migration, consumer-integration]
|
||||
people: [jeff-dewitte, quy-mai]
|
||||
related: [pdiap-15836]
|
||||
updated: 2026-04-20
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- xflow
|
||||
- swiftui
|
||||
---
|
||||
# PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation
|
||||
|
||||
## Status
|
||||
|
||||
- Done
|
||||
- Rollout draft prepared and sent to Jeff for review on April 13, 2026
|
||||
- Rollout document was approved, published, and the spike was later moved to Done
|
||||
|
||||
---
|
||||
|
||||
## Current Framing
|
||||
|
||||
- Approved title: `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`.
|
||||
- This work is currently framed in the workspace as a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately.
|
||||
- The process-oriented deliverable has been completed and the spike is closed.
|
||||
|
||||
---
|
||||
|
||||
## Current Scope
|
||||
|
||||
- Define a consumer-facing rollout plan for the broader UIKit-removal work.
|
||||
- Preserve both UIKit and SwiftUI paths appropriately while introducing the new path safely.
|
||||
- Cover risky entry points such as `FTTransfer`, while keeping the latest spike finding explicit that consumer-side changes there may no longer be strictly required after the SwiftUI dismissal behavior is applied correctly.
|
||||
- Include validation expectations in `XQ1`.
|
||||
- Use a global feature-flag rollout model rather than entry-point-based enablement.
|
||||
- Include consumer communication expectations.
|
||||
- Include a 30-day production period with no reported bugs before final removal.
|
||||
- Include a follow-up release to remove the feature flag and old code after rollout confidence is achieved.
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- The feature-flag and rollout planning guidance applies to the broader UIKit-removal spike, not only to dismissal-sequencing work.
|
||||
- Jeff suggested sending the process-oriented rollout document to Quy for feedback when ready.
|
||||
- The draft shared with Jeff already reflects the global feature flag, broad `XQ1` validation, and consumer-facing rollout flow guidance.
|
||||
- Additional review feedback from April 13: rename the proposed flag to `xflow-swiftui-enabled`, make consumer contact and `XQ1` validation explicit in the first phase, remove overly technical rollout wording, and avoid implying there are no consumer-side changes without qualification.
|
||||
- On April 14, Jeff asked whether the FTTransfer part of the rollout document also needed updating; David confirmed the document had already been revised to clarify that root-cause section.
|
||||
- April 15 clarification: do not reuse the existing SwiftUI LaunchDarkly flag for this rollout.
|
||||
- The new flag name for this work should be `xflow-swiftui-container-enabled`.
|
||||
- The document should note that the flag is `to be added in the future as part of implementation`.
|
||||
- Late April 14 guidance: the document was approved late in the day; the next step is to publish it, then close out the spike by commenting `Spike Results:` with the relevant document links and the new follow-up story link.
|
||||
- The new follow-up story should also be marked as a blocker for the reopened UIKit-removal story.
|
||||
|
||||
---
|
||||
|
||||
## Related Work
|
||||
|
||||
- Related consumer rollout thinking should stay aligned with `PDIAP-15836`.
|
||||
- `PDIAP-15838` should not be framed as part of this UIKit-removal spike.
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: done
|
||||
ticket: PDIAP-15765
|
||||
title: "AO DOB field error not showing investigation"
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4, cogstore]
|
||||
workstreams: [ao-discourse, xflow-debugging, consumer-integration]
|
||||
people: [jeff-dewitte, gurram-santosh, raj-sundararaj]
|
||||
related: [pdiap-15838]
|
||||
updated: 2026-04-20
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- ao
|
||||
- xflow
|
||||
---
|
||||
# PDIAP-15765 - AO DOB field error not showing investigation
|
||||
|
||||
## Status
|
||||
|
||||
- Done
|
||||
- Small XFlowSDK compatibility fix merged and released in XFlow `2.8.48`
|
||||
- XFlowViewMaker was updated to the new XFlow version, approved, and published after the required code-owner approval
|
||||
- The downstream Fid4 update was carried through a consumer PR that was later approved and merged
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- This ticket is tied to an AO DOB validation issue.
|
||||
- The issue was confirmed for authenticated users in the `HybridYouthAccountOpening` flow on the `TeenIdentityCheck` page.
|
||||
|
||||
---
|
||||
|
||||
## Confirmed Findings
|
||||
|
||||
- The issue reproduces only for authenticated users based on the currently stored evidence.
|
||||
- The Youth / `TeenIdentityCheck` scenario is the iOS-only issue; do not describe it as reproducing on Android.
|
||||
- Root cause was documented.
|
||||
- The original external report was incomplete.
|
||||
- For the config discussion, `CheckIdentity` was already correct. The `TeenIdentityCheck` issue had two config gaps inside `validation-rules`: the root key should be `validations`, and the age gate also needs `eighteenOrAbove` there when that rule is required.
|
||||
- Follow-up validation on April 13 showed two distinct authenticated scenarios rather than one uniform cross-platform issue.
|
||||
- A `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario reproduces on both iOS and Android.
|
||||
- A `HybridYouthAccountOpening` / `TeenIdentityCheck` scenario works on Android but fails on iOS.
|
||||
- Current evidence suggests Android is more flexible in how it decodes rule variations, while iOS is stricter about the expected `validation-rules` structure.
|
||||
- Later validation on April 15 showed the original `HybridYouthAccountOpening` / `TeenIdentityCheck` issue no longer reproduces once the payload uses `validations` instead of `birthDate`.
|
||||
- A minimal XFlowSDK fix was still prepared on April 15 so the iOS `.apxDateSelect` path also falls back to `birthDate` for a future release.
|
||||
- Jeff confirmed on April 15 that this minimal iOS fallback is the right fix direction for the Youth / `TeenIdentityCheck` case and approved opening the PR under the same story.
|
||||
- On April 16, Jeff decided the iOS PR should be the primary fix path for the Youth / `TeenIdentityCheck` issue rather than relying on a separate service rollout.
|
||||
- Later on April 16, the PR received final approval, was merged, and the XFlow release was cut as version `2.8.48`.
|
||||
|
||||
---
|
||||
|
||||
## Current Guidance
|
||||
|
||||
- Treat the iOS-only `HybridYouthAccountOpening` / `TeenIdentityCheck` discrepancy as the main client-side issue currently aligned with the story.
|
||||
- Keep the cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario separate until it is clear whether it is a service/config issue, a distinct bug, or an unreported rule-processing difference.
|
||||
- Keep the authenticated-user qualifier whenever this ticket is mentioned.
|
||||
- Do not describe it as a generic validation issue without the `TeenIdentityCheck` and auth context.
|
||||
- The originally reported Youth issue was fixed for the Youth-flow `TeenIdentityCheck` path by the service-side payload update from `birthDate` to `validations`; local Fid4 validation also confirmed it. The XFlowSDK fallback PR should still be released so iOS handles the older `birthDate` format more safely.
|
||||
- That service-side Youth fix was later rolled back in QA so the iOS PR can remain the single fix path; local Fid4 validation with the PR still confirmed the `birthDate` validation works correctly.
|
||||
- Jeff provided historical context that these fallback paths exist largely to accommodate older AO payload conventions; when the issue is AO-specific, iOS-only, and caused by a service-vs-SDK key mismatch, this kind of iOS fallback is the usual fix.
|
||||
- The `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue is different from the original Youth report: the rule content itself does not include `ageRange` or `eighteenOrAbove`, so that path still points to a service-side update rather than the same iOS parsing gap.
|
||||
- David compared `HybridBrokerageAccountOpening` / `JointIdentityCheck` in Cogstore and found the relevant rule content is the same in QA and Production despite different flow-definition versions, so that separate issue should also exist in Production.
|
||||
- The small iOS PR should be described as a compatibility safeguard for future older-format payloads and should not be framed as applying to the `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue.
|
||||
- The service-side `birthDate` -> `validations` change and the small iOS PR both relate to the same Youth / `TeenIdentityCheck` issue; they should not be described as separate Youth issues.
|
||||
|
||||
---
|
||||
|
||||
## Next Step
|
||||
|
||||
- The XFlowViewMaker approval and publish step are complete.
|
||||
- The Fid4 dependency conflict was resolved through the podspec repo by removing the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs.
|
||||
- The podspec-repo PR was sent to Tauf and approved.
|
||||
- After that merge, `pod install --repo-update` in Fid4 worked because the published podspecs no longer restricted the XFlowViewMaker version.
|
||||
- The Fid4 PR with the latest versions was later approved and merged.
|
||||
- Story moved to Done after the downstream release propagation completed.
|
||||
- Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of the client-fix scope unless later evidence proves it is part of the same issue.
|
||||
- Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after consumer confirmation.
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: in-progress
|
||||
ticket: PDIAP-15836
|
||||
title: "Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment"
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks]
|
||||
workstreams: [xflow-swiftui-migration, consumer-integration]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-14859, pdiap-12284, pdiap-15838]
|
||||
updated: 2026-05-14
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- xflow
|
||||
- swiftui
|
||||
---
|
||||
# PDIAP-15836 - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
|
||||
|
||||
## Status
|
||||
|
||||
- Moved to In Progress on May 7.
|
||||
- David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, and was validating it.
|
||||
- Jeff directed David to do this dismissal/lifecycle work together with `PDIAP-12284` in the same branch because both changes are disruptive enough to require consumer testing.
|
||||
- May 11 simulator log review suggests the tested SwiftUI-host path now fires in the intended order: host-disappearance confirmation precedes `fireEndActivityDelegates`, delegate callbacks, and `activitySession` cleanup. Treat this as promising validation evidence for the tested run, not final consumer validation.
|
||||
- May 12 branch validation reported that explicit UIKit host mode still preserves dismissal-completion behavior and delegate callbacks/session cleanup remain after confirmed dismissal. Broader compile validation still depends on resolving the XFlowViewMaker / XFlowSDK dependency mismatch.
|
||||
- May 13 AccountLink runtime validation looks good in both SwiftUI-default and forced UIKit-host modes. Both paths preserved the intended dismissal sequencing, with delegate callbacks and session cleanup after confirmed dismissal.
|
||||
- May 14 SampleApp work refined dismissal validation coverage: SampleApp can exercise both UIKit-host and SwiftUI-host paths, while XFlowSDK entrypoints prepare the matching dismissal mechanism for the active integration path. This supports validating that UIKit dismiss completion and SwiftUI `XFlowDismissalHost` lifecycle sequencing both converge on the canonical delegate/session teardown path.
|
||||
- Jeff recommended broad Fid4 validation before PR review: test as many current XFlow entry and dismissal points as possible in both host modes, especially AO flows, and use temporary logs to confirm the active entry path, host mode, dismissal mechanism, delegate callbacks, and session cleanup.
|
||||
- May 20-21 status: 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.
|
||||
- `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 gaps: `accountlink` UIKit host, `AODeeplinkLaunchView` (both toggle branches and dismissal), and launch wrappers/common-launch flows. Draft PRs were opened for XFlowSDK and XFlowViewMaker on May 20 while validation continues.
|
||||
- Quy confirmed on May 13 that this story and `PDIAP-12284` can both remain In Progress together, so no immediate Jira restructuring is required.
|
||||
- Sequenced after `PDIAP-15838` source work, but merge/release is delayed until after REST-transition consumer validation
|
||||
- Sized at `8` points
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- This story came out of the `AccountLink` root cause investigation.
|
||||
- It is tied to the dismissal sequencing problem found after UIKit removal in SwiftUI-only paths.
|
||||
- The root cause document was updated and the revised wording was approved.
|
||||
|
||||
---
|
||||
|
||||
## Approved Scope
|
||||
|
||||
- Modernize dismissal delegate lifecycle sequencing for pure SwiftUI flows.
|
||||
- Cover the missing lifecycle contract where delegate callbacks can happen before the view is fully removed.
|
||||
- Validate the change across affected SwiftUI flows rather than only in one narrow reproduction.
|
||||
- Preserve a single canonical delegate/session-clear path if possible, and do not treat SwiftUI `onDisappear` as proof of dismissal completion unless simulator logs validate that lifecycle contract.
|
||||
|
||||
---
|
||||
|
||||
## Sequencing And Dependencies
|
||||
|
||||
- This story should come after `PDIAP-15838`.
|
||||
- `PDIAP-12284` is the original UIKit-wrapping removal story and was reopened after rollback.
|
||||
- Current working relationship: implement and validate `PDIAP-15836` together with `PDIAP-12284` in the same branch unless direction changes. David identified a possible isolated/minimal fix path, but Jeff prefers combined branch work because consumer testing is required either way.
|
||||
- It is aligned with epic `26Q2 - Updating XFlowSDK to Decouple and Fix ApexKit Dependencies (Split Part 2)`.
|
||||
- If possible, it should use the same consumer-impact feature flag strategy as the broader UIKit-removal rollout.
|
||||
- Current combined-branch planning should keep dismissal sequencing host-agnostic: the SwiftUI host path must prove dismissal completion before delegate callbacks, while the temporary `UIHostingController` fallback should preserve legacy dismiss-completion behavior.
|
||||
- Current validation logs did not show the key failure patterns for the tested run, such as delegate firing before host-disappearance confirmation or repeated host-disappearance confirmation for the same dismissal id.
|
||||
- SampleApp should be used as a guardrail for stale host-mode state by running UIKit-host and SwiftUI-host flows back-to-back without restarting the app.
|
||||
- Fid4 validation should also use the previous Confluence entry-point list as a starting point, but current source inspection/logging should decide which entries are still valid, renamed, removed, or replaced.
|
||||
- Expect a long-lived branch: after implementation, maintain the branch until consumer-testing approval. Jeff expects the GraphQL-removal branch to merge first after the REST validation period, then that branch should be merged into the `PDIAP-15836` / `PDIAP-12284` branch. Current estimate is roughly 90-100 days from 2026-05-05 unless Fidelity shortens the review windows.
|
||||
|
||||
---
|
||||
|
||||
## Communication Notes
|
||||
|
||||
- Keep the scope framed as lifecycle sequencing in a pure SwiftUI environment, not only as a symptom like multiple modal presentation.
|
||||
- If mentioned externally, keep it separate from `PDIAP-15838`.
|
||||
- The Confluence/root-cause document was updated to reflect that FTTransfer changes are not the primary need anymore.
|
||||
- The primary recommendation is to adjust the dismissal handling/sequencing correctly in the hosting path.
|
||||
- FTTransfer improvements can still be mentioned as a secondary improvement, but not as a required change to reproduce the same visual behavior.
|
||||
- When explaining why code still remains, clarify that the spike identified and documented the root cause, but implementation changes have not yet been published.
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: done-pending-merge
|
||||
ticket: PDIAP-15838
|
||||
title: "Remove Apollo for iOS"
|
||||
systems: [xflowsdk]
|
||||
workstreams: [rest-migration]
|
||||
people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
|
||||
related: [launchdarkly, github-copilot]
|
||||
updated: 2026-05-13
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- rest
|
||||
- graphql
|
||||
---
|
||||
# PDIAP-15838 - Remove Apollo for iOS
|
||||
|
||||
## Status
|
||||
|
||||
- Ticket moved to Done after external review feedback was addressed
|
||||
- Draft PR remains unmerged and must be kept up to date with `main`
|
||||
- PR merge should wait 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
|
||||
- Sized at `8` points
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- This ticket covers the REST migration cleanup on iOS.
|
||||
- The approved title is `Remove Apollo for iOS`.
|
||||
|
||||
---
|
||||
|
||||
## Approved Scope
|
||||
|
||||
- Remove Apollo from iOS.
|
||||
- Remove GraphQL-specific networking code.
|
||||
- Remove related tests and mocks.
|
||||
- Remove transport feature flags so REST remains.
|
||||
|
||||
---
|
||||
|
||||
## Current Guidance
|
||||
|
||||
- Do not frame this ticket as directly tied to the UIKit-removal spike.
|
||||
- Do not imply it is dependent on or part of dismissal-sequencing work.
|
||||
- Keep the migration framing explicit: REST remains behind a feature flag until otherwise confirmed, and GraphQL fallback context still matters when describing the overall migration.
|
||||
- Keep the REST-activation investigation context as useful background, but focus current updates on Apollo-removal cleanup, validation, and merge sequencing.
|
||||
- For standups and concise status updates, center the story on Apollo-removal progress and the `PicoSDK` transitive dependency path; omit extra exploratory asks unless they directly affect the story outcome or create a blocker.
|
||||
- Jeff confirmed this investigation should stay ahead of Adam's separate service-side flow report for now and asked for faster progress.
|
||||
- Current local evidence shows the LaunchDarkly boolean evaluating to `true`, with payload and context present from the iOS side; remaining uncertainty is around production-side context interpretation, timing/caching, or downstream transport gating.
|
||||
- Use the current support path while direct Flagship LaunchDarkly access is missing: monitor the Tauf thread, follow the outreach path to Jeffrey O'Leary, package the scenario for GitHub Copilot with build settings and tool details, and ask Aylwing for a quick perspective if available.
|
||||
- Adam later reported that the latest build is activating REST correctly, so the story context returned to the planned GraphQL-removal and related LaunchDarkly-toggle cleanup work.
|
||||
- Keep the real-device-only scenario in mind as a useful fallback hypothesis if the issue returns: environment-specific differences such as LaunchDarkly context, timing, or cached toggle state may explain behavior that does not reproduce in the simulator.
|
||||
- Adam was the reported source of the REST activation problem, and his side validates behavior on real devices.
|
||||
- Current codebase analysis suggests the main remaining source-level blockers are no longer transport selection but residual Apollo model/runtime coupling: `XFlow.Slot` usage in the page interactor/worker path, `NetworkClient` references still touched by init/session lifecycle, and Apollo/AppSync config surface that may still behave like public API.
|
||||
- Follow-up analysis suggested `XFlow.Slot` might be the only Apollo-generated production model still used outside the GraphQL-generated folder, but local trial changes surfaced additional Apollo-dependent models/build errors. Treat the `XFlow.Slot` simplification as a promising first step, not as a fully validated statement about the whole codebase.
|
||||
- The suggested simplification is to remove the current round-trip `stagedValues() -> [String: String] -> XFlow.Slot -> [String: String] -> XFlowUpdateSlotsRequest.slots` and instead pass `[String: String]` straight through to `XFlowUpdateSlotsRequest.slots`, keeping `SlotVariable: Encodable` in the REST model layer for request serialization.
|
||||
- The next AI follow-up should focus only on the first step and ask GitHub Copilot to corroborate residual Apollo-model dependencies by using `xcodebuild` failures, not just static reference search.
|
||||
- Follow-up enum validation indicates at least some Apollo-generated enum types can likely be replaced with native Swift `enum Name: String` definitions without preserving Apollo `EnumType` behavior. For the currently checked production callers, Copilot reported no Apollo-specific enum API dependency for `XFlow.ContentType`, `XFlow.ScreenshotFormat`, and `XFlow.NextTransitionType`; current behavior relies on `rawValue`, equality/switch use, and `init?(rawValue:)`-style parsing.
|
||||
- The currently observed fallback behavior is simple and code-local: unknown `ContentType` values are skipped by converter guards, unknown `ScreenshotFormat` values fall back to PDF in downstream callers, and unknown `NextTransitionType` values currently propagate as `nil` where the target property is optional.
|
||||
- Design direction for the Phase 1 Apollo cleanup: prefer replacing `XFlow.Slot` with a native Swift `Slot` model instead of collapsing it to `[String: String]` through the full production path. Keep `[String: String]` only at the boundary where the REST request/DTO is built in the worker or transport layer.
|
||||
- The current implementation state is cleaner on the model side: Apollo-generated production models have now been replaced with native Swift models/enums for the active path, so the next focus should move from model decoupling to remaining Apollo runtime/infrastructure dependencies.
|
||||
- The `XFlowInitManager` runtime/init cleanup step has now been applied successfully: the three `NetworkClient.shared.updateAppSyncURL(...)` calls were removed from the start/session lifecycle paths, `getAppSyncEndPoint()` was removed after becoming unused, and the project still compiles with `getEndPoint()` left intact for current REST selection.
|
||||
- `NetworkClient.swift` can likely stay temporarily in the tree as a disconnected compatibility shim until broader package/project cleanup, and `XFlowInitManagerConfig.swift` may need to keep AppSync getter/config surface temporarily to avoid an accidental public API break.
|
||||
- Follow-up runtime scan now suggests `GraphQL/NetworkClient.swift` has no live production callers and only self-references remain inside the file. The proposed next removal order is to delete `GraphQL/NetworkClient.swift` first, build/reference-check, then delete `GraphQL/ApolloGeneratedCode`, while keeping the AppSync members in `XFlowInitManagerConfig.swift` temporarily as compatibility-only surface.
|
||||
- Current local state after broader cleanup: runtime Apollo decoupling and most Apollo-specific test cleanup now appear complete, production code compiles cleanly aside from a pre-existing environment issue, and no live Apollo imports/references remain in production code. Remaining work is mainly package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
|
||||
- Current local state now also indicates the test target compiles cleanly after a minimal follow-up update to `XFlowTransportSelectionTests.swift`, preserving REST-relevant transport tests while removing obsolete GraphQL/Apollo assertions. The remaining Apollo-removal work appears concentrated in package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
|
||||
- Latest follow-up says the Apollo package/build cleanup has also now been applied: direct Apollo dependency references were removed from package/build ownership surfaces, leaving the main remaining follow-up as Fid4 validation plus any later decision on whether to deprecate/remove the temporary AppSync compatibility getters in `XFlowInitManagerConfig.swift`.
|
||||
- Apollo source-level cleanup appears sequenced as: replace `XFlow.Slot` with a transport-agnostic model first, decouple `XFlowInitManager` from `NetworkClient` while preserving current REST endpoint behavior, then remove runtime GraphQL code, project wiring, Apollo-only tests/scripts/docs, and finally treat any transitive PicoSDK Apollo dependency as a separate dependency-exit task.
|
||||
- Apollo may still remain in the pod graph transitively through PicoSDK even after source-level cleanup, so "Apollo removed" should be framed carefully unless the dependency graph is also cleared.
|
||||
- Latest local follow-up suggests `SampleApp` depends on `PicoSDK`, and that transitive dependency may still be the practical reason Apollo remains in the pod graph. Newer `PicoSDK` versions no longer depend on Apollo, but the upgrade path does involve real breaking changes. The current investigation is to determine how `SampleApp` can absorb those changes by comparing against how `Fid4` currently uses `PicoSDK` for the two specific flows that still depend on it.
|
||||
- Jeff later confirmed that this `PicoSDK` / `SampleApp` cleanup is in scope for `PDIAP-15838` because Apollo needs to be removed from the project, including the transitive sample-app path. Keep the nuance explicit that this update affects `SampleApp`, not the `XFlowSDK` production runtime directly.
|
||||
- David updated `SampleApp` to use the newer `PicoSDK` path, removing Apollo from the transitive sample-app dependency path and re-enabling the FGO and FidFolios flows for testing in `SampleApp`.
|
||||
- The `SampleApp` Pico changes now more closely mirror how Pico is already used in Fid4.
|
||||
- A draft PR has been opened for `PDIAP-15838 - Remove Apollo for iOS`; after internal review, the link should be sent to Bruce.
|
||||
- Internal review found and resolved `PicoSDK` integration concerns: `TransactionContextManager(resolver:)` handles Pico setup internally in `PicoSDK 4.3.18` through lazy resolver-based initialization, the resolver already exists on `XFlowSampleAppViewModel`, and `PicoInterface` was minimally patched so the async completion path avoids a strong `self` capture and returns through `MainActor.run` for UI-state safety.
|
||||
- The REST kill-switch removal is intentional for permanent GraphQL deprecation, but merge timing is gated: the previous REST-toggle implementation should first be QA-tested and active in production with REST enabled for all consumers for 30 days without issues.
|
||||
- Merge sequencing is now explicitly gated by backend production readiness: Bruce reinforced that the GraphQL/Apollo removal PR should not merge until the backend is in production because GraphQL fallback is still needed before then.
|
||||
- Bruce clarified that the current SDK-side updates are not REST behavior changes; the functional REST/backend fix is on the Flagship/Fid4 side, while SDK updates are cleanup, more graceful error handling, logging, and replacing a deprecated logger interface.
|
||||
- Bruce asked whether iOS Fid4 has a release-build optimization or code-minification concept comparable to Android; treat this as a validation/build-configuration question until clarified, not as evidence of a known iOS minification issue.
|
||||
- Jeff clarified the validation ask: inspect whether Fid4 has simulator-versus-physical-device or generated-build differences in build settings/schemes/configurations, including any optimized-build-size or release-style settings that could explain behavior seen in generated builds but not when running locally.
|
||||
- Current likely Fid4 build differences to report: Trunk/generated builds use the `Release` configuration while local runs are usually `Debug`; optimization settings such as `SWIFT_OPTIMIZATION_LEVEL` and `GCC_OPTIMIZATION_LEVEL` can differ; Jenkins uses a generated `build-overrides` xcconfig that local builds do not use and may affect values such as secrets; and CocoaPods dependency resolution can vary depending on the local specs repo state.
|
||||
- External review reached Bruce and produced minor feedback. David addressed the feedback and pushed the suggested change.
|
||||
- One accepted review change was to set `responseKey: String? = nil` as the default in `FlowRESTOperationContract`, allowing operations such as `updateSlots`, `storeString`, and `publishEvent` to omit `responseKey` when not needed.
|
||||
- The native Swift domain enum file should remain as the canonical location for XFlow domain enums after removal of GraphQL-generated code.
|
||||
- Jeff directed David to move the ticket to Done, while keeping the PR unmerged for at least 30 days.
|
||||
- Branch maintenance is now part of the work: keep the GraphQL/Apollo-removal branch up to date with `main` until the REST backend/toggle validation window allows merge. If future `main` merges create conflicts that look non-trivial, raise it so a 1-2 point maintenance story can be created.
|
||||
- May 11 preparation for another REST-layer validation meeting: Fid4 `4.32` was checked out in a separate folder, aligned to the published/internal build `Podfile.lock` from iOSInstaller, and built successfully. Current XQ1 behavior appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST; `Open an account` is the simplest non-authenticated XFlow entry point to use for a quick readiness test.
|
||||
- Jeff confirmed May 11 that the REST back end has now been deployed, and a meeting is scheduled for May 12 with the team lead and Bruce to toggle the flag and test both REST and non-REST states.
|
||||
- REST detection for the meeting: Charles Proxy to verify `/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. 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. Treat this as evidence that the production REST path can activate on iOS when the LD targeting context matches.
|
||||
|
||||
---
|
||||
|
||||
## Sequencing
|
||||
|
||||
- This story remains sequenced before `PDIAP-15836`.
|
||||
- This branch should merge to `main` before the future `PDIAP-15836` / `PDIAP-12284` branch is updated and merged.
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
type: work-item
|
||||
project: fidelity
|
||||
status: done
|
||||
ticket: PDIAP-16167
|
||||
title: AccountLink - XFlow causing web view rewrites investigation
|
||||
systems: [xflowsdk, xflowviewmaker, fttransfer]
|
||||
workstreams: [ao-discourse, consumer-integration]
|
||||
people: [jeff-dewitte, zachary-boutyard]
|
||||
related: [pdiap-15836]
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
- discourse
|
||||
- swiftui
|
||||
updated: 2026-05-05
|
||||
---
|
||||
|
||||
# PDIAP-16167 - AccountLink - XFlow causing web view rewrites investigation
|
||||
|
||||
## Status
|
||||
|
||||
- Done
|
||||
- Confluence report published
|
||||
- Findings/comment sent to Zachary and posted for Jira/Discourse follow-up
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- Discourse 30181: FTTransfer (Zachary) reported that the AccountLink webview reloads / goes blank when the user taps the exit button in the FTTransfer playground.
|
||||
- Zachary believes the issue is "new" and linked to a recent XFlow version change.
|
||||
|
||||
---
|
||||
|
||||
## Confirmed Findings
|
||||
|
||||
- **Root Cause:** SwiftUI Identity Reset (Modifier-Site Teardown). The `.ftFullScreenCover` modifier was anchored to a volatile branch inside `BankInformationView`. When the webview triggered an exit alert, the environment republish dismantled that volatile branch and rebuilt the presenter off-screen, causing the blank screen.
|
||||
- **XFlow is NOT the cause:** XFlow eventing fires once to toggle a boolean and exits. The teardown happens later on a local JS/alert callback. XFlow does not mutate view identity, host lifecycle, or alert state.
|
||||
- **v0.1.0 Rollback Proof:** The issue persists identically when rolling back XFlowSDK to v0.1.0 (pre-REST, pre-Apollo removal), empirically proving the defect is decoupled from the SDK's recent evolution.
|
||||
- **Comparative Analysis:** The non-XFlow entry point (Zachary's alternative flow) survives because it uses a stable coordinator boundary (`BankSetupContainerView` / `NavigationStack`), bypassing the fragile modifier placement.
|
||||
|
||||
---
|
||||
|
||||
## Verified Resolution
|
||||
|
||||
- Moving the `.ftFullScreenCover` and the `shouldShowWebView` observer to the **stable root** of `BankInformationView` resolves the issue. Pure SwiftUI fix, no UIKit workarounds needed.
|
||||
- Jeff acknowledged the fix and asked to include it in the Confluence report.
|
||||
|
||||
---
|
||||
|
||||
## Current Guidance
|
||||
|
||||
- Keep future references clear that this was documented as a consumer-side SwiftUI presentation-topology defect, not an XFlow/XFlowViewMaker regression.
|
||||
- Include Jeff's preferred clarification that `XFlowSDK v0.1.0` predates the REST and Apollo-related changes that were newer additions.
|
||||
|
||||
---
|
||||
|
||||
## Closure Notes
|
||||
|
||||
- The published recommendation is to move the full-screen cover modifier to the stable root of `BankInformationView`, outside the conditional branch.
|
||||
- David moved the story to Done on 2026-05-05.
|
||||
Reference in New Issue
Block a user