Rule（规则）：每次对话都会读的规矩

# 项目规则（起步套件模板，请按你的项目改）

> 这个文件放在项目根目录。Claude Code 每次会话开头都会读它。保持短：只写"每次都该知道"的事。

## 沟通规则
- 始终用【你的语言】回答。
- 较长的回答写进 `reply.md`，终端只说一句确认（例：「已更新 reply 第 120 行」）。
- 我把需求写在 `req.md`，说「req 更新」你就去读；详见 `.claude/rules/req-reply-protocol.md`。

## 工作方式
- 先给 1 个推荐方案并直接执行；我说「给我几个选项」才讨论。
- 做不完整的部分必须明说，见 `.claude/rules/honest-reporting.md`。
- 看到标有 `[手动修改]` 的代码，不要改，见 `.claude/rules/protect-hand-edits.md`。

## 项目信息（请填写）
- 这个项目做什么：
- 技术栈：
- 怎么启动 / 怎么测试：
- 部署到哪里：

## 常用命令（见 `.claude/commands/`）
- `/status`：看当前进度与未完成事项
- `/estimate`：做之前先估算
- `/session-end`：结束前存档，方便下次接续

# 规则：诚实汇报完成状态

当任务里有"技术上做不到 / 做不完整"的部分时，禁止用看起来完整、实际不生效或有漏洞的东西掩盖。

1. 能做的部分做实，不偷工减料。
2. 做不到的部分明确标注：代码注释、界面警示条、文档里的 ⚠️ 小节，写清楚"这里是占位 / mock / 演示"。
3. 写清楚"差什么条件才能变成真的"（例：需要后端校验支付回调、需要真实 API Key），不要只写"暂不支持"。
4. 完成汇报时主动说，不要等被追问。
5. 汇报里区分三类：已验证（写怎么验证的）、没测到（写原因）、没做（写原因）。

典型触发场景：支付、多用户账号、权限校验、依赖用户暂时没有的资源（真实密钥、真实服务器）、"只在本地 mock 数据上测过"。

# 规则：保护我手写的部分

- 代码里标有 `[手动修改]`（或 `[hand-edited]`）注释的部分，不要修改，也不要"顺手优化"。
- 我告诉你"这里我手改过"时：在项目 `CLAUDE.md` 的"手动修改记录"表里记一行（日期 / 文件 / 说明），之后同样不改。
- 确实需要动这部分才能完成任务时：先停下，说明原因，等我同意。

手动修改记录（按需追加）：

| 日期 | 文件 | 说明 |
|------|------|------|

# 规则：req / reply 沟通协议

目的：把"人说的话"和"AI 的回答"存成两个文件，带行号，随时能回头查，也不会因为会话清空而丢。

## 文件
- `req.md`：我写需求（可以很随意，一条一行）。
- `reply.md`：你写回答。只能在文件末尾追加新区块，禁止改写、合并、删除旧区块。

## 触发
我说"req 更新"或"req 第 N 行后"：先读 `req.md` 确认行数够（不够就提示"文件可能没保存"），再回答。

## reply 区块格式
```
══════════════════════════════
❓ [日期 时间]
原文：
1. （req 原文逐字粘贴）
2. （req 原文逐字粘贴）

整理后的问题（对应原文）
1. (原文 [1][2]) 整理后的问题
───────────────────────────────
回答
1. (原文 [1][2]) 标题
   答案（用纯文本，不用表格和 Markdown 标记，因为我看的是原始文本和行号）
执行情况：[1] ✅  [2] ⏳ 等待确认
📌 req 第X-X行 → reply 第XX行 ✅
```
- 原文必须逐字，不能用"大意"代替。
- 整理后的问题永远要有，不能省。一个编号下有多条子要点，要逐条对应逐条回答，不能合并成一条而漏掉某条。
- `reply 第XX行` 是本区块 `══` 所在行号，写完用搜索确认，不要写"此处"。
- 终端里只输出：确认一句 + `✅ req 第X-X行 → reply 第XX行`。