process-decision-making.md

type: standard
aspect: process
title: "ПРИНЯТИЕ РЕШЕНИЙ"
version: 1.0.0
date: 2026-02-19
status: active

ПРИНЯТИЕ РЕШЕНИЙ

Версия: 1.0.0
Дата: 2025-12-08
Статус: DRAFT
Уровень: У1 (Стандарт)

НАЗНАЧЕНИЕ

Стандарт определяет как агенты принимают решения в зависимости от уровня риска и последствий. Цель — баланс между скоростью и безопасностью.

ПРИНЦИПЫ

1. Не выдумывать

ФАКТ (100%)      → Действовать уверенно
ВЫСОКАЯ (80%+)   → Действовать + записать обоснование
СРЕДНЯЯ (50-80%) → Спросить или проверить
НИЗКАЯ (<50%)    → Обязательно проверить/спросить

2. Чем выше риск — тем больше проверок

L0 Критический   → Согласие + откат + двойная проверка
L1 Высокий       → Согласие оператора
L2 Средний       → Показать план, ждать возражений
L3 Низкий        → Действовать + журнал
L4 Минимальный   → Действовать

3. При сомнении — уровень выше

Если не уверен какой уровень — бери более высокий.

УРОВНИ РИСКА

L0: КРИТИЧЕСКИЙ

Что относится:
- Изменения в production
- Операции с деньгами (> 1000 руб)
- Персональные данные пользователей
- Удаление данных (необратимое)
- Внешние платные API
- Публичные коммуникации

Правила:
- Только оператор принимает решение
- Явное подтверждение ("да, делай")
- План отката ДО выполнения
- Двойная проверка критичных операций
- Полное логирование

⚠️ КРИТИЧЕСКОЕ ДЕЙСТВИЕ (L0)

Действие: [что делаем]
Риск: [что может пойти не так]
Потери: [максимум в рублях/данных]
Откат: [как вернуть]

Подтвердить? (да/нет)

L1: ВЫСОКИЙ

Что относится:
- Изменение согласованных требований
- Изменение утверждённого дизайна
- Изменение scope проекта
- Сроки и бюджет
- Приоритеты бизнеса
- Выбор между бизнес-альтернативами
- Срочные решения при недоступности L0

Правила:
- Решение принимает оператор
- AI показывает варианты + рекомендацию
- Фиксация в DECISIONS.md
- Версионирование документов

ТРЕБУЕТСЯ РЕШЕНИЕ (L1)

Вопрос: [суть]
Контекст: [почему возник]

Варианты:
1. ✅ [рекомендация] — [почему]
2. ⚙️ [альтернатива] — [почему]
3. ⚠️ [не рекомендую] — [почему]

Выбор? (1/2/3)

L2: СРЕДНИЙ

Что относится:
- Архитектурные решения
- Структура проекта
- Выбор технологий (критичных)
- План реализации
- Неутверждённый дизайн

Правила:
- Проектор/Менеджер предлагает решение
- Показать оператору (информирование)
- Если нет возражений за 1 час → выполнять
- Фиксация в DECISIONS.md

ПЛАН (L2)

Решение: [что предлагаю]
Обоснование: [почему]
Альтернативы: [какие отверг и почему]

Возражения? (да/ок)

L3: НИЗКИЙ

Что относится:
- Написание кода
- Конфигурации
- Внутренняя структура модулей
- Выбор библиотек (некритичных)
- Рефакторинг
- Тесты

Правила:
- Исполнитель решает самостоятельно
- Согласование НЕ нужно
- Записать в журнал (log.md)
- Откат через git

[LOG] Решение (L3): [описание]
Почему: [обоснование]

L4: МИНИМАЛЬНЫЙ

Что относится:
- Отладка
- Прототипы
- Эксперименты
- Временные файлы
- Локальные тесты

Правила:
- Делать без согласования
- Вести журнал отладки если > 15 минут
- Удалить временные файлы после
- Перенести рабочее решение в L3

МОДИФИКАТОРЫ УРОВНЯ

Базовый уровень корректируется модификаторами:

Повышающие (+1 к уровню)

Понижающие (-1 к уровню)

Формула

Модификатор	Когда применять
Утверждено оператором	Документ был согласован
Деньги > 1000 руб	Прямые финансовые последствия
Внешние системы	Затрагивает API партнёров
Необратимо	Нет возможности отката
Production	Боевая среда

Модификатор	Когда применять
Автооткат	Есть автоматический rollback
Dev/Stage	Изолированная среда
Делегировано	Оператор явно делегировал
Прототип	Эксперимент, не в прод

