37 lines
4.6 KiB
Markdown
37 lines
4.6 KiB
Markdown
---
|
||
work_item: ORCH-091
|
||
stage: architecture
|
||
author_agent: architect
|
||
status: accepted
|
||
created_at: 2026-06-09
|
||
model_used: claude-opus-4-8
|
||
---
|
||
|
||
# 10 — Технические риски: ORCH-091 — Карточка трекера (статусы, откаты, метрики)
|
||
|
||
Work Item: **ORCH-091** · Repo: **orchestrator** · Стадия: architecture
|
||
|
||
> Информационный (гейтом не парсится). Перечисляет риски реализации и их митигейшн.
|
||
|
||
## Реестр рисков
|
||
|
||
| ID | Риск | Вер. | Влия. | Митигейшн |
|
||
|----|------|------|-------|-----------|
|
||
| TR-1 | Регресс существующих меток/строк при правке цикла рендера (In Review, Awaiting Deploy, Done, эффорт-суффикс, формат строк/тоталов) | Сред. | Сред. | `is_active_stage` не трогаем; нормализация только в гейте подавления (D2); формат `_stage_line` байт-в-байт; зелёные `tests/test_tracker_*` + `test_telegram_tracker` (AC-6). |
|
||
| TR-2 | Рассинхрон карты статусов с `STAGE_TRANSITIONS` в будущем (новая стадия без лейбла) | Сред. | Низ. | Полнота — тест по `STAGE_TRANSITIONS.keys()` (NFR-3); нейтральный фолбэк вместо «To Analyse» (D1) → даже без лейбла не «лжёт». |
|
||
| TR-3 | Неверная точка отсчёта позиции стадии → неверное снятие/сохранение `✅` (особенно схлопывание `deploy-staging`/`deploy` в строку «Внедрение») | Сред. | Сред. | Позиция из порядка `STAGE_TRANSITIONS`; нормализация `deploy-staging→deploy` только для current-pos (D2); сценарные тесты отката `deploy-staging→development` и `review→development` (AC-4). |
|
||
| TR-4 | Расхождение метрик строки стадии с тоталами задачи (двойной/потерянный учёт) | Низ. | Сред. | Строка и тоталы используют ОДНИ формулы (`_input_total`/`_duration_seconds`/`cost_usd`) над ОДНИМ множеством `agent_runs`; тест сходимости Σ(строки) == `SUM(agent_runs)` по `task_id` (AC-5). |
|
||
| TR-5 | Исключение в `render_task_tracker`/`plane_status_label` блокирует индикацию | Низ. | Сред. | Контракт never-raise сохранён; `_pipeline_pos` never-raise (unknown → «далёкое будущее» = старое поведение); деградация к безопасному выводу (NFR-1/AC-3,7). |
|
||
| TR-6 | Новая import-связь `notifications.py → stages` вводит цикл импорта | Низ. | Низ. | `stages.py` — лист без обратных зависимостей на `notifications`; импорт ключей словаря, не функций; `stages.py` не изменяется (ТЗ §2). |
|
||
| TR-7 | Фикстура AC-4 без in-flight developer-прогона → строка «Разработка» не `🔄` | Низ. | Низ. | ADR D2 фиксирует: пост-откатный `🔄` требует строки `agent_runs` c `finished_at IS NULL`; тест-план обязан включать такой прогон (реальное прод-состояние после relaunch). |
|
||
|
||
## Сводный вывод
|
||
|
||
Доминирующий класс — **риски регресса индикативного слоя** (TR-1/TR-3) и **сходимости метрик**
|
||
(TR-4). Все смягчаются тестами и минимальной поверхностью правок (один модуль, без затрагивания
|
||
`STAGE_TRANSITIONS`/`QG_CHECKS`/схемы БД/транспорта). Эскалация `arch:major-change` **не нужна**:
|
||
изменение локально, обратимо `git revert`, never-raise, kill-switch не требуется. Возврат в анализ
|
||
**не требуется** — BRD/ТЗ полны и реализуемы без нарушения принципов. Остаточный риск для
|
||
прод-конвейера (self-hosting) — **низкий**: слой чисто индикативный, управляющий конвейер
|
||
(стадии/гейты/очередь) не затрагивается, рендер деградирует безопасно.
|