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.
• Jeff also clarified that in this case, if the root cause is architectural on the framework side, the team is not in an authoritative position to call out consumer code. His preferred pattern under uncertainty is rollback plus investigation rather than confident ownership claims.

ApexKitV3 / Swift 6 Follow-up

• Jeff clarified that when the external team says they will stop support, they mean the dependency will be deleted, which would cause build errors on the XFlow side unless it is removed or replaced.
• Breakpoint and import-removal follow-up showed that removing import ApexKitV3 across XFlow causes 23 compilation issues.
• Replacing those imports with ApexKitSwiftUI still leaves 13 build errors.
• Current high-confidence understanding is that XFlow still has meaningful dependency impact from ApexKitV3, and this is not just a trivial dead-code cleanup.
• Swift 6 support is not yet implemented; related work is planned under a 26Q3 backlog epic.
• New direction from Jeff after speaking with Quy: spend the rest of today researching the impact of this change and prepare a short Confluence write-up by EOD, preferably by 4:30 PM.
• The requested write-up should cover what change is being requested, build-error and component impact, what needs retesting, which flows/components are affected, and the overall risk including whether consumers should be involved in testing.
• Jeff explicitly wants the document framed as carrying impact and consumer-testing risk if the change requires more than small adjustments.
• Confirmed wording note: Quy should be treated as Scrum Master in prompts and write-ups, not described generically as a stakeholder.
• Additional analysis context for the ApexKitV3 investigation: the Swift version change was reverted back to Swift 5, and the Pods were updated to the latest versions including ApexKitSwiftUI 1.27.14. The current question is whether the ApexKitV3-removal impact remains the same under that updated dependency baseline.
• Document-review guidance for the ApexKitV3 impact write-up: it should not read as if code changes have already been made, should stay understandable for a non-technical reader, and should avoid overcommitting on production impact where SwiftUI-vs-legacy-path usage is still being verified.
• Additional document-review guidance: if the write-up already recommends consumer testing, it should not hedge with wording like if the change extends beyond small cleanup. The risk section should stay internally consistent and reflect the current conclusion directly.