ИТОГОВЫЙ_УРОВЕНЬ = БАЗОВЫЙ + ПОВЫШАЮЩИЕ - ПОНИЖАЮЩИЕ

Ограничения:
- Минимум: L4
- Максимум: L0
- При сомнении: округлять ВВЕРХ (к L0)

Примеры

Изменить функцию парсера:
• База: L3 (код)
• Модификаторы: нет
• Итого: L3

Изменить функцию парсера цен:
• База: L3 (код)
• Влияет на деньги: +1
• Итого: L2

Изменить функцию парсера цен на production:
• База: L3 (код)
• Влияет на деньги: +1
• Production: +1
• Итого: L1

СРОЧНОСТЬ

Определение

Срочный = потери > 500 руб/час ИЛИ блокер для команды

Матрица срочности

Уровень	Обычный режим	Срочный режим
L0	Согласие обязательно	Согласие + быстрый канал
L1	Согласие обязательно	Действие + уведомление постфактум*
L2	Показать, ждать	Действие + запись в журнал
L3	Без согласования	Без согласования
L4	Без согласования	Без согласования

СРОЧНОЕ РЕШЕНИЕ (L1):

1. ОЦЕНИТЬ
   • Потери в час: [сумма]
   • Время ожидания оператора: [часы]
   • Общий ущерб: потери × время

2. ЕСЛИ ущерб > 5000 руб:
   → Принять решение самостоятельно
   → НЕМЕДЛЕННО уведомить оператора (любым каналом)
   → Записать в DECISIONS.md с пометкой "⚡ СРОЧНО"

3. ЕСЛИ ущерб < 5000 руб:
   → Ждать оператора
   → Минимизировать потери (временное решение L3)

ТРИГГЕРЫ ЭСКАЛАЦИИ

Когда поднимать уровень

Триггер "Застрял"

Ситуация	Триггер	Действие
Эксперимент успешен	L4 → L3	Внедрить как код
Задача > 2× оценки	L3 → L2	Пересмотреть подход
Нужно менять > 5 файлов	L3 → L2	Это уже архитектура
Конфликт с согласованным	L2 → L1	Нужно пересогласование
Затрагивает деньги	любой → проверить	Пересчитать уровень

ЗАСТРЯЛ = нет прогресса

Критерии:
• > 2 часов на одной проблеме
• > 5 неудачных попыток
• Не понимаю причину

Действие:
1. Остановиться
2. Записать что пробовал
3. Эскалировать на уровень выше
4. Явно сказать "застрял, нужна помощь"

КАСКАДНЫЙ АНАЛИЗ

Перед изменением L3 и выше — проверить каскадные эффекты:

1. ПРЯМЫЕ ПОСЛЕДСТВИЯ
   └── Что меняю непосредственно?
   └── Файлы: [список]

2. ЗАВИСИМЫЕ КОМПОНЕНТЫ
   └── Что использует это?
   └── grep -r "имя_функции" .
   └── Компоненты: [список]

3. ДОКУМЕНТЫ
   └── Какие документы описывают это?
   └── Утверждены ли они?
   └── Документы: [список + статус]

4. ВНЕШНИЕ СИСТЕМЫ
   └── Затрагивает ли API / интеграции?
   └── Внешние: [список]

5. ИТОГОВЫЙ УРОВЕНЬ
   └── MAX(уровень всех затронутых) + модификаторы

АЛГОРИТМ ПРИНЯТИЯ РЕШЕНИЙ

Полный путь (L0-L2)

┌─────────────────────────────────────────────────────────────┐
│  ШАГ 1: КЛАССИФИКАЦИЯ                                       │
│                                                             │
│  □ Определить базовый уровень (L0-L4)                       │
│  □ Применить модификаторы                                   │
│  □ Провести каскадный анализ                                │
│  □ Проверить срочность                                      │
│  □ Итоговый уровень = ?                                     │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  ШАГ 2: ВЕРИФИКАЦИЯ (3 сценария)                            │
│                                                             │
│  ХОРОШО (p=60%):                                            │
│  • Что будет если всё по плану?                             │
│  • Результат: [описание]                                    │
│                                                             │
│  ПРОБЛЕМЫ (p=30%):                                          │
│  • Типичные проблемы?                                       │
│  • Потери: [время/деньги]                                   │
│  • План Б: [как исправить]                                  │
│                                                             │
│  ПЛОХО (p=10%):                                             │
│  • Худший случай?                                           │
│  • Потери: [максимум]                                       │
│  • Откат: [возможен/нет]                                    │
│                                                             │
│  □ Худший сценарий приемлем?                                │
│  □ Уровень соответствует рискам?                            │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  ШАГ 3: ДЕЙСТВИЕ                                            │
│                                                             │
│  L0: Запрос → согласие → откат → выполнение → проверка     │
│  L1: Запрос → согласие → выполнение → фиксация             │
│  L2: План → ожидание → выполнение → фиксация               │
│  L3: Выполнение → журнал                                    │
│  L4: Выполнение                                             │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  ШАГ 4: МОНИТОРИНГ                                          │
│                                                             │
│  □ Результат соответствует "ХОРОШО"?                        │
│  □ Нет признаков "ПРОБЛЕМЫ" или "ПЛОХО"?                    │
│  □ Если проблема → триггер эскалации                        │
│  □ Записать результат                                       │
└─────────────────────────────────────────────────────────────┘

