AgentLab

复核 R-d2（起不来的库容器回退后还在一遍遍重启）：stop_pg 对在跑的和在重启的（restarting）都停；migrate-to-postgres 回退时先 docker update --restart=no 再停，再起库时（start_pg）恢复 --restart unless-stopped；./deploy.sh stop 用同一个函数一起好。假 docker 单测：镜像起不来、容器一直 restarting 时回退后停在 exited、重启策略是 no，换回能起的镜像重跑照常，stop 也停得下在重启的

2026-10-16 12:46:48 +08:00

conftest.py

2026-10-21 16:03:10 +08:00

eval_samples.py

评测执行的主干：后台评测、无头作答、评分、统计、对比与 A/B、清理（下一轮第 3 波 W3-c 第一段）

2026-10-16 16:38:09 +08:00

fake_docker.py

2026-10-19 16:09:19 +08:00

jsonguard.py

两种库行为再对齐一轮（复核 NUL、R-a4、R-a6、R-a7、R-a10）

2026-10-19 12:06:31 +08:00

ledger_samples.py

口径账本：合并查询的格照实写为什么没比对；账本测试按用例各用一个数据源隔开

2026-10-16 14:23:41 +08:00

pgpool.py

应用库可移植到 PostgreSQL：AGENTLAB_DATABASE_URL 设成 postgresql+asyncpg://… 时整个应用库用 PostgreSQL，断点用官方的 langgraph-checkpoint-postgres（同一个库，AGENTLAB_CHECKPOINT_URL 可另给）；不设时照旧是数据目录里的 SQLite，行为不变

2026-10-19 09:52:09 +08:00

test_acceptance_retail_fixture.py

…

test_access_key_gate.py

访问密钥与服务账号的后端（下一轮第 2 波 W2-d，细案 04 A1–A6、总方案 X8）

2026-10-16 13:48:09 +08:00

test_access_key_use.py

访问密钥收尾：服务账号进授权不进岗位的测试、关停时写请求记录的测试，几处整理

2026-10-16 14:15:51 +08:00

test_access_keys.py

访问密钥收尾：服务账号进授权不进岗位的测试、关停时写请求记录的测试，几处整理

2026-10-16 14:15:51 +08:00

test_action_assertion.py

应用平台集成（后端应用与流程）：身份断言 sub 为发起人、确认人进 act；应用助手对话（取或建、带历史）与助手润色只能改呈现；按新口径补算（只对无副作用的视图、加锁、同一输入只补一次）；钩子按名字关联、入站按发布版声明认；应用详情只对 manage 给草稿与岗位绑定；删工作流的阻挡算上已退役版本；待办恢复失败退回待处理；调用工具节点作证核对快照归属；子图固定版本须已发布且未退役（发起与发布检查都查）；视图里端点快照按能力的遮罩字段遮（含统一复核后的修复）

2026-10-14 21:55:51 +08:00

test_agent_cited_fields.py

…

test_agent_guards.py

…

test_agent_steps.py

…

test_aiosqlite_close.py

…

test_analysis_bundle.py

可验证报告的核对页给分析结论的方法写上中文叫法：服务端在随文件附带的分析结论条目上带 method_label（contract.method_label，和导出页同一份），verifier.js 的数字详情、指标上的可比性两处「方法与版本」照导出页写「变化拆解（可加） · decompose.additive@1」，页面只显示、不另起叫法；条目上没带叫法的只写 id。以前只显示方法 id。测试：分析结论、口径卡指标上的可比性两种条目都带叫法

2026-10-21 15:49:06 +08:00

test_analysis_card_data.py

分析卡运行时对合并后的阈值再核一遍（复核 R28）：画图时阈值覆盖只能对着缺省值校验（schema 不改），发起时的设置快照合进来以后可能冲突——管理员把「超出常规波动」调到 3、卡上把「明显超出」覆盖成 2.5，就永远判不出超出。卡上写了覆盖时，运行时对缺省 ← 快照 ← 覆盖合并后的阈值跑一次 contract.settings_problem，有问题让卡失败并说清「阈值覆盖和这次运行的分析设置冲突：…。请改分析卡上的阈值覆盖」（配置错误，不是数据问题，一项都不算）

2026-10-21 16:11:00 +08:00

test_analysis_card.py

分析入口的测试补真算子：test_analysis_e2e 加 agent 调波动基线（本周明显超出常规波动、历史新低，本期完不完整按现查的表范围判）、趋势、差异检验（逐行明细，华东的单笔金额高于华南）、可比性检查（两份查询各一周）各一次的端到端，台账、交回模型的那一段、复算逐字段相同都核；分析卡以合并查询为输入跑一次（输入写明 sqlite 方言、工件就是合并查询的快照）。test_analysis_card 的下钻样例 DRILL 原来 by 和 period 是同一列、真算子下会报错：shop 加渠道列（各地区两周的合计不变），DRILL 改成读华东按渠道的那次查询（drill_graph），另用真算子跑一遍下钻（闭合、主要来自线上、parent 是上一项的结论工件、复算一致）；夹具改用 scratch_source。过时的说明照实改：替身的用途、口径卡可比性挂钩里「还没有算子」的说法

2026-10-21 16:06:40 +08:00

test_analysis_claims_lexicon.py

说法表的 scan 加 bare=True：只按词认、不看上下文（构成、建议计划、业务状态、「相当」的比法、「未见异常」的主语这些只对整句话成立的规矩都不用），给认叫法（度量的叫法、因子名）里夹带的判断词用——叫法是一个名字不是一句话，「主要来自华东的销售额」照样认出来源；缺省照旧按整句的规矩。原因只是指代的那条注释改准。测试：几个叫法按词认、按整句不认

2026-10-21 17:10:43 +08:00

test_analysis_claims_operators.py

说法核对接上证据接入（W1-b）和真算子（W1-a）：一句的分析依据按引用的编号认（A 开头、目录条目 kind analysis），判定语 [[a:A1]]、具名标量 [[a:A1.键]] 整段不扫，[[see:A1]]、[[see:A1.r0]]、[[see:a:A1]] 都当依据；目录条目只带摘要的（存进文档的那份）复核时按工件取回整份结论（_Snapshots.analysis）。算子、模式的叫法从契约取（OP_LABELS、method_label）。比率拆解的结构为主、各段自身为主（判定语就说「主要来自…」）也能挂来源类判断；ASCII 的段名认整词时，挨着的汉字不算连着。去掉测试里代为解析 [[see:A…]] 的替身；新增挂真算子结论的绑定测试：可加拆解的主要来源与拖累带动、分散、持平带抵消、比率拆解的结构变化、乘积拆解的因子、波动基线的方向和新高新低与正常波动、趋势的方向和连续期数、差异检验两组的先后、算不了的基线，以及经组装和复核时判定语、具名标量不扫

2026-10-21 13:29:23 +08:00

test_analysis_claims.py

「连续」按趋势结论记的末尾连续同向核（values 的 run_direction、run_length），不再先要整体判定是上升或下降：算子修复后趋势判定语在方向相反时写「，但最近已连续 N 期上升」，句子照它写「最近已连续 4 周上升」要对得上，整体没有明显趋势、末尾连续下降的也能说连续。句子写了期数的（「连续 5 周上升」「三连降」「十二连涨」，阿拉伯数字、全角数字、一到九十九的中文数字）要 run_length 不少于它，没写的至少 3 期；方向对不上照旧报相反；没记 run_direction 的老结论按整体的趋势方向。测试：期数不够、整体下降而末尾连续上升、没有明显趋势而末尾连续下降、老结论，和各种写法认出的期数

2026-10-21 15:56:49 +08:00

test_analysis_comparable.py

同口径先去掉最外层排序、按去掉日期的写法比（复核 R7）：same_query 不再只在规范形式完全相同时才把日期换成占位——两边都去掉最外层的 ORDER BY（同一层有 LIMIT / OFFSET 时不去：排序决定取哪几行），时间条件的界（字面量、按运行当天现算的都算）和像日期的字面量换成同一个占位后规范化再比：一样就通过，只差字面量判「两边除了日期，筛选的还不一样」，还不一样才交给 explain_sql_diff；交给它的也去掉最外层排序、现算的界换成按先后编号的日期字面量（它只认字面量的时间范围），只差时间范围、排序的照旧算同口径。只有一边带 ORDER BY、上周对本周到今天这类现算界写法不同的不再落进兜底判成结构不同，两份快照的变化拆解也不再因此不拆

2026-10-21 15:51:30 +08:00

test_analysis_compare.py

运行对比里的分析卡只认做完了的那次执行：analysis.end 先按卡记在这一次执行里，见到这张卡的 node.finished 才算数（新的 node.started 清掉上一次没做完的）。分析卡执行到一半失败时前几项已经发了 analysis.end，以前运行对比会把这次失败执行的判定当成结果列出来、也算进执行次数。测试：中途失败的那次不列、不算次数，失败后重来做完的按做完的那次对比

2026-10-21 15:50:15 +08:00

test_analysis_contract.py

分析设置要求「集中」的合计占比不小于「主要来源」的占比（复核 R16）：contract.settings_problem 加一条（没写的项按缺省补齐了比），说法用 LABELS 的叫法：「「集中」的合计占比不能小于「主要来源」的占比」——原来「主要来源」0.9 配「集中」0.5 能通过，一段占 60% 时判分散、判定语却说「没有哪一段占到 90%」。设置页写进来的、分析卡上的覆盖都按它挡；api/settings.analysis_values 读存着的一组时这一对对不上同样两项都按缺省（同另外两对）

2026-10-21 16:00:29 +08:00

test_analysis_decompose.py

一份快照按期次分组的变化拆解也核本期齐不齐（复核 R20）：可加、比率、乘积三种模式用波动基线同一套完整性检查（comparable.period_complete：不到整周、没过完、数据没到、SQL 截掉一部分），本期不齐算不了（partial_target，「本期数据只到 2026-10-20，还差 5 天，和完整的周比没有意义」），核对不了（查不到表的范围、周号认不出算法、期次不是日期）附一句说明，只在证据面板、不进判定语（两份快照时可比性结论照旧进判定语）；结论的 params 记下运行当天。期次按 periods.parse_compared 认：周号按 SQL 认算法；快照里往往只有比的两期，值都是日期、推断成按周、期次列又是直接取的日期列（原样、date(列)、DATE(列)、CAST 成日期）时按天认——昨天对上周同一天正好隔 7 天，光看值分不出是两天还是两周。可比性检查按期次分组、没给粒度时同样按它认。证据接口的一条测试（tests/test_analysis_evidence_api.py）跟着补上这一句说明的种类

2026-10-21 16:09:21 +08:00

test_analysis_differ.py

差异检验拿不到 p 值照实说、敏感性只在真实的各组里找离群值（复核 R8、R9）：一对都拿不到 p 值（比率有一组样本量为 0；均值、逐行有一组不到 2 个样本，或均值、标准差为空）时算不了，契约 REASONS 加 untestable，原因写哪一组怎么了（「华东只有 1 个样本、华南只有 1 个样本，算不了差异」），不再判 ok + 可能只是样本波动；只有一部分拿不到的，那几对不算进比了几对、不参与校正，表里写清哪一组怎么了，判定语后接「另有 n 对算不了（…）」（契约 CAVEATS 加 untested，排在判定语附带说明的前面）。逐行模式比三组以上时，离均值最远的那一笔只在真实的各组里找（原来池子里混着各对的「其余各组合计」，第一组以外的离群值删不到它自己那一组，漏报 outlier_sensitive），去掉以后由各组重建每一对的「其余」合计再检验

2026-10-21 15:56:16 +08:00

test_analysis_e2e_claims.py

2026-10-21 16:03:10 +08:00

test_analysis_e2e_evidence.py

转正 W1-b 的端到端测试（tests/test_analysis_e2e_evidence.py）：分析卡、agent 分析工具、口径卡指标上的两期可比性各发起一次真运行，片段接口的出处链、证据图、审计、报告导出、可验证报告都按封存的输入真复算、逐字段相同；打印改成断言

2026-10-21 14:08:56 +08:00

test_analysis_e2e.py

分析入口的测试补真算子：test_analysis_e2e 加 agent 调波动基线（本周明显超出常规波动、历史新低，本期完不完整按现查的表范围判）、趋势、差异检验（逐行明细，华东的单笔金额高于华南）、可比性检查（两份查询各一周）各一次的端到端，台账、交回模型的那一段、复算逐字段相同都核；分析卡以合并查询为输入跑一次（输入写明 sqlite 方言、工件就是合并查询的快照）。test_analysis_card 的下钻样例 DRILL 原来 by 和 period 是同一列、真算子下会报错：shop 加渠道列（各地区两周的合计不变），DRILL 改成读华东按渠道的那次查询（drill_graph），另用真算子跑一遍下钻（闭合、主要来自线上、parent 是上一项的结论工件、复算一致）；夹具改用 scratch_source。过时的说明照实改：替身的用途、口径卡可比性挂钩里「还没有算子」的说法

2026-10-21 16:06:40 +08:00

test_analysis_evidence_api.py

合入复核修复（证据接入与入口）：跨段指标不当两期查、证据接口重渲染与组装同一个函数、一次请求同一份结论只复算一次、比率闭合核对、代入式按点名的段、写作目录分析段限额、核对页写方法叫法、运行对比只认做完的执行、读快照进线程、四个工具与合并查询的真算子测试、夹具清源

2026-10-21 16:58:45 +08:00

test_analysis_evidence.py

写作目录省略说明里分析结论那几句改成给模型看的常量（ANALYSIS_TABLES_OMITTED_PROMPT、ANALYSIS_TRIMMED_PROMPT、ANALYSIS_LEVEL_PROMPT_WORDS），和别的写作规则同一个认法，界面文案检查不再把它们当界面上的字；「没列出的照样能引用」改成「没列出的也能引用」

2026-10-21 16:10:01 +08:00

test_analysis_intent.py

问题意图：「变化大不大」「变化大吗」归到波动一类（问的是这次变化大不大，不是变化从哪来），自查那条问题照「问题问的是波动大不大」说；来源一类只留「怎么变了 / 有什么变化 / 变化在哪」。测试加一个正例

