ru-software-registry

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, если пользователь явно не просит коммитить документы.

Обязательный порядок

Начинать каждую оценку с технического аудита кода. Не давать вывод "подходит/не подходит для реестра" до выполнения audit_project.py и ручного просмотра его результатов.

Минимальный технический аудит перед документами:

• найти runtime-загрузки из браузера: Google Fonts, Tailwind CDN, jsdelivr, unpkg, cdnjs, Bootstrap CDN, FontAwesome CDN, внешние <script>/<link>;
• разделить внешние URL на functional_api (MAX, Диадок, российские LLM, платежи, почта) и frontend_runtime_asset (шрифты/CDN/JS/CSS), вторые считать блокером;
• проверить секреты, приватные ключи, .env, пароли, API ключи, VPN URI, дампы БД и персональные данные;
• проверить Docker base images и системные пакеты: иностранный образ допустим для разработки, но для реестра отметить как риск и предложить российский/воспроизводимый контур сборки;
• проверить dependency manifests и lock-файлы (package*.json, composer*.json, pyproject.toml, requirements*.txt, go.mod, Cargo.toml);
• проверить TODO/PLACEHOLDER/DEBUG/console.log/test credentials;
• проверить, что ИИ/LLM-провайдеры и зарубежные интеграции опциональны и не являются обязательным контуром работы продукта;
• зафиксировать найденные блокеры и только после их устранения переходить к документам.

Если пользователь спрашивает "оценить для реестра", в ответе сначала давать выводы по коду и runtime-зависимостям, затем документы и правообладателя.

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

1. Проверить проект и сначала разобрать технические блокеры:

python <skill>/scripts/audit_project.py .

Если blocking_findings не пустой, остановиться на исправлении кода/репозитория. Не переходить к генерации пакета документов, пока блокеры не сняты или явно не приняты пользователем как осознанный риск.

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

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

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

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 или российское зеркало исходников;
• релизы и теги версий;
• отсутствие секретов в репозитории;
• инструкции запуска, резервного копирования и обновления;
• сведения о хостинге в РФ, если продукт работает как сервис.

Считать блокерами для реестровой готовности:

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

Если обнаружены токены, пароли, приватные ключи, .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 для проверки актуальных требований на официальных источниках и явно отделять факты из источников от рабочих предположений.