Audit Log

Lente: senior new-joiner che entra a freddo nel dossier e ne valuta architettura, duplicazioni, coerenza interna, manutenibilità.

Top findings (refresh 2026-05-08 su dossier v1.10):

1. Modulo j4rv1s sparso in 9 sezioni senza indice cross-reference — lettore perde il filo
2. Ridondanza "zero porte aperte" in 4 sezioni (§02, §06, §07, §09) — consolidare o rendere esplicita la ridondanza
3. Titolo §15 obsoleto: "(aperte 2026-05-06)" mentre alcune sono state risolte successivamente
4. Stato ISSUE non scannabile: 11 paragrafi `<li>` lunghi senza colonna stato/severity/owner
5. §02 sproporzionata: edge satelliti j4rv1s appare prima della topologia 2-siti base
6. §14 Decisioni piatte (19+ righe) senza grouping tematico né colonna data/stato

ISSUE generate originali: 001-006 (vedi §15 dossier).

Quando rifarlo: dopo bump major del dossier, dopo aggiunta nuovo modulo, almeno una volta l'anno.

Lente: ingegnere prestazioni che cerca colli di bottiglia, logica inefficiente, opportunità di ottimizzazione su throughput, memoria, scalabilità.

Top findings:

1. NFS gigabit per Immich thumbnails — scroll mobile lento su libreria grande
2. btrfs CoW su volume Postgres — latency commit non ottimale, fix con chattr +C (ISSUE-004)
3. Immich ML su CPU 11th gen — face recognition iniziale ore-giorni; opzione GPU futura
4. Indici Mailpiler potenzialmente su NFS invece che NVMe locale (ISSUE-005)
5. Watchtower pull image durante orari di punta — schedulare di notte
6. Mancanza log aggregato centrale — diagnostica forense limitata

ISSUE generate: 004, 005 (incluse in batch arch+perf 001-006).

Quando rifarlo: post deploy stack reale (oggi è hypothesis-based su Fase 0); annualmente; quando si nota degrado UX percepito.

Lente: esperto data visualization che valuta come il documento sfrutta l'UI per comunicare meglio.

Top findings (refresh 2026-05-08 su dossier v1.10 + UI str4tum):

1. UI str4tum sotto-utilizzata: 3 pattern visivi base in uso vs 9 disponibili
2. KPI tile bar mancante — numeri chiave (11 servizi, 0 porte aperte, 5 layer backup, ecc.) non in evidenza
3. Stato Progetto panel (signature str4tum) completamente assente
4. Numeri/date inline non wrappati in <span class="num"> / <span class="date">
5. Diagrammi ASCII non collapsible, problematici su mobile
6. §15 ISSUE beneficerebbero di tabella con priority-dot + stato + tag invece di paragrafi

Output applicato in v2.0: KPI tile bar in cover, Stato Progetto panel sopra §01, ISSUE table refactor.

Quando rifarlo: dopo cambi UI majeurs (es. nuove versioni str4tum), aggiunta sezioni grandi, percezione "il documento si è gonfiato e rotto".

Lente: security engineer/analyst senior che valuta postura di sicurezza tecnica del progetto.

Top findings:

1. Account Cloudflare = SPoF di MITM totale se compromesso (ISSUE-010)
2. Authentik admin compromise = take over IdP per tutti i servizi (ISSUE-001 estesa)
3. LUKS at-rest assente — chiunque acceda fisicamente al G8 legge tutto plaintext (ISSUE-007)
4. Watchtower auto-pull con tag mobili — supply chain risk
5. B2 application key con permessi delete — ransomware potrebbe wipe off-site
6. NFS DS720+ senza Kerberos — chiunque su LAN può montare
7. TOTP unico fattore 2FA — phishing AiTM bypass
8. Niente log aggregato per analisi forense

Scenari di attacco realistici (top 3): S1 phishing CF account, S3 furto fisico G8, S7 ransomware con wipe B2.

ISSUE generate: 007 (LUKS, ancora aperta), 010 (CF hardening, RESOLVED 2026-05-08 con 2FA TOTP attivo). Hanno innescato anche estensione di 001 (Authentik break-glass).

Quando rifarlo: pre-deploy in produzione, annualmente, dopo cambi major del modello identità (passkey, MFA, federation), dopo introduzione nuovi servizi pubblici.

Lente: auditor di conformità che valuta gap rispetto a standard. Caveat: ISO/NIS2 non formalmente applicabili a uso domestico; GDPR si applica per dati di terzi che entrano nei sistemi (es. amici dei figli su Matrix).

Top findings:

1. Nessuna data retention policy esplicita per servizio (ISSUE-008)
2. Procedura off-boarding utente assente (GDPR art. 17) — ISSUE-009
3. Runbook DR/IR non scritto — gap operational
4. Test restore backup mai eseguito — claim 3-2-1 non validato
5. Nessuna review periodica accessi — Authentik users drift
6. DPA Cloudflare/B2 non archiviati nel repo — vendor dependency non documentata
7. Mini-RoPA assente — registro trattamenti
8. Famiglia non istruita su phishing/MFA — awareness training

