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

feat: Update rollout documents and work items for UIKit-removal spike, clarifying consumer communication and validation expectations

Browse Source
This commit is contained in:
David Delagneau
2026-04-14 14:14:33 -06:00
parent bbac484170
commit 494978605e
5 changed files with 64 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
ai/state/current.md
View File

@@ -10,6 +10,8 @@
- 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
- 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
- The process-oriented rollout document for the UIKit-removal spike has been drafted and sent to Jeff for review
- 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
@@ -20,6 +22,8 @@
- 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
- 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
---
@@ -35,6 +39,9 @@
- 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
- 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
---
@@ -50,6 +57,7 @@
- Standups should omit items not tied to a story unless they are real blockers
- 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
- Standups should be written as David's external progress report and should not mention Jeff by name
- Standups should never mention Mattermost because it is internal-only communication