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

docs: update Discourse AccountLink investigation status and capture April 30 daily progress

Browse Source
This commit is contained in:
David Delagneau
2026-04-30 11:28:14 -06:00
parent fa1ab57de8
commit 5ceb3ec42e
3 changed files with 26 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
project-knowledge/01-current/current-work.md
View File

@@ -2,7 +2,7 @@
type: current type: current
project: fidelity project: fidelity
status: active status: active
updated: 2026-04-29 updated: 2026-04-30
tags: tags:
- current-work - current-work
- fidelity - fidelity
@@ -46,8 +46,10 @@ tags:
- 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 - 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 - 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 `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 - The new Discourse / FTTransfer AccountLink issue is under investigation; Zachary believes it may come from XFlow, but current evidence shows it reproduces in `FTTransferPlayground` with Zachary's account and does not reproduce in `Fid4` with the same account
- 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 - Current Discourse / FTTransfer findings point to the `BankInformationView` path rather than XFlow directly: XFlow appears to finish before `BankInformationView` takes over, and the web-view reload looks like a SwiftUI recomposition/state issue in the playground path
- Continue the Discourse / FTTransfer investigation to verify root cause and any remaining relationship to XFlowViewMaker before assigning ownership or creating a story
- Jeff asked David to try to resolve the Discourse consumer issue by end of day on April 30 if possible
- 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 - 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 - 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
@@ -87,6 +89,7 @@ tags:
- When one Jira item has multiple concrete updates, prefer one top-level Jira bullet with indented sub-bullets rather than repeating the same Jira line multiple times - When one Jira item has multiple concrete updates, prefer one top-level Jira bullet with indented sub-bullets rather than repeating the same Jira line multiple times
- When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas - When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas
- For Friday standups that may also be sent to Teams, prefer plain language over internal implementation terms; avoid words like `fallback` unless the meaning is obvious to the audience - For Friday standups that may also be sent to Teams, prefer plain language over internal implementation terms; avoid words like `fallback` unless the meaning is obvious to the audience
- For standups that may also be sent to Teams, keep the update concise, omit internal review-feedback details, and avoid phrasing like `confirmed` when the audience lacks the internal context for what was confirmed
- When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone - When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone
- Standups should omit side questions or manager-only context refreshes unless they materially changed story work - Standups should omit side questions or manager-only context refreshes unless they materially changed story work
- For `PDIAP-15838` standups, focus on Apollo-removal progress and the `PicoSDK` transitive dependency work; omit extra exploratory asks unless they directly changed the story outcome or created a blocker - For `PDIAP-15838` standups, focus on Apollo-removal progress and the `PicoSDK` transitive dependency work; omit extra exploratory asks unless they directly changed the story outcome or created a blocker

24
project-knowledge/06-daily/2026-04-29.md
View File

@@ -5,11 +5,11 @@ date: 2026-04-29
status: active status: active
focus: [ao-discourse] focus: [ao-discourse]
work-items: [] work-items: []
blockers: [phone-verification-gate-in-fttransferplayground] blockers: []
tags: tags:
- daily - daily
- fidelity - fidelity
updated: 2026-04-29 updated: 2026-04-30
--- ---
# 2026-04-29 # 2026-04-29
@@ -25,31 +25,37 @@ updated: 2026-04-29
- David successfully configured the `FTTransferPlayground` environment. - 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. - 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. - 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.
- David asked Zachary for reproduction details, including whether the issue reproduces in `Fid4` and which account/steps were used.
- With the account Zachary shared, David reproduced the issue in `FTTransferPlayground`.
- David tested the same account in `Fid4`, but the issue did not reproduce there.
- David narrowed the visible issue to the `BankInformationView` path rather than XFlow directly: an XFlow flow occurs before the web view is presented, but it finishes before `BankInformationView` takes over.
--- ---
## Findings ## Findings
- David does not yet know how to bypass the phone-number verification step in `FTTransferPlayground`. - The issue occurs when tapping `exit`: the alert appears, but the view immediately rebuilds.
- 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 behavior currently looks like a SwiftUI recomposition issue: `.state` is updated to `.loading`, which triggers a redraw, presents an `EmptyView`, dismisses the alert, and reloads the web view.
- 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. - The remaining uncertainty is why this happens in `FTTransferPlayground` but not in `Fid4`.
--- ---
## Communication ## Communication
- David updated Jeff with the `FTTransferPlayground` setup status and the current verification blocker. - David updated Jeff with the `FTTransferPlayground` setup status and the current verification blocker.
- Jeff asked David to ping Zachary directly for help, including asking whether Zachary has seen the issue in `Fid4` and how David might reproduce it there.
- David reported that the issue reproduces in `FTTransferPlayground` with Zachary's account but not in `Fid4` with the same account.
- Jeff asked David to prioritize resolving the Discourse consumer issue by end of day on April 30 if possible.
--- ---
## Next Steps ## Next Steps
- Keep trying to reproduce the FTTransfer / AccountLink issue through `FTTransferPlayground`. - Continue deeper testing to isolate why the behavior occurs in `FTTransferPlayground` but not in `Fid4`.
- Determine whether the phone-verification step can be bypassed locally. - Verify the root cause and whether there is any remaining relationship to XFlowViewMaker before assigning ownership or creating a story.
- If not, ask Zachary which user/account he used or whether he knows why the Face ID path errors in this app.
--- ---
## Blockers ## Blockers
- Phone-number verification currently blocks reaching the web-view portion of the flow in `FTTransferPlayground`. - None currently.

5
project-knowledge/06-daily/2026-04-30.md Normal file
View File

@@ -0,0 +1,5 @@
# 2026-04-30
## Context Updates
- Jeff requested confirmation on whether the webview reload issue is tied to `XFlow`. If not, we need to compare the failing flow against Zachary's working non-XFlow entry point to understand the discrepancy.
- David reported that the issue seems isolated to a premature deallocation in the SwiftUI lifecycle between `BankInformationView` and `BankSetupWebView`, meaning it does not appear to be an `XFlowViewMaker` bug.