le0nardomartins/ClaudeMemorySync-Serveur

Claude Memory Sync : Serveur

Dépôts :

• Serveur (celui-ci) : https://github.com/le0nardomartins/ClaudeMemorySync-Server
• Client (un par machine) : https://github.com/le0nardomartins/ClaudeMemorySync. Il embarque le skill claude-memory-sync, effectue la fusion à trois voies, chiffre tout avec la SYNC_KEY, et prend également en charge un mode serverless basé sur un dépôt Git privé.

Le serveur ne fusionne pas et ne peut pas lire le contenu. Il stocke des manifestes et des blocs scellés, et n'accepte une nouvelle version que si elle est construite sur la plus récente (409 conflit dans le cas contraire).

Lire à la demande, dans ce dossier :

• deploy.md : déploiement sur Railway ou un autre hébergeur, mise à jour
• api.md : le protocole, pour déboguer les requêtes
• operations.md : SQL pour les requêtes et la maintenance, sauvegardes, révocation, diagnostics

Les messages de journal du serveur sont en portugais. operations.md liste chacun d'eux avec leur signification.

Règles qui s'appliquent toujours

1. Données. Avec SYNC_KEY sur les machines, la base de données ne contient que des données chiffrées. Sans elle, elle contient les clés API de l'utilisateur. Dans les deux cas, ne jamais exposer Postgres publiquement et ne jamais partager DATABASE_URL.
2. Clés. CLIENT_PUBLIC_KEYS ne contient que des clés publiques, qui peuvent être affichées. CLIENT_PRIVATE_KEY et SYNC_KEY ne doivent jamais être envoyées au serveur ni dans le chat.
3. Confirmer d'abord avant un déploiement, un push, une modification de variable Railway, TRUNCATE, DELETE, ou toute autre action irréversible. Sauvegarder (pg_dump, voir operations.md) avant de toucher aux données.
4. Protocole correspondant. Le client et le serveur doivent exécuter la même version du protocole. Lorsque l'un est mis à jour, rappeler à l'utilisateur de mettre à jour l'autre sur chaque machine.
5. La réinitialisation du serveur ne supprime rien sur les machines. Chacune conserve sa base localement et télécharge tout à nouveau lors de la prochaine synchronisation. Pour supprimer un fichier de toutes les machines, le supprimer sur une seule machine suffit : ne pas toucher au serveur pour cela.

Tâches

Déploiement initial

Suivre deploy.md → « Railway ». L'utilisateur doit :

• créer le projet et Postgres dans le tableau de bord, ou autoriser l'utilisation de la CLI Railway ;
• coller les clés publiques.

À la fin, chercher memory server na porta ... | PCs autorizados: ... dans le journal.

Autoriser une machine

1. Sur la machine, générer les clés : python src/components/remote_client.py keygen <nom> (client) ou npm run keygen -- <nom> (ici).
2. Ajouter <nom>:<base64> à CLIENT_PUBLIC_KEYS, séparé par une virgule, sans supprimer les autres.
3. Railway redémarre automatiquement. Vérifier que le nom apparaît dans PCs autorizados dans le journal.

Révoquer une machine

Supprimer son entrée de CLIENT_PUBLIC_KEYS. Si la machine a été compromise, guider l'utilisateur pour faire tourner la SYNC_KEY sur chaque machine (dépannage client) et réinitialiser l'historique (operations.md).

Dépannage

Lire les journaux du service (tableau de bord Railway ou railway logs) et comparer avec operations.md → « Diagnostics ». Côté client, le fichier est sync.log. Un 409 suivi d'un 201 est normal.

Interroger ou maintenir la base de données

Utiliser les requêtes dans operations.md. Pour un accès ponctuel, utiliser railway connect Postgres. Privilégier les requêtes en lecture seule et confirmer toute écriture.

Mettre à jour le serveur

1. Pusher vers le dépôt : Railway déploie à partir du Dockerfile. Les migrations s'exécutent au démarrage (db.migrate).
2. Demander ensuite à l'utilisateur de mettre à jour les clients.