Provedenie Vetki Do Uborki

Git PR Lifecycle Safeguard

Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю «Безопасное проведение изменений через Pull Request»: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.

Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

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

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

Обзор

Skill защищает цикл WIP/old commit -> clean PR -> merge -> branch cleanup. Он нужен не для любого git-вопроса, а когда есть риск смешать состояния: dirty tree, старый локальный commit, неправильная feature branch, stale remote branch, PR после merge, branch cleanup или remote branch clutter.

Главный принцип: сначала доказать реальное состояние через read-only проверку, затем менять repo только по явному и проверенному scope.

Естественные Входы

Запускайте skill на фразы:

• «вынеси это в отдельную ветку»;
• «сохрани старый commit»;
• «сделай PR, но не смешивай»;
• «этот WIP не должен попасть в текущую ветку»;
• «PR смержен, что теперь?»;
• «убери branch clutter»;
• «можно архивировать после PR?»;
• «почисти remote branches»;
• «доведи локальную работу до clean PR»;
• «пока шли тесты, main продвинулся; перед commit ещё раз сверь базу и не потеряй WIP»;
• «после merge верни repo в чистое состояние».

Общий Первый Шаг

Перед любым изменяющим действием выполните read-only reality check. Если доступен sverka-git-pered-deystviem, используйте его правила как нижний gate.

Минимальный снимок:

git -C <repo> status --short --branch --untracked-files=all
git -C <repo> diff --stat
git -C <repo> diff --cached --stat
git -C <repo> stash list --max-count=5
git -C <repo> branch -vv

Если работа касается push, PR, merge или remote cleanup, после локального снимка обновите refs и проверьте PR state:

git -C <repo> fetch --all --prune
git -C <repo> branch -r --merged origin/main
git -C <repo> branch -r --no-merged origin/main

Не называйте repo «чистым», если чистое только рабочее дерево, но активная ветка не та, upstream [gone], есть локальный commit без PR или осталась remote branch с diff относительно origin/main.

Явная Граница Одобрения Перед Публикацией

Обычный цикл ниже не добавляет отдельный вопрос об одобрении. Но если пользователь явно потребовал сначала показать кандидата, действуйте так:

1. После окончательного staging успешно обновите remote refs и зафиксируйте:

   • выбранный до одобрения режим границы. По умолчанию strict-base: любой сдвиг base запрещает сам push. Режим target-only допустим, только если пользователь до одобрения явно согласился, что push защищается по target/destination, а base ограничивает только PR diff. Менять режим после одобрения нельзя;
   • имя remote, полные имена base/target refs и один фактический destination. Без сырого вывода в tool log получите списки из git remote get-url --all "<remote>" и git remote get-url --push --all "<remote>". Для этой границы оба списка должны содержать ровно один и тот же URL, а к этой URL не должна применяться ни одна url.*.insteadOf или url.*.pushInsteadOf. Иначе не публикуйте: имя origin или уже раскрытая URL не исключают повторную подстановку адреса;
   • полные строки <base-full-ref> и <target-full-ref> должны различаться. Их равенство запрещает одобрение, commit, push и работу с PR: точный lease защищает значение указанного ref, но не доказывает, что target не является самой base-веткой;
   • destination должен быть без встроенного пароля или token, секретного query/fragment и приватного локального пути, чтобы его можно было безопасно показать пользователю и передать git ls-remote и git push. Иначе остановитесь до push и настройте credential-free destination;
   • OID staged tree из git write-tree;
   • OID base и target либо подтверждённое отсутствие target читайте напрямую с этого destination через git ls-remote --heads "<destination>" "<base-full-ref>" "<target-full-ref>";
   • при существующем target OID HEAD должен точно совпадать с OID target; при отсутствии target OID HEAD должен точно совпадать с OID base. Иначе сначала пересоберите кандидата от точного удалённого состояния;
   • если существует MERGE_HEAD, он должен содержать ровно один OID, совпадающий с OID base. Дополнительные merge parents требуют пересборки;
   • OID текущего HEAD как первого будущего parent и, если существует MERGE_HEAD, все OID из него как остальных будущих parents;
   • ожидаемый merge-base base и будущего commit: для обычного commit это merge-base между base и HEAD, для merge с base среди MERGE_HEAD — OID base. Merge без base среди будущих parents этим правилом не публикуйте.
   • точный снимок будущих метаданных commit: сообщение побайтово, включая trailers, строки author и committer с name, email, date и timezone, режим подписи и полный ожидаемый набор headers с их значениями. Не подменяйте этот снимок текущими значениями Git config. Если значение подписи или другого header нельзя зафиксировать до одобрения, этот commit требует отдельного показа и нового одобрения после создания, но до push. Покажите пользователю все зафиксированные выше поля снимка, включая режим границы, remote, полные base/target refs и их OID, destination, staged tree, HEAD, будущих parents, merge-base и метаданные commit, а также полный кандидат PR через git diff --cached <expected-merge-base-oid> --; при существующем target также покажите изменение относительно него через git diff --cached <target-oid> --. Итоговый tree diff не доказывает отсутствие промежуточной неопубликованной истории и не заменяет точное совпадение HEAD с target или base. После полного показа считайте этот снимок единственным текущим кандидатом одобрения. Новый полный снимок сразу аннулирует прежний кандидат и его одобрение.

