648 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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	a9ffbcfa86	数据目录闭环（前端）：类型、接口、文案和纯函数——起草任务的逐段落盘、块进度字段和清单的 blank_columns_from；审阅队列、成批审阅、审阅进度、用过这张表的运行；导出导入（下载文件、预览、导入）；表助手的事件流（按行读 data: <JSON>，开流前被拒带状态码和机读码，能停止）；表助手的对话怎么截（最多 40 条、每条 4000 字、从用户的话开始）、待保存的修改怎么累积（同一路径以最后一次提案为准、保存带最早那条提案的版本、409 后按预览重算）；审阅视图的地址参数、成批结果和表详情改过之后的状态同步；文案进 lib/terms.ts	2026-10-14 08:44:14 +08:00
ThearchyHelios	a87b935ebf	合入数据目录起草改造：用模型起草改成后台任务，逐表记状态和原因，写完一张就并入目录，可以停止、只重试失败的表，服务重启时没跑完的标中断、不自动续跑；保留模型思考，输出额度 32768（服务方不收时退回 8192）；列分段均分、宽表先起草表级再分段起草列，额度用完或超时就拆小再问、段大小随之减半、每段调用次数封顶，接连没写出来时给提醒；重新起草不丢已有的模型起草项；模型拿不准而留空的列逐表记下并提示；数据源上的起草要求和本次补充说明交给模型（不能推翻只记数据事实的规矩）；设置里单独的起草模型（数据目录和按配方导入的 AI 起草共用）；库注释就是名字本身或标识符写法的不当中文名；旧的同步起草遇到进行中的任务回 409	2026-10-14 07:27:04 +08:00
ThearchyHelios	1130f22201	合入数据目录起草验收后修正（前端）：进行中醒目显示接连没写出来的提醒、用量写没写出来和超时的次数并说明超时不计用量、段缩小的说明；逐表与汇总显示模型拿不准留空的列和办法（补充起草要求后重新起草，已有内容不会丢）；清单轻提示与表详情的两个入口；表结构里已经没有的表不再给重新起草	2026-10-13 21:29:00 +08:00
ThearchyHelios	048501d03a	合入数据目录起草验收后修正（后端）：重新起草不丢已有的模型起草项；列分段均分；拆不开的空壳段再问一次；超时改拆小；段大小随额度用完和超时减半；每个原始段最多 8 次调用；接连没写出来时给提醒；用量记超时和没写出来的次数；记下模型留空的列；按表的先后排队不插队；库注释就是名字本身或标识符写法的不当中文名；同步起草遇到进行中的任务回 409；原因写清第几段、哪几列	2026-10-13 21:29:00 +08:00
ThearchyHelios	f74744b29e	README：数据目录的模型起草照复核修正补上——超时的两半同时问、拆到每段 10 列仍接连超时就不再拆，每段连同它分开、拆小的各块最多 8 次，没写出来的原因写清第几段、哪几列，留空的列只记目录里还没有中文名和含义的，库注释就是名字本身或标识符写法的整条不记进目录	2026-10-13 21:26:07 +08:00
ThearchyHelios	7bc7fc685f	起草按复核修正：读回复出错也记进用量；补问时列出了、字段留空不算没写出来；留空的列看目录里已有的；一项都没写出来的宽表逐段写范围；提醒照约定的说法 ... - 读回复时出了意料之外的错：这次调用照样记进用量（算一次出错），再交给 _guarded 记这一块没写出来；以前 _take 抛异常 时这次调用不进 calls、token、failed_calls，也不进提醒的窗口。校验（catalog._from_model）里该是文字的地方写成了 数组、对象的（列名、表类型、业务日期的列、度量类型，columns 不是数组的）直接丢掉、不抛异常：实测列名写成数组时 抛 TypeError，整张表记「起草这张表时出错」。 - 补问时请写的列都列出来了、字段留空：表上算拿不准（记留空），用量和提醒里也不再算一次「只给空壳」没写出来；以前 提醒会因此劝人换模型，真正该做的是补充起草要求。 - 留空的列不算目录里已经有中文名或含义的（不论来源：以前模型起草、按「重新起草不丢内容」留下的，库注释，人工；驳回 的不算有）；写入时（write_draft）再按并入目录之后的结果筛一遍，起草进行中有人填了的同样不算。以前照界面的建议补了 起草要求再起草，模型这次没再给的老列又被说成「拿不准、留空了」，提示一直消不掉。 - 一项都没写出来的宽表同样逐段写上列的范围：「这张表 95 列，分 4 段起草，第 1 段（表级的项）、第 2 段（c001 到 c032，共 32 列）……都没写出来：原因」；只有一段的表照旧只写原因（这一段就是整张表）。 - 提醒照约定写「建议在「设置 → 偏好设置」的「起草模型」换一个模型、缩小起草范围，或者停止这次起草」。	2026-10-13 21:25:59 +08:00
ThearchyHelios	84405977b6	起草引擎按复核修正：每个原始段连同分开的各块一共 8 次；一直超时的模型几轮就停；止损后纯文本不再原样再问 ... - 封顶管到原始段：段大小减半以后，新开始的段按上限分开的各块（窄表重新拼成的各组、单表均分的各块）共用这一段的 调用次数（_Budget 在 _work 里按原始段建，_start、_guarded 接过去），不再每块各有 8 次。以前上限缩到 10 列后一直 只给空壳，4 张窄表拼成的 40 列段调用 20 次，最坏是「段列数 / 上限 × 8」。止损的计数（连续几段没写出来）同样按 原始段数。 - 超时的两半同时问：带表级项的前一半不再先写完才问后一半（一次超时就是一个时限，40 → 20 → 10 串着问要好几个时限）； 额度用完、只给空壳的照旧先写前一半、后一半拿它做背景。 - 超时另有一条止损：拆到每段 10 列（MODEL_MIN_PART_COLUMNS）的调用接连超时 2 次（MODEL_GIVE_UP_AFTER），超时就和 段大小无关了，后面超时的不再拆小，超时拆出来、等名额时还没问的块也不再问（次数退回）；有一次调用写出来就恢复。 只管超时：额度用完、只给空壳照旧拆小。原因后面补「拆到每段 10 列仍然超时，已停止拆小重试，建议更换起草模型」。 用假模型量：每次都超时的 40 列表从 8 次调用、约 7 轮（420 秒时约 49 分钟）降到 6 次、3 轮；首轮同时起草的 3 段从 24 次、约 8 轮降到 12 次、4 轮；40、20 列超时而 10 列写得完的照旧拆到 10 列全部写出。 - 止损以后本来能拆小的段只给空壳：已经走纯文本的不再原样再问（约定只对拆不开的段再问一次）；结构化输出的照旧换 纯文本问一次。 - resolve_draft_model 的说明照实写：超时不由引擎重试，当作这一段太大、拆小再问。 - 止损的说明改成文字（_Why.halted），两种止损各说一次。	2026-10-13 21:25:27 +08:00
ThearchyHelios	ead8ea216b	数据目录起草（前端）：表结构里已经没有的表（只剩目录）不再给「重新起草这张表」「补充起草要求」——服务端只会把它记成已跳过。表详情顶部照写上次起草的结果（没写全的原因、留空了几列），不再建议补充起草要求后重新起草，写明「表结构中已没有这张表，不能重新起草」；清单上留空列的轻提示照旧，悬停里不再建议重新起草。起草设置收到的预先选好的范围（表详情的「补充起草要求」、结果里的「重新起草这几张表」）里的表已经不在表结构里时不再退回别的范围：那一项照旧选着，写明「表结构中已没有这张表，不能起草」（只少了几张时写其中几张不会起草），不能开始，也不默认勾用模型、不把焦点放进起草要求——以前退到「使用次数最多的 20 张表」还勾着用模型，以为只起草这一张，实际按别的范围起草了；选的那一项不在了时，单选框照实际起草的那一项勾。check-catalog 新加一节：只剩目录的表的清单提示与详情；打开详情以后表才没了（清单重取了、详情没重新载入）时「补充起草要求」打开的设置；重新打开后不再给两个按钮。check-all 里数据目录的耗时按实测改成 140 秒	2026-10-13 21:13:15 +08:00
ThearchyHelios	912bc3f107	check-catalog：假服务端给的提醒原文和宽表没写出来的原因照服务端的原样写——提醒是「最近 6 次调用有 4 次没写出来（额度用完 1 次、超时 3 次）。可以在「设置 → 偏好设置」的「起草模型」换一个模型、减少这次起草的表，或者停止这次起草」（原因按额度用完、超时、只给空壳、出错的顺序列）；宽表的原因在列范围之后接着写「这一段没写出来；已拆小重试仍没写出」。以前是照约定自拟的一句，和服务端实际拼出来的不一样，只影响检查的逼真度	2026-10-13 21:09:49 +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	1e1aa3f64a	起草引擎：提醒第一次出现时记一条日志（最近几次调用有几次没写出来、原因）；模块说明补上补问时才列出、字段留空的列也算拿不准	2026-10-13 20:30:02 +08:00
ThearchyHelios	a9170d8728	README：数据目录的模型起草补上验收后的修正（列分段均分、按表先后排队、超时拆小、段大小减半、每段 8 次封顶、提醒换模型、重新起草不删模型这次没给的项、留空的列逐表记下、库注释就是名字本身的不当中文名）	2026-10-13 20:30:02 +08:00
ThearchyHelios	afc98d1318	旧的同步起草 POST /catalog/draft：同一个源有排队或进行中的后台起草任务时回 409 catalog_draft_busy（和建任务同一句话），不再两边同时写同一个源的目录、抢模型名额	2026-10-13 20:30:02 +08:00
ThearchyHelios	975dde1146	起草引擎按验收修正：列分段均分、超时拆小、段大小随模型减半、每段 8 次封顶、提醒、超时与没写出来的计数、模型留空的列、不插队、原因写清哪几段哪几列 ... - 均分：超过 40 列的表，列分段数是列数除以 40 向上取整，各段列数平均（相差不超过 1），不再留下 2 到 8 列的尾段（实测 会思考的模型常对这种小段只给空壳）；表级那段、窄表拼段、parts_total 不变。 - 拆不开的段（不到 10 列）只给空壳：再问一次，结构化输出换纯文本，已经走纯文本的原样再问，仍是空壳才记没写出来。 - 超时当作这一段太大：不再原样重试同样大小的段，按额度用完的办法拆小再问；网络错误、429、5xx 仍原样退避重试。 - 段大小随模型调整：一次起草里额度用完或超时累计 2 次，之后新开始的段列数上限减半（40 → 20 → 10，最低 10），新开始 的段超过上限就先按上限均分开（多表的段按表重新拼）；任务记当前的上限 part_columns。 - 封顶：一段（连同它拆出来的、补问的、重试的）最多调用 8 次，到了次数还没写完的记没写出来、原因写清。止损照旧。 - 提醒：最近 6 次调用有 4 次以上没写出来（额度用完、超时、空壳、出错），任务的 notice 写一句提醒（次数、原因，建议在 「设置 → 偏好设置」的「起草模型」换一个模型、减少表或停止）；之后最近 6 次里少于 2 次就清掉。 - 用量：进度回调 usage 换成 call_done（CallReport：用量、没写出来的原因种类、当前的提醒和列数上限），任务的用量加 timeouts、failed_calls；超时的调用 token 照实记 0。 - 留空的列：请模型写了、模型也列出了，中文名和含义却都没给（或者给的都没通过校验）的列记在 ModelOutcome.blank，逐表 记 blank_columns 和最多 5 个列名 blank_sample，任务上是合计，目录清单的 last_draft 也带列数；表的状态不因此变。已确认 的、库注释已经说清的列不算。补问时把漏的列列出来、字段却留空的，算留空，不再记成「漏了这些列」。 - 公平排队：宽表的表级那段写完，它的列分段排到已经排着的段后面（先来先服务），不再插到队首让窄表一直等。 - 原因：几段因为同一个原因没写出来时说「这几段」，同一段拆出来的几块仍是「这一段」；只有真拆小过才补「已拆小重试仍 没写出」（截断后只补剩下的不算）；每段写上列的范围，例如「第 5 段（列名 到 列名，共 33 列）」，窄表写出是哪几列。 - 库：catalog_draft_jobs 加 timeouts、failed_calls、part_columns、notice，catalog_draft_tasks 加 blank_columns、 blank_sample，旧库启动时补列（存量回填 0 和空）。假模型加 hang（头几次调用一直不回，用来模拟超时）。	2026-10-13 20:30:02 +08:00
ThearchyHelios	645064fe47	数据目录重新起草不丢内容；库注释就是名字本身或标识符写法的不当中文名 ... - 合并（merge_notes）只改模型起草这一个来源的「覆盖即删」：模型这次对某一项没给值（留空，或者给的值没通过校验、在 _from_model 里就丢掉了），以前模型起草的项留着，只有给了合格的新值才替换。只有这一轮完整起草过（covered 含 llm）、 而这一项说的列已经不在表结构里（列级的项看列名，业务主键、业务日期看它们指着的列）才删；write_draft 把表结构里的 列名交给合并。注释、外键、命名推断、剖析各自的规矩不变，人工确认、驳回的不动。删除数因此只在真删时才有。 以前整库重跑一次，模型这次没给的几百项全被删掉，有的表覆盖率从八成多掉到五成，表仍记「已完成」。 - 库注释（comment_role）：和表名（列注释和列名）相同（忽略大小写、下划线、连字符、空白，表名带 schema 前缀的也比 不带前缀的），或者是标识符写法（只有字母、数字、下划线、点，不带空格），不当中文名、也不当说明，不记进目录；交给 模型的表结构里照旧有这条注释。以前这种注释短、不带句读就当中文名，库注释的级别又高于模型起草，模型起草的中文名 永远进不了目录。已有目录不另做迁移：起草到那张表时，旧的那条随这一轮的注释删掉，模型起草的中文名就能进来。	2026-10-13 20:30:02 +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	c5a95c9198	test_masking_tool_boundary：查金额原值之前先去掉哈希——工件 id、快照里记的哈希是随机的十六进制，偶尔碰巧含「1200」，全量并行时偶发失败	2026-10-13 16:59:58 +08:00
ThearchyHelios	950b88a15b	README：数据目录一节补上模型起草（后台任务、只重试失败的表、中断不自动续跑、保留思考加大额度、按段起草宽表、起草要求与本次补充说明、起草模型设置）	2026-10-13 16:57:02 +08:00
ThearchyHelios	f532c5c130	合入数据目录起草改造（前端）：起草对话框改成后台任务（逐表进度与段进度、停止、关掉不停、只重试失败的表、两种 409）、起草要求与本次补充说明、目录页进度与清单上的上次起草失败标记和单表重起草、设置页起草模型；check-catalog、check-manage 随之改写	2026-10-13 16:56:02 +08:00
ThearchyHelios	e6edc3a582	合入数据目录起草改造（后端）：起草模型设置组 catalog_draft、数据目录与配方 AI 起草共用取模型；新起草引擎保留思考、额度 32768 被拒退回 8192，40 列 / 4 张表分段，宽表表级加列分段，按失败原因拆小、补缺、截断捡回、改走纯文本、退避重试与止损；起草要求进提示词；后台起草任务与 draft-jobs 接口、启动标中断不续跑；目录清单 last_draft、active_job、guidance	2026-10-13 16:56:02 +08:00
ThearchyHelios	38d6f47e67	PUT /catalog/guidance 的请求没写 guidance、或者不是一段文字时回 422 带一句中文说明（同超长时的写法），不再是 pydantic 的英文校验结果；表名恰好叫 guidance 的整份提交照旧	2026-10-13 16:48:46 +08:00
ThearchyHelios	4857c578f6	起草的止损和公平：连续 2 段（MODEL_GIVE_UP_AFTER）拆到底仍一项没写出来，这次起草后面的段不再拆小重试，没写出来就直接记下，原因后面补「模型连续 2 段都没写出来，已停止拆小重试，建议更换起草模型」；有一段写出来就恢复拆小。每次起草同时只起草 3 段（MODEL_CONCURRENCY），一段连同拆小、补缺做完再取下一段，宽表的表级那段写完，它的列分段排到最前面一段一段起草；同时在等全进程名额的调用每次起草最多 3 个，几次起草（不同数据源的任务、同步起草）交替排队，后开始的不再等前一个排着的上百段全部调完。实测一直只给空壳的 294 列宽表从 168 次调用降到 81 次，20 张 120 列的宽表一直用完额度从约 900 次降到 122 次	2026-10-13 16:46:52 +08:00
ThearchyHelios	c3105bba4f	起草引擎按失败原因处理的三处修正：结构化输出回了一段说明文字（不是 JSON、也没停在额度上，例如网关接受了 response_format 却没照做）不再因为带着思考就当成额度用完去拆，也不直接判失败，这次起草后面改走纯文本、这一段换纯文本问一次（纯文本另带格式说明）；只有停在额度上、或者正文为空而有思考才算额度用完。补问之后整列没列出来的列记没写出来（「模型的回复里漏了这些列，补问一次仍没有给出」），表是 partial、covered 不含 llm，以前起草过的待确认模型项不再被删（以前补问只给空壳也记 ok，还把这一轮没给的旧项删掉）；列出了、字段留空的照旧算拿不准；补问时整张表还一项都没有的，照只给空壳的规矩拆小、换纯文本，不直接记失败。几处没写出来的原因按基础原因去重，拆小重试过的在最后补一句，不再出现同一句说两遍。假模型照提示词把请写的列都列出来（字段留空是拿不准），要模拟漏列的传 list_all=False	2026-10-13 16:42:45 +08:00
ThearchyHelios	ec6838dc10	起草模型的 SDK 不再自己重试：ModelSpec 加 max_retries，build_chat_model 一直传到 SDK 客户端（Bearer 鉴权换上的 Anthropic 客户端也带上）；数据目录起草建的大、小两个模型都是 max_retries=0，429、5xx、网络错误、超时只由起草引擎按失败原因重试（最多 2 次）。以前 openai、anthropic 的 SDK 各自先重试 2 次，叠在引擎的重试上，一段最多发 9 次请求，报错却写「已重试 2 次」，网关限流时还放大流量。不写 max_retries 的调用照 SDK 默认，配方 AI 起草不动	2026-10-13 16:40:07 +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
ThearchyHelios	f57c6e284b	数据目录起草的几处说法照服务端的实际做法改：点停止后写「正在停止：取消进行中的模型调用，正在写入目录的表写完后停止…」（服务端马上停掉进行中的调用、只等手上那张表写完，不是等当前这次调用结束）；任务整体出错时原因照服务端的原话在「起草失败」下面写一次（服务端的原因有的自带「起草任务出错：」开头，界面不再套一层），服务端给没结束的表记的同一句不再逐表重复（服务重启中断同样），各有原因的照写；「只重试失败的表」没建成和开始时同一个说法——起草模型用不了（服务端重试也回 409 catalog_draft_model_unavailable）照原样写那句话、长句不再拆成「标题：原因」，别的写「未能开始起草」；提示里原因为空时不留冒号。check-catalog 先补会失败的检查：停止的说法、重试时起草模型用不了、任务整体出错（原因只写一次、逐表不重复、都能重试），服务重启中断的逐表不再重复原因；假服务端的中断任务照后端记上同一句原因	2026-10-13 16:34:29 +08:00
ThearchyHelios	bf0619a03c	目录清单的 last_draft 改在库里挑：每张表最近一次起草任务里的那一项用窗口函数取，起草进行中清单页反复刷新时不再把最近一百个任务的逐表记录全读出来	2026-10-13 15:38:27 +08:00
ThearchyHelios	b988a5ae18	起草引擎和后台任务的几处收紧：提示词要求请写的每一列都列出来（拿不准的字段留空、列不漏），免得模型留空的列再被补问；纯文本那条路的格式示例改用「表类型」「度量类型」占位，不让模型照抄示例值；从正文取 JSON 时依次试多个括号作开头，说明文字里带括号、外面多包一层都认得；用量记在单次调用的时限之外，落库慢了不会把已经回来的调用算成超时；后台任务收尾写库出错只记日志；补上从正文取 JSON、任务开始时模型已用不了（整体 failed）的测试	2026-10-13 15:36:24 +08:00
ThearchyHelios	f4ef5919bd	数据目录：正在编辑一张表时，它的「重新起草这张表」先不给点并写明先保存或取消——起草会写进这张表，编辑中的保存就会撞上版本冲突；check-catalog 补一项	2026-10-13 15:34:12 +08:00
ThearchyHelios	c1a70ecf38	数据目录起草改成后台任务：新表 catalog_draft_jobs、catalog_draft_tasks 存任务和逐表状态，同一个源同时只有一个排队或进行中的任务（接口先查、部分唯一索引兜底）；POST /catalog/draft-jobs 建任务（202），GET /draft-jobs/active、/latest、/{id} 读任务，/cancel 停止（排队的直接停，进行中的停掉正在进行的模型调用，已写进目录的不回滚），/retry 只重试失败、只写出一部分、停止了的表；同源 409 catalog_draft_busy、起草模型用不了 409 catalog_draft_model_unavailable、已结束 409 catalog_draft_finished；每张表一结束就并入目录，进度、计数、用量随时落库；服务启动时把没做完的任务标成中断、不自动续跑，关停时同样；目录清单每行加 last_draft，顶层加 guidance、active_job；数据源级的起草要求存在 options 里，经 PUT /catalog/guidance 维护（最多 2000 字，表名恰好叫 guidance 的整份提交照旧），数据源接口不显示、整份回写 options 时留着，拼连接串时摘掉；本次说明最多 1000 字，任务记下起草要求和本次说明的快照，同步起草也带上数据源的起草要求	2026-10-13 15:33:00 +08:00
ThearchyHelios	8795475207	check-catalog：上次起草失败的表打开后的说明（原因和「重新起草这张表」）也截一张图；check-all 的耗时表里数据目录一项按实测改成 110 秒（起草改成后台任务后多了五段检查，单独隔离跑约 108 秒）	2026-10-13 15:32:00 +08:00
ThearchyHelios	31caf02323	设置页加「起草模型」一节（前端）：数据目录的「用模型起草」和按配方导入表格时的 AI 起草用的模型，接入、模型两项照核查模型的做法——两项都留空跟随助手的模型，只填模型时写明按模型名用哪个接入，存着的接入不存在、已停用时在那一格下面说清用模型起草会报错，换接入时清掉不属于它的模型；和其余设置共用保存条，改了才整组写 catalog_draft（空着的存 null），服务端按项拒收（422，field 为 catalog_draft.provider）时整句落到那一格、焦点移过去；老服务端没有这一组时不显示。check-manage 加一节覆盖	2026-10-13 15:25:27 +08:00
ThearchyHelios	90a560d07e	数据目录起草改成后台任务（前端）：对话框选范围、写起草要求和本次补充说明后建任务，之后显示任务的进度和结果——总进度、新增 / 更新 / 删除合计、逐表状态、宽表的段进度、没写全的原因；可以停止、在后台继续，关掉对话框任务照常进行，目录页上方显示一条进度，点开回到对话框，结束时提示并可查看结果；结果里只列没写全的表，「只重试失败的表」新建只含失败、部分完成、已停止的表的任务；服务重启中断的任务写明原因、同样能重试；已有任务（409）转去显示进行中的那一个，起草模型用不了（409）留在设置阶段写明原因；起草要求改过先存再建任务，写明用的是哪个起草模型、数据源说明也一并交给模型；清单上标出上次起草失败、部分完成的表并写原因，表详情里给「重新起草这张表」；进行中每 1.5 秒取一次，取回的状态只往前走。check-catalog 用假的任务接口覆盖这些（任务怎么往前走由检查自己推），旧的同步起草检查换掉	2026-10-13 15:24:57 +08:00
ThearchyHelios	6b1f63a9dc	数据目录模型起草换成分段、按失败原因处理的引擎（data/catalog_draft.py）：每次最多 4 张表、40 列，窄表按顺序拼段，宽表拆成「表级一段 + 每 40 列一段」，列分段带着表注释和表级起草结果做背景，最后合并照旧逐项校验；思考和输出用完额度、只给空壳时拆成两半再问（最少 5 列、最多 3 层），拆不开的空壳换纯文本问一次，写出来了后面都走纯文本；被截断的 JSON 先捡回已完整的表和列、只补剩下的；缺了的表和列只补缺的、补一次；服务方嫌额度大时退回 8192、结构化输出不支持时改走纯文本，都管到这次起草结束；网络错误、429、5xx、超时退避重试最多 2 次；单次调用 420 秒；全进程最多 3 个调用同时进行；报错写原因和办法（第几段、共几列没写出来、可以只重试这张表）；提示词加上起草要求一段（数据源说明、起草要求、本次说明，规矩在前、冲突以规矩为准）和「思考时不必逐列草拟」；同步起草改用新引擎，写入抽成每张表一结束就能调的 write_draft	2026-10-13 15:19:06 +08:00
ThearchyHelios	b940b27e24	起草模型设置：新增设置组 catalog_draft（接入、模型），点名的接入不存在或已停用时保存回 422；数据目录起草和按配方导入的 AI 起草共用一处取模型（起草模型 > 助手的模型 > 默认接入），取自起草模型时报错照实说起草模型那一项；数据目录起草不再关思考，额度 32768，服务方嫌大时退回 8192（之后都用小额度），单次调用时限 420 秒交给 SDK；配方 AI 起草的额度、思考设置不动	2026-10-13 15:00:38 +08:00
ThearchyHelios	49583b273f	check-all：报告导出的检查加进 ORDER——以前只在耗时表里登记，check-all 不认、一直没跑，README 里写的 28 项这才对得上；那一段的注释改成「复核套件与导出」（占位早就换成了真检查）	2026-10-13 10:20:47 +08:00
ThearchyHelios	1e95f41a10	报告导出成 HTML 时，升级前写的老文档里取自遮罩列的指标写「已遮罩」：正文引用了、证据目录里却还带着原值的那几个，按可验证报告认老文档的同一个判断（certain_masks + bundle/build.py 的 withheld_metric_aliases，只认确定取自遮罩列的）照现在的报告撰写节点的写法改写，正文、按钮提示和出处链里都不出现原值；普通指标照常，现在写的文档本来就是「已遮罩」	2026-10-13 10:04:30 +08:00
ThearchyHelios	06b2c2b8ae	合入报告导出为自包含 HTML（数字点得开口径、来源、计算方式）与可验证报告数字详情里的口径卡一节；和可验证报告的遮罩改造合并：口径卡只给 id 的规则（有指标的值取自遮罩列、文档里写成「已遮罩」的）照旧，随文件附带的卡才附上它的输入指向的查询快照；数字详情保留显示文字核对和超过 2^53 的数照 JSON 原文显示，口径卡一节里输入的值同样照原文；样本页从 16 份变成 17 份	2026-10-13 10:03:24 +08:00
ThearchyHelios	4cd5f334a3	合入核查与定时七项新功能：双盲复算（看不到原 SQL 的 agent 按输入重算，不一致时停下来让人选、只差一个条件时把选择写进数据目录，设置可全局开关、节点可单独设）、两次运行的变化三分法（口径变化、数据变化、参数变化，按维度找主要贡献）、反方审稿（关键结论逐句用只读查询去驳，被推翻的让出具降档）、可验证报告（单个文件断网重算哈希、逐个核对数字和显示文字，遮罩快照只给哈希）、审批质询（停在审批时提问、可新跑只读查询、问答随运行封存）、数字推演沙盘（改输入、排除快照行，不往运行里写任何东西）、定时任务（cron、日期变量、补跑与防重叠、站内与 Webhook 通知、跑完自动和上一次对比）；核查 agent 的查询结果在工具边界先遮，取自遮罩格的口径卡指标不进报告和可验证报告；以及两轮真实模型验收中发现问题的修复	2026-10-13 09:46:06 +08:00
ThearchyHelios	23f9453409	check-verify：设置页「核查」一节存完之后取今日花费的那次请求，满并行时晚于「已保存」到达，轮询等它（最多 3 秒）再判；单独跑一直通过，check-all 满并行时偶发 2 → 2	2026-10-12 23:23:01 +08:00
ThearchyHelios	fc628a86a2	合入期 5 验收修复 N1：取自遮罩格的口径卡指标不进报告文档和可验证报告——写作目录与文档证据目录写「已遮罩」，引用它的 [[m:…]] 由报告自查拦下；转抄上游口径卡的遮罩在指标依赖图上一次算出最小不动点（循环自引用不误判、不再指数耗时），上游卡在任何一次执行里有遮罩指标时转抄一律不给；可验证报告的显示文字核对改成白名单，紧挨着的数字、小数点、真负号判不通过，易混字、量级单位、删除线、方向字符判无法核对，有一项无法核对总览就不给绿色并提示对照服务端封存哈希	2026-10-12 23:05:18 +08:00
ThearchyHelios	7589c350bd	期 5 验收修复 N1 第 4 轮：转抄上游口径卡按整张卡、每一次执行认（保守规则）；显示文字白名单收紧复核点名的几类，软换行和金额符号不再误伤 ... 复核第 3 轮（91aa34d）找到三处 major、两处 minor：循环里卡转抄自己上一轮、更早一轮取过号码（SQL 带模板）时，写作目录只看 运行状态里最后一次的产出，号码进了报告正文和成果，自查通过、正式运行成功，封存之后的面板才写「已遮罩」；整张卡、清单文字、 下标不是字面量的转抄只按值认，由遮罩格算出来的年薪（月薪 × 12）在写作目录、报告、成果、证据面板、可验证报告里照给；显示 文字的白名单里还收着易混字（’ 当千分位、刂 当竖线、×10⁴ / T / bn / m 改量级、en dash 当负号），伪造页总览照样是绿色的 「全部通过」；先起别名再套没起别名的表达式、+phone 这类 SQL 写法认不出遮罩列；段内软换行紧挨着数字、数字前的 ￥ ¥ 被判 无法核对，原样导出的正常报告总览变成中性。 转抄的保守规则（recompute.masked_closure 的 CopyEdge.card；写作目录、报告自查、证据面板、推演、可验证报告同一个判断） - 卡上的输入转抄上游口径卡（字面量下标、下标不是字面量、整张卡、清单文字、整份指标列表都算），只要那张卡在这次运行的任何 一次执行里有一个指标不给，转抄出来的就不给（masked，整张卡转抄不再降成 table 按值认）；那张卡一个不给的指标都没有时照常， 没设遮罩的工作流、循环里累加自己上一轮的卡照给（第 3 轮修好的那条不回退）。最小不动点上按卡汇总：每张卡「有指标不给」 只从无到有、遮罩列只增不减，变一次只重认转抄它的那几个，工作量仍和边数成正比 - 每一次执行的指标集按台账认：写作目录（withheld_metrics）把运行状态里台账的 metric_set 条目交给 _CopyGraph（_executions， 连同它们的输入先在线程里读好），封存之后按封存范围内的台账；可验证报告（_Store._executions）按 node.finished 的台账条目 - 转抄的是哪张卡按读到的产出上记着的指标集认（经数据整形赋给变量的也认得出是哪张卡），认不出的按取值链上的节点 - 推演（recompute._copied）、证据面板（_copied_held）随之去掉整张卡转抄的 table 一档 - 行为变化：转抄了带遮罩指标的卡的普通指标（客户数、数指标个数、清单字数）也写「已遮罩」、推演不让改，正式运行引用它判 失败；那张卡自己的普通指标照给。test_report_masked_card_copies、test_report_masked_copy_closure 里按老规则写的期望相应改了 显示文字核对（verifier.js） - 弯撇号（U+2018、U+2019）移出常见写法的名单；偏旁形的汉字（刂冫氵亻阝扌忄犭礻衤讠钅饣纟丬）、康熙部首、部首补充、扩展 B 区以后的字不算常见写法：紧挨着数字判无法核对 - 数字后面紧接 ×、*、^ 再接数字判无法核对（新原因「后面紧接着乘号或乘方和数字」），后面那个数本身也核对过的（两个数相乘） 不算 - 数字后面紧接着、或隔着空白和左括号的英文量级写法（T、G、m、b，bn、mn、tn，thousand、million、billion、trillion）按整串 字母认，判无法核对；ms、GB 这类别的单位不算 - en dash 归入像负号的短横：紧挨在数字前面判无法核对（不判不通过），前面是数字、字母的区间照常 - 段内的换行（页面上显示成一个空格）、金额前面的「￥」「¥」收进名单 - 「（单位：万元）」、x10 这类隔着几个字或换了写法的认不出：名单只是兜底，bundle/build.py 的模块说明写明真伪以封存哈希为准 已知局限不再加规则：api/evidence.py、bundle/build.py 的模块说明写明遮罩只减少暴露、不是安全边界，列出认不出的 SQL 写法 （先起别名再套没起别名的表达式、+phone、Postgres 给没起别名的表达式起的列名、视图、自己建的函数、数据整形取出来的号码）。 验证 - 新增 tests/test_report_masked_copy_any_run.py（20 项）：纯函数上的边规则（四种写法、循环三轮、之前认好的指标、读到的产出 读不出来）；循环里转抄更早一轮的号码（护栏写法、只按字面量下标两种）写作目录写「已遮罩」、正式运行判失败，标注时文档、 成果、面板、可验证报告都没有号码；循环之后的卡转抄最后一轮，写作目录、面板、推演、可验证报告同一个判断，可验证报告自己 （没有报告的运行、老文档）也认；经数据整形转抄的按卡本身认；年薪的五种转抄写法写作目录都写「已遮罩」，标注时文件里没有 年薪；没碰号码列的循环、卡上没有遮罩指标的照常 - test_bundle_shown：复核点名的几类各自判无法核对、写明原因、总览中性；软换行、￥ ¥、两个核对过的数相乘、en dash 区间、 ms / GB 照常通过；PROSE 样本去掉 en dash，加上软换行和 ￥ ¥，17 处全部通过 - check-bundle 补弯撇号、刂、扩展 B 区、×10⁴、bn、billion、en dash 七种篡改（各自判无法核对、点名、总览中性），prose 样本 17 处全绿 - 复核者探针：test_probe_r3a、test_probe_r3c 的写法都拦住；test_probe_n1c（没设遮罩的循环自引用）照常；layout_probe 的 108 种写法里点名的几类都判无法核对，￥ ¥ 照常通过；Chrome 断网打开 forge3、forge4 的伪造页，点名的几类都不是绿的、提示 都显示 - 开发数据 39 份报告 1591 处、验收数据 58 份 1695 处引用按新规则扫过，判不通过和无法核对都是 0 - 每处改动都做了「去掉实现、测试变红」：17 个定点变异（不看整张卡、不读每一次执行、写作目录不交台账、可验证报告不读每一次 执行、整张卡退回按值认、推演不认、按取值链上的节点认卡两处；弯撇号、偏旁、扩展 B 区、乘号乘方、英文量级、en dash、软换行、 ￥ ¥、两数相乘豁免）全部变红	2026-10-12 23:01:09 +08:00