Déploiement app assisté par invite

Ce que fait la fonctionnalité

Le point prompt-to-app actuel combine un brief écrit avec un dépôt modèle Git existant et met ce dépôt en file via le pipeline de déploiement app immuable normal. Le brief est enregistré comme provenance pour itérations ultérieures.

Il ne génère pas un nouveau dépôt application depuis le brief. L’URL modèle est requise, et le premier déploiement contient la source modèle à la révision résolue sauf si cette source implémente déjà la demande.

Créer depuis une invite et un modèle

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 réponse inclut ID app, déploiement et build durables plus URL flux build. La création est asynchrone. Suivez l’enregistrement déploiement ou flux build jusqu’à état terminal ; ne soumettez pas déploiement en double uniquement parce que la progression est silencieuse.

Avant de soumettre la requête :

• relisez dépôt et licence ;
• épinglez ou enregistrez révision source exacte utilisée par le déploiement ;
• vérifiez install, build, run, port et comportement health ; et
• gardez secrets hors invite et dépôt.

L’invite est contexte, pas preuve que la source résultante la satisfait. Testez comportement déployé contre critères d’acceptation dérivés du brief.

Demander un changement ultérieur

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

Ceci dispatch une tâche agent repair asynchrone pour une app que vous possédez et qui a une source Git. Interrogez :

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

La réponse statut combine état déploiement le plus récent avec état thread itération et preuves résultat rapportées.

Frontière d’itération importante

Le chemin repair actuel peut travailler dans son sandbox et demander un déploiement neuf, mais persistance vers le dépôt Git développeur n’est pas encore une étape garantie. Un thread agent done ne prouve donc pas à lui seul que :

• le changement demandé est présent dans le dépôt amont ;
• un commit précis a été construit ;
• tests ont réussi ;
• le nouveau déploiement est devenu actif ; ou
• l’ancien déploiement peut être restauré.

Pour chaque itération, enregistrez indépendamment commit amont, ID déploiement, ID build, résultat health et preuves test d’acceptation. Si le dépôt amont n’a pas été mis à jour, conservez le patch via un workflow source contrôlé revu opérateur avant de compter sur le changement.

Séquence d’acceptation sûre

1. Traduisez le brief en critères d’acceptation observables.
2. Relisez modèle sélectionné et révision exacte.
3. Mettez en file un déploiement et suivez ses ID durables.
4. Confirmez build, health check candidat et bascule route séparément.
5. Exercez critères d’acceptation contre URL déployée.
6. Confirmez que commit source existe dans dépôt que vous contrôlez.
7. Conservez preuves et cible rollback.

Voir Déploiement app pour étapes déploiement immuable et gestion échec.