2. Получите явное одобрение этого снимка. Пользователь не обязан повторять все SHA, refs, destination и метаданные: фраза одобряю последний показанный снимок достаточна, только если существует ровно один текущий кандидат и после его показа не менялось ни одно поле. Такое одобрение относится ко всему снимку, а не только к staged tree. Ответ да, один OID staged tree, сокращённый SHA или ссылка на прежний снимок недостаточны. Непосредственно перед commit снова обновите remote refs и сравните все зафиксированные значения, включая полный список будущих parents, метаданные commit, режим границы, destination и отсутствие URL-подстановок, с одобренными. Ошибка обновления или любое изменение запрещает commit, push, создание и обновление PR до нового показа и одобрения. Только после успешного сравнения создайте commit из одобренных значений: явно передайте точные bytes сообщения, author/committer identities, timestamps/timezones, режим подписи и ожидаемые headers; не оставляйте их Git config или текущему времени.

3. Tree нового commit должен совпасть с одобренным tree, упорядоченный список его parents — с одобренным списком, а merge-base base и commit — с ожидаемым merge-base. До push, не выводя неожиданные raw metadata в tool log, прочитайте полное содержимое объекта через git cat-file commit "<verified-commit-oid>" и побайтово сравните его headers и сообщение с одобренным снимком. Любой дополнительный header или изменение author, committer, trailers, подписи либо сообщения, в том числе внесённое hook-ом, делает commit новым кандидатом: не публикуйте его до нового показа и одобрения. Перед push снова сравните destination и отсутствие URL-подстановок, перечитайте с него base/target и повторите проверки commit. Push выполняйте в явно зафиксированный destination и только с явным refspec <verified-commit-oid>:refs/heads/<target>. Сам push должен включать точное серверное условие target:

   # target существовал при одобрении
   git push "--force-with-lease=refs/heads/<target>:<approved-target-oid>" \
     "<approved-push-destination>" \
     "<verified-commit-oid>:refs/heads/<target>"
   
   # target отсутствовал при одобрении; пустой expect требует его отсутствия
   git push "--force-with-lease=refs/heads/<target>:" \
     "<approved-push-destination>" \
     "<verified-commit-oid>:refs/heads/<target>"
   

   Точный lease — только server-side CAS для обновляемого target ref; при совпадении expect он сам по себе может разрешить non-fast-forward. Поэтому прежние gates обязаны отдельно доказать нужную ancestry и fast-forward от одобренного target.

   Обычный git push не умеет атомарно сделать update target зависимым от неизменности base, который не обновляется. Повторный fetch или no-op refspec для base не создают server-side cross-ref CAS. Если одобрение запрещает любую публикацию при сдвиге base, остановитесь до push, пока не доказан такой серверный guard. Только в заранее одобренном режиме target-only сдвиг base после target push запрещает работу с PR и требует нового diff и одобрения, но не выдавайте это за server-side запрет самого push.

4. После push, но до работы с PR, прямым git ls-remote с одобренного destination снова прочитайте base/target: OID base должен остаться одобренным, а OID target — указывать ровно на этот commit. Создайте или обновите PR только для этих веток и прочитайте его обратно: имена head/base PR должны совпасть с ожидаемыми ветками, а OID head PR должен совпасть с проверенным OID target. OID base PR не заменяет повторную проверку живого OID удалённой base. Иначе снова покажите кандидата и получите новое одобрение.

Режим 1: local-wip-to-clean-pr

Используйте, когда локальный WIP или старый commit нужно вынести в отдельный PR без смешения с текущей веткой.

Процесс:

1. Зафиксируйте исходный scope:
   • текущая ветка и upstream;
   • staged, unstaged, untracked;
   • нужные файлы или commit SHA;
   • есть ли чужие изменения в рабочем дереве.
   • если в одном intended-файле смешаны нужные и чужие hunks и их нельзя безопасно разделить, остановитесь до staging, stash и rebase и запросите один выбор точного состава патча.
2. Если есть WIP в текущем дереве, сохраните его безопасно:
   • общий git stash push --include-untracked -m "<описание>" допустим, только если весь status, включая untracked, доказанно относится к задаче; создание новой записи и глобальную чистоту после неё докажите по references/late-base-gate.md;
   • явный git add <paths> только после проверки scope, если пользователь подтвердил файлы;
   • не используйте общий stash или git add . при mixed worktree.
3. Создайте clean branch от актуального origin/main:
   • git switch -c codex/<short-name> origin/main;
   • для старого commit используйте git cherry-pick <sha>.
4. Разрешайте конфликты без потери текущих строк:
   • для catalog.md сохраняйте уже существующие skill rows и добавляйте новую строку рядом;
   • для registry/docs не откатывайте изменения, пришедшие в origin/main;
   • после ручного разрешения проверяйте отсутствие стандартных conflict-marker строк.
5. Доведите пакет до текущего repo contract:
   • known-exceptions.yaml;
   • секция ## Логирование Сбоев;
   • examples и catalog row для team-ready;
   • отсутствие шаблонных заглушек.
6. Привяжите проверки к точному состоянию:
   • обновите refs и сохраните tested_base_sha;
   • разделите clean committed-only состояние и WIP; для WIP проверьте весь status, включая untracked, stage только доказанный intended scope и сохраните tested_tree=$(git -C <repo> write-tree);
   • не продолжайте автоматически при mixed WIP;
   • выполните git diff --check, git diff --cached --check, полную suite и нужные живые пробы.
7. После тестов выполните поздний гейт базы до любого commit:
   • после каждого первоначального или повторного test run заново обновите refs, сравните current_base_sha с tested_base_sha и докажите через merge-base --is-ancestor, что база входит в HEAD;
   • только после успешных compare и ancestry, до commit, сохраните verified_base_sha; новый drift возвращает процесс к этому же gate;
   • при drift commit запрещён: clean committed-only переносите без stash, а WIP — только по fail-closed процедуре references/late-base-gate.md;
   • после переноса заново получите tested_tree, повторите полную suite, base-sensitive checks и затронутые живые пробы; для изменения Codex plugin явно пересчитайте semver относительно нового origin/main, сохранив выбранный до drift тип повышения (patch, minor или major); если тип не доказан, остановитесь для одного выбора до повторных тестов.
8. Сформируйте commit и свяжите его с тестами:
   • непосредственно до commit повторно сравните index с tested_tree, докажите отсутствие tracked изменений вне index, untracked и unmerged;
   • после commit сохраните verified_head_sha и докажите, что его tree в точности равен tested_tree, а staged, unstaged и untracked отсутствуют;
   • после доказанного commit удалите только созданный процессом recovery-stash: заново найдите его текущий selector по сохранённым object SHA и subject, непосредственно перед stash drop ещё раз сверьте SHA и не выполняйте cleanup без исключительного контроля над stash reflog; если точная идентичность или такой контроль не доказаны, сохраните stash и сообщите его SHA и команду восстановления. Исходные stashes не меняйте.
9. Непосредственно перед push выполните короткий гейт ещё раз:
   • после fetch база должна равняться verified_base_sha и входить в HEAD;
   • текущие HEAD и tree должны равняться verified_head_sha и tested_tree, а полный status — оставаться пустым;
   • любой drift возвращает процесс к переносу и повторным проверкам.
10. Push:

• новую ветку публикуйте обычным git push -u origin <branch>;
• перед переписыванием опубликованной ветки сохраните её remote SHA, а после rebase/amend используйте только явный lease --force-with-lease=refs/heads/<branch>:<expected_remote_sha> по правилам references/late-base-gate.md. Если действует явная граница одобрения, вместо этой сокращённой команды используйте явные destination, refspec и exact lease из раздела выше.

11. После push, но до PR, снова получите origin/main и точный remote head:

• base drift возвращает процесс к rebase и повторным тестам;
• remote head, не равный verified_head_sha, останавливает процесс;
• оставшийся из-за заблокированного cleanup recovery-stash сохраняйте по object SHA и явно называйте способ восстановления.

