docs(changelog): 修正表述笔误
refactor(cordis): 磁盘缓存改用上上游能力并清理本地副本
按上游/下游归属规约:类型断言守卫已回流 Wavelet(f3d85d5,附回归用例),
本仓库删除 OpenFlare/plugins/server/pkg/cache 整包并改 import 到
Wavelet/pkg/cache/disk,同步后与上游零漂移。
验证:go build 通过;go test ./... exit 0(137 包 ok);256 条路由对拍与
232 条 swagger 操作均零差异;make build-all 四进制;前端零改动。
docs(cordis): 记录 T1 清理结果与五个复用阻塞点
refactor(cordis): server 复用上游 pkg 能力并删除等价本地副本
按上游/下游归属规约清理重复实现,删除 7 个与上游等价的本地包并改 import:
shared/response→pkg/response、pkg/{logger,mail,trace,httppool,cache/ram}→
上游同名包、infra/persistence/batchwriter→pkg/batchwriter。逐项核过差异:
httppool 逐字节相同;logger 的 Config 字段完全一致;response 的 7 个 Abort*
一致;cache/ram 换过去顺带把裸 go 变回带 panic 恢复的 util.Go。
两处非等价差异按语义处理:
- batchwriter.Stats 与 status DTO 原为类型别名,改为消费侧逐字段转换,
避免 model 反向依赖基础设施类型;
- 上游 pkg/idgen 要求显式 Init(本地副本为懒加载自动初始化),本次保留本地
副本,待与 infra 初始化一并迁移(已登记在清理计划)。
验证:go build 通过;go test ./... exit 0(138 包 ok);256 条路由对拍零差异;
make swagger 232 条操作零增减,且归一化后与旧文档深度相等——差异仅为
response.Any / logger.LogEntry 两个定义名随包路径改名,接口形状未变。
chore(cordis): 回流内核与 pkg/util 通用能力并清理 vendoring 污染
按新增的上游/下游归属规约:HandleRaw/BasePath 与版本比较、网络、格式化助手
属通用能力,已提交到 Wavelet 分支 feat/cordis-router-raw-routes,本仓库改为
纯同步获取(pkg/util 已零漂移),补丁登记保留至上游合并。
同时修掉我此前 git add -A 造成的污染:首次 vendoring 把上游工作区里被
gitignore 的运行期产物一起提交进来(upload 的 diskcache 缓存块 650 个与
driver_http/dist 前端构建物 380 个,共 12872 行/1030 文件)。sync-upstream.sh
现显式排除 uploads/dist/data/*.db,.gitignore 补上对应兜底规则。
AGENTS.md 增加上游/下游改动归属规约,并把仍指向前 Cordis 布局的硬性约束
(internal/router + Serve、internal/repository/logstore、internal/platform/bootstrap、
internal/cmd)改到当前插件路径。
验证:go build 通过;go test ./... exit 0(144 包 ok);make swagger 232 条
操作与基线逐条一致;make build-all 四进制;gofmt 干净。
feat(cordis): server 插件化并改由内核挂载控制面路由
新增 plugins/server/plugin.go:Apply 以 ctx.Router().Group(app.api_prefix)
声明根级与 /v1 全部路由;33 个注册函数由 *gin.RouterGroup 改为
core.RouterExtension,RegisterCollection 改用内核新增的 HandleRaw 保留
尾部斜杠变体,AdminMiddlewares 返回 []any(Go 不允许把 []T 展开为 ...any)。
删除 router.Serve 与 registerRoutes,装配根改为 core.App +
driver_http.New(WithEngine(router.BuildEngine())),监听、信号与优雅退出归内核;
前端 SPA 的 NoRoute 兜底因内核暂无贡献点而保留在引擎层。
路由保真证据:plugin_parity_test 对拍 baseline/routes-engine.txt 的 256 条
(方法 路径) 零差异;go test ./... exit 0(144 包 ok,含真实 handler 的
openflare/integration 用例走同一条挂载路径);make swagger 232 条操作与基线
逐条一致;golangci-lint 0 issues;make build-all 四进制;embed_frontend
标签编译通过;前端零改动。
已知待补:带 Redis 的实机 HTTP 冒烟(本机 6379 未启动,session store 与
改造前一样在建店阶段即 fatal),以及 bootstrap 的任务/设置/迁移注册迁入 Apply。
feat(core): RouterExtension 增加 HandleRaw 与 BasePath 以保真尾部斜杠路由
server 插件化的前置:Handle 经 cleanPath 会剥掉尾部斜杠,无法表达
/resource 与 /resource/ 两条不同路由,而 OpenFlare 有 20 个历史 list
端点两者都注册且部署关闭了 RedirectTrailingSlash,缺失即 404。新增
HandleRaw 与 BasePath(作用域包装器同样登记反注册),补 extpoints 用例;
并把 router.Serve 拆出 BuildEngine 以便交给 driver_http.WithEngine 复用,
新增路由表导出 harness,固化 256 条 (方法 路径) 基线供插件化对拍。
上游补丁登记于 backend/OpenFlare/upstream-patches.md,同步脚本改为按目录
前缀输出差异并在同步后提醒确认补丁是否仍在。
验证:go build 通过;go test ./... exit 0(143 包 ok);gofmt 干净。
docs(cordis): 记录 server 插件接入内核的可行路径与内核能力缺口
feat(cordis): agent/relay/flared 落地为内核驱动插件
三个边缘守护进程各新增 plugin.go,实现 core.Plugin + core.Driver
(自定义 DriverType 与同名 profile),装配与生命周期从 main 迁入
Apply/Start/Stop:Apply 负责 JSON 配置加载、运行环境与用户确保、
openresty/frps/frpc 管理器与各服务装配;Start 以 util.Go 拉起阻塞式
runner 与 GeoIP 周期更新;Stop 收敛主循环结果并在超时时报错而非静默。
入口改为 core.NewApp(core.WithProfile(...)) + Prepare/Run,保持
-config 旗标、默认路径、退出码与启动/停止日志不变。
验证:go build 通过;go test ./... exit 0(143 包 ok,含 3 个插件身份
与配置失败路径测试);make build-all 四进制产出;三进制实跑缺失配置
均 exit 1 且错误链保留 load {agent,relay,flared} config 原因;gofmt 干净。
refactor(cordis): 按功能职责拆分为 4 个插件与 share 共享层
backend/OpenFlare 不再平铺遗留分层,改为 plugins/{server,agent,relay,flared}
加 share/:控制面业务(openflare/admin/oauth/user/upload/cap/config/health 与
repository/model/infra/router 等支撑层)归 server;三个边缘守护进程各自成插件;
被两个以上插件消费的 protocol/geoip/wsclient/render/pagesarchive/edge 归 share。
同时把 pkg/util 与 buildinfo 合并回上游 pkg(上游已覆盖全部符号,仅 8 个函数与
2 个类型为 OpenFlare 独有,已一并迁入),装配根统一到 backend/cmd(含三个 daemon
入口),Dockerfile 与 release 工作流的构建路径和 -X 注入路径同步更新。
验证:go build 通过;go test ./... exit 0(141 包 ok);make swagger exit 0 且
232 条 API 操作与基线逐条一致;make build-all 产出 4 进制;-X 注入经二进制
strings 实测生效;日志后端直连门禁改写为按 server 插件业务域扫描并在扫描数为 0
时报错(防门禁静默失效);前端零改动。
feat(cordis): 落地 backend/share 共享层与上游同步脚本
跨插件共享资源(控制消息协议、GeoIP+iputil、边缘守护进程日志)从下游包
移入 backend/share,并声明其只能依赖 core/pkg 与标准/第三方库,禁止反向
引用下游业务与具体插件实现;新增 scripts/sync-upstream.sh 只覆盖
backend/{core,pkg,plugins},同步后 --check 报告零差异,证明与上游逐字一致。
go build 通过,go test ./... exit 0(142 包 ok),前端零改动。
refactor(cordis): 采用与 Wavelet 同构的单模块布局并引入上游内核
按上游结构落位:backend/{core,pkg,plugins} 为 Wavelet 上游拷贝,OpenFlare
全部业务收拢到上游 downstream 所对应的位置 backend/OpenFlare/,模块名保持
Wavelet 以保证上游 import 路径逐字一致、同步零改写;三个 daemon 入口移至
backend/OpenFlare/cmd,backend/cmd 与 main.go 作为控制面装配根。
行为不变:go build 通过,142 个测试包全绿(含上游插件测试),232 条 API
操作与改造前逐条一致,四进制产物正常,前端零改动。swagger 暂只扫描下游代码,
待 P4 挂载上游路由后再纳入 plugins/。
style: 修正模块路径改写导致的 import 分组排序漂移
refactor(layout): Go 代码迁入 backend/ 并将模块名简化为 OpenFlare
对齐上游 Wavelet 的仓库布局,为以第二 module 形态 vendoring Cordis 内核与
平台插件做准备:模块路径整体改写为 OpenFlare,Go 目标加 cd backend,
swaggo 产物移至 backend/docs 并把 json/yaml 复制回 docs/ 供站点消费,
Dockerfile 与 release 工作流的构建目录、ldflags 模块路径同步更新。
行为保持不变:232 条路由与改造前逐条一致,95 个测试包全绿,
四进制产物正常,前端零改动。
chore(cordis): 落地改造计划与 schema/路由基线
新增 legacy_dump_test 迁移快照 harness:在临时 sqlite 库上按生产顺序
(goose.UpTo → zone 导入 → goose.Up)跑完 76 个历史迁移并导出 schema 与
版本序列,作为改造前后一致性门禁的唯一事实来源。同时记录 232 条路由清单
与 foundation 实施计划。
docs(cordis): add OpenFlare Cordis 架构改造设计
明确上游以第二 module 形态 vendoring 进 backend/Wavelet、4 个插件
(server/agent/relay/flared) 全部装载内核,并规定保留 76 个历史 goose
迁移 + 一次性版本 stamp 桥接的迁移方案,配套三方 schema 一致性门禁,
确保已部署库不重跑历史、不丢数据。
9.5 KiB
name, description
| name | description |
|---|---|
| push-notification | Wavelet 项目专用:当需要开发或接入新的系统通知推送事件、修改消息推送底层设计、调用统一触发器投递消息、或开发带消息推送功能的业务功能时必须使用。本技能指导元数据声明、触发流程、解耦防线和动态同步机制。 |
新增消息推送与通知事件开发规范
本技能涵盖 Wavelet 的系统通知推送开发规范。开始开发前先阅读仓库根目录 AGENTS.md,遵守项目级核心规则。
消息推送架构设计 (Architecture)
Wavelet 的消息推送机制采用了元数据驱动 + 统一触发器 + 异步任务派发的解耦设计,其分层及职责划分如下:
| 目录/包名 | 职责定位 | 包含内容与设计细节 |
|---|---|---|
pkg/push/ |
推送基础设施层 | 静态定义、不依赖系统数据库和任何框架。定义了统一接口 Pusher、单例 PusherPool 和多实现(Lark, Webhook, Email 等),提供配置验证及发送功能。 |
internal/apps/admin/push/ |
通知服务与后台任务层 | 包含以下核心文件: 1. events.go:定义通知事件的结构模型( NotificationMessage, EventMetadata)、内置事件的动态注册中心(BuiltInEvents 及 RegisterBuiltInEvent 函数)以及统一触发器类 EventTrigger(包括其底层的派发引擎逻辑)。2. tasks.go:定义 Asynq 后台异步发送任务、处理器 PushHandler 及其校验逻辑,并记录推送历史审计。3. routers.go:管理端接口,负责获取事件配置列表和更新配置。 |
internal/apps/admin/push/custom_events/ |
自定义通知事件包 | 事件元数据定义与 push 侧处理逻辑;一个 Go 文件代表一个事件。在 register.go 统一装配,禁止 init() 副作用。 |
internal/listener/ |
域事件分发层 | 核心域发射事件(如 EmitAdminLoggedIn),push 在 bootstrap 阶段通过 OnAdminLoggedIn 订阅,避免 auth/user 直接依赖 push。 |
internal/platform/bootstrap/ |
应用装配根 | RegisterPushDomainEvents() 调用 custom_events.Register();Init 中执行 SyncEvents 将内置事件元数据同步到数据库。 |
| 数据库审计表 | 状态与历史审计 | w_push_events 存放每个通知事件的启用状态、启用渠道、发送目标和自定义渲染模板。w_push_histories 存放消息发送记录用于审计。 |
核心开发步骤 (Step-by-Step Flow)
如果某个新业务(如“新用户注册”或“订单创建”)需要带有消息推送功能,请严格按照以下步骤开发:
步骤 1:在 custom_events/ 中声明事件元数据与处理函数
在 internal/apps/admin/push/custom_events/ 下新建一个 Go 文件(如 user_registered.go),声明 EventMetadata 和 push 侧处理函数(组装 body 并调用 DefaultTrigger.Trigger)。
package custom_events
import (
"context"
"time"
"OpenFlare/internal/apps/admin/push"
"OpenFlare/internal/listener"
)
var NewUserRegistered = push.EventMetadata{
Key: "user_registered",
Name: "新用户注册提醒",
DefaultTemplate: push.NotificationMessage{
Title: "新用户注册通知",
Content: "新用户 {{user.username}} (邮箱: {{user.email}}) 于 {{time}} 成功注册。",
Level: "INFO",
},
Description: "当系统有新用户注册成功时,向管理员或指定目标发送通知",
}
func handleUserRegistered(ctx context.Context, event listener.UserRegistered) {
if event.User == nil {
return
}
body := map[string]any{
"user": event.User,
"time": time.Now().Format("2006-01-02 15:04:05"),
}
push.DefaultTrigger.Trigger(ctx, NewUserRegistered, body)
}
EventTrigger.Trigger已内置异步 Goroutine 与context.WithoutCancel;处理函数内直接调用即可,无需外层go func()。
步骤 2:在 listener/ 定义域事件并在 register.go 装配
- 在
internal/listener/新增域事件类型、Emit*与On*注册函数(参考 admin_login.go)。 - 在 register.go 中注册元数据并订阅域事件:
func Register() {
push.RegisterBuiltInEvent(NewUserRegistered)
listener.OnUserRegistered(handleUserRegistered)
}
禁止在 custom_events 或 router 中使用 init() 注册;禁止在 router.go 空白导入 custom_events。
步骤 3:在业务代码中发射域事件(不 import push)
在业务逻辑完成处(如 internal/apps/user/routers.go)仅 import internal/listener 并发射事件:
import "OpenFlare/internal/listener"
func Register(c *gin.Context) {
// ... 注册成功逻辑 ...
listener.EmitUserRegistered(ctx, user)
}
步骤 4:在 bootstrap / cmd 入口显式装配
新增事件后,确保 custom_events.Register() 已被 bootstrap.RegisterPushDomainEvents() 调用,且 API/all 进程在 bootstrap.Init 之前完成注册:
| 进程 | cmd 入口调用 |
|---|---|
api |
bootstrap.RegisterAPI() → bootstrap.Init(ctx, Options{API: true}) |
all |
bootstrap.RegisterAll() → bootstrap.Init(ctx, Options{API: true}) |
worker / scheduler |
不注册 push 域事件;仅 bootstrap.Init + 各自 RegisterWorker/RegisterScheduler |
Init 中的 SyncEvents 会将 user_registered 元数据同步到 w_push_events,管理员即可在前端配置推送渠道。
步骤 5:编写集成测试
在 custom_events/ 或 listener/ 包内添加测试,验证 Emit* → handler → DefaultTrigger.Trigger 全链路。测试 setup 须显式调用 custom_events.Register()(或 bootstrap.RegisterPushDomainEvents())和 push.SyncEvents,参考 admin_login_test.go。
模板渲染与支持的系统变量 (Template Rendering & Variables)
消息的 title、content 以及 ext 字段中的字符串值都支持变量占位符替换,采用双花括号形式 {{variable}}。
1. 通用事件参数 (Common Variables)
在 Wavelet 系统中,user 是一个通用的、必传的事件参数。如果在触发通知事件时未提供 user(或为 nil),底层 EventTrigger 会自动注入一个系统的虚拟用户(ID 为 999,昵称为“系统”)。因此,以下变量是所有通知事件均支持的通用渲染参数:
{{time}}:事件发生/触发的具体时间(格式:2006-01-02 15:04:05){{user.id}}:触发用户/系统用户的 ID{{user.username}}:触发用户/系统用户的用户名{{user.nickname}}:触发用户/系统用户的昵称{{user.email}}:触发用户/系统用户的电子邮箱{{user.phone}}:触发用户/系统用户的手机号{{user.bio}}:触发用户/系统用户的个人简介{{user.gender}}:触发用户/系统用户的性别{{user.location}}:触发用户/系统用户的所在地{{user.website}}:触发用户/系统用户的个人网站
(注:系统中的任何自定义事件,若传入了对应的复杂结构体,其结构体 JSON 字段均可通过扁平化点路径方式直接在模板中进行引用。)
2. 特定事件携带的业务变量 (Event Specific Variables)
除了通用的 user 和 time 外,特定事件在触发时还可以携带额外的上下文参数:
- 管理员登录提醒 (
admin_login){{ip}}:管理员登录来源的客户端 IP{{time}}:管理员登录成功时间
3. 自定义消息通道的请求体变量说明 (Custom Channel JSON Variables)
在配置“自定义消息通道”时,其请求体 (JSON Schema) 支持以 $ 开头的变量替换。支持的替换变量如下:
{
"title": "$title",
"description": "$description",
"content": "$content",
"url": "$url",
"to": "$to"
}
$title:通知的标题(如:“管理员登录提醒”)$description:当前通知事件的描述$content:通知的具体渲染后正文内容$url:附加的操作或详情链接(若有)$to:当前派发的推送目标(如邮箱、ID 或 Chat ID,即 resolved target)
严格遵循事项与防线 (Guardrails)
1. 禁止绕过统一触发器 (Always Use EventTrigger)
- 所有推送请求必须经过
EventTrigger.Trigger,以确保进行“事件是否启用”、“目标渠道过滤”、“全局推送配置读取”及“发送日志审计”等流程。
2. 禁止业务模块直接依赖 push (Decouple via listener)
oauth、user等核心域 不得importinternal/apps/admin/push或custom_events。- 跨模块通知必须通过
internal/listener发射域事件;push 在custom_events.Register()中订阅。
3. 禁止 init() 与 router 副作用注册 (Explicit Bootstrap)
- 不得在
init()中调用RegisterBuiltInEvent或订阅 listener。 - 不得在
router.go空白导入custom_events触发注册。 - 统一在
internal/platform/bootstrap+internal/cmd入口显式装配。