Roadmap POC → MVP avanzato → Release 1

Le durate sono da stimare dopo refinement e sizing del team. L'ordine rappresenta dipendenze e gate, non sprint già impegnati.

Fase 0 — Baseline e tenant foundation

Obiettivo: condivisione sicura per organizzazione.

1. Congelare contratti AS-IS, dataset di prova e regression suite.
2. Scrivere ADR tenant e matrice ruoli/permessi.
3. Implementare OrganizationContext server-side usando identità/membership di piattaforma.
4. Migrare schema, unicità, indici e stato operativo con expand/backfill/enforce.
5. Rendere tenant-aware data-service, rendicontazione-service, repository, import, export, job, cache e audit.
6. Aggiungere test a due tenant e penetration test IDOR di base.
7. Pilotare con due utenti della stessa organizzazione.

Exit gate: tutti i criteri P0 della pagina visibilità per organizzazione superati.

Fase 1 — Fondazioni di dominio e HR

Obiettivo: anagrafiche affidabili su cui basare pianificazione e costi.

1. Riorganizzare il service nei moduli workforce, projects, actuals, forecasting, data-exchange, reporting senza cambiare deployment.
2. Introdurre società/sotto-aziende e storico di appartenenza.
3. Introdurre catalogo sedi tenant-aware, pagina di gestione e storico sede di assegnazione del dipendente.
4. Separare ruolo, macro-livello e job level; migrare valori esistenti.
5. Storicizzare reporting line e validare stesso tenant, anti self-reference e anti-ciclo.
6. Consolidare storico costo dipendente e intervalli non sovrapposti.
7. Collegare opzionalmente dipendente e account utente.
8. Aggiungere tipo risorsa e flusso freelancer con ore contrattuali.
9. Completare UI Dipendenti con tab profilo, organizzazione/ruolo, sede, reporting, costi e audit.

Exit gate: CRUD, migrazioni, import/export e UI coprono il nuovo modello senza regressioni.

Fase 2 — Ferie

Obiettivo: rendere più preciso il forecast. Non è un modulo HR — la fase è stata ridimensionata dal committente, e la decisione è registrata in Stato e decisioni.

1. Le due tabelle — saldo annuale e piano mensile — con il decremento dei giorni goduti dall'import presenze, riconosciuti da 8FE. Fatto il 17 agosto 2026, migrazione 108: employee_leave_balances (leave_year, entitled_days, consumed_days) e employee_monthly_leave_plan (plan_month, planned_days). I giorni goduti si ricalcolano a ogni import e a ogni annullamento, non si decrementano.
2. L'interfaccia che mostra ferie prese e residue, e con cui Admin/HR inserisce i giorni previsti per dipendente e anno. Fatta il 18 agosto 2026: sotto-scheda Ferie dentro Storico nella scheda dipendente — form dei previsti sopra, anni sotto con previsti, goduti e residui. Resta un attributo del singolo: nessun default di organizzazione, nessuna derivazione dal contratto, nessuna ereditarietà fra anni.
3. Il self-service per inserire i giorni pianificati, per mese e non per giorno. Fatto il 18 agosto 2026: dodici mesi in «I miei dati», solo i futuri modificabili, e il tetto dei giorni disponibili imposto dal servizio.
4. Solo dopo, l'uso del piano nel forecast: il monte ore del mese cala dei giorni pianificati. Fatto il 18 agosto 2026: in ricalcolaTutti il monte ore smette di essere una costante e diventa una funzione di persona e mese. Solo le ferie pianificate; quelle non ancora collocate restano fuori per decisione esplicita.

Fuori perimetro per decisione esplicita: workflow di approvazione e stati, carry-over, calendari di festività, unità in ore, viste manager, permessi (<n>PR), part-time e assunzioni infra-annuali. Il modello di capacità dipendente/progetti — quello che servirebbe al residuo ferie non ancora pianificato — si sviluppa più avanti.

Exit gate: un dipendente inserisce i giorni per mese, la scheda mostra prese e residue, e il monte ore del forecast cala di conseguenza.

Fase 3 — Progetti, enti e tariffe

Obiettivo: valorizzazione economica corretta e temporalmente stabile.

1. Completare enti finanziatori e tariffe storiche per macro-livello.
2. Rendere esplicita su progetto la strategia REAL/STANDARD.
3. Aggiungere max_hours_per_resource con default 1720 e override.
4. Aggiungere la sede opzionale al progetto e validare la compatibilità città con le sedi storiche delle risorse associate.
5. Validare tariffe mancanti/sovrapposte e associazioni cross-tenant.
6. Applicare la tariffa valida alla data a forecast, consuntivo ed export.
7. Aggiungere schermate/configurazioni e report di qualità dati.

