docs: define pull request review policy

docs/CONTRIBUTING.md

@@ -17,6 +17,14 @@
 ## 4. 合并请求与代码审查
 合并前说明：需求/Issue、改动范围、测试命令及结果、截图（界面改动）、数据库变更、风险和回滚方式。至少一位非作者成员审查；无成员可审查时由负责人确认并记录。发现冲突先沟通，不直接覆盖。
 
+### 审阅与合并权限
+
+- 范涵宇、杨星萱完成工作后，必须从各自 `feat/...` 或 `docs/...` 分支向 `dev` 发起合并请求；作者不得自行合并。
+- 吉海燕负责审阅范涵宇、杨星萱提交的合并请求。只有吉海燕明确批准后，才可合并到 `dev`。
+- 吉海燕自己的前端分支须由范涵宇或杨星萱中至少一名非作者成员审阅；吉海燕在获得审阅意见后执行合并。
+- `dev` 合入 `main` 前，须完成对应阶段验收，并由吉海燕确认。任何成员不得直接向 `main` 推送功能改动。
+- 审阅意见、测试结果与最终批准结论应保留在 Gitea 合并请求中，便于项目验收和软著材料追溯。
+
 ## 5. 前后端协作
 - 所有接口以 `/api` 开头；Pydantic 定义输入输出模型。
 - 接口字段命名使用 `snake_case`，日期使用带时区的 ISO 8601；错误响应明确错误原因。

docs/TEAM_WORKPLAN.md

@@ -17,7 +17,7 @@
 1. `main` 只放稳定可演示版本；`dev` 是团队集成分支；每人从 `dev` 创建 `feat/<模块>-<描述>` 分支。
 2. 每项工作先建 Gitea Issue，写明负责人、验收标准、分支名和预计完成日期；完成后提交合并请求。
 3. 数据库结构、Pydantic Schema、`/api` 接口字段、Embedding 模型和实验口径属于公共边界，修改前须在 Issue 中说明并通知相关成员。
-4. 合并请求至少由一名非作者审查。页面改动附截图；后端改动附测试命令和结果；数据库改动附迁移/初始化说明。
+4. 范涵宇、杨星萱的合并请求由吉海燕审阅批准后才能合并到 `dev`；吉海燕自己的合并请求须由范涵宇或杨星萱中至少一人审阅。页面改动附截图；后端改动附测试命令和结果；数据库改动附迁移/初始化说明。
 5. 知识条目必须保留标题、分类、正文、来源链接、采集日期、核验状态和核验说明。杨星萱审核后，范涵宇才可纳入正式检索索引。
 
 ## 三、开始工作前：所有成员照此执行
@@ -45,7 +45,7 @@ git switch -c feat/<模块>-<简短描述>
 
 1. 在 Gitea 建立 Issue：写清目标、负责人、验收条件、分支名和预计完成日期。
 2. 开发完成后提交合并请求到 `dev`：说明改动文件、测试命令和结果；前端附截图，数据库附初始化/迁移说明。
-3. 由非作者成员审查；发现问题在合并请求讨论中处理，不私下覆盖他人提交。
+3. 范涵宇、杨星萱的合并请求由吉海燕审阅并明确批准后才能合并；吉海燕自己的合并请求至少由一名非作者成员审阅。发现问题在合并请求讨论中处理，不私下覆盖他人提交。
 4. 合并后更新 `docs/TASKS.md` 的状态，并在 Issue 写明“已完成、阻塞原因或下一步”。
 
 ### 3. 公共边界速查
@@ -223,4 +223,4 @@ npm run dev
 2. 有明确的验收步骤、测试结果或可核验资料。
 3. 公共接口、文档和任务状态已同步更新。
 4. 无真实密钥、个人隐私数据和未经授权的材料。
-5. 合并请求通过非作者审查并合入 `dev`；阶段验收后再合入 `main`。
+5. 合并请求按既定审阅权限获批后合入 `dev`；阶段验收并经吉海燕确认后再合入 `main`。