Ship Cloudflare Sites v1.1
基于仓库证据和用户请求范围运行。部署请求授权对指定环境执行常规部署工作流；仅在需要额外的破坏性、不可逆或实质性变更时提问。切勿从未指定的环境推断生产目标。
发现项目
- 在编辑前阅读仓库说明并检查当前工作树。
- 运行
scripts/audit-cloudflare-project.sh <project-root>并检查所有报告的阻塞项。 - 从文件（而非记忆）中解析框架、包管理器、适配器、Worker入口、Wrangler配置、环境、绑定、迁移、域名、CI路径和密钥名称。
- 使用仓库固定的CLI。在进行远程更改前，在本地
--help和当前官方文档中验证可变Cloudflare/OpenNext行为。 - 仅阅读相关参考：
- 阅读 references/release-workflow.md 以了解发布、回滚或版本迭代。
- 阅读 references/cloudflare-resources.md 以了解配置或更改D1、R2、密钥、域名、缓存、环境或可观测性。
选择操作模式
- 审计/计划： 保持只读。返回证据、阻塞项、风险和确切的下步操作。
- 开发/配置： 在本地编辑和验证。仅在用户请求配置或部署需要时才创建远程资源。
- 配置： 确认账户、区域、环境、名称和预期所有权；仅创建缺失的资源，并将返回的ID持久化到所选配置中。
- 发布： 构建一次，然后部署已验证的工件。对于低风险的发布，请求后使用直接部署；对于有风险或明确需要逐步发布的发布，使用版本上传加受控推广。
- 恢复： 选择已知良好的Worker版本，然后分别处理D1和R2状态。Worker版本不包含存储状态。
应用不变防护措施
- 区分本地、预览/预发和生产资源。使每个远程命令的目标明确。
- 将密钥值排除在源代码、输出、屏幕截图和shell参数之外。仅报告名称和存在状态。
- 在发布前检查脏工作树。不要丢弃、提交或发布无关的用户更改。
- 将D1变更建模为有序迁移，并在多个版本间优先采用扩展/回填/收缩策略。
- 对长期缓存资产使用不可变或带版本的R2键。将覆盖、删除、CORS变更和缓存清除视为一个协调变更。
- 将Worker自定义域名和R2自定义域名视为独立资源。分别验证顶点域、
www、规范重定向、证书和资产主机名。 - 不要将上传称为成功发布。验证公共主机名、关键路由、D1支持的行为、一个代表性R2对象和部署后日志。
生成发布记录
返回：
- 发布ID、Git提交、环境、Worker和存储资源名称；
- 已发布的源代码/配置变更以及排除的工作树更改；
- 本地检查点及其结果；
- D1迁移加上恢复书签/导出和兼容性顺序；
- R2/域名/缓存/密钥变更（不含密钥值）；
- Worker版本/部署ID和流量百分比（如可用）；
- 烟雾测试URL和结果；
- 回滚目标、存储注意事项和剩余手动操作。
如果检查点失败，在达到不安全边界前停止，保留证据，并说明剩余步骤。不要静默地削弱检查点。