- design.md: Р-20 (законные повторы кода в перечне, синонимы в словаре имён), Р-21 (мягкое соотношение, сошедшееся точно, подтверждает неуверенное значение), Р-22 (S-1…S-25 приняты с оговорками; отмечены утверждённые владельцем); решения при доработке S-26…S-52 с ценой ошибки - statement-normalization: отдельное требование sync-statements (пути, VERSION, коды 0 / 10 / 20 / 2), словарь единиц и ОКЕИ, ref Excel с кавычками, нумерация с двойниками и пропуском, номер колонки, содержимое строки, столбец кодов у DISCLOSURE, упрощённый 2400 мягкий, Р-20 / Р-21 со сценариями, обе редакции перечня, интерфейс функции статуса, TABLE_PARSE_ERROR / SHEET_OTHER уровня файла - arm-core: признак строки правки row_index IS NULL, header_source, формы без checks (1.x и миграция) — §7 ядром в document_issue, codes / column_index, RESULT_STATUS_INCONSISTENT, синонимы и «итого по разделу», PATCH organization_name / confirmed: false / подтверждение даты, LINE_CODE_TAKEN, акцепт и подтверждения, LINES_UNRESOLVED с текстом, «того же периода», откат миграции - recognition-contract: MODIFIED «Копия контракта … идентична» — сверка по MAJOR копии, *.v1.schema.json на окне; 1.x — MAPPING_WARNING / LEGACY_WARNING; okei, column_index, пустые массивы DISCLOSURE, статус ОСВ одной формулировкой - quality-checks (новая дельта): make check охватывает копию arm_statements, make check-full — statements-check - tabular-recognition-service: манифест statements_manifest.yaml — failed_relations страниц 2 баланса (K-25) - scan-gateway, arm-web: TABLE_PARSE_ERROR файла; подсказки шапки, снятие подтверждений, LINE_CODE_TAKEN - proposal: шаг 0 выкладки, перечни кодов, ожидания на реальных сканах, Impact Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BJKMLHdxMwSUeYcdkwqX4W
4.4 KiB
MODIFIED Requirements
Requirement: make check — быстрые проверки без Docker
Каждый сервисный репозиторий SHALL предоставлять цель make check, выполняющую из api/: ruff check .,
ruff format --check ., mypy src (в сервисе с копией общего кода arm_statements — mypy src arm_statements, в
arm-core — ещё scripts), pytest -m "not integration" (включая тесты копии arm_statements/tests/), тест
идентичности вендоренного контракта с ../docs/contracts (на окне перехода между MAJOR — со схемой того MAJOR,
который сервис пишет). Цель SHALL завершаться ненулевым кодом при первой упавшей проверке и MUST NOT требовать
запущенного Docker, PostgreSQL или NATS. Свежесть копии arm_statements относительно репозитория arm-statements в
make check MUST NOT проверяться (соседний репозиторий в make check не читается).
Scenario: Файл не отформатирован
- WHEN в репозитории есть файл, не отформатированный
ruff format - THEN
make checkзавершается с кодом 1 на шагеruff format --check, следующие шаги не выполняются
Scenario: Чистый репозиторий
- WHEN все проверки проходят
- THEN
make checkзавершается с кодом 0 за время, не превышающее нескольких минут, без обращения к сети
Scenario: Тесты копии общего кода
- WHEN в
tabular-parserлежит копияapi/arm_statements/с тестами пакета - THEN
make checkгоняет их вместе с тестами сервиса,mypyпроверяет и копию
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-v<текущая>.dbml, путь — переменная DBML Makefile). В сервисе с копией общего
кода arm_statements цель SHALL выполнять statements-check — ../docs/scripts/sync-statements.sh --check по этому
хосту (спека statement-normalization, требование «sync-statements — копии пакета в потребителях»): коды 0 и 10
— шаг зелёный (10 — с предупреждением «копия отстала»), 20 и 2 — красный. make check-full SHALL быть
выполнен перед созданием PR, его итог (и предупреждение statements-check, если было) вписывается в описание PR.
Scenario: Расхождение ORM и DBML
- WHEN в ORM добавлена колонка, которой нет в DBML
- THEN шаг
check_dbml_vs_ormпадает с перечнем расхождений,make check-fullзавершается с кодом 1
Scenario: Миграция без отката
- WHEN
downgradeревизии не удаляет созданный ею объект - THEN шаг «upgrade → downgrade → upgrade» падает
Scenario: Прямая правка копии общего кода
- WHEN в
scan-gatewayпоправлен файлapi/arm_statements/steps/…, а вarm-statementsтакого изменения нет - THEN
statements-checkзавершается с кодом 20 и называет файл,make check-fullкрасный