From e389e0ae5e759b8a729806ae7fd411f2861f8023 Mon Sep 17 00:00:00 2001 From: "david.delagneau" Date: Wed, 15 Apr 2026 08:41:03 -0600 Subject: [PATCH] feat: Update documentation for PDIAP-14859 and PDIAP-15765, including rollout approvals and next steps --- ai/logs/2026-04-14.md | 9 +++++++++ ai/logs/2026-04-15.md | 20 ++++++++++++++++++++ ai/state/current.md | 27 +++++++++++---------------- ai/state/work-items.md | 4 ++-- ai/work-items/index.md | 6 +++--- ai/work-items/pdiap-14859.md | 7 ++++++- ai/work-items/pdiap-15765.md | 8 +++++--- 7 files changed, 56 insertions(+), 25 deletions(-) create mode 100644 ai/logs/2026-04-15.md diff --git a/ai/logs/2026-04-14.md b/ai/logs/2026-04-14.md index 18e4cc1..39d92cb 100644 --- a/ai/logs/2026-04-14.md +++ b/ai/logs/2026-04-14.md @@ -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. diff --git a/ai/logs/2026-04-15.md b/ai/logs/2026-04-15.md new file mode 100644 index 0000000..6a0c961 --- /dev/null +++ b/ai/logs/2026-04-15.md @@ -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. diff --git a/ai/state/current.md b/ai/state/current.md index d21f243..18390a9 100644 --- a/ai/state/current.md +++ b/ai/state/current.md @@ -7,24 +7,19 @@ - Debug Discourse and AO issues - Prepare better updates for the current manager or stakeholder through Mattermost - Follow up on active tickets through `ai/work-items/`, especially `PDIAP-14859`, `PDIAP-15765`, `PDIAP-15836`, and `PDIAP-15838` -- Finalize `PDIAP-14859` with a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately -- Prioritize `PDIAP-15838` next; `PDIAP-15836` comes later +- Wrap up `PDIAP-14859` by publishing the approved rollout document, linking the spike-result documents and follow-up story, then closing the spike +- After the immediate `PDIAP-14859` closeout and `PDIAP-15765` resume work, return to `PDIAP-15838`; `PDIAP-15836` comes later +- Resume `PDIAP-15765` for the authenticated iOS-only Youth `TeenIdentityCheck` handling gap so iOS aligns with Android behavior +- Keep the separate `HybridBrokerage` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there - Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers - Thoroughly verify current `ApexBridgingAddressComponent` / rule-loading usage before describing it as inactive or dead code - Reconcile the old UIKit address-rule path with the current SwiftUI handling path through the adapter/view-model layer before reporting final ownership or replacement guidance -- Prioritize same-day research on `ApexKitV3` removal risk and prepare a high-level Confluence write-up for Quy by `4:30 PM` if possible +- The ApexKitV3 risk write-up for Quy has been published and sent; use that research as the current high-level framing for dependency-removal risk - Investigate the current XFlow dependency surface on `ApexKitV3`, including the `23` build errors on removal and the remaining `13` errors when swapping to `ApexKitSwiftUI` -- The process-oriented rollout document for the UIKit-removal spike has been drafted and sent to Jeff for review +- The process-oriented rollout document for the UIKit-removal spike is approved and ready to publish for spike closure - The rollout document should frame the work as a more deliberate migration phase toward the SwiftUI-only path, not as a correction to a prior failed attempt -- The rollout document should make clear that the migration plan uses a dual-path pattern to switch between the `UIHostingController` path and the SwiftUI-only path during rollout -- The rollout should be described as a global feature-flag rollout, not entry-point-based enablement -- The document should emphasize broad validation in XQ1 before any production release -- The document is directed to consumers and should not use stakeholder-oriented wording -- The rollout document should not say rollout phases begin with low-risk consumers; the global flag applies to all flows together once production rollout begins -- Broad XQ1 validation is a required gate before any production enablement -- The document should explicitly mention applying architectural improvements learned from prior SwiftUI iterations, especially where earlier approaches introduced anti-patterns -- The rollout document should stay concise and avoid an overly complex phase model -- The rollout document needs one more revision before publishing, including the `xflow-swiftui-enabled` flag name, clearer first-phase consumer contact and `XQ1` validation language, and removal of overly technical wording +- The rollout document uses a global feature-flag rollout model with broad XQ1 validation before production enablement +- The rollout document should use the new flag name `xflow-swiftui-container-enabled` and note that the flag will be added later during implementation - Re-check the authenticated AO validation issue with scenario-specific evidence: the Youth `TeenIdentityCheck` path currently points to an iOS-only decoding gap, while a separate `HybridBrokerage` case reproduces on both platforms --- @@ -39,13 +34,12 @@ - Validating dismissal sequencing changes across SwiftUI flows - Keeping REST deprecation scope explicit while GraphQL fallback still exists - Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement -- Keeping the consumer-facing rollout document aligned with the actual global-flag rollout model and broad XQ1 validation requirement -- Incorporating Jeff's pending review feedback on the `PDIAP-14859` rollout draft once it arrives +- Closing `PDIAP-14859` cleanly with the right links, blocker relationship, and feature-flag wording - Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope - Avoiding assumptions about legacy Apex/ApexKit paths; breakpoint evidence and helper usage both need to be reconciled before reporting ownership or replacement guidance - When ownership is still uncertain under production pressure, prefer rollback-plus-investigation framing over confident blame assignment to consumers - Swift 6 migration risk is now time-sensitive because external dependency removal could break XFlow before the planned `26Q3` work -- The write-up for Quy needs a high-level risk framing, affected components/flows, and retesting scope rather than low-level implementation detail +- The write-up for Quy should remain the reference framing for moderate effort, medium risk, and required consumer validation while deeper implementation details are still being researched --- @@ -59,6 +53,7 @@ - Standups should omit side questions or manager-only context refreshes unless they materially changed story work - If a root cause document or other documentation update directly supports a story, it should be reported under that story instead of as a separate standalone item - Standups should omit items not tied to a story unless they are real blockers +- If a new request is important work but not directly tied to a Jira item, include it as a standalone bullet instead of forcing it under a story - Manager updates should be short, precise, and natural in English - Mattermost messages should make scope and next action explicit - When root cause is not fully isolated, do not position framework conclusions as authoritative consumer-side fault diff --git a/ai/state/work-items.md b/ai/state/work-items.md index 3fe6e0f..ece01ee 100644 --- a/ai/state/work-items.md +++ b/ai/state/work-items.md @@ -10,7 +10,7 @@ Update the per-ticket files first when scope, status, sequencing, or communicati - `PDIAP-14859` - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation Detail: `ai/work-items/pdiap-14859.md` - Current note: rollout draft has been reviewed; next revision should incorporate the `xflow-swiftui-enabled` flag name, explicit first-phase consumer contact and `XQ1` validation, and tighter consumer-facing wording before publishing. + Current note: the impact write-up is published, and the rollout document is approved for publication; update it to use the new flag name `xflow-swiftui-container-enabled` with a note that it will be added later during implementation, then publish and close out the spike with `Spike Results:` links. - `PDIAP-15838` - Remove Apollo for iOS Detail: `ai/work-items/pdiap-15838.md` @@ -22,4 +22,4 @@ Update the per-ticket files first when scope, status, sequencing, or communicati - `PDIAP-15765` - AO DOB field error not showing investigation Detail: `ai/work-items/pdiap-15765.md` - Current note: authenticated AO validation work now has two scenarios: an iOS-only Youth `TeenIdentityCheck` decoding gap and a separate cross-platform `HybridBrokerage` case that should stay scoped separately. + Current note: move the story back to In Progress for the authenticated iOS-only Youth `TeenIdentityCheck` handling gap, while keeping the separate cross-platform `HybridBrokerage` case out of scope for this fix. diff --git a/ai/work-items/index.md b/ai/work-items/index.md index 06f7585..12ea634 100644 --- a/ai/work-items/index.md +++ b/ai/work-items/index.md @@ -9,7 +9,7 @@ Provide a quick view of active and recently relevant Jira-linked work while keep ## Active - [pdiap-14859.md](./pdiap-14859.md) - `PDIAP-14859` `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation` active spike/planning work around dual UIKit/SwiftUI support, dynamic `UIHostingController` removal, and consumer rollout planning. + `PDIAP-14859` `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation` spike wrap-up work around dual UIKit/SwiftUI support, dynamic `UIHostingController` removal, consumer rollout planning, and linking the final result documents. - [pdiap-15838.md](./pdiap-15838.md) `PDIAP-15838` next story to work on; approved scope removes Apollo and GraphQL-specific iOS transport code while leaving REST. @@ -17,10 +17,10 @@ Provide a quick view of active and recently relevant Jira-linked work while keep - [pdiap-15836.md](./pdiap-15836.md) `PDIAP-15836` approved follow-up story for dismissal delegate lifecycle sequencing in pure SwiftUI; comes after `PDIAP-15838`. -## Holding / Closure Pending +## Active / Reopened - [pdiap-15765.md](./pdiap-15765.md) - `PDIAP-15765` authenticated-only TeenIdentityCheck DOB issue; root cause documented and waiting for the right closure timing. + `PDIAP-15765` authenticated-only TeenIdentityCheck DOB issue; reopened around the iOS-only Youth-flow handling gap while the separate cross-platform `HybridBrokerage` scenario stays out of scope. --- diff --git a/ai/work-items/pdiap-14859.md b/ai/work-items/pdiap-14859.md index de278ca..e97268c 100644 --- a/ai/work-items/pdiap-14859.md +++ b/ai/work-items/pdiap-14859.md @@ -4,6 +4,7 @@ - Active - Rollout draft prepared and sent to Jeff for review on April 13, 2026 +- Rollout document approved for publication; publish and close out the spike next --- @@ -35,7 +36,11 @@ - The draft shared with Jeff already reflects the global feature flag, broad `XQ1` validation, and consumer-facing rollout flow guidance. - Additional review feedback from April 13: rename the proposed flag to `xflow-swiftui-enabled`, make consumer contact and `XQ1` validation explicit in the first phase, remove overly technical rollout wording, and avoid implying there are no consumer-side changes without qualification. - On April 14, Jeff asked whether the FTTransfer part of the rollout document also needed updating; David confirmed the document had already been revised to clarify that root-cause section. -- Await final follow-up after incorporating the latest review feedback. +- April 15 clarification: do not reuse the existing SwiftUI LaunchDarkly flag for this rollout. +- The new flag name for this work should be `xflow-swiftui-container-enabled`. +- The document should note that the flag is `to be added in the future as part of implementation`. +- Late April 14 guidance: the document was approved late in the day; the next step is to publish it, then close out the spike by commenting `Spike Results:` with the relevant document links and the new follow-up story link. +- The new follow-up story should also be marked as a blocker for the reopened UIKit-removal story. --- diff --git a/ai/work-items/pdiap-15765.md b/ai/work-items/pdiap-15765.md index 3da0da5..37b5df8 100644 --- a/ai/work-items/pdiap-15765.md +++ b/ai/work-items/pdiap-15765.md @@ -2,8 +2,8 @@ ## Status -- Holding -- Ready for closure timing review +- Active again +- Move back to In Progress on the next workday --- @@ -38,4 +38,6 @@ ## Next Step -- Jeff approved moving the story to Done once the new sprint starts. +- Resume the story and implement the iOS-side handling so the authenticated Youth `TeenIdentityCheck` service response is handled the same way as Android. +- Keep the separate `HybridBrokerage` scenario out of the client-fix scope unless later evidence proves it is part of the same issue. +- Consider a separate follow-up ticket for the cross-platform service-side issue if that path still stands after the iOS-only fix is underway.