Saltar al contenido principal

Llevar tu repositorio a la memoria

Instalaste @mnemosyne_os/mcp desde un directorio, y tu agente tiene ahora herramientas que todavía no puede usar. Esta página dice qué funciona ya y para qué está la aplicación. Luego qué hacer para que tu código esté delante de tu agente mañana por la mañana.

Lo que responde sin instalar nada más​

Tres herramientas leen los archivos de transcripción que tu arnés de agente ya escribe en el disco:

  • mnemosyne_agent_list nombra las sesiones que corren en esta máquina, en qué repositorio y en qué rama, y marca aquella con la que hablas.
  • mnemosyne_agent_collisions dice si otro agente trabaja en el mismo árbol de trabajo git. El índice lo comparten todos los procesos de un árbol, así que un commit de uno se lleva lo que el otro ha preparado.
  • mnemosyne_agent_files lista los archivos que una sesión escribió, por llamada de herramienta y por comando de shell.

Ninguna aplicación, ningún vault, ningún token, ninguna llamada de red. Pregunta a tu agente qué más corre en este repositorio y tienes respuesta al primer intento.

Todo lo demás se niega mientras la aplicación no esté abierta. La negativa dice cuál de los dos problemas tienes: nunca se instaló aquí, o está instalada y cerrada. Son dos pasos siguientes distintos, así que son dos frases distintas.

Por qué hay una aplicación​

Pregunta legítima cuando viniste a buscar un servidor. Tres cosas tienen que vivir en algún sitio, y ninguna cabe en un relé.

Algo tiene que guardar el contenido. Un texto se vuelve recuperable una vez troceado, vectorizado e indexado, y ese índice es una base de datos en tu disco. El servidor MCP no guarda ningún estado: abre un socket y pasa mensajes. Si guardara tu repositorio, tendrías una segunda copia de tu código dentro de un proceso donde no puedes mirar. Ninguna lista de lo que entró. Ninguna forma de sacar una cosa.

Algo tiene que recuperar bien. Una búsqueda por similitud devuelve el pasaje que se parece a la pregunta, que a menudo no es el que la responde. El motor detrás del socket ejecuta un canal léxico y un canal vectorial, y fusiona sus clasificaciones. Eso pide un índice de verdad y no una envoltura alrededor de una llamada de vectorización.

Alguien tiene que decidir. Qué carpetas se vigilan. En qué vault aterrizan. Qué vaults puede leer un agente, y cuáles no deben mezclarse nunca con el resto. Qué modelo responde. Son decisiones sobre tu propia materia, y un servidor sin pantalla tendría que tomarlas por ti en un archivo que editas a ciegas.

Así que sí, una aplicación de escritorio. Lo que te da: cada crónica que entró es visible, y se quita una por una. Viven en el mismo tablero que las tarjetas que muestran lo que hacen tus agentes.

Llevar tu materia dentro​

Tus archivos: código, notas de arquitectura, decisiones​

Declaras una carpeta, la aplicación la vigila, y lo que aterriza ahí se ingiere en el vault que elegiste. No se lee nada que no hayas nombrado.

Este es el paso que se pierde. Instalar la aplicación te da vaults vacíos, y es declarar la carpeta lo que los llena. Ver Primeros pasos y DocWatch.

Tus commits​

mnemosyne_git_log lee el repositorio en el momento en que lo llamas. Nada se ingiere y nada se almacena. El historial que ve tu agente nunca está caduco ni duplicado.

Lo que tus agentes anotaron​

Sus notas, las reglas del proyecto, sus archivos de sesión: Conectar la memoria de tu agente de código.

Qué va dónde​

Ruta por ruta, porque una sola frase sobre privacidad sería falsa para una de ellas.

  • Los vaults son archivos en tu propio disco, bajo tu cuenta. Los lee la aplicación y lo que tú conectes a ella.
  • El servidor MCP abre un socket, 127.0.0.1:7799, y no almacena nada. Es MIT, así que puedes leer exactamente lo que envía.
  • El modelo que responde es el que elegiste. Un modelo local mantiene la pregunta en la máquina. Un proveedor cloud que configuraste con tu propia clave recibe la pregunta y los pasajes recuperados para ella. Es el mismo intercambio que cualquier otra llamada de API que hagas.

Y después​