arm-ka-docs/openspec/changes/unified-statement-normalization/review-2026-10-18-spec-2.md

# Повторное ревью спеки вслепую (18.10.2026, Opus, коммит 248f8b0)

Ревьюер: отдельный агент (модель Opus), без права правки, режим «чёрный ящик» — не открывал design.md и прошлые
отчёты; решения писателя S-1…S-52 получил отдельным файлом. Маркеры находок — L-n.

Сверка перед передачей владельцу (сессия): подтверждены L-3 (DBML v5.19 — уникальность `(stored_file_id, file_ordinal)`
на всех документах), L-4 (`arm-core/api/src/schemas/files.py` — `JobBrief.warnings: list[str]`), L-5 (сценарий «3450»
в спеке statement-normalization при отрезке 3100–3699).

Отчёт агента ниже без сокращений.

---

# Ревью спеки `unified-statement-normalization` (вслепую, коммит 248f8b0)

## 1. Вердикт

Спека зрелая. Цепочка шагов 1–8, контракт v2.0, DBML v5.19, §7/§9/§11 и перечень кодов в основном согласованы. `openspec validate --strict` проходит, `validate_contracts.py` зелёный (18 примеров + перечень). Схемы `*.v1.schema.json` побайтно равны схемам из 43b4b80.

К написанию плана спека **условно готова**. Сначала нужно закрыть одну критическую находку и примерно десять важных.

**Что блокирует план:**
- **L-1.** Не определено, входят ли значения строк `detail` в `needs_review` и в статус. От этого зависит, станут ли 4 из 6 реальных OCR-документов `done`. Нормативный текст спеки противоречит §11.4.
- **Переход и выкладка:**
  - правило выбора схемы по `$id` ломает тест идентичности для `recognition-request` и для примеров;
  - ядро не входит в шаг 0;
  - `file_ordinal` задан только у форм, а уникальный индекс стоит на всех документах;
  - предупреждения ОСВ и `JobBrief.warnings` в 2.0 никуда не отображены.
- **Раскладка:** не задано, как колонки сегмента со своей шапкой сопоставляются с колонками документа. Это напрямую касается сегодняшнего `done` НПЗ (листы 4 ББ и 3 ОФР со своей шапкой).
- **Разбор суммы:** нет правила «какие символы выбрасываются и когда `amount = null`». Сценарий `211(1 |` → `string_value` из этих правил не выводится.

**Что проверено на данных:**
- Excel из манифеста не даёт ни одной строки `unreadable`/`missing`.
- Нумерация Межениновской (строки 24 и 49) распознаётся новым детектором.
- Сегодняшние `done` сохраняются, если L-6 решить «по порядку» или «по дате».

## 2. Находки

### critical

**L-1. `needs_review` значений строк `detail` и статус документа.**
- Где: `statement-normalization` — «Шаг 8 — `needs_review` значения» («SHALL вычислять `needs_review` у каждого значения») и «Шаг 8 — статус» («нет значений… с `needs_review`»). Против: §11.4 «`detail`… в проверки §7, агрегаты и `done` она не входит». В `arm-web` строки `detail` скрыты переключателем. Проверка согласованности ядра (§9.3, S-48) тоже смотрит «значение с `needs_review`».
- Проблема: у значения строки `detail` нет кода, поэтому покрыть его соотношением нельзя. Любая такая ячейка с уверенностью ниже 100 даёт `needs_review = true`, и по нормативному тексту документ уходит в `needs_check`. При этом причина спрятана под переключателем.
- Проверено скриптом на фикстурах (`scratchpad/rev3/cov.py`). В ББ и ОФР РБ («Бухгалтерская отчетность 1 кв.25») и Счастливочной («БО 1 кв 2025») **все** неуверенные значения строк с кодом покрыты соотношениями. Жёсткие соотношения сходятся. Неуверенные коды подтверждаются перечнем `fsbu4` целиком, разлепленные 1500/1700 тоже покрыты. Держат документ только значения строк `detail` (`'86 157'@67`, `'134'@33`, `'(115 464)'@78` и др.).
- Итог: если `detail` исключить, 4 документа из 6 станут `done`; если включить — 0. Ожидание «доля done небольшая» (proposal, §11.9) верно только во втором случае, но явно этого нигде не сказано.
- Предложение: явно записать в шаге 8 и в функции статуса, что значения `detail` в `done` не входят (`needs_review = false` или исключаются из входа функции; подсказку оставить по `text`/`confidence`). Либо наоборот — оставить и потребовать у экрана счётчик «скрытых сомнительных ячеек» у переключателя. В любом случае нужен сценарий на РБ.

