LifeOS

Persönliches Commitment-System: Erfassung primär per Telegram, KI-Strukturierung, Beziehungs-Gedächtnis, Wochen-Rückblick. PWA mit Push-Benachrichtigungen, alles aus einer einzigen Commitment-Tabelle.

Schlüsselentscheidung

Ein einziges Commitment-Datenmodell für alles — Tasks, Erinnerungen, Versprechen, Termine, Habits, Ziele, Areas, Projekte sind nur Type-Flags auf derselben Tabelle, Hierarchie über Self-Reference auf den Parent. Eine Recurrence-Engine, eine Status-Maschine, ein Set Sicherheits-Regeln. Preis: Type-Flag-Polymorphie überall, Queries werden gelegentlich umständlicher. Bezahlt sich aus, weil keine Schema-Migration jemals nötig wird, wenn ein neuer Verpflichtungstyp dazukommt.

Keine Todo-App, kein CRM — ein persönliches Betriebssystem für Verpflichtungen: gegenüber dir selbst (Ziele, Routinen), gegenüber anderen (Versprechen, Folge-Schritte) und gegenüber dem Alltag (Termine, Aufgaben). Erfasst wird primär per Telegram in natürlicher Sprache; Claude strukturiert und fragt bei Unsicherheit nach, statt zu raten. Wiederholungen werden als RRULE gespeichert; Erinnerungen laufen über BullMQ + Web-Push. Menschen sind eigenständige Entitäten mit Interaktions-Verlauf und konfigurierbarem Folge-Rhythmus.

Vision in einem Satz

Alles im Leben ist eine Verpflichtung — gegenüber dir selbst, gegenüber anderen, gegenüber dem Alltag. LifeOS erfasst, strukturiert und holt sie zur richtigen Zeit nach vorn. Keine Todo-App, kein CRM — ein persönliches Betriebssystem.

Erfassungs-Kanäle

Phone-first, immer. Telegram ist die primäre Eingangstür — eine schnelle Capture-Zeile, mit der man unterwegs Gedanken parkt, ohne die App öffnen zu müssen.

Kanal	Rolle
Telegram	Primärer Erfassungs-Kanal. Natürliche Sprache rein, Inline-Buttons für Rückfragen raus. Antworten auf alte Bot-Nachrichten reaktivieren den Thread.
PWA Quick-Add	Sekundärer Erfassungs-Slot, wenn man bereits in der App ist. Gleiche KI-Parsing-Pipeline wie Telegram.
Web Push (PWA)	Passive Erinnerungen, geplante Benachrichtigungen, sanftes Anstupsen — funktioniert dank Service-Worker auch auf iOS.
Telegram-Reminder	Aktive Benachrichtigungen mit Inline-Buttons: erledigt, snooze, neu planen.

Beispiel-Captures

Was die KI aus unsauberer Eingabe macht:

'ruf morgen Mama an'
'erinner mich in 2 Wochen, Jonas wegen Umzug zu fragen'
'Anna Geburtstag 12. April, brauche Geschenk und Dinner'
'jeden zweiten Dienstag Yoga'

Commitment — das Kern-Objekt

Alles, was Aktion erfordert, ist ein Commitment. Eine einzige Tabelle mit Type-Flag und Self-Reference auf den Parent — Areas, Projekte, Tasks, Habits sind nur unterschiedliche Sichten desselben Datentyps.

Feld	Beschreibung
type	task, reminder, promise, event, habit, goal, area, project — alles ein Datentyp.
dueDate / scheduledDate	Harte Deadline vs. geplantes Bearbeitungsdatum. Beide auf dem Kalender, unterschiedlich behandelt.
recurrence (RRULE)	iCal-Standard. Anthropic parst natürliche Sprache zu RRULE: 'jeden 2. Dienstag' → echtes Recurrence-Rule-Objekt.
parent	Area → Goal → Project → Task → Subtask. Beliebig tief, ein Datenmodell.
linkedPeople	Wer ist involviert / wem wurde es versprochen. Direkter Join zur Person.
linkedGoal	Welches langfristige Ziel diese Verpflichtung bedient.
commitmentStrength	Hartes Versprechen / weiche Absicht / Idee. Beeinflusst Sortierung und UI-Gewicht.
status + snoozeUntil	open / in_progress / done / snoozed / deferred / cancelled. Snoozed-Einträge tauchen automatisch wieder auf.

Architektur

Klassischer Monorepo-Aufbau: React-PWA, Express-API, Postgres mit Prisma. Daneben Telegram-Webhook, BullMQ auf Redis und die Anthropic-API.

