АДРЕСНЫЙ РЕЖИМ -ADDRESS:Шаг 1 - ЛЛМ ФЕРСТ + feat(address): стабилизация wave1 dynamic resolver контрагентов, follow-up carryover и актуализация docs/tests

2026-04-02 23:11:49 +03:00
parent 53716e548e
commit 88094c09f8
243 changed files with 94296 additions and 181 deletions
@@ -21,6 +21,8 @@

 Поддерживаемые intents в runtime:

+- `period_coverage_profile` (Wave-1 B1, pre-gate)
+- `document_type_and_account_section_profile` (Wave-1 B1, pre-gate)
 - `list_open_contracts`
 - `list_payables_counterparties`
 - `list_receivables_counterparties`
@@ -35,6 +37,7 @@
 Ключевой scope-лимит:

 - `COMPOUND_FACTUAL_QUERY` пока detection-only (без multi-intent execution).
+- `period_coverage_profile` и `document_type_and_account_section_profile` реализованы в коде, но еще не закрыты через domain live-gate Batch-1.
 - `account_turnover_snapshot` и `list_documents_by_type` не реализованы в runtime V1.

 ## Основные документы
@@ -50,6 +53,13 @@
 - `step0_preprod_rail_plan_v1.md` - обязательный pre-prod рельсовый этап перед массовым расширением доменов.
 - `step0_closeout_2026-04-02.md` - факт закрытия Step-0 с артефактами и gate-подтверждением.
 - `domain_expansion_implementation_plan_v1.md` - план `Step-4`.
+- `general_domain_questions_analysis_plan_v1_2026-04-02.md` - глубокий разбор общего домена (40 вопросов), route-модель и batch-план внедрения.
+- `management_route_probe_report_g1_2026-04-02.md` - live Batch-0 probe по первой группе общего домена (Q1–Q5) с route-верификацией через MCP/1С.
+- `complex_questions_status_and_reuse_map_2026-04-02.md` - сверка кода/доков по "сложным вопросам": что реализовано, что detection-only, и как переиспользовать в продуктовом плане.
+- `step4_wave1_batch1_master_checker_v1.md` - master checker первой волны Step-4 (`Q1..Q7 + Q28`) с go/no-go фазами.
+- `wave1_batch1_readiness_report_2026-04-02.md` - авто-отчет готовности к старту Batch-1.
+- `domain_general_batch1_foundation_card_v1.md` - domain card первой волны (Phase A).
+- `step4_wave1_batch1_phaseA_backlog_v1.md` - рабочий backlog по подготовке кода и gate-этапам Batch-1.
 - `domain_card_template_v1.md` - шаблон описания домена для repeatable delivery.
 - `domain_acceptance_question_set_template_v1.md` - шаблон структуры domain acceptance question set.
 - `run_pack_spec_v1.md` - обязательный формат run-артефактов и gate-валидации.
@@ -68,6 +78,7 @@
 - `python scripts/compare_address_run_summary.py --baseline-summary <baseline_run_summary.json> --candidate-summary <candidate_run_summary.json>`
 - `python scripts/run_address_nightly_regression.py`
 - `python scripts/run_address_nightly_regression.py --dry-run`
+- `python scripts/check_address_wave1_batch1_readiness.py`
 - `powershell -ExecutionPolicy Bypass -File .\scripts\run_address_nightly_regression.ps1`

 ## Связанные run-паки
@@ -0,0 +1,112 @@
+# Management Route Probe Report — General Domain Group 1 (Q1–Q5)
+
+- Дата/время запуска: `2026-04-02T19:55:56+03:00`
+- Endpoint: `http://127.0.0.1:6003`
+- Channel: `default`
+- Контур: `question_mode=address_query`, Batch-0 route probes
+
+## Вердикт по вопросам группы 1
+- Q1 (покрытие периодов): **PASS**
+- Q2 (самый активный год по документам): **PASS**
+- Q3 (самый активный месяц по операциям): **PASS**
+- Q4 (наиболее частые типы документов): **PASS**
+- Q5 (наиболее/наименее заполненные разделы учета): **PASS**
+
+## Q1 — Покрытие базы и активность по годам
+- Мин период: `2014-05-27T12:00:00Z`
+- Макс период: `2030-08-03T12:00:00Z`
+- Всего операций в регистре: `12659`
+- Годы с данными: `2014..2030` (уникальных лет: `13`)
+- Топ годов по количеству операций:
+  - `2015`: `3212`
+  - `2019`: `2273`
+  - `2018`: `2234`
+  - `2020`: `1391`
+  - `2017`: `1376`
+  - `2016`: `1187`
+  - `2021`: `553`
+  - `2014`: `235`
+
+## Q2 — Самый активный год по количеству документов
+- Метрика: `COUNT(DISTINCT Регистратор)` по годам на `РегистрБухгалтерии.Хозрасчетный`.
+- Топ годов:
+  - `2019`: `1004`
+  - `2018`: `703`
+  - `2015`: `671`
+  - `2016`: `577`
+  - `2020`: `536`
+  - `2017`: `456`
+  - `2021`: `308`
+  - `2014`: `115`
+- Вывод: route дает корректный ranking по документной активности в контуре движений.
+
+## Q3 — Самый активный месяц по количеству операций
+- Метрика: `COUNT(*)` по `НАЧАЛОПЕРИОДА(Период, МЕСЯЦ)`.
+- Топ месяцев:
+  - `2015-02`: `1249`
+  - `2015-01`: `924`
+  - `2018-08`: `854`
+  - `2019-05`: `536`
+  - `2017-12`: `503`
+  - `2020-06`: `305`
+  - `2020-03`: `297`
+  - `2019-09`: `273`
+  - `2018-11`: `261`
+  - `2015-12`: `225`
+  - `2018-12`: `213`
+  - `2019-08`: `185`
+
+## Q4 — Наиболее частые типы документов
+- Метрика: `COUNT(DISTINCT Регистратор)` по `ПРЕДСТАВЛЕНИЕ(ТИПЗНАЧЕНИЯ(Регистратор))`.
+- Топ типов:
+  - `Списание с расчетного счета`: `2352`
+  - `Поступление товаров и услуг`: `486`
+  - `Регламентная операция`: `414`
+  - `Поступление на расчетный счет`: `323`
+  - `Счет-фактура полученный`: `262`
+  - `Операция (бухгалтерский и налоговый учет)`: `147`
+  - `Реализация товаров и услуг`: `123`
+  - `Отражение зарплаты в регламентированном учете`: `87`
+  - `Приходный кассовый ордер`: `76`
+  - `Расходный кассовый ордер`: `73`
+  - `Требование-накладная`: `45`
+  - `Передача товаров`: `16`
+
+## Q5 — Заполненность разделов учета
+- Метод: агрегирование по первым двум цифрам кода счета (дебет + кредит).
+- Топ разделов:
+  - `90` `Продажи`: `2973`
+  - `51` `Расчетные счета`: `2967`
+  - `60` `Расчеты с поставщиками и подрядчиками`: `2793`
+  - `44` `Расходы на продажу`: `2422`
+  - `68` `Расчеты по налогам и сборам`: `1554`
+  - `10` `Материалы`: `1494`
+  - `19` `НДС по приобретенным ценностям`: `1490`
+  - `91` `Прочие доходы и расходы`: `1324`
+  - `41` `Товары`: `1312`
+  - `76` `Расчеты с разными дебиторами и кредиторами`: `1240`
+- Разделы с минимальной активностью (среди использованных):
+  - `58` `Финансовые вложения`: `2`
+  - `81` `Собственные акции (доли)`: `2`
+  - `80` `Уставный капитал`: `5`
+  - `75` `Расчеты с учредителями`: `16`
+  - `55` `Специальные счета в банках`: `18`
+  - `84` `Нераспределенная прибыль (непокрытый убыток)`: `20`
+  - `26` `Общехозяйственные расходы`: `51`
+  - `71` `Расчеты с подотчетными лицами`: `76`
+  - `43` `Готовая продукция`: `81`
+  - `50` `Касса`: `163`
+
+## Что подтверждено для продуктового плана
+- `R01 period_coverage_profile`: подтвержден (Q1/Q3).
+- `R02 document_type_usage_profile`: подтвержден (Q2/Q4).
+- `Q5` закрывается route-контрактом через account-section aggregation; нужна фиксация правила для "почти не используются" (порог/квантиль).
+
+## Ограничения и требования к точности
+- Q2/Q4 измеряются по `Регистратор` в движениях; это нужно явно закрепить как `movement-based document activity`.
+- Для Q5 нельзя опираться только на raw счета: обязателен post-processing `section = account_code[:2]`.
+- Есть записи с редкими/системными кодами (например off-balance); требуется whitelist/normalization policy для бизнес-отчета.
+
+## Следующий шаг Batch-0
+- Зафиксировать route contracts для `R01` и `R02` в runtime docs.
+- Добавить acceptance-вопросы Q1..Q5 в domain pack с жесткой проверкой метрик и сортировки.
@@ -31,6 +31,8 @@
 | AQ-P0-08 | Покажи документы по договору Y | `list_documents_by_contract` | `contract` | `period_from`, `period_to`, `as_of_date`, `organization`, `counterparty`, `limit`, `sort` | `DOCUMENT`, `DOCUMENT_JOURNAL`, `ACCOUNTING_REGISTER`, `NSI_CATALOG` | `address_documents_by_contract_v1` | `FACTUAL_LIST` | P0 |
 | AQ-P0-08B | Покажи банковские операции по договору Y | `bank_operations_by_contract` | `contract` | `period_from`, `period_to`, `as_of_date`, `organization`, `counterparty`, `limit`, `sort` | `DOCUMENT`, `DOCUMENT_JOURNAL`, `ACCOUNTING_REGISTER`, `NSI_CATALOG` | `address_bank_operations_by_contract_v1` | `FACTUAL_LIST` | P0 |
 | AQ-P0-09 | Какие документы формируют остаток по счету 62? | `documents_forming_balance` | `account` + `as_of_date` (`as_of_date` defaulted) | `organization`, `counterparty`, `contract`, `period_from`, `period_to`, `limit`, `sort` | `ACCOUNTING_REGISTER`, `DOCUMENT` | `address_documents_forming_balance_v1` | `FACTUAL_LIST` | P0 |
