Commit Graph

15 Commits

Author SHA1 Message Date
76ac1c7b6b security(config): 四个同族兜底缺陷一次收口 —— APP_KEYS / 弱口令 / IPv6 兜底 / 本地生产密钥同值(R106-D6~D9)
共同根因(R104 结论的延续):**同族问题各自实现必然漂移**。
本仓 DB_PASSWORD 与 JWT_SECRET(R105-D1)已统一为「缺凭据明确失败」,
但同族的另三处仍停在「可预测的公开兜底」上,另新增一处跨环境密钥同值。

D6 · APP_KEYS 派生兜底(原 config.default.js:157)
  原:const DEFAULT_APP_KEYS = appInfo.name + '_competition_website_secret_key_2026';
      config.keys = process.env.APP_KEYS || DEFAULT_APP_KEYS;
  「派生」不等于安全:由 appInfo.name 可推算 ⇒ 等价于「Cookie 签名密钥公开
  ⇒ 任何人可伪造已签名 Cookie」。收口到 _secret.cjs 唯一解析入口:
    · scripts/_secret.cjs 抽出通用 _loadSecret(),新增 loadAppKeys()
      (① env → ② scripts/.creds.local.json:app_keys → ③ 明确失败,⛔ 无兜底)
    · 生产安全守卫移除 config.keys === DEFAULT_APP_KEYS 比对分支(已无可比兜底值)
    · scripts/_creds.py 与 .creds.local.example.json 同步键面(两侧同源,永不漂移)

D7 · 生产弱口令兜底(原 config.default.js:176)
  原:config.testDefaultPassword = process.env.TEST_DEFAULT_PASSWORD || '123456';
  而 deploy/.env.production 的 TEST_DEFAULT_PASSWORD 一直是**注释状态** ⇒ 生产
  实际取到的就是弱口令 '123456'。一旦走到「批量写默认口令」的路径(重置测试数据 /
  显式 testFlag=true 的导入)会批量设弱口令 —— 属**静默弱口令**而非明确失败。
  修法:生产(config.isProduction)未显式注入 ⇒ 置 null;使用点改走新增的
  app/lib/passwordPolicy.requireTestPassword() 明确失败。测试环境语义逐字不变。

D8 · 本地 DB 兜底 host 引发 IPv6 建连超时(原 config.default.js:217)
  原:host: process.env.DB_HOST || 'localhost'。Node >= 18 的 verbatim DNS 可能把
  localhost 解析到 ::1,而本机 MariaDB 只听 IPv4 ⇒ **建连 ETIMEDOUT**(不报 1045、
  不报 ECONNREFUSED),现象是「后端启动卡在 DB」,极易误判为「服务没起来」。
  且本仓 scripts/_db.cjs:43 的兜底早已是 '127.0.0.1' —— 同子系统两套默认值必然漂移。
  修法:兜底改为 IPv4 字面量(生产显式注入 DB_HOST ⇒ 逐字不变)。
  配套(config.local.js 为 gitignored 本地文件,不入库):补 host/port 覆盖 ——
  「第二道保险」原本只保账号/口令,反而漏掉了真正会出问题的连接目标。

D9 · 本地 dev 与生产共用同一 JWT/APP_KEYS(loadDeployEnv)
  非生产跳过清单原本只含 DB_/REDIS_/ALIYUN_/SMS_,注释称「仍保留
  JWT_SECRET / APP_KEYS …… 本地无副作用」—— 该结论不成立:本地进程持有
  **生产签名密钥** ⇒ 本地 token 可冒充生产用户(反之亦然),两套环境的会话边界
  实际被打通,属**安全属性**缺陷。
  修法:新增 DEPLOY_ENV_LOCAL_SKIP_KEYS 精确跳过(⛔ 不用前缀以免误伤),本地改由
  scripts/.creds.local.json 供值;Python 侧 scripts/_fixtures.py resolve_jwt_secret()
  同步为「非生产优先本仓凭据文件」—— 否则脚本会用生产密钥签 token 交给本地后端
  验签,必然 401(正是该函数注释里记录过的 23 项级联假红)。

行为等价性(生产逐字不变,已逐项实测):
  · D6/D8:生产显式注入 APP_KEYS / DB_HOST ⇒ 取值路径不变
  · D7:生产 resetTestData 本有 403 守卫、导入默认 testFlag=false ⇒ 原不可达
  · D9:isProdEnv=true ⇒ 不跳过任何键 ⇒ 生产加载路径不变

