12 KiB

Raw Blame History

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. Принципы выполнения

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

Не переписывать runtime foundations.
Не растворять exact capability routes обратно в “общую умность”.
Не ломать working baseline ради одного edge-case.
Укреплять сначала orchestration/state/policy слой, а не маскировать проблемы answer wording-ом.
Любой новый 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 нельзя:

Вводить новый “универсальный супер-классификатор”, который обходил бы AssistantService и AddressQueryService.
Дублировать domain purity правила в локальных regex-патчах конкретных capability.
Переносить session/navigation state обратно в transcript-only memory.
Сливать root context и focus object обратно в один плоский набор фильтров.
Чинить системные проблемы через answer wording без policy/runtime изменения.
Маскировать 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, а не только по “кажется, ответ стал лучше”.

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

direct_answer_first
selected_object_memory_survives_short_followup
new_explicit_selected_object_overrides_old_focus
root_context_survives_domain_pivot_without_object_leak
unsupported_new_domain_does_not_replay_previous_exact_answer
full_anchor_not_degraded_by_canonical_rewrite
limited_mode_remains_truthful
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.

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

12 KiB Raw Blame History Unescape Escape