Il problema operativo.
Gestire i tirocini non significa soltanto mostrare una dashboard. Una scuola deve coordinare coorti, studenti, aziende ospitanti, tutor, date, ore, check-in ed evidenze firmate. Ruoli diversi devono vedere parti diverse dello stesso record, e una correzione non deve cancellare ciò che è successo prima.
La precedente implementazione accademica non poteva essere riutilizzata come base di prodotto. Ho ricostruito VECTOR da zero, prendendo come riferimento soltanto il dominio dei tirocini. Nel nuovo repository non sono entrati codice legacy, dati personali, nomi o risorse grafiche del progetto precedente.
Cosa deve garantire un sistema gestito dalla scuola.
L’architettura parte da quattro vincoli pratici:
- Ogni installazione appartiene a una sola scuola, che controlla database, identità visiva, backup e distribuzione.
- Permessi e ambito dei tutor devono essere applicati dal server prima di selezionare, contare o esportare i record.
- Ogni tirocinio conserva la versione del programma che ne ha definito ore, check-in ed evidenze; le correzioni mantengono il record operativo originale.
- Import, export, retention e ripristino devono essere limitati, verificabili e ripetibili in sicurezza dopo un errore.
Definire prima il confine di proprietà.
Spostare più stato nel browser avrebbe comunque lasciato irrisolte le domande difficili. Avrebbe potuto nascondere i controlli di ruolo nell’interfaccia, caricare l’intera scuola in memoria e trattare un campo modificato come se il valore precedente non fosse mai esistito.
VECTOR assegna ogni installazione a una scuola invece di costruire un servizio condiviso multi-tenant. La responsabilità operativa è chiara e backup, retention e personalizzazione white-label restano più semplici da controllare. Il progetto distribuisce software, non una piattaforma cloud gestita.
Un server compatto con confini espliciti.
L’ambiente web comunica con un’API Express che gestisce autenticazione, ruoli, versioni di programma e transizioni. SQLite conserva i record della scuola in WAL. I cursori AES-GCM legano copertura e attenzione a scuola, ruolo, filtri e posizioni stabili senza rivelarne il contenuto.
Perché queste tecnologie.
Lo stack è dimensionato per una scuola che possiede e gestisce la propria installazione.
Una sola scuola per installazione.
- Perché
- Proprietà dei dati, ruoli, white label, backup e ripristino restano entro un confine istituzionale chiaro.
- Cosa ho escluso
- Un SaaS multi-tenant richiederebbe isolamento tra clienti, billing, operazioni centrali e garanzie di conformità che non appartengono al prodotto.
- Quanto è costata
- Accettiamo che ogni scuola gestisca aggiornamenti, capacità e backup della propria istanza.
Express come livello server.
- Perché
- Autenticazione, ruoli, perimetro e transizioni vengono applicati prima che i dati raggiungano il browser.
- Cosa ho escluso
- Un’app solo browser lascerebbe regole e dati sul client, che non può imporre autorizzazioni affidabili.
- Quanto è costata
- Accettiamo di distribuire e mantenere un servizio server esposto alla rete dell’istituto.
SQLite in modalità WAL.
- Perché
- Transazioni, portabilità e snapshot a file singolo sono proporzionati al carico di una singola scuola.
- Cosa ho escluso
- PostgreSQL o un database cloud aggiungerebbero servizio, credenziali e amministrazione senza una scala multi-tenant dimostrata.
- Quanto è costata
- Accettiamo limiti di scrittura concorrente e nessuna alta disponibilità automatica.
Docker con strumenti espliciti di backup e ripristino.
- Perché
- L’istituto ottiene un’installazione riproducibile e un percorso di recupero verificabile sulla propria infrastruttura.
- Cosa ho escluso
- Una piattaforma gestita semplificherebbe le operazioni, ma sposterebbe controllo e dipendenza verso un fornitore.
- Quanto è costata
- Accettiamo che l’operatore monitori storage, provi i ripristini e pianifichi gli aggiornamenti.
Le scelte che rendono più sicuro il lavoro quotidiano.
Il prodotto preferisce regole visibili a uno stato nascosto ma comodo.
Versionare le regole, non soltanto il tirocinio
Una versione di programma pubblicata è immutabile. Le nuove regole valgono per le nuove assegnazioni; un tirocinio esistente conserva ore obiettivo, check-in minimi ed evidenze con cui è iniziato.
Il compromessoUna correzione richiede una nuova versione e i tirocini ancora intatti possono essere riassegnati solo in modo esplicito. Il completamento non cambia retroattivamente.
Mostrare i vuoti prima che diventino eccezioni
La copertura viene calcolata per coorte e periodo, distinguendo assegnazione valida, assenza e sovrapposizione. Da una riga scoperta si avvia un tirocinio precompilato senza perdere il contesto.
Il compromessoÈ una vista operativa limitata, non un motore generico di report. Proprio per questo il risultato resta azionabile e corretto per ruolo.
Derivare l’attenzione dai record già posseduti
La coda deriva il lavoro dovuto da evidenze, ore, date e assegnazioni dei tutor invece di mantenere un secondo elenco. Il server applica il ruolo prima di conteggio e paginazione.
Il compromessoLa coda non conserva promemoria arbitrari: resta coerente con il record del tirocinio ed evita una seconda fonte di verità.
Self-hosting e ripristino.
Ogni scuola può impostare nome, colori, logo e contatti di supporto, con revisioni che proteggono le modifiche simultanee. L’immagine Alpine con Node 24 fissato gira con utente non root, codice applicativo di proprietà root, nessun gestore di pacchetti e supporto per un filesystem radice in sola lettura. I comandi health e doctor fermano l’avvio quando configurazione, schema o proprietà dell’archiviazione non sono sicuri.
Gli strumenti creano uno snapshot SQLite privato con limite di dimensione, lo ispezionano senza avviare l’applicazione e lo ripristinano attraverso un percorso protetto che rileva sostituzioni dei path e modifiche della sorgente. L’automazione scansiona container e sorgenti per vulnerabilità e segreti, pubblica un SBOM, costruisce due volte l’archivio e verifica il percorso di accettazione estratto prima della pubblicazione.
Cosa supporta VECTOR oggi.
Una scuola può pubblicare regole di programma, controllare la copertura della coorte, creare tirocini dai vuoti di pianificazione e lavorare una coda di attenzione per ruolo. Lo stesso record conserva ore, check-in, storia delle evidenze, audit, import atomico, export filtrato e retention governata.
VECTOR è software open source in self-hosting. Non è un SaaS gestito e non dichiara certificazioni di conformità, alta disponibilità o SSO. Per un’istituzione che ne abbia bisogno, questi aspetti restano lavoro di prodotto e di distribuzione.
Registro delle evidenze.
La release firmata 3.4.0 lega le promesse del prodotto a controlli concreti:
- Policy di programma
- I coordinatori pubblicano versioni immutabili con ore obiettivo, numero minimo di check-in ed evidenze richieste. I tirocini esistenti mantengono la versione assegnata.
- Operazioni limitate
- Paginazione indicizzata e stabile per studenti e aziende, validazione batch degli import e limiti di capacità nel database mantengono liste, cronologia dei tirocini, sessioni ed elenco degli amministratori entro confini operativi espliciti.
- Archiviazione e ripristino
- Avvio, doctor, backup, ispezione, compattazione e ripristino rifiutano alias SQLite non sicuri e derive dello schema, verificano i file WAL associati ed eseguono controlli d’integrità e snapshot sulla stessa connessione protetta con cui accedono al database.
- Confine richieste e sessioni
- Origini di produzione esatte, errori di login neutrali rispetto all’identità, rifiuto dei cookie duplicati, controlli CSRF timing-safe e un massimo di dieci sessioni sono applicati prima che il workspace per ruolo possa esporre i record della scuola.
- Verifica e release
- Gate su Node 22 e 24, accettazione Chromium e WebKit, soglie di coverage native, prove di scala e CRUD, scansioni Trivy e due build identiche byte per byte proteggono la release. Il tag firmato e verificato risolve al commit fb802e5 e la release GitHub immutabile pubblica otto artefatti vincolati da digest, incluso l’SBOM CycloneDX.
Release verificata v3.4.0 Verifica del
Questo case study descrive la release immutabile 3.4.0 e i suoi controlli di self-hosting al commit fb802e5. GitHub Pages è un tour del prodotto; l’applicazione operativa parte dal pacchetto server. Non sono rappresentati dati scolastici reali, integrazioni istituzionali o risultati, e la release non dichiara disponibilità gestita o certificazioni di conformità.