Files
OpenFlare/.agents/skills/new-api/SKILL.md
T
ryan dbaa3bf140 feat(cordis): add OpenFlare Cordis 架构改造设计
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 一致性门禁,
确保已部署库不重跑历史、不丢数据。
2026-08-30 10:12:52 +08:00

8.3 KiB
Raw Blame History

name, description
name description
new-api Wavelet 项目专用:当新增或修改自定义业务 API、新增业务路由、新增 service 层核心逻辑时必须使用。本技能指导包职责划分、推荐文件结构、路由解耦、Swagger 文档生成与质量门禁验证。

新增业务 API 开发与路由注册规范

本技能是 Wavelet 项目接口开发与路由注册的唯一指导规范。在开发任何新接口前,请严格按照本指南进行架构决策与路由注册。


核心路由准则与防线 (Routing Governance & Guardrails)

Wavelet 后端路由采用了严格的框架层与业务层隔离机制。请牢记以下开发原则:

  1. 禁止修改框架级路由文件:
    • 以下文件属于系统框架/平台级接口,禁止为了添加自定义业务接口而进行任何修改:
      • internal/router/router.go(核心入口委派)
      • internal/router/root/default.go(公开文件服务、robots.txt、Swagger 及 /api/health 路由)
      • internal/router/root/frontend.go(前端静态服务)
      • internal/router/v1/v1.go(V1 分发层协调器)
      • internal/router/v1/admin.go(框架管理员端管理接口)
      • internal/router/v1/user.go(框架普通用户端基础接口、OAuth及公开接口)
  2. 仅允许在 custom.go 中注册业务接口:

路由归属判定表 (Where should I register my new API?)

根据接口的访问路径特征和访问身份/限制条件,决定将新开发的 API 挂载至何处:

目标 API 路径特征 访问身份/条件限制 对应的路由注册入口 是否允许修改
/my-custom-path (挂载在根路径下的特殊业务接口) 自定义控制 root/custom.go 中的 RegisterCustomRootRoutes 允许修改 (业务自定义入口)
/api/v1/custom/... (API v1 下的定制业务接口) 自定义控制 v1/custom.go 中的 RegisterCustomRoutes 允许修改 (业务自定义入口)
/api/v1/admin/... (系统管理员管理端接口) 需要管理员登录 (admin.LoginAdminRequired()) v1/admin.go 禁止修改 (仅限系统框架路由)
/api/v1/user/... (框架普通用户基础接口) 需要普通用户登录 (oauth.LoginRequired()) v1/user.go 禁止修改 (仅限系统框架路由)
/api/v1/public/... (Captcha、Config 等系统公开接口) 所有人 (无条件 / 公开) v1/user.go 禁止修改 (仅限系统框架路由)
GET /f/:id, GET /robots.txt, GET /api/health (系统级默认及公开接口) 所有人 (无条件 / 公开) root/default.go 禁止修改 (仅限系统框架路由)

两个自定义路由包的用法与区别 (Root Custom vs V1 Custom)

1. 根路径自定义包:root/custom.go

  • 适用场景:适用于需要直接挂载在主域名根路径下的特殊自定义业务接口(如第三方 Webhook 回调、特定的短链接重定向、外部数据接口等,不需要 /api/v1 前缀)。
  • 用法示例: 在 root/custom.go 中实现:
    package root
    
    import (
    	"OpenFlare/internal/apps/custom"
    	"github.com/gin-gonic/gin"
    )
    
    // RegisterCustomRootRoutes registers custom business routes that belong to the root path.
    func RegisterCustomRootRoutes(r *gin.Engine) {
    	// 挂载到根路径下,如 GET /my-custom-webhook
    	r.GET("/my-custom-webhook", custom.HandleRootWebhook)
    }
    
    (注:该函数已由 root.go 自动加载,你无需修改任何其他核心文件。)

