365 Commits

Author	SHA1	Message	Date
ThearchyHelios	034ac4b63b	W4R-04 数据源页：指名一张卡片的地址全站只认 #source-<id>，带 &maintenance 打开它的定时维护 ... 复核 W4R-04：定时任务页上维护定时的「去数据源页设置」链的是 /data/databases?source=<id>，数据源页只认 #source-<id>（目录页 任务条上探查的「查看」用的写法），没人读 ?source，点了落在列表顶上，既不滚到那张卡片也不打开定时维护。 改法按复核意见统一到 #source-<id>，数据源页这边： - 新的 lib/sourceAnchor.ts 管这个地址的拼和拆（sourceAnchor / parseSourceAnchor / sourceCardId），两边各写一遍的话改一边 另一边就落空。目录页任务条上探查的「查看」改用它，拼出来的地址和原来一样。 - DataSourcesTab 按 useLocation 的 # 处理：列表载入后滚到那张卡片；带 &maintenance 的再打开那张卡片的「定时维护」（只有 手工登记的库才开，上传表格、记录表照旧没有这个入口），标记用过就从地址里去掉，刷新不再弹（同目录页的 pjob / djob）。 - 指名的数据源已经不在了（维护定时比数据源活得久，删数据源不删它）：照实说「没找到这个数据源，可能已经删除」，不然只是 落在列表顶上、什么也没发生。 定时任务页那边的链接（ScheduleDetail.tsx，W4-b 的文件）这里不动，要改成 /data/databases#source-<id>&maintenance （或 sourceAnchor(id, 'maintenance')），check-schedules 的断言跟着改。 check-catalog-changes 加一节「链到一张卡片」：前面垫十张库让那张落在第一屏下（先有对照：不带地址时看不见）；带 &maintenance 打开那张卡片的定时维护、滚到眼前、地址里只剩 #source-<id>；刷新只滚不弹；源不在了照实说；导入表格的源不弹；只是打开没有 保存，没有写请求。先写这一节跑出 6 项失败；修完 115 项全过；把打开、去标记、照实说三处去掉回跑，4 项报错，已还原。	2026-10-16 21:37:25 +08:00
ThearchyHelios	4a81ad25bf	check-auth：导航从九项变十项（搭建者、关登录各一处） ... 第 4 波加了顶级导航「评测」（搭建者以上可见，评测-D8）：check-auth 里「搭建者：导航九项」「关登录：导航九项」两处按数目断言， 跟着改成十项，搭建者那处另断言「评测」在里面；使用者那处（只有应用和设置）不变。check-auth 不在 check-all 的清单里，另起一套 后端 + vite 跑了「导航」「关登录」两段，全过。	2026-10-16 20:55:22 +08:00
ThearchyHelios	badd610cd2	评测页补齐：工作流题、手动清理更早的明细、逐题明细里的作答经过和答案原文 ... 前三波的接口这一波都要有界面（收口）： - 加题时「写 SQL 定期望」「选口径」两种可以选题目种类——问数据题（问法交给助手）或工作流题（固定一个已发布版本、按入口字段填 输入模板，考的是这一版本身）；题目表里工作流题写工作流和版本。反问、从运行认定只对问数据题有意义，不给选。 - 评测记录页签加「清理更早的明细」（POST /suites/{id}/cleanup，先确认、写清后果；收尾时本来就按保留规则自动清，这里是手动再清一次）。 - 逐题表展开时读这一题的明细工件（GET …/results/{id}）：自动重来了几次、作答的经过、答案原文——答错的题能看到它当时答了什么。 check-evals 跟着加三处（工作流题的请求体、清理先确认再发、明细），101 项。	2026-10-16 20:41:50 +08:00
ThearchyHelios	45c1ede402	评测前端：顶级导航「评测」、题集与加题、发起评测、评测详情、口径命中与重复度、目录快照；定时页选目标种类；记录页评测来源；设置里评测一组 ... 为什么：前三波评测只有接口，这一波是收口——每样能力都要有界面、能走通（细案 01 第 18 项、第 15 项定时的前端部分，评测-D8）。 界面层不放逻辑：比率、结论、趋势、分档、能不能做都由服务端给（上一次提交在 api/evals.py 补的 latest、trend、actions、 preview、signals、逐题花费），界面只显示。 - 导航：「评测」排在设置前面、⌥0，搭建者以上可见（使用者的页面表在 visiblePages 里收窄，手输地址被送回应用首页）。导航从 9 项 变 10 项，在 600、520、480 像素高的窗口里重新量过：≤520px 那档的导航项从 32px 收到 30px（17px 图标 + 2px + 11px 字）， 不然 480 高时遥测点超出视口 12px；App.tsx 的说明跟着改。 - 评测页 pages/evals/*（类型 typesEval.ts、接口 api/evals.ts、文案 lib/termsEval.ts 的 EVAL_TEXT）：题集列表（最近一次、同一 变体的趋势、定时，没有定时给「设定时」带着题集去新建）；新建、导入（先预览）、导出、归档、删除、题集设置（时区、默认变体—— 定时评测按它评、预算只填要改的项）；题目表（启用、试算、编辑、删除），口径升版待处置的顶部提示和三选一处置（叫法由服务端给， 没有缺省）；加题四种方式：写 SQL 定期望（选数据源、写 SQL、预览、点选格 / 列 / 配对列、按维度找行、试算，遮罩列拒收的原话 落在 SQL 下面）、选口径（工作流｜口径卡｜指标，不能复用的照列写原因，口径的输入按那一版的入口字段填）、从问数据运行认定 （选运行、选查询、选取哪一列，用到遮罩列的查询不给认定）、期望没有数据或期望反问；可另加文字要点。数值期望不许人填：只点选 取哪一格。 - 发起评测：评一次 / A/B 对照（两到三臂）/ 目录贡献对照（预设，可加「只用已核实和已确认的项」），变体有助手、写作模型、结论 裁判、目录（当前 / 只用已核实的 / 关 / 快照）、重复次数；估算和发起是同一份请求体，项数、按上一次估的花费、生效的预算、今天 已花照服务端写；可点名和哪一次比。 - 评测详情 /evals/runs/:id：进度和每题正在做什么、停止、只重试没做完的、按新规则重评、设为基线（按钮照服务端的 actions 摆）； 总览卡片（准确率和可追溯准确率带区间、花费、逐题 E1）和各项分布（结论、作答路径、出具档位、复核、结论裁判、引用率、查看、 耗时、按角色的用量）；逐题表（结论、期望和答案里的数、弱匹配、SQL 差在哪、查看、耗时、花费，展开看原因、去运行详情； ?case= 定位那道题）；和上一次比（换基准、指纹差异、转移和归因）；A/B 配对表（都对 / 只 A 对 / 只 B 对 / 都错、p 值）。 - 「口径命中与重复度」页签：E1、E3 这一窗口的值和档位、参考线、往前几个窗口的趋势（GET /api/evals/signals），明细直接调口径 账本的 GET /api/ledger/stats（总方案 X2）；成员不少于 3 的问题类能加入题集（带着问法去加题）、提取模板（从最近一次的运行提取， 去画布）。目录快照页签：拍当前目录、影子起草（先估算再开始，能停）。 - 定时页：新建时先选定时什么（工作流 / 评测题集；数据源维护在数据源页建），评测题集的表单（pages/schedules/TargetEditor.tsx：名称、题集、 FreqPicker、补发宽限，建题集目标用 ScheduleTargetCreate），评测题集的定时在详情里能改名称、频率、时区、补发宽限（SchedulePatch， 只交改了的、带版本）；数据源维护的定时只读、链到数据源页，第 3 波「只能查看，不能修改」那句改成说清在数据源页设置；触发历史里 的评测链到评测详情。纯函数 targetFormOf / targetCreateBody / targetPatchBody / targetProblems 放 model.ts。 - 记录页：评测运行旁的「评测」标记写是哪一步（作答、算期望……），点了回到评测里那道题；运行详情页头有键盘到得了的链接 （pages/runs/EvalSource.tsx）。 - 设置：偏好设置里「评测」一节（pages/EvalSettings.tsx，SettingsPage 里加一行）：四项预算缺省、保留几次、缺省开不开结论裁判、 今天已花；自己存、只交 eval 一组，取值范围只在服务端判。 - 问数据用量（评测-D14 的界面一半）：复核慢过问数据页的等待上限时，答案照原样先交出去，复核那一次的用量晚到了照记进这一轮、 再落一次库（以前直接丢掉）；开发期 window.__chatReviewWait 让检查脚本把上限调短。 检查：check-evals.mjs 换成真检查（假接口加夹具，写请求在浏览器层拦下并断言请求体，98 项）；check-shell 导航十项、⌥0、三种窗口高； check-schedules 目标种类（纯函数和页面）；check-chat 用量那一段加复核晚到。	2026-10-16 20:38:07 +08:00
ThearchyHelios	9ad6c035d0	口径账本的界面检查：check-ledger 换成真检查，check-evidence、check-chat 各加一段 ... 都用 page.route 假接口加夹具（scripts/ledger-fixtures.mjs：GET /api/runs/{id}/ledger 的形状照服务端 run_view，挂在可点击 证据的夹具 evidence-doc.json 上，只用通用名），写请求在浏览器层拦下、核对请求体，认不出的写请求一律记账、结束时必须为空。 - check-ledger（骨架里的占位换掉）： · 比对还没出结果：「口径」一步写「正在比对口径」、按退避再取（间隔越来越长），等满了照实说、给「再取一次」、不再取， 点了重新取、比对过了就画出来，之后不再取（store/ledger 在开发构建里挂 window.__ledger，把等待起点挪到两分钟前）； · 三种情况：来自口径（口径、级别、怎么认的、参数、事后补比的说明）、相关口径（差在哪 + 看差多少）、这次的推理； · 对账：参数要核对时表单直接打开、照入口字段画 → 发起带核对过的参数（空着的不送）→ 409 带回的选项画「选择要对照的 指标」、一组没选不发起 → 选好再发起带上对照 → 结果卡片先写进行中、再取一次后画出按你的问法 / 按口径 / 差值 / 相对差， 点差值打开出处链； · 可沉淀的问题：工作流列表弹窗里的抽屉，三类来源分开写、各写怎么认出来的；聚类只按那一轮固化；「不是口径」不写理由 不能确认、写了才记下并拿掉这一项；固化走 from-run 的 freeze（带同组的别的运行和来源轮次）、打开画布里的草稿； · 使用者：不能出具的照服务端的原因写「请搭建者出具」、不摆按钮，对账照样能用，出具过的正式运行不给链接、写由搭建者查看； · 设置里口径账本一组：显示生效的值，不合规的值写范围、不让存，保存条写改了哪几项，整组写 ledger。 - check-evidence「口径账本」一节：来自口径的数字挂「受管 / 已发布」小标记（紧跟数字、悬停写口径和认法、读屏念在数字上）， 相关口径、这次的推理、没比对的不挂；面板「口径」一步在出处链最上面，四种标签各写各的，不是数的片段不画；同一次运行只取 一次账本。别的节的夹具一律答不比对，不落到真服务端。 - check-chat「口径账本」一节：交付了的轮次底部先写「正在比对口径」，按退避再取到比对出结果后写摘要、比完不再取；按口径正式 出具、对账按钮照服务端的动作摆，出具的请求只说按哪份口径，出具过的正式运行挂在轮次下面（档位、打开运行）；对账请求带 哪条查询、哪份口径、核对过的参数。	2026-10-16 20:34:21 +08:00
ThearchyHelios	e48b258449	W4-d 收尾：队列里的任务结束时重取变化计数和清单；定时维护里不给探查任务点了没用的「查看进度」 ... - 目录页：后台任务条的队列里有任务走了（结束了）就重取变化的计数、「变化」视图重取一页；走的是探查任务时清单也重取（表结构 变了）。起草、剖析结束时页面跟着的任务本来就会重取清单。 - 定时维护「最近一次」：剖析任务的「查看进度」到数据目录页打开那个剖析任务（pjob）；探查任务没有另外的进度页（进行中时 进度就在这张数据源卡片上），不再给一个关上对话框就什么也看不到的按钮。check-catalog-changes 补上这两条。	2026-10-16 20:14:12 +08:00
ThearchyHelios	bbf6ebb79d	召回收尾：启动时只接着做当前发布版的自动批次、补测重启后从已有召回运行重算计划；时间线认不出的依据种类不猜 ... - ledger/recall.resume：最近发布、之后又发布了更新版本的不再接着做（新版本的召回本来就覆盖更早的所有版本） - 测试：重启前只发起了一组、也没收尾，重启后接着发完自动那一批、补上收尾照样开待办，再重启一次不再发起 - run/decode：ledger.basis_changed 认不出种类时写「答案的依据有变」，不当成目录事实变了；batches 的说明照实写参数原样给搭建者	2026-10-16 20:11:46 +08:00
ThearchyHelios	9252e6bb0e	W4-d 检查：check-catalog-changes 换成真检查；check-catalog、check-catalog-profile、check-catalog-loop、check-capabilities 跟上 ... - check-catalog-changes（骨架里的占位换掉）：假接口加夹具（虚构的网店库），写请求在浏览器层拦下、断言请求体。守的是「变化」 视图的分组（要处理 / 提醒 / 说明，组内照服务端的先后）、两种筛选进请求和地址、刷新后还在；一条变化的依据、前后、影响面 （目录项现在的状态、「这条 SQL 现在会报列不存在」、模板链到编排页那个节点、有效记录条件）；动作照服务端给的 actions 画、做不了 的写原因；清理先确认、加入码值带含义、知道了、误报的请求体，误报没写理由（含只填空白）按钮不能点；处理完写目录版本、建了的 起草任务点得进进度；表详情一节（变化、撤销过的「已列全」、四种观察和口径、口径换过的提醒、断档的日子也在小柱图里）；数据源 角标（读屏写全、点了到「变化」）；定时维护缺省关、开启时提示低峰时段、建（target_kind=source_maintenance）和改（PATCH 只带 改了的和版本）、步骤走 PUT、最近一次建了哪个任务和哪几步没执行；后台任务条按服务端的两种先后、页头读屏不写数字、提醒在条上 写全文、「查看」打开对应的对话框、探查的到数据源卡片；窄屏不撑宽页面。去掉排序、去掉「没写理由不能点」回跑，这几项都会报出来。 - check-catalog、check-catalog-profile：DraftStrip 的断言换成后台任务条（data-catalog-job-strip、data-catalog-job），页头的 「起草」「数据剖析」只断言读屏写状态、不写数字；剖析的「最近查询多数超时」改在任务条上断言全文；check-catalog-profile 的假接口 按建的先后给出队列，两种排法（起草在前 / 剖析在前）的文字都断言；窄屏下任务条看得见。三个目录检查都给变化、观察、后台任务、 upkeep 配上空的假接口，不把假的源放行到服务端去查。 - check-catalog-loop.mjs 的 PROFILE_ON 换成 table_max_queries: 40、table_max_s: 60（和 check-catalog-profile 的 DEFAULTS 一致， 05 (g)）。 - check-capabilities：全局渠道可订阅的事件里有了「数据源有变化要处理」（第 4 波打开了订阅），登记了还没推送的只剩召回。 本包相关的检查（catalog-changes、catalog、catalog-profile、catalog-loop、capabilities、manage）在另起的一套后端 + vite 上都过了。	2026-10-16 20:05:43 +08:00
ThearchyHelios	35583ba1d8	口径召回前端（W4-a）：版本用量加问数回答和召回、发布弹窗预告召回规模、版本历史看召回批次、recall 待办卡、时间线认两个新事件 ... 为什么：前三波召回只有接口；这一波收口，口径升版之后谁的答案受影响、重算了几组、数变没变、怎么处置都要在界面上走得通。 - canvas/versionUsage：使用情况那一行加问数回答、导出、定时任务、召回（老服务端不给就不写） - canvas/RecallPanel（新）：发布弹窗「召回」一行——旧版本被谁用过、按参数去重几组、发布后自动重算几组、超出上限几组（可在 版本历史接着算）、上限为 0 时只列不算、不能重算的原因；版本历史展开一版——每组结论（数变了 / 没变 / 无法重算：原因 / 重算失败 / 正在重算 / 未重算）、变了的指标、开了几条待办、召回运行链接，「另有 M 组未重算」+ 接着算 - run/RecallTask（新）+ TaskCard：recall 待办卡——旧口径、新口径、两版之差一行一个指标，每个数点得开召回卡的指标链；每个答案 当时的值点得开（正式运行的口径卡、问数回答的查询快照），问数回答链回对话；「按新版重新出具」（不能时停用并写服务端给的 原因）、「知道了」；遮罩值写已遮罩、点不开；目录有变、表结构变了两种只有「知道了」 - run/decode：ledger.recalled（已按 vN 核对，不影响；召回核对数变没变；试算结果）、ledger.basis_changed（依据有变、依据的 表结构已变）；缺字段不猜 - 文案进 lib/termsRecall.ts；接口 api/recall.ts、形状 typesRecall.ts；TaskKind 加 recall - 检查：check-inbox 加 recall 卡两段，check-publish 加召回预告和召回批次两段（版本历史、发布弹窗都在这里测；check-versions 测的是上传表格的版本页，和召回无关），check-decode 加两个新事件的夹具，check-capabilities 的可订阅事件跟上 ledger.recall	2026-10-16 20:05:24 +08:00
ThearchyHelios	4c7c0cf283	驳回节点的画法（前端）：被驳回的那一步画成「被驳回」，不画成失败 ... 服务端给被驳回的那一步的 node.failed 带上了 reason=rejected（上一个提交）。界面上读 node.failed 的几处都认它 （05-已知遗留 (a)、总方案 X9：驳回是人的决定，不是故障），没有 reason 的老运行照旧画失败： - run/decode：问数据过程、记录页、画布右栏的时间线里，这一步状态 rejected（StepStatus 加一种），副标题写谁驳回、 备注（REJECTED_TEXT.step），原话放展开里；不是 error 级别，不当成出错 - run/trace、run/derive：NodeState 加 rejected；那一段收成 rejected，不记成「失败的节点」，下游是「未到达」不是 「被阻断」；回放投影同样是 rejected - 画布节点卡：rejected 一种读数（耗时 + 原话第一句，整句悬停），中性色、停止剪影，不挂失败红框、不抖动；小地图、 运行胶囊的计数、时间轴泳道认得它；记录页航迹的节点卡写「被驳回：原话」 - check-decode、check-run-states 各加一段：新旧两种形状	2026-10-16 19:42:11 +08:00
ThearchyHelios	45fab21072	第 4 波契约骨架：频率选择抽成公共组件 components/FreqPicker.tsx（频率与时区的纯函数搬到 lib/freq.ts，pages/schedules/model.ts 原样再导出），定时维护和定时任务共用；前端类型加 ScheduleTargetCreate（建评测题集、数据源维护这两种非工作流目标），api.schedules.create 收它；设置 ledger 一组加 recall_limit（口径升版后每次最多重算几组，缺省 50，0 表示不自动重算）；test_notify_events 的 PUSHED_THIS_ROUND 拆成一项一行、给 source.changed、ledger.recall 各留一个位置；check-all 预登记 catalog-changes、evals、ledger 三项检查（先放占位）	2026-10-16 19:09:47 +08:00
ThearchyHelios	337513b83d	check-publish：「版本列表标出已退役的版本」等列表取回再数（并行时打开那一刻列表还是空的，偶发不过）	2026-10-16 18:59:50 +08:00
ThearchyHelios	eb6e3c7ab7	合入 W3-d 邮件、待办汇总、分享链接：邮件渠道（SMTP 可选、口令加密、退信不追踪）；每天的待办汇总与访问密钥到期提醒；分享链接（只存哈希、必设到期、只显示定时出数的视图、/s 页不进外壳、下载报告）；「最近一次封存」按来源白名单认；使用者拿不到邮件渠道的收件地址；同站门户嵌整站的配置说明	2026-10-16 18:48:07 +08:00
ThearchyHelios	1c8ca4c3d7	合入 W3-c 评测执行：后台评测与无头作答、六种期望五种结论的评分、重评、结论裁判记评测账、统计（Wilson 区间、按角色用量）、对比与 A/B（McNemar）、目录贡献预设、预算与止损、清理；定时任务接题集目标，定时评测有退步 / 没有评完推全局渠道；定时页照实显示非工作流目标	2026-10-16 18:46:44 +08:00
ThearchyHelios	defdb28e3f	合入 W3-b 口径账本闭环：caliber_from.nodes 改名映射；问数据的助手 use_caliber 选用已发布口径（服务端确定性内联实例化）；按口径正式出具（自动只给问数据的答案）与口径对账；认证队列、固化成口径草稿、发布后补比；账本统计补上对账与认证转化；使用者的原始运行记录只给问数据的运行	2026-10-16 18:45:45 +08:00
ThearchyHelios	72a45f3ef3	check-capabilities 跟上全局渠道推送的定时评测两个事件（复核 M1） ... W3-c 打开 eval.regressed、eval.failed 的全局渠道订阅时没改这项检查的期望，分支上「全局渠道：推给全局渠道的五项」和「登记了 还没推送的不列」两项就不过（复现：check-capabilities 63 通过、2 不过）。 - 全局渠道的期望改成 [...every, 'review.done', 'eval.regressed', 'eval.failed']，标题照 W3-d 的写法叫「推给全局渠道的几项」， 合并时两边的期望并在一起即可；个人渠道、应用渠道的期望不变（这两个事件只推全局渠道）。 - 「登记了还没推送的不列」里去掉评测的两项；另加一项：全局渠道列出的叫法照实带「定时」（定时评测有退步、定时评测没有评完）。 check-capabilities 66 项、check-schedules 355 项全过。	2026-10-16 18:23:03 +08:00
ThearchyHelios	8181efe836	W3-a 前端跟上：运行里的结构变化提醒、剖析清单里取值观察的说法 ... 后端这一波新写的 schema.drift 事件、剖析任务里的取值观察检查，前端不跟上就是半截的： - run/decode.ts 认 schema.drift：时间线里一行警告（运行未被拦截），展开逐表写发布时和现在的结构版本、表删了写「表已删除」， 下面列出还没处理的结构变化；schemaDrift / schemaDriftLine 解析，和 catalog.drift 分开记、不混读版本号。 - 运行横幅（pages/runs/Banners.tsx）：和 catalog.drift 共用同一块横幅（data-run-banner 不变）。只有结构变了时标题按结构说； 目录、结构都变了时结构另起一组带小标题；每张表给到数据目录的入口。RunDetailView 取最后一条 schema.drift 一并传进去。 - 剖析清单：取值观察的四类检查（行数、码值观察、最新业务日期、按日行数）在检查项、发过的查询、跳过的项里有中文叫法； 逐表进度多一类「取值观察 N/M」（后端 checks_by_kind 加 observe 一组）。剖析的范围、任务的触发（定时维护建的）进类型。 - 文案进 lib/terms.ts（SCHEMA_DRIFT_TEXT：叫「结构变化」，和已有的「目录有变化」分开，X10）。 - 检查脚本：check-decode 加 schema.drift 一节（标题、警告级、逐表版本、表已删除、另有几条、形状不对不出行），check-runs 加一节（只有结构变化、目录和结构都变了两种情形下的同一块横幅、入口链接、时间线一行、运行照常完成）。 验证：tsc、check-copy；decode 680、runs 327、catalog-profile 191、stream 461、publish 285 项全过。	2026-10-16 17:28:07 +08:00
ThearchyHelios	ed72ee68d6	W3-a 关联覆盖率下降、清理目录跨表、扩容器集成测试到对象索引和取值观察 ... - 剖析核对关联关系时，覆盖率从够有确证的线（95%）掉到线以下的记一条 coverage_drop（取值变化，warning）：剖析本身照旧 按规则降回推断（人工确认的只补上新的覆盖率），这里只把「覆盖率下降」留进变化记录。人点的剖析也记（变化记录全站一份）。 关系的发现里多带 previous_coverage。 - 处理动作「清理目录」逐表清：这张表上说到被删的列的项，加上别的表指向它的关联关系（表删了时尤其如此）；记这张表的 目录版本，别的表也动了的另记 catalog_versions。 - 剖析任务的逐表进度多一类 observe（取值观察的四类合成一组），前端「取值观察 N/M」用它。 - 定时维护补一条测试：AGENTLAB_SCHEDULER 关着时调度循环不起，到点的维护不触发、不建任务。 - scripts/dialect-it.sh / dialect_it.py 扩到第 2 波的对象索引字典查询（走字典查询不退回 Inspector、类型、表注释、行数 估算、Oracle 小写名的 quote）和这一波的取值观察（经剖析引擎只观察：行数、小表码值整表、大表 PG / Oracle 块采样、MySQL 前 N 行、最新业务日期排除无效日期，max_date_sql 直接跑）。夹具的订单表加了表注释。本机跑了一次四种库的容器 （postgres:16、mysql:8.4、mariadb:11、gvenzl/oracle-free:23-slim）：121 项全过、0 项不通过，跑完容器已删、镜像留着。 验证：后端全量 14046 通过（11 跳过、8 预期失败）。	2026-10-16 17:28:07 +08:00
ThearchyHelios	538799e70d	沉淀：认证队列、固化成口径草稿、发布后补比；账本统计补上对账与认证队列的转化（口径账本做法 8、10，拍板 L9） ... 为什么：同一类问题被反复问、Agent 反复写出同一个形状的 SQL，就该沉淀成一份口径；以前 from-run 保留 Agent，沉淀出的模板没有固定 SQL，以后永远比对不上。第 2 波的统计在 E2 反馈、E3 认证队列上照实写了「目前没有数据」，这一波补上能补的。 做了什么（新增 ledger/certify.py）： - GET /api/ledger/certify-queue（搭建者）：确定性重复（问数据运行里被报告引用、没对上口径的查询，按数据源 + normalize_sql 文本分组，≥3 次运行且来自 ≥2 段对话；跨运行变化的字面量是参数候选，展示的形状不带取值）、问题聚类（app/chat/questions 全站唯一的那份）、被反复用的答案（导出 ≥2 次用第 2 波的 report.exported 审计、做成过应用看蓝图来源、在画布里打开或提取过看工作流 origin）。每项给代表问题、轮次、相关口径、是否已固化。 - POST /api/ledger/certify-queue/dismiss：「不是口径」写审计 ledger.certify.dismiss，之后不再进队。 - 固化成口径草稿（from-run 加 freeze、peers 后转调 certify.freeze）：报告引用的查询变成固定 SQL 的取数节点，跨轮变化的字面量换成 '{{ input.pN }}'（缺省值取代表运行的），单行结果的数值列成口径卡指标，报告核对规则按受管要求写、契约 report_from + metrics_from + required（多行加 cells）；过 validate_graph 和受管门禁。新工作流 origin.sources 记来源问题。 - 发布之后补比：api/workflows.commit_publish 提交后调 certify.after_publish，来源运行按新口径补比一次（新的 trigger=certified，界面写「按之后发布的口径回看」，时间线和账本接口同一句）。 - 统计：E2 加对过账的答案数、参数经人核对的、指标由人选的次数（反馈照实写第 4 波）；E3 认证队列的转化（固化、发布、不是口径）。 测试：tests/test_ledger_certify.py（参数推断与模板、三种信号进队、门槛、不是口径、固化草稿过受管门禁、发布后来源运行补比成等价已证明并出队、再问标等价已证明、统计）。	2026-10-16 17:06:41 +08:00
ThearchyHelios	df6c3ce10d	定时页照实显示非工作流目标；评测停止时几臂一起收尾；工作流题的测试 ... 为什么：这一波后端开始接受评测题集、数据源维护这两种定时目标（总方案 X4），定时页要能把它们照实列出来、点进去 不报错；界面上不能有点了没用的入口。 - 定时页列表：非工作流目标写种类（评测题集 / 数据源维护）和目标名，不标运行类别，「编辑」写成「查看」 - 详情：非工作流目标的设置只读地列出名称、目标、频率、时区、补发宽限，不出工作流那张表单（选工作流、输入模板、 Webhook 对它们不适用）；页头的启用、立即运行、删除和触发历史照常 - 立即运行发起的是一次评测时说「已发起一次评测」（以前会落到「未能发起运行」）；触发历史写评测的编号 - types.ts：Schedule 加 target_kind / target_id / target_label / target_name / target_exists，触发记录加 eval_run_id； 文案进 SCHEDULE_TEXT - check-schedules 加一段「目标不是工作流的定时任务」 - runner：还没准备好就被停下、出错时，按 pair_id 找全几臂一起收尾 - 测试：工作流题按钉住版本跑探索运行（不发正式运行、不建图）；钉住基线的接口 - 后端几句给人看的话按文案规范改（不用「跑」「钉」）	2026-10-16 17:04:05 +08:00
ThearchyHelios	1fe3d85773	W3-d 检查脚本：check-share 新建，check-capabilities 加邮件 ... - check-share.mjs：/s 分享页不进外壳（整页只请求分享页一个接口）、key 只在请求头里、视图照画而流程组件是说明、印章常显、 页脚、点数字说明出处在报告里、下载报告带请求头、撤销 / 到期 / 链接不完整写明、没允许嵌入的在 iframe 里不显示；应用编辑里 开关没开时不给新建、建分享链接只显示一次、列表与撤销。接口全部伪造，按路径开头拦（前端模块地址里也有「/api/」） - check-capabilities：「邮件服务」一节（管理员改、搭建者只看、口令只说设没设、有改动时不能发测试邮件、测试邮件照服务端 的话写「已交给邮件服务器」）、待办汇总的发送时间只交这一项、邮件服务没启用时不列邮件格式、个人邮件渠道写「发到账号邮箱」 且建的时候不带地址、投递记录写「已交给邮件服务器」；可订阅事件的期望跟着第 3 波打开的待办汇总、密钥快到期更新 - check-all 登记 share	2026-10-16 17:00:49 +08:00
ThearchyHelios	f887cdc30a	W3-d 邮件、待办汇总、分享链接的界面 ... - 设置 → 通知：渠道多一种格式「邮件」，邮件服务没启用时不列；个人邮件渠道不填地址，写「发到账号邮箱 …」（账号没有邮箱照实写 发不出去），全局、应用的填收件地址；投递记录里邮件成功写「已交给邮件服务器」、悬停说明退信不追踪；新增「邮件服务」一节 （管理员改、搭建者只看：口令留空不改、可清除，发测试邮件要先保存）和「每天的待办汇总」的发送时间 - 设置 → 偏好设置的「应用」一节：「允许建分享链接」开关（缺省关，写明关掉时已有的一并打不开） - 应用编辑 → 岗位与授权：分享链接的管理（选页面、始终最新 / 固定这一期、有效期 1–90 天、允许嵌入；链接只显示这一次； 列出状态、到期、打开次数，撤销先确认）；开关关着时不给新建，已有的照列能撤销；个人应用写明不能分享 - /s 分享页：不进外壳（App 在 /s 上整个跳过认人、取目录、心跳、读主题，请求层在 /s 上也不送去登录页），key 从 # 后面读、 放进请求头；同一个 ViewRenderer 渲染、操作全禁用；印章常显（「数据的来历」逐个列视图的印章）；点数字说明出处在下载的 报告里；页脚「只读 · 由 X 于 … 分享 · … 到期」；撤销、到期、关了开关、链接不完整按服务端的话写明；没允许嵌入的分享在别的 页面的 iframe 里不显示内容、给「在新窗口打开」 - ViewRenderer 加 onEvidence：点数字交给调用方（分享页），不开在线证据面板 - check-copy 加「快照链接」一条（总方案 X10：写「分享链接」），带自检	2026-10-16 16:44:06 +08:00
ThearchyHelios	4f4ad48ad7	组合式问数：问数据的助手可以 use_caliber 选用已发布口径，服务端确定性内联实例化（口径账本做法 4，拍板 L3） ... 为什么：问数据以前看不到口径，也没有组合机制；子图做骨架的路走不通（子图证据不交回父图、使用者用不了子工作流）。改成助手只选口径、填参数，取数节点由服务端按固定版本照抄，证据照常封存、比对照常复证。 做了什么： - 问数据的查看对象加 caliber（look/calibers 的 compose 模式）：另给每张卡的入口字段（类型、必填、可选值、格式、缺省值）和「能不能组合」（ledger/derive.load_pinned 同一个认法），能组合的写出 use_caliber 的写法；仍不给 SQL。只给搭建者及以上：使用者的图里看得到拷进来的取数 SQL。 - 新增 ledger/compose.py：use_caliber {id, workflow_id, version, card, metrics, inputs} 经 derive.caliber_block（扩了 card_id、inputs 两项）实例化——取数节点照抄、id 加前缀、模板按参数渲染成字面 SQL，口径卡 id 就是操作 id、caliber_from 带改名映射。参数按入口字段过 apps/forms 校验，写进 SQL 引号里的不能带引号、裸写的只能是数；只能选这一轮看到的那一版、能组合的卡、卡上的指标；不合规拒收。 - GraphApplier 落地 use_caliber：节点、连线记进 seen（兜底重放照样在），入口连到第一个取数节点；转给界面的只有那一条操作带 result；拒收的原因经自查交回模型（GraphChecker.issues）。 - 提示：协议多一段 USE_CALIBER_PROMPT；LOOK_WHEN 里问数据那一条按细案改写（只在能选用口径时换）。运行时写 SQL 的 Agent 不看口径（L2）。 - 比对器认出助手选用的查询（从封存的图里读 caliber_from.nodes）：证明了的标 composed「助手选用」，没能证明的照常是相关口径并说明；标签 how=composed，指标标签记取自哪几条查询；比对算法版本升到 2。 - 前端：问数据过程里 use_caliber 照实显示一行（选用了哪一版、生成几个节点；拒收写原因），节点数算进「新增几个步骤」；文案进 LEDGER_TEXT.use；check-decode 加一节。 测试：tests/test_ledger_compose.py（实例化确定性、各种拒收、查看文字不带 SQL、提示切换、落地与接线、拒收交回模型、剧本模型走一遍生成再真跑出 composed 标签、使用者不给口径）。	2026-10-16 16:35:28 +08:00
ThearchyHelios	ee8c0317a2	合入 W2-d 访问密钥与服务账号：服务账号（管理员建、不能登录）与个人访问密钥（管理员开关，缺省关）；只存哈希、必设到期、轮换与撤销；按路由白名单放行、封顶在使用者边界（看到的都遮过）；发起入口和刷新视图必须带幂等键；视图数据接口 agentlab.viewdata/1；审计、请求记录、钩子收件记录；接口说明；设置里的访问密钥页	2026-10-16 15:38:33 +08:00
ThearchyHelios	64ed51c95d	合入 W2-b 口径账本内核：sql_semantics 的参数绑定与等价证明（绑定只当启发，等价只由 explain_sql_diff 判，执行守门进语料）；探索运行封存后在后台比对口径，结果存 caliber_match 工件并追加封存后事件 ledger.matched，启动补比；逐个数的口径标签与整题判断（GET /api/runs/{id}/ledger、证据片段、报告导出的「口径」一步）；运行与问数据轮次、画布来源的封存链接；报告导出留审计；E1–E4 统计	2026-10-16 15:38:11 +08:00
ThearchyHelios	e7d75be267	check-decode 覆盖查看记录的 added_to_scope：读进来、展开区写「按需加入探查范围」，老服务端没有这一项时不出这一句 ... 为什么：运行面板的查看记录新读了 added_to_scope、prefiltered（next-round 03 A2），要有一项检查守住解码和说法。	2026-10-16 14:49:41 +08:00
ThearchyHelios	f4755056e6	前端跟上后台探查：数据源卡片上的进度、停止、结果，探查范围面板；目录清单的几种「不在」、分批显示、搜索范围外的表并加入范围 ... 为什么：探查改成了后台任务（POST /introspect 回 202 和任务），界面不能再等同步结果；几千张表的库要能设范围、看命中数， 目录清单要说清表为什么不在，范围外的表要找得到、加得进来。这一波直接进 main，不能有半截的功能。 - 数据源卡片：「探查结构」开始后台任务，进行中每秒取一次进度（进度条、正在读哪张、排在谁后面），「停止」停在当前一批之后； 结束时换上任务带回的数据源、说一句结果；最近一次没做完（部分读不到、停止、中断、失败）常驻一行，读不到的表可展开。 规则命中超过上限时照实说命中数并给「调整探查范围」；已有任务时跟上那一个；对象清单拿不到时重取卡片显示原因。 有范围外的表时写「探查范围 400 / 3,000」。换 schema 后的重新探查、按配置重新探查、新建后的探查都走任务。 - 探查范围面板（IntrospectScopeDialog）：全部对象 / 按规则，包含、排除（排除优先）、显式列出、显式移出、包含视图、上限； 边改边数命中（停手 400 毫秒问服务端，不连库），超上限写明会被拒绝、「保存并探查」点不了；一律在范围内的表说明和举例； 按需加入的留痕；没有对象索引时「刷新对象索引」（dry_run）。界面不算命中，规则只在服务端一处。 - 数据目录：表清单一次画 200 行、「显示更多」；表结构里没有的按 absent_reason 分开说（只有真删除说「表已不在」），老服务端 不给原因时照旧；有范围外的表时搜索词同时在对象索引里找，命中列在清单下面、「加入范围」后清单重取；顶部说明按探查范围写 （老缓存照旧说只探查了前 N 张、请重新探查）；表详情按原因说；起草、剖析排在探查后面时写明。 - 运行面板的查看记录读 added_to_scope，展开区写「按需加入探查范围」。 - 类型、接口、文案各写各的块（types.ts / typesApp.ts 末尾、client.ts 的 datasources 和 dataCatalog、terms.ts 的 INTROSPECT_TEXT / INTROSPECT_SCOPE_TEXT / CATALOG_ABSENT_TEXT / CATALOG_SCOPE_TEXT），SCHEMA_PARTIAL_TEXT 改成按探查范围说。 - 检查：check-manage 的假探查改回 202 和任务、加「数据 · 后台探查与探查范围」一节（超上限、刷新对象索引、边改边数、 保存并探查、进度、停止、结果）；check-catalog 的「只探查了一部分表」改成老缓存的说法，加「探查范围：三种不在、分批显示、 加入范围」一节。两项检查 1,135 项全过。 - introspect_jobs 的一句报错不用「连不上」（check-copy）。	2026-10-16 14:46:58 +08:00
ThearchyHelios	7576fa6ce9	前端跟上口径账本内核：时间线认得 ledger.matched；问数据的运行带上属于哪段对话、哪一轮；「在画布里打开」带来源 ... 为什么：这一波合入就进 main，后端新加的封存后事件、来源链要在界面上接得住，不能有订阅了收不到、点了没用的地方 （next-round 02 做法 2、9）。账本的标签、证据面板的「口径」一步、对账在第 4 波接界面，这一波只有接口。 - run/decode.ts：ledger.matched 解读成时间线上一行「比对已发布口径：1 条查询等价已证明，2 条有相关口径」，副标题写明「封存后比对， 不在封存范围内」，事后补比、按需比的另写「按现在的口径回看」；有没比完的标成提醒；不改相位。文案进 lib/terms.ts 的 LEDGER_TEXT （连同 X10 的叫法：来自口径 / 相关口径 / 这次的推理 / 没有比对，等价已证明 / 助手选用，受管 / 已发布）。 - store/chat.ts：发起运行时带 origin_ref {conversation_id, turn_id}（等开轮请求拿到服务端的轮次 id）；服务端核对不过 （origin_ref_invalid：对话刚被删）时不带来源照常发起——来源只是留痕，不挡这一轮的回答。 - pages/ChatPage.tsx：「在画布里打开」带 origin {run_id, conversation_id, turn_id}（这一轮跑过才有）；核对不过时不带来源照常新建。 run/AssistantStream.tsx 的 onOpenGraph 多给一个轮次 id（只加参数，别处不受影响）。 - api/client.ts：runs.start 的 origin_ref、workflows.create 的 origin。 - 检查脚本：check-decode 加「口径账本」一节；check-chat 断言发起时带上 origin_ref、「在画布里打开」带上来源；check-report-export 加「口径一步」：没比对过的运行没有这一步，数据块里放一份编的标签断网打开，面板最上面是「口径」、写明封存后比对、遮罩的参数写 「已遮罩」（只打印这一节，不打印真数据）。 验证：tsc、check-copy；check-all --stacks 1 decode chat report-export 全过（1485 项）。	2026-10-16 14:15:22 +08:00
ThearchyHelios	0b825f40ee	设置里的「访问密钥」与钩子的收件记录（下一轮第 2 波 W2-d 前端，细案 04 A1、A6、A7） ... - 设置 → 访问密钥：管理员看个人访问密钥的开关、服务账号（建、停用前确认）和全部密钥；别人只看自己的个人访问密钥，管理员 打开开关之后才有这一页（认人接口多给一项 personal_keys：关着时建不了、已有的也不生效，给一页空的没有用）。新建时缺省只勾读 的权限，服务账号勾不了回复待办，有效期必填最长 365 天；明文只显示这一次，点「我已保存」就没了；轮换、撤销先确认；关登录时 照实说访问密钥不生效、不给建的入口 - 「最近的请求」做成共用组件（components/RecentRequests.tsx）：每把密钥的请求记录、钩子的收件记录都用它，接口写路由模板， 成功、被拒、处理中分开上色 - 接口说明：照服务端门禁那张表列出方法、路径、权限、说明、错误码，标出要幂等键的 - 应用编辑 → 钩子：生成过密钥的钩子能展开收件记录（状态、原因、发起的实例），写明近 1 小时验签失败几次 - 名录里的服务账号：选人控件缺省不收（岗位绑定、改派不能派给它），应用授权照收；身份页那一行标出服务账号，不给角色和密码的 控件；审计按「访问密钥」筛 - 检查：新建 check-access-keys（不叫 check-tokens，那个名字查的是设计令牌），check-app-editor 的钩子一段加收件记录；登记进 check-all	2026-10-16 14:11:30 +08:00
ThearchyHelios	3f5cf79b26	合入 W1-d 集成底座：安全响应头（frame-ancestors 缺省 self、白名单、script-src 先只上报）；对外访问地址只留一个设置（环境变量优先）；开登录时收起 /docs；集成接口的错误一律带机读码	2026-10-16 12:51:43 +08:00
ThearchyHelios	02abede047	合入 W1-c 目录方言与 Excel 期 5：剖析方言修正（IN 两边类型族、列类型存方言完整写法与 ENUM 码值、Oracle 小写引号名、统计过期复核、无效日期、按存储顺序取前 N 行的说法）、方言金样与 sqlglot 校验、本机容器集成脚本；Excel 列表按期累积、穿插小计、表格对象起草、CSV 走配方	2026-10-16 12:51:43 +08:00
ThearchyHelios	696cd17a4a	合入 W1-b 已知遗留：人工驳回记成已取消 + end_reason=rejected（不重试、不被出错时继续吞掉），各处照实写「被驳回」；个人渠道「我发起的实例完成 / 失败」生效；导入清单如实记「是否认证」；使用者选人按候选池、开登录时服务端核对；自由形蓝图按导入的图列「谁来做」；tick 按 id 断言	2026-10-16 12:51:43 +08:00
ThearchyHelios	e96b0180d9	可验证报告、报告导出写「被驳回」：元信息带 end_reason，核对仍按运行取消 ... 为什么：被驳回的运行导出后，可验证报告的运行结果写「已取消」，报告导出的运行状态也写「已取消」，和系统里「被驳回」两种 说法。封存里被驳回和手动停止是同一种结束事件（运行取消），分开它们的原因在那条事件的内容里，而运行取消的内容不随文件 附带（里面有驳回人和备注）——光看封存分不出来。 做了什么： - 两种导出的元信息都带 end_reason（bundle/build、report_export/build、对应的接口）。 - verifier.js：运行结果按运行记录写「被驳回」，核对的仍是「最后一条结束类事件是运行取消」，旁边写「已核对运行取消，被驳回 取自运行记录」，原因里写明这一半要去系统里对照；手动停止、老运行照旧「已取消」；文件里写被驳回、事件却是运行结束的照旧 不通过。runtime.js 的运行状态照 end_reason 写「被驳回」。 - 样本页加一份 rejected（check-bundle 样本数 17 → 18），断言写被驳回、写明取自运行记录、不提重新封存。 测试：test_bundle_rejected 用 node 载入 verifier.js 核运行信息（被驳回、手动停止、老运行、伪造）；test_bundle_build 核 元信息和样本页；test_bundle_api 核两种导出接口都带 end_reason。把实现退回去回跑，被驳回、伪造两条和元信息、样本页、 接口的断言都失败（手动停止、老运行两条守的是原样，照旧通过）；改完通过。	2026-10-16 12:46:48 +08:00
ThearchyHelios	b6cb5816db	问数据：被驳回的那次尝试不写「已手动停止」，会话列表标「被驳回」 ... 为什么：一轮的运行被审批人驳回之后点「重新运行本轮」，「之前的尝试」那一行写「已手动停止」，用户其实没有停过它。会话 列表的 last_status 把被驳回的一轮归成 cancelled，左栏不标——在等审批的那一问被驳回之后，看起来像是答完了（以前驳回 记成失败，左栏标的是「失败」）。 做了什么： - store/chat 的 attemptOf：被驳回的那次记 outcome=rejected，摘要写「被驳回：张工 驳回了「查数」：…」；老留档里记成 cancelled 的不改写。ChatPage 的尝试徽标认 rejected。 - api/conversations 的 last_status：前端落库时 meta 里记着 rejected 的、页面关掉没落库而运行是 cancelled + end_reason=rejected 的，都记 rejected；手动停止照旧 cancelled。types 的 last_status 加上 rejected。 - 左栏：打开过的看最后一轮（相位 cancelled 且带着驳回），没打开过的看 last_status，都标「被驳回」（不画异常色）。 测试：test_conversation_status 加一条（两种认法的被驳回、两种手动停止），改之前失败；check-chat 加一节被驳回（刷新后 认得出、补救区的话、左栏两种、重新运行之后的尝试记录），把前端改动退回去回跑，那一节 4 项不通过，改完通过。	2026-10-16 12:46:36 +08:00
ThearchyHelios	58c26baa33	记录页、画布上找得到被驳回的运行：分段、计数、搜索词、遥测、缩略条、运行胶囊 ... 为什么：被驳回的显示码 rejected 不在 RUN_STATUS_ORDER 里，也不在计数的 COUNTED 里，搜索词表里没有「驳回」。点「已取消」 分段时服务端交回了它，前端按显示码一筛又筛掉了；以前它算在「失败」里，现在哪个计数里都没有；搜「驳回」不当状态词认； 详情的状态格没有副标题，缩略条没有结束标记。画布的运行胶囊更糟：相位是 cancelled，写「已取消」，一句话写「张工 取消了 本次运行 · 停在「研究协作团队」」——驳回的人并没有停过它。 做了什么： - lib/status：RUN_STATUS_ORDER 在已取消后面加上 rejected（分段、搜索词表都从它生成），查询时照旧换回 cancelled。 - 计数加上被驳回；搜索词另认「驳回」「已驳回」；缩略条和已取消共用一个结束标记（同一个剪影和颜色）。 - 遥测的状态格：副标题写谁在哪一步驳回、备注（REJECTED_TEXT.sub，和时间线那一行同一句）；run.cancelled 还没取到时 按驳回的那一步说。 - 运行胶囊：run.cancelled 带 reason=rejected 或运行记录 end_reason=rejected 时，状态写「被驳回」，一句话写 「张工 驳回了「主管审批」：口径不对」，不再接「停在…」；回放到中途照旧说那一刻的相位。手动停止照旧。 检查：check-runs 加一节（伪造被驳回、手动停止、失败各一条）：分段和计数里有被驳回、已取消和失败的计数都不含它、点被驳回 只留它、点已取消只留手动停止、搜「驳回」「被驳回」都筛得出、失败页签里没有它、详情显示码和状态格。check-canvas-fx 加 一节被驳回的胶囊。把这几处改动退回去回跑，check-runs 4 项、check-canvas-fx 3 项不通过；改完都通过。	2026-10-16 12:46:35 +08:00
ThearchyHelios	70c5a006d2	像小计的行只认夹在明细中间的；可以在配方里声明「没有小计行」，不再每期确认 ... 复核发现（C-subtotal-suspect-false-positive）：没配小计时，_suspect_word 对只有「标签文字列 + 数字列」的列表 不加限制，「其余文字列为空」自然成立，首列以 合计/总计/小计/汇总/累计 开头的普通数据行都被报 subtotal_suspect， 最后一行也报（说明却写「夹在明细中间」）。这是必勾的确认项：存量配方（「累计充值」「累计消费」这类键值清单） 升级后每一期导入都多一项，工作流里「按配方导入一期」直接被 files/imports._needs_people 挡下；确认又记不住， 只能用 declare_subtotals 把真数据改成小计。 改法： - 执行器（recipe_engine._watch_suspect / _settle_suspects）：这一行本身像小计（首列以合计字样开头、其余文字和 日期列空着、有数）之外，还要上一行明细在某个文字或日期列上有值、这一行那一列空着，并且下一行明细在同一列上 也有值（或者下面紧跟着合计行——最后一组的小计也在列表里面）。候选先挂着，等下一行明细再定；列表到头了还挂着的 不报。两列的键值清单因此不会报；上下明细那一列本来就空着的也不报。 - 配方新增 ListRows.no_subtotals（缺省 false，规范化时省略，存量配方的哈希不变）：人确认过这张列表没有小计行， 以合计字样开头的行照常是数据，执行器不再报 subtotal_suspect。它是放宽，出确认项 no_subtotals:<块>，签名只看 这个开关，配上（或改过）的那一次确认一次，之后各期不再出。和 subtotals 二选一，同时配了报 subtotals_conflict。 - 配方面板「小计行」里没勾「有小计行」时多一个勾选框「没有小计行（以合计字样开头的行也是数据，不再提醒）」； 勾上「有小计行」时自动去掉它。subtotal_suspect 的说明改成「上下明细都有值的文字列在这一行空着」，并说明以后 不想再确认去哪里勾。 - check-manage 加一步：勾选「没有小计行」发 PUT，no_subtotals 为 true。 测试：test_recipe_p5 加复核的两列反例（门票收入 / 累计收入 / 汇总调整 / 餐饮收入；最后一行「合计调整项」）、 最后一行和上下明细那一列空着的反例、夹在中间和紧跟合计行的正例、no_subtotals 的导入、确认项、签名和冲突校验； 去掉「要有下文」的条件回跑两条失败。	2026-10-16 12:17:33 +08:00
ThearchyHelios	479cec0af7	通知事件一次登记（总方案 X6、5.1）：六个新事件进 notify/service.EVENTS，推给哪几条路也登记在那一处 ... 复核指出 X6 漏做：第 2、3 波的数据源变化、口径召回、评测、触达四块都要往 EVENTS、EVENT_LABEL 和前端设置页的事件列表里 加东西，正是 X6 要避免的同一处多方冲突；消息里能放什么也没有一处先定好。 做了什么： - EVENTS 改成登记表：每个事件一行，叫法 + 推给哪几条路（scopes：global 全局渠道自己订阅、user 相关的人自己的个人渠道、 app 应用版本 spec.notify 的订阅）。本轮新登记 source.changed、ledger.recall、eval.regressed、eval.failed、task.digest、 key.expiring，scopes 都是空的——登记了、还没有推送。实现推送的那一块只改自己那一行的 scopes（各行之间隔着说明行，几块并行 改也不会挨着冲突），前端叫法表不用再动。EVENT_LABEL 从登记表派生，老的 import 不变。 - 模块说明写清消息结构：标题、状态、条数、链接，加编号和搭建时起的名字；不放报告和答案里的数、表名、列名、取值、SQL、 按运行数据渲染出来的句子。 - _channels 只走事件登记了的路；没登记的事件直接报错（推送之前先登记）。现有五个事件登记的路照现在的做法，行为不变。 - 接口：订阅按登记核对（subscribe_problem）：没推送的「还没有推送，暂时不能订阅」，范围不对的「不推给范围是「应用」的 渠道」。只核对这次新勾的：以前存下的照旧，开关、改名不会因此 422。GET /api/notify/events 多给 scopes（空的照实给）。 - 前端：terms.ts 的 eventLabel 和 EVENTS 一一对应、逐字一致，六个新事件先有叫法；设置页的渠道编辑框、应用的通知改按 GET /api/notify/events 列（这种范围收得到的才列，已经勾着的照样列出来能取消；取不到时照实说）。 顺带修掉的（就在要改的那张列表上）：设置页以前按前端叫法表的键列事件，里面有五个服务端从来不认的（待办升级、待办超时、 待办处理完、动作失败、动作已生效），一勾保存就 422；改派、升级、催办只在投递记录里出现，另起 deliveryEventLabel（加上测试 消息），记录里照实写是哪一种。服务端 EVENT_LABEL 的四句老叫法（有待办派给我、实例完成、实例失败、写入结果未知）改成和界面 同一句，界面上看到的字不变。 验证：新增 test_notify_events（登记表、前后端逐字对照、接口拒收、只走登记了的路），去掉 _channels 的按路过滤或「只核对新勾 的」回跑各有一项失败；check-capabilities 加一段「可订阅的事件照服务端登记列」，把列表改回按叫法表的键列，四项失败。	2026-10-16 12:12:14 +08:00
ThearchyHelios	a137182145	Excel 期 5：列表按期累积、穿插的小计、表格对象起草、CSV 走配方（E） ... 为什么：每月一份的明细导出是最常见的场景，期 4 之前列表只能每期替换；夹在中间的小计会让规则起草失败； 表格对象这个现成的边界信号没用上；CSV 不能走配方。四项都复用现有的执行器、核对、累积、溯源，不另起一套。 - 列表按期累积：ListBlock.period 二选一——{column, check: within_context} 按日期列分期，试运行多一条结构类核对 D（每行的日期都在本期统计期内，空着也不行）；{synthesize: 统计期} 每行加「统计期起」「统计期止」两列，列表在 统计期定下来之前就抽完了，这两格先放占位、写库时换成真值。accumulate_blockers 放行绑定了统计期的列表；合计行、 小计行另存的表各期主键分不开，照旧不能累积；同一订单两期都出现由并集的主键核对拒收。U3 按列表的分期方式核对。 说明里「按哪一列筛选」用分期列，加的两列有列说明；空行之后文字行的说法补了并集版本（列表能累积以后要用到）。 - 穿插的小计：ListRows.subtotals {label_column, pick, scope: since_previous | group_column, group_column, keep_as}。 小计行不进数据，每个数字格一条合计格（分段键是块 id + ·小计），核对模块按它所管那组明细的 rowid 区间用 SQL 求和比对（新 T 编号，标题「小计行按各组明细求和」），整行记进排除的行（reason=subtotal），可以另存成 reported_total 表（小计项、分组取值、各数字列）；数字格全空报 subtotal_blank（结构类）；合计行的公式引用了小计格 时按它管的明细换算。静态校验：标签列、分组列要在列里，按组小计要给分组列，小计和合计的开头词不能互为前缀。 规则起草把第一列同一个合计字样、下面还有明细的行提议成小计（以前记 stray_totals 失败），框选同一条规则。 - 表格对象起草：工作表有表格对象时按它出列表块：表头行、列范围、数据行、汇总行（映射成 total_row，标签取汇总行 第一列的文字）都由表格对象给，锚点仍按表头文字、不记坐标；表名优先用表格对象的名字（含数字的不用）。不调用 AI。 - CSV 走配方：新增 csv_grid，按内容认出 CSV（不是 zip、不是 OLE、开头没有 NUL），编码和分隔符复用 tabular 读 CSV 的那一段，适配成一张名为「CSV」的工作表（SheetScan.path=csv:，WorkbookScan.format=csv）；只有写法毫无歧义的 整数、小数转成数，千分位、前导零、日期写法一律留作文字交给配方的规则。坐标沿用「工作表!A1」（偏离细案的 R{行}C{列}，理由见 csv_grid 的模块说明）。CSV 不做稀疏判定。导入向导和简单上传的结构提示都放行 CSV。 - 每个列表一道题「每期怎么更新」（q_list_period）：每期替换 / 按期累积并按某个日期列核对 / 按期累积并加统计期 起止两列，后两种同时把导入模式改成按期累积、缺统计期的工作表一并配上（问题集合按草稿生成、回答时不变，草稿里 的列表还不符合累积资格，q_mode 不会出现，所以并成一道题）。确认项新增 subtotals:<块>、list_period:<块>。 - 前端配方面板：列表块多「小计行」（标签列、开头词、管哪些明细、分组列、另存）和「按期累积时每一行属于哪一期」； 回执「排除的行」认 subtotal。 验证：新增 tests/test_csv_grid.py、test_recipe_p5.py（执行器、核对、校验、资格、并集物化、起草）、 test_recipe_p5_e2e.py（经接口：三份月度 CSV 累积、部分重叠拒收、同一期替换要确认；带穿插小计的 Excel 起草、 核对、提交）。去掉小计识别、统计期回填、D 核对分别回跑，新测试 10 条失败。旧测试里「夹在中间的小计一律失败」 「列表只能每期替换」的断言按新行为改写。	2026-10-16 11:09:39 +08:00
ThearchyHelios	a56c405c9a	check-ui-kit：存量驳回的另三种原话都归成「人工审批驳回」、不给继续运行 ... 为什么：lib/explain 的正则只留给存量 failed+驳回（新的驳回结束在 cancelled，界面按 end_reason 说），以前只认「人工驳回」一种， 动作确认、工具调用审批、代码执行审批的驳回原话落到兜底、给出注定再失败的「继续运行」（05-已知遗留 (a)）。这三种要有检查守着。 做了什么：失败归类的样本加三对（「「付款」未确认（被驳回），没有发送：…」「工具 x 的调用已被驳回：…」「代码执行已被驳回：…」）， 期望标题「人工审批驳回，运行终止」、continuable=false；「片段还在后端源码里」那一项加上 tools.py 里这三处原话。 验证：check-all --stacks 1 ui-kit 497 项通过。	2026-10-16 11:07:17 +08:00
ThearchyHelios	335dc99c3e	检查脚本跟上：驳回、使用者选人、自由形「谁来做」 ... 为什么：前几个提交改了驳回的终态、选人控件的候选、自由形蓝图的「谁来做」，浏览器检查里的伪造数据和断言要守住新说法 （05-已知遗留 (a)(b)(d)）。check-decode 的一节已在驳回前端那个提交里。 做了什么： - check-apps：伪造接口加 /api/directory/candidates（按段里给的池答）和 /api/directory（使用者 403）；新段「入口：使用者选人」 ——边输入边按入口和字段取候选、列表里是池里的人、不去取整份名录、不在池里当场说清、选中的写显示名悬停给用户名；新段「实例页： 被驳回」——状态照服务端写「「付款」未确认（被驳回）」、不写失败、那一步写未确认（被驳回）。 - check-inbox：新待办「指定复核人」（补充输入里有选人控件）；按 task_id 和字段问候选、不取整份名录；服务端 422 code=principal 挂回选人字段。 - check-personal：提交审核选人按 purpose=review 取候选，不是搭建者的名字当场说清。 - check-blueprint：自由形模板的 cards 加 people；新段「自由形：谁来做」——按 derived_people 摆三行（岗位、核实人、只读的发起人）、 没绑的标缺、问题归在这张卡片上、只读行没有修改、不能加减步骤、选人发 bp_set 到那一行的 path。 验证：check-all --stacks 1 跑 decode、apps、inbox、personal、blueprint（1030 项）和 ui-kit、chat、runs、stream（1982 项），全部通过。	2026-10-16 11:04:28 +08:00
ThearchyHelios	ee6e07959b	问数据一轮的「决定」下沉到后端 chat/turn.py，问数据页照后端给的走（细案 01 做法 1，总方案 2.1）；这一轮的花费 = 助手 + 运行 + 复核 ... - chat/turn.py：next_step（有 error 级问题时自查过就判失败、没自查过的老服务端才重来一次；autorun=false 只建不跑；reply、只有反问直接收尾；其余运行）、fill_input（规则同 chat.ts 的 fillInput）、retry_after_review（retry、broken、这一轮还没试满）、retry_instruction（两种措辞原样搬过来） - answer_ops 的 final（含只问不改那条）带 next（run | ready | fail）；/copilot/review 的结果带 retry_instruction（ReviewIn.attempt 按这一轮试过几次判，要重来是那句话，不重来是 null） - 前端 store/chat.ts：final 照 next 走，复核照 retry_instruction 走（原样交回给助手），launch / watch / settle 把 attempt 带到复核；老后端没有这两个字段时退回原来的规则（常量和措辞留在 retryInstruction 里，和后端逐字对照） - 这一轮的用量：usage 操作累加进 copilot，复核结果的 usage 累加进 review，自动重来和用户点重试换下来的运行并进 earlier，当前运行的抄进 run，一起随 meta.usage 落库；问数据页轮次头部写这一轮的花费（runCostText：估不出的写「≥」或「金额无法估算」），悬停分得清助手建图、运行、复核，文案在 lib/terms.ts 的 TURN_COST_TEXT；ReviewResult 类型补 retry_instruction、usage - 新增 tests/test_chat_turn_policy.py（各条决定的分支；前后端对照 MAX_ATTEMPTS、认问题字段的正则、两种重来措辞——改一个字回跑会失败；复核按 attempt 给不给 retry_instruction）；test_copilot_answer_ops 的基线比对改成「final 只多一个 next」 - check-chat 补一段「新服务端」：照 next=ready 不发起、照 retry_instruction 原样重来、第二次复核带 attempt=1、meta.usage 四份都记下、头部写 $0.067 且悬停分得清三部分	2026-10-16 10:59:15 +08:00
ThearchyHelios	2fa2db3ea0	驳回不再记成失败（前端）：终态按 end_reason 写「被驳回」，副标题写谁、在哪一步、备注 ... 为什么：服务端已把人的驳回收成 cancelled + end_reason=rejected（上一个提交）。前端以前靠正则解析报错原文认驳回，而且只认 「人工驳回」一种，动作确认、工具调用审批、代码执行审批的三种原话都落到兜底、给出注定再失败的「继续运行」（05-已知遗留 (a)）。 做了什么： - types.ts：Run.end_reason（rejected / stopped）。 - lib/status：新增状态 rejected（「被驳回」，同取消的剪影、不画红、终态），resolveStatus 按 endReason 区分；记录页列表、详情、 航迹的终点按它写「被驳回 · 原话」。 - run/decode：run.cancelled 带 reason=rejected 时标题写「被驳回」，副标题「张工 驳回了「付款」：金额不对」（超时驳回写按设置 驳回、不重复备注），指向那一步；手动停止、老事件照旧「已取消」。 - store/chat + ChatPage：终态里被驳回的一轮照 cancelled 收（不给继续运行），徽标写「被驳回」，补救区说明这是审批人的决定、 副标题写谁和备注；刷新之后从 meta.rejected 恢复；核对状态时按运行的 end_reason 认。 - lib/explain：正则只留给存量 failed+驳回，补上「未确认（被驳回）」「的调用已被驳回」「代码执行已被驳回」三种原话，一律不给继续运行。 - 继续运行被拒的说法改成「被驳回的运行不能继续运行：改好内容后重新发起」（check-copy 不收「接着跑」）。 - check-decode 加一节：reason=rejected 的标题、副标题、没署名没备注、超时驳回、相位、手动停止和老事件。 偏离：问数据的「之前的尝试」（retry 留档，W1-a 的地盘）里被驳回的那一次仍写「已手动停止」，没动。	2026-10-16 10:54:02 +08:00
ThearchyHelios	2fb16c2719	设置页加「通用」标签放对外访问地址；环境变量指定时显示「由环境变量指定」不可改，定时任务里的入口跟着认 ... 服务端已经只认一个对外访问地址（core/public_url.py），界面上这一项以前只在定时任务的 Webhook 一节里改得到，叫「服务 访问地址」，和设置接口、通知里的「对外访问地址」两种说法；环境变量设了时那里照样能改，改了也不生效。 - 新增「设置 → 通用」（pages/settings/GeneralTab.tsx）：写明它管哪几件事（通知和 Webhook 的链接、单点登录的回调、来源 核对）；管理员能改，保存前先重读 notify 一组、只换这一项，末尾的 / 去掉，带 ? 或 # 的当场标错；改了没保存离开先问； 环境变量指定了的只显示它、写明「由环境变量 AGENTLAB_PUBLIC_URL 指定」，不给输入框；搭建者只看。使用者看不到这一页 - 定时任务 Webhook 一节的快捷入口改叫「对外访问地址」，按 GET /api/settings 的 public_url 一组认：环境变量指定的只显示、 不给修改按钮，设置里存着的旧值不再冒充生效的那个；地址校验和「通用」同一个（lib/publicUrl.ts） - 文案进 lib/terms.ts（GENERAL_SETTING_TEXT，SCHEDULE_TEXT 的 linkBase 一组改说法） 检查：check-manage 加「设置 · 通用：对外访问地址」一节（标签、说明、校验、离开先问、只写 notify 一组、环境变量只读、 搭建者只读）；check-schedules 加「对外访问地址由环境变量指定」一节。check-manage、check-schedules 在隔离的一套后端 + vite 上全部通过，tsc、check-copy 通过。	2026-10-16 10:31:26 +08:00
ThearchyHelios	ee7b8b2f97	剖析与探查的方言修正（C1）和没有真库时的方言验证（C2） ... 为什么：剖析是全站唯一主动查业务库的地方，以前只在守卫放行和字符串片段两层上测过，从没在真库上跑过。 本机四个容器（PG 16、MySQL 8.4、MariaDB 11、Oracle Free 23）实测，旧的 IN 列表写法在 PostgreSQL 上整数子列 对文字主键直接报 operator does not exist: character varying = integer，关系一条都核对不了。 C1 方言修正： - IN 列表的字面量按被指向列的类型族写（key_literals）：父列文字写 '12'，父列数字只收整数写法的值，父列是时间、 对不上的不拼并在备注里写「两端类型不同」；子表是 CHAR(n) 时去掉补齐的尾随空格。 - 列类型改存按方言编译的完整写法（VARCHAR2(20 CHAR)、NUMBER(10, 0)、ENUM('a','b')、TIMESTAMP WITH TIME ZONE）， 编译不了退回 str()。SQLAlchemy 把 Oracle 的 VARCHAR2 反射成通用 VARCHAR（容器实测），照数据字典写成 VARCHAR2。 ENUM / SET 另记 enum_values；Oracle 小写带引号的表和列记 quote_name；各索引（含主键）的首列记进 index_first_columns（下一波取值观察判断能不能对大表发窗口查询）。新探查的快照哈希会变，旧运行封存的不受影响。 - catalog._type_family 认 ENUM / SET 是文字、INTERVAL 不是数字，去掉引号里的取值再认；新增 column_family （有 enum_values 的是文字，PostgreSQL 枚举编译出来只有类型名）；is_date_column 不再把 ENUM('date') 认成日期列。 - 码值候选：ENUM / SET 不看列名直接算候选，ENUM 列定义里这次没出现的取值也写进码值（含义待填）；VARCHAR2(20 CHAR) 的长度按 20 算；CHAR 码值去尾随空格；MySQL 上写明按排序规则分组、比较（可能不分大小写）。 - 统计信息估出的行数不超过整表统计上限时再跑一次有上限的计数确认，统计过期的大表不再被当成小表做整表统计。 - 日期列的最小值、最大值只看 0001-01-02 到 9999-12-31 之间的值，零日期、占位日期、PG 的 ±infinity 不计入， 照实写「另有 N 个无效日期未计入」，日期范围里带 invalid 个数（界面显示）。 - 新增取值观察用的方言方法 date_literal / day_trunc / sample_from，以及按日行数、时间窗口里的取值分布、块采样三类 查询的拼法（窗口上端截在 9999-12-31 之前，不让 infinity 多出一天）。 - 说明文字不再说「抽样」：大表看的是「按存储顺序取前 N 行」；设置项「抽样键值数」改叫「核对键值数」。 C2 验证： - tests/test_profile_dialect_golden.py：五种方言 × 全部剖析和观察查询的完整 SQL 钉在 tests/fixtures/dialect/， sqlglot 逐条解析、过只读守卫，再用 qualify + annotate_types 核对 IN 两边类型族一致（附旧写法的对照）。 - scripts/dialect-it.sh（不进 CI）：本机起四个容器，建虚构夹具（保留字列、Oracle 小写带引号的表、CHAR 码值、 MySQL ENUM、零日期 / infinity / 占位日期、做旧的统计信息、超上限的大表、带索引的日期列），用 AgentLab 自己的 探查和剖析代码跑全部查询，断言零报错、结论和手算一致。四种库都通过；MariaDB 插入时自己更新行数估算，统计信息 做不旧，照实打印。把 IN 列表改回旧写法回跑，PG 上照样报出上面那条错误。跑完删容器、留镜像。	2026-10-16 10:25:28 +08:00
ThearchyHelios	dd00234622	系统派生的运行不进使用统计（总方案 X1、X2，细案 01 做法 4）：评测一跑，聚类、白名单、目录使用热度都会被刷高 ... - engine/origin.py：SYSTEM_ORIGINS = (eval, reconcile, recall) 和 counted_runs()（写法同 hidden_runs，coalesce 防 NULL：来源为空的老运行、外连接没对上运行的行照常计入）；ledger_issue 是替用户正式出具，照常计入 - 取问题、聚类全站只留一份：新增 app/chat/questions.py（recent_questions / cluster_questions）。只取问题原文、不取整份输入（以前把含 history 的 input JSON 拿去聚，同一段对话里的不同问题会聚成一类）；问数据按轮次一轮一条（conversation_turns.question），同一轮里的自动重来只是换了挂着的运行，不多算；别的探索运行取 input.question；排除系统运行和别人的私有运行。/governance/exploratory-clusters 改用它，多给 turn_ids 和 embedder（本地哈希向量的结果只是下限） - 工具白名单衰减、目录的使用次数和「被哪些运行用过」、审阅队列的使用权重（都走 catalog.query_snapshot_tables）只算 counted_runs 圈进来的运行 - 记录页：没按来源筛时默认不列这三类，按来源点名就列；新增 GET /api/runs/unlisted（同一份筛选，_filtered 和列表共用）照实给出没列出几次、各是哪种来源。界面在列表底下（空列表时也写）写「另有 N 次系统运行未列出（评测 2 次、口径对账 1 次）」，来源下拉的「全部」改说「全部来源（不含系统运行）」；文案进 lib/terms.ts 的 SYSTEM_RUNS_TEXT；check-runs 补一段 - test_personal_apps 里代表「别的探索运行」的两条运行改成画布试跑：问数据的问题按轮次取，没挂在任何一轮上的问数据运行不单独算 - 新增 tests/test_eval_origin.py（去掉 counted_runs 的过滤回跑，5 项都会失败）	2026-10-16 10:18:12 +08:00
ThearchyHelios	ff278afd7e	剖析的范围在开始时定：排在起草后面的剖析任务，开始时按起草后的目录重挑要剖析的表 ... 真实后端验收里「起草完接着剖析」这条主路走不通：剖析任务建的那一刻就按当时的目录定了表单，可它排在起草后面，起草还没提出 关系，只靠关系才有检查项的表（链接表、明细表）一张都挑不进来，起草写完关系后剖析照旧跳过它们。 - 开始剖析时（_ProfileRun._rescope）按那一刻的目录重定：需要剖析的表、全部表整份重挑（这个任务的表都还没开始）；指定的表里 建任务时判为「没有可剖析的项」的再看一次，现在有了就排上。 - 排在起草后面时挑不出表也照建，不再 409（起草多半会提出关系）；开始时还挑不出来，任务以 0 张表结束，提醒里写明为什么。 - 界面：排队时写明要剖析哪些表开始时按起草后的目录再定，开始前的张数是按现在的目录算的。 - 新测试在去掉重挑的代码上两条都失败。	2026-10-15 19:43:29 +08:00
ThearchyHelios	90fa83d807	check-catalog-profile 跟上「需要剖析」的新说法（多出码值、日期列的也算，上次是空表的不算）	2026-10-15 19:35:01 +08:00
ThearchyHelios	4c4fa8e4e9	「需要剖析」多认一种：上次剖析之后多出了码值、日期检查（new_checks）；停止排队任务时不再读过期的 job（起草、剖析两处） ... - 以前只认从没剖析过、上次没做完、又冒出了待核实关系三种：上次剖析时没有可剖析的项（指定了表、记为跳过），后来有人把一列 记成状态类，或者日期列变了，「需要剖析的表」永远漏掉它。现在按当前要做的检查对上次剖析的检查项（kind、target），多出了 码值、日期检查就要剖析，原因 new_checks；上次是空表而跳过的仍不算（不发查询不知道有没有数据），界面和 409 的说法写明。 due_reason 改收 plan_checks 列出的检查，没人用的 profile_checks 去掉。 - 停止一个排队中的任务时，排队那一步没停成（刚被后台认领）要回滚，回滚让读到的 job 属性全部过期，再读 job.id 就在异步会话里 同步加载（MissingGreenlet），接口 500。起草的 cancel 在 main 上就是这样写的，剖析照抄了；两处都先把 id、状态取出来。 新测试在旧代码上复现了这个 500。	2026-10-15 19:28:17 +08:00
ThearchyHelios	6c728aaacd	数据剖析按复核意见修三处：没来得及收尾的表照实说、停止中的说法、展开的进行中一行不跟着查询数重取 ... - 服务重启的说明不再一律说「做完的项已写进数据目录」（R1 前端这一侧）。目录只在一张表结束时和它的结果一起写：停止、关停 服务时正在剖析的那张来得及收尾，做完的项照常写进去（服务端记部分完成，原因写「已做完的 N 项照常写进了数据目录」）；进程 被杀、下次启动时才标中断的那张没来得及收尾，这次的结论一项都没写进去，服务端把它记成已停止、查完的项改记跳过。界面按逐表 的状态认出这样的表（已停止却有开始时刻：正常收尾的表不会是已停止，没开始的表没有开始时刻），服务重启、停止的说明里点名它 「剖析到一半服务就停了，没来得及收尾，这次的结论没有写进目录，保留原来的结论」，有别的表收了尾才说「其余做完的项已写进数据 目录」；逐表一行用服务端给这张表的原话（查完的几项没写进目录），一项都还没查完、原因就是任务那一句时写「没来得及收尾」。 不说「做完的项没写进去」：被杀时它可能一项都还没查完。 - 「正在停止」不再说等正在执行的那条查询结束（R4）。停止时服务端不等这条查询（它在发过的查询里记失败），库那边按单条时限截止 它，收尾写完停止就答；单条时限设得长时，旧说法会让人以为要等满时限。改成「正在执行的那条查询不再等待，由数据库按单条时限 截止；已做完的项照常写进目录…」，和服务端的说法一致；接口、停止逻辑的注释同步改。 - 展开进行中的那一行，只在一项检查开始、结束时重取这张表的完整结果（R5）。服务端只在这两个时刻写检查清单、正在做哪一项和发过 的查询，其间每发一条查询只加查询数和用时；以前重取的依据带着查询数，进行中几乎每次轮询（1.5 秒）都多取一份没变的结果， 一张 40 条查询的表约多 40 次。依据改成状态、结束的项数和正在做哪一项。 检查脚本 check-catalog-profile：伪造的停止照服务端分「来得及收尾」（正在剖析的那张记部分完成、原因写做完的已写进目录）和 「没来得及收尾」（记已停止、查完的项改记跳过、说法照服务端）两种；停止那一节跟着改（正在剖析的那张是部分完成，汇总 「完成 1，部分完成 1，已停止 3」），「正在停止」的说法改查新句子；服务重启一节加关停时收了尾、进程被杀（查完一项、一项都 没查完）三种；表详情一节加剖析到一半进程被杀；进行中一节加一条：展开进行中的一行后只多发查询时不再请求 tasks/{seq}，一项 结束、换下一项时重取一次。先在改动前的代码上跑过，这几条照复核说的那样不通过（展开后多取了 2～3 次、停止中还是旧说法、 服务重启一律说已写进），改完通过。	2026-10-15 19:18:17 +08:00
ThearchyHelios	e7ab6a14c5	数据剖析的浏览器检查：新建 check-catalog-profile，check-catalog 里同步接口那套剖析检查删掉 ... check-catalog-profile 照 check-catalog 的写法：数据源、目录、剖析任务、起草任务都用 page.route 伪造（虚构的网店业务库， 表名 orders、customers、visits 这类），任务怎么往前走由检查自己推，没配的写请求一律 503，最后核对真库没变。查的是： 范围与个数（按清单行上的 profile_due、profile_checks、视图算）、按表写的预算和这次最多约几条查询、只读一条一条发可随时 停止的说明、进行中逐表行和各类检查进度、页头进度入口和提醒、停止、展开逐表的检查清单和发过的查询、结束后的汇总筛选和 重试、止损和服务重启、409 六种情况加老服务端没带机读码、和起草互相排队的说法、表清单的「剖析」一列和「需要剖析」筛选、 表详情的一节和「剖析这张表」（含正忙时说清这张表在不在那个任务里）、设置两项新字段和被拒时报错落到那一项、窄屏。 同步接口那一节里顺带查的码值弹窗（光标落在空着的码值上、回车保存只换那一列、填完回到结果接着下一列）一并搬过来。 check-catalog 删掉旧的剖析设置、剖析、剖析 409 三节，假服务端的同步剖析接口换成剖析任务（取进行中、最近一次答空， 建任务一律 503）；其余各节不动。check-all 的 ORDER、ESTIMATE 登记 catalog-profile。 界面顺带改三处（截图里看出来的）：结束后的进度写做完了几张（同起草，停止、失败、跳过的不算）；没开始就停下的表不写 各类检查的 0/N；表详情一节里码值候选不在目录里时不给「填写含义」（码值弹窗改的是目录里那一项）。	2026-10-15 18:33:46 +08:00