feat: replace megamemory with markdown-based memory system

Remove the megamemory MCP knowledge graph and replace with plain
markdown files in .memory/ for tracking plans, research, knowledge,
and implementation state. This enables collaboration across people
and agentic coding tools (Claude Code, Copilot, Cursor, etc.).

Changes:
- Remove megamemory MCP from opencode.jsonc
- Delete tool/megamemory.ts and .megamemory/ database
- Rewrite all 25 config files to use .memory/ markdown files
- Add cross-tool instruction file awareness (AGENTS.md, CLAUDE.md,
  copilot-instructions.md, .cursorrules)
- Update save-memory, bootstrap-memory, status commands for md workflow
- Update all agent files, skills, and commands consistently

.config/opencode/commands/bootstrap-memory.md

@@ -1,47 +1,86 @@
-# Bootstrap Project Knowledge Graph
+# Bootstrap Project Memory Files
 
-RUN { git ls-files; git ls-files --others --exclude-standard; } 2>/dev/null | sort -u | xargs wc -l 2>/dev/null | sort -rn | head -150
+RUN { git ls-files; git ls-files --others --exclude-standard; } 2>/dev/null | sort -u
 READ README.md
 
-You are bootstrapping the megamemory knowledge graph for this project.
+You are bootstrapping `.memory/` files for this project.
 
-Your job is to understand the codebase and record its core concepts, architecture,
-and patterns as knowledge graph nodes. The file listing above is sorted by line
-count — the biggest files are where the core logic lives.
+Your job is to inspect the codebase and create an initial memory baseline in plain
+markdown files. Capture architecture, core modules, conventions, and key decisions
+so future sessions can resume quickly.
 
-## Step 1: Check existing graph
+## Step 1: Create `.memory/` structure
 
-Call `megamemory:list_roots` to see what's already recorded. If the graph has
-good coverage, report what's there and ask if I want to fill in specific areas.
+Create (if missing):
 
-## Step 2: Identify major modules
+```
+.memory/
+  knowledge.md
+  decisions.md
+  plans/
+  research/
+```
 
-From the file listing and README, identify the top-level systems in this project.
-Think in terms of:
-- What does this project DO? (features)
-- What are the distinct subsystems? (modules)
-- How is it structured? (patterns, decisions)
+`.memory/` is tracked in git.
 
-## Step 3: Read and create root concepts
+## Step 2: Inspect project structure
 
-For each major module, read its key files to understand what it does. Then call
-`megamemory:create_concept` with a specific, detailed summary. Include parameter
-names, defaults, file paths, and behavior details — not vague descriptions.
+Run `git ls-files` to understand the project layout, then read `README.md` and
+the highest-signal files for architecture and conventions.
 
-## Step 4: Create children for important sub-components
+Identify:
+- What the project does (primary capabilities)
+- Core modules/subsystems and responsibilities
+- Key patterns/conventions (naming, layering, testing, config)
 
-For substantial modules, create child concepts for key pieces. Stay max 2 levels
-deep. Focus on things a developer would need to know when working in that area.
+## Step 3: Write initial `knowledge.md`
 
-## Step 5: Link related concepts
+Populate `.memory/knowledge.md` with:
+- Project purpose and scope
+- Architecture overview
+- Key modules with file paths
+- Important implementation patterns/conventions
 
-Connect concepts that interact across boundaries using `megamemory:link`.
-Focus on meaningful relationships: depends_on, calls, connects_to, implements,
-configured_by.
+Use markdown sections with max 2 heading levels.
+
+## Step 4: Seed `decisions.md`
+
+Populate `.memory/decisions.md` with any clear, durable decisions found in docs
+or code patterns (for example: stack choices, testing strategy, architectural
+constraints). Include rationale when known.
+
+## Step 5: Initialize plans/research folders
+
+- If active in-progress work is discoverable, create `.memory/plans/<feature>.md`
+  with scope, tasks, and acceptance criteria.
+- If research artifacts are discovered, create `.memory/research/<topic>.md`
+  with findings and references.
+
+## Step 6: Create/update cross-tool instruction files
+
+After `.memory/knowledge.md` is populated, use it as the source of truth to
+create or update all cross-tool instruction files:
+
+- `AGENTS.md`
+- `CLAUDE.md`
+- `.github/copilot-instructions.md`
+- `.cursorrules`
+
+Each file should include the same core project guidance:
+- project overview and purpose
+- tech stack
+- architecture summary
+- coding conventions/patterns
+- build/test/lint commands
+- project structure overview
+
+If any of these files already exist, preserve existing project-specific content
+and merge in new knowledge instead of overwriting wholesale.
 
 ## Guidelines
 
