Этап 4 corrective pack 2 по family isolation после текущих routing fixes

IN/Stage 4 - Family Card v1 FA.md

@@ -0,0 +1,251 @@
+# Stage 4 - Family Card v1 — FA amortization coverage (runtime-aligned)
+
+**document_status:** `ACTIVE`  
+**family_name:** `Амортизация ОС — полнота охвата / риск пропуска объекта`  
+**family_id:** `FA_AMORTIZATION_COVERAGE_V1`  
+**stage_scope:** `Stage 4 (P0-only)`  
+**current_family_status:** `PROOF_PATH_RAISED_LIVE_ACCEPTANCE_PENDING`  
+**primary_gap:** `live object-level relation clarity + production live acceptance`  
+**latest_pack:** `2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure`  
+**next_pack_focus:** `live replay acceptance + relation/anchor consistency in production channel`  
+**family_source_of_truth_questions:** `FA-Q1 (31 июля: 2 471,52 / 2 465,28 / 849,83 — полное ли начисление); FA-Q2 (expected vs actual set по объектам ОС за июль); FA-Q3 (есть ли missing object candidates в июльском начислении)`  
+**family_latest_live_replay:** `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure_live_attempt\fa_live_raw.json (текущий live attempt: http_status=400, невалидная приемка)`  
+**family_latest_acceptance_run:** `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure\run_summary.json`
+
+## 1) Что фиксирует этот документ
+
+Карточка разделяет два слоя:
+
+1. `Runtime V1 (as-is)` — только то, что подтверждено текущим кодом и артефактами пакета.
+2. `Target V2 (planned)` — что нужно дожать, но пока не считается текущим acceptance gate.
+
+Это защищает от ложного закрытия family по mock-результату без live-приемки.
+
+## 2) Runtime V1 (фактический контракт на 2026-03-29)
+
+### 2.1 Claim contract (as-is)
+
+- **primary claim_type:** `prove_fixed_asset_amortization_coverage`
+- **additional claim_types:** пока не выделялись как отдельные first-class claim types
+- **границы claim:**
+- не расширяет домены за рамки Stage 4 P0;
+- не вводит новый proof engine;
+- не использует Stage 5 investigation как core path.
+
+### 2.2 Required anchors (runtime-enforced, as-is)
+
+Для `prove_fixed_asset_amortization_coverage` в рантайме обязательны:
+
+- `period`
+- `fixed_asset_signal`
+- `amortization_signal`
+- `amount_or_document`
+- `account_scope_or_document_type`
+
+Факт по latest acceptance run:
+
+- `required_anchors_count = 5`
+- `missing_anchor_classes_count = 0`
+- `claim_anchor_coverage_ratio = 1`
+
+### 2.3 Claim-bound live recipe (runtime-enforced, as-is)
+
+Обязательные live вызовы:
+
+1. `find_amortization_documents_in_period`
+2. `find_fixed_asset_movements_accounts_01_02`
+3. `find_fixed_asset_cards_expected_for_period`
+4. `match_expected_vs_actual_fa_coverage`
+
+Ожидаемый результат recipe:
+
+- документ(ы) начисления амортизации;
+- candidate/actual набор объектов ОС;
+- expected set для периода;
+- сравнение expected vs actual и кандидаты пропуска.
+
+### 2.4 Route behavior (as-is)
+
+Для FA-claim runtime:
+
+- форсирует claim-bound live-capable route;
+- может переопределять `store_feature_risk` в live/hybrid path;
+- экспортирует `fa_live_route_audit` в debug payload.
+
+Факт по latest acceptance run:
+
+- `live_route_execution_rate = 1`
+- `required_live_calls = 4`
+- `missing_live_calls = 0`
+- `route_adjustments_applied = 1`
+
+### 2.5 Evidence/admissibility behavior (as-is)
+
+Факт по latest acceptance run:
+
+- `admissible_evidence_count = 16`
+- `rejected_evidence_count = 32`
+- reject breakdown: `wrong_account_scope = 16`, `weak_source_mapping = 16`
+
+Факт по targeted evidence:
+
+- `targeted_evidence_hit_rate = 1`
+- `expected_fa_set_count = 2`
+- `actual_fa_set_count = 2`
+- `missing_fa_candidates_count = 0`
+- `uncertain_fa_candidates_count = 28`
+
+### 2.6 Runtime acceptance snapshot (по latest pack)
+
+- `FA_EXPECTED_SET_FIXED = FIXED`
+- `FA_RELATION_MAPPING_FIXED = FIXED`
+- `FA_CLAIM_ANCHOR_CLOSURE_FIXED = FIXED`
+- `FA_PROOF_CLOSURE_FIXED = FIXED`
+- общий статус: `FA_PACK_ACCEPTED`
+- важная оговорка: режим пакета `mock` (controlled replay)
+
+### 2.7 known_runtime_limits (as-is)
+
+- `live acceptance pending`: актуальный live attempt завершился `http_status=400`, не может быть источником приемки.
+- `relation clarity incomplete`: несмотря на coverage=1 в mock, в relation map много `coverage_status=uncertain` и слабых object-level link.
+- `admissibility noise remains`: значимый reject-шум (`wrong_account_scope`, `weak_source_mapping`) сохраняется и требует дожима для production live.
+
+## 3) Target V2 (planned, не критерий текущей приемки)
+
+### 3.1 Planned claim extension
+
+- Развести подтипы FA-claim по режимам:
+- `prove_fixed_asset_amortization_completeness`
+- `prove_fixed_asset_missing_object_risk`
+- `prove_fixed_asset_expected_actual_consistency`
+
+### 3.2 Planned anchor extension
+
+- Явный `expected_fa_set` как first-class anchor.
+- Явный `actual_fa_set_from_amortization` как first-class anchor.
+- Явный `missing_fa_candidates` с object identity и link quality.
+
+### 3.3 Planned family metrics
+
+- `fa_expected_set_reconstruction_rate`
+- `fa_relation_mapping_coverage_rate`
+- `fa_claim_anchor_coverage_rate`
+- `fa_actual_vs_expected_comparison_rate`
+- `fa_proof_closure_rate`
+- `fa_false_grounded_answer_rate`
+- `fa_live_acceptance_pass_rate`
+
+## 4) Required entities and relations (business contract)
+
+### 4.1 Минимально необходимые сущности для proof closure
+
+1. Документ(ы) начисления амортизации за июль.
+2. Объекты ОС, которые должны участвовать в начислении.
+3. Движения/проводки по контуру амортизации (в т.ч. счета 01/02).
+4. Expected set объектов ОС на период.
+5. Actual set объектов, реально попавших в начисление.
+6. Missing/uncertain candidates для object-level verdict.
+
+### 4.2 Критические relation links
+
+1. `fa_object -> amortization_document`
+2. `amortization_document -> movement/posting`
+3. `fa_object -> expected_period_coverage`
+4. `expected_set -> actual_set`
+5. `missing_or_uncertain_object -> coverage_risk_verdict`
+
+## 5) Snapshot/Live coverage verdict (as-is)
+
+- По FA family практический режим: `snapshot_plus_live_required`.
+- В controlled replay proof-path поднят до `grounded_positive`.
+- Production live приемка пока не закрыта.
+
+## 6) Answer/proof modes contract
+
+### `grounded_positive`
+
+Допускается, если одновременно:
+
+- `admissible_evidence_count > 0`
+- реконструированы `expected_fa_set` и `actual_fa_set`
+- сделано сравнение expected vs actual
+- вывод имеет object-level опору, не только сумму
+- `false_grounded_answer_rate = 0`
+
+Короткий пример:
+
+- `За июль подтверждены ожидаемый и фактический наборы ОС; пропусков по зафиксированным объектам не выявлено, риск неполноты начисления низкий.`
+
+### `limited_or_insufficient_evidence`
+
+Обязателен, если:
+
+- не реконструирован expected set или actual set
+- object-level links недостаточны
+- есть только косвенная/шумная опора
+
+Короткий пример:
+
+- `Суммы начисления зафиксированы, но object-level соответствие expected vs actual не восстановлено; вывод ограничен и не подтверждает полноту начисления.`
+
+### Запрещенные паттерны
+
+- вывод о полноте начисления только по суммам без object-level связи
+- уверенный verdict при `admissible = 0`
+- общий lifecycle-текст без указания missing object/link
+
+Короткий антипример:
+
+- `Амортизация начислена корректно, пропусков нет` (нельзя без expected/actual object-level proof).
+
+## 7) Gap register (FA family)
+
+| gap_id | category | severity | current_state | note |
+| --- | --- | --- | --- | --- |
+| FA-G1 | `live_acceptance_not_confirmed` | blocker | open | текущий live attempt дал `http_status=400`, приемка фактически mock-only |
+| FA-G2 | `wrong_entity_mapping` / `relation_clarity` | high | open | в relation map много `coverage_status=uncertain` и слабых direct links |
+| FA-G3 | `admissibility_reject_not_due_to_data` | medium | open | reject-шум по `wrong_account_scope` и `weak_source_mapping` |
+| FA-G4 | `answer_layer_underuses_available_evidence` | medium | partial | в части трасс answer-mode может звучать ограничительно при сильной eligibility |
+
+## 8) Code-path inventory (где живет контракт)
+
+- `llm_normalizer/backend/src/services/assistantClaimBoundEvidence.ts`
+- FA claim resolution;
+- required anchors;
+- targeted checks;
+- expected/actual/missing/uncertain FA coverage structures.
+
+- `llm_normalizer/backend/src/services/assistantDataLayer.ts`
+- claim-bound FA live plan;
+- live call profile `claim_bound_fa_live_path`;
+- relation markers (`asset_card_to_depreciation`, `document_to_posting`).
+
+- `llm_normalizer/backend/src/services/assistantService.ts`
+- FA live route enforcement;
+- route override audit (`fa_live_route_audit`);
+- handoff в eligibility/answer layer.
+
+- run artifacts:
+- `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure`
+- `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure_live_attempt`
+- `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_FA_Pack_Amortization_Proof_Closure_mock_replay`
+
+## 9) Regression set and acceptance policy
+
+Обязательный минимум для FA family:
+
+1. Базовый вопрос по трем суммам `2 471,52 / 2 465,28 / 849,83`.
+2. Вариация без сумм, но с запросом полноты expected vs actual.
+3. Вариация на missing-object risk.
+4. Follow-up по конкретному объекту ОС (если объект выделен).
+
+Политика:
+
+- после каждого FA pack обязателен новый run folder в `llm_normalizer/docs/runs`;
+- acceptance фиксируется на уровне family;
+- mock acceptance не заменяет live acceptance;
+- `false_grounded` должен оставаться нулевым.
+
+## 10) Project decision line for this family
+
+FA family поднята до proof-ready уровня в controlled replay, но остается в статусе `live acceptance pending` до подтверждения object-level closure на реальном live канале.

