incremental-implementation

incremental-implementation — скилл для безопасной реализации изменений небольшими завершёнными срезами. Он применяется к многофайловым фичам, новым функциям по task breakdown, рефакторингу и ситуациям, когда до первой проверки уже хочется написать больше примерно ста строк. Основная идея проста: выбрать минимальную полную часть работы, реализовать её, протестировать, проверить результат, сохранить отдельный откатный шаг и только затем переходить к следующему срезу. Такой порядок позволяет обнаружить проблему в ранней части задачи до того, как она распространится на остальные изменения. Предпочтительный способ нарезки — вертикальный срез через весь путь продукта. Для функции, связанной с задачами, это может быть последовательность: сначала создание задачи через DB, API и базовый UI, затем список, после этого редактирование и в конце удаление с подтверждением. Каждый этап должен оставлять рабочий end-to-end путь. Когда backend и frontend развиваются параллельно, предлагается contract-first подход: сначала определить контракт, затем отдельно реализовать backend с API-тестами, frontend с согласованными mock-данными и после этого интеграцию. Для высокой неопределённости используется risk-first порядок: сначала проверяется самый рискованный участок, например WebSocket-соединение, и только потом поверх доказанной связи строится real-time функциональность. Перед написанием кода скилл требует проверить простоту решения. Нужно спросить, можно ли сделать меньше строк, оправданы ли абстракции и не строится ли механизм для гипотетических требований вместо текущей задачи. Scope discipline запрещает заодно чистить соседние файлы, менять импорты вне своей области, удалять непонятные комментарии, добавлять «полезные» функции и модернизировать синтаксис в файлах, которые лишь читаются. Одно изменение должно решать одну логическую задачу. Не следует смешивать компонент, рефакторинг и конфигурацию в одном срезе. Если найденная проблема не относится к текущей задаче, её нужно зафиксировать отдельно, а не исправлять мимоходом. Рабочие правила делают каждый промежуточный результат проверяемым. После каждого среза проект должен оставаться компилируемым, существующие тесты должны проходить, а новая часть — быть проверена соответствующим тестом или ручным smoke-проверкой. Незавершённую пользовательскую возможность следует скрывать безопасным feature flag, выключенным по умолчанию. Новые значения по умолчанию должны быть консервативными: например, уведомления не включаются без явного opt-in. Изменения в существующих файлах должны быть минимальными и легко откатываться; миграции базы должны иметь обратный путь. Отдельные небольшие шаги облегчают локализацию регрессии и позволяют не накапливать большой неработающий diff. Скилл прямо предупреждает о признаках неправильного процесса: больше ста строк без запуска тестов, несколько несвязанных изменений в одном срезе, перенос проверки «на самый конец», поломка сборки между шагами, большой незакоммиченный массив и создание новой утилиты ради одноразовой операции. Финальная проверка включает тесты, build, type-check, lint, проверку фактической работы и отсутствие незакоммиченных изменений. При этом метод не предназначен для однофайлового изменения одной функции, когда область уже минимальна и дополнительная нарезка не даёт пользы. Это дисциплина исполнения, а не повод превращать простой патч в искусственную архитектуру.