3 Commits

Author	SHA1	Message	Date
ThearchyHelios	87f0d62f9b	多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁	2026-10-19 11:40:33 +08:00
ThearchyHelios	aa3bd65cfc	W4-d 前端：数据目录页的「变化」视图、表详情「结构与取值变化」一节、后台任务条、数据源的角标和定时维护 ... 第 3 波的结构变化、取值观察、变化记录、定时维护都只有接口，这一提交给它们界面，能走通（收口）： - 数据目录页左栏加第三个视图「变化」（view=changes）：按要处理 / 提醒 / 说明分组（组内照服务端排好的先后），能按开着的 / 处理过的、结构变化 / 取值变化筛，筛选和打开的那一条记在地址里；视图标签上写几条要处理。点开一条，右栏写服务端的一句说法、 依据（谁、经什么测到的；取值变化写观察口径，结构变化写比对的两版结构）、前后各是什么、影响面（说到这些列的目录项和它们 现在的状态、写死了这张表的已发布模板、「这条 SQL 现在会报列不存在」、有效记录条件）、能做的处理。动作和做不了的原因都照 服务端给的 actions 画；清理目录项先确认，加入码值可以先填含义，误报必须写理由（写之前按钮不能点，服务端也会拒）。处理完 照实写结果：谁、什么时候、目录第几版、建了的任务（点得进起草、剖析的进度）。 - 表详情加「结构与取值变化」一节：这张表的变化（点「去处理」到「变化」视图里那一条）、撤销过的「已列全」、最近几次取值观察 （行数、码值分布、最新业务日期、按日行数）和各自的口径，口径换过的说一句不互相比较；按日行数的小柱图只给眼睛看，数字写在 字里和读屏名称里。 - 后台任务条（05 (g)）：页头的「起草」「数据剖析」改回纯入口（进行中转圈、排队中时钟，读屏名称写状态、不写数字）；DraftStrip 换成 JobStrip，按服务端给的同源队先后列出探查、起草、剖析，每项一行加进度条和提醒（剖析的「最近查询多数超时」也挪到这里， 窄屏、触屏看得见全文），「查看」打开对应的对话框，探查的到数据源卡片上（#source-<id> 滚过去）。 - 数据源卡片：要处理的变化条数的角标（读屏写全，点开到「变化」视图）；「定时维护」对话框（和「探查范围」一样是卡片上的 独立对话框，不塞进编辑表单：两个保存混在一起出错时说不清哪一样没存上）：开关缺省关、开启时提示选低峰时段，选步骤（PUT /maintenance），频率用 components/FreqPicker，保存成一条 target_kind=source_maintenance 的定时任务（新建 ScheduleTargetCreate， 改频率、开关 SchedulePatch 带版本）；照实写下一次什么时候、最近一次建了哪些任务、哪几步没执行和原因（触发记录的 inputs）， 剖析没开、调度没开时说到点会怎样。上传表格、记录表不给这一节。开着的维护在卡片上带一个标签写频率。 - 地址里带 pjob / djob 时打开那个剖析、起草任务的进度（定时维护的「最近一次」从数据源页链过来）。 新文件：typesSource.ts（接口约定）、api/sourceChanges.ts、lib/termsSource.ts（terms.ts 末尾转出）、pages/catalog/changes.ts、 ChangesQueue.tsx、ChangeDetail.tsx、TableChanges.tsx、JobStrip.tsx、pages/SourceMaintenanceDialog.tsx。变化的叫法和服务端逐字 一致，tests/test_source_change_terms.py 守着（维护步骤的叫法同样）。观察的按日行数服务端补上窗口里没数据的日子（不然小柱图 看不出断档）。	2026-10-16 19:46:14 +08:00
ThearchyHelios	238330b9c1	W4-d 后端：给目录前端的变化、观察、后台任务、定时维护接口补齐界面要的几样；打开 source.changed 的订阅 ... 第 3 波的变化接口只给了 agentlab-change/1 的原样，界面要的几样（能不能做、依据什么、现在怎样）如果让前端自己判，就违背 「界面层不放逻辑」。这一提交由服务端给出，界面只照写： - 变化列表、单条、处理的回答里每条另带 category（结构 / 取值）、basis_text（依据的口径，照观察时记下的写整表、窗口、块采样、 按存储顺序的前 N 行）、actions（现在能做哪几个处理动作，做不了的写原因：剖析没开、表结构里没有了、影响面里没有目录项）、 job（处理时建的任务，界面能点进进度）、影响面里每个目录项现在的状态（清理过、改过的照实）。召回拉的 list_changes 不带这些。 - 列表能按 category 筛（和 kind 一起给时取交集，一种都对不上就是空的，不是不筛），能按 status=handled 看处理过的（最近测到的 在前：处理过的不再按要不要先处理排）。 - GET /api/datasources/upkeep：数据源列表一次取齐各源要处理的变化条数（卡片角标）和指向它的维护定时（频率、开没开、下一次）。 - GET /{id}/observations：表详情「结构与取值变化」一节的最近几次观察，各带口径；码值的占比、按日行数的合计由服务端算；现在 被遮罩的列（观察时还没遮的）整组不给，遮罩在读的那一刻再核。 - GET /{id}/background-jobs：这个源进行中和排队的探查、起草、剖析，按同源队的先后排好（05 (g)：排队顺序取服务端的，界面 不自己排），各带 waiting_for。 - GET /{id}/maintenance：维护定时换成定时任务页同一个形状（改频率、开关照样带 version 走 PATCH），最近一次触发带 inputs （建了哪些任务、哪几步没执行和原因），另说调度开没开、这个源要不要维护（上传表格、记录表不要）。 - notify：source.changed 打开订阅（只推全局渠道，按源汇总不归哪个人），链接落到目录页的「变化」标签页。 test_notify_events 里 W4-d 那一行加上；test_source_changes 里原先假设订阅没开的那句改成「没有渠道订阅时推不出去」。 data/source_changes.py（W4-a 的文件）只在末尾加了 available_actions、counts_by_source、list_handled 和 HANDLED； data/catalog_profile_observe.py 末尾加了 key_text、recent。新测试 tests/test_source_upkeep.py。	2026-10-16 19:31:21 +08:00