Memora

El servidor se ejecuta automáticamente cuando está configurado en Claude Code. Invocación manual:

# Default (stdio mode for MCP)
memora-server

# With graph visualization server
memora-server --graph-port 8765

# HTTP transport (alternative to stdio)
memora-server --transport streamable-http --host 127.0.0.1 --port 8080

Claude Code

Agrega a .mcp.json en la raíz de tu proyecto:

BD local:

{
  "mcpServers": {
    "memora": {
      "command": "memora-server",
      "args": [],
      "env": {
        "MEMORA_DB_PATH": "~/.local/share/memora/memories.db",
        "MEMORA_ALLOW_ANY_TAG": "1",
        "MEMORA_GRAPH_PORT": "8765"
      }
    }
  }
}

BD en la nube (Cloudflare D1) - Recomendado:

{
  "mcpServers": {
    "memora": {
      "command": "memora-server",
      "args": ["--no-graph"],
      "env": {
        "MEMORA_STORAGE_URI": "d1://<account-id>/<database-id>",
        "CLOUDFLARE_API_TOKEN": "<your-api-token>",
        "MEMORA_ALLOW_ANY_TAG": "1"
      }
    }
  }
}

Con D1, usa --no-graph para deshabilitar el servidor de visualización local. En su lugar, usa el grafo alojado en tu URL de Cloudflare Pages (ver Grafo en la nube).

BD en la nube (S3/R2) - Modo sincronización:

{
  "mcpServers": {
    "memora": {
      "command": "memora-server",
      "args": [],
      "env": {
        "AWS_PROFILE": "memora",
        "AWS_ENDPOINT_URL": "https://<account-id>.r2.cloudflarestorage.com",
        "MEMORA_STORAGE_URI": "s3://memories/memories.db",
        "MEMORA_CLOUD_ENCRYPT": "true",
        "MEMORA_ALLOW_ANY_TAG": "1",
        "MEMORA_GRAPH_PORT": "8765"
      }
    }
  }
}

CLI de Codex

Agrega a ~/.codex/config.toml:

[mcp_servers.memora]
  command = "memora-server"  # or full path: /path/to/bin/memora-server
  args = ["--no-graph"]
  env = {
    AWS_PROFILE = "memora",
    AWS_ENDPOINT_URL = "https://<account-id>.r2.cloudflarestorage.com",
    MEMORA_STORAGE_URI = "s3://memories/memories.db",
    MEMORA_CLOUD_ENCRYPT = "true",
    MEMORA_ALLOW_ANY_TAG = "1",
  }

Las 43 herramientas MCP se registran incondicionalmente, por lo que cada sesión de agente se inyecta con el esquema completo de herramientas de ~12,700 tokens incluso cuando la mayoría de las herramientas nunca se llaman. MEMORA_TOOL_PROFILE expone un subconjunto por implementación para que una herramienta restringida esté genuinamente ausente: falta en tools/list Y no es despachable (call_tool devuelve unknown-tool, no una ejecución oculta). El perfil se aplica y se atestigua al inicio; el perfil activo y el recuento de herramientas expuestas se registran en stderr.

• Sin definir / vacío = full. Ningún despliegue existente cambia su comportamiento.
• Un valor desconocido aborta el inicio con un mensaje que nombra los valores válidos. Nunca retrocede silenciosamente a full — un error tipográfico no debe reexponer herramientas de mantenimiento destructivas (memory_rebuild_embeddings, memory_delete_batch) a cada worker. Cierre en fallo.
• memory_list está en leader pero no en agent. Fue excluido de ambos mientras costaba 163-174s en un almacén D1 frente a los 0.22s de memory_list_compact; #973 corrigió eso (ahora ~1.1s). Se mantiene fuera de agent porque la superficie de lectura de un worker es deliberadamente estrecha, no por velocidad.
• El límite líder/agente es dato en memora/tool_profile.py (dos frozensets). Editarlo es una línea, no un barrido de 43 decoradores.
• La poda elimina del dict privado _tool_manager._tools de FastMCP, por lo que memora fija mcp>=1.27,<1.28 (el minor auditado) y ejecuta una atestación de inicio a través de los manejadores de solicitudes MCP registrados de bajo nivel (_mcp_server.request_handlers[ListToolsRequest] / [CallToolRequest] — el callable de despacho real que usan las solicitudes de clientes, no los helpers de Python FastMCP.list_tools / call_tool) que se niega a iniciar si el SDK instalado enruta el listado/despacho a otro lugar (deriva de implementación privada). El pin es la guardia estática; la atestación es el respaldo en tiempo de ejecución. Subir el límite superior requiere volver a ejecutar tests/test_tool_profile.py.
• Bajo despliegue en contenedor el perfil es por contenedor mientras que los roles son por agente. Un contenedor que sirve al líder de un workspace y a sus workers necesita el superconjunto líder; agent eliminaría create_section/store_document/delete/digest/tags del líder.
• memora-server (es decir, memora.server.main()) es la única ruta de servicio perfilada soportada. Un embedder directo que importa memora.server.mcp y llama a mcp.run() él mismo omite el perfilado por completo (el mcp global aún contiene las 43 herramientas); los embedders que quieran perfilado deben llamar a apply_tool_profile ellos mismos o usar main().

