Фабрика фич: feature-adr

Привет! Этот курс — про пакет @dzhechkov/skills-feature-adr: набор навыков для Claude Code, который превращает просьбу «реализуй функцию» в дисциплинированный конвейер — от требований до кода, прошедшего независимую проверку качества.

Знакомься: Мира, участница мастерской по работе с harness. dz она уже пробовала — устанавливала пакеты, запускала команды. Сегодня ей поручили разработать первую настоящую функцию, и делать это наугад страшно. Пакет feature-adr служит ей страховкой: одиннадцать шагов, после каждого из которых остаётся артефакт, доступный для проверки.

Что входит в пакет:
- 11 навыков — feature-adr, explore, challenge-panel, configure-feature-adr, system-grill и другие;
- 12 модулей конвейера — шаги 00–09 плюс проработка идей;
- поддержка agentic-qe — проверка качества встроена в процесс, а не добавлена задним числом.

Исходники и публичное зеркало: github.com/djd1m/dz-harness.

Компромиссы: пакет обеспечивает дисциплину и сохраняет цепочку артефактов, но для исправления опечатки такой конвейер избыточен — мелкие правки вноси вручную.

💬 Просто попроси.
- «Покажи, что умеет пакет feature-adr» → ассистент откроет README пакета и перескажет раздел What You Get.
- «Хочу разрабатывать функции, как на мастерской» → ассистент предложит установить пакет и запустить /feature-adr для твоей идеи.

Мира открывает терминал. Для установки нужна одна команда: пакет развернёт шаблоны навыков прямо в твоём проекте.

1. Выполни npx @dzhechkov/skills-feature-adr в корне проекта — навыки появятся в .claude/skills/.
2. Открой Claude Code в этой же папке.
3. Набери /feature-adr и опиши нужную функцию своими словами.

Готово — конвейер запущен. Начальная настройка не требуется: это режим Reference. Флаги --full-qe и --full-qe-extended подключают расширенную проверку качества (9 и 15 QE-навыков), когда она тебе понадобится.

Страница пакета: npmjs.com/package/@dzhechkov/skills-feature-adr · зеркало: github.com/djd1m/dz-harness.

Компромиссы: npx всегда загружает свежую версию, но в монорепозитории с workspaces может найти не тот исполняемый файл — решение описано в Troubleshooting (раздел 12 напомнит).

💬 Просто попроси.
- «Установи мне feature-adr» → ассистент выполнит команду установки пакета и проверит, что навыки появились в .claude/skills/.
- «Запусти конвейер для моей идеи» → ассистент вызовет /feature-adr с твоим описанием функции.
- «Включи полную проверку качества» → ассистент добавит флаг --full-qe-extended.

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

1. Шаг 0 — классификатор сложности: относит функцию к уровню S/M/L/XL.
2. Шаги 1–5 — проектирование: требования → исследование → ADR (архитектурное решение) → доменная модель → архитектура.
3. Шаг 6 — план реализации.
4. Шаг 7 — код.
5. Шаг 8 — межмодельная QE-проверка (независимая проверка качества).
6. Шаг 9 — fleet QE для крупных функций.

На конвейер можно посмотреть с двух сторон: в целом это воронка «идея → проверенный код», а по шагам — цепочка артефактов 00_complexity … 08_qe_report, где каждый файл можно открыть и оспорить.

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

💬 Просто попроси.
- «Покажи схему конвейера» → ассистент перечислит шаги 0–9 и укажет, какой артефакт создаётся на каждом из них.
- «На каком мы шаге?» → ассистент заглянет в features/<slug>/ и скажет, какие артефакты уже готовы.

Есть вопрос, на который непросто ответить: «насколько сложна моя функция?» Мира сначала полагалась на интуицию — и ошибалась в обе стороны. Поэтому в конвейере решение принимает не человек и не его настроение, а классификатор сложности — шаг 0.

Классификатор оценивает функцию по нескольким параметрам (каждый — от 1 до 4 баллов) и определяет уровень:

• S — небольшая: конвейер объединяет часть шагов и самостоятельно проходит до конца;
• M — средняя: самостоятельное выполнение с итоговой проверкой;
• L — крупная: после составления плана конвейер ОСТАНАВЛИВАЕТСЯ в контрольной точке — человек изучает ADR и план;
• XL — очень крупная: то же самое, плюс обязательный fleet QE на шаге 9.

