# 10 - Текущая архитектура ассистента на 2026-04-15

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

Этот документ фиксирует не историческую эволюцию, а текущий рабочий архитектурный срез ассистента в проекте `NDC_1C`.

Цель документа:
- зафиксировать, какие архитектурные блоки реально участвуют в runtime сейчас;
- отделить текущий работающий контур от ранних проектных отчетов и аудитов;
- дать опорную карту для дальнейшего bounded hardening без разрушения baseline.

Документ не заменяет ранние отчеты в `docs/ARCH`, а накладывается на них как актуальный operational snapshot.

## 2. Как читать `docs/ARCH` после этого обновления

Исторические документы сохраняют свою роль:
- `1-4` — bootstrap, ранний pipeline, MVP и GUI/manual слой;
- `5` — ранний отчет по assistant mode;
- `6` — интегральный статус проекта и Stage 4 на конец марта;
- `7-9` — архитектурные аудиты, gap-регистры, source-to-proof и relation разведка.

Текущий документ нужен для другого:
- не объяснить, как проект развивался;
- а зафиксировать, как именно устроен ассистент сейчас на уровне runtime, state, orchestration и capability routing.

## 3. Executive Summary

На текущем этапе ассистент представляет собой не один monolithic pipeline, а связку из пяти рабочих слоев:

1. `Assistant / living router` — решает, идти ли в address/data lane, в data-scope lane или в обычный chat.
2. `Address orchestration runtime` — собирает predecompose, carryover, continuation contract и orchestration decision.
3. `Address exact execution lane` — выполняет exact-capability routes через `AddressQueryService`.
4. `Session memory + navigation state` — хранит `investigation_state`, `address_navigation_state`, `result_sets`, `focus_object`, `organization/date scope`.
5. `Answer/debug contract layer` — формирует ответ, debug payload, continuation contract и данные для GUI/debug drawer.

Ключевая особенность текущей архитектуры:
- разговорный слой уже не является единственным носителем контекста;
- контекст все больше держится в структурированном session/navigation state;
- exact-capability routes уже существуют как отдельный runtime-контур, а не как побочный продукт общего chat-flow.

## 4. Graphify-срез по кодовой базе

По `graphify-out/GRAPH_REPORT.md` на `2026-04-15`:
- корпус: `473 files`;
- граф: `4865 nodes`, `10622 edges`, `132 communities`;
- среди god nodes находятся:
  - `resolveAddressIntent()`;
  - `composeFactualReply()`;
  - `resolveAssistantOrchestrationDecision()`.

Архитектурно самые важные community:
- `Community 2` — orchestration и `AssistantService`;
- `Community 6` — exact capability/runtime execution, включая `AddressQueryService`;
- `Community 14` — domain cards, domain purity, source gating;
- `Community 17` — navigation state, `focus_object`, `result_sets`, session carryover;
- `Community 20` — address orchestration runtime adapter и follow-up message policy.

Это подтверждает, что текущая система уже раскладывается на отдельные runtime-блоки, а не живет в одном промптовом центре принятия решений.

## 5. Текущая карта runtime

### 5.1 Верхний уровень

Текущий поток запроса выглядит так:

`GUI/API -> AssistantService -> orchestration decision -> address runtime adapter -> AddressQueryService -> compose/debug/session persistence`

На этом уровне уже зафиксированы три разных режима:
- `address_data`;
- `assistant_data_scope`;
- `chat`.

Ключевая точка маршрутизации — `resolveAssistantOrchestrationDecision()` в `llm_normalizer/backend/src/services/assistantService.ts`.

### 5.2 Session memory

Сессионная память не ограничивается простым хранением истории сообщений.

Текущий session store:
- `AssistantSessionStore`;
- `investigation_state`;
- `address_navigation_state`.

Это означает, что архитектурно ассистент уже работает не только на transcript memory, но и на явном структурированном state.

## 6. Orchestration слой

### 6.1 Главный orchestration узел

`AssistantService` является текущим orchestration-ядром ассистента.

Он отвечает за:
- выбор living mode;
- resolution follow-up context;
- построение continuation contracts;
- связывание session memory с runtime execution;
- routing между address lane, data-scope и chat.

