diff --git a/context/05-domain-rules.md b/context/05-domain-rules.md
index 6059607..994f12a 100644
--- a/context/05-domain-rules.md
+++ b/context/05-domain-rules.md
@@ -707,6 +707,8 @@ closing_* = closing_* строки Qn
 deviation_amount = |ΣA − ΣB|; deviation_percent = deviation_amount / min(ΣA, ΣB) * 100
 mode = min:    расхождение ≤ 5 % → элиминация_r = min(ΣA, ΣB); > 5 % → подсветка, элиминация_r = 0, ждёт корректировки
 mode = manual: элиминация_r = 0 — только корректировка / гудвилл (§8)
+mode = min_or_full (правило 2, DOC-274230; seed правится в AURORA-1546): обе стороны > 0 → min(ΣA, ΣB) без порога;
+               ΣB = 0 → ΣA; ΣA = 0 → 0; компании 2 — каскадом по строкам article_2_line (§8 «КФО», п. 4)
 ```
 **Знак** (решение владельца 23.10.2026): суммы сторон — **со знаком**, как в шахматке §6 (одно правило и одна пара дают
 одинаковые ΣA и ΣB на обоих экранах). Отрицательное сальдо строки (§1: возможно) — встречная позиция, например аванс или
@@ -941,7 +943,14 @@ OQ-145); тем же правилом сервисы разрешают ничь
 - **Контроль распределения** (`CorrectionBalanceOut`): `debit_total`/`credit_total` — суммы сохранённых статей;
   `difference`/`difference_percent` между ними, `remainder_1`/`remainder_2` — сумма стороны агрегата минус сохранённая
   статья. Это только отображаемый контроль — корректировку можно сохранить, даже если стороны не сошлись; в КФО по
-  выбранным статьям уходит меньшая сумма (ответ п. 8).
+  выбранным статьям уходит меньшая сумма (ответ п. 8): при заполненных обеих сторонах каждая исключает меньший из
+  итогов, снимая его со своих статей по порядку (блок «КФО», п. 5). Применённая корректировка **заменяет** автосумму
+  агрегата, а не прибавляется к ней.
+- **Автосумма агрегата** (`eliminated_amount`) — по режиму правила, **одной функцией домена с КФО** (блок «КФО», п. 4):
+  `min` — меньшая сторона в допуске, иначе 0; `manual` — 0; `min_or_full` (правило 2 после правки seed в AURORA-1546)
+  — меньшая сторона при обеих > 0, `amount_1` при пустой стороне 2, порога нет: `exceeds_threshold = false`, статус
+  `AUTO` при обеих сторонах, `ONE_SIDED` при пустой стороне 2 (`eliminated_amount = amount_1`). Сейчас
+  `services/correction_source.py` знает только `manual` и «остальное как `min`» — правится вместе с seed.
 - **Порог отклонения агрегата** (`exceeds_threshold`, не путать с контролем выше): `deviation_percent = |ΣA − ΣB| /
   min(ΣA, ΣB) × 100` сторон агрегата (§5, п. 1/2a); реализовано **строго больше 5 %** (R-35, `domain/corrections.py`,
   `arm-core#215`/Task 8) — ровно 5,00 % в допуске. ТЗ/DOC-272613 читались как «от 5 % включительно»; аналитик на это не
@@ -973,21 +982,183 @@ OQ-145); тем же правилом сервисы разрешают ничь
   тоже); в КФО — `Σ G > 0` строк, где `use_goodwill` = действующая ∧ отмечена ∧ доля и комментарий заполнены ∧ `G > 0`, и
   только при `consolidation_version.goodwill_enabled` (переключатель на вкладке, OQ-27). Доли в итогах не складываются;
   сумма заполненных долей разных ГО в одной ДО > 100 % — предупреждение, не ошибка.
-- **КФО** (AURORA-1546, ещё не реализовано): для пары с `use_goodwill` — ГО `1170 − ФВ`, ДО `1310 − P`, ГО строка
-  `GOODWILL` `+ G` (служебный код, ASSUMPTION OQ-37), обычный ББ-2 по этой паре не применяется; при `G ≤ 0` — обычный
-  ББ-2, разница в 1370 не переносится. Изменение ввода, переключателя или источников делает результат КФО устаревшим.
+- **КФО** — блок «КФО» ниже, п. 8: ветка гудвилла идёт по паре этой таблицы независимо от агрегатов корректировок;
+  у пары с `use_goodwill` — ГО `1170` на ФВ, ДО `1310` на P, строка `GOODWILL` на G, агрегат правила 2 той же пары не
+  применяется; при `G ≤ 0` или выключенном `goodwill_enabled` — обычный агрегат правила 2. Изменение ввода,
+  переключателя или источников делает результат КФО устаревшим.
 
