feat: Update work item notes for PDIAP-15838 and add daily log for Apollo removal progress

project-knowledge/01-current/work-items.md

@@ -20,7 +20,7 @@ Update the per-ticket files first when scope, status, sequencing, or communicati
 
 - `PDIAP-15838` - Remove Apollo for iOS
   Detail: `project-knowledge/02-work-items/pdiap-15838.md`
-  Current note: assigned to the next sprint; current context and investigation notes remain relevant, but it should not be described as current-sprint in-progress implementation work.
+  Current note: assigned to the next sprint; current context and investigation notes remain relevant, model decoupling for the active path is now cleaner, and the next technical focus is the remaining Apollo runtime/infrastructure cleanup rather than Apollo-generated model replacement.
 
 - `PDIAP-15836` - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
   Detail: `project-knowledge/02-work-items/pdiap-15836.md`

project-knowledge/02-work-items/pdiap-15838.md

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

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

@@ -0,0 +1,48 @@
+---
+type: daily
+project: fidelity
+date: 2026-04-21
+status: active
+focus: [rest-migration]
+work-items: [pdiap-15838]
+blockers: []
+tags:
+  - daily
+  - fidelity
+updated: 2026-04-21
+---
+
+# 2026-04-21
+
+## Focus
+
+- Continue `PDIAP-15838` Apollo-removal cleanup.
+
+---
+
+## Work Done
+
+- Cleaned up the active production model layer so it no longer depends on Apollo-generated models for the current path.
+
+---
+
+## Findings
+
+- 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.
+- Any Apollo dependency that remains only through PicoSDK should be treated separately from source-level cleanup.
+
+---
+
+## Next Steps
+
+- Confirm the remaining `NetworkClient` / init-session Apollo dependencies and whether any AppSync config APIs still need compatibility handling.
+- Identify the runtime Apollo files that can now be removed safely after the model cleanup.
+- 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.
+
+---
+
+## Blockers
+
+- None currently.