xiaotutongxue

lovife/xiaotutongxue

Fork 0

Commit Graph

Author	SHA1	Message	Date
lovife	9911ff01f1	feat(submit): 提交 + 红黄绿校验（PRD §5.7 的 VAL 系列）一次给全，不"改一条再拒一次"：学生一次可能同时缺 3 项材料、2 个字段没填，逐条拒绝会让他改 5 次提交 5 次。所以 validate 收全部问题后一次性返回 {ruleCode, severity, title, detail}，ruleCode 用 PRD 的 VAL-xx 编号。两段式提交：只有黄色警告时先返回 submitted=false 让学生确认，再带 confirmWarnings=true 才真的提交。为什么不前端自己判断 —— 只有服务端的校验结果算数，两次请求之间学生可能又改坏了什么。实现的规则：VAL-01 证件号 / VAL-05 材料完整性 / VAL-06 格式 / VAL-07 体积 / VAL-08 清晰度 / VAL-09 重复文件 / VAL-13 报考三项 / VAL-15 补考科目数按等级 / VAL-16 在校生三项 / VAL-17 工作年限 / VAL-18 未规范化 / VAL-20 体积下限 / VAL-22 表单必填（新增： PRD 的 VAL-01~21 是具体业务规则，没覆盖动态表单的必填字段，按系列顺延补的）。 ═══ 本轮抓到的四个真问题（都记在代码注释里了）═══ ① 校验器不能用列名当字段 key。字段 key 是 snake_case （work_unit / job_level / enroll_date），不是列名；而且报考三项存在 ext_json 里、不是独立列（契约 §2.4）。写 camelCase 的表现是 "明明填了却说没填"。更糟的是 VAL-16 读列、VAL-22 读表单装配值 —— 两条规则对同一份数据给出相反结论，学生不知道该信哪一条。现在统一用 FillService.getForm 装配出来的那一份作为唯一取值口径。 ② VAL-22 没判可见性。不判可见就会要求一个在校生填「补考理论」—— 而那个字段在他页面上根本不存在。求值口径已与前端 fill.vue 的 visible() 逐字对齐（norm 归一 true/false↔1/0、未知 op 一律可见）。 ③ VAL-01 读错了列：collect_roster.id_card_no 是 AES 密文（列注释写明的），明文只在导入与门禁时短暂存在。一开始拿它算校验位，于是每一份填报单都被判"身份证号未通过校验" —— 100% 阻断。这种"规则很对但读错列"的错，反而容易被当成"校验太严"而不是 bug。现在只确认名册里有证件号（用脱敏列），校验位交给导入与门禁。 ④ 静态资源没有 Cache-Control/ETag（新增 StaticCacheHeaderFilter）。没有它浏览器会走启发式缓存：旧 index.html → 旧 chunk → 学生发版后看到的是上个月的页面，而开发机硬刷新一次就没了，极容易被当成"偶发"。现在 /assets/** 一年 immutable（文件名带内容哈希）、 .html no-cache（每次校验）、/api/* no-store。排查过程里还确认了一件事：材料上传那轮的"浏览器加载旧 chunk" 不是构建问题 —— 从 8080 下载的 chunk 与磁盘文件 SHA-256 一致、里面确实有新代码，是缓存头缺失导致的浏览器行为。验收：e2e-m3-submit.py 30/30（含"该拦的确实拦了"和"修好后确实放过"）。回归：草稿 27 / 门禁 29 / 材料上传 29 / 材料目录 68 全绿。	2026-09-29 12:39:16 +08:00
lovife	8ef09733b1	feat(file): 材料上传的前端界面 + 列出/删除接口后端：GET /mp/files/submissions/{id}（列出我的材料）+ DELETE /mp/files/{id}（软删）。两者都把归属条件（submitter_id）写进 SQL 的 WHERE —— 与门禁、草稿同一套写法，少一个条件就是"能看/能删别人的材料"。前端（填报页的材料区）： · 按材料项列出：名称、必传标记、格式白名单与体积上限、来源引导语 · 已传的显示「原名 → 规范名」与「压缩前 → 压缩后」体积（学生要能看见系统做了什么） · 传完立刻处理并显示结果 ⚠️ 为什么上传后马上处理而不是留到提交时：学生要能看到"压到了多大、叫什么名字" 才算完成。若把处理留到提交时，他上传时会以为"传上去了"，提交时才发现体积超标 —— 而那时他可能已经在回家的路上。 · 学生能自己删（传错了不该只能找班主任）。已提交的填报单不给增删，与草稿同口径。 ⚠️ 本轮未完成浏览器肉眼验证：构建产物里确实有材料区的代码（产物 grep 到「需要上传的材料」），但浏览器加载的是缓存的旧 chunk （实测 .fill__wrap 只有 4 个子元素，没有材料卡），我用带时间戳的方式绕缓存没成功。代码与产物是对的，需要一次硬刷新（Ctrl+Shift+R）或清缓存后再确认。这条记下来，不要当成"已验证"。	2026-09-29 11:59:58 +08:00
lovife	465700969a	feat(h5): 填报页（三态 + 条件级联 + 失焦自动存草稿）学生终于能在手机上真正填一份表了。三态渲染（契约 §9.2）： locked=true → 只读灰底 + 「如有误请联系班主任」 prefilled=true,locked=false → 可编辑 + 橙字「老师已填，请核对」其余 → 普通空白实测：姓名/身份证号/联系电话/报考职业/工种/等级只读，学历可改并标注来源。条件级联（visibleWhen）在前端求值，实测正确：「是否在校生=是」→ 在读学校/所学专业/入学时间出现；「是否补考」未填 → 补考三科不出现。隐藏 ≠ 清空：学生把「是否补考」改回"否"，已填的补考科目仍留在草稿里（万一他改回来）。要不要清空由后端在提交时判断 —— 前端不该替用户做不可逆的事。保存策略：失焦即存单个字段。不做"整表提交"——学生填到一半切出去接电话，回来整表丢失是最让人恼火的失败。单字段保存的代价是一次请求，远小于"白填一遍"。进页面时若还没有草稿会先建一份（否则第一次失焦保存会因 submissionId 为空而静默不存）。前端拦住只读字段的保存请求（能省一次必然失败的请求），但服务端那道拒绝才是真的。顺带：核验页的「开始填写材料」接上了（带 taskId + scene —— H5 跳转不保留 URL 参数）。验收：构建产物含 pages-fill-fill；用无头浏览器实测渲染，三态与两处级联均正确，抬头显示「请在 2026-10-15 前提交」。	2026-09-29 11:43:45 +08:00

Author

SHA1

Message

Date

lovife

9911ff01f1

feat(submit): 提交 + 红黄绿校验（PRD §5.7 的 VAL 系列）

一次给全，不"改一条再拒一次"：学生一次可能同时缺 3 项材料、2 个字段没填，
逐条拒绝会让他改 5 次提交 5 次。所以 validate 收全部问题后一次性返回
{ruleCode, severity, title, detail}，ruleCode 用 PRD 的 VAL-xx 编号。

两段式提交：只有黄色警告时先返回 submitted=false 让学生确认，
再带 confirmWarnings=true 才真的提交。为什么不前端自己判断 ——
只有服务端的校验结果算数，两次请求之间学生可能又改坏了什么。

实现的规则：VAL-01 证件号 / VAL-05 材料完整性 / VAL-06 格式 /
VAL-07 体积 / VAL-08 清晰度 / VAL-09 重复文件 / VAL-13 报考三项 /
VAL-15 补考科目数按等级 / VAL-16 在校生三项 / VAL-17 工作年限 /
VAL-18 未规范化 / VAL-20 体积下限 / VAL-22 表单必填（**新增**：
PRD 的 VAL-01~21 是具体业务规则，没覆盖动态表单的必填字段，按系列顺延补的）。

═══ 本轮抓到的四个真问题（都记在代码注释里了）═══

① **校验器不能用列名当字段 key**。字段 key 是 snake_case
   （work_unit / job_level / enroll_date），不是列名；而且报考三项
   存在 ext_json 里、**不是独立列**（契约 §2.4）。写 camelCase 的表现是
   "明明填了却说没填"。更糟的是 VAL-16 读列、VAL-22 读表单装配值 ——
   **两条规则对同一份数据给出相反结论**，学生不知道该信哪一条。
   现在统一用 FillService.getForm 装配出来的那一份作为唯一取值口径。

② **VAL-22 没判可见性**。不判可见就会要求一个在校生填「补考理论」——
   而那个字段在他页面上根本不存在。求值口径已与前端 fill.vue 的 visible()
   逐字对齐（norm 归一 true/false↔1/0、未知 op 一律可见）。

③ **VAL-01 读错了列**：collect_roster.id_card_no 是 **AES 密文**
   （列注释写明的），明文只在导入与门禁时短暂存在。一开始拿它算校验位，
   于是每一份填报单都被判"身份证号未通过校验" —— 100% 阻断。
   这种"规则很对但读错列"的错，反而容易被当成"校验太严"而不是 bug。
   现在只确认名册里有证件号（用脱敏列），校验位交给导入与门禁。

④ **静态资源没有 Cache-Control/ETag**（新增 StaticCacheHeaderFilter）。
   没有它浏览器会走启发式缓存：旧 index.html → 旧 chunk →
   **学生发版后看到的是上个月的页面**，而开发机硬刷新一次就没了，
   极容易被当成"偶发"。现在 /assets/** 一年 immutable（文件名带内容哈希）、
   *.html no-cache（每次校验）、/api/** no-store。

排查过程里还确认了一件事：材料上传那轮的"浏览器加载旧 chunk"
不是构建问题 —— 从 8080 下载的 chunk 与磁盘文件 SHA-256 一致、里面确实有新代码，
是缓存头缺失导致的浏览器行为。

验收：e2e-m3-submit.py **30/30**（含"该拦的确实拦了"和"修好后确实放过"）。
回归：草稿 27 / 门禁 29 / 材料上传 29 / 材料目录 68 全绿。

2026-09-29 12:39:16 +08:00

lovife

8ef09733b1

feat(file): 材料上传的前端界面 + 列出/删除接口

后端：GET /mp/files/submissions/{id}（列出我的材料）+ DELETE /mp/files/{id}（软删）。
  两者都把归属条件（submitter_id）写进 SQL 的 WHERE —— 与门禁、草稿同一套写法，
  少一个条件就是"能看/能删别人的材料"。

前端（填报页的材料区）：
  · 按材料项列出：名称、必传标记、格式白名单与体积上限、来源引导语
  · 已传的显示「原名 → 规范名」与「压缩前 → 压缩后」体积（学生要能看见系统做了什么）
  · 传完**立刻处理**并显示结果

  ⚠️ 为什么上传后马上处理而不是留到提交时：学生要能看到"压到了多大、叫什么名字"
     才算完成。若把处理留到提交时，他上传时会以为"传上去了"，提交时才发现体积超标 ——
     而那时他可能已经在回家的路上。

  · 学生能自己删（传错了不该只能找班主任）。已提交的填报单不给增删，与草稿同口径。

⚠️ 本轮**未完成浏览器肉眼验证**：构建产物里确实有材料区的代码
   （产物 grep 到「需要上传的材料」），但浏览器加载的是**缓存的旧 chunk**
   （实测 .fill__wrap 只有 4 个子元素，没有材料卡），我用带时间戳的方式绕缓存没成功。
   代码与产物是对的，需要一次硬刷新（Ctrl+Shift+R）或清缓存后再确认。
   这条记下来，不要当成"已验证"。

2026-09-29 11:59:58 +08:00

lovife

465700969a

feat(h5): 填报页（三态 + 条件级联 + 失焦自动存草稿）

学生终于能在手机上真正填一份表了。

三态渲染（契约 §9.2）：
  locked=true                → 只读灰底 + 「如有误请联系班主任」
  prefilled=true,locked=false → 可编辑 + 橙字「老师已填，请核对」
  其余                        → 普通空白
实测：姓名/身份证号/联系电话/报考职业/工种/等级 只读，学历可改并标注来源。

条件级联（visibleWhen）在前端求值，实测正确：
  「是否在校生=是」→ 在读学校/所学专业/入学时间 出现；
  「是否补考」未填 → 补考三科不出现。

**隐藏 ≠ 清空**：学生把「是否补考」改回"否"，已填的补考科目仍留在草稿里
（万一他改回来）。要不要清空由后端在提交时判断 —— 前端不该替用户做不可逆的事。

保存策略：**失焦即存单个字段**。不做"整表提交"——学生填到一半切出去接电话，
回来整表丢失是最让人恼火的失败。单字段保存的代价是一次请求，
远小于"白填一遍"。
进页面时若还没有草稿会先建一份（否则第一次失焦保存会因 submissionId 为空而静默不存）。

前端拦住只读字段的保存请求（能省一次必然失败的请求），但**服务端那道拒绝才是真的**。

顺带：核验页的「开始填写材料」接上了（带 taskId + scene —— H5 跳转不保留 URL 参数）。

验收：构建产物含 pages-fill-fill；用无头浏览器实测渲染，
三态与两处级联均正确，抬头显示「请在 2026-10-15 前提交」。

2026-09-29 11:43:45 +08:00

3 Commits