docs(generator): issue 09 и 10 дооформлены до ready-for-agent

- Зачем:
  - закрыть последний шаг триажа: без Acceptance criteria и способа приёмки
    задачи нельзя передавать Codex на исполнение.
- Что:
  - issue 09: причина уточнена по коду (расходится источник фактуры — донор
    против seed_click_id, а не индекс), зафиксировано решение хранить донора
    в state, критерии расширены полями location (referer, utm) по итогам ревью.
  - issue 10: приёмка по скриншотам playwright-cli с определением «читаемо»,
    поправлена длительность пересборки (6 часов по умолчанию, не 2 суток),
    отмечено, что legacy world_map, похоже, не умеет легенду и tooltip.
  - handoff триажа дополнен сдвигами в понимании и итогом тройного ревью.
- Проверка:
  - утверждения по коду сверены с generation.py, runtime.py, state.py и
    sql/ddl/dds/30_dds.sql двумя независимыми ревью-агентами.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.scratch/handoffs/2026-07-04-generator-backlog-triage.md

@@ -43,20 +43,34 @@
 
 ## Следующий шаг
 
-Дооформить до `ready-for-agent` два независимых issue (можно параллельно с
-остальной очередью):
+Весь бэклог готов к передаче Codex: `/goal` на отдельные задачи (09 и 10
+независимы, можно параллельно) или `/coordinator-loop` на цепочки 07 -> 08 и
+07 -> 11 -> 12. Задача 13 — после фикса 09.
 
-1. **09 — баг браузерной фактуры на стыке.** Нет секции Acceptance criteria;
-   зафиксировать выбор направления фикса (сериализация фактуры в state против
-   выбора по абсолютному `event_index`; второе не трогает схему state) и
-   требование теста по per-event полям `dds.event`, включая crash-recovery
-   (гипотеза: тот же restore-механизм). Режим ревью — гейт (state).
-2. **10 — гео-карта.** Прописать способ приёмки (Playwright-скриншоты, что
-   считать «читаемо»); учесть, что стенд с 14 июня мог умереть, а полная
-   пересборка регенерирует backfill.
+## Дооформление 09 и 10 — что изменилось против прежнего понимания
 
-После этого весь бэклог готов к передаче Codex (`/goal` на задачу или
-`/coordinator-loop` на цепочку 07 -> 08 / 07 -> 11 -> 12).
+Сделано в этот же день, вторым заходом. 09 и 10 переведены в `ready-for-agent`;
+детали — в самих issue, здесь только сдвиги в понимании:
+
+- **Гипотеза по 09 не подтвердилась.** Дело не в рассинхроне `event_index`, а в
+  источнике фактуры: при рождении визита браузерные строки берутся у случайного
+  «донора» из словаря, при восстановлении — у `seed_click_id` пользователя.
+  Прежняя развилка «выбор по абсолютному индексу, не трогая схему state»
+  оказалась нерабочей — restore не знает донора. Решение пользователя: хранить
+  `base_click_id` донора в state (альтернативы и причины отказа — в issue).
+- **Дефект 09 шире браузера** (нашло ревью): per-event поля location (referer,
+  utm) расходятся на стыке так же — критерии приёмки расширены, иначе частичный
+  фикс «только браузер» прошёл бы приёмку. Расхождение event_id (uuid4 при
+  рождении, uuid5 при restore) зафиксировано как известное и вне скоупа.
+- **По 10 сняты две мины:** пересборка по умолчанию даёт 6 часов истории, а не
+  2 суток (профиль «2 суток одной командой» — это ещё не сделанная задача 11);
+  legacy-виз `world_map`, похоже, вообще не умеет легенду и tooltip — основной
+  путь, вероятно, смена типа визуализации, а не настройка (проверить через
+  Context7 при реализации).
+- **Процессная заметка:** дооформленные issue прогнаны через тройное ревью
+  (самопроверка + два свежих агента, адверсарно, с проверкой каждого утверждения
+  по коду). Улов оправдал затраты — см. пункты выше; для issue с режимом «гейт»
+  так стоит делать и дальше.
 
 ## Не забыть (вне бэклога)