# Черновой маршрут отзыва, исправления и удаления публикаций

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

Файл `data/withdrawal_correction_deletion_process.csv` подготавливает организационный материал для решения №6 `withdrawal_correction_and_deletion_process` из пакета персональных данных.

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

## Восемь этапов

1. `request_intake` — минимальная регистрация обращения.
2. `request_classification` — определение типа и области запроса.
3. `context_and_authority_check` — проверка контекста и связи заявителя с публикацией во внешнем закрытом контуре.
4. `protective_visibility_decision` — отдельное решение о временном ограничении видимости.
5. `content_action` — исправление, отзыв, удаление либо сохранение публикации после решения.
6. `propagation_check` — проверка производных страниц, индексов и кешей.
7. `requester_response` — подготовка и доставка ответа через утверждённый канал.
8. `case_closure_and_follow_up` — закрытие обращения и последующая проверка результата.

## Что остаётся пустым

Во всех восьми строках намеренно не заполнены:

- `owner_role_code`;
- `reviewer_role_code`;
- `channel_code`;
- `target_time_code`;
- `evidence_ref`.

Эти значения нельзя определять автоматически. Они зависят от решения об операторе портала, организационной модели и юридической проверки.

## Граница публичного репозитория

В GitHub нельзя размещать:

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

Допустимы только обезличенные коды этапов и ссылки вида `case:`, `decision:` или `evidence:`, когда они реально созданы во внешнем закрытом реестре.

## Что не доказывает матрица

Наличие строки в CSV не означает, что:

- обращение получено;
- заявитель проверен;
- публикация временно скрыта;
- исправление или удаление выполнено;
- ответ отправлен;
- обращение закрыто;
- установлены обязательные сроки;
- определены ответственные лица.

## Следующий ручной маршрут

1. Определить оператора портала.
2. Назначить обезличенные роли владельца процесса и юридического проверяющего.
3. Утвердить допустимые каналы приёма и ответа.
4. Проверить состав действий и подтверждений по каждому типу запроса.
5. Установить сроки и правила срочного временного ограничения.
6. Определить закрытое хранилище для оригиналов обращений и доказательств.
7. Утвердить критерии закрытия, повторного открытия и последующего контроля.
8. Только после этого изменять решение №6 в каноническом пакете.

## Автоматические проверки

CI подтверждает:

- ровно восемь этапов и их порядок;
- статус `draft` у каждой строки;
- заполненность описательных полей;
- пустые роли, канал, срок и `evidence_ref`;
- отсутствие прямых контактов, URL и секретов;
- сохранение решения №6 в `pending / not_started`;
- read-only поведение интерфейса;
- подключение тестов к общему project-mode.

Автоматическая проверка не заменяет организационное решение и юридическое заключение.