-**КФО** (ТЗ 6.4, Прил. 10): по каждому коду строки ББ/ОФР:
-`sum_amount = Σ по компаниям` (значения отчётной колонки ББ / ОФР за период, в тыс. руб.) →
-`eliminated_auto` (Σ сумм элиминации троек, §5 п. 1; пересчёт в тыс. руб.) → `eliminated_manual = Σ correction APPLIED` → `goodwill_adjust` →
-`consolidated_amount`; `vgo_amount = eliminated_auto + eliminated_manual`; разрез `kfo_result_line_company` (`amount`,
-`share_percent` = доля компании в консолидированном показателе). Эталон колонок — `Консолидация_Группа РБ.xlsx`, лист
-`01.10.2024`: «значение на дату | в т. ч. взаимные обязательства | очищенные показатели | доля в показателе по группе».
+**КФО** (ТЗ 6.4, 6.8, Прил. 10; AURORA-1546 — расчёт, AURORA-1547 — экран, AURORA-1417 — пересчёт; ещё не реализовано;
+контракт — `dev/api-contract-kfo.md`). Источники, в порядке приоритета: DOC-274230 «Правила пар счетов» (Лысенко,
+27.10.2026), DOC-259025 «Гудвилл» (03.11), DOC-272613 «Корректировка данных агрегатом» (04.11); черновик команды
+DOC-274636 «Расчёт КФО» и DOC-274647 «Экран: КФО» — там, где страниц Лысенко нет (решение владельца 28.10.2026: страницы
+аналитика важнее черновика). Развилки, которые решает заказчик, закрыты вариантом черновика как стартовым и помечены
+OQ — менять по ответу.
 
