feat: Enhance project documentation with updates on REST migration, GitHub Copilot, and LaunchDarkly integration

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

@@ -41,6 +41,7 @@ tags:
 - David has now confirmed the production build already contains the commit that added the LaunchDarkly flag, so the current investigation should focus more on LaunchDarkly evaluation context, targeting, initialization timing, and any additional transport-selection gating on iOS
 - Jeff explicitly wants the REST-flag investigation to stay ahead of Adam's separate service-side flow report for now and wants faster visible progress on that path
 - 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
 - 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
@@ -60,6 +61,8 @@ tags:
 - David does not yet know where the iOS app assembles or identifies the LaunchDarkly context attributes, but can inspect source code and use Charles Proxy during investigation
 - Current local evidence shows the LaunchDarkly boolean evaluating to `true`, with payload and context present from the iOS side, so the remaining uncertainty is around production-side context interpretation, timing, caching, or additional downstream gating
 - The urgent REST-activation investigation is no longer the immediate blocker after Adam reported the latest build working, but the earlier context/timing uncertainty remains useful background if the issue reappears
+- 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
 - Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope

project-knowledge/02-work-items/pdiap-15838.md

@@ -6,8 +6,8 @@ ticket: PDIAP-15838
 title: "Remove Apollo for iOS"
 systems: [xflowsdk]
 workstreams: [rest-migration]
