implementation-workflow

name	implementation-workflow
description	Обязательный протокол проектирования и внедрения функционала для J-DiskTree. Активирует режим PLAN MODE, проверку на потокобезопасность, строгий аудит I/O операций и рендеринга на Canvas. Запрещает прямое использование write\_file для существующих файлов.

ОПИСАНИЕ НАВЫКА

Этот файл содержит обязательный чек-лист и алгоритм мышления, который должен применяться ПЕРЕД написанием любой строчки кода для нового функционала. Цель навыка — предотвратить блокировку UI-потока, исключить ConcurrentModificationException, обеспечить максимальную скорость сканирования диска и сохранить чистоту архитектуры (MVI/MVVM).

!! КРИТИЧЕСКИЕ ПРАВИЛА (БЕЗОПАСНОСТЬ И ПРОЦЕСС) !!

1. ОБЯЗАТЕЛЬНЫЙ PLAN MODE: Перед началом ЛЮБОЙ реализации ты ОБЯЗАН вызвать инструмент enter_plan_mode (или просто выдать блок [PLAN MODE: ACTIVE]). Работа без зафиксированного и одобренного плана запрещена.
2. ЗАПРЕТ write_file НА СУЩЕСТВУЮЩИЕ ФАЙЛЫ: Инструмент write_file используется ИСКЛЮЧИТЕЛЬНО для создания новых файлов.
   • НИКОГДА не используй write_file для изменения уже созданных файлов (это ведет к потере смежного кода). Используй патчинг или выдавай diff-блоки.

ТРИГГЕР ЗАПУСКА

Навык запускается автоматически при запросах пользователя на:

• Добавление новой логики обхода диска или фильтрации файлов.
• Создание или изменение алгоритмов рендеринга (Treemap).
• Добавление новых экранов или компонентов в Compose Multiplatform.
• Изменение моделей данных (State) или управления потоками (Coroutines/Threads).

ФАЗА 1: СБОР КОНТЕКСТА (DISCOVERY)

Прежде чем формировать план, ответь себе на следующие вопросы (во внутреннем монологе или в выводе PLAN MODE):

1. Потокобезопасность: Блокирует ли новая фича главный поток (Main UI Thread)? Если да — перепроектируй.
2. Иммутабельность: Мутируют ли передаваемые данные? Как предотвратить гонку данных между I/O сканером и отрисовкой Compose?
3. Ограничения ОС: Как фича поведет себя при встрече с AccessDeniedException (Windows) или скрытыми/системными файлами?
4. Память (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. Суть изменений: Кратко (1-2 предложения), что мы делаем технически.
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, отрисовка, "глупые" компоненты).
3. Остановка: Ожидание команды на старт.

ФАЗА 4: ИСПОЛНЕНИЕ (EXECUTION)

1. Реализация: Только после явного аппрува (команды) приступай к написанию кода строго по шагам плана.
2. Валидация: Визуальная проверка кода на отсутствие блокировок UI-потока.
3. Обновление состояния: Если задача добавила важный модуль (например, внедрен алгоритм Squarified), ОБЯЗАТЕЛЬНО обнови файл .gemini/PROJECT_STATE.md.
4. GIT: Предложи текст для коммита на английском языке (настоящее время, conventional commits).

CRITICAL RULE: Никогда не пропускай фазу ожидания. Если план не утвержден пользователем, генерация кода запрещена.