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

project-knowledge/02-work-items/pdiap-15838.md

@@ -53,6 +53,12 @@ tags:
 - Jeff later relayed that Adam says the latest build is now activating REST correctly, so the story should shift back to the planned GraphQL-removal and related LaunchDarkly-toggle cleanup work.
 - Keep the real-device-only scenario in mind as a useful fallback hypothesis if the issue returns: environment-specific differences such as LaunchDarkly context, timing, or cached toggle state may explain behavior that does not reproduce in the simulator.
 - Adam was the reported source of the REST activation problem, and his side validates behavior on real devices.
+- Current codebase analysis suggests the main remaining source-level blockers are no longer transport selection but residual Apollo model/runtime coupling: `XFlow.Slot` usage in the page interactor/worker path, `NetworkClient` references still touched by init/session lifecycle, and Apollo/AppSync config surface that may still behave like public API.
+- Follow-up analysis suggested `XFlow.Slot` might be the only Apollo-generated production model still used outside the GraphQL-generated folder, but local trial changes surfaced additional Apollo-dependent models/build errors. Treat the `XFlow.Slot` simplification as a promising first step, not as a fully validated statement about the whole codebase.
+- The suggested simplification is to remove the current round-trip `stagedValues() -> [String: String] -> XFlow.Slot -> [String: String] -> XFlowUpdateSlotsRequest.slots` and instead pass `[String: String]` straight through to `XFlowUpdateSlotsRequest.slots`, keeping `SlotVariable: Encodable` in the REST model layer for request serialization.
+- The next AI follow-up should focus only on the first step and ask GitHub Copilot to corroborate residual Apollo-model dependencies by using `xcodebuild` failures, not just static reference search.
+- Apollo source-level cleanup appears sequenced as: replace `XFlow.Slot` with a transport-agnostic model first, decouple `XFlowInitManager` from `NetworkClient` while preserving current REST endpoint behavior, then remove runtime GraphQL code, project wiring, Apollo-only tests/scripts/docs, and finally treat any transitive PicoSDK Apollo dependency as a separate dependency-exit task.
+- Apollo may still remain in the pod graph transitively through PicoSDK even after source-level cleanup, so "Apollo removed" should be framed carefully unless the dependency graph is also cleared.
 
 ---
 

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.