Важно: уровень нельзя изменить во время выполнения — если границы функции изменились, честнее перезапустить конвейер. Зато в контрольной точке шага 0 ты можешь отменить решение классификатора — последнее слово остаётся за человеком.

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

💬 Просто попроси.
- «Оцени сложность этой функции» → ассистент выполнит шаг 0 и покажет решение классификатора с баллами.
- «Я не согласна, это L, а не M» → ассистент изменит уровень в контрольной точке шага 0.

Мира однажды обожглась: написала подробное ТЗ, а итоговый код жил своей жизнью. Spec-Driven Development (SDD) в feature-adr решает именно эту проблему с помощью четырёх принципов:

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

Обрати внимание на повторение: контракт появляется в требованиях, снова подтверждается в ADR и проверяется в QE — одна и та же идея выражена трижды, в трёх местах. Поэтому она и не теряется.

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

💬 Просто попроси.
- «Покажи спецификацию этой функции» → ассистент откроет слои 01_requirements → 03_adr → 06_plan и покажет, как контракт передаётся от шага к шагу.
- «Код разошёлся со спецификацией?» → ассистент сверит код с контрактом спецификации, как это делает шаг 8.

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

• Шаг 1 — требования: из семи слов рождается список: какие форматы нужны, кому и что НЕ входит в задачу. Самое ценное здесь — границы.
• Шаг 2 — исследование: что уже есть в кодовой базе и какие решения существуют? Возможно, экспорт уже наполовину реализован?
• Шаг 3 — ADR: архитектурное решение с альтернативами. Не «сделаем так», а «выбрали X, отвергли Y и Z, потому что…». Для L/XL план дополнительно проверяет challenge-panel — независимый проверяющий, который пытается найти слабые места в плане ДО написания кода.
• Шаг 4 — доменная модель: сущности и общий язык для их описания.
• Шаг 5 — архитектура: как решение встраивается в систему.

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

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

💬 Просто попроси.
- «Преврати мою идею в требования» → ассистент запустит шаг 1 и вернёт список требований с чёткими границами.
- «Проверь план с помощью challenge-panel» → ассистент передаст план challenge-panel — независимому проверяющему, который не участвовал в его составлении.

Неожиданная ситуация: на четвёртом часу выполнения функции уровня L сессия прерывается из-за лимита. Мира холодеет — неужели четыре часа работы конвейера пропали?

Нет. Конвейер сохранял долговечные контрольные точки — каждая затратная стадия (классификация, проектирование, план, код, QE) записывалась в features/<slug>/.fa-state/checkpoints.jsonl. Повторный запуск с тем же идентификатором возобновляет работу: завершённые стадии не вычисляются заново, а выполнение продолжается с места обрыва.

Чтобы возобновление сработало правильно, соблюдай два правила:

• Повторный вызов — с теми же аргументами. Контрольные точки привязаны к хэшу входных данных: изменишь уровень или описание — входные данные станут другими, и стадии будут пересчитаны.
• Вносила правки в код вручную во время работы над функцией? Укажи для resume значение «нет» (resume: 'never'): хэш проверяет входные данные запуска, а не содержимое дерева.

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

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

💬 Просто попроси.
- «Продолжи работу над функцией после обрыва» → ассистент перезапустит конвейер с тем же идентификатором, и resume использует готовые стадии.
- «Я правила код вручную, продолжи безопасно» → ассистент перезапустит конвейер с resume: never и заново проверит стадии.

Стоит задуматься над вопросом: если модель написала код, почему бы ей самой его не проверить? Она ведь лучше всех знает, что именно написала…

Именно поэтому этого делать нельзя. Модель проверит код на соответствие СОБСТВЕННОМУ пониманию задачи — и пропустит те же ошибки, которые сама допустила. Слепые зоны автора и проверяющего совпадут.

Правило шага 8 в feature-adr: межмодельная проверка (наш термин — кросс-модельное QE ревью) — код проверяет модель ДРУГОГО семейства. Писал Claude → проверяет Codex; писал Codex → проверяет Claude. Правило зависит от СЕМЕЙСТВА, а не от среды запуска: смена терминала не влияет на выбор проверяющей модели.

У шага 8 есть ещё три важных свойства, каждое из которых появилось после неудачного опыта:

• Вердикт разбирается автоматически, а не придумывается: пустой вывод проверяющей модели означает НЕ «замечаний нет», а то, что проверка не состоялась.
• Проверка предельно прямолинейна: оценка A–F и перечень замечаний вместо вежливого «всё отлично».
• Если проверяющая модель недоступна, система явно сообщает о переходе к запасному варианту и называет причину, а не незаметно заменяет независимую проверку самопроверкой.

