Despliegue de app asistido por prompt

Qué hace la feature

El endpoint prompt-to-app actual combina un brief escrito con un repositorio plantilla Git existente y encola ese repositorio mediante el pipeline normal de despliegue inmutable de app. El brief se guarda como procedencia para iteraciones posteriores.

No genera un repositorio de aplicación nuevo desde el brief. La URL de plantilla es obligatoria, y el primer despliegue contiene la fuente de plantilla en la revisión resuelta salvo que esa fuente ya implemente la solicitud.

Crear desde prompt y plantilla

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

La respuesta incluye ID duraderos de app, despliegue y compilación más una URL de stream de compilación. La creación es asíncrona. Sigue el registro de despliegue o stream de compilación hasta un estado terminal; no envíes un despliegue duplicado solo porque el progreso esté en silencio.

Antes de enviar la solicitud:

• revisa el repositorio y su licencia;
• fija o registra la revisión fuente exacta usada por el despliegue;
• verifica install, build, run, puerto y comportamiento de salud; y
• mantén secretos fuera del prompt y del repositorio.

El prompt es contexto, no prueba de que la fuente resultante lo satisface. Prueba el comportamiento desplegado contra criterios de aceptación derivados del brief.

Solicitar un cambio posterior

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

Esto despacha una tarea asíncrona de agente de reparación para una app que posees y que tiene fuente Git. Haz polling:

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

La respuesta de estado combina el último estado de despliegue con el estado del hilo de iteración y cualquier evidencia de resultado reportada.

Límite importante de iteración

La ruta de reparación actual puede trabajar en su sandbox y solicitar un despliegue fresco, pero la persistencia de vuelta al repositorio Git del desarrollador aún no es una etapa garantizada. Un hilo de agente done por tanto no prueba por sí solo que:

• el cambio solicitado está presente en el repositorio upstream;
• se compiló un commit concreto;
• las pruebas pasaron;
• el nuevo despliegue se activó; o
• el despliegue antiguo puede restaurarse.

Para cada iteración, registra de forma independiente el commit upstream, ID de despliegue, ID de compilación, resultado de salud y evidencia de prueba de aceptación. Si el repositorio upstream no se actualizó, conserva el parche mediante un flujo de control de fuente revisado por el operador antes de confiar en el cambio.

Secuencia de aceptación segura

1. Traduce el brief en criterios de aceptación observables.
2. Revisa la plantilla seleccionada y la revisión exacta.
3. Encola un despliegue y sigue sus ID duraderos.
4. Confirma compilación, health check del candidato y conmutación de ruta por separado.
5. Ejercita los criterios de aceptación contra la URL desplegada.
6. Confirma que el commit fuente existe en el repositorio que controlas.
7. Conserva evidencia y un objetivo de rollback.

Consulta Despliegue de app para etapas de despliegue inmutable y manejo de fallos.