empty-gen-project

Imported from getcher123/empty-gen-project (AGENTS.md). Install upstream with npx skills add getcher123/empty-gen-project. Copyright stays with the author.

Рабочие правила проекта

Единый вход: создание зон и внесение правок, общий шаблон чек-листа. Эти правила действуют для всех агентов и новых итераций проекта.

Перед каждой задачей

1. Определить зону и объект по запросу; не направлять новую зону в Home Care по историческому default. Прочитать индекс zones/<zone>/README.md, относящиеся индексы категорий и актуальные ТЗ/решения пользователя.
2. Выбирать конкретные версии по индексам и решению пользователя, не по максимальному номеру или latest. История выпусков и версионных команд — справочный архив, не актуальное поручение. Исторические генераторы сохранять; перед применением проверять их соответствие текущему объекту и версии.
3. Прочитать правило ревью, навигацию журнала опыта и применимые записи; при повторной проблеме открыть первичный отчёт. Весь архив без необходимости не загружать.
4. Зафиксировать scope, неизменяемые части, источники/версии, допущения и затронутые результаты. Вести один рабочий сквозной чек-лист зоны по process-checklist-handoff: Current Status, Handoff, дополняемый журнал и ссылки на этапные документы. Старые чек-листы не пересоздавать задним числом.
5. Запрос на анализ, документацию, чертёж или презентацию не разрешает автоматически платные изображения, Blender или возобновление приостановленного объекта.

Сквозной маршрут и происхождение формы

Вводные → исходные визуализации / очистка → проектирование и чертежи → адаптированный серый объём → проверка / выбор основы → оформление / выкладка → рендер → выдача. Этапы, входы и go/no-go — в гайде.

• Входящие 3D-визуализации и их проверенная очистка задают исходную архитектуру, пространственный характер, выбранные свет/ракурс. Актуальные ТЗ/чертежи задают размеры и согласованные изменения. Неизменённую архитектуру сохранять; отменённые детали не переносить.
• При конфликте источников не усреднять форму в генерации: разрешить расхождение, актуализировать схему в рамках задачи либо запросить решение. Неизвестные части и размеры помечать допущениями. При отсутствии пригодных исходников — gap и согласованная альтернатива, не выдуманный «оригинал».
• Обязательный старт новой зоны — исходный пайплайн и zone-reference-pipeline. Если навык недоступен, прочитать полный проектный workflow и сообщить о fallback. Получить весь согласованный нейтральный M, проверить и зафиксировать M-gate; каждый G — только из соответствующего M. Новое ТЗ в исходную очистку не внедрять. Использовать профильные init/check/freeze-команды; они не генерируют изображения и не заменяют визуальную проверку. До полного комплекта или явного исключения пользователя не переходить к зависимой финальной генерации.
• После проектирования — объёмные референсы по актуальным чертежам и чек-лист. Это адаптация проверенной архитектурной основы, не обязательная реконструкция с нуля по плоской схеме и не новый G исторической M/G-пары.
• Первый проектный объём — основные архитектурные формы без детализации: силуэт, дуги/завороты, толщина, связи, проёмы, полки/ниши, тумбы, отдельная столешница/цоколь, уровни и носители. Нейтральный серый, без отделки/брендинга/товаров/новых узлов; оборудование условно. «Без деталей» не означает удалять конструкцию. Пригодный существующий объём повторно не генерировать.
• Связанную конструкцию не разрезать на новые самостоятельные стенды. Не придумывать стену помещения/угол/кабину позади свободного объекта; собственные конструктивные стенки сохранять. Пристенность — только по ТЗ/источнику. Для включённой пары с/без переднего объекта одна камера; иной ракурс — отдельный вид. Состав видов определяется задачей, не числом ниш/ракурсов Personal Care.
• До оформления — проверка геометрии конкретного объекта и выбор пользователя либо явное разрешение продолжать с указанным черновиком. Все производственные чертежи всей зоны не обязательны. Независимая подготовка точных брендовых исходников допустима параллельно.

Внесение правок

Обязательный порядок — изменения и возврат на этапы.

• До выполнения записать что изменилось, исходную версию, неизменяемые части, затронутые материалы и разрешённый объём.
• Режим — в рамках запроса: обновить заказанный результат и необходимые исходники; прочие зависимые материалы отметить как требующие обновления, не пересобирать автоматически.
• Конструктивную правку проводить через ТЗ/чертёж и затронутые проектные референсы, не оставлять только в AI-картинке. Текст/материал/выкладку возвращать к их исходному мастер-слою, не перестраивая незатронутую форму.
• Различать локальную правку выбранного кадра и новую генерацию от обновлённых источников. После локальной правки просматривать весь кадр. Восстановление нативной графики не должно скрывать дрейф конструкции.
• Актуальность для текущего задания, пользовательское утверждение и технические/визуальные проверки учитывать отдельно в Markdown-индексе/чек-листе; не менять ради этого machine manifest. Старые отчёты и pass не переписывать.
• При остановке пользователя — прекратить новые запросы/повторы/сборки, сохранить состояние и Handoff без автоматической следующей команды. Возобновление только по поручению.

