文档需求：对齐一期范围与甲方待确认事项

2026-09-16 14:30:41 +08:00
1 parent a429ac9632
commit b835848719
@@ -0,0 +1,226 @@
+# SYFJGYD学员管理系统
+# 一期需求实现进度表
+
+> **系统对外正式名称**：SYFJGYD学员管理系统
+> **内部工程代码代号**：RailwaySystem
+> **文档性质**：需求梳理与实现进度基线文档（DOCUMENTATION / REQUIREMENT ALIGNMENT ONLY）
+> **生产发布分支基线**：`feat/cicd-pipeline`（Commit SHA: `08419b635bafb872ab8e150b086fa2a894272e1b`，已集成 R.2 三角色 RBAC 发版，对应当前正式生产 Release）
+> **研发特性分支说明**：R.3 DMS 智能门禁适配代码处于独立研发分支 `feature/dms-r3`（Commit SHA: `a2b7c2c04b82c8eee8e1b135a5cbc98a090a756f`），已完成 Wave 0 ~ Wave 3B，并已完成 Pre-Release QA，尚未合并至生产发布分支
+> **更新时间**：2026-09-16
+
+---
+
+## 一、概述与整体判定
+
+### 1.1 文档目的
+本文档基于当前 RailwaySystem 代码仓库的真实实现、已完成的自动化测试与浏览器验收证据、国产人大金仓（KingbaseES）数据库物理结构，以及项目第一至第三次内部/外部会议结论，对“SYFJGYD学员管理系统”一期的需求实现进度进行全方位事实校准与盘点。
+
+本文档的核心目标包括：
+1. **统一团队内部认知**：客观、真实地反映一期各模块的实际代码与页面就绪度，不虚报、不浮夸，严格区分已发布生产能力与独立研发分支能力；
+2. **支撑下阶段甲方确认**：为与指导教师/沈阳房建公寓段业务负责人的下一轮需求确认提供准确、经得起代码核验的事实依据；
+3. **现场验收范围冻结**：作为后续现场部署、功能演示与一期验收的范围基线；
+4. **防止需求边界漂移**：严格区分“已冻结的正式需求”、“已实现的核心功能”、“技术就绪但待确认业务口径的事项”与“会议发散性讨论候选需求”，坚决防止将非正式讨论项误当成一期承诺。
+
+### 1.2 统计口径与发布边界（Release Boundary）
+为确保所有结论具备事实可查性，本次梳理严格遵循以下证据优先级与版本边界界定：
+
+* **当前正式生产 Release 边界**：当前正式生产 Release（Commit SHA: `08419b635bafb872ab8e150b086fa2a894272e1b`，基于生产发布分支 `feat/cicd-pipeline`）**尚未包含 R.3 DMS 业务代码**。因此，凡涉及 DMS 业务编排、门禁适配器、Token 管理与 Mock 验证的内容，一律明确标注为 `FEATURE_BRANCH_VERIFIED`（独立研发分支已验证）以及 `NOT_YET_RELEASED_TO_PRODUCTION`（尚未并入当前生产发布分支），严禁误报为“当前生产系统已上线”。
+* **Tier 1（开发基线）**：`doc/RailwaySystem 智慧培训系统一期 PRD V1.0.md`，一期内部开发正式基线。
+* **Tier 2（会议依据）**：第二次项目会议结论、第三次内部会议记录。用于解释业务背景、修正理解偏差。**明确铁律：会议中的探讨与设想 ≠ 自动冻结为一期正式需求**。
+* **Tier 3（客观事实）**：当前正式代码库、KingbaseES 物理表结构、当前正式生产 Release、端到端 E2E 证据包（`RBAC_E2E_R2_20260916_102500`、`DEMO_E2E_20260915_122800`）、DMS R.3 设计与 QA 验证资产。用于判定功能是否真实代码实现与测试通过。严禁仅凭 API Contract 设计文档作为“代码已实现”的依据。
+* **Tier 4（参考资产）**：早期历史说明书、旧版 HTML 原型与旧数据库设计，仅供溯源参考。
+
+### 1.3 状态分类定义（Requirement Classification Model）
+本文档对所有需求项严格执行以下 8 种标准化状态，杜绝使用“基本完成”、“大概支持”等模糊描述：
+
+| 状态代码 | 状态名称 | 严格判定标准 |
+| :--- | :--- | :--- |
+| **`DONE_VERIFIED`** | 已完成并验证 | 已经具备完整的前后端代码/页面/API，并通过了自动化测试、浏览器端到端或物理数据库落库验证。（若仅在独立特性分支完成，需显式附加分支状态说明）。 |
+| **`DONE_NEEDS_BUSINESS_CONFIRMATION`** | 技术就绪待业务确认 | 技术架构与功能页面已实现，但具体业务判定口径（如请假撤权规则、过渡期策略等）仍需甲方确认签字。 |
+| **`INTEGRATION_READY`** | 接口就绪待外部联调 | 本地业务逻辑、Adapter 适配层与 Mock 机制已完成并验证，等待对接真实第三方生产/测试环境。 |
+| **`IN_PROGRESS`** | 开发进行中 | 属于一期规划范围，当前已有部分代码或模型，但核心业务逻辑/聚合计算仍在开发完善中。 |
+| **`WAITING_FOR_EXTERNAL_INPUT`** | 阻塞待外部输入 | 属于一期确定目标，但必须等待甲方或第三方厂商提供协议规范、正式账号、物理硬件或测试数据方可推进。 |
+| **`PENDING_CUSTOMER_CONFIRMATION`** | 会议提出待甲方确认 | 会议中曾提出或讨论过，但尚未由甲方正式决策是否纳入一期范围的候选需求。严格禁止盲目开发。 |
+| **`FUTURE_PHASE`** | 明确归入后续阶段 | 明确不属于当前一期范围，或建议作为二期、未来长期规划的内容。 |
+| **`NOT_SUPPORTED_BY_SOURCE`** | 材料不足无法判定 | 仅在设计文档中有构想，当前正式代码库无实际 Controller/Service 实现，无代码支撑。 |
+
+### 1.4 一期核心业务闭环完成情况整体判定
+当前系统在当前正式生产 Release 上已成功实现了短周期铁路培训的核心教务正向业务全闭环：
+> **基础资源就绪 → 开班计划制定 → 本期课程绑定 → 参训学员名册 → 智能冲突排课 → 现场报到核验 → 课堂考勤打卡 → 结训状态流转 → 历史数据沉淀**
+
+* **核心教务管理主链**：已具备完全真实的后端 Service/Controller、前端交互与完整自动化场景测试（SC-01 ~ SC-06 全部通过）；
+* **三角色权限隔离**：已完整落地管理员（Admin）、教师（Teacher）、学员（Student）三角色认证与工作台数据隔离，并通过防横向越权（IDOR）严格验证；
+* **国产数据库适配**：全量 21 张核心业务表完成国产人大金仓（KingbaseES V9）物理对齐与序列自增补丁适配；
+* **学情与分析模块现状**：Legacy Analytics 已对齐 V2 基础读模型，但综合成绩加权计算、动态画像刷新引擎等高级业务能力尚处于开发完善中（PARTIAL / IN_PROGRESS），不虚报为完全就绪；
+* **智能门禁准备度**：独立研发分支 `feature/dms-r3` 已完成适配器、Token 防击穿与 Mock 验证，生产发布分支尚未合并发布，待正式物理沙箱交接后统筹推进。
+
+---
+
+## 二、一期需求实现全景矩阵
+
+### 域 A：基础资源管理（6 项）
+
+| 编号 | 业务域 | PRD/需求项 | 当前系统实现 | 状态 | 证据 | 是否需甲方确认 | 下一步 |
+| :---: | :--- | :--- | :--- | :---: | :--- | :---: | :--- |
+| A-01 | 基础资源 | 教师档案管理 | 支持教师工号、姓名、联系电话、专业领域、状态启停用及详情查看，支持关键词检索与多条件过滤。 | `DONE_VERIFIED` | `TrainTeacherController.java`<br>`build_ui/src/views/train/teacher/index.vue`<br>E2E 模块 1 验证通过 | 否 | 建议冻结一期功能 |
+| A-02 | 基础资源 | 学员档案管理与敏感信息脱敏 | 支持学员档案管理，录入身份证时后端自动可逆加密存盘并建立哈希索引，前端强制脱敏（显后4位）；支持单条维护，以及通过参训名单批量导入机制辅助建档。 | `DONE_VERIFIED` | `TrainStudentController.java`<br>`build_ui/src/views/train/student/index.vue`<br>Kingbase 物理落库断言通过（SC-01/SC-02） | 是（需确认最终导入字段口径） | 建议冻结本地主档能力，等待甲方提供名册清单格式 |
+| A-03 | 基础资源 | 课程库管理 | 支持独立课程目录维护，支持配置课程编码、名称、学时、学分、课程类别等属性，具备严格防重编码校验。 | `DONE_VERIFIED` | `TrainCourseController.java`<br>`build_ui/src/views/train/course/index.vue`<br>E2E 模块 3 验证通过 | 否 | 建议冻结一期功能 |
+| A-04 | 基础资源 | 理论教室空间管理 | 支持教学楼栋、教室编号、容纳人数、启用状态维护，并支持多电子班牌的绑定与状态反查。 | `DONE_VERIFIED` | `TrainClassroomInfoController.java`<br>`build_ui/src/views/train/classroom/index.vue`<br>E2E SC-04 验证通过 | 否 | 建议冻结一期功能 |
+| A-05 | 基础资源 | 实训场地空间管理 | 支持 VR 室、3D 演练区、实操场地等专项区域登记，维护场地容纳人数与可用状态，在排课中与普通教室互斥。 | `DONE_VERIFIED` | `TrainTrainingSiteController.java`<br>`build_ui/src/views/train/site/index.vue`<br>E2E 验证通过 | 否 | 建议冻结一期功能 |
+| A-06 | 基础资源 | 公寓宿舍房源与床位管理 | 支持公寓楼栋、楼层、房间号、床位总数、适用性别、房间状态台账维护，支持查看当前房间容量。 | `DONE_VERIFIED` | `TrainDormitoryInfoController.java`<br>`build_ui/src/views/train/dormitory/index.vue`<br>Kingbase `train_dormitory_info` | 是（需确认分配精度是到房间还是具体床位号） | 等待甲方确认床位分配精度要求 |
+
+---
+
+### 域 B：培训业务管理（10 项）
+
+| 编号 | 业务域 | PRD/需求项 | 当前系统实现 | 状态 | 证据 | 是否需甲方确认 | 下一步 |
+| :---: | :--- | :--- | :--- | :---: | :--- | :---: | :--- |
+| B-01 | 培训业务 | 开班计划制定与流转 | 支持拟定开班计划、配置培训周期、招生规模限制，维护计划从草稿、进行中到已结束的完整生命周期。 | `DONE_VERIFIED` | `TrainPlanController.java`<br>`build_ui/src/views/train/plan/index.vue`<br>E2E SC-01/SC-05 闭环验证通过 | 否 | 建议冻结计划管理功能 |
+| B-02 | 培训业务 | 本期课程配置（一班多课） | 支持为一个开班计划动态配置多门课程，设定各项要求学时与考核方式，彻底消除单班单课限制。 | `DONE_VERIFIED` | `TrainPlanCourseController.java`<br>`build_ui/src/views/train/plan/components/TimetablePanel.vue`<br>E2E SC-01 验证通过 | 否 | 建议冻结一班多课模型 |
+| B-03 | 培训业务 | 参训学员名册管理 | 支持参训学员名册绑定，实现同一计划防重复报名拦截（40030）、超过计划容量硬阻断（40031）、停用学员入班拦截；具备参训名单批量导入能力。 | `DONE_VERIFIED` | `TrainEnrollmentController.java`<br>`build_ui/src/views/train/plan/components/EnrollmentPanel.vue`<br>E2E SC-02 验证通过 | 是（确认一期参训名单来源方式） | 等待甲方确认名册导入流程 |
+| B-04 | 培训业务 | 课次与教学日程编排 | 支持在培训周期内编排具体课次（Lesson），关联本期课程、主讲教师、起止时间段及场地空间。 | `DONE_VERIFIED` | `TrainLessonController.java`<br>`build_ui/src/views/train/plan/components/TimetablePanel.vue`<br>E2E SC-01 验证通过 | 否 | 建议冻结课次编排能力 |
+| B-05 | 培训业务 | 教师排课与课表关联 | 课次编排时指定授课教师，支持教师课表聚合查询与教师自服务工作台专属授课日程过滤。 | `DONE_VERIFIED` | `TrainLessonController.java`<br>`TrainTeacherMeController.java`<br>E2E 模块 1 验证通过 | 否 | 建议冻结教师排课功能 |
+| B-06 | 培训业务 | 场地空间二选一互斥选择 | 课次支持绑定理论教室或实训场地，强制执行教室与场地二选一严格互斥（XOR）校验，禁止双选或漏选。 | `DONE_VERIFIED` | `TrainLessonServiceImpl.java` 互斥校验<br>E2E SC-03 验证通过 | 否 | 建议冻结场地互斥逻辑 |
+| B-07 | 培训业务 | 排课四维智能冲突检测 | 排课时失焦自动预检教师时间冲突、教室占用冲突、实训场地占用冲突及同班时间重叠；冲突时弹出 Warning 预警，支持教务核验后二次确认保存，严禁非法 force 参数。 | `DONE_VERIFIED` | 后端 `/train/lessons/check-conflict`<br>前端 `TimetablePanel.vue` 预警弹窗<br>E2E SC-03 验证通过 | 否 | 建议冻结软冲突预检与保存机制 |
+| B-08 | 培训业务 | 课程表多维聚合展示 | 支持班级总课程表导出与查看，支持教师个人课表及学员个人课表专属聚合视图。 | `DONE_VERIFIED` | 后端 `/train/plans/{id}/timetable`<br>前端自服务专属课表页 | 否 | 建议冻结课程表聚合能力 |
+| B-09 | 培训业务 | 现场报到确认与核销 | 现场报到核验支持记录核验方式（人脸、刷卡、扫码、人工），成功后事务性联动参训状态流转为“1:已报到”并记入时间，重复报到自动拦截（40050）。 | `DONE_VERIFIED` | `TrainReportActionController.java`<br>`build_ui/src/views/train/report/index.vue`<br>E2E SC-06 验证通过 | 是（确认一期现场采用人工电脑核验还是外接设备） | 等待甲方确认报到硬件配置 |
+| B-10 | 培训业务 | 强事务一键结训联动 | 计划结训操作将开班状态置为“2:已结束”，事务联动将班内所有正常在读学员（状态0/1）批量流转为“4:已完成”并写入结训时间，历史退训学员（状态3）保持不变。 | `DONE_VERIFIED` | `TrainPlanServiceImpl.completePlan()`<br>E2E SC-05 断言通过 | 是（确认结训与合格/发证是否拆分） | 等待甲方确认结训与结业评定口径 |
+
+---
+
+### 域 C：学习与考勤管理（8 项）
+
+| 编号 | 业务域 | PRD/需求项 | 当前系统实现 | 状态 | 证据 | 是否需甲方确认 | 下一步 |
+| :---: | :--- | :--- | :--- | :---: | :--- | :---: | :--- |
+| C-01 | 学习管理 | 课堂签到与签退打卡 | 支持针对具体课次的打卡流水记录，支持记录签到/签退时间，初次打卡时间幂等保护防篡改。 | `DONE_VERIFIED` | `AttendanceController.java`<br>`build_ui/src/views/train/checkin/index.vue`<br>E2E SC-06 验证通过 | 否 | 建议冻结打卡基础接口 |
+| C-02 | 学习管理 | 考勤状态与人工修正 | 考勤状态收敛为：0缺勤、1正常、2迟到、3早退、4请假；教师或管理员代签/调整时自动置位 `manual_flag=1`，保留完整审计痕迹。 | `DONE_VERIFIED` | `AttendanceController.java`<br>前端考勤调整弹窗<br>E2E SC-06 验证通过 | 是（需确认迟到/早退判定时间阈值） | 等待甲方明确迟到/早退判定规则 |
+| C-03 | 学习管理 | 成绩项目管理与成绩录入 | 当前正式代码库仅保留旧版单表成绩查询；PRD V1.0 规划的多课程考核项目（Score Items）、权重分配与综合成绩加权核算在后端与业务层尚处于开发阶段，未形成完整业务闭环。 | `IN_PROGRESS` | 旧表 `train_score_info` 已淘汰，新业务表已就绪；缺少对应应用服务与综合成绩计算业务逻辑 | 是（需确认成绩评定及格线与各项目权重） | 完善 Score-Items 与综合成绩计算业务服务 |
+| C-04 | 学习管理 | 自主学习时长台账记录 | 当前系统实现了学习时长只读台账与列表查询（对齐 V2 数据模型），但外部学习事件自动接收写入、内容关联核算等业务逻辑尚未完成，目前仅具备只读展示能力。 | `IN_PROGRESS` | `TrainStudyDurationController.java`<br>`build_ui/src/views/train/duration/index.vue`<br>`docs/_meta/legacy-analytics-v2-audit.md` 确认只读对齐 | 是（确认一期时长是由人工录入还是系统回传） | 完善学习时长业务写入流 |
+| C-05 | 学习管理 | 学员综合画像展示 | 当前具备静态画像雷达图前端页面与只读模型，但基于考勤合格率、考试成绩和实训时长的动态画像生成/刷新计算引擎（`portrait generate/refresh`）在代码中尚未实现。 | `IN_PROGRESS` | 前端 `portrait/index.vue`、`character/charts.vue`<br>后端缺乏动态生成服务与定时计算逻辑 | 是（需确认评价维度与标签定义；属于 DELIVERY / DEMO DATA 任务） | 补齐动态画像计算服务，灌装演示数据验证 |
+| C-06 | 学习管理 | 培训统计报表看板 | 当前系统具备前端统计看板页面和部分基础指标查询，但综合学情跨表高级聚合统计接口尚未完全对齐，整体处于部分完成（PARTIAL）状态。 | `IN_PROGRESS` | 前端 `analysis/timeAndAddress.vue`<br>`docs/_meta/legacy-analytics-v2-audit.md`<br>截图 `19-report-analytics.png` | 是（需确认管理层重点关注的报表格式；属于 DELIVERY / DEMO DATA 任务） | 补齐聚合统计服务，灌装演示数据 |
+| C-07 | 学习管理 | 外部 VR/3D 学习系统接入 | 仅在 API 契约设计文档中有接口设想，当前正式代码库中不存在外部学习数据接收（external study receive）的 Controller 与 Service 实现，暂无代码支撑。 | `NOT_SUPPORTED_BY_SOURCE` | PRD V1.0 规划项，当前正式代码库无相关业务实现 | 是（确认一期是否要求对接真实 VR 系统） | 等待甲方明确是否有对接要求，未确认前不开发 |
+| C-08 | 学习管理 | 外部考试系统成绩自动同步 | 仅在 API 契约文档中有规划，当前正式代码库中未实现外部考试系统数据同步（external score receive/import）的接收接口与服务，暂无代码支撑。 | `NOT_SUPPORTED_BY_SOURCE` | 当前仅有系统内手动录入设想，无外部回传代码 | 是（确认是否有外部考试平台对接需求） | 等待甲方确认外部考试系统现状 |
+
+---
+
+### 域 D：住宿与智能门禁管理（10 项）
+> ⚠️ **发布边界特别说明**：当前正式生产 Release（生产发布分支 `feat/cicd-pipeline`）尚未合入 R.3 业务代码。D-01 ~ D-09 的实现与自动化测试均在独立研发分支 `feature/dms-r3` 上验证通过（**`FEATURE_BRANCH_VERIFIED / NOT_YET_RELEASED_TO_PRODUCTION`**），待后续发版窗口统一合并。
+
+| 编号 | 业务域 | PRD/需求项 | 当前系统实现 | 状态 | 证据 | 是否需甲方确认 | 下一步 |
+| :---: | :--- | :--- | :--- | :---: | :--- | :---: | :--- |
+| D-01 | 住宿门禁 | 本地宿舍预分配与状态流转 | 支持为参训学员预分配公寓房间，支持不住宿标记，维护预分配、已入住、已退宿状态，校验房间容纳上限。<br>*(注：独立研发分支已验证，尚未合并至生产发布分支)* | `DONE_VERIFIED` | 独立分支 `fb959cfe` 对齐通过<br>`FEATURE_BRANCH_VERIFIED`<br>`NOT_YET_RELEASED_TO_PRODUCTION` | 是（确认分配精度到房间还是床位） | 建议冻结本地住宿核心业务模型，等待合并窗口 |
+| D-02 | 住宿门禁 | 调房换宿与退宿业务 | 支持学员中途换房操作，老住宿记录置为已调离并保留历史审计流水；支持学员结训退宿处理。<br>*(注：独立研发分支已验证，尚未合并至生产发布分支)* | `DONE_VERIFIED` | 独立分支 `TrainAccommodationServiceImpl.java`<br>`FEATURE_BRANCH_VERIFIED`<br>`NOT_YET_RELEASED_TO_PRODUCTION` | 否 | 建议冻结本地调房与退宿逻辑 |
+| D-03 | 住宿门禁 | 厂商中立门禁授权生命周期模型 | 建立标准领域授权状态机（PENDING_GRANT -> GRANTING -> ACTIVE -> REVOKED / ERROR），解耦具体门锁硬件协议。<br>*(注：独立研发分支已验证，尚未合并至生产发布分支)* | `DONE_VERIFIED` | `docs/development/dms-r3/06_authorization_state_machine.md`<br>`FEATURE_BRANCH_VERIFIED`<br>`NOT_YET_RELEASED_TO_PRODUCTION` | 否 | 建议冻结厂商中立领域模型 |
+| D-04 | 住宿门禁 | 外部空间与门锁映射表维护 | 实现了本地房间与 DMS 空间（Building, Floor, Room）及设备（DoorLock）的双向映射持久化表（`train_external_resource_mapping`），支持单主锁拓扑。<br>*(注：独立研发分支已验证，尚未合并至生产发布分支)* | `DONE_VERIFIED` | 独立分支 `22bcd1ba` 落地映射表<br>`FEATURE_BRANCH_VERIFIED`<br>`NOT_YET_RELEASED_TO_PRODUCTION` | 是（需确认实际宿舍门锁拓扑与主锁规划） | 等待甲方提供门锁点位与房间对应清单 |
+| D-05 | 住宿门禁 | 外部异步操作流水表与防篡改 | 实现 `train_external_operation` 异步流水表，记录每次 DMS 请求的 operationId、重试次数、执行状态与错误分类，保障全链路审计。<br>*(注：独立研发分支已验证，尚未合并至生产发布分支)* | `DONE_VERIFIED` | 独立分支持久化层代码<br>`FEATURE_BRANCH_VERIFIED`<br>`NOT_YET_RELEASED_TO_PRODUCTION` | 否 | 建议冻结异步操作审计机制 |
+| D-06 | 住宿门禁 | DMS Token 安全管理器 | 实现统一 `DmsHttpClient` 与 `TokenManager`，参数化 Cookie 头，双重检查锁（DCL）高并发单飞防击穿，提前 120 秒平滑刷新，全局日志脱敏。<br>*(注：独立研发分支已验证，尚未合并至生产发布分支)* | `DONE_VERIFIED` | 独立分支 `e608c79f` 落地适配器<br>`FEATURE_BRANCH_VERIFIED`<br>`NOT_YET_RELEASED_TO_PRODUCTION` | 是（需厂家书面确认 Cookie 头 Key 名称） | 等待第三方厂家技术人员核实 Cookie 头 |
+| D-07 | 住宿门禁 | 在线限时密码适配与下发注销 | 实现 4~8 位数字限时密码创建与注销适配逻辑，采用强随机生成，全链路零落库、零明文打印、零异常栈泄露；注销返回 operationId。<br>*(注：独立研发分支已验证，尚未合并至生产发布分支)* | `DONE_VERIFIED` | 独立分支 `DmsPasswordClient.java`<br>`FEATURE_BRANCH_VERIFIED`<br>`NOT_YET_RELEASED_TO_PRODUCTION` | 是（确认学员端查看/获取开门密码的业务渠道） | 等待甲方确定密码交付方式 |
+| D-08 | 住宿门禁 | 门禁业务编排与状态驱动对账 | 实现 `AccessAuthorizationOrchestrator.reconcile()` 驱动机制；报到成功触发异步授权；调房执行“先下发新宿舍门禁，成功后再注销旧宿舍”；请假保持现状不自动撤权。<br>*(注：独立研发分支已验证，尚未合并至生产发布分支)* | `DONE_NEEDS_BUSINESS_CONFIRMATION` | 独立分支 `fc4898ca` 编排落地<br>`FEATURE_BRANCH_VERIFIED`<br>`NOT_YET_RELEASED_TO_PRODUCTION` | 是（需公寓方确认请假撤权规则与调房过渡期） | 提交公寓管理方书面确认业务规则 |
+| D-09 | 住宿门禁 | DMS 异步轮询器与 Mock E2E 验证 | 实现轻量原生 `MockDmsServer`，全覆盖模拟 DMS 鉴权、多锁与异步延迟流转；配合 `DmsOperationPoller` 实现 10 秒指数退避轮询与终态闭环。<br>*(注：独立研发分支已验证，尚未合并至生产发布分支)* | `DONE_VERIFIED` | 独立分支 `3001b5d1` Mock E2E 通过<br>`FEATURE_BRANCH_VERIFIED`<br>`NOT_YET_RELEASED_TO_PRODUCTION` | 否 | 建议冻结本地 Mock 与 Poller 机制 |
+| D-10 | 住宿门禁 | 真实 DMS 外部平台端到端联调 | 团队成员已有第三方接口测试经验，曾拿到测试账号并实际成功获取 Token，具备进一步测试基础；本地代码具备完整 Adapter/Mock/QA 基础。但系统全生命周期尚未对公网真实 DMS 发起过连通联调。 | `INTEGRATION_READY` | 本地 Mock 100% 通过<br>真实调用计数 `LIVE_DMS_REQUEST_COUNT = 0` | 是（必须等待甲方/厂家提供专属测试环境与实验台锁具） | 协调专属测试沙箱环境，进行端到端真机验收 |
+
+---
+
+### 域 E：权限管控与系统安全（10 项）
+
+| 编号 | 业务域 | PRD/需求项 | 当前系统实现 | 状态 | 证据 | 是否需甲方确认 | 下一步 |
+| :---: | :--- | :--- | :--- | :---: | :--- | :---: | :--- |
+| E-01 | 权限安全 | 管理员/教师/学员三角色登录认证 | 复用底层安全认证体系，支持 Admin、Teacher、Student 三角色登录，成功颁发 JWT Token，拦截非法密码与验证码错误。 | `DONE_VERIFIED` | `docs/reports/e2e-r2/RBAC_E2E_R2_20260916_102500/report.md`<br>阶段 4 断言全部通过 | 否 | 建议冻结三角色登录基座 |
+| E-02 | 权限安全 | 管理员统一建号与角色授权流程 | 管理员在后台统一创建新系统账号，分配合规角色（教师或学员），支持重置密码与账号启停用。 | `DONE_VERIFIED` | E2E 阶段 2 断言通过<br>成功创建 7 个独立测试账号并分配合规角色 | 否 | 建议冻结管理员建号流 |
+| E-03 | 权限安全 | 教师主档与系统账号唯一绑定 | 支持将 `sys_user` 与 `train_teacher` 档案唯一绑定；具备严格互斥（Teacher XOR Student），防静默覆盖；支持安全解绑（不删除用户主体）。 | `DONE_VERIFIED` | 提交 `f8b998cc` 落地绑定流<br>E2E 阶段 3 断言通过 | 否 | 建议冻结教师账号绑定流程 |
+| E-04 | 权限安全 | 学员主档与系统账号唯一绑定 | 支持将 `sys_user` 与 `train_student` 档案唯一绑定；防静默覆盖保护；角色错配拒止；支持安全解绑。 | `DONE_VERIFIED` | `TrainAccountBindingAdminController.java`<br>前端绑定弹窗<br>E2E 阶段 3 断言通过 | 否 | 建议冻结学员账号绑定流程 |
+| E-05 | 权限安全 | 教师自服务与数据范围隔离 | 教师登录后动态加载专属自服务工作台，仅可见本人负责的培训班与课次；跨班名册查看、跨课次打卡被系统级 403 拦截，屏蔽管理端与全局主档菜单。 | `DONE_VERIFIED` | `TrainTeacherMeController.java`<br>`build_ui/src/views/train/me/teacher/index.vue`<br>E2E 阶段 5 断言通过 | 否 | 建议冻结教师自服务数据隔离 |
+| E-06 | 权限安全 | 学员自服务与数据范围隔离 | 学员登录后仅展示个人工作台，仅可见本人参训、课表日程、报到凭证、宿舍床位、成绩与画像；跨人凭证调阅被严格拦截（HTTP 200 / code 403）。 | `DONE_VERIFIED` | `TrainStudentMeController.java`<br>`build_ui/src/views/train/me/student/index.vue`<br>E2E 阶段 6 断言通过 | 否 | 建议冻结学员自服务数据隔离 |
+| E-07 | 权限安全 | 横向越权（IDOR）防御与安全边界 | 系统建立严密的数据权限与业务主体验证边界，教师与学员尝试越权调用管理端 API 或篡改参数访问他人主体均被强阻断并留痕。 | `DONE_VERIFIED` | `docs/reports/e2e-r2/RBAC_E2E_R2_20260916_102500/idor-results.md`<br>42 项探测用例 100% 通过 | 否 | 建议冻结安全权限边界 |
+| E-08 | 权限安全 | 公开自主注册策略（默认关闭） | 登录界面明确隐藏并关闭注册入口（`register: false`），后端注册服务不向普通用户开放，培训账号一律由管理人员后台开通。 | `DONE_VERIFIED` | `build_ui/src/views/login.vue:93`<br>R.2 验收报告一致确认 | 是（需甲方确认正式环境是否保持关闭公开注册） | 建议冻结关闭公开注册策略，待甲方签字确认 |
+| E-09 | 权限安全 | 操作审计流水与耗时监控 | 全量拦截并记录管理端关键业务操作（增删改及状态流转），记录操作人、IP、模块、请求参数、状态及耗时（`cost_time`）。 | `DONE_VERIFIED` | `001_sys_oper_log_cost_time.sql`<br>E2E 阶段 12 审计落库验证通过 | 否 | 建议冻结操作日志审计功能 |
+| E-10 | 权限安全 | 复合角色与无档案身份兜底 | 支持管理员兼任教师的复合主体登录，默认进入管理驾驶舱并支持双向切换；对于分配角色但未绑定业务档案的账号，给出受控友好的“未绑定档案”提示，杜绝白屏崩溃。 | `DONE_VERIFIED` | E2E 阶段 7 断言通过 | 否 | 建议冻结复合主体交互逻辑 |
+
+---
+
+### 域 F：外部集成与候选扩展（9 项）
+
+| 编号 | 业务域 | PRD/需求项 | 当前系统实现 | 状态 | 证据 | 是否需甲方确认 | 下一步 |
+| :---: | :--- | :--- | :--- | :---: | :--- | :---: | :--- |
+| F-01 | 外部集成 | 电子班牌设备集成与课表展示 | 支持教室绑定电子班牌硬件编号，实现班牌拉取今日日程与班级看板大屏，单教室多班牌具备优雅降级逻辑。 | `DONE_VERIFIED` | `TrainElectronicBoardController.java`<br>`build_ui/src/views/train/board/index.vue`<br>E2E SC-04 通过 | 是（需厂家提供班牌物理网络协议） | 获取班牌硬件调试样机并核验通信协议 |
+| F-02 | 外部集成 | 人员主数据外部系统同步 | 系统目前支持管理员录入与参训名单批量导入；第三方 HR/数据平台自动同步中心未开发，系统预留了数据源扩展契约。 | `PENDING_CUSTOMER_CONFIRMATION` | PRD V1.0 第 7.2 节<br>第三次会议讨论项 | 是（PRD V1.0 基线为管理员录入与参训名单批量导入，外部人员同步是否纳入一期需甲方明确决策） | 等待甲方明确是否纳入一期范围，未确认前不开发自动同步模块 |
+| F-03 | 外部集成 | 组织架构外部系统自动同步 | 系统目前使用内置部门管理（`sys_dept`）自建维护局/段/车间/班组，未实现与外部 HR 平台的自动双向同步。 | `PENDING_CUSTOMER_CONFIRMATION` | 第三次会议讨论项<br>PRD V1.0 未列入一期必选 | 是（确认组织架构是由管理员维护还是外部同步） | 等待甲方确认权责，未确认前不开发同步中心 |
+| F-04 | 外部集成 | 单点登录（SSO） | 采用本系统独立的账号密码与验证码登录体系；SSO 对接尚未开发。 | `PENDING_CUSTOMER_CONFIRMATION` | 第三次会议讨论项<br>当前正式策略：沿用本系统登录，不开发 SSO | 是（确认一期是否必须支持 SSO 及具体技术协议） | 等待甲方明确技术标准，未提供前保持冻结不开发 |
+| F-05 | 外部集成 | 现场人脸识别闸机设备对接 | 系统支持记录“人脸”核验标记与人脸特征关联字段，核心业务主链已通，尚未与具体物理人脸闸机 SDK 深度集成。 | `WAITING_FOR_EXTERNAL_INPUT` | PRD V1.0 第 2.4/19.1 节 | 是（需甲方提供人脸识别硬件型号与本地 SDK 协议） | 等待甲方与设备供应商提供硬件协议 |
+| F-06 | 外部集成 | 移动端原生 App / 微信小程序 | 当前系统采用 Web 前端，可通过现代浏览器访问自服务页面；移动端布局与实际操作体验尚需专项移动端验收，未开发独立原生 App 或微信小程序。 | `PENDING_CUSTOMER_CONFIRMATION` | PRD V1.0 架构范围规划 | 是（确认一期是否接受 Web 自服务端访问） | 等待甲方确认终端形态需求 |
+| F-07 | 外部扩展 | 门禁刷卡开门（实体学员卡） | 当前一期未实现；依赖物理发卡机、RFID 芯片卡及线下制卡发卡运营流程；是否纳入后续阶段由甲方确认。 | `FUTURE_PHASE` | DMS 设计 `13_open_questions.md` Q-BLK-02 明确推荐选项 1，实体卡作为二期备选 | 是（建议二期实施） | 建议一期采用在线限时密码，实体卡推迟至二期评估 |
+| F-08 | 外部扩展 | 远程紧急开门与二维码开门 | 当前一期未实现；远程开门涉及高危安防控制与网络延迟风险，二维码依赖专用光学扫码门锁硬件；是否纳入后续阶段由甲方确认。 | `FUTURE_PHASE` | 第三次会议讨论项<br>DMS 架构决策 Q-NON-05 严格排除远程开门 | 是（向甲方说明安防风险，建议二期再议） | 建议明确属于二期候选或不建议上线 |
+| F-09 | 外部扩展 | 手机蓝牙 / NFC 钥匙开门 | 当前一期未实现；依赖特定移动端原生 SDK、系统权限及特定蓝牙芯片门锁；是否纳入后续阶段由甲方确认。 | `FUTURE_PHASE` | 第三次会议讨论项<br>PRD V1.0 未列入一期范围 | 是（建议推迟至二期） | 明确推迟至二期 |
+
+---
+
+## 三、第三次内部会议新增与强化事项专门说明
+
+针对第三次内部会议中提出的新情况与讨论要点，特作如下事实化说明与定性：
+
+### 3.1 DMS 真实接口测试情况说明
+* **客观事实**：在前期调研与预研中，团队已有成员获得过外部测试账号并进行了接口尝试，实际成功完成了 Token 获取，证明该外部平台接口具备进一步对接的技术可行性。
+* **边界界定**：上述事实**绝不代表当前 RailwaySystem 工程已经完成了真实 DMS 的端到端联调**。
+* **当前定性**：在独立研发分支 `feature/dms-r3`（Commit SHA: `a2b7c2c04b82c8eee8e1b135a5cbc98a090a756f`）上，代码层面已经具备了工业级的 Adapter 适配层、高并发 Token 管理器、Mock DMS 模拟器及 Kingbase 物理持久化能力（`INTEGRATION_READY`），且真实调用计数严格保持 `LIVE_DMS_REQUEST_COUNT = 0`。下一阶段需要与沈阳房建公寓段及厂商正式交接公网测试沙箱凭据与实验台硬件，方可展开真实联调。
+
+### 3.2 单点登录（SSO）需求定性
+* **会议背景**：会议中有老师提出，若从铁路局其他内部平台进入本系统，希望能够无需重复输入密码，实现单点免登。
+* **边界界定**：该项在会议中仅属于探讨性质，缺乏正式的统一认证中心技术方案支持。
+* **当前定性**：**`PENDING_CUSTOMER_CONFIRMATION`（会议提出待甲方确认）**。在未经甲方技术部门出具正式架构批复及提供协议文档前，**一期坚决不启动自主编码开发**。已将 SSO 协议类型（OAuth2/OIDC/CAS/JWT）、用户信息映射规则、Token 换取规则及单点登出规范列入《甲方需求确认清单》P0 级问题。
+
+### 3.3 人员与组织架构自动同步定性
+* **会议背景**：会议讨论指出参训人员可能来源于局内部既有系统，组织架构可能无需在本地重复维护。
+* **边界界定**：PRD V1.0 基线明确界定一期以“管理员后台录入与参训名单批量导入”为主。
+* **当前定性**：**`PENDING_CUSTOMER_CONFIRMATION`**。系统已具备高内聚的学员管理与名册管理能力，不能默认必须开发复杂的外部 HR 同步中心，需等待甲方明确数据权威归属与是否纳入一期建设。
+
+### 3.4 演示数据与统计展示任务定性（Demo Data Task）
+* **会议背景**：会议反馈，在空数据或仅有少量基础数据时，学情统计大屏、成绩分布与学员画像雷达图无法充分展现设计效果。
+* **边界界定**：这属于**交付层数据准备问题（DELIVERY / DEMO DATA TASK）**，而非统计模块未做规划。
+* **当前定性**：准备一套覆盖完整培训业务链路的演示数据，用于成绩、考勤、统计、画像展示。具体规模由内部演示需求确定，不作为甲方正式需求。
+
+---
+
+## 四、一期当前建议冻结状态
+
+为确保一期系统高质量按期交付并顺利通过现场验收，建议团队与甲方共同将当前状态冻结划分为以下四类：
+
+### 4.1 已经完成并建议冻结（建议不再接受随意变更）
+以下核心功能已经过全链路自动化测试、E2E 浏览器验证及物理数据库断言，建议作为一期基线直接冻结：
+1. **基础资源主档**：教师管理、学员主档（含身份证加密与脱敏）、课程库、理论教室、实训场地、宿舍房源；
+2. **教务业务闭环**：开班计划拟定、本期课程绑定（一班多课）、参训名单入班与容量限制、课次编排、场地 XOR 互斥、四维软冲突预检二次确认保存、课程表多维聚合展示；
+3. **关键节点联动**：现场报到状态强事务核销、课堂考勤（打卡/代签/事假/`manual_flag` 审计留痕）、一键结训强事务联动及退训学员保护；
+4. **权限与安全体系**：Admin/Teacher/Student 三角色登录认证、管理员建号与绑定流、教师自服务工作台、学员自服务工作台、横向越权（IDOR）系统级阻断、关闭公开注册、操作日志审计。
+
+### 4.2 具备部分技术基础或独立研发分支实现，待业务确认与后续开发
+以下事项已经具备部分技术基础或独立研发分支实现，但仍存在业务口径确认和/或后续开发工作，不应理解为确认规则后即可直接生产上线：
+1. **智能门禁业务策略**：学员请假期间门禁是否自动撤权；调房换宿“新房生效后再注销旧房”过渡期确认；门禁授权有效期的起止计算依据；
+2. **开门密码交付方式**：在全链路零明文存盘的安全规范下，学员端查看/接收限时密码的具体产品路径（个人中心动态查看 vs 管理员现场告知 vs 短信）；
+3. **宿舍主锁拓扑**：确认单宿舍是否仅需一把主锁下发开门密码，确认是否存在套间多门锁需求；
+4. **考勤与成绩口径**：迟到/早退阈值需甲方确认；综合成绩项目、权重和及格线既需甲方确认，也需配合 C-03 完成相应业务服务开发。
+
+### 4.3 真实外部系统联调（受控推进）
+以下事项均依赖外部环境、硬件或协议后才能继续推进。其中 DMS 已具备完整 Adapter/Mock 基础；电子班牌具备系统侧展示能力；人员/成绩外部数据源则需在甲方确认纳入范围并提供接口规范后再开发：
+1. **DMS 智能门禁外部联调**：获取供应商专属测试租户（`appid`、`appsecret`、`projectId`）与实验台测试锁具，执行真机发码与状态对账验收；
+2. **电子班牌终端联调**：获取物理班牌样机，验证投屏刷新频率与通信稳定性；
+3. **外部数据源接入（若甲方确认纳入范围）**：在甲方确认纳入范围并提供接口规范后，获取人员主数据同步接口与外部成绩回传规范。
+
+### 4.4 不建议当前继续自行扩展的内容（明确排除或归入二期）
+为了防止项目范围无限蔓延，以下内容建议双方一致明确**不纳入一期开发与验收范围**：
+1. **高危远程控制**：远程紧急开锁（Remote Unlock）；
+2. **硬件重度依赖项**：实体学员卡/门禁卡发卡与刷卡开门、手机蓝牙/NFC 虚拟钥匙开门、专用二维码扫码开门；
+3. **未立项复杂架构**：单点登录（SSO）全套开发、自动化 HR 组织架构双向同步中心、复杂机器学习画像规则引擎、多实例分布式 DMS 调度锁。
+
+---
+
+## 五、资料依据
+
+本文档严格基于以下工程资产与历史资料进行梳理与事实断言，全篇不包含任何真实明文密码、密钥或敏感配置：
+
+1. **PRD 开发基线**：`doc/RailwaySystem 智慧培训系统一期 PRD V1.0.md`（一期内部开发正式基线）；
+2. **历史需求与原始材料**：`doc/raw_materials/学员管理系统相关需求.md`、`doc/raw_materials/学员管理系统功能分析_20260831.md`；
+3. **会议纪要与决策**：第二次项目会议结论（业务最小闭环原则、一班多课、排除二期智慧基地控制）、第三次内部会议记录（DMS 预研事实、SSO 探讨、组织架构讨论、Demo 数据需求）；
+4. **生产 Release 与发版说明**：`docs/reports/release-notes.md`（v1.0.0-final-candidate 发版说明，对应正式生产 Release `08419b63`）、`docs/_meta/final-release-readiness.md`；
+5. **R.2 RBAC 真实三角色验收证据包**：`docs/reports/e2e-r2/RBAC_E2E_R2_20260916_102500/`（含 `report.md`、`role-matrix.md`、`account-binding-results.md`、`idor-results.md` 等）；
+6. **业务场景综合测试证据**：`docs/reports/final-test-report.md`（SC-01 ~ SC-06 六大业务场景 100% PASS）、`docs/reports/browser-acceptance-report.md`；
+7. **DMS 智能门禁适配资产**：`docs/development/dms-r3/`（含 `06_authorization_state_machine.md`、`13_open_questions.md`、`14_decision_summary.md` 及 Wave 0 ~ Wave 3B、Pre-Release QA 验证记录）；
+8. **学情分析与模型审计**：`docs/_meta/legacy-analytics-v2-audit.md`（明确 Analytics/Score/Portrait 读模型对齐与写操作现状）。
@@ -0,0 +1,129 @@
+# SYFJGYD学员管理系统
+# 一期甲方需求确认清单
+
+> **系统对外正式名称**：SYFJGYD学员管理系统
+> **内部工程代码代号**：RailwaySystem
+> **文档性质**：业务边界确认与外部联调准入清单（BUSINESS ALIGNMENT & ACCEPTANCE SCOPE）
+> **编制基线**：PRD V1.0、第三次内部沟通会议纪要及当前系统真实交付能力
+> **面向对象**：沈阳房建公寓段项目负责人、业务主管教师及各外部系统协调人员
+> **更新时间**：2026-09-16
+
+---
+
+## 一、填写与使用说明
+
+1. **文档目的**：为了保障“SYFJGYD学员管理系统”一期能够精准契合沈阳房建公寓段短周期铁路培训的实际管理模式，锁定现场验收与外部联调范围，避免双方将“非正式探讨项”误当作“必须交付项”，特提炼本清单供业务主管与技术负责人书面确认。
+2. **问题分级原则**：
+   * **P0（核心阻塞级）**：直接影响一期验收范围、第三方系统对接或生产环境开通，若不确认将导致开发与外部联调停滞；
+   * **P1（业务形态级）**：不影响教务主流程流转，但影响功能页面展示深度、统计口径与业务细节形态；
+   * **P2（后续规划级）**：属于二期或未来长期演进的扩展能力，用于提前锁定技术路线与长远规划，一期不做承诺。
+3. **填写要求**：请业务负责人重点审阅“当前默认处理”方案，如认可默认处理可直接勾选或批注“认可”，如有特殊业务管理要求请在“甲方答复”栏补充具体规范，并签署确认日期。
+
+---
+
+## 二、P0 核心阻塞级确认清单（共 18 项）
+
+### 1. 一期最终范围与验收基线
+
+| 编号 | 优先级 | 需要确认的问题 | 为什么必须确认 | 当前默认处理 | 甲方答复 | 确认日期 |
+| :---: | :---: | :--- | :--- | :--- | :--- | :--- |
+| **Q-P0-01** | **P0** | **一期验收基线确认**<br>《智慧培训系统一期 PRD V1.0》是否继续作为本期工程现场功能验收的正式业务基线？ | 明确系统验收边界，防止后续范围无限蔓延或理解不一致。 | **当前默认**：以 PRD V1.0 为唯一验收基准，以“最小可用、完整培训业务闭环”为原则推进验收。 | | |
+| **Q-P0-02** | **P0** | **核心培训业务流程符合度**<br>当前正式生产 Release 已完成“开班→绑定课程→参训名单→排课→现场报到→课次考勤→结训归档”的核心教务闭环。宿舍门禁能力正在独立 DMS 分支验证，成绩、学时与画像等能力仍在完善。请确认该整体业务流程及阶段划分是否符合贵段实际运作模式。 | 确保软件业务主线契合段内日常培训管理习惯，避免现场部署后流程脱节。 | **当前默认**：当前已完成核心教务主链 E2E 验证；DMS、成绩学情等扩展环节按各自实际状态继续推进。 | | |
+| **Q-P0-03** | **P0** | **一期必须完成的第三方接口范围**<br>在智能门锁、电子班牌、单点登录、外部人员同步等候选集成中，一期必须在本阶段完成现场硬联调的接口是哪几项？ | 区分“一期必须联调项”与“二期扩展项”，以便集中资源调配硬件与网络。 | **当前默认**：当前技术推进重点为 DMS 智能门禁；电子班牌已有系统侧展示能力；一期哪些第三方系统必须完成真实硬件联调，以甲方本次确认结果为准。 | | |
+| **Q-P0-04** | **P0** | **明确归入二期的功能范围确认**<br>二期建议内容（如平板端基地控制、工位分配、智慧照明、工具箱、数字孪生等）是否一致确认一期不纳入？ | 杜绝二期或外围硬件控制功能在一期验收中被作为卡点。 | **当前默认**：PRD V1.0 明确列为二期的硬件中控与数字孪生类需求，一期坚决不进行开发。 | | |
+
+---
+
+### 2. 人员主数据与组织架构归属
+
+| 编号 | 优先级 | 需要确认的问题 | 为什么必须确认 | 当前默认处理 | 甲方答复 | 确认日期 |
+| :---: | :---: | :--- | :--- | :--- | :--- | :--- |
+| **Q-P0-05** | **P0** | **学员档案主要来源渠道**<br>一期正式投入使用时，参训学员档案是通过管理员在系统界面单条录入、通过标准 Excel 模板批量导入、还是由外部既有系统推送？ | 决定一期数据准备重点。若外部同步，需提前明确接口；若导入，需固定模版。 | **当前默认**：当前支持：管理员单条维护学员；参训名单 Excel 批量导入；导入流程可按现有规则辅助建立基础学员档案。 | | |
+| **Q-P0-06** | **P0** | **授课教师档案维护方式**<br>培训基地的授课教师（内部教员、外聘专家）是由教务管理员在系统后台自建维护，还是需从局统一师资库同步？ | 明确师资档案的权威数据源。 | **当前默认**：由基地管理员在后台直接维护教师工号、姓名、专业领域与联系方式。 | | |
+| **Q-P0-07** | **P0** | **组织架构管理权责归属**<br>学员所属的“局 / 段 / 车间 / 班组”等组织架构是由系统管理员在本地组织树中维护，还是完全以局级统一组织架构为准？ | 决定组织部门树是否允许本地增删改，避免出现数据冲突。 | **当前默认**：采用系统内置多级部门架构管理，由管理员在后台自行配置各级车间与科室。 | | |
+| **Q-P0-08** | **P0** | **外部人员同步接口规范（若确认外部同步）**<br>若确定学员/组织必须从外部平台自动同步，请提供：接口网络规范、人员唯一身份编码（工号/身份证）、增量同步周期以及离职/停用规则。 | 外部同步需要明确通信协议与字段映射，否则无法开发集成。 | **当前默认**：在未提供正式接口文档前，系统暂不自行开发外部同步中心，保持本地管理。 | | |
+
+---
+
+### 3. 现场学员报到核验方式
+
+| 编号 | 优先级 | 需要确认的问题 | 为什么必须确认 | 当前默认处理 | 甲方答复 | 确认日期 |
+| :---: | :---: | :--- | :--- | :--- | :--- | :--- |
+| **Q-P0-09** | **P0** | **现场报到核验操作形态**<br>开班当天学员到达基地时，正式报到是由教务管理员在电脑端查询学员后点击确认、还是外接身份证读卡器刷证、还是人脸识别闸机自动核销、还是学员手机自助报到？ | 决定报到现场需要配备的电脑、读卡器或网络设备，以及报到界面主交互形态。 | **当前默认**：管理员在管理端“现场报到”列表核对学员身份后，点击“确认报到”完成状态核销，系统自动联动学员状态并触发门禁授权；支持登记人脸/刷卡/扫码核验标记。 | | |
+
+---
+
+### 4. DMS 智能门禁联调与业务策略
+
+> **说明：本节涉及已实现的 DMS 技术能力，当前均指 `feature/dms-r3` 独立研发分支验证结果，尚未合入当前正式生产 Release；本节业务策略仍以甲方书面确认为准。**
+
+| 编号 | 优先级 | 需要确认的问题 | 为什么必须确认 | 当前默认处理 | 甲方答复 | 确认日期 |
+| :---: | :---: | :--- | :--- | :--- | :--- | :--- |
+| **Q-P0-10** | **P0** | **正式测试租户凭据安全交接**<br>DMS 智能门禁平台供应商能否提供专属联调测试环境（独立 `appid`、`appsecret`、`projectId`）？如何通过安全加密渠道交付（严禁在普通微信群或公共代码库明文传输）？ | 保护门禁平台核心密钥安全，杜绝敏感凭据泄漏。 | **当前默认**：系统已实现配置文件动态注入与脱敏保护，待双方负责人通过加密通信渠道离线交接密钥后配置生效。 | | |
+| **Q-P0-11** | **P0** | **联调测试空间与门锁范围限定**<br>供应商与公寓方指定的联调门锁范围是什么？是否具备挂载在实验台的物理测试门锁与测试网关？ | 严禁直接在学员现住公寓的真实门锁上做联调测试，防止误开门或干扰在住人员。 | **当前默认**：在供应商提供明确的“实验台测试楼栋、测试房间、测试门锁编号”前，系统全流程在独立分支轻量模拟门锁服务（Mock）下验证，公网真实调用次数严格为 0。 | | |
+| **Q-P0-12** | **P0** | **系统允许调用的门锁操作范围**<br>学员管理系统向 DMS 发起指令的权限边界是什么？（建议：仅允许生成限时开门密码、注销指定密码、查询设备操作状态） | 严格遵循最小权限原则，防止系统误调用全局清空或非授权硬件配置接口。 | **当前默认**：系统仅收敛至“下发限时密码”、“注销指定密码”与“查询指令结果”，不调用批量删除或全局配置接口。 | | |
+| **Q-P0-13** | **P0** | **门禁授权有效期时间计算来源**<br>下发给门锁的限时密码，其起止时间是根据培训班计划起止时间推导、还是根据住宿安排起止时间推导、还是由宿管员手工指定？ | 明确开门权限的时间窗口边界，防止学员提前进房或结训后仍能开锁。 | **当前默认**：不自行假定门禁有效期公式。系统等待业务侧明确授权起止规则；在规则确认前不得生成无依据的有效期时间。 | | |
+| **Q-P0-14** | **P0** | **在线开门密码交付触达渠道**<br>出于安全合规要求，系统数据库对生成的 6 位开门密码明文全链路不留存。那么密码生成后，最终如何告知学员？（候选方案：学员手机端个人中心动态查看、管理员现场告知、短信平台发送通知等） | 密码明文不落库是安全红线，必须确定业务告知路径，否则学员无法获知开门密码。 | **当前默认**：密码交付渠道尚未确定。当前技术实现坚持密码明文不持久化、不写日志、不在普通接口/UI中泄露。学员个人中心、管理员现场告知、短信等均作为待甲方确认候选方案。 | | |
+| **Q-P0-15** | **P0** | **中途请假离校撤权策略**<br>学员在培训期间请假外出时，宿舍门禁权限是否需要系统自动撤销？ | 业务争议：若自动撤销，学员中途回房取私人物品或请假归来无法开门；若不撤权，外出期间存在他人冒用隐患。 | **当前默认**：学员中途短期请假时，系统**默认保持门禁权限不撤销**，以便妥善保管宿舍内个人生活用品；待结训退宿时统一强制注销。 | | |
+| **Q-P0-16** | **P0** | **调房换宿门禁过渡策略确认**<br>学员中途调整宿舍时，系统执行“先向新宿舍门锁下发新密码，确认生效后，再注销旧宿舍密码”的策略，是否存在两间房短时间均可开门的过渡期，公寓方是否认可？ | 保证学员可用性，防止新宿舍发码失败时学员两头进不去门。 | **当前默认**：采用“先授新房、对账成功后注销旧房”的高可用容错策略，全过程写入审计流水备查。 | | |
+| **Q-P0-17** | **P0** | **宿舍主门锁拓扑结构确认**<br>各宿舍房间门锁是仅有一把入室主门锁，还是存在“外防盗门 + 内部卧室门”等多把锁需要同时下发相同密码的套间结构？ | 决定门锁下发策略是单锁模式还是多锁同步联动模式。 | **当前默认**：严格执行“单房间唯一下发主门锁（Primary Lock）”策略，次锁不自动发码；若存在套间多锁，请公寓方明确说明。 | | |
+
+---
+
+### 5. 单点登录（SSO）
+
+| 编号 | 优先级 | 需要确认的问题 | 为什么必须确认 | 当前默认处理 | 甲方答复 | 确认日期 |
+| :---: | :---: | :--- | :--- | :--- | :--- | :--- |
+| **Q-P0-18** | **P0** | **一期是否必须接入单点登录（SSO）**<br>第三次会议讨论提及单点免登需求。请确认：一期是否必须接入局统一认证平台？若确认接入，请提供统一认证平台技术协议规范（OAuth2 / OIDC / CAS / SAML 等）、认证服务端地址、用户工号映射字段与登出处理规则。 | SSO 属于跨系统企业级集成，必须有明确协议文档与认证环境支持方可启动开发，严禁凭空盲测。 | **当前默认**：一期保持独立账号密码及图形验证码登录，**暂不自行启动 SSO 编码**；待甲方正式出具技术标准与测试服务后再启动集成。 | | |
+
+---
+
+## 三、P1 业务形态级确认清单（共 11 项）
+
+| 编号 | 优先级 | 需要确认的问题 | 为什么必须确认 | 当前默认处理 | 甲方答复 | 确认日期 |
+| :---: | :---: | :--- | :--- | :--- | :--- | :--- |
+| **Q-P1-01** | **P1** | **培训成绩数据来源**<br>各门课程的考试成绩，是由任课教师在系统后台录入、还是由纸质考卷批改后教务统一导入、还是从外部机考系统自动推送？ | 决定成绩管理模块是以教师自服务录入为主，还是以外部接口同步为主。 | **当前默认**：当前系统保留旧版成绩单表列表，多课程考核项目与加权计算正在完善中，支持后续人工录入或按需扩展外部同步。 | | |
+| **Q-P1-02** | **P1** | **自主学习时长数据来源**<br>学员台账中的“自主学习时长”，是一期由管理员根据考勤/课后任务手工补录，还是由外部在线学习平台自动回传？ | 影响学习时长统计的自动化程度。 | **当前默认**：当前系统提供学习时长台账只读列表查询，外部学习事件自动接入写入机制待业务明确后完善。 | | |
+| **Q-P1-03** | **P1** | **外部 VR / 3D 实训系统对接深度**<br>基地配备的 VR 室与 3D 演练系统，一期是仅在排课中作为场地资源预约，还是需要系统与 VR 软件通信获取学员实训操作得分与时长？ | 评估是否需要 VR 软件开发商提供 SDK 或网络接口。 | **当前默认**：一期先将 VR/3D 实训系统作为实训场地资源纳入排课与冲突管理；实训结果的成绩/时长记录方式随成绩与学习时长模块完善后确定，暂不自行开发真实 VR 数据接口。 | | |
+| **Q-P1-04** | **P1** | **电子班牌终端硬件与通信协议**<br>安装在教室门外的物理电子班牌，支持哪种网络协议（网页 URL 投屏 / 安卓 APK 原生请求）？轮询刷新的时间间隔要求是多少？ | 保证班牌终端能够准确、稳定渲染今日课程表与班级动态。 | **当前默认**：系统已提供班牌专用 Web 看板大屏页面，支持浏览器全屏投屏，数据按配置定时轮询刷新。 | | |
+| **Q-P1-05** | **P1** | **现场人脸识别设备接口协议**<br>若现场配备人脸闸机设备，该设备是支持主动推送 HTTP 回调，还是需要系统调用本地 DLL/SDK 下发人脸底库？ | 决定人脸核验的数据对接架构。 | **当前默认**：一期主流程在前端与业务服务层打通人脸核验状态标记，暂未绑定特定私有硬件驱动。 | | |
+| **Q-P1-06** | **P1** | **培训统计报表核心分析指标**<br>管理大屏与综合报表中，段领导最关心的核心指标包括哪些？（如：参训率、各单位参训分布、考勤及格率、多期培训横向对比、成绩优秀率等） | 使统计图表精准匹配管理层关注焦点，提高决策实用性。 | **当前默认**：系统当前提供开班总数、在训总人数、单位参训人次分布、每日考勤合规率与基础成绩分布展示，高级聚合统计按需定制。 | | |
+| **Q-P1-07** | **P1** | **学员综合画像评价维度与标签**<br>学员个人中心的学情雷达图与综合评价标签，具体的评分权重与评定规则如何设定？（如：出勤权重、实作权重、理论权重、优秀学员判定条件） | 消除算法硬编码，使学员画像评价公平、透明、合规。 | **当前默认**：当前系统具备静态雷达图前端页面与只读模型，动态画像计算与自动刷新服务待业务指标确定后完善。 | | |
+| **Q-P1-08** | **P1** | **教师档案是否扩展授课履历**<br>师资管理中是否需要详细记录教师的历史授课课时汇总、主讲课题清单及受评满意度评分？ | 决定教师档案信息项的丰富程度。 | **当前默认**：支持查看教师当前所授课次与排课日程，历史授课记录在课程表中持久化可查。 | | |
+| **Q-P1-09** | **P1** | **教师资质证书与特种作业到期提醒**<br>系统是否需要对教师的特种作业操作证、内训师资格证设置到期预警机制？ | 评估是否需要增加后台定时告警任务。 | **当前默认**：当前尚未作为一期已验收能力；如甲方确认需要，再确定资质字段、有效期与提醒方式。 | | |
+| **Q-P1-10** | **P1** | **界面视觉规范与设计稿要求**<br>甲方是否有正式的铁路系统 VI 视觉识别规范、企业标准色或指定的前端 UI 设计稿？ | 确保软件界面风格符合铁路行业统一品牌形象。 | **当前默认**：系统统一采用现代中后台视觉设计，对外正式标识统一为“SYFJGYD学员管理系统”。 | | |
+| **Q-P1-11** | **P1** | **移动端访问形态要求**<br>一期是否接受学员和教师使用手机自带浏览器直接访问自服务页面，还是必须定制企业微信应用或独立小程序？ | 明确前端工程的交付形态。 | **当前默认**：当前系统采用 Web 前端，可通过现代浏览器访问；移动端布局与实际操作体验尚需专项移动端验收。 | | |
+
+---
+
+## 四、P2 后续规划与二期候选清单（共 8 项）
+
+> ⚠️ **重要声明**：本节所列事项明确属于二期或未来长期演进能力，一期系统未做交付承诺。列出本节旨在澄清技术边界，防止会议发散讨论项被误列入现场验收范围。
+
+| 编号 | 优先级 | 候选需求项 | 建议推迟至二期 / 暂不实施原因 | 一期应对方案 | 甲方答复 | 确认日期 |
+| :---: | :---: | :--- | :--- | :--- | :--- | :--- |
+| **Q-P2-01** | **P2** | **远程紧急一键开门（Remote Unlock）** | 当前一期未实现；远程开锁属于高危控制操作，涉及网络延迟误开与安防责任界定；是否纳入后续阶段由甲方确认。 | 一期严格排除；现场若遇特殊情况由宿管员使用物理应急钥匙或现场重置限时密码开门。 | | |
+| **Q-P2-02** | **P2** | **动态二维码扫码开门** | 当前一期未实现；依赖专用光学扫码硬件锁具与对应协议支持；是否纳入后续阶段由甲方确认。 | 一期 DMS 当前优先采用在线限时密码方案，最终开门方式以甲方及公寓管理方确认结果为准。 | | |
+| **Q-P2-03** | **P2** | **实体学员卡 / 芯片门禁卡开锁** | 当前一期未实现；依赖物理发卡机、RFID 芯片卡及线下制卡发卡运营流程；是否纳入后续阶段由甲方确认。 | 一期暂不上线实体卡管理，二期根据基地硬件布设情况统一规划。 | | |
+| **Q-P2-04** | **P2** | **手机蓝牙 / NFC 虚拟钥匙开门** | 当前一期未实现；依赖各品牌移动端原生 SDK、操作系统权限及特定蓝牙门锁；是否纳入后续阶段由甲方确认。 | 推迟至二期评估。 | | |
+| **Q-P2-05** | **P2** | **高级机器学习画像规则引擎** | 当前一期未实现高级机器学习画像规则引擎；是否纳入后续阶段由甲方根据画像应用目标与数据条件确认。 | 一期优先采用可解释的基础业务指标展示，具体画像指标、权重与标签规则待甲方确认，并随 C-03/C-05 完善。 | | |
+| **Q-P2-06** | **P2** | **跨系统企业级统一工作门户** | 当前一期未实现；涉及全局待办中心聚合与多业务系统深层打通，需全局统筹规划；是否纳入后续阶段由甲方确认。 | 一期独立提供高内聚的培训管理工作台与自服务中心。 | | |
+| **Q-P2-07** | **P2** | **跨组织多身份复合矩阵权限** | 当前一期未实现；当前培训角色清晰，暂无引入复杂多维权限矩阵的迫切需求；是否纳入后续阶段由甲方确认。 | 一期已实现 Admin、Teacher、Student 三角色严格隔离与复合主体平滑兼容。 | | |
+| **Q-P2-08** | **P2** | **多实例分布式 DMS 任务调度集群锁** | 当前一期未实现；一期单机或轻量集群下已有单进程并发防击穿（DCL）保障；是否引入分布式锁集群方案由二期部署架构决定。 | 一期采用严密的单进程并发防击穿与幂等调度，保障系统稳定。 | | |
+
+---
+
+## 五、资料依据与事实出处
+
+本文档严格基于以下工程事实与资料编制，绝无凭空编造：
+
+1. **PRD 需求基准**：`doc/RailwaySystem 智慧培训系统一期 PRD V1.0.md`（特别是第 28 节“当前仍需现场验证的问题” V-01 ~ V-14）；
+2. **历次项目会议结论**：第二次项目会议结论（最小闭环原则、排除智慧基地中控）、第三次内部会议记录（DMS 测试事实、SSO 讨论、组织架构来源、演示数据任务）；
+3. **已落地的测试验收证据**：
+   * 三角色权限验收报告：`docs/reports/e2e-r2/RBAC_E2E_R2_20260916_102500/report.md`
+   * 业务主链路场景测试报告：`docs/reports/final-test-report.md`（SC-01 ~ SC-06 全部通过）
+4. **DMS 架构与开放问题资产**：
+   * 门禁授权状态机：`docs/development/dms-r3/06_authorization_state_machine.md`
+   * 未决业务问题清单：`docs/development/dms-r3/13_open_questions.md`
+   * 架构决策汇总：`docs/development/dms-r3/14_decision_summary.md`（含 Wave 0 ~ Wave 3B 及 Pre-Release QA 验证记录）；
+5. **学情分析与模型审计**：`docs/_meta/legacy-analytics-v2-audit.md`（明确 Analytics/Score/Portrait 读模型对齐与写操作现状）。