xuyue/OJ2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
175 Commits 1 Branch 0 Tags
74b97c610fbb6a7f35555708a53b68ea36028171
Commit Graph

132 Commits

Author SHA1 Message Date
yuetsh
74b97c610f fix(题单): 「选做」终于作数了，分母只算必做题 
isRequired 一直只是卡片上的一行字：卡片写着「（选做）」，进度分母和 all_problems
奖章却照样要求做完。结果是学生按提示跳过选做题，进度条卡在 100% 以下、全通奖章也
拿不到 —— 快照里 22 个人做完了全部必做题却显示未完成（题单 5 三人、6 十人、8 两人、
11 七人）。旧栈的 update_progress 同样不区分，是一路继承下来的。

改成：分母只算必做题，选做题做了仍然计分（totalScore 把它算进去），只是不卡完成。
一道必做都没标的题单退回「全部都算必做」—— 那种题单多半是没用这个字段，而不是真的
整单选做，不兜住的话它永远完不成。

## problem_count 奖章不能跟着改

老师当初是按题单的**总题数**设阈值的：题单 5 的「一职欧拉」要 8 题，而它的必做只有
7 道。要是 problem_count 也改用只数必做的 completedProblemsCount，这枚奖章一夜之间
不可得，76 个已经拿到的人会被 recalculateBadge 收回。所以它数的是「做出的题目总数
（含选做）」，从 progress_detail 的键数来。score 类同理不受影响。

预演证实了这道闸门有效：22 人拿到完成状态，奖章补发 56 条、**收回 0 条**。

## 顺带：第三份手抄的达标逻辑

PUT /problem-set-progress 里还藏着一份 inline 的奖章判定，和 services 里那份、
补发脚本里那份是三份各写各的 —— 这次改 problem_count 的语义，漏掉任何一份都会让
学生提交时发的奖章和后台重算的结果对不上。三处统一到 eligibleForBadge。

## 工具改名并扩到进度

backfill-badges → backfill-problemsets。语义变更之后，已有的进度行要跑一遍才会按新
规则重算，否则那 22 个人得等到老师下次动题单才生效。两笔账本来也是同一笔：进度一变，
奖章达标面就跟着变，所以落库走 resyncProgress（它重算进度后会顺手重算该题单全部奖章），
预演里的奖章差异也是照着订正后的进度算的，保证预演和 --apply 的结果一致。

在生产快照上实跑：

  合计：进度 494 条要重算（完成 +22 / -0），奖章补发 56 条、收回 0 条
  已订正 10 个题单 → 复核通过：题单数据与规则一致
  user_badge 1180 → 1236，已完成 621 → 643
  「未完成但有完成时间」仍是 4 条（d7a6414 那条语义保住了）
  重复跑幂等：进度 0 条、奖章 0 条

抽查题单 6（9 必做 + 1 选做）：只做必做的显示 9/9 100% 已完成、80 分；连选做一起做的
同样 9/9 已完成，但 90 分。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 08:55:36 -06:00
yuetsh
d9e6a2a3f0 perf(题单): 学生端题目列表少两次 join 一次查询，顺带把并列的 order 排稳 
## 排序

学生端 /problem-sets/:id/problems 只按 order 排，没有 tiebreaker，而卡片是按数组
下标编号的（#1 #2 #3）。order 并列时 Postgres 不保证次序，题单 8（3 道题 order 都是
10）、题单 11（2 道并列 4）、题单 14（3 道并列 0）实际就有并列，于是「第 3 题」指
哪道题每次刷新都可能变。后台那条列表一直是 order + id 排的，两边本来就不一致。

补上 asc(id)。教师进度视图里那份题目清单（同一路由文件 :398）有同样的问题，一并补。

实跑：四道题、三道 order 并列，连打 5 次次序完全一致。

## 载荷

这个接口原来复用 problemListItemSchema，为此要多 join user + user_profile 凑
createdBy、再多查一次标签表凑 tags —— 而题单卡片只渲染题号、标题、难度、分数和
完成标记。tags / submissionNumber / acceptedNumber / createdBy / contestId /
allowFlowchart / showFlowchart / hasAstRules 一个都不用，myStatus 甚至写死是 null。

而且 select 的是 schema.problem 整行，题面、样例、答案、ast_rules、flowchart_data、
sql_display 全都白拉回来一遍。

改成 problemSetProblemItemSchema（id / _id / title / difficulty 四个字段），查询相应
收窄：两次 join 去掉，标签那次查询整条去掉，行查询只取四列。每次请求从 4 条查询降到
3 条，其中最大的那条不再拖整行题面。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 08:47:57 -06:00
yuetsh
d7a6414735 fix(题单): complete_time 翻回「只设不清」；完成题单后那个必然报错的 tab 
三件事，都是上一轮结论没查扎实留下的。

## complete_time

f9354b0 把「退回未完成时清空 complete_time」定成两边统一的行为，理由写的是
「快照里 complete_time 非空 ⟺ is_completed」。那个检查只做了一个方向（已完成但
没有完成时间 = 0 条），反方向没查 —— 实际有 4 条 is_completed=false 却留着
complete_time，全在题单 8：那批人 2025-11-14 在它还只有 6 题时完成过，老师后来
加到 12 题，进度退回未完成，完成时间保留了下来。

旧栈是故意不清的（problemset/models.py:218 只有 `if is_completed and not
complete_time` 这一条赋值），语义是「曾经完成于」。清空是重写时在学生路径上引入的，
上一版又把它推广到了后台路径。

翻回只设不清。「未完成 + 有完成时间」是允许的组合。反过来清空的代价不可逆：往一个
100 人已完成的题单里加一道题、再改主意删掉，这 100 个人的历史完成时间就一起被冲成
「现在」—— 上一轮的实跑已经在题单 9 上复现过。

## 两处注释订正

「旧后端不做加题后的重算」这个说法是错的，本仓早先的注释里有，上一版我照搬进了
services/problemset.ts 和提交信息。旧栈用 signals 做了，而且两件事都做：
problemset/signals.py 在 ProblemSetProblem 的 post_save / post_delete 上重算全部
参与者进度、再重算该题单全部奖章。重写时 views 里翻不到显式调用就当成没做，于是
奖章那一半漏了 —— 53 条应发未发正是这么来的。

另外补上 53 条里那 23 条的出处：旧栈的管理命令 fix_problemset_progress 按实际 AC
补 progress_detail，而 signals 不挂在 Progress 上，所以进度补了、奖章没补。

## 用户进度 tab

detail.vue 的 showTabs 写的是「超管 或 自己完成了题单」，而它渲染的
UserProgressView 调的是 requireTeacher 的接口。两边正好错开：

- 学生做完题单 → tab 出现 → 点进去 403（实跑确认：已完成该题单的 student 拿到
  403 permission-denied，devadmin 拿到 200）。而 loadUserProgress 没有 try/catch、
  loading.value = false 又写在 await 之后，转圈永远停不下来。
- Teacher Admin 看不到这一栏，尽管他们才是它的目标用户、也是唯一调得动的角色。

条件换成 isTeacherOrAbove，取数补 try/finally。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 08:42:40 -06:00
yuetsh
05cf8011e3 fix(题单): 奖章补发改成二进制子命令，独立脚本在生产跑不了
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
上一版把补发写成 `bun src/scripts/backfill-problemset-badges.ts`，那在生产上根本执行
不了 —— api 镜像是 debian-slim + 一个编译好的 oj2-api，既没有 bun 也没有源码。

改成 main.ts 的子命令，跑法对齐 migrate（deploy.sh:197 就是这个形态）：

  docker compose -f docker/compose.debian.yml run --rm oj-api oj2-api backfill-badges
  docker compose -f docker/compose.debian.yml run --rm oj-api oj2-api backfill-badges --apply

脚本本身从「导入即执行」改成导出一个返回退出码的函数，main.ts 负责解析参数和 exit。
package.json 的 backfill:badges 也指向同一入口，本机和生产走的是同一条代码路径。

用编译出来的二进制在 /tmp 下实跑过全部四条路径（预演 / --apply 后自动复核 / 重复跑
幂等 / 误发时拒绝执行并退 1，加 --allow-revoke 才收回），确认动态 import 的模块进了
bundle、不依赖源码树。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 08:26:27 -06:00
yuetsh
f9354b0df1 fix(题单): 进度重算漏了分数和完成状态，奖章没人补发
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
进度算法在学生路径和后台路径各写了一遍，于是各自漂了一段。后台那份
（resyncProgress）名叫「把所有参与者的进度重算一遍」，实际只更新分母和百分比：

- 不碰 total_score。改题目分值时专门调了它，函数体里却没这个字段，score 类奖章
  因此按陈旧分数判定。
- 不碰 is_completed。加一道题之后分母变大、百分比掉下来，人还标着「已完成」。
- 不清理 progress_detail。删掉一道题之后 least(completed, total) 只保证不超过分母，
  会把没做的题算成做了 —— 3 题的题单只做出 C，删掉 C 就变成 1/2 = 50%。
- 不重算奖章。题目集一变 all_problems 的达标面就变了，没有任何地方补发。

