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

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

Browse Source
This commit is contained in:
David Delagneau
2026-04-21 07:33:53 -06:00
parent 4d8948672b
commit 688b4d462a
5 changed files with 20 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -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`.