### important

**L-2. Тест идентичности на окне перехода: правило `$id` неполно.**
- Где: `recognition-contract`, требование «Копия контракта…», шаг 0 proposal, `dev/checks.md`.
- Проблемы:
  - `recognition-request.schema.json` в docs имеет `$id` `arm-ka/recognition-request/v1`, а файла `recognition-request.v1.schema.json` нет. По написанному правилу тест ищет несуществующий файл и падает либо молча пропускается («недоступно — пропуск»).
  - На шаге 0 (до слияния docs) файлов `*.v1.schema.json` ещё нет вообще.
  - Существующие тесты (`arm-core/api/tests/test_contract.py:109-125`, `tabular-parser/api/tests/unit/test_contract.py:113-126`, `scan-gateway/api/tests/unit/test_contract.py:120-131`) сравнивают **весь набор `*.json` через `rglob`, включая `examples/`**. После шага 2 в docs появятся `examples/v1/*`, `*.v1.schema.json`, а `examples/*.json` станут v2.0. Набор и байты не совпадут у всех трёх репозиториев.
  - У ядра такой же тест, но в шаге 0 ядра нет: между шагами 2 и 3 `make check` в main arm-core красный.
- Предложение:
  - файл `<имя>.v1.schema.json` брать, только если он есть, иначе основной;
  - явно описать сравнение примеров (копия v1 ↔ `examples/v1/`, файлы другого MAJOR игнорировать);
  - включить arm-core в шаг 0 (или сливать шаги 2 и 3 одновременно);
  - добавить сценарий «запрос v1.0 после слияния v2.0».

**L-3. `file_ordinal` и уникальный `(stored_file_id, file_ordinal)`.**
- Где: `arm-core` «Хранение результата формы v2.0» — `file_ordinal` назначается только `BALANCE`/`INCOME`. Маппер 1.x о нём молчит. В DBML `default 0` и `unique (stored_file_id, file_ordinal)`.
- Сценарий: книга с двумя листами ОСВ, или PDF ББ+ОФР по 1.x → два документа с `file_ordinal = 0` → нарушение уникальности → файл `ERROR`.
- Предложение: «каждый `document` (ОСВ, формы, `DISCLOSURE`/`OTHER`) при любом MAJOR получает `file_ordinal` = индекс в `documents[]`». Добавить сценарий «книга из двух ОСВ».

**L-4. Предупреждения файла и ОСВ в 2.0 никуда не отображены в ядре и API.**
- `metrics.warnings` становится массивом структур, а 1.x тоже конвертируется в структуры `LEGACY_WARNING`. При этом `JobBrief.warnings: list[str]` (`arm-core/api/src/schemas/files.py:59`) читается через `_strings(metrics.get("warnings"))` (`services/documents.py:67`). Структуры отфильтруются, и карточка файла потеряет `JSON_FAILED`/`TABLE_LOST`/`FILE_TYPE_MISMATCH`.
- `osvDocument.warnings` (`OSV_*`) и `osvDocument.status` в спеке `arm-core` не отображены никуда. Сегодня предупреждения ОСВ видны в `job.warnings` (строки `sheet=…`), после перехода tabular-parser на 2.0 они исчезнут из UI.
- В recognition_job будут лежать и строки (старые задания), и структуры.
- Гайд фронта утверждает «поля добавляются, старые не удаляются» — для `JobBrief.warnings` это неверно.
- Предложение: требование в `arm-core` — форма `JobBrief.warnings` (структуры или `message`), где хранятся и показываются предупреждения ОСВ, используется ли `osvDocument.status`.

**L-5. Ошибка в сценарии «Год и сумма — не код».**
- Где: `statement-normalization` «Диапазоны кодов».
- Проблема: «3450» лежит внутри отрезка 3100–3699 (отчёт об изменениях капитала), то есть по правилу это код. Тест, написанный по сценарию, упадёт.
- Предложение: заменить на число вне отрезков (1050, 7450) или ограничить «кодовые диапазоны» для поиска столбца.

