153 Commits

Author	SHA1	Message	Date
ThearchyHelios	7088f4557e	普通用户建应用的契约骨架（docs/design/normal-user-apps.md 第五部分）：蓝图、蓝图留痕、发布单、文件、记录表的模型和迁移，应用的 scope / owner / blueprint_id；运行来源加 trial、personal_app；应用描述的固定版本可以没有版本号（试运行派生的草稿）或改钉蓝图（个人应用），视图来源加 exploratory，组件加 hidden，表单加文件控件；agentlab.blueprint/1 与 bp_* 操作、agentlab.template/1 与关节类型的定义；实例化、试运行、发布单、个人应用、记录表、文件、白话层的接口签名；蓝图、模板、文件、个人应用、蓝图助手的路由桩（501）；前端约定 typesBlueprint.ts、接口桩、新建应用与蓝图页的占位路由、termsBlueprint.ts	2026-10-15 09:49:45 +08:00
ThearchyHelios	e182c2d214	复测收尾：账号密码登录时应用检查和授权接口核对名录（没有的、已停用的报错或拒收，单点登录只提醒），名录口径收成 auth/directory 一处；受管发布版在页头、版本历史、选择器、发布前检查里按发布级别写，草稿和发布版内容相同时照实说；写入能力在工具库写「只演练」；印章的「截至」只写一次；走驳回出口到达的结局不用成功样式；停着等人时说在等哪一步，同页已有会签进度时待办状态不再画一遍，名单写显示名；应用编辑器可以归档（写清后果），已归档的应用拒收草稿修改和发布；受管发布成功的提示写明受管；权限测试按 id 取应用，不撞别的测试留下的同名应用	2026-10-15 08:35:28 +08:00
ThearchyHelios	941723b17c	端到端验收修复与指标出具： ... - 身份与工具：登录页建第一个管理员（认人接口的 401 说明能不能建）；搭建者有只读的人和组名录，选人给候选并核对名字；授权三行带标题；端点请求头名校验（空名、非法名存不进、发不出时说清原因）；写入能力在工具页试运行一律演练、不发送，HTTP 状态照实说成败；写记忆不算只读、查询能力只能选同一端点上的只读能力；审批与遮罩的说法和实际规则一致；开登录时不要署名、导入和发布记登录的人；使用者不显示推演等只给搭建者的操作，403 按是否开登录说话；登录页只认一次人 - 流程与实例：图里用到的岗位（派给谁、超时升级给谁、发送确认派给谁）全部派生、没绑人的发布时报错；写外部系统的参数按能力声明的类型收拢后再算哈希和发送，收不成就不发；发起人的实例页只看这一步的状态，处理人才给待办卡；会签进度带登录核实和时间，升级后照实写规则；实例状态写流程的结论（已退回、未确认、等待核实写入结果），核实生效后不再挂失败原因；流程应用首页不派生最近封存运行的结果块，看板没数据时是安静的空态；样例⑩的金额带类型和下限、待办标题带金额，表单上下限前后端一起生效 - 看板与证据：定时任务模板加 ISO 周、上一 ISO 周、本月、上月；出处链穿过原样解析查询结果的整形节点，追不到原始数据的照实说停在哪里，样例⑨改用 cell()；应用首页和版本历史都能做成应用；指标块单位不重复；版本列表带退役说明；定时任务页头跟着刷新；删视图要确认、新视图能起名；编辑器属性用中文名、术语带解释 - 指标出具（用户 2026-10-15 拍板）：契约只写「指标来自」、上游没有报告撰写节点、成果里没有模型写的话时按指标出具——必需指标齐、指标输入追到原始数据、成果字段里的数回指得上才完整出具；受管级要求每个指标静态地追到原始数据（governed.metric_untraced）；出具横幅和应用印章写明按指标 - 受管工作流降为已发布只给管理员（Q8 顺延，服务端同样拦）；工作流接口带当前发布版的级别，画布上改过之后也认得出受管工作流	2026-10-15 07:15:37 +08:00
ThearchyHelios	c6a29bfd7c	前端：审批卡按审批当场拼出待办（不再为一张卡取一次待办，收到中断就出卡；有 task_id 走待办接口，没有走老的审批接口）；矮窗口导航两档高度不再叠加，480px 放得下九项；待办数随目录启动时就取、外壳订阅时当场记底，派给自己的新待办通知不再漏；头一回取目录的卡住从启动算起；外壳横向裁掉悬停提示的占位；证据抽屉同一指标在取时不另发请求；编辑器去掉第二个 main、检查一次只跑一遍；记录页对不上待办的审批照旧画审批卡，待办行写 runName 和节点名；检查脚本按新页面更新断言（沙箱没有待办时用合成的两条、未保存与已删除工作流分开认、生效记录页签、能力子页签）	2026-10-14 23:57:43 +08:00
ThearchyHelios	1dd4f93579	应用平台集成（前端）：钩子按名字管理并只显示一次密钥、按新口径补算、应用助手对话历史、设置页按角色收起与身份设置补管理员用户名、按需视图每日上限、界面偏好按角色只存本地、使用者问数据用数据源名单并在运行流连不上时改轮询、能力字段待审阅、记录页按来源筛选与待办 id、编辑器的入口 / 表单 / 待办外观 JSON 分区、画布 ?publish=1、工具页绑定端点与 MCP 认证头掩码编辑、派给自己的新待办系统通知、样例与检查脚本改走待办接口（含统一复核后的修复）	2026-10-14 21:55:51 +08:00
ThearchyHelios	e341beb1cb	应用平台 FE-6 搭建面：应用编辑器（固定版本、派生、页面树与属性面板、预览、检查、发布时选处置、岗位与授权、钩子、通知、助手面板），人工节点新字段与写入动作说明，发布弹窗与版本页的退役和使用情况，记录页的来源、待办与动作事件、生效记录，发起表单换成表单渲染器并带来源，问数据「做成应用」，look 的界面与 meta.looks，工具页的能力与端点，设置页的身份、通知、审计；检查脚本的更新与新增（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	22021e76c3	应用平台 FE-5 使用面：表单渲染器与子集校验、待办卡（会签进度、动作确认哈希卡、核实选项）、视图渲染与组件目录 v1 的渲染器（印章、指标点开出处、趋势与图表、表格、报告）、应用首页 / 应用页 / 发起 / 实例 / 待办 / 登录页、导航加「应用」与徽标按来源分开、按角色收起导航、401 跳登录与请求头；新检查脚本 check-apps、check-inbox、check-auth（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	220fd0e365	应用平台契约骨架：新表（身份、能力与端点、应用、待办与生效记录、通知）与迁移（补列、多列索引），运行来源与新事件类型，「人」的唯一入口 api/deps.py（关登录时行为不变），应用描述与表单的形状、受信组件目录 v1，各包跨包函数的签名桩，新路由登记，发布门禁的扩展钩子 EXTRA_LINTS；前端接口约定 typesApp.ts、各接口文件、SchemaForm / TaskCard 的 props 与最简实现、应用相关路由与占位页	2026-10-14 17:53:40 +08:00
ThearchyHelios	49f00c589a	目录修改提案的依据改存成目录项单独的字段 reason（界面上叫「确认时的依据」，最多 500 字，超了截成 499 字加「…」），不再拼进备注：拼进 note 之后，带依据保存的关联关系再剖析时测量的说法换不了新、和覆盖率那一栏对不上；改了值的关联关系旧依据叠在新依据后面、越存越长；值不变、保存即确认的项撤销审阅回到推断后「依据：使用者说……」还挂着，看起来像使用者确认过一条推断项。去留：值改了（关联关系也一样）换成这次的依据，没写就去掉旧的；值不变的确认换成这次的，不叠；单项确认、驳回留着，撤销审阅去掉；整份提交改了值的、状态改回推断的、双盲复算改写的去掉；剖析刷新关联关系的测量只动备注。校验认 reason（文字、最多 500 字），起草、剖析的合并不碰人工确认的项，导出导入时已确认、已驳回的项连依据一起带，推断、有确证的项不带。表助手背景里已有的依据写成「以前确认时的依据：……」，系统提示词和 propose_changes 的说明写清那不是这次对话里使用者说的话、引用时写「以前确认时的依据写着：……」，遮罩列的项不给。表详情里依据和说明分开写：表级的项在值下面另起一行，列的一格、关联关系另一个悬停图标（读屏念「确认时的依据：……」），状态弹层里也写，驳回的项只在弹层里写；check-catalog-loop 的假服务端照服务端记下依据，补依据和说明分开、弹层、驳回项的检查；README 表助手一行写上依据另存	2026-10-14 15:38:15 +08:00
ThearchyHelios	cdf5ed38ef	导入目录完成的提示只数真正写进去的表（有新增或更新的项、版本前进了），文件中的项这里都有了的表不算、逐表写「没有变化」；一张都没写进去时说清「没有需要写入的内容」，写入出错的表另外说明；导入之后只重新载入写进去的表；check-catalog-loop 补导入结果的检查	2026-10-14 14:07:15 +08:00
ThearchyHelios	a78affa2f1	目录修改提案落在已驳回的项上时，改前写出被驳回的原值：plan_patch 交回的 before 带上驳回的值、before_status 写 rejected（只改给人看的信息，算改后、算状态照旧按没有这一项，保存时照旧换成人工确认的新值）；助手流的提案卡片、表助手的提案卡片和待保存的修改写「已驳回：<原值>」，和导入预览「目标里这一项已经驳回」一致；check-catalog-loop、check-stream 补对应检查	2026-10-14 14:07:15 +08:00
ThearchyHelios	1d59ba23dc	数据目录闭环（前端）复核修正（表助手）：保存撞上 409 后只按预览重算交去保存的那几项，保存、重算期间回答里又到的提案原样留着、不再被当成不合法悄悄去掉，提案到了也不把正在进行的保存翻回可以点；交给助手的待保存的修改最多 200 项（服务端同一个上限，多了整个请求 422），超出时只交最近的 200 项；开场的留空列取那次起草记下的列名（从那次起草任务里这张表的 blank_sample 取），没写出来的列不再当成留空的列举例，「补上留空的 N 列」点名的正是这 N 列，记全了时只算还没补上的；拿不到（最近一次停止了、任务不在了、老服务端没有列名）时改说「目录里还有 M 列没有中文名和含义」，按钮上的数字就是点名的列数；只读查询后面还有行时写「取回前 50 行，后面还有」，不说成结果一共 50 行；check-catalog-loop 的假事件流照服务端夹 SSE 注释行（「: keep-alive」），提案带 source、table_label，出错码用 assistant_*，假服务端照服务端的上限回 422，补回答进行中保存撞上 409、留空列的三种出处、待保存超过 200 项接着问的检查	2026-10-14 10:10:38 +08:00
ThearchyHelios	299224acaf	数据目录闭环（前端）复核修正（审阅队列）：每一项的位置按 path 说到列（「列 ticket_no 的度量类型」「表的有效记录条件」「指向 members 的关联关系」，同提案卡片），复选框的读屏名也写到列——服务端的 field_label 只是字段的叫法（「码值」「中文名」），列名另放在 column，列级的项只写它分不清是哪一列；审阅进度三行同一个口径：已确认 ÷（已确认 + 待确认），已驳回的、有确证的不计入，审完了就是 100%，悬停写明口径；常用表写实际几张（服务端只算被运行用过的），没有时写「还没有运行用过的表」，不再写死「常用 20 张表」；「用过这张表的运行」写「共 N 次运行」并说明和表头按查询算的使用次数不是一个数，队列里使用次数的悬停同表清单；check-catalog-loop 的队列、进度、导入预览夹具照服务端的真实形状（field_label 只写字段名、带 column，reasons 用服务端的说法，进度带 items_proposed，导入报告带 version、error、冲突的状态），补位置、进度口径的纯函数和页面检查	2026-10-14 10:10:07 +08:00
ThearchyHelios	dff53db165	数据目录闭环（前端）复核修正：停止、服务重启中断之后「只重试这些表」写明会重新起草整张表、已写进目录的内容不会丢，不再说「接着起草剩下的段」——服务端的重试不跳过已写进的段，宽表重试花的时间和额度和第一次差不多；check-catalog 的假服务端中断时照服务端写「已中断：已写进目录 N 段，剩下 M 段没起草」，补一条中断的宽表只写一遍已写进几段、提示写明会重新起草整张表	2026-10-14 10:06:42 +08:00
ThearchyHelios	bc4ea277e9	数据目录闭环（前端）复查修正：部分完成的宽表也写「已写进目录 N 段」（段进度都结束了，看不出写进了几段），服务端原因里已经写了的不重复；表助手「补上留空的列」超过 20 列时写明一共几列；流式回答每来一段只重画正在回答的那一轮；答完的一轮没有用量、没有查询时不再露出一个 0；check-catalog 补部分完成的那一条	2026-10-14 08:51:23 +08:00
ThearchyHelios	a9ffbcfa86	数据目录闭环（前端）：类型、接口、文案和纯函数——起草任务的逐段落盘、块进度字段和清单的 blank_columns_from；审阅队列、成批审阅、审阅进度、用过这张表的运行；导出导入（下载文件、预览、导入）；表助手的事件流（按行读 data: <JSON>，开流前被拒带状态码和机读码，能停止）；表助手的对话怎么截（最多 40 条、每条 4000 字、从用户的话开始）、待保存的修改怎么累积（同一路径以最后一次提案为准、保存带最早那条提案的版本、409 后按预览重算）；审阅视图的地址参数、成批结果和表详情改过之后的状态同步；文案进 lib/terms.ts	2026-10-14 08:44:14 +08:00
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	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	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	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	b4edcadc88	合入期 5 前置修复 L3：记录页的工件列表把双盲复算对照、反方审稿记录、质询回答归到「核查记录」一组，窄屏下说明换到第二行、序号不被截掉；运行对比的默认基准接口带上 previous，运行详情的对比入口在基准不是紧挨着的上一次时写明「与上一次成功的运行对比」，和触发历史一致	2026-10-06 22:19:25 +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	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	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