Prompt-assisted App Deployment

Was das Feature tut

Der aktuelle prompt-to-app endpoint kombiniert written brief mit existing Git template repository und queued dieses Repository durch normal immutable app-deployment pipeline. Brief wird als Provenienz für later iterations gespeichert.

Es generiert kein neues application repository aus dem brief. Template URL ist required, und first deployment enthält template source at resolved revision unless source already request implementiert.

Aus Prompt und Template erstellen

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

Response enthält durable app, deployment und build IDs plus build stream URL. Creation ist asynchronous. Deployment record oder build stream folgen bis terminal state; kein duplicate deployment submiten nur weil progress quiet ist.

Vor Request:

• repository und license reviewen;
• exact source revision used by deployment pinnen oder recorden;
• install, build, run, port und health behavior verifizieren; und
• secrets aus prompt und repository halten.

Prompt ist context, kein Nachweis dass resulting source brief satisfies. Deployed behavior gegen acceptance criteria derived from brief testen.

Spätere Änderung anfordern

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

Dispatched asynchronous repair-agent task für app you own mit Git source. Pollen:

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

Status response kombiniert latest deployment state mit iteration-thread state und reported result evidence.

Wichtige Iteration boundary

Current repair path kann in sandbox arbeiten und fresh deployment requesten, aber persistence back to developer Git repository ist noch nicht guaranteed stage. done agent thread beweist daher nicht selbst dass:

• requested change in upstream repository present ist;
• specific commit built wurde;
• tests passed;
• new deployment active wurde; oder
• old deployment restored werden kann.

Für jede iteration independently upstream commit, deployment ID, build ID, health result und acceptance-test evidence recorden. War upstream repository nicht updated, patch durch operator-reviewed source-control workflow bewahren before relying on change.

Sichere Abnahme-Sequenz

1. Brief in observable acceptance criteria übersetzen.
2. Selected template und exact revision reviewen.
3. One deployment queuen und durable IDs folgen.
4. Build, candidate health check und route switch separately bestätigen.
5. Acceptance criteria gegen deployed URL exercisen.
6. Source commit exists in repository you control bestätigen.
7. Evidence und rollback target behalten.

Siehe App deployment für immutable deployment stages und failure handling.