xuyue/OJ2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
109 Commits 1 Branch 0 Tags
19054718d5d4aa2c545c98a27067b837a3b49611
Commit Graph

11 Commits

Author SHA1 Message Date
yuetsh
586c88f629 build(数据库): 改用 drizzle migration，加提交列表索引、清掉 Django 残留
Some checks failed
Deploy / deploy (push) Has been cancelled
Details 
一条线上的三件事：让 drizzle 的迁移机制真正可用 → 用它加索引 → 用它清掉
不再需要的 Django 表，最后接进部署和 CI。

## 1. 让 drizzle-kit generate 可用

原本以为不能用：只加一个索引，generate 却吐出一堆噪音，其中 5 条
`DROP SEQUENCE auth_*/django_*` 打到生产库上会直接搞坏旧后端。
逐个查下来全是 `pull` 出的基线自己不能 round-trip，都是可修的：

- **快照里的 Django 序列**：tablesFilter 只过滤表、不过滤它们的序列。
  已从 0000_snapshot.json 清掉。
- **bigint 上限精度**：pull 生成的 `maxValue: 9223372036854775807` 是 JS
  number 字面量，round-trip 成 ...776000，每次 generate 都多出 10 条
  ALTER COLUMN。改成字符串。
- **表达式索引的 opclass**：problem_tag_name_ci_unique 在快照里带
  opclass，drizzle 自己序列化不出来，导致每次 drop + recreate。已去掉。

改完 `generate` 是干净的 no-op。

两个改不掉、只能绕的写进了 CLAUDE.md：索引 `.desc()` 生成 SQL 时会被丢
（单列索引不写方向即可，Postgres 用 Index Scan Backward 服务 ORDER BY
DESC，实测同样 0.08ms）；migrator 把所有语句包一个事务，
CREATE INDEX CONCURRENTLY 跑不了。

最容易吃亏的是 drizzle 没有 --fake-initial：对已有数据的库直接 migrate
会从 0000 跑起、撞表回滚，**而且 exit 1 但一个错误都不打印**。

## 2. 0001 提交列表索引

`WHERE contest_id IS NULL ORDER BY create_time DESC LIMIT n` 用不上现有的
contest_create_time_idx (contest_id, create_time DESC) —— Postgres 不把
`IS NULL` 当成能吃掉首列、从而继承第二列有序性的等值条件。把
enable_seqscan / enable_bitmapscan 全关掉逼它用也不肯，宁可走单列
contest_id 索引再全量排序。于是每翻一页都 Parallel Seq Scan 扫完整张表。

换成部分索引后谓词由索引自己保证，索引序就是查询要的排序序。生产快照
（12.3 万条提交）实测首页取 10 行：61.8ms / 读 18936 blocks →
0.22ms / 读 34 blocks。端到端 94ms → 6ms。

真正要命的不是单次 61ms，是每个请求都要把 169MB 的表刷一遍
shared_buffers —— 一节课几十个学生同时开提交列表，磁盘和缓存直接被打穿。

## 3. 0002 删掉 Django 残留

确认旧 Django 后端不再使用、也不再作为回滚路径。删前核实过：没有任何
OJ2 保留的表引用这 7 张，3 条外键全在它们内部（所以不用 CASCADE，真有
漏网的会报错而不是被悄悄级联掉）；5 个序列都由各自的表 owned，随
DROP TABLE 一并消失；数据全是 Django 自身元数据。tablesFilter 随之移除。

**回滚路径就此作废** —— CLAUDE.md 开头和 runbook 的「回滚保证」「七、回滚」
都改了。这条迁移已在本机 dev 库和生产快照副本上跑通，**生产库尚未执行**。

## 4. migrate 接进部署与 CI

deploy.sh 在构建之后、起栈之前跑 `oj2-api migrate`，失败就中止部署（旧
容器原样还在跑）。CI 走的也是 deploy.sh，所以不用给 GitHub 配数据库凭据，
也不用把生产库对外开放。

迁移文件**不内嵌进二进制**，随镜像装在 /usr/local/share/oj2/migrations。
这样 drizzle 的 migrate() 能原样用 —— 靠 _journal.json 自动发现，新增迁移
不用改任何代码，和 Django 扫 migrations/ 是一回事。内嵌就得为每条迁移
手写一行 import，那是迟早会漏的账。（CLAUDE.md 里「单二进制不能读文件」
那条讲的是 node_modules 和 import.meta.dir 推路径，按显式绝对路径读一个
数据目录不在此列。）

三道闸门，都是写完测出来才补上的：

