# Otsev Lozhnogo Uspeha Operatsii

> «Ложный success», «успех раньше времени», «честно ли запуск завершён», «все пути к завершению», «completion gate после инцидента». Вердикт PASS/FALSE_SUCCESS/UNPROVEN.

- Skill: `kir-kopylov/otsev-lozhnogo-uspeha-operatsii` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add kir-kopylov/otsev-lozhnogo-uspeha-operatsii`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/otsev-lozhnogo-uspeha-operatsii/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kir-kopylov (https://skillmd.com/u/kir-kopylov)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kir-kopylov/otsev-lozhnogo-uspeha-operatsii

---


# Аудит Честного Завершения

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

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

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

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

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

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

## Обзор

Skill отвечает на один вопрос: вправе ли полная операция считаться завершённой. Он не оценивает полезность архитектуры целиком и не строит систему восстановления.

Главный инвариант: финальное завершение допустимо только тогда, когда каждый путь к нему требует прямого доказательства каждого заранее обязательного условия.

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

- «проверь, не объявляет ли процесс успех раньше времени»;
- «можно ли честно считать этот запуск завершённым»;
- «найди путь ложного `success` в этой реализации»;
- «проверь completion gate после инцидента»;
- «один источник сработал, но весь run стал успешным — проверь».

## Вход И Область Проверки

Нужны:

- конкретная полная операция и отдельно существующие узкие операции;
- авторитетный контракт обязательных условий;
- реализация, описание workflow либо фактический пакет доказательств запуска.

Тесты, журналы, отчёты и известный инцидент полезны, но не заменяют контракт. Если обязательства или проверяемая область не установлены из доступных источников, верните `UNPROVEN`; не придумывайте их и не превращайте пользователя в курьера данных, которые можно прочитать доступными tools.

## Вердикты

- `PASS`, `close_allowed=yes` — в проверенной области каждый путь к полному завершению требует прямых доказательств всех обязательств;
- `FALSE_SUCCESS`, `close_allowed=no` — существует воспроизводимый путь, который объявляет полное завершение при незакрытом обязательстве;
- `UNPROVEN`, `close_allowed=no` — контракт, пути или доказательства нельзя установить достаточно надёжно.

`PASS` относится только к явно названной области и источникам. Offline-проверка не доказывает поведение живой внешней системы.

## Процесс

1. Зафиксируйте границу полной операции. Не смешивайте её с узкой командой, проверкой одного объекта или отдельным этапом.
2. Выпишите обязательства только из авторитетного контракта. Сохраните точные требования к количеству, статусу, свежести и происхождению доказательства.
3. Найдите все способы объявить финальное завершение: возвраты, итоговые статусы, exit codes, записи состояния, отчёты и вызывающие их ветки.
4. Для каждого пути заполните матрицу `обязательство → прямая проверка → путь завершения → статус`. Один удобный сигнал не переносите на остальные обязательства.
5. Проверьте косвенные признаки: один найденный объект, отсутствие исключения, ответ writer, HTTP 200, зелёный тест, совпавший идентификатор или hash сами по себе не доказывают полное завершение.
6. Для каждого самостоятельного обхода соберите минимальный воспроизводимый контрпример без изменения production-системы. Если обход нельзя доказать, используйте `UNPROVEN`, а не догадку.
7. Верните один вердикт, матрицу, контрпример и границу доказанного. Не переходите к ремонту без отдельного запроса.

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

```text
Вердикт: PASS / FALSE_SUCCESS / UNPROVEN
close_allowed: yes / no
Область: <полная операция и исключённые узкие операции>

| Обязательство | Прямое доказательство | Пути завершения | Статус |
| --- | --- | --- | --- |
| ... | ... | ... | закрыто / обход / неизвестно |

Путь ложного завершения: <точный путь либо «не доказан»>
Минимальный контрпример: <вход и ожидаемый наблюдаемый результат; для PASS — «не применимо», для UNPROVEN — «не доказан»>
Граница доказанного: <что проверено и на какой слой вывод не переносится>
Следующий шаг: <одно действие, необходимое из-за вердикта>
```

## Жёсткие Правила

- Обязательство без прямого доказательства не считается выполненным.
- Доказательство должно относиться к той же операции и удовлетворять точным условиям контракта; идентификатор или hash сами по себе не доказывают происхождение.
- Неизвестное, устаревшее, противоречивое или неполное доказательство не разрешает закрытие.
- Допустимый пустой бизнес-результат может завершиться успешно, если все обязательства процесса доказаны.
- Найдите все самостоятельные пути к финальному статусу, а не только первый дефект.

## Границы

- Не используйте skill для проектирования будущего `/goal`-контракта; это задача `kontrakt-tseli-do-starta`.
- Не используйте его как code-fixer: аудит не меняет код, статусы, схемы или тесты.
- Не добавляйте replay, fault-runner, retry framework, recovery capsule или новую архитектуру ради найденного обхода.
- Не проверяйте им точность сохранённого payload, восстановление после обрыва или идемпотентность — это отдельные задачи.
- Не выдавайте статический анализ, fixtures или старые логи за подтверждение текущего live-state.

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

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

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

Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/otsev-lozhnogo-uspeha-operatsii/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/otsev-lozhnogo-uspeha-operatsii/exception-log.jsonl`.

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

## Definition Of Done

Аудит готов, если:

- область полной операции отделена от узких операций;
- все пути к финальному завершению перечислены;
- каждое обязательство сопоставлено с прямой проверкой на каждом пути;
- вердикт не сильнее доказательств;
- для каждого доказанного обхода дан минимальный контрпример;
- граница между offline- и live-доказательством названа явно;
- код и архитектура не изменены.