Dmitry Dementiev
f0370cdb90
- Зачем:
- переработку steady-stream генератора нужно передать агентам как набор
проверяемых вертикальных задач, а не как один крупный rewrite.
- Что:
- создан локальный набор из семи ready-for-agent задач для реализации новой
иерархической модели генератора.
- добавлен handoff с текущим состоянием обсуждения, рекомендуемым следующим
шагом через TDD и примером команды /goal для запуска задачи 01.
- Проверка:
- git diff HEAD~1 --stat.
37 lines
2.0 KiB
Markdown
37 lines
2.0 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`
|
|
|
|
## Comments
|
|
|