Харнесс изнутри: одна команда, пять слоёв и карта из сорока курсов

Начинаем не со схемы, а с одной настоящей команды. Аня уже посмотрела схему со стрелками и честно призналась, что не поняла ничего: коробочки называются красиво, а что происходит после нажатия Enter — не видно. Поэтому первый разбор — путь команды dz guard целиком, от нажатия клавиши до числа, которое получает оболочка.

Четыре термина, по одной фразе каждый. dz — программа, которую запускают строкой в терминале; такую программу называют CLI (command-line interface, «интерфейс командной строки»). Интерфейс — часть кода, которая разговаривает с человеком и с файлами: читает, печатает, возвращает число. Ядро — часть, которая ничего не читает и не печатает: она получает значения и возвращает значение. Код возврата — то самое число, которым программа отвечает оболочке: 0 — прошло, не 0 — отказ.

Восемь шагов ровно так, как они лежат в коде на закреплённом снимке a10241d1 (снимок — отпечаток состояния репозитория, к которому привязаны все ссылки этого курса):

1. Человек набирает dz guard в терминале.
2. Диспетчер разбирает аргументы и находит ветку — harness-cli/src/cli.ts:16762, case 'guard'.
3. Ветка зовёт локальную функцию команды — cmdGuard(...), cli.ts:9680.
4. Функция читает файлы проекта и собирает факты.
5. Факты уходят в ядро на решение — evaluateGuard(facts, rules), harness-core/src/guard.ts:765.
6. Ядро возвращает вердикт значением и ничего не печатает.
7. Интерфейс печатает вердикт человеку и возвращает код.
8. Оболочка получает код возврата.

Где здесь шов. Шов — место, где кончается одна ответственность и начинается другая. В этом пути он проходит между шагами 4 и 5: до него живёт интерфейс, после — ядро. Польза от такого разделения ровно одна и вполне практическая: решение можно проверить тестом, не запуская программу, а печать проверяется прогоном.

Квитанции к этому разделу (команды, которыми Аня перепроверила все три ссылки):

git show a10241d1:packages/@dzhechkov/harness-cli/src/cli.ts | grep -n "case 'guard'"      # 16762
git show a10241d1:packages/@dzhechkov/harness-cli/src/cli.ts | grep -n '^function cmdGuard(' # 9680
git show a10241d1:packages/@dzhechkov/harness-core/src/guard.ts | grep -n 'export function evaluateGuard' # 765

Куда идти дальше по этой теме. Устройство самого движка под dz — курс engine: он показывает, что происходит внутри после Enter. Сами команды и как ими пользоваться каждый день — курс harness-cli.

Здесь курс делает то, чего документ пока не делает: показывает правку рецензента и объясняет, почему она несущая.

Первая редакция раздела говорила, что шов проходит «ровно в одном месте». Аня нашла в отзыве независимого проверяющего возражение, которое трудно отвести: таблица одного счастливого пути не доказывает, что внутри команды нет других обращений к ядру и что решения не принимаются где-то ещё. Для слова «ровно» нужен полный граф вызовов, а его никто не строил.

Поэтому правильная формулировка — «показанный здесь основной шов». Она слабее и честнее: пример показывает, КАК выглядит шов там, где он проведён, и ничего не утверждает про остальные команды.

Что отзыв, наоборот, подтвердил своими словами: в хорошо разделённой команде интерфейс собирает факты и показывает результат, а ядро принимает проверяемое решение, — однако не все команды устроены столь чисто. Это ровно та мысль, которую стоит унести; в ней нет слова «все».

Два числа, которые полезно держать рядом. Генератор снимка выдаёт 82 команды dz и 85 веток case в диспетчере. Числа разные. Курс не берётся объяснять разницу: объяснение, которое давал документ, — среди находок, ещё не закрытых проверкой. Само расхождение — хорошее напоминание, что «одна команда = одна ветка» тут не аксиома.

Перепроверить обе величины:

node scripts/arch-snapshot-counts.mjs --rev a10241d1

Общее правило, ради которого раздел написан. Один пример — сильное ОБЪЯСНЕНИЕ и слабое ДОКАЗАТЕЛЬСТВО. Пользуйся им, чтобы понять форму; не пользуйся, чтобы утверждать общее свойство.

Куда идти дальше. Как вообще отличают «показали» от «доказали» — курс skills-qe: он про требование предъявить свежее свидетельство до слова «готово». Как формулировать утверждение не сильнее своих входов — курс skills-reasoning.

