Перейти к содержанию

WORKFLOW — как мы работаем вместе

Договорённость от 2026-08-18. Появилась после второго разбора совета, который показал: за пять дней проект дал 7 коммитов прозы и ноль строк логики, а на доске не была закрыта ни одна из 45 задач. Значит нужен не более подробный план, а механизм, где работа не считается сделанной, пока её не посмотрел человек.

Главное правило

Прямой пуш в main технически запрещён. Не договорённость, а настройка: во всех десяти репозиториях ветка защищена с push_access_level = 0 — никто, включая владельца и Claude. Проверено: сервер отклоняет пуш с pre-receive hook declined.

Любое содержательное изменение идёт так:

ветка → коммиты → merge request с полным описанием → ревью владельца → мерж владельцем

Мержит владелец. Исключение, введённое владельцем 2026-08-20: если апрув владельца уже стоит, Claude мержит сам, не переспрашивая. Апрув в GitLab не мержит автоматически, и MR простаивали именно из-за этого.

Обычная документация не ждёт апрува. Claude сам мержит MR, если в нём нет кода и изменены только Markdown-файлы с описанием проекта или сервиса (docs/**, обычный README.md). Перед мержем он всё равно сверяет текст с кодом и проверяет, что MR действительно не затрагивает исполняемые файлы. В этот коридор не входят CLAUDE.md, AGENTS.md, docs/TOOLING.md, CI, Compose и инструкции, меняющие доступы или порядок внешних действий: это договорённости и границы безопасности, их владелец смотрит сам.

Что обязано быть в каждом MR

Шаблон подставляется автоматически (.gitlab/merge_request_templates/default.md), пять разделов:

Раздел Зачем
Что меняется одним абзацем, в каком состоянии остаётся система
Почему именно так варианты, выбор, чем заплатили. Главный раздел
На что смотреть при ревью самые спорные места, и где Claude меньше всего уверен
Как проверено конкретные команды и что видно глазами, а не «тесты проходят»
Что НЕ сделано осознанно отложенное и известные ограничения

Раздел «где я меньше всего уверен» — не вежливость. Ревью тем полезнее, чем точнее названо слабое место; прятать сомнения означает тратить чужое внимание впустую.

Как идёт ревью

  • Вопросы — комментариями к строкам, Claude отвечает там же, в треде.
  • Непонятный код — дефект описания, а не читателя. Если пришлось спрашивать «что тут происходит» — либо код переписывается понятнее, либо в нём не хватает комментария о причине.
  • Владелец должен разбираться во всём проекте. Исключение — внутренности вёрстки и внутренности wger: там достаточно понимать назначение и границы, но не каждую строку.
  • Замечание, с которым Claude не согласен, обсуждается, а не молча исполняется и не молча игнорируется.

Размер MR

Мелкий MR, который можно прочитать целиком, лучше большого и правильного. Ориентир: один MR — одно решение. Если в описании раздел «почему именно так» распадается на два независимых сюжета, это два MR.

Отдельно: изменения контрактов (proto) и схемы идут отдельными MR от кода, который ими пользуется, — их читают иначе и цена ошибки другая.

Что от владельца требуется по ходу

Три разных типа участия, они помечены на доске метками do:::

  • do::user-manual — то, чего Claude сделать не может: DNS, регистрация приложений в Google, доступы.
  • do::user-verify — подтвердить, что не сломалось: например, жив ли VPN после правки Caddy. У Claude нет клиентов и глаз владельца.
  • do::user-test — проверить в реальных условиях: зал, телефон, мобильная сеть.

Плюс ревью каждого MR — оно не помечается меткой, оно всегда.

Что Claude делает без спроса

  • Ветки, коммиты, MR, описания, ответы в тредах.
  • Чтение чего угодно, диагностика, замеры.
  • Локальный запуск тестов и линтеров.

Чего Claude не делает без явного разрешения

  • Мерж в main — никогда.
  • Изменения на VPS (там живёт VPN) и на чужих VM.
  • Применение миграций к базе с данными.
  • Удаление чего бы то ни было, что не создано в этой же сессии.

Документация идёт вместе с кодом

Правило из корневого CLAUDE.md остаётся: меняешь поведение сервиса — правишь его раздел в SERVICES.md; меняешь схему или контракт — правишь DATA_MODEL.md; принял решение с долгими последствиями — ADR в DECISIONS.md; напоролся на неочевидное — запись в LESSONS.md.

Новое ограничение, из разбора совета: новых ADR без закрытых задач не заводим. Документ, описывающий работу, не должен появляться раньше работы.