Мира сначала расстраивалась из-за оценок C и D. Потом заметила: каждое замечание модели другого семейства — это ошибка, которая не дошла до рабочей системы.

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

💬 Просто попроси.
- «Пусть код проверит другая модель» → ассистент запустит шаг 8 с проверяющей моделью противоположного семейства.
- «Почему оценка C?» → ассистент распределит замечания из 08_qe_report.md по степени серьёзности.

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

• 08_qe_report.md — отчёт о межмодельной проверке на шаге 8: оценка, замечания и необходимые исправления;
• 09_fleet_qe_assessment.md — результаты fleet QE: на уровнях L/XL после одиночной проверки к работе приступает целая группа специализированных QE-агентов из agentic-qe — они создают тесты, анализируют покрытие и проверяют безопасность, причём каждый отвечает за своё направление.

Чем fleet QE отличается от шага 8? Шаг 8 — это один независимый проверяющий, который читает код. Fleet — команда узких специалистов, каждый из которых ВЫПОЛНЯЕТ свою проверку: запускает тесты, измеряет покрытие, ищет уязвимости. Проверяющий читает; fleet измеряет.

Режимы подключения agentic-qe:

1. Reference — без установки, только методология;
2. --full-qe — 9 базовых QE-навыков;
3. --full-qe-extended — все 15, включая расширенные.

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

Компромиссы: fleet QE — самый затратный шаг конвейера, поэтому он обязателен только на уровнях L/XL; для S/M расходы на него не окупаются.

💬 Просто попроси.
- «Покажи отчёт о качестве функции» → ассистент откроет 08_qe_report.md и 09_fleet_qe_assessment.md и перескажет замечания.
- «Повтори fleet QE» → ассистент запустит группу agentic-qe на текущем коде функции.

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

Главные из них:

• Сначала измерь, потом утверждай. Рядом с каждым числом должна быть команда, воспроизводящая результат. Утверждение без измерения проверку не проходит.
• Никаких «100%», пока измерение буквально этого не доказало.
• QE оценивает сам прогон, а не весь проект: учитывается то, что сделала ЭТА функция, а не общее состояние репозитория.
• Отсутствие ошибки — не успех. Молчание инструмента не превращается в зелёную галочку: необходимо явное подтверждение успешного результата.
• Свойство, названное в ADR, обязано иметь тест. Самое важное свойство проекта нередко оказывается самым непроверенным; шаг 8 явно требует теста для него.

Зачем это нужно лично тебе? Это метапознание в чистом виде: проверки служат внешней совестью, которая заставляет замечать, ГДЕ твоя уверенность опирается на измерение, а где — лишь на настроение.

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

💬 Просто попроси.
- «Проверь мой отчёт на честность» → ассистент найдёт утверждения без команды для воспроизведения результата и запросит измерение для каждого из них.
- «Есть ли тест на свойство из ADR?» → ассистент сопоставит названные в ADR свойства с реальными тестами, как это делает шаг 8.

Сначала условие, без которого этого раздела не существует. Самообучение конвейера работает только при установленном dz — запасного пути нет. Все три действия петли (поднять уроки, записать новые, подтвердить существующие) — это вызовы команд dz recall, dz teach и dz statusline --fa-record; сам конвейер живёт в песочнице без доступа к файлам и хранить ничего не умеет. Без dz фича всё равно будет сделана: шаги пройдут, артефакты появятся. Но прогон останется без памяти, без возобновления и без следов — каждый раз с чистого листа. Подробно о разделении ролей — в разделе «Вместе с dz»: конвейер это сценарий, dz это память, правила и приборы.

Теперь решение принимаешь ты: выбор слоёв самообучения зависит от проекта, и единственно правильного НАБОРА здесь нет. А вот порядок самого цикла строго определён, и упражнение ниже проверяет именно его:

1. Recall — на шаге 0 конвейер извлекает из хранилища шаблонов уроки прошлых запусков;
2. Добавление — лучшие найденные уроки включаются в требования и ADR как усвоенные шаблоны;
3. Сравнение — на шаге 8 возможные новые уроки сопоставляются с теми, которые уже были извлечены;
4. Teach или reinforce — действительно новый урок записывается, уже известный — усиливается, а не дублируется.

