Se il pulsante Publish o Update mostra "Your Cloud Balance is insufficient to publish" oppure "Your Cloud Balance is insufficient to update", significa che il tuo portafoglio Cloud è esaurito.

Per risolvere:

1. Vai su Settings > Cloud & AI per controllare il tuo saldo attuale.

2. Seleziona Top up now e aggiungi fondi al tuo portafoglio Cloud.

3. Torna al pannello Publish e riprova.

Nota: il tuo portafoglio Cloud è separato dai crediti del tuo abbonamento. Il portafoglio Cloud finanzia i servizi di hosting e deployment, mentre i crediti dell'abbonamento vengono usati per le conversazioni con l'agente IA.

1. Controlla la vista di utilizzo dello spazio di archiviazione e individua le chat, i progetti e i file più grandi.
2. Scarica o esegui il backup di tutto ciò che potrebbe servirti in seguito.
3. Elimina solo gli elementi non necessari. Se l'eliminazione della chat offre di rimuovere i dati su disco associati, seleziona quell'opzione solo dopo aver confermato che i dati possono essere eliminati in sicurezza.
4. Aggiorna la pagina e conferma che lo spazio disponibile sia aumentato.
5. Torna a Publish e riprova una volta.

L'eliminazione può essere permanente e può compromettere un progetto che fa riferimento a un file rimosso. Se l'utilizzo non diminuisce, contatta il Supporto con la vista dello spazio di archiviazione, il piano, il link del progetto e l'ora del tentativo di pubblicazione non riuscito.

Attendi che la scansione di sicurezza termini, poi controlla ogni elemento segnalato prima di pubblicare.

1. Seleziona Resolve All e controlla il comportamento interessato. Correggi i problemi che coinvolgono segreti esposti, autenticazione, autorizzazioni, dati utente o accesso esterno non sicuro prima dell'uso in produzione.
2. Se un segreto potrebbe essere stato esposto, rimuovilo dal progetto e ruotalo tramite il provider pertinente prima di pubblicare.
3. Esegui di nuovo la scansione e verifica il flusso interessato.
4. Usa Publish Anyway solo quando un revisore responsabile comprende e accetta il rischio residuo non critico. Registra il motivo ed evita di aggirare un rischio non risolto su un sito di produzione.

Se non riesci a determinare l'impatto di un risultato, non pubblicarlo. Contatta il Supporto o il responsabile della sicurezza con il testo del risultato e prove sanificate.

1. Testa separatamente l'URL di produzione della piattaforma e il dominio personalizzato. Confronta anche la pagina principale con la pagina specifica o il percorso API che non funziona.
2. Registra il codice di stato esatto, l'URL completo, l'ora e il fuso orario, e se il problema è costante o intermittente.
3. Controlla lo stato dell'ultimo deployment e verifica se una modifica recente a dipendenze, variabili d'ambiente, Database o servizi esterni coincide con l'inizio del problema.
4. Acquisisci gli errori rilevanti di Console e Network.

Se il problema continua, contatta il Supporto con i passaggi per riprodurlo, la versione interessata e la diagnostica sanificata. Prima di inviare un HAR, output di comandi o screenshot, rimuovi cookie, header Authorization, token, parametri di query segreti, dati personali e informazioni di pagamento.

Se il tuo deployment va in timeout o il sito live è temporaneamente non disponibile:

1. Controlla se sia il sottodominio Prod della piattaforma sia Preview sono inaccessibili, oppure solo uno dei due.

2. Mantieni visibile la pagina di errore corrente — non fare clic ripetutamente su Publish.

3. Controlla se hai modificato di recente dipendenze, punti di ingresso di avvio o connessioni al Database, poiché queste modifiche possono influire sul deployment.

Se il problema persiste, contatta il Supporto e includi:

- Link del progetto e URL live

- Ora del problema e tuo fuso orario

- Numero di versione e screenshot della pagina di errore

- Se Preview funziona normalmente

- Se hai modificato di recente dipendenze, voce di avvio o connessione al Database

Se il pannello Publish mostra "latest" con il pulsante disattivato, oppure è bloccato su "Building":

1. Non fare clic ripetutamente su Publish — questo non velocizzerà il processo e potrebbe creare attività di build duplicate.

2. Attendi qualche minuto e aggiorna la pagina.