Exit gate: golden test economici riproducono costi reali e standard attraverso cambi tariffa.

Fase 4 — Data exchange estendibile

Obiettivo: aggiungere nuovi formati senza modificare il dominio.

1. Definire modelli canonici employee/project/actual/leave. Fatto il 19 agosto 2026 — con una scoperta: tre dei quattro esistevano già senza nome dentro importPayloads.js. Il quarto, le assenze, mancava davvero: uscivano solo dentro le giornate di presenza, e un formato che portasse le ferie senza le presenze non aveva modo di consegnarle.
2. Creare interfacce e registry adapter. Scritto e provato, modules/data-exchange/registroAdapter.js — ma non ancora collegato alle rotte, che chiamano i lettori dritti. È il debito più visibile della fase.
3. Incapsulare i formati attuali come adapter v1 senza regressioni.
4. Implementare i nuovi formati del committente come adapter separati.
5. Mantenere staging, diff, approvazione, idempotenza, rollback e report errori.
6. Aggiungere contract test per adapter e fixture anonimizzate/versionate.

Exit gate: un formato nuovo viene aggiunto senza cambiare repository o regole di business.

Fase 5 — Consuntivo, consegna e correzioni

Obiettivo: gestione mensile controllata e ricalcolo retroattivo.

1. Separare cursore consuntivo e cursore consegna. Fatto il 18 agosto 2026, migrazione 117 — con una correzione del disegno decisa dal committente: il cursore di consegna non è per organizzazione ma per progetto (projects.delivered_through_month), perché ogni progetto si rendiconta al suo ente con i suoi tempi. Sostituisce freeze_config, rimosso. Fra i due cursori resta la finestra in cui persone e ore si possono ancora spostare. Vedi Stato e decisioni.
2. Implementare comando deliver month con snapshot, firma/hash e permesso dedicato.
3. Bloccare DB/API/UI per periodi consegnati.
4. Implementare correzione retroattiva per periodi aperti, dirty range e ricalcolo cronologico.
5. Conservare versioni, motivazione, attore e confronto prima/dopo.
6. Rigenerare report interessati, evitando la modifica degli snapshot consegnati.

Exit gate: correzione di X aggiorna X..N; la stessa operazione su un mese consegnato fallisce senza scritture parziali.

Fase 6 — Forecasting vincolato (MVP avanzato)

Obiettivo: copertura progetti senza over-allocation.

1. Formalizzare priorità, funzione obiettivo e semantica “progetto coperto” col committente.
2. Implementare capacità netta, ferie e limite ore. È qui che atterra il modello di capacità dipendente/progetti rimandato dalla Fase 2, quello che serve al residuo ferie non ancora pianificato.
3. Calcolare globalmente per organizzazione, non progetto per progetto in isolamento.
4. Integrare tutti i trigger tramite outbox/job idempotenti.
5. Mostrare stato, domanda scoperta, over-capacity, motivazioni e confronto versioni.
6. Gestire freelancer con ore contrattuali e strategia dedicata.
7. Eseguire UAT su scenari reali anonimizzati.

Exit gate MVP avanzato: flusso end-to-end HR → progetto → forecast → consuntivo → correzione → consegna → report validato dal committente.

Fase 7 — Hardening Release 1

Obiettivo: prodotto vendibile e operabile.

1. Performance/load test su volumi attesi e ricalcoli concorrenti.
2. SLO, dashboard, alert, tracing e runbook per import/forecast/report.
3. Backup/restore e disaster recovery testati.
4. Security review, dependency scan, audit accessi e retention/privacy.
5. Migrazione onboarding per nuova organizzazione e import iniziale verificabile.
6. Manuale utente, amministrazione, supporto e changelog.
7. Feature flag, rollback applicativo/dati e canary/pilot.
8. UAT formale, criteri di go-live e sign-off.

Exit gate Release 1: checklist qualità completa, nessun finding critico, restore provato e prima organizzazione onboarding tramite procedura documentata.

Backlog successivo

• scenari what-if e approvazione del forecast;
• notifiche manager/dipendente;
• API pubbliche/connettori HR;
• workflow ferie avanzato se richiesto;
• ottimizzazione multi-obiettivo configurabile;
• estrazione del forecasting worker se giustificata dalle metriche.