ddadmin
31a71f93ea
- Зачем: - нужно закрепить принятое человеком HITL-решение до кодовых задач 02-06. - Что: - добавлен рабочий контракт настроек, хода часов, state, манифеста и ClickHouse-проверки. - выбран один живой ход часов через фиксированный модельный шаг без отдельной матрицы драйверов. - уточнена граница стартовой истории как [T0, T_end) и закрыт чек-лист issue 01. - Проверка: - git diff --cached --check.
66 lines
4.6 KiB
Markdown
66 lines
4.6 KiB
Markdown
Status: ready-for-human
|
||
|
||
# Контракт модельного времени и стартовой истории
|
||
|
||
## Parent
|
||
|
||
`.scratch/generator-model-time-startup-history/PRD.md`
|
||
|
||
## What to build
|
||
|
||
Зафиксировать рабочий контракт для реализации модельного времени и стартовой
|
||
истории. Это HITL-срез: до кода нужно решить внешний интерфейс, формат
|
||
стартовой истории и правила восстановления, чтобы worker-и не угадывали
|
||
поведение через тесты.
|
||
|
||
Контракт должен остаться коротким и понятным: что задаёт `T0`, как задаётся ×K,
|
||
что такое `T_end`, как выглядит стартовая история, какие метки времени
|
||
модельные, а какие операционные.
|
||
|
||
## Acceptance criteria
|
||
|
||
- [x] Выбраны имена и формат настроек для `T0`, скорости ×K и режима промотки
|
||
прошлого.
|
||
- [x] Описан живой ход часов: модельное время идёт фиксированным шагом
|
||
`tick_seconds * K`; измеренный настенный интервал между тиками не входит в
|
||
текущий контракт.
|
||
- [x] Разделены уровни повторяемости: точная повторяемость промотки прошлого и
|
||
точная повторяемость живого режима при тех же настройках и числе успешных
|
||
тиков.
|
||
- [x] Описано, как после сбоя вычисляется модельная точка возобновления при ×K:
|
||
из сохранённой модельной метки, сохранённой настенной метки и скорости.
|
||
- [x] Описано, что короткий и долгий простой считаются по модельному времени:
|
||
при большом ×K короткий настенный простой может стать долгим модельным.
|
||
- [x] Описан манифест стартовой истории: минимум `GEN_SEED`, `T0`, `T_end`,
|
||
настройки генерации, версия state и контрольные числа.
|
||
- [x] Описана граница `T_end`: где заканчивается прошлое и с какой метки
|
||
начинается живое продолжение, без дублей и дыр.
|
||
- [x] Разделены модельные метки событий и настенные операционные метки сервиса.
|
||
- [x] Зафиксирован часовой пояс модельных часов для дневного коэффициента.
|
||
- [x] Решено, как координатор будет получать повторяемую ClickHouse-проверку:
|
||
через очистку данных или идемпотентный прогон.
|
||
- [x] Если выбран чистый прогон, перечислены поверхности сброса: таблицы
|
||
ClickHouse, Kafka-топики данных и состояние генератора (`generator_state` или
|
||
явный сброс состояния при старте).
|
||
- [x] Контракт записан в 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
|