**L-6. Сопоставление колонок сегмента со своей шапкой не задано.**
- Где: «Шаг 2 — сегменты», «Шаг 2 — номер колонки».
- Проблема: правило «по порядку» задано только для сегментов **без** шапки. Для повторной шапки (OCR) и листа-продолжения со своей шапкой (НПЗ «Бухгалтерский баланс. Лист 4» — колонки 8–10 при 16/21/24 у первого листа; «Отчет о финансовых результата_3») не сказано, становятся ли колонки новыми `columns[]` или как они сопоставляются (по порядку? по `period_date`?).
- Сценарий: исполнитель создаёт новые колонки → суммы разных листов в разных колонках → §7 НПЗ ББ ломается → сегодняшний `done` становится `needs_check`.
- Предложение: «колонки сегмента с шапкой сопоставляются с колонками первого сегмента по `period_date`, иначе по порядку; число не совпало — `SEGMENT_COLUMNS_MISMATCH`». Добавить сценарий на НПЗ.

**L-7. `parse_amount`: не задано, какие символы выбрасываются и когда `amount = null`.**
- Где: шаг 4.
- Проблема: правило перечисляет двойники, `|`, пробелы, скобки, прочерк. Но сценарии требуют выбрасывать `:`, `=`, `■`, `•` («| : 122477» → 122477), а сценарии `arm-core` и `scan-gateway` ждут, что `211(1 |` даст `string_value` без `amount`.
- Текущий `amounts.py` (`scan-gateway/api/src/normalizer/ocr/amounts.py:56-90`) выбрасывает всё, кроме цифр, `+-.`, и дал бы `211(1 |` → 2111, `(Ю4)` → −4.
- Предложение: явное правило — какой мусор выбрасывается (с `is_recognized = false`), когда результат `null` + `string_value` (непарная скобка, буква внутри цифр, доля мусора). Сценарии на `211(1 |`, `(Ю4)`, `: : 2856983 = ■`.

**L-8. `sync-statements --check`: код 20 при дрейфе перечня кодов в docs.**
- Проблема: правка `statement-code-orders.yaml` в docs до обновления `arm-statements` и пересинхронизации даёт `check-full` = 20 (красный) во **всех** хостах. Это противоречит обоснованию S-30 («отставшая копия не должна блокировать посторонние PR»).
- Предложение: сверять копию перечня с версией docs, соответствующей копии (или выдавать 10, если копия равна дереву своего `VERSION`). Либо зафиксировать порядок «docs и arm-statements сливаются в один день».

**L-9. Полярность `needs_review` при приёме 1.x и в миграции.**
- Где: `recognition-contract` («`needs_review` значения — по прежнему `values_ok` (`is_recognized` не `false` и `confidence` 100 или пуста)»), `arm-core` «Миграция», §9.5, шапка DBML.
- Проблема: в тексте описано условие **OK**, будто это значение `needs_review`. Буквальная реализация ставит `needs_review = true` чистым значениям. Сценария, ловящего это, нет.
- Предложение: «`needs_review = NOT values_ok`» и сценарий.

**L-10. Публичный API пакета для пересчёта в ядре не описан.**
- Спека задаёт вход функции статуса, но не вход пересчёта §7 и `needs_review` из строк БД.
- Не описано, как передать:
  - `is_modified`/`is_confirmed`/`line_code_modified`;
  - исключение правленых ячеек из голосования знака;
  - `form_variant`, эффективную дату для редакции;
  - строки шаблонные и `detail`;
  - что делать с `needs_review_fields` и `form_variant` после правки кода или даты колонки.
- Риск: пакет пишется под `FormCandidate` сервисов, и ядро не может им воспользоваться без реконструкции сетки.
- Предложение: требование «Точка входа пакета для пересчёта по сохранённым данным» с типами и сценарием.

