507 Commits

Author	SHA1	Message	Date
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	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	4819b21269	下一轮第 1 波的契约骨架：运行加 end_reason（人工驳回 / 手动停止），定时任务加目标种类和 id、触发记录加评测 id（定时只有一套），运行来源登记 eval、ledger_issue、reconcile、recall（都只能由服务端写）；迁移只加不改	2026-10-16 09:43:08 +08:00
ThearchyHelios	ff278afd7e	剖析的范围在开始时定：排在起草后面的剖析任务，开始时按起草后的目录重挑要剖析的表 ... 真实后端验收里「起草完接着剖析」这条主路走不通：剖析任务建的那一刻就按当时的目录定了表单，可它排在起草后面，起草还没提出 关系，只靠关系才有检查项的表（链接表、明细表）一张都挑不进来，起草写完关系后剖析照旧跳过它们。 - 开始剖析时（_ProfileRun._rescope）按那一刻的目录重定：需要剖析的表、全部表整份重挑（这个任务的表都还没开始）；指定的表里 建任务时判为「没有可剖析的项」的再看一次，现在有了就排上。 - 排在起草后面时挑不出表也照建，不再 409（起草多半会提出关系）；开始时还挑不出来，任务以 0 张表结束，提醒里写明为什么。 - 界面：排队时写明要剖析哪些表开始时按起草后的目录再定，开始前的张数是按现在的目录算的。 - 新测试在去掉重挑的代码上两条都失败。	2026-10-15 19:43:29 +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	4f0b60df03	导入、同步起草撞上剖析、起草任务时，说法按这次要做的事说下一步 ... 复核 R3。导入目录、同步起草撞上剖析任务回 409 profile_busy 时，原话来自 busy_message，结尾固定是「请等这次剖析结束 （或先停止它）再开始新的剖析」；使用者这时是在导入、起草，不是要开始新的剖析，导入对话框原样显示这句。导入撞上起草 任务时同样说「再开始新的起草」（这是改造前就有的，同一类问题一起改了）。 - catalog_profile_jobs.busy_message / ensure_free 加 then（缺省 THEN_PROFILE「再开始新的剖析」，建剖析任务、重试照旧）。 - catalog_jobs.busy_message / sync_busy_message / ensure_draft_free 同样加 then（缺省 THEN_DRAFT「再开始新的起草」）； ensure_idle 和 _lane_busy 按这次要做的事（kind）选：导入撞上什么都是「再导入」；同步起草撞上剖析是「再起草」，撞上 起草仍是「再开始新的起草」（和建起草任务同一句话，test_catalog_draft_jobs 钉着这一点，没动那个文件）。 - 导入接口的说明补上撞上剖析任务回 profile_busy。 测试：剖析时导入、同步起草、再建剖析任务三句结尾各自对得上；队被剖析占着时（任务刚好在收尾）同样按这次要做的事说。	2026-10-15 19:12:48 +08:00
ThearchyHelios	7ee820f0f5	表的「上次剖析」取真正开始过的那一次：没开始就停了的、还排着的不再挡掉上一次真正剖析，保留也不清它 ... 复核 R2。以前每张表的「最近一次剖析」只按任务的建立先后取，没开始就结束了的那一项（停在前面的表上、任务止损或整体 出错后没轮到）、排队中还没轮到的那一项也算。于是表详情、表清单的上次剖析变成一条没有行数、没有发过的查询的「已停止」； prune 只保护排第一的那一项，上一次真正剖析所在的任务就会被清掉——行数估算、日期范围、发过的查询只存在剖析任务里 （设计文档 §5 否决了写进目录），删了就找不回来，和 §4.8「表详情的上次剖析永远有」相抵。建一个排队任务时顺手的 prune 就能清掉它。 - _ranked（替代 _latest_per_table）一个子查询给两个排名：shown 是真正开始过（started_at 有值；收过尾的表都有）的最近 一项，一次都没开始过才退回最近一项；latest 是最近一项，只用来看这张表是不是已经排在进行中的任务里。 - last_profiles、last_detail、prune 的保护都按 shown。表还排在进行中的任务里时，表详情给的是上一次真正剖析的明细， 排队、在做由页面跟着的任务说（前端 profileCell / ProfileSection 的 live 本来就这样）。 - due_reason 也按 shown（加上 queued：已经排在进行中的任务里不算要剖析），不照复核建议看最新一项：不然表清单一边显示 「上次剖析：完成」，一边说「上次剖析没做完」。真正没剖析完整的表照样 due——上次真正剖析是 partial 的仍是 unfinished， 从没开始过的退回最近一项（cancelled）仍是 unfinished，剖析之后冒出的待核实关系仍是 new_relations。 测试：新增先剖析 channels、再在 [visits, channels] 停在 visits 上——channels 的上次剖析仍是第一次（行数、发过的查询 都在），不算要剖析；prune(keep=1) 不删；保留数为 0 时再建一个排队任务也不删。	2026-10-15 19:11:59 +08:00
ThearchyHelios	35c83d3001	剖析收尾照实说：没写进目录的检查项不再标「完成」，目录和表的剖析结果同一个事务提交 ... 复核 R1。目录只在一张表结束时由 _record 写一次，进程被杀（启动时标中断）、任务整体出错（剖析到一半快照被改动）时， 正在剖析的那张表没走到这一步，可它已经做完的检查项仍记 done：检查清单上标着完成，findings 是空的，目录里那几条关系 还是推断。_close_tasks 只改 pending / running，于是把没写进去的结论说成了做完。 - _close_tasks：还没结束的表上 done 的检查项也记为跳过，原因同这张表（中断 cancelled、出错 error），说明是 「{原因}，查完了但结论没有写进数据目录」，算进 unfinished，重试时带上这张表；这张表的 error 写明「已查完的 N 项 没有写进数据目录，剩下 M 项没查」。跳过的项按检查项列全：进行中的表只随时落了检查项，按规则不查的（遮罩……）以前 收尾时不进跳过的项。优雅停止、关停不走这条路，正在剖析的那张表做完的项照常写进目录（error 说「照常写进了数据目录」）， 前端可以据此分开说。 - 目录和这张表的剖析结果改成同一个事务：catalog.write_entry 加 commit=False（只写进事务、冲突照样回滚）， catalog_profile._record 写目录不提交，recorded（_save_table）也不提交，最后一起提交。以前是两次提交，进程在中间没了 会出现目录写了、剖析记录却说没写的情形，上面那句「没写进目录」就不照实。 - 不改成每项做完就写目录：每写一次目录升一个版本，表结构快照的哈希跟着变，和人工编辑撞乐观锁的机会也成倍增加； 设计文档定的是整张表结束时并一次。 测试：启动标中断那条改断言（查完的码值记 skipped / cancelled、error 带「已查完的 1 项」）；新增剖析到一半快照被改动 （4 条关系查过了、全记 skipped / error、目录不动、重试带上 visits）；新增记结果那一步出错时目录跟着回滚（换回两次提交 这条就挂）。	2026-10-15 19:11:28 +08:00
ThearchyHelios	f375101c5e	补齐剖析任务的测试（设计文档 §7 后端那一串），顺手改掉几处过时的说明 ... 新增 tests/test_catalog_profile_jobs.py，用很小的 SQLite 夹具和假的查询层让超时、失败、停在哪一条都可控： - 同源排队：起草在跑时剖析建成 queued、waiting_for = draft，起草结束后自动开始；剖析在跑时建起草任务不 409、排在后面（waiting_for = profile），同种任务照旧 409；停掉排队中的剖析任务（在队里等着的一起停掉，检查项不留「排队」）；导入目录、同步起草在剖析时 409 profile_busy；同步起草、导入期间建的剖析任务排在它后面，导入期间再导入一次 409 - 停止：停在 visits 的码值上，做完的 4 项照常写进目录、没做的记 cancelled 且目录不动，后面的表 cancelled，正在等的那条查询留痕写明没等结果；已结束的再停 409 catalog_profile_finished - 关停标中断、启动标中断不续跑（进行中那张表的检查项转成跳过）；重试只带没做完的表、设置取当前的，没有可重试的 422，正忙 409 - 任务级止损：连续 3 条失败（error 带驱动报错第一行）、最近 10 条 7 条超时（停下、后面的表带同一句原因）；提醒在好转后清掉，成功一条重置连续失败数 - 每张表开始前重读数据源：停用、关掉剖析就停；遮罩按最新的设置 - 范围：全部 / 需要剖析 / 指定（视图、表结构里没有、没有可剖析的项建成 skipped），有待核实关系的在前；profile_due 的 never / unfinished / new_relations；挑不出表 409 profile_nothing；超 500 张 422；空表一条查询记 skipped - 留痕：IN 列表里抽到的键值（文字键）不出现在库里的 query_log；表清单、表详情带上次剖析 - 设置迁移：启动时删掉旧键，老页面带旧键保存只摘掉；保留：超过保留数删旧的，不删某张表最近一次剖析所在的任务，建任务时顺手清 剖析停在一张表中途时，那张表的 error 改说「已做完的 N 项照常写进了数据目录」；engine.py、catalog_transfer.py、catalog_jobs.py 里还写着查询次数上限、只看起草任务的几处说明跟上。	2026-10-15 18:40:19 +08:00
ThearchyHelios	6b3c737fb8	数据剖析改成逐表的后台任务：引擎改编排、剖析任务、接口、设置换新键 ... 以前剖析是一次同步长请求，预算按整次算（max_queries 60、max_total_s 120），选 50 张表只做得完前两三张，其余整张记「查询次数用完」；不能停，关掉页面报告就没了，对业务库查了什么无从查。 - data/catalog_profile.py：检查逻辑和 _apply 并入规则原样保留，只换编排。公开的逐表入口 profile_table：先列全检查项（plan_checks，纯函数，范围的 profile_checks、建任务时列的检查项、执行用同一份；遮罩、多列、不在表结构里、指向视图的关系在这里就列成按规则跳过），第一条查询估行数（确知空表整张表跳过），逐项执行、进度回调，整张表结束写目录并和回调在同一次库操作里；停止时做完的项照常写、没做的记 cancelled 保留旧结论。_Runner 拆成整个任务一个的 SourceRunner（只读守卫、单条时限、任务级止损：连续 3 条失败、最近 10 条 7 条超时；最近 6 条 4 条超时提醒；每条查询留痕，SQL 经 normalize_sql 去掉字面量）和每张表一个的 TableBudget（用完只停这张表）。删掉同步的 profile_catalog、挑表前批量估行数（_skip_empty、PROFILE_DEFAULT_TABLES、PROFILE_PROBE_TABLES）和进程内 _RUNNING。设置换成 table_max_queries（1–200，缺省 40）、table_max_s（10–600，缺省 60），旧键 max_queries、max_total_s 启动时从库里删掉（migrate_settings，不折算：旧值按整次算，含义不同），保存时只摘掉不报错（without_legacy）。表助手的 run_query 和起草时核对有效记录条件改走单条查询入口 run_single_query，行为不变。 - data/catalog_profile_jobs.py：剖析任务的建（selected / needed / all 三种范围，排序同前：有待核实关系的在前、使用次数、表结构顺序；挑出 0 张 ProfileNothing）、排队（和同源起草按建立先后串行，waiting_for）、执行（每张表开始前重读数据源：停用或关掉剖析就停下；遮罩按最新设置）、停止、重试、启动标中断不续跑、保留最近 50 个结束的任务（某张表最近一次剖析所在的不删）、last_profile / profile_due 的查询、任务和逐表的接口形状。 - api/catalog.py：加 /profile-jobs（建、active、latest、{job_id}、tasks/{seq}、cancel、retry），登记在 /{table} 前面；删掉 POST /catalog/profile；清单每行加 last_profile、profile_due、profile_due_reason、profile_checks，顶层加 active_profile_job；单表加 last_profile；导入目录、同步起草遇到剖析任务 409 profile_busy。api/coded.py 加 profile_nothing、catalog_profile_finished；api/datasources.py 保存时摘掉旧键；main.py 启动时标中断加设置迁移，关停时停掉进行中的剖析。 - 测试：test_catalog_profile.py、test_catalog_profile_units.py、test_catalog_semantics.py 里打同步接口和旧设置键的改走任务和新键，检查逻辑的断言保留；同步接口的整次总量上限一条改成逐表次数、逐表时长两条。	2026-10-15 18:30:48 +08:00
ThearchyHelios	1e58862bf0	抽出数据目录后台任务的共用运行时，起草任务改用它：为剖析改成逐表的后台任务做准备 ... data/catalog_job_runtime.py 从 catalog_jobs.py 抽出进程内任务的执行与停止（JobManager：start / stop(grace) / wait / running / shutdown；JobRun 把进队、等轮到自己、执行、按停止原因收尾、出队写一次）、同一任务的库写入一条一条来并 shield（SerialWriter）、启动时标中断（interrupt_on_startup、close_job）、状态词常量，以及每个源一条先来先到的队（SourceLanes：任务阻塞地占，同步写操作不阻塞地试占）。剖析和起草是同一类问题（关页面就没了、不能停、不留痕），生命周期各写一份迟早一边修了另一边没修；共用的是生命周期代码，表各建各的。 起草的行为不变（test_catalog_draft_jobs.py 一条不改全过），只是：ensure_idle 拆成「同种任务互斥」（ensure_draft_free，建起草任务、重试用，剖析任务不挡起草，起草任务排在它后面）和「同步写操作要求源空闲」（ensure_idle，同步起草、导入用，剖析任务也算）；同步起草、导入目录执行期间占着这个源的队，期间新建的任务排在后面；任务和清单顶上的进度带 waiting_for（起草排在剖析后面时为 profile）；排队中被停止的任务连同在队里等着的后台执行一起停掉、出队。 db/models.py 加 CatalogProfileJob、CatalogProfileTask 两张表（create_all 建，同源排队或进行中的部分唯一索引照起草的写法）；catalog_profile_jobs.py 先放剖析任务的忙碌判定，下一步补全。	2026-10-15 18:10:50 +08:00
ThearchyHelios	d2b398563b	写回卡片加「结果不明时谁去核实」：写回的目标能力没登记查询时，结果不明（请求发出去了、没拿到答复）平台查不了、也不自动重发，要有人去目标系统里核实；以前发布单报「写入结果不明时没人核实」「有一步还没指定谁来做」却在卡片上找不到地方改。 ... - 蓝图格式：写回卡片多一项 reconciler（一组人或组），旧蓝图没有这一项照旧可读；只收用户的操作（同「谁能看」），助手整张换写回卡片时留着用户选好的人 - 是否需要（templates/_common.needs_reconciler，和应用骨架加核实岗位同一个判断）：模板用到写回卡片、选了目标能力、能力没登记查询；交给前端的蓝图带 reconciler_needed，界面不自己判 - 蓝图检查 bp.reconciler_unbound：试运行只提醒（待办派给试运行的人自己），发布挡住；发布单上应用检查说同一件事的 app.reconciler_unbound 和核实岗位的 app.slot_unbound 不再重复列 - 岗位绑定：选了的人绑到应用的核实岗位；能力补登了查询就不再要、也不再绑，卡片上留着的人照样摆出来、写明用不上 - 卡片：需要时摆这一项，标「缺」、写明为什么要人核实，选人控件只能选人或组；「缺」只挡发布；蓝图助手的提示词写明这一项由用户定 - 示例蓝图（核对写回）补上核实人，审批、核对写回的卡片说明写上这一项；测试和检查脚本跟上	2026-10-15 17:31:20 +08:00
ThearchyHelios	7fc3488b55	取数 SQL 不再把数据源名写成库名，试运行失败的蓝图不能发布：填关节的说明以前把表写成「数据源名.表名」，模型照抄进 SQL，数据库把数据源名当成库名（MySQL 报 Unknown database），应用每次出数都失败；说明改成只写数据源里的表名，并写明不要加数据源名。助手自查加 sql_source_prefix：表名前面写了数据源名就交回模型改（认列的检查找表时去掉前缀，拦不住它；数据源名恰好是库名、schema 的不报）。发布单遇到最近一次试运行失败改为挡住（plan.trial_failed，带出错的那一句），不再只是「还没有成功的试运行」的提醒	2026-10-15 17:31:20 +08:00
ThearchyHelios	fcbf711941	按需求挑选不再总是「没挑出来，已把表目录交给助手」：挑选以为能关掉思考、只给 1024 的输出额度，可经 OpenAI 兼容接入的推理模型（DeepSeek、GLM、Kimi 这一类）收不到 thinking=off，想完就没额度写结果，回复是空的或 JSON 只写了一半，又被报成「不是约定的格式」。额度改成和证据裁判、核查同一档 16384，服务方嫌大时退回 4096（按接入和模型记在进程里、互相认），时限 20 秒放宽到 45 秒；结构化输出带原始回复，正文、工具调用参数里的 JSON 也认，<think> 里的草稿不算，正文里顺手写的 [1] 不算空结果；没成的原因照实分开说：被截断（带额度）、回复是空的、写了字却不是约定的格式，认不出的回复开头记进日志	2026-10-15 14:59:40 +08:00
ThearchyHelios	f0b66c2551	发布单的问题照实分清挡不挡发布：平台能力的治理默认在没人治理过时一直生效（在默认写好之前登记的 records_append 会停在「不许无人值守、没有查询能力」，填报登记出发布单时报写入不经确认、结果不明没人核实、要找管理员登记查询能力；管理员改过的同步不动）；发布摘要的三栏只列挡发布的问题，只是提醒的（视图要等第一次正式运行才有数之类）另列「提醒（不挡发布）」；确认按钮「每周一 09:00 自动出数」补上空格；检查脚本和测试跟上	2026-10-15 14:44:26 +08:00
ThearchyHelios	be845bb823	蓝图「看哪些数」对到的数据源和表要真的存在：卡片上照实说是哪一项、怎么改（bp.data_source_unknown / bp.data_table_unknown，带白话），挡住试运行和发布单，助手自查也拿得到；填报登记里本应用的记录表写 @records、表名固定，提示词和模板说明写明这个约定；「对到的表」改成从已接入的数据源和表里选，填报登记多一项「本应用的记录表」，卡片上照白话显示（以前要到试运行才报「绑定的工具不存在」，用户找不到在哪改）	2026-10-15 14:32:25 +08:00
ThearchyHelios	7739340607	普通用户建应用集成收尾： ... - 问数据和个人应用的图放行绑定只读查询等合规工具的调用工具节点，只读和遮罩在这条路径上生效；被治理成写入的工具在只读运行里直接拒；知识库范围在工具层固定（图级默认值、参数名纠错、Agent 都改不了） - 个人应用的刷新和个人蓝图的试运行只有拥有者能读：运行、事件、证据、工件、文件、运行与审批列表、对比、可验证报告、质询、假设分析、提取工作流一并收紧；个人蓝图的试运行不论谁发起都按个人应用约束 - 共享蓝图只给拥有者、对应应用的管理者、管理员，看不到的一律 404；审核副本归审核人；管理员看别人的个人应用只有元数据、可以归档 - 记录表跨版本汇总（只读挂载旧版本、按当前列 UNION ALL、各版本各自固定高水位，缺的版本照实写进印章）；停用前发起的运行可以继续写旧版本；更正沿用原提交人、更正人记审计 - 约定收口：待办种类 review、事件 file.extracted、表单错误 file、模板定义带示例与预置；前端类型一次补齐、去掉临时的局部类型；审核待办卡不再给打不开的链接；读附件事件有中文说法；检查脚本补断言	2026-10-15 13:55:19 +08:00
ThearchyHelios	277982ead3	普通用户建应用（后端）： ... - 蓝图：bp_* 操作和逐卡白名单、蓝图检查、留痕、按蓝图判权限；五个场景模板加自由形（骨架、关节、应用骨架、定时任务），实例化与骨架比对；BlueprintApplier / TemplateApplier（只收模板声明过的关节）与自查；look 新类别口径卡；蓝图对话和填关节两个流式接口，不同组的关节并行填、出错的组串行重试；模板列表 - 试运行与发布单：四种起点（对话、模板、问数据的一轮、已发布版本）；试运行是探索运行，草稿应用按这次运行解析、印章写试运行，流程类派给自己、不触发升级；发布单九步、预检只读、每步留痕、停下后接着做、核对卡片指纹和应用管理权、启动时整理中断的单；白话层覆盖全部问题编号 - 记录表与文件：平台托管只追加的记录表、按高水位固定数据、连接上的临时视图做行级可见、写入走动作（records_append）、表版本在发布时切换、草稿不影响线上、记录列表遮敏感列；文件按哈希存、两步上传、提交时绑定运行、下载按读权限、清理、file_text、按配方导入一期（table_import_period） - 个人应用：存成个人应用（问数据的约束）、刷新（遮罩、只读、每日上限）、只有拥有者看得见、提交审核与共享副本、开关下发到认人接口；页面编辑的候选；隐藏组件不下发；三条新检查	2026-10-15 12:09:29 +08:00
ThearchyHelios	7088f4557e	普通用户建应用的契约骨架（docs/design/normal-user-apps.md 第五部分）：蓝图、蓝图留痕、发布单、文件、记录表的模型和迁移，应用的 scope / owner / blueprint_id；运行来源加 trial、personal_app；应用描述的固定版本可以没有版本号（试运行派生的草稿）或改钉蓝图（个人应用），视图来源加 exploratory，组件加 hidden，表单加文件控件；agentlab.blueprint/1 与 bp_* 操作、agentlab.template/1 与关节类型的定义；实例化、试运行、发布单、个人应用、记录表、文件、白话层的接口签名；蓝图、模板、文件、个人应用、蓝图助手的路由桩（501）；前端约定 typesBlueprint.ts、接口桩、新建应用与蓝图页的占位路由、termsBlueprint.ts	2026-10-15 09:49:45 +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	bb85fbc3ce	应用检查：静态文字里的数和固定版本里节点配置写着的数（审批金额线、时限、会签人数这类流程规则）对得上算有出处，对不上的列出是哪几个数、说明数据要绑定、规则要先写进工作流；应用润色助手的提示词同步：规则在固定的版本里没有就不照写，在说明里告诉用户（真实模型验收发现）	2026-10-14 23:58:12 +08:00
ThearchyHelios	e2841cb027	助手按需查看：点名的一个都没认出来时（常见的是拿数据源说明里的中文词当表名），同一次查看按需求在那几个来源里挑，不让模型为拿真名再看一次，没认出来的照样写「没找到」；候选库一张表都没探查到时不再说「按需求没挑出来」，照实说尚未探查结构、不交空目录，查看算没完成；点名不在这一轮的数据源不补空目录（真实模型验收发现）	2026-10-14 23:58:12 +08:00
ThearchyHelios	49f6f42df2	测试：设置被整体拒收的两条断言改为比较请求前后的主题，不再假定同一测试进程里别的测试没改过它（并行全量时按顺序偶发失败）	2026-10-14 22:17:00 +08:00
ThearchyHelios	bff3062a97	集成收尾：前端约定写入后端实际返回的形状（应用详情只对 manage 给草稿、补算计划与结果、按名字的钩子行、能力字段审阅），去掉多种字段名都认的兼容解析；钩子按（应用, 名字）、应用助手对话按（应用, 建立人）加唯一索引，迁移前去重，插入改在保存点里、撞上就改用已有的那一行；口径卡固定的版本也须已发布且未退役，记级别之前有正式运行凭据的老版本启动时补记为已发布；证据面板和应用视图按列名遮端点快照（同一个函数），不再整张表遮掉；待办计数带上最新一条的时间，新待办通知不再漏；非管理员的搭建者不出模型接入的改动按钮	2026-10-14 22:08:33 +08:00
ThearchyHelios	d67349562a	应用平台集成（后端应用与流程）：身份断言 sub 为发起人、确认人进 act；应用助手对话（取或建、带历史）与助手润色只能改呈现；按新口径补算（只对无副作用的视图、加锁、同一输入只补一次）；钩子按名字关联、入站按发布版声明认；应用详情只对 manage 给草稿与岗位绑定；删工作流的阻挡算上已退役版本；待办恢复失败退回待处理；调用工具节点作证核对快照归属；子图固定版本须已发布且未退役（发起与发布检查都查）；视图里端点快照按能力的遮罩字段遮（含统一复核后的修复）	2026-10-14 21:55:51 +08:00
ThearchyHelios	acb9ae1774	应用平台集成（后端访问面）：开登录后使用者的问数据只能是探索运行、节点与工具白名单、查询结果在工具边界遮罩且数据源强制只读、记忆与知识库范围不能自选，运行流按运行判读权限；对话按建立人隔离（应用助手对话要 manage）；能力字段语义的审阅队列与批量审阅；按需视图每日上限登记为设置项；通用设置接口不再读写登录设置；运行带来源、按来源筛选，审批带待办 id（含统一复核后的修复）	2026-10-14 21:55:51 +08:00
ThearchyHelios	04ffce252a	集成：冻结文件按各包请求一次补齐——对话表加建立人（开登录后按人隔离对话）及迁移和索引，钩子回执、投递记录的状态注释；前端约定补待办的节点名与运行类别、生效记录的幂等键等字段、发布结果的级别与哈希、视图来源的种类、各组件数据形状的说明、钩子、助手的澄清问题与应用润色的请求和结束事件	2026-10-14 20:06:27 +08:00
ThearchyHelios	0f32b8335e	应用平台 BE-4 助手：按需查看（默认只给数据源概览、look 行停下执行接着写、一次拿齐、每轮 3+1 次、系统代为查看、查看记录进历史），生成过程可插拔（Applier / Checker 注入、ask 结束本轮），查看对象按类型标记并实现表 / 能力 / 工作流版本三种（表详情与 db_schema__、/schema 共用并按遮罩规矩），应用润色接口 /copilot/app-stream，从运行提取模板记来源，演示模型走一次查看（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	acdc9677a8	应用平台 BE-2 流程：待办服务（派给谁、any/all/quorum 汇总、条件 UPDATE 抢恢复、提醒升级超时驳回、审批接口改为垫片、存量补建），人工节点新配置与校验，写外部系统的动作流程（生效记录先写后发、确认卡哈希、结果未知挂起与核实、永不自动重发），重放豁免与升级安全测试，正式运行不许带图接着跑、接着跑不覆盖发起人（F2），运行来源，通知发送核心与渠道，入站签名钩子，process.* 检查，报销审批模板，假外部系统（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	00bd51b9a5	应用平台 BE-3 应用：「已发布且未退役」的唯一判定与版本退役，正式运行接受固定的已发布版本并核对 expect_hash（F1），口径升版只看已发布版本（F3），有应用固定或生效记录时拒绝删除工作流（F4）；表达式的根名字与禁止算术参数，表单子集校验与输入节点字段转换，应用对象、发布、版本、授权、页面解析与视图模型（三种来源、缓存、印章、证据指针、遮罩）、入口发起实例、应用操作、app.* 检查、确定性派生、账本只读接口、指标证据链接口（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	5dba66c2b6	应用平台 BE-1 治理底座：身份三种模式（off 默认 / local / oidc）、会话与 CSRF、中间件写入身份、角色与组与审计、按权限矩阵挂路由级依赖、运行与工件的读权限和 user 角色遮罩、reset-admin 找回；能力登记（同步、治理与乐观锁、发起快照、发布版本、作证判定）、登记的端点与平台执行器（分环境、演练、幂等头、身份断言、端点快照作证）、密钥加密与掩码、MCP 的 SSRF 与认证头、写入能力只进调用工具节点、正式运行里只读免审批的能力直接执行、四条 action.* 发布检查（含统一复核后的修复）	2026-10-14 20:05:23 +08:00
ThearchyHelios	c38c0043a4	契约骨架补充：运行路径上的能力登记函数给出和今天一致的默认实现（并行开发互不卡住），build_tools 加 allow_write 参数；前端补 ViewRenderer、PrincipalPicker 的接口桩和按草稿预览的参数	2026-10-14 17:56:54 +08:00
ThearchyHelios	8f64853bf6	契约骨架补充：launch_run 和 run_manager.start 接收运行来源（origin_kind、origin、app_id、app_version）和 expect_hash，来源记在运行上、run.origin 事件放进发起时的 notes（在封存范围内）	2026-10-14 17:54:58 +08:00
ThearchyHelios	220fd0e365	应用平台契约骨架：新表（身份、能力与端点、应用、待办与生效记录、通知）与迁移（补列、多列索引），运行来源与新事件类型，「人」的唯一入口 api/deps.py（关登录时行为不变），应用描述与表单的形状、受信组件目录 v1，各包跨包函数的签名桩，新路由登记，发布门禁的扩展钩子 EXTRA_LINTS；前端接口约定 typesApp.ts、各接口文件、SchemaForm / TaskCard 的 props 与最简实现、应用相关路由与占位页	2026-10-14 17:53:40 +08:00
ThearchyHelios	b149351960	导入目录：推断、有确证的项在校验之前去掉确认时的依据，手改过的文件里依据不合规也不再把整项跳过（照常只填空缺）；已确认、已驳回的项依据不合规照旧跳过	2026-10-14 16:11:04 +08:00
ThearchyHelios	a88fd93376	剖析不改人确认过的外键关系的基数：值不变、保存即确认的外键关系来源仍是 fk，以前 _patch_fk 不看状态，数据核实出的基数不同就直接改写，确认时的依据还挂着，前后矛盾；现在同 _patch_confirmed，不改人定的基数、也不标用数据核实过，测量的说法照常写进备注	2026-10-14 16:11:04 +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	a78affa2f1	目录修改提案落在已驳回的项上时，改前写出被驳回的原值：plan_patch 交回的 before 带上驳回的值、before_status 写 rejected（只改给人看的信息，算改后、算状态照旧按没有这一项，保存时照旧换成人工确认的新值）；助手流的提案卡片、表助手的提案卡片和待保存的修改写「已驳回：<原值>」，和导入预览「目标里这一项已经驳回」一致；check-catalog-loop、check-stream 补对应检查	2026-10-14 14:07:15 +08:00
ThearchyHelios	eb8d73b6da	表助手不再把数据源的起草要求当成使用者的原话：交给模型的背景里起草要求标明「不是这次对话里使用者说的话」，系统提示词和 propose_changes 的说明写清 reason 里引用的原话只能是这次对话里使用者的消息，依据来自起草要求时写「起草要求写着：……」	2026-10-14 14:07:15 +08:00
ThearchyHelios	20bef14520	保存目录修改提案时依据随项保存：表助手、助手流里「建议更新数据目录」的提案经 /catalog/{table}/patch 保存，写了依据的项备注记成「依据：……」（超出目录文字项的上限 500 字截断），没写依据的照旧；值不变、保存即确认的项和沿用了测量备注的关联关系，依据写在原来的备注前面（关联关系的剖析备注再剖析时整段换掉，放在前面才留得住）。表详情里人工确认的项有备注时也看得到：表级的项写在值下面（同有效记录条件的说明），列的一格、关联关系悬停看；check-catalog-loop 的假服务端照服务端记下依据，补保存后看得到依据、人工确认项的说明两处检查	2026-10-14 14:07:14 +08:00
ThearchyHelios	fc25c6367c	起草任务写进目录的项，修改时间取那一次写入的时间：宽表逐段落盘的每一段、整张表收尾各取一次当时的时间，不再整个任务都记成开始的那一刻（以前只在任务开始时取一次、截到秒，比任务的开始时间还早，也看不出哪一段是什么时候写进去的）；补一条用假时钟逐段核对的测试	2026-10-14 14:07:14 +08:00
ThearchyHelios	af0b0fa136	测试夹具：表助手和导入导出测试里虚构订单表的号码列改叫 buyer_phone（和仓库里其他虚构夹具一致）	2026-10-14 10:21:30 +08:00
ThearchyHelios	6baebe821a	合入数据目录闭环第一步（后端 B）：表助手（表详情页对话，流式返回，成批提出经校验的修改提案，只在开了剖析的源上经只读守卫跑查询、结果先遮）；审阅队列（按使用次数、风险、来源排序，批量确认驳回逐表乐观锁，表被哪些运行用过，审阅进度）；数据目录导出导入（先预览，确认和驳回的照带、冲突保留目标、推断只填空缺、对不上的跳过并写原因）；一次修改上限提到 200 项	2026-10-14 10:16:53 +08:00
ThearchyHelios	d3bd80211a	数据目录闭环第一步（后端 A）复核修正：没收下的有效记录条件不算失败，在起草任务逐表的 log 里记一句，接口看得到（以前只进服务端日志）——没通过校验的写原因（「有效记录条件里不能有子查询，模型提议的这一条没有收下：……」），剖析核对排除 0% 或 100% 的写数到了多少行；只在请模型写表级的项的那段里记，一张表最多 10 句。CatalogDraftTask 加 log 列（存量任务回填 NULL，接口给空列表）	2026-10-14 10:00:10 +08:00
ThearchyHelios	7383877ee7	数据目录闭环第一步（后端 A）复核修正：模型提议的有效记录条件存整理过的写法——原文照旧（NOT IN、IS NOT NULL 不被改写），只把列换成表结构里的真名、不带表名、按数据源的方言要加引号的加引号，剖析核对的就是存下的这一条。以前存的是模型的原文，核对时却按真名加了引号：PostgreSQL 上混合大小写的列（"OrderStatus"）存成 orderstatus <> 'X'，一跑就报列不存在，SQL 检查还会让模型照抄。列名先照原样对表结构，只差大小写的几列写不清是哪一列的不收；加了引号超过 500 字的不收（写进去会让整张表写入失败）；不合规的说法用界面上的叫法「有效记录条件」	2026-10-14 09:59:52 +08:00
ThearchyHelios	9c30bf0307	数据目录闭环第一步（后端 A）复核修正：起草提示里「已确认的目录项」不再带遮罩列的码值，人工确认过的也不给（码值就是这一列的取值），开没开剖析都一样；这一列别的确认过的项照给。和新加的码值背景、表助手的背景、导入目录的口径一致	2026-10-14 09:59:35 +08:00
ThearchyHelios	a490365bcf	数据目录闭环第一步（后端 A）复核修正：按比例止损只看每次调用的最终结局。服务方嫌额度太大退回 8192、结构化输出不支持或回了说明文字改走纯文本、429 / 5xx 退避重试之前的那次照旧记进用量和提醒，不进止损的窗口——它不花额度，也说明不了模型写不出来；重试用完仍出错的那一次照常算。以前额度上限 8192、不支持 json_schema 的 OpenAI 兼容网关上，并发的头几次调用全是这种重来，第一次额度用完就凑满 10 次里 7 次，那一段直接记没写出来、不再拆小	2026-10-14 09:59:19 +08:00
ThearchyHelios	813522ec7b	表助手：待保存的修改不设上限、有效记录条件按起草的规矩核对。宽表上逐列补中文名、含义，几轮下来待保存的修改常常超过一次保存的 200 项，以前请求里超过 200 项就 422、对话用不了；现在交多少都收，背景里只列最近的 200 项（界面上新的提案接在后面）并写明另有几项，码值照全部待保存的修改合并。模型提的有效记录条件是 SQL：按 sqlcheck.valid_filter_problem 核对（一个条件、只用这张表的列、不能有子查询、聚合、窗口、分号，只能用几个函数），sqlcheck 里还没有这条规矩时至少核对用到的列都是这张表的、都在表结构里、没有子查询，不过的不交给界面、原因交回模型；系统提示里先写明这几条写法	2026-10-14 09:52:37 +08:00
ThearchyHelios	9b4663afa8	导入核对有效记录条件用到的列：有效记录条件是表级的一项、却写着列名，按列跳过的规矩拦不住它。按目标数据源的方言解析出条件里用到的列，不在目标的表结构里、是别的表的列、带子查询（没法核对子查询用到的表和列）、解析不了或不止一句的跳过并写原因；人工写的条件不限函数，列名大小写和目标不同、带本表表名（文件里的写法、目标的写法都认）的照带。核对用的 filter_columns_problem 放在 catalog_transfer，表助手在没有起草的校验规矩时也用它	2026-10-14 09:52:13 +08:00