sundynix-agentix

sundynix/sundynix-agentix

Fork 0

Commit Graph

Author	SHA1	Message	Date
Blizzard	ac38d5e663	fix(prod): 后端生产级 A 类硬伤全清（7 项：授权/崩溃点/全表扫/限流/鉴权/限额）部署前生产级审计（可靠性/数据层/安全三路）后，清掉 7 处代码级硬伤： A1 后台定时器 goroutine 无 panic recover → 单个 DB panic 崩整个 gateway。加 safeGo/ safeCall，包住订阅/掉单补偿/微信推送/探针 goroutine，单轮 tick 再兜一层。 A2 提示词控制面(建/激活/停用，热广播全服务)只 RequireAuth → 任意登录用户改全局提示词。三写端点+列表挂 RequireAdmin。 A3 HITL 审批端点无角色门 → viewer 可放行烧钱执行。加 RequireTenantRole(member)。 A4 审计/护栏列表 limit 无校验，limit=-1 让 gorm 取消 LIMIT 全表扫。加 clampLimit/ clampOffset，AdminTasks/AdminSpaces 补上界。 A5 限流 Redis 一挂就完全放行(fail-open)。加进程内固定窗口兜底(fail-safe) + 登录/注册按 IP 专用严限流(10/min)。 A6 公开 by-id 端点(stream/exec/report导出/kb导入流)无鉴权无租户过滤。加 AuthFromHeaderOrQuery(从 ?token= 取 JWT) + task/report 按 owner 归属校验；桌面端 5 处 EventSource/下载 URL 经 tokenQuery 附 JWT。 A7 文件上传无大小上限(整文件进内存 OOM 面) → 50MB 闸(KB_MAX_UPLOAD_BYTES)+ LimitReader； http.Server 加 ReadHeaderTimeout/ReadTimeout/MaxHeaderBytes(不设 WriteTimeout 保 SSE)。带单测：clampLimit/safeCall/procLimiter/AuthFromHeaderOrQuery/TaskOwner。 build+vet+全量 test 绿；desktop tsc 绿。B(迁移工具/实时探针/出网韧性/登录锁定/leader选举) 与 C(TLS/PG HA/K8s/备份自动化/可观测)分期后做，参照 production_readiness.md。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-21 15:04:47 +08:00
Blizzard	80d4aaf4ba	feat(billing): 订阅制后端 —— 手动购买 + 周期发放积分 + 到期失效规格（按需求）：用户扫码买一个订阅周期，有效期内每 N 天发一次积分，到期即失效，不自动续费。N 与每次发放额度都在套餐里配，后台可改。为什么不做自动续费：微信 Native 扫码支付没有代扣能力，真自动续费要走「委托代扣」 ——另一套产品与资质。与其假装有，不如把"到期即失效"这个语义做扎实。两个决定，都写进了代码注释： - 发放语义是累加而非重置。每次刷新写一条 grant 分录、余额累加。重置型（月度配额清零）会让「余额 = SUM(ledger)」这条对账不变量变复杂，且有误清用户自费积分的风险。 - 订阅开通放在 store.MarkOrderPaid 内，而不是各调用方。回调与掉单补偿两条路都经过它，放这一处才没人能漏掉；按 orderID 幂等，重复调用无害。复用而非另造：订阅单与积分包单走同一条支付链路（下单/回调/查单/掉单补偿），只是 kind=sub 且 credits_micro=0——积分不在付款时给，由订阅按周期发。定时器每 10 分钟扫一轮，语义与幂等都在 store.TickSubscription 里，与手动触发共用，不会两处漂移。停机期间欠下的发放会一次性补齐。 8 组测试。其中一条当场抓到真 bug：开通时原本无条件发一笔，同一订单重复开通（回调重推/查单赛跑）会因序号自增绕过幂等索引，白送积分。改为开通也走与定时器同一套排期判断——排期天然幂等。教训：幂等键要锚在业务时间轴上，不能靠自增序号。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 16:11:34 +08:00

Author

