feat: Update work item statuses and refine sprint planning for PDIAP-15838; adjust standup prompt guidelines

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

@@ -17,8 +17,8 @@ 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 now in progress
-- The current top priority is back to `PDIAP-15838` implementation work for removing GraphQL and related LaunchDarkly toggles
+- `PDIAP-15838` is assigned to the next sprint
+- 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
@@ -64,7 +64,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
-- Continue broader Apollo-removal / REST-migration cleanup now that the latest build is reportedly activating REST again
+- Keep the Apollo-removal / REST-migration context ready for the next sprint, when `PDIAP-15838` becomes active
 - 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

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: now in progress; Adam says the latest build is activating REST again, so the story focus should return to removing GraphQL and the related LaunchDarkly toggles.
+  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.
 
 - `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: in-progress
+status: planned
 ticket: PDIAP-15838
 title: "Remove Apollo for iOS"
 systems: [xflowsdk]
 workstreams: [rest-migration]
 people: [jeff-dewitte, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
 related: [launchdarkly, github-copilot]
-updated: 2026-04-20
+updated: 2026-04-21
 tags:
   - work-item
   - fidelity
@@ -19,8 +19,8 @@ tags:
 
 ## Status
 
-- In Progress
-- Current top priority within this story is back to the GraphQL-removal / LaunchDarkly-toggle cleanup after Adam reported the latest build activating REST correctly
+- Planned for next sprint
+- Not the current sprint's active implementation story
 - Sized at `8` points
 
 ---
@@ -46,11 +46,11 @@ 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.
-- Treat the REST-activation investigation as the immediate priority before resuming broader Apollo-removal cleanup.
+- 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.
 - 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.
-- Jeff later relayed that Adam says the latest build is now activating REST correctly, so the story should shift back to the planned GraphQL-removal and related LaunchDarkly-toggle cleanup work.
+- Adam later reported that the latest build is activating REST correctly, so the story context returned to the planned GraphQL-removal and related LaunchDarkly-toggle cleanup work.
 - Keep the real-device-only scenario in mind as a useful fallback hypothesis if the issue returns: environment-specific differences such as LaunchDarkly context, timing, or cached toggle state may explain behavior that does not reproduce in the simulator.
 - Adam was the reported source of the REST activation problem, and his side validates behavior on real devices.
 - Current codebase analysis suggests the main remaining source-level blockers are no longer transport selection but residual Apollo model/runtime coupling: `XFlow.Slot` usage in the page interactor/worker path, `NetworkClient` references still touched by init/session lifecycle, and Apollo/AppSync config surface that may still behave like public API.
@@ -64,4 +64,4 @@ tags:
 
 ## Sequencing
 
-- This is the next story to work on before `PDIAP-15836`.
+- This story is assigned to the next sprint and remains sequenced before `PDIAP-15836`.

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

@@ -23,9 +23,8 @@ updated: 2026-04-20
 
 ## Work Done
 
-- Moved `PDIAP-15765` to Done.
-- Moved `PDIAP-14859` to Done.
-- Updated `PDIAP-15838` to In Progress.
+- Continued the REST activation investigation tied to `PDIAP-15838`.
+- Refined the current Apollo-removal analysis and next implementation order for `PDIAP-15838`.
 
 ---
 
@@ -33,6 +32,7 @@ updated: 2026-04-20
 
 - The immediate priority is no longer closeout work on the completed stories.
 - The immediate priority is to investigate why REST is not activating.
+- The earlier `Done` transitions for `PDIAP-15765` and `PDIAP-14859` should not be treated as April 20 work; they happened before this workday and should not be repeated in standups for this date.
 - David confirmed the production build already contains the commit that added the LaunchDarkly flag, so the working hypothesis should move away from "missing code in production build" and toward LaunchDarkly evaluation context, targeting, initialization timing, or downstream gating conditions.
 - David has source-code access and can use Charles Proxy during local investigation, but does not yet know where the LaunchDarkly context attributes are assembled on iOS.
 - Jeff explicitly confirmed the REST-flag investigation should remain the priority over Adam's separate service-side flow issue.
@@ -52,6 +52,7 @@ updated: 2026-04-20
 - David clarified additional Fidelity-side process context: Quy acts as Scrum Master, manages retrospectives, DSE/daily syncs, sprint review, and sprint planning, retrospectives use Miro, Jira is the tracking system, and the Fidelity-side sprint cadence is two weeks with labels like `PDIAP 26Q1.1` and `PDIAP 26Q2.1`.
 - David corrected the Q2 sprint examples: `PDIAP 26Q2.1` is `3/26 - 4/09`, and `PDIAP 26Q2.2` is `4/09 - 4/23`.
 - David clarified that Jira should be represented as a first-class Fidelity tool/system because it is used more heavily than Confluence in day-to-day work tracking.
+- David clarified that `PDIAP-15838` is assigned to the next sprint, so it should not be described as current-sprint in-progress implementation work.
 
 ---