feat: transition PDIAP-15838 to active status and update Apollo removal strategy to include production-gated merge requirements and PicoSDK dependency cleanup.

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

@@ -2,7 +2,7 @@
 type: current
 project: fidelity
 status: active
-updated: 2026-04-17
+updated: 2026-04-28
 tags:
   - current-work
   - fidelity
@@ -17,8 +17,7 @@ tags:
 - Prepare better updates for the current manager or stakeholder through Mattermost
 - Follow up on active tickets through `project-knowledge/02-work-items/`, especially `PDIAP-15838` and `PDIAP-15836`
 - `PDIAP-15765` is done and `PDIAP-14859` is also done
-- `PDIAP-15838` is assigned to the next sprint
+- `PDIAP-15838` is the active Apollo-removal / REST-migration cleanup and validation focus
-- Do not describe `PDIAP-15838` as current-sprint in-progress implementation work
 - `PDIAP-15836` comes after the current REST-investigation / Apollo-removal work
 - Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there
 - Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers
@@ -43,6 +42,8 @@ tags:
 - Jeff suggested broadening the investigation support path while direct Flagship LaunchDarkly access is still missing: monitor the Tauf thread, follow up with Jeffrey O'Leary, package the scenario for the AI tool with build settings and tool details, and ask Aylwing for a quick perspective if available
 - The Fidelity-side AI tool Jeff referenced for this investigation is GitHub Copilot
 - Jeff later relayed that Adam says the latest build is now activating REST correctly, so David should switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles
+- Do not merge the GraphQL/Apollo removal PR until the REST backend is deployed to production; GraphQL fallback is still needed before then
+- Current `PDIAP-15838` follow-up includes Fid4 validation, simulator-vs-device/generated-build configuration checks, and investigating the `PicoSDK` upgrade path for `SampleApp` because current `PicoSDK` usage still brings Apollo transitively
 - Before closing out the AO thread, send one more working-group Teams reply that summarizes the original iOS issue, links the Jira comment, Discourse comment, and PR, and separates the remaining `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue
 - The `HybridBrokerageAccountOpening` / `JointIdentityCheck` rule-content issue appears unchanged between QA and Production in Cogstore and should be treated as the remaining service-side follow-up
 
@@ -64,7 +65,7 @@ tags:
 - Adam reported the earlier REST activation problem, and he or his team validate behavior on real devices rather than simulator-only paths
 - Avoid treating GitHub Copilot or LaunchDarkly as story-specific tools; both are broader Fidelity workflow tools that happened to matter in this investigation
 - Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
-- Keep the Apollo-removal / REST-migration context ready for the next sprint, when `PDIAP-15838` becomes active
+- Keep Apollo-removal / REST-migration cleanup grounded in backend readiness: source-level cleanup can continue, but merge/release timing depends on REST backend production deployment
 - Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope
 - Avoiding assumptions about legacy Apex/ApexKit paths; breakpoint evidence and helper usage both need to be reconciled before reporting ownership or replacement guidance
 - When ownership is still uncertain under production pressure, prefer rollback-plus-investigation framing over confident blame assignment to consumers
@@ -84,6 +85,7 @@ tags:
 - For Friday standups that may also be sent to Teams, prefer plain language over internal implementation terms; avoid words like `fallback` unless the meaning is obvious to the audience
 - When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone
 - Standups should omit side questions or manager-only context refreshes unless they materially changed story work
+- For `PDIAP-15838` standups, focus on Apollo-removal progress and the `PicoSDK` transitive dependency work; omit extra exploratory asks unless they directly changed the story outcome or created a blocker
 - If a root cause document or other documentation update directly supports a story, it should be reported under that story instead of as a separate standalone item
 - Standups should omit items not tied to a story unless they are real blockers
 - If a new request is important work but not directly tied to a Jira item, include it as a standalone bullet instead of forcing it under a story

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

@@ -2,7 +2,7 @@
 type: current-work-items
 project: fidelity
 status: active
-updated: 2026-04-17
+updated: 2026-04-28
 tags:
   - current-work
   - work-item
@@ -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, 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.
+  Current note: active Apollo-removal cleanup and validation; do not merge the PR until the REST backend is deployed to production because GraphQL fallback is still needed. Current follow-up includes Fid4 validation, simulator-vs-device/generated-build configuration checks, and `PicoSDK` upgrade investigation for `SampleApp` because the current setup still brings Apollo transitively.
 
 - `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

@@ -1,14 +1,14 @@
 ---
 type: work-item
 project: fidelity
-status: planned
+status: active
 ticket: PDIAP-15838
 title: "Remove Apollo for iOS"
 systems: [xflowsdk]
 workstreams: [rest-migration]
 people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
 related: [launchdarkly, github-copilot]
-updated: 2026-04-27
+updated: 2026-04-28
 tags:
   - work-item
   - fidelity