# Leader deployment — exposes 19 tools
MEMORA_TOOL_PROFILE=leader memora-server

# Agent worker — exposes 12 tools
MEMORA_TOOL_PROFILE=agent memora-server

# Full (default) — all 43 tools, existing behaviour
memora-server

# Typo refuses to start:
# MEMORA_TOOL_PROFILE=agnt memora-server
# Error: unknown MEMORA_TOOL_PROFILE='agnt'; valid values: full, leader, agent

Un proceso memora puede servir a cada workspace. MEMORA_DATABASES es un registro JSON de {name: storage URI}; un cliente llega a su almacén en /mcp/<name>. El selector es la URL ya presente en .mcp.json, no un argumento de herramienta — un db opcional en cada herramienta son 43 oportunidades de olvidar uno, y cada fallo escribiría en el almacén de otra persona.

MEMORA_DATABASES sin definir es la forma antigua: un backend de MEMORA_STORAGE_URI / MEMORA_DB_PATH, un /mcp. Los despliegues stdio existentes no cambian.

Enrutamiento (solo streamable-http):

El enlace es fijo por sesión MCP, no por solicitud. Una sesión abierta en /mcp/alpha y reutilizada contra /mcp/beta aún resuelve a alpha. Un cliente no puede cambiar a medias de base de datos a mitad de conversación.

La configuración malformada se niega a iniciar (no retrocede a la base de datos heredada): JSON malo, un no-objeto, claves duplicadas, una URI vacía, un nombre que no sea un segmento de ruta de URL, o MEMORA_DEFAULT_DB faltante/desconocido cuando se listan más de una base de datos.

Par trabajado — ejecuta esto, conéctate a esto. Un listener streamable-HTTP, no una entrada MCP command (eso generaría un hijo stdio que nunca habla MCP en stdio). Las credenciales viven en el proceso del servidor.

MEMORA_DATABASES='{"memora":"d1://<account-id>/<memora-db-id>","ob1":"d1://<account-id>/<ob1-db-id>"}' \
MEMORA_DEFAULT_DB=memora \
CLOUDFLARE_API_TOKEN='<token>' \
MEMORA_VECTOR_SCAN_PAGE_SIZE=100 \
memora-server --transport streamable-http --host 127.0.0.1 --port 8000 --no-graph

{
  "mcpServers": {
    "memora": {
      "type": "http",
      "url": "http://127.0.0.1:8000/mcp/ob1"
    }
  }
}

Variante contenedor / proxy (el lanzador habitual de este host, no el comando anterior): scripts/memora-instance.sh up myinstance inicia el mismo servidor HTTP dentro de un contenedor y coloca scripts/memora_proxy.py en 127.0.0.1:<PORT> (8910 para la instancia memora). La URL del workspace es entonces http://127.0.0.1:8910/mcp/ob1. Ver Despliegue en contenedor.

Un registro puede mezclar d1://, s3:// y rutas locales; parse_backend_uri despacha según el esquema.

memory_stats informa la base de datos enlazada. Devuelve database (el nombre que esta sesión realmente resolvió) y database_source (path, registry_default o unconfigured). Un nombre válido pero incorrecto en .mcp.json es indetectable de otro modo: cada herramienta funciona, las lecturas tienen éxito y las escrituras aterrizan silenciosamente en el almacén de otro proyecto. Llama a memory_stats y verifica database contra el workspace que querías.

