ddadminandClaude Fable 5
85f076e205
- Зачем:
- 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>
4.6 KiB
Status: done
Контракт модельного времени и стартовой истории
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