+| AQ-B1-10 | За какие годы/месяцы в базе есть активность? | `period_coverage_profile` | - | `period_from`, `period_to`, `organization`, `limit` | `ACCOUNTING_REGISTER` | `address_period_coverage_profile_v1` | `FACTUAL_SUMMARY` | B1 |
+| AQ-B1-11 | Какие типы документов чаще всего и какие разделы учета заполнены/пустые? | `document_type_and_account_section_profile` | - | `period_from`, `period_to`, `organization`, `limit` | `ACCOUNTING_REGISTER`, `DOCUMENT` | `address_document_type_and_account_section_profile_v1` | `FACTUAL_SUMMARY` | B1 |
 | AQ-P1-10 | Дай обороты по счету 51 за период | `account_turnover_snapshot` | `account`, `period_from`, `period_to` | `organization`, `counterparty`, `limit` | `ACCOUNTING_REGISTER`, `DOCUMENT` | - (not implemented) | `LIMITED_WITH_REASON` | P1 |
 | AQ-P1-11 | Дай список документов по типу за период | `list_documents_by_type` | `document_type`, `period_from`, `period_to` | `organization`, `counterparty`, `contract`, `limit` | `DOCUMENT`, `DOCUMENT_JOURNAL` | - (not implemented) | `LIMITED_WITH_REASON` | P1 |
 | AQ-P2-12 | Покажи технические константы конфигурации | `unsupported_for_v1` | - | - | `CONSTANT` | - | `LIMITED_WITH_REASON` | P2 |
@@ -50,6 +52,8 @@

 Реально реализованы в runtime:

+- `period_coverage_profile`
+- `document_type_and_account_section_profile`
 - `list_open_contracts`
 - `open_items_by_counterparty_or_contract`
 - `list_documents_by_counterparty`
