feat: Update rollout document to clarify global feature-flag rollout and emphasize consumer-facing language

ai/state/current.md

@@ -13,6 +13,13 @@
 - Focus now on creating a process-oriented rollout document for the UIKit-removal spike that can be shared for feedback
 - 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
 
 ---
 
@@ -26,6 +33,7 @@
 - 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
 
 ---