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

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

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.