# AI Film Project — Start Here v5.1

> **01.11.2026 — ChatGPT / Work / Grok Bot:** роли, расписания, общий замок, защита от дублей и границы доказанной готовности — `ops/LAUNCHER-COORDINATION.md`; живой реестр — `ops/slot-backup.json`. Копии и прежние отчёты не переопределяют этот реестр.

> **27.10.2026 — «Продолжай»:** явный фокус задачи, проверяемый checkpoint и доказательства, компактный пакет и восстановление после обрыва — `ops/CONTINUE-PROTOCOL.md`. Пакет не разрешает внешние действия; живые проверки и полный fallback сохраняются.

> **23.10.2026 — точные статусы и отпечаток.** Готовность показывать по каждой части: слот / исходный результат / подготовка и QC стыка / отдельный референс / решение владельца. Существующий робот строит `ops/queue-readiness.json`; success не делает вход готовым. Сайт обновляет также master/status/сертификат, сохраняя черновики. Процедура и источники — `ops/QUEUE-READINESS.md`. Новая62 — мост к червям; кабина37/39/40/41/52/53/59/60 — очищенный `S37-cockpit-empty.png`, без людей и мечей.

**Назначение:** главная операционная инструкция проекта для текущего редактора и любого следующего чата / сменщика: обзор проекта, приём смены и поведение агента. Механика записи, синхронизации, робота и Topview — `SYNC-RUNBOOK.md`; здесь — одна строка и ссылка.
**Редакция:** 18.10.2026 — убраны повторы между инструкциями (одно правило — одно место); генеральная зачистка 11–14.10.2026 до этого. Прежние тексты — `git log` и `archive/instructions-before-cleanup-2026-10-14/AI-PROJECT-GUIDE.md` (только справка, не канон).

> **Источник истины (решение владельца 11.10.2026, 03:25 МСК).** Канон один — GitHub `virudik/ai-film-prompts`, ветка `main`: `video-prompts.md` и ровно 7 инструкций. Google Drive, Notion, Claude Project, ChatGPT Project и Library — резервные копии только для чтения, никогда не правятся вместо канона и не переопределяют `main`. Правка = минимальный коммит в `main`; authority и процедуры — `SYNC-RUNBOOK.md`. Свежий `main` всегда побеждает.

**Где живёт каждое правило.**

| Тема | Где |
|---|---|
| Authority, запись в канон, один писатель, проверка «готово» | `SYNC-RUNBOOK.md` (верх, §1–9, §14) |
| Робот, мониторы, внешний запуск, архив MP4 | `SYNC-RUNBOOK.md` (верхние блоки, «Мониторы и расписание») |
| Topview: slow, слоты, телеметрия, привязка задач | `SYNC-RUNBOOK.md` (§10, §18, «Canonical Topview state») |
| Кнопки владельца и `owner_task` | `SYNC-RUNBOOK.md` «Кнопки владельца и задачи текстом»; для владельца — `USER-GUIDE.md` §20 |
| Валидатор, сайт, комментарии | `SYNC-RUNBOOK.md` §6, §11, «Валидатор, health и Control Center» |
| Референсы (reference-first, QC, запуск сцены) | `SYNC-RUNBOOK.md` «Scene Reference Pack automation» |
| Как писать промты, выбор движка | `PROMPT-STYLE-GUIDE.md` |
| Приём смены, master, поведение агента, персонажи, монтаж | этот файл |
| Что видит и делает владелец | `USER-GUIDE.md` |
| Карта репозитория, хранилищ, workflow и скриптов | `README-AI-SYNC.md` |
| Резервные копии и восстановление | `BACKUP-AI-RUNBOOK.md` |

## Формат takeover и решение D7

