Promptassisterad appdistribution

Vad funktionen gör

Den nuvarande prompt-to-app endpoint kombinerar en skriftlig brief med ett befintligt Git-mallrepo och köar det repot genom normal immutable app-deployment pipeline. Briefen sparas som provenance för senare iterationer.

Den genererar inte ett nytt application repository från briefen. Template URL krävs, och den första deployment innehåller template source vid den lösta revisionen om inte källan redan implementerar begäran.

Skapa från prompt och mall

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

Svaret innehåller beständiga app-, deployment- och build-ID plus en build stream URL. Skapandet är asynkront. Följ deployment-posten eller build stream tills den når terminal state; skicka inte in dubbel deployment bara för att framstegen är tyst.

Innan du skickar begäran:

• granska repot och dess licens;
• fäst eller anteckna exakt source revision som deployment använder;
• verifiera install, build, run, port och health-beteende; och
• håll secrets utanför prompten och repot.

Prompten är kontext, inte bevis att resulterande source uppfyller den. Testa beteendet efter deployment mot acceptance criteria härledda från briefen.

Begär en senare ändring

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

Detta startar en asynkron repair-agent task för en app du äger som har Git source. Polla:

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

Statussvaret kombinerar senaste deployment state med iteration-thread state och eventuellt rapporterat result evidence.

Viktig iterationsgräns

Den nuvarande repair-vägen kan arbeta i sin sandbox och begära ny deployment, men persistence tillbaka till utvecklarens Git repository är ännu inte ett garanterat steg. En done agent thread bevisar därför inte i sig att:

• den begärda ändringen finns i upstream repository;
• en specifik commit byggdes;
• tester passerade;
• den nya deployment blev aktiv; eller
• den gamla deployment kan återställas.

För varje iteration, registrera oberoende upstream commit, deployment ID, build ID, health result och acceptance-test evidence. Om upstream repository inte uppdaterades, bevara patchen via ett operator-granskat source-control-arbetsflöde innan du litar på ändringen.

Säker acceptanssekvens

1. Översätt briefen till observerbara acceptance criteria.
2. Granska vald mall och exakt revision.
3. Köa en deployment och följ dess beständiga ID.
4. Bekräfta build, candidate health check och route switch var för sig.
5. Pröva acceptance criteria mot deployed URL.
6. Bekräfta att source commit finns i repot du kontrollerar.
7. Behåll evidence och rollback target.

Se Appdistribution för immutable deployment stages och failure handling.