270 Commits

Author	SHA1	Message	Date
ThearchyHelios	a702a5c14b	普通用户建应用（前端）：新建应用的三个起点（说需求、场景模板、从已有的开始）；蓝图页（对话加卡片、反问选项、关节逐组进度、试运行、发布摘要按你来定 / 助手可以修 / 要找管理员分栏、逐步打勾、接着做）；问数据「做成应用」改走蓝图；问数据和画布的反问收尾；页面上直接改（选中、改字、隐藏、挪动、删除、加数据卡片、自动存草稿）；文件控件；我的记录列表；个人应用的界面（我的应用、刷新与剩余次数、提交审核、审核待办卡）；设置页的个人应用开关；四个新检查脚本并加进完整关口	2026-10-15 12:09:29 +08:00
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	77cd95901a	完整关口收尾：端点认证头重名只标后加的那一行（原有的那行本身没错）；check-apps 实例状态只认状态标签本身（标签里嵌着带 data-status 的图标）；check-app-editor 选人输入框挂了候选列表，角色是 combobox，按输入框定位	2026-10-15 07:27:57 +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	bff3062a97	集成收尾：前端约定写入后端实际返回的形状（应用详情只对 manage 给草稿、补算计划与结果、按名字的钩子行、能力字段审阅），去掉多种字段名都认的兼容解析；钩子按（应用, 名字）、应用助手对话按（应用, 建立人）加唯一索引，迁移前去重，插入改在保存点里、撞上就改用已有的那一行；口径卡固定的版本也须已发布且未退役，记级别之前有正式运行凭据的老版本启动时补记为已发布；证据面板和应用视图按列名遮端点快照（同一个函数），不再整张表遮掉；待办计数带上最新一条的时间，新待办通知不再漏；非管理员的搭建者不出模型接入的改动按钮	2026-10-14 22:08:33 +08:00
ThearchyHelios	1dd4f93579	应用平台集成（前端）：钩子按名字管理并只显示一次密钥、按新口径补算、应用助手对话历史、设置页按角色收起与身份设置补管理员用户名、按需视图每日上限、界面偏好按角色只存本地、使用者问数据用数据源名单并在运行流连不上时改轮询、能力字段待审阅、记录页按来源筛选与待办 id、编辑器的入口 / 表单 / 待办外观 JSON 分区、画布 ?publish=1、工具页绑定端点与 MCP 认证头掩码编辑、派给自己的新待办系统通知、样例与检查脚本改走待办接口（含统一复核后的修复）	2026-10-14 21:55:51 +08:00
ThearchyHelios	04ffce252a	集成：冻结文件按各包请求一次补齐——对话表加建立人（开登录后按人隔离对话）及迁移和索引，钩子回执、投递记录的状态注释；前端约定补待办的节点名与运行类别、生效记录的幂等键等字段、发布结果的级别与哈希、视图来源的种类、各组件数据形状的说明、钩子、助手的澄清问题与应用润色的请求和结束事件	2026-10-14 20:06:27 +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	c38c0043a4	契约骨架补充：运行路径上的能力登记函数给出和今天一致的默认实现（并行开发互不卡住），build_tools 加 allow_write 参数；前端补 ViewRenderer、PrincipalPicker 的接口桩和按草稿预览的参数	2026-10-14 17:56:54 +08:00
ThearchyHelios	220fd0e365	应用平台契约骨架：新表（身份、能力与端点、应用、待办与生效记录、通知）与迁移（补列、多列索引），运行来源与新事件类型，「人」的唯一入口 api/deps.py（关登录时行为不变），应用描述与表单的形状、受信组件目录 v1，各包跨包函数的签名桩，新路由登记，发布门禁的扩展钩子 EXTRA_LINTS；前端接口约定 typesApp.ts、各接口文件、SchemaForm / TaskCard 的 props 与最简实现、应用相关路由与占位页	2026-10-14 17:53:40 +08:00
ThearchyHelios	085fcb7e81	助手流「建议更新数据目录」那一行展开的明细，改前改用和卡片同一个写法（patchBeforeText）：提案落在已驳回的项上时写「已驳回：可累加 → 存量」，不再写成像是当前值的「可累加 → 存量」、和同一轮下面卡片的「已驳回：可累加」对不上；check-decode 补一条	2026-10-14 15:38:22 +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	6b94811bed	审阅队列成批审阅之后列表头的「N 项待确认」跟着变：总数减掉列表里已经不是推断的项（成批审阅、表详情里改过的），撤销审阅回到推断的、冲突的照算，和视图标签、按表筛选的计数同一个口径；载入下一页的偏移用同一个算法；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	20bef14520	保存目录修改提案时依据随项保存：表助手、助手流里「建议更新数据目录」的提案经 /catalog/{table}/patch 保存，写了依据的项备注记成「依据：……」（超出目录文字项的上限 500 字截断），没写依据的照旧；值不变、保存即确认的项和沿用了测量备注的关联关系，依据写在原来的备注前面（关联关系的剖析备注再剖析时整段换掉，放在前面才留得住）。表详情里人工确认的项有备注时也看得到：表级的项写在值下面（同有效记录条件的说明），列的一格、关联关系悬停看；check-catalog-loop 的假服务端照服务端记下依据，补保存后看得到依据、人工确认项的说明两处检查	2026-10-14 14:07:14 +08:00
ThearchyHelios	5b5b6d8df2	起草逐表行列出服务端记下的说明（task.log：没收下的有效记录条件和原因），check-catalog 补一项；README 数据目录一节补上防错事实的提议、审阅队列、表助手、导出与导入，模型起草一行写上逐段落盘、不设总时长上限与按比例止损、块进度、同步起草与任务互斥	2026-10-14 10:19:18 +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	41012b1b83	数据目录闭环（前端）复查修正：导入预览里跳过的项写界面上的说法（「列 gate_code 的中文名」），关联关系照编号写；check-catalog-loop 切视图的那一条等清单真的换回来再断言	2026-10-14 08:54:04 +08:00
ThearchyHelios	bc4ea277e9	数据目录闭环（前端）复查修正：部分完成的宽表也写「已写进目录 N 段」（段进度都结束了，看不出写进了几段），服务端原因里已经写了的不重复；表助手「补上留空的列」超过 20 列时写明一共几列；流式回答每来一段只重画正在回答的那一轮；答完的一轮没有用量、没有查询时不再露出一个 0；check-catalog 补部分完成的那一条	2026-10-14 08:51:23 +08:00
ThearchyHelios	a6e5b857fe	数据目录闭环（前端）：数据目录页左栏加「审阅队列」视图——照服务端的优先级列出推断项，每项写位置、所在表、值、说明、为什么排在这里、来源和状态、所在表的使用次数，按项（影响数字的项 / 名称和含义）和表筛选（记在地址里），多选成批确认、驳回、撤销审阅（逐表带读到的版本，逐条的结果原地标出、冲突的写明），顶上是审阅进度（常用 20 张表、全部表、影响数字的项），点开一项右栏是所在表的详情（滚到那一项、列出用过这张表的运行），详情里改过之后队列跟着换状态；页头加「导出目录」（下载服务端给的文件）和「导入目录」（选文件 → 预览对上的表、新增 / 更新 / 保留 / 冲突 / 跳过，冲突逐条列出 → 确认导入 → 逐表写入后的版本，起草任务进行中、文件格式不对时照原样写服务端那句话）；新检查 check-catalog-loop（表助手、审阅队列、导出导入、防错事实的说明和纯函数，用 page.route 假接口），登记进 check-all	2026-10-14 08:44:49 +08:00
ThearchyHelios	1cc9fe1a3d	数据目录闭环（前端）：表详情加「表助手」——顶部和上次起草的提示里都有「和助手一起完善」入口，对话流式显示、能停止，助手跑过的只读查询写 SQL 和前几行（默认收起），修改提案逐项写改前、改后、依据并能逐项去掉、加回，「待保存的修改」跨多轮累积（同一项以最后一次提案为准），一键保存（最多 200 项，409 时按最新内容重算后停下来再看一眼），没开数据剖析的源写明只能根据表结构和目录推断、不能查数据，有留空列时开场引导先问这几列，有待保存的修改时换表、关闭先问；表详情加「用过这张表的运行」、有效记录条件和去重规则的推断项在值下面写说明（剖析核对的排除比例或没核对的原因）、从审阅队列打开的那一项标出来；起草任务逐表显示块进度（段被拆小后看得出来）和已写进目录的段，停止后写明已写进几段、只重试时接着起草，清单和表详情在最近一次停止、中断又没有新写入时接着用再之前那次起草记下的留空列数提示；check-catalog 加一节按约定的新字段推进	2026-10-14 08:44:37 +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	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