2026-10-21 18:27:05 +08:00

test_analysis_judge_ledger.py

证据接入按 W1-a、W1-c 的实际接口对齐：复算就是真的 app.analysis.recompute——load 交查询快照工件的原内容、load_result 交上一层结论（只认封存范围内交回过的查询、台账记过的结论，取不回照实说取不回哪一份），方法升没升版按结论里的 method 和现在的 contract.METHODS 比（升了版、复算成立的写结果同不同，现在的方法复算不了的写明原因），去掉为算子没落地准备的那一套；关键数的代入式按真的具名的数写（乘积拆解补上，波动基线按变化率比的按百分比写，负数加括号）。口径卡指标上的可比性结论（不进台账、只从卡上引用）点得开：证据面板的指标步骤带它整条出处链（判定 → 方法 → 计算 → 输入 → 复算 → 封存，封存按卡上记的 sha256 认），报告导出收在一个可展开的块里，可验证报告随附带的卡一起附上、④ 按已核对的卡认它、数字详情里展示各项检查和服务端复算；裁判的指标摘录、写作目录照卡上记的判定语写。现查结果分清按运行当天现算的界、一列一个值都没有、表的范围；可验证报告里分析工具的 tool.end、分析卡的 analysis.end 和结论同一个认法才带内容，输入的角色写叫法。测试改用真算的结论（run 交的输入照分析入口的写法，复算交工件原内容），下钻、总数闭合、方法升版、可比性端到端都过真的复算

2026-10-21 13:49:09 +08:00

test_analysis_method_guide.py

分析方法定稿（ANALYSIS_METHOD_PROMPT，guide id 升到 analysis.method@2）：在第一版六条上写清按问题选基期（环比比上一个整期、同比比去年同期并写 lag、和目标比要库里有目标，没说就比上一个整期，本期取最近一个过完的整期）；周序列的期次在 SQL 里由日期列算出来，写每周第一天的日期（附 SQLite 写法）或 ISO 周，SQLite 的 %W、MySQL 的 %u 不是 ISO 周，直接取现成的周号文本本期齐不齐核对不了；先可比性与基线、趋势，再拆因子与结构、按维度由粗到细，找到主要来源再下钻一层；每次写明在验证什么，拆了不集中也是结论；不作因果断言；阈值不由模型定、算不了照实说、调用写错照说明改；最后交给写作者的文字里列出做过的分析（An）和判定原话。测试守这几件事都在、点名的工具是那五个、五个工具共用这一份

2026-10-21 18:08:25 +08:00

test_analysis_pages.py

两份页面脚本的测试跟上方法叫法和比率的闭合核对：可验证报告核对页的「方法与版本」写「变化拆解（可加） · decompose.additive@1」「可比性检查 · comparable@1」（服务端带来的叫法加 id）；导出页点开比率拆解的判定语，总数那一格写「整体比率那一格」、闭合核对写「整体比率 x 与各段分子之和 ÷ 分母之和 y 闭合」，不写「各段之和」（比率拆解的那次封存运行抽成 ratio_run，证据接口和页面两处共用）

2026-10-21 16:00:44 +08:00

test_analysis_periods.py

周号超出任何算法（W54 以上）的认不出、算起止超出日期范围的当这一周没有（复核 R3 补）：认不出算法时原来按周号排先后，「2026-W99」也会当一周收下，现在周号大于 53 的不当周号写法，原因里照实举它；按算法算起止时日子超出日期能表示的范围（公元 9999 年末）交回没有这一周，不抛异常

2026-10-21 16:56:48 +08:00

test_analysis_phrases_labels_bare.py

叫法消毒按词认判断词（scan bare）：说法核对修复后 scan 缺省按整句规矩认（没说变化的「主要来自」不算判断），叫法是一个名字不是一句话，「主要来自华东的销售额」这样的叫法要整个不要

2026-10-21 17:12:48 +08:00

test_analysis_phrases.py

判定语照方向接末尾连续期数、辛普森的结构变化只说一遍（复核 R14、R21）：趋势末尾连续同向的期数和趋势同向时接「，已连续 3 周下降」，反向时接「，但最近已连续 3 周上升」，不再出现「呈下降趋势……已连续 3 周上升」。比率拆解判在结构变化上（mix_driven）时正文已经说了结构变化、点了那一段，辛普森那一句只说「各段的退款率大多在下降，整体却上升」；别的判定照旧带上哪一段占比从多少变到多少

2026-10-21 15:57:51 +08:00

test_analysis_probe.py

分析算子收尾：复算剔除系统字段改用同一个 DERIVED_PARAMS；去掉没用的导入和小函数；测试按仓库的写法从 tests.analysis_samples 导入样例

2026-10-21 13:08:14 +08:00

test_analysis_run.py

测试用的假结论按各算子的形状给（复核 R31）：testing.fake_result 不再一律拿可加拆解的结果表——波动基线（期次、value、change、role）、趋势（期次、value、change）、差异检验（a、b、a_value……p_adj、flag）、可比性检查（check、status、base、target、note）各给自己形状的结果表（带列类型）、具名标量、参数和输入（可比性检查是基期、本期两份），数是编的、和判定语对得上；差异检验没写模式时按比率。变化拆解那一份照旧。测试对着真算子核对列和具名标量的键

2026-10-21 16:16:40 +08:00

test_analysis_scope.py

报告文档里系统写的「分析范围」（engine/analysis_scope，契约 ScopeBlock）：按写作目录里的 A 条目照实写现象（可比性、基线、趋势）、拆过（按下钻链，上一层在前）、排除（分散的拆解、差异可能只是样本波动的检验）、算不了（带原因）、检验次数；agent 写的假设不进这一段。没拆的候选维度确定地从数据目录算：拆解所用查询 SQL 里的事实表（目录标了 fact / log，没标且只读一张表时就是它）上标成属性、状态、不遮罩（数据源设置和查询当时记下的遮罩列）、取值不多（码值表不超过 50 个取值或已列全）的列，加上关联的维度表（标了 dimension 或多对一）上同样的列；拆解按的列对不上目录、读不到目录、源还没有目录、取不回查询、认不出事实表的，not_decomposed 为 None、note 照实写核对不了。目录经这次运行的目录视图读（data/catalog_view，关掉的当核对不了），出错不挡报告。契约的 ScopeBlock 加一项 corrected（检验之间有没有校正：只做一次为 true、不止一次为 false、没做为 None）

2026-10-21 13:12:05 +08:00

test_analysis_series.py

维度列、期次列和结果表的固定列重名时报调用错误（复核 R17）：结果表的列 id 是输入的维度列（期次列）加上固定的几列，维度列叫 flag、base、target、delta、share（可加）或 mix、rate、total、w_base……（比率），期次列叫 value、change、role（波动基线、趋势）时列 id 重复，引用结果表的格会认错，下钻还会报「A1 按 0 列拆」。common.reserved_check 不分大小写挡住这些名字，告诉 agent 在 SQL 里换个别名（比如 AS flag_name）；这是结构性的调用错误，分析卡里照旧让卡失败

2026-10-21 16:02:44 +08:00

test_analysis_settings.py

分析设置要求「集中」的合计占比不小于「主要来源」的占比（复核 R16）：contract.settings_problem 加一条（没写的项按缺省补齐了比），说法用 LABELS 的叫法：「「集中」的合计占比不能小于「主要来源」的占比」——原来「主要来源」0.9 配「集中」0.5 能通过，一段占 60% 时判分散、判定语却说「没有哪一段占到 90%」。设置页写进来的、分析卡上的覆盖都按它挡；api/settings.analysis_values 读存着的一组时这一对对不上同样两项都按缺省（同另外两对）

2026-10-21 16:00:29 +08:00

test_analysis_stats.py

分析算子的统计函数（app/analysis/stats.py，纯 Python、不加依赖）：正态分布函数（math.erfc）与分位数（Acklam 逼近 + Halley 修正）、t 分布（正则化不完全 β 的连分式，自由度很大时按正态）与分位数（二分）、Wilson（从 eval/stats 移过来，评测改为引用、行为不变）、Newcombe 区间、合并比例 z 检验、Fisher 精确检验（lgamma）、Welch t 检验与区间、Holm 校正、Mann–Kendall（n ≤ 10 且无并列用逆序数递推的精确分布，否则正态近似带并列修正和连续性校正）、Theil–Sen（精确的数在公分母上按整数比，只对浮点相等的那几个精确比）、中位数 / MAD / 名次；测试用公认表值钉住（正态 0.975 分位、t(10) 临界值、品茶表、Newcombe 例子、小样本精确分布对照暴力枚举）

2026-10-21 13:03:12 +08:00

test_analysis_tools.py

2026-10-21 16:03:10 +08:00

test_api_messages.py

…

test_app_access_scope.py

应用平台集成（后端应用与流程）：身份断言 sub 为发起人、确认人进 act；应用助手对话（取或建、带历史）与助手润色只能改呈现；按新口径补算（只对无副作用的视图、加锁、同一输入只补一次）；钩子按名字关联、入站按发布版声明认；应用详情只对 manage 给草稿与岗位绑定；删工作流的阻挡算上已退役版本；待办恢复失败退回待处理；调用工具节点作证核对快照归属；子图固定版本须已发布且未退役（发起与发布检查都查）；视图里端点快照按能力的遮罩字段遮（含统一复核后的修复）

2026-10-14 21:55:51 +08:00

test_app_backfill.py

应用平台集成（后端应用与流程）：身份断言 sub 为发起人、确认人进 act；应用助手对话（取或建、带历史）与助手润色只能改呈现；按新口径补算（只对无副作用的视图、加锁、同一输入只补一次）；钩子按名字关联、入站按发布版声明认；应用详情只对 manage 给草稿与岗位绑定；删工作流的阻挡算上已退役版本；待办恢复失败退回待处理；调用工具节点作证核对快照归属；子图固定版本须已发布且未退役（发起与发布检查都查）；视图里端点快照按能力的遮罩字段遮（含统一复核后的修复）

2026-10-14 21:55:51 +08:00

test_app_catalog.py

普通用户建应用（后端）：

2026-10-15 12:09:29 +08:00

test_app_endpoint_masks.py

应用平台集成（后端应用与流程）：身份断言 sub 为发起人、确认人进 act；应用助手对话（取或建、带历史）与助手润色只能改呈现；按新口径补算（只对无副作用的视图、加锁、同一输入只补一次）；钩子按名字关联、入站按发布版声明认；应用详情只对 manage 给草稿与岗位绑定；删工作流的阻挡算上已退役版本；待办恢复失败退回待处理；调用工具节点作证核对快照归属；子图固定版本须已发布且未退役（发起与发布检查都查）；视图里端点快照按能力的遮罩字段遮（含统一复核后的修复）

2026-10-14 21:55:51 +08:00

test_app_forms.py

端到端验收修复与指标出具：

2026-10-15 07:15:37 +08:00

test_app_instance_page.py

驳回出口（后端）：审批、补充输入、编辑稿件、动作确认、代码和工具审批、双盲裁决接了「驳回」出口时沿它往下走

2026-10-18 15:56:29 +08:00

test_app_platform_v1.py

端到端验收修复与指标出具：

2026-10-15 07:15:37 +08:00

test_app_polish_scope.py

应用平台集成（后端应用与流程）：身份断言 sub 为发起人、确认人进 act；应用助手对话（取或建、带历史）与助手润色只能改呈现；按新口径补算（只对无副作用的视图、加锁、同一输入只补一次）；钩子按名字关联、入站按发布版声明认；应用详情只对 manage 给草稿与岗位绑定；删工作流的阻挡算上已退役版本；待办恢复失败退回待处理；调用工具节点作证核对快照归属；子图固定版本须已发布且未退役（发起与发布检查都查）；视图里端点快照按能力的遮罩字段遮（含统一复核后的修复）

2026-10-14 21:55:51 +08:00

test_app_principal_directory.py

复测收尾：账号密码登录时应用检查和授权接口核对名录（没有的、已停用的报错或拒收，单点登录只提醒），名录口径收成 auth/directory 一处；受管发布版在页头、版本历史、选择器、发布前检查里按发布级别写，草稿和发布版内容相同时照实说；写入能力在工具库写「只演练」；印章的「截至」只写一次；走驳回出口到达的结局不用成功样式；停着等人时说在等哪一步，同页已有会签进度时待办状态不再画一遍，名单写显示名；应用编辑器可以归档（写清后果），已归档的应用拒收草稿修改和发布；受管发布成功的提示写明受管；权限测试按 id 取应用，不撞别的测试留下的同名应用

2026-10-15 08:35:28 +08:00

test_app_spec_tools.py

测试：随机名字不带数字——新增 tests/fixtures/names.letters（uuid4 的十六进制里数字换成字母，同 test_run_data_versions 的写法），dual_check_shop 的数据源名、盲算的调用编号，评测、应用说明检查、导入、遮罩、通知几处测试里拼进文本的随机名字都改用它（以前带着「330」「300」「48」这类数时撞上「文本里不许出现这个数」的断言）；test_eval_schedule 查通知里有没有数时先去掉 32 位编号和发送时间（随机的编号带过「310」）；test_null_not_null_values_fall_back_to_the_model_default 显式导入 app.db.models（单独跑时 schedules 还没登记进元数据，KeyError）。deploy.sh 注明内置库不用 copy-to-postgres 的 --direct-url

2026-10-19 15:16:54 +08:00

test_app_use.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

test_app_versions.py

口径召回后端（W4-a）：发布新版本后反查用过旧版的答案、按参数分组在同一份数据上重算两版之差，数真变了才开 recall 待办

2026-10-16 19:52:03 +08:00

test_approval_default.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_approval_report_check.py

…

test_approval.py

驳回不再记成失败（后端）：人的驳回收成 cancelled + end_reason=rejected，消费方都读这一个字段

2026-10-16 10:14:27 +08:00

test_atomic_writes.py

原子写和部署脚本的几处（复核 R-a11、R-a12、R-a13 追加写）

2026-10-19 12:07:31 +08:00

test_auth_access.py

