Implementacija aplikacije pomoću prompta

Što funkcija radi

Trenutačni endpoint prompt-to-app spaja pisani brief s postojećim Git predloškom repozitorija i taj repozitorij stavlja u red normalnog immutable app-deployment pipelinea. Brief se sprema kao provenance za kasnije iteracije.

Ne generira novi repozitorij aplikacije iz briefa. URL predloška je obavezan, a prva implementacija sadrži izvor predloška na određenoj reviziji, osim ako taj izvor već ispunjava zahtjev.

Stvaranje iz prompta i predloška

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 uključuje trajne ID-je aplikacije, implementacije i builda te URL build streama. Stvaranje je asinkrono. Pratite zapis implementacije ili build stream dok ne dosegne konačno stanje; ne šaljite dupliciranu implementaciju samo zato što napredak dugo ništa ne javlja.

Prije slanja zahtjeva:

• pregledajte repozitorij i njegovu licencu;
• pričvrstite ili zabilježite točnu reviziju izvora koju će implementacija koristiti;
• provjerite ponašanje instalacije, builda, pokretanja, porta i health checka; i
• držite secrets izvan prompta i repozitorija.

Prompt je kontekst, a ne dokaz da rezultirajući izvor zadovoljava brief. Testirajte implementirano ponašanje prema kriterijima prihvaćanja izvedenim iz briefa.

Zahtjev za kasniju promjenu

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

Time se pokreće asinkroni zadatak repair agenta za aplikaciju koju posjedujete i koja ima Git izvor. Upitajte:

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

Odgovor statusa spaja najnovije stanje implementacije sa stanjem iteration threada i eventualnim prijavljenim dokazima rezultata.

Važna granica iteracije

Trenutačni repair put može raditi u svom sandboxu i zatražiti svježu implementaciju, ali persistencija natrag u Git repozitorij developera još nije zajamčena faza. done agent thread stoga sam po sebi ne dokazuje da:

• tražena promjena postoji u upstream repozitoriju;
• je određeni commit buildan;
• su testovi prošli;
• je nova implementacija postala aktivna; ili
• se stara implementacija može vratiti.

Za svaku iteraciju zasebno zabilježite upstream commit, deployment ID, build ID, rezultat health checka i dokaze acceptance testova. Ako upstream repozitorij nije ažuriran, sačuvajte patch kroz operaterski pregledani source-control workflow prije nego se oslonite na promjenu.

Sigurno slijed prihvaćanja

1. Prevedite brief u opažljive kriterije prihvaćanja.
2. Pregledajte odabrani predložak i točnu reviziju.
3. Stavite jednu implementaciju u red i pratite njene trajne ID-je.
4. Odvojeno potvrdite build, health check kandidata i prebacivanje rute.
5. Provjerite kriterije prihvaćanja na implementiranom URL-u.
6. Potvrdite da izvorni commit postoji u repozitoriju koji kontrolirate.
7. Zadržite dokaze i cilj za rollback.

Pogledajte App deployment za immutable faze implementacije i rukovanje greškama.