From bc467c8a8c9797171daf66b67ac473a2cd947109 Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Tue, 12 May 2026 08:00:14 -0600 Subject: [PATCH] feat: update implementation details for PDIAP-12284 and PDIAP-15836, including host-mode API changes and dependency alignment --- project-knowledge/01-current/current-work.md | 2 + project-knowledge/01-current/work-items.md | 2 +- .../02-work-items/pdiap-12284.md | 4 +- .../02-work-items/pdiap-15836.md | 3 +- project-knowledge/06-daily/2026-05-12.md | 48 +++++++++++++++++++ 5 files changed, 56 insertions(+), 3 deletions(-) create mode 100644 project-knowledge/06-daily/2026-05-12.md diff --git a/project-knowledge/01-current/current-work.md b/project-knowledge/01-current/current-work.md index 43003eb..e60fb86 100644 --- a/project-knowledge/01-current/current-work.md +++ b/project-knowledge/01-current/current-work.md @@ -22,6 +22,8 @@ tags: - `PDIAP-12284` remains paired with `PDIAP-15836`; plan the branch as combined UIKit-removal / SwiftUI lifecycle work rather than splitting the dismissal sequencing into an independently merged path unless direction changes. - Current `PDIAP-12284` implementation direction is to explore XFlowViewMaker-owned global host-mode resolution rather than Fid4-owned per-flow host-mode mapping: SwiftUI host should remain the default, missing/unknown feature configuration should also default to SwiftUI, and `UIHostingController` should be selected only through an explicit temporary fallback flag. - Keep host-mode resolution decoupled from XFlowSDK and app-specific LaunchDarkly/Flagship clients; XFlowSDK should consume a resolved host-mode decision, while Copilot/code inspection should confirm whether XFlowViewMaker can use existing `FeatureEnabling` / `Featuring` abstractions or needs a small dependency-injection path. +- May 12 implementation pass for `PDIAP-12284` / `PDIAP-15836` indicates the host-mode API is branch-local/new, keeps two enum types to preserve the XFlowViewMaker/XFlowSDK boundary, uses neutral `swiftUIHost` / `uiKitHost` cases, sets the feature flag key to `iOS-XflowUIKitHostEnabled`, defaults missing/false/unavailable values to SwiftUI, and removes `AnyView` from `buildFlow` internals while leaving it only at the existing public `FlowViewMaker` boundary. +- Current compile validation blocker for that branch appears to be dependency alignment: XFlowViewMaker's podspec resolves `XFlowSDK 2.8.48`, which does not expose the new host-mode API; XFlowSDK SwiftPM validation is also blocked in the current environment by missing `fidelity-src` registry configuration. - Latest `PDIAP-12284` / `PDIAP-15836` simulator log review suggests the SwiftUI-host dismissal sequence is firing in the intended order for the tested run: host disappearance is confirmed before `fireEndActivityDelegates`, delegate callbacks, and `activitySession` cleanup. Treat this as a promising validation run, not final story closure. - 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 diff --git a/project-knowledge/01-current/work-items.md b/project-knowledge/01-current/work-items.md index 88f0d5b..bf0530f 100644 --- a/project-knowledge/01-current/work-items.md +++ b/project-knowledge/01-current/work-items.md @@ -28,7 +28,7 @@ Update the per-ticket files first when scope, status, sequencing, or communicati - `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. 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. May 11 validation is promising for dismissal sequencing, but merge/release still waits until after REST-transition consumer validation. Jeff confirmed the feature flag strategy should be implemented in this branch. + 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. May 12 implementation pass resolved earlier shape concerns with neutral enum names, `iOS-XflowUIKitHostEnabled`, SwiftUI default semantics, and `AnyView` removed from builder internals. Remaining validation blocker appears to be dependency alignment: XFlowViewMaker is resolving `XFlowSDK 2.8.48`, which lacks the new host-mode API. ## Backlog / Future Reference diff --git a/project-knowledge/02-work-items/pdiap-12284.md b/project-knowledge/02-work-items/pdiap-12284.md index 2a56bef..d387183 100644 --- a/project-knowledge/02-work-items/pdiap-12284.md +++ b/project-knowledge/02-work-items/pdiap-12284.md @@ -26,6 +26,8 @@ tags: - 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. --- @@ -37,7 +39,7 @@ tags: - 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. -- Current code-review concerns to resolve before accepting the implementation: avoid unnecessary duplicate host-mode enums across XFlowViewMaker and XFlowSDK if one shared type can express the public contract safely; avoid naming that over-commits to `Fallback` if the toggle should be neutral and rollout-oriented; prefer a Fidelity-aligned boolean flag name using the `iOS-` prefix pattern when applicable; and review the new `AnyView` usage in `buildFlow` against safer SwiftUI alternatives. +- 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. --- diff --git a/project-knowledge/02-work-items/pdiap-15836.md b/project-knowledge/02-work-items/pdiap-15836.md index 325b23c..3169457 100644 --- a/project-knowledge/02-work-items/pdiap-15836.md +++ b/project-knowledge/02-work-items/pdiap-15836.md @@ -8,7 +8,7 @@ systems: [xflowsdk, xflowviewmaker, ftframeworks] workstreams: [xflow-swiftui-migration, consumer-integration] people: [jeff-dewitte] related: [pdiap-14859, pdiap-12284, pdiap-15838] -updated: 2026-05-11 +updated: 2026-05-12 tags: - work-item - fidelity @@ -23,6 +23,7 @@ tags: - 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. - Sequenced after `PDIAP-15838` source work, but merge/release is delayed until after REST-transition consumer validation - Sized at `8` points diff --git a/project-knowledge/06-daily/2026-05-12.md b/project-knowledge/06-daily/2026-05-12.md new file mode 100644 index 0000000..d860b03 --- /dev/null +++ b/project-knowledge/06-daily/2026-05-12.md @@ -0,0 +1,48 @@ +--- +type: daily +project: fidelity +date: 2026-05-12 +status: active +focus: [pdiap-12284, pdiap-15836] +work-items: [PDIAP-12284, PDIAP-15836] +blockers: [xflowviewmaker-xflowsdk-dependency-mismatch] +tags: + - daily + - fidelity +updated: 2026-05-12 +--- + +# 2026-05-12 + +## Focus + +- Continue the combined `PDIAP-12284` / `PDIAP-15836` implementation path for SwiftUI host-mode routing and dismissal sequencing. + +--- + +## Findings + +- Copilot's inspection says the host-mode API appears new in the current branch and is not present on `main` in `XFlowSDK`; XFlowViewMaker's `FlowConfig` host-mode shape also differs from `main`. That makes neutral enum-case renaming safer within this branch, pending normal review. +- The current implementation keeps two host-mode enum types to preserve the module boundary: XFlowViewMaker owns host-selection policy and XFlowSDK owns presentation mechanics. Conversion is intended to stay in one place in `FlowViewBuilder` with an explicit boundary comment. +- Enum cases were renamed to neutral names: `swiftUIHost` and `uiKitHost`. +- The final feature flag key is `iOS-XflowUIKitHostEnabled`. Semantics: `true` uses the temporary UIKit host path; `false`, missing, unavailable, or unknown uses the SwiftUI host. +- Old host-flag key usage was removed rather than dual-supported because it was not found in current code search outside the branch context. +- `AnyView` was removed from `buildFlow` internals by making the builder path type-safe with `ViewBuilder`; `AnyView` remains only at the existing `FlowViewMaker` public API boundary where `makeFlowView` currently returns `AnyView`. +- Files reported changed: `FlowConfig.swift`, `FlowViewBuilder.swift`, `FlowViewMaker.swift`, and `XFlowManager.swift`. +- Validation reported: SwiftUI remains the default host mode; explicit UIKit host path preserves dismissal-completion behavior; delegate callbacks/session cleanup still happen after confirmed dismissal; existing `FlowConfig` standard init call sites remain compatible; edited files had no file-level diagnostics. +- Build validation is not green yet. XFlowViewMaker's module build failed because its podspec currently resolves `XFlowSDK 2.8.48`, which does not expose the new host-mode type/API. XFlowSDK SwiftPM validation in that environment is also blocked by registry configuration: no registry configured for the `fidelity-src` scope. + +--- + +## Next Steps + +- Keep the implementation changes if the local diff matches the reported boundaries, then perform a minimal dependency-alignment follow-up so XFlowViewMaker validates against the updated XFlowSDK branch/API instead of pod version `2.8.48`. +- Separate code-correctness validation from environment/dependency blockers when reporting status. +- After dependency alignment, rerun the targeted symbol/error/compile pass to confirm no stale enum names, host defaults, or dismissal sequencing regressions remain. + +--- + +## Blockers + +- XFlowViewMaker compile validation is currently blocked by dependency mismatch against `XFlowSDK 2.8.48`, not by a confirmed code-level error in the host-mode changes. +- XFlowSDK SwiftPM validation is blocked in the current environment by missing `fidelity-src` registry configuration.