make-3d: 3D-модель через варианты

Скилл про форму работы, а не про решение. На входе уже известно, какая модель нужна, какие у неё состояния и 2–3 кандидата формы. Если это ещё не решено, сначала разбери с человеком через /mp-grill-me и возвращайся сюда.

Вариант — одна форма модели, построенная целиком одним исполнителем. Лист — снимок варианта по общему шаблону. Канон — исходник сцены, который видит человек; до выбора его не трогает никто.

Шаги

1. Сцена. Найди исходник сцены, команду сборки, где рисуются объекты, откуда берутся данные и адрес живой страницы. Сними, как сцена выглядит сейчас, и покажи снимок в чате картинкой. Готово: знаешь файлы объектов, команду сборки и живой адрес. Правила сцены (что где стоит, что нельзя закрывать, стиль) читай в её каноне (DESIGN.md, CONTEXT.md, README) и неси в бриф.
2. Демо-данные. Один набор на все варианты, где встречается каждое состояние модели и крайние случаи: ноль, один, много, каждый цвет. Готово: по набору можно проверить любое правило состояния.
3. Копии сцены. У каждого варианта своя папка-копия вне канона (node_modules симлинком на оригинал), свой порт и свой кеш сборщика. Папку для листов заведи постоянную, в репозитории человека (например artifacts/<дата>-<модель>/<вариант>/), чтобы листы пережили перезапуск сессии.
4. Бриф. Один шаблон на все варианты; различается только описание формы и её состояний. В брифе:
   • своя папка, свой порт, что трогать нельзя (канон, установленные скиллы, данные человека), останавливать только свои процессы по PID;
   • стиль сцены сохранить;
   • форма и каждое её состояние словами;
   • демо-данные и их формат;
   • листы (шаг 6) и путь для них;
   • «посмотри на листы сам; если деталь не читается или закрывает соседнее, поправь и сними заново»;
   • отчёт: пути к листам, изменённые файлы, формат данных одной строкой.

5. Запуск. Один исполнитель на вариант, все параллельно, в фоне. По умолчанию исполнитель — Codex CLI:

   codex exec -C <копия> --skip-git-repo-check -m <модель> -o <итог.md> - < <бриф.md>

   Модель — самая сильная из доступных Codex. Если CLI отвечает «model not supported», CLI устарел: возьми более новый (например тот, что поставляется с приложением) или обнови пакет. Codex недоступен — тот же бриф субагенту-исполнителю.

6. Листы. У каждого варианта один и тот же набор, одна камера и один свет, чтобы варианты сравнивались один к одному:

   • general.png — вся сцена, модель в контексте;
   • states.png — сетка состояний, у каждого номер и подпись в одну строку;
   • detail.png — крупный план детали, от которой зависит читаемость.

   Снимать после реальной задержки, когда анимации отыграли. Готово: у каждого варианта три листа, и на general.png модель различима без зума.

7. Показ. Листы варианта отправляй в чат картинками, как только вариант готов, не дожидаясь остальных. Когда готовы все: сравнение в 2–4 строки (что читается сильнее, что ближе к смыслу, где риск) и твоя рекомендация. Выбирает человек.
8. Канон. Выбранный вариант переносится в исходник сцены без демо-обвязки (подписи «эскиз», коллажи, демо-набор). Демо-данные заменяются настоящими: скан или источник, который сцена уже читает. Правила состояний закрываются тестами. Сборка и тесты зелёные, коммит только своих путей. Финальные листы на настоящих данных — в чат. Живую страницу открой сам и сверь с листами; если видишь старую версию, перезагрузи с обходом кеша. Если у проекта есть словарь терминов, добавь туда модель и её состояния.

Данные человека на сцене

Модель показывает факт, а не содержимое: имена файлов и флаги состояния. Содержимое файлов, значения переменных и адреса репозиториев на сцену не попадают. Если сцена уходит другим людям (урок, общий экран), новые поля идут туда только по слову человека.