3 Commits

Author SHA1 Message Date
yuming 23278fee06 补最终修复报告,并标注计划文档里已过时的手工 SQL
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-16 10:28:29 +08:00
yuming 955c80e221 实现计划:订阅消息额度治理
9 个任务,含单测代码与端到端验证脚本。用 Node 18 内置的 node:test
做后端单测(零新依赖),前端沿用 miniprogram-automator。

Task 1 是前置重构:把 reminder.js 内联的日期计算抽成可注入 today 的
纯函数模块,让核心逻辑第一次变得可单测,也供风险预警计算复用。

计划里记录了上线首日的一个真空风险:subscribe_quota 是新表,存量用户
初始余额均为 0,而新版 reminder 在余额为 0 时不发任何请求——后端一上线
存量用户提醒会立刻全部停发,且此时新版小程序还在审核中,用户无从补救。
附了按纪念日条数补初始余额的 SQL,须在部署后、当天 9 点定时任务前执行。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-15 16:55:18 +08:00
yuming 6d0119103f 设计文档:订阅消息额度治理
记录订阅消息额度供需倒挂问题的设计方案:服务端按 openid 记账、
用户点击时搭车补额度、额度不足时按优先级取舍并在首页预警。

核实并记录了几条决定设计走向的微信平台约束:
- 额度是 (用户 × 模板) 维度且永久有效,但用户关通知总开关会全部清零
- 无官方接口可查余额,只能自行记账并靠 43101 校正
- requestSubscribeMessage 必须由真实点击手势触发,无法在 onLaunch 静默调用
- 长期订阅类目不符,申请不到

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-15 16:44:19 +08:00