Prompt-assisted app deployment

What the feature does

The current prompt-to-app endpoint combines a written brief with an existing Git template repository and queues that repository through the normal immutable app-deployment pipeline. The brief is saved as provenance for later iterations.

It does not generate a new application repository from the brief. The template URL is required, and the first deployment contains the template source at the resolved revision unless that source already implements the 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"
}

The response includes durable app, deployment, and build IDs plus a build stream URL. Creation is asynchronous. Follow the deployment record or build stream until it reaches a terminal state; do not submit a duplicate deployment merely because progress is quiet.

Before submitting the request:

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

The prompt is context, not proof that the resulting source satisfies it. Test the deployed behavior against acceptance criteria derived from the 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"
}

This dispatches an asynchronous repair-agent task for an app you own and that has a Git source. Poll:

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

The status response combines the latest deployment state with iteration-thread state and any reported result evidence.

Important iteration boundary

The current repair path can work in its sandbox and request a fresh deployment, but persistence back to the developer’s Git repository is not yet a guaranteed stage. A done agent thread therefore does not by itself prove that:

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

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

Safe acceptance sequence

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

See App deployment for the immutable deployment stages and failure handling.