- **Цель владельца:** не передавать смену вручную каждые несколько часов и не терять ни решений, ни требований, ни проверок. Решения, технические детали и checkpoint уже лежат в каноне `main` и живых статусах; память Project и сам разговор — не authority.
- **Claude — один долгоживущий рабочий чат** (решение 11.10, 02:06): длинные чаты сжимаются автоматически (платный план + «Выполнение кода»); после сжатия и по команде «Продолжай» чат перечитывает верхний блок `NEW-CHAT-HANDOFF.md`, `claude/CURRENT-STATE.md` (Claude Project) и открытые задачи владельца; всё важное сразу записывается в канон.
- **Приём смены — короткий (D7) или полный.** **Короткий приём смены (D7, решение владельца 14.10.2026).** Новый чат может принять смену, не читая все 7 инструкций: (1) `git pull` в `main`; (2) `shadow/takeover-brief.md` — «Валиден при генерации: True» и все 15 правил ✓; (3) `shadow/current-checkpoint.md` целиком (= верхние блоки `NEW-CHAT-HANDOFF.md` дословно); (4) живые `project-status.json`, `topview-status.json`, `instruction-sync-status.json`, `automation-monitor-status.json`, `monitor-role.json` и открытые `owner_decisions` в Supabase; (5) под задачу — полные разделы из «Что читать под задачу» в брифе (промты — `PROMPT-STYLE-GUIDE.md` целиком + сцена и соседние; новая сцена — ещё разделы `SYNC-RUNBOOK.md` о новой сцене и приёме задач Topview; сюжет — `film-analysis.md`, `film-backlog.md`, Notion «Кино»; Topview — разделы `SYNC-RUNBOOK.md` о цикле и слотах). **Полное чтение 7 инструкций обязательно**, если: бриф невалиден или в нём есть «✕ ANCHOR MISSING»; задача правит любую из 7 инструкций или это материальное изменение workflow / сайта / authority / восстановления; восстановление после сбоя; задача затрагивает синхронизацию, расписание, семантику слотов или общие правила нескольких сцен; по брифу нельзя уверенно ответить на обязательный вопрос; владелец просит «полный приём»; любое сомнение. В докладе о готовности указать, какой приём использован (короткий или полный). Бриф строит робот (`scripts/build_takeover_brief.py`, workflow `shadow-brief.yml`) при каждом изменении канона; это навигатор, не authority — свежий `main` всегда важнее (`SYNC-RUNBOOK.md` «Бриф для короткого приёма»).
- **Критерии, по которым D7 принят и которые продолжают действовать:** не хуже полного чтения по контрольным задачам (проверка 30 вопросов 14.10 — `reports/cleanup-2026-10-14/`); ноль пропущенных решений владельца, нарушений authority / approval / slow-lock и ложных подтверждений; 100% возврат к полному чтению при любом триггере; периодический полный cross-document audit сохраняется. Если короткий приём хоть раз привёл к ошибке из-за пропущенного правила — записать инцидент в хендоф и сообщить владельцу (он может отменить D7).
- **ChatGPT:** восстановление по «Продолжай» реализовано в `ops/CONTINUE-PROTOCOL.md`: настройки Project указывают на свежий протокол, выбранный этап проверяется по доказательствам. Это не управляет лимитами интерфейса; отдельная разработка API-сессии не входит в текущий workflow.

## 1. Takeover gate — что обязательно прочитать до начала работы

Новый чат **не вступил в роль редактора**, пока не прошёл короткий приём D7 или полный приём по условиям выше. Восстановление после сбоя — всегда полный приём. При полном приёме все 7 документов из `main` читаются в порядке:

1. `NEW-CHAT-HANDOFF.md` (верхние блоки — живое состояние)
2. `SYNC-RUNBOOK.md`
3. `AI-PROJECT-GUIDE.md` — этот файл
4. `PROMPT-STYLE-GUIDE.md`
5. `USER-GUIDE.md`
6. `README-AI-SYNC.md`
7. `BACKUP-AI-RUNBOOK.md`

После них обязательно: свежий `video-prompts.md` (`git pull`); живые `project-status.json`, `topview-status.json`, `instruction-sync-status.json`, `automation-monitor-status.json` (последний подтверждённый цикл писателя телеметрии), `deep-audit-status.json`, `monitor-role.json`; открытые задачи владельца в Supabase `owner_decisions` (`pending` / `in_progress` / `needs_owner`); для сюжета и монтажа — `film-analysis.md`, `film-backlog.md`, при необходимости `PROGRESS.md`, `Seregius_montazhny_razbor.html` и релевантные страницы Notion `Кино`; для промтов — `PROMPT-STYLE-GUIDE.md` + 1–2 близкие сцены master.

