diff --git a/project-knowledge/01-current/current-work.md b/project-knowledge/01-current/current-work.md index 23368f8..64f27cc 100644 --- a/project-knowledge/01-current/current-work.md +++ b/project-knowledge/01-current/current-work.md @@ -2,7 +2,7 @@ type: current project: fidelity status: active -updated: 2026-05-13 +updated: 2026-05-14 tags: - current-work - fidelity @@ -25,8 +25,12 @@ tags: - 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. - After manual dependency/build handling, Fid4 now compiles with the latest `FlowViewBuilder` shape. Next validation should be runtime log evidence: confirm a representative flow selects the default SwiftUI host path, then simulate/force `iOS-XflowUIKitHostEnabled == true` to confirm the temporary UIKit host path and dismissal-completion behavior. -- `PDIAP-12284` moved to In Progress on May 12. `PDIAP-15836` may become a subtask of `PDIAP-12284`; final Jira structure and point handling are pending Quy/Jeff direction. +- `PDIAP-12284` moved to In Progress on May 12. Quy confirmed on May 13 that `PDIAP-12284` and `PDIAP-15836` can both remain In Progress together, so no immediate Jira restructuring is required. - 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. +- May 13 AccountLink runtime validation looks good in both host modes: SwiftUI-default and forced UIKit-host paths selected the expected host branch and preserved dismissal sequencing, with delegate/session teardown after confirmed dismissal. Before push, clean temporary debug prints and consider moving dismissal-specific helper types out of `XFlowManager.swift` into a dedicated dismissal file. +- Follow-up SampleApp validation found a likely branch-introduced dismissal regression caused by host-mode mismatch: SampleApp uses `initialViewController(...)` / UIKit presentation, but the branch defaulted manager host mode to SwiftUI, so `endActivity` can take the SwiftUI subject path without a SwiftUI dismissal host subscriber. Fix direction should preserve existing behavior by keeping `initialViewController(...)` on the UIKit dismiss-completion path and `makeInitialFlowView(...)` on the SwiftUI lifecycle path. +- SampleApp should support explicit validation of both UIKit-host and SwiftUI-host scenarios. XFlowSDK should remain self-aware of which dismissal mechanism to use based on the active integration path, so SampleApp can exercise both paths without relying on stale singleton/default host-mode state. +- May 14 SampleApp iteration: SampleApp was updated to choose between UIKit-host (`initialViewController(...)`) and SwiftUI-host (`makeInitialFlowView(...)`) paths from the existing `Use SwiftUI` setting / feature-toggle path. XFlowSDK entrypoints now prepare the matching dismissal mechanism, and the SampleApp SwiftUI-host rendering was refined to use a `ViewBuilder`/`flowContent` approach rather than storing an `AnyView` in state. Next validation is SampleApp back-to-back host-mode switching plus Fid4 AccountLink revalidation in both host modes. - 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 - Thoroughly verify current `ApexBridgingAddressComponent` / rule-loading usage before describing it as inactive or dead code diff --git a/project-knowledge/01-current/work-items.md b/project-knowledge/01-current/work-items.md index fc056d7..ea7fc99 100644 --- a/project-knowledge/01-current/work-items.md +++ b/project-knowledge/01-current/work-items.md @@ -2,7 +2,7 @@ type: current-work-items project: fidelity status: active -updated: 2026-05-13 +updated: 2026-05-14 tags: - current-work - work-item @@ -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: moved to In Progress on May 12 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. Fid4 now compiles after manual dependency/build handling; next validation is runtime log evidence for default SwiftUI host first, then forced UIKit-host flag behavior. `PDIAP-15836` may become a subtask pending final Jira/points direction. + Current note: moved to In Progress on May 12 and should be handled with `PDIAP-15836` in the same branch. Quy confirmed both stories can remain In Progress together, so no immediate Jira restructuring is required. 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. Fid4 now compiles after manual dependency/build handling. May 13 AccountLink runtime validation looks good for both SwiftUI-default and forced UIKit-host paths. May 14 SampleApp work added explicit UIKit-host vs SwiftUI-host validation paths and refined SwiftUI-host rendering to avoid local `AnyView` state, using a `ViewBuilder`/`flowContent` path instead. Next validation is SampleApp back-to-back mode switching and Fid4 AccountLink revalidation in both host modes. ## Backlog / Future Reference diff --git a/project-knowledge/02-work-items/IA improvements.md b/project-knowledge/02-work-items/IA improvements.md index 793ca9e..13d454c 100644 --- a/project-knowledge/02-work-items/IA improvements.md +++ b/project-knowledge/02-work-items/IA improvements.md @@ -20,3 +20,5 @@ - Start as a service - Auto categorize by context - Multi photos session, copy multiples images in clipboard +- Swiftlint integration + - Auto validator diff --git a/project-knowledge/02-work-items/pdiap-12284.md b/project-knowledge/02-work-items/pdiap-12284.md index 12752bb..853c634 100644 --- a/project-knowledge/02-work-items/pdiap-12284.md +++ b/project-knowledge/02-work-items/pdiap-12284.md @@ -8,7 +8,7 @@ systems: [xflowsdk, xflowviewmaker] workstreams: [xflow-swiftui-migration, consumer-integration] people: [jeff-dewitte] related: [pdiap-15836, pdiap-15838] -updated: 2026-05-13 +updated: 2026-05-14 tags: - work-item - fidelity @@ -28,7 +28,13 @@ tags: - 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. - After manual dependency/build handling, Fid4 now compiles with the latest `FlowViewBuilder` shape. Next validation should be runtime evidence: first verify a representative flow selects the default SwiftUI host path, then simulate/force `iOS-XflowUIKitHostEnabled == true` to verify the temporary UIKit host path and dismissal behavior. -- `PDIAP-15836` may become a subtask of this story; final Jira structure and point handling are pending Quy/Jeff direction. +- Quy confirmed on May 13 that this story and `PDIAP-15836` can both remain In Progress together, so no immediate Jira restructuring is required. +- May 13 AccountLink runtime validation looks good in both host modes. The SwiftUI-default path and forced UIKit-host path selected the expected branch and preserved dismissal sequencing; no AccountLink issue was observed in either mode during these runs. +- Before push, cleanup should remove temporary `XFlow-DISMISS-DEBUG` prints and consider moving dismissal-specific helper types out of `XFlowManager.swift` into a dedicated dismissal file. +- Follow-up SampleApp validation found a likely host-mode mismatch regression introduced by the branch: `initialViewController(...)` still represents the UIKit presentation path, but manager state could remain on SwiftUI host mode and route `endActivity` through the SwiftUI dismissal subject without an active `XFlowDismissalHost`. The minimal fix should preserve existing behavior by forcing/setting UIKit host mode for `initialViewController(...)` and SwiftUI host mode for `makeInitialFlowView(...)`. +- SampleApp should be updated to support explicit validation of both UIKit-host and SwiftUI-host modes. The SDK should choose the appropriate dismissal mechanism from the active integration path, not from stale/default host-mode state. +- May 14 SampleApp iteration updated the sample to exercise both host scenarios explicitly: UIKit-host through `initialViewController(...)` and SwiftUI-host through `makeInitialFlowView(...)`, selected by the existing `Use SwiftUI` / feature-toggle path. XFlowSDK entrypoints should prepare their own matching dismissal mechanism so `endActivity` cannot route to the SwiftUI subject unless the SwiftUI host is actually active. +- The SampleApp SwiftUI-host rendering was refined to avoid storing `AnyView` in state; SwiftUI-host content now lives behind a `ViewBuilder` / `flowContent` rendering path. This keeps local SampleApp code aligned with the branch goal of avoiding unnecessary `AnyView`, while preserving type erasure only at true public boundaries such as the existing XFlowViewMaker boundary if still required. --- @@ -41,6 +47,7 @@ tags: - 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. - 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. +- SampleApp-specific rendering should not reintroduce `AnyView` just to switch between validation paths. Prefer view-builder composition plus state that represents the selected host path, plugins, and controller. --- diff --git a/project-knowledge/02-work-items/pdiap-15836.md b/project-knowledge/02-work-items/pdiap-15836.md index 3169457..9bcd65e 100644 --- a/project-knowledge/02-work-items/pdiap-15836.md +++ b/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-12 +updated: 2026-05-14 tags: - work-item - fidelity @@ -24,6 +24,9 @@ tags: - 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. +- May 13 AccountLink runtime validation looks good in both SwiftUI-default and forced UIKit-host modes. Both paths preserved the intended dismissal sequencing, with delegate callbacks and session cleanup after confirmed dismissal. +- May 14 SampleApp work refined dismissal validation coverage: SampleApp can exercise both UIKit-host and SwiftUI-host paths, while XFlowSDK entrypoints prepare the matching dismissal mechanism for the active integration path. This supports validating that UIKit dismiss completion and SwiftUI `XFlowDismissalHost` lifecycle sequencing both converge on the canonical delegate/session teardown path. +- Quy confirmed on May 13 that this story and `PDIAP-12284` can both remain In Progress together, so no immediate Jira restructuring is required. - Sequenced after `PDIAP-15838` source work, but merge/release is delayed until after REST-transition consumer validation - Sized at `8` points @@ -55,6 +58,7 @@ tags: - 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. - Current validation logs did not show the key failure patterns for the tested run, such as delegate firing before host-disappearance confirmation or repeated host-disappearance confirmation for the same dismissal id. +- SampleApp should be used as a guardrail for stale host-mode state by running UIKit-host and SwiftUI-host flows back-to-back without restarting the app. - 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. --- diff --git a/project-knowledge/06-daily/2026-05-13.md b/project-knowledge/06-daily/2026-05-13.md index 7930601..34c6e2c 100644 --- a/project-knowledge/06-daily/2026-05-13.md +++ b/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. --- diff --git a/project-knowledge/06-daily/2026-05-14.md b/project-knowledge/06-daily/2026-05-14.md new file mode 100644 index 0000000..b189cee --- /dev/null +++ b/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.