arm-ka-docs/spec.md at 9b1a4ccbfd4196404d6488af2a52fa1844b19b11

Andrey Epifancev 90ea429642 docs(#116 ): proposal и дельты спек единой нормализации ББ/ОФР

- proposal: зачем, что меняется, порядок выкладки «сначала ядро», non-goals
- statement-normalization: шаги 1–8 общего кода arm_statements (кандидат, раскладка, статусы строк,
  значения, §7, needs_review, структурная проверка кода, уровни предупреждений, статус)
- recognition-contract: файл результата и конверт v2.0, переход 1.x → 2.0
- tabular-recognition-service, scan-gateway: адаптеры шага 1 и что уходит из сервисов
- arm-core: хранение v2.0, агрегат по коду, document_issue, RECOGNIZED, PATCH lines/columns/confirmed,
  порядок 409, миграция v5.19, crm_id ГСК/ГСЗ
- arm-web: экран проверки формы по новым полям
- design.md: автозамена между файлами — §9.5 п. 3, а не §12 п. 3

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BJKMLHdxMwSUeYcdkwqX4W

2026-10-18 00:40:50 +04:00

4.4 KiB

Raw Blame History

ADDED Requirements

Requirement: Адаптер json ИС шага 1

scan-gateway SHALL оставить у себя обмен с ИС Сканирование (горячие папки, опрос, срок, склейку набора json в raw/{job_id}.json до нормализации, очистку папки) и адаптер «таблица table_structure[i] json → FormCandidate»; шаги 2–8 SHALL выполняться копией пакета arm_statements. Адаптер SHALL: создавать кандидата на каждую таблицу каждого успешного json; копировать шапку json (organization, inn, units, date) в шапку каждой своей таблицы как Cell (text = form_name, confidence ИС); передавать label.form_name таблицы как заголовок в evidence (тип — общим правилом шага 1 по словарю заголовков, statement_labels.yaml уходит в словарь пакета); строить плотную сетку по row_index и column_index ИС (пустые позиции — null), Cell.ref = row:<row_index>; locator = file:<имя json>;table:<i>. value у OCR-ячеек всегда null.

Scenario: Один json — ББ и ОФР

WHEN json aep_3.json содержит две таблицы — «Бухгалтерский баланс» и «Отчет о финансовых результатах» — под общей шапкой
THEN два кандидата с locator file:aep_3.json;table:0 и …;table:1, у каждого копия шапки json

Requirement: Ошибки набора json

Ошибочный json набора (parse_error, непустой error.code, корень не объект) при хотя бы одном успешном соседе SHALL давать предупреждение файла JSON_FAILED (error, locator = file:<имя json>, в message — код и сообщение ИС); все json ошибочны — конверт error с кодом первого. Исключение при разборе таблицы — предупреждение TABLE_PARSE_ERROR (error) документа-кандидата, остальные таблицы разбираются; ни одной таблицы не разобрано — error RECOGNITION_FAILED.

Scenario: Потерянный ОФР (решение № 28 среза 3a)

WHEN <job_id>.json успешен (ББ), а <job_id>_ofr.json вернул INVALID_DOCUMENT
THEN документ ББ получает свой статус; в metrics.warnings — JSON_FAILED уровня error; конверт needs_check; ядро не автоподтверждает документы файла

Requirement: Что уходит из шлюза

scan-gateway SHALL удалить api/rules/statement_lines.yaml и подстановку наименований по справочнику, срезание уверенности кода до 99 по справочнику, выбор редакции для имён (_choose_edition), пропуск строк с нечисловым и пустым кодом со счётчиками, правило «оставлена первая строка» при повторе кода, синтез шапки, правило «ячейки под колонкой нет → confidence = 0, не распознано», привязку is_recognized к confidence и правило «любое предупреждение → needs_check». Модули normalizer/ocr/text|dates|amounts переезжают в общие разборы пакета, layout|rows|header| document — в шаги 2–6 пакета; ocr_lookalikes.yaml — в словарь пакета.

Scenario: Строки без кода в aep_3

WHEN в aep_3.json строки «БАЛАНС» и «Выручка» имеют пустой код, а в колонке значения мусор 211(1 |
THEN строки попадают в результат со статусами (detail под строкой с кодом, missing в начале таблицы) и сырым текстом; счётчиков «строк без кода с суммами пропущено» нет

4.4 KiB Raw Blame History Unescape Escape