codemonsters.log

Смотри, какая красота. Коммит: Human Gate 1. Что сделал Харнес? Оператору нужно принять дизайн и план работ. Тикеты мне тоже нравятся. Gate 1: Проверка плана работ. В ветке содержание работы. https://github.com/codemonstersteam/pinout-openapi/tree/docs/concept-mechanism-consistency Изначально была задача: https://github.com/codemonstersteam/pinout-openapi/blob/docs/concept-mechanism-consistency/TASK.md Проработка идеи: https://github.com/codemonstersteam/pinout-openapi/blob/docs/concept-mechanism-consistency/docs/CONCEPT.md Далее эмуляция и вывод алгоритма, чтобы понять, как это будет работать и будет ли работать: https://github.com/codemonstersteam/pinout-openapi/blob/docs/concept-mechanism-consistency/sandbox/ALGORITHM.md Попросил машину провести эксперимент, чтобы убедиться, что идея и процесс рабочие. #codemonsterslog

Привет! Подготовил интересные материалы, которые помогут тебе отправиться в невероятное и увлекательное путешествие в разработку AI-агентов. Сразу бросилась в глаза модульность — прямо как в 70-х рекомендовали отцы-основатели из IBM: головной модуль и подчинённые. Эта дисциплина прекрасно ложится в проектирование и реализацию с тестами в агентском режиме Понравилось, что с гардрейлами получилось организовать процесс работы агента и субагентов по заданному алгоритму и держать творческую вариативность в узде. Одна ответственность, малый консистентный контекст, чёткие контракты в сообщениях: что на вход, что на выход — с контролем входных и выходных данных. The anatomy of a skill. И получается фантастическое изделие из конечных и вариативных автоматов. Ссылки: Architecture Patterns and Implementation Frameworks A practical guide to building agents Мех и человеческие проверки: 1. Гардрэйлс (хуки, live-блок) — harness/enforcement/ + чистая логика shared.mjs: - claude → PreToolUse/PostToolUse хуки; opencode → TS-плагин tool.execute.before/after - enforce: closed-set роутинг, фронтдор (@gilb первый), Gate #1 (реализатор заблокирован без plan-review.md+gate1.approved), decisions.log - exit 2 = блок, без участия модели; fail-open на инфра-сбое 2. Валидаторы (DoD-гейты) — 15× validate-*.mjs (plan/tickets/dod/readme/mermaid/slices/constructors/contract-frozen/…); вызывают роли + CI; детерминированно, без LLM 3. Человеческие гейты — маркеры .agent/gates/ (#1 план, #2 мерж, #3 канарейка), ставит оператор Евалс (eval-run/eval-judge.mjs) — не контроль, а пост-хок оценка прогона (A/B). Суть: контроль = хук + детерминированный чек, а не проза-инструкция («проза не держит — держит хук»). GL HF DD #codemonsterslog

Привет! Подготовил интересные материалы, которые помогут тебе отправиться в невероятное и увлекательное путешествие в разработку AI-агентов. Сразу бросилась в глаза модульность — прямо как в 70-х рекомендовали отцы-основатели из IBM: головной модуль и подчинённые. Эта дисциплина прекрасно ложится в проектирование и реализацию с тестами в агентском режиме Понравилось, что с гардрейлами получилось организовать процесс работы агента и субагентов по заданному алгоритму и держать творческую вариативность в узде. Одна ответственность, малый консистентный контекст, чёткие контракты в сообщениях: что на вход, что на выход — с контролем входных и выходных данных. The anatomy of a skill. И получается фантастическое изделие из конечных и вариативных автоматов. Ссылки: Architecture Patterns and Implementation Frameworks A practical guide to building agents Мех и человеческие проверки: 1. Гардрэйлс (хуки, live-блок) — harness/enforcement/ + чистая логика shared.mjs: - claude → PreToolUse/PostToolUse хуки; opencode → TS-плагин tool.execute.before/after - enforce: closed-set роутинг, фронтдор (@gilb первый), Gate #1 (реализатор заблокирован без plan-review.md+gate1.approved), decisions.log - exit 2 = блок, без участия модели; fail-open на инфра-сбое 2. Валидаторы (DoD-гейты) — 15× validate-*.mjs (plan/tickets/dod/readme/mermaid/slices/constructors/contract-frozen/…); вызывают роли + CI; детерминированно, без LLM 3. Человеческие гейты — маркеры .agent/gates/ (#1 план, #2 мерж, #3 канарейка), ставит оператор Евалс (eval-run/eval-judge.mjs) — не контроль, а пост-хок оценка прогона (A/B). Суть: контроль = хук + детерминированный чек, а не проза-инструкция («проза не держит — держит хук»). GL HF DD #codemonsterslog