验证:
  · 配置层双环境断言:本地 jwt=8066e07d5683 / keys=e4cfe40ff3ea(≠ 生产
    a05591750093 / ae0d155385c1);生产两值逐字不变;生产 testDefaultPassword=null
  · 本地后端真实重启(仅给 DB_PORT=3307、**不给 DB_HOST**)⇒ 启动成功,
    /api/health {"code":0,...,"db":"ok"};日志显示跳过 16 个键(含 JWT_SECRET/APP_KEYS)
  · D9 判决点 d9_verify_split.py:本地密钥签 token ⇒ 200;生产密钥 ⇒ **401**
  · 生产部署后 r106_prod_sentinel.js:pass=11 fail=0;/api/health 200
  · 门禁:verify_no_secrets.py VERIFY_ALL_PASS(HIGH 0,判别力自证 17/17);
    verify_script_health.py H1–H4 PASS
2026-10-12 11:06:01 +08:00
95ad1adca4 fix(deps): xlsx → @e965/xlsx@0.20.3(消除两处已知 high 供应链漏洞)
背景:npm 上的 xlsx 永久冻结在 0.18.5(SheetJS 已停止向 npm 发布),该版本含
CVE-2023-30533(原型污染,0.19.3 修复)与 CVE-2024-22363(ReDoS,0.20.2 修复)两处 high,
而 npm 上**不存在**修复版本——官方修复版只发自家 CDN。

选型判据=CDN 可达性:本机实测 cdn.sheetjs.com 不可达(curl rc=35 schannel 吊销离线;
--ssl-no-revoke 后 rc=28 超时),采用官方 CDN tarball 会把「依赖能否装上」变成部署单点。
故改用 npm 上忠实转发官方 CDN 构建的 @e965/xlsx(0.20.3,含上述两处修复、零依赖、
API 与 xlsx 全等)。未选 exceljs:其 API 完全不同,11 个调用点需全量重写且写入变异步,
风险直接落在承载生产导入路径的代码上。

- package.json:xlsx@^0.18.0 → @e965/xlsx@^0.20.3
- app/service/admin.js(成绩导出 / 客观题模板 / 报名表导入 / 客观题导入)
  app/service/bigQuestion.js(综合大题模板 / 综合大题导入):仅改 require 包名,
  业务逻辑零改动(共 6 条路径 / 11 个调用点)
- package-lock.json:移除 xlsx 及其 7 个传递依赖(cfb/codepage/ssf/wmf/word/adler-32/frac),
  净 −7 包

验证:API 面 + 写读往返 PASS;差分测试 24/24(含畸形尺寸样本与 201 行模板);
真实 HTTP 回归 6 条路径 PASS(写 3/3 均 PK 头、读 3/3 正效应且落库计数吻合);
跨库往返 6/6;npm audit 中 xlsx 命中【无】(backend high 23 → 22)。
2026-10-10 15:15:37 +08:00
29ce734ffa fix(admin): getTeams「已激活」口径修正为「至少一名成员激活」
R90续三:需求方确认该筛选的设计目的是「确认小组是否已有人激活可以参赛」,
故 partial(部分激活)应归入已激活侧查看,旧口径「全员激活」与之不符。

- 行字段 activated:activatedCount === memberCount → activatedCount > 0
- 新增 allActivated 字段保留严格「全员激活」语义(不丢信息)
- summary 新增筛选后三态分布 filteredActivated / filteredPartial / filteredInactive
- 筛选逻辑零改动:语义收敛在行字段 activated 上,筛选仍按该字段判定
- 同步修正方法头 JSDoc 与筛选/summary 段注释

预期副作用:选中「已有成员激活」时 filteredMemberActivated 恒等于全集
memberActivated(inactive 组贡献 0)⇒ 原先「选手列表激活 4 人 / 小组视图 3 人」
的差额(= partial 组内已激活成员)不再出现。

生产已部署并复验:线上 33 项断言 ALL_PASS,activated=true 由 2 组变为 3 组
(2 全员 + 1 部分)、成员激活 3 → 4;服务器侧 MySQL 只读交叉复核一致。
2026-10-09 15:53:20 +08:00
26a29b2214 feat(admin): 选手列表补齐「小组编号/所属学校」,小组视图汇总改双口径
R90 人工测试反馈三问题修复(方案 1 + 方案 3-A):

