david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Refine Apollo cleanup design direction to prioritize native Swift models and limit dictionary usage to REST boundaries

Browse Source
This commit is contained in:
David Delagneau
2026-04-21 09:11:41 -06:00
parent f51fb07bfb
commit 73947adee7
2 changed files with 2 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
project-knowledge/02-work-items/pdiap-15838.md
View File

@@ -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.