solo-deploy

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/deploy

Deploy the project to its hosting platform. Reads the stack template YAML (

templates/stacks/{stack}.yaml

) for exact deploy config (platform, CLI tools, infra tier, CI/CD, monitoring), detects installed CLI tools, sets up database and environment, pushes code, and verifies deployment is live.

将项目部署到对应的托管平台。读取栈模板YAML文件（

templates/stacks/{stack}.yaml

）获取精确的部署配置（平台、CLI工具、基础设施层级、CI/CD、监控），检测已安装的CLI工具，设置数据库和环境，推送代码，并验证部署是否上线。

References

参考文档

```
templates/principles/dev-principles.md
```
— CI/CD, secrets, DNS, shared infra rules (solo-factory)
```
templates/stacks/*.yaml
```
— Stack templates with deploy, infra, ci_cd, monitoring fields (solo-factory)

Paths are relative to
solo-factory/
. If not found, try
1-methodology/
(solopreneur KB symlinks).

```
templates/principles/dev-principles.md
```
— CI/CD、密钥、DNS、共享基础设施规则（solo-factory）
```
templates/stacks/*.yaml
```
— 包含部署、基础设施、ci_cd、监控字段的栈模板（solo-factory）

路径相对于
solo-factory/
。如果未找到，请尝试
1-methodology/
（个体创业者知识库符号链接）。

When to use

使用时机

After

/build

has completed all tasks (build stage is complete). This is the deployment engine.

Pipeline:

/build

→ /deploy
→

/review

在/build完成所有任务（构建阶段结束）之后使用。这是部署引擎。

流水线：/build → /deploy
→ /review

MCP Tools (use if available)

MCP工具（如有可用则使用）

```
session_search(query)
```
— find how similar projects were deployed before
```
project_code_search(query, project)
```
— find deployment patterns across projects
```
codegraph_query(query)
```
— check project dependencies and stack

If MCP tools are not available, fall back to Glob + Grep + Read.

```
session_search(query)
```
— 查找之前类似项目的部署方式
```
project_code_search(query, project)
```
— 跨项目查找部署模式
```
codegraph_query(query)
```
— 检查项目依赖和技术栈

如果MCP工具不可用，回退使用Glob + Grep + Read。

Pre-flight Checks

预检查

1. Verify build is complete

1. 验证构建已完成

Check
```
.solo/states/build
```
exists.
If not found: "Build not complete. Run
```
/build
```
first."

检查
```
.solo/states/build
```
是否存在。
如果未找到：“构建未完成，请先运行/build。”

2. Detect available CLI tools

2. 检测可用的CLI工具

Run in parallel — detect what's installed locally:

bash

vercel --version 2>/dev/null && echo "VERCEL_CLI=yes" || echo "VERCEL_CLI=no"
wrangler --version 2>/dev/null && echo "WRANGLER_CLI=yes" || echo "WRANGLER_CLI=no"
npx supabase --version 2>/dev/null && echo "SUPABASE_CLI=yes" || echo "SUPABASE_CLI=no"
fly version 2>/dev/null && echo "FLY_CLI=yes" || echo "FLY_CLI=no"
sst version 2>/dev/null && echo "SST_CLI=yes" || echo "SST_CLI=no"
gh --version 2>/dev/null && echo "GH_CLI=yes" || echo "GH_CLI=no"

Record which tools are available. Use them directly when found — do NOT

npx

if CLI is already installed globally.

并行运行以下命令，检测本地已安装的工具：

bash

vercel --version 2>/dev/null && echo "VERCEL_CLI=yes" || echo "VERCEL_CLI=no"
wrangler --version 2>/dev/null && echo "WRANGLER_CLI=yes" || echo "WRANGLER_CLI=no"
npx supabase --version 2>/dev/null && echo "SUPABASE_CLI=yes" || echo "SUPABASE_CLI=no"
fly version 2>/dev/null && echo "FLY_CLI=yes" || echo "FLY_CLI=no"
sst version 2>/dev/null && echo "SST_CLI=yes" || echo "SST_CLI=no"
gh --version 2>/dev/null && echo "GH_CLI=yes" || echo "GH_CLI=no"