Salud de un proceso multi-base de datos: GET /health es vivacidad (sin I/O de base de datos — la única señal en la que un supervisor puede reiniciar). GET /health/db es una superficie de alerta (siempre HTTP 200; status es ok, degraded, unknown — sin instantánea aún, una actualización agotó el tiempo, o evidencia más antigua que la máxima obsolescencia — o error si el registro en sí es inutilizable). GET /health/db/{name} es la sonda específica del workspace (200 o 503). Retirar todo el proceso porque un almacén está degradado derriba también a los saludables.

Con MEMORA_DATABASES sin definir, un proceso aún enlaza una base de datos durante su vida útil (MEMORA_STORAGE_URI / MEMORA_DB_PATH). Esa es la forma original de un-almacén-un-contenedor-un-puerto.

Con MEMORA_DATABASES definido, un contenedor sirve a cada workspace y los clientes seleccionan un almacén por ruta de URL (/mcp/<name>). Ver Enrutamiento multi-base de datos. scripts/memora-instance.sh quiere uno de STORAGE_URI, VOLUME o MEMORA_DATABASES por archivo de instancia (load() requiere al menos uno). Si se definen más de uno, cmd_up usa MEMORA_DATABASES, luego STORAGE_URI, luego VOLUME.

Dockerfile construye una imagen sin credenciales; scripts/memora-instance.sh despliega una instancia desde instances/myinstance.env (u otro archivo nombrado). El CLI de tiempo de ejecución del script es $MEMORA_CONTAINER_BIN (predeterminado container — el CLI de Apple). Cada operación de contenedor que el script realiza respeta esa anulación (build, up, status, logs, down). El proceso memora_proxy.py generado fija container list, que también es por qué existe el proxy: ese runtime reasigna la IP del contenedor en cada inicio.

./scripts/memora-instance.sh build   myinstance   # build the image
./scripts/memora-instance.sh up      myinstance   # run the container
./scripts/memora-instance.sh proxy   myinstance   # render a LaunchAgent + print install commands
./scripts/memora-instance.sh status                # every instance at a glance

Luego apunta el workspace a ello — toda la configuración del cliente, sin secretos en ella. Una instancia de registro necesita el almacén en la ruta (/mcp/<name>); /mcp desnudo es el predeterminado del registro:

{"mcpServers": {"memora": {"type": "http", "url": "http://127.0.0.1:8910/mcp/ob1"}}}

Las credenciales nunca entran en la imagen, el archivo de instancia o la configuración HTTP del workspace. Se leen en tiempo de ejecución desde una configuración de credenciales separada ($CRED_SOURCE — en sí un .mcp.json que contiene solo el bloque mcpServers.memora.env) y se inyectan con -e. Si el archivo de instancia no define CRED_SOURCE, el script usa ~/.config/memora/credentials.mcp.json cuando ese archivo existe, de lo contrario ~/repos/agentic-box/.mcp.json. Pasa todas las variables que ese archivo define, no unas pocas seleccionadas a mano: un contenedor iniciado con solo las claves de incrustación pierde silenciosamente la consolidación LLM de memory_absorb en lugar de fallar ruidosamente.

Por qué existe el proxy — lee esto antes de decidir que no lo necesitas. El runtime predeterminado (container de Apple) reasigna la IP de un contenedor en cada inicio, no solo al recrear. Un cliente MCP lee su configuración una vez al inicio, por lo que una dirección movida no produce un error: produce un cuelgue silencioso permanente. scripts/memora_proxy.py mantiene un 127.0.0.1:<PORT> estable frente a la dirección móvil y re-resuelve por conexión.

Dos modos de fallo que distingue, que costaron una interrupción para aprender:

• La búsqueda se ejecutó y el contenedor no está listado → realmente se fue. Rechaza.
• La búsqueda no pudo ejecutarse (tiempo de espera bajo presión de memoria del host) → nada nuevo se sabe. Sigue sirviendo la última dirección buena conocida, limitada por MEMORA_PROXY_STALE_GRACE (300s). Confundir los dos llevó a cada workspace fuera de línea mientras los contenedores estaban respondiendo normalmente en direcciones sin cambios.

Define MEMORA_TOOL_PROFILE por instancia (ver Perfiles de herramientas). Nota que el perfil es por contenedor mientras que los roles son por agente: si un contenedor sirve al líder de un workspace y a sus workers, necesita el superconjunto líder.

