этап 1 · окружение · данные в PostgreSQL · 8 контрольных запросов

Отчёт этапа 3 Протокол приёмки Приложение 1 — регрессия Приложение 2 — живая приёмка Отчёт этапа 2 Отчёт этапа 1

Этап 1 — окружение, данные в PostgreSQL, офлайн-тесты

Статус: сделано, перепроверено с чистого листа 24.10.2026. Границы этапа (без ядра, HTTP/MCP, контейнера и вызовов модели) соблюдены — их и не трогали.

Что сделано

1. Комплект КОРУС распакован, его содержимое лежит прямо в корне репозитория (документы 01–06, ACCESS.md, CLAUDE.md, reference_impl/, demo_stand/, customer_materials/, eval/). Папка с архивом из репозитория убрана.
2. Первым коммитом записан список того, что не должно попадать в репозиторий: рабочее окружение питона, файлы своей базы PostgreSQL, файл-сокет, журналы, CSV синтетики и посторонние копии DuckDB.
3. Собрано рабочее окружение: зависимости референсной реализации (duckdb, boto3) плюс psycopg и sqlglot, нужные для работы с PostgreSQL на следующих этапах. Команда одна: bash scripts/setup_env.sh.
4. Прогнаны офлайн-тесты референса на DuckDB — это точка отсчёта до каких-либо правок кода.
5. Поднята своя PostgreSQL 16, в неё загружена синтетическая витрина закупок (DDL + 11 файлов данных), и 8 контрольных запросов сверены между DuckDB и PostgreSQL — совпало всё, сверка точная (деньги до копейки, количества до штуки, без округления с допуском).
6. Добавлен режим самопроверки сверки: он искажает один результат и должен дать «НЕ совпадает» — иначе сверке нельзя доверять. Проверено, что она действительно ловит искажение, включая отдельно оговорённый случай — расхождение ровно в 1 рубль на крупной сумме (~28 млрд).
7. PostgreSQL после работы остановлена.

Что изменилось с прошлой версии отчёта

• Убран раздел о временной технической вставке, которая раньше была нужна, чтобы DuckDB запускался на этой площадке: площадку исправили, обход больше не нужен и в коде его не осталось.
• Убран раздел о случае, когда один раз не удалось сохранить изменения в историю проекта: это была разовая неполадка самой рабочей площадки, а не ошибка в работе; к текущему результату она не относится.
• Добавлен раздел ниже с выводом самопроверки сверки в обе стороны: обычный прогон (должен совпасть) и прогон с искажением (должен НЕ совпасть) — оба прогнаны заново и показаны рядом.

Вывод офлайн-тестов референса (DuckDB) — прогон с чистого листа 24.10.2026

Команда:

.venv/bin/python reference_impl/qa/test_handler.py

Итоговая строка реального прогона:

Пройдено 85 из 85

Окружение перед прогоном было пересобрано с нуля (rm -rf .venv && bash scripts/setup_env.sh) — это не повтор старого результата, а свежий прогон на чистом окружении.

Сверка 8 контрольных запросов: PostgreSQL против DuckDB — прогон 24.10.2026

ИНН «Альфа-Снаб Екатеринбург» (используется в запросах 1 и 4), определён запросом по наименованию — 6600370124, одинаковый в обеих базах.

Итоговая строка скрипта сверки: совпадает, код возврата 0.

При переносе запросов на PostgreSQL обойдена известная ловушка из документации комплекта: сумма закупок — поле с плавающей точкой, а округление до копеек на PostgreSQL для такого поля без явного приведения к типу numeric не работает (функция round(double precision, integer) не существует). Во всех запросах округление сделано как ROUND(сумма::numeric, 2).

Самопроверка сверки — в обе стороны (прогон 24.10.2026)

Сверке можно доверять только если она умеет не только подтверждать совпадение, но и ловить расхождение. Проверено явно в обе стороны, оба прогона — свежие, после перезагрузки PostgreSQL.

1. Честный прогон — данные не трогали, ожидается «совпадает»:

.venv/bin/python scripts/compare_pg_duckdb.py

Итоговая строка: «совпадает», код возврата 0. Все 8 запросов — «да» (таблица выше).

2. Прогон с искажением — один результат PostgreSQL намеренно подменён, ожидается «НЕ совпадает»:

.venv/bin/python scripts/compare_pg_duckdb.py --self-check-poison

