refactor: update work items and daily logs for PDIAP-12284 and PDIAP-15836, enhancing host-mode resolution strategy and lifecycle sequencing
This commit is contained in:
@@ -20,6 +20,8 @@ tags:
|
||||
- `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.
|
||||
- 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
|
||||
|
||||
@@ -24,11 +24,11 @@ Update the per-ticket files first when scope, status, sequencing, or communicati
|
||||
|
||||
- `PDIAP-15836` - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
|
||||
Detail: `project-knowledge/02-work-items/pdiap-15836.md`
|
||||
Current note: moved to In Progress on May 7. David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, but Jeff directed David to do the dismissal/lifecycle work and `PDIAP-12284` UIKit-removal work in the same branch because both changes require consumer testing.
|
||||
Current note: moved to In Progress on May 7. David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, but Jeff directed David to do the dismissal/lifecycle work and `PDIAP-12284` UIKit-removal work in the same branch because both changes require consumer testing. The SwiftUI path still needs proof that delegate/session-clear callbacks fire only after dismissal completion.
|
||||
|
||||
- `PDIAP-12284` - Remove UIKit wrapping from XFlow
|
||||
Detail: `project-knowledge/02-work-items/pdiap-12284.md`
|
||||
Current note: reopened after rollback and should be handled with `PDIAP-15836` in the same branch. Jeff's current direction is to combine the UIKit-removal and dismissal/lifecycle changes because both are disruptive enough to require consumer testing; merge/release still waits until after REST-transition consumer validation.
|
||||
Current note: reopened after rollback and should be handled with `PDIAP-15836` in the same branch. Current implementation direction is to avoid Fid4 per-flow host-mode mapping and instead evaluate XFlowViewMaker-owned global host-mode resolution, with SwiftUI as default and `UIHostingController` only as an explicit temporary fallback; merge/release still waits until after REST-transition consumer validation.
|
||||
|
||||
## Backlog / Future Reference
|
||||
|
||||
|
||||
@@ -23,6 +23,7 @@ tags:
|
||||
- Reopened after rollback.
|
||||
- Quy already moved this story into the next sprint (`26Q2.6`); leave it in To Do until the sprint starts on Thursday.
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
@@ -30,6 +31,9 @@ tags:
|
||||
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
@@ -45,3 +49,4 @@ tags:
|
||||
|
||||
- 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.
|
||||
|
||||
@@ -40,6 +40,7 @@ tags:
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
@@ -50,6 +51,7 @@ tags:
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
@@ -3,8 +3,8 @@ type: system
|
||||
project: fidelity
|
||||
status: active
|
||||
workstreams: [consumer-integration, xflow-swiftui-migration]
|
||||
related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836]
|
||||
updated: 2026-04-17
|
||||
related: [xflowsdk, fid4, ftframeworks, consumer-integration, pdiap-14859, pdiap-15765, pdiap-15836, pdiap-12284]
|
||||
updated: 2026-05-08
|
||||
tags:
|
||||
- system
|
||||
- fidelity
|
||||
@@ -48,6 +48,8 @@ XFlowViewMaker is the adapter layer between XFlowSDK and consuming app/framework
|
||||
- If the issue involves version propagation into Fid4, treat XFlowViewMaker as part of the release path unless direct-consumption work has replaced it.
|
||||
- Current understanding is that Fid4 does not consume XFlowSDK directly; XFlowViewMaker remains the required integration layer for Fid4 and for other consumers such as `FTAccountOpen` and `FTTransfer`.
|
||||
- Questions about removing or collapsing the layer should be evaluated against current consumer integration patterns, not just local SDK behavior.
|
||||
- For the current `PDIAP-12284` / `PDIAP-15836` migration planning, XFlowViewMaker is the preferred candidate owner for global host-mode resolution if product-code inspection confirms it can access the existing feature-flag abstraction cleanly. This avoids Fid4-owned per-flow mapping and keeps XFlowSDK decoupled from app-specific LaunchDarkly/Flagship clients.
|
||||
- The desired host-mode behavior for that migration is SwiftUI host by default, SwiftUI host when feature configuration is missing or unknown, and `UIHostingController` only when an explicit temporary fallback flag requests it.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -3,9 +3,9 @@ type: workstream
|
||||
project: fidelity
|
||||
status: active
|
||||
systems: [xflowsdk, xflowviewmaker, ftframeworks, fid4]
|
||||
work-items: [pdiap-14859, pdiap-15836]
|
||||
work-items: [pdiap-14859, pdiap-15836, pdiap-12284]
|
||||
related: [consumer-integration, xflow-debugging]
|
||||
updated: 2026-04-16
|
||||
updated: 2026-05-08
|
||||
tags:
|
||||
- workstream
|
||||
- fidelity
|
||||
@@ -38,6 +38,9 @@ Track the durable behavior patterns introduced while moving XFlow from older ass
|
||||
- a lifecycle sequencing problem
|
||||
- a consumer presentation constraint in Fid4
|
||||
- Do not assume a visual issue is only cosmetic; several historical SwiftUI bugs changed flow behavior materially.
|
||||
- For UIKit-wrapping removal, prefer a host-mode design that keeps SwiftUI as the default and limits `UIHostingController` to an explicit temporary fallback. Missing or unknown rollout configuration should not silently restore the UIKit host.
|
||||
- Keep host-mode ownership at the shared integration layer when possible. A Fid4-only per-flow map is less reusable for XFlow's multiple consumers and creates cleanup work when the fallback is retired.
|
||||
- Dismissal sequencing changes must be validated as lifecycle contracts, not just visual symptom fixes: delegate/session-clear callbacks should fire after confirmed dismissal, and `onDisappear` should not be treated as sufficient proof without simulator-log evidence.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -23,24 +23,33 @@ updated: 2026-05-08
|
||||
## Work Done
|
||||
|
||||
- Mattermost sync confirmed David moved `PDIAP-15836` to In Progress and found a possible minimal dismissal fix path that would not require removing `UIHostingController`.
|
||||
- Refined the Copilot implementation direction for the combined `PDIAP-15836` / `PDIAP-12284` branch: evaluate XFlowViewMaker-owned global host-mode resolution instead of Fid4-owned per-flow mapping.
|
||||
- Friday standup reported `PDIAP-15836` as In Progress and aligned with `PDIAP-12284` so dismissal/lifecycle changes and UIKit-removal work can be handled in the same branch and validated together.
|
||||
- Friday standup reported continued `PDIAP-12284` evaluation around a dual-path strategy: SwiftUI host should become the default while preserving the current `UIHostingController` path temporarily for validation.
|
||||
|
||||
---
|
||||
|
||||
## Findings
|
||||
|
||||
- David's early `PDIAP-15836` finding was that the tested dismissal approach appeared coupled to the `UIHostingController` removal path, but he was investigating whether the lifecycle/dismissal fix could be isolated.
|
||||
- Current working design preference is SwiftUI host by default, including missing or unknown feature configuration; `UIHostingController` should be selected only by an explicit temporary fallback flag.
|
||||
- XFlowSDK should consume a resolved host-mode decision rather than depend directly on LaunchDarkly, Flagship, or app-specific feature-flag clients.
|
||||
- The SwiftUI dismissal path still needs evidence that delegate/session-clear callbacks fire only after dismissal completion; do not rely on `onDisappear` alone unless simulator logs validate it.
|
||||
|
||||
---
|
||||
|
||||
## Communication
|
||||
|
||||
- Jeff directed David to do the `PDIAP-15836` dismissal/lifecycle work and `PDIAP-12284` UIKit-removal work in the same branch, because both changes are disruptive enough to require consumer testing.
|
||||
- Jeff approved the Friday standup wording for Teams, and David sent it.
|
||||
- Jeff said he was traveling to Managua and asked David to monitor and respond on Teams while he was gone, asking for help if a message came in that David was unsure how to answer.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Treat `PDIAP-15836` and `PDIAP-12284` as same-branch work unless later direction changes; keep consumer-testing impact explicit.
|
||||
- Ask Copilot to inspect whether XFlowViewMaker can use existing `FeatureEnabling` / `Featuring` abstractions for global host-mode resolution; if not, have it return the smallest dependency-injection option instead of pushing per-flow logic into Fid4.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user