-**Пороги** (ТЗ 6.8, FNR03 шаги 4–5), `kfo_result.threshold_*`:
-- ББ: если `1300 < 0.1 × 1600` → Σ расхождений ≤ 1 % × 1600 (ВБ), иначе ≤ 10 % × 1300 (ЧА).
-- ОФР: если `2200 / 2110 < 10 %` или отрицательна → ≤ 1 % × 2110 (выручка), иначе ≤ 10 % × 2200.
-Превышение → `threshold_justification` обязателен (принятие риска), подсветка.
+**Единицы.** Результат КФО хранится и отдаётся в **тыс. руб.** с двумя знаками. Суммы ОСВ и агрегатов — в рублях;
+в тысячи переводятся один раз — на ячейке «в т. ч. взаимные» (компания × строка, п. 6).
+
+1. **Строки.** Бланк ББ и ОФР — полный вариант (`full`) той редакции, которую ядро выбирает по **отчётной дате версии**
+   (§11.9: ≤ 31.12.2024 — `66n`, позже — `fsbu4`; перечни — `contracts/statement-code-orders.yaml`, наименования —
+   словарь имён ядра). Плюс служебная строка `GOODWILL` (п. 8). Выводятся все строки бланка, в том числе нулевые.
+   Строки форм компаний вне бланка и строки без кода в КФО не входят (решение 17.10.2026; предупреждение
+   `LINE_OUTSIDE_BLANK`). Перечень дополнительных строк FNR03 («ППА», «Износ ОС», «Дополнительная информация») — OQ-180.
+2. **«По данным клиента» (`client_amount`).** По каждой компании периметра (`consolidation_member`) — подтверждённый
+   (`CONFIRMED`) документ ББ / ОФР, привязанный к версии (`consolidation_document`). Колонка: ББ — на конец отчётного
+   квартала, ОФР — за период с начала года по конец квартала; по дате колонки, не по `is_current` (как УК гудвилла).
+   Строки со статусом `ok`; повторы кода суммируются. Единицы формы — словарём единиц `arm_statements` → тыс. руб.:
+   «тыс. руб.» — как есть, «руб.» — / 1000, «млн руб.» — × 1000, до двух знаков `ROUND_HALF_UP`.
+   - **Знак строк расходов.** Формы хранят расходы по-разному (§7, §11.9: скобки, минус или «без знака»). Строки
+     расходов бланка — **2120, 2210, 2220, 2330, 2350** — приводятся к одной конвенции: `client_amount = −|значение|`.
+     Остальные строки — как в форме (1370, 2300, 2400 и прочие бывают любого знака по существу).
+   - Нет формы → значения компании 0, `FORM_MISSING`; две и более подтверждённые формы одного типа → 0,
+     `FORM_AMBIGUOUS`; единицы не распознаны → 0, `FORM_UNITS_UNKNOWN`. Значение из ОСВ вместо формы — OQ-182.
+   - КФО считается и при неполном комплекте — по тому, что подтверждено и привязано (DOC-274636, допущение 17).
+3. **Агрегаты.** Взаимные суммы КФО берёт из **агрегатов таблицы корректировок** (§5 п. 2a, `VgoService`): тройка
+   (правило, компания 1, компания 2) с суммами сторон `amount_1`, `amount_2` (рубли) после ручных решений
+   `vgo_assignment`. Отдельного обхода ОСВ в КФО нет: что аналитик видит в таблице корректировок, то и вход КФО.
+   Нераспределённые строки ни в один агрегат не входят и в КФО не исключаются (`UNALLOCATED_ROWS` — число таких строк
+   без отметки «не учитывать в КФО»).
+4. **Исключения агрегата.** Каждый агрегат даёт список исключений `(компания, код строки, сумма в рублях ≥ 0)`. Есть
+   применённая корректировка (`APPLIED`) — п. 5, иначе **автосумма** по режиму правила (`elimination_rule.elimination_mode`):
+
+   | Режим | Автосумма | Куда |
+   |---|---|---|
+   | `min` (ББ 3–8) | `min(amount_1, amount_2)`, если обе стороны > 0 и отклонение в допуске (порог — блок «Корректировка», OQ-178); иначе 0 | `article_1_line` компании 1, `article_2_line` компании 2 |
+   | `min_or_full` (ББ 2) | обе стороны > 0 → `min(amount_1, amount_2)`; сторона 2 = 0 → `amount_1`; сторона 1 = 0 → 0; порога нет (DOC-274230, правило 2) | `article_1_line` компании 1; компании 2 — каскадом по `article_2_line` |
+   | `manual` (ББ 1) | 0 — только корректировка | — |
+   | режимы ОФР | по правилам ОФР (DOC-274230, AURORA-1999, §5); до неё агрегатов ОФР нет — `INCOME_RULES_MISSING` | по правилу |
+
+   **Каскад** (составная статья «a/b/c»): сумма снимается со строки `a` компании в пределах её доступного остатка
+   («по данным клиента» строки в рублях минус уже снятое с неё другими агрегатами, не ниже 0), остаток — со строки `b`,
+   затем `c`; не уместившееся — целиком на последнюю строку (DOC-274230: «если остаётся положительный остаток, он
+   исключается из строки 1370»). Агрегаты обходятся в порядке `rule_no`, затем ИНН компании 1, затем ИНН компании 2.
+
+   Seed правил ББ версии 1 (`arm-core/api/seed/core/elimination_rules_v1.yaml`, правка — в AURORA-1546, на месте, без
+   новой версии правил: верифицированных версий нет): правило 2 — `elimination_mode: min_or_full`,
+   `article_2_line: "1310/1350/1370"`. **Правило 1 остаётся `manual`**: по DOC-274230 обе его суммы — у компании 2
+   (Кт 76.7.1 − Дт 76.7.9 с каскадом 1150 → 1450 → 1550), а сторона агрегата устроена «компания 1 — сторона 1,
+   компания 2 — сторона 2»; автосумма правила 1 — после переработки seed (OQ-193), до того — корректировкой.
+
+   Автосумма — **одна функция домена** для таблицы корректировок и КФО (блок «Корректировка», `eliminated_amount`).
+5. **Корректировка заменяет автосумму.** Применённая корректировка агрегата отменяет его автосумму целиком и к ней не
+   прибавляется (DOC-274636, допущение 4; DOC-272613: корректировки не меняют суммы сторон). Исключения: компания 1 —
+   статьи `debit[]` (основная, затем дочерние), компания 2 — `credit[]`, суммы как введены. Если заполнены обе стороны
+   и их итоги разные, каждая сторона исключает **меньший** итог (ответ Лысенко п. 8): снимается со статей стороны по
+   порядку — основная, затем дочерние в порядке ввода — до исчерпания. Пустая сторона ничего не исключает, другая — как
+   введена (одностороннее правило 1, правила ОФР 1–3).
+6. **«В т. ч. взаимные» по компании (`vgo_amount`).** Σ исключений компании по строке в рублях → тыс. руб., **до целых
+   тысяч, половина — от нуля** (`ROUND_HALF_UP` по модулю), со **знаком строки**: у строк расходов (п. 2, они ≤ 0)
+   `vgo_amount` отрицательный. На всех строках одно равенство `cleaned_amount = client_amount − vgo_amount`; исключение
+   приближает значение к нулю (при превышении — проходит через ноль). Округление ячейки, а не каждой тройки и не «без
+   округления» — OQ-184.
+7. **Строка КФО.** По компании: `client_amount`, `vgo_amount`, `cleaned_amount`, `share_percent = cleaned / bank_amount
+   × 100` (хранится 4 знака, отдаётся 2; `bank_amount = 0` → `null`; бывает отрицательной и больше 100 %). По строке:
+   `sum_amount = Σ client`, `vgo_amount = Σ vgo по компаниям = eliminated_auto + eliminated_manual` (auto — от агрегатов
+   без корректировки и гудвилл-пар, manual — от агрегатов с корректировкой; по одному агрегату они **не складываются**),
+   `goodwill_adjust` (у `GOODWILL` и итогов, куда он входит), **`bank_amount = sum_amount − vgo_amount + goodwill_adjust`**
+   (`kfo_result_line.consolidated_amount`).
+
+   **Итоговые строки** (1100, 1200, 1300, 1400, 1500, 1600, 1700; 2100, 2200, 2300, 2400, 2500): «по данным клиента» —
+   итог из формы компании; «в т. ч. взаимные» — Σ `vgo_amount` слагаемых по формуле бланка с их знаками (1100 ←
+   1110…1190; 1600 ← 1100 + 1200; 1700 ← 1300 + 1400 + 1500; 2100 ← 2110 + 2120; 2200 ← 2100 + 2210 + 2220; дальше по
+   бланку); `goodwill_adjust` — Σ слагаемых (то есть G у 1100 и 1600); очищенные — разность. Итог КФО — подписанный
+   клиентом итог минус взаимные, а не сумма своих строк (OQ-183). Доли компаний у 1100/1600 в сумме меньше 100 % на долю
+   гудвилла — у него нет разреза по компаниям. `deviation_amount` у итоговых строк — `null`.
+8. **Гудвилл** (DOC-259025, блок «Гудвилл» выше). По паре ГО → ДО таблицы гудвилла с `use_goodwill` при
+   `goodwill_enabled` версии: исключения ГО `1170` на ФВ (все строки 58.01 и потомков пары, как в таблице гудвилла),
+   ДО `1310` на P (без каскада); G — в строку `GOODWILL`; агрегат правила 2 той же пары (компания 1 = ГО, компания 2 =
+   ДО), если он есть, **не применяется** — ни автосумма, ни корректировка. Строка 58.01 пары перенесена аналитиком в
+   другое правило или отмечена «не учитывать» — она всё равно в ФВ, предупреждение `GOODWILL_ROW_REASSIGNED` (ВГО по ней
+   может исключиться дважды, решает аналитик). Гудвилл включён, а применимых пар нет — `GOODWILL_NOT_APPLIED`.
+   Строка `GOODWILL` — раздел I, сразу после 1170, без разреза по компаниям; `goodwill_adjust = bank_amount = Σ G`
+   применимых пар, до целых тысяч; входит в 1100 и 1600; `kfo_result.goodwill_total` — то же значение. Место строки —
+   по DOC-259025 (отдельная строка раздела I); макет `[31-04]` показывает «В т.ч. Гудвилл» под 1170 — OQ-185.
+9. **Расхождения по статьям.** По агрегатам режима `min` (ББ и ОФР): `|amount_1 − amount_2|` — на статью стороны с
+   большей суммой (компания 1 — `article_1_line`, компания 2 — `article_2_line`), независимо от корректировок (OQ-186).
+   Агрегаты `manual`, `min_or_full` и гудвилл-пары в расхождения не входят. По строке — Σ в рублях → тыс. руб. до целых
+   (`deviation_amount`). `total_deviation_bb` / `total_deviation_ofr` — Σ по строкам бланка своего отчёта, без итогов;
+   `has_deviations` — хотя бы одна строка ≠ 0.
+10. **Контрольные пороги** (ТЗ 6.8, Методика пп. 5.1.2.4, 5.4; величины — КФО банка, тыс. руб.):
+    - ББ: ЧА = строка 1300 (как FNR03, OQ-187), ВБ = 1600. `ЧА ≥ 10 % ВБ` → база ЧА, предел 10 % ЧА; иначе (в том
+      числе ЧА ≤ 0) → база ВБ, предел 1 % ВБ.
+    - ОФР: `2200 ≥ 0` и `2200 / 2110 ≥ 10 %` → база 2200, предел 10 % 2200; иначе → база 2110, предел 1 % 2110.
+      `2110 = 0` → база 2110, предел 0 (OQ-188).
+    - Превышение — `total_deviation > предел`; равно — норма. Процент от базы — для сводки, база = 0 → `null`.
+    - Превышение хотя бы по одному отчёту → нужно обоснование принятия риска (`threshold_justification`). Обязательность
+      перед отправкой на верификацию (OQ-189, вариант черновика 2) проверяет переход статуса — AURORA-2002 / 1414.
+11. **Реквизиты формы** (ТЗ 6.4, DOC-274636 правило 9): ГК, ГСК, отчётная дата, номер и статус версии, сценарий,
+    подход (`approach` — пакет документов), гудвилл учтён да/нет и сумма, расхождения ББ/ОФР и превышения, обоснование,
+    корректировки — число агрегатов с применённой корректировкой и Σ их исключений по отчёту
+    (`kfo_result.corrections_count_bb/_ofr`, `corrections_amount_bb/_ofr`, тыс. руб.), причины отклонений от Методики
+    (`consolidation_version.methodology_deviations` — ввод на вкладке «КФО»), решение УОБ (номер и дата — только
+    чтение). «Подход по Методике» и «согласовано клиентом» — не делаем до ответа заказчика (OQ-190, OQ-191).
+12. **Пересчёт и заморозка.** Результат хранится у версии (`kfo_result`, одна запись). Пока версия не заморожена,
+    чтение отдаёт результат по текущим данным: если входы изменились после `computed_at`, сервер пересчитывает и
+    сохраняет до ответа (как обнаруживать изменения — AURORA-1417). Кнопки «Рассчитать» нет (OQ-192). Комментарии строк
+    и обоснование переносятся при пересчёте по (тип отчёта, код строки). При «Верифицирован» `is_frozen = true` (ставит
+    AURORA-2002) — дальше результат только читается. **Предупреждения** `{code, message, legal_entity_id?,
+    statement_type?, count?}` не блокируют расчёт; они и сводка корректировок — часть результата и **хранятся в
+    `kfo_result`** (`warnings`), чтобы замороженная версия отдавала то, что видели при верификации. Коды:
+    `FORM_MISSING`, `FORM_AMBIGUOUS`, `FORM_UNITS_UNKNOWN`, `LINE_OUTSIDE_BLANK`, `UNALLOCATED_ROWS`,
+    `INCOME_RULES_MISSING`, `GOODWILL_NOT_APPLIED`, `GOODWILL_ROW_REASSIGNED`. Правка ручных полей — аудит `KFO_EDIT`.
+
+**Пример** (тыс. руб., если не сказано иное; те же числа — в `examples` контракта). Три компании: А «Альфа», Б «Бета»,
+В «Гамма»; отчётная дата 01.10.2025 (ФСБУ 4). Агрегаты, рубли:
+
+| Агрегат | `amount_1` | `amount_2` | Что исключается |
+|---|---|---|---|
+| пр. 6, А → Б | 102 000 000,00 | 100 000 400,50 | отклонение 1,99 % — автосумма 100 000 400,50: А 1230, Б 1520 |
+| пр. 6, Б → А | 10 000 000,00 | 50 000 000,00 | 400 % — автосумма 0; корректировка Дт Б 1230 10 000 000, Кт А 1520 10 000 000 |
+| пр. 6, А → В | 30 000 000,00 | 29 100 000,00 | 3,09 % (автосумма была бы 29 100 000), но корректировка: Дт А 1230 20 000 000 + А 1170 5 000 000, Кт В 1520 22 500 000 — итоги 25 000 000 и 22 500 000, каждая сторона исключает 22 500 000: А 1230 20 000 000, А 1170 2 500 000, В 1520 22 500 000 |
+| пр. 2, А → Б | 50 000 000,00 | 40 000 000,00 | гудвилл-пара (ФВ 50 000 000, УК 40 000 000, d = 80 %, P = 32 000 000, G = 18 000 000): А 1170 50 000 000, Б 1310 32 000 000, `GOODWILL` 18 000; агрегат не применяется |
+| пр. 2, А → В | 15 000 000,00 | 0,00 | `min_or_full`, стороны 2 нет → 15 000 000: А 1170; у В каскад 1310 (есть 10 000 000) → 10 000 000, 1350 (3 000 000) → 3 000 000, остаток 2 000 000 → 1370 |
+| ОФР, А → Б | 10 000 000,00 | 10 000 000,00 | по правилам ОФР 1–2 (S без НДС): А 2110, Б 2120 |
+
+ББ (по компании: по данным клиента / в т. ч. взаимные / очищенные):
+
+| Строка | А | Б | В | КФО банка | Расхождения |
+|---|---|---|---|---|---|
+| 1170 | 70 000 / 67 500 / 2 500 | 0 / 0 / 0 | 0 / 0 / 0 | 2 500 | 0 |
+| `GOODWILL` | — | — | — | 18 000 | 0 |
+| 1100 | 70 000 / 67 500 / 2 500 | 0 / 0 / 0 | 0 / 0 / 0 | 20 500 (2 500 + гудвилл 18 000) | — |
+| 1230 | 520 000 / 120 000 / 400 000 (70,42 %) | 130 000 / 10 000 / 120 000 (21,13 %) | 48 000 / 0 / 48 000 (8,45 %) | 568 000 | 2 900 |
+| 1600 | 590 000 / 187 500 / 402 500 | 130 000 / 10 000 / 120 000 | 48 000 / 0 / 48 000 | 588 500 | — |
+| 1310 | 100 000 / 0 / 100 000 | 40 000 / 32 000 / 8 000 | 10 000 / 10 000 / 0 | 108 000 | 0 |
+| 1350 | 0 / 0 / 0 | 0 / 0 / 0 | 3 000 / 3 000 / 0 | 0 | 0 |
+| 1370 | 280 000 / 0 / 280 000 | −20 000 / 0 / −20 000 | 5 000 / 2 000 / 3 000 | 263 000 | 0 |
+| 1300 | 380 000 / 0 / 380 000 | 20 000 / 32 000 / −12 000 | 18 000 / 15 000 / 3 000 | 371 000 | — |
+| 1520 | 160 000 / 10 000 / 150 000 | 110 000 / 100 000 / 10 000 | 30 000 / 22 500 / 7 500 | 167 500 | 40 000 |
+| 1700 | 590 000 / 10 000 / 580 000 | 130 000 / 132 000 / −2 000 | 48 000 / 37 500 / 10 500 | 588 500 | — |
+
+- 1230 А: 100 000 400,50 + 20 000 000 = 120 000 400,50 руб. → 120 000 тыс. (округление ячейки); Б 1520 —
+  100 000 400,50 → 100 000. Корректировка Б → А заменила автосумму (0), а не прибавилась к ней; корректировка А → В —
+  тоже, хотя автосумма была бы 29 100 000.
+- Расхождения: 1 999 599,50 (А → Б) + 900 000 (А → В) = 2 899 599,50 руб. → 2 900 на 1230 А (сторона 1 больше);
+  40 000 000 → 40 000 на 1520 А (сторона 2 Б → А больше). Пары правила 2 в расхождения не входят. Всего ББ 42 900.
+- Порог ББ: ЧА 371 000 ≥ 10 % ВБ (58 850) → база ЧА, предел 37 100; 42 900 > 37 100 — **превышение** (11,56 % от ЧА),
+  нужно обоснование.
+- Сходимость: 1600 = 1700 = 588 500 (у ГО −ФВ, у ДО −P, гудвилл +G).
+- **Гудвилл выключен** (та же версия, `goodwill_enabled = false`): агрегат пр. 2 А → Б — `min_or_full` → 40 000 000;
+  А 1170 −40 000 (всего 57 500), Б 1310 −40 000 (каскад уместился в 1310); `GOODWILL` 0; 1600 = 1700 = 580 500;
+  ЧА 363 000, предел 36 300, превышение 11,82 %.
+
+ОФР (у Б 2120 в форме «без знака» +60 000 → приведено к −60 000; у В формы ОФР нет — `FORM_MISSING`, нули):
+
+| Строка | А | Б | В | КФО банка |
+|---|---|---|---|---|
+| 2110 | 200 000 / 10 000 / 190 000 | 80 000 / 0 / 80 000 | 0 / 0 / 0 | 270 000 |
+| 2120 | −120 000 / 0 / −120 000 | −60 000 / −10 000 / −50 000 | 0 / 0 / 0 | −170 000 |
+| 2100 | 80 000 / 10 000 / 70 000 | 20 000 / −10 000 / 30 000 | 0 / 0 / 0 | 100 000 |
+| 2200 | 50 000 / 10 000 / 40 000 | 15 000 / −10 000 / 25 000 | 0 / 0 / 0 | 65 000 |
+
+Σ `vgo_amount` строки 2100 = 10 000 − 10 000 = 0 — валовая прибыль группы не меняется. Порог ОФР: 65 000 / 270 000 =
+24 % ≥ 10 % → база 2200, предел 6 500; расхождений ОФР нет (агрегаты ОФР 1–2 — не `min`).
+
+**Прогон на «Русском бисквите»** (критерий AURORA-1546): версия на 01.10.2024 — бланк 66н (есть 1120, 1231, 2930;
+нет 1105, 1215, 2420), против листа `01.10.2024` эталона `Консолидация_Группа РБ.xlsx` (колонки «значение на дату |
+в т. ч. взаимные обязательства | очищенные показатели | доля в показателе по группе»). Ожидаемые расхождения с эталоном:
+алгоритм по ТЗ (min, порог 5 %), а эталон исключает каждую сторону полностью (OQ-155); ручные правки аналитика —
+показываются, не прячутся.
 
 **Сравнение с КФО клиента** (`scenario = CONFIRM`): `client_kfo_line` построчно: `client_amount`, `client_vgo_amount`
 (ручной ввод), `bank_amount`, `bank_vgo_amount` (из `kfo_result_line`), `deviation_percent` к наименьшему, причина.
