# Overview delle tre idee evolutive

Documento di sintesi che mette in relazione i tre piani esplorativi:

- [idea-1-python-rewrite.md](idea-1-python-rewrite.md) — Conversione del sistema in Python
- [idea-2-linux-host.md](idea-2-linux-host.md) — Host CI su Linux Mint
- [idea-3-esxi-support.md](idea-3-esxi-support.md) — Build VM su ESXi remoto

---

## Matrice di sinergia

| Combinazione                            | Sinergia | Note                                                                             |
| --------------------------------------- | -------- | -------------------------------------------------------------------------------- |
| Solo Idea 1 (Python)                    | Neutra   | Refactor "interno", nessun beneficio funzionale immediato. Utile se prerequisito a 2/3. |
| Solo Idea 2 (Linux host + KVM)          | Alta     | Cambio piattaforma; PS 7 possibile ma Python (Idea 1) consigliato.               |
| Solo Idea 3 (ESXi backend)              | Alta     | Compatibile con stato attuale; PowerCLI o pyVmomi.                               |
| Idea 1 + Idea 2                         | **Molto alta** | La rewrite Python rimuove l'attrito cross-platform.                              |
| Idea 1 + Idea 3                         | **Molto alta** | `pyVmomi` è Python-only.                                                         |
| Idea 2 + Idea 3                         | Media    | Host Linux + build ESXi: massimo decoupling, ma rischi sommati.                  |
| Idee 1 + 2 + 3                          | Alta     | Massima modernizzazione. Da scaglionare in 3 milestone separate.                 |

---

## Ordine consigliato (se si vogliono perseguire tutte)

1. **Idea 1 prima fase** (estrarre `_Common` + `_Transport` in Python con
   strangler fig) — riduce rischio futuro senza rompere niente.
2. **Idea 3 con backend astratto** (sui job sperimentali, label dedicata) —
   sblocca scalabilità.
3. **Idea 1 fasi 2-4** (completamento rewrite Python).
4. **Idea 2** (migrazione host Linux) — solo dopo 1 e 3 stabili.

Andare nell'ordine inverso (prima Linux, poi ESXi, infine Python) raddoppia
il debito tecnico nei periodi intermedi.

---

## Quando NON fare nulla

Il sistema attuale è documentato come `production-ready`. Astenersi se:

- La concorrenza richiesta è ≤4 job e l'hardware regge.
- Non c'è pressione team su preferenze cross-platform.
- Non si pianifica espansione hardware nei prossimi 6 mesi.
- Il budget tempo è meglio speso in nuovi workflow CI per altri repo.

In quel caso, l'investimento migliore è **estendere i test** (`tests/` Pester
attuali), aggiungere osservabilità (`Get-CIJobSummary`, metriche) e
documentare meglio l'esistente — non riscrivere.