# 10A - План bounded hardening текущей архитектуры на 2026-04-15

## 1. Назначение документа

Этот документ фиксирует не общий wishlist и не разовый разбор отдельного прогона, а bounded hardening plan для текущей архитектуры ассистента.

Цель:
- усилить существующие блоки;
- не снести рабочий baseline;
- не ввести решения, противоречащие уже внедренным architectural rails.

Документ опирается на текущий runtime, зафиксированный в:
- `docs/ARCH/10 - current_assistant_architecture_2026-04-15.md`
- `graphify-out/GRAPH_REPORT.md`

## 2. Принципы выполнения

Все дальнейшие изменения должны проходить по следующим правилам:

1. Не переписывать runtime foundations.
2. Не растворять exact capability routes обратно в “общую умность”.
3. Не ломать working baseline ради одного edge-case.
4. Укреплять сначала orchestration/state/policy слой, а не маскировать проблемы answer wording-ом.
5. Любой новый hardening должен быть выражен либо как:
   - новый guard;
   - новая policy;
   - новый state invariant;
   - новый regression test.

## 3. Что уже считается baseline и не должно деградировать

На текущем этапе надо считать защищаемым baseline следующее:
- living router между `address_data`, `assistant_data_scope` и `chat`;
- `AddressQueryService` как отдельный exact execution lane;
- `addressNavigationState` с `result_set`, `focus_object`, `organization_scope`, `date_scope`;
- `dialogContinuationContractV2`;
- `capability route guard` и `route expectation audit`;
- inventory selected-object follow-up как отдельный сценарный класс;
- organization clarification path;
- limited mode вместо ложного “подтвержденного” ответа при незакрытом proof path.

Любой фикс, который делает систему “умнее”, но при этом размывает эти элементы, считается архитектурно спорным.

## 4. Главные линии bounded hardening

### 4.1 Явное различение root frame и object frame

Что уже есть:
- `organization_scope`;
- `date_scope`;
- `active_focus_object`;
- `current_frame_kind`;
- `root_context_only`.

Что надо усилить:
- перестать трактовать carryover как один общий пакет фильтров;
- закрепить root-level и object-level continuation как разные режимы;
- не позволять object-intent автоматически переживать любой domain pivot.

Практический смысл:
- `root context` должен переживать больше типов follow-up;
- `object context` должен переноситься только в совместимых сценариях.

### 4.2 Жесткий policy-слой для domain pivot

Текущая архитектура уже содержит:
- `domain_scope`;
- `forbidden_cross_domain_leakage`;
- `assistant_data_scope_query_detected`;
- `non_domain_query_indexed`.

Надо закрепить общий policy:
- если новый вопрос совместим с текущим drilldown domain — можно использовать object carryover;
- если новый вопрос уходит в соседний, но поддержанный домен — переносим только root context;
- если новый вопрос не собрался, нельзя автоматически продолжать предыдущий object route.

Это должен быть orchestration-level guard, а не частный патч в inventory или VAT.

### 4.3 Meta-follow-up как отдельный класс вопросов

В текущем контуре мета-вопросы типа:
- `это много или мало?`
- `это критично?`
- `это нормально?`
- `что из этого важнее?`

не должны притворяться повторным exact business query.

Надо закрепить отдельную политику:
- meta-follow-up не должен слепо replay-ить предыдущий ответ;
- он должен опираться на предыдущий answer object/result, а не запускать старый route без надобности;
- meta-layer должен быть отделен от exact data route.

### 4.4 Admissibility и truthfulness guard для entity/field extraction

Текущий runtime уже умеет:
- отбрасывать часть низкокачественных anchor-ов;
- использовать clarification;
- сохранять limited mode.

Следующий bounded шаг:
- ввести общий admissibility слой для extracted entity values;
- не позволять деградации полного anchor-а до обрубка;
- не позволять generic semantic hint перетирать уже подтвержденный selected object;
- не позволять неподтвержденному полю мимикрировать под бизнес-роль.

Это особенно важно для:
- item/counterparty/contract anchors;
- selected-object lifecycle follow-up;
- purchase/sale provenance chains.

### 4.5 Stabilization слоя selected-object continuity

Selected-object continuity уже является частью реальной архитектуры, а не UX-дополнением.

