fix: reduce signup bonus to ten points

progress.md

@@ -2001,3 +2001,28 @@
 - 安全回归：完整 `GenerateApiTests` 首次运行 53 条时发现旧 `image_url` 会因新多图单图限制而绕过 `IMAGE_URL_MAX_BYTES`。已修复为 URL 下载取既有 URL 上限与请求上下文单图上限中的较小值，恢复旧接口保护语义。
 - 文档：同步更新 `README.md`、`00-ai-start-here.md`、`02-requirements.md`、`04-architecture.md`、`api.md`、`routes.md`、`env.md`、`deployment.md`、`current-state.md` 与任务看板，明确多图请求格式、主图 / 参考图语义、异步存储和 Nginx 请求体配置。
 - 验证：`C:/Python312/python.exe -m compileall -q apps config`、`manage.py check`、`manage.py makemigrations --check --dry-run` 通过；迁移 `api.0003_image_generation_task_input` 已应用到当前开发库。Provider 测试 13 条通过；序列化器多图、空数组与混用边界通过；目标 API 6 条通过（同步多图、URL+base64 混合、混用拒绝、超限拒绝、异步存储 / worker 恢复、旧 URL 上限）。完整 53 条 `GenerateApiTests` 的修复后重跑受远程 MySQL 测试库耗时影响超过 5 分钟未完成，未出现新的失败输出；此前完整运行唯一失败已修复并由目标回归用例确认。中转站两图 `images/edits` 重复 multipart `image` 直连验收此前返回 HTTP 200 和有效图片，作为真实上游多文件传输证据。
+
+## 2026-07-18 文档登记：T-621 注册赠点运营后台配置
+
+- 背景：当前新用户赠点由 `grant_signup_bonus(points=100)` 的代码默认值决定，既不读取 `.env`，也不能在 django-admin 调整。运营需要在不重启服务的前提下管理未来新注册用户的试用额度。
+- 决策：新增数据库单例 `SignupBonusPolicy`，默认启用并赠送 100 点；admin 只能编辑，不允许新增或删除。配置改动须写独立只读审计记录，避免将 Django `LogEntry` 作为唯一业务审计。
+- 账务口径：赠点服务在同一事务内读取策略、锁钱包并创建既有 `SignupBonusGrant(user UNIQUE)`。策略停用时仍写 `points_granted=0` 的决定记录、不写零额流水，防止注册回调重试或后续重新开启策略对同一用户补发；历史用户的已发点数、流水和余额不回算。
+- 任务文档：`docs/06-tasks.md` 新增 T-621 和 M17；`docs/current-state.md` 更新为下一可领取任务。未改代码、数据库或线上配置。
+
+## 2026-07-18 评审修订：T-621 卡片按设计评审优化
+
+- 背景：对 T-621 卡片做实现前评审，发现并发锁语义、约束设计和若干实现细节可优化，已把结论落回 `docs/06-tasks.md` 的 T-621 描述。未改代码 / 数据库。
+- 并发锁（重要）：原措辞「配置修改和注册赠点行锁序列化」会导致对策略单例行 `pk=1` 加排他锁、把所有注册全局串行化。修订为：策略只做只读快照（不 `select_for_update`），单用户幂等由 `SignupBonusGrant(user UNIQUE)` + 钱包行锁保证，不同用户注册不相互阻塞。
+- 约束简化：`points` 由「启用 1..10000 / 停用 0..10000」两套条件约束，简化为 DB 统一 `0 <= points <= 10000`，「启用需 >= 1」放表单 / `clean()` 层校验；停用时 `points` 不参与发放。
+- 实现细节明确：`grant_signup_bonus()` 移除 / 忽略 `points` 入参（一律以策略为准，避免双真相源）；停用 `points=0` 路径必须绕过 `_validate_positive_points`（其拒绝 `<= 0`，否则连带回滚用户创建）。
+- 可读性：`SignupBonusGrant` 现含赠 0 决定记录，`verbose_name` / 列表展示澄清为「注册赠点处理记录（含赠 0）」；`points` 上限 `10000` 在 `help_text` 注明口径来源。
+- 测试补充：停用 `points=0` 不被正数校验误杀；不同用户并发注册不因策略读取相互串行 / 阻塞。
+
+## 2026-07-18 决策：T-621 移入 Backlog，注册赠点调整为 10 点
+
+- 决策：T-621「注册赠点运营后台配置」不再作为可领取任务，移入 `docs/06-tasks.md` 的 Backlog；不新增 `SignupBonusPolicy`、审计表或 admin 配置，当前额度继续由代码默认值控制。
+- 口径：后续新注册用户一次性赠送 **10 点**；已注册用户的余额、注册赠点记录与流水不回算、不补发、不扣回。
+- 实现：`grant_signup_bonus()` 默认值、`SignupBonusGrant.points_granted` 默认值、用户端注册/首页文案和相关 billing / portal 测试同步改为 10；新增 `billing.0009_signup_bonus_default_ten`，仅更新后续插入记录的数据库默认值。
+- 安全：仍复用既有 `SignupBonusGrant(user UNIQUE)` 数据库级幂等标记和 billing 事务写账；此次只调整额度，不改变注册接入、钱包锁、流水或 API 契约。
+- 本地验证：`C:/Python312/python.exe manage.py migrate --noinput` 已应用 `billing.0009_signup_bonus_default_ten`；`manage.py check` 0 issues；`makemigrations --check --dry-run` 无待生成迁移；`compileall` 通过。定向 MySQL 测试 5 条通过：服务默认发放 / 已有钱包累加 / 并发仅发一次 / 注册 adapter 写余额与流水 / 首页匿名文案。测试仅出现既有 allauth 条件唯一约束在 MySQL 上不创建的 `models.W036` 警告。
+- 线上部署结果将在本次提交后补充。