La domanda di prodotto.
Coordinare i tirocini coinvolge persone, organizzazioni ospitanti, supervisori, tappe e ore. Una console utile deve rispondere rapidamente a domande operative semplici: chi è bloccato, cosa scade e quale record richiede attenzione.
Il concetto accademico originale è stato ricostruito come applicazione statica volutamente limitata. I dati pubblici sono fittizi, le modifiche restano nel browser e ogni stato della demo può essere ripristinato.
Cosa promette l’edizione pubblica.
La ricostruzione mantiene un confine piccolo e ispezionabile:
- Ogni persona e organizzazione nel dataset distribuito è fittizia.
- La ricerca e i filtri di stato lavorano su un unico modello esplicito di tirocinio.
- Gli aggiornamenti delle tappe persistono soltanto nel local storage del browser e possono essere azzerati.
- Non esistono account, database, endpoint di analytics o API remote di scrittura.
Modellare il processo prima della dashboard.
Una dashboard diventa fragile quando totali, etichette e stato delle righe derivano ciascuno lo stato in modo diverso. Il primo compito è stato rendere lo stato del tirocinio e il calcolo delle ore un unico modello verificato.
L’interfaccia è poi diventata una proiezione di quel modello: metriche della coorte, filtri e progressi individuali usano le stesse funzioni, mentre la persistenza locale conserva soltanto lo stato di lavoro fittizio.
Un confine di prodotto statico completo.
Un dataset fittizio incluso nel repository alimenta il modello dei tirocini. Ricerca, filtri, riepiloghi della coorte e transizioni delle tappe leggono lo stesso stato derivato. Il browser conserva le modifiche localmente; il reset ripristina la fixture originale.
Le scelte che rendono affidabile la demo.
L’app pubblica fa meno, ma ogni interazione visibile è reale.
Distribuire record fittizi
L’intera coorte è progettata per la dimostrazione, quindi l’applicazione non richiede esportazioni di produzione censurate.
La demo non può sostenere di rappresentare il processo o il volume dati di un’istituzione reale.
Derivare le metriche dal modello
Calcoli di stato e ore sono condivisi da schede, filtri e record individuali e coperti da test Node.js.
I nuovi stati del flusso devono aggiornare il contratto del modello prima di apparire nell’interfaccia.
Mantenere locale la persistenza
Le modifiche alle tappe sopravvivono a un refresh tramite local storage e il reset ripristina la fixture originale.
Questa edizione non offre collaborazione, autenticazione o sincronizzazione tra dispositivi.
Verifica del sito statico.
Il server locale riproduce l’esatto percorso base di GitHub Pages, così le regressioni dei link assoluti falliscono prima del deploy. I test Node.js coprono il modello dati e Playwright verifica l’esperienza nel browser.
I rilasci stabili includono archivi ZIP e TAR deterministici con inventario, SBOM CycloneDX, evidenza del commit sorgente e checksum SHA-256.
Cosa supporta la console.
Un operatore può cercare per studente, organizzazione ospitante o supervisore, filtrare la coorte per stato, esaminare i progressi, avanzare una tappa e ritrovare lo stesso stato locale dopo un refresh.
VECTOR è una demo mirata, non un servizio ospitato per i tirocini. Il suo valore è un modello di interazione coerente e funzionante con un confine dati insolitamente chiaro.
Registro delle evidenze.
L’edizione pubblica include una fixture volutamente piccola e verificabile:
- Fixture
- Sei tirocini fittizi distribuiti in quattro stati; due attivi e due in revisione.
- Vista derivata
- La fixture verificata riporta un completamento aggregato del 67% su obiettivi di 160/180 ore.
- Verifica
- 30 dichiarazioni di test Node.js e cinque E2E nel browser, inclusi mobile a 390 px e controllo esatto dell’overflow a 320 px.
- Limite
- Tutta la persistenza appartiene a un singolo browser. Il progetto non è un sistema di tirocinio multiutente in produzione.