feat: Enhance Apollo removal analysis with AI insights on enum replacements and dependency validation

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

@@ -49,6 +49,7 @@ updated: 2026-04-20
 - 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.
+- Additional Copilot validation on Apollo-generated enums says the checked production callers for `XFlow.ContentType`, `XFlow.ScreenshotFormat`, and `XFlow.NextTransitionType` appear to need only native `String`-backed enums plus the current local fallback behavior, not Apollo `EnumType` semantics.
 - 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.