3. Se lo stato non cambia dopo l'aggiornamento, contatta il Supporto.

Includi quanto segue quando contatti il Supporto:

- Link della chat

- Screenshot completo del pannello Publish (inclusi URL della pagina, numero di versione e stato del pulsante)

- Ora dell'evento e tuo fuso orario

- Numero di versione attualmente visualizzato

- In quale passaggio ha iniziato a mostrare "Building" oppure il pulsante è diventato disattivato

1. Controlla se l'immagine manca in Visualizzatore App, sul sito pubblicato o in entrambi.
2. Seleziona Reload App Viewer una volta. Se il problema è solo sul sito live, conferma che l'ultima versione sia stata pubblicata o aggiornata.
3. Comunica all'Agente la pagina, l'immagine che dovrebbe apparire e da dove proveniva originariamente l'immagine. Chiedigli di controllare che il progetto corrente utilizzi ancora il nome e la posizione corretti dell'immagine.
4. Se l'immagine originale è stata rimossa o rinominata, carica o seleziona di nuovo l'immagine desiderata, poi ritesta la pagina.
5. Se l'immagine usa Archivio App o un altro servizio collegato, conferma che il servizio previsto sia collegato e che il file esista ancora lì.

Se l'immagine continua a non caricarsi, contatta Atoms Support con il Chat Link, l'URL della pagina interessata, il nome o la sorgente dell'immagine e uno screenshot. Non includere link di accesso privati, password, chiavi o token.

Se il pacchetto self-host esportato viene scaricato correttamente ma non si avvia:

1. Controlla il README incluso nel pacchetto di esportazione per i requisiti dell'ambiente e i passaggi di configurazione.

2. Verifica che il tuo ambiente di runtime corrisponda ai requisiti (versione del sistema operativo, versione di Docker, versione di Node.js).

3. Esegui il comando di avvio e controlla l'output completo per eventuali messaggi di errore.

Se il problema persiste, contatta il Supporto e includi:

- Versione dell'esportazione e ora del download

- Sistema operativo in uso e versione di Docker

- Comando completo eseguito e output completo

- Script o percorso API non riuscito

- Metodo di deployment previsto

Importante: allega un esempio di configurazione sanificato, ma NON includere password, segreti o token.

Visualizzatore App e il sito pubblicato mostrano fasi diverse del tuo progetto. Salvare una modifica visiva non aggiorna da solo il sito live.

1. In Design, seleziona Save e attendi che l'attività corrente dell'Agente o la build termini.
2. Apri Publish. La pubblicazione usa la versione più recente del progetto; nel pannello Publish non c'è un selettore di versione.
3. Seleziona Publish per la prima release oppure Update per una release successiva. Attendi finché il pannello mostra Up to date.
4. Apri il sito live in una nuova scheda e ricaricalo una volta.
5. Se l'indirizzo Atoms predefinito mostra la modifica ma un dominio personalizzato no, controlla invece la connessione del dominio anziché pubblicare ripetutamente la stessa versione.

Se il sito live continua a mostrare la versione sbagliata, contatta Atoms Support con il Chat Link, l'URL live, la versione che intendevi pubblicare, l'ora e il fuso orario, e screenshot di Visualizzatore App e del sito live.

1. Contieni il rischio immediato. Se la release espone dati sensibili o crea un comportamento non sicuro, apri App Status e usa Pause per un'app Atoms Cloud idonea oppure Unpublish per rimuovere l'accesso pubblico. Se non c'è un rischio attivo, evita di causare un'interruzione non necessaria.
2. Registra il dominio interessato, l'ora di pubblicazione, la versione corrente, la versione prevista e l'impatto sul business.
3. Dopo che l'attività corrente dell'agente si è fermata, apri Versions, scegli l'ultima versione sicuramente funzionante e seleziona Restore this version.
4. Verifica la versione ripristinata in Preview, inclusi i flussi critici di accesso, pagamento e dati, poi pubblicala o aggiornala.

Il ripristino di una versione del progetto potrebbe non annullare le modifiche al Database di produzione o le azioni esterne. Non sovrascrivere o eliminare dati di produzione per imitare un rollback. Contatta immediatamente il Supporto quando sono coinvolti dati, credenziali, pagamenti o modifiche distruttive.

