david.delagneau
1ad707373a
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps. - Established a daily logs index for easy navigation of daily notes. - Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation. - Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams. - Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
62 lines
5.5 KiB
Markdown
62 lines
5.5 KiB
Markdown
---
|
|
type: daily
|
|
project: fidelity
|
|
date: 2026-04-15
|
|
focus: [xflow-swiftui-migration, ao-discourse]
|
|
work-items: [pdiap-14859, pdiap-15765]
|
|
blockers: []
|
|
updated: 2026-04-16
|
|
tags:
|
|
- daily
|
|
- fidelity
|
|
---
|
|
# 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.
|
|
|
|
## PR Drafting Context
|
|
|
|
- The `xflow-for-ios` PR template currently uses sections `## What`, `## Why`, `## How`, `### Changes details`, and `## Missed anything?` with a final checklist.
|
|
- The April 15 iOS fix PR is a one-line change in `XFlowViewAdapterRepresentable.swift` for `.apxDateSelect`, adding `birthDate` as a fallback after `validations`.
|
|
- This PR should be described as a small compatibility bug fix for older AO-style payloads rather than as a broader Android-parity refactor.
|
|
- David opened the PR for this minimal iOS compatibility fix.
|
|
|
|
## Standup And Flow Naming Notes
|
|
|
|
- David prefers standups to use one top-level Jira bullet with indented sub-bullets when a single ticket has multiple updates.
|
|
- In recent standup wording, `Youth flow` should be treated as shorthand for the real flow ID `HybridYouthAccountOpening`.
|
|
- The relevant page in that flow is `TeenIdentityCheck`.
|
|
- The separate authenticated flow under discussion remains `HybridBrokerageAccountOpening`, with the relevant page `JointIdentityCheck`.
|