2. V1 API 自定义包:v1/custom.go

  • 适用场景:适用于普通的自定义业务 API,需要规范挂载在标准 API V1 路径下(即自动带有 /api/v1/custom/... 前缀,可选择性配置用户/管理员登录中间件)。
  • 用法示例: 在 v1/custom.go 中实现:
    package v1
    
    import (
    	"OpenFlare/internal/apps/custom"
    	"github.com/gin-gonic/gin"
    )
    
    // RegisterCustomRoutes registers standard custom API routes under /api/v1.
    func RegisterCustomRoutes(apiV1Router *gin.RouterGroup) {
    	customRouter := apiV1Router.Group("/custom")
    	{
    		// 挂载到 /api/v1/custom 下,例如:POST /api/v1/custom/action
    		customRouter.POST("/action", custom.DoActionHandler)
    	}
    }
    
    (注:该函数已由 v1/v1.go 自动加载,你无需修改任何其他核心文件。)

当新增一套定制的业务接口(例如名为 custom 的业务模块)时,建议采用以下标准文件结构:

internal/
├── router/
│   ├── root/
│   │   └── custom.go           # [修改] 若为根路径 API,在此处注册,将路由委派给 apps/custom
│   └── v1/
│       └── custom.go           # [修改] 若为 v1 API,在此处注册,将路由委派给 apps/custom
└── apps/
    └── custom/
        ├── routers.go          # [新建] HTTP Handlers (Gin),负责参数绑定、校验与响应
        ├── logics.go           # [新建] 业务逻辑层:承载模块内闭环的纯 Go 业务逻辑,不依赖 gin.Context
        └── errs.go             # [新建] 存放模块特有的业务错误常量定义(可选)

核心开发步骤 (Step-by-Step Flow)

步骤 1:数据库定义与迁移

如果自定义功能涉及新表或字段,请参考 database-migration 技能,在 internal/infra/persistence/migrator/goose/ 目录下编写迁移文件,在 internal/model/ 中定义 GORM 实体(无 CRUD / 无 DB 访问),并在 internal/repository/ 中实现数据访问(repository 为唯一持久化入口)。

步骤 2:在模块内实现业务逻辑 (logics.go / service.go)

业务逻辑逻辑应当实现于 internal/apps/custom/ 目录下:

  • 优先使用纯函数(logics.go):定义接收 context.Context 且不依赖 *gin.Context 的函数,易于单元测试与 Worker 复用。参考 internal/apps/user/logics.go。
  • 有状态服务(service.go):若需注入依赖(如 DB 连接、外部客户端等),可定义 Service 结构体和构造函数。
  • 跨模块副作用(推送、任务监听等):核心业务代码通过 internal/listener 发射域事件,禁止直接 import push 模块;装配在 internal/platform/bootstrap 完成(参见 push-notification skill)。

步骤 3:编写 HTTP Handler (routers.go)

在 internal/apps/custom/routers.go 中编写 Handler:

  • 负责请求参数绑定与校验(使用 ShouldBindJSON/ShouldBindQuery)。
  • 负责提取 Session / 用户身份。
  • 调用业务逻辑层,并使用 OpenFlare/internal/shared/response 统一返回响应:
    • 成功时返回:response.OK(data) 或 response.OKNil()
    • 失败时返回:response.Err(msg)
  • 编写规范的 Swagger 注释。

步骤 4:在自定义包中注册路由并委派

根据 路由归属判定表,在 root/custom.go 或 v1/custom.go 中编写注册代码,将路由路径绑定到步骤 3 中编写的 Handler。


质量验证门禁 (Quality Gates)

每次新增或修改接口后,必须运行并验证以下各项:

  1. 自动授权许可:make license(新增 Go 文件时自动添加许可头)
  2. 重新生成 Swagger 文档:make swagger(若有 Swagger 注释修改)
  3. 静态代码及风格检查:make code-check(确保通过 golangci-lint 和前端 TS 检查)
  4. 自动化单元测试:go test ./...(确保所有测试 100% 通过)