Files
clickstream-ch-kafka-supers…/.scratch/generator-model-time-startup-history/issues/01-time-and-startup-history-contract.md
T
ddadmin 31a71f93ea docs(generator): зафиксирован контракт модельного времени
- Зачем:
  - нужно закрепить принятое человеком HITL-решение до кодовых задач 02-06.
- Что:
  - добавлен рабочий контракт настроек, хода часов, state, манифеста и ClickHouse-проверки.
  - выбран один живой ход часов через фиксированный модельный шаг без отдельной матрицы драйверов.
  - уточнена граница стартовой истории как [T0, T_end) и закрыт чек-лист issue 01.
- Проверка:
  - git diff --cached --check.
2026-06-14 16:30:15 +03:00

4.6 KiB

Status: ready-for-human

Контракт модельного времени и стартовой истории

Parent

.scratch/generator-model-time-startup-history/PRD.md

What to build

Зафиксировать рабочий контракт для реализации модельного времени и стартовой истории. Это HITL-срез: до кода нужно решить внешний интерфейс, формат стартовой истории и правила восстановления, чтобы worker-и не угадывали поведение через тесты.

Контракт должен остаться коротким и понятным: что задаёт T0, как задаётся ×K, что такое T_end, как выглядит стартовая история, какие метки времени модельные, а какие операционные.

Acceptance criteria

  • Выбраны имена и формат настроек для T0, скорости ×K и режима промотки прошлого.
  • Описан живой ход часов: модельное время идёт фиксированным шагом tick_seconds * K; измеренный настенный интервал между тиками не входит в текущий контракт.
  • Разделены уровни повторяемости: точная повторяемость промотки прошлого и точная повторяемость живого режима при тех же настройках и числе успешных тиков.
  • Описано, как после сбоя вычисляется модельная точка возобновления при ×K: из сохранённой модельной метки, сохранённой настенной метки и скорости.
  • Описано, что короткий и долгий простой считаются по модельному времени: при большом ×K короткий настенный простой может стать долгим модельным.
  • Описан манифест стартовой истории: минимум GEN_SEED, T0, T_end, настройки генерации, версия state и контрольные числа.
  • Описана граница T_end: где заканчивается прошлое и с какой метки начинается живое продолжение, без дублей и дыр.
  • Разделены модельные метки событий и настенные операционные метки сервиса.
  • Зафиксирован часовой пояс модельных часов для дневного коэффициента.
  • Решено, как координатор будет получать повторяемую ClickHouse-проверку: через очистку данных или идемпотентный прогон.
  • Если выбран чистый прогон, перечислены поверхности сброса: таблицы ClickHouse, Kafka-топики данных и состояние генератора (generator_state или явный сброс состояния при старте).
  • Контракт записан в durable-документ: обновление PRD.md, короткий design note в .scratch/generator-model-time-startup-history/ или уточнение спеки. Сам issue 01 только ссылается на источник истины.

Решение

Контракт записан в durable-документ: docs/specs/2026-06-14-generator-model-time-and-startup-history.md, раздел «Рабочий контракт реализации».

PRD ссылается на этот раздел в сквозных инвариантах. Для следующих задач важная граница: стартовая история покрывает [T0, T_end), а живое продолжение стартует из слепка на T_end.

Дополнительную матрицу «фиксированный шаг / измеренная настенная дельта» не вводим: ADR-0005 не требовала такого публичного выбора, а текущей учебной цепочке нужен один повторяемый живой ход часов.

Blocked by

None - can start immediately