Das Produktproblem.
Karriereinformationen verteilen sich häufig auf alte Lebensläufe, Jobportale, Notizen und Bewerbungsplattformen. Allgemeine AI-Werkzeuge schaffen ein weiteres Problem: Eine überzeugend formulierte Antwort kann den Bezug zu dem Fakt verlieren, der sie stützt.
Der erste Start setzt dort an, wo viele Menschen bereits stehen: bei einem vorhandenen Lebenslauf. CareerOS legt zuerst den kleinsten gültigen und revisionsgeführten Profildatensatz an, importiert das Dokument lokal innerhalb fester Grenzen und lässt jeden extrahierten Eintrag unbestätigt. Danach landet der Benutzer direkt in der Faktenprüfung, nicht in einem halbfertigen Konto oder bei einem unerklärten Fehler.
Was das System schützen muss.
Die Architektur folgt vier Produktvorgaben:
- Private Karrieredaten, generierte Dokumente und Analysen bleiben auf dem Gerät.
- LLM-gestütztes Matching und Coaching erfordern eine freigegebene lokale Laufzeit; es gibt keinen Rückfall auf ein Cloud-Modell.
- Generierte Vorschläge dürfen Quelldaten oder deren Revisionsverlauf nicht stillschweigend ersetzen.
- Backups, Exporte und Löschung müssen strukturierte Datensätze und lokale Artefakte gemeinsam und konsistent erfassen.
Die Designentscheidung.
Die schwierige Aufgabe war nicht, ein Chatfenster hinzuzufügen. Sie bestand darin, Belege, deterministischen Workflow-Zustand und Modellinterpretation sauber zu trennen. Diese drei Bereiche haben unterschiedliche Fehlerbilder und gehören nicht in eine unscharfe Datenstruktur.
Ich habe sie in einen Karriere-Tresor, reproduzierbare Bereitschafts- und Bewerbungsdatensätze sowie schemageprüfte lokale Analyse-Pipelines getrennt. Die Oberfläche kann dadurch zeigen, woher eine Schlussfolgerung stammt und welche Korrektur in den Quelldatensatz gehört.
Eine überwachte lokale Laufzeit.
Tauri betreibt die Desktop-Shell und überwacht einen FastAPI-Sidecar auf der Loopback-Schnittstelle. React stellt den Arbeitsbereich bereit, SQLite und lokale Artefakte speichern den dauerhaften Datensatz, und eine verwaltete llama.cpp-kompatible Laufzeit führt die verpflichtende LLM-Analyse aus, ohne selbst zur Speicherschicht zu werden.
Warum diese Technologien.
Jede Komponente hält das Produkt lokal, prüfbar und mit vertretbarem Aufwand auslieferbar.
Tauri als Desktop-Shell.
- Warum
- Es passt zu einer lokalen Anwendung, die native Fenster, Dateien und die Überwachung von Diensten integrieren muss, ohne einen vollständigen Browser mitzuliefern.
- Was ich ausgeschlossen habe
- Electron würde Gewicht und Laufzeitoberfläche vergrößern; eine reine Browser-Lösung könnte Sidecar und lokale Artefakte nicht ebenso zuverlässig steuern.
- Der Preis dafür
- Dafür nehme ich eine zusätzliche Rust-Grenze und plattformspezifische Paketierung in Kauf.
Ein FastAPI-Sidecar für die Anwendungsdienste.
- Warum
- Dokument- und Analyseabläufe bleiben in Python, werden der Shell aber über eine enge, prüfbare Loopback-API bereitgestellt.
- Was ich ausgeschlossen habe
- Alles in Rust neu zu schreiben würde das Python-Ökosystem nachbauen; Logik im Browser würde die Kontrolle über lokale Daten schwächen.
- Der Preis dafür
- Damit muss ich einen zweiten Prozess starten, überwachen und versionieren.
SQLite als versionierter Datenspeicher.
- Warum
- Transaktionen, Migrationen und eine einzelne Datei passen zu einem lokal verwalteten persönlichen Arbeitsbereich statt zu einem gemeinsam gehosteten Dienst.
- Was ich ausgeschlossen habe
- Ein lokaler Datenbankserver brächte einen zusätzlichen Administrationsprozess und Zugangsdaten mit sich; ein Cloud-Speicher eine Netzwerk- und Anbietergrenze. Für einen gemeinsam genutzten Dienst besteht im Projektumfang jedoch keine Anforderung, die eine der beiden Optionen lösen würde.
- Der Preis dafür
- Die Kehrseite sind begrenzte Parallelität und die Verantwortung für lokale Migrationen und Sicherungen.
Eine lokale, mit llama.cpp kompatible Laufzeit.
- Warum
- Die Analyse bleibt innerhalb der erklärten Gerätegrenze und lässt sich auf freigegebene Modelle und Aufgaben beschränken.
- Was ich ausgeschlossen habe
- Eine Cloud-LLM-API würde Karrieredaten vom Gerät übertragen und Datenschutz sowie Verhalten von einem entfernten Dienst abhängig machen.
- Der Preis dafür
- Das verlangt Ersteinrichtung, passende Hardware und Geduld bei lokaler Latenz; nicht jedes Modell wird unterstützt.
Entscheidungen, die daraus ein echtes Werkzeug machen.
Die nützliche Arbeit geschieht vor und nach dem Modellaufruf.
Den Datensatz vor dem Lebenslauf-Import anlegen
Der erste Start erzeugt einen minimalen revisionsgeführten Profildatensatz und führt erst danach einen begrenzten lokalen Import aus. Extrahierte Fakten bleiben Kandidaten, bis der Benutzer sie prüft. Der Lebenslauf beschleunigt damit die Einrichtung, ohne zur ungeprüften Wahrheit zu werden.
Der ZielkonfliktDas Onboarding braucht einen ausdrücklichen Prüfschritt. Dafür hinterlässt eine fehlgeschlagene oder unvollständige Extraktion keinen mehrdeutigen Tresorzustand.
Private Änderungen zuerst protokollieren
Zurücksetzen, Wiederherstellung, Löschung, Migrationen und private Dateien halten zuerst eine begrenzte Absicht fest. Die Wiederaufnahme prüft über stabile Dateideskriptoren Identität, Größe und Digest.
Der ZielkonfliktWartung braucht zusätzliche Wiederherstellungslogik; dafür hinterlassen Neustart oder mehrdeutiger Commit keine unbemerkte Teiloperation.
Agenten einen getrennten Lesezugang geben
Agent Access lässt den angemeldeten Benutzer Geltungsbereiche wählen und verlangt vor der einmaligen Ausgabe eines Bearer-Tokens eine erneute Anmeldung. Berechtigungen laufen ab und sind widerrufbar. Die installierbare CLI und der MCP-Server stellen über stdio einen geschlossenen Satz schreibgeschützter Werkzeuge bereit, keine freien Prompts oder entfernte Schreib-API.
Der ZielkonfliktDer Benutzer muss den Agent-Client weiterhin einrichten, und ein externer Client kann gelesene Daten übertragen. Der enge Vertrag ermöglicht nützliche Automatisierung, ohne die Desktop-Sitzung zu teilen.
Wie das Produkt verifiziert wird.
Für v1.11.1 bestanden 2.194 Backend-Tests bei 7 erwarteten Skips und 81,91 % Gesamtabdeckung einschließlich Verzweigungen. Hinzu kamen 476 Frontend-Tests in 79 Dateien und 27 Rust-Tests. Migration, Archiv, Journale, Wiederherstellung und konkurrierende Veröffentlichung sind in Fehlerszenarien geprüft.
Protected-Branch-CI, CodeQL und Containerprüfungen sind am Commit 96ca0f8 grün. Probelauf und signierter Tag bauten und prüften jeweils sechs native Pakete; dieselben Wheel-Bytes liefen unter Linux, macOS und Windows mit Python 3.12 und 3.13. Das unveränderliche Release veröffentlicht 26 digestgebundene Artefakte.
Was heute vorhanden ist.
v1.11.1 liefert eine funktionsfähige Desktop-Utility mit CV-Einrichtung, Career Vault, geführter Suche, Job Library, Bewerbungszeitleisten, Lebenslauf-Studio, Archiv v6 und lokaler Analyse. Zurücksetzen, Wiederherstellung, Löschung, Migrationen und private Dateien sind neustartfest wiederherstellbar.
Rotierende Sitzungsfamilien, ausfallsichere Konfiguration und strenge lokale Antwortgrenzen schützen Loopback. Öffentliche Diagnostik ist inhaltsfrei; Forced-Colors-, Tastatur- und WCAG-Prüfungen decken Anmeldung und Agent Access auf Englisch und Italienisch responsiv ab.
Die authentifizierte Desktop-App verwaltet nun Berechtigungen für sieben schreibgeschützte Operationen, die eine per Bearer-Token authentifizierte CLI und ein MCP-Server über stdio bereitstellen. Beide Befehle sind im Release-Wheel enthalten. Codex, Claude Code und Shell-Skripte können eine bewusst kleine Ansicht eines autorisierten Kontos lesen, aber weder den Tresor ändern noch freie Prompts aufrufen oder einen entfernten Transport öffnen.
Das Produkt behauptet nicht, ein LLM könne eine Karriere entscheiden. Das Modell hilft, einen eigenen Belegbestand auszuwerten; Datensatz, Quelle und letzte Entscheidung bleiben beim Benutzer.
Evidenzprotokoll.
Das aktuelle Repository dokumentiert diese reproduzierbaren Prüfungen und Grenzen:
- Backend
- In der Release-Suite für v1.11.1 bestanden 2.194 Backend-Tests; 7 wurden erwartungsgemäß übersprungen. Die Gesamtabdeckung betrug 81,91 %, Verzweigungen eingeschlossen.
- Frontend + Shell
- Alle 476 Frontend-Tests in 79 Dateien und 27 Rust-Tests bestehen. Lizenz-, Symbol-, Bundle-, Browser-, Container- und Supply-Chain-Verträge laufen auf demselben Release-Commit.
- Neustartfeste Wiederherstellung
- Persistierte Zustände und begrenzte Journale mit Prüfsummen lassen Zurücksetzen, Wiederherstellung, Löschung, Migrationen und private Dateien nach einem Neustart konvergieren, ohne unbegrenzten Pfaden oder Nutzdaten zu vertrauen.
- Sitzungen und Diagnostik
- Einmalige Refresh-Rotation gehört zu persistierten Sitzungsfamilien; Replay widerruft die Familie und Wartungssitzungen bleiben vom Arbeitsbereich getrennt. Öffentliche Such- und Laufzeitdiagnostik kommt nur aus einem geschlossenen, inhaltsfreien Register.
- Agentenzugriff
- Die Desktop-App erteilt begrenzte, widerrufbare Berechtigungen für sieben schreibgeschützte Operationen über CLI und MCP-Server. Das Release liefert beide Befehle als installierbares Python-Wheel, zeigt das Bearer-Token einmal und speichert nur dessen Digest.
Geprüftes Release v1.11.1 Geprüft am
Diese Fallstudie beschreibt das unveränderliche Release v1.11.1 am Commit 96ca0f8. Signierter Tag und 26 Artefakte folgen einem Probelauf auf sechs nativen Zielen und sechs Agent-Access-OS/Python-Kombinationen. Prüfsummen und GitHub-Provenienz binden die Bytes; native Pakete bleiben unsignierte Community-Builds ohne Plattformsignatur oder Notarisierung. Behauptet werden weder Beschäftigungsergebnisse noch Modellgenauigkeit oder universelle Hardwareunterstützung.