dz CLI: арсенал для твоего AI-харнеса

Мира — участница нашей мастерской, и её первый вопрос был таким же, как у тебя: «зачем мне ещё одна CLI-утилита?»

Ответ короткий: dz — это пакетный менеджер навыков для харнеса твоего AI-агента, плюс кросс-компилятор. Харнес — вся обвязка вокруг модели: навыки (skills), команды, хуки, память. Ты один раз описываешь, ЧТО должен уметь твой агент, а dz раскладывает это под конкретную платформу — Claude Code, Copilot, Cursor, Gemini, всего 10 целевых платформ.

Что это меняет на практике:

• без dz Мира копировала бы markdown-файлы руками и через неделю не помнила бы, какая копия свежая;
• с dz канонический источник один, а dz list покажет всё установленное;
• один сломанный навык никогда не спрячет остальные.

Компромисс: ты платишь за новую абстракцию (нужно освоить команды dz), а взамен получаешь воспроизводимость — тот же арсенал на любой машине одной командой.

💬 Просто попроси. Сразу главный секрет удобства: команды dz не надо заучивать. Внутри Claude Code или Codex ты просто говоришь ассистенту «покажи, какие навыки у меня установлены» — и он сам выполнит dz list. Команды в этом курсе — чтобы ты ПОНИМАЛ, что происходит под капотом; разговаривать с харнесом можно словами.

Хватит теории — Мира уже открыла терминал, открывай и ты.

Пакет живёт на npm: страница @dzhechkov/harness-cli на npmjs.com, исходники — в публичном зеркале на GitHub. Путь до работающего инструмента — три шага:

1. Установи как обычный npm-пакет: npm i -g @dzhechkov/harness-cli.
2. Проверь, что инструмент жив: dz --version (работают также dz -v и dz version) — одна строка, exit 0.
3. Разверни арсенал в проекте: dz init — компилирует канонические навыки под твою платформу.

Хочешь выборочно? dz init --select agentdb-memory поставит один конкретный компонент — например, самообучающуюся память на AgentDB.

Грабли Миры — не повторяй: она сначала запустила init в домашней папке вместо проекта — dz кладёт файлы относительно текущей директории.

Компромисс: init за один вызов делает сразу многое — это быстро, но пока не знаешь, ЧТО именно он разложил, стоит заглянуть в созданные файлы (следующие секции как раз про это).

💬 Просто попроси. В Claude Code достаточно сказать: «поставь dz и разверни навыки в этом проекте» → ассистент выполнит dz init; «какая у меня версия dz?» → dz --version. Мира за первую неделю не набрала руками ни одной команды — она их только читала в ответах ассистента и постепенно запомнила сама.

Теперь, когда init отработал, Мира спрашивает: «а как управлять тем, ЧТО именно ставится?»

Есть три способа — но прежде чем я их покажу, реши за Миру сам. Ей нужно: быстро стартовать сегодня, не притащить лишнего и через месяц спокойно получать обновления. Что выберешь: готовый набор целиком, ручной точечный выбор или пакет с версией? Запомни ответ — сейчас проверим.

1. Пресет — готовый набор под роль, например academic для научной работы. «Поставила за минуту, — говорит Мира, — но в списке появились навыки, которые мне не нужны».
2. Точечный выбор — dz init --select <имя> ставит ровно один навык. Чисто — но имя надо ЗНАТЬ, а Мира пока не знает ни одного.
3. Целый npm-пакет навыков — команды и навыки приезжают вместе с версией и README.

А теперь важное: как понять, что пакет не подменили? Для этого есть подпись:

• dz sign подписывает пакет;
• dz verify-pack проверяет подпись;
• dz doctor и dz upgrade делают эту проверку автоматически.

Сверь свой выбор с компромиссами: пресет быстр, но тащит лишнее; точечный выбор чист, но требует знать имена; пакет даёт версионирование, но добавляет зависимость от npm. Мира выбрала пресет для старта и точечные добавки потом — разумное решение по умолчанию; если ты выбрал иначе — значит, у тебя другие приоритеты, и это не ошибка.

💬 Просто попроси. «Проверь, что подписи навыков целы» → dz verify-pack; «продиагностируй мою установку» → dz doctor; «обнови навыки до свежих» → dz upgrade. Ты называешь НАМЕРЕНИЕ — ассистент выбирает команду. Именно поэтому три способа не надо помнить: достаточно помнить, чего ты хочешь.

