architect(ET): auto-commit from architect run_id=739

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

@@ -0,0 +1,54 @@
+---
+work_item: ORCH-116
+stage: architecture
+author_agent: architect
+status: proposed
+created_at: 2026-06-16
+model_used: 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.