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
-- Do not describe `PDIAP-15838` as current-sprint in-progress implementation work
+- `PDIAP-15838` is the active Apollo-removal / REST-migration cleanup and validation focus
 - `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