49 lines
3.1 KiB
Markdown
49 lines
3.1 KiB
Markdown
---
|
|
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.
|