Namestitev aplikacije s pomočjo prompta

Kaj funkcija počne

Trenutni endpoint prompt-to-app združi pisni brief z obstoječim Git predlognim repozitorijem in ta repozitorij uvrsti v običajno immutable app-deployment pipeline. Brief se shrani kot provenance za poznejše iteracije.

Ne ustvari novega repozitorija aplikacije iz briefa. URL predloge je obvezen in prva namestitev vsebuje vir predloge na določeni reviziji, razen če ta vir zahtevo že izpolnjuje.

Ustvarjanje iz prompta in predloge

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"
}

Odgovor vključuje trajne ID-je aplikacije, namestitve in builda ter URL build streama. Ustvarjanje je asinhrono. Spremljajte zapis namestitve ali build stream, dokler ne doseže končnega stanja; ne pošiljajte podvojene namestitve zgolj zato, ker napredek dolgo nič ne poroča.

Pred pošiljanjem zahteve:

• preglejte repozitorij in njegovo licenco;
• pripnite ali zabeležite natančno revizijo vira, ki jo bo namestitev uporabila;
• preverite obnašanje namestitve, builda, zagona, porta in health checka; in
• držite secrets izven prompta in repozitorija.

Prompt je kontekst, ne dokaz, da izvirni koda ustreza briefu. Preizkusite nameščeno obnašanje glede na sprejemna merila, izpeljana iz briefa.

Zahteva za poznejšo spremembo

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

To sproži asinhrono nalogo repair agenta za aplikacijo, ki vam pripada in ima Git vir. Poizvedujte:

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

Odgovor statusa združi najnovejše stanje namestitve s stanjem iteration threada in morebitnimi poročanimi dokazi rezultata.

Pomembna meja iteracije

Trenutna repair pot lahko dela v svojem sandboxu in zahteva novo namestitev, vendar persistenca nazaj v Git repozitorij razvijalca še ni zagotovljena faza. done agent thread zato sam po sebi ne dokazuje, da:

• je zahtevana sprememba v upstream repozitoriju;
• je bil zgrajen določen commit;
• so testi uspeli;
• je nova namestitev postala aktivna; ali
• je mogoče obnoviti staro namestitev.

Pri vsaki iteraciji ločeno zabeležite upstream commit, deployment ID, build ID, rezultat health checka in dokaze sprejemnih testov. Če upstream repozitorij ni bil posodobljen, ohranite patch prek operatersko pregledanega source-control workflow, preden se zanašate na spremembo.

Varno zaporedje sprejema

1. Pretvorite brief v opazljiva sprejemna merila.
2. Preglejte izbrano predlogo in natančno revizijo.
3. Uvrstite eno namestitev in spremljajte njene trajne ID-je.
4. Ločeno potrdite build, health check kandidata in preklop poti.
5. Preizkusite sprejemna merila na nameščenem URL-ju.
6. Potrdite, da izvorni commit obstaja v repozitoriju, ki ga nadzorujete.
7. Hranite dokaze in cilj za rollback.

Glejte App deployment za immutable faze namestitve in obravnavo napak.