vibe-coding-production

# 上线准备：从 demo 到正式系统

这是 **vibe-coding-kit** 里负责"上线"的 Skill。只想验证想法的人用不到它——决定把项目做成能长期运行、给别人用的正式系统时，再来。

> 前置：先用 `vibe-coding-requirements` 说清需求、`vibe-coding-architecture` 选好技术。开发全程配合 `vibe-coding-survival` 避坑。

每个环节都配了**直接发给 AI 的话术**和**你用来验收的标准**——你不需要会写代码，只需会问、会检查。

---

## 准入检查（开始本阶段前必做）

本 skill 是流程第三阶段 **S3·上线准备**。开始前：

1. **读 `docs/进度账本.md`。** 确认 **S2 架构选型出口门已过**（技术栈已选定），且**用户明确确认"要做成正式系统、给别人用"**。只想跑 demo 的人不进 S3。
2. 任一条不满足就别开始：需求/选型没定完，先回 S1/S2；用户只想验证想法，就停在 demo，别硬上线。
3. 本阶段步骤对应账本：**S3.1 开发规范 → S3.2 安全基线 → S3.3 部署 → S3.4 测试验收 →（`可选`）S3.5 文档**。每过一步回写账本。

---

## 一、开发规范（对应 S3.1）

把下面四段整理成一份"规范说明"，每次让 AI 写代码时贴上，确保风格一致、日后好维护。

### 1.1 Git 分支策略（最简版）
```
main 分支          ← 永远是能稳定部署的版本
  └── dev 分支     ← 日常开发，AI 写的代码先合到这
        └── feat/xxx 分支  ← 每个新功能开一个，做完合回 dev
```
> "每次写新功能时，顺便告诉我：① 该建什么分支名 ② commit message 写什么。"

（完全不用 git 也没关系，但至少要做 `vibe-coding-survival` 里的"保住能用的版本"——那是 git 的朴素替代。）

### 1.2 日志规范
> "所有关键操作必须打日志，格式统一为 `[时间] [级别] [模块] 内容`。级别分三级：INFO（正常流程）、WARN（异常但能自动恢复）、ERROR（需我人工处理）。至少记录：请求进入、鉴权结果、数据库操作、外部调用、返回结果。卡密、密码等敏感信息脱敏，只显示前 4 位和后 4 位，中间用 *** 代替。"

### 1.3 错误处理规范
> "所有可能出错的地方都要显式处理。错误信息必须含三要素：① 哪里出错（模块/函数名）② 为什么出错（具体原因）③ 建议怎么解决。绝不要把错误悄悄吞掉（catch 了却什么都不做）。"

### 1.4 代码风格
> "代码注释用中文。每个函数上方注释说明：这函数做什么、输入什么、输出什么。变量名和函数名用英文，但要见名知意。"

---

## 二、安全基线（对应 S3.2）

> `▸ 过门`：8 条逐条确认（标"已做"或"不适用"）→ 账本 S3.2 标 ✅。涉及钱/别人隐私的，触发 survival 红线、提示找真人。

逐条把要求提给 AI，再逐条确认它做没做到。

| # | 安全要求 | 对 AI 说的话 |
|:-:|---------|-------------|
| 1 | 鉴权 | "所有接口都要验证身份，没通过的直接拒绝，返回 401。" |
| 2 | 防暴力破解 | "同一 IP 连续失败 N 次后，锁定 M 分钟。" |
| 3 | 输入校验 | "所有用户输入都要校验和清理，防止注入攻击。" |
| 4 | HTTPS | "生产环境必须用 HTTPS。" |
| 5 | 敏感信息保护 | "密钥、密码用环境变量或配置文件读取，绝不写死在代码里。" |
| 6 | 日志脱敏 | "敏感数据在日志里脱敏。" |
| 7 | 最小权限 | "数据库连接用最小必要权限，不要用 root。" |
| 8 | 错误信息 | "对外返回的错误信息不要暴露内部实现细节。" |

> **开源专属提醒：** 把代码公开（push 到 GitHub 等）之前，务必再确认一遍：代码里、配置里、提交历史里，**没有任何密钥、密码、token**。一旦推到公开仓库，就当全世界都看到了——即使事后删除也来不及，必须立刻作废并更换那个密钥。最稳妥的做法是把密钥放进一个单独的配置文件，并让 AI 帮你把它加进 `.gitignore`（让 git 永远忽略它）。

