Wdrażanie aplikacji wspomagane promptem

Co robi ta funkcja

Obecny prompt-to-app endpoint łączy pisemny brief z istniejącym repozytorium szablonu Git i ustawia to repozytorium w kolejce przez normalną immutable app-deployment pipeline. Brief jest zapisywany jako provenance na potrzeby późniejszych iteracji.

Nie generuje nowego application repository z briefu. Template URL jest wymagany, a pierwsze wdrożenie zawiera template source w rozwiązanej rewizji, chyba że ta source już realizuje żądanie.

Utworzenie z promptu i szablonu

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

Odpowiedź zawiera trwałe ID app, deployment i build oraz build stream URL. Tworzenie jest asynchroniczne. Śledź rekord deployment lub build stream do stanu terminalnego; nie wysyłaj duplikatu deployment tylko dlatego, że postęp jest cichy.

Przed wysłaniem żądania:

• przejrzyj repozytorium i licencję;
• przypnij lub zapisz dokładną source revision używaną przez deployment;
• zweryfikuj install, build, run, port i zachowanie health; oraz
• trzymaj secrets poza promptem i repozytorium.

Prompt to kontekst, a nie dowód, że wynikowa source go spełnia. Testuj zachowanie po wdrożeniu względem acceptance criteria wynikających z briefu.

Żądanie późniejszej zmiany

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

To uruchamia asynchroniczne zadanie repair-agent dla app, której jesteś właścicielem i która ma Git source. Odpytuj:

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

Odpowiedź statusu łączy najnowszy deployment state ze stanem iteration-thread oraz ewentualnym result evidence.

Ważna granica iteracji

Obecna ścieżka repair może pracować w sandboxie i poprosić o świeże deployment, ale persistence z powrotem do Git repository dewelopera nie jest jeszcze gwarantowanym etapem. Wątek agenta done sam więc nie dowodzi, że:

• żądana zmiana jest w upstream repository;
• zbudowano konkretny commit;
• testy przeszły;
• nowe deployment stało się aktywne; lub
• można przywrócić poprzednie deployment.

Dla każdej iteracji niezależnie zapisuj upstream commit, deployment ID, build ID, health result i acceptance-test evidence. Jeśli upstream repository nie zostało zaktualizowane, zachowaj patch przez workflow source control sprawdzony przez operatora, zanim polegasz na zmianie.

Bezpieczna sekwencja akceptacji

1. Przekształć brief w obserwowalne acceptance criteria.
2. Przejrzyj wybrany szablon i dokładną rewizję.
3. Ustaw w kolejce jedno deployment i śledź trwałe ID.
4. Potwierdź osobno build, candidate health check i route switch.
5. Sprawdź acceptance criteria względem deployed URL.
6. Potwierdź, że source commit istnieje w repozytorium, które kontrolujesz.
7. Zachowaj evidence i rollback target.

Zobacz Wdrażanie aplikacji w sprawie immutable deployment stages i failure handling.