По ответам пользователя 03.10.2026: обмен через recognition_job перестроен на core NATS (queue group'ы, ack сервиса = конверт status=processing, повторная публикация ядром 30 с × 3 → dlq, дедуп по result_msg_id); capability ci-template заменена на quality-checks (make check / make check-full, конфигураций CI нет); compose: PostgreSQL 16, NATS без --jetstream, python:3.11-slim; пакеты raisa_* фильтруются при dev-установке, npm raisa-* → optionalDependencies. Обновлены 03-architecture, 09-delivery-plan, 00-workspace-layout, proposal/design/specs/tasks change'а; открытые вопросы к платформе закрыты, остались Node и JWT РАИСА. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
4.9 KiB
Spec Delta: quality-checks
Purpose
Единый набор проверок качества для сервисных репозиториев АРМ КА, выполняемый локально одной командой перед каждым PR: какие проверки обязательны, в каком порядке и с какими внешними ресурсами. Конфигураций CI в репозиториях нет — в Gitea CI не используется, пайплайн платформы банка вне зоны проекта.
ADDED Requirements
Requirement: make check — быстрые проверки без Docker
Каждый сервисный репозиторий SHALL предоставлять цель make check, выполняющую из api/: ruff check .,
ruff format --check ., mypy src, pytest -m "not integration", тест идентичности вендоренного контракта с
../docs/contracts. Цель SHALL завершаться ненулевым кодом при первой упавшей проверке и MUST NOT требовать запущенного
Docker, PostgreSQL или NATS.
Scenario: Файл не отформатирован
- WHEN в репозитории есть файл, не отформатированный
ruff format - THEN
make checkзавершается с кодом 1 на шагеruff format --check, следующие шаги не выполняются
Scenario: Чистый репозиторий
- WHEN все проверки проходят
- THEN
make checkзавершается с кодом 0 за время, не превышающее нескольких минут, без обращения к сети
Requirement: make check-full — полная проверка против compose
Каждый сервисный репозиторий SHALL предоставлять цель make check-full: make check плюс pytest -m integration против
инфраструктуры docs/dev/docker-compose.yml (PostgreSQL 16, NATS, MinIO, для scan-gateway — эмулятор). Для arm-core
цель SHALL дополнительно выполнять «alembic upgrade head → alembic downgrade base → alembic upgrade head» на чистой
БД и python scripts/check_dbml_vs_orm.py против ../docs/model/data-model-v5.13.dbml. make check-full SHALL быть
выполнен перед созданием PR, его итог вписывается в описание PR.
Scenario: Расхождение ORM и DBML
- WHEN в ORM добавлена колонка, которой нет в DBML
- THEN шаг
check_dbml_vs_ormпадает с перечнем расхождений,make check-fullзавершается с кодом 1
Scenario: Миграция без отката
- WHEN
downgradeревизии не удаляет созданный ею объект - THEN шаг «upgrade → downgrade → upgrade» падает
Requirement: Фикстуры и соседние репозитории — опциональны с предупреждением
Проверки SHALL брать docs и fixtures из соседних каталогов workspace (../docs, ../fixtures) или из переменных
ARM_KA_DOCS, ARM_KA_FIXTURES. При отсутствии фикстур тесты с маркером fixtures SHALL пропускаться с явной причиной;
при отсутствии docs тест идентичности контракта SHALL пропускаться с предупреждением. Отсутствие соседей MUST NOT делать
make check красным.
Scenario: Нет фикстур
- WHEN
../fixturesотсутствует иARM_KA_FIXTURESне задан - THEN тесты с маркером
fixturesпомечены skipped с причиной «ARM_KA_FIXTURES недоступен», остальные выполняются
Requirement: Одинаковый набор целей во всех репозиториях
Makefile каждого сервисного репозитория SHALL содержать цели up, test, test-integration, lint, check,
check-full с одинаковой семантикой (описана в docs/dev/checks.md); репозиторий MAY добавлять свои цели (migrate,
seed, emulator), но MUST NOT менять смысл общих.
Scenario: Сверка с описанием
- WHEN ревьюер сравнивает список общих целей
Makefileсервиса сdocs/dev/checks.md - THEN все общие цели присутствуют и запускают описанные команды