Risk-классификация и capability envelope

1. Классификация риска идёт раньше первого промпта

У многих разработчиков цепочка до этого момента выглядела примерно так: увидели issue, открыли Claude, сформулировали задачу — а о риске подумали уже по ходу. На pet-проекте это ещё переживается; в Commerce OS это уже импровизация с элементами цирка.

Классификация риска нужна не ради бюрократии и не ради красивой таблички в Notion. Она отвечает на очень приземлённый вопрос: какой blast radius будет у ошибки, если Claude сделает лишнее. Правка README.md и правка production-конфига платежей — это совсем разные последствия, а Claude при этом старателен одинаково. Проблема не в старательности, а в том, что старательный ассистент с доступом не туда — это уже маленький производственный инцидент.

Раньше на safety было легко смотреть с хвоста процесса: tests, review, quality gates, merge. С production вопрос сдвигается левее: сначала — что Claude вообще можно поручить, потом закрепить границы в репозитории, не тащить в сессию лишние данные, рискованные шаги гнать в дешёвой среде, и только потом подходить к релизу.

Полезно сразу развести четыре сущности, которые легко перепутать:

Risk classification появляется до prompt и до execution. Это не quality gate перед merge: gate спрашивает «можно ли выпускать результат дальше?», а классификация — «какой режим работы вообще допустим с самого начала?».

Наглядно это выглядит так:

flowchart TD
    A["Новая задача"] --> B["Risk classification"]
    B --> C["Capability envelope"]
    C --> D["Task spec / prompt"]
    D --> E["Работа Claude"]
    E --> F["Checks / review / gate"]

Если совсем по-простому, раньше вы отвечали только на два вопроса: «что делаем?» и «как проверим?». Теперь добавляется третий: «насколько опасно вообще начинать это таким способом?». Именно этот вопрос спасает команды от фразы «ну кто же мог подумать, что правка конфига окажется важнее самой фичи».

2. Shortcut: low-risk, review-required, high-risk

Хорошая новость: в ежедневной работе вам не нужен комитет по философии рисков. Для большинства задач хватает очень грубого, но полезного shortcut, который можно прогнать буквально за пять секунд. Его задача не в академической точности. Его задача — вовремя остановить слишком бодрый старт.

Вот базовая схема:

На первый взгляд правило грубое. И да, специально: оно рассчитано на того, кто решает быстро по задаче из backlog, а не на техлида, пишущего политику на квартал вперёд. Если вам, чтобы классифицировать задачу, нужно полчаса спорить, low-risk это или review-required, значит shortcut уже сработал: показал, что задача не такая уж очевидная.

Очень важно понять последнюю строку: если не уверены, по умолчанию — review-required, не low-risk. Это правило нужно не потому, что мир злой, а потому, что неопределённость сама по себе повышает риск. Когда вы едете в тумане, нормальный водитель не жмёт газ со словами «да, наверное, там прямая».

А вот на этом месте часто спотыкаются: изменение конфигурации тоже обычно review-required, хотя выглядит почти как текст. Конфиги любят ломать не хуже кода — просто делают это молча и с лицом невиновного YAML-файла.

3. Одной метки мало — нужен capability envelope

Одна метка review-required полезна примерно как наклейка «осторожно» на двери: она говорит, что внутри серьёзное, но что именно делать, чего не делать и где огнетушитель — не сказано. Поэтому после risk label нужна следующая вещь — capability envelope, то есть контур разрешённых возможностей для этой конкретной задачи. Самый удобный формат здесь — короткий шаблон, который встаёт и в RISK_CLASSIFICATION.md, и в PR description, и в handoff note:

## Capability envelope

Risk level: review-required
Allowed tools: Read, Edit in `support/**`, run tests
Required approvals: human PR review
Required checks: unit tests, integration tests, lint
Forbidden actions: edits in `payments/**`, `migrations/**`, `.env*`
Rollback expectation: revert PR, regression test remains

Шесть полей, каждое — за своё:

Обратите внимание на полезную деталь: capability envelope не подменяет task spec. Task spec скажет: «исправить сортировку refund-запросов». Envelope скажет: «редактировать только support-часть, в payments не лезть, после изменений — такие-то проверки». То есть одна сущность отвечает за смысл задачи, а другая — за границы поведения.

И ещё один практический момент про меру: low-risk задачам не нужен роман в десяти главах, для них envelope может быть очень коротким. High-risk задачи, наоборот, почти всегда требуют явного запрета на выполнение и режима plan-only. Не надо одинаково подробно оформлять всё подряд, иначе люди перестанут читать документ уже на третьем README fix.

4. Shortcut на задачах Commerce OS

Чтобы не жить в абстракции, давайте прогоним shortcut на знакомых задачах из Commerce OS. На бумаге почти всё выглядит очевидно, но в реальном backlog внезапно выясняется, что «маленькая правка» и «безопасная правка» — далеко не синонимы.

Вот несколько типовых примеров:

Полезнее всего смотреть на пограничные случаи. Допустим, у вас задача: «немного поправить конфиг feature flag». Новичок легко скажет: «это же просто конфиг, почти как текстовый файл». А на практике конфиг может выключить половину checkout-потока, поменять доступы или уронить совместимость. Поэтому в этом shortcut изменения конфигов по умолчанию идут в review-required. Не потому, что все конфиги одинаково страшные, а потому, что shortcut защищает от слишком раннего оптимизма.

