sundynix-agentix

sundynix/sundynix-agentix

Fork 0

Commit Graph

Author	SHA1	Message	Date
Blizzard	b1fea23a0c	feat(site): 官网定价页 —— 套餐由后台配置驱动，公开可见官网加「定价」菜单与页面。数据来自 GET /api/v1/pricing（不挂鉴权）：运营改价、上下架、调发放节奏都在管理端完成，官网跟着变，不用发版；未登录就能看到价格，这是转化的前提，也是官网存在的意义。接口只吐在售项与展示字段，成本、权重、租户信息一律不出去。结账仍在 Web 面完成（那里有登录态、租户上下文与支付轮询），官网只负责「看价 → 去买」。同一套支付流程不在两处各实现一遍——这也是本次订阅开发一直遵循的那条线：积分包与订阅共用一个支付弹窗，桌面端不重复购买入口。 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-20 16:59:58 +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

b1fea23a0c

feat(site): 官网定价页 —— 套餐由后台配置驱动，公开可见

官网加「定价」菜单与页面。数据来自 GET /api/v1/pricing（**不挂鉴权**）：
运营改价、上下架、调发放节奏都在管理端完成，官网跟着变，不用发版；
未登录就能看到价格，这是转化的前提，也是官网存在的意义。

接口只吐在售项与展示字段，成本、权重、租户信息一律不出去。

结账仍在 Web 面完成（那里有登录态、租户上下文与支付轮询），官网只负责
「看价 → 去买」。同一套支付流程不在两处各实现一遍——这也是本次订阅开发
一直遵循的那条线：积分包与订阅共用一个支付弹窗，桌面端不重复购买入口。

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

2026-07-20 16:59:58 +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