Nasazení aplikace s pomocí promptu

Co funkce dělá

Aktuální endpoint prompt-to-app spojí písemný brief s existujícím Git šablonovým repozitářem a zařadí tento repozitář do běžné immutable app-deployment pipeline. Brief se uloží jako provenance pro pozdější iterace.

Negeneruje nový repozitář aplikace z briefu. URL šablony je povinné a první nasazení obsahuje zdroj šablony v dané revizi, pokud tento zdroj požadavek už neimplementuje.

Vytvoření z promptu a šablony

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

Odpověď obsahuje trvalá ID aplikace, nasazení a buildu plus URL build streamu. Vytvoření je asynchronní. Sledujte záznam nasazení nebo build stream, dokud nedosáhne terminálního stavu; neposílejte duplicitní nasazení jen proto, že průběh dlouho nic nehlásí.

Před odesláním požadavku:

• zkontrolujte repozitář a jeho licenci;
• připněte nebo zaznamenejte přesnou zdrojovou revizi, kterou nasazení použije;
• ověřte chování instalace, buildu, běhu, portu a health checku; a
• držte secrets mimo prompt i repozitář.

Prompt je kontext, ne důkaz, že výsledný zdroj briefu vyhovuje. Otestujte nasazené chování proti akceptačním kritériím odvozeným z briefu.

Požadavek na pozdější změnu

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

Tím se pro aplikaci, kterou vlastníte a která má Git zdroj, spustí asynchronní úloha repair agenta. Dotazujte:

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

Odpověď statusu spojuje nejnovější stav nasazení se stavem iteration threadu a případnými hlášenými důkazy výsledku.

Důležitá hranice iterace

Aktuální repair cesta může pracovat ve svém sandboxu a požádat o nové nasazení, ale persistenci zpět do Git repozitáře vývojáře zatím nelze považovat za garantovanou fázi. done agent thread tedy sám o sobě neprokazuje, že:

• požadovaná změna je v upstream repozitáři;
• byl sestaven konkrétní commit;
• testy prošly;
• nové nasazení se stalo aktivním; nebo
• lze obnovit staré nasazení.

U každé iterace samostatně zaznamenejte upstream commit, deployment ID, build ID, výsledek health checku a důkazy akceptačních testů. Pokud upstream repozitář nebyl aktualizován, uchovejte patch operátorem schváleným source-control workflow, než na změnu spoléháte.

Bezpečná akceptační sekvence

1. Převeďte brief na pozorovatelná akceptační kritéria.
2. Zkontrolujte vybranou šablonu a přesnou revizi.
3. Zařaďte jedno nasazení a sledujte jeho trvalá ID.
4. Potvrďte build, health check kandidáta a přepnutí trasy zvlášť.
5. Ověřte akceptační kritéria proti nasazené URL.
6. Potvrďte, že zdrojový commit existuje v repozitáři, který ovládáte.
7. Ponechte důkazy a cíl pro rollback.

Viz App deployment pro immutable fáze nasazení a zpracování chyb.