Кредиты в кодексе, продолжение


посмотрел текущее использование кредитов. Итого получается примерно $45 за 2 дня. Стабильно чуть больше 500 кредитов в день в среднем (это $20), 600 максимум.

Итого: если планируем регулярный объём работы то или пучок Team аккаунтов (штук 5, не меньше), или Pro план. подписки сильно выгоднее даже кредитов, а кредиты сильно выгоднее апи.

При активном использовании никакой экономии не получится, бюджеты в диапазоне $100-200 в мес. Это только на клозедов!

Очередной CLI на посмотреть

Сайт сделан грамотно, 10c все таки приличная большая контора - но с азиатским уклоном, конечно, что даже прикольно.

Фичи:
- Субагенты имеются (и пучок встреонных),
- менеджер фоновых процессов,
- выбор моделей (gpt-5/codex, gemini, glm),
- кастомные слеш команды есть (с параметрами),
- маркетплейс/плагины тоже
- mcp: local/sse/http
- memory: в кастомном CODEBUDDY.md, пользователь/проект, @ссылки, нет folder-bound памяти - это все базовая функциональность, но имеется

Интересная штука, довольно функциональная.

▶️ Upd: plan-mode тоже осилили, оказывается!
Ещё есть какой то Spec-kit, но где, пока не понятно

https://www.codebuddy.ai/blog/Automate%20Complex%20CLI%20Tasks%20CodeBuddy%20Code%201.20%20Bri

▶️ Upd 2: SpecKit оказался не доморощенный, а оригинал от гитхаба

Есть мануал как это в CodeBuddy запустить

https://www.codebuddy.ai/blog/Exploring%20Spec-Based%20Programming%20(Spec%20Coding)%20Usi



#post
@deksden_notes

MiniMax M2 vs GLM 4.6 React UI


Сравнили:

https://x.com/donvito/status/1988561391553323287?s=20

GLM местами поинтереснее, но подглючивает вроде))

Воркфлоу - анализ

(идея)

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

Как тестовая штука хочу такую вещь прикрутить: анализ проекта через ИИ.

Стадия 1️⃣: структура

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

При извлечении пробуем получить гипотезу о месте сущности по C4 классификации в системе - к какой подсистеме она относится и тп. Гипотеза этапа извлечения остаётся в БД.

Итог стадии: неструктурированный массив сущностей кода

Стадия 2️⃣: формирование структуры

Берём итоги прогона, обрабатываем все необработанные сущности

- собираем все упоминания сущности в коде/доке; смотрим на гиптезы к какому уровню в структуре проекта она относится; принимаем решение куда её определяем - по совокупности информации;

Итог стадии: имеем структурированную информацию о проекте - со ссылками на источники информации

- побочно: видим какие сущности кода упоминаются в документации и где; получаем покрытие документацией кода;
- видим какие сущности упоминаются в документации но в коде отсутствуют (косячная документация)

- на сдачу можно построить repoWiki по проекту

🟢 Интересно попробовать имея БД сущностей кода (практически граф) - попробовать по разному его структурировать, выделить разные срезы. Хотя это немного сомнительно, но ведь у нас все карты: код, комменты, дока!

Стадия 3️⃣: анализ

У нас есть библиотека "аспектов". Аспект - это отдельное направление анализа кода (безопасность, архитектура, code smells, границы сервисов, контракты, обработка ошибок, стиль кода, ...). Аспект может быть применён к разным скоупам: по C4 уровню - система, домен, контейнер, компонент/юнит.

Для каждого аспекта выбираем набор сущностей, которые попадают под анализ по этому аспекту. Формируем набор задачек для анализа каждого аспекта. Анализируем. Агенту рассказываем как доп информацию смотреть - делать запросы в БД сущностей, ходить смотреть исходный код/доку по ссылкам из БД на источники.

Набор проведённых анализов по аспекту консолидируем в единый документ по этому аспекту.

Такой процесс производим по каждому аспекту.


🟢 Вот такая задумка. Что думаете? Годный план? Кто чего уловил - кому то актуально? или я чего то невнятно пояснил?

- хочу погонять анализ через разные модели: что найдёт на одной и той же базе gemini, codex, gpt-5, k2 thinking, sonnet.

🟢 Да, такие воркфлоу я и понимаю под сложными. может для кого то это и не сложно на агентах сделать - но мне кажется на стоковом СС такое вряд ли летает


#post
@deksden_notes

#DeksdenFlow - 0, TLDR

🟢 Тема с flow для агентной разработки получила довольно большое внимание, в связи с чем я решил таки потратить время и засесть за цикл постов про свой flow, который я использую для разработки.

▶️ Основной тейк этой темы: делаем доработки параллельно в несколько потоков.

