xuyue/OJ2
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
475 Commits 1 Branch 0 Tags
cdd69764c4eca50f27a2ec97f093e67ea6bbc617
Commit Graph
27 Commits
Author SHA1 Message Date
xuyueandClaude Opus 5.5 84bfb44c20 feat(题目列表): SQL 题混在一般题里看不出来，点进去才发现不是写 C——和画流程图一样挂「SQL」标签，「全部类型」里也能单独筛 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-09 16:51:42 +08:00
xuyueandClaude Opus 5.5 e852bf4498 fix(题目列表): 排序里多了个用不上的「按题号」，原来的最早创建、最多 / 最少提交、通过都没了——换回原来那一套
Deploy / deploy (push) Canceled after 0s
Details 
最新创建 / 最早创建 / 最多人做过 / 最少人做过 / 最多人做对 / 最少人做对。排序值和原来一样，
旧链接照样能用；「最多 / 最少」改成按人数，和最后一列「做对 / 做过」对得上。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-09 12:58:26 +08:00
xuyueandClaude Opus 5.5 97426f0895 fix(题目列表): 选了知识点后题目改成按题号排，和平时看惯的「最新的在前」不一样——默认一律按最新创建 
排序下拉固定三项：最新创建（默认）/ 按题号 / 最多人做对。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-10-09 12:57:14 +08:00
xuyueandClaude Opus 5.5 ed7752afbb feat(题目列表): 学生自己挑题时只看得到一堆标签和提交数，不知道自己练到哪了——改成左栏知识点进度、顶上先说做到了什么
Deploy / deploy (push) Canceled after 0s
Details 
- 左栏是知识点（可切到主题）和自己的进度：做了一部分写 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
xuyueandClaude Opus 5.5 a8918b41b1 fix(题目统计): 「答案错误几乎都卡在第 1 个测试点」几乎每道题都弹，说了等于没说——答案错误最多时不再给提示
Deploy / deploy (push) Canceled after 0s
Details 
七成多的题错得最多的都是答案错误（快照 349 / 484），卡在第 1 个测试点过六成的也有 185 / 320 道，
两句提示对哪道题都一样。具体错在哪，每次提交的结果里已经有「题目里的例子 N 就错了」和三栏对照。
运行时错误、编译失败排第一时的提示保留。后端那条扫 info JSONB 数第 1 个点的查询一起删掉。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 12:21:00 +08:00
xuyueandClaude Opus 5.5 13051926cf fix(统计): 按班级列的时候零星一两个人补做的班排在最前，改成交过的人多的在前
Deploy / deploy (push) Canceled after 0s
Details 
题目页「各班做得怎样」和数据统计「按班级汇总」一起改，两边顺序一致。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 00:59:41 +08:00
xuyueandClaude Opus 5.5 50d8e072ac fix(题目页): 统计页签的各班表和数据统计「按班级汇总」对不上，改成同一个口径 
原来题目页写 13/26（做对/交过）、数据统计写 13/58（做完/班级人数），列的班也不一样，
老师点过去看到的数「变了」。现在两边都是：只算学生，做完/班级人数、交了没对、没交、
正确率、最近一次，按最近一次排。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 00:56:35 +08:00
xuyueandClaude Opus 5.5 db493cebe4 fix(题目页): 统计页签的老师版回到讲这道题本身，各班只列一张表，不选班、不列人名
Deploy / deploy (push) Canceled after 0s
Details 
按人看谁没做对是提交页「数据统计」的活；表里点一个班就去那边看。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 00:50:01 +08:00
xuyueandClaude Opus 5.5 99319fdcc5 feat(题目页): 「统计」页签重做——学生看难不难、几次做对、常错在哪，老师按班看谁没做对 
- 全部按人算：原来的「通过数」是 AC 条数、「通过率」按提交算；击败用户、饼图、历年 AC 率去掉
- 错得最多的那种给一句该怎么办（都指向「运行例子」），自己交了 3 次以上还没对再多一张卡
- 老师选一个班：做对 / 交了没对（次数、最后结果）/ 没交；班里错得和全站不一样时点出来
- 题库入口工具栏的「课堂统计」并进这里（题单没有页签，按钮留着）
- 新接口 /problems/:id/stats（按内部题号，比赛题不再查到同号公开题），删掉 beat-count、yearly-ac

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-30 00:39:57 +08:00
xuyueandClaude Opus 5.5 d07459928d feat(标签): 题目列表的标签分成「知识点」「主题」两组，新建的标签在后台标出待归类
Deploy / deploy (push) Canceled after 0s
Details 
- 迁移 0022：problem_tag 加 category（knowledge / theme）和 category_confirmed；
  存量 25 个题材、题集类标签归主题，其余归知识点，全部记为已确认
- 前台题目列表按两组显示标签，组内按题目数从多到少
- 后台标签管理：每行切换分类；出题时新建的标签默认知识点、标「待归类」并排在最前，
  页头提示待归类数量，可点「确认」保留默认；加分类筛选
- 新接口 PUT /admin/problem-tags/:id/category，设置分类即视为确认

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 2026-09-27 20:38:43 +08:00
xuyue d25b5dbe6d update
Deploy / deploy (push) Canceled after 0s
Details
2026-09-27 19:36:28 +08:00
xuyueandClaude Opus 5 8b4d8899f9 feat(判题机): 自建镜像升级工具链，语言收敛到 C / C++ / Python
Deploy / deploy (push) Canceled after 0s
Details 
上游 QingdaoU/JudgeServer 停更在 2024-04（registry 上的 latest 和 1.6.1 是同一份
镜像，编译器停在 gcc-13），没有新版可拉，所以自己重编。docker/judge/ 是只改工具链
的 Dockerfile 分叉，server/ 和 Judger/ 从上游固定 commit b28aa56 拉，一行没动。

