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

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.