Add project-knowledge structure and templates

- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People."
- Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views.
- Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation.
- Updated scripts and prompts to reflect the new project-knowledge directory structure.
- Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps.
- Ensured all references in workflows and scripts point to the new project-knowledge paths.

agent-memory/integrations/technical-verification.md

@@ -0,0 +1,82 @@
+---
+type: agent-integration
+status: active
+updated: 2026-04-17
+tags:
+  - process
+  - engineering
+  - verification
+---
+# Technical Verification
+
+## Goal
+
+Ensure the agent gives senior-engineer technical advice instead of relying on stale model memory or generic best-practice claims.
+
+---
+
+## When To Verify
+
+Verify against primary/current documentation before making strong claims about:
+
+- dependency managers and package managers
+- CocoaPods, podspecs, private specs repos, trunk/CDN behavior, and migration strategy
+- Swift Package Manager behavior or migration strategy
+- Xcode, Swift, SwiftUI, Swift concurrency, Swift Testing, XCTest, or Apple framework behavior
+- CI/build systems and release propagation
+- security, authentication, networking, or migration practices
+- any claim that a pattern is a bad practice when project constraints may change the recommendation
+
+---
+
+## Source Priority
+
+Prefer:
+
+- official vendor documentation
+- language or framework documentation
+- official migration guides
+- source repository documentation when it is the canonical project source
+- current project memory when the question is project-specific
+
+Use blogs, forum posts, or third-party guides only as supporting context, not as the primary basis for a strong recommendation.
+
+---
+
+## Answering Pattern
+
+For technical recommendations:
+
+1. State what is known from workspace context.
+2. Verify current external behavior when the topic is version-sensitive or disputed.
+3. Separate general best practice from project-safe recommendation.
+4. Explain tradeoffs and validation path.
+5. If context is missing, ask the smallest material clarification question.
+
+---
+
+## Bad Practice Claims
+
+Avoid blanket claims such as:
+
+- "CocoaPods is bad practice"
+- "SPM is always better"
+- "This architecture is an anti-pattern"
+- "This should be removed"
+
+Instead explain:
+
+- what risk the pattern introduces
+- whether the risk is current or theoretical
+- whether the project has constraints that justify it
+- what a safer migration path would look like
+
+---
+
+## Agentic Self-Improvement
+
+The agent should be aware it is maintaining a workspace, not just answering chat prompts.
+
+If a conversation reveals a recurring gap in technical quality, source verification, command behavior, or memory routing, the agent should propose or apply a workspace improvement in the correct file.
+
+Do not store tool failures or one-off uncertainty as project facts. Store reusable rules and source anchors when they improve future technical answers.