orchestrator/docs/work-items/ORCH-116/08-data-requirements.md

work_item, stage, author_agent, status, created_at, model_used

work_item	stage	author_agent	status	created_at	model_used
ORCH-116	architecture	architect	proposed	2026-06-16	claude-opus-4-8

08 — Требования к данным: ORCH-116 — детерминированный test-раннер

Work Item: ORCH-116 · Repo: orchestrator · Стадия: architecture

1. Изменения схемы БД — НЕТ (NFR-1)

Новых таблиц / колонок / индексов / миграций нет. Раннер использует существующие структуры:

Структура	Использование	Запись?
tasks (stage, branch, work_item_id)	резолв полей задачи по task_id; гард стадии testing в should_intercept; продвижение/откат — через существующий advance_stage (он же пишет стадию под transition-lease ORCH-114)	раннер сам стадию не пишет — только через advance_stage
jobs (status, task_content)	mark_job(done|failed) для строки джоба (через _run_test_runner_job); restart-safe счётчик tool-error DEFER — COUNT(*) по маркеру test-runner infra-retry в task_content re-queued джоба	да (mark_job, enqueue_job — существующие API)
agent_runs	НЕ создаётся — детерминированный раннер не спавнит LLM (happy-path без _spawn)	нет
transition_lease (ORCH-114)	берётся/освобождается внутри advance_stage на side-effectful переходе	раннер не трогает

2. Restart-safe счётчик DEFER — без колонки (зеркало ORCH-115/110)

Бюджет tool-error DEFER (D5) считается из persisted очереди jobs подсчётом маркера test-runner infra-retry в task_content re-queued джоба (зеркало staging_runner._infra_retry_count / stage_engine._merge_infra_retry_count). Это переживает рестарт сервиса без новой колонки/таблицы — намеренно, ради NFR-1 (схема БД байт-в-байт).

3. Артефакт 13-test-report.md — контракт frontmatter неизменен (AC-2)

Раннер пишет тот же файл с тем же machine-key, что читает гейт:

• result: PASS|FAIL (UPPERCASE) — канонический ключ _parse_tests_verdict (src/qg/checks.py:265); имя/регистр/токены не меняются.
• Обязательная 52c-схема: work_item / stage: testing / author_agent: test-runner / status: success|failed / created_at / model_used: n/a.
• Инвариант D6.1 (данные): status: читается тем же парсером (verdict:/status:/result:, negative-token-priority) → значение status: обязано быть выровнено по вердикту (success↔PASS, failed↔FAIL); иначе негативный токен в status: при result: PASS исказит вердикт. Это требование к значению данных, не к схеме.

4. Счётчики наблюдаемости — in-process, не БД

Блок test_runner в GET /queue питается in-process счётчиками _TEST_RUNNER_COUNTERS (runs/pass/fail/tool_error/deferred) — паттерн _STAGING_RUNNER_COUNTERS/ _MERGE_GATE_COUNTERS. В БД не персистятся (обнуляются при рестарте — приемлемо для оперативной наблюдаемости).

5. Вывод

Требований к изменению данных/схемы нет. Совместимость с общей БД (self-hosting + enduro-trails) сохранена: аддитивных объектов не вводится, существующие read/write идут через существующие API.