api_for_gu

Официальные документы API Госуслуг

Проверяемый локальный снимок публичного каталога API Госуслуг, прочитанный 12 августа 2026 года. Скрипт складывает неизменённые DOCX/PDF с gu-st.ru в игнорируемый Git каталог source/, а публикуемый catalog.json фиксирует исходный URL, дату, размер и SHA-256 каждого файла.

Материалы в source/ и дословно извлечённые XML/XSD принадлежат их правообладателям и не лицензируются AGPL проекта. Публичность URL сама по себе не подтверждает право на повторное распространение, поэтому эти каталоги исключены из Git; публикуются только ссылки, метаданные, хэши и самостоятельно написанная реализация. Python wheel/sdist и runtime Docker image официальный снимок также не включают.

Состав снимка

• 28 документов общим объёмом 12 067 207 байт;
• 21 спецификация отдельной услуги;
• базовая спецификация API ЕПГУ v1.14 от 29.01.2026, API ГЭПС v1.0, регламент v1.8 и пять общих руководств/соглашений;
• 134 извлечённых блока: 98 XML-примеров и 36 XSD-схем из спецификаций 18 услуг.

Строгая проверка XML считает 102 блока well-formed и 32 блока фрагментами/невалидными. Это характеристика механического извлечения и исходного текста, а не оценка юридической силы документа.

Обновление и проверка

Из корня репозитория:

# Скачать отсутствующие файлы и проверить их по зафиксированным SHA-256.
python scripts/sync_api_for_gu_docs.py --check

# Скачать отсутствующие/изменённые файлы; --force повторно скачивает всё.
python scripts/sync_api_for_gu_docs.py --force

# Повторно извлечь XML/XSD и записать inventory.json.
python scripts/extract_api_for_gu_assets.py

# Только проверить извлечённые файлы и цепочку хэшей, ничего не перезаписывая.
python scripts/extract_api_for_gu_assets.py --check

После изменения официального снимка нужно просмотреть diff catalog.json, проверить дату, название и код каждой услуги, заново построить service_profiles.json и выполнить контрактные тесты. Скрипты не должны автоматически повышать готовность профиля до verified.

Как используются извлечённые материалы

extracted/inventory.json связывает каждый блок с услугой, исходным DOCX, таблицей/ячейкой, SHA-256 и результатом проверки well-formed XML. Эти материалы служат доказуемой основой для ручной разработки профиля, но не являются готовыми production-шаблонами:

• примеры могут содержать тестовые персональные данные и значения-заглушки;
• отдельная ячейка DOCX может быть только фрагментом XML/XSD;
• схема может находиться во внешнем архиве или ЛКУВ и потому не извлечься из DOCX;
• совпадение хэша подтверждает неизменность файла, но не корректность выбранного варианта услуги.

В текущем backend-реестре 21 профиль. Доступны три профиля Госключа: УНЭП 10000000374, УКЭП для юридических лиц/ИП 60025907 и УКЭП с сертификатом Федерального казначейства 60080470. Ещё 18 видны в UI как reference, но их отправка заблокирована. У 10000000374 capability УКЭП физического лица остаётся справочной. Для ФССП 60010153 схема и транспорт каталогизированы, однако извлечённый XML является демонстрационным; включение требует типизированной формы, fail-closed проверки placeholder/полей и приёмки в авторизованном контуре.

Зафиксированные противоречия и пробелы

• 10000000588: DOCX v3.0 использует namespace 2.5.4/2.0.5, а связанный публичный архив схем — 2.5.3/2.0.4.
• 60079416: официальные материалы расходятся по полям FileName/Description и лимиту 50/20 документов; профиль расшифрования Госключа заблокирован.
• В нескольких примерах СФР есть кириллические URI пространства имён: строгий lxml отвергает их, хотя менее строгий парсер может разобрать дерево.
• Для 10000000585, 60048912 и 10000000588 из DOCX не извлечены самостоятельные XML/XSD-блоки; внешние источники требуют ручной проверки.

Оригинальные официальные файлы не исправляются молча. Нормализация или принятое решение должны оформляться отдельным профилем, тестом и пояснением с сохранением хэша исходника.

Полная матрица находится в ../SERVICES.md, результаты аудита — в ../AUDIT_2026-08-12.md.