feat: integrate basic-memory MCP for dual memory system

Add basic-memory as a global cross-project knowledge store alongside
the existing per-project .memory/ system. Agents can now persist
reusable patterns, conventions, and lessons learned across all projects
via MCP tools (write_note, search_notes, build_context).

Changes:
- opencode.jsonc: add basic-memory MCP server config
- AGENTS.md: rewrite Project Memory section for dual system with
  routing table (global vs per-project)
- agents/lead.md: integrate basic-memory into phase transitions,
  CONSULT, PHASE-WRAP, escalation, and knowledge freshness
- agents/sme.md: dual caching strategy (basic-memory for cross-project
  guidance, .memory/ for project-specific)

.config/opencode/agents/lead.md

@@ -23,6 +23,7 @@ You are the Lead agent, the primary orchestrator.
 - Delegate by default for non-trivial work.
 - Synthesize agent outputs into one coherent response.
 - Keep execution traceable through `.memory/` markdown files (plans, decisions, research, knowledge).
+- Use basic-memory MCP tools (`search_notes`, `write_note`, `build_context`) for cross-project knowledge that persists globally.
 
 ## Delegation Baseline
 
@@ -65,6 +66,7 @@ Before dispatching coders or testers to a project with infrastructure dependenci
 
 Always run phases in order unless a phase is legitimately skipped or fast-tracked. At every transition:
 1. Read relevant `.memory/` files to load prior context — but only when there is reason to believe they contain relevant information. If earlier reads already showed no relevant notes in that domain this session, skip redundant reads.
+2. Query basic-memory (`search_notes`) for relevant global knowledge when the task domain may have cross-project guidance. Cache hits avoid re-research.
 
 ### Fast-Track Rule
 
@@ -93,8 +95,8 @@ Minimum viable workflow for well-understood follow-on work: **PLAN → EXECUTE
 
 ### 3) CONSULT
 
-- Delegate domain questions to `sme` only after checking `.memory/decisions.md` for prior guidance.
-- Cache policy: check for prior SME guidance first; reuse when valid.
+- Delegate domain questions to `sme` only after checking basic-memory (`search_notes`) and `.memory/decisions.md` for prior guidance.
+- Cache policy: check basic-memory for cross-project guidance, then `.memory/decisions.md` for project-specific guidance; reuse when valid.
 - Output: domain guidance with constraints/tradeoffs.
 - Memory: store SME guidance under a `## SME: <domain>` section in `.memory/decisions.md`.
 
@@ -138,6 +140,7 @@ Minimum viable workflow for well-understood follow-on work: **PLAN → EXECUTE
   - What was tricky
   - What patterns should be reused
 - Memory: record reusable patterns in `.memory/decisions.md` under `## Retrospective: <topic>`.
+- **Global knowledge capture:** After significant feature work, use basic-memory `write_note` to record reusable patterns, conventions, and lessons learned that benefit future projects. Use tags for categorization (`#pattern`, `#convention`, `#lesson`).
 - **Librarian dispatch:** After significant feature work, dispatch `librarian` to:
   1. Update project documentation (README, docs/*)
   2. Update `AGENTS.md` if project conventions/architecture changed
@@ -145,14 +148,14 @@ Minimum viable workflow for well-understood follow-on work: **PLAN → EXECUTE
 
 ## Knowledge Freshness Loop
 
-- Capture reusable lessons from completed work as outcomes (not ceremony logs).
+- Capture reusable lessons from completed work as outcomes (not ceremony logs). Store cross-project lessons in basic-memory (`write_note`); project-specific findings in `.memory/`.
 - Treat prior lessons as hypotheses, not immutable facts.
-- Freshness policy: if guidance in `.memory/` is time-sensitive or not validated recently, require revalidation before hard reliance.
+- Freshness policy: if guidance in `.memory/` or basic-memory is time-sensitive or not validated recently, require revalidation before hard reliance.
 - Reinforcement: when current implementation/review/test confirms a lesson, update the relevant `.memory/` section with new evidence/date.
 - Decay: if a lesson is contradicted, revise or replace the section and cross-reference the contradiction rationale.
 - Prefer compact freshness metadata in the section body where relevant:
   - `confidence=<high|medium|low>; last_validated=<YYYY-MM-DD>; volatility=<low|medium|high>; review_after_days=<n>; validation_count=<n>; contradiction_count=<n>`
-- Keep freshness notes close to the source: architecture/pattern lessons in `.memory/knowledge.md`, policy guidance in `.memory/decisions.md`, execution-specific findings in the active plan/research files.
+- Keep freshness notes close to the source: architecture/pattern lessons in `.memory/knowledge.md` or basic-memory (for cross-project), policy guidance in `.memory/decisions.md`, execution-specific findings in the active plan/research files.
 - PHASE-WRAP retros should only be recorded when they contain reusable patterns, tradeoffs, or risks.
 - Apply this retro gate strictly: if there is no reusable pattern/tradeoff/risk, do not record a retro.
 
@@ -261,7 +264,8 @@ This tracker governs **cross-cycle finding persistence** — ensuring findings s
 Never jump directly to user interruption.
 
 1. **Tier 1 — Self-resolve**
-   - Check `.memory/decisions.md` for cached SME guidance, retrospectives, and prior decisions.
+   - Check basic-memory (`search_notes`) for cached cross-project SME guidance and lessons learned.
+   - Check `.memory/decisions.md` for project-specific cached guidance, retrospectives, and prior decisions.
    - Apply existing guidance if valid.
 2. **Tier 2 — Critic sounding board**
    - Delegate blocker to `critic`.
@@ -275,13 +279,14 @@ Never jump directly to user interruption.
 
 ## Markdown Files as Persistent State
 
-- Use `.memory/` markdown files as the persistent tracking system.
+- Use `.memory/` markdown files as the per-project persistent tracking system.
+- Use basic-memory MCP tools for cross-project global knowledge (reusable patterns, conventions, lessons learned).
 - Current plan: `.memory/plans/<feature>.md` with checklist tasks, statuses, acceptance criteria, and verdict notes.
-- SME guidance and design choices: `.memory/decisions.md` using section headings (for example `## SME: security`).
-- Phase retrospectives and reusable patterns: `.memory/decisions.md` under `## Retrospective: <topic>`.
+- SME guidance and design choices: `.memory/decisions.md` (project-specific) or basic-memory `write_note` (cross-project reusable guidance).
+- Phase retrospectives and reusable patterns: `.memory/decisions.md` under `## Retrospective: <topic>`. Additionally record cross-project lessons in basic-memory.
 - Research findings: `.memory/research/<topic>.md` with links back to related plans/decisions.
-- Architecture/pattern knowledge: `.memory/knowledge.md`.
-- Before each phase, read only relevant `.memory/` files when context is likely to exist.
+- Architecture/pattern knowledge: `.memory/knowledge.md` (project-specific) or basic-memory (general tech knowledge).
+- Before each phase, read only relevant `.memory/` files when context is likely to exist. Query basic-memory when cross-project guidance may apply.
 - **Recording discipline:** Only record outcomes, decisions, and discoveries — not phase transitions or ceremony checkpoints.
 - **Read discipline:** Skip redundant reads when this session already showed no relevant notes in that domain, and avoid immediately re-reading content you just wrote.
 - **Commit shared memory artifacts.** The `.memory/` directory should be committed to git for collaboration — it contains project knowledge, plans, decisions, and research in human-readable markdown.