Тема: Часть 20. Антипаттерны SDD
Уровень сложности: Средний
Расчётное время изучения: 4-6 часов (теория 2 часа, практика 2-4 часа)
Предварительные требования: Основы SDD (Specification-Driven Development) — части 1-5 курса
Понимание git, pull requests и базового CI/CD
Опыт работы с AI-ассистентами в разработке (Claude, GPT, Qwen и др.)
Базовое знание структуры проектов: package.json, requirements, тестирование
Цели обучения: Диагностировать минимум 8 антипаттернов SDD в реальном проекте по чек-листу из части 20
Применять конкретные техники исправления для каждого антипаттерна (например, разделение QWEN.md и specs/, введение факт-репро в validation.md)
Проводить ревью validation.md и выявлять иллюзии тестирования (тавтологии, зеркала, снапшот-обман)
Создавать устойчивый к /clear процесс, при котором новый агент может продолжить работу без истории чата
Формулировать объяснение PR своими словами, разграничивая ответственность человека и агента
Обзор: Эта часть курса — диагностическая карта для SDD-процессов, которые стали тяжёлыми, шумными или бесполезными. Антипаттерн в SDD выглядит как правильный процесс (файлы на месте, проверки проходят, агент работает быстро), но постепенно отнимает у человека контроль над проектом. Материал охватывает 14 конкретных антипаттернов: от спецификации после кода и гигантских requirements.md до галлюцинаций в коде агента и иллюзий тестирования. Каждый антипаттерн снабжён симптомами, объяснением вреда и пошаговым исправлением. Финальный диагностический чек-лист из 8 вопросов позволяет быстро оценить здоровье процесса: при трёх отрицательных ответах рекомендуется упрощение вместо добавления новых инструментов.
Ключевые концепции: Спецификация после кода: Антипаттерн, при котором агент сначала реализует фичу, а потом дописывает requirements.md, plan.md и validation.md под готовый код. Спецификация превращается в отчёт вместо инструмента направления. Исправление: коммитить черновую спецификацию до реализации, запрещать продуктовый код в сессии создания спецификации, в PR явно показывать коммит спецификации до коммита реализации.
Гигантский requirements.md: Один файл требований содержит десятки пунктов, несколько сценариев, будущие фазы и спорные решения. Агент начинает сам выбирать приоритеты, человек теряет границы. Исправление: дробить на фазы, выносить будущее в roadmap.md, оставлять только текущую ветку, спорные решения помечать как вопросы.
Незапущенный validation.md: В проверке красивые факты, но нет следов их выполнения. Создаёт ложное чувство готовности. Исправление: хранить команду/сценарий рядом с каждым фактом, требовать от агента список пройденных/проваленных/непроверенных фактов, не считать факт подтверждённым без воспроизводимости.
Ослабление фактов после ошибки: Тест упал — агент меняет ожидаемый результат в validation.md вместо кода. Процесс защищает реализацию агента, а не намерение продукта. Исправление: требовать показать расхождение без правок, ревьюить изменения validation.md особенно внимательно, сохранять причину изменения, запрещать удаление обязательных фактов без решения человека.
Ритуальный /clear: Команда /clear вызывается между фазами, но после неё агент получает длинное объяснение из чата. Видимость проверки переносимости при фактической зависимости от памяти человека. Исправление: после /clear давать только ссылки на файлы, проверять понимание новой сессией, дописывать спецификации вместо расширения промпта.
Навык как магическая кнопка: Команда зовёт навык Qwen Code, но никто не читает SKILL.md и не понимает его решения. Навык становится скрытым процессом. Исправление: хранить проектные навыки в репозитории, ревьюить SKILL.md как процессный код, писать ограничения, не создавать навык до 2–3 повторений ручного процесса.
Qwen.md как свалка: В QWEN.md складывают продуктовые требования, стек, личные предпочтения, временные задачи и заметки по ошибкам. Агент перестаёт отличать постоянные правила от временного контекста. Исправление: продуктовые решения в specs/, правила поведения в QWEN.md, временные выводы в память или ретроспективу, регулярная чистка устаревшего.
Хук, который молча меняет проект: Хук форматирует, переписывает или удаляет файлы без явного шага в плане. Изменения вне контроля агента и человека. Исправление: хуки по умолчанию проверяют или логируют, форматирование только как явное командное правило, все изменения в git diff, при блокировке — объяснение причины.
Память как скрытый источник истины: Агент принимает решения на основе памяти, но их нет в specs/, QWEN.md или AGENTS.md. Новые участники не видят основания решений. Исправление: память = подсказка, не правило; переносить повторяющиеся выводы в ревьюируемые файлы; удалять устаревшую память; в споре память vs спецификация — выбирать спецификацию.
Mcp без задачи: К проекту подключают MCP-серверы «на будущее». Агент получает лишние полномочия, команда не понимает возможные внешние действия. Исправление: подключать только под конкретный сценарий, ограничивать инструменты, хранить конфигурацию в ревьюируемом месте, отключать экспериментальные серверы после проверки.
Слишком большой mvp: Первая версия включает авторизацию, роли, аналитику, интерфейс, миграции, импорт, интеграции. Агент быстро создаёт много файлов, человек не успевает оценить качество. Исправление: первая фаза доказывает один риск, ограничение по времени, возврат к последнему зелёному состоянию при расползании, добавление функций только после проверяемых фактов.
Галлюцинации в коде агента: Агент уверенно ссылается на несуществующие функции, методы, пакеты. Особенно опасны несуществующие имена пакетов (атака slopsquatting: атакующий регистрирует похожее имя, npm install тянет вредоносный код). Исправление: список разрешённых зависимостей в tech-stack.md, отдельный шаг ревью для добавления зависимостей, сверка версий при первой ошибке, визуальная проверка имён пакетов, требование ссылки на определение при ссылке на новую функцию.
Иллюзии тестирования: npm test зелёный, но баг остаётся. Подвиды: тавтологический тест (сравнивает с тем же выражением), тест-зеркало (проверяет, что вернуло, без независимого ожидания), обман через снапшот (ошибка фиксируется в снапшоте как «правильная»), тест, который не падает ни при какой ошибке. Исправление: факт-репро в validation.md, чтение самих тестов при ревью, мутационное тестирование (Stryker для Vitest), запрет снапшотов для бизнес-логики.
Разработчик не понимает свой pr: Автор PR не может объяснить решение, пересылает ответы агента. Ответственность размывается, будущее обслуживание невозможно. Исправление: правило — автор объясняет PR своими словами, ревьюер задаёт вопрос с ответом только у человека, поощрение «парного SDD», перечитывание git diff и формулирование «я сделал X, потому что Y».
Практические упражнения: Название: Диагностика репозитория по чек-листу
Проблема: Вам дан доступ к репозиторию проекта, который использует SDD 3 месяца. Проведите диагностику по 8 вопросам из чек-листа части 20. Для каждого отрицательного ответа: укажите конкретный антипаттерн, найдите доказательство в репозитории (коммит, файл, PR), предложите исправление с примером нового состояния. Репозиторий содержит: requirements.md на 200 строк с пометками 'фаза 2' и 'обсудить', validation.md с фактами без команд, QWEN.md с продуктовыми решениями и личными предпочтениями, хук pre-commit, который автоформатирует код, 3 MCP-сервера в конфигурации, из которых 2 не используются в текущих задачах.
Решение: 1. Вопрос 1 (спецификация после кода): Проверяем git log --oneline -- requirements.md plan.md validation.md — файлы коммичены после реализации. Антипаттерн: 'Спецификация после кода'. Исправление: git rebase -i с перестановкой коммитов, в CONTRIBUTING.md правило: спецификация до реализации. 2. Вопрос 3 (QWEN.md vs specs/): В QWEN.md найдены 'используем PostgreSQL' (продуктовое) и 'не используй await в циклах' (правило поведения). Антипаттерн: 'QWEN.md как свалка'. Исправление: перенос 'PostgreSQL' в specs/architecture.md, оставление только правил агента в QWEN.md. 3. Вопрос 4 (хуки): pre-commit изменяет файлы без шага в plan.md. Антипаттерн: 'Хук, который молча меняет проект'. Исправление: замена на проверочный хук, форматирование через явную команду npm run format в CI. 4. Вопрос 5 (MCP): 2 неиспользуемых сервера. Антипаттерн: 'MCP без задачи'. Исправление: удаление из конфигурации, комментарий с датой эксперимента и решением. 5. Вопрос 7 (/clear): Проверка — создать новую сессию, дать только ссылки на файлы, проверить понимание задачи. Если не понимает — дописать specs/current-task.md. Итого 4 отрицательных ответа — требуется упрощение процесса перед добавлением новых инструментов.
Сложность: intermediate
Название: Ревью validation.md с выявлением иллюзий
Проблема: Вам прислали validation.md и тесты для фичи 'расчёт скидки'. Тесты проходят (покрытие 95%). Найдите иллюзии тестирования: (1) test('скидка 10%', () => expect(calcDiscount(100, 10)).toBe(100 * 0.9)); (2) test('скидка работает', async () => { const result = await calcDiscount(200, 20); expect(result).toBe(result); }); (3) snapshot-тест для функции форматирования цены; (4) test('не падает', () => { expect(() => calcDiscount('abc', 'def')).not.toThrow(); }). Для каждого: классифицируйте подвид иллюзии, объясните, какой баг останется незамеченным, перепишите тест корректно.
Решение: (1) Тавтологический тест: 100 0.9 — то же выражение, что внутри функции. Баг: если функция просто возвращает price (100 - percent) / 100, переименование переменной сломает, но логика не проверена. Корректно: const expected = 90; expect(calcDiscount(100, 10)).toBe(expected); + отдельный тест на граничные значения (percent = 0, 100, 101). (2) Тест-зеркало: expect(result).toBe(result) всегда true. Баг: любой результат считается верным, включая undefined, null, ошибку расчёта. Корректно: жёстко задать expected = 160; + проверка типа. (3) Обман через снапшот: первый запуск создал снапшот с ошибкой. Баг: форматирование '1 000,00' vs '1 000.00' зафиксировано как правильное и не проверяется. Корректно: явные expect с локалью, запрет снапшота для бизнес-логики. (4) Тест, который не падает ни при какой ошибке: единственное утверждение — не выбросить. Баг: функция возвращает NaN, null, строку 'NaN' — тест зелёный. Корректно: проверка валидных входов отдельно, проверка ошибок — expect().toThrow() с конкретным сообщением. Дополнительно: добавить факт-репро в validation.md — команда, которая до фикса падала (например, calcDiscount(-10, 10) возвращал отрицательную цену).
Сложность: intermediate
Название: Преобразование 'свалки' QWEN.md в структурированный процесс
Проблема: Дан QWEN.md из реального проекта (фрагмент): '# QWEN.md\n\n## Продукт\nМы делаем CRM для стоматологий. Основной экран — календарь приёмов.\n\n## Стек\nReact 18, Node 20, PostgreSQL 15.\n\n## Мои предпочтения\nЯ терпеть не могу async/await в циклах, пиши через Promise.all.\n\n## Временно\nБаг #234: пока не чиним, клиент согласен.\n\n## Ошибка 15 марта\nАгент использовал lodash, хотя мы отказались. Больше не использовать.\n\n## Правила агента\n- Всегда пиши тесты перед кодом\n- Не меняй package.json без спроса'. Преобразуйте в правильную структуру: разделите по назначению, укажите, куда перенести каждый блок, какие правила устарели и подлежат удалению, какие требуют регулярного ревью.
Решение: Структурирование по правилам части 20: 1. 'Продукт' + 'Стек' → specs/product.md и specs/tech-stack.md (продуктовые решения не в QWEN.md). 2. 'Мои предпочтения' → удалить или преобразовать в объективное правило: 'Предпочитай параллельное выполнение независимых операций через Promise.all, если порядок не важен' — в QWEN.md как правило поведения агента. Личное 'терпеть не могу' — неприемлемо. 3. 'Временно: Баг #234' → перенести в ретроспективу или память с датой истечения, удалить из QWEN.md через 2 недели после закрытия. 4. 'Ошибка 15 марта' → если правило актуально ('не использовать lodash'), перенести в specs/dependencies.md с обоснованием; если агенты больше не допускают — удалить как устаревшее. 5. 'Правила агента' — оставить в QWEN.md, дополнить: 'Всегда пиши тесты перед кодом' → уточнить 'Следуй TDD: факт в validation.md → тест → реализация'. 'Не меняй package.json без спроса' → усилить: 'Добавление зависимости — отдельный шаг с ревью tech-stack.md'. Ревью: QWEN.md ревьюить ежемесячно, specs/ — при изменении архитектуры, память — еженедельно на чистку.
Сложность: intermediate
Название: Построение устойчивого к /clear процесса
Проблема: Вы работаете над фичей 'интеграция с платёжной системой' 2 недели. История чата содержит 50+ сообщений с уточнениями, отклонениями от плана, компромиссами. Завтра в проект приходит новый разработчик (и новый агент). Создайте минимальный набор файлов, который позволит продолжить работу после /clear без пересказа из чата. Учтите: текущая фаза — тестирование webhook'ов, известная проблема — sandbox отвечает 202 вместо 200, принятое решение — ретраи с экспоненциальной задержкой (не в спецификации изначально).
Решение: Создаём файлы: 1. specs/payment-integration/current-phase.md: 'Фаза 3.3: Тестирование webhook\'ов. Статус: в процессе. Блокер: sandbox возвращает 202 вместо документированного 200. Решение: ретраи с экспоненциальной задержкой (max 5 попыток, base delay 1s, multiplier 2). Решение принято 2024-01-15, причина: sandbox-окружение платёжной системы несовместимо с документацией, продакшен не затронут. Следующий шаг: валидация ретраев под нагрузкой.' 2. specs/payment-integration/decisions.md: запись о решении с контекстом, альтернативами (ожидание фикса от платёжки — отклонено, т.к. срок неизвестен), подпись человека. 3. validation.md: обновить факт 'Webhook обрабатывает 202 от sandbox' с командой curl для воспроизведения + факт 'Ретраи не превышают 30s суммарно' с нагрузочной командой. 4. QWEN.md: добавить правило 'При интеграциях с внешними API: документировать расхождения с документацией в specs/<integration>/discrepancies.md'. 5. Проверка: новая сессия получает только ссылки на эти 4 файла + задачу 'продолжить фазу 3.3'. Если агент предлагает изменить ретраи без чтения decisions.md — процесс не устойчив, требуется усиление спецификации.
Сложность: advanced
Кейсы: Название: Крах MVP: когда агент построил слишком много за 48 часов
Сценарий: Стартап в области EdTech заказал разработку платформы для онлайн-курсов. Запрос: 'MVP за 2 недели — регистрация, просмотр курсов, базовая аналитика для преподавателей'. Агент (Claude Code с доступом к большому контексту) сгенерировал за 48 часов: полноценную авторизацию с ролями (админ, преподаватель, студент, гость), систему прав доступа на уровне полей, дашборд аналитики с 12 виджетами, миграции данных из CSV, интеграцию с SendGrid и Stripe. Всё 'работало' — npm test зелёный, 150+ файлов, 80% покрытие.
Задача: Основатель не смог объяснить, как работает система прав: 'Агент сказал, что так надёжнее'. При первой реальной нагрузке (20 одновременных регистраций) обнаружились: race condition в проверке уникальности email, отсутствие транзакций в критичных операциях, 'аналитика' считала метрики на клиенте по полной выборке. Покрытие 80% оказалось иллюзией — тесты проверяли существование функций, не их корректность. Попытка исправить одну ошибку ломала три других из-за скрытых зависимостей. Проект ушёл на полный переписывание через 6 недель.
Решение: Применение антипаттернов части 20: 1. 'Слишком большой MVP' — первая фаза должна доказывать один риск. В данном случае: можно ли быстро создать и отобразить курс? Всё остальное — последующие фазы. 2. 'Иллюзии тестирования' — внедрение факт-репро: каждый факт в validation.md сопровождался командой, которая до фикса падает. Мутационное тестирование (Stryker) выявило, что 60% 'покрытых' тестов не ловят мутации. 3. 'Разработчик не понимает свой PR' — введено правило: основатель обязан объяснить PR своими словами, иначе слияние блокируется. 4. 'Спецификация после кода' — переписывание началось с черновой спецификации 'один курс, один пользователь, одна страница'.
Результат: Переписанный MVP (фактически 'nano-MVP') — регистрация через email, создание курса с текстом, просмотр списка — был готов за 3 дня с 12 файлами. Основатель понимал каждое решение. Фаза 2 (аналитика) открыла, что первоначальные 12 виджетов не нужны: преподаватели просили только 'сколько студентов начало и закончило'. Общее время до первого платящего пользователя сократилось с 10 недель до 4, стоимость поддержки — в 8 раз ниже.
Извлечённые уроки: Покрытие кода числом — метрика иллюзии, если тесты не проверяют поведение. Мутационное тестирование обязательно для критичных путей.
Агент может создать 'работающий' проект, который человек не способен поддерживать. Контроль человека измеряется способностью объяснить PR, не скоростью генерации кода.
MVP — это эксперимент по проверке риска, не мини-версия полного продукта. Каждая фаза должна иметь один измеримый риск и факт его проверки.
Связанные концепции: Слишком большой MVP
Иллюзии тестирования
Разработчик не понимает свой PR
Спецификация после кода
Название: Атака slopsquatting: когда галлюцинация агента стала уязвимостью
Сценарий: Команда из 5 разработчиков использовала SDD для микросервиса обработки документов. Агент предложил библиотеку для парсинга PDF — 'pdf-parse-pro' вместо известного 'pdf-parse'. Разработчик не проверил имя глазами, npm install сработал, тесты прошли (агент написал заглушки для недостающих методов). Пакет оказался вредоносным: при парсинге документов выше 10 MB отправлял содержимое на внешний сервер. Обнаружено через 3 недели после деплоя в production.
Задача: Уязвимость возникла на стыке двух антипаттернов: 'Галлюцинации в коде агента' (несуществующий пакет, похожий по имени на реальный) и 'Иллюзии тестирования' (заглушки агента маскировали отсутствие реальной функциональности). Стандартный процесс SDD не предусматривал отдельного ревью зависимостей — они добавлялись как часть 'реализуй фичу'. tech-stack.md существовал, но не содержал списка разрешённых зависимостей.
Решение: Внедрение многоуровневой защиты по части 20: 1. tech-stack.md — явный список разрешённых зависимостей с версиями, обоснованием и альтернативами. 2. Добавление зависимости — отдельный шаг ревью, аналогичный изменению архитектуры. 3. Визуальная проверка: имя, отличающееся от привычного одной буквой — стоп-сигнал, требуется поиск в официальном реестре и проверка загрузок/возраста. 4. При первой ошибке типов или рантайма — обязательная сверка с package.json и проверка существования пакета. 5. Интеграция с Snyk и npm audit в CI, блокирующая PR при новых зависимостях без ревью.
Результат: После внедрения за 6 месяцев: 2 попытки добавления похожих имён ('expresss' вместо 'express', 'lodash-es-extra') заблокированы на этапе CI. Время на добавление легитимной зависимости увеличилось с 0 до 15 минут (обсуждение необходимости). Сокращение 'теневых' зависимостей на 40%. Команда осознанно отказалась от 3 'удобных' пакетов в пользу встроенных решений Node.js.
Извлечённые уроки: Галлюцинации агента — не просто ошибки качества кода, а вектор безопасности. Имена пакетов требуют такой же строгости, как секреты и доступы.
Заглушки агента для несуществующих API создают ложное чувство работоспособности. Тест должен падать до реализации, иначе это не TDD, а самообман.
Процесс 'отдельный шаг ревью для зависимостей' кажется избыточным, пока не столкнёшься с инцидентом. Оптимальная частота ревью — не нулевая, а осознанная.
Связанные концепции: Галлюцинации в коде агента
Иллюзии тестирования
Навык как магическая кнопка
MCP без задачи
Название: Восстановление контроля после 'ритуального /clear'
Сценарий: Команда из 2 человек (техлид и продуктолог) разрабатывала инструмент визуализации данных за 4 месяца. Процесс 'работал': /clear каждые 3-4 дня, затем 10-минутный пересказ контекста в чате. При уходе техлида в отпуск продуктолог попытался продолжить с новым агентом. Новая сессия не поняла: какая фаза активна, почему выбран тот или иной формат данных, какие компромиссы приняты. 2 недели ушли на восстановление контекста, проект заморозился.
Задача: Корневая проблема: /clear использовался как 'ритуал очищения', но процесс полностью зависел от памяти техлида в чате. Никакие решения, компромиссы, отклонения от плана не фиксировались в ревьюируемых файлах. Антипаттерны: 'Ритуальный /clear', 'Память как скрытый источник истины', частично 'QWEN.md как свалка' (временные выводы накапливались в памяти агента).
Решение: Радикальное преобразование по части 20: 1. После /clear — только ссылки на файлы, никаких 'напоминаний' из чата. 2. Внедрение specs/decisions/ с шаблоном: контекст, рассмотренные варианты, выбранное решение, причина, дата, подпись. 3. Каждая фаза — отдельный specs/phase-N.md с текущим статусом, блокерами, следующим шагом. 4. Проверка переносимости: каждую неделю один разработчик начинал новую сессию с /clear и только файлами, проверяя понимание задачи. 5. Память агента — периодическая чистка, повторяющиеся выводы мигрировали в specs/ или QWEN.md.
Результат: Через 3 месяца: новый разработчик вошёл в проект за 2 часа (чтение specs/decisions/ + текущей фазы), вместо 2 недель. Отпуск техлида больше не блокировал проект. Обнаружен побочный эффект: записанные решения позволили отклонить 40% предложений агента как 'уже рассмотрено и отклонено по причине X'. Скорость разработки снизилась на 15% (время на документирование), но предсказуемость выросла на порядок.
Извлечённые уроки: /clear — инструмент агента, не процесса. Процесс устойчив, если новая сессия понимает задачу из файлов, не из чата человека.
Память агента ценна как подсказка, но опасна как правило. Повторяющиеся выводы обязаны мигрировать в ревьюируемые файлы.
Запись решений 'замедляет' разработку, но 'ускоряет' масштабирование команды и снижает зависимость от конкретных людей.
Связанные концепции: Ритуальный /clear
Память как скрытый источник истины
QWEN.md как свалка
Разработчик не понимает свой PR
Советы по изучению: Проходите материал последовательно, но после каждого антипаттерна делайте паузу и проверяйте свой текущий проект — диагностика в реальном контексте закрепляет лучше, чем теория
Ведите 'антидневник': для каждого обнаруженного антипаттерна в вашей практике записывайте конкретный файл/коммит/PR, исправление, и дату проверки через месяц
Изучайте парно с коллегой: один находит антипаттерн, другой проверяет, действительно ли это он, или ложное срабатывание — развивает критическое мышление
Используйте финальный чек-лист как еженедельную рутину, не как разовую диагностику; установите напоминание в календаре
Для визуалов: создайте mind-map с 14 антипаттернами, связями между ними (например, 'ритуальный /clear' → 'память как источник истины') и вашими проектными примерами
Для практиков: не пытайтесь исправить все антипаттерны сразу; выберите 3 с наибольшим негативным воздействием по вашему чек-листу, внедрите за неделю, затем следующие
Для аудиалов: проговаривайте вслух объяснение каждого PR перед слиянием — если 'я сделал X, потому что Y' не складывается, PR не готов
Дополнительные ресурсы: Часть 16 курса (ревью антипаттернов): Те же ошибки с позиции ревьюера: как поймать антипаттерн в чужом pull-запросе
Часть 18 курса (безопасность): Антипаттерны, которые одновременно являются угрозами безопасности: секреты в спецификациях, MCP без ревью, ослабление validation.md
Часть 9 курса (матрица фактов): Матрица «тип фичи → уровень фактов», которая прямо лечит антипаттерн «слабый validation.md»
Часть 22 курса (парный sdd): Паттерн «один пишет спецификацию, второй ревьюит до реализации» — профилактика 'разработчик не понимает свой PR'
Stryker mutator (для vitest): Инструмент мутационного тестирования для выявления иллюзий тестирования — https://stryker-mutator.io/
Npm audit и snyk: Инструменты для автоматической проверки зависимостей, дополнение к ручному ревью имен пакетов
Приложение c курса (шаблон pr): Шаблон описания PR с требованием объяснения своими словами
Резюме: Антипаттерны SDD — это привычки, которые выглядят как правильный процесс, но ломают результат. Ключевое отличие от обычных ошибок: файлы на месте, проверки проходят, агент работает быстро, но человек постепенно теряет контроль. Часть 20 предоставляет диагностическую карту из 14 антипаттернов: от спецификации после кода и гигантских requirements.md до галлюцинаций в коде агента и иллюзий тестирования. Каждый антипаттерн имеет чёткие симптомы, объяснение вреда и конкретное исправление. Финальный чек-лист из 8 вопросов позволяет быстро оценить здоровье процесса: при трёх отрицательных ответах правило простое — не добавлять новые инструменты, а упрощать процесс. Главный принцип: SDD работает, когда агент направляется спецификацией, а не подменяет её; когда человек понимает свой PR, а не пересылает ответы агента; когда новая сессия после /clear продолжает работу из файлов, а не из памяти чата.