skipi-box

Imported from ZloyRadetski/skipi-box (AGENTS.md). Install upstream with npx skills add ZloyRadetski/skipi-box. Copyright stays with the author.

Правила проекта Skipi

Источник поведения и границы

• Основная цель рефакторинга: максимум переносимого кода в shared/core, shared/app и shared/ui; Android/Desktop содержат реальные операции ОС, storage/I/O adapters и native/runtime wiring.
• Функциональность и её семантика переносятся из существующего Android-приложения точно. Не придумывать новые функции, defaults, конфликтные политики, editor flows или runtime-возможности.
• Перед переносом сверять Android-источник и при необходимости историю. Наличие текущего альтернативного Desktop-алгоритма не определяет каноническую семантику.
• Отсутствие мобильного переносимого сценария в текущем Desktop не является причиной исключать его перенос. Настоящее platform/native ограничение подтверждается конкретным механизмом.
• Сохранять существующие форматы и их фактический контракт. Не обещать round-trip неизвестных полей там, где текущий codec их игнорирует.
• Для профилей Desktop без resource-user-agent использовать Skipi/<текущая версия>/Desktop, по последнему явному уточнению пользователя. Android сохраняет прежний UA. Значение из .conf, включая явно пустое, имеет прежний приоритет; не подменять профильный fallback глобальной Desktop-настройкой загрузки.
• Текущий план/зависимости/статус: tasks/plan.md, checklist: tasks/todo.md. Исторические планы не заменяют последние указания пользователя.

Сначала тесты, затем production-код

Прямое правило пользователя: сначала пишутся тесты, затем код; код пишется под тесты, а не тесты под готовый код.

1. До production-изменения описать ожидаемое поведение по Android-оригиналу и написать поведенческие тесты следующего малого среза.
2. Запустить их до изменения реализации. Дефект/отсутствующий общий путь воспроизвести как RED; для чистого переноса зафиксировать работающий Android baseline и тот же контракт общего пути.
3. Затем написать минимальный код, получить GREEN и провести рефакторинг под теми же тестами.
4. Не менять expectations/snapshots под реализацию и не отключать тесты ради зелёной сборки. Проверять входы/результаты, а не зеркалить внутреннюю структуру кода.
5. Перед завершением запускать соответствующие suites и необходимые integration/compile/UI/native проверки; отчёт различает выполненные и непроведённые проверки.
6. В отчёте среза указывать тесты и исходный результат до production-кода, затем GREEN. Документирование само по себе не требует фиктивных поведенческих тестов.

Использовать существующий Gradle wrapper и конвенции Kotlin/Compose тестов в commonTest, app/src/test и desktopApp/src/test. Фактические команды и требования JDK/SDK находятся в разделе Q1–Q4 текущего плана. Успешный обычный Desktop unit suite без SKIPI_CORE_INTEGRATION_DIR не доказывает реальный FFM/Core запуск.

Координация

• Основной агент выступает оркестратором: разделяет задачи, удерживает контракты, проверяет тестовую спецификацию и итоговый diff.
• Для research и написания кода пользователь предпочитает subagents gpt-6-luna, reasoning max, когда соответствующие средства доступны.
• Тесты среза должны быть готовы до production-работы над ним; параллельно выполнять только независимые ветки со стабильными контрактами и без пересечения изменяемых файлов.
• Не повторять успешно завершённые проверки без новых изменений или нерешённой причины.
• Сохранять посторонние изменения, native submodule и пользовательские данные. Restore/reset QA выполнять на изолированных данных.