记录可用的工具。如果找到已安装的CLI工具，请直接使用——不要在全局已安装的情况下使用

npx

。

3. Load project context (parallel reads)

3. 加载项目上下文（并行读取）

```
CLAUDE.md
```
— stack name, architecture, deploy platform
```
docs/prd.md
```
— product requirements, deployment notes
```
docs/workflow.md
```
— CI/CD policy (if exists)
```
package.json
```
or
```
pyproject.toml
```
— dependencies, scripts
```
fly.toml
```
,
```
wrangler.toml
```
,
```
sst.config.ts
```
— platform configs (if exist)
```
docs/plan/*/plan.md
```
— active plan (look for deploy-related phases/tasks)

Plan-driven deploy: If the active plan contains deploy phases or tasks (e.g. "deploy Python backend to VPS", "run deploy.sh", "set up Docker on server"), treat those as primary deploy instructions. The plan knows the project-specific deploy targets that the generic stack YAML may not cover. Execute plan deploy tasks in addition to (or instead of) the standard platform deploy below.

```
CLAUDE.md
```
— 栈名称、架构、部署平台
```
docs/prd.md
```
— 产品需求、部署说明
```
docs/workflow.md
```
— CI/CD策略（如果存在）
```
package.json
```
或
```
pyproject.toml
```
— 依赖项、脚本
```
fly.toml
```
、
```
wrangler.toml
```
、
```
sst.config.ts
```
— 平台配置文件（如果存在）
```
docs/plan/*/plan.md
```
— 活跃计划（查找与部署相关的阶段/任务）

基于计划的部署： 如果活跃计划包含部署阶段或任务（例如“将Python后端部署到VPS”“运行deploy.sh”“在服务器上设置Docker”），将这些作为主要部署指令。计划包含了通用栈YAML可能未覆盖的项目特定部署目标。除了下面的标准平台部署步骤外，还要执行计划中的部署任务（或替代标准步骤）。

4. Read stack template YAML

4. 读取栈模板YAML

Extract the stack name from

CLAUDE.md

(look for

stack:

field or tech stack section).

Read the stack template to get exact deploy configuration:

Search order (first found wins):

```
templates/stacks/{stack}.yaml
```
— relative to this skill's repo (solo-factory)
```
1-methodology/stacks/{stack}.yaml
```
— solopreneur KB symlink
```
.solo/stacks/{stack}.yaml
```
— user's local overrides (from
```
/init
```
)

Extract these fields from the YAML:

deploy

— target platform(s):

vercel

cloudflare_workers

cloudflare_pages

fly.io

docker

app_store

play_store

local

deploy_cli

— CLI tools and their use cases (e.g.

vercel (local preview, env vars, promote)

)

```
infra
```
— infrastructure tool and tier (e.g.
```
sst (sst.config.ts) — Tier 1
```
)
```
ci_cd
```
— CI/CD system (e.g.
```
github_actions
```
)
```
monitoring
```
— monitoring/analytics (e.g.
```
posthog
```
)
```
database
```
/
```
orm
```
— database and ORM if any (affects migration step)
```
storage
```
— storage services if any (R2, D1, KV, etc.)
```
notes
```
— stack-specific deployment notes

Use the YAML values as the source of truth for all deploy decisions below. The YAML overrides the fallback tier matrix.

从

CLAUDE.md

中提取栈名称（查找

stack:

字段或技术栈部分）。

读取栈模板以获取精确的部署配置：

搜索顺序（找到第一个即停止）：

```
templates/stacks/{stack}.yaml
```
— 相对于本技能的仓库（solo-factory）
```
1-methodology/stacks/{stack}.yaml
```
— 个体创业者知识库符号链接
```
.solo/stacks/{stack}.yaml
```
— 用户本地覆盖配置（来自/init）

从YAML中提取以下字段：

deploy

— 目标平台：

vercel

、

cloudflare_workers

、

cloudflare_pages

、

fly.io

、

docker

、

