ddadmin
796c3f26a9
- Зачем: - нужен рабочий план для реализации модельного времени и стартовой истории. - Что: - добавлен parent PRD с инвариантами, зависимостями и review gate. - добавлены шесть локальных issue для последовательной работы. - добавлен handoff для продолжения в новой сессии. - Проверка: - git diff --check.
6.0 KiB
6.0 KiB
Модельное время и стартовая история генератора
Status: Draft
Зачем
Нужно довести решение ADR-0005 и ADR-0006 до рабочего процесса: генератор живёт по модельному времени, умеет быстро создать прошлое, сохранить слепок состояния и продолжить поток так, чтобы результат был проверяем в ClickHouse.
Источник решений:
docs/specs/2026-06-14-generator-model-time-and-startup-history.mddocs/adr/0005-generator-model-clock.mddocs/adr/0006-generation-as-sole-analytics-source.mddocs/research/2026-06-11-subagent-coordinator-experiment.md
Общие правила приёмки
- Каждый кодовый срез должен заканчиваться проверкой через ClickHouse, а не только локальными тестами генератора.
- Быстрый цикл внутри задачи идёт через
/tdd: один поведенческий тест, минимальная реализация, зелёная проверка. - Координатор не работает в
/goalна всю цепочку. Один worker получает один issue, не коммитит и не реализует следующие задачи. - После реализации worker делает саморевью без правок. Координатор классифицирует находки и возвращает только обязательные исправления.
- Коммиты делает координатор после своих проверок и
git status --short. - Ручная проверка дашбордов глазами выполняется только в конце всей цепочки.
Сквозные инварианты
event_timestamp— модельное время, а не настенные часы компьютера.- Операционные метки сервиса, история пачек, метрики здоровья и длительность тика остаются настенным временем, если отдельная задача не докажет обратное.
- При одинаковых
GEN_SEED,T0, скорости и настройках поток повторяем. - При ×K модельное время и событийный бюджет идут по модельной длительности тика, а не по реальной длительности сна процесса.
- После сбоя точка возобновления считается из сохранённой связки модельного и
настенного времени, а не простым
datetime.now(). - Стартовая история — это события плюс слепок состояния плюс манифест, чтобы не
смешать данные от разных
GEN_SEED,T0иT_end. - На стыке
[T0, T_end]и живого продолжения не должно быть дублей и дыр. - Повторная проверка на чистом стенде должна быть воспроизводимой: либо команда явно чистит данные, либо процесс идемпотентен.
Задачи
issues/01-time-and-startup-history-contract.md— контракт модельного времени и стартовой истории.issues/02-model-time-to-clickhouse.md— минимальный поток по модельному времени до ClickHouse.issues/03-model-speed-and-day-factor.md— ×K и дневной коэффициент по модельному времени.issues/04-state-v2-model-resume.md— восстановление state v2 от модельной точки возобновления.issues/05-startup-history-backfill-to-clickhouse.md— промотка прошлого, стартовая история и живое продолжение до ClickHouse.issues/06-generated-history-as-analytics-source.md— штатный путь стенда переводится на стартовую историю как источник аналитики.
Контрольные точки
- После задачи 3 нужен внешний review gate по сквозному инварианту времени: проверить, где ещё остались настенные часы, и не расходятся ли живой путь, расчёт интенсивности и сохранение состояния.
- После задачи 5 нужен внешний review gate по распределениям и двум путям генерации: проверить форму данных, стык истории и живого продолжения, однородность визита до и после восстановления.
Для этих контрольных точек по возможности нужен reviewer другой родословной, а не тот же worker: research показал, что сквозные свойства и форма распределений хуже ловятся одной линией проверки.
Финальная ручная приёмка
После задачи 6 человек смотрит Superset/Grafana и проверяет, что стенд живёт на генерации: видны история, возвраты, воронка и суточное «дыхание». Если текущих панелей не хватает для такого просмотра, создаётся отдельная задача на панель или runbook, а не расширяется эта цепочка задним числом.