Skip to Content
TestingPrompt-assistert app-implementering

Prompt-assistert app-implementering

Hva funksjonen gjør

Det nåværende prompt-to-app endpoint kombinerer en skriftlig brief med et eksisterende Git-malrepository og setter det repositoryet i kø gjennom normal immutable app-deployment pipeline. Briefen lagres som provenance for senere iterasjoner.

Det genererer ikke et nytt application repository fra briefen. Template URL er påkrevd, og første deployment inneholder template source ved den løste revisjonen med mindre kilden allerede implementerer forespørselen.

Opprett fra prompt og mal

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

Svaret inneholder varige app-, deployment- og build-ID-er pluss en build stream URL. Opprettelse er asynkron. Følg deployment-posten eller build stream til terminal state; ikke send inn duplikat deployment bare fordi fremdriften er stille.

Før du sender forespørselen:

  • gå gjennom repository og lisens;
  • fest eller noter nøyaktig source revision som deployment bruker;
  • verifiser install, build, run, port og health-atferd; og
  • hold secrets ute av prompt og repository.

Prompten er kontekst, ikke bevis for at resulterende source oppfyller den. Test atferd etter deployment mot acceptance criteria utledet fra briefen.

Be om en senere endring

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

Dette starter en asynkron repair-agent task for en app du eier som har Git source. Poll:

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

Statussvaret kombinerer siste deployment state med iteration-thread state og eventuelt rapportert result evidence.

Viktig iterasjonsgrense

Den nåværende repair-stien kan jobbe i sandboxen sin og be om ny deployment, men persistence tilbake til utviklerens Git repository er ennå ikke et garantert trinn. En done agent thread beviser derfor ikke i seg selv at:

  • den forespurte endringen finnes i upstream repository;
  • en bestemt commit ble bygget;
  • tester bestod;
  • ny deployment ble aktiv; eller
  • gammel deployment kan gjenopprettes.

For hver iterasjon, registrer uavhengig upstream commit, deployment ID, build ID, health result og acceptance-test evidence. Hvis upstream repository ikke ble oppdatert, bevar patchen via en operator-gjennomgått source-control workflow før du stoler på endringen.

Sikker akseptsekvens

  1. Oversett briefen til observerbare acceptance criteria.
  2. Gå gjennom valgt mal og nøyaktig revisjon.
  3. Sett én deployment i kø og følg de varige ID-ene.
  4. Bekreft build, candidate health check og route switch hver for seg.
  5. Prøv acceptance criteria mot deployed URL.
  6. Bekreft at source commit finnes i repositoryet du kontrollerer.
  7. Behold evidence og rollback target.

Se App-implementering for immutable deployment stages og failure handling.

App-observabilityObjektlagring for apper