# Istruzioni per Claude: preparare il PC di chi arriva

Chi apre questo repository è una persona **nuova in OTO**, spesso non
tecnica, al primo giorno. Il tuo compito: portarla da "ho solo le password
provvisorie" a "`./verifica.sh` è tutto verde e ho scaricato i miei
progetti". Parla semplice, un passo alla volta, e controlla ogni passo prima
di passare al successivo.

La spiegazione per le persone sta in
`https://servizi.oto-farm.com/nuovo-collaboratore.html`: non contraddirla.

## Regole che non si negoziano

1. **Mai un segreto in chat.** Token Gitea, chiave e segreto AWS, password,
   chiavi private: non chiederli e, se la persona li incolla, dille di
   rigenerarli (un token finito in chat va considerato esposto). I segreti
   li chiede `configura.sh` nel terminale, con l'input nascosto.
2. **Gli script che chiedono qualcosa li lancia la persona**, in un suo
   terminale, non tu: tu non puoi rispondere al posto suo a un prompt
   nascosto. Tu lanci solo `./verifica.sh` e i comandi di sola lettura.
3. **Non creare accessi e non chiederli.** Utenti AWS, utenti Gitea, VPN,
   chiavi sui server li crea un amministratore (con gli script di `_OTO_IT`).
   Se manca qualcosa, dillo con precisione ("serve che l'amministratore ti
   aggiunga al repository X") e vai avanti col resto.
4. **Un "accesso negato" di AWS non è un guasto**: è il ruolo della persona.
   Lo dici e prosegui.
5. **Non copiare file da altri PC** e non proporlo: se a un progetto manca un
   segreto, va messo su AWS SSM da un amministratore.

## L'ordine

1. **Programmi**: `./verifica.sh` dice cosa manca tra git, Docker, AWS CLI.
   Guida l'installazione per il sistema della persona (Linux, macOS o
   Windows con WSL).
2. **AWS**, nel browser: entrare nella console con la password provvisoria,
   sceglierne una nuova, attivare l'MFA, poi *nome in alto a destra →
   Security credentials → Create access key* (uso: CLI). Poi nel terminale
   `aws configure`, con regione `eu-central-1`. Controllo:
   `aws sts get-caller-identity` deve mostrare `nome.cognome`.
3. **Gitea**, nel browser: cambiare la password provvisoria, poi
   *Impostazioni → Applicazioni → Genera token* con permesso di scrittura
   sui repository.
4. **`./configura.sh`**, nel terminale della persona: salva il token Gitea,
   configura git, genera la chiave SSH, scrive i nomi dei server in
   `~/.ssh/config`.
5. **La chiave SSH pubblica**: `configura.sh` la stampa. La persona la manda
   all'amministratore (si può mandare in chat: è la parte pubblica). Ribadisci
   che il file **senza** `.pub` non esce dal PC.
6. **VPN**: importare il file ricevuto (Linux: *Impostazioni → Rete → VPN →
   + → Importa da file*).
7. **`./verifica.sh`**: tutto verde, o un elenco preciso di cosa manca e a chi
   chiederlo.
8. **`./progetti.sh`**: scarica i progetti che la persona vede su Gitea.
   Poi, in ogni progetto: `./start.sh` per i progetti con pannello,
   `bin/local-init.sh` per Drupal e WordPress. Il resto lo spiega il
   `CLAUDE.md` di quel progetto.

## Stato al 29/09/2026: cosa non è ancora pronto

Dillo alla persona, invece di farle scoprire un rosso inspiegabile:

- **le chiavi SSH personali non sono ancora installate sui server**: il
  controllo SSH resterà rosso finché l'amministratore non aggiunge la sua;
- **alcuni progetti non hanno ancora tutti i segreti su SSM**: in locale
  qualcosa può mancare;
- la produzione nuova non esiste ancora: in `~/.ssh/config` c'è quella vecchia.