Розгортання застосунків з prompt

What the feature does

Current prompt-to-app endpoint combines written brief with existing Git template repository and queues that repository through normal immutable app-deployment pipeline. Brief saved as provenance for later iterations.

It does not generate new application repository from brief. Template URL required, first deployment contains template source at resolved revision unless source already implements request.

Create from a prompt and 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"
}

Response includes durable app, deployment, build IDs plus build stream URL. Creation asynchronous. Follow deployment record or build stream until terminal state; do not submit duplicate deployment merely because progress quiet.

Before submitting request:

• review repository and license;
• pin or record exact source revision used by deployment;
• verify install, build, run, port, health behavior; and
• keep secrets out of prompt and repository.

Prompt is context, not proof resulting source satisfies it. Test deployed behavior against acceptance criteria derived from brief.

Request a later change

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

Dispatches asynchronous repair-agent task for app you own and that has Git source. Poll:

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

Status response combines latest deployment state with iteration-thread state and any reported result evidence.

Important iteration boundary

Current repair path can work in sandbox and request fresh deployment, but persistence back to developer Git repository not yet guaranteed stage. done agent thread therefore does not by itself prove:

• requested change present in upstream repository;
• specific commit built;
• tests passed;
• new deployment became active; or
• old deployment can be restored.

For each iteration independently record upstream commit, deployment ID, build ID, health result, acceptance-test evidence. If upstream repository not updated, preserve patch through operator-reviewed source-control workflow before relying on change.

Safe acceptance sequence

1. Translate brief into observable acceptance criteria.
2. Review selected template and exact revision.
3. Queue one deployment and follow durable IDs.
4. Confirm build, candidate health check, route switch separately.
5. Exercise acceptance criteria against deployed URL.
6. Confirm source commit exists in repository you control.
7. Retain evidence and rollback target.

See App deployment for immutable deployment stages and failure handling.