feat: Update Quy Mai's role description and guidance for clarity on Scrum Master title usage

This commit is contained in:
2026-04-14 14:31:11 -06:00
parent 494978605e
commit 6fcf3de2c3
3 changed files with 19 additions and 1 deletions

View File

@@ -12,6 +12,8 @@
- 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
- 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 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
@@ -42,6 +44,8 @@
- 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
---