docs(generator): добавлены задачи по модельному времени

- Зачем:
  - нужен рабочий план для реализации модельного времени и стартовой истории.
- Что:
  - добавлен parent PRD с инвариантами, зависимостями и review gate.
  - добавлены шесть локальных issue для последовательной работы.
  - добавлен handoff для продолжения в новой сессии.
- Проверка:
  - git diff --check.

.scratch/generator-model-time-startup-history/PRD.md

@@ -0,0 +1,80 @@
+# Модельное время и стартовая история генератора
+
+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, а не расширяется эта цепочка задним числом.