284 Commits

Author	SHA1	Message	Date
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	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
ThearchyHelios	d2b398563b	写回卡片加「结果不明时谁去核实」：写回的目标能力没登记查询时，结果不明（请求发出去了、没拿到答复）平台查不了、也不自动重发，要有人去目标系统里核实；以前发布单报「写入结果不明时没人核实」「有一步还没指定谁来做」却在卡片上找不到地方改。 ... - 蓝图格式：写回卡片多一项 reconciler（一组人或组），旧蓝图没有这一项照旧可读；只收用户的操作（同「谁能看」），助手整张换写回卡片时留着用户选好的人 - 是否需要（templates/_common.needs_reconciler，和应用骨架加核实岗位同一个判断）：模板用到写回卡片、选了目标能力、能力没登记查询；交给前端的蓝图带 reconciler_needed，界面不自己判 - 蓝图检查 bp.reconciler_unbound：试运行只提醒（待办派给试运行的人自己），发布挡住；发布单上应用检查说同一件事的 app.reconciler_unbound 和核实岗位的 app.slot_unbound 不再重复列 - 岗位绑定：选了的人绑到应用的核实岗位；能力补登了查询就不再要、也不再绑，卡片上留着的人照样摆出来、写明用不上 - 卡片：需要时摆这一项，标「缺」、写明为什么要人核实，选人控件只能选人或组；「缺」只挡发布；蓝图助手的提示词写明这一项由用户定 - 示例蓝图（核对写回）补上核实人，审批、核对写回的卡片说明写上这一项；测试和检查脚本跟上	2026-10-15 17:31:20 +08:00
ThearchyHelios	1e707c43c5	蓝图卡片加「确认全部」：一张卡片上待确认、有值的项不止一项时，卡头摆「确认全部（N）」，一次修改带上这几项的状态（只改状态、来源不变，服务端整批落或整批不落），不用再一项一项点；只有一项的用它自己的「确认」。按钮「改」改成「修改」，页面编辑的「改文字」改成「修改文字」；检查脚本跟上	2026-10-15 15:03:43 +08:00
ThearchyHelios	f0b66c2551	发布单的问题照实分清挡不挡发布：平台能力的治理默认在没人治理过时一直生效（在默认写好之前登记的 records_append 会停在「不许无人值守、没有查询能力」，填报登记出发布单时报写入不经确认、结果不明没人核实、要找管理员登记查询能力；管理员改过的同步不动）；发布摘要的三栏只列挡发布的问题，只是提醒的（视图要等第一次正式运行才有数之类）另列「提醒（不挡发布）」；确认按钮「每周一 09:00 自动出数」补上空格；检查脚本和测试跟上	2026-10-15 14:44:26 +08:00
ThearchyHelios	7739340607	普通用户建应用集成收尾： ... - 问数据和个人应用的图放行绑定只读查询等合规工具的调用工具节点，只读和遮罩在这条路径上生效；被治理成写入的工具在只读运行里直接拒；知识库范围在工具层固定（图级默认值、参数名纠错、Agent 都改不了） - 个人应用的刷新和个人蓝图的试运行只有拥有者能读：运行、事件、证据、工件、文件、运行与审批列表、对比、可验证报告、质询、假设分析、提取工作流一并收紧；个人蓝图的试运行不论谁发起都按个人应用约束 - 共享蓝图只给拥有者、对应应用的管理者、管理员，看不到的一律 404；审核副本归审核人；管理员看别人的个人应用只有元数据、可以归档 - 记录表跨版本汇总（只读挂载旧版本、按当前列 UNION ALL、各版本各自固定高水位，缺的版本照实写进印章）；停用前发起的运行可以继续写旧版本；更正沿用原提交人、更正人记审计 - 约定收口：待办种类 review、事件 file.extracted、表单错误 file、模板定义带示例与预置；前端类型一次补齐、去掉临时的局部类型；审核待办卡不再给打不开的链接；读附件事件有中文说法；检查脚本补断言	2026-10-15 13:55:19 +08:00
ThearchyHelios	a702a5c14b	普通用户建应用（前端）：新建应用的三个起点（说需求、场景模板、从已有的开始）；蓝图页（对话加卡片、反问选项、关节逐组进度、试运行、发布摘要按你来定 / 助手可以修 / 要找管理员分栏、逐步打勾、接着做）；问数据「做成应用」改走蓝图；问数据和画布的反问收尾；页面上直接改（选中、改字、隐藏、挪动、删除、加数据卡片、自动存草稿）；文件控件；我的记录列表；个人应用的界面（我的应用、刷新与剩余次数、提交审核、审核待办卡）；设置页的个人应用开关；四个新检查脚本并加进完整关口	2026-10-15 12:09:29 +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	5d42ffb62b	check-auth：会话过期时认人接口也回 401（同服务端，不然登录页认得出人又送回原处、来回跳）；过期后点页签只为触发取数，外壳心跳先收到 401 已经跳走时点不到不算错，核对的是跳到了登录页并带上原处	2026-10-15 00:07:51 +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	acdc9677a8	应用平台 BE-2 流程：待办服务（派给谁、any/all/quorum 汇总、条件 UPDATE 抢恢复、提醒升级超时驳回、审批接口改为垫片、存量补建），人工节点新配置与校验，写外部系统的动作流程（生效记录先写后发、确认卡哈希、结果未知挂起与核实、永不自动重发），重放豁免与升级安全测试，正式运行不许带图接着跑、接着跑不覆盖发起人（F2），运行来源，通知发送核心与渠道，入站签名钩子，process.* 检查，报销审批模板，假外部系统（含统一复核后的修复）	2026-10-14 20:05:23 +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	5880af465e	check-catalog、check-catalog-loop：关页面之前先撤掉拦截、忽略还在路上的那几条，取真实设置的拦截在页面关掉之后才回来时不再把检查进程带崩（满负荷并行时偶发「Request context disposed」）	2026-10-14 10:37:26 +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	cab1a10bdc	check-catalog-loop：表助手的输入框过输入法护栏——组字时的回车（isComposing、Safari 式 keyCode=229）不发送，组字时的 Esc 不关面板，草稿还在	2026-10-14 08:55:40 +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	ead8ea216b	数据目录起草（前端）：表结构里已经没有的表（只剩目录）不再给「重新起草这张表」「补充起草要求」——服务端只会把它记成已跳过。表详情顶部照写上次起草的结果（没写全的原因、留空了几列），不再建议补充起草要求后重新起草，写明「表结构中已没有这张表，不能重新起草」；清单上留空列的轻提示照旧，悬停里不再建议重新起草。起草设置收到的预先选好的范围（表详情的「补充起草要求」、结果里的「重新起草这几张表」）里的表已经不在表结构里时不再退回别的范围：那一项照旧选着，写明「表结构中已没有这张表，不能起草」（只少了几张时写其中几张不会起草），不能开始，也不默认勾用模型、不把焦点放进起草要求——以前退到「使用次数最多的 20 张表」还勾着用模型，以为只起草这一张，实际按别的范围起草了；选的那一项不在了时，单选框照实际起草的那一项勾。check-catalog 新加一节：只剩目录的表的清单提示与详情；打开详情以后表才没了（清单重取了、详情没重新载入）时「补充起草要求」打开的设置；重新打开后不再给两个按钮。check-all 里数据目录的耗时按实测改成 140 秒	2026-10-13 21:13:15 +08:00