DailyHorse: Ein lokales Work OS für den Arbeitsalltag

Das Problem: Arbeit verteilt sich auf zu viele einzelne Oberflächen#

Ein normaler Entwicklungs- und Redaktionstag beginnt selten in nur einer Anwendung. Projektdateien liegen im Dateimanager, ein Serverzugang in einem SFTP-Client, Aufgaben in einem Terminal, Research in Browser-Tabs, Termine im Kalender und Kennzahlen bei verschiedenen Plattformen. Dazu kommen Mail, Geräte und die Frage, ob die lokale Entwicklungsumgebung gerade überhaupt sauber läuft.

Keine dieser Anwendungen ist überflüssig. Das Problem entsteht zwischen ihnen: Kontext geht verloren, der nächste sinnvolle Schritt ist nicht sichtbar und dieselben Informationen werden immer wieder zusammengesucht.

DailyHorse ist als lokale Arbeitsoberfläche für genau diese Lücke entstanden. Es versucht nicht, eine IDE, einen Mailclient, einen Browser oder FileZilla nachzubauen. Stattdessen fasst es die relevanten Signale und kontrollierten Aktionen in einem gemeinsamen täglichen Kontext zusammen.

Was DailyHorse ist – und was nicht#

DailyHorse ist ein local-first Dashboard für eine einzelne Arbeitsmaschine. Die Weboberfläche läuft lokal, der Fastify-Backenddienst ebenfalls. Daten, Tokens und lokale Arbeitszustände bleiben auf dem Rechner, soweit eine aktivierte Integration sie nicht für ihren jeweiligen Dienst benötigt.

Das Projekt ist kein gehosteter Teamdienst und kein Remote-Administrationswerkzeug. Die Oberfläche bindet bewusst nur an Loopback. Diese Einschränkung ist Teil des Konzepts: Ein Dashboard, das lokale Terminal-, Datei- und Geräteaktionen bündeln kann, gehört nicht ungeschützt ins Netzwerk.

Das Ergebnis ist eher ein persönliches Work OS als ein weiteres SaaS-Dashboard: ruhig, technisch und auf die Frage ausgerichtet, was heute Aufmerksamkeit braucht.

Die Today-Ansicht: Arbeit sichtbar machen#

Die Startansicht ist kein Activity Feed. Sie bündelt die Bereiche, die im Tagesverlauf tatsächlich Entscheidungen auslösen:

• Projekte halten zusammengehörige Aufgaben und Research-Einträge zusammen.
• Research Queue sammelt Themen und Links, bevor sie in der täglichen Arbeit verloren gehen.
• Attention Center zeigt Aufgaben mit Klärungsbedarf, relevante Ereignisse und noch nicht eingerichtete Integrationen.
• Agentenarbeit nimmt Aufgaben für OpenCode entgegen und macht den Warteschlangenstatus sichtbar.
• Mail und Kalender bleiben bewusst auf einen kompakten, lesenden Überblick begrenzt.
• Systemübersicht zeigt CPU, Arbeitsspeicher, Home-Datenträger, Netzwerkdurchsatz, Uptime und den lokalen Dashboard-Service.

Wichtig ist dabei die Semantik: Nicht verfügbare Daten werden nicht durch plausible Zahlen ersetzt. Ein Sensor, eine Integration oder eine Berechtigung ist entweder verfügbar, nicht eingerichtet oder aktuell nicht erreichbar.

OpenCode und Terminal im selben Arbeitskontext#

Für Entwicklungsarbeit bringt DailyHorse einen lokalen Command Center mit. Mehrere OpenCode-Sitzungen können verwaltet, Aufgaben eingereiht und Statuswechsel nachvollzogen werden. Daneben gibt es ein interaktives Shell-Terminal auf PTY-Basis.

