# Podtverzhdenie Planovoy Rassylki

> «Рассылка сработала?», «почему письма нет?», «не было ли дубля?», «засчитать этот запуск?», «подтверди плановую доставку»: цепочка запуск → отправка → провайдер → копия.

- Skill: `kir-kopylov/podtverzhdenie-planovoy-rassylki` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add kir-kopylov/podtverzhdenie-planovoy-rassylki`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/podtverzhdenie-planovoy-rassylki/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/podtverzhdenie-planovoy-rassylki

---


# Подтверждение плановой рассылки

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

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

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

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

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

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

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

## Задача

Этот навык доказывает статус **одного заранее подготовленного выпуска**. Он не исследует новости, не меняет содержание письма, не создаёт Gmail-черновик, не отправляет письмо и не меняет расписание.

Время запуска рядом со временем полученного письма — слабое совпадение, а не доказательство. Для `PASS` нужна цепочка: запланированный запуск → конкретный вызов отправки → ответ почтового провайдера → полученная копия того же письма.

## Нужный Вход

Соберите один нормализованный пакет доказательств:

- ожидаемый выпуск: `run_id`, `artifact_sha256`, получатели, тема, текст, HTML при наличии, дедлайн;
- запись планировщика с `run_id`, идентификатором его запуска и временем старта;
- запись конкретной отправки с тем же идентификатором запуска, временем отправки, отпечатком выпуска и ответом провайдера с `message_id` и временем принятия;
- полученная копия с тем же `message_id` и полями письма;
- явная область поиска дублей: ящик, начало и конец интервала, запрос и правило, что считать копией;
- полная read-only история использованных `run_id` для проверки повторного запуска;
- прежняя сохранённая квитанция, если она уже есть.

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

## Как Проверять

1. **Сначала сохраните старое.** Если передана прежняя квитанция, оцените её отдельно до свежего поиска. Новый недоступный поиск не стирает уже сохранённое доказательство.
2. **Проверьте происхождение.** `run_id` у ожидаемого выпуска и планировщика совпадает; идентификатор запуска планировщика совпадает с конкретной отправкой; `message_id` отправки совпадает с полученной копией.
3. **Проверьте содержание.** Сравните отпечаток исходящего пакета, получателей, тему, текст и HTML, если HTML ожидался. Нельзя зачесть красивый текст с чужим HTML или неверной темой.
4. **Проверьте порядок и срок.** Время старта ≤ отправка ≤ ответ провайдера ≤ получение; полученная копия лежит внутри объявленного интервала и не позже дедлайна. Если часы или часовые зоны не позволяют сравнить — это не успех.
5. **Проверьте дубли и повтор запуска.** Поиск должен быть полным для указанного ящика, интервала, запроса и правила копии. История не должна содержать текущий `run_id`. Итог «дублей нет» всегда ограничен этой областью, а не всем интернетом или всеми ящиками.

## Итоговые Статусы

| Статус | Значение |
|---|---|
| `PASS` | Полная цепочка существует; содержание совпало; выпуск получен в срок; в объявленной области найдена ровно одна копия. |
| `FAIL` | Наблюдается положительное нарушение: другой текст/HTML/тема/получатель, дубль, опоздание или разорванная подтверждённая цепочка. |
| `UNPROVEN` | Не хватает цепочки, поиск неполный, время несопоставимо или данные недоступны. Это не означает «не отправлено». |

Верните не общий «всё хорошо», а короткую квитанцию:

```text
Статус: PASS / FAIL / UNPROVEN.
Получение: [что подтверждено отдельно от зачёта планового запуска].
Происхождение: [цепочка либо её пробел].
Содержание: [текст/HTML/тема/получатели].
Срок: [результат сравнения].
Дубли: [результат только для ящика, интервала и правила].
Прежняя квитанция: [сохранена / не передана].
Следующее безопасное действие: [одно действие].
```

## Локальный Проверяющий Модуль

Для пакета без секретов можно запустить:

```bash
python3 scripts/verify_receipt.py receipt-packet.json
```

Модуль только читает JSON и возвращает `PASS`, `FAIL` или `UNPROVEN` с причинами. Он не обращается к Gmail, не создаёт историю и не отправляет письма. Его `PASS` ограничен теми записями и областью поиска, которые вошли во входной пакет.

Первая версия поддерживает только выпуск без CC, BCC и вложений. Непустые дополнительные получатели или вложения не игнорируются: пакет не может получить `PASS` без отдельного расширения контракта.

## Границы

- Не отправляйте или повторно не отправляйте письмо ради проверки.
- Не называйте отсутствие письма в неполном поиске доказательством сбоя.
- Не называйте одну найденную копию доказательством отсутствия дублей вне объявленной области.
- Не стирайте старую квитанцию из-за новой ошибки чтения или пустого поиска.
- Не считайте `isinstance(prior_receipt, dict)` доказательством: прежняя квитанция должна содержать `run_id`, `message_id`, отпечаток и время записи.
- Не обещайте mathematically exact-once: почтовый провайдер и область наблюдения дают только доказанный практический вывод.

## Definition Of Done

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

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

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

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

Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/podtverzhdenie-planovoy-rassylki/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, поиск оказался уже заявленной области, отсутствовала связь планировщика с отправкой или квитанция была потеряна в интерпретации, запишите приватную карточку в `~/.codex/skill-runs/podtverzhdenie-planovoy-rassylki/exception-log.jsonl`.

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