av
bf6a173115
- DECISIONS.md (4040 строк, 65 тем) → decisions/, файл на тему плюс указатель; - буквенные метки решений заменены сквозными Р1–Р234, следствия получили префикс С при прежних номерах: схема букв выродилась до пятибуквенных и сломалась — `АЕАКЛ` была занята и темой 53, и темой 65; - 42 перекрёстные ссылки переписаны под новые номера и стали живыми; где номер означал тему, а слово стояло «решение», формулировка исправлена.
5.1 KiB
14. Умолчания режимов прогона перевёрнуты (2026-08-03)
Что было
Оба скилла держали одно и то же умолчание — «по очереди», — хотя цена очереди у
них разная. review-pipeline гнал проходы последовательно и требовал для
параллельности двух условий (явная просьба и поимённо названный набор).
task-batch, наоборот, планировал волны параллельных задач с потолком 2–3 и
считал параллельность нормой прогона.
Перепутаны оказались уровни. Проход ревью — чтение и рассуждение: он ничего не поднимает, ни за что не дерётся и по построению не видит выводов соседа. Задача батча — полный цикл пайплайна: гейт, поднятие сервиса вживую, вложенное ревью, общие порты и рабочие каталоги. Дешёвое стояло в очереди, дорогое гонялось разом.
Решено
Р47. В ревью умолчание — параллельно. Стадии по-прежнему идут по порядку, параллельность касается только проходов внутри стадии. Последовательно гоняем по трём особым причинам, и каждая называется в отчёте: сказал оператор; проходы меряют; машина занята — причём занятость видит вызывающий, а не конвейер. Просьба «гони последовательно» набора не требует: очередь ничего не портит, она только дольше, и домысливать тут нечего — в отличие от прежнего правила, где неназванный набор блокировал отступление.
Р48. Меряющая пара — правило стадии, а не решение прогона. adversary и
ops идут по очереди всегда: оба доказывают находки числами и оба меряют одно
железо, а испорченный оракул хуже отсутствующего. Общее «гони параллельно» этого
не отменяет; отменяет только прямое слово оператора про эту пару, и тогда в
границы покрытия идёт строка про замеры под соседней нагрузкой.
Р49. В батче умолчание — по одной задаче, параллельность — по графу зависимостей. План собирается как граф (рёбра — жёсткие зависимости и сериализуемые пересечения) и в умолчании линеаризуется в один порядок. Просьба «гони параллельно» разрешает использовать ширину графа, а не гнать всё разом: потолок 2–3, замеряющая задача — волной по одной. Прежние правила волн сохранены целиком, они просто перестали быть умолчанием.
Что из этого следует
С56. Режим батча задаёт режим ревью внутри задачи, и его называет charter. Батч идёт по одной — машина свободна, сабагент гонит проходы параллельно; батч идёт волнами — сабагенту предписан последовательный режим с этой самой причиной. Сабагент своего соседа не видит, поэтому решать это ему нельзя.
С57. Ранний выход из ревью переехал на границу стадии. Стадии идут по порядку в любом режиме, так что остановиться между ними можно всегда; остановка внутри стадии осталась побочной выгодой последовательного режима — но не поводом его выбирать.
С58. Цена параллельного батча проверяется до первой волны. Тесты, делящие фиксированный порт или файл БД, и проект, умеющий поднимать один экземпляр, — основание гнать по одной даже после просьбы, сказанное строкой: просьба была про параллельность, а не про сломанные тесты.