@@ -19,8 +19,8 @@ tags:
 
 ## Status
 
-- Planned for next sprint
+- Active Apollo-removal cleanup and validation
-- Not the current sprint's active implementation story
+- PR merge should wait until the REST backend is deployed to production because GraphQL fallback is still needed before then
 - Sized at `8` points
 
 ---
@@ -46,7 +46,8 @@ tags:
 - Do not frame this ticket as directly tied to the UIKit-removal spike.
 - Do not imply it is dependent on or part of dismissal-sequencing work.
 - Keep the migration framing explicit: REST remains behind a feature flag until otherwise confirmed, and GraphQL fallback context still matters when describing the overall migration.
-- Keep the REST-activation investigation context as useful background, but do not present this story as current-sprint active implementation work if it is assigned to the next sprint.
+- Keep the REST-activation investigation context as useful background, but focus current updates on Apollo-removal cleanup, validation, and merge sequencing.
+- For standups and concise status updates, center the story on Apollo-removal progress and the `PicoSDK` transitive dependency path; omit extra exploratory asks unless they directly affect the story outcome or create a blocker.
 - Jeff confirmed this investigation should stay ahead of Adam's separate service-side flow report for now and asked for faster progress.
 - Current local evidence shows the LaunchDarkly boolean evaluating to `true`, with payload and context present from the iOS side; remaining uncertainty is around production-side context interpretation, timing/caching, or downstream transport gating.
 - Use the current support path while direct Flagship LaunchDarkly access is missing: monitor the Tauf thread, follow the outreach path to Jeffrey O'Leary, package the scenario for GitHub Copilot with build settings and tool details, and ask Aylwing for a quick perspective if available.
@@ -70,6 +71,7 @@ tags:
 - 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.
 - Latest local follow-up suggests `SampleApp` depends on `PicoSDK`, and that transitive dependency may still be the practical reason Apollo remains in the pod graph. Newer `PicoSDK` versions no longer depend on Apollo, but the upgrade path does involve real breaking changes. The current investigation is to determine how `SampleApp` can absorb those changes by comparing against how `Fid4` currently uses `PicoSDK` for the two specific flows that still depend on it.
+- Jeff later confirmed that this `PicoSDK` / `SampleApp` cleanup is in scope for `PDIAP-15838` because Apollo needs to be removed from the project, including the transitive sample-app path. Keep the nuance explicit that this update affects `SampleApp`, not the `XFlowSDK` production runtime directly.
 - Merge sequencing is now explicitly gated by backend production readiness: Bruce reinforced that the GraphQL/Apollo removal PR should not merge until the backend is in production because GraphQL fallback is still needed before then.
 - Bruce clarified that the current SDK-side updates are not REST behavior changes; the functional REST/backend fix is on the Flagship/Fid4 side, while SDK updates are cleanup, more graceful error handling, logging, and replacing a deprecated logger interface.
 - Bruce asked whether iOS Fid4 has a release-build optimization or code-minification concept comparable to Android; treat this as a validation/build-configuration question until clarified, not as evidence of a known iOS minification issue.
@@ -80,4 +82,4 @@ tags:
 
 ## Sequencing
 
-- This story is assigned to the next sprint and remains sequenced before `PDIAP-15836`.
+- This story remains sequenced before `PDIAP-15836`.

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

@@ -31,6 +31,9 @@ updated: 2026-04-27
 - David reviewed what may still be pending and noticed that `SampleApp` depends on `PicoSDK`, which still brings Apollo transitively in the current setup.
 - The likely recommendation is to move `PicoSDK` to a newer version because newer releases no longer depend on Apollo.
 - That upgrade path does include breaking changes. The current follow-up is to figure out how to handle them in `SampleApp` by comparing against how `Fid4` currently uses `PicoSDK` for the two specific flows that still depend on it.
+- The current `PicoSDK` update also requires re-enabling the `FGO` and `FidFolios` flows in `SampleApp` for validation there; without this update, the Pico endpoint path fails in the sample app.
+- Jeff confirmed this `PicoSDK` / `SampleApp` work should be treated as in scope because Apollo must be removed from the project, including the transitive `SampleApp` path used through `PicoSDK`.
+- Important scope nuance: updating `PicoSDK` affects `SampleApp`, not `XFlowSDK` production runtime itself.
 
 ---
 
@@ -39,3 +42,4 @@ updated: 2026-04-27
 - Hold any PR merge until the REST backend is deployed to production.
 - Check Fid4 build settings/schemes/configurations for simulator-versus-device differences, especially release/generated-build optimization or size-related settings that could explain behavior seen in generated builds but not local runs.
 - Investigate the `PicoSDK` upgrade path in `SampleApp`, using the current `Fid4` integration for the two affected flows as the comparison point for handling the breaking changes safely.
+- Include the `PicoSDK` / `SampleApp` update in the current Apollo-removal PR.