sqhh99/point/project-records

# 工作日志：<一句话主题>
 
-**日期：** YYYY-MM-DD
-**分支：** `<branch>`（从 `main` 的 `<commit>` 拉出）
-**执行者：** <bot 名>
-**相关记录：** 审查归档 / PR 记录的链接
 
## 1. 请求
> 用户或 bot 的原话
这个请求实际要什么，一两句话。
 
## 2. 计划
按实际执行顺序列出步骤。
 
## 3. 改动的文件
| 文件 | 改动 | 对应的需求 |
每个文件写清为什么改，不只是改了什么。
 
## 4. 验证
跑了什么、没跑什么、为什么。没跑就直说。
 
## 5. 遗留事项
没做完、没覆盖、需要后续跟进的。

# <标题> 代码审查
 
-**日期：** YYYY-MM-DD
-**PR：** #<n>，审查时的 commit `<sha>`
-**范围：** 读了什么、怎么读的（读源码、追调用链、跑 CI / 本地运行）
-**未覆盖：** 有意没看的部分
 
## 状态摘要
一段话说明问题是否已处理，加上问题表。
 
| # | 问题 | 严重度 | 是否已处理 |
|---|------|--------|------------|
| 1 | ... | 中 | ❌ 未处理  /  ✅ 已处理 — YYYY-MM-DD |
 
## 合并门禁
两个平台 CI、阻塞讨论、版本号、安全门禁各自的结果。
 
## <n>. <问题标题>
**位置：** `file:line` · **严重度：** ... · **是否已处理：** ...
哪里有问题、什么路径会触发、实际有多容易触发——如实写，不夸大严重度。
**修复：** 处理后补上，描述实际改动而不是意图。
 
## 确认无误——不要「修」这些
看起来像缺陷但其实处理正确的地方，防止以后被人改坏。

# PR：<标题>
 
-**日期：** / **分支：** `<branch>` → `main` / **基线 commit：** `<sha>` / **相关记录：**
 
## 关联
关联的 Issue 或要解决的问题（写「Related to #123」）。
 
## 改了什么
用户或开发者会注意到的变化，不要只贴文件列表。
 
## 改动类型
-[ ] Bug 修复
-[ ] 新功能
-[ ] 性能或重构（不改变行为）
-[ ] 仅文档、CI 或构建
 
## 版本号
升了哪一位、理由；或「不升版本」。
 
## 如何测试
-[ ] `pnpm lint` 和 `pnpm typecheck` 通过
-[ ] `pnpm test` 通过（core + main）
-[ ] `pnpm e2e` 通过
-[ ] Windows 和 macOS 上的 CI 全绿（写明 commit）
-[ ] 在应用里实际走过受影响的流程（写明是哪个）
没跑的项留空，写明原因，以及合并前谁、在哪个环境里跑。
 
## 检查项
-[ ] UI 改动附了改前改后截图，放在 `docs/pull-requests/assets/<文件名>/`
-[ ] 数据库表结构变化附了迁移脚本和迁移测试
-[ ] 打包布局、依赖、安全相关（CSP、IPC、外部内容渲染）变化在上面单独说明
-[ ] AI 声明：哪些部分由哪个 bot 生成，是否验证