Deploy app assistito da prompt

Cosa fa la feature

L’endpoint prompt-to-app attuale combina un brief scritto con un repository template Git esistente e accoda quel repository tramite la normale pipeline deploy app immutabile. Il brief è salvato come provenienza per iterazioni successive.

Non genera un nuovo repository applicazione dal brief. L’URL template è richiesto e il primo deploy contiene sorgente template alla revisione risolta salvo che quella sorgente implementi già la richiesta.

Crea da prompt e template

POST /api/apps/from-prompt
Content-Type: application/json
 
{
  "brief": "A private reading-list app with a health endpoint",
  "template_git_url": "https://github.com/example/reviewed-template.git",
  "branch": "main",
  "visibility": "private"
}

La risposta include ID durabili app, deployment e build più URL stream build. La creazione è asincrona. Segui record deploy o stream build fino a stato terminale; non inviare deploy duplicato solo perché il progresso è silenzioso.

Prima di inviare la richiesta:

• rivedi repository e licenza;
• pin o registra revisione sorgente esatta usata dal deploy;
• verifica install, build, run, porta e comportamento health; e
• tieni segreti fuori da prompt e repository.

Il prompt è contesto, non prova che la sorgente risultante soddisfi il brief. Testa comportamento deployato contro criteri accettazione derivati dal brief.

Richiedi modifica successiva

POST /api/apps/{app_id}/iterate
Content-Type: application/json
 
{
  "instruction": "Add an authenticated export endpoint and a regression test"
}

Questo dispatcha task repair-agent asincrono per un’app che possiedi e che ha sorgente Git. Fai polling:

GET /api/apps/{app_id}/agent-status?thread_id={thread_id}

La risposta stato combina stato deploy più recente con stato thread iterazione ed eventuale evidenza risultato riportata.

Confine iterazione importante

Il percorso repair attuale può lavorare nella sua sandbox e richiedere redeploy fresco, ma persistenza nel repository Git dello sviluppatore non è ancora stage garantito. Un thread agent done quindi non prova da solo che:

• la modifica richiesta sia presente nel repository upstream;
• un commit specifico sia stato buildato;
• i test siano passati;
• il nuovo deploy sia diventato attivo; o
• il deploy precedente possa essere ripristinato.

Per ogni iterazione, registra indipendentemente commit upstream, ID deploy, ID build, risultato health ed evidenza test accettazione. Se il repository upstream non è aggiornato, preserva patch tramite workflow source-control revisionato operatore prima di affidarti al cambio.

Sequenza accettazione sicura

1. Traduci il brief in criteri accettazione osservabili.
2. Rivedi template selezionato e revisione esatta.
3. Accoda un deploy e segui i suoi ID durabili.
4. Conferma build, health check candidato e switch route separatamente.
5. Esercita criteri accettazione contro URL deployato.
6. Conferma che commit sorgente esista nel repository che controlli.
7. Conserva evidenza e target rollback.

Vedi App deployment per stage deploy immutabile e gestione fallimenti.