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.
Il primo avvio parte da dove si trovano già molte persone: un CV esistente. CareerOS crea prima il profilo revisionato minimo, importa il documento localmente entro limiti precisi e lascia ogni dato estratto in attesa di conferma. L’utente arriva alla revisione dei fatti, non a un account creato a metà o a un errore senza spiegazione.
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.
Perché queste tecnologie.
Ogni componente mantiene il prodotto locale, verificabile e abbastanza semplice da distribuire.
Tauri per la shell desktop.
- Perché
- È adatto a un’app locale che deve integrare finestre native, file e supervisione dei servizi senza incorporare un intero browser.
- Cosa ho escluso
- Electron avrebbe ampliato peso e superficie del runtime; una soluzione solo browser non potrebbe governare con la stessa affidabilità sidecar e artefatti locali.
- Quanto è costata
- Accetto un confine Rust in più e un packaging specifico per ogni piattaforma.
Un sidecar FastAPI per i servizi applicativi.
- Perché
- Mantiene in Python i flussi di documenti e analisi, ma li espone alla shell tramite una API loopback stretta e verificabile.
- Cosa ho escluso
- Riscrivere tutto in Rust avrebbe duplicato l’ecosistema Python; spostare la logica nel browser avrebbe indebolito il controllo sul dato locale.
- Quanto è costata
- Questo significa avviare, monitorare e versionare un secondo processo.
SQLite come archivio versionato.
- Perché
- Transazioni, migrazioni e un singolo file si adattano a uno spazio di lavoro personale posseduto localmente, non a un servizio condiviso ospitato.
- Cosa ho escluso
- Un database server locale aggiungerebbe processo e credenziali da amministrare; un archivio cloud introdurrebbe rete e confine del fornitore. Nessuno dei due risponde a un requisito di servizio condiviso previsto dal progetto.
- Quanto è costata
- La contropartita è una concorrenza limitata, oltre alla responsabilità di progettare migrazioni e backup locali.
Un runtime locale compatibile con llama.cpp.
- Perché
- L’analisi resta entro il confine dichiarato del dispositivo e può essere vincolata a modelli e attività approvati.
- Cosa ho escluso
- Una API LLM cloud trasferirebbe dati professionali fuori dal dispositivo e renderebbe privacy e comportamento dipendenti da un servizio remoto.
- Quanto è costata
- In cambio, la prima configurazione richiede tempo e l’esperienza dipende dall’hardware e dai modelli supportati.
Le scelte che lo rendono uno strumento vero.
Il lavoro utile avviene prima e dopo la chiamata al modello.
Creare il registro prima di importare il CV
Il primo avvio crea un profilo revisionato minimo e solo dopo esegue un’importazione locale con limiti definiti. I dati estratti restano candidati finché l’utente non li verifica, quindi il CV accelera la configurazione senza diventare una verità indiscutibile.
Il compromessoL’onboarding richiede un passaggio esplicito di revisione, ma un’estrazione parziale o fallita non lascia il vault in uno stato ambiguo.
Registrare le mutazioni private prima di cambiare i dati
Reset, ripristino, cancellazione, migrazioni pacchettizzate e pubblicazione di fonti, foto o CV registrano prima un intento specifico e limitato. Il recupero riapre descrittori stabili di file regolari e verifica identità, dimensione e digest prima di convergere o riprovare.
Il compromessoOgni percorso di manutenzione include logica di ciclo di vita e recupero, ma un riavvio o un commit ambiguo non può lasciare silenziosamente un’operazione del vault applicata a metà.
Dare agli agenti un accesso separato e in sola lettura
Agent Access chiede all’utente autenticato di scegliere gli ambiti e autenticarsi di nuovo prima di mostrare il token bearer una sola volta. Le autorizzazioni scadono e sono revocabili; la CLI installabile e il server MCP espongono su stdio un insieme chiuso di strumenti in sola lettura, non prompt liberi o API remote di scrittura.
Il compromessoL’utente deve comunque configurare il client dell’agente e un client esterno può trasmettere i dati letti. Il contratto ristretto rende utile l’automazione senza condividere la sessione desktop.
Come viene verificato il prodotto.
I controlli della release v1.11.1 hanno superato 2.194 test backend; 7 sono stati saltati come previsto. La copertura complessiva ha raggiunto l’81,91%, rami inclusi. Si aggiungono 476 test frontend superati in 79 file e tutti i 27 test Rust. Le suite di migrazione, archivio, journal, ripristino e pubblicazione concorrente esercitano i percorsi di errore dietro i nuovi controlli del ciclo di vita.
CI protetta, CodeQL e controlli dei container rinforzati sono verdi sul commit 96ca0f8. Una prova generale senza pubblicazione e il workflow del tag firmato hanno assemblato ed eseguito sei pacchetti nativi in modo indipendente. Gli stessi byte del wheel Agent Access sono stati provati su Linux, macOS e Windows con Python 3.12 e Python 3.13 prima che la release immutabile pubblicasse 26 artefatti vincolati da digest.
Cosa esiste oggi.
La release v1.11.1 è una utility desktop funzionante con configurazione dal CV, Career Vault, ricerca guidata, Job Library revisionata, una timeline per opportunità, studio per il CV, archivio v6 e analisi locale obbligatoria. Reset, ripristino, cancellazione completa, migrazioni e pubblicazione dei file privati dispongono ora di recupero durevole ai riavvii.
Famiglie di sessione a rotazione, configurazione fail-closed e limiti rigidi per le risposte dei provider e dei runtime locali proteggono il confine loopback. Le diagnostiche pubbliche non contengono dati privati, mentre i controlli forced-colors, tastiera e WCAG coprono login e Agent Access in italiano e inglese sui layout responsive supportati.
L’app desktop autenticata ora gestisce le autorizzazioni per sette operazioni in sola lettura esposte tramite una CLI e un server MCP su stdio, entrambi inclusi nel wheel di release e autenticati con token bearer. Codex, Claude Code e script shell possono consultare una vista volutamente ridotta di un solo account autorizzato, ma non possono modificare il vault, invocare prompt liberi o aprire un trasporto remoto.
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
- La suite della release v1.11.1 ha superato 2.194 test backend; 7 sono stati saltati come previsto. La copertura complessiva ha raggiunto l’81,91%, rami inclusi.
- Frontend + shell
- Passano tutti i 476 test frontend in 79 file e tutti i 27 test Rust. I contratti per licenze, icone, bundle, browser, container e supply chain girano sullo stesso commit della release.
- Ripristino durevole ai riavvii
- Stati del ciclo di vita persistenti e journal limitati con checksum permettono a reset, ripristino, cancellazione, migrazioni pacchettizzate e pubblicazione dei file privati di convergere dopo un riavvio senza fidarsi di path o payload illimitati.
- Sessioni e diagnostica
- La rotazione monouso dei refresh token appartiene a famiglie di sessione persistenti, il replay revoca la famiglia e le sessioni di manutenzione non possono entrare nel workspace. Le diagnostiche di ricerca e runtime attraversano i confini pubblici solo tramite un registro tipizzato, chiuso e privo di contenuti privati.
- Accesso agenti
- L’app desktop rilascia autorizzazioni con ambiti e revoca per sette operazioni in sola lettura esposte dalla CLI e dal server MCP. La release include entrambi i comandi in un wheel Python installabile, mostra il token bearer una volta sola e ne conserva soltanto il digest.
Release verificata v1.11.1 Verifica del
Questo case study descrive la release immutabile v1.11.1 al commit 96ca0f8. Il tag firmato e verificato e i 26 artefatti pubblicati seguono una prova generale senza pubblicazione su sei piattaforme native e sei combinazioni sistema operativo/Python per Agent Access. Checksum e provenienza GitHub legano i byte alla release, ma gli installer nativi restano build della comunità senza firma di piattaforma o notarizzazione. Non afferma risultati occupazionali, accuratezza del modello su dati privati né supporto per ogni modello locale e ogni macchina.