最后一条攒下了实打实的欠账：8-07 的快照里 53 条应发未发，涉及 30 名学生，误发 0 条。
其中 23 条来自 2026-05-22 00:50 那次一分钟内跨 7 个题单的批量补进度 —— 进度补了，
奖章没人回头判。

两边不再分叉的唯一办法是只留一处算法，所以抽出 services/problemset.ts：
computeProgress 是纯函数，学生做出一题和后台改题目都只是调用者；
eligibleForBadge / recalculateBadge / resyncProgress 一并搬过来，补发脚本才能复用
同一套判定。批量写回仍是一条 UPDATE ... FROM (VALUES ...)，没退回逐行往返。

顺带修掉空题单的坑：isCompleted 加了 total > 0 前提。原来 0 === 0 也成立，老师先建
题单、学生先加入、题目后加，加入那一刻就写下 complete_time 并计进「完成题单数」成就，
而且后面补上题目也不会自愈。

一处行为变化：退回未完成时 complete_time 会清空。后台那份原来保留旧时间，学生那份
一直是清空的，统一成后者 —— 否则同一行会出现「未完成 + 有完成时间」，破坏现有数据里
「complete_time 非空 ⟺ is_completed」这条不变量。代价是加题再删题会把历史完成时间
洗成「现在」。

scripts/backfill-problemset-badges.ts 补历史欠账，默认只读预演，--apply 才落库。
只要存在误发就拒绝执行并打出名单，要连收回一起做得显式加 --allow-revoke ——
recalculateBadge 的删除是真删，user_badge 的 earned_time 没有别处备份。

在生产快照上实跑：补发 1180 → 1233 条，复核全部一致，历史 earned_time 未被刷新；
resyncProgress 对题单 9（7 题 / 117 人 / 100 人完成）加题后正确退回 0 人完成并收回
100 枚奖章，删题后完整恢复；改题目分值 10→20 使总分和 7460 → 8590，正好 +113×10。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 08:23:38 -06:00
yuetsh
ff31f7abd1 fix(题单): 补回加入题单前旧提交的遮挡 
旧栈的 SubmissionListSerializer.get_show_link 有一条防作弊规则：学生加入含某道题的
题单后，他在加入之前留下的 AC 代码就摆在提交列表里，复制粘贴即可过关，所以要把这段
旧提交藏起来。重写时整条丢了 —— canViewSubmission 里 grep 不到一个 problemset，
自己的提交第一行就无条件 return true。

前端反而把 UI 留着了：ProblemSubmission.vue 那个锁图标的 tooltip 一直写着「这道题在
你已经加入的题单中，只有在题单中完成此题，代码才可见」，而后端永远不会给出
showLink: false，图标一次都没亮过 —— 提示语本身成了操作指引。

题单的 end_time 也因此成了孤儿字段：它不是「截止后不能提交」，是这道闸门的时间边界。

影响面不是边角：8-07 的快照里 1734 人次、188 名学生在加入题单之前就已经 AC 过题单
里的题，占全部已解题次的 22.5%。

补回来的同时改了三处旧栈的做法：

- 判断放进 canViewSubmission，列表和详情一起挡。旧栈只挡列表链接，
  SubmissionAPI.get 光走 check_user_permission，知道 submission id 直接访问照样
  拿得到代码，遮挡是虚的。
- 一题落在多个已加入题单里时取 max(join_time)，「存在任一题单要求遮挡就遮挡」等价于
  「早于最晚的那次加入」。旧栈用 .first() 取任意一条，行为不确定。
- 比赛提交列表不挂闸门。题单里的题必定是非比赛题（加题时卡了 contestId IS NULL），
  而那条列表只出比赛提交，交集恒空，挂上去就是每页白跑一次查询 —— 而比赛进行中它是
  被刷得最狠的。旧栈 ContestSubmissionListAPI 照抄了 bulk_fetch，那边同样是死代码。

闸门只挡「看代码」这一路，不挡 allowShared=false 那一路 —— 后者是分享开关的归属校验，
与作弊无关，挡了学生连自己旧提交的分享都动不了。管理员不受限，对齐旧栈的
is_regular_user() 前提。

