Deine Meetings, committet in dein eigenes Repository

Die Aufzeichnung von Earkeep besteht schon aus einfachen Dateien: eine JSONL-Datei pro Tag, in einem Ordner deiner Wahl, oft im Repository, in dem auch deine Notizen liegen. Ein Ordner ist aber nur versioniert, wenn jemand committet, und von Hand committen hört spätestens am Mittwoch auf. Deshalb macht Earkeep die Commits und überlässt den Rest des Repositorys dir.

Es schaltet sich nur in einem Repository ein. Ist der Transkript-Ordner oder einer darüber ein Git-Repository, bietet Settings → Storage & Git die Funktion an. Andernfalls gibt es einen Button, der git init ausführt, und das ist der einzige Weg, auf dem Earkeep je ein Repository anlegt.

Du bestimmst, wann committet wird: wenn ein Tag endet, wenn sich ein Meeting ändert, beides (Standard) oder nie.

• Wenn ein Tag endet heißt fünf Minuten nach Mitternacht. Ein Laptop, der um Mitternacht schläft, committet den gestrigen Tag, sobald er aufwacht.
• Wenn sich ein Meeting ändert heißt gespeichert, beendet, in der Länge angepasst, umbenannt oder gelöscht, wenige Sekunden nach der letzten Änderung. Das Ziehen an einer Kante ergibt also einen einzigen Commit. Der Beginn eines Meetings löst keinen Commit aus, neue Transkriptzeilen allein auch nicht.

Ein Commit pro Tagesdatei, sonst nichts. Was du selbst gestaged hast, bleibt aus den Commits von Earkeep heraus, und eine Tagesdatei, die deine .gitignore ausschließt, wird übergangen.

Nur auf einem Branch, den du erlaubst: main (oder master), der jeweils ausgecheckte Branch oder einer, den du benennst. Auf jedem anderen Branch wird nichts committet, und Settings sagt dir, warum.

Jede Nachricht nennt den Tag und das Meeting, sodass git log --oneline sich liest wie deine Woche:

Jede Nachricht ist eine Vorlage, die du in Settings umschreiben kannst, eine pro Ereignis, mit {date} und {meeting} als Platzhaltern.

Pushe auf alle Remotes (Standard), auf die Remotes, die du auswählst, oder gar nicht. Dann bleibt jeder Commit auf deinem Gerät.

Das ist der einzige Weg, auf dem ein Transkript dein Gerät verlässt, und zwar nur zu einem Remote, das du eingerichtet hast, unter deinem eigenen Konto. Earkeep hat in diesem Pfad keinen Server.

Es ist dein eigenes git, also gelten dein SSH-Agent, deine Credential-Helper und deine Hooks wie im Terminal. Ein Push, der nach einem Passwort oder einer Passphrase fragen würde, schlägt sofort fehl und nennt den Grund, statt auf eine Eingabeaufforderung zu warten, die niemand sieht.

Ein Remote, das weitergezogen ist, wird gepullt, nicht abgelehnt. Earkeep tut, was git pull --rebase --autostash tut, und pusht dann. Die Aufnahme läuft weiter; das Bearbeiten eines Meetings ist für diesen Moment pausiert und sagt das auch.

Widersprechen die Commits des Remotes deinen eigenen, übergibt Earkeep den angehaltenen Rebase an einen der ACP-Agenten auf deinem Rechner, etwa Claude Code oder Codex. Danach prüft es das Repository, nicht die Antwort des Agenten: Der Rebase ist abgeschlossen, die Commits beider Seiten sind da, kein Konfliktmarker ist übrig. Erst dann pusht es.

Alles, was dahinter zurückbleibt, wird rückgängig gemacht: Der Rebase wird abgebrochen, dein Branch und deine uncommitteten Änderungen kehren so zurück, wie sie waren, und Earkeep zeigt dir, was der Agent gesagt hat. Der Agent ist dein eigenes Werkzeug mit deinem eigenen Schlüssel, was er liest, geht also dorthin, wohin dieser Agent normalerweise sendet.

Ein Fehler erscheint über dem Transkript in klaren Worten (das Remote hat deinen Schlüssel abgewiesen, der Host war nicht erreichbar, ein Konflikt braucht dich), darunter die Originalmeldung von git. Earkeep versucht es alle fünf Minuten erneut, sodass der Push durchgeht, sobald die Ursache behoben ist.

• Privat von Grund auf: die Dateien, die hier committet werden.
• Agenten und MCP: die Agenten, die deine Protokolle schreiben und deine Konflikte lösen.
• PKM für Entwickler: Notizen als Git-Repository.
• Das LLM-Wiki: was aus einem versionierten Ordner voller Meetings wird.