fidelity-ai-workspace/project-knowledge/06-daily/2026-04-28.md

type, project, date, status, focus, work-items, blockers, tags, updated

type	project	date	status	focus	work-items	blockers	tags	updated
daily	fidelity	2026-04-28	active	rest-migration ao-discourse	pdiap-15838		daily fidelity	2026-04-28

2026-04-28

Focus

• 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

• 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

• 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.