Programos diegimas pagal promptą

Ką daro funkcija

Dabartinis prompt-to-app endpoint sujungia rašytinį brief su esama Git template saugykla ir į eilę deda tą saugyklą per įprastą nekintamo programos diegimo pipeline. Brief išsaugomas kaip provenance vėlesnėms iteracijoms.

Jis negeneruoja naujos programos saugyklos iš brief. Template URL būtinas, o pirmas diegimas turi template source nustatytu revision, nebent tas source jau įgyvendina užklausą.

Kurti iš prompto ir 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"
}

Atsakyme yra ilgalaikiai app, deployment ir build ID bei build srauto URL. Kūrimas asinchroninis. Sekite diegimo įrašą arba build srautą, kol pasiekia galutinę būseną; nepateikite dubliuoto diegimo vien todėl, kad progresas tylus.

Prieš pateikiant užklausą:

• peržiūrėkite saugyklą ir jos licenciją;
• užfiksuokite arba įrašykite tikslų source revision, kurį naudoja diegimas;
• patikrinkite install, build, run, port ir health elgseną; ir
• laikykite secrets už prompto ir saugyklos ribų.

Promptas yra kontekstas, ne įrodymas, kad gautas source atitinka jį. Tikrinkite įdiegtą elgseną pagal iš brief išvestus priėmimo kriterijus.

Prašyti vėlesnio pakeitimo

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

Tai paleidžia asinchroninę repair-agent užduotį programai, kurios savininkas esate ir kuri turi Git source. Tikrinkite periodiškai:

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

Būsenos atsakyme sujungta naujausia diegimo būsena su iteracijos thread būsena ir bet kokiais praneštais rezultatų įrodymais.

Svarbi iteracijos riba

Dabartinis repair kelias gali dirbti savo sandbox ir prašyti naujo diegimo, bet persistence atgal į kūrėjo Git saugyklą dar nėra garantuotas etapas. Todėl done agent thread pats savaime neįrodo, kad:

• pageidaujamas pakeitimas yra upstream saugykloje;
• konkretus commit buvo build;
• testai praeiti;
• naujas diegimas tapo aktyvus; arba
• seną diegimą galima atkurti.

Kiekvienai iteracijai nepriklausomai užfiksuokite upstream commit, deployment ID, build ID, health rezultatą ir acceptance testų įrodymus. Jei upstream saugykla nebuvo atnaujinta, išsaugokite patch per operatoriaus peržiūrėtą source control workflow prieš pasikliaudami pakeitimu.

Saugi priėmimo seka

1. Paverstikite brief į stebėtinus priėmimo kriterijus.
2. Peržiūrėkite pasirinktą template ir tikslų revision.
3. Į eilę įdedkite vieną diegimą ir sekite jo ilgalaikius ID.
4. Patvirtinkite build, kandidato health check ir route switch atskirai.
5. Patikrinkite priėmimo kriterijus prieš įdiegtą URL.
6. Patvirtinkite, kad source commit egzistuoja jūsų valdomoje saugykloje.
7. Saugokite įrodymus ir rollback tikslą.

Žr. Programos diegimas dėl nekintamo diegimo etapų ir gedimų valdymo.