Хотя тема мне казалась довольно простой и несложной, серия постов получилась довольно объёмной - аж 7 штук. Хорошее число, в принципе!

## 🚀 DeksdenFlow:

1️⃣ Git Workflow
2️⃣ Контексты
3️⃣ Protocol - обсуждение
4️⃣ Protocol - фиксация плана
5️⃣ Protocol - реализация плана
6️⃣ Protocol - review merge
7️⃣ Заключительное организационное


Посты уже родились и написаны в тексте, немного вычитаю и буду закидывать в канал!

‼️ Сами промпты (Github Gists):

* [protocol-new](https://gist.github.com/deksden/28e8b74ee109f99832a0e2c29f336bb2)

* [protocol-resume](https://gist.github.com/deksden/4429c877a156655d6ecf697e146f3a23)

* [protocol-review-merge](https://gist.github.com/deksden/e3cf8161d84594fad8463bcc5e41565e)

* [protocol-review-merge-resume](https://gist.github.com/deksden/813369837cfc204c8f09419331df4db8)

Понеслась?)

#DeksdenFlow - 1 :: git, worktree

Раскрытие темы начнём с git и подходов к работе с проектом.

Когда работаем с агентами в несколько потоков с одним проектом - вариантов организовать это всего два.

1️⃣ Первый - ограниченный. Мы можем делить работу между агентами "по территориальному признаку", чтобы не пересекались. Например, один обновляет документацию, другой правит код. Но есть шансы что будут накладки - при правке кода очевидно надо будет обновить документацию. А одновременная правка одинаковых файлов обычно хорошим не кончается. В общем - вариант для простых очевидных случаев, применять аккуратно.

2️⃣ Второй вариант - делать все "по науке" и использовать git, который как раз для таких вещей и придумывали. В нем есть инструмент worktree, он похож на обычный чекаут репозитория, но полученный чекаут (называется рабочее дерево - worktree) оптимизирован и использует локальный репозиторий. Для нас это не существенные детали "под капотом", и с точки зрения функциональности мы просто получаем обычную ветку (branch) в отдельной папке нашего локального компьютера.

❓ Какая минимальная стратегия использования веток (branching strategy) - для локальной разработки простого проекта? У нас есть основная ветка "main". При необходимости сделать какие то изменения в репозитории мы образуем от main отдельную ветку - она будет нашей фича-веткой. Порядок работы простой - делаем изменения, коммитим по ходу работы.

Я работаю с GitHub, поэтому использую его фичи, с прицелом на универсальный флоу, в том числе для фоновых удалённых агентов (remote agents) типа Jules/Codex Cloud. При создании ветки я делаю Draft PR в main, и там собираю все коммиты ветки. Теперь прогресс по плану будет виден и на гитхабе.

❓ Где располагать локально worktree? Я пробовал внутри папки проекта. Я пробовал "сбоку" папки проекта (Типа, проекты в /Documents/Projects/(project), а Worktree расположено в /Document/Projects/Worktrees/(worktree)).

В общем, без разницы - если вы будете вести изменения БЕЗ СМЕНЫ папки агента на папку worktree, то даже весьма внимательный кодекс ВСЕГДА, даже для небольших рефакторингов, ошибается папкой и меняет файлы в основной ветке вместо worktree.
Это когда он просто меняет основной репозиторий, "по привычке", видимо. В итоге имеем на main ненужные нам изменения.

🟢 Сейчас у мен папка worktrees/ - это "соседняя" папка с папкой проектов.

Все лежит в .../_Projects/ и далее:
* worktrees/
* (project)/

Расположение папки такое - следствие экспериментов. Думаю, можно выбрать оптимальнее, возможно, внутри проекта - чтобы не мешать другим проектам. Это надо ещё экспериментировать - но от ошибок с путями агентов расположение папки особо не спасает.

‼️ Всегда меняйте папку агента (это с которой он стартует) на сделанное worktree.

▶️ Пока одна сессия агента работает в одном worktree, вы можете таким манером "наплодить" сколько угодно деревьев от основного проекта. Все что нужно будет сделать потом - это merge веток ваших worktree (фичаветок) в главную ветку main.

▶️ Конфликты merge: если с момента создания ветки в вашей основной ветке произошли изменения (а они бы должны происходить, ибо зачем начинать танцы с git Если все линейно?) - при слиянии нужно будет "решить конфликты". Агенты это тоже делают хорошо, просто это отдельная задача.

▶️ Ветки, которые были успешно слиты в main я удаляю - и локально, и удалённо. Чтобы не "засорять" репозиторий лишними ветками.

...

#DeksdenFlow - 1 :: git, worktree (2/2)

...

❓ Есть ли flow посложнее? Конечно. Если у вас сколько-нибудь развивающийся проект, то после такой локальной разработки "выходит в прод". Тут уже нужно модернизировать flow хотя бы до создания простого этапного (staging) ci/cd.

🟢 Обычно я использую набор окружений local / beta / prod:
- local: это локальное окружение для разработки, его я разворачиваю в том числе у фоновых агентов (Jules/Codex Cloud), если такая нужда появляется; окружение использует много локальной инфраструктуры, например, обычно БД локально redis/postgres/neo4j;
- beta: это полу-боевое окружение, когда некоторые возможности разработки ещё включены (расширенные логи, например), но окружение уже в облаке и использует облачные сервисы; разворачиваю на технических доменах провайдера (если vercel) или что то типа beta.domain.com; его можно местами показывать заказчику и на нем гонять всякие тесты типа приёмочных сценариев;
- prod: это боевое окружение

🪾 Ветки в данном кейсе:
- dev (от которой теперь делаем фича-бранчи); она же развёрнута на beta;
- и main (в которую пушим только из dev); она на prod

При желании/потребности усложняем всякими hotfix , канареечными релизами, blue / green релизами и далее до бесконечности. Через github эту штуку можно обвешать проверками, настроить правила - пределов глубины закапывания в devops тут особо не видно.

🏁 Итак, вот вкратце та часть моего Flow, которая касается работы с Git. Что неясно, непонятно, невнятно - спрашиваем в комментах, как обычно!

#DeksdenFlow - 2 :: Контексты

Важно пояснить про концепцию "контекстов".

▶️ При работе с проектам я привык к использованию пула условно готовых к работе контекстов агента - "прогретый" контекст.

Так как я использую меморибанк и аннотированные индексные файлы, то новую сессию агента я начинаю с промпта о чтении главного индексного файла меморибанка, в котором, как известно, содержится аннотированные ссылки на основные разделы и файлы меморибанка - такая "карта знаний" о проекте. Я называю этот процесс "праймингом контекста меморибанком".

Пример для проекта "оркестратор":

стартовая точка меморибанка: `.memory-bank/index.md`, прочитай файл полностью.

подготовься: обсуждаем оркестратор, работу с воркером, систему событий

подготовь контекст, изучай код и документацию, меморибанк

прочитай все нужные тебе для понимания тематики файлы (открой, прочитай, кратко пропиши усвоенные тобой тезисы)

сами вопросы будут позже

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

На кодексе исполняю такой промпт gpt-5-codex medium, хотя, наверняка, и low справится. может быть стоит на -mini переключить, тут главное не забыть потом поменять. Так как я регулярно забываю, то сразу указываю более-менее адекватную модель.

Да, проблема с моделью бы решилась, если бы в Кодексе было такое прекрасное расширение, как CCStatusBar в СС и мы ясно бы видели в статусной строке текущую модель. Но Кодекс пока рудиментарен по фичам, что порой реально неудобно - как в этом случае.

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

В итоге за 3-9 минут (как пойдёт, бывает по разному), у меня получается сессия агента уже немного узнавшего про проект и готового к новым вопросам/задачам.

▶️ Сессии агентов запускаю в табах iTerm2, и табы переименовываю порядковым номером очередного контекста с префиксом "c" - то есть "с062", "c063". Одна-две "прогретые" сессии обычно висят в фоне.

❓ Почему не tmux? Так как окон много, я в них путаюсь. А tmux позволяет именовать только окна, а не панели с отдельным терминалом - мне это неудобно. Решения с именами панелей я пока не нашёл, хотя возможно оно существует. Конечно, tmux интереснее: сессия не потеряется при необходимости перестартовать терминал.

▶️ Тему меморибанков и конекстного инжиниринга для неё я довольно подробно прописывал.

Кто хочет ознакомиться с базовой концепцией: есть статья на хабре про раннее понимание темы - она до сих пор может быть полезной

* AI Software Engineering: От хаоса Vibe Coding к системной разработке с AI-агентами
🔗 https://habr.com/ru/articles/934806/

На канале про некоторые техники конекст-инжиниринга для меморибанков тоже была серия постов:

* индексные файлы: https://t.me/deksden_notes/46
* аннотированные ссылки: https://t.me/deksden_notes/47
* атомарные duo файлы: https://t.me/deksden_notes/49

🟢 Желающие читают, знакомятся, спрашивают

🏁 По мере надобности очередного контекста, берём первый свободный контекст. Для чего именно нужны такие контексты - читайте в других разделах Flow.

#DeksdenFlow - 3 :: Protocol - Этап обсуждения

⚪️ Почти любую доработку в системе я провожу через этап планирования.

Исключением являются только короткие фиксы, которые я делаю так: допустим, при работе с системой замечен какой то косячок, который надо поправить. Я беру из пула готовых "прогретых" контекстов один, и пишу раздел системы, который затронут косячком. Например, это дашборд (веб приложение для управления системой) - тогда второй промпт для контекста агента будет "подготовься к работе с дашбордом, сформируй контекст, возвращайся как будешь готов к обсуждению".

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

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

▶️ Регулярно возникает ситуация когда я понимаю, что вместо короткого фикса требуется доработка, а то и переработка какой то части системы. Например, сервер в дашборд отдаёт не так, не то, или не сколько надо.

Тогда мы начинаем "этап планирования".

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

▶️ Насчёт моделей в кодексе. Выбор невелик, но он есть:
- Gpt-5-thinking high
- Gpt-5-codex high

Я предпочитаю на планирование брать Gpt-5 : по моим ощущениям она поумнее. Возможно, потому что Gpt-5-codex это агентный тюн, который лучше движется по задачам, но, возможно, в некоторый ущерб креативности. Поэтому - обычная Gpt-5-thinking

▶️ Что такое планирование? Это когда мы обсуждаем доработку/переработку системы, и в итоге обсуждения доработки рождается план внесения изменений в систему.

Я привык работать паттерном "подготовились -> поработали" ВСЕГДА:
- сначала агенту формулируется тема обсуждения/вопрос и даётся задание "подготовиться к вопросу, сформировать контекст, возвращаться как готов".
- само обсуждение вопроса провожу следом, поверх готового контекста

▶️ Процесс обсуждения у меня не структурированный. Обычно перед обсуждением в кодексе я вставляю промпт чтобы поменять стиль общения. По-умолчанию Gpt-5 и особенно Кодекс общаются как аутисты/асоциалы - кратко, тезисно, малопонятно, экономя токены. Объяснения, пояснения, примеры из него надо клещами вытаскивать. Когда он пишет код - это норм, но на этапе планирования хотелось бы общения

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

...

#DeksdenFlow - 3 :: Protocol - Этап обсуждения (2/2)

...

В общем, вы уловили суть - не все мои настройки подойдут всем и всегда, поэтому стиль общения настраиваем под себя. Для кодекса несколько помогает, но не полностью - системный промпт мы же не отключаем!

Вот в СС стиль общения ЗАМЕНЯЕТ прописанный в системном промпте стиль - поэтому кастомный стиль общения был известным хаком как поместить инструкции прямо в системный промпт. Кроме того, стиль работает хорошо, противоречивые инструкции о стиле общения отсутствуют. Но, не устаю повторять, в Кодексе нету стилей общения и замены системного промпта (да, в СС и системный промпт заменить можно), потому что Кодекс рудиментарный по фичам.

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

👉 Тут есть момент, который у меня сейчас недостаточно проработан: размер задания. Им сейчас можно управлять только промптом. Что можно было бы доработать: попробовать оценить сложность каждого пункта плана "в попугаях", чтобы сбалансировать работу поровнее - будет идеально, если каждый шаг будет "входить" в контекст с запасом.

У меня же иногда бывало с большими рефакторингами что шаги "вылезали" за контекст. С последними версиями кодекса существенно подкрутили функцию auto compact, и теперь он не так тупеет со сменой контекста, что ситуация стала менее критичной.

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

🏁 Итак: мы остановились на этапе, когда вы завершили обсуждение доработки с агентом, и собираетесь зафиксировать доработку в виде плана. Это тема следующего раздела.

#DeksdenFlow - 4, Protocol, Этап фиксации плана


⚪️ Мы продолжаем с точки, когда испытали горячее желание зафиксировать обсуждение плана с агентом в виде плана.

Такое нельзя держать в себе, и для этого момента у меня есть длинный промпт, называется "protocol-new".

▶️ Сначала о терминах - почему "протокол"? Потому что эта система родилась из желания "тянуть" длинные рефакторинги через несколько контекстов, и для фиксации текущего состояния был использован файл "протокола" - там был раздел "выполненной работы", отсюда отличие от термина "план".

▶️ В итоге я пришёл к системе "protocol": это когда мы нашу доработку ведём фиксируя ряд файлов: протокол = план + контекст + методика + лог.

---

- папка протокола нумеруется, паттерн "XXXX-{название протокола}/", например "0040-server-refactoring/";
- ключевым является номер ХХХХ, который называется номером протокола, и по нему система его идентифицирует.
- все папки протокола у меня живут в корне проекта в папке ".protocols/"; точка в начале папки обозначает типа "системную" папку, подчёркивая её служебный характер;
- Идентифицировать протокол по полному названию папки смысла особого нету, агент разберётся и по номеру. Вполне работают промпты типа "Прочитай протокол 0074 из папки .protocols/".
- если прописать в главном индексном файле что есть такая папка .protocols, что там есть папки с названиями по паттерну XXXX-имя_папки, что ХХХХ тут номер протокола, что внутри содержатся протоколы доработок системы в наборе файлов, и пояснить про набор файлов -> тогда агент ищет быстрее и лучше.

---

- план разделён на крупные этапы, которые я исторически назвал "шагами"; по своей сути "шаг" - это группа задач;
- шаг разделён на несколько задач, обычно до 5-7;
- ‼️ мы уже обсуждали, что деление плана на шаги и оценка сложности/размера шага - это область доработки системы

---

- plan.md: в папке содержится файл "plan.md" с общим планом
- шапка общего плана написана в формате mini-ADR (погуглите про этот термин - **Architecture Decision Record**), это попытка сохранить из обсуждения не только информацию о том ЧТО необходимо делать, но и ПОЧЕМУ мы делаем именно так и ДЛЯ ЧЕГО;

---

- отдельные шаги получают собственные файлы планов в файлах с паттерном имени "YY-{название шага}.md"; это помогает сфокусировать агента на задачах текущего шага, не засоряя контекст/внимание деталями задач других шагов;
- внутри отдельного шага прописаны не только задачи доработки, но и организационные действия по плану (методика работы)

---

- перед началом каждого шага система проверяет что все изменения закоммичены
- задачи шага выполняются последовательно
- после выполнения всех задач мы делаем проверки:
* typecheck : обязательно, надо чтобы созданный код был корректным
* lint : обязательно, а то потом мы устанем вычищать стиль кода после больших правок; ‼️ лог линтера на каждом шаге поначалу стоит изучить: если ошибок довольно много, это означает что агентам неправильно доведён стиль кодирования в проекте, и они систематически что то делают не то - значит, следует исправить промпты;
* я запускаю 'test' : на этот скрипт завязаны юнит тесты; ‼️ стратегия тестирования - отдельная большая тема, про неё можно сказать много и там существует куча подходов со своими плюсами;
* когда все проверки прошли - агент должен сделать коммит и пуш; коммит делается с тегом шага, вида "[XXXX-YY]", где XXXX это номер протокола, YY-номер шага.

---

* Briefing: в файле шага есть секция briefing - это важные сведения для формирвоания контекста для выполнения работы по этому шагу; там прописывается цель доработок, важные файлы которые нужно знать, дополнительная информация - на что нужно обратить внимание. Эта секция помогает агенту подготовится для работы по шагу и сформировать нужный контекст.

---

* log.md: это файл про то, что сделано; ‼️ тут тоже была идея фиксировать не просто дубль лога изменения файлов в git, а прописывать особенности реализации, решённые проблемы, существенные детали; не сказал бы чтобы агентам было понятно это требование, поэтому пишут чего могут;

...

#DeksdenFlow - 4, Protocol, Этап фиксации плана (2/2)


...


* context.md: файл контекста - скорее это статус выполнения протокола, с текущим шагом, последним действием, следующим шагом, сведениями о git и рабочих папках.

Довольно обширно вышло с протоколом, верно? Обратите внимание - я постарался раскрыть некоторую логику почему сделано именно ТАК, но лучше задавать вопросы что кажется непонятным или неясным. ‼️ Моя логика может не работать универсально, или не подходить, тут нет железных схем или устоявшейся практики - лучше всего уяснить логику формирования плана и все тюнинговать "под себя"

👉 Да, не устану повторять что Кодекс капитально отстаёт по фичам. Что можно было бы доработать в системе "Protocol", если бы один из самых мелких стартапов в истории нашёл бы инженеров для создания субагентов.

Субагенты решили бы проблему следования инструкциям для специфических видов деятельности:
- кастомный субагент для написания кода получил бы инструкцию с деталями стиля кода в проекте, на что обращать внимание, что делать, чего избегать, примеры хороших паттернов, примеры анти-паттернов; для ui следил бы за классами Tailwind и тп;
- агент который работает с git мог бы внимательнее следить за форматом commit сообщений, не забывать ставить тег протокола/шага, проверял бы перед коммитом что ему сообщили что проверки были и они были зелёные и отказывался бы без такой информации делать коммит,
- агент тестирования мог бы лучше знать какой набор тестов запустить, а какой - не стоит; можно было бы не только юнит тесты запускать, но и часть полу-интеграционных или компонентных тестов;

▶️ Итак, мы обсудили структуру того протокола, который формирует мой промпт. Этот промпт мы отправляем в момент, когда мы обсудили с агентом доработки и готовы их фиксировать.

▶️ Далее система начинает исполнять протокол, и делает технический первый шаг:
- присваивает новый номер протокола
- проверяет чтобы ветка main была чистой - если нет, надо с этим что то сделать (игнорировать тоже можно, но лучше сделать коммит текущих изменений);
- создаёт новое worktree в папке деревьев в системе; соответственно, делается новый git branch
- делает draft PR
- в этом новом дереве создаёт папку для нового протокола, и формирует там все файлы протокола.
- делает коммит/пуш с новыми файлами
- переводит контекст на шаг 1.

🏁 Вот тут я останавливаюсь с текущим контекстом, шаг 0 завершен

#DeksdenFlow - 5, Protocol, этап Реализация (1/2)


⚪️ Мы остановились в момент, когда новый протокол получил свою ветку и первый технический коммит в PR уже сделан. Можно посмотреть на него в github.

‼️ Важно: в этот момент мы меняем контекст. Почему? Самая важная причина - смена CWD, текущей рабочей папки агента.

Я не смог заставить кодекс надёжно редактировать файлы только внутри worktree. Менял расположение папки, писал инструкции для контроля - ничего не помогает. Часто агент начинает изменять файлы по стандартным путям, а это основной репозиторий на ветке main. Изменения по этому пути считаются внесением правок в ветку main. Это создаёт некоторый хаос и бардак, и приходится переносить изменения - абсолютно неудобно.

👉 Что спасает, причём почти на 100%: мы переходим в новое ворктри, и стартуем агента из этой папки. Когда CWD = нужный нам ворктри, ошибки полностью исчезают. Вот тут и пригождается запасик "прогретых" контекстов.

Для возобновления работы по протоколу используем промпт "protocol (resume)". В этот промпт надо вставить номер протокола, чтобы агент нашёл нужный.

▶️ Далее агент работает в соответствии с промптом:
- найдёт файлы протокола, прочитает, ознакомится
- восстановит контекст
- посмотрит текущий зафиксированный шаг
- возобновит работу с прерванного места
- добавит в "log.md" отметку о восстановлении контекста - это я на всякий случай решил статистику вести, сколько контекстов ушло на протокол; чистое любопытство, особой роли не играет - можно увидеть следом за заголовком лога;

▶️ Когда агент восстановил контекст, он пишет об этом отчёт и предлагает возобновить работу.

‼️ Засеките заполнение контекста в этой контрольной точке, просто запомните цифру.

Дальше мы пишем, в основном, один промпт на протяжении всей работы агента -

продолжай работу по плану протокола

Как правило, агент останавливается в момент завершения шага. Но если шаг попался крупный (а мы помним, что это - зона доработки система Protocol), то может остановиться в середине.

‼️ Важно: когда шаг выполнен, результат работы должен быть закоммичен и сделан пуш. Обычно агентследует формату и пишет что коммит/пуш сделаны, проверки прошли. Обычно! Но иногда внимание агента снижается, и он этого не делает. Поэтому если он вывел отчёт о выполненной работы и планирует переходить к следующему шагу, а вы не видите инфы о проверках/коммите/пуше, то спрашиваем:

Все проверки по протоколу выполнены? Вес прошли, все исправлено? Коммит / пуш сделаны?

Обычно этого достаточно.

▶️ Такими шагами мы движемся к полному выполнению всего протокола. Когда Кодекс выполнил шаг - обратите внимание на процент расхода контекста на выполнение шага. Прикиньте - хватает ли с запасом для следующего шага?

👉 Если хватает, то "продолжай работу по плану протокола!"

👉 Если маловато - берите следующий контекст, делайте CWD на wortree, берите промпт "resume" и восстанавливайте контекст протокола и продолжайте в новом

👉 Если недоследили и агент "стукнулся в лимит контекста" (автокомпакт отключен) - ничего страшного, берём новый контекст, делаем CWD на wortree, делаем "resume" и продолжаем - система должна нормально стартовать с места прерывания;

...

#DeksdenFlow - 5, Protocol, этап Реализация (2/2)

...

👉 Если недоследили, а в Кодексе включён автокомпакт и этот процесс прошел? Тогда кодекс восстановит контекст "по своему разумению" - там уже не будет изначально "прогретого" меморибанком контекста, и протокол восстановления контекста у него свой, он не факт что будет следовать нашему (хотя и такое случается! у меня даже отметку о восстановлении контекста добавляет);
- тут я пробовал продолжать работу - вроде бы норм, но глубоко не исследовал
- чтобы не рисковать вообще (хотя негатива от продолжения в прежнем контексте не было, повторюсь) - можно взять новый прогретый контекст и "resume" там.
- не надо делать мультикомпакт (проходить через компакт много раз)! Это официалы даже пишут в подсказке Кодекса - я пробовал, начинает чудить - вам это может не понравится


‼️ Не забываем, что для работы в worktree нужён контекст с CWD установленной на это worktree. К сожалению, агент тихонько начинает работать и так, но он почти гарантированно делает ошибки, и пишет по пути основного репозитория, и правки попадают в main. Что делать в этом случае?
- ничего страшного: как заметили правки на main, то делаем так:
- просим перенести изменения в main в рабочую ветку
- когда закончили с переносом, выходим из агента (он покажет как возобновить эту сессию через codex resume ...)
- меняем рабочую директорию
- делаем codex resume (session-id)
- "продолжить!"

▶️ Допустим, все шаги протокола выполнены, агент перевёл PR в статус Ready. Что дальше?

🏁 А дальше - этап Merge.

#DeksdenFlow - 6, Protocol, Этап Review and Merge

⚪️ Выполнение содержательной части нашего протокола закончено, агент реализовал все запланированные шаги, изменения закоммичены и лежат в worktree.

▶️ Далее наша задача - влить эти изменения в основную ветку main. Сложности тут могут быть стандартные: за время, пока отрабатывал протокол, вы могли внести другие изменения в ветку main, и синхронизация требует типового процесса merge.

🟢 Более того: вся эта свистопляска с git и была затеяна ради возможности параллельно вести много доработок! Пока выполняется реализация какого то протокола, вы можете стартовать с другими протоколами, и также параллельно их вести!

Например, 1-2 протокола идут у вас в режиме "продолжай работу по плану протокола!", а вы третью доработку обсуждаете с агентом в режиме планирования. Это штатная возможность системы, даже её основная задача - обеспечивать параллельную доработку.

▶️ Для проведения merge мы берен новый контекст, берём промпт "review and merge", проставляем в нем номер протокола, и запускаем этим промптом в агента.

‼️ Важно: CWD этапа merge - это обычная папка вашего проекта, ничего менять не надо, берём стоковый контекст.

Получив промпт, агент будет действовать:
* загрузит файлы протокола, ознакомится с ними:
- сделает файлы для лога этапа merge

▶️ Этап merge работает на верхнем уровне так:
- шаг 1-m: сначала прогоняет "облачные" проверки, которые настроены в вашем ci/cd на github (те самые checks) - если их нет, то ок, этап пройден
- **шаг 2-m:**потом прогоняем внимательно все локальные проверки
- обязательно typecheck / lint
- текущие тесты
- сборку build проекта (это не делается после каждого шага, потому что частично реализованные доработки могут мешать сборке системы)
- если что то не проходит, скажите агенту исправлять.
- шаг 3-m: далее делаем ревью полноты: сверяем реализацию с планом
- шаг 4-m: далее - делаем merge, при необходимости решая конфликты.
- ‼️ архив протоколов может помочь агенту грамотно провести сложный merge - он прочитает последние протоколы, и поймёт какие исправления были внесены, как их корректно слить с нашими
- шаг 5-m: финиш: чистим систему, удаляем рабочее дерево и ветки из git.

▶️ Как правило, мне хватало одного контекста чтобы провести merge. Допускаю, что при большом объёме правок в связи с решением merge-конфликтов может потребоваться новый контекст для продолжения работы - тогда есть промпт "review-merge resume"

🏁 Поздравляю! Если вы читаете это - вы закончили работу с протоколом, успешно влив изменения из рабочего дерева обратно в main

#DeksdenFlow - 7, Заключительное организационное


⚪️ Итак, мы прошли все по цепочке этого простого флоу для локальной разработки

Такой порядок действий позволяет довольно легко тянуть 3-4 параллельные доработки, просто эпизодически кликая в терминале "Продолжай работу по плану протокола!".

Работа в 3-4 потока потенциально неплохо жгет лимиты, я один раз почти выбрал недельный лимит на плане Pro - а это надо стараться. Думаю, с одним проектом будет тяжело выбить лимиты.


▶️ Ещё разок о нейминге вкладок в терминале, после "оглашения" всего флоу становится понятно, зачем такое вообще надо - такое помогает не запутаться в ситуации:

- свободные готовые контексты я именую паттерном "с034",
- когда в контекст загружен протокол, я пишу номер протокола и порядковый номер возобновления контекста в имя вкладки, например "0072-3".
- если мы находимся на стадии ревью, то добавляем префикс/суффикс m "m0071-2"l впрочем, второй контекст для merge у меня сейчас редко встречается;
- когда основная работа по протоколу завершается, в момент когда успешно стартовали с merge и появилась вкладка "m0071", то вкладаку "0071-5" с финишем реализации протокола мы закрываем;
- если я нахожусь на стадии обсуждения чего то, я указываю одиночную цифру в заголовке вкладки "5", "6" например; вы же помните - когда появляется протокол, мы меняем контекст, поэтому после "protocol resume" и появления "XXXX-2" для нового номера протокола такие вкладки просто закрываются;



▶️ Как работать с промптами:

* я сохраняю промпты в Obsidian, потому что там крутой и удобный редактор markdown;
* промпты тут явные кандидаты для созания кастомных слеш-комманд; причём, у resume/merge даже параметры понятно какие и куда указывать
* почему нету слеш команд? потому что я работаю с разными агентами - к сожалению, формат слеш команд отличается, и место хранения отличается. Копировать и следить за версиями, модифицировать $ARGUMENTS или его отсутствие для разных агентов довольно муторно и я обхожусь банальным Obsidian;
* если вы работаете с одним агентом - логично будет сконвертировать промпты в слеш команды


‼️ Не копируйте и не используйте промпты бездумно! Мои промпты и мой Flow - это отправная точка сборки вашего собственного flow. Важно все осознать и вместо копирования производить "усвоение", и адаптацию. Все что неясно или непонятно - спрашивайте. Самое важное - понять логику процесса, выстраивание процессов и владение этой логикой, кмк, и есть довольно важный скилл нынче.


🏁 Собственно, все

👌 В общем - такое мы практикуем! (ц)

Codex 0.58 + gpt-5.1-codex


... released!

#DeksdenFlow и Gpt-5.1


Родился небольшой апдейт по флоу в связи с выходом Gpt-5.1

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

Не знаю с чем связано, может в момент перехода с модели на модель, контексты формирвоались старой моделью - но Gpt-5.1-codex при реализации протокола (этап, когда она уже идёт "по шагам") стала как gpt-5 останавливаться и переспрашивать после каждой задачи. Замечу, что Gpt-5-codex так не делает, а работает довольно долго без этих вот "испугов" и неуверенностей

Промпт я использовалс стандартный - "Продолжай работу по плану"

И реально, вместо выполнения полного шага, модель останавливалась посередине с промежуточным отчётом.

👉 После разных экспериментов, оказалось что теперь требуется прямо сказать: "выполни шаг полностью, все его задачи" - и тогда она снова работает по 20-40 минут нормально.

В связи с чем такое поведение - не могу сказать.


Вот такое вот наблюдение

Имейте ввиду!

🟢 Upd: вскрытие показало! Видимо, 5.1 доучивали следовать инструкциям. Потому что инструкциям оно следует довольно внимательно.

Оказалось, что если сказать "действуй по плану протокола, выполняй все задачи" - то все задачи оно выполнит, а вот коммит и пуш изменений делать не будет, потому что эти инструкции были не в задачах! Это дополнительные инструкции шага, которые хз как назвать.

а вот если сказать что то вроде "выполняй все задачи шага и дальнейшие инструкции" - то все инструкции полностью выполняет!

🤔 Требования к ясности, непротиворечивости, недвусмысленности промптов, видимо, повысились. Нам нужен ЯСНОМЕТР для промптов.



#post
@deksden_notes

Технически-экономическое


Как вы помните - я за подписки. И за выбор

Вот тут народ прикрутил CLIProxyAPI к Droid CLI чтобы работать поверх текущего CLI с подпиской - chatgpt/claude

🔗 https://github.com/ben-vargas/ai-cli-proxy-api/blob/main/USING_WITH_FACTORY_AND_AMP.md

🤟 Такое мы ценим!

Qwen Code

... выпустил 0.2.1

в целом - 8 версий за 17 дней


Всякое новое:

🌐 Free Web Search: Support for multiple providers. Qwen OAuth users get 2000 free searches per day!
🎯 Smarter Code Editing: New fuzzy matching pipeline reduces errors and saves tokens—fewer retries needed.


‼️ ⚙️More Control: Fine-tune AI behavior with temperature, top_p, and max tokens settings.


💻 Better IDE Integration: Enhanced Zed IDE support with todo and task management tools.
📝 Cleaner Output: Tool responses now use plain text instead of complex JSON—easier for AI to understand.
🔍 Improved Search: Better file filtering (respects `.gitignore`), smarter search tools, and standardized naming.
⚡ Faster Performance: Multi-stage normalization pipeline for zero-overhead matching, better Unicode handling, and optimized output limits.
🐛 Bug Fixes: Fixed token limits for multiple models, improved cross-platform support (macOS & Windows), and better stability.


Ну - суть не в этом, а в том, что они тоже активно развиваются!

https://github.com/QwenLM/qwen-code