- getAccounts:新增 teamUid / teamId / teamNumber / schoolName
  · 与 getTeams 同源口径(小组键 = 组别 group + 队伍号 teamUid;
    学校取自 aggregation.organization_cn)
  · 2 条批量 SQL(Aggregation / Team 各一次)替代逐行查询,避免 N+1
  · 既有字段一律不变
- getTeams:summary 新增 memberActivatedInPartial / filteredTotal /
  filteredMemberTotal / filteredMemberActivated
  · 既有 6 个汇总字段语义保持「筛选前全集」不变
  · 同步修正 JSDoc 中陈旧的 allSummary 描述

生产已部署并复验:线上接口 63 项断言全部 PASS,
且与服务器侧 MySQL 只读交叉复核一致。
2026-10-09 15:27:37 +08:00
c101b15e2e feat(admin): 新增小组激活状态清单接口 /api/admin/teams
- router:GET /api/admin/teams(adminAuth;固定路径段,与既有路由无通配冲突)

- controller:teams() 整体透传 group/activated/includeTest(防前端筛选静默失效)

- service:getTeams(),键 = 组别+队伍号;成员并集 aggregation.team_uid ∪ contestants.team_id;学校取 aggregation.organization_cn;激活 = 全组成员均已激活;附 summary 与 schoolConflict

- model/aggregation:补声明运行库既有列 organization_cn / group(此前模型漏声明 ⇒ 查询被当未知列)

线上验证:R86 已部署上线,公网 /api/admin/teams 返回 401(鉴权在位)
2026-10-09 09:33:05 +08:00
481de69e3d fix(agg-key): 归集键串行修复 —— 考试/作品提交记录不得跨选手串行展示
现象(人工测试反馈,已取证):
  测试账号 吴巍荪(cid=621, test_flag=1) 完成一次高职考试提交后,
  正常生产账号 王乐乐(cid=600, test_flag=0) 在管理端评分列表出现**完全相同**的
  作答数据(70 题 / 38 分),而王乐乐本人从未作答。

根因:
  各提交表的 aggregation_uid 写入键不统一 ——
    - 中职/高职:controller/exam.js 写 aggregation_uid = contestant.id
    - 本科/教师:*_submissions 写 aggregation.aggregation_uid(真实聚合 uid)
  历史实现为兼容「两种写法并存」,对两侧都做**无条件双键归集**
  (同时用 contestant.id 与真实 aggregation_uid 去匹配提交表)。
  而这两套编号来自**彼此独立的自增序列**、数值区间完全重叠 ⇒
  「某人的真实聚合 uid == 同组另一人的 contestant.id」时,
  前者会把后者的作答/作品记录「借」过来展示。
  生产实测共 283 对碰撞(gaozhi 239 / benke 43 / jiaoshi 1)。

治法:新增唯一真相源 app/lib/aggregationKey.js
  - 主键按组语义确定:考试组 = contestant.id;作品组 = 真实 aggregation_uid
  - 兜底键沿用历史混杂写法,但**仅在与同组任何主键不冲突时**才启用
    (未通过者丢弃 —— 只丢掉「本就会命中他人数据」的兜底,保留其余兼容性)
  - 不设「兜底键被多人共用」分支:两套编号各自都是 PRIMARY KEY
    (aggregation_uid / contestants.id),该情形结构上不可能发生,属死判据
  - 6 处归集点全部改走该模块:
      service/admin.js  getExamSubmissions / getScores(考试分支) / getScores(作品分支)
                        getContestantScore / _reviewWorks
      controller/score.js  _resolveTeamScoreSource(考生端,与 getContestantScore 同函数)

生产实测影响面(用**线上实际部署的模块** + 生产真实数据核算,n=600):
  旧规则碰撞对 283 → 新规则残留碰撞 **0**;兜底保留 317 / 丢弃 283
  守恒校验:保留 317 + 丢弃 283 = 600;丢弃数 == 旧规则碰撞对 ⇒ YES
  观测值会变化的考生 = **仅 1 人**(gaozhi cid=600 王乐乐 旧=70 → 新=0,即本病例)
  吴巍荪 cid=621 归集键 ["621","642"] 行数 70 保持 **未被误伤**

