 ThearchyHelios
|
0d9f1d9339
|
用户看得到的列表补决胜键（复核 R-a9）：按名称、时间等可能并列的排序后面补上同一个模型的 id，并列时两种库排出来一样
- 实测 /api/evals/calibers、/api/schedules/trigger-options 按 Workflow.name 排序遇同名并列时 SQLite、PostgreSQL 顺序不同。用 AST 逐个过了一遍 order_by：最后一个排序键是 created_at / updated_at / last_active_at / at / name / 各种 *_at 之类、不唯一的列，又不带 DISTINCT、GROUP BY 的，补「, 模型.id」（降序补 id.desc()），共 104 处，分布在 api、apps、auth、blueprints、chat、data、engine、eval、ledger、look、memory、process、providers、scheduler（runs.py 里的三处在上一个提交里）
- 按唯一列（seq、version、唯一的 name）排的不动；按聚合、coalesce 之类表达式排的说明见 db/postgres
|
2026-10-19 12:07:06 +08:00 |
|
|
ThearchyHelios
|
e5003a1d46
|
W3-d 复核 L2：使用者列通知渠道时拿不到全局、应用邮件渠道的收件地址
复核发现：GET /api/notify/channels 对使用者照样列全局、应用渠道（应用的通知里要挑渠道，只用名字和 id），而邮件渠道的
mail_to 给的是全部收件地址原文；channel_out 的说明却写着「搭建者以上才看得到」。Webhook 渠道只给主机名，邮件渠道多露了
一层：任何使用者都能拿到内部的收件名单。
做法：channel_out 加 recipients 参数，list_channels 按 _can_edit 的同一条规矩判（关登录时谁都能改，开了登录要搭建者
以上）：改得了的照原样给 mail_to（改地址要整份重填），改不了的只给条数 mail_count。个人渠道照旧写发到自己的账号邮箱。
建、改渠道的返回本来就只给能改的人，照旧。说明同步改；前端 typesApp 的 NotifyChannelRow 加 mail_count（设置页的
通知只给使用者列个人渠道，界面上用不上，不加入口）。
测试（tests/test_notify_mail.py）：开登录，使用者列渠道时全局、应用的邮件渠道照样在、没有 mail_to、只有条数，自己的个人
渠道照常；搭建者看得到地址。去掉修复回跑，这一项失败。
|
2026-10-16 18:20:52 +08:00 |
|
|
ThearchyHelios
|
86d2840e41
|
W3-d 邮件渠道、待办汇总、访问密钥到期提醒（后端）
邮件（04 细案 B2，集成-I4 / I5，改写应用平台 Q6）：
- notify/mail.py：标准库 smtplib 放进 asyncio.to_thread，单次超时 10 秒；4xx 和连不上按 1/2/4 秒重试，5xx 不重试；
报错只写主机名和服务器回话，口令一律抹掉；纯文本 + 转义过的 HTML，带 List-Unsubscribe 和 Auto-Submitted；测试可换假的
SMTP 工厂。模块说明写清改写 Q6 的理由：SMTP 是可选配置、退信不追踪照实说「已交给邮件服务器」
- 通知渠道多一种格式「邮件」（core.CHANNEL_FORMATS；定时任务的 Webhook 只会发 HTTP，FORMATS 不加，免得定时任务能选
邮件）：个人邮件渠道不收地址，只发到名录里的账号邮箱，没有邮箱记一条失败投递并写明去「设置 → 身份」填；全局、应用的填
固定地址，最多 20 个；邮件服务没启用时不收新的邮件渠道；渠道列表另给 mail（启没启用、本人的账号邮箱），投递记录带格式
- 设置的 mail 一组（只有管理员能改）：口令用 core/crypto 加密，读的时候只说配没配；启用时要配全；发件人名称、主机不许
换行；「发测试邮件」只发到管理员自己的账号邮箱，关登录、没有邮箱时 422 说清怎么办
- mail.default_for_assignees（缺省关）：开了之后第一次派到待办的人自动有一个个人邮件渠道（订阅待办打开、动作结果未知、
审核有结果），本人删了不再建回来；关登录时不建
待办汇总与密钥到期（04 细案 B3）：
- notify/digest.py 接进调度循环的步骤列表：每天到 notify.digest_at（缺省 09:00，服务端时区）给订阅了 task.digest 的
个人渠道发汇总（条数、最早时限、最多 5 条节点名、去待办箱的链接，没有待办不发）；按日期在 settings 表里插一行认领，
重启不重发；认领行和自动建邮件渠道的名单是通知自己记的账，设置接口不列不收
- key.expiring：到期前 7 天、1 天各推一次，个人密钥推本人的个人渠道、服务账号的推全局渠道，推之前记审计、按审计去重；
轮换下来的旧密钥、撤销了的、建的时候就在这一档里的不推
- 两个事件推送实现了，才在 notify/service.EVENTS 打开它们的订阅范围
设置的 notify 一组加 digest_at；只给一部分时补上存着的另几项；环境变量锁住对外访问地址时只核对那一项，汇总时间照常能改。
apps 一组加 share_links（分享链接的开关，缺省关，下一个提交用）。测试：假 SMTP 工厂下的收件人、失败投递、重试、口令、
设置与权限、自动建渠道；汇总按时、只发一次、重启不重发；密钥两档、谁收、不该推的几种。
|
2026-10-16 16:21:41 +08:00 |
|
|
ThearchyHelios
|
479cec0af7
|
通知事件一次登记（总方案 X6、5.1）：六个新事件进 notify/service.EVENTS，推给哪几条路也登记在那一处
复核指出 X6 漏做：第 2、3 波的数据源变化、口径召回、评测、触达四块都要往 EVENTS、EVENT_LABEL 和前端设置页的事件列表里
加东西，正是 X6 要避免的同一处多方冲突；消息里能放什么也没有一处先定好。
做了什么：
- EVENTS 改成登记表：每个事件一行，叫法 + 推给哪几条路（scopes：global 全局渠道自己订阅、user 相关的人自己的个人渠道、
app 应用版本 spec.notify 的订阅）。本轮新登记 source.changed、ledger.recall、eval.regressed、eval.failed、task.digest、
key.expiring，scopes 都是空的——登记了、还没有推送。实现推送的那一块只改自己那一行的 scopes（各行之间隔着说明行，几块并行
改也不会挨着冲突），前端叫法表不用再动。EVENT_LABEL 从登记表派生，老的 import 不变。
- 模块说明写清消息结构：标题、状态、条数、链接，加编号和搭建时起的名字；不放报告和答案里的数、表名、列名、取值、SQL、
按运行数据渲染出来的句子。
- _channels 只走事件登记了的路；没登记的事件直接报错（推送之前先登记）。现有五个事件登记的路照现在的做法，行为不变。
- 接口：订阅按登记核对（subscribe_problem）：没推送的「还没有推送，暂时不能订阅」，范围不对的「不推给范围是「应用」的
渠道」。只核对这次新勾的：以前存下的照旧，开关、改名不会因此 422。GET /api/notify/events 多给 scopes（空的照实给）。
- 前端：terms.ts 的 eventLabel 和 EVENTS 一一对应、逐字一致，六个新事件先有叫法；设置页的渠道编辑框、应用的通知改按
GET /api/notify/events 列（这种范围收得到的才列，已经勾着的照样列出来能取消；取不到时照实说）。
顺带修掉的（就在要改的那张列表上）：设置页以前按前端叫法表的键列事件，里面有五个服务端从来不认的（待办升级、待办超时、
待办处理完、动作失败、动作已生效），一勾保存就 422；改派、升级、催办只在投递记录里出现，另起 deliveryEventLabel（加上测试
消息），记录里照实写是哪一种。服务端 EVENT_LABEL 的四句老叫法（有待办派给我、实例完成、实例失败、写入结果未知）改成和界面
同一句，界面上看到的字不变。
验证：新增 test_notify_events（登记表、前后端逐字对照、接口拒收、只走登记了的路），去掉 _channels 的按路过滤或「只核对新勾
的」回跑各有一项失败；check-capabilities 加一段「可订阅的事件照服务端登记列」，把列表改回按叫法表的键列，四项失败。
|
2026-10-16 12:12:14 +08:00 |
|
|
ThearchyHelios
|
acdc9677a8
|
应用平台 BE-2 流程：待办服务（派给谁、any/all/quorum 汇总、条件 UPDATE 抢恢复、提醒升级超时驳回、审批接口改为垫片、存量补建），人工节点新配置与校验，写外部系统的动作流程（生效记录先写后发、确认卡哈希、结果未知挂起与核实、永不自动重发），重放豁免与升级安全测试，正式运行不许带图接着跑、接着跑不覆盖发起人（F2），运行来源，通知发送核心与渠道，入站签名钩子，process.* 检查，报销审批模板，假外部系统（含统一复核后的修复）
|
2026-10-14 20:05:23 +08:00 |
|
|
ThearchyHelios
|
220fd0e365
|
应用平台契约骨架：新表（身份、能力与端点、应用、待办与生效记录、通知）与迁移（补列、多列索引），运行来源与新事件类型，「人」的唯一入口 api/deps.py（关登录时行为不变），应用描述与表单的形状、受信组件目录 v1，各包跨包函数的签名桩，新路由登记，发布门禁的扩展钩子 EXTRA_LINTS；前端接口约定 typesApp.ts、各接口文件、SchemaForm / TaskCard 的 props 与最简实现、应用相关路由与占位页
|
2026-10-14 17:53:40 +08:00 |
|