Dmitry Dementiev
48e3bf2900
- Зачем: - перед задачей активных визитов нужно отделить модель генератора от сервисной обвязки. - Что: - добавлена спека уборки сервиса генератора перед задачей 03. - добавлена промежуточная issue 02.5 с критериями приёмки. - уточнены требования к Dockerfile и временному тиковому слою. - задача 03 заблокирована новой задачей уборки. - Проверка: - просмотрен staged diff через `git diff --cached --stat`.
37 lines
2.1 KiB
Markdown
37 lines
2.1 KiB
Markdown
Status: ready-for-agent
|
|
|
|
# Поток по тикам с активными визитами
|
|
|
|
## What to build
|
|
|
|
Разложить визиты по тикам генератора. Визит может жить дольше одного тика:
|
|
генератор хранит активные визиты между вызовами, выпускает только те события,
|
|
чьё запланированное время наступило, и не приклеивает все события к текущему
|
|
тику.
|
|
|
|
Задача проверяет основную потоковую механику без Kafka и без восстановления
|
|
после рестарта.
|
|
|
|
Источник решений: `docs/specs/2026-06-10-generator-math-model.md`, раздел
|
|
«Раскладка по тикам».
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] Тест через публичный интерфейс генератора показывает, что один `click_id`
|
|
может появляться в выходе нескольких последовательных тиков.
|
|
- [ ] На каждом тике выпускаются только созревшие события активных визитов.
|
|
- [ ] `event_timestamp` отражает запланированное время события, а не время
|
|
фактической отправки тика.
|
|
- [ ] Завершённые визиты больше не выпускают события в следующих тиках.
|
|
- [ ] При достижении потолка активных визитов новые рождения в этот тик
|
|
пропускаются, а бюджет не копится бесконечно.
|
|
- [ ] Конфигурация запрещает состояние, где потолок активных визитов не меньше
|
|
потолка популяции пользователей.
|
|
|
|
## Blocked by
|
|
|
|
- `.scratch/feature-data-generator/issues/02-visit-page-path-and-monotonic-time.md`
|
|
- `.scratch/feature-data-generator/issues/02-5-generator-service-cleanup.md`
|
|
|
|
## Comments
|