feat: Add context and guidance on AO fallback handling and validation discrepancies for iOS

ai/context/workstreams/ao-discourse.md

@@ -12,6 +12,8 @@ Handle externally reported issues without misclassifying scope or over-claiming
 - External reports should be treated as external behavior until verified.
 - Many issues only reproduce with authenticated users or in consumer-specific contexts.
 - Some historical reports turned out to be service/configuration issues, environment issues, or existing behavior rather than new regressions.
+- AO-backed flows still carry older service conventions that can differ from what newer XFlow SwiftUI paths were primarily validated against.
+- In at least some AO validation cases, iOS expected `validations` while older AO payloads could still send fallback-style keys such as `birthDate`.
 
 ---
 
@@ -24,6 +26,8 @@ Handle externally reported issues without misclassifying scope or over-claiming
   - whether the issue exists in main
   - whether the behavior is external, existing, or regression
 - Do not use vague comparison phrases like "same behavior" without scope.
+- For AO consumers, check whether the payload shape reflects older AO service conventions before concluding the issue is purely client-side.
+- If iOS-only behavior appears around validation decoding, compare what AO sends against older fallback handling already present in XFlow, especially when Android appears more permissive.
 
 ---
 
@@ -31,3 +35,4 @@ Handle externally reported issues without misclassifying scope or over-claiming
 
 - Historical reports around button visibility, analytics, slot updates, and consumer validation repeatedly required deeper reproduction work before scoping a fix.
 - Slack history shows multiple examples where the original ticket or report was not enough to define the real root cause.
+- Jeff clarified on April 15, 2026 that these fallback validation paths exist largely to accommodate AO flows. AO was the earliest service integration, built around older custom backend tooling and harder-to-change payload conventions, while newer consumer services were primarily built through Slate and aligned more naturally with `validations` during the SwiftUI refactor.

ai/logs/2026-04-15.md

@@ -18,3 +18,18 @@
 - This separate `HybridBrokerage` path currently appears consistent across iOS and Android, so it may be expected flow/service behavior rather than the same client-side defect.
 - Confidence is still limited: David wants to re-check whether anything changed in that path before stating that conclusion too strongly.
 - One reason for suspicion is that the validation appears to use `min: 10` and `max: 10`, which may indicate questionable or non-meaningful validation setup rather than the same decoding problem tracked in the iOS story.
+- Latest clarification from David: the original iOS-only issue is specifically that iOS does not recognize rules when they come under the `birthDate` key.
+- Once the payload was changed from `birthDate` to `validations`, the originally reported iOS issue no longer reproduced and the validation loaded correctly.
+- Fresh guidance from Jeff after the Android reproduction: this follow-up question should be sent to Rashmi as a separate consumer-side confirmation request, not answered internally.
+- Jeff asked that the message start with: `One follow-up question about the other issue I found while attempting to reproduce (this was what I had originally thought your team was reporting):`
+- Jeff also wants the message to end by asking whether Rashmi thinks that behavior is a bug as well.
+- Later clarification from Jeff: send Rashmi a separate message asking whether their team changed the service payload on their side, since the original iOS-only Youth issue no longer reproduces after the payload moved from `birthDate` to `validations`.
+- Jeff's current framing: even if their side changed the payload and the issue no longer reproduces, the iOS-side handling gap likely still should be fixed because the problem was iOS-only.
+
+## Jeff Context On AO Fallback Handling
+
+- Jeff confirmed the minimal iOS fallback change is the right fix for this issue.
+- He clarified that the preexisting fallback-style validation handling in XFlow exists largely to accommodate AO flows.
+- Jeff's project history note: AO is the oldest service integration and has older, harder-to-change payload conventions, while newer consumer services were largely built through Slate and were the primary validation target during the SwiftUI refactor.
+- That history explains why `validations` aligned better with newer SwiftUI work, while older AO payload shapes can still require explicit iOS fallback handling.
+- Jeff's practical guidance: when the issue is AO-consumer-specific, iOS-only, and caused by a mismatch between what the AO service sends and what the SDK expects, the easiest fix is often to add the minimal compatibility fallback on iOS.