IN/Stage 4 - Family Card v1 RBP.md

@@ -0,0 +1,240 @@
+# Stage 4 - Family Card v1 — RBP tail / write-off overstay (runtime-aligned)
+
+**document_status:** `ACTIVE`  
+**family_name:** `РБП — хвост / списание / overstay`  
+**family_id:** `RBP_TAIL_WRITEOFF_OVERSTAY_V1`  
+**stage_scope:** `Stage 4 (P0-only)`  
+**current_family_status:** `ACCEPTED_WITH_LIMITATIONS`  
+**primary_gap:** `source coverage`  
+**latest_pack:** `2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix`  
+**next_pack_focus:** `source coverage recovery + route tightening for full claim closure`  
+**family_source_of_truth_questions:** `RBP-Q1 (Списание РБП за Июль 2020, включая 5 000); RBP-Q2 (хвост РБП к концу июля без суммы); RBP-Q3 (полнота закрытия июльского списания)`  
+**family_latest_live_replay:** `2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix/1.txt (локальный replay; внешний live-канал требует отдельной приемки)`  
+**family_latest_acceptance_run:** `2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix/run_summary.json`
+
+## 1) Что фиксирует этот документ
+
+Карточка теперь разделяет два слоя:
+
+1. `Runtime V1 (as-is)` — только то, что уже реально работает в коде и подтверждено артефактами.
+2. `Target V2 (planned)` — что хотим довести в следующих pack, но пока не считаем критерием текущей приемки.
+
+Это нужно, чтобы не смешивать факт и план и не закрывать family “по красивому тексту”.
+
+## 2) Runtime V1 (фактический контракт на 2026-03-29)
+
+### 2.1 Claim contract (as-is)
+
+- **primary claim_type:** `prove_rbp_tail_state`
+- **additional claim_types:** пока не first-class в runtime (учитываются как план V2)
+- **границы claim:**
+- не включает Stage 5 investigation как core path;
+- не расширяет домены за пределы Stage 4 P0;
+- не делает full redesign proof engine.
+
+### 2.2 Required anchors (runtime-enforced, as-is)
+
+Для `prove_rbp_tail_state` в рантайме обязательны:
+
+- `period`
+- `rbp_signal`
+- `writeoff_signal`
+
+Технические reason codes на этом шаге:
+
+- `claim_missing_required_anchors`
+- `claim_anchor_resolution_low`
+
+### 2.3 Claim-bound live recipe (runtime-enforced, as-is)
+
+Обязательные live вызовы:
+
+1. `find_rbp_writeoff_documents_in_period`
+2. `find_rbp_object_movements_account_97`
+3. `find_month_close_entries_linked_to_rbp`
+4. `compute_end_period_residual_by_rbp_object`
+
+Ожидаемый результат recipe:
+
+- подтверждение документа списания;
+- привязка к объекту(ам) РБП;
+- движение/связанные записи;
+- residual state на границе периода.
+
+### 2.4 Route behavior (as-is)
+
+Для `prove_rbp_tail_state` runtime:
+
+- форсирует live-capable маршрут (`hybrid_store_plus_live` / `live_mcp_drilldown`);
+- поднимает `insufficient_specificity` в live path вместо `no_route`;
+- экспортирует `rbp_live_route_audit` в debug payload.
+
+### 2.5 Evidence/admissibility behavior (as-is)
+
+Подтверждено в текущем пакете:
+
+- убрана инъекция raw live rows при `matched_rows = 0`;
+- добавлена стабилизированная live metadata для source mapping;
+- claim-bound targeted checks для RBP расширены до object/document/movement/residual.
+
+Наблюдаемые baseline reject reasons (до фикса пакета):
+
+- `zero_live_match`
+- `weak_source_mapping`
+- `wrong_account_scope`
+
+### 2.6 Runtime acceptance snapshot (по артефактам latest pack)
+
+- `RBP_SOURCE_COVERAGE_FIXED = NOT_FIXED`
+- `RBP_LIVE_ROUTE_FIXED = FIXED`
+- `RBP_EVIDENCE_MATERIALIZATION_FIXED = FIXED`
+- общий статус: `RBP_PACK_ACCEPTED_WITH_LIMITATIONS`
+
+### 2.7 known_runtime_limits (as-is)
+
+- `source coverage incomplete`: для части object-level proof звеньев данные в runtime source set еще неполные.
+- `business scope inconsistency possible`: в части live traces возможна несогласованность `generic_accounting` vs `company_specific_accounting`.
+- `anchor noise in edge cases`: в отдельных кейсах могут появляться нерелевантные account hints, влияющие на route profile.
+
+## 3) Target V2 (planned, не критерий текущей приемки)
+
+### 3.1 Planned claim extension
+
+Дополнительные claim types (план):
+
+- `prove_rbp_writeoff_completeness`
+- `prove_rbp_lifecycle_overstay`
+- `prove_rbp_period_end_residual_state`
+
+### 3.2 Planned anchor extension
+
+Расширенный target-набор anchors (план):
+
+- период (primary + period-end)
+- суммы/диапазоны
+- объект РБП
+- документ/тип документа
+- движения/остаток на конец периода
+- lifecycle markers для overstay
+
+### 3.3 Planned family metrics
+
+Плановые family-метрики (в stable harness):
+
+- `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`
+
+До формализации в harness эти метрики считаются target-моделью, а не текущим hard gate.
+
+## 4) Required entities and relations (business contract)
+
+### 4.1 Минимально необходимые сущности для proof closure
+
+1. Документ `Списание РБП` за целевой период.
+2. Объект(ы) РБП.
+3. Движения/регистровые записи по списанию.
+4. Residual state на конец периода.
+5. Связь со стадией month-close при необходимости.
+
+### 4.2 Критические relation links
+
+1. `RBP object -> writeoff document`
+2. `writeoff document -> movement/register record`
+3. `movement/register record -> period-end residual`
+4. `expected lifecycle -> actual lifecycle result`
+5. `residual state -> overstay/no-overstay verdict`
+
+## 5) Snapshot/Live coverage verdict (as-is)
+
+- `snapshot-only` для RBP сейчас **недостаточен** для устойчивого object-level proof closure.
+- Family требует `snapshot_plus_live_required`.
+- Главный незакрытый узел — source coverage в production live данных.
+
+## 6) Answer/proof modes contract
+
+### `grounded_positive`
+
+Допускается, если одновременно:
+
+- `admissible_evidence_count > 0`
+- закрыта цепочка object/document/movement/residual
+- вывод опирается на конкретные source refs
+- `false_grounded_answer_rate = 0`
+
+Короткий пример:
+
+- `Подтвержден документ "Списание РБП" за июль 2020, найден связанный объект РБП и остаток на конец периода = 0; признаков overstay по этому объекту не выявлено.`
+
+### `limited_or_insufficient_evidence`
+
+Обязателен, если:
+
+- не найден ключевой link (document/object/residual)
+- admissible evidence недостаточно
+- нет права имитировать доказанность
+
+Короткий пример:
+
+- `Документ списания найден, но связь с объектом РБП и подтвержденный остаток на конец периода не восстановлены; вывод ограничен до partial coverage без утверждения об overstay.`
+
+### Запрещенные паттерны
+
+- общий lifecycle narrative без указания missing link
+- уверенный вывод при `admissible = 0`
+- смешивание snapshot-гипотез с live-доказанностью без маркировки
+
+Короткий антипример:
+
+- `Есть признаки проблемы по РБП, вероятно хвост остался` (нельзя без document/object/residual подтверждения).
+
+## 7) Gap register (RBP family)
+
+| gap_id | category | severity | current_state | note |
+| --- | --- | --- | --- | --- |
+| RBP-G1 | `missing_source_data` / `source_coverage` | blocker | open | ключевая причина `ACCEPTED_WITH_LIMITATIONS` |
+| RBP-G2 | `business_scope_resolution_consistency` | high | open | в отдельных live traces встречается несогласованность generic/company-specific слоев |
+| RBP-G3 | `anchor_quality` | medium | open | в отдельных кейсах попадают нерелевантные account hints, что ухудшает route profile |
+
+## 8) Code-path inventory (где живет контракт)
+
+- `llm_normalizer/backend/src/services/assistantClaimBoundEvidence.ts`
+- claim type resolution;
+- required anchors для `prove_rbp_tail_state`;
+- anchor resolution rate и claim reason codes.
+
+- `llm_normalizer/backend/src/services/assistantDataLayer.ts`
+- claim-bound live plan для RBP;
+- обязательные live call ids и account scope overrides;
+- source profile `claim_bound_rbp_live_path`.
+
+- `llm_normalizer/backend/src/services/assistantService.ts`
+- RBP live route enforcement;
+- no-route recovery;
+- `rbp_live_route_audit` export.
+
+- run artifacts:
+- `llm_normalizer/docs/runs/2026-03-29_Stage_04_RBP_Pack_Live_Source_To_Proof_Fix`
+
+## 9) Regression set and acceptance policy
+
+Обязательный минимум для family replay:
+
+1. Базовый RBP вопрос: `Списание РБП за Июль 2020`, включая сумму `5 000`.
+2. Вариация без суммы (проверка period + overstay signal).
+3. Вариация на полноту закрытия.
+4. Follow-up по тому же документу/объекту.
+5. Соседний month-close sanity case.
+
+Политика:
+
+- после каждого family pack обязателен новый run folder в `llm_normalizer/docs/runs`;
+- приемка фиксируется на уровне family, не одиночного вопроса;
+- `false_grounded` должен оставаться нулевым.
+
+## 10) Project decision line for this family
+
+RBP уже перешел в family-based execution контур Stage 4, но остается в статусе `accepted_with_limitations` до восстановления source coverage в живом канале.