复测收尾：账号密码登录时应用检查和授权接口核对名录（没有的、已停用的报错或拒收，单点登录只提醒），名录口径收成 auth/directory 一处；受管发布版在页头、版本历史、选择器、发布前检查里按发布级别写，草稿和发布版内容相同时照实说；写入能力在工具库写「只演练」；印章的「截至」只写一次；走驳回出口到达的结局不用成功样式；停着等人时说在等哪一步，同页已有会签进度时待办状态不再画一遍，名单写显示名；应用编辑器可以归档（写清后果），已归档的应用拒收草稿修改和发布；受管发布成功的提示写明受管；权限测试按 id 取应用，不撞别的测试留下的同名应用

2026-10-15 08:35:28 +08:00

test_auth_identity.py

切到账号密码登录时，已经有能用密码登录的管理员就不再要求建第一个管理员：以前设置页只要从「未开启」切到账号密码登录就一律显示「第一个管理员」表单、一律提交 bootstrap（前端 needsBoot 只看切换方向），库里已经有设了密码的管理员也得再建一个。/api/auth/settings 现在带 local_admins（没停用、能用密码登录的管理员）和 passwordless_admins（没停用、还没设密码的）；设置页按它判断：有能登录的就提示「切换后用其中一个账号登录，保存后会回到登录页」、不提交 bootstrap；只有没设密码的管理员时照旧要建，并说清是谁没设密码、可以在用户列表里给他重设密码。从单点登录切到账号密码登录同样按这条判（以前不显示表单、后端却要求）。用户列表里新建用户、重设密码后，登录方式那一块重新判断。判据和后端 _local_admin_exists 同一个

2026-10-19 18:48:22 +08:00

test_autofix_assist.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_autofix_governance.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_autofix_graph_defaults.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_autofix_rules.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_background_drain.py

后台任务的 drain 不再空转：notify.service、eval.cleanup 的 drain 改用新增的 core/background.drain——做完了的任务直接从集合里摘掉，只等本事件循环上没做完的，别的循环上没做完的不等、循环关了的摘掉。以前 while _background: await gather(...) 碰上别的事件循环上做完、discard 回调永远不跑的任务，gather 立刻返回、不让出事件循环，在那里空转（CPU 打满、进程卡死）：PostgreSQL 全量里 test_personal_apps 的收尾两次卡在这里。单测在另一个线程里跑 drain、按线程等（空转时事件循环转不动，wait_for 救不了）

2026-10-19 15:29:00 +08:00

test_blueprint_data_sources.py

蓝图「看哪些数」对到的数据源和表要真的存在：卡片上照实说是哪一项、怎么改（bp.data_source_unknown / bp.data_table_unknown，带白话），挡住试运行和发布单，助手自查也拿得到；填报登记里本应用的记录表写 @records、表名固定，提示词和模板说明写明这个约定；「对到的表」改成从已接入的数据源和表里选，填报登记多一项「本应用的记录表」，卡片上照白话显示（以前要到试运行才报「绑定的工具不存在」，用户找不到在哪改）

2026-10-15 14:32:25 +08:00

test_blueprint_generation.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

test_blueprint_ops.py

写回卡片加「结果不明时谁去核实」：写回的目标能力没登记查询时，结果不明（请求发出去了、没拿到答复）平台查不了、也不自动重发，要有人去目标系统里核实；以前发布单报「写入结果不明时没人核实」「有一步还没指定谁来做」却在卡片上找不到地方改。

2026-10-15 17:31:20 +08:00

test_blueprint_starts.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

test_blueprint_template_run.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

test_blueprint_templates.py

自由形应用的两处小问题：入口按钮「发起」后英文名空一格，岗位显示名不再拿岗位名充数

2026-10-17 12:00:58 +08:00

test_blueprint_trial.py

驳回不再记成失败（后端）：人的驳回收成 cancelled + end_reason=rejected，消费方都读这一个字段

2026-10-16 10:14:27 +08:00

test_bubblewrap_probe.py

bubblewrap 沙箱不再继承后端的环境变量（复核 R-a5）：bwrap 参数最前面加 --clearenv，再按缺省（HOME、TMPDIR、PATH、LANG、PYTHONDONTWRITEBYTECODE）和调用方给的逐条 --setenv；bwrap 进程本身也只拿 PATH

2026-10-19 12:07:31 +08:00

test_bundle_api.py

2026-10-16 12:46:48 +08:00

test_bundle_build.py

2026-10-16 12:46:48 +08:00

test_bundle_masked_cards.py

…

test_bundle_masked_metrics.py

…

test_bundle_masked_queries.py

…

test_bundle_prose_export.py

…

test_bundle_rejected.py

报告里标识列的数不分千位（产线编码 1203 不再写成「1,203」）：新增 engine/cell_format.plain_columns，按序看查询当时冻结的数据目录给源列标的度量类型（identifier / status / attribute 不分，flow / stock / ratio 分）、源列名像编码编号（CODE、ID、NO 整词或结尾、驼峰的 Id/No/Code、编码、编号、代码）、是分组键（列、别名、序号都认）而不是聚合；SUM、COUNT、AVG 这类聚合是量，MIN、MAX 按那一列判；判断不了的照旧分千位。只看查询快照和它指向的表结构快照（内容寻址），组装、流式渲染、写作目录、出口复核一致。单元格显示规则 3 版：真有格子因此改了写法的文档记 cell_display: 3、引用上记 plain；离线核对页认 3 版、照 plain 渲染（解析不了 SQL），老文档按记下的版本复核照旧分千位。样本里订单号（order_no）随之不分组，check-bundle 跟着改

2026-10-16 12:46:48 +08:00

test_bundle_shown.py

2026-10-19 17:55:02 +08:00

test_bus_attach.py

…

test_caliber_from_nodes.py

口径卡来源支持节点改名映射 caliber_from.nodes（口径账本做法 4 ③）

2026-10-16 16:20:25 +08:00

test_caliber_from.py

集成收尾：前端约定写入后端实际返回的形状（应用详情只对 manage 给草稿、补算计划与结果、按名字的钩子行、能力字段审阅），去掉多种字段名都认的兼容解析；钩子按（应用, 名字）、应用助手对话按（应用, 建立人）加唯一索引，迁移前去重，插入改在保存点里、撞上就改用已有的那一行；口径卡固定的版本也须已发布且未退役，记级别之前有正式运行凭据的老版本启动时补记为已发布；证据面板和应用视图按列名遮端点快照（同一个函数），不再整张表遮掉；待办计数带上最新一条的时间，新待办通知不再漏；非管理员的搭建者不出模型接入的改动按钮

2026-10-14 22:08:33 +08:00

test_capabilities_registry.py

发布单的问题照实分清挡不挡发布：平台能力的治理默认在没人治理过时一直生效（在默认写好之前登记的 records_append 会停在「不许无人值守、没有查询能力」，填报登记出发布单时报写入不经确认、结果不明没人核实、要找管理员登记查询能力；管理员改过的同步不动）；发布摘要的三栏只列挡发布的问题，只是提醒的（视图要等第一次正式运行才有数之类）另列「提醒（不挡发布）」；确认按钮「每周一 09:00 自动出数」补上空格；检查脚本和测试跟上

2026-10-15 14:44:26 +08:00

test_capability_review.py

应用平台集成（后端访问面）：开登录后使用者的问数据只能是探索运行、节点与工具白名单、查询结果在工具边界遮罩且数据源强制只读、记忆与知识库范围不能自选，运行流按运行判读权限；对话按建立人隔离（应用助手对话要 manage）；能力字段语义的审阅队列与批量审阅；按需视图每日上限登记为设置项；通用设置接口不再读写登录设置；运行带来源、按来源筛选，审批带待办 id（含统一复核后的修复）

2026-10-14 21:55:51 +08:00

test_catalog_api.py

大库的对象索引、探查范围和后台探查（next-round 03 A1），schema_view 预筛与按需加入、剖析事实的后端（A2、遗留 e 的底座）

2026-10-16 14:17:06 +08:00

test_catalog_assistant.py

大库的对象索引、探查范围和后台探查（next-round 03 A1），schema_view 预筛与按需加入、剖析事实的后端（A2、遗留 e 的底座）

2026-10-16 14:17:06 +08:00

test_catalog_draft_engine.py

数据目录闭环第一步（后端 A）复核修正：按比例止损只看每次调用的最终结局。服务方嫌额度太大退回 8192、结构化输出不支持或回了说明文字改走纯文本、429 / 5xx 退避重试之前的那次照旧记进用量和提醒，不进止损的窗口——它不花额度，也说明不了模型写不出来；重试用完仍出错的那一次照常算。以前额度上限 8192、不支持 json_schema 的 OpenAI 兼容网关上，并发的头几次调用全是这种重来，第一次额度用完就凑满 10 次里 7 次，那一段直接记没写出来、不再拆小

2026-10-14 09:59:19 +08:00

test_catalog_draft_facts.py

剖析与探查的方言修正（C1）和没有真库时的方言验证（C2）

2026-10-16 10:25:28 +08:00

test_catalog_draft_jobs.py

起草任务写进目录的项，修改时间取那一次写入的时间：宽表逐段落盘的每一段、整张表收尾各取一次当时的时间，不再整个任务都记成开始的那一刻（以前只在任务开始时取一次、截到秒，比任务的开始时间还早，也看不出哪一段是什么时候写进去的）；补一条用假时钟逐段核对的测试

2026-10-14 14:07:14 +08:00

test_catalog_draft_settings.py

测试：设置被整体拒收的两条断言改为比较请求前后的主题，不再假定同一测试进程里别的测试没改过它（并行全量时按顺序偶发失败）

2026-10-14 22:17:00 +08:00

test_catalog_draft.py

…

test_catalog_impact.py

应用平台 BE-4 助手：按需查看（默认只给数据源概览、look 行停下执行接着写、一次拿齐、每轮 3+1 次、系统代为查看、查看记录进历史），生成过程可插拔（Applier / Checker 注入、ask 结束本轮），查看对象按类型标记并实现表 / 能力 / 工作流版本三种（表详情与 db_schema__、/schema 共用并按遮罩规矩），应用润色接口 /copilot/app-stream，从运行提取模板记来源，演示模型走一次查看（含统一复核后的修复）

2026-10-14 20:05:23 +08:00

test_catalog_merge.py

…

test_catalog_observe.py

剖析任务接口收取值观察范围，对话框给出「取值观察」；定时维护挑不出要观察的表时把原因记进触发记录

2026-10-17 08:51:51 +08:00

test_catalog_patch.py

生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报

2026-10-16 10:45:45 +08:00

test_catalog_profile_jobs.py

数据剖析可以同时剖析几张表：剖析设置加「同时剖析的表数」（table_concurrency，1–3，缺省 1，即以前的一张做完再做下一张；上限 3 是给这个源上的分析留出连接池的临时连接），每张表的查询仍一条一条发，所以同一时刻对业务库最多这么多条查询。剖析任务的执行改成按设置开几个执行者，按任务里的顺序一张结束就开始下一张；进度、发过的查询各落在自己那张表上（不再记「正在做的那一张」）。每张表开始前照旧重读数据源：停用、关掉剖析或止损后不再开始新的表，正在做的几张照常做完（止损时剩下的项记止损的原因），都结束后再把没开始的记停下；止损的连续失败、超时比例按几张表的查询合起来算。停止、关停时正在做的几张各自收尾，做完的项照常写进目录，都收完才往上交（等的时候又被停止也等完）；一张表让任务整体出错（快照被改动、数据源没了、记结果写库出错）时，另几张按停止收尾、原因写这一句，本进程续不上租约的不写。同时要估同一张表的行数时只估一次（按表加锁，先来的没估成后来的自己估）。同源已有剖析时的 409 说法从「第 x / y 张表」改成「已完成 x / y 张表」。界面：设置表单多一格（单位「张」，提示写明业务库同时要应付几条查询、和分析共用连接），风险说明、卡片悬停、开始前的醒目一句在大于 1 时写明「同时剖析 N 张表、每张表的查询一条一条地发」，预算多一行，这次最多用时按几轮算。测试：同一时刻在途查询不超过设置、每张表仍一条一条发（1/2/3 三种）、几张一起显示进行中并按顺序开始、同时停止各自写进目录、止损后不再开始新表、停用时正在做的做完、一张出错另几张按停止收尾、共享行数只估一次；check-catalog-profile 加一节（预算、估算、说法、两行进行中、表清单）。验收：后端全量 14979 通过；止损那条并发测试单独跑 30 遍、整个剖析任务测试文件并行跑 15 遍都没有偶发；tsc；check-catalog-profile 217 项、check-copy 28 项全过

2026-10-21 09:08:10 +08:00

test_catalog_profile_units.py

数据剖析可以同时剖析几张表：剖析设置加「同时剖析的表数」（table_concurrency，1–3，缺省 1，即以前的一张做完再做下一张；上限 3 是给这个源上的分析留出连接池的临时连接），每张表的查询仍一条一条发，所以同一时刻对业务库最多这么多条查询。剖析任务的执行改成按设置开几个执行者，按任务里的顺序一张结束就开始下一张；进度、发过的查询各落在自己那张表上（不再记「正在做的那一张」）。每张表开始前照旧重读数据源：停用、关掉剖析或止损后不再开始新的表，正在做的几张照常做完（止损时剩下的项记止损的原因），都结束后再把没开始的记停下；止损的连续失败、超时比例按几张表的查询合起来算。停止、关停时正在做的几张各自收尾，做完的项照常写进目录，都收完才往上交（等的时候又被停止也等完）；一张表让任务整体出错（快照被改动、数据源没了、记结果写库出错）时，另几张按停止收尾、原因写这一句，本进程续不上租约的不写。同时要估同一张表的行数时只估一次（按表加锁，先来的没估成后来的自己估）。同源已有剖析时的 409 说法从「第 x / y 张表」改成「已完成 x / y 张表」。界面：设置表单多一格（单位「张」，提示写明业务库同时要应付几条查询、和分析共用连接），风险说明、卡片悬停、开始前的醒目一句在大于 1 时写明「同时剖析 N 张表、每张表的查询一条一条地发」，预算多一行，这次最多用时按几轮算。测试：同一时刻在途查询不超过设置、每张表仍一条一条发（1/2/3 三种）、几张一起显示进行中并按顺序开始、同时停止各自写进目录、止损后不再开始新表、停用时正在做的做完、一张出错另几张按停止收尾、共享行数只估一次；check-catalog-profile 加一节（预算、估算、说法、两行进行中、表清单）。验收：后端全量 14979 通过；止损那条并发测试单独跑 30 遍、整个剖析任务测试文件并行跑 15 遍都没有偶发；tsc；check-catalog-profile 217 项、check-copy 28 项全过