SHA1

Message

Date

Blizzard

ac38d5e663

fix(prod): 后端生产级 A 类硬伤全清（7 项：授权/崩溃点/全表扫/限流/鉴权/限额）

部署前生产级审计（可靠性/数据层/安全三路）后，清掉 7 处代码级硬伤：

A1 后台定时器 goroutine 无 panic recover → 单个 DB panic 崩整个 gateway。加 safeGo/
   safeCall，包住订阅/掉单补偿/微信推送/探针 goroutine，单轮 tick 再兜一层。
A2 提示词控制面(建/激活/停用，热广播全服务)只 RequireAuth → 任意登录用户改全局提示词。
   三写端点+列表挂 RequireAdmin。
A3 HITL 审批端点无角色门 → viewer 可放行烧钱执行。加 RequireTenantRole(member)。
A4 审计/护栏列表 limit 无校验，limit=-1 让 gorm 取消 LIMIT 全表扫。加 clampLimit/
   clampOffset，AdminTasks/AdminSpaces 补上界。
A5 限流 Redis 一挂就完全放行(fail-open)。加进程内固定窗口兜底(fail-safe) + 登录/注册
   按 IP 专用严限流(10/min)。
A6 公开 by-id 端点(stream/exec/report导出/kb导入流)无鉴权无租户过滤。加
   AuthFromHeaderOrQuery(从 ?token= 取 JWT) + task/report 按 owner 归属校验；桌面端
   5 处 EventSource/下载 URL 经 tokenQuery 附 JWT。
A7 文件上传无大小上限(整文件进内存 OOM 面) → 50MB 闸(KB_MAX_UPLOAD_BYTES)+ LimitReader；
   http.Server 加 ReadHeaderTimeout/ReadTimeout/MaxHeaderBytes(不设 WriteTimeout 保 SSE)。

带单测：clampLimit/safeCall/procLimiter/AuthFromHeaderOrQuery/TaskOwner。
build+vet+全量 test 绿；desktop tsc 绿。B(迁移工具/实时探针/出网韧性/登录锁定/leader选举)
与 C(TLS/PG HA/K8s/备份自动化/可观测)分期后做，参照 production_readiness.md。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-21 15:04:47 +08:00

Blizzard

80d4aaf4ba

feat(billing): 订阅制后端 —— 手动购买 + 周期发放积分 + 到期失效

规格（按需求）：用户扫码买一个订阅周期，有效期内每 N 天发一次积分，到期即失效，
不自动续费。N 与每次发放额度都在套餐里配，后台可改。

为什么不做自动续费：微信 Native 扫码支付没有代扣能力，真自动续费要走「委托代扣」
——另一套产品与资质。与其假装有，不如把"到期即失效"这个语义做扎实。

两个决定，都写进了代码注释：
- **发放语义是累加而非重置**。每次刷新写一条 grant 分录、余额累加。重置型
  （月度配额清零）会让「余额 = SUM(ledger)」这条对账不变量变复杂，且有误清
  用户自费积分的风险。
- **订阅开通放在 store.MarkOrderPaid 内**，而不是各调用方。回调与掉单补偿两条
  路都经过它，放这一处才没人能漏掉；按 orderID 幂等，重复调用无害。

复用而非另造：订阅单与积分包单走同一条支付链路（下单/回调/查单/掉单补偿），
只是 kind=sub 且 credits_micro=0——积分不在付款时给，由订阅按周期发。

定时器每 10 分钟扫一轮，语义与幂等都在 store.TickSubscription 里，与手动触发
共用，不会两处漂移。停机期间欠下的发放会一次性补齐。

8 组测试。其中一条当场抓到真 bug：开通时原本无条件发一笔，同一订单重复开通
（回调重推/查单赛跑）会因序号自增绕过幂等索引，白送积分。改为开通也走与定时器
同一套排期判断——排期天然幂等。教训：幂等键要锚在业务时间轴上，不能靠自增序号。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-07-20 16:11:34 +08:00

2 Commits