# Prepara il tuo progetto per Alaska

Continua nella chat dove hai progettato la tua app. Copia queste istruzioni e incollale in ChatGPT o Claude.

## Testo da copiare nella chat

> Prepara il progetto che abbiamo discusso per Alaska seguendo le istruzioni ufficiali disponibili qui: https://appalaska.com/guide/prepara-progetto.html. Leggi la guida prima di procedere. Recupera le decisioni e i materiali già presenti nella conversazione. Chiedimi soltanto le informazioni essenziali mancanti, senza ripetere domande già risolte. Prepara il pacchetto richiesto dalla guida con brief, specifiche UX/UI, asset disponibili e istruzioni per Alaska. Segnala ciò che manca senza inventarlo. Se non puoi aprire il link o generare lo ZIP, dichiaralo.

Se la chat non riesce ad aprire il link, copia e incolla le istruzioni complete riportate sotto.

## Istruzioni complete per l’assistente

Versione 1.0 · 16 ottobre 2026

### 1. Riparti dalla conversazione

Leggi il progetto già discusso, le decisioni dell’utente e i materiali effettivamente accessibili. Conserva scelte, priorità, nomi e direzione visiva approvati. Non chiedere di nuovo ciò che è già risolto. Distingui sempre requisiti confermati, proposte da approvare e informazioni mancanti. Non ampliare arbitrariamente le funzioni e non trasformare una proposta in una decisione.

Chiedi solo chiarimenti che cambiano materialmente il risultato: piattaforma, flusso principale, destinatari, dati o integrazioni indispensabili. Raggruppa le domande essenziali. Per gli altri vuoti, registra il punto aperto; non inventare risposte né bloccare la preparazione dei materiali già definiti. Se non puoi leggere questa guida, altri link o allegati, dichiaralo e chiedi il contenuto necessario.

### 2. Che cosa riceve davvero Alaska

Alaska riceve descrizioni e allegati nella chat del progetto. Il client Web permette di allegare uno ZIP: i file vengono estratti come materiali del progetto, inclusi asset di formati non interpretabili direttamente. Non esiste uno schema obbligatorio dei nomi né un validatore di questo pacchetto progettuale. La struttura sotto è una convenzione consigliata per rendere le istruzioni chiare.

Prepara specifiche per un’app iOS o Web, oppure per entrambe, secondo le decisioni dell’utente. Se sono richieste altre piattaforme, registrale come esigenza da verificare con Alaska: questa guida non ne attesta il supporto. Per le nuove app Alaska usa anche React Native/Expo con anteprima Web e percorso di build iOS. Lo ZIP è materiale per la progettazione e realizzazione, non una promessa che qualunque repository o prototipo venga eseguito senza adattamenti.

L’anteprima, le integrazioni e la distribuzione dipendono dal progetto e dagli accessi configurati. Un caricamento riuscito non prova che l’app sia completa, che tutti gli asset siano stati interpretati o che sia stata pubblicata. Configurazione Apple, TestFlight e App Store sono passaggi successivi e distinti dalla consegna dello ZIP. Non promettere supporto universale, importazione Figma automatica, collegamento automatico alla chat originale o pubblicazione automatica.

### 3. Brief, funzioni e confini

Definisci nome del progetto, piattaforma richiesta, utenti, problema, obiettivo e risultato principale. Elenca funzioni confermate in ordine di priorità, esclusioni esplicite e vincoli. Separa le proposte opzionali e le questioni aperte. Indica la lingua e i dispositivi previsti. Non sostituire una specifica completa già approvata con un MVP ridotto senza consenso.

### 4. UX e interfaccia

Descrivi il percorso principale dall’ingresso al completamento e i flussi secondari confermati. Specifica navigazione, schermate, contenuti, campi, azioni e testi visibili. Per ogni schermata rilevante descrivi stato iniziale, caricamento, assenza di dati, successo ed errore, con recupero e validazioni. Indica indietro, annullamento, conferme ed effetti delle azioni sui dati.

Specifica colori con valori, tipografia e alternative disponibili, gerarchia, spaziature, componenti e comportamento delle interazioni: selezione, focus, disabilitazione, feedback e adattamento alle dimensioni dello schermo. Conserva il design approvato. Quando un dettaglio non è deciso, chiamalo proposta; non dichiararlo approvato. Considera leggibilità, contrasto, etichette accessibili e aree di tocco.

