arm-core/openspec/changes/unified-normalization-core-a/design.md

Context

Сквозной дизайн — change docs unified-statement-normalization (design.md, specs/arm-core/spec.md, плана plans/2026-10-18-plan-3-arm-core.md). Здесь — решения уровня ядра для части А: где лежит код, как идёт миграция, какие допущения сделаны планом. Схема данных — ../docs/model/data-model-v5.19.dbml.

Goals / Non-Goals

Goals и Non-goals — см. proposal.md.

Decisions

• D-1. Часть А не зависит от пакета. До части Б §7 считается на лету по api/rules/statement_checks.yaml и агрегату формы по коду (P3-14); временный код удаляется в B6.
• D-2. Миграция только добавляет. Одна ревизия (0007): новые колонки, таблица, enum'ы, индексы и значения по умолчанию; §7 по существующим формам не пересчитывается (Р-24); откат останавливается на несовместимых данных (спека «Миграция DBML v5.19»).
• D-3. origin = template ⇔ row_index IS NULL. line_code_original_value IS NULL для origin больше не используется.
• D-4. Порядок A5 — последним (R-1).

Decisions made without discussion

Решения, принятые без обсуждения с человеком на этапе плана и исполнения части А (маркеры P3-n — из плана 3; R-n — рулинги контроллера; Р-n — решения владельца, поверх плана).

