Anubis
Anubis ist eine Desktop-Anwendung für Verfahren, die sich über Wochen ziehen und an einer Frist hängen: Freischaltungen bei Plattformen, OAuth-Verifizierungen, Compliance-Audits, Einsprüche, oder einfach, um Passwörter und Zugangsdaten für ein Projekt abzulegen. Verfahren, Korrespondenz, Fristen, Verträge und Zugangsdaten liegen an einer Stelle, lokal.
Über das Projekt
Lokale Desktop-Anwendung für Plattform-Verfahren wie OAuth-Verifizierungen, Compliance-Audits und Einsprüche: Verfahren mit Status und Frist, der komplette Nachrichtenverlauf, Dokumente, AVVs und API-Keys an einer Stelle, lokal auf dem eigenen Rechner und ohne Cloud, die Zugangsdaten verschlüsselt. E-Mails kommen als .eml-Datei in den Verlauf, hinaus gehen Vorgangsakten als Markdown und Fristen als abonnierbarer Kalender. Ein mitgelieferter MCP-Server öffnet denselben Datenbestand für KI-Assistenten, ohne Secrets herauszugeben.
Funktionen im Überblick
- Verfahren mit Status-Workflow, Referenznummer und Frist
- Nachrichtenverlauf je Verfahren, ein- und ausgehend
- Dokumenten-Vault mit SHA-256-Prüfsumme und Textextraktion aus PDF, DOCX und Textdateien
- API-Keys verschlüsselt gespeichert, Klartext nur per protokollierter Aktion
- E-Mail-Import: eine .eml wird zur Nachricht, Anhänge werden zu Dokumenten am selben Verfahren
- Textbausteine für wiederkehrende Schreiben, Platzhalter füllt Anubis aus dem Verfahren
- Vorgangsakte als Markdown-Export, Fristen als abonnierbarer Kalender
- Volltextsuche, Fristen-Erinnerungen und ein Backup bei jedem Start, das sich zurückspielen lässt
- MCP-Server für KI-Assistenten: lesend und sicher schreibend, ohne Secret-Zugriff
Warum ich es gebaut habe
Wer eine App bei einer großen Plattform freischalten lassen will, sammelt schnell einen unübersichtlichen Stapel: Tickets in fremden Portalen, E-Mail-Verläufe, angeforderte Screenshots, unterzeichnete Auftragsverarbeitungsverträge und ein Bündel API-Keys, und das für mehrere Projekte parallel. Dasselbe Muster entsteht überall dort, wo ein Verfahren über Wochen läuft und an einer Frist hängt. Der Ärger kommt dabei selten von der Technik, sondern daher, dass eine Frist verstreicht oder niemand mehr weiß, was in welchem Verfahren zuletzt geantwortet wurde. Anubis ist meine Antwort darauf, ein Archiv, das den Stand jedes Verfahrens kennt und beim Start eine Systembenachrichtigung schickt, wenn etwas überfällig ist oder in den nächsten Tagen fällig wird.
Verfahren und Korrespondenz
Jedes Verfahren hat Plattform, Art, Referenznummer, Frist und einen Status-Workflow von „Entwurf" über „Eingereicht" und „In Prüfung" bis zur Entscheidung. Daran hängt der vollständige Nachrichtenverlauf in beide Richtungen, jeweils mit dem tatsächlichen Datum statt dem Importzeitpunkt. Das Dashboard beantwortet die einzige Frage, die morgens zählt: Was ist überfällig, was wird in weniger als sieben Tagen fällig, wo warte ich auf Antwort. Eine Volltextsuche über Verfahren, Korrespondenz und Dokumente findet den einen Satz wieder, den man drei Monate später zitieren muss, und liest dabei auch den extrahierten Text der Dokumente mit, nicht nur deren Dateinamen. Eine gespeicherte .eml-Datei wandert als Nachricht in den Verlauf, ihre Anhänge werden zu Dokumenten am selben Verfahren; das geschieht zweistufig, erst die Vorschau, die nichts schreibt, dann die Übernahme, und steht die Vorgangsnummer im Betreff, schlägt Anubis das passende Verfahren gleich vor. Ein IMAP-Zugang ist bewusst nicht vorgesehen: Die Anwendung verspricht, dass nichts den Rechner verlässt, und eine Postfachverbindung wäre keine Funktion, sondern eine andere Architektur.
Dokumente und Zugangsdaten
Dokumente wandern per Drag & Drop in einen lokalen Vault, bekommen eine SHA-256-Prüfsumme und werden mit Dateirechten 0600 abgelegt; aus PDF, DOCX und Textdateien wird der Text extrahiert, damit die Suche sie mitliest. API-Keys ruhen verschlüsselt, über den Schlüsselbund des Systems, ersatzweise über ein Master-Passwort mit argon2id und AES-256-GCM. Angezeigt wird grundsätzlich maskiert; Klartext gibt es nur über eine ausdrückliche Aktion, und die landet in der Aktivitätsliste. Es geht nichts nach außen: keine Telemetrie, kein Konto, keine Cloud.
Vorlagen, Akte und Fristenkalender
Wiederkehrende Schreiben, Widerspruch, Nachfassen, Bitte um Fristverlängerung, liegen als Textbausteine bereit. Beim Einsetzen füllt Anubis die Platzhalter aus dem Verfahren, also Projekt, Titel, Referenz, Frist, Einreichdatum und Status. Ein Platzhalter ohne Wert verschwindet, sonst ginge eine leere Referenz in genau dieser Form an die Plattform hinaus; ein unbekannter bleibt dagegen stehen, weil er ein Tippfehler in der Vorlage ist und auffallen soll. Ein Verfahren lässt sich als Akte exportieren, eine einzelne Markdown-Datei mit Kopfdaten, der Korrespondenz in zeitlicher Ordnung, einer Dokumententabelle samt Prüfsummen und dem Verlauf; die Nachrichtentexte stehen darin als Zitat, damit Markdown aus einer fremden Mail die Struktur der Akte nicht zerlegt. Und weil ein Fristenüberblick nur hilft, solange das Fenster offen ist, schreibt Anubis auf Wunsch eine Kalenderdatei neben die Datenbank: offene Verfahrensfristen und AVV-Wiedervorlagen als Ganztagstermine mit Erinnerung zwei Tage vorher. Einmal im Kalender abonniert, hält jeder weitere Export sie aktuell. Das ersetzt eine Kalenderansicht in der Anwendung, die dieselben Daten nur ein zweites Mal anders zeigen würde.
Technische Umsetzung
Anubis ist eine Tauri-Anwendung, bei der ein Kern in Rust die Datenhoheit behält. Die Oberfläche, ein statisch exportiertes Next.js-Bundle mit Tailwind, hat weder Datenbank- noch Dateizugriff, alles läuft über getypte Kommandos. Gespeichert wird in SQLite über rusqlite im WAL-Modus. Schema, Migrationen, Repositories, Verschlüsselung und Dateispeicher liegen in einer eigenen Crate, die sich die App mit dem MCP-Server teilt, sodass die Abfragen nur an einer Stelle stehen. Angefangen hat das Ganze unter Electron; der Umstieg hat das Backend nach Rust geholt, ohne das Schema anzufassen, sodass bestehende Vaults ohne Migration weiterlaufen. Dazu kommen die üblichen Härtungen: eine strenge CSP ohne fremde Quellen, keine Asset-Freigabe für die Webview, weshalb Dokumente im Programm des Systems statt in der Oberfläche aufgehen, und ein eng gefasstes Rechteprofil für die Kommandos.
MCP-Server für KI-Assistenten
Zum Projekt gehört ein eigenständiger MCP-Server, über den ein KI-Assistent denselben Datenbestand lesen und kontrolliert fortschreiben kann: Verfahren anlegen, Status setzen, Nachrichten protokollieren. Weil MCP ein offenes Protokoll ist, hängt das an keinem bestimmten Anbieter; entwickelt und im Alltag eingesetzt habe ich es mit Claude. Die Grenze ist fest verdrahtet statt konfigurierbar. Der Server kennt kein Feld für Secret-Klartext und kein Werkzeug, um eines anzuzeigen, und jede Schreiboperation landet in der Aktivitätsliste unter dem Namen, den der Client beim Verbinden angibt, wobei die Kennung für den Menschen am Gerät reserviert bleibt, damit später unterscheidbar ist, wer geschrieben hat. Das ist die Bauweise, die ich auch für Kundenprojekte empfehle, wenn ein Assistent Zugriff auf echte Daten bekommen soll: Was er nicht darf, steht im Code des MCP-Servers, der die Werkzeuge bereitstellt, und nicht im Systemprompt, den man dem Modell mitgibt. Ein Verbot im Prompt ist eine Bitte, über die ein Modell hinweggehen kann; ein Werkzeug, das der Server gar nicht erst anbietet, lässt sich nicht aufrufen.
Weitere Projekte
Ein ähnliches Projekt im Kopf?
Was in meinen eigenen Produkten steckt, entwickle ich genauso für Ihr Vorhaben, von der Idee bis zum laufenden Betrieb.