⬆️Разработал инструмент, который реализует четкий конвейер разработки API сервиса на Go или CLI. Этот инструмент делает то, что мне нужно по требованию, единообразно, четко и правильно, следуя научному подходу, а не просто потому, что так принято в интернете или на GitHub. Пришла пора писать видосы. https://github.com/codemonstersteam/rationaldev-ai-sdlc-skills Результат работы workflow: https://github.com/codemonstersteam/pinout-openapi/tree/main Сам harness, я и тестирую, и провел уже сотни тестов на золотой задаче создания сервиса. Тестил в том числе на glm 5.2, qwen 3.6-2.6b Важно: Еще много работы и улучшений Но процесс предсказуемый с единообразными артефактами #codemonsterslog

Тестирую workflow по разработке сервиса. Задачу перед собой поставил такую: хочу, чтобы агент или связка агентов: 1. Прожаривал требования; 2. Отдавал их агенту, и тот по постановке решал задачу согласно прописанному фреймворку и требованиям к архитектуре и качеству. В результате двух недель экспериментов с golden task workflow подход работает стабильно. В экспериментах используются GLM 5.2 для проработки плана, архитектуры и нарезки тикетов, а Qwen3.6‑27b — для реализации тикетов. Вывод: С вариативными GPT workflow прекрасно работает. Это конвейер где синтетическое творчество варится в дисциплине и четкой последовательности действий. Я не могу пока раздувать вывод эмоциональным всплеском ;)) 2 недели 20+ прогонов Несколько поздних ночных сессий. Результат меня удовлетворяет, узнал много нового. Вывод 2: эксперименты очень важны, экспериментируй и воплощай то, что тебе очень интересно. #codemonsterslog #ai #agents

Навёл порядок в скилл-харнесе для рационального SDLC с ИИ. Что сделал: 🔹 Оптимизировал все 18 скиллов — привёл каждый к ≤300 строкам. Часть со временем разбухла; вырезал дубли и воду, правила свёл к нормативным. Суть не потерял — гейты, формулы, чеклисты на месте. 🔹 Перевёл на английский. Не из эстетики — по замерам экономит токены (−29% по набору, 63k → 45k). Английский плотнее в токенайзере, а скилл-нагрузка грузится в каждый вызов роли. 🔹 Заострил роль планировщика — добавил сбор требований. Раньше дизайн стартовал «от одной фразы». Теперь есть фронт requirements-intake: бизнес-требование → функциональные требования (use-cases по Кокберну), акторы, интерфейсы, контракт API, карта отказов. Спрашиваешь харнес «с чего начать?» в пустом проекте — он ведёт именно сюда. По-моему, вышло достойно. https://github.com/codemonstersteam/rationaldev-ai-sdlc-skills

Собираю все скиллы в удобный пак заодно решил проверить какой будет эффект при переводе на английский тесты показали - эффект будет положительный #codemonsterslog

