golive-skill：让 AI 智能体一键上线产品

mikehasa/golive-skill

发送域名设置（sending-domain setup）、DNS 记录、域名验证（domain verification）以及通过应用自身环境密钥的一次真实发送（已送达；新建子域名落入了垃圾邮件） · Vercel + Stripe（测试支付） 测试模式密钥（test-mode keys）和 webhook 注册、一次未签名请求的拒绝，以及一笔以签名验证事件（signature-verified event）形式送达的真实测试卡支付 · 这些都是对已有账户的已批准一次性运行（approved disposable run）；已完成的测试资源之后被删除，近期运行的一次性项目和记录也在同一监管下被清理。 跨配对仅有模拟覆盖（mocked coverage），并非等价的真实证据。 Supabase CLI 登录复用另行通过了只读验证；完整的部署测试使用了显式 token。 · 新用户的首账户设置以及每一个应用框架尚未被验证。

生命周期命令也有自己的证据：golive teardown 在一个一次性 Netlify 项目上做了真实演练（在没有 --confirm-destroy 时被阻止，然后被移除，账户的站点列表除了它之外没有变化），更早的运行清除了 golive 写入的 GoDaddy 与 Porkbun 记录、撤销了它签发的 Resend 发送密钥（sending keys），并移除了它注册的 Stripe 测试模式端点。

golive status 对一个真实项目做了只读运行；golive handoff --write 在一个仅含 Vercel 的一次性装置（fixture）上运行：两份产物都被写出并被审计（每一行声明都有一个出处标签、所有权证明（ownership proof）和下线门控（teardown gate）被具名，文档、其 JSON 副本、state 或 config 中没有任何形似凭据的值），项目随后通过已批准的下线流程被移除，技术栈仅有主机方，所以文档中其他服务提供商的行仍是模拟覆盖。证据请参见"观察到的验证"。

还存在一些实验性的适配器：Supabase Auth 配置、Supabase Auth 注册流程、其密码恢复（password recovery）和账户隔离（account isolation），以及 Cloudflare DNS。Supabase Auth 设置，注册、邮箱确认、密码最小长度、它使用的邮件发送器（mailer），加上站点 URL（site URL）和重定向允许列表（redirect allowlist），通过一个已批准的计划自动化，并被重新读取作为证据；该路径通过了一次性真实运行：策略写入在回读中成立（密码最小长度：6 → 12），auth-policy 最终仅留下内置邮件器建议（built-in-mailer advisory）作为唯一发现。 可选的注册流程（auth.e2e）通过同一次运行：一步已批准操作（auth:test-user，需要 --confirm-live）植入了一个真实的测试账户，该地址在确认前无法登录（email_not_confirmed），auth-signup/auth-session 检查证明了注册邮件、强制确认、确认后的登录、会话令牌（session token）以及匿名拒绝。 两点限制仍然存在：确认是通过 Auth 管理 API 而不是种子账户自身的邮箱点击来应用的；收件箱投递按设计由人工确认，golive 永不接触收件箱。 之后在一次性装置（一个已部署的 Vercel 站点，其声明的路由在无会话时返回 401，外加一张 RLS 保护的表）上的已批准运行同时演练了应用侧两条腿：对 auth.protectedPath 的匿名 GET 返回了 401，登录后的探针以已认证用户身份读取了那张表，因此探针的 bearer 修复不再是模拟覆盖。 该证据无法涵盖的部分：该运行中表的那一行是计数而非表名，且任何 401 都被算作受保护，WAF 或维护页面会被同样读出；这两点之后都被修复了（issue #30：探针会列出它读取的表名，且被拒绝的受保护路径会与公共根目录相互印证，目前为模拟覆盖且尚未重新实跑）。 密码恢复已在同一服务上实现但尚未真实验证：auth.recovery: true 增加一步已批准操作（auth:recovery，需要 --confirm-live），通过服务自身恢复调用来轮换那个已记录测试账户的密码，请求邮件、用管理 API 铸造链接、将其兑换为会话、用该会话设置新密码，auth-recovery 检查证明结果：请求被接受，无账户的地址获得相同回复（无账户枚举），已使用令牌在重放时被拒绝，新密码可以登录而被替换的密码不能。 收件箱点击和任何验证码都留给人工（auth:recovery-email 交接单中如此说明）；真实演练另行安排。 账户隔离同样在同一服务上实现：auth.isolation: true 与 auth.identityPath、auth.isolationPath 增加一步已批准操作（auth:isolation，需要 --confirm-live），植入第二个真实测试账户，地址由 auth.testEmail 派生，密码也仅存在于该次运行的内存中，并通过服务的管理 API 确认（没有第二次收件箱点击：该流程关注的是应用数据，而非投递）。 auth-isolation 检查随后以两个账户身份登录，并在生产 URL 上读取应用自身的两条声明路由：两者都必须拒绝匿名调用者（200 是关键发现）；每个账户的身份路由必须返回其自身的用户 ID 而永远不会是另一个的；行路由必须仅返回调用者自身的行，通过每个账户用其会话通过该路由写入并回读的一个唯一标记行来核对，因此答案中出现另一账户的标记即为跨账户读取并以失败（关键）判定。 当路由未声明时，非阻塞的 auth:isolation-routes 交接将任务交给应用代码（app-code task）；404 或被拒绝的会话会以该任务名跳过，绝不算作通过。