-- Be specific. "Handles auth" is useless. "JWT auth with RS256, tokens from
-  /auth/login, validated in middleware, refresh tokens in Redis with 7d TTL" is useful.
-- Focus on the top 10-15 most important concepts first. The graph grows over time.
-- Don't document trivial things. If it's obvious from the file name, skip it.
+- Be specific with file paths, APIs, parameters, and behavioral details.
+- Keep sections concise and scannable.
+- Prefer durable knowledge over transient status notes.
+- Add markdown cross-references between related entries (for example,
+  knowledge entries linking to decisions).

.config/opencode/commands/docs.md

@@ -11,7 +11,7 @@ $ARGUMENTS
 
 Requirements:
 
-- Query megamemory first for prior workflow and documentation decisions.
+- Read relevant `.memory/*.md` files first for prior workflow and documentation decisions.
 - If scope is ambiguous, ask one focused clarification question using the question tool.
 - Update required documentation surfaces:
   - `README`

.config/opencode/commands/init.md

@@ -1,5 +1,5 @@
 ---
-description: Initialize or update a project with scaffold, docs, and knowledge graph — adapts to both new and existing projects.
+description: Initialize or update a project with scaffold, docs, and .memory files — adapts to both new and existing projects.
 ---
 
 You are initializing or updating a project. Follow these steps in order.
