Этап 4 — пакет по РБП: покрытие источника, live-маршрут и материализация доказательной базы

### 1. Контекст

Этот пакет делается **узко под кейс РБП**, а не как новая общая волна по всей системе.
Вопрос про РБП уже зафиксирован как company-specific тест на lifecycle anomaly без выхода в полный Stage 5:
**“31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?”**

По живому прогону видно, что сейчас кейс остаётся в `partial_coverage`, живёт на snapshot-логике, live-путь слабый, admissible evidence до ответа не доезжает, а среди ограничений прямо фигурируют:

* snapshot 2020 read-only;
* live probe как ограниченный выборочный запрос;
* `matched_rows = 0`;
* live evidence исключён из grounded answer;
* admissibility gate убирает non-admissible evidence.

Stage 4 по-прежнему держим в рамках `P0-only`:

* без новых доменов,
* без graph/schema expansion,
* без Stage 5/6 как нового core path,
* без больших транспортных рефакторингов.

---

## 2. Цель пакета

Нужно **не улучшить wording**, а восстановить для РБП нормальный путь:

**вопрос про РБП → правильные seed-объекты → правильный source coverage → правильный live route → admissible evidence → внятный proof-style ответ**

Итогом пакета должно стать:

1. понимание, какие данные по РБП реально нужны;
2. понимание, где они лежат в snapshot/live;
3. рабочий live/source path до этих данных;
4. non-zero admissible evidence по РБП-кейсу;
5. ответ, который ограничивается только если данных реально нет, а не потому что контур не дошёл до нужных сущностей.

---

## 3. Source of truth для пакета

### Базовый вопрос

**31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?**

### Текущее живое поведение

По живому прогону для этого вопроса зафиксировано:

* `business_scope = generic_accounting`;
* `entity_hints = ["РБП"]`;
* `document_hints = ["Списание РБП"]`;
* `time_scope = "июль 2020"`;
* режим ответа — `partial_coverage`;
* в uncertainties присутствуют snapshot-only, ограниченный live probe, `matched_rows=0`, live evidence excluded, admissibility gate removed evidence.

Это и есть исходная точка, от которой строится пакет.

---

## 4. Главная рабочая гипотеза

Для РБП-кейса проблема сейчас не в одном месте, а в связке:

* **source coverage**: runtime не поднимает нужный набор сущностей по РБП;
* **route gap**: live path либо не выбирается, либо не ведёт к нужным данным;
* **evidence materialization**: даже если часть сигнала есть, он не превращается в admissible evidence.

Эта гипотеза должна быть либо подтверждена, либо опровергнута артефактами этого пакета.

---

# 5. Что нужно сделать

Пакет выполнить по 4 узлам.

---

# Узел A — восстановить минимальную предметную модель РБП

## Задача

Понять, **какие сущности и переходы вообще обязательны** для ответа на вопрос о “живущем дольше ожидаемого” РБП.

## Что сделать

Для кейса РБП определить:

### A1. Seed entities

* документ “Списание РБП за Июль 2020 г.”;
* суммы списания, включая 5 000;
* объект РБП / карточка РБП;
* период July 2020.

### A2. Required entities

Минимально установить, какие сущности нужны для доказательного ответа:

* документ списания РБП;
* объект(ы) РБП;
* движения/остатки по РБП;
* основание списания;
* expected schedule/lifecycle списания;
* хвост/остаток на конец июля;
* связанные регистры;
* проводки;
* month-close связка, если она обязательна.

### A3. Expected transitions

Зафиксировать обязательные переходы:

* объект РБП → документ списания;
* документ списания → движение/регистр/проводка;
* движение/остаток → состояние на конец июля;
* expected schedule → фактическое списание;
* июльский остаток → признак “живёт дольше ожидаемого”.

## Acceptance

* Для РБП должен появиться явный `required_entity_map`, а не общий доменный шум.
* Должно быть ясно, **без каких сущностей proof в принципе невозможен**.

---

# Узел B — аудит покрытия источника по РБП

## Задача

Понять, **есть ли вообще нужные данные**, и где именно они доступны.

## Что сделать

Проверить отдельно:

### B1. Snapshot coverage

* какие snapshot-файлы реально содержат данные по РБП;
* есть ли в них документ списания;
* есть ли объекты РБП;
* есть ли остатки/движения/проводки;
* хватает ли snapshot-only, чтобы ответить на вопрос.

### B2. Live coverage

* какие MCP/live методы позволяют добраться до РБП-данных;
* есть ли прямой путь до:

  * документа списания,
  * объекта РБП,
  * остатка на конец периода,
  * движения списания,
  * schedule/основания;
* что доступно напрямую, а что только через несколько шагов.

### B3. Coverage verdict

Для каждого обязательного элемента указать:

* `available_in_snapshot`
* `available_via_live`
* `available_but_not_used_by_runtime`
* `not_reachable_in_current_runtime`

## Acceptance

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

---

# Узел C — починить live route под РБП

## Задача

Сделать так, чтобы runtime **реально шёл** в нужный контур РБП, а не оставался на snapshot-only/semantic profile.

## Что сделать

1. Определить корректный `claim_type` для РБП-кейса, например:

   * `prove_rbp_tail_state`
   * `prove_rbp_lifecycle_overstay`
2. Для него прописать required live route:

   * первый вызов на документ списания;
   * второй на объект РБП;
   * третий на движения/остатки;
   * четвёртый на подтверждение конца периода / хвоста.
