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.
CareerOS Local wurde zuerst als belastbares Arbeitsprotokoll entworfen. Erfahrung, Ausbildung, Fähigkeiten und Erfolge behalten Herkunft, Prüfstatus und Revisionsverlauf. Das LLM analysiert diesen eigenen Datenbestand für Matching und Coaching, statt ein zweites, losgelöstes Profil zu erfinden.
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.
Entscheidungen, die daraus ein echtes Werkzeug machen.
Das nützliche Produkt ist der vollständige Arbeitsablauf rund um das Modell.
Herkunft im Datensatz bewahren
Karrierefakten behalten Quelle, Prüfstatus und Revisionen. Lebenslaufinhalte und Bewerbungsbelege können auf diesen Datensatz zurückverweisen.
Das verlangt mehr Struktur als ein Freitextprofil, ermöglicht dafür aber Korrekturen und Audits.
Lokale Analyse voraussetzen
Opportunity-Matching und Coaching bleiben gesperrt, bis die freigegebene lokale Laufzeit bereit ist. Die Anwendung sendet die Aufgabe nie als bequemen Fallback an ein entferntes Modell.
Die Ersteinrichtung ist aufwendiger und die Hardware spielt eine Rolle; die Datenschutzgrenze bleibt dafür ehrlich.
Bewerbungen als Belege paketieren
Versionierte Lebensläufe, Antworten, Anforderungszuordnungen und geprüfte Dateien lassen sich mit einem kanonischen SHA-256-Manifest exportieren.
Ein Dossier ist bewusster aufgebaut als ein Ordner mit losen Dateien; dafür ist es reproduzierbar und prüfbar.
Wie das Produkt verifiziert wird.
Das Repository testet Python-Dienste, React-Verhalten und die Rust-Desktop-Integration. Datenbankmigrationen durchlaufen Upgrade-, Downgrade- und erneute Upgrade-Zyklen. Backup-Tests prüfen die Versionen 1–4 ohne Änderungen und testen danach Austausch, Korruptionserkennung und verifizierten Rollback mit kurzlebigen lokalen Daten.
Die Release-Automatisierung prüft außerdem Abhängigkeitslizenzen, SBOMs, Container und die Richtlinie für schwerwiegende Schwachstellen. Produkt-Touren werden in der echten Anwendung mit fiktiven Daten aufgenommen; der Recorder verwirft Browserfehler, fehlgeschlagene API-Antworten und sichtbare Warnungen.
Was heute vorhanden ist.
CareerOS Local ist eine funktionsfähige Desktop-Utility mit Karriere-Tresor, Lebenslauf-Studio, privater Opportunity-Pipeline, Bewerbungsdossiers, Backups, Exporten und einer überwachten lokalen Analyse-Laufzeit.
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
- 1.369 Tests bestehen im v1.6.0-Kandidaten; eine unabhängige Prüfung wiederholte 42 Portabilitäts- und Speichertests.
- Frontend + Shell
- 334 Frontend-Tests in 64 Dateien und 17 Rust-Bibliothekstests bestehen, einschließlich des nativen Backup-Writers.
- Backup-Prüfung
- Archive der Versionen 1–4 durchlaufen einen vollständigen, nicht verändernden Preflight; die Antwort enthält begrenzte Metadaten statt Archivinhalten.
- Skalierungs-Fixture
- Eine Agenda-Fixture mit 10.000 Bewerbungen erfasst einen p95 von 68,670 ms bei einem Projektbudget von 200 ms.
- Grenze
- Lokale Belege schützen nicht vor einem Prozess, der direkt in die Datenbank schreiben kann; unsignierte Importe werden unter Quarantäne gestellt.