Dein Datenformat bleibt lesbar. Für immer.

Das Monica-Chandler-Problem

Apps, die persönliche Daten verwalten, haben ein strukturelles Vertrauensproblem: Nutzer:innen wissen nie genau, ob ein Update ihre Daten still umbricht. Monica, ein beliebter Open-Source-Personal-CRM, hat über die Jahre das Datenbankschema mehrfach geändert — und wer nicht regelmäßig exportiert oder auf Migrations-Fehler geachtet hat, stand manchmal mit inkonsistenten Daten da.

Wir nennen das das "Monica-Chandler-Problem": Die Angst, dass ein Update Julias Knie-OP-Notiz, Mikes Spitznamen oder drei Jahre Interaktionshistorie still überschreibt, weil die Migration einen Edge-Case nicht bedacht hat.

Unser Versprechen: Das passiert bei Endearist nicht. Hier steht konkret, wie wir das durchsetzen.

Wie Migrations-Disziplin technisch aussieht

Schema-Dumps vor jedem Versions-Bump

Bevor wir die Datenbank-Versionsnummer erhöhen, wird ein vollständiger Schema-Dump in das Repository committed. Das ist eine harte technische Regel — kein Versions-Bump ohne committed Schema-Snapshot. Wenn du in zehn Jahren schaust, welches Schema v1.4.2 hatte, findest du es im Git-Log.

Migrations nur vorwärts, reversibel über JSON

Alle Datenbank-Migrationen laufen in eine Richtung: von alt nach neu. Wir schreiben keine Migrationen, die Daten irreversibel löschen oder transformieren, ohne einen Pre-Migration-Snapshot zu erstellen. Vor jeder Migration wird ein vollständiger JSON-Export der betroffenen Daten gespeichert — als Sicherheitsnetz, falls die Migration fehlschlägt oder einen Fehler enthält.

Das bedeutet konkret: Wenn eine Migration fehlschlägt, wird der Pre-Migration-Snapshot automatisch restored. Du bekommst eine Fehlermeldung, aber keinen Datenverlust. Das ist nicht optional — es ist Teil der Migrations-Pipeline.

Schema-Version in jeder Backup-Datei

Jedes automatische Backup enthält die Schema-Version, unter der es erstellt wurde. Das bedeutet: Wenn du ein Backup von v1.2.0 mit Endearist v2.5.0 öffnest, weiß die App exakt, welche Migrationen sie anwenden muss — und sie tut es in Reihe, verifiziert, mit Pre-Step-Snapshots.

Feldgenaue Sync-Konflikte statt stiller Gewinner

Local-first Software hat eine zusätzliche Verantwortung: Zwei Geräte können nahe beieinanderliegende Daten ändern, bevor sie synchronisieren. Unsere Merge-Policy ist auf Felder und Zeitstempel ausgelegt, nicht auf "letzte Datei gewinnt". Wenn dein Laptop eine Geburtstagserinnerung ändert und dein Handy gleichzeitig eine Notiz ergänzt, sind das getrennte Fakten und beide sollen erhalten bleiben. Wenn zwei Änderungen wirklich kollidieren, soll die App den Konflikt zeigen, statt eine Seite still zu verwerfen.

Die Policy ist nach Datentyp explizit. Skalare Felder wie ein Erinnerungsintervall können Last-Write-Wins nutzen, aber der verworfene Wert bleibt im Changelog wiederherstellbar. Mengen wie Tags oder Gruppenmitgliedschaften werden vereinigt, mit Tombstones für Löschungen, damit entfernte Einträge nicht still zurückkommen. Interaktionshistorie ist append-only: Wenn zwei Geräte zwei getrennte Ereignisse hinzufügen, sollen beide bleiben. Lange persönliche Notizen sind Manual-Review-Felder; wenn zwei Geräte dieselbe Notiz ändern, soll Endearist fragen statt einen semantischen Merge zu erfinden.

Das klingt klein, ist aber der Unterschied zwischen "Sync war erfolgreich" und "Sync war erfolgreich, ohne den Fakt zu löschen, den du wichtig genug fandest, ihn aufzuschreiben." Wir zeigen lieber selten eine Konfliktprüfung, als still die falsche Version einer persönlichen Erinnerung zu wählen.

Was das in der Praxis bedeutet

Vorwärtskompatibilität über Releases hinweg

Jeder Release-Kandidat muss alle Migrations-Schritte von v1 bis zur aktuellen Version erfolgreich durchlaufen. Das wird als Teil der Continuous-Integration-Pipeline geprüft — kein Release geht raus, wenn der Migrations-Roundtrip fehlschlägt. "Alle Migrationen von v1 bis heute müssen round-trippen" ist eine der Pre-Merge-Bedingungen in unserer Engineering-Dokumentation.

Dein Datenformat ist kein proprietäres Geheimnis

Das SQLite-Schema ist dokumentiert. Der Markdown-Export-Entwurf ist öffentlich. Selbst wenn Endearist morgen aufhören würde zu existieren, könntest du mit einem Standard-SQLite-Tool deine Daten öffnen und lesen — ohne proprietäre Software, ohne uns.

Das ist die praktische Bedeutung von Schema-Stabilität: Deine Beziehungshistorie hängt nicht an unserem künftigen Geschäftsmodell. Updates dürfen die App besser machen, aber sie dürfen deine alten Erinnerungen nicht unlesbar machen.

Was wir versprechen und was nicht

Wir versprechen: Jede neue Version von Endearist kann Daten jeder älteren Version öffnen. Jede Migration ist getestet. Kein Silent-Drop von Datenfeldern ohne explizite Benutzerwarnung. Kein automatischer Merge langer persönlicher Notizen, wenn die App nicht wissen kann, welche Version wahr ist.

Wir versprechen nicht: Rückwärtskompatibilität — eine ältere App-Version kann möglicherweise keine Daten öffnen, die mit einer neueren Version erstellt wurden. Das wäre technisch schwer durchzuhalten und gibt dir keinen praktischen Mehrwert, weil du immer auf die neueste Version aktualisieren kannst.