Shag Posle Prervannoy Tseli

Возобновление Прерванного /goal

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

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

Применяю экспериментальный навык «Восстановление прерванной цели» (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.

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

Не завершайте первый ответ уведомлением или обещанием будущей проверки. До ответа сразу выполните доступный read-only поиск текущей /goal, управляющих файлов и Git-состояния и верните наблюдаемый вердикт с одним следующим шагом. Если одну целевую задачу нельзя определить из текущего контекста или инструментов, верните AMBIGUOUS_TARGET и один ближайший вопрос, который различит кандидатов.

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

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

Обзор

Выполните один проход только для чтения. Результат — не пересказ чата и не продолжение цели, а проверенное состояние, видимые противоречия, список действий, которые нельзя повторять, и ровно один следующий шаг.

Не создавайте новый runtime, parser, журнал или собственную схему состояния. Не исправляйте найденные расхождения. Память чата используйте только как указатель, а не как доказательство.

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

Используйте skill, когда пользователь пишет примерно так:

• «продолжи прерванный /goal»;
• «после падения Codex проверь, что уже сделано»;
• «можно ли безопасно продолжить эту цель»;
• «восстанови состояние по репозиторию и назови следующий шаг»;
• «не читай весь чат, восстановись по файлам»;
• «проверь, не были ли commit, push или PR уже сделаны».

Источники И Их Полномочия

Каждый источник доказывает только свой слой:

1. Все применимые AGENTS.md от корня репозитория до каждого целевого артефакта и названные в них route, contract, registry или state-файлы задают правила и ожидаемый маршрут проекта. Более глубокая инструкция уточняет правила только в своей области; она не отменяет применимые родительские инструкции молча.
2. Если установлен goalrt, его документированный read-only status и журнал являются источником состояния runtime. Не разбирайте неизвестную схему самостоятельно.
3. Git доказывает корень репозитория, HEAD, ветку, upstream, состояние working tree/index и существование commit.
4. Текущий provider state доказывает push, PR/MR, review, merge и другое состояние внешней системы только в момент проверки.
5. Постоянные документы и артефакты доказывают своё содержимое и сохранённое состояние, но не публикацию или запуск.
6. Чат, summary, имя файла и timestamp являются только указателями до повторного открытия авторитетного источника.

Перед повтором commit, push, PR/MR, сообщения, запроса или другого внешнего действия сначала проверьте его текущее состояние в соответствующем источнике. Не повторяйте действие по памяти чата.

Подробная модель источников и состояний находится в references/state-model.md. Читайте её только когда источники расходятся либо непонятно, какой из них вправе подтверждать конкретное утверждение.

Ограниченное Чтение Журнала

При обычном возобновлении:

1. найдите валидную контрольную точку;
2. проверьте её курсор или идентификатор последнего применённого события и проверочный отпечаток;
3. восстановите записанное состояние;
4. прочитайте только события после курсора до конца журнала;
5. сопоставьте полученное состояние с текущими источниками.

Не читайте весь append-only журнал при каждом цикле. Полное воспроизведение допустимо только при отсутствии контрольной точки, её повреждении или несовпадении отпечатка, а также по явному запросу на аудит или восстановление. Причину полного чтения укажите в результате до начала такого чтения.

Процесс

1. Прочитайте known-exceptions.yaml.
2. Определите одну целевую задачу, один /goal и один репозиторий. Если кандидатов несколько или исходная задача известна только по архивной session, не угадывайте: выберите AMBIGUOUS_TARGET и передайте следующий шаг narabotki-sessii-v-vetku в режиме read-only map.
3. Для каждого целевого артефакта соберите все AGENTS.md, чья область включает этот путь, и прочитайте цепочку от корня репозитория к самому глубокому каталогу. Затем прочитайте прямо названные ими управляющие файлы. Если две применимые инструкции расходятся и правило приоритета не снимает конфликт, выберите RECONCILE_REQUIRED. Не считайте открытый пункт уже принятым.
4. Снимите состояние Git только для чтения: repo root, HEAD, branch, upstream, working tree/index, relevant commits.
5. Если утверждение касается внешнего действия, проверьте текущий provider state. Локальная ветка не доказывает push; текст про PR не доказывает существующий PR.
6. Если есть журнал, восстановите состояние по контрольной точке и хвосту. Если журналом владеет goalrt, используйте только его документированный read-only путь.
7. Разведите четыре независимых состояния: контракт утверждён, артефакты опубликованы, исполнение запущено, результат принят. Одно не доказывает другое.
8. Сопоставьте источники. Отсутствующее пишите как неизвестно; противоречие не исправляйте догадкой.
9. Выберите один вердикт, укажите уже выполненное, что нельзя повторять, и ровно один следующий шаг. Сам шаг не выполняйте.
10. Остановитесь и запустите обязательный опрос после использования.

Вердикты

• RESUME_SAFE: цель, репозиторий и состояние однозначны; источники согласованы; первое незавершённое действие доказуемо.
• RECONCILE_REQUIRED: два авторитетных источника противоречат друг другу, поэтому продолжение может закрепить неверное состояние.
• NO_ACTIVE_GOAL: управляющие источники и runtime не подтверждают активную цель; новый запуск является отдельным решением.
• AMBIGUOUS_TARGET: нельзя доказать одну задачу, один /goal или один репозиторий; следующий шаг — восстановить карту происхождения через narabotki-sessii-v-vetku без изменений.
• INSUFFICIENT_EVIDENCE: цель определена, но не хватает конкретного текущего доказательства публикации, запуска, результата или последнего действия.

Не повышайте вердикт по косвенному признаку. Если route говорит «первый цикл не запущен», а state говорит ACTIVE_REVIEW_PENDING, выбирайте RECONCILE_REQUIRED и не запускайте новый цикл.

Формат Результата

Статус: <один вердикт>
Подтверждено:
- <факт — точный наблюдаемый источник>
Противоречия:
- <нет или точные конфликтующие утверждения>
Не повторять:
- <уже выполненное либо действие без текущей проверки>
Следующий шаг: <ровно одно действие и его владелец>
Как проверить: <один ожидаемый наблюдаемый результат>
Изменения: нет

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

Границы

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

• формирования или изменения /goal-контракта — это делает kontrakt-tseli-do-starta;
• поиска неизвестной session, cwd, worktree, commit или настоящего target по сырым архивам — это делает narabotki-sessii-v-vetku в режиме read-only map;
• простой проверки Git без прерванной цели — используйте sverka-git-pered-deystviem;
• выполнения следующего шага или доменного исследования;
• изменения файлов, index, refs, stash, веток, remote-tracking refs, provider state или управляющих документов;
• commit, push, PR/MR, сообщений, удаления, очистки, запуска или восстановления runtime;
• вызова goalrt run start, goalrt run recover или самостоятельного изменения его journal/state;
• полного чтения raw session или всего журнала без одной из явно разрешённых причин.

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

Завершение

Работа завершена, когда каждый сообщённый факт связан с текущим наблюдаемым источником, четыре состояния жизненного цикла разведены, противоречия видны, выбран один вердикт, названо то, что нельзя повторять, и указан ровно один следующий шаг. Репозиторий и внешние системы остаются без изменений.

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

После каждого использования skill нужно запустить короткий опрос. Это не скрытая платформенная автоматизация; это обязательный post-use блок в ответе skill. Опрос задаётся один раз — после выдачи итогового вердикта и следующего шага либо после явного стопа, не посреди восстановления. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

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

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/shag-posle-prervannoy-tseli/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 не коммитить.