steelmorgan/escalation-format

Формат эскалации пользователю

Этот навык задаёт формат сообщения эскалации. Фильтр «когда эскалировать» — отдельный: он в framework/workflows/orchestrator/SKILL.md § 4 «Принцип „делегируй, не спрашивай“». Перед применением формата ОБЯЗАТЕЛЬНО пройти этот фильтр и убедиться, что эскалация легитимна (admin-операция / изменение контракта L1-L2 / бизнес-выбор / 3+ BLOCK / scope-расширение). Технические выборы и диагностика эскалации НЕ требуют — они решаются делегированием сабагенту. Применять формат ниже к техническому вопросу = ошибка.

Hard

• На каждую эскалируемую проблему — обязательная структура:

  1. Что: одно предложение, описывающее саму проблему.
  2. Почему это проблема: краткое пояснение причин — что именно не работает / нарушается / противоречит. Включи конкретные ссылки file:line или REQ-ID, чтобы пользователь мог проверить.
  3. Варианты решения: перечисли реалистичные опции (минимум 2), пронумеруй (A, B, C...).
  4. Оценка каждого варианта: для каждого — плюсы / минусы / влияние на затронутые артефакты (спека, дизайн, тесты, код), включая затраты на правку и риски.
  5. Рекомендация: если есть — укажи свой выбор и обоснование. Если выбор не очевиден — явно скажи «выбор за пользователем».

• Запрещено эскалировать «один вопрос без контекста». Если пользователь не понимает, какие проблемы за вопросом стоят, — он не может выбрать.

• Запрещено прятать варианты в одну фразу типа «принимаем или меняем спеку». Каждый вариант должен быть развернут — что меняется, где, какой ценой.

• Группировка: если эскалируется несколько связанных проблем — оформляй каждую отдельным блоком с заголовком; не сваливай всё в один абзац.

Soft

• Используй markdown-таблицы для сравнения вариантов, если их 3+.
• Старайся ограничить ответ 1-2 экранами; если проблем много — выдели Top-3 критичных и приложи остальные ниже.
• Если в проблеме есть бизнес-смысл (UX, нагрузка, безопасность) — обязательно отрази его в оценке вариантов, не только техническую сторону.

Пример (хороший)

Проблема 1 — REQ-X противоречит REQ-Y

Что: REQ-X требует поведение A, REQ-Y требует не-A.

Почему это проблема: при попытке тестирования (spec.md:142) UT-X-01 ожидает поведение A, а UT-Y-02 — не-A. Developer-Code не сможет одновременно выполнить оба теста. Это нарушение source-of-truth-policy уровень L2.

Варианты:

• A. Удалить REQ-Y. Плюсы: спека становится последовательной, минимум переделок. Минусы: теряется бизнес-кейс «не-A».
• B. Переписать REQ-X в SHOULD. Плюсы: оба требования сосуществуют. Минусы: контракт A становится опциональным — Developer-Code может его обойти.
• C. Разделить контекст: A применяется в кейсе K1, не-A — в K2. Плюсы: оба бизнес-кейса сохраняются. Минусы: правка спеки + новый ADR + правка дизайна (3-5 мест) + 2 новых unit-теста.

Рекомендация: C — единственный вариант, сохраняющий оба бизнес-смысла. Затраты на правку приемлемы.

Пример (плохой)

«У нас в спеке противоречие. Поправить или оставить?»

— Без пояснения причин, без вариантов, без оценки. Запрещено.

depends_on:

• framework/workflows/orchestrator/SKILL.md