«Хорошо, — говорит Мира, дочитав про три способа установки, — но у меня остался вопрос из прошлой секции. Имя навыка, оказывается, надо ЗНАТЬ. А я не знаю ни одного. У меня есть только задача: мне прислали результаты анализов, и я хочу в них разобраться».

Это и есть первый настоящий вопрос новичка. Он звучит не «какая команда», а «у меня вот такая задача — чем её решать». Прежде чем читать дальше, реши за Миру: листать каталог глазами, угадывать имя команды или сказать задачу обычными словами? Запомни свой ответ — сейчас сверим.

Первый способ, главный: обычные слова. Скажи задачу ассистенту так, как рассказал бы коллеге: «пришли анализы крови, чем их разобрать?». В арсенале есть навык skill-advisor — он ровно для этого: читает ЖИВОЙ каталог в момент вопроса и отвечает, какой навык, пресет или готовый пакет взять, в каком порядке их применять и чего в арсенале НЕТ. Русские фразы он понимает: среди его пусковых фраз записаны «какой скилл» и «чем решить задачу» — это видно в его собственном описании через dz info skill-advisor.

Почему важно именно «живой каталог»: арсенал меняется каждую неделю. Любой список навыков, вписанный в текст статьи или курса, начинает врать через месяц. skill-advisor не хранит список — он спрашивает каталог заново на каждый вопрос.

Второй способ: команды — когда нужное слово ты уже знаешь.

dz registry                      # весь каталог по категориям
dz registry --category health    # одна категория целиком
dz registry search анализ        # поиск по слову
dz recommend "<задача>"          # подбор по ключевым словам
dz stats                         # сколько всего пакетов, навыков, целей

И честный предел, который надо знать заранее. Подбор командой работает по БУКВАМ, а не по смыслу, и словарь тем внутри него — только английский. Измерено запуском 1 сентября 2026:

1. dz registry search "анализы" — ноль результатов. dz registry search "анализ" — восемь. Разница в одной букве: поиск сверяет подстроку, и множественное число уже не совпадает.
2. dz recommend "пришли анализы крови, хочу разобраться" предлагает devops и qe-engineer — то есть Kubernetes и тестирование. Тот же вопрос по-английски даёт другие темы.

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

Сверь свой выбор с тем, что вышло у Миры. Она начала фразой «мне прислали анализы, чем смотреть» — и получила имена навыков, которые не смогла бы угадать. Потом проверила себя каталогом: dz registry --category health показал 27 навыков одной только медицинской категории. И лишь третьим шагом поставила найденное точечно. Компромисс: обычные слова требуют работающего ассистента и дают ответ, который стоит перепроверить каталогом; команда отвечает мгновенно и одинаково, но только если ты угадал слово. Если ты выбрал «листать каталог» — это не ошибка, просто дороже: читать весь список глазами дольше, чем задать один вопрос.

💬 Просто попроси. «У меня вот такая задача — какой навык взять?» → ассистент включит skill-advisor; «покажи весь каталог» → dz registry; «что вообще есть по здоровью» → dz registry --category health; «поставь вот этот» → dz init --select <имя>. Ты называешь ЗАДАЧУ — имя команды подбирается за тебя.

Ты уже прошёл две фазы, даже не зная об этом.

Начнём с обманутого ожидания: Мира искала нужную команду перебором, листая вывод dz list, и на третьем экране из 85 команд сдалась: «да тут неделя нужна, чтобы просто ПРОЧИТАТЬ этот список». Прежде чем читать дальше, реши за неё: зубрить команды по алфавиту, выучить топ-10 самых частых — или найти карту, которая говорит, куда смотреть В ТВОЕЙ ситуации?

README идёт третьим путём: работа с dz разложена на шесть фаз пользовательского пути:

1. Discover — что вообще есть? (dz list)
2. Install — разверни рабочее место (dz init)
3. Use — работай с агентом
4. Create — собери свой навык
5. Maintain — держи арсенал свежим (dz doctor, dz upgrade)
6. Share — опубликуй в мир

Зачем эта карта? Мира отвечает: затем же, зачем сетевику схема сети — когда что-то непонятно, находишь СВОЮ фазу, и список нужных команд сокращается с 84 до пяти-шести. Топ-10 по частоте не сработал бы: в него попали бы частые команды из чужих сценариев, а не из твоего.

