Да, давай сделаем следующий прогон уже **не “на каноничных вопросиках”**, а на более злой, предметной и местами провокационной выборке — ближе к тому, как человек реально разговаривает с бухгалтерским ассистентом. И да, архитектуру отчёта тоже сразу зафиксируем, чтобы на выходе был **один читаемый MD-файл**, который одновременно:

* удобно читать человеку,
* удобно парсить машине,
* удобно сравнивать между прогонами.
  Опираюсь на выжимку из разговора с главбухом: ядро ценности — не ввод первички, а контроль, сверка, поиск расхождений, анализ счетов, предзакрытие периода и вопросно-ответный интерфейс поверх нормализованной модели 1С. 

---

# Что предлагаю сделать

Новый прогон собрать как **Benchmark v2 / Creative Stress Run**, где вопросы будут:

* более длинные;
* более “человеческие”;
* с доменной неоднозначностью;
* с причинно-следственными цепочками;
* с несколькими сущностями сразу;
* с формулировками не “из теста”, а ближе к живому главбуху. 

И на выходе генерировать **один отчёт `.md`** следующего типа:

---

# Архитектура итогового отчёта

## Имя файла

`benchmark_creative_stress_run_accounting_assistant_YYYY-MM-DD.md`

---

## Структура файла

### 1. Паспорт прогона

Короткий верхний блок:

```md
# Creative Stress Benchmark Run — Accounting Assistant

## Паспорт
- run_id: creative_stress_run_2026-03-23
- dataset_version: semantic_v2 + router_fix
- questions_total: 40
- benchmark_profile: creative_hard_human_like
- generated_from: accounting_automation_structured_notes
- mode: validation / stress / pilot-readiness
- executor: <pipeline or person>
- overall_status: pass / pass_with_notes / fail
```

### 2. Executive summary

Коротко по-человечески:

* что проверяли;
* что в целом показал прогон;
* где система сильна;
* где ещё спотыкается;
* готовность к следующему этапу.

### 3. Сводные метрики

Машиночитаемо и читаемо одновременно:

```md
## Сводные метрики
- route_mismatch_count:
- degraded_answers_count:
- batch_route_count:
- live_mcp_drilldown_count:
- hybrid_store_plus_live_count:
- store_canonical_count:
- store_feature_risk_count:
- avg_latency_ms:
- p95_latency_ms:
- pass_rate:
- strongest_zone:
- weakest_zone:
```

### 4. Сводка по классам вопросов

Разбивка:

* heavy_analytical
* cross_entity
* drilldown_explain
* period_close_risk
* document_reconciliation
* rule_based_account_control
* anomaly_probe
* ambiguous_human_query

### 5. Детальный блок Q/A

И вот это главный кусок. Для каждого вопроса — отдельный кейс в одном и том же формате.

---

# Формат одного кейса в отчёте

Вот рекомендованный шаблон.

```md
---
question_id: QH-01
question_class: cross_entity
difficulty: hard
domain_tags: [60, 62, сверка, документы, проводки, period_close]
expected_route: hybrid_store_plus_live
actual_route:
route_match:
latency_ms:
decision_flags:
  needs_exact_object_trace:
  needs_causal_chain:
  needs_cross_entity_join:
  needs_full_period_aggregation:
  needs_ranking:
  needs_anomaly_summary:
  needs_runtime_truth:
  freshness_sensitive:
  ambiguous_object_scope:
  store_sufficiency_confident:
  precomputed_aggregate_available:
store_sufficiency:
  canonical_sufficient:
  feature_sufficient:
  risk_sufficient:
  freshness_ok:
  aggregate_level_ok:
  ranking_ready:
  explanation_ready:
  reason_codes: []
answer_quality:
  status: pass / partial / fail
  confidence: high / medium / low
  degraded: false
---

## QH-01. [Короткое название кейса]

**Вопрос:**  
Покажи, по каким покупателям у нас на конец июня висят отгрузки без оплаты, и сразу свяжи это с реализациями, договорами и проводками, чтобы было видно, где именно хвост и чем он подтверждается.

**Что хотел проверить этот вопрос:**  
Проверка связки 62 ↔ 90 ↔ документы реализации ↔ оплаты ↔ договоры ↔ проводки, то есть не плоский факт, а причинная цепочка.

**Почему вопрос сложный:**  
Требует одновременно:
- cross-entity join,
- causal stitching,
- period-end cut,
- объяснимую цепочку источников.

**Как система должна была это понять:**  
Это не simple factual и не чистый trend.  
Это causal cross-entity scenario → ожидается `hybrid_store_plus_live`.

**Куда ожидали маршрут:**  
`hybrid_store_plus_live`

**Куда реально пошёл маршрут:**  
`...`

**Почему это корректно / некорректно:**  
Короткий человеческий комментарий.

**Краткий ход решения системы:**  
1. Определила периодный срез.  
2. Определила сущности: покупатель, реализация, оплата, договор, проводка.  
3. Проверила sufficiency canonical store.  
4. Поняла, что нужен causal join.  
5. Пошла в hybrid.

**Что ожидали увидеть в ответе:**  
- список покупателей;
- сумма хвоста;
- документы реализации;
- отсутствие / наличие оплат;
- связка с договором;
- подтверждающие проводки;
- указание проблемного периода.

**Что реально получили:**  
Короткий summary ответа.

**Вердикт по кейсу:**  
pass / partial / fail

**Замечания:**  
Что докрутить, если что.
```

