Прогоните план через три ревью и сведите вердикт

Шаг 0. Профиль ревьюируемого артефакта

До первого этапа ответь на четыре вопроса, ответы — в шапку отчёта:

1. Что ревьюим — идея на абзац / план фичи / архитектурный документ / диф или PR / работающий интерфейс.
2. Что меняется наружу — экраны, тексты, публичные API, ничего.
3. Какие деньги и данные затрагиваются — расчёт цены, списания, ПДн, остатки, ничего из этого.
4. Есть ли снапшот — редакция плана, на которую сошлются все этапы.

Четвёртый пункт не формальность: этапы, посмотревшие разные редакции, дадут вердикты, которые нельзя сложить. Фиксируй текст плана до старта.

Шаг 0.1. Какие этапы нужны

Полный прогон не всегда оправдан. Решай по таблице:

Дизайн-этап нужен, если план меняет экран внешнего пользователя, текст в интерфейсе, поток оплаты или согласие на обработку ПДн. Диф целиком в *.py, *.sql, CI и миграциях — пропуск.

Инженерный этап нужен всегда, когда есть код или схема данных; пропуск — только для идеи без плана реализации.

CEO-этап «лайт» — три вопроса из шести: кто клиент, какую проблему решаем, как узнаем, что сработало; полный — все шесть плюс выбор режима масштаба.

Пропуск обязан быть записан: «Дизайн-ревью: пропущено — изменения не выходят за бэкенд». Читатель отличает «проверили» от «не смотрели» только по этой строке.

Шаг 0.2. Инлайн или делегирование

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

Реально существующие параметры: agent_type (explore | execute | verify), tasks (1–5), wait. Никакого max_iterations нет — бюджет задан ролью.

Бюджеты ролей (актуально на 2026-07-28, задаются конфигом платформы)

Следствие: этапы запускай как explore. Запущенный как verify этап не загрузит навык-ревьюер и выдаст импровизацию — тот же пересказ, чужими руками. verify годится лишь на сверку чисел в отчёте.

Стоимость полного прогона против выборочного

Три этапа в бюджетах explore = до 240 tool calls и 300 тыс. токенов; выборочный прогон по Шагу 0.1 обычно снимает этап целиком — треть. Платформа держит 3 одновременных LLM-вызова: три параллельных этапа по стене идут как один самый долгий. Правило: нужны все три и надо читать код — делегируй одним вызовом с wait=true; нужен один — не делегируй вовсе.

Шаг 0.3. Как не потерять контекст между этапами

• Текст плана клади в context задачи (лимит 16 000 знаков), task_instruction держи коротким (лимит 4000). План длиннее — стадируй артефактом (save_artifact в repl_execute) и ссылайся на его имя.
• Возврат идёт двумя каналами: summary инлайн обрезается на ~1200 знаках и full_output_path с полным выводом. Таблицу из 10 дизайн-измерений в 1200 знаков не уложить — читай full_output_path для каждого этапа с вердиктом хуже «Готов», иначе половина проблем исчезнет по дороге.
• Подагент делегировать дальше не может (глубина — 1): трёхуровневых схем не проектируй.

Карточка плана

Едет во все этапы дословно, чтобы они не разошлись по редакциям:

Шаг 0.4. Порядок этапов: параллельно или последовательно

По умолчанию этапы независимы и идут параллельно: они читают один снапшот и не нуждаются в выводах друг друга.

Последовательность обязательна ровно в одном случае — когда CEO-этап меняет сам предмет ревью: вердикт «Нужна переработка» или режим «СОКРАЩЕНИЕ», после которого из плана уходит 30% пунктов и больше. Тогда дизайн и инженерка ревьюят урезанный план, иначе половина их замечаний адресована функциональности, которой не будет. Отсюда протокол: CEO первым инлайном (он дешёвый — текст против текста), посмотри вердикт, потом одним вызовом run_subagent гони дизайн и инженерку параллельно против выжившей редакции.

Шаг 0.5. Досрочная остановка

Останавливай пайплайн при любом из условий:

1. CEO не может назвать клиента. Ответ — категория («малый бизнес»), а не конкретный человек: план перепишут целиком, дизайн-ревью такого плана — выброшенный бюджет.
2. Нечего ревьюить. Нет ни списка изменений, ни описания экранов, ни схемы данных — верни список недостающего.
3. Снапшота нет, план правится по ходу. Вердикты по движущейся цели нельзя свести.
4. Первый этап нашёл блокер с приоритетом ≥12 (формула ниже): утечка ПДн, потеря денег, нарушение договора с площадкой. Остальные этапы не изменят «переработать».

Остановка ≠ молчание: дай по оставшимся этапам 3–5 строк «на что смотреть, когда план вернётся» по заголовкам измерений навыка, и напиши, что этап не выполнялся.

Независимость этапов означает, что дизайнер не смягчает оценку из-за одобрения CEO. Она не значит, что этапы обязаны отработать по плану, который решено переписать.

Нормализация вердиктов

Этапы говорят на трёх языках. Сведи их к шкале 0/1/2:

Две поправки, без которых нормализация врёт:

• Проблема с приоритетом «Критический» обнуляет этап независимо от среднего балла: дизайн со средним 8.4 и одним нечитаемым на мобильном шагом оплаты — это 0, потому что среднее прячет провал в одном измерении за девятью хорошими.
• Этап, неприменимый по Шагу 0.1, в свёртку не входит: он не 0 и не 2, его нет.

Свёртка: минимум, а не среднее

Ревью — конъюнкция, а не средневзвешенное. Пример: CEO=2, Дизайн=2, Инженерка=0 (нашли передачу токена площадки в query-строке). Среднее даёт 1.33 → «нужна доработка», план едет в спринт с пометкой «почти готово». Минимум даёт 0 → «требует переработки», утечка чинится до релиза. Разница между формулами — разница между инцидентом и его отсутствием.

Итог словами: 2 — Готов к реализации, 1 — Нужна доработка, 0 — Требует переработки.

Приоритет сквозного списка проблем

Формула

Каждой проблеме из любого этапа считай P = И × Р × Н:

• И — влияние: 3 — блокирует использование или теряет деньги/данные; 2 — заметно ухудшает результат; 1 — косметика.
• Р — радиус: 3 — все пользователи или все данные; 2 — сегмент (площадка, тариф, тип клиента); 1 — единичный сценарий.
• Н — необратимость: 2 — после релиза чинится миграцией данных, сменой публичного контракта или разговором с клиентом; 1 — правится деплоем.

Пороги: P ≥ 12 — блокер, релиз не выходит; 6–11 — чинить до релиза; 3–5 — следующий спринт; ≤2 — бэклог.

Поправка на согласие. Проблема, независимо поднятая двумя этапами и более, получает И + 1 (потолок 3): совпадение перспектив — сигнал сильнее, чем уверенность одной.

Дедупликация

Одна проблема, увиденная с двух сторон, — один пункт: дизайн пишет «нет пустого состояния для списка заказов», инженерка — «не обработан пустой ответ Ozon API при нулевых заказах», это один дефект на двух слоях. В отчёт идёт формулировка этапа с бо́льшим P, в скобках оба источника — [Диз+Инж]. Не сливай проблемы, у которых совпадает экран, но различается причина.

Квота. В отчёт идут топ-5 по P плюс все блокеры; остальное — приложением. Список из тридцати замечаний не читают.

Конфликты между перспективами

Конфликт — не сбой пайплайна, а его продукт. Разреши его по каталогу ниже или оставь открытым, назвав цену вариантов.

Конфликт A: «расширить» против «слишком большой диф»

CEO требует амбиции, инженерка ставит красный флаг на >8 файлов и >2 новых сервиса. Правило: амбиция цели и размер первой поставки — разные величины. Расширяй цель, режь релиз.