-people: [jeff-dewitte]
+people: [jeff-dewitte, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
-related: []
+related: [launchdarkly, github-copilot]
 updated: 2026-04-20
 tags:
   - work-item
@@ -49,8 +49,10 @@ tags:
 - Treat the REST-activation investigation as the immediate priority before resuming broader Apollo-removal cleanup.
 - 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 the AI tool with build settings and tool details, and ask Aylwing for a quick perspective if available.
+- 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.
+- 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.
 
 ---
 

project-knowledge/03-context/systems/github-copilot.md

@@ -0,0 +1,47 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: [jeff-dewitte]
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-20
+---
+
+# GitHub Copilot
+
+## Role
+
+- GitHub Copilot is a broadly used AI tool in the Fidelity workflow, especially when product-side code access and richer implementation context are available on the Fidelity machine.
+
+---
+
+## Stable Patterns
+
+- Use this tool when the local Fidelity-side product context is richer than what can be summarized indirectly in chat.
+- It is useful for investigation, code-oriented debugging, and implementation support when David can provide concrete build, file, and runtime details from the Fidelity development environment.
+- Tool output should still be checked against local evidence, reproduction results, and confirmed project context.
+
+---
+
+## Current Example
+
+- During the April 20, 2026 REST / LaunchDarkly investigation, Jeff specifically suggested using GitHub Copilot with more detailed local context from David's side.
+
+---
+
+## Risks
+
+- Do not assume the tool output is authoritative without checking it against local evidence.
+- Keep the tool's Fidelity-side access level and data visibility labeled as contextual rather than assumed workspace-wide.
+
+---
+
+## Related Context
+
+- `project-knowledge/04-people/jeff-dewitte.md`
+- `project-knowledge/02-work-items/pdiap-15838.md`

project-knowledge/03-context/systems/index.md

@@ -81,6 +81,12 @@ tags:
 - [nexus-fidelity.md](./nexus-fidelity.md)
   Internal Fidelity tool identified from the current bookmark/tool set.
 
+- [launchdarkly.md](./launchdarkly.md)
+  Feature-flag platform used broadly across the Fidelity workflow for rollout and environment-controlled behavior.
+
+- [github-copilot.md](./github-copilot.md)
+  Fidelity-side AI tool used broadly when richer product-side context is available on the development machine.
+
 ---
 
 ## Guidance

project-knowledge/03-context/systems/launchdarkly.md

@@ -0,0 +1,47 @@
+---
+type: system
+project: fidelity
+status: active
+systems: []
+workstreams: []
+people: []
+related: []
+tags:
+  - system
+  - fidelity
+updated: 2026-04-20
+---
+
+# LaunchDarkly
+
+## Role
+
+- LaunchDarkly is the feature-flag platform used broadly in the Fidelity workflow.
+- It is part of the normal delivery path for controlled rollout, environment-specific behavior, and gradual activation of changes.
+
+---
+
+## Stable Patterns
+
+- LaunchDarkly can affect behavior by environment, context, targeting, timing, and cached flag state.
+- When a bug appears only on certain builds or devices, LaunchDarkly evaluation is a valid investigation path even if local simulator checks look correct.
+- Missing direct dashboard access does not remove LaunchDarkly from consideration; code-side evidence, payload inspection, and runtime evaluation still matter.
+
+---
+
+## Current Example
+
+- During the April 20, 2026 REST migration investigation, LaunchDarkly was a central part of the debugging path because the behavior differed between local validation and consumer real-device reports.
+
+---
+
+## Risks
+
+- Do not assume a simulator result fully represents real-device LaunchDarkly behavior.
+- Do not treat missing direct Flagship dashboard access as proof that LaunchDarkly is not involved; indirect evidence still matters.
+
+---
+
+## Related Context
+
+- `project-knowledge/02-work-items/pdiap-15838.md`

project-knowledge/04-people/adam-abdelhadi.md

@@ -0,0 +1,41 @@
+---
+type: person
+project: fidelity
+role: consumer-side validator
+status: active
+teams: []
+topics: [rest-migration, launchdarkly, real-device-validation]
+related: [pdiap-15838, launchdarkly]
+tags:
+  - person
+  - fidelity
+updated: 2026-04-20
+---
+
+# Adam Abdelhadi
+
+## Role
+
+- Adam reported the iOS-side REST activation problem during the current `PDIAP-15838` investigation.
+- He or his team validate behavior on real devices.
+
+---
+
+## Collaboration Pattern
+
+- Jeff relayed Adam's report that REST was not activating for the affected build and later relayed Adam's update that the latest build was working.
+- Adam's reports are currently relevant as real-device validation input rather than as direct ownership proof for the root cause.
+
+---
+
+## Communication Notes
+
+- Treat Adam's observations as high-value consumer-side validation, especially when simulator and real-device behavior differ.
+- If future context clarifies his exact team or ownership boundary, update this file directly.
+
+---
+
+## Related Context
+
+- `project-knowledge/02-work-items/pdiap-15838.md`
+- `project-knowledge/03-context/systems/launchdarkly.md`

project-knowledge/04-people/aylwing-olivas.md

@@ -3,7 +3,7 @@ type: person
 project: fidelity
 role: collaborator
 status: active
-updated: 2026-04-16
+updated: 2026-04-20
 tags:
   - person
   - fidelity
@@ -31,4 +31,5 @@ Repeated Fidelity collaborator visible across multiple historical Slack channels
 
 - Treat Aylwing as a useful source for higher-level technical framing and dependency risk context
 - Treat Aylwing as a strong reviewer for architecture direction, refactor scope, and risk framing
+- Jeff explicitly suggested asking Aylwing for a quick perspective during the April 20, 2026 REST / LaunchDarkly investigation because of his broad cross-project experience
 - If future context clarifies the formal team or title, update this file directly

project-knowledge/04-people/index.md

@@ -53,6 +53,12 @@ tags:
 - [tauf.md](./tauf.md)
   Taufiqur Ashrafy, often referred to as Tauf; CI/Jenkins support contact who helps with release-pipeline troubleshooting and related publication issues.
 
+- [jeffrey-oleary.md](./jeffrey-oleary.md)
+  Fidelity-side support contact that Tauf redirected David to during the April 20, 2026 REST / LaunchDarkly investigation; exact team and ownership still need confirmation.
+
+- [adam-abdelhadi.md](./adam-abdelhadi.md)
+  Consumer-side validator who reported the REST activation problem during `PDIAP-15838`; he or his team test on real devices.
+
 ## Usage
 
 When a person appears repeatedly in project communication, create or update their file here so the agent can reuse:

project-knowledge/04-people/jeff-dewitte.md

@@ -74,3 +74,5 @@ Good updates usually clarify:
 - Use polished native-sounding English for external-facing comments; avoid sending rough wording when a cleaner version is easy to produce
 - When a consumer issue may actually belong to another team/framework, document the finding clearly and route ownership instead of carrying it indefinitely in XFlow
 - For cross-team status messages, make the sequence of events extremely explicit so the reader can tell what was the original issue, what changed, what XFlow changed, and what remains a separate service-side issue
+- When direct access is missing, Jeff may push for progress through adjacent evidence sources and support contacts instead of waiting on missing permissions
+- Jeff explicitly suggested using the Fidelity-approved AI tool with detailed local context, plus outreach to Aylwing / Tauf / Jeffrey O'Leary, during the April 20, 2026 REST / LaunchDarkly investigation

project-knowledge/04-people/jeffrey-oleary.md

@@ -0,0 +1,41 @@
+---
+type: person
+project: fidelity
+role: support contact
+status: active
+teams: []
+topics: [rest-migration, launchdarkly, build-debugging]
+related: [pdiap-15838, github-copilot]
+tags:
+  - person
+  - fidelity
+updated: 2026-04-20
+---
+
+# Jeffrey O'Leary
+
+## Role
+
+- Fidelity-side contact that Tauf redirected David to during the April 20, 2026 REST / LaunchDarkly investigation.
+- Exact team and formal ownership are still unknown.
+
+---
+
+## Collaboration Pattern
+
+- Jeff approved reaching out to Jeffrey after Tauf suggested he might be familiar with this type of issue.
+- Jeffrey is currently relevant as a possible support contact for build-specific or environment-specific behavior affecting REST activation on iOS.
+
+---
+
+## Communication Notes
+
+- Treat Jeffrey as a suggested escalation/support contact, not yet as a confirmed owner.
+- If future context clarifies his team, access level, or ownership boundary, update this file directly.
+
+---
+
+## Related Context
+
+- `project-knowledge/02-work-items/pdiap-15838.md`
+- `project-knowledge/03-context/systems/github-copilot.md`

project-knowledge/04-people/tauf.md

@@ -10,7 +10,7 @@ aliases: [Taufiqur Ashrafy, Tauf]
 tags:
   - person
   - fidelity
-updated: 2026-04-17
+updated: 2026-04-20
 ---
 
 # Taufiqur Ashrafy
@@ -35,6 +35,7 @@ updated: 2026-04-17
 - Often referred to informally as `Tauf`.
 - Fidelity Teams may show names in a surname-first style, so this person may appear under a different display order there.
 - In the current XFlowViewMaker propagation issue, Tauf clarified that the needed fix belongs in the podspec repo rather than FTFrameworks source, and pointed David toward removing the XFlowViewMaker version constraint for `ftaccountopen`.
+- During the April 20, 2026 REST / LaunchDarkly investigation, Tauf redirected David toward Jeffrey O'Leary as a better contact for that scenario.
 
 ---
 
@@ -42,3 +43,5 @@ updated: 2026-04-17
 
 - `project-knowledge/03-context/workstreams/consumer-integration.md`
 - `project-knowledge/02-work-items/pdiap-15765.md`
+- `project-knowledge/02-work-items/pdiap-15838.md`
+- `project-knowledge/04-people/jeffrey-oleary.md`

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

@@ -38,7 +38,10 @@ updated: 2026-04-20
 - 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.
 - 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`.