14 Commits

Include renames

Author	SHA1	Message	Date
xuyueandClaude Opus 5	b16e11e85d	fix(题目推荐): 已 AC 过滤下推 SQL、难度按语义排序、难度标签渲染 ... 相似题目推荐（GET /problems/:displayId/similar）三个 bug： - 排除已 AC 的题发生在 limit(5) 之后，候选被筛掉几条就少几条，甚至清零让整块 不渲染。而这个接口只在刚 AC 或连挂三次时才调用，正是最容易全中的时候。 （老栈是 .exclude(...) 在切片之前，重写时引入的回归） - order by difficulty 是 text 字典序，High < Low < Mid，「由易到难」实际是最难的 先上。改成显式 case 排名，并加上共享标签数作为第一排序键、id 兜稳定序。 - 前端 ref<any[]> 盖住了类型错误：getSimilarProblems 已过 filterResult，难度是 中文，模板却在比 'Low' / 'High' 再查 DIFFICULTY 表，结果每条推荐都渲染成黄色 的「中等」。 顺带：比赛题不再发这个请求（接口只在公开题库按 displayId 找，撞号会在比赛中把 题库列给学生）；多余的 id in (子查询) 换成 join 中间表。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 09:24:46 +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	cc51e305cf	refactor(时区): 常量收进契约、SQL 统一走 localTime，去掉会话时区与 TZ 兜底 ... - TIME_ZONE / TIME_ZONE_OFFSET_MINUTES 移到 packages/contract/src/time.ts， 前后端共用一份，不再各写一遍靠注释对齐。 - apps/api/src/time.ts 新增 localTime(列)，替换散落 7 处的 `at time zone ${TIME_ZONE_SQL}`；ac-trend 的 where 复用同一个 year 表达式。 - /problems/:displayId/yearly-ac 漏写了时区、按 UTC 切年，被会话时区兜底掩盖； 改为按东八区切（只影响每年 12-31 北京 0–8 点的提交归年）。 - 删掉数据库连接的 TimeZone 和 Dockerfile 的 TZ：正确代码不依赖它们， 它们只会在线上掩盖漏写处、让 dev 与线上答案不同。 - time.ts：calendarDayYearsAgo/pad 并入 shiftMonthsByCalendar，startOfCalendarDay 并入 todayStart，localWeekday 改用 getUTCDay，删掉历史叙述注释。 - 前端 zonedParts 改为固定偏移 + getUTC*（与后端、日期选择器同一写法）， 去掉 Intl formatToParts；10 万次 299ms → 11ms。zonedYear 去掉按浏览器时区的兜底。 - 两份 CLAUDE.md 同步；n-date-picker 那条过时说明改成现用法。 验证：新旧「近两年起点」21359 个时刻 0 差异、localWeekday 0 差异、 前端固定偏移与 Intl 在 America/New_York 下 47821 个时刻 0 差异； localTime 在 select/group by/where 复用可用；fix-achievement-hours 预演仍为 148 / 60。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd	2026-09-14 06:06:52 -06:00
xuyueandClaude Opus 5	4c0c38445c	fix(时区): 日历口径收回东八区，读出的时刻统一成 ISO 并保留微秒 ... 旧栈 Django 按 Asia/Shanghai 算日历，OJ2 重写时这个锚点丢了：容器和数据库会话 都是 UTC，于是「今日提交」在北京时间 0–8 点是空的，「凌晨/早起提交次数」整体偏 8 小时，热力图、AC 趋势年份、近两年活跃人数也各按进程时区切。 - 新增 apps/api/src/time.ts 作为唯一锚点（固定 +8 偏移，不依赖进程 TZ / tzdata）， todayStart、成就小时/日期键、热力图、月份平移、年份夹逼全部改走它； SQL 里按日历切的一律显式 at time zone。 - db/index.ts：连接会话时区设为东八区（兜底）；给 timestamptz(1184) 挂 parser， 读出统一成 ISO 8601 UTC，撤掉为拿 PG 文本形状写的 ::text。parser 保留微秒 —— 生产库 12.3 万条提交几乎全带微秒，截成毫秒会让翻页分界行和班级 AC 排名的 <= min(create_time) 把自己排除（翻页每页丢一条、排名少 1）。 - 前端 parseTime/zonedParts/zonedYear 按 Asia/Shanghai 渲染，n-date-picker 做 toPickerValue/fromPickerValue 平移，站内不再按浏览器时区取时间部件。 - Dockerfile 设 TZ=Asia/Shanghai 作为第二道兜底。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01K1d8B3f4SXJwDvUY625eQd	2026-09-14 05:55:17 -06:00
xuyueandClaude Opus 5	ab47e71d6f	refactor(契约): 出参不再 parse，后台老题详情和站内信页不再 500 ... ## 出参改 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
xuyueandClaude Opus 5	25b86ec17e	refactor(提交): 删掉从来没用起来的「提交互相可见」 ... 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	bb0f5ec5ef	fix(AI提示): 解锁条件前后端对齐，提示不再一点就没 ... 「失败 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
xuyueandClaude Sonnet 5	7b6bfeb6fb	fix(标签): /problem-tags 计数漏过滤隐藏题和赛题 ... 标签列表按题目数 > 0 过滤，但计数没有像 /problems 那样限制 visible=true 且非赛题，导致标签在首页出现、点进去却一道题都没有。 同时把旧仓库冻结政策收紧写进 CLAUDE.md：从今天起旧仓库零改动， 不再有内部小修的例外，所有后续工作只落在 OJ2。 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>	2026-08-26 00:22:05 -06:00
xuyueandClaude Opus 5	3f6b4102c9	feat(题目): 学生题目页恢复「要求」展示，走新的 astRequirements 字段 ... 旧后端的 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	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	b4b61af6b0	fix(阶段3): 匿名不可读用户档案，真名改为默认不下发 ... F1：GET /profiles/:username 只挂了 optionalAuth、handler 内无登录判断， 匿名可读 email、adminType、className、lastLogin。用户名又能经 /rankings/users 公开枚举，等于可以无 cookie 批量收集全校学生的邮箱与最后登录时间。 handler 开头补上未登录即返回空，对齐旧后端 account/views/oj.py 的 UserProfileAPI.get 首行 `if not user.is_authenticated: return self.success()`。 F2：旧后端把「是否下发真名」做成 UsernameSerializer(need_real_name=False) 的默认关闭开关，全仓 11 处调用只有比赛榜单一处显式打开；新后端没搬这一层， 真名随用户对象无条件下发，13 个下发点里 8 个匿名可达。 这里补回同一层：helpers.ts 新增 sampleUser()，realName 默认不下发， 需要的地方显式传 { includeRealName: true }。12 个下发点改为走这个函数， 只有比赛榜单一处打开（对齐 contest/serializers.py:84 的 is_contest_admin）。 没有逐处删字段 —— 那样下次新增端点还会重犯。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-07 01:59:05 -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	3c975e85ee	feat(阶段1): Hono 应用与题目列表接口，读通本地真实数据	2026-08-06 21:14:58 -06:00