Разбор. План: синхронизация остатков с 1С для Ozon. CEO в режиме РАСШИРЕНИЕ: клиент торгует на трёх площадках, добавить WB и Яндекс Маркет. Инженерка: три клиента API с разной пагинацией и лимитами, 14 файлов, 3 сервиса — красный флаг по обоим порогам. Разрешение: цель — три площадки, релиз 1 — Ozon плюс адаптер, чей интерфейс с первого дня рассчитан на три реализации: 6 файлов, 1 сервис. В отчёт: «цель — 3 площадки (CEO), релиз 1 — 6 файлов (инженерка)».

Конфликт B: покрытие тестами против срока

Разбор. 11 непокрытых веток, закрыть все — 5 дней. По правилу: 3 ветки в расчёте цены со скидкой площадки и 1 в списании остатка закрываем за 1.5 дня, остальные 7 в экспорте XLSX получают ★★ и ждут спринта. Срок соблюдён, риск денег закрыт.

Конфликт C: дизайн просит оптимистичный UI, инженерка запрещает

Правило: спрашивай, кто владеет истиной. Оптимистичное обновление разрешено, где операция идемпотентна и обратима локально (пометить прочитанным, добавить тег, сменить сортировку). Запрещено, где единственный источник истины — ответ внешней системы: цена на площадке, остаток, статус отгрузки, результат платежа; там вместо оптимизма — явный прогресс и блокировка повторной отправки.

Разбор. Дизайн: «после „Обновить цену" карточка сразу показывает новую цену». Инженерка: «площадка применяет цену асинхронно и может отклонить её — пользователь увидит цену, которой нет». Разрешение: новое значение со статусом «отправлено, ожидает подтверждения площадки» и временем последней сверки — мгновенная обратная связь без вранья на экране.

Конфликт E: молчаливый — этапы не спорят, потому что смотрели разное

Самый опасный: выглядит как согласие. Признаки — этапы цитируют формулировки, которых нет в снапшоте; ссылаются на пункты с разной нумерацией; один обсуждает экран, которого другой не видел; оценка объёма у CEO и инженерки различается вдвое. Правило: ничего не сводить, зафиксировать снапшот заново, перезапустить разошедшиеся этапы. Отчёт по разным редакциям хуже его отсутствия — он выглядит достоверным.

Правило по умолчанию, когда готового нет

Приоритет у стороны, чья ошибка необратима: деньги, ПДн, юридические обязательства и публичные контракты перевешивают удобство, скорость и красоту. Необратимости нет ни у кого — бери вариант, который позволяет узнать ответ дешевле (флаг, канарейка, один сегмент клиентов).

Неразрешённый конфликт не замалчивается

Он идёт в отчёт строкой: суть, позиция каждого этапа, варианты A/B, цена каждого в днях или рублях, кто решает. Вычеркнутый ради красивого отчёта конфликт вернётся на реализации, дороже.

Шаблон сводного отчёта

Проблемы с P 3–11, не попавшие в топ, ставь задачами через manage_task: иначе следующее ревью найдёт их заново.

Российский контекст: где пороги другие

• Маркетплейсы (Ozon, Wildberries, Яндекс Маркет). План, где цена или остаток уезжает на площадку, получает Н=2 автоматически: неверная цена на карточке — проданный товар по неверной цене, деплоем не чинится. Инженерный этап проверяет пагинацию и поведение при лимитах API площадки, дизайн — что интерфейс показывает время последней успешной синхронизации, а не молча старые данные.
• Учётные системы (1С, МойСклад). Обмен асинхронный: дизайн, нарисовавший мгновенный результат, конфликтует с реальностью — правило конфликта C.
• Персональные данные. Новое поле с ПДн или передача их третьей стороне получает И=3 и Н=2 автоматически, а CEO-этап отвечает на «почему сейчас» ещё и в смысле правовых оснований. Номера статей закона не выдумывай — поставь открытый вопрос для юриста.
• Оплата, эквайринг, Битрикс24. Экран оплаты не бывает «пропустить дизайн-ревью» — всегда полный этап. Двусторонняя синхронизация с CRM — типовой конфликт A: назначь одну систему владельцем каждого поля, это дешевле любой стратегии слияния.

Режимы отказа самого пайплайна