LaunchRepoUna run ha un obiettivo, esiti registrati e una prossima azione chiara. Parti da 10 nuovi invii confermati, con al massimo 2 piattaforme in parallelo se la tua macchina e la configurazione del browser lo consentono. Il lavoro lo svolge il tuo agente; la dashboard salva il piano e i progressi. Inizia dopo l’onboarding e il test di connessione con Chrome.
1. Controlla prodotto e permessi
Leggi il brief di prodotto, l’identità, i permessi e i record degli invii già esistenti. Usa funzionalità verificate, prezzi attuali, screenshot autentici e i testi pubblici che hai approvato. Una prova resta una prova. I dati obbligatori sconosciuti restano sconosciuti finché non vengono verificati. Prima di creare qualsiasi cosa, conferma l’account di destinazione e cerca eventuali schede esistenti.
2. Pianifica la run
Nel pianificatore locale delle run scegli il numero di nuovi invii e il limite di parallelismo. La raccomandazione è 10 invii con un tetto di 2 worker. L’hardware incide sulla concorrenza, non su quante piattaforme sono adatte al tuo prodotto. Una macchina con risorse limitate, sotto carico in quel momento o con capacità sconosciuta dovrebbe partire con un solo worker. Anche una macchina potente parte con un tetto di due.
Due worker richiedono workspace del browser controllati separatamente e piattaforme assegnate distinte. Se condividono il focus del browser o non riescono a tenere isolato il proprio lavoro, usane uno solo. Non lasciare mai che entrambi scelgano la stessa piattaforma. Leggi per intero il playbook di ogni candidata e verifica idoneità attuale e accesso gratuito prima di aprirne il modulo. Sostituisci i percorsi non adatti o a pagamento con alternative adatte; non abbassare i tuoi standard pur di arrivare a dieci.
3. Parti con un obiettivo esplicito
Copia il prompt della run salvato. Se il tuo agente supporta /goal, usa la sua funzione di obiettivo con quel testo. Altrimenti incollalo come un normale messaggio. /goal è una funzione dell’host, non un comando universale di LaunchRepo. Restano validi i limiti di utilizzo del provider, i permessi mancanti e le verifiche che richiedono una persona.
Un obiettivo tipico è:
Complete 10 new, relevant, free directory submissions for this product. Use at most 2 workers, only with sufficient resources and isolated browser control; otherwise work sequentially. Read the saved run and existing submissions first. Save each confirmed outcome and its evidence, then continue. Replace blocked candidates with suitable alternatives. Stop when the target is reached or explain the exact reason no further progress is possible. Preserve the remaining work for resume.
4. Invia, salva, chiudi, continua
Per ogni piattaforma assegnata:
- Ricontrolla idoneità, accesso gratuito, campi obbligatori, consensi e l’identità con cui hai effettuato l’accesso.
- Prepara i testi approvati e asset autentici. Rileggi i campi compilati e verifica che le bozze siano state salvate.
- Controlla il totale finale. Salta i pagamenti obbligatori. Se è richiesto un badge ufficiale, segui il permesso registrato per il sito web e verifica il deploy pubblico prima di attestarlo.
- Invia entro i permessi del titolare e controlla la conferma effettiva. Dopo un timeout, controlla account e scheda prima di qualsiasi nuovo tentativo.
- Registra subito lo stato osservato, le prove non sensibili e la prossima azione.
- Dopo aver salvato le prove, chiudi solo la finestra assegnata a questo invio e i tab di verifica che le appartengono. Lascia intatte le finestre personali, gli altri worker, la dashboard, i moduli non salvati e i passaggi di consegne ancora aperti. Conserva il profilo del browser per gli accessi futuri.
- Continua finché l’obiettivo salvato non è raggiunto o finché non resta più lavoro idoneo che possa procedere.
5. Conta con precisione gli invii confermati
| Esito | Conta per la run? |
|---|---|
Nuovo submitted_pending_review, queued, scheduled o live |
Sì, una volta per piattaforma, con conferma |
| Passaggio successivo da in attesa a live | Nessun conteggio aggiuntivo |
already_listed o un invio precedente |
No |
| Bozza, CAPTCHA, 2FA o dato obbligatorio mancante | No |
| Percorso a pagamento, piattaforma non adatta o non disponibile | No |
Un invio in attesa di revisione è un invio riuscito, non una promessa di pubblicazione. Un lancio programmato deve rispettare la data minima di lancio del prodotto. La distribuzione tramite partner conta a parte solo dopo che il partner ha confermato il proprio invio. Vedi la guida alla registrazione degli esiti per le prove richieste dal tracker.
6. Riprendi il lavoro rimanente
Quando una sessione si interrompe, conserva la run e il suo obiettivo residuo, aggiorna SESSION.md con la prossima azione e tieni in vista i passaggi di consegne a una persona. Avvia la sessione successiva con il prompt di ripresa salvato. Riutilizza i permessi permanenti, ricontrolla i tentativi rimasti in sospeso e rispetta le finestre di revisione delle piattaforme senza inventare uno SLA. Non inviare mai di nuovo solo per scalare una coda.
Se la dashboard mostra 6 of 10 submitted, restano quattro nuovi invii. Può anche mostrare due piattaforme in corso e una che aspetta te: queste non si sommano alle sei. Se esistono solo sei percorsi gratuiti adatti, chiudi con quel risultato onesto e con il motivo per cui l’obiettivo non è stato raggiunto. Dieci è un obiettivo, non un inventario garantito di piattaforme adatte.