lunar-mini/REMINDER.md

开发提醒

2026-09-06：商业化功能不能只完成界面

• 任何标记为“支付已接入”的功能，必须同时具备真实服务商下单、Webhook 验签、订单状态机、幂等处理、用户权益、退款处理和后台查询。
• 演示支付必须明确标注，不能把模拟数据描述成真实支付能力。
• 付费数字内容必须支持跨设备恢复，并保存购买时的不可变快照，避免算法升级后用户看到不同结果。
• 完成页面设计后，应继续验证完整的“登录—下单—支付通知—发放权益—恢复报告—退款撤权”闭环。
• 没有商户凭证时只能声明代码与模拟测试完成，不能声明真实生产收款已经开通。
• 管理后台新增 PC 商业模块后，必须统一品牌名称、页面标题和导航，不能让新旧产品名称混在同一套后台界面里。
• 排盘产品必须保存服务端历史快照；不能只依赖浏览器状态，否则重复排盘、算法升级和跨设备恢复都会产生歧义。
• 基础排盘事实（四柱、起运、刑冲合害、神煞位置）应作为免费层展示，付费点应放在个性化解释而不是隐藏原始数据。
• 交运时间不能直接使用 ChildLimit 的出生区间起点；应显示真正的第一步大运交运时间。
• 商业前端的本地 file: 依赖可能缓存旧版 @lunar/core；生产构建必须先构建 core，并通过显式别名引用最新 dist。
• 神煞规则不能统一套用“年干与日干”两个锚点；必须按每个神煞的标准查法指定锚点，并使用 pp.test 中的真实命例做回归测试。
• 大运切换必须同时切换该步大运对应的十年流年，不能让当前大运标题与首步大运流年混用。
• 排盘数据会进入服务端时，必须明确说明采集字段、保存目的与范围；免费排盘默认不上传，主动同意后才保存，同意版本需留档，公开写入接口必须限流。付费下单的报告快照应在下单前另行说明。

2026-09-25：邮件服务方案必须先确认代码可用

• 推荐邮箱 SMTP 服务前，先核对后端是否已实现对应协议；不能把“服务商支持 SMTP”说成“当前应用已经可以发信”。必须先完成实现和端到端验证，再指导用户配置凭证。