Implementarea aplicației asistată de prompt

Ce face funcția

Endpointul prompt-to-app actual combină un brief scris cu un depozit Git șablon existent și pune acel depozit în coada pipeline-ului obișnuit immutable app-deployment. Brieful se salvează ca provenance pentru iterările ulterioare.

Nu generează un depozit de aplicație nou din brief. URL-ul șablonului este obligatoriu, iar prima implementare conține sursa șablonului la revizia rezolvată, dacă sursa nu implementează deja cererea.

Creare din prompt și șablon

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

Răspunsul include ID-uri durabile pentru aplicație, implementare și build, plus URL-ul build stream. Crearea este asincronă. Urmăriți înregistrarea implementării sau build stream până ajunge într-o stare terminală; nu trimiteți o implementare duplicată doar pentru că progresul rămâne tăcut.

Înainte de a trimite cererea:

• revizuiți depozitul și licența lui;
• fixați sau notați revizia exactă a sursei folosită de implementare;
• verificați comportamentul de instalare, build, rulare, port și health check; și
• țineți secret-ele în afara promptului și a depozitului.

Promptul este context, nu dovadă că sursa rezultată îndeplinește brieful. Testați comportamentul implementat față de criteriile de acceptare derivate din brief.

Cerere de modificare ulterioară

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

Aceasta lansează o sarcină asincronă a repair agentului pentru o aplicație pe care o dețineți și care are sursă Git. Interogați:

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

Răspunsul de status combină starea celei mai recente implementări cu starea iteration thread și orice dovezi de rezultat raportate.

Limită importantă a iterării

Calea repair actuală poate lucra în sandbox-ul ei și poate solicita o implementare nouă, dar persistarea înapoi în depozitul Git al dezvoltatorului nu este încă o etapă garantată. Un agent thread done nu dovedește deci, de una singură, că:

• modificarea cerută este prezentă în depozitul upstream;
• un commit anume a fost construit;
• testele au trecut;
• noua implementare a devenit activă; sau
• implementarea veche poate fi restaurată.

Pentru fiecare iterare, înregistrați separat commitul upstream, deployment ID, build ID, rezultatul health check și dovezile testelor de acceptare. Dacă depozitul upstream nu a fost actualizat, păstrați patch-ul printr-un workflow source-control revizuit de operator înainte să vă bazați pe modificare.

Secvență sigură de acceptare

1. Traduceți brieful în criterii de acceptare observabile.
2. Revizuiți șablonul selectat și revizia exactă.
3. Puneți în coadă o implementare și urmăriți ID-urile durabile.
4. Confirmați separat build-ul, health check-ul candidatului și comutarea rutei.
5. Exercitați criteriile de acceptare pe URL-ul implementat.
6. Confirmați că commitul sursă există în depozitul pe care îl controlați.
7. Păstrați dovezile și ținta de rollback.

Consultați App deployment pentru etapele immutable ale implementării și gestionarea eșecurilor.