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

ai/context/people/quy-mai.md

@@ -2,7 +2,7 @@
 
 ## Role
 
-Scrum/contact point repeatedly involved in backlog and process management.
+Confirmed Scrum Master / contact point repeatedly involved in backlog and process management.
 
 ---
 
@@ -17,4 +17,5 @@ Scrum/contact point repeatedly involved in backlog and process management.
 ## Guidance
 
 - Treat Quy as an important source for process expectations, backlog cleanup, and story framing
+- When drafting notes or prompts, refer to Quy as Scrum Master rather than a generic stakeholder
 - If future context clarifies the formal title/team, update this file directly

ai/logs/2026-04-14.md

@@ -42,3 +42,16 @@
 - Suggested clarification for Jeff and Aylwing: the dismissal issue should be framed as a corner case that was not simple to identify without deeper analysis. The FTTransfer-side SwiftUI behavior was still a real observed symptom, but the deeper root cause only became clear after more thorough investigation.
 - Additional clarification for that same reply: the FTTransfer-side state-management behavior should be described as a real SwiftUI anti-pattern that can cause view/state identity loss. That behavior was valid to call out, but it still did not fully explain the deepest root cause until the dismissal-path analysis was completed.
 - Jeff clarified the broader lesson: if ownership is still uncertain, the safer path is to roll back and continue investigating rather than make confident claims about consumer-side fault before the code is fully understood. The risk is loss of trust and reduced ability for the framework team to make authoritative calls independently.
+- Jeff also clarified that in this case, if the root cause is architectural on the framework side, the team is not in an authoritative position to call out consumer code. His preferred pattern under uncertainty is rollback plus investigation rather than confident ownership claims.
+
+## ApexKitV3 / Swift 6 Follow-up
+
+- Jeff clarified that when the external team says they will stop support, they mean the dependency will be deleted, which would cause build errors on the XFlow side unless it is removed or replaced.
+- Breakpoint and import-removal follow-up showed that removing `import ApexKitV3` across XFlow causes `23` compilation issues.
+- Replacing those imports with `ApexKitSwiftUI` still leaves `13` build errors.
+- Current high-confidence understanding is that XFlow still has meaningful dependency impact from `ApexKitV3`, and this is not just a trivial dead-code cleanup.
+- Swift 6 support is not yet implemented; related work is planned under a `26Q3` backlog epic.
+- New direction from Jeff after speaking with Quy: spend the rest of today researching the impact of this change and prepare a short Confluence write-up by EOD, preferably by `4:30 PM`.
+- The requested write-up should cover what change is being requested, build-error and component impact, what needs retesting, which flows/components are affected, and the overall risk including whether consumers should be involved in testing.
+- Jeff explicitly wants the document framed as carrying impact and consumer-testing risk if the change requires more than small adjustments.
+- Confirmed wording note: Quy should be treated as Scrum Master in prompts and write-ups, not described generically as a stakeholder.

ai/state/current.md

@@ -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
 
 ---