Deployment de app assistido por prompt

O que o feature faz

Endpoint prompt-to-app atual combina brief escrito com repositório Git template existente e enfileira repositório pelo pipeline normal de deployment imutável de app. Brief é salvo como proveniência para iterações posteriores.

Não gera repositório de aplicativo novo a partir do brief. URL do template é obrigatória e primeiro deployment contém origem do template na revisão resolvida salvo se origem já implementa pedido.

Criar a partir de prompt e 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"
}

Resposta inclui IDs duráveis de app, deployment e build mais URL de stream de build. Criação é assíncrona. Siga registro de deployment ou stream de build até estado terminal; não envie deployment duplicado só porque progresso está quieto.

Antes de enviar pedido:

• revise repositório e licença;
• fixe ou registre revisão de origem exata usada pelo deployment;
• verifique install, build, run, port e comportamento de health; e
• mantenha segredos fora do prompt e repositório.

Prompt é contexto, não prova de que origem resultante o satisfaz. Teste comportamento deployado contra critérios de aceitação derivados do brief.

Pedir mudança posterior

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

Isso despacha tarefa assíncrona de repair-agent para app que você possui e que tem origem Git. Faça poll:

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

Resposta de status combina estado de deployment mais recente com estado de thread de iteração e evidência de resultado reportada.

Limite importante de iteração

Caminho de repair atual pode trabalhar em sandbox e pedir deployment fresh, mas persistência de volta ao repositório Git do desenvolvedor ainda não é estágio garantido. Thread de agent done portanto não prova por si que:

• mudança solicitada está presente no repositório upstream;
• commit específico foi construído;
• testes passaram;
• novo deployment ficou ativo; ou
• deployment antigo pode ser restaurado.

Para cada iteração, registre independentemente commit upstream, ID de deployment, ID de build, resultado de health e evidência de teste de aceitação. Se repositório upstream não foi atualizado, preserve patch por workflow de controle de origem revisado por operador antes de confiar na mudança.

Sequência de aceitação segura

1. Traduza brief em critérios de aceitação observáveis.
2. Revise template selecionado e revisão exata.
3. Enfileire um deployment e siga IDs duráveis.
4. Confirme build, health check do candidato e troca de rota separadamente.
5. Exercite critérios de aceitação contra URL deployada.
6. Confirme que commit de origem existe no repositório que você controla.
7. Retenha evidência e alvo de rollback.

Veja App deployment para estágios de deployment imutável e tratamento de falha.