Стабилизировать маржинальность номенклатуры
This commit is contained in:
@@ -44,6 +44,27 @@ Fresh validation cut:
|
||||
- `npm.cmd run build` passed;
|
||||
- graphify rebuilt to `6371` nodes, `14048` edges, `141` communities.
|
||||
|
||||
## 2026-05-18 Overlay - Context Entry And Latest Semantic Integrity Closure
|
||||
|
||||
The current short handoff document is now `41 - assistant_context_entry_2026-05-18.md`.
|
||||
|
||||
The latest saved-session semantic replay closure is:
|
||||
|
||||
- source saved session: `gen-mo1t93wq-jy0453e`;
|
||||
- final replay artifact: `artifacts/domain_runs/saved_session_gen_mo1t93wq_jy0453e_rerun_final_semantic_20260518`;
|
||||
- result: `accepted`, `31/31 passed`, `0 failed`, `execution_status=exact`;
|
||||
- commit: `9c86407 Зафиксировать семантическую целостность VAT, debt mirror и trace-ответов`;
|
||||
- graphify after the code cut: `6490 nodes`, `14412 edges`, `141 communities`.
|
||||
|
||||
This May-18 closure does not reopen Post-F. It reinforces Post-F as a regression gate and records four extra live-session seams:
|
||||
|
||||
- same-period VAT follow-up now preserves the prior requested tax period instead of drifting to current date;
|
||||
- stale MCP discovery counterparty no longer contaminates short debt mirror follow-ups such as `а нам?`;
|
||||
- inventory sale trace answers now distinguish sale trace by nomenclature from exact selected lot/batch proof;
|
||||
- broad best-year answers no longer rank unreliable yearly operating net when one direction is row-limit constrained.
|
||||
|
||||
Use this overlay when starting a new chat or preparing a Tasker handoff card.
|
||||
|
||||
## Current Module Map
|
||||
|
||||
- `Post-F Semantic Integrity Hardening`: `99%`, operationally closed as a hardening slice and now used as a regression gate.
|
||||
@@ -96,6 +117,7 @@ Fresh validation cut:
|
||||
- Completed broader schema/primitive discovery closure slice: `Mixed Schema/Primitive Closure Replay`: phase105 validates the combined current module surface across inventory root scope, historical inventory carryover, role-tail hygiene, bank role/purpose, supplier payout, bidirectional SVK value-flow, clean debt polarity, VAT tax-period continuity, and cash-flow/profit boundary; phase105 live replay is accepted.
|
||||
- Current live canary: `phase105_mixed_schema_primitive_closure_live3` accepted `13/13`.
|
||||
- Current accepted autorun: `AGENT | Phase 105 mixed schema/primitive closure replay` (`gen-ag05131312-2d0445`).
|
||||
- Current saved-session semantic replay closure: `saved_session_gen_mo1t93wq_jy0453e_rerun_final_semantic_20260518` accepted `31/31`.
|
||||
- Implementation breadth: `~99% (Open-World Bounded Autonomy Breadth through Slice 25)`.
|
||||
- Active broader autonomy module: `Open-World Schema/Primitive Discovery`, with phases97-105 accepted and saved; the module is now at manual-review readiness rather than another blind coding slice.
|
||||
- Next active slice: run/review the phase105 GUI autorun or the user's fat manual pack; if it stays clean, close this module, otherwise convert the next observed failure into a narrow phase106 repair/replay.
|
||||
@@ -167,28 +189,29 @@ After any code or documentation sync that changes the map, rebuild graphify and
|
||||
For current planning, read:
|
||||
|
||||
1. `README.md`
|
||||
2. this document
|
||||
3. `31 - inventory_reserve_liquidation_quality_reviewed_route_2026-05-12.md`
|
||||
4. `33 - limit_honesty_business_language_2026-05-13.md`
|
||||
5. `32 - financial_counterparty_flow_hints_2026-05-13.md`
|
||||
6. `30 - vendor_procurement_quality_reviewed_route_2026-05-12.md`
|
||||
7. `29 - debt_due_date_aging_reviewed_route_2026-05-10.md`
|
||||
8. `28 - accounting_profit_margin_reviewed_route_2026-05-10.md`
|
||||
9. `27 - proof_family_enablement_candidates_2026-05-10.md`
|
||||
10. `26 - route_candidate_driven_enablement_loop_2026-05-10.md`
|
||||
11. `25 - open_world_route_candidate_promotion_2026-05-10.md`
|
||||
12. `34 - large_query_budget_continuation_2026-05-13.md`
|
||||
13. `35 - large_query_continuation_ux_2026-05-13.md`
|
||||
14. `36 - inventory_root_scope_no_warehouse_clarification_2026-05-13.md`
|
||||
15. `37 - debt_mirror_clean_scope_polarity_2026-05-13.md`
|
||||
16. `24 - agentic_semantic_development_loop_and_autorun_hygiene_2026-05-10.md`
|
||||
17. `23 - current_execution_spine_and_semantic_control_gate_2026-05-05.md`
|
||||
18. `22 - open_world_bounded_autonomy_breadth_2026-05-01.md`
|
||||
19. `20 - planner_autonomy_consolidation_2026-05-01.md`
|
||||
20. `19 - inventory_stock_open_world_breadth_proof_2026-05-01.md`
|
||||
21. `40 - mixed_schema_primitive_closure_replay_2026-05-13.md`
|
||||
22. `39 - generic_role_tail_anchor_hygiene_2026-05-13.md`
|
||||
23. `17 - post_f_semantic_integrity_hardening_2026-04-23.md`
|
||||
24. `16 - data_need_graph_and_open_world_mcp_plan_2026-04-22.md`
|
||||
2. `41 - assistant_context_entry_2026-05-18.md`
|
||||
3. this document
|
||||
4. `31 - inventory_reserve_liquidation_quality_reviewed_route_2026-05-12.md`
|
||||
5. `33 - limit_honesty_business_language_2026-05-13.md`
|
||||
6. `32 - financial_counterparty_flow_hints_2026-05-13.md`
|
||||
7. `30 - vendor_procurement_quality_reviewed_route_2026-05-12.md`
|
||||
8. `29 - debt_due_date_aging_reviewed_route_2026-05-10.md`
|
||||
9. `28 - accounting_profit_margin_reviewed_route_2026-05-10.md`
|
||||
10. `27 - proof_family_enablement_candidates_2026-05-10.md`
|
||||
11. `26 - route_candidate_driven_enablement_loop_2026-05-10.md`
|
||||
12. `25 - open_world_route_candidate_promotion_2026-05-10.md`
|
||||
13. `34 - large_query_budget_continuation_2026-05-13.md`
|
||||
14. `35 - large_query_continuation_ux_2026-05-13.md`
|
||||
15. `36 - inventory_root_scope_no_warehouse_clarification_2026-05-13.md`
|
||||
16. `37 - debt_mirror_clean_scope_polarity_2026-05-13.md`
|
||||
17. `24 - agentic_semantic_development_loop_and_autorun_hygiene_2026-05-10.md`
|
||||
18. `23 - current_execution_spine_and_semantic_control_gate_2026-05-05.md`
|
||||
19. `22 - open_world_bounded_autonomy_breadth_2026-05-01.md`
|
||||
20. `20 - planner_autonomy_consolidation_2026-05-01.md`
|
||||
21. `19 - inventory_stock_open_world_breadth_proof_2026-05-01.md`
|
||||
22. `40 - mixed_schema_primitive_closure_replay_2026-05-13.md`
|
||||
23. `39 - generic_role_tail_anchor_hygiene_2026-05-13.md`
|
||||
24. `17 - post_f_semantic_integrity_hardening_2026-04-23.md`
|
||||
25. `16 - data_need_graph_and_open_world_mcp_plan_2026-04-22.md`
|
||||
|
||||
Documents `01` through `15` remain valuable, but mostly as the historical architecture trail.
|
||||
|
||||
@@ -0,0 +1,178 @@
|
||||
# 41 - Вход в контекст разработки ассистента 1C (2026-05-18)
|
||||
|
||||
## Назначение
|
||||
|
||||
Этот документ является короткой, но полной точкой входа для нового чата, нового Codex-сеанса или нового инженера.
|
||||
|
||||
Он фиксирует актуальное состояние архитектуры после закрытия последнего semantic replay по saved-session `gen-mo1t93wq-jy0453e` и коммита:
|
||||
|
||||
- `9c86407 Зафиксировать семантическую целостность VAT, debt mirror и trace-ответов`
|
||||
|
||||
Главная цель проекта не изменилась:
|
||||
|
||||
- построить 1C-ассистента, который сам выбирает безопасные маршруты по MCP/1C evidence;
|
||||
- не превращать систему в набор хардкодных доменных скрепок;
|
||||
- отвечать бизнесово полезно, прямо и честно;
|
||||
- не выдавать неподтвержденные inference как confirmed 1C fact.
|
||||
|
||||
## Что читать первым
|
||||
|
||||
Для быстрого входа читать в таком порядке:
|
||||
|
||||
1. `AGENTS.md`
|
||||
2. `graphify-out/GRAPH_REPORT.md`
|
||||
3. `docs/ARCH/11 - architecture_turnaround/README.md`
|
||||
4. `docs/ARCH/11 - architecture_turnaround/21 - current_status_canon_2026-05-01.md`
|
||||
5. `docs/ARCH/11 - architecture_turnaround/24 - agentic_semantic_development_loop_and_autorun_hygiene_2026-05-10.md`
|
||||
6. `docs/ARCH/11 - architecture_turnaround/40 - mixed_schema_primitive_closure_replay_2026-05-13.md`
|
||||
7. этот документ
|
||||
8. актуальные Tasker-карточки с label `1C assistant` и `Архитектура`
|
||||
|
||||
Исторические документы `01`-`20` важны как trail решений, но текущий рабочий статус берется из `21`, `24`, `40`, этого документа и Tasker.
|
||||
|
||||
## Текущий статус модулей
|
||||
|
||||
Post-F Semantic Integrity Hardening:
|
||||
|
||||
- статус: `99%`, operationally closed;
|
||||
- теперь это regression gate, а не активный denominator;
|
||||
- защищает stale scope, wrong focus_object, repeated pivots, post-pivot arbitration, VAT materialization, debt mirror polarity, selected-object continuity и answer-shape truth.
|
||||
|
||||
Planner Autonomy Consolidation:
|
||||
|
||||
- статус: `100%` для declared phase83 slice;
|
||||
- planner-brain, catalog alignment, live-readiness gate и mixed replay приняты;
|
||||
- это не означает arbitrary 1C autonomy, но это закрывает первый мозг маршрутов.
|
||||
|
||||
Open-World Schema/Primitive Discovery:
|
||||
|
||||
- phases97-105 приняты и сохранены как canaries;
|
||||
- phase105 mixed schema/primitive closure replay accepted `13/13`;
|
||||
- модуль находится на manual-review readiness, а не на blind coding stage.
|
||||
|
||||
Agentic Semantic Development Loop:
|
||||
|
||||
- статус: `99%`;
|
||||
- stage loop, business-audit handoff, save-after-acceptance gate и autorun hygiene работают;
|
||||
- human GUI checkpoint остается финальным high-signal подтверждением.
|
||||
|
||||
Последний semantic integrity cut:
|
||||
|
||||
- saved session: `gen-mo1t93wq-jy0453e`;
|
||||
- final replay: `artifacts/domain_runs/saved_session_gen_mo1t93wq_jy0453e_rerun_final_semantic_20260518`;
|
||||
- результат: `accepted`, `31/31 passed`, `0 failed`, `execution_status=exact`;
|
||||
- закрытые seams: VAT same-period carryover, stale MCP discovery counterparty in short debt mirror, sale-trace lot/batch honesty, broad best-year net-ranking honesty.
|
||||
|
||||
## Архитектурная концепция
|
||||
|
||||
Система состоит из нескольких связанных слоев.
|
||||
|
||||
Assistant runtime:
|
||||
|
||||
- внешний фасад живого ассистента, GUI и runtime-сессий;
|
||||
- основной pressure center все еще вокруг `assistantService.ts`, но бизнесовая логика постепенно вынесена в специализированные модули;
|
||||
- runtime обязан сохранять session state, но не должен позволять старой памяти победить explicit current-turn meaning.
|
||||
|
||||
Exact address lane:
|
||||
|
||||
- `AddressQueryService`, `addressRecipeCatalog`, `addressIntentResolver`, `addressFilterExtractor`, `address_runtime/*`;
|
||||
- отвечает за VAT, receivables/payables, inventory, value-flow, bank operations, accounting result, procurement, debt aging, inventory quality events и связанные factual replies;
|
||||
- exact route может быть fast path, но не может обходить truth gate, scope gate и answer-shape gate.
|
||||
|
||||
MCP discovery/planner lane:
|
||||
|
||||
- `assistantMcpDiscoveryPlanner`, `assistantMcpCatalogIndex`, `assistantMcpDiscoveryPilotExecutor`, `assistantMcpDiscoveryRuntimeBridge`;
|
||||
- выбирает reviewed primitive chains через metadata, entity grounding, documents, movements, value-flow, route candidates;
|
||||
- не должен превращать unknown или proxy-only evidence в confirmed fact.
|
||||
|
||||
Data-need graph and route-candidate layer:
|
||||
|
||||
- описывает вопрос пользователя как бизнесовую потребность, а не только как route id;
|
||||
- хранит subject, fact family, action family, period, aggregation, ranking, comparison, proof expectation, missing axes и forbidden-overclaim flags;
|
||||
- `route_candidate` превращает missing proof family в конкретный enablement target, а не в размытое “не умеем”.
|
||||
|
||||
Continuity and transition layer:
|
||||
|
||||
- `assistantTransitionPolicy`, `assistantContinuityPolicy`, `assistantMcpDiscoveryTurnInputAdapter`, navigation state и focus/answer object helpers;
|
||||
- решает, что переносится между turn-ами: organization, counterparty, period, selected object, answer_object, provenance bundle;
|
||||
- explicit current-turn entity/period/action должны побеждать stale organization, stale focus_object и старые discovery candidates.
|
||||
|
||||
Answer shaping and response policy:
|
||||
|
||||
- `assistantMcpDiscoveryAnswerAdapter`, `assistantMcpDiscoveryResponseCandidate`, `assistantMcpDiscoveryResponsePolicy`, factual reply builders;
|
||||
- пользовательский ответ должен начинаться с прямого business answer;
|
||||
- proof, caveats, row limits и method notes идут после ответа;
|
||||
- internal route ids, capability ids, raw debug enums и service mechanics не должны попадать в финальный ответ.
|
||||
|
||||
GUI, autoruns and runtime artifacts:
|
||||
|
||||
- `autoRuns`, `eval`, `assistantService`, `addressTextRepair`;
|
||||
- GUI autoruns являются human checkpoint и replay history;
|
||||
- сохранение вопросов не равно AGENT replay;
|
||||
- saved AGENT pack допустим только после live replay and review;
|
||||
- UTF-8 без BOM и отсутствие mojibake являются acceptance surface, а не косметикой.
|
||||
|
||||
## Главные инварианты
|
||||
|
||||
- Сначала проверяется человеческий смысл вопроса и ответа, потом debug.
|
||||
- Live replay важнее зеленых unit tests.
|
||||
- Explicit текущий субъект сильнее stale scope.
|
||||
- Valid clarification is not a bug.
|
||||
- Debt mirror должен различать `мы должны` и `нам должны`.
|
||||
- Bank-like counterparty не является обычным поставщиком или клиентом без purpose/operation evidence.
|
||||
- VAT period carryover должен сохранять тот же период, если пользователь говорит `за этот период`.
|
||||
- Inventory sale trace может подтвердить sale trace by nomenclature, но не exact selected lot без batch/lot proof.
|
||||
- Broad business overview не должен ранжировать unreliable net, если один из потоков ограничен row cap.
|
||||
- No route/proxy/MCP/debug garbage in final answer.
|
||||
|
||||
## Текущие canary/replay anchors
|
||||
|
||||
Ключевые canaries:
|
||||
|
||||
- `phase83_planner_brain_alignment_live_20260501_readygate_rerun3`
|
||||
- `address_truth_harness_post_f_cross_stage_canary_agent_20260424_live7`
|
||||
- `inventory_stock_open_world_breadth_rerun_semantic_integrity_20260501_fix5`
|
||||
- `phase90`-`phase96` route-candidate/proof-family acceptance chain
|
||||
- `phase97_financial_counterparty_flow_hints_live4`
|
||||
- `phase98_limit_honesty_business_language_live3`
|
||||
- `phase99_large_query_budget_continuation_live2`
|
||||
- `phase100_large_query_continuation_ux_live2`
|
||||
- `phase101_inventory_root_scope_no_warehouse_clarification_live1`
|
||||
- `phase102_debt_mirror_clean_scope_polarity_live3`
|
||||
- `phase103_financial_role_purpose_arbitration_live3`
|
||||
- `phase104_generic_role_tail_anchor_hygiene`
|
||||
- `phase105_mixed_schema_primitive_closure_live3`
|
||||
- `saved_session_gen_mo1t93wq_jy0453e_rerun_final_semantic_20260518`
|
||||
|
||||
Если новый фикс касается соседней зоны, соответствующий replay нужно использовать как semantic regression gate.
|
||||
|
||||
## Как продолжать в новом чате
|
||||
|
||||
Новый Codex-сеанс должен начинать так:
|
||||
|
||||
1. прочитать `AGENTS.md`;
|
||||
2. прочитать `graphify-out/GRAPH_REPORT.md`;
|
||||
3. прочитать этот документ, README, `21`, `24`, `40`;
|
||||
4. проверить `git status --short`;
|
||||
5. не коммитить runtime_job artifacts без явного решения;
|
||||
6. определить текущий active module и его denominator;
|
||||
7. если пользователь принес run id, сначала читать human Q/A, затем artifacts/debug;
|
||||
8. если внесены code changes, запускать targeted tests, build по необходимости, semantic replay, graphify rebuild;
|
||||
9. после accepted replay обновлять docs/Tasker, если меняется архитектурный статус.
|
||||
|
||||
## Текущее направление после этого среза
|
||||
|
||||
Следующий крупный фокус:
|
||||
|
||||
- закрепить agentic semantic replay loop как регулярный gate после крупных фиксов;
|
||||
- минимизировать ручную роль пользователя до финального GUI checkpoint;
|
||||
- продолжать движение к open-world bounded autonomy, где ассистент не ждет хардкодного route-per-domain, а выбирает reviewed MCP primitive path по data-need graph, route_candidate и evidence gates.
|
||||
|
||||
При этом нельзя объявлять проект universal arbitrary-1C agent.
|
||||
|
||||
Честная формулировка текущего состояния:
|
||||
|
||||
- система уже умеет много устойчивых 1C-контуров;
|
||||
- bounded MCP autonomy substrate реально работает;
|
||||
- route-candidate-driven enablement показал, как превращать gaps в reviewed routes;
|
||||
- но широкая arbitrary schema traversal все еще должна расширяться через replay-backed slices, а не через свободную импровизацию.
|
||||
+175
@@ -0,0 +1,175 @@
|
||||
# 42 - Project Audit Milestone And Next Vector (2026-05-18)
|
||||
|
||||
## Purpose
|
||||
|
||||
This note records the May-18 audit milestone after a repo-first review of:
|
||||
|
||||
- current runtime code shape;
|
||||
- graphify pressure centers;
|
||||
- current architecture canon in `21`, `24`, `40`, and `41`;
|
||||
- Tasker handoff cards for `1C assistant` / `1С-ассистент`;
|
||||
- latest accepted live replay and saved-session closure artifacts.
|
||||
|
||||
Its purpose is not to reopen old slices.
|
||||
|
||||
Its purpose is to:
|
||||
|
||||
- freeze the current project map in one place;
|
||||
- state what is actually closed, what is still open, and what is merely pressure-tested;
|
||||
- define the next unified development vector after the current sync pass.
|
||||
|
||||
## Audit Result
|
||||
|
||||
The project is materially beyond the old "build first exact routes" stage.
|
||||
|
||||
The real current architecture is a bounded MCP-first assistant built from these active layers:
|
||||
|
||||
- assistant runtime and orchestration facade;
|
||||
- exact address lane;
|
||||
- MCP discovery / planner lane;
|
||||
- data-need graph and route-candidate layer;
|
||||
- continuity / transition / selected-object state layer;
|
||||
- truth gate and answer-shaping layer;
|
||||
- AGENT semantic replay operating loop;
|
||||
- GUI / autorun / runtime artifact layer.
|
||||
|
||||
The most connected code pressure centers remain:
|
||||
|
||||
- `executeAssistantMcpDiscoveryPilot()`
|
||||
- `buildAssistantMcpDiscoveryTurnInput()`
|
||||
- `ChannelRegistry`
|
||||
- `composeFactualReplyBody()`
|
||||
- `extractAddressFilters()`
|
||||
- `repairAddressMojibake()`
|
||||
|
||||
This confirms that the current blast radius is not only in one route or one wording family. The highest-risk seams still sit at:
|
||||
|
||||
- runtime input assembly;
|
||||
- continuity and stale-scope arbitration;
|
||||
- MCP execution and evidence shaping;
|
||||
- final answer truthfulness and text hygiene.
|
||||
|
||||
## Current Module Map
|
||||
|
||||
### Operationally closed or used as regression gates
|
||||
|
||||
- `Post-F Semantic Integrity Hardening`: operationally closed at `99%`
|
||||
- `Planner Autonomy Consolidation`: closed at `100%`
|
||||
- `Route-Candidate-Driven Enablement Loop`: closed at `100%`
|
||||
- reviewed proof-family routes through phases `93-96`
|
||||
- business-overview breadth slices through the currently accepted reviewed families
|
||||
|
||||
### Active but already implementation-heavy
|
||||
|
||||
- `Open-World Schema/Primitive Discovery`: `95%`
|
||||
- phases `97-105` are accepted and saved
|
||||
- current closure replay: `phase105_mixed_schema_primitive_closure_live3`, `13/13`
|
||||
- module status: manual-review readiness, not blind coding stage
|
||||
|
||||
### Active operating layer
|
||||
|
||||
- `Agentic Semantic Development Loop`: `99%`
|
||||
- dogfood loop accepted
|
||||
- autorun/runtime Cyrillic hygiene accepted
|
||||
- manual GUI confirmation still required before treating fat packs as fully human-accepted
|
||||
|
||||
## Latest Accepted Semantic Closure
|
||||
|
||||
Latest saved-session closure:
|
||||
|
||||
- source saved session: `gen-mo1t93wq-jy0453e`
|
||||
- replay artifact: `artifacts/domain_runs/saved_session_gen_mo1t93wq_jy0453e_rerun_final_semantic_20260518`
|
||||
- result: `accepted`
|
||||
- score: `31/31 passed`
|
||||
- execution status: `exact`
|
||||
- commit anchor: `9c86407 Зафиксировать семантическую целостность VAT, debt mirror и trace-ответов`
|
||||
|
||||
This closure additionally hardened:
|
||||
|
||||
- same-period VAT carryover;
|
||||
- stale MCP discovery counterparty contamination in short debt-mirror follow-ups;
|
||||
- sale-trace honesty between nomenclature trace and exact lot/batch proof;
|
||||
- broad best-year net-ranking honesty under row-cap asymmetry.
|
||||
|
||||
## Important Accepted Breadth Boundary
|
||||
|
||||
`phase86` must be treated as a real accepted contour in the current map:
|
||||
|
||||
- spec: `docs/orchestration/address_truth_harness_phase86_business_overview_debt_position.json`
|
||||
- accepted replay: `artifacts/domain_runs/address_truth_harness_phase86_business_overview_debt_position_live_20260504_debt2`
|
||||
|
||||
Meaning:
|
||||
|
||||
- explicit-period `business_overview` may include confirmed receivables/payables snapshot on an explicit as-of date;
|
||||
- all-time follow-up must not reuse the old debt snapshot as current or general debt position;
|
||||
- debt quality, overdue debt, credit risk, profit, and margin remain bounded unless separately proven.
|
||||
|
||||
This boundary matters because it is a clean example of the current project style:
|
||||
|
||||
- expand breadth through reviewed evidence;
|
||||
- widen answer usefulness;
|
||||
- keep stale-scope and overclaim protection intact.
|
||||
|
||||
## Documentation And Tasker Audit Findings
|
||||
|
||||
### What was already good
|
||||
|
||||
- the repo canon in `21`, `24`, `40`, and `41` is coherent and materially up to date;
|
||||
- the high-level Tasker card set `01-17` already covers the architecture spine well;
|
||||
- the dedicated context-entry card `[1С-ассистент] Вход в контекст разработки ассистента 1С` already works as the right top-level handoff card.
|
||||
|
||||
### What was missing or underrepresented
|
||||
|
||||
- latest May-18 saved-session closure was not reflected everywhere;
|
||||
- the current honest `95%` status for `Open-World Schema/Primitive Discovery` needed to be stated more explicitly in Tasker;
|
||||
- the accepted `phase86` debt-position breadth boundary was present in repo docs and artifacts, but was not explicit enough in the card layer;
|
||||
- the practical review order `human Q/A first -> replay artifacts -> debug later` needed to be restated in the main handoff card layer;
|
||||
- the current "active gate" reality around semantic-control / fat GUI review was still more explicit in repo docs than in the Tasker map.
|
||||
|
||||
## Unified Next Development Vector
|
||||
|
||||
The project should not fork into unrelated planning threads.
|
||||
|
||||
The current unified vector is:
|
||||
|
||||
1. Close the current human acceptance gate cleanly.
|
||||
2. Institutionalize the AGENT semantic replay loop as the normal post-fix gate.
|
||||
3. Expand open-world bounded autonomy only through replay-backed breadth slices.
|
||||
4. Reduce pressure on central continuity and intent seams while preserving existing regression gates.
|
||||
|
||||
In practical terms this means:
|
||||
|
||||
- first finish `phase105` GUI/manual review or the equivalent fat user pack review;
|
||||
- if the review is clean, close the current `Open-World Schema/Primitive Discovery` module honestly;
|
||||
- if the review exposes a real semantic defect, convert it into a narrow `phase106 repair/replay`, not a broad architecture rewrite;
|
||||
- continue future breadth through reviewed primitive descriptors, data-need coverage, route-candidate enablement, and replay-backed acceptance;
|
||||
- do not regress into domain-hardcode-first growth.
|
||||
|
||||
## What Should Not Become The Next Vector
|
||||
|
||||
The next vector should not be:
|
||||
|
||||
- "rewrite the runtime again";
|
||||
- "add routes opportunistically without replay discipline";
|
||||
- "treat green tests or route ids as primary acceptance";
|
||||
- "expand arbitrary schema traversal before the current closure gate is honestly reviewed";
|
||||
- "replace the AGENT loop with ad hoc manual debugging."
|
||||
|
||||
## Recommended Immediate Work Order
|
||||
|
||||
1. Keep the main context-entry card and current module cards synchronized with repo canon.
|
||||
2. Add or maintain one explicit Tasker card for the current semantic-control / GUI/manual acceptance gate if that gate is not clearly represented.
|
||||
3. Use `phase105` and the May-18 saved-session closure as the current top replay anchors.
|
||||
4. After the card sync, plan the next slice only from the audited state above, not from older percentage snapshots or stale docs.
|
||||
|
||||
## Honest Project Status Statement
|
||||
|
||||
The project already has a real bounded MCP autonomy substrate and a strong semantic hardening backbone.
|
||||
|
||||
It is not a universal arbitrary-1C agent yet.
|
||||
|
||||
The correct current status is:
|
||||
|
||||
- many important 1C contours are already stable and replay-backed;
|
||||
- the main remaining risk is not absence of architecture, but semantic drift on mixed human-style pressure surfaces;
|
||||
- the next development denominator is controlled breadth expansion after an honest current acceptance closure, not a reset.
|
||||
+360
@@ -0,0 +1,360 @@
|
||||
# 43 - Business Answer Contract And Semantic Audit Uplift (2026-05-18)
|
||||
|
||||
## Purpose
|
||||
|
||||
This note freezes the next real project module after the May-18 project audit.
|
||||
|
||||
Its purpose is to turn a high-quality human audit of real runs into:
|
||||
|
||||
- a runtime answer-shaping module;
|
||||
- a stronger semantic replay audit contract;
|
||||
- a concrete execution order for the next development stage.
|
||||
|
||||
The core conclusion is:
|
||||
|
||||
- the assistant already finds many real facts correctly;
|
||||
- the current weak point is not raw retrieval;
|
||||
- the weak point is the conversion from confirmed facts into a business-useful answer and a business-grade replay verdict.
|
||||
|
||||
In short:
|
||||
|
||||
`truth/retrieval is materially ahead of user-facing answer quality and semantic audit quality`
|
||||
|
||||
## Canonical Diagnosis
|
||||
|
||||
The current assistant too often behaves like a careful technical reporter instead of a strong 1C business analyst.
|
||||
|
||||
This means:
|
||||
|
||||
- confirmed numbers are found;
|
||||
- organization/date context is often preserved;
|
||||
- truth and anti-overclaim guards are active;
|
||||
- but the final answer is still overloaded with caveats, low on management interpretation, weak on next action, and not stable enough on semantic disambiguation.
|
||||
|
||||
The current failure pattern is:
|
||||
|
||||
1. the system proves a fact;
|
||||
2. the truth layer leaks directly into the user answer;
|
||||
3. the user receives a cautious technical block instead of a business answer;
|
||||
4. the replay evaluator notices this only partially;
|
||||
5. the run remains technically respectable but business-weak.
|
||||
|
||||
## What The Human Audit Proved
|
||||
|
||||
The human audit established two linked facts.
|
||||
|
||||
### 1. The current audit layer is too weak
|
||||
|
||||
If the AGENT semantic replay audit were as strong as the human review, more runs would be rejected or repaired before being treated as healthy.
|
||||
|
||||
The current replay stack can already see some of this through metrics such as:
|
||||
|
||||
- `accountant_actionability_score`
|
||||
- `mechanism_specificity_score`
|
||||
- `followup_context_retention_score`
|
||||
|
||||
But the practical business reading is still underpowered.
|
||||
|
||||
The system can tell that the answer is weak.
|
||||
It is still not good enough at explaining why it is weak in the same business language a strong human reviewer uses.
|
||||
|
||||
### 2. The runtime answer layer is the main product gap
|
||||
|
||||
The main user-facing problem is not "the system cannot compute".
|
||||
|
||||
The main problem is:
|
||||
|
||||
`the system cannot consistently convert computed truths into a concise, useful, accountant-grade answer`
|
||||
|
||||
This gap shows up as:
|
||||
|
||||
- dirty answer shape;
|
||||
- too much defensive wording in the main body;
|
||||
- weak distinction between cashflow, profit, debt, bank contour, inventory snapshot, and historical inventory;
|
||||
- weak business takeaway;
|
||||
- missing next action;
|
||||
- technical or truth-gate wording leaking into the user-facing answer.
|
||||
|
||||
## Architectural Reading Of The Gap
|
||||
|
||||
This audit should be read as a split between two layers.
|
||||
|
||||
### Layer A: Truth Layer
|
||||
|
||||
This layer answers:
|
||||
|
||||
- what is confirmed;
|
||||
- by which evidence;
|
||||
- within which date window;
|
||||
- with which limitations;
|
||||
- whether overclaim protection should block or soften the answer.
|
||||
|
||||
This layer is already substantial and should remain strict.
|
||||
|
||||
### Layer B: Business Answer Layer
|
||||
|
||||
This layer answers:
|
||||
|
||||
- what the result means for the business user;
|
||||
- which figures matter first;
|
||||
- what ambiguity should be surfaced explicitly;
|
||||
- what should be checked next;
|
||||
- how to keep the answer readable without lying.
|
||||
|
||||
This layer is the main missing product denominator.
|
||||
|
||||
Current problem:
|
||||
|
||||
`Layer A is too visible; Layer B is too weak`
|
||||
|
||||
## Exact Code Seams
|
||||
|
||||
The current implementation seams match this diagnosis closely.
|
||||
|
||||
### Runtime answer shaping seams
|
||||
|
||||
- `llm_normalizer/backend/src/services/answerComposer.ts`
|
||||
- `llm_normalizer/backend/src/services/address_runtime/composeStage.ts`
|
||||
- `llm_normalizer/backend/src/services/assistantTruthAnswerPolicyRuntimeAdapter.ts`
|
||||
- `llm_normalizer/backend/src/services/assistantDebugPayloadAssembler.ts`
|
||||
|
||||
Relevant active contracts already exist:
|
||||
|
||||
- `answer_contract_stage4_v1`
|
||||
- `answer_structure_v11`
|
||||
- `direct_answer`
|
||||
- `mechanism_block`
|
||||
- `uncertainty_block`
|
||||
- `next_step_block`
|
||||
|
||||
This means the next step is not a greenfield rewrite.
|
||||
It is a targeted strengthening of the answer contract and reply renderer.
|
||||
|
||||
### Replay / audit seams
|
||||
|
||||
- `llm_normalizer/backend/src/services/evalService.ts`
|
||||
- `llm_normalizer/backend/src/eval/p0_eval_runner.ts`
|
||||
- `llm_normalizer/backend/src/eval/p0_metric_definitions.ts`
|
||||
- `llm_normalizer/backend/src/eval/p0_acceptance_gate.ts`
|
||||
|
||||
These seams already compute weak/strong answer signals, but they do not yet encode the full business-grade audit logic demonstrated by the human review.
|
||||
|
||||
## Next Module Definition
|
||||
|
||||
The next module should be named:
|
||||
|
||||
`Business Answer Contract + Semantic Audit Uplift`
|
||||
|
||||
It must be treated as one module with two subtracks, not as unrelated work.
|
||||
|
||||
### Track 1. Runtime Business Answer Contract
|
||||
|
||||
Goal:
|
||||
|
||||
- make the assistant answer like a usable 1C analyst without weakening truthfulness.
|
||||
|
||||
Required outcomes:
|
||||
|
||||
1. Introduce stable answer shapes for business question families.
|
||||
2. Move caveats out of the main answer body and compress them into one honest boundary block.
|
||||
3. Force a management-first direct answer before evidence details.
|
||||
4. Always provide a concrete next action when the contour allows it.
|
||||
5. Prevent technical leakage into the user-facing answer.
|
||||
|
||||
### Track 2. Semantic Audit Uplift
|
||||
|
||||
Goal:
|
||||
|
||||
- make AGENT replay review detect the same answer-quality failures that a strong human auditor detects.
|
||||
|
||||
Required outcomes:
|
||||
|
||||
1. Detect when the answer is factually grounded but business-useless.
|
||||
2. Detect when ambiguity was handled weakly or silently.
|
||||
3. Detect when caveats dominate the main answer instead of being bounded cleanly.
|
||||
4. Detect when heterogeneous quantities are surfaced as misleading business totals.
|
||||
5. Detect when the answer lacks a management takeaway or next step.
|
||||
|
||||
## Required Runtime Changes
|
||||
|
||||
### 1. Introduce answer intent shapes
|
||||
|
||||
The runtime should stop relying only on broad reply classes such as:
|
||||
|
||||
- `factual`
|
||||
- `factual_with_explanation`
|
||||
- `partial_coverage`
|
||||
- `clarification_required`
|
||||
|
||||
It should add stable business answer shapes such as:
|
||||
|
||||
- `inventory_snapshot`
|
||||
- `historical_inventory_snapshot`
|
||||
- `cashflow_overview`
|
||||
- `profit_vs_cashflow_disambiguation`
|
||||
- `counterparty_value_flow`
|
||||
- `bank_flow_classification`
|
||||
- `tax_payable`
|
||||
- `accounts_payable`
|
||||
- `accounts_receivable`
|
||||
- `business_overview_summary`
|
||||
|
||||
Each shape should have its own user-facing render contract.
|
||||
|
||||
### 2. Introduce ambiguity-first handling for overloaded business words
|
||||
|
||||
Critical words such as:
|
||||
|
||||
- "заработала"
|
||||
- "прибыль"
|
||||
- "деньги"
|
||||
- "должны"
|
||||
- "остатки"
|
||||
- "оборот"
|
||||
- "выручка"
|
||||
|
||||
must not silently collapse into one interpretation.
|
||||
|
||||
The answer should explicitly split the meaning when needed:
|
||||
|
||||
- cashflow meaning;
|
||||
- accounting profit meaning;
|
||||
- debt snapshot meaning;
|
||||
- turnover meaning.
|
||||
|
||||
### 3. Force management-first answer order
|
||||
|
||||
The default order should become:
|
||||
|
||||
1. business conclusion;
|
||||
2. 3-5 key figures;
|
||||
3. one short boundary/limitation line;
|
||||
4. next useful step.
|
||||
|
||||
This order should be preferred over:
|
||||
|
||||
- raw table-first answers;
|
||||
- long limitation-first answers;
|
||||
- technical explanation-first answers.
|
||||
|
||||
### 4. Suppress misleading aggregate quantities
|
||||
|
||||
For heterogeneous inventory and similar mixed lists, the runtime should avoid presenting meaningless aggregate counts as if they were strong management metrics.
|
||||
|
||||
This is especially important when a count mixes radically different unit types.
|
||||
|
||||
### 5. Add actionability by contract
|
||||
|
||||
Every relevant answer family should end with a next useful option, for example:
|
||||
|
||||
- show document drilldown;
|
||||
- split by months;
|
||||
- separate bank from clients;
|
||||
- compute pure accounting profit;
|
||||
- show overdue aging;
|
||||
- open top counterparties;
|
||||
- explain why this debt remains open.
|
||||
|
||||
This should be contract-driven, not an optional wording flourish.
|
||||
|
||||
## Required Audit Changes
|
||||
|
||||
### 1. Upgrade replay verdict language
|
||||
|
||||
The replay review should explicitly distinguish:
|
||||
|
||||
- factually wrong;
|
||||
- factually right but business-wrong;
|
||||
- factually right but ambiguity-handled-poorly;
|
||||
- factually right but too technical/leaky;
|
||||
- factually right but low-actionability.
|
||||
|
||||
### 2. Add stronger answer-quality probes
|
||||
|
||||
The semantic audit should explicitly score:
|
||||
|
||||
- management conclusion present or absent;
|
||||
- key figure prioritization quality;
|
||||
- limitation compression quality;
|
||||
- ambiguity handling quality;
|
||||
- next-step usefulness;
|
||||
- bank/business contour classification quality;
|
||||
- follow-up interpretation continuity.
|
||||
|
||||
### 3. Treat “technical cleanliness” as a first-class acceptance surface
|
||||
|
||||
If the answer leaks technical mechanics into the business response, that must be treated as a real quality defect, not as harmless debug residue.
|
||||
|
||||
### 4. Strengthen human-style post-run findings
|
||||
|
||||
The replay artifacts should move closer to the human audit style:
|
||||
|
||||
- what worked;
|
||||
- what the user actually wanted;
|
||||
- what was answered instead;
|
||||
- why the answer is still weak;
|
||||
- what exact runtime behavior should be changed.
|
||||
|
||||
## Proposed Execution Order
|
||||
|
||||
The next execution order should be:
|
||||
|
||||
1. freeze this module and Tasker it;
|
||||
2. implement runtime answer-shape uplift first;
|
||||
3. rerun focused semantic packs against the same business questions;
|
||||
4. then tighten replay audit scoring and narrative findings using the new denominator;
|
||||
5. only after that widen breadth again.
|
||||
|
||||
Reason:
|
||||
|
||||
- if audit is improved before answer contracts, we mostly get stronger failure reporting;
|
||||
- if answer contracts are improved first, the next audit pass can judge a better target surface.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
The module should be accepted only when the following become true on focused replay packs.
|
||||
|
||||
### Runtime acceptance
|
||||
|
||||
- direct answers start with business meaning, not caveat noise;
|
||||
- ambiguous business terms are split honestly when needed;
|
||||
- cashflow vs profit confusion is handled explicitly;
|
||||
- bank-like contours are classified without pretending they are ordinary customer revenue;
|
||||
- mixed inventory counts are not surfaced as misleading management totals;
|
||||
- next-step guidance is present and useful.
|
||||
|
||||
### Audit acceptance
|
||||
|
||||
- weak business answers are called out even when retrieval is correct;
|
||||
- replay findings read closer to a senior analyst review than to a metric dump;
|
||||
- `accountant_actionability_score`, `mechanism_specificity_score`, and `followup_context_retention_score` stop being chronically weak on the target pack;
|
||||
- accepted runs no longer pass merely because the truth layer is clean.
|
||||
|
||||
## What This Module Is Not
|
||||
|
||||
This module is not:
|
||||
|
||||
- a new domain-route spree;
|
||||
- a planner rewrite;
|
||||
- a truth-gate rollback;
|
||||
- a generic UX polish task.
|
||||
|
||||
It is the missing business-answer contract between the already-strong retrieval core and the user.
|
||||
|
||||
## Recommended Immediate Tasker Shape
|
||||
|
||||
One active card should represent this module explicitly, with subtasks for:
|
||||
|
||||
1. answer intent shapes;
|
||||
2. ambiguity handler for overloaded business words;
|
||||
3. business-first render order;
|
||||
4. actionability contract;
|
||||
5. semantic audit uplift and replay rubric alignment.
|
||||
|
||||
## Honest Status Line
|
||||
|
||||
The project is now at the point where:
|
||||
|
||||
- retrieval competence is no longer the main differentiator;
|
||||
- answer usefulness and replay audit quality are the next denominator;
|
||||
- if this module lands well, the assistant will stop sounding like a debug log and start sounding like a real 1C analyst.
|
||||
@@ -58,13 +58,15 @@ This package answers the next question:
|
||||
38. [38 - financial_role_purpose_arbitration_2026-05-13.md](./38%20-%20financial_role_purpose_arbitration_2026-05-13.md)
|
||||
39. [39 - generic_role_tail_anchor_hygiene_2026-05-13.md](./39%20-%20generic_role_tail_anchor_hygiene_2026-05-13.md)
|
||||
40. [40 - mixed_schema_primitive_closure_replay_2026-05-13.md](./40%20-%20mixed_schema_primitive_closure_replay_2026-05-13.md)
|
||||
41. [41 - assistant_context_entry_2026-05-18.md](./41%20-%20assistant_context_entry_2026-05-18.md)
|
||||
|
||||
## Current Status Snapshot (2026-05-13)
|
||||
## Current Status Snapshot (2026-05-18)
|
||||
|
||||
This package is no longer planning-only.
|
||||
|
||||
Status canon for planning:
|
||||
|
||||
- The fastest current handoff document is now [41 - assistant_context_entry_2026-05-18.md](./41%20-%20assistant_context_entry_2026-05-18.md).
|
||||
- The current operational overlay is now [24 - agentic_semantic_development_loop_and_autorun_hygiene_2026-05-10.md](./24%20-%20agentic_semantic_development_loop_and_autorun_hygiene_2026-05-10.md).
|
||||
- The active engineering surface is no longer only individual route hardening; it is the repo-native AGENT/stage-loop operating system that should generate/review/replay/audit/repair/rerun current-stage packs before saving accepted autoruns.
|
||||
- The first dogfood stage loop for `agentic_semantic_development_loop` is accepted in artifacts, but manual GUI confirmation remains required before treating a fat AGENT pack as fully human-accepted.
|
||||
@@ -153,6 +155,7 @@ Status canon for planning:
|
||||
- The seventh broader schema/primitive discovery support slice is [38 - financial_role_purpose_arbitration_2026-05-13.md](./38%20-%20financial_role_purpose_arbitration_2026-05-13.md), now accepted live and saved as a user-runnable AGENT autorun.
|
||||
- The eighth broader schema/primitive discovery support slice is [39 - generic_role_tail_anchor_hygiene_2026-05-13.md](./39%20-%20generic_role_tail_anchor_hygiene_2026-05-13.md), now accepted live and saved as a user-runnable AGENT autorun.
|
||||
- The mixed schema/primitive closure replay is [40 - mixed_schema_primitive_closure_replay_2026-05-13.md](./40%20-%20mixed_schema_primitive_closure_replay_2026-05-13.md), now accepted live and saved as a user-runnable AGENT autorun.
|
||||
- The latest saved-session semantic integrity closure is `saved_session_gen_mo1t93wq_jy0453e_rerun_final_semantic_20260518`, accepted `31/31` after repairing VAT same-period carryover, stale MCP-discovery counterparty carryover in short debt mirror turns, sale-trace lot/batch honesty, and broad best-year net-ranking honesty.
|
||||
|
||||
It now documents a turnaround that is already operational in code, already materially past the acute regression breakpoint, and already moved through bounded MCP autonomy, Post-F hardening, inventory breadth proof, and the declared Planner Autonomy slice:
|
||||
|
||||
@@ -423,6 +426,7 @@ Read in this order:
|
||||
39. `38 - financial_role_purpose_arbitration_2026-05-13.md`
|
||||
40. `39 - generic_role_tail_anchor_hygiene_2026-05-13.md`
|
||||
41. `40 - mixed_schema_primitive_closure_replay_2026-05-13.md`
|
||||
42. `41 - assistant_context_entry_2026-05-18.md`
|
||||
|
||||
## Planning Rules
|
||||
|
||||
|
||||
@@ -50,6 +50,12 @@
|
||||
"expected_requested_result_modes": ["confirmed_balance"],
|
||||
"expected_result_modes": ["confirmed_balance"]
|
||||
},
|
||||
{
|
||||
"intent": "inventory_margin_ranking_for_nomenclature",
|
||||
"expected_selected_recipes": ["address_inventory_margin_ranking_for_nomenclature_v1"],
|
||||
"expected_requested_result_modes": ["confirmed_balance"],
|
||||
"expected_result_modes": ["confirmed_balance"]
|
||||
},
|
||||
{
|
||||
"intent": "inventory_purchase_to_sale_chain",
|
||||
"expected_selected_recipes": ["address_inventory_purchase_to_sale_chain_v1"],
|
||||
|
||||
@@ -0,0 +1,109 @@
|
||||
{
|
||||
"schema_version": "domain_scenario_manifest_v1",
|
||||
"scenario_id": "inventory_margin_ranking_agent_loop_20260522",
|
||||
"domain": "inventory_margin_ranking",
|
||||
"title": "Inventory nomenclature margin ranking limited-answer loop",
|
||||
"description": "Shared-session replay for nomenclature profitability ranking: missing period clarification, period-scoped insufficient realization/cost evidence, and follow-up action quality.",
|
||||
"acceptance_canon": {
|
||||
"root_step_id": "step_01_margin_root_needs_period",
|
||||
"primary_user_path": [
|
||||
"step_01_margin_root_needs_period",
|
||||
"step_02_september_2017_period",
|
||||
"step_03_show_cost_base_lines",
|
||||
"step_04_expand_to_2017",
|
||||
"step_05_account_41_not_01"
|
||||
],
|
||||
"required_paraphrase_families": [
|
||||
"colloquial",
|
||||
"canonical"
|
||||
],
|
||||
"required_carryover_invariants": [
|
||||
"intent_scope",
|
||||
"period_scope",
|
||||
"organization_scope",
|
||||
"answer_shape"
|
||||
]
|
||||
},
|
||||
"analysis_context": {
|
||||
"as_of_date": "2026-05-22",
|
||||
"source": "manual_export_and_codex_agent_loop"
|
||||
},
|
||||
"steps": [
|
||||
{
|
||||
"step_id": "step_01_margin_root_needs_period",
|
||||
"title": "Root asks nomenclature high/low profit without period",
|
||||
"question": "Какая номеклатура товара реализована с высокой прибылью какая с низкой",
|
||||
"node_role": "root",
|
||||
"paraphrase_family": "colloquial",
|
||||
"expected_capability": "inventory_inventory_margin_ranking_for_nomenclature",
|
||||
"expected_result_mode": "clarification_required"
|
||||
},
|
||||
{
|
||||
"step_id": "step_02_september_2017_period",
|
||||
"title": "User provides period",
|
||||
"question": "сентябрь 2017",
|
||||
"node_role": "critical_child",
|
||||
"paraphrase_family": "colloquial",
|
||||
"depends_on": [
|
||||
"step_01_margin_root_needs_period"
|
||||
],
|
||||
"expected_capability": "inventory_inventory_margin_ranking_for_nomenclature",
|
||||
"expected_result_mode": "limited_accounting_answer",
|
||||
"required_carryover_invariants": [
|
||||
"intent_scope",
|
||||
"period_scope",
|
||||
"organization_scope"
|
||||
]
|
||||
},
|
||||
{
|
||||
"step_id": "step_03_show_cost_base_lines",
|
||||
"title": "Follow-up asks for found evidence after no sales",
|
||||
"question": "покажи найденные строки себестоимостной базы",
|
||||
"node_role": "critical_child",
|
||||
"paraphrase_family": "canonical",
|
||||
"depends_on": [
|
||||
"step_02_september_2017_period"
|
||||
],
|
||||
"expected_result_mode": "evidence_or_honest_boundary",
|
||||
"required_carryover_invariants": [
|
||||
"intent_scope",
|
||||
"period_scope",
|
||||
"organization_scope"
|
||||
]
|
||||
},
|
||||
{
|
||||
"step_id": "step_04_expand_to_2017",
|
||||
"title": "User expands period to full year",
|
||||
"question": "расширь до 2017 года",
|
||||
"node_role": "critical_child",
|
||||
"paraphrase_family": "colloquial",
|
||||
"depends_on": [
|
||||
"step_02_september_2017_period"
|
||||
],
|
||||
"expected_capability": "inventory_inventory_margin_ranking_for_nomenclature",
|
||||
"expected_result_mode": "ranking_or_limited_accounting_answer",
|
||||
"required_carryover_invariants": [
|
||||
"intent_scope",
|
||||
"period_scope",
|
||||
"organization_scope"
|
||||
]
|
||||
},
|
||||
{
|
||||
"step_id": "step_05_account_41_not_01",
|
||||
"title": "User corrects account family to 41 not fixed assets",
|
||||
"question": "анализ по 41 счету а не 01",
|
||||
"node_role": "critical_child",
|
||||
"paraphrase_family": "colloquial",
|
||||
"depends_on": [
|
||||
"step_04_expand_to_2017"
|
||||
],
|
||||
"expected_capability": "inventory_inventory_margin_ranking_for_nomenclature",
|
||||
"expected_result_mode": "same_inventory_margin_context_or_clarification",
|
||||
"required_carryover_invariants": [
|
||||
"intent_scope",
|
||||
"period_scope",
|
||||
"organization_scope"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user