Гейт первого ревью новой сущности

Правило пользователя от 15.09.2026: независимое визуальное ревью обязательно один раз после создания новой сущности, перед её первой передачей человеку на утверждение. После циклов правок той же сущности — только по явной просьбе или при низкой собственной уверенности; конкретное сомнение назвать заранее. Версия, экспорт или новый ракурс сами по себе не новая сущность.

• Reviewer — субагент, не автор проверяемой версии; разрешение только на ограниченное read-only ревью, не на изменения или платные запросы.
• Открывать реальные PNG/виды и первичные ТЗ/планы/референсы. Сохранять reviewer ID, версии/SHA, источники, замечания и вердикт в соответствующем _technical/.
• Авторская визуальная и соразмерная техническая проверка обязательны. Подтверждённые ошибки исправить; авторское закрытие не подменяет вердикт reviewer. Старый pass не переносить на новые SHA; отсутствие повторного ревью само по себе не блокирует обычную правку (not_required_after_revision).
• Если обязательное первое ревью недоступно — обозначить незакрытый гейт; непроверенный черновик только для уточнения, не как готовый к первому утверждению. Исключение — по явному решению пользователя. Массовое ретроспективное ревью не запускать.
• Утверждает человек; проверки не означают производственной готовности.

Куда сохранять результат

• Пользовательские AI-генерации, Blender-рендеры и презентации — прямо в zones/<zone>/renders/.
• Чертежи draw.io и PDF/SVG/PNG/validation — прямо в zones/<zone>/drawings/.
• ТЗ, brief, токены, редакции и рабочий чек-лист — прямо в zones/<zone>/techspec/.
• Редактируемые Blender-файлы — прямо в zones/<zone>/models/.
• Промпты, ответы, логи и отчёты — единственный _technical/ соответствующей категории. Без папок по датам/batch/провайдеру/попытке/варианту.
• input/ неизменяем; references/ — подготовленные общие исходники; docs/ — правила; scripts/ — воспроизводимые инструменты. Подробности — структура, реестр референсов.
• Имена: <zone>-<object>-<view-or-purpose>-<route>-vNN.<ext>. Следующая свободная версия; существующие результаты и исторические генераторы не перезаписывать.

Профильные маршруты

• Изображения по умолчанию: graphitek-imagegen → LaoZhang → gemini-content; гайд. FAL — fallback по правилам навыка после двух одинаковых LaoZhang-попыток при временном сбое, кроме hard error. image_gen.imagegen — только по прямому запросу/явному сравнению. Промышленный стиль Graphitek не переносить в Amway.
• Чертежи: drawio-technical-drawings, единый A3-стиль проекта по I-02, native draw.io + PDF/SVG/PNG + validation. Экспорт/пакет — общие инструменты навыка; текущий сборщик и параметры конкретного объекта — из его индекса. Частные/учебные размеры HC и PC не норматив для новых зон; общие параметры — реестр.
• 3D: blender-modeling-visualization. Для воспроизводимой сборки/рендера Blender Python в отдельном background-процессе, без переключения экрана пользователя. Blender MCP — только при доступности в текущем сеансе и необходимости live-инспекции/правки.
• Презентации: design-variant-presentations, гайд. Общий сборщик, единый 16:9: описание слева, крупный рендер справа, код/краткое название; PDF/PPTX/PNG-обзор. Токены текущего бренда и неизменённый мастер-логотип, без растяжения/перегенерации готовых изображений и без отмены текущего выбора ради сравнения истории.
• Оригинальные логотипы, тексты и этикетки брать из применимых бренд-материалов; их актуальность и права фиксировать. Исторические или AI-знаки не заменяют мастер. Частные мастер-файлы/команды — в индексах зоны.
• Figma считать доступной только после live-проверки инструмента; установленный плагин не подтверждает доступ агента.

Память проекта

Журнал опыта хранит сложности и проверенные решения; архив маршрутов — хронологию версий, не актуальные указатели.

После существенной трудности/решения в разрешённой работе обновить EXP-ID или добавить следующий: симптом, причина с уровнем уверенности, действие, результат, проверка и ссылки. Различать проверенный факт, наблюдение и гипотезу. Подробные доказательства — в _technical/, без секретов/новых batch-папок. При запросе только анализа/ответа не менять журнал автоматически. Перенос межпроектного приёма в общий навык — лишь отдельная разрешённая задача; клиентские решения остаются в проекте.

После изменений журнала/маршрутов выполнить node scripts/verify-project-lessons.cjs; структура не заменяет содержательную проверку. Файловая память не означает обучение модели или автоматическую синхронизацию облака.