a9f1555da2
分析能力入口（一）：设置加「分析」一组（api/settings.py 的 analysis：判定用的阈值、一次运行最多分析几次、最多下钻几层、列出前几段），键、缺省、取值范围、叫法全取 app/analysis/contract.py（DEFAULTS / RANGES / LABELS / settings_problem），设置接口里和 ledger 组同一个写法：GET 按生效的样子给（存坏了的项按缺省，「明显超出」不大于「超出常规波动」、最多用几期历史小于至少几期的那一对一起按缺省），PUT 先查后写（不认识的键、类型、范围、两两之间的大小，说法用设置项的叫法），浮点的项存成浮点；analysis_settings 给发起时的快照和没有快照时现读用
2026-10-21 13:01:47 +08:00
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
f87b07694d
助手搭图时就发现「查的区间里表里没有数据」：自查（GraphChecker）对工具节点写死的 SQL 按今天跑一遍覆盖检查（data/coverage.sql_gaps：不跑原 SQL，只跑算界和现查范围的两条小查询，SQL 里所有带时间谓词的表都查，按表去重、限时，异步查库，带模板的 SQL 不查）；完全不重叠的作为一条 sql_no_data 问题交回模型改一轮（换有这段数据的表，没有就在 done 的说明里照实告诉用户数据只到哪天），修正后仍在的不挡运行，作为提醒留在检查结果和交付的问题清单里（问数据流式、画布非流式都是）。look / db_schema 的剖析信息在日期范围最早和最晚是同一天时加一句「剖析时这张表的 X 只有一天的数据，可能每天整表重灌：算历史周期请换有历史的表」；助手节点手册写明按周期取数前先看表的日期范围，只有一天、最新日期早于要查的区间的表不能用来算这段时间
2026-10-20 10:38:30 +08:00
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
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
8ce578042c
合入：工作流可以改名（画布顶栏、工作流列表各一个入口；服务端拦空名、超长、重名，内置模板不改名）
2026-10-20 08:19:32 +08:00
3c5c9d3c15
工作流可以改名：画布顶栏名字旁边、工作流列表每一行多一个「重命名」，两处共用 canvas/WorkflowPicker.renameWorkflow——只改名字，不加版本、不碰图，画布上还没保存的改动原样留着（改的正是打开的这一张时只换它的名字）。服务端 PATCH /api/workflows/{id} 的名字以前原样写入：现在去掉首尾空白，空名 422、超过 200 字 422、和别的工作流同名 409；内置模板不许改名（启动时 seed_defaults 按名字补内置模板，改了名下次启动会再导入一份原名的），界面上也不给模板改名入口，要改就「以此模板新建」。测试 tests/test_workflow_rename.py
2026-10-20 08:18:55 +08:00
6b68961c65
助手把操作写成工具调用格式时照操作读；一个能落地的操作都没有时当场纠正一次；报错按诊断照实说
...
部署上画布助手连着几轮报「助手本轮未完成：模型没有给出任何修改，也没有说明原因」，又试了一次才成。本地用同一网关、同一模型、同一底图和需求重放复现：模型思考里写着「先输出 look」，正文却是一段 DeepSeek 的 DSML 工具调用（invoke name="look"，参数 need、targets），意图和参数都对，只是不是约定的单行 JSON。读流只认 JSON 和原生工具调用，于是一个操作都没认出、整轮报错；画布不处理 next=retry，点重试原样再发，几率不变。提示词里「输出这一行就停下，系统把结果交回来」很像工具调用，却从没说这里没有工具调用接口。
- engine/toolcalls：take_leaked_calls 读写成文字的工具调用（DSML 竖线一到两个、带不带空格，<function_calls><invoke>，<tool_call>{name, arguments}，DeepSeek 特殊 token 两种排法），按出现先后交出已写完的调用和没写完的那一段；final 时参数写完整、只差结尾的补上结尾再读，写到一半的不硬读。_MARKUP 补认 DSML 结尾标签和 function_calls / tool_calls 包装（agent 节点的识别跟着受益）。has_markup 只认标记本身
- copilot_gen._iter_ops：从有标记的那一行起攒，一次调用写完就按名字读成操作（名字是操作名的才认，规矩同原生工具调用 _call_op；op 写在最前，接着写时交回模型的是约定写法），读到 look 照样停下去查看；读不出的记「工具调用标记的名字不认识 / 参数解析不了 / 没写完」；raw 交出正文开头一段
- Generation：起草时一次调用读完、到这时还没有能落地的操作（plan、look 不算——查看完接着写什么都没认出的整轮照样是空的），把原话交回去、附 StreamDiagnosis.correction 那句纠正，当场重写一次（FORMAT_NUDGE_PROMPT，每轮一次）；什么都没写的把纠正接在最后那条消息后面。诊断按次收（absorb），记 nudged。写成标记被读出、当场纠正都打 info 日志
- 报错说法：Generation.empty 默认用 StreamDiagnosis.headline（写成工具调用格式 / 只写了思考 / 什么都没有输出 / 格式不对 / 只说了打算），不再一律「也没有说明原因」；摘要注明当场纠正过
- 提示词：look 用法（四个入口共用）和画布、应用、蓝图的输出格式都写明这里没有工具调用接口
- 问数据失败原因 meta.cause（kind=copilot）带上 code、diagnostics
验证：本地真模型重放，修后 DSML 没再出现、都正常交付；把第一次调用换成读不出的 DSML 后交给真模型，都被当场纠正救回来（先 look 再出操作）；原先抓到的真实 DSML 原文离线读成 look。测试：新增 tests/test_copilot_markup_ops.py（各写法、流式切碎、和 JSON 行混写、读不出的诊断、DSML look 驱动真查看、说明文字 / 只写思考 / 只写 plan / 查看后空续写的纠正、只纠正一次、画布流不报错、报错说法、提示词）；空生成相关的旧测试按「一次生成先纠正一次」更新（基线夹具 no_ops 的说法）。后端全量通过。
2026-10-19 22:48:23 +08:00
fa951a2756
切到账号密码登录时，已经有能用密码登录的管理员就不再要求建第一个管理员：以前设置页只要从「未开启」切到账号密码登录就一律显示「第一个管理员」表单、一律提交 bootstrap（前端 needsBoot 只看切换方向），库里已经有设了密码的管理员也得再建一个。/api/auth/settings 现在带 local_admins（没停用、能用密码登录的管理员）和 passwordless_admins（没停用、还没设密码的）；设置页按它判断：有能登录的就提示「切换后用其中一个账号登录，保存后会回到登录页」、不提交 bootstrap；只有没设密码的管理员时照旧要建，并说清是谁没设密码、可以在用户列表里给他重设密码。从单点登录切到账号密码登录同样按这条判（以前不显示表单、后端却要求）。用户列表里新建用户、重设密码后，登录方式那一块重新判断。判据和后端 _local_admin_exists 同一个
2026-10-19 18:48:22 +08:00
29c44ce65a
助手一个操作都没给（copilot_empty）时看得出模型交回了什么，自动重来带一句纠正，格式跑偏的操作不再被静默丢掉：copilot_gen 新增 StreamDiagnosis，起草阶段记结束原因、正文（不算空白）和思考的字数、认出几行操作、原生工具调用的名字、跳过的行按原因数（不是完整的 JSON、不是 JSON 对象、缺 op、工具调用名字不认识、参数解析不了）、正文里写成文字的工具调用标记，只记长度个数和原因、不记原文；copilot_empty 的 error 带 detail（一句话）和 diagnostics（机读），问数据、画布、应用润色、蓝图四处一致，非流式的 502 也带上。重来时交给助手的原因换成按诊断给的纠正（只写了思考 / 什么都没输出 → 直接输出操作、要看表先写一行 look；格式跑偏 → 每个操作单独一行完整的 JSON；用了工具调用 → 这里不走工具调用），chat/turn.empty_retry_instruction 附在问题后面，不原样重发；诊断随 turn.retry 事件记下。原来静默丢掉的写法照常读：分成多行写的 JSON（以「{」开头读不成就往后攒）、和围栏写在同一行的操作、原生工具调用里名字是操作名的（参数就是操作的字段）
2026-10-19 17:55:02 +08:00
ba4c604539
数字标记后面重复写的单字单位也去掉（部署上的「覆盖 8条 条产线」）：以前单字的单位后面紧跟着字时一律不动，现在只在它和后面的字连起来是一个更长的单位（人次、个月、台套、元/…，_LONGER_UNIT）时不动，让「人」对「人次」这样的不一致照旧露出来；「条产线」「人参加」照样去掉重复的那个字，流式渲染一致。写作规则加一条 UNIT_RULE（[[m:]]、[[v:]] 自带单位，后面不要再写一遍），助手节点手册讲 [[m:]] 的那一行也写明
2026-10-19 17:55:02 +08:00
41b350b87c
相对日期一律按运行当天算：助手节点手册的搭图规则（画布、问数据共用）加第 6 条——「今天、昨天、上周、本月、去年」按运行当天算，SQL 用方言里取当天的写法、agent 先调 current_time，不用 MAX(日期) 去推「上周」，要说数据最新到哪天就另取一列；报告写作规则加一条（period_rule），告诉写作者今天是哪天、上周是哪几天：数据没覆盖问的那段时间时先照实说、写明数据最新到哪天，最近一段的数可以给但写具体起止日期，不叫它「上周」「本月」
2026-10-19 16:53:46 +08:00
1e87504e5c
复核把「首稿没过、重写后已通过」当缺口：report_repair、report_rewrite 这类「改过一次」的信号按同一个报告节点最后一次 report.checked 定档——最终通过的（没有违规；裁判摘要里不再有证据不支持的句子）不进复核的异常清单，复核模型被别的信号叫起来时，说明里另起一节「已经处理好的」写「报告「x」首稿有 N 处没过核对，重写后已全部通过」，不再写成「核对仍未全部通过、可能不准」；最终没过的照旧记缺口。report_repair、report_rewrite 的日志带上处数
2026-10-19 16:43:54 +08:00
4e3623885b
合入 W2-a 的复核修复（nr8/a：导入的 NOT NULL 补值与孤儿行、收尾 dispose、sslmode 换算、PostgreSQL 写入去 NUL、不分大小写搜索 contains_ci、json_eq 两库同语义、JSON 守卫、用户可见列表补决胜键、bubblewrap --clearenv、部署脚本与原子写的几处、README 连接数预算）
...
# Conflicts:
# backend/app/api/schedules.py
# backend/app/main.py
2026-10-19 12:21:38 +08:00
0d9f1d9339
用户看得到的列表补决胜键（复核 R-a9）：按名称、时间等可能并列的排序后面补上同一个模型的 id，并列时两种库排出来一样
...
- 实测 /api/evals/calibers、/api/schedules/trigger-options 按 Workflow.name 排序遇同名并列时 SQLite、PostgreSQL 顺序不同。用 AST 逐个过了一遍 order_by：最后一个排序键是 created_at / updated_at / last_active_at / at / name / 各种 *_at 之类、不唯一的列，又不带 DISTINCT、GROUP BY 的，补「, 模型.id」（降序补 id.desc()），共 104 处，分布在 api、apps、auth、blueprints、chat、data、engine、eval、ledger、look、memory、process、providers、scheduler（runs.py 里的三处在上一个提交里）
- 按唯一列（seq、version、唯一的 name）排的不动；按聚合、coalesce 之类表达式排的说明见 db/postgres
2026-10-19 12:07:06 +08:00
7febf2bcdb
两种库行为再对齐一轮（复核 NUL、R-a4、R-a6、R-a7、R-a10）
...
- 编排者的决定：PostgreSQL 下文本列写入时去掉 NUL 字符（before_cursor_execute 钩子，只装在应用库引擎上，看所有字符串参数，没有 NUL 的原样交回），SQLite 不变；同 JSON 列的处理
- R-a4 应用库地址里的 sslmode= 换成 asyncpg 的 ssl=（取值同一套），sslrootcert 等证书参数、application_name 这类 asyncpg 不收的参数启动时就报错并说怎么写（证书用 PGSSLROOTCERT 等环境变量）；断点库连接串换回 sslmode=
- R-a6 不分大小写的搜索换成 db/portable.contains_ci：SQLite 上同 ilike（lower LIKE lower），PostgreSQL 上模式带 COLLATE "default"（列是 COLLATE "C"，列上的 ILIKE 只认 ASCII，É/é、Ж/ж、全角Ａ/ａ 匹配不上）；运行列表按名字、对象索引按注释两处都改；改正 db/postgres 里那句说明
- R-a7 JSON 守卫改成编译层：tests/jsonguard 挂在应用库编译器上（conftest，两种库、跑全量时一直生效），整个 JSON 值出现在 = / != / IN / IS DISTINCT FROM / 大小比较、SELECT DISTINCT、GROUP BY、ORDER BY、UNION（去重的几种）里就报错；按类型认，变量别名、跨行 order_by、select(Run.origin).distinct()、JSON 下标的比较都抓得到，测试拿这些反例证明，json_eq、IS NULL、UNION ALL 不受影响。原来的逐行正则测试删掉
- R-a10 json_eq 两种库同一语义、按 JSON 类型比：字符串只等于字符串，数只等于数（1 等于 1.0），True / False 只等于 JSON 的 true / false（SQLite 上用 json_type 分开，以前 1 能匹配 true）；非标量 TypeError。json_text 两种库都是「字符串取本身、别的取 JSON 写法」（SQLite 上同 PostgreSQL 的 ->>），数 1 的 json_text 两边都是 '1'
- db/postgres 说明里写清 NULL 排序补写的范围（只认直接按列排的）
2026-10-19 12:06:31 +08:00
ae254b052e
合入遗留收口分支 nr8/l 的复核修复（变化记录先占住那一行再读改写、召回里行序不定的指标、事件触发列表按任务各取上限、选对象按名字查用 ilike、子工作流写入认旧键、几处测试的竞态）
...
# Conflicts:
# backend/app/ledger/recall.py
2026-10-19 12:05:19 +08:00
c768c56fd7
多进程协调补齐几处：执行时长从拿到名额算起（排队等名额不算执行，墙钟本来就从开始执行算）；蓝图留痕、蓝图助手开轮先占住那一行再取最大值往下接；问数据等别的进程接着跑的运行时回库里等封存；按配方导入的 AI 起草、知识库重建索引另取跨进程的锁（多进程时重建进度记在设置表里，别的进程读得到、属主不在了照实说没做完）；调度循环一拍的间隔可配（AGENTLAB_SCHEDULER_TICK_S）
2026-10-19 11:51:29 +08:00
20f8eb37e0
选对象按名字查改用 ilike（复核 L3）：PostgreSQL 上 LIKE 分 ASCII 大小写、SQLite 不分，两种库说法不一；% 和 _ 照 runs._like 转义、按字面匹配。补测试
2026-10-19 11:44:49 +08:00
87f0d62f9b
多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁
2026-10-19 11:40:33 +08:00
358206312e
事件触发的规模：定时任务列表里每个事件触发任务「有几条在等」一次查齐（outbox.pending_for_many：待派发数一条 SQL 按任务分组算，窗口要看的事件一次读出），不再每行查一次；每一拍派发只读触发条件的事件种类、对象对得上的任务（SQLAlchemy 的通用 JSON 访问），保存时查环一层查一次、只顺着「上游工作流运行成功结束」的边找；选对象（trigger-options）按事件、关键字查、一页最多 100 个、more 说还有没有，当前选中的总在里面，编辑页一页没列完时多一个按名称查找。顺带修：等着的时候任务改了条件、最早那条不再合条件时，「什么时候合成触发」按剩下的最早一条算（列表上的时刻和真发起的一致）；一个窗口的结束时刻和这个任务已有的另一次触发撞在同一刻（别的期次早一拍发了）时往后挪，那几条事件照常发起，不再被记到已有的触发上
2026-10-19 09:46:47 +08:00
04d80472f9
子工作流里的反方审稿按全局 id 记它审的报告：审稿记录和工件上的报告写这次运行里的 id（「sub/write」，同 report.checked、报告文档，第 1 波 B1 修过报告节点同样的问题），证据面板连子工作流里的审稿一起认（_Sealed.nodes_of nested），点开子图里那份报告的句子认得出审它的那次审稿；审批卡上的报告按全局 id 记，打开证据面板、审批质询对得上；单句面板的报告名写「子工作流 › 报告」，不写内部 id
2026-10-19 09:08:45 +08:00
aa051b0a28
运行对比里子工作流的口径卡按卡所在那一层找产出：组装推演用的 Sources 时带上是哪张卡，节点产出、跑完的时刻按 engine/lineage.in_scope 换成卡那一层的 id（同推演 api/whatif._sources、证据面板 _InputMasks._output）。以前子图里的卡取值链写的是子图里的 id（nodes.parse），对比拿父图里同名的节点当它的产出，容器输入认到父图那次查询上；加一条子图卡的真跑对比测试
2026-10-19 09:03:37 +08:00
ebf1d63269
助手的节点手册讲驳回出口：哪些节点能接（审批、补充输入、编辑稿件、动作确认、代码和工具审批、双盲裁决），连线写 sourceHandle="rejected"，什么时候接（驳回后要通知、退回修改、走另一条路），不接时怎样（运行结束、记为被驳回；审批模式这一路到此为止；写了驳回即终止就别接），驳回那条路必须走到成果节点或结束，失败重试、出错时继续不管驳回。以前手册只有一句审批的 approved / rejected，助手画出来的图驳回就整轮结束
2026-10-19 08:47:53 +08:00
c0739dfd5d
合入 W1-c 数据事件触发：定时任务加「事件触发」（上传表格出新一期、上游工作流正式运行成功结束、数据源有要处理的变化），事件在发生处写进待派发事件、调度循环去抖派发；保存时与运行时防环；{{ event.* }} 模板变量；途经驳回、应用补算的缺省不认（可勾选）；积压一拍处理完、过期的合成一条跳过；按期次分窗口；定时页可选「定时 / 事件触发」
2026-10-18 18:23:33 +08:00
3d5fb19fbd
合入 W1-b 子工作流证据交回父图 + 驳回出口：子图每一步进同一个运行的事件流；子图出口字段带出处，父图口径卡、报告跨子图追到原始数据（运行时、证据面板、静态检查同一套，最多 3 层）；报告目录收进子图里的查询和口径卡；审批、动作确认、代码和工具审批、双盲裁决可接「驳回」出口，驳回后沿出口往下走（不接时行为不变），动作确认走出口不发送；发布检查拦下走不到结束的驳回路径；实例页、通知写「被驳回，转到 X」；子图里的报告按全局 id 记、父图只认自己的报告
2026-10-18 18:23:15 +08:00
32dbfcfb52
复核修正（后端）：子图里的报告不再被判「疑似被修改」、驳回出口的双盲裁决照样降档、可验证报告与推演按卡所在的层找产出、子图那一步写名字
...
- B1 子工作流里有报告撰写节点时：它的 report.checked 进了父运行（节点 id「sub/write」），报告文档却记子图里的 id「write」，
证据接口、可验证报告、质询拿两边一比判「疑似被修改」，评测读答案也说答案不能当证据。
- nodes/report：报告文档、产出工件记这次运行里的节点 id（ctx.run.global_id），和事件同一个；nodes/io 子图自己的出具契约
按同一个 id 核对，_issuance.report.node_id 同样写这次运行里的 id
- api/evidence：_reports 默认只认父图上的报告（子图的报告是子工作流那一步内部的东西，父图的答案是子工作流出口的值），
nested=True 连子图里的一起给；点名要子图报告的（?report=sub/write）照样点得开（_named_reports）；按成果挑报告的兜底
不再挑中子图的报告。成果上没有 _issuance 时退回最后一条 issuance 事件，子图成果节点的那条不认
- bundle：出具档位（_tier）同样不认子图成果节点的 issuance，verifier.js 同一个认法；子图报告的文档在引用链上照常核对
- B2 双盲裁决被驳回、走驳回出口接到出具成果时：节点产出换成 exit_payload，出具缺口和 dual_check 台账条目跟着丢了，审核人驳回的
那组数照样完整出具（比选「两边都不对」还宽）。NodeRejected 加 exit_updates（节点在驳回之前已算出的产出字段、台账、用量），
compiler._rejected_exit 并进去；双盲复算驳回时照记缺口「指标「X」两路结果不一致，审核人驳回了裁决」和一条结论为驳回的
dual_check。核对过别的关卡：人工节点、工具调用审批、动作确认、代码执行审批都在产出缺口、台账之前就被驳回，没有可丢的
- B4 子图里的卡转抄同一张子图里的卡、按位置取格：可验证报告（bundle/build._outputs_of）和推演（api/whatif._sources）按这次
运行里的 id 查产出，子图卡上记的是子图里的 id，查不到就整张遮住、推演不了；父图有同名节点时还拿父图那个当依据。改成按卡
所在那一层的 id 查（engine/lineage.in_scope / scoped_id，证据面板 _InputMasks 同一个认法），转抄的卡认不出时的兜底同样换层
- B6 子图里的一步出错、被驳回后 Run.error_node_id 是「sub/x」：实例页（apps/resolve）、通知（notify/service）照终态事件上记的
名字写「子工作流 › x」（run_node_label），不露出内部 id
测试：test_subgraph_evidence（子图含报告：证据图按父图、评测读答案不报被改、子图报告点得开、可验证报告核对通过且不写子图的
档位、子图自己的契约照常；子图卡在可验证报告里不被遮、推演还原得出、父图同名节点不当依据；子图那一步的名字）、
test_dual_check_node（驳回出口接到出具成果照样降档、台账照记、证据面板认得）。每条都去掉修复回跑过，确实失败
2026-10-18 18:15:37 +08:00
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
85eee89799
问数据一轮的复核修正（后端）：同时来的几次发起只起得来一次、事件 seq 不撞号、晚到的复核记得上也送得到、使用者不能继续运行、
...
入口的 history 只取这一轮之前的、只有问数据的对话能发起
A1 并发发起不原子（复核实测：同一对话同时两次新问都 202、两轮 seq 都是 0；同一轮同时 3 次重试 [500, 202, 202]，同一轮建两次图、
停止只停了后一个；写 turn.attempt 撞号时任务已提交成排队却没有后台任务，这段对话从此一直「正忙」）：
- 发起的核对和写入（这段对话忙不忙、下一轮排第几、轮次、任务、这一次尝试的第一条事件 turn.attempt）放进一个事务，第一句先占住
这段对话（hold_conversation：SQLite 上拿到写锁、PostgreSQL 上锁住这一行），同时来的几次一个接一个，后来的看得见先来的写下的；
重试、接着收尾的那一轮占住之后重读，任务按「不在排队、不在跑」条件更新、看 rowcount；写不进去整个事务回滚，什么都不留下。
继续运行要先续上那次运行（它用自己的会话写库，不能放进占着对话的事务），续上了却没排上队的把它取消；挂起旧运行的取消挪到
提交之后（只有排上队的那一次去取消）。页面打开时自动发的接着收尾占锁时不改活跃时间。
- conversations.new_turn 先记活跃时间再数 seq（第一句写就占住这段对话），老页面的开轮接口也不再撞号。
- 事件的 seq 由任务行上的计数器发（UPDATE … SET last_seq = last_seq + 1 RETURNING），同一轮同时追加的几处各拿不同的号。
- ChatTurnManager.start：同一轮在这个进程里还有后台任务活着就不起第二个、不覆盖登记；上一次的任务刚记完结局还没退出时等它退出再起。
A2 使用者（user 角色）现在能「继续运行」了：以前 POST /api/runs/{id}/continue 对它是 403（只放行停止），问数据这里照原说法回 403
role_required，运行不动；重试本轮、重新运行本轮照常。
A3 晚到的复核：先写库、发 review.late，再出登记、叫醒订阅方（以前反过来，开着的实时流先收到 stream.end 走掉）；那一行的几处写入
（任务、晚到的复核、下一次尝试）先占住那一行再读改写（hold_turn），用量改成按增量记在库里那一份上（以前任务开始时拿一份拷贝、
之后整块盖回去，重试时晚到复核记的那笔会被盖掉）；自动重来时换下来的那次运行交出去之后不再当这一次的运行记一遍。
A4 运行入口的 history 只取这一轮之前的：新的 conversations.run_history 照以前页面 historyOf 的规则（答案没有用说明、都没有的跳过、
每轮截 600 字、最多 6 轮），重试、重新运行较早的一轮时后面几轮不再进它的入口。
A5 只有问数据的对话（kind=chat）能发起一轮，别的种类 422 chat_turn_invalid。
测试：tests/test_chat_turns_races.py（asyncio.gather 并发两次新问、三次重试、两个标签页接着收尾、二十次并发追加事件；发起写到一半
出错什么都不留下；后台任务不起第二个；使用者继续运行 403 且说法同 /runs；开着的流收到 review.late；重试不丢晚到复核的用量；
history 只取之前的、截 600 字、跳过没答案的；重新运行较早的一轮不带后面几轮；只认问数据的对话）。先写测试，12 条都失败；去掉
占锁、计数器、不起第二个、先写库再叫醒、增量记用量、同一事务、按 seq 截这几处修复分别回跑，对应的测试都会失败。
2026-10-18 18:07:03 +08:00
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
3998e821dc
子工作流的证据交回父图（后端）：子图每一步进同一个运行、台账和口径卡交回、出口字段带出处、父图跨子图往下追
...
调查时发现：run_subgraph 只设了节点 id 前缀（node_prefix）没用上，子图在父节点里用 ainvoke 跑，LangGraph 不把它的
custom 事件交给父图的流——子图里每一步在运行的事件里一条都没有，时间线看不到、封存也不含它查过的数。「事件本来就在同一个
运行里」此前并不成立（docs/design/orchestration-round/00-总方案.md §2）。
- engine/context + nodes/multi：子图拿到父运行的写入口（STREAM_KEY）和前缀（PREFIX_KEY），子图里的节点经它发事件，节点 id
「子工作流节点 id/…」，嵌套的一层层接上；工件按这次运行里的 id 记。子图里报的错（含被驳回）交回时节点 id 换成这一层的、
名字接上子工作流（runner 的 run.failed / run.cancelled 写「子工作流 › 那一步」），不再和父图里同名的节点混在一起
- nodes/multi：子图的台账条目加前缀并进父图 evidence（父图报告的目录据此收进子图里的查询和口径卡）；子图口径卡的产出以
「子工作流节点 id/卡」进父图 nodes；出口每个字段按出口模板认出处（模板整串就是一个取值链、渲染出来正是那个值的才认，
同口径卡认输入的那一套），出自子图运行输入的按子工作流节点的「输入」模板再往父图追一层，追不到的记 subgraph_input
- engine/compiler：子工作流节点自己的 node.finished 不再重记交回来的台账条目（子图那几步自己的 node.finished 已经带着）
- nodes/metrics：父图口径卡读 nodes.<子图>.output.<字段>（或 assign_to 变量的字段）时接上那个字段的出处，另记 subgraph、
field；经子图出口转抄子图口径卡的指标照样带上不完整、存疑；cell(nodes.<子图>.output.<原样交出的查询结果>, …) 按台账
认出子图里的那份快照
- engine/lineage：静态认法跨子图往下追（出口模板 → 子图里接着认；子图的运行输入按「输入」模板回父图认；最多 3 层），
和运行时同一套；whole_ref 是两边共用的「整串一个取值链」判断。lint_process.load_subgraphs 往下读嵌套的子工作流，
subgraph_spec 给静态认法取图；没读好放进来的照旧停在子工作流节点
- nodes/report：报告收证据的范围加上上游子工作流交回来的（evidence_from 写了子工作流节点的一并算）
- nodes/io：指标出具的缺口里，停在子图里的说停在那个子工作流（和静态检查同一句）
- api/evidence：卡上记的节点 id 按卡所在那一层认（_scoped：子图里的卡写子图里的 id），转抄、输入、追不到的那几步一路给到
子图里的那一格；子图里的节点按 node.started 记的名字接成「子工作流 › 节点」（node_label、subgraph_label）；双盲复算条目
里的卡 id 同样换成这次运行里的
- apps/resolve：实例进度不单列子图里的步骤
- 口径账本的 use_caliber 不改；比对读封存的查询，子图里的查询如今在封存范围里，照常认得出
测试：test_subgraph_evidence（子图每一步进运行、报错点名子图里那一步、实例进度、父图口径卡跨子图追到查询格并完整出具、
子图里追不到的父图降档、不是整串取值链的停在子工作流、运行输入往父图追、嵌套两层、静态检查与运行时一致（含两层和输入
模板）、父图报告引用子图里的查询和口径卡并一路点到那一格、封存与可验证报告、子图里的遮罩照父图的运行）。去掉「交写入口」
回跑，五条失败（快照不在封存范围里）。后端全量 14472 通过
2026-10-18 16:11:15 +08:00
d18a496ef9
问数据整轮放到服务端跑（后端）：一轮是一个后台任务，建图、运行、复核、按复核重来、落库都在服务端，页面断了也会跑完
...
为什么：一轮问数据以前是浏览器在推（store/chat.ts 的 plan / launch / settle）：网络一抖建图那条流就断、建了一半的图丢掉；
发起运行、复核、重来、落库都要页面在，页面一关这一轮就停在 running，15 分钟后才被判成断了（总方案 §0 的调查结论）。
做了什么：
- 流程和评测共用一份：eval/answer.Driver 里的流程抽到 chat/drive.TurnDriver，差异写成子类给的几项（生成的请求、目录视图、
改图、入口、发起参数、停在审批上怎么办、复核等多久）。评测的 Driver 成了它的子类，行为和测试一字不变（test_eval_* 照跑）。
- chat/job.py：问数据的一轮是 core/job_runtime 上的后台任务（不占数据源的队，并发归「交互」类，第 2 波再给上限和优先级）。
停在审批上照旧等人（评测是取消）；复核最多等 25 秒，晚到的那次用量照记（review.late）；按复核自动重来一次；用户点的
重试本轮、重新运行、放宽步数、跑一下、继续运行、接着收尾都是同一轮里的一次尝试，上一次的结局归档进 meta.attempts。
- 事件日志（新表 chat_turn_events，models_chat.py，不进运行的封存范围）：每一步按 seq 落库再叫醒订阅方，订阅方按 seq
回库里读——回放和实时是同一段代码；心跳一拍也回库里看一次，第 2 波多进程时别的进程写的最迟一拍送到。
- 接口 api/chat_turns.py：POST /api/chat/turns（202 带 turn_id）、GET /{id}、GET /{id}/stream?after=（SSE：先回放、再推
实时、带心跳、结束补 stream.end）、POST /{id}/cancel。挂 chat_scope，每个接口按这一轮所属的对话核对归属；访问密钥调不了。
- conversation_turns 那一行由服务端写（chat/record.py：状态、运行 id、答案、复核、meta 各项和页面以前写的一一对应）；失败
只记原因（meta.cause），说法留在界面层按 lib/explain 讲。TurnOut 带这一轮的任务（job），列表判「还在跑」先看任务。
- 使用者的问数据运行规则（白名单、自己的记忆范围、遮罩、只读）抽到 chat/launch.user_chat_run，POST /api/runs 和服务端的
一轮共用，说法一字不变。
- 服务重启：还在建图的标中断（可重试本轮）；已发起运行的接着等那次运行、照常复核收尾；和调度循环同一个开关，拷来的数据
目录启动时不替人收尾，页面打开对话时再请服务端接着收尾（mode=resume）。老轮次停在建图中的同样标中断。
- 删对话时先停掉它正在跑的几轮（取消各自的运行），任务和事件日志一并删。
测试：tests/test_chat_turns.py——一轮跑完不依赖页面、直接回答与反问、开流前被拒、实时流回放后接实时与按 seq 重连（补齐、
不重复）、思考合并、建图中与运行中停止、重启时建图中标中断与已发起运行的接着收尾、开关关着时等人来接、等审批后收尾、
按复核重来、用户重试归档、一段对话一次一轮、继续运行被拒照 /runs 的说法、删对话停掉这一轮、使用者的归属与遮罩只读、
访问密钥调不了、驳回与失败与发起被拒的原因、晚到的复核、跑一下与重新运行不重建。去掉几处关键实现回跑，相应的测试都会失败。
2026-10-18 16:05:53 +08:00
a1ab3247f9
数据事件触发（后端）：待派发事件表、调度循环派发与去抖、防环、{{ event.* }} 模板变量、接口收 trigger_kind / trigger
...
做了什么：
- 新表 trigger_events（待派发事件）、trigger_deliveries（一个事件派给一个定时任务、等去抖），放在 db/models_triggers.py，
models.py 末尾整模块导入。事件在发生处、和那件事同一个事务里写一行：上传表格按期累积的新一期启用（table_versions 的
publish_build / publish_snapshot 切指针那一下，移除、作废、回滚不算）、正式运行成功收尾（runner._finalize 写终态的事务里
加两行调用 outbox.stage_run_finished）、探查 / 剖析新记了要处理的变化（source_changes.notify_after_job，一个任务一条）。
发生处不发起运行：事务边界、重复与重启都在派发这边说清，也为第 2 波多进程做准备（认领靠条件 UPDATE）。
- scheduler/outbox.py：调度循环每一拍（fire_due 之后）派发：pending 事件条件 UPDATE 认领成 routed，同一事务里给合条件、启用着的
事件触发任务写 delivery；窗口从最早一条的发生时刻起算 debounce_s（缺省 60 秒），过了就合成一次触发，内容取最新的那条，
fire_at 取窗口结束的时刻（同一窗口永远同一个时刻，触发记录唯一约束兜住重复派发）；照 fire_once 发起正式运行，ScheduleFire
kind=event、inputs 写 {event: 事件说明, inputs: 渲染出的输入}；上一次没结束记 skipped_overlap；派发太晚（超出补发宽限）
记 skipped_misfire；任务停用、改了触发条件时等着的标 dropped。AGENTLAB_SCHEDULER 关着时没有这一拍，事件留着，接口照实说。
- scheduler/triggers.py：三种事件的触发条件（table.version 可选只认新增的一期；workflow.finished 可选只认某个应用 / 某种来源；
source.changed）、核对对象（表格是按期累积的上传表格、上游工作流已发布、应用在）、说法、{{ event.* }} 变量（table、version、
period、activated_at；workflow_id、run_id、outputs.<字段>；source、counts）、示例事件（预览、立即运行用对象最近一次真实的事件）、
防环：保存时查 workflow.finished 串成的环（停用的也算，A→B→A、自己触发自己都拒，422 写出经过的工作流），运行时按 origin 里的
触发深度兜底（超过 5 层记未能发起）。
- service：fire_once / _fire_workflow 接事件（模板按事件种类校验、渲染 {{ event.* }}，运行来源 origin.trigger 带种类、对象、
事件 id、深度、经过的运行和一句说法）；check_template / render_inputs / variables 加可选的 event 参数，cron 任务一字不变。
- api/schedules.py：收 trigger_kind（cron 缺省）/ trigger，event 时目标只能是工作流、cron 存空串、下一次触发为空；返回带
trigger_kind、trigger、trigger_text（也是 description_text）、trigger_state（几条事件在等、去抖到何时、调度开没开）；触发
历史带 event；预览按示例事件渲染；变量清单按事件种类给；新增 GET /api/schedules/trigger-options（各事件能选的对象及不能选的
原因、来源、应用，界面不自己判）；立即运行按示例事件发起；触发方式建好之后不能改。Webhook 照旧可配，通知写「事件触发」那一行。
- 应用页印章的来源（apps/resolve._from_text）照实写「由事件触发：…」。
为什么：总方案 §4 已拍板接这三种事件、不接口径发布，一套定时机制（X4）；派发放在调度循环里而不是发生处，事务和重复都说得清。
测试：test_schedule_events.py（三种事件各触发一次、去抖合并与窗口外另起、重叠跳过、停用 / 改条件丢弃、调度关着时事件留着、
超出宽限、触发链深度与上限、模板校验与渲染、期次写法、通知、印章）、test_schedule_events_api.py（建、核对、防环、改、预览、
变量、立即运行、触发状态、可选对象）；test_schedules_api.py 的约定键集合补上新加的几项。
2026-10-18 15:53:08 +08:00
f8d89e780c
合入 nr6/b：评测「期望没有数据」只认数值格和叙述里的数、逐题 E1 比产出答案的那条查询、判错时给配对上的那一格、估不出金额时不写 0、没做完的模型调用也计一次、助手只给思考不给操作时自动重来一次（问数据与评测同一个决定）、目录两种计数照实说、自由形应用入口与岗位显示名；评分规则升到第 2 版
2026-10-17 12:28:04 +08:00
8c2ff49b50
use_caliber 的协议写清 card 填什么，写错了交回的原因能一次改对
...
真实验收里模型第一次常把 card 写成自己起的 c1 被拒，之后才改对：协议示例写的是 "card":"口径卡节点 id"，紧接着又说
「口径卡（节点 id 就是 c1）」，两个 id 混在一起。
- api/copilot_context.USE_CALIBER_PROMPT：示例写 "card":"card"；说清 workflow_id、version、card 原样照抄，只改 id、metrics、
inputs；card 是那一版工作流图里口径卡的节点 id（查看结果的写法里写好了），id 是这次选用自己起的名字、生成的口径卡用它当
节点 id；add_edge c1 → report 里的 c1 是自己起的 id。
- look/calibers.DETAIL_COMPOSE_PROMPT：同样写明 card 原样照抄、id 自己起。
- ledger/compose：card 写错时说清 card 要填节点 id、可填的有哪几个（「节点 id」（口径卡「名字」）），写成了自己起的 id 的
另说一句「「c1」是你给这次选用起的 id，不是口径卡的节点 id」；几张卡要选时同样列节点 id。校验不放宽。
测试：tests/test_ledger_compose.py 新增两条（协议写清两个 id；card 写成自己的 id 被拒、原因说清该写什么，照着改成节点
id 就过）。改回原来的文字再跑，两条失败。
2026-10-17 12:17:21 +08:00
1b31c49a00
问题聚类的类 id 由成员定，「不是口径」按成员记
...
类的 id 以前按种子问题的原文算：种子是一类里最新的那一句，时间相同的几句读出来先后不定、来了一句新问法种子就换了，
两次读取 id 就变，认证队列里点过的「不是口径」随之失效。
- app/chat/questions：Question.key 是稳定的 id（问数据的那一轮 turn:…、别的探索运行 run:…）；QuestionCluster.id 是成员的
id 排好之后取的哈希，同一批问题两次读取一样；recent_questions 同一时刻问的几句按 id 排出先后，不靠库里读出来的先后。
- ledger/certify：问题聚类那一项的 id 用类的 id；「不是口径」时服务端按同一批问题重新聚一次，记下这一类现在的成员（不收
客户端传的成员，找不到、取向量出错就只记 id）；之后这一类过半的成员是某一次记下的，就照样不进队——来了几句新问法 id
会变，按成员认不失效。以前按种子原文算的 id 记的照样认；记的成员读不懂的照实忽略。
- api/ledger：dismiss 把当前身份交给 certify（重新聚类要按这个人读得到的问题）。
测试：tests/test_ledger_certify.py 新增三条——同一批问题换个先后读，种子不同、类的 id 一样；点过「不是口径」之后换个说法
再问一句，成员变了照样不进队，读不懂的老记录不报错也不藏；按旧的种子原文 id 记的照样生效。把 id 改回按种子原文、把按
成员认去掉再跑，各自的用例失败。
2026-10-17 12:15:07 +08:00
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
78e9b0c6da
目录的「使用次数」和「用过这张表的运行」口径照实写：一个按查询计、一个按运行计
...
验收时同一张表「使用 4 次」、「共 3 次运行」对不上，接口说明（GET /catalog/{table}/usage、catalog_review.table_runs）
却写「取法同使用次数」，看着该是同一个数。两者数的确实是同一批查询快照（catalog.query_snapshot_tables），但使用次数按
查询计（同一次运行里查了两次算两次），用过这张表的运行按运行去重，前者可能比后者大——数没错，说明错了。
改了接口说明、table_runs 的说明和 catalog_review 模块说明里那一条，写清两种计法和为什么会不一样；表清单上「使用 N 次」的
悬停说明写明「按查询算」，并点出下面「用过这张表的运行」按运行算（运行列表那边的悬停说明本来就写清了，没动）。
测试：test_catalog_review_queue.py::test_usage_counts_queries_and_the_runs_list_counts_runs（同一次运行查两次：清单 4、
运行 3；接口说明不再写「取法同使用次数」、写明按运行和按查询）。去掉修复回跑失败。
2026-10-17 11:55:53 +08:00
3dc5f5add4
助手只写了思考、一个操作都没给时自动重来一次：问数据和评测走同一个决定
...
真实模型验收里 deepseek 偶发只出思考、不出操作，生成过程交出 error「助手本轮未完成：模型没有给出任何修改，也没有说明
原因」，问数据这一轮照实报了，但不会自动重来——而这种偶发情况重来一次多半就好，「重来一次」的规矩本来就有
（chat/turn 的 MAX_ATTEMPTS = 2，含第一次）。
- chat/turn：error 也由 next_step 判：机读码是 EMPTY_GENERATION（copilot_empty）的判 retry，别的仍判失败（被截断的不重来：
额度不变，重来还是截断）；error_reason 取重来时交给助手的原因（error 带的 reason，没有就去掉「助手本轮未完成：」前缀）；
- api/copilot.answer_ops：一个操作都没给时 CopilotIncomplete 带上这个码；error 操作多带 reason 和 next（retry | fail），和
final 的 next 一样由服务端定；
- 问数据页（store/chat.ts）照 error.next 走：retry 就带着原因重来一次（同 retry_instruction 的从零重建措辞，次数照
MAX_ATTEMPTS），试满了才照实报；进度写「助手上一次没有给出任何操作，正在重新生成工作流…」（lib/terms 的 CHAT_RETRY_TEXT）；
第一次建图的用量照样记进这一轮；
- 评测（eval/answer.Driver.drive）用同一个 next_step / error_reason / retry_instruction：先重来一次，还不行才记建图失败、
助手调用失败；每次自动重来的原因照实记在 turn.retries（没过检查、复核判不可用的重来也记），评测页逐题明细写出来。
测试：test_chat_turn_policy.py 的 test_next_step_branches（error 的两支和 error_reason）、
test_the_frontend_retries_an_error_the_server_says_to_retry、test_answer_ops_says_to_retry_an_empty_generation、
test_the_eval_driver_retries_an_empty_generation_once（重来后回答 / 重来还不行，两次的用量都算）；
test_copilot_answer_ops.py 的 SSE 对照多认 error 上新加的 next、reason、code。去掉修复回跑都失败。
浏览器：check-chat 新加 emptyretry 一节（重来一次后照常回答、交回去的话带原因、两次用量都记；两次都不行照实报、不试第三次），
check-chat 840 项全过。
2026-10-17 11:51:34 +08:00
d9eaf8b850
撤销分享链接交回的 page_title 是页面标题，和建、列的一样
...
验收：DELETE /api/apps/{app_id}/shares/{share_id} 的返回里 page_title 是页面 id（"home"），建分享时返回的是页面标题。
revoke_share 调 share_out(row) 时没给标题表，share_out 就退回页面 id。
改法：撤销照列表的取法（应用当前的版本 _previous 的 spec）给 share_out 标题表；撤销过的再撤销也一样。
测试：test_shares 的撤销用例加断言：建出来的 page_title 是「首页」，撤销、再撤销交回的都是「首页」。去掉修复回跑挂。
2026-10-17 09:19:24 +08:00
eb6abffc61
评测逐题结果给出这一题实际问的问题，模板原文另放 question_template
...
验收：评测结果列表里 question 是原始模板（带 {{ schedule.last_week_start }}），作答运行实际收到的问题已经渲染好了。
results 接口直接取的是 EvalCase.question。
改法：api/evals 的 _asked_questions 按执行时同一个算法、同一组输入渲染：题目模板 + 这次评测的截至时间（as_of，
建评测时就定下、重试不变）+ 题集时区 + 定时的 cron（runner._unit 交给 Driver 的就是这个）。题目在这次评测之后
改过（结果记的 case_hash 对不上现在的）时，现在的模板不一定是当时问的：改取作答运行输入里的 question，也没有
（反问、建图失败没有运行）就给 null，不拿现在的模板编一个。模板原文放 question_template。没有加库表的列：
渲染是确定的，不用另存。
前端：评测页逐题表的问法一格写实际问的问题；模板原文和它不同时（带变量，或题目改过）另起一行「题目原文：…」，
文案进 termsEval。类型补上 question_template。
测试：test_eval_runner 新增一条：带变量的题，结果的 question 和作答时 Driver 收到的一字不差、不含 {{，模板原文在
question_template；没有变量的题两者一样；题目改过、没有作答运行可取时 question 为 null、模板照给。去掉修复回跑挂。
check-evals 的夹具给带变量的那一题配上渲染好的 question 和模板原文，核对逐题表写的是实际问的、原文另起一行，
没有变量的题不多这一行。tsc、check-copy 通过，check-evals 102 项全过（漏到服务端的那个偶发问题另一次提交里修）。
2026-10-17 09:02:57 +08:00
f5c9f0c13c
剖析任务接口收取值观察范围，对话框给出「取值观察」；定时维护挑不出要观察的表时把原因记进触发记录
...
验收：取值观察只能经定时维护触发——POST /catalog/profile-jobs 的 scope 只收 needed、all，可剖析任务本来就支持
observe（只观察、不剖析）。另外 12 小时内观察过的表不再观察时，任务以 0 张表结束，原因只在剖析任务的 notice
里，从定时维护触发时触发记录（ScheduleFire.inputs）看不出来。
后端：
- ProfileJobIn.scope 加 observe（maintenance 是定时维护用的，接口照旧不收）。挑不出表时照旧 409 profile_nothing，
说法是 NOTHING_TO_OBSERVE（「最近 12 小时内都观察过了」）。
- catalog_profile_jobs.nothing_reason：按此刻的表结构和目录一张表都挑不出来时交回 ProfileNothing 的原话；排在
起草后面时说不准，返回 None。
- source_maintenance._start：建出 0 张表的剖析任务、这次触发又没有探查（开始时表结构不会变）、也没排在起草后面
（目录不会变）时，判断得出任务会以 0 张表结束，把原因记进 inputs.skipped（同一套 NOT_RUN 说法进 reason）。
任务照建、触发照旧是 started：每小时一次的维护不至于一天二十几次「没能发起」。同一次触发里有探查、或者排在
起草后面时判断不了，保持现状，写进了模块说明。
前端：剖析对话框的范围里加「取值观察：有数据目录的 N 张表」（说法照维护设置里「取值观察」那一步：码值分布、
最新业务日期、按日行数和行数，和同口径的历史比出取值变化；最近 12 小时内观察过的这次不再观察），建任务带
scope: observe。张数按清单上有数据目录、不是视图的表算（isObservable，profile.ts），观察到期没有由服务端判，
所以是上限。挑不出表时说「没有要观察的表」和服务端原话，不给「改选全部表」（那是剖析，不是观察）。文案进
PROFILE_TEXT。
测试：test_catalog_observe 新增一条（接口建 observe 任务、只做观察检查，再建一次 409 profile_nothing，maintenance
422）；test_source_maintenance 新增一条（只选取值观察，12 小时内再触发：任务 0 张表，inputs.skipped 和 reason 写明
原因）。去掉修复回跑两条都挂。check-catalog-profile 跟上：范围多一项 observe:1，说法核对；新一节建取值观察任务
（请求体 {scope: observe}）、都观察过时的「没有要观察的表」且没有「改选全部表」。tsc、check-copy 通过，
check-catalog-profile 204 项全过。
2026-10-17 08:51:51 +08:00
3f75cb1d2e
恢复被驳回的运行：照 end_reason 说「被驳回」，和继续运行同一个错误码 run_rejected
...
验收：对被驳回的运行调 POST /api/runs/{id}/resume，回的是「这次运行已取消，没有待处理的审批，无法恢复。已取消的
运行请重新发起」，/continue 却是对的（run_rejected）。resume 只看 status，cancelled 一律说「已取消」；存量的
failed + 驳回还会被说成「失败的运行可点继续运行」，而继续运行其实会被拒。
改法：runner 加 _resume_refused：cancelled + end_reason=rejected、以及加 end_reason 之前记成 failed 的驳回
（_rejected_before，同 continue_failed 的判断）抛 ContinueRefused(REJECTED_RESUME, code=RUN_REJECTED)，别的照
_cannot_resume。resume 开头的状态检查、等审批凑齐时发现运行已经不在 interrupted 两处都用它。/resume 接口像
/continue 一样把带机器码的拒绝回成 CodedHTTPException(409, …, code)。ContinueRefused 是 ValueError 的子类，
别的调用方（待办服务）照旧按 ValueError 接。
测试：test_run_rejected 新增一条：驳回的运行 /resume 回 409 + run_rejected、说「被驳回」；手动停止的照旧说
已取消、不带这个码；存量 failed + 驳回也回 run_rejected，不再叫人点「继续运行」。去掉修复回跑挂。
2026-10-17 08:31:17 +08:00
c64c7a1062
目录接口对探查范围外的表照实说「在探查范围外」，不再说「可能已被删除或尚未探查结构」
...
验收：GET /api/datasources/{id}/catalog/{表} 对「对象索引里有、但在探查范围外」的表回 404「数据源中没有表 …，可能
已被删除或尚未探查结构」，而 /schema 和 /catalog/search 都说对了。_table_key 一律写死这一句，没看 absent_reasons。
改法：source_objects 加 ABSENT_MESSAGE 和 absent_message()，给人看的五种「不在」（表已不在、全库对象清单里也没有、
在探查范围外、在范围里却读不到结构、老缓存说不清）一句一句，和界面的 CATALOG_ABSENT_TEXT、/schema 用的
schema_view.absent_detail 同一套原因。上传表格、记录表按版本走，没有对象索引又没截断过的老缓存认不出名字是不是
从来就没有过：这两种只说「数据源中没有表 …」，不说「已删除」。用到的三处都换成它：_table_key（表详情、审阅、
使用记录等十来个接口共用）、表助手开始前的 404、批量审阅逐条的 table_missing 错误。
测试：test_catalog_schema_truncated 新增一条（205 张表、规则只收 200 张的合成库）：范围外的表在表详情、表助手、
批量审阅里都说「探查范围外」，对象索引里也没有的说「没有表 …」。去掉修复回跑挂。
2026-10-17 08:28:54 +08:00
d4e68bd1a9
合入 W4-d 目录前端：数据目录的「变化」视图与处理动作、数据源角标、表详情「结构与取值变化」一节、数据源的定时维护（一条目标为数据源的定时任务）、后台任务条（探查、起草、剖析按服务端排队顺序）；打开 source.changed 订阅；指名数据源卡片统一用 #source-<id>
2026-10-16 22:30:09 +08:00
d17a08bafb
合入 W4-c 账本前端：证据「口径」一步与数字上的小标记、问数据轮次摘要与按口径出具 / 对账、对账视图与反馈、可沉淀的问题、设置里的口径账本一组、比对结果按退避轮询；被驳回的那一步 node.failed 带 reason=rejected，画布、航迹、时间线、问数据过程都画「被驳回」
2026-10-16 22:29:02 +08:00
13bd021219
合入 W4-b 评测前端：顶级导航「评测」（搭建者以上、⌥0）、题集与四种加题、发起评测与预估花费、评测详情与逐题结果、对比与 A/B、口径命中与重复度、目录快照；定时页选目标种类、认得数据源维护的触发记录；记录页的评测来源；设置里的评测一组；问数据建图用量不再是下限（读完模型的流再关）；问题聚类的向量只取一次
2026-10-16 22:28:35 +08:00
b3dcddb52e
召回复核修正（后端）：人工节点不再挡召回、读不出召回卡记失败、旧版不再接着算、团队渠道一次召回只推一条、目录核对按数据源合并排队；账本接口带上召回标记，对账结果可以反馈
...
- W4R-01：召回只查新版图里会不会写外部系统（apps/backfill 抽出 graph_external_write，graph_side_effect 复用它）。召回图只有两版
的取数和口径卡，图里别处的人工节点、按流程使用的问题碰不到它；口径卡上游的人工节点 derive 本来就认作数据部分不能复用。
「按新版重新出具」走完整的正式运行，仍按 graph_side_effect 全套拒绝。原来带审批的口径升版后一组都不召回，L6 对它们失效。
- W4R-09：收尾时召回卡读不出、或缺了某个比较的旧值 / 新值，照实记重算失败（读不出召回卡），原答案一个不动。原来两边都是空，
按渲染比被当成「没变」，给每个原答案永久盖上「已核对，不影响」，收过尾之后再也不核对。
- W4R-12：这一版已经不是当前发布版（之后又发布了更新的版本）时不再发起召回、不给接着算，批次里写 continue_reason，接着算的
接口 409 带同一句。同启动时接着做只认当前发布版：新版本的召回覆盖更早的所有版本，再按旧版开「口径升到 vN」的待办只是添乱。
- W4R-13：开登录时一组答案几个主人就几条待办，全局渠道却按这一批（recall.batch_of_key：同一次召回、同一个来由）只在最早开的
那条上推一次，答案、待办按这一批汇总，几条的链到待办箱；别的几条连 task.opened 也不再推全局渠道。个人渠道照旧每人一条。
- W4R-11：目录审阅之后的核对按数据源排队、批量审阅的几张表合成一遍（catalog_pass，同一数据源一把锁）；查询快照按数据源在库里
筛、按运行结束时间分页、每张表凑够 BASIS_MAX_RUNS 次运行就停；冻结的表结构快照这一遍里按工件 id 只读一次。原来批量审阅
几十张表就同时起几十个后台任务，每个都全表扫查询快照、反复读同一份几 MB 的表结构快照。
- W4R-03（本包那一半）：GET /api/runs/{id}/ledger 加 recall：checked（已按 vN 核对，不影响）、basis（依据有变：哪一种、几项、
新出现几条错误级问题）、tasks（看的这个人手上说的是这个答案、还没处理的 recall 待办）。不放数、不放表名。几种状态都带。
- W4R-10（本包那一半）：新事件 ledger.feedback（对账运行上的封存后事件），POST /api/ledger/answers/{run}/reconcile/{rid}/feedback
{verdict: useful | unclear} 记反馈，同一个人改主意只算最后一次（app/ledger/feedback.py）；账本接口的 reconciled 每一项带
feedback {mine, useful, unclear}；统计 E2 的 feedback 数到它，去掉「第 4 波接上」的占位说法。离线核对页、封存后事件摘要
都认得这个事件。
测试：test_ledger_recall 新增七个用例、改了人工节点那一个（召回照算、重新出具照实拒绝）；新增 test_ledger_feedback；
test_ledger_api 的 E2 断言跟上。每个修复都先写失败的测试、去掉修复回跑确认抓得住。后端全量 14237 通过。
2026-10-16 22:16:58 +08:00
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
d0082b4645
问题聚类的向量只取一次：评测页「口径命中与重复度」不再按窗口把问题重发给向量模型（复核 W4R-14）
...
为什么：这个页签一次打开，/api/evals/signals 按窗口调 compute_stats（缺省 6 个窗口，每个都聚一次问题），页面另调
/api/ledger/stats，一共聚 8 遍；chat/questions.cluster_questions 每遍都把窗口里的问题原文整批发给 embed_texts，
一次里重复的问法也照发。配了远程向量模型时每打开一次就是几百到几千次向量调用，慢、花钱。复现：本地 3 句问题各问 3 次，
一次打开每句被取了 9 次向量。
做法（改在全站唯一的取问题、聚类处 app/chat/questions.py，不动 ledger/stats 的统计口径）：
- 问题原文 → 向量在进程里留一份（_vectors，最多 VECTOR_CACHE_MAX=1000 句、最近用到的留着），同一句话只取一次，
一次里重复的问法去重后只发一句；/signals、/ledger/stats、认证队列、治理页的探索问题聚类都走它；
- 缓存认「哪一个 embedder、哪一个取向量的函数」算的：设置页换了向量模型（configure 换了对象）整份丢掉，不把两个
向量空间的坐标混着比；取的这一会儿换了的，这一批照用、不留；
- 取向量按事件循环串行（每个循环一把锁，同项目里别处的写法）：页面并行取的两个接口不把同一批问题各发一遍。
测试：test_evals_ui_api 新增「一次打开每句问题只取一次向量、再打开一次都不取、两个接口并行也一样」；
新文件 tests/test_question_vectors.py（去重、换模型丢缓存、取到一半换模型、上限与最近使用、并行只发一批）。
去掉缓存回跑：每句 9 次；去掉换模型的核对：2 条失败；去掉共用的锁：并行那条失败。
2026-10-16 21:41:30 +08:00
ThearchyHelios