Восстановление после дрейфа ИИ-агентов и процесс передачи задач

Вернуться к курсу по взаимодействию ИИ

Проверяйте дрейф перед задачами и после прерванной публикации. Сравните версии источников, версии адаптеров и состояние доставки в репозитории или рабочей изолированной среде. Делайте это после завершения одного направления работы. Так старые сводки не станут актуальным источником истины, а история восстановления останется доступной для проверки.

Главное #

• Дрейф источника отличается от дрейфа адаптера.
• Частичная публикация требует отдельного журнала для каждой системы.
• Восстановление сохраняет историю и проверенные изменения.
• Передача задачи требует самостоятельного чтения актуальных источников другим проверяющим.

Перед началом #

Предварительные условия: рабочий процесс GitHub в браузере или смешанный процесс публикации . Расчётное время: от 60 до 90 минут. Сложность: расширенная проверка.

Безопасность: используйте только синтетические записи. Приостановите автоматическую публикацию перед проверками восстановления. Работающая служба удаления не предоставляется.

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

Классифицируйте дрейф #

Самый свежий текст не обязательно является утверждённым источником истины. Недавнее несанкционированное изменение требует расследования, а не автоматического принятия. До копирования значений выясните статус и владельца.

Выполните предварительную проверку #

Read MAP-01 and capture its revision.
Read POL-01 and compare active adapter versions.
Read REQ-17 and RUN-04 from mapped homes.
Read config.json at protected main.
Read frozen proposal and current role reviews.
Compare current sources with reviewed bases.
List mismatches, denied reads, and pending publications.
Stop consequential writes until owners resolve each mismatch.

Автор предложения выполняет предварительную проверку до подготовки черновика. Публикатор повторяет её перед записью. Сохраните сравнение версий вместе с предложением. Еженедельные проверки дополняют чтение источников, но не заменяют его.

Пример дрейфа адаптера: POL-01 переходит на версию 2, а в CLAUDE.md по-прежнему указана версия 1. Остановитесь, прочитайте проверенное изменение политики, обновите адаптер через защищённый PR и запустите новую сессию. Простая смена номера версии без загрузки политики не исправляет контекст.

Создайте дрейф источника в автономной лабораторной среде: распакуйте свежую копию предоставленного ZIP-файла в пустой временный каталог. Из корневого каталога скопируйте baseline/ в candidate/, выполните python3 check.py capture --base baseline > candidate/context.json, затем выполните python3 check.py validate --base baseline --candidate candidate. Зафиксируйте первый результат PASS. Откройте baseline/requirement.json в текстовом редакторе и измените только "retention_days": 7 на "retention_days": 8. Повторно выполните ту же команду validate. Ожидается ненулевой код завершения и сообщение STALE_CONTEXT: capture the trusted base again. Сохраните оба результата и путь изменённого источника. После сохранения частных свидетельств удалите временную распаковку и распакуйте свежую копию для сброса состояния. Не применяйте восьмидневное изменение к опубликованному репозиторию и не считайте повторный захват подтверждением владельца.

Создайте дрейф адаптера во временном репозитории: в новой ветке предложения скопируйте утверждённый текст адаптера POL-01 версии 1 в CLAUDE.md и укажите версию 1. В отдельном проверяемом предложении по политике опишите изменение до версии 2 с конкретным новым условием остановки. Оставьте адаптер на версии 1. Попросите проверяющего сравнить две записи и отметить адаптер как устаревший до слияния или запуска агента. Сбросьте эксперимент, закрыв тестовые предложения или обновив адаптер через проверенный PR. Затем откройте новую сессию и проверьте обе версии и новое условие остановки. Сохраните старый и исправленный diff. Это проверка документации, а не имитация отказа платформы.

Восстановите прерванную публикацию #

1. Приостановите публикацию PROP-042 и назначьте ответственного за восстановление.
2. Прочитайте фактическое состояние во всех задействованных системах. Разделите завершённые, неудачные и не предпринятые действия.
3. Попросите продуктовую команду выбрать завершение, проверенный откат или удержание.
4. Подготовьте предложение по восстановлению на основе свежих версий, сохранив область и исключения, если они отдельно не были пересмотрены.
5. Выполняйте по одному проверенному шагу, записывая и перечитывая каждый результат.
6. Проверьте итоговое состояние и оставшиеся ограничения до возобновления обычной работы.

recovery_id: RECOVERY-042
proposal_id: PROP-042
mode: awaiting-owner-choice
illustrative_state:
  requirement: thirty-days-published
  implementation: seven-days-on-main
  runbook: seven-days
  delivery: blocked
choices:
  forward: finish approved implementation and runbook
  backout: restore baseline through reviewed changes
  hold: wait for evidence or access

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

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