Отдельная хитрость фазы Use: dz profile — один раз скажи, кто ты, и агент перестанет объяснять тебе не то и не так.

Мы повторяем это намеренно: та же карта фаз встретится тебе и в упражнении, и в финальном тесте — то, что повторено трижды, запоминается. Компромисс: карта фаз — упрощение, реальная работа скачет между фазами; но как навигация по 85 командам она окупается с первого дня.

💬 Просто попроси. Профиль настраивается разговором: «объясняй мне про тестирование попроще, я новичок, а в сетях я профи — там жаргон можно» → ассистент сам вызовет dz profile set. Фазы пути — это не «выучи на каждой фазе новые команды», а «по мере роста проси о более сложном».

Вот вопрос, на который Мира не нашла готового ответа — подумай и ты, прежде чем читать дальше: если твой агент-конвейер описан планом, обязан ли живой Claude-хост присутствовать при КАЖДОМ запуске?

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

Путь по шагам:

1. dz workflow — проектирует петлю под твой сценарий. Здесь модель нужна: это разовая проектная работа.
2. dz workflow-lint — проверяет план до запуска. Дешёвый детерминированный гейт: ошибка плана ловится ДО того, как что-то выполнится, а не в три часа ночи посреди прогона.
3. dz workflow run — выполняет план без хоста Claude. План уже составлен, выполнение не требует дорогой модельной сессии.
4. dz workflow-trace export / import — телеметрию прогона можно унести на другую машину.

«То есть я плачу за проектирование один раз, а дальше гоняю петлю каждую ночь без модели?» — переспрашивает Мира. Именно.

Ещё одна команда той же семьи с говорящим принципом: dz feature-adr-checkpoint записывает стадию конвейера только после того, как ЗАСВИДЕТЕЛЬСТВУЕТ её — не по обещанию, а по факту.

Компромисс: план без хоста дешевле и воспроизводимее, но он статичен — импровизировать по ходу, как живая сессия, он не умеет.

💬 Просто попроси. «Собери мне ночной конвейер: прогнать тесты, починить красное, утром отчёт» → ассистент напишет workflow и проверит его dz workflow-lint. «Почему вчерашний прогон встал?» → dz workflow-trace. Петли проектируются диалогом; команды — то, во что диалог компилируется.

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

Почему? Потому что чат — не память. Урок существует, только если он ЗАПИСАН:

• dz teach "<урок>" — кладёт урок в хранилище;
• dz recall — поднимает его при следующей работе.

Но тут вторая ловушка, тоньше первой: свежий урок — это гипотеза в карантине, а не знание. Один случай (n=1) мог быть совпадением; dz держит новый урок в карантине, пока тот не докажет пользу повторно, и только потом продвигает.

Рангом урока управляет не дата записи, а польза. Работают два разных вопроса:

• помогал ли урок хоть раз — поиск поднимает выше тот, что уже пригодился в деле. В коде эта переранжировка названа *bandit*: так в теории принятия решений зовут приём, где из нескольких вариантов чаще выбирают тот, что раньше приносил отдачу.
• растёт ли отдача со временем — сравнивается, как часто урок помогал недавно против того, как помогал раньше. Направление этого изменения и называют *наклоном*: урок с нарастающей пользой встаёт выше того, что однажды сработал и заглох. В коде эта оценка носит имя *SAFLA-дельта*, по названию принятой в проекте схемы самообучения (дельта здесь — просто разница между «стало» и «было»).

Хранилищ два на выбор: простой текстовый файл, где каждая строка — отдельная запись (формат JSONL), — или база с векторным поиском AgentDB (dz init --select agentdb-memory). Векторный поиск ищет по СМЫСЛУ, а не по совпадению слов: запрос «грабли с внешней моделью» найдёт урок, где написано «Codex вернул заглушку», хотя ни одно слово не совпало.

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

💬 Просто попроси. Это самый разговорный урок из всех: «запомни урок: пустой вывод — это отказ, а не успех» → dz teach; «какие у нас были грабли с внешней моделью?» → dz recall. Память харнеса и задумана как собеседник: ты ей рассказываешь и её спрашиваешь — просто у неё, в отличие от чата, ничего не испаряется.

Мира научила помощника десятку уроков и на другой день наступила на те же грабли. Уроки на месте — она проверила. Почему они не сработали?

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

