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

.opencode/agents/fidelity.md

@@ -32,3 +32,5 @@ Behavior rules:
 - Do not wait for a dedicated sync command if the correct memory update is already obvious.
 - Do not over-promote uncertain information. Keep uncertain items in the daily log.
 - When drafting communication, preserve technical meaning and improve clarity in natural US English.
+- When answering Swift/iOS programming questions, use the project-local iOS skills and `ai/context/ios/`.
+- If the answer depends on current Apple APIs or Xcode/iOS behavior, verify with official Apple or Swift documentation before presenting it as current best practice.

.opencode/commands/fidelity-context.md

@@ -10,6 +10,9 @@ Use these files as the baseline context:
 @ai/AGENTS.md
 @ai/context/index.md
 @ai/context/project.md
+@ai/context/ios/index.md
+@ai/context/ios/current-practices.md
+@ai/context/ios/project-swift-guidance.md
 @ai/context/systems/index.md
 @ai/context/workstreams/index.md
 @ai/context/process/communication.md

.opencode/commands/swift-help.md

@@ -0,0 +1,36 @@
+---
+description: Answer Swift or iOS programming questions with Fidelity/XFlow context
+---
+
+Answer the user's Swift/iOS programming question using current iOS practices and this workspace's Fidelity context.
+
+Read:
+
+@ai/AGENTS.md
+@ai/context/ios/index.md
+@ai/context/ios/current-practices.md
+@ai/context/ios/project-swift-guidance.md
+@ai/context/index.md
+@ai/context/systems/index.md
+@ai/context/workstreams/index.md
+@ai/work-items/index.md
+@knowledge/agent-memory-rules.md
+
+User question:
+
+$ARGUMENTS
+
+Instructions:
+
+- Use the `ios-swift-answering` skill if available.
+- Use `swiftui-xflow-review` if the question touches SwiftUI, XFlow, UIKit bridge removal, modal presentation, lifecycle, or backend-driven UI.
+- Use `ios-testing-strategy` if the question touches tests or validation.
+- If current Apple API behavior matters, verify against official Apple or Swift documentation before making strong claims.
+- Contextualize the answer to Fidelity only when it materially changes the recommendation.
+- Separate current best practice from project-safe recommendation when they differ.
+
+Return:
+
+1. Recommendation
+2. Project-specific caveats
+3. Validation or follow-up checks

.opencode/plugins/fidelity-compaction.js

@@ -16,6 +16,9 @@ export const FidelityCompaction = async ({ directory }) => {
         "README.md",
         "ai/context/index.md",
         "ai/context/project.md",
+        "ai/context/ios/index.md",
+        "ai/context/ios/current-practices.md",
+        "ai/context/ios/project-swift-guidance.md",
         "ai/context/systems/index.md",
         "ai/context/workstreams/index.md",
         "ai/context/process/communication.md",

.opencode/skills/ios-swift-answering/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: ios-swift-answering
+description: Answer Swift, SwiftUI, and iOS programming questions using current Apple guidance while adapting recommendations to Fidelity/XFlow project constraints.
+compatibility: opencode
+---
+
+## When To Use
+
+Use this skill for Swift, SwiftUI, iOS architecture, concurrency, testing, or debugging questions.
+
+## Workflow
+
+1. Identify whether the question is general Swift/iOS or Fidelity-specific.
+2. Read `ai/context/ios/current-practices.md` for currentness rules.
+3. Read `ai/context/ios/project-swift-guidance.md` when the answer may affect XFlow, Fid4, XFlowViewMaker, FTFrameworks, feature flags, or consumer validation.
+4. If the answer depends on current Apple APIs, Xcode versions, or migration guidance, verify with official Apple/Swift documentation before making strong claims.
+5. Separate:
+   - current best practice
+   - project-safe recommendation
+   - assumptions to confirm
+
+## Output Rules
+
+- Be direct and senior-engineer practical.
+- Avoid generic architecture advice when project constraints matter.
+- Do not assume deployment target, Xcode version, or framework migration status.
+- Mention tradeoffs and validation path when relevant.

.opencode/skills/ios-testing-strategy/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: ios-testing-strategy
+description: Recommend iOS testing approaches for Swift, SwiftUI, XFlow, Fid4, and REST migration work while respecting existing XCTest/Swift Testing/project constraints.
+compatibility: opencode
+---
+
+## When To Use
+
+Use this skill for unit tests, UI tests, integration tests, regression coverage, XFlow flow validation, or REST/GraphQL migration testing questions.
+
+## Workflow
+
+1. Identify the behavior under test.
+2. Classify the test level:
+   - unit
+   - integration
+   - UI / consumer flow
+   - exploratory validation
+3. Check whether the behavior depends on backend configuration, auth state, entry point, feature flags, or Fid4 integration.
+4. Prefer the test framework already used by the project unless the user asks about migration.
+5. If suggesting Swift Testing, confirm Xcode/project support first and do not mix APIs inside the same test.
+
+## Project-Specific Guidance
+
+- XFlow behavior may require exploratory validation beyond unit tests.
+- AO/Discourse issues often need auth-state and entry-point coverage.
+- REST migration tests must distinguish REST path from GraphQL fallback.
+- Consumer-facing changes may require Fid4 validation even when SDK tests pass.
+
+## Output Rules
+
+- Recommend the smallest useful test strategy.
+- Include what cannot be proven by that test layer.
+- Mention manual/exploratory validation when code-level tests are insufficient.

.opencode/skills/swiftui-xflow-review/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: swiftui-xflow-review
+description: Review or reason about SwiftUI code in XFlow/Fidelity contexts, especially lifecycle, modal presentation, navigation, backend-driven UI, and UIKit bridge removal.
+compatibility: opencode
+---
+
+## When To Use
+
+Use this skill when a SwiftUI question touches XFlow, Fid4, XFlowViewMaker, modal presentation, dismissal sequencing, navigation, `UIHostingController`, or backend-driven UI behavior.
+
+## Review Heuristics
+
+- Check whether behavior is driven by backend configuration before blaming local SwiftUI code.
+- Identify data ownership and view lifecycle boundaries.
+- Treat dismissal sequencing as high risk when delegate callbacks, `onDisappear`, or upstream state changes are involved.
+- Treat UIKit bridge removal as rollout-sensitive, not just cleanup.
+- Separate SwiftUI best practice from Fidelity-safe migration strategy.
+
+## Fidelity-Specific Checks
+
+- Does the change preserve UIKit/SwiftUI parity?
+- Does it require a feature flag?
+- Does it need validation in Fid4 or only XFlowSDK?
+- Could XFlowViewMaker or FTFrameworks block consumer visibility?
+- Is the issue external behavior, existing behavior, or a regression?
+
+## Output Rules
+
+- Provide a clear recommendation.
+- Include risks and validation path.
+- Avoid recommending a pure SwiftUI approach without noting rollout and consumer validation impact.