验证:scripts/verify_agg_key_crosstalk.py 17/17 PASS(真实 HTTP + 库内真值)
  夹具刻意构造「真实聚合 uid == 同组他人 contestant.id」并含**正向对照**(兜底保留者)
  变异自证 A(拆掉碰撞闸门)→ H1/H4/H5/H6/B1/B4 共 6 项变红,失败信息精确复现原现象
  变异自证 B(兜底键整体删除=过度修复)→ H3/H4/H5/H8 共 4 项变红
  ⇒ 两条职责各有独立判别器;还原后 diff 空、md5 一致、零标记残留

部署(生产 back-end):线上 3 文件 md5 与本地逐文件一致;
  MainPID 3343212 → 3344477;8023 监听正常;journalctl -p err = -- No entries --;
  路由探针 health 200 / 错口令 HTTP200+code4004 / 不存在路由 404 / 未授权 401
2026-10-08 12:23:18 +08:00
a471487092 fix(admin): 修复选手管理「激活状态」「注册日期」筛选被静默丢弃
现象(人工测试反馈):选手管理页「激活状态」下拉选择后列表无变化。

根因 —— 两层都在丢参且零报错:
  - controller/admin.js 只解构 group/keyword/page/pageSize,
    前端已发出的 activated 从未透传给 service
  - service/admin.js 即使收到也未解构 activated,where 中根本没有该条件
  - 同族缺陷:前端还发了 startDate/endDate(注册日期范围),
    controller 同样未转发 => 该筛选同样失效(此前无人报告)

修复:
  - controller:将 activated/startDate/endDate 整体透传给 service
  - service:解构 activated,并对 BOOLEAN 列做白名单归一化
    前端 el-select 传的是字符串 'true'/'false',直接入 where 会被
    MySQL 隐式转为 0,导致「已激活」错查出「未激活」(比不筛选更难察觉);
    白名单之外的值(含 undefined/'')一律视为未指定忽略,
    避免畸形入参被当作 false 而静默缩窄结果集

验证(scripts/verify_accounts_filter.py,9/9 PASS,真实 HTTP + 独立 DB 真值):
  A1 无筛选 total=26 == DB 26
  A2 activated=true  -> 10 == DB 已激活数
  A3 activated=false -> 16
  A4 分区性 10 + 16 == 26(关键判别器)
  D1 日期限定 DB 实际存在那天 -> 20 == DB 当日
  D2 负向对照(范围早于最早记录)-> 0
  变异自证:拆掉 where.activated 分支重跑 -> A2/A2b/A3/A3b/A4 全红 EXIT=1,
  失败信息精确复现原现象(total=26 != 10);还原后 diff 空、md5 一致、无标记残留
  同族扫描:全后端 ctx.query 仅 11 处,逐点核对 => 仅 getAccounts 一对丢参

部署(生产 back-end):
  线上 md5 与本地逐文件一致(controller ad0e60f8 / service 93eb3dbb)
  MainPID 3341710 -> 3343212;8023 监听正常;err 级日志 -- No entries --
  路由探针:health 200 / admin-login 错误口令 HTTP200+code4004 / 不存在路由 404 /
            未授权 accounts 401
2026-10-08 11:22:18 +08:00
154338e5dd feat(big-question): 综合大题 Excel 模板下载 + 批量导入(R73)
新增 GET /api/admin/big-questions/:group/template —— 生成自解释模板:
数据 sheet 排第 1(导入侧按 SheetNames[0] 解析,是承重契约)+「填写说明」sheet,
含列名含义/状态建议/常见被拒原因,让测试人员下载即会用,不依赖外部文档。

新增 POST /api/admin/big-questions/:group/import-excel —— 逐行调用
service.bigQuestion.createQuestion,标题长度/三小问/分值/泄题检测(detectAnswerLeak)
全部自动继承,与手工录入同一入口同一校验;批量导入绝不成为绕过防呆的后门。
组别以 URL :group 为准,忽略表格里的组别列;同组内标题重复即跳过并报错;
状态缺省 0(停用),批量录入的题未经人工校对不直接进抽题池。