Измеренная цена этого пробела. В самом dz когда-то было восемнадцать перехватчиков, и ни один не читал хранилище уроков. Больше сотни записанных уроков попадали в работу только если человек сам набирал dz recall или если о них спрашивал конвейер разработки фич. Один и тот же урок был записан — и не помешал повторить ту же ошибку во второй раз.

Как это работает сейчас. Третья нога — перехватчик, и срабатывает он не при старте сессии, а на каждый ваш запрос. Разница существенная: при старте ещё неизвестно, о чём пойдёт речь, а к моменту запроса тема уже названа — и подобрать можно по ней.

Порядок такой:

1. вы пишете запрос обычными словами;
2. перехватчик берёт его текст и спрашивает хранилище уроков — до восьми самых близких по смыслу;
3. те, что прошли порог значимости, дописываются к вашему запросу как справка;
4. помощник видит их вместе с задачей — до того, как начнёт отвечать.

Две вещи, которые делают эту ногу пригодной, а не назойливой.

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

Молчание при любом сбое. Нет службы, нет зависимостей, испорченный ввод, медленный ответ — перехватчик молча завершается успехом. Сломанная подсказка не имеет права задержать вашу работу; полезность здесь стоит ниже безотказности, и это записано в самом коде.

Чего эта нога НЕ делает. Она не проверяет, что урок верен, и не заставляет ему следовать. Она кладёт его вам на стол в нужную минуту. Проверка верности — работа карантина и подтверждения вторым случаем (раздел про динамику самообучения).

💬 Просто попроси. Отдельной команды тут не нужно: нога работает сама на каждом запросе. Но проверить её можно словами: «что мы знаем про эту ошибку?» → dz recall по теме; «покажи, какие уроки поднимались и пригодились» → dz recall --usage.

Новый проект — это просто; а вот Мира получила ЧУЖОЙ репозиторий на сто тысяч строк.

Прежде чем читать дальше, выбери за неё:

1. читать код файл за файлом, пока картина не сложится;
2. расспросить автора, пока он не ушёл из команды;
3. сгенерировать карту командой.

Вариант 1 честен, но на ста тысячах строк это недели — а картину в голове всё равно никак не проверить. Вариант 2 быстр, но легенда в чьей-то голове устаревает и не передаётся следующему. Команда dz architecture — это вариант 3: она восстанавливает общую картину проекта, когда за деревьями файлов ты перестал видеть лес — или ПЕРЕД тем, как добавлять фичу в незнакомый код.

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

Рядом — целое семейство команд той же философии:

• dz project-skills — складывает конвенции проекта в навык, который подмешивается в каждый прогон;
• dz mr-rakes — учится на граблях: какие ошибки этот проект повторяет;
• dz retro — закрывает сессию разбором: что записать в уроки.

А для старта без знания схем есть пошаговый проводник — guided setup.

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

💬 Просто попроси. «Нарисуй карту архитектуры этого проекта» → dz architecture; «какие навыки подойдут этому репозиторию?» → dz project-skills; «подведи итоги сессии» → dz retro. Чужой проект ты исследуешь вопросами — команды под ними ассистент подберёт сам.

Финальный сюрприз курса — и он неприятный: зелёный тест может НИЧЕГО не проверять.

Мира однажды гордилась зелёным прогоном, пока не выяснила: тест прошёл бы и на коде БЕЗ её фичи. Для этого есть dz discrimination-check — он доказывает, что тест ловит дефект. По шагам:

1. возьми дерево ДО фичи;
2. прогони на нём свой новый тест;
3. красный — тест различает мир с фичей и без; зелёный — тест слеп, и его зелёный цвет ничего не стоит.

Второй гейт той же семьи — dz guard: самоизменяющаяся операция должна быть ОТКЛОНЕНА заранее, а не оплакана потом; guard встаёт на шов и отказывает до ущерба.

Третий шаг той же лестницы — dz feature-adr-setup --guards: превращает правило проекта в ТЕСТ. Потому что правило, живущее в памяти ревьюера, нарушается молча — а тест падает громко.

Компромисс: каждый гейт — трение при каждом прогоне; но цена трения фиксирована и мала, а цена теста, ослепшего молча, ничем не ограничена.

