<!--
PR 模板 v2 — 两目的设计：
  · 上半部分（摘要 / 为什么现在做 / 如何验证 / 风险与回滚 / 破坏性变更）= 当下 reviewer 决策
  · 下半部分（权衡与备选 / 度量指标 / 契约面 / 高风险路径 / 后续跟进）= 未来 retro / bisect / changelog
  空段直接删整段，不要留空标题。规范全文：docs/standards/13-pr-description-spec.md
-->

## 摘要

<!-- 一句话：做了什么 + 为什么。
     反例："本 PR 在反复尝试后..."  正例："修 X bug：根因 Y，解法 Z" -->

## 主要组成

<!-- 多文件 / 多 topic / 多迭代 PR 用表格列要点：文件 + 改动 / 主题 + 文件。
     单文件 hotfix / 文档可删整段。 -->

## 为什么现在做

<!-- 触发这次改动的具体场景：bug 复现 / 性能撞墙 / 外部约束 / 技术债到期 / 复盘衍生。
     半年后回看能知道"当时为什么这个时间点做这个决定"。 -->

## 如何验证

<!-- 审查者拿到这个 PR 怎么验证 OK？逐项勾选状态清晰。 -->
- [ ] 后端 build 通过
- [ ] 前端 tsc / build 通过
- [ ] 涉及模块的 L1 集成测试通过
- [ ] （如有 UI 改动）MCP / 手动浏览器走查
- [ ] （如部署 / 配置 / 迁移类 PR）已实测对应业务 API 响应正确（[5 条规则·规则 4](../docs/standards/12-five-meta-rules.md)：完工 ≠ 命令成功）

## 风险与回滚

<!--
影响面 + 回滚预案。一句话也行。例：
- 数据迁移：是否需要回滚 SQL
- 外部依赖：是否需要先在 ADP/Outlook/SAP 加权限/凭据
- 部署侧：是否要改 .env / certs / pm2 / 数据库
-->

## 破坏性变更

<!-- 必填 Y / N。
     Y 时：依赖方清单 + 迁移路径 + 兼容窗口。
     此段始终保留（即使 N，也写 N），便于未来 changelog / bisect 检索。 -->

否（N）

---

<!--
↓ 下面五段是「未来回顾」段，按 PR 类型条件填，不填整段删。
  · 权衡与备选：触碰契约面 / 架构 / 高风险路径时必填
  · 度量指标：性能 / 体积 / CI 时长 / 覆盖率 / 错误率类 PR 必填
  · 契约面检查：触碰契约面才填
  · 高风险路径：触碰才填
  · 后续跟进：永远填（写"无"也行，强制思考一遍）
-->

## 权衡与备选方案

<!-- 考虑过的备选 → 没选的原因 → 接受的代价。
     给未来：类似决策不再重复推理。无权衡可写则删整段。 -->
- 考虑过：
- 没选的原因：
- 接受的代价：

## 度量指标

<!-- before/after 量化。性能 / bundle / CI 时长 / 错误率 / 覆盖率。
     无量化指标删整段。 -->
- before：
- after：

## 契约面检查

<!--
若不涉及对应契约面，勾否即可，无需展开。
判定流程详见 .agents/skills/contract-check/SKILL.md，规则原文详见 docs/standards/12-five-meta-rules.md。
-->

- [ ] **env 变量**（规则 1）：本 PR 是否引入新 `process.env.X`？
  - 若有，列出 keys：`<在此回答 / 无>`
  - 若有，是否同步加 `.env.example`？dev / test / uat / pro 4 套环境的 `.env` 由谁配？`<在此回答>`
- [ ] **契约面**（规则 1）：本 PR 是否改动 API 字段 / 状态枚举 / 权限点 / DB schema / UI 关键交互？若是，真相源 + 派生位（docs / 前端 / 测试）是否同步？
- [ ] **依赖**（规则 2）：本 PR 是否升级 deps？`package-lock.json` 主版本变化是否过 review？是否触碰已知 ESM 风险包（@scure/* / @noble/* 等）？

## 高风险路径与违规说明

<!--
按 CLAUDE.md「PR 拆分准则」段：以下路径默认必须单独 PR。
触碰则勾选；如合并到本 PR，必须在下方写明原因。
-->

触碰以下任一路径默认必须单独 PR：

- [ ] `prisma/schema/**` 或 `prisma/migrations/**`
- [ ] `docs/standards/**` / `CLAUDE.md` / `AGENTS.md`
- [ ] `.gitea/workflows/**`
- [ ] API 契约面 / 性能关键代码 / 热路径

**触碰但合并到本 PR 的原因**：

<!-- 不适用 / 在此说明（例：用户拍板 docs/standards 跟相关 skill 一起合，避免状态分裂） -->

**本 PR 是否违反 [12 五条规则](../docs/standards/12-five-meta-rules.md)**：

<!-- 不适用 / 在此说明 -->

## 后续跟进

<!-- 本 PR 留下的 TODO / 衍生 issue / 已知限制 / out-of-scope。
     用 issue 链接，不写"以后再说"。无衍生写"无"。 -->
-

## 关联

<!--
⚠ 解决 issue 的 PR **必须**写 Closes #N（一个 issue 一行，不要用逗号合并）：
- Closes #123
- Fixes #456
（关键字：Closes / Close / Fixes / Fix / Resolves / Resolve / 关闭 / 修复）

部分解决用 "Refs #N"（不会自动关 issue）。

注：通过 API / CLI 创建 PR 时此模板不会自动加载，需手动遵循本结构。
仅 Gitea 网页 "New Pull Request" 入口会自动预填。
-->