- **破坏性迁移拦截**：DROP TABLE / DROP COLUMN / DROP SCHEMA /
  ALTER COLUMN ... TYPE / TRUNCATE 命中就退出 4，需要
  `OJ2_ALLOW_DESTRUCTIVE=1` 显式放行。DROP INDEX / DROP CONSTRAINT 不算，
  拦了只会让人习惯性带上放行开关。扫描前先剥注释，避免误报。
- **基线缺失**：退出 3 并直接打印该敲的 SQL。注意判的是
  `max(created_at) < 0` 而不是「表不存在」—— 表存在而为空（上次迁移失败
  留下的）同样是没基线。
- **迁移目录读不到**：这是最可能犯的错（Dockerfile 漏拷），原本是 drizzle
  的堆栈，现在直接说该检查哪一行。

另外发现 0000_crazy_gateway.sql 是 pull 的产物，**整份被 /* */ 包着，
可执行语句 0 条**，所以这个库根本不能靠迁移自举建表。原先写的「空库就从
0000 建」跑起来会炸在一个和真实原因毫不相干的 unterminated /* comment 上。
现在如实说明：结构只能来自 docs/specs/schema.sql 或生产 dump。

验证：镜像内编译（ARTIFACTS=build）出的真实镜像跑完五种场景 —— 拦截、
放行、幂等、无基线、漏拷目录，全部符合预期；dev 形态同样五种场景全过。
tsc / 路由遮蔽 / deploy.sh 语法 / generate no-op 都通过。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-26 07:56:30 -06:00
yuetsh
6e905085a1 chore(依赖): 后端升到 TypeScript 7，前端被 vue-tsc 挡住留在 5.9 
apps/api 单独嵌套 typescript ^7.0.2，`bun run --filter '@oj2/api' typecheck`
从此跑的是原生版；根和 apps/web 留在 5.9.3。api 在 TS 7 下 0 error，
另外塞了个故意写错的文件复检过，确认它真在报错、不是静默跳过。

前端升不了：vue-tsc 启动时要 require.resolve("typescript/lib/tsc")，
而 TS 7 的 exports 里已经没有这个子路径，直接
ERR_PACKAGE_PATH_NOT_EXPORTED。vue-tsc@latest 就是仓库里的 3.3.11，
还没有支持 TS 7 的版本 —— 它 peer 写的是 typescript >=5.0.0，范围太松，
装上去不报冲突、一跑就炸。读源码看到 resolveTscPath 里唯一的适配分支是认
@typescript/typescript6，可见 Vue 侧目前给的路只到 6。硬上的代价是丢掉
刚清零的前端类型门禁，不值得。

顺带清掉一处假配置：apps/web 原本声明着 "typescript": "^7.0.2"，是
ae1fb32 从 ojnext 原样搬过来的，**从来没生效过** —— vue-tsc 被 hoist 在根
node_modules/，解析 typescript 时看的是根上那份 5.9.3，压根看不见
apps/web 里嵌套的 7.0.2。留着它有两个坏处：白拉 20 个
@typescript/typescript-* 平台包；哪天 bun 换个 hoist 策略把它提到根上，
vue-tsc 就会以那个看不懂的 ERR_PACKAGE_PATH_NOT_EXPORTED 挂掉。改成显式
跟随根版本。

所以现在的分工是：**vue-tsc 把根上的 typescript 钉死在 5.x**，谁要升根
版本谁先解决 vue-tsc。等 vue-tsc 支持 TS 7，把 apps/api 那行删掉、
根上升到 7 即可。

验证（删空 node_modules 重装后）：apps/api tsc 7.0.2 下 0 error、
check:routes 167 条无遮蔽、apps/web vue-tsc 0 error、vite build 通过、
drizzle-kit v0.31.10 正常。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-25 17:39:50 -06:00
yuetsh
0e1e024fa4 chore(依赖): 升一批 patch/minor，锁死 mermaid-legacy 和 TypeScript 大版本 
后端：@node-rs/jieba 2.0.1→2.0.2（含精确 pin 的 -linux-x64-gnu）、
bullmq 6.0.9→6.2.2、postgres→3.4.9、sql.js→1.14.2、web-tree-sitter→0.26.13；
hono ^4.0.0→^4.13.4 与 zod ^4.0.0→^4.4.3 只是把范围收紧到实装版本。

前端：@codemirror/view→6.43.9、highlight.js→11.12.0、mermaid→11.17.2、
naive-ui→2.45.2、pinia→4.0.3、y-codemirror.next→0.3.6、vite→8.2.2、
@types/node→26.3.0。

刻意没动两个：

- mermaid-legacy（npm:mermaid@^9.4.3）保持 9.4.3，vite 的 build target
  也没碰 —— 机房 Chrome < 94 的兜底，legacy polyfill 产物照常生成。
- typescript 停在 5.9.3（只把根上的范围从 ^5.7.0 收到 ^5.9.3）。
  7.0.2 是 Go 原生重写版，另开一个 commit 处理。

踩到的坑记一笔：`bun install` 不清理旧的嵌套副本。升完 @codemirror/view 后
md-editor-v3/node_modules/ 下留着一份 6.43.8，vue-tsc 立刻报
dispatchTransactions 私有属性冲突 —— 看起来像版本不兼容，其实
md-editor-v3 要的是 ^6.38.2，6.43.9 完全满足。当时全仓有十几处这种残留。
**升完依赖必须 rm -rf node_modules && bun install 再验类型**，否则会
对着一堆假的类型冲突查半天。

验证（删空 node_modules 重装后）：apps/api tsc 0 error、check:routes 167 条
无遮蔽、apps/web vue-tsc 0 error、vite build 通过、单二进制在仓库外起得来
并打库返回真数据、jieba 原生模块 dev 与编译两种形态都验过、BullMQ 两个
worker 正常 ready。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-25 17:39:06 -06:00
yuetsh
967e9ef7f7 feat: 路由遮蔽检查脚本；切换前把前后端接口逐条对了一遍 
## 切换前核对：前端调的接口后端有没有漏

写脚本把前端 224 个调用点和后端注册的路由逐条比对。**零缺口** —— 唯一报出来的
一条是我的正则被嵌套括号截断了（`users/${encodeURIComponent(...)}/badges`），
后端那条路由是有的。「后端有、前端没调」那 25 条也逐个看过，全是脚本的假阳性
（把 `.get("user")` 这类非路由调用当成了路由）和假阴性（前端用三元表达式拼路径，
正则看不见，比如 `GET /me` 其实在 shared/api.ts 里被调）。

结论是没发现缺口，但这个脚本不够可靠、不足以证明"一定没有"，所以没留进仓库。

## 路由遮蔽检查（留成常驻脚本）

比"有没有漏"更值得防的是遮蔽：**Hono 按注册顺序匹配，不是静态优先**。
`/problems/:id` 注册在 `/problems/random` 前面的话，后者永远进不去 ——
不报错、不警告，只是静默走进前一条的 handler。阶段 4 真实发生过一次，
两个教师用的分析端点被吃掉，一直到评审才发现。

全仓 167 条路由按真实注册顺序扫：**零遮蔽**。

这个结论敢下，是因为检测器本身也验了：
- 自检用例里放了阶段 4 那个历史真实案例，能抓到；边界（两边都是参数、
  段数不同、不同前缀）不误报
- 核对了 24 个 router 全在扫描范围内，没有漏扫
- 反向验证：往 problem.ts 末尾加一条注册在 `:displayId` 之后的字面量路由，
  脚本立刻报出来并 exit 1

未经验证的检测器报"没问题"是没有意义的 —— 这个教训今天已经吃过两次
（tree-sitter 那次、SQL 内存那次）。

脚本落在 apps/api/src/scripts/check-route-shadowing.ts，
`bun run --filter '@oj2/api' check:routes`，加完路由跑一下。
CLAUDE.md 里也写了。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-08 03:42:37 -06:00
yuetsh
ea521e7b0a feat(阶段5): 镜像、三套 compose，前端切回 /api 与 /ws 
## 镜像

一个 Dockerfile 两个 target：api（单二进制）和 web（Caddy + 前端产物）。
旧后端是一个容器里用 supervisord 跑 caddy+gunicorn+dramatiq，这里拆成
oj-web / oj-api / oj-worker 三个容器 —— Docker 本身就是进程管理器，
拆开之后 worker 挂了能单独重启、日志也分得开，少一层 supervisord 要维护。

同一个镜像换个子命令就是 worker，镜像里只有一份运行时。
新增 healthcheck 子命令：运行镜像是 debian-slim，没有 curl/wget，
让二进制自己打 /health（只打 /health 不碰库 —— 库挂了该由库的 healthcheck 报，
不该让 api 跟着被判不健康然后被重启）。

**数据目录照抄旧后端**（test_case、public/upload、public/avatar）。
不是审美问题：切换那天不用搬动任何文件，回滚时旧后端立刻能找到自己的数据。
少一次几十 GB 的 mv，就少一个在停机窗口里出错的机会。

构建路上踩到三个坑，都是「本地能过、容器里过不了」那一类：

- 构建上下文吸进了 data/，judge_server/run 是判题沙箱用别的 uid 建的，
  docker 连 stat 都做不了，构建直接失败 → 补 .dockerignore
- mermaid@9.4.3（机房老 Chrome 的 legacy 依赖，不能砍）从容器里连
  registry.npmjs.com 稳定失败，主机上没问题 → 换 npmmirror，并重试两次
- 容器里 bun 用 isolated 布局，本地是扁平的。靠「提升」才能解析到的包
  在容器里一律解析不到：@node-rs/jieba-linux-x64-gnu（编译要 import 它的 .node）、
  以及前端的 @codemirror/{language,state,view} 和 @lezer/highlight。
  这些本来就是代码直接 import 的，补成直接依赖。顺手写了个脚本扫全仓，
  确认只有这 4 个。

## 前端切回 /api、/ws

迁移期用 /api2、/ws2 指新后端，/api、/ws 还指着 Django。端点已全部搬完，
临时前缀去掉。改动只有三处（api2.ts 的 baseURL、websocket.ts 的两个 URL），
`api2` 那些 import 是模块名不是路径，不动。vite 代理同步收敛成三条。

## compose

- debian：全套（含 postgres，对外开 5445 给机房连）
- school：**没有 postgres**，连服务器的库；本地 Redis + 本地判题沙箱
- 两边共用一个库但各有各的队列和 WS 推送，和旧后端的 Dramatiq/Channels 拓扑一致

密钥一律走 env 且带 `:?`，没设置就直接报错退出，不静默用弱默认值。
COOKIE_SECURE 在机房必须是 false（http 直连 IP，带 Secure 的 Cookie 发不回来，
表现是「登录成功但立刻又变未登录」）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 23:41:20 -06:00
yuetsh
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
yuetsh
e3faa689e7 feat(阶段2补课): SQL 判题链路 + 最后两个后台端点 
新后端此前完全没有 SQL 判题（旧 judge/sql_runner.py 378 行 + sql_dispatcher.py
113 行无对应实现），阶段 2 纵切时漏了这条与沙箱完全不同的路径。

  judge/sql/engine.ts   判题核心，移植自 sql_runner.py，判定口径逐条对齐
  judge/sql/child.ts    子进程入口
  judge/sql/index.ts    父进程：spawn + 硬超时
  judge/run.ts          language === "SQL" 时分流，不经判题沙箱
  POST admin/sql-test-cases/preview    题目页展示数据预览
  POST admin/sql-test-cases/generate   AI 按标准答案倒推初始化脚本

题目保存时重新生成 sqlDisplay（对齐旧 generate_sql_display）：取测试点 1 的初始化
脚本 + 标准答案跑一遍，失败一律拦下不让保存 —— 展示数据直接决定学生看到的表结构
与期望结果，宁可不保存也不能存错的。

## 防护换了实现，逐条实测

bun:sqlite 没有 authorizer / progress_handler / setlimit，且实测 Worker.terminate()
杀不掉跑飞的查询（原生代码占着线程）。改用「WASM 引擎 + 独立子进程」：

  ATTACH  → WASM 无宿主文件系统绑定，结构上够不到（比旧的 authorizer 更强）
  查询题只读 → PRAGMA query_only=1
  超时    → 子进程外部 SIGKILL
  单值内存 → 子进程 ulimit -d

八条提交实测：正确→Accepted；列少一个/漏过滤→Wrong Answer；语法错误→Compile Error；
查询题里 INSERT→运行错误并说明；递归 CTE 死循环→CPU 超时；hex(zeroblob(2e8))→内存超限；
attach '/etc/passwd'→打不开。

## 踩到的两个坑（已写进 docs/specs/phase3-coverage.md）

1. ulimit 必须用 -d 不能用 -v。-v 限虚拟地址空间而 JS 引擎预留巨量地址，实测 -v 之下
   Bun 退出时有概率 panic（SIGILL），结果早已写出但进程异常终止，父进程读到空串
   误判成超时 —— 6 次里坏 2 次。换 -d 后 12/12 稳定。
2. 子进程写完结果直接 SIGKILL 自己，不走 process.exit()——后者仍有清理会撞限额。

至此 admin/api.ts 已无任何指向旧后端的调用。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 17:03:41 -06:00
yuetsh
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
yuetsh
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
yuetsh
ec274419c3 Build Phase 2 judge vertical slice 2026-08-06 22:42:39 -06:00
yuetsh
f635737453 feat(阶段1): drizzle schema 从本地库生成并剪掉 Django 框架表 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-06 20:45:51 -06:00