xuyue and Claude Opus 5.5
ed7752afbb
feat(题目列表): 学生自己挑题时只看得到一堆标签和提交数，不知道自己练到哪了——改成左栏知识点进度、顶上先说做到了什么
...
Deploy / deploy (push) Canceled after 0s
- 左栏是知识点（可切到主题）和自己的进度：做了一部分写 37/96 加进度条，全做对写「通关」，
一道没做对过的只写题数，不再是一整列 0/108
- 顶上一行：做对几道 · 这周 +n（或连续几周都有做对）· 离哪个成就最近 ·「有 n 道差一点」
（点开才列出来）；新生引去「输出入门」；一言照旧在右边
- 每题最后一列是做对 / 做过的人数，代替提交数和按提交算的通过率（和题目页统计同一个口径）
- 「画流程图 / 语法要求 / 有参考图」挂在题目名后面，「全部类型」下拉单独筛这三类，
不再混在排序里；题目页的「代码要求」统一叫「语法要求」
- 「只看没做完」开关（默认关）、「随便来一道」（当前知识点里先挑没做对的简单 / 中等题）
- 画流程图的题，流程图评到 A / S 在状态列也打勾，和题单、课堂条一个口径
- 老师看不到状态列和个人进度；出题者筛选保留
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-10-09 12:31:49 +08:00
xuyue and Claude Opus 5.5
e7b95d211d
fix(题目): 修掉题目页重构审查查出的问题——提交途中换题会把结果算到新题上、运行例子把对的菱形判错、点评完「下一题」不跳等
...
题目页重构之后按「功能对照 / 状态 / 结果页 / 布局与后端」四路审查了一遍，查出的问题一起修：
提交与换题
- 提交、画流程图途中换题：A 题格式化好的代码会盖掉 B 的草稿，A 判对了把 B 标成已解决、
弹 B 的点评、题单里跳回题单。现在每个请求回来先核对题目，轮询和推送回来的也核对提交编号
- 画着流程图换到不能画的题，语言退到题目的第一门、还被记成偏好；现在回到学生习惯的那门
- 强制点评评完点「继续 / 下一题」，学生之前在看「题目」页签的话会停在原题
- 离开题目页之后判题、流程图的 WebSocket 一直连着，现在闲 15 分钟断开
运行例子
- 输出开头的空格被削掉，打印菱形这类题对的代码也显示「没对上」
- C 的编译警告拼进了「你的输出」（后台生成测试点也会写进 .out）
- Python 的语法错误（中文标点）被说成「下标有没有越界、除数是不是 0」
- 比赛里仍然把空格画成「·」、把不同的地方标红
入口与协作
- 比赛里不给「课堂统计」、不绑协作：房间和统计都按题号找，比赛题号和公开题撞号
- 「看他交过什么」按整名匹配，不再混进学号相近的同学
- 协作中点上下文条、相似题、下一题开新标签，协作不断
- 题单入口给管理员的「⋯」里留「本题提交」
结果与题面
- 「去自己输入拿 51 这些数试试」取到了题面 HTML 里的颜色值；「题目原话」露出 "
- 流程图 A 级的学生标题下还写着「还没交过」
- 「我的提交」上方补回「答案错误 × 3」这样的计数
- 流程图历次评分能点开看那一版的图；读分数失败不再说「还没交过流程图」；手机上能看流程图点评
- 「结果」页签有新结果没看时加粗上色，看过就恢复
- 空画布拖进第一个节点画布会跳一下；画布底下空着一条
- 比赛没开始写成「已结束」、倒计时超过一个月算错；分隔条拖到头工具栏被挤坏；题单里的题目页有备案页脚
- 流程图历次分数只读需要的几列（一个学生一道题 23 次提交：96 kB → 2 kB）
- 比赛密码、比赛没开始等几条学生看得到的英文报错换成中文
设计文档照实际做法更新了第 5.5、5.6、6、8、9、10、11 节。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-29 00:07:16 +08:00
xuyue and Claude Opus 5.5
83b6b7a81a
fix(题目): 修掉代码审查查出的几处问题——流程图拿到的徽章不弹、点评弹窗读失败时关不掉等
...
- 流程图画到 A / S 拿到的题单徽章、成就原来不弹：流程图那条 WebSocket 只认评分完成 / 失败，
成就消息被丢掉了，要等下次换路由拉 pending 才出来
- 强制点评弹窗读不出点评、或者一直交不上时，「下一题 / 继续」按钮也给出来：原来弹窗关不掉，
只能按浏览器后退；拦下换题时就记上「继续」，按钮文字不会写错
- 「放回编辑器」走正常的换语言路子（画流程图时切回代码编辑器、读那门语言的草稿）；
这道题已经不收的语言（0020 摘掉的 Java / JS / Go）置灰，只能复制
- 举着手时刚交对、1.5 秒内点下一题：原来「确定要换题吗」要问两遍（点评完再问一次），
现在同意过的那个地址不再问
- 课堂看板上评分中、评失败的流程图不再算「尝试过」，和学生的课堂条一个口径；
新加的流程图查询和其他查询并行，不再多等一轮数据库
- 课堂条的数据只认最后发出的那次请求：进页面那次后到的话会把刚做完的那道盖回「没做」
- 「A / S 算做完」收进契约，前后端只留一份；协作中老师的判断统一用 useTeacherCollab；
几处放错位置、说法过时的注释
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-28 19:35:07 +08:00
xuyue and Claude Opus 5.5
3fe3caa944
feat(流程图): 流程图画到 A / S 算这道题做完——题单进度、课堂条都认；加入题单之前画的图先藏起来
...
Deploy / deploy (push) Canceled after 0s
- 流程图评到 A 或 S，记进所有已加入、且包含这道题的题单（和判题那一路同一个口径，不看从哪个
入口交的），徽章和题单类成就照样推送。原来题单进度只在判代码时记，流程图作业在题单里永远是
「没做」。流程图提交的 id 进不了 problemset_submission（外键指向代码提交表），所以只写
progress_detail —— 解锁旧提交的那道闸看的也是它
- 课堂条（/me/class-activity）的 myStatus：流程图 A / S 也算 accepted，评完的非 A/S 算 tried
- 题单防抄闸门补到流程图上：加入题单之前画的图，对本人藏起来（列表 showLink、详情 404、
current / history 不数它），规则和代码提交同一份（problemSetJoinTimes 挪进 services/problemset）。
原来加入之前画到 A 的那张图点一下就能载回画布、交上去就是 A
- 新增 GET /problems/:id/flowchart/scores：一次给出自己评完的每一次的分数和等级，外加被藏起来
的次数（原来 history 一次只给一条，看分数走势得一页一页翻）
- 「A/S 算过关」和按分数定等级收进 flowchart/grade.ts；判题那边的记账 + 通知抽成
recordSolvedAndNotify，两条路共用
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-28 17:56:35 +08:00
xuyue and Claude Opus 5.5
71670e609b
feat(成就): 新增「最长连续新通过周数」指标，按课表的节奏算连续；修掉比赛成就重扫因孤儿提交失败
...
Deploy / deploy (push) Canceled after 0s
按天的连续成就对这里的学生基本拿不到：2025 秋最长连续交题天数的中位数是 1 天，
连续 7 天的只有 3 人。按周算，连续 2/4/8 周分别有约 73%/49%/8% 的学生做到过。
- 新指标 max_ac_week_streak：连续几个自然周（周一起、东八区）每周都至少新通过一道题
（不含比赛）。判题结算时增量累计（比按天那段多一道判断：重判更早的提交不会把连续清零）；
后台建成就触发重扫时，先从提交记录全量补算（refreshAcWeekStreakForAll），同 contest_joined
- 老的「坚持三天」「坚持一周」不动：下架的成就连已获得的人也看不到
- 修：库里 28 个已不存在的用户留下了 935 条提交（其中 11 人有比赛提交），全量补算往
user_stat 写时撞外键，整次失败——比赛类成就的重扫因此一直是失败的；两处都改为只算
还在的用户。本地修好后重扫「初入赛场」补发了 3 人
- 本地验证：连续 2/4/8 周补发 1086/618/123 人，与独立 SQL 一致
线上要在后台手动建成就（指标选「最长连续新通过周数」），建的时候自动补发。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-28 08:27:25 +08:00
xuyue and Claude Opus 5.5
2a4405d2ea
feat(题目): Python 语法错误改成中文说明，在编辑器里标出位置，中文标点可以一键换成英文
...
Deploy / deploy (push) Canceled after 0s
中职学生看不懂英文报错。原来提交前用浏览器里的 Skulpt 拦语法错误，只弹一句
「第 N 行存在语法错误」——Skulpt 九成报的是 bad input / bad token，没有列号。
- 提交前的语法检查挪到服务端：/code/format 先用 CPython 编译一遍（只编译不执行），
api 镜像加 python3-minimal（3.13，与判题机同版本，+17MB），前端删掉 Skulpt
- 报错按规则表翻成中文（pythonError.ts），生产库 2695 条 Python 编译错误覆盖 99.7%；
提交前拦下的和判题回来的编译错误共用同一张卡片
- 编辑器里标红出错行和 ^ 指的位置
- 中文标点（历史编译错误的 22%）一键换成英文，跳过字符串和注释、处理 f 字符串花括号；
594 条里修好 593 条，经 tokenize 核对没有改到字符串内容；走编辑器事务，可 Ctrl+Z
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-27 21:47:01 +08:00
xuyue
d25b5dbe6d
update
Deploy / deploy (push) Canceled after 0s
2026-09-27 19:36:28 +08:00
xuyue and Claude Opus 5.5
9412ba3cf6
refactor(契约): 展示题号统一叫 problemDisplayId，题单 id 统一叫 problemSetId
...
Deploy / deploy (push) Canceled after 0s
前后端同时改，部署前开着的旧页面要刷新一次（题号列会是空的、提交筛选会失效）。
- 挂在非题目对象上的展示题号，原来叫 problem（字符串）或 displayId，统一成
problemDisplayId：提交列表、流程图列表、统计的 lastFailure / items /
今日最热题、站内信里的提交、后台题单的题目列表。别处的 problem 都是对象
或数字 id，这几处是字符串，最容易看错
- 列表筛选的 query 参数 ?problemId= 实际传的是展示题号，改成
?problemDisplayId=（提交列表、流程图列表、三个统计接口）
- 契约里 problemsetId / problemSetId、problemset / problemSet 两种拼法并存，
统一成 problemSetId / problemSet，和 ProblemSet* 类型名、problem-sets
路径、前端路由参数一致。drizzle 的列键跟表名走，没动
- aiDetail.user（用户名字符串，而契约里别的 user 都是对象）→ username。
ai_analysis.data 里存的历史快照仍是 user，没有代码读回它
- 后台题单题目表的列是按字符串键 'displayId' 取的，类型检查抓不到，一并改
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-27 16:08:31 +08:00
xuyue and Claude Opus 5.5
5ae830a7f9
refactor: 一批名不副实的命名改掉（只动一端，不碰契约）
...
后端：
- getUserByToken → authenticateToken：它会删会话、续 TTL、记在线，不是纯读
- todayStart → dayStart(instant)：本来就接受任意时刻，不只是「今天」
- objectValue → asRecord，删掉 4 份一模一样的私有拷贝和 `as toObject` 别名
- 报错文案 "does not exists" / "Already be a public problem" 改通顺
前端：
- utils/types 里 Contest / User / Problem 三个别名删掉：Contest 原来指后台
比赛、契约里同名的却是学生侧。现在 Contest = 学生侧、AdminContest = 后台，
后台用户表单叫 AdminUserForm，题目详情直接用 ProblemDetail
- SubmissionInfo → ContestSubmissionInfo，免得和 submission.info 撞名
- utoa / atou → compressToBase64 / decompressFromBase64（实际是 zlib + base64），
encode / decode → base64EncodeUtf8 / base64DecodeUtf8
- filterResult → toProblemRow、toProblemListItem → toAdminProblemRow，
行字段 submission / rate → submissionCount / acRate
- 组件：Modal → AddFromLibraryModal、Form → EditorToolbar、
ContestEditor → BasicEditor（题单也在用它）、rank 的 Index → RankMedal、
Name → UserNameCell、Password → PasswordCell、ContestType → ContestAccessTag
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-27 16:08:21 +08:00
xuyue and Claude Opus 5.5
e17da63fc6
fix(上传): 头像和题面插图按文件头认格式，不信扩展名
...
原来只看扩展名：改个后缀什么都能落盘，再由 /public/* 按扩展名配 content-type
发出去。线上 Caddy 有 nosniff 兜着，但不该把非图片存到盘上。
- services/image.ts：按 PNG / JPEG / GIF / BMP 的文件头识别，返回落盘用的扩展名 ——
以内容为准，改名成 .png 的 JPEG 存成 .jpg，content-type 才对得上
- 头像上传、后台插图上传都走它；插图那边扩展名白名单保留当第一道快速筛
- serveUpload 自己也带 x-content-type-options: nosniff，不只靠 Caddy
实跑核过：真 PNG / GIF 正常；改名成 .png 的 JPEG 存成 .jpg；改名成 .png 的 HTML
两个入口都拒；/public/upload 回 image/png + nosniff。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-27 15:15:36 +08:00
xuyue and Claude Opus 5.5
b105fe3cbd
fix(测试点): 解压前按条目头拦大小，防 zip bomb
...
原来 unzipSync 先把整包解进内存，再逐个查大小 —— 检查之前就已经解完了。
实测一个 300KB 的 zip（10 个 30MB 的全零文件）让进程 RSS 涨 455MB，
容器只有 512MB。
- 第一遍 unzipSync 的 filter 只读目录、恒返回 false，按条目头的 originalSize
累计，单个超 32MB / 总计超 128MB 就抛；第二遍才真解，而且只解 N.in / N.out /
N.sql（N ≤ 500），压缩包里别的文件一律不解
- originalSize 可以造假，但 fflate 按它分配输出缓冲、不扩容（解多了只截断），
所以按它限额就是按实际内存限额
实测：同一个 zip bomb 被拦下时 RSS 只涨 1MB；单文件 300MB 的包按单文件上限拦；
正常测试点照常落盘、CRLF 照常归一、带 ../ 的条目名照常被忽略。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-27 15:14:12 +08:00
xuyue and Claude Opus 5.5
6406794971
refactor(AI): 学情统计查询从 routes/ai.ts 挪到 services/learning-stats.ts
...
routes/ai.ts 1149 行里约六成是 buildSolved / buildDetail / buildDuration 这些查询
构造器，它们不碰 Context，只是查询。挪出去之后 route 文件剩 585 行，只管
「鉴权 → 取参 → 调统计 → 回包」和 AI 调用本身；targetUser / throttleAi 依赖
Context，留在 route 里。
纯搬移，函数体一行没改。实跑核过：同一个用户的 /ai/detail、/ai/duration（按月、
按周）、/ai/solved、/ai/heatmap 五个响应，改前改后逐字节一致。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-27 15:09:21 +08:00
xuyue and Claude Opus 5.5
09030240b8
fix(AI): 流式调用加空闲超时、客户端断开即停上游、错误原因不下发
...
- streamChat 加 45 秒空闲超时（每收到一块重新计时，不掐长回答），原来 provider
卡住这条请求就永远挂着
- 加 cancel()：客户端断开时 abort 上游 fetch，原来会把 provider 的回答读完白烧 token，
还把「客户端走了」记成 AI 失败；现在留痕写「客户端已断开」
- 推给前端的 error 事件改成固定中文文案（缺 AI_KEY 时是「AI 功能未开启」）。原来
error.message 原样下发，里面可能是 provider 的 HTTP 响应体或数据库报错；
真实原因只进 console.error 和 onError 留痕
用假 provider 实跑核过：正常流式、客户端 1 秒断开时上游被取消、provider 500 时
客户端只拿到固定文案（响应体只在日志里）、provider 挂住 45 秒后收到 error + end。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-27 15:01:43 +08:00
xuyue and Claude Opus 5.5
fb240d4254
feat(限流): 登录、注册、比赛密码防爆破
...
三处原来都不限次数。学生初始密码弱，/classes/:name/usernames 又能公开列出整班
用户名，等于现成的撞库名单。
services/throttling.ts 加固定窗口计数（INCR + EXPIRE NX，锁定时长就是剩余 TTL），
何时计数由调用方决定：
- 登录按用户名 15 分钟 10 次失败，成功清零；按 IP 15 分钟 100 次失败，成功不清零
（否则拿自己的号登一次就能重置）。机房一个班共用出口 IP，所以 IP 那道放得宽
- 注册按 IP 每小时 100 个成功注册
- 比赛密码按「人 × 比赛」10 分钟 10 次失败
- IP 取 X-Real-IP：api 端口不对外，Caddy 用 {client_ip} 覆盖写入，可信
前端登录、注册、比赛密码三处按新错误码给中文提示。
本机实跑核过：第 11 次错误登录被拦、成功清零（用户名大小写不敏感）、同 IP 换
100 个用户名被拦且别的 IP 不受影响、比赛密码第 11 次被拦。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com >
2026-09-27 14:51:52 +08:00
xuyue and Claude Opus 5.5
9d271942aa
feat(AI 提示): 题面补上输入输出说明和样例，HTML 去标签
...
Deploy / deploy (push) Canceled after 0s
两段（诊断 / 生成提示）原来只喂 description，而且是 HTML 原文：模型拿不到输出格式
要求，「输出格式不对」这类最常见的 WA 基本看不出来。
- problemBrief：描述 + 输入说明 + 输出说明 + 最多 3 组样例，末尾点明判题逐字比对。
全是学生看得到的内容，两段都放；标准答案和测试点仍只进诊断
- plainText：去标签、段落 / <br> 换行、表格单元格补空格、解码命名和数字实体
（' 这类带前导零的也认），图片留「[图片]」占位；样例原样不去空白
- 阶梯 prompt 版本 3 / 4 → 5 / 6，旧常量标停用保留；编译失败那一档（1 / 2）不动
用 2026-09-14 的生产备份核过：962 道题的题面无残留标签 / 实体、无裸 `<`。
另有 341 道题面带图片、模型看不到，本次未处理。
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com >
2026-09-27 14:28:21 +08:00
xuyue and Claude Opus 5.5
22fc8d63e2
feat(AI 提示): 阶梯延到 L3 思路 / L4 示例
...
Deploy / deploy (push) Canceled after 0s
- 契约 HINT_LEVELS 加两级，HINT_MAX_LEVEL 2 → 4。前端的等级标签和「再多一点提示」
按钮本来就跟着契约和 canEscalate 走，不用改
- L3 分步骤讲思路（中文伪代码），沿用 L0～L2 的零代码规则
- L4 是阶梯上唯一放开代码的一级，上限两行：过滤不再「出现代码就拦」，而是把代码块
非空行、摊平进正文的类代码行、过长的行内代码合起来数，超过 KEY_LINES_MAX 才拦；
没闭合的围栏按开到结尾算。重生成措辞和兜底话术按级补齐
- prompt 版本沿用 3 / 4：LEVEL_COMMON 拆成三句再拼回，L0～L2 的 system 逐字未变
（已对照改前逐字核过），新两级靠 ai_hint.level 区分。不需要迁移
老师按班级 / 作业设最高等级拆到 2e，未做。
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com >
2026-09-23 09:20:24 +08:00
xuyue and Claude Opus 5
954797a9a5
feat(AI 提示): 提示分级（L0 反问 / L1 定位 / L2 概念）与输出后过滤
...
Deploy / deploy (push) Canceled after 0s
提示不再一上来就把话说完。等级记在「学生 × 题目」上，没有单独的表 —— 它就是
ai_hint.level 的历史，当前等级 = 这道题上（最近一次 AC 之后）给过的最高一级。
阶梯（services/hint-level.ts）
- 只有学生点「再多一点提示」才升级（请求带 more），不带就按当前等级再生成一次
- 升一级要先再交一次：锚点是「这一级是**什么时候**开出来的」，也就是这一级最早那条
提示的 ai_hint.create_time，必须有比这个时刻更新的提交才准 +1。锚点不能用提示所在
那条提交的时间 —— 端点谁的提交 id 都认（只校验归属），拿一条老提交去要提示，锚点
就退回到那条老提交的时间，连点两下 more 就能从 L0 爬到 L2，一次新提交都不用交
- AC 之后清零；编译失败自成一档（level = -1），既不消耗也不推进阶梯
- HINT_MIN_FAILURES 3 → 1：门槛的活由阶梯接走了，第一次失败只开放 L0，而 L0 只反问、
什么都不泄露，拦着它没有意义
- canEscalate 由后端算好在 done 事件里给，前端不自己推阶梯
输出后过滤（services/hint-filter.ts）
- 「不要给代码」写在 prompt 里只是软约束，模型忍不住一次就把这一级的意义废掉了。
所以整段生成、过滤通过才推给前端，逐字显示改由前端模拟 —— 边流式边过滤做不到，
发现违规时内容已经在学生屏幕上了
- 判定只用客观、低误报的信号：代码块、过长的行内代码、整行不含中文的类代码行、
和标准答案重合 3 行以上、L0 一句问句都没有
- 违规就重生成一次，只重一次，再不过发写死的兜底话术。重试措辞按档分叉：编译档本来
就允许给片段，对它说「不要出现任何代码」等于用阶梯的标准把这一档也砍了
- 两次都留痕（filter_attempt / filter_blocked / filter_reason），7.5 的输出过滤触发率
就是从这三列出来的
services/ai.ts 加 streamWhole：事件形状和 streamChat 一样，前端不分叉。produce 期间
每 15 秒发一行 SSE 注释当心跳 —— 这条流中间有一大段静默（诊断 20s + 生成 60s +
重生成 60s，最坏 140 秒），而 NPM / nginx 的 proxy_read_timeout 默认 60 秒，超了学生
看到「请求失败」，后端却还在烧第二次调用，那条提示照样落库、照样把等级推上去。
prompt 版本另开 3 / 4（阶梯上每一级都换了 system），编译档仍走 1 / 2 的单段式基线，
两批数据不混在一起。迁移 0021 给 ai_hint 加四列，都可空、不带默认值，已有的行留 null
表示「分级上线前」。
实跑
- 阶梯：在 dev 库上用真实行驱动 decideHintLevel。正常路径 S1→S2→S3 走出 L0→L1→L2，
同级连点 more 不升，AC 之后回 L0，编译档给 L-1 且不推进阶梯。把旧锚点规则复刻出来
跑同一组数据做对照：只拿最老那条提交反复 POST，旧规则 L0→L1→L2（零新提交），
新规则钉死在 L0，正常路径两者行为一致
- 过滤：起假 AI 服务端走完整条链路。L1 摊平代码→重生成后合规（attempt 2 / 未拦），
L0 两次都甩代码块→兜底话术（blocked，reason 两条相连），编译档抄标程→命中「和标准
答案重合 3 行」且追加的是分叉后的措辞
- streamWhole：produce 拖 16.5 秒收到 1 条心跳；同一份流喂给前端 consumeJSONEventStream
只解析出 delta + done（注释行被静默跳过，前端零改动）；中途 cancel 断开后 produce
跑完不抛
- api / web typecheck、check:routes、fmt 全过
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com >
2026-09-21 19:03:21 -06:00
xuyue and Claude Opus 5
06ad6745b7
feat(AI 提示): 两段式提示——先诊断出错误标签，再生成提示
...
Deploy / deploy (push) Has been cancelled
AI 时代 OJ 设计的 2b。标准答案能让提示准得多，但不能进生成提示的 prompt
（学生代码里一段注释就能把它套走），所以拆成两段：
- 诊断：看得到标准答案、第一个没过的测试点、带行号的学生代码；出参只允许
{ tag, lines, confidence }，safeParse 过闸、多余字段剥掉，没有自由文本通道
- 生成提示：看不到标准答案和测试点原文，只多一句「问题定位：X，大约在第 a 行」
- 诊断失败（20 秒超时、不是 JSON、校验不过）退回单段式；同一条提交复用诊断；
编译失败不诊断
- 契约新增 HINT_ERROR_TAGS（13 个，落库值，只增不改）与 hintDiagnosisSchema
- 迁移 0018：ai_hint 加 diagnosis / diagnosis_error 两列
- 单段式 prompt 原样搬进 services/hint-diagnosis.ts，记版本 1；两段式记版本 2
- completeChat 支持 JSON 模式和自定义超时，现有调用不受影响
- 开关 AI_HINT_DIAGNOSE 默认关（2a 的基线还在攒），两套生产 compose 透传
实跑（一次性库 + 本地假 LLM）：开关关时请求与 2a 逐字节相同；开时正常 /
复用 / 坏 JSON / 非法标签 / 行号越界 / 超时 / 编译失败七种场景符合预期；
12 次模型请求里诊断全都带标准答案和测试点，生成全都不带。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-19 06:56:38 -06:00
xuyue and Claude Opus 5
47d8f46bdb
feat(AI 提示): 提示落库并收集学生评价，落进 ai_hint
...
Deploy / deploy (push) Has been cancelled
AI 时代 OJ 设计的 2a：先把现有提示记下来，为后面的分级和两段式诊断攒对照数据。
提示本身的行为不变，发给模型的 prompt 一字未改。
- 迁移 0017 建 ai_hint：模型、prompt 版本、内容、错误、耗时、学生评价；
成功和失败都记（失败率是 AI 悄悄变差时最先动的数）。挂在 submission 上 CASCADE
- streamChat 第三个参数改成 { onComplete, onError }：onComplete 的返回值并进
done 事件，提示 id 由此带回前端；班级学情分析那处调用同步改写，行为不变
- 落库失败只记日志，不影响学生拿到提示
- 新增 POST /ai/hint/:id/feedback：只能评自己的提示（别人的一律 404），可以改票
- 前端提示生成完出「有帮助 / 没帮助」，选中的高亮；后端没存上时不出按钮
- 实跑：本地假 LLM 验证成功 / provider 断开 / 缺 AI_KEY 三条路径的落库，
评价接口六种请求，浏览器里按钮出现、改票、重复点不发请求
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-19 06:00:10 -06:00
xuyue and Claude Opus 5
ed56a209ea
chore(格式): Prettier 统一到全仓，后端和契约一次性格式化
...
Deploy / deploy (push) Has been cancelled
原来只有 `apps/web` 在 Prettier 下（配置在 `apps/web/.prettierrc.toml`、脚本在
web 的 package.json），后端和契约从来没格式化过 —— 手写在 100 列上下，`db/schema.ts`
还是 drizzle-kit pull 留下的 tab 缩进。两套口径分叉久了，跨端改一处就得记着「这边
什么风格」。
- 配置搬到根目录 `.prettierrc.toml`，内容不变（`semi=false`，其余全默认，
printWidth 80 —— 和前端已有的格式一致，不另立一套宽度）；
- 脚本统一成根目录 `bun run fmt`，覆盖 `apps/*/src`、`apps/web/tests` 和两个构建
配置；web 自己那份 `fmt` 和重复的 prettier 依赖删掉；
- `.prettierignore` 挡掉两类不该碰的：drizzle-kit 生成的 `src/db/meta/` 结构快照
（它是 db:generate 的比对输入，只该由 drizzle-kit 写）、unplugin 每次 dev 都会
重写的 `auto-imports.d.ts` / `components.d.ts`；
- 全量跑了一遍。纯格式，无行为改动：api typecheck / check:routes / check:ast、
前端 type-check 全过，起 api 打了接口确认正常。前端这 39 个文件的小改动是
prettier 版本漂移（类型断言的换行口径变了），不是新配置带来的。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-16 08:27:34 -06:00
xuyue and Claude Opus 5
5eee13fe81
chore: 删掉两个跑完的一次性订正脚本，recount 留着
...
Deploy / deploy (push) Has been cancelled
fix-achievement-hours 订正的是时区丢失那两周误发的「夜猫子」「早起的鸟儿」，
2026-09-14 已跑完（修正 148 行 · 撤回 60 条），根因修在代码里之后不会再产生；
backfill-problemsets 补的三笔题单历史欠账也已结清，进度记账现在在判题这一路。
两个子命令、两条 npm 脚本一并去掉，services/problemset.ts 的 badgeHolderDiff
只服务于补发脚本，删完 0 处引用，一起清掉。
recount 留着 —— 反范式计数列会被重判、删提交带偏，是会复发的漂移，
补一条 npm 脚本（原来只有子命令）。
docs/timezone.md 里那节改成「账已平、脚本已删」，但保住那条教训：
unlockAchievements 是纯阈值比较，只删 user_achievement 不修 metrics 的话，
学生下次提交就把同一个成就原样再发一次。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-09-16 08:03:57 -06:00
xuyue and Claude Opus 5
3921c496cb
fix(成就): 后台补发成就后重算已解锁数并接着判「奖杯收藏家」；recount 订正存量
...
rescanAchievement 只插 user_achievement、加 unlock_count，不重算
achievement_unlocked_count，也不做元成就的第二轮判定（旧 rescan_achievement
原样如此）。判题结算只在「这次有新解锁」时才重算，所以被补发的人计数会一直停在
旧值。2026-09-07 一次补发之后 269 人少算，其中 10 人实际够 15 个却没拿到
「奖杯收藏家」。
- 新增 refreshUnlockedCount：一条 SQL 按 user_achievement 重算，只 jsonb_set
这一个键、只写值变了的行。rescanAchievement 补发非白金成就后调用它，再补发元成就。
- recount 同时核对已解锁数与元成就漏发，--apply 先改计数再补发，复核同一份口径。
用 09-14 生产备份实跑：recount 订正 269 人、补发 10 条，复核通过、重跑无差异，
其余指标 0 行被动；模拟调低阈值补发 1504 条，「奖杯收藏家」随之 65 → 95，
与预先算出的跨线人数一致。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
2026-09-14 05:55:38 -06:00
xuyue and Claude Opus 5
4c0c38445c
fix(时区): 日历口径收回东八区，读出的时刻统一成 ISO 并保留微秒
...
旧栈 Django 按 Asia/Shanghai 算日历，OJ2 重写时这个锚点丢了：容器和数据库会话
都是 UTC，于是「今日提交」在北京时间 0–8 点是空的，「凌晨/早起提交次数」整体偏
8 小时，热力图、AC 趋势年份、近两年活跃人数也各按进程时区切。
- 新增 apps/api/src/time.ts 作为唯一锚点（固定 +8 偏移，不依赖进程 TZ / tzdata），
todayStart、成就小时/日期键、热力图、月份平移、年份夹逼全部改走它；
SQL 里按日历切的一律显式 at time zone。
- db/index.ts：连接会话时区设为东八区（兜底）；给 timestamptz(1184) 挂 parser，
读出统一成 ISO 8601 UTC，撤掉为拿 PG 文本形状写的 ::text。parser 保留微秒 ——
生产库 12.3 万条提交几乎全带微秒，截成毫秒会让翻页分界行和班级 AC 排名的
<= min(create_time) 把自己排除（翻页每页丢一条、排名少 1）。
- 前端 parseTime/zonedParts/zonedYear 按 Asia/Shanghai 渲染，n-date-picker 做
toPickerValue/fromPickerValue 平移，站内不再按浏览器时区取时间部件。
- Dockerfile 设 TZ=Asia/Shanghai 作为第二道兜底。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd
2026-09-14 05:55:17 -06:00
xuyue and Claude Opus 5
79bfd28b07
chore: 删掉 369 行没有任何调用方的代码
...
Deploy / deploy (push) Has been cancelled
## utils/functions.ts 砍掉一半（622 → 291 行）
- trickOrTreat()：317 行、八种页面恶搞效果（中文乱码、页面翻转、去掉鼠标……），
**全仓零调用**，占这个共享工具文件的一半；
- 文件末尾注释掉的 getChromeVersion / isLowVersion / protocol 六行。
## 其余没有调用方的导出
- services/achievement-metrics.ts 的 RARITIES / OPERATORS —— 和契约的
achievementRaritySchema / achievementOperatorSchema 取值逐字相同，是没人用的第二份；
- collab/state.ts 的 hasRequest；以及 resetCollabState，它的注释写着「仅供进程退出或
测试用」，而本仓库不写测试（项目约定），进程退出那条路径也没调过；
- contract/language.ts 的 JUDGE_LANGUAGES，注释说「前端用它排语言 tab」——前端并没有，
它排 tab 用的是 constants.ts 里以 ProblemLanguage 为键的 SOURCES / LANGUAGE_SHOW_VALUE
（那组映射的完整性 tsc 已经在管）；
- web 的 useSimplePagination（usePagination 的一层空壳包装）和 updateProblemSetProgress。
扫描口径：三个包全部 .ts / .vue 里逐个导出符号数出现次数，只在定义处出现的算无引用
（.vue 模板里的引用也计入）。剩下 56 个仍无引用的全部是契约里 `z.infer` 派生的一行
类型（46 个请求类型 + 10 个领域类型）—— 它们是在用的 schema 的类型另一半，成体系的
1:1 镜像，删一部分只会让那个文件变得随意，所以不动。
## 留给你定的一件事
`updateProblemSetProgress` 删掉之后，后端 `PUT /problem-set-progress`（routes/problemset.ts:249）
就没有任何调用方了。题单进度实际是判完之后由 services/problemset.ts 的 recordSolvedProblem
在服务端记账的（schema.ts 里那条注释写明了），这个端点是一条客户端自报进度的平行路径。
没顺手删：删端点是行为变化，而且不能排除有脚本在打它。
tsc、vue-tsc、vite build、单二进制编译、check:routes、check:ast 均通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH
2026-09-10 19:38:16 -06:00
xuyue and Claude Opus 5
ab47e71d6f
refactor(契约): 出参不再 parse，后台老题详情和站内信页不再 500
...
Deploy / deploy (push) Has been cancelled
## 出参改 satisfies
出参是后端自己刚拼出来的字面量，TS 编译期已经验过；再 xxxSchema.parse({...}) 一遍
拿不到任何新信息，唯一可能失败的输入是库里的历史数据，而失败的代价是 500。136 处
全部撤掉，撤的时候当场炸出两个一直存在的线上故障：
- 后台打开任何一道没编辑过的题都是 500 —— problem.last_update_time 是全库唯一可空
的列（961 道题里 470 道是 NULL），而 adminProblemSchema.lastUpdateTime 写的是
z.string()；
- 收到过站内信的人打开消息页全是 500 —— embeddedSubmissionSchema 从
submissionDetailSchema 继承了 problemDisplayId 却没 omit，路由只填了同义的
problem；列表为空时才碰巧不炸，所以一直没人报。
两个都是读出侧校验自己造出来的故障，不是它拦住的故障。
## 校验责任挪回写入侧
- db/schema.ts：枚举型的列和几个形状确定的 JSONB 挂 .$type<>()（submission.result /
.language、problem.difficulty / .languages / .template / .astRules / .sqlConfig /
.sqlDisplay、achievement.rarity / .operator、exercise.type、reaction.type、
tutorial.type、problemset.difficulty / .status、flowchart_submission.status、
problemset_badge.condition_type、acm_contest_rank.submission_info）。只影响 TS、
不产生 SQL，断言逐列拿根目录那份生产备份核过全量数据。
- createProblemRequestSchema.languages 收窄成 problemLanguageSchema，兑现
problem.languages 列上的断言。
- 新增 routes/helpers.ts 的 asFilterValue()：query 筛选值（result / language /
difficulty / status）要和收窄过的列比较时做纯类型交接，不加校验 —— 在这儿拦一道
会把「筛出空列表」变成「筛条件被忽略、返回全部」。
- 判题产物（submission.info / statistic_info / exercise.data）照旧放行，形状真相
在判题机那边；judge/sql、flowchart/run、events.ts 里对自家产物的 parse 一并撤掉。
- 仍然 parse 的只有 judge/events.ts 的 parseSubmissionEvent —— 从 Redis 收回来的
报文是真边界，失败返回 null 而不是 500。
顺带清掉两处重复的真相：stringArray 原本在 routes/helpers.ts、routes/problem.ts、
routes/submission.ts 各有一份拷贝，5 个调用点全部只作用于 problem.languages，列有类型后
三份一起删；routes/site.ts 里和契约同名同形的本地 interface Quote 也删了 —— loadSentences
读入时已经逐字段守过，那处 parse 同样是多余的。
## 文档
CLAUDE.md 那一节从「契约收紧要挑地方」改写成「出参不 parse，用 satisfies」，写明
三处写入侧闸门（入参 safeParse 58 处、列上 $type、语义校验函数）；apps/web/CLAUDE.md
同步 —— 现在收紧字段的后果落在 tsc 编译期，但契约形状仍要对得上存量数据。
## 验证
- 生产备份全量：12.4 万条提交的 result 全在 -2..6,10、961 道题的 languages 均为合法
数组、10050 条榜单条目形状全对，无一例外；
- tsc -p apps/api 与 vue-tsc --noEmit 均 exit 0；check:routes 检查 177 条路由，无遮蔽；
前端 build、单二进制编译并在仓库目录之外启动均通过；
- 实跑 40+ 端点（学生端 / 后台 / AI / 榜单 / 题目回写往返），以及一次完整比赛 e2e：
建比赛 → 复制题目 → 错解 → 正解，把 judge/run.ts 榜单写入的三个分支全走到
（error_number 0→1、is_first_ac + ac_time 671、totalTime 1871 = 671 + 1×20×60），
后台核查页的勾选与 404 分支一并验过，测试数据已清理；
- 两个 500 用抓到的真实响应对着改动前的契约复验：lastUpdateTime 收到 null、
problemDisplayId 收到 undefined，改动后同样两个响应均通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH
2026-09-10 18:14:05 -06:00
xuyue and Claude Opus 5
7d15e6aeaa
refactor(契约): 判题产物退回不校验，练一练的形状闸挪到写入侧，运行时闸门收回三处
...
前四轮把契约当成运行时闸门铺开，复盘下来三块里只有一块是赚的：类型收拢成一份
（语言联合、Problem/Message/ContestRank 的重复派生）留着；另外两块退回来。
## 判题产物：读出侧不再校验
judgeCaseResultSchema 按采样键集收紧的结果，用根目录那份生产备份全量跑了一遍：
124192 条提交里 9163 条对不上，**RE 8480/8480、TLE 338/338+26、MLE 1/1 全中**，
另有 270 条 WA、47 条 AC。原因不是键集合，是空值和 SQL 链路：
- 沙箱在非正常退出的测试点上写 `output_md5: null`，契约写的是 z.string()；
- SQL 判题（judge/sql/engine.ts 的 CaseResult）根本没有 `output` 键；
- SQL 通过的测试点 `error_message` 是 null，契约写的是 z.string().optional()。
更糟的是失败方式：`info` 是 `union([完整形状, z.object({})])`，对不上的一律落进
第二支被剥成 `{}` 且 parse 成功 —— 管理员详情页的测试点表格**静默消失**，无日志。
JSONB 的形状真相在写入侧（判题机），读出侧再校验一遍只会在两边分叉时丢数据。
所以 `info` 回到 z.unknown()，形状改用 JudgeInfo / JudgeCaseResult 两个 TS 类型
描述（按判题机实际写的形状，不是采样出来的），取值处由 submissionCaseResults()
做唯一需要的运行时判断：有没有 data 数组。statisticInfo 换成 looseObject ——
所有键可选、不剥未知键，对任何对象都不会失败，它的作用是给类型不是当闸门。
## 练一练：形状闸从读路径挪到写路径
exerciseSchema 的 superRefine 挂在读路径上，而这个 schema 后端也在 parse
（routes/content.ts），等于一行脏数据就能让整条学生练习列表 500。同时写入侧的
exerciseDataError **一次都没查过 question**，两边严紧度不一致，脏数据进得来出不去。
exerciseDataByType 保留，改由 exerciseDataError 在写入前查，错误信息按字段翻成
中文给老师看；读路径回到不校验。
## 运行时闸门收回三处
contract() 从 41 个端点收回到题目详情 / 提交详情 / 用户资料 —— 原本就写了
.parse() 的那三条。留着的理由是「别抛错」（原来 parse 抛 ZodError 会白屏、
后面的 as 又让校验白做），不是校验：前后端同仓、共享同一份 schema，字段漂移
tsc 已经抓了。闸门本身也瘦掉了没人读的 window.__OJ2_CONTRACT_DRIFT__ 那套簿记。
## 验证
- 生产备份全量：124192 条提交过 submissionDetailSchema / submissionListItemSchema
零失败，其中 112144 条能拿到测试点明细（另外 12048 条本来就是 data:null）；
151 道练习读路径 151/151、写入闸 151/151（老师改旧题不会被新闸挡）；
- 反向验证写入闸：缺题干的排序题被拒并给出「题干的格式不对」；
- 本地实跑：种一条生产形状的 RE 提交（output_md5: null），管理员详情接口原样
返回 info.data（改之前是 {}）；库里塞一行没有 options 的 mcq，学生端练习列表
照常返回两条而不是 500；
- vue-tsc / tsc -p apps/api 均 exit 0，vite build 通过，check:routes 无遮蔽。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH
2026-09-10 04:53:28 -06:00
xuyue and Claude Opus 5
5222e012e1
fix(比赛): 修四处 —— 倒计时两倍速、排名不自动刷新、题目状态恒空、比赛隐藏后审核页取不到代码
...
查比赛功能时实跑出来的四个问题，都在这一条里修掉：
**倒计时两倍速**（store/contest.ts）。init() 里 setInterval 之前不清旧表，而
detail.vue 在「未开始 → 进行中」那一刻会再 init 一次（为了捞开赛后才拿得到的题），
于是两个 interval 一起给 now 加 1000。学生赛前挂着页面就会中招：一场 60 分钟的
比赛，真过了 30 分钟页面就显示「已结束」、倒计时归零，而服务端还在正常收提交。
ojnext 里就有，是原样搬过来的。
**排名页「开启自动刷新」开着但不刷新**（contest/pages/rank.vue）。useIntervalFn
传的是 immediate: false，而 watch(autoRefresh) 只在开关变化时才 resume ——
开关初值就是 true、进页面不产生变化，表从没启动过，得手动关一次再开。改成
watchEffect，由「开关 + 比赛进行中」共同驱动，顺带不再在赛后空转轮询。同样来自
ojnext。
**比赛题的 myStatus 恒为 null**（routes/contest.ts）。判题其实把状态记进了
user_profile 的 acm_problems_status.contest_problems，只是这两条路由硬编码下发
空值，于是题目页的「状态」列永远是「未做」，赛后也不恢复。旧后端在赛后/管理员
视角是给的，这是回归。不按赛中赛后分档：这是学生自己的判题结果，不泄露别人任何
信息（旧后端赛中不给，只是因为它整条路换了个 serializer）。
**比赛一隐藏，审核页的「查看代码」必 404**（services/contest.ts）。acm-helper
故意不卡 visible（赛后核查恰恰发生在比赛收起来之后），它调的比赛提交列表却卡着，
两边对不上。findVisibleContest 换成 findAccessibleContest：公开的谁都取得到，
隐藏的只有比赛管理员取得到，学生看隐藏比赛照旧 404。
实跑验证（dev 全栈，判题走临时 worker 绕开本机 token 不一致）：
- 浏览器跨过开赛时刻挂着不动 —— 墙钟 20.0 秒，倒计时正好减 20 秒（原来会减 40）。
- 排名页停在「无数据」，另一账号提交一发 AC，5 秒内表格自己长出
`1 student2 1/3 0:00:42`，没刷新页面。
- 学生 AC 后列表和详情都回 myStatus: 0，没做过的另一个学生仍是 null，匿名照旧 401。
- 比赛隐藏 + 已结束：出题人 detail / problems / rank / submissions / acm-helper
全 200，学生这 5 条全 404，提交也 404，隐藏比赛不进公开列表。
- 排名记账口径未受影响：10 次提交（8 编译失败 + 2 AC）落库 submission_number=9、
accepted_number=1、total_time=231=ac_time、is_first_ac=true。
tsc / vue-tsc / check:routes（175 条无遮蔽）均干净，测试数据已清库。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_017xu912Rv5JUUuy6MqMcQW2
2026-09-07 19:19:29 -06:00
xuyue and Claude Opus 5
5d60bb15bb
perf(redis): 热路径合并往返，限流脚本改走 EVALSHA
...
Deploy / deploy (push) Has been cancelled
审查 Redis 用法时找到的四处小账，都是确定性改动，语义不变：
- `getUserByToken` 里两条串行 EXPIRE 合成一次 pipeline。这是全后端最热的
Redis 路径 —— 每个带鉴权的 HTTP 请求都要续一次会话和反向索引。上次给
`touchSession` 修的正是同一个形状，这处漏了，两边现在一致。
- `createSession` 的 SET / SADD / EXPIRE 三趟并成一趟。登录是突发的，
一个班同时登录时差别全压在这一下。
- 限流的 Lua 从 `redis.eval` 改成 `defineCommand`，稳态走 EVALSHA 只发
40 字节 sha1，不再每次带上 937 字节的脚本全文；NOSCRIPT 由 ioredis
自动回退成 EVAL 重新灌，Redis 重启和 SCRIPT FLUSH 都不用管。
- 删掉 websocket 订阅连接上重复的 error 监听 —— `withErrorLogging` 已经
打过一遍且带连接名，留着只会把同一条错误打两份。
实跑验证（dev 栈，API 跑在 3999）：登录后 `session:*` 多一条、
`user-sessions:1` 的 scard 和 ttl(604800) 都对；把两个键的 TTL 压到 100
再打一次带鉴权的请求，两个都回到 604800。限流侧 `info commandstats` 显示
evalsha calls=3/failed=1 + eval calls=2 —— 失败那次正是 SCRIPT FLUSH 之后
的 NOSCRIPT 回退；令牌桶数值与旧实现逐位一致（10 个初始额度扣 3 剩 7，
再要 20 个被拒并返回 wait=433.33 = (20-7)/0.03）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01XvmqDsZNyUo9P3sFQtoWVB
2026-09-07 18:44:59 -06:00
xuyue and Claude Opus 5
ec1509c46d
perf(限流): 桶参数加 60 秒进程内缓存；Redis 连接补 error 监听
...
getBucketConfig 每次都查一次 `throttling` 配置项，而限流点在提交判题、AI 分析、
流程图评分上（5 处调用）—— 判题高峰期等于每条提交多一趟数据库，只为读一个几乎
从不变的值。上一代在 options/options.py 的 my_property 里也是带 TTL 缓存的，
重写时漏掉了。
缓存放进程内而不是 Redis：每站只有一个 api 进程服务读请求（oj-api 单容器、
Bun.serve 没有 reusePort、worker 只消费队列），进程内 Map 就等于全站缓存，
放 Redis 只是多一趟网络加一次序列化。异常分支特意不写缓存 —— 数据库抖一下不该
让接下来一整分钟全站都按默认参数限流。`throttling` 没有后台界面、只能直接改库，
改完最多一分钟后生效。
顺带给三条 Redis 连接都挂上 error 监听。ioredis 对没有监听者的 error 走
silentEmit：不崩进程，但把连接错误直接 console.error 到 stderr，绕开这里的日志，
而且不说是哪条连接 —— 这个进程同时开着会话读写、两条队列、一条订阅，「哪条」正是
要先知道的。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01XvmqDsZNyUo9P3sFQtoWVB
2026-09-07 07:41:09 -06:00
xuyue and Claude Opus 5
498fc1ceca
fix(后台): 会话吊销、导入查重、练习题校验，以及一批后台页面的小毛病
...
Deploy / deploy (push) Has been cancelled
后台代码审查后的一批修复。
后端：
- 改密码 / 重置密码 / 禁用账号现在真的把该用户所有设备的会话删掉。原来只
publishSessionRevoked 广播断 WebSocket，HTTP 拿着旧 cookie 照样能用到会话
自然过期 —— 给被盗用的账号改密码等于没改。为此在 Redis 里补了反向索引
user-sessions:<id>（createSession 写入、登出和失效路径清理、跟着会话续期）。
- 导入用户补齐校验：邮箱走 z.email()、批内查重、库内查重，用户名和邮箱各报各的；
用户名和邮箱都归一成小写，和登录的 lower(username) 比较口径对齐。以前导入这条
路什么都不查，而前端占位邮箱按「班级+批内序号」拼，同一个班导第二批必然重号，
那两个账号从此在后台保存一次就撞 409、再也改不动。前端生成的占位邮箱同步加了
每批随机后缀。
- PUT /users/:id 的邮箱查重改比 lower(email)，存量大小写混着的数据也能拦住。
- 删用户的裸 catch 收窄成只认外键冲突 23503（顺 cause 链找，drizzle 0.45 把驱动
错误包了一层），别的错照常抛 500，不再把连接故障说成「该用户还有历史数据」。
- 练习题 data 补语义校验（services/exercise.ts）：没有 {{空位}} 的填空题、空选项的
选择题、越界的下标等一律拒收。以前后端零校验，坏数据只有学生端会撞到。
- PUT /judge-servers/:id 改用 queryInteger，非数字 id 回 404 而不是 500。
- 比赛克隆不加归属校验是**有意的**（快速再开一场以前的比赛；保密边界在师生之间不在
教师之间），把这条政策和它的副作用写进注释，免得反复被当成漏洞。
前端：
- 编辑用户弹窗的「班级」输入框改成只读 —— 它一直是个改了没用的控件，班级由后端从
用户名推导。
- 新建用户预填唯一占位邮箱、角色默认改成实际会建出来的 Regular User、密码留空直接拦。
- 比赛题目列表的列过滤写的是 top_reaction，实际 key 是 topReaction，空列一直没被滤掉。
- AI 生成流程图加 try/finally，接口失败不再把按钮卡在 loading。
- 单个判题机删除后刷新表格；后台首页显示在线判题机数量（后端一直在下发）。
- 下载测试点失败时读 Blob 里的错误信封弹提示，不再毫无反应。
- 练习题编辑器补上和后端一致的前置校验。
验证：tsc / vue-tsc / vite build / check:routes 全过；后端每条改动都在本机起服务
实跑确认（会话吊销、导入各种重复、练习题七种题型、外键 409、非数字 id）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01RC5uL72UY9aZFuTvUKe2jv
2026-09-06 08:41:54 -06:00
xuyue and Claude Opus 5
2c4d56b29a
refactor(后端): 清掉 Django 遗留的死列与手工级联，角色字符串收成一份
...
三条迁移，一次部署（0008/0009 含 DROP COLUMN，需要 OJ2_ALLOW_DESTRUCTIVE=1）：
- 0008 删 IP 相关：比赛 IP 白名单（前端本来就没有输入框，detail.vue 无条件置空）、
submission.ip（前端从未显示过）、以及一次都没被调用过的 IP 限流桶。
judge_server.ip 是运维数据，保留。
- 0009 删九个只有 Django 时代写过、OJ2 一次都没读过的列：user 的 auth_token /
open_api / open_api_appkey / session_keys，user_profile 的 blog / github /
school / major / language。open_api 后台连开关都没有，那段「已经开着就不重置
appkey」的逻辑从上线起没进过 if。判据是「全仓零读取」而不是「看着没用」——
raw_password 同样刺眼却是在用的，别一起清掉。
- 0010 给 17 条外键补上删除动作，不再是 Django 留下的一律 NO ACTION。父行消失后
必然无意义、且不构成学生留痕的走 CASCADE（中间表、题单/教程/成就的组成部分、
user_profile 与 user_stat）；需要人看见的继续拦着——submission.problem_id、
以及 user 的绝大多数外键，删用户撞外键会被 handler 翻译成「请改为禁用账号」，
这是有意的：全 CASCADE 会静默抹掉成就与进度，而 submission.user_id 压根没有
外键，结果是一半删一半留。六处手工级联随之删掉。
角色字符串收进 packages/contract/src/roles.ts：原先 ADMIN_ROLES / TEACHER_ROLES
在两个文件各抄一份、学生口径在四个文件各写一遍、前端 USER_TYPE 是第三份副本。
AuthUser.adminType 与 drizzle 的列都收窄成联合类型，二十多处 `=== "Super Admin"`
从此受编译器管着（$type 是纯 TS 层的，generate 确认不产生任何 SQL 变更）。
顺带删掉 db/relations.ts —— drizzle-kit pull 的产物，全仓零引用。
一处行为变化：后台用户列表传非法的 ?type= 回 400，不再静默返回空列表；界面上的
下拉只有合法值，打不到这条。
验证：tsc / vue-tsc / vite build / check:routes 全过；三条迁移在 dev 库执行，
并逐条建 fixture 走 HTTP 接口验过删除连坐与拦截（题单五张子表连坐、user_badge
二级连坐、删有提交的题目仍 409、删有表情的用户仍 409）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01AeJoYc2t2d7cThVqMBYrBF
2026-09-02 22:57:45 -06:00
xuyue and Claude Opus 5
9d9e104df6
fix(题单): 进度记账挪到判题这一路，不再靠前端回调
...
前端记账是这条链上最松的一环：SubmitCode.vue 看到 AC 就回调
PUT /problem-set-progress，而且只认路由参数里那一个题单。于是
· 从普通题库入口做出同一道题 → 不计进度
· 网络一抖、页面提前关掉 → 进度静默丢失
· 一道题同时在两个已加入的题单里 → 只有进去的那个记上
旧栈为此专门有个管理命令 fix_problemset_progress 定期按实际提交补账 ——
2026-05-22 00:50 那次一分钟内跨 7 个题单的批量补进度就是它跑的。
改成判题落库之后由 judge/run.ts 记账（recordSolvedProblem），记进该用户**所有**已加入
且包含这道题的题单。位置在最后那条 publishSubmissionUpdate("finished") 之前，所以前端
收到「判完了」时进度已经落库，跳回题单页看到的就是新数据。前端那次回调删掉。
不按 visible / status 过滤：进度是学生自己的记录，老师把题单藏起来不该让它停止累积；
更要紧的是这条口径必须和补账工具一致，否则补账工具会永远「发现」差异。
实跑（本地起 api + worker 真判一次）：提交时**完全没带 problemSetId**，判完之后
progress 变成 1/1 100% 已完成、10 分、complete_time 落下、all_problems 奖章发出、
problemset_submission 也记上了。
## 补账那半
backfill-problemsets 前面加一道「按实际 AC 补进度」，移植自旧栈的
fix_problemset_progress，口径和 recordSolvedProblem 逐条对齐（非比赛提交、
ACCEPTED 或 AST_CHECK_FAILED、取最早那次）。补录的格子先并进 detail 再重算，
所以预演里的奖章名单是照着「补完账又重算过」的进度算的，和 --apply 的结果一致。
在生产快照上实跑：
合计：补录 10 道题，进度 497 条要重算（完成 +23 / -0），奖章补发 56 条、收回 0 条
已订正 11 个题单 → 复核通过
user_badge 1180 → 1236，已完成 621 → 644，problemset_submission 7735 → 7745
「未完成但有完成时间」仍是 4 条；重复跑幂等
补录的 10 道分布在题单 4/5/6/15/16（1/1/1/4/3），和离线独立算的数字逐个对上 ——
其中题单 15 那位 AC 了全部 12 题却一直显示未完成。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
2026-09-01 00:01:38 -06:00
xuyue and Claude Opus 5
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
xuyue and Claude Opus 5
d7a6414735
fix(题单): complete_time 翻回「只设不清」；完成题单后那个必然报错的 tab
...
三件事，都是上一轮结论没查扎实留下的。
## complete_time
f9354b0noreply@anthropic.com >
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
2026-08-31 08:42:40 -06:00
xuyue and Claude Opus 5
f9354b0df1
fix(题单): 进度重算漏了分数和完成状态，奖章没人补发
...
Deploy / deploy (push) Has been cancelled
进度算法在学生路径和后台路径各写了一遍，于是各自漂了一段。后台那份
（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
xuyue and Claude Opus 5
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
xuyue and Claude Opus 5
a75c70c82d
perf(后端): 干掉 14 处 N+1 查询
...
Deploy / deploy (push) Has been cancelled
列表接口按行发查询是从阶段 3 一路带过来的写法：`Promise.all(rows.map(...))`
看着是并发的，但每行都往库里打一次，行数一多就是几百上千次往返。同样的模式
也散在几个后台批处理和写入路径里。全部改成「先收集 id，一条 inArray/group by
查回来建 Map」——`routes/problem.ts` 的 getProblemTags 早就是这么写的，这次
只是把剩下的地方对齐。
用户可见的列表：
- `GET /problem-sets` 每行 5 条（题目数/我的进度/奖章/已获奖章/创建者），
limit 上限 250 就是 1250 次往返。改成固定 5 条，与行数无关。
- `GET /contests` 每场比赛一条 creator 查询。后台的比赛列表本来就是 join
出来的，只有这条公开列表漏了。
- `GET /admin/problems`、`GET /admin/contests/:id/problems` 每题一条标签查询。
- `GET /admin/problem-sets` 每行 3 条；`.../badges` 每个奖章一条 count。
后台批处理：
- `refreshContestJoinedForAll` 原来是每个用户 1 条 count 加一个独立事务里的
insert/select for update/update。改成一条 group by 出全部用户的场次，再分批
upsert，`metrics || excluded.metrics` 是 jsonb 浅合并，只覆盖 contest_joined
一个键，其余指标原样保留 —— 合并在一条语句里完成，for update 那把锁不再需要。
- `rescanAchievement` 补发循环、`unlockAchievements`：命中的一次插完，
onConflictDoNothing 的 returning 就是真新解锁的那批，unlockCount 改成一次 +N。
- `resyncProgress` 逐行 UPDATE 改成一条，completed 用 least() 夹住。
写入路径：
- 标签解析抽出 normalizeTagNames + findTagsByName（一条 lower(name) IN），
新建题、改题、批量打标签三条路共用。
- 克隆比赛：题面一条 INSERT、标签一条 SELECT 加一条 INSERT。新旧题的对应
关系靠 _id 认，不依赖 returning 的行序。
- `POST /admin/website` 8 个键一条多行 upsert。
- 题单奖章判定一次插完。
`/ai/duration`：原来每个时间桶两条查询、桶之间还串行，一年 12 个桶 24 次往返。
改成先算桶、再一条查询把整段区间拉回来在内存里分桶。时间戳用
`extract(epoch) * 1000` 取毫秒回来比，别指望 Date.parse 认 pg 那个
`2026-08-12 00:00:00+00` 格式。**相邻桶首尾相接、两端闭区间**（落在边界上的
提交两个桶都算）这条旧语义是照搬的，不要顺手改成半开区间。
验证：本机起 dev 栈，造了覆盖各分支的种子数据（创建者重复的题单、零题目/零
奖章的题单、completed > total 的脏进度、除不尽的百分比、大小写混写的已有标签、
带/不带标签的比赛题、正好落在分桶边界上的提交），旧代码跑一遍、新代码跑一遍：
- 51 个接口响应逐字节一致
- 12 张表的快照逐行一致（唯一差别是 progress_detail 里的 submit_time 墙钟值）
- 打开 log_statement=all 数过条数，例如 `GET /admin/problems` 20 道题
24 → 5，`GET /problem-sets` 28 → 8，`/ai/duration` years:1 28 → 5，
202 个用户的成就补发 1828 → 614
一处可观察的行为变化：补发现在整批共用一个 unlockTime，原来是每人一个
new Date()。rescanAchievement 上方的注释本来就写着补发会给几百人盖同一个
时间戳、前端据此只显示「已获得」不显示日期，所以这个方向是对的。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-26 23:43:57 -06:00
xuyue and Claude Opus 5
9653f1541a
refactor(契约): SQL 展示数据进契约，topReaction 收成枚举
...
d3b05b8noreply@anthropic.com >
2026-08-25 19:02:25 -06:00
xuyue and Claude Opus 5
25c6e99c54
feat(后台): 补回「最高票评价」列，重写时漏掉了
...
管理端题目列表的「反馈」列一直是空的：前端渲染逻辑还在，后端两处
硬编码 topReaction: null —— 旧后端的 reaction/services.py:get_top_reactions
没有跟着迁过来，阶段 0 的清单也没抓到。
新增 services/reaction.ts，口径逐条对齐旧实现：
- 按 (problem_id, type) 分组计数，取票数最高的那个；
- 并列时按 reactionKeySchema 的定义顺序取靠前的，与前端 REACTIONS 的顺序
一致（旧后端是 TYPE_ORDER，已核对两边七个 key 的顺序与内容完全相同）；
- 只返回有评价的题目，没有的题调用方兜 null。
比库里可能残留、但前端已经下掉的类型多了一道跳过：不跳的话一个不再展示的
类型会以并列最优的身份把真正的最高票挤掉。
只有公开题列表下发，比赛题列表不下发 —— 与旧后端一致（旧的 top_reaction
只出现在 ProblemAPI，ContestProblemAPI 没有），前端那一列的注释也是这么写的。
实测：造 3 票 learned + 1 票 too_easy 取到 learned/3；interesting 与
too_hard 各 1 票时取到 too_hard（定义顺序在前）；插一条 obsolete_kind
不影响结果；无评价的题返回 null。探针数据已清理。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-25 14:08:09 -06:00
xuyue and Claude Opus 5
c2a81209d7
refactor(前端): 拆掉 camelCase→snake_case 转换层，契约成为唯一真相
...
utils/legacy.ts 是迁移期的临时层：新后端一律 camelCase，而组件读的还是
旧 Django 的 snake_case，于是在 api 层做一次递归键名重写。它自己的注释就
写了「迁移完成后这一层应当整体拆掉」。现在拆了。
代价不只是那 96 处包装：每个响应都要递归遍历整个对象重写一遍键名，而且
utils/types.ts 和 packages/contract 是两份真相 —— 手抄的那份还抄歪了好几处。
做法是按域推进，每域都用 vue-tsc 相对基线做差，确认零新增错误后再往下走。
前端的类型现在一律以契约为准，只在必要处窄化（比如 languages/template 的键
窄化成 LANGUAGE），删掉的重复定义包括 WebsiteConfig、LoginSummary、
AchievementSummary、ProblemSet、Contest、User、Profile、AdminTag、
StuckProblem 等等，其中 ClassComparison 有两个组件各手抄了一份。
## 顺带修掉的真 bug
- 管理端公告列表的「可见」开关每次都 400：列表响应被契约 omit 掉了 content，
而更新接口要求 content 必填，toggleVisible 把列表行原样回传。而且是乐观
翻转、不 await 不 catch，管理员看到开关动了、实际没存也没有提示。
改成先 GET 整条再 PUT，加失败提示。
- 删有提交的题时只显示笼统的「删除失败」：前端还在 match 旧 Django 的英文
文案，而后端返回的是 problem-has-submissions + 中文。连同另外 8 处同类
匹配一起改成判错误码 —— 文案是后端随时能改的，match 文案改一个字就静默失效。
- SubmissionStatus.time_limit_exceeded 写成 `1 | 2`，TS 按位或算成 3，和
memory_limit_exceeded 撞了同一个值。后端 judge/status.ts 里这是分开的
两个码，按后端拆成 cpu_/real_ 两项。当前没有代码读这两个成员，但
CLAUDE.md 明确要求判题状态码三处同步。
- 流程图历史翻到没有提交的那一页会直接抛：契约里 submission 是 nullable，
被 any 掩盖成看起来非空。补了 null 分支。
## 契约里被逼出来的三处不诚实
- grade 写成 z.string()，但 averageGrade() 在没有可用数据时返回空串，
前端三张图表拿它查 Record<Grade,...> 会查出 undefined。按实际收紧成
z.enum([...,""])，四个查表点都补了「无评级」分支。
- difficulty 写成 z.string()。核对过生产库 dump：956 道题只有
Low/Mid/High 三个值（761/149/46）。收紧成枚举。
- topReaction 写成 z.string()，既对不上前端渲染的 {type,count}，也对不上
旧后端 get_top_reactions 下发的形状。改成正确形状并注明当前恒传 null。
## 明确保留 snake_case 的 54 处
判题沙箱原始输出（cpu_time/exit_code/output_md5/compile_output）、
statistic_info 内容（err_info/time_cost/ast_results）、submission_info
JSONB（is_ac/ac_time/error_number，回滚时旧后端还要读）、SQL 判题引擎的
total_rows/order_sensitive/changed_tables、WebSocket 的 submission_id、
以及数据库选项键 enable_maxkb。每一处都在类型定义旁写了为什么不能改。
language 没有跟着收紧契约 —— 它是配置项、随时可能加语言，收紧会让新语言
在后端 parse 时直接抛。改在 api 边界一处窄化。
## 另外
- utils/http.ts 整个模块已是死代码（四处引用全是 import type），删除。
- profile 的 blog/github/school/major/language 五个字段全链路空转，没有
任何组件读，从契约到类型一并摘除（数据库列不动）。
- admin/account.ts 往 user_profile 塞的 totalScore 是 OI 模式遗留，表里
没这一列。Drizzle 按表定义拼列名会把它静默丢弃，所以没出过错，是死代码。
验证：vue-tsc 143 → 54 条且无新增，apps/api tsc、check:routes、web build
全通过；各域响应形状逐条打接口核对过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-25 13:44:24 -06:00
xuyue and Claude Opus 5
e2c6ee69da
fix(阶段5): jieba 资源导入不能用在 dev；补上 /public/upload 的伺服
...
## jieba：两种形态得走两条路
上一条 commit 把 jieba 的 .node 改成 `with { type: "file" }` 内嵌，只验证了
编译产物，没跑 `bun run` —— 结果 dev 直接起不来：
TypeError: To load Node-API modules, use require() or process.dlopen
instead of import.
`.node` 的资源导入只有打包器认，运行时不认。而且必须是**动态** import：
静态 import 在模块加载时就求值，拿 isCompiled 判断也来不及。
所以分两条路：dev 用包自己的入口（那条路 bun run 下是好的），编译形态才走
内嵌资源。两边都实测过了。.wasm 没这个毛病，两种形态都正常。
withBuiltinDict 因此变成 async，连带 buildWordFrequencies 也是。
jieba 实例改成缓存 Promise 而不是结果，并发进来两个请求只会建一次词典。
## /public/upload 之前根本没人伺服
后台上传图片存盘、返回 `/public/upload/<name>`，但没有任何路由处理这个前缀 ——
题面里插的图片一律 404。补上，并和头像共用一个 serveUpload：只取路径最后一段
且要求它和原样一致，`..`、子目录、编码斜杠都在这里被拒。
生产环境这些请求也走后端（Caddy 反代整段 /public），不让 Caddy 直接读盘，
这样开发和生产是同一条代码路径。
dev 模式 8 项实测：上传图片/头像/默认头像回退 200，不存在、`..`、编码穿越、
子目录、编码斜杠全 404。编译产物在干净目录里 7 项照旧全过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 23:20:12 -06:00
xuyue and Claude Opus 5
ce21a2bb8f
feat(阶段5): 让 bun build --compile 的产物真正自足
...
编译产物拿到没有 node_modules 的目录里跑，原来是一路崩的 —— 而且**在仓库
目录里跑时全都正常**，因为它顺着 cwd 找到了 node_modules，假装没事。
这类问题只会在服务器上第一次启动时暴露。逐个堵掉：
- `import.meta.dir` 在二进制里恒为 `/$bunfs/root`，往上三级就是文件系统根：
`data/test_case` 悄悄变成 `/data/test_case`，`.env` 去读 `/.env`。
新增 runtime.ts 显式分叉：编译后按 cwd，开发时按仓库根（后者不能改，
compose 挂给判题沙箱的是仓库根的 data/test_case）。
- sql.js / tree-sitter 的 wasm、jieba 的 .node 和 4.8MB 词典，
原来都靠运行时 require.resolve / Bun.resolveSync / __dirname 去 node_modules 里找。
全部改成 `with { type: "file" }` 内嵌成资源。jieba 尤其绕：它的 index.js
运行时探测平台再 require 子包，dict.js 用 __dirname 读 dict.txt，两条都
依赖磁盘布局，所以单独包了 vendor/jieba.ts 直接 require 内嵌的 .node。
- SQL 判题要 spawn 一个能被 SIGKILL 的子进程，原来 spawn 的是 child.ts 的路径，
编译后那个文件不存在。改成二进制自己按 argv 分发：新增 main.ts 作为唯一入口，
serve / worker / sql-child 三个子命令，镜像里只需要一份运行时。
## 顺带修掉一个能拖垮生产的坑
「spawn 自己」意味着只要 argv 分发这一环出问题（子命令改名没同步、compose 里
command 写错、拿别的入口编了二进制），「起自己」就变成「把整个程序再跑一遍」，
而那一遍又会 spawn 一个自己 —— 指数增长。
这不是假想：开发时用一个没有分发器的临时入口编了个二进制，一跑就递归 fork
105MB 的进程，几秒触发 global OOM，内核把开发机的终端杀了
（`selftest invoked oom-killer ... Killed process ... Alacritty`）。
同样的错误发生在服务器上就是判题机连同数据库一起拖死。
加了递归闸：父进程 spawn 时打 OJ2_SQL_CHILD 标记，带标记的进程一律拒绝再 spawn，
最多一层就停在一条明确的 SYSTEM_ERROR 上。
## 验证
产物拷进只有它自己一个文件的目录，2G 内存上限下跑，7 项全过：
jieba 分词（自定义词「循环结构」「死循环」命中）、tree-sitter Python3/C 各两条
（含一条**预期失败**的规则做对照，否则「语言没加载成功」和「规则通过」返回值
一模一样，分不出来）、SQL 判题 AC、SQL 只读防护仍拦住 PRAGMA。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 23:13:57 -06:00
xuyue and Claude Opus 5
cd5dd16f3b
feat(阶段4): 测试用例压缩包上传与下载
...
POST admin/test-cases
GET admin/problems/:id/test-cases （返回 zip 二进制）
落盘格式必须与判题沙箱镜像的约定一致（沙箱直接读挂进去的目录），已用真判题验证：
上传 zip → 建题 → 提交 Python 解法 → 沙箱读到用例并判出 Accepted。
安全与健壮性上比旧后端多做的几件事：
- **zip slip 从设计上进不来**：不遍历压缩包条目，只按精确文件名（`N.in`/`N.out`/`N.sql`）
取内容，条目名一律不参与路径拼接。实测带 `../../etc/passwd` 条目的包能正常处理，
且只取到 1.in/1.out。
- 单文件 32MB、解压后总量 128MB、测试点数 500 的上限，防 zip bomb 与写满磁盘 ——
旧后端一概没有，机房那台机器盘写满之后判题也会一起挂。
- 坏 zip 返回 400 而不是 500。
对齐旧后端的细节：CRLF→LF 归一；`stripped_output_md5` 按 Python `bytes.rstrip()`
的口径只剥尾部 ASCII 空白后再算（实测与 hashlib.md5 结果一致）；编号从 1 起连续、
遇缺口即停；SQL 包至少 2 个测试点（题目页会展示测试点 1 的期望结果，只有一个时
学生可以对照着硬编码 AC）；目录 0710、文件 0640。
## 顺带修掉一个只在判题时才暴露的路径 bug
config 里的相对路径（data/test_case、data/avatar、data/upload）原先按进程 cwd 解析，
而起服务的方式会把 cwd 切到 apps/api/，于是测试点落在 apps/api/data/ 下 ——
但 docker/compose.dev.yml 把**仓库根**的 data/test_case 挂进判题沙箱。两边不是同一个
目录，新传的测试点判题时会「找不到测试数据」，且只在真正判题时才暴露。
改成一律按仓库根解析，实测沙箱能看到新传的目录。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 16:42:54 -06:00
xuyue and Claude Opus 5
7e1a782747
feat(阶段4): 用户管理 + 成就管理；补上 rescan 与 contest_joined
...
GET/POST/DELETE admin/users （DELETE 走 body 传 ids）
GET/PUT admin/users/:id
POST admin/users/:id/reset-password
GET admin/achievement-metrics
GET/POST admin/achievements
GET/PUT/DELETE admin/achievements/:id
顺带补了新后端缺失的两块（不补的话成就后台建出来的东西是坏的）：
1. **rescanAchievement**：旧后端 `rescan_achievement` 的对应实现。判定平时只在判题
结算时发生，后台新建成就或调低阈值不会自动补发，必须显式扫一遍。补发标记
backfilled=true —— 前端据此只显示「已获得」不显示日期，否则一次补发会给几百人
盖同一个时间戳，把「最近获得」板块冲垮。
触发判据包含 metric 与 visible 的变化，不只看 operator/threshold：换维度、
以及从下架改上架（草稿期已达标的人）这两种都会漏。
2. **contest_joined 指标整个漏掉了**。旧 METRIC_REGISTRY 有 18 个指标，新后端只算
17 个，配在这个指标上的成就永远解锁不了。已补上计算，并把注册表抽成
services/achievement-metrics.ts 作为单一事实源 —— 后台下拉框和参数校验都读它，
避免「下拉框里选得到但没人算」这种组合。
用户管理的几处要点：
- className 解析位数不对**直接报错不猜**。猜错会把 class_name 存歪，而剥前缀显示
姓名、班级下拉、统计页都依赖它准确。
- problem_permission 按 admin_type 归一（超管恒 All、普通用户恒 None），否则把超管
降级成普通用户后他还留着 All。
- 改用户名要同步 submission.username 这个冗余列，否则历史提交查不到。
- openApi 已开着就不重置 appkey，否则每次保存用户都把对方的 key 换掉。
- **删除用户不复刻 Django 的应用层级联硬删**。用户是被引用最广的一张表，改成让
数据库外键拦下来：撞外键说明还有历史数据，应当禁用而不是删除，返回 409 并说明。
实测：学生 403；导入 2 人 / 重复 409 / 班级号位数报错文案正确；改名+降权后
permission 归一为 None、重名 409；重置密码 6 位无 0；删自己 400；
成就指标 18 项、新建后补发 unlockCount=2、野指标与野稀有度均 400。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 07:27:36 -06:00
xuyue and Claude Opus 5
20ecc05f63
fix(Minor M2): 比赛权限加中间件兜底
...
旧后端用 @check_contest_permission 装饰器，漏挂一眼看得出来；新后端手工在 handler
里调 canAccessContest，漏调一次就是静默放行，而且这类路由挂的是 optionalAuth
（本身不拦人），从路由注册那一行完全看不出它受保护。
新增 requireContestAccess(checkType, paramName)，把「取比赛 → 404 → 鉴权 →
401/403」四步收进注册行。手工调用点 5 → 2：
- GET /contests/:id/access —— 报告权限而非强制，不能 403，留手工
- POST /submissions —— 比赛 id 来自请求体，中间件跑时 body 还没解析，留手工
两处都就地写了说明。canAccessContest 改成泛型，因为 Hono 的 Context 在
Variables 上逆变，写死 Context<AppEnv> 与 ContestEnv 不兼容。
实测拦截行为不变：匿名 401、登录 200、密码赛未过密码 403。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 07:00:58 -06:00
xuyue and Claude Opus 5
836d97847e
feat(阶段3): 补齐用户侧依赖的三个 admin 端点
...
重判、提交统计、流程图统计这三条挂在旧后端的 admin 路由下，权限也确实是
teacher/super admin，但入口在用户侧页面里（提交列表页的重判按钮、两个统计面板）。
不做完，阶段 3 的出口标准「用户侧全部功能跑在新后端上」就不成立 —— 按 URL
前缀切阶段会漏掉它们。
- POST submissions/:id/rejudge ← GET admin/submission/rejudge
- GET submissions/statistics ← GET admin/submission/statistics
- GET flowcharts/statistics ← GET admin/flowchart/statistics
几处对齐旧后端的细节：
- AST_CHECK_FAILED(10) 与 ACCEPTED(0) 同算通过
- 完成度先用原始花名册人数算、再修正 person_count，顺序照搬，兜住「学生已删号
但提交记录还在」
- 有提交但零通过的学生，两个名单里都不出现（旧后端同样口径）
- 词云用 @node-rs/jieba，STOPWORDS 与 38 个自定义词逐词照搬；jieba@2 没有
insertWord，改用 loadDict 加载用户词典
- avgScore 分母是有分数的条数，对齐 Django Avg() 跳过 NULL
rejudge 的 jobId 带时间戳。队列保留最近 100 个已完成任务，沿用 submissionId
做 jobId 的话 BullMQ 会认为任务已存在，重判会静默变成空操作。
correctRate 改成数值不带 %，展示格式化交给前端。stripClassPrefix 用
startsWith+slice 而不是 replace，前缀对不上时不会从中间截出乱码；site.ts
原有的 replace 写法一并改掉。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 06:48:05 -06:00
xuyue and Claude Opus 5
8237909d00
fix(阶段3): 提交可见性守卫补上匿名，详情脱敏，提交接口加限流
...
F3：`isRegularUser(user)` 对匿名用户（user 为 null）返回 false，
`submission_list_show_all` 关闭时守卫整体短路 —— 匿名能看到全部提交，
权限反而大于登录学生。实测开关关闭时匿名 total=23、登录学生 total=0。
而关闭这个开关的典型场景正是考试。改为 `!isAdminRole(user)`（非管理员即受限），
并删掉 isRegularUser（全仓只有这一处调用，留着就是下一个坑）。
F4：提交详情把 info（含每个测试点的 test_case 编号与 output_md5）与 ip
按「是不是自己的提交」下发。旧后端 submission/views/oj.py 把关的是角色：
is_admin_role() 决定用 SubmissionModelSerializer 还是
SubmissionSafeModelSerializer(exclude=("info", "contest", "ip"))。改为仅管理员可见。
F6：旧后端 SubmissionAPI.throttling 的 TokenBucket 没搬过来。
按旧参数重建（options/options.py:120 的 user 桶：capacity 20、fill_rate 0.03、
default_capacity 10，实际值仍以数据库 throttling 配置项为准），
落在 redis 上并改用 Lua 脚本做成原子操作 —— 旧实现自己注明「不是线程安全的」，
而限流要挡的正是并发突发。挂点位置与旧后端一致：比赛权限校验之后、取题目之前。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 01:59:19 -06:00
xuyue and Claude Opus 5
8c00cdc947
feat(阶段3): oj 侧端点铺开（基线提交，未经评审）
...
由外部 agent (Codex) 在本会话额度中断期间完成。原样提交作为基线，
后续修复单独成 commit，便于区分与回退。
覆盖 oj 侧 65 个端点，新增 9 组路由（account/achievement/ai/classroom/
content/contest/flowchart/problemset/site）与对应 Zod 契约。
已核验：tsc --noEmit 退出码 0；API 可启动；/api/problems 返回真实数据；
judge 与 flowchart worker 均 ready。
未核验：权限边界与数据泄露，评审进行中。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com >
2026-08-07 01:25:36 -06:00
xuyueandClaude Opus 5.5