---
name: ru-software-registry
description: "Подготовка продукта к подаче в реестр российского ПО Минцифры и сопровождение заявки через портал. Use when the user asks in Russian or by meaning: подать в реестр отечественного ПО, подготовить документы для Минцифры, проверить готовность к реестру российского ПО, оформить заявку в реестр ПО, собрать пакет документов для реестра, including projects that need README/license/releases/GitVerse/npm/Docker checks, PDF/DOCX document package, and browser-based portal filling."
---

# Реестр российского ПО

## Рабочий принцип

Вести проект от технической проверки до готовой заявки. Не выполнять юридически значимые действия без пользователя: финальная отправка, подписание КЭП и подтверждение сведений остаются за правообладателем.

Всегда работать в папке текущего продукта. Создавать отдельную рабочую папку `registry_ru/` в корне продукта и добавлять ее в `.gitignore`, если пользователь явно не просит коммитить документы.

## Быстрый старт

1. Проверить проект:

```powershell
python <skill>/scripts/audit_project.py .
```

2. Найти локальные данные правообладателя:

- сначала `data/applicant.local.json` в репозитории skill;
- затем `%USERPROFILE%\.codex\ru-software-registry\applicant.local.json`;
- если данных нет, попросить заполнить только недостающее.

3. Создать пакет документов:

```powershell
python <skill>/scripts/generate_registry_docs.py --project . --profile <path-to-applicant.local.json>
```

4. Проверить документы, ссылки и вложения. Для PDF/DOCX использовать доступные локальные инструменты проекта или Documents skill, если пользователь просит финальные файлы.

5. Через Browser открыть `https://reestr.digital.gov.ru/`, дождаться авторизации пользователя, заполнить заявку, прикрепить документы, остановиться перед финальной подписью/отправкой.

## Порядок работы

### 1. Аудит проекта

Проверить:

- `README.md` с понятным описанием продукта, установкой, эксплуатацией, поддержкой;
- `LICENSE`, желательно Apache-2.0/MIT/AGPL/GPL или иная открытая лицензия;
- `package.json`, `pyproject.toml`, `Dockerfile`, `docker-compose.yml` или другая воспроизводимая установка;
- публичный GitHub/GitVerse или российское зеркало исходников;
- релизы и теги версий;
- отсутствие секретов в репозитории;
- инструкции запуска, резервного копирования и обновления;
- сведения о хостинге в РФ, если продукт работает как сервис.

Если обнаружены токены, пароли, приватные ключи, `.env`, дампы БД или персональные данные, остановиться и предложить исправить до публикации.

### 2. Классификация ПО

Не угадывать окончательно, но предлагать классы. Для чат-ботов и диалоговых сервисов обычно начинать с:

- `05.09 Средства управления диалоговыми роботами (чат-боты и голосовые роботы)`;
- дополнительный класс при необходимости: `06.02 Коммуникационное программное обеспечение`;
- ОКПД2 часто подходит: `62.01.29 Оригиналы программного обеспечения прочие`.

Перед подачей сверить актуальные классы с официальным порталом, потому что реестр и классификатор могут меняться.

### 3. Документы

Минимальный пакет:

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

Для подробного состава и формулировок читать `references/document-package.md`.

### 4. Подача через портал

При заполнении портала:

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

Для карты полей читать `references/portal-workflow.md`.

### 5. После подачи

Проверить статус в "Мои заявления". Нормальные ранние статусы: `Новое`, затем проверка комплектности и экспертное рассмотрение. Если пришел запрос на уточнение, готовить точечный ответ и новые PDF без переписывания всего пакета.

## Локальные данные

Не коммитить реальные данные правообладателя. Допустимые публичные файлы: только `applicant.example.json` и обезличенные шаблоны.

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

- тип правообладателя;
- ФИО/название, ИНН, ОГРН/ОГРНИП;
- адрес;
- телефон, email, поддержка;
- сведения о хостинге;
- год и суммы выплат иностранным лицам;
- сайт продукта и ссылки на исходники/релизы.

## Проверка актуальности

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