---

# Почему такой формат хороший

Он одновременно:

* удобен для ручного чтения;
* достаточно структурирован для diff между прогонами;
* хранит route-логику рядом с человеческим комментарием;
* позволяет потом быстро делать выжимку по классам ошибок;
* пригоден как для внутреннего техотчёта, так и для демонстрации зрелости системы.

---

# Новый набор вопросов для Creative Stress Run

Ниже даю **40 вопросов**, уже заметно более жёстких и ближе к реальному бухгалтерам-режиму. Они построены из тех болей, что были в выжимке: 01/02, 97, 41, 51, 60, 62, 90, 10, сверки, незакрытые хвосты, предзакрытие периода, ошибки дат, отсутствие документов, причинная цепочка. 

---

## Блок A. Предзакрытие периода

### QH-01

Собери мне предзакрытие июня по-человечески: какие счета сейчас выглядят самыми проблемными, где хвосты, где незакрытые куски и что надо проверить в первую очередь, если период закрывать сегодня.

**Класс:** heavy_analytical
**Ожидаемый route:** `batch_refresh_then_store`

### QH-02

Покажи не просто проблемные счета за июнь, а объясни, почему именно они попали в риск-зону: чем это вызвано, какими документами и какими типовыми ошибками это может быть связано.

**Класс:** heavy_analytical
**Ожидаемый route:** `batch_refresh_then_store`

### QH-03

Сделай рейтинг самых опасных хвостов на конец июня, чтобы было видно, какие из них могут реально аукнуться при сдаче отчётности, а какие просто технический шум.

**Класс:** heavy_analytical
**Ожидаемый route:** `batch_refresh_then_store`

### QH-04

Есть ли у нас на конец июня такие расхождения, которые визуально небольшие, но по природе похожи на системную ошибку, а не на разовый косяк?

**Класс:** heavy_analytical / anomaly_probe
**Ожидаемый route:** `batch_refresh_then_store`

### QH-05

Если бы ты был главбухом и у тебя было полчаса перед закрытием периода, какие пять зон ты бы открыл первыми и почему?

**Класс:** heavy_analytical + explain
**Ожидаемый route:** `batch_refresh_then_store`

---

## Блок B. 60 / 62 / сверки / хвосты

### QH-06

Покажи, по каким поставщикам у нас не бьются взаиморасчёты, и разложи это не только по суммам, а по конкретным документам, оплатам и отсутствующим закрывающим.

**Класс:** cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-07

По каким покупателям у нас есть отгрузка, но нет оплаты или нормального закрытия, и как это выглядит в цепочке документ → проводка → взаиморасчёт?

**Класс:** cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-08

Где по 60 и 62 счётам у нас не просто долг висит, а есть ощущение, что отсутствует какой-то первичный документ, из-за чего цепочка развалилась?

**Класс:** cross_entity / explain
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-09

Покажи мне контрагентов, по которым расхождение выглядит подозрительно: то есть не обычная задержка, а именно такая история, где документы, оплаты и сальдо друг другу не соответствуют.

**Класс:** cross_entity / anomaly_probe
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-10

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

**Класс:** cross_entity / period_close_risk
**Ожидаемый route:** `hybrid_store_plus_live`

---

## Блок C. 41 / товары / приход / реализация

### QH-11

Где товар уже ушёл в реализацию, а нормального прихода под него в учёте не видно, и как эта проблема выглядит по датам, документам и поставщикам?

**Класс:** cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-12

Найди мне такие продажи, где себестоимость или приход выглядят подозрительно, как будто накладная запоздала, документ не дошёл или дата заведена криво.

**Класс:** cross_entity / anomaly_probe
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-13

Покажи отрицательные или аномальные остатки по товарам не просто списком, а с объяснением, какая цепочка событий к этому привела.

