Changelog - Template Bootstrap .Italia

• Header con spiegazione della governance
• List-group con link ai 3 rami attuali (1.2.x → corrente, 1.1.x → consolidate, 1.0.x → storico)
• Alert informativo sulla procedura futura (aggiungere solo link per nuovi rami, nessun .md da toccare)
• Footer con link di ritorno all'indice changelog generale

• Status: creato (nuovo)
• Contenuto: entry point stabile con link ai rami 1.0.x, 1.1.x, 1.2.x
• Impatto: diventa il riferimento unico nei file .md

• Aggiornamento: aggiunta sezione "Regola anti-impatto futuro (changelog beta)" con 4 regole operative
• Contenuto: tutte le referenze .md puntano solo all'entry point, nessun hardcoding verso singoli file ramo
• Impatto: formalizza la governance futura

• Aggiornamento: precisato che entry point è "stabile" e aggiunto riferimento ai file ramo nella sezione comandi preflight
• Impatto: checklist di chiusura release rimane invariata, solo chiarimento semantico

• Aggiornamento: sezione 1.0 "Nota di Coerenza (Sync & Recovery)" – precisato che changelog.html è entry point stabile e file ramo contengono dettagli operativi
• Impatto: procedura recovery aggiornata con riferimento esplicito a tutti e 3 file ramo

• Aggiornamento: identico a instruction.md § 1.0 (sezione duplicata per v3)
• Impatto: allineamento versione V3 con baseline

• Aggiornamento: sezione "Documentare nel Changelog (Step 8)" – clarificato che entry point è stabile e va specificato il changelog di ramo da aggiornare
• Impatto: procedura sync ora esplicita i due riferimenti (entry point + ramo)

• Aggiornamento: sezione 11 "Snapshot di allineamento documentale" – esteso il riferimento a sync/recovery con file ramo espliciti
• Impatto: recovery procedure documentata con referenze complete

• Aggiornamento: sezione "Riferimenti" – aggiunto "(entry point stabile verso i changelog di ramo)" per chiarezza
• Impatto: convenzione override rimane invariata, solo nota semantica aggiunta

• Colore base: color: var(--afterbottom-text-color, $afterbottom-text-color)
• Hover: color: var(--accent-light, $accent-color-1)
• Icone SVG: .icon { width/height: 1.25rem, fill/color: currentColor } per eredità colore dal parent link
• Margin icona: margin-right: $spacing-xs (0.25rem)

• Esteso selettore .mod-list, .nav { li a { ... } } con nuovi stili icon completi
• Aggiunto blocco .icon { ... } dentro li a per styling SVG icone
• Risultato: link e icone ora ereditano colore dal context afterbottom correttamente

• Aggiunto (dopo riga 33 nel blocco > li { ... }): regola &.active > .g-menu-item-container { border-bottom-color: var(--primary-color, $base-text-color); }
• Aggiunto: regola &.active.menu-parent-indicator > .g-menu-item-container { border-bottom-color: transparent; } per override selettivo su parent item
• Risultato: comportamento coerente e intuitivo che guida l'utente nella navigazione gerarchica senza ambiguità

colors (array):
              [0] '#0066cc'      → primary base
              [1] '#bfdfff'      → primary-light (GENERABILE: mix($white, primary, 75%))
              [2] '#1887F5'      → primary-medium (POSSIBILE DUPLICATE?)
              [3] '#101d35'      → primary-dark
              [4] '#dce9f5'      → accent-light (GENERABILE: mix($white, primary, 85%))
              [5] '#004d99'      → accent-dark (GENERABILE: darken(primary, 10%))
              [6] '#003366'      → accent-darker (RARAMENTE USATO)