diff --git a/context/07-open-questions.md b/context/07-open-questions.md
index b8cdb4c..1ae2dbc 100644
--- a/context/07-open-questions.md
+++ b/context/07-open-questions.md
@@ -183,3 +183,17 @@
 | OQ-175 | Процент расхождения шахматки при отрицательной меньшей стороне: `variance_pct = variance / min(amount_a, amount_b) * 100` при отрицательном сальдо (возможно по §1) уходит в минус — пара (100, −5) даёт −2100 %, порог > 5 % не срабатывает, пара не подсвечивается. Считать от `\|min\|`, от меньшей по модулю стороны или подсвечивать пары с разными знаками всегда? | ревью arm-core #165 (AURORA-1651), 22.10.2026 | §6, шахматка, xlsx | открыт; до решения — как в коде (min со знаком); у пар ВГО §5 суммы сторон тоже со знаком (решение владельца 23.10.2026), но при `min ≤ 0` процент не считается и тройка подсвечивается |
 | OQ-176 | Счёт `000` «Вспомогательный» (технический счёт 1С для ввода остатков, `kind = AP`, `is_off_balance = false`) входит в шахматку «все счета». Исключать его вместе с забалансовыми? | ревью arm-core #165 (AURORA-1651), 22.10.2026 | §6, режим «все счета» | открыт; до решения — входит (решение владельца 22.10.2026: не трогать) |
 | OQ-178 | Порог превышения отклонения агрегата в таблице корректировок — ровно 5 % в допуске (строго `>`) или на проверку («от 5 % включительно», как читается DOC-272613/ТЗ)? Аналитик (Лысенко) на прямой вопрос не отвечал | `dev/api-contract-corrections.md` §2; R-34/R-35 (`arm-core`, `openspec/changes/corrections-table-ui/design.md`) | §5 п. 2a, §8 «Корректировка», экран «Таблица корректировок» | открыт; реализовано строго `>` 5 % (R-35, `domain/corrections.py`) — фронт и сервер синхронны между собой, но не точно со спорным текстом ТЗ; правка при подтверждении — один оператор в `editorModel.ts`/`CorrectionTable.tsx` и в `domain/corrections.py` |
