mister-wolf 2.22.1 → 2.23.0

package/templates/base/skills/wolf-git/reference/git-collaboration-policy-v1.1.md

@@ -0,0 +1,553 @@
+# Регламент совместной работы с Git
+
+**Версия документа:** 1.1  
+**Дата:** 1 ноября 2026 года  
+**Назначение:** нормативная основа для людей, агентов и разработки переносимых инструментов и скиллов Mr. Wolf.  
+**Статус:** проект регламента по итогам согласования процесса; введение в конкретном репозитории требует настройки защит и CI.
+
+## 1. Область действия и язык требований
+
+Регламент применяется к небольшим проектам с одной актуальной линией выпуска, одной интеграционной веткой `main` и параллельной работой людей и агентов. Ветка `dev` не используется. Постоянные ветки поддержки старых релизов не создаются.
+
+Правила одинаковы для одного хоста, нескольких хостов, отдельных clones и связанных worktrees. Харнес агента, Git-хостинг, CI и registry могут различаться. Основой служат стандартный Git, переносимые скрипты и явно заданная политика проекта.
+
+В документе:
+
+- **ОБЯЗАТЕЛЬНО** — условие допуска к следующему этапу.
+- **ЗАПРЕЩЕНО** — действие не входит в обычный процесс и не может выполняться ради обхода гейта.
+- **ДОПУСКАЕТСЯ** — разрешённый вариант при указанных условиях.
+- **Гейт** — проверяемые условия перехода между этапами. Непройденный гейт блокирует конкретный переход, а не всю независимую работу проекта.
+
+Регламент определяет требуемое поведение. Приведённые ниже поля, статусы и операции — контракт для будущей реализации, а не утверждение о существующих командах Wolf.
+
+## 2. Основные понятия
+
+| Понятие | Значение |
+|---|---|
+| Общий репозиторий | Назначенный Git remote, через который публикуют и принимают работу |
+| Локальная копия | Clone на конкретном хосте со своими локальными данными |
+| Worktree | Отдельный рабочий каталог, связанный с локальным Git-репозиторием |
+| Рабочая ветка | Ветка одной задачи с владельцем и целевой веткой |
+| Родительская ветка | Рабочая ветка ведущего участника, принимающая результаты его подзадач |
+| Baseline | Конкретный разрешённый SHA, от которого создана рабочая ветка |
+| Checkpoint | Локальный коммит, сохраняющий известный набор изменений; не является приёмкой |
+| MR | Запрос на слияние; включает также PR на платформах с таким названием |
+| Приёмка | Решение, что результат задачи отвечает требованиям и может быть предъявлен к интеграции |
+| Интеграция | Включение принятого результата в целевую ветку |
+| Кандидат интеграции | Точный merge-коммит с первым родителем — SHA целевой ветки, вторым — принятый SHA исходной ветки; проверяется до публикации |
+| Выпуск | Публикация конкретной версии из выбранного принятого коммита |
+| Digest образа | Идентификатор содержимого образа или его индекса, в отличие от изменяемого тега |
+
+**Изменено, сохранено, опубликовано, принято, интегрировано и выпущено — разные состояния.**
+
+| Состояние | Минимальное подтверждение |
+|---|---|
+| Изменено | Файлы в рабочем каталоге |
+| Сохранено | Локальный SHA, содержащий нужную работу |
+| Опубликовано | Наблюдаемая ссылка в общем репозитории, из которой доступен этот SHA |
+| Принято | Решение уполномоченного принимающего для конкретного SHA |
+| Интегрировано | Подтверждённый результат MR в целевой ветке |
+| Выпущено | Git-тег версии и подтверждённый опубликованный образ с digest |
+
+## 3. Ответственность и полномочия
+
+Роли обозначают ответственность, а не обязательные отдельные процессы или агентов. Человек может выполнять роль ведущего; ведущий агент Wolf — принимать результаты исполнителей.
+
+| Участник | Ответственность и полномочия |
+|---|---|
+| Владелец проекта | Утверждает политику, полномочия, обязательные проверки и настройки защиты |
+| Владелец задачи / ветки | Отвечает за историю ветки, checkpoint, публикацию, актуализацию и уборку своих рабочих копий |
+| Ведущий участник | Назначает подзадачи, принимает дочерние MR и отвечает за общий результат своей ветки |
+| Принимающий | Проверяет требования задачи и разрешает предъявление конкретного SHA к интеграции |
+| Обработчик интеграции | Последовательно проверяет кандидатов и обновляет `main` в пределах заданных правил |
+| Оператор выпуска | Явно запускает выпуск версии из выбранного SHA; человеком или агентом согласно политике проекта |
+| CI выпуска | Проверяет запрос, создаёт тег, собирает и публикует образ, запускает очистку registry |
+
+У рабочего каталога один активный писатель. У рабочей ветки один активный владелец записи и публикации. Другие участники предлагают изменения через собственные ветки и MR.
+
+Назначенный владелец задачи вправе и обязан создавать локальные checkpoint-коммиты своих изменений в назначенной ветке. Это постоянное полномочие: повторное разрешение на каждый коммит не требуется. Публикация рабочей ветки разрешается назначением на задачу, если проект не установил иной порядок.
+
+Владелец не вправе включать неизвестные или чужие изменения в свой коммит. Если исполнитель не имеет права коммитить, в поручении ОБЯЗАТЕЛЬНО указывается ведущий, который сохраняет его результат до остановки или передачи. Обязанность сохранить работу не может оставаться без ответственного.
+
+Право коммитить и публиковать рабочую ветку не даёт права напрямую менять `main`, создавать релизные теги или обходить проверки. Стюард не участвует в обычном контроле Git-процесса: состояние проверяют инструменты, решения принимают назначенные участники.
+
+## 4. Модель веток и дерева задач
+
+### 4.1. Общие правила
+
+1. `main` содержит интегрированные результаты и является базой независимых задач.
+2. Непосредственная разработка и ручные checkpoint-коммиты в `main` ЗАПРЕЩЕНЫ.
+3. Каждая новая задача получает отдельную ветку. Завершённые имена веток повторно не используются.
+4. Независимые ведущие участники создают ветки от проверенного SHA общего `main`.
+5. Субзадача ответвляется от явно выбранного SHA родительской рабочей ветки и предъявляется обратно в неё.
+6. После окончательной интеграции рабочая ветка закрывается. Последующие изменения оформляются новой задачей и веткой.
+7. Опубликованную историю рабочих веток не переписывают. Историю `main` и опубликованные релизные теги не переписывают никогда в рамках штатного процесса.
+
+### 4.2. Пример
+
+| Участник | Ветка | База при создании | Цель MR |
+|---|---|---|---|
+| Ведущий А | `feat/123-some-a` | Проверенный SHA `main` | `main` |
+| Субагент А1 | `feat/124-some-a1` | SHA `feat/123-some-a` | `feat/123-some-a` |
+| Субагент А2 | `fix/125-some-a2` | SHA `feat/123-some-a` | `feat/123-some-a` |
+| Ведущий Б | `feat/126-some-b` | Проверенный SHA `main` | `main` |
+
+Префиксы `feat/`, `fix/`, `docs/`, `chore/` помогают навигации. Они не определяют полномочия. Имя включает уникальный идентификатор задачи и краткое описание. Связь с родителем хранится явно, а не вычисляется по похожести названий.
+
+Ведущий не предъявляет свою ветку в `main`, пока необходимые дочерние результаты не приняты, а оставшиеся подзадачи не закрыты, отменены или явно вынесены в самостоятельную работу. После готовности родительского MR запись в его ветку замораживается; изменение снимает готовность.
+
+## 5. Работа на одном и нескольких хостах
+
+| Размещение | Обязательное правило |
+|---|---|
+| Один clone, связанные worktrees | Каждому активному писателю — отдельный worktree и отдельная ветка |
+| Несколько clones на одном хосте | Каждый clone самостоятельно проверяет и синхронизирует состояние |
+| Разные хосты | Обмен коммитами через общий репозиторий; разные активные владельцы работают в разных ветках |
+| Передача одной ветки | Сначала остановка прежнего владельца и публикация; затем подтверждённое принятие новым |
+
+Договорённость «редактируем разные файлы» не разрешает независимую одновременную запись в один рабочий каталог. Параллельные независимые писатели используют разные ветки.
+
+Связанные worktrees имеют общие локальные ветки и часть Git-метаданных. Инструменты ОБЯЗАТЕЛЬНО координируют операции над общими refs и служебным состоянием clone. Нельзя изменять ветку, используемую другим владельцем, или обходить защиту Git от её одновременного checkout.
+
+`git worktree lock` не считается блокировкой записи для агентов или механизмом распределённого владения. Владение отражается в состоянии задачи, а прекращение записи подтверждает прежний владелец или ответственный ведущий после остановки процесса.
+
+Факт потери связи или давность активности не разрешают второму участнику немедленно продолжить запись в ту же ветку. При сомнении создаётся отдельная ветка восстановления, а владение разбирается явно.
+
+## 6. Вход в работу: проверка и актуализация
+
+### 6.1. Обязательная последовательность
+
+При начале задачи, возобновлении после перерыва, рестарта или смены владельца участник:
+
+1. Проверяет идентичность репозитория, адрес общего remote, хост, путь worktree и ветку задачи.
+2. Проверяет staged, unstaged, untracked-файлы и известные ценные файлы вне Git.
+3. Проверяет незавершённые merge, rebase, cherry-pick и другие Git-операции.
+4. Проверяет назначенного владельца, baseline, локальный HEAD и сохранённые сведения о задаче.
+5. Получает актуальные refs общего репозитория и фиксирует время успешного наблюдения.
+6. Отдельно сравнивает рабочую ветку с её опубликованной версией и с целевой веткой MR.
+7. Только после этого выбирает разрешённое обновление или восстановление.
+
+Fetch обновляет сведения об удалённом состоянии, но не означает включения изменений в рабочую ветку. Старое значение remote-tracking ref не является подтверждением текущего состояния сервера.
+
+### 6.2. Локальный `main`
+
+После успешного получения удалённого состояния применяется таблица:
+
+| Локальный `main` относительно общего `main` | Разрешённое действие |
+|---|---|
+| Совпадает | Использовать SHA как проверенную базу |
+| Только отстаёт | Обновить fast-forward при чистом каталоге и отсутствии чужого владельца |
+| Впереди | Остановить обновление; установить происхождение и сохранить локальные коммиты |
+| История разошлась | Остановить обновление; выполнить разбор расхождения |
+| Remote недоступен | Пометить актуальность как неподтверждённую |
+
+Локальные коммиты в `main` нельзя автоматически пушить, сбрасывать или удалять ради синхронизации. Известную полезную работу можно сохранить отдельной веткой и затем предъявить через обычный MR. Приведение локального `main` к общему состоянию выполняют только после сохранения работы и проверки владения.
+
+Для создания новой задачи не требуется обязательно переключать или обновлять локальный `main`: допустимо создать ветку непосредственно от проверенного SHA общего `main`. Аномалия локального `main` всё равно фиксируется и не скрывается.
+
+### 6.3. Рабочая ветка и её опубликованная версия
+
+| Состояние | Действие |
+|---|---|
+| Совпадают | Продолжить после остальных проверок |
+| Локальная впереди | Проверить принадлежность коммитов задаче; опубликовать на обязательной границе |
+| Локальная только отстаёт | Установить происхождение удалённых коммитов; обновить fast-forward, если они ожидаемы |
+| Разошлись | Остановить автоматическое обновление; выяснить причины и владельца |
+| Удалённая ветка отсутствует | Различить новую неопубликованную ветку, закрытую задачу и неожиданное удаление |
+
+Наличие ожидаемых локальных коммитов само по себе не является ошибкой. Неизвестное происхождение локальных или удалённых изменений — основание для разбора.
+
+### 6.4. Обновление из целевой ветки
+
+Изменения цели включаются в опубликованную рабочую ветку через merge. Перед merge собственная работа сохраняется, неизвестные изменения разбираются. После разрешения конфликтов выполняются необходимые проверки.
+
+Ведущий обновляет свою ветку из `main`; субагент — из родительской ветки. Одновременное независимое вливание `main` во все уровни дерева не требуется.
+
+После каждого нового коммита цели немедленное обновление всех веток не требуется. Проверить положение ОБЯЗАТЕЛЬНО при входе, передаче и предъявлении результата. Включить обновления требуется при зависимости от них, конфликте, нарушении совместимости или возврате MR обработчиком. Автоматически совместимый результат может проверить сам обработчик интеграции без изменения исходной ветки.
+
+Rebase допускается только для неопубликованной работы единственного владельца, от которой никто не ответвлялся. Составная команда `pull` не используется как безусловный способ исправить любое состояние: получение сведений и способ изменения истории должны быть явными.
+
+### 6.5. Работа без связи
+
+Допускается продолжать известную локальную задачу от ранее проверенной базы и создавать checkpoint. Фиксируется последнее успешное наблюдение remote. Новая независимая задача от неподтверждённой базы, приёмка в общую ветку, межхостовая передача и выпуск блокируются до восстановления связи. В отчёте нельзя называть такую копию актуальной.
+
+## 7. Создание ветки и worktree
+
+Перед созданием ОБЯЗАТЕЛЬНО определить задачу, владельца, цель MR и точный baseline SHA. Текущий HEAD не выбирается автоматически.
+
+Ветку верхнего уровня создают от проверенного `main`; дочернюю — от сохранённого и идентифицированного коммита родителя. Для передачи на другой хост этот коммит должен быть опубликован и доступен получателю. Изменения родителя, оставшиеся только в файлах, не являются базой дочерней ветки.
+
+Создание включает проверку уникальности имени, отсутствия существующей работы той же задачи, безопасного пути и регистрации worktree. Непустой посторонний каталог не перезаписывается. Для продолжения задачи сначала ищут существующую ветку и worktree, а не создают дубликат.
+
+Подготовка окружения выполняется отдельно: зависимости, локальные настройки и секреты не должны случайно попасть в коммиты. Симлинки и общие каталоги не должны позволять двум worktrees незаметно менять одни и те же исходники или результаты сборки.
+
+## 8. Сохранение и публикация
+
+Checkpoint ОБЯЗАТЕЛЕН:
+
+- на завершённом логическом шаге;
+- перед плановой остановкой и передачей владения;
+- перед операцией, способной затронуть незакоммиченную работу;
+- перед предъявлением результата к приёмке.
+
+Внутри непрерывной работы владельца допускаются известные незакоммиченные изменения. Коммит перед каждым действием или запуском каждого субагента не требуется. В штатной схеме субагент работает в своей ветке и сохраняет её результат сам либо через явно назначенного ответственного.
+
+Промежуточный checkpoint допускается с незавершёнными проверками или падающими тестами, если это явно отражено в сообщении и состоянии задачи. Такой коммит сохраняет работу и не проходит гейт готовности автоматически.
+
+Перед коммитом проверяется diff и выбирается известный набор файлов. Безусловное включение всех файлов из неизвестного состояния ЗАПРЕЩЕНО. Секреты, временные данные и локальные настройки не публикуются.
+
+Публикация ОБЯЗАТЕЛЬНА перед MR, межхостовой передачей и плановой остановкой при доступном remote. Если связи нет, checkpoint остаётся локальным с явным указанием этого ограничения и ответственным за последующую публикацию.
+
+Подтверждение push содержит remote, ветку, SHA и время наблюдения. Успешный локальный commit или намерение выполнить push не подтверждают публикацию. Неожиданный отказ push требует повторного inspect, а не force push.
+
+## 9. Передача задачи
+
+Плановая передача выполняется последовательно:
+
+1. Прежний владелец прекращает новые изменения и останавливает писателей своей ветки.
+2. Сохраняет и публикует результат, фиксирует остаточные локальные данные.
+3. Передаёт сведения из таблицы ниже.
+4. Получатель выполняет входную проверку и подтверждает доступность нужного SHA.
+5. После подтверждения меняется активный владелец; прежний запись не возобновляет.
+
+| Обязательное поле | Содержание |
+|---|---|
+| Задача и владелец | Кто передаёт, кто принимает, что осталось сделать |
+| Репозиторий и ветка | Общий remote, исходная ветка и цель MR |
+| База и результат | Baseline SHA и последний опубликованный SHA |
+| Рабочая копия | Хост, clone/worktree; локальный путь не считается общим адресом |
+| Состояние | Незавершённые операции, остаточные файлы, дочерние задачи |
+| Проверки | Что выполнено, на каком SHA, что не выполнено или падает |
+| Следующий шаг | Конкретное действие продолжения |
+
+При аварийном прерывании новый участник сначала восстанавливает факты. Отсутствие записи handoff не разрешает очистить каталог или объявить неопубликованную работу ненужной. Данные `stash`, reflog и локальные файлы рассматриваются как возможные источники восстановления, а не как подтверждённая передача.
+
+## 10. MR и приёмка дочерних задач
+
+MR ОБЯЗАТЕЛЬНО содержит задачу, исходную и целевую ветки, предъявляемый SHA, описание результата, существенные изменения контрактов, результаты проверок и известные ограничения.
+
+Ведущий принимает дочерние MR последовательно в свою ветку. Для каждого результата проверяется совместимость с текущим состоянием родителя. Если два дочерних результата затрагивают общий контракт, ведущий отвечает за их согласование и совокупную проверку.
+
+Субагент не перенаправляет MR в `main` самостоятельно. Ведущий не подменяет приёмку дочерних результатов простым наличием коммитов.
+
+**Стандартный способ приёмки — merge commit (`--no-ff`)**, как для дочерних MR в родительскую рабочую ветку, так и для MR в `main`. Принятая исходная история коммитов сохраняется в графе Git: итоговый коммит интеграции имеет первым родителем актуальную цель, вторым — точный принятый SHA источника. Fast-forward вместо отдельного коммита интеграции не используется. Обновление рабочей ветки из цели по-прежнему выполняется обычным merge по §6.4.
+
+**Squash не применяется автоматически.** Как исключение он ДОПУСКАЕТСЯ только при явном решении принимающего для небольшой независимой задачи, когда нет активных зависимых веток, сохранена прослеживаемость исходного SHA/MR и проверена возможность безопасной уборки. Исключение не меняет общий алгоритм очереди в §11: если используемый обработчик не умеет строить и проверять squash-кандидата с теми же гарантиями, такой MR интегрируется стандартным merge либо остаётся без интеграции до поддержанного процесса. Запрет переписывания опубликованной истории сохраняется.
+
+После интеграции исходная ветка закрывается для новых задач. Перед удалением проверяются оставшиеся зависимые ветки: их можно закончить, отменить с сохранением работы или перенести на новую подтверждённую базу. После обычного merge связь с уже принятыми исходными коммитами сохраняется и доступна через ancestry. После разрешённого squash эта связь не сохраняется; интеграцию подтверждают отдельно по записи MR и точным SHA.
+
+**Происхождение изменений.** Каждый MR содержит task ID, parent task при наличии, source/target refs, предъявленный source SHA и ссылки на evidence и приёмку. Коммит интеграции должен содержать устойчивые ссылки на задачу и MR (например, `Task:` и `MR:`), а журнал интеграции — source SHA, target SHA до слияния, result SHA и результаты проверок. Это позволяет расследовать изменения по `git log --first-parent`, полному графу и `git blame` без обязательного чтения переписки агентов. Метаданные не заменяют проверок и не должны включать секреты или приватные трассы.
+
+## 11. Очередь интеграции в main
+
+### 11.1. Хранение и запуск
+
+Очередь — открытые MR в `main`, имеющие действующую отметку готовности для конкретного исходного SHA. Очередь не хранится исключительно в ожидающих CI-запусках. Для одного репозитория одновременно работает один обработчик интеграции.
+
+Обработчик запускается при появлении готового MR, после завершения обработки кандидата, при значимом изменении состояния очереди и вручную. Периодический запуск раз в `reconcile_interval_minutes` восстанавливает работу после пропущенного события или сбоя.
+
+Повторные события не отменяют активную интеграцию. Порядок готовых независимых MR — по времени получения действующей готовности, при равенстве по устойчивому идентификатору MR. Возвращённый и исправленный MR получает новое место. Зависимость должна быть выполнена до готовности; срочность допускает явно зафиксированный приоритет без пропуска проверок.
+
+### 11.2. Алгоритм
+
+1. Выбрать следующий готовый MR; проверить его актуальность, целевую ветку и приёмку.
+2. Зафиксировать исходный SHA `S` и текущий SHA `main` — `T`.
+3. Построить во временном изолированном каталоге **merge-коммит-кандидат `C`** из точных `T` и `S`, с двумя родителями в порядке `T`, `S` (эквивалент `--no-ff`, даже если допустим fast-forward). При конфликте не создавать готового кандидата: вернуть задачу владельцу. Проверить дерево результата, родителей и ссылки на задачу/MR.
+4. Выполнить обязательные проверки именно для `C` по утверждённой политике CI; проверки только исходного `S` недостаточны.
+5. Перед публикацией повторно проверить: MR открыт и готов, исходный SHA всё ещё `S`, приёмка действительна, `main` всё ещё `T`.
+6. При выполнении условий опубликовать именно проверенный `C` как новый `main`, с серверной проверкой ожидаемого предыдущего состояния.
+7. Зафиксировать соответствие MR, `S`, `T`, `C` и результатов проверок; завершить MR средствами выбранной платформы.
+8. Перейти к следующему MR уже относительно обновлённого `main`.
+
+Если `main` или исходный SHA изменился, старый результат не публикуется. Кандидат строится заново; изменение исходной ветки также снимает готовность и требует новой приёмки. Успех CI для прежней пары SHA не переносится автоматически на новую.
+
+Адаптер Git-хостинга ОБЯЗАТЕЛЬНО обеспечивает условное обновление цели и запрещает незаметную подмену проверенного кандидата. Обычный force push для этого не используется. Если платформа самостоятельно формирует merge-коммит, реализация должна доказать совпадение точного публикуемого коммита с проверенным `C` (включая родителей и дерево) либо построить и проверить фактически публикуемый кандидат заранее. Простая проверка исходной ветки или сходства diff недостаточна. Если хостинг не даёт такой гарантии, автоматическая публикация через этот адаптер запрещена до выбора поддержанного способа интеграции.
+
+### 11.3. Ошибки и ожидание
+
+| Ситуация | Реакция |
+|---|---|
+| Конфликт | Снять готовность, сообщить владельцу, сразу перейти к следующему MR |
+| Ошибка обязательной проверки | То же; повторять неизменный код без причины не нужно |
+| Сбой инфраструктуры | Одна повторная попытка по умолчанию; затем снять готовность и сообщить причину |
+| Тайм-аут проверки | Завершить попытку как неуспешную, освободить очередь; исходный код не удалять |
+| Изменилась цель | Перестроить кандидата относительно нового SHA |
+| Перезапуск обработчика | Прочитать MR и фактический `main`; продолжить без повторного применения принятого результата |
+
+Очередь **не ждёт исправления конфликтного MR**. Владелец может исправлять его сколько требуется; после новой приёмки MR возвращается в очередь. Начальный тайм-аут — 20 минут, изменяется параметром проекта. Результат проверки, пришедший после отмены попытки, не разрешает публикацию.
+
+### 11.4. Пример А и Б
+
+А и Б начали от `M0`. Для А построен и проверен кандидат `M1`; он принят. Для Б затем проверяется кандидат от `M1`, уже включающий А. Если он совместим — принимается. При конфликте Б обновляет собственную ветку и предъявляет исправленный результат; следующий независимый MR не ждёт Б.
+
+Очередь устраняет гонку публикации, но не смысловые противоречия. При изменении общих API, схем данных, конфигурации и зависимостей ведущие заранее фиксируют контракт или зависимость задач. Ответственность за адаптацию обычно несёт ещё не принятый результат; нарушение ранее согласованного контракта разбирается по существу, а не по принципу «первый всегда прав».
+
+## 12. Защита main и политика проверок
+
+Общий `main` изменяет только механизм интеграции с ограниченными полномочиями. Прямые push участников, принудительное обновление и удаление ветки блокируются настройками сервера. Исправления, откаты и изменения самого CI проходят через рабочую ветку и MR.
+
+Обязательные проверки определяются проектом: корректность задачи, нужные тесты, статический анализ и другие применимые проверки. Документационные изменения могут иметь более лёгкий набор, если это заранее описано политикой. Пустое «всё проверено» без SHA и результатов не принимается.
+
+CI использует доверенную конфигурацию гейтов. Изменение CI в MR не может само снять собственные обязательные проверки или получить полномочия обновления `main`, создания тегов либо удаления образов. Проверка недоверенного кода и операции с секретами публикации разделяются по полномочиям.
+
+Слияние в `main` **не запускает публикацию контейнерного образа**. Проверки MR могут выполнять необходимую проверку сборки, если это нужно проекту; это не выпуск и не публикация образа в registry.
+
+## 13. Тегирование и выпуск контейнерного образа
+
+### 13.1. Общие правила
+
+Проект поддерживает одну актуальную линию версий. Git-тег имеет вид `vMAJOR.MINOR.PATCH`, тег образа — `MAJOR.MINOR.PATCH`. Компоненты — неотрицательные целые числа без ведущих нулей. Стабильные версии сравниваются численно по major, затем minor, затем patch.
+
+Новая версия ОБЯЗАТЕЛЬНО больше всех ранее выпущенных стабильных версий, включая уже удалённые из registry. Источник истории выпусков — Git-теги и журнал выпуска, а не только оставшиеся образы. Опубликованные номера не используются повторно; теги версии и соответствие версии digest не перезаписываются.
+
+### 13.2. Три отдельных CI-процесса
+
+| Процесс | Запуск | Результат |
+|---|---|---|
+| Интеграция | Готовый MR | Принятый коммит в `main` |
+| Подготовка выпуска | Явная команда уполномоченного участника с версией и SHA | Проверенный и опубликованный Git-тег |
+| Выпуск образа | Событие публикации релизного Git-тега | Проверенный образ версии, `latest`, журнал выпуска и очистка |
+
+Создание тега не выполняется автоматически после каждого MR. Между выпусками в `main` может накопиться несколько принятых задач. Развёртывание — отдельное действие; автоматический CD этим регламентом не вводится.
+
+### 13.3. Подготовка выпуска
+
+1. Изменения версии, changelog и необходимые обновления документации принимаются обычным MR.
+2. Оператор явно выбирает версию и полный SHA принятого коммита. Нельзя подменять его текущим HEAD, если `main` успел уйти вперёд.
+3. CI проверяет нахождение SHA в истории общего `main`, соответствие версии в исходниках, обязательные проверки и отсутствие уже опубликованной версии.
+4. Создаёт и публикует аннотированный Git-тег `vX.Y.Z` на выбранном SHA.
+5. Фиксирует запрос выпуска и запуск следующего процесса.
+
+Адаптер CI должен учитывать платформенные ограничения запуска workflow другим workflow. До ввода процесса ОБЯЗАТЕЛЬНО проверить, что созданный служебной учётной записью тег действительно запускает выпуск, а повтор события не создаёт дубликаты.
+
+### 13.4. Публикация и частичные сбои
+
+Для одного образа подготовка версий и выпуск координируются последовательно: более новая версия не должна завершить публикацию раньше незавершённого предыдущего выпуска и затем получить устаревший `latest`. Зависший выпуск не удерживает очередь интеграции в `main`; он блокирует только последующие выпуски до возобновления либо явного завершения попытки.
+
+CI получает код по тегу, проверяет его SHA, собирает и проверяет образ. Затем публикует версионный тег, подтверждает доступность digest и обновляет `latest` на тот же digest. Только после подтверждения обоих тегов запускается очистка.
+
+| Сбой | Правило |
+|---|---|
+| Сборка до публикации версии | Повторить выпуск того же Git-тега; тег не передвигать |
+| Образ версии опубликован, `latest` не обновлён | Повторить продвижение существующего digest, не пересобирать и не перезаписывать версию |
+| Неизвестно, завершилась ли публикация | Сначала прочитать фактические теги и digest; не выполнять слепую повторную запись |
+| Публикация успешна, очистка упала | Выпуск остаётся успешным, очистка отмечается отдельно как неуспешная и допускает повтор |
+| Ошибка в опубликованном продукте | Исправление через MR и новый номер версии |
+
+Повторная попытка проверяет согласованность Git-тега, версии, SHA и digest. Несовпадение блокирует автоматическое продолжение. Журнал выпуска содержит версию, Git SHA, digest, ссылку на CI, время и статусы публикации/очистки.
+
+## 14. Очистка registry
+
+### 14.1. Политика хранения
+
+Параметр `keep_last` — положительное целое число. Начальный пример — `5`; это настройка проекта, а не неизменное правило.
+
+После успешного выпуска сохраняются:
+
+- `keep_last` наибольших опубликованных стабильных версий `MAJOR.MINOR.PATCH`;
+- образ, на который указывает `latest`.
+
+Если `latest` указывает на одну из сохраняемых версий, дополнительный образ не появляется. Если указывает за пределы списка, он всё равно защищён. Количество относится к версиям, а не слоям, платформенным манифестам или числу записей registry.
+
+Политика не поддерживает отдельные релизные линии и не сортирует образы по датам сборки, изменения тега или выдаче API. Например, `2.22.10` новее `2.22.9`, а `2.10.0` новее `2.9.0`. Используется проверенный числовой parser; лексикографическая сортировка запрещена.
+
+### 14.2. Алгоритм очистки
+
+1. Проверить параметр, конкретный registry и имя репозитория образов.
+2. Получить полный список тегов со всеми страницами; при невозможности подтвердить полноту прекратить удаление.
+3. Выделить строго допустимые стабильные версии. Неканонические и неизвестные теги показать в отчёте, но не удалять этим правилом.
+4. Отсортировать версии численно по убыванию, выбрать `keep_last` и добавить защиту `latest`.
+5. Получить соответствия тегов и digest; построить план удаления старых версий.
+6. Проверить все ссылки на удаляемое содержимое, включая сохраняемые и неизвестные теги и индексы нескольких архитектур.
+7. Повторно проверить план перед изменением; выполнить допустимые удаления и записать фактический результат.
+
+По возможности удаляются только устаревшие теги. Если API удаляет сразу manifest/digest вместе со всеми его тегами, адаптер не должен затрагивать содержимое, используемое сохраняемыми или неизвестными тегами либо сохраняемыми multi-platform индексами. При невозможности доказать безопасность конкретный объект пропускается с причиной; политика количества может временно не выполняться.
+
+Полная поддержка multi-platform графа нужна только при использовании таких образов, но неподдерживаемый формат должен приводить к отказу удаления, а не к предположению о безопасности. Фактическое освобождение слоёв выполняется средствами registry и не гарантируется одним удалением тега.
+
+Очистка выполняется в конце успешного выпуска, без отдельного обязательного расписания. Она не пересекается с публикацией того же образа; все писатели соблюдают общую координацию. Ручной повтор поддерживает тот же регламент. Ошибка конфигурации, списка или проверки не разрешает удаление «по приблизительному списку».
+
+Скрипт предоставляет режимы плана без записи и применения. После первоначального включения автоматическое применение не требует подтверждения каждого удаления, если оно укладывается в утверждённую политику. Отдельные сложные категории хранения не вводятся. Удалённые версии не гарантированы для отката; `keep_last` выбирают с учётом нужного запаса.
+
+## 15. Очистка worktrees, веток и локальных данных
+
+### 15.1. Уборка как часть закрытия
+
+Интеграция не означает завершение уборки. Владелец каждого хоста отвечает за локальные worktrees и clones; центральный CI не объявляет их удалёнными без подтверждения с хоста.
+
+Перед удалением ОБЯЗАТЕЛЬНО:
+
+1. Остановить владельца и все связанные процессы записи.
+2. Подтвердить интеграцию задачи либо её отмену с явным решением о сохранении нужной работы.
+3. Проверить отсутствие незавершённых Git-операций, staged/unstaged/untracked-изменений и дополнительных коммитов после предъявленного SHA.
+4. Проверить ценные ignored-файлы, локальные артефакты и резервные данные: чистый `git status` сам по себе не доказывает, что каталог можно удалить.
+5. Проверить, что ветка не нужна активным потомкам, MR или другому владельцу.
+6. Сохранить необходимые локальные данные и получить свежий результат проверки непосредственно перед удалением.
+
+При стандартном merge ОБЯЗАТЕЛЬНО подтвердить, что предъявленный исходный SHA является предком опубликованного результата интеграции, а интеграционный коммит имеет ожидаемых родителей и связан с записью MR. Эта проверка подтверждает включение коммитов, **но не отсутствие новых локальных изменений, посторонних данных или активных зависимостей**. При разрешённом squash ancestry исходного SHA отсутствует; сохранность доказывают записью интеграции MR с точными source/result SHA и проверкой актуального состояния ветки. Дополнительные коммиты после принятого source SHA разбирают отдельно при любом способе интеграции. Простой статус MR «merged» не разрешает удалить любое текущее содержимое ветки.
+
+### 15.2. Порядок
+
+Сначала очищают worktrees завершённых подзадач, затем их локальные ветки и, если больше не нужны, удалённые ветки. После принятия родительской задачи аналогично убирают её рабочую копию и ветку. Полезный принятый дочерний результат может быть сохранён в опубликованной родительской ветке до её интеграции в `main`.
+
+Worktree удаляют штатными средствами Git, не безусловным удалением каталога. Удалённая ветка удаляется с проверкой ожидаемого SHA: появление нового коммита отменяет старое разрешение на уборку. На каждом шаге результат записывается отдельно, чтобы повтор уборки после сбоя был безопасным.
+
+Автоматические `remove --force`, `reset --hard`, `clean` с удалением неизвестных файлов и принудительное удаление веток ради чистоты ЗАПРЕЩЕНЫ. По умолчанию локальную ветку удаляют штатным `branch -d` после снятия worktree и проверок. Если даже после стандартного merge `branch -d` отказывает из-за выбранной checkout/merge-базы, отказ разбирают, а не обходят автоматически. При разрешённом squash специальное удаление допускается только после доказанной сохранности по записи MR и повторной проверки неизменности SHA; отказ обычного `branch -d` сам по себе не является разрешением на принудительное удаление.
+
+Основной clone и его главный рабочий каталог не удаляются как обычный дочерний worktree. Удаление целого clone — отдельная процедура с проверкой всех веток, worktrees и локальных данных.
+
+### 15.3. Поиск забытых копий
+
+При начале рабочей сессии выполняется локальный осмотр зарегистрированных рабочих копий:
+
+| Найдено | Действие |
+|---|---|
+| Завершённая задача, сохранность подтверждена | Выполнить уборку по гейту |
+| Завершённая задача, осталась работа | Установить владельца и сохранить результат |
+| Активная задача | Оставить |
+| Неизвестная задача или владелец | Поставить на разбор, не удалять |
+| Давно не использовалась | Сообщить владельцу; возраст не даёт права удаления |
+| Следы уже удалённого worktree | Проверить и затем очистить устаревшие служебные записи Git |
+
+Если хост недоступен, задача может иметь статус «интегрирована, уборка ожидается». Уборка других задач и работа очереди продолжаются. Полное закрытие фиксируется после подтверждения по всем зарегистрированным рабочим копиям задачи.
+
+## 16. Сводная таблица гейтов
+
+| Гейт | Условия допуска | Кто проверяет и отвечает | При отказе |
+|---|---|---|---|
+| G0. Вход / возобновление | Известны репозиторий, ветка, владелец, локальные изменения, Git-операции и состояние remote | Владелец через inspect/check | Разбор расхождения; ограниченная офлайн-работа только по §6.5 |
+| G1. Создание ветки | Задача, уникальное имя, разрешённый baseline SHA, цель и безопасный путь | Владелец / ведущий | Не создавать; устранить неопределённость |
+| G2. Остановка / передача | Checkpoint, публикация при доступной связи, прекращение записи, handoff | Прежний владелец; получатель подтверждает вход | Не объявлять передачу завершённой |
+| G3. Готовность MR | Опубликованный SHA, выполнение задачи, проверки и приёмка, завершение обязательных потомков | Принимающий / ведущий | Оставить MR неготовым; вернуть замечания |
+| G4. Приём дочерней задачи | Совместимость с текущим родителем, проверки конкретного кандидата | Ведущий | Вернуть владельцу подзадачи |
+| G5. Интеграция в main | Готовый MR, проверенный кандидат, неизменные source/target SHA, серверные полномочия | Единственный обработчик | Снять готовность или перестроить кандидата; очередь продолжает работу |
+| G6. Тег версии | Явный запрос, принятый SHA, корректная новая версия, проверки и документация | CI подготовки выпуска | Не создавать тег; указать причину |
+| G7. Выпуск образа | Неизменный Git-тег, проверенный образ, доступный версионный digest и `latest` | CI выпуска | Восстановить соответствующий этап без перезаписи версии |
+| G8. Очистка registry | Успешная публикация, полный список, валидный `keep_last`, безопасный план | Скрипт очистки под координацией выпуска | Не удалять непроверенное; отдельно сообщить ошибку уборки |
+| G9. Уборка worktree | Нет писателей и несохранённой работы, подтверждена судьба результата и зависимостей | Локальный владелец через check/remove | Сохранить каталог; зафиксировать причину |
+
+Гейт не пройден, если подтверждение отсутствует или устарело из-за изменения проверяемых SHA. Успех инструмента проверки Git не заменяет приёмку функционального результата.
+
+## 17. Восстановление и отклонения
+
+| Отклонение | Обязательная реакция |
+|---|---|
+| Неизвестные файлы или коммиты | Зафиксировать состояние, не включать в свою работу, выяснить происхождение и сохранить |
+| Локальный main впереди / разошёлся | Сохранить коммиты отдельной ссылкой, определить путь MR; не push/reset автоматически |
+| Два активных владельца | Прекратить конфликтующую запись, сохранить оба результата, восстановить одного владельца |
+| Незавершённый merge/rebase | Установить цель операции; осознанно завершить или отменить с сохранением работы |
+| MR принят, но владелец успел добавить коммиты | Не считать новые коммиты принятыми; оформить отдельную ветку/MR |
+| Регрессия в main | Откат либо исправление новой веткой и MR через ту же очередь; история main сохраняется |
+| Сбой между обновлением main и закрытием MR | Сверить фактический SHA и журнал; завершить учёт, не применять задачу второй раз |
+| Устаревшие сведения о публикации | Получить новое наблюдение; не выдавать старую проверку за текущую |
+
+Участник сообщает: что обнаружено, какие SHA/пути затронуты, что сохранено, какой переход заблокирован и кто должен продолжить. Общее «Git сломан» не считается пригодным handoff.
+
+## 18. Настройки проекта
+
+Ниже — пример будущего контракта конфигурации, а не готовый формат Wolf. Значения, кроме обязательных правил процесса, настраиваются под проект.
+
+```yaml
+git_policy:
+  remote: origin
+  integration_branch: main
+  acceptance_method: merge
+  merge_commit: always # предлагаемое поле политики Wolf: эквивалент --no-ff
+  squash_exception: explicit_only # лишь при условиях §10 и поддержанной проверке кандидата
+  update_method: merge
+  published_history_rewrite: false
+  queue:
+    order: ready_at
+    candidate_timeout_minutes: 20
+    infrastructure_retries: 1
+    reconcile_interval_minutes: 10
+  required_checks: [] # заполнить реальными идентификаторами проверок до включения
+release_policy:
+  git_tag_prefix: v
+  version_format: MAJOR.MINOR.PATCH
+  trigger: explicit_request
+  image_build_trigger: release_tag
+  image_latest_tag: latest
+  keep_last: 5 # положительный параметр, свободно меняется владельцем проекта
+```
+
+Пустой перечень обязательных проверок в примере не означает разрешения интеграции без контроля. При вводе процесса задаются реальные проверки либо явно утверждённая минимальная политика для данного типа репозитория. Также конфигурируются адрес образа, полномочия CI и используемый адаптер хостинга/registry.
+
+## 19. Требования к реализации в Wolf
+
+### 19.1. Разделение ответственности
+
+| Слой | Что реализует |
+|---|---|
+| Политика | Правила этого документа, настройки и полномочия проекта |
+| Переносимые скрипты | Фактический inspect/check, создание, checkpoint, публикация, безопасная уборка |
+| Адаптер Git-хостинга | MR, статусы, готовность, условное обновление цели и защита refs |
+| CI | Последовательная интеграция, подготовка тега, выпуск и очистка |
+| Скиллы | Когда запускать операции, как читать результаты и реагировать на отказ |
+| Агенты / люди | Смысловая приёмка, разрешение конфликтов и выполнение разрешённых действий |
+
+OpenCode и другие харнесы вызывают общий механизм. Инструкции не должны зависеть от специальных worktree-команд одного харнеса. Отдельный постоянный агент-контролёр и распределённая система блокировок для первой реализации не требуются.
+
+### 19.2. Требования к операциям
+
+- Явные repository/worktree, задача, стадия и ожидаемые SHA; запрет опасных неявных значений по текущему каталогу.
+- Один фактический сборщик Git-состояния для всех проверок; отсутствие нескольких расходящихся трактовок.
+- Режим проверки без исправлений; отдельные изменяющие операции.
+- Краткий человекочитаемый итог и структурированный JSON с вердиктом, кодами причин, фактами и допустимым следующим действием.
+- Различение «условия нарушены» и «не удалось проверить»; отсутствие данных не считается успехом.
+- Повторная проверка предусловий непосредственно перед записью, общая локальная координация и серверные проверки ожидаемых refs.
+- Безопасный повтор после частичного сбоя; журнал фактических результатов и отсутствие дубликатов интеграции/выпуска.
+- Проверка собственных полномочий; отсутствие автоматического force, публикации неизвестной истории и удаления ради зелёного статуса.
+
+В состоянии задачи достаточно ссылок и компактных фактов: task/parent, владелец, host/clone/worktree, branch/target, baseline/HEAD, dirty-state, remote observation, MR/source/result SHA, состояние проверок, следующий шаг и состояние уборки. Состояние Wolf не заменяет фактическую проверку Git и remote.
+
+### 19.3. Сценарии приёмки реализации
+
+Реализация считается пригодной после проверки как минимум следующих сценариев:
+
+1. А и Б на разных хостах начинают от одного SHA; оба результата последовательно принимаются с проверкой совместного состояния.
+2. Конфликт Б не задерживает следующий независимый MR.
+3. Изменение source или target после проверки не позволяет опубликовать старого кандидата.
+4. Перезапуск CI после фактического merge не приводит к повторному применению задачи.
+5. Локальные неопубликованные коммиты в main обнаруживаются и сохраняются без автоматического push/reset.
+6. Передача ветки требует остановки прежнего писателя и доступности опубликованного SHA на другом хосте.
+7. После merge проверяется ancestry принятого SHA и запись MR; завершённая ветка без новых данных убирается безопасно, а ветка с дополнительным коммитом сохраняется. При явно разрешённом squash применяется отдельная проверка сохранности по source/result SHA.
+8. Worktree с ценными ignored-файлами не удаляется по одному лишь чистому status.
+9. Между MR и выпуском main уходит вперёд; тег остаётся на явно выбранном релизном SHA.
+10. Повтор выпуска после публикации версии восстанавливает latest без перезаписи образа версии.
+11. Числовая сортировка правильно обрабатывает `2.9.0`, `2.10.0`, `2.22.9`, `2.22.10`; изменение keep_last меняет план.
+12. Неполный список registry, общий digest сохраняемого тега и multi-platform ссылки не приводят к удалению нужного содержимого.
+13. Ошибка очистки не отменяет опубликованный выпуск и допускает безопасный повтор.
+14. Обычный merge в main не публикует контейнерный образ.
+15. Приём дочернего и головного MR через merge сохраняет исходные коммиты; `git log --first-parent` показывает интеграции, а полный граф позволяет связать изменение с исходным SHA и MR.
+16. Для merge-кандидата проверены два родителя (`T`, `S`), дерево и точный SHA `C`; изменение любого из `T`/`S` запрещает публикацию ранее проверенного `C`. Не поддерживающий эту гарантию hosting adapter отказывает безопасно.
+17. Запрос squash без явного исключения или при активной дочерней ветке не интегрируется squash-способом; при разрешённом исключении проверяется безопасная уборка без ancestry.
+
+## 20. Краткая памятка участнику
+
+1. **Вход:** проверь локальную работу, владельца и remote; затем обновляй.
+2. **Новая задача:** отдельная ветка от явного SHA main; подзадача — от SHA родителя.
+3. **Работа:** один писатель, свои файлы, checkpoint на логических границах.
+4. **Передача:** остановись, сохрани, опубликуй, передай SHA и следующий шаг.
+5. **Приёмка:** предъяви опубликованный SHA и проверки; субзадачу принимает родитель.
+6. **Main:** предъяви готовый MR; интеграцию выполняет общая очередь.
+7. **Отказ:** исправь конкретную причину и предъяви новый результат; чужая независимая работа продолжается.
+8. **Выпуск:** явный запрос версии и SHA, Git-тег, сборка и публикация образа, очистка registry.
+9. **Завершение:** подтверди сохранность, убери worktree и ненужные ветки на каждом хосте.
+
+## 21. Технические основания
+
+Выбор очереди, модели веток, полномочий и правил хранения — политика данного регламента. Поведение инструментов проверяется по первичной документации:
+
+- [Git worktree](https://git-scm.com/docs/git-worktree) — устройство связанных рабочих копий, общие refs, удаление и служебная блокировка.
+- [Git push](https://git-scm.com/docs/git-push) — обновление удалённых refs и защита от нежелательных изменений истории.
+- [Git merge](https://git-scm.com/docs/git-merge) — merge-коммиты, `--no-ff`, порядок родителей и отличия от squash.
+- [Git log](https://git-scm.com/docs/git-log) — `--first-parent` и анализ происхождения изменений.
+- [Semantic Versioning 2.0.0](https://semver.org/) — формат стабильной версии, числовой порядок и неизменность опубликованной версии.
+
+Конкретные события CI, условия блокировки и операции удаления registry определяются адаптерами и проверяются при внедрении. Настоящий документ не предполагает, что обычный Git самостоятельно предоставляет MR, очередь, сведения о владельцах или registry API.
+
+
+## 22. История изменений регламента
+
+- **1.1 (1 ноября 2026):** по решению владельца стандартная интеграция дочерних MR и MR в `main` изменена с squash на merge commit (`--no-ff`); уточнены два родителя и проверка точного кандидата, происхождение task/MR, уборка worktrees, конфигурация и сценарии приёмки. Squash оставлен только как явно разрешаемое исключение с отдельной проверкой сохранности. Остальные правила GitFlow не меняются.