8 Commits

Include renames

Author	SHA1	Message	Date
xuyue	d25b5dbe6d	update	2026-09-27 19:36:28 +08:00
xuyueandClaude Opus 5.5	9412ba3cf6	refactor(契约): 展示题号统一叫 problemDisplayId，题单 id 统一叫 problemSetId ... 前后端同时改，部署前开着的旧页面要刷新一次（题号列会是空的、提交筛选会失效）。 - 挂在非题目对象上的展示题号，原来叫 problem（字符串）或 displayId，统一成 problemDisplayId：提交列表、流程图列表、统计的 lastFailure / items / 今日最热题、站内信里的提交、后台题单的题目列表。别处的 problem 都是对象 或数字 id，这几处是字符串，最容易看错 - 列表筛选的 query 参数 ?problemId= 实际传的是展示题号，改成 ?problemDisplayId=（提交列表、流程图列表、三个统计接口） - 契约里 problemsetId / problemSetId、problemset / problemSet 两种拼法并存， 统一成 problemSetId / problemSet，和 ProblemSet* 类型名、problem-sets 路径、前端路由参数一致。drizzle 的列键跟表名走，没动 - aiDetail.user（用户名字符串，而契约里别的 user 都是对象）→ username。 ai_analysis.data 里存的历史快照仍是 user，没有代码读回它 - 后台题单题目表的列是按字符串键 'displayId' 取的，类型检查抓不到，一并改 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-09-27 16:08:31 +08:00
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	eda1eb7eee	chore(题单): 删掉客户端自报进度的 PUT /problem-set-progress ... 这个端点是「AC 之后前端回调一下，把进度写进题单」那套设计的残留，早就被服务端记账 取代了 —— SubmitCode.vue 里留着当时的说明：客户端那条路只认路由参数里的那一个题单 （从普通题库入口做出同一道题不计进度），网络一抖、页面提前关掉进度就静默丢失； 现在判完之后由 judge/run.ts → services/problemset.ts 的 recordSolvedProblem 记账， 而且记进所有已加入且包含这道题的题单。 上一个提交删掉前端最后一个调用方 updateProblemSetProgress 之后，它就彻底没人打了。 留着的代价不只是死代码：那是一条**学生可以自己写进度**的写入口。 删之前逐个核过： - 前端零引用（唯一的 wrapper 已在上个提交删掉）； - recomputeProgress 还有 POST 那条在用，保留；computeProgress / eligibleForBadge / updateAchievementsForProblemSet / publishAchievementNotification 在别处都有调用方； - 它往 problemset_submission 写的那一笔，services/problemset.ts:260 做的是一模一样的 去重后插入，不会因此少写。 顺带清掉因此变成孤儿的四个 import 和契约里的 updateProblemSetProgressRequestSchema 与 UpdateProblemSetProgressRequest。 ## 验证 起服务实跑： - PUT /api/problem-set-progress 现在 404； - 保留的 POST（加入题单）仍然 201，progress 行照常由 recomputeProgress 建出来； - 服务端那条替代路径端到端跑通：新建题单 → 加入题目 1004 → 学生加入 → 交一发 AC， 判完后 problemset_progress 自动变成 completed=1/total=1/100%/得分 10， problemset_submission 也落了一行 —— 全程没有任何客户端回调。 tsc、check:routes、vue-tsc、单二进制编译均通过；测试题单已清理。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012j1vgeDqay8wKCh8dPgPcH	2026-09-10 19:42:17 -06:00
xuyueandClaude Opus 5	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
xuyueandClaude Opus 5	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
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	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