Поверх этого цикла можно подключать дополнительные слои: --with-learning добавляет обучение с вознаграждением (человеческая оценка контрольных точек превращается в сигнал), --knowledge-extractor — сбор знаний, пригодных для повторного использования. Правило одно: слои не конфликтуют, но хранилище должно быть ЕДИНЫМ — если разделить память между репозиториями, цикл перестанет накапливать знания.

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

Компромиссы: запись результатов самообучения почти не требует затрат, но хранилище нужно периодически упорядочивать; без чтения (recall) оно превращается в журнал, в который только записывают.

💬 Просто попроси.
- «Что конвейер уже узнал о нашем проекте?» → ассистент выполнит recall по хранилищу шаблонов и покажет главные уроки.
- «Включи обучение с вознаграждением» → ассистент добавит флаг --with-learning при следующем запуске.

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

Всё находится в features/<slug>/, а имена файлов пронумерованы по шагам:

• 00_complexity_assessment.md — решение классификатора сложности;
• 01_requirements.md, 02_research.md — требования и исследование;
• 03_adr/001-….md — архитектурные решения с альтернативами;
• 04_domain_model.md, 05_architecture.md — домен и архитектура;
• 06_implementation_plan.md — план;
• 07_code_changes/ — перечень изменений кода;
• 08_qe_report.md, 09_fleet_qe_assessment.md — отчёты о качестве.

Важно: сам код находится в кодовой базе, а features/<slug>/ содержит документацию по принятым решениям. Номер файла совпадает с номером шага, поэтому у вопроса «где посмотреть, почему выбрали X» всегда есть точный адрес: 03_adr/.

Частый вопрос из Troubleshooting (да, такие дополнительные заметки нужно читать обязательно): в монорепозитории с workspaces команда npx может не найти исполняемый файл пакета — помогает явное указание пути или запуск из корня.

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

💬 Просто попроси.
- «Покажи артефакты функции» → ассистент выведет структуру features/<slug>/ и состояние каждого файла.
- «Почему здесь выбрали такую архитектуру?» → ассистент откроет 03_adr/ и перескажет решение вместе с альтернативами.

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

Ответ — второе, и это принципиально. Адаптация конвейера под проект стоит на двух опорах.

Опора первая: онбординг команды. У пакета есть отдельный документ-проводник, который читается сверху вниз: установка → первая фича → механика спецификации → маршрутизация моделей → слои самообучения → работа с pull request в команде → частые вопросы. Он приезжает вместе с пакетом (node_modules/@dzhechkov/skills-feature-adr/docs/team-onboarding.md), поэтому у каждой установки он есть локально — даже без сети.

Установка в существующий проект не затирает чужое:

1. npx @dzhechkov/skills-feature-adr init — раскладывает конвейер рядом с тем, что уже есть;
2. при обновлении сравниваются три состояния — исходное, твоё и новое, — поэтому твои правки переживают обновление, а не гибнут под ним;
3. опасный шаг (например, повторное добавление существующей команды) выносится на подтверждение, а не выполняется молча.

Опора вторая: проект диктует конвейеру свои правила. Команда dz project-skills читает манифест репозитория и превращает его в подсказки для КАЖДОЙ стадии: продуктовое видение, критик, тон бренда, планка качества — плюс произвольные роли, которых требует именно этот проект. Конвейер остаётся тем же, но говорит на языке проекта. Команда только читает и ничего не меняет, а без манифеста прогон получается ровно таким же, как обычный, — байт в байт.

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

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

💬 Просто попроси. «Разверни feature-adr в этом проекте, ничего не затирая» → ассистент выполнит установку и покажет, что именно добавилось. «Какие правила этого репозитория должен учитывать конвейер?» → dz project-skills. «Дай документ для онбординга команды» → он лежит внутри пакета, ассистент его найдёт.

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

Первый поток: чекпоинты. После каждой дорогой стадии конвейер записывает её результат в журнал прогона. Смысл прямой: если сессия умерла на седьмом шаге, повторный запуск не начинает с нуля — он ВОЗОБНОВЛЯЕТ уже сделанное. Возобновление опирается на отпечаток входных данных: изменил задание — отпечаток другой, стадия честно пересчитывается заново.

Второй поток: обучающие пары. Каждая стадия дополнительно сохраняет тройку «вход → выход → оценка»: полный текст задания, каким его получила модель; то, что она вернула; и оценку качества с указанием, КТО оценивал. Плюс происхождение: модель, её семейство и роль. Это сырьё для будущего дообучения собственной модели — по одному файлу на стадию.

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

