Roadmap & Fasi · v1.0

st4ck planning

phasing rollout · single-operator delivery plan

PM senior review · append-only · cross-link dossier §11

Fase corrente

Fase 0 — closing

preparazione hardware
~95% complete

Next milestone

Fase 1A — CF hardening

unblocks all Fase 1+
ETA 1 weekend

Coverage piano

18 fasi · 0 done

F0 + 6 in F1 + 4 in F2
+ 3 in F3 + 4 in F4

Questa è la pianificazione operativa di st4ck redatta con la lente di un project manager senior (15+ anni delivery IT, sensibilità lean): fasi piccole, dipendenze esplicite, definition-of-done per ogni step. Convenzione append-only: i task non si cancellano, si segnano come DONE per preservare la storia di delivery. Stato vivo aggiornato a ogni avanzamento.

🎯 NEXT PHASE

Fase 0 — closing (preparazione hardware)

Goal: chiudere la preparazione hardware del compute primario casa, sbloccando l'inizio di Fase 1. Esce quando NVMe 990 PRO è nel G8, BIOS aggiornato, HA Voice PE ordinati, hardware key 2FA confermata, dismissioni programmate.

#	Step	Stato	Definition of Done	Effort	Dipende da / link
0.1	Spostamento NVMe 990 PRO 1TB dal G5 al G8	TODO	NVMe montato slot Gen4 G8, partizione btrfs creata, OS Ubuntu 24.04 LTS bootable, fstab UUID-pinned	S (~2h)	—
0.2	BIOS update G8 ultima versione HP	TODO	BIOS post-update verificato (versione + checksum), VT-x/AMD-V abilitato, secure boot OFF (compat. Linux)	S (~30min)	0.1
0.3	Ordine 2× HA Voice PE (Nabu Casa)	TODO	Ordine effettuato (~140 EUR), tracking ricevuto, ETA confermato (lead time 2-4 settimane)	S (~15min)	—
0.4	Conferma hardware key 2FA acquistata (YubiKey 5 / Titan)	TODO	Risposta Sì/No documentata. Se No: ordine prima di Fase 1A; se Sì: pronta per enrollment Authentik post-Fase 1C	S (~10min)	—
0.5	Programma dismissione G5 + NUC10 + 2× DS718+	TODO	Foto annunci preparate, prezzo target (~750-1000 EUR totale), HDD recuperati DS718+ → ready per DS720+ #2 setup	M (~3h)	0.1 (G5 vuoto post-NVMe move)
0.6	Compilazione bozza letter-to-family + DR runbook (B1+B2)	TODO	Bozza riempita su dr.html, scrittura a mano cartacea, 3 buste sigillate (Aldo / persona di fiducia / cassaforte famiglia). Mitiga RA-002 Bus factor	L (~2h)	—
0.7	Calendar OPS-001..009 monthly homelab check ricorrente	TODO	Evento ricorrente Google Calendar primo sabato del mese (~1h), checklist linkata a dossier §13	S (~15min)	—

Exit criteria Fase 0: tutti i 7 step in DONE. Output verso Fase 1A: G8 production-ready bootabile su Ubuntu 24.04 LTS (vuoto, no servizi), NVMe in posizione, BIOS aggiornato. Storage NAS DS720+ #1 invariato (already production).

Roadmap completa — 18 fasi

Pianificazione granulare in fasi piccole (1-2 weekend ciascuna) per favorire delivery incrementale, validazione intermedia, e bus factor mitigation (un singolo subentrante può raccogliere il piano dal punto di interruzione). Ogni fase ha exit criteria discreti, tutti raggiunti = fase chiusa.

Fase 0 — Preparazione hardware

0 Preparazione hardware compute primario 95% · IN PROGRESS

Vedi tabella NEXT PHASE sopra per lo step-by-step dettagliato. Goal: G8 production-ready, OS bootabile, hardware del modulo j4rv1s ordinato, dismissioni programmate. Exit: 7/7 step DONE.

Fase 1 — Foundation deploy (CF hardening + auth + storage layer)

1A Hardening account Cloudflare + 2FA hardware key TODO · ~1 weekend

Goal: proteggere il root account Cloudflare prima di qualsiasi deploy che dipenda da CF (ed è tutto). Mitiga ISSUE-010 (already RESOLVED parzialmente con TOTP) e completa hardening multi-fattore.

1A.1 — Enrollment YubiKey/Titan come 2FA primary su account CF root TODO
1A.2 — Backup recovery codes CF in busta sigillata (B2 cartaceo) TODO
1A.3 — API token scoped (no global API key) per cloudflared, dns-only e zone-only TODO
1A.4 — Audit log CF abilitato + scarico mensile in archivio TODO
1A.5 — Allowlist IP per dashboard CF (casa + genitori) TODO

