From 7384471db3bcbcb788139d878c267ae66a7aac02 Mon Sep 17 00:00:00 2001 From: Andrey Epifancev Date: Mon, 2 Nov 2026 12:19:05 +0400 Subject: [PATCH] =?UTF-8?q?=D0=A0=D0=B5=D0=B2=D1=8C=D1=8E=20#208:=20=D0=BF?= =?UTF-8?q?=D1=80=D0=B8=D0=B2=D0=B5=D1=81=D1=82=D0=B8=20README/OpenSpec=20?= =?UTF-8?q?=D0=B2=20=D1=81=D0=BE=D0=BE=D1=82=D0=B2=D0=B5=D1=82=D1=81=D1=82?= =?UTF-8?q?=D0=B2=D0=B8=D0=B5=20=D1=81=20=D1=84=D0=B0=D0=BA=D1=82=D0=B8?= =?UTF-8?q?=D1=87=D0=B5=D1=81=D0=BA=D0=B8=D0=BC=20=D0=B4=D0=B8=D1=84=D1=84?= =?UTF-8?q?=D0=BE=D0=BC?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - README: вернуть потерянный абзац-предупреждение про e2e и queue group (был затёрт вставкой нового раздела); описание раздела про корректировки поправлено под архитектуру CorrectionAggregateSource (1540 не читает vgo_assignment напрямую, см. design.md Decision 1). - design.md: Non-Goals ложно утверждал "DBML/ORM/миграция не меняются", хотя в ветке есть миграция 0011 (vgo_assignment, AURORA-1751); уточнена граница ответственности и добавлено пояснение в Migration Plan. - tasks.md: зафиксировано, что make dbml-check не выполнялся — DBML v5.24 ещё не существует в arm-ka-docs, вопрос поднимается отдельно. Co-Authored-By: Claude Sonnet 5 --- README.md | 17 +++++++++++++---- .../changes/corrections-api-stage-one/design.md | 7 +++++-- .../changes/corrections-api-stage-one/tasks.md | 1 + 3 files changed, 19 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 846878b..e25604d 100644 --- a/README.md +++ b/README.md @@ -1186,14 +1186,23 @@ docker compose -f ../docs/dev/docker-compose.yml -p arm-ka --profile services st Образ собирается из `../tabular-parser` (main соседнего репозитория workspace). +**Перед e2e остановите другие экземпляры ядра, подписанные на `files.tabular_parsed`** (контейнер `arm-core` из профиля +`services`, локальный `make run`/`run_server.py` с `NATS_ENABLED=true`): тест подписывается на реальный subject в боевой +queue group `arm-core`, подписчики группы получают сообщения по очереди (round-robin), и ack/результат парсера уйдут +чужому экземпляру (он отбросит их как `unknown_job`, у него другая БД) — тест упадёт по таймауту 60 с. Поднимайте только +`tabular-parser` (`--no-deps`), как в команде выше. + ### Основа таблицы корректировок (AURORA-1540, в работе) -Текущая задача не реализует ручное назначение, перенос или исключение строк ОСВ. +Текущая задача не реализует ручное назначение, перенос или исключение строк ОСВ через API (запись и перенос в +`vgo_assignment` — AURORA-1751). Чистая функция `domain/corrections.py` реализует контроль готового агрегата: при отклонении не более 5 % -справочная сумма элиминации равна меньшей стороне. Соседняя задача записывает готовые назначения в -`vgo_assignment`, а API корректировок читает их и группирует строки по правилу и паре компаний. Этот API -не выбирает правила, не разносит строки ОСВ и не меняет назначения. +справочная сумма элиминации равна меньшей стороне. Разнесение строк ОСВ по правилам и хранение ручных решений +(таблица `vgo_assignment`) — ответственность AURORA-1751 (`services/vgo.py`). API корректировок получает уже +вычисленные агрегаты и пары через интерфейс `CorrectionAggregateSource` (реализация `VgoCorrectionSource` вызывает +`VgoService.assignment_candidates`) и не читает схему `vgo_assignment` напрямую. Этот API не выбирает правила, не +разносит строки ОСВ и не пишет назначения. Подключены маршруты под `/api/v1/consolidations/versions/{version_id}`: diff --git a/openspec/changes/corrections-api-stage-one/design.md b/openspec/changes/corrections-api-stage-one/design.md index ed49b26..4c0c5c5 100644 --- a/openspec/changes/corrections-api-stage-one/design.md +++ b/openspec/changes/corrections-api-stage-one/design.md @@ -15,8 +15,9 @@ **Non-Goals:** -- Реализовывать собственное сопоставление строк ОСВ, выбирать правило или хранить вычисленные пары. -- Изменять DBML, добавлять ORM-модель или миграцию. +- Реализовывать собственное сопоставление строк ОСВ, выбирать правило или хранить вычисленные пары — это + AURORA-1751; DBML v5.24, ORM-модель `VgoAssignment` и миграция `vgo_assignment` в этой ветке сделаны в рамках + 1751, а не этим change (см. Migration Plan). - Импортировать XLSX, рассчитывать КФО, поддерживать ОФР или UI. ## Decisions @@ -44,3 +45,5 @@ ## Migration Plan Миграция для таблицы корректировок, вычисленных пар или их состава не добавляется. Существующая модель `correction` используется без изменения. + +В ветке есть миграция `0011_dbml_v5_24` — она создаёт только `vgo_assignment` (AURORA-1751), таблиц `correction`/`correction_line` не касается. DBML v5.24 в `arm-ka-docs` на момент этого change ещё не существует (`docs/model/data-model-v5.24.dbml`), `make dbml-check` не проходит; вопрос поднят отдельно. diff --git a/openspec/changes/corrections-api-stage-one/tasks.md b/openspec/changes/corrections-api-stage-one/tasks.md index 5cd58ec..7f5e7ec 100644 --- a/openspec/changes/corrections-api-stage-one/tasks.md +++ b/openspec/changes/corrections-api-stage-one/tasks.md @@ -33,6 +33,7 @@ - `mypy` схемы, источника и экспорта корректировок — успешно. - Целевые тесты источника, экспорта, VGO и OpenAPI — 90 успешно. - Расширенный набор с API-тестами остановлен на зависшей инициализации интеграционных фикстур; завершившиеся целевые тесты ошибок не показали. +- `make dbml-check` **не выполнялся**: `docs/model/data-model-v5.24.dbml` в `arm-ka-docs` ещё не существует (вопрос поднят отдельно, вне этого PR). ## Workflow follow-up