🙏Собрал развернутое саммари сессии митапа 🔌 pinout: спроектировали валидатор OpenAPI-контрактов и попутно прокачали свои скиллы разработки На этой сессии проектировали инструмент, который на pre-merge стадии в CI проверяет, что потребитель REST-сервиса совместим с прод-контрактом поставщика — сравнением их OpenAPI-спек. Без генерации клиентских либ, без подъёма заглушек: чистая функция «спека vs спека». 🔗 Экосистема: https://github.com/codemonstersteam/pinout 🔗 Сам валидатор: https://github.com/codemonstersteam/pinout-openapi Что зацепило больше всего 📐 Системные use case по Коберну. Оказалось, что fully-dressed use case (акторы, предусловия, основной сценарий, extensions = режимы отказа, гарантии/exit) — это не «бумажка для галочки», а рабочая спецификация. Структура use case изоморфна Gherkin: Main Success → happy-тест, каждый Extension → один сценарий отказа. Формула сошлась сама собой: N сценариев = 1 + число extensions. 🗺 C4 как уровни дизайна. Разложили проект по уровням C4 на Mermaid (рендерится прямо в GitHub): • C1 (контекст экосистемы) — в концепт-репо • C2 + C3 (контейнер + дерево модулей) — в компоненте • C4 = тот самый системный use case «как работает программа» 📄 Живой пример: https://github.com/codemonstersteam/pinout-openapi/blob/main/docs/design/contract-validate/c4.md Главный инсайт — это всё прошивается в систему Получилась сквозная трассировка: use case (Cockburn) → вертикальный слайс → компонентный тест → узлы графа контрактов. 1 слайс = 1 внешний вход = 1 use case. Ничего не выдумывается из кода — каждый компонентный тест выводится из соответствующего extension use case, с двусторонней сверкой (нет extension без теста и нет теста без extension). Как мы доработали скиллы разработки По следам сессии внесли правки прямо в процедуры скиллов (не в «когда-нибудь потом»): ✅ documentation — обязательные C4-диаграммы по уровням, системный use case как C4-уровень, таблица сбоев в README, gate: документация только по скиллу (никакой свободной прозы мимо процедур) ✅ program-design — C4 по уровням, модель ошибок (коды → exit, «деградация видна, не маскируется под успех»), трассировка UC→слайс→тест, conformance-gate (STOP перед хендоффом) ✅ component-tests — режимы отказа берутся из extensions use case ✅ роль plan-reviewer — асимметричная проверка соответствия дизайна скиллу Плюс зашили несколько жёстких правил в скилл проектирования: • Один внешний вход = один Request. Все параметры (включая флаги CLI) собираются в единый Request; флаг — это поле Request, а не отдельный аргумент или «прокинутый сбоку» io.Writer. Внешний ввод парсится только в адаптере. • Развилки по флагам — это юниты, а не компонентные тесты. Выбор «куда писать» (--out) и «в каком формате» (--format) оформляется чистой функцией (resolveDestination, renderReport) и покрывается юнит-тестами. В компонентные сценарии идёт только режим отказа записи — иначе матрица stdout/файл × json/md раздувает число сценариев. • Запрет «тестового» второго метода I/O (WriteTo(io.Writer) рядом с боевым Write) — решение выносится в логику, лишний шов не заводится. Вывод сессии: use case по Коберну + C4 + вертикальные слайсы — это один связный конвейер, а не три отдельные практики. Когда они сшиты, дизайн перестаёт расходиться с тестами и кодом by design. #codemonstersvlog #разработка #архитектура #C4 #UseCase #OpenAPI

🛠 На митапе: — Спроектировали pinout-openapi (C4: С1 в pinout, C2-C3 — в openapi). — Обновили README. — Гульнара помогла с Use Case'ами (Cockburn), документация стала чётче. ⚠️ Выявили риски со сборкой OpenApi и $ref — вынесли в таблицу. Решили не усложнять, сначала проверим в деле. 📌 План: допрограммируем по дизайну, на след. митапе (вторник) протестируем на проекте. Получилось достойно. Давно собирался затащить c4. Скиллы доработаны 🧸 👋 Что ещё улучшить? Пишите в комментариях.

Погнали https://telemost.yandex.ru/j/8669013602 🔧 Чем займёмся: · Продолжим пилить инструменты Pinout — погружаемся глубже. Спроектируем тулзу pinout-openapi и обсудим концепт. Посмотрим как харнес поможет спроектировать то, что нужно. · Живое общение: отвечу на ваши вопросы, обсудим идеи.

🔥 Пора снимать видосы! Смешные но по делу. Я уже подготовил дерзкий SDLC без вот этого вот консервативного финтеха ;) Врываемся в дерзкое тестирование в нашем диком мире: — Тесты до нагрузки (чтобы не было мучительно больно); – нагрузку разберем позже; — Карго-культ и те самые "усложнялки", которые инженеры подкидывают нам как сюрприз. Мне нужен тулинг, который наконец поставит разработку платформы на поток. 🚀 Его и пилим ;) чтобы взлететь, нужно сначала пусковую отстроить. Поэтому стартуем с базы инженерного мастерства и ковыряем CI/CD до самых косточек. А потом в реальном времени спроектируем сложную систему и разработаем севместно с машиной. Все расскажу и покажу. Готовьте гиты, будет жарко! Без лишних съездов с трассы, только прямая дорога в пром ;))). 🛠️ Highway to prod ;) #codemonstersvlog