# PROMPT-STYLE-GUIDE — единый стандарт видео-промтов > **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`, без людей и мечей. > **Источник истины:** GitHub `main` (`video-prompts.md` + 7 инструкций); копии только для чтения; свежий `main` побеждает — `SYNC-RUNBOOK.md` (верх). ## Операционный указатель Этот файл — стандарт написания промтов и единственный дом правил о них: качество, структура, выбор движка и происхождение (provenance) промтов. Кто пишет канон, роли мониторов, расписание, Topview (runtime-модель, слоты, `active_tasks[]`, таблица slow, очередь / ETA), recovery и процедуры записи — в `SYNC-RUNBOOK.md` и свежем `monitor-role.json`; здесь они не дублируются. На сайте файл — №4 «Стандарт написания промтов» в списке 7 инструкций. **Версия:** 2.3 (25.10.2026: по команде владельца после аудита танцев — подробность по задаче, свобода исполнения и точность критических действий; §5А заменяет обязательный одинаковый каркас). §7А «Две версии промта» сохраняется. **Назначение:** обязательная специализированная инструкция для текущего редактора и любого следующего чата / сменщика AI Film Project. ## 1. Зачем существует этот файл Все новые видео-промты проекта должны сохранять качество лучших актуальных сцен `video-prompts.md`: ясный замысел, узнаваемых персонажей, исполнимое действие и нужную связность. Сложность, число секций и длина сами по себе не являются качеством. Это **не шаблон для буквального копирования** старых текстов. Короткий самодостаточный промт допустим, если вместе с назначенными референсами он передаёт нужное действие и защищает существенные ограничения. Общие эпитеты не заменяют замысел; дополнительные абзацы не заменяют ясность. Главная цель — заранее закрывать риски генерации: identity drift, смешивание референсов, нелогичную геометрию, случайную камеру, сломанный тайминг, неверный lip sync, мультяшность, лишние объекты, неправильное аудио и прочие типовые ошибки. ## 2. Когда читать Этот файл входит в набор 7 инструкций (порядок приёма смены — `AI-PROJECT-GUIDE.md` §1). Claude Code (`CLAUDE.md`) и любой другой агент читают его целиком перед prompt-работой. Перед написанием **любого нового prompt** или существенной переработкой существующего prompt текущий чат/сменщик обязан: 1. fresh-read этот `PROMPT-STYLE-GUIDE.md`; 2. `git pull` и чтение свежего `video-prompts.md` из `main`; 3. открыть минимум 1–2 актуальные сцены master, наиболее близкие к задаче; 4. проверить current Scene ID / engine / reference assignment; 5. только затем писать новый prompt. Нельзя заменять этот full guide кратким пересказом из переписки или памятью предыдущего чата. Номер новой сцены — §9. ## 3. Источник истины и приоритеты - Единственный prompt master: `video-prompts.md` в GitHub `main`; сначала `git pull` и чтение свежего master, затем правка; старые вложения и резервные копии master не являются. - Текущая явная команда пользователя сильнее старых заметок и исторических snapshot-ов. - Approved model sheet сильнее визуального сходства случайного frame reference. - Не придумывать отсутствующие референсы, костюмы, имена файлов или номера сцен. ## 4. Как должен выглядеть scene block в master Обычная новая сцена оформляется на двух уровнях. ### 4.1. Человеческая обвязка сцены ```md ## Сцена N — Короткое понятное название **Контекст использования:** зачем сцена нужна, её функция, важные решения пользователя, ограничения. **Референсы:** @Image1 = ... · @Image2 = ... **Что происходит:** короткий человеческий пересказ результата без технической перегрузки. ```text ...полный prompt... ``` ``` Если сцена slow, marker `**⏳ В МЕДЛЕННОЙ ГЕНЕРАЦИИ**` добавляется только когда генерация реально запущена / scene входит в canonical slow-list. Статус `READY` сам по себе не означает slow. Метка одна на сцену и без технического хвоста (`SYNC-RUNBOOK.md`, «Одна метка slow»). ### 4.2. Полный prompt Сам prompt содержит только нужные этой генерации указания: **что неизменно, главное действие и тон исполнения, камера, звук и реальные риски**. Для непрерывного танца достаточно ясного действия со свободой естественной пластики; для гега, физического контакта и продолжения нужен точный порядок и состояние на стыке. Подробная человеческая карточка сцены не обязана целиком попадать в копируемый блок. ## 5. Базовая структура полного prompt Ниже — перечень смысловых компонентов для проверки, а не требование заполнить все разделы. Выбирать и объединять их по §5А; не дописывать пустую техническую обвязку ради шаблона. ### A. Техническая строка В начале явно задавать режим и технические параметры, например: ```text Mode: reference-to-video | Duration: 30s | Resolution: 1080p | Aspect ratio: 16:9 | FPS: 24 | Native audio: on ``` Не копировать 1080p/16:9 механически, если пользователь или движок требуют другое. ### B. REFERENCES Каждому референсу назначить **одну ясную роль**: - PRIMARY exact identity reference; - location / environment only; - starting composition only; - ending composition only; - costume / transformed form only; - prop / vehicle design only. Плохой вариант: `@Image1 — reference`. Хороший вариант: объяснить, **что брать и что не брать** из изображения. ### C. IMPORTANT REFERENCE RULE / REFERENCE PRIORITY При двух и более референсах почти всегда нужен явный приоритет. Нужно писать, например: - лицо/возраст/пропорции берутся только из model sheet; - локационный кадр не имеет права переопределять персонажа; - стартовый/финальный кадр отвечает за композицию, а не identity; - запрещено усреднять лица между изображениями; - approved character sheet является identity lock. ### D. STYLE GOAL / SCENE / ENVIRONMENT Нужно описывать не набор эпитетов, а конкретную постановочную цель: - live-action или стилизация; - жанр; - настроение; - физический характер мира; - уровень серьёзности/комедии; - production design; - что должно ощущаться как реальная съёмка. Формулировки «cinematic, beautiful, epic» сами по себе недостаточны. ### E. TIMELINE / STORY FLOW / SCENE STRUCTURE Временная разметка нужна, когда от времени или порядка зависит смысл: реплика, причинное действие, гег, монтажный стык. Само наличие 20–30 секунд её не требует. Для одного непрерывного танца или музыкального исполнения предпочтительно `ACTION` / `STORY FLOW`, без перечня движений на каждые 2–4 секунды. Пример логики: ```text [0:00–0:05] setup [0:05–0:11] first action / first line [0:11–0:18] escalation [0:18–0:25] consequence [0:25–0:30] final composition ``` Тайминг должен быть **реалистичным**: длинную реплику нельзя запихивать в 2 секунды, а сложное физическое действие не должно происходить одновременно с пятью другими ключевыми событиями. Если точные секунды мешают модели, использовать `Story flow:` и последовательные beats, но порядок всё равно должен быть однозначным. ### F. CAMERA / LENS / CONTINUITY Нужен понятный план камеры; он может быть одной строкой. Отдельный блок оправдан сложной траекторией или стыком. Глобальные правила проекта: - physically stable cinematic motion; - controlled inertia; - no random jitter / micro-shake; - coherent 3D space; - камера не телепортируется; - новые объекты не возникают из ничего, а раскрываются движением камеры; - направление движения и пространственная логика не ломаются между beats. **Музыкальный номер и подвижная камера (30.10.2026):** задавать одну осмысленную дугу/наезд/отъезд под действие, а не одинаковый360° облёт всем. В свободном исполнении движение камеры усиливает уже живую пластику; у касаний лица, опор, игровых рук и удара сохранять видимый контакт и ось. Неподвижна геометрия в пространстве, а не положение ориентиров на экране: разрешать естественный параллакс. Неизвестную обратную сторону локации сначала закрепить отдельным постановочным видом; варианты расстановки до выбора владельца остаются в галерее, не становятся обязательными входами. Нельзя скрывать камерой, склейкой или вспышкой физический контакт. Если нужен continuous take — написать это явно. Если допустима shot progression — описать её как мотивированную последовательность, а не случайный монтаж. ### G. PERFORMANCE / ACTING Для людей и антропоморфных персонажей описывать: - исходное эмоциональное состояние; - изменение состояния; - уровень мимики и жестов; - natural blinking / breathing / weight transfer; - что нельзя переигрывать; - как сохраняется identity и costume. Комедия проекта часто лучше работает, когда персонажи играют происходящее **серьёзно**, а юмор возникает из ситуации, а не из гротескной актёрской игры. ### H. DIALOGUE / VOCALS / LIP SYNC Если есть речь или пение: - язык указывать явно; - точный текст помещать отдельно; - назначать конкретного говорящего; - требовать natural pronunciation и accurate lip sync; - описывать интонацию; - запрещать subtitles/captions, если они не нужны. Для русского диалога по умолчанию — естественная русская речь без акцента, если пользователь не задал другое. Для пения явно писать `sung, not spoken`, breathing, phrasing, mouth shapes и роль музыкального сопровождения. Если пользователь хочет существующую песню, но точные защищённые lyrics не были предоставлены пользователем, не вставлять их самостоятельно: использовать оригинальный текст, предоставленный пользователем текст или нейтральный placeholder/описание вокала в зависимости от задачи. ### I. LIGHTING / MATERIAL REALISM / PRODUCTION DESIGN Нужно конкретизировать: - источник и направление света; - характер теней; - material response кожи, ткани, металла, воды и т. п.; - глубину/дымку/рефлексы; - что должно оставаться физически правдоподобным. Для live-action полезны отдельные realism locks: pores, fabric weave, practical-light falloff, natural motion blur, believable reflections. **Динамический свет (30.10.2026, после проверки танцев):** если нужны светомузыка или смена цвета, раздельно описывать постоянные геометрию/нейтральный свет на лицах и меняющиеся излучение приборов/световые линии пола/отражения. Указать наблюдаемую смену и её примерный ритм. Не запрещать её общим `lighting unchanged` / `remain steady`; запрет мерцания ограничивать лицами, экспозицией и общими вспышками. Референс задаёт устройство локации и начальную фазу, а не замораживает свет на весь ролик. Успех новой формулировки проверяется по будущему результату; текст не гарантирует синхрон с музыкой. ### J. AUDIO (native) Если `Native audio: on`, описывать звук так же конкретно, как изображение: - dialogue/vocal priority; - шаги; - ветер; - вода; - одежда; - engine hum / room tone; - музыка и её громкость; - что не должно заглушать речь. ### K. NEGATIVE PROMPT Negative prompt должен быть **коротким и сценоспецифичным**: только вероятные ошибки этой сцены. Число слов не является критерием; не копировать весь список ниже и не повторять уже однозначные позитивные указания. Обычно проверять риски: - identity drift / face morphing; - costume drift; - duplicated / missing people; - distorted hands / fingers; - broken physical interaction; - lip desync; - wrong speaker; - cartoon / anime / game-render look, если нужен live-action; - plastic/wax skin; - warped environment; - changing geometry; - camera jitter; - hard cuts / random montage; - accidental subtitles/text/logo/watermark; - типичные ошибки конкретной сцены: неправильный slap, неверное оружие, лишний микрофон, магические грибы и т. д. ### L. FRAME FILL / NO BARS Для всех текущих и будущих prompts действует глобальное правило, если пользователь явно не отменил его: ```text FRAME FILL / NO BARS: Fill the entire generated frame edge-to-edge. No letterboxing, no pillarboxing, no black bars, no side bars, no decorative borders, no empty margins. ``` ## 5А. Структура по задаче (обязательный принцип для новых и переработанных prompts — с 25.10.2026) **Выбирать подробность по риску и замыслу, не по длине соседнего текста.** Формат 13.10 с обязательным одинаковым порядком всех секций заменён этим правилом. Копируемый блок всегда автономен; это не означает большой объём. - **Свободное исполнение:** техническая строка → роли референсов и короткий `CHARACTER APPEARANCE / IDENTITY LOCK` → одно главное действие с настроением → камера / свет / звук → нужные ограничения и заполнение кадра. Можно объединять близкие секции и писать их в одну строку. Оставлять модели выбор шагов, связок, небольших поворотов, реакций и музыкальной пластики в пределах заданного номера. - **Точный гег / физическое взаимодействие / продолжение:** тот же минимум плюс конкретные опоры, хват, пространственная причинность, `START STATE` / `END STATE` и `STORY FLOW` или выполнимая `TIMELINE`. Размечать ключевые события, а не каждый микрожест. Уточнять, чем управляет настоящий кадр или видео предыдущей части. - **Смешанная сцена:** свободное исполнение между точными ключевыми событиями. Не превращать весь номер в пошаговую инструкцию из-за одного сложного контакта. `CHARACTER APPEARANCE / IDENTITY LOCK` (§16A) и смысл `FRAME FILL / NO BARS` (§5.L) сохраняются в каждом автономном блоке. Имена остальных секций и их порядок не являются критерием готовности. Краткий lock содержит реальные признаки персонажей, а не только `same as reference`. В копируемый блок не пишутся операторские фразы («если кадра нет — сцена не готова», «генерация не разрешена», «подобрать до запуска»). Они живут в человеческой обвязке. Названия движков: `Wan 3.0`, `Seedance 2.5`, `Seedance 2.0`; параметры сверять с реальными настройками, запись 1080p/4K в тексте не повышает разрешение рендера. Если сцена уже запущена, новая редакция master предназначена для будущих разрешённых запусков. Сохранить фактически отправленный текст, SHA и receipt в истории; в обвязке указать прежнюю редакцию. Оценивать результат по отправленному тексту. У ожидающих items обновить метку/SHA, не менять историю активных задач и не создавать новые повторы одним редактированием. `DRAFT` → `READY` только когда все входы существуют, пройден QA §11 и нет «подобрать до запуска». Написанный промт не доказывает готовность видеостыка или качество будущего ролика. Разрешение запуска — отдельно по канону очереди. **Wan 3.0:** те же смысловые требования; минимальной длины и требования «без сжатия секций» нет. Для непрерывного 30-секундного действия сохранять живой темп и естественное развитие, а не растягивать несколько жестов длинными удержаниями. Для продолжения настоящий конец предыдущей части определяет старт. Правила движков и запуска — §7 / §7А и `SYNC-RUNBOOK.md`. ## 6. Уровень подробности и принцип качества Главный принцип: **maximum useful specificity, minimum redundant wording**. Хороший master-level prompt — не самый длинный. Он достаточно конкретен, чтобы модель однозначно поняла персонажей, действие, пространство, камеру, звук и ограничения, но не повторяет один и тот же смысл в нескольких длинных блоках. ### 6.1. Самодостаточность без раздувания Каждый production prompt, который пользователь копирует отдельно, должен быть самодостаточным. При этом автономность **не означает** механически копировать внутрь каждого блока весь scene-level bible. В автономный prompt переносить: - exact reference roles и priority; - short appearance/identity lock каждого важного персонажа; - обязательные continuity facts для этой части; - конкретное действие / dialogue / vocals; - camera plan; - нужные lighting/audio/negative constraints; - START STATE / END STATE, если prompt является частью последовательности. Scene-level bible может хранить более подробную драматургию и общую режиссуру серии, но отдельный prompt должен содержать только ту её часть, которая реально нужна этой генерации. ### 6.2. Приоритеты MUST / SHOULD / MAY При сложном prompt редактор обязан мысленно, а при необходимости явно, разделять требования по важности. **MUST — нельзя потерять:** exact identity / approved costume or form; reference ownership and priority; обязательные персонажи и реквизит; заданные владельцем ключевые действия, реплики и причинный порядок; ключевой старт/финал; критический continuity. **SHOULD — желательно сохранить:** конкретная траектория камеры; эмоциональная динамика; lighting / production-design нюансы; второстепенные физические реакции. **MAY — оставить модели свободу:** шаги, связки, пластику и реакции внутри свободного номера, если они не закреплены решением владельца или физикой гега; микрожесты и фоновую жизнь. Точная опора при переноске и хват инструмента — MUST; произвольное число сгибаний коленей между ними — не MUST. Если требований слишком много, сокращать MAY и часть SHOULD, а не MUST. ### 6.3. Complexity budget Не перегружать 20–30 секунд количеством независимых событий. Перед сохранением prompt проверить: - сколько ключевых действий должно произойти; - сколько персонажей одновременно говорят/двигаются; - сколько смен композиции/камеры запрошено; - хватает ли времени на реплику + паузу + реакцию + переход; - не требуют ли два события несовместимых позиций персонажа или камеры одновременно. Если prompt перегружен, лучше сократить beats или разделить генерацию, чем компенсировать перегрузку ещё большим количеством текста. ### 6.4. Запрет семантических дублей Критическое правило можно повторить максимум там, где повторение действительно усиливает управление моделью, например один раз в `REFERENCE PRIORITY` и один раз в коротком `IDENTITY LOCK`. Не нужно три-четыре раза разными словами повторять `same face`, `same costume`, `same location`, если смысл уже однозначно закреплён. Повторение не заменяет точность и может размывать относительный приоритет остальных требований. ### 6.5. Короткая формула «делать / не делать» **Делать:** конкретно назначать роли референсов; защищать identity; писать только выполнимые beats; давать камере физически понятную траекторию; сохранять пространство и continuity; рассчитывать речь/пение по времени; описывать звук, если он нужен; оставлять модели свободу исполнения везде, где точная хореография не является целью сцены или условием непрерывности. **Не делать:** превращать prompt в набор эпитетов; смешивать роли нескольких reference images; заставлять пользователя вручную доклеивать общий identity-блок; повторять одну мысль 3–4 раза; перегружать 30 секунд независимыми событиями; использовать огромный универсальный negative prompt вместо рисков конкретной сцены; копировать устаревший live-example как источник истины; спрашивать заново уже известную внешность персонажа. ## 7. Адаптация под движок ### Русский диалог → Wan 3 (постоянное engine-routing правило) Любая сцена со слышимой разговорной репликой на русском направляется в **Wan 3**: Seedance 2.5 в текущем workflow ненадёжен для естественной русской речи / произношения и lip sync и автоматически такой сцене не назначается. Исключение — только новая прямая команда пользователя для конкретной сцены. Правило относится и к новым сценам, и к существенной переработке существующих русскоязычных dialogue scenes: при чтении сцены с `dialogue.language = ru` проверять `target_engine = Wan 3`, при существенной переработке исправлять старое назначение в рамках того же Scene ID. Правило не требует перезапускать активную slow-задачу или менять утверждённый результат без решения владельца. ### Seedance 2.5 Обычно хорошо работает для сцен без русского разговорного диалога: подробная режиссёрская структура, точное распределение референсов, ясная временная последовательность, controlled camera motion и native audio instructions. Не перегружать одновременными независимыми действиями. Если несколько обязательных событий — распределять их по времени; один непрерывный номер не дробить без причины. ### Wan 3.0 Особенно внимательно контролировать live-action realism, identity stability, естественное русское произношение, mouth/lip sync, материальность и отсутствие мультяшного/глянцевого CG look, если предыдущий результат имел такой дефект. ### Veo / другие движки Сохранять необходимые смысловые требования, но учитывать ограничения конкретной модели по длительности, native audio, reference count и moderation. Не тащить технические параметры Seedance в другой движок механически. ## 7А. Две версии промта для каждой сцены (решение владельца 18.10.2026, с 19.10.2026 — две вместо трёх) - **Каждая активная сцена имеет две версии промта:** **30 с · Wan 3.0 / Seedance 2.5** (один текст на оба движка) и **Seedance 2.0 · 2 × 15 с**. 19.10.2026 владелец слил прежние отдельные версии Wan 3.0 и Seedance 2.5: их тексты совпадали на 85–98%. Новую сцену сразу пишут в обеих версиях; существенная переработка сцены обновляет обе. Обе версии рассказывают одну историю: те же START / END STATE, роли референсов, замки, реплики и решения владельца; различаются темп и техника движка. - **30 с · Wan 3.0 / Seedance 2.5:** один самодостаточный текст на 30 с. На Seedance 2.5 запускается тот же текст без правок (строка `Optimized for` остаётся как есть), иначе не совпадёт SHA в очереди. Отдельный текст под Seedance 2.5 не пишут. - **Seedance 2.0 · 2 × 15 с:** часть 1 и часть 2 самодостаточны; часть 2 стартует с `@Video1` = последние секунды результата части 1; реплика целиком в одной части. Для музыкальных и танцевальных серий (28, 49) версия может состоять из нескольких роликов — так и подписано на вкладке. - **Разметка в master:** после «Что происходит» — `
`, внутри панели `
` (`wan30` = вкладка «30 с · Wan 3.0 / Seedance 2.5»), вокруг тегов пустые строки. Первая панель с `data-main="1"` — блок с меткой `N`; заголовки остальных: `#### N · Wan 3.0 · 30 с`, `#### N · Seedance 2.0 часть 1/2` (метки — `scripts/topview_prompt_match.py`). У каждой панели строка «Входы» со своей нумерацией. На сайте это вкладки над промтом. Новых панелей `sd25` не заводить. - **Какую версию запускать:** только блок, чей `canonical_block_label` (и SHA) стоит в `ops/topview-launch-queue.json`. Вкладки — выбор для владельца, не разрешение на запуск; автоматика сама другие версии не запускает и не подставляет. На сайте такая вкладка помечена «★ в очереди». `scene-meta.target_engine` = движок пункта очереди; для 30-секундного текста пункт очереди сам называет движок (`model`: Wan 3.0 или Seedance 2.5). - **Движок по умолчанию:** русская речь в кадре, тихие и разговорные сцены → **30 с на Wan 3.0** (Seedance плохо говорит по-русски, §7); экшен, перелёты, танцы, музыка, быстрое движение → **Seedance 2.0 · 2 × 15 с** (решение владельца 18.10, 03:09); тот же 30-секундный текст на **Seedance 2.5** — запас, только по прямой команде владельца. - **Когда переключаться** (всегда решением владельца): Wan замедлил сцену или «поплыли» лица → Seedance 2.0; заметен шов между частями Seedance 2.0 или сцене нужен один непрерывный дубль → 30-секундный текст на Seedance 2.5; Seedance исказил русскую речь или липсинк → 30-секундный текст на Wan 3.0. После решения: новый элемент очереди с меткой выбранной версии и нужным `model`, прежний → `superseded_owner_model_selection`, обновить `target_engine`. ## 8. Continuity между сценами **Корабль Серёги — правило владельца 23.10.2026:** в каждом самостоятельном prompt крыша, фонарь кабины, крылья и наружный корпус пусты. В движении Серёга целиком внутри закрытой кабины, за управлением; снаружи его можно видеть только через остекление. На стоянке вход/выход через боковой люк и рампу с земли. Не переносить человека с крыши исходного кадра: база формы `references/scenes/scene-37/S37-ship-clean-roof.png`, оригинал — только provenance. Для каждой локации брать соответствующий AI-референс из `references/scenes/ship-locations/` по слотам конкретного блока; карта и provenance — `reports/serega-ship-locations-2026-10-23.json`. Это не видеокадры: реальный @Video1 определяет старт и направление, картинка — форму/окружение только нужного этапа; открытый люк и шасси не переносить в полёт. Несколько видов означают один корабль. Финал предыдущей части с человеком на крыше не использовать для продолжения; записать дефект и ждать решения, без автоповтора. Если сцена является продолжением: - явно назвать связь с предыдущей; - сохранить одежду, свет, погоду, повреждения, реквизит; - сохранить направление движения; - определить стартовую и конечную композицию; - не менять геометрию пространства без мотивированного перехода. Если есть starting/ending frame references, указать, что именно они фиксируют и что они **не имеют права переопределять**. Для последовательных генераций предпочтительно явно фиксировать handoff: ```text START STATE: [позиция персонажей, поза/направление, состояние реквизита, камера/крупность, свет] END STATE: [позиция персонажей, поза/направление, состояние реквизита, камера/крупность, свет] ``` `END STATE` текущего блока должен быть совместим с `START STATE` следующего. Это полезнее абстрактной фразы `preserve continuity`, особенно для 8–30-секундных последовательностей. ## 9. Правила для нового Scene ID Номер не спрашивать, если его можно определить из свежего master и `project-status.json` (`latest_scene`, зарезервированные ID); Scene ID стабильны, не перенумеровываются ради «красивой» последовательности, удалённые не переиспользуются; новую сцену из Topview-задачи — только с согласия владельца. Полные правила — `AI-PROJECT-GUIDE.md` §3; шаги добавления (карта, счётчики, meta, а не только prompt в конец файла) — `SYNC-RUNBOOK.md` §4. ## 10. Что запрещено считать готовым prompt Не оставлять как финальный master prompt текст уровня: > A woman stands by a lake and sings emotionally. Cinematic camera slowly moves closer. Beautiful lighting, realistic style. Проблема примера — не краткость, а отсутствие узнаваемого персонажа, назначенных референсов, содержания вокала и ясного результата. Добавлять недостающие существенные сведения, а не все возможные заголовки. Точный тайминг и отдельный negative не нужны только ради формальности. Также нельзя: - автоматически переписывать все NEEDS_FIX разом; - подменять точный model sheet «похожим» лицом; - добавлять в prompt выдуманный reference; - превращать continuous scene в хаотичный montage без причины; - снимать slow самому (slow снимает только кнопка владельца, `SYNC-RUNBOOK.md`); - создавать `video-prompts-v2/final/copy` вместо правки единственного master в `main`. Плохие практики (`same character as reference` без реальных признаков, `see shared block above`, референсы без ясного ownership, огромный универсальный negative, повторы одного lock в 3–5 местах, слишком много beats, невозможная камера, полные копии live-prompts в инструкции) разобраны в §6.3–6.5, §5.F, §5.K, §12 и §16A. ## 11. Финальный prompt-QA перед сохранением Перед записью в master редактор обязан проверить не только наличие блоков, но и их **согласованность и полезность**. ### A. Структура и references - [ ] Scene ID определён по стабильным правилам и не переиспользован. - [ ] `scene-meta` соответствует движку, длительности, языку и production state. - [ ] Есть `Контекст использования`, `Референсы`, `Что происходит`. - [ ] Техническая строка соответствует реальному движку/режиму. - [ ] Каждому reference назначена конкретная роль. - [ ] При 2+ references явно разрешён ownership/priority там, где возможен конфликт. - [ ] Environment/group/start/end reference не может случайно переопределить identity отдельного персонажа. ### B. Персонажи - [ ] Каждый важный известный персонаж resolve через `character-references.json` + fresh master/current variant. - [ ] В автономном production prompt есть short appearance/identity lock с реальными distinguishing traits. - [ ] Costume/form соответствует именно этой сцене, а не случайному варианту из другой сцены. - [ ] При нескольких персонажах ясно, какой reference принадлежит кому; запрещено face blending / swapping. ### C. Исполнимость и режиссура - [ ] Timeline/story flow физически реалистичен для длительности. - [ ] Dialogue/vocals реально помещаются в выделенное время с дыханием/паузами/реакциями. - [ ] Complexity budget не перегружен лишними независимыми beats. - [ ] Камера физически понятна, стабильна и совместима с заявленным continuous/shot-based режимом. - [ ] Для цепочки сцен определены совместимые START STATE / END STATE, если это полезно. - [ ] Performance задаёт живое исполнение; серьёзное лицо не превращено в неподвижное тело. - [ ] Для свободного номера нет лишнего счёта шагов, микротайминга и пауз между командами; для гега сохранены опоры, хват и причинный порядок. ### D. Реализм, звук и негативы - [ ] Environment / lighting / material realism описаны ровно настолько, насколько нужны сцене. - [ ] Audio конкретен при `Native audio: on`. - [ ] Negative prompt ориентирован на реальные риски именно этой сцены, а не является бесконечным универсальным хвостом. - [ ] `FRAME FILL / NO BARS` присутствует, если пользователь явно не отменил правило. ### E. Редактура prompt - [ ] Нет внутренних противоречий. - [ ] Нет семантических дублей и ненужного повторения больших блоков. - [ ] MUST-требования заметно важнее SHOULD/MAY деталей. - [ ] Prompt полностью самодостаточен: один блок можно скопировать и запустить без текста выше/ниже. - [ ] Нет зависимостей вида `see shared block above`. - [ ] Все references, названные в prompt, реально существуют и используются. ### F. После записи - [ ] Обновлены map/counts/meta, если это требуется архитектурой. - [ ] Пройдены запись и проверка по `SYNC-RUNBOOK.md` §3 и §14. Если любой пункт A–E нарушен, prompt ещё не готов, даже если он выглядит длинным и «кинематографичным». ## 12. Эталон качества: только fresh master, без полнотекстовых копий Эта инструкция **не хранит полные копии текущих live-prompts** как вечные примеры. Причина: master меняется, сцены могут быть удалены, переработаны или получить новые reference roles; встроенная копия неизбежно становится stale и начинает учить сменщика устаревшему состоянию. Как работать правильно: перед созданием / переработкой prompt пройти шаги §2 и выбрать одну-две **текущие активные** сцены, близкие по типу задачи (dialogue / action / music / continuous take / multiple references), только как живые structural examples; брать из них удачные паттерны структуры, но не копировать факты, одежду, references или scene-specific negative prompt; если пример в handoff / старом обсуждении расходится с fresh master, fresh master имеет приоритет. Хороший эталон определяется не номером сцены, а качествами: - ясные reference roles и priority; - точный short identity lock; - реалистичная timeline/beat structure; - физически понятная камера; - coherent 3D space; - acting/dialogue/audio specificity; - risk-oriented negative prompt; - автономность copy-paste блока; - отсутствие лишнего повторения. Никогда не считать удалённую/неактивную сцену автоматически действующим эталоном только потому, что она когда-то была вставлена в документацию. ## 13. Правило для следующего чата / сменщика Готовность нового prompt определяется QA §11, а не количеством секций или сравнением длины с соседними сценами. Не раздувать удачный компактный текст и не сокращать необходимую физику/непрерывность ради краткости. Сменщик не должен просить пользователя заново объяснять уже известные project rules. Если задача однозначно выводится из fresh master + handoff + этого guide, нужно продолжать работу по установленному workflow. ## 14. Documentation / handoff maintenance for prompt changes Prompt-writing standard — не отдельная статичная памятка. Если появляется новое повторяемое правило для будущих сцен (новый обязательный block, новый reference-priority rule, новое continuity / audio / camera правило, новая engine-specific практика) или подтверждённая информация, которая улучшает будущие prompts или выбор движка (модель лучше / хуже справляется с языком, lip sync, reference handling, identity, camera motion, длительностью или типом сцены), это нельзя оставлять только в текущем чате: в том же рабочем цикле обновить **этот** `PROMPT-STYLE-GUIDE.md` и, если важно следующему сменщику, `NEW-CHAT-HANDOFF.md`. Это материальное изменение — дальше по `SYNC-RUNBOOK.md` §9 (`cert_github.py`, тесты, push, Notion-указатель; резервные копии — best-effort). Не создавать `PROMPT-STYLE-GUIDE-v2/final/copy`: правится тот же файл в `main`. Принцип: **подтверждённое улучшение prompt workflow должно стать частью канонического стандарта, а не памятью одного чата.** Примеры в этом файле иллюстрируют смысловые требования, а не обязательную сложность или длину. Перед копированием решения всегда смотреть свежий master. ## 15. Definition of Done для prompt-work и передачи следующему чату Новая или изменённая сцена записана только после: свежего `git pull`, свежего guide и master; промта master-level (QA §11); записи и проверки по `SYNC-RUNBOOK.md` §3 и §14 (минимальный коммит, согласованные оглавление / счётчики / meta, `SYNC-TRIGGER.txt`, `health=ok`, Pages, если сцена на сайте, read-back). Следующий чат обязан знать: prompt style не хранится «в памяти прошлого чата». Он хранится здесь и в живом master. Если владелец формулирует новую сцену кратко, задача редактора — самостоятельно подготовить достаточный автономный промт по §5А, не заставляя повторно диктовать техническую структуру. ## 16. Имена персонажей → exact identity в prompt Перед написанием новой сцены редактор обязан разрешить имена через `character-references.json` + current `video-prompts.md`. Пользователь может задавать сцену человеческим языком — например, «Паша говорит Саше, затем заходит Серёжа» — и не обязан каждый раз повторять внешность. Для каждого известного персонажа в prompt: - использовать canonical name; - назначить exact attached model sheet как PRIMARY identity reference, если он доступен в этой generation task; - кратко зафиксировать отличительные черты лица/телосложения/прически/костюма из approved model sheet/current scene variant; - не переносить одежду из другой сцены, если current scene требует иной approved variant; - не позволять environment/group reference переопределять индивидуальную identity. Не хранить здесь фиксированный список персонажей как canonical truth: он быстро устаревает. Актуальный roster и aliases всегда брать из fresh `character-references.json` + current master. Персонажи, существующие только в конкретных current prompts (например Маша-Лагуна или Imperial Officer), разрешаются через fresh scene references/master. Не выдумывать global model sheet для персонажа, которого там нет. Если user name/alias реально может относиться к двум разным людям и current sources не снимают неоднозначность, задать один точный вопрос. В остальных случаях resolve самостоятельно. ## 16A. Автономность каждого prompt-блока и обязательное описание внешности Любой prompt, который пользователь может копировать в генератор как отдельный блок, обязан быть **полностью автономным**. Пользователь не должен собирать prompt из нескольких мест, отдельно копировать общий identity-блок или помнить правила, находящиеся выше по странице. Обязательный стандарт для всех новых prompt-блоков и серийных частей одной сцены (`Часть 1`, `Песня 1`, `Shot 3` и т.п.): - внутри **каждого** копируемого prompt-блока должен быть собственный краткий `CHARACTER APPEARANCE / IDENTITY LOCK`; - в нём кратко фиксируются ключевые признаки внешности каждого важного персонажа: лицо, возрастной образ, телосложение/пропорции, кожа/цвет, волосы или эквивалентные head elements, одежда/костюм, силуэт и критические дизайн-элементы; - attached model sheet / face reference остаётся абсолютным визуальным источником identity; если текстовое описание случайно конфликтует с approved reference, следует reference; - для известного персонажа редактор обязан сам получить описание из `character-references.json` + fresh master/current scene variant. **Не спрашивать пользователя заново**, если identity уже однозначно известна; - если у сцены есть длинный общий identity bible, он может оставаться в master как документация/continuity layer, но отдельный production prompt **не должен зависеть** от ссылки вида `see shared block above`, `follow the shared identity block above` и т.п.; - каждый prompt должен работать по принципу: **открыл один блок → скопировал целиком → приложил указанные references → запустил генерацию**; - short appearance lock должен быть достаточно конкретным, чтобы удерживать identity на wide / profile / orbit / close-up ракурсах, но не раздувать prompt повторением полного паспорта персонажа; - если в prompt несколько персонажей, краткий appearance/identity lock обязателен для каждого важного персонажа либо в общем компактном block с явным разделением по именам; - запрещено подменять точное описание общими словами вроде `same character as reference`, если в registry/master уже есть однозначные отличительные признаки, полезные для консистентности. Рекомендуемый формат: ```text CHARACTER APPEARANCE / IDENTITY LOCK: @ImageX is the absolute visual authority for [Character Name]. Preserve the exact face, body proportions, approved skin/hair/color identity, costume or silhouette, and the key design elements from the attached reference. Do not redesign, beautify, age-shift, replace hairstyle/head structure, change costume logic, or alter the approved character design. ``` Это шаблон структуры, а не повод писать одинаковый абстрактный текст для всех. Для конкретного персонажа редактор должен подставлять **реальные отличительные признаки из approved model sheet/current variant**. Definition of Done для любого автономного prompt: - prompt полностью самодостаточен; - внутри есть short appearance/identity lock с реальными отличительными признаками; - нет зависимости от prose выше/ниже копируемого блока; - reference roles ясны; - written appearance не конфликтует с attached reference; - пользователь не должен дополнительно уточнять, что именно ещё вставить в генератор. ### Совместимость со старыми prompts Для **новых и существенно перерабатываемых** production prompts использовать стандартный заголовок `CHARACTER APPEARANCE / IDENTITY LOCK`. Для старых prompts audit должен проверять **семантическое наличие** identity protection, а не только буквальное совпадение заголовка. Если equivalent lock уже корректно реализован внутри `ENVIRONMENT & ASSET LOCK`, `IMPORTANT REFERENCE RULE` или другого ясного блока, это не automatic failure. При следующей содержательной переработке сцену привести к текущему стандартному заголовку. ## 17. Связь prompt с монтажным контекстом Перед созданием сцены следующий чат уже знаком с монтажным слоем (`AI-PROJECT-GUIDE.md` §16: `Seregius_montazhny_razbor.html`, `film-analysis.md`, `film-backlog.md`). При разработке новой сцены учитывать её монтажную функцию: что было до неё, что должно стать понятнее после неё, какие сюжетные/диалоговые проблемы она закрывает и не дублирует ли уже существующий beat. Монтажный анализ — context/recommendation layer, не второй prompt master. Новый explicit user decision и current master имеют приоритет над старой рекомендацией. ## 18. Imported Topview prompt: fidelity rule Когда новая сцена создана (только с согласия владельца) из уже запущенной/готовой Topview video task, есть особое правило происхождения prompt: - **actual prompt, реально отправленный в Topview, сохраняется verbatim** как source prompt этой imported scene; - нельзя автоматически переписать его в более красивый master-style и затем утверждать, что именно эта новая версия использовалась при генерации; - master-style wrapper (`Контекст использования`, `Референсы`, `Что происходит`, корректный `scene-meta`) может быть добавлен вокруг source prompt; - если позже пользователь просит улучшенный rerender prompt, это уже отдельная новая редакционная версия внутри той же scene по обычным правилам, при этом происхождение исходного Topview prompt не теряется; - known characters при import resolve через global registry/current master, но неизвестные детали не выдумываются. Это исключение существует ради provenance: guide определяет качество новых prompts, но не должен переписывать историю уже совершённой генерации. ## 19. Prompt-quality проверки в daily deep audit Раз в 24 часа суточная глубокая проверка монитора (`SYNC-RUNBOOK.md`) может **проверять** активные / новые промты на регрессию относительно этого guide. Проверять прежде всего: - reference ownership/priority при нескольких изображениях; - identity/appearance protection каждого важного персонажа; - автономность copy-paste блока; - timeline/dialogue timing feasibility; - camera/continuity и START/END handoff для последовательностей; - semantic duplication / prompt bloat; - risk-oriented negative prompt; - audio и `FRAME FILL / NO BARS`, когда применимо. Audit должен быть **семантическим**, а не тупым grep по одному заголовку. Отсутствие буквальной строки `CHARACTER APPEARANCE / IDENTITY LOCK` в legacy prompt не является само по себе дефектом, если equivalent identity lock реально присутствует и однозначен. Это audit, а не разрешение автоматически переписывать творческий prompt. Автоматически допустимы только однозначные механические/documentation fixes. Содержательное изменение сцены, диалога, режиссуры или approval требует обычного editor/user workflow. Результат глубокой проверки записывается в `deep-audit-status.json`. ## 05.10.2026 — обязательные правила после проверки Scenes 24–27 Общие уроки проверки кошачьей ветки (сами сцены 24–27 ушли «В фильме»; примеры сцен — иллюстрация). Полные актуальные prompts всегда брать только из свежего `video-prompts.md` в `main`. - **Разделяй pair continuity и exact environment/composition.** Общий парный референс персонажей не должен одновременно задавать интерьер. Если есть утверждённое фото кабины/локации, выделяй его отдельным `PRIMARY EXACT ... reference` с абсолютным authority для пространства, света, масштаба мебели/архитектуры и композиции. - **Роль персонажа и сторона кадра — разные вещи.** Не выводи frame-left/frame-right из слов `pilot`/`navigator`. Если approved image показывает Рыжика слева, а Лучика справа, прямо фиксируй `RYZHIK frame-left`, `LUCHIK frame-right`, сохраняя роли отдельно. - **Масштаб нужно задавать относительно объектов.** Для животных недостаточно писать `normal size`: указывай `ordinary domestic-cat scale relative to seats/consoles/human`, плюс отрицательные ограничения `not giant / not half-human / not waist-high`. Если рядом человек — фиксируй относительную высоту. - **Если персонажа не должно быть видно, не корми модель его визуальным референсом.** Для Scene 26 Серёга — story/off-camera addressee; его image reference нельзя подключать к генерации. В prompt отдельно запрещай лицо, тело, силуэт, отражение, тень, частичный limb, lightsaber, появление/растворение. Это сильнее, чем просто `Serega off-camera`. - **Сохраняй удачные артефакты атмосферы из результата, если пользователь их явно одобрил.** В Scenes 26–27 нужен тонкий сухой ash/dust/ember particulate layer, даже если старое описание локации запрещало volcanic ash. Формулируй различие: `fine non-volcanic dry particulate REQUIRED`, `heavy volcanic ash storm FORBIDDEN`. - **Action scenes требуют anti-static lock.** Для динамичного боя явно запрещай длинные hero poses, solo glamour holds и frozen tableau; задавай непрерывное locomotion/re-angling/pressure и readable multi-character interaction. - **Одна правка должна быть перенесена во все production variants той же Scene.** Если Scene 27 имеет 30s основной prompt и split 2×15s, scale/atmosphere/action/reference corrections повторяются внутри каждого блока автономно. Движок не должен зависеть от текста соседнего prompt. - Technical success предыдущего render не означает approval и не разрешает rerun. Результат сначала оценивается человеком; confirmed lessons затем попадают в master и этот guide. ## 25.10.2026 — танцы, музыка и свобода исполнения Основание: [аудит 28 оригинальных роликов и точных отправленных промтов](reports/dance-prompt-audit-2026-10-25.md). Наблюдение: активное движение есть и у короткого сольного текста (121 знак), и у подробной кантины (8859 знаков). В слабоподвижных старых номерах встречаются прямые указания ждать, делать мелкие движения и долго держать позу. Это **не доказывает**, что длина сама вызывает неудачу: различались постановка, входы и модели; одинаковый текст также давал разные результаты. Практика для следующих редакций: описать, кто что исполняет, настроение, пространство и читаемый результат; дать свободной пластике развиваться. Серьёзные лица + энергичные тела сохраняют юмор Серёгиуса. Не раздавать каждому суставу команды. Сохранять точность там, где она нужна: взаимный жест у лица, реальные точки поддержки, руки на игровых поверхностях, удар корпусом инструмента после замаха, состояния стыка. Коты двигаются как коты; для них свобода не означает человеческую анатомию. Гипотезу об улучшении проверять по новым результатам, не объявлять подтверждённой после редактуры. Сравнение подробности делать при одинаковых модели, настройках, референсах и замысле; фиксировать фактически отправленный текст и несколько результатов при разрешённых попытках. Отдельно оценивать движение, лица/состав, физику гега и пригодность к монтажу. Сам аудит не разрешает дополнительные тестовые генерации. ## Scene Reference Pack automation — правила для промтов Reference-first, QC по одному кадру, сохранение кадров (`references/scenes/scene-N/` в `main`), восстановление входов из Topview, команда «запускай сцену N» (**генерация только по команде владельца, только безлимит через сайт Topview под входом владельца; платный путь MCP / Canvas запрещён, credits не тратить; технический `success` ≠ одобрение**) и контрольные точки — `SYNC-RUNBOOK.md` «Scene Reference Pack automation». Здесь — только то, что касается текста промта. **Prompt integration.** A prompt's `REFERENCES` section must distinguish identity authority, environment authority, prop authority, composition/pose helper and first/last-frame authority. A generated group/composition still must never silently become an identity authority. When a new approved still is adopted, update the scene's reference map and negative prompt against the failure it was designed to prevent. Нумерация `@ImageN` локальна для каждого автономного промта; роли задаются каноническими ролями, а не историческим именем файла `ImageN`.