客观题模板 buildQuestionTemplate 同步加「填写说明」sheet:数据 sheet 仍排第 1、
原 8 列不变,故 importQuestionsFromExcel 的 SheetNames[0] 解析不受影响(已离线验证)。
路由顺序硬约束:含具体段的 template / import-excel 必须排在通配段 /:id 之前。
2026-10-08 10:08:41 +08:00
0531131f0e feat(admin): 报名表导入补列名别名 + 只导参赛选手 + 判重口径(R32)
- COLUMN_ALIAS/pick():兼容上游列名(身份证号码/全名/队伍ID),上游导出表免改表头
- 只导身份=参赛选手:其余计入 result.ignored/ignoredBy(≠skipped),建团队同步过滤
- 判重改以身份证号为准(同证即同人);错误消息附「队伍/姓名/手机号」便于同名定位
- 修 teamUidCache 复用库内团队时写入 maxTeamUid 而非真实 uid 的 bug
- phone 空值写 ''(列 NOT NULL)
- 实测:1225 行 -> 成功 591 / 跳过 3(身份证非18位)/ 忽略 631 / 建队 297
2026-09-29 09:40:51 +08:00
e74778ee08 feat(admin): 成绩导出改为 Excel + 板块迁移配套接口(R29)
- service/admin.js: 抽出 buildScoreExportTable(group) 作单一数据源(CSV/XLSX 共用,消除表头漂移)
  + 新增 exportToXlsx()(SheetJS aoa_to_sheet + write buffer + !cols 列宽)
- controller/admin.js: 新增 exportExcel()(xlsx MIME + ctx.attachment 中文文件名编码)
- router.js: 新增 GET /api/admin/export-excel/:group(adminAuth)
- export-csv 路由刻意保留:verify_full_e2e.py B10/D10、verify_upload_download.py B2 依赖其非空断言
2026-09-28 16:42:36 +08:00
2ab0991310 fix(admin): 复核页选择题选项渲染修复 + 阅卷导出 Word + 评分两位小数(R28)
针对测试人员反馈的四项:
1) 复核明细「选择题大量空白」:options 为 text 列存 JSON 字符串,原先被原样透传,
   前端 v-for 对字符串逐字符迭代(op.key/op.text 皆 undefined)⇒ 每字符渲染一行。
   新增 parseOptions()(仅 string 才 JSON.parse,失败降级 null)。
2) 选项与答案不随机:仅题目用 RAND() 抽题,normalizeQuestion 无 shuffle,字母无歧义。
3) 评分精度:DECIMAL(6,1) -> DECIMAL(6,2),migration 026 覆盖 17 列(与 025 同范围),
   lib/decimal_score.js 与 11 个 model 注释同步;汇总收敛 round2(×100/100)。
4) 阅卷导出:GET /api/admin/big-answers/:group/export?ids=
   单选考生 -> 直接 .docx;多位/全部 -> 每位考生单独 .docx 打包 .zip。
   路由为 3 段,注册在 :group 通配段之前。

验证:verify_big_question 51 PASS/1 FAIL(唯一 FAIL=测试人员新数据,非本次改动)、
verify_score_leak_all_channels 24/24、verify_question_no_answer_leak 4/3/0/1。
2026-09-28 15:50:46 +08:00
cbc05ed4e7 feat(admin): 成绩复核——按姓名/身份证/电话检索考生并查看全卷客观题逐题作答与正确答案(R26)
- service.admin: 新增 reviewSearch / getContestantScore / _reviewWorks;移除同名的死代码旧实现
- 归集双键合并 [contestant.id] ∪ [真实 aggregation_uid],与 getExamSubmissions 口径逐字一致
- 题序还原:优先 exam_submissions.question_order,缺失则回退「选择→判断 + 题号升序」并回传 questionOrderFixed=false
- 未作答行 answerMatches 返回 null(非 false),避免界面把「未答」读成「答错」
- 组别以库中考生 group 为准,路由 :group 不符返回 409,防前端传错组照错人
- 异常可区分:questionMissing(题被删/改组)、answerMatches≠isCorrect(判分矛盾)
- 因回传正确答案,两条路由均挂 adminAuth —— 选手端可达即成绩泄露(与 verify_score_leak_all_channels.py 三通道门禁一致)
- 不改动 schema、不改动既有接口行为

controller.admin: 新增 reviewSearch / contestantScore(NOT_FOUND→404 / GROUP_MISMATCH→409 / 其它→400)
router.js: 注册 GET /api/admin/review/search 与 /api/admin/review/score/:group/:id,均 adminAuth
2026-09-28 10:15:42 +08:00
079c1b31c9 R20:客观题分值口径 + 大题一位小数评分 + 页面刷新修复 + 大题导出 Word
A1/A2 客观题:
- 清理题库占位题(答案恒 A/true、分值恒 5),客观题分值硬约束为 1 分
- 新增 scripts/check_question_bank_health.py(带变异注入自检,已验证判别力)
- ci-gates.sh 由 9 步扩为 10 步,纳入题库健康门禁

