ДОМЕНЫ - ВОПРОСЫ - ОРРКЕСТРАЦИЯ - БАЗА - Поднять внешний domain-case loop для Codex с baseline/rerun артефактами
This commit is contained in:
@@ -1,9 +1,9 @@
|
||||
# ADDRESS Query Docs
|
||||
|
||||
Дата: 2026-04-08
|
||||
Дата: 2026-04-13
|
||||
Статус синхронизации: актуализировано по текущему коду в `llm_normalizer/backend/src/services/*`.
|
||||
|
||||
## Актуальный статус (2026-04-08)
|
||||
## Актуальный статус (2026-04-13)
|
||||
|
||||
- Этап стабилизации закрыт под `strict_policy=route`.
|
||||
- Step-0 pre-prod rails закрыт (reference-domain + nightly automation).
|
||||
@@ -47,8 +47,12 @@
|
||||
- Task Scheduler: `NDC_ADDRESS_Nightly_Regression` временно `Disabled` (ручной режим до стабилизации infra-канала).
|
||||
- Текущий production-контур: `question_mode=address_query`, live-first через MCP.
|
||||
- Следующий этап: `Step-5` Architecture + UX Quality (LLM-first валидация входа, улучшение пользовательского ответа, без расширения domain scope).
|
||||
- Contracts domain increment (2026-04-13):
|
||||
- прямой вопрос об открытых договорах теперь идет в exact-capability `open_contracts_confirmed_as_of_date`;
|
||||
- heuristic `list_open_contracts` сохранен как diagnostic-only слой;
|
||||
- business-view exact-ответа усилен через `net/gross`, split `special_valid` vs `dirty_unresolved` и разрез компонентных остатков.
|
||||
|
||||
## Что реально реализовано в коде (срез 2026-04-08)
|
||||
## Что реально реализовано в коде (срез 2026-04-13)
|
||||
|
||||
Поддерживаемые intents в runtime:
|
||||
|
||||
@@ -60,7 +64,8 @@
|
||||
- `customer_revenue_and_payments` (Wave-1 B3 value, gate-closed)
|
||||
- `supplier_payouts_profile` (Wave-1 B3 value, gate-closed)
|
||||
- `contract_usage_and_value` (Wave-1 B3 value, gate-closed)
|
||||
- `list_open_contracts`
|
||||
- `open_contracts_confirmed_as_of_date`
|
||||
- `list_open_contracts` (diagnostic heuristic)
|
||||
- `list_payables_counterparties`
|
||||
- `list_receivables_counterparties`
|
||||
- `account_balance_snapshot`
|
||||
@@ -83,6 +88,7 @@
|
||||
|
||||
- `address_scenario_matrix.md` - актуальная матрица сценариев `question -> intent -> recipe_id`.
|
||||
- `query_recipes_v1.md` - фактический каталог runtime recipes и их контрактов.
|
||||
- `../../TECH/address_open_contracts_confirmed_as_of_date_spec.md` - exact-spec для домена открытых договоров на дату.
|
||||
- `runtime_readiness_matrix_v1.md` - статус готовности сценариев по текущему коду.
|
||||
- `address_runtime_contracts.md` - актуальный debug/output контракт address lane.
|
||||
- `runtime_integration_plan.md` - фактическая схема интеграции в `assistantService`.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Address Scenario Matrix (V1)
|
||||
|
||||
Дата: 2026-04-02
|
||||
Дата: 2026-04-13
|
||||
Режим: `question_mode=address_query` (отдельно от deep-analysis)
|
||||
|
||||
## Scope
|
||||
@@ -21,7 +21,8 @@
|
||||
|
||||
| scenario_id | Пользовательский вопрос | intent | required_filters (runtime) | optional_filters | target_entity_family | recipe_id (runtime) | expected_response_type (runtime) | priority |
|
||||
|---|---|---|---|---|---|---|---|---|
|
||||
| AQ-P0-01 | Какие договоры не закрыты на текущую дату? | `list_open_contracts` | - | `as_of_date`, `organization`, `limit` | `ACCOUNTING_REGISTER`, `DOCUMENT`, `NSI_CATALOG` | `address_open_contracts_candidates_v1` | `FACTUAL_LIST` | P0 |
|
||||
| AQ-P0-01 | Какие есть открытые договоры на дату? | `open_contracts_confirmed_as_of_date` | `as_of_date` (`as_of_date` defaulted from period end) | `period_from`, `period_to`, `organization`, `counterparty`, `contract`, `limit`, `sort` | `ACCOUNTING_REGISTER`, `DOCUMENT`, `NSI_CATALOG` | `address_open_contracts_confirmed_as_of_date_v1` | `FACTUAL_LIST` | P0 |
|
||||
| AQ-P0-01H | Покажи кандидаты незакрытых договоров / где спорные хвосты по договорам? | `list_open_contracts` | - | `as_of_date`, `organization`, `limit` | `ACCOUNTING_REGISTER`, `DOCUMENT`, `NSI_CATALOG` | `address_open_contracts_candidates_v1` | `FACTUAL_LIST` | P0 |
|
||||
| AQ-P0-02 | Кому мы должны денег на сегодня? | `list_payables_counterparties` | - | `as_of_date`, `counterparty`, `contract`, `limit` | `ACCOUNTING_REGISTER` | `address_movements_payables_v1` | `FACTUAL_LIST` | P0 |
|
||||
| AQ-P0-03 | Кто должен нам денег на сегодня? | `list_receivables_counterparties` | - | `as_of_date`, `counterparty`, `contract`, `limit` | `ACCOUNTING_REGISTER` | `address_movements_receivables_v1` | `FACTUAL_LIST` | P0 |
|
||||
| AQ-P0-04 | Какой остаток по счету 60 на дату? | `account_balance_snapshot` | `account` (`as_of_date` defaulted) | `as_of_date`, `period_from`, `period_to`, `limit` | `ACCOUNTING_REGISTER`, `CHART_OF_ACCOUNTS` | `address_movements_account_snapshot_v1` | `FACTUAL_SUMMARY` | P0 |
|
||||
@@ -42,19 +43,21 @@
|
||||
- Если mode распознан как `address_query`, ответ строится через whitelist recipe + MCP live path.
|
||||
- Если `shape=EXPLAIN_OR_REASON`, запрос не идет в address lane (handoff в deep-analysis).
|
||||
- Если обязательные фильтры не извлечены, возвращается `LIMITED_WITH_REASON` с `limited_reason_category=missing_anchor`.
|
||||
- Для `open_contracts_confirmed_as_of_date` запрещена silent-подмена на `list_open_contracts`; при недоступности exact-ответа допустим только честный `LIMITED_WITH_REASON`.
|
||||
- Для `account_balance_snapshot` и `documents_forming_balance`:
|
||||
- `as_of_date` берется из `period_to`, если период задан;
|
||||
- иначе default на текущую дату runtime.
|
||||
- Для `documents/bank by counterparty|contract` период по умолчанию не форсируется (all-time), с runtime лимитами и fallback-логикой.
|
||||
- `COMPOUND_FACTUAL_QUERY` пока только детектируется; multi-intent execution не реализован.
|
||||
|
||||
## Runtime status note (2026-04-02)
|
||||
## Runtime status note (2026-04-13)
|
||||
|
||||
Реально реализованы в runtime:
|
||||
|
||||
- `period_coverage_profile`
|
||||
- `document_type_and_account_section_profile`
|
||||
- `list_open_contracts`
|
||||
- `open_contracts_confirmed_as_of_date`
|
||||
- `list_open_contracts` (diagnostic heuristic)
|
||||
- `open_items_by_counterparty_or_contract`
|
||||
- `list_documents_by_counterparty`
|
||||
- `bank_operations_by_counterparty`
|
||||
|
||||
@@ -1,5 +1,7 @@
|
||||
# Статус сложных вопросов и карта переиспользования (2026-04-02)
|
||||
|
||||
Файл сохранен под историческим именем `complex_questions_status_and_reuse_map_2026-04-02.md`, но дополнен актуальным обновлением на 2026-04-13.
|
||||
|
||||
Контур: `question_mode=address_query`
|
||||
|
||||
## 1. Что реально есть в коде сейчас
|
||||
@@ -43,3 +45,15 @@
|
||||
1. Закрыть Batch-1 (`Q1..Q7`, `Q28`) на базе уже подтвержденных `R01/R02` + `R03` + часть `R07`.
|
||||
2. После Batch-1 перейти к lifecycle (Batch-2), не смешивая его с risk/аномалиями.
|
||||
3. Каждую пачку закрывать run-pack артефактами и обязательным comparator к baseline.
|
||||
|
||||
|
||||
## 5. Update 2026-04-13: что уже перестало быть только design-layer
|
||||
|
||||
- Класс вопросов про открытые договоры на дату больше не остается чисто heuristic/runtime-gap сценарием.
|
||||
- Для прямого business wording теперь есть отдельный exact-path:
|
||||
- `open_contracts_confirmed_as_of_date`
|
||||
- `address_open_contracts_confirmed_as_of_date_v1`
|
||||
- Это не отменяет диагностический `list_open_contracts`, но меняет его роль:
|
||||
- heuristic-layer теперь служит для diagnostic/triage сценариев;
|
||||
- exact business answer строится отдельным compute-route.
|
||||
- Следующий remaining gap по этому домену теперь лежит не в route existence, а в entity normalization и executive presentation.
|
||||
|
||||
@@ -1,6 +1,8 @@
|
||||
# ADDRESS Project Status Rails Graph (2026-04-08)
|
||||
|
||||
Дата среза: 2026-04-08
|
||||
Файл сохранен под историческим именем `project_status_rails_graph_2026-04-08.md`, но дополнен актуальным update-блоком на 2026-04-13.
|
||||
|
||||
Дата базового среза: 2026-04-08
|
||||
Контур: `question_mode=address_query`
|
||||
|
||||
## Граф статуса
|
||||
@@ -65,3 +67,17 @@ flowchart LR
|
||||
- Added debug/log audit fields: `dialog_continuation_contract_v2`, `address_retry_audit`.
|
||||
- Targeted regression after hardening: `246/246` PASS (`assistantAddressFollowupContext`, `addressQueryRuntimeM23`, `assistantAddressLlmPredecompose`).
|
||||
- Living router increment: conversational `chat` mode added for non-data messages with safe fallback to deep pipeline (`assistantLivingRouter 4/4`, `assistantLivingChatMode 1/1`, build PASS).
|
||||
|
||||
|
||||
## Contracts Exact Increment Update (2026-04-13)
|
||||
|
||||
- Для прямого вопроса об открытых договорах введен exact-capability:
|
||||
- `open_contracts_confirmed_as_of_date`
|
||||
- `address_open_contracts_confirmed_as_of_date_v1`
|
||||
- `list_open_contracts` больше не рассматривается как target-route для прямого business question и сохранен только как diagnostic heuristic-layer.
|
||||
- Поверх exact snapshot добавлен business-view:
|
||||
- `net_open_balance`
|
||||
- `gross_open_balance`
|
||||
- split `special_valid` / `dirty_unresolved`
|
||||
- Актуальный targeted gate после increment:
|
||||
- `367/367 PASS` (`addressQueryRuntimeM23 + assistantLivingRouter + assistantWave17 regression`).
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Query Recipes V1 (Address Query)
|
||||
|
||||
Дата: 2026-04-02
|
||||
Дата: 2026-04-13
|
||||
Контур: `question_mode=address_query` (live-first, whitelist only)
|
||||
|
||||
## 1) Safe Access Contract
|
||||
@@ -48,7 +48,8 @@
|
||||
| `address_document_type_and_account_section_profile_v1` | `document_type_and_account_section_profile` | профиль типов документов + заполненность разделов учета | - | `period_from`, `period_to`, `organization`, `limit` | `document_section_profile` | `preferred` |
|
||||
| `address_movements_payables_v1` | `list_payables_counterparties` | movement-срез по обязательствам | - | `as_of_date`, `counterparty`, `contract`, `limit` | `movements` | `preferred` |
|
||||
| `address_movements_receivables_v1` | `list_receivables_counterparties` | movement-срез по требованиям | - | `as_of_date`, `counterparty`, `contract`, `limit` | `movements` | `preferred` |
|
||||
| `address_open_contracts_candidates_v1` | `list_open_contracts` | кандидаты незакрытых договоров | - | `as_of_date`, `organization`, `limit` | `movements` | `preferred` |
|
||||
| `address_open_contracts_confirmed_as_of_date_v1` | `open_contracts_confirmed_as_of_date` | подтвержденный срез открытых договоров на дату | `as_of_date` | `period_from`, `period_to`, `organization`, `counterparty`, `contract`, `limit`, `sort` | `open_contracts_confirmed_as_of_balance_profile` | `strict` |
|
||||
| `address_open_contracts_candidates_v1` | `list_open_contracts` | диагностические кандидаты незакрытых договоров | - | `as_of_date`, `organization`, `limit` | `movements` | `preferred` |
|
||||
| `address_open_items_by_party_or_contract_v1` | `open_items_by_counterparty_or_contract` | открытые позиции по party/contract | - (`service guard`: нужен `counterparty OR contract`) | `as_of_date`, `counterparty`, `contract`, `limit` | `movements` | `preferred` |
|
||||
| `address_documents_by_counterparty_v1` | `list_documents_by_counterparty` | документы по контрагенту | `counterparty` | `period_from`, `period_to`, `as_of_date`, `organization`, `limit`, `sort` | `bank_docs` | `preferred` |
|
||||
| `address_bank_operations_by_counterparty_v1` | `bank_operations_by_counterparty` | банковские операции по контрагенту | `counterparty` | `period_from`, `period_to`, `as_of_date`, `organization`, `limit`, `sort` | `bank_docs` | `preferred` |
|
||||
@@ -65,7 +66,8 @@
|
||||
- `document_type_and_account_section_profile`;
|
||||
- `documents/bank by counterparty|contract`;
|
||||
- `open_items_by_counterparty_or_contract`;
|
||||
- `list_open_contracts`.
|
||||
- `list_open_contracts`;
|
||||
- `open_contracts_confirmed_as_of_date`.
|
||||
- Для all-time запросов `documents/bank by *` runtime поднимает limit до max.
|
||||
- Для account intents при явном `account` limit поднимается до `200`.
|
||||
|
||||
@@ -91,6 +93,9 @@ Legacy совместимость:
|
||||
- auto-broaden периода до доступных данных (`period_window_auto_broadened_to_available_data`).
|
||||
- Для `documents/bank by *` при anchor mismatch:
|
||||
- factual fallback на ближайшие строки (`anchor_not_matched_fallback_rows`) вместо silent empty.
|
||||
- Для `open_contracts_confirmed_as_of_date`:
|
||||
- exact недоступность должна заканчиваться `LIMITED_WITH_REASON`;
|
||||
- `list_open_contracts` допустим только как отдельный diagnostic capability, не как silent fallback.
|
||||
|
||||
## 8) Result Modes
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Runtime Integration Plan (question_mode=address_query)
|
||||
|
||||
Дата среза: 2026-04-02
|
||||
Дата среза: 2026-04-13
|
||||
|
||||
## 1) Цель
|
||||
|
||||
@@ -54,7 +54,8 @@ Address lane уже встроен в `AssistantService` и включен featu
|
||||
|
||||
Реализовано:
|
||||
|
||||
- `list_open_contracts`
|
||||
- `open_contracts_confirmed_as_of_date`
|
||||
- `list_open_contracts` (diagnostic heuristic)
|
||||
- `list_payables_counterparties`
|
||||
- `list_receivables_counterparties`
|
||||
- `account_balance_snapshot`
|
||||
@@ -92,6 +93,7 @@ Address lane уже встроен в `AssistantService` и включен featu
|
||||
- Period auto-broaden for by-counterparty/by-contract docs+bank intents
|
||||
- Anchor mismatch fallback для document/bank intents
|
||||
- Contract-docs recovery path через bank-like rows
|
||||
- Для `open_contracts_confirmed_as_of_date` silent degrade в `list_open_contracts` запрещен; при недоступности exact-ответа допускается только `LIMITED_WITH_REASON`.
|
||||
|
||||
## 8) Compound Scope
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Runtime Readiness Matrix V1 (Code Sync)
|
||||
|
||||
Дата: 2026-04-08
|
||||
Дата: 2026-04-13
|
||||
|
||||
Формат: `scenario -> structural_readiness -> runtime_readiness -> blocker`
|
||||
|
||||
@@ -17,7 +17,8 @@
|
||||
|
||||
| scenario_id | scenario | structural_readiness | runtime_readiness | current_blocker | next_action |
|
||||
|---|---|---|---|---|---|
|
||||
| AQ-P0-01 | list_open_contracts | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | contract candidates зависят от качества movement materialization | усилить contract resolver confidence и стабилизировать non-empty профили |
|
||||
| AQ-P0-01 | open_contracts_confirmed_as_of_date | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | exact core работает; остаточный риск теперь в entity normalization и качестве 76-аналитик | усиливать identity quality gates, special/dirty split и executive summary |
|
||||
| AQ-P0-01H | list_open_contracts (diagnostic) | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | heuristic shortlist пригоден только для диагностики и не должен подменять exact final output | держать как diagnostic-only capability и не смешивать с exact-path |
|
||||
| AQ-P0-02 | list_payables_counterparties | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | broad prompts могут давать sparse/empty | держать curated positive + периодные подсказки |
|
||||
| AQ-P0-03 | list_receivables_counterparties | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | broad prompts могут давать sparse/empty | держать curated positive + периодные подсказки |
|
||||
| AQ-P0-04 | account_balance_snapshot | STRUCTURALLY_VISIBLE | LIVE_QUERYABLE_WITH_LIMITS | часть кейсов упирается в account-scope/materialization | продолжить account token/shape audit |
|
||||
@@ -38,7 +39,19 @@
|
||||
| AQ-P1-10 | account_turnover_snapshot | STRUCTURALLY_VISIBLE | UNKNOWN | intent/recipe отсутствуют в runtime | планировать как отдельный домен Step-4 |
|
||||
| AQ-P1-11 | list_documents_by_type | STRUCTURALLY_VISIBLE | UNKNOWN | intent/recipe отсутствуют в runtime | планировать как отдельный домен Step-4 |
|
||||
|
||||
## Sync Notes (2026-04-08)
|
||||
## Sync Notes (2026-04-13)
|
||||
|
||||
- В runtime появился отдельный exact intent для открытых договоров:
|
||||
- `open_contracts_confirmed_as_of_date`
|
||||
- `address_open_contracts_confirmed_as_of_date_v1`
|
||||
- `list_open_contracts` сохранен как diagnostic heuristic-layer и больше не считается целевым final route для прямого бизнес-вопроса об открытых договорах.
|
||||
- Для open-contracts exact добавлен второй business-layer поверх точного snapshot:
|
||||
- `net_open_balance`
|
||||
- `gross_open_balance`
|
||||
- `balance_components[]`
|
||||
- split `special_valid` vs `dirty_unresolved`
|
||||
- Актуальный targeted code gate:
|
||||
- `addressQueryRuntimeM23 + assistantLivingRouter + assistantWave17 regression = 367/367 PASS`.
|
||||
|
||||
- В runtime реализованы by-contract intents:
|
||||
- `list_documents_by_contract`
|
||||
|
||||
@@ -1,8 +1,19 @@
|
||||
# 1CLLMARCH Fact Check And Stabilization Plan
|
||||
|
||||
Updated at: 2026-04-11
|
||||
Updated at: 2026-04-13
|
||||
Source baseline: `docs/TECH/1CLLMARCH.md`
|
||||
|
||||
## Update 2026-04-13
|
||||
|
||||
- Exact capability for open contracts as-of date is now implemented:
|
||||
- `open_contracts_confirmed_as_of_date`
|
||||
- `address_open_contracts_confirmed_as_of_date_v1`
|
||||
- The former `list_open_contracts` path remains only as diagnostic heuristic-layer and is no longer the target final route for direct business wording.
|
||||
- The main remaining gap for this domain is now presentation/entity quality, not route existence:
|
||||
- net/gross aggregation,
|
||||
- special vs dirty split,
|
||||
- contract/counterparty identity quality.
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This document fixes the current factual state of the codebase against `1CLLMARCH` and records a production-focused stabilization plan that preserves:
|
||||
|
||||
@@ -1,52 +1,75 @@
|
||||
# Статус проекта на 2026-04-12
|
||||
# Статус проекта на 2026-04-13
|
||||
|
||||
Файл сохранен под историческим именем `STATUS_2026-04-12.md`, но содержимое актуализировано по коду и тестам на 2026-04-13.
|
||||
|
||||
## 1) Что уже стабильно в compute-слое
|
||||
|
||||
- Введены и работают exact-маршруты подтвержденного среза на дату:
|
||||
- В runtime закреплены exact-маршруты подтвержденного среза на дату:
|
||||
- `payables_confirmed_as_of_date` (`address_payables_confirmed_as_of_date_v1`)
|
||||
- `receivables_confirmed_as_of_date` (`address_receivables_confirmed_as_of_date_v1`)
|
||||
- `vat_payable_confirmed_as_of_date` (`address_vat_payable_confirmed_as_of_date_v1`)
|
||||
- Для этих интентов зафиксирован expected route/result mode в:
|
||||
- `vat_liability_confirmed_for_tax_period` (`address_vat_liability_confirmed_tax_period_v1`)
|
||||
- `open_contracts_confirmed_as_of_date` (`address_open_contracts_confirmed_as_of_date_v1`)
|
||||
- Для exact-сценариев зафиксирован контракт:
|
||||
- `requested_result_mode = confirmed_balance`
|
||||
- `result_mode = confirmed_balance`
|
||||
- `capability_route_mode = exact`
|
||||
- Для открытых договоров прямой бизнес-вопрос больше не идет в heuristic shortlist:
|
||||
- exact-вопросы маршрутизируются в `open_contracts_confirmed_as_of_date`;
|
||||
- `list_open_contracts` сохранен как диагностический heuristic-слой, а не как substitute для exact-ответа.
|
||||
- Для exact-интентов ожидания маршрутов закреплены в:
|
||||
- `docs/TECH/address_route_expectations_v1.json`
|
||||
- Режим результата для exact-сценариев закреплен как `confirmed_balance`.
|
||||
|
||||
## 2) Что исправлено в цепных (follow-up) вопросах
|
||||
## 2) Что доведено в follow-up и presentation-слое
|
||||
|
||||
- Исправлен перенос даты среза в коротких продолжениях по долгам:
|
||||
- после вопроса о долгах на дату follow-up по дебиторке наследует `as_of_date`, если новая дата не задана явно.
|
||||
- Добавлен короткий follow-up для НДС:
|
||||
- короткие реплики вида `а ндс?`/`по ндс` теперь корректно идут в VAT exact-route с переносом даты среза из контекста.
|
||||
- Сохранена стратегия LLM-first нормализации с последующим детерминированным compute-роутингом.
|
||||
- Короткие follow-up-вопросы продолжают использовать дату среза из контекста, если новая дата явно не задана.
|
||||
- Для debt/VAT/open-contracts контуров сохранена схема `LLM-first normalize -> deterministic compute route`.
|
||||
- Для exact-кейса открытых договоров presentation-слой стал бизнесовее:
|
||||
- появился `net/gross` слой поверх точного среза;
|
||||
- одна детальная строка = один договор, один контрагент, один тип открытого остатка;
|
||||
- смешанные экономические смыслы не склеиваются в одну строку;
|
||||
- отдельными блоками вынесены `финансовые/специальные` и `спорные/некачественно нормализованные` позиции.
|
||||
- Для open-contracts exact-core отделен от heuristic diagnostics: улучшения бизнес-вывода больше не требуют менять сам route.
|
||||
|
||||
## 3) Что уже покрыто тестами
|
||||
|
||||
- Добавлены/актуализированы тесты на carryover и follow-up:
|
||||
- Актуальный целевой regression-gate:
|
||||
- `llm_normalizer/backend/tests/addressQueryRuntimeM23.test.ts`
|
||||
- `llm_normalizer/backend/tests/assistantAddressFollowupContext.test.ts`
|
||||
- Проверен маршрутный baseline:
|
||||
- `llm_normalizer/backend/tests/addressRouteBaseline.test.ts`
|
||||
- `llm_normalizer/backend/tests/assistantLivingRouter.test.ts`
|
||||
- `llm_normalizer/backend/tests/assistantWave17RunRegression20260411.test.ts`
|
||||
- Текущий кодовый результат:
|
||||
- `367/367` PASS.
|
||||
- В тестах отдельно закрыты:
|
||||
- exact routing для `open_contracts_confirmed_as_of_date`;
|
||||
- отсутствие silent degrade в heuristic для прямого exact-запроса;
|
||||
- business-view блоков `net/gross` и вынос грязных сущностей в спорный блок.
|
||||
|
||||
## 4) Известные ограничения (не считать багом расчета)
|
||||
## 4) Известные ограничения (не считать поломкой exact-core)
|
||||
|
||||
- В разговорных нерелевантных репликах (эмоции/брань/односложные сообщения) система может уйти в `clarification_required`; это относится к conversational-слою, не к compute-расчету.
|
||||
- `query_shape` в части exact-кейсов может оставаться `UNKNOWN` при корректном `intent`; расчетный маршрут при этом работает корректно.
|
||||
- Качество бизнес-категоризации контрагентов (особенно по счету 76) требует отдельной донастройки presentation-слоя.
|
||||
- `query_shape` в части exact-кейсов может оставаться `UNKNOWN` при корректном `intent`; сам вычислительный маршрут при этом работает корректно.
|
||||
- В exact-кейсе открытых договоров главный остаточный риск теперь не в маршрутизации, а в качестве бизнес-сущностей:
|
||||
- неидеальная идентичность `contract_label` / `counterparty_label`;
|
||||
- грязные аналитики по счету `76`;
|
||||
- дальнейшее улучшение executive-summary поверх уже точного среза.
|
||||
- `list_open_contracts` по-прежнему heuristic и должен использоваться только как диагностический слой.
|
||||
- `COMPOUND_FACTUAL_QUERY` остается detection-only: multi-intent execution в runtime пока не включен.
|
||||
|
||||
## 5) Что в приоритете дальше
|
||||
|
||||
1. НДС-контур: усилить доказательную часть расчета "к уплате на дату" и добавить понятную детализацию оснований.
|
||||
2. Цепные вопросы: закрепить перенос контекста между payables/receivables/VAT во всех коротких follow-up формулировках.
|
||||
3. Ответы для UI: довести формат вывода до стабильной блочной структуры без markdown-зависимости.
|
||||
4. Категоризация: отделить поставщиков/заказчиков от банков/госорганов/спецобязательств в итоговой выдаче.
|
||||
1. НДС-контур: усилить exact evidence layer для ответов “НДС к уплате / обязательство за период/на дату”.
|
||||
2. Открытые договоры: усилить quality gates для `contract/counterparty identity`, особенно на `76` и специальных расчетах.
|
||||
3. UI-ответы: довести exact business view до executive-summary уровня без потери доказательности.
|
||||
4. Compound factual queries: не расширять домены раньше, чем появится контролируемый multi-intent execution.
|
||||
|
||||
## 6) Быстрый smoke-check (ручной)
|
||||
|
||||
1. `кому мы должны на сентябрь 2017`
|
||||
2. `а нам кто должен?`
|
||||
3. `кто нам должен на сентябрь 2017`
|
||||
4. `а ндс?`
|
||||
1. `какие есть открытые договора на май 2020`
|
||||
2. `а по ним кто нам должен и кому должны мы?`
|
||||
3. `скок надо ндс платить на март 2020`
|
||||
4. `а на эту же дату`
|
||||
|
||||
Ожидаемое поведение:
|
||||
|
||||
- для 1/3 — `confirmed_balance` в exact-route,
|
||||
- для 2/4 — корректный follow-up с переносом даты среза, без ухода в эвристический shortlist для exact-интентов.
|
||||
- для 1 — exact route `open_contracts_confirmed_as_of_date`, `confirmed_balance`, без подмены на heuristic shortlist;
|
||||
- для 2 — follow-up c сохранением даты и корректным переключением домена;
|
||||
- для 3/4 — exact VAT/payables route с переносом даты среза, если пользователь не задал новую.
|
||||
|
||||
@@ -0,0 +1,176 @@
|
||||
# Address Query Spec: Confirmed Open Contracts As Of Date
|
||||
|
||||
## 1. Контекст проблемы
|
||||
|
||||
Запросы вида:
|
||||
|
||||
- `какие есть открытые договора на май 2020`
|
||||
- `какие договоры открыты на 31.05.2020`
|
||||
- `покажи открытые договоры на дату`
|
||||
|
||||
относятся к классу **балансных договорных запросов** и требуют точного среза открытых взаиморасчетов на дату.
|
||||
|
||||
Историческая проблема состояла в том, что сценарий `list_open_contracts` долгое время жил как heuristic shortlist по движениям `60/62/76`. Для диагностики это полезно, но для прямого бизнес-ответа недостаточно.
|
||||
|
||||
## 2. Цель
|
||||
|
||||
Ввести и зафиксировать exact-capability `open_contracts_confirmed_as_of_date`, который:
|
||||
|
||||
- строит подтвержденный срез договоров с ненулевым остатком взаиморасчетов на дату;
|
||||
- не подменяется heuristic shortlist в финальном пользовательском ответе;
|
||||
- показывает не только точные компоненты, но и управленческий `net/gross` view поверх них;
|
||||
- отделяет специальные валидные позиции от грязных/некачественно нормализованных сущностей.
|
||||
|
||||
## 3. Базовая бизнес-дефиниция
|
||||
|
||||
`Открытый договор = договор, по которому на дату среза есть ненулевой остаток взаиморасчетов.`
|
||||
|
||||
По умолчанию это не означает:
|
||||
|
||||
- “активный по карточке договора”;
|
||||
- “не исполненный по предмету договора”;
|
||||
- “просроченный по сроку оплаты”.
|
||||
|
||||
Это именно балансный срез открытых расчетов.
|
||||
|
||||
## 4. Канонический runtime-контракт
|
||||
|
||||
- `intent = open_contracts_confirmed_as_of_date`
|
||||
- `recipe_id = address_open_contracts_confirmed_as_of_date_v1`
|
||||
- `requested_result_mode = confirmed_balance`
|
||||
- `result_mode = confirmed_balance`
|
||||
- `capability_route_mode = exact`
|
||||
- `query_template = open_contracts_confirmed_as_of_balance_profile`
|
||||
- `account_scope = 60/62/76`
|
||||
- `account_scope_mode = strict`
|
||||
|
||||
## 5. Источник данных
|
||||
|
||||
Основной источник:
|
||||
|
||||
- `РегистрБухгалтерии.Хозрасчетный.Остатки(<as_of_date>)`
|
||||
|
||||
Контур включает остатки по счетам:
|
||||
|
||||
- `60*`
|
||||
- `62*`
|
||||
- `76*`
|
||||
|
||||
Сценарий использует exact snapshot по остаткам, а не только movement-shortlist.
|
||||
|
||||
## 6. Единицы агрегации
|
||||
|
||||
### 6.1 Exact component row
|
||||
|
||||
Минимальная детальная единица ответа:
|
||||
|
||||
- один договор;
|
||||
- один контрагент;
|
||||
- один тип открытого остатка.
|
||||
|
||||
Поддерживаемые типы компонентов:
|
||||
|
||||
- `receivable`
|
||||
- `payable`
|
||||
- `advance_issued`
|
||||
- `advance_received`
|
||||
- `other_receivable`
|
||||
- `other_payable`
|
||||
|
||||
### 6.2 Management profile row
|
||||
|
||||
Поверх component-уровня собирается второй слой:
|
||||
|
||||
- `contract + counterparty`
|
||||
- `net_open_balance`
|
||||
- `gross_open_balance`
|
||||
- `balance_components[]`
|
||||
|
||||
Именно этот слой нужен для бизнес-чтения, чтобы не воспринимать противоположные компоненты как дубли.
|
||||
|
||||
## 7. Категории результата
|
||||
|
||||
### 7.1 Commercial
|
||||
|
||||
Нормально нормализованный договорный профиль, пригодный для основного бизнес-списка.
|
||||
|
||||
### 7.2 Special valid
|
||||
|
||||
Позиция не коммерческая, но валидная по смыслу:
|
||||
|
||||
- финансовые/банковские договоры;
|
||||
- специальные расчетные позиции.
|
||||
|
||||
### 7.3 Dirty unresolved
|
||||
|
||||
Позиция точная по балансу, но грязная по сущностям:
|
||||
|
||||
- не удалось надежно определить контрагента;
|
||||
- договор не похож на устойчивый договорный реквизит;
|
||||
- в поле договора похоже попал контрагент или чужая аналитика;
|
||||
- по одному договору нашлось несколько конфликтующих контрагентов.
|
||||
|
||||
Такие строки не должны смешиваться с основным коммерческим блоком.
|
||||
|
||||
## 8. Quality gates
|
||||
|
||||
### 8.1 Contract identity gate
|
||||
|
||||
Строка не считается качественной коммерческой строкой, если `contract_label`:
|
||||
|
||||
- слишком короткий;
|
||||
- похож на юрлицо, а не на договор;
|
||||
- совпадает с `counterparty_label`;
|
||||
- выглядит как служебная аналитика.
|
||||
|
||||
### 8.2 Counterparty identity gate
|
||||
|
||||
Строка не считается чистой, если:
|
||||
|
||||
- контрагент не определен;
|
||||
- в поле контрагента попал текст договора/служебная аналитика;
|
||||
- контрагент конфликтует между компонентами одного профиля.
|
||||
|
||||
## 9. Политика fallback
|
||||
|
||||
Для `open_contracts_confirmed_as_of_date` запрещено:
|
||||
|
||||
- тихо деградировать в `heuristic_candidates` как финальный ответ;
|
||||
- выдавать diagnostic shortlist вместо точного snapshot без явной маркировки.
|
||||
|
||||
Допустимый fallback только один:
|
||||
|
||||
- `LIMITED_WITH_REASON`, если exact не удалось собрать.
|
||||
|
||||
`list_open_contracts` допускается только как отдельный heuristic diagnostic capability.
|
||||
|
||||
## 10. Контракт ответа
|
||||
|
||||
### 10.1 Exact business answer
|
||||
|
||||
Ответ должен содержать:
|
||||
|
||||
1. статус exact-результата;
|
||||
2. дату среза;
|
||||
3. `net` и `gross` summary;
|
||||
4. блок `чистый открытый остаток по договорам`;
|
||||
5. блоки детальных компонентов;
|
||||
6. отдельный блок `финансовые/специальные позиции`;
|
||||
7. отдельный блок `спорные/некачественно нормализованные позиции`.
|
||||
|
||||
### 10.2 Что пользователь не должен видеть
|
||||
|
||||
- `0` и пустые account placeholders;
|
||||
- смешение противоположных остатков в одной строке;
|
||||
- грязные entity labels в основном коммерческом блоке.
|
||||
|
||||
## 11. Acceptance criteria
|
||||
|
||||
1. Прямой вопрос про открытые договоры на дату идет в `open_contracts_confirmed_as_of_date`, а не в `list_open_contracts`.
|
||||
2. Финальный exact-ответ имеет:
|
||||
- `result_mode = confirmed_balance`
|
||||
- `balance_confirmed = true`
|
||||
- `capability_route_mode = exact`
|
||||
3. Для одного договора возможны несколько component-строк, но management-view показывает также `net/gross` профиль.
|
||||
4. Специальные валидные позиции и грязные сущности разведены в разные блоки.
|
||||
5. Heuristic shortlist не подменяет exact output.
|
||||
Binary file not shown.
+39
@@ -0,0 +1,39 @@
|
||||
name = "domain_analyst"
|
||||
description = "Read-only business and technical analyst for domain-case verdicts based on assistant outputs, JSON debug payloads, diffs, and rerun artifacts."
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "read-only"
|
||||
developer_instructions = """
|
||||
You are the strict domain analyst.
|
||||
|
||||
You do not write product code.
|
||||
You read:
|
||||
- the user question
|
||||
- the assistant answer
|
||||
- technical_debug_payload_json
|
||||
- optional diffs
|
||||
- rerun artifacts
|
||||
|
||||
Your job is to produce a detailed verdict in Russian with strong business focus.
|
||||
|
||||
Always answer in a strict structure:
|
||||
1. Смысл вопроса
|
||||
2. Что реально посчитано
|
||||
3. Где расхождение по бизнес-смыслу
|
||||
4. Где route / capability mismatch
|
||||
5. Evidence quality
|
||||
6. P0 defects
|
||||
7. P1 defects
|
||||
8. P2 defects
|
||||
9. Minimal patch directions
|
||||
10. Acceptance criteria for rerun
|
||||
|
||||
Rules:
|
||||
- Call out non-business garbage explicitly.
|
||||
- Distinguish exact, partial, heuristic, and technical-insufficiency modes.
|
||||
- Do not accept a heuristic result as a final answer.
|
||||
- Do not praise superficial wording improvements if the compute layer is still wrong.
|
||||
- Highlight if an answer is unusable for a manager, accountant, or operator.
|
||||
- If the system answered a weaker question than the user asked, say so explicitly.
|
||||
"""
|
||||
nickname_candidates = ["Lens", "Vector", "Delta"]
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
name = "domain_coder"
|
||||
description = "Implementation-focused agent for minimal domain fixes in 1C/MCP capabilities, routes, schemas, validators, and presentation logic without changing architecture."
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "workspace-write"
|
||||
developer_instructions = """
|
||||
You are the domain implementation agent.
|
||||
|
||||
Your mission:
|
||||
- Read the target case, current answer, JSON/debug payload, and analyst verdict.
|
||||
- Find the smallest domain-only patch that moves the case toward a correct, useful, business-readable answer.
|
||||
- Do not change architecture.
|
||||
- Do not rewrite orchestration globally unless the change is strictly local and domain-scoped.
|
||||
- Prefer exact 1C/MCP-backed routes over heuristics.
|
||||
- If exact data exists in 1C/MCP, use it.
|
||||
- If exact data does not exist, surface a technical insufficiency rather than fabricating a result.
|
||||
|
||||
Allowed change zones:
|
||||
- intents
|
||||
- domain-specific routing
|
||||
- recipes
|
||||
- capability mapping
|
||||
- evidence/source-ref modeling
|
||||
- role modeling
|
||||
- exact/confirmed routes
|
||||
- domain validators
|
||||
- follow-up resolution for a domain case
|
||||
- business-readable presentation
|
||||
|
||||
Forbidden:
|
||||
- broad architecture changes
|
||||
- fake data
|
||||
- silent heuristic masking
|
||||
- large refactors unrelated to the case
|
||||
- changing successful baseline flows without necessity
|
||||
|
||||
Always produce:
|
||||
1. a short coder_plan
|
||||
2. the minimal patch
|
||||
3. a patch_summary
|
||||
4. rerun instructions or executed rerun artifacts
|
||||
"""
|
||||
nickname_candidates = ["Forge", "Quartz", "Helix"]
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
name = "orchestrator"
|
||||
description = "Coordinates a domain-case loop: baseline run, analyst verdict, minimal domain patch, rerun, and final acceptance status."
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "workspace-write"
|
||||
developer_instructions = """
|
||||
You are the orchestrator for domain-case development in a 1C/MCP project.
|
||||
|
||||
Your job:
|
||||
1. Accept a domain case from the user.
|
||||
2. Create or reuse an artifact folder under artifacts/domain_runs/<case_id>/.
|
||||
3. Ask domain_coder for the baseline run and artifact capture.
|
||||
4. Ask domain_analyst for a strict business/route/evidence verdict on the baseline.
|
||||
5. Feed that verdict back to domain_coder for the smallest defensible domain-only patch.
|
||||
6. Run a rerun and collect new artifacts.
|
||||
7. Ask domain_analyst for before/after comparison.
|
||||
8. End with one status: accepted | partial | blocked | needs_exact_capability.
|
||||
|
||||
Hard rules:
|
||||
- Do not change architecture.
|
||||
- Do not allow heuristic output to be presented as a confirmed business answer.
|
||||
- Keep the process artifact-driven.
|
||||
- If the repository structure differs from the template package, inspect the project and adapt scripts/references/paths before the first serious loop.
|
||||
- Make Codex use the domain-case-loop skill when the workflow is repeatable.
|
||||
- When a case is too broad, decompose it into one exact capability question, not into vague prompt tuning.
|
||||
|
||||
Required outputs per cycle:
|
||||
- baseline_output
|
||||
- baseline_debug
|
||||
- analyst_verdict
|
||||
- coder_plan
|
||||
- patch_summary
|
||||
- rerun_output
|
||||
- rerun_debug
|
||||
- before_after_diff
|
||||
- final_status
|
||||
"""
|
||||
nickname_candidates = ["Atlas", "Radian", "North"]
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# Project-scoped Codex configuration
|
||||
# Adapt paths and approval settings to your environment if needed.
|
||||
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "workspace-write"
|
||||
approval_policy = "on-request"
|
||||
project_root_markers = [".git"]
|
||||
|
||||
[agents]
|
||||
max_threads = 3
|
||||
max_depth = 1
|
||||
job_max_runtime_seconds = 3600
|
||||
+107
@@ -0,0 +1,107 @@
|
||||
---
|
||||
name: domain-case-loop
|
||||
description: Use this skill when a user wants to iteratively refine a 1C/MCP domain case through a multi-agent loop: baseline run, JSON analysis, minimal domain patch, rerun, and before/after verdict. Trigger for domain debugging, capability hardening, business-answer quality fixes, follow-up continuity bugs, and exact-vs-heuristic route issues.
|
||||
---
|
||||
|
||||
# Domain case loop
|
||||
|
||||
This skill packages the standard workflow for iterating on a single domain case.
|
||||
|
||||
## Use this skill when
|
||||
|
||||
- the user wants to improve one domain question end-to-end;
|
||||
- the answer exists but is noisy, heuristic, partial, or business-useless;
|
||||
- the route is wrong even if the wording looks better;
|
||||
- there is a gap between exact compute intent and actual fallback output;
|
||||
- there are follow-up / continuation bugs that corrupt business context.
|
||||
|
||||
## Do not use this skill when
|
||||
|
||||
- the user is asking for a broad architecture rewrite;
|
||||
- there is no concrete domain case or no reproducible input;
|
||||
- the task is only prose editing with no technical/domain component;
|
||||
- the task is a generic repo cleanup unrelated to domain capability behavior.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1 — Normalize the case
|
||||
Create `artifacts/domain_runs/<case_id>/case_brief.md` with:
|
||||
- domain name
|
||||
- raw user question
|
||||
- expected business meaning
|
||||
- expected exact capability
|
||||
- expected result mode
|
||||
- known constraints
|
||||
- acceptance criteria draft
|
||||
|
||||
Use `references/case_brief_template.md`.
|
||||
|
||||
### Step 2 — Capture baseline
|
||||
Collect:
|
||||
- baseline assistant answer
|
||||
- baseline technical debug payload
|
||||
- supporting logs if available
|
||||
|
||||
Write:
|
||||
- `baseline_output.md`
|
||||
- `baseline_debug.json`
|
||||
|
||||
### Step 3 — Analyst verdict
|
||||
Spawn `domain_analyst` and provide:
|
||||
- raw question
|
||||
- baseline output
|
||||
- baseline debug payload
|
||||
- optional relevant code excerpts or file paths
|
||||
|
||||
Require a full verdict using `references/verdict_template.md`.
|
||||
|
||||
### Step 4 — Domain patch
|
||||
Spawn `domain_coder` with:
|
||||
- the case brief
|
||||
- the analyst verdict
|
||||
- the baseline artifacts
|
||||
|
||||
Require:
|
||||
- a minimal patch
|
||||
- zero architecture drift
|
||||
- rerun after changes
|
||||
|
||||
### Step 5 — Rerun
|
||||
Capture:
|
||||
- `rerun_output.md`
|
||||
- `rerun_debug.json`
|
||||
- `patch_summary.md`
|
||||
|
||||
### Step 6 — Before/after analysis
|
||||
Spawn `domain_analyst` again for:
|
||||
- before/after comparison
|
||||
- final status recommendation
|
||||
|
||||
### Step 7 — Final status
|
||||
Write `final_status.md` with one of:
|
||||
- accepted
|
||||
- partial
|
||||
- blocked
|
||||
- needs_exact_capability
|
||||
|
||||
## Hard rules
|
||||
|
||||
- Do not count heuristic candidates as confirmed business answers.
|
||||
- If exact data should exist in 1C/MCP, prefer exact route work over prompt cosmetics.
|
||||
- If exact data does not exist yet in the reachable contour, return a technical insufficiency with a crisp blocker.
|
||||
- Never fabricate 1C data.
|
||||
- Keep domain fixes minimal and localized.
|
||||
- Preserve successful baseline scenarios.
|
||||
- Treat follow-up continuity as a state-machine problem, not a wording problem.
|
||||
|
||||
## Domain-specific framing
|
||||
|
||||
For this repository:
|
||||
- architecture must remain unchanged;
|
||||
- 1C/MCP is the primary source of truth;
|
||||
- analyst output must be detailed and business-readable;
|
||||
- answers should be suitable for product hardening, not just debugging notes.
|
||||
|
||||
## Recommended artifact set
|
||||
|
||||
Use the artifact layout from `references/artifact_layout.md`.
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
# Artifact layout
|
||||
|
||||
For each domain case use:
|
||||
|
||||
artifacts/domain_runs/<case_id>/
|
||||
- case_brief.md
|
||||
- baseline_output.md
|
||||
- baseline_debug.json
|
||||
- analyst_verdict.md
|
||||
- coder_plan.md
|
||||
- patch_summary.md
|
||||
- rerun_output.md
|
||||
- rerun_debug.json
|
||||
- before_after_diff.md
|
||||
- final_status.md
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# Case brief template
|
||||
|
||||
## Domain
|
||||
`<domain_name>`
|
||||
|
||||
## Raw user question
|
||||
`<raw_question>`
|
||||
|
||||
## Expected business meaning
|
||||
- ...
|
||||
|
||||
## Expected capability
|
||||
- ...
|
||||
|
||||
## Expected result mode
|
||||
- confirmed_balance / confirmed_tax_liability / partial / technical_insufficiency / other
|
||||
|
||||
## Constraints
|
||||
- no architecture changes
|
||||
- 1C/MCP first
|
||||
- no fabricated values
|
||||
- heuristic is not product success
|
||||
|
||||
## Known current behavior
|
||||
- ...
|
||||
|
||||
## Draft acceptance criteria
|
||||
- ...
|
||||
+8
@@ -0,0 +1,8 @@
|
||||
# Domain constraints
|
||||
|
||||
- Архитектуру проекта не менять.
|
||||
- Максимально использовать 1С/MCP.
|
||||
- Не придумывать значения.
|
||||
- Не считать heuristic ответ продуктовым успехом.
|
||||
- Математика вне 1С допустима только как детерминированный постпроцесс над уже подтвержденными фактами.
|
||||
- Analyst read-only, Coder implementation-focused.
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
# Verdict
|
||||
|
||||
## 1. Смысл вопроса
|
||||
...
|
||||
|
||||
## 2. Что реально посчитано
|
||||
...
|
||||
|
||||
## 3. Где расхождение по бизнес-смыслу
|
||||
...
|
||||
|
||||
## 4. Где route / capability mismatch
|
||||
...
|
||||
|
||||
## 5. Evidence quality
|
||||
- exact / partial / heuristic / technical insufficiency
|
||||
- why
|
||||
|
||||
## 6. P0 defects
|
||||
- ...
|
||||
|
||||
## 7. P1 defects
|
||||
- ...
|
||||
|
||||
## 8. P2 defects
|
||||
- ...
|
||||
|
||||
## 9. Minimal patch directions
|
||||
- ...
|
||||
|
||||
## 10. Acceptance criteria for rerun
|
||||
- ...
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
param(
|
||||
[string]$CaseId = ("case_" + (Get-Date -Format "yyyyMMdd_HHmmss")),
|
||||
[string]$Question = ""
|
||||
)
|
||||
|
||||
$ArtifactDir = Join-Path "artifacts/domain_runs" $CaseId
|
||||
New-Item -ItemType Directory -Force -Path $ArtifactDir | Out-Null
|
||||
|
||||
@"
|
||||
# Case brief
|
||||
- case_id: $CaseId
|
||||
- raw_question: $Question
|
||||
"@ | Set-Content -Encoding UTF8 (Join-Path $ArtifactDir "case_brief.md")
|
||||
|
||||
Write-Host "Created artifact directory: $ArtifactDir"
|
||||
Write-Host "TODO: replace this script with the real project-specific baseline runner."
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
CASE_ID="${1:-case_$(date +%Y%m%d_%H%M%S)}"
|
||||
QUESTION="${2:-}"
|
||||
ARTIFACT_DIR="artifacts/domain_runs/${CASE_ID}"
|
||||
|
||||
mkdir -p "${ARTIFACT_DIR}"
|
||||
|
||||
cat > "${ARTIFACT_DIR}/case_brief.md" <<EOF
|
||||
# Case brief
|
||||
- case_id: ${CASE_ID}
|
||||
- raw_question: ${QUESTION}
|
||||
EOF
|
||||
|
||||
echo "Created artifact directory: ${ARTIFACT_DIR}"
|
||||
echo "TODO: replace this script with the real project-specific baseline runner."
|
||||
@@ -0,0 +1,104 @@
|
||||
# AGENTS.md
|
||||
|
||||
## Назначение проекта
|
||||
|
||||
Этот репозиторий содержит LLM-first + детерминистский контур для доменных запросов по 1С через MCP.
|
||||
Задача Codex в рамках этого проекта — не менять архитектуру, а системно доводить доменные capability и ответы до точного, полезного и бизнес-корректного вида.
|
||||
|
||||
## Главные правила
|
||||
|
||||
### 1. Архитектуру не трогать
|
||||
- Не менять архитектурное ядро проекта.
|
||||
- Не переписывать orchestration, если кейс можно решить в доменном слое.
|
||||
- Не делать широких рефакторингов ради одного доменного кейса.
|
||||
- Не размывать рабочие baseline-сценарии.
|
||||
|
||||
### 2. Максимум 1С/MCP
|
||||
- Приоритет — точный ответ из 1С-контуров через MCP.
|
||||
- Сначала искать точный путь в 1С-модели, регистрах, документах, аналитиках, субконто, остатках и движениях.
|
||||
- Не подменять недостающий exact-route эвристикой, если можно добрать данные из 1С.
|
||||
- Если exact-route пока невозможен, прямо локализовать, чего именно не хватает.
|
||||
|
||||
### 3. Никаких выдумок
|
||||
- Не придумывать факты, суммы, сущности, договоры, контрагентов, статусы.
|
||||
- Не считать heuristic-ответ финальным пользовательским ответом.
|
||||
- Не высасывать “причину открытости / закрытости / долга” без данных.
|
||||
- Любые вычисления вне 1С делать только как детерминированный постпроцесс над уже подтвержденными фактами.
|
||||
|
||||
### 4. Доменные кейсы обрабатываются через capability
|
||||
Каждый серьезный доменный вопрос должен стремиться к отдельному capability, а не к расплывчатому общему route.
|
||||
Примеры:
|
||||
- confirmed_receivables_as_of_date
|
||||
- confirmed_payables_as_of_date
|
||||
- confirmed_vat_liability_for_tax_period
|
||||
- contracts_with_open_settlements_as_of_date
|
||||
|
||||
### 5. Строгая маркировка режимов ответа
|
||||
Допустимые режимы:
|
||||
- `confirmed_balance`
|
||||
- `confirmed_tax_liability`
|
||||
- `partial`
|
||||
- `heuristic_candidates`
|
||||
- `technical_insufficiency`
|
||||
|
||||
Если ответ не подтвержден, это должно быть явно отражено.
|
||||
Heuristic route не считается продуктовым success-состоянием.
|
||||
|
||||
### 6. Analyst vs Coder
|
||||
- `domain_analyst` не пишет продуктовый код.
|
||||
- `domain_coder` не должен сам себе ставить “accepted” без прохождения acceptance criteria.
|
||||
- Orchestrator обязан сохранять артефакты и before/after.
|
||||
|
||||
## Как работать над доменным кейсом
|
||||
|
||||
1. Зафиксировать смысл вопроса.
|
||||
2. Понять, какой capability должен существовать.
|
||||
3. Получить baseline-ответ и baseline JSON.
|
||||
4. Отдать baseline `domain_analyst`.
|
||||
5. Получить P0/P1/P2 + acceptance criteria.
|
||||
6. Внести минимальные доменные правки.
|
||||
7. Выполнить rerun.
|
||||
8. Сравнить before/after.
|
||||
9. Сохранить итог.
|
||||
|
||||
## Что считается плохой практикой
|
||||
|
||||
- Лечить доменные баги только prose-правками.
|
||||
- Маскировать heuristic shortlist под точный ответ.
|
||||
- Путать объект ответа и источник сигнала.
|
||||
- Смешивать бизнес-сущности:
|
||||
- контрагент
|
||||
- договор
|
||||
- объект расчетов
|
||||
- обеспечительный инструмент
|
||||
- госорган
|
||||
- банк
|
||||
- фин. продукт
|
||||
- Держать грязный follow-up context после неудачного turn.
|
||||
|
||||
## Что аналитик должен проверять всегда
|
||||
|
||||
- совпадает ли реальный ответ со смыслом вопроса;
|
||||
- exact vs heuristic;
|
||||
- есть ли подмена вопроса другим сценарием;
|
||||
- route maturity;
|
||||
- evidence completeness;
|
||||
- business readability;
|
||||
- presence of non-business garbage;
|
||||
- stable vs polluted context в follow-up сценариях.
|
||||
|
||||
## Что кодер должен делать всегда
|
||||
|
||||
- минимальный patch;
|
||||
- zero architecture drift;
|
||||
- zero fabricated data;
|
||||
- rerun после изменений;
|
||||
- сохранение артефактов;
|
||||
- no silent fallback masking.
|
||||
|
||||
## Если пакет/skill требует адаптации
|
||||
|
||||
Если фактическая структура репозитория отличается от шаблона:
|
||||
- найти реальные точки входа;
|
||||
- адаптировать scripts, references и prompts;
|
||||
- расширить шаблоны в `.codex/`, но не менять архитектурное ядро продукта.
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
name = "domain_analyst"
|
||||
description = "Read-only business and technical analyst for domain-case verdicts based on assistant outputs, JSON debug payloads, diffs, and rerun artifacts."
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "read-only"
|
||||
developer_instructions = """
|
||||
You are the strict domain analyst.
|
||||
|
||||
You do not write product code.
|
||||
You read:
|
||||
- the user question
|
||||
- the assistant answer
|
||||
- technical_debug_payload_json
|
||||
- optional diffs
|
||||
- rerun artifacts
|
||||
|
||||
Your job is to produce a detailed verdict in Russian with strong business focus.
|
||||
|
||||
Always answer in a strict structure:
|
||||
1. Смысл вопроса
|
||||
2. Что реально посчитано
|
||||
3. Где расхождение по бизнес-смыслу
|
||||
4. Где route / capability mismatch
|
||||
5. Evidence quality
|
||||
6. P0 defects
|
||||
7. P1 defects
|
||||
8. P2 defects
|
||||
9. Minimal patch directions
|
||||
10. Acceptance criteria for rerun
|
||||
|
||||
Rules:
|
||||
- Call out non-business garbage explicitly.
|
||||
- Distinguish exact, partial, heuristic, and technical-insufficiency modes.
|
||||
- Do not accept a heuristic result as a final answer.
|
||||
- Do not praise superficial wording improvements if the compute layer is still wrong.
|
||||
- Highlight if an answer is unusable for a manager, accountant, or operator.
|
||||
- If the system answered a weaker question than the user asked, say so explicitly.
|
||||
"""
|
||||
nickname_candidates = ["Lens", "Vector", "Delta"]
|
||||
+43
@@ -0,0 +1,43 @@
|
||||
name = "domain_coder"
|
||||
description = "Implementation-focused agent for minimal domain fixes in 1C/MCP capabilities, routes, schemas, validators, and presentation logic without changing architecture."
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "workspace-write"
|
||||
developer_instructions = """
|
||||
You are the domain implementation agent.
|
||||
|
||||
Your mission:
|
||||
- Read the target case, current answer, JSON/debug payload, and analyst verdict.
|
||||
- Find the smallest domain-only patch that moves the case toward a correct, useful, business-readable answer.
|
||||
- Do not change architecture.
|
||||
- Do not rewrite orchestration globally unless the change is strictly local and domain-scoped.
|
||||
- Prefer exact 1C/MCP-backed routes over heuristics.
|
||||
- If exact data exists in 1C/MCP, use it.
|
||||
- If exact data does not exist, surface a technical insufficiency rather than fabricating a result.
|
||||
|
||||
Allowed change zones:
|
||||
- intents
|
||||
- domain-specific routing
|
||||
- recipes
|
||||
- capability mapping
|
||||
- evidence/source-ref modeling
|
||||
- role modeling
|
||||
- exact/confirmed routes
|
||||
- domain validators
|
||||
- follow-up resolution for a domain case
|
||||
- business-readable presentation
|
||||
|
||||
Forbidden:
|
||||
- broad architecture changes
|
||||
- fake data
|
||||
- silent heuristic masking
|
||||
- large refactors unrelated to the case
|
||||
- changing successful baseline flows without necessity
|
||||
|
||||
Always produce:
|
||||
1. a short coder_plan
|
||||
2. the minimal patch
|
||||
3. a patch_summary
|
||||
4. rerun instructions or executed rerun artifacts
|
||||
"""
|
||||
nickname_candidates = ["Forge", "Quartz", "Helix"]
|
||||
+38
@@ -0,0 +1,38 @@
|
||||
name = "orchestrator"
|
||||
description = "Coordinates a domain-case loop: baseline run, analyst verdict, minimal domain patch, rerun, and final acceptance status."
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "workspace-write"
|
||||
developer_instructions = """
|
||||
You are the orchestrator for domain-case development in a 1C/MCP project.
|
||||
|
||||
Your job:
|
||||
1. Accept a domain case from the user.
|
||||
2. Create or reuse an artifact folder under artifacts/domain_runs/<case_id>/.
|
||||
3. Ask domain_coder for the baseline run and artifact capture.
|
||||
4. Ask domain_analyst for a strict business/route/evidence verdict on the baseline.
|
||||
5. Feed that verdict back to domain_coder for the smallest defensible domain-only patch.
|
||||
6. Run a rerun and collect new artifacts.
|
||||
7. Ask domain_analyst for before/after comparison.
|
||||
8. End with one status: accepted | partial | blocked | needs_exact_capability.
|
||||
|
||||
Hard rules:
|
||||
- Do not change architecture.
|
||||
- Do not allow heuristic output to be presented as a confirmed business answer.
|
||||
- Keep the process artifact-driven.
|
||||
- If the repository structure differs from the template package, inspect the project and adapt scripts/references/paths before the first serious loop.
|
||||
- Make Codex use the domain-case-loop skill when the workflow is repeatable.
|
||||
- When a case is too broad, decompose it into one exact capability question, not into vague prompt tuning.
|
||||
|
||||
Required outputs per cycle:
|
||||
- baseline_output
|
||||
- baseline_debug
|
||||
- analyst_verdict
|
||||
- coder_plan
|
||||
- patch_summary
|
||||
- rerun_output
|
||||
- rerun_debug
|
||||
- before_after_diff
|
||||
- final_status
|
||||
"""
|
||||
nickname_candidates = ["Atlas", "Radian", "North"]
|
||||
+13
@@ -0,0 +1,13 @@
|
||||
# Project-scoped Codex configuration
|
||||
# Adapt paths and approval settings to your environment if needed.
|
||||
|
||||
model = "gpt-5.4"
|
||||
model_reasoning_effort = "high"
|
||||
sandbox_mode = "workspace-write"
|
||||
approval_policy = "on-request"
|
||||
project_root_markers = [".git"]
|
||||
|
||||
[agents]
|
||||
max_threads = 3
|
||||
max_depth = 1
|
||||
job_max_runtime_seconds = 3600
|
||||
+107
@@ -0,0 +1,107 @@
|
||||
---
|
||||
name: domain-case-loop
|
||||
description: Use this skill when a user wants to iteratively refine a 1C/MCP domain case through a multi-agent loop: baseline run, JSON analysis, minimal domain patch, rerun, and before/after verdict. Trigger for domain debugging, capability hardening, business-answer quality fixes, follow-up continuity bugs, and exact-vs-heuristic route issues.
|
||||
---
|
||||
|
||||
# Domain case loop
|
||||
|
||||
This skill packages the standard workflow for iterating on a single domain case.
|
||||
|
||||
## Use this skill when
|
||||
|
||||
- the user wants to improve one domain question end-to-end;
|
||||
- the answer exists but is noisy, heuristic, partial, or business-useless;
|
||||
- the route is wrong even if the wording looks better;
|
||||
- there is a gap between exact compute intent and actual fallback output;
|
||||
- there are follow-up / continuation bugs that corrupt business context.
|
||||
|
||||
## Do not use this skill when
|
||||
|
||||
- the user is asking for a broad architecture rewrite;
|
||||
- there is no concrete domain case or no reproducible input;
|
||||
- the task is only prose editing with no technical/domain component;
|
||||
- the task is a generic repo cleanup unrelated to domain capability behavior.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1 — Normalize the case
|
||||
Create `artifacts/domain_runs/<case_id>/case_brief.md` with:
|
||||
- domain name
|
||||
- raw user question
|
||||
- expected business meaning
|
||||
- expected exact capability
|
||||
- expected result mode
|
||||
- known constraints
|
||||
- acceptance criteria draft
|
||||
|
||||
Use `references/case_brief_template.md`.
|
||||
|
||||
### Step 2 — Capture baseline
|
||||
Collect:
|
||||
- baseline assistant answer
|
||||
- baseline technical debug payload
|
||||
- supporting logs if available
|
||||
|
||||
Write:
|
||||
- `baseline_output.md`
|
||||
- `baseline_debug.json`
|
||||
|
||||
### Step 3 — Analyst verdict
|
||||
Spawn `domain_analyst` and provide:
|
||||
- raw question
|
||||
- baseline output
|
||||
- baseline debug payload
|
||||
- optional relevant code excerpts or file paths
|
||||
|
||||
Require a full verdict using `references/verdict_template.md`.
|
||||
|
||||
### Step 4 — Domain patch
|
||||
Spawn `domain_coder` with:
|
||||
- the case brief
|
||||
- the analyst verdict
|
||||
- the baseline artifacts
|
||||
|
||||
Require:
|
||||
- a minimal patch
|
||||
- zero architecture drift
|
||||
- rerun after changes
|
||||
|
||||
### Step 5 — Rerun
|
||||
Capture:
|
||||
- `rerun_output.md`
|
||||
- `rerun_debug.json`
|
||||
- `patch_summary.md`
|
||||
|
||||
### Step 6 — Before/after analysis
|
||||
Spawn `domain_analyst` again for:
|
||||
- before/after comparison
|
||||
- final status recommendation
|
||||
|
||||
### Step 7 — Final status
|
||||
Write `final_status.md` with one of:
|
||||
- accepted
|
||||
- partial
|
||||
- blocked
|
||||
- needs_exact_capability
|
||||
|
||||
## Hard rules
|
||||
|
||||
- Do not count heuristic candidates as confirmed business answers.
|
||||
- If exact data should exist in 1C/MCP, prefer exact route work over prompt cosmetics.
|
||||
- If exact data does not exist yet in the reachable contour, return a technical insufficiency with a crisp blocker.
|
||||
- Never fabricate 1C data.
|
||||
- Keep domain fixes minimal and localized.
|
||||
- Preserve successful baseline scenarios.
|
||||
- Treat follow-up continuity as a state-machine problem, not a wording problem.
|
||||
|
||||
## Domain-specific framing
|
||||
|
||||
For this repository:
|
||||
- architecture must remain unchanged;
|
||||
- 1C/MCP is the primary source of truth;
|
||||
- analyst output must be detailed and business-readable;
|
||||
- answers should be suitable for product hardening, not just debugging notes.
|
||||
|
||||
## Recommended artifact set
|
||||
|
||||
Use the artifact layout from `references/artifact_layout.md`.
|
||||
+15
@@ -0,0 +1,15 @@
|
||||
# Artifact layout
|
||||
|
||||
For each domain case use:
|
||||
|
||||
artifacts/domain_runs/<case_id>/
|
||||
- case_brief.md
|
||||
- baseline_output.md
|
||||
- baseline_debug.json
|
||||
- analyst_verdict.md
|
||||
- coder_plan.md
|
||||
- patch_summary.md
|
||||
- rerun_output.md
|
||||
- rerun_debug.json
|
||||
- before_after_diff.md
|
||||
- final_status.md
|
||||
+28
@@ -0,0 +1,28 @@
|
||||
# Case brief template
|
||||
|
||||
## Domain
|
||||
`<domain_name>`
|
||||
|
||||
## Raw user question
|
||||
`<raw_question>`
|
||||
|
||||
## Expected business meaning
|
||||
- ...
|
||||
|
||||
## Expected capability
|
||||
- ...
|
||||
|
||||
## Expected result mode
|
||||
- confirmed_balance / confirmed_tax_liability / partial / technical_insufficiency / other
|
||||
|
||||
## Constraints
|
||||
- no architecture changes
|
||||
- 1C/MCP first
|
||||
- no fabricated values
|
||||
- heuristic is not product success
|
||||
|
||||
## Known current behavior
|
||||
- ...
|
||||
|
||||
## Draft acceptance criteria
|
||||
- ...
|
||||
+8
@@ -0,0 +1,8 @@
|
||||
# Domain constraints
|
||||
|
||||
- Архитектуру проекта не менять.
|
||||
- Максимально использовать 1С/MCP.
|
||||
- Не придумывать значения.
|
||||
- Не считать heuristic ответ продуктовым успехом.
|
||||
- Математика вне 1С допустима только как детерминированный постпроцесс над уже подтвержденными фактами.
|
||||
- Analyst read-only, Coder implementation-focused.
|
||||
+32
@@ -0,0 +1,32 @@
|
||||
# Verdict
|
||||
|
||||
## 1. Смысл вопроса
|
||||
...
|
||||
|
||||
## 2. Что реально посчитано
|
||||
...
|
||||
|
||||
## 3. Где расхождение по бизнес-смыслу
|
||||
...
|
||||
|
||||
## 4. Где route / capability mismatch
|
||||
...
|
||||
|
||||
## 5. Evidence quality
|
||||
- exact / partial / heuristic / technical insufficiency
|
||||
- why
|
||||
|
||||
## 6. P0 defects
|
||||
- ...
|
||||
|
||||
## 7. P1 defects
|
||||
- ...
|
||||
|
||||
## 8. P2 defects
|
||||
- ...
|
||||
|
||||
## 9. Minimal patch directions
|
||||
- ...
|
||||
|
||||
## 10. Acceptance criteria for rerun
|
||||
- ...
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
param(
|
||||
[string]$CaseId = ("case_" + (Get-Date -Format "yyyyMMdd_HHmmss")),
|
||||
[string]$Question = ""
|
||||
)
|
||||
|
||||
$ArtifactDir = Join-Path "artifacts/domain_runs" $CaseId
|
||||
New-Item -ItemType Directory -Force -Path $ArtifactDir | Out-Null
|
||||
|
||||
@"
|
||||
# Case brief
|
||||
- case_id: $CaseId
|
||||
- raw_question: $Question
|
||||
"@ | Set-Content -Encoding UTF8 (Join-Path $ArtifactDir "case_brief.md")
|
||||
|
||||
Write-Host "Created artifact directory: $ArtifactDir"
|
||||
Write-Host "TODO: replace this script with the real project-specific baseline runner."
|
||||
+17
@@ -0,0 +1,17 @@
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
CASE_ID="${1:-case_$(date +%Y%m%d_%H%M%S)}"
|
||||
QUESTION="${2:-}"
|
||||
ARTIFACT_DIR="artifacts/domain_runs/${CASE_ID}"
|
||||
|
||||
mkdir -p "${ARTIFACT_DIR}"
|
||||
|
||||
cat > "${ARTIFACT_DIR}/case_brief.md" <<EOF
|
||||
# Case brief
|
||||
- case_id: ${CASE_ID}
|
||||
- raw_question: ${QUESTION}
|
||||
EOF
|
||||
|
||||
echo "Created artifact directory: ${ARTIFACT_DIR}"
|
||||
echo "TODO: replace this script with the real project-specific baseline runner."
|
||||
@@ -0,0 +1,51 @@
|
||||
# Пакет для мультиагентной отработки доменов в Codex
|
||||
|
||||
Этот пакет подготовлен под задачу итеративной отработки доменных кейсов в проекте 1С/MCP через Codex в VS Code или CLI.
|
||||
|
||||
## Что внутри
|
||||
|
||||
- `AGENTS.md` — корневые проектные инструкции для Codex.
|
||||
- `.codex/config.toml` — проектные настройки Codex.
|
||||
- `.codex/agents/` — три кастомных агента:
|
||||
- `orchestrator.toml`
|
||||
- `domain_coder.toml`
|
||||
- `domain_analyst.toml`
|
||||
- `.codex/skills/domain-case-loop/` — skill для повторяемого цикла:
|
||||
- кейс → прогон → артефакты → аналитика → фиксы → rerun
|
||||
- `docs/` — шаблоны и справочные документы.
|
||||
- `artifacts/domain_runs/` — место для артефактов прогонов.
|
||||
- `СОПРОВОДИТЕЛЬНОЕ_ПИСЬМО.md` — короткое письмо для передачи пакета в Codex.
|
||||
- `ТЗ_НА_РАЗВОРОТ_МУЛЬТИАГЕНТНОГО_КОНТУРА.md` — ТЗ на разворот и адаптацию под реальный репозиторий.
|
||||
|
||||
## Как положить в проект
|
||||
|
||||
1. Распаковать архив в корень репозитория.
|
||||
2. Проверить, что корень проекта определяется корректно.
|
||||
3. Открыть проект в VS Code с Codex extension или в Codex CLI.
|
||||
4. Попросить Codex:
|
||||
- прочитать `AGENTS.md`
|
||||
- проверить `.codex/config.toml`
|
||||
- проверить кастомных агентов в `.codex/agents/`
|
||||
- проверить skill `domain-case-loop`
|
||||
- адаптировать пути, скрипты и ссылки под фактическую структуру репозитория
|
||||
5. После адаптации запустить первый кейс через оркестратор.
|
||||
|
||||
## Базовый способ запуска
|
||||
|
||||
Можно начинать сообщением в Codex примерно такого вида:
|
||||
|
||||
> Отрабатываем домен `open_contracts`.
|
||||
> Возьми skill `domain-case-loop`.
|
||||
> Спауни `domain_analyst` и `domain_coder`.
|
||||
> Кейс: "какие есть открытые договора на май 2020".
|
||||
> Сначала собери артефакты текущего поведения, затем аналитик пусть даст verdict, потом кодер внесет минимальные доменные правки без изменения архитектуры, после этого сделай rerun и сохрани before/after.
|
||||
|
||||
## Важные принципы пакета
|
||||
|
||||
- Архитектурный код проекта не трогать.
|
||||
- Доменные доработки делать в субдоменных сущностях, recipes, routes, schemas, validators, domain-specific mapping и presentation logic.
|
||||
- Максимально использовать 1С-контур через MCP.
|
||||
- Эвристики не считать продуктовым ответом.
|
||||
- Ничего не высасывать из пальца.
|
||||
- Если точный ответ недоступен в 1С-контуре, прямо писать, чего не хватило.
|
||||
- Аналитик работает в read-only логике и не пишет продуктовый код.
|
||||
+14
@@ -0,0 +1,14 @@
|
||||
# Библиотека кейсов
|
||||
|
||||
Для каждого домена поддерживайте набор cases:
|
||||
|
||||
- `id`
|
||||
- `domain`
|
||||
- `raw_question`
|
||||
- `expected_business_meaning`
|
||||
- `expected_capability`
|
||||
- `expected_result_mode`
|
||||
- `must_not_happen`
|
||||
- `acceptance_criteria`
|
||||
|
||||
Это должно стать regression suite после стабилизации.
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
# Как запускать контур
|
||||
|
||||
## Вариант 1 — из VS Code / Codex IDE
|
||||
|
||||
Сформулируйте задачу примерно так:
|
||||
|
||||
> Отрабатываем домен `<domain_name>`.
|
||||
> Используй skill `domain-case-loop`.
|
||||
> Спауни `domain_analyst` и `domain_coder`.
|
||||
> Кейс: `<вопрос пользователя>`.
|
||||
> Сначала собери baseline и JSON, потом дай analyst verdict, потом внеси минимальный domain patch без изменения архитектуры, потом сделай rerun и сохрани before/after.
|
||||
|
||||
## Вариант 2 — из CLI
|
||||
|
||||
Можно дать аналогичный промпт в Codex CLI в корне проекта.
|
||||
|
||||
## Хорошая постановка кейса
|
||||
|
||||
- домен
|
||||
- один конкретный вопрос
|
||||
- желаемый exact result
|
||||
- что в текущем ответе не устраивает
|
||||
- какие ограничения нельзя нарушать
|
||||
|
||||
## Пример
|
||||
|
||||
> Отрабатываем домен `contracts`.
|
||||
> Кейс: "какие есть открытые договора на май 2020".
|
||||
> Цель: exact capability `contracts_with_open_settlements_as_of_date`, дата 31.05.2020, без эвристического shortlist в финальном ответе.
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
# Схема verdict аналитика
|
||||
|
||||
Analyst verdict должен быть длинным, строгим и практически полезным.
|
||||
|
||||
## Обязательные разделы
|
||||
1. Смысл вопроса
|
||||
2. Что реально посчитано
|
||||
3. Где подмена бизнес-смысла
|
||||
4. Где capability/route mismatch
|
||||
5. Evidence quality
|
||||
6. P0
|
||||
7. P1
|
||||
8. P2
|
||||
9. Minimal patch directions
|
||||
10. Acceptance criteria
|
||||
|
||||
## Что считать P0
|
||||
- exact question answered with heuristic output
|
||||
- fabricated or weakly grounded business conclusion
|
||||
- wrong domain object
|
||||
- broken follow-up state that contaminates later turns
|
||||
- output unusable for business user
|
||||
|
||||
## Что считать P1
|
||||
- bad classification
|
||||
- non-business garbage
|
||||
- weak presentation of evidence
|
||||
- missing source refs
|
||||
- route expectation too permissive
|
||||
|
||||
## Что считать P2
|
||||
- cosmetic wording
|
||||
- secondary readability issues
|
||||
- duplicate lines
|
||||
+9
@@ -0,0 +1,9 @@
|
||||
# Куда смотреть сначала
|
||||
|
||||
1. `AGENTS.md` — общие правила проекта и жёсткие запреты.
|
||||
2. `.codex/agents/orchestrator.toml` — координатор цикла.
|
||||
3. `.codex/agents/domain_coder.toml` — кодер домена.
|
||||
4. `.codex/agents/domain_analyst.toml` — аналитик домена.
|
||||
5. `.codex/skills/domain-case-loop/SKILL.md` — пошаговый workflow.
|
||||
6. `ТЗ_НА_РАЗВОРОТ_МУЛЬТИАГЕНТНОГО_КОНТУРА.md` — что Codex должен развернуть в проекте.
|
||||
7. `СОПРОВОДИТЕЛЬНОЕ_ПИСЬМО.md` — текст для передачи Codex.
|
||||
+20
@@ -0,0 +1,20 @@
|
||||
# Содержимое пакета
|
||||
|
||||
Ниже два одинаковых набора файлов:
|
||||
|
||||
1. Основной набор для Codex:
|
||||
- `.codex/config.toml`
|
||||
- `.codex/agents/orchestrator.toml`
|
||||
- `.codex/agents/domain_coder.toml`
|
||||
- `.codex/agents/domain_analyst.toml`
|
||||
- `.codex/skills/domain-case-loop/...`
|
||||
|
||||
2. Дублирующий видимый набор:
|
||||
- `CODEX_VISIBLE/config.toml`
|
||||
- `CODEX_VISIBLE/agents/orchestrator.toml`
|
||||
- `CODEX_VISIBLE/agents/domain_coder.toml`
|
||||
- `CODEX_VISIBLE/agents/domain_analyst.toml`
|
||||
- `CODEX_VISIBLE/skills/domain-case-loop/...`
|
||||
|
||||
Если файлов `.codex/...` не видно в проводнике, используй папку `CODEX_VISIBLE` как читаемое зеркало.
|
||||
После копирования в репозиторий рабочим набором должен остаться именно `.codex/...`.
|
||||
+44
@@ -0,0 +1,44 @@
|
||||
# Сопроводительное письмо для Codex
|
||||
|
||||
Нужно развернуть в текущем репозитории мультиагентный контур для итеративной отработки доменных кейсов 1С/MCP.
|
||||
|
||||
## Цель
|
||||
|
||||
Сделать устойчивый цикл:
|
||||
|
||||
1. Берется доменный кейс.
|
||||
2. Собирается текущий ответ, JSON и технические артефакты.
|
||||
3. Аналитик дает подробный бизнес-разбор и технический verdict.
|
||||
4. Кодер вносит минимальные доменные правки.
|
||||
5. Выполняется rerun.
|
||||
6. Результат сравнивается с предыдущим прогоном.
|
||||
7. Успешный кейс сохраняется как golden case / regression case.
|
||||
|
||||
## Критические ограничения
|
||||
|
||||
- Не менять архитектуру проекта.
|
||||
- Не ломать LLM-first + детерминистский контур.
|
||||
- Не придумывать значения, которых нет в 1С.
|
||||
- Не считать heuristic-ответы продуктовым success-состоянием.
|
||||
- Максимально использовать 1С/MCP и внутреннюю фактическую модель проекта.
|
||||
- Если для точного ответа данных из 1С недостаточно, вернуть честный diagnostic, а не выдуманный результат.
|
||||
- Аналитика должна быть подробной, бизнесовой и строгой.
|
||||
- Для кастомных агентов использовать `gpt-5.4`, без mini-моделей.
|
||||
|
||||
## Что нужно сделать сначала
|
||||
|
||||
1. Прочитать `AGENTS.md`.
|
||||
2. Проверить кастомных агентов в `.codex/agents/`.
|
||||
3. Проверить skill `domain-case-loop`.
|
||||
4. Сопоставить шаблонный пакет с фактической структурой репозитория.
|
||||
5. Расширить или поправить skill/агентов/скрипты, если реальная структура проекта этого требует.
|
||||
6. Подготовить первый тестовый запуск на одном доменном кейсе.
|
||||
|
||||
## Что считается хорошим результатом
|
||||
|
||||
- Один запуск кейса можно инициировать одной командой/одним промптом.
|
||||
- На выходе всегда есть артефакты before/after.
|
||||
- Есть отдельный verdict аналитика.
|
||||
- Есть минимальный patch plan кодера.
|
||||
- Есть rerun.
|
||||
- Есть явные acceptance criteria по кейсу.
|
||||
+173
@@ -0,0 +1,173 @@
|
||||
# ТЗ на разворот мультиагентного контура отработки доменов
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Развернуть в репозитории мультиагентный контур для системной отработки доменных кейсов 1С/MCP без изменения архитектурного ядра проекта.
|
||||
|
||||
Контур должен поддерживать цикл:
|
||||
|
||||
- постановка доменного кейса;
|
||||
- прогон текущей реализации;
|
||||
- сбор ответа, JSON и технических артефактов;
|
||||
- бизнес- и route-анализ;
|
||||
- минимальные доменные правки;
|
||||
- rerun;
|
||||
- сравнение before/after;
|
||||
- сохранение кейса в набор regression/golden cases.
|
||||
|
||||
## 2. Жесткие ограничения
|
||||
|
||||
### 2.1 Архитектура
|
||||
- Не менять архитектурный код проекта.
|
||||
- Не перепридумывать текущую orchestration-концепцию.
|
||||
- Не ломать LLM-first + детерминистскую часть.
|
||||
- Не переписывать общий runtime ради одного домена.
|
||||
|
||||
### 2.2 Доменная работа
|
||||
- Править только доменные и субдоменные сущности, если это требуется для кейса:
|
||||
- intents
|
||||
- capability routing
|
||||
- recipes
|
||||
- exact/confirmed routes
|
||||
- validators
|
||||
- role modeling
|
||||
- evidence / source refs
|
||||
- presentation logic
|
||||
- continuation / context hygiene для доменного поведения
|
||||
- Максимально использовать данные 1С через MCP.
|
||||
- Если 1С-контур не отдает нужную ось, сначала искать точный путь в 1С/MCP, а не заменять это эвристикой.
|
||||
|
||||
### 2.3 Качество ответа
|
||||
- Эвристика не считается финальным продуктовым ответом.
|
||||
- Нельзя высасывать из пальца значения, контрагентов, договоры, суммы, причины.
|
||||
- Если ответ не может быть подтвержден — прямо писать, что именно не подтверждено и чего не хватает.
|
||||
- Математические вычисления вне 1С допустимы только когда они действительно нужны как детерминированный постпроцесс на уже полученных фактах.
|
||||
|
||||
## 3. Состав агентов
|
||||
|
||||
### 3.1 Orchestrator
|
||||
Задачи:
|
||||
- принять кейс;
|
||||
- понять, какой capability / route должен существовать;
|
||||
- запустить кодера и аналитика;
|
||||
- дождаться их результатов;
|
||||
- решить следующий шаг;
|
||||
- выполнить rerun и сверку.
|
||||
|
||||
### 3.2 Domain Coder
|
||||
Задачи:
|
||||
- найти текущую реализацию кейса;
|
||||
- собрать текущие артефакты;
|
||||
- внести минимальные доменные правки;
|
||||
- не трогать архитектурное ядро;
|
||||
- прогнать rerun;
|
||||
- сохранить patch summary.
|
||||
|
||||
### 3.3 Domain Analyst
|
||||
Задачи:
|
||||
- читать ответ, JSON, логи и diff;
|
||||
- не писать продуктовый код;
|
||||
- давать строгий business verdict;
|
||||
- выделять P0/P1/P2;
|
||||
- формулировать acceptance criteria на rerun.
|
||||
|
||||
## 4. Базовый workflow
|
||||
|
||||
1. Пользователь задает доменный кейс.
|
||||
2. Orchestrator создает case folder в `artifacts/domain_runs/<case_id>/`.
|
||||
3. Domain Coder:
|
||||
- собирает baseline;
|
||||
- сохраняет ответ и JSON;
|
||||
- делает краткий patch plan.
|
||||
4. Domain Analyst:
|
||||
- читает baseline;
|
||||
- пишет verdict.
|
||||
5. Orchestrator возвращает verdict кодеру.
|
||||
6. Domain Coder делает минимальные правки.
|
||||
7. Выполняется rerun.
|
||||
8. Domain Analyst сравнивает before/after.
|
||||
9. Orchestrator завершает кейс итоговым статусом:
|
||||
- accepted
|
||||
- partial
|
||||
- blocked
|
||||
- needs exact capability
|
||||
|
||||
## 5. Что именно нужно реализовать в репозитории
|
||||
|
||||
### 5.1 Codex customization
|
||||
- Подключить и адаптировать `AGENTS.md`.
|
||||
- Подключить и адаптировать `.codex/config.toml`.
|
||||
- Подключить кастомных агентов из `.codex/agents/`.
|
||||
- Подключить skill `domain-case-loop`.
|
||||
|
||||
### 5.2 Артефакты кейса
|
||||
На каждый кейс сохранять:
|
||||
- `case_brief.md`
|
||||
- `baseline_output.md`
|
||||
- `baseline_debug.json`
|
||||
- `analyst_verdict.md`
|
||||
- `coder_plan.md`
|
||||
- `patch_summary.md`
|
||||
- `rerun_output.md`
|
||||
- `rerun_debug.json`
|
||||
- `before_after_diff.md`
|
||||
- `final_status.md`
|
||||
|
||||
### 5.3 Формат verdict аналитика
|
||||
Обязательные разделы:
|
||||
- смысл вопроса;
|
||||
- что реально посчитано;
|
||||
- business mismatch;
|
||||
- route mismatch;
|
||||
- evidence quality;
|
||||
- P0 / P1 / P2;
|
||||
- минимальные правки;
|
||||
- acceptance criteria.
|
||||
|
||||
## 6. Что нужно проверить и при необходимости расширить
|
||||
|
||||
Codex должен после загрузки пакета сам проверить:
|
||||
- фактическую структуру репозитория;
|
||||
- где реально лежат routes / recipes / normalizers / schemas / evaluators / runners;
|
||||
- как запускать локальный доменный прогон;
|
||||
- где сохранять артефакты;
|
||||
- нужно ли расширить skill дополнительными reference-файлами;
|
||||
- нужны ли project-specific scripts для baseline/rerun.
|
||||
|
||||
Если структура проекта требует расширения шаблонов — расширить их в рамках этого пакета, но без изменения архитектурного ядра продукта.
|
||||
|
||||
## 7. Режимы успеха
|
||||
|
||||
### Accepted
|
||||
- получен точный или честно подтвержденный ответ;
|
||||
- acceptance criteria выполнены;
|
||||
- regression case сохранен.
|
||||
|
||||
### Partial
|
||||
- найдено улучшение, но exact-result не достигнут;
|
||||
- причина ограничений зафиксирована.
|
||||
|
||||
### Blocked
|
||||
- не хватает доступа, осей данных или исполняемого контура;
|
||||
- проблема локализована.
|
||||
|
||||
### Needs exact capability
|
||||
- текущий heuristic route не годится;
|
||||
- нужен отдельный exact capability.
|
||||
|
||||
## 8. Первая задача после разворота
|
||||
|
||||
Взять один доменный кейс и прогнать контур end-to-end.
|
||||
Рекомендуемый стартовый кейс:
|
||||
- открытые договоры на дату
|
||||
или
|
||||
- дебиторка / кредиторка на дату
|
||||
или
|
||||
- НДС к уплате за период
|
||||
|
||||
Кейс должен дойти до:
|
||||
- baseline
|
||||
- verdict
|
||||
- patch
|
||||
- rerun
|
||||
- final status
|
||||
@@ -0,0 +1,105 @@
|
||||
# Domain Case Loop Repo Adapter
|
||||
|
||||
Документ фиксирует, как шаблонный пакет мультиагентной оркестрации привязывается к реальному репозиторию `NDC_1C`.
|
||||
|
||||
## Что уже есть в проекте
|
||||
|
||||
- Ассистентный runtime с `address_query` и `deep` ветками.
|
||||
- Technical export в UI:
|
||||
- `llm_normalizer/frontend/src/utils/conversationExport.ts`
|
||||
- Async single-case прогон:
|
||||
- `POST /api/eval/run-async/start`
|
||||
- `GET /api/eval/run-async/:job_id`
|
||||
- Session logs:
|
||||
- `llm_normalizer/data/assistant_sessions/*.json`
|
||||
- Autoruns/annotations/post-analysis API:
|
||||
- `llm_normalizer/backend/src/routes/autoRuns.ts`
|
||||
|
||||
## Что добавлено для project-scoped Codex automation
|
||||
|
||||
- root `.codex/`:
|
||||
- `.codex/config.toml`
|
||||
- `.codex/agents/orchestrator.toml`
|
||||
- `.codex/agents/domain_coder.toml`
|
||||
- `.codex/agents/domain_analyst.toml`
|
||||
- `.codex/skills/domain-case-loop/...`
|
||||
- helper script:
|
||||
- `scripts/domain_case_loop.py`
|
||||
- artifact root:
|
||||
- `artifacts/domain_runs/`
|
||||
|
||||
## Почему это лучший путь для текущего репо
|
||||
|
||||
Мы не встраиваем новый orchestration runtime в продуктовый backend.
|
||||
Мы поднимаем отдельный Codex-driven outer loop, который использует уже существующие:
|
||||
|
||||
1. assistant runtime;
|
||||
2. technical debug payload;
|
||||
3. session logs;
|
||||
4. async eval single-case flow.
|
||||
|
||||
Это позволяет автоматизировать текущую ручную схему без architecture drift.
|
||||
|
||||
## Два режима baseline/rerun capture
|
||||
|
||||
### 1. Автоматический run-case
|
||||
|
||||
Использует живой backend:
|
||||
|
||||
```powershell
|
||||
python scripts/domain_case_loop.py run-case `
|
||||
--domain open_contracts `
|
||||
--question "какие есть открытые договора на март 2020" `
|
||||
--analysis-date 2020-03-31 `
|
||||
--expected-capability contracts_with_open_settlements_as_of_date `
|
||||
--expected-result-mode confirmed_balance
|
||||
```
|
||||
|
||||
Что делает:
|
||||
|
||||
1. создает `artifacts/domain_runs/<case_id>/`;
|
||||
2. запускает `assistant_stage1` на одном вопросе;
|
||||
3. ждет completion;
|
||||
4. забирает session/report artifacts;
|
||||
5. сохраняет `baseline_output.md`, `baseline_debug.json`, `baseline_turn.json` и связанные JSON.
|
||||
|
||||
### 2. Импорт уже скопированного техчата
|
||||
|
||||
Подходит для текущего исторического режима, где у пользователя уже есть markdown export:
|
||||
|
||||
```powershell
|
||||
python scripts/domain_case_loop.py import-export `
|
||||
--domain open_contracts `
|
||||
--input "C:\\Users\\DCTOUCH\\Desktop\\акие_есть_открытые_договора_на_март_2020.md"
|
||||
```
|
||||
|
||||
## Канонический JSON для аналитика
|
||||
|
||||
Главный вход аналитика теперь:
|
||||
|
||||
- `baseline_turn.json`
|
||||
- `rerun_turn.json`
|
||||
|
||||
Они содержат:
|
||||
|
||||
1. вопрос;
|
||||
2. ответ;
|
||||
3. `technical_debug_payload`;
|
||||
4. session summary;
|
||||
5. run/session ids;
|
||||
6. report excerpt;
|
||||
7. ссылку на markdown export.
|
||||
|
||||
## Правило завершения цикла
|
||||
|
||||
Кейс считается `accepted`, только если одновременно выполнено:
|
||||
|
||||
1. `quality_score >= 80`;
|
||||
2. нет unresolved `P0`;
|
||||
3. rerun не маскирует heuristic output под confirmed answer.
|
||||
|
||||
Во всех остальных случаях итог должен быть:
|
||||
|
||||
- `partial`
|
||||
- `blocked`
|
||||
- `needs_exact_capability`
|
||||
Reference in New Issue
Block a user