xsl
cf9d500bfa
SmsSender Protocol（fake/tencent）+ 验证码生命周期（哈希存储/一次性/ 5 次作废）+ 号码-IP-设备三重频控 + 掩码纪律（FR-ACC-04/14，TD-32； 真实发送待签名审核）。 实现：packages/identity/sms_login.py（SmsStore/SmsSender 双 Protocol、 FakeSmsSender 打日志、TencentSmsSender 包官方 SDK 失败映射 61000、 SmsAuthService 验证码生命周期 + UTC+8 时段桶频控）；路由 POST /auth/sms/send、POST /auth/sms/verify（provider="phone" 映射 + issue_session + TokenPairResponse，与华为通道零耦合）。测试：单测 37 个 （内存 dict 实现 store、注入时钟模拟 TTL；号码规范化/掩码/频控矩阵/ 验证码四要素/腾讯通道桩测），集成 7 个（send→verify 双令牌闭环、同号 同 user、脚本化刷量 11 发第 11 次 42911、IP/设备维度、错 5 次作废）。 门禁：ruff/mypy(identity+apps/api)/lint-imports 全绿，单测 275 通过、 集成 23 通过。 偏差说明： 1. SmsSender.send_code 收 (phone, masked, code) 三参而非单一「掩码键」： 腾讯通道下发必须有真实号码（掩码/哈希无法投递）；防泄漏由「实现层 不得记录 phone」约定 + structlog 全局手机号脱敏兜底。 2. 频控计数按「请求」计（含被拒请求）且在限额检查前自增：否则被拒 请求不烧额度，攻击者可无限试探；同时这是「连发 11 次第 11 次 42911」脚本化验收在真实时钟下成立的前提。 3. request_code 对 sender 逃逸的非 AppError 异常兜底包成 61000： 通道故障不得以 5xxxx 内部错误形式稀释告警（TencentSmsSender 自身 映射为主，此处仅接漏网）。 4. wire 请求模型（SmsSendRequest/SmsVerifyRequest）定义在 sms_login.py 内（任务文档允许的两选一，未新建 sms_schemas.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。 混队列会让「换装排队把报告拖慢」。