Rollouts 部署观察

Rollouts 对 Teams/Enterprise 提供，从 PR 创建到部署后检查变化。支持 Origin、GitHub、GitLab.com、Bitbucket Cloud，最多监控 200 个仓库。

验证计划与检查时点

PR 打开后读取 diff 和相关系统，生成包含风险、预期效果、观测信号及缺少埋点的计划。GitHub/GitLab.com/Bitbucket Cloud 以评论呈现，Origin 在 PR 页面显示。只有有仓库写权限的人可提及评论指定 handle 修改计划。

部署事件到达后按环境分别检查：立即、20 分钟、1 小时、1 天和 3 天。staging 通过不保证 production 通过。发现回归或预期效果未发生时开 issue 并通知作者。

四步接入

在 Automations > Team > From Cursor 启用 Rollouts，依次选择仓库、接入 deployment events、连接遥测工具、配置通知。至少需要一个观测工具，未连接时变化会停在 pending，不能检测问题。

CI 使用 CURSOR_API_KEY，可为用户、服务账号或带 admin:* 的 team Admin key。官方流程先在 api2.cursor.sh 的 auth/exchange_user_api_key 交换 token，再带 Bearer 和 Connect-Protocol-Version: 1 调用 api.cursor.com 的 factory.v1.DeploymentsService。

先用 CreateEnvironment/CreateService 建立环境与服务；部署前 CreateDeployment 带 deploySourceUri、environment、service、commit SHA 形式的 deployVersion 和 started event；结束后 AppendDeploymentEvent 报 completed.succeeded、completed.failed 或 aborted。具体请求体按官方示例接入，报告失败不能使真正部署失败。

状态和人工修复

列表按 Attention、Monitoring、Pending、Verified 分组，每个环境独立显示 Deploying、Monitoring、Verified、Deploy failed、Issues found 等状态。开放 issue 或失败部署进入 Attention；全部 issue 关闭后计为 Verified，重开则回 Attention。因此 Verified 不等于所有问题都已自动修复。

issue 页 Fix issue 启动 Cloud Agent，后续 View fix 可重新打开；也可 Close 并提供原因。Rollouts 不会自行 merge、revert 或 rollback。Services 中 Archive 只隐藏服务，历史部署仍保留，Restore 可恢复。

跳过规则与通知

默认跳过不影响运行行为的纯文档、格式/lint/错字和 test-only 变化，只在明确匹配时跳过并评论原因。清空 Which changes to monitor 文本可监控所有变化，提及跳过评论中的 handle 也可要求监控。

Personal Slack Notifications 初始只发 Issues found，可再开启部署成功/失败和 Check clear。可发送 DM 或公共频道，按界面邀请所需 App；不支持 Slack Connect。管理员须先接入 Slack，团队通知默认值仅管理员能改，个人可覆盖。官方说明 Rollouts Slack 通知在 Privacy Mode 下不可用，不应套用普通 Slack Cloud Agents 的隐私支持结论。