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

feat: Update daily log for PDIAP-15838 with recent Apollo removal progress and next steps

Browse Source
This commit is contained in:
David Delagneau
2026-04-21 10:18:13 -06:00
parent 3709674665
commit 3cfc69e9a6
2 changed files with 8 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -61,6 +61,8 @@ tags:
- 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. - 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. - 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.
- 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 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.
- 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 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. - 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.

8
project-knowledge/06-daily/2026-04-21.md
View File

@@ -23,6 +23,7 @@ updated: 2026-04-21
## Work Done ## Work Done
- Cleaned up the active production model layer so it no longer depends on Apollo-generated models for the current path. - Cleaned up the active production model layer so it no longer depends on Apollo-generated models for the current path.
- Removed the three `NetworkClient.shared.updateAppSyncURL(...)` calls from `XFlowInitManager` and removed `getAppSyncEndPoint()` after it became unused; the project still compiles.
--- ---
@@ -31,13 +32,16 @@ updated: 2026-04-21
- The model-decoupling step for `PDIAP-15838` is now in a cleaner state. - The model-decoupling step for `PDIAP-15838` is now in a cleaner state.
- The next focus should shift to the remaining Apollo-dependent runtime and infrastructure surface: init/session coupling through `NetworkClient`, Apollo-generated/runtime code that is no longer needed, and Apollo-specific tests/scripts/build wiring. - The next focus should shift to the remaining Apollo-dependent runtime and infrastructure surface: init/session coupling through `NetworkClient`, Apollo-generated/runtime code that is no longer needed, and Apollo-specific tests/scripts/build wiring.
- Any Apollo dependency that remains only through PicoSDK should be treated separately from source-level cleanup. - Any Apollo dependency that remains only through PicoSDK should be treated separately from source-level cleanup.
- Copilot's focused runtime/init guidance says the safest next source-level step is to remove only the three `updateAppSyncURL(...)` calls from `XFlowInitManager`, then delete internal `getAppSyncEndPoint()` if it becomes unused, while leaving `NetworkClient.swift` and `XFlowInitManagerConfig.swift` in place temporarily as disconnected compatibility surface until later cleanup.
- After that step, no live init/session runtime wiring from `XFlowInitManager` into Apollo/AppSync remains; the remaining Apollo surface appears to be disconnected compatibility/runtime code plus later package/build/test cleanup.
--- ---
## Next Steps ## Next Steps
- Confirm the remaining `NetworkClient` / init-session Apollo dependencies and whether any AppSync config APIs still need compatibility handling. - Confirm whether `NetworkClient.swift` still has any live production callers or can now be treated as removable runtime dead code.
- Identify the runtime Apollo files that can now be removed safely after the model cleanup. - Confirm whether `XFlowInitManagerConfig.swift` AppSync getters are truly compatibility-only or still externally used.
- Identify the runtime Apollo files that can now be removed safely after the model and init cleanup.
- Remove Apollo-only tests, mocks, codegen scripts, and build wiring once runtime references are gone. - Remove Apollo-only tests, mocks, codegen scripts, and build wiring once runtime references are gone.
- Treat any transitive PicoSDK Apollo dependency as a separate dependency-exit step. - Treat any transitive PicoSDK Apollo dependency as a separate dependency-exit step.