2026-10-21 09:08:10 +08:00

test_catalog_profile.py

数据剖析可以同时剖析几张表：剖析设置加「同时剖析的表数」（table_concurrency，1–3，缺省 1，即以前的一张做完再做下一张；上限 3 是给这个源上的分析留出连接池的临时连接），每张表的查询仍一条一条发，所以同一时刻对业务库最多这么多条查询。剖析任务的执行改成按设置开几个执行者，按任务里的顺序一张结束就开始下一张；进度、发过的查询各落在自己那张表上（不再记「正在做的那一张」）。每张表开始前照旧重读数据源：停用、关掉剖析或止损后不再开始新的表，正在做的几张照常做完（止损时剩下的项记止损的原因），都结束后再把没开始的记停下；止损的连续失败、超时比例按几张表的查询合起来算。停止、关停时正在做的几张各自收尾，做完的项照常写进目录，都收完才往上交（等的时候又被停止也等完）；一张表让任务整体出错（快照被改动、数据源没了、记结果写库出错）时，另几张按停止收尾、原因写这一句，本进程续不上租约的不写。同时要估同一张表的行数时只估一次（按表加锁，先来的没估成后来的自己估）。同源已有剖析时的 409 说法从「第 x / y 张表」改成「已完成 x / y 张表」。界面：设置表单多一格（单位「张」，提示写明业务库同时要应付几条查询、和分析共用连接），风险说明、卡片悬停、开始前的醒目一句在大于 1 时写明「同时剖析 N 张表、每张表的查询一条一条地发」，预算多一行，这次最多用时按几轮算。测试：同一时刻在途查询不超过设置、每张表仍一条一条发（1/2/3 三种）、几张一起显示进行中并按顺序开始、同时停止各自写进目录、止损后不再开始新表、停用时正在做的做完、一张出错另几张按停止收尾、共享行数只估一次；check-catalog-profile 加一节（预算、估算、说法、两行进行中、表清单）。验收：后端全量 14979 通过；止损那条并发测试单独跑 30 遍、整个剖析任务测试文件并行跑 15 遍都没有偶发；tsc；check-catalog-profile 217 项、check-copy 28 项全过

2026-10-21 09:08:10 +08:00

test_catalog_publish_drift.py

…

test_catalog_reason.py

剖析不改人确认过的外键关系的基数：值不变、保存即确认的外键关系来源仍是 fk，以前 _patch_fk 不看状态，数据核实出的基数不同就直接改写，确认时的依据还挂着，前后矛盾；现在同 _patch_confirmed，不改人定的基数、也不标用数据核实过，测量的说法照常写进备注

2026-10-14 16:11:04 +08:00

test_catalog_render.py

…

test_catalog_review_queue.py

目录的「使用次数」和「用过这张表的运行」口径照实写：一个按查询计、一个按运行计

2026-10-17 11:55:53 +08:00

test_catalog_runtime.py

…

test_catalog_schema_truncated.py

运行时 db_schema 按需加入探查范围的留痕记上运行的发起人

2026-10-17 09:12:29 +08:00

test_catalog_semantics.py

剖析的关系覆盖率把对不上类型的键算作没对上；升级前旧说法的剖析备注不再让目录升版本

2026-10-16 12:02:41 +08:00

test_catalog_store.py

…

test_catalog_terms.py

…

test_catalog_transfer.py

导入目录：推断、有确证的项在校验之前去掉确认时的依据，手改过的文件里依据不合规也不再把整项跳过（照常只填空缺）；已确认、已驳回的项依据不合规照旧跳过

2026-10-14 16:11:04 +08:00

test_catalog_view.py

分析能力入口（二）：五个 agent 分析工具（analysis_decompose / baseline / trend / differ / comparable，名字取 contract.TOOL_NAMES），参数只有「算什么」（引用本节点查过的结果 Q3、列的角色、期次、总数 headline、下钻 parent、度量叫法、在验证什么），没有阈值参数；五个工具共用一份「分析方法」说明（ToolSpec 新增 guide：方法说明 + 去重用的 id，register / build_tools 透传进工具的 metadata），Agent 节点、协作成员绑了任一分析工具就接在 Skill 后面注入 system，同一份只注入一次，模型调用节点不注入。Agent 建工具时经 ToolContext.extra 交一个本节点的分析容器（app/tools/analysis.py 的 AnalysisScope），每次查询记台账时往里放一份输入快照（编号和「【证据 Qn】」同一个），分析结论落成 analysis_result 工件、台账记 contract.ledger_entry（带 call_id），交回模型「【分析 An】」加判定语、判定标准、关键数、附带说明、算不了的原因、结果表前几段；tool.end 带 analysis_artifact；下钻按 An 取本节点的结论；调用写错（contract.CallError，含这个节点的分析次数用完 max_calls）作为工具错误交回、不记台账、不占编号；算不了照样记结论并发一条 analysis_refused。编号只在记台账时放进容器，审批恢复重放时分析不再执行、编号不错位。遮罩列按证据面板同一个函数认（数据源设的、按 SQL 认出改了名字的），遮罩运行交给算子的是遮过的快照。阈值读发起时的快照，没有就现读设置；运行期依赖给运行当天、按运行目录视图读的目录、剖析事实、现查表范围的探查（W1-a 的 make_prober，还没有时不给）。协作成员同样注入方法、同样编号（协作节点不记台账）。使用者问数据的白名单加上五个分析工具和分析卡；调用工具节点调分析工具在画布上就报错（analysis.tool_node）。能力登记不把它们当查询（is_platform_query 不认）

2026-10-21 13:02:30 +08:00

test_challenge_masking.py

测试：随机名字不带数字——新增 tests/fixtures/names.letters（uuid4 的十六进制里数字换成字母，同 test_run_data_versions 的写法），dual_check_shop 的数据源名、盲算的调用编号，评测、应用说明检查、导入、遮罩、通知几处测试里拼进文本的随机名字都改用它（以前带着「330」「300」「48」这类数时撞上「文本里不许出现这个数」的断言）；test_eval_schedule 查通知里有没有数时先去掉 32 位编号和发送时间（随机的编号带过「310」）；test_null_not_null_values_fall_back_to_the_model_default 显式导入 app.db.models（单独跑时 schedules 还没登记进元数据，KeyError）。deploy.sh 注明内置库不用 copy-to-postgres 的 --direct-url

2026-10-19 15:16:54 +08:00

test_challenge_node.py

子工作流里的反方审稿按全局 id 记它审的报告：审稿记录和工件上的报告写这次运行里的 id（「sub/write」，同 report.checked、报告文档，第 1 波 B1 修过报告节点同样的问题），证据面板连子工作流里的审稿一起认（_Sealed.nodes_of nested），点开子图里那份报告的句子认得出审它的那次审稿；审批卡上的报告按全局 id 记，打开证据面板、审批质询对得上；单句面板的报告名写「子工作流 › 报告」，不写内部 id

2026-10-19 09:08:45 +08:00

test_challenge_rationale_rules.py

…

test_chat_turn_policy.py

2026-10-19 22:48:23 +08:00

test_chat_turns_races.py

问数据一轮的复核修正（后端）：同时来的几次发起只起得来一次、事件 seq 不撞号、晚到的复核记得上也送得到、使用者不能继续运行、

2026-10-18 18:07:03 +08:00

test_chat_turns.py

复核 R-b15（隔离后等不到重新登记的运行原因记错、任务没摘）：_drive 里 fence.ready() 等不到时照实收尾——排队中的（一步都没执行过）收成失败，写明「本进程隔离后没能重新登记，这次运行没有开始执行」并记 run.failed；要接着执行的（继续、批了审批）收成中断、断点完好可继续运行；条件更新，状态、属主变了（别的进程先接手）就不动；执行任务从 run_manager._tasks 里摘掉。补测试：隔离后新身份一直没登记上，新发起的运行收成失败、原因写对、run.failed 记下、任务摘掉

2026-10-19 22:48:23 +08:00

test_claims_prefilter.py

…

test_cluster_fence.py

2026-10-19 15:08:39 +08:00

test_cluster.py

复核 R-b14（PostgreSQL 单进程墙钟一跳就隔离自己）：取得到计入休眠的钟（SLEEP_AWARE）时 stale() 只看它，墙钟只在取不到时当后备（两只里走得多的那只）；两只钟对不上（jumped）不再直接隔离，先续一次租——续租那一句按库的时钟核对「自己的租约还没过期」，以它为准：续上了只记一条日志照常，续不上才隔离。README「多进程」补一句：库服务器自己的时钟往前跳超过一个租约时所有进程一起隔离、怎么恢复，往回跳时真没了的进程要多等，本机墙钟跳了不隔离。补测试：墙钟往前往后跳一小时不算续晚了、只算对不上，计入休眠的钟走过两个租约照样算，取不到时墙钟当后备；PostgreSQL 单进程墙钟 ±1 小时续租照常续上、不隔离，真过期仍隔离；执行到一半墙钟 ±1 小时，运行照常跑完、世代不变（改前的写法往前跳那条不过）

2026-10-19 15:07:17 +08:00

test_code_evidence_role.py

…

test_code_output.py

…

test_compare_api.py

运行对比里子工作流的口径卡按卡所在那一层找产出：组装推演用的 Sources 时带上是哪张卡，节点产出、跑完的时刻按 engine/lineage.in_scope 换成卡那一层的 id（同推演 api/whatif._sources、证据面板 _InputMasks._output）。以前子图里的卡取值链写的是子图里的 id（nodes.parse），对比拿父图里同名的节点当它的产出，容器输入认到父图那次查询上；加一条子图卡的真跑对比测试

2026-10-19 09:03:37 +08:00

test_compare_engine.py

…

test_compare_guards.py

…

test_continue_run.py

…

test_contract_analysis_claims.py

2026-10-21 16:03:10 +08:00

test_contract_cells.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_contract_citations.py

…

test_contract_claims.py

…

test_contract_fenced_body.py

…

test_contract_judge.py

…

test_contract_shapes.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

test_conversation_status.py

问数据：被驳回的那次尝试不写「已手动停止」，会话列表标「被驳回」

2026-10-16 12:46:36 +08:00

test_conversations_isolation.py

应用平台集成（后端访问面）：开登录后使用者的问数据只能是探索运行、节点与工具白名单、查询结果在工具边界遮罩且数据源强制只读、记忆与知识库范围不能自选，运行流按运行判读权限；对话按建立人隔离（应用助手对话要 manage）；能力字段语义的审阅队列与批量审阅；按需视图每日上限登记为设置项；通用设置接口不再读写登录设置；运行带来源、按来源筛选，审批带待办 id（含统一复核后的修复）

2026-10-14 21:55:51 +08:00

test_conversations.py

生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报

2026-10-16 10:45:45 +08:00

test_copilot_analysis.py

助手建图加「关掉分析工具」的开关，给评测的「分析工具开、关」对照用：api/copilot.answer_ops 加关键字参数 analysis_tools（缺省真，和以前一字不差）。为假时给助手的工具清单不列五个分析工具（_tool_catalog），节点手册去掉只讲分析能力的三段（agent 段里分析类问题绑分析工具那一条、分析卡一整条、搭图规则第 7 条；报告段的引用写法和分析说法核对照留，node_reference），问数据的包装不给分析类问题那一条形状（ANALYSIS_SHAPE_PROMPT 抽成常量），问题意图那条自查不提；图里照样绑了分析工具的（Agent、协作成员、调用工具节点）按「绑定的工具不存在」挡（analysis_tools_off，交回模型去掉，改不好就不运行）。chat/drive.TurnDriver 加同名参数和属性 analysis_tools（缺省真），_generate 透传给 answer_ops；问数据页不暴露，eval/answer.Driver 之后按变体设。测试：关着时工具清单、手册、包装都没有分析，绑了被挡、改掉就运行；开着时绑了照常运行；没碰分析工具的一轮开、关交出的操作逐条一样；TurnDriver 透传

2026-10-21 18:47:10 +08:00

test_copilot_answer_ops.py

应用平台 BE-4 助手：按需查看（默认只给数据源概览、look 行停下执行接着写、一次拿齐、每轮 3+1 次、系统代为查看、查看记录进历史），生成过程可插拔（Applier / Checker 注入、ask 结束本轮），查看对象按类型标记并实现表 / 能力 / 工作流版本三种（表详情与 db_schema__、/schema 共用并按遮罩规矩），应用润色接口 /copilot/app-stream，从运行提取模板记来源，演示模型走一次查看（含统一复核后的修复）

2026-10-19 22:48:23 +08:00

test_copilot_approval_wording.py

…

test_copilot_blueprint_stream.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

test_copilot_challenge_guide.py

…

test_copilot_claims_default.py

…

test_copilot_context.py

2026-10-14 20:05:23 +08:00

test_copilot_coverage.py

助手搭图时就发现「查的区间里表里没有数据」：自查（GraphChecker）对工具节点写死的 SQL 按今天跑一遍覆盖检查（data/coverage.sql_gaps：不跑原 SQL，只跑算界和现查范围的两条小查询，SQL 里所有带时间谓词的表都查，按表去重、限时，异步查库，带模板的 SQL 不查）；完全不重叠的作为一条 sql_no_data 问题交回模型改一轮（换有这段数据的表，没有就在 done 的说明里照实告诉用户数据只到哪天），修正后仍在的不挡运行，作为提醒留在检查结果和交付的问题清单里（问数据流式、画布非流式都是）。look / db_schema 的剖析信息在日期范围最早和最晚是同一天时加一句「剖析时这张表的 X 只有一天的数据，可能每天整表重灌：算历史周期请换有历史的表」；助手节点手册写明按周期取数前先看表的日期范围，只有一天、最新日期早于要查的区间的表不能用来算这段时间

2026-10-20 10:38:30 +08:00

test_copilot_empty_diagnosis.py