3. Проверить, что runtime действительно выбирает этот путь, а не остаётся в `canonical-only`.
4. В debug payload вывести:

   * `claim_type`
   * `required_live_calls`
   * `executed_live_calls`
   * `missing_live_calls`
   * `route_gap_reason`

## Acceptance

* У РБП-кейса должен появиться **непустой и осмысленный live call path**.
* Live path должен быть привязан к claim, а не быть декоративным probe.

---

# Узел D — materialization: превратить данные по РБП в admissible evidence

## Задача

Убрать главный провал: данные/сигналы есть или могут быть, но до admissible evidence они не доезжают.

## Что сделать

Для РБП-кейса восстановить полный путь:

`raw source result -> candidate evidence -> admissible evidence -> answer`

И по каждому шагу показать:

* что пришло;
* что было отрезано;
* почему было отрезано;
* что должно было стать admissible evidence, но не стало.

### Обязательно классифицировать причины reject-а

Использовать причины вида:

* `wrong_period`
* `wrong_domain`
* `weak_source_mapping`
* `zero_live_match`
* `missing_relation_reconstruction`
* `missing_required_anchor`
* `insufficient_object_identity`

### Цель

Не просто сделать `admissible > 0`, а понять, **какие именно evidence items должны считаться допустимыми для РБП proof**.

## Acceptance

* У РБП-кейса должно появиться **non-zero admissible evidence**, либо должно быть строго доказано, почему это невозможно на текущих данных.
* Ответ “нет admissible evidence” должен быть объясним именно через materialization path.

---

# Узел E — финальный proof contract по РБП

## Задача

Сделать так, чтобы answer mode по РБП зависел от фактического proof-path, а не от общей слабой гипотезы.

## Что сделать

Финальный ответ по РБП должен собираться так:

### Если admissible evidence есть

Ответ должен уметь сказать:

* какие объекты РБП подтверждены;
* по каким из них списание подтверждено;
* по каким виден хвост/остаток на конец июля;
* почему это похоже на “живёт дольше ожидаемого”.

### Если admissible evidence всё ещё нет

Ответ должен честно сказать:

* какое именно звено не удалось подтвердить;
* не просто “сигнал слабый”, а:

  * нет документа,
  * нет объекта,
  * нет движения,
  * нет остатка,
  * нет связи между ними.

## Acceptance

* РБП-кейс должен перестать быть общим lifecycle-туманом.
* Answer mode должен быть привязан к реальному состоянию claim-proof.

---

## 6. Проверки

Обязательно выполнить:

1. replay исходного РБП-вопроса;
2. debug/export после фикса;
3. live call inventory;
4. evidence conversion trace;
5. before/after по answer mode.

Желательно дополнительно:

* один соседний month-close кейс на sanity-check;
* один follow-up по тому же РБП-кейсу.

---

## 7. Метрики пакета

Добавить/обновить:

* `rbp_required_entity_coverage_rate`
* `rbp_live_route_execution_rate`
* `rbp_admissible_evidence_nonzero_rate`
* `rbp_source_to_proof_completion_rate`
* `rbp_partial_coverage_default_rate`
* `rbp_false_grounded_answer_rate`

### Минимальные пороги

* `rbp_required_entity_coverage_rate >= 0.9`
* `rbp_live_route_execution_rate >= 0.9`
* `rbp_admissible_evidence_nonzero_rate > 0`
* `rbp_false_grounded_answer_rate = 0`
* `rbp_partial_coverage_default_rate` должно снизиться относительно текущего live baseline

---

## 8. Обязательные артефакты

В новой run-папке положить:

1. `README.md`
2. `run_summary.json`
3. `rbp_source_coverage_report.md`
4. `rbp_live_route_report.md`
5. `rbp_evidence_materialization_report.md`
6. `rbp_claim_proof_report.md`
7. `rbp_before_after_matrix.md`
8. `chat_export_rbp.md`
9. `debug_payloads/`
10. `raw_live_calls/`
11. `rbp_required_entity_map.json`
12. `rbp_admissibility_reject_breakdown.json`

---

## 9. Что не делать

* не трогать НДС как главный фокус;
* не расползаться на общую архитектуру;
* не идти в новую большую волну по всем P0-доменам;
* не закрывать пакет по summary без replay РБП-кейса;
* не маскировать отсутствие данных красивым limited-answer.

---

## 10. Финальный verdict

В конце пакета выдать:

* `RBP_SOURCE_COVERAGE_FIXED / NOT_FIXED`
* `RBP_LIVE_ROUTE_FIXED / NOT_FIXED`
* `RBP_EVIDENCE_MATERIALIZATION_FIXED / NOT_FIXED`

И общий статус:

* `RBP_PACK_ACCEPTED`
* или `RBP_PACK_ACCEPTED_WITH_LIMITATIONS`
* или `RBP_PACK_NOT_ACCEPTED`

---

## 11. Ожидаемый результат

После этого пакета должно стать ясно:

* есть ли у вас вообще рабочий proof-path по РБП;
* можно ли из текущих данных построить доказательный ответ;
* если нельзя — это потому что данных реально нет, или потому что runtime не умеет до них дойти.

И главное:
по РБП должно стать **невозможно** говорить абстрактно “слабая доказательная база”.
Должно быть понятно, **что именно не доезжает и на каком узле**.

Если хочешь, следующим сообщением я дам ещё:

1. **понятное русское название этой волны**,
2. **текст коммита на 3–4 строки**.