le0nardomartins/ClaudeMemorySync-Server

Claude Memory Sync: servidor

Repositórios:

• Servidor (este): https://github.com/le0nardomartins/ClaudeMemorySync-Server
• Cliente (um por máquina): https://github.com/le0nardomartins/ClaudeMemorySync. Ele inclui o skill claude-memory-sync, faz merge de 3 vias, criptografa tudo com SYNC_KEY e também suporta um modo sem servidor usando um repositório Git privado.

O servidor não faz merge e não consegue ler o conteúdo. Ele armazena manifests e blobs lacrados, e só aceita uma nova versão se ela foi construída sobre a mais recente (caso contrário, 409 conflict).

Leia sob demanda, nesta pasta:

• deploy.md: implantação no Railway ou outro host, atualização
• api.md: o protocolo, para depuração de requisições
• operations.md: SQL para consultas e manutenção, backups, revogação, diagnósticos

As mensagens de log do servidor estão em português. operations.md lista cada uma com seu significado.

Regras que sempre se aplicam

1. Dados. Com SYNC_KEY nas máquinas, o banco de dados contém apenas dados criptografados. Sem ele, contém as chaves de API do usuário. De qualquer forma, nunca exponha o Postgres publicamente e nunca compartilhe DATABASE_URL.
2. Chaves. CLIENT_PUBLIC_KEYS contém apenas chaves públicas, que podem ser exibidas. CLIENT_PRIVATE_KEY e SYNC_KEY nunca vão para o servidor ou para o chat.
3. Confirme primeiro antes de implantar, fazer push, alterar uma variável do Railway, TRUNCATE, DELETE ou qualquer outra ação irreversível. Faça backup (pg_dump, veja operations.md) antes de tocar nos dados.
4. Protocolo compatível. Cliente e servidor devem executar a mesma versão do protocolo. Quando um for atualizado, lembre o usuário de atualizar o outro em todas as máquinas.
5. Resetar o servidor não exclui nada nas máquinas. Cada uma mantém sua base localmente e envia tudo novamente na próxima sincronização. Para remover um arquivo de todas as máquinas, basta excluí-lo em uma máquina: não mexa no servidor para isso.

Tarefas

Implantação inicial

Siga deploy.md → "Railway". O usuário deve:

• criar o projeto e o Postgres no painel, ou permitir o uso da CLI do Railway;
• colar as chaves públicas.

Ao final, procure por memory server na porta ... | PCs autorizados: ... no log.

Autorizar uma máquina

1. Na máquina, gere as chaves: python src/components/remote_client.py keygen <nome> (cliente) ou npm run keygen -- <nome> (aqui).
2. Adicione <nome>:<base64> a CLIENT_PUBLIC_KEYS, separado por vírgula, sem remover as outras.
3. O Railway reinicia automaticamente. Verifique se o nome aparece em PCs autorizados no log.

Revogar uma máquina

Remova a entrada dela de CLIENT_PUBLIC_KEYS. Se a máquina foi comprometida, oriente o usuário a rotacionar a SYNC_KEY em todas as máquinas (solução de problemas do cliente) e resetar o histórico (operations.md).

Solucionar problemas

Leia os logs do serviço (painel do Railway ou railway logs) e compare com operations.md → "Diagnósticos". No lado do cliente, o arquivo é sync.log. Um 409 seguido de um 201 é normal.

Consultar ou manter o banco de dados

Use as consultas em operations.md. Para acesso único, use railway connect Postgres. Prefira consultas somente leitura e confirme qualquer escrita.

Atualizar o servidor

1. Faça push para o repositório: o Railway implanta a partir do Dockerfile. As migrações são executadas na inicialização (db.migrate).
2. Em seguida, peça ao usuário para atualizar os clientes.