david.delagneau
1ad707373a
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
3.1 KiB
3.1 KiB
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 |
|
|
|
2026-04-28 |
2026-04-28
Focus
- Continue
PDIAP-15838Apollo-removal work, especially clearing the remaining transitivePicoSDKdependency fromSampleApp. - Start investigating the new Discourse-reported FTTransfer / AccountLink issue after the draft PR is open.
Findings
- For
PDIAP-15838, David updatedSampleAppto use a newerPicoSDKpath 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
PicoSDKupdate re-enabled the FGO and FidFolios flows for testing inSampleApp; without the update, the Pico endpoint fails. - Jeff confirmed the
SampleApp/PicoSDKupdate is in scope forPDIAP-15838because Apollo needs to be removed from the project, and the sample app should stay aligned with how Fid4 consumes Pico. - David clarified that the
PicoSDKupdate affectsSampleApp, not theXFlowSDKproduction runtime directly, and alignsSampleAppwith the newer Pico usage already present in Fid4. - A draft PR for
PDIAP-15838 - Remove Apollo for iOSwas opened for internal review before sending to Bruce. - Aylwing reviewed the draft PR and raised questions around intentional removal of the REST kill switch,
PicoSDKManagerinitialization 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 inPicoSDK 4.3.18through lazy resolver-based initialization, and theSampleAppAuthDependencyResolveris already available from the view model. - David confirmed the resolver is an existing
XFlowSampleAppViewModelproperty. - David applied a minimal
PicoInterfacepatch so theTaskdoes not strongly captureselfand both completion paths return throughMainActor.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-15838draft PR to Bruce after internal review is ready. - Keep the
PDIAP-15838PR 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.