Proverka Prichin Sboya

Проверка Причин Сбоя

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

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

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

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

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

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

Назначение

Skill включается уже при первом неоднозначном сбое или нейтральном, воспроизводимом поведении сети, API, CI, интеграции, desktop-приложения, устройства или сервиса. Он подходит и когда пользователь не сообщает об ошибке, а спрашивает, по какому правилу система выбирает источник, среду, профиль или маршрут. Результат — не правдоподобная причина и не длинное дерево советов, а один безопасный опыт, наблюдение которого различает две конкурирующие версии.

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

Главный принцип: меняйте не формально одну настройку, а создавайте один causal_contrast — одно различие, которому две гипотезы дают разные прогнозы. Если действие одновременно меняет несколько причинно значимых факторов, результат нельзя использовать для локализации причины.

Быстрый Роутинг

• Если есть точный доменный skill или runbook, используйте его команды и ограничения, а этот skill — для выбора различающего опыта.
• Если есть точная failing assertion и следующий локальный fix однозначен, обычная диагностика короче и полезнее.
• Если явного сбоя нет, но поведение воспроизводимо зависит от источника, среды, профиля или API-маршрута, используйте тот же различающий цикл.
• Если два опыта с одинаковым state_fingerprint уже дали inconclusive или invalid_test, передайте задачу в peresmotr-predposylok-posle-povtora.
• Если пользователь просит исследовать похожие внешние случаи после зацикливания, используйте peresmotr-predposylok-posle-povtora.
• Если нет ни outcome, ни точного вопроса о правиле либо нет свежего наблюдаемого факта, получите один самый дешёвый доступный вход и остановитесь.

Входы

Обязательные:

outcome: "Какой конечный результат или наблюдаемое правило нужно установить."
current_observation:
  fact: "Что наблюдалось без объяснения причины."
  source: "Лог, команда, целевой интерфейс или подтверждение пользователя."
  observed_at: "Когда наблюдение было получено."
target: "Какая техническая система или операция исследуется либо не достигла outcome."
constraints: "Что нельзя менять, запускать, повторять или раскрывать."

Опциональны предыдущие попытки, журналы, снимок конфигурации, доступные инструменты, предполагаемые причины и уже известные ложные признаки успеха. Не угадывайте обязательные входы. Подробный контракт лежит в references/diagnostic-contract.md.

Рабочий Протокол

1. Прочитайте known-exceptions.yaml. При совпадении примените указанное do_next_time, не повторяя известную ошибку.
2. Зафиксируйте outcome или вопрос о фактическом правиле, прямое доказательство результата и forbidden false positives. Открытое окно, зелёный индикатор, живой процесс, TCP-соединение, HTTP 200 или успешный локальный тест не заменяют иной пользовательский результат.
3. Соберите свежий state_fingerprint: целевой объект, релевантная конфигурация, среда, последний причинно значимый шаг и наблюдение. Время храните в metadata факта, но не включайте в ключ повтора опыта.
4. Разделите факты, выводы и внешние сведения. Наблюдение из терминала не является прямым фактом о GUI; транспортный ответ не является успешной авторизацией; чужой кейс не является локальным доказательством.
5. Постройте только нужные причинные границы. Это карта, а не обязательная линейная лестница: outcome, клиент, процесс, конфигурация, данные, права, интеграция или транспорт, внешняя зависимость и измерительный стенд.
6. Сформулируйте hypothesis_a и hypothesis_b, которые обе объясняют текущий симптом или правило выбора. До опыта раскройте направления и варианты каждой версии как полные множества наблюдаемых прогнозов. Множества A и B не должны пересекаться; одиночный прогноз считайте множеством из одного исхода.
7. Выберите самый дешёвый и безопасный probe с высокой различающей способностью. Запишите causal_contrast, held_constant, expected_if_a, expected_if_b, владельца действия и evidence, которое нужно сохранить. Evidence должно содержать фактическое значение, метку или относительный порядок на проверяемой границе, а не только факт успешного выполнения вызова.
8. Пройдите Safety Gate. Самостоятельно выполните только разрешённую безопасную проверку. Если нужен человек или отдельное разрешение, дайте одну точную инструкцию и остановитесь.
9. После валидной проверки сопоставьте фактическое наблюдение с заранее записанными множествами. Исход только из A даёт favors_a, только из B — favors_b. Пригодный наблюдаемый исход вне обоих множеств даёт models_rejected: обе версии отвергнуты, поведенческий контракт не формулируется, следующий шаг — пересобрать версии по новому факту. Если пригодного однозначного наблюдения нет, используйте inconclusive. Не объявляйте root cause по результату favors_a или favors_b. При этих двух verdict для нейтрального поведения формулируйте только наблюдаемый контракт: «при условиях X система наблюдаемо делает Y».
10. Ответьте коротко: покажите один следующий опыт и явную границу знания. Следующую ветку выбирайте только после нового результата.
11. Обновите do-not-repeat: одинаковые state_fingerprint и probe повторно не выполняются без нового причинно значимого факта.
12. Если прямое evidence подтверждает пользовательский outcome, отдельно отметьте, что цель достигнута. Это не второй verdict и не заменяет единственный verdict, выбранный в шаге 9. outcome_reached используйте как единственный verdict только когда прямое evidence подтверждает конечный пользовательский результат, а классификация наблюдения по A/B не проводится. Если измеритель не различил гипотезы, исправляйте наблюдаемость, а не сочиняйте третью причину.

