feat: Add iOS and Swift context files and guidelines for answering programming questions

ai/context/index.md

@@ -21,6 +21,14 @@ Stable context about core product components and how they relate:
 - [systems/xflowviewmaker.md](./systems/xflowviewmaker.md)
 - [systems/ftframeworks.md](./systems/ftframeworks.md)
 
+### `ios/`
+
+Swift and iOS best-practice context for programming questions:
+
+- [ios/index.md](./ios/index.md)
+- [ios/current-practices.md](./ios/current-practices.md)
+- [ios/project-swift-guidance.md](./ios/project-swift-guidance.md)
+
 ### `workstreams/`
 
 Durable context about recurring streams of work and investigation:
@@ -56,5 +64,6 @@ Confirmed technical or product decisions with ongoing impact.
 
 - Load `project.md` and this index first.
 - Open `systems/` when the question is about architecture, ownership, or integration.
+- Open `ios/` when the question is about Swift, SwiftUI, iOS architecture, testing, concurrency, or debugging.
 - Open `workstreams/` when the question is about current priorities, debugging themes, or historical project patterns.
 - Open `process/` when drafting messages, standups, Jira notes, or deciding how to update memory.

ai/context/ios/current-practices.md

@@ -0,0 +1,62 @@
+# Current iOS And Swift Practices
+
+## Goal
+
+Keep Swift/iOS answers modern without turning the workspace into stale API documentation.
+
+---
+
+## Currentness Rule
+
+For version-sensitive recommendations, verify against official sources before presenting as current best practice.
+
+Prefer:
+
+- Apple Developer Documentation
+- Swift.org / docs.swift.org
+- official WWDC materials when API behavior or migration guidance matters
+
+Avoid relying only on memory for:
+
+- newest SwiftUI APIs
+- Observation / data-flow migration guidance
+- Swift Testing availability or migration advice
+- Swift concurrency behavior
+- Xcode or iOS version-specific recommendations
+
+---
+
+## Stable Defaults
+
+- Prefer simple, testable Swift over clever abstractions.
+- Prefer structured concurrency over ad-hoc callback or detached-task patterns when the deployment target and codebase support it.
+- Keep UI state changes on the main actor.
+- Avoid recommending new APIs until deployment target and project constraints are known.
+- For SwiftUI, separate pure view composition from side effects and navigation/workflow coordination.
+- For testing, use the framework already adopted by the codebase unless the user explicitly asks about migration.
+
+---
+
+## Testing Guidance
+
+- Apple positions Swift Testing as a modern option for unit tests in Xcode 16 and later.
+- XCTest remains relevant, especially for UI tests, performance tests, and existing test suites.
+- Do not recommend wholesale migration from XCTest unless the project constraints support it.
+
+---
+
+## SwiftUI Guidance
+
+- Observation can be adopted incrementally; do not assume a project can immediately replace all `ObservableObject` usage.
+- In SwiftUI code review, focus on data ownership, lifecycle, invalidation scope, navigation boundaries, and side effects.
+- Avoid introducing `@StateObject`, `@ObservedObject`, `@State`, or `@Observable` recommendations without first identifying ownership and deployment constraints.
+
+---
+
+## Source Anchors
+
+- SwiftUI documentation: `https://developer.apple.com/documentation/swiftui`
+- Observation migration: `https://developer.apple.com/documentation/swiftui/migrating-from-the-observable-object-protocol-to-the-observable-macro`
+- Swift Testing: `https://developer.apple.com/documentation/testing`
+- XCTest: `https://developer.apple.com/documentation/xctest`
+- Swift language: `https://developer.apple.com/swift/`

ai/context/ios/index.md

@@ -0,0 +1,23 @@
+# iOS And Swift Context
+
+## Goal
+
+Help the agent answer Swift and iOS programming questions with current best practices while still respecting Fidelity/XFlow project constraints.
+
+---
+
+## Files
+
+- [current-practices.md](./current-practices.md)
+  Rules for staying current with Apple and Swift best practices.
+
+- [project-swift-guidance.md](./project-swift-guidance.md)
+  Fidelity-specific guidance for applying Swift/iOS advice in this workspace.
+
+---
+
+## Usage
+
+- Use these files before answering Swift, SwiftUI, iOS architecture, testing, concurrency, or debugging questions.
+- When a recommendation depends on current Apple APIs, prefer official Apple or Swift documentation before making strong claims.
+- Keep project constraints visible: XFlow is backend-driven, Fid4 is consumer validation, and REST/GraphQL migration constraints may affect architecture.

ai/context/ios/project-swift-guidance.md

@@ -0,0 +1,37 @@
+# Project Swift Guidance
+
+## Goal
+
+Apply Swift/iOS advice in a way that fits Fidelity's XFlow, Fid4, XFlowViewMaker, and FTFrameworks environment.
+
+---
+
+## Fidelity-Specific Constraints
+
+- XFlow is backend-driven; UI behavior may be service/configuration driven, not purely local Swift code.
+- Fid4 is the real consumer validation target for many issues.
+- XFlowViewMaker and FTFrameworks can affect whether a fix is visible in Fid4.
+- REST migration constraints still matter; do not assume REST is active by default.
+- Some work happens behind feature flags, especially risky consumer-impact changes.
+
+---
+
+## SwiftUI / XFlow Priorities
+
+- Treat modal presentation, dismissal sequencing, and lifecycle boundaries as high-risk areas.
+- Be careful when removing UIKit bridges such as `UIHostingController`; preserve consumer behavior and rollout safety.
+- When discussing SwiftUI architecture, include how the change affects:
+  - backend-driven flow rendering
+  - consumer app integration
+  - feature flags
+  - validation in Fid4
+  - UIKit/SwiftUI parity
+
+---
+
+## Answering Rules
+
+- If the user asks a general Swift question, answer generally but include a Fidelity/XFlow note when relevant.
+- If the user asks about a code change, separate modern best practice from what is safe for the current project.
+- If codebase constraints are unknown, say what must be confirmed: deployment target, Xcode version, module ownership, feature flag path, and consumer validation path.
+- For manager-ready explanations, connect the technical recommendation to scope, risk, and validation.