sundynix/sundynix-agentix
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
390 Commits 5 Branches 0 Tags
main
Commit Graph

5 Commits

Author SHA1 Message Date
Blizzard 07955ddf07 feat(auth): 微信扫码登录后端 —— 网页授权 + ticket 轮询 
服务号「植趣 ZeeQ」已认证，走网页授权（snsapi_base，只拿 openid、用户无感），
不接管消息推送，副作用最小。

流程：PC 建 ticket → 二维码指向 /wx/mp?t= → 用户微信扫码 → 302 到微信授权页 →
回调 /api/v1/wx/mp/callback 用 code 换 openid → 找/建用户 → ticket 置 authorized →
PC 轮询 /wx/mp/poll 拿到 authorized → 签发 JWT。ticket 一次性消费防重放。

- 配置(appid/secret/base_url)后台可改，secret AES 加密入库，与微信支付同一套 secrets；
- ticket 存 Redis（短 TTL），无 Redis 时回退进程内内存（本地单实例可用，生产必须有 Redis）；
- User 加 wechat_openid。**部分唯一索引**（WHERE openid <> ''）而非普通唯一：
  存量邮箱用户该列是空串，普通唯一索引会让多个空串互撞、AutoMigrate 直接失败
  —— 与之前 NULL 余额同类的坑，这次提前避开。

单测覆盖：授权 URL 拼接（含 #wechat_redirect 锚点必须在末尾）、secret 加密往返、
建号/查号、空 openid 不误命中存量用户。微信 API 调用依赖公网回调，本地测不了，
留待部署后真机扫码。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-21 08:44:00 +08:00
Blizzard f8f7359723 feat(admin): 订阅管理页 + 修「余额列为 NULL 导致充值永不到账」 
管理端「支付 → 订阅」：套餐配置 + 全平台订阅观测。配置时直接算出「一个周期
发几次、合计多少积分」，时长不能被间隔整除时橙字提示到期前会有空档 —— 让人在
配的时候就看见后果，而不是上线后才发现只发了一次。

顺带修了个真 bug，是拿真库验订阅时撞出来的（本地 42 个租户里 11 个中招）：

  credit_balance_micro 是后加的列，早于它创建的租户行值为 NULL。而入账语句是
  「余额 + N」—— SQL 里 NULL + N 仍是 NULL，于是这些租户**充值永远不到账**：
  分录照写、余额不动、不报错。这条路径是充值/兑换码/退款/扣费/订阅发放共用的，
  不是订阅引入的问题。

三处修：
  - 5 处余额增减一律改 coalesce(credit_balance_micro, 0)，新写入自愈；
  - 启动迁移回填存量 NULL（按账本求和，让「余额 = SUM(ledger)」重新成立）；
  - 模型只加 default:0，**刻意不加 not null** —— 存量库有 NULL 行，AutoMigrate
    尝试 SET NOT NULL 会直接失败，而且它在回填之前跑，等于把部署搞挂。

回归测试先证明能失败（去掉 coalesce → 余额 0）再确认修复。第一版测试因为我给
模型加了 not null 而无法造出 NULL，恰好暴露了上面那个部署风险。

真库验证：回填后 42 个租户 0 个 NULL；那个"有分录但余额 NULL"的租户余额
2981 = 账本合计 2981.34。管理端页面显示真实订阅（已发放 3 次 = 首笔 + 补发 2 笔）。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-20 16:28:32 +08:00
Blizzard 93741a5504 feat(gateway): 闭合积分环 —— 充值/发放 + 提交前余额硬拦截(默认关) 
让预付费积分成为闭环（发放→消耗→见底拦住）：
- POST /admin/credits/grant：给租户充值/发放（正=grant，负=adjust 校正），
  复用 store.GrantCredits（账本分录 + 物化余额，一事务）。
- 提交门控：credit_enforce 开启且租户余额≤0 → 拒绝新任务 402；默认关=软扣不拦。
  开关入 billing-config（sundynix_setting KV，后台可切）。
- 修 bug：GrantCredits 是跨租户管理操作，须 store.WithoutTenant——否则 tenant 插件
  会把账本分录的 tenant_id 覆盖成 admin 自己的租户（余额记目标、分录记 admin，破坏对账）。

live 验证：enforce 关→余额0可提交；开→余额0拒 402；充值后可提交、余额递减；
修复后 grant 分录落到目标租户、balance==SUM(ledger) 不变量成立。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-07 13:53:43 +08:00
Blizzard bf75bb8a62 feat(gateway): SaaS P2 计量·增量3 —— GET /admin/usage 用量/积分/成本口径 
系统级(store.WithoutTenant，跨租户)用量观测：
- 无 tenant：全平台按天 SUM 趋势 + 各租户用量排行(含当前余额)。
- 有 tenant：该租户按天趋势 + 当前积分余额。
- from/to(YYYYMMDD)缺省近 30 天。UsageTrend/UsageByTenant/TenantBalance store 方法。

live 验证：两口径数值自洽（balance=seed−credits、credits=tok×汇率、totals=trend之和）。
至此 P2 计量后端(事实源)齐：明细/账本/余额/rollup/查询。前端页 + P4 硬拦截/充值待需求拉动。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-07 11:42:21 +08:00
Blizzard d058a63434 feat(gateway): SaaS P2 计量·增量2 —— 积分账本 + 物化余额 + 用量 rollup 
- credit_ledger（append-only）：grant/usage/adjust 分录，扣量/充值的事实源。
- tenant.credit_balance_micro：物化余额（= 账本之和），用量扣、充值增。
- usage_rollup：租户/天 upsert 累加（配额/账单读一行，不扫明细）。
- 消费 usage_event 一个事务内：落明细 → applyUsageCredit(账本负分录+扣余额)
  → upsertRollup(累加)。幂等锚在 usage_event.task_id 唯一：RowsAffected==0（重投）
  则跳过账本/余额/rollup，绝不重复计费。软扣：余额可为负（不拦，硬闸留 P4）。
- GrantCredits 充值/发放 API（记 grant 分录+增余额；增量3 admin 接）。

live 验证：ledger 负分录(ref=task_id) / 余额递减 / rollup 两任务累加(count=2,tok/credits求和)
/ **balance==seed+SUM(ledger) 不变量成立**（物化余额 == 账本真值）。

增量3（GET /admin/usage 趋势+余额）待做。

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-07 11:26:27 +08:00