Includi i mockup disponibili come riferimenti, indicando schermata e stato rappresentati. Un mockup è una guida visiva, non una funzione già implementata. Se un file Figma non è esportabile o un link non è accessibile, elencalo tra i materiali mancanti e richiedi un’esportazione utilizzabile soltanto se essenziale.

### 5. Asset e provenienza

Allega gli asset reali come file separati dai documenti: loghi, icone, immagini e altri materiali supportati. Non usare uno screenshot dell’intera schermata al posto delle immagini che l’app deve utilizzare. Distingui asset pronti all’uso, riferimenti visivi e elementi ancora da produrre.

Per ogni asset disponibile indica percorso relativo nel pacchetto, funzione, schermata, provenienza e condizioni d’uso note. Se licenza, autore o diritto d’uso non sono noti, scrivi “da verificare”; non inventare licenze o autorizzazioni. Puoi includere font e altri file reali nello ZIP: indica nome, origine e ruolo, distinguendo la conservazione del file dalla capacità di leggerlo o usarlo, che va verificata. Non generare immagini senza strumenti disponibili e non descrivere un’immagine proposta come un file pronto.

### 6. Dati, accessi e integrazioni

Descrivi dati ed entità, esempi sintetici, persistenza locale o remota, relazioni, regole di aggiornamento e cancellazione, ruoli e isolamento tra utenti, se previsti. Specifica permessi del dispositivo necessari e quando richiederli. Distingui dati di esempio da dati reali; non inserire dati personali reali non necessari.

Per ciascuna integrazione richiesta indica servizio, scopo, operazioni, dipendenze e comportamento quando manca o non risponde. Distingui integrazioni richieste, già configurate con prova disponibile e da verificare. Non dare per disponibili servizi, connessioni o backend solo perché citati nella chat.

Elenca gli accessi da configurare separatamente con Alaska: per esempio account Apple per la distribuzione iOS, progetto dati o servizio esterno quando necessario. Nel pacchetto non includere password, token, chiavi API, certificati, cookie di sessione, file .env o altri segreti. Non richiedere di incollarli nella conversazione: usa le procedure dedicate del servizio.

### 7. Struttura consigliata del pacchetto

Usa documenti Markdown UTF-8, nomi chiari e percorsi relativi. Adatta o riusa documenti esistenti equivalenti senza duplicare requisiti. Mantieni un solo riferimento autorevole per ogni decisione. La struttura è consigliata, non obbligatoria per l’importatore.

```
nome-progetto-alaska.zip
  README.md
  BRIEF.md
  UX_UI.md
  DATI_INTEGRAZIONI.md
  ASSET.md
  ACCETTAZIONE.md
  ISTRUZIONI_ALASKA.md
  MATERIALI_MANCANTI.md
  assets/
  riferimenti/
```

- README.md: indice, breve descrizione, ordine di lettura, stato della consegna e versione/data del pacchetto; cita questa guida versione 1.0 del 16 ottobre 2026.
- BRIEF.md: piattaforme, utenti, obiettivo, funzioni, priorità, esclusioni e decisioni confermate; separa proposte e questioni aperte.
- UX_UI.md: flussi, navigazione, schermate, testi, stati, regole visive e interazioni; collega i mockup realmente presenti.
- DATI_INTEGRAZIONI.md: dati, persistenza, permessi, ruoli, integrazioni e accessi da configurare separatamente, senza segreti.
- ASSET.md: inventario dei file con ruolo, stato (pronto o riferimento), provenienza e condizioni d’uso note; elenca a parte gli elementi da produrre.
- ACCETTAZIONE.md: criteri verificabili collegati ai requisiti confermati. Per ogni criterio indica situazione iniziale, azione e risultato atteso; includi i principali stati di errore e assenza di dati.
- ISTRUZIONI_ALASKA.md: richiesta di realizzazione coerente con il brief, ordine delle priorità, documenti da leggere, mappa riferimenti/schermate, asset da usare e vincoli da rispettare. Chiedi di segnalare conflitti, materiali mancanti e limiti prima di sostituire una scelta approvata. Non presentare queste istruzioni come codice già realizzato.
- MATERIALI_MANCANTI.md: file, decisioni, accessi e verifiche mancanti; impatto e prossimo passo. Scrivi esplicitamente anche se non risultano materiali mancanti.
- assets/: solo asset reali disponibili; riferimenti/: mockup, schermate e documenti di riferimento disponibili. Crea queste cartelle solo se contengono file; non usare segnaposto spacciati per asset.