@@ -0,0 +1,45 @@
+# Статус сложных вопросов и карта переиспользования (2026-04-02)
+
+Контур: `question_mode=address_query`
+
+## 1. Что реально есть в коде сейчас
+
+1. Сложная форма вопроса распознается:
+- `AddressQueryShape` содержит `COMPOUND_FACTUAL_QUERY`.
+- `classifyAddressQueryShape()` детектирует compound-сигналы.
+
+2. Но runtime multi-step исполнения нет:
+- `AddressIntent` в runtime ограничен P0-набором + `unknown`.
+- В `resolveAddressIntent()` нет management/P1 intent-ов (`account_turnover_snapshot`, `list_documents_by_type`, lifecycle/aging/risk intents).
+- В `addressRecipeCatalog.ts` нет recipe под сложные aggregate/comparative management-вопросы.
+- В `AddressQueryService` неизвестный intent уходит в `LIMITED_WITH_REASON` (`category=unsupported`), а не в multi-step plan execution.
+
+Итог: мы не "забили", а остановились на стабилизации P0 и рельсах; сложные вопросы остались в detection/design слое, но не доведены до execution слоя.
+
+## 2. Что уже можно переиспользовать без переписывания
+
+1. `Decompose -> Resolve -> Execute -> Compose` каркас уже рабочий.
+2. У нас есть зрелый debug-контракт (`reasons`, `limited_reason_category`, stage status), его можно сохранить и расширять.
+3. Follow-up context слой уже есть и пригоден для management-цепочек.
+4. Gate-механика Step-0 и nightly regression уже в прод-ритме.
+5. Для общего домена уже есть:
+- смысловая декомпозиция 40 вопросов;
+- route-модель `R01..R09`;
+- batch rollout (`B1..B5`);
+- live-подтверждение первой группы (`Q1..Q5`) через Batch-0 probe.
+
+## 3. Что усиливать в продуктовом плане
+
+1. Не внедрять домены "по одному интенту", а только batch-пачками с gate.
+2. Для каждого route фиксировать:
+- fact-источник (`movement` vs `document`);
+- ключи фильтрации (`*_Key`);
+- метрики и формулы;
+- правила сортировки и tie-break.
+3. Для сложных C4 вопросов сначала включить multi-step executor, потом запускать quality/risk домен.
+
+## 4. Ближайший практический путь
+
+1. Закрыть Batch-1 (`Q1..Q7`, `Q28`) на базе уже подтвержденных `R01/R02` + `R03` + часть `R07`.
+2. После Batch-1 перейти к lifecycle (Batch-2), не смешивая его с risk/аномалиями.
+3. Каждую пачку закрывать run-pack артефактами и обязательным comparator к baseline.
@@ -0,0 +1,41 @@
+# Contracts-By-Counterparty Fix Report (2026-04-02)
+
+## Problem (live repro)
+- Query `покажи договора все по жуковке 51` was not handled as a contract-list-by-anchor scenario.
+- Query often fell into wrong lanes (`list_documents_by_contract` with `missing_required_filters`, or broad fallback lists).
+
+## Implemented fixes
+1. Added dedicated intent: `list_contracts_by_counterparty`.
+2. Added dedicated recipe: `address_contracts_by_counterparty_v1` (contract catalog based).
+3. Added compose output branch for contract list answers.
+4. Updated decompose/filter/resolve/runtime to require and carry `counterparty` anchor for this intent.
+5. Improved loose anchor extraction for `по <anchor> <number>` (e.g. `по жуковке 51`).
+6. Prevented false `contract` extraction (`contract="все"`) for this intent.
+7. Disabled broad unrelated fallback for doc/bank intents when anchor is not matched (`filterByAnchors` guard).
+8. Added historical-window recovery for doc/bank anchor lookups (retry with ascending period sort when all-time latest slice misses old anchors).
+9. Added short follow-up year parsing (`теперь за 21` -> `2021-01-01..2021-12-31`).
+10. Added dynamic counterparty resolver via live 1C catalog (`Справочник.Контрагенты`) without hardcoded client dictionaries:
+   - anchor canonicalization now happens before main recipe execution;
+   - resolved value is stored in `anchor_value_resolved`;
+   - extraction `raw` value is preserved in `anchor_value_raw`;
+   - catalog list is cached for 2 minutes to avoid repeated latency.
+
+## Validation
+- Unit tests: `tests/addressQueryRuntimeM23.test.ts` -> 163/163 passed.
+- Build: `npm run build` -> passed.
+- Targeted live run:
+  - run id: `Address_Contracts_Zhukovka_Targeted_AfterFix_2026-04-02_v3`
+  - semantic pass: 3/3
+  - route pass: 2/3
+  - factual pass: `покажи договора по свк` and `покажи договора все по жуковке 51`
+  - docs query `покажи документы все по жуковке 51` now returns clean `empty_match` (no broad unrelated fallback list)
+- User repro validation run:
+  - run id: `Address_UserRepro_Followup_Zhukovka_AfterFix_2026-04-02`
+  - `покажи заказчиков за 20 год` -> factual (2020)
+  - `теперь за 21` -> factual with extracted period `2021-01-01..2021-12-31`
+  - `покажи доки по жуковке за все время` and `...жуковке 51...` -> factual via historical-window recovery (2017 row found)
+
+## Current status
+- Contract-list route is implemented and operational.
+- `жуковке 51` is now canonicalized to the real counterparty from 1C catalog (`ТСЖ \Жуковка 51\`) in runtime without static dictionaries.
+- Remaining accuracy risk is generic ambiguity for very short anchors (when multiple counterparties fit equally); this now degrades safely via low-confidence/ambiguous resolver path.
@@ -255,3 +255,21 @@ Core metrics:
 2. Для каждого домена есть полный комплект артефактов (docs + question set + run artifacts).
 3. Global baseline-паки не деградируют после каждого включения.
 4. `global_execution_checklist_v1.md` отражает актуальный финальный статус.
+
+## 13. Wave-1 Kickoff Status (2026-04-02)
+
+Первая волна расширения (`Batch-1: Q1..Q7 + Q28`) переведена в управляемый стартовый режим:
+
+1. Master checker:
+- `step4_wave1_batch1_master_checker_v1.md`
+
+2. Авто-checker готовности:
+- `scripts/check_address_wave1_batch1_readiness.py`
+- отчет: `wave1_batch1_readiness_report_2026-04-02.md`
+
+3. Phase A артефакты:
+- `domain_general_batch1_foundation_card_v1.md`
+- `domain_general_batch1_acceptance_2026-04-02_phaseA.json`
+- `step4_wave1_batch1_phaseA_backlog_v1.md`
+
+Текущее решение: `READY_FOR_PHASE_A` (можно начинать по фазам, без прямого включения Batch-1 intents в production-path до закрытия Phase B/C gate).
@@ -0,0 +1,154 @@
+# Domain Card — general_batch1_foundation V1
+
+Дата: `2026-04-02`  
+Домен: `general_batch1_foundation`  
+Статус: `active` (Phase A prepared, Phase B runtime intents implemented, Phase C pending)  
+Владелец: `Address Runtime Team`
+
+## 1. Scope
+
+Кратко: домен закрывает стартовый управленческий слой общего домена (`Q1..Q7 + Q28`) без multi-intent и без quality/risk аналитики.
+
+In-scope intents:
+
+1. `period_coverage_profile` (`Q1`, `Q2`, `Q3`)
+2. `document_type_and_account_section_profile` (`Q4`, `Q5`)
+3. `counterparty_population_and_roles` (`Q6`, `Q7`)
+4. `contract_usage_overview` (`Q28`)
+
+Out-of-scope:
+
+1. lifecycle/cohort (`Q8+`)
+2. revenue/supplier/aging/risk блоки (`Q14+`, `Q33+`, `Q39+`)
+3. `COMPOUND_FACTUAL_QUERY` multi-step execution
+
+## 2. Intent Contract
+
+### 2.1 `period_coverage_profile`
+
+- `query_shape`: `FACTUAL_SUMMARY`
+- `required_filters`: `[]`
+- `optional_filters`: `[period_from, period_to, organization, limit]`
+- `resolver_signals`: `годы`, `периоды`, `самый активный год`, `самый активный месяц`
+- `ambiguity_rules`: если вопрос содержит одновременно `год` и `месяц`, приоритет у `месяц`-ранжирования
+- `fallback_policy`: при пустом окне периода разрешен controlled broaden до доступного окна с явным пояснением
+
+### 2.2 `document_type_and_account_section_profile`
+
+- `query_shape`: `FACTUAL_SUMMARY`
+- `required_filters`: `[]`
+- `optional_filters`: `[period_from, period_to, organization, limit]`
+- `resolver_signals`: `типы документов`, `чаще всего документы`, `разделы учета`, `заполнены/не используются`
+- `ambiguity_rules`:  
+  `типы документов` -> профиль типов;  
+  `разделы учета` -> профиль sections (первые 2 символа кода счета, дебет+кредит)
+- `fallback_policy`: только внутри intent; не переключать на `period_coverage_profile`
+
+### 2.3 `counterparty_population_and_roles`
+
+- `query_shape`: `FACTUAL_SUMMARY`
+- `required_filters`: `[]`
+- `optional_filters`: `[period_from, period_to, organization, limit]`
+- `resolver_signals`: `сколько контрагентов`, `сколько заказчиков`, `сколько поставщиков`, `типы контрагентов`
+- `ambiguity_rules`: роль `customer/supplier/mixed` определяется по account/direction сигнатуре, не по свободному тексту
+- `fallback_policy`: при неоднозначной роли возвращать `mixed/unknown` bucket с пояснением, без ложной категоризации
+
+### 2.4 `contract_usage_overview`
+
+- `query_shape`: `FACTUAL_SUMMARY`
+- `required_filters`: `[]`
+- `optional_filters`: `[period_from, period_to, organization, limit]`
+- `resolver_signals`: `сколько всего договоров`, `сколько использовались`, `мертвые договоры`
+- `ambiguity_rules`: `used` считается только при наличии factual связи договора с движением/документом
+- `fallback_policy`: если нет стабильной связи на ключах, вернуть `LIMITED_WITH_REASON` (`recipe_visibility_gap`)
+
+## 3. Recipe Mapping
+
+Связка `intent -> recipe_id` должна совпасть с runtime catalog после Phase B.
+
+| intent | recipe_id (runtime/planned) | mcp_method | expected_statuses |
+| --- | --- | --- | --- |
+| `period_coverage_profile` | `address_period_coverage_profile_v1` (runtime) | `POST /api/execute_query` | `matched_non_empty`, `no_raw_rows` |
+| `document_type_and_account_section_profile` | `address_document_type_and_account_section_profile_v1` (runtime) | `POST /api/execute_query` | `matched_non_empty`, `no_raw_rows`, `materialized_but_not_matched` |
+| `counterparty_population_and_roles` | `address_counterparty_population_roles_v1` (planned) | `POST /api/execute_query` | `matched_non_empty`, `materialized_but_not_matched`, `no_raw_rows` |
+| `contract_usage_overview` | `address_contract_usage_overview_v1` (planned) | `POST /api/execute_query` | `matched_non_empty`, `recipe_visibility_gap`, `no_raw_rows` |
+
+## 4. Anchor and Resolver Rules
+
+- `anchor_type`: `period`, `organization` (в Batch-1 нет обязательного party anchor)
+- `anchor_resolution_order`: explicit period -> organization -> default all-time
+- `min_confidence`: `medium`
+- `unresolved_behavior`: при неразрешенном required-filter (если появится в реализации) -> `LIMITED_WITH_REASON`, без псевдо-factual
+
+## 5. Limited Reasons (taxonomy)
+
+Разрешенные категории для домена:
+
+1. `empty_match`
+2. `recipe_visibility_gap`
+3. `execution_error`
+4. `unsupported`
+
+Запрещено:
+
+- выдавать factual при неподтвержденной метрике;
+- смешивать `operations` и `documents` в одной метрике без явной оговорки.
+
+## 6. Test Coverage
+
+Unit:
+
+1. resolver intent positives/negatives для 4 интентов Batch-1
+2. extraction period filters (`YYYY`, `YYYY-MM`, `YYYY-MM-DD`)
+3. role-split classifier tests (`customer/supplier/mixed`)
+4. account-section parser tests (`code[:2]`)
+
+Integration:
+
+1. recipe selection per intent
+2. execution status mapping
+3. debug payload completeness
+
+Live acceptance:
+
+1. canonical questions
+2. noisy/slang questions
+3. follow-up chains
+
+## 7. Gate Criteria
+
+Domain gate:
+
+- `strict_pass(route)=100%`
+- `false_factual_rate=0`
+- `execution_error_rate=0`
+
+Global gate:
+
+- baseline stress `102/102` сохраняется
+- baseline follow-up `25/25` сохраняется
+
+## 8. Rollout Plan
+
+1. `shadow` — прогоны без влияния на production answer path.
+2. `soft-enable` — включение под feature-flag только для Batch-1 intents.
+3. `prod` — после green domain gate и global non-regression gate.
+
+## 9. Artifacts
+
+Обязательные артефакты:
+
+1. `domain_general_batch1_foundation_card_v1.md`
+2. `question_sets/domain_general_batch1_acceptance_2026-04-02_phaseA.json`
+3. `runs/<run_id>/run_summary.json`
+4. `runs/<run_id>/full_live_results.json`
+5. `runs/<run_id>/failures_only.json`
+6. `runs/<run_id>/README.md`
+
+## 10. Change Log
+
+- `2026-04-02` — создана карточка домена для Batch-1 новой волны (Phase A).
+- `2026-04-02` — синхронизирован runtime status Phase B.1: в коде реализованы `period_coverage_profile` и `document_type_and_account_section_profile`.
+- `2026-04-02` — реализованы `counterparty_population_and_roles` и `contract_usage_overview`; targeted live-pack `Q6/Q7/Q28` прошел `strict factual 9/9` (`2026-04-02_Address_Batch1_NextPack_Q6_Q7_Q28`).
+- 2026-04-02 - hotfix slang count routing: скока/скок поставщиков|заказчиков стабильно маршрутизируются в counterparty_population_and_roles; targeted live-pack 2026-04-02_Address_SupplierCount_Targeted_AfterFix прошел strict factual 4/4.
+- 2026-04-02 - hotfix follow-up slang variant: скок клиентов now maps to counterparty_population_and_roles; targeted live-pack 2026-04-02_Address_SupplierClient_Followup_AfterFix passed strict factual 3/3.
@@ -0,0 +1,444 @@
+# Общий Домен Вопросов — Анализ и План Внедрения V1
+
+Дата: 2026-04-02
+Источник: `docs/ADDRESS/TEMP/ОБЩИЙ_ДОМЕН_ВОПРОСОВ.md`
+Контур: `question_mode=address_query`
+
+## 1. Ключевой вывод по текущему состоянию
+
+1. Текущий runtime хорошо закрывает P0 address lookup/drilldown, но не закрывает управленческие агрегаты из общего домена.
+2. Вопросы из общего домена требуют не только фильтрации, но и устойчивых агрегатов, ранжирования, cohort/lifecycle логики и сравнений между выборками.
+3. Для точного забора данных нужен переход от текстовых anchor-match паттернов к key-based маршрутам (`*_Key`) и явным group-by query templates.
+4. Для части вопросов нужен multi-step execution (сейчас `COMPOUND_FACTUAL_QUERY` только detection-only).
+
+## 2. Разбор 40 вопросов по смысловым группам
+
+### G1. Профиль данных и активности (Q1–Q5)
+Суть: «что есть в базе», активность по годам/месяцам, типы документов, заполненность контуров.
+
+Сложность:
+- C1: Q1, Q2, Q3, Q4
+- C2: Q5
+
+### G2. Контрагенты и жизненный цикл базы (Q6–Q13)
+Суть: численность, роли, активность в периоде, новые/ушедшие, одноразовые, долгоживущие.
+
+Сложность:
+- C1: Q6, Q7, Q8, Q9
+- C3: Q10, Q11, Q12, Q13
+
+### G3. Клиентская ценность, выручка, оплаты (Q14–Q21)
+Суть: вклад клиентов в деньги/частоту/средний чек, концентрация выручки.
+
+Сложность:
+- C2: Q14, Q15, Q16, Q17, Q18, Q19, Q20
+- C3: Q21
+
+### G4. Поставщики и выплаты (Q22–Q27)
+Суть: ключевые/малозначимые поставщики, частота операций, регулярность, неактивные.
+
+Сложность:
+- C2: Q22, Q23, Q24, Q25
+- C3: Q26, Q27
+
+### G5. Договорная база (Q28–Q32)
+Суть: total vs used, активность по суммам/документам, stale договоры, мультидоговорность контрагентов.
+
+Сложность:
+- C2: Q28, Q29, Q30
+- C3: Q31, Q32
+
+### G6. Дебиторка/кредиторка и хвосты (Q33–Q38)
+Суть: top debtors/creditors, старение долгов, сравнение проблемности customer vs supplier контуров.
+
+Сложность:
+- C2: Q33, Q36
+- C3: Q34, Q35, Q38
+- C4: Q37
+
+### G7. Качество учета и риск-аномалии (Q39–Q40)
+Суть: подозрительные/неполные документы, разрозненные кейсы с высокой активностью.
+
+Сложность:
+- C4: Q39, Q40
+
+## 3. Уровни сложности (для реализации пачками)
+
+- C1: одношаговый aggregate/list по одной fact-проекции.
+- C2: агрегат + период/роль + ранжирование top/bottom.
+- C3: lifecycle/cohort и/или временные сравнения с вычислением first/last activity.
+- C4: multi-step comparative и quality-scoring (несколько подзапросов + сводка).
+
+## 4. Маршруты данных 1С (target route set)
+
+Ниже маршруты в терминах «что нужно строить» для точного забора данных.
+
+### R01. `period_coverage_profile`
+Назначение: Q1–Q3.
+
+Source objects:
+- `РегистрБухгалтерии.Хозрасчетный`
+- `Документ.*` (для проверки активности по документным датам)
+
+Key metrics:
+- min/max дата в фактах
+- count операций по годам
+- count операций по месяцам
+
+Output:
+- покрытие периодов
+- топ активный год/месяц
+
+### R02. `document_type_usage_profile`
+Назначение: Q4, часть Q5.
+
+Source objects:
+- `ДокументЖурнал.*`
+- `Документ.*`
+
+Key metrics:
+- count документов по `Recorder_Type`/типу документа
+- доля каждого типа
+
+Output:
+- рейтинг типов документов
+- профиль заполненности контуров по типам
+
+### R03. `counterparty_population_and_roles`
+Назначение: Q6, Q7.
+
+Source objects:
+- `Справочник.Контрагенты`
+- факты движения/документы для определения роли в деятельности
+
+Key metrics:
+- total уникальных контрагентов
+- active контрагенты
+- распределение customer/supplier/mixed
+
+Output:
+- сводка по размеру и структуре базы контрагентов
+
+### R04. `counterparty_activity_lifecycle`
+Назначение: Q8–Q13, Q26–Q27.
+
+Source objects:
+- `РегистрБухгалтерии.Хозрасчетный` (через контрагентные аналитики)
+- `Документ.*` банковых контуров
+
+Key metrics:
+- first_activity_date
+- last_activity_date
+- ops_count
+- active_year_flags
+
+Output:
+- active in year/all-time
+- new/lost counterparties
+- one-time counterparties
+- longest-running counterparties
+- regular vs episodic, stale entries
+
+### R05. `customer_revenue_and_payments`
+Назначение: Q14–Q21.
+
+Source objects:
+- `Документ.ПоступлениеНаРасчетныйСчет`
+- `РегистрБухгалтерии.Хозрасчетный` (в т.ч. account 62/76 для customer-контура)
+
+Key metrics:
+- total_inflow_by_counterparty
+- payment_ops_count
+- avg_check
+- max_single_payment
+- revenue_share
+
+Output:
+- top/bottom customers
+- частота оплат
+- средний чек
+- концентрация выручки
+
+### R06. `supplier_payouts_profile`
+Назначение: Q22–Q25.
+
+Source objects:
+- `Документ.СписаниеСРасчетногоСчета`
+- `РегистрБухгалтерии.Хозрасчетный` (account 60/76)
+
+Key metrics:
+- total_outflow_by_supplier
+- payout_ops_count
+- active_supplier_flags
+
+Output:
+- top/bottom suppliers by payouts
+- suppliers by operations frequency
+
+### R07. `contract_usage_and_value`
+Назначение: Q28–Q32.
+
+Source objects:
+- `Справочник.ДоговорыКонтрагентов`
+- факты движений/документов с `Договор*_Key`
+
+Key metrics:
+- contracts_total
+- contracts_used
+- amount_by_contract
+- docs_count_by_contract
+- last_activity_by_contract
+
+Output:
+- used vs unused contracts
+- top contracts by amount/docs
+- stale contracts
+- counterparties with multi-contract structure (working vs dead)
+
+### R08. `open_items_and_aging`
+Назначение: Q33–Q38.
+
+Source objects:
+- `РегистрБухгалтерии.Хозрасчетный`
+- при необходимости специализированный register/обороты для aging
+
+Key metrics:
+- open_balance_by_party
+- debt_age_buckets
+- oldest_open_items
+
+Output:
+- top debtors/creditors
+- old small tails
+- supplier/customer open-item contrasts
+- oldest unresolved debts
+
+### R09. `accounting_quality_risk_scan`
+Назначение: Q39–Q40.
+
+Source objects:
+- `Документ.*`
+- `ДокументЖурнал.*`
+- `РегистрБухгалтерии.Хозрасчетный`
+
+Deterministic checks (v1):
+- неполные обязательные поля
+- аномальные суммы/частоты
+- противоречивые связи контрагент-договор-документ
+- высокая активность при нестабильной структуре данных
+
+Output:
+- risk-ranked список документов/контрагентов
+- причины попадания в риск
+
+## 5. Критически важные требования к точности маршрутов
+
+1. Key-first фильтрация:
+- для контрагента/договора использовать `*_Key`, а не только текстовые представления.
+
+2. Единая каноническая проекция фактов:
+- `event_date`, `doc_ref`, `doc_type`, `amount`, `direction`, `account_dt/kt`, `counterparty_key`, `contract_key`, `organization_key`.
+
+3. Сигнатура роли контрагента:
+- customer/supplier определять по account/направлению движения, а не по свободному тексту вопроса.
+
+4. Разделение «операции» vs «документы»:
+- в каждом route явно фиксировать базу расчета (движения или документы), чтобы не смешивать метрики.
+
+5. Multi-step вопросы (C4) исполнять как план из подзапросов:
+- сначала отдельные factual подвыборки,
+- затем агрегирование/сравнение в composer.
+
+## 6. Что нужно расширить в runtime перед внедрением домена
+
+1. Новые intents (management layer):
+- `period_coverage_profile`
+- `document_type_usage`
+- `counterparty_lifecycle_profile`
+- `customer_revenue_ranking`
+- `supplier_payout_ranking`
+- `contract_portfolio_profile`
+- `open_items_aging_profile`
+- `accounting_quality_anomalies`
+
+2. Новые recipe templates:
+- `group_by_year_month`
+- `group_by_counterparty`
+- `group_by_contract`
+- `aging_bucket`
+- `quality_scan`
+
+3. Новый execution path для compound/comparative:
+- multi-step executor для C4 (в текущем V1 этого нет).
+
+4. Composer расширение:
+- табличные ранжированные summary-блоки (top/bottom, доли, buckets, risk reasons).
+
+## 7. План внедрения пачками
+
+### Batch 0 (обязательный foundation)
+Scope:
+- route probes по полям `counterparty_key/contract_key` и качеству join.
+- подтверждение query templates для group-by на live.
+
+Artifacts:
+- `management_route_probe_report_*.md`
+- baseline query fixtures.
+
+Gate:
+- ни одного route без подтвержденного key-based фильтра.
+
+### Batch 1 (C1/C2, быстрый бизнес-эффект)
+Вопросы:
+- Q1–Q7, Q28.
+
+Routes:
+- R01, R02, R03, часть R07.
+
+Результат:
+- общий профиль базы + структура контрагентов + базовая договорная метрика.
+
+### Batch 2 (C3 lifecycle)
+Вопросы:
+- Q8–Q13, Q26, Q27, Q31, Q32.
+
+Routes:
+- R04, часть R07.
+
+Результат:
+- устойчивый lifecycle слой (new/lost/one-time/long-term/stale).
+
+### Batch 3 (ценность и концентрация)
+Вопросы:
+- Q14–Q25, Q29, Q30.
+
+Routes:
+- R05, R06, часть R07.
+
+Результат:
+- клиентская/поставщическая ценность и контрактные рейтинги.
+
+### Batch 4 (задолженности и aging)
+Вопросы:
+- Q33–Q38.
+
+Routes:
+- R08.
+
+Результат:
+- дебиторка/кредиторка с age-buckets и сравнительной аналитикой.
+
+### Batch 5 (quality/risk)
+Вопросы:
+- Q39–Q40.
+
+Routes:
+- R09.
+
+Результат:
+- управленческий quality/risk слой с объяснимыми причинами аномалий.
+
+## 8. Acceptance и рельсовые критерии для каждой пачки
+
+1. Domain pack обязателен:
+- canonical
+- noisy/slang
+- follow-up chains
+- multi-step (для C4)
+
+2. Gate каждой пачки:
+- `strict_pass(route)=100%` на domain pack
+- `false_factual_rate=0`
+- `execution_error_count=0`
+
+3. После каждой пачки:
+- обязательный global regression `102 + 25`
+- comparator against baseline PASS
+
+4. Обновление docs:
+- `runtime_readiness_matrix_v1.md`
+- `address_scenario_matrix.md`
+- domain card + run artifacts
+
+## 9. Риски и как их снимать
+
+1. Риск: ложные агрегаты из-за текстовых anchor-match.
+- Мера: key-based joins и route probes до включения intent.
+
+2. Риск: смешение операций и документов в одной метрике.
+- Мера: отдельные route contracts для movement-based и document-based метрик.
+
+3. Риск: срыв на multi-step вопросах.
+- Мера: отдельный compound executor для C4, без неявных fallback в single-intent.
+
+4. Риск: рост R&D хаоса по доменам.
+- Мера: только batch rollout + обязательный gate + closeout per batch.
+
+## 10. Практический next step (сейчас)
+
+1. Запустить Batch 0:
+- field-probe по key-полям для контрагента/договора в register/docs.
+- зафиксировать финальный route contract для R01–R03 и R07 (часть).
+
+2. После Batch 0 сразу брать Batch 1 как первый production-ready срез общего домена.
+
+Фактический статус на 2026-04-02:
+- стартовая управленческая рамка Batch-1 зафиксирована в `step4_wave1_batch1_master_checker_v1.md`;
+- readiness подтвержден авто-отчетом `wave1_batch1_readiness_report_2026-04-02.md` (`READY_FOR_PHASE_A`).
+
+## 11. Полная матрица Q -> Route -> Complexity -> Batch
+
+| Q | Краткий смысл | Route | Complexity | Batch |
+|---|---|---|---|---|
+| Q1 | годы покрытия базы | R01 | C1 | B1 |
+| Q2 | самый активный год | R01/R02 | C1 | B1 |
+| Q3 | самый активный месяц | R01 | C1 | B1 |
+| Q4 | самые частые типы документов | R02 | C1 | B1 |
+| Q5 | заполненность контуров учета | R02 (+R01) | C2 | B1 |
+| Q6 | всего уникальных контрагентов | R03 | C1 | B1 |
+| Q7 | заказчики/поставщики/прочие | R03 | C1 | B1 |
+| Q8 | заказчики активные в году | R04 | C1 | B2 |
+| Q9 | заказчики активные за все время | R04 | C1 | B2 |
+| Q10 | новые заказчики в году | R04 | C3 | B2 |
+| Q11 | заказчики, ушедшие после периода | R04 | C3 | B2 |
+| Q12 | контрагенты с одной активностью | R04 | C3 | B2 |
+| Q13 | самые долгоживущие контрагенты | R04 | C3 | B2 |
+| Q14 | top заказчики по деньгам (all-time) | R05 | C2 | B3 |
+| Q15 | top заказчики по деньгам (год) | R05 | C2 | B3 |
+| Q16 | low-value активные заказчики | R05 | C2 | B3 |
+| Q17 | кто платит чаще всего | R05 | C2 | B3 |
+| Q18 | самые крупные разовые оплаты | R05 | C2 | B3 |
+| Q19 | самый высокий средний чек | R05 | C2 | B3 |
+| Q20 | низкий средний чек + много операций | R05 | C2/C3 | B3 |
+| Q21 | концентрация выручки по клиентам | R05 | C3 | B3 |
+| Q22 | top поставщики по выплатам (all-time) | R06 | C2 | B3 |
+| Q23 | top поставщики по выплатам (период) | R06 | C2 | B3 |
+| Q24 | минимальные выплаты среди активных | R06 | C2 | B3 |
+| Q25 | поставщики с max числом операций | R06 | C2 | B3 |
+| Q26 | регулярные vs эпизодические поставщики | R04/R06 | C3 | B2 |
+| Q27 | давно неиспользуемые поставщики | R04 | C3 | B2 |
+| Q28 | договоры: всего vs реально использованные | R07 | C2 | B1 |
+| Q29 | top договоры по деньгам | R07 | C2 | B3 |
+| Q30 | top договоры по числу документов | R07 | C2 | B3 |
+| Q31 | давно неиспользуемые договоры | R07 | C3 | B2 |
+| Q32 | мультидоговорные контрагенты + рабочие договоры | R07 | C3 | B2 |
+| Q33 | top дебиторы на сейчас | R08 | C2 | B4 |
+| Q34 | мелкие, но старые долги | R08 | C3 | B4 |
+| Q35 | поставщики с незакрытыми расчетами в нашу пользу | R08 | C3 | B4 |
+| Q36 | top кредиторы (кому должны) | R08 | C2 | B4 |
+| Q37 | где больше проблемных хвостов: customer vs supplier | R08 (+compound compare) | C4 | B4 |
+| Q38 | самые старые незакрытые задолженности | R08 | C3 | B4 |
+| Q39 | документы с ошибками/неполнотой/подозрительностью | R09 | C4 | B5 |
+| Q40 | контрагенты с активностью и нестабильностью данных | R09 | C4 | B5 |
+
+## 12. Статус Batch-0 по первой группе (live-подтверждение)
+
+На дату `2026-04-02` выполнен live probe первой группы общего домена (`Q1..Q5`) через MCP endpoint `POST /api/execute_query?channel=default`.
+
+Артефакт:
+- `management_route_probe_report_g1_2026-04-02.md`
+
+Итог:
+1. `R01 period_coverage_profile` подтвержден на live-данных (`Q1`, `Q3`).
+2. `R02 document_type_usage_profile` подтвержден на live-данных (`Q2`, `Q4`).
+3. Для `Q5` подтверждена реализуемость через account-section aggregation (по первым двум символам кода счета, дебет+кредит), требуется формализовать policy для "почти не используется" (порог/квантиль + исключения по off-balance/служебным кодам).
@@ -80,6 +80,21 @@
 - [ ] Resolver hardening для более широкого набора anchor-типов (без company-specific словарей).
 - [ ] CI/nightly automation полного regression-пака.

+#### Step-4 Wave-1 (general domain, Batch-1: Q1..Q7 + Q28)
+
+- [x] Создан master checker новой волны: `step4_wave1_batch1_master_checker_v1.md`.
+- [x] Добавлен автоматический readiness checker: `scripts/check_address_wave1_batch1_readiness.py`.
+- [x] Выпущен readiness report: `wave1_batch1_readiness_report_2026-04-02.md` (`READY_FOR_PHASE_A`).
+- [x] Phase A стартован:
+  - `domain_general_batch1_foundation_card_v1.md`
+  - `domain_general_batch1_acceptance_2026-04-02_phaseA.json`
+  - `step4_wave1_batch1_phaseA_backlog_v1.md`
+- [ ] Phase A закрыт (intent naming freeze + negative cases).
+- [ ] Phase B закрыт (resolver/types/recipes/compose для Batch-1).
+- [ ] Phase C закрыт (domain gate + global non-regression gate).
+- [x] Phase B.1 начат: реализован первый Batch-1 intent `period_coverage_profile` (resolver + types + recipe + compose), unit/build green.
+- [x] Phase B.1 progress: реализован второй Batch-1 intent `document_type_and_account_section_profile` (resolver + classifier + recipe + compose), unit/build green (`107 passed`).
+
 ## Документация (code-sync)

 - [x] Базовые docs синхронизированы с текущим runtime-кодом (`README`, `address_scenario_matrix`, `query_recipes`, `runtime_readiness_matrix`, `address_runtime_contracts`, `runtime_integration_plan`).
@@ -0,0 +1,118 @@
+# LLM-First Pre-Gate Contract V1 (2026-04-02)
+
+## Цель
+
+Убрать зависимость от ручного пополнения сленговых словарей на входе в `address_query`.
+
+Новый принцип:
+
+1. Сначала выполняется `LLM pre-decompose` (попытка канонизации пользовательского текста).
+2. Затем rule-gate работает как валидатор маршрута, а не как первичный смысловой парсер.
+3. В debug и в run-артефактах фиксируется единый контракт канонизации + метрики качества.
+
+## Что внедрено в код
+
+### 1. Контракт канонизации (новый модуль)
+
+Файл:
+
+- `llm_normalizer/backend/src/services/address_runtime/predecomposeContract.ts`
+
+Экспорт:
+
+- `buildAddressLlmPredecomposeContractV1(...)`
+
+Схема контракта:
+
+- `schema_version: address_llm_predecompose_contract_v1`
+- `source_message`
+- `canonical_message`
+- `mode`, `mode_confidence`
+- `query_shape`, `query_shape_confidence`
+- `intent`, `intent_confidence`
+- `entities` (`account`, `counterparty`, `contract`, `document_type`, `document_ref`, `organization`)
+- `period` (`scope`, `period_from`, `period_to`, `as_of_date`, `has_explicit_period`)
+- `aggregation_profile` (`management_profile | list_lookup | balance_snapshot | open_items | unknown`)
+
+### 2. Прокидка контракта в runtime debug
+
+Файл:
+
+- `llm_normalizer/backend/src/services/assistantService.ts`
+
+Добавлено:
+
+- `llm_predecompose_contract` в address-debug payload.
+- Прокидка `address_*` полей pre-decompose/gate в debug deep-ответов (для случаев, когда address lane заблокирован и финальный ответ не address).
+
+### 3. LLM-first поведение pre-decompose
+
+Файл:
+
+- `llm_normalizer/backend/src/services/assistantService.ts`
+
+Сделано:
+
+- Убрана ранняя блокировка `not_address_like` перед попыткой LLM нормализации.
+- Убрана отсечка кандидатов по `execution_readiness=no_route` + regex в pre-decompose candidate extraction.
+- Добавлен сигнал gate: `llm_canonical_candidate_detected`.
+
+### 4. Метрики в live-runner
+
+Файл:
+
+- `scripts/run_address_live_slang_stress.py`
+
+`run_summary.json` теперь включает:
+
+- `totals.llm_decomposition_attempted_count`
+- `totals.llm_decomposition_applied_count`
+- `totals.llm_fallback_count`
+- `totals.llm_fallback_rate`
+- `totals.tool_gate_blocked_count`
+- `totals.tool_gate_blocked_rate`
+- `distributions.tool_gate_decision`
+- `distributions.tool_gate_reason`
+- `address_llm_predecompose_metrics.overall`
+- `address_llm_predecompose_metrics.by_intent`
+
+### 5. Intent-усиление для roster-формулировок
+
+Файл:
+
+- `llm_normalizer/backend/src/services/addressIntentResolver.ts`
+
+Добавлен сигнал lifecycle для формулировок вида:
+
+- `кто у нас заказчики вообще`
+- `какие есть заказчики/клиенты`
+- `кто есть заказчики в базе`
+
+## Валидация
+
+### Unit/Integration tests
+
+- `tests/assistantAddressLlmPredecompose.test.ts` -> pass
+- `tests/addressQueryRuntimeM23.test.ts` -> pass
+
+### Live run (targeted)
+
+- `docs/ADDRESS/runs/2026-04-02_Address_LLM_First_Gate_Probe_WithMetrics/run_summary.json`
+  - `strict_pass_rate = 1.0`
+  - `tool_gate_blocked_rate = 0.0`
+
+- `docs/ADDRESS/runs/2026-04-02_Address_GateBlock_Probe_WithMetrics_02/run_summary.json`
+  - подтвержден захват блокировки gate:
+  - `tool_gate_blocked_count = 1`
+  - `tool_gate_blocked_rate = 0.5`
+  - `address_llm_predecompose_metrics.by_intent.unknown.gate_block_rate = 1.0`
+
+## Что это дает в процессной модели
+
+1. Мы больше не “размазываем” смысловую обработку по regex-словарам.
+2. У нас есть наблюдаемая метрика, когда gate начинает душить реальный поток:
+   - `gate_block_rate` overall/by intent.
+3. У нас есть наблюдаемая метрика костыльности:
+   - `fallback_rate` overall/by intent.
+4. Расширение доменов можно вести через route/recipe-пакеты и acceptance-паки, а не через бесконечные сленг-патчи.
+
@@ -0,0 +1,112 @@
+# Management Route Probe Report — General Domain Group 1 (Q1–Q5)
+
+- Дата/время запуска: `2026-04-02T18:15:58+03:00`
+- Endpoint: `http://127.0.0.1:6003`
+- Channel: `default`
+- Контур: `question_mode=address_query`, Batch-0 route probes
+
+## Вердикт по вопросам группы 1
+- Q1 (покрытие периодов): **PASS**
+- Q2 (самый активный год по документам): **PASS**
+- Q3 (самый активный месяц по операциям): **PASS**
+- Q4 (наиболее частые типы документов): **PASS**
+- Q5 (наиболее/наименее заполненные разделы учета): **PASS**
+
+## Q1 — Покрытие базы и активность по годам
+- Мин период: `2014-05-27T12:00:00Z`
+- Макс период: `2030-08-03T12:00:00Z`
+- Всего операций в регистре: `12659`
+- Годы с данными: `2014..2030` (уникальных лет: `13`)
+- Топ годов по количеству операций:
+  - `2015`: `3212`
+  - `2019`: `2273`
+  - `2018`: `2234`
+  - `2020`: `1391`
+  - `2017`: `1376`
+  - `2016`: `1187`
+  - `2021`: `553`
+  - `2014`: `235`
+
+## Q2 — Самый активный год по количеству документов
+- Метрика: `COUNT(DISTINCT Регистратор)` по годам на `РегистрБухгалтерии.Хозрасчетный`.
+- Топ годов:
+  - `2019`: `1004`
+  - `2018`: `703`
+  - `2015`: `671`
+  - `2016`: `577`
+  - `2020`: `536`
+  - `2017`: `456`
+  - `2021`: `308`
+  - `2014`: `115`
+- Вывод: route дает корректный ranking по документной активности в контуре движений.
+
+## Q3 — Самый активный месяц по количеству операций
+- Метрика: `COUNT(*)` по `НАЧАЛОПЕРИОДА(Период, МЕСЯЦ)`.
+- Топ месяцев:
+  - `2015-02`: `1249`
+  - `2015-01`: `924`
+  - `2018-08`: `854`
+  - `2019-05`: `536`
+  - `2017-12`: `503`
+  - `2020-06`: `305`
+  - `2020-03`: `297`
+  - `2019-09`: `273`
+  - `2018-11`: `261`
+  - `2015-12`: `225`
+  - `2018-12`: `213`
+  - `2019-08`: `185`
+
+## Q4 — Наиболее частые типы документов
+- Метрика: `COUNT(DISTINCT Регистратор)` по `ПРЕДСТАВЛЕНИЕ(ТИПЗНАЧЕНИЯ(Регистратор))`.
+- Топ типов:
+  - `Списание с расчетного счета`: `2352`
+  - `Поступление товаров и услуг`: `486`
+  - `Регламентная операция`: `414`
+  - `Поступление на расчетный счет`: `323`
+  - `Счет-фактура полученный`: `262`
+  - `Операция (бухгалтерский и налоговый учет)`: `147`
+  - `Реализация товаров и услуг`: `123`
+  - `Отражение зарплаты в регламентированном учете`: `87`
+  - `Приходный кассовый ордер`: `76`
+  - `Расходный кассовый ордер`: `73`
+  - `Требование-накладная`: `45`
+  - `Передача товаров`: `16`
+
+## Q5 — Заполненность разделов учета
+- Метод: агрегирование по первым двум цифрам кода счета (дебет + кредит).
+- Топ разделов:
+  - `90` `Продажи`: `2973`
+  - `51` `Расчетные счета`: `2967`
+  - `60` `Расчеты с поставщиками и подрядчиками`: `2793`
+  - `44` `Расходы на продажу`: `2422`
+  - `68` `Расчеты по налогам и сборам`: `1554`
+  - `10` `Материалы`: `1494`
+  - `19` `НДС по приобретенным ценностям`: `1490`
+  - `91` `Прочие доходы и расходы`: `1324`
+  - `41` `Товары`: `1312`
+  - `76` `Расчеты с разными дебиторами и кредиторами`: `1240`
+- Разделы с минимальной активностью (среди использованных):
+  - `58` `Финансовые вложения`: `2`
+  - `81` `Собственные акции (доли)`: `2`
+  - `80` `Уставный капитал`: `5`
+  - `75` `Расчеты с учредителями`: `16`
+  - `55` `Специальные счета в банках`: `18`
+  - `84` `Нераспределенная прибыль (непокрытый убыток)`: `20`
+  - `26` `Общехозяйственные расходы`: `51`
+  - `71` `Расчеты с подотчетными лицами`: `76`
+  - `43` `Готовая продукция`: `81`
+  - `50` `Касса`: `163`
+
+## Что подтверждено для продуктового плана
+- `R01 period_coverage_profile`: подтвержден (Q1/Q3).
+- `R02 document_type_usage_profile`: подтвержден (Q2/Q4).
+- `Q5` закрывается route-контрактом через account-section aggregation; нужна фиксация правила для "почти не используются" (порог/квантиль).
+
+## Ограничения и требования к точности
+- Q2/Q4 измеряются по `Регистратор` в движениях; это нужно явно закрепить как `movement-based document activity`.
+- Для Q5 нельзя опираться только на raw счета: обязателен post-processing `section = account_code[:2]`.
+- Есть записи с редкими/системными кодами (например off-balance); требуется whitelist/normalization policy для бизнес-отчета.
+
+## Следующий шаг Batch-0
+- Зафиксировать route contracts для `R01` и `R02` в runtime docs.
+- Добавить acceptance-вопросы Q1..Q5 в domain pack с жесткой проверкой метрик и сортировки.
@@ -44,6 +44,8 @@

 | recipe_id | intent | purpose | required_filters | optional_filters | query_template | account_scope_mode |
 |---|---|---|---|---|---|---|
+| `address_period_coverage_profile_v1` | `period_coverage_profile` | профиль покрытия периодов + топ год/месяц активности | - | `period_from`, `period_to`, `organization`, `limit` | `period_profile` | `preferred` |
+| `address_document_type_and_account_section_profile_v1` | `document_type_and_account_section_profile` | профиль типов документов + заполненность разделов учета | - | `period_from`, `period_to`, `organization`, `limit` | `document_section_profile` | `preferred` |
 | `address_movements_payables_v1` | `list_payables_counterparties` | movement-срез по обязательствам | - | `as_of_date`, `counterparty`, `contract`, `limit` | `movements` | `preferred` |
 | `address_movements_receivables_v1` | `list_receivables_counterparties` | movement-срез по требованиям | - | `as_of_date`, `counterparty`, `contract`, `limit` | `movements` | `preferred` |
 | `address_open_contracts_candidates_v1` | `list_open_contracts` | кандидаты незакрытых договоров | - | `as_of_date`, `organization`, `limit` | `movements` | `preferred` |
@@ -59,6 +61,8 @@

 - Базовый max limit: `200`.
 - Расширенный max limit (`1000`) для:
+  - `period_coverage_profile`;
+  - `document_type_and_account_section_profile`;
  - `documents/bank by counterparty|contract`;
  - `open_items_by_counterparty_or_contract`;
  - `list_open_contracts`.
@@ -96,7 +100,7 @@ Legacy совместимость:

 Фактическая реализация `composeStage` сейчас отдает:

- `FACTUAL_SUMMARY` в основном для `account_balance_snapshot`;
+- `FACTUAL_SUMMARY` для `account_balance_snapshot`, `period_coverage_profile`, `document_type_and_account_section_profile`;
 - для остальных factual intents — `FACTUAL_LIST`.

 ## 9) Guardrails
@@ -27,6 +27,8 @@
 | AQ-P0-08 | list_documents_by_contract | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | document-filter может обнулять rows по узкому окну | contract docs fallback + resolver hardening |
 | AQ-P0-08B | bank_operations_by_contract | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | устойчивость зависит от contract anchor качества | усилить contract normalization и follow-up carryover |
 | AQ-P0-09 | documents_forming_balance | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | account-family чувствителен к row-shape/materialization | продолжить materialization diagnostics |
+| AQ-B1-10 | period_coverage_profile | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | новый management intent, еще не закрыт domain-gate Batch-1 | закрыть Phase B/C gate на `Q1..Q7 + Q28` |
+| AQ-B1-11 | document_type_and_account_section_profile | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | новый management intent, требуется gate-проверка ranking стабильности | закрыть Phase B/C gate на `Q1..Q7 + Q28` |
 | AQ-P1-10 | account_turnover_snapshot | STRUCTURALLY_VISIBLE | UNKNOWN | intent/recipe отсутствуют в runtime | планировать как отдельный домен Step-4 |
 | AQ-P1-11 | list_documents_by_type | STRUCTURALLY_VISIBLE | UNKNOWN | intent/recipe отсутствуют в runtime | планировать как отдельный домен Step-4 |

@@ -35,6 +37,9 @@
 - В runtime реализованы by-contract intents:
  - `list_documents_by_contract`
  - `bank_operations_by_contract`
+- В runtime реализованы первые management intents Batch-1:
+  - `period_coverage_profile`
+  - `document_type_and_account_section_profile`
 - `COMPOUND_FACTUAL_QUERY` остается detection-only (без multi-intent execution).
 - Финальные gate-артефакты стабильности:
  - stress `102/102`: `docs/ADDRESS/runs/2026-04-02_Address_Slang_Live_Stress_2026-04-02_12-57-27/run_summary.json`
@@ -0,0 +1,60 @@
+# Step-4 Wave-1 Batch-1 Master Checker V1
+
+Дата: 2026-04-02  
+Контур: `question_mode=address_query`  
+Scope Batch-1: `Q1..Q7 + Q28` (первая волна общего домена)
+
+## 1. Go/No-Go Checker (перед стартом кодирования)
+
+Источник авто-проверки:
+- `wave1_batch1_readiness_report_2026-04-02.md`
+- script: `python scripts/check_address_wave1_batch1_readiness.py`
+
+Результат на 2026-04-02:
+- **READY_FOR_PHASE_A**
+
+Контрольные пункты:
+
+- [x] Step-0 pre-prod rails закрыт.
+- [x] Базовый Step-4 план зафиксирован.
+- [x] Анализ общего домена (40 вопросов) зафиксирован.
+- [x] Live probe первой группы (`Q1..Q5`) зафиксирован.
+- [x] Карта статуса сложных вопросов и reuse-слой зафиксированы.
+- [x] Baseline stress `102/102`.
+- [x] Baseline follow-up `25/25`.
+- [x] Nightly regression green.
+
+## 2. Гейтинг Batch-1 (чтобы не "вкорячивать")
+
+Batch-1 можно переводить в runtime только после закрытия трех фаз:
+
+1. **Phase A — Design/Contract**
+- domain card для Batch-1;
+- финализированный intent contract;
+- acceptance question set (canonical + noisy + follow-up).
+
+2. **Phase B — Runtime Prep**
+- intent resolver additions;
+- filter extractor additions;
+- recipe catalog additions;
+- composer output contract для ranking/summary формата.
+
+3. **Phase C — Live Gate**
+- domain acceptance run-pack;
+- global regression (`102 + 25`);
+- comparator PASS к baseline.
+
+## 3. Статус текущей волны
+
+- [x] **Phase A стартован** (документационный контур и readiness checker подготовлены).
+- [ ] Phase A закрыт.
+- [x] Phase B.1 в работе: реализованы `period_coverage_profile`, `document_type_and_account_section_profile`, `counterparty_population_and_roles`, `contract_usage_overview` (unit/build green).
+- [x] Targeted live-check Batch-1 next pack (`Q6/Q7/Q28`) выполнен: `strict factual 9/9`.
+- [ ] Phase B закрыт.
+- [ ] Phase C закрыт.
+
+## 4. Решение на сейчас
+
+1. Начинать можно, но строго по фазам выше.
+2. Прямое включение Batch-1 intents в production-path без Phase B/C — запрещено.
+3. Точка входа в работу: `Phase C` (full Batch-1 acceptance + global non-regression).
@@ -0,0 +1,88 @@
+# Step-4 Wave-1 Batch-1 — Phase A/B Backlog V1
+
+Дата: 2026-04-02  
+Статус: `active`  
+Scope: `Q1..Q7 + Q28`
+
+## 1. Phase A (Design/Contract) — старт
+
+- [x] Зафиксирован master checker: `step4_wave1_batch1_master_checker_v1.md`
+- [x] Выпущен readiness report: `wave1_batch1_readiness_report_2026-04-02.md`
+- [x] Зафиксирована domain card: `domain_general_batch1_foundation_card_v1.md`
+- [x] Сформирован стартовый acceptance набор: `domain_general_batch1_acceptance_2026-04-02_phaseA.json`
+- [x] Финализировано именование Batch-1 intent-ов (freeze):  
+  `period_coverage_profile`, `document_type_and_account_section_profile`, `counterparty_population_and_roles`, `contract_usage_overview`.
+- [ ] Добавить negative-кейсы (похожая формулировка -> другой intent/limited)
+
+## 2. Phase B (Runtime Prep) — задачи по коду
+
+### 2.1 Resolver / Types
+
+- [x] `llm_normalizer/backend/src/services/addressIntentResolver.ts`  
+  Добавить intents Batch-1:  
+  `period_coverage_profile`, `document_type_and_account_section_profile`, `counterparty_population_and_roles`, `contract_usage_overview`.
+- [x] `llm_normalizer/backend/src/types/addressQuery.ts`  
+  Расширить `AddressIntent`, `AddressResponseType`/debug контракт при необходимости.
+- [ ] `llm_normalizer/backend/src/services/address_runtime/decomposeStage.ts`  
+  Добавить follow-up carryover правила для Batch-1 summary intents.
+
+Статус Phase B.1 (факт):
+
+- [x] Добавлен `period_coverage_profile` в `AddressIntent` и resolver-сигналы.
+- [x] Добавлен `document_type_and_account_section_profile` в `AddressIntent` и resolver-сигналы.
+- [x] Добавлен `counterparty_population_and_roles` в `AddressIntent` и resolver-сигналы.
+- [x] Добавлен `contract_usage_overview` в `AddressIntent` и resolver-сигналы.
+- [x] Расширен mode classifier для management profile вопросов (`management_profile_signal_detected`).
+
+### 2.2 Recipe / Execution
+
+- [x] `llm_normalizer/backend/src/services/addressRecipeCatalog.ts`  
+  Добавить recipes:
+  - `address_period_coverage_profile_v1`
+  - `address_document_type_and_account_section_profile_v1`
+  - `address_counterparty_population_roles_v1`
+  - `address_contract_usage_overview_v1`
+- [ ] `llm_normalizer/backend/src/services/addressQueryService.ts`  
+  Добавить обработку summary/list composer-путей для новых intents.
+- [ ] Зафиксировать operation-vs-document contracts для метрик `Q1..Q5`.
+
+Статус Phase B.1 (факт):
+
+- [x] Добавлен recipe `address_period_coverage_profile_v1` + query template `period_profile`.
+- [x] Добавлен recipe `address_document_type_and_account_section_profile_v1` + query template `document_section_profile`.
+- [x] Добавлен recipe `address_counterparty_population_roles_v1` + query template `counterparty_roles_profile`.
+- [x] Добавлен recipe `address_contract_usage_overview_v1` + query template `contract_usage_profile`.
+
+### 2.3 Compose / Output
+
+- [ ] `llm_normalizer/backend/src/services/address_runtime/composeStage.ts`  
+  Формат rank-list/summary для management intents (top/bottom + labels + metric basis).
+- [ ] Добавить единый wording для partial (`limited_reason_category`) в Batch-1.
+
+Статус Phase B.1 (факт):
+
+- [x] Добавлен summary composer для `period_coverage_profile` (coverage range + top year/docs + top month/ops).
+- [x] Добавлен summary composer для `document_type_and_account_section_profile` (top doc types + top/low account sections).
+- [x] Добавлен summary composer для `counterparty_population_and_roles` (total + role split).
+- [x] Добавлен summary composer для `contract_usage_overview` (total vs used + unused + share).
+- [x] Прогнаны build + unit:
+  - `npm.cmd run build`
+  - `npm.cmd test -- tests/addressQueryRuntimeM23.test.ts` (`132 passed`)
+  - live targeted pack `Q6/Q7/Q28`: `2026-04-02_Address_Batch1_NextPack_Q6_Q7_Q28` (`strict factual 9/9`)
+
+## 3. Phase C (Gate) — критерии закрытия
+
+- [ ] Domain run-pack по `domain_general_batch1_acceptance_2026-04-02_phaseA.json`:
+  - `strict_pass(route)=100%`
+  - `false_factual_rate=0`
+  - `execution_error_rate=0`
+- [ ] Global non-regression:
+  - `address_slang_stress_full_2026-04-02.json`
+  - `address_followup_context_chains_2026-04-02.json`
+  обе метрики не ниже baseline (`102/102`, `25/25`).
+- [ ] Обновить docs: `runtime_readiness_matrix_v1.md`, `address_scenario_matrix.md`, `global_execution_checklist_v1.md`.
+
+## 4. Точка старта работ
+
+Следующая практическая задача: перейти к domain gate по full Batch-1 pack  
+(`domain_general_batch1_acceptance_2026-04-02_phaseA.json`) и закрыть Phase C.
@@ -0,0 +1,18 @@
+# Wave-1 Batch-1 Readiness Report
+
+- Generated at: `2026-04-02T18:35:01+03:00`
+- Decision: **READY_FOR_PHASE_A**
+
+## Checks
+- `master_checklist_exists`: **PASS** — X:\1C\NDC_1C\docs\ADDRESS\address_query\global_execution_checklist_v1.md
+- `step0_closeout_exists`: **PASS** — X:\1C\NDC_1C\docs\ADDRESS\address_query\step0_closeout_2026-04-02.md
+- `step4_plan_exists`: **PASS** — X:\1C\NDC_1C\docs\ADDRESS\address_query\domain_expansion_implementation_plan_v1.md
+- `general_domain_analysis_exists`: **PASS** — X:\1C\NDC_1C\docs\ADDRESS\address_query\general_domain_questions_analysis_plan_v1_2026-04-02.md
+- `group1_probe_report_exists`: **PASS** — X:\1C\NDC_1C\docs\ADDRESS\address_query\management_route_probe_report_g1_2026-04-02.md
+- `complex_status_map_exists`: **PASS** — X:\1C\NDC_1C\docs\ADDRESS\address_query\complex_questions_status_and_reuse_map_2026-04-02.md
+- `baseline_stress_102`: **PASS** — strict=102/102, route=102/102
+- `baseline_followup_25`: **PASS** — strict=25/25, route=25/25
+- `nightly_regression_green`: **PASS** — overall_ok=true, packs=2
+
+## Next Action
+- Start/continue Phase A for Batch-1 (domain card + acceptance set + implementation backlog).