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

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

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
 

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

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
 

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.