解锁三条路实跑验证过：在题单里做出该题、题单过 end_time、题单归档。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 08:23:13 -06:00
yuetsh
2031e6a434 update
Some checks failed
Deploy / deploy (push) Has been cancelled
Details
2026-08-31 07:41:44 -06:00
yuetsh
e62f41f6c7 refactor(web): Header 只管顶栏，全局的东西挂回 App 
Header 一直兼着「全局挂载点」：课堂求助的提示、新求助 toast、求助列表和
教师端协作弹框都寄生在里面，只因为顶栏是全局的。它其实不是 ——
/admin/* 走的是 admin.vue，没有 Header，老师一进后台这四个消费者全部
卸载：求助照收，提示、角标、弹框一个都不出现，正好是 collab.ts 里写的
「老师可能正在后台改题时收到求助」那个场景。

这些东西跟着连接走，而连接在 App.vue 按登录态开关，所以搬进 CollabHost
挂在同一层。Header 因此不必再是单根组件，default.vue 那个靠 class 传
居中样式的写法也换成外层 div，连带删掉「必须挂在根 n-flex 内部」那段
补丁注释。

顺带：
- 圆环扩散的暗黑切换抽成 useDarkTransition
- 求助的角标/toast/列表不再限桌面端 —— 老师缩窗口也得知道有人在等；
  接单确实要在电脑上写代码，那道闸挪进 HelpRequestList
- 站名改 text 按钮，能 tab 到、回车能按
- logout 的两步收进 userStore.signOut()
- 清掉死代码：handleMenuSelect 只认一个不存在的 key、active 里
  ["user","setting"] 永远不生效的排除、两个 show:false 的菜单项

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 07:36:14 -06:00
yuetsh
cbe6955c26 update
Some checks failed
Deploy / deploy (push) Has been cancelled
Details
2026-08-30 22:22:10 -06:00
yuetsh
0e083225f1 update
Some checks failed
Deploy / deploy (push) Has been cancelled
Details
2026-08-30 22:11:31 -06:00
yuetsh
38b81881d5 feat(collab): 教师端弹框补上代码提示，语言跟着学生走
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
教师端的协作编辑器只有高亮和括号匹配，没装 autocompletion —— 老师替学生
写代码时没有下拉补全，只能盲敲。而且语言写死 cpp()，学生写 Python 时老师
看到的是 C 的高亮。

- 求助协议带上语言：help_request 记到 HelpRequest，accept 时写进 Room，
  room_open 发给两端；认不出的语言一律当 C（老客户端不带这个字段，而它
  以前就是写死 C 的）
- 新增 help_language / room_language：学生在排队或协作期间切语言，只更新
  语言，不动队列位置和房间；已开房就把新语言推给老师，弹框的高亮和补全
  实时跟着换
- CollabModal 装上 autocompletion，和学生端用同一套 enhanceCompletion +
  completeAnyWord；语言→高亮扩展的映射抽到 shared/extensions/language.ts
  两端共用，免得再分叉
- 学生端求助按钮合并状态提示：原来按钮旁边还挂一个 n-tag，一行工具栏在
  1280 的机房屏上放不下，改成状态全进 label（已求助 · 待接入 / 已求助 ·
  前面 N 人 / xxx 老师帮你中）

扩展数组变了 vue-codemirror 会整体 reconfigure，但 CM6 对已存在的
compartment 取 `compartments.get() || ext.inner`，collabDoc 那个装 yCollab
的 compartment 内容会被沿用，切语言、切主题都不会把协作弄断 —— 实跑验证过
双向同步、补全下拉、协作中切语言三条路径。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015APGLsyaCUa7XFMYAaCho4
 2026-08-30 10:28:36 -06:00
yuetsh
2f9b6dbf03 FIX
Some checks failed
Deploy / deploy (push) Has been cancelled
Details
2026-08-30 09:59:27 -06:00
yuetsh
ffabcd4a0d fix(collab): 提示会丢、排队位置不刷新；显式声明 lib0
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
- 一次性提示原来挂在题目页的 Form.vue 上消费：学生排着队切去看提交记录，
  老师这时取消了他的求助，那条提示就永远没人消费。挪到顶栏统一弹，
  教师端的 error 提示同理。另外加了序号——连着两次同样的文案在 Vue 眼里
  === 相等，watch(notice) 不会第二次触发。

- queueAhead 原来只在「建请求 / 重连 / 退回排队」推过，前面的人被接走或
  被取消之后不重算，第五个学生会一直显示「前面还有 4 人」。跟着
  broadcastRequests 一起推，两件事永远同时发生。

- collabDoc 动态 import 了 lib0/encoding 和 lib0/decoding，但 lib0 不在
  package.json 里，靠 yjs 提升到根 node_modules 才能解析。上游依赖树一变
  就断，而且断在运行时不在构建时。按现装的 0.2.117 钉住。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016DHxhKNxXfG89JnVzHbvgj
 2026-08-30 09:38:04 -06:00
yuetsh
4abaf9c7e4 fix(collab): 动态 import 竞态、切走页面的语义、演示模式的身份错位 
- collabDoc.start 要 await 六个动态 import，房间可能在这期间就关了（机房首次
  加载 y* 那几个 chunk 正是最慢的时候）。stop() 先跑完面对的是 doc === null，
  什么也拆不到；import 回来之后 start 的后半段照样建文档、装 binaryHandler、
  挂 yCollab、发 SyncStep1——给一个不存在的房间。加会话代号，过期就整个放弃。

- SyncCodeEditor 卸载（切走题目页、把语言切成流程图）原来只是悄悄 stop()，
  房间和 active 都还留着，老师那边模态框照开、字照敲，一个也到不了；watch
  没有 immediate，学生切回来也不会重建。改成明确 leave() 结束协作。
  另外 @ready 也作为起点之一：学生排队时切走、老师这期间接了单，切回来能接上。

- 演示模式下 isTeacherOrAbove 被强制 false，服务端却按库里的 adminType 照样
  把他算作在线老师：学生因此拿到 pending 而不是 no_teacher，排队等一个顶栏里
  根本没有求助列表的人；他自己看到的求助按钮点下去，服务端回「教师不能发起求助」。
  两头都不对，索性对演示模式整个关掉这个功能。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016DHxhKNxXfG89JnVzHbvgj
 2026-08-30 09:38:04 -06:00
yuetsh
66a564710f fix(collab): 两处会让协作「看起来正常、其实各写各的」的缺陷 
都是实测复现出来的，不是推测。

1. 教师第二次接单，看到的是上一个学生的代码拼在自己文档里
   CollabModal 的 code ref 跨会话不清。n-modal 默认 display-directive="if"，
   每次打开都重挂 CodeMirror，拿这个 ref 当初始文档；而 yCollab 只观察 ytext、
   从不反过来用 ytext 覆盖编辑器。于是上一轮的代码留在文档里，新学生的内容
   作为 delta 插到位置 0，两边偏移从此对不上。
   实测三轮会累积成 CCC/BBB/AAA/XXX，且教师敲一行之后，教师看到
   「BBB/AAA/XXX」、学生看到「BBB/XXX」——两份不同的文档。
   改法：不绑 v-model，文档完全交给 Yjs；并把 start 的起点从「房间打开 +
   await nextTick」换成「编辑器 ready」，顺带修掉绑到已 destroy 的旧 view。

2. 学生换连接后房间静默死掉
   handleCollabOpen 迁移 socket 时只补发了 help_status，没补 room_open，
   而前端每次连接建立都会把 room 清成 null —— 页面显示「老师正在帮你」，
   编辑器却早把 yCollab 摘了，老师敲的字一个也到不了。
   补发 room_open 也修不好：CRDT 状态跟着旧连接没了，新建 Y.Doc 再 seed
   会和老师那份合并成重复文本。所以改成直接拆房、请求退回排队，
   老师再点一次 —— 和老师掉线走同一条路子。

顺带修掉验证时挖出来的第三个：握手帧会被丢。
两端挂 yCollab 的时刻不同步（教师等模态框、学生等 chunk），先挂好的那端发的
SyncStep1 到对面时还没有 binaryHandler，服务端转发是成功的、客户端却静静丢掉。
丢的偏偏是握手——y-protocols 里 A 的内容靠 B 发的 Step1 换回来，教师的 Step1
一丢，学生的代码就永远到不了教师那边（单向同步，同样看着像在协作）。
CollabWebSocket 改成 handler 装上之前先把二进制帧缓着，装上再按序放行。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016DHxhKNxXfG89JnVzHbvgj
 2026-08-30 09:37:41 -06:00
yuetsh
bb33e0f0e5 refactor(web): 删掉 SyncCodeEditor 的 problem prop 
老实现的残留：sync.ts 拿它拼房间名 problem-${problemId}。新实现的房间以
学生为键、由服务端分配，前端不需要题号 —— 这个必填 prop 声明之后
整个组件再没用过第二次。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016DHxhKNxXfG89JnVzHbvgj
 2026-08-30 09:05:48 -06:00
yuetsh
4b6242ba70 fix(比赛): 比赛进行中，学生打开比赛题必 500 
contest.ts 两处把「藏起来的难度」表示成空串，而 problemDifficultySchema
是严格的三值枚举，parse 直接抛 ZodError。contestDetailsAllowed 在
「比赛进行中 + 看的人不是管理员」时就是假 —— 也就是正常学生在正常比赛里，
比赛题列表和详情页一开就挂。dev 库 contest 表一直是空的，这条路径没被跑到过。

改成下发 null，契约里给这两个字段单独起了 maskedProblemDifficultySchema。
语义上对齐旧 Django：ProblemSafeSerializer 把 difficulty 放在 exclude 里，
字段整个不下发，而不是给一个假值。

端上顺着 null 补了四处：ProblemInfo 的「难度」项整条不渲染（和旧栈表现一致），
题目列表、题单列表同理，transforms 的 ProblemFiltered.difficulty 也放开为可空。
这几处是 vue-tsc 逐个揪出来的，正是严格枚举该起的作用。

实测（学生 / 超管 × 比赛题 / 普通题 四种组合）：学生看比赛题详情与列表
从 500 变 200 且 difficulty 为 null，超管仍拿到真值 Low，普通题不受影响；
页面上「难度」整项消失，统计面板其余内容正常。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016DHxhKNxXfG89JnVzHbvgj
 2026-08-30 09:01:56 -06:00
yuetsh
c7132025f7 fix(collab): 二进制帧的宽松限流档名存实亡 
两档共用一个令牌桶：桶按严格档的 20 初始化，之后每条文本帧（含 30 秒
一次的心跳）都会 Math.min(RATE_BURST, ...) 把它压回 20，二进制帧那档
标的 200 突发根本拿不到。实测连打 150 帧在第 101 帧被 1008 踢下线——
正是设计里要避免的「协作编辑时打字把自己踢掉」。

改成两个独立的桶。文本帧仍是 20 / 每秒 2，二进制帧 200 / 每秒 100。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016DHxhKNxXfG89JnVzHbvgj
 2026-08-30 08:29:36 -06:00
yuetsh
d1fc6349b7 refactor(web): 删掉 y-webrtc 协同编辑的旧实现 
sync.ts / syncStatus.ts、y-webrtc 依赖、PUBLIC_SIGNALING_URL 全部移除，
外部信令服务器 signaling.xuyue.cc 不再被使用。
顺带修掉 CLAUDE.md 里「协作在流程图编辑器」这句一直是错的描述。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016DHxhKNxXfG89JnVzHbvgj
 2026-08-30 08:22:06 -06:00
yuetsh
86857dedf0 feat(web): 协作编辑走 collab 通道 
Yjs sync/awareness 协议直接跑在 /ws/collab 上，服务端哑转发。
内容源是学生：学生端先把编辑器内容写进 ytext 再挂 yCollab，
教师端 seedContent 恒为 null —— 这条根治了老实现里谁的代码活下来看运气的问题。

订正 brief 里的一处疏漏：SyncCodeEditor.vue 挂在每个用户的题目页上，教师也不例外
（ProblemEditor.vue 只按语言是不是 Flowchart 分支，不看角色）。教师接单同样会让
collabStore.room 非空，若不按角色收窄，教师自己停在某道题页面上接单时，这个组件
会把教师自己的编辑器内容当成种子插入文档，还会跟 CollabModal 抢
setBinaryHandler 这个单例槽位。改为 `room && !collabStore.isTeacher` 才起协作，
教师端的协作只归 CollabModal 管。

另外两处修正：
- editorView 用 shallowRef 而非 ref —— CodeMirror 的 EditorView 是带 getter 的类
  实例，ref() 的深度 UnwrapRef 会把它拆成丢了原型方法的假类型，vue-tsc 报错。
- Header.vue 挂 CollabModal 放进根 n-flex 内部而不是同级 —— 组件一旦变成多根
  fragment，default.vue 里 `<Header class="header" />` 的 class 就没有单一根节点
  可以落地，header 行会丢掉居中样式（实测触发了 Vue 的
  Extraneous non-props attributes 警告）。n-modal 默认 teleport 到 body，塞在
  这里不影响其实际渲染位置。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-08-28 07:43:08 -06:00
yuetsh
bfe4468fdb feat(web): 教师顶栏的求助列表 
按题目分组，同题多人时标出人数。按等待时长排序但不强制先来先到 ——
上课时有的问题一句话说清、有的要讲五分钟。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-08-28 06:48:07 -06:00
yuetsh
6f873be367 feat(web): 题目页的「开启同步」换成「求助」 
学生发起求助，状态与排队位置显示在按钮旁。
教师端入口不在题目页，所以对教师隐藏这个按钮。

顺带修正 handleHelpCancel：去掉 request.socket !== ws 的校验。
学生取消自己的求助，不管从他哪个标签页发起都合法——
getRequest(ws.data.userId) 已经把范围锁在这一个用户上了，
不是跨用户操作，不需要再比对是不是同一条连接。这层校验此前
会让「第二个标签页点取消」被服务端静默丢弃，前端却已经乐观
地把按钮变回「求助」，是一处 UI 说谎；现在两边状态一致。
handleCollabClose 里排队分支的 socket 归属校验不受影响，
那里的关闭事件是顺带触发的，仍然需要认出是不是本人这条连接。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-08-28 06:33:25 -06:00
yuetsh
ab8fcc2d42 fix(collab): room_closed 无条件归位、断线重连补状态、学生 socket 重连迁移 
Critical：room_closed 不再按 reason 挑着重置 helpStatus——学生自己的 socket
发送失败时服务端删了请求却发不出任何纠正帧，store 会卡在陈旧的 active/pending
上出不来。现在一律先归 idle，老师掉线那条路径服务端会紧跟着补一条
help_status:pending，同一条连接消息严格按序到达，不会被这次重置抢跑。

Critical：断线重连没有补状态。前端 CollabWebSocket 加 onConnected 钩子，
每次连接建立（含重连）都清空本地 requests/helpStatus/room，等服务端补发；
后端 handleCollabOpen 对非老师的重连方，如果这个账号名下还有请求，
补发对应的 help_status（pending 带重算的 queueAhead，active 带 teacherName）。

Critical：重连后请求仍绑在旧 socket 上，导致 handleHelpCancel 的归属校验
认不出新连接、后续通知也写进死连接。handleCollabOpen 里把请求和（如果有）
房间迁移到新 socket，并清掉旧 socket 的 roomOwnerId，防止它稍后的 close
反过来拆掉刚迁移出去的房间。

Minor：disconnect() 补齐 queueAhead/teacherName/notice 的重置，不留陈旧值。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-08-28 06:01:41 -06:00
yuetsh
17aa69f8a7 feat(web): 课堂求助 store 与全局 collab 连接 
连接全局常驻，不跟题目页起落 —— 老师在任何页面都要能收到求助。
列表按题目聚合，同题多人时能一眼看出该全班讲。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-08-28 05:36:51 -06:00
yuetsh
aef687bcfc fix(api): collab 二进制转发的背压误判与发送失败后的幽灵请求 
Important 1：handleCollabBinary 把 send() 返回的 -1 当成失败，实测证明
-1 只是背压——消息已排队，最终照样送达（8MB 帧原样完整到达）；只有 0
才是真丢。之前 sent <= 0 一触发背压就拆房间，慢网/大粘贴反而先弄死正常
会话。改成只认 sent === 0；同时空 Uint8Array 的 send() 也回 0（送达和
真丢用同一个返回值分不清），先按长度 0 直接忽略，不转发也不参与失败
判定，否则任意一方发一个空二进制帧就能把房间拆了。

Important 2：发送失败后走 teardownRoom("peer_offline") 从不 removeRequest
（只有 reason === "done" 才删），请求卡在 status: "active" 没有房间，
之后 handleReject / handleHelpCancel / handleLeave / handleAccept 全部
因为状态或归属对不上而拒绝处理，那个学生的后续求助永远被静默吞掉。
补上 offlineSide 参数，和教师断线共用同一条收尾路径：老师那侧消失，
请求退回 pending 并清 teacherId/teacherName，学生收到新的 help_status
pending；学生那侧消失，请求整条清掉。两种情况都发 room_closed 并
broadcastRequests()。

Minor：handleHelpCancel 没有 request.socket === ws 校验，同一账号第二个
标签页能取消第一个标签页排队中的请求——和上一轮修的 close 排队分支是
同一类归属漏洞，补上同样的检查。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-08-28 05:28:14 -06:00
yuetsh
457df1ef3c fix(api): collab 房间越权与几处时序/静默丢帧缺口 
Critical：学生排队断线分支补归属+状态校验，避免同账号双标签页
把 active 请求错删、被另一个学生请求顶替后又被别的老师抢建出
第二间房；handleAccept 补 getRoom(studentId) 兜底同一学生 id
下已有房间的情况。

Important：handleAccept 的库查询是个 await 点，之后补上
teacherSockets().has(ws) 判活，教师在等待期间断线不会再对着
死 socket 建房间。

Minor：handleReject 补上和 handleAccept 一致的库复核，堵住
连接存活期间被降级/禁用的教师继续掐请求的口子；
handleCollabBinary 检查 peer.send() 返回值，转发失败时走既有
teardownRoom 拆房间，不再静默丢帧、悄悄分叉两边的代码。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-08-28 02:48:35 -06:00
yuetsh
b14639d890 feat(api): collab 房间管理与 Yjs 帧转发 
accept 时按库里的 adminType 复核身份，房间以学生为键。
服务端只按房间转发二进制帧，不解析内容。
老师掉线请求退回排队，学生掉线请求随人清除。

顺带处理三项 Task 2 评审遗留：
- TEACHER_ROLES 去重，handler.ts 改为从 routes/helpers.ts 导入，不再自留一份
- 补全学生排队中断线（尚未进房间）的清理分支，避免陈旧请求卡死在列表里
- 修正 websocket.ts 里一处过期注释：username/adminType 是三种 kind 都会填，
  不是只有 collab 才填

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-08-28 02:36:12 -06:00
yuetsh
1db2c49b87 feat(api): 新增 /ws/collab 通道与课堂求助控制面 
学生发起/撤销求助，在线教师收到全量列表。求助只在内存，不落库。
二进制帧的限流单独一档，避免协作输入把连接踢掉。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
 2026-08-28 02:24:44 -06:00
yuetsh
c04570b4ad feat(web): BaseWebSocket 支持二进制帧收发 
onmessage 原来无条件 JSON.parse，收到 Yjs 二进制帧会落进 catch。
加 onBinary 钩子与 sendRaw，让 collab 通道能复用基类的重连与心跳。
 2026-08-28 02:06:13 -06:00
yuetsh
f38444c97a fix(代码规则): 给 C 题配的规则一半是哑弹，C++ 题根本配不了
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
后台的节点下拉是一张 C/Python 混在一起的 15 条表，整份铺给每种语言。给 C 题选到
只有 Python 有的 list_comprehension、f-string，规则存得进去，判题时拿裸名去比节点
类型，C 的语法树里永远不存在它——「必须使用列表推导式」永远失败、「不能使用
f-string」永远通过，两头都不报错，只有学生受着。反过来 mappings 支持的 do_while、
switch、struct、include 在表里没有，编辑器根本选不到。

标签表改成按语言分组，和判题机 mappings 的键集逐条对齐；保存时校验规则与语言是否
匹配，不匹配给中文提示。C 的 target 从 8 个可用变成 14 个。

C++ 接上了 tree-sitter-cpp，386 道 C++ 题从此能配规则。它继承 tree-sitter-c 的语法，
C 那 14 个 target 实测全部通用，另加范围 for、类定义、try-catch、throw、namespace、
模板、lambda、using 共 22 个。调用形态和 C/Python 都不同，一并处理：a.push_back()
和 p->push_back() 是 call_expression + field_expression，不是 Python 的 attribute；
std::sort(...) 的 function 是 qualified_identifier 而不是 identifier，所以额外比一次
:: 末段，否则学生写没写 using namespace std 会得到不同判定。

一起收掉的几处：

- Java/Golang/JavaScript 配的规则一条都不会跑，题目页却照常把它们渲染成「要求」
  挂给学生看。现在后台不给这些语言开 tab，下发给学生的要求也按语言过滤。
- 「出现次数」不填数字存下来是一条恒真规则，描述还退化成光秃秃一个「for 循环」。
  切换引擎时给默认值，保存时拦下，读取时整条丢弃。
- 次数规则失败只说「if 条件 出现 2 次 ✗」，学生不知道自己写了几次，补上「当前 N 次」。
  旧栈的引擎其实算了这个数，但 checker 只取 describe，算完就扔。
- must_have_nesting 的文案没走标签表，学生看到的是「必须使用 for_loop 嵌套」。
- 运算符文案给的是逻辑名，C 题的学生看到「必须使用 and 运算符」，而 C 里写的是 &&。

语义校验放在 astRulesError() 而不是 zod 的 refine 上：astRulesSchema 同时用于读后台
题目详情，在读路径上抛错会让历史脏数据把整个题目详情打不开。保存前先 pickAstRules()
剔除够不着的分组再校验，否则早年配过 C++ 规则的题会把老师锁死——tab 里看不到那组
规则，保存却被拦下。

生产库那 17 条规则（全是 Python3 的 must_exist_node / count_node）行为不变，逐条实跑
核对过。C++ 的 22 个节点 target、25 个运算符也逐个跑了，没有恒假的哑弹。改了带 wasm
内嵌的 ast.ts，dev 和编译两种形态都验过。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 11:53:37 -06:00
yuetsh
280443c892 fix
Some checks failed
Deploy / deploy (push) Has been cancelled
Details
2026-08-27 11:26:00 -06:00
yuetsh
77717e439d fix(主题切换): 圆环从视口正中扩散，跟点击的地方对不上
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
深浅色切换的圆环扩散原本把圆心写死在 window.innerWidth / 2，不管点哪儿都从屏幕
正中冒出来。改成取指针落点。

半径也跟着修了。原来是 hypot(x, y)，只量到左上角——圆心居中时恰好是对的，一挪到
按钮（在右上角）就不够长了，右下角会留一大块旧配色等圆环扩过去，看着像没刷新。
现在取到最远那个角的距离。

键盘触发（Enter / 空格）时 clientX/clientY 是 0，照用会让圆环从屏幕左上角冒出来，
这种情况退回按钮自身中心，用 event.detail === 0 判断。

startViewTransition 的降级判断原样保留，机房那批 Chrome 低于 94 仍然是直接切。

实测（钩住 documentElement.animate 看真实关键帧，视口 1280x633、按钮中心 1255,29）：
点正中得 circle at 1255px 29px / r=1392.78，点按钮左上角 (1246,22) 得 at 1246px 22px，
说明跟的是指针不是按钮；键盘 Enter 得 at 1255px 29px，没跑到 (0,0)。三次主题都正确
翻转，无报错。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 11:18:12 -06:00
yuetsh
6c2381ad2c perf(提交列表): 越早的页越慢，最后一页要等 1.2 秒
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
翻页用的是 LIMIT n OFFSET m，而 Postgres 对 OFFSET 没有捷径：前 m 行必须真的
产出再丢掉，丢弃又发生在 join 之后，每一行都白回了一次表。生产快照（10.4 万条
公开提交）实测最后一页 1258ms、碰了 95347 个 buffer。最早那几页平时没人翻，
数据页从来不在缓存里，全是冷读，所以感受上比新的几页慢得多。

改成两步：先只 select create_time / id 数到第 m 行拿游标——这两列正好是部分索引
的全部内容，跳过 m 行走 Index Only Scan，Heap Fetches 为 0，纯在索引页里数数；
再拿这一行做 keyset 回查，只回表取 limit 行。同一页降到约 9ms、885 个 buffer，
端到端 HTTP 10.7ms。代价变成 O(m) 个索引条目而不是堆页，按快照密度外推，
涨到 100 万条时最深一页仍在几十毫秒量级。

接口签名和前端都没动，页码跳转照旧。offset 为 0、以及按题号筛选时（条件在
problem 表上，第一步得跟着 join，index-only 就没了）退回普通 offset。

部分索引从 (create_time) 换成 (create_time, id)：create_time 由
new Date().toISOString() 生成，只有毫秒精度，不是全序，游标用 <= 回查时同毫秒的
上一页末行会重复出现在下一页页首。加 id 之后两步走同一个顺序。索引 2.3MB → 6.9MB。

索引两列都建成默认 ASC，靠 Index Only Scan Backward 反着扫。别照着 ORDER BY
写成 (create_time DESC, id DESC)：ORDER BY 的 DESC 默认 NULLS FIRST，索引的 DESC
默认 NULLS LAST，规划器认为出不了序，会退化成 external merge sort（5.2MB 落盘），
比不加索引还糟。这一条已写进 schema.ts 和迁移文件的注释。

正确性：在快照上把新旧写法返回的 id 序列逐页比对，14 个 offset × 4 个 limit
共 56 组全部一致，含末尾残页与越界。

比赛提交列表暂不改：单场比赛撑死几千条，offset 不构成问题。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 11:13:38 -06:00
yuetsh
8861393529 fix(流程图): 评分明细的顺序是乱的，40 分的那项排在最后
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
AI 是按分值从高到低返回的：`逻辑正确性(40) → 完整性(30) → 规范性(20) → 清晰度(10)`。
但 `ai_criteria_details` 存在 jsonb 列里，而 Postgres 的 jsonb **不保留键序** ——
它按「键长度 + 字节序」重排，读出来变成 `完整性 → 清晰度 → 规范性 → 逻辑正确性`，
权重最高的那项被排到了最后。

评分弹框和教师端的评分详情都是直接 `v-for` 遍历这个对象，所以两处都乱。
统计面板因为用的是写死的 `CRITERIA_ORDER`，一直是对的 —— 于是同一份数据在两个
地方的顺序还不一致。

把顺序抽到 `utils/constants` 共享，三处统一走 `sortFlowchartCriteria()`；
表里没有的键排到后面，AI 万一返回别的评分项也不会丢。

顺带把限流的提示改得能看懂：撞上 429 时原来只显示「流程图提交失败」，学生会以为
是自己的图有问题然后反复点，越点等得越久。现在按错误码分支，提示「提交太频繁了，
缓一会儿再交」。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 10:53:29 -06:00
yuetsh
e921506f40 fix(流程图): 「重新判题」从来没成功过，而且会把原来的评分清掉 
`bullmq` 对自定义 jobId 有一条兼容老式可重复任务的校验：一旦包含 `:`，就必须
正好切成三段（`job.js` 里的 `split(':').length !== 3`），否则抛
`Custom Id cannot contain :`。

- 代码提交的重判用的是 `${id}:rejudge:${时间戳}` —— 三段，能过；
- 流程图的重判用的是 `${id}:${时间戳}` —— **两段，必抛**。

所以这个接口从上线起就没有成功过一次。更糟的是清空评分发生在入队**之前**：

    await db.update(...).set({ status: 0, aiScore: null, ... })
    await flowchartQueue.add(...)   // ← 在这里抛，500

每点一次「重新判题」，原来的分数、等级、反馈、评分明细就永久丢一次，提交卡在
PENDING，队列里没有任何任务会来救它，老师看到的只是「重新评分失败」。

改成三段式 jobId，并把入队失败落成 FAILED（而不是留在 PENDING）——
与 `POST /flowcharts` 的处理保持一致。

之前几轮验证没发现，是因为当时手上只有一条 PENDING 的提交，被 409（状态不允许
重判）挡在了入队之前，正好绕开了这个 bug。这次完整走教师流程才撞上。

实测：修复前点重判 → 前端「重新评分失败」、库里 status 变 0 且分数清空、
api 日志抛 `Custom Id cannot contain :`；修复后 → 「重新评分已提交」，
70分B级 重评为 86分A级。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 10:51:00 -06:00
yuetsh
e00ab7b876 perf(流程图统计): 给词云的分词量封顶
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
统计接口会把时间窗内所有已完成提交的 criteria / feedback / suggestions 全取回来，
逐条走一遍 jieba。而前端的「全部时段」是不带 start 的 —— 攒一学年就得把所有评语
重新 cut 一遍，而这是个同步阻塞的请求。

只给词云的分词条数封顶（3000），并按时间倒序取，留下的是最近的那批。

**数值不封顶**：总数、均分、等级分布、各项平均分、完成人数仍然按整个时间窗精确
计算 —— 那只是已取回行上的算术，不额外花钱。这些数一旦采样，老师看到的完成率和
均分就是错的，而且从界面上完全看不出来；词云是辅助性的，看的是高频问题，取最近
这些条足够。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:27:33 -06:00
yuetsh
74d3b97f05 feat(流程图列表): 补上状态列，重判按钮按状态置灰 
教师端的流程图提交列表一直没有状态列。「排队中」「评分中」「评分失败」三种情况
在界面上长得一模一样 —— 都只是分数栏空着，老师分不出是还没评完还是评失败了。

三处一起改：

- 加状态列（排队中 / 评分中 / 已完成 / 评分失败）。
- 分数列只在已完成时渲染 Grade。原来无论什么状态都渲染，没评完会显示成 0 分，
  看着像「评了但得了 0 分」。
- 重判按钮按状态置灰。后端只接受已完成 / 已失败的重判（其余返回 409），
  原来是点了才知道不行。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:27:33 -06:00
yuetsh
f5ad5318a0 fix(流程图编辑器): Ctrl+Y 没接、清空画布不问一声、存档里塞满 vue-flow 内部字段 
## 存档里的一大半是运行时内部状态

画布上的 node 是 vue-flow 的 GraphNode，除了我们自己塞的字段，还挂着
`dimensions` / `computedPosition` / `handleBounds` / `selected` / `dragging` /
`resizing` / `initialized` / `isParent` / `events`（见 vue-flow 的 parseNode）。
这些会跟着一起写进 localStorage、进 20 份历史快照被反复深拷贝、还压缩后提交进
数据库**长期存着**。而重新挂载时它们全都会被重新算一遍 —— 存下来没有任何意义，
还把存档格式和 vue-flow 的内部实现绑死了，将来升级或迁移数据都得跟着动。

`handleBounds` 尤其占地方：一个循环节点有 4 个 handle，每个 6 个数字。

抽一个 `serialize.ts`，落盘/入历史/提交前统一裁成 id / type / position / data /
style 五个字段。`style` 保留 —— 它是建节点时按类型算好的，丢了恢复出来的图会变样。

实测：一个两节点带连线的图，存档 600 字节、节点上只剩那五个字段，九个内部字段
一个不剩；提交上去压缩后 396 字节。

## Ctrl+Y 是假的

工具栏按钮的 title 写着「重做 (Ctrl+Y)」，但只实现了 Ctrl+Shift+Z，按 Y 没反应。
顺手把 key 比较改成小写不敏感（按住 Shift 时 event.key 是大写的 "Z"）。

## 清空画布点一下就没了

那个按钮不但清空画布，`clearCache()` 还会把这道题存着的草稿一起删掉，刷新也找
不回来。学生误点的代价太大，加一道确认；画布本来就是空的时候不弹。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:27:19 -06:00
yuetsh
9e41855610 fix(流程图): 点进去空白的 tab、以及「渲染成功」这个只进不出的开关 
## 两个开关同时打开会做出一个空 tab

后端在 `allowFlowchart` 为真时把 `mermaidCode` 置成 null（不能把标准答案下发给
正要自己画图的学生，见 routes/problem.ts）。而前端 `tabOptions` 只看
`showFlowchart` 就把 "flowchart" 加进选项，面板那边却要求
`showFlowchart && mermaidCode` —— 两个开关都打开时，选项存在、面板不存在，
URL 里带 `?tab=flowchart` 就会选中一个渲染不出任何东西的页签。

三个断点条件还各不相同（两处要求两者都有，第三处只看 showFlowchart，那处会拿
null 去渲染 ProblemFlowchart）。统一成一个 `canShowFlowchart`。

后台那边把「显示标准流程图」在允许提交流程图时置灰并说明原因，再补一个 watch
把存量数据里两个都开着的情况纠正掉 —— 它们本来就是互斥的。

## 「渲染成功」只进不出

保存前的校验靠 `mermaidRenderSuccess`，而 MermaidEditor 只在成功时 emit、
这个 ref 也就只会从 false 变 true，永不复位。**先写对、再改坏，照样能存进库。**

改成上报渲染结果本身（`render-state`），并在 modelValue 一变就立刻打回
「未验证」，等防抖后的渲染真跑完再报结论 —— 只挂防抖那一支的话，改完 300ms 内
点保存读到的还是上一次的结论，刚改坏的代码会被当成校验通过。宁可让出题人多等
一下，也不能放脏数据进库。

实测：改动后 50ms 读到 false（此时保存会被拦），渲染完成后回到 true；
贴一段坏语法则一直是 false。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:27:02 -06:00
yuetsh
d10172f017 fix(流程图): 节点名里带一个双引号，生成的 mermaid 就是坏的 
节点和连线的标签是学生自己敲的任意文字，而转换器是直接把它塞进 `"..."` 里：

    ${nodeId}(("${label}"))

出现一个双引号就把语法撑破了。后果不只是图渲染不出来 —— 这段坏掉的代码会**原样
提交给 AI 打分**，学生完全不知道自己被扣分是因为一个引号。把 `说"你好"` 当节点名
是很自然的写法。

改用 mermaid 的实体转义。`#` 必须先转，否则标签里本来就有的 `#quot;` 之类会被当
成实体解释；换行转成 `<br/>`，不然会截断整条语句。

实测：`说"你好" #1` 现在生成 `说#quot;你好#quot; #35;1`，渲染出来仍然显示
`说"你好" #1`；未转义的那版渲染报语法错误、一个 svg 都出不来。

顺带补上 `edges` 的空值保护 —— `nodes` 有，`edges` 一直没有，拿到 undefined 直接抛。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:26:45 -06:00
yuetsh
0392445dd2 fix(流程图): 补上几处静默失败 —— 点了没反应、弹框永久转圈 
`utils/api.ts` 的拦截器只对 login-required / account-disabled / permission-denied
弹提示，其余业务错误一律静默 reject。而流程图这一块的调用点基本都没 catch，
于是失败时用户什么都看不到：

- **重新判题**：后端会拒掉还在评分中的提交（409 retry-not-allowed），也可能撞上
  限流。老师点下去完全没反应，连报错都没有。实测修复前 0 条提示，修复后弹出
  「这条还在评分中，等出了结果再重新评分」。
  提示按**错误码**分支而不是 match 文案（`utils/api.ts` 里写明的约定）——
  后端文案是英文的，直接弹给老师看不合适。
- **课堂统计**：请求失败后图表停在旧数据上，没有任何迹象表明这次没拉到。

同一批里 `SubmitFlowchart` 的三处（弹框翻页、打开评分详情、加载到编辑器）随
上一个提交一起改了，问题是一样的：前两处失败时 `rendering` 卡在 true，弹框
永久转圈。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:15:11 -06:00
yuetsh
5480abaaea fix(流程图编辑器): 换题草稿串题、第一步撤销不了、历史存的是改动前的状态 
## 换题时画布不跟着换

storage key 是按题目 ID 算的 computed。`useStorage` 确实会 watch key，但它只把
新 key 的内容读进 `storedData`，**不会回填 `nodes`/`edges`**，而 `loadFromCache()`
只在 onMounted 调一次。于是同名路由换参数（题目 → 题目，组件不重新挂载）时，
画布上还留着上一题的图；学生一动，防抖保存就把上一题的内容写进**这一题的 key**，
把原本存着的草稿覆盖掉。

补一个 key 的 watch，重新载入并在载不到时清空画布。这里依赖 `useStorage` 内部
对 key 的 watch 先于本 watch 执行 —— 两者都是 pre flush，且 useStorage 在上方
先创建，pre 队列按创建顺序跑，此刻 `storedData` 已经是新 key 的数据。

实测（router.push 直接切题）：修复前 1003 的画布上挂着 1002 的节点，修复后
1003 是空的、1002 的草稿完好。

**需要说明**：今天的 UI 走不到这条路 —— 题目页没有「下一题」入口，题单和比赛
切题都要先回列表页（不同路由、组件会重新挂载）。所以这条目前是加固，一旦以后
加了题内切题入口就立刻变成必需品。

## 撤销少一步、存的还是旧状态

`historyIndex` 从 -1 开始，而 `canUndo` 要求 `index > 0`，第一步操作永远撤销
不了。补 `resetHistory`，挂载时和换题后各播一次初始快照（换题不重建的话，一次
撤销会把上一题的图还原到这一题里）。

`addEdges` / `removeNodes` / `removeEdges` 之后紧接着 `saveState(nodes.value,
edges.value)` —— 而 vue-flow 的 store → v-model 回写走的是 `watchPausable`
（pre flush，异步），此刻读到的还是**改动前**的数组，存进历史整体错开一步。
画布上的 `handleDrop` 早就 `await nextTick()` 了，这几处一直漏了；
`clearCanvas` 因为是直接赋值 model ref（同步）反而是对的 —— 所以这套行为一直
是「有时对有时错」，更难排查。

顺带：`handleNodeDelete` 里手动删相连边是多余的，`removeNodes` 的
`removeConnectedEdges` 默认就是 true；`deleteSelected` 在什么都没选中时不再
白记一条历史。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:14:59 -06:00
yuetsh
5f0fe713dc fix(流程图渲染): 出错后再也画不出来、每失败一次往 body 漏一个 div 
## 渲染失败后永久空白

四个渲染点都是同一个写法：

    <n-alert v-if="renderError" ... />
    <div v-else ref="mermaidContainer"></div>

一旦渲染出错，容器被 `v-else` 卸载，`mermaidContainer.value` 变成 null。而
`renderFlowchart` 一进来就先清 `renderError`、再因为 `!container` 直接 return ——
于是**报错提示消失了，图也再画不出来**，只剩一块空白，只能刷新页面。翻历史提交
最容易踩到。改成容器常驻、用 `v-show` 隐藏，和 MermaidEditor 本来的写法一致。
`FlowchartScoreDetail` 那处 Teleport 上不能挂 v-show，把条件挪到内层容器。

实测：修复前切回合法代码后 0 个 svg（永久空白），修复后正常渲染。

## 每次渲染失败都往 body 漏一个 div

`m.render(id, code)` 没传容器，mermaid 会在 `document.body` 上建一个临时
`div#d{id}`。而 `suppressErrorRendering` 默认关着，看 mermaid 源码，解析出错时
是先 `errorRenderer.draw()` 再 `throw`，**清理临时容器的那行在 throw 之后**，
永远执行不到；每次 render 用的又是新的随机 id，`removeExistingElements` 也清不掉
旧的。于是渲染失败一次就留一个。

出题页是边敲边预览，且没有防抖，每个字符触发一次完整渲染，中间态几乎全是语法
错误 —— 实测逐字符敲 26 个字符，body 里留下 16 个残留 div。打开
`suppressErrorRendering`（该分支是先清理再抛）+ 预览防抖 300ms，实测降到 0，
预览功能不受影响。

## 顺带

`loadMermaid` 缓存的是实例，两个组件同屏挂载时会双双落进 `if (!mermaidInstance)`，
import 和 initialize 各跑两次。改成缓存 Promise，并在失败时清掉缓存，避免一次
网络抖动把后续所有渲染都钉死在这个失败结果上。

`SubmitFlowchart` 的 `updatePage` / `openDetailModal` / `loadToEditor` 一并补了
错误兜底（同文件，见下一个提交的说明）：前两个失败时 `rendering` 会卡在 true，
弹框永久转圈；`loadToEditor` 是裸 `JSON.parse`，老提交数据坏掉就点了没反应。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:14:40 -06:00
yuetsh
c27c9fdbf9 fix(流程图评分): 队列重试从没生效过、AI 调用不设超时、等级由模型自报 
## 重试是摆设

`flowchartQueue` 配了 `attempts: 3` + 指数退避，但任务开头有一道守卫：

    if (!row || ![0, 1].includes(row.flowchart.status)) return

而 catch 里第一件事就是把 status 写成 3(FAILED)。于是第 2、3 次尝试进来一看
状态是 3，直接 return、算作成功 —— **实际只跑了一次**。AI 侧的偶发失败（限流、
超时、网络抖动）永远等不到重试，学生看到「评分失败」只能自己重新提交。

改成只有最后一次尝试才落 FAILED，中间几次把状态留在 PROCESSING(1) 让守卫放行。
「是不是最后一次」由 worker 算好传进来：`attemptsMade` 是「此前已失败几次」，
当前这次还没计入，所以判据是 `attemptsMade + 1 >= attempts`。

实测（用没配 AI_KEY 这条必然失败的路径）：修复前 t+1s 就落 FAILED、只评一次；
修复后评满 3 次，状态到 t+7s 才落 FAILED。

## fetch 不设超时

`completeChat` 直接 `fetch`，而 fetch 默认不超时。AI 侧一挂就把 worker 的并发位
（只有 2 个）一直占着，学生那边的按钮也就一直转。加 60 秒超时。

流式调用**不加**：那边超时会把正在推的长回答直接掐断，而客户端断开本来就能收尾。

## 等级不该由模型说了算

提示词里写死了 S/A/B/C 四档分数区间，但模型偶尔会给出「88 分配 S 级」这种自相
矛盾的结果，甚至直接吐「优秀」。脏值会一路串到等级分布图、等级筛选，以及
「A/S 才把流程图展示给学生」的判断里。改成一律由分数推出等级，模型自报的 grade
不再采信；score 本来就已经 clamp 到 0-100。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:14:21 -06:00
yuetsh
8f08ed03a0 fix(流程图): 学生能翻出全班评分、AI 调用没有限流 
## 列表漏了一道门

代码提交列表在 `routes/submission.ts` 里有 `submission_list_show_all` 兜底：
关掉时非管理员一律返回空。流程图列表**从来没有这道门**，而它的过滤是

    if (myself === "1" || (!username && 是普通用户)) 只看自己
    else if (username) 按用户名模糊匹配

—— 只要带上 `username`，第二支就把第一支的限制绕过去了。学生在提交记录页把
语言切成「流程图」、用户名框随便填一个字，就能翻出全班同学的 AI 评分，不需要
动接口。补上和代码提交同一套口径。

## 提交与重判没有限流

每一次流程图提交都会触发一次外部 AI 调用，是和判题沙箱同级的有限资源，而这两个
入口都没限流。`canView` 还允许**本人**重试自己的提交，等于学生可以对着自己的
提交反复点，无上限地刷 AI 调用。

限流桶不能直接用 `throttling:user:<id>` —— 那是代码提交在用的桶（capacity 20，
回填约 1.8 个/分钟），共用的话学生在机房连着交几次代码，流程图这边就会莫名其妙
交不上去。单独开 `throttling:user:flowchart:<id>`。

重判对教师放行：成批点几十行是他们的正常用法。

## 提交编号的权限判断在前端自己算了一遍

契约里 `flowchartListItem.showLink` 是后端逐行下发的（与 `GET /flowcharts/:id`
的放行条件同源），前端却没用，自己按「超管或本人」重算了一次 —— 教师因此看得到
「重新判题」却打不开评分详情。

更要命的是无权限那一支渲染的 `n-text` **照样挂着 @click**，权限判断只改了外观。
学生点别人的编号，后端以 404 挡下，`loadSubmission` 只 console.error，于是弹出
一个 600px 高的空白面板，什么提示都没有。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 06:14:05 -06:00
yuetsh
64facc5701 fix(WebSocket): 断线不重连、评分结果会丢、登出后连接还活着
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
排查 WS 这一块时发现的一批问题，多数是「机制写了但从没生效过」。

## 重连

`disconnect()` 里 `enableAutoReconnect = false`，而 `connect()` 从不改回 true ——
登出再登录后，这条连接就永远失去了自动重连能力（configUpdate 那条 watch 上尤其
明显）。改成用 `closedByUser` 表达「用户主动断开」的意图，和 `enableAutoReconnect`
这个**配置**分开。

`scheduleDisconnect` 的回调里断完紧接着一句 `enableAutoReconnect = true`，而
close 是异步的 —— 等 onclose 跑到时标志已经翻回来了，1 秒后又自动连上。那个
「15 分钟空闲省资源」从来没真正断开过。现在只断开，不做事后翻转。

重连的 setTimeout 没存句柄，组件卸载后照样触发 `connect()`，在已销毁的组件上
又建一条连接。现在 `disconnect()` 里 clearTimeout。

退避从「线性 ×5 次」改成「指数 + 抖动、30 秒封顶、次数不封顶」。原来 1+2+3+4+5
只有 15 秒，后端 deploy 重启一次就超了，之后这条连接死到用户刷新为止。抖动是
为了避免一个班几十台机器在同一毫秒一起冲回刚起来的后端。另挂 online /
visibilitychange，网络恢复或切回标签页立刻重连，不必等退避走完。

所有 socket 回调改成闭包住局部 ws 并在入口 `if (ws !== this.ws) return`，旧连接
迟到的 onclose 不再污染新连接的状态 —— 也是让 `disconnect()` 能被 onclose 识别
出来的关键。

## 订阅重放

`pendingSubmissionId` 一发送成功就清空，它只解决了「还没连上就 subscribe」，
**没解决断线重连**。而真正会丢结果的恰恰是后者：服务端收到 subscribe 会回一份
当前状态，掉线期间错过的推送就是靠这次重放补回来的；不重新订阅，重连后只收得到
「将来」的事件，可结果已经是过去式了。改成订阅意图保留到显式 `unsubscribe()`，
每次 onConnected 都重发。

这套逻辑原来只有 SubmissionWebSocket 有，FlowchartWebSocket 是 send 失败打一行
日志了事 —— socket 一掉，那次评分结果就再也回不来，按钮一直转圈。提成公共基类
SubscribingWebSocket，两条通道共用。

流程图另加轮询兜底：提交后 5 秒 WS 还没出结果就每 3 秒拉一次，读 status 2/3
结算，3 分钟上限。判题那边一直有兜底，流程图这边没有，而 Redis pub/sub 是发完
不管的，worker 推的那一刻连接不在就永远丢了。

`useSubmissionMonitor` 里 `watch(wsStatus, ..., { immediate: true })` 的回调在
watch() **返回之前**就同步跑了，已经连着时 `unwatch` 还是 null，if 不成立，
watcher 永远停不掉：每提交一次泄漏一个，往后每次重连它们都会把各自那个早就判完
的旧 submissionId 重新订阅一遍。整块删掉，直接 subscribe —— 基类已经管了时序。

WS handler 原来不校验 submissionId。学生同时开着几道题的页面时，每条连接都订在
同一个用户 topic 上，别的页面的评分结果会被当成自己的。

## 会话

握手时校验过一次会话就再也不管了，这条连接却能挂几个小时：用户在别的标签页
登出、或者会话本身到期，旧 socket 照样收推送。加一条 60 秒一轮的巡检，用
Redis EXPIRE 一条命令同时完成「判断存在」和「续期」（续期是必要的：只开着页面
挂 WS 的人一次 HTTP 请求都不发，不该被算成不活跃踢下线）。Redis 抛错时整轮
放弃，绝不因为一次抖动把全班踢下线。

禁用只改数据库的 isDisabled 列、不动 Redis 里的会话，巡检永远发现不了。加
`session:revoked` 频道主动通知，**两种作用域不能混**：

    { token }   用户登出。只断这一张会话 —— 同一个人在别的设备上是另一张
                会话，按 userId 广播会把他手机上的登录一起踢掉
    { userId }  账号被禁用。所有设备都得断

先发一帧 force_logout 再隔 100ms 断开。只断不发的话前端只看到一次普通掉线，
会照常重连、页面上还显示着登录态。token 不进帧里 —— 那是 httpOnly cookie 的值，
推到 WS 上就等于交给了 JS，匹配全在服务端做。

前端在协议层拦截 force_logout（和 pong 一样，不下发给业务 handler），并主动
disconnect —— 否则会一路 401 重连到退避上限，正是这机制要消掉的浪费。表现刻意
和 utils/api.ts 里 account-disabled / login-required 两支保持一致：同一件事从
HTTP 和 WS 两条路进来，学生看到的不该有两个样子。

## 开销与安全

`void handleMessage(...)` 是裸的，里面有两次 DB 查询和一个会抛的 schema.parse，
库抖一下就是一个 unhandled rejection（隔壁 bridgeSubmissionEvents 两处都接住了，
只有这里漏了）。

ping 提到用户查询之前。原来的顺序是「先查 user 再看消息类型」，每个客户端每
30 秒都要为一次心跳打一趟数据库。禁用用户不会因此漏网：推送路径上 bridge 会查，
subscribe 这条真正读数据的路径下面照样查。

bridge 两条 per-user 通道都先看 `server.subscriberCount(topic)`，没人订阅就别
查库了 —— 判题高峰期绝大多数事件的目标用户此刻并不在线。

flowchart 评分失败原来把 error.message 原样推给学生、前端直接弹出来，AI provider
的地址和内部报错就这么进了浏览器。改成真实原因写服务端日志。

加每连接令牌桶（20 突发 + 每秒回填 2）。一条 subscribe 在服务端是一到两次数据库
查询，一个学生开着一条 socket 狂发就能压住库。正常流量离阈值几十倍远。

升级时校验 Origin。会话 cookie 是 SameSite=Lax、WS 握手不是导航，跨站页面本来就
带不上 cookie，所以这是防御纵深不是唯一防线。同源放行；本机开发（Vite 5173 →
API 3000）自动放行，且只在两边都是本机时成立 —— 生产环境 url.hostname 是正式
域名，这条永远不触发；跨域部署走 ALLOWED_WS_ORIGINS。不发 Origin 的一律放行：
真正的攻击面是带着受害者 cookie 的浏览器页面，而浏览器一定会带 Origin。

顺带：useConfigWebSocket 的 handler 从 onMounted 挪到同步注册（调用方在 setup
阶段就 connect() 了），删掉每条消息打完整内容的 console.log 和死字段
ws.data.username。

## 没动的

题目页上并没有两条 /ws/submissions —— Form.vue 里 SubmitFlowchart 和 SubmitCode
是 v-if/v-else，互斥。学生实际是 2 条连接：全站一条 /ws/config + 一条
/ws/submissions，正常，不必合并。

## 验证

55 个用例，分六组打桩跑（假 WebSocket + 假计时器；会话/限流/吊销三组对着真
Redis）：

    重连语义        7   断开后不再自我复活、卸载后计时器已取消、退避封顶、
                        online 立即重连、旧 onclose 不污染新连接
    订阅重放        9   未就绪时补发、重连后重新订阅、unsubscribe 后不再重放
    会话巡检        8   EXPIRE 三态、只断失效的、同 token 只查一次、
                        Redis 抖动时一个都不踢
    Origin/限流    13   跨站与跨端口拒绝、生产不因 localhost 开后门、
                        突发额度、按时间回填
    强制登出       13   登出只断同 token（别的设备不受牵连）、禁用断所有设备、
                        巡检先通知再断
    前端登出        5   两支表现、收到后不再重连、两条通道只处理一次

前两组做了改动前/后对比，老代码该挂的都挂了 —— 「重连后自动重新订阅」正是这么
跑出来的，此前我以为 pendingSubmissionId 已经覆盖了这种情况。

apps/api 的 tsc 和 apps/web 的 vue-tsc 都干净，仓库既有测试照常通过。

**SubmitFlowchart.vue 的轮询兜底未经运行时验证** —— 在 SFC 内，没搭组件挂载
环境，只过了类型检查和人工核对。要验的话，停掉 worker 提交一次流程图，看 5 秒
后是否转入轮询、3 分钟后是否给出超时提示。

这批改动动了 WS 的行为面（限流会断连接、Origin 会拒绝、巡检会踢会话），上线前
建议手测：提交代码看判题、切流程图看评分、后台改配置看全站生效、开两个标签页
在一个里登出、禁用一个在线学生看另一端反应。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 05:07:26 -06:00
yuetsh
47a43b9880 fix(提交列表): 转圈圈延迟 300ms 出现，快请求不再闪一下
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
翻页、切筛选大多一百毫秒内就回来了，转圈圈闪一下再切数据比直接切更晃眼。
给 loading 加一层延迟：只有真的慢到 300ms 以上才显示。

是**单向**延迟 —— 只推迟「显示」，请求一结束立刻收掉，不留尾巴（用
refDebounced 之类的双向去抖会在数据到了之后还多转 300ms）。

没有用 n-spin 的 delay：n-data-table 压根不走 n-spin，它渲染的是内部的
_internal/loading，直接由 loading 控制、没有 delay 参数。要用内置的就得把表格
包进 <n-spin :show :delay> 再去掉 :loading —— 那会换掉加载样式，还会丢掉
loading 时锁住排序/分页交互（DataTable 里那个 `disabled: this.loading`）。
这几行就是 n-spin 内部同样的写法，理由写在注释里了。

验证：headless chromium 走 CDP，只给 /api/submissions 加延迟（给全站加延迟的话
dev 模式几百个模块请求全被拖慢，页面根本起不来，第一次就是这么测出假结果的），
每 120ms 采一次 DOM：

    API 不加延迟   转圈圈全程没出现，表格直接 0 行 → 5 行
    API +800ms     表格 291ms 挂上 → 654ms 转圈圈出现（挂载后约 300ms）
                   → 1138ms 数据到位 → 1381ms 收掉

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 00:53:40 -06:00
yuetsh
6ac458e6f3 refactor(WebSocket): 判题/流程图推送改用驼峰，去掉没人读的三个字段 
submission_id / time_cost / memory_cost / err_info 是 OJ2 两端自己定的线上格式，
没有第三方消费（/ws/submissions 只有 apps/web 一个客户端），没理由留着 snake。
flowchart 那条更别扭：同一个对象里 submission_id 是 snake、criteriaDetails 是驼峰。

三个字段直接删掉而不是改名 —— 它们是从 statistic_info 原样抄出来的一份，前端
一处都没读过（useSubmissionMonitor 只用 submissionId / result / status）。耗时和
错误信息在提交详情里本来就有，判完了去拉一次就是，不必让推送顺带背一份 JSONB
的形状。score 保留，它不涉及大小写。

**没动的都是有外部约束的**，别顺手一起改：

- 发给判题沙箱的请求体（language_config / max_cpu_time / max_memory /
  test_case_id / io_mode）和它回的字段（cpu_time / memory / test_case）——
  那是沙箱的 API，不是我们的
- 测试点 info 文件的键，沙箱直接读那个文件
- submission.statistic_info 里的 time_cost / err_info / ast_results ——
  判题机按这套写，12 万条历史提交就是这形状
- acm_problems_status、progress_detail 这些存量 JSONB
- AST 规则键（for_loop）、成就指标（accepted_count）、reaction 语义键 ——
  那是词汇表标识符不是字段名，for_loop 还要映射到 tree-sitter 的 while_statement

验证：起 dev 栈（api + worker + 沙箱），学生账号真提一次代码，抓 /ws/submissions
的帧：

    {"type":"submission_update","submissionId":"bf13b7f0…","result":6,"status":"pending"}
    {"type":"submission_update","submissionId":"bf13b7f0…","result":7,"status":"judging"}
    {"type":"submission_update","submissionId":"bf13b7f0…","result":-2,"status":"finished","score":0}

subscribe 帧也换成 submissionId 并被接受（否则会回一个 error 帧，没有）。
流程图那条路径要 AI 评分才跑得起来，本机没配，只做了类型检查。

前后端同一个 docker 栈一起构建部署，没有版本错配窗口。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 00:48:54 -06:00
yuetsh
bc0b782443 update
Some checks failed
Deploy / deploy (push) Has been cancelled
Details
2026-08-27 00:42:39 -06:00
yuetsh
8ae14f055a refactor(站点配置): WS 直接推契约字段名，去掉前端那层 snake→驼峰胶水 
上一版是在前端加 toCamel 把 `enable_maxkb` 换成 `enableMaxkb`。但 snake_case
是 options 表从 Django 继承来的**存储格式**，只该活在库里；WS 这一跳两边都是
OJ2 自己写的，没理由让前端再维护一层换名。

后端改成广播 OPTION_KEYS 的 key（契约字段名）而不是 value（表列键），前端直接
按名字赋值。库里的列名一个字没动。

顺带清掉两处已经死掉的客户端→服务端配置推送：

- admin/setting/config.vue 保存后调 updateConfig("enable_maxkb", ...) 和
  ("submission_list_show_all", ...)。那条 ConfigWebSocket 从没 connect() 过，
  send() 直接返回 false；就算连上了，服务端的消息处理也只认 ping / subscribe，
  会回一个 error 帧。广播本来就由后端在 POST /admin/website 里做，八个键一个
  不落，这两行纯属多余，且用的正是刚废掉的 snake 键。
- ConfigWebSocket.updateConfig 一并删掉，免得再有人调一个静默失败的方法。
  这条通道是单向的，原地留注释说明。

验证：dev 栈 + headless chromium 走 CDP 抓 Network.webSocketFrameReceived。
后台保存配置后，页面收到的八条帧的 key 全是驼峰（websiteName / enableMaxkb
/ submissionListShowAll ...），且页面不刷新，document.title 和页头站点名当场
跟着变。小助手那四条路径重跑一遍照旧：未登录不加载、登录后出现、后台关掉当场
消失、开回来当场重现。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 00:42:14 -06:00