app_store

、

play_store

、

local

deploy_cli

— CLI工具及其用例（例如

vercel (local preview, env vars, promote)

）

```
infra
```
— 基础设施工具和层级（例如
```
sst (sst.config.ts) — Tier 1
```
）
```
ci_cd
```
— CI/CD系统（例如
```
github_actions
```
）
```
monitoring
```
— 监控/分析工具（例如
```
posthog
```
）
```
database
```
/
```
orm
```
— 数据库和ORM（如果有，影响迁移步骤）
```
storage
```
— 存储服务（如果有，R2、D1、KV等）
```
notes
```
— 栈特定的部署说明

将YAML值作为以下所有部署决策的唯一依据。YAML会覆盖回退层级矩阵。

5. Detect platform (fallback if no YAML)

5. 检测平台（无YAML时回退）

If stack YAML was not found, use this fallback matrix:

Stack	Platform	Tier
`nextjs-supabase` / `nextjs-ai-agents`	Vercel + Supabase	Tier 1
`cloudflare-workers`	Cloudflare Workers (wrangler)	Tier 1
`astro-static` / `astro-hybrid`	Cloudflare Pages (wrangler)	Tier 1
`python-api`	Fly.io (quick) or Pulumi + Hetzner (production)	Tier 2/4
`python-ml`	skip (CLI tool, no hosting needed)	—
`ios-swift`	skip (App Store is manual)	—
`kotlin-android`	skip (Play Store is manual)	—

$ARGUMENTS

specifies a platform, use that instead of auto-detection or YAML.

Auto-deploy platforms (from YAML

deploy

field or fallback):

```
vercel
```
/
```
cloudflare_pages
```
— auto-deploy on push. Push to GitHub is sufficient if project is already linked. Only run manual deploy for initial setup.
```
cloudflare_workers
```
—
```
wrangler deploy
```
needed (no git-based auto-deploy for Workers).
```
fly.io
```
—
```
fly deploy
```
needed.

如果未找到栈YAML，使用以下回退矩阵：

技术栈	平台	层级
`nextjs-supabase` / `nextjs-ai-agents`	Vercel + Supabase	Tier 1
`cloudflare-workers`	Cloudflare Workers（wrangler）	Tier 1
`astro-static` / `astro-hybrid`	Cloudflare Pages（wrangler）	Tier 1
`python-api`	Fly.io（快速部署）或Pulumi + Hetzner（生产环境）	Tier 2/4
`python-ml`	跳过（CLI工具，无需托管）	—
`ios-swift`	跳过（App Store需手动操作）	—
`kotlin-android`	跳过（Play Store需手动操作）	—

如果

$ARGUMENTS

指定了平台，使用指定平台而非自动检测或YAML配置。

自动部署平台（来自YAML的

deploy

字段或回退矩阵）：

```
vercel
```
/
```
cloudflare_pages
```
— 推送代码时自动部署。如果项目已关联，推送到GitHub即可。仅在初始设置时运行手动部署命令。
```
cloudflare_workers
```
— 需要
```
wrangler deploy
```
（Workers不支持基于Git的自动部署）。
```
fly.io
```
— 需要
```
fly deploy
```
。

Deployment Steps

部署步骤

Step 1. Git — Clean State + Push

步骤1. Git — 清理状态 + 推送

bash

git status
git log --oneline -5

If dirty, commit remaining changes:

bash

git add -A
git commit -m "chore: pre-deploy cleanup"

Ensure remote exists and push:

bash

git remote -v
git push origin main

If no remote, create GitHub repo:

bash

gh repo create {project-name} --private --source=. --push

For platforms with auto-deploy (Vercel, CF Pages): pushing to main triggers deployment automatically. Skip manual deploy commands if project is already linked.

bash

git status
git log --oneline -5

如果工作区有未提交的更改，提交剩余更改：

bash

git add -A
git commit -m "chore: pre-deploy cleanup"

确保远程仓库存在并推送：

bash

git remote -v
git push origin main

如果没有远程仓库，创建GitHub仓库：

bash

