diff --git a/project-knowledge/01-current/current-work.md b/project-knowledge/01-current/current-work.md index 501d3da..3f0bfd1 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-08 +updated: 2026-05-11 tags: - current-work - fidelity @@ -22,6 +22,7 @@ tags: - `PDIAP-12284` remains paired with `PDIAP-15836`; plan the branch as combined UIKit-removal / SwiftUI lifecycle work rather than splitting the dismissal sequencing into an independently merged path unless direction changes. - Current `PDIAP-12284` implementation direction is to explore XFlowViewMaker-owned global host-mode resolution rather than Fid4-owned per-flow host-mode mapping: SwiftUI host should remain the default, missing/unknown feature configuration should also default to SwiftUI, and `UIHostingController` should be selected only through an explicit temporary fallback flag. - Keep host-mode resolution decoupled from XFlowSDK and app-specific LaunchDarkly/Flagship clients; XFlowSDK should consume a resolved host-mode decision, while Copilot/code inspection should confirm whether XFlowViewMaker can use existing `FeatureEnabling` / `Featuring` abstractions or needs a small dependency-injection path. +- 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. - 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 @@ -45,6 +46,7 @@ tags: - Jeff suggested broadening the investigation support path while direct Flagship LaunchDarkly access is still missing: monitor the Tauf thread, follow up with Jeffrey O'Leary, package the scenario for the AI tool with build settings and tool details, and ask Aylwing for a quick perspective if available - The Fidelity-side AI tool Jeff referenced for this investigation is GitHub Copilot - Jeff later relayed that Adam says the latest build is now activating REST correctly, so David should switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles +- For the upcoming REST-layer validation meeting, David prepared Fid4 `4.32` in a separate folder on the release branch, aligned it with the published/internal build `Podfile.lock` from iOSInstaller, and verified the project builds. Current XQ1 behavior appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST; `Open an account` is the simplest non-authenticated entry point for quick XFlow validation. - `PDIAP-15838` draft PR has reached external review; Bruce left minor feedback, David addressed it, and Jeff directed David to move the ticket to Done while holding the merge - Do not merge the GraphQL/Apollo removal PR until REST backend is live in production and the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for at least 30 days without issues - Current `PDIAP-15838` follow-up centers on the `PicoSDK` update in `SampleApp`: the newer Pico path removes the remaining transitive Apollo dependency, re-enables FGO and FidFolios testing in `SampleApp`, and aligns the sample implementation with current Fid4 usage @@ -83,6 +85,7 @@ tags: - Adam reported the earlier REST activation problem, and he or his team validate behavior on real devices rather than simulator-only paths - Avoid treating GitHub Copilot or LaunchDarkly as story-specific tools; both are broader Fidelity workflow tools that happened to matter in this investigation - Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement +- Current Fid4 validation logs include duplicate Objective-C class warnings for `Secure` / `DeviceRisk` symbols loaded from both `SecureDocV.framework` and `Fid4.debug.dylib`; treat this as environment/integration noise unless runtime behavior points to a validation blocker, and redact raw device-token prints before sharing logs. - Keep Apollo-removal / REST-migration cleanup grounded in production readiness: source-level cleanup can continue, but merge/release timing depends on the prior REST-toggle implementation being QA-tested and stable in production for the agreed window - Keep the GraphQL/Apollo removal branch and the future `PDIAP-15836` / `PDIAP-12284` branch current with `main`; if conflict resolution looks non-trivial, flag it so a 1-2 point branch-maintenance story can be created - Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope diff --git a/project-knowledge/01-current/work-items.md b/project-knowledge/01-current/work-items.md index 9207d30..df4a4c8 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-08 +updated: 2026-05-11 tags: - current-work - work-item @@ -24,11 +24,11 @@ Update the per-ticket files first when scope, status, sequencing, or communicati - `PDIAP-15836` - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment Detail: `project-knowledge/02-work-items/pdiap-15836.md` - Current note: moved to In Progress on May 7. David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, but Jeff directed David to do the dismissal/lifecycle work and `PDIAP-12284` UIKit-removal work in the same branch because both changes require consumer testing. The SwiftUI path still needs proof that delegate/session-clear callbacks fire only after dismissal completion. + Current note: moved to In Progress on May 7. David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, but Jeff directed David to do the dismissal/lifecycle work and `PDIAP-12284` UIKit-removal work in the same branch because both changes require consumer testing. A May 11 simulator log review suggests the tested SwiftUI-host path fires delegate/session-clear callbacks only after host-disappearance confirmation, but broader branch and consumer validation are still needed. - `PDIAP-12284` - Remove UIKit wrapping from XFlow Detail: `project-knowledge/02-work-items/pdiap-12284.md` - Current note: reopened after rollback 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; merge/release still waits until after REST-transition consumer validation. + Current note: reopened after rollback 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 11 validation is promising for dismissal sequencing, but merge/release still waits until after REST-transition consumer validation. ## Backlog / Future Reference diff --git a/project-knowledge/02-work-items/pdiap-12284.md b/project-knowledge/02-work-items/pdiap-12284.md index e34ec51..5eed1c0 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-08 +updated: 2026-05-11 tags: - work-item - fidelity @@ -24,6 +24,7 @@ tags: - 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. +- 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. --- @@ -34,6 +35,7 @@ tags: - 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. +- 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. --- diff --git a/project-knowledge/02-work-items/pdiap-15836.md b/project-knowledge/02-work-items/pdiap-15836.md index cb1bdba..325b23c 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-08 +updated: 2026-05-11 tags: - work-item - fidelity @@ -22,6 +22,7 @@ tags: - Moved to In Progress on May 7. - David found a possible minimal dismissal fix path that would not require removing `UIHostingController`, and was validating it. - 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. - Sequenced after `PDIAP-15838` source work, but merge/release is delayed until after REST-transition consumer validation - Sized at `8` points @@ -52,6 +53,7 @@ tags: - 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. +- 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. - 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/02-work-items/pdiap-15838.md b/project-knowledge/02-work-items/pdiap-15838.md index 505785b..6bd5b9c 100644 --- a/project-knowledge/02-work-items/pdiap-15838.md +++ b/project-knowledge/02-work-items/pdiap-15838.md @@ -8,7 +8,7 @@ systems: [xflowsdk] workstreams: [rest-migration] people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas] related: [launchdarkly, github-copilot] -updated: 2026-05-05 +updated: 2026-05-11 tags: - work-item - fidelity @@ -88,6 +88,7 @@ tags: - The native Swift domain enum file should remain as the canonical location for XFlow domain enums after removal of GraphQL-generated code. - Jeff directed David to move the ticket to Done, while keeping the PR unmerged for at least 30 days. - Branch maintenance is now part of the work: keep the GraphQL/Apollo-removal branch up to date with `main` until the REST backend/toggle validation window allows merge. If future `main` merges create conflicts that look non-trivial, raise it so a 1-2 point maintenance story can be created. +- May 11 preparation for another REST-layer validation meeting: Fid4 `4.32` was checked out in a separate folder, aligned to the published/internal build `Podfile.lock` from iOSInstaller, and built successfully. Current XQ1 behavior appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST; `Open an account` is the simplest non-authenticated XFlow entry point to use for a quick readiness test. --- diff --git a/project-knowledge/06-daily/2026-05-11.md b/project-knowledge/06-daily/2026-05-11.md new file mode 100644 index 0000000..4111375 --- /dev/null +++ b/project-knowledge/06-daily/2026-05-11.md @@ -0,0 +1,54 @@ +--- +type: daily +project: fidelity +date: 2026-05-11 +status: active +focus: [pdiap-12284, pdiap-15836, pdiap-15838] +work-items: [PDIAP-12284, PDIAP-15836, PDIAP-15838] +blockers: [fid4-validation-environment-warnings] +tags: + - daily + - fidelity +updated: 2026-05-11 +--- + +# 2026-05-11 + +## Focus + +- Continue the combined `PDIAP-12284` / `PDIAP-15836` work, with emphasis on the `PDIAP-12284` SwiftUI-host / UIKit-wrapper-removal path and dismissal-sequencing validation. +- Prepare Fid4 `4.32` for a likely REST-layer validation meeting, including release-branch setup, published `Podfile.lock` alignment, and XFlow entry-point readiness. + +--- + +## Work Done + +- Continued the `PDIAP-12284` implementation/validation loop with Copilot using a simulator console log from the current session. +- Prepared a separate Fid4 project folder on the `4.32` release branch and used the `Podfile.lock` from the published/internal `4.32` build downloaded through iOSInstaller. +- Built the Fid4 `4.32` setup successfully to verify readiness for the upcoming REST-layer validation session. + +--- + +## Findings + +- The latest log review reported two dismissal sequences with the expected order: `endActivity` requested, dismiss requested, host received dismiss request, host disappearance confirmed, `fireEndActivityDelegates`, delegate event/exit callbacks, then `activitySession` cleared. +- The log review did not surface the key failure patterns that would invalidate the dismissal sequencing, such as delegate firing before host-disappearance confirmation or multiple host-disappearance confirmations for the same dismissal id. +- Remaining non-XFlow log noise appears to be environment/integration related: Objective-C duplicate class warnings for `Secure` / `DeviceRisk` symbols from both `SecureDocV.framework` and `Fid4.debug.dylib`, Firebase configuration warnings, simulator noise, and raw device-token prints. +- Treat the dismissal sequencing result as a promising validation run, but avoid calling the full story complete until the branch is reviewed and any required consumer validation is done. +- Current XQ1 validation appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST even before the planned toggle-change meeting. +- The simplest non-authenticated Fid4 entry point identified for quick XFlow validation is `Open an account`. + +--- + +## Next Steps + +- Continue reviewing the `PDIAP-12284` implementation and confirm the SwiftUI-host default path and temporary UIKit-hosted path are both routed and validated as intended. +- Decide whether the duplicate `Secure` / `DeviceRisk` class warnings are only known environment noise or need separate follow-up before relying on the validation session. +- Avoid sharing raw logs without redacting device-token prints. +- Re-run a quick Fid4 `4.32` smoke test through `Open an account` and any other known entry points before the REST-layer validation meeting. + +--- + +## Blockers + +- No story blocker confirmed, but the Fid4 validation session includes duplicate-class warnings that may need triage if runtime casting/crash behavior appears during validation. diff --git a/prompts/standup.md b/prompts/standup.md index f88ecaf..3609918 100644 --- a/prompts/standup.md +++ b/prompts/standup.md @@ -39,6 +39,7 @@ Generate a standup update for the active project profile. - On Mondays, use Friday's work context unless a later prior day has Mattermost activity - If the previous calendar day has no work activity or is OOO/weekend, use the latest prior day with Mattermost activity - Treat the previous workday communication context as the primary source for the previous-work section +- When the previous-workday evidence is itself a standup, do not promote that standup's nested `Yesterday` lines as work performed on the previous workday. Use same-day follow-up evidence, same-day daily logs, or explicit user-provided context for what actually happened on that date. - If a latest daily log exists, use its `Work Done` and same-day findings as the primary source for `Yesterday`; use current memory only to disambiguate, not to backfill unrelated older events - Do not reuse older investigation context from `current-work.md` as `Yesterday` unless the latest daily log or previous-workday communication confirms it happened on that workday - Prefer updates directly tied to active work items over side questions, context refreshes, or manager-only reminders