**Класс:** drilldown_explain / cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-14

Есть ли такие товарные позиции, где проблема тянется не один раз, а повторяется по схожему паттерну: продажа раньше прихода, странный разрыв по датам, неподложенные документы?

**Класс:** heavy_analytical / anomaly_probe
**Ожидаемый route:** `batch_refresh_then_store`

### QH-15

Покажи, какие складские или товарные хвосты на конец июня больше всего искажают картину периода.

**Класс:** heavy_analytical
**Ожидаемый route:** `batch_refresh_then_store`

---

## Блок D. 97 / расходы будущих периодов

### QH-16

По каким расходам будущих периодов у нас задан срок так, что списание либо идёт криво, либо вообще не должно было так выглядеть?

**Класс:** rule_based_account_control
**Ожидаемый route:** `store_feature_risk`

### QH-17

Покажи мне расходы будущих периодов, где ошибка, скорее всего, сидит в дате начала, окончания или вообще в неверно указанном годе.

**Класс:** rule_based_account_control / anomaly_probe
**Ожидаемый route:** `store_feature_risk`

### QH-18

Есть ли такие записи на 97 счёте, которые вроде заведены, но по ним нет нормального ежемесячного списания, и с какими исходными документами это связано?

**Класс:** cross_entity / explain
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-19

Покажи банковские гарантии, лицензии и похожие истории, которые сидят на 97, но выглядят так, будто срок действия и срок списания друг другу противоречат.

**Класс:** rule_based_account_control / cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-20

Сделай мне обзор по 97 счёту: что там сейчас выглядит как реальный риск периода, а что просто требует внимания, но не горит.

**Класс:** heavy_analytical
**Ожидаемый route:** `batch_refresh_then_store`

---

## Блок E. 01 / 02 / ОС / амортизация

### QH-21

Какие основные средства выглядят заведёнными так, будто амортизационная группа или срок амортизации выбраны сомнительно?

**Класс:** rule_based_account_control
**Ожидаемый route:** `store_feature_risk`

### QH-22

Покажи карточки ОС, где параметры похожи на ручную ошибку: группа одна, срок другой, логика начисления не бьётся.

**Класс:** rule_based_account_control / anomaly_probe
**Ожидаемый route:** `store_feature_risk`

### QH-23

Есть ли у нас объекты, по которым амортизация должна была идти, но не идёт, и чем это подтверждается в карточке и движениях?

**Класс:** cross_entity / explain
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-24

Покажи самые подозрительные случаи по ОС, которые потенциально опасны не потому, что сумма большая, а потому что логика учёта объекта выглядит криво.

**Класс:** heavy_analytical / explain
**Ожидаемый route:** `batch_refresh_then_store`

### QH-25

Есть ли системный паттерн ошибок в заведении основных средств, а не просто единичные косяки?

**Класс:** heavy_analytical / anomaly_probe
**Ожидаемый route:** `batch_refresh_then_store`

---

## Блок F. 51 / банк / выписки / отражение в учёте

### QH-26

Покажи движения по банку, где есть ощущение, что выписка, документ и проводка не собрались в нормальную цепочку.

**Класс:** cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-27

Есть ли у нас банковские движения, которые визуально выглядят нормально, но по логике счёта 51 оставляют некорректный хвост или ломают инвариант счёта?

**Класс:** rule_based_account_control / anomaly_probe
**Ожидаемый route:** `store_feature_risk`

### QH-28

Найди операции по банку, где, скорее всего, проблема не в сумме, а в том, что что-то не было проведено или не туда легло.

**Класс:** drilldown_explain / cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-29

Сделай мне список самых подозрительных банковских кейсов июня с коротким объяснением по каждому: в чём суть риска и что бы ты проверил руками первым.

**Класс:** heavy_analytical
**Ожидаемый route:** `batch_refresh_then_store`

### QH-30

Покажи, где движение по банку есть, а нормального отражения в учёте не видно, либо наоборот — в учёте что-то есть, а банковской логики под этим не хватает.

**Класс:** cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

---

## Блок G. 90 / 62 / реализация и неоплата

### QH-31

Какие реализации на конец июня зависли без оплаты и уже выглядят не как нормальная отсрочка, а как потенциально проблемный хвост?

**Класс:** heavy_analytical / cross_entity
**Ожидаемый route:** `batch_refresh_then_store`

### QH-32

Покажи связку реализация → оплата → договор → проводки по самым крупным незакрытым отгрузкам.

**Класс:** cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-33

Где по реализации хвост образовался не из-за отсутствия денег как таковых, а из-за разрыва документов, дат или отражения?

