Keep Fidelity context current from daily work performed on another machine
Track REST migration findings
Debug Discourse and AO issues
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 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
Thoroughly verify current ApexBridgingAddressComponent / rule-loading usage before describing it as inactive or dead code
Reconcile the old UIKit address-rule path with the current SwiftUI handling path through the adapter/view-model layer before reporting final ownership or replacement guidance
The ApexKitV3 risk write-up for Quy has been published and sent; use that research as the current high-level framing for dependency-removal risk
Investigate the current XFlow dependency surface on ApexKitV3, including the 23 build errors on removal and the remaining 13 errors when swapping to ApexKitSwiftUI
The process-oriented rollout document for the UIKit-removal spike is approved and ready to publish for spike closure
The rollout document should frame the work as a more deliberate migration phase toward the SwiftUI-only path, not as a correction to a prior failed attempt
The rollout document uses a global feature-flag rollout model with broad XQ1 validation before production enablement
The rollout document should use the new flag name xflow-swiftui-container-enabled and note that the flag will be added later during implementation
Re-check the authenticated AO validation issue with scenario-specific evidence: the HybridYouthAccountOpening / TeenIdentityCheck path currently points to an iOS-only decoding gap, while a separate HybridBrokerageAccountOpening / JointIdentityCheck case reproduces on both platforms
The immediate Youth issue was fixed on the service side for the Youth-flow TeenIdentityCheck path after the payload moved from birthDate to validations; local Fid4 validation also confirmed it. The XFlowSDK-side fallback PR should still ship in the next release
Jeff later decided the iOS fallback PR should be treated as the primary fix path for the Youth issue rather than relying on a separate service rollout; the QA-side service change has since been rolled back and Fid4 validation still passed with the PR in place
When describing the XFlowSDK fallback PR, frame it as a compatibility improvement for similar future birthDate payloads, not as a fix for the separate HybridBrokerageAccountOpening / JointIdentityCheck issue
The Youth / TeenIdentityCheck issue was iOS-only; do not describe it as reproducing on both platforms
The service-side payload update and the XFlowSDK fallback PR address the same Youth / TeenIdentityCheck issue; do not split them into separate Youth issues when summarizing scope
The PDIAP-15765 compatibility fix is now fully closed out and the story is in Done
A new urgent consumer report says REST calls fail on iOS when the toggle is enabled, but current local validation says REST works on both main and release/4.30; treat version/flag mismatch as the leading explanation until broader evidence says otherwise
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
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
Active Concerns
Authenticated vs non-authenticated behavior
Reproducibility across entry points
Backend-driven inconsistencies in XFlow
Distinguishing external issues from true regressions
Preserving accurate context when summarizing work from another machine
Validating dismissal sequencing changes across SwiftUI flows
Keeping REST deprecation scope explicit while GraphQL fallback still exists
Current LaunchDarkly access does not include Flagship LD projects; only the sample app LD project is available from David's side
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
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
Swift 6 migration risk is now time-sensitive because external dependency removal could break XFlow before the planned 26Q3 work
The write-up for Quy should remain the reference framing for moderate effort, medium risk, and required consumer validation while deeper implementation details are still being researched
Communication Priorities
Standups should reflect the latest technical state, not generic progress
Standups should prefer updates directly tied to active work items over one-off memory refreshes or side questions
Standups should include story titles whenever a reported update maps to a Jira item
Standups should use bullet points for each item, but avoid dash-separated title formatting inside the sentence body
When one Jira item has multiple concrete updates, prefer one top-level Jira bullet with indented sub-bullets rather than repeating the same Jira line multiple times
When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas
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
Manager updates should be short, precise, and natural in English
Mattermost messages should make scope and next action explicit
When root cause is not fully isolated, do not position framework conclusions as authoritative consumer-side fault
Standups should be written as David's external progress report and should not mention Jeff by name
Standups should never mention Mattermost because it is internal-only communication
Notes
REST remains behind a feature flag
Validate against main before calling something a regression
This workspace is the context source for communication, not the source of product code changes