Variable de script en tiempo de despliegue (no una variable de entorno de memora-server — nunca llega al proceso dentro del contenedor):

instances/README.md cubre los campos de configuración y launchd/README.md el proxy supervisado. REVERT.md documenta restaurar un workspace al servidor stdio directo.

Memora soporta tres backends de embeddings:

Los embeddings y el LLM se configuran por separado.

Una división parcial (solo un MEMORA_EMBEDDING_* definido) se rechaza para que el secreto de un proveedor nunca se envíe a otro host.

Trampa — OpenRouter no tiene endpoint de embeddings. El catálogo de OpenRouter es solo chat/multimodal (sin modelos de embedding). No apuntes la ruta de embeddings a OpenRouter vía OPENAI_BASE_URL (o una URL base MEMORA). Esa combinación da 404 en cada llamada de embed; sin MEMORA_EMBEDDING_STRICT=1 Memora retrocede a TF-IDF y sigue respondiendo, por lo que el almacén se llena con bolsas de palabras clave mientras parece saludable. OpenRouter sigue siendo adecuado solo para el LLM.

Ejemplo trabajado (LLM vía OpenRouter, embeddings vía Cloudflare Workers AI):

@cf/baai/bge-m3 es de 1024 dimensiones. El token necesita permiso de Workers AI. Forma del endpoint:

https://api.cloudflare.com/client/v4/accounts/<account_id>/ai/v1

{
  "env": {
    "MEMORA_EMBEDDING_MODEL": "openai",
    "OPENAI_API_KEY": "<openrouter-key>",
    "OPENAI_BASE_URL": "https://openrouter.ai/api/v1",
    "MEMORA_LLM_MODEL": "deepseek/deepseek-chat",
    "MEMORA_EMBEDDING_API_KEY": "<cloudflare-api-token-with-workers-ai>",
    "MEMORA_EMBEDDING_BASE_URL": "https://api.cloudflare.com/client/v4/accounts/<account_id>/ai/v1",
    "OPENAI_EMBEDDING_MODEL": "@cf/baai/bge-m3",
    "MEMORA_EMBEDDING_STRICT": "1"
  }
}

Lo que esta corrección hace (sin exagerar): los embeddings y el LLM pueden usar proveedores diferentes; una división parcial se rechaza; el modo estricto convierte la degradación silenciosa en un fallo duro y nombrado.

Automático: Los embeddings y las referencias cruzadas se calculan automáticamente cuando memory_create, memory_update o memory_create_batch.

Reconstrucción manual requerida cuando la huella del almacén cambia — no solo MEMORA_EMBEDDING_MODEL, sino también:

• Endpoint de embeddings (MEMORA_EMBEDDING_BASE_URL / host)
• ID real del modelo (OPENAI_EMBEDDING_MODEL, p. ej. cambiar a @cf/baai/bge-m3)
• Tipo o dimensiones del vector (bolsas TF-IDF de palabras clave vs densas de 1024-d; o 384 vs 1024)
• Almacén mixto (algunas filas densas, algunas dispersas) — la similitud coseno solo comparte claves, por lo que los tipos mixtos dan 0.0 de recuperación para filas antiguas

Forma de la huella: backend|model|repr (p. ej. openai|@cf/baai/bge-m3|dense:1024). El valor de metadatos heredado openai solo se trata como una discrepancia.

# After changing embedding model/endpoint, rebuild all embeddings
memory_rebuild_embeddings

# Then rebuild cross-references to update the knowledge graph
memory_rebuild_crossrefs

Un servidor HTTP integrado se inicia automáticamente con el servidor MCP, ofreciendo una visualización interactiva del grafo de conocimiento.

Panel de Detalles

Panel de Línea de Tiempo

Acceso local:

http://localhost:8765/graph

Acceso remoto vía SSH:

ssh -L 8765:localhost:8765 user@remote
# Then open http://localhost:8765/graph in your browser

Configuración:

{
  "env": {
    "MEMORA_GRAPH_PORT": "8765"
  }
}

Para deshabilitar: añade "--no-graph" a los argumentos en tu configuración de MCP.

Funciones de la Interfaz del Grafo