На текущем этапе это уже не просто “controller”, а фактический координатор между state, semantics и runtime.

### 6.2 Address orchestration runtime

Для address/data контура вынесен отдельный adapter:
- `assistantAddressOrchestrationRuntimeAdapter.ts`

Он выполняет:
- LLM predecompose или fallback predecompose;
- нормализацию `effectiveMessage`;
- resolution carryover context через `resolveAddressFollowupCarryoverContext()`;
- защиту от неудачных канонизаций через `shouldPreferRawFollowupMessage()`;
- построение `dialogContinuationContract`;
- формирование `addressRuntimeMeta`.

Это важное отличие текущей архитектуры от ранних отчетов:
- predecompose;
- carryover;
- continuation contract;
- orchestration decision

теперь собраны в отдельный runtime-блок, а не размазаны по нескольким ad hoc helper-ам.

## 7. Session state и navigation state

### 7.1 Что реально хранится

`addressNavigationState.ts` фиксирует текущую модель навигационного состояния.

Текущий `session_context` включает:
- `active_result_set_id`;
- `active_focus_object`;
- `last_confirmed_route`;
- `date_scope`:
  - `as_of_date`;
  - `period_from`;
  - `period_to`;
- `organization_scope`.

Отдельно хранятся:
- `result_sets[]`;
- `navigation_history[]`.

### 7.2 Что это значит архитектурно

Текущий диалоговый контекст больше не должен держаться только “в голове модели”.

У системы уже есть структурированные сущности:
- результат ответа как `result_set`;
- выбранный объект как `focus_object`;
- подтвержденный маршрут как `last_confirmed_route`;
- текущий root scope как `organization/date scope`.

Это база для устойчивых drilldown-сценариев.

### 7.3 Как state эволюционирует

`evolveAddressNavigationStateWithAssistantItem()` делает следующее:
- вынимает из assistant reply `detected_intent`, `selected_recipe`, `extracted_filters`;
- строит `result_set_id`;
- при наличии — строит `focus_object`;
- пишет navigation event;
- обновляет active result/focus/route/date/org scope.

Важно:
- `active_focus_object` не затирается автоматически при отсутствии нового focus;
- `organization_scope` и `date_scope` также тянутся как долговременный session context.

## 8. Follow-up и continuation semantics

### 8.1 Carryover контекст

`resolveAddressFollowupCarryoverContext()` сейчас является центральным узлом follow-up логики.

Он собирает carryover из:
- предыдущего address reply;
- navigation state;
- organization clarification state;
- implicit continuation signal;
- selected object / displayed entities;
- inventory root frame.

### 8.2 Root frame и drilldown frame

В текущей реализации уже присутствует различие между:
- `inventory_root`;
- `inventory_drilldown`;
- `generic`.

То есть архитектура уже ушла от полностью плоского carryover.

Фактически в runtime уже живут два уровня:
- root context:
  - организация;
  - дата/период;
  - root intent;
- object/drilldown context:
  - item/counterparty/contract/focus object;
  - drilldown intent.

### 8.3 Root-only carryover

Отдельно введен режим `carry_root_context` / `root_context_only`.

Он используется в тех местах, где нужно:
- сохранить организацию и temporal scope;
- но не тянуть старый object-level intent в новый доменный вопрос.

Архитектурно это важный шаг: система уже умеет не только продолжать предыдущий вопрос, но и ограничивать глубину carryover.

### 8.4 Continuation contract

`buildAddressDialogContinuationContractV2()` сейчас формирует отдельный machine-readable контракт продолжения.

Он хранит:
- `decision`;
- `decision_reasons`;
- `previous_intent`;
- `target_intent`;
- `intent_selection_mode`;
- `anchor_type`;
- `anchor_value`;
- `implicit_continuation_signal`.

Это уже полноценный runtime artifact, а не побочный debug-комментарий.

## 9. Exact capability runtime

### 9.1 Role of `AddressQueryService`

`AddressQueryService` — текущий exact execution engine для address/data маршрутов.