💬 Просто попроси. «Проверь всё перед публикацией» → dz guard --op publish; «докажи, что этот тест правда ловит баг» → dz discrimination-check. Заметь: просьба «проверь» — человеческая, а вот ОТКАЗ гейта — машинный и неумолимый. В этом и смысл: просишь словами, а проверяет — не настроение, а код.

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

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

dz profile init задаёт пять вопросов и записывает ответы в личное хранилище ~/.dz/profile.json (права 0600, и НИКОГДА не в проект — это про тебя, а не про репозиторий):

1. язык диалога;
2. регистр — насколько подробно объяснять («профи», «профи лайт», «просто»);
3. сильные домены — где можно без скидок: «networking (CCIE; NSX)» — пояснение в скобках сохранится как заметка;
4. слабые домены — где всегда нужна одна простая фраза, без просьбы;
5. преподаёшь ли ты — если да, объяснения строятся пересказываемыми.

Дальше самое важное. Профиль доставляется отмеченным блоком в ~/.claude/CLAUDE.md — то есть действует в каждом проекте, даже там, где dz не установлен. Один раз сказал — работает везде.

Правка на ходу, без повторного опроса:

• dz profile show — путь к хранилищу, возраст записи, вердикт о расхождении и готовый блок;
• dz profile set register профи — принимает твои же слова, русские в том числе; неизвестное значение будет отвергнуто с перечислением допустимых, а не проглочено молча;
• dz profile set weak add build-toolchains — добавить слабый домен;
• dz profile sync — перезаписать блок (запускается сам после init и set; чужое содержимое файла сохраняется байт в байт, перед каждой правкой делается копия).

И граница, ради которой всё это безопасно: регистр меняет ФОРМУ, а не ФАКТЫ. Числа, оговорки и плохие результаты переживают любое упрощение. Профиль управляет диалогом — и не распространяется на ADR, сообщения коммитов и отчёты качества: у них свой читатель и свои правила.

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

💬 Просто попроси. «Запомни: про сети со мной можно как с профи, а про сборку объясняй с азов» → ассистент сам вызовет dz profile set. «Покажи мой профиль» → dz profile show. Профиль и задуман как разговор о себе, а не как заполнение анкеты.

Ночной прогон завершился, Мира утром смотрит на результат — и не понимает, почему он шёл сорок минут вместо десяти. Спросить некого: агент не помнит, а разговор давно закрыт.

Здесь и нужна телеметрия прогона — следы, которые работа оставляет на диске сама, без просьбы.

Что читает эти следы:

• dz workflow-trace — временная шкала прогона и проверка последовательности: что за чем шло и где встало. Важная деталь честности: инструмент ВСЕГДА сообщает, кто засвидетельствовал запись — прибор, агент или никто; а --corroborate сверяет её с независимыми записями хоста в той части, которую тот способен подтвердить.
• dz score --slug <фича> — оценка ПРОЦЕССА одного прогона по его артефактам: была ли подтверждена архитектурная запись, доказала ли проверка свою различающую силу, какую оценку дала независимая модель. Оценка описательная: низкий балл ничего не блокирует и выходит с нулевым кодом.
• dz compounding — отчёт о том, окупается ли обучение: сколько уроков было пригодно, сколько применено, сколько сработало. Если данных мало, отчёт честно говорит «НЕ ИЗМЕРЕНО» вместо красивого нуля.
• dz deadwood — что не используется совсем; строго совещательно, ничего не удаляет.

Следы переносимы. dz workflow-trace export складывает телеметрию одного прогона в ОДИН файл — события, а не готовые сводки, — а import разворачивает её под явно названным корнем на другой машине. Разворачивание отказывается затирать прогон, у которого уже есть содержимое: лучше отказ, чем молча стёртая история.

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

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

💬 Просто попроси. «Почему вчерашний ночной прогон шёл так долго?» → ассистент откроет dz workflow-trace. «Оцени, насколько дисциплинированно прошла эта фича» → dz score. «Окупается ли наше обучение?» → dz compounding. «Забери телеметрию этого прогона на ноутбук» → export, затем import.

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

Хорошая новость: перенос — это две команды, и они устроены безопасно.

Вывоз. dz recall --all --json > patterns.json выкладывает ВСЁ хранилище в один файл: уроки с их текстами, доменами и накопленной пользой.

Ввоз. dz teach --from-json patterns.json вливает файл в хранилище другой машины. Два свойства делают эту команду безопасной:

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