Перед **любой записью** в master — ещё один `git pull` и чтение свежего `video-prompts.md`; capability preflight — `SYNC-RUNBOOK.md` §1. Нельзя просить владельца повторять то, что однозначно записано в этих источниках: сначала искать ответ в каноне.

## 2. Источники истины и роли хранилищ

Порядок приоритета: **GitHub `main`** (master + 7 инструкций, статусы, сайт / Pages) → **Topview** (телеметрия генераций) → **Notion** (сюжет, идеи, история). Резервные копии — ниже по порядку и никогда не побеждают `main`. Роли хранилищ — `README-AI-SYNC.md` «Storage roles»; резервные копии — `BACKUP-AI-RUNBOOK.md`. **Проекты** (20.10.2026): кроме Серёгиуса (корень) в `projects/<id>/` живут Котмонавты, Кот детектив, Роскосмос (`roscosmos`) и Разное (`raznoe`) — свои мастер, сцены с 1, хендоф, инструкция, референсы, очередь и замок; эти 7 инструкций действуют для всех. Правила и распознавание проекта по сообщению владельца — `projects/README.md`; не назван — Серёгиус; в ответе всегда называть проект. Кнопки владельца (фаза 1 «Брак», фаза 2 «Принять» / «Переделать» / «В монтаж» и «🎞 В фильме» / «Не нужна» / «Не ждать») применяет робот `sync-from-drive.yml` — `SYNC-RUNBOOK.md` «Кнопки владельца и задачи текстом»; кнопки не запускают генераций.

## 3. Master: как вести `video-prompts.md`

- Единственный master — `video-prompts.md` в `main`. Не создавать `v2`, `final`, `copy`, `final-final`. `project-status.json` генерируется и вторым master не является.
- Перед каждой записью — `git pull` и чтение свежего master.
- Менять только нужную сцену и связанные оглавление / счётчики / статус / slow-метки. Минимальный diff. Процедура записи — `SYNC-RUNBOOK.md` §3–5.
- Scene ID стабильны и не перенумеровываются; закрытые ID не переиспользуются никогда. Актуальный список зарезервированных ID — `project-status.json.reserved_scene_ids` и строка «Сцены … удалены из active master» в свежем master; в инструкциях список не дублируется. Закрытые «🎞 В фильме» сцены в master не возвращать.
- Если следующий Scene ID однозначно следует из свежего master (`project-status.json.latest_scene` и зарезервированные ID), не спрашивать владельца — брать следующий новый стабильный ID. Новую сцену из Topview-задачи заводят только с согласия владельца.
- Готовая сцена убирается из активного master только по решению владельца, что результат принят и промт не нужен (кнопки «🎞 В фильме» / «Не нужна»); `Topview success` для этого недостаточно.
- `NEEDS_FIX` и `NEEDS_RERENDER` не разрешают автоматическую переписку или перезапуск; разбор — по одной сцене.
- Slow-сцены не перезапускать без решения владельца. Canonical slow снимает **только явная применённая кнопка владельца**; одна метка slow в карточке — `SYNC-RUNBOOK.md` (верхние блоки).
- Master — UTF-8 без BOM, только LF, не более одной пустой строки подряд (проверяет валидатор).

## 4. Как писать промты

Полный обязательный стандарт — `PROMPT-STYLE-GUIDE.md` (структура по задаче — §5А, самодостаточность и appearance lock — §16A, выбор движка — §7 и §7А, порядок подготовки — §2). Достаточность определяется смыслом и QA, а не длиной: свободное исполнение оставляют модели, критические гэги и стыки задают точно. Владельца о внешности известных персонажей не переспрашивают.

## 5. Routine master write

`git pull` → минимальная правка → `SYNC-TRIGGER.txt` → валидатор `health=ok` → Pages → проверка; подробно — `SYNC-RUNBOOK.md` §3 и §14. Отклонённый push = другой писатель: перечитать свежий `main` и сделать правку заново.

## 6. Instruction / handoff maintenance и Documentation Duty

Есть **семь** обязательных документов; их канон — `main`. Любое материальное нововведение документируется **в том же рабочем цикле** — определение и Definition of Done: `SYNC-RUNBOOK.md` §9; процедура правки инструкций — §7.

