389 lines
15 KiB
Markdown
389 lines
15 KiB
Markdown
Этап 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 строки**.
|