Dev Productivity Session Memory

This cookbook provides a complete setup guide and prompt engineering blueprint to run sovseal as a local Model Context Protocol (MCP) server. By storing dev session memory locally, you gain persistent context without leaking proprietary codebase layouts or IP to public SaaS databases.

Latency & Privacy Edge

• 0 RTT Local Latency: Reading memories takes ~6.1 ms, compared to 300+ ms for cloud-hosted memory search.
• Absolute Privacy: Plaintext code fragments are stored locally in LanceDB. The cloud synchronization, if enabled, only transmits client-side encrypted (AES-256-GCM) blocks.

Setup Guide

1. Claude Desktop Integration

To register sovseal as a background memory server inside Claude Desktop:

1. Open the Claude Desktop configuration file:
   • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
   • Windows: %APPDATA%\Claude\claude_desktop_config.json
2. Add the sovseal configuration block:

{
  "mcpServers": {
    "sovseal": {
      "command": "npx",
      "args": ["-y", "@sovseal/mcp-server"]
    }
  }
}

3. Restart Claude Desktop. The store_memory and recall_memory tools will automatically appear in your active model's tool shelf.

2. Cursor IDE Integration

To register sovseal inside Cursor:

1. Navigate to Settings -> Features -> MCP.
2. Click + Add New MCP Server.
3. Fill out the form:
   • Name: sovseal
   • Type: stdio
   • Command: npx -y @sovseal/mcp-server
4. Save and verify that the status circle turns green.

Agent System Prompt Blueprint

To ensure your assistant leverages the memory server automatically without manual commands, prepend this instruction block to your system prompt or Cursor .cursorrules file:

# Persistent Memory Instruction
You are connected to a local `sovseal` memory server containing developer state across editor sessions.

## Execution Rules:
1. At the start of a conversation or task, immediately call `recall_memory` with queries like "active project layout", "recent decisions", or "workflow instructions".
2. When the user explains an architectural decision, completes a task, or sets a project preference, call `store_memory` with a concise fact (e.g., "The project uses Prisma, with schema at /db/schema.prisma").
3. Do not store temporary variables, syntax errors, or intermediate logs. Only store structural facts and decisions.

Operational Workflows

Memory Ingestion Example

When you explain a project constraint:

"We are migrating from Express to NestJS. The database uses PostgreSQL. Do not write any raw SQL; always use Prisma."

The agent will execute:

store_memory({
  "content": "Project migration state: Express to NestJS. DB: PostgreSQL. Constraint: Use Prisma for database access, no raw SQL."
})

This returns immediately on local commit (3.8 ms p50).

Session Recovery Example

On a fresh launch the next day, you ask:

"What are the rules for writing database queries here?"

The agent runs:

recall_memory({
  "query": "database query rules prisma"
})

The server returns the stored constraint via local vector lookup in ~6.1 ms, and the agent responds:

"Since you are migrating to NestJS and PostgreSQL, all database access must go through Prisma. Raw SQL queries are prohibited."

Managing and Pruning Context

Since local memory is stored in an on-disk LanceDB instance, you can inspect and clean up the database files directly:

• Database Path: ~/.sovseal/db/memories.lance
• Config Path: ~/.sovseal/config.json (stores your 256-bit AES key and project mappings; keep this file secure).

If you want to clear all memory for a clean slate, run:

rm -rf ~/.sovseal/db/memories.lance