| name | feature-architect |
| description | Обязательный протокол проектирования перед реализацией нового функционала. Используй ВСЕГДА при запросе на добавление новых механик, систем или существенном изменении логики. Гарантирует архитектурную чистоту, TDD подход и анализ производительности. |
Feature Architect: Zenith Protocol
Этот навык ЗАПРЕЩАЕТ писать код до утверждения Технического Дизайна (Design Doc).
Рабочий процесс (Workflow)
Шаг 1: Анализ (Code Mapping & API Review)
- Найди все затронутые классы в
code_map.md.
- Изучи соответствующие модули API (
api/items.md, api/mechanics.md и др.).
- Выяви потенциальные конфликты с существующими системами.
Шаг 2: Выбор паттерна (Blueprint Matching)
Выбери подходящий шаблон из patterns.md. Если паттерна нет — предложи архитектурное решение на основе "Lead Developer Mandates" из gemini.md.
Шаг 3: Составление Технического Дизайна (Design Doc)
Предоставь пользователю отчет со следующей структурой:
- Цель: Краткое описание фичи.
- Архитектура:
- Компоненты: Какие новые
ItemComponent или BlockEntity будут созданы.
- Data Structure: Новые поля в JSON (предметы, блоки, конфиги).
- Logic Flow: Последовательность вызовов (например:
Input -> Player -> World -> Event).
- Производительность (Performance):
- Как часто будет выполняться код (каждый тик или по событию)?
- Есть ли тяжелые операции (поиск пути, BFS, сложные циклы)?
- Как минимизировать нагрузку (кэширование, интерполяция, битовые маски)?
- План Верификации (TDD):
- Как мы проверим корректность (логи, визуальные индикаторы, тестовые предметы)?
Шаг 4: Одобрение
ОСТАНОВИСЬ и дождись подтверждения от пользователя ("ОК", "Делай", "Directives"). НИКОГДА не пиши код до этого момента.
Шаг 5: План мод
ОБЯЗАТЕЛЬНО работай в план моде для лучшего структурирования своей работы.
Lead Developer Mandates (Напоминание)
- Никакого хардкода строк или числовых ID.
- Использование
Identifier.of().
- Композиция вместо наследования.
- Битовые маски для метаданных.
- Интерполяция
prevPosition для всех сущностей.