2026-10-19 22:48:23 +08:00

test_copilot_entity_guide.py

…

test_copilot_evidence_guide.py

生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报

2026-10-16 10:45:45 +08:00

test_copilot_look.py

生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报

2026-10-16 10:45:45 +08:00

test_copilot_markup_ops.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-19 22:48:23 +08:00

test_copilot_merge.py

生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报

2026-10-16 10:45:45 +08:00

test_copilot_patch_layout.py

生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报

2026-10-16 10:45:45 +08:00

test_copilot_prompt_evidence.py

2026-10-21 13:13:04 +08:00

test_copilot_reject_exit_guide.py

助手的节点手册讲驳回出口：哪些节点能接（审批、补充输入、编辑稿件、动作确认、代码和工具审批、双盲裁决），连线写 sourceHandle="rejected"，什么时候接（驳回后要通知、退回修改、走另一条路），不接时怎样（运行结束、记为被驳回；审批模式这一路到此为止；写了驳回即终止就别接），驳回那条路必须走到成果节点或结束，失败重试、出错时继续不管驳回。以前手册只有一句审批的 approved / rejected，助手画出来的图驳回就整轮结束

2026-10-19 08:47:53 +08:00

test_copilot_scope.py

生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报

2026-10-16 10:45:45 +08:00

test_copilot_selfcheck.py

生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报

2026-10-16 10:45:45 +08:00

test_copilot_sql_alias.py

应用平台 BE-4 助手：按需查看（默认只给数据源概览、look 行停下执行接着写、一次拿齐、每轮 3+1 次、系统代为查看、查看记录进历史），生成过程可插拔（Applier / Checker 注入、ask 结束本轮），查看对象按类型标记并实现表 / 能力 / 工作流版本三种（表详情与 db_schema__、/schema 共用并按遮罩规矩），应用润色接口 /copilot/app-stream，从运行提取模板记来源，演示模型走一次查看（含统一复核后的修复）

2026-10-14 20:05:23 +08:00

test_copilot_sqlcheck.py

生成过程抽成 answer_ops、复核抽成 review_of_run，助手建图和复核的用量也记下（细案 01 做法 2、3）：评测和问数据页走同一条生成路径，这一轮的花费不再低报

2026-10-16 10:45:45 +08:00

test_copilot_stream.py

…

test_copilot_table_pick.py

按需求挑选不再总是「没挑出来，已把表目录交给助手」：挑选以为能关掉思考、只给 1024 的输出额度，可经 OpenAI 兼容接入的推理模型（DeepSeek、GLM、Kimi 这一类）收不到 thinking=off，想完就没额度写结果，回复是空的或 JSON 只写了一半，又被报成「不是约定的格式」。额度改成和证据裁判、核查同一档 16384，服务方嫌大时退回 4096（按接入和模型记在进程里、互相认），时限 20 秒放宽到 45 秒；结构化输出带原始回复，正文、工具调用参数里的 JSON 也认，<think> 里的草稿不算，正文里顺手写的 [1] 不算空结果；没成的原因照实分开说：被截断（带额度）、回复是空的、写了字却不是约定的格式，认不出的回复开头记进日志

2026-10-15 14:59:40 +08:00

test_copilot_truncation.py

测试：随机名字不带数字——新增 tests/fixtures/names.letters（uuid4 的十六进制里数字换成字母，同 test_run_data_versions 的写法），dual_check_shop 的数据源名、盲算的调用编号，评测、应用说明检查、导入、遮罩、通知几处测试里拼进文本的随机名字都改用它（以前带着「330」「300」「48」这类数时撞上「文本里不许出现这个数」的断言）；test_eval_schedule 查通知里有没有数时先去掉 32 位编号和发送时间（随机的编号带过「310」）；test_null_not_null_values_fall_back_to_the_model_default 显式导入 app.db.models（单独跑时 schedules 还没登记进元数据，KeyError）。deploy.sh 注明内置库不用 copy-to-postgres 的 --direct-url

2026-10-19 22:48:23 +08:00

test_copy_to_postgres.py

2026-10-19 15:16:54 +08:00

test_csv_grid.py

配方导入只把 .csv / .tsv 当 CSV 读；网页、XML 冒充的 Excel 照旧拒收并说清楚

2026-10-16 12:23:19 +08:00

test_custom_tool_draft.py

…

test_custom_tool_schema.py

…

test_datasource_force_readonly.py

…

test_datasource_option_keys.py

数据源的探查范围、定时维护不再被拼进连接串：data/engine._NON_DRIVER_OPTIONS 补上 introspect_scope、catalog_maintenance。以前漏在名单外，设过探查范围（运行时按需把范围外的表加进来时也会自动写）或定时维护的 MySQL / PostgreSQL / Oracle 数据源，驱动 connect() 收到不认识的关键字参数，每一条查询都失败；加守卫测试，把 app/data 下所有 *_OPTION 常量扫出来逐个核对都不进连接串

2026-10-19 08:08:51 +08:00

test_datasource_preview.py

大库的对象索引、探查范围和后台探查（next-round 03 A1），schema_view 预筛与按需加入、剖析事实的后端（A2、遗留 e 的底座）

2026-10-16 14:17:06 +08:00

test_datasource.py

…

test_datasources_upload.py

应用库可移植到 PostgreSQL：AGENTLAB_DATABASE_URL 设成 postgresql+asyncpg://… 时整个应用库用 PostgreSQL，断点用官方的 langgraph-checkpoint-postgres（同一个库，AGENTLAB_CHECKPOINT_URL 可另给）；不设时照旧是数据目录里的 SQLite，行为不变

2026-10-19 09:52:09 +08:00

test_db_direct.py

R-b12 的尾巴：check_pgbouncer 判同一个主机端口时把主机名规范化——localhost、127.x.x.x、::1 都算本机回环，IP 按地址比（::ffff:10.0.0.5 和 10.0.0.5 相同），解析不成 IP 的按字面（小写）比、不查 DNS。补测试：localhost 对 127.0.0.1、127.0.0.1 对 ::1、IPv4 映射地址同端口都拒绝，本机另一个端口、名字不同的放行

2026-10-19 15:09:10 +08:00

test_db_portable.py

两种库行为再对齐一轮（复核 NUL、R-a4、R-a6、R-a7、R-a10）

2026-10-19 12:06:31 +08:00

test_db_startup.py

合入 nr8/b 之后的配合：启动时先等库再做版本检查（cluster/version.preflight 是第一次连库，放在等库之前的话库的容器晚一步起来服务就直接崩），单测核对先后；deploy/README 多进程一段写明内置 PostgreSQL 是直连、不用 AGENTLAB_DATABASE_DIRECT_URL，upgrade 先停掉旧容器（全部工作进程）、备份、再起新版本，正合不许新旧版本同时运行的拦截

2026-10-19 14:06:20 +08:00

test_deploy_script.py

复核 R-d6（sudo ./deploy.sh 时 DATA_DIR=~/… 展开成 /root 下）：有 SUDO_USER 时 ~ 按它的家目录展开（getent passwd 取，取不到退回 $HOME），「不能是家目录本身」也按它查；install、upgrade、migrate 开头打印展开后的绝对路径（DATA_DIR 用了 ~ 时注明 ~ 是哪个目录）。deploy/README 写一句（agentlab.env 已有的行没动）。假 docker 单测：SUDO_USER 的家目录、取不到时退回 $HOME

2026-10-19 16:15:21 +08:00

test_direct_select.py

…

test_directory_candidates.py

使用者选人（后端）：按用途给候选池，开登录时入口表单、待办表单的选人控件按同一个池核对

2026-10-16 10:24:22 +08:00

test_dual_check_config.py

…

test_dual_check_executor.py

…

test_dual_check_facts.py

SQL 差异说明认得同一列上的条件改写：说清「这次对 X 的条件是 …，口径是 …」

2026-10-17 08:17:12 +08:00

test_dual_check_fixture.py

SQL 差异说明认得同一列上的条件改写：说清「这次对 X 的条件是 …，口径是 …」

2026-10-17 08:17:12 +08:00

test_dual_check_node.py

双盲复算：盲算触顶、按无法复算记时（_limit_text 那一路），把盲算交回的理由（渲染后的正文，已经过遮罩）截一段带进原因（「盲算已达每项最多查询次数（1 次）；盲算交回的理由：…」），审批卡、缺口说明上看得到它查到了什么，没有理由的照旧。原值所在的格子落在「查询区间里这张表没有数据」的列上时不派盲算、按无法复算记；盲算交回的格子落在这样的列上时不判一致、按无法复算记；原因都写「查询区间里这张表没有数据（…）」

2026-10-20 10:33:34 +08:00

test_dual_check_rationale_rules.py

…

test_dual_check_upload.py

…

test_emit_order.py

…

test_endpoints.py

端到端验收修复与指标出具：

2026-10-15 07:15:37 +08:00

test_engine_cache.py

…

test_eval_analysis_runs.py

评测变体加「分析工具」开 / 关（缺省开）和「分析工具贡献」预设对照：eval/variants 的变体多一项 analysis {tools: on | off}，只认这两个值、缺省开，不合规的照实拒（eval_variant_invalid，落到 variant.analysis）；analysis_tools(变体) 读开关，加这一项之前存下的变体按开。eval/answer.TurnContext 加 analysis_tools，Driver 透传给 chat/drive.TurnDriver（再到 api/copilot.answer_ops）：关的那一臂建图时工具清单不列分析工具、节点手册不讲分析卡；工作流题不建图，不受影响。同一变体（variant_key）认分析工具：开着时不写进去，和加这一项之前算出来的一样，以前的评测照样当基准、趋势线不断；关着时不同。指纹记 analysis_tools，对比的指纹差异写「分析工具：开 → 关」（老指纹里没有这一项的按开）；变体那一句写「分析工具开 / 关」，结果页、A/B、估算照它显示。api/evals 的预设对照加 analysis_tools（variants.analysis_tools_preset：开、关两臂，名字「分析工具开」「分析工具关」，别的项照 variant 或题集的缺省）。测试：变体规范化、拒收、同一变体指纹、变体那一句、预设两臂和 Driver 拿到的开关、估算与 A/B 拒收（test_eval_runner）；指纹差异的开、关和老指纹（test_eval_compare）；真运行的「分析工具贡献」对照（test_eval_analysis_runs：关的那一臂助手看到的 system 里没有分析工具和分析卡、作答运行里没有分析结论、算错，开的那一臂对且可追溯，两臂共用期望、指纹和同一变体都不同）

2026-10-21 19:32:38 +08:00

test_eval_analysis_suite.py

虚构库 retail_trends 与分析题集：26 周的零售订单（截止昨天、固定种子），相对上一个整周埋了八个效应；题集 analysis_suite.json 每个效应一题，期望由平台的分析方法在期望 SQL 上算

2026-10-21 18:12:12 +08:00

test_eval_analysis.py

分析期望的两处小修：期望 SQL 只返回两期时补上的基期、本期写成文字交给分析工具的参数（期次是数的也认，算子按写出来的样子比）；参数和结果对不上的原因前面写「第 n 个期望（贡献）算不出期望」，不再叠两个「的」。测试补逐题 E1 顺着下钻找到两层的查询

2026-10-21 18:30:08 +08:00

test_eval_cases.py

评测接口与题集导出导入、零售样例题集（第 2 波 W2-c）

2026-10-16 13:58:36 +08:00

test_eval_cleanup.py

评测执行的测试：执行、评分、统计与对比、清理、定时与通知

2026-10-16 16:49:47 +08:00

test_eval_compare.py

评测变体加「分析工具」开 / 关（缺省开）和「分析工具贡献」预设对照：eval/variants 的变体多一项 analysis {tools: on | off}，只认这两个值、缺省开，不合规的照实拒（eval_variant_invalid，落到 variant.analysis）；analysis_tools(变体) 读开关，加这一项之前存下的变体按开。eval/answer.TurnContext 加 analysis_tools，Driver 透传给 chat/drive.TurnDriver（再到 api/copilot.answer_ops）：关的那一臂建图时工具清单不列分析工具、节点手册不讲分析卡；工作流题不建图，不受影响。同一变体（variant_key）认分析工具：开着时不写进去，和加这一项之前算出来的一样，以前的评测照样当基准、趋势线不断；关着时不同。指纹记 analysis_tools，对比的指纹差异写「分析工具：开 → 关」（老指纹里没有这一项的按开）；变体那一句写「分析工具开 / 关」，结果页、A/B、估算照它显示。api/evals 的预设对照加 analysis_tools（variants.analysis_tools_preset：开、关两臂，名字「分析工具开」「分析工具关」，别的项照 variant 或题集的缺省）。测试：变体规范化、拒收、同一变体指纹、变体那一句、预设两臂和 Driver 拿到的开关、估算与 A/B 拒收（test_eval_runner）；指纹差异的开、关和老指纹（test_eval_compare）；真运行的「分析工具贡献」对照（test_eval_analysis_runs：关的那一臂助手看到的 system 里没有分析工具和分析卡、作答运行里没有分析结论、算错，开的那一臂对且可追溯，两臂共用期望、指纹和同一变体都不同）

2026-10-21 19:32:38 +08:00

test_eval_e2e.py

评测执行的测试：执行、评分、统计与对比、清理、定时与通知

2026-10-16 16:49:47 +08:00

test_eval_gold.py

评测期望的遮罩拒收测试：每种写法的期望直接写在参数里，不再用嵌套的条件表达式拼

2026-10-16 14:06:29 +08:00

test_eval_origin.py

系统派生的运行不进使用统计（总方案 X1、X2，细案 01 做法 4）：评测一跑，聚类、白名单、目录使用热度都会被刷高

2026-10-16 10:18:12 +08:00

test_eval_runner.py