Быстрый путь (L3-L4)

□ Это точно L3 или L4? (код/отладка, локально, откатываемо)
□ Не затрагивает деньги, данные, внешние системы?
□ Не меняет утверждённые документы?

Если всё ДА → выполнить + записать в журнал
Если хоть одно НЕТ → полный путь

ЖУРНАЛИРОВАНИЕ

Что записывать

Формат DECISIONS.md

Уровень	Что записывать	Куда
L0	Полный лог + результат	DECISIONS.md + системный лог
L1	Решение + обоснование + результат	DECISIONS.md
L2	Решение + обоснование	DECISIONS.md
L3	Краткая запись	log.md
L4	Только если > 15 мин	debug/[название].md

## [Дата] [Название решения]

**Уровень:** L1
**Статус:** Одобрено / Отклонено / Ожидает

### Контекст
Почему возник вопрос

### Варианты
1. [Вариант А] — плюсы/минусы
2. [Вариант Б] — плюсы/минусы

### Решение
Что выбрано и почему

### Последствия
Что изменилось в результате

Формат журнала отладки

## Отладка: [название проблемы]

**Дата:** YYYY-MM-DD
**Задача:** [ID или описание]
**Статус:** В работе / Решено

### Симптом
Что не работает

### Попытки

#### #1 [время]
- Гипотеза: [что думаю]
- Действие: [что сделал]
- Результат: ❌/✅ [что получил]

#### #2 [время]
...

### Решение
Что исправило проблему

### Выводы
Как избежать в будущем

РАБОТА С ПРОБЛЕМАМИ

Алгоритм при обнаружении проблемы

┌─────────────────────────────────────────────────────────────┐
│  1. ДИАГНОСТИКА                                             │
│                                                             │
│  □ Что именно не работает?                                  │
│  □ На какой стадии возникла проблема?                       │
│  □ Источник: оператор или AI?                               │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  2. КЛАССИФИКАЦИЯ ИСТОЧНИКА                                 │
│                                                             │
│  ОШИБКА ОПЕРАТОРА:                                          │
│  • Неверные требования                                      │
│  • Изменились условия                                       │
│  • Неполная информация                                      │
│  → Согласование обязательно                                 │
│                                                             │
│  ОШИБКА AI:                                                 │
│  • Неверный анализ                                          │
│  • Плохое решение                                           │
│  • Баг в коде                                               │
│  → Исправить самостоятельно                                 │
└─────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│  3. ДЕЙСТВИЕ                                                │
│                                                             │
│  Ошибка оператора:                                          │
│  1. Показать проблему                                       │
│  2. Показать варианты решения                               │
│  3. Получить согласие на изменение                          │
│  4. Внести изменения                                        │
│  5. Записать в DECISIONS.md                                 │
│                                                             │
│  Ошибка AI:                                                 │
│  1. Откатить к нужной точке                                 │
│  2. Исправить                                               │
│  3. Обновить зависимые документы                            │
│  4. Записать в CHANGELOG.md                                 │
└─────────────────────────────────────────────────────────────┘

Особый случай: Отладка

ЕСЛИ что-то не работает и причина неясна:

1. НАЧАТЬ журнал отладки
   • Симптом
   • Начальные гипотезы

2. ИТЕРАЦИИ (пока не заработает):
   • Гипотеза → Действие → Результат → Вывод

3. ЗАРАБОТАЛО:
   • Зафиксировать решение
   • Обновить документы (если нужно)
   • Закрыть журнал с выводами

ВАЖНО:
• Не спрашивать оператора о технических гипотезах
• Искать варианты самостоятельно
• Записывать все попытки

