david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: update implementation details for PDIAP-12284 and PDIAP-15836, including host-mode API changes and dependency alignment

Browse Source
This commit is contained in:
David Delagneau
2026-05-12 08:00:14 -06:00
parent 12f3e74d39
commit bc467c8a8c
5 changed files with 56 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
project-knowledge/02-work-items/pdiap-12284.md
View File

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