Основной поток внутри `tryHandle()`:
- `runAddressDecomposeStage()`;
- pre-execution grounding;
- organization clarification / scope resolution;
- requested result mode resolution;
- capability route decision;
- recipe selection;
- exact MCP query execution;
- materialization;
- scoped filtering;
- future/temporal guards;
- limited/factual reply building.

### 9.2 Что изменилось относительно ранних отчетов

Текущий address runtime уже не является “одним generic execute_query на удачу”.

Сейчас в нем есть:
- capability route guard;
- route expectation audit;
- organization clarification path;
- intent-specific filter layer;
- lifecycle detachment semantics;
- historical/broadened retry layers;
- exact/limited result policy.

То есть ранняя картина из `ARCH/5` уже устарела: exact-capability execution есть и он занимает отдельный крупный слой runtime.

### 9.3 Capability policy

`addressCapabilityPolicy.ts` фиксирует точные capability routes.

На текущем этапе в policy явно присутствуют, в частности:
- inventory:
  - `inventory_on_hand_as_of_date`;
  - `inventory_purchase_provenance_for_item`;
  - `inventory_purchase_documents_for_item`;
  - `inventory_supplier_stock_overlap_as_of_date`;
  - `inventory_sale_trace_for_item`;
  - `inventory_purchase_to_sale_chain`;
  - `inventory_aging_by_purchase_date`;
- VAT:
  - `vat_payable_confirmed_as_of_date`;
  - `vat_liability_confirmed_for_tax_period`.

Это важно зафиксировать отдельно:
- capability layer уже живет как explicit policy map;
- она не должна снова расползаться в “общую умность”.

## 10. Data/domain слой

### 10.1 Domain purity

`assistantDataLayer.ts` продолжает играть роль доменного ограничителя и source gate.

В нем присутствуют:
- `domain_scope`;
- `forbidden_cross_domain_leakage`;
- source gating;
- graph traversal profiles;
- live MCP call planning;
- domain card based filtering.

### 10.2 Почему это важно для текущей архитектуры

Даже если текущая задача решается в address exact lane, система уже опирается на более широкий доменный слой:
- domain cards;
- source purity;
- graph-aware retrieval planning;
- forbidden cross-domain leakage rules.

Следовательно, любые новые hardening-решения нельзя строить как локальные regex-патчи в inventory/VAT ветках, если они конфликтуют с domain purity моделями.

## 11. Data source модель

Текущий runtime работает как минимум с двумя типами источников:
- live MCP / `execute_query` и каталожные резолверы;
- snapshot/canonical/risk материалы, участвующие в более широком assistant/data контуре.

Для address exact lane центральным остается live execution, но:
- orchestration уже знает про data-scope и domain routes;
- в проекте сохраняется split между lightweight live path и более широкими доказательными/аналитическими слоями.

## 12. Debug, contracts и observability

Текущая архитектура сильно опирается на machine-readable debug artifacts.

На runtime-уровне зафиксированы:
- `technical_debug_payload_json`;
- `addressRuntimeMeta`;
- `orchestrationContract`;
- `dialogContinuationContract`;
- `route_expectation_*`;
- `capability_id`;
- `selected_recipe`;
- `limited_reason_category`.

Для проекта это уже не “вспомогательная телеметрия”, а часть архитектуры:
- через эти контракты GUI, аудит и domain loop понимают, что именно решила система;
- без них bounded hardening быстро превращается в непрозрачную серию случайных патчей.

## 13. Feature-flag слой

В текущем runtime существенная часть поведения завязана на feature flags.

Ключевые flags, влияющие на архитектуру:
- `FEATURE_ASSISTANT_ADDRESS_QUERY_V1`;
- `FEATURE_ASSISTANT_ADDRESS_QUERY_LIVE_V1`;
- `FEATURE_ASSISTANT_CAPABILITY_ROUTE_GUARD_V1`;
- `FEATURE_ASSISTANT_ROUTE_EXPECTATION_AUDIT_V1`;
- `FEATURE_ASSISTANT_ROUTE_EXPECTATION_HARD_GUARD_V1`;
- `FEATURE_ASSISTANT_INVESTIGATION_STATE_V1`;
- `FEATURE_ASSISTANT_ADDRESS_NAVIGATION_STATE_V1`;
- `FEATURE_ASSISTANT_LIVING_CHAT_ROUTER_V1`;
- `FEATURE_ASSISTANT_STATE_FOLLOWUP_BINDING_V1`;
- `FEATURE_ASSISTANT_CONTRACTS_V11`;
- `FEATURE_ASSISTANT_ANSWER_POLICY_V11`.

