fidelity-ai-workspace/ai/logs/2026-04-15.md

2026-04-15

Toggle Name Follow-up

• Additional historical context from Teams suggests the existing LaunchDarkly flag name xflow-master-swiftui-enabled was already shared in the Fid4 LaunchDarkly project as the SwiftUI toggle.
• User-provided historical references: Neetu Gupta asked for the SwiftUI toggle name and Jason Mandozzi replied with xflow-master-swiftui-enabled plus the LaunchDarkly link; in January 2025, Thomas Payne also asked whether the team was ready to activate that same toggle.
• Current interpretation: the team may be able to keep using the same flag name even though the rollout intent is now narrower. In the current rollout, toggling would switch only the final UIHostingController wrapping on or off, while SwiftUI remains in use either way.
• This historical evidence supports keeping the existing flag name if renaming would add friction, but the semantic mismatch should still be acknowledged when describing the rollout.
• Fresh clarification from Jeff on April 15: do not reuse the old SwiftUI LaunchDarkly flag for this rollout.
• New required flag name for the rollout document: xflow-swiftui-container-enabled.
• The rollout document should explicitly note that this new flag is to be added in the future as part of implementation.
• Jeff plans to ask later how to get the new flag added when implementation time comes.

PDIAP-15765 Follow-up Drafting Context

• David plans to confirm that PDIAP-15765 was moved from investigation back to In Progress.
• Current working interpretation: the HybridBrokerageAccountOpening / JointIdentityCheck behavior appears to be a different issue from the iOS-only Youth TeenIdentityCheck gap.
• This separate HybridBrokerage path currently appears consistent across iOS and Android, so it may be expected flow/service behavior rather than the same client-side defect.
• Confidence is still limited: David wants to re-check whether anything changed in that path before stating that conclusion too strongly.
• One reason for suspicion is that the validation appears to use min: 10 and max: 10, which may indicate questionable or non-meaningful validation setup rather than the same decoding problem tracked in the iOS story.
• Latest clarification from David: the original iOS-only issue is specifically that iOS does not recognize rules when they come under the birthDate key.
• Once the payload was changed from birthDate to validations, the originally reported iOS issue no longer reproduced and the validation loaded correctly.
• Fresh guidance from Jeff after the Android reproduction: this follow-up question should be sent to Rashmi as a separate consumer-side confirmation request, not answered internally.
• Jeff asked that the message start with: One follow-up question about the other issue I found while attempting to reproduce (this was what I had originally thought your team was reporting):
• Jeff also wants the message to end by asking whether Rashmi thinks that behavior is a bug as well.
• Later clarification from Jeff: send Rashmi a separate message asking whether their team changed the service payload on their side, since the original iOS-only Youth issue no longer reproduces after the payload moved from birthDate to validations.
• Jeff's current framing: even if their side changed the payload and the issue no longer reproduces, the iOS-side handling gap likely still should be fixed because the problem was iOS-only.

Jeff Context On AO Fallback Handling

• Jeff confirmed the minimal iOS fallback change is the right fix for this issue.
• He clarified that the preexisting fallback-style validation handling in XFlow exists largely to accommodate AO flows.
• Jeff's project history note: AO is the oldest service integration and has older, harder-to-change payload conventions, while newer consumer services were largely built through Slate and were the primary validation target during the SwiftUI refactor.
• That history explains why validations aligned better with newer SwiftUI work, while older AO payload shapes can still require explicit iOS fallback handling.
• Jeff's practical guidance: when the issue is AO-consumer-specific, iOS-only, and caused by a mismatch between what the AO service sends and what the SDK expects, the easiest fix is often to add the minimal compatibility fallback on iOS.