两者均已实现并有模拟覆盖，但尚未真实验证，它们的真实运行另行安排。

上文列出的 DNS、邮件和测试模式支付路径都是已测试的；自定义域名运行使用了 Porkbun 和 GoDaddy 记录写入；Cloudflare DNS 特别尚未构成经过验证的 alpha 路径，其他 auth 服务仍处于引导（guided）状态。参见提供商范围和观察到的验证。

完整的上线清单与路线图

一个可用的 URL 仅是开始。根据应用的不同，上线可能涵盖以下全部事项。

GoLive 应当判断哪些条目适用，协助你完成它们，并展示结果的证据。

一个静态站点不应被要求配置数据库；一个付费 SaaS 不应止步于一个已部署的主页。

这是我们的产品路线图，也是发布清单。勾选与删除线标记的是具体的真实测试里程碑，而非已完成的类别或你应用的已完成清单。

✅ 已真实测试 · 🚧 进行中 / 实验性（代码已存在；完整流程待补） · 🗺️ 计划中

发布应用

✅ 前端托管：在 Vercel 和 Netlify 上证明部署（deployment）。

在两条已测试路径上构建、部署并验证目标项目。

✅ 数据库：证明与 Supabase 和 Neon 的配置（provisioning）和连接。

已测试路径包含环境接入（environment wiring）和应用 CRUD（Create, Read, Update, Delete）检查。

✅ 环境接入：在两条已测试路径上连通托管与数据库凭据。

更广泛的密钥轮换（secret rotation）和环境生命周期管理仍是计划中。

🗺️ 后端 / 服务器：专用 API 服务、容器、持久服务器、运行时配置和健康检查。 应用路由已通过受支持的主机部署。

🗺️ Schema 与数据：经审核的迁移、安全上线、环境隔离和应用数据检查。这些在真实测试中分别被监督；可复用的工作流仍是计划中。

🗺️ 文件与对象存储：存储桶、上传、访问规则、签名 URL（signed URL）和生命周期策略。

使其成为完整的产品

🚧 认证（Authentication）：注册、登录、会话（sessions）、密码恢复和账户隔离。

Supabase auth 策略（注册、邮箱确认、密码最小长度、邮件发送器）以及站点 URL / 重定向允许列表通过已批准计划写入、重新读取作为证据，并由 auth-policy/auth-redirects 检查验证，在一次已批准的一次性运行中演练，其中策略写入在十二字符最小值处成立。 可选的流程（auth.e2e: true）通过同一次运行：auth:test-user 步骤植入了一个真实测试账户，该地址在确认前无法登录，auth-signup/auth-session 检查证明了注册邮件、强制确认、确认后的登录与会话令牌，在 Supabase 上以一次性项目形式真实验证，其中确认来自 Auth 管理 API 而非种子邮件点击，收件箱投递仍由人工确认，此后一次运行证明了一个声明的受保护路径（匿名 401）以及对 RLS 受保护表的登录读取，以计数而非表名报告。 密码恢复已在同一服务上实现，并由模拟测试覆盖（auth.recovery: true 增加 auth:recovery 步骤与 auth-recovery 检查，证明无账户枚举、一次性令牌与被替换的密码）；其真实运行仍待完成。 账户隔离，另一半，且更早的运行无法演练，同样以相同方式实现并有模拟覆盖：auth.isolation: true 与 auth.identityPath、auth.isolationPath 增加 auth:isolation 步骤（第二个真实测试账户，通过服务管理 API 确认并按 ID 与地址记录）以及 auth-isolation 检查，以两个账户登录并在应用自身路由上证明两者都不能读取对方的身份或行（跨账户读取关键失败；未声明或 404 的路由以 app-code 任务跳过）。其真实运行同样另行安排。 其他 auth 服务仍是引导状态。