12. Откройте PR - это стандартное завершение цикла local-wip-to-clean-pr, а не шаг, ожидающий отдельного запроса на публикацию:

• title и body должны описывать scope, происхождение WIP и проверки;
• затем проверьте mergeable, changed files и checks.

13. После открытия или обновления PR проверьте автоматическое review от chatgpt-codex-connector: если согласны с замечанием - почините и запушьте фикс; если не согласны или видите иначе - ответьте на комментарий с обоснованием на русском. Не оставляйте замечание бота без ответа ни в одну, ни в другую сторону. Это про обработку уже пришедшего отзыва, а не про подмену собственного review содержимого PR.

Если title или body изменены после выполнения PR-governance job, старый зелёный job не подтверждает новые метаданные. Снова проверьте текущий текст локальным governance script, если он есть в repo. Для утверждения именно о CI нужен новый pull_request event с уже исправленными метаданными: простой rerun старого job может использовать прежний event payload. Не создавайте бессодержательный commit только ради нового события — разделяйте локальную проверку текущего текста и устаревший CI-сигнал до следующего содержательного push или иного штатного нового события.

Режим 2: post-merge-branch-housekeeping

Используйте после merge или когда пользователь хочет убрать branch clutter.

Процесс:

1. Обновите refs:
   • git fetch --all --prune.
2. Проверьте, что PR действительно merged, а не только green:
   • PR state;
   • mergedAt или merge commit;
   • commit reachable из origin/main.
3. Верните локальный repo в ожидаемое состояние:
   • если worktree clean, переключитесь на main;
   • fast-forward local main до origin/main;
   • не продолжайте новую работу из старой feature branch.
4. Удалите локальные branches только если они merged в origin/main.
5. Для remote cleanup:
   • перечислите git branch -r --merged origin/main;
   • сверяйте с PR state, если branch name неочевиден;
   • удаляйте remote branch только если она доказанно merged или явно признана stale/discarded пользователем.
6. Unmerged remote branches не удаляйте автоматически:
   • покажите commit, diff, возраст, PR state;
   • классифицируйте keep, delete after confirmation, rebuild as new PR.
7. В конце покажите:
   • текущую ветку;
   • clean worktree;
   • локальные branches;
   • remote branches, которые остались, и почему.

Правила Безопасности

Нельзя:

• использовать git add . при mixed worktree;
• создавать общий stash при недоказанном mixed WIP;
• продолжать commit или push после drift origin/main по результатам старых тестов;
• удалять recovery-stash по текущей позиции вместо записанного object SHA;
• удалять ветку, если commit не reachable из origin/main или merged PR;
• force-push без явного ожидаемого remote SHA в --force-with-lease;
• выполнять git reset --hard;
• считать git branch -r достаточным доказательством для удаления remote branch;
• продолжать новую работу из старой feature branch после merge;
• считать skipped publish job проблемой без проверки условия workflow;
• считать 200, green check или merged PR доказательством локальной установки.

Границы

Не используйте skill:

• для учебного вопроса без намерения менять repo;
• для CI-debug как отдельной задачи, если проблема уже локализована в логах GitHub Actions;
• для публикации PR, если пользователь просил только анализ или план;
• для destructive cleanup вне подтверждённого repo;
• чтобы заменить review содержимого PR.

Если есть несколько repo-кандидатов или пользователь не указал target repo, остановитесь после read-only поиска и попросите выбрать один repo.

Опрос После Использования

Опрос задаётся один раз — после завершения цикла (PR влит и cleanup сделан) или явного стопа, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по skill:
1. Что в этом использовании provedenie-vetki-do-uborki было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/provedenie-vetki-do-uborki/usage-feedback.jsonl — лучше через bundled script:

python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

Логирование Сбоев

Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/<skill-name>/exception-log.jsonl.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.

Критерий Готовности

Работа завершена, когда:

• рабочее дерево clean или явно назван оставшийся intentional WIP;
• текущая ветка соответствует этапу: clean PR branch до merge, main после cleanup;
• PR создан или cleanup завершён;
• проверки названы явно;
• поздний гейт после тестов и короткий гейт перед push прошли на одном verified_base_sha, а опубликованный verified_head_sha содержит ровно проверенный tested_tree;
• созданный процессом recovery-stash удалён по object SHA либо сохранён с точной командой восстановления; исходные stashes не изменены;
• merged local branches удалены;
• remote branches удалены только если merged/closed и safe;
• оставшиеся unmerged branches перечислены с причиной keep/delete-later;
• пользователь понимает, что не было изменено и почему.