Skip to Content
TestingPrompt-ondersteunde app-implementatie

Prompt-ondersteunde app-implementatie

Wat de functie doet

Het huidige prompt-to-app endpoint combineert een schriftelijke brief met een bestaande Git-templatesrepository en zet die repository in de wachtrij via de normale immutable app-deployment pipeline. De brief wordt opgeslagen als provenance voor latere iteraties.

Het genereert geen nieuwe application repository uit de brief. De template URL is verplicht, en de eerste deployment bevat de template source op de opgeloste revisie, tenzij die source het verzoek al implementeert.

Aanmaken vanuit prompt en 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"
}

Het antwoord bevat duurzame app-, deployment- en build-ID’s plus een build stream URL. Aanmaken is asynchroon. Volg het deploymentrecord of de build stream tot een terminal state; dien geen dubbele deployment in alleen omdat de voortgang stil lijkt.

Voor u het verzoek indient:

  • controleer de repository en de licentie;
  • pin of noteer de exacte source revision die de deployment gebruikt;
  • verifieer install, build, run, port en health-gedrag; en
  • houd secrets uit de prompt en de repository.

De prompt is context, geen bewijs dat de resulterende source daaraan voldoet. Test het gedrag na deployment tegen acceptance criteria die uit de brief volgen.

Een latere wijziging aanvragen

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

Dit start een asynchrone repair-agent task voor een app die van u is en een Git source heeft. Poll:

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

Het statusantwoord combineert de laatste deployment state met iteration-thread state en eventueel gerapporteerd result evidence.

Belangrijke iteratiegrens

Het huidige repair-pad kan in zijn sandbox werken en een nieuwe deployment aanvragen, maar persistence terug naar de Git-repository van de ontwikkelaar is nog geen gegarandeerd stadium. Een done agent thread bewijst daarom op zichzelf niet dat:

  • de gevraagde wijziging in de upstream repository staat;
  • een specifieke commit is gebouwd;
  • tests zijn geslaagd;
  • de nieuwe deployment actief is geworden; of
  • de oude deployment kan worden hersteld.

Noteer per iteratie onafhankelijk de upstream commit, deployment ID, build ID, health result en acceptance-test evidence. Als de upstream repository niet is bijgewerkt, bewaar de patch via een door een operator beoordeelde source-control workflow voordat u op de wijziging vertrouwt.

Veilige acceptatiereeks

  1. Zet de brief om in observeerbare acceptance criteria.
  2. Controleer de gekozen template en exacte revisie.
  3. Zet één deployment in de wachtrij en volg de duurzame ID’s.
  4. Bevestig build, candidate health check en route switch afzonderlijk.
  5. Toets de acceptance criteria tegen de deployed URL.
  6. Bevestig dat de source commit bestaat in de repository die u beheert.
  7. Bewaar evidence en een rollback target.

Zie App-implementatie voor de immutable deployment stages en failure handling.

App-observabilityObjectopslag voor apps