Exit: il break-glass scenario "Aldo perde password CF" è gestibile via recovery codes cartacei + hardware key fisica. Dipendenze: Fase 0 chiusa, hardware key 2FA disponibile.

1B G8 OS baseline + LUKS at-rest encryption TODO · ~1 weekend

Goal: G8 con Ubuntu 24.04 LTS configurato baseline + LUKS sui dischi dati (mitiga ISSUE-007 P1). Pre-requisito per qualsiasi servizio che tocca dati persistenti.

1B.1 — Install Ubuntu Server 24.04 LTS minimal sul 990 PRO TODO
1B.2 — Hardening base: ufw, fail2ban, ssh key-only no password, no root login TODO
1B.3 — LUKS encryption su Kioxia XG6 e SSD esterno USB-C (passphrase + keyfile slot) TODO
1B.4 — btrfs subvolumes per /srv/data, /srv/data2 (snapshot-friendly) TODO
1B.5 — Auto-unlock LUKS al boot via TPM2 (non passphrase manuale) TODO
1B.6 — Smoke test: reboot, LUKS sblocca, btrfs monta, UPS shutdown sicuro TODO

Exit: G8 spegnimento → riavvio → tutti i mount disponibili senza intervento. Dipendenze: 1A chiusa.

1C Authentik IdP + Postgres dedicato + Redis TODO · ~1 weekend

Goal: Identity Provider in piedi prima di qualsiasi altro servizio. Tutti i servizi famiglia useranno OIDC verso Authentik, quindi Authentik è il primo a deploy. Mitiga ISSUE-004 (`chattr +C` Postgres su btrfs).

1C.1 — docker-compose.yml baseline con authentik-server, authentik-worker, postgres-authentik, redis-authentik TODO
1C.2 — `chattr +C` su volume Postgres prima di first run (no copy-on-write) TODO
1C.3 — Bootstrap admin Authentik, configurazione email service (SMTP esterno o disabilitato) TODO
1C.4 — TOTP enforcement per admin, hardware key enrollment (post-1A.1) TODO
1C.5 — Backup config Authentik (export YAML blueprints) committato in repo privato TODO

Exit: login Authentik web funzionante con TOTP+hardware key, blueprint export riproducibile. Dipendenze: 1B chiusa.

1D Caddy reverse-proxy + cloudflared tunnel TODO · ~1 weekend

Goal: tutta l'infrastruttura di accesso pubblico in piedi. Caddy interno, cloudflared per tunnel, primi hostname pubblici (1d.d0mus.com per Authentik).

1D.1 — Caddy container con Caddyfile baseline, internal-only network TODO
1D.2 — cloudflared container con CF Tunnel pre-configurato (token in .env), public hostname per 1d.d0mus.com TODO
1D.3 — DNS CF: 1d.d0mus.com → tunnel ingress, TLS auto-provisioning TODO
1D.4 — Smoke test: 1d.d0mus.com pubblico → Authentik login UI TODO
1D.5 — Documentazione runbook "aggiungere nuovo servizio dietro tunnel" TODO

Exit: Authentik raggiungibile pubblicamente con TLS valido via tunnel. Dipendenze: 1C chiusa.

1E Synapse (Matrix) + Postgres + bridging Element TODO · ~1 weekend

Goal: primo servizio "vero" famiglia in piedi: chat E2EE Matrix. Test del pattern OIDC-via-Authentik su un servizio reale prima di sbloccare gli altri.

1E.1 — Synapse container, postgres-synapse con `chattr +C` TODO
1E.2 — homeserver.yaml baseline, registrazione disabilitata, OIDC delegata a Authentik TODO
1E.3 — Caddy + tunnel: ch4t.d0mus.com → Synapse TODO
1E.4 — Element Web statico su CF Pages → w3b.d0mus.com (homeserver puntato) TODO
1E.5 — Account famiglia di test: 1 admin + 1 membro normale, login OIDC end-to-end, cifratura E2EE verificata TODO

Exit: due account che si scrivono in chat E2EE via Element Web autenticati Authentik. Dipendenze: 1D chiusa.

1F Backup baseline (Restic locale + B2 + monitoring) TODO · ~1 weekend

Goal: nessun servizio aggiuntivo senza backup verificato. Restic locale + B2 cloud con restore-test reale.

1F.1 — Restic config su /srv/restic-local (USB-C SSD), policy snapshot+forget TODO
1F.2 — Restic config remote B2 (bucket eu-central, password manager-stored) TODO
1F.3 — Cron backup giornaliero 03:00 (postgres + volumi container critici) TODO
1F.4 — Healthcheck endpoint Healthchecks.io / dead-man-switch TODO
1F.5 — Restore test reale: distruggi DB Authentik di prova → restore da B2 → login funziona TODO

