部署：push origin 就由开发机编好、测过再传到服务器，服务器不再自己编，push 后一两分钟上线。照 OJ2 的做法，开发机上的 gitea-runner（和 OJ2 共用，标签 iot-deploy，一次只跑一个任务）跑 .gitea/workflows/deploy.yml：编 C# 运行时（Release）、网页和 server.js，跑服务端测试（用要上线的 Release 版运行时）、网页端测试和类型检查，产物 rsync 到服务器的 prebuilt/（按内容比、传完才换上、断了重试），服务器上 deploy/update.sh --prebuilt 用现成产物构建镜像，只剩几条 COPY。以前 GitHub 上测试约 5 分钟、服务器 2 核再编约一分钟（编的时候学生程序会卡），push 后 6 分钟多才上线。host 模式用开发机自己的 ssh 和 git 访问，不需要 secret。Dockerfile 加构建参数 ARTIFACTS（build 默认在镜像里编 / prebuilt 用现成产物），服务器自己编的能力保留；prebuilt/COMMIT 和要部署的提交对不上时 update.sh 直接失败。服务端测试同时跑：文件之间 --parallel，评分测试标 describe.concurrent（--max-concurrency=8），本机 4 分钟降到半分钟，连跑三遍都通过。GitHub 的 ci.yml 改成 PR 跑测试、手动触发才部署（服务器自己编），开发机不在时用，push 不再两边各部署一遍。顺手：update.sh 每次部署拉一下 caddy:2-alpine（up 不会自己拉，一直是第一次部署时那份）；app 和 caddy 的容器日志限 10MB × 3。部署说明、README、设计方案同步

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

server/test/grading.test.ts

@@ -33,7 +33,9 @@ async function prepare(id: string, name: string, edit?: { file: string; from: st
   return dir
 }
 
-describe('参考答案全部通过', async () => {
+// 每个检查大部分时间在等学生程序的定时器，挨个跑要 3 分钟；测试之间各用各的临时目录，可以同时跑（30 秒左右）。
+// 同时跑的个数由 bun test 的 --max-concurrency 管，CI 里给的是 8：太多时 CPU 跟不上，定时器来不及触发会误判
+describe.concurrent('参考答案全部通过', async () => {
   const ids = (await Array.fromAsync(new Bun.Glob('*/checks.yaml').scan({ cwd: SAMPLES }))).map((p) => p.split('/')[0]).sort()
   test('每个示例都有评分规则', () => expect(ids.length).toBe(23))
   for (const id of ids) {
@@ -49,7 +51,7 @@ describe('参考答案全部通过', async () => {
   }
 })
 
-describe('改坏的代码', () => {
+describe.concurrent('改坏的代码', () => {
   test('编译不通过时所有项都不通过', async () => {
     const id = 'p2-t1-LED显示屏'
     const dir = await prepare(id, 'compile-error', { file: 'Form1.cs', from: 'led.setLedText(res);', to: 'led.setLedText(res)' })