Vercel 部署与运维连接器

解决什么问题

管理 Vercel 上的项目时，工程师通常要在几件琐碎事之间来回切换：查项目列表、改环境变量、追某次部署的运行日志、验证域名解析、维护 Webhook。这些操作要么依赖 Web 控制台手动点，要么自己拼 vercel CLI 或直接调 REST API——后者意味着你得自己保管 token、处理过期与 scope，还得为每种操作手写请求构造。当这类动作被嵌进自动化流程时，凭证暴露的风险和脚本的维护成本会进一步放大。

oo-vercel 把这件事收敛为一条通道：通过 OOMOL 已连接的 Vercel 账户，用 oo CLI 调用 Vercel connector。凭证由 OOMOL 服务端注入，本地脚本里不会出现原始 token。

技能如何工作

该技能共暴露 23 个 action，按风险可以分成三档：

• 只读类：list_projects、get_deployment、get_runtime_logs、get_domain_config、list_webhooks 等，拿到结果直接返回，可以安全地放进自动化流程。
• 写入类：create_project、create_project_env、update_project、create_webhook、verify_project_domain 等，会真实改变 Vercel 侧的状态，执行前需要与使用者确认 payload 和预期效果。
• 破坏类：delete_project_env 等删除操作，必须先确认目标并获得明确批准。

调用方式是 schema 优先：先执行 oo connector schema 拿到权威的输入/输出契约，再按契约构造 JSON payload，通过 --data 传入（可以是 JSON 字符串或 @path/to/file.json，省略则发送 {}）。返回结构固定为 data 加 meta，执行追踪 id 位于 meta.executionId。

正常的调用流程不涉及登录：假设用户已安装 oo CLI、完成登录并连接 Vercel。仅当命令真正因认证或连接问题失败时，才回退到一次性的初始设置步骤（如 oo auth login 或重新连接 Vercel，认证类型为 API key）。

适用边界与注意点

• 只覆盖 Vercel 一侧的项目管理、部署、域名与 Webhook，不涉及 Next.js 应用逻辑本身。
• 写入和删除 action 的状态变更发生在远端，本地没有事务保护，误用可能直接改坏线上配置，务必先确认 payload。
• 若返回 HTTP 402 / OOMOL_INSUFFICIENT_CREDIT，说明 OOMOL 账户额度耗尽，需充值后再重试。
• 每个 action 的详细说明和精确命令在其对应的参考文件中，执行前建议先读参考文件再拉取实时 schema。