1. Interrompi o attendi l'attività corrente dell'agente; una versione non può essere ripristinata mentre è attivo un lavoro in conflitto.
2. Apri Versions, individua l'ultima versione sicuramente funzionante e seleziona Restore this version.
3. Controlla il progetto ripristinato in Preview e testa i flussi critici che sono cambiati.
4. Pubblica o aggiorna solo dopo che il risultato in Preview è corretto.

Il ripristino di una versione del progetto non comporta necessariamente il rollback dei record del Database di produzione, delle modifiche allo schema, delle variabili d'ambiente, dei pagamenti, delle email o di altre azioni esterne. Se la release ha modificato dati di produzione o la versione di destinazione non è disponibile, fermati e contatta il Supporto con entrambi i numeri di versione, il dominio interessato e il risultato richiesto per la conservazione dei dati.

Pause e Unpublish sono due azioni diverse:

Pause (solo progetti Atoms Cloud):

- L'app diventa non disponibile per i visitatori.

- Le risorse del server restano allocate e la fatturazione continua.

- Puoi riprendere l'app in qualsiasi momento da App Status.

Unpublish (tutti i progetti):

- Il sito web va completamente offline. Chiunque usi l'URL pubblicato perde l'accesso.

- Per i progetti Atoms Cloud, le risorse del server vengono rilasciate.

- Puoi pubblicare di nuovo il progetto in seguito, ma i visitatori non potranno accedervi finché non lo farai.

Usa Pause per una rimozione temporanea con riavvio rapido. Usa Unpublish per rimuovere completamente il sito.

Se il browser mostra "too many redirects" oppure la pagina continua a ricaricarsi senza mostrare contenuti:

1. Prova il sottodominio Prod predefinito della piattaforma (non il tuo dominio personalizzato) per determinare se il loop di reindirizzamento è causato dalla configurazione del dominio o dall'applicazione stessa.
2. Se il sottodominio Prod predefinito funziona, controlla le impostazioni DNS del tuo dominio personalizzato e il registrar del dominio per eventuali regole di reindirizzamento che potrebbero entrare in conflitto con la piattaforma.
3. Svuota la cache del browser oppure prova in una finestra in incognito per escludere reindirizzamenti memorizzati nella cache.

Se il problema persiste, contatta il Supporto e includi:

- URL completo che mostra il loop di reindirizzamento

- Se il sottodominio Prod predefinito è accessibile

- Nome del dominio e provider DNS

- Screenshot completo dell'errore

Se la tua app funziona in Preview ma non in produzione a causa di variabili d'ambiente mancanti o vuote:

1. Controlla se la variabile d'ambiente è stata salvata prima o dopo l'ultima pubblicazione. Se è stata salvata dopo, devi pubblicare di nuovo affinché la modifica abbia effetto.
2. Verifica che la variabile sia impostata per l'ambiente corretto (Development vs. Production).
3. Controlla se il messaggio di errore del servizio downstream fornisce un indizio — per esempio, "unauthorized" spesso significa che una chiave API è vuota o non corretta in quell'ambiente.

Se il problema persiste, contatta il Supporto e includi:

- Link del progetto o URL live

- Il nome della chiave interessata e quale ambiente presenta il problema

- L'errore completo del servizio downstream

- Uno screenshot sanificato della pagina di configurazione

- Se la configurazione è stata salvata prima o dopo la pubblicazione

Importante: fornisci solo i nomi delle chiavi. NON inviare valori segreti, password o token.

I risultati possono usare una formulazione simile pur indicando posizioni diverse. Una formulazione simile non significa necessariamente che i risultati siano duplicati.

1. Confronta il nome del risultato e la posizione mostrata per ciascun elemento.
2. Controlla ogni posizione unica invece di ignorare la formulazione ripetuta.
3. Se diversi risultati hanno la stessa causa sottostante, correggi quella causa e poi controlla di nuovo ogni posizione.
4. Esegui di nuovo la scansione di sicurezza sulla versione aggiornata.

Se lo stesso risultato e la stessa posizione continuano a comparire più di una volta, contatta Atoms Support con il Chat Link, l'ora della scansione e il fuso orario, il numero di risultati e uno screenshot oscurato. Rimuovi eventuali password, chiavi, token o altre informazioni sensibili che potrebbero comparire in un risultato.

