ddadmin
79c2c2657c
- Зачем: - ревью выявило слабые места в критериях приёмки модельного времени. - Что: - уточнены правила повторяемости, чистого прогона и review gate. - добавлены критерии для однородности визита через восстановление и T_end. - обновлён handoff с важными рисками для следующего агента. - Проверка: - git diff --check.
37 lines
2.3 KiB
Markdown
37 lines
2.3 KiB
Markdown
Status: ready-for-agent
|
|
|
|
# Модельное время до ClickHouse
|
|
|
|
## Parent
|
|
|
|
`.scratch/generator-model-time-startup-history/PRD.md`
|
|
|
|
## What to build
|
|
|
|
Сделать минимальный живой поток, где генератор стартует от `T0`, пишет
|
|
`event_timestamp` по модельному времени и доводит события до ClickHouse
|
|
обычным путём стенда. Срез должен доказать не внутренний класс часов, а
|
|
наблюдаемое поведение: данные в ClickHouse начинаются от модельной точки и
|
|
повторяются при тех же настройках.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [ ] При фиксированных `GEN_SEED` и `T0` первый короткий прогон пишет события с
|
|
модельными `event_timestamp`, начинающимися около `T0`.
|
|
- [ ] Повторный чистый прогон с теми же настройками даёт те же контрольные
|
|
числа в ClickHouse по правилу повторяемости из контракта задачи 1.
|
|
- [ ] Повторный чистый прогон явно сбрасывает или обходит старое состояние
|
|
генератора, чтобы сервис не продолжил прошлый запуск из `generator_state`.
|
|
- [ ] Расчёт дневного коэффициента в этом срезе больше не зависит от реального
|
|
часа запуска процесса.
|
|
- [ ] Локальные тесты проверяют поведение через публичный интерфейс генератора
|
|
или сервиса, без привязки к внутреннему устройству часов.
|
|
- [ ] Есть команда или короткая инструкция для координатора: поднять стенд,
|
|
прогнать поток, выполнить SQL-проверку в ClickHouse.
|
|
- [ ] Документация запуска не утверждает, что `event_timestamp` равен
|
|
настенному времени.
|
|
|
|
## Blocked by
|
|
|
|
- `.scratch/generator-model-time-startup-history/issues/01-time-and-startup-history-contract.md`
|