343 Commits

Author	SHA1	Message	Date
ThearchyHelios	9d8b41430e	完善口径管理、主动调查与后台任务，修复通用问题 ... - 完善口径编辑、只读试运行、统一质量验证与执行语义指纹 - 增加可执行指标约束、有预算的主动调查和过程评测 - 提取发布检查、证据读取与起草服务，支持任务停止、重试和检查点恢复 - 增加版本传递影响分析，修复并发覆盖、敏感值遮罩、异常评分及页面状态问题 - 修复 SQLite 复合查询追溯和 microVM 可选依赖缺失处理 - 纳入当前设计文档及部署配置调整 验证：相关主回归 3822 项通过，4 项跳过、8 项预期失败；补充回归通过。 前端构建、文案检查及 git diff --check 通过。 全量检查仍有环境权限、PostgreSQL 可选依赖和既有部署配置、SQLite 文件基线差异导致的未通过项。	2026-11-06 17:14:45 +08:00
ThearchyHelios	5f0b2359ac	入口只留每次都会变的东西，固定条件写死在 SQL 里 ... 实测同一份文档：入口从 7 个（start/end/factory_code/object_id/line_code/gc_code/scx_code） 降到 2 个（start/end）。 提示词加了四条：同一维度只做一个入口（factory_code 和 gc_code 是同一件事）、编码和主键不当 必填入口、跨表编码在 SQL 里 JOIN 映射、可选维度写成空值不过滤；入口上限 4 个，超了照实报 出来但不悄悄删（删了 SQL 还引用着）。起草页多一栏「固定条件」：工厂、产线、属性组填这里， 写死在 SQL 里，不变成每次都要填的参数。	2026-11-04 14:47:23 +08:00
ThearchyHelios	1048905095	必填入口没有值时停在 needs_input，不再把试运行判成失败 ... 草稿图建出来后，start/end 这类必填入口往往没有缺省值，系统不会替你编日期去跑。现在记成 needs_input：入口字段做成可填表单（日期预填七天前/今天，可改），点「试运行」按这些值跑 一次；缺值仍回 422，不会发请求。试运行只跑取数与口径卡，参数按发布同一套规则校验。	2026-11-04 13:35:21 +08:00
ThearchyHelios	62c8702478	跨轮重复的未决问题只留一条 ... 十轮起草每轮都会重新问一遍同一件事，68 条问题里有一半是重复。按第一个分句去重：问的是 同一件事就只留先出现的那一句，措辞不同的仍然留下，交给人判断。	2026-11-04 09:56:42 +08:00
ThearchyHelios	97cd9498a4	入口字段声明不一致时合并，不把整份草稿判死 ... 同一份文档分十轮起草，各轮对 factory_code 的必填/类型声明常对不上。原先直接抛错，34 条 指标的草稿因为一个字段的 required 不同整份作废。现在必填取并集、类型取更宽，每一处不一致 记一条说明摆在入口字段下面；建图和界面共用同一套合并逻辑。	2026-11-04 09:54:16 +08:00
ThearchyHelios	939f0f3448	起草上限放到 10 轮 60 条 ... 实测同文档 6 轮只覆盖 22 条（每轮 3–5 条），剩 23 条撞在轮数上限上。按实测节奏放到 10 轮。	2026-11-04 09:28:54 +08:00
ThearchyHelios	ec8ee6c92a	起草自动续跑：多轮覆盖 uncovered，最多 6 轮 40 条 ... 每轮收一组指标、写一次进度（第几轮、覆盖几条、还剩几条），直到没有新指标、uncovered 空了或到上限。中途每轮落库，页面能看到「第 2 轮 · 已覆盖 12 条 · 还有 27 条」，不再是 一个转圈的空白。	2026-11-04 09:24:37 +08:00
ThearchyHelios	8b2f01d15d	目录按文档点到的表优先展开；模型提问不再算起草失败 ... 这个数据源的目录渲染出来十万字符，被截到两万四，kpi_info 的 attribute01…54 全在被砍掉的 后半段，模型看不到列就只能如实列问题——界面却把它记成「起草失败」。 现在文本按「概览 → 全量表索引 → 全量列名 → 文档点到的表展开」排，预算不够先丢最后一段， 列名一个不少。模型一条指标都没写、但把缺什么说清楚时，草稿落在 questions_open，问题原样 留下来，不再报失败。	2026-11-04 08:54:42 +08:00
ThearchyHelios	8682deb447	起草按「能共用一条 SQL 的一组」进行，并抢救被截断的回复 ... 实测：一条 SQL 枚举十几列 CASE WHEN 就把输出额度吃光，文档里十几条指标一条都写不出来， 界面只报「没有一条指标通过校验」。现在提示模型一次只起草同组指标（最多 6 条）、SQL 写短， 其余的进 uncovered；回复被截断时按完整片段抢救指标和 SQL，失败原因里写清模型实际交回了 什么形状，不再只说没有指标。	2026-11-04 08:37:52 +08:00
ThearchyHelios	13f1158191	口径起草一次到位：生成取数图并自动试运行，不再要求人工接一次运行 ... 「不从指标定义编译 SQL」管的是事后比对的基准，不是起草。起草照样让模型写 SQL，但只允许 目录里的表和列、单条只读 SELECT、入口字段必须先声明；每条定义仍要能逐字对上原文。 起草成功即建工作流与 v1；试运行只跑取数与口径卡（derive.caliber_probe），不触发报告撰写， 也不会因为没有可用模型就判这份口径不行。接上一次运行保留为辅助入口。	2026-11-04 00:30:26 +08:00
ThearchyHelios	43a38e926c	起草失败单独记一种状态，别再停在「起草中」 ... 没有可用模型、模型回复读不懂时，草稿此前一直留在 drafting，界面会以为还在跑。现在置 failed 并把原因写进 error；补上真指标后 PATCH 仍能把它推回正常流程。	2026-11-03 23:07:01 +08:00
ThearchyHelios	7f66985dba	口径草稿：从业务文档抽定义，再从一次真实运行接上取数路径 ... 新增 caliber_drafts 表与 /api/ledger/drafts 一组接口：抽取在后台跑，文档缺失整单拒绝， 有未决问题时停在 questions_open，问题清完才到 path_pending。 接上运行沿用从运行固化的建图逻辑，定义按同名或同义词并入指标卡，expression 与 id 不动； 文档引用记进 origin.documents，复核能落回具体段落。接入只产出可试跑的草稿，不发布、不发起运行。	2026-11-03 22:50:14 +08:00
ThearchyHelios	753c35918d	复盘修正：试运行不计入统计、评估标签遮罩、规则/评估卡可组合	2026-11-03 21:23:08 +08:00
ThearchyHelios	e1d63e7389	规则 DSL 编译成只读 SQL，并用 fixture 验证	2026-11-03 20:50:06 +08:00
ThearchyHelios	68af29a180	增加口径目录页与试跑：入口表单、依赖说明和只读试跑	2026-11-03 19:43:39 +08:00
ThearchyHelios	aeaca4ce69	记录口径调用审计：compose 与正式出具各记一条参数指纹	2026-11-03 19:38:00 +08:00
ThearchyHelios	5eb1c8ff00	增加口径可调用 descriptor：入口 Schema、依赖与出具策略	2026-11-03 19:34:28 +08:00
ThearchyHelios	174375c6c7	新设遮罩列时清理目录里的码值、含义与备注	2026-11-03 18:53:39 +08:00
ThearchyHelios	7b47ce1724	合入第 2 波复核修复 S1：分析结论的占比、变化率、比率之差按百分数 / 百分点显示——结果表带每列的显示格式、具名的数带格式，证据渲染、整表、写作目录、证据面板、导出、可验证报告都按它；显示规则 4 版，老文档按记下的版本复核；空格写「—」 ... # Conflicts: # backend/tests/test_analysis_pages.py	2026-10-21 16:23:39 +00:00
ThearchyHelios	709a50208a	合入第 2 波复核修复 S2、S5、S6：关分析工具那一臂挡分析卡与用了分析的子工作流、节点手册里不再出现分析；问题意图词表与自查那句进评测的提示词指纹；问题意图不把问构成当来源、不把问数据质量当异常	2026-10-21 16:22:21 +00:00
ThearchyHelios	eade5aab5d	关分析工具那一臂挡分析卡：图里有分析卡、嵌套的子工作流里有分析卡或分析工具都挡回去改；关掉时节点手册里不再出现分析卡、分析工具和分析相关的配置（改写与整段去掉）；问题意图词表版本与自查交回的那句进评测的提示词指纹；问题意图不把「哪个贡献最多」当来源、不把「数据是否正常」当异常；评测「关」那一臂的替身改成照样试着加分析卡、靠真代码挡	2026-10-21 16:19:49 +00:00
ThearchyHelios	31ed7a96f3	证据面板的计算一步照服务端写好的字显示：具名的数按结论记的格式（占比 61.9%，不再写 0.618556701031）、结果表的格同样（变化率 -14.6%），空格写「—」不写 null；列类型照结果表的 column_types。比率拆解的整体比率那一格和对照的那一格也按格式写（3.5%，不是 0.035）。前端照原样显示（只补一句说明）	2026-10-21 15:55:20 +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	03cedbaf1d	合入 W2-c 前端：分析卡节点与分析项编辑器、报告节点两个新字段、设置「分析」一节、问数据时间线的分析步骤与出具横幅三项、运行对比的分析卡一区、证据面板与正文接上分析结论（六步出处链、闭合核对、两期可比性、说法违规标注、分析范围）、可验证报告核对页与分析样本页、口径账本摘要防 NaN；服务端补分析工具事件里的判定与分析结论的单独出处接口 ... # Conflicts: # backend/tests/test_eval_schedule.py	2026-10-21 19:34:24 +08:00
ThearchyHelios	8a6ad0e7a2	评测变体加「分析工具」开 / 关（缺省开）和「分析工具贡献」预设对照：eval/variants 的变体多一项 analysis {tools: on | off}，只认这两个值、缺省开，不合规的照实拒（eval_variant_invalid，落到 variant.analysis）；analysis_tools(变体) 读开关，加这一项之前存下的变体按开。eval/answer.TurnContext 加 analysis_tools，Driver 透传给 chat/drive.TurnDriver（再到 api/copilot.answer_ops）：关的那一臂建图时工具清单不列分析工具、节点手册不讲分析卡；工作流题不建图，不受影响。同一变体（variant_key）认分析工具：开着时不写进去，和加这一项之前算出来的一样，以前的评测照样当基准、趋势线不断；关着时不同。指纹记 analysis_tools，对比的指纹差异写「分析工具：开 → 关」（老指纹里没有这一项的按开）；变体那一句写「分析工具开 / 关」，结果页、A/B、估算照它显示。api/evals 的预设对照加 analysis_tools（variants.analysis_tools_preset：开、关两臂，名字「分析工具开」「分析工具关」，别的项照 variant 或题集的缺省）。测试：变体规范化、拒收、同一变体指纹、变体那一句、预设两臂和 Driver 拿到的开关、估算与 A/B 拒收（test_eval_runner）；指纹差异的开、关和老指纹（test_eval_compare）；真运行的「分析工具贡献」对照（test_eval_analysis_runs：关的那一臂助手看到的 system 里没有分析工具和分析卡、作答运行里没有分析结论、算错，开的那一臂对且可追溯，两臂共用期望、指纹和同一变体都不同）	2026-10-21 19:32:38 +08:00
ThearchyHelios	5a02d17bf2	助手建图加「关掉分析工具」的开关，给评测的「分析工具开、关」对照用：api/copilot.answer_ops 加关键字参数 analysis_tools（缺省真，和以前一字不差）。为假时给助手的工具清单不列五个分析工具（_tool_catalog），节点手册去掉只讲分析能力的三段（agent 段里分析类问题绑分析工具那一条、分析卡一整条、搭图规则第 7 条；报告段的引用写法和分析说法核对照留，node_reference），问数据的包装不给分析类问题那一条形状（ANALYSIS_SHAPE_PROMPT 抽成常量），问题意图那条自查不提；图里照样绑了分析工具的（Agent、协作成员、调用工具节点）按「绑定的工具不存在」挡（analysis_tools_off，交回模型去掉，改不好就不运行）。chat/drive.TurnDriver 加同名参数和属性 analysis_tools（缺省真），_generate 透传给 answer_ops；问数据页不暴露，eval/answer.Driver 之后按变体设。测试：关着时工具清单、手册、包装都没有分析，绑了被挡、改掉就运行；开着时绑了照常运行；没碰分析工具的一轮开、关交出的操作逐条一样；TurnDriver 透传	2026-10-21 18:47:10 +08:00
ThearchyHelios	8a81fa767e	助手建图认分析能力：节点手册加分析卡一段（用途是模板里固定要做的分析，items / overrides，输入只认调用数据库查询工具的调用工具节点和合并查询，产出 nodes.<id>.results.<项> 可按判定分支，结果不进口径卡）、agent 段补五个分析工具（分析类问题绑，绑了平台注入分析方法，只绑给查库的 agent）、报告段补分析结论的引用写法（a:An、a:An.键、v:An.r0.列、table:An、句末 see:An）和分析说法核对（check 缺省、strict、off，只能往严里改）、分析范围，受管指引和发布前修复的硬性约定写明分析说法核对要严格；搭图规则加一条。问数据的包装加「分析类问题」的形状（input → agent 绑查询、表结构和分析工具 → report 按分析结论写、引用判定语 → output）。报告的证据来源认分析卡。自查：GenerateIn 加 question（问数据的一轮把原问题带上，重来时 instruction 是带着原因的那段话），问题是分析类、查库的 Agent 没绑分析工具、图里也没有分析卡时提一条问题（analysis_tools_missing，带 for_model），照 coverage 只交回模型改一轮，改过一轮仍在的不挡运行、收尾时留作提醒。测试：手册里的引用写法交给真解析器、分析卡与工具的叫法取契约、包装的分析形状、自查只挡一轮与几种不提的情形、重来按原问题判	2026-10-21 18:08:37 +08:00
ThearchyHelios	998ab23bae	报告末尾「分析范围」里的编号点得开：证据接口加 GET /runs/{id}/evidence/analyses/{alias}（?report= 同片段接口），交回那份分析结论的出处链（判定 → 方法 → 计算 → 输入 → 复算 → 封存，和点开正文里它的判定语同一条，按导出页已有的 _scope_chain），正文没引用的结论（算不了的、可比性检查）也点得开；只认这份报告证据目录里的分析结论，没有的 404（evidence_analysis_not_found）。选报告、文档完好与否的几种错误挪进 _open_report，片段接口和它共用同一套错误码。测试：同一条链、算不了的照实给原因、目录里没有的和不是分析结论的 404、文档被改过 409	2026-10-21 18:02:34 +08:00
ThearchyHelios	41ad3a1c05	合入复核修复（证据接入与入口）：跨段指标不当两期查、证据接口重渲染与组装同一个函数、一次请求同一份结论只复算一次、比率闭合核对、代入式按点名的段、写作目录分析段限额、核对页写方法叫法、运行对比只认做完的执行、读快照进线程、四个工具与合并查询的真算子测试、夹具清源	2026-10-21 16:58:45 +08:00
ThearchyHelios	472f78344d	分析设置要求「集中」的合计占比不小于「主要来源」的占比（复核 R16）：contract.settings_problem 加一条（没写的项按缺省补齐了比），说法用 LABELS 的叫法：「「集中」的合计占比不能小于「主要来源」的占比」——原来「主要来源」0.9 配「集中」0.5 能通过，一段占 60% 时判分散、判定语却说「没有哪一段占到 90%」。设置页写进来的、分析卡上的覆盖都按它挡；api/settings.analysis_values 读存着的一组时这一对对不上同样两项都按缺省（同另外两对）	2026-10-21 16:00:29 +08:00
ThearchyHelios	40918a7fb1	可疑实体找「最接近的名字」时重建的目录（_scope_catalog）不收分析结论：候选只看表和字段，用不到结论的内容，以前每点开一个可疑的名字都把这次运行的分析结论读盘、复验一遍哈希（build_catalog 给 A 条目装整份结论）。查询、表和字段的编号不受影响。测试：台账里有分析结论时重建目录不读任何工件，按报告节点和退回不分范围两条路都是	2026-10-21 15:39:43 +08:00
ThearchyHelios	496dc27419	比率拆解的总数闭合核对：证据面板的输入一步按拆解的模式认 headline 对着哪个数（_HEADLINE_TOTALS 分可加、比率两套：可加对各段之和 base_total / target_total，比率对整体比率即各段分子之和 ÷ 分母之和 r_base_total / r_target_total），closure 带上 mode；比率拆解的两格角色写「基期整体比率」「本期整体比率」。以前只认 base_total / target_total，比率的 headline 在证据面板不显示闭合核对。导出页（report_export/runtime.js）比率的写「整体比率 x 与各段分子之和 ÷ 分母之和 y 闭合 / 对不上」、那一格叫「整体比率那一格」，可加的照旧。测试：可加拆解的 closure 带 mode、角色叫法不变，比率拆解两格各自闭合、复算一致	2026-10-21 15:37:20 +08:00
ThearchyHelios	b6efee81fd	一次请求里同一份分析结论只复算一次：_Sealed 加 rechecks（结论工件 id → 复算的结论，只活在这一次请求里），_analysis_recheck 按工件先查它。导出页里同一份结论被判定语、具名的数、整表展开的每一格、分析范围的编号各引一处，引用键不同、各接一条链，以前每条链各复算一次（1000 段的拆解导出一次复算 33 次、1.66 s，现在 1 次、0.2 s）。分析范围的编号先查导出的 memo：正文已经引了判定语的（同一个引用键）不再建一遍链（_scope_chains 换成按编号建的 _scope_chain，引用键 _scope_cite_key）。测试：判定语、具名的数、整表 12 格、依据、分析范围一起导出只复算一次，各链的复算一步照样是复算一致；下一次请求重新复算	2026-10-21 15:34:37 +08:00
ThearchyHelios	8a62826034	证据接口重新渲染分析结论的引用改用组装、出口复核同一个函数：_analysis_rendered 按封存的结论走 evidence.resolve_ref（resolve_ref 加 display，按文档记下的单元格显示规则），结果表的格照结果表记的列类型、显示规则、标识列渲染，和组装时的 _resolve_cell 一致。以前不看列类型和显示规则，文本码值「1203」重渲染成「1,203」、ISO 日期时间带着 T，render_ok 为假，证据面板和导出页报假的「与按结论渲染的结果不一致」。片段上没记引用的（口径卡指标上的可比性、分析范围的编号）照旧按判定语渲染。测试：门店码、时段两种格在片段接口和导出页数据块里都 render_ok	2026-10-21 15:32:21 +08:00
ThearchyHelios	d307d087bc	审计单列一行的分析说法违规码改为引用 engine/analysis_claims.CODES，去掉 api/evidence 里另写的一份字面量	2026-10-21 14:47:19 +08:00
ThearchyHelios	5f96a23452	分析次数上限照实按每个 Agent 每次执行说：设置叫法「Agent 每次执行最多分析几次」，次数用完的调用错误「这个 Agent 这次执行最多做 N 次分析，已经用完」（入口按本节点这次执行的分析容器数次数，本来就是这样算的）	2026-10-21 14:08:56 +08:00
ThearchyHelios	4afe8e6f4f	合入 W1-c 入口：五个分析工具与方法注入、分析卡、口径卡可比性、运行对比按项对齐、设置与快照、使用者白名单	2026-10-21 13:59:06 +08:00
ThearchyHelios	cb2fdd860f	证据接入按 W1-a、W1-c 的实际接口对齐：复算就是真的 app.analysis.recompute——load 交查询快照工件的原内容、load_result 交上一层结论（只认封存范围内交回过的查询、台账记过的结论，取不回照实说取不回哪一份），方法升没升版按结论里的 method 和现在的 contract.METHODS 比（升了版、复算成立的写结果同不同，现在的方法复算不了的写明原因），去掉为算子没落地准备的那一套；关键数的代入式按真的具名的数写（乘积拆解补上，波动基线按变化率比的按百分比写，负数加括号）。口径卡指标上的可比性结论（不进台账、只从卡上引用）点得开：证据面板的指标步骤带它整条出处链（判定 → 方法 → 计算 → 输入 → 复算 → 封存，封存按卡上记的 sha256 认），报告导出收在一个可展开的块里，可验证报告随附带的卡一起附上、④ 按已核对的卡认它、数字详情里展示各项检查和服务端复算；裁判的指标摘录、写作目录照卡上记的判定语写。现查结果分清按运行当天现算的界、一列一个值都没有、表的范围；可验证报告里分析工具的 tool.end、分析卡的 analysis.end 和结论同一个认法才带内容，输入的角色写叫法。测试改用真算的结论（run 交的输入照分析入口的写法，复算交工件原内容），下钻、总数闭合、方法升版、可比性端到端都过真的复算	2026-10-21 13:49:09 +08:00
ThearchyHelios	7474fa5030	证据接口认分析结论：封存范围按台账记下分析结论；证据图的 A 条目带算子、判定、谁做的，连「派生自」的边到它的输入（Q…）和下钻的上一层（A…）；片段接口的出处链为判定 → 方法 → 计算 → 输入（每份输入落到哪个 Q、用了哪些列和行、headline 闭合、下钻的上一层，接输入快照的查询步骤并照常遮罩）→ 复算（按 sha256 取回封存的输入、在线程里复算并逐字段比，算子没落地、出意外照实写复算失败，不让接口出错）→ 封存，结论哈希不符的只给判定和封存两步并写明原因；Agent 写的假设标成 Agent 写的假设；片段说明分判定语、具名的数、结果表的格三种。指标步骤展示口径卡记的两期可比性（点得开那份可比性结论）。审计：分析判定、分析结论的叫法，结果表的格按台账认封存，分析说法核对的三种违规单列一行，违规码补上判断词未挂分析结论、判断与分析结论不符、因果说法没有依据，以及原来就缺的依据写在句子中间、缺失断言。报告导出：判定语片段按引用键共用出处链，分析范围里的编号接同一条链。裁判的 loader 把分析结论的输入快照也逐份遮好	2026-10-21 13:07:55 +08:00
ThearchyHelios	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
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	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
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	8ce578042c	合入：工作流可以改名（画布顶栏、工作流列表各一个入口；服务端拦空名、超长、重名，内置模板不改名）	2026-10-20 08:19:32 +08:00
ThearchyHelios	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
ThearchyHelios	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
ThearchyHelios	fa951a2756	切到账号密码登录时，已经有能用密码登录的管理员就不再要求建第一个管理员：以前设置页只要从「未开启」切到账号密码登录就一律显示「第一个管理员」表单、一律提交 bootstrap（前端 needsBoot 只看切换方向），库里已经有设了密码的管理员也得再建一个。/api/auth/settings 现在带 local_admins（没停用、能用密码登录的管理员）和 passwordless_admins（没停用、还没设密码的）；设置页按它判断：有能登录的就提示「切换后用其中一个账号登录，保存后会回到登录页」、不提交 bootstrap；只有没设密码的管理员时照旧要建，并说清是谁没设密码、可以在用户列表里给他重设密码。从单点登录切到账号密码登录同样按这条判（以前不显示表单、后端却要求）。用户列表里新建用户、重设密码后，登录方式那一块重新判断。判据和后端 _local_admin_exists 同一个	2026-10-19 18:48:22 +08:00
ThearchyHelios	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