fidelity-ai-workspace/project-knowledge/06-daily/2026-04-20.md

type: daily project: fidelity date: 2026-04-20 status: active focus: [rest-migration] work-items: [pdiap-15838] blockers: [] tags: - daily - fidelity updated: 2026-04-20

2026-04-20

Focus

• Prioritize investigation into why REST is not activating on iOS.
• Continue PDIAP-15838 with the investigation as the immediate focus.

---

Work Done

• Continued the REST activation investigation tied to PDIAP-15838.
• Refined the current Apollo-removal analysis and next implementation order for PDIAP-15838.

---

Findings

• 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.
• Jeff wants faster progress on the REST-flag investigation and asked David to keep him updated while continuing the current research.
• Jeff suggested using outside help while the direct Flagship LaunchDarkly access gap remains: monitor the Tauf thread, follow the redirect to Jeffrey O'Leary, describe the issue in detail to the AI tool with build settings and tool details, and ask Aylwing for a quick sanity check if available.
• Jeff referred to GitHub Copilot as the Fidelity-side AI tool that may produce better results when David provides richer local product context than Jeff can summarize indirectly.
• Current local evidence says the LaunchDarkly boolean evaluates to true, the payload is present, and the context is being sent; the remaining questionable area is whether the production-side context or timing is still affecting real-device behavior.
• A plausible fallback explanation, if the issue reappears, is a real-device-only environment difference rather than business logic alone, including LaunchDarkly context interpretation, timing, or cached toggle state that would not match the simulator path.
• Adam Abdelhadi was the reported source of the REST activation problem, and his side validates behavior on real devices.
• Jeff later relayed that Adam says the latest build is now activating REST correctly, so the urgent production-toggle investigation is no longer the immediate focus.
• Jeff directed David to switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles.
• AI-assisted codebase analysis for PDIAP-15838 says the main remaining Apollo blockers are residual XFlow.Slot model coupling in the page interactor/worker path, init/session lifecycle coupling to NetworkClient, and remaining Apollo build/dependency wiring.
• The proposed safe order is: replace XFlow.Slot with a transport-agnostic type first, decouple init/session from NetworkClient without changing REST endpoint behavior, then remove runtime GraphQL code, Apollo project wiring, Apollo-only tests/scripts/docs, and treat any PicoSDK-transitive Apollo dependency as a later dependency-exit step.
• The current risk is no longer GraphQL transport itself; it is hidden runtime or public-API coupling plus the chance of claiming full Apollo removal while a transitive dependency still exists through PicoSDK.
• Follow-up AI analysis says the XFlow.Slot replacement may be simpler than expected: no new model may be needed because activitySession?.stagedValues() already yields [String: String] and XFlowUpdateSlotsRequest.slots already accepts [String: String]. If that holds in code, the current Apollo dependency is mostly an unnecessary intermediate conversion step.
• Local trial changes showed that XFlow.Slot is likely not the only remaining Apollo-dependent model in the first-step cleanup path, so the next Copilot pass should validate the real dependency surface through xcodebuild errors instead of assuming static references tell the whole story.
• Additional Copilot validation on Apollo-generated enums says the checked production callers for XFlow.ContentType, XFlow.ScreenshotFormat, and XFlow.NextTransitionType appear to need only native String-backed enums plus the current local fallback behavior, not Apollo EnumType semantics.
• 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.

---

Communication

---

Next Steps

• Investigate why REST is not activating on iOS.
• Inspect where iOS builds and identifies the LaunchDarkly context so local logs and Charles captures can confirm which attributes are actually sent.
• Package the current reproduction details for the AI tool, including build settings and the external tool being used.
• Keep watching the outreach thread with Tauf / Jeffrey O'Leary and ask Aylwing for a quick perspective if he is available.
• Resume PDIAP-15838 implementation work for removing GraphQL and related LaunchDarkly toggles.

---

Blockers

• None currently.