ddadmin
796c3f26a9
- Зачем: - нужен рабочий план для реализации модельного времени и стартовой истории. - Что: - добавлен parent PRD с инвариантами, зависимостями и review gate. - добавлены шесть локальных issue для последовательной работы. - добавлен handoff для продолжения в новой сессии. - Проверка: - git diff --check.
81 lines
6.0 KiB
Markdown
81 lines
6.0 KiB
Markdown
# Модельное время и стартовая история генератора
|
||
|
||
Status: Draft
|
||
|
||
## Зачем
|
||
|
||
Нужно довести решение ADR-0005 и ADR-0006 до рабочего процесса: генератор живёт
|
||
по модельному времени, умеет быстро создать прошлое, сохранить слепок состояния
|
||
и продолжить поток так, чтобы результат был проверяем в ClickHouse.
|
||
|
||
Источник решений:
|
||
|
||
- `docs/specs/2026-06-14-generator-model-time-and-startup-history.md`
|
||
- `docs/adr/0005-generator-model-clock.md`
|
||
- `docs/adr/0006-generation-as-sole-analytics-source.md`
|
||
- `docs/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]` и живого продолжения не должно быть дублей и дыр.
|
||
- Повторная проверка на чистом стенде должна быть воспроизводимой: либо команда
|
||
явно чистит данные, либо процесс идемпотентен.
|
||
|
||
## Задачи
|
||
|
||
1. `issues/01-time-and-startup-history-contract.md` — контракт модельного
|
||
времени и стартовой истории.
|
||
2. `issues/02-model-time-to-clickhouse.md` — минимальный поток по модельному
|
||
времени до ClickHouse.
|
||
3. `issues/03-model-speed-and-day-factor.md` — ×K и дневной коэффициент по
|
||
модельному времени.
|
||
4. `issues/04-state-v2-model-resume.md` — восстановление state v2 от модельной
|
||
точки возобновления.
|
||
5. `issues/05-startup-history-backfill-to-clickhouse.md` — промотка прошлого,
|
||
стартовая история и живое продолжение до ClickHouse.
|
||
6. `issues/06-generated-history-as-analytics-source.md` — штатный путь стенда
|
||
переводится на стартовую историю как источник аналитики.
|
||
|
||
## Контрольные точки
|
||
|
||
- После задачи 3 нужен внешний review gate по сквозному инварианту времени:
|
||
проверить, где ещё остались настенные часы, и не расходятся ли живой путь,
|
||
расчёт интенсивности и сохранение состояния.
|
||
- После задачи 5 нужен внешний review gate по распределениям и двум путям
|
||
генерации: проверить форму данных, стык истории и живого продолжения,
|
||
однородность визита до и после восстановления.
|
||
|
||
Для этих контрольных точек по возможности нужен reviewer другой родословной, а
|
||
не тот же worker: research показал, что сквозные свойства и форма распределений
|
||
хуже ловятся одной линией проверки.
|
||
|
||
## Финальная ручная приёмка
|
||
|
||
После задачи 6 человек смотрит Superset/Grafana и проверяет, что стенд живёт на
|
||
генерации: видны история, возвраты, воронка и суточное «дыхание». Если текущих
|
||
панелей не хватает для такого просмотра, создаётся отдельная задача на панель
|
||
или runbook, а не расширяется эта цепочка задним числом.
|