# Narabotki Sessii V Vetku > «Сохрани результат Codex-сессии в repo», «куда сессия записала файлы», «перенеси в чистый MR», «архивируй task», «попала ли работа в main». Чистый PR/MR, доказан target. - Skill: `kir-kopylov/narabotki-sessii-v-vetku` (Agent Skill, multi-file: 14 files) - Install (CLI): `npx skillmds@latest add kir-kopylov/narabotki-sessii-v-vetku` - Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/narabotki-sessii-v-vetku/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: kir-kopylov (https://skillmd.com/u/kir-kopylov) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/kir-kopylov/narabotki-sessii-v-vetku --- # Codex Session To Repo Rescue ## Запуск Навыка При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции: Применяю **«Сохранение результата сессии в репозитории»**: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания. Не завершайте ответ одной строкой уведомления. Сразу после неё в том же ответе начните доступный read-only поиск task/session и repo. Если источник нельзя однозначно определить из текущего контекста или инструментов, задайте один ближайший вопрос, который меняет выбор target. Не включайте в строку `author_github`, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык. Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык. Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения. ## Обзор Восстанавливайте не текст разговора, а долговечный результат работы: файлы, commit, branch, worktree, evidence package и их связь с целевым remote. Стройте цепочку: ```text Codex task -> session file -> cwd -> repo/worktree -> commit/files -> remote -> PR/MR -> target branch ``` Начинайте раньше обычного git-workflow: repo, worktree и commit могут быть неизвестны. Когда они доказаны, используйте `sverka-git-pered-deystviem` как нижний read-only gate, а `provedenie-vetki-do-uborki` — для clean branch, PR/MR и cleanup. Если известны repo и SHA/WIP и восстанавливать след Codex-сессии не нужно, сразу передавайте задачу этим git-skills. ## Режим И Полномочия Сначала зафиксируйте режим по формулировке пользователя: - `map-only` — найти и описать сохранённую работу; не менять repo, session state, branches или remotes; - `prepare` — собрать и проверить clean package локально; не push и не открывать PR/MR; - `publish` — commit, push и PR/MR входят в scope, только если пользователь просит добавить результат в repo, опубликовать или довести до PR/MR; - `prove-target` — проверить уже созданный PR/MR или target branch без новой публикации. Архивирование, удаление task/session, удаление checkpoint, branch или worktree не выводите из слова «сохранить». Для этих действий нужно отдельное явное намерение, а удаление checkpoint разрешайте только после доказательства результата в target. ## Процесс ### 1. Прочитать Known Exceptions Перед выполнением прочитайте `known-exceptions.yaml`. Применяйте подходящее `do_next_time` сразу, не повторяя уже известную ошибку. ### 2. Идентифицировать Task Без Загрузки Всего Чата 1. Если доступен Codex thread/task tool, получите по нему `thread_id`, title, archived/pinned state и последние нужные метаданные. 2. До inventory создайте immutable target lock. Если дано только название task, добавьте наблюдаемый размер из UI; resolver использует index и только ранние user messages, а не широкое чтение raw chat: ```bash python3 /scripts/rescue_evidence.py resolve-session \ --title "<точное название>" --expected-size-mib \ --lock-file /target-lock.json ``` `` должен быть приватным локальным каталогом вне любого Git worktree. `target-lock.json` содержит локальную identity и абсолютный session path: никогда не добавляйте его в manifest, commit или publish package. Если native task tool уже вернул точный ID, используйте `--thread-id ` вместо `--title`. Статус `identity_incomplete`, `ambiguous_target` или `target_not_found` — жёсткий стоп; не выбирайте первый или самый похожий candidate. 3. Продолжайте только после JSON-статуса `target_locked`. Inventory принимает lock, а не свободный `thread_id`: ```bash python3 /scripts/rescue_evidence.py inventory-session \ --target-lock /target-lock.json ``` 4. Не заменяйте существующий lock другим target. `target_lock_conflict` означает, что текущий recovery run и все его выводы нужно явно аннулировать; для другого target создайте новый run-dir и новый lock. 5. Считайте подтверждёнными только поля, которые вернули текущие tools или файл: session path, `cwd`, archive state, repo root, worktrees, branch, HEAD и очищенные remotes. 6. Если inventory вернул `records_truncated=true`, `path_hints_truncated=true` или `discovery_status=partial`, не делайте отрицательный вывод «worktree/commit не найден». Повторите с большим `--max-records` или сузьте поиск дополнительным evidence. 7. Не считайте размер session-файла доказательством причины тормозов. Размер здесь только identity gate; performance triage — отдельная задача. Если task tool недоступен, schema JSONL неизвестна или `thread_id` не найден, сообщите точный пробел. Не придумывайте связь с repo по похожему имени папки. ### 3. Построить Recovery Map Для каждого кандидата соберите read-only evidence: - session file и активный/архивный каталог; - `cwd` из session metadata; - repo root и `git worktree list --porcelain`; - branch, upstream, HEAD, staged/unstaged/untracked и stash; - commits, которых нет в предполагаемом target; - changed paths и уже существующие durable artifacts; - remote names и URL без credentials, query tokens и fragments; - открытый PR/MR, если он есть. Сначала ищите уже созданные файлы, commit и worktree. Raw session используйте только как указатель на действия, если durable artifacts не дают ответа. Не пересобирайте результат из длинного чата, пока не доказано, что файлов или commit нет. ### 4. Доказать Настоящий Target Не считайте `origin/main` настоящим target автоматически. Проверьте: - какой repo должен владеть результатом; - fork это или upstream; - remote URL и default branch; - base/target project и branch у PR/MR; - source/head project, branch и commit; - есть ли несколько child repos или worktrees с похожими артефактами. Если остаются несколько равноправных target-кандидатов, завершите read-only карту со статусом `BLOCKED_TARGET_UNKNOWN` и попросите точный repo URL или `owner/name`. Не создавайте branch до выбора target. Не пишите без уточнения «работы нет в main». Пока base/target project и branch не подтверждены provider metadata, допустима только точная формулировка: «результат не найден в проверенном `/`; настоящий target не подтверждён». В режиме `map-only` можно завершить `RECOVERY_MAPPED` с полем `target_status=unconfirmed`; этот статус не разрешает publish или cleanup. Подробные provider checks и manifest contract читайте в `references/domain-playbook.md`. ### 5. Зафиксировать Artifact Allowlist Составьте явный список полезных repo-relative paths и источник каждого пути: working tree, index, commit или approved artifact directory. Никогда не включайте по умолчанию: - Codex session JSONL, state/log SQLite и raw chat exports; - `.codex/**`, `.goal-runtime/**`, hooks, active-goal state и локальные настройки; - `.env*`, credentials, tokens, auth caches и credential-bearing remote URLs; - raw exception logs, temporary files, private screenshots и личные абсолютные пути. Если старая branch смешивает нужную работу с предыдущей историей, не сливайте её целиком. Создайте clean branch от доказанного target tip и перенесите только allowlist через `cherry-pick --no-commit`, точечный restore или копирование выбранных артефактов. Сохраните исходную branch/worktree как checkpoint. ### 6. Проверить Пакет До Commit Минимальные проверки: ```bash git diff --cached --check git diff --cached --name-status git diff --cached --stat ``` Дополнительно: - сверить changed paths с allowlist и denylist; - прогнать secret scan и repo tests; - распарсить JSON, JSONL, YAML и другие структурированные файлы; - проверить отсутствие conflict markers и случайных служебных файлов; - если есть approved manifest — проверить `path`, `sha256` и `size` по нужным byte sources. До commit проверяйте working tree и index: ```bash python3 /scripts/rescue_evidence.py verify-manifest \ --repo --manifest --sources working,index ``` После commit проверяйте commit и независимый fresh checkout: ```bash python3 /scripts/rescue_evidence.py verify-manifest \ --repo --manifest --sources commit,checkout --commit HEAD ``` Без `--exact-scope` команда проверяет только перечисленные manifest entries и возвращает `package_ready=false`: это допустимо для approved evidence subset, но не доказывает отсутствие лишних paths. Если manifest описывает полный artifact allowlist, до commit добавьте `--exact-scope index --base ` вместе с byte source `index`, а после commit — `--exact-scope commit --base ` вместе с source `commit`. Script сначала разрешает недоверенные revisions в commit OID, читает Git paths через NUL и запрещает зелёный scope при unmerged (`U`) или type-change (`T`) paths. Только `status=ok`, `hash_status=ok`, `scope.status=ok` и `package_ready=true` разрешают считать manifest-пакет полностью проверенным. Если Windows working copy отличается от Git blob из-за EOL, не переписывайте approved evidence. Сначала докажите источник расхождения. При необходимости добавьте узкую `.gitattributes` policy, затем повторите проверку index, commit и fresh checkout. ### 7. Publish И Provider Reality Check В режиме `publish`: 1. Создайте осмысленный commit только из allowlist. 2. Push выполните в feature branch, не в target branch. 3. Откройте PR/MR по языковой и governance policy целевого repo. 4. Сверьте changed files PR/MR с локальным allowlist. 5. Проверьте CI/checks, head/source commit и фактический target project/branch. 6. Не приписывайте себе merge, auto-merge или удаление source branch, если это наблюдаемое действие Git provider. Если provider автоматически merged PR/MR, зафиксируйте это отдельно как внешний факт и продолжите с проверкой target. Если source branch уже автоматически удалена, не считайте ошибку повторного delete провалом cleanup. ### 8. Доказать Результат В Target После merge или заявления «уже в main» обновите refs и проверьте минимум два независимых признака: - target branch указывает на provider-confirmed target SHA; - package commit reachable из target, либо squash/merge commit доказан provider metadata; - diff выбранных paths между package commit и target равен нулю; - manifest/hash/size воспроизводятся из target commit и fresh checkout; - PR/MR head/source ref соответствует проверенному package commit. Статус `TARGET_PROVEN` допустим только после этой проверки. Green CI, HTTP `200`, существующая remote branch или закрытый PR/MR сами по себе недостаточны. ### 9. Cleanup И Передача Ответственности До `TARGET_PROVEN` сохраняйте: - исходную архивную task/session; - старую checkpoint branch/worktree; - clean publish commit и manifest. После `TARGET_PROVEN` удаляйте только новые временные worktrees/branches, если это входит в scope. Старый checkpoint не удаляйте автоматически: назовите его состояние и предложите отдельное решение. В финале явно укажите: - что уже сохранено и где; - что доказано в target; - что осталось резервом; - что не публиковалось; - какие CI/merge/cleanup действия выполнил provider; - что остаётся за Codex и требуется ли действие пользователя. ## Статусы Завершения - `RECOVERY_MAPPED` — цепочка до файлов/commit построена, mutations не выполнялись; отдельно указать `target_status=confirmed|unconfirmed`; - `READY_TO_PUBLISH` — clean package локально проверен, но publish не входит в scope; - `PUBLISHED_AWAITING_TARGET_PROOF` — PR/MR открыт или merged-state ещё не подтверждён; - `TARGET_PROVEN` — результат доказан в настоящем target; - `BLOCKED_TARGET_UNKNOWN` — несколько target-кандидатов, нужен точный repo; - `BLOCKED_UNSAFE_SCOPE` — allowlist нельзя отделить от raw/private/local state без решения пользователя. ## Границы Не используйте skill: - для известного repo и известного WIP/SHA без session-forensics — используйте `provedenie-vetki-do-uborki`; - для простого вопроса «что в worktree?» — используйте `sverka-git-pered-deystviem`; - для создания skill из разговора — используйте `kontrakt-navyka-do-sborki`, затем `dobavlenie-navyka-v-biblioteku`; - для диагностики тормозов Codex Desktop без задачи сохранить repo-результат; - для восстановления удалённого текста чата как архива переписки; - для force-push, history rewrite, destructive cleanup или удаления session/checkpoint без отдельного явного решения. ## Опрос После Использования Опрос задаётся один раз — после `TARGET_PROVEN`, сдачи read-only recovery map или явного стопа, не посреди recovery/publish цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте. ```text Опрос по skill: 1. Что в этом использовании narabotki-sessii-v-vetku было полезно? 2. Что стоит доработать в skill или его формате? Можно ответить коротко или написать "пропустить". ``` Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/narabotki-sessii-v-vetku/usage-feedback.jsonl` — лучше через bundled script: ```bash python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..." ``` Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет в JSONL `redaction_applied` и `redaction_types`. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить. ## Логирование Сбоев Перед выполнением прочитайте локальный `known-exceptions.yaml` как список уже известных случаев и применяйте подходящее `do_next_time` без нового поиска. Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в `~/.codex/skill-runs/narabotki-sessii-v-vetku/exception-log.jsonl`. Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите `unknown`. Raw logs не коммитить.