Отсюда неожиданный вывод, который стоит запомнить: вывоз-ввоз — это не только переезд, но и СЛИЯНИЕ двух хранилищ. Две машины, каждая со своим опытом, обмениваются файлами в обе стороны — и обе становятся умнее.

Отдельно от уроков переносится их смысловой слой — векторное представление, благодаря которому поиск находит урок по смыслу, а не по буквальному совпадению слов: dz vector export и dz vector import. Ввоз здесь тоже щадящий: записи обновляются по идентификатору, ничего не затирается, чужое пропускается.

После слияния двух хранилищ появляется третья задача — дубликаты по смыслу: один и тот же урок, записанный разными словами. dz vector harmonize их находит; по умолчанию только показывает, а применяет изменения лишь по явной просьбе и с резервной копией.

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

💬 Просто попроси. «Выгрузи все выученные уроки в файл, я перенесу их на другую машину» → dz recall --all --json. «Влей вот этот файл уроков в наше хранилище» → dz teach --from-json. «Проверь, нет ли у нас теперь дублей по смыслу» → dz vector harmonize (сначала покажет, а не переделает).

В прошлом разделе Мира научилась записывать уроки и поднимать их. Но записать — это одно событие, а жизненный путь урока — это движение во времени, и вот его-то обычно и не показывают.

Останови взгляд на неприятном числе. Вот что говорит отчёт об этом самом складе прямо сейчас:

468 уроков · 321 когда-либо применён · 411 хоть раз затронут поиском
 57 не тронуты НИ РАЗУ · 114 в карантине
 доля «записали, но не читаем»: 31 %

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

Три ноги петли, и каждая обязательна:

1. собрать — dz teach, урок попадает на склад;
2. ранжировать — иначе на сотом уроке поиск вернёт шум вместо нужного;
3. применить — если урок ни разу не поднялся в работе, он не существует для дела.

Путь урока по шагам — и он едет сам. Это ключевое: движение по пути автоматическое, никто не ведёт урок за руку. Ты записал его один раз — дальше система сама наблюдает, сама считает и сама поднимает или опускает его в выдаче.

Что происходит без твоего участия:

1. Карантин ставится сам при записи. Свежий урок — не знание, а гипотеза: один случай мог быть совпадением, поэтому в полную силу он не действует.
2. Статистика применения копится сама. Каждый раз, когда урок поднялся в работе, это записывается в фоне — тебе не нужно ничего отмечать.
3. Ранг пересчитывается сам при каждом поиске: наверх идут те, что уже пригодились и чья польза нарастает.

И одно исключение, которое сделано намеренно. Выход из карантина автоматическим НЕ является — он заслуживается явным подтверждением. Причина тонкая и стоила отдельного разбора: если бы карантин снимался от того, что урок просто ПОКАЗАЛСЯ в выдаче, то любой случайный показ продвигал бы гипотезу в правило. Показ — это ещё не польза. Поэтому система различает два сигнала: «урок увиден» копится молча и двигает только ранг, а «урок подтверждён» — это отдельное событие, и только оно выпускает урок из карантина.

Где ты можешь вмешаться в автоматику (именно вмешаться — по умолчанию она работает без тебя):

• dz teach --reinforce <урок> — подтвердить: пригодился ещё раз, можно выпускать из карантина;
• dz recall --promote — продвинуть вручную, когда ты уверен раньше статистики;
• dz recall --forget — убрать урок, оказавшийся неверным.

Обе последние команды по умолчанию только ПОКАЗЫВАЮТ, что сделают, и применяют лишь по явной просьбе: общая память не переписывается молча.

Чем двигается ранг — не датой. Свежесть ничего не доказывает. Ранг двигают два разных вопроса:

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

Окупается ли петля целиком. На это отвечает dz compounding, и главная его ценность — в отказе врать: когда данных мало, он говорит «НЕ ИЗМЕРЕНО», а не рисует ноль. Он же показывает траекторию нарушений по каждому сторожу — где повторов стало меньше (петля сработала), а где больше (защита новая либо не применяется).

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

💬 Просто попроси. «Этот урок подтвердился второй раз — продвинь его» → dz recall --promote. «Этот урок оказался неверным, убери» → dz recall --forget. «Окупается ли наше обучение?» → dz compounding. Заметь: обе правки склада по умолчанию сначала показывают, что сделают, — общая память не переписывается молча.