Архитектурно это значит:
- текущая система уже modularized;
- но operational profile зависит от конфигурации flags, а не только от кода.

## 14. Что устарело в ранних архитектурных документах

### 14.1 Что больше нельзя считать точным описанием текущего состояния

Ранние документы `ARCH/5` и частично `ARCH/6_global_report` полезны как история, но не как точный snapshot текущего runtime.

Устаревшими в них являются, в частности, представления о том, что:
- assistant mode в основном сводится к answer composer + session memory;
- retrieval plan еще в основном stubbed;
- routing и follow-up существуют как легкая надстройка поверх ответа.

На текущем этапе это уже не так:
- continuation contracts существуют;
- navigation state существует;
- exact capability runtime существует;
- route expectation / capability guard / organization clarification существуют;
- root/drilldown carryover уже встроен в orchestrator.

### 14.2 Как использовать старые документы теперь

Старые отчеты полезны:
- как описание этапов развития;
- как baseline для исторического сравнения;
- как объяснение происхождения guardrails и audit criteria.

Но для описания того, “как работает ассистент сейчас”, опорным должен считаться уже этот документ.

## 15. Текущие архитектурные инварианты

На момент `2026-04-15` безопасно считать архитектурными инвариантами следующее:

1. Exact business routes должны жить как explicit capability/runtime paths, а не как heuristic chat imitation.
2. Follow-up continuity должна опираться не только на transcript, но и на structured state.
3. `focus_object`, `result_set`, `organization_scope`, `date_scope` являются частью архитектуры, а не UX-деталью.
4. Root context и drilldown context нельзя больше считать одной плоской переменной “контекст разговора”.
5. Machine-readable debug/contracts обязательны для объяснимости и bounded hardening.
6. Domain purity и forbidden cross-domain leakage уже являются встроенными guardrails и должны учитываться при любом расширении.

## 16. Текущие ограничения

Несмотря на значительный сдвиг архитектуры, текущая система еще не должна описываться как полностью закрытая production architecture.

Остаются ограничения:
- часть follow-up semantics еще зависит от LLM predecompose и quality canonicalization;
- часть object-level continuity еще удерживается комбинацией transcript + navigation state, а не единым frame engine;
- не все capability routes одинаково зрелые по depth и proof closure;
- hardening по meta-follow-up, pivot semantics и field admissibility еще остается отдельным слоем работы.

## 17. Практический итог

Текущий ассистент уже нельзя описывать как “чат над 1С”.

Более точная формулировка:

`структурированный orchestration runtime + session/navigation state + exact address capability engine + domain/data guardrails`

Именно в этой рамке должны приниматься следующие решения:
- не через новый общий rewrite;
- не через промптовую переумность;
- а через bounded усиление уже существующих архитектурных блоков.

## 18. Связанные документы

Исторический baseline:
- `docs/ARCH/5 - assistant_mode_architecture_report_2026-03-24.md`
- `docs/ARCH/6 - project_and_stage4_full_report_2026-03-28.md`
- `docs/ARCH/6_global_report/Assistant_Mode_GLOBAL_STATUS_2026-03-24.md`

Аудит и gap-анализ:
- `docs/ARCH/7 - аудит архитектуры на 4 этапе/7 - assistant_runtime_ground_truth_audit_2026-03-28.md`
- `docs/ARCH/8_audit_artifacts/8 - аудит source_to_proof_по_3_контрольным_вопросам_2026-03-29.md`
- `docs/ARCH/9_audit_artifacts/9 - разведка_структуры_1с_и_связей_через_mcp_по_3_контрольным_вопросам_2026-03-29.md`
- `docs/ARCH/9_audit_artifacts/9F - current_runtime_vs_required_runtime.md`

Следующий operational документ:
- `docs/ARCH/10A - current_assistant_hardening_plan_2026-04-15.md`