| name | implementation-workflow |
| description | Обязательный протокол проектирования и внедрения функционала для J-DiskTree. Активирует режим PLAN MODE, проверку на потокобезопасность, строгий аудит I/O операций и рендеринга на Canvas. Запрещает прямое использование write\_file для существующих файлов. |
ОПИСАНИЕ НАВЫКА
Этот файл содержит обязательный чек-лист и алгоритм мышления, который должен применяться ПЕРЕД написанием любой строчки кода для нового функционала. Цель навыка — предотвратить блокировку UI-потока, исключить ConcurrentModificationException, обеспечить максимальную скорость сканирования диска и сохранить чистоту архитектуры (MVI/MVVM).
!! КРИТИЧЕСКИЕ ПРАВИЛА (БЕЗОПАСНОСТЬ И ПРОЦЕСС) !!
- ОБЯЗАТЕЛЬНЫЙ PLAN MODE: Перед началом ЛЮБОЙ реализации ты ОБЯЗАН вызвать инструмент enter_plan_mode (или просто выдать блок [PLAN MODE: ACTIVE]). Работа без зафиксированного и одобренного плана запрещена.
- ЗАПРЕТ write_file НА СУЩЕСТВУЮЩИЕ ФАЙЛЫ: Инструмент write_file используется ИСКЛЮЧИТЕЛЬНО для создания новых файлов.
- НИКОГДА не используй write_file для изменения уже созданных файлов (это ведет к потере смежного кода). Используй патчинг или выдавай diff-блоки.
ТРИГГЕР ЗАПУСКА
Навык запускается автоматически при запросах пользователя на:
- Добавление новой логики обхода диска или фильтрации файлов.
- Создание или изменение алгоритмов рендеринга (Treemap).
- Добавление новых экранов или компонентов в Compose Multiplatform.
- Изменение моделей данных (State) или управления потоками (Coroutines/Threads).
ФАЗА 1: СБОР КОНТЕКСТА (DISCOVERY)
Прежде чем формировать план, ответь себе на следующие вопросы (во внутреннем монологе или в выводе PLAN MODE):
- Потокобезопасность: Блокирует ли новая фича главный поток (Main UI Thread)? Если да — перепроектируй.
- Иммутабельность: Мутируют ли передаваемые данные? Как предотвратить гонку данных между I/O сканером и отрисовкой Compose?
- Ограничения ОС: Как фича поведет себя при встрече с AccessDeniedException (Windows) или скрытыми/системными файлами?
- Память (OOM): Не приведет ли фича к OutOfMemoryError при парсинге диска C:\ с 2 000 000 файлов?
ФАЗА 2: АРХИТЕКТУРНОЕ ПРОЕКТИРОВАНИЕ (STRICT CHECKLIST)
Core & I/O Checklist (Java Backend)
- [ ] I/O API: Используется исключительно java.nio.file. Никаких java.io.File.
- [ ] Concurrency: Сканирование строго делегировано в фоновые потоки (ForkJoinPool, VirtualThreads или Dispatchers.IO).
- [ ] Error Handling: Ошибки файловой системы молча перехватываются (swallowed), процесс сканирования не прерывается.
- [ ] Domain: Модели данных (FileNode, Tree) реализованы через неизменяемые record или классы с final полями.
UI & Presentation Checklist (Compose Multiplatform)
- [ ] State Management: Состояние приложения централизовано во ViewModel/Стейт-холдере и передается в UI как Immutable StateFlow/State.
- [ ] Rendering Constraint: Для отображения тысяч файлов используется ИСКЛЮЧИТЕЛЬНО вызов drawRect внутри компонента Canvas. Запрещено создавать отдельные @Composable ноды для каждого файла.
- [ ] Separation of Concerns: UI-компоненты "глупые". В них нет логики сканирования диска или расчета координат Treemap.
- [ ] UX: Продуманы ли индикаторы прогресса (Progress Bar) для длительных I/O операций?
ФАЗА 3: ПРЕЗЕНТАЦИЯ ПЛАНА (PLAN MODE OUTPUT)
После прохождения чек-листа сформируй ответ пользователю в следующем формате:
- Суть изменений: Кратко (1-2 предложения), что мы делаем технически.
- Шаги реализации (Архитектура):
- Step 1: Domain & Models (Records, иммутабельные структуры).
- Step 2: Core & I/O (Сканеры NIO, пулы потоков, алгоритмы).
- Step 3: State Management (ViewModel, объединение I/O и UI).
- Step 4: Compose UI (Canvas, отрисовка, "глупые" компоненты).
- Остановка: Ожидание команды на старт.
ФАЗА 4: ИСПОЛНЕНИЕ (EXECUTION)
- Реализация: Только после явного аппрува (команды) приступай к написанию кода строго по шагам плана.
- Валидация: Визуальная проверка кода на отсутствие блокировок UI-потока.
- Обновление состояния: Если задача добавила важный модуль (например, внедрен алгоритм Squarified), ОБЯЗАТЕЛЬНО обнови файл .gemini/PROJECT_STATE.md.
- GIT: Предложи текст для коммита на английском языке (настоящее время, conventional commits).
CRITICAL RULE: Никогда не пропускай фазу ожидания. Если план не утвержден пользователем, генерация кода запрещена.
