From 73947adee71b32c331973f712dca72316c977d30 Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Tue, 21 Apr 2026 09:11:41 -0600 Subject: [PATCH] feat: Refine Apollo cleanup design direction to prioritize native Swift models and limit dictionary usage to REST boundaries --- project-knowledge/02-work-items/pdiap-15838.md | 1 + project-knowledge/06-daily/2026-04-20.md | 1 + 2 files changed, 2 insertions(+) diff --git a/project-knowledge/02-work-items/pdiap-15838.md b/project-knowledge/02-work-items/pdiap-15838.md index b9ca331..030c8b2 100644 --- a/project-knowledge/02-work-items/pdiap-15838.md +++ b/project-knowledge/02-work-items/pdiap-15838.md @@ -59,6 +59,7 @@ tags: - 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. - Follow-up enum validation indicates at least some Apollo-generated enum types can likely be replaced with native Swift `enum Name: String` definitions without preserving Apollo `EnumType` behavior. For the currently checked production callers, Copilot reported no Apollo-specific enum API dependency for `XFlow.ContentType`, `XFlow.ScreenshotFormat`, and `XFlow.NextTransitionType`; current behavior relies on `rawValue`, equality/switch use, and `init?(rawValue:)`-style parsing. - The currently observed fallback behavior is simple and code-local: unknown `ContentType` values are skipped by converter guards, unknown `ScreenshotFormat` values fall back to PDF in downstream callers, and unknown `NextTransitionType` values currently propagate as `nil` where the target property is optional. +- Design direction for the Phase 1 Apollo cleanup: prefer replacing `XFlow.Slot` with a native Swift `Slot` model instead of collapsing it to `[String: String]` through the full production path. Keep `[String: String]` only at the boundary where the REST request/DTO is built in the worker or transport layer. - 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. diff --git a/project-knowledge/06-daily/2026-04-20.md b/project-knowledge/06-daily/2026-04-20.md index a2ccaeb..c419fd5 100644 --- a/project-knowledge/06-daily/2026-04-20.md +++ b/project-knowledge/06-daily/2026-04-20.md @@ -50,6 +50,7 @@ updated: 2026-04-20 - 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. +- Current design preference for the Apollo cleanup is to keep domain-facing code using a native `Slot` model and limit `[String: String]` to the REST boundary/DTO construction layer instead of pushing the dictionary type through the full interactor/worker path. - 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.