Files
orchestrator/docs/work-items/ORCH-115/08-data-requirements.md
claude-bot f120e4bd8f
All checks were successful
CI / test (push) Successful in 1m9s
architect(ET): auto-commit from architect run_id=733
2026-06-16 01:37:27 +03:00

44 lines
2.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
work_item: ORCH-115
stage: architecture
author_agent: architect
status: proposed
created_at: 2026-06-16
model_used: claude-opus-4-8
---
# 08 — Требования к данным: ORCH-115 — детерминированный staging-раннер
Work Item: **ORCH-115** · Repo: **orchestrator** · Стадия: architecture
> When-applicable. Создан **намеренно** при `N/A`-результате: «нет изменений схемы БД» — это
> критический инвариант NFR-1/AC-5, поэтому решение фиксируется явно и аудитопригодно.
## D-1. Схема БД
**Изменений нет.** Ни новых таблиц, ни колонок, ни миграций. Раннер использует существующие
таблицы read/write через существующие хелперы:
- `tasks` — чтение `stage`/`work_item_id`/`branch` по `task_id` (дискриминатор стадии D1,
поля артефакта/гейта); запись стадии — **только внутри `advance_stage`** (его существующий
CAS/lease-контракт ORCH-114, раннер схему не трогает).
- `jobs` — статус джоба ведётся `mark_job(done|failed)` самим раннером (зеркало
`_run_deploy_finalizer_job`); requeue defer — `enqueue_job` свежего `deployer`-джоба
(существующий механизм).
## D-2. Restart-safe состояние без схемы (defer-счётчик D5)
Счётчик infra-defer (ограничение петли tool-error, D5) — **без колонки БД**: подсчёт
маркера-подстроки в `task_content` нового `deployer`-джоба (зеркало
`merge_gate._merge_infra_retry_count` ORCH-110 и `_deploy_finalize_defer_count` ORCH-036).
Сохраняет restart-safe семантику без миграции (NFR-1).
## D-3. Артефакт `15-staging-log.md` (контракт неизменен)
Формат/расположение/machine-key прежние: `docs/work-items/<work_item_id>/15-staging-log.md`,
frontmatter `staging_status: SUCCESS|FAILED` (UPPERCASE) + обязательная 52c-схема. Меняется
лишь *продюсер* (детерминированный код вместо LLM): `author_agent: staging-runner`,
`model_used: n/a`**имя и регистр ключа `staging_status:` не меняются**; читается
неизменённым `_parse_staging_status` (AC-2/AC-5; TC-04).
## D-4. Наблюдаемость — in-process, не БД
Счётчики `staging_runner` (`runs`/`success`/`failed`/`tool_error`/`deferred`) — in-process
(`_STAGING_RUNNER_COUNTERS`, паттерн `_MERGE_GATE_COUNTERS` ORCH-110), отдаются read-only в
`GET /queue`. В БД не персистятся.