B 大题评分一位小数:
- 新增 app/lib/decimal_score.js:DECIMAL(6,1) + getter 兜底,单点收口
  「DB 列 / model 声明 / dialectOptions.decimalNumbers」三处必须同时成立
- 10 个 model 的 score 字段改走该工厂
- database/migrations/025:17 列 INT → DECIMAL(6,1)(6 列题目分值保持 int)
- service/bigQuestion.js:setSubScores 用 Math.round(n*10)/10 收敛,不再抹成整数

C 页面状态刷新:
- 修复 onQuestionTypeChange 的 `bigQuestions.length === 0` 守卫(切组后旧数组仍非空
  ⇒ 永不重新拉取)
- 修复评分后只刷一半(saveBigScores / saveExamScore 各只刷一侧列表)
- 收敛为唯一刷新入口 refreshQuestionData();ensureBigData 改按「数据属于哪个组」
  判定;fetchBigQuestions/fetchBigAnswers 增加组别竞态守卫

D 大题导出 Word(单题 / 批量 / 全部):
- 新增 app/lib/docx.js:零新依赖手写 OOXML(复用已有 archiver@8),支持 p/strong/
  span/a/br/table/ul-ol 子集,具名捕获组词法解析,pPr 严格排在 runs 之前
- service.bigQuestion.exportQuestions + controller.exportBigQuestions +
  GET /api/admin/big-questions/:group/export
- 前端导出选中/全部两按钮 + 表格多选(reserve-selection)

计划外发现并修复(已在报告中披露):
- 管理端跨组写分越权:setSubScores 定位作答行时缺 group 约束,可用任意组的路径
  改写他组考生成绩(读写不对称:读取侧有 where:{group},写入侧没有)
  ⇒ 已补 group 约束,并区分「不属于本组」与「尚未抽题」两种文案
- 导出路由注册顺序:export 原注册在 :group/:id 之后(当时因后者仅 PUT/DELETE 而
  未暴露问题),已前移以消除「将来新增 GET /:group/:id 会吞掉 export」的隐患

验证(全部实测,非仅看退出码):
- ci-gates.sh 10/10 全绿;四连门禁 52/0 · 22/0 · 20/0 · 46/0
- 端到端探针 probe_d_03(导出+小数)ALL PASS;probe_e_01(切组刷新)22/22 ALL PASS
- 前端构建 VITE_EXIT=0

未 push:须先上线验证通过再单独授权。
2026-09-23 18:29:50 +08:00
e7af00beb9 fix(admin): CSV 表头「Word分」改为「大题分」+ 移除 getExamSubmissions 重复 examScore 键
改动(3 处):
  ① getExamSubmissions CSV 表头(L631):
       「...,客观题分,Word分,总分」→「...,客观题分,大题分,总分」
  ② 移除 getExamSubmissions 返回对象中重复定义的 examScore 键(原 L445):
       该键与 L456 的 `examScore: autoScore` 重名,对象字面量重复键「后者静默胜出」,
       L445 实为死代码。当前因 updateScores 会同步写 contestants.exam_score
       而「结果碰巧一致」,属隐患,故删除并加注释说明。
  ③ 同步两处注释口径:Word 阅卷分 → 综合大题阅卷分(getScores isExam 分支)。

不改动(保持契约):updateScores 入参名 wordScore、路由
  /api/admin/submissions/:group/:id/word、contestants.word_score 列名。
  (列名为历史沿用,语义已是「综合大题得分」,仅文案口径调整。)

影响面:仅中职/高职(isExam)分支;本科/教师组 CSV 与成绩口径不变。

验证:CSV 表头端到端实测 = 选手ID,身份证号,姓名,手机号,是否提交,客观题分,大题分,总分;
     verify_scoring_e2e.py 17/0;verify_big_question.py --cleanup 52/0;零回归。
2026-09-22 13:05:35 +08:00
WorkBuddy
a303cf2d53 chore: 后端首次基线提交
运行必须源码:app/(controller/model/service/middleware/lib/utils/validate/router)、config/、database/(migrations/seeders/sql)、启动脚本、app/public/templates 模板。
已忽略运行非必须:node_modules/、logs/、run/、app/public 运行时上传数据、.env*、构建/缓存产物。
2026-08-17 12:25:42 +08:00