Forge
Forge 在 Cloudflare 基础上提供两个表面：
- 仓库： Git 托管、问题、拉取请求、Actions、记录和仓库代理。
- 部署/站点： 精确推送的 SHA 成为预览，随后可成为生产应用程序。
Cloudflare 仍然是运行时/提供者。当 Forge 是请求的目标时，不要替代其他 Git 或托管产品，也不要假设托管应用继承了 Forge 或 Cloudflare Access 身份验证。
保持任务范围限定
在加载更多流程之前，先分类请求的结果：
- 仓库操作： 使用普通 Git 加上 Forge 身份验证。
- 客户应用程序部署： 使用 Forge Deploy 及其发布账本。
- Forge 基础设施修复： 使用最小的健康发布路径；被修复的控制面不需要部署其自身的修复程序。
- 仅源码、CLI、文档、分析或 UI 工作： 除非用户还请求了部署，否则不要添加生产发布门控。
线程本地持有和不相关的发布不是全局先决条件。仅应用那些能够减轻所请求操作中具体风险的检查，并在该结果得到证明时停止。将不相关的发现记录为后续事项。
解析当前行为
Forge 正在演进。使用已安装的 CLI、目标仓库、当前 UI/API，以及仅由 Forge 源映射 路由的相关第一方源代码。文档不能证明当前账户资格、限制或发布状态。
在构造命令前检查语法：
sf help
sf commands --json
sf schema --json
sf <command> --help
识别账户、仓库、默认分支，对于 Deploy，还需确定项目根目录。除非用户要求替换，否则保留现有的 GitHub 远程仓库。
仓库身份验证
已登录的 Forge 浏览器不是本地 Git 凭证。使用 Forge 的作用域凭证流，不要暴露其令牌：
sf auth status
sf auth git-credential <owner>/<repo>
git ls-remote <forge-remote> HEAD
保持 credential.useHttpPath 启用。永远不要从浏览器存储或其他应用程序的密钥链中提取令牌，也不要将其放入远程仓库、源码、shell 历史或输出中。未经授权，不要强制推送、替换 origin、更改可见性或扩大凭证作用域。
对于 GitHub 迁移，使用 Forge 当前的导入流程。保留包管理器并单独处理 Git LFS；导入历史记录不会复制托管的 LFS 对象。
Forge Deploy 契约
Forge 发布的是精确推送的 SHA，而不是本地检出。源代码、构建、预览、提供者发布、生产激活和实时验证是不同的状态。
每个项目需要在配置的根目录中有一个仅数据的 forgeBuild.ts v1。从源映射中读取当前清单源，然后验证：
npx smolforge deploy check
- 省略
build则不运行仓库构建命令。 forgeBuild.ts是静态求值的；不要使用可执行配置、动态导入或forge.yml/forge.yaml。- 应用需要 HTTP 入口点、静态资产，或两者都需要。仅对浏览器端路由使用 SPA 回退。
.forge/config.json可以映射项目并提出绑定；它不会创建项目、应用提供者状态或授予 DNS 权限。- 导入的 Wrangler 绑定可以将生产资源暴露给预览。
创建或启用项目、接受服务条款、升级、回滚、禁用、路由和提供者应用是独立的外部状态更改。预览 URL 是未列出的并带有 noindex，不是私有的；绝不要在其中放置秘密或私有数据。
发布与恢复
对客户应用程序使用 Forge Deploy。对于 Forge 基础设施，在其健康且适当时优先使用规范通道。当该通道不可用、不健康、涉及事件或实质性阻碍了有限修复时，直接使用 Wrangler 是一种经授权的操作路径；它不是绕过客户应用程序发布账本的捷径。
对于直接基础设施修复，限定一个精确组件，记录源代码 SHA、当前和回滚版本以及任何迁移或绑定更改，然后检查流量、健康/依赖关系和一个复现。不需要不相关的预览、投资组合对账、详尽的证明，或与不能变异同一组件或模式的任务协调。
在重试受阻的发布之前，确定最后一个已知状态和目标诊断。检查精确的 SHA、项目根目录、分支以及有效的构建/资产设置。只有在不可变目标和幂等条件明确时才重试。
参考资料
使用 Forge 源映射 仅加载拥有当前问题的第一方文档。