Exit: backup → restore di un DB validato in tempo < RTO target. Dipendenze: 1E chiusa.

Fase 2 — Family-facing services

2A Immich (foto famiglia) TODO · ~1 weekend

Goal: Immich production con import iniziale foto famiglia, app mobile testata, ML face recognition attiva.

2A.1 — docker-compose Immich (server + ML + postgres dedicato + redis) TODO
2A.2 — Storage NFS DS720+ #1 mounted su G8 per library media TODO
2A.3 — OIDC integration Authentik TODO
2A.4 — Caddy + tunnel: ph0t0.d0mus.com TODO
2A.5 — Import iniziale ~10K foto storiche da iCloud/locale, run ML faces TODO
2A.6 — App mobile Immich su iPhone/Android famiglia, autoupload abilitato TODO
2A.7 — Restic include /srv/data/immich nel backup giornaliero TODO

Exit: 2 dispositivi famiglia uploadano in autoupload, ML faces popolata. Dipendenze: 1F chiusa.

2B Seafile + OnlyOffice (drive collaborativo) TODO · ~1 weekend

Goal: drive famiglia con editing collaborativo. Migrazione documenti famiglia esistenti.

2B.1 — docker-compose Seafile + onlyoffice-documentserver + postgres dedicato TODO
2B.2 — OIDC + tunnel: dr1v3.d0mus.com TODO
2B.3 — Library famiglia con permessi base (admin Aldo, members family) TODO
2B.4 — Migrazione doc famiglia (Drive personale) TODO
2B.5 — Restic include Seafile data TODO

2C Vaultwarden + Paperless-ngx TODO · ~1 weekend

Goal: password manager famiglia in piedi (priority alta) + KB documenti.

2C.1 — Vaultwarden + postgres dedicato, OIDC, tunnel v4ult.d0mus.com TODO
2C.2 — Migrazione vault da provider attuale (esportare → importare) TODO
2C.3 — App Bitwarden mobile/desktop puntate a server self-host TODO
2C.4 — Paperless-ngx + postgres dedicato, OIDC, tunnel kb.d0mus.com TODO
2C.5 — Import primi 50 documenti scansionati (test OCR + tagging) TODO

2D Home Assistant + Mailpiler + Blinko TODO · ~1-2 weekend

Goal: closing della suite servizi famiglia. HA migrazione, Mailpiler archivio, Blinko note.

2D.1 — Migrazione Home Assistant container con copia volume config esistente TODO
2D.2 — Mailpiler + dipendenze (rspamd, ecc.), import archivio email TODO
2D.3 — Blinko + postgres 14 dedicato (vincolo upstream) TODO
2D.4 — OIDC + tunnel per tutti e 3 i servizi TODO
2D.5 — Closing: 11 servizi famiglia tutti up con login unico Authentik TODO

Exit: stack completo. Dipendenze: 2A-2C tutte chiuse.

Fase 3 — Replica off-site (genitori)

3A Approvvigionamento G8 #2 + setup base genitori TODO · ~2-4 settimane (lead time)

3A.1 — Acquisto G8 #2 mercato usato (~250 EUR target) TODO
3A.2 — Spostamento NVMe 970 EVO+ 500GB (riserva) sul G8 #2 TODO
3A.3 — Acquisto UCG-Ultra (~160 EUR) + UPS basic TODO
3A.4 — Trasporto fisico hardware presso casa genitori TODO
3A.5 — Acquisto DS720+ #2 (HDD recuperati DS718+ post-dismissione) TODO

3B UniFi Site Magic VPN + Snapshot Replication TODO · ~1 weekend

3B.1 — UDM Pro + UCG-Ultra in Site Magic (zero-touch sui peer) TODO
3B.2 — DS720+ #1 → DS720+ #2 Snapshot Replication ogni 15min TODO
3B.3 — G8 #2 deploy passivo: stesso docker-compose, services stopped (ready-to-run) TODO
3B.4 — Restic config secondario su DS720+ #2 (backup locale ai genitori) TODO

3C Failover drill (test reale) TODO · ~1 giornata

3C.1 — Simulazione G8 casa morto: switch DNS a G8 genitori TODO
3C.2 — G8 genitori promuove DS720+ #2 a r/w, avvia stack TODO
3C.3 — Verifica login Authentik + accesso ai 11 servizi TODO
3C.4 — RTO/RPO misurati e confrontati con target dossier §10 TODO
3C.5 — Failback procedure documentata e testata TODO

