Persönliches Projekt · Windows-Desktop · Nathan Klieme

Eine App,
zwei Fassungen

N∞.AI ist das Programm, mit dem ich meinen Arbeitstag organisiere. Aufgaben, Notizen, Projekte und Termine liegen an einer Stelle, und sie bleiben auf meinem Rechner. Hier siehst du zwei Fassungen davon: die, die ich täglich benutze, und den Neuaufbau, an dem ich gerade sitze.

~92.000Zeilen Quellcode
in Fassung 1.7.2

249Befehle über die
Prozessgrenze

78Testdateien
in der 1.7.2

60Commits im Neuaufbau
seit dem 26. August

Worum es geht

Mein Tag springt hin und her zwischen Planung, Organisation und dem Programmieren. Für jeden dieser Bereiche gibt es gute Werkzeuge. Nur hängen sie nicht zusammen, und die meisten wollen meine Daten auf ihre Server legen.

Also habe ich mir selbst etwas gebaut. Ein Fenster, in dem aus einer Notiz eine Aufgabe wird, die Aufgabe zu einem Projekt gehört und der Termin dazu im selben Kalender steht. Nichts davon verlässt den Rechner, außer ich gebe es ausdrücklich frei.

Nebenbei ist das Projekt mein Übungsplatz. Ich will eine Oberfläche bauen können, die nach etwas aussieht. Ich will wissen, wie man eine saubere Grenze zwischen zwei Programmteilen zieht. Und ich will einen Ablauf haben, der meine Fehler findet, bevor ich sie selbst bemerke.

Die gebaute Fassung

1.7.2 · im täglichen Einsatz

Diese Fassung ist über Monate gewachsen und mein tägliches Werkzeug. Der Kern läuft: Ich werfe alles Ungeordnete in den Eingang und sortiere es später. Aufgaben gibt es als Board, als Timeline und im Fokus-Modus. Dazu Projekte, Kalender, Tagesplanung, Routinen, ein Papierkorb, aus dem man Dinge zurückholen kann, Sicherungen und signierte Updates für Windows.

Dann kam Stück für Stück mehr dazu: ein Bereich für meine eigenen Code-Projekte, eine Bibliothek für Gestaltungsvorlagen, eine Suche über alles.

Die Oberfläche ist komplett selbst gebaut. Kein fertiges Baukastensystem, sondern eigenes Raster, eigene Typografie, umschaltbare Akzentfarben, heller und dunkler Modus. Das war viel Arbeit, und genau daraus ist der Entschluss zum Neuaufbau entstanden.

EingangAlles Ungeordnete landet zuerst hier. Sortiert wird später.
AufgabenBoard, Timeline und Fokus-Modus, alle auf denselben Daten.
ProjekteHält zusammen, was zu einem Vorhaben gehört.
KalenderTag, Woche, Monat. Externe Kalender nur lesend.
EntwicklungMeine Code-Projekte mit Verbindung zu GitHub.
BibliothekGestaltungsvorlagen. Die Suche findet auch, was auf den Bildern steht.

Startseite der Fassung 1.7.2 mit Begrüßung, Tageslage und empfohlenem nächsten Schritt — **Start.** Was heute ansteht, in einem Satz. Darunter der Schritt, den die App als nächsten vorschlägt.

Aufgabenboard der Fassung 1.7.2 mit vier Spalten und Kennzahlen — **Aufgaben.** Vier Spalten mit den Zahlen darüber. Dieselben Aufgaben gibt es auch als Timeline und im Fokus-Modus.

Projektübersicht der Fassung 1.7.2 mit Gruppierung nach Dringlichkeit — **Projekte.** Oben steht, was mich braucht. Überfälliges zuerst, alles Laufende darunter.

Wochenkalender der Fassung 1.7.2 mit Tagesfokus in der Seitenspalte — **Kalender.** Wochenraster, daneben der Tag im Detail. Termine und Aufgaben desselben Tages nebeneinander.

Entwicklungsbereich der Fassung 1.7.2 mit Workspace-Liste und GitHub-Verbindung — **Entwicklung.** Meine Codebasen mit ihrem GitHub-Stand. Aus diesem Bereich ist der Neuaufbau entstanden.

