Il problema di prodotto.
Le informazioni professionali tendono a disperdersi tra vecchi CV, portali di lavoro, appunti e sistemi di candidatura. Gli strumenti AI generici aggiungono un altro problema: una risposta ben scritta può perdere il legame con il fatto che la sostiene.
CareerOS Local è stato progettato prima di tutto come registro operativo. Esperienze, formazione, competenze e risultati conservano provenienza, stato di verifica e cronologia delle revisioni. L’LLM analizza poi quel registro, di proprietà dell’utente, per il matching e il coaching, invece di inventare un secondo profilo scollegato.
Ciò che il sistema deve proteggere.
L’architettura segue quattro vincoli di prodotto:
- I dati professionali privati, i documenti generati e le analisi restano sul dispositivo.
- Il matching e il coaching basati su LLM richiedono un runtime locale approvato; non esiste un fallback verso modelli cloud.
- I suggerimenti generati non possono sostituire silenziosamente i dati di origine o la loro cronologia.
- Backup, esportazione e cancellazione devono includere in modo coerente sia i dati strutturati sia gli artefatti locali.
La scelta progettuale.
La parte difficile non era aggiungere una chat. Era costruire un confine tra evidenze, stato deterministico dei flussi e interpretazione del modello. Questi tre elementi hanno modalità di errore diverse e non dovrebbero condividere una struttura dati vaga.
Li ho separati in un archivio professionale, registri riproducibili di preparazione e candidatura e pipeline di analisi locale validate tramite schema. L’interfaccia può mostrare da dove proviene una conclusione e quale correzione appartiene al dato di origine.
Un runtime locale supervisionato.
Tauri gestisce l’app desktop e supervisiona un sidecar FastAPI su loopback. React offre lo spazio di lavoro, SQLite e gli artefatti locali conservano il registro persistente, mentre un runtime gestito compatibile con llama.cpp esegue l’analisi LLM obbligatoria senza diventare un livello di persistenza.
Le scelte che lo rendono uno strumento vero.
Il prodotto utile è l’intero flusso costruito attorno al modello.
Conservare la provenienza nel registro
I dati professionali mantengono fonte, stato di verifica e revisioni. Il contenuto del CV e le evidenze di candidatura possono risalire a quel registro.
Richiede più struttura di un profilo libero, ma rende possibili correzioni e verifiche.
Richiedere l’analisi locale
Il matching delle opportunità e il coaching restano bloccati finché il runtime locale approvato non è pronto. L’applicazione non invia mai l’attività a un modello remoto come fallback di comodo.
La prima configurazione è più impegnativa e l’hardware conta, ma il confine di privacy resta reale.
Trattare le candidature come evidenze
CV versionati, risposte, mappature dei requisiti e file verificati possono essere esportati con un manifesto SHA-256 canonico.
Un dossier richiede più cura di una cartella di file sparsi; in cambio è riproducibile e verificabile.
Come viene verificato il prodotto.
Il repository testa i servizi Python, il comportamento React e l’integrazione desktop Rust. Le migrazioni del database vengono eseguite in cicli di upgrade, downgrade e nuovo upgrade. I test dei backup ispezionano senza modifiche le versioni 1–4, poi verificano sostituzione, rilevamento della corruzione e rollback su dati locali temporanei.
L’automazione dei rilasci controlla anche licenze delle dipendenze, SBOM, container e policy sulle vulnerabilità ad alta gravità. Le immagini del tour provengono dall’applicazione reale con dati fittizi e il registratore rifiuta errori del browser, risposte API fallite e avvisi visibili.
Cosa esiste oggi.
CareerOS Local è una utility desktop funzionante con archivio professionale, studio per il CV, pipeline privata delle opportunità, dossier di candidatura, backup, esportazioni e un runtime supervisionato per l’analisi locale.
Non sostiene che un LLM possa decidere una carriera. Il modello aiuta a interpretare un insieme di evidenze di proprietà dell’utente; l’utente conserva il registro, la fonte e la decisione finale.
Registro delle evidenze.
Il repository documenta questi controlli e limiti riproducibili:
- Backend
- 1.369 test superati nella candidate v1.6.0; una review indipendente ha rieseguito 42 test su portabilità e storage.
- Frontend + shell
- 334 test frontend in 64 file e 17 test della libreria Rust superati, incluso il writer nativo dei backup.
- Verifica dei backup
- Gli archivi dalla versione 1 alla 4 ricevono un preflight completo e non mutante; la risposta contiene metadati limitati, non il contenuto dell’archivio.
- Fixture di scala
- Una fixture agenda con 10.000 candidature registra un p95 di 68,670 ms rispetto al budget di progetto di 200 ms.
- Limite
- Le ricevute locali non proteggono da un processo che può scrivere direttamente nel database; le importazioni non firmate vengono messe in quarantena.