5 Commits

Include renames

Author	SHA1	Message	Date
xuyueandClaude Opus 5	ed56a209ea	chore(格式): Prettier 统一到全仓，后端和契约一次性格式化 ... 原来只有 `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	a5b57d8ab8	fix(判题): 任务被遗弃时给提交落一个终态，别永远停在「等待评分」 ... judgeSubmission 自己的 try/catch 已经把正常路径上的异常都接住、落成 SYSTEM_ERROR 了，但队列的 failed 事件只有一行 console.error。判题队列没配 attempts（flowchart 队列配了 3），失败即终局；worker 进程被杀那种 —— 机房断电、容器 OOM、部署重启 —— BullMQ 走完 stalled 重入队还是没人接，最后 emit failed，那条提交就永远停在 「等待评分」：学生看着转圈，教师统计里还占着一个「判题中」的名额。 加 failAbandonedSubmission()，在 failed 里调用，复用已有的 markSystemError（只动 PENDING/JUDGING，判完的和重判过的都不会被覆盖）。三种情况实跑验过：不存在的提交 安全返回、卡住的那条变成 result=5 并写入 err_info、已 AC 的那条没被动。 生产库里 3 条卡死的 PENDING（2022-11 / 2026-03 / 2026-04）都是旧栈时代留下的， OJ2 上没有实例 —— 这次是把口子堵上，不是修已发生的故障。那 3 行和跟着差 1 的三道题 计数器还得手工处理。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KqjE6qPo67fqVDKn6Bx7yd	2026-09-08 18:29:30 -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	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