feat: update daily logs for 2026-04-30; refine Discourse / FTTransfer investigation findings and root cause analysis

project-knowledge/06-daily/2026-04-30.md

@@ -1,5 +1,57 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-30
+status: active
+focus: [ao-discourse, xflow-debugging]
+work-items: []
+blockers: []
+tags:
+  - daily
+  - fidelity
+updated: 2026-05-01
+---
+
 # 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.
+## Focus
+
+- Continue the Discourse / FTTransfer AccountLink investigation and verify whether the web-view reload issue is caused by XFlow/XFlowViewMaker or by the consumer SwiftUI hierarchy.
+
+---
+
+## Work Done
+
+- Compared the failing `FTTransferPlayground` path with the working non-XFlow entry point Zachary referenced.
+- Explored whether XFlow event handling could be contributing to the issue, since similar event/lifecycle concerns came up in prior work.
+- Ran a deeper architecture analysis of the web-view reload behavior with concrete code references.
+- Identified the likely root cause as a SwiftUI view-identity / environment-republish issue around `BankInformationView` and `BankSetupWebView`, not XFlow rendering or XFlowViewMaker lifecycle logic directly.
+
+---
+
+## Findings
+
+- XFlow is definitely the upstream trigger path, but the failure is driven entirely by how the consumer SwiftUI hierarchy anchors the web-view presentation.
+- **Final Root Cause (Modifier-Site Teardown):** The `.ftFullScreenCover` modifier was incorrectly attached to a **volatile branch** of `BankInformationView` (e.g., inside a dynamic loaded/error state view). When the webview triggered an exit alert, the resulting state mutation caused SwiftUI to re-evaluate that volatile branch. This dismantled the presentation anchor and rebuilt it off-screen (`inWindow=false`), resulting in a blank screen.
+- The working non-XFlow route survives because it uses a completely different, stronger modal/coordinator boundary (`BankSetupContainerView`), avoiding this fragile modifier placement.
+- **Verified Solution:** The issue was resolved by moving the `.ftFullScreenCover` and its `shouldShowWebView` observer to the **stable root** of `BankInformationView`. By anchoring the presentation to the static root instead of a dynamic child branch, transient state changes no longer dismantle the presenter. This fixes the bug perfectly using pure SwiftUI, without any UIKit (`UIHostingController`) hacks.
+
+---
+
+## Communication
+
+- David asked Zachary for the working non-XFlow entry point so the failing and working paths could be compared directly.
+- David can now confidently update Jeff and Zachary that XFlow is completely cleared, and the bug was a classic SwiftUI presentation-anchor issue in the playground's consumer code.
+
+---
+
+## Next Steps
+
+- Finalize the PR with the structural fix (moving the cover to the stable root of `BankInformationView`).
+- Share the exact lines changed with Zachary so his team can apply this SwiftUI best practice to other covers in their playground.
+
+---
+
+## Blockers
+
+- None currently.

project-knowledge/06-daily/index.md

@@ -1,7 +1,7 @@
 ---
 type: daily-index
 project: fidelity
-updated: 2026-04-29
+updated: 2026-05-01
 tags:
   - daily
   - map
@@ -28,6 +28,7 @@ Promote durable facts into `project-knowledge/01-current/`, `project-knowledge/0
 - [2026-04-27](2026-04-27.md)
 - [2026-04-28](2026-04-28.md)
 - [2026-04-29](2026-04-29.md)
+- [2026-04-30](2026-04-30.md)
 
 ---