**L-11. Следствие одобренного S-49: правило «итого по разделу — только равенство» ломается на реальной фикстуре.**
- Счастливочная: разлепленная строка 1500 (уверенность 56) с наименованием «Итого по разделу V1» → `NAME_MISMATCH` → `NEEDS_CHECK`, хотя документ полностью сходится.
- РБ: «Итого по разделу V /» совпадает, только если после нормализации обрезаются крайние пробелы. Нормализация этого не говорит.
- Предложение: сравнивать для «итого по разделу» римский номер раздела (первый токен после фразы), явно делать `strip`.
- Кроме того: словарь имён ядра fsbu4 не содержит 1105/1130/1140/1530/2460. Синонимы Р-20 (1220 «НДС, начисленный по отгрузке», 1520 «Обязательство по аренде», 2410 УСН) нужно **явно** потребовать добавить в `statement_lines.yaml`. Сейчас это есть только в сценарии. Без этого законные повторы РБ/Счастливочной/aep_6 дают `NAME_MISMATCH`, а неуверенный 1105 всегда даёт `NAME_MISMATCH`.

**L-12. Страховка ядра (S-48) уже функции статуса.**
- Проверка «согласован» не включает строку `unreadable` без значений, `layout_found`, `has_organization_or_inn`, `period_known`.
- Сценарий: сервис по ошибке прислал `done` при строке `unreadable` без значений → ядро `RECOGNIZED` и автоподтверждение, хотя функция статуса даёт `needs_check`.
- Предложение: «согласован ⇔ общая функция статуса по входу, собранному из результата, даёт `done`». Это не пересчёт `needs_review` и §7, а вызов той же функции.

**L-13. Миграция задним числом меняет подтверждаемость существующих форм.**
- `document_issue` при миграции считается по новому правилу «посчитанного» соотношения. Пустая цель теперь нарушение: страницы 2 ББ без 1600, «только актив».
- Сценарий: `NEEDS_CHECK`-форма, которую до миграции можно было подтвердить, после миграции получает 409 `CHECKS_NOT_PASSED`.
- Импорт живого кода пакета из ревизии Alembic невоспроизводим (S-36 это признаёт).
- Предложение: признать следствие в спеке (сценарий) или считать при миграции по прежнему правилу. Вынести вопрос владельцу.

### minor

- **L-14.** §11.4 приводит «изо :» как пример `unreadable`, но цифр там нет. По правилу это пустой код, и в aep_3 строка (1130, значение `'3'@0`) уйдёт в `detail` и будет скрыта. Исправить пример или правило (считать цифрой и двойники).
- **L-15.** «Ближайшая строка с кодом выше» для `detail`: не сказано, `ok` ли это (если выше стоит `unreadable`). При отметке `ok` → `detail` не сказано про перепривязку детей этой строки (`parent_row_index`).
- **L-16.** Ручная дата колонки (PATCH `columns`) не меняет `period_kind`. Если колонка была `relative:*`, следующая правка `report_date` перезапишет ручную дату. Нужно: ручная дата → `absolute`.
- **L-17.** `COLUMN_DATE_UNCERTAIN` нельзя снять подтверждением той же даты: «запрос без изменений — 200 без эффектов». Нужен аналог S-42 для колонок.
- **L-18.** Подпись OCR с уверенностью ниже 100 подтверждается «ожидаемыми датами» от эффективной даты. Если даты отчёта нет, эффективная дата может определяться этой же подписью, и она подтверждает сама себя. Исключить её при вычислении.
- **L-19.** LIS:
  - не определено, что значит «уверенные коды — якоря» (обязательное включение или вес);
  - не сказано, что делать при конфликте якорей между собой или с перечнем;
  - `form_variant` определяется «по структуре кодов» — каких строк (`ok`?);
  - пересчитывается ли `form_variant` после назначения кода — не сказано.
- **L-20.** «Форма записи знака по `text`» для `{38378)` не определена: `{` не принимается за открывающую скобку. Нужно «форма знака — по результату разбора: скобки / минус / без знака». Не сказано и то, входит ли сама ячейка в «большинство».
- **L-21.** `CODE_NOT_IN_EDITION` и `CODE_NOT_IN_DICTIONARY`: какая редакция берётся — по дате (`edition`) или выбранная LIS. Межениновская на бланке 66н в 2025 году получит `info` на 1120.
- **L-22.** В схеме `form_variant` не входит в `required`, хотя спека говорит «SHALL иметь». `OTHER` в 2.0 никогда не порождается (лист «прочее» → `SHEET_OTHER`, документа нет), но остался в enum и в правилах ядра.
- **L-23.** Сценарий arm-core «Два баланса в одном файле… ни один не автоподтверждается» безусловный. Правило Р-18/S-45 требует **того же периода**.
- **L-24.** Откат:
  - DBML (шапка v5.19) считает `crm_id` групп несовместимостью для `downgrade`, спека — нет;
  - `downgrade` неизбежно удаляет `is_confirmed`, `document_issue`, `header_source`, что противоречит «MUST NOT удалять данные молча». Сформулировать точно.
