le0nardomartins/ClaudeMemorySync-Server

Claude Memory Sync: Server

Repositories:

• Server (dieser): https://github.com/le0nardomartins/ClaudeMemorySync-Server
• Client (eine pro Maschine): https://github.com/le0nardomartins/ClaudeMemorySync. Er enthält das Skill claude-memory-sync, führt den 3-Wege-Merge durch, verschlüsselt alles mit dem SYNC_KEY und unterstützt auch einen serverlosen Modus, der auf einem privaten Git-Repository basiert.

Der Server führt keine Zusammenführung durch und kann keine Inhalte lesen. Er speichert versiegelte Manifeste und Blobs und akzeptiert nur eine neue Version, wenn sie auf der neuesten aufbaut (andernfalls 409 conflict).

Bei Bedarf lesen, in diesem Ordner:

• deploy.md: Bereitstellung auf Railway oder einem anderen Host, Aktualisierung
• api.md: Das Protokoll, zum Debuggen von Anfragen
• operations.md: SQL für Abfragen und Wartung, Backups, Widerruf, Diagnose

Server-Logmeldungen sind auf Portugiesisch. operations.md listet jede mit ihrer Bedeutung auf.

Regeln, die immer gelten

1. Daten. Mit SYNC_KEY auf den Maschinen enthält die Datenbank nur verschlüsselte Daten. Ohne ihn enthält sie die API-Schlüssel des Benutzers. In beiden Fällen Postgres niemals öffentlich zugänglich machen und DATABASE_URL niemals teilen.
2. Schlüssel. CLIENT_PUBLIC_KEYS enthält nur öffentliche Schlüssel, die angezeigt werden dürfen. CLIENT_PRIVATE_KEY und SYNC_KEY gelangen niemals auf den Server oder in den Chat.
3. Zuerst bestätigen vor einer Bereitstellung, einem Push, einer Änderung einer Railway-Variable, TRUNCATE, DELETE oder anderen irreversiblen Aktionen. Vor dem Bearbeiten von Daten ein Backup erstellen (pg_dump, siehe operations.md).
4. Passendes Protokoll. Client und Server müssen dieselbe Protokollversion verwenden. Wenn eines aktualisiert wird, den Benutzer daran erinnern, das andere auf jeder Maschine zu aktualisieren.
5. Das Zurücksetzen des Servers löscht nichts auf den Maschinen. Jede Maschine behält ihre lokale Basis und lädt beim nächsten Durchlauf alles erneut hoch. Um eine Datei von allen Maschinen zu entfernen, reicht es, sie auf einer Maschine zu löschen: Dafür den Server nicht anfassen.

Aufgaben

Erstmalige Bereitstellung

deploy.md → „Railway“ folgen. Der Benutzer muss:

• das Projekt und Postgres im Dashboard erstellen oder die Verwendung der Railway-CLI erlauben;
• die öffentlichen Schlüssel einfügen.

Am Ende im Log nach memory server auf port ... | PCs autorisiert: ... suchen.

Eine Maschine autorisieren

1. Auf der Maschine Schlüssel generieren: python src/components/remote_client.py keygen <name> (Client) oder npm run keygen -- <name> (hier).
2. <name>:<base64> an CLIENT_PUBLIC_KEYS anhängen, durch Komma getrennt, ohne die anderen zu entfernen.
3. Railway startet von selbst neu. Überprüfen, dass der Name im Log unter „PCs autorisiert“ erscheint.

Eine Maschine widerrufen

Den Eintrag aus CLIENT_PUBLIC_KEYS entfernen. Falls die Maschine kompromittiert war, den Benutzer durch das Rotieren des SYNC_KEY auf jeder Maschine (Client-Fehlerbehebung) und das Zurücksetzen des Verlaufs (operations.md) führen.

Fehlerbehebung

Die Dienstprotokolle lesen (Railway-Dashboard oder railway logs) und mit operations.md → „Diagnose“ vergleichen. Auf der Client-Seite ist die Datei sync.log. Ein 409 gefolgt von einem 201 ist normal.

Datenbank abfragen oder warten

Die Abfragen in operations.md verwenden. Für einmaligen Zugriff railway connect Postgres verwenden. Schreibgeschützte Abfragen bevorzugen und jede Schreiboperation bestätigen.

Server aktualisieren

1. In das Repository pushen: Railway stellt vom Dockerfile bereit. Migrationen werden beim Start ausgeführt (db.migrate).
2. Dann den Benutzer bitten, die Clients zu aktualisieren.