 ThearchyHelios
|
77cd95901a
|
完整关口收尾：端点认证头重名只标后加的那一行（原有的那行本身没错）；check-apps 实例状态只认状态标签本身（标签里嵌着带 data-status 的图标）；check-app-editor 选人输入框挂了候选列表，角色是 combobox，按输入框定位
|
2026-10-15 07:27:57 +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
|
5d42ffb62b
|
check-auth：会话过期时认人接口也回 401（同服务端，不然登录页认得出人又送回原处、来回跳）；过期后点页签只为触发取数，外壳心跳先收到 401 已经跳走时点不到不算错，核对的是跳到了登录页并带上原处
|
2026-10-15 00:07:51 +08:00 |
|
|
ThearchyHelios
|
bb85fbc3ce
|
应用检查：静态文字里的数和固定版本里节点配置写着的数（审批金额线、时限、会签人数这类流程规则）对得上算有出处，对不上的列出是哪几个数、说明数据要绑定、规则要先写进工作流；应用润色助手的提示词同步：规则在固定的版本里没有就不照写，在说明里告诉用户（真实模型验收发现）
|
2026-10-14 23:58:12 +08:00 |
|
|
ThearchyHelios
|
e2841cb027
|
助手按需查看：点名的一个都没认出来时（常见的是拿数据源说明里的中文词当表名），同一次查看按需求在那几个来源里挑，不让模型为拿真名再看一次，没认出来的照样写「没找到」；候选库一张表都没探查到时不再说「按需求没挑出来」，照实说尚未探查结构、不交空目录，查看算没完成；点名不在这一轮的数据源不补空目录（真实模型验收发现）
|
2026-10-14 23:58:12 +08:00 |
|
|
ThearchyHelios
|
c6a29bfd7c
|
前端：审批卡按审批当场拼出待办（不再为一张卡取一次待办，收到中断就出卡；有 task_id 走待办接口，没有走老的审批接口）；矮窗口导航两档高度不再叠加，480px 放得下九项；待办数随目录启动时就取、外壳订阅时当场记底，派给自己的新待办通知不再漏；头一回取目录的卡住从启动算起；外壳横向裁掉悬停提示的占位；证据抽屉同一指标在取时不另发请求；编辑器去掉第二个 main、检查一次只跑一遍；记录页对不上待办的审批照旧画审批卡，待办行写 runName 和节点名；检查脚本按新页面更新断言（沙箱没有待办时用合成的两条、未保存与已删除工作流分开认、生效记录页签、能力子页签）
|
2026-10-14 23:57:43 +08:00 |
|
|
ThearchyHelios
|
49f6f42df2
|
测试：设置被整体拒收的两条断言改为比较请求前后的主题，不再假定同一测试进程里别的测试没改过它（并行全量时按顺序偶发失败）
|
2026-10-14 22:17:00 +08:00 |
|
|
ThearchyHelios
|
c86e58f464
|
README 与部署说明：应用（怎么生成、能做哪几类、视图与印章、流程与待办、写外部系统、入站钩子、按新口径补算、升级安全）、身份与权限（三种登录方式、会话、找回、角色与授权、使用者的问数据、遮罩的边界）、能力登记与端点、助手按需查看；默认不开登录的说法、核心能力表、数据目录与遮罩、节点类型、安全边界、检查项（33 项另加 check-auth）、从旧版本升级；部署配置模板加登录一节
|
2026-10-14 22:12:01 +08:00 |
|
|
ThearchyHelios
|
bff3062a97
|
集成收尾：前端约定写入后端实际返回的形状（应用详情只对 manage 给草稿、补算计划与结果、按名字的钩子行、能力字段审阅），去掉多种字段名都认的兼容解析；钩子按（应用, 名字）、应用助手对话按（应用, 建立人）加唯一索引，迁移前去重，插入改在保存点里、撞上就改用已有的那一行；口径卡固定的版本也须已发布且未退役，记级别之前有正式运行凭据的老版本启动时补记为已发布；证据面板和应用视图按列名遮端点快照（同一个函数），不再整张表遮掉；待办计数带上最新一条的时间，新待办通知不再漏；非管理员的搭建者不出模型接入的改动按钮
|
2026-10-14 22:08:33 +08:00 |
|
|
ThearchyHelios
|
1dd4f93579
|
应用平台集成（前端）：钩子按名字管理并只显示一次密钥、按新口径补算、应用助手对话历史、设置页按角色收起与身份设置补管理员用户名、按需视图每日上限、界面偏好按角色只存本地、使用者问数据用数据源名单并在运行流连不上时改轮询、能力字段待审阅、记录页按来源筛选与待办 id、编辑器的入口 / 表单 / 待办外观 JSON 分区、画布 ?publish=1、工具页绑定端点与 MCP 认证头掩码编辑、派给自己的新待办系统通知、样例与检查脚本改走待办接口（含统一复核后的修复）
|
2026-10-14 21:55:51 +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
|
e341beb1cb
|
应用平台 FE-6 搭建面：应用编辑器（固定版本、派生、页面树与属性面板、预览、检查、发布时选处置、岗位与授权、钩子、通知、助手面板），人工节点新字段与写入动作说明，发布弹窗与版本页的退役和使用情况，记录页的来源、待办与动作事件、生效记录，发起表单换成表单渲染器并带来源，问数据「做成应用」，look 的界面与 meta.looks，工具页的能力与端点，设置页的身份、通知、审计；检查脚本的更新与新增（含统一复核后的修复）
|
2026-10-14 20:05:23 +08:00 |
|
|
ThearchyHelios
|
22021e76c3
|
应用平台 FE-5 使用面：表单渲染器与子集校验、待办卡（会签进度、动作确认哈希卡、核实选项）、视图渲染与组件目录 v1 的渲染器（印章、指标点开出处、趋势与图表、表格、报告）、应用首页 / 应用页 / 发起 / 实例 / 待办 / 登录页、导航加「应用」与徽标按来源分开、按角色收起导航、401 跳登录与请求头；新检查脚本 check-apps、check-inbox、check-auth（含统一复核后的修复）
|
2026-10-14 20:05:23 +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
|
fc002bd3b3
|
README：检查数改成 29 项并在分类里列上 catalog-loop；功能概览的数据目录一行补上表助手、审阅队列、导出导入；对话里纠正一行写明理由记为这一项的「确认时的依据」
|
2026-10-14 16:26:59 +08:00 |
|
|
ThearchyHelios
|
6dbe4ade17
|
合入数据目录闭环第一步：表助手（表详情页对话完善一张表，成批提出经校验的修改提案、拿不准的反过来问，只在开了数据剖析的源上经只读守卫跑查询、结果先遮，确认后一次保存并把依据另存为这一项的「确认时的依据」）；审阅队列（按使用次数、风险、来源排序并写明理由，批量确认驳回逐表乐观锁，表被哪些运行用过，审阅进度）；数据目录导出导入（先预览，确认和驳回的照带、冲突保留目标、推断只填空缺、对不上的跳过并写原因）；起草时提议有效记录条件和去重规则（sqlglot 校验，开了剖析的源上核对排除比例）；起草遗留：宽表逐段落进目录、停止和中断不丢、按比例止损、块进度、同步起草与任务双向互斥；剖析不改人确认过的外键关系的基数
|
2026-10-14 16:24:11 +08:00 |
|
|
ThearchyHelios
|
a2342c1459
|
合入数据目录闭环第一步验收后的修正：保存修改提案时确认的依据另存成每一项的 reason（不再拼进备注，改值、确认、撤销审阅各有去留，导出导入照带，表助手背景标明是以前确认时的依据）；表助手分清起草要求和使用者原话；起草逐段写入各取当时的时间；审阅队列列表头计数跟着审阅更新；导入完成只数真正写入的表；提案落在驳回项上时改前写出驳回的原值；剖析不改人确认过的外键关系的基数；导入时推断项的依据在校验前去掉
|
2026-10-14 16:11:04 +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
|
085fcb7e81
|
助手流「建议更新数据目录」那一行展开的明细，改前改用和卡片同一个写法（patchBeforeText）：提案落在已驳回的项上时写「已驳回：可累加 → 存量」，不再写成像是当前值的「可累加 → 存量」、和同一轮下面卡片的「已驳回：可累加」对不上；check-decode 补一条
|
2026-10-14 15:38:22 +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
|
cdf5ed38ef
|
导入目录完成的提示只数真正写进去的表（有新增或更新的项、版本前进了），文件中的项这里都有了的表不算、逐表写「没有变化」；一张都没写进去时说清「没有需要写入的内容」，写入出错的表另外说明；导入之后只重新载入写进去的表；check-catalog-loop 补导入结果的检查
|
2026-10-14 14:07:15 +08:00 |
|
|
ThearchyHelios
|
6b94811bed
|
审阅队列成批审阅之后列表头的「N 项待确认」跟着变：总数减掉列表里已经不是推断的项（成批审阅、表详情里改过的），撤销审阅回到推断的、冲突的照算，和视图标签、按表筛选的计数同一个口径；载入下一页的偏移用同一个算法；check-catalog-loop 补纯函数和成批确认、撤销审阅、单项确认、刷新之后的计数检查
|
2026-10-14 14:07: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
|
5880af465e
|
check-catalog、check-catalog-loop：关页面之前先撤掉拦截、忽略还在路上的那几条，取真实设置的拦截在页面关掉之后才回来时不再把检查进程带崩（满负荷并行时偶发「Request context disposed」）
|
2026-10-14 10:37:26 +08:00 |
|
|
ThearchyHelios
|
af0b0fa136
|
测试夹具：表助手和导入导出测试里虚构订单表的号码列改叫 buyer_phone（和仓库里其他虚构夹具一致）
|
2026-10-14 10:21:30 +08:00 |
|
|
ThearchyHelios
|
5b5b6d8df2
|
起草逐表行列出服务端记下的说明（task.log：没收下的有效记录条件和原因），check-catalog 补一项；README 数据目录一节补上防错事实的提议、审阅队列、表助手、导出与导入，模型起草一行写上逐段落盘、不设总时长上限与按比例止损、块进度、同步起草与任务互斥
|
2026-10-14 10:19:18 +08:00 |
|
|
ThearchyHelios
|
3d075e5432
|
合入数据目录闭环第一步（前端）：表详情页的表助手面板（流式对话、只读查询、提案、待保存的修改一次保存）、用过这张表的运行、有效行过滤与去重规则的说明；审阅队列视图（排序、筛选、批量审阅、冲突、进度）；导出、导入预览与导入；起草的块进度、已写进目录的段、停止后的留空提示；新检查 check-catalog-loop
|
2026-10-14 10:16:53 +08:00 |
|
|
ThearchyHelios
|
6baebe821a
|
合入数据目录闭环第一步（后端 B）：表助手（表详情页对话，流式返回，成批提出经校验的修改提案，只在开了剖析的源上经只读守卫跑查询、结果先遮）；审阅队列（按使用次数、风险、来源排序，批量确认驳回逐表乐观锁，表被哪些运行用过，审阅进度）；数据目录导出导入（先预览，确认和驳回的照带、冲突保留目标、推断只填空缺、对不上的跳过并写原因）；一次修改上限提到 200 项
|
2026-10-14 10:16:53 +08:00 |
|
|
ThearchyHelios
|
17a0ab53bf
|
合入数据目录闭环第一步（后端 A）：宽表逐段落进目录、停止和中断不丢已写的段；止损按最近调用的失败比例、同表接连 3 段没写出来就跳过剩下的段；块进度；停止后保留留空提示；「已拆小重试」只说拆过的段；同步起草与后台任务双向互斥；起草时提议有效行过滤和去重规则（sqlglot 校验、开了剖析的源上核对排除比例、遮罩列的码值不给模型）
|
2026-10-14 10:16:52 +08:00 |
|
|
ThearchyHelios
|
1d59ba23dc
|
数据目录闭环（前端）复核修正（表助手）：保存撞上 409 后只按预览重算交去保存的那几项，保存、重算期间回答里又到的提案原样留着、不再被当成不合法悄悄去掉，提案到了也不把正在进行的保存翻回可以点；交给助手的待保存的修改最多 200 项（服务端同一个上限，多了整个请求 422），超出时只交最近的 200 项；开场的留空列取那次起草记下的列名（从那次起草任务里这张表的 blank_sample 取），没写出来的列不再当成留空的列举例，「补上留空的 N 列」点名的正是这 N 列，记全了时只算还没补上的；拿不到（最近一次停止了、任务不在了、老服务端没有列名）时改说「目录里还有 M 列没有中文名和含义」，按钮上的数字就是点名的列数；只读查询后面还有行时写「取回前 50 行，后面还有」，不说成结果一共 50 行；check-catalog-loop 的假事件流照服务端夹 SSE 注释行（「: keep-alive」），提案带 source、table_label，出错码用 assistant_*，假服务端照服务端的上限回 422，补回答进行中保存撞上 409、留空列的三种出处、待保存超过 200 项接着问的检查
|
2026-10-14 10:10:38 +08:00 |
|
|
ThearchyHelios
|
299224acaf
|
数据目录闭环（前端）复核修正（审阅队列）：每一项的位置按 path 说到列（「列 ticket_no 的度量类型」「表的有效记录条件」「指向 members 的关联关系」，同提案卡片），复选框的读屏名也写到列——服务端的 field_label 只是字段的叫法（「码值」「中文名」），列名另放在 column，列级的项只写它分不清是哪一列；审阅进度三行同一个口径：已确认 ÷（已确认 + 待确认），已驳回的、有确证的不计入，审完了就是 100%，悬停写明口径；常用表写实际几张（服务端只算被运行用过的），没有时写「还没有运行用过的表」，不再写死「常用 20 张表」；「用过这张表的运行」写「共 N 次运行」并说明和表头按查询算的使用次数不是一个数，队列里使用次数的悬停同表清单；check-catalog-loop 的队列、进度、导入预览夹具照服务端的真实形状（field_label 只写字段名、带 column，reasons 用服务端的说法，进度带 items_proposed，导入报告带 version、error、冲突的状态），补位置、进度口径的纯函数和页面检查
|
2026-10-14 10:10:07 +08:00 |
|
|
ThearchyHelios
|
dff53db165
|
数据目录闭环（前端）复核修正：停止、服务重启中断之后「只重试这些表」写明会重新起草整张表、已写进目录的内容不会丢，不再说「接着起草剩下的段」——服务端的重试不跳过已写进的段，宽表重试花的时间和额度和第一次差不多；check-catalog 的假服务端中断时照服务端写「已中断：已写进目录 N 段，剩下 M 段没起草」，补一条中断的宽表只写一遍已写进几段、提示写明会重新起草整张表
|
2026-10-14 10:06:42 +08:00 |
|
|
ThearchyHelios
|
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 |
|