From 46c7ce2824512e80445c93083fa34809974c7a9c Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Mon, 11 May 2026 07:15:34 -0600 Subject: [PATCH] refactor: update work items and daily logs for PDIAP-12284 and PDIAP-15836, enhancing host-mode resolution strategy and lifecycle sequencing --- project-knowledge/01-current/current-work.md | 2 ++ project-knowledge/01-current/work-items.md | 4 ++-- project-knowledge/02-work-items/pdiap-12284.md | 5 +++++ project-knowledge/02-work-items/pdiap-15836.md | 2 ++ project-knowledge/03-context/systems/xflowviewmaker.md | 6 ++++-- .../03-context/workstreams/xflow-swiftui-migration.md | 7 +++++-- project-knowledge/06-daily/2026-05-08.md | 9 +++++++++ 7 files changed, 29 insertions(+), 6 deletions(-) diff --git a/project-knowledge/01-current/current-work.md b/project-knowledge/01-current/current-work.md index ac64bf0..501d3da 100644 --- a/project-knowledge/01-current/current-work.md +++ b/project-knowledge/01-current/current-work.md @@ -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 diff --git a/project-knowledge/01-current/work-items.md b/project-knowledge/01-current/work-items.md index 8cfdcde..9207d30 100644 --- a/project-knowledge/01-current/work-items.md +++ b/project-knowledge/01-current/work-items.md @@ -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 diff --git a/project-knowledge/02-work-items/pdiap-12284.md b/project-knowledge/02-work-items/pdiap-12284.md index 0a3405d..e34ec51 100644 --- a/project-knowledge/02-work-items/pdiap-12284.md +++ b/project-knowledge/02-work-items/pdiap-12284.md @@ -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. diff --git a/project-knowledge/02-work-items/pdiap-15836.md b/project-knowledge/02-work-items/pdiap-15836.md index 59bb634..cb1bdba 100644 --- a/project-knowledge/02-work-items/pdiap-15836.md +++ b/project-knowledge/02-work-items/pdiap-15836.md @@ -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. --- diff --git a/project-knowledge/03-context/systems/xflowviewmaker.md b/project-knowledge/03-context/systems/xflowviewmaker.md index 618f9b1..efdd162 100644 --- a/project-knowledge/03-context/systems/xflowviewmaker.md +++ b/project-knowledge/03-context/systems/xflowviewmaker.md @@ -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. --- diff --git a/project-knowledge/03-context/workstreams/xflow-swiftui-migration.md b/project-knowledge/03-context/workstreams/xflow-swiftui-migration.md index d86f400..6ccd642 100644 --- a/project-knowledge/03-context/workstreams/xflow-swiftui-migration.md +++ b/project-knowledge/03-context/workstreams/xflow-swiftui-migration.md @@ -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. --- diff --git a/project-knowledge/06-daily/2026-05-08.md b/project-knowledge/06-daily/2026-05-08.md index fb90b29..32b1caa 100644 --- a/project-knowledge/06-daily/2026-05-08.md +++ b/project-knowledge/06-daily/2026-05-08.md @@ -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. ---