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

feat: Update work items and daily log for Apollo removal progress and SwiftUI migration cleanup

Browse Source
This commit is contained in:
David Delagneau
2026-04-21 11:52:13 -06:00
parent 44d70f4d7a
commit e5d41c876e
3 changed files with 18 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
project-knowledge/02-work-items/pdiap-15836.md
View File

@@ -8,7 +8,7 @@ systems: [xflowsdk, xflowviewmaker, ftframeworks]
workstreams: [xflow-swiftui-migration, consumer-integration]
people: [jeff-dewitte]
related: [pdiap-14859]
updated: 2026-04-16
updated: 2026-04-21
tags:
- work-item
- fidelity
@@ -53,3 +53,6 @@ tags:
- Keep the scope framed as lifecycle sequencing in a pure SwiftUI environment, not only as a symptom like multiple modal presentation.
- If mentioned externally, keep it separate from `PDIAP-15838`.
- The Confluence/root-cause document was updated to reflect that FTTransfer changes are not the primary need anymore.
- The primary recommendation is to adjust the dismissal handling/sequencing correctly in the hosting path.
- FTTransfer improvements can still be mentioned as a secondary improvement, but not as a required change to reproduce the same visual behavior.

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

@@ -63,6 +63,9 @@ tags:
- The current implementation state is cleaner on the model side: Apollo-generated production models have now been replaced with native Swift models/enums for the active path, so the next focus should move from model decoupling to remaining Apollo runtime/infrastructure dependencies.
- The `XFlowInitManager` runtime/init cleanup step has now been applied successfully: the three `NetworkClient.shared.updateAppSyncURL(...)` calls were removed from the start/session lifecycle paths, `getAppSyncEndPoint()` was removed after becoming unused, and the project still compiles with `getEndPoint()` left intact for current REST selection.
- `NetworkClient.swift` can likely stay temporarily in the tree as a disconnected compatibility shim until broader package/project cleanup, and `XFlowInitManagerConfig.swift` may need to keep AppSync getter/config surface temporarily to avoid an accidental public API break.
- Follow-up runtime scan now suggests `GraphQL/NetworkClient.swift` has no live production callers and only self-references remain inside the file. The proposed next removal order is to delete `GraphQL/NetworkClient.swift` first, build/reference-check, then delete `GraphQL/ApolloGeneratedCode`, while keeping the AppSync members in `XFlowInitManagerConfig.swift` temporarily as compatibility-only surface.
- Current local state after broader cleanup: runtime Apollo decoupling and most Apollo-specific test cleanup now appear complete, production code compiles cleanly aside from a pre-existing environment issue, and no live Apollo imports/references remain in production code. Remaining work is mainly package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
- Current local state now also indicates the test target compiles cleanly after a minimal follow-up update to `XFlowTransportSelectionTests.swift`, preserving REST-relevant transport tests while removing obsolete GraphQL/Apollo assertions. The remaining Apollo-removal work appears concentrated in package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
- 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.