Prompt-assisteret app-implementering

Hvad funktionen gør

Det nuværende prompt-to-app endpoint kombinerer en skriftlig brief med et eksisterende Git-skabelonrepository og sætter det repository i kø gennem normal immutable app-deployment pipeline. Briefen gemmes som provenance til senere iterationer.

Det genererer ikke et nyt application repository ud fra briefen. Template URL er påkrævet, og den første deployment indeholder template source ved den løste revision, medmindre kilden allerede implementerer anmodningen.

Opret fra prompt og skabelon

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 indeholder varige app-, deployment- og build-ID’er plus en build stream URL. Oprettelse er asynkron. Følg deployment-posten eller build stream, indtil den når terminal state; indsend ikke dublet deployment alene fordi fremskridtet er stille.

Før du indsender anmodningen:

• gennemgå repository og licens;
• fastgør eller notér den præcise source revision, som deployment bruger;
• verificér install, build, run, port og health-adfærd; og
• hold secrets ude af prompt og repository.

Prompten er kontekst, ikke bevis for at den resulterende source opfylder den. Test adfærd efter deployment mod acceptance criteria afledt af briefen.

Anmod om en senere ændring

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 ejer, som har Git source. Poll:

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

Statussvaret kombinerer seneste deployment state med iteration-thread state og eventuelt rapporteret result evidence.

Vigtig iterationsgrænse

Den nuværende repair-sti kan arbejde i sin sandbox og anmode om frisk deployment, men persistence tilbage til udviklerens Git repository er endnu ikke et garanteret trin. En done agent thread beviser derfor ikke i sig selv, at:

• den ønskede ændring findes i upstream repository;
• en specifik commit blev bygget;
• tests bestod;
• den nye deployment blev aktiv; eller
• den gamle deployment kan gendannes.

For hver iteration skal du uafhængigt registrere upstream commit, deployment ID, build ID, health result og acceptance-test evidence. Hvis upstream repository ikke blev opdateret, bevar patchen via en operator-gennemgået source-control workflow, før du stoler på ændringen.

Sikker acceptsekvens

1. Oversæt briefen til observerbare acceptance criteria.
2. Gennemgå valgt skabelon og præcis revision.
3. Sæt én deployment i kø og følg dens varige ID’er.
4. Bekræft build, candidate health check og route switch hver for sig.
5. Afprøv acceptance criteria mod deployed URL.
6. Bekræft at source commit findes i det repository, du kontrollerer.
7. Behold evidence og rollback target.

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