Die Oberfläche verwaltet dabei nicht die Berechtigungen von OpenCode selbst. Sie startet lokale Prozesse, hält Sitzungs- und Aufgabenmetadaten vor und behandelt Neustarts konservativ: Läuft ein Prozess beim Neustart des Begleitdienstes nicht mehr nachweisbar weiter, wird kein falscher Erfolgsstatus angezeigt.

Das ist absichtlich weniger spektakulär als ein angeblicher autonomer Agentenmodus – und im Alltag nützlicher. Sichtbarer Status, Queue, Ausgabe und ein klarer Punkt für menschliche Prüfung sind verlässlicher als erfundene Fortschrittsanzeigen.

Dateien: lokaler Projektbaum und SFTP nebeneinander#

Der Dateien-Workspace verbindet zwei getrennte Sicherheitsbereiche: freigegebene lokale Roots und konfigurierte Remote-Verbindungen.

Auf der lokalen Seite werden nicht automatisch beliebige Systempfade geöffnet. Roots werden bewusst freigegeben, gegen Traversal geprüft und über kanonische Pfade abgesichert. Symbolische Links werden vorsichtig behandelt, damit ein Eintrag innerhalb eines Projektordners nicht unbemerkt aus dem erlaubten Bereich herausführt.

Auf der Server-Seite arbeitet DailyHorse mit SFTP. Die Oberfläche zeigt lokalen und entfernten Verzeichnisinhalt nebeneinander, inklusive Breadcrumbs, Sortierung und bewusst ausgelöster Aktualisierung. Remote-Pfade werden als POSIX-Pfade normalisiert; das verhindert kosmetische und semantische Fehler wie doppelte Slashes beim Wechsel zwischen Root und Unterordnern.

Ein Production-Ziel wird sichtbar gekennzeichnet. Transfers sollen nicht wie ein automatisches Deployment wirken: Bestehende Dateien dürfen nicht still überschrieben werden, und ein konfigurierter Zugang bedeutet nicht automatisch, dass jede Aktion sinnvoll ist.

SFTP-Zugangsdaten ohne Klartext in der Anwendung#

Für passende Linux-/KDE-Setups kann DailyHorse SFTP-Passwörter über KDE Wallet verwalten. Die Architektur trennt die Browseroberfläche vom Secret:

DailyHorse UI
        │
        ▼
Local Fastify backend
        │
        ▼
small local DBus helper
        │
        ▼
KDE Wallet

Das Passwort wird nicht in SQLite, Browser Storage oder Prozessargumenten abgelegt. Der Backenddienst kann es nur für die unmittelbar benötigte SFTP-Authentifizierung lesen. Die SFTP-Verbindung prüft Server-Host-Keys gegen die lokale known_hosts-Vertrauensbasis; unbekannte oder geänderte Schlüssel werden nicht automatisch akzeptiert.

Das ist kein allgemeiner Secrets-Manager. Es ist eine eng begrenzte lokale Integration für Connection Profiles.

GitHub: nicht nur Repository-Metadaten#

Die GitHub-Integration kann neben vorhandenen Repository- und Interaktionsdaten auch die offiziellen Traffic Views je Repository synchronisieren. Die Today-Card Top Repositories ordnet Repositories nach echten Views aus dem verfügbaren GitHub-Traffic-Fenster und zeigt ergänzend Unique Visitors.

Die Einschränkung ist wichtig: GitHub liefert Traffic nur für passende Repository-Berechtigungen und nur für ein begrenztes Zeitfenster. Fehlt diese Capability, zeigt DailyHorse nicht ersatzweise Sterne, Clones oder Interaktionen als vermeintliche Views. Eigene Snapshots können dagegen langfristig eine lokale Historie aufbauen, sobald sie tatsächlich gesammelt wurden.

Browser, Research und Editorial#

Die Chromium-Erweiterung macht DailyHorse als New-Tab-Oberfläche und Side Panel erreichbar. Sie kann offene Tabs anzeigen und gespeicherte Seiten in Ordnern organisieren. Gespeicherte Seiten bleiben in chrome.storage.local; eine externe Browser-Historie oder breite Host-Berechtigungen sind dafür nicht nötig.

