coding-posture

Coding Posture — это навык для выбора рабочего режима перед нетривиальной задачей разработки. Он предлагает не играть роль «персонажа», а выбрать короткую процедуру по преобладающему риску: debug, fix, review, test-first, refactor, optimize, migrate, upgrade, integrate, spike или unstuck. Если задача сводится к одной простой строке или вообще не связана с кодом, навык прямо разрешает его пропустить. Если недостающие требования меняют реализацию, сначала нужно задать уточняющий вопрос, а после выбора режима одной строкой назвать его и причину. Основной принцип навыка — рабочий цикл «собрать контекст → локализовать проблему → внести минимальное изменение → запустить настоящую проверку → прочитать фактический результат → повторить». Это важно для карточки, потому что Coding Posture не обещает автоматическое исправление и не заменяет проектные инструкции: он задаёт порядок рассуждения и контрольные точки. Режим не расширяет полномочия агента, не разрешает небезопасные действия и не отменяет более строгие правила безопасности, пользователя или репозитория. В режиме debug сначала воспроизводят отказ, фиксируют точную команду и сообщение об ошибке, локализуют минимальный участок и проверяют одну гипотезу за раз. Финальная проверка должна снова запускать исходный failing command. Режим fix предназначен для небольшой известной срочной правки: он ограничивает diff, избегает лишних изменений зависимостей и по возможности оставляет узкую регрессионную проверку. Режим review применяется к security, auth, payments и ревью diff: выводы должны иметь привязку к файлам и строкам, а проверка охватывает корректность, безопасность, обратную совместимость, скрытые связи и пропущенные тесты. Режим test-first подходит, когда поведение удобно проверять тестом. Сначала формулируют или находят тест, запускают его в состоянии RED, затем делают минимальную реализацию, получают GREEN и только после этого выполняют более широкий набор проверок. Режим refactor сохраняет поведение: перед удалением нужно проследить call sites, флаги, тесты и документацию, не смешивать изменение поведения с очисткой и доказать эквивалентность существующими проверками. Режим optimize требует сначала измерить реальное узкое место профилированием или benchmark, записать baseline, изменить одну вещь и сравнить результат; похожая на дорогую часть кода сама по себе не является основанием для оптимизации. Для миграций кода, схемы или инфраструктуры используется режим migrate. Перед изменением состояния он требует определить путь восстановления, по возможности проверить этап на безопасной цели и предпочесть обратимые шаги. Режим upgrade требует прочитать changelog, release notes или migration guide, учесть транзитивные зависимости и lockfile, обновить места вызова только по реальным breaking changes и прогнать полный набор проверок. Режим integrate применяется при подключении внешнего API, сервиса или инструмента: сначала читают контракт, проверяют форму ответа, обрабатывают ошибки авторизации, таймауты, лимиты, повторные попытки, пагинацию и пустые или частичные ответы; внешняя зависимость считается недоверенной. Режим spike предназначен для прототипа или неизвестной библиотеки. Его артефакты нужно держать отдельно от production-путей, а результат завершать вердиктом validated, invalidated или unclear и списком того, что потребуется для production. Режим unstuck включают после повторных неудач или метаний: нужно остановить догадки, перечислить уже проверенные гипотезы и доказательства, сформулировать две наиболее вероятные причины, выбрать тест, который их различит, и собрать недостающую информацию до новых правок. Во всех режимах Coding Posture запрещает разрушительные git, deploy и data-команды без явно определённой области, включая force push, reset --hard, drop, delete и truncate. Нельзя объявлять задачу завершённой по повторному чтению собственного изменения: требуется реальный внешний feedback — тест, build, воспроизведение или другой check, который касается нужного пути. Нельзя ослаблять тесты, удалять их или подставлять жёсткие ожидаемые значения только ради зелёного результата. Если подходящего режима нет, «no mode» считается допустимым решением. Поэтому навык полезен как компактный выбор процедуры и минимальный safety-check перед работой, но его checklist не является гарантией корректности, полноценным security-аудитом, подтверждением качества продукта или заменой человеческого решения для неоднозначных и рискованных изменений.