Этап 4 / Пакет по РБП восстановление живого контура сбора данных и доказательной базы
This commit is contained in:
@@ -0,0 +1,448 @@
|
||||
разведку структуры 1С и связей через MCP по 3 контрольным кейсам.md
|
||||
|
||||
---
|
||||
|
||||
# ТЗ для Codex
|
||||
|
||||
## Этап 4 — разведка структуры 1С и связей через MCP по 3 контрольным кейсам
|
||||
|
||||
## Цель: понять, какие сущности, регистры, документы и переходы реально нужны для доказательного ответа
|
||||
|
||||
### 1. Контекст
|
||||
|
||||
Текущая проблема выглядит не как чисто текстовый дефект, а как сбой в контуре:
|
||||
|
||||
**вопрос → якоря → маршрут → данные 1С → связи между сущностями → evidence → ответ**
|
||||
|
||||
Есть подозрение, что система:
|
||||
|
||||
* не до конца понимает, какие объекты 1С нужны для ответа на конкретный тип вопроса;
|
||||
* не до конца понимает, как эти объекты связаны;
|
||||
* не всегда идёт в нужные документы/регистры через MCP;
|
||||
* даже когда данные приходят, не всегда умеет собрать из них admissible evidence.
|
||||
|
||||
Эта работа не про новый prompt и не про wording.
|
||||
Это **разведка структуры данных и зависимостей**.
|
||||
|
||||
---
|
||||
|
||||
## 2. Главная цель задания
|
||||
|
||||
Нужно не “починить ответы” и не “сделать ещё один rerun”, а:
|
||||
|
||||
### **Построить доказательную карту связей 1С по 3 типовым вопросам**
|
||||
|
||||
И ответить на вопросы:
|
||||
|
||||
1. какие сущности 1С реально участвуют в каждом кейсе;
|
||||
2. какие связи между ними обязательны;
|
||||
3. какие регистры и документы надо проходить;
|
||||
4. какие MCP-вызовы нужны, чтобы это собрать;
|
||||
5. где контур сейчас рвётся:
|
||||
|
||||
* источник,
|
||||
* маршрут,
|
||||
* mapping структуры 1С,
|
||||
* evidence materialization,
|
||||
* answer handoff.
|
||||
|
||||
---
|
||||
|
||||
## 3. Source of truth — 3 контрольных вопроса
|
||||
|
||||
### Вопрос 1 — НДС
|
||||
|
||||
**13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?**
|
||||
|
||||
### Вопрос 2 — РБП
|
||||
|
||||
**31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?**
|
||||
|
||||
### Вопрос 3 — Амортизация
|
||||
|
||||
**31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?**
|
||||
|
||||
Эти 3 вопроса являются **единственной обязательной базой** для текущей разведки.
|
||||
|
||||
---
|
||||
|
||||
## 4. Что нельзя делать
|
||||
|
||||
1. Не пытаться описать “всю 1С целиком”.
|
||||
2. Не делать общую энциклопедию регистров.
|
||||
3. Не уходить в redesign архитектуры.
|
||||
4. Не строить новый proof engine.
|
||||
5. Не ограничиваться пересказом старых отчётов.
|
||||
6. Не делать выводы без артефактов.
|
||||
7. Не “гулять по базе” без цели — только от вопроса к связанным сущностям.
|
||||
|
||||
---
|
||||
|
||||
## 5. Что нужно сделать
|
||||
|
||||
Работу нужно провести по 5 узлам.
|
||||
|
||||
---
|
||||
|
||||
# Узел A — Построить карту обязательных сущностей для каждого вопроса
|
||||
|
||||
Для каждого из 3 вопросов определить:
|
||||
|
||||
### A1. Seed entities
|
||||
|
||||
С чего начинается поиск:
|
||||
|
||||
* документ;
|
||||
* контрагент;
|
||||
* договор;
|
||||
* объект расчётов;
|
||||
* объект РБП;
|
||||
* объект ОС;
|
||||
* номенклатура;
|
||||
* проводка;
|
||||
* регистр.
|
||||
|
||||
### A2. Required entities
|
||||
|
||||
Какие сущности обязательно нужны для ответа.
|
||||
|
||||
#### Для НДС-кейса
|
||||
|
||||
Минимально проверить:
|
||||
|
||||
* документ поступления;
|
||||
* документ реализации;
|
||||
* счёт-фактура;
|
||||
* движения по НДС;
|
||||
* проводки;
|
||||
* запись книги покупок / продаж;
|
||||
* связь между документами и регистрами;
|
||||
* мебельные позиции / номенклатура / объект товара;
|
||||
* контрагент / договор / документная цепочка.
|
||||
|
||||
#### Для РБП-кейса
|
||||
|
||||
Минимально проверить:
|
||||
|
||||
* документ списания РБП;
|
||||
* объект РБП;
|
||||
* движения по РБП;
|
||||
* остаток/хвост на конец июля;
|
||||
* основание и график списания;
|
||||
* связанный month-close контур;
|
||||
* проводки / регистры / документы подтверждения.
|
||||
|
||||
#### Для амортизации
|
||||
|
||||
Минимально проверить:
|
||||
|
||||
* объекты ОС;
|
||||
* документ начисления амортизации;
|
||||
* движения начисления;
|
||||
* expected set объектов на июль;
|
||||
* фактическое попадание в начисление;
|
||||
* проводки;
|
||||
* остаточные хвосты / пропуски по объектам.
|
||||
|
||||
### A3. Expected transitions
|
||||
|
||||
Для каждого вопроса зафиксировать:
|
||||
|
||||
* какие переходы между сущностями **обязательны**,
|
||||
* какие переходы являются “смежным контуром”,
|
||||
* какие missing transitions означают реальную проблему.
|
||||
|
||||
---
|
||||
|
||||
# Узел B — Проверить, что из этого реально есть в snapshot и что реально доступно через MCP
|
||||
|
||||
### B1. Snapshot coverage
|
||||
|
||||
Для каждого вопроса определить:
|
||||
|
||||
* какие snapshot-источники реально содержат нужные сущности;
|
||||
* достаточно ли snapshot-only для ответа;
|
||||
* какие части цепочки snapshot не покрывает.
|
||||
|
||||
### B2. MCP/live coverage
|
||||
|
||||
Для каждого вопроса определить:
|
||||
|
||||
* какие MCP-методы/запросы позволяют добыть нужные сущности;
|
||||
* что доступно напрямую;
|
||||
* что доступно только через несколько переходов;
|
||||
* где нужны пошаговые адресные вызовы.
|
||||
|
||||
### B3. Coverage verdict
|
||||
|
||||
По каждому вопросу дать жёсткий ответ:
|
||||
|
||||
* `snapshot_sufficient`
|
||||
* `live_required`
|
||||
* `snapshot_plus_live_required`
|
||||
* `data_not_reachable_in_current_runtime`
|
||||
|
||||
---
|
||||
|
||||
# Узел C — Построить карту связей между элементами 1С
|
||||
|
||||
Это ключевая часть задания.
|
||||
|
||||
Нужно не просто перечислить сущности, а построить **relation map**.
|
||||
|
||||
### Для каждого вопроса определить:
|
||||
|
||||
1. какие связи прямые:
|
||||
|
||||
* документ → проводка
|
||||
* документ → счёт-фактура
|
||||
* документ → регистр
|
||||
* объект → начисление
|
||||
* списание → остаток
|
||||
2. какие связи косвенные:
|
||||
|
||||
* договор → расчёты → документ
|
||||
* номенклатура → документ поступления → реализация
|
||||
* объект ОС → амортизационный контур
|
||||
3. какие связи обязательны для доказательства;
|
||||
4. какие связи являются “смежным контуром”, но не ядром ответа;
|
||||
5. какие связи невозможно восстановить текущими средствами.
|
||||
|
||||
### Формат
|
||||
|
||||
Не “словесное описание”, а нормальная матрица:
|
||||
|
||||
* `entity_A`
|
||||
* `entity_B`
|
||||
* `relation_type`
|
||||
* `required_for_claim`
|
||||
* `reachable_via_snapshot`
|
||||
* `reachable_via_live`
|
||||
* `current_runtime_uses_it`
|
||||
* `notes`
|
||||
|
||||
---
|
||||
|
||||
# Узел D — Проверить реальные маршруты через MCP
|
||||
|
||||
Codex должен не гадать, а **пройти по MCP/1С и проверить**.
|
||||
|
||||
### Для каждого вопроса:
|
||||
|
||||
1. какие вызовы реально нужны;
|
||||
2. в каком порядке их нужно делать;
|
||||
3. какие аргументы нужны;
|
||||
4. какие из них сейчас реально используются runtime;
|
||||
5. каких вызовов не хватает;
|
||||
6. какие вызовы возвращают шум вместо полезной опоры;
|
||||
7. где вызов правильный, но не хватает связи к следующему узлу.
|
||||
|
||||
### Нужен результат в форме:
|
||||
|
||||
* `question`
|
||||
* `required_live_calls`
|
||||
* `current_live_calls`
|
||||
* `missing_live_calls`
|
||||
* `wrong_live_calls`
|
||||
* `call_sequence_for_proof`
|
||||
|
||||
---
|
||||
|
||||
# Узел E — Построить source-to-proof failure map
|
||||
|
||||
Для каждого из 3 вопросов нужно финально ответить:
|
||||
|
||||
### Что система должна была сделать
|
||||
|
||||
Например:
|
||||
|
||||
* для НДС — собрать цепочку документ → проводка → НДС-регистр → книга;
|
||||
* для РБП — доказать, что часть РБП осталась жить дольше ожидаемого;
|
||||
* для амортизации — доказать полноту/неполноту охвата объектов ОС.
|
||||
|
||||
### Что система реально смогла поднять
|
||||
|
||||
* какие объекты;
|
||||
* какие регистры;
|
||||
* какие связи;
|
||||
* какие evidence items.
|
||||
|
||||
### Где контур рвётся
|
||||
|
||||
Использовать такие категории:
|
||||
|
||||
* `missing_source_data`
|
||||
* `source_exists_but_runtime_does_not_use_it`
|
||||
* `wrong_route_selection`
|
||||
* `wrong_entity_mapping`
|
||||
* `missing_relation_reconstruction`
|
||||
* `live_call_insufficient_for_proof`
|
||||
* `evidence_not_materialized`
|
||||
* `claim_anchor_coverage_insufficient`
|
||||
* `answer_layer_cannot_close_proof`
|
||||
|
||||
---
|
||||
|
||||
## 6. Как выполнять работу
|
||||
|
||||
### Этап 1 — Статический проход по коду
|
||||
|
||||
Понять:
|
||||
|
||||
* какие модули отвечают за source selection;
|
||||
* какие — за MCP/live;
|
||||
* какие — за mapping сущностей;
|
||||
* какие — за evidence packaging;
|
||||
* какие — за admissibility и answer mode.
|
||||
|
||||
### Этап 2 — Инвентаризация данных
|
||||
|
||||
Проверить:
|
||||
|
||||
* какие snapshot-файлы реально участвуют;
|
||||
* что в них лежит;
|
||||
* какие live endpoints/методы реально доступны.
|
||||
|
||||
### Этап 3 — Целевая разведка по 3 вопросам
|
||||
|
||||
Не общая прогулка по базе, а **управляемое движение от вопроса к связанным объектам**.
|
||||
|
||||
### Этап 4 — Relation reconstruction
|
||||
|
||||
Построить карту обязательных связей по каждому вопросу.
|
||||
|
||||
### Этап 5 — Failure classification
|
||||
|
||||
Показать, на каком узле реальный обрыв.
|
||||
|
||||
---
|
||||
|
||||
## 7. Что нужно создать
|
||||
|
||||
Создать новый комплект в `docs/ARCH`.
|
||||
|
||||
### Основной отчёт
|
||||
|
||||
`docs/ARCH/9 - разведка_структуры_1с_и_связей_через_mcp_по_3_контрольным_вопросам_2026-03-29.md`
|
||||
|
||||
---
|
||||
|
||||
## 8. Обязательные приложения
|
||||
|
||||
### `9A - entity_seed_map.md`
|
||||
|
||||
Для каждого вопроса:
|
||||
|
||||
* seed entities
|
||||
* required entities
|
||||
* expected transitions
|
||||
|
||||
### `9B - snapshot_vs_live_coverage_map.md`
|
||||
|
||||
Что реально есть в snapshot и что реально добывается через live.
|
||||
|
||||
### `9C - relation_map_1c_entities.md`
|
||||
|
||||
Карта связей между сущностями 1С по 3 кейсам.
|
||||
|
||||
### `9D - mcp_query_recipes.md`
|
||||
|
||||
Какие MCP-вызовы нужны для доказательного ответа по каждому кейсу.
|
||||
|
||||
### `9E - source_to_proof_failure_map.md`
|
||||
|
||||
Где именно рвётся контур по каждому вопросу.
|
||||
|
||||
### `9F - current_runtime_vs_required_runtime.md`
|
||||
|
||||
Сравнение:
|
||||
|
||||
* что нужно было сделать;
|
||||
* что делает текущий runtime.
|
||||
|
||||
---
|
||||
|
||||
## 9. Папка артефактов
|
||||
|
||||
`docs/ARCH/9_audit_artifacts/`
|
||||
|
||||
Обязательно положить:
|
||||
|
||||
* `chat_export_3_questions.md`
|
||||
* `debug_payloads/`
|
||||
* `raw_live_calls/`
|
||||
* `snapshot_samples/`
|
||||
* `relation_probe_logs/`
|
||||
* `query_recipe_examples/`
|
||||
* `replay_logs/`
|
||||
|
||||
---
|
||||
|
||||
## 10. Главные вопросы, на которые отчёт обязан ответить
|
||||
|
||||
### По НДС
|
||||
|
||||
* какие сущности и регистры реально нужны;
|
||||
* как они связаны;
|
||||
* почему positive path уже работает или где ещё шум;
|
||||
* что ещё надо дочистить.
|
||||
|
||||
### По РБП
|
||||
|
||||
* есть ли в source нужные данные вообще;
|
||||
* есть ли путь к ним через MCP;
|
||||
* где рвётся связка `source coverage + route + evidence materialization`.
|
||||
|
||||
### По амортизации
|
||||
|
||||
* какие объекты ОС должны участвовать;
|
||||
* как понять expected coverage;
|
||||
* почему admissible evidence уже есть, но proof не замыкается;
|
||||
* где именно не хватает mapping/anchors.
|
||||
|
||||
---
|
||||
|
||||
## 11. Итоговый общий verdict
|
||||
|
||||
В конце основного отчёта обязательно выдать один из вердиктов:
|
||||
|
||||
* `SOURCE_COVERAGE_IS_PRIMARY_PROBLEM`
|
||||
* `MCP_ROUTE_IS_PRIMARY_PROBLEM`
|
||||
* `ONE_C_RELATION_MAPPING_IS_PRIMARY_PROBLEM`
|
||||
* `EVIDENCE_MATERIALIZATION_IS_PRIMARY_PROBLEM`
|
||||
* `MULTI_NODE_FAILURE_CONFIRMED`
|
||||
|
||||
И отдельно по каждому из 3 вопросов дать свой локальный verdict.
|
||||
|
||||
---
|
||||
|
||||
## 12. Критерий качества
|
||||
|
||||
После выполнения этой работы должно стать **невозможно** говорить расплывчато:
|
||||
“кажется, плохо работаем с источником”.
|
||||
|
||||
Вместо этого должно быть ясно:
|
||||
|
||||
* какие данные нужны;
|
||||
* где они лежат;
|
||||
* как они связаны;
|
||||
* как до них идти через MCP;
|
||||
* где текущий runtime теряет их;
|
||||
* что конкретно чинить следующим пакетом.
|
||||
|
||||
---
|
||||
|
||||
## 13. Что должно получиться на выходе
|
||||
|
||||
Не новая волна фиксов, а **карта реальных зависимостей** и **точная карта поломки** по трём кейсам.
|
||||
|
||||
После этого должно быть понятно:
|
||||
|
||||
1. надо ли делать отдельный pack на source coverage;
|
||||
2. надо ли делать pack на relation mapping 1С;
|
||||
3. надо ли делать pack на evidence materialization;
|
||||
4. можно ли РБП и амортизацию чинить отдельно, а НДС только дочищать.
|
||||
|
||||
---
|
||||
|
||||
Если хочешь, следующим сообщением я дам ещё **короткое русское название этой работы для коммита/задачи** и **сверхкороткую версию промпта для Codex** без длинного ТЗ.
|
||||
@@ -0,0 +1,388 @@
|
||||
Этап 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 строки**.
|
||||
Reference in New Issue
Block a user