**注意红线：** 涉及真实收付款、存别人的个人信息等，别独自硬上——见 `vibe-coding-survival` 的「红线」。

---

## 三、部署策略（对应 S3.3）

> `▸ 过门`：部署步骤可执行、亲手走通一遍 → 账本 S3.3 标 ✅。

> "告诉我完整的部署步骤，每步用一句话说明为什么需要它。包括：① 服务器要装哪些依赖（运行环境、数据库等）② 文件放哪个目录 ③ 配置文件放哪 ④ 怎么启动服务 ⑤ 怎么设置开机自启 ⑥ 怎么看日志 ⑦ 怎么更新版本（停旧启新的流程）。"

**输出物：** 部署步骤清单。

---

## 四、测试验收（对应 S3.4）

> `▸ 过门`：验收清单是 checkbox 格式、每条可验证 → 账本 S3.4 标 ✅。

你不用写测试代码，但要有一份能逐条手动验证的清单。

> "给我一份功能验收清单，列出所有场景，我逐条手动验证。包括：① 正常流程的每个步骤 ② 异常情况（无效输入、超时、资源不足）③ 边界情况（空值、极限值）。"

每一条都要你**亲手跑通**才算过，不是 AI 说过就过（参见 `vibe-coding-survival` 的"让 AI 证明给你看"）。

**输出物：** 功能验收清单（可逐条打勾的 Checklist）。

---

## 五、文档要求（对应 S3.5 ·`可选`）

> `▸ 过门`：交付文档齐全 → 账本 S3.5 标 ✅；个人小项目可精简，跳过须留痕。

让 AI 每次写完代码都配套产出说明，免得过几天就忘了哪是哪。

> "每次代码修改完成后，给我一份简短说明：① 新增/修改了哪些文件 ② 每个文件做了什么（一句话）③ 怎么验证功能正常 ④ 有什么要注意的（配置改动、新增依赖等）。"

把这些汇总进你的「项目说明书」（模板见仓库 `examples/项目说明书-模板.md`）。

---

## 上线前最终检查清单

- [ ] 需求基准描述、技术栈、目录结构都记在项目说明书里
- [ ] 安全基线 8 条逐条确认
- [ ] 代码/历史里没有任何密钥、密码（尤其要开源时）
- [ ] 部署步骤亲手走通一遍
- [ ] 功能验收清单逐条打勾
- [ ] 留了一个"能用版"备份
- [ ] 涉及钱/别人隐私的部分，已找人把关或已确认不涉及

---

## 出口门（声称 S3 完成前必过）

> 以下约束来自项目治理配置 `harness.json`（`workflow.stages[S3].exit_gate`）和 `CLAUDE.md`。
> 在声称"上线准备完成"之前，你必须逐条确认。
> **全过之后，最后一步：在 `docs/进度账本.md` 把 S3 标记为「已完成、出口门 ✓」。这是流水线最后一阶段，到此全流程走完。**

### 必须产出的内容

- [ ] `docs/项目说明书.md` 中「安全清单」已填写
- [ ] `docs/项目说明书.md` 中「验收清单」已填写
- [ ] `docs/进度账本.md` 中 S3 各必经步骤为 ✅（S3.5 文档可跳并留痕）
- [ ] `docs/项目说明书.md` 中「部署步骤」建议填写（如准备部署）
- [ ] `docs/项目说明书.md` 中「开发规范要点」建议填写

### 硬性检查

- [ ] 「安全清单」中 8 条安全基线至少逐条确认（标注"已做"或"不适用"）
- [ ] 「验收清单」是可以逐条打勾的 checkbox 格式（`- [ ]` 或 `- [x]`）
- [ ] 每条验收项写成"我做 X，应该看到 Y"的可验证格式
- [ ] 代码和提交历史中无密钥、密码、token（尤其准备开源时）
- [ ] `.gitignore` 中已加入敏感配置文件（如有）

### 自检完成声明

全部通过后声明：
"✅ S3 出口门通过：安全清单已逐条确认，验收清单可逐条打勾验证，账本 S3 已标完成。全流程走完，可用 `vibe-coding-harness` 做最终质检。"