Теперь пример из support-потока. Исправление сортировки refund-запросов — это review-required. Здесь не нужно устраивать чрезвычайное положение, но и нельзя писать prompt в стиле «Claude, быстро поправь и заодно почисти всё вокруг». Правильный режим — ограничить область support/**, запретить payments/**, потребовать regression test и diff review. Никакой драмы, просто дисциплина.

А вот rotation production key — уже совсем другой разговор. Здесь Claude полезен как подготовщик материалов: plan, checklist, rollback window, список зависимых сервисов. Но не как исполнитель. И это важная смена интонации. В low-risk вы можете просить «обнови». В review-required — «сначала исследуй и предложи план». В high-risk — «ничего не выполняй, только подготовь материалы». Одно только изменение глагола сильно снижает шанс случайно сделать лишнее.

5. RISK_CLASSIFICATION.md в Workflow Kit

Чтобы классификация не жила только в голове одного аккуратного человека в команде, её нужно превратить в артефакт. В нашем курсе таким артефактом становится RISK_CLASSIFICATION.md из Workflow Kit. Это важная деталь: документ живёт не внутри конкретной фичи Commerce OS, а в мета-слое командного workflow.

Хороший RISK_CLASSIFICATION.md должен быть коротким, жёстким к неопределённости и читаться за минуту. Например, так:

# RISK_CLASSIFICATION.md

## Быстрая классификация
- production / DB / secrets / shared infra / mass deletion -> high-risk
- code / config / dependencies / API contracts -> review-required
- docs / README / small local refactor with tests -> low-risk
- if unsure -> review-required

## Шаблон capability envelope
Уровень риска:
Разрешённые инструменты:
Требуемые одобрения:
Требуемые проверки:
Запрещённые действия:
Ожидаемый откат:

Да, она короткая — и именно поэтому её реально будут читать. А если превратить этот файл в корпоративный роман с тридцатью исключениями, студенты, разработчики и даже сам Claude начнут воспринимать документ как интерьер, а не как инструмент.

Обычно дальше команда делает две полезные вещи. Во-первых, ссылается на этот файл из CLAUDE.md, чтобы у Claude был тот же словарь, что и у людей. Во-вторых, вставляет capability envelope в PR description для review-required и high-risk задач — тогда ревьюер видит не просто diff, а сразу контекст: какой риск, что разрешено, что запрещено, какие проверки обязательны:

## Capability envelope
Risk level: review-required
Allowed tools: Read, Edit in `support/**`, run tests
Required checks: unit + integration tests
Forbidden actions: `payments/**`, `migrations/**`, `.env*`
Rollback expectation: revert PR

Заметьте, как быстро такой блок охлаждает хаос. Разговор в ревью перестаёт звучать как «я вроде поправил, посмотрите» — и начинает звучать как «вот в каких границах велась задача и почему diff выглядит именно так». Для production-команды это очень взрослая разница.

6. Постановка задачи после классификации

Самое практичное последствие сегодняшней темы видно не в документах, а в том, как вы формулируете задачу для Claude: один и тот же issue при разной классификации получает разные стартовые глаголы, разный объём работы и разный уровень свободы. И, честно говоря, это одна из самых полезных привычек всего модуля.

Для low-risk задач формулировка может звучать почти прямолинейно:

Обнови `README.md`: команда запуска изменилась на `./gradlew bootRun`.
Затронь только документацию.
Покажи итоговый diff.

Никакой драмы — быстрая понятная правка без лишнего процесса.

Для review-required тон меняется:

Задача review-required: исправить сортировку refund-запросов в support inbox.
Сначала исследуй affected files и предложи короткий план.
Не меняй `payments/**`, `migrations/**` и `.env*`.
После плана дождись подтверждения.

Обратите внимание, как появляется фраза «сначала исследуй и предложи план». Это и есть применение классификации на практике — не какой-то далёкий policy-файл, а конкретная рабочая интонация.

Для high-risk тон меняется сильнее:

Задача high-risk: подготовить plan для rotation production Stripe key.
Ничего не выполняй и не редактируй.
Подготовь checklist, rollback notes, список зависимостей и рисков.

Здесь Claude превращается из исполнителя в аналитика и редактора артефактов. И это абсолютно нормально: иногда лучший способ использовать AI — не дать ему сделать действие, а дать хорошо подготовить человека к этому действию.

Из этой же логики вырастает ещё одна полезная привычка. Если во время работы вы вдруг понимаете, что low-risk задача задевает API-контракт или требует похода в продовую базу, вы не «дожимаете» старый prompt, а переклассифицируете задачу: меняете capability envelope и только потом продолжаете. Это кажется мелочью, но именно в таких мелочах workflow перестаёт быть красивой схемой на слайде и становится страховкой от самоуверенной глупости.

Но capability envelope живёт на уровне конкретной задачи. Если запрет на payments/** или .env* есть только в одном task spec, он слишком хрупкий: следующая задача сформулируется иначе, и граница растворится. Поэтому envelope для задачи нужен вместе с общим baseline репозитория, где чувствительные зоны закреплены не как пожелание в prompt, а как общая policy.

Когда команда привыкает к этому языку, первый вопрос по новой задаче с участием AI звучит уже не «какой тут prompt написать?», а «какой здесь риск?». И вот с этого момента у вас появляется не просто Claude в проекте, а управляемая система работы с ним.