🗺️ OAuth / 社交登录 / SSO：客户端注册、授权界面、权限范围（scopes）、回调 URL 和提供商审核。 当前 auth 提供商配置处于引导状态。

✅ 支付与订阅：通过 Stripe 证明测试模式结账（test-mode checkout）与 webhook 接收。

一笔真实测试卡支付以签名验证的 checkout.session.completed 事件送达。Live-mode 就绪、权限、退款和订阅事件仍待验证。

✅ 事务性邮件（Transactional email）：通过 Resend 证明发送域名设置、验证和真实投递。

通过应用自身环境密钥的一次发送已送达（在新建子域名上落到垃圾邮件，尚无 DMARC）。

借助 auth.smtp: resend，auth:smtp 步骤还会写入 auth 项目的自定义 SMTP，Resend 的主机/端口/用户、应用已使用的发件人，以及取自 golive 签发的发送密钥的 SMTP 密码（邮件流程的密钥，或它为 SMTP 单独签发的密钥），之后 auth-policy 将报告通过 Resend 的自定义 SMTP，而非对内置邮件器提出警告。 该密码为仅写（服务返回的是哈希值），所以回读只能确认设置，而一次真实的 auth 邮件才是唯一完整证明。

已实现并有模拟覆盖，尚未真实验证；退信处理（bounce handling）与更丰富的消息内容仍待验证。

✅ 域名 / DNS / HTTPS：在主机+DNS 配对上证明域名绑定、DNS 连线与 HTTPS 服务。

已测试：Vercel 绑定配合 Porkbun 和 GoDaddy 记录写入（使用 --confirm-dns），所有权验证（ownership verification）以及一次性子域名上的 HTTPS 200。Cloudflare DNS 适配器、重定向以及更多主机配对仍待真实验证。

🗺️ SMS 与推送通知：发送方注册、凭据、权限和投递检查。

🗺️ 第三方与 AI 服务：API 访问、权限范围、回调、配额（quotas）与功能测试。

缺失的环境变量今日可被检出；服务特定工作流仍是计划中。

🗺️ 后台工作：cron 计划、队列、worker、重试和失败任务恢复。

🗺️ 缓存、搜索与实时：缓存、搜索/向量索引（vector indexes）以及按需的实时服务。

带着信心发布，然后持续运行

🗺️ 安全与滥用控制：访问策略、暴露的凭据、安全头、限速和机器人防护。已存在范围化的 RLS / 顾问检查和凭据模式检查。

🗺️ 监控与告警：错误追踪、日志、正常运行时间（uptime）和可操作的告警。

今日仅有提供商的引导建议；已验证的配置仍是计划中。按需漂移检查（drift checks）已存在（golive status，下文），持续的监控与告警尚不存在。

🗺️ 产品分析：事件验证与同意/数据设置，超出今日的引导式提供商建议。

🚧 CI/CD 与安全发布：预览（previews）、发布检查、提升（promotion）、回滚（rollback）和漂移检测，建立在今日已批准的 CLI 部署之上。

部署身份，已实现，未真实验证：每次成功的部署都会记录提供商自身对所做部署的身份（deployed:<target>:id=<provider>|<deployment id>|<url>|<time> 写入 .golive/state.json，模拟覆盖；提供商若不报告身份则不记录），以便后续能力可以指定一个精确部署。

可选的预览部署与发布检查，已实现，未真实验证：在 golive.yaml 中设置 release.preview: true（并将 preview 加入 targets），plan 会新增 preview:deploy，一次创建，将当前工作树部署到主机的预览目标，命名提供商、项目、环境目标以及该预览与生产共享的源项目；当 live-mode 值填入预览环境名称时需 --confirm-live，并以 deployed:preview:id 记录提供商自身的身份，以及 release:check，该步骤不进行写入，声明 preview:deploy 为其前置条件，并在提供商对该部署的读取或其包的凭据扫描失败时令 plan 失败。 在已切割（cut）的 plan 中该检查是最后一步，因此它把关的是提升（其自身的 plan 在生产变更前重新运行该检查），而不是 plan 在它之前发出的生产部署。

提升与回滚，已实现，未真实验证：在 release.preview 可选之上开启 release.promote: true，plan 即请求一次按提升进行的发布；开启 release.rollback: true，plan 即请求将生产重新指向 golive 自身创建并记录的某个更早部署。

promote:production 命名它将作为生产的确切部署 ID，提供商仅在部署存在后报告其 ID，因此切割候选（cutting the candidate）和提升它是两次 plan，而预览会说明它是哪一个，由 release:check 在