E-01 · Этап 6: план ревизии#
Подготовлен: 2026-09-16 · исполнен: 2026-09-16 · на входе — 18 находок из 99-findings.md
Решения по Б1–Б5 приняты:
D-02разделён сразу ·D-06про деградацию отложен, чтобы не расширять комбинаторику проверяемого · одна собранная версия на документ · реестр ограничений перенесён вdecisions/· дальше E-02.Исполнение разошлось с планом в одном месте: правок оказалось четырнадцать, а не одиннадцать. Находки 2, 12 и 13 не попали в раздел A, хотя развилок не содержат — список составлялся по памяти и потерял три позиции из восемнадцати.
Прогон закончен по существу. Осталось превратить находки в правки. План разделён на то, что исполняется без обсуждения, и то, где выбор не мой.
A. Делаю сам — правки следуют из находок однозначно#
Одиннадцать находок из восемнадцати не содержат развилки: они называют ошибку и способ её исправить. Здесь нечего решать, только сделать.
| Находка | Правка | Документ |
|---|---|---|
| 1, 15 | Три степени достоверности факта вместо двух: [замер] — измерено на нашем профиле · [расчёт] — выведено арифметически из известных величин · [нет данных]. Правило: расчёт разрешает принять решение, но обязывает записать, какой замер его подтвердит |
00-template.md |
| 3 | [нет данных] блокирует решение только в оси, которая различает оставшиеся варианты. Пустая ячейка в оси, где все кандидаты одинаковы, безвредна |
00-template.md |
| 8 | Что делать, когда дисквалификация оставила один вариант: матрица не заполняется, вместо неё строка «дисквалификаторы сделали всю работу» с перечнем сработавших | 00-template.md |
| 18 | Разделить короткую форму и короткую запись: это независимые вещи. Убрать ложный сигнал «запись разрослась → проверьте форму» | 00-template.md, 01-adr-template.md |
| 5 | Строка «чего это решение не решает» — в шапку документа решения | D-01, 00-template.md |
| 4 | Порог выноса в реестр ограничений: не «больше десятка», а три-четыре записи — по факту прогона | D-01 |
| 9 | Отличать разрез по профилю нагрузки от решения о кэше: у пути чтения нет своего языка, инвариантов и владельца данных | D-02 |
| 10 | Поле «самая дорогая будущая граница» — в раздел записи в ADR | D-02, 01-adr-template.md |
| 11 | Условие применимости: процесс пересекает границу, за которой нет общей транзакции — своя она или чужая, неважно | D-04 |
| 14 | Как делить процесс перед применением: единица решения — участок между границами, а не продуктовый сценарий | D-04 |
| 16 | Строка «инвалидация против короткого TTL» в таблицу отклонений — главная развилка читающего кэша | D-03 |
| 15 | Снять противоречие: дисквалификатор «узкое место не подтверждено замером» против эвристики «нет данных — не повод откладывать». После правки 1 противоречие снимается само: расчёт — достаточное основание, догадка — нет | D-03 |
Плюс хозяйственное: в constraints.md продублировалась фраза при правке — уберу.
B. Решаешь ты — пять развилок#
Б1. Разделять ли D-02 сейчас или после E-02#
Позиция про стадии принята, и D-02 — первый кандидат на разделение: на гринфилде у него нет источника фактов. Но разделяющий признак проверен ровно на одном случае.
| Вариант | За | Против |
|---|---|---|
| Разделить сейчас | Находка 7 самая крупная, тянуть её через E-02 — значит проходить E-02 по заведомо неверному документу | Признак разделения проверен на одном случае; можем начать делить не по той линии |
| Отложить до E-02 | Второй кейс даст второй пример и подтвердит или опровергнет признак | E-02 пройдёт по документу, про который уже известно, что он неверен для гринфилда |
Моя рекомендация: разделить сейчас. Проходить E-02 по документу с известной ошибкой — это тратить второй кейс на подтверждение того, что уже подтверждено.
Б2. Заводить ли документ про деградацию и поведение при отказе#
Номер
D-05при исполнении ушёл к «Границам на старте» (развилка Б1). Решение про деградацию, когда дойдёт очередь, получитD-06.
Находка 17: дисквалификатор D-03 требует спроектированной деградации, а документа под это нет. Решение продуктовое, необратимое, уровня W7 — то есть полноценное, не строка в чужом ADR.
Это расширение набора, против которого я сам возражал два этапа назад. Разница в том, что здесь его потребовал не мой список пробелов, а сработавший дисквалификатор в живом прогоне.
Моя рекомендация: завести, но после правок по разделу A — иначе он родится по старому шаблону и его придётся править следом.
Б3. Сколько версий выпускать#
Половина находок тянет на MAJOR. Два способа:
| Вариант | Как выглядит история версий |
|---|---|
| Одна собранная версия на документ | D-03 v2.0 с одной записью: «по итогам прогона E-01: исправлено противоречие, добавлена развилка инвалидации» |
| Версия на находку | D-03 v2.0, v3.0 — по записи на правку |
Моя рекомендация: одна собранная. Правила версионирования требуют, чтобы запись отвечала на вопрос «что перепроверить в старых ADR»; для всех этих правок ответ один и тот же — «перепроверить по итогам прогона E-01». Дробить его на пять записей значит сделать историю длиннее, а не полезнее.
Б4. Переносить ли форму реестра ограничений в decisions/#
Реестр набрал десять записей за четыре ADR и оказался полезнее, чем я ожидал — половина записей это «не используем, потому что», которые иначе всплывали бы заново. Сейчас форма живёт внутри примера.
| Вариант | Следствие |
|---|---|
Перенести как decisions/03-constraints-registry.md |
Форма становится частью метода, версионируется, проверяется скриптом |
| Оставить в примере | Метод остаётся тоньше; каждая команда придумывает форму сама |
Моя рекомендация: перенести. Реестр — единственный артефакт прогона, который понадобился на каждом этапе без исключения.
Б5. Что дальше после этапа 6#
| Вариант | Что проверит |
|---|---|
| E-02 «Лента новостей» | Противоположный угол: большой объём, итоговая согласованность, нет дефицитного ресурса. Проверит правки на непохожем кейсе |
D-05 и другие недостающие решения |
Ширина набора: авторизация, ключ шардирования, контракт API |
| Третья стадия — «система под изменением» | Целый пласт, которого нет: миграция, совместимость, окно перехода |
Моя рекомендация: E-02. Правки раздела A сделаны по одному кейсу; пока они не проверены на втором, набор новых документов будет расти на непроверенном основании.
C. Что намеренно НЕ делаем#
ADR-0001…0004 не переписываются. Они написаны по D-01 v1.0, D-02 v2.1, D-03 v1.0, D-04 v1.0 — и это остаётся верным навсегда. После правок их поле «Метод» будет указывать на старые версии, история версий скажет, что изменилось, и читатель сам решит, что перепроверять. Ровно тот сценарий, ради которого версионирование и заводилось, — первый случай его настоящего применения.
Переписать их значило бы стереть единственное свидетельство того, как метод работал до правок.
Прогон не переделывается под новые версии. Если правки верны, повторный прогон даст те же решения — проверять это дороже, чем полезно. Проверка будет на E-02, на непохожем кейсе.
D. Порядок исполнения#
- Ответы по Б1–Б5.
- Правки раздела A, сгруппированные по документам:
00-template.md→D-01→D-02→D-03→D-04→01-adr-template.md. - Прогон
check.py; совместимость всех документов с новой версией мастер-шаблона. - Итог ревизии в
96-backlog.md: таблица «было / стало» по каждой находке. - То, что решено в Б2 и Б4, — отдельными шагами после правок.
Предварительная арифметика версий, если правки раздела A пройдут целиком:
| Документ | Было | Станет | Почему |
|---|---|---|---|
00-template.md |
v3.0 | v4.0 | Изменились правила заполнения и состав обязательных полей |
D-01 |
v1.0 | v1.1 | Порог реестра и строка о границе решения не меняют исхода |
D-02 |
v2.1 | v3.0 | Меняется область применения; при разделении — плюс новый документ |
D-03 |
v1.0 | v2.0 | Отвергнуто умолчание для целого класса случаев — исход меняется |
D-04 |
v1.0 | v2.0 | Меняется условие применимости и ось согласованности |
01-adr-template.md |
v1.1 | v1.2 | Новые поля, старые записи остаются верными |