Нужно закрепить инварианты:
- выбранный объект не должен теряться из-за слабого rewrite;
- короткий follow-up не должен автоматически сбрасывать focus;
- новый явно выбранный объект должен приоритетно заменять старый;
- `focus_object` и `previous_anchor` не должны конфликтовать.

Это должно проверяться не на одном кейсе, а на классе сценариев:
- canonical wording;
- colloquial wording;
- UI selected-object wording;
- короткий follow-up;
- follow-up после limited answer.

### 4.6 Оркестрационный разрыв между supported route и unsupported carryover

Одна из основных зон риска — когда:
- route поддержан;
- но carryover прилетает в неправильной форме;
- и система либо уходит в wrong-route, либо в generic partial.

Надо усиливать границу:
- carryover policy и route policy должны быть согласованы;
- если carryover сомнителен, exact route не должен получать мусорный anchor;
- если route валиден, generic conversational fallback не должен подменять его без явной причины.

## 5. Что нельзя делать в рамках этого плана

Чтобы не войти в архитектурный конфликт с текущей системой, в bounded hardening нельзя:

1. Вводить новый “универсальный супер-классификатор”, который обходил бы `AssistantService` и `AddressQueryService`.
2. Дублировать domain purity правила в локальных regex-патчах конкретных capability.
3. Переносить session/navigation state обратно в transcript-only memory.
4. Сливать `root context` и `focus object` обратно в один плоский набор фильтров.
5. Чинить системные проблемы через answer wording без policy/runtime изменения.
6. Маскировать `empty_match`, `missing_anchor`, `recipe_visibility_gap`, `execution_error` под “подтвержденный ответ”.

## 6. Приоритетный порядок внедрения

### P0. Сохранение архитектурной формы

Сначала должны усиливаться те места, которые защищают уже сложившуюся форму runtime:
- root vs object carryover policy;
- selected-object continuity;
- domain pivot guard;
- admissible entity carryover.

### P1. Meta и reasoning поверх результата

После этого:
- meta-follow-up policy;
- reuse answer object/result object;
- bounded comparative/explanatory follow-up.

### P2. Глубина доказательного маршрута

После стабилизации orchestration/state слоя:
- расширение object-level proof paths;
- новые exact capability routes;
- deeper provenance/sale/purchase chains;
- richer document relation recovery.

## 7. Обязательные acceptance-invariants

Любое изменение по этому плану должно проверяться по invariants, а не только по “кажется, ответ стал лучше”.

Минимальный набор:

1. `direct_answer_first`
2. `selected_object_memory_survives_short_followup`
3. `new_explicit_selected_object_overrides_old_focus`
4. `root_context_survives_domain_pivot_without_object_leak`
5. `unsupported_new_domain_does_not_replay_previous_exact_answer`
6. `full_anchor_not_degraded_by_canonical_rewrite`
7. `limited_mode_remains_truthful`
8. `exact_supported_route_not_shadowed_by_generic_chat_fallback`

## 8. Требуемые классы автотестов

### 8.1 Orchestration/state tests

Нужны отдельные регрессии на:
- `carry_root_context`;
- `root_context_only`;
- `dialogContinuationContractV2`;
- explicit object switch;
- follow-up after limited result.

### 8.2 Address runtime tests

Нужны тесты на:
- full item anchor preservation;
- selected-object sale/purchase routes;
- organization clarification continuity;
- empty-match honesty;
- route expectation consistency.

### 8.3 Router boundary tests

Нужны тесты на переходы:
- `address_data -> assistant_data_scope`;
- `address_data -> chat`;
- `inventory drilldown -> tax/meta pivot`;
- `meta-followup -> no route replay`.

## 9. Документальный результат, который должен остаться после внедрения

Каждый крупный bounded hardening должен оставлять после себя:
- короткий architecture note в `docs/ARCH` или `docs/ADDRESS`;
- regression tests;
- при необходимости — audit addendum;
- обновленный graphify snapshot.

То есть hardening должен завершаться не только кодом, но и явной фиксацией архитектурного состояния.

## 10. Итоговая формула

Правильный способ решать следующие проблемы в проекте:

`не rewrite системы`

а

`bounded hardening существующих блоков`

через:
- orchestration policy;
- structured state;
- domain compatibility;
- admissible carryover;
- exact capability discipline.

Именно эта рамка считается безопасной для текущей архитектуры проекта.