# Пакет фактического подтверждения публикации

Дата: 14 июля 2026 года. Обновлено: 16 июля 2026 года.

## Назначение

Пакет помогает отправлять единообразные запросы по задачам `data/publication_basis_review_queue.csv` и разбирать ответы без ложного вывода, что редакционная переписка сама по себе является юридически утверждённым согласием.

Шаблоны находятся в `data/publication_basis_confirmation_templates.json`.

Фактическое исполнение фиксируется в обезличенном журнале `data/publication_basis_confirmation_register.csv`. Панель журнала: `/publication-basis-review/`.

## Общий принцип

Запрос предназначен для двух целей:

1. проверить фактическую актуальность председателя, контакта или ссылки;
2. узнать предпочтительный публичный канал ТОС и сведения, которые нужно убрать или исправить.

Запрос не является формой согласия на обработку или распространение персональных данных. Ответ не создаёт `publication_consent_ref` автоматически.

## Рабочий журнал

Журнал содержит ровно 24 строки в порядке очереди 13/9/2. Каждая строка связана с волной и соответствующим шаблоном.

В публичном репозитории допустимы только обезличенные коды:

- роль получателя;
- тип канала;
- роль ответственного;
- даты этапов;
- структурированный результат разбора;
- обезличенный `factual_source_ref`.

Адрес получателя, ФИО, телефон, email, ссылка на личный профиль, скриншот и сырая переписка в журнал не вносятся.

Строка считается готовой к отправке только после заполнения `recipient_role`, `channel_type` и `owner_role`. Это всё ещё статус `draft`: он не подтверждает отправку.

## Шаблоны

### Волна 1

Используется для карточек с личными профилями, сочетанием телефон+email или нераспознанными ссылками.

Нужно уточнить:

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

### Волна 2

Используется для карточек с телефоном или email без критериев первой волны.

Главный вопрос: является ли контакт общим каналом ТОС или личным контактом, который следует заменить либо скрыть.

### Волна 3

Используется для карточек, где опубликовано только ФИО председателя.

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

## Подстановка данных

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

- `[НАЗВАНИЕ ТОС]`;
- `[ССЫЛКА НА КАРТОЧКУ]`;
- `[ПЕРЕЧЕНЬ ТИПОВ ОПУБЛИКОВАННЫХ ПОЛЕЙ]`;
- `[СРОК ОТВЕТА]`.

Пакет не содержит контактов, ФИО получателей, email, телефонов или личных ссылок. В репозитории не создаются готовые письма с такими значениями.

## Что фиксировать после отправки

В публичном контуре допустимо хранить только:

- slug ТОС;
- ID шаблона;
- статус запроса;
- роль получателя без ФИО;
- тип канала отправки без адреса получателя;
- роль ответственного;
- дату отправки и повторного контакта;
- дату получения ответа;
- дату и роль редакционного разбора;
- обезличенный `factual_source_ref`;
- перечень типов полей, которые оставить или удалить;
- предпочтительный тип общего публичного канала;
- классификацию опубликованной ссылки.

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

Свободные текстовые примечания в публичном контуре не сохраняются: результат разбора фиксируется только в разрешённых структурированных полях.

## Этапы статуса

- `draft` — строка подготовлена; даже заполненный канал ещё не означает отправку;
- `sent` — запрос фактически отправлен, указаны дата и срок повторного контакта;
- `waiting` — ожидается ответ после фактической отправки;
- `received` — ответ получен, но может быть ещё не разобран;
- `needs_clarification` — ответ разобран, но доказательств недостаточно для окончательного решения;
- `closed_without_response` — контактные попытки завершены без ответа, решение фиксируется без создания `factual_source_ref`.

Статусы `sent`, `waiting` и `received` нельзя ставить без реального действия.

Для неразобранного `received` поля решения и `factual_source_ref` остаются пустыми. Только после редакционного разбора можно указать типы полей для сохранения, удаления или замены.

## Как использовать ответ

Ответ может:

- подтвердить или опровергнуть факт;
- дать основание исправить или удалить данные;
- определить предпочтительный общий канал ТОС;
- сформировать обезличенный `source_ref` после редакционной проверки.

Ответ не может автоматически:

- создать `publication_consent_ref`;
- перевести карточку в `partial` или `verified`;
- разрешить публикацию нового личного контакта;
- заменить отдельный утверждённый юридический процесс.

## Допустимые редакционные решения

- `keep_current` — оставить перечисленные подтверждённые типы полей;
- `remove_fields` — удалить перечисленные поля по проверяемому основанию;
- `replace_with_general_channel` — заменить личный контакт общим каналом ТОС;
- `hide_until_confirmed` — скрыть неподтверждённое до получения основания;
- `no_change_without_evidence` — не менять карточку при недостаточных доказательствах.

Редакционное решение не создаёт согласие на распространение персональных данных и не заменяет задачу #205 по юридической модели портала.

## Граница автоматизации

Код проверяет:

- соответствие 24 строк исходной очереди;
- правильный шаблон для каждой волны;
- хронологию дат;
- обязательные обезличенные роли и канал;
- отсутствие фиктивных результатов в `draft`, `sent` и `waiting`;
- разделение получения ответа и редакционного разбора;
- запрет `factual_source_ref` при закрытии без ответа.

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