Exit: failover end-to-end in tempo < RTO target. Dipendenze: 3B chiusa.

Fase 4 — Modulo j4rv1s + advanced

4A j4rv1s F0b — uncomment compose blocks + first deploy TODO · ~1 weekend

4A.1 — Uncomment 7 blocchi `j4rv1s-*` + `wyoming-*` in docker-compose TODO
4A.2 — Uncomment Caddy block j4rv1s.d0mus.com TODO
4A.3 — Set vars produzione (MISTRAL_API_KEY, ANTHROPIC_API_KEY, HA_LONGLIVED_TOKEN) TODO
4A.4 — Smoke test API /health + skill stub locale TODO

4B HA Voice PE setup + ESPHome flash TODO · ~1 weekend (post 0.3)

4B.1 — Unboxing 2× HA Voice PE, flashing ESPHome con preset Nabu Casa TODO
4B.2 — Posizionamento studio + cucina (mensole alte, lontano da rumore) TODO
4B.3 — Wakeword "jarvis" microWakeWord on-device TODO
4B.4 — Pipeline HA Assist: voice → wyoming-faster-whisper (STT) → j4rv1s-api → wyoming-piper (TTS) TODO
4B.5 — Test multi-room: "jarvis che ore sono?" da entrambe le stanze TODO

4C j4rv1s F2 — LLM router + first 5 skills TODO · ~2 weekend

4C.1 — Router classification logic L1-L5 implementata in router.py TODO
4C.2 — 5 skill iniziali: ora_corrente, meteo, kb_search (Paperless), foto_ricerca (Immich), home_control (HA) TODO
4C.3 — RAG su Qdrant per kb_search + foto_ricerca TODO
4C.4 — Telemetria opex cloud (token in/out per L3-L5) TODO
4C.5 — 1 settimana use reale, misurazione opex effettivo TODO

4D Pausa-consolidamento 6 mesi (review syst3m) DEFERRED · 6 mesi post-4C

Stop deliberato sull'aggiunta di servizi/feature. 6 mesi di consolidamento, monitoring, refactoring, prima di valutare j4rv1s F5-F7 (skill avanzate, dashboard, multi-utente). Raccomandazione audit syst3m.

4D.1 — Re-run audit syst3m + homelab-architect a fine periodo DEFERRED
4D.2 — Decisione go/no-go su j4rv1s F5-F7 DEFERRED

Convenzioni di tracking

Status enum

Status	Significato	Quando applicare
DONE	Step completato e Definition-of-Done verificata	DoD soddisfatta + smoke test passato. Mai marcare DONE per "quasi fatto".
IN PROGRESS	Step iniziato ma non chiuso	Lavoro attivo nelle ultime 7 giorni. Se >7gg → BLOCKED o TODO.
TODO	Step pianificato, dipendenze non ancora chiuse o non iniziato	Default per step nuovo aggiunto al piano.
BLOCKED	Step non eseguibile per dipendenza esterna	Causa documentata in note. Esempi: lead time HW, decisione famiglia, audit pendente.
DEFERRED	Decisione esplicita di rinviare oltre l'orizzonte attuale	Differimento intenzionale. Cross-link a §15 dossier "decisioni differite".

Regola append-only

Mai cancellare task chiusi. I task DONE rimangono visibili nel piano per:

Storico delivery (cosa è stato fatto, quando, da chi)
Onboarding di una persona di fiducia (vedere il flusso di lavoro reale)
Audit retrospettivi (RA-008 mitigation: tech debt da scelte 2026)
Recupero da incidenti (rollback su un commit dello stato pre-incidente)

Se un task viene annullato (decisione cambia), si marca DEFERRED con razionale, non si elimina la riga. Se un task viene riformulato, si chiude il vecchio come DONE (con nota "rifattorizzato in X.Y.Z") e si apre il nuovo.

Aggiornamenti incrementali

Quando un task si chiude:

Cambia TODO / IN PROGRESS → DONE nel relativo `<li>` o riga tabella.
Aggiungi class="row-done" alla `<tr>` della NEXT PHASE table per attenuare visivamente.
Se chiude una fase intera: aggiorna progress bar + status nel `<summary>` della fase.
Se la fase corrente cambia: aggiorna meta-card "Fase corrente" e "Next milestone" nell'header row.
Bump versione roadmap (es. v1.0 → v1.1) nel title, doc-toolbar, footer + riga changelog (sezione sotto, da creare quando necessario).

Cross-link al dossier

Le fasi qui sono lo specchio temporale di §11 Phasing del Rollout nel dossier (vista architetturale macro). Le ISSUE/RA citate sono in §15 dossier. Le pendenze trasversali per priorità (non temporali) sono in backlog.