Add daily logs and templates for Fidelity project

- Created daily log entries for April 13-16, 2026, capturing standup contexts, Mattermost syncs, and ongoing work items.
- Established a daily logs index for easy navigation of daily entries.
- Introduced templates for daily notes, decisions, meeting notes, people, systems, and work items to standardize documentation.
- Developed maps for AI workspace core, current work, Fidelity domain, and work items to enhance workspace navigation.
- Implemented base configurations for daily notes, decisions, people, systems, work items, and workstreams to streamline data management.
- Added a placeholder for attachments to facilitate file organization.

vault/03-context/ios/current-practices.md

@@ -0,0 +1,71 @@
+---
+type: guidance
+project: fidelity
+status: active
+updated: 2026-04-16
+tags:
+  - ios
+  - fidelity
+---
+# 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/`

vault/03-context/ios/index.md

@@ -0,0 +1,32 @@
+---
+type: guidance-index
+project: fidelity
+status: active
+updated: 2026-04-16
+tags:
+  - ios
+  - fidelity
+---
+# 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.

vault/03-context/ios/project-swift-guidance.md

@@ -0,0 +1,46 @@
+---
+type: guidance
+project: fidelity
+status: active
+updated: 2026-04-16
+tags:
+  - ios
+  - fidelity
+---
+# 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.