Восстановление в GitHub использует проверенный revert или компенсацию. Восстановление в Confluence сравнивает историю и применяет проверенное восстановление или компенсацию. Восстановление в Jira сохраняет историю предложения, повторно открывая или блокируя доставку. Читайте итоговые ревизии, а не предполагайте, что нумерация истории начинается заново.

Проверьте независимую передачу #

Handoff: HANDOFF-042
Task: PROP-042
Map and policy: attach current approved revisions
Evidence: requirement, runbook, configuration references
Ledger: completed, failed, pending
Decision: owner choice and fixed proposal revision
Limits: no runtime deletion test or production data
Next role: accountable role
Next action: one bounded step
Stop: changed base, access denial, conflicting authority

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

Негативная передача: откажите в доступе к REQ-17. Ожидайте явную блокировку, а не догадку или привилегированный фрагмент. Восстановите только утверждённый доступ через администратора и повторите проверку.

Сначала поставьте диагноз #

Начните с инвентаризации состояния. «Ассистенты расходятся во мнениях» описывает симптом ответа, а не проблему исходного источника. Прочитайте независимо сопоставленное требование, конфигурацию, runbook, политику и запись о доставке, прежде чем просить любого ассистента исправить их.

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

Выполните компенсацию #

Пример прерывания: REQ-17 содержит утверждённое намерение на тридцать дней, а доставка ожидает завершения. Конфигурация и runbook по-прежнему содержат семь дней. Сопровождающий сообщает о нерешённой ошибке реализации. Продуктовая команда выбирает восстановление вместо продолжения.

1. Зафиксируйте текущие версии: требование тридцать, конфигурация семь, runbook семь, доставка заблокирована.
2. Заморозьте ожидающее предложение: сохраните проверки и доказательства неудачной публикации.
3. Подготовьте компенсирующее изменение требования: верните семь, сохранив промежуточные исключения и заметки.
4. Получите проверку владельца: укажите текущую версию источника и точный текст восстановления.
5. Опубликуйте разрешённым способом: перечитайте итоговую версию требования.
6. Сверьте журнал: все применимые опубликованные значения равны семи, исходное изменение не доставлено.

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

Recovery decision: illustrative compensation
Original proposal: PROP-042 revision 1
Observed mismatch: requirement 30, configuration/runbook 7
Owner decision: restore approved baseline intent
Review object: fixed compensation against current requirement version
Result: capture resulting revision and seven-day read-back
Original delivery: withdrawn or blocked with explanation
Limit: no runtime deletion or data restoration performed

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

Проверьте новую передачу #

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

Read the mapped current sources independently.
Distinguish approved intent, committed configuration, and delivery state.
Compare them with the reviewed package and ledger.
List missing reads and changed bases.
Recommend one bounded next action with its accountable role.
Do not treat this handoff as approval or publication permission.

Ожидаемое рассуждение: получатель проверяет результат компенсации, прежде чем утверждать, что базовое состояние восстановлено. Если он только повторяет «семь дней» из передачи, требование независимого чтения не проверено. Запросите свидетельства из источников, а не ещё одну сводку.

Завершённая учебная инвентаризация, синтетическое прерывание:

Передайте эту инвентаризацию второму читателю без старого чата. Передача пройдена, только если читатель самостоятельно находит все четыре состояния, называет исключение резервных копий, определяет base-001 как текущую защищённую ревизию и рекомендует шаг восстановления, проверенный владельцем. Отметьте провал при неверной ревизии, пропущенном исключении или неподтверждённом возобновлении. Запишите ссылки читателя на источники и исправления до следующей записи.

Решите, возобновлять ли работу #

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

Проверка завершения: предоставьте наблюдаемую инвентаризацию состояния, решение владельца, проверенное исправление, итоговое чтение результата и независимое восстановление картины. Если доступ мешает чтению, зафиксируйте блокировку. Перенесите этот стандарт доказательств в итоговый проект.

Устранение неполадок и откат #

Конфликты revert: подготовьте компенсирующее изменение относительно текущего состояния. Восстановление теряет исключения: перед записью сравните весь относящийся к делу раздел. Ответом управляет старая память: начните заново с утверждённых источников и удалите устаревший контекст черновика.

Откат восстановления: остановитесь на последнем проверенном состоянии и добавьте запись в журнал. Не стирайте исходные события аудита и не выполняйте принудительный сброс защищённой истории. Передайте нерешённые вопросы полномочий продуктовой команде.

Упражнение и самопроверка #

Добавьте устаревшие доказательства, устаревший адаптер политики и частичную публикацию. Передайте записи другому проверяющему без объяснений и попросите назвать ответственного за исправление.

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

Основные источники #

• Контроли восстановления репозитория: Защищённые ветки .
• История страниц: Документация Confluence .
• Проверка инструкций: Память Claude Code .

Следующие шаги #

Завершите Retention Capstone , используя оба направления и второго читателя. Покажите актуальные чтения источников, расхождения версий, владельца решения, проверенное восстановление, чтение результата и независимое восстановление картины.