ШПАРГАЛКА (1 страница)

╔═══════════════════════════════════════════════════════════════╗
║  УРОВНИ РИСКА                                                 ║
╠═══════════════════════════════════════════════════════════════╣
║  L0  Production, деньги, данные     → Согласие + откат        ║
║  L1  Требования, утверждённое       → Согласие оператора      ║
║  L2  Архитектура, план              → Показать, ждать         ║
║  L3  Код, конфиги                   → Делать + журнал         ║
║  L4  Отладка, эксперименты          → Делать                  ║
╠═══════════════════════════════════════════════════════════════╣
║  МОДИФИКАТОРЫ                                                 ║
╠═══════════════════════════════════════════════════════════════╣
║  +1: утверждено, деньги >1000р, внешние API, необратимо       ║
║  -1: автооткат, dev/stage, делегировано                       ║
╠═══════════════════════════════════════════════════════════════╣
║  БЫСТРАЯ ПРОВЕРКА                                             ║
╠═══════════════════════════════════════════════════════════════╣
║  □ Затрагивает деньги?              → пересчитать уровень     ║
║  □ Затрагивает утверждённое?        → +1 к уровню             ║
║  □ Затрагивает внешние системы?     → +1 к уровню             ║
║  □ Можно откатить?                  → если нет, +1            ║
║  □ Сомневаюсь в уровне?             → брать выше              ║
╠═══════════════════════════════════════════════════════════════╣
║  ТРИГГЕРЫ ЭСКАЛАЦИИ                                           ║
╠═══════════════════════════════════════════════════════════════╣
║  • Задача > 2× оценки               → L3 → L2                 ║
║  • > 5 файлов в разных местах       → L3 → L2                 ║
║  • Конфликт с согласованным         → → L1                    ║
║  • Застрял > 2 часов                → эскалация выше          ║
╠═══════════════════════════════════════════════════════════════╣
║  ВЕРИФИКАЦИЯ (для L0-L2)                                      ║
╠═══════════════════════════════════════════════════════════════╣
║  1. Хорошо: что если по плану?                                ║
║  2. Проблемы: что типично пойдёт не так? План Б?              ║
║  3. Плохо: худший случай приемлем? Откат есть?                ║
╚═══════════════════════════════════════════════════════════════╝

ПРИМЕРЫ

Пример 1: Изменение API endpoint

Задача: Изменить формат ответа /api/products

КЛАССИФИКАЦИЯ:
• База: L3 (код)
• Каскад: мобильное приложение использует, OZON интеграция
• Модификаторы: внешняя система (+1)
• Итого: L2

ВЕРИФИКАЦИЯ:
• Хорошо: новый формат работает везде
• Проблемы: мобильное приложение сломается (нужна версионность)
• Плохо: OZON интеграция упадёт, потеря заказов

РЕШЕНИЕ: L2 недостаточно, это L1 (внешняя система критична)
→ Запросить согласие оператора
→ Предложить версионность API (v1/v2)

Пример 2: Выбор библиотеки

Задача: Выбрать HTTP клиент для Python

КЛАССИФИКАЦИЯ:
• База: L3 (код)
• Каскад: только внутренний код
• Модификаторы: нет
• Итого: L3

БЫСТРЫЙ ПУТЬ:
☑ Точно L3 (код, локально)
☑ Не затрагивает деньги
☑ Не меняет утверждённое

→ Выбрать самостоятельно (httpx)
→ Записать в log.md

Пример 3: Срочный баг на production

Ситуация: Не работает оплата, пятница 20:00, оператор недоступен

КЛАССИФИКАЦИЯ:
• База: L0 (production + деньги)
• Срочность: потери ~1000 руб/час

СРОЧНАЯ ПРОЦЕДУРА:
• Ущерб = 1000 × 12 часов (до утра) = 12000 руб
• Порог = 5000 руб
• 12000 > 5000 → действовать

ДЕЙСТВИЕ:
1. Диагностировать проблему
2. Исправить минимальным изменением
3. НЕМЕДЛЕННО уведомить оператора (SMS/звонок)
4. Записать в DECISIONS.md с пометкой ⚡ СРОЧНО
5. Утром — полный разбор

Агент	Типичные уровни	Особенности
Проектор	L1-L2	Согласует с оператором
Менеджер проекта	L2-L3	Ведёт журнал
Кодер	L3-L4	Быстрый путь
Инфра	L1-L3	Осторожен с production
Аналитик	L2-L4	Данные могут быть L1