xsl
ecdfbb64c3
POST /quota/tasks/{task_key}/claim：配置驱动任务注册表、
grant_bonus 纯域函数、ledger 幂等键防重、task_bonus_max 封顶（FR-BILL-03/04）。
实现：packages/domain/billing/quota.py 新增 BonusDecision/grant_bonus（mypy strict，
恰好到顶允许、超一格整体拒绝）、grant_idempotency_key、PERIOD_TYPES；
packages/billing/service.py 新增 claim_task_bonus（幂等快捷路径 → 行锁 → 封顶判定
→ 同事务更新 bonus_granted 并写 system_grant 流水，delta=0 且 balance_after 按
remaining 口径；IntegrityError 并发兜底回滚为 40910）；响应模型 TaskBonusClaimResponse
放新建的 packages/billing/schemas.py；路由挂在 apps/api/routers/quota.py，
rules 由 settings.task_bonus_rules 注入（amount 为占位值，产品定稿后改 env）。
测试：新增单测 11 个（封顶边界、amount<=0、不动 used、hard_cap 独立生效、
默认规则形状与 env 覆盖通路）；新增集成 4 个（领取+重复 40910+纯 DB 流水断言、
五类任务全部到账、未知任务 40410、amount=11>max=10 → 40310 且无新流水）。
门禁全绿：ruff check / ruff format --check / mypy 两段 / lint-imports；
单测 180 passed，集成 7 passed。
偏差说明：1) 任务文档提到的 BillingService._load_rule 实际名为 _require_rule，
直接复用现有助手；2) packages/billing/repo.py 无需新增函数（现有
get_ledger_by_idempotency_key/lock_or_create_quota/add_ledger 已覆盖本任务）；
3) 文档设想的「TASK_BONUS_RULES_JSON 空值容错」经 env 源实测不成立——
pydantic-settings 对 dict 字段先做 JSON 解码，空白字符串在 Settings 构造时即
报错（共享校验器/config.py 属禁改，未动）；单测改为覆盖受支持的空配置形态 "{}"。
apps/ — 可部署的进程
| 目录 | 进程 |
|---|---|
api/ |
FastAPI 应用：路由、依赖注入、中间件 |
worker/ |
Celery 任务定义与四队列配置（gpu / cpu / io / beat） |
admin/ |
极简运营后台（占位，FR-ADM-01~05） |
API 层的职责边界（架构 §3.1 L3）
只做编排：认证鉴权、参数校验、幂等、配额校验与预扣、统一响应、OpenAPI。
不能放什么
- 业务规则。路由函数里出现
if判断业务条件，几乎总是应该下沉到packages/<域>/service.py或packages/domain/。 - 直接写 SQL 或用 ORM 查表。走域的
service。 - 直接调用外部 API。LLM 走
packages/llm；未来的审核、视觉、换装同理。 - 裸
dict返回。所有响应必须经过packages.shared.response.ok()/fail()。
契约先行（NFR-MAINT-01）
先在 apps/api/schemas.py 定义 Pydantic schema，再写实现。客户端类型由
OpenAPI 生成，schema 一变客户端立刻可见。
Worker 的规矩
- 每个长耗时任务都必须落
tk_task，走packages/task的状态机。 不要自己维护状态字段。 - 失败必须退还配额（
billing.refund()，FR-BILL-05）。apps/worker/tasks.py里的ping_task是形状示例。 - 队列按资源画像分：GPU 推理进
gpu，视觉/渲染进cpu，外部调用进io。 混队列会让「换装排队把报告拖慢」。