ISSUE generate: 008 (retention, RISOLTA in v1.6), 009 (off-boarding runbook, ancora aperta).

Quando rifarlo: annualmente, prima di onboarding utenti esterni alla famiglia ristretta, dopo modifiche normative (AI Act, DSA, DMA), se il progetto evolve verso uso non strettamente domestico.

Lente: homelab architect senior che valuta infrastruttura self-host residenziale bilanciando resilienza e mantenibilità single-operator. Lente diversa da syst3m (strategic 3-10y): qui focus su realtà quotidiana di gestire un homelab da solo.

Top findings:

1. Mappa servizi critici vs accessori: tier-1 vita di casa = WiFi, UDM, AdGuard, UPS, HA, Vaultwarden, Authentik. Drill DR mensili dovrebbero focus prioritario su questi 5 (non su Mailpiler / Blinko)
2. Risk map operativo (vs strategico): rischi tecnologici già coperti, ma rischi fisici/operativi quotidiani uncovered — ventole, polvere, batteria UPS, AP secondario, surge protector
3. 3 GAP veri identificati: UniFi controller config NON backuppata (ISSUE-012 P1), UDM Pro config idem (ISSUE-013 P1), HA Voice PE firmware rollback procedure assente (ISSUE-014 P2)
4. Backup confidence MEDIA su 3 categorie: HA config (drift su update), Authentik Postgres restore, email storica integrita' import
5. 9 OPS recommendations quotidiane in nuova subsection §13: pulizia fisica G8, UPS battery health, etichette fisiche, smart home failsafe, 4G/5G dongle emergency, morning health check, btrfs scrub, config export UniFi/UDM, controlled firmware updates
6. Cose da NON fare (anti-over-engineering): nessuna nuova proibizione da aggiungere, st4ck gia' ha buona disciplina (vincolo soft §14 + decisioni differite)

Singola raccomandazione cross-cutting: introdurre un "monthly homelab check" (~1 ora) che esegua le 9 OPS-001..009 in checklist. Pattern mancante che chiude il gap "grandi rischi coperti, piccoli rischi quotidiani no".

Punteggio implicito vs homelab famiglia comparabili: top 5%. Documentazione + 6 audit precedenti + ADR + risk register + DR bozza posizionano st4ck nel range "homelab quasi-aziendale single-operator" senza essere over-engineered.

ISSUE/OPS generate: ISSUE-012, 013, 014 in §15 dossier + OPS-001..009 in nuova subsection §13.

Quando rifarlo: annuale, dopo cambi maggiori del parco hardware fisico (es. nuovo router, nuovo NAS), dopo un episodio operativo significativo (overheat, power outage major).

Lente: system architecture specialist che rivaluta il progetto nel suo complesso su orizzonte 3-10 anni: coerenza vision/implementazione, lock-in, scalabilità, TCO, what-if scenari, evoluzione incrementale.

Top findings:

1. Vendor independence dichiarata, ma lock-in CF cresciuto in 5 versioni (v1.4→v1.10): DNS+Tunnel+Pages+Access+WAF tutto Cloudflare. Trade-off pragmatico, ma manca exit strategy documentata
2. Bus factor = 1 rischio dominante. Aldo indisponibile 6 mesi = stack a rischio. Manca runbook step-by-step + chiavi recovery in safe + persona di fiducia onboarded
3. Postgres 14 EOL Nov 2026 (vincolo upstream Blinko) — riapertura ISSUE-003 con deadline hard
4. Mac mini M4 introdurrebbe macOS nello stack → secondo OS rompe la regola "tutto Linux + tutto Docker" pillar di mantenibilità
5. Modulo j4rv1s gonfia il monorepo — F4-F7 = 1500+ righe Python; valutare submodule prima di F4
6. DSM Synology EOL (~2027) — TrueNAS familiarizzazione lab già da Fase 3
7. 10 what-if scenari mappati (CF pricing 5x, hardware morto, OSS abbandonato, ecc.) con resilience analysis
8. Vincolo soft mantenibilità da codificare: ≤15 servizi attivi, ≤20 ISSUE aperte, ≤2 OS distinti

Risk register architetturale generato: RA-001..008 (vedi §15 dossier).

Raccomandazione strategica unica: dopo Fase 3 (off-site DR live), pausa consolidamento di 6 mesi. Operare. Imparare cosa rompe in produzione reale. Solo dopo, espandere j4rv1s F4-F7.

3 azioni critiche entro Fase 1: Plan B Cloudflare doc, Letter to family + DR runbook + chiavi safe, Risk register esplicito in §15. Effort totale: ~7 ore.

Quando rifarlo: annualmente, dopo decisioni architetturali maggiori (riapertura D2 j4rv1s, cambio storage stack, introduzione orchestrator), quando il dossier supera v3.0.