**Класс:** cross_entity / explain
**Ожидаемый route:** `hybrid_store_plus_live`

### QH-34

Сделай рейтинг самых неприятных незакрытых реализаций: чтобы было видно и сумму, и возраст хвоста, и признаки, что это именно проблема учёта, а не обычная операционка.

**Класс:** heavy_analytical
**Ожидаемый route:** `batch_refresh_then_store`

### QH-35

Покажи мне такие кейсы по 90/62, где всё выглядит почти нормально, но если копнуть глубже, видно, что период закрывается на кривой связке.

**Класс:** anomaly_probe / cross_entity
**Ожидаемый route:** `hybrid_store_plus_live`

---

## Блок H. 10 / материалы / списание

### QH-36

Что сейчас лежит на 10 счёте так, будто это уже давно просится в списание или хотя бы в ручную проверку?

**Класс:** rule_based_account_control
**Ожидаемый route:** `store_feature_risk`

### QH-37

Покажи материалы, по которым можно заподозрить нелогичный остаток: они висят, но движения и хозяйственная логика вокруг них выглядят странно.

**Класс:** rule_based_account_control / anomaly_probe
**Ожидаемый route:** `store_feature_risk`

### QH-38

Свяжи по нескольким подозрительным материалам остаток, документы, движения и возможный сценарий, почему они зависли.

**Класс:** cross_entity / explain
**Ожидаемый route:** `hybrid_store_plus_live`

---

## Блок I. Специально неоднозначные человеческие вопросы

### QH-39

Где у нас вообще “пахнет ручной ошибкой”, а не нормальной хозяйственной жизнью? Не по одному счёту, а в целом по июню.

**Класс:** heavy_analytical / anomaly_probe / ambiguous_human_query
**Ожидаемый route:** `batch_refresh_then_store`

### QH-40

Что сейчас в июне выглядит как история, которую бухгалтер потом будет долго и нервно распутывать, если не проверить заранее?

**Класс:** heavy_analytical / period_close_risk / ambiguous_human_query
**Ожидаемый route:** `batch_refresh_then_store`

---

# Как я предлагаю оформить ответы в прогоне

Не просто “вопрос — route — pass/fail”, а именно **гибридный стиль**:

## Для человека

* нормальный текст вопроса;
* короткое объяснение, что этот вопрос вообще проверяет;
* почему он сложный;
* короткий человеческий вердикт по кейсу.

## Для машины

* `question_id`
* `question_class`
* `expected_route`
* `actual_route`
* `route_match`
* `decision_flags`
* `store_sufficiency`
* `latency_ms`
* `answer_quality.status`
* `degraded`
* `reason_codes`

Это как раз даст вам отчёт, который можно:

* читать глазами,
* diff’ать между версиями,
* позже использовать как validation corpus.

---

# Очень важная рекомендация

Я бы в этот новый прогон добавил **ещё одно поле**, которого раньше, скорее всего, не хватало:

```md
**Проверяемая бухгалтерская гипотеза:**  
Какую именно предметную гипотезу должен был подтвердить или опровергнуть ассистент.
```

Пример:

* “по 97 счёту ошибка сидит в дате начала/окончания”;
* “по 41 счёту продажа опередила приход”;
* “по 60/62 счёту хвост образован отсутствием документа, а не просто неоплатой”.

Это сильно улучшит читаемость именно для предметников.

---

# Мой практический совет по следующему прогону

Сделайте следующий прогон не на всех 40 сразу, а в два прохода:

**Проход 1 — 15 вопросов**

* QH-01, 03, 06, 07, 11, 16, 18, 21, 23, 26, 29, 31, 33, 39, 40

Это даст:

* heavy,
* cross-entity,
* anomaly,
* rule-based,
* ambiguous human questions.

**Проход 2 — все 40**
После того как увидите, где он ещё хромает на творческих и длинных формулировках.

---

# Короткий вывод

Да, следующий benchmark надо делать уже не “академическим”, а **человекообразным и предметно-злым**.
И лучший формат отчёта для этого — **один MD-файл с карточками кейсов**, где рядом живут:

* вопрос,
* предметный смысл,
* ожидаемый маршрут,
* фактический маршрут,
* краткий ход рассуждения системы,
* и итоговый вердикт по качеству ответа.
  Вся эта логика напрямую вытекает из разговора с главбухом: ваша ценность — это контрольный и аналитический слой по реальным бухгалтерским болям, а не игрушечные вопросы “найди документ номер N”. 

Если хочешь, следующим сообщением я сразу превращу это в **готовую болванку отчёта в markdown**, уже целиком, чтобы вы просто вставили туда результаты прогона.