ddadmin
79c2c2657c
- Зачем: - ревью выявило слабые места в критериях приёмки модельного времени. - Что: - уточнены правила повторяемости, чистого прогона и review gate. - добавлены критерии для однородности визита через восстановление и T_end. - обновлён handoff с важными рисками для следующего агента. - Проверка: - git diff --check.
3.8 KiB
3.8 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 только ссылается на источник истины.
Blocked by
None - can start immediately