gh repo create {project-name} --private --source=. --push

对于支持自动部署的平台（Vercel、CF Pages）： 推送到main分支会自动触发部署。如果项目已关联，跳过手动部署命令。

Step 2. Database Setup

步骤2. 数据库设置

Supabase (if

supabase/

dir or Supabase deps detected):

bash

undefined

Supabase（如果检测到

supabase/

目录或Supabase依赖）：

bash

undefined

If supabase CLI available:

如果Supabase CLI可用：

supabase db push # apply migrations supabase gen types --lang=typescript --local > db/types.ts # optional: regenerate types

If no CLI: guide user to Supabase dashboard for migration.

**Drizzle ORM** (if `drizzle.config.ts` exists):
```bash
npx drizzle-kit push      # push schema to database
npx drizzle-kit generate  # generate migration files (if needed)

D1 (Cloudflare) (if

wrangler.toml

has D1 bindings):

bash

wrangler d1 migrations apply {db-name}

If database is not configured yet, list what's needed and continue — don't block on it.

supabase db push # 应用迁移 supabase gen types --lang=typescript --local > db/types.ts # 可选：重新生成类型

如果没有CLI：引导用户到Supabase控制台进行迁移。

**Drizzle ORM**（如果`drizzle.config.ts`存在）：
```bash
npx drizzle-kit push      # 将架构推送到数据库
npx drizzle-kit generate  # 生成迁移文件（如果需要）

D1（Cloudflare）（如果

wrangler.toml

包含D1绑定）：

bash

wrangler d1 migrations apply {db-name}

如果数据库尚未配置，列出所需内容并继续——不要因数据库问题阻塞部署。

Step 3. Environment Variables

步骤3. 环境变量

Read

.env.example

.env.local.example

to identify required variables.

Generate platform-specific instructions:

Vercel:

bash

undefined

读取

.env.example

或

.env.local.example

以识别所需变量。

生成平台特定的操作说明：

Vercel：

bash

undefined

If vercel CLI is available and project is linked:

如果Vercel CLI可用且项目已关联：

vercel env ls # show current env vars

vercel env ls # 显示当前环境变量

Guide user:

引导用户：

echo "Set env vars: vercel env add VARIABLE_NAME" echo "Or via dashboard: https://vercel.com/[team]/[project]/settings/environment-variables"


**Cloudflare:**
```bash
wrangler secret put VARIABLE_NAME  # interactive prompt for value

echo "设置环境变量：vercel env add VARIABLE_NAME" echo "或通过控制台：https://vercel.com/[team]/[project]/settings/environment-variables"


**Cloudflare：**
```bash
wrangler secret put VARIABLE_NAME  # 交互式输入变量值

Or in wrangler.toml [vars] section for non-secret values

对于非机密值，也可在wrangler.toml的[vars]部分设置


**Fly.io:**
```bash
fly secrets set VARIABLE_NAME=value
fly secrets list

Do NOT create or modify
.env
files with real secrets. List what's needed, let user set values.


**Fly.io：**
```bash
fly secrets set VARIABLE_NAME=value
fly secrets list

请勿创建或修改包含真实密钥的
.env
文件。列出所需变量，让用户设置值。

Step 4. Platform Deploy

步骤4. 平台部署

Vercel (if not auto-deploying):

bash

vercel link          # first time: link to project
vercel               # deploy preview
vercel --prod        # deploy production (after verifying preview)

Cloudflare Workers/Pages:

bash

wrangler deploy              # Workers
wrangler pages deploy ./out  # Pages (check build output dir)

Fly.io:

bash

fly launch   # first time — creates app, sets region
fly deploy   # subsequent deploys

SST (if sst.config.ts exists):

bash

sst deploy --stage prod    # production
sst deploy --stage dev     # staging

Vercel（如果不使用自动部署）：

bash

vercel link          # 首次使用：关联到项目
vercel               # 部署预览版本
vercel --prod        # 部署生产版本（验证预览版本后）

Cloudflare Workers/Pages：

bash

wrangler deploy              # Workers部署
wrangler pages deploy ./out  # Pages部署（检查构建输出目录）

