快速辅助应用程序部署

该功能的作用

当前的应用程序提示端点将书面摘要与 existing Git template repository 相结合，并通过正常的不可变应用程序部署管道对该存储库进行排队。该概要被保存为以后迭代的出处。

not 会根据摘要生成新的应用程序存储库。模板 URL 是必需的，并且第一个部署包含已解析修订版的模板源，除非该源已经实现了请求。

根据提示和模板创建


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

响应包括持久应用程序、部署和构建 ID 以及构建流 URL。创建是异步的。遵循部署记录或构建流，直到达到最终状态；不要仅仅因为进展缓慢而提交重复的部署。

提交请求之前：

审查存储库及其许可证；
固定或记录部署使用的确切源版本；
验证其安装、构建、运行、端口和运行状况行为；和
对提示和存储库保密。

提示是上下文，而不是结果源满足它的证据。根据简报得出的验收标准测试部署的行为。

请求稍后更改


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

这将为您拥有且具有 Git 源的应用程序分派异步修复代理任务。民意调查：


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

状态响应将最新的部署状态与迭代线程状态以及任何报告的结果证据相结合。

重要的迭代边界

当前的修复路径可以在其沙箱中工作并请求全新部署，但仍无法保证持久返回到开发人员的 Git 存储库。因此，done 代理线程本身并不证明：

请求的更改存在于上游存储库中；
建立了特定的提交；
测试通过；
新的部署开始生效；或
可以恢复旧的部署。

对于每次迭代，独立记录上游提交、部署 ID、构建 ID、运行状况结果和验收测试证据。如果上游存储库未更新，请在依赖更改之前通过操作员审查的源代码控制工作流程保留补丁。

安全接受顺序

将简报转化为可观察的验收标准。
检查所选模板和确切的修订版本。
对一项部署进行排队并遵循其持久 ID。
分别确认构建、候选人健康检查和路由切换。
针对已部署的 URL 执行验收标准。
确认源提交存在于您控制的存储库中。
保留证据和回滚目标。

有关不可变的部署阶段和故障处理，请参阅应用部署。