• Indice [1] primary-light: mix($white, #0066cc, 75%) produce valore molto simile a '#bfdfff'
• Indice [4] accent-light: mix($white, #0066cc, 85%) produce valore molto simile a '#dce9f5'
• Indice [5] accent-dark: darken(#0066cc, 10%) produce valore molto simile a '#004d99'
• Indice [6] accent-darker: RIDONDANTE, presente ma mai consumato nei dati attuali

• KEEP [0] = primary base (required)
• REMOVE [1] → generiamo al compile-time tramite mixin
• INVESTIGATE [2] = primary-medium (verificare se è duplicate di [0] o intenzionale)
• KEEP [3] = primary-dark (required, non generabile in modo affidabile)
• REMOVE [4] → generiamo al compile-time tramite mixin
• REMOVE [5] → generiamo al compile-time tramite mixin
• REMOVE [6] → non usato, candidato eliminazione

• File: gantry/presets.yaml
• Struttura: array di 7 colori per ciascun preset (base, verde, rosso, neutro)
• Responsabilità: DEFINIRE i colori come source-of-truth per l'installazione distribuita

• File: gantry/theme.yaml
• Struttura: blueprint espone i colori come parametri della UI Gantry admin
• Responsabilità: ESPORRE la struttura array ai preset-switcher particle e alle configurazioni override runtime

• File: particles/bootstrapitalia-preset-switcher.html.twig, particles/bootstrapitalia-preset-switcher.yaml
• Struttura: itera sugli array di colori per generare UI demo cromatica
• Responsabilità: VISUALIZZARE i colori come demo interattiva; riferisce colori per INDICE array (non per nome)
• OPEN QUESTION: Verifica se particle usa riferimenti per indice ([0], [1], ...) o per nome (primary-base, primary-light, ...)

• File: scss/bootstrapitalia-joomla/_core.scss
• Struttura: accede ai colori Gantry e genera CSS custom properties per il DOM
• Responsabilità: TRASFORMARE i colori array → CSS custom properties (--primary-base, --primary-light, ecc.)
• OPEN QUESTION: Come accede ai colori? Via Gantry variables? Interpolazione SCSS array? Mixin che legge presets.yaml?

• File: template Twig sections (afterbottom, footer, header, ecc.)
• Struttura: applica le CSS custom properties tramite var(--property-name, fallback)
• Responsabilità: CONSUMARE le custom properties per styling runtime

• È un file PHP Gantry (particle factory)?
• È una compilazione SCSS che legge la struttura?
• È generato runtime dal preset-switcher?
• IMPATTO: Blocca la decisione su dove eseguire la generazione di mix()/darken()

• Se usa indici: la refactor da array → map richiede aggiornamento del template Twig
• Se usa nomi: la refactor potrebbe essere reversibile con alias backward-compatible
• IMPATTO: Determina la complessità di migrazione verso struttura map vs array

• Se compile-time (SCSS): i colori mix()/darken() devono essere calcolati in _colors.scss
• Se runtime (PHP/Twig): i colori possono rimanere array e trasformarsi in DOM runtime
• IMPATTO: Determina se il refactoring richiede modifiche SCSS o PHP

• Alias di fallback? (es. $colors-primary-light: $colors[1] o $colors[primary-light]?)
• Versioning di preset.yaml (v2 con map, v1 deprecato)?
• Nuova chiave di blueprint parallel alla vecchia durante transizione?
• IMPATTO: Determina il numero di file da modificare e il risk di regressione

• Rimosso: border-bottom-color dal blocco &:hover, &.active
• Rimosso: blocco .nav.mod-list { ... } (migrato a Joomla layer)
• Risultato: menu principale pulito, nessun border redundante

• Aggiunto: completo blocco .nav.mod-list { ... } dal layer base
• Aggiornato: separatore da \f105 a ›, transizione smooth, underline hover
• Risultato: Joomla-specific styling centralizzato e coerente

• Aggiunto: background-color e color alla radice #g-afterbottom
• Aggiunto: spacing tra moduli con selettore .platform-content + .platform-content
• Aggiornato: font-size h3→h4 in .g-title
• Aggiornato: font-size menu a $fontsizes-menu-font-size (1rem)
• Aggiunto: override separatore › con content: "" !important; display: none;
• Aggiunto: underline base e hover su link menu
• Risultato: sezione completamente ottimizzata secondo pattern CSS custom properties

• Analizzato: struttura array 7 colori per preset
• Identificati: candidati a riduzione/generazione SCSS
• Demandata: decisione di refactor a session dedicata

• Verificato: coerenza colori rosso preset con gantry/presets.yaml
• Confermato: background '#cc334a', text '#ffffff', heading '#ffffff'