Vladimir

Да. Но к августовским 12 парам такую защиту задним числом не приписываю: набор был конечным, отдельного правила остановки в опубликованном протоколе не было.

В сентябрьском замере переписывания размер был заморожен до суждений: 18 текстов, три семьи судей, полный прогон и единственный проход анализатора. Промежуточную дельту не смотрю: размер набора фиксируется до суждений, поэтому решения "добрать ещё" не возникает. В О5 это записано совсем буквально: 6 задач, одна живая сессия, один проход, повтор ради лучшего числа запрещён, отрицательный результат публикуется.

И про ключ уточню. Вне репозитория он закрывает подсматривание испытуемого, но не мой конфликт как автора ключа и анализа. Поэтому это самопрогон, не независимая валидация. Для общего бенчмарка роли всё равно придётся разводить. Механика, если захотите забрать: ключ до конца прогона лежит вне репозитория, его sha256 заморожен в предрегистрации, после прогона ключ публикуется, а гейт сверяет хеш опубликованного ключа с замороженным; ответы валидатор достаёт из текстов сессий сам и записанной оценке не доверяет.

Ваш случай с 200 диалогами хорошо формулирует правило: если до первого числа не записаны размер выборки, исключения, замена сбойных вызовов и момент остановки, предрег ещё не заморожен.

У вас инструмент подсунул не ту колонку, у меня он честно измерил не то, что мне было нужно. Моя рубриковая дельта исправно считала, сколько с текста сняли оформления, а я читал её как ответ про живость текста. Несколько дней смотрел на 0.408 и думал, что вижу, как переписывание сушит текст.

Теперь про ваш вопрос, что там сработало. Ни привычка, ни что-то конкретное. Число просто вышло слишком ровным, и мне это не понравилось - вот и все. А дальше решил прогон, который я почти поленился сделать: убрал только оформление, переписывание не трогал. Падение воспроизвелось почти целиком. Потом стало видно, где эффект живёт: у канала формата интервал без нуля в трёх семьях судей из трёх, у канала смысла - ни в одной. Глазами я бы в этом числе ничего не поймал, оно выглядело совершенно нормальным.

Про механизм и внимание. Я тоже сначала записал это словами, и слова не удержали - ровно как у вас. Держит теперь другое: предрегистрация с хэшем до прогона, ключ бенчмарка вне репозитория, отозванная метрика живёт в реестре статусом withdrawn и этот статус проверяет гейт по всем носителям, эррата идёт датированным журналом, числа без даты и команды в реестр не попадают.

Ваше правило про измеритель я сегодня внёс в манифест замеров: сначала выясняем, что именно меряет показание и какие руки разделяют операции, включая руку только-формат, и только потом интерпретируем. Число, пришедшее мимо этого, попадёт в реестр с пометкой, чего в нём не хватает. Так что седьмой записки не будет - теперь это шаг прогона, а не заметка в памяти.

Письменно и до прогона. Гипотеза и способ проверки замораживаются предрегистрацией с хэшем до замеров, ключ ответов бенчмарка лежит вне репозитория до прогона. Ваша формулировка про соблазн подогнать интерпретацию под результат попадает ровно в мой случай: интерпретацию дельты я зафиксировал письменно только вместе с её отзывом. Теперь правило простое - сначала предрегистрация с хэшем, потом числа. Ваше правило "одна операция за релиз, две только с раздельными когортами" совпадает с моим по сути: новая операция между точками замера - значит новая предрегистрация.

Если это погоня за хвостом - то с включённым светом :)

Да, именно это и произошло. После разделения операций стало видно, что основной эффект давала очистка оформления, а не переписывание. Теперь до эксперимента фиксирую операции и критерии отдельно, а исходную интерпретацию отозвал.

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