Style-Bibliothek der Fassung 1.7.2 mit zwei Style-Kacheln — **Bibliothek.** Vorlagen samt Bildern. Ein Wort aus einer Bildbeschreibung findet den passenden Style.

Oberfläche

React 19 · TypeScript
Vite · Bundler
Eigenes Designsystem
lucide-react · Symbole

Rahmen & Kern

Tauri 2 · Desktop
Rust · Backend
SQLite · rusqlite
tokio · Nebenläufigkeit

Prüfung & Auslieferung

Vitest · 78 Testdateien
ESLint · eigene Regeln
Signierte Updates
GitHub als Update-Kanal

Der Neuaufbau

seit 26. August 2026 · im Bau

Die 1.7.2 funktioniert, aber sie ist an zwei Stellen teuer geworden. Ich habe Bedienelemente selbst nachgebaut, mitsamt Fokusführung, Überlagerungen und Tastatursteuerung. Und ich habe rund 600 Zeilen eigene Stil-Wächter geschrieben, damit die CSS nicht ausufert. Beides war Arbeit, die mir ein Werkzeug hätte abnehmen können.

Der Neuaufbau ist deshalb kein Umzug. Es ist ein zweiter Versuch mit drei Regeln: eine Sprache statt zwei, TypeScript vom Fenster bis zur Datenbank. Fertige, barrierefreie Bausteine als Grundlage (@base-ui/react), deren Aussehen von mir kommt. Und ein Designsystem aus Tokens, Bausteinen und Komponenten, statt Farbwerte irgendwo im Code stehen zu haben.

Eine Sache habe ich dabei umgedreht. Erst stand fest, wie das Programm aussehen soll: eigene Schrift, eigene Farben, eigenes Raster. Danach erst fiel die Entscheidung für die Technik. Native Windows-Bedienelemente wären der ruhigere Weg gewesen, aber wer sie ohnehin komplett umgestaltet, zahlt ihren Preis und bekommt ihren Vorteil nicht.

Eingangshalle des Neuaufbaus: nächtliches Bild mit Begrüßung und Datum — **Die Eingangshalle.** Der Start ist keine Übersicht, sondern eine Schwelle. Ein Bild, das sich mit der Tageszeit ändert, und ein Klick, der hineinführt. Beim Wechsel in die Projekte wächst das Bild zur Karte, statt dass die Seite umspringt. Das macht die View Transition API des Browsers.

Aufgabenboard des Neuaufbaus mit zwei offenen Spalten und einer eingeklappten — **Aufgaben.** Spalten lassen sich einklappen, die Gruppierung umschalten. Frist, Projekt und Dauer stehen auf der Karte nur dann, wenn es sie gibt.

Aufgabenboard mit geöffnetem Seitenpanel zur gewählten Aufgabe — **Panel statt Dialog.** Die gewählte Aufgabe öffnet sich seitlich. Das Board bleibt sichtbar und bedienbar.

Projektübersicht des Neuaufbaus mit einer orange hervorgehobenen Leitfläche — **Projekte.** Eine einzige Fläche trägt Farbe: das Projekt, das ohne mich nicht weitergeht. Der Rest bleibt still.

Projektseite des Neuaufbaus mit nächstem Schritt, Arbeitsliste und Standnotiz — **Projektseite.** Oben der nächste Schritt, darunter die Arbeit nach Zeit sortiert. Daneben zwei Sätze für mich selbst in vier Wochen.

Oberfläche

React 19.2 · TypeScript 7
Vite 8 · Bundler
Tailwind 4 · enger Rahmen
@base-ui/react · Primitives

Rahmen & Kern

Electron 44
node:sqlite · eingebaut
Haupt-, Preload-, Fensterprozess
electron-builder · Paket

Prüfung & Ablauf

Vitest · Fachlogik
Playwright · am Programm
Biome · Format & Regeln
lefthook · vor dem Commit

Vorher, nachher

Dieselben drei Ansichten in beiden Fassungen. Umschalten statt untereinanderlegen, dann sieht man, was sich wirklich geändert hat: weniger Rahmen, klarere Hierarchie, und Farbe nur dort, wo sie etwas bedeutet.

