le0nardomartins/ClaudeMemorySync-Server

Claude Memory Sync: servidor

Repositorios:

• Servidor (este): https://github.com/le0nardomartins/ClaudeMemorySync-Server
• Cliente (uno por máquina): https://github.com/le0nardomartins/ClaudeMemorySync. Incluye el skill claude-memory-sync, realiza la fusión en tres direcciones, cifra todo con SYNC_KEY y también ofrece un modo sin servidor respaldado por un repositorio Git privado.

El servidor no fusiona ni puede leer el contenido. Almacena manifiestos sellados y blobs, y solo acepta una nueva versión si se construyó sobre la más reciente (en caso contrario, da 409 conflict).

Lea bajo demanda, en esta carpeta:

• deploy.md: despliegue en Railway u otro host, actualización
• api.md: el protocolo, para depurar solicitudes
• operations.md: SQL para consultas y mantenimiento, copias de seguridad, revocación, diagnósticos

Los mensajes del registro del servidor están en portugués. operations.md enumera cada uno con su significado.

Reglas que siempre aplican

1. Datos. Con SYNC_KEY en las máquinas, la base de datos solo contiene datos cifrados. Sin ella, guarda las claves de API del usuario. De cualquier forma, nunca exponga Postgres públicamente y nunca comparta DATABASE_URL.
2. Claves. CLIENT_PUBLIC_KEYS contiene solo claves públicas, que pueden mostrarse. CLIENT_PRIVATE_KEY y SYNC_KEY nunca van al servidor ni al chat.
3. Confirme primero antes de un despliegue, un push, cambiar una variable de Railway, TRUNCATE, DELETE o cualquier otra acción irreversible. Haga una copia de seguridad (pg_dump, ver operations.md) antes de tocar los datos.
4. Protocolo coincidente. Cliente y servidor deben ejecutar la misma versión del protocolo. Cuando uno se actualice, recuerde al usuario que actualice el otro en todas las máquinas.
5. Reiniciar el servidor no elimina nada en las máquinas. Cada una mantiene su base localmente y vuelve a subir todo en la siguiente ronda. Para eliminar un archivo de todas las máquinas, basta con eliminarlo en una: no toque el servidor para eso.

Tareas

Despliegue inicial

Siga deploy.md → "Railway". El usuario debe:

• crear el proyecto y Postgres en el panel, o permitir el uso de la CLI de Railway;
• pegar las claves públicas.

Al final, busque memory server na porta ... | PCs autorizados: ... en el registro.

Autorizar una máquina

1. En la máquina, genere claves: python src/components/remote_client.py keygen <nombre> (cliente) o npm run keygen -- <nombre> (aquí).
2. Agregue <nombre>:<base64> a CLIENT_PUBLIC_KEYS, separado por coma, sin eliminar las demás.
3. Railway se reinicia solo. Verifique que el nombre aparezca en PCs autorizados en el registro.

Revocar una máquina

Elimine su entrada de CLIENT_PUBLIC_KEYS. Si la máquina fue comprometida, guíe al usuario para rotar SYNC_KEY en cada máquina (solución de problemas del cliente) y restablecer el historial (operations.md).

Solucionar problemas

Lea los registros del servicio (panel de Railway o railway logs) y compárelos con operations.md → "Diagnósticos". Del lado del cliente, el archivo es sync.log. Un 409 seguido de un 201 es normal.

Consultar o mantener la base de datos

Use las consultas en operations.md. Para acceso puntual, use railway connect Postgres. Prefiera consultas de solo lectura y confirme cualquier escritura.

Actualizar el servidor

1. Haga push al repositorio: Railway despliega desde el Dockerfile. Las migraciones se ejecutan al iniciar (db.migrate).
2. Luego pida al usuario que actualice los clientes.