Один Причинный Контраст

Один причинный контраст — это не обязательно одна команда или один клик. Допустимо выполнить несколько технических подшагов, если они вместе меняют только один проверяемый механизм, а остальные значимые условия сохранены или зафиксированы.

Перед опытом проверьте:

• expected_if_a и expected_if_b задают полные множества наблюдаемых прогнозов с учётом возможных направлений и вариантов, и эти множества не пересекаются;
• если прогноз зависит от сохранённых ключей или порядка, их фактические значения и относительный порядок прочитаны на границе системы, а прогнозы пересчитаны до интерпретации; последовательность действий этого не заменяет;
• probe считывает фактическое значение, метку или относительный порядок, а не только успешность вызова;
• baseline и probe измеряются одним способом;
• перечислены held_constant;
• скрытая смена маршрута, версии, кэша, времени, аккаунта или стенда не смешалась с проверяемым фактором;
• результат можно получить без необратимого или неразрешённого действия.

Если прогнозы совпадают или их множества пересекаются, кандидат не является различающим probe: не запускайте его, не присваивайте verdict и не записывайте строку в experiment-ledger.jsonl. Если единственный различающий probe необратим, небезопасен или не разрешён, вердикт — blocked. В обоих случаях остановитесь, не заменяя опыт догадкой.

Формат Цикла

Внутренне заполните:

outcome:
observed_facts:
state_fingerprint:
causal_boundaries:
hypothesis_a:
hypothesis_b:
causal_contrast:
held_constant:
probe:
owner:
expected_if_a:
expected_if_b:
evidence_to_capture:
safety_gate:
stop_condition:
verdict:

Пользователю по умолчанию покажите простую форму:

Факт:
Две проверяемые версии:
Один безопасный опыт:
Если A:
Если B:
Граница знания:

Допустимые verdict:

• outcome_reached — прямое доказательство пользовательского результата;
• favors_a — наблюдение согласуется с A лучше, чем с B, но причина не доказана;
• favors_b — наблюдение согласуется с B лучше, чем с A, но причина не доказана;
• inconclusive — различающий probe не дал пригодного однозначного наблюдения;
• models_rejected — валидное фактическое наблюдение не входит ни в одно из двух заранее заданных множеств прогнозов;
• invalid_test — изменено несколько причинных факторов, состояние дрейфовало или evidence не относится к этому опыту;
• blocked — нет безопасного observable, полномочия или человеческого действия.

Семантика evidence и verdict описана в references/evidence-and-verdicts.md; примеры причинных границ — в references/causal-boundaries.md.

Safety Gate

Без отдельного согласия допустимы:

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

Отдельного разрешения требуют:

• запись конфигурации, production-данных или внешнего состояния;
• integration/e2e-тест с БД, API, сообщениями, платежами или внешним стендом, если отсутствие побочных эффектов не подтверждено заранее;
• перезапуск сервиса, установка или обновление программ;
• переключение VPN, firewall, DNS или маршрутов;
• авторизация, смена credentials или использование приватного секрета;
• звонок, сообщение, заявка, платная операция или изменение аккаунта;
• probe с неизвестными побочными эффектами.

Наличие rollback не заменяет разрешение. Если среда критична для безопасности или production, доменный runbook и владелец системы имеют приоритет.

Долгая И Многосессионная Работа

По умолчанию skill работает в чате и ничего не записывает. Если диагностика переживает сессии или содержит больше одного опыта, предложите пользователю сохранить в выбранном им workspace:

diagnostic-case.yaml
experiment-ledger.jsonl
do-not-repeat.md

Не создавайте эти файлы без согласия. Для созданного журнала можно запустить scripts/validate_diagnostic_ledger.py: валидатор проверяет форму, допустимый verdict и дубликаты одинакового probe при том же fingerprint. Он не доказывает смысловую независимость гипотез, непересечение множеств прогнозов или соответствие verdict фактическому наблюдению.

Внешние Кейсы

Внешний кейс допускается только как источник нового локального observable. Форум, документация, issue, память или рассказ другого пользователя не доказывают локальную причину. Если кейс не даёт проверяемого наблюдения, он не может определять следующий probe.

Анти-Правила

1. Не превращайте симптом в причину: timeout, HTTP 200, зелёный UI или connected описывают наблюдение, а не механизм.
2. Не обвиняйте credentials без evidence слоя авторизации.
3. Не называйте proxy-признак завершением пользовательской цели.
4. Не меняйте одновременно маршрут, версию, конфигурацию и credentials ради «быстрой проверки».
5. Не повторяйте тот же probe при том же state_fingerprint.
6. Не выдавайте внешний успешный кейс за локальное доказательство.
7. Не используйте слова «должно сработать» как результат опыта.
8. Не раскрывайте secrets, raw logs, аккаунты, контакты и приватные пути.

Границы

Используйте skill для технических систем с наблюдаемыми компонентами и конкурирующими объяснениями одного симптома или воспроизводимого поведения.

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

• для организационных и бизнес-проблем без технического объекта;
• для статистического продуктового A/B-теста;
• для обычного code review или справочного вопроса;
• когда точная failing assertion уже однозначно задаёт следующий fix;
• для обхода ограничений, защит или пользовательских запретов;
• вместо доменного runbook в safety-critical или production-среде;
• после доказанного зацикливания, когда нужен peresmotr-predposylok-posle-povtora.

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

Опрос задаётся один раз — после классификации первого различающего опыта, достижения outcome, явного blocked или явной остановки неразличающего кандидата, не посреди диагностического цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

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

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

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

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

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

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

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

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

Definition Of Done

Основной цикл с различающим опытом завершён, когда:

• назван либо outcome и свежий наблюдаемый симптом, либо вопрос о фактическом правиле и свежий наблюдаемый факт;
• факты отделены от гипотез и снабжены provenance;
• есть две конкурирующие причины с полными непересекающимися множествами наблюдаемых прогнозов;
• выбран ровно один безопасный causal_contrast;
• указаны owner, expected observations, evidence и stop condition, а probe считывает фактическое значение или порядок на проверяемой границе;
• результат получил один допустимый verdict без заявления недоказанной причины;
• пост-вывод ограничен условиями и наблюдаемым поведением, без утверждения внутренней реализации, замысла, нормальности или бага;
• показан один следующий шаг или честный blocked;
• после двух одинаковых неразличающих циклов задача передана в peresmotr-predposylok-posle-povtora.

Остановка неразличающего кандидата завершена отдельно, когда совпадение или пересечение прогнозов явно зафиксировано, кандидат не запущен, verdict не присвоен, строка в experiment-ledger.jsonl не создана, названа граница знания и работа остановлена до появления безопасного опыта с непересекающимися прогнозами.