Research-Einträge leben im Dashboard als kleine Queue. Der separate Editorial-Workspace bleibt dagegen für den eigentlichen Publishing-Workflow zuständig: Quellen, Entwürfe, Markdown, statischer Build, SEO und Social-Metadaten. DailyHorse zeigt den Kontext und verlinkt den Workspace, ersetzt aber nicht dessen redaktionelle Regeln.

Geräte und lokale Systemgesundheit#

Über KDE Connect kann DailyHorse bereits gekoppelte, erreichbare Geräte erkennen und kontrollierte Aktionen anbieten: Dateien, Links oder Zwischenablage-Inhalte übergeben sowie ein Gerät klingeln lassen, wenn die jeweilige Fähigkeit verfügbar ist. Pairing, Transport und Verschlüsselung bleiben vollständig bei KDE Connect.

Die System-Card ist bewusst keine htop-Kopie. Sie zeigt wenige aussagekräftige Werte: CPU-Auslastung und Load, Linux-konform interpretierten Speicher, den relevanten Home-Datenträger, optional verfügbare Temperaturwerte, Netzwerkdeltas, Uptime und den Status des lokalen Dashboard-Services.

Die technische Architektur#

Chromium extension / DailyHorse web UI
                  │
                  ▼
          Local Fastify backend
          │         │          │
          ▼         ▼          ▼
       SQLite      PTYs     Providers
                   │          │
                OpenCode   GitHub, Google, IMAP
                             KDE Connect, SFTP

React und Vite bilden die Oberfläche, Fastify die lokale API, SQLite hält Arbeits- und Synchronisationszustand. Provider werden über klar begrenzte Connectoren synchronisiert; das Dashboard liest anschließend lokale Daten, statt bei jedem Render externe APIs abzufragen.

Local first als praktische Entscheidung#

Local first ist hier keine pauschale Datenschutzformel. Es beschreibt konkrete Grenzen:

• Der Dienst ist für 127.0.0.1 gedacht, nicht für eine öffentliche Serverbereitstellung.
• Tokens und Provider-Credentials bleiben serverseitig auf der lokalen Maschine.
• Workspace-Steuerung benötigt eine lokale, kurzlebige Session.
• IMAP wird im Dashboard bewusst read-only verwendet.
• Unklare Daten werden als nicht verfügbar dargestellt.
• Es gibt keine generische API zum Ausführen beliebiger Shell-Kommandos.

Wer DailyHorse nutzen möchte, braucht deshalb eigene Zugänge für die gewünschten Integrationen. Nicht alles muss verbunden sein: Ein leerer Connector ist ein ehrlicher Zustand und keine kaputte Demo.

Für wen das Projekt gedacht ist#

DailyHorse richtet sich an Menschen, die Entwicklung, Inhalte, Projekte und lokale Infrastruktur auf einer Linux-Arbeitsmaschine zusammenführen möchten. Besonders passend ist es dort, wo ein Browser-Tab nicht nur Recherche bedeutet, sondern der Einstieg in den nächsten Arbeitsschritt sein soll.

Der Quellcode, die Installationshinweise und die aktuelle Feature-Liste liegen im öffentlichen Repository:

https://github.com/Grenoullie91/DailyHorse

Fazit#

DailyHorse ersetzt keine spezialisierten Werkzeuge. Gerade deshalb bleibt der Anspruch überschaubar: die relevanten Informationen und bewussten Aktionen in einem lokalen, nachvollziehbaren Arbeitskontext zusammenzubringen.

Für den Arbeitsalltag ist das oft wertvoller als eine weitere große Plattform – weil der Weg von „Ich muss etwas erledigen“ zu „Hier ist der passende nächste Schritt“ kürzer wird.