Искажены два запроса: сумма закупок по ИНН «Альфа-Снаб Екатеринбург» (на 0,01 руб., с 1 357 249 732,08 до 1 357 249 732,09 руб.) и число позиций по БЕ 1100 (на 1 штуку, с 23 718 до 23 719). Итоговая строка: «НЕ совпадает», код возврата 1; оба искажённых запроса в таблице отмечены «НЕТ», остальные шесть — «да» (сверка не «краснит» всё подряд, а точечно находит именно испорченные строки).

Отдельно проверено более крупное и округлое искажение по прямому требованию заказчика — ровно 1 рубль на сумме около 28 млрд (запрос 2: 28 076 423 313,02 → 28 076 423 314,02 руб.) — и оно тоже распознано как «НЕТ»: точность сравнения (Decimal, округление ровно до 2 знаков, равенство без допуска) не теряет расхождение даже на крупной сумме. Подробности и вывод этой отдельной проверки — в reports/archive/etap-4-priemka-chistyi-progon.md, раздел 6.

Вывод: сверка работает в обе стороны — подтверждает совпадение, когда данные верны, и находит расхождение, когда данные испорчены. Если бы самопроверка этого не умела, доверять зелёной галочке «совпадает» на настоящих данных было бы нельзя.

Сколько строк загружено в каждую таблицу

Проверено прямым запросом count(*) к своей PostgreSQL после загрузки — совпадает с числом строк, которое выгрузил export_csv.py из purch_demo.duckdb.

Роль только на чтение и прогон SQL из кода (дополнительная проверка, прогон 24.10.2026)

Сверх минимума этапа 1 дополнительно поднята роль purch_ro — у неё есть только SELECT на схемы витрины (dm_purch, dds_v_purch, dm_v_purch) и нет прав на запись. Проверено 7 разных попыток записи под этой ролью (INSERT/UPDATE/DELETE/CREATE/DROP/TRUNCATE, в таблицу и во вью) — все 7 отклонены сервером. Под той же ролью выполнены вживую все 17 фиксированных SQL-запросов, встречающихся в коде шлюза (справочники резолвера + все запросы шаблонной справки по контрагенту): 11 выполнились и вернули результат, 6 — нет, все по одной и той же причине — функция округления суммы (ROUND(SUM(...), 2)) в коде справки написана для DuckDB и не существует в PostgreSQL для чисел с плавающей точкой без явного приведения к numeric. Это дефект диалекта в самом коде purch_card.py, а не в загрузке данных или в правах роли (этим же способом доступа справочники и первый запрос справки читаются без проблем); чинить код ядра на этапе 1 не входило в задачу — правка (привести 6 мест к ::numeric) нужна на этапе переноса ядра в свой пакет сервиса, находка зафиксирована, чтобы не потерять её. Подробный протокол, полный список запросов и точный текст ошибок — reports/etap-1-shag2-rol-chteniya.md.

Требования заказчика этапа 1 — по пунктам (протокол приёмки)

Полный протокол с построчным выводом команд этого прогона — reports/archive/etap-4-priemka-chistyi-progon.md.

Как повторить с нуля

rm -rf .venv
bash scripts/setup_env.sh
.venv/bin/python reference_impl/qa/test_handler.py
bash scripts/load_postgres.sh
.venv/bin/python scripts/compare_pg_duckdb.py
.venv/bin/python scripts/compare_pg_duckdb.py --self-check-poison
.venv/bin/python scripts/check_ro_role.py
PATH=/usr/lib/postgresql/16/bin:$PATH pg_ctl -D .pgdata stop

Что не получилось и почему

На этом этапе (1 из 5) не проверялось, отвечает ли ассистент на реальные вопросы о закупках — это требует вызова модели и запуска ядра сервиса (классификатор, генерация SQL, сводка), а заказчик прямо исключил вызовы модели из объёма этапа 1. Эта проверка относится к этапам 6–7 (регрессия на модели, живая приёмка) и будет сделана там.

Больше ничего из объёма этапа 1 не сорвалось: офлайн-тесты 85 из 85, загрузка и сверка PostgreSQL — все 8 запросов совпали, самопроверка и проверка на 1 рубль/28 млрд подтверждены, PostgreSQL остановлена. Дополнительно (сверх минимума) проверена роль только на чтение — не получилось выполнить без ошибки 6 из 17 запросов кода справки по контрагенту из-за диалектного дефекта округления, не относящегося к этому этапу (подробности выше и в reports/etap-1-shag2-rol-chteniya.md); это находка для этапа переноса ядра, а не незачёт этапа 1.

Страница собрана из файла reports/etap-1.md рабочей копии проекта скриптом scripts/render_report.py.