Come ho fatto il portfolio che stai guardando

Non tutte le decisioni erano tecniche. Sul telefono i tre pilastri della home erano impilati e centrati, e da soli occupavano metà della sezione, così il primo progetto arrivava dopo più di due schermate di scroll. Li ho messi in riga, con l'icona a sinistra e il testo accanto, e il lavoro ora arriva dopo una schermata e mezza.

Un'immagine che sul mio computer era nitida usciva sgranata sul sito. L'AI mi ha proposto tre soluzioni, consigliandone una, e le ho scartate tutte chiedendo invece se bastasse cambiare la risoluzione. Non bastava, ma la domanda ha spostato il problema: partire da un'immagine grande e lasciare che il browser la riducesse la ammorbidiva. La soluzione è stata esportare da Figma due versioni alla larghezza esatta con cui compare nella pagina, in 1× e in 2×.

Quando controllare tutto a occhio è diventato lungo e poco affidabile, ho fatto scrivere all'AI una suite di test su due livelli. Il primo gira in tre secondi sulla build finita e verifica le cose che si rompono in silenzio, come link, asset, tag SEO e script inline. Il secondo apre il sito in un browser vero con Playwright, prova le interazioni, controlla l'overflow a 390, 800 e 1440 pixel, passa axe per l'accessibilità e confronta gli screenshot con una baseline. L'ottica era controllare i guasti meccanici e lasciare a me il giudizio sul look and feel, per questo il confronto visivo segnala le differenze e non blocca niente.

$ pnpm test
▸ build…
  ok in 2.0 s
▸ controlli statici, browser e confronto visivo…
✔ /: ogni link e asset interno esiste in dist/
✔ CSP: ogni <script> inline di ogni pagina ha il suo hash
✔ carousel Works: il pallino N porta alla slide N e aggiorna aria-current
✔ /about/: nessun overflow orizzontale a 390px (mobile)
✔ / a 1440px: nessuna violazione axe seria o critica
…
ℹ tests 118
ℹ pass 118
ℹ fail 0

◎ confronto visivo: 12 da guardare su 21

Con la stessa logica ho fatto aggiungere la sicurezza. A ogni build uno script scrive gli header e una Content Security Policy che elenca l'hash di ogni script inline, così uno script nuovo è coperto da solo e uno esterno viene bloccato. Il sito non carica niente da altri domini, e se un controllo è rosso, che si tratti di una dipendenza con una vulnerabilità alta o di uno script senza hash, un hook ferma il push su main, che su Cloudflare vuol dire pubblicare.

▸ push su main: lancio la suite di test prima di pubblicare
▸ build…
  ok in 2.5 s
▸ controlli statici, browser e confronto visivo…
✖ /: nessun errore JS e nessuna risorsa mancante
✖ nessuna pagina carica script, stili o font da un altro dominio
…
ℹ tests 118
ℹ pass 110
ℹ fail 8

  Loading the script 'https://cdn.example.com/analytics.js' violates
  the following Content Security Policy directive (…)
  The action has been blocked.

✗ suite rossa: il push su main è stato fermato.
  Per pubblicare comunque: git push --no-verify