ДОМЕНЫ - ВОПРОСЫ - ОРРКЕСТРАЦИЯ - БАЗА - Поднять внешний domain-case loop для Codex с baseline/rerun артефактами

2026-04-13 19:37:57 +03:00
parent f64980fa13
commit 8e16bc1f01
59 changed files with 2663 additions and 46 deletions
@@ -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"]
@@ -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"]
@@ -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"]
@@ -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
@@ -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`.
@@ -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
@@ -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
+- ...
@@ -0,0 +1,8 @@
+# Domain constraints
+
+- Архитектуру проекта не менять.
+- Максимально использовать 1С/MCP.
+- Не придумывать значения.
+- Не считать heuristic ответ продуктовым успехом.
+- Математика вне 1С допустима только как детерминированный постпроцесс над уже подтвержденными фактами.
+- Analyst read-only, Coder implementation-focused.
@@ -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
+- ...
@@ -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."
@@ -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/`, но не менять архитектурное ядро продукта.
@@ -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"]
@@ -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"]
@@ -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"]
@@ -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
@@ -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`.
@@ -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
@@ -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
+- ...
@@ -0,0 +1,8 @@
+# Domain constraints
+
+- Архитектуру проекта не менять.
+- Максимально использовать 1С/MCP.
+- Не придумывать значения.
+- Не считать heuristic ответ продуктовым успехом.
+- Математика вне 1С допустима только как детерминированный постпроцесс над уже подтвержденными фактами.
+- Analyst read-only, Coder implementation-focused.
@@ -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
+- ...
@@ -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."
@@ -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 логике и не пишет продуктовый код.
@@ -0,0 +1,14 @@
+# Библиотека кейсов
+
+Для каждого домена поддерживайте набор cases:
+
+- `id`
+- `domain`
+- `raw_question`
+- `expected_business_meaning`
+- `expected_capability`
+- `expected_result_mode`
+- `must_not_happen`
+- `acceptance_criteria`
+
+Это должно стать regression suite после стабилизации.
@@ -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 в финальном ответе.
@@ -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
@@ -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.
@@ -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/...`.
@@ -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 по кейсу.
@@ -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`