评测变体加「分析工具」开 / 关（缺省开）和「分析工具贡献」预设对照：eval/variants 的变体多一项 analysis {tools: on | off}，只认这两个值、缺省开，不合规的照实拒（eval_variant_invalid，落到 variant.analysis）；analysis_tools(变体) 读开关，加这一项之前存下的变体按开。eval/answer.TurnContext 加 analysis_tools，Driver 透传给 chat/drive.TurnDriver（再到 api/copilot.answer_ops）：关的那一臂建图时工具清单不列分析工具、节点手册不讲分析卡；工作流题不建图，不受影响。同一变体（variant_key）认分析工具：开着时不写进去，和加这一项之前算出来的一样，以前的评测照样当基准、趋势线不断；关着时不同。指纹记 analysis_tools，对比的指纹差异写「分析工具：开 → 关」（老指纹里没有这一项的按开）；变体那一句写「分析工具开 / 关」，结果页、A/B、估算照它显示。api/evals 的预设对照加 analysis_tools（variants.analysis_tools_preset：开、关两臂，名字「分析工具开」「分析工具关」，别的项照 variant 或题集的缺省）。测试：变体规范化、拒收、同一变体指纹、变体那一句、预设两臂和 Driver 拿到的开关、估算与 A/B 拒收（test_eval_runner）；指纹差异的开、关和老指纹（test_eval_compare）；真运行的「分析工具贡献」对照（test_eval_analysis_runs：关的那一臂助手看到的 system 里没有分析工具和分析卡、作答运行里没有分析结论、算错，开的那一臂对且可追溯，两臂共用期望、指纹和同一变体都不同）

2026-10-21 19:32:38 +08:00

test_eval_schedule.py

撤回上一条（定时评测测试放大数据源上限）：评测包 an2/b 的 5d53ed73 做了同一处修改，留着合并时会撞同一个夹具；这里撤回，合并后照 an2/b 那一份

2026-10-21 18:40:30 +08:00

test_eval_score.py

评测逐题比 SQL 和账本同一个口径：传报告引用了哪几列（ledger/match.referenced_of），整条比不等价时按引用的列投影再比；「多查了几列」那一条不算差在哪个方面

2026-10-17 12:29:20 +08:00

test_eval_snapshots.py

多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁

2026-10-19 11:40:33 +08:00

test_eval_stats.py

评测估算和每题平均花费：有估不出金额的调用时不再写成 0 美元

2026-10-17 11:40:27 +08:00

test_evals_api.py

测试：随机名字不带数字——新增 tests/fixtures/names.letters（uuid4 的十六进制里数字换成字母，同 test_run_data_versions 的写法），dual_check_shop 的数据源名、盲算的调用编号，评测、应用说明检查、导入、遮罩、通知几处测试里拼进文本的随机名字都改用它（以前带着「330」「300」「48」这类数时撞上「文本里不许出现这个数」的断言）；test_eval_schedule 查通知里有没有数时先去掉 32 位编号和发送时间（随机的编号带过「310」）；test_null_not_null_values_fall_back_to_the_model_default 显式导入 app.db.models（单独跑时 schedules 还没登记进元数据，KeyError）。deploy.sh 注明内置库不用 copy-to-postgres 的 --direct-url

2026-10-19 15:16:54 +08:00

test_evals_ui_api.py

问题聚类的向量只取一次：评测页「口径命中与重复度」不再按窗口把问题重发给向量模型（复核 W4R-14）

2026-10-16 21:41:30 +08:00

test_evidence_api.py

…

test_evidence_audit.py

报告撰写节点加「分析说法核对」（analysis_claims：off / check / strict，缺省 check）和「分析范围」（analysis_scope：auto / off，缺省 auto），画布校验和执行时报同一句话（report.analysis_claims_invalid / analysis_scope_invalid），界面叫法进 labels，运行对比登记这两项。check：判断词没挂对分析结论、原因没有依据的句子交回写作者重写一次（不按最多重写次数反复），仍有的标在报告里、写一条日志 report_analysis_claims，不影响档位；strict：按最多重写次数重写，仍有的写进产出的 issuance_gaps（另记 analysis_gap）；两种都不让节点失败（不挡生成）；off 不核、写作规则和文档一字不变；升级前发起的运行照旧。写作者角色改成「挑重点、组织结构、说清变化；有分析结论时说清变化来自哪里；原因只按证据写」，写作规则按目录里有没有分析结论各加一段判断词规则，重写请求列出违规和修法；这次有分析结论、取值 auto 时每一稿文档都带系统写的 analysis_scope。产出和 report.checked 记下处置。几个测裁判、结论句策略、审计表的用例写作者那句「增长主要来自新客」没有拆解可挂，把分析说法核对关掉

2026-10-21 13:12:15 +08:00

test_evidence_challenge_marks.py

…

test_evidence_entities.py

字段标记紧跟在同一张表名后面时只显示字段名（部署上的「取自某表的某表.某列」）：[[c:表.列]] 前面紧挨着（隔空白、「的」「中的」「里的」）刚写过同一张表的名字——写成文字或 [[t:同一张表]] 都算，按 name_key 比，带库名的全名、末段都认，英文名前面还连着字母的不算——正文只显示列名，出处、证据标识照旧是那个字段，引用上记 short: true，复核照它核对显示的字；没有这一项的老文档照旧按全名核对。整篇组装、render_markers、流式渲染一致（流式渲染记着已放出正文的末尾一截）。写作规则（ENTITY_RULES）写一句

2026-10-19 17:55:02 +08:00

test_evidence_entity_chain.py

…

test_evidence_judge_api.py

应用库可移植到 PostgreSQL：AGENTLAB_DATABASE_URL 设成 postgresql+asyncpg://… 时整个应用库用 PostgreSQL，断点用官方的 langgraph-checkpoint-postgres（同一个库，AGENTLAB_CHECKPOINT_URL 可另给）；不设时照旧是数据目录里的 SQLite，行为不变

2026-10-19 09:52:09 +08:00

test_evidence_judge.py

全量回归抓到的两处：裁判那本账留回 judge._today 这个日历名字；冻结表结构快照时 ctx 不一定带目录视图

2026-10-16 11:04:41 +08:00

test_evidence_legacy_guess.py

…

test_evidence_legacy.py

…

test_evidence_markers.py

…

test_evidence_mask_memo.py

…

test_evidence_masked_aliases.py

…

test_evidence_masks_like_bundle.py

…

test_evidence_metric_masks.py

…

test_evidence_on_demand_formal.py

…

test_evidence_query_catalog.py

…

test_evidence_query_chain.py

…

test_evidence_quotes.py

…

test_evidence_see_brackets.py

…

test_evidence_tidy_claims.py

数字标记后面重复写的单字单位也去掉（部署上的「覆盖 8条条产线」）：以前单字的单位后面紧跟着字时一律不动，现在只在它和后面的字连起来是一个更长的单位（人次、个月、台套、元/…，_LONGER_UNIT）时不动，让「人」对「人次」这样的不一致照旧露出来；「条产线」「人参加」照样去掉重复的那个字，流式渲染一致。写作规则加一条 UNIT_RULE（[[m:]]、[[v:]] 自带单位，后面不要再写一遍），助手节点手册讲 [[m:]] 的那一行也写明

2026-10-19 17:55:02 +08:00

test_evidence_unicode_names.py

字段标记紧跟在同一张表名后面时只显示字段名（部署上的「取自某表的某表.某列」）：[[c:表.列]] 前面紧挨着（隔空白、「的」「中的」「里的」）刚写过同一张表的名字——写成文字或 [[t:同一张表]] 都算，按 name_key 比，带库名的全名、末段都认，英文名前面还连着字母的不算——正文只显示列名，出处、证据标识照旧是那个字段，引用上记 short: true，复核照它核对显示的字；没有这一项的老文档照旧按全名核对。整篇组装、render_markers、流式渲染一致（流式渲染记着已放出正文的末尾一截）。写作规则（ENTITY_RULES）写一句

2026-10-19 17:55:02 +08:00

test_evidence_validate.py

…

test_evidence_verify_status.py

…

test_excel_p1_integration.py

…

test_expressions.py

…

test_extract_truncation.py

…

test_fan_in.py

…

test_files.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

test_fixtures_xlsx.py

…

test_frontend_eval_unions.py

评测前端：变体里能选「分析工具」开 / 关，发起评测多一种「分析工具贡献对照」。typesEval 加 EvalAnalysisTools、EvalPreset，EvalVariant 多 analysis；termsEval 加分析工具的叫法、提示和这种对照的说明，对比「都没变」那句带上分析工具。StartDialog：ArmFields 多一格分析工具（题集的默认变体同一张表单），预设对照里由预设定的那一项不摆（目录贡献不摆目录、分析工具贡献不摆分析工具）；分析工具贡献对照交 {preset: analysis_tools, variant}，变体里不带分析工具和名字，缺省每题 3 次。结果页、对比页、A/B 照服务端的变体那一句和指纹差异显示。check-evals：发起时评一次选「关」、两种预设的请求体和估算的两臂，对比写「分析工具：开 → 关」，分析工具贡献对照的两臂和详情页头；test_frontend_eval_unions 对上分析工具的取值、叫法和预设对照

2026-10-21 19:32:38 +08:00

test_frontend_type_unions.py

普通用户建应用集成收尾：

2026-10-15 13:55:19 +08:00

test_gov_wrapup.py

…

test_governance_analysis_claims.py

自动修复和门禁对 analysis_claims 写了认不出的值（如 loose）对齐 claims 的做法：G3 那一条修复（_plan_report_policy）不再顺手改成 strict（门禁跳过它、交给校验报），认不出的取值由校验那条 report.analysis_claims_invalid 自己的修复管——受管级别改成 strict（G3 只认它，答案唯一），别的级别不核对、重写一次后标出、重写后仍有的计入缺口三档要人选，不给建议（同 claims_invalid 的 _plan_claims）；跳过认不出的取值统一按门禁的 _POLICY_PROBLEMS 判。测试：受管级别 G3 修复只改 numbers、认不出的取值另有一条改成 strict，一起应用后通过；已发布级别三档候选、选了照写

2026-10-21 16:08:22 +08:00

test_governance_judge.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_governance_report_lint.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_graph_checks.py

…

test_guardrails.py

…

test_health_record.py

…

test_inquiry_api.py

…

test_inquiry_masking_e2e.py

…

test_inquiry_masking.py

…

test_inquiry_rationale_rules.py

…

test_inquiry_usage.py

…

test_integration_errors.py

应用入口、按需视图的表单没通过校验也带 code（form_invalid），和待办回复、入站钩子同一个码

2026-10-16 10:33:41 +08:00

test_introspect_broken_view.py

…

test_introspect_constraints.py

…

test_introspect_jobs.py

多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁

2026-10-19 11:40:33 +08:00

test_issuance_matched.py

…

test_issuance_positions.py

…

test_issuance_upstream_gaps.py

…

test_issuance.py

…

test_job_runtime.py

多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁

2026-10-19 11:40:33 +08:00

test_judge_entity_sql.py

…

test_judge_excerpt_masks.py

…

test_judge_provenance.py

…

test_judge_rework_api.py

…

test_judge_rework_engine.py

…

test_judge_rework_grading.py

报告撰写节点加「分析说法核对」（analysis_claims：off / check / strict，缺省 check）和「分析范围」（analysis_scope：auto / off，缺省 auto），画布校验和执行时报同一句话（report.analysis_claims_invalid / analysis_scope_invalid），界面叫法进 labels，运行对比登记这两项。check：判断词没挂对分析结论、原因没有依据的句子交回写作者重写一次（不按最多重写次数反复），仍有的标在报告里、写一条日志 report_analysis_claims，不影响档位；strict：按最多重写次数重写，仍有的写进产出的 issuance_gaps（另记 analysis_gap）；两种都不让节点失败（不挡生成）；off 不核、写作规则和文档一字不变；升级前发起的运行照旧。写作者角色改成「挑重点、组织结构、说清变化；有分析结论时说清变化来自哪里；原因只按证据写」，写作规则按目录里有没有分析结论各加一段判断词规则，重写请求列出违规和修法；这次有分析结论、取值 auto 时每一稿文档都带系统写的 analysis_scope。产出和 report.checked 记下处置。几个测裁判、结论句策略、审计表的用例写作者那句「增长主要来自新客」没有拆解可挂，把分析说法核对关掉

2026-10-21 13:12:15 +08:00

test_judge_settings.py

…

test_judge_truncation.py

…

test_kb_progress.py

知识库「同时只跑一个重建」的两条测试，放行之后只重建一个空集合：测的是互斥不是重建本身。按全部集合重建要把同一个 xdist 进程里别的测试留下的几百段都重算一遍（这一轮加了测试，分到它那个进程的多了，实测停在 428/431），满载时超过 10 秒的等待，后面一条也跟着撞上「正在重建」

2026-10-19 12:07:31 +08:00

test_kb.py

…

test_layout.py

…

test_ledger_api.py

E4 的版本用量只算有口径卡的工作流

2026-10-17 09:19:24 +08:00

test_ledger_cells.py

差异说明认得一边套了 ROUND：说「X 套了 ROUND(…, 2)：保留 2 位小数，另一边没有取整」，只陈述写法、不断言值不同，判等价照旧不等价；零售样例题集的期望 SQL 去掉 ROUND(…, 2)（取整交给展示，评分本来按容差比数），评测逐题比 SQL 不再因为期望里的取整一律对不上

2026-10-17 13:31:25 +08:00

test_ledger_certify.py

问题聚类的类 id 由成员定，「不是口径」按成员记

2026-10-17 12:15:07 +08:00

test_ledger_compose.py

口径标签逐格判：引用了好几列的查询，每个数按它自己那一格标

2026-10-17 13:07:19 +08:00

test_ledger_derive.py

评测题集与期望答案（第 2 波 W2-c）第一步：模型、派生图、期望的三种来源、目录快照与影子起草

2026-10-16 13:49:53 +08:00

test_ledger_feedback.py

召回复核修正（后端）：人工节点不再挡召回、读不出召回卡记失败、旧版不再接着算、团队渠道一次召回只推一条、目录核对按数据源合并排队；账本接口带上召回标记，对账结果可以反馈

2026-10-16 22:16:58 +08:00

test_ledger_issue.py