Una scansione completata senza risultati segnalati è un controllo utile, ma non può garantire che ogni problema di sicurezza o di runtime sia stato trovato. La scansione controlla la versione del progetto selezionata; la tua app deve comunque essere testata nel modo in cui gli utenti reali la useranno.

Prima di pubblicare, testa i percorsi importanti della tua app, inclusi accesso, ruoli utente, accesso ai dati privati, pagamenti e servizi collegati. Usa account di test separati per ruoli diversi e conferma che ogni account possa accedere solo alle informazioni e alle azioni previste per esso.

Se scopri un problema in produzione che potrebbe esporre account, dati privati, pagamenti o credenziali, interrompi l'uso o limita prima l'accesso alla funzionalità interessata. Ruota qualsiasi credenziale che potrebbe essere stata esposta, poi contatta Atoms Support con il Chat Link, la versione interessata, i passaggi per riprodurre il problema, l'ora e il fuso orario, e uno screenshot oscurato. Non condividere la credenziale esposta stessa.

Se la scansione segnala che un'azione riservata agli amministratori potrebbe non essere protetta, tratta il risultato come non risolto finché non confermi che utenti non autorizzati non possano usarla. Nascondere un pulsante amministratore non è sufficiente se l'azione può comunque essere richiesta in un altro modo.

1. Apri il risultato e identifica l'azione o la posizione che nomina.
2. Decidi quali ruoli autenticati dovrebbero essere autorizzati a usare quell'azione.
3. Chiedi all'Agente di controllare il permesso dell'utente quando l'azione viene richiesta, non solo quando il pulsante viene mostrato.
4. Testa l'azione da disconnesso, con un normale account di test e con un account di test amministratore autorizzato.
5. Conferma che i tentativi rifiutati non rivelino dati privati e non apportino modifiche, poi esegui di nuovo la scansione di sicurezza.

Non pubblicare la funzionalità interessata se un account non autorizzato può ancora usare l'azione. Contatta Atoms Support con il Chat Link, il testo del risultato, la versione interessata e uno screenshot oscurato se non riesci a risolverlo.

HTTPS protegge le informazioni mentre viaggiano tra un utente e un servizio. Se la scansione segnala un problema HTTPS, usa il risultato esatto per identificare l'indirizzo, la risorsa, il callback o la configurazione del dominio interessati.

1. Apri il risultato e annota la posizione e l'indirizzo esatti che segnala.
2. Chiedi all'Agente di sostituire quella connessione specifica con l'indirizzo sicuro supportato dal relativo provider, oppure di correggere la configurazione del dominio correlata.
3. Non ignorare gli avvisi sui certificati e non cambiare un indirizzo alla cieca se il servizio esterno non documenta un equivalente sicuro.
4. Ritesta il percorso utente interessato e conferma che nessuna password, token, dettaglio di pagamento o informazione privata venga inviata tramite una connessione non sicura.
5. Esegui di nuovo la scansione di sicurezza sulla versione aggiornata.

Se il risultato riguarda un dominio personalizzato o un certificato che non riesci a correggere, contatta Atoms Support con il Chat Link, l'URL interessato, il testo del risultato, l'ora e il fuso orario, e uno screenshot oscurato.

Row Level Security, o RLS, è una funzionalità di Supabase che controlla quali righe del Database ogni utente può leggere o modificare. Questo risultato è rilevante solo quando il progetto usa Supabase e la scansione identifica una tabella le cui regole di accesso devono essere controllate.

1. Apri il risultato e identifica la tabella che nomina.
2. Scrivi chi dovrebbe poter visualizzare, aggiungere, modificare o eliminare i dati di quella tabella.
3. Chiedi all'Agente di creare i criteri Supabase meno permissivi che supportino quei percorsi utente.
4. Testa da disconnesso e con un account di test separato per ogni ruolo. Conferma che ogni account possa accedere solo alle righe e alle azioni previste.
5. Esegui di nuovo la scansione di sicurezza dopo l'applicazione dei criteri.

Non disattivare RLS e non consentire l'accesso a tutti gli utenti solo per eliminare l'avviso. Prima di apportare una modifica che potrebbe influire sui dati esistenti, conferma il piano e conserva un backup o un'esportazione sicura, se appropriato. Non condividere mai chiavi Supabase o credenziali del Database in Chat o negli screenshot.