Dmitry Dementiev
f0370cdb90
- Зачем:
- переработку steady-stream генератора нужно передать агентам как набор
проверяемых вертикальных задач, а не как один крупный rewrite.
- Что:
- создан локальный набор из семи ready-for-agent задач для реализации новой
иерархической модели генератора.
- добавлен handoff с текущим состоянием обсуждения, рекомендуемым следующим
шагом через TDD и примером команды /goal для запуска задачи 01.
- Проверка:
- git diff HEAD~1 --stat.
2.5 KiB
2.5 KiB
Status: ready-for-agent
Интенсивность и калибровка потока
What to build
Связать иерархическую модель с целевой интенсивностью потока. Старая идея Пуассона, часового коэффициента и jitter должна задавать бюджет активности, из которого рождаются визиты; фактические события выходят по запланированным паузам активных визитов.
На этом шаге также нужно проверить, что параметры модели дают поток,
сопоставимый с профилем сида: длина визита около 10 событий в среднем и по
медиане, доля дошедших до /confirmation около 25%, межсессионные паузы
согласованы с формулой из спеки.
Источник решений: docs/specs/2026-06-10-generator-math-model.md, разделы
«Связка с моделью интенсивности», «Параметры» и «Критерии приёмки».
Acceptance criteria
- Средняя интенсивность событий за длинное окно соответствует
GEN_LAMBDA_BASE_PER_MIN * часовой коэффициентс разумным отклонением. - Рождения визитов рассчитываются из бюджета событий и средней длины визита,
а не из старых границ
GEN_MIN/MAX_EVENTS_PER_TICKв прежнем смысле. - Доля новых пользователей за длинное окно близка к
GEN_P_NEW_USER. - Межсессионные паузы одного пользователя не меньше кулдауна, а среднее на дефолтах находится в районе расчёта из спеки.
- Распределение длины визита на симуляции сопоставимо с сидом: медиана около 10, среднее около 10, максимум не выше потолка.
- Воронка по шагам
/home -> товары -> /cart -> /payment -> /confirmationмонотонно затухает на длинной симуляции.
Blocked by
.scratch/feature-data-generator/issues/04-user-population-and-returns.md