docs: 同步交接摘要 / PRD / 原型，并记录品牌改名「深学在线」

- 交接摘要补 §一·三十五~§一·三十八：角色与授权、需求收敛（4 角色 / 10 菜单 / 取消二期）、
  PC 端重搭后的 UI 修复与卡片式基线、品牌改名与新标识
- PRD 与功能逻辑卷只改标题行与产品代号线；**文件名不动** —— verify-docs.py 按路径读，
  全库还有 20+ 处按文件名引用，改名会连带炸脚本
- 原型 index / admin-web / teacher-app / student-app 的品牌区改「深学在线」，
  admin-web 的 .mark（10 处）换成内嵌的新标 data URI，保持原型"单文件自包含"的约定
- 根 AGENTS.md 与 frontend-pc 的规范同步：接线检查补第 ⑨ 项（SVG 资产是不是合法 XML ——
  SVG 注释里出现连续两个减号就 not well-formed，图标裂开而控制台一句话都不报）、
  「最容易写错的约定」6 -> 7 条（新增品牌标）
- deploy/docker-compose.yml 只改头注释里的项目名（compose 的 name 与七牛对象前缀都没动）

docs/数据信息填报系统PRD-功能逻辑卷.md

@@ -1,7 +1,7 @@
-# 数据信息填报系统 · 功能逻辑 PRD
+# 深学在线 · 功能逻辑 PRD
 
-> 产品代号：**填报通 / CollectFlow**（暂定）
-> 版本：V1.9（2026-09-28 同步数据库决策与字段落库方式）
+> 产品代号：**深学在线**
+> 版本：**V2.0**（2026-10 需求收敛：4 角色 / 不设二期 / 门禁失败只留「重新填写」）
 > 日期：2026-09-24
 > 文档定位：**只描述"系统怎么运转"，不含数据库设计、接口定义、代码结构**
 > 配套文档：《数据信息填报系统PRD》（主 PRD，含库表与接口）—— 主 PRD 回答"做什么"，本文回答"怎么运转"
@@ -11,6 +11,7 @@
 
 | 版本 | 日期 | 变更内容 |
 |---|---|---|
+| **V2.0** | **2026-10** | **需求收敛**：① 角色由 6 个减为 **4 个**（平台运营 / 学校管理员 / 班主任 / 学生；删「副班主任」「审核员」）；② §2.2 社会收集、§3.12 历史数据整理器、专项职业能力相关段落 **整节作废**；③ §3.1 门禁失败**只留「重新填写」**——原「申请加入名单」（FR-509）通道整体撤销，名单外的人由老师手工加人，系统内不展示任何联系方式；④ **不再有任何二期功能设计**（OCR 与材料识别改为「缓做，等供应商」）。跨文档数字：接口 **119** / 错误码 **54** / 权限码 **28** / 原型 **29 屏**。 |
 | V1.0 | 2026-09-24 | 初稿：角色/流转/12 个功能逻辑/规则速查/20 个边界场景/文案规范 |
 | **V1.1** | 2026-09-24 | **压缩逻辑按实测重写**：用 28 张真实 A4 扫描件实测，**300dpi/q85 下 28/28 达标（平均 806KB）**，无需牺牲清晰度。① §3.7.1 新增实测结论；② §3.7.3 由"逐级降质逼近"改为"一次编码到位 + 兜底路径"；③ §3.7.4 抽检机制标注为"实测不触发"；④ §4 速查表、§7 未决事项同步更新 |
 | **V1.2** | 2026-09-24 | **修正材料来源通道**：取消"直接拍照"（实测 4 类材料无一来自现场拍照，均为截图/扫描件/照相馆电子版）。① §3.5 改为"**微信聊天记录 / 手机相册 / 聊天文件**"三通道，拍照默认关闭；② 新增"**必须保留原始文件名**"设计逻辑（聊天记录可拿到原始名，相册拿不到）；③ 新增来源引导文案与 4 个相关异常分支；④ §4 速查表、§5 场景表（+4 条）、§6 文案、§7 未决事项同步更新 |
