126 Commits

Author	SHA1	Message	Date
ThearchyHelios	41f64172c3	types.ts：RunComparison 的注释挪回它正上方。分析卡那一节插进来的时候把「GET /runs/{id}/compare?base=…」的说明顶到了 RunCompareAnalysisSide 头上，读的人以为那是另一边的说明	2026-10-21 15:53:41 +00:00
ThearchyHelios	c54196326f	证据面板的分析结论：结果表的格写列名，总数那一格的值按服务端的写法显示。①「这一处引用的是 结果表第 1 行『share』」原来写的是列 id，现在服务端在 cited 上另给 column_label（结果表记的 labels，如「占变化的比重」），目录条目也带上 labels，证据面板、读屏的出处、导出页、可验证报告都照列名写；② 输入里「总数那一格 … = 159175.18」和同一节的闭合核对「159,175.18」两个写法并排，现在服务端另给 value_rendered（render_cell，千分位、NULL 写「—」，和闭合核对同一个写法），三处界面照原样显示。结果表数的换算（比率、空格）不在这次改动里	2026-10-21 15:53:27 +00:00
ThearchyHelios	9461c03a63	分析结论的「在验证什么」照实说谁写的：分析卡上那一条是模板作者写的，标「分析卡上写的『在验证什么』」；Agent 现场做的照旧「Agent 写的假设」（台账条目带 item 的是分析卡、带 call_id 的是 Agent）。服务端按 origin 给 hypothesis_label、hypothesis_note 两句，证据面板、导出页、可验证报告都照原样显示，不自己拼。测试：证据接口两种都测，分析卡的链、导出页、核对页各加一条断言	2026-10-21 15:52:19 +00:00
ThearchyHelios	29874166df	证据面板与报告正文接上分析结论（分析能力一轮）。点判定语、具名的数、结果表的格：出处链照服务端的分析几步（判定 → 方法 → 计算 → 输入 → 复算 → 封存）——判定写编号和方法的叫法（method_label）、判定语照原样、判定标准、点名的段、方向、谁做的（Agent 现场 / 分析卡 / 口径卡执行时的可比性检查）、附带说明、Agent 写的假设（另说它不是结论）；方法写版本、实际用的阈值（契约的叫法）、规范化后的参数；计算写代入式、具名的数、结果表（被引用的数描出来、那一格高亮）；输入每份一节，总数和各段之和的闭合核对照服务端算好的数，输入快照的查询步骤接在后面、点 Q 跳过去；复算一致与否、封存范围内台账记没记过、算不了的写原因；分析结论的数不走口径账本。口径卡指标上多一行「两期可比性」（判定、判定语，展开看那份可比性结论的整条链，随卡封存）。说法违规（判断词未挂分析结论、判断与分析结论不符、因果说法没有依据，按 unit / segment / span）标在正文上：只在判断词下面画提醒色波浪线，那段文字是一个可点的片段，句末挂「说法待核」，n / N 跳得到；点开写种类的叫法（同审计）、服务端的原话、所挂的结论（点一下落到它的判定语）。正文后面是系统写的「分析范围」（现象、拆过、排除、算不了、没拆的候选维度、做过几次差异检验），编号点得开——正文没引用的取新接口 …/evidence/analyses/{alias} 的出处链，关掉焦点回到那个编号。整句面板挂的依据是分析结论时写「派生自 Q1、Q2」（证据图的 derived_from 边，按这份报告认）。记录页：审计表的说法违规行写种类的叫法、点得开；工件页签认得分析结论（哪一种分析，算不了的写没有做成）。夹具 evidence-analysis.json 是真运行组装的（后端测试库里的虚构零售库 shop，模型换成脚本）。check-evidence 加三节（分析结论的出处链、说法违规与分析范围、指标上的两期可比性），check-runs 加一节（审计行、工件页签）	2026-10-21 18:57:22 +08:00
ThearchyHelios	78800511e0	前端：分析卡节点（分析能力一轮）。节点库「把关」一类加「分析卡」（类型色 --nt-analysis，亮暗两套），卡片摘要写做哪几种分析（「波动基线、变化拆解（可加）」，叫法照契约）；检查器的分析项编辑器：每项标识、分析方法（五个算子）、模式（有模式的才给）、输入只列上游的查询节点（调用数据库查询工具的「调用工具」节点、合并查询，删掉或挪到下游的照实列出），按方法摆参数格（analysisItems.paramSpecs：维度列、期次、基期、本期、度量列或分子分母、乘积和因子、比较方式、粒度、对照组、几对……，期次可以写 {{ }}），可加、比率的变化拆解另有总数核对两格和下钻（上一层只列排在前面的变化拆解），变化拆解、可比性检查可以写成基期、本期两份查询，换方法、模式时只留新方法用得到的参数；在验证什么一句话；阈值覆盖只列写了的几项、从没写的里选，范围当场按契约说（两两之间的大小交给服务端），全删掉不留空对象。服务端按 items[i].<键> 报的问题落在那一格下面，定位退不到的子键（params.parent.key）逐段往上退；查询节点连到分析卡时还没选输入的第一项选上它（同合并查询，和连线同一步撤销）。报告节点加「分析说法核对」（缺省重写一次后标出）、「分析范围」（高级，缺省有分析结论时附上），选项以 engine/labels.py 的短说法开头。叫法、范围只照契约一份（lib/termsAnalysis：OP_LABELS / MODE_LABELS / LABELS / RANGES，check-studio 读后端源码逐项比对）。check-studio 加两节：叫法与契约一致、分析卡的画布编辑与校验定位	2026-10-21 18:17:56 +08:00
ThearchyHelios	f774e42463	数据剖析可以同时剖析几张表：剖析设置加「同时剖析的表数」（table_concurrency，1–3，缺省 1，即以前的一张做完再做下一张；上限 3 是给这个源上的分析留出连接池的临时连接），每张表的查询仍一条一条发，所以同一时刻对业务库最多这么多条查询。剖析任务的执行改成按设置开几个执行者，按任务里的顺序一张结束就开始下一张；进度、发过的查询各落在自己那张表上（不再记「正在做的那一张」）。每张表开始前照旧重读数据源：停用、关掉剖析或止损后不再开始新的表，正在做的几张照常做完（止损时剩下的项记止损的原因），都结束后再把没开始的记停下；止损的连续失败、超时比例按几张表的查询合起来算。停止、关停时正在做的几张各自收尾，做完的项照常写进目录，都收完才往上交（等的时候又被停止也等完）；一张表让任务整体出错（快照被改动、数据源没了、记结果写库出错）时，另几张按停止收尾、原因写这一句，本进程续不上租约的不写。同时要估同一张表的行数时只估一次（按表加锁，先来的没估成后来的自己估）。同源已有剖析时的 409 说法从「第 x / y 张表」改成「已完成 x / y 张表」。界面：设置表单多一格（单位「张」，提示写明业务库同时要应付几条查询、和分析共用连接），风险说明、卡片悬停、开始前的醒目一句在大于 1 时写明「同时剖析 N 张表、每张表的查询一条一条地发」，预算多一行，这次最多用时按几轮算。测试：同一时刻在途查询不超过设置、每张表仍一条一条发（1/2/3 三种）、几张一起显示进行中并按顺序开始、同时停止各自写进目录、止损后不再开始新表、停用时正在做的做完、一张出错另几张按停止收尾、共享行数只估一次；check-catalog-profile 加一节（预算、估算、说法、两行进行中、表清单）。验收：后端全量 14979 通过；止损那条并发测试单独跑 30 遍、整个剖析任务测试文件并行跑 15 遍都没有偶发；tsc；check-catalog-profile 217 项、check-copy 28 项全过	2026-10-21 09:08:10 +08:00
ThearchyHelios	9e1ff11278	交叉表支持按文字导入的指标（如「高峰时段」一行写着「18-19」），堵上占位符陷阱：配方的 measures 分段加 text_measures（标签 → text / hour_range），落成文字列（时段存规范写法），空格、公式、占位符照块的取值规则，数字、日期、解析不了的时段报 value_not_text / value_not_hour_range；规则起草遇到无标题指标块里整行是文字的行（标签不带词表单位）按文字指标起草，并出卡片和问题要人确认（「不是」就去掉，回到按数字导入、试运行拒收），确认清单加 text_measure 项，前后对照报类型和存法变化；数值区不合格的格一行合成一条起草失败（不再一行 30 条）。陷阱：以前照「请添加占位符」把「18-19」加成占位符，整格静默存成空值、干跑照样通过——静态校验拒收含数字的占位符（placeholder_digits，重放和沿用现行配方的放行），value_not_number 的下一步按格子情况写：整行文字的提示改「指标类型」并给修复按钮 declare_text_measure，含数字的不再提示加占位符；标签带单位的拒按文字导入（text_measure_unit），文字列不能写单位（unit_on_text）。配方面板每个指标多一个「指标类型」下拉（数字 / 时段 / 文字）。默认值不进规范形式，已存配方的哈希不变。测试 tests/test_recipe_text_measures.py（合成夹具，假名）；check-manage 加指标类型三项	2026-10-20 11:41:28 +08:00
ThearchyHelios	6fa2e297db	口径卡、报告、出具、复核认「查询区间里这张表没有数据」：口径卡按输入的快照 id + 列认（cell()、按位置取的格、Agent 经 cite_fields 交来的字段，按列，同一条查询里有数的列不受影响；转抄的指标照抄），给指标标 no_data 并写明原因，清单注明「这段时间表里没有数据：不要当成 0 解读」，发一条 metric_no_data；有出具契约的成果按缺口降档（契约收来的指标，和报告直接引用的这样的格）。写作目录里这样的指标、查询格子里这样的列都写清，写作规则加一句（目录里有这样的项才加）。证据面板的指标标「区间内无数据」并写明原因，查询步骤列出这几列。复核把 query_no_data、metric_no_data 记成缺口（DEGRADED），归进新的 REBUILD：是缺口、却值得换一张有这段数据的表重建一次，should_retry 和 chat/turn.retry_after_review 都认，问数据据此给出「按复核重来」的指示	2026-10-20 10:29:01 +08:00
ThearchyHelios	301bbd55f3	口径卡分母为 0 时算不出来就是空值，和「缺少输入」分开说；指标清单按格式渲染。助手节点手册讲口径卡的那段写明分母可能为 0 时写「… if 分母 else None」、不要写 else 0，附示例；画布校验加一条提醒 metrics.zero_for_undefined（按语法树认：条件表达式一边有除法、另一边是常量 0，两边对调、套在 round 里、嵌套的都认）。输入都齐、计算式自己交回空值的指标多记 undefined: true（状态仍是 missing_input，按状态认的地方和老运行不受影响），清单、写作目录、引用解析不了的原因、运行对比、证据面板都说「算不出来（这组输入下计算式没有值，比如分母为 0）」；推演把它当不带值的字段。指标清单（{{ nodes.卡.text }}）改用卡上渲染好的 rendered：比率 0.0007 显示成 0.07%、金额带千分位，和报告里 [[m:]] 一致；有值却显示不出来的照实说，不拼原值	2026-10-20 10:04:53 +08:00
ThearchyHelios	358206312e	事件触发的规模：定时任务列表里每个事件触发任务「有几条在等」一次查齐（outbox.pending_for_many：待派发数一条 SQL 按任务分组算，窗口要看的事件一次读出），不再每行查一次；每一拍派发只读触发条件的事件种类、对象对得上的任务（SQLAlchemy 的通用 JSON 访问），保存时查环一层查一次、只顺着「上游工作流运行成功结束」的边找；选对象（trigger-options）按事件、关键字查、一页最多 100 个、more 说还有没有，当前选中的总在里面，编辑页一页没列完时多一个按名称查找。顺带修：等着的时候任务改了条件、最早那条不再合条件时，「什么时候合成触发」按剩下的最早一条算（列表上的时刻和真发起的一致）；一个窗口的结束时刻和这个任务已有的另一次触发撞在同一刻（别的期次早一拍发了）时往后挪，那几条事件照常发起，不再被记到已有的触发上	2026-10-19 09:46:47 +08:00
ThearchyHelios	c0739dfd5d	合入 W1-c 数据事件触发：定时任务加「事件触发」（上传表格出新一期、上游工作流正式运行成功结束、数据源有要处理的变化），事件在发生处写进待派发事件、调度循环去抖派发；保存时与运行时防环；{{ event.* }} 模板变量；途经驳回、应用补算的缺省不认（可勾选）；积压一拍处理完、过期的合成一条跳过；按期次分窗口；定时页可选「定时 / 事件触发」	2026-10-18 18:23:33 +08:00
ThearchyHelios	3d5fb19fbd	合入 W1-b 子工作流证据交回父图 + 驳回出口：子图每一步进同一个运行的事件流；子图出口字段带出处，父图口径卡、报告跨子图追到原始数据（运行时、证据面板、静态检查同一套，最多 3 层）；报告目录收进子图里的查询和口径卡；审批、动作确认、代码和工具审批、双盲裁决可接「驳回」出口，驳回后沿出口往下走（不接时行为不变），动作确认走出口不发送；发布检查拦下走不到结束的驳回路径；实例页、通知写「被驳回，转到 X」；子图里的报告按全局 id 记、父图只认自己的报告	2026-10-18 18:23:15 +08:00
ThearchyHelios	656a550408	数据事件触发按复核意见修正：途经驳回、去抖积压、source.changed 补写、按期次分窗口、补算缺省不认、示例出口字段同一套过滤 ... M1 途经驳回（编排者已定）：outbox.stage_run_finished 收可选的 rejected_via（缺省 None 即没途经驳回），事件内容带 rejected 和 rejected_via，说法接「（途经驳回）」，模板有 {{ event.rejected }}（true / false）。触发条件缺省只认没途经驳回的，trigger 加 include_rejected（界面「也认途经驳回的」勾选，说明照实写）。runner._finalize 把 _rejected_via(state) 传进来那一下留给编排者 在合并时接（runner 的 _rejected_via 在 W1-b 的分支上）；测试直接调 stage_run_finished 传参覆盖。 C1 去抖积压：以前一拍只走一个窗口，积压时后面的越等越久、全过了宽限，而且每个窗口各记一条跳过，原因还说调度没在跑。 现在 _drain 按发生时刻把等着的事件切成窗口，一拍里把到点的处理完（最多 100 个窗口、5000 条）；排在前面已过补发宽限的合成 一条 skipped_misfire（合并了几次事件、几个窗口、时间跨度，上传表格另写合掉的期次），派给任务时已经晚于宽限才说「调度未运行」， 否则照实说积压；宽限内的照常发起（照重叠规则跳过的照实记）。 C3 source.changed：这一处确实没法和变化记录同一个事务（一次探查、剖析的变化分好几批落库，一批只触发一次要等任务结束才知道）， 改成说实话：models_triggers 的说明写清哪两种同事务、哪一种不是。trigger_events 加 dedupe_key（source.changed:<任务号>，唯一）， emit_source_changed 按它去重；调度的一拍（刚起的服务第一拍就补，之后每 10 分钟）由 backfill_source_changes 按任务号补写：2 天内 测到、还开着的要处理级变化，任务已结束却没有事件的补一条。分组在 Python 里做，不用各库写法不同的 JSON 取值。 C4 按期次分窗口：triggers.window_key 让上传表格按期次各自成窗口，9 月、10 月连着启用各有各的触发；同一期的重传照旧合并。 两个窗口结束在同一刻时后一个挪 1 微秒，fire_at 不撞唯一约束。 C5 应用补算：workflow.finished 缺省不认 app_backfill 发起的（升版补算连发好几条、各是某一期的历史输入），trigger 加 include_backfill（界面「也认应用补算的」），选了「只认应用补算」时本来就认；说法写「途经驳回、应用补算的不算」。 C6 示例出口字段：triggers.outputs_of 一处过滤「_」开头的键，真派发、预览、立即运行共用；示例事件也按 matches 跳过缺省不认的 途经驳回、应用补算，取合条件的最近一次。 测试：新加 test_schedule_events_review.py（11 项，先写、先看着失败；去掉 matches 的驳回判断、把每拍窗口数改回 1 回跑，对应用例 各自失败），test_schedule_events_api.py 加一项「也认」两项经接口存取和说法；check-schedules 加「上游工作流的请求体」一段、纯函数 几条、触发历史里合并跳过那一行的夹具。 验证：后端全量 14479 通过；tsc、check-copy；check-schedules 447 项、check-runs 327 项通过（拿锁、--stacks 1）。	2026-10-18 18:09:20 +08:00
ThearchyHelios	5ff3e1136d	问数据整轮放到服务端跑（前端）：store/chat.ts 改成「发起 + 播放」，断线按 seq 重连补齐，刷新、关掉再打开接着看 ... 为什么：一轮问数据搬到服务端之后（上一个提交），页面不该再推这一轮：建图那条流、发起运行、复核、按复核重来、落库都和页面 绑在一起，页面一断这一轮就停。现在页面只发起、只看，要不要运行、要不要重来、什么时候交付都照服务端说的。 做了什么： - 新的 api/chatTurns.ts：发起、查询、停止（挂在 api.chatTurns），streamChatTurn 订阅这一轮的事件日志——先回放、再接实时； 断了按收到的最后一个 seq 自动重连（收到东西马上接着连，连不上按退避），45 秒什么都没收到（服务端 15 秒一拍心跳）当连接死了。 - store/chat.ts：plan / launch / settle / retry 换成发起（launchTurn）+ 播放（play）。收到的操作照原来的渲染逻辑画（画布边收 边长、过程步骤、思考、查看、用量）；收到 run 就接上运行自己的实时流画过程（watch 只画过程，不再判结局）；stage 说到了 哪一步（停在审批上立刻去拿待审批）；turn.retry 照原来自动重来那样重置；end 照服务端落库的那一行摆结局（和刷新之后从库里 恢复的是同一份 restoreTurn）。「重试本轮」「重新运行本轮」「放宽步数」「跑一下」「继续运行」「停止」都走新接口。 - 页面不再写这一轮的结局（不再 PATCH 轮次、不再调 /copilot/review、不再发 POST /api/runs）；失败的说法照服务端记的原因 （meta.cause）按 lib/explain 讲，老轮次记的 failure 照旧认。 - 刷新、关掉再打开：服务端还在跑的一轮（ConversationTurn.job）从这一次尝试的第一条事件接着播；库里停在半路、服务端又没在跑 的（老轮次、服务重启后停着的）请服务端接着收尾（mode=resume），不在页面上自己收尾。问数据页的显示不变。 - 页面上那份退路（MAX_ATTEMPTS、fillInput、retryInstruction、等复核的计时）去掉：决定只在服务端一处。后端对照测试改成守 「页面上不再有这几样」。 - scripts/check-chat.mjs：伪造的服务端照 backend/app/chat/job.py 的做法用原来那几份剧本把一轮跑完（生成、发起运行、等运行的剧本 放完、复核、拼那一行），原有各段照过；守落库的几处改成守「页面不 PATCH 这一轮」和照服务端那一行摆；新加「断线重连补齐」 「刷新、关掉再打开接着看」「停止（建图中也停得下）」几段，并核对发起、重试、放宽步数、继续运行、停止的请求体。 - 服务端顺带：turn.attempt 带上到目前为止的用量、从什么时候算起（补交付的到运行结束为止），turn.retry 带上换下来的那次运行 并进之后的用量（页面上的运行壳子里没有用量）；接着收尾（resume）不要求运行还在，运行记录删了的照实收成「运行记录不见了」。	2026-10-18 16:49:26 +08:00
ThearchyHelios	38addf8f5d	驳回出口与子工作流证据（前端）：画布多一个「驳回」出口、走了驳回出口的那一步画「被驳回」、子工作流里的步骤和证据有名字 ... 接后端两个提交（docs/design/orchestration-round/00-总方案.md §2、§3）： - canvas/nodeDefs：会被人驳回的节点多一个「驳回」出口（id rejected，和后端 REJECT_HANDLE 同一个，中性色）：人工节点三种 模式、双盲复算一律给；沙箱代码只在审批策略是每次审批时给；调用工具选了工具、审批策略不是从不审批时给（数据源的查询 只读，只在明说每次审批时给）。出口跟着配置算：改成不会被驳回时，studio 原有的出口同步把连在驳回出口上的线收掉；补充输入 改成审批时普通出口的线跟到「批准」 - run/trace：node.finished 带 outcome=rejected 时这一步收成 rejected（exited，记下转到哪几步），下一次执行开始时清掉； 子工作流里的步骤不另算一路并行 - run/derive：接了驳回出口的关卡按出口路由（驳回出口 / 其余是普通出口，同 compiler._make_router）；走了驳回出口的算 「送出了数据」，下游照常排队、跑完，普通出口那一侧未到达；退回修改时两条出口都算走过；withSubSteps 把子工作流里的 步骤排在子工作流那一步后面（泳道、航迹的节点列表） - run/decode：走了驳回出口的那一步状态 rejected、副标题写谁驳回、备注、转到哪一步；终态写「完成（途经驳回）」和途经的 那几步（run.finished 的 rejected_via），没有途经的一字不变；子工作流里的步骤名接上子工作流的名字 - run/useNodeView：回放时「走了驳回出口」只说被驳回的那一刻 - canvas/NodeCard、pages/runs/TracePane：走了驳回出口的节点卡写「被驳回，转到「X」」，航迹节点卡写出口和转到哪，关键时刻 多一条「「审批」被驳回，转到「X」」、结局写「运行完成（途经驳回）」 - run/EvidencePanel、types：输入来源写明经哪个子工作流的哪个出口字段；子工作流里的节点（「sub/…」，画布上没有）照证据接口 给的名字写（node_label、subgraph_label），悬停写 id；停在子工作流入口的写「子工作流的运行输入」 - lib/terms：REJECTED_TEXT 加出口、走出口那一步、途经驳回的说法；EVIDENCE_TEXT 加经子工作流的说法 检查脚本：check-decode（驳回出口的步骤、航迹、走过的边、跑到一半、批准走普通出口；子工作流步骤名）、check-run-states （reject-exit：卡片状态与剪影、槽里写转到哪、驳回边走过批准边没走、运行成功）、check-studio（各类节点的出口、能连能画、 改配置收掉驳回线、改模式线跟过去）、check-evidence（subgraph：输入来源写明经哪个子工作流、子图节点写名字）	2026-10-18 16:30:39 +08:00
ThearchyHelios	3f1eeff841	数据事件触发（界面）：定时页新建时选「定时 / 事件触发」、事件那一节、列表与详情的等待状态、触发历史和运行详情的「由事件触发」 ... 做了什么： - 新建定时任务（目标是工作流时）先选怎么触发：定时 / 事件触发（TriggerEditor 的 TriggerModePicker）；修改时只读地写出触发方式、 说明建好之后不能改。选了事件触发，频率那一节换成事件（EventSection）：三种事件、对象下拉（能选哪些、不能选的原因由新接口 GET /api/schedules/trigger-options 给，界面照着画、选不了的置灰并写原因）、上传表格的期次（只认新增的一期）、上游工作流的 只认应用 / 只认来源和触发链上限的说明、去抖、时区；换事件种类时对象和过滤清掉。 - 预览按一次事件渲染输入（对象最近一次的事件，没有时照实说是示例值），不列触发时间；变量按事件种类取（api.schedules.eventVariables）， 插得进 {{ event.* }}；请求体带 trigger_kind、trigger，cron 交空串；修改时只交改了的触发条件。model.ts 加 TriggerForm 与 triggerBody / switchEvent，表单问题里事件触发不查频率、要求选对象；服务端 422 指 trigger 时落到事件那一节。 - 列表、详情：「事件触发」标签，频率处写触发说明；下次运行写在等什么（去抖中收到几次、何时合成一次触发；有事件等待派发；调度 没开时照实说不会派发）。触发历史：类型「事件」，写「由事件触发：…」、合并了几次、第几层；立即运行按最近一次事件发起的写 「按事件：…」并标示例值。运行详情页头写「由事件触发：…（定时任务「X」）」（RunDetailView 只多传一个 trigger 属性），立即运行 按事件发起的写「立即运行定时任务「X」，按事件：…」，不说成由事件触发；应用页印章同样不算。 - 文案进 lib/termsTrigger.ts；SCHEDULE_TEXT 只补触发类型「事件」和「还需处理」里的「触发事件」。立即运行按示例事件的说法 不再在服务端加「（示例值）」后缀，是不是示例值看 real。 为什么：总方案 §4 要求定时页能建事件触发的任务、列表 / 详情 / 触发历史 / 记录页照实显示；能不能选、为什么由服务端判，界面不放逻辑。 验证：tsc、check-copy；check-schedules 加纯函数一段（表单 ⇄ 请求体）和三段页面（新建的请求体、列表 / 详情 / 触发历史、运行详情 页头，含 390px 浅色），假接口加了触发选项、事件预览、事件变量、事件触发任务的夹具，写请求断言请求体；原有各段照过；check-runs 照过。	2026-10-18 16:11:55 +08:00
ThearchyHelios	c3123e3818	转抄口径卡指标的出处跨卡往下追，对账、召回运行按追到底的结果判档 ... 对账卡的「口径」、召回卡的「旧版 / 新版」写成 nodes.<口径卡>.metrics[i].value，出处停在「来自口径卡指标」，对账运行、 召回运行一律降档出具（「输入没追到原始数据」）；口径卡自己的指标明明追得到取数查询。 - engine/lineage：metric_copy 认出转抄一个指标的值的写法；traced() 对 via=metric 的输入看 upstream.traced； MAX_COPY_DEPTH = 8。 - engine/nodes/metrics：转抄的输入记 upstream {metric, artifact, depth, traced}——那张卡的指标集落了工件、那个指标的输入 都追到了原始数据（它自己转抄的已经一层层追过，记在它的输入上）、层数没超上限才算追到；超了就算没追到（防环：循环里 抄自己上一轮的卡每一轮多一层）。那个指标不完整、所依据的查询没通过 SQL 检查的，转抄出来的同样不完整、存疑，出具照样 降档：信任按追到底的结果给，不多给。 - api/evidence：转抄的输入后面接一步 upstream（那张卡的那个指标：值、原式、代入式、它的输入、追没追到，取值按同一套遮罩）， 转抄的转抄接着追（同一个指标只接一次、最多 8 层），它的输入落在查询快照上的照常给查询步骤；出处链里遮着的列把这几步 的输入也算上。reconcile.py、recall.py 生成的式子不用改。 - 前端证据面板：新的一节「转抄的口径卡指标」，输入来源里转抄的那一项写清追没追到、点一下跳到那一步，那一步的输入点一下 跳到口径的取数查询（文案进 lib/terms.ts）。check-ledger 加一段：对账结果里点「按口径」的数，一路点到口径的取数查询。 测试：tests/test_metric_copy_lineage.py（转抄、转抄的转抄完整出具；转抄没追到的照样停在那张卡；上游不完整的转抄也不完整； 层数上限；真跑对账、召回都完整出具，出处链接上口径卡那一步、给出口径的取数查询）。去掉 upstream 再跑，5 条失败。	2026-10-17 12:05:12 +08:00
ThearchyHelios	d17a08bafb	合入 W4-c 账本前端：证据「口径」一步与数字上的小标记、问数据轮次摘要与按口径出具 / 对账、对账视图与反馈、可沉淀的问题、设置里的口径账本一组、比对结果按退避轮询；被驳回的那一步 node.failed 带 reason=rejected，画布、航迹、时间线、问数据过程都画「被驳回」	2026-10-16 22:29:02 +08:00
ThearchyHelios	7f5578c094	定时任务页认得数据源维护：触发历史列出建了的探查、剖析任务和没执行的步骤；「去数据源页设置」改链 #source-<id>（复核 W4R-05、W4R-04） ... W4R-05 为什么：数据源维护的一次触发建的是探查、剖析任务，没有运行；api/schedules._fire_outs 不交触发记录的 inputs， FireRow 只认 run_id 和 eval_run_id，于是每一次建了任务的维护都写成「已发起 · 未发起运行」，和数据源页「定时维护」的 「最近一次」对不上；「立即运行」一次维护还弹「未能发起运行」。 - 后端 api/schedules._fire_outs：目标是数据源维护的触发另带 inputs（{steps, jobs, skipped}，app/data/source_maintenance 记在触发上的那一份，和数据源页「定时维护」读的同一个形状）；别的目标给 null（工作流触发的 inputs 是按模板渲染的工作流 输入，触发历史不列）。触发历史、页头「上次触发」、列表、立即运行的答复都走它。test_schedules_api 的 FIRE_KEYS 加 inputs。 - 前端 FireHistory：维护的那一行逐个列建了的任务（步骤、任务种类、编号、表数），探查链到数据源页那张卡片、剖析链到数据 目录里那个任务的进度（?pjob=，同「最近一次」）；没执行的步骤逐条写原因，服务端连成一句的原因不再重复；没建任务写 「没有建任务」（刚触发、任务还在建写「正在建维护任务」），不写「未发起运行」。 - 立即运行（parts.runNow）：维护开始了说「已开始维护」、详情逐行写建了什么；跳过照实说上一次维护还没做完；没开始说 「没有开始维护」和原因。状态小标签的悬停同理。 - types.ts 加 ScheduleMaintenanceStep、ScheduleMaintenanceInputs（和 W4-d 的 MaintenanceFireInputs 结构一致，合并后 交叉类型照样过 tsc）；叫法进 SCHEDULE_TEXT（步骤叫法同服务端 STEP_LABEL，测试逐个对上）。 W4R-04 为什么：维护定时详情里「去数据源页设置」链到 /data/databases?source=<id>，数据源页（W4-d）只认 #source-<id> （目录页后台任务条「查看」的约定），点过去落在列表顶上。统一成 #source-<id>：链接都经 model.sourceCardPath 出， 探查任务的链接同用它。 检查：check-schedules 新增「纯函数：数据源维护链到哪里、建了什么怎么写」「数据源维护的触发历史」两段（假接口：四种 维护触发、立即运行开始与跳过），改「链到数据源页」的断言；394 项全过。去掉 FireRow 的维护分支、链接改回 ?source= 回跑： 4 项失败。后端新文件 tests/test_maintenance_fire_history.py（立即运行一次维护后触发历史、页头、列表都带 inputs；工作流 触发不列渲染的输入；步骤和叫法前后端对上）。	2026-10-16 22:02:09 +08:00
ThearchyHelios	b24aabefcf	账本前端：证据「口径」一步、数字上的小标记、问数据轮次摘要与出具 / 对账、可沉淀的问题、设置里的口径账本一组 ... 第 2、3 波只有接口，这一波接上界面（docs/design/next-round/02-口径账本.md 做法 3–6、8 的界面、做法 11；总方案 X3、X10）。 界面层不放逻辑：标签、整题判断、能不能出具、能不能自动、不能的原因、要不要先核对参数都照 GET /api/runs/{id}/ledger 给的画。 - 比对结果不靠实时流（第 2 波遗留）：ledger.matched 在封存之后追加、事件总线已经关了，打开着的页面收不到。store/ledger 按退避轮询（1、2、3、5、8、13 秒，之后每 15 秒），服务端答 pending 时写「正在比对口径」，等满 2 分钟还没结论照实说、 给「再取一次」；要自动出具的再等出具的那一次出现，出具、对账的运行没结束的等它们结束。只在有组件看着时轮询，同一次 运行的正文、面板、轮次摘要共用一份 - 证据正文（EvidenceDoc）：来自口径的数字后面挂一个小标记，写明受管 / 已发布，悬停写是哪一份口径、怎么认的；相关口径的 数不加标记 - 证据面板出处链最上面加「口径」一步（run/LedgerStep）：来自口径——「X」v3（受管）· 参数 · 等价已证明 / 助手选用 · 按口径正式出具；相关口径——差在哪 + 看差多少；这次的推理——没有相关的已发布口径；没比对的写原因；脚注写「封存后比对， 不在封存范围内」，事后补比的写按哪种口径回看 - 口径对账（run/LedgerReconcile）：核对参数（照动作里的入口字段画，推断的参数要先核对，遮罩值不回填）→ 发起（认不出列 怎么配时照 409 带回的选项选对照的指标）→ 结果卡片：每组按你的问法、按口径、差值（附相对差）各自点得开出处链 （apps/EvidenceDrawer，同应用页点数） - 问数据轮次底部（run/LedgerTurn）：一行摘要（几个数来自口径「X」vN、几个是这次的推理、几个没有比对）、整题等价时按口径 正式出具（能自动的写正在自动出具；不能的照写原因，使用者没有应用授权写「请搭建者出具」）、有相关口径时对账；出具过的 正式运行挂在下面，档位写完整出具 / 降档出具 / 不予出具，搭建者点开去运行；回收站里的对话只看不发起 - 可沉淀的问题（pages/ledger/CertifyQueue）：工作流列表弹窗里的抽屉，确定性重复、问题聚类、被反复用的答案分开写； 「固化成口径草稿」走 /copilot/from-run 的 freeze 并打开画布，聚类没有共同的 SQL、按人挑的那一轮固化；「不是口径」 要写理由 - 设置（pages/settings/LedgerSettings，照 VerifySettings）：自动按口径正式出具、每日上限、比对时限、升版后每次最多重算几组， 和其余偏好共用保存条、整组写 ledger - 类型 typesLedger.ts、接口 api/caliberLedger.ts（挂 api.caliberLedger）、文案 lib/termsLedger.ts；types.ts 的证据片段 答复加 ledger、rendered 两个键	2026-10-16 20:02:08 +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	1c8ca4c3d7	合入 W3-c 评测执行：后台评测与无头作答、六种期望五种结论的评分、重评、结论裁判记评测账、统计（Wilson 区间、按角色用量）、对比与 A/B（McNemar）、目录贡献预设、预算与止损、清理；定时任务接题集目标，定时评测有退步 / 没有评完推全局渠道；定时页照实显示非工作流目标	2026-10-16 18:46:44 +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	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	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	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	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	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	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	b334f58009	导入清单的「是否认证」界面照记下的说：登录身份 / 未认证署名 ... 为什么：服务端开始如实记「是否认证」之后（导入清单那个提交），界面上的清单、导入记录、接受理由还一律写「署名（未认证）」， 开了登录、署名就是登录的人时说错了（05-已知遗留 (c)）。 做了什么：导入记录接口带上 signed_by_verified（按这一期导入清单里记下的；旧清单记的是 false，照记下的说，不改写；简单导入 没有清单按未认证）。ManifestBody 的文件署名、接受理由的署名，VersionsDialog 的导入记录、快照里各期、接受理由的署名，都按记下 的值写「登录身份：x」或「署名（未认证）：x」，和确认框里那一行（signerLine）同一套说法。接受理由由提交这一期的人写：署名和 清单（导入记录）的一样时才算认证。统计期、修改记录的署名是暂存时记的，没有记是否认证，照旧写「署名（未认证）」。 测试：test_signer_verified 加一句：开登录导入后导入记录的 signed_by_verified 为真。	2026-10-16 10:54:30 +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	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	03a9684a18	数据剖析前端改成逐表的后台任务：对话框看得到每张表的进度，可以停止、重试没做完的表 ... 以前剖析是一次同步长请求，进行中只有一条已用时长的横条、停不下来，关掉页面报告就没了；预算按整次剖析算，几十张表 往往只做完前两三张。服务端改成逐表的后台任务（profile-jobs）后，界面照起草任务的做法重做： - types、api：按接口约定加剖析任务、逐表行、逐表详情（检查清单、发现、发过的查询）、清单行上的最近一次剖析和 profile_due / profile_checks、目录顶上的 active_profile_job，起草任务加 waiting_for；删掉同步接口 profile() 和只给它用的 类型；设置换成每张表最多查询数、每张表时长上限两项新键 - profileJob.ts（新）：useProfileJob，进行中每 1.5 秒取一次，状态只往前走，关掉对话框照常进行，结束时右下角提示 - ProfileDialog 重做：开始前四种范围和个数、按表写的预算和这次最多约几条查询、只读一条一条发可随时停止的说明，同源有 起草任务时「排队剖析」；进行中逐表一行（状态、各类检查进度、查询数、用时、正在做哪一项），点开看检查清单、发现和发过的 查询；结束后汇总、止损和停止的原因照实写、按有发现 / 有跳过 / 失败筛、重试没做完的表；409 六种情况各有说法和下一步 - 目录页头部起草、剖析各一个进度入口；表清单加「剖析」一格和「需要剖析」开关（地址里记 profile=due）；表详情加 「数据剖析」一节和「剖析这张表」 - 起草排在剖析后面时写「排在剖析任务后面，剖析结束后自动开始」 - 文案：去掉「剖析无法中途停止」「总时长上限」等已不成立的说法，补上新的跳过原因和任务状态的叫法	2026-10-15 18:14:14 +08:00
ThearchyHelios	7739340607	普通用户建应用集成收尾： ... - 问数据和个人应用的图放行绑定只读查询等合规工具的调用工具节点，只读和遮罩在这条路径上生效；被治理成写入的工具在只读运行里直接拒；知识库范围在工具层固定（图级默认值、参数名纠错、Agent 都改不了） - 个人应用的刷新和个人蓝图的试运行只有拥有者能读：运行、事件、证据、工件、文件、运行与审批列表、对比、可验证报告、质询、假设分析、提取工作流一并收紧；个人蓝图的试运行不论谁发起都按个人应用约束 - 共享蓝图只给拥有者、对应应用的管理者、管理员，看不到的一律 404；审核副本归审核人；管理员看别人的个人应用只有元数据、可以归档 - 记录表跨版本汇总（只读挂载旧版本、按当前列 UNION ALL、各版本各自固定高水位，缺的版本照实写进印章）；停用前发起的运行可以继续写旧版本；更正沿用原提交人、更正人记审计 - 约定收口：待办种类 review、事件 file.extracted、表单错误 file、模板定义带示例与预置；前端类型一次补齐、去掉临时的局部类型；审核待办卡不再给打不开的链接；读附件事件有中文说法；检查脚本补断言	2026-10-15 13:55:19 +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	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	49f00c589a	目录修改提案的依据改存成目录项单独的字段 reason（界面上叫「确认时的依据」，最多 500 字，超了截成 499 字加「…」），不再拼进备注：拼进 note 之后，带依据保存的关联关系再剖析时测量的说法换不了新、和覆盖率那一栏对不上；改了值的关联关系旧依据叠在新依据后面、越存越长；值不变、保存即确认的项撤销审阅回到推断后「依据：使用者说……」还挂着，看起来像使用者确认过一条推断项。去留：值改了（关联关系也一样）换成这次的依据，没写就去掉旧的；值不变的确认换成这次的，不叠；单项确认、驳回留着，撤销审阅去掉；整份提交改了值的、状态改回推断的、双盲复算改写的去掉；剖析刷新关联关系的测量只动备注。校验认 reason（文字、最多 500 字），起草、剖析的合并不碰人工确认的项，导出导入时已确认、已驳回的项连依据一起带，推断、有确证的项不带。表助手背景里已有的依据写成「以前确认时的依据：……」，系统提示词和 propose_changes 的说明写清那不是这次对话里使用者说的话、引用时写「以前确认时的依据写着：……」，遮罩列的项不给。表详情里依据和说明分开写：表级的项在值下面另起一行，列的一格、关联关系另一个悬停图标（读屏念「确认时的依据：……」），状态弹层里也写，驳回的项只在弹层里写；check-catalog-loop 的假服务端照服务端记下依据，补依据和说明分开、弹层、驳回项的检查；README 表助手一行写上依据另存	2026-10-14 15:38:15 +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	a9ffbcfa86	数据目录闭环（前端）：类型、接口、文案和纯函数——起草任务的逐段落盘、块进度字段和清单的 blank_columns_from；审阅队列、成批审阅、审阅进度、用过这张表的运行；导出导入（下载文件、预览、导入）；表助手的事件流（按行读 data: <JSON>，开流前被拒带状态码和机读码，能停止）；表助手的对话怎么截（最多 40 条、每条 4000 字、从用户的话开始）、待保存的修改怎么累积（同一路径以最后一次提案为准、保存带最早那条提案的版本、409 后按预览重算）；审阅视图的地址参数、成批结果和表详情改过之后的状态同步；文案进 lib/terms.ts	2026-10-14 08:44:14 +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