- configura.sh e progetti.sh escono 1 se un passo non riesce (scrittura di
~/.ssh/config, chiave SSH, clone, chiave AWS), e lo dicono in rosso;
- git: per l'indirizzo di Gitea si usa solo il gestore "store", e un token
vecchio rimasto in ~/.git-credentials si sostituisce (prima si aggiungeva
solo se mancava: API buona e git clone rotto). verifica.sh chiede a git la
credenziale che userebbe davvero, invece di accontentarsi di un gestore
qualsiasi;
- AWS: la chiave si controlla PRIMA di salvarla, e deve essere l'utente della
persona nell'account di OTO (ARN completo, non solo il nome). Senza Gitea il
passo si salta e verifica.sh non da' piu' verde a una chiave qualsiasi.
Avviso se AWS_PROFILE o AWS_ACCESS_KEY_ID... fanno usare un'altra chiave;
- API di Gitea: codice HTTP controllato, "Gitea non risponde" distinto da
"token non valido", elenco dei progetti interrotto solo su una pagina vuota
vera; token passato a curl da stdin; JSON letto anche con gli spazi;
- progetti.sh: nomi confrontati in modo esatto, accetta organizzazione/nome
e dice quando un nome corto e' ambiguo;
- la chiave ~/.ssh/oto_ed25519 viene collegata anche ai nomi che cercano i
deploy dei progetti (oto_staging_ed25519, oto_production_ed25519): su un
PC preparato da qui il primo deploy si fermava con "Chiave privata non
trovata";
- verifica.sh --senza-vpn, per chi non ha la VPN: staging giallo e non rosso.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
configura.sh (token Gitea, git, chiave SSH, nomi dei server), verifica.sh
(verde/rosso per ogni accesso), progetti.sh (scarica i repository visibili),
e un CLAUDE.md che guida la persona senza chiederle mai un segreto in chat.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
