From fa1ab57de89a4b16a6a33d399ee0ce8054805927 Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Wed, 29 Apr 2026 07:39:55 -0600 Subject: [PATCH] feat: update daily logs and work items for 2026-04-29; refine Apollo removal strategy and address FTTransfer issue --- project-knowledge/01-current/current-work.md | 12 ++-- project-knowledge/01-current/work-items.md | 4 +- .../02-work-items/pdiap-15838.md | 11 +++- project-knowledge/06-daily/2026-04-28.md | 33 ++++++----- project-knowledge/06-daily/2026-04-29.md | 55 +++++++++++++++++++ project-knowledge/06-daily/index.md | 7 ++- 6 files changed, 99 insertions(+), 23 deletions(-) create mode 100644 project-knowledge/06-daily/2026-04-29.md diff --git a/project-knowledge/01-current/current-work.md b/project-knowledge/01-current/current-work.md index b76aed5..d3cc918 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-04-28 +updated: 2026-04-29 tags: - current-work - fidelity @@ -42,8 +42,12 @@ 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 -- Do not merge the GraphQL/Apollo removal PR until the REST backend is deployed to production; GraphQL fallback is still needed before then -- Current `PDIAP-15838` follow-up includes Fid4 validation, simulator-vs-device/generated-build configuration checks, and investigating the `PicoSDK` upgrade path for `SampleApp` because current `PicoSDK` usage still brings Apollo transitively +- `PDIAP-15838` draft PR is open for internal review; after internal review, send the link to Bruce +- Do not merge the GraphQL/Apollo removal PR until the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for 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 +- The `PicoSDK` update affects `SampleApp`, not the `XFlowSDK` production runtime directly +- The new Discourse / FTTransfer AccountLink issue is under investigation; Zachary believes it may come from XFlow, but ownership should not be stated until David reproduces it and confirms scope +- For the Discourse / FTTransfer issue, David has `FTTransferPlayground` running near Zachary's reported path but is currently blocked before the web view by phone-number verification / a Face ID-related error - Before closing out the AO thread, send one more working-group Teams reply that summarizes the original iOS issue, links the Jira comment, Discourse comment, and PR, and separates the remaining `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue - The `HybridBrokerageAccountOpening` / `JointIdentityCheck` rule-content issue appears unchanged between QA and Production in Cogstore and should be treated as the remaining service-side follow-up @@ -65,7 +69,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 -- Keep Apollo-removal / REST-migration cleanup grounded in backend readiness: source-level cleanup can continue, but merge/release timing depends on REST backend production deployment +- 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 - Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope - Avoiding assumptions about legacy Apex/ApexKit paths; breakpoint evidence and helper usage both need to be reconciled before reporting ownership or replacement guidance - When ownership is still uncertain under production pressure, prefer rollback-plus-investigation framing over confident blame assignment to consumers diff --git a/project-knowledge/01-current/work-items.md b/project-knowledge/01-current/work-items.md index 8b7fd46..502ae9e 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-04-28 +updated: 2026-04-29 tags: - current-work - work-item @@ -20,7 +20,7 @@ Update the per-ticket files first when scope, status, sequencing, or communicati - `PDIAP-15838` - Remove Apollo for iOS Detail: `project-knowledge/02-work-items/pdiap-15838.md` - Current note: active Apollo-removal cleanup and validation; do not merge the PR until the REST backend is deployed to production because GraphQL fallback is still needed. Current follow-up includes Fid4 validation, simulator-vs-device/generated-build configuration checks, and `PicoSDK` upgrade investigation for `SampleApp` because the current setup still brings Apollo transitively. + Current note: active Apollo-removal cleanup and validation; draft PR is open for internal review. `SampleApp` was updated to a newer `PicoSDK` path so Apollo is removed from the transitive sample-app dependency path too. Do not merge until the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for 30 days without issues. - `PDIAP-15836` - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment Detail: `project-knowledge/02-work-items/pdiap-15836.md` diff --git a/project-knowledge/02-work-items/pdiap-15838.md b/project-knowledge/02-work-items/pdiap-15838.md index 3300a9d..aa458e8 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-04-28 +updated: 2026-04-29 tags: - work-item - fidelity @@ -19,8 +19,8 @@ tags: ## Status -- Active Apollo-removal cleanup and validation -- PR merge should wait until the REST backend is deployed to production because GraphQL fallback is still needed before then +- Draft PR open for internal review +- PR merge should wait until the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for 30 days without issues - Sized at `8` points --- @@ -72,6 +72,11 @@ tags: - Apollo may still remain in the pod graph transitively through PicoSDK even after source-level cleanup, so "Apollo removed" should be framed carefully unless the dependency graph is also cleared. - Latest local follow-up suggests `SampleApp` depends on `PicoSDK`, and that transitive dependency may still be the practical reason Apollo remains in the pod graph. Newer `PicoSDK` versions no longer depend on Apollo, but the upgrade path does involve real breaking changes. The current investigation is to determine how `SampleApp` can absorb those changes by comparing against how `Fid4` currently uses `PicoSDK` for the two specific flows that still depend on it. - Jeff later confirmed that this `PicoSDK` / `SampleApp` cleanup is in scope for `PDIAP-15838` because Apollo needs to be removed from the project, including the transitive sample-app path. Keep the nuance explicit that this update affects `SampleApp`, not the `XFlowSDK` production runtime directly. +- David updated `SampleApp` to use the newer `PicoSDK` path, removing Apollo from the transitive sample-app dependency path and re-enabling the FGO and FidFolios flows for testing in `SampleApp`. +- The `SampleApp` Pico changes now more closely mirror how Pico is already used in Fid4. +- A draft PR has been opened for `PDIAP-15838 - Remove Apollo for iOS`; after internal review, the link should be sent to Bruce. +- Internal review found and resolved `PicoSDK` integration concerns: `TransactionContextManager(resolver:)` handles Pico setup internally in `PicoSDK 4.3.18` through lazy resolver-based initialization, the resolver already exists on `XFlowSampleAppViewModel`, and `PicoInterface` was minimally patched so the async completion path avoids a strong `self` capture and returns through `MainActor.run` for UI-state safety. +- The REST kill-switch removal is intentional for permanent GraphQL deprecation, but merge timing is gated: the previous REST-toggle implementation should first be QA-tested and active in production with REST enabled for all consumers for 30 days without issues. - Merge sequencing is now explicitly gated by backend production readiness: Bruce reinforced that the GraphQL/Apollo removal PR should not merge until the backend is in production because GraphQL fallback is still needed before then. - Bruce clarified that the current SDK-side updates are not REST behavior changes; the functional REST/backend fix is on the Flagship/Fid4 side, while SDK updates are cleanup, more graceful error handling, logging, and replacing a deprecated logger interface. - Bruce asked whether iOS Fid4 has a release-build optimization or code-minification concept comparable to Android; treat this as a validation/build-configuration question until clarified, not as evidence of a known iOS minification issue. diff --git a/project-knowledge/06-daily/2026-04-28.md b/project-knowledge/06-daily/2026-04-28.md index 9b2cb40..61ac41b 100644 --- a/project-knowledge/06-daily/2026-04-28.md +++ b/project-knowledge/06-daily/2026-04-28.md @@ -3,9 +3,9 @@ type: daily project: fidelity date: 2026-04-28 status: active -focus: [ao-discourse] -work-items: [] -blockers: [phone-verification-gate-in-fttransferplayground] +focus: [rest-migration, ao-discourse] +work-items: [pdiap-15838] +blockers: [] tags: - daily - fidelity @@ -16,23 +16,30 @@ updated: 2026-04-28 ## Focus -- Investigate the Discourse-reported FTTransfer / AccountLink reproduction path. +- Continue `PDIAP-15838` Apollo-removal work, especially clearing the remaining transitive `PicoSDK` dependency from `SampleApp`. +- Start investigating the new Discourse-reported FTTransfer / AccountLink issue after the draft PR is open. --- ## Findings -- David successfully configured the environment for `FTTransferPlayground`. -- The exact version Zachary mentioned was not available as a branch; the closest match found locally was the tag `Release/Foundation/5.0.0-beta.24`, which appears to correspond to the `5.0.24 beta` version he referenced. -- David was able to reach the flow so it matches Zachary's video more closely, but before the web view loads, the app requires phone-number verification. -- David does not yet know how to bypass that verification step in `FTTransferPlayground`. -- In prior `Fid4` validation, a similar gate could be bypassed by enabling Face ID, but the same attempt in this app currently produces a separate error. -- The current follow-up may require asking Zachary which user he used or whether he recognizes the Face ID / verification error in this app. +- For `PDIAP-15838`, David updated `SampleApp` to use a newer `PicoSDK` path that no longer brings Apollo transitively, so Apollo is removed from the sample app dependency path as well as the direct XFlow cleanup path. +- The `PicoSDK` update re-enabled the FGO and FidFolios flows for testing in `SampleApp`; without the update, the Pico endpoint fails. +- Jeff confirmed the `SampleApp` / `PicoSDK` update is in scope for `PDIAP-15838` because Apollo needs to be removed from the project, and the sample app should stay aligned with how Fid4 consumes Pico. +- David clarified that the `PicoSDK` update affects `SampleApp`, not the `XFlowSDK` production runtime directly, and aligns `SampleApp` with the newer Pico usage already present in Fid4. +- A draft PR for `PDIAP-15838 - Remove Apollo for iOS` was opened for internal review before sending to Bruce. +- Aylwing reviewed the draft PR and raised questions around intentional removal of the REST kill switch, `PicoSDKManager` initialization ownership, resolver availability, and async completion returning to the main actor. +- Jeff confirmed removal of the REST kill switch is intentional for permanent GraphQL deprecation, but the PR should merge only after the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for 30 days without issues. +- David confirmed `TransactionContextManager(resolver:)` handles Pico setup internally in `PicoSDK 4.3.18` through lazy resolver-based initialization, and the `SampleAppAuthDependencyResolver` is already available from the view model. +- David confirmed the resolver is an existing `XFlowSampleAppViewModel` property. +- David applied a minimal `PicoInterface` patch so the `Task` does not strongly capture `self` and both completion paths return through `MainActor.run`, making UI-state callers safer. +- After internal review, the next handoff is to send the draft PR link to Bruce. +- A new Discourse report came in around an AccountLink / FTTransfer multiple-presentation or web-view rewrite issue. Earlier UIKit-removal investigation had ruled out that change as the cause, but Zachary provided additional detail and believes it may still come from XFlow, so ownership needs careful reproduction before suggesting it is outside XFlow. --- ## Next Steps -- Keep trying to reproduce the FTTransfer / AccountLink issue through `FTTransferPlayground`. -- Determine whether the phone-verification step can be bypassed locally. -- If not, ask Zachary which user/account he used or whether he knows why the Face ID path errors in this app. +- Send the `PDIAP-15838` draft PR to Bruce after internal review is ready. +- Keep the `PDIAP-15838` PR in draft/review state until the REST production-readiness window is satisfied. +- Continue investigating the Discourse-reported FTTransfer / AccountLink issue and confirm reproduction/ownership before proposing a story or suggesting it is outside XFlow. diff --git a/project-knowledge/06-daily/2026-04-29.md b/project-knowledge/06-daily/2026-04-29.md new file mode 100644 index 0000000..acbd970 --- /dev/null +++ b/project-knowledge/06-daily/2026-04-29.md @@ -0,0 +1,55 @@ +--- +type: daily +project: fidelity +date: 2026-04-29 +status: active +focus: [ao-discourse] +work-items: [] +blockers: [phone-verification-gate-in-fttransferplayground] +tags: + - daily + - fidelity +updated: 2026-04-29 +--- + +# 2026-04-29 + +## Focus + +- Continue investigating the Discourse-reported FTTransfer / AccountLink reproduction path. + +--- + +## Work Done + +- David successfully configured the `FTTransferPlayground` environment. +- For the version Zachary mentioned, David did not find a matching branch; the closest match found was the tag `Release/Foundation/5.0.0-beta.24`, assumed to correspond to the `5.0.24 beta` version Zachary referenced. +- David reached the flow so it now looks similar to Zachary's video, but the app asks for phone-number verification before the web view loads. + +--- + +## Findings + +- David does not yet know how to bypass the phone-number verification step in `FTTransferPlayground`. +- In prior `Fid4` validation, a similar step could be bypassed by enabling Face ID, but trying that in `FTTransferPlayground` produced a separate error that is not yet understood. +- The current follow-up may require asking Zachary which user he used or whether he knows what causes the Face ID / verification error in this app. + +--- + +## Communication + +- David updated Jeff with the `FTTransferPlayground` setup status and the current verification blocker. + +--- + +## Next Steps + +- Keep trying to reproduce the FTTransfer / AccountLink issue through `FTTransferPlayground`. +- Determine whether the phone-verification step can be bypassed locally. +- If not, ask Zachary which user/account he used or whether he knows why the Face ID path errors in this app. + +--- + +## Blockers + +- Phone-number verification currently blocks reaching the web-view portion of the flow in `FTTransferPlayground`. diff --git a/project-knowledge/06-daily/index.md b/project-knowledge/06-daily/index.md index cd9fc5c..6fbed43 100644 --- a/project-knowledge/06-daily/index.md +++ b/project-knowledge/06-daily/index.md @@ -1,7 +1,7 @@ --- type: daily-index project: fidelity -updated: 2026-04-16 +updated: 2026-04-29 tags: - daily - map @@ -23,6 +23,11 @@ Promote durable facts into `project-knowledge/01-current/`, `project-knowledge/0 - [2026-04-14](2026-04-14.md) - [2026-04-15](2026-04-15.md) - [2026-04-16](2026-04-16.md) +- [2026-04-20](2026-04-20.md) +- [2026-04-21](2026-04-21.md) +- [2026-04-27](2026-04-27.md) +- [2026-04-28](2026-04-28.md) +- [2026-04-29](2026-04-29.md) ---