出具、按需视图的每日上限改成先占额度再发起（用户拍板）：新增 cluster/quota——额度记在库里（rate_counters 按名字 + 本地日期一行），占一份是一句带条件的 UPDATE（没到上限才加一），两种库上都是原子的，这一天第一次占按库里已有的记录起算，发起被拒或出错就退回。出具去掉全站一把锁，只留同一（运行、工作流、版本）的去重锁，几份不同的出具可以同时发起；按需视图的锁缩回按缓存键（视图 + 参数）去重，每日上限改用这个应用的额度。补测试：20 个协程同时占正好到上限、按已有记录起算、退回再占；两个进程同时占正好到上限；三份不同的答案同时出具正好到上限、多出来的回 429

2026-10-19 12:57:38 +08:00

test_ledger_match.py

口径账本：合并查询的格照实写为什么没比对；账本测试按用例各用一个数据源隔开

2026-10-16 14:23:41 +08:00

test_ledger_projection.py

按行号取多行查询里的一格，重跑、核对时行序不定的照实标出来：sql_semantics.ordered / row_stable 认这一行重跑时还是不是同一行（最外层带 ORDER BY 的按位置认，一定只出一行的第 0 行认得住，别的行序不定）。口径账本的比对记下 ordered、one_row，指标标签按「同一行」认来自口径只在行认得住时成立，行序不定的标相关、写明原因；口径召回里两版都按行号取一格、查询又没有 ORDER BY 的指标记行序不定（changed 为空），召回待办上写「行序不定」，不按位置硬比；对账的多行对齐每一组先核对那一行的维度就是它，重跑时缺了一行、多出一行错位的记空值，不拿别的维度的数冒充

2026-10-19 10:01:05 +08:00

test_ledger_recall.py

召回里行序不定的指标不当「没变」（编排者拍板）：全部指标都行序不定的，结论写「核对不了（行序不定）」（召回批次的新状态 row_order），开召回待办请人核对，待办和通知的标题照实说没能核对，不在原答案上记「已核对，不影响」；部分行序不定的，已判定的照常判，行序不定的那几项在结论里列出（row_order_metrics），数没变时原答案的记账照样列出、问数据的轮次写「其中「x」行序不定，没能核对」。补测试

2026-10-19 11:54:08 +08:00

test_ledger_reconcile.py

对账视图测试跟上预选字段：只引用一列、没有逐格比的查询，options.suggested 为空

2026-10-19 10:05:38 +08:00

test_ledger_row_order.py

按行号取多行查询里的一格，重跑、核对时行序不定的照实标出来：sql_semantics.ordered / row_stable 认这一行重跑时还是不是同一行（最外层带 ORDER BY 的按位置认，一定只出一行的第 0 行认得住，别的行序不定）。口径账本的比对记下 ordered、one_row，指标标签按「同一行」认来自口径只在行认得住时成立，行序不定的标相关、写明原因；口径召回里两版都按行号取一格、查询又没有 ORDER BY 的指标记行序不定（changed 为空），召回待办上写「行序不定」，不按位置硬比；对账的多行对齐每一组先核对那一行的维度就是它，重跑时缺了一行、多出一行错位的记空值，不拿别的维度的数冒充

2026-10-19 10:01:05 +08:00

test_lineage_static_copy.py

静态地认指标出处也跨卡往下追：转抄同一张图里另一张口径卡的指标，按那个指标的式子接着认（最多 MAX_COPY_DEPTH 层），受管级发布检查、应用检查和运行时、证据面板同一套说法；被抄的卡按 caliber_from 固定在别处版本的照旧停在那张卡

2026-10-17 12:31:13 +08:00

test_lint_contract_report_from.py

…

test_lint_process.py

应用平台 BE-2 流程：待办服务（派给谁、any/all/quorum 汇总、条件 UPDATE 抢恢复、提醒升级超时驳回、审批接口改为垫片、存量补建），人工节点新配置与校验，写外部系统的动作流程（生效记录先写后发、确认卡哈希、结果未知挂起与核实、永不自动重发），重放豁免与升级安全测试，正式运行不许带图接着跑、接着跑不覆盖发起人（F2），运行来源，通知发送核心与渠道，入站签名钩子，process.* 检查，报销审批模板，假外部系统（含统一复核后的修复）

2026-10-14 20:05:23 +08:00

test_look_large.py

探查范围外、没有注释的表中文需求命不中：照实写进模块说明，加一条测试钉住

2026-10-17 11:53:54 +08:00

test_maintenance_fire_history.py

定时任务页认得数据源维护：触发历史列出建了的探查、剖析任务和没执行的步骤；「去数据源页设置」改链 #source-<id>（复核 W4R-05、W4R-04）

2026-10-16 22:02:09 +08:00

test_manage_api.py

…

test_markup_leak.py

…

test_masked_merge_queries.py

…

test_masked_metric_values.py

…

test_masking_excerpts.py

…

test_masking_opaque_sql.py

…

test_masking_reformatted_numbers.py

…

test_masking_star_renames.py

…

test_masking_table_functions.py

…

test_masking_tool_boundary.py

…

test_masking_values_and_show.py

…

test_masking_whole_rows.py

…

test_mcp_cache.py

应用平台 BE-1 治理底座：身份三种模式（off 默认 / local / oidc）、会话与 CSRF、中间件写入身份、角色与组与审计、按权限矩阵挂路由级依赖、运行与工件的读权限和 user 角色遮罩、reset-admin 找回；能力登记（同步、治理与乐观锁、发起快照、发布版本、作证判定）、登记的端点与平台执行器（分环境、演练、幂等头、身份断言、端点快照作证）、密钥加密与掩码、MCP 的 SSRF 与认证头、写入能力只进调用工具节点、正式运行里只读免审批的能力直接执行、四条 action.* 发布检查（含统一复核后的修复）

2026-10-14 20:05:23 +08:00

test_merge_engine.py

…

test_merge_node.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_merge_provenance.py

…

test_merge_sqlcheck.py

…

test_metric_comparability.py

分析入口的测试补真算子：test_analysis_e2e 加 agent 调波动基线（本周明显超出常规波动、历史新低，本期完不完整按现查的表范围判）、趋势、差异检验（逐行明细，华东的单笔金额高于华南）、可比性检查（两份查询各一周）各一次的端到端，台账、交回模型的那一段、复算逐字段相同都核；分析卡以合并查询为输入跑一次（输入写明 sqlite 方言、工件就是合并查询的快照）。test_analysis_card 的下钻样例 DRILL 原来 by 和 period 是同一列、真算子下会报错：shop 加渠道列（各地区两周的合计不变），DRILL 改成读华东按渠道的那次查询（drill_graph），另用真算子跑一遍下钻（闭合、主要来自线上、parent 是上一项的结论工件、复算一致）；夹具改用 scratch_source。过时的说明照实改：替身的用途、口径卡可比性挂钩里「还没有算子」的说法

2026-10-21 16:06:40 +08:00

test_metric_copy_lineage.py

转抄口径卡指标的出处跨卡往下追，对账、召回运行按追到底的结果判档

2026-10-17 12:05:12 +08:00

test_metric_lineage.py

口径卡分母为 0 时算不出来就是空值，和「缺少输入」分开说；指标清单按格式渲染。助手节点手册讲口径卡的那段写明分母可能为 0 时写「… if 分母 else None」、不要写 else 0，附示例；画布校验加一条提醒 metrics.zero_for_undefined（按语法树认：条件表达式一边有除法、另一边是常量 0，两边对调、套在 round 里、嵌套的都认）。输入都齐、计算式自己交回空值的指标多记 undefined: true（状态仍是 missing_input，按状态认的地方和老运行不受影响），清单、写作目录、引用解析不了的原因、运行对比、证据面板都说「算不出来（这组输入下计算式没有值，比如分母为 0）」；推演把它当不带值的字段。指标清单（{{ nodes.卡.text }}）改用卡上渲染好的 rendered：比率 0.0007 显示成 0.07%、金额带千分位，和报告里 [[m:]] 一致；有值却显示不出来的照实说，不拼原值

2026-10-20 10:04:53 +08:00

test_metric_no_data.py

应用实例页：成果没配出具契约时（印章上是「未声明出具契约」），本该降档的缺口照实写进印章的说明——口径卡里输入取自「查询区间里这张表没有数据」的列的指标、双盲复算的缺口（无法复算、审核人没采用原流程……）；配了契约的已经按缺口降档，不另写

2026-10-20 10:39:53 +08:00

test_metric_origin.py

端到端验收修复与指标出具：

2026-10-15 07:15:37 +08:00

test_metric_value_artifact.py

…

test_metrics_issuance.py

端到端验收修复与指标出具：

2026-10-15 07:15:37 +08:00

test_metrics_undefined.py

口径卡分母为 0 时算不出来就是空值，和「缺少输入」分开说；指标清单按格式渲染。助手节点手册讲口径卡的那段写明分母可能为 0 时写「… if 分母 else None」、不要写 else 0，附示例；画布校验加一条提醒 metrics.zero_for_undefined（按语法树认：条件表达式一边有除法、另一边是常量 0，两边对调、套在 round 里、嵌套的都认）。输入都齐、计算式自己交回空值的指标多记 undefined: true（状态仍是 missing_input，按状态认的地方和老运行不受影响），清单、写作目录、引用解析不了的原因、运行对比、证据面板都说「算不出来（这组输入下计算式没有值，比如分母为 0）」；推演把它当不带值的字段。指标清单（{{ nodes.卡.text }}）改用卡上渲染好的 rendered：比率 0.0007 显示成 0.07%、金额带千分位，和报告里 [[m:]] 一致；有值却显示不出来的照实说，不拼原值

2026-10-20 10:04:53 +08:00

test_microvm_kvm.py

…

test_model_budget.py

…

test_model_error.py

…

test_multiprocess_e2e.py

复核 R-b1（卡住但没死的进程被当成没了）：续租约挪到单独的任务、专用连接（不走连接池，不被同一拍别的活拖住）；进程间请求另起任务办，不在心跳里等收尾；新增 cluster/fence 自我隔离——离上次续上租约超过一个租约时长，或者这段执行属于上一次隔离之前，执行在写事件、写断点、开审批、发外部写入、后台任务写库之前就停手（Fenced 是 BaseException，节点里的 except Exception 拦不住），续租时发现续晚了就隔离：停掉手上的运行和后台任务、不写终态，换一个身份重新登记；运行收尾先占住那一行、属主不是自己就不写；别的进程按租约过期再多等一个租约时长才算不在了（两边中间留一段）；run_events 的 (run_id, seq) 改成唯一索引（存量库先数重复，有就照实记日志、这一次不建，不让启动失败）。补测试：卡住期间被接手之后不盖终态、不写事件、序号不重；被接手的那次在别处接着跑完只结束一次、后面那一步只跑一次；收尾按属主写；撞号被库拒绝；多进程端到端加 6b、6c（真 SIGSTOP / SIGCONT）

2026-10-19 13:15:56 +08:00

test_names.py

…

test_nested_loops.py

…

test_net_fake_ip.py

…

test_notify_channels.py

测试：随机名字不带数字——新增 tests/fixtures/names.letters（uuid4 的十六进制里数字换成字母，同 test_run_data_versions 的写法），dual_check_shop 的数据源名、盲算的调用编号，评测、应用说明检查、导入、遮罩、通知几处测试里拼进文本的随机名字都改用它（以前带着「330」「300」「48」这类数时撞上「文本里不许出现这个数」的断言）；test_eval_schedule 查通知里有没有数时先去掉 32 位编号和发送时间（随机的编号带过「310」）；test_null_not_null_values_fall_back_to_the_model_default 显式导入 app.db.models（单独跑时 schedules 还没登记进元数据，KeyError）。deploy.sh 注明内置库不用 copy-to-postgres 的 --direct-url

2026-10-19 15:16:54 +08:00

test_notify_digest.py

W3-d 收尾：关登录时不发汇总和到期提醒、分享页不下发入口表单、邮件标题去换行；测试互不干扰

2026-10-16 17:11:54 +08:00

test_notify_events.py

合入 W4-d 目录前端：数据目录的「变化」视图与处理动作、数据源角标、表详情「结构与取值变化」一节、数据源的定时维护（一条目标为数据源的定时任务）、后台任务条（探查、起草、剖析按服务端排队顺序）；打开 source.changed 订阅；指名数据源卡片统一用 #source-<id>

2026-10-16 22:30:09 +08:00

test_notify_mail.py

W3-d 复核 L2：使用者列通知渠道时拿不到全局、应用邮件渠道的收件地址

2026-10-16 18:20:52 +08:00

test_notify_run.py

测试：随机名字不带数字——新增 tests/fixtures/names.letters（uuid4 的十六进制里数字换成字母，同 test_run_data_versions 的写法），dual_check_shop 的数据源名、盲算的调用编号，评测、应用说明检查、导入、遮罩、通知几处测试里拼进文本的随机名字都改用它（以前带着「330」「300」「48」这类数时撞上「文本里不许出现这个数」的断言）；test_eval_schedule 查通知里有没有数时先去掉 32 位编号和发送时间（随机的编号带过「310」）；test_null_not_null_values_fall_back_to_the_model_default 显式导入 app.db.models（单独跑时 schedules 还没登记进元数据，KeyError）。deploy.sh 注明内置库不用 copy-to-postgres 的 --direct-url

2026-10-19 15:16:54 +08:00

test_openai_stream_usage.py

…

test_ops.py

复核 R-d4（升级前的 SQLite 备份只拷了应用库和断点库）：填报的记录表 records/**/*.db 也用 SQLite 的备份接口拷进同一份备份，相对路径照旧，目录 0700、文件 0600；库在 PostgreSQL 时不做这份（记录表跟着整目录备份）。deploy/README 写清这份备份含什么、不含什么（上传原件和版本库、工件库、附件、知识库、沙箱工作区、.secret_key 要整目录备份），恢复步骤加上记录表

2026-10-19 16:12:07 +08:00

test_p3_api_errors.py