@@ -46,8 +46,12 @@ Delegate to the `coder` subagent with explicit mode (`new_project` or `existing_
 - Required scaffold targets:
   - `README.md` — title, purpose, tech stack, quick-start, project structure overview
   - `AGENTS.md` — project-specific workflow notes (code style, test commands, linting, build commands, commit conventions); do **not** duplicate global `AGENTS.md` policies — only add project-specific details
+  - `CLAUDE.md` — project instructions for Claude Code (same core content as `AGENTS.md`, adapted for Claude)
+  - `.github/copilot-instructions.md` — project instructions for GitHub Copilot
+  - `.cursorrules` — project instructions for Cursor
   - `docs/architecture.md` — stub with title + purpose
-  - `.gitignore` — must include `.megamemory/` entry; add stack-appropriate ignores (e.g., `node_modules/`, `__pycache__/`, `target/`)
+  - `.gitignore` — add stack-appropriate ignores (e.g., `node_modules/`, `__pycache__/`, `target/`)
+  - `.memory/` — create and/or update `knowledge.md`, `decisions.md`, `plans/`, `research/`
   - other stack-specific scaffold files if clearly implied (e.g., `package.json`, `pyproject.toml`)
 - If `new_project`:
   - create all required scaffold files/directories
@@ -55,7 +59,9 @@ Delegate to the `coder` subagent with explicit mode (`new_project` or `existing_
   - create or fill in only missing pieces
   - **do not overwrite existing files**
   - explicitly instruct coder to check existence before creating each target
-  - if `.gitignore` exists, instruct coder to append `.megamemory/` if not already present
+  - if any cross-tool instruction files are missing (`AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`, `.cursorrules`), create them
+  - if they exist, verify they are in sync with `AGENTS.md` for core project knowledge (purpose, stack, conventions, commands, structure)
+  - if `.memory/` is missing, create the full `.memory/` directory structure
   - examples:
     - if `README.md` exists and `AGENTS.md` is missing, create only `AGENTS.md`
     - if `docs/` is missing, create it and add `docs/architecture.md`
@@ -66,21 +72,21 @@ Always delegate to the `librarian` subagent, for both new and existing projects.
 
 - Ensure `README.md` is accurate and complete for the current project state.
 - Ensure `AGENTS.md` captures project-specific workflow decisions from Step 2.
+- Verify cross-tool instruction files are consistent with each other (`AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`, `.cursorrules`).
 - Ensure stubs are explicitly marked for later completion.
 - Keep edits additive and non-destructive for existing projects.
 
-## Step 5 — Initialize or update knowledge graph (Lead)
+## Step 5 — Initialize or update `.memory` project overview (Lead)
 
-Always update megamemory for this project.
+Always create or update `.memory/knowledge.md` for this project.
 
-- First call `megamemory:understand` to check whether a project root concept already exists.
-- If an appropriate concept exists, call `megamemory:update_concept`.
-- If none exists, call `megamemory:create_concept` with:
-  - Kind: `module`
-  - Name: `<project name>`
-  - Summary: purpose, stack, key files, and notable init/update decisions
-  - File refs: include whichever exist among `README.md`, `AGENTS.md`, `docs/architecture.md`
-- Create links (`megamemory:link`) from this concept to related existing concepts when applicable. If no related concepts exist yet (brand new knowledge graph), skip linking.
+- Read existing `.memory/knowledge.md` (if present) to avoid duplicate sections.
+- Create or update a project overview section with:
+  - Project name
+  - Purpose and stack
+  - Key files (`README.md`, `AGENTS.md`, `docs/architecture.md` when present)
+  - Notable init/update decisions
+- Add markdown cross-references to related sections in `.memory/decisions.md` when applicable.
 
 ## Step 6 — Git handling (delegate to `coder`)
 
@@ -88,12 +94,11 @@ Delegate git operations to `coder` based on discovered state.
 
 - If `.git/` already exists:
   - skip `git init`
-  - ensure `.megamemory/` is in `.gitignore` (if not already handled in Step 3)
   - stage only newly created or modified files from this init/update flow
   - create a commit
 - If `.git/` does not exist:
   - use Step 2 answer to decide whether to run `git init`
-  - if initialized, ensure `.megamemory/` is in `.gitignore`, then stage only newly created or modified files and create a commit
+  - if initialized, stage only newly created or modified files and create a commit
 - Commit message should be concise and conventional, e.g.:
   - `chore: initialize project scaffold` (new project)
   - `chore: add missing project scaffolding` (existing project)

.config/opencode/commands/plan.md

@@ -6,7 +6,7 @@ You are the lead agent. The user has invoked `/plan` to begin structured plannin
 
 ## Steps
 
-1. **CLARIFY**: Ask the user clarifying questions about the task using the `question` tool. Gather: goals, constraints, affected areas, success criteria. Record in megamemory.
+1. **CLARIFY**: Ask the user clarifying questions about the task using the `question` tool. Gather: goals, constraints, affected areas, success criteria. Record in the relevant plan file.
 
 2. **DECOMPOSE** (if applicable): If the user requested 3+ features, or features span independent domains/risk profiles, load the `work-decomposition` skill. Follow its decomposition procedure to:
    - Identify distinct features and assess independence
@@ -16,11 +16,11 @@ You are the lead agent. The user has invoked `/plan` to begin structured plannin
    - Identify human checkpoint triggers (security, architecture, vision-dependent features)
    - Present the decomposition to the user and wait for approval before proceeding
 
-3. **DISCOVER**: Delegate to `explorer` to map relevant parts of the codebase. Delegate to `researcher` for any technical unknowns. Record findings in megamemory.
+3. **DISCOVER**: Delegate to `explorer` to map relevant parts of the codebase. Delegate to `researcher` for any technical unknowns. Record findings in the relevant `.memory/` files.
 
-4. **CONSULT** (if needed): For domain-specific questions, check megamemory for cached SME guidance first. If not cached, delegate to `sme`.
+4. **CONSULT** (if needed): For domain-specific questions, check `.memory/decisions.md` for cached SME guidance first. If not cached, delegate to `sme`.
 
-5. **PLAN**: Draft a phased task list per workstream. Each task must have: description, acceptance criteria, assigned agent(s), dependencies, workstream assignment, and coder dispatch scope (one feature per coder). Store plan as a megamemory `feature` concept.
+5. **PLAN**: Draft a phased task list per workstream. Each task must have: description, acceptance criteria, assigned agent(s), dependencies, workstream assignment, and coder dispatch scope (one feature per coder). Store the plan in `.memory/plans/<feature>.md`.
 
 6. **CRITIC-GATE**: Delegate plan to `critic`. If APPROVED → present plan to user and await go-ahead. If REPHRASE → revise and re-gate. If RESOLVE → **stop**, resolve every blocker, then re-gate. Do not proceed to EXECUTE with unresolved blockers.
 

.config/opencode/commands/research.md

@@ -11,7 +11,7 @@ $ARGUMENTS
 
 Requirements:
 
-- Query megamemory first for existing related concepts.
+- Read relevant `.memory/*.md` files first for existing related research and decisions.
 - If scope is ambiguous, ask one focused clarification question using the question tool.
 - Provide findings, tradeoffs, and recommended approach.
-- Record durable insights in megamemory with create/update/link operations.
+- Record durable insights in the relevant `.memory/` files with markdown sections and cross-references.

.config/opencode/commands/review.md

@@ -11,7 +11,7 @@ $ARGUMENTS
 
 Requirements:
 
-- Query megamemory first for project conventions and prior decisions.
+- Read relevant `.memory/*.md` files first for project conventions and prior decisions.
 - If review scope is ambiguous, ask one focused clarification question using the question tool.
 - Categorize findings: critical, warning, suggestion.
 - Include concrete file references and rationale.

.config/opencode/commands/save-memory.md

@@ -1,83 +1,79 @@
 # Save Session Knowledge
 
-You are saving what you learned this session into the megamemory knowledge graph.
+You are saving what you learned this session into the project's `.memory/` directory.
 This is YOUR memory — record anything valuable for future sessions: what you
 understood about the project, what you built, decisions that were made, patterns
 you noticed, or intent the user shared.
 
-## Step 1: Load existing graph
+## Step 1: Load existing memory files
 
-Call `megamemory:list_roots` to see what's already recorded. Understanding the
-current state prevents duplicates and helps you decide what to update vs create.
+Read the `.memory/` directory and existing files to see what's already recorded.
+At minimum, check:
+- `.memory/knowledge.md`
+- `.memory/decisions.md`
+- `.memory/plans/*.md`
+- `.memory/research/*.md`
+
+Understanding current state prevents duplication and helps you decide what to update.
 
 ## Step 2: Reflect on this session
 
 Think about what happened this session. Consider:
 - What did you learn about the project's purpose or intent?
 - What features, modules, or components did you build or change?
-- What design decisions were made and why?
+- What design or architectural decisions were made and why?
 - What patterns or conventions did you discover?
-- What architectural understanding do you have now that isn't in the graph?
+- What research findings are worth keeping?
 - Did anything get removed, replaced, or deprecated?
 
-## Step 3: Search for overlap
+## Step 3: Map learnings to memory files
 
-Before creating anything new, call `megamemory:understand` with queries based on
-what you worked on this session. For each area you touched, search to see if
-concepts already exist that should be updated rather than duplicated.
+For each thing worth remembering, update the right file:
 
-For example, if you worked on authentication, call:
-  megamemory:understand — query="authentication"
+- **Project architecture/patterns/conventions** → `.memory/knowledge.md`
+- **Decisions and rationale** → `.memory/decisions.md`
+- **Ongoing feature plans and acceptance criteria** → `.memory/plans/<feature>.md`
+- **Deep research findings** → `.memory/research/<topic>.md`
 
-Do this for each distinct area. Existing concepts that are stale or incomplete
-should be updated — don't create a new node when an update will do.
+Prefer updating existing sections over creating duplicates.
 
-## Step 4: Write to the knowledge graph
+## Step 4: Write updates using markdown sections
 
-For each thing worth remembering:
+Use standard markdown headings (`##`) and concise subsections when needed.
+Do not use concept IDs or graph-style metadata.
 
-**New understanding** → `megamemory:create_concept`
-  - name: human-readable name
-  - kind: use `decision` for intent/rationale, `feature` for capabilities,
-    `module` for subsystems, `pattern` for conventions, `config` for setup,
-    `component` for distinct pieces of a system
-  - summary: be specific — include parameter names, defaults, file paths,
-    behavior details, and the WHY behind things
-  - why: the rationale — this is often the most valuable part
-  - file_refs: relevant files if applicable
-  - edges: connect to existing concepts where relationships exist
-    [{to: "concept-id", relation: "depends_on|implements|calls|connects_to|configured_by", description: "why"}]
-  - created_by_task: brief description of what you were doing this session
+When writing, be specific:
+- include parameter names, defaults, file paths, behavior details
+- include rationale (`why`) for decisions
+- include cross-references to related memory entries
 
-**Updated understanding** → `megamemory:update_concept`
-  - id: the concept slug
-  - changes: {summary?, why?, file_refs?, name?, kind?}
-  If an existing concept is now stale or incomplete based on what you learned,
-  update it. This is often more valuable than creating new nodes.
+Example cross-reference:
+- `See [Decision: Auth token TTL](../decisions.md#decision-auth-token-ttl)`
 
-**New connections** → `megamemory:link`
-  - from, to: concept IDs
-  - relation: depends_on | implements | calls | connects_to | configured_by
-  - description: why this relationship exists
-  If you discovered how existing concepts relate to each other.
+## Step 5: Verify and report
 
-**Removed/replaced things** → `megamemory:remove_concept`
-  - id: concept to remove
-  - reason: why it was removed
-  If something in the graph is no longer true.
+Re-read updated `.memory/` files to confirm they reflect current understanding.
+Report what was added/updated and where.
 
-## Step 5: Verify
+## Step 6: Sync cross-tool instruction files when project knowledge changed
 
-Call `megamemory:list_roots` again. Confirm the graph reflects your current
-understanding. Report what you saved.
+Check whether `.memory/knowledge.md` was **materially** updated in this save.
+Material updates include project-level changes such as architecture, conventions,
+or build/test/lint commands.
+
+- If there was a material `knowledge.md` update:
+  - Read current instruction files: `AGENTS.md`, `CLAUDE.md`,
+    `.github/copilot-instructions.md`, `.cursorrules`
+  - Update them to reflect the new core project knowledge while preserving
+    tool-specific formatting and project-specific content.
+- If updates were only plans/research/tracking details (no project-level
+  knowledge change), do **not** update instruction files.
 
 ## Guidelines
 
 - Record what a future you (with no memory of this session) would need to know.
-- Intent and rationale ("why") are more valuable than implementation details.
-- Update existing concepts before creating new ones — keep the graph lean.
-- Don't record trivial things. If it's obvious from the code, skip it.
-- Max 2 levels of nesting. Flat is better than deep.
-- Connect concepts — isolated nodes are less useful than a connected graph.
-- Be specific. "Handles auth" is useless. "JWT auth with RS256, validated in
-  middleware at src/middleware/auth.ts, refresh tokens in Redis with 7d TTL" is useful.
+- Outcomes and rationale are more valuable than ceremony.
+- Don’t log process-only updates like "started phase X".
+- Keep hierarchy shallow (max 2 heading levels preferred).
+- Be specific. "Handles auth" is weak. "JWT auth with RS256, validated in
+  `src/middleware/auth.ts`, refresh tokens in Redis with 7d TTL" is useful.

.config/opencode/commands/sme.md

@@ -1,18 +1,18 @@
 ---
-description: Invoke the SME (Subject Matter Expert) agent for deep domain consultation — guidance is cached in megamemory
+description: Invoke the SME (Subject Matter Expert) agent for deep domain consultation — guidance is cached in .memory/decisions.md
 ---
 
 You are the lead agent. The user has invoked `/sme` to consult a domain expert.
 
 ## Steps
 
-1. Check megamemory for existing SME guidance on the requested domain (`megamemory:understand` with the domain as query). If found, return the cached guidance immediately with its concept ID.
+1. Check `.memory/decisions.md` for existing SME guidance on the requested domain. If found, return the cached guidance immediately with its section heading.
 
 2. If not cached, delegate to the `sme` agent with:
    - The user's specific question
    - Relevant context (project stack, constraints, current approach)
    - Any relevant file paths or code snippets
 
-3. Once SME responds, the guidance will be cached in megamemory automatically. Present the guidance to the user.
+3. Once SME responds, record or update the guidance in `.memory/decisions.md`. Present the guidance to the user.
 
-4. Link the SME guidance concept to any active plan concept in megamemory.
+4. Add cross-references between the SME guidance section and any active plan file in `.memory/plans/`.

.config/opencode/commands/status.md

@@ -1,14 +1,16 @@
 ---
-description: Show persistent cross-session work status from megamemory
+description: Show persistent cross-session work status from .memory files
 agent: lead
 ---
 
-Load persistent project status from megamemory and provide a resume-oriented status report.
+Load persistent project status from `.memory/` and provide a resume-oriented status report.
 
 Requirements:
 
-- Call `megamemory:list_roots` to load top-level concepts.
-- Call `megamemory:understand` for in-progress work, open decisions, and pending next steps.
+- Read the `.memory/` directory listing first.
+- Read `.memory/plans/*.md` for in-progress and recently completed work.
+- Read `.memory/decisions.md` for pending or unresolved decisions.
+- If present, use `.memory/knowledge.md` for additional context.
 - Summarize:
   1. What is currently in progress
   2. What was completed recently

.config/opencode/commands/test.md

@@ -11,7 +11,7 @@ $ARGUMENTS
 
 Requirements:
 
-- Query megamemory first for testing context.
+- Read relevant `.memory/*.md` files first for testing context.
 - If scope is ambiguous, ask one focused clarification question using the question tool.
 - Prefer `uv run pytest` command patterns for Python projects.
 - Report commands run, pass/fail results, and likely root causes for failures.