- Зачем:
- follow-up задачи после ревью 2026-06-14 лежали без триажа; решения по
артефакту, громкому отказу и интерфейсу приняты 2026-07-04 и должны
попасть в задачи до передачи исполнителю.
- Что:
- задачи 07 (миграция курса) и 08 (артефакт) поменяны местами — номера
отражают порядок; ссылки обновлены.
- 07 (артефакт + runbook) дооформлен: импорт строго через Kafka (напрямую
в ClickHouse не пишет), громкий отказ при несовместимом state с правкой
спеки, граница runbook «использование, не устройство»; ready-for-agent.
- 08 дооформлен: устройство генератора вне пути менти, реальный объём
(make data во всех уроках 00-05), демо вне скоупа; ready-for-agent.
- новые задачи: 11 глаголы/длительность/профили (после 07, до 12),
12 Airflow-DAG как пульт (приоритет поднят), 13 доливка (после 09).
- задачи 01-06 переведены в done (стояли ошибочные ready-for-human);
PRD фичи дополнен списком задач 7-13 с порядком и зависимостями.
- Проверка:
- head -1 .scratch/generator-model-time-startup-history/issues/*.md;
grep по старым именам файлов ничего не находит вне handoff.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
52 lines
3.3 KiB
Markdown
52 lines
3.3 KiB
Markdown
Status: done
|
|
|
|
# Модельное время до ClickHouse
|
|
|
|
## Parent
|
|
|
|
`.scratch/generator-model-time-startup-history/PRD.md`
|
|
|
|
## What to build
|
|
|
|
Сделать минимальный живой поток, где генератор стартует от `T0`, пишет
|
|
`event_timestamp` по модельному времени и доводит события до ClickHouse
|
|
обычным путём стенда. Срез должен доказать не внутренний класс часов, а
|
|
наблюдаемое поведение: данные в ClickHouse начинаются от модельной точки и
|
|
повторяются при тех же настройках.
|
|
|
|
## Acceptance criteria
|
|
|
|
- [x] При фиксированных `GEN_SEED` и `T0` первый короткий прогон пишет события с
|
|
модельными `event_timestamp`, начинающимися около `T0`.
|
|
- [x] Повторный чистый прогон с теми же настройками даёт те же контрольные
|
|
числа в ClickHouse по правилу повторяемости из контракта задачи 1.
|
|
- [x] Повторный чистый прогон явно сбрасывает или обходит старое состояние
|
|
генератора, чтобы сервис не продолжил прошлый запуск из `generator_state`.
|
|
- [x] Расчёт дневного коэффициента в этом срезе больше не зависит от реального
|
|
часа запуска процесса.
|
|
- [x] Локальные тесты проверяют поведение через публичный интерфейс генератора
|
|
или сервиса, без привязки к внутреннему устройству часов.
|
|
- [x] Есть команда или короткая инструкция для координатора: поднять стенд,
|
|
прогнать поток, выполнить SQL-проверку в ClickHouse.
|
|
- [x] Документация запуска не утверждает, что `event_timestamp` равен
|
|
настенному времени.
|
|
|
|
## Решение
|
|
|
|
Живой сервис получает модельную точку из `GEN_MODEL_T0`, считает дневной
|
|
коэффициент по модельному времени и передаёт эту же точку в тиковый поток. После
|
|
успешного тика модельная точка сдвигается на
|
|
`GEN_TICK_SECONDS * GEN_MODEL_TIME_SPEED`.
|
|
|
|
Проверка ClickHouse выполнена двумя чистыми прогонами с `GEN_STATE_RESET=true`.
|
|
Оба раза получены одинаковые контрольные числа: 5 событий, диапазон
|
|
`event_ts = 2026-01-01 10:00:00.000000`, 5 уникальных `event_id` и 5 уникальных
|
|
`click_id`.
|
|
|
|
Риски по восстановлению state v2 оставлены для задачи 04: текущий срез
|
|
доказывает чистый live-старт, а не возобновление после сбоя.
|
|
|
|
## Blocked by
|
|
|
|
- `.scratch/generator-model-time-startup-history/issues/01-time-and-startup-history-contract.md`
|