R-001 — Progresso de aula persiste direto e de forma síncrona

TLDR: POST /engagements/progress/lesson chama LessonProgressService.save_progress diretamente no ciclo de request/response — sem task Celery, sem rate limit e sem buffer no Redis.

Given / When / Then

Dado que um usuário envia a posição de assistir da aula para POST /engagements/progress/lesson Quando a requisição é recebida Então o progresso é persistido de forma síncrona via LessonProgressService.save_progress, e o resultado {lesson_id, user_id, position, completed} é retornado no response

Restrições

• Não deve adiar a persistência para uma task Celery neste endpoint — o response reflete o estado já salvo
• Não deve aplicar rate limit nem bufferizar as requisições de progresso de aula no Redis — esse mecanismo foi removido para aulas. ProgressService.register_hit_exceeds_rate_limit / store_latest_position continuam em uso para os outros tipos de conteúdo (áudio, meditação, live)

Teste vinculado

tests/engagements/test_serializers_views_urls.py — test_progress_lesson_view_post_saves_progress_directly

Histórico

Esta regra substitui a versão anterior, em que o progresso era despachado por task Celery e caía num buffer no Redis quando o usuário excedia 3 requisições em 30 segundos. Ver specs/20260710112204_progress_direct_persist_rate_limit.md para o desenho anterior e specs/20260612142912_progress_buffer_redis_flush.md para a origem do buffer.