**Непрерывная передача знаний.** Любое подтверждённое знание, улучшение, ограничение модели, удачная практика, выбор engine, особенность prompt-writing, reference handling, continuity, генерации, монтажа, сайта, sync / восстановления или способ предотвратить найденную ошибку нельзя оставлять только в чате. Определить, к какой инструкции оно относится (таблица выше), и записать в том же цикле; если важно для продолжения — ещё и в handoff; если меняет стандарт промтов — в `PROMPT-STYLE-GUIDE.md`. Не размножать чисто эфемерные факты (очередь, ETA, текущий SHA). Принцип: если подтверждённая новая информация улучшает будущую работу, она должна пережить текущий чат через каноническую документацию — в одном месте, с короткой ссылкой из других.

## 7. Instruction sync

Сертификат `instruction-sync-status.json` — `SYNC-RUNBOOK.md` §8.

## 8. Control Center — текущий baseline

Сайт: `https://virudik.github.io/ai-film-prompts/` (GitHub Pages, только чтение). Базовый состав и site-only процедура — `SYNC-RUNBOOK.md` §6; контракты UI — «Валидатор, health и Control Center»; что видит владелец — `USER-GUIDE.md` §7. Постоянную функцию или архитектурное правило документировать по разделу 6.

## 9. Comments security

`SYNC-RUNBOOK.md` §11.

## 10. Slow / Topview

Canonical slow, слоты (ёмкость 6), телеметрия, publish gate и запреты писателя телеметрии — `SYNC-RUNBOOK.md` (верхние блоки, §10, «Canonical Topview state»). Коротко: технический `success` ≠ approval; slow снимает только кнопка владельца; ничего не одобрять, не удалять, не перезапускать и не создавать Scene ID без указания владельца.

## 11. Runtime state и исторические снимки

Текущие числа сцен, активные ID, slow ID, SHA — из свежего master и живого `project-status.json`. Текущие task / status / queue / ETA — из живого `topview-status.json` после проверки привязки. Исторические разделы, старые коммиты, письма GitHub Actions и старые страницы Notion — evidence, не текущий авторитет (`SYNC-RUNBOOK.md` §13).

## 12. Resilience / известные сбои

`SYNC-RUNBOOK.md` §13.

## 13. Notion и резервные копии

Notion — `SYNC-RUNBOOK.md` §12; резервные копии и recovery-пакет — `BACKUP-AI-RUNBOOK.md`; копия `video-prompts.md` в Library или на Drive никогда не используется как master.

## 14. Поведение нового сменщика

Новый чат должен:
- сначала пройти короткий приём D7 либо обязательное полное чтение семи документов по условиям раздела «Формат takeover и решение D7»;
- подтвердить доступ к чтению и записи репозитория и возможность проверок (валидатор, тесты, Pages) перед редактированием;
- проверить живые статусы и роль писателя (`monitor_role.py`, `monitor-role.json`);
- не переспрашивать известные IDs, роли хранилищ, Scene ID и правила стиля промтов; не импровизировать другую архитектуру; продолжать с текущего состояния;
- не предлагать владельцу «вставить самому», если инструменты позволяют выполнить каноническую запись;
- доводить изменения до конца: коммит → sync → валидатор → статус → Pages → документация и резервные копии, где применимо;
- чётко отделять факт, рекомендацию и то, что требует решения пользователя; не приписывать владельцу решений, которых он прямо не выражал;
- спрашивать владельца только о творческих и редакторских решениях, неоднозначной привязке «задача ↔ сцена», approval, rerender, удалении и закрытии сцен, небезопасных действиях, сбое, который не исправился после одной проверенной попытки, и о том, что канон не позволяет решить безопасно; детерминированное обслуживание (проверки, восстановление, формат, статусы) делается инструментами;
- при ограничении инструмента честно назвать конкретный недоступный шаг.

Если нет возможности записи в репозиторий, агент остаётся review-only и прямо сообщает ограничение, но не создаёт новый master. Цель takeover: владелец говорит только новую творческую или рабочую задачу, а сменщик уже знает инфраструктуру и процесс.

## 15. Персонажи / референсы — обязательный takeover слой

