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

2026-04-14

Previous Workday Refresh

• PDIAP-14859 rollout draft remained in revision on April 13 rather than being finalized; the work was limited to the specific draft changes requested in review, not a broad rewrite.
• The rollout document should rename the proposed flag from xflow-master-swiftui-enabled to xflow-swiftui-enabled.
• The first rollout phase should explicitly mention contacting consumers ahead of time and asking them to validate their flows in XQ1.
• The rollout document should remove overly technical wording and avoid implying there are no consumer-side changes without qualification.
• Current spike clarification: FTTransfer changes are no longer considered strictly required after applying the SwiftUI dismissal behavior correctly, but risky entry points still need explicit rollout coverage.

AO / Discourse Findings

• The AO reply about TeenIdentityCheck was approved and sent after clarifying that CheckIdentity was already correct and that the TeenIdentityCheck issue was the missing validations root and missing eighteenOrAbove inside validation-rules.
• Later validation showed two distinct authenticated scenarios rather than one uniform cross-platform issue.
• A HybridBrokerage scenario reproduces on both iOS and Android.
• A Youth flow (Open an account -> Save & Invest for a child -> Fidelity Youth Account) fails on iOS while working on Android.
• Current evidence suggests Android is more flexible when decoding rule variations, while iOS is stricter about the expected validation-rules structure in the Youth-flow scenario.
• The iOS-only Youth-flow discrepancy is the scenario currently aligned with the story-level client fix.
• The cross-platform HybridBrokerage scenario should stay scoped separately until it is clear whether it is a service/config issue or a distinct bug.

Current Direction

• PDIAP-14859 remains focused on incorporating rollout-document feedback and publishing a consumer-facing plan.
• PDIAP-15838 remains the next implementation story after the rollout-document work is in a good state.

New Investigation Note

• For the Murali group discussion, there appears to be usage of ApexBridgingAddressComponent through references in XFlowPageApexItem.
• If that usage is active, the dependency comes from ApexKitV3, which was expected to retain support after the earlier ApexKit removal.
• Current guidance from that discussion is to migrate toward FDS or ApexKitSwiftUI, but the exact replacement for ApexBridgingAddressComponent is still unclear and needs investigation and validation.
• Narrower wording for the current status: there are visible references at a glance, but it is not yet confirmed whether they are active or dead code; the next step is to validate with a run.

Fresh Mattermost Sync

• Confirmed with breakpoints that ApexBridgedAddressComponent is not used when loading an address component; the observed path goes through ApexGoogleAddressViewModel.
• A follow-up review raised that the old component may still be used to load rules and appears in XFloaValueChanger, so it should not be treated as dead code without deeper verification.
• Current direction for that investigation is to be exhaustive and avoid assumptions before describing the old bridged path as unused.
• Clarification from the same thread: the remaining ApexKitV3 reference does not cause build issues because ApexKitSwiftUI still depends on ApexKitV3.
• PDIAP-14859 rollout-document follow-up: Jeff asked whether the FTTransfer section needed updating, and David confirmed the document had already been revised to clarify that root cause.
• Latest clarification in the Murali thread: ApexBridgedAddressComponent belonged to the old UIKit rule-handling flow. In the current implementation, rules are described as being handled through the SwiftUI path, parsed from the payload and applied through the XFlowViewApadater / ViewModelAdapter layer using ApexGoogleAddressViewModel.
• Clarification for the retro/ownership discussion: the earlier FTTransfer-side explanation was not fully wrong, but it was incomplete. The SwiftUI state behavior was a real symptom/effect on the consumer side; the deeper root cause was the dismissal flow handling that had not been covered correctly. The main gap was concluding consumer ownership before isolating that underlying dismissal root cause.
• Suggested clarification for Jeff and Aylwing: the dismissal issue should be framed as a corner case that was not simple to identify without deeper analysis. The FTTransfer-side SwiftUI behavior was still a real observed symptom, but the deeper root cause only became clear after more thorough investigation.
• Additional clarification for that same reply: the FTTransfer-side state-management behavior should be described as a real SwiftUI anti-pattern that can cause view/state identity loss. That behavior was valid to call out, but it still did not fully explain the deepest root cause until the dismissal-path analysis was completed.
• Jeff clarified the broader lesson: if ownership is still uncertain, the safer path is to roll back and continue investigating rather than make confident claims about consumer-side fault before the code is fully understood. The risk is loss of trust and reduced ability for the framework team to make authoritative calls independently.