• Panel de Detalles - Ver contenido de memoria, metadatos, etiquetas y memorias relacionadas
• Panel de Línea de Tiempo - Explorar memorias cronológicamente, haz clic para resaltar en el grafo
• Panel de Historial - Registro de acciones de todas las operaciones con entradas consecutivas agrupadas y referencias de memoria clicables (las memorias eliminadas se muestran tachadas)
• Panel de Chat - Haz preguntas sobre tus memorias usando chat LLM impulsado por RAG con respuestas en streaming y referencias [Memory #ID] clicables
• Control Deslizante de Tiempo - Filtrar memorias por rango de fechas, arrastra para explorar el historial
• Actualizaciones en Tiempo Real - El grafo, la línea de tiempo y el historial se actualizan vía SSE cuando las memorias cambian
• Filtros - Menús desplegables de etiquetas/secciones, controles de zoom
• Renderizado Mermaid - Los bloques de código se renderizan como diagramas

Colores de Nodos

• 🟣 Etiquetas - Tonos púrpura por etiqueta
• 🔴 Problemas - Rojo (abierto), Naranja (en progreso), Verde (resuelto), Gris (no se corregirá)
• 🔵 TODOs - Azul (abierto), Naranja (en progreso), Verde (completado), Rojo (bloqueado)

El tamaño del nodo refleja el número de conexiones.

Cuando usas Cloudflare D1 como tu base de datos, la visualización del grafo se aloja en Cloudflare Pages - no se necesita servidor local.

Beneficios:

• Acceso desde cualquier lugar (sin túnel SSH)
• Actualizaciones en tiempo real vía WebSocket
• Soporte multi-base de datos vía el parámetro ?db=
• Acceso seguro con Cloudflare Zero Trust

Configuración:

1. Crear base de datos D1:

   npx wrangler d1 create memora-graph
   npx wrangler d1 execute memora-graph --file=memora-graph/schema.sql
   

2. Desplegar Pages:

   cd memora-graph
   npx wrangler pages deploy ./public --project-name=memora-graph
   

3. Configurar enlaces en el Panel de Cloudflare:

   • Pages → memora-graph → Configuración → Enlaces
   • Añadir D1: DB_MEMORA → tu base de datos
   • Añadir R2: R2_MEMORA → tu bucket (para imágenes)

4. Configurar MCP con el URI de D1:

   {
     "env": {
       "MEMORA_STORAGE_URI": "d1://<account-id>/<database-id>",
       "CLOUDFLARE_API_TOKEN": "<your-token>"
     }
   }
   

Acceso: https://memora-graph.pages.dev

Asegurar con Zero Trust:

1. Panel de Cloudflare → Zero Trust → Acceso → Aplicaciones
2. Añadir aplicación para memora-graph.pages.dev
3. Crear política con correos electrónicos permitidos
4. Pages → Configuración → Habilitar Política de Acceso

Consulta memora-graph/ para configuración detallada y configuración multi-base de datos.

Haz preguntas sobre tu base de conocimiento directamente desde la interfaz del grafo. El panel de chat usa RAG (Generación Aumentada por Recuperación) para buscar memorias relevantes y transmitir respuestas del LLM con soporte de llamada a herramientas.

• Alternar vía el ícono de chat flotante en la parte inferior derecha
• Búsqueda semántica encuentra las memorias más relevantes como contexto
• Respuestas en streaming con referencias [Memory #ID] clicables que enfocan el nodo del grafo
• Llamada a herramientas — el LLM puede crear, actualizar y eliminar memorias directamente desde el chat (por ejemplo, "guarda esto como una memoria", "elimina la memoria #42", "actualiza la memoria #10 con...")
• Funciona tanto en el servidor local como en el despliegue de Cloudflare Pages

Configurar el modelo de chat:

Requiere una API compatible con OpenAI (OPENAI_API_KEY + OPENAI_BASE_URL para local, secreto OPENROUTER_API_KEY para Cloudflare). El modelo de chat debe soportar uso de herramientas (llamada de funciones).

Encuentra y fusiona memorias duplicadas usando comparación semántica impulsada por IA:

# Find potential duplicates (uses cross-refs + optional LLM analysis)
memory_find_duplicates(min_similarity=0.7, max_similarity=0.95, limit=10, use_llm=True)

# Merge duplicates (append, prepend, or replace strategies)
memory_merge(source_id=123, target_id=456, merge_strategy="append")

Comparación con LLM analiza pares de memorias y devuelve:

• verdict: "duplicate", "similar" o "different"
• confidence: puntuación de 0.0-1.0
• reasoning: Explicación breve
• suggested_action: "merge", "keep_both" o "review"

Funciona con cualquier API de chat compatible con OpenAI (OpenAI, OpenRouter, Azure, etc.) vía OPENAI_BASE_URL. OpenRouter es adecuado para esta ruta de LLM; no proporciona embeddings — configura los embeddings por separado (consulta Búsqueda Semántica y Embeddings).

Almacena documentos estructurados (informes de investigación, decisiones de arquitectura, autopsias) como árboles de fragmentos buscables:

# Store a markdown document — auto-parsed into typed fragments
memory_store_document(
    content="# Research Report\n\n## Evidence Table\n| Claim | Confidence |\n...",
    document_key="research/memora-enhancements-2026-04-08",
    tags=["memora/research"]
)
# Returns: {root_id: 230, fragment_count: 100, node_map: {claim: [...], plan_item: [...], ...}}

# Retrieve the full document or specific fragment types
memory_get_document(document_key="research/memora-enhancements-2026-04-08")
memory_get_document(document_key="...", node_kinds=["claim"], content_mode="full")

# Delete a document and all its fragments
memory_delete_document(document_key="research/memora-enhancements-2026-04-08")

Cómo funciona: El analizador divide el markdown por estructura — las tablas se convierten en afirmaciones individuales, las listas numeradas en elementos de plan, las listas de URL en referencias, y las secciones de riesgo en fragmentos de riesgo. Cada fragmento es buscable de forma independiente vía memory_semantic_search mientras que el documento completo se puede recuperar como una unidad.

Tipos de fragmentos: claim, plan_item, reference, section_chunk, risk

Protecciones de integridad: Los fragmentos de documentos están protegidos contra modificaciones accidentales:

• memory_delete requiere force=True para fragmentos
• memory_merge se niega a fusionar fragmentos
• memory_absorb excluye fragmentos de la coincidencia de similitud
• memory_find_duplicates y memory_detect_supersessions omiten fragmentos
• La interfaz del grafo oculta fragmentos, mostrando solo el nodo raíz del documento

Herramientas estructuradas para tipos comunes de memoria:

# Create a TODO with status and priority
memory_create_todo(content="Implement feature X", status="open", priority="high", category="backend")

# Create an issue with severity
memory_create_issue(content="Bug in login flow", status="open", severity="major", component="auth")

# Create a section placeholder (hidden from graph)
memory_create_section(content="Architecture", section="docs", subsection="api")

Analiza memorias almacenadas y muestra perspectivas accionables:

# Full analysis with LLM-powered pattern detection
memory_insights(period="7d", include_llm_analysis=True)

# Quick summary without LLM (faster, no API key needed)
memory_insights(period="1m", include_llm_analysis=False)

Devuelve:

• Resumen de actividad — memorias creadas en el período, agrupadas por tipo y etiqueta
• Elementos abiertos — TODOs y problemas abiertos con detección de obsoletos (configurable vía MEMORA_STALE_DAYS; memory_insights predeterminado 14, interfaz del grafo predeterminado 30 — misma variable, dos consumidores)
• Candidatos de consolidación — pares de memorias similares que podrían fusionarse
• Análisis con LLM — temas, áreas de enfoque, brechas de conocimiento y un resumen (requiere OPENAI_API_KEY)

Gestiona relaciones entre memorias:

# Create typed edges between memories
memory_link(from_id=1, to_id=2, edge_type="implements", bidirectional=True)

# Edge types: references, implements, supersedes, extends, contradicts, related_to

# Remove links
memory_unlink(from_id=1, to_id=2)

# Boost memory importance for ranking
memory_boost(memory_id=42, boost_amount=0.5)

# Detect clusters of related memories
memory_clusters(min_cluster_size=2, min_score=0.3)

Para visualización sin conexión, exporta memorias como un archivo HTML estático:

memory_export_graph(output_path="~/memories_graph.html", min_score=0.25)

Esto es opcional - el Servidor de Gráfico en Vivo proporciona la misma visualización con actualizaciones en tiempo real.

Explora memorias directamente en Neovim con Telescope. Copia el plugin a tu configuración:

# For kickstart.nvim / lazy.nvim
cp nvim/memora.lua ~/.config/nvim/lua/kickstart/plugins/

Uso: Presiona <leader>sm para abrir el explorador de memorias con búsqueda difusa y vista previa.

Requiere: telescope.nvim, plenary.nvim y memora instalados en tu entorno de Python.