refactor: update work items and daily logs for PDIAP-12284 and PDIAP-15836, enhancing host-mode resolution strategy and lifecycle sequencing

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.

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