+| OQ-180 | Строки КФО вне бланка ФСБУ: нужны ли строки FNR03 «ППА», «Право пользования активами», «Износ основных средств», «Расхождение баланса по Активу и Пассиву», «Форма 0710002 с.2», «Дополнительная информация»? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 1; FNR03 (DOC-221276) | §8 «КФО» п. 1 | открыт, вопрос заказчику; допущение принято (docs #206): только бланк редакции на отчётную дату + строка `GOODWILL` |
+| OQ-181 | Состав колонок формы КФО: колонки макета `[31-04]` плюс расчётные «Расхождения» или ещё «КФО клиента» и ручные «Расхождения/Примечания», как в FNR03 и Прил. 10? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 2; макет `[31-04]`; ТЗ Прил. 10 | §8 «КФО» п. 7; `dev/api-contract-kfo.md` | открыт, вопрос заказчику; допущение принято (docs #206): колонки макета + «Расхождения» (расчётные); «Примечания» = «Комментарий»; КФО клиента — только на «Подтверждении КФО клиента» |
+| OQ-182 | Значение компании без подтверждённой формы ББ/ОФР: 0 с предупреждением, строки из ОСВ по счетам статьи (нужна таблица «строка ↔ счета») или КФО не считается? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 3; ТЗ Прил. 10 («Баланс (форма 01)» / «ОСВ»); `kfo_result_line.source_kind` | §8 «КФО» п. 2 | открыт, вопрос заказчику; допущение принято (docs #206): 0 и `FORM_MISSING`; `source_kind` всегда `balance` |
+| OQ-183 | Итоговая строка КФО (1100…1700, 2100…2500): по формуле бланка из очищенных строк или как итог формы клиента минус взаимные слагаемых? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 7 | §8 «КФО» п. 7 | открыт, вопрос заказчику; допущение принято (docs #206): итог формы клиента минус Σ взаимных слагаемых (совпадает с подписанным клиентом) |
+| OQ-184 | Округление рублей до тысяч: ячейка «в т. ч. взаимные» (компания × строка) после сложения, каждая тройка до сложения, без округления (тысячи с копейками) или банковское? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 8 | §8 «КФО» п. 6 | открыт, вопрос заказчику; допущение принято (docs #206): ячейка после сложения в рублях, до целых тысяч, половина от нуля |
+| OQ-185 | Место гудвилла в КФО: отдельная строка раздела I (DOC-259025, FNR03 «Заполнение поля Гудвил»), «В т.ч. Гудвилл» под 1170 (макет `[31-04]`) или строка 1105 бланка ФСБУ 4 (см. OQ-37)? | DOC-259025; DOC-274636, вопрос 9; макет `[31-04]`; ФСБУ 4/2023 | §8 «КФО» п. 8 | открыт, вопрос заказчику; допущение принято (docs #206): служебная строка `GOODWILL` раздела I после 1170, входит в 1100 и 1600, без разреза по компаниям; решают методологи |
+| OQ-186 | «Совокупный объём расхождений» для порога: разницы сторон всех пар как найдены, только пары без корректировки или остатки после корректировок? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 10; FNR03 шаг 4 | §8 «КФО» п. 9 | открыт, вопрос заказчику; допущение принято (docs #206): разницы сторон всех агрегатов `min` как найдены, независимо от корректировок |
+| OQ-187 | ЧА для порога ББ: строка 1300 КФО банка (FNR03) или расчёт по приказу Минфина № 84н (≈ 1300 + 1530)? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 11; ТЗ 6.8; Методика 5.1.2.4 | §8 «КФО» п. 10 | открыт, вопрос заказчику; допущение принято (docs #206): строка 1300 |
+| OQ-188 | Порог при нулевой базе (2110 = 0 или 1600 = 0): предел 0 (любое расхождение — превышение) или порог не применяется? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», допущение 12 | §8 «КФО» п. 10 | открыт, вопрос заказчику; допущение принято (docs #206): предел 0 |
+| OQ-189 | Что делает превышение порога: только подсветка, обязательное обоснование до отправки на верификацию, только до финала или блокировка верификации? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 13; DOC-037736 («НЕ ТОЧНО»); Excel В-01 | §8 «КФО» п. 10; AURORA-2002/1414 | открыт, вопрос заказчику; допущение принято (docs #206): обоснование обязательно до отправки на «Верификацию РФ/ГО» и до финала; проверяет переход статуса |
+| OQ-190 | «Подход» в реквизитах КФО: пакет документов (`approach` BASIC/EXTENDED, ТЗ 5.1) или подход по Методике (сноска 15: «по Методике / индивидуальный / принята аудированная отчётность»)? Для второго нужно новое поле версии | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 14 | §8 «КФО» п. 11 | открыт, вопрос заказчику; допущение принято (docs #206): показывается только `approach`; поле «подход по Методике» не заводим до ответа |
+| OQ-191 | Где фиксируется согласование КФО клиентом (Методика 5.8, 6.1): поле версии «да / нет / не направлялось» с датой или не вести в АРМ? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 15 | §8 «КФО» п. 11 | открыт, вопрос заказчику; допущение принято (docs #206): не ведём до ответа (вариант черновика — поле версии) |
+| OQ-192 | Пересчёт КФО: автоматически после каждого изменения (Excel Р-11, Р-23), по кнопке «Рассчитать КФО» с пометкой «устарела» (FNR03) или только при открытии? | DOC-274636 «Расчёт КФО» (черновик), «Что решить», вопрос 16; AURORA-1417 | §8 «КФО» п. 12 | открыт, вопрос заказчику; допущение принято (docs #206): автоматически: чтение пересчитывает устаревший результат, кнопки нет |
+| OQ-193 | Правило ББ 1 (76.7.1 / 76.7.9) автоматически по DOC-274230: обе суммы — у компании 2 (Кт 76.7.1 − Дт 76.7.9, каскад 1150 → 1450 → 1550), а сторона агрегата §5 устроена «компания 1 — сторона 1». Как переложить правило в seed (стороны, режим)? | DOC-274230 правило 1; `arm-core/api/seed/core/elimination_rules_v1.yaml` | §5 п. 1, §8 «КФО» п. 4 | открыт, задача команды (follow-up AURORA-1546); до решения правило 1 — `manual`, только корректировкой |