До «готов продолжать» новый чат открывает на Control Center вкладку «Персонажи / Референсы» (`references.html`) и читает `character-references.json` (без base64 в рабочий текст), строит рабочую карту **каноническое имя → алиасы → точный model sheet → текущее использование в сценах → отличительные признаки / костюм** и сверяет её со свежим master. Реестр содержит утверждённые model sheets: Серёга (Канцлер / The Chancellor), Юля, Паша (JEDI-A / Navy Jedi), Артём (Bearded Jedi), Илюша (Hooded Jedi), Саша (JEDI-B / Glasses Jedi), Лёша (PURPLE), Виталик (BLACK), а также Маша Лагуна, Лучик, Рыжик, Алеся — актуальный состав и сцены всегда в `character-references.json`. «Серёжа» трактуется как «Серёга», если контекст однозначен; алиасы автоматически на других людей не расширяются.

На запросы вида «Паша говорит Саше», «заходит Серёжа» редактор не просит описывать внешность заново, а разрешает имена через реестр и текущий master: сохраняет identity, использует утверждённый model sheet как PRIMARY identity reference (если доступен) и даёт достаточное текстовое описание внешности, одежды и роли. Персонаж не из реестра, но однозначно заданный референсами текущей сцены (например, Маша-Лагуна или конкретный офицер), берётся из маппинга сцены. Только при реальной неоднозначности, которую канон не снимает, задаётся уточняющий вопрос.

**Коты.** Лучик — бело-серый пушистый длинношёрстный кот, постоянный синий световой меч (в Scene 13 — тот же Лучик без меча, говорящий кот на коленях PURPLE; синий меч, вертикальная поза и храм из его model sheet в сцену Совета не попадают). Рыжик — рыжий пушистый длинношёрстный табби-кот, постоянный зелёный световой меч. Коты — обычного домашнего масштаба. Для котов всегда индивидуальный точный model sheet как identity authority плюс короткий текстовый lock; парный или композиционный референс не переопределяет морду, окрас, шерсть и пропорции.

`character-references.json` — реестр и публикационный слой, не второй master; поле `scenes` — текущее использование в активных сценах. При конфликте с устаревшим полем сначала сверять свежий master; точный утверждённый model sheet всегда сильнее случайного сходства группового кадра. Утверждённый model sheet — авторитет по внешности; текущий master — авторитет по использованию в сценах.

## 16. Монтажный разбор фильма — обязательный takeover слой

До доклада о готовности открыть «Монтажный разбор» на сайте (`Seregius_montazhny_razbor.html`, вторая версия — `Seregius_montazhny_razbor-2.html`) и ознакомиться как минимум со структурным анализом, сюжетными пробелами, рекомендациями по диалогам, финалу, переходам и персонажам; сверить выводы с `film-analysis.md`, `film-backlog.md`, при необходимости `PROGRESS.md` и релевантным Notion `Кино`. Цель — компактная рабочая карта: что в фильме уже есть → что подтверждено фактами → что рекомендация → какие пробелы остаются → какие идеи закрыты новыми сценами. Держать весь HTML дословно не нужно. Старую рекомендацию разбора не выдавать за текущую задачу, если master / backlog / новое решение владельца её заменили. Для глубокой монтажной работы читать нужный участок отчёта полностью. При разработке новой сцены учитывать её монтажную функцию (`PROMPT-STYLE-GUIDE.md` §17).

## 17. Readiness audit перед докладом «готов»

После чтения проверить актуальность самой системы, а не принять документы на веру:
- 7 инструкций читаются из `main` и внутренне согласованы; сертификат свежий, покрывает все 7 и `all_match=true`;
- master ↔ `project-status.json` согласованы (SHA, health); Topview-телеметрия не противоречит canonical slow; роль писателя и последний цикл робота;
- сайт и Pages отвечают; Control Center содержит заявленные постоянные функции;
- `references.html` / `character-references.json` доступны, привязка не явно устарела относительно master;
- `Seregius_montazhny_razbor.html`, `film-analysis.md`, `film-backlog.md` доступны;
- `deep-audit-status.json`: когда была последняя успешная глубокая проверка; старая / отсутствующая — выполнить её до уверенного отчёта о готовности;
- Notion-указатель достаточен для навигации; резервные копии (если доступны) помечены как резервные, не выглядят новее `main` и, если устарели, остаются recovery-only и не блокируют готовность (без запросов разрешений у владельца).

