 ThearchyHelios
|
62089f2849
|
复核「另外两处」：评测每题的时限、算期望的时限都不算排队等运行名额的那一段（within 代替 asyncio.wait_for，作答那次运行在 slots 里还排着队时不走表；算期望的运行排着队时把截止时刻往后挪），满载时不再被记成超时、触发止损；同源队（SourceLanes）跟发名额一样，拿这个源的咨询锁之前备好「哪些别的属主确实不在了」，持锁期间只用持锁的那条连接，拿锁之后才出现的属主这一次当活着。slots 加 waiting(run_id, here=)：本进程里的直接看、不查库。补测试：排队 0.8 秒、时限 0.3 秒照样答完不记超时（改前的写法这条不过）；within 暂停的那几段不算、不暂停照样超时；同源队持锁期间不查「谁还活着」、没了的进程照样让位、拿锁之后才出现的属主不删
|
2026-10-19 13:31:46 +08:00 |
|
|
ThearchyHelios
|
0d9f1d9339
|
用户看得到的列表补决胜键（复核 R-a9）：按名称、时间等可能并列的排序后面补上同一个模型的 id，并列时两种库排出来一样
- 实测 /api/evals/calibers、/api/schedules/trigger-options 按 Workflow.name 排序遇同名并列时 SQLite、PostgreSQL 顺序不同。用 AST 逐个过了一遍 order_by：最后一个排序键是 created_at / updated_at / last_active_at / at / name / 各种 *_at 之类、不唯一的列，又不带 DISTINCT、GROUP BY 的，补「, 模型.id」（降序补 id.desc()），共 104 处，分布在 api、apps、auth、blueprints、chat、data、engine、eval、ledger、look、memory、process、providers、scheduler（runs.py 里的三处在上一个提交里）
- 按唯一列（seq、version、唯一的 name）排的不动；按聚合、coalesce 之类表达式排的说明见 db/postgres
|
2026-10-19 12:07:06 +08:00 |
|
|
ThearchyHelios
|
9cd45ca047
|
评测题目返回给界面的说明改成合规文案：check-copy 三项规则恢复全过
check-copy 也扫后端交给界面的报错文案，nr2/c 交付时没跑这一道，有三项没过（复核 C-1）：
- 口语补语：期望 SQL 行数不够时写的「取不到值」「取不到第 N 行」，改成「没有可用的值」「没有第 N 行」；
同一处 where 匹配到多行的「取不准是哪一行」一并改成「无法确定是哪一行」。
- 禁用词「钉住」「改钉」：升版处置的叫法（UPGRADE_LABEL）和 DisposeRefused、升版状态的说明，按全站
「固定版本」的说法改成「固定的…」「改为固定新版本」，和应用、子工作流的升版说明一致。
- 半角标点和英文引号：题目 where 写错时的报错例子原来是一段 JSON，改成全角的「地区：华南」，并写明取值只能是
文字或数字（校验本来就只收这两种）。
只改文案，判断和机读码都不变。代码注释和模块说明里的「钉」不上界面，照全仓库的写法保留。
|
2026-10-16 15:23:44 +08:00 |
|
|
ThearchyHelios
|
7f14313416
|
评测题目的几处收紧：口径题只能固定已发布未退役的版本、处置升版后按新版本再核一遍、试算前结束读事务、影子起草分开记只写出一部分的表
- cases.resolve_case：口径题钉的版本没发布过或已退役的，保存时照实拒收（422，field=gold.version）；以前要等试算跑到
升版判断才说得出。
- 处置升版（recompute / incomparable）改钉新版本之前，按新版本再过一遍 resolve_case（入口字段、指标），说得清是哪一项不行。
- 接口里的试算要等一次运行跑完（最多两分钟）：先结束这个请求的读事务再等，不一直开着它（导入时同样）。
- 影子起草：只写出一部分的表另记（tables_partial），快照照出、状态 partial；一张都没起草出来才算失败、不出快照。以前
只写出一部分的表算成没起草出来，几张表都只写出一部分时整次记失败、写好的部分也丢了。
- 题集里推起草哪些表时，期望 SQL 按题集的时区渲染。
|
2026-10-16 14:05:22 +08:00 |
|
|
ThearchyHelios
|
2b9dcc55e3
|
评测题集与期望答案（第 2 波 W2-c）第一步：模型、派生图、期望的三种来源、目录快照与影子起草
- db/models_eval.py：EvalSuite、EvalCase、EvalRun、EvalResult 一次定全（第 3 波的执行、评分直接用），另加
EvalCatalogSnapshot 登记目录快照（谁、何时、来源、影子起草的进度和用量）。EvalResult.job_id 是 eval_run_id 的
别名：后台任务运行时的收尾按 task_model.job_id 认逐项。预算缺省按评测-D9（同时 2 题、每题 900 秒、单次 2 美元、
每日 5 美元），这一波只定字段。
- app/ledger/derive.py：全站唯一的「从钉住版本派生只读图」的生成器（总方案 X3）。这一波实现口径探针：拷出口径卡读
的取数节点（id、配置、图级 defaults 原样）+ caliber_from 固定到那一版的口径卡；只认可复用的源头卡，取数节点只许
引用入口字段，别的照实拒收。对账（这次的取数 + 口径 + 对账卡）、召回（新旧两版带前缀、caliber_from.nodes 改名
映射）的扩展点写在模块说明里，assemble / caliber_block 直接可用。
- app/eval/cases.py、suites.py：题目和题集的形状与校验。数值期望不许人填（评测-D4，写了 value 一类的键一律拒收），
文字要点单列、不计入准确率；只做单轮（评测-D12，history 必须为空）；变量只认定时任务那份 {{ schedule.* }}；
题目指纹去掉确认人、出处运行、升版处置这些记录项。
- app/eval/gold.py：SQL 题、口径题、从运行认定三种期望。每次都以来源 eval、只读 + 遮罩的探索运行重算，期望值取封存的
查询快照（或口径卡的指标集）；只读守卫拒写语句、用到遮罩列的拒收（认法同证据面板的派生遮罩）、取不到值 / 失败 /
超时 / 停在人工确认上各写各的原因。口径升版用和正式运行同一个 unresolved_caliber_upgrades 判、退役按
subgraph_pin_problems 判，待处置就跳过；recompute / dual / incomparable 三选一、没有缺省。作答前后各算一次
（bracket / settle）给第 3 波的执行调。
- app/eval/snapshots.py：目录快照存成 kind=eval_catalog_snapshot 的内容寻址工件（读法即 data/catalog_view.py 定的
那一种）；影子起草是不占数据源队的后台任务，起草写进内存里的目录副本，不调 write_entry、不碰线上目录、不查业务库，
只起草题集用得到的表，开始前估算花费；停止、出错的不出快照。
- data/catalog_draft.py 只加入口 run_shadow_draft（同一个起草引擎，唯一不同是不去业务库数有效行过滤的排除比例）；
data/catalog.py 把写库前的并入抽成纯函数 merge_draft、建起草模型抽成 build_draft_model（行为不变，影子起草和写库
用同一套并入规矩、同一个模型建法）。
|
2026-10-16 13:49:53 +08:00 |
|