xuyue/OJ2
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
635 Commits 1 Branch 0 Tags
4be569d978197059d487804e03ff2ff9f6f6c751
Commit Graph
66 Commits
Author SHA1 Message Date
xuyueandClaude 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
xuyueandClaude Opus 5 d7a6414735 fix(题单): complete_time 翻回「只设不清」；完成题单后那个必然报错的 tab 
三件事，都是上一轮结论没查扎实留下的。

## complete_time

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

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

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

## 两处注释订正

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

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

## 用户进度 tab

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

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

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

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

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

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

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

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

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

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

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

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QqqZwxtXLo2GTqMi51C94D
 2026-08-31 08:23:38 -06:00
xuyueandClaude 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
xuyueandClaude Opus 5 a75c70c82d perf(后端): 干掉 14 处 N+1 查询
Deploy / deploy (push) Has been cancelled
Details 
列表接口按行发查询是从阶段 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
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 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
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 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
xuyueandClaude 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
xuyueandClaude 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
xuyueandClaude 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
xuyueandClaude 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
xuyueandClaude 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
xuyueandClaude 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
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