242 Commits

Author	SHA1	Message	Date
ThearchyHelios	ead8ea216b	数据目录起草（前端）：表结构里已经没有的表（只剩目录）不再给「重新起草这张表」「补充起草要求」——服务端只会把它记成已跳过。表详情顶部照写上次起草的结果（没写全的原因、留空了几列），不再建议补充起草要求后重新起草，写明「表结构中已没有这张表，不能重新起草」；清单上留空列的轻提示照旧，悬停里不再建议重新起草。起草设置收到的预先选好的范围（表详情的「补充起草要求」、结果里的「重新起草这几张表」）里的表已经不在表结构里时不再退回别的范围：那一项照旧选着，写明「表结构中已没有这张表，不能起草」（只少了几张时写其中几张不会起草），不能开始，也不默认勾用模型、不把焦点放进起草要求——以前退到「使用次数最多的 20 张表」还勾着用模型，以为只起草这一张，实际按别的范围起草了；选的那一项不在了时，单选框照实际起草的那一项勾。check-catalog 新加一节：只剩目录的表的清单提示与详情；打开详情以后表才没了（清单重取了、详情没重新载入）时「补充起草要求」打开的设置；重新打开后不再给两个按钮。check-all 里数据目录的耗时按实测改成 140 秒	2026-10-13 21:13:15 +08:00
ThearchyHelios	b91a652efe	数据目录起草（前端）：模型拿不准、留空的列（中文名和含义都没给）单独写出来，不算没写全、表照样是已完成。起草对话框逐表写「12 列模型拿不准、留空了」，列名悬停看得到、也可以展开（最多 5 个，没列全写一共几列）；结束后写合计「共 13 列模型拿不准、留空了（2 张表）」和办法——在起草要求里补充缩写和术语的含义，再重新起草这几张表，已有的内容不会丢；「重新起草这 N 张表」回到设置，范围就是这几张、勾着用模型、焦点在起草要求，补完再开始；结束后默认列出的表连同有留空列的（「只看未写全、有留空列的表」）；关着对话框时结束的提示也接着写留空的列；设置阶段的「上一次起草」都写完了、只是有留空列的也提，写明几列。清单上上次起草有留空列的表一行淡色轻提示（不是失败标记，和失败、部分完成的标记分开；还在起草的那一次不算「上次」）；表详情顶部同样提示（只有留空列时是提示、不是失败；部分完成又有留空列的并在一条里），给「重新起草这张表」和「补充起草要求」（打开起草设置，范围只有这张表）。类型加 CatalogDraftTask.blank_columns、blank_sample，CatalogDraftJob.blank_columns，last_draft.blank_columns（老服务端没有，按 0）。check-catalog 新加一节覆盖逐表与汇总、展开列名、默认列表、清单轻提示（颜色同次要信息、不是警告色）、进行中不算「上次」、回到设置重新起草（先存起草要求再建任务）、结束提示、表详情的两个按钮，窄屏展开列名一并量；check-all 里数据目录的耗时按实测改成 130 秒	2026-10-13 20:30:18 +08:00
ThearchyHelios	a0b06f93c4	数据目录起草（前端）：调用接连没写出来时，进行中醒目显示服务端给的提醒（job.notice）——提醒的样式、不是错误，写在进度条下面；关掉对话框时目录页上方的进度也带着这一行（全文在悬停里）；好转后服务端清掉就收起，任务结束后不再显示。用量那一行接着写没写出来、超时的次数（没写出来的次数里含超时，写成「没写出来 4 次（其中超时 3 次）」，不读成两个数相加），有超时时写明「超时的调用不计用量，实际用量可能更多」；额度用完、超时多了服务端把之后的段缩小时写明「之后的段每段最多 20 列」。类型加 CatalogDraftJob.part_columns、notice，usage 加 timeouts、failed_calls（老服务端没有这几个键，按 0 和 null 处理）。check-catalog 的假服务端跟着给这几项，新加一节覆盖提醒的出现与消失、超时和没写出来的次数、段缩小的说明、任务结束后提醒收起，窄屏的起草弹窗和上方进度带着提醒一并量；宽表没写出来的原因照新写法写明列的范围（第 3 段（promo_attr_19 到 promo_attr_43，共 25 列））	2026-10-13 20:26:52 +08:00
ThearchyHelios	0dbfeffb23	check-catalog：409 之后「取的是进行中的那一个」原来恒为真（计数 >= 0），改成等到确实在取那个任务的进度；补「任务进行中离开数据目录页（页内跳转，页面卸下）以后不再取进度」，之前只查了结束以后不再取；设置阶段先等上一次起草取回来再让别处建任务，免得它晚到、取回的已经是进行中的任务而走不到 409。假服务端的说法照后端的原话：起草模型用不了是「无法由模型起草数据目录」（原来还是「由助手」），已有任务、任务不存在、已经结束、没有可重试的表、起草要求超长同样对齐；起草要求的请求没有 guidance 这一项时同后端回 422；重试建的任务带 retry_of。types.ts 的 CatalogDraftJob 加可选的 retry_of（约定里没有、后端多给的，界面不用）	2026-10-13 16:34:46 +08:00
ThearchyHelios	f57c6e284b	数据目录起草的几处说法照服务端的实际做法改：点停止后写「正在停止：取消进行中的模型调用，正在写入目录的表写完后停止…」（服务端马上停掉进行中的调用、只等手上那张表写完，不是等当前这次调用结束）；任务整体出错时原因照服务端的原话在「起草失败」下面写一次（服务端的原因有的自带「起草任务出错：」开头，界面不再套一层），服务端给没结束的表记的同一句不再逐表重复（服务重启中断同样），各有原因的照写；「只重试失败的表」没建成和开始时同一个说法——起草模型用不了（服务端重试也回 409 catalog_draft_model_unavailable）照原样写那句话、长句不再拆成「标题：原因」，别的写「未能开始起草」；提示里原因为空时不留冒号。check-catalog 先补会失败的检查：停止的说法、重试时起草模型用不了、任务整体出错（原因只写一次、逐表不重复、都能重试），服务重启中断的逐表不再重复原因；假服务端的中断任务照后端记上同一句原因	2026-10-13 16:34:29 +08:00
ThearchyHelios	f4ef5919bd	数据目录：正在编辑一张表时，它的「重新起草这张表」先不给点并写明先保存或取消——起草会写进这张表，编辑中的保存就会撞上版本冲突；check-catalog 补一项	2026-10-13 15:34:12 +08:00
ThearchyHelios	31caf02323	设置页加「起草模型」一节（前端）：数据目录的「用模型起草」和按配方导入表格时的 AI 起草用的模型，接入、模型两项照核查模型的做法——两项都留空跟随助手的模型，只填模型时写明按模型名用哪个接入，存着的接入不存在、已停用时在那一格下面说清用模型起草会报错，换接入时清掉不属于它的模型；和其余设置共用保存条，改了才整组写 catalog_draft（空着的存 null），服务端按项拒收（422，field 为 catalog_draft.provider）时整句落到那一格、焦点移过去；老服务端没有这一组时不显示。check-manage 加一节覆盖	2026-10-13 15:25:27 +08:00
ThearchyHelios	90a560d07e	数据目录起草改成后台任务（前端）：对话框选范围、写起草要求和本次补充说明后建任务，之后显示任务的进度和结果——总进度、新增 / 更新 / 删除合计、逐表状态、宽表的段进度、没写全的原因；可以停止、在后台继续，关掉对话框任务照常进行，目录页上方显示一条进度，点开回到对话框，结束时提示并可查看结果；结果里只列没写全的表，「只重试失败的表」新建只含失败、部分完成、已停止的表的任务；服务重启中断的任务写明原因、同样能重试；已有任务（409）转去显示进行中的那一个，起草模型用不了（409）留在设置阶段写明原因；起草要求改过先存再建任务，写明用的是哪个起草模型、数据源说明也一并交给模型；清单上标出上次起草失败、部分完成的表并写原因，表详情里给「重新起草这张表」；进行中每 1.5 秒取一次，取回的状态只往前走。check-catalog 用假的任务接口覆盖这些（任务怎么往前走由检查自己推），旧的同步起草检查换掉	2026-10-13 15:24:57 +08:00
ThearchyHelios	06b2c2b8ae	合入报告导出为自包含 HTML（数字点得开口径、来源、计算方式）与可验证报告数字详情里的口径卡一节；和可验证报告的遮罩改造合并：口径卡只给 id 的规则（有指标的值取自遮罩列、文档里写成「已遮罩」的）照旧，随文件附带的卡才附上它的输入指向的查询快照；数字详情保留显示文字核对和超过 2^53 的数照 JSON 原文显示，口径卡一节里输入的值同样照原文；样本页从 16 份变成 17 份	2026-10-13 10:03:24 +08:00
ThearchyHelios	7cec3079f0	合入期 5 验收修复 M2：证据面板与推演按 SQL 认出改了名字的遮罩列；推演里取自遮罩格的指标不露原值；报告自查拦下引用遮罩列的格子（按列名对整个数据源生效，和证据面板同一个口径）；结论句裁判的摘录按快照逐份遮确定取自遮罩列的列；片段接口在没开结论句裁判时照实说；遮罩分析按快照工件 id 缓存	2026-10-12 14:17:45 +08:00
ThearchyHelios	1cfa5a524d	M2 复核第 4 轮：报告自查认遮罩列和证据面板同一个口径，哪张表（含视图）里叫这个名字的列都算；结论句裁判的摘录按快照逐份遮确定取自遮罩列的列；没起别名、盖住全部结果列的表达式算确定取自遮罩列，值照收 ... 第 3 轮的「遮罩表」推断和退回的裁判摘录各开了一个口子，收值时又把按位置认得出的列丢了： - 报告自查去掉「遮罩表」推断（_mask_owners）。数据源的 mask_columns 只认列名、不支持写成「表.列」，按列名在整个数据源上 生效：引用的那一格按 SQL 认出取自任何一张表里叫这个名字的列就记 masked_cell，视图（customer_spend.name）、没有第二个 遮罩列的表（employees.name）、门店名（stores.name）都算，和证据面板的遮法一致。以前经视图引用客户姓名、引用店员姓名， 正式运行照常成功，姓名写进了报告。SQL 血缘只用来点名出处，和排除值确实取自普通表别的列的（SELECT region AS phone FROM stores）；视图、表结构里没有的表、写了别的库名的表、没标 is_view 的老表结构、没有冻结表结构的快照看不出列的出处， 照算（_frozen_schema 只把 is_view 明写为 false 的表当普通表）。违规说明照实写取自哪张表的哪一列：「列「store」按 SQL 认出取自 stores.name，数据源对列名「name」设置了遮罩（按列名对所有表生效）」 - 交给结论句裁判的摘录按快照逐份遮（api/evidence.py 的 _judge_loader）：每份快照里确定取自遮罩列的列（_mask_sets 的 sure）并进交给 judge.prepare 的那一份快照的 mask_columns（工件本身不动），裁判照它自己的办法遮掉，judge.py 不用改。 c.phone AS tel 的号码不再进摘录；不按数据源名合并（另一份快照里同名、取自门店热线的列照给），不用宁可多遮的 hidden （整份遮的快照、只数个数的列照给）。按需裁判和报告撰写节点里当场裁判同一个函数。摘录变了的句子复用键随之变，此前 判过的会重判一次 - 收「这次运行查到过的遮罩值」：_sure 以前凡是要遮的列盖住了全部结果列、名字又对不上，就当认不准、整份算， SELECT UPPER(phone) FROM customers 一个值都收不到，证据面板之后照原样显示 SQL 里写着的号码。现在结果后面垫一列再认一遍 （_whole），垫的那一列也算进来的才是整份算的；按位置认得出的照收，整份遮的照旧只遮显示、不收值 测试：test_report_masked_owners.py 改名 test_report_masked_any_table.py 并按新口径改写（经视图改名 / 不改名、店员、门店名、 客户名真跑判失败且成果里没有值；* 展开、WITH、UNION、视图里改成遮罩列名字的列、没有表结构、没标 is_view、表结构里没有的 表、写了库名的表）；新增 test_judge_excerpt_masks.py（按需、当场两条路的摘录都不给改了名字的号码列，同名的门店热线照给； 没起别名的 UPPER(phone) 摘录也不给）；test_evidence_mask_memo.py 加没起别名的表达式照收值；违规说明的断言跟着改	2026-10-12 13:50:31 +08:00
ThearchyHelios	65d6a1e63c	M2 复核第 3 轮：报告自查只查引用、别的表里同名的列不算；裁判摘录退回只按数据源设的遮罩列；收遮罩值只收确定取自遮罩列的值；遮罩分析和收到的值按快照工件记在进程里 ... 第 2 轮的按值自查和面板那套宁可多遮的认法带进了误判，正式运行因此失败，代价远大于收益，这一轮回到规格原意： - 报告自查去掉按值在正文里找遮罩值（engine/evidence.py 的 masked_values、report.py 的收值）：两个字的姓名会撞上「销售 高峰」这类常用词，同名列的值会撞上门店名；照抄成正文的号码本来就会被「数字没有出处」拦下。时间线日志 report_masked_cell 不再带 written，decode.ts、terms.ts、证据审计的 CSV 回到「引用了遮罩列」一种说法，check-decode 同步 - 自查认引用时从 _mask_sets 的 sure 起，再按 SQL 血缘（sqlglot.lineage，按快照里冻结的表结构）核一遍值取自哪张表的哪一列 （api/evidence.py 的 _cited_masks / _owned_columns）：遮罩列不带表名，同名的列在几张表里都有、其中有的表另有别的遮罩列时 （customers 有 name 和 phone，stores 只有 name），只认那几张表，门店名不算客户姓名；值根本不取自遮罩列的（region AS phone）也不算。认不出出处的照算，没探查过表结构的照列名认。违规说明点名它取自的那一列遮罩列 - 交给裁判的摘录退回 M2 之前的做法，只按数据源设的列名遮（删掉 _judge_masks）：并进面板那套宁可多遮的列后，整份遮的快照、 只数个数的列从摘录里消失，被引用的金额、人数裁判看不到。按需裁判和节点里当场裁判都改回 - 证据面板、推演收「这次运行查到过的遮罩值」只收 sure 的列（_snapshot_secrets，同 masking 收值的口径）：SQL 认不准、整份 遮的快照只遮显示，里面的区域名、金额不再收成遮罩值 - 按快照工件 id 在进程里记下遮罩分析和收到的值（_SnapshotMemo，键里带数据源现在设的遮罩、在不在、类型，设置改了不拿旧的； 只记读得出来的快照，存取加锁，分析结果冻结、交出去的值另抄一份）：之后点开片段、推演都不再把全部快照读盘、复验、分析， 只读这一步要显示的那一份。30 份 500 行的快照，第一次约 0.7 秒，之后不到 1 毫秒 测试：新增 test_report_masked_owners.py（高峰、门店名写成文字照常出具，照抄号码由数字核对拦下，引用门店名不算、引用客户名算， 同一条查询里两张表的同名列、只设 name、* 展开、WITH、UNION、没有表结构、表值函数）、test_evidence_mask_memo.py（整份遮 的快照不收值、只读一次只分析一次、设置改了重新收、推演共用、再点开片段只读本步快照）；裁判摘录改测被引用的金额和计数 都在摘录里；按值自查的用例改成不按值认的回归	2026-10-12 12:33:32 +08:00
ThearchyHelios	ce4be9cc8f	M2 复核第 2 轮：报告自查按值认出正文里写着的遮罩值，只数个数的列不再判违规；遮没遮核对不了的输入写「无法核对」；整句面板挂的依据按证据图的标签写 ... - 自查按值认（engine/evidence.py 的 masked_values，report.py 的 _MaskedCells）：写作目录里确定取自遮罩列的值出现在正文里——照抄成文字（姓名这类文字列数字核对管不到）、写成数字（换了写法的长号码组装时被拆成几个数字片段，按整句认）、经指标带出来（[[m:phone_raw]] 的值就是号码）——记一条 masked_cell（by_value），不带值，交回写作者时附上值换成「已遮罩」的那一句。只收确定取自遮罩列的列、不收分档标签；运行输入里写着的值是发起运行的人自己填的，不算。只读数据源现在设了遮罩的快照，认引用时读过的不再读，没设遮罩的运行一份都不读 - 时间线：日志 report_masked_cell 多带 written（其中按值认出的几处），标题分「引用了…格子」「写进了…值」「引用、写进了…」；缺口、日志按两种分别说；违规清单、CSV 的叫法改成「写进了遮罩列的值」 - 只数个数的列（COUNT(*) FILTER (WHERE phone IS NULL)、SUM(phone IS NULL)、AVG(phone IS NOT NULL)、SUM(amount) FILTER (WHERE phone IS NOT NULL)）：认遮罩列的那一套把 FILTER 条件、汇总里的真假条件当成值的来历，数据质量报告引用「手机号缺失的人数」在正式运行里判失败。自查认之前先改写（_counted：FILTER 同 WHERE 去掉，汇总里的真假条件改成 CASE WHEN … THEN 1 ELSE 0 END），不判违规；证据面板、推演照可验证报告的认法多遮（只影响展示），根上的改法在 masking 里 - 证据面板：遮没遮核对不了的输入（快照、取值链上的产出读不出来），值和代入式里写「无法核对」，不写「已遮罩」，数据源可能根本没设遮罩 - 整句面板「挂的依据」不再直接读文档目录里的「名称 = 渲染值」：按证据图的标签写（服务端已把用到遮罩列的指标值换成「已遮罩」），证据图没回来时指标只写名字 - on_demand：当场裁判过、文档里却压根没有这句的判定时，不说「原因见判定」 - 测试：合并查询自查的用例补上拼接、upper、WITH；推演对整行、下标不是字面量的一格说「用到了遮罩列」（顺着取值链认出来的，不是按值猜的）；计数指标 cnt 的原值照给；SQL 认不准、只数个数的反例	2026-10-12 10:48:19 +08:00
ThearchyHelios	25011d074b	M2 复核第 1 轮：合并查询按合并 SQL 认遮罩列，报告自查只拦确定取自遮罩列的格子，推演和证据面板对指标原值同一个判断，面板认法和可验证报告同一个函数 ... 接手被限流打断的第 1 轮修复，补完后提交。处理的复核发现： - 合并查询：合并 SQL 里对遮罩列改名、套函数、拼接、汇总、经 WITH 转一道得来的结果列，以前没有逐格来历就认不出，片段接口、勾行接口原样给出号码、报告自查也漏判。现在 _merge_mask_sets 把各输入要遮的列名当作遮罩列、按 SQLite 读法认合并 SQL；输入快照读不出来又可能带着遮罩的，它的列全部当遮罩列 - 报告自查：_mask_sets 分出 hidden（面板、推演按它遮，宁可多遮）和 sure（自查按它判违规）。SQL 认不准、整份算进来的列，只装着分档标签的列不再判 masked_cell，正式运行不会因为和遮罩列无关的金额判失败；sure 按数据源自己的方言认 - 判失败的下一步：违规里有引用遮罩列的，只说去改写作指令，不建议换模型、不建议先改成标注 - 时间线、缺口不再说「这些值会随报告出具」「出具已按缺口降档」：探索运行、没设出具契约的成果不出具，只说已记为缺口 - 只读引用到的快照：报告节点组装好一稿之后只认正文引用到的那几份查询快照，认过的不再读 - 审计表、导出的 CSV 给 masked_cell 单列一行 - 推演和证据面板：指标原值给不给是同一个判断（recompute.withheld_value），输入分类同一套（input_origin 的 wide：整行、下标不是字面量的、整份结果都认）。数行数的 len(vars.res.rows) 两边都照给，str(vars.res.rows)、整行、数据整形取出来的号码两边都不给；遮没遮核对不了的写「无法核对」，不写「已遮罩」 - 认不出出处的输入按值认：值就是这次运行查到过的遮罩值的不给、不推演 - 证据图 evidence[].label 用到遮罩列的指标写「名称 = 已遮罩」 - 证据面板认遮罩列调可验证报告的那个函数（bundle/build.py 的 _derived_columns），再按数据源方言认一遍，可验证报告整份遮的面板不会照给 - 查询步骤的 SQL、合并 SQL、SQL 检查片段、合并警告里写着的遮罩值展示时换成「已遮罩」，底下写明只是展示时换的 - 交给裁判的摘录：按需裁判、节点内当场裁判都把 SQL 里改了名字的遮罩列并进数据源名下（_judge_masks） - on_demand：当场裁判过、这句没判成（触顶、出错、被截断）时照实说没判成	2026-10-12 10:17:40 +08:00
ThearchyHelios	265ba0c91d	报告导出为自包含 HTML（数字点得开口径、来源、计算方式）；可验证报告的数字详情补齐口径卡一节 ... 两件事，一条心：把「网页上点数字看得到的效果」带出系统外。 ① 报告导出：新增 GET /api/runs/{run_id}/report.html（app/report_export：build + 模板 + 浏览器端脚本）。 正文由服务端按报告文档的块、句、片段渲染成 HTML——不执行脚本也读得到整份报告（附件预览常常不执行脚本）； 执行脚本后，带出处的数字、无证据的数字、可疑的表名字段名都点得开，面板是网页上证据面板同一个拼法的 出处链（api/evidence._chain）：指标步骤带口径卡名与版本、原式、代入式、每个输入取自哪次查询的哪一格、 复算、双盲复算；查询步骤带 SQL 和被引用的行；数据源遮罩列照网页上的规矩写「已遮罩」。封存状态逐项标明； 没封存的运行照常导出（和网页上读报告一个道理）。同样的引用共用一条链，长报告不把整份快照抄几十遍。 入口在问数据答案和运行详情成果上的「导出」（带证据的报告给 HTML，Markdown 留一个小的；旧运行照旧只有 Markdown）——api.reportExport + AssistantStream 的 AnswerActions。 ② 可验证报告（bundle）的数字详情补齐：点开数字原来只有出处和值，现在多一节口径卡——指标（名 + id）、 单位、原式、代入式、输入（取值 ← 路径、取自哪次查询的哪一行哪一列）、复算；输入指向的查询快照也随文件 附带（遮罩规则同嵌入那一套，build._card_input_queries），④ 引用链按「已核对的口径卡的输入」认它们 （哈希对不上的卡不认，免得替被改过的卡圆）。收件人不连服务也能看到每个数怎么算出来的。 测试：后端 tests/test_report_export.py（真跑运行导出，正文、出处链、遮罩、只读、404/409、共用链）； bundle_samples 的口径卡换成带原式/代入式/输入/复算的真实形状，另加 metric-only 样本页（只引用指标的 报告，快照从口径卡的输入这一条路附带）；check-bundle 断言数字详情和这条引用链，加上篡改；新增 scripts/check-report-export.mjs（真导出断网点开、不执行脚本也读得到、成果上的导出按钮、旧答案没有 HTML 按钮、409 提示），挂进 check-all。README 补「导出两份」一节。全量 pytest 通过；check-bundle、 check-report-export、check-stream、check-evidence、check-chat 全部通过（check-runs 5 项失败为基线 上就有的沙箱数据形态问题，与本次无关）。	2026-10-10 12:59:21 +08:00
ThearchyHelios	6d4f452f36	M4 复核修正：规范化后不同的行带上所在的子句，ON 挂在 JOIN 那一行的末尾 ... 复核发现上一版把 ON 单独排成一行后，「规范化后不同的行」丢了关联条件的上下文：只差一个关联条件时那一栏只剩 「AND refunds.state = 'done'」，有两个 LEFT JOIN 时看不出是哪个 JOIN 的，也看不出是关联条件还是筛选条件；两边 JOIN 的表不同时，两边都有的那一行「ON」被 difflib 当成相同的行吃掉，表名下面直接跟条件；关联子查询换成两张表时也一样。 这几种都只给兜底说明，审核人全靠这一栏逐行对照。 - sql_semantics：ON 挂在 JOIN 那一行的末尾（表名、子查询的右括号后面），条件各占一行缩在下面，仍比 WHERE 的条件 深一级（ON 里和 WHERE 里的同一个条件不当成同一行）。text_diff 里不同的行前面带上它的各级上级行（排在前面、缩进比 它浅的最近一行，一层层数到顶格），以「 」开头、两边相同，只为标出不同的行在哪个 WHERE、哪个 JOIN 的 ON、哪层 子查询里；截到 40 行时末尾落单的上级行不留。只动排版：拿测试里的 SQL 语料（990 对，4 种方言、有无表结构、两个 方向）逐对比过，equivalent、items、fallback、level 和改之前完全一致，有没有不同的行也一致，不再有单独一行的 ON。 - SqlDiff 的约定多一条：「 」开头的是上下文行，只跟着不同的行出现。test_sql_semantics 的 check_shape 原来只认 「- 」「+ 」，改成也认「 」、并要求最后一行是不同的行（374 个用例只因这一行断言变红，判定和说明都没变）。 - 审批卡（DualCheckApproval）：两栏各自只放用得着的上级行（这一边不同的行往上数，缩进更浅的最近一行，一层层往上）， 只有另一边用得着的不放；上级行不高亮、用淡一级的字色（同原文栏里没标的行），标题后面说明「淡色的行两边相同，标出 所在的子句」，悬停也是这句；这一边没有不同的行时照旧说没有，老工件没有上级行，照旧。lineDiff 注释里「条件并成 一行」的旧说法改正。 - 测试：test_sql_text_diff 里 ON 那条的期望改成带 JOIN 的上级行，补两个 LEFT JOIN 只差一个关联条件（两个方向）、 两边 JOIN 的表不同、关联子查询换成两张表、同一个条件在 ON 和 WHERE 里、顶格的行不带上下文、40 行截断几条；去掉 上级行、去掉「ON 挂在行末」、去掉截断后的清理，各自让对应的用例变红。 - 夹具 dual_check.json 按 test_dual_check_fixture 的办法重新生成（只变 text_diff），另加 join_condition 变体（只差 一个关联条件、只给兜底）；check-verify 查两栏的上级行（WHERE）列在不同的行前面、不高亮、标题有说明，join_condition 下原流程一栏是带 ON 的 JOIN 加缩进的条件、盲算一栏不画只有原流程用得着的上级行，深浅色对比度、390px 不溢出。	2026-10-07 01:34:59 +08:00
ThearchyHelios	3e0aacac18	M2 时间线认得报告引用了遮罩列的那一行：decode.ts 把日志 report_masked_cell 说成「报告引用了 N 处取自遮罩列的格子，已标注」，副标题点名引用（不写值），下一步说出具已降档、去改写作指令；证据面板的违规清单给 masked_cell 一个自己的叫法「引用了遮罩列」，不再落成「文档核对未通过」 ... 文案放在 terms.ts 新块 MASKED_CELL_TEXT；check-decode.mjs 加一节守住后端字段（count、refs、columns）、标题、副标题、缺字段时的说法。	2026-10-07 00:24:19 +08:00
ThearchyHelios	5b18eab310	M4：双盲复算「规范化后不同的行」每个条件一行，两边相同的条件不再被标成差异 ... 验收时审批卡把两边完全相同的日期区间标成了差异：_text_diff 逐行比两边 sqlglot pretty 的输出，pretty 按宽度决定 换不换行，两个合取的 WHERE 排成一行、三个的拆成三行，同一个条件在两边落在不同的行上。原文 SQL 都是单行时原文栏 一行都不标，这一栏是唯一逐行指出差在哪的地方，审核人会以为统计期也不一样。 现在逐行比之前两边按同一套排版写（_diff_lines / _line_generator，按方言给 sqlglot 的生成器加一处改动）：WHERE、 HAVING、ON 的合取式每个条件一行，各层子查询里的也一样；条件本身是 OR 连起来的一律加括号（单独一个和与别的并列时 写法一样）；ON 照 WHERE 的样子单独一行、条件缩进在下面（ON 里和 WHERE 里的同一个条件不当成同一行）。比的时候 不看条件前面的 AND（一边多出来的条件排在最前面时，另一边同一个条件只差在有没有 AND），列出来的仍是各自原样的行。 只动排版：判不判等价、差异说明不变（拿测试里的 SQL 对照语料按三种方言、有无表结构逐对比过，items、equivalent、 fallback、level 全部一致），sql_semantics、sql_equivalence 原有测试全过。 前端夹具 dual_check.json 里的 text_diff 是服务端的真实输出，按 test_dual_check_fixture 的办法重新生成（只变了 text_diff）；check-verify 的对照行一节另查「只差结束日期时开始日期不标」「多出的两个条件各占一行」。	2026-10-07 00:12:31 +08:00
ThearchyHelios	b4edcadc88	合入期 5 前置修复 L3：记录页的工件列表把双盲复算对照、反方审稿记录、质询回答归到「核查记录」一组，窄屏下说明换到第二行、序号不被截掉；运行对比的默认基准接口带上 previous，运行详情的对比入口在基准不是紧挨着的上一次时写明「与上一次成功的运行对比」，和触发历史一致	2026-10-06 22:19:25 +08:00
ThearchyHelios	0580663f6e	助手栏连着选两次、两次都没存上时退回服务端存着的设定：以前退回的是第一次选时显示的乐观值（从没存上），原因和齿轮红点一起消失；现在记下服务端最后一次认下的设定，没存上时退回它并再取一次以服务端为准。check-studio 用放行闸门造出先发的那次还没回来就又选了一次的情形	2026-10-06 20:10:51 +08:00
ThearchyHelios	db84e576c0	模型接入报错收尾（第 1 轮复核，前端）：反方审稿的模型一栏不再多出一句相反的说明；检查器读工作流默认设置里的模型；助手栏保存失败时退回原样并说明、「当前」只写在跟随默认上、原因的去向写「上方」；接入「启用」的说明另起一行；落到演示模型的修复候选加醒目标签 ... - 检查器：模型一栏的留空说明（modelDefault）只用于节点定义里的模型栏。反方审稿的「反方模型」自己画、只读节点自己的 配置、留空跟随设置，以前全图默认点名了接入时也被套上「留空则使用接入「X」的默认模型」，和它自己的说明相反；工作流 默认设置写了模型时，空选项和说明写「使用工作流默认设置的模型「X」」（后端执行时取的就是它，也不报「没有指定模型」）， 不再说成某个接入的默认模型； - 助手栏「助手使用的模型」：重新选择时保存失败，下拉、原因、齿轮上的红点退回选之前的样子（服务端存着的没变），下面写 「保存失败，助手使用的模型未更改」，收起再展开后不再留着；只认最后一次选择的回包；选了具体模型时「跟随默认」不写 「当前」（那时服务端给的 effective_model 是选的那个模型）；下拉下面的原因用服务端的 panel_error； - 设置页接入编辑框：停用的后果另起一行写在复选框下面（aria-describedby 接上，读屏名只是「启用」），不再和「启用」并排 放在 label 里把它挤成上下两个字；说法收紧为「停用后，该接入的模型不再出现在下拉列表中，指定它或其模型的节点和设置也 无法调用」——调不了以后怎样（报错、转人工审批、记未裁判、记缺口）由各组自己那句说，不笼统写「运行时报错」； - 发布前检查：候选带 demo 标记时，选项名旁加提醒色的「演示模型」标签，说明里那半句照旧（normalizeFix 留下这个标记）。 types.ts 的 PublishFix 选项加可选的 demo 字段。 检查：check-studio 那一节加反方审稿不套说明（全图默认点名接入、写了模型两种）、工作流默认设置带模型时的空选项和说明、 保存失败退回原样与收起再展开、选具体模型不写「当前」、原因写「上方」；check-manage 量「启用」只占一行（1440、390）、 说明不在 label 里、读屏名只是「启用」、说明在弹窗里；check-publish 的伪造门禁跟上「无法改用其他接入：」与 demo 标记， 加一节演示标签（两个候选各一个、提醒色而非淡色、和选项名同一行、390 宽在弹窗里）。新加的检查项对着改动前的界面跑过， 都会不通过。	2026-10-06 19:43:44 +08:00
ThearchyHelios	53bb356fae	复核第 1 轮：对比入口预先问默认基准带 5 秒超时、问到没有默认基准时写「选择基准对比…」直接去对比页手动选、切回页面时再问一次；工件页签的悬停照实写，320px 时校验值和大小不再拆开 ... - 对比入口（pages/runs/compare/entry.tsx）：预先问 compare/base 卡着不回时 5 秒后按没问到算，叫法退回「与上一次对比」、可点，不再一直停在不可点的「正在查找」；问到没有默认基准（多为工作流的第一次运行）时写「选择基准对比…」，点了直接去只带本次的对比页手动选（对比页自己再找一次），不再写「与上一次对比」、点了再问一遍弹提示；切去别的标签页再切回来时再问一次，问的期间保留原来的叫法、可点，问到不一样才换，问不到不改；更正预先问那段注释的前提（compare/base 不回 409、422，不先问是因为这些入口本来不给点） - 运行详情「工件」页签头的悬停写上证据快照、核查记录和每个节点的产出三组（RUN_ARTIFACTS_TEXT.tabTitle，RunDetailView 只换这一处）；证据快照的悬停不再说「结论里的数字从这里来」，点明含核查、质询时执行的查询；核查记录的悬停用行上的种类名，指明其间执行的查询见「证据快照」；两句都在 45 字内 - 工件行的校验值和大小包在一起排、一起折行，这一栏窄于 22rem 时收起校验值：320px 下大小不再单独折到种类下面，每行仍是两行 - 对比页没带运行时的说明缩成 32 字，不逐个列菜单项的叫法 - 检查：check-compare 补预先问超时、没有默认基准、切回页面再问、点了才发现没有基准后叫法跟着改、工件页签悬停几节；check-verify 改两组悬停的断言、补 320px；check-schedules 的假 compare/base 补上 previous: false（和服务端一致），断言运行详情菜单项与触发历史链接的叫法一字不差	2026-10-06 18:25:35 +08:00
ThearchyHelios	c8800d75e3	模型接入报错的说法与修复候选收尾（前端）：助手栏照实显示存着的模型设定、能重新选「跟随默认」清掉失效的接入；检查器模型一栏说清留空用哪个接入；停用接入的后果写全；问题只认自己那一处的修复 ... - 助手栏「助手使用的模型」：读 GET /api/copilot/model 的 error，照实写在下拉下面，齿轮上加红点（收着时也看得出来）。存着的 设定下拉里列不出来（点名了接入，或模型不在可选列表中）时列成一项并选中，不再停在「跟随默认」——以前看着一切正常、 发出一句话才报错，而且再选「跟随默认」不算改动、清不掉存着的接入，报错又指到改不了它的设置页。这时发出的请求不带 模型，服务端按存着的整组取，和下拉上显示的一致； - 检查器模型一栏：节点（没写就是全图默认）点名了接入时，空选项和说明写「使用接入「X」的默认模型」；X 不存在、已停用时 空选项说状态、不写说明，不再和检查器顶上接入那条问题矛盾（同后端去掉「没有指定模型」那一条）； - 设置页：接入编辑框「启用」旁、卡片上「已停用」的悬停说明写全停用的后果（指定它或它的模型的节点和设置运行时报错）， 不只说下拉里看不到；门控、裁判、核查三格存着的接入名恰好是某个启用接入的模型时，补一句在这一组哪一栏用它，和服务端 保存时 422 的那句一致； - 发布前检查：点名的模型接入只认节点、字段都对得上的修复，没有就是这一处没有修复，不再退到同节点、同编号别处的修复 （同后端 annotate）——以前给不出修复的那一行下面会画着另一处的选项； - 说法收进 terms.ts（PROVIDER_REF_TEXT、ASSISTANT_MODEL_TEXT），getModel / setModel 的返回补上类型（CopilotModel）。 检查：check-studio 加一节（检查器空选项与说明、助手栏的错误与重新选择、发出的请求不带模型、390 宽不多撑出横向溢出）， check-manage 加一节（停用后果、接入名恰好是模型名）并跟上 422 的新说法，check-publish 的伪造门禁照后端「没有修复时 不指到发布前检查」，加一节给不出修复的那一行不借同节点别处的修复。	2026-10-06 17:51:26 +08:00
ThearchyHelios	b8dfbdb335	对比入口的注释换个说法：「接着跑完」改成「接着运行完」，和界面文案的用词一致	2026-10-06 17:25:07 +08:00
ThearchyHelios	2a64099cb8	对比页没带运行时的说明把菜单项的两种叫法都写上：上一次没有成功时运行详情的菜单里写的是「与上一次成功的运行对比」，说明只写「与上一次对比」会让人找不到 ... check-compare 跟着核对两种叫法都在	2026-10-06 17:24:17 +08:00
ThearchyHelios	0f48bd17c4	运行详情「工件」页签：双盲复算对照、反方审稿记录、质询回答单独归到「核查记录」一组；窄屏上说明换到第二行，第几件和第几次尝试在截断范围外，悬停写全说明 ... 分组：以前这三种都算进「证据快照」，那一组的说明却写着「查询、工具调用、知识检索的原始结果」。model.ts 加 artifactGroup（证据快照、核查记录、节点产出三组，按种类分），筛选多一档「核查记录」，件数、悬停说明跟着改：证据快照写上口径卡、报告文档和表结构，核查记录说清装的是什么、核查时执行的查询快照仍归在证据快照。别的种类的归类不变（isEvidence 改成只认证据快照这一组，认不出的种类照旧算证据快照）。口径卡里容器型变量输入的完整值（metric_input）以前露键名，补上名字「指标输入」和说明。 窄屏：以前一行里挤着种类、说明、校验值、大小和时刻，390px 时说明只剩三个字、序号也被截掉。行按列表这一栏的宽度排（容器查询，35rem 以下），窄时说明换到第二行占满整行，第一行留种类、校验值、大小和时刻（时刻和种类对齐）；序号和第几次尝试从被截断的说明里挪出来；按钮的悬停写「打开某种工件：整句说明 #n」。容器设在列表上、不设在整个页签上，查看工件的弹窗（fixed 定位）不落进容器里。新文案放在 terms.ts 的 RUN_ARTIFACTS_TEXT。 新预览用例 ?syn=run-artifacts（虚构的门店周报，22 件，各种工件都有，含封存后追加的长问题质询回答）。check-verify：分组和 isEvidence 的口径、四档筛选的件数和悬停、点各档只剩该组；390px 深浅色下说明都在第二行、被截断的说明看得见至少 200px（以前 0 到 63px）、第几件整个落在行内、时刻在第一行和种类对齐、不横向溢出、对比度。check-inquiry：工件页签的读法改成按 data 属性，质询回答归在核查记录、悬停带整句说明	2026-10-06 17:15:52 +08:00
ThearchyHelios	50f15b40c4	合入期 5 前置修复 K1：点名的模型接入不存在或已停用时照实报错，不再悄悄换成演示模型——各条用到模型的路径照实失败或记为核查不可用；保存设置时 422、画布校验给警告、发布与发布前检查挡住并给修复候选（不指定模型、改用启用的接入），只写模型而提供它的接入已停用也查得出	2026-10-06 16:55:27 +08:00
ThearchyHelios	6514db6118	运行详情「更多」里的对比入口按默认基准是不是紧挨着的上一次定叫法：上一次失败、取消、还没结束时写「与上一次成功的运行对比」，和定时任务触发历史里的同名链接一字不差、点进去是同一个基准 ... 拿到能对比的运行（已封存、属于已保存的工作流、不在运行中）就预先问一次 compare/base，按答复里的 previous 定叫法；按运行 id 加清单哈希记，失败后接着运行完重新封存了会再问。问到之前这一项只写「正在查找上一次成功的运行…」、不给点：菜单开着时不会先写一个叫法、问到了再换成另一个，也点不到说错了的入口。预先问出错、找不到默认基准都不提示，叫法退回「与上一次对比」，点了照常再问一次、照实说。点了总是再问一次、按那一次的答复跳：详情页可能开了很久，预先问到的基准不一定还是现在的。 类型 RunCompareBase 加 previous（老服务端不给，按 true 算，同 ScheduleFireCompare）；两种叫法放在 RUN_COMPARE_TEXT（menu、menuLastOk），SCHEDULE_TEXT 的 compareLinkLastOk 和 compareLink 一样改成取它的 getter，过时的说明一并改掉。check-compare：夹具里本次的默认基准带 previous: false（和触发历史那一行同一个假定）；上一次失败了、上一次就是成功的两种，运行详情和触发历史两个入口叫法一致、打开同一对运行；预先问的那一次压住时菜单项只写正在查找、问到后直接是最终叫法（记下菜单开着时出现过的每一种状态核对）；预先问出错、找不到基准时不提示、点了照常再问；点了之后对比页不再自己找一遍	2026-10-06 16:52:30 +08:00
ThearchyHelios	0a690a599b	发布前修复点名的模型接入：按执行时的取法算修完落到哪里，只写了模型而接入已停用的也拦下 ... - 「不指定接入」以前只去掉接入、留下同一处写着的模型，复核又只查点名的接入：按模型名落回停用的接入，或者成员跟随节点、节点跟随全图默认，拿别家的接入去调这个模型。检查、发布都通过，正式运行在那一处照样失败 - 现在每个候选（不指定、改用某个启用的接入）先在副本上改，按执行器的取法（成员先看自己、再看节点、再看全图默认；节点看全图默认；都没写按模型名找；核查和裁判整组交给设置）算出改动波及的每一处用哪个接入、哪个模型。落到的接入不提供那一处的模型、按模型名落到停用接入或认不出的模型、落到内置演示模型的，连同一级写着的模型一并去掉再算，还落不稳的候选不给；候选说明写清执行时改用哪里、模型去没去掉、换上的接入实际用哪个模型 - 门禁把哪一级都没写接入、只写了模型而提供它的接入已停用的那一处也记成 provider.disabled（落在写模型的字段，原因和运行时同一句）：复核拒得掉这类修复，检查器里只能选模型的节点发布前也查得出来；这一处配「不指定模型」或改用一个启用接入的修复 - 按模型名找接入、没写时退回哪个接入抽成 factory.provider_for_model、fallback_provider，运行时和门禁共用一份 - 问题面板、修复预览写得出「模型」「成员「x」的模型」；check-publish 的伪造门禁跟上新的候选，补只写模型的一段 - 测试：复核发现的几种形状逐一钉住（含发布前检查修好、保存、发布后正式运行成功的端到端一条）；依赖旧做法的两条测试改成新的正确行为	2026-10-06 16:31:06 +08:00
ThearchyHelios	3f17fd3c71	合入期 5 前置修复 K4：运行把这一段执行的截止时刻交给节点（engine/deadline.py），反方审稿与双盲复算开始每一项前看剩余时间，按剩余时间收紧每项时长、给下游留出余量，来不及的记为未能反查 / 无法复算并写明「运行时限将至」，整次运行不再被时长上限中止；继续运行取 checkpoint 里的结果不重复反查	2026-10-06 16:26:45 +08:00
ThearchyHelios	4314a7fc44	合入期 5 前置修复 K2：核查与裁判模型的输出额度提到 16384，服务方嫌大时退回 4096（和助手共用 providers/budget.py）；每次调用认截断，因推理占满额度没交出结果时照实说（verify_truncated、judge_truncated），不再说成盲算没查到、没按结构交结果	2026-10-06 16:26:37 +08:00
ThearchyHelios	0a875fd3af	合入期 4 整合 J4：质询回答工件在记录页有名字和说明；问答串在审批列表取失败时不再漏条目；运行对比的默认基准与定时任务自动对比用同一条规则（同一任务、同一工作流、比这次先发起的上一次成功并封存的运行），触发历史在基准不是紧挨着的上一次时写明「与上一次成功的运行对比」	2026-10-06 16:23:40 +08:00
ThearchyHelios	ed888d59df	合入期 4 整合 J3：出具横幅按「核查未通过 / 核查未完成 / 校验未全部完成」分组；审批卡把运行类别交给反方审稿概况；证据接口的核查类型契约挪进 types.ts；反方审稿加单句模式、证据面板不再谈出具；证据接口带上句子的反方判断映射，正文给被审过的句子挂句末标记；质询图标平时对比度达标	2026-10-06 16:23:33 +08:00
ThearchyHelios	384af7a5f2	界面跟上点名接入的新规矩：设置页标出已停用的接入、选不了别的停用接入，接入表变了画布重新校验，问题面板和修复预览不露键名 ... 点名停用的接入以前照常调用，现在运行时照实报错，界面要提前说： - 设置页门控、裁判、核查三格：存着的接入已停用和「不存在」一样在那一格下面写明后果；下拉里别的停用接入列着但选不了（只留已选着的那个）；模型一格不再写「留空则使用」一个调不了的接入的默认模型。服务端按项拒收（422 带 field）时整句落到那一格下面、焦点移过去，保存条连同原因一起写，不再截掉「请在……中启用它」。 - 画布校验现在读接入表：编排页记下校验时的接入表签名（id、名称、启用与否），从设置里改完接入回来、或目录刷新后接入表变了，就重新校验一次，不再停着一句过时的「已停用」。 - 问题面板、修复预览里点名接入的字段写「模型接入」「成员「分析师」的模型接入」「工作流默认设置 · 模型」，不露 provider、model 键名；修复预览给列表项写名字。同一节点上自己的接入和成员的接入是两处问题，合并、找修复都连字段一起认，计数不再少算。 检查：check-publish 加点名接入的修复（一处一行、候选、预览、应用、390px 不溢出）、问题面板字段叫法、在设置里删了接入回到画布重新校验；check-manage 加设置页已停用接入的三格说明、选项、按项拒收；check-evidence 里全图默认的 model 改按「模型」核对（不借裁判叫法的原意不变）。	2026-10-06 15:14:40 +08:00
ThearchyHelios	6a54ab06c2	J3 复核修正（第 1 轮）：过期的证据图重取一次，只有反方标记的句子在面板里先写判断，没反查成的不说成反方模型的判断 ... 证据图缓存会过期：正文有运行就取证据图，之后一直用缓存。审批卡里展开过报告的话，缓存的是运行停在审批上那一刻的图：报告 改写后（第二次审批、同一张卡换稿）新稿在那份图里找不到，一个标记都挂不上；审批之后才审完的反方审稿，成果区也看不到；证据页 挂上时只管「运行已结束、图没封存」，停在第二次审批上的运行、别处正在取的那份都不管，画的是旧稿、审计表却是新取的。改成： - EvidenceDoc（useRunGraph）挂上、换稿那一刻手里已有的那份，找不到正文这一稿，或者正文是运行的成果（EvidenceField 给 settled）而那份没封存，就按（运行、报告、工件）重取一次；重取回来还是这样就作罢，挂上时还没有、正在取的那份不算过期； - 证据页挂上时手里那份不是「封存了、封存的就是这一版（manifest_seq）」就重取，不看运行停在哪；别处正在取的取回来再看一眼； 重取回来之前占位，第一次渲染就按挂上那一刻手里的那份定，不先画一帧旧稿。 整句面板的反方审稿：只有反方标记的句子（没有可点片段、也没有裁判判定）只能从标记点进来，面板却只认片段接口的 unit.challenge，还在取时这一节空着，答 500 时整节消失、也不说为什么。EvidencePanel 收下正文的标记（marks），片段接口还没答、 答不了、答了却没有可用内容时先按标记写出判断（ChallengeSummary 导出的 ClaimVerdictPending），说正在获取、未能获取（带重试， 重试后焦点落到「反方的理由与查询」或新的「重试」上）、无法查看；拿到 unit.challenge 换成完整的单句展示。 没反查成的句子：单句展示里一定没反查成的那一句不再写「判断由反方模型给出」（那是服务端按规则记的无法判断，反方模型没看过）； 无法判断的句末标记悬停说明、先行版的落款写「可能是反方模型的判断，也可能是未能反查时记下的」，说不准的仍写判断出自反方模型。 其余几处： - 挂上时一个键盘目标都没有、反方标记随证据图后来才到：Tab 位交给第一枚标记（以前三枚都是 tabindex=-1，Tab 跳过整份报告）； - 只有反方标记的句子，读屏不再把「反方审稿」念两遍； - 带字的醒目标记悬停、展开时不铺浅底（10px 的失败色、提醒色字叠在 14% 的浅底上，浅色主题只有 4.0 左右），改描 1px 内边， 和裁判徽标并在一起的同样；无法判断换成省略号盾牌，不再和裁判的「?」、质询的问号挤成三个问号，也和经受住的勾分得开。 检查：check-evidence 新增 mark-panel（片段接口压着、答 500、重试，390px 不溢出）、mark-tab（标记晚到进 Tab 顺序）、stale（审批卡 换稿、同一张卡换稿、成果区、证据页停在审批上和别处正在取，各重取一次、对上了不再取、旧稿一帧都不画）三节，marks 一节补读屏原文 逐字比、展开和悬停时的对比度、图标形状、无法判断的说法，verify 一节改等单句展示（原来等的选择器单句模式里没有，每遍白等 4 秒）； 新预览用例 evidence-marks-text、evidence-marks-stale（dev/fixtures/evidence_marks.tsx）。check-challenge 新增 challenge-claim-quiet： 单句、不谈出具，给齐正式运行、运行 id、degrades 也不写降档、不取运行类别（以前这个开关在哪个用例里都观察不到）。	2026-10-06 14:36:21 +08:00
ThearchyHelios	48f656f362	证据裁判截断的回复整批不采信，截断另记 judge_truncated，时间线的下一步指到换模型 ... 复核第 1 轮的发现： - 有的网关把截断的强制工具调用解析成半截清单：第一条判定写完、第二条只写了编号。_ask 拿到清单就交出去，不再看截断，于是记成一句支持、一句格式不对、两句未给出判定，llm.end 也不标截断。现在回复被截断就整批记 truncated（最后一条可能只写了一半，也可能判定写完、理由写到一半，分不清哪条完整），纯文本调用同理 - 截断的那一批原来只发 llm.end（时间线标题「结论句裁判未能执行」）和 judge_failed（下一步「检查裁判模型的接入后重新运行」）：截断时接入是好的，同一个模型重新运行多半还是截断。现在另发 judge_truncated（max_tokens、unjudged），judge_failed 不再带截断；时间线上调用那一行说「裁判模型的输出达到上限（N token）被截断」，judge_truncated 那一行的下一步指到在报告撰写节点的「结论句裁判」或设置里换不带推理的裁判模型，入口落到节点的结论句裁判；check-decode 加一节 - 复核层（review.py）认得 judge_truncated：是缺口，记成它自己的 kind - 退回小额度按 budget_refused 认，和核查同一种记法记在进程里：之后每份报告、每次点击直接用小的 测试补上半截清单（剧本和真实 ChatAnthropic）、纯文本清单后面还在写、截断和格式不对各记各的日志、跨报告记住被嫌大、自建服务的 max_new_tokens	2026-10-06 14:30:15 +08:00
ThearchyHelios	4905de728c	核查截断的回复一律不采信，触顶原因的先后照旧，截断的建议按模型从哪来的说 ... 复核第 1 轮的发现（主要一条）：Anthropic 的工具调用写到一半到了上限时，回复照样带着 tool_use（input 是空的，有的网关给半截对象）。工具循环只在没有工具调用时才看截断，于是一轮轮执行空参数的查询，撞到步数上限，最后记成「没有按结构交结果」；收尾的强制工具调用截在半路时解析出空对象或半截对象，空对象记成没按结构交，反方审稿的半截对象（结论写完、理由写到一半）被当成「经受住」，质询把半句话当成回答。 - 工具循环：回复被截断就停，带着的工具调用不执行（半截的 SQL 查出来的数是错的），也不收尾 - 截断前查到过东西的也不再按查到的收尾：截断前查到的不一定是要的那个数，交出去的结果只在 notes 里写一句「可能不完整」，审批卡、反方结论、质询回答都看不到，残缺的结果还照常参与比对和处置。同时长到点一样算半路被掐断，原因照截断说，查过的照记；TRUNCATED_SETTLED 和日志里的 delivered 字段去掉 - 收尾：回复被截断时，解析出来的、从回复里抠出来的都不采信（结构化、普通调用都是），也不退回普通调用 - 上一轮的 give_up 把触顶原因的先后从「先 stopped」换成了「先 refused」：去掉 give_up，收尾被上限拦下时照旧报先撞上的那个（双盲复算按它写无法复算的原因，反方审稿按每日上限决定还派不派后面的句子） - 截断的原因开头只说「未能给出结果」（质询里提问人看到的就是这句，不说「核查未能完成」）；建议在节点里说「在节点上指定不带推理的模型，或在设置里更换核查模型」（节点上的模型优先于设置，和时间线上的下一步一致），质询只说设置 - 退回小额度按 budget_refused 认，按 (接入, 模型, 额度) 记在进程里 - 时间线：verify_truncated 的副标题固定说「这次核查未能给出结果」，check-decode 跟上；review.py 里 verify_truncated 的注释跟上 测试补上真实 ChatAnthropic（只有 HTTP 层是假的）的循环截断、收尾截断（空对象、半截对象），真实 ChatOpenAI 写到一半的工具调用参数，Bearer 鉴权下 SDK 在本地拒绝时退回 4096，自建服务的 max_new_tokens，跨次核查记住被嫌大，触顶原因的先后	2026-10-06 14:30:03 +08:00
ThearchyHelios	b2878fde59	时间线认得核查日志里的 cause: run_deadline：单次运行时限将至没核成的那几行说时限，下一步说怎么腾出时间，不再叫人调高核查的上限或去查模型和数据源；设置页双盲复算、反方审稿的时长设成不限时写明仍受单次运行时限约束 ... 为什么（复核第 1 轮）：反方审稿、双盲复算为后续节点预留时间，没开始的、缩短时长后到时没做完的以前读成「反方审稿已达时长上限」「未能反查」「无法复算」，下一步是「调高反方审稿的上限」「检查核查模型和数据源」「调高……中的上限后重新运行」——调高了只会更快撞线，模型和数据源本来就没问题。服务端现在另起一条、带 cause 和 run_seconds（单次运行时限），这里照它说。设置页「不限」的说明原来写「仅受模型接口自身的超时约束」，可这两种核查在运行里执行，时限将至时照样按剩余时间缩短。 - decode.ts：dual_check_unchecked、challenge_unreviewed、challenge_limit 带 cause: run_deadline 时，标题写「运行时限将至，……」，副标题写「单次运行时限为 600 秒，已为后续节点预留时间」（双盲复算前面再点名指标），下一步写减少句数或指标、在核查前加人工审批（时限按审批前后分段计算）、请管理员调大单次运行时限（AGENTLAB_MAX_RUN_SECONDS）；不带 cause 的照旧 - terms.ts：叫法放在 DUAL_CHECK_TEXT（共用的副标题和双盲复算两句）、CHALLENGE_TEXT.log（反方审稿三句）、VERIFY_SETTING_TEXT.unlimitedNote 多一种 runTimeout - VerifySettings.tsx：时长设成不限时，审批质询照旧（它不在运行的那一段里执行），双盲复算、反方审稿用 runTimeout 的说法 检查：check-decode 新增一节（追加在文件末尾），先核对后端还是这么发，再看三种日志带不带 cause 各怎么说、同一节点里两条分得开、缺字段不崩；对着改之前的 decode.ts 这一节 7 项变红。check-verify 新增一节（追加在文件末尾）：三项时长设成不限时各自的说明，390px 深浅色不横向溢出、对比度 ≥ 4.5；改之前这一项变红。	2026-10-06 14:25:53 +08:00
ThearchyHelios	f815b1232a	审批质询收尾：审批列表取不到时别的审批里问的单独一组写「无法确认提问时的报告版本」并给重试；质询回答的问题摘要截在空格上也补省略号；工件页签里运行结束之后才写下的工件不给航迹跳转 ... - 审批列表没取到时，那几条以前被标成「报告其他版本上的质询」：同一屏上卡里挂在句子下面的一条，证据页签却说是别的 版本，审批人会以为报告换过稿，也没有办法重取。现在单独一组照实说没能确认、给「重试」，取到后按结果各归其位（这张 审批里问的回到句子下面，审的是另一稿的才算其他版本）；取到了列表却没有那张审批的、报告没有报告文档的照旧算对不上 - 质询回答工件的说明：服务端先去掉问题首尾的空白再截前 40 字，摘要以空格结尾只会是截断截在了空白上。以前先去空白再 数字数，少一个字就漏了省略号，半句话读成整个问题；改为按原样数、显示时才去空白 - 运行详情「工件」页签：晚于运行结束的工件（封存后追加的质询回答和它查询的快照）以前也给「T+…」跳转，点了把航迹拖到 运行结束之后几十分钟、几天；现在只写时间。pages/runs/ArtifactsPane.tsx 只加了结束时刻这一道边界，运行中、停在审批上 的运行照旧（航迹还没有结束时刻） - 预览用例 inquiry-run-artifacts 换成带起止时间的航迹、多一件以空格结尾的问题摘要；check-inquiry 补对应断言，以及审批 列表取不到时的标题、重试、重试后的归拢和深浅色对比度	2026-10-06 13:33:54 +08:00
ThearchyHelios	1bee9b5100	触发历史不再给基准已过时的自动对比；对比页找不到默认基准时标题不再和「可在上方选择」打架，换基准的下拉和基准卡写明失败、取消的运行 ... - 中间失败的那次事后被接着运行成功之后，第 3 周存着的那份对比（比的是第 1 周，previous 为假）和运行详情「与上一次 对比」的默认基准（现在是第 2 周）又对不上，两处却都写「上一次成功的运行」。auto_compare.outdated 对基准当时就不是 紧挨着的上一次的那几份按 pick_base 现挑一遍，基准变了的算过时；api/schedules._fire_outs 对过时的给 null（不给链接、 不给旧计数），两个同名入口比的始终是同一对运行。基准没变的照旧给：中间那次还没结束、后来失败、被删掉都一样。紧挨着 的上一次不会过时（两次之间插不进新的运行），不核 - test_base_follows_launch_order_not_finish_time 补上：接着运行完之后第 3 周的触发记录不再带对比、任务列表的 last_fire 同样不带、运行详情的默认基准是第 2 周；另加一条基准仍是挑出来的那一次时照旧给出 - 对比页找不到默认基准：标题由「未找到可作为基准的运行」改为「没有默认基准」——失败、取消但封存了的运行不当默认基准， 却照样能在上方手动选；服务端的原因改成「没有找到上一次成功的运行：需要同一工作流、同一运行类别里比这次先发起、成功 结束并已封存的运行」，运行详情弹出的提示单独读也说得清 - 换基准的下拉给失败、已取消的运行写上状态，基准卡也标出来；下拉说明补一句默认基准只取成功结束的运行 - 运行详情「更多」的菜单项点之前不知道基准是哪一次，基准不是紧挨着的上一次时仍叫「与上一次对比」，和触发历史的叫法 不同：注释照实写明，留作后续	2026-10-06 13:33:40 +08:00
ThearchyHelios	2c2672cc04	时间线认得核查模型的输出被截断（verify_truncated）：标题说「核查模型的输出达到上限（N token）被截断」，副标题说这次核查未能完成或已按截断前查到的结果收尾，下一步指到换不带推理的模型，入口落到节点的模型 ... decode.ts 按结构化字段（max_tokens、delivered）解读，不从原话里认，缺字段时只给不带数的标题；文案放在 terms.ts 新的 VERIFY_TRUNCATED_TEXT。check-decode 加一节：先核对 verify_agent.py 还是这么发的，再核对三种取值（没交出结果、退回 4096 后交了结果、缺字段）的标题、副标题、下一步、入口和原话。 跑完之后的复核层（engine/review.py 的 WARN_CODES）登记 verify_truncated：同 verify_limit 记成它自己的 kind、degraded，不落成笼统的 warn，也不触发「重跑一次大概率能好」。	2026-10-06 13:06:18 +08:00
ThearchyHelios	4b5b3ecbf7	正文给被反方审过的句子挂句末标记，「质询」图标平时的对比度提到 3:1 以上：EvidenceDoc 按证据图 reports[].challenge_verdicts 给被审句子挂标记（被推翻、被削弱带字醒目，经受住、无法判断只有淡色图标），已有裁判徽标的并在同一枚徽标里，点开是整句面板，没有可点片段、没开裁判的句子也打得开；有运行就取一次证据图（同一次运行只取一回，不逐句请求），只认工件 id 对得上的那份报告；证据页挂载时手里那份证据图是运行收尾前取的（没封存）就重取。句末「质询」图标平时改用暗字色压到 70%，深浅两套、页面底色和面板底色上都在 3.3 以上，不撑开排版。check-evidence 补标记、整句面板、未能反查的说法和平时对比度的断言，probe 改在打开页面之前挂路由（证据图一挂上就取）	2026-10-06 13:02:30 +08:00
ThearchyHelios	a25fed002e	出具横幅把核查缺口分组，审批卡把运行类别交给反方审稿：IssuanceBanner（运行面板成果区、问数据回答、证据页同一个）把双盲复算、反方审稿报上来的缺口另起「核查未通过」「核查未完成」两组，排在「校验未全部完成」上面，先后同时间线和成果节点印章；证据页去掉另列一遍的 IssuanceWithChecks 包装，直接用横幅。RunPanel 的审批卡把 approval.run_class 传给 ChallengeSummary，运行的 GET 失败也照样写「出具会降档」、不另取。check-stream 补横幅分组的断言（新预览用例 issued-verify），check-verify 的 verify-gaps 改读横幅里的新组，check-challenge 补整张审批卡带运行类别的用例	2026-10-06 13:02:04 +08:00
ThearchyHelios	573313cbc2	证据接口的核查状态类型挪进 types.ts，证据面板的反方审稿改用单句展示：EvidenceDualCheck、EvidenceUnitChallenge、输入步骤的 masked / mask_unverified、证据图的 challenge_verdicts 照服务端逐字核对；审批卡上的概况类型补上 unreviewed、degrades。ChallengeSummary 加单句模式（scope=claim，只画这一句的判断、它可能没反查成的说明、展开看理由和查询，不画报告级的标题和计数）和显式的「不谈出具」开关（issuance=false，不预告降档、也不为此取运行类别），证据面板改用这两样，去掉传 runId 为空的做法；check-evidence 的核查一节跟着改成单句的断言	2026-10-06 13:01:17 +08:00
ThearchyHelios	238fe94fee	质询回答工件兜底说明的注释照实写：服务端都会记问题摘要，没有时只是兜底，不说成「这一版之前存的」	2026-10-06 12:32:15 +08:00
ThearchyHelios	aa2b93f587	check-compare 里找不到基准的假答复照服务端的新说法写；触发历史的对比链接去掉没人用的标记 ... - 「不属于已保存工作流」那一段伪造的 404 说明原先抄的是旧的 NO_BASE_TEXT（更早结束并已封存），改成服务端现在的 「上一次成功的运行……比这次先发起、成功结束并已封存的运行」，假答复和接口约定保持一致 - FireHistory 的 CompareLink 去掉 data-fire-compare-previous：检查只看看得见的字，不靠这个标记	2026-10-06 12:30:44 +08:00
ThearchyHelios	21e8455403	双盲复算审批卡的预览夹具跟上收尾版差异说明：变体换成仍有代表性的一组，预告按带日期类型的表结构重新生成 ... - 收尾版差异说明对同一列上的时间范围只给兜底，旧的 time_range 变体失去意义：改名为 fallback（说不清的，兜底加 逐行对照，审批卡默认展开对照），另加 time_column（按哪一列筛时间不同，两列都声明为日期类型，预告写业务日期）； 有效记录条件（filter_extra）、去重规则（dedup）和其余仍说得出的变体照留。夹具由服务端重新生成：filter_extra、 two_filters、peers.filter 的筛选说法也跟上了现在的输出（「……的行和 status 为空的行」），原先排在 time_range 后面没被比到。 - test_dual_check_fixture 的表结构把 paid_at、created_at 声明为 TIMESTAMP（业务日期的类型门槛），预告、合并预告、 被挡下的那一份照旧写业务日期；新增一条守住几种变体的方面和预告会写的项，免得规则一改变体悄悄变了形状。 - check-verify 跟着改：没有预告的那一节换上 fallback、time_column，兜底的那种对照默认已展开、不再点一下收起；有预告 的那一节兜底变体按兜底说明核对，换了时间列两边都写同一项时后一条按省略写法核对，并看选盲算时加重的那一条；几个 输入都差在时间列的合并用例改取 time_column 的说法。check-verify、check-decode 浏览器检查通过。	2026-10-06 12:19:44 +08:00
ThearchyHelios	a358fbd244	审批质询收尾：工件页签认得质询回答；几处问答串要对的审批不同、审批列表取不到时各自照样列出 ... - 工件名：质询的回答文档以 inquiry_answer 登记在运行名下，工件页签原先直接显示英文原值。ARTIFACT_KIND_LABEL 加「质询 回答」，说明在 meta.question 有值时写「质询「…」的回答」（服务端只记前 40 字，满 40 字的补省略号），没有时写「审批 质询的回答：逐段的片段和每个数字的出处」；文案放在 INQUIRY_TEXT - 问答串的竞态：loadApprovalDocs 发现别处正在取审批列表就直接返回，没把这一处要对的审批记进 asked。请求回来后这一处的 unknown 不变、effect 不再执行，settled 一直为假，头上写着「· N 次」，别的审批里问的那几条一直不显示（一张卡审两份 报告；运行详情的待审批卡和证据页签同时挂着、审批列表失败时）。现在提前返回前也把这一处的 id 并进 asked：列表按运行取， 在路上的那一份本来就带着全部审批，不另发请求 - 预览用例：inquiry-approval-two（一张卡审两份报告）、inquiry-run-waiting（待审批卡和证据页签同时挂着）、 inquiry-run-artifacts（工件页签）；夹具补探索运行的工件列表 run_artifacts - check-inquiry：审批列表压住、再答 404，两处的条目都列出（查不到审批的单独成组），头上的次数和列出的条数一致、审批 列表只取一次；工件页签里有「质询回答」的名字和说明、不出现英文的种类名、打开的弹窗标题也是中文；390px 深浅色下不溢出、 看得清	2026-10-06 12:19:13 +08:00
ThearchyHelios	a18b24ab6f	对比页与触发历史照实说「上一次成功的运行」：两个同名入口打开同一对运行、写同一句来历 ... 服务端的默认基准和自动对比已经共用一个挑法（只挑比本次先发起、成功结束并封存的运行），界面上的说法跟着改： - 对比页的「默认基准：…」改成「同一定时任务上一次成功的运行」「同一工作流、同一运行类别上一次成功的运行」；运行详情 查找基准时的提示、没带本次时的说明同样改成「上一次成功的运行」 - 触发历史的「与上一次对比」：基准不是紧挨着的上一次（previous 为 false）时，链接上看得见的字写「与上一次成功的运行 对比」，触屏、键盘聚焦都看得到，悬停照旧写是哪一次。两种都带上「同一定时任务」的来历：新的说法对这两种都成立， 对比页和从运行详情进去时一字不差 - check-compare：两种来历的说法；运行详情「更多」和触发历史两个入口打开同一对运行、写同一句来历、摘要一致 - check-schedules：previous 为 false 时看得见的字（含键盘聚焦、390px 窄屏）；两个入口拿同一个基准	2026-10-06 12:05:40 +08:00
ThearchyHelios	cc166fefb8	合入期 4 审批质询（前端）：报告句末与划选原文浮出「质询」，问答串与提问框挂在审批卡和运行详情，回答按片段与出处渲染；同一张卡挂两处、换了审批、报告改写前的问答各归其位；时间线解读 approval.inquiry，等待中来质询阶段仍是等待	2026-10-06 11:32:20 +08:00