Andrey Epifancev 248f8b0c74 openspec(#116): спека по ревью K-1…K-25 и решениям владельца Р-20…Р-22; решения S-26…S-52
- 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
2026-10-18 02:17:36 +04:00

4.4 KiB
Raw Blame History

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 красный