### 8. Formati e limiti verificati dell’importazione ZIP

Crea uno ZIP standard a volume singolo, senza password, con compressione normale Deflate o senza compressione. ZIP64, archivi multi-volume e collegamenti simbolici non sono supportati. Evita percorsi assoluti, segmenti “.” o “..”, barre inverse e nomi duplicati anche per sole maiuscole/minuscole. I percorsi non devono superare 240 caratteri; preferisci nomi brevi e distintivi. I percorsi interni possono essere rinominati durante l’importazione: descrivi anche il ruolo dei file, senza dipendere dalla loro collocazione nel runtime.

Il caricamento accetta fino a 100 MiB per allegato (nell’interfaccia indicati come 100 MB) e fino a 10 allegati per messaggio. Ogni ZIP ammette fino a 1.000 file utilizzabili, 25 MiB per file estratto e 250 MiB estratti complessivi; l’indice non deve superare 2.000 voci, incluse cartelle e file ignorati. Mantieni il pacchetto essenziale, senza cache, dipendenze, cartelle .git o archivi annidati.

Lo ZIP conserva i file anche quando il loro formato non è interpretabile direttamente. Preferisci Markdown o testo UTF-8 per le specifiche e PNG/JPEG/WebP per i riferimenti visivi. La lettura dei PDF dipende dal testo estraibile: una scansione non equivale a un documento testuale. La conservazione di un file non garantisce un’interpretazione completa, la conversione o l’esecuzione del contenuto: documenta in testo le decisioni essenziali.

Video, audio, file .fig e font possono essere conservati come asset opachi: non promettere trascrizione, analisi, conversione o uso automatici. Gli archivi annidati non vengono aperti ricorsivamente. I file nascosti, le cartelle con nome che inizia con un punto e __MACOSX vengono saltati: non collocarvi materiali necessari. Non convertire o rinominare un’estensione per fingere capacità di lettura. Se uno ZIP supera i limiti, riduci file superflui o dimensioni delle immagini preservando la leggibilità; se necessario prepara parti chiaramente numerate e un indice, rispettando i limiti anche della richiesta complessiva.

### 9. Controllo e consegna all’utente

Prima della consegna controlla che tutti i file citati come inclusi esistano davvero, siano apribili e abbiano i nomi corretti. Controlla l’indice dello ZIP, i limiti quando puoi misurarli, i rimandi e l’inventario asset. Verifica che brief, UX/UI, istruzioni e criteri di accettazione non contengano requisiti contraddittori. In caso di conflitto conserva la decisione confermata più recente, segnalando la risoluzione; chiedi solo se rimane una scelta sostanziale irrisolta. Segnala ciò che non hai potuto verificare.

Non dichiarare creati documenti, immagini o ZIP che non hai generato realmente. Se puoi creare file, consegna il vero ZIP e un riepilogo: contenuti inclusi, requisiti confermati, punti aperti e materiali mancanti. Se non puoi generare immagini, includi soltanto quelle realmente disponibili ed elenca quelle da produrre. Se non puoi generare file o ZIP, dichiara “Consegna parziale: ZIP non generato”, fornisci i testi dei documenti con i nomi consigliati e istruzioni semplici per salvarli e comprimerli; elenca i file e gli asset ancora mancanti. Non offrire un falso collegamento di download.

Per consegnare ad Alaska: accedi ad appalaska.com, crea un progetto dalla chat, usa il comando per allegare file e seleziona lo ZIP. Attendi la conferma di caricamento, leggi gli eventuali avvisi sui formati ignorati e invia un messaggio che chieda di leggere tutti i materiali e realizzare il progetto secondo ISTRUZIONI_ALASKA.md. Il semplice caricamento non invia il messaggio e non avvia automaticamente la realizzazione. Verifica il riepilogo del progetto e le eventuali richieste di chiarimento di Alaska; le conferme di spesa e distribuzione seguono il normale flusso del servizio.