Всё, что ты узнал о складе уроков, живёт в командах: спросил — увидел. Мира заметила проблему: чтобы понять, работает ли обучение, каждый раз надо ОСТАНОВИТЬСЯ и спросить. А значит, не спросишь — не заметишь, что оно сломалось.

Отсюда статусная панель — строка в самом низу окна Claude Code, которая показывает состояние харнесса постоянно, без вопросов. Ставится один раз:

dz statusline --install

Вот как она выглядит на этом складе прямо сейчас:

🎓 dz: 468 patterns · 326 used · 🧠 4 sources · ⎇ main · ⟳ 20h

Как её читать слева направо:

• 468 patterns — сколько уроков лежит на складе всего;
• 326 used — сколько из них хоть раз реально применялись. Разрыв между числами и есть та самая доля «записали, но не читаем» из прошлого раздела — её видно, не спрашивая;
• 🧠 4 sources — сколько источников знания подключено (оцифрованные книги и корпуса);
• ⎇ main — на какой ветке ты работаешь: защита от правки не в том месте;
• ⟳ 20h — сколько часов назад склад уплотнялся в последний раз. Растущее число говорит, что фоновое обслуживание не идёт.

И второй режим — живой прогон конвейера. Когда идёт разработка фичи, панель получает дополнительный сегмент, который обновляется прямо во время работы: на каком шаге прогон, сколько уроков поднято перед стартом и сколько записано по итогам. Конвейер сам сообщает панели своё состояние командой dz statusline --fa-record — тебе делать ничего не нужно, ты просто видишь строку вроде «Step 8 QE · поднято 1 · записано 2 · подтверждено 2».

Зачем это, если те же числа даёт dz compounding? Затем же, зачем приборная панель в машине: не «спросить давление в шинах», а увидеть, что оно упало, не задавая вопроса. Панель — это перевод обучения из состояния «можно проверить» в состояние «видно всегда».

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

💬 Просто попроси. «Поставь мне статусную панель» → dz statusline --install. «Что сейчас показывает панель?» → dz statusline. Заметь: цифры в панели не надо обновлять руками — она читает то же хранилище, что и все остальные команды.

У Мира накопилась знакомая беда: идеи приходят в работе, записываются в случайные места и там умирают. А те, что не умерли, оказываются записаны трижды разными словами.

Бэклог идей решает обе беды сразу — и решает не списком, а тремя механизмами.

Механизм первый: сверка по смыслу при записи. Ты пишешь dz backlog add "<идея>", и прежде чем создать запись, система сравнивает её со всеми существующими по смыслу, а не по совпадению слов. Три исхода: очень похоже — идеи сливаются; отчасти похоже — ставится связь «родственные»; ново — создаётся запись. Именно поэтому «починить подбор инструментов» и «recommend не понимает русский» не станут двумя карточками.

Механизм второй: компас. У бэклога есть цели с весами — что вообще считается движением вперёд. Сейчас их пять, например:

unified-harness (вес 1)      — всё личное ИИ-хозяйство в одном месте
compounding-learning (0.9)   — петля обучения окупается
honest-quality (0.9)         — честные гейты, никаких ложных зелёных
npm-product-quality (0.8)    — опубликованные пакеты как честные продукты
teachable-ecosystem (0.7)    — харнесс учит себе других

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

Механизм третий: жребий вместо спора с собой. Утренний вопрос «что делать сегодня» съедает силы и решается предвзято: берётся то, что приятнее. dz backlog roulette тянет взвешенный жребий, где вес складывается из трёх множителей:

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

Жребий воспроизводим: с одним и тем же зерном выпадет то же самое — это не «случайность ради случайности», а способ снять с себя предвзятость выбора.

И честная деталь, которая делает всё остальное рабочим. Закончил задачу — отметь: dz backlog ship <id>. Иначе она остаётся в барабане и будет выпадать снова и снова. Есть и обратные ходы: drop — отказаться с названной причиной, reopen — вернуть, harmonize — найти смысловые дубли, накопившиеся со временем.

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

💬 Просто попроси. «Запиши идею: …» → dz backlog add со сверкой по смыслу. «Что взять сегодня?» → dz backlog roulette --pick 3 покажет тройку с весами. «Эту сделал» → dz backlog ship. «Нет ли у нас дублей?» → dz backlog harmonize (сначала покажет, потом спросит).