АРЧ - Усилить root-frame возврат, memory recap и colloquial provenance follow-up
This commit is contained in:
@@ -0,0 +1,206 @@
|
||||
# Follow-up Context + Root Pivot Audit (2026-04-15)
|
||||
|
||||
Дата: 2026-04-15
|
||||
Статус: `active audit note`
|
||||
Источник прогона: `C:\Users\DCTOUCH\Desktop\test.txt`
|
||||
|
||||
## 1. Зачем этот документ
|
||||
|
||||
Этот note фиксирует, что именно подтвердил живой прогон с appended audit, что в исходном разборе нужно скорректировать, и как это соотносится с уже внедренным bounded fix:
|
||||
|
||||
- `root_context_only` carryover при pivot из inventory drilldown в налоговый/смежный учетный домен;
|
||||
- сохранение baseline inventory selected-object маршрутов;
|
||||
- отсутствие архитектурного конфликта с текущими rails.
|
||||
|
||||
Цель документа не переписать общий план, а зафиксировать фактический срез по одному реальному диалогу, чтобы следующие правки не лечили неверную причину.
|
||||
|
||||
## 2. Что подтверждено прогоном
|
||||
|
||||
### 2.1. VAT root-query работает как capability
|
||||
|
||||
Стартовый запрос про прогноз НДС на март 2020 отработал корректно:
|
||||
|
||||
- `detected_intent = vat_payable_forecast`
|
||||
- `selected_recipe = address_vat_payable_forecast_v1`
|
||||
- ответ построен в address lane, а не через chat/deep fallback
|
||||
|
||||
Это важно, потому что базовый VAT route в этом прогоне не деградировал.
|
||||
|
||||
### 2.2. Meta follow-up по VAT сломан по answer policy
|
||||
|
||||
Запрос `это много или мало?` не получил новый evaluative answer shape. Вместо этого ассистент повторил почти весь предыдущий factual VAT answer.
|
||||
|
||||
Подтвержденные симптомы:
|
||||
|
||||
- `followup_context_applied = true`
|
||||
- `previous_intent = vat_payable_forecast`
|
||||
- `target_intent = unknown`
|
||||
- route при этом остался в address lane
|
||||
|
||||
Вывод:
|
||||
|
||||
- поломка не в data retrieval;
|
||||
- поломка в policy для meta follow-up поверх успешного финансового ответа.
|
||||
|
||||
### 2.3. Есть leakage VAT frame в новый inventory root-query
|
||||
|
||||
На запрос `остаток на складе за май 2020` система все равно несет хвост VAT-сценария:
|
||||
|
||||
- `previous_intent = vat_payable_forecast`
|
||||
- `target_intent = inventory_on_hand_as_of_date`
|
||||
- `intent_selection_mode = carry_previous_intent`
|
||||
|
||||
При этом итоговый inventory intent все же распознается правильно, но сам факт такого carryover является архитектурно неправильным. Новый root-query не должен стартовать с хвостом чужого домена.
|
||||
|
||||
### 2.4. Multiple-organization clarification в этом прогоне работает правильно
|
||||
|
||||
После вопроса `какая база подключена ?` система ушла в `assistant_data_scope_query_detected`, показала 3 организации и не выбрала активную организацию самовольно.
|
||||
|
||||
На первом inventory root-query без организации система корректно вернула clarification:
|
||||
|
||||
- `organization_clarification_required`
|
||||
- `multiple_known_organizations_detected`
|
||||
|
||||
После ответа `альтернатива` активная организация была зафиксирована как:
|
||||
|
||||
- `organization_grounded_from_scope_candidates`
|
||||
|
||||
Это важная корректировка исходного разбора: в данном прогоне проблема не в преждевременном выборе организации из наблюдаемых строк.
|
||||
|
||||
### 2.5. Selected-object sale trace маршрутизируется, но может честно вернуться empty
|
||||
|
||||
Запрос по выбранной позиции `кому продали` был правильно классифицирован:
|
||||
|
||||
- `detected_intent = inventory_sale_trace_for_item`
|
||||
- `selected_recipe = address_inventory_sale_trace_for_item_v1`
|
||||
|
||||
Но retrieval вернул:
|
||||
|
||||
- `limited_reason_category = empty_match`
|
||||
- `mcp_call_status = no_raw_rows`
|
||||
|
||||
Это означает:
|
||||
|
||||
- classification и follow-up routing для этого шага в прогоне живы;
|
||||
- ответ не найден в доступном execution contour;
|
||||
- данный шаг сам по себе не доказывает, что orchestration сломан.
|
||||
|
||||
### 2.6. Short follow-up после limited sale step теряет selected-object continuity
|
||||
|
||||
Следующий короткий вопрос `а купили у кого` уже не продолжил selected-object inventory chain. Он ушел в living chat:
|
||||
|
||||
- `tool_gate_decision = skip_address_lane`
|
||||
- `tool_gate_reason = non_domain_query_indexed`
|
||||
- `followup_context_detected = false`
|
||||
|
||||
Это и есть реальный continuity incident в конце цепочки.
|
||||
|
||||
## 3. Что в исходном разборе нужно поправить
|
||||
|
||||
### 3.1. Нельзя утверждать, что этот прогон сломан из-за авто-grounding организации из observed rows
|
||||
|
||||
В `test.txt` не подтверждается `organization_grounded_from_observed_rows`. По этому диалогу организация была:
|
||||
|
||||
1. сначала явно не выбрана;
|
||||
2. затем корректно запрошена через clarification;
|
||||
3. затем выбрана пользователем;
|
||||
4. затем grounded из scope candidates.
|
||||
|
||||
Следовательно, в данном прогоне root cause не в org policy.
|
||||
|
||||
### 3.2. Пустой sale trace не равен провалу intent-routing
|
||||
|
||||
`empty_match` по sale trace нельзя автоматически считать провалом follow-up architecture. В этом кейсе route выбран корректно; проблема либо в данных, либо в доступном документном/проводочном контуре.
|
||||
|
||||
### 3.3. Главный continuity bug здесь не на шаге `кому продали`, а на шаге `а купили у кого`
|
||||
|
||||
Пока selected-object sale trace хотя бы доходит до exact capability, короткий follow-up после ограниченного результата уже не доходит даже до address lane. Именно это место нужно держать как следующий incident.
|
||||
|
||||
## 4. Соотношение с уже внедренным bounded fix
|
||||
|
||||
### 4.1. Что уже закрыто чисто
|
||||
|
||||
В runtime уже внедрен узкий guard:
|
||||
|
||||
- при pivot из inventory drilldown в foreign accounting domain не тащить selected item;
|
||||
- сохранять только root context (`organization`, `warehouse`, `as_of_date`, `period_from`, `period_to`);
|
||||
- маркировать carryover как `root_context_only`.
|
||||
|
||||
Этот fix архитектурно совместим с текущими rails, потому что:
|
||||
|
||||
- не переписывает state model;
|
||||
- не ломает inventory selected-object цепочки внутри inventory domain;
|
||||
- не меняет execution semantics exact routes;
|
||||
- ограничивает только cross-domain contamination.
|
||||
|
||||
### 4.2. Что этот прогон показывает поверх уже закрытого
|
||||
|
||||
Прогон из `test.txt` показывает еще три отдельные задачи, которые не конфликтуют с `root_context_only` fix и должны решаться отдельно:
|
||||
|
||||
1. `meta_followup_answer_policy`
|
||||
VAT/налоговые meta follow-up типа `это много или мало?` должны выдавать evaluative short answer, а не replay предыдущего factual summary.
|
||||
|
||||
2. `root_domain_pivot_resets_previous_intent`
|
||||
Новый inventory root-query после VAT/налогового домена не должен нести `previous_intent = vat_payable_forecast`.
|
||||
|
||||
3. `selected_object_continuity_after_limited_result`
|
||||
Short follow-up после limited selected-object answer не должен выпадать в `non_domain_query_indexed`, если последний успешный/ограниченный шаг был inventory drilldown по выбранной позиции.
|
||||
|
||||
4. `invalid_entity_extraction_guard`
|
||||
Временной кусок `за май` не должен попадать в `warehouse`.
|
||||
|
||||
## 5. Что нельзя делать по итогам этого прогона
|
||||
|
||||
1. Нельзя откатывать или ослаблять `root_context_only` fix.
|
||||
Этот прогон не опровергает его; он показывает другой класс дефектов.
|
||||
|
||||
2. Нельзя лечить root leakage полным отключением follow-up carryover.
|
||||
Это сломает рабочие selected-object цепочки в inventory.
|
||||
|
||||
3. Нельзя интерпретировать любой `empty_match` как classifier failure.
|
||||
Нужно различать:
|
||||
- route selected correctly;
|
||||
- retrieval found no rows;
|
||||
- follow-up context lost before route selection.
|
||||
|
||||
4. Нельзя лечить `warehouse = "за май"` через новые хардкодные словари по конкретным месяцам.
|
||||
Нужен entity admissibility guard для warehouse anchor.
|
||||
|
||||
## 6. Приоритетный backlog после аудита
|
||||
|
||||
### P0
|
||||
|
||||
1. Запретить replay полного factual ответа на evaluative/meta follow-up поверх VAT/tax summary.
|
||||
2. Ввести reset previous intent на root-domain pivot из VAT/tax в inventory root query.
|
||||
3. Вернуть address-lane continuity для short purchase follow-up после limited selected-object inventory step.
|
||||
|
||||
### P1
|
||||
|
||||
1. Отбрасывать временные фрагменты как invalid warehouse anchor.
|
||||
2. Развести в acceptance:
|
||||
- `route matched but empty`
|
||||
- `route not matched`
|
||||
- `follow-up continuity lost`
|
||||
|
||||
## 7. Обязательные regression checks
|
||||
|
||||
1. `VAT factual -> это много или мало?`
|
||||
Ожидание: короткая evaluative реплика, без replay исходного factual summary.
|
||||
|
||||
2. `VAT root -> inventory root`
|
||||
Ожидание: новый root query не наследует `previous_intent` из чужого домена.
|
||||
|
||||
3. `inventory selected item -> sale empty_match -> а купили у кого`
|
||||
Ожидание: address lane не теряется, selected object продолжает жить.
|
||||
|
||||
4. `остаток на складе за май 2020`
|
||||
Ожидание: `warehouse` не заполняется значением `за май`.
|
||||
|
||||
## 8. Итог
|
||||
|
||||
По этому прогону архитектурная картина такая:
|
||||
|
||||
- узкий fix `root_context_only` был правильным и не противоречит системе;
|
||||
- текущий диалог подтверждает еще несколько независимых дефектов вокруг meta follow-up, root pivot reset и short follow-up continuity;
|
||||
- org clarification policy в этом кейсе, наоборот, отработала лучше, чем предполагал исходный аудит;
|
||||
- следующий слой исправлений должен быть точечным и не должен ломать действующие inventory selected-object rails.
|
||||
@@ -0,0 +1,78 @@
|
||||
# Project Status Update (2026-04-15)
|
||||
|
||||
Дата: 2026-04-15
|
||||
Статус: `incremental update`
|
||||
Базовые статусные документы:
|
||||
|
||||
- `project_status_rails_graph_2026-04-08.md`
|
||||
- `step5_architecture_ux_quality_plan_v1_2026-04-08.md`
|
||||
|
||||
## 1. Новое подтвержденное улучшение
|
||||
|
||||
В address/orchestration runtime внедрен bounded guard:
|
||||
|
||||
- inventory drilldown -> tax/VAT/adjacent accounting pivot
|
||||
- не тащит selected item в новый домен
|
||||
- сохраняет только root context
|
||||
|
||||
Это снижает риск cross-domain contamination без отката follow-up памяти внутри inventory domain.
|
||||
|
||||
## 2. Что этот апдейт не должен означать
|
||||
|
||||
Этот инкремент не означает, что:
|
||||
|
||||
1. все follow-up проблемы уже решены;
|
||||
2. inventory root-queries полностью изолированы от предыдущих VAT frame;
|
||||
3. любой selected-object chain теперь устойчив при limited answers;
|
||||
4. answer-shape policy для meta follow-up уже приведена в порядок.
|
||||
|
||||
То есть статус должен читаться как:
|
||||
|
||||
- один архитектурный риск закрыт;
|
||||
- несколько соседних policy-рельс остаются открытыми.
|
||||
|
||||
## 3. Свежий live snapshot по `test.txt`
|
||||
|
||||
### Подтверждено
|
||||
|
||||
1. VAT exact route жив.
|
||||
2. Data-scope selection по организациям жив.
|
||||
3. Clarification по множественным организациям в этом сценарии корректный.
|
||||
4. Sale trace по выбранной позиции запускается как exact capability.
|
||||
|
||||
### Открытые инциденты
|
||||
|
||||
1. Meta follow-up после VAT summary повторяет старый factual answer.
|
||||
2. Inventory root-query после VAT все еще может нести чужой `previous_intent`.
|
||||
3. Short purchase follow-up после limited sale step может выпадать в `non_domain_query_indexed`.
|
||||
4. Entity extraction все еще допускает мусорный warehouse anchor из temporal phrase.
|
||||
|
||||
## 4. Риск неправильной интерпретации
|
||||
|
||||
По этому состоянию нельзя говорить:
|
||||
|
||||
- "архитектура диалога развалилась полностью"
|
||||
- "inventory sale trace не работает вообще"
|
||||
- "организация выбирается хаотично из observed rows"
|
||||
|
||||
Более точная формулировка:
|
||||
|
||||
- exact routes частично живы;
|
||||
- bounded carryover hardening движется в правильную сторону;
|
||||
- основной оставшийся риск — несогласованность соседних follow-up policies.
|
||||
|
||||
## 5. Что держим как ближайший operational focus
|
||||
|
||||
1. Meta follow-up answer-shape hardening.
|
||||
2. Root-domain pivot reset для новых inventory root-queries.
|
||||
3. Selected-object continuity after limited result.
|
||||
4. Invalid entity admissibility guard for `warehouse`.
|
||||
|
||||
## 6. Acceptance note
|
||||
|
||||
Следующие исправления должны идти как отдельные bounded changes с targeted regressions.
|
||||
Нельзя закрывать статус формулировкой "follow-up problem solved globally", пока:
|
||||
|
||||
- `это много или мало?` после VAT не дает короткий evaluative answer;
|
||||
- `а купили у кого` после limited inventory step не держит selected-object continuity;
|
||||
- `за май` может попасть в `warehouse`.
|
||||
@@ -0,0 +1,132 @@
|
||||
# Step-5 Increment Update (2026-04-15)
|
||||
|
||||
Дата: 2026-04-15
|
||||
Статус: `active`
|
||||
Связанные документы:
|
||||
|
||||
- `step5_architecture_ux_quality_plan_v1_2026-04-08.md`
|
||||
- `project_status_rails_graph_2026-04-08.md`
|
||||
- `followup_context_root_pivot_audit_2026-04-15.md`
|
||||
|
||||
## 1. Что именно обновлено в runtime
|
||||
|
||||
В текущем инкременте зафиксирован bounded fix для cross-domain carryover:
|
||||
|
||||
1. Если пользователь находится внутри inventory drilldown по выбранной позиции,
|
||||
2. и следующим коротким сообщением делает pivot в чужой учетный домен,
|
||||
3. runtime больше не тянет selected item в новый route,
|
||||
4. а сохраняет только root context.
|
||||
|
||||
Практически это выражается так:
|
||||
|
||||
- `followupSelectionMode = carry_root_context`
|
||||
- `followupContext.root_context_only = true`
|
||||
|
||||
Сохраняются только root-level поля:
|
||||
|
||||
- `organization`
|
||||
- `warehouse`
|
||||
- `as_of_date`
|
||||
- `period_from`
|
||||
- `period_to`
|
||||
|
||||
Не сохраняются:
|
||||
|
||||
- `item`
|
||||
- object-level `previous_intent`
|
||||
- object-level anchor
|
||||
|
||||
## 2. Почему это решение считается чистым
|
||||
|
||||
Это решение не спорит с текущей архитектурой rails, потому что:
|
||||
|
||||
1. не меняет execution semantics existing exact capabilities;
|
||||
2. не отключает inventory selected-object carryover внутри inventory domain;
|
||||
3. не подменяет root frame object frame-ом и наоборот;
|
||||
4. не лечит UX-проблемы через query-level костыли.
|
||||
|
||||
То есть это не "новая архитектура", а аккуратный guard на границе между:
|
||||
|
||||
- follow-up orchestration,
|
||||
- selected-object navigation,
|
||||
- domain pivot policy.
|
||||
|
||||
## 3. Что показал свежий live audit
|
||||
|
||||
Разбор прогона из `C:\Users\DCTOUCH\Desktop\test.txt` подтверждает:
|
||||
|
||||
### Уже нормально
|
||||
|
||||
1. VAT root route сам по себе работает.
|
||||
2. Data-scope вопрос по базе/организации работает.
|
||||
3. Multiple-organization clarification в этом сценарии работает корректно.
|
||||
4. Inventory selected-object sale trace доходит до exact capability.
|
||||
|
||||
### Еще не закрыто
|
||||
|
||||
1. Meta follow-up `это много или мало?` все еще replays предыдущий factual VAT answer.
|
||||
2. Новый inventory root-query после VAT все еще несет `previous_intent = vat_payable_forecast`.
|
||||
3. После limited selected-object sale step короткое `а купили у кого` может выпасть в `non_domain_query_indexed`.
|
||||
4. В extraction все еще возможен мусорный `warehouse = "за май"`.
|
||||
|
||||
## 4. Как интерпретировать эти дефекты
|
||||
|
||||
Важно не смешивать разные классы проблем:
|
||||
|
||||
### A. Route/intent problem
|
||||
|
||||
Когда нужный intent вообще не распознан или address lane не запускается.
|
||||
|
||||
### B. Retrieval/execution problem
|
||||
|
||||
Когда route выбран корректно, но retrieval возвращает `empty_match` / `no_raw_rows`.
|
||||
|
||||
### C. Answer-shape problem
|
||||
|
||||
Когда данные/intent корректны, но форма ответа не соответствует пользовательскому вопросу.
|
||||
|
||||
### D. Follow-up continuity problem
|
||||
|
||||
Когда новый короткий вопрос не унаследовал допустимый контекст из предыдущего шага.
|
||||
|
||||
Свежий прогон содержит все четыре типа, но в разных местах. Это важно для планирования, чтобы не чинить retrieval-пустоту как orchestration-баг и наоборот.
|
||||
|
||||
## 5. Следующий bounded backlog
|
||||
|
||||
### P0
|
||||
|
||||
1. `meta_followup_answer_policy`
|
||||
Для evaluative short follow-up поверх VAT/tax factual summary запретить replay полного ответа.
|
||||
|
||||
2. `root_domain_pivot_resets_previous_intent`
|
||||
Для нового root inventory query после VAT/tax не тянуть `previous_intent` из чужого домена.
|
||||
|
||||
3. `selected_object_continuity_after_limited_result`
|
||||
После limited inventory drilldown answer short follow-up должен оставаться в address lane.
|
||||
|
||||
### P1
|
||||
|
||||
1. `invalid_warehouse_anchor_guard`
|
||||
Темпоральные куски вроде `за май` не должны заполнять `warehouse`.
|
||||
|
||||
2. `acceptance_split_for_empty_match`
|
||||
В acceptance нужно отдельно учитывать:
|
||||
- `route matched but empty`
|
||||
- `route not matched`
|
||||
- `follow-up continuity lost`
|
||||
|
||||
## 6. Обязательные regression chains
|
||||
|
||||
1. `прогноз НДС -> это много или мало?`
|
||||
2. `прогноз НДС -> остаток на складе за май 2020`
|
||||
3. `inventory selected item -> кому продали -> а купили у кого`
|
||||
4. `остаток на складе за май 2020` с проверкой admissibility для `warehouse`
|
||||
|
||||
## 7. Итог
|
||||
|
||||
Состояние на 2026-04-15 выглядит так:
|
||||
|
||||
- bounded root-context-only fix — правильный;
|
||||
- inventory rails не надо откатывать;
|
||||
- текущие open issues лежат рядом с ним, а не внутри него;
|
||||
- дальнейшая работа должна идти через изолированные policy/acceptance fixes, а не через очередной общий rewrite follow-up логики.
|
||||
Reference in New Issue
Block a user