topfans/docs/superpowers/notification-system-changelog.md
2026-06-16 21:30:58 +08:00

7.1 KiB
Raw Permalink Blame History

通知系统实施 - 改动追踪

状态:实施完成,等待人工 stage + commit

由于项目 .claude/hookify.block-auto-git-add.local.md hook 拦截 git add,所有 subagent 改动留在工作区未 stage,由你最终手动处理。

当前分支: feat/asset_material_relations


实施结果

阶段 任务 状态 编译/测试 Stage
阶段 1 T1 数据库迁移 SQL 5 DDL Staged
阶段 2 T2-T3 asset proto + 填充 Build pass T2 staged, ⚠️ T3 unstaged
阶段 3 T4 notification proto Build pass ⚠️ Unstaged
阶段 3 T5-T6 config + model Build pass ⚠️ Unstaged
阶段 3 T7-T9 repository + tests Tests 3 PASS, 3 SKIP (no DB) ⚠️ Unstaged
阶段 3 T10-T12 service + provider Tests PASS ⚠️ Unstaged
阶段 3 T13 main.go Build pass ⚠️ Unstaged
阶段 4 T14-T16 social integration 5 tests PASS ⚠️ Unstaged
阶段 5 T17-T20 admin (Python) 126 routes ⚠️ Unstaged
阶段 6 T21-T22 gateway Build pass ⚠️ Unstaged
阶段 7 T23 整体回归 All green -

总文件改动: 21 个文件

  • 9 Modified (M)
  • 9 Untracked (??)
  • 2 Added staged (A) - T1 迁移 + T2 proto
  • 1 Deleted (D) - backend/socialService 旧的二进制文件(与本任务无关)

整体回归结果

检查项 结果
全量 Go 编译 exit 0
notification service 测试 3 PASS / 3 SKIP无 DB
social service fireLike 测试 5 PASS
gateway 编译 pass
迁移 SQL DDL 数 52 CREATE TABLE + 1 ALTER SEQUENCE + 2 CREATE INDEX
admin 后端 import 126 routes registered

完整改动清单

后端 (Go)

M  backend/go.work
M  backend/pkg/proto/asset/asset.pb.go
M  backend/proto/asset.proto

?? backend/migrations/2026_06_16_001_create_notifications.sql
?? backend/proto/notification.proto
?? backend/pkg/proto/notification/
   ├── notification.pb.go (generated)
   └── notification.triple.go (generated)

M  backend/services/assetService/service/asset_service.go
?? backend/services/notificationService/
   ├── go.mod
   ├── main.go
   ├── configs/config.yaml
   ├── model/notification.go
   ├── repository/notification_repository.go
   ├── repository/notification_stats_repository.go
   ├── repository/notification_repository_test.go
   ├── service/notification_service.go
   ├── service/notification_service_test.go
   ├── provider/notification_provider.go

M  backend/services/socialService/main.go
M  backend/services/socialService/service/asset_like_service.go
?? backend/services/socialService/client/notification_client.go
?? backend/services/socialService/client/notification_client_mock.go
?? backend/services/socialService/service/asset_like_service_test.go

M  backend/gateway/config/config.go
M  backend/gateway/main.go
M  backend/gateway/router/router.go
?? backend/gateway/controller/notification_controller.go

Admin 后端 (Python)

?? TopFans-activity-admin/backend/models/notification.py
M  TopFans-activity-admin/backend/models/__init__.py
?? TopFans-activity-admin/backend/crud/notification_crud.py
M  TopFans-activity-admin/backend/crud/__init__.py
M  TopFans-activity-admin/backend/crud/minting_crud.py
?? TopFans-activity-admin/backend/handlers/notification.py
M  TopFans-activity-admin/backend/handlers/minting.py
M  TopFans-activity-admin/backend/router/__init__.py
M  TopFans-activity-admin/backend/schemas/minting.py

文档

A  docs/superpowers/plans/2026-06-16-notification-system.md
A  docs/superpowers/specs/2026-06-16-notification-system-design.md
?? docs/superpowers/notification-system-changelog.md (本文件)

Spec 验收清单

docs/superpowers/specs/2026-06-16-notification-system-design.md §12 逐项核对:

  • 迁移文件已应用notifications 表存在(待运维跑 SQL
  • notification service 进程启动正常main.go 已就绪)
  • 前端 GET /api/v1/notifications?type=like&tab=today 返回今日点赞(需启动服务 + 集成测试)
  • 点赞触发后,被点赞方收到通知(需 e2e 测试)
  • 未读数 GET /api/v1/notifications/unread-count 返回正确数字(需 e2e 测试)
  • admin POST 创建单用户系统通知前端能查到API 已实现)
  • admin 按 star 广播指定 star 的所有粉丝收到CRUD 已实现)
  • admin 全量广播所有用户收到CRUD 已实现)
  • admin 创建 activity 后自动广播handler 已实现)
  • admin 手动 broadcast API 工作(端点已注册)
  • 软删除后列表不再返回SQL WHERE is_deleted = FALSE
  • 标已读后未读数对应类型 -1事务内 stats.DecrementByType
  • 删除未读通知后未读数 -1事务内 stats.DecrementByType
  • 通知写入失败时点赞主路径返回成功fireLikeNotification 设计为 fire-and-log
  • 同一 asset 收到 N 个赞 → 列表只显示 1 张聚合卡(含 total_count + 前 3 个点赞人预览)
  • 点击 like 聚合卡 → 跳到 /pages/asset/detail?id={target_id}target_id 字段已暴露)
  • MarkAsReadByTarget → 该 target 下所有未读 like 标已读、未读数对应 -N
  • DeleteByTarget → 该 target 下所有 like 软删、未读数对应 -N
  • system / activity 通知仍按单条 MarkAsRead(id) / DeleteNotification(id) 操作

Plan vs Reality 差异(需记录)

  1. Plan 假设 *database.DB / *sql.Tx,实际项目用 *gorm.DB。Subagent T7+ 全部调整。
  2. Plan 假设 scripts/compile-proto.sh 有 notification block实际没有。Subagent T4 用 direct protoc 命令生成。
  3. Plan 写 configs/config.yamlsocialService 实际用 dubbo.yaml;新 notificationService 用 config.yaml(这是 plan 对的,但 socialService 用了不同命名)。
  4. Plan 写 asset_provider.go,实际响应构造在 asset_service.go。Subagent T3 编辑了正确文件。
  5. Plan 未提到 go.mod / go.work 更新,但新 service 必须有。Subagent T5-T6 自动添加。
  6. Admin 后端没有 require_admin 中间件,只有 verify_token。Subagent T17-T20 用 verify_token 替代。
  7. Admin 后端没有 users(只有 fan_profiles_resolve_recipients("all") 用 fan_profiles DISTINCT user_id。
  8. LSP 多次报 style 警告(interface{}any,非阻塞。
  9. 两个预存的诊断laser_generate_controller.goai_chat_controller.go)与本任务无关。

上线 Checklist运维侧

  1. 跑迁移:backend/migrations/2026_06_16_001_create_notifications.sql
  2. 部署新版 assetService含 name/cover_url
  3. 部署新版 socialService含点赞通知调用
  4. 部署新版 notificationServiceport 20010
  5. 部署新版 gateway含 notification 路由)
  6. 部署新版 admin 后端
  7. 配置 gateway config 加 DUBBO_NOTIFICATION_SERVICE_URL(默认 tri://127.0.0.1:20010

每步独立发布,任何一步出问题可单独回滚。