多进程端到端验收：scripts/test-multiprocess.sh 用本机 postgres:16 起临时库，tests/test_multiprocess_e2e.py（缺省跳过，AGENTLAB_MULTIPROCESS_E2E=1）在上面起两个 uvicorn 工作进程，用演示模型跑七个场景——两个进程都登记、一个当班；运行由接到请求的进程认领，另一个进程上的流收得到实时事件和流式增量，同一个审批决定同时发给两边只执行一次，两边事件流不重不漏、封存核对得上；跨进程停止；定时只触发一次；全站一个名额时评测的作答运行排着队，后来的问数据运行先拿到名额；两个进程同时记同一本每日账不越过上限；强杀一个进程后在跑的运行被照实标中断、停在审批上的照常在另一个进程上批完、当班交接。顺带修：等名额时被停止也照实收成已取消（以前停在排队中）；当班的本地余量不超过租约的四分之一（租约调短时一直不当班）；启动清理上传半成品时没有别的活着的进程就全清；文件锁守卫的几项测试只在 SQLite 跑；问数据事件日志清理那一拍不带时刻时按现在算

2026-10-19 12:03:35 +08:00

test_personal_apps.py

系统派生的运行不进使用统计（总方案 X1、X2，细案 01 做法 4）：评测一跑，聚类、白名单、目录使用热度都会被刷高

2026-10-16 10:18:12 +08:00

test_plain_layer.py

普通用户建应用（后端）：

2026-10-15 12:09:29 +08:00

test_positional_masks_elsewhere.py

端到端验收修复与指标出具：

2026-10-15 07:15:37 +08:00

test_process_actions.py

结果未知自动核实的测试先等排上查询再看记录：运行先挂起、runner 再安排核实（actions.on_unknown），并行跑时测试会在中间读到还没排上查询的记录。测试的竞态，产品行为不动

2026-10-19 11:58:45 +08:00

test_process_hooks.py

集成收尾：前端约定写入后端实际返回的形状（应用详情只对 manage 给草稿、补算计划与结果、按名字的钩子行、能力字段审阅），去掉多种字段名都认的兼容解析；钩子按（应用, 名字）、应用助手对话按（应用, 建立人）加唯一索引，迁移前去重，插入改在保存点里、撞上就改用已有的那一行；口径卡固定的版本也须已发布且未退役，记级别之前有正式运行凭据的老版本启动时补记为已发布；证据面板和应用视图按列名遮端点快照（同一个函数），不再整张表遮掉；待办计数带上最新一条的时间，新待办通知不再漏；非管理员的搭建者不出模型接入的改动按钮

2026-10-14 22:08:33 +08:00

test_process_tasks.py

驳回不再记成失败（后端）：人的驳回收成 cancelled + end_reason=rejected，消费方都读这一个字段

2026-10-16 10:14:27 +08:00

test_profile_dialect_golden.py

取值观察：业务日期有未来值时不再误报量跌、缺天；「今天」统一按服务端所在时区

2026-10-17 07:59:19 +08:00

test_profile_dialect_units.py

ENUM / SET 只认 MySQL 带括号的写法；PostgreSQL 的域记底下的类型

2026-10-16 12:06:24 +08:00

test_profile_facts.py

大库的 look 预筛与按需加入、剖析事实四处一致、有效记录条件按 quote_name 加引号的测试；对象索引批量更新改走按表的 executemany

2026-10-16 14:26:04 +08:00

test_provenance_acceptance.py

…

test_provenance_api.py

…

test_provenance_contract.py

…

test_provenance_db.py

…

test_provenance_unchanged.py

…

test_provenance.py

…

test_provider_ref_checks.py

…

test_provider_ref_landing.py

…

test_provider_ref_runtime.py

报告撰写节点加「分析说法核对」（analysis_claims：off / check / strict，缺省 check）和「分析范围」（analysis_scope：auto / off，缺省 auto），画布校验和执行时报同一句话（report.analysis_claims_invalid / analysis_scope_invalid），界面叫法进 labels，运行对比登记这两项。check：判断词没挂对分析结论、原因没有依据的句子交回写作者重写一次（不按最多重写次数反复），仍有的标在报告里、写一条日志 report_analysis_claims，不影响档位；strict：按最多重写次数重写，仍有的写进产出的 issuance_gaps（另记 analysis_gap）；两种都不让节点失败（不挡生成）；off 不核、写作规则和文档一字不变；升级前发起的运行照旧。写作者角色改成「挑重点、组织结构、说清变化；有分析结论时说清变化来自哪里；原因只按证据写」，写作规则按目录里有没有分析结论各加一段判断词规则，重写请求列出违规和修法；这次有分析结论、取值 auto 时每一稿文档都带系统写的 analysis_scope。产出和 report.checked 记下处置。几个测裁判、结论句策略、审计表的用例写作者那句「增长主要来自新客」没有拆解可挂，把分析说法核对关掉

2026-10-21 13:12:15 +08:00

test_provider_ref_wording.py

…

test_provider_resolution.py

…

test_public_url.py

W3-d 邮件渠道、待办汇总、访问密钥到期提醒（后端）

2026-10-16 16:21:41 +08:00

test_publish_check_api.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_publish_plan.py

自由形蓝图（后端）：按导入的图列出「谁来做」，只定由谁做；没绑时 bp.people_unbound 指向那张卡片

2026-10-16 10:34:18 +08:00

test_publish_sqlcheck.py

门禁 G3 加一条：受管级别的报告撰写节点要把「分析说法核对」设为严格（REPORT_POLICY 加 analysis_claims: strict，没写时运行时是 check、只标注）。受管级别挡住发布、已发布级别只警告，写错的值交给校验；已经发布的版本照常运行（按缺省的 check 核），下次发布才按新规则查。同一份要求自动跟到自动修复（一键写明）、一键升级成受管、按口径出具起草的报告节点；自动修复「不许放宽」的判断认这一项（从严格改回去算放宽）；白话补一句分析说法；模板 ⑨ 的报告节点补上这一项，拿来照旧能发布成受管。各处「受管要求都满足」的图（测试夹具）跟着补上这一项

2026-10-21 13:13:04 +08:00

test_query_column_types.py

…

test_query_coverage.py

覆盖检查：现查没成功（大表全表 MIN / MAX 超时、库一时连不上）也记 LIVE_TTL_S，期间同一张表直接退回剖析、取值观察，不再每次白等 PROBE_TIMEOUT_S 秒（测试 test_a_failed_probe_is_not_retried_for_a_while）；方言容器集成测试（scripts/dialect_it.py）加一段覆盖检查：只存当天的滚动表（DATE 列，MySQL / MariaDB 另有按文字 'YYYYMMDD' 存的），按运行当天现算的上周区间判成没有数据、区间包含当天只是别的条件筛空的不报，查询后和助手自查两个入口都核——PostgreSQL 16、MySQL 8.4、MariaDB 11、Oracle Free 23 全过

2026-10-20 10:58:20 +08:00

test_query_deadline.py

…

test_question_vectors.py

问题聚类的向量只取一次：评测页「口径命中与重复度」不再按窗口把问题重发给向量模型（复核 W4R-14）

2026-10-16 21:41:30 +08:00

test_readonly_source.py

…

test_recipe_acceptance_p3.py

多进程端到端验收：scripts/test-multiprocess.sh 用本机 postgres:16 起临时库，tests/test_multiprocess_e2e.py（缺省跳过，AGENTLAB_MULTIPROCESS_E2E=1）在上面起两个 uvicorn 工作进程，用演示模型跑七个场景——两个进程都登记、一个当班；运行由接到请求的进程认领，另一个进程上的流收得到实时事件和流式增量，同一个审批决定同时发给两边只执行一次，两边事件流不重不漏、封存核对得上；跨进程停止；定时只触发一次；全站一个名额时评测的作答运行排着队，后来的问数据运行先拿到名额；两个进程同时记同一本每日账不越过上限；强杀一个进程后在跑的运行被照实标中断、停在审批上的照常在另一个进程上批完、当班交接。顺带修：等名额时被停止也照实收成已取消（以前停在排队中）；当班的本地余量不超过租约的四分之一（租约调短时一直不当班）；启动清理上传半成品时没有别的活着的进程就全清；文件锁守卫的几项测试只在 SQLite 跑；问数据事件日志清理那一拍不带时刻时按现在算

2026-10-19 12:03:35 +08:00

test_recipe_acceptance.py

…

test_recipe_accumulate.py

…

test_recipe_ai.py

…

test_recipe_checks.py

…

test_recipe_compare.py

…

test_recipe_confirm_p3.py

…

test_recipe_confirm.py

…

test_recipe_contract.py

交叉表支持按文字导入的指标（如「高峰时段」一行写着「18-19」），堵上占位符陷阱：配方的 measures 分段加 text_measures（标签 → text / hour_range），落成文字列（时段存规范写法），空格、公式、占位符照块的取值规则，数字、日期、解析不了的时段报 value_not_text / value_not_hour_range；规则起草遇到无标题指标块里整行是文字的行（标签不带词表单位）按文字指标起草，并出卡片和问题要人确认（「不是」就去掉，回到按数字导入、试运行拒收），确认清单加 text_measure 项，前后对照报类型和存法变化；数值区不合格的格一行合成一条起草失败（不再一行 30 条）。陷阱：以前照「请添加占位符」把「18-19」加成占位符，整格静默存成空值、干跑照样通过——静态校验拒收含数字的占位符（placeholder_digits，重放和沿用现行配方的放行），value_not_number 的下一步按格子情况写：整行文字的提示改「指标类型」并给修复按钮 declare_text_measure，含数字的不再提示加占位符；标签带单位的拒按文字导入（text_measure_unit），文字列不能写单位（unit_on_text）。配方面板每个指标多一个「指标类型」下拉（数字 / 时段 / 文字）。默认值不进规范形式，已存配方的哈希不变。测试 tests/test_recipe_text_measures.py（合成夹具，假名）；check-manage 加指标类型三项

2026-10-20 11:41:28 +08:00

test_recipe_diff_p3.py

…

test_recipe_diff.py

…

test_recipe_e2e.py

…

test_recipe_engine_crosstab.py

…

test_recipe_engine_list.py

…

test_recipe_engine_messages.py

交叉表支持按文字导入的指标（如「高峰时段」一行写着「18-19」），堵上占位符陷阱：配方的 measures 分段加 text_measures（标签 → text / hour_range），落成文字列（时段存规范写法），空格、公式、占位符照块的取值规则，数字、日期、解析不了的时段报 value_not_text / value_not_hour_range；规则起草遇到无标题指标块里整行是文字的行（标签不带词表单位）按文字指标起草，并出卡片和问题要人确认（「不是」就去掉，回到按数字导入、试运行拒收），确认清单加 text_measure 项，前后对照报类型和存法变化；数值区不合格的格一行合成一条起草失败（不再一行 30 条）。陷阱：以前照「请添加占位符」把「18-19」加成占位符，整格静默存成空值、干跑照样通过——静态校验拒收含数字的占位符（placeholder_digits，重放和沿用现行配方的放行），value_not_number 的下一步按格子情况写：整行文字的提示改「指标类型」并给修复按钮 declare_text_measure，含数字的不再提示加占位符；标签带单位的拒按文字导入（text_measure_unit），文字列不能写单位（unit_on_text）。配方面板每个指标多一个「指标类型」下拉（数字 / 时段 / 文字）。默认值不进规范形式，已存配方的哈希不变。测试 tests/test_recipe_text_measures.py（合成夹具，假名）；check-manage 加指标类型三项

2026-10-20 11:41:28 +08:00

test_recipe_engine_p3.py

列表中间像小计的行：照常导入、要人确认，带「改作小计核对」的修复按钮

2026-10-16 11:16:33 +08:00

test_recipe_fixes.py

…

test_recipe_imports_p3.py

…

test_recipe_imports.py

测试：随机名字不带数字——新增 tests/fixtures/names.letters（uuid4 的十六进制里数字换成字母，同 test_run_data_versions 的写法），dual_check_shop 的数据源名、盲算的调用编号，评测、应用说明检查、导入、遮罩、通知几处测试里拼进文本的随机名字都改用它（以前带着「330」「300」「48」这类数时撞上「文本里不许出现这个数」的断言）；test_eval_schedule 查通知里有没有数时先去掉 32 位编号和发送时间（随机的编号带过「310」）；test_null_not_null_values_fall_back_to_the_model_default 显式导入 app.db.models（单独跑时 schedules 还没登记进元数据，KeyError）。deploy.sh 注明内置库不用 copy-to-postgres 的 --direct-url

2026-10-19 15:16:54 +08:00

test_recipe_mutations.py

…

test_recipe_notes_p3.py

2026-10-16 11:09:39 +08:00

test_recipe_notes.py

…

test_recipe_p5_e2e.py

2026-10-16 11:09:39 +08:00

test_recipe_p5.py

配方导入只把 .csv / .tsv 当 CSV 读；网页、XML 冒充的 Excel 照旧拒收并说清楚

2026-10-16 12:23:19 +08:00

test_recipe_perf.py

…

test_recipe_select.py

2026-10-16 11:09:39 +08:00

test_recipe_suggest.py

交叉表支持按文字导入的指标（如「高峰时段」一行写着「18-19」），堵上占位符陷阱：配方的 measures 分段加 text_measures（标签 → text / hour_range），落成文字列（时段存规范写法），空格、公式、占位符照块的取值规则，数字、日期、解析不了的时段报 value_not_text / value_not_hour_range；规则起草遇到无标题指标块里整行是文字的行（标签不带词表单位）按文字指标起草，并出卡片和问题要人确认（「不是」就去掉，回到按数字导入、试运行拒收），确认清单加 text_measure 项，前后对照报类型和存法变化；数值区不合格的格一行合成一条起草失败（不再一行 30 条）。陷阱：以前照「请添加占位符」把「18-19」加成占位符，整格静默存成空值、干跑照样通过——静态校验拒收含数字的占位符（placeholder_digits，重放和沿用现行配方的放行），value_not_number 的下一步按格子情况写：整行文字的提示改「指标类型」并给修复按钮 declare_text_measure，含数字的不再提示加占位符；标签带单位的拒按文字导入（text_measure_unit），文字列不能写单位（unit_on_text）。配方面板每个指标多一个「指标类型」下拉（数字 / 时段 / 文字）。默认值不进规范形式，已存配方的哈希不变。测试 tests/test_recipe_text_measures.py（合成夹具，假名）；check-manage 加指标类型三项

2026-10-16 11:09:39 +08:00

test_recipe_text_measures.py

2026-10-20 11:41:28 +08:00

test_recipe_validate_p3.py

2026-10-16 11:09:39 +08:00

test_recipe_validate.py