docs: add signup bonus requirement

docs/05-coding-rules.md

@@ -6,7 +6,7 @@
 ## 0. 黄金法则
 
 1. **不臆造**：数据字段、文件、接口、依赖、支付回调字段，不确定就查证或询问。
-2. **守范围**：只做当前任务要求的事，不顺手加后续功能（如异步队列、报表、注册赠点）。
+2. **守范围**：只做当前任务要求的事，不顺手加后续功能（如异步队列、报表、复杂活动赠点）。
 3. **照架构**：使用既定技术栈（Django+DRF+admin）和模块边界，不擅自引入新框架。
 4. **小步改**：一次只解决一个问题，不夹带无关重构。
 5. **可验证**：改完必须能迁移、能测试、对得上验收标准。
@@ -28,7 +28,7 @@
 ## 3. 范围纪律
 
 - MVP 只做 `02-requirements.md` 中列为 P0 的功能。
-- V2 / V3 功能（异步队列、报表、注册赠点、自动退款对账）只记录，不实现。（自助注册/扫码充值/API Key 管理已纳入 MVP）
+- V2 / V3 功能（异步队列、报表、复杂活动赠点 / 邀请奖励、自动退款对账）只记录，不实现。（自助注册/扫码充值/API Key 管理已纳入 MVP；新用户一次性注册送 100 点已拆为 T-608）
 - 需求明确排除的非目标不得实现（自建收银台、多币种、分账等）。
 - 不为“将来可能用到”提前抽象。
 
@@ -37,6 +37,7 @@
 - 技术栈以 `03-tech-stack.md` 为准；新增依赖前先说明理由，未经确认不引入重量级依赖（Celery、Redis 等）。
 - 模块职责以 `04-architecture.md` 为准，不跨层偷写逻辑。
 - **点数余额只能经 `apps/billing` 修改**：余额存 `UserWallet`（与 auth `User` 分离），扣点锁 wallet 行；API 层/Admin/用户端都不得直接写 `points_balance`。
+- **注册赠点也只能经 `apps/billing` 修改**：T-608 的 100 点试用额度必须走 `grant_signup_bonus()` 这类计费层服务，写 `PointsLedger(signup_bonus)`，不得在 allauth adapter、view 或 signal 里直接把钱包余额设为 100。
 - **API Key 哈希存储**（sha256），明文只在生成时返回一次；不存明文、任何页面不回显。
 - **对外 API 只挂 API Key 认证，不挂 SessionAuthentication**；用户端页面用 session + CSRF；自助注册**免邮箱验证**（`ACCOUNT_EMAIL_VERIFICATION="none"`，邮箱仍必填且唯一）、生成接口须限流。
 - **用户端与后台账号分离**：portal 与 `/admin/` 共用同一个 Django 会话（同一 `sessionid`），后台访问只多一道 `is_staff` 门槛。因此 **终端用户一律 `is_staff=False`**（普通用户登 portal 进不了后台，无泄露）；**运营用专用 admin superuser 登录 `/admin/`，不要拿这个账号登 portal**——账号分离（方案 A）就是「解耦入口」的正解，不要为同账号双会话去拆 cookie/子域名。详见 `04-architecture.md`。
@@ -90,6 +91,7 @@ python manage.py runserver
 - **回调防护与兜底**：支付回调端点必须 `@csrf_exempt`（网关调用无 CSRF token）；回调可能丢失，须提供按 `order_no` 主动查单兜底，避免已付款却一直 pending。
 - **失败必退**：调用上游失败时，已预扣的点数必须冲正退回。
 - **全程留痕**：每笔点数变动写 `points_ledger`，每次调用写 `call_record`，运营手工调整必须填原因。
+- **注册赠点幂等**：新用户 100 点试用额度必须有数据库级幂等保护，同一用户无论注册回调、重试或并发触发多少次，都最多发放一次；不得用 MySQL 不支持的条件唯一约束。
 - **敏感信息**：密钥/凭证只用环境变量或后台配置，不写真实值进代码与文档。
 - 资金相关改动必须有对应测试（并发扣点、重复回调、上游失败退点至少各一条）。
 - 不绕过支付系统的鉴权、验签或风控。