- **L-25.** Механика копии `arm_statements`:
  - `VERSION` лежит в копии, но его нет в дереве источника — исключить при сравнении;
  - зависимости пакета (PyYAML и др.) должны быть в `requirements.txt` хостов (зеркало банка);
  - `mypy` не поддерживает конфиг каталога копии: строгость хоста применяется к коду пакета, а править копию нельзя. Нужно требование «пакет проходит самый строгий конфиг хостов»;
  - `conftest` хоста может влиять на тесты пакета.
- **L-26.** «Шаг 1 — многостраничная форма» сформулирован для «каждого адаптера», но у OCR кандидат строится на каждую таблицу ИС, склейки нет. Явно ограничить требование Excel.
- **L-27.** `TABLE_LOST` — «таблица ИС с содержимым» без определения содержимого таблицы.
- **L-28.** `validate_contracts.py` пишет «не строка из 4 цифр», а регулярка допускает 5. Не проверяет, что число копий повтора совпадает с `repeats`.
- **L-29.** Сценарий 1.x в `recognition-contract` («обе строки кода — по прежнему правилу «остаётся первая»») читается двусмысленно.
- **L-30.** Значение с текстом без цифр и уверенностью 100 (`'I'@100` в строке без кода, aep_6 строка 38) не делает строку строкой данных и молча теряется. Это противоречит принципу «ничего не выбрасывать молча». Признать или включить в «содержимое».

## 3. Решения писателя