Теперь остановись и спроси себя: что из этого можно показывать посторонним?

Ответ неприятный и важный. Обучающие пары содержат ПОЛНЫЙ текст заданий — а значит, могут содержать код твоего целевого репозитория. Каталог с ними намеренно НЕ спрятан от системы контроля версий: это осознанное решение — спрятанное молча забывается, а видимое заставляет принять решение осознанно. Рядом лежит записка-предупреждение. Правило простое: перед тем как поделиться каталогом пар, посмотри, что в нём.

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

💬 Просто попроси. «Продолжи вчерашнюю фичу, не переделывая уже сделанное» → возобновление по чекпоинтам. «Кто выполнял проверку в том прогоне и почему?» → записи маршрутизации. «Собери, что накопилось для дообучения» → каталог обучающих пар (сначала проверь, что там нет чужого кода).

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

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

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

А если склад уже раскололся? Лечение — тот же перенос, что и в дневной работе:

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

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

Остановись и спроси себя: чем перенос уроков отличается от переноса телеметрии прогона? Тем, что телеметрия — это следы ОДНОГО прогона (что произошло), а уроки — обобщение поверх многих (что из этого следует). Первое отвечает «почему так вышло», второе — «как больше не наступать». Переносятся они разными командами и живут в разных местах.

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

💬 Просто попроси. «Запиши урок в наш основной склад, а не в этот репозиторий» → конвейер прибьёт запись к нужному корню. «Собери уроки из того проекта и влей к нам» → выгрузка и слияние. «Проверь, не появилось ли дублей после слияния» → сначала покажет, потом спросит.

Конвейер идёт долго: L-фича со всеми проверками — это часы. И Мира столкнулась с неприятным вопросом: как понять, что он идёт, а не завис?

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

Что в ней видно:

📐 adapters-emit-mcp-and-hooks · Step 8 QE · поднято 1 · записано 2 · подтверждено 2

• имя фичи — какой прогон идёт, если их несколько;
• шаг — где конвейер сейчас: «Step 8 QE» значит, что дизайн и код позади, идёт независимая проверка;
• поднято — сколько выученных уроков конвейер поднял ПЕРЕД стартом и учёл в дизайне;
• записано — сколько новых уроков он отложил по итогам;
• подтверждено — сколько существующих уроков получили подтверждение вместо создания дубля.

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

Кто это пишет. Ты — никто. Конвейер сам сообщает панели состояние на каждом шаге командой dz statusline --fa-record: он записывает свой шаг в отдельный файл, а панель его читает. Важная деталь устройства: у каждой фичи свой файл состояния. Это не мелочь — два конвейера, идущие одновременно, писали бы в один файл и затирали бы состояние друг друга; отдельный файл на фичу делает такое невозможным.

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

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

💬 Просто попроси. «Поставь панель» → dz statusline --install, дальше она работает сама. «На каком шаге прогон?» → достаточно взглянуть вниз экрана; за подробностями — dz workflow-trace.

Мира долго считала конвейер и командную строку разными инструментами: один делает фичи, другая ставит навыки. Пока не увидела, что происходит НА ГРАНИЦЕ между ними.

Что даёт связка. Конвейер — это последовательность шагов, но сам по себе он ничего не помнит и ничего не проверяет. Всё это приходит из dz:

• память — перед стартом конвейер поднимает выученные уроки (dz recall) и вплетает их в требования; по итогам записывает новые (dz teach);
• правила проекта — конвейер спрашивает у dz project-skills, какие соглашения действуют в этом репозитории, и говорит языком проекта, а не вообще;
• честные проверки — dz discrimination-check доказывает, что новый тест различает мир с фичей и без, а dz guard не пускает опасную правку;
• следы — чекпоинты, строка затрат, обучающие пары и живая панель прогона пишутся командами dz, а не самим конвейером.

Отсюда простое правило: конвейер — это сценарий, dz — это память, правила и приборы. Сценарий без них выполним, но каждый прогон начинается с чистого листа.

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

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

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

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

💬 Просто попроси. «Сделай фичу X с учётом наших прошлых граблей» → конвейер сам поднимет уроки перед стартом. «Почему он предложил именно такой дизайн?» → смотри поднятые уроки и правила проекта. «Запиши, что мы поняли на этой фиче» → запись уходит на общий склад, а не в текущий репозиторий.