镜像 oj2-judge-2（不在任何 registry 上：本机 build.sh --save → scp → docker load）
- gcc/g++ 13 → 14.2，Python 3.12 → 3.13.5，都是 trixie 默认
- Go / JDK / Node 整套删掉：前端的题目语言复选框从来只给 C / C++ / Python / SQL，
  12 万条提交里 Java 44 条、Golang 15、JavaScript 3，全是很早以前的
- 体积 1.1GB → 433MB；默认走清华源，构建 12 分钟 → 40 秒（--no-mirror 换回官方）
- deploy.sh 加一道自检：镜像不在本机就中止，并打印该跑的三条命令

C 的编译参数加三个 -Wno-error（implicit-function-declaration / int-conversion /
incompatible-pointer-types）：gcc-14 把它们从 warning 提成了 error，而 -w 压不住。

语言值统一成 Python（迁移 0019 / 0020）
- 0019：Python3（104527 条提交）与 Python2（3 条）并成 Python，一并改掉 937 道题的
  languages、75 个 template 键、15 个 ast_rules 键、257 条 answers、1235 个用户的
  成就指标 _languages（languages_used 重算，总和 1928 → 1925，少的 3 个是同时用过
  两种 Python 的人）
- 0020：把 Java / JavaScript / Golang 从 84 道题的可选语言里摘掉 —— 不摘的话那些题
  的语言下拉还能选 Java，提交必 SYSTEM_ERROR
- 契约新增 normalizeLanguage() 别名表，判题侧一律走 judgeConfigFor()：旧客户端
  localStorage 里的 Python3、迁移前排进队列的任务都还能判；协作的语言归一也走它，
  否则上线那一刻学生页面里的 Python3 会静默落到 C
- 回滚要连数据一起回，只滚代码会让所有 Python 提交变 SYSTEM_ERROR

实跑
- 判题冒烟 docker/judge/smoke.ts 13 条全过：三种语言、六种状态码、gcc 宽松度
- 拿备份里的真实代码逐文件比对新旧镜像的编译结果，0 差异：C 提交 1951 份
  （1725 过 / 226 CE）、C++ 882 份、Python 2000 份、20 篇 C 教程的 93 个代码块。
  不加那三个 -Wno-error 的话，C 有 26 份会从能过变成 CE
- 迁移在灌了 12.4 万行真实数据的一次性库里跑过：0 残留、没有题目被清空；
  dev 库用真正的执行器跑通
- check:ast 56 个 target 全过，前后端 typecheck 均 0

顺带记下一个升级之前就有的坑（现在随 Go 一起消失，写在 README 里）：GOCACHE 指向
容器的 tmpfs，判题机重启后第一次 Go 提交是冷构建，Go 1.22 要 5.6 秒 CPU、超过 3 秒
的编译预算，于是重启后第一个交 Go 的学生必吃一次 CE，后面的人缓存热了又都正常。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-09-20 06:24:05 -06:00
xuyueandClaude Opus 5 ed56a209ea chore(格式): Prettier 统一到全仓，后端和契约一次性格式化
Deploy / deploy (push) Has been cancelled
Details 
原来只有 `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
xuyueandClaude Opus 5 91712b482d fix(AST): f-string 规则从上线起就没生效过；加 check:ast 把这类静默错判变成机器检查
Deploy / deploy (push) Has been cancelled
Details 
## 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
xuyueandClaude Opus 5 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
xuyue aab0404ed7 refactor(契约): 语言与判题产物的形状收进契约，学生端高频响应接上运行时校验
Deploy / deploy (push) Has been cancelled
Details 
契约在前端一直只当类型包用：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
xuyueandClaude Opus 5 25b86ec17e refactor(提交): 删掉从来没用起来的「提交互相可见」
Deploy / deploy (push) Has been cancelled
Details 
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
xuyueandClaude Opus 5 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
xuyueandClaude Opus 5 f38444c97a fix(代码规则): 给 C 题配的规则一半是哑弹，C++ 题根本配不了
Deploy / deploy (push) Has been cancelled
Details 
后台的节点下拉是一张 C/Python 混在一起的 15 条表，整份铺给每种语言。给 C 题选到
只有 Python 有的 list_comprehension、f-string，规则存得进去，判题时拿裸名去比节点
类型，C 的语法树里永远不存在它——「必须使用列表推导式」永远失败、「不能使用
f-string」永远通过，两头都不报错，只有学生受着。反过来 mappings 支持的 do_while、
switch、struct、include 在表里没有，编辑器根本选不到。

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

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

一起收掉的几处：

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

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

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

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-27 11:53:37 -06:00
xuyueandClaude Opus 5 7793a2fe4c 清理旧后端下线后的残留
Deploy / deploy (push) Has been cancelled
Details 
旧 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
xuyueandClaude Opus 5 3f6b4102c9 feat(题目): 学生题目页恢复「要求」展示，走新的 astRequirements 字段
Deploy / deploy (push) Has been cancelled
Details 
旧后端的 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
xuyueandClaude Opus 5 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
xuyueandClaude 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
xuyueandClaude Opus 5 44f6f27841 chore(阶段3): 删除阶段 1 的临时验证物 
GET /api/dev/problems、dev-problems.vue、对应路由项，以及只服务于它的
problemSummarySchema。阶段 1 用来验证「能从真实库读出一道题」，已完成使命。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 06:48:20 -06:00
xuyueandClaude 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
xuyue ec274419c3 Build Phase 2 judge vertical slice 2026-08-06 22:42:39 -06:00
xuyue 9bfe629cd7 feat(阶段1): monorepo 骨架与 @oj2/contract 契约包 2026-08-06 20:39:39 -06:00