@@ -85,8 +86,9 @@
 | 平台运营 | PC | 开通/停用租户、查看全局用量、内容风控 | 查看任何考生的材料内容 |
 | 学校管理员 | PC（主）+ 手机（次） | 建任务、配规则、导名册、终审、导出上报 | 修改已归档任务的配置 |
 | 班主任 | PC + 手机 | 催报、初审、批量通过、代传材料 | 终审、导出、查看其他班级 |
+| ~~副班主任~~ / ~~审核员~~ | — | **已删除**（2026-10 需求收敛）：内置角色由 6 个减为 **4 个**（平台运营 / 学校管理员 / 班主任 / 学生） | — |
 | 填报人（学生） | 微信小程序 | 填报、上传、修改、撤回（未审核前） | 查看他人材料、修改已终审内容 |
-| 社会填报人 | 小程序 / H5 | 自主填报 | 查看他人、指定班主任 |
+| ~~社会填报人~~ | — | **不做**（2026-10 取消社会收集） | — |
 
 **端能力差异（功能逻辑层面）**
 
@@ -113,7 +115,7 @@
 填报人扫码 → 微信授权
    ↓ 【门禁】填写「姓名 + 身份证号」→ 与名单匹配
    ↓ 匹配成功 → 绑定名单项 → 回填只读信息 → 进入填报
-   ↓ 匹配失败 → 统一提示页（重新填写 / 申请加入名单），不给填报
+   ↓ 匹配失败 → 统一提示页（只有「重新填写」+ 提示联系老师），不给填报
 填报人逐项填写表单 → 逐项上传材料
    ↓ 每次上传后立即：命名规范化 → 压缩 → 校验 → （必要时）OCR
    ↓ 填报人看到"文件名已规范 / 体积已压缩 / 有无问题"的即时反馈
@@ -133,22 +135,11 @@
 
 > 🔒 **门禁不变式**：**没有名单，就不能填报。** 名单是唯一的准入依据，不存在"自由填报"。
 
-### 2.2 社会收集（差异流程）
+### 2.2 社会收集（差异流程）—— **不做**（2026-10 取消）
 
-```
-【前置】管理员建任务（模式=社会收集，无班主任层，但同样必须先导入名单）
-   ↓ 导入名单（预报名名单 / 意向名单 / 报名点收集的名单）
-   ↓ 生成公开填报二维码/链接
-社会人员扫码 → 微信授权
-   ↓ 【门禁】填写「姓名 + 身份证号」→ 与名单匹配（规则与学校收集完全一致）
-   ↓ 匹配失败 → 统一提示页，不给填报
-填报 → 上传材料（同样走规范化 / 压缩 / 校验）
-提交 → 直接进入【待终审】（跳过初审）
-管理员终审 → 通过 → 导出
-```
-
-> ⚠️ **与学校收集唯一的差异**：审核流跳过班主任层。**名单导入与身份核验两项完全一致。**
-> 📌 初稿曾写"社会收集名册可选、允许自由填报"，本版已废除。
+> ⚠️ **本节作废**：社会收集（`collectMode=2`）**不再设计**，传入直接返回 **`40044`**。
+> 原设计的差异点（跳过班主任初审、直达管理员终审）记录在此仅供追溯。
+> **名单导入与身份核验两项与学校收集完全一致**，这条不变。
 
 ### 2.3 状态机
 
@@ -219,7 +210,7 @@
         本地先做格式 + 校验位校验 → 不合格当场提示，不发请求
   ↓ ⑤ 提交匹配（在服务端完成）
   ↓ ⑥ 命中 → 绑定 → 进入填报页