Маленький сюрприз, который стоит дороже, чем кажется.

Аня решила перепроверить ссылки из первого раздела — не по снимку, а просто в рабочем каталоге, как сделал бы любой нормальный человек. И получила другие числа.

# на закреплённом снимке a10241d1
git show a10241d1:packages/@dzhechkov/harness-cli/src/cli.ts | grep -n "case 'guard'"       # 16762
git show a10241d1:packages/@dzhechkov/harness-cli/src/cli.ts | grep -n '^function cmdGuard('  # 9680

# в рабочем дереве в тот же день
grep -n "case 'guard'" packages/@dzhechkov/harness-cli/src/cli.ts # 16779
grep -n '^function cmdGuard(' packages/@dzhechkov/harness-cli/src/cli.ts # 9681
```

Семнадцать строк разницы за сутки. Ничего не сломалось: просто кто-то дописал код выше по файлу. При этом третья ссылка — guard.ts:765 — совпала и там, и там. То есть ошибка не постоянная и не громкая: часть ссылок сходится, часть тихо уезжает. Именно поэтому она опасна.

Правило, которое из этого следует. Ссылка вида файл:строка — не адрес, а координата на конкретном снимке. Приводи её ТОЛЬКО вместе с отпечатком снимка, иначе через неделю читатель откроет указанную строку, увидит там что-то другое и решит, что документ врёт целиком.

Это, кстати, единственная причина, по которой архитектурный документ вообще завёл себе «один снимок на весь документ» и генератор чисел: чтобы читатель, встретив два числа на соседних страницах, мог сказать, сравнимы ли они между собой.

Куда идти дальше. Как вообще устроена дисциплина «у каждого утверждения — проверяемая ссылка» — курс evidence-wiki. Как проверять инструмент измерением, а не чтением, — курс skills-bto.

Единственный кусок документа, к которому у пяти проверок не нашлось ни одной претензии. Наоборот: последний рецензент назвал легенду среди того, что сделало текст честнее. Поэтому её берём как есть — она пригодна к преподаванию без правок.

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

• [СХЕМА] — концептуальная картина: слои, роли, замысел. Проверяется ничем машинным, это просто язык описания. НЕ доказывает, что код устроен именно так.
• [ГРАФ] — связи, посчитанные по полям манифестов (манифест — файл, где пакет объявляет, от кого зависит). Проверяется командой над снимком. НЕ доказывает, что связь используется в работе: импорт не равен вызову.
• [ГАРАНТИЯ] — обещание поведения: что не пройдёт, что будет отказом, какая появится квитанция. Проверяется прогоном и кодом возврата. НЕ доказывает ничего за пределами названной области действия.

Правило, из-за которого легенда и появилась: каждая гарантия обязана нести область действия рядом с собой. Гарантия без границы читается как абсолютная, а абсолютных здесь нет ни одной. Обе формулировки, которые проверка назвала опасными, были именно такими — обещаниями без границы.

Маленькая честность про эту самую страницу. Два независимых рецензента заметили в документе смешную вещь: метки [ГРАФ] и [СХЕМА] стоят, а картинок под ними нет — метка обещает изображение, а следом идёт обычный абзац. Курс это чинит буквально: диаграмма выше — настоящая, и стоит она ровно под тем жанром, который обещает.

Куда идти дальше. Как заставить каждое утверждение носить свою ссылку — курс evidence-wiki. Как оформлять решения так, чтобы владелец видел развилку, а не пересказ, — курс skills-decision-mockups.

Одна фраза, ради которой всё это придумано: каждая проверка должна жить на самом дешёвом слое, который способен её выразить, — потому что проверка, поднятая на слой выше, превращается из гарантии в вероятность.

Сразу оговорка про слово «лестница». Независимая проверка справедливо заметила: называть это «петлёй» нельзя. Петля — цикл с обратной связью, а здесь никакой обратной связи не показано. Лестница — шкала размещения: она отвечает на вопрос «куда положить проверку», и только на него. Аня держит это в голове, чтобы не пересказать сильнее, чем есть.

Пять слоёв, сверху вниз — от самого надёжного к самому слабому:

1. Детерминированный тест или правило dz guard — дёшево, воспроизводимо, молча не отказывает.
2. Всегда загружаемый файл роли — подаётся агенту в контекст каждый прогон; но прочтение и следование ему ничем не проверяются.
3. Гейт шага конвейера (гейт — обязательная проверка на пути, без прохождения которой шаг не считается сделанным) — у него машинно-проверяемый выход.
4. Суждение навыка или ревьюера — сработает, если навык вызван удачно.
5. Память агента («надо не забыть») — вероятностно, отказывает молча.

Разница между слоем 1 и слоем 5 — не в качестве, а в поведении при отказе. Тест, который перестал ловить, краснеет. Память, которая перестала помнить, молчит — и ты узнаёшь об этом из инцидента.

Область действия самой лестницы, дословно из документа. Лестница говорит, КУДА класть проверку, и не утверждает, что все существующие проверки уже лежат правильно. Она также ничего не гарантирует сама по себе: её собственное соблюдение — суждение автора правки, то есть слой 4. Практическое следствие: фраза «это на слое 1» доказывается только показанным тестом, который краснеет, а не местом в таблице.

Куда идти дальше. Как конвейер фичи расставляет свои гейты по шагам — курс feature-adr. Как измерением проверяют, что проверка вообще кусается, — курс skills-bto. Как решения фиксируются, а не теряются в переписке, — курс skills-ecc.

Это не опровержение лестницы, а её недостающая ступенька — и она важнее, чем выглядит.

Проверяющий написал так: слой 1 назван фактически гарантией, хотя даже корректный тест ничего не гарантирует, если его не запускают на обязательном пути. Аня перечитала дважды и согласилась: тест в репозитории и тест на пути к выпуску — это два разных объекта.

Условие, без которого нижняя ступенька пустая: проверка со слоя 1 становится гарантией только тогда, когда она лежит на ОБЯЗАТЕЛЬНОМ пути — там, где мимо неё нельзя пройти. Тест, который никто не запускает, — это документация с претензией.

Вторая половина того же возражения тоньше. Краснеющий тест доказывает чувствительность теста к конкретной поломке, которую в него подставили. Он не доказывает:

• что проверяемое свойство описано полностью — поломок бывает больше одной;
• что гейт вообще исполняется на пути к выпуску.

Три вопроса, которые после этого раздела задаются к любой фразе «у нас это на слое 1»:

1. Покажи тест, который краснеет, — не место в таблице, а прогон.
2. Покажи, что он на обязательном пути: что ломается, если его пропустить.
3. Назови, какую именно поломку он ловит — и какую заведомо не ловит.

Куда идти дальше. Проверка того, что тест действительно кусается, — курс skills-qe. Измерение вместо чтения, с честным вердиктом «недостаточно данных», — курс skills-bto.

Задача, ради которой всё это существует. Скилл — папка с инструкцией для ИИ-агента: что уметь и как именно это делать. Каждый редактор с ИИ читает скиллы в своём формате и из своей папки. Раньше это означало по копии инструкции на редактор — и все копии со временем расходились. Решение: писать один раз в канонической форме (канон — единственная форма-первоисточник, из которой машинно получают остальные) и переводить её в форматы редакторов. Переводчик и называется адаптером.

Проверяющий справедливо заметил, что обещание «переводим один канон в десять форм» непроверяемо, пока не сказано, ЧТО переводится и что при этом сохраняется. Аня пошла читать код.

Канон скилла — это три поля (core/src/skill-document.ts:36): заголовок как текст, тот же заголовок разобранным, и тело. Не структура с десятками свойств, а именно эти три. В самом коде рядом написано несущее свойство: заголовок и тело, сложенные обратно, воспроизводят исходный файл побайтово.

Контракт адаптера — три операции (core/src/adapter.ts): получить контекст компиляции (куда писать и в строгом ли режиме), выдать результат — список файлов и предупреждения, и проверить — сошлось или нет, с перечнем ошибок.

Платформ ровно десять, и они перечислены константой (adapter.ts:16). Это значит, что одиннадцатую нельзя добавить молча: имя обязано появиться в списке. Ту же величину независимо выдаёт генератор снимка (targets = 10).

Граница, ради которой раздел и написан. Контракт обещает ДОСТАВКУ: файл записан, поля на месте, проверка сошлась. Он не обещает и не может обещать ПОВЕДЕНИЕ: как хост прочитает заголовок, вызовет ли скилл в нужный момент, поймёт ли его так же, как соседний редактор. И отдельно, дословно: проверка адаптера сравнивает полученный результат с формальными требованиями к файлам и полям, но не запускает целевой редактор.

Перепроверить обе величины:

git show a10241d1:packages/@dzhechkov/core/src/adapter.ts | sed -n '16p'
node scripts/arch-snapshot-counts.mjs --rev a10241d1     # величина targets

Куда идти дальше. Как один навык превращается в формат каждого редактора и что при этом теряется — курс adapters. Как этими переводами управляют из командной строки — курс harness-cli. Вторая дверь, для агента, а не для человека, — курс skills-mcp.

Деталь, которой в архитектурном документе нет, а в коде она есть. Аня нашла её, когда пошла проверять контракт адаптера, и это ровно тот механизм, отсутствие которого рецензент отметил как пропуск.

В контексте компиляции есть поле strict. Комментарий рядом с ним говорит прямо: когда strict включён, адаптер обязан отказать, а не применить перевод с потерей молча; когда выключен — а выключен он по умолчанию, — потеря сообщается предупреждением.

Остановись на этой фразе. Она означает, что по умолчанию система выбирает продолжить и рассказать, а не остановиться. Это осознанный выбор, и у него две стороны:

• Плюс: перевод в десять форматов не падает целиком из-за того, что один редактор не умеет какую-то возможность.
• Минус: предупреждение — самый лёгкий вид сообщения, чтобы его не заметить. Потеря случилась, отказа не было, никто не остановился.

По лестнице из пятого раздела это видно сразу: предупреждение, которое читает человек, — это слой 4 (сработает, если на него посмотрели). Отказ с кодом возврата — слой 1. Один флаг переносит проверку с четвёртого слоя на первый.

Перепроверить формулировку:

git show a10241d1:packages/@dzhechkov/core/src/adapter.ts | grep -n -A3 'strict'

Дальше решаешь ты. В упражнении ниже разберём три ситуации, где выбор между строгим режимом и предупреждением не очевиден.

Куда идти дальше. Что именно теряется при переводе в каждый формат — курс adapters. Как устроен движок, который применяет результат перевода к файлам, — курс engine.

Самый полезный раздел документа — про его собственный провал. Первая попытка независимой проверки архитектуры не выдала вердикта вообще. Аня перемерила всё, что можно перемерить, и вот что осталось стоять:

wc -c docs/architecture/verify-codex.log        # 741583
ls docs/architecture/verify-codex.md           # No such file or directory
grep -cE '^\s+[0-9]+\t' docs/architecture/verify-codex.log   # 5272
grep -c '^/bin/bash -lc' docs/architecture/verify-codex.log  # 25

741 583 байта журнала. Файла с вердиктом нет вовсе. Двадцать пять команд оболочки — и 5 272 пронумерованные строки чужих файлов, втянутые в контекст.

Первый вывод, ради которого раздел сохранён. Отсутствие вердикта нельзя читать как отсутствие претензий. Прогон не доказал ничего ни в одну сторону, и записать его как «замечаний нет» было бы подменой. Пустой ответ проверяющего — это отказ прибора, а не чистая совесть.

Второй вывод — и здесь курс поправляет сам документ. Соблазнительно объяснить провал так: «долго бегал по дереву, потому и не успел». Собственный журнал проверки это ОПРОВЕРГ: команд было немного, и суммарно они выполнялись считанные секунды. Убило не время команд, а объём, втянутый в контекст — те самые тысячи пронумерованных строк. Разница практическая: от «работал слишком долго» лечатся терпением, от «набрал слишком много» — только сужением.

Третий вывод опирается не на этот случай, а на отдельное измерение (.claude/rules/feature-adr-ultracode.md, строки 152–157): один и тот же вопрос, одна и та же модель, три отправки. Без ограничения объёма — 280 секунд, аварийный код возврата 124, 416 килобайт разведки, вердикта нет; под потолком в 1500 секунд — снова нет. Тот же вопрос с прямым указанием «читай только эти два файла» — 41 секунда, нормальный выход, оценка выставлена. Третий способ, где объём задаётся diff-ом изменений, — 146 секунд, нормальный выход, вердикт с находками.

Отсюда правило целиком: поднятие потолка времени покупает больше разведки, а не ответ. Лечение — объём.

Куда идти дальше. Как устроен конвейер, который заказывает независимое ревью и умеет честно сказать «вердикта не было» — курс feature-adr. Как требовать свежее свидетельство вместо отчёта на слово — курс skills-qe.

Здесь курс обязан начать с оговорки о себе самом.

В документе есть сводная врезка «четыре места, где нельзя принять решение». Аня проверила и обнаружила: врезку добавили ПОСЛЕ последнего прохода проверки, и сам этот блок никто не рецензировал.

# последний рецензент читал РОВНО ОДИН файл — он назван в его же задании:
head -c 200 docs/architecture/reassessment-2026-09-03/_q-final3.txt
grep -c 'Четыре места' docs/architecture/reassessment-2026-09-03/_consolidated3.md   # 0

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

Четыре ловушки:

1. Разрешить выкладку, доверившись заставе верхнего уровня. Застава сверяет только корень и внутрь подкаталогов не смотрит. Настоящий ответ даёт проверка содержимого выходного дерева, и её сегодня нет.
2. Разрешить выкладку по совпадению «55 = 55». Генератор снимка действительно выдаёт public=55 appendixRows=55 equal=true. Но равенство количеств не доказывает совпадения имён: два списка по 55 элементов могут состоять из разных элементов. Настоящий ответ — поимённый инвентарь по каждому пакету.
3. Считать документ актуальным после зелёного генератора. Генератор сверяет девять счётных величин, а не весь текст. Зелёный генератор говорит только про эти девять чисел.
4. Принять приведённый в тексте curl за воспроизводимую проверку. Команды в тексте сокращены до сути; полные лежат в журналах проверки.

Общее правило, из которого эти четыре — частные случаи: документ описывает, а не уполномочивает. Решение о выпуске принимают приборы, отказывающие кодом возврата, а не абзац, прочитанный как разрешение.

Куда идти дальше. Как выглядит дисциплина «каждое утверждение носит проверяемую ссылку» — курс evidence-wiki. Как оформить владельцу настоящую развилку с рекомендацией вместо пересказа — курс skills-decision-mockups. Как фиксировать принятые решения, чтобы к ним можно было вернуться, — курс skills-ecc.

Этот раздел можно читать первым и единственным. Если ты пришёл за указателем, а не за архитектурой — вот он целиком.

Сколько курсов на самом деле, по генератору снимка: dirs=41 pages=40 links=40 broken=0. То есть каталогов сорок один, собранных страниц сорок, ссылок в указателе сорок, битых ссылок ноль. Каталогов на один больше, чем страниц, и курс не выдаёт эти два числа за одно и то же — документ на такой подмене уже был пойман проверкой. Перепроверить: node scripts/arch-snapshot-counts.mjs --rev a10241d1.

Семья 1 — Движок, командная строка и адаптеры. Отвечает на вопрос «как это вообще работает изнутри».

• engine — что происходит внутри dz после Enter: ядро, хранилища знаний, пресеты, мост к внешним инструментам.
• harness-cli — как устанавливать, обновлять и согласованно держать навыки ассистента в разных средах.
• adapters — как один навык превращается в формат каждого редактора и что при этом теряется.

Семья 2 — Конвейер фич и качество. Отвечает на вопрос «как довести изменение до кода, которому можно верить».

• feature-adr — путь одной фичи от согласованных требований и зафиксированных решений до проверенного кода.
• skills-qe — требование предъявить свежее свидетельство качества до слова «готово».
• skills-bto — проверка навыков и команд измерением вместо чтения, с честным вердиктом «недостаточно данных».
• skills-ecc — инженерная культура: решения фиксируются, а не теряются в переписке.
• skills-reasoning — меняет не то, что агент знает, а как он думает: проговорённые допущения, хирургические правки.

Семья 3 — Продукт и требования. Отвечает на вопрос «что вообще стоит делать и как это обосновать».

• skills-pm — продуктовые навыки для инженера, которому отдали продукт: дерево возможностей, приоритизация, канва стратегии.
• skills-analyst-manual — путь от размытой задачи до брифа: гейт ясности, правильный порядок вопросов.
• idea2prd — превращает сырую идею в комплект требований, который можно передать кодирующему ассистенту.
• design-thinking — проверка идеи на людях: отделить подтверждённые потребности от догадок.
• keysarium — где ИИ принесёт продукту пользу и как защитить выбранный сценарий перед стейкхолдерами.
• presentation-storyteller — тема превращается в презентацию к защите: аргументация, источники, речь к слайдам.

Семья 4 — Книги как навыки. Отвечает на вопрос «как заставить ассистента отвечать главами, а не памятью».

• book-digitizer — превращает инженерную книгу в устанавливаемый пакет навыков и базу знаний.
• skills-book-ai-apps — оцифрованная книга по ИИ-приложениям: ответы страницами и главами.
• skills-book-ddia — высоконагруженные приложения: репликация, партиционирование, транзакции.
• skills-book-fundamental-software-architecture — основы архитектуры ПО: компромиссы, характеристики, чек-листы завершения.

Семья 5 — Инженерные наборы навыков. Отвечает на вопрос «как агент делает дежурную инженерную работу одинаково».

• skills-devops — ревью, аудит, миграции, инциденты, деплой как протоколы.
• skills-12factor — двенадцать правил облачного приложения как навыки агента.
• skills-mcp — рабочие инструкции к внешним инструментам вместо угадывания их протокола.
• skills-web3 — работа с блокчейн-стеком: кошельки, контракты, проверка транзакций.
• skills-reverse-engineering — разбор чужого продукта до понятной модели: что делает, из чего собран, как повторить.

Семья 6 — Сайты, курсы и публикация. Отвечает на вопрос «как показать сделанное людям».

• tutorial-factory — фабрика, которой собран и этот курс: из пакета получается проверяемый интерактивный сайт.
• skills-edu-site — сборка обучающего сайта из данных курса: разделы, упражнения, прогресс.
• skills-transcript-site — транскрипт выступления превращается в сайт за шесть шагов.
• skills-website-cloner — ответ на «хочу так же» клоном сайта, а не похожей вёрсткой.
• skills-demo-publisher — автоматическая запись демонстраций и самодостаточный сайт с видео.
• skills-package-story-page — страница-история о пакете с доказательствами из пути, а не из обещаний README.
• skills-taste — как собирать с агентом интерфейсы, которые не выглядят одинаково.

Семья 7 — Исследование, факты и решения. Отвечает на вопрос «откуда мы это знаем и как это предъявить».

• evidence-wiki — каждое утверждение получает проверяемую ссылку вместо набора цифр без источников.
• scout — поиск новых навыков и инструментов по одиннадцати источникам вместо ручного просмотра.
• news — дайджест по теме со ссылками на источники и только новое в следующих выпусках.
• skills-academic — конвейер проверки выпускных работ вместо чтения на глаз.
• skills-decision-mockups — страница решений для владельца: настоящие развилки, макеты до и после.

Семья 8 — Готовые продукты и запуск. Отвечает на вопрос «как выглядит собранное на этом харнессе целиком».

• health-advisor — подготовка к разговору с врачом: разбор анализов и сочетаний лекарств, данные остаются у пользователя.
• trip-planner — поездка складывается в один автономный мобильный файл: дни, карты, погода, контакты.
• p-replicator — разворачивает новый проект целиком: от среды разработки до готового к запуску приложения.
• cloudru-hub — подключение облачного движка так, чтобы платные шаги требовали явного разрешения.
• loop-designer — проектирование воспроизводимой многошаговой работы агентов и проверки каждого запуска.

Аня советует держать эту карту открытой в соседней вкладке: сорок курсов запомнить нельзя, а восемь вопросов — можно.

Честный итог: чем этот курс является и чем нет.

Аня прошла все одиннадцать разделов и подводит черту. Курс собран из кусков архитектурного документа, которые выдержали независимую проверку, — и только из них. Сам документ несёт оценку C: пять проходов проверки, а в последнем отзыве поимённо перечислены шестнадцать мест, где утверждение сильнее своего доказательства. Перепроверить количество:

awk '/Что осталось поимённо/{f=1} /Три следующих исправления/{f=0} f' \
  docs/architecture/reassessment-2026-09-03/_a-final3.md | grep -c '^- '   # 16

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

Что курс дал:

• один настоящий путь команды с проверяемыми ссылками и оговоркой о его границах;
• три жанра утверждений — вопрос «какого это жанра» снимает большую часть путаницы;
• лестницу из пяти слоёв и условие, при котором нижняя ступенька работает;
• контракт адаптера с честной границей между доставкой и поведением;
• две истории отказа, каждая с опровергнутым первым объяснением.

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

Три двери — выбирай по себе.

1. Ты хочешь понять систему изнутри — engine, затем adapters.
2. Ты собираешься менять код — feature-adr, затем skills-qe.
3. Ты просто пользуешься — harness-cli, затем нужная семья из карты в одиннадцатом разделе.

Вопрос на подумать, у которого нет одного ответа. Этот курс — тоже документ. Он ничего не гарантирует и никого ни на что не уполномочивает. Тогда что именно ты теперь можешь сделать, чего не мог до него, — и чем ты это проверишь?