Startseite der Fassung 1.7.2 — Start · Fassung 1.7.2 — Begrüßung, Tageslage und ein vorgeschlagener nächster Schritt auf einer Seite.

Eingangshalle des Neuaufbaus — Start · Neuaufbau — eine Schwelle statt einer Übersicht: ein Bild, das der Tageszeit folgt, und ein Klick hinein.

Aufgabenboard der Fassung 1.7.2 — Aufgaben · Fassung 1.7.2 — vier Spalten, Kennzahlen darüber, Filter für Projekt und Priorität.

Aufgabenboard des Neuaufbaus — Aufgaben · Neuaufbau — dieselbe Arbeit, weniger Rahmen: einklappbare Spalten, umschaltbare Gruppierung, Angaben nur dort, wo es sie gibt.

Projektübersicht der Fassung 1.7.2 — Projekte · Fassung 1.7.2 — nach Dringlichkeit gruppiert, in Karten gleicher Gewichtung.

Projektübersicht des Neuaufbaus — Projekte · Neuaufbau — eine einzige Fläche trägt Farbe: das Projekt, das ohne mich nicht weitergeht.

Start, Fassung 1.7.2. Begrüßung, Lage des Tages und ein Vorschlag, was als Nächstes drankommt. Bild anklicken zum Umschalten

Wie ich arbeite

Der Ablauf ist mir so wichtig wie das Ergebnis. Ich arbeite allein, es schaut niemand über meine Pull Requests.

Ein Arbeitspaket, ein Zweig Jede Änderung läuft auf einem eigenen Zweig. Zusammengeführt wird erst, wenn der volle Durchlauf grün ist.
Prüfungen vor dem Festschreiben Ein Haken formatiert die vorgemerkten Dateien und lässt die betroffenen Tests laufen. Dafür hat er zehn Sekunden. Was länger dauert, wandert in den vollen Durchlauf, statt dass ich die Grenze anhebe.
Getestet wird am laufenden Programm Neben den Fachtests startet Playwright das gebaute und das fertig gepackte Programm und bedient es wie ein Mensch. Fehler in Übergängen und Fokusführung zeigen sich sonst nirgends.
Entscheidungen werden aufgeschrieben Zu jedem Baustein steht in einem eigenen Wiki, was entschieden wurde, warum, und was dagegen sprach. Ein Commit sagt mir nur, was ich geändert habe. Nach drei Wochen weiß ich nicht mehr, weshalb.
Fertig heißt abgenommen Vier Stufen: gebaut, geprüft, abgenommen, ausgeliefert. Fertig ist erst, was ich am laufenden Programm selbst durchgegangen bin.

Der Stapel im Vergleich

Frage	Fassung 1.7.2	Neuaufbau
Desktop-Rahmen	Tauri 2 mit Rust-Backend	Electron 44, Haupt- und Fensterprozess getrennt
Sprachen	Rust und TypeScript	Nur TypeScript, vom Fenster bis zur Datenbank
Oberfläche	React 19, eigenes Designsystem, selbst gebaute Bedienelemente	React 19.2, Tailwind 4 im engen Rahmen, `@base-ui/react` als Grundlage
Daten	SQLite über `rusqlite`, Zugriff nur über benannte Befehle	SQLite über `node:sqlite`, ein einziges Verbindungsmodul
Prozessgrenze	249 benannte Tauri-Befehle; die Oberfläche greift nie direkt zu	`contextBridge` mit typisierten Kanälen, kein Node im Fenster
Tests	Vitest, 78 Testdateien	Vitest für die Fachlogik, Playwright am gebauten und am gepackten Programm
Werkzeuge	ESLint, eigene Prüfskripte	Biome, lefthook, electron-builder

Eine Eigenheit fällt beim Blick in den Code sofort auf: Ordner, Dateien und Bezeichner sind auf Deutsch benannt. src/ablage, src/renderer/huelle, projektAnlegen. Das ist Absicht bei einem Programm, dessen Oberfläche und Dokumentation durchgehend deutsch sind. Ein Begriff, überall derselbe, ohne dass ich im Kopf übersetzen muss. In einem Team mit englischer Codebasis würde ich es selbstverständlich anders halten.