Fly.io：

bash

fly launch   # 首次使用——创建应用，设置区域
fly deploy   # 后续部署

SST（如果存在sst.config.ts）：

bash

sst deploy --stage prod    # 生产环境部署
sst deploy --stage dev     # 预发布环境部署

Step 5. Verify Deployment

步骤5. 验证部署

After deployment, verify it actually works:

bash

undefined

部署完成后，验证其是否正常运行：

bash

undefined

1. HTTP status check

1. HTTP状态检查

STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://{deployment-url})

2. Check for runtime errors in page body

2. 检查页面内容中是否有运行时错误

BODY=$(curl -s https://{deployment-url} | head -200)

3. Check Vercel deployment logs for errors

3. 检查Vercel部署日志中的错误

vercel logs --output=short 2>&1 | tail -30


**If HTTP status is not 200, or page contains error messages:**
1. Check `vercel env ls` — are all required env vars set on the platform?
2. If env vars missing: add them with `vercel env add NAME production <<< "value"`
3. If env vars set but wrong: `vercel env rm NAME production` then re-add
4. After fixing env vars: redeploy with `vercel --prod --yes`
5. Re-check HTTP status and page content

**Common runtime errors and fixes:**
- "Supabase URL/Key required" → add `NEXT_PUBLIC_SUPABASE_URL` + `NEXT_PUBLIC_SUPABASE_ANON_KEY` to Vercel
- "DATABASE_URL not set" → add `DATABASE_URL` to Vercel
- "STRIPE_SECRET_KEY missing" → add Stripe keys or remove Stripe code if not ready
- Blank page / hydration error → check build logs, may need `vercel --prod` redeploy

**Do NOT output `<solo:done/>` until the live URL returns HTTP 200 and page loads without errors.** If you cannot fix the issue, output `<solo:redo/>` to go back to build.

vercel logs --output=short 2>&1 | tail -30


**如果HTTP状态不是200，或页面包含错误消息：**
1. 检查`vercel env ls`——平台上是否设置了所有必需的环境变量？
2. 如果缺少环境变量：使用`vercel env add NAME production <<< "value"`添加
3. 如果环境变量已设置但值错误：`vercel env rm NAME production`然后重新添加
4. 修复环境变量后：使用`vercel --prod --yes`重新部署
5. 重新检查HTTP状态和页面内容

**常见运行时错误及修复方法：**
- "Supabase URL/Key required" → 在Vercel上添加`NEXT_PUBLIC_SUPABASE_URL` + `NEXT_PUBLIC_SUPABASE_ANON_KEY`
- "DATABASE_URL not set" → 在Vercel上添加`DATABASE_URL`
- "STRIPE_SECRET_KEY missing" → 添加Stripe密钥，或如果未准备好则移除Stripe相关代码
- 空白页面 /  hydration错误 → 检查构建日志，可能需要`vercel --prod`重新部署

**在实时URL返回HTTP 200且页面无错误加载之前，请勿输出`<solo:done/>`**。如果无法修复问题，输出`<solo:redo/>`返回构建阶段。

Step 6. Post-Deploy Log Monitoring

步骤6. 部署后日志监控

After verifying HTTP 200, tail production logs to catch runtime errors that only appear under real conditions (missing env vars, DB connection issues, SSR crashes, API timeouts).

Read the

logs

field from the stack YAML to get platform-specific commands:

Vercel (Next.js):

bash

vercel logs --output=short 2>&1 | tail -50

Look for:

Error

FUNCTION_INVOCATION_FAILED

EDGE_FUNCTION_INVOCATION_FAILED

504 GATEWAY_TIMEOUT

, unhandled rejections.

Cloudflare Workers:

bash

wrangler tail --format=pretty 2>&1 | head -100

Look for:

Error

, uncaught exceptions, D1 query failures, R2 access errors.

Cloudflare Pages (Astro):

bash

wrangler pages deployment tail --project-name={name} 2>&1 | head -100

Fly.io (Python API):

bash

fly logs --app {name} 2>&1 | tail -50
fly status --app {name}

Look for:

ERROR

CRITICAL

, unhealthy instances, OOM kills, connection refused.

Supabase Edge Functions (if used):

bash

supabase functions logs --scroll 2>&1 | tail -30

What to do with log errors:

Env var missing → fix with platform CLI (see Step 3), redeploy
DB connection error → check connection string, IP allowlist
Runtime crash / unhandled error → output
```
<solo:redo/>
```
to go back to build with fix
No errors in 30 lines of logs → proceed to report

If logs show zero traffic (fresh deploy), make a few test requests:

bash

curl -s https://{deployment-url}/           # homepage
curl -s https://{deployment-url}/api/health  # API health (if exists)

Then re-check logs for any errors triggered by these requests.

验证HTTP 200后，跟踪生产日志以捕获仅在真实环境下才会出现的运行时错误（缺少环境变量、数据库连接问题、SSR崩溃、API超时）。

从栈YAML的

logs

字段中读取平台特定的命令：

Vercel（Next.js）：

bash

vercel logs --output=short 2>&1 | tail -50

查找：

Error

、

FUNCTION_INVOCATION_FAILED

、

EDGE_FUNCTION_INVOCATION_FAILED

、

504 GATEWAY_TIMEOUT

、未处理的Promise拒绝。

Cloudflare Workers：

bash

wrangler tail --format=pretty 2>&1 | head -100

查找：

Error

、未捕获的异常、D1查询失败、R2访问错误。

Cloudflare Pages（Astro）：

bash

wrangler pages deployment tail --project-name={name} 2>&1 | head -100

Fly.io（Python API）：

bash

fly logs --app {name} 2>&1 | tail -50
fly status --app {name}

查找：

ERROR

、

CRITICAL

、不健康实例、OOM终止、连接被拒绝。

Supabase Edge Functions（如果使用）：

bash

supabase functions logs --scroll 2>&1 | tail -30

日志错误的处理方式：

缺少环境变量 → 使用平台CLI修复（见步骤3），重新部署
数据库连接错误 → 检查连接字符串、IP白名单
运行时崩溃 / 未处理错误 → 输出
```
<solo:redo/>
```
返回构建阶段进行修复
30行日志中无错误 → 继续生成报告

如果日志显示无流量（新部署），发送几次测试请求：

bash

curl -s https://{deployment-url}/           # 首页
curl -s https://{deployment-url}/api/health  # API健康检查（如果存在）

然后重新检查日志，查看这些请求是否触发了任何错误。

Step 7. Post-Deploy Report

步骤7. 部署后报告

Deployment: {project-name}

  Platform:  {platform}
  URL:       {deployment-url}
  Branch:    main
  Commit:    {sha}

  Done:
    - [x] Code pushed to GitHub
    - [x] Deployed to {platform}
    - [x] Database migrations applied (or N/A)

  Manual steps remaining:
    - [ ] Set environment variables (listed above)
    - [ ] Custom domain (optional)
    - [ ] PostHog / analytics setup (optional)

  Next: /review — final quality gate

部署项目：{project-name}

  平台：  {platform}
  URL：       {deployment-url}
  分支：    main
  提交：    {sha}

  已完成：
    - [x] 代码推送到GitHub
    - [x] 部署到{platform}
    - [x] 数据库迁移已应用（或不适用）

  剩余手动步骤：
    - [ ] 设置环境变量（如上所列）
    - [ ] 自定义域名（可选）
    - [ ] PostHog / 分析工具设置（可选）

  下一步：/review — 最终质量检查

Completion

完成信号

Signal completion

—

Output this exact tag ONCE and ONLY ONCE — the pipeline detects the first occurrence:

<solo:done/>

Do NOT repeat the signal tag anywhere else in the response. One occurrence only.

仅输出一次以下精确标签——流水线会检测第一个出现的标签：

<solo:done/>

请勿在响应的其他地方重复该信号标签。仅出现一次。

Error Handling

错误处理

CLI not found

CLI未找到

Cause: Platform CLI not installed. Fix: Install the specific CLI:

npm i -g vercel

npm i -g wrangler

brew install flyctl

brew install supabase/tap/supabase

原因： 未安装平台CLI。 修复： 安装对应的CLI：

npm i -g vercel

、

npm i -g wrangler

、

brew install flyctl

、

brew install supabase/tap/supabase

。

Deploy fails — build error

部署失败——构建错误

Cause: Build works locally but fails on platform (different Node version, missing env vars). Fix: Check platform build logs. Ensure

engines

in package.json matches platform. Set missing env vars.

原因： 本地构建正常，但平台构建失败（Node版本不同、缺少环境变量）。 修复： 检查平台构建日志。确保package.json中的

engines

与平台匹配。设置缺少的环境变量。

Database connection fails

数据库连接失败

Cause: DATABASE_URL not set or network rules block connection. Fix: Check connection string, platform's DB dashboard, IP allowlist.

原因： 未设置DATABASE_URL或网络规则阻止连接。 修复： 检查连接字符串、平台的数据库控制台、IP白名单。

Git push rejected

Git推送被拒绝

Cause: Remote has diverged. Fix:

git pull --rebase origin main

, resolve conflicts, push again.

原因： 远程仓库已更新，本地与远程分歧。 修复：

git pull --rebase origin main

，解决冲突，重新推送。

Verification Gate

验证关卡

Before reporting "deployment successful":

Run
```
curl -s -o /dev/null -w "%{http_code}"
```
against the deployment URL.
Verify HTTP 200 (not 404, 500, or redirect loop).
Check the actual page content matches expectations (not a blank page or error).
Only then report the deployment as successful.

Never say "deployment should be live" — verify it IS live.

在报告“部署成功”之前：

运行
```
curl -s -o /dev/null -w "%{http_code}"
```
检查部署URL。
验证 HTTP状态为200（不是404、500或重定向循环）。
检查实际页面内容符合预期（不是空白页面或错误页面）。
只有在满足以上条件后，才报告部署成功。

永远不要说“部署应该已上线”——要验证它确实已上线。

Critical Rules

关键规则

Use installed CLIs — detect
```
vercel
```
,
```
wrangler
```
,
```
supabase
```
,
```
fly
```
,
```
sst
```
before falling back to
```
npx
```
.
Auto-deploy aware — if platform auto-deploys on push, just push. Don't run manual deploy commands unnecessarily.
NEVER commit secrets — no .env files with real values, no API keys in code.
Preview before production — deploy preview first, verify, then promote to prod.
Check build locally first —
```
pnpm build
```
/
```
uv build
```
(or equivalent) before deploying.
Check production logs — always tail logs after deploy, catch runtime errors before declaring success.
Report all URLs — deployment URL + platform dashboard links.
Infrastructure in repo — prefer
```
sst.config.ts
```
or
```
fly.toml
```
over manual dashboard config (see infra-prd.md).
Verify before claiming done — HTTP 200 from the live URL + clean logs, not just "deploy command succeeded".

使用已安装的CLI — 在回退到
```
npx
```
之前，先检测
```
vercel
```
、
```
wrangler
```
、
```
supabase
```
、
```
fly
```
、
```
sst
```
。
支持自动部署 — 如果平台在推送时自动部署，只需推送代码。不要不必要地运行手动部署命令。
绝对不要提交密钥 — 不要包含真实值的.env文件，不要在代码中包含API密钥。
先预览再发布到生产环境 — 先部署预览版本，验证后再升级到生产环境。
先在本地检查构建 — 部署前先运行
```
pnpm build
```
/
```
uv build
```
（或等效命令）。
检查生产日志 — 部署后始终跟踪日志，在宣布成功前捕获运行时错误。
报告所有URL — 部署URL + 平台控制台链接。
基础设施即代码 — 优先使用
```
sst.config.ts
```
或
```
fly.toml
```
而非手动控制台配置（见infra-prd.md）。
验证后再标记完成 — 实时URL返回HTTP 200 + 日志无错误，而不仅仅是“部署命令执行成功”。