david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Update documentation for PDIAP-14859 and PDIAP-15765, including rollout approvals and next steps

Browse Source
This commit is contained in:
David Delagneau
2026-04-15 08:41:03 -06:00
parent 4edc7ef4fc
commit e389e0ae5e
7 changed files with 56 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
ai/logs/2026-04-14.md
View File

@@ -58,3 +58,12 @@
- 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.
## Late-Day Outcome
- The ApexKitV3 impact write-up was revised with the requested wording changes, including using `Impacted Flows` and making consumer validation a direct recommendation rather than a conditional one.
- Jeff approved the ApexKitV3 write-up after those edits, and David published it and sent the Confluence link to Quy with a concise summary of the effort and risk.
- End-of-day direction for `PDIAP-14859`: the rollout document was approved as good enough, but it was not published on April 14. The next step is to publish it on the next workday, then comment the spike with `Spike Results:` links and the follow-up story link.
- The UIKit-removal follow-up story should be linked as a blocker for the reopened UIKit-removal work after the spike is closed out.
- End-of-day direction for `PDIAP-15765`: move the story back to In Progress on the next workday and focus on the authenticated iOS-only Youth `TeenIdentityCheck` gap so iOS handles the service response the same way as Android.
- The separate `HybridBrokerage` scenario remains distinct from the iOS-only Youth-flow issue and may need its own follow-up ticket if the service-side problem still stands after the client-side story is resumed.

20
ai/logs/2026-04-15.md Normal file
View File

@@ -0,0 +1,20 @@
# 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.