feat: Update PDIAP-15838 and daily notes with AI-assisted analysis on Apollo removal and GraphQL cleanup strategy

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

@@ -44,6 +44,11 @@ updated: 2026-04-20
 - Adam Abdelhadi was the reported source of the REST activation problem, and his side validates behavior on real devices.
 - Jeff later relayed that Adam says the latest build is now activating REST correctly, so the urgent production-toggle investigation is no longer the immediate focus.
 - Jeff directed David to switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles.
+- AI-assisted codebase analysis for `PDIAP-15838` says the main remaining Apollo blockers are residual `XFlow.Slot` model coupling in the page interactor/worker path, init/session lifecycle coupling to `NetworkClient`, and remaining Apollo build/dependency wiring.
+- The proposed safe order is: replace `XFlow.Slot` with a transport-agnostic type first, decouple init/session from `NetworkClient` without changing REST endpoint behavior, then remove runtime GraphQL code, Apollo project wiring, Apollo-only tests/scripts/docs, and treat any PicoSDK-transitive Apollo dependency as a later dependency-exit step.
+- The current risk is no longer GraphQL transport itself; it is hidden runtime or public-API coupling plus the chance of claiming full Apollo removal while a transitive dependency still exists through PicoSDK.
+- Follow-up AI analysis says the `XFlow.Slot` replacement may be simpler than expected: no new model may be needed because `activitySession?.stagedValues()` already yields `[String: String]` and `XFlowUpdateSlotsRequest.slots` already accepts `[String: String]`. If that holds in code, the current Apollo dependency is mostly an unnecessary intermediate conversion step.
+- Local trial changes showed that `XFlow.Slot` is likely not the only remaining Apollo-dependent model in the first-step cleanup path, so the next Copilot pass should validate the real dependency surface through `xcodebuild` errors instead of assuming static references tell the whole story.
 - David clarified additional Fidelity-side process context: Quy acts as Scrum Master, manages retrospectives, DSE/daily syncs, sprint review, and sprint planning, retrospectives use Miro, Jira is the tracking system, and the Fidelity-side sprint cadence is two weeks with labels like `PDIAP 26Q1.1` and `PDIAP 26Q2.1`.
 - David corrected the Q2 sprint examples: `PDIAP 26Q2.1` is `3/26 - 4/09`, and `PDIAP 26Q2.2` is `4/09 - 4/23`.
 - David clarified that Jira should be represented as a first-class Fidelity tool/system because it is used more heavily than Confluence in day-to-day work tracking.