Безопасно исправимый дрейф документации чинить по правилам authority, и только затем докладывать. Если исправление может изменить творческий канон, master, сюжет или approval — не угадывать, сообщить конфликт владельцу. Доклад кратко перечисляет, что прочитано и проверено, какой приём использован, текущий checkpoint сцен / slow, что исправлено и реальные открытые вопросы.

## 18. Topview Scene Intake — привязка к существующей сцене и новая сцена

Классификация задач, привязка к существующей сцене и импорт новой сцены по согласию владельца — `SYNC-RUNBOOK.md` §18; дословность импортированного промта — `PROMPT-STYLE-GUIDE.md` §18.

## 19. Служебные файлы на Control Center

`SYNC-RUNBOOK.md` §19.

## 20. Мониторы и робот телеметрии

Писатель телеметрии всегда один (`monitor-role.json`, `scripts/monitor_role.py`): с 13.10.2026 `primary=robot` (GitHub-робот `topview-robot.yml`), `standby=chatgpt`, монитор Claude выключен. Роли, подхват, аварийная остановка и порядок цикла — `SYNC-RUNBOOK.md` («Робот GitHub», «Мониторы и расписание»); робот — `ops/ROBOT-TELEMETRY.md`.

### Самостоятельная работа между сменами

Разрешение владельца на конечную очередь сохраняется при смене чата. После приёма агент продолжает её без повторных вопросов и проверяет существующую задачу по расписанию; ожидание слотов не закрывает работу. Полная процедура — `ops/CONTINUE-PROTOCOL.md`, раздел «Самостоятельное продолжение разрешённой очереди», и `ops/TOPVIEW-FREE-LAUNCH.md`. Актуальное состояние — `reports/current-work-checkpoint.md`, `work-resume-register.json`, `ops/topview-launch-queue.json`. Для этой очереди используются существующее часовое задание `6acae6ab433481919e88665c520b8ef2` (HH:55 Europe/Moscow) и Relay-обработчик по `ops/TOPVIEW-EVENT-WAKE.md`, а робот телеметрии остаётся основным писателем своего домена. Не путать активную настройку с подтверждённым исполнением; вход и возможности нового/фонового чата проверять заново. Обычный чат не становится постоянно работающим процессом от записи в инструкции. О реальном блокере сообщать, не перекладывать штатное продолжение на владельца.

## 21. Внешний запуск робота и автоархив MP4

`SYNC-RUNBOOK.md` «Запуск автоматики снаружи» и «Автоархив готовых Topview MP4 в Drive».

## Scene Reference Pack automation и CLAUDE.md

Референсы (reference-first, QC по одному кадру, save-before-next, восстановление входов, команда «запускай сцену N» — **только по команде владельца, безлимитный режим через сайт Topview под входом владельца, кредиты не тратить**) — `SYNC-RUNBOOK.md` «Scene Reference Pack automation». Корневой `CLAUDE.md` — не-канонический bootstrap, не восьмая инструкция: `README-AI-SYNC.md` «Claude Code bootstrap adapter».

История решений — `NEW-CHAT-HANDOFF.md` (журнал) и `git log`.

## Состав команды · 01.11.2026

Доступ к Claude потерян по сообщению владельца; прежняя долгоживущая сессия не считается доступной автоматически. ChatGPT продолжает управление; Grok Bot добавлен помощником со своим браузером. Роли запусков и ограничения — `ops/LAUNCHER-COORDINATION.md`, назначения — `ops/OWNER-TASKS.md`. Параллельный анализ допустим, каноническая запись сериализована замком. Подключение launcher не является доказательством готовности Grok к любому творческому/коннекторному действию. Проект Grok — копия main, не ещё один мастер.

## Общая работа с Grok · 01.11.2026

Grok — дополнительный управляющий и помощник запуска в подтверждённых пределах. Адресат задач сайта `grok`; общий inbox без нового мастера. Защита повторов provider/message ID, разрешённое ночное окно с отдельной проверкой провайдера и общие Drive входы — `ops/LAUNCHER-COORDINATION.md`. Передача боту и чату: `reports/grok-shared-ops-handoff.md`; полученный файл не заменяет fresh main. Первый Create и фактический запуск рутины проверяются отдельно.