-       未命中 → 失败提示页（重新填写 / 申请加入名单）
+       未命中 → 失败提示页（只有「重新填写」+ 提示联系老师）
 ```
 
 **匹配判定顺序**
@@ -244,9 +235,10 @@
 
 > "**没有找到你的信息。**
 > 请核对姓名和身份证号是否与老师提供的名单一致。
-> 如果确实已报名，可以申请加入名单，由老师审核。"
+> 如确认已报名，请联系老师把你加入名单。"
 
-提供两个动作：**重新填写** ／ **申请加入名单**（FR-509）——**均为系统内动作，不展示任何联系方式**
+只提供一个系统内动作：**重新填写**；另加一句纯文案提示"请联系老师把你加入名单"
+（原「申请加入名单」自助通道已于 2026-10 撤销）——**系统内不展示任何联系方式**
 
 **🔒 安全要求（重要，必须实现）**
 
@@ -270,10 +262,10 @@
 | 同一微信帮多人填（哥哥帮弟弟） | 允许，但**切换填报人需重新走核验**，且记录操作留痕 |
 | 名单外的人确实要报名 | 本版按需求实现为"**不给填、只提示**"，需老师去后台把人加进名单（见下方待决策事项） |
 
-> 🤔 **待决策：名单外的人怎么处理？**
-> **修订（FR-509）**：名单外的人原先只能"联系老师"，老师需反复去后台加人——这在几百人的社会收集中会成为运营负担。现已改为**学生自助申请 + 管理员逐条审批**，且**系统内不展示联系方式**。
-> **建议方案**（未纳入本版）：在失败页增加"**申请加入名单**"按钮 → 生成管理员待办 → **管理员批准后自动放行**。
-> 这样既守住"必须先有名单"的门禁，又不用老师手工加人。**请确认是否采纳。**
+> ✅ **已决策（2026-10，需求收敛）：名单外的人由老师在任务里手工加人，不做自助通道。**
+> 曾经的"学生自助申请 + 管理员逐条审批"（FR-509）已**整体撤销**（模块、表、接口、页面、错误码一并删除）。
+> 门禁失败页只保留「重新填写」+ 一句"请联系老师把你加入名单"，**系统内不展示联系方式**。
+> 这样守住的仍是同一条铁律：**没有名单，就不能填报** —— 加人的动作留在老师手里。
 
 ### 3.2 报考范围聚合与任务创建
 
@@ -323,7 +315,7 @@
 | 整批出现多组不同的报考项 | 正常（一个任务可覆盖多个工种），但需管理员确认无误 |
 | 老师发现填错想改 | 管理员可直接修改名单行（留痕），范围自动重新聚合 |
 | 名单里出现参考字典没有的职业/工种 | 仅提示"可能拼写有误"，**不阻断**（最终以机构要求为准） |
-| 认定类型 = 专项职业能力 | 三项中只有"职业"有值，工种/等级允许为空 |
+| ~~认定类型 = 专项职业能力~~ | **不做**（2026-10 取消；传 `certType=3` 返回 `40044`） |
 
 **关键设计**
 
@@ -450,13 +442,13 @@
 
    | 认定类型 / 等级 | 最多可选科目数 | 可选项 |
    |:--:|:--:|---|
-   | **专项职业能力** | **0** | 无补考 |
+   | ~~**专项职业能力**~~ | ~~0~~ | **不做**（2026-10 取消） |
    | 三 / 四 / 五级 | **1** | 补考理论、补考实操 中选一个 |
    | 一 / 二级 | **2** | 补考理论、补考实操、补考综合 中最多选两个 |
 
    ⇒ 达到上限后，其余科目选项**置灰不可选**（而不是事后报错）。
 
-6. **专项职业能力的整体降级**：`认定类型 = 专项职业能力` 时，**工种、等级、补考三项全部隐藏**，官方规则 05/06/07 整体跳过。
+6. ~~**专项职业能力的整体降级**~~：**不做**（2026-10 取消二期；`certType=3` 直接 `40044`）。原设计是：该类型下工种、等级、补考三项全部隐藏，官方规则 05/06/07 整体跳过。
 
 7. **下拉严格受限**：官方规定"**若手动输入则只能填写下拉选项中包含的值**"。
    ⇒ 移动端一律用选择器；PC 端允许输入但做**严格值匹配**，不在选项内的值直接拒绝。
@@ -494,7 +486,7 @@
 | 提交后又想改 | 未进入审核前可"撤回"；已进入审核需联系老师驳回 |
 | **报考范围已关闭**（认定机构批次结束） | 提示"本批次已结束"，不允许新建填报单；已提交的不受影响 |
 | **学生发现自己的报考职业/工种/等级不对** | 提示"该三项由老师统一确定，请联系老师修改"，**不允许自行输入** |
-| **选了"专项职业能力"却想填工种/等级** | 该三项不显示；若历史数据带出旧值，自动清空 |
+| ~~选了"专项职业能力"却想填工种/等级~~ | **不做**（2026-10 取消该认定类型） |
 
 ### 3.5 材料上传与材料识别逻辑
 
@@ -634,7 +626,7 @@
 | # | 场景 | 问题 |
 |---|---|---|
 | 1 | 填报上传 | 用户在"身份证"槽位传了学籍表 → 需要发现并提示 |
-| 2 | 整理器散图分拣 | 一堆没有目录的散图 → 需要判断每张是什么，才能归入目录 |
+| ~~2~~ | ~~整理器散图分拣~~ | **已取消**（2026-10，整理器模块删除） |
 | 3 | 审核辅助 | 班主任想快速确认"这堆材料里有没有传错的" |
 | 4 | 缺失检测兜底 | 例如"其它佐证材料"传了 3 张，需要区分它们分属什么 |
 
@@ -795,8 +787,8 @@
 |---|---|---|
 | 填报上传 | 每次上传后（异步） | 冲突时提示 + 一键移动 |
 | 提交前总校验 | 提交时 | 汇总"疑似传错"清单，按 🟡 警告呈现 |
-| 整理器·散图分拣 | 无目录结构时 | 自动归属；判不出的进待人工归属 |
-| 整理器·体检报告 | — | 输出"疑似错位"清单 |
+| ~~整理器·散图分拣~~ | — | **已取消**（2026-10） |
+| ~~整理器·体检报告~~ | — | **已取消**（2026-10） |
 | 审核辅助 | 班主任查看时 | 材料卡片上显示"系统判定：身份证 92%" |
 | 规则优化 | 定期 | 用人工纠正确认的结果反哺关键词表 |
 
@@ -1146,38 +1138,13 @@
 - 系统记录每个人剩余的授权额度，额度不足时自动降级到服务号或短信；
 - 产品层减少催报次数、提升一次填完率（减少返工即减少通知）。
 
-### 3.12 历史数据整理器逻辑
+### 3.12 历史数据整理器逻辑 —— **已取消**（2026-10 需求收敛）
 
-**用途**：处理老师手上已经存在的"乱文件夹"，无需重新收集即可产出规范结果。作为获客入口（先看到价值，再谈系统上线）。
-
-**触发**：上传一个压缩包，或指定一个已有目录结构。
-
-**处理步骤**
-1. **解析文件树**：识别目录与文件名，生成清单。
-2. **逐文件走同一套规则**：形态识别 → 命名规范化（§3.6）→ 压缩（§3.7）→ 校验（§3.8）。
-3. **生成《材料体检报告》**，包含：
-   - 命名违规清单（原文件名 → 规范名）
-   - 证件号异常清单（与名册比对的结果，含裁决结论）
-   - 体积超标清单（压缩前后对比）
-   - 分辨率不足清单
-   - 缺失材料清单（同一人缺了哪几项）
-   - 重复文件清单
-4. **输出规范化后的压缩包**，目录结构可直接上报。
-5. 报告与结果可生成分享链接给班主任。
-
-**特殊能力：散图分拣**
-老师从微信里收到的常常是**一堆没有目录、名字很乱的散图**。整理器需要能：
-- 按证件号/姓名把散图自动归属到人；
-- 无法归属的单独列出，供人工拖拽归位；
-- 归位后按材料类型自动分入对应目录。
-
-**异常分支**
-
-| 情况 | 处理 |
-|---|---|
-| 压缩包内有嵌套压缩包 | 提示是否一并展开处理 |
-| 存在无法识别的文件（如 `IMG_001.jpg`） | 归入"待人工归属"，不猜测、不放任 |
-| 名册缺失（没有 Excel） | 允许无名册运行：仅做命名规范与压缩，不做一致性校验，报告中说明该限制 |
+> ⚠️ **整节作废**：历史整理器（含"散图分拣"与《材料体检报告》）连模块、表、接口、权限码、
+> PC 页面与原型屏一并删除，**不再排期**。
+>
+> 它当年复用的是同一套规则（形态识别 → 命名规范化 → 压缩 → 校验），这条"规则引擎只有一套"的
+> 设计结论仍然成立，只是**不再有"处理历史乱文件夹"这个入口**。
 
 ---
 
@@ -1214,7 +1181,7 @@
 **准入（门禁）**
 - **两种模式都必须先导名单**，没有名单不能填报
 - 进入填报前必须**填写「姓名 + 身份证号」匹配名单**，不通过只提示、不放行
-- 匹配失败**不区分原因**（防止探测身份证号），只给"重新填写 / 申请加入名单"两个出口
+- 匹配失败**不区分原因**（防止探测身份证号），只给「重新填写」一个出口 + 提示联系老师加人
 - 匹配接口必须**限流**（同 openid 每小时 ≤10 次）
 - 姓名形近字/同音字可纠错，但必须**让用户确认**后才通过
 
@@ -1284,7 +1251,7 @@
 | 17 | 任务截止了但学生要补交 | 学生忘交 | 任务已截止 | 提示"已截止"；管理员可延长截止或点名放行 | 🟡 |
 | 18 | 班主任离职/换人 | 账号停用 | 待办无人处理 | 支持转交；超时自动升级通知管理员 | 🟡 |
 | 19 | 导出时有人材料不全 | 3 人未完成 | 前置检查不通过 | 🔴 报错并列出名单，提供"仅导出已通过者" | 🟡 |
-| 20 | 老师手里已有 475MB 的乱文件夹 | 每班 112 个文件 | 走整理器路径 | 输出体检报告 + 规范包 | ✅（内容核对） |
+| ~~20~~ | ~~老师手里已有 475MB 的乱文件夹~~ | — | ~~走整理器路径~~ | **已取消**（2026-10：整理器模块删除） | — |
 | 21 | 学生从**聊天记录**选了照相馆发来的照片 | 文件带原始名 `张三-...-一寸照片.jpg` | 文件名可读 → 直接提取姓名/证件号/材料名 | ✅ 一次通过；文案"已按文件名自动识别" | ❌ 自动 |
 | 22 | 学生从**相册**选了截图 | 文件名为 `IMG_4821.PNG`，1025×590 | 无文件名信息 → 走 OCR + 人工确认归属 | 🟡"这张图没有名字信息，已识别为学籍表，请确认" | 🟡 确认 |
 | 23 | 学生从聊天记录收到的是被微信压缩过的图 | 分辨率明显偏低 | 低于建议值 | 🟡"这张图可能被压缩过，建议让对方发原图" | 🟡 确认 |
@@ -1294,7 +1261,7 @@
 | 27 | 同一个名单项被两个人绑定 | 冒用 / 代填冲突 | 已被绑定 | 🔴"该信息已被登记，如有疑问请联系老师" | 🟡 |
 | 28 | 老师忘了导入名单就想发布任务 | 操作遗漏 | 发布前校验不通过 | 🔴"请先导入名单，名单必须包含姓名和身份证号" | ❌ 阻断发布 |
 | 29 | 学生把学籍表传到了"身份证"槽位 | 槽位与内容冲突 | 规则层识别出关键词"学籍"，置信度 0.93 | 🟡"这张看起来是**学籍表**，不是身份证。要移过去吗？"[一键移动] | 🟡 用户确认 |
-| 30 | 学生传了一堆散图，没归类 | 微信收到的图片 | 整理器无槽位 → 按证件号归属到人 + 按内容判定材料类型 | 自动归入目录；判不出的进"待人工归属" | 🟡 部分人工 |
+| ~~30~~ | ~~学生传了一堆散图，没归类~~ | — | ~~整理器无槽位 → 自动归属~~ | **已取消**（2026-10） | — |
 | 31 | 学生传了一张纯色背景的图 | 一寸照片（无文字） | 形态规则：5:7 比例 + 背景纯净 → 置信度 0.88 | 🟡"请确认这张是一寸照片" | 🟡 确认 |
 | 32 | 学生把正确材料放在正确位置，但因图糊识别失败 | 槽位与内容无法比对 | 置信度 <0.4 → **不判断** | ✅ 直接放行（**不因识别失败而打扰用户**） | ❌ 系统静默放行 |
 
@@ -1323,7 +1290,7 @@
 | **材料从哪来** | — | "这份材料一般在**微信聊天记录**里：照相馆/打印店发给你之后，从这里选，系统能自动帮你填好信息" |
 | **相册图片无名字** | 无法解析文件名 | "这张图没有名字信息，系统已识别为学籍表。请确认是不是这一份" |
 | **聊天图片被压缩过** | 图片分辨率偏低 | "这张图好像被微信压缩过，有点糊。可以让对方发一张原图，或者点开图片后选『原图』再保存" |
-| **门禁：匹配失败** | 未找到该身份证号 / 姓名不匹配 | "**没有找到你的信息。**请核对姓名和身份证号是否与老师提供的名单一致。如果确实已报名，可以申请加入名单，由老师审核" |
+| **门禁：匹配失败** | 未找到该身份证号 / 姓名不匹配 | "**没有找到你的信息。**请核对姓名和身份证号是否与老师提供的名单一致。如确认已报名，请联系老师把你加入名单" |
 | **门禁：姓名疑似写错** | 身份证对、姓名形近 | "你是不是 **杨晨**？（老师名单上写的是这个名字）" |
 | **门禁：已被绑定** | 名单项已绑他人 | "该信息已被登记，如有疑问请联系老师" |
 | **门禁：限流** | 尝试过于频繁 | "操作过于频繁，请稍后再试" |
@@ -1358,9 +1325,9 @@
 | 8 | 导出包默认保留 7 天是否够用 | 低 | 客户 |
 | 9 | **各来源通道的实际体积上限需实测**（微信聊天记录选文件、相册、文件选择三条通道各自能传多大的文件），并据此设计超限提示与降级路径 | 中 | 研发 |
 | 10 | **微信相册/相机权限的隐私声明**需在小程序后台同步更新（当前声明需覆盖"从相册选择"） | 中 | 研发 + 法务 |
-| **11** | **名单外的人怎么处理？** 当前按需求实现为"不给填、只提示"，需老师去后台加人。建议增加"申请加入名单 → 管理员审批后自动放行"通道，**请确认是否采纳** | **高** | 客户 |
+| ~~11~~ | ~~名单外的人怎么处理？建议增加"申请加入名单 → 管理员审批后自动放行"通道~~ → **已决策（2026-10）：不做自助通道，由老师手工加人** | — | 已关闭 |
 | 12 | **门禁限流阈值**（同 openid 每小时 10 次）是否合适，需按实际人数与使用习惯标定 | 中 | 研发 |
-| 13 | 社会收集的名单从哪来（预报名名单 / 报名点收集 / 机构导出）？若来源不稳定，"先导名单"的落地难度较大 | 中 | 客户 |
+| ~~13~~ | ~~社会收集的名单从哪来~~ → **已关闭**（2026-10 取消社会收集） | — | 已关闭 |
 | 14 | 门禁核验是否还要加**手机号验证码**（防止他人拿到姓名+身份证号后代填） | 中 | 客户 |
 | **15** | **材料识别的 VLM 选型与单价**（用于成本核算与供应商比价）；触发率 15% 为预估值，需用真实数据实测标定 | 中 | 研发 + 商务 |
 | 16 | 关键词表由谁维护（平台预置 + 租户自维护）；是否需要"从历史文件自动学习关键词"功能 | 中 | 产品 |