| S-n | Суть | Оценка | Обоснование |
|---|---|---|---|
| S-4 (утв., Р-22 / S-49) | Совпадение наименований | согласен с оговоркой (следствие) | Утверждено. Следствие на фикстурах: «Итого по разделу V1» у Счастливочной → `NAME_MISMATCH`; не задан `strip` (L-11). |
| S-5 (утв. с изм.) | Упрощённый набор, ОФР 2400 мягкое | согласен | Утверждено. В упрощённом ОФР нет ни одного жёсткого соотношения, покрытие только мягким точно — так и задумано. |
| S-7 (утв.) | Прочерк = пусто, `true` | согласен | Тире на месте цифры ловит §7. |
| S-10 (утв.) | `needs_review_fields` только для даты | согласен | Сформулировано одинаково во всех документах. |
| S-12 (утв.) | Ожидаемые даты + 31.12 | согласен с оговоркой | Замкнутость при отсутствии даты отчёта (L-18). |
| S-13 → S-40 | Детектор нумерации | согласен | Проверено на Межениновской (строки 24, 49) — нумерация распознаётся. |
| S-14 (утв.) | Признак повторной шапки | согласен | Не задано сопоставление колонок такого сегмента (L-6). |
| S-15 (утв. с ог.) | `ref`, `row_index`, экранирование листа | согласен | Примеры приведены к правилу. |
| S-17 → S-43/S-47 | Формат PATCH `lines` | согласен | — |
| S-19 (ог.) | Имена DBML, `codes`, `column_index` | согласен с оговоркой | `file_ordinal` уникален для всех документов, а спека задаёт его только формам (L-3). |
| S-20 (утв.) | `crm_id` уникален | согласен | Добавить в условия отката (L-24). |
| S-21 → S-36 | Значения по умолчанию 1.x | согласен с оговоркой | Полярность `needs_review` (L-9). |
| S-22 (утв.) | Статус ОСВ | согласен с оговоркой | Ядро `osvDocument.status` и `warnings` нигде не потребляет (L-4). |
| S-24 → S-26 | Редакция в сервисах | — | см. S-26. |
| S-25 (утв.) | Квартал → `NEEDS_CHECK`, `PERIOD_REQUIRED` | согласен | — |
| S-26 | Всегда обе редакции, дата решает ничью | согласен | Межениновская 66н-2025 иначе не подтвердилась бы. **Меняет смысл дизайна (выбор по дате), владельцем не утверждено.** |
| S-27 | Перечень в docs, байтовая копия в пакете | согласен с оговоркой | Дрейф перечня делает все хосты красными (L-8). |
| S-28 | Только коды с образцом | согласен с оговоркой | Старые бланки 66н (2421/2430/2450) с неуверенным кодом дадут `needs_review`; приемлемо при OQ-168. |
| S-29 | Выбор схемы по `$id` | не согласен | `recognition-request` (`$id` /v1, без `.v1`-файла), примеры и ядро не покрыты; на шаге 0 `.v1`-файлов ещё нет. Предложение — L-2: брать `.v1`, только если файл существует; правило для `examples/`; ядро в шаг 0. |
| S-30 | Механика `sync-statements` | согласен с оговоркой | `VERSION` в сравнении, зависимости, `mypy`-конфиг, код 20 при дрейфе перечня (L-8, L-25). |
| S-31 | `column_index` = столбец сетки | согласен с оговоркой | Нужно правило для сегментов со своей шапкой (L-6). Меняет смысл поля контракта — допустимо в MAJOR. |
| S-32 | `TABLE_PARSE_ERROR`, `SHEET_OTHER` — уровень файла | согласен | — |
| S-33 | `header_source` jsonb | согласен | — |
| S-34 | PATCH `organization_name` | согласен с оговоркой | Нужен, иначе `NO_ORGANIZATION_NO_INN` не снять. **Расширение функционала — не утверждено владельцем.** |
| S-35 | `RELATION_FAILED`/`RELATION_SOFT`, `codes` | согласен | — |
| S-36 | §7 один раз для 1.x и в миграции | согласен с оговоркой | Задним числом меняет подтверждаемость существующих форм; импорт живого пакета из Alembic (L-13). **Меняет смысл — не утверждено.** |
| S-37 | Строка правки ⇔ `row_index IS NULL` | согласен | Миграция корректна (маппер 3b всегда пишет `line_code_original_value`, `repositories/statements.py:80`). **Отступление от дизайна — не утверждено.** |
| S-38 | Вход функции статуса; `unreadable` без значений | согласен с оговоркой | Не решён вопрос `detail` в `needs_review` (L-1, critical). |
| S-39 | Столбец кодов ищется и у `DISCLOSURE` | согласен | — |
| S-40 | Детектор нумерации с двойниками и пропуском | согласен | Ложных срабатываний на фикстурах нет. |
| S-41 | `LINES_UNRESOLVED` — сумма или текст | согласен | Мусор на месте суммы требует разбора. **Расширяет Р-13 — не утверждено.** |
| S-42 | Подтверждение даты тем же значением | согласен с оговоркой | Нужен аналог для даты колонки (L-17). |
| S-43 | Имена (`LINE_CODE_TAKEN`, `period_date`) | согласен | — |
| S-44 | Откат | согласен с оговоркой | `crm_id` и неизбежная потеря новых колонок (L-24). |
| S-45 | «Тот же период» = (год, квартал) | согласен | Поправить безусловный сценарий (L-23). |
| S-46 | Единицы и ОКЕИ | согласен | — |
| S-47 | Пробелы PATCH; подтверждение не сбрасывает акцепт | согласен по существу | **Сужает правило Среза 3b «акцепт сбрасывается любой правкой» — ждёт владельца.** |
| S-48 | Страховка `done` → `RESULT_STATUS_INCONSISTENT` | согласен с оговоркой | Проверка уже функции статуса; предлагается вызывать саму функцию (L-12). **Ядро переопределяет статус сервиса — не утверждено.** |
| S-49 | Синонимы; «итого по разделу» — только равенство | согласен с оговоркой | Ломается на «Итого по разделу V1»; синонимы Р-20 и 1105 явно добавить в словарь (L-11). |
| S-50 | Толкование Р-21 | согласен | Проверено на РБ/Счастливочной: 2400/2410/2411/25xx покрываются мягкими точно. |
| S-51 | Ожидания на реальных сканах | согласен с оговоркой | Верно, только если значения `detail` держат статус; иначе 4 из 6 документов `done` (L-1). |
| S-52 | Манифест tabular-parser | согласен | Подтверждено разбором: строк `unreadable`/`missing` в Excel нет; страницы 2 ББ дают `1600 = 1700` с пустой целью. |

**Меняют смысл и ещё не утверждены владельцем:** S-26, S-34, S-36, S-37, S-41, S-47 (явно вынесено владельцу), S-48. Пограничные: S-31 (смысл поля контракта) и S-38 (`unreadable` без значений → `needs_check`, но подтверждение не блокирует).

## 4. Что проверил и признал согласованным

**Согласовано:**
- Поля контракта v2.0 ↔ DBML v5.19 ↔ маппинг `arm-core`: строки, значения, колонки, шапка (`header_source`, `*_original_value`), `document_issue` (`kind`/`code`/`severity`/`codes`/`column_id`/`column_index`/`field`), `statements_version`, `form_variant`, `needs_review_fields`.
- Условные требования схемы: `line_code` null ⇔ статус не `ok`; `parent_ref` у `detail`; `checks` у `BALANCE`/`INCOME` со строками; `statements_version` при наличии формы.
- Порядок 409 одинаков в спеке, §9.5 п. 4 и гайде фронта. Коды 422 одинаковы.
- Таблица предупреждений спеки и §11.9 совпадают по кодам и уровням.
- Миграция `row_index` согласуется с текущим кодом ядра.
- `sync-statements --check` на текущих данных пройдёт: все коды словаря ядра есть в перечне своей редакции. В обратную сторону в словаре нет 1231; 2530, 2930; 1105, 1130, 1140, 1530; 2460.
- Сценарии разбора кода и сумм («1220 ,», «| 140», «I1О0», «1 2О5», «(7744536}», «4,200», «42831 1») выводятся из правил. Исключения — «3450» (L-5) и «| : 122477» (L-7).
- Формат OpenSpec: MODIFIED в `recognition-contract` и `quality-checks` содержат полный текст с прежними сценариями, заголовки совпадают с `openspec/specs`. REMOVED нет, и он не нужен.
- Ручной прогон aep_3 и aep_6 подтверждает обещанное: `missing` «Выручка», `detail` «БАЛАНС» с нарушением `1600 = 1100 + 1200`, `unreadable` «44 30\nI |» без разлепления, законные повторы 1220/1520/2410 и раздел III НКО укладываются в перечни `fsbu4`/`66n`.

**Файлы:**
- `openspec/changes/unified-statement-normalization/proposal.md` и все `specs/*/spec.md`;
- `openspec/specs/recognition-contract/spec.md`, `openspec/specs/quality-checks/spec.md`;
- `docs/contracts/*.schema.json` (v2 и v1), `statement-code-orders.yaml`, `examples/*`, `examples/v1/*`, `scripts/validate_contracts.py` (запущен), `Makefile`;
- `context/05-domain-rules.md` §1.6, §7, §9.3–§9.5, §11–§12;
- `context/07-open-questions.md` (диф), `context/03-architecture.md` (диф);
- `model/data-model-v5.19.dbml` (диф к v5.18), `model/entities-v5.19.md` (диф);
- `dev/frontend-api-guide.md` §5.6.1, `dev/checks.md` (диф);
- файл решений `writer-decisions-2.md`.

**Код и данные:**
- `fixtures/ocr/*.json` (все таблицы aep_3, aep_6, РБ и Счастливочной за 1 кв. 2025) и `fixtures/ocr/expected_normalize/*`;
- манифест `tabular-parser/api/tests/statements_manifest.yaml` и все его Excel-файлы — прогоном через `read_book_detected`, `find_forms`, `find_layout`, `line_code` tabular-parser;
- tabular-parser: `api/rules/statement_checks.yaml`, `src/parser/statements/statement.py`, `book.py`, `grid.py`;
- scan-gateway: `src/normalizer/ocr/amounts.py`, `layout.py`;
- arm-core: `api/rules/statement_lines.yaml`, `src/schemas/files.py` (`JobBrief`), `src/services/documents.py:39-68`, `src/repositories/statements.py:80`, `src/schemas/statements.py:158`, `tests/test_contract.py:100-125`;
- тесты идентичности контракта сервисов (`tests/unit/test_contract.py`) и Dockerfile трёх репозиториев (`COPY api/` — копия пакета в образ попадёт).

Codegraph не использовал: нужные места знал точно, читал файлы напрямую.

Скрипты прогона лежат в `/private/tmp/claude-501/-Users-andrey-epifancev-projects-awp-ca/12de9a9a-5665-41d0-beea-0651270d88ec/scratchpad/rev3/`: `dump.py` (таблицы ИС), `cov.py` (покрытие §7 на OCR), `xl.py` и `xl2.py` (статусы строк и колонки Excel).