Дата	Решение	Обоснование	Цена ошибки
2026-10-18	P3-1. Миграция пишет header_source с ключами inn, report_date, units, organization_name: text — из inn_original_value, report_date_original_value, units_original_value, organization_name; confidence — inn_confidence у inn, у остальных null	спека: «из *_original_value и inn_confidence»; прочих полей в v5.18 сырыми нет	подсказка у поля старой формы беднее; формы старых времён на контуре удалены очисткой
2026-10-18	P3-2. organization_name_modified — false у всех форм (миграция и оба маппера), не NULL	как inn_modified в маппере 1.x; API отдаёт bool	одна строка UPDATE
2026-10-18	P3-3. needs_review_fields: маппер 1.x пишет [], миграция оставляет NULL, чтение NULL = []	спека миграции поле не заполняет	нет
2026-10-18	P3-4. Маппер 1.x тоже хранит вторую форму того же типа (Р-10); формы одного типа и одной пары period_year, period_quarter получают MAPPING_WARNING «в файле есть другая форма <тип> за тот же период» и по D-6 — NEEDS_CHECK (аналог Р-18)	частичный индекс v5.19 больше не заставляет пропускать; одно правило хранения для обоих MAJOR	O-1: если владелец хочет прежний пропуск — вернуть ветку continue
2026-10-18	P3-5. Предупреждения маппинга листа ОСВ (повтор счёта, строки без родителя, нарастающая по данным Q1) пишутся ещё и в document_issue документа листа (warning, MAPPING_WARNING, info, core) при любом MAJOR; строки в metrics.mapping_warnings остаются	спека: DocumentOut.issues ОСВ — «вместе с предупреждениями маппинга ядра этого листа»	нет
2026-10-18	P3-6. file_ordinal объединённого документа DISCLOSURE / OTHER — индекс первого такого документа в documents[]	несозданный документ «номер не занимает»	нет
2026-10-18	P3-7. Переопределено Р-40 (владелец, 18.10.2026): CODE_NOT_IN_DICTIONARY / CODE_NOT_IN_EDITION пишутся только для четырёхзначных кодов (пятизначные подстроки Excel не дают info; закрывает O-3). Остальное — как ниже. CODE_NOT_IN_DICTIONARY и CODE_NOT_IN_EDITION — одна запись на код документа (line_ids — все строки ok с кодом), пятизначные коды тоже проверяются; при приёме 1.x проверки ядра уровня info не пишутся	спека для 1.x перечисляет только §7 и MAPPING_WARNING	O-3 (поток info у пятизначных)
2026-10-18	P3-8. После правки записи core CODE_NOT_IN_DICTIONARY, CODE_NOT_IN_EDITION, NAME_MISMATCH и STATEMENTS_VERSION_MISMATCH пересчитываются (заменяются); NAME_MISMATCH не ставится строке с code_fixed; MAPPING_WARNING, RESULT_STATUS_INCONSISTENT, LEGACY_WARNING сохраняются	код строки меняется правкой; страховка статуса — факт приёма	O-4
2026-10-18	P3-9. Результат 2.0: значение с column_index вне колонок формы и повтор column_index колонки — первое остаётся, MAPPING_WARNING	FK значения на колонку; уникальность (meta_id, column_index)	нет
2026-10-18	P3-10. Части PATCH применяются в порядке lines → values → columns → header; вся адресация (422) проверяется до первой записи; UNKNOWN_CELL по line_code — по кодам строк ok с учётом назначений lines этого запроса; один line_id дважды в lines — 422 INVALID_LINE_PATCH	атомарность и предсказуемость	нет
2026-10-18	P3-11. reference_name — первое имя кода в редакции ответа (edition по дате); нет редакции или кода — null	спека: «первое имя кода в словаре»; edition ответа — по дате	нет (Р-29)
2026-10-18	P3-12. (= Р-35, решение владельца.) Очистка отказывает, только если документ формы упомянут в ex_snapshot_item или привязан к версии в статусе «Верифицирована» или дальше: VERIFIED или ARCHIVED с ex_snapshot.source_version_id = версия; привязки к версиям в работе, на согласовании, REJECTED, CANCELLED (и архивированным отменённым) снимаются, статус версий не меняется	решение владельца 18.10.2026 (Р-35): верифицированная версия read-only и заморожена в ЕХ, прочие — нет; на стенде версий дальше «в работе» нет	архивированная версия без снимка ЕХ (из CANCELLED) очистке не мешает — если бы мешала, владелец увидел бы лишний отказ
2026-10-18	P3-13. Коды выхода purge_statements.py: 0 — отчёт или выполнено, 1 — отказ (п. 2 спеки), 2 — ошибка аргументов	как у check_dbml_vs_orm.py	нет
2026-10-18	P3-14. До части Б §7 считает ядро на лету (statement_checks.yaml) по агрегату; checks.failed[].codes берутся из правила, line_ids — по агрегату	часть А должна быть самосогласованной	временный код удаляется в B6
2026-10-18	P3-15. Для условия RECOGNIZED 2.0 предупреждения файла берутся из metrics.warnings файла результата; в recognition_job.metrics.warnings — из конверта (inbox)	маппер читает файл результата; по контракту наборы одинаковы	нет
2026-10-18	P3-16. (= Р-34, решение владельца.) Подтверждение кода (lines[] {confirmed: true}) ставит is_confirmed = true и needs_review = false, line_code_confidence и line_code_modified не меняет; назначение кода — confidence = 100, line_code_modified = true	иначе исходная уверенность теряется, а снятие подтверждения не может вернуть needs_review (гайд §5.6.1: «при false — пересчитывается»); аналогия с ячейкой (is_modified не ставится); подтверждено владельцем 18.10.2026 (Р-34), спека arm-core, §9.5 п. 9 и гайд §5.6.1 приведены к этому	нет
2026-10-18	P3-17. Порядок строк ответа: строки ok (с шаблонными) — по коду, затем row_index (NULL последними), затем id; за каждой строкой ok источника — её «вложения» по row_index: строки detail с этим родителем и строки unreadable / missing / detail без родителя, у которых она — ближайшая предыдущая по row_index строка ok источника; вложения без такой строки — в начале	спека «Ответ GET …/statement»	нет
2026-10-18	P3-18. Уточнено Р-41 (владелец): смена crm_id пишется в аудит как изменение группы (GROUP_CHANGE) — закрывает O-6. Изменение crm_id ГСК/ГСЗ пишет одно событие GROUP_CHANGE с before/after всех изменённых полей вместо MEMBERSHIP_CHANGE	спека: «изменение — аудит GROUP_CHANGE»	O-6
2026-10-18	P3-19. Ядро зовёт у пакета choose_edition (engine.edition) и status_input_from_contract (engine.contract_document_status) вместо сборки StoredForm ради редакции и своего status_input_from_v2; to_contract ядру не нужен	одно правило с сервисом и с recompute (план 1, P1-25, P1-27); пары (код, уверенный) — из строк ok результата по row_index	при ошибке сборки пар редакция приёма разойдётся с редакцией после правки — тест B1 сравнивает их
2026-10-18	P3-20. header.source.<поле>.confidence — строка Decimal с двумя знаками ("61.54"), как прочие уверенности API; в JSONB header_source остаётся число как пришло	фронт читает все уверенности одним способом (план 6, A8)	округление до сотых в подсказке; исходное число — в БД
2026-10-18	P3-21. StatementHeaderOut.okei — из financial_statement_meta.okei (колонка есть с v5.18), только чтение; в PATCH header не входит	спека header контракта несёт okei, экран показывает issues с field = "okei" у поля	нет
2026-10-18	P3-22. Справочник строк для подсказки кода — поле StatementOut.edition_lines [{code, name}], а не отдельный эндпоинт: данные уже загружены (LineCatalog, A6) при сборке ответа, нет нового маршрута, права, кэша и запроса на фронте; около 80 пар на форму (≈ 4 КБ) против строк формы с значениями; у формы без даты — коды всех редакций, по одному	наименьший объём реализации в ядре и во фронте; закрывает пробел «у формы без даты подсказки нет» (план 6, O-3)	ответ GET тяжелее на ≈ 4 КБ; если понадобится справочник вне формы — отдельный эндпоинт поверх того же LineCatalog.edition_lines
2026-10-18	P3-23. DocumentBrief.issue_counts {error, info} — все записи document_issue документа (и relation / soft, в том числе акцептованные) по severity; один групповой запрос на файл	панели файлов нужен признак «есть что смотреть» без запроса на каждый документ (план 6, O-4)	акцептованное нарушение продолжает помечать документ в панели — подробности на экране документа
2026-10-18	P3-24. Ошибки элемента lines[] (409 LINE_CODE_TAKEN, 422 LINE_CODE_REQUIRED, INVALID_LINE_CODE, INVALID_LINE_PATCH, UNKNOWN_LINE) несут в detail line_id и line_code первого неверного элемента; LINE_CODE_REQUIRED добавлен к четырём кодам запроса фронта	экран ставит ошибку у поля нужной строки, не угадывая (план 6, O-2); одно правило для всех ошибок элемента	при нескольких неверных элементах фронт видит только первый — как и прежде
2026-10-18	R-1. Порядок исполнения части А: A0–A4, затем A6–A13; A5 (контракт 2.0, recognition_exchange.py) — последней, после слияния плана 0 (в origin/main нет api/tests/contract_identity.py)	A5 зависит от теста идентичности плана 0, остальные задачи его результат не потребляют	возможные конфликты слияния в documents.py / recognition_exchange.py при A5 в конце
2026-10-18	R-2. Исполнители задач и их ревьюеры — sonnet; финальное ревью ветки — opus	план даёт прозу, а не готовый код; ревью ветки ловит сквозные расхождения	более слабая модель на задаче — лишние итерации ревью
2026-10-18	R-3. Тесты с БД идут на scratch-БД armcore_pytest_* compose-Postgres :5432 (устройство conftest); контейнеры не останавливаются и не пересоздаются	общий стенд разработки не должен падать из-за прогонов	недоступный Postgres — задача BLOCKED, а не пропуск тестов
2026-10-18	R-4. A0 (только артефакты OpenSpec) без отдельного ревью сабагентом: достаточно openspec validate --strict	кода в задаче нет	неточность формулировок дельт; поймало финальное ревью
2026-10-18	R-5. Ревью A1 и A2 объединено в один пакет после A2	downgrade-тесты A1 проверяемы только с A2	находки по A1 пришли на один раунд позже
2026-10-18	R-6. Ревью малых задач объединялось парами (A3+A4, A8+A9, A10+A11, A12+A13)	экономия раундов ревью	находки по первой задаче пары приходят на шаг позже
2026-10-18	R-7. Change unified-normalization-core-a архивируется только вместе с unified-normalization-core-b; тексты поведения части Б в дельтах А остаются	разбор дельт на два change дороже и не нужен до выкладки обеих частей	если А заархивировать отдельно, openspec/specs опишет нереализованное
2026-10-18	R-8. Одна волна правок по итогам финального ревью (sonnet), затем один scoped re-review; M-6, M-8, M-13 не правятся (deferred / rejected)	замечания малы; M-13 (advisory-блокировки purge пофайлово) — окно обслуживания	M-6 (отдельный SUM для code_amount) и M-8 остаются техдолгом
2026-10-18	A1-1. result_mapping.map_file до A5/A9 присваивает file_ordinal порядковым номером создания документов	иначе uq_document_stored_file_id_file_ordinal ломает файл с 2+ документами	номера не равны индексу в documents[]; заменено в A9/A5
2026-10-18	A1-2. organization_name_modified — nullable boolean (как в DBML); миграция пишет false	соответствие DBML v5.19	нет
2026-10-18	A1-3. Тест-фабрика tests/factories.py и tests/test_models_part_04_06._document нумеруют file_ordinal	уникальность (stored_file_id, file_ordinal)	нет
2026-10-18	A1-4. Старый тест «две BALANCE с NULL -> IntegrityError» переписан под DISCLOSURE	по v5.19 для форм это больше не нарушение	нет
2026-10-18	A1-5. Имена FK/PK новых объектов (fk_financial_statement_value_confirmed_by_app_user, fk_document_issue_*, pk_document_issue) — по NAMING_CONVENTION	совпадают с create_all, тест схемы зелёный	нет
2026-10-18	A2-1. line_status считается потерянным при <> 'ok' (колонка NOT NULL default 'ok')	IS NOT NULL всегда истинно	шум в журнале отката
2026-10-18	A2-2. Булевы счётчики и organization_name_modified считаются как IS TRUE; причина отказа «наименование правилось» — organization_name_modified IS TRUE	NULL не считается правкой	нет
2026-10-18	A2-3. Причина «строки формы без кода» — по line_code IS NULL (любые), «повтор» — только по ненулевым кодам	точность причин отказа отката	нет
2026-10-18	A2-4. Сообщение журнала склеивает счётчики через ;	читаемость	нет
2026-10-18	A3-1. Только PATCH, меняющий crm_id, пишет GROUP_CHANGE (before/after всех изменённых полей запроса); PATCH только имени/даты остаётся MEMBERSHIP_CHANGE; создание — MEMBERSHIP_CHANGE с crm_id в payload	P3-18 / Р-41 про смену crm_id; минимум изменения поведения	фильтр аудита по действию для правок групп расходится; правка в одну строку
2026-10-18	A3-2. Предпроверка уникальности crm_id не учитывает видимость (глобальная уникальность), как для ГК	единый подход	crm_id невидимой группы раскрывает существование через 409 (как ГК/ЮЛ)
2026-10-18	A3-3. Before-payload удаления группы включает crm_id	полнота аудита	нет
2026-10-18	A4-1. run принимает подменяемую фабрику транзакции (по умолчанию session_transaction)	тесты идут на db_session	нет (боевой путь — по умолчанию)
2026-10-18	A4-2. PurgePlan несёт include_mixed; BlockingVersion по ex_snapshot_item имеет статус EX_SNAPSHOT_ITEM и version_id = ex_snapshot.source_version_id	сигнатура apply_purge без флага	нет
2026-10-18	A4-3. Проверка блокировки покрывает ВСЕ документы удаляемых целиком файлов (в том числе OSV/DISCLOSURE; OSV смешанных файлов с --include-mixed)	иначе удаление сломало бы FK/заморозку	лишний отказ, если OSV удаляемого файла в верифицированной версии (корректно: она заморожена)
2026-10-18	A4-4. apply_purge блокирует все файлы плана (jobs -> file -> documents, по id файла), перепланирует под блокировками и отказывает до первой мутации (PurgeRefusedError); версии блокируются позже (file -> doc -> version)	защита от гонки с загрузкой	окно между проверкой и блокировкой версий (T4.3, rejected)
2026-10-18	A4-5. Dry-run с блокировкой печатает блок отказа, но выходит с 0; --apply с блокировкой: отчёт в stdout, сообщение в stderr, код 1	P3-13: 0 = отчёт	нет
2026-10-18	A4-6. FILE_DELETE.after_value: для целого файла {unbound_version_ids}, для смешанного {deleted_documents, unbound_version_ids}	трассируемость очистки	нет
2026-10-18	A4-7. superseded_with_osv — файлы, у которых superseded_by_file_id указывает на удаляемый файл и которые содержат OSV	сохранение замещения ОСВ	нет
2026-10-18	A6-1. section_number возвращает строчные буквы (работает по нормализованному тексту)	внутренний формат	нет
2026-10-18	A6-2. names() — имена без повторов в порядке редакций и появления; edition_codes — по всем записям	стабильность подсказки	нет
2026-10-18	A6-3. Если «итого по разделу» только у одного из имён, номер у другого None — сравнение только по равенству строк	спека	нет
2026-10-18	A6-4. Пустые справочные имена пропускаются	шум	нет
2026-10-18	A5-1. FileWarning наследует DocumentWarning (есть также line_refs/column_index/field): схема fileWarning = warning + locator	надмножество брифа, без дублирования полей	нет
2026-10-18	A5-2. MetricsV2 наследует Metrics (переопределяет warnings); ветвление в _metrics_json идёт по классу конверта, не метрик	изоляция v1/v2 при общей базе метрик	v2-конверт обернул бы уже готовые структуры; покрыто test_inbox_v2_warnings_kept
2026-10-18	A5-3. parse_message/parse_result: не-2 MAJOR отдаётся модели v1, чей шаблон ^1\.\d+$ даёт ValidationError (3.0, «banana», нет поля); нечитаемый JSON в parse_result — json.JSONDecodeError (ValueError), не ValidationError	единая точка отказа для неподдерживаемых версий	вызывающий код, ждущий только ValidationError, пропустит ошибку чтения JSON (см. открытый вопрос)
2026-10-18	A5-4. У v2-предупреждения без locator в метрики пишется как пришло (ключа нет), у LEGACY — locator: None	не домысливать данные, не менять пришедшее	потребитель обязан читать locator как необязательный (file_warnings так и делает)
2026-10-18	A5-5. RecognitionResultMessageV2 не наследует v1; общие поля вынесены в _MessageBase	изоляция isinstance между версиями	нет
2026-10-18	A5-6. file_warnings: locator не-строка/не-null -> объект пропускается	защита от мусора во входящем конверте	потеря предупреждения с некорректным locator
2026-10-18	A6-5. Старые тесты API обновлены под код 1105 в fsbu4 (yaml дополнен 1105/1130/1140/1530/2460 и вторыми именами)	данные docs	для ГСК-кода 1105 на 66н с датой fsbu4 появляется пустая строка «Гудвил» (O-2 A6)
2026-10-18	A7-1. FailedCheck.codes — поле с default (), участвует в сравнении	P3-14	низкая
2026-10-18	A7-2. insert_statement до маппера 2.0 пишет row_index = порядковый номер строки черновика	иначе все строки источника стали бы origin = template	заменено в A9/части Б
2026-10-18	A7-3. checks_input принимает объекты-колонки (id, column_index) — протокол, без импорта моделей в домен	чистый домен	нет
2026-10-18	A7-4. code_amount: колонка — первая по column_index, затем SUM по ней; нет колонки или непустых — None	определённость суммы	M-6: отдельный SUM, deferred в часть Б
2026-10-18	A7-5. В API checks.failed[].codes и line_ids не выведены в A7 (только домен)	не в брифе A7	закрыто в A8
2026-10-18	A7-6. Порядок строк ответа в A7 не менялся	P3-17 — задача A8	нет
2026-10-18	A8-1. insert_statement временно пишет period_kind (absolute при дате, иначе none)	иначе тест брифа на 1.x не проходит до A9	заменено в A9; совпадает с backfill миграции
2026-10-18	A8-2. FailedCheckOut.line_ids — объединение line_ids агрегата по codes правила; у межформенной проверки — строки только читаемой формы	кода второй формы в агрегате нет	фронт не подсветит строку другой формы
2026-10-18	A8-3. header.source: запись с text: null отдаётся как есть, нечисловая уверенность -> null, не-dict записи пропускаются	T1.1: «нет подсказки»	нет
2026-10-18	A8-4. order_lines: detail с неизвестным родителем ведёт себя как detail без родителя; вложения по row_index; равные ключи — порядок входа (по id)	P3-17	нет
2026-10-18	A8-5. IssueCounts — dataclass репозитория, сервис переводит в IssueCountsOut	слои	нет
2026-10-18	A9-1. ColumnDraft вместо кортежа в StatementDraft.columns (несёт period_kind / label_confidence)	нужны поля колонки	правка 4 утверждений в тестах
2026-10-18	A9-2. header_source.*.confidence в БД — число как пришло из 1.x (float), не Decimal	JSONB; P3-20	нет
2026-10-18	A9-3. Повтор формы определяется только при известных годе и квартале у обеих; текст issue без префикса locator, в metrics.mapping_warnings — с префиксом	P3-4	нет
2026-10-18	A9-4. Пустая ячейка (нет значения) -> needs_review = false (value_clean(None, None) истинно)	формула приёма 1.x	нет
2026-10-18	A9-5. У листа ОСВ issue пишутся и для предупреждения о повторе счёта (относится к первому листу)	P3-5	нет
2026-10-18	A10-1. Контрагент UNKNOWN трактуется как None, блокирует только MISMATCH	спека: counterparty_check != MISMATCH	низкая
2026-10-18	A10-2. name_mismatches: строка ok с line_code_confidence = None считается уверенной (не проверяется); line_status сравнивается со StatementLineStatus.ok (StrEnum)	спека: «confidence < 100» (T10.1: покрыто комментарием и тестом)	строка без уверенности не даёт NAME_MISMATCH
2026-10-18	A10-3. has_error_warning: строго severity == "error" (регистр важен), не список -> False	строгий контракт	нет
2026-10-18	A10-4. noqa PLR0913 на form_status_v2 и тестовом хелпере	сигнатура задана планом	нет
2026-10-18	A11-1. Тест test_disclosure_is_confirmable удалён: form_blocker принимает meta, у расшифровки её нет; не-форма проверяется вызывающими (FORM_TYPES) — тест возвращён в волне правок (T11.1) на уровне сервиса	покрытие подтверждения DISCLOSURE/OTHER	нет
2026-10-18	A11-2. confirmed_twin при пустом периоде возвращает None (PERIOD_REQUIRED сработает раньше); первым выбирается близнец с меньшим file_ordinal	детерминизм	нет
2026-10-18	A11-3. Дубль ищется только среди CONFIRMED; второй NEEDS_CHECK-близнец не блокирует	бриф	нет
2026-10-18	A11-4. line_id в extra — строка (str(uuid)), как document_id	единообразие	нет
2026-10-18	A12-1. Новый код 422 DUPLICATE_COLUMN (колонка дважды в columns[])	в брифе не было	низкая
2026-10-18	A12-2. Подтверждение даты отчёта требует непустого report_date (null == null не подтверждение)	смысл подтверждения	низкая
2026-10-18	A12-3. Равное текущему organization_name — no-op	подтверждать нечего	нет
2026-10-18	A12-4. Снятие подтверждения ячейки и возврат суммы к исходной: needs_review = не(правлена	подтверждена	строка detail
2026-10-18	A12-5. recompute дополнительно сбрасывает needs_review у правленых/подтверждённых значений и значений строк detail (settle_edited_values)	согласованность флагов	T13.3: флаг навсегда false у значений detail (часть Б)
2026-10-18	A12-6. Подтверждение ячейки без записи значения в БД — 422 UNKNOWN_CELL до записей; колонка не этой формы в values[] — UNKNOWN_CELL, UNKNOWN_COLUMN — только для columns[]	существующий тест	нет
2026-10-18	A12-7. is_current пересчитывается только при смене дат колонок (самая поздняя дата, меньший column_index)	как при приёме	нет
2026-10-18	A12-8. Ключи аудита подтверждений: value:<id>:confirmed, column:<id>:date_confirmed, needs_review_fields; смена даты колонки — column:<id>	единый формат	нет
2026-10-18	A12-9. Смена report_date убирает report_date из needs_review_fields без отдельного ключа аудита	минимум шума	нет
2026-10-18	A12-10. lines[] в StatementPatch нет в A12 (добавлено в A13)	разбиение задач	нет
2026-10-18	A13-1. Тесты используют код 1215 вместо 1250 из брифа	1250 есть в источнике ББ Межениновской, а нужен «только шаблонный» код	нет
2026-10-18	A13-2. tests/test_api_statements.py::insert_line кладёт StatementLineStatus, а не строку	identity map сервиса	нет
2026-10-18	A13-3. Пометка шаблонной строки (row_index IS NULL) как detail — 422 INVALID_LINE_PATCH; подтверждение кода у строки не ok — тоже	спека такого перехода не перечисляет; у detail нужен row_index для родителя	низкая, фронт такого не шлёт
2026-10-18	A13-4. Назначение того же кода строке ok с этим кодом — no-op; detail -> detail — no-op	нечего менять, аудита нет	T13.1: no-op элемент может дать ложный 409 — недостижимо
2026-10-18	A13-5. Порядок проверок по элементам: действие, повтор, UNKNOWN_LINE, LINE_CODE_REQUIRED, INVALID_LINE_CODE, допустимость; затем отдельным проходом LINE_CODE_TAKEN (409 после всех 422)	предсказуемость	нет
2026-10-18	A13-6. needs_review при снятии подтверждения: ok и не line_code_modified и уверенность < 100	правило приёма 1.x; для 2.0 уточнит часть Б	нет
2026-10-18	A13-7. Назначение кода: confidence = Decimal("100.00") (ответ отдаёт объект сессии)	без перечитывания	нет
2026-10-18	A13-8. Удаление пустой шаблонной строки пропускается, если она сама — цель элемента запроса	избежать удаления цели	нет
2026-10-18	A13-9. Отступление от P3-10: 422 в values / columns после применённых lines откатывает всю транзакцию запроса; отдельной предпроверки адресации values для lines нет. UNKNOWN_CELL по line_code видит назначения lines этого запроса (они применены и flush-нуты раньше); 409 приоритетнее такого 422	эквивалентное наблюдаемое поведение при меньшем коде (T13.5)	при ошибке в откате частичная запись — тест M-10 фиксирует отсутствие записей и аудита
2026-10-18	A13-10. user_id в apply_line_edits принят по интерфейсу, не используется; аудит строк — ключ line:<id> с {line_code, line_status, parent_row_index, is_confirmed}, в него попадают и detail со сменой только родителя	у строки нет автора правки	нет
2026-10-18	A13-11. Пометка шаблонной строки как detail = 422 INVALID_LINE_PATCH	см. A13-3	низкая

Open questions

Вопросы владельцу (O-n из плана 3, не закрытые решениями Р-34 / Р-35 / Р-40 / Р-41; нумерация плана).

• O-1. Р-10 для 1.x (P3-4): вторая форма того же типа хранится и при 1.x (план) или пропускается, как раньше?
• O-3 (закрыт Р-40 для четырёхзначных). CODE_NOT_IN_DICTIONARY / CODE_NOT_IN_EDITION — только для четырёхзначных кодов; пятизначные подстроки Excel info не дают. Подтвердить, что сценарий спеки «Нестандартный код Excel» приведён к этому.
• O-4. Пересчёт проверок ядра уровня info после правки (P3-8) спека не описывает; после смены кода они не пересчитываются в части А (T13.4), пересчёт — в части Б.
• O-6 (закрыт Р-41). Смена crm_id ГСК/ГСЗ — GROUP_CHANGE.
• O-7. Конверт с неизвестным MAJOR (3.0) inbox отбрасывает с предупреждением в лог (задание закроется по сроку); сценарий «файл получает ERROR с mapping_error» выполняется для файла результата. Оставить?
• O-9. Выкладка: PR части А в main без снимка контура до части Б; встроенный фронт arm-core/web получает новые типы только через sync-web после плана 6.
• O-10. Метрики fields_* ядро не считает по строкам формы (копирует из конверта, recognition_exchange.FIELD_COUNTERS). Подтвердить, что спека («метрики fields_*») не требует нового расчёта.
• Наблюдение. Хранимая вторая ББ теперь входит в ключи автозамещения: файл с ББ на 30.09.2025 и ББ на 31.12.2024 может заместить более старый файл; его ОФР при этом выпадает с предупреждением OQ-154.
• A5-O1. parse_result на битом JSON бросает JSONDecodeError/UnicodeDecodeError, а не ValidationError: в части Б при переключении _load_result ловить ValueError.
• A5-O2. statement-code-orders.yaml не скопирован в api/contracts (тест идентичности его не покрывает); при необходимости ядру — скопировать в части Б.
• A5-O3. frontend-api-guide в docs должен описывать JobBrief.warnings как объекты (docs, план 6).
• Нумерация. Пропуски в нумерации O-n (O-2, O-5, O-8) закрыты планом/рулингами Р-n.