# 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:

- по умолчанию helper запускает кейс через `local / qwen2.5-14b-instruct-1m / http://127.0.0.1:1234/v1`;
- для переопределения доступны `--llm-provider`, `--llm-model`, `--llm-base-url`, `--llm-api-key`.

```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`

`needs_exact_capability` здесь означает не "закрыть кейс как чужой", а "доменный запрос валиден для проекта, но текущий контур еще не умеет его отрабатывать точно".

## Политика для новых и неразмеченных доменов

Outer loop должен считать нормальным, что пользователь будет приносить кейсы из доменов, которые еще не размечены в текущем runtime.

Если baseline показывает, что:

1. вопрос лежит внутри целевого project scope;
2. 1С/MCP/данные проекта концептуально относятся к этому домену;
3. ответ не получен из-за отсутствующего intent/route/capability/bootstrap;

то кейс нельзя автоматически считать `out_of_scope`.

Такой кейс должен переходить в режим domain enablement:

- явно зафиксировать, чего не хватает: `intent`, `route`, `capability`, `data access`, `contour bootstrap`;
- сформировать минимальную задачу на прокидывание контура;
- после этого повторно прогонять baseline/rerun уже как продуктовый кейс.