Andrey Epifancev a0be5ab5a1 docs: Срез 0 под факты платформы — NATS без JetStream, Python 3.11, PostgreSQL 16, без CI и Nexus
По ответам пользователя 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>
2026-10-03 16:21:39 +04:00

4.9 KiB
Raw Blame History

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 все общие цели присутствуют и запускают описанные команды