IN/Stage 4 - Family Card v1 — VAT chain.md

@@ -0,0 +1,230 @@
+# Stage 4 - Family Card v1 — VAT chain (runtime-aligned)
+
+**document_status:** `ACTIVE`  
+**family_name:** `НДС-цепочка — полнота прохождения от документа до налогового отражения`  
+**family_id:** `VAT_CHAIN_COMPLETENESS_V1`  
+**stage_scope:** `Stage 4 (P0-only)`  
+**current_family_status:** `PARTIALLY_WORKING / NON-BLOCKER`  
+**primary_gap:** `residual admissibility/materialization quality`  
+**latest_pack:** `2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt`  
+**next_pack_focus:** `targeted live narrowing + reject cleanup for VAT proof-path`  
+**family_source_of_truth_questions:** `VAT-Q1 (13 июля поступление, 15 июля реализация — полная ли НДС-цепочка); VAT-Q2 (есть ли выпадение между документом, проводкой, НДС-регистром и книгой); VAT-Q3 (по July 2020 VAT path grounded-positive или остаются weak-mapping шумы)`  
+**family_latest_live_replay:** `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\1_live_replay.txt`  
+**family_latest_acceptance_run:** `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt\run_summary.json`
+
+## 1) Что фиксирует этот документ
+
+Карточка разделяет два слоя:
+
+1. `Runtime V1 (as-is)` — только то, что подтверждено текущим кодом и run-артефактами.
+2. `Target V2 (planned)` — что нужно дожать следующими family-pack, но пока не является hard gate текущей приемки.
+
+Это соответствует Stage 4 family-based execution в рамках `P0-only` без перехода в Stage 5 и без архитектурного redesign.
+
+## 2) Runtime V1 (фактический контракт на 2026-03-29)
+
+### 2.1 Claim contract (as-is)
+
+- **primary claim_type:** `prove_vat_chain_completeness`
+- **additional claim_types:** пока не выделялись как first-class в runtime
+- **границы claim:**
+- не расширяет домены за рамки VAT family;
+- не включает общий налоговый аудит;
+- не включает Stage 5 investigation как core path.
+
+### 2.2 Required anchors (runtime-enforced, as-is)
+
+Для `prove_vat_chain_completeness` в текущем runtime обязательны:
+
+- `period`
+- `document_types`
+- `vat_signal`
+- `chain_signal`
+
+Факт: эти anchors соответствуют текущему `requiredByClaim` в runtime.
+
+### 2.3 Claim checks and live recipe (runtime-enforced, as-is)
+
+Для VAT claim runtime требует закрытия проверок:
+
+1. `source_document_found`
+2. `invoice_found`
+3. `tax_register_entry_found`
+4. `book_entry_found`
+5. `chain_linkage_status`
+
+Текущий live acquisition path для VAT в runtime:
+
+- в отличие от RBP/FA, нет выделенного VAT-specific набора обязательных live call id;
+- используется `hybrid_store_plus_live` + generic live overlay probe;
+- positive VAT-case может быть закрыт за счет admissible evidence и targeted checks.
+
+### 2.4 Route behavior (as-is)
+
+Факт по latest run:
+
+- VAT case (`L1`) отрабатывает в `factual_with_explanation`;
+- claim: `prove_vat_chain_completeness`;
+- mode: `grounded_positive`;
+- scope: `company_specific_accounting`;
+- temporal outcome: `passed`.
+
+### 2.5 Evidence/admissibility behavior (as-is)
+
+Факт по VAT case (`L1`) в latest run:
+
+- `admissible_evidence_count = 12`
+- `grounding_mode = grounded_positive`
+- основные reject-хвосты: `wrong_account_scope`, `weak_source_mapping`
+
+Факт по aggregate reject breakdown (run-level):
+
+- `weak_source_mapping` и `wrong_account_scope` остаются ключевым residual шумом.
+
+### 2.6 Runtime acceptance snapshot (по latest pack)
+
+- family status: `PARTIALLY_WORKING / NON-BLOCKER`
+- по `L1` VAT-кейсу есть `grounded_positive`
+- общий статус run: `WAVE19_2_ACCEPTED`
+- важная оговорка: в run зафиксирован `normalizer_mode = useMock=true`
+
+### 2.7 known_runtime_limits (as-is)
+
+- `normalizer_mock_mode_in_latest_acceptance`: latest acceptance run выполнялся в режиме `useMock=true`.
+- `no_explicit_vat_live_call_contract`: для VAT пока нет отдельного жесткого live-call контракта как у RBP/FA.
+- `admissibility_noise_remains`: сохраняются residual rejects по `weak_source_mapping` и `wrong_account_scope`.
+
+## 3) Target V2 (planned, не критерий текущей приемки)
+
+### 3.1 Planned claim extension
+
+- `prove_vat_register_book_consistency`
+- `prove_document_to_tax_reflection_closure`
+- `prove_missing_vat_link_risk`
+
+### 3.2 Planned anchor extension
+
+- `invoice_anchor`
+- `register_entry_anchor`
+- `book_entry_anchor`
+- `vat_amount_anchor`
+- `goods_or_item_linkage_anchor`
+
+### 3.3 Planned family metrics
+
+- `vat_grounded_positive_rate`
+- `vat_admissibility_noise_rate`
+- `vat_book_register_linkage_rate`
+- `vat_false_grounded_answer_rate`
+- `vat_live_targeting_precision_rate`
+
+## 4) Required entities and relations (business contract)
+
+### 4.1 Минимально необходимые сущности для proof closure
+
+1. Документ поступления/реализации.
+2. Счет-фактура.
+3. Проводка/движение.
+4. Запись в НДС-регистре.
+5. Запись в книге покупок/продаж.
+6. Связь по товарной позиции/номенклатуре/документной цепочке.
+7. Контрагент/договорный контур при необходимости.
+
+### 4.2 Критические relation links
+
+1. `receipt_or_sale_document -> posting`
+2. `document -> invoice`
+3. `invoice -> vat_register_entry`
+4. `vat_register_entry -> purchase_or_sales_book_entry`
+5. `goods_or_item_context -> chain_completeness_verdict`
+
+## 5) Snapshot/Live coverage verdict (as-is)
+
+- practical mode для VAT family: `snapshot_plus_live_required`
+- positive path уже подтвержден на части кейсов
+- family не является текущим главным blocker
+- next focus: `live narrowing + reject cleanup`, без domain expansion
+
+## 6) Answer/proof modes contract
+
+### `grounded_positive`
+
+Допускается, если одновременно:
+
+- `admissible_evidence_count > 0`
+- подтверждены звенья `document -> invoice -> register -> book`
+- вывод не основан только на общем domain narrative
+- `false_grounded_answer_rate = 0`
+
+Короткий пример:
+
+- `По July 2020 цепочка документ -> проводка -> НДС-регистр -> книга подтверждена; явного выпадения по этой связке не найдено.`
+
+### `limited_or_insufficient_evidence`
+
+Обязателен, если:
+
+- отсутствует одно из ключевых звеньев цепочки;
+- evidence есть, но mapping слабый;
+- `register/book` linkage не закрыт.
+
+Короткий пример:
+
+- `Документный и проводочный контур частично подтверждены, но связь до НДС-регистра или книги не восстановлена; вывод ограничен.`
+
+### Запрещенные паттерны
+
+- `НДС отражен корректно` без документно-регистровой связки;
+- уверенный verdict при `admissible = 0`;
+- подмена chain-proof общим domain narrative.
+
+Короткий антипример:
+
+- `НДС-цепочка в порядке` (нельзя без подтверждения register/book closure).
+
+## 7) Gap register (VAT family)
+
+| gap_id | category | severity | current_state | note |
+| --- | --- | --- | --- | --- |
+| VAT-G1 | `admissibility_residual_noise` | medium | open | остаточный шум по `weak_source_mapping` / `wrong_account_scope` |
+| VAT-G2 | `live_targeting_breadth` | medium | open | live targeting для VAT еще можно сузить до более proof-specific слоя |
+| VAT-G3 | `materialization_cleanup` | medium | open | positive path есть, но часть proof-path требует дочистки |
+| VAT-G4 | `false_grounded_risk_control` | low | controlled | family должна удерживать `false_grounded = 0` |
+
+## 8) Code-path inventory (где живет контракт)
+
+- `llm_normalizer/backend/src/services/assistantClaimBoundEvidence.ts`
+- VAT claim type;
+- required anchors;
+- required checks для VAT chain.
+
+- `llm_normalizer/backend/src/services/assistantDataLayer.ts`
+- route/live plan behavior (в т.ч. generic live overlay для non-FA/RBP);
+- VAT semantic profile and relation patterns.
+
+- `llm_normalizer/backend/src/services/assistantService.ts`
+- routing and eligibility handoff;
+- answer-mode and debug export integration.
+
+- run artifacts:
+- `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-29_Stage_04_Wave_19_2_Live_Runtime_Fix_Replay_1txt`
+
+## 9) Regression set and acceptance policy
+
+Обязательный минимум для VAT family:
+
+1. базовый вопрос по поступлению 13 июля и реализации 15 июля;
+2. вариация на выпадение между документом, проводкой и налоговым отражением;
+3. вариация на книгу покупок/продаж;
+4. follow-up по той же цепочке;
+5. соседний VAT sanity-check.
+
+Политика:
+
+- после каждого VAT family pack обязателен новый run folder;
+- acceptance фиксируется на уровне family;
+- `false_grounded` должен оставаться нулевым.
+
+## 10) Project decision line for this family
+
+VAT family уже переведена в family-based execution контур Stage 4 и рассматривается как `non-blocker`, где нужен cleanup-дожим, а не отдельный большой redesign-пакет.

IN/ВОПРОСЫ_2020_07_extracted.txt

@@ -0,0 +1,34 @@
+20 вопросов по вашей компании и июльскому снапшоту
+1. Расчёты / банк / 60–62
+Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?Проверяет payment →settlement closure по поставщику.
+Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?Это прямой company-specific тест на зачёт аванса покупателя.
+По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реализации или в конце июля там остался аванс/переплата?Хороший тест на 62.01/62.02 и partial settlement.
+Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё равно могут не сойтись?Это вопрос не про сумму, а про механизм.
+Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в договоре, в объекте расчётов или в хронологии документов?Проверяет problem-first объяснение, а не dump.
+Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно было закрыться?Тест на document_conflict.
+Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот объект расчётов или вообще нет подтверждённого closure?Это уже “человеческий” symptom-first вопрос.
+Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет?Полезный тест на ranking и truthful limitations.
+2. НДС / книга покупок / книга продаж
+13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас полная или где-то есть выпадение между документом, проводкой и налоговым отражением?Это хороший cross-branch вопрос по реальной цепочке июля.
+По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже действительно отразился там, где должен, или он только “догадывается”?Тест на false confidence и mechanism specificity.
+31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?Это уже отличный реальный кейс под P0-домен НДС.
+Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, или цепочка “документ → счёт-фактура → налоговая запись” неполная?Проверяет expected edges.
+Полезно для поиска реальных дыр, а не только для заранее известных кейсов.
+Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-фактуре, на проводке по 19, или на записи книги покупок?Тест именно на explainability.
+Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными?Это хороший semi-open case на company snapshot.
+Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не подтверждены?Тест на broken_chain_segment в домене НДС.
+3. Закрытие месяца / затраты / РБП / амортизация
+31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?Это company-specific вопрос на period close.
+31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?Хороший тест на lifecycle anomaly без выхода в полный Stage 5.
+31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?Даже если ОС не P0, этот кейс полезен как controlled adjacent check.
+После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?Это уже зрелый product test на limitation honesty.
+Какие из этих 20 самые сильные для первого прогона
+Если сжать до “ядра”, я бы первым запускал вот эти 8:
+Оплата 55 200 по договору № 01/19-ПТ — почему долг мог остаться.
+Поступление денег 276 873,60 от 13 июля — корректно ли зачёлся аванс 15 июля.
+Платежи 40 860 и 20 000 по договору № 1-ПМ/2020 — аванс это или закрытие дебиторки.
+31 июля услуги связи + НДС 233,33 + полученный счёт-фактура — полная ли НДС-цепочка.
+Есть ли покупки июля, где товар/услуга есть, а НДС-контур неполный.
+Закрытие косвенных расходов 31 июля — не осталось ли хвостов.
+Списание РБП на 31 июля — не живёт ли часть РБП дольше ожидаемого.
+После полного month-end — что из остатков является реальной проблемой, а что нет.

IN/Этап 4 — corrective pack по family isolation.md

@@ -0,0 +1,314 @@
+# Этап 4 — corrective pack по family isolation, claim routing и чистой приемке
+
+## 1. Контекст
+
+Stage 4 уже работает в `family-based execution`:
+
+- единица анализа: `family`;
+- единица реализации: `family pack`;
+- единица приемки: `family acceptance`.
+
+По трем новым прогонам подтверждено: основная проблема в runtime не текстовая, а маршрутизационная:
+
+- leakage между family/lane;
+- неправильный `claim_type` на корректных вопросах;
+- рассинхрон между route/domain/claim в разных слоях runtime;
+- смешанные acceptance-файлы, где трудно объективно мерить качество lane/family.
+
+## 2. Архитектурная рамка corrective pack
+
+Чтобы пакет был совместим с текущим проектом, фиксируем:
+
+1. `core families` Stage 4:  
+   `VAT chain`, `RBP tail`, `FA amortization`.
+2. `control lanes` (regression/sanity, не first-class family):  
+   `settlements_60_62`, `month_close_indirect_costs`.
+3. Пакет не добавляет новые домены и не меняет Stage 4 модель.
+4. Пакет не строит новый proof engine и не уводит в Stage 5.
+
+## 3. Цель corrective pack
+
+Привести execution к состоянию, где:
+
+1. вопрос из одного family/lane не уходит в чужой `claim/domain path`;
+2. routing в live и follow-up не расходится между runtime-слоями;
+3. acceptance выполняется по чистым family/lane файлам;
+4. `false_grounded_answer_rate = 0`;
+5. `wrong_family_route_rate = 0` на контрольном наборе этого pack.
+
+## 4. Подволны
+
+### Подволна 1 — Family isolation matrix
+
+#### Задача
+
+Снять матрицу соответствия вопроса и целевого family/lane, и явно показать точки leakage.
+
+#### Что сделать
+
+Построить матрицу по контрольным вопросам из трех файлов:
+
+- `расчеты банк 60 62.txt`
+- `ндс книга покупок и продаж.txt`
+- `рбп затраты аморт.txt`
+
+Для каждого вопроса зафиксировать:
+
+- `raw_question`
+- `expected_lane_type` (`core_family` | `control_lane`)
+- `expected_family_or_lane`
+- `expected_domain`
+- `expected_claim_type`
+- `actual_domain`
+- `actual_claim_type`
+- `actual_query_subject`
+- `actual_source_profile`
+- `actual_business_scope`
+- `mismatch_type`
+
+Минимальные lane:
+
+1. `settlements_60_62` (control lane)
+2. `VAT chain` (core family)
+3. `RBP tail` (core family)
+4. `FA amortization` (core family)
+5. `month_close_indirect_costs` (control/sanity lane)
+
+#### Acceptance
+
+Есть явная матрица:
+
+- что относится к core family, а что к control lane;
+- где и почему происходит leakage.
+
+### Подволна 2 — Claim routing + domain purity alignment
+
+#### Задача
+
+Устранить переходы:
+
+- settlement -> VAT claim;
+- settlement -> FA claim;
+- VAT -> settlement guard path;
+- month-close -> случайный FA/RBP claim без основания.
+
+#### Что сделать
+
+##### A. Синхронизировать domain inference между слоями
+
+Унифицировать доменную классификацию для:
+
+- `assistantService` domain hint;
+- `investigationState` explicit domain hint;
+- follow-up cross-scope checks.
+
+Цель: один и тот же вопрос не должен получать разные домены в разных слоях runtime.
+
+##### B. Ужесточить claim inference для settlement/VAT/FA
+
+1. Settlement/advance/closure не должны резолвиться в:
+
+- `prove_vat_chain_completeness`;
+- `prove_fixed_asset_amortization_coverage`.
+
+2. Убрать ложный FA-триггер на числовых артефактах:
+
+- числа из дат/сумм не должны поднимать FA claim;
+- `62.02` не должен теряться как `amount_token` в settlement flow.
+
+3. FA claim допускается только при явном FA-сигнале:
+
+- лексический FA-сигнал;
+- или валидные account/object anchors после account extraction cleanup.
+
+##### C. Привязать `query_subject` к resolved family/lane
+
+`query_subject` должен строиться от resolved route/domain/claim, а не от сырого mixed-domain списка.
+
+Практический эффект:
+
+- VAT не должен уходить в `supplier_tail_analysis`;
+- settlement не должен маскироваться под VAT/FA path.
+
+##### D. Сохранить рабочий RBP path
+
+Не ломать поднятый RBP контракт:
+
+- `claim_type = prove_rbp_tail_state`;
+- обязательный live recipe;
+- non-zero admissible evidence path.
+
+##### E. Для FA использовать route-lock/parity контроль
+
+FA в этом паке контролируется через:
+
+- `claim-route lock`;
+- `mock/live parity` по целевым FA вопросам;
+
+а не через прямую метрику domain-card purity 1:1.
+
+#### Acceptance
+
+На контрольном наборе pack:
+
+- `wrong_family_route_rate = 0`;
+- `wrong_claim_type_rate = 0`;
+- `domain_purity_guard_lane_match_rate = 1.0` для lanes с domain-card (`settlements`, `VAT`, `month_close`);
+- `fa_route_lock_correctness_rate >= 0.95`;
+- `supplier_customer_polarity` не остается unresolved на core settlement cases.
+
+### Подволна 3 — Чистая структура acceptance-прогонов
+
+#### Задача
+
+Убрать смешанные acceptance-файлы.
+
+#### Что сделать
+
+Собрать отдельные прогоны:
+
+1. `chat_export_settlements.txt` (control lane)
+2. `chat_export_vat.txt` (core family)
+3. `chat_export_rbp.txt` (core family)
+4. `chat_export_fa.txt` (core family)
+5. `chat_export_month_close_sanity.txt` (control lane)
+
+Правило:
+
+- один файл = один family/lane;
+- mixed files не используются как family acceptance.
+
+#### Acceptance
+
+Все acceptance-артефакты lane-clean и сопоставимы между волнами.
+
+### Подволна 4 — Final live rerun по изолированным lanes
+
+#### Задача
+
+Пересобрать финальный live rerun после исправления isolation/routing.
+
+#### Обязательный набор кейсов
+
+`settlements_60_62` (control lane):
+
+1. supplier settlement (`55 200`)
+2. buyer advance (`62.02`)
+3. closure case без суммы
+4. follow-up по тому же договору/документу
+
+`VAT chain`:
+
+1. услуги связи (`1 166,67 + НДС 233,33`)
+2. счет-фактура / книга покупок
+3. выпадение между документом и книгой
+4. follow-up по той же VAT-цепочке
+
+`RBP tail`:
+
+1. `Списание РБП за Июль 2020` (`5 000`)
+2. вариант без суммы
+3. полнота закрытия
+4. follow-up по объекту/документу
+
+`FA amortization`:
+
+1. `2 471,52 / 2 465,28 / 849,83`
+2. expected vs actual set
+3. missing object risk
+4. follow-up по объекту ОС
+
+`month_close_indirect_costs` (control lane):
+
+1. базовый вопрос по косвенным расходам
+2. зависший хвост
+3. limitation-honesty после полного month-end
+
+#### Acceptance
+
+Новый live rerun показывает:
+
+- route/claim isolation без cross-family leakage;
+- корректную lane-классификацию;
+- честный limited mode только по фактической нехватке данных.
+
+## 5. Метрики corrective pack
+
+### Добавить/вывести
+
+- `wrong_family_route_rate`
+- `wrong_claim_type_rate`
+- `domain_purity_guard_lane_match_rate`
+- `fa_route_lock_correctness_rate`
+- `family_isolation_correctness_rate`
+- `live_recipe_binding_rate`
+- `false_grounded_answer_rate`
+- `mechanism_discrimination_rate`
+- `limited_answer_honesty_rate`
+
+### Минимальные пороги (для контрольного набора этого pack)
+
+- `wrong_family_route_rate = 0`
+- `wrong_claim_type_rate = 0`
+- `domain_purity_guard_lane_match_rate = 1.0` (для lanes с domain-card)
+- `fa_route_lock_correctness_rate >= 0.95`
+- `false_grounded_answer_rate = 0`
+- `mechanism_discrimination_rate >= 0.90`
+- `limited_answer_honesty_rate >= 0.95`
+
+## 6. Что создать
+
+### В `docs/ARCH`
+
+1. `10 - family_isolation_and_claim_routing_corrective_pack_2026-03-29.md`
+2. `10A - family_isolation_matrix.md`
+3. `10B - wrong_claim_route_register.md`
+4. `10C - clean_family_run_structure.md`
+5. `10D - family_acceptance_policy_update.md`
+6. `10E - cross_layer_domain_inference_parity.md`
+
+### В `llm_normalizer/docs/runs/<new_run_pack>`
+
+1. `run_summary.json`
+2. `before_after_metrics.json`
+3. `family_case_matrix.md`
+4. `acceptance_note.md`
+5. `chat_export_settlements.txt`
+6. `chat_export_vat.txt`
+7. `chat_export_rbp.txt`
+8. `chat_export_fa.txt`
+9. `chat_export_month_close_sanity.txt`
+10. `debug_payloads/`
+11. `routing_parity_diff.md`
+
+## 7. Что нельзя делать
+
+- не добавлять новые домены;
+- не менять Stage 4 family-based model;
+- не строить новый proof engine;
+- не смешивать acceptance разных family/lane в одном файле;
+- не закрывать acceptance по одному удачному ответу;
+- не лечить leakage общим ростом generic retrieval.
+
+## 8. Финальный verdict
+
+Выдать:
+
+- `FAMILY_ISOLATION_FIXED / NOT_FIXED`
+- `CLAIM_ROUTING_FIXED / NOT_FIXED`
+- `CLEAN_FAMILY_ACCEPTANCE_READY / NOT_READY`
+
+Общий статус:
+
+- `STAGE4_FAMILY_ISOLATION_PACK_ACCEPTED`
+- или `STAGE4_FAMILY_ISOLATION_PACK_ACCEPTED_WITH_LIMITATIONS`
+- или `STAGE4_FAMILY_ISOLATION_PACK_NOT_ACCEPTED`
+
+## 9. Ожидаемый итог
+
+После этого пакета:
+
+- settlement-вопросы не уходят в VAT/FA claim;
+- VAT-вопросы не ведутся через settlement-path;
+- mixed-file приемка не используется;
+- прогресс измеряется по чистым family/lane с сопоставимыми метриками и артефактами.

IN/Этап 4 — пакет по амортизации.md

@@ -0,0 +1,292 @@
+Этап 4 — пакет по амортизации.md
+: замыкание доказательной цепочки по объектам ОС
+1. Контекст
+
+После аудита и последующих пакетов:
+
+НДС уже не главный blocker;
+РБП выведен из критического состояния;
+амортизация остаётся следующим главным узлом.
+
+По аудиту по амортизации картина такая:
+
+источник не пустой;
+admissible evidence уже есть;
+live path уже что-то поднимает;
+но claim-proof не замыкается из-за:
+недостаточного mapping связей 1С,
+слабого покрытия claim anchors,
+отсутствия внятного expected set объектов ОС за июль.
+
+То есть проблема по амортизации сейчас не в нуле данных, а в том, что система не умеет собрать из уже поднятых данных доказанный вывод:
+
+все ли нужные объекты ОС попали в начисление;
+если не все — какой именно объект/контур выпал;
+или текущий набор начислений выглядит полным.
+2. Цель пакета
+
+Нужно не “улучшить ответ”, а замкнуть proof-контур по амортизации:
+
+вопрос про амортизацию → объекты ОС → expected set за июль → фактическое начисление → проводки/движения → покрытие / непокрытие → доказательный вывод
+
+Итогом должно стать:
+
+явное понимание, какие объекты ОС должны участвовать в начислении за июль;
+явное понимание, какие из них реально попали в начисление;
+восстановление связей между объектами ОС, документом начисления, движениями и проводками;
+non-zero claim-proof coverage;
+ответ, который может либо:
+доказать полноту начисления,
+либо показать, что есть риск пропуска конкретных объектов,
+либо честно ограничиться, если не хватает ключевой связи.
+3. Source of truth
+Базовый вопрос
+
+31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объектам за июль или есть риск, что какой-то объект ОС в июле не попал в амортизацию?
+
+Текущий диагноз
+
+По аудиту и прогонам:
+
+admissible evidence уже есть;
+live path не нулевой;
+но итоговый proof не закрывается, потому что не хватает:
+корректной карты связей,
+object-level coverage,
+claim anchor closure.
+4. Главная рабочая гипотеза
+
+Для амортизации основной разрыв сейчас в связке:
+
+entity/relation mapping
+система не понимает до конца, как объект ОС связывается с начислением, движением, проводкой и expected coverage;
+expected set reconstruction
+система не умеет уверенно определить, какие объекты ОС вообще должны были попасть в начисление за июль;
+claim anchor closure
+сумма начисления и сам факт начисления видны, но они не собираются в доказательство полноты/неполноты охвата.
+5. Что нужно сделать
+
+Работу выполнить по 5 узлам.
+
+Узел A — Построить минимальную предметную модель амортизации
+Задача
+
+Понять, какие сущности 1С обязательны для доказательного ответа на вопрос про полноту начисления амортизации.
+
+Что сделать
+
+Для кейса амортизации определить:
+
+A1. Seed entities
+документ/операция начисления амортизации на 31 июля;
+три суммы: 2 471,52 / 2 465,28 / 849,83;
+July 2020;
+объекты ОС, если их можно выделить напрямую или через связанные документы/регистры.
+A2. Required entities
+
+Минимально установить:
+
+документ начисления амортизации;
+объект(ы) ОС;
+движения начисления;
+проводки;
+регистры состояния/начисления/учёта ОС;
+expected set объектов ОС на июль;
+фактический set объектов, попавших в начисление;
+признаки “должен был попасть / не попал”.
+A3. Expected transitions
+
+Обязательные переходы:
+
+объект ОС → начисление амортизации;
+начисление → движения/проводки;
+объект ОС → expected July coverage;
+expected set → actual set;
+actual set vs missing set → риск неполного начисления.
+Acceptance
+Должен появиться явный fa_required_entity_map.
+Должно быть понятно, без каких сущностей доказательство полноты невозможно.
+Узел B — Восстановить expected set объектов ОС за июль
+Задача
+
+Ответить на главный скрытый вопрос:
+какие объекты ОС вообще должны были попасть в амортизацию за июль?
+
+Что сделать
+Определить, откуда в 1С можно получить expected population объектов ОС на июль:
+активные объекты ОС;
+объекты, находящиеся в состоянии, допускающем амортизацию;
+объекты, не выбывшие и не исключённые из расчёта;
+объекты, для которых июльское начисление ожидаемо.
+Проверить:
+есть ли этот expected set в snapshot;
+есть ли он через live;
+нужно ли собирать его из нескольких регистров/документов.
+Зафиксировать:
+expected_fa_set
+actual_fa_set_from_amortization
+missing_fa_candidates
+uncertain_fa_candidates
+Acceptance
+Должен появиться reconstructible expected_fa_set, а не просто суммы начисления.
+Должно быть понятно, может ли система вообще доказать “полноту” начисления, а не только наличие документа.
+Узел C — Восстановить relation mapping по объектам ОС
+Задача
+
+Понять, как именно объект ОС связывается с начислением, движениями и проводками.
+
+Что сделать
+
+Для каждого candidate объекта ОС построить relation map:
+
+fa_object
+document_amortization
+movement
+posting
+period
+coverage_status
+
+Нужно зафиксировать:
+
+прямые связи;
+косвенные связи;
+missing links;
+ambiguous links;
+какие связи текущий runtime уже использует;
+какие связи есть в 1С, но не реконструируются рантаймом.
+Acceptance
+Должна появиться object-level relation map по амортизации.
+Должно стать ясно, где именно рвётся связь между ОС и начислением.
+Узел D — Замкнуть claim anchors для амортизации
+Задача
+
+Сделать так, чтобы claim по амортизации опирался не только на суммы, а на полноценный набор anchors.
+
+Что сделать
+
+Для claim типа prove_fixed_asset_amortization_coverage выделять и проверять:
+
+период;
+суммы начисления;
+документ начисления;
+объекты ОС;
+expected object set;
+actual object set;
+missing object candidates;
+проводки/движения, подтверждающие начисление.
+
+В debug/export ввести:
+
+claim_type
+required_anchors
+resolved_anchors
+missing_anchor_classes
+claim_anchor_coverage_ratio
+Acceptance
+Кейc по амортизации не должен падать просто как claim_anchor_coverage_insufficient без расшифровки.
+Должно быть видно, каких именно anchors не хватает.
+Узел E — Собрать proof-style answer по амортизации
+Задача
+
+Сделать так, чтобы финальный ответ зависел от object-level proof, а не от общей гипотезы по lifecycle.
+
+Что сделать
+Если proof-path собран
+
+Ответ должен уметь сказать:
+
+какие объекты ОС подтверждены в начислении;
+какие должны были попасть и не подтверждены;
+выглядит ли начисление полным;
+где именно есть риск пропуска.
+Если proof-path неполный
+
+Ответ должен честно сказать:
+
+каких данных не хватает;
+какого object-level звена не хватает;
+можно ли судить только о частичном покрытии.
+Запрещено
+выдавать общий lifecycle-туман без object-level explanation;
+ограничиваться только тем, что “сигнал слабый”.
+Acceptance
+Answer mode должен быть привязан к object-level proof.
+Амортизация должна перестать быть абстрактным month-close кейсом без объектной структуры.
+6. Проверки
+
+Обязательно выполнить:
+
+replay базового вопроса по амортизации;
+debug/export после фикса;
+live call inventory;
+relation reconstruction trace;
+expected vs actual FA coverage matrix;
+before/after по answer mode.
+
+Желательно:
+
+один соседний follow-up по тому же кейсу;
+один sanity-check по другому ОС-related кейсу, если есть.
+7. Метрики пакета
+
+Добавить/обновить:
+
+fa_expected_set_reconstruction_rate
+fa_relation_mapping_coverage_rate
+fa_claim_anchor_coverage_rate
+fa_actual_vs_expected_comparison_rate
+fa_proof_closure_rate
+fa_false_grounded_answer_rate
+Минимальные пороги
+fa_expected_set_reconstruction_rate >= 0.85
+fa_relation_mapping_coverage_rate >= 0.85
+fa_claim_anchor_coverage_rate >= 0.9
+fa_proof_closure_rate > 0
+fa_false_grounded_answer_rate = 0
+8. Обязательные артефакты
+
+В новой run-папке положить:
+
+README.md
+run_summary.json
+fa_expected_set_report.md
+fa_relation_mapping_report.md
+fa_claim_anchor_report.md
+fa_proof_closure_report.md
+fa_before_after_matrix.md
+chat_export_fa.md
+debug_payloads/
+raw_live_calls/
+fa_required_entity_map.json
+fa_expected_vs_actual_set.json
+fa_relation_map.json
+fa_admissibility_reject_breakdown.json
+9. Что не делать
+не тащить в эту волну РБП как главный фокус;
+не расползаться на весь month-close контур;
+не строить новый общий proof engine;
+не закрывать пакет по summary без replay амортизационного кейса;
+не маскировать отсутствие object-level proof красивым текстом ответа.
+10. Финальный verdict
+
+В конце пакета выдать:
+
+FA_EXPECTED_SET_FIXED / NOT_FIXED
+FA_RELATION_MAPPING_FIXED / NOT_FIXED
+FA_CLAIM_ANCHOR_CLOSURE_FIXED / NOT_FIXED
+FA_PROOF_CLOSURE_FIXED / NOT_FIXED
+
+И общий статус:
+
+FA_PACK_ACCEPTED
+или FA_PACK_ACCEPTED_WITH_LIMITATIONS
+или FA_PACK_NOT_ACCEPTED
+11. Ожидаемый результат
+
+После этого пакета должно стать ясно:
+
+какие объекты ОС должны были участвовать в начислении за июль;
+какие реально участвовали;
+по каким объектам доказательство есть;
+где именно остаётся разрыв;
+может ли система по амортизации выдавать не просто “limited”, а нормальный object-level proof-style вывод.