|
|
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 |
|
|
|
91712b482d
|
fix(AST): f-string 规则从上线起就没生效过；加 check:ast 把这类静默错判变成机器检查
Deploy / deploy (push) Has been cancelled
## check:ast
判题机拿 target 的 node 去比 tree-sitter 节点类型，**对不上不报错**：collectNodes 一个
都收不到，于是「必须使用 X」永远失败、「不能使用 X」永远通过，两头不报错，只有学生
受着。上一个提交把两张表合成一张，杜绝了「漏配」，但「配错」照样静默 —— 所以加一个
检查，逐个 target 去问语法：这个节点类型你到底有没有。
bun run --filter '@oj2/api' check:ast
升级 tree-sitter-* 之后必须跑：语法改节点名是常事，后果全静默。它只验节点类型存在，
不验语义对不对（把 while_loop 配成 for_statement 这种两个都存在，机器看不出来）。
## 它抓出来的那个
56 个 target 里坏了一个：Python3 的 f_string 一直配的是 format_string，而这个版本的
tree-sitter-python **根本没有这种节点** —— f-string 是一个 string，靠 string_start 为
f" 和内部的 interpolation 子节点来认。也就是说「不能使用 f-string」这条规则从上线起
就一直判成通过，「必须使用 f-string」一直判成失败。
改成 interpolation。实测：带占位符的 f-string（单双引号都有）命中，而 % 格式化、
.format()、普通字符串、字符串拼接都不误伤。代价是 f"abc" 这种没有占位符的 f-string
认不出来 —— 它确实不含 interpolation，但没占位符的 f-string 本来也没意义，比起原来
「一个都认不出来」是严格的改善。这条写在表里的注释上了。
## 验证
给题目 1004 配「必须有 for 循环 + 不能用 f-string」两条规则实跑：
- 有 for、用了 f-string → 修复前 ACCEPTED(0)，修复后 AST_CHECK_FAILED(10)，
ast_results 为「必须使用 for 循环/通过」「不能使用 f-string/不通过」；
- 有 for、不用 f-string → ACCEPTED(0)；
- check:ast 修复前 exit 1 并指出这一条，修复后 56 个全过、exit 0。
tsc、check:routes、vue-tsc、vite build、单二进制编译均通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH
|
2026-09-10 19:33:19 -06:00 |
|
|
|
a6ba5cdf07
|
refactor(AST): 两张 target 表合成一张，加节点类型漏配在结构上不再可能
契约的 AST_NODE_TARGETS_BY_LANGUAGE 是 target → 中文名，judge/ast.ts 的 mappings 是
target → tree-sitter 节点类型，同一批键分在两个包里，靠一句「两边必须同增同减」的注释
维持。只加一边是静默错判：老师给 C 题选到只有 Python 有的 list_comprehension，判题机
拿裸名去比节点类型，C 的语法树里永远不存在它，于是「必须使用列表推导式」永远失败、
「不能使用 f-string」永远通过，两头都不报错，只有学生受着。
现在一个 target 一条 { label, node }：label 给后台下拉和题目页，node 给判题机。加 target
而漏配节点类型在结构上就不可能了。judge/ast.ts 的 mappings 整张删掉，解析统一走契约的
astTargetNodeType()（节点查 node，运算符查运算符表 —— 那张表的值本身就是要比的 token，
判题机原来抄的 and→&& 三条取值逐个相同，纯属重复）。
顺带把同一份数据的四份拷贝收成一份：C 的 14 条原来在契约和判题机里各抄了两遍
（C 一份、C++ 一份），现在 C++ 逐条引用 C_NODE_TARGETS；运算符表的 C++ 改成
{ ...C_OPERATOR_TARGETS, "<<", ">>" }。C++ 那几条仍逐条列出而不是 spread，是为了保住
下拉框的显示顺序（C++ 独有的几条插在中间）。
## 验证
行为零变化，是逐个 target 机械比对过的：把 HEAD 版的两张表原样取出来，对三种语言的
全部 target 比对「label / 运算符文案 / tree-sitter 解析结果 / 下拉框顺序」四项 ——
C 37 个、C++ 47 个、Python3 43 个，全部一致，键集与顺序也一致。
实跑：给题目 1004 配两条 Python3 规则（必须有 for 循环、不能用 f-string），交一发没有
for 循环的正确答案，判成 AST_CHECK_FAILED(10)，statistic_info.ast_results 为
「必须使用 for 循环 / 不通过」「不能使用 f-string / 通过」—— label 与 node 两半都走到了。
再交一发带 for 循环的，判成 ACCEPTED(0)。
tsc、vue-tsc、vite build、单二进制编译均通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH
|
2026-09-10 19:30:35 -06:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
684f2d29a5
|
feat(契约): 练一练的内容按题型收进契约，7 个题型组件不再裸读 data
Deploy / deploy (push) Has been cancelled
`Exercise*.vue` 七个组件直接读 `data.question` / `data.options` / `data.lines`，
而契约里 `data` 是 `Record<string, unknown>`（后端不校验）、前端只做了类型收窄
—— 也就是说这条路径**从来没有在运行时被看过一眼**，结构对不上时渲染期才炸。
现在 exerciseSchema 用 superRefine 按外层 `type` 分派到对应的内容形状，
外层与 data 对不上也会被抓住（`type: "mcq"` 配 `{question, code}` 会在渲染
mcq 组件时炸在 `data.options`）。七个题型的键集按生产库实测确定。
**这个 schema 后端也在 parse**（routes/content.ts 的 `exerciseSchema.parse`），
所以收紧它同时是一道服务端闸门：坏数据会让练习列表 500。因此先用生产全量
数据核验：151/151 通过，且反向验证确认能抓住题型与 data 不匹配的情况。
`getExercises` 另加了一层逐题型校验，让前端也能把内层分歧记进
`__OJ2_CONTRACT_DRIFT__`；`z.infer` 拿不到判别联合（superRefine 无法把校验
结果反映到推断类型上），所以类型上仍需一次经过 unknown 的断言 —— 它不掩盖
未经检查的分歧，因为运行时那一步已经做过。
顺带补上 getFlowchartSubmission 的闸门；被守卫端点达到 41 个。
验证：vue-tsc 与 tsc -p apps/api 均 exit 0；vite build 通过；check:routes 无遮蔽。
|
2026-09-10 04:28:26 -06:00 |
|
|
|
de34a47996
|
refactor(契约): 契约闸门铺到其余学生端接口，并清掉与契约等价的重复类型
Deploy / deploy (push) Has been cancelled
## 闸门覆盖
从 7 条扩到 20 条：竞赛列表/详情/口令/榜单、题单列表/详情/题目/徽章/进度、
全服榜与活跃榜、公告列表/详情、教程、用户度量、流程图历史/当前/统计、
提交统计与统计明细、相似题目、题目 AC 榜。
## 顺手把两处形状收进契约
- `contestRankItemSchema.submissionInfo` 原来只是 `Record<string, unknown>`，
前端被迫再声明一份 `SubmissionInfo` 去覆盖它。现在 JSONB 的 snake_case 形状
（is_ac / ac_time / is_first_ac / error_number / checked）进了契约，那层覆盖随之消失。
- 竞赛题目列表用 `problemListItemSchema.array()` 而不是契约里的
`contestProblemsSchema` —— 后者是 `array(union([列表项, 详情]))`，联合类型会让
`filterResult` 的类型收窄落到详情分支，而且学生侧这条接口只下发列表项。
## 清掉两处确证重复的派生
用类型探针（双向可赋值）逐对验证，`Problem` 与 `Message` 的本地派生与契约**完全等价**，
是没有内容的重复：`Problem` 的 languages/template 收窄、`Message` 的 submission 收窄
都已经在前两轮搬进契约。其余七处派生（Submission 的 result|9、Profile、AdminProblem、
Exercise、ContestRank、BlankProblem、TutorialEdit 等）探针确认**不等价**，都有真实理由，
一律保留。
`Problem` 原来还挂着 hasAstRules / visible / answers 三个可选字段，探针证明它们对
赋值没有影响（契约里本来就有 hasAstRules），去掉后没有任何调用点报错。
## 验证
- vue-tsc 与 tsc -p apps/api 均 exit 0；vite build 通过；check:routes 无遮蔽；
- 契约 schema 直跑真实接口：学生会话 13 通过 / 0 失败，管理员会话 15 通过 / 0 失败；
跳过的三条都是预期的权限或空数据（/submissions/statistics 与 /flowcharts/statistics
要教师权限、/users/:id/metrics 只统计公开提交）。
|
2026-09-10 04:23:41 -06:00 |
|
|
|
aab0404ed7
|
refactor(契约): 语言与判题产物的形状收进契约，学生端高频响应接上运行时校验
Deploy / deploy (push) Has been cancelled
契约在前端一直只当类型包用：45 处引用里几乎全是 import type，三个 .parse() 后面
还都紧跟一个 as 把校验结果断言回去，等于没校验。这一轮把形状的来源收拢。
## 语言：三份真相并成一份
前端 utils/types.ts 手写了一份 9 值的语言联合，后端 judge/languages.ts 有自己的一套，
生产库又有一套。手抄那份**漏了 SQL**，而生产库 961 道题里有 9 道 SQL 题、
124191 条提交里有 91 条 SQL 提交 —— 这些提交的 language 在前端类型上是 undefined。
现在唯一来源是契约的 problemLanguageSchema，constants.ts 的显示映射以它为键，
契约里加语言而那边没补映射会当场编译不过。
## 判题产物：按生产数据实测收紧
judgeInfoSchema / statisticInfoSchema 的形状来自 124191 条提交的实测，不是手抄：
- info.data 有 12048 条是 null（编译失败等没有逐测试点结果），前端手抄的 Info
却把 data 写成非空数组 —— 这 12048 条在类型上根本不成立；
- info 还允许**空对象**：非管理员看提交详情时后端下发 info: {}（权限投影）。
收紧时必须把它算进去，否则每条非管理员看的提交详情直接 500 —— 本地实测复现过；
- statistic_info 的五个键按出现次数定成全部可选；另有 8916 条 JSONB 原文因内嵌
带转义的 shell 输出不是合法 JSON，被后端 objectValue() 兜成 { value: ... }，
所以不能用严格对象，否则这 8916 条会被误判成分歧。
## 运行时闸门
新增 utils/contract.ts：safeParse 失败时记一条分歧（去重、控制台可见、
window.__OJ2_CONTRACT_DRIFT__ 可查）后**放行原始数据**，不白屏 —— 面向学生的
生产站点，字段空着比整页崩掉可接受。接在 7 条高频链路上：/site、/site/online、
/problems、/problems/:id、/submissions、/submissions/:id、/me。
提交详情的 info 是联合类型，调用方不再直接取 .data，统一走
utils/functions.ts 的 submissionCaseResults()。
## 验证
- vue-tsc 与 tsc -p apps/api 均 exit 0；vite build 通过；
- 契约 schema 直跑真实接口：7/7 通过（自包含脚本，从登录到详情全链路）；
- 用生产备份复核收紧后的约束：961 题的 languages 无越界值，template 只出现
C/Python3 两个键 —— 不会因为这次收紧在生产上抛错。
|
2026-09-10 04:19:41 -06:00 |
|
|
|
26b23aa7c0
|
fix(统计): 「提交记录」列出所有交过的人，不再只有做完的
Deploy / deploy (push) Has been cancelled
统计面板那张表原来只给 `isDone` 为真的人，于是一次没对的学生连同他的提交
在面板里根本不存在——tab 却叫「提交记录」，看起来就像统计只认成功的提交。
- `data` 改成给窗口里交过东西的全部人，每行带 `done`；「完成人数」和完成度
跟着 `done` 数，不是 `data.length`，两个数字口径不变。
- 表格加「完成」列区分两种人；展开行拉的仍是那个人的全部提交（items 接口
本来就不按结果过滤），对错都在里面。
- 「交了没全对」那一栏原来无条件按花名册取，不填班级/用户名时花名册为空、
整栏跟着空掉，这批人两栏都不在。改成没有花名册时退回「有提交但没做完的
全部普通学生」，教师和禁用账号仍然排除；全站视图里保留完整用户名不剥班级
前缀。「还没交」那一栏没有花名册是真算不出来，仍然为空。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PZbWEaPCnGvmdfNFpPFNGb
|
2026-09-08 23:52:34 -06:00 |
|
|
|
9c5a1d551d
|
perf(教师统计): 展开行的明细改成按需拉，统计响应不再背着 4.9 万行没人看的数据
Deploy / deploy (push) Has been cancelled
上一版把明细收成「只取有 AC 的人、每人最近 50 条」，拿生产快照（12.4 万条提交）
实测下来只从 105631 行降到 49108 行 —— 2.1 倍，不是一个数量级。原因是绝大多数人
本来就不到 50 条，每人截断那道闸在真实分布上基本没咬到，最坏情况响应体仍有 ~2.4MB。
真正的问题是形状不对：表格一次只展开一行（updateExpandedRowKeys 只留最后一个 key），
却给 1900 个人各准备了一份。所以明细整个从统计响应里拿掉，改成展开时按需拉：
- 新端点 `GET /submissions/statistics/items`，要用户名 + 同一套时间窗和题号。
用户名这里是**精确匹配**，不是统计接口那种 ilike —— 那边填 ks251 要圈出整个班，
这边是「点开的这一行是谁」。上限 200 条，多取一条来判断 truncated，被截断时
展开行里说明「只显示最近 200 条」，免得老师以为这人就交了这么多。
- 时间窗和题号抽成共用的 statisticsScope，两个接口必须同一个范围，否则展开行
看到的是另一个窗口的数据。
- 前端按人缓存，收起再展开不重拉；每次重新统计（含 15 秒自动刷新）清缓存，
并把当前展开着的那一行重拉一遍 —— 展开行跟着一起活着，不然刷新之后上面的数
变了、下面的明细还是老的。
- 去重放在 loadItems 里：点一行会同时走 rowProps 的 onClick 和表格的
update:expanded-row-keys，两边都想拉，改之前真发出了两条一模一样的请求。
顺带把 submissionItems 从 submissionStatisticsUserSchema 里删掉。
生产快照上的验证（12.4 万条提交 / 1956 用户 / 961 题，恢复进一次性容器跑完即删）：
- 最坏情况（全部时段 + 不填条件）少搬 49108 行，约 2.4MB
- 真实课堂量级（最忙的一小时：583 条提交 / 81 人）四条查询分别是
主聚合 45ms、明细 6.5ms、语法未过 2.4ms、最近错因 <1ms
- 「已解决」那条口径修正的实际影响：13.3% 的「人×题」有重复 AC，同一题最多 AC 45 次；
按人看最夸张的是 419 条 AC 其实只有 38 道题
- 语法要求的题 15 道、result=10 共 57 条，其中「最后也没改对」的 18 个人×题
—— 角标会出现，但稀有
浏览器实跑：展开前不发明细请求；展开后 1 条、12 个按钮；收起 +0、再展开 +0（走缓存）；
自动刷新时统计与明细 1:1 配对、间隔 15 秒，没有重复请求。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd
|
2026-09-08 05:43:32 -06:00 |
|
|
|
f66bafafaf
|
feat(教师统计): 提交统计面板返修 —— 统计口径、未完成分两栏、多题、自动刷新
排查这个面板时发现的一串问题和缺口，一起修掉。改动集中在
`GET /submissions/statistics` 和 `StatisticsPanel.vue`，两边互相咬着，
拆不成独立的 commit。
**「已解决」数的不是题数**（真在显示错数字）。`count(*) filter (accepted)`
按用户名分组、没有 distinct problem_id，同一道题重复 AC 会重复计数。查单道题时
看不出来，老师查「这节课全班」时「已解决 5」可能是同一道题交了 5 次。新增
`solvedCount = count(distinct problem_id) filter (accepted)`，表格那一列换成它；
`acceptedCount` 保留，正确率的分子仍然是提交条数。
**正确率把判题中的算进了分母**。PENDING / JUDGING 进分母不进分子，全班同时交卷的
那几秒正确率凭空掉一截 —— 而老师盯着看的就是这个数。分母改成判完的条数，
`UNJUDGED_RESULTS` 提到 judge/status.ts 共用。总提交仍是全部条数（交了就算交过，
否则人数口径会跟着变，正在判的学生会掉进「没交」名单），另外下发 `judgingCount`，
非零时面板多显示一块「判题中」，三个数字才对得上。
**「未完成」实际是「一次没交」**。做了但一次没对的学生既不在「完成人数」也不在
未完成名单，等于从屏幕上消失 —— 而那恰恰是最该去看一眼的人。新增
`dataAttempted`，未完成栏拆成「还没交」/「交了没对」两组，tab 计数是两者之和。
请假隐藏对两组同时生效：他们同样占着班级人数这个分母，只藏一半会把完成度算错。
**点名字能看到错在哪**。`dataAttempted` 带上最近一条提交的题号、状态和
`statistic_info.err_info`（截断 400 字），点名字弹出来，还能一步跳到代码。
老师不用再切到提交列表、翻到这个人、点开代码。
**支持一次查几道题**。题号框接受 `1001,1005,1010`（中英文逗号、分号、空格都当
分隔符，投影前手敲不该因为打了全角逗号就查不出来），有一个题号不存在就整体 404。
**完成 = 这几道全解决**；只填一道时和原来完全等价，不填题号时退回「至少做出一道」。
差一道的人落在「交了没全对」里，名字后面缀 `2/3题`。
**零提交时整块面板消失**。判空条件是 `count.total > 0`，可一节课刚开始一条提交都
没有、后端已经把整份花名册当作「未完成」返回了 —— 最该看名单的时刻反而只显示
「暂无数据」。流程图那边更彻底：`/flowcharts/statistics` 的零提交分支把
`dataUnaccepted` 写死成空数组，名单压根没下发。
**面板不会自己刷新**。打开是空的、要点一次按钮，拿到的是那一刻的快照。改成打开即查
+ 每 15 秒滚动重查，页面切到后台就停，关掉面板随组件卸载停掉。上一次没回来就跳过
这一次。班级从手打 `ks251` 换成下拉（选项来自网站配置的 class_list，和登录框同一份），
保留自由输入，查过的班级记进 localStorage 下次带上 —— 机房电脑一台对一个班。
**明细查询没有 LIMIT**。展开行用的 submissionItems 原来把窗口内**全部**提交捞进内存
再原样序列化，「全部时段 + 不填条件」就是十几万条。改成只取有 AC 的人、每人最近 50 条，
截断用窗口函数发生在数据库侧；表格「提交数」仍是真实总数。
**顺带**：`personRate` 前端从来没读过（完成度是前端按「减掉请假人数的分母」自己算的），
从契约里删掉；「语法未过」的题数单列出来（AST_CHECK_FAILED 全站仍然算通过，口径没动，
只是让老师看得见谁是绕过语法要求做出来的，那批人教学上没达标）。
实跑验证（dev 全栈 + 浏览器）：
- 已解决：student 两条 AC 都在题号 5 上 —— 改前显示 2，改后显示 1
- 正确率：临时把两条改成 PENDING/JUDGING，12 条提交 2 条通过 —— 16.67% → 20%，
面板多出「判题中 2」，表格显示「12（2 条判题中）」
- 未完成两栏：student2 没交、student 交了 12 次没对，请假隐藏 student 后
班级人数 2→1、tab 2→1、出现「恢复 1 位」
- 错因弹层：点 student 弹出「最近一次：1020 · 编译失败 / Test case not found / 看代码」
- 多题：`1004` 完成 1 人；`1004,1005` 完成 0 人、交了没全对 student 1/2题 8次；
全角逗号同上；`1004,9999` 报 `Problem 9999 does not exist`
- 自动刷新：打开即发请求，之后 04:44:22 → 04:44:36 → 04:44:51 → 04:45:06 每 15 秒
一次且窗口跟着滚；关掉面板后 20 秒请求数不再增长
- 班级下拉：选「25计算机1班」→ ks251，重开面板自动带上并立刻查
tsc / vue-tsc / check:routes 全过。验证用的 dev 库改动已还原。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd
|
2026-09-08 05:20:51 -06:00 |
|
|
|
6a438872b9
|
feat(排行榜): 页头显示当前在线人数，在线绿点只给老师
Deploy / deploy (push) Has been cancelled
新增匿名可读的 GET /api/site/online，一条 ZCOUNT 让 Redis 自己数，
不拉成员、也不写（清理过期成员留给后台列表，匿名接口不带写操作）。
榜单页进页面拉一次，为 0 时不显示。
/rankings/users 的 isOnline 是三态：null 表示「这个调用方不该知道」，
只有老师及以上拿到 true/false。写成普通 boolean 的话学生看到的 false
和真的离线分不开，等于默认把每个人的在线状态摊给全校同学看。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xu912Rv5JUUuy6MqMcQW2
|
2026-09-07 19:36:12 -06:00 |
|
|
|
856b7a280e
|
feat(后台用户): 新增「在线优先」排序，列表直接显示在线标记
在线状态库里没有、会话也判定不了 —— session 的 TTL 是 7 天且每次请求续期，
「有会话」只说明这人一周内来过。新开一个 Redis sorted set（auth/presence.ts）
记最后活动时间，5 分钟内有活动算在线。
写入全搭在已有的 pipeline 上，不多一趟往返：登录、每个带鉴权请求的续期、
以及 touchSession —— 只挂着 WebSocket 不发请求的人靠最后这条，sweepSessions
每 60 秒一轮，所以窗口取 5 分钟，明显大于那个间隔。登出、改密码、禁用账号
会立刻把人摘掉；过期成员在后台读列表时顺手清理（整个 key 不能设 TTL，
ZADD 不重置 key 的 TTL，到期会把还在线的人一起抹掉）。
排序 orderBy=-online 先捞在线 id，SQL 里 case when 分两档，档内继续按
最近登录排；没人在线时那个 case 恒等于 1，直接省掉。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017xu912Rv5JUUuy6MqMcQW2
|
2026-09-07 19:30:45 -06:00 |
|
|
|
25b86ec17e
|
refactor(提交): 删掉从来没用起来的「提交互相可见」
Deploy / deploy (push) Has been cancelled
problem.share_submission（题目级）和 submission.shared（单条）两个开关，连同
判定分支一起删掉。
生产备份（2026-08-07）里的实际用量：956 道题只有 2 道开过 share_submission，
还都是 contest_id=1 的比赛题 —— 比赛未结束时那条分支根本走不到，等于一天都没
生效过。123140 条提交里 shared=true 的有 40 条，39 条在 2022 年、1 条在
2023-03-30，之后近三年零使用；出题页从来没给过题目级开关，单条分享的入口在更早
那版前端上，ojnext 和 OJ2 都没搬过来，OJ2 里 PUT /submissions/:id 一个调用方
都没有。
canViewSubmission 剩下三条：本人 / 管理员（比赛中的 Student Admin 除外）/ 本题
作者，其余一律看不到。结尾的 `shareSubmission || shared` 没了；它上面那条「比赛
未结束一律不给」也一并去掉 —— 走到那里的必然不是这三种人，现在无论比赛与否都是
false，留着是重复的。allowShared 参数随之消失，它唯一的用途就是分享开关的归属
校验。
一并删掉：PUT /submissions/:id、响应里的 shared / canUnshare（列表、详情、站内
信内嵌三处）、题目详情与后台题目里的 shareSubmission、shareSubmissionRequestSchema，
以及新建提交时那句 shared: false（列上本来就有 default false）。
两个数据库列保留不删，只在 schema.ts 上注明已停用：删列是破坏性迁移，而留着不读
不写零成本，还留着那 40 条的历史痕迹。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XvmqDsZNyUo9P3sFQtoWVB
|
2026-09-07 07:18:41 -06:00 |
|
|
|
2256597838
|
fix(后台建题): 修好 dev 代理走错服务，以及新建页带出上一题 id、超长标签报英文
三处不相干的小毛病，都在「新建/编辑题目」这条路上。
vite 的 /api 代理写的是 localhost:3000。api 用 Bun.serve 起、只绑 IPv4 的
0.0.0.0:3000，而 Node 解析 localhost 时 ::1 排在前面 —— 别的项目的 dev server
一占 [::1]:3000，两边端口就不冲突（一个 v4 一个 v6，谁都不报错），浏览器发出的
/api/* 整个落到那个站上，表现是后台一进就被弹回首页。改成 127.0.0.1。
新建页和编辑页共用同一个 localStorage 草稿键，而编辑页会把服务器数据连 id 一起
写进去。没保存就离开的话，这个 id 跟着草稿漂到新建页：「下载测试点」下的是那道旧
题的包，SQL 测试点编辑器也会去回显那道旧题的脚本。新建分支进来先把 id 摘掉。
新标签没有长度限制，超过 32 字要到保存时才撞出 zod 的英文原文（Too big:
expected string to have <=32 characters）。把 32 提成契约里的
PROBLEM_TAG_MAX_LENGTH，输入框拿它做 maxlength，validateNewTags 再兜一道粘贴
绕过的情况，提示换成中文。校验的松紧没动，32 字仍然存得进、33 字仍然拦下。
editContestProblem 和 editProblem 函数体逐字相同（都是 PUT admin/problems/:id，
比赛由后端从题目自己推导），合成一个。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XvmqDsZNyUo9P3sFQtoWVB
|
2026-09-07 07:18:23 -06:00 |
|
|
|
bb0f5ec5ef
|
fix(AI提示): 解锁条件前后端对齐，提示不再一点就没
Deploy / deploy (push) Has been cancelled
「失败 3 次解锁 AI 提示」实际是「在当前这次页面会话里再失败 3 次」：
problemStore.failCount 是个从 0 起数的内存计数器，刷新、切题、跳进跳出就归零，
而后端闸门数的是数据库里的历史失败数，两边根本不是一回事。昨天在这题上撞了
十次墙的学生今天进来照样看不到按钮。
- 数法收成一个 countFailedSubmissions()，题目详情的 myFailedCount 和
POST /ai/hint 共用。原来详情把「等待/正在评分」也算失败，连点三次提交就能
把按钮点亮，点下去却回 hint-locked
- 阈值 3 挪进契约 HINT_MIN_FAILURES，两端引用同一个常量
- failCount 改成 myFailedCount + 本次会话增量；在题目页里登录的补拉一次详情，
否则停在匿名时的 0
- 结果面板改 display-directive="show"，不再一收起来就把流式输出中的提示连同
那次 LLM 调用一起作废；补「上次结果」按钮，原来唯一的重开方式是再提交一次
- prompt 里的判题结果翻成中文，原来拼的是裸状态码，模型不知道 -1 是什么
- system_error 不计入失败数、也不显示按钮：判题机自己崩了不是学生的问题
- 比赛中不给提示，和「求助」按钮同一个口径
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RC5uL72UY9aZFuTvUKe2jv
|
2026-09-06 07:24:26 -06:00 |
|
|
|
8a88fe8d99
|
feat(智能分析): 解题表格改服务端分页，/ai/detail 不再下发整份 solved
Deploy / deploy (push) Has been cancelled
原来 /ai/detail 把区间内做出来的每道题连排名带等级整份下发，一个活跃学生一年几百道，
一次请求就是几百 KB，而表格一屏只看得到二十行。
拆成两支：
- GET /ai/detail 只留聚合（solvedCount、difficulty、tags、attempts、activity、errors…）
- GET /ai/solved?offset&limit 按首次通过时间升序分页给逐题明细
排名只跟当前这批题有关，所以分页那支只算一页的 problemIds，不必把整年算一遍。抽出
firstAcQuery / buildSolved / listSolved 三个函数，detail 和分页两边共用。
前端相应改动：
- 难度分布改读后端的 difficulty 聚合（本来就在下发，之前是从逐题列表里现数的）
- 几次做对改读新的 attempts 数组（每道题的尝试次数）；tooltip 里的题名去掉了 ——
明细是分页拿的，不该为了一个 tooltip 把全量拉回来
- Overview 用 solvedCount
- SolvedTable 的代码提交那张走 remote 分页，流程图那张仍是本地分页（一个 OJ 的
流程图题就那么几道，全量下发没问题）；换时间范围回到第一页
- 表格原来是 max-height 1500 的滚动区，现在由分页兜住，滚动条和分页器不再并存
/ai/analysis 的 prompt 仍然带逐题明细（少了它模型只剩聚合数字），但顺手卡了 200 条 ——
以前是整份 solved 无上限塞进去，题做得多的学生一次调用能顶好几倍 token。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LZuPwqDmLEiK9zgQ9z9sVn
|
2026-09-03 03:18:18 -06:00 |
|
|
|
4d7be969d9
|
refactor(智能分析): 重排版面，砍掉重复的三张周期图，补三个新维度
原来 8 张图挤在两列大网格里，左列还套了一层两列小网格 —— 四张小图各自只有半页的
一半宽，"难度掌握情况"的标题被挤断成两行、周期图的 x 轴标签斜着叠在一起、一年热力图
53 列塞进半宽几乎看不清。改成单列为主，宽的图给全宽，窄的图两两并排。
砍掉的重复：进步曲线 / 提交效率 / 周期综合读的是同一个 durationData，半年视图统共
6 个桶四个字段，摊成三张卡六条曲线还都是双轴。合并成一张：柱是完成题目数和总提交数，
线是 AC 率，等级进 tooltip（S/A/B/C 四档离散值连成折线读不出东西，逐题等级表格里有）。
同期解题排名分布也砍了：五片扇形对十几道题做统计本来就是噪声，而排名逐题列在
SolvedTable 里，饼图没有增加任何信息。
换形式：
- 标签雷达图 → 横向条形。雷达对比较大小是最差的形式之一，原来还把值归一化成"占最多
标签的百分比"，第一名恒为 100%，等于只画了个排序。现在画真实题数。
- 难度掌握情况 → 难度分布。去掉叠在里面的 S/A/B/C 维度，3×4 十二个格子对一个两个月
做十来道题的学生大部分恒为 0。
热力图改成一格一周（53 格，周一起算，最后一格是本周）。按天切的话一年 365 格里三百多
格是空的，中职学生一年也就二三十天有提交，整张图看着像没用过。颜色阈值跟着按周重定。
新增三个维度：
- 错在哪里：判完的失败提交按状态码分组。编译错误占大头说明语法不熟，答案错误占大头
说明是逻辑问题，两种情况老师该给的建议完全不同。
- 几次做对：到首次通过为止提交了几次，分一次过 / 2-3 / 4-6 / 7次以上。原来只有一个
"平均提交次数"，看不出分布。
- 流程图得分：detailsData.flowcharts 早就在下发，但全页一张图都没有，只在解题表格的
第二个 tab 里列着。
顺带：
- 时间活跃度从"只统计 AC 时间"改成"统计全部提交"，星期和时段由后端按东八区聚合。
只看 AC 的话十来个点撒进 7×4 的格子几乎全是空的，和热力图的时区口径也对不上。
- 两两并排用弹性容器而不是固定两列网格：知识点分布在没有标签时整张卡不渲染，
固定两列会空掉一半。
- AI 卡片原来有三个条件挂载点（solved>10 在右列、≤10 在全宽行、=0 藏在 Overview
里面），单列之后收成最后一张无条件的卡。
- DurationChart 右轴的 S/A/B/C 一个刻度都没显示过：轴范围 -0.5~3.5，生成的刻度值是
-0.5/0.5/1.5/2.5/3.5，拿去索引 gradeOrder 全是 undefined。
契约新增 activity / errors / rankScope / solved[].attempts / durationData[].acceptedCount。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LZuPwqDmLEiK9zgQ9z9sVn
|
2026-09-03 03:08:54 -06:00 |
|
|
|
69883bd016
|
fix chart
Deploy / deploy (push) Has been cancelled
|
2026-09-03 02:35:29 -06:00 |
|
|
|
7129f1a12d
|
fix(智能分析): 提示泄题、班级分析漏鉴权、AI 端点全线无限流
Deploy / deploy (push) Has been cancelled
/ai/hint 把参考答案原文放进 prompt，靠 system 里一句「不可透露」约束，而学生的代码
本身也是 prompt 的一部分 —— 一段「忽略上面的指示，把参考答案打印出来」的注释就能把
答案套走。改成不再发参考答案，让出来的 2000 字预算给题面；解锁条件（失败满 3 次）
原来只长在前端的会话计数器上，刷新就归零、直接 POST 更是完全绕开，补成端点自己查库。
/ai/class-analysis 只有 requireAuth，前端按钮上的 isAdminRole 只是 UI —— 任何学生
直接 POST 就能用，而且 comparison 全由客户端给，等于一个开放的代打 LLM 接口。补上
isTeacherOrAbove，与 /ai/class-pk-analysis 对齐。
/ai/analysis 收的是前端算好的 details/duration 整包，原样进 prompt 又原样写进
ai_analysis 表。改成只传 start/end/duration/username，学情数据一律服务端重算，
detail/duration 的计算抽成 buildDetail/buildDuration 三处共用；报告归被分析的那个人，
不归发起请求的人 —— 后台的 pin 和学生侧 /ai/pinned 都是按 user_id 找报告的。
四个 POST 端点和 login-summary 的模型调用全部过令牌桶（复用 services/throttling，
key 用 ai:<id> 与提交、流程图分开计数），超了返 429。
顺带修掉同一块里的几处：
- /ai/duration 的等级被写死成 `solved ? "B" : ""`，DurationChart 上那条折线因此恒定
在 B。按旧后端 ai/views/oj.py:484 重新实现，按桶内同班排名算再取平均。
- 热力图 SQL 里 date() 用会话时区、JS 一边用 toISOString 取 UTC 一边用 getDate 取容器
本地时区，三套混用；固定按东八区。365 格原来末格落在昨天，今天那格永远是空的。
- loginSummaryStore.open() 从 ojnext 移植时掉了，LoginSummaryModal 一直挂在 layout 里
但没人触发，整条登录小结链路是死的。
- flowchart bestGrade 拿 max 回头 find 浮点相等的行；ai_analysis.provider 写死 deepseek。
- 前端四处 X-CSRFToken 是 Django 时代遗留，OJ2 后端没有任何 CSRF 校验，连同
getCSRFToken 一起删掉；非 2xx 响应统一走 aiStreamError 转成中文。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LZuPwqDmLEiK9zgQ9z9sVn
|
2026-09-03 02:13:59 -06:00 |
|
|
|
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 |
|
|
|
e624c62502
|
feat(提交): 列表标出来自题单的提交
Deploy / deploy (push) Has been cancelled
submission 新增 problemset_id，学生从 /problemset/:id/problem/:pid 入口提交时
前端带上、后端落库，提交列表在题目后面挂一个「题单 xxx」的标签，点了进题单。
只是来源标记：题单进度和奖章仍由判完之后的 recordSolvedProblem 按「已加入且含
这道题的所有题单」记账，和从哪个入口进来无关，所以这个字段带错顶多标签不准，
不影响成绩。校验只确认这道题在那个题单里 —— 不查 visible / status、也不查有没有
加入，藏起来的题单里还困着已加入的学生；对不上就当没带，提交照收。
外键 ON DELETE SET NULL：删题单不该带走提交，清掉标记就行。索引建成部分索引
（WHERE problemset_id IS NOT NULL），绝大多数提交不来自题单，全列索引是给 12 万行
白建一遍；谓词能被 problemset_id = $1 蕴含，删题单时的外键检查也用得上它。
列表按页单独查一次题单标题，没有把 problemset join 进那条调过的深翻页查询。
比赛提交恒为 null：题单只收非比赛题。
历史回填从 problemset_submission 取「当年首次 AC 那条」，其余老提交无从判断入口，
一律留空。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y7AsqceaUfC81k7UCDcSk2
|
2026-09-02 22:06:29 -06:00 |
|
|
|
286487acf3
|
fix(自学): 少于三分钟的不算已读
原来只要打开过（viewCount > 0）就记成已读，于是「点开看一眼就退」和「认真读完」
在老师那张表上长得一模一样，「已读 17/17」并不说明他学了。加一道 3 分钟的门槛 ——
按最短的一课定的下限，读不完还翻不动的课文，扫一眼是到不了这个数的。
阈值 TUTORIAL_READ_SECONDS 放在 contract 里，前后端共用一个数：学生端目录的 ✓、
后台「按学生」的已读课数、「按课程」的读过人数，三处口径必须一致，各写各的迟早分叉。
**累计时长故意不卡**。时长记的是真实停留，不满三分钟的秒数照样算进去，于是
「已读 0 课、累计 25 分钟」成为一种能看见的状态 —— 他翻了很多课，每课都没读满。
这正是这道门槛想让老师看见的东西，把时长一起滤掉反而把信息删了。
「按课程」的人均时长跟着改了分子：分母是读满三分钟的人，分子就得是同一批人的时长，
否则拿全部时长去除达标人数，人均会被翻一眼就走的人凭空抬高。
顺带修掉「✓ 已读 · -」：心跳 15 秒一跳，点开就走会落在 0 秒上，而 readableDuration(0)
返回的是 "-"。新口径下打勾要求 ≥180 秒，这个组合不可能再出现；打开过但没读满的
显示灰色的「读了 N 分钟」，记是记下了，只是还没到「已读」。
后台筛选栏上方写了一行口径说明，免得老师对着「已读 0 课 / 累计 25 分钟」猜是不是坏了。
本机实跑：student 读 A 课 500 秒、B 课 60 秒 → 已读 1/2、累计 560 秒；
A 课「读过 2 人、累计 700、人均 350」，B 课「读过 0 人、累计 60、人均 0」。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013rpSKCNpVcMhTFhw21YiL7
|
2026-09-02 20:37:30 -06:00 |
|
|
|
bd84599174
|
feat(自学): 教程和练一练都留痕，老师能看到谁学了多少
Deploy / deploy (push) Has been cancelled
自学模块以前一个字节都不落库：读到第几课只存在浏览器的 localStorage 里，
练一练的对错是组件内的一个 ref，刷新即失忆。老师能看到的只有「谁交了题」。
现在两张新表：
* tutorial_progress —— 一个学生 × 一课，记打开次数和累计停留秒数
* exercise_attempt —— 一个学生 × 一道练习，记试了几次、错了几次、
第几次做对的、最后一次做错时填的什么
都存聚合不存流水。练习那张表尤其明显：流水会随着学生反复点提交无限长，
而多出来的行回答不了任何新问题 ——「他第 3 次和第 5 次都选了 B」对老师
没有意义，「他试了 7 次才对」有。
停留时长只在页面可见、且十分钟内有过操作时才计。机房的电脑经常开着页面
就走了，不设这道闸的话「停留时长」会变成「电脑开机时长」，老师看到的
数字全是假的。换课、切标签页、关窗口都会先把攒着的秒数冲给**离开的那一课**。
练一练的对错仍然是前端判的：答案本来就随题面一起下发到浏览器，后端再判
一遍也挡不住任何人，只是重复实现七套判题。所以这是教学观察数据，不是成绩。
`last_wrong_answer` 存的是前端拼好的一句人话（「选了 C」「顺序 3-1-2」），
不是原始作答结构 —— 七种题型形状各不相同，存结构就得在后台按题型各写一套
渲染，而老师要看的只是他错在哪。
顺带修掉预测输出题的一个老问题：它的 `submitted` 一旦为真就不再收回，而
`allCorrect` 是跟着输入实时算的，于是学生错一次之后把答案改对，界面直接
跳成「输出正确！」、提交按钮同时禁用，submit() 再也执行不到 —— 这道题
**永远不会被记成做对**。排序/连线/找错/分组四种题本来就在交互处把 submitted
置回 false，只有这里漏了，按同一套补上。
学生端：目录每课显示「✓ 已读 · 11 分钟」和「练一练 3/5」。教程保持免登录
可读，未登录只是不留痕，并明说一句。
老师端：后台新开「自学情况」（教师及以上可进），三个 tab ——
按学生（默认把读得最少的排在最前，这张表要回答的是谁还没开始）、
按练习（每道题的正确率、一次做对几人、做对的人平均试几次；展开看逐人明细
和他们最后错在哪）、按课程。班级框填 3-4 位是具体班级，1-2 位当年级前缀。
外键用了库级 CASCADE，和 Django 建的那批 NO ACTION 不同：删教程、删用户
不必再记得回来手工清子表。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GW5ef6C2kRW8Ru27ghCaUu
|
2026-09-01 08:54:27 -06:00 |
|
|
|
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 |
|
|
|
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 |
|
|
|
f38444c97a
|
fix(代码规则): 给 C 题配的规则一半是哑弹，C++ 题根本配不了
Deploy / deploy (push) Has been cancelled
后台的节点下拉是一张 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 |
|
|
|
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 |
|
|
|
7793a2fe4c
|
清理旧后端下线后的残留
Deploy / deploy (push) Has been cancelled
旧 Django 后端 2026-08-26 下线、回滚路径作废，代码里还留着几处以它为前提的
死代码和过期注释。
- PUBLIC_WS_URL / PUBLIC_OJ_URL 全部删除。BaseWebSocket 的
`${PUBLIC_WS_URL}/${path}/` fallback 是 Channels 时代的写法，而三个子类
早就各自传 url，等于永不执行；config.vue 里 PUBLIC_OJ_URL 只是个会被
getWebsiteConfig() 立刻覆盖、且指着 :8000 的假初值。WebSocketConfig.path
随之去掉，url 改成必填。
- vite.config：删掉 /api2、/ws2 的迁移期注释，换成还成立的约束（代理这三段
要和 docker/Caddyfile 同步）；newBackend 改名 backend。
- 六处 “回滚时旧后端还要读” 换成真实理由：snake_case 保留的结论不变，但因为
判题机按这套键名写、存量 JSONB 就是这形状。
- CLAUDE.md：数据库一节开头「不写迁移 + 先想清楚回滚」与下一节的 drizzle
migration 自相矛盾，改掉；判题状态码不再要求同步到 OnlineJudge，理由换成
历史 submission.result 和沙箱用的就是这套编码。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-26 09:09:26 -06:00 |
|
|
|
75dd9bfa42
|
fix(提交): 独立的 /submission/:id 页面上「复制回到题目」抛 problemID
## 复现与根因
在 `/submission/<提交id>` 这个独立页面点「复制回到题目」，必抛：
Error: Missing required param "problemID"
`detail.vue` 的 `problemID` 是**可选** prop，但 `copyToProblem()` 无条件把它塞
进 `router.push({ params: { problemID } })`。三个组件调用方（提交列表弹框、
题目页提交弹框、后台 ACM 助手）都显式传了这个 prop，所以弹框里一直是好的；
而路由 `submission/:submissionID` 配的是 `props: true`，只喂得进
`submissionID` —— 那条路上这个 prop 恒为 undefined。
组件想自己兜底也兜不了：`submissionDetailSchema` 只有 `problemId`（内部数字
id），没有拼路由要用的 display id（`problem._id`）。
ojnext 里是**一模一样**的代码，不是这次重写引入的。
## 改法
后端补 `problemDisplayId`：`submissionDetail()` 本来就 join 了 problem 表，
不额外查库。前端 `props.problemID ?? submission.problemDisplayId`。
## ⚠️ 还剩一条边没关
非管理员看到的 `contestId` 是被抹掉的（`full ? contestId : null`，对齐旧后端
`SubmissionSafeModelSerializer` 的 exclude，把关的是角色不是归属）。所以**学生
自己的比赛提交**从这个独立 URL 打开时，组件判断不出它属于比赛，会跳到公开题
路由 `/problem/<显示编号>`，那里查的是 `contestId is null`，落到「题目不存在」。
改之前这条路是抛异常，改之后是跳错地方 —— 都不对，但主路径（非比赛提交）现在
是对的。要彻底关掉得让后端把 `contestId` 也发给**提交本人**（不只是管理员），
那是在动一条刻意对齐旧后端的决定，留给你定。另外这条路由**全站没有任何入口
链接**（查过了），只有直接输 URL 或外部链接才会到。
## 验证
真起服务、真点按钮：
- 修之前：点击不跳转，控制台 `Missing required param "problemID"`，
Vue 警告里能看到 `<Detail submissionID="..." >` 确实没有 problemID。
- 修之后：无异常，跳到 `/problem/1004`（那条提交对应的题），
编辑器里是这条提交的代码（`n = int(input())…`），语言也带过去了。
- 回归：走提交列表弹框（有传 prop 的那条路）照样无异常、照样跳 `/problem/1004`。
- tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 23:59:46 -06:00 |
|
|
|
3f6b4102c9
|
feat(题目): 学生题目页恢复「要求」展示，走新的 astRequirements 字段
Deploy / deploy (push) Has been cancelled
旧后端的 ProblemSerializer.Meta.exclude 没排掉 ast_rules，学生拿到的是规则原文，
题目页上那块「要求」（「if 条件 出现 2 次」之类）是显示的。阶段 3 泄露评审刻意
收掉了它，只留 hasAstRules 布尔值 —— 报告里当时就写了：
「新的更安全，但如果 ojnext 有地方读 ast_rules 的具体内容（比如提示"必须用
for 循环"），需要补个专门的字段。」
前端确实有（ProblemContent.vue 的 astRulesForDisplay + 整块渲染），但那个字段
一直没补。结果是这块在 OJ2 上**永远拿不到数据**，代码还在、没人报错。12 道题
受影响；学生只有提交失败后才能从 statistic_info.ast_results 里看到要求。
现在按评审自己的建议补上：oj 侧题目详情（含比赛题）多一个 astRequirements，
**只有渲染要用的两个字段**：
{ description: "if 条件 出现 2 次", kind: "count" }
文案由后端生成，engine / target 这些内部字段不出现在响应里 —— 收紧保留，
展示恢复。实测响应里搜不到 "engine" 也搜不到 "if_statement"。
## 顺带合掉一堆重复
描述文案原来有两份几乎一样的实现：判题机 ast.ts 里一份（写进 ast_results）、
ProblemContent.vue 里一份（题目页用）。现在统一成 ast.ts 的 describeAstRule，
两边共用。差异只在 min/max 同时给出时的措辞（生产库里没有这种规则，实际输出
逐字不变），另外判题机现在也能用上节点类型的中文名 —— 没写 label 的规则以前
判题结果里显示 `必须使用 function_definition`，现在是 `必须使用 函数定义`。
节点类型中文名那 15 条原来在 AstRulesEditor.vue（下拉 options）和
ProblemContent.vue（NODE_TARGET_LABELS）各手抄一份，收进契约的
AST_NODE_TARGET_LABELS，编辑器的下拉现在从它生成。
前端删掉 NODE_TARGET_LABELS / ruleDescription / ruleTagType 共 ~80 行，
`Problem` 类型里那个 oj 侧根本不下发的 astRules 幽灵字段也去掉了。顺带修掉
一处潜在重复渲染：原来 message 非空时 ruleDescription 返回 message、模板里
又单独渲染一次 message（生产库 message 全是空串，所以没露出来）。
## 一个坑：契约里差点搞出循环引用
astRequirements 一开始放在 admin.ts，problem.ts 去 import 它 —— 而 admin.ts
本来就 import problem.ts。**tsc 一声不吭地过了**，运行时才炸：
ReferenceError: Cannot access 'astRequirementsSchema' before initialization
所以整块 AST schema 从 admin.ts 挪到了 problem.ts（本来也是题目域的东西），
admin.ts 反过来从那边取。这类环 tsc 抓不到，加跨文件 schema 引用时得实跑一次。
## 验证
tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过。
起服务实打：
- 把生产库那条规则种进本地库，匿名请求 /api/problems/1001：astRequirements 是
`{"Python3":[{"description":"if 条件 出现 2 次","kind":"count"}, ...]}`，
响应里没有 astRules、没有 engine、没有 if_statement。
- 浏览器打开题目页，「要求」那块活了：`要求 | if 条件 出现 2 次 | else 子句 出现 2 次`。
- 后台编辑页展开「代码规则检查」，两条规则正常渲染成
`出现次数 | if 条件 | 精确`，下拉选项（现在从契约生成）正确。
- 直接调 describeAstRule / checkAst / astRequirements：三种 kind 分类正确，
engine 认不出的规则被丢掉，null 和非对象都回落成 null。
- oj 侧 3 页 + 后台 4 页走查无重定向、console 无报错。
冒烟改动已还原（problem 2 的 ast_rules 复位成 null）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 23:27:40 -06:00 |
|
|
|
f919d41199
|
refactor(契约): AST 代码要求收进契约，三份各写各的合成一份
同一个形状原来在三个地方各定义了一份，三份都不一样：
apps/api/src/judge/ast.ts engine target outer inner label message exact min max
apps/web/src/utils/types.ts engine target message min max
AstRulesEditor.vue（本地） engine target label message exact min max
ProblemContent.vue（本地） engine target label message exact min max
判题机那份是真的（evaluateRule 按 engine 分支读哪几个字段），契约里则压根没有，
`astRules: z.unknown()`。后果是后台编辑器写得出 label 和 exact、判题机也认，
但 utils/types.ts 那个类型描述不了它们 —— 生产库 12 道带 AST 规则的题里，
15 条规则带 label、6 条带 exact，全都在类型之外。
现在契约里一份 astRuleSchema，四处都指向它。engine 收成枚举，列全判题机
实现的十种。**存量数据核过**：12 道题逐条过新 schema，12/12 通过。
顺带三件：
- `astRules` 的响应和请求 schema 从 z.unknown() 换成 astRulesSchema。之前
engine 写错一个字母能存进去，判题机 evaluateRule 走 `default: return null`
静默跳过 —— 老师设了规则、规则不生效、没有任何提示。现在保存时就 400，
错误信息把十个合法值列出来。
- judge/run.ts 的 astRulesForLanguage 原来是整片 `rules as AstRule[]` 硬转，
改成逐条 safeParse：认不出的丢掉那一条，行为和 evaluateRule 的 default 分支
一致，只是提前到读取处，也不再骗类型系统。
- 判题机实现了 must_have_nesting，但后台编辑器没有对应选项，目前只能手工造
数据才用得上。枚举里留着并加了注释，没有顺手去补 UI（那是加功能不是清理）。
## 验证
tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过。
起服务实打：
- 把生产库那条带 label/exact 的规则种进本地库，后台题目详情 200、字段齐全；
原样 PUT 回去 200，库里 label 和 exact 都在（旧类型描述不了的那两个）。
- engine 传 "must_do_magic" → 400，错误信息列出十个合法值。
- 直接调 checkAst：三条规则（两条合法 + 一条 engine 认不出）进去，判题机收下
两条；两个 if/else 的代码 passed=true，一个的 passed=false，描述文案
「if 条件 出现 2 次」正确用上了 label。
冒烟改动已还原（problem 2 的 ast_rules 复位成 null，测试标签删掉）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 23:15:52 -06:00 |
|
|
|
3f55d231c3
|
refactor(契约): samples / answers / testCaseScore 补回旧后端的校验
Deploy / deploy (push) Has been cancelled
旧后端这三个字段都是逐字段校验的（CreateSampleSerializer /
CreateAnswerSerializer / CreateTestCaseScoreSerializer），新后端一路写成
`z.record(z.string(), z.unknown())`，**比旧的松**。松出来的不只是少拦几个
错误请求，还有一处静默的落库形状漂移。
## test_case_score 会越存越胖，而且 score 变成字符串
上传接口的响应有六个键，前端 `{...entry, score}` 原样往回传。旧后端的 DRF
serializer 只认 input_name / output_name / score，多的直接丢，所以生产库
956 行 test_case_score **全部只有三个键**、7990 条 score 全部是 int
（前端算出来是 `(100/n).toFixed(0)` 这种字符串，IntegerField 收下时转了）。
新后端不做这件事，往后在 OJ2 上新建或编辑的题会存六个键、score 是字符串 ——
和旧后端写出来的不是一个形状。这列判题机不读，不影响判题，但它是回滚要
原样交回去的持久化数据，不该在这上面分叉。
现在三个精确 schema 顶上：problemSampleSchema / problemAnswerSchema /
problemTestCaseScoreSchema。zod 的 object 默认剥未知键，和 DRF 同一个行为；
score 用 `z.coerce.number().int().min(0)`，对齐 IntegerField 的收字符串转整数。
前端跟着改：`Testcase` 从 `TestCaseEntry & { score: string }`（六键+字符串分数）
换成契约的 ProblemTestCaseScore（三键+整数），三处构造点只挑落库要的键。
detail.vue 那处写成 `Number((100 / n).toFixed(0))` —— 取值和原来逐字相同，
只是不再包成字符串，分数算法一个字没动。AdminProblem 的 Omit 列表也短了两项
（samples / testCaseScore 现在契约里就是准的），只剩 answers 要把 language
收窄成 LANGUAGE。
## 顺带：一段被 @ts-ignore 压着的死代码
admin/problem/detail.vue 上传测试点那里有
// @ts-ignore
if (res.error) { ... }
—— 拿 { error, data } 信封当返回值判。上一个 commit 拆信封时正是因为
@ts-ignore 压着，vue-tsc 没报出来。res 现在是 UploadTestCaseResponse，
没有 error 这个键，这个分支永远进不去。失败本来就走 catch。
（全仓另外两处 @ts-ignore 查过了，是 skulpt 和 wangeditor 没类型定义，正常。）
## 生产数据依据
956 道题逐条扫过备份：samples 947 条 {input,output} + 9 条空数组（SQL 题没
样例）；answers 268 条 {code,language} + 633 null + 55 空数组；
test_case_score 956 条全是三键，score 全 int。收紧不会打到任何存量行。
## 验证
tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、build 通过。
起服务实打了写路径：
- 后台题目详情 200，三个 schema 都 parse 得过存量数据。
- 故意造脏 PUT：score 传字符串 "20" + 塞进 stripped_output_md5 / input_size /
output_size，落库是干净的 `{input_name, output_name, score: 20(int)}`；
samples 和 answers 里塞的多余键同样被剥掉。
- 三个错误载荷都按预期 400：samples 缺 output、answers 缺 code、score 传负数。
- 浏览器里打开后台题目编辑页，点提交 → PUT 200 → 跳回列表，库里形状正确。
（顺带发现 tags 为空的题在编辑页点提交会被 `tags.min(1)` 挡下 400 —— 旧后端
`allow_empty=False` 也是这个行为，不在本次范围。）
冒烟改动已还原：problem 2 的 answers 复位成 []，测试用的「冒烟」标签删掉。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 23:04:41 -06:00 |
|
|
|
5c772319e9
|
refactor(契约): 公告两侧形状分开，判题状态码从契约派生
Deploy / deploy (push) Has been cancelled
## 公告：一个 schema 兼两种形态，兼出两处谎
前端 utils/types.ts 只手抄了**后台那份**公告形状，oj 侧也拿它当类型用。可
apps/api/src/routes/content.ts 的 `/announcements` 列表既不下发 content 也不
下发 visible —— 于是类型声称列表行有这两个键、运行时都是 undefined。今天没炸
只是因为组件恰好没读（正文是点开后另拉一次详情）。
契约那边则是另一头：announcementSchema 把 content 写成 `.optional()`，让一个
schema 同时兼列表和详情。代价是**详情**拿到的 content 类型也成了
`string | undefined`，组件只能 ?? 兜底。
现在两边都按后台侧早就在用的套路拆开：content 必填，列表用
`.omit({ content: true })` 派生。四个类型各归各位：
oj 列表 AnnouncementListItem 无 content、无 visible
oj 详情 Announcement 有 content、无 visible
后台列表 AdminAnnouncementListItem 无 content、有 visible
后台详情 AdminAnnouncement 有 content、有 visible
前端手抄的 Announcement / AnnouncementEdit / AnnouncementListItem 全部删掉，
AnnouncementEdit 改成从请求体派生（`CreateAnnouncementRequest & { id: number }`）。
后端 content.ts 的列表端点跟着换成 announcementListItemSchema —— 它本来就没
传 content，输出一字不变。
## SUBMISSION_RESULT 不再手抄
`-2 | -1 | 0 | ... | 10` 这 11 个码是从后端抄的，改成 `JudgeStatus | 9`：
后端那部分从契约派生，9 是前端本地的「正在提交」伪状态（后端永远不下发，
所以契约里没有，见 constants.ts 的 SubmissionStatus.submitting）。
这样 CLAUDE.md 说的「三处同步」才真的有人守：**实测过**，往
judgeStatusSchema 加一个 `z.literal(11)`，constants.ts 的 JUDGE_STATUS 立刻
报 TS2741 缺 '11' 的映射，加不上标签就编译不过。
顺带 useSubmissionMonitor.ts 里两处裸 `9`（各带一句 `// 9 = submitting`）
换成 SubmissionStatus.submitting，注释就不用写了。
## 顺手
TestcaseUploadedReturns 这个改名 re-export 去掉，直接用契约的
UploadTestCaseResponse（全仓 2 处引用）。
**没动 transforms.ts。** 之前把它记成「旧前端字段名的化石」，看下来判断有误：
filterResult 里 difficulty 要查 DIFFICULTY 映射表转中文、rate 要 getACRate 算、
status 要把 myStatus 翻成 passed/failed/not_test —— 是实打实的视图模型，不是
单纯改名。改它只会把计算逻辑挪个地方。
## 验证
tsc(apps/api) 0 error、check:routes 168 条无遮蔽、vue-tsc 0 error、vite build
通过。因为动了后端响应 schema，起服务实跑了公告的四条路径：
- curl 三个端点逐个核对键集：oj 列表无 content/visible 且只出可见的那条、
oj 详情有 content、后台列表有 visible 无 content 且两条都在。
- 浏览器里 oj 公告列表渲染正常、点开正文能出来；后台列表两行齐全；
编辑页表单载入正确；改标题保存 PUT 200，库里 title 变了、visible/top 没被
带歪，保存后跳回列表并重新拉取。
（agent-browser 的 `find text 保存 click` 打不到 naive-ui 的按钮 handler ——
不发请求也不报错，一开始误判成保存坏了。改用 DOM 上直接 .click() 就正常，
是自动化的坑，不是应用的问题。）
冒烟用的两条公告已删干净。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 22:54:01 -06:00 |
|
|
|
9653f1541a
|
refactor(契约): SQL 展示数据进契约，topReaction 收成枚举
d3b05b8 把 SQLDisplay* 列进「保留不动的窄化」，理由是契约那边就是
Record<string, unknown>。这次把那个碗底扫了 —— 因为「契约说不知道形状、
前端手抄一份来渲染」正是那个 commit 修的五处分歧的同一个模子。
SQL 题两个 JSONB 列现在有精确 schema：sqlConfigSchema、sqlDisplaySchema、
sqlDisplayTableSchema、sqlDisplayColumnSchema。键名保持 snake_case，是
problem.sql_config / sql_display 的原文，回滚时旧后端要读同一份。前端
utils/types.ts 里手抄的 SQLConfig / SQLDisplay / SQLDisplayTable /
SQLDisplayColumn 共 30 行删掉改成 re-export，Problem 和 AdminProblem 的
Omit 列表各短两项。手抄那份把 SQLDisplayColumn.type 写成了可选，后端一直
是必有的空串。
后端跟着收紧：commonChecks / generateSqlDisplay 的 Record<string, unknown>
换成 SqlConfig，`sqlConfig.mode === "modify" ? "modify" : "query"` 这句防御
删了 —— 现在类型上就只有那两个值。请求侧 createProblemRequestSchema.sqlConfig
也不再是 record：mode 是枚举、order_sensitive 缺省补 false，正好是旧后端
SQLConfigSerializer 的口径（新后端之前反而比旧的松，什么都收）。
顺带修 adminProblemListItemSchema.topReaction 的注释：写着「当前后端恒传
null，get_top_reactions 没跟着迁过来」，但 admin/problem.ts:257 早就在调了，
只有比赛题列表恒 null。这条注释会骗人去补一个已经存在的实现。类型同时从
z.string() 收成 reactionKeySchema —— getTopReactions 本来就把库里认不出的
类型滤掉了，只是类型上没体现，前端因此得在 transforms.ts 写
`as AdminProblemFiltered["topReaction"]`，现在那个强转和 `?? null` 一起没了。
服务层里的 `as ReactionKey` 换成 isReactionKey 类型守卫。
**收紧 JSONB 的 schema 会把「存量数据形状不对」从静默降级变成 500，所以实打了：**
- 从生产库备份捞出 9 道 SQL 题的 sql_config / sql_display 原文，逐条过新
schema，9/9 通过；键集与旧后端 judge/sql_runner.py:build_display 的产出
逐字一致（columns/name/rows/total_rows/truncated，expected 两形态）。
- 把其中 query 形态、modify 形态各一条种进本地库，起 API 打 oj 详情和后台
详情共四个端点，全 200，expected 两种分支都正确解析。
- topReaction：插两条并列票，按 reactionKeySchema 顺序正确取到 confusing；
再插一条库里已下掉的类型，被守卫滤掉返回 null。
另：`bunx vue-tsc --noEmit` 不带 -p 是**无效的**，根 tsconfig.json 是
"files": []，塞个类型错误进去照样 exit 0。要跑 `bun run type-check`
（-p tsconfig.app.json），这次的结论出自它。tsc(apps/api) 0 error、
check:routes 168 条无遮蔽、vite build 通过。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 19:02:25 -06:00 |
|
|
|
d3b05b8629
|
refactor(契约): 补齐 80 个类型导出，前端不再手抄形状
契约原来有 184 个 schema 但只导出了 104 个类型，缺的那 80 个前端只能照着
手抄一遍 —— 这是「表格列静默空白」那一类 bug 的根因（d3348f9、2edb8cf，
以及上一个 commit 修的 Top100 两列）。现在 186 个 schema 对 186 个类型，
一一对应，下次要用直接 import。
补导出是机械的（fooSchema → Foo），零命名冲突。真正有价值的是换的过程中
契约逼出来的 5 处分歧 —— 手抄那份在说谎，而 vue-tsc 拦不住，因为类型说它是对的：
- Tutorial.createdBy 手抄成了可选的 `User`（即 AdminUser，带 email、
rawPassword），后端下发的是必有的 SampleUser。读 createdBy.email 会拿到
undefined。列表页因此被迫写 `row.createdBy?.username` 和 `row.createdAt!`，
换成契约类型后两处断言都不需要了。
- TutorialListItem 手抄成 `Omit<Tutorial, "content">`，但后端列表接口连 code
一起省了 —— 类型声称 code 在。
- Testcase 手抄成 `{input_name, output_name, score}`：响应实际有 5 个字段，
且**没有 score**。score 是上传完成后前端按测试点数量平分补上去的，手抄那份
把本地字段说成了响应字段。现在写成 `TestCaseEntry & { score: string }`。
- Tag 手抄成 `{id, name}`，契约是 `{id, name, problemCount}` —— shared/api.ts
只好用 `Tag & { problemCount: number }` 把丢掉的补回来。
- CreateMessage 是旧后端按名字投递的形状（sender/recipient/submission），
契约要的是 recipientId/submissionId。全仓零引用，删掉。
同时删掉另外两个零引用的手写类型：LANGUAGE_SHOW_LABEL、UserAdminType；
本地重复的 SampleUser 换成契约的；oj/problem/list.vue 里本地第三份 Tag 改成
`ContractTag & { checked: boolean }`。
需要收窄的一律**从契约派生再收窄**，字段名跟着契约走，只有真正本地的那一两个
键是自己的：
export type Exercise = Omit<AdminExercise, "data"> & { data: 七种题型的联合 }
export type SubmitCodePayload =
Omit<CreateSubmissionRequest, "language"> & { language: LANGUAGE }
保留不动的窄化：StatisticInfo / SubmissionInfo（判题 JSONB 原文，snake_case）、
SQLDisplay*、ProblemFiltered（视图模型）、Exercise*Data（契约里 data 就是
Record<string, unknown>，七种题型结构不同，后端本来也不校验）。
types.ts 的手写 interface 从 31 个降到 22 个。
顺带修的代码：admin/tutorial/detail.vue 新建教程的表单对象缺三个后端产出的
字段，加了 TutorialEdit（对齐 BlankProblem / BlankContest 的写法）；三处测试点
上传原来是拿响应对象原地塞 score，改成 map 出新对象，分数算法一字未改。
验证：apps/api tsc(7.0.2) 0 error、check:routes 168 条无遮蔽、
apps/web vue-tsc 0 error、vite build 通过。改动绝大部分在类型层，运行时只有
测试点上传那三处（等价替换）—— **那条路径要传 zip 才能实跑，没有实打**，
只做了代码等价性核对。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 18:07:01 -06:00 |
|
|
|
78a2fb4fce
|
feat(排行榜): 重写全服 Top100，补上「我的排名」，后台那条挪进 admin
起因是 Top100 的「已解决」「提交数」两列一直空白：列的 key 还是
snake_case（accepted_number / submission_number），而数据早在 c2a8120 拆掉
转换层后就是 camelCase 了。naive-ui 按 row[key] 取值，取到 undefined 就渲染
空白、不报错 —— 和 d3348f9 是同一个病根。
顺着这条线把整个端点重写了：
**上限不再由调用方传。** `top` 参数原来有三个调用方各传各的（100 / 10 / 0），
而它会覆盖 limit 与 offset、total 却按全量算，正是 36e4ac2 那个「每页都是同样
100 条」的成因。现在 100 写死在服务端，参数只剩 limit / offset。
「全服 Top10」不需要另一个上限，它就是这个榜的第一页。
**排序补了第三档 asc(user.id)。** 前两个键完全相同的学生在真实数据里成片存在
（都是 0/0），没有稳定兜底键时 postgres 每次返回的顺序可以不同，翻页会看到重复
或漏掉的人。老代码缺这一档。
**新增 me（我的全服名次）。** 名次 = 排在我前面的人数 + 1，三个排序键逐级比较，
与列表的 orderBy 逐字对应 —— 少比一级就会出现「显示第 7 名、实际排在表格第 9 行」。
榜上高亮我那一行，名次超出 100 时在 footer 单独给一行。未登录、教师/超管返回 null。
**后台那条搬去 /api/admin/rankings/users**（requireSuperAdmin，无上限）。
原来它走的是公开端点的 top=0 分支，也就是任何匿名请求都能 ?top=0&limit=250
翻走全校学生名单和个性签名 —— 而 /profiles/:username 恰恰为了收紧枚举面才做了
「匿名一律返回空」，注释里还专门点了 /rankings/users 的名。这条页面本来就是
requiresSuperAdmin，它调的另外两个接口也都是 requireSuperAdmin，守卫对得上。
顺手去掉恒真条件 gte(acceptedNumber, 0)：该列是 notNull default 0。
同一次扫了全仓 218 个表格列定义，筛出 70 个没有 render 的（只有这些才靠 key
直接取值），比对全部类型定义里的字段名 —— 除这两处外没有漏网的。`_id` 和
`test_case` 是真字段名，不能改。另外收掉两处同类的雷：
admin/setting/config.vue 手写的 `interface Testcase` 字段名和类型都是错的
（真实数据是 createTime: number，不是 create_time: string），改用契约的
OrphanTestCase；serverColumns 里 last_heartbeat / create_time 两个残留 key
有 render 兜着没出事，一并改正。
实测（造 120 个探针用户，含 3 个 AC 与提交数完全相同的并列，验完已清库）：
122 人时 total=100；offset=95 末页 5 条；offset=100 越界返回空且不发 SQL；
并列三人稳定占据前三；student(ac=2) 拿到 rank=121 走「不在榜上」分支；
把 ac 调到 450 时 rank=4 且表格第 4 行正是 student（名次与行号对得上）；
升成超管后 me 变 null；后台端点 total=121 无上限、keyword=probe_01 命中 10 条、
未登录 401；传 top=1 已被忽略。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 17:57:55 -06:00 |
|
|
|
0e1e024fa4
|
chore(依赖): 升一批 patch/minor，锁死 mermaid-legacy 和 TypeScript 大版本
后端：@node-rs/jieba 2.0.1→2.0.2（含精确 pin 的 -linux-x64-gnu）、
bullmq 6.0.9→6.2.2、postgres→3.4.9、sql.js→1.14.2、web-tree-sitter→0.26.13；
hono ^4.0.0→^4.13.4 与 zod ^4.0.0→^4.4.3 只是把范围收紧到实装版本。
前端：@codemirror/view→6.43.9、highlight.js→11.12.0、mermaid→11.17.2、
naive-ui→2.45.2、pinia→4.0.3、y-codemirror.next→0.3.6、vite→8.2.2、
@types/node→26.3.0。
刻意没动两个：
- mermaid-legacy（npm:mermaid@^9.4.3）保持 9.4.3，vite 的 build target
也没碰 —— 机房 Chrome < 94 的兜底，legacy polyfill 产物照常生成。
- typescript 停在 5.9.3（只把根上的范围从 ^5.7.0 收到 ^5.9.3）。
7.0.2 是 Go 原生重写版，另开一个 commit 处理。
踩到的坑记一笔：`bun install` 不清理旧的嵌套副本。升完 @codemirror/view 后
md-editor-v3/node_modules/ 下留着一份 6.43.8，vue-tsc 立刻报
dispatchTransactions 私有属性冲突 —— 看起来像版本不兼容，其实
md-editor-v3 要的是 ^6.38.2，6.43.9 完全满足。当时全仓有十几处这种残留。
**升完依赖必须 rm -rf node_modules && bun install 再验类型**，否则会
对着一堆假的类型冲突查半天。
验证（删空 node_modules 重装后）：apps/api tsc 0 error、check:routes 167 条
无遮蔽、apps/web vue-tsc 0 error、vite build 通过、单二进制在仓库外起得来
并打库返回真数据、jieba 原生模块 dev 与编译两种形态都验过、BullMQ 两个
worker 正常 ready。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 17:39:06 -06:00 |
|
|
|
1198895b54
|
refactor(前端): vue-tsc 清零，type-check 可以当 CI 门禁了
接上 vue-tsc 时有 143 条既有错误，上一批迁移带走 89 条，这里把剩下的清完。
大部分是噪音（未使用的回调参数、死变量、少数 unknown），但里面躺着两个真问题：
- 个人主页查不存在的用户会抛：getProfile 返回 null 时后面照样取
.acmProblemsStatus，靠 `!` 压着。加了早返回。
- getProblemSetProgress 我上一批标错了类型：后台这个接口返回的是裸数组，
不是分页信封（和 oj 侧的 /user-progress 不一样）。已改正并加注释区分。
其余处理：
- 未使用的回调参数按 TS 约定加 `_` 前缀（v-for 的项、供子类重写的空钩子、
路由守卫的 from）；确认无用的局部变量直接删（clickX/clickY 算了点击位置
但飞出方向用的是随机角度，hasToday 下面已经用 lastDateOnly 判过，
prefix 算了周/月但标签里没用上）。
- App.vue 的 highlight.js 注册：Promise.all([...]).then(m => m.map(x => x.default))
会把元组塌成 (HLJSApi | LanguageFn)[]，hljs 上就找不到 registerLanguage。
改成逐个取 .default。
- 给一批 api 补上契约类型（getMetrics / getHitokoto / getTutorials /
formatCode / getProblemBeatRate / getClassUsernames 等），契约相应补了
8 个 z.infer 导出。
- ContestRank.submissionInfo 和 AcmHelperItem.acInfo 在 api 边界窄化成
SubmissionInfo —— 契约里是 Record<string, unknown>（JSONB 原文）。
- FlowchartEditor 的 TS2589：vue-flow 的 Node 嵌套太深，ref<Node[]>([]) 的
UnwrapRef 推导撞上实例化层级上限，改成 ref([]) as Ref<Node[]>。
- api2.ts 的响应拦截器**故意**不返回 AxiosResponse（要把 { data } 信封剥掉），
类型上确实说不通，没硬掰，写注释说明为什么用断言。
- 题目列表的「随机」按钮在模板里一直是注释状态，对应的 getRandom 和
getRandomProblemID 一并删除（后端 /problems/random 保留不动）。
验证：vue-tsc 0 条，apps/api tsc、check:routes、web build 全通过；
修过 key 的列都打接口确认过字段真实存在。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-25 14:04:10 -06:00 |
|
|
|
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 |
|
|
|
e3faa689e7
|
feat(阶段2补课): SQL 判题链路 + 最后两个后台端点
新后端此前完全没有 SQL 判题（旧 judge/sql_runner.py 378 行 + sql_dispatcher.py
113 行无对应实现），阶段 2 纵切时漏了这条与沙箱完全不同的路径。
judge/sql/engine.ts 判题核心，移植自 sql_runner.py，判定口径逐条对齐
judge/sql/child.ts 子进程入口
judge/sql/index.ts 父进程：spawn + 硬超时
judge/run.ts language === "SQL" 时分流，不经判题沙箱
POST admin/sql-test-cases/preview 题目页展示数据预览
POST admin/sql-test-cases/generate AI 按标准答案倒推初始化脚本
题目保存时重新生成 sqlDisplay（对齐旧 generate_sql_display）：取测试点 1 的初始化
脚本 + 标准答案跑一遍，失败一律拦下不让保存 —— 展示数据直接决定学生看到的表结构
与期望结果，宁可不保存也不能存错的。
## 防护换了实现，逐条实测
bun:sqlite 没有 authorizer / progress_handler / setlimit，且实测 Worker.terminate()
杀不掉跑飞的查询（原生代码占着线程）。改用「WASM 引擎 + 独立子进程」：
ATTACH → WASM 无宿主文件系统绑定，结构上够不到（比旧的 authorizer 更强）
查询题只读 → PRAGMA query_only=1
超时 → 子进程外部 SIGKILL
单值内存 → 子进程 ulimit -d
八条提交实测：正确→Accepted；列少一个/漏过滤→Wrong Answer；语法错误→Compile Error；
查询题里 INSERT→运行错误并说明；递归 CTE 死循环→CPU 超时；hex(zeroblob(2e8))→内存超限；
attach '/etc/passwd'→打不开。
## 踩到的两个坑（已写进 docs/specs/phase3-coverage.md）
1. ulimit 必须用 -d 不能用 -v。-v 限虚拟地址空间而 JS 引擎预留巨量地址，实测 -v 之下
Bun 退出时有概率 panic（SIGILL），结果早已写出但进程异常终止，父进程读到空串
误判成超时 —— 6 次里坏 2 次。换 -d 后 12/12 稳定。
2. 子进程写完结果直接 SIGKILL 自己，不走 process.exit()——后者仍有清理会撞限额。
至此 admin/api.ts 已无任何指向旧后端的调用。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 17:03:41 -06:00 |
|
|
|
007ae8619b
|
feat(阶段4): SQL 测试点脚本回显
GET admin/problems/:id/sql-scripts
只读磁盘上的 N.sql，不需要 SQL 引擎 —— 同组的 sql-preview / sql-ai-gen 要跑 SQLite
生成展示数据，新后端还没有那条链路，那两个仍指向旧后端。
实测：SQL 题回显两个脚本内容正确；测试点不是 SQL 类型返回 409 并说明；题目不存在 404。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 16:45:15 -06:00 |
|
|
|
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 |
|
|
|
e396d78a07
|
feat(阶段4): 题目管理 / 比赛题目 / 比赛题⇄公开题互转
GET/POST admin/problems
GET/PUT/DELETE admin/problems/:id
POST admin/problems/:id/make-public
GET/POST admin/contests/:contestId/problems
POST admin/contests/:contestId/problems/from-public
合并了旧后端拆开的两套路由：旧 admin/problem 与 admin/contest/problem 的
GET 详情、PUT、DELETE 都只按题目 id 取、比赛是从题目推导出来的，分开没有意义，
还逼前端多传一个它未必知道的 contestId。现在共用 /admin/problems/:id。
归属判断按旧后端的口径分开：**比赛题看比赛的创建者，公开题看题目自己的创建者**
（旧 ensure_created_by(problem.contest, user) vs ensure_created_by(problem, user)）。
一道比赛题的 created_by 可能是克隆时的操作人，跟谁有权改它没关系。
题号唯一性的作用域也跟着走：公开题在全部公开题里唯一，比赛题在本场比赛内唯一。
删题不删测试用例目录，与旧后端一致（它把 rmtree 注释掉了）：删错了还能从磁盘捞回来，
而误删的测试数据没有别处备份；孤儿目录另有清理入口。有提交记录的题目拒绝删除。
## SQL 题目前只能编辑、不能新建
新后端**没有 SQL 判题链路** —— 旧 judge/sql_runner.py（378 行）+ sql_dispatcher.py
（113 行）无对应实现，languages.ts 里也只有 C/C++/Java/Golang/JavaScript/Python3 六种。
题目页给学生看的表结构与期望结果（sql_display）要跑 SQLite 现算，算不出来就没法建题。
因此：新建 SQL 题返回 501 并说明原因；**编辑已有 SQL 题时原样保留 sqlDisplay 不动** ——
不动它比生成一个错的安全，它直接决定学生看到的期望结果。SQL 的前置校验
（必须是唯一语言、要有 sql_config、要有 SQL 标准答案）照旧执行。
实测：学生 403；缺样例/缺输入描述/SQL 混语言三条校验文案与旧后端一致；
题号重复 409、跨比赛题号互不影响；公开题加入比赛后计数归零且标签带过来；
比赛题转公开后 visible=false、contestId=null、重复转 409；删除级联正常。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 16:37:20 -06:00 |
|
|
|
764e0d28cc
|
feat(阶段4): 标签管理 / 批量打标签 / 题目可见性 / 卡点与 AC 趋势 / 流程图 AI
GET/PUT/DELETE admin/problem-tags[/:id]
POST admin/problems/batch-tag
PUT admin/problems/:id/visibility
GET admin/problems/stuck
GET admin/problems/ac-trend
POST admin/problems/flowchart
要点：
- 后台标签列表用 leftJoin 且不加 having，能看到 problemCount=0 的标签 ——
那正是要清理的那些。oj 侧的 /problem-tags 才过滤 >0。
- 标签改名撞上已有标签视为合并：只给「还没挂目标标签」的题目补关系，
否则会撞 (problem_id, problemtag_id) 唯一约束。
- 批量打标签：add 时按需新建标签、remove 时只认已有标签 ——
否则「移除」会顺手造出一堆空标签。名字去重且大小写不敏感。
- **旧 ProblemVisibleAPI 的 `self.error(...)` 少写了 return**，题目不存在时会继续
往下跑并抛 AttributeError（500）。这里正常返回 404。
顺带记下一条阶段 5 的必做项（见 phase3-coverage.md 文末）：本地库按显式 id 从生产
导入，序列没跟着走，第一次新建标签就撞 problem_tag_pkey。只要切换流程里有
「导出→导入到新库」这一步，就必须重置全部序列，否则读全正常、第一次写才炸。
实测：学生 403；大小写重复与空白名去重后 tagCount=1、重复 add 幂等、
remove 不存在的标签 404 且不新建；纯改名 merged=false、合并 merged=true
affectedCount=1 且只剩一个标签；可见性取反两次复原、不存在的题 404。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 16:30:48 -06:00 |
|
|
|
5e0229db12
|
feat(阶段4): 题单管理（题目 / 奖章 / 进度三层）
GET/POST admin/problem-sets
GET/PUT/DELETE admin/problem-sets/:id
PUT admin/problem-sets/:id/visibility （取反语义，与旧一致）
PUT admin/problem-sets/:id/status
GET/POST admin/problem-sets/:id/problems
PUT/DELETE admin/problem-sets/:id/problems/:itemId
GET/POST admin/problem-sets/:id/badges
PUT/DELETE admin/problem-sets/:id/badges/:badgeId
GET admin/problem-sets/:id/progress
DELETE admin/problem-sets/:id/progress/:userId
修掉旧后端三个问题：
1. **后台列表写死了 visible=True，可它同时又提供「切换可见性」的接口** ——
一旦把题单设成不可见，它就从后台列表消失，再也没法在界面上改回来。
新实现不按 visible 过滤，后台能看见自己管的全部题单。实测取反两次仍在列表里。
2. **加题/删题/改分值后不重算学生进度**。往题单里加一道题，学生那边的
totalProblemsCount 还是老数字，进度百分比因此偏高，甚至已「完成」的人分母变了
却还标着完成。新实现加了 resyncProgress，实测 2/2 加一道题后变成 2/3 = 66.67%。
只重算分母与百分比，不碰 completeTime —— 已完成过的事实不因加题而撤销。
3. 把人踢出题单时一并收回他基于这份题单拿到的奖章，否则奖章悬空。
奖章重算对齐旧 recalculate_user_badges（那边靠 post_save 信号，这里显式调）：
只增删差集、保留已有记录的 earnedTime，否则每改一次条件所有人的获得时间都会
刷新成今天。实测 all_problems 建成时补发 1 人 → 加题后收回 → 改成
problem_count>=2 后重新发出 → 踢人后收回。
删题单要按序清五张子表（全是 NO ACTION 外键）：user_badge 挂在 problemset_badge
上，得先于 badge 删。
实测：学生 403；重复加题 409、加不存在的题 404、野状态/野奖章条件 400；
级联删除后五张表全为 0。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 16:25:14 -06:00 |
|
|
|
553c084579
|
feat(阶段4): 比赛管理 + 克隆 + ACM 赛后核查
GET/POST admin/contests
GET/PUT admin/contests/:id
POST admin/contests/:id/clone
GET/PUT admin/contests/:id/acm-helper
克隆是深拷贝：新比赛从 10 分钟后开始、时长与原比赛相同、一律不可见（时间是拍脑袋定的，
直接开放会让学生看到一场没准备好的赛），比赛题目连同标签一起复制，
提交数/通过数/statistic_info 归零 —— 克隆的是题面不是历史战绩。
实测：源题 99/55 两个标签，克隆出来 0/0 两个标签俱在。
两处比旧后端更严：
- **ACM 核查的 rank 必须属于本场比赛**。旧后端只按 rank_id 取，不校验归属，
带上任意 rank_id 就能改别的比赛的核查标记。
- 比赛详情/编辑越权时报「不存在」而不是「无权限」，不泄露「有这么个东西但你看不到」。
其余对齐：非超管只看得到自己建的比赛；空串密码归一成 null（否则 contestType 会把
「密码是空字符串」当成密码保护赛）；CIDR 按 ip_network(strict=False) 的口径校验，
允许主机位非零。
核查页的 realName 是**有意下发**的：这个页面就是老师对着名单确认谁抄了，
接口已由 requireTeacher + 归属校验双重把关。
实测：学生 403；结束早于开始 400、非法 CIDR 400 且文案带具体网段；创建空串密码
→ Public、改密码后 → Password Protected 且后台能读到密码原文；克隆时长一致且不可见；
不可见比赛的核查页 404；rank 不属于本场 404。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 16:02:28 -06:00 |
|
|
|
bc54fbff98
|
feat(阶段4): 站点配置 / 判题机 / 孤儿用例 / 概览 / 图片上传
GET/POST admin/website
GET admin/judge-servers
PUT admin/judge-servers/:id
DELETE admin/judge-servers/:hostname
GET/DELETE admin/orphan-test-cases
GET admin/dashboard
GET admin/random-usernames
POST admin/upload-image
顺带补上配置广播：旧后端改配置会经 WebSocket 推给所有开着页面的人，改完立刻生效。
新后端只服务 /ws/submissions，前端的 ConfigWebSocket 还连着旧 Django Channels。
现在加了 /ws/config 通道（同一个 Bun.serve 只能挂一个 handler，用 socket data 上的
kind 区分），前端 ConfigWebSocket 改走 /ws2/config。
几处判断：
- **判活不能比字符串**。库里 timestamptz 形如 `2026-08-07 13:42:50+00`（空格分隔），
toISOString() 是 `...T13:42:44.000Z`（T 分隔），字典序空格 < 'T'，同一天的心跳永远
小于阈值 —— 所有判题机都会显示离线。实测确实复现（dashboard 说 1 台在线、列表却
两台全 abnormal），已改为 Date.parse 后比较。
- 删指定的孤儿用例时**先确认它确实是孤儿**。旧后端不校验，一个手抖的 id 就能删掉在用
题目的测试数据，而测试数据没有别处备份。
- 图片上传的文件名完全由服务端生成，不带用户提供的任何一段；另加 10MB 上限 ——
旧后端靠 nginx 兜，但机房那台机器盘写满之后判题也会一起挂。
- 停用判题机后不再 process_pending_task()：任务在 BullMQ 里排着，worker 恢复自己接着
消费，不存在旧自研分发器那种「没有新提交就一直 waiting」的问题。
- dashboard 不再下发 env.FORCE_HTTPS / STATIC_CDN_HOST，前端从未读过。
实测：学生 403；配置读写回读 + oj 侧 /site 同步生效 + 还原；判题机列表带 token、
状态判定正确（一台 normal 一台 abnormal，与 dashboard 计数一致）；删不存在 404；
删非孤儿用例 404；随机点名缺班级号 400。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 07:43:38 -06:00 |
|
|
|
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 |
|
|
|
af9cb796bd
|
feat(阶段4): 教程 / 练习 / AI 学情报告的后台接口
GET/POST admin/tutorials
GET/PUT/DELETE admin/tutorials/:id
PUT admin/tutorials/:id/visibility
GET admin/tutorials/:id/exercises
POST admin/exercises
PUT/DELETE admin/exercises/:id
GET admin/ai/reports （?pinnedOnly=true 不分页）
GET admin/ai/reports/:id
POST admin/ai/reports/:id/pin
几处判断：
- 练习改成挂在教程下的嵌套路径，旧后端是 ?tutorial_id= 查询参数。本来就是一对多的
从属关系，嵌套更贴事实，也省掉「忘了传 tutorial_id」这类错误。
- 删教程必须先删练习。Django 的 on_delete=CASCADE 是应用层实现的，库里外键实际是
NO ACTION（核对过 pg_constraint.confdeltype='a'），直接删会撞外键变 500。
已实测：带 2 个练习的教程能正常删掉且练习一并清除。**后台每个 DELETE 都要照此
核一遍子表**，这是本阶段的通用陷阱。
- 改可见性不动 updatedAt —— 上下架不是内容修改，改了会打乱按更新时间排序的直觉。
- AI 报告的 data / systemPrompt / userPrompt 一律不下发，里面是喂给模型的原始
学情数据与提示词。列表只给 120 字摘要，与旧 AIAnalysisListSerializer 一致。
实测：匿名 401 / 学生 403 / 超管 200；教程练习增删改查、非法 type 400、
挂到不存在的教程 404、置顶互斥（同一学生至多一份）、再钉一次取消，全部符合预期。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 07:10:34 -06:00 |
|