┌──────────────┐     ┌──────────────┐     ┌──────────────────┐
│  React PWA   │────▶│  Express API │────▶│   PostgreSQL     │
│  (Tailwind)  │◀────│  (Node.js)   │     │   (Prisma ORM)   │
└──────────────┘     └──────┬───────┘     └──────────────────┘
                            │
                    ┌───────┼────────┐
                    │       │        │
              ┌─────▼──┐ ┌─▼─────┐ ┌▼──────────┐
              │Telegram│ │BullMQ │ │Claude API │
              │Webhook │ │(Redis)│ │(Anthropic)│
              └────────┘ └───────┘ └───────────┘
                            │
                      ┌─────▼──────┐
                      │ Web Push   │
                      │ Service    │
                      └────────────┘

Dashboard — was zählt jetzt?

Der Startbildschirm beantwortet genau eine Frage. Sieben Sektionen, alle gleich strukturiert, alle aus derselben Commitment-Tabelle hervorgegangen.

Heute

Geplante Commitments, Fälligkeiten, Events, Routinen.

Überfällig

Verpasste Deadlines, ungelöste Items.

Demnächst

Preview der nächsten Tage.

Offene Schleifen

Versprechen an / von anderen, unerledigte Punkte.

Personen

Wer braucht Aufmerksamkeit, fällige Follow-ups.

Ziele

Fortschritt, Streaks, Drift-Warnungen.

Inbox-Counter

Unverarbeitete Einträge, die Triage brauchen.

Wochen-Review — geführter Flow

Erscheint Montag im Dashboard, getriggert per Push. Sechs Schritte; auch jederzeit manuell aufrufbar.

1
Inbox leeren — alle unstrukturierten Items verarbeiten.
2
Commitments durchgehen — Überfällig, abgestanden, neu planen.
3
Someday / Maybe — aufgeschobene Items, die wieder relevant werden.
4
Beziehungen — wer braucht Aufmerksamkeit, offene Versprechen.
5
Ziele — Fortschritts-Check, Drift-Erkennung, KI-vorgeschlagene nächste Schritte.
6
Woche planen — Schlüssel-Commitments setzen.

Schlüsselentscheidungen

Ein Datenmodell für alles

Tasks, Erinnerungen, Versprechen, Termine, Habits, Ziele, Areas, Projekte — alles dieselbe Commitment-Tabelle mit Type-Flag. Parent-Relations machen die Hierarchie. Ein Schema, eine Recurrence-Engine, eine Status-Maschine.

Capture-First, Struktur-Second

Eingaben dürfen unsauber sein. 'Anna Geburtstag 12. April, brauche Geschenk und Dinner' landet in der Inbox; die KI extrahiert Person, Datum und zwei Folge-Commitments. Was unklar bleibt, wird gefragt — nicht geraten.

KI assistiert, entscheidet nicht

Bei Mehrdeutigkeit fragt das System per Inline-Button-Auswahl oder Freitext nach. Wichtige Daten werden nie still geändert. Haiku übernimmt schnelle Mikro-Operationen, Sonnet die komplexe Parsing-Arbeit.

RRULE statt eigenes Recurrence-Format

iCal-RRULE deckt alles ab — täglich, wöchentlich, zweiwöchentlich, 'jeden 2. Dienstag', eigene Cron-Ausdrücke. Breit unterstützt, kompatibel, keine eigene Recurrence-Engine zu warten. Beim Abschluss wird die nächste Instanz automatisch erzeugt; abgeschlossene Instanzen werden archiviert, nicht gelöscht.

Beziehungen als eigenständiges Objekt

Eine Person hat Kontext, einen Interaktions-Verlauf (manuell + automatisch aus abgeschlossenen Commitments), einen Folge-Rhythmus und offene Schleifen. Das System holt aktiv nach vorn, wer Aufmerksamkeit braucht — kein CRM-Datengrab.

Ephemere KI-Konversationen

Pro Interaktion eine ephemere Konversation; nach erfolgreicher Extraktion endet der Kontext. Nur Antworten auf alte Bot-Nachrichten reaktivieren den ursprünglichen Thread. Konversationshistorie wird 24h gehalten, dann verworfen — nur die extrahierten Commitments bleiben bestehen.

SSE statt WebSockets

Live-Dashboard-Updates kommen über Server-Sent Events. Einfacher als WebSocket, reicht für 'unidirektional + Reconnect', spart Komplexität auf Server- und Client-Seite.

Notification-Batching mit harten Caps

Ruhezeiten, Stummschaltung pro Kategorie, Frequenz-Caps, intelligentes Bündeln von Low-Priority-Items in Digests. Vernünftige Defaults, vollständig konfigurierbar — niemand wird zugespamt.

Deployment

Self-hosted auf einem VPS, Docker-Compose für Postgres und Redis. Der Telegram-Bot läuft im Webhook-Modus auf demselben Server. VAPID-Keys werden server-seitig erzeugt, JWT ohne Ablauf für persistente Sessions, einfache Username/Passwort-Auth (bcrypt). Online-only — kein Offline-Sync, keine Synchronisations-Kopfschmerzen.