feat: update daily logs and work items with May 14 entries, including validation progress for PDIAP-12284 and PDIAP-15836

project-knowledge/06-daily/2026-05-13.md

@@ -23,12 +23,16 @@ updated: 2026-05-13
 ## Work Done
 
 - In yesterday's REST validation meeting, the initial production-environment check showed GraphQL when Fid4 was only pointed at production. The fuller meeting result was that iOS successfully validated REST after Raj enabled the production LaunchDarkly toggle for the specific production test user context, targeting the MID for the account tested with Bruce.
+- Runtime validation for the combined `PDIAP-12284` / `PDIAP-15836` branch now looks good for AccountLink in both host modes. The SwiftUI-default path and forced UIKit-host path both showed consistent host selection and preserved dismissal sequencing, with delegate/session teardown after confirmed dismissal. No AccountLink issue was observed in either host mode during these runs.
 
 ---
 
 ## Findings
 
 - Do not summarize yesterday's REST validation only as "production still used GraphQL." The accurate framing is that plist-only production environment selection was insufficient, but production LaunchDarkly targeting for the tested user's MID activated REST successfully on iOS.
+- Cleanup/review focus before push: remove temporary `XFlow-DISMISS-DEBUG` prints and consider moving new dismissal-specific helper types out of `XFlowManager.swift` into a dedicated file so `XFlowManager` keeps orchestration responsibilities while dismissal lifecycle state stays isolated.
+- Follow-up SampleApp validation found a likely branch-introduced dismissal regression: SampleApp uses `initialViewController(...)` and presents a UIKit controller path, but the branch defaulted `presentationHostMode` to SwiftUI, so `endActivity` could publish to the SwiftUI dismissal subject even though no `XFlowDismissalHost` subscriber was created. The minimal fix direction is to keep `initialViewController(...)` on the UIKit host/dismiss-completion path while leaving `makeInitialFlowView(...)` on the SwiftUI host path.
+- Updated SampleApp direction: SampleApp should be able to switch between UIKit-host and SwiftUI-host scenarios for validation, while XFlowSDK should infer/use the correct dismissal mechanism from the integration path rather than relying on stale/default host-mode state.
 
 ---
 
@@ -40,7 +44,7 @@ updated: 2026-05-13
 
 ## Next Steps
 
-- Focus today on the combined `PDIAP-12284` / `PDIAP-15836` runtime validation: default SwiftUI host path first, then explicit UIKit-host flag path.
+- Prepare the combined `PDIAP-12284` / `PDIAP-15836` branch for push: clean temporary debug instrumentation, consider extracting dismissal helper types from `XFlowManager.swift`, run a final compile/lint or targeted validation pass, and preserve the AccountLink host-mode validation evidence for the PR/Jira update.
 
 ---
 

project-knowledge/06-daily/2026-05-14.md

@@ -0,0 +1,40 @@
+---
+type: daily
+project: fidelity
+date: 2026-05-14
+updated: 2026-05-14
+focus:
+  - PDIAP-12284
+  - PDIAP-15836
+work-items:
+  - PDIAP-12284
+  - PDIAP-15836
+blockers: []
+tags:
+  - daily
+  - fidelity
+---
+
+# 2026-05-14
+
+## Focus
+
+- Continue `PDIAP-12284` / `PDIAP-15836` validation and cleanup for SwiftUI-host vs UIKit-host routing and dismissal sequencing.
+
+---
+
+## Findings
+
+- May 13 refreshed communication confirmed Quy said `PDIAP-12284` and `PDIAP-15836` can both remain In Progress together; no immediate Jira restructuring is required.
+- SampleApp validation support was refined so the app can exercise both host scenarios explicitly: UIKit host through `initialViewController(...)` and SwiftUI host through `makeInitialFlowView(...)`.
+- XFlowSDK routing should remain entrypoint-aware: the SwiftUI entrypoint prepares SwiftUI host state and clears UIKit bridge state, while the UIKit entrypoint prepares UIKit host state. This prevents `endActivity` from publishing to the SwiftUI dismissal subject when no `XFlowDismissalHost` subscriber exists.
+- Follow-up SampleApp changes removed the local `AnyView` state/storage approach and moved SwiftUI-host rendering behind a `ViewBuilder`-style `flowContent` path. This keeps `AnyView` out of SampleApp and leaves type erasure only at boundaries that truly require it, such as the existing XFlowViewMaker public boundary if still needed.
+- Current SampleApp host-mode validation still appears to depend on a deprecated `enable-swift-ui` toggle. Next source review should align SampleApp flag evaluation with the Fid4-style path for the specific rollback flag that enables the UIKit host, while keeping SwiftUI as the default path.
+
+## Validation To Run
+
+- In SampleApp, validate UIKit-host mode by turning `Use SwiftUI` off, launching a flow, completing to `endActivity`, and confirming dismissal uses UIKit dismiss completion and returns to the list.
+- In SampleApp, validate SwiftUI-host mode by turning `Use SwiftUI` on, launching the same flow, completing to `endActivity`, and confirming dismissal goes through `XFlowDismissalHost` lifecycle sequencing and returns to the list.
+- Repeat both modes back-to-back without restarting the app to guard against stale singleton/default host-mode state.
+- Re-run Fid4 AccountLink validation in default SwiftUI-host and forced UIKit-host modes after the SampleApp changes settle.
+- After updating SampleApp flag evaluation, validate that the explicit UIKit-host rollback flag selects the UIKit path and that the default/missing/false value selects the SwiftUI path, matching Fid4 behavior as closely as the sample infrastructure allows.