#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, а прописывать особенности реализации, решённые проблемы, существенные детали; не сказал бы чтобы агентам было понятно это требование, поэтому пишут чего могут;
...
⚪️ Мы продолжаем с точки, когда испытали горячее желание зафиксировать обсуждение плана с агентом в виде плана.
Такое нельзя держать в себе, и для этого момента у меня есть длинный промпт, называется "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, а прописывать особенности реализации, решённые проблемы, существенные детали; не сказал бы чтобы агентам было понятно это требование, поэтому пишут чего могут;
...
🔥5👍3❤2
#DeksdenFlow - 4, Protocol, Этап фиксации плана (2/2)
...
* context.md: файл контекста - скорее это статус выполнения протокола, с текущим шагом, последним действием, следующим шагом, сведениями о git и рабочих папках.
Довольно обширно вышло с протоколом, верно? Обратите внимание - я постарался раскрыть некоторую логику почему сделано именно ТАК, но лучше задавать вопросы что кажется непонятным или неясным. ‼️ Моя логика может не работать универсально, или не подходить, тут нет железных схем или устоявшейся практики - лучше всего уяснить логику формирования плана и все тюнинговать "под себя"
👉 Да, не устану повторять что Кодекс капитально отстаёт по фичам. Что можно было бы доработать в системе "Protocol", если бы один из самых мелких стартапов в истории нашёл бы инженеров для создания субагентов.
Субагенты решили бы проблему следования инструкциям для специфических видов деятельности:
- кастомный субагент для написания кода получил бы инструкцию с деталями стиля кода в проекте, на что обращать внимание, что делать, чего избегать, примеры хороших паттернов, примеры анти-паттернов; для ui следил бы за классами Tailwind и тп;
- агент который работает с git мог бы внимательнее следить за форматом commit сообщений, не забывать ставить тег протокола/шага, проверял бы перед коммитом что ему сообщили что проверки были и они были зелёные и отказывался бы без такой информации делать коммит,
- агент тестирования мог бы лучше знать какой набор тестов запустить, а какой - не стоит; можно было бы не только юнит тесты запускать, но и часть полу-интеграционных или компонентных тестов;
▶️ Итак, мы обсудили структуру того протокола, который формирует мой промпт. Этот промпт мы отправляем в момент, когда мы обсудили с агентом доработки и готовы их фиксировать.
▶️ Далее система начинает исполнять протокол, и делает технический первый шаг:
- присваивает новый номер протокола
- проверяет чтобы ветка main была чистой - если нет, надо с этим что то сделать (игнорировать тоже можно, но лучше сделать коммит текущих изменений);
- создаёт новое worktree в папке деревьев в системе; соответственно, делается новый git branch
- делает draft PR
- в этом новом дереве создаёт папку для нового протокола, и формирует там все файлы протокола.
- делает коммит/пуш с новыми файлами
- переводит контекст на шаг 1.
🏁 Вот тут я останавливаюсь с текущим контекстом, шаг 0 завершен
...
* context.md: файл контекста - скорее это статус выполнения протокола, с текущим шагом, последним действием, следующим шагом, сведениями о git и рабочих папках.
Довольно обширно вышло с протоколом, верно? Обратите внимание - я постарался раскрыть некоторую логику почему сделано именно ТАК, но лучше задавать вопросы что кажется непонятным или неясным. ‼️ Моя логика может не работать универсально, или не подходить, тут нет железных схем или устоявшейся практики - лучше всего уяснить логику формирования плана и все тюнинговать "под себя"
👉 Да, не устану повторять что Кодекс капитально отстаёт по фичам. Что можно было бы доработать в системе "Protocol", если бы один из самых мелких стартапов в истории нашёл бы инженеров для создания субагентов.
Субагенты решили бы проблему следования инструкциям для специфических видов деятельности:
- кастомный субагент для написания кода получил бы инструкцию с деталями стиля кода в проекте, на что обращать внимание, что делать, чего избегать, примеры хороших паттернов, примеры анти-паттернов; для ui следил бы за классами Tailwind и тп;
- агент который работает с git мог бы внимательнее следить за форматом commit сообщений, не забывать ставить тег протокола/шага, проверял бы перед коммитом что ему сообщили что проверки были и они были зелёные и отказывался бы без такой информации делать коммит,
- агент тестирования мог бы лучше знать какой набор тестов запустить, а какой - не стоит; можно было бы не только юнит тесты запускать, но и часть полу-интеграционных или компонентных тестов;
▶️ Итак, мы обсудили структуру того протокола, который формирует мой промпт. Этот промпт мы отправляем в момент, когда мы обсудили с агентом доработки и готовы их фиксировать.
▶️ Далее система начинает исполнять протокол, и делает технический первый шаг:
- присваивает новый номер протокола
- проверяет чтобы ветка main была чистой - если нет, надо с этим что то сделать (игнорировать тоже можно, но лучше сделать коммит текущих изменений);
- создаёт новое worktree в папке деревьев в системе; соответственно, делается новый git branch
- делает draft PR
- в этом новом дереве создаёт папку для нового протокола, и формирует там все файлы протокола.
- делает коммит/пуш с новыми файлами
- переводит контекст на шаг 1.
🏁 Вот тут я останавливаюсь с текущим контекстом, шаг 0 завершен
👍7🔥4
#DeksdenFlow - 5, Protocol, этап Реализация (1/2)
⚪️ Мы остановились в момент, когда новый протокол получил свою ветку и первый технический коммит в PR уже сделан. Можно посмотреть на него в github.
‼️ Важно: в этот момент мы меняем контекст. Почему? Самая важная причина - смена CWD, текущей рабочей папки агента.
Я не смог заставить кодекс надёжно редактировать файлы только внутри worktree. Менял расположение папки, писал инструкции для контроля - ничего не помогает. Часто агент начинает изменять файлы по стандартным путям, а это основной репозиторий на ветке main. Изменения по этому пути считаются внесением правок в ветку main. Это создаёт некоторый хаос и бардак, и приходится переносить изменения - абсолютно неудобно.
👉 Что спасает, причём почти на 100%: мы переходим в новое ворктри, и стартуем агента из этой папки. Когда CWD = нужный нам ворктри, ошибки полностью исчезают. Вот тут и пригождается запасик "прогретых" контекстов.
Для возобновления работы по протоколу используем промпт "protocol (resume)". В этот промпт надо вставить номер протокола, чтобы агент нашёл нужный.
▶️ Далее агент работает в соответствии с промптом:
- найдёт файлы протокола, прочитает, ознакомится
- восстановит контекст
- посмотрит текущий зафиксированный шаг
- возобновит работу с прерванного места
- добавит в "log.md" отметку о восстановлении контекста - это я на всякий случай решил статистику вести, сколько контекстов ушло на протокол; чистое любопытство, особой роли не играет - можно увидеть следом за заголовком лога;
▶️ Когда агент восстановил контекст, он пишет об этом отчёт и предлагает возобновить работу.
‼️ Засеките заполнение контекста в этой контрольной точке, просто запомните цифру.
Дальше мы пишем, в основном, один промпт на протяжении всей работы агента -
Как правило, агент останавливается в момент завершения шага. Но если шаг попался крупный (а мы помним, что это - зона доработки система Protocol), то может остановиться в середине.
‼️ Важно: когда шаг выполнен, результат работы должен быть закоммичен и сделан пуш. Обычно агентследует формату и пишет что коммит/пуш сделаны, проверки прошли. Обычно! Но иногда внимание агента снижается, и он этого не делает. Поэтому если он вывел отчёт о выполненной работы и планирует переходить к следующему шагу, а вы не видите инфы о проверках/коммите/пуше, то спрашиваем:
Обычно этого достаточно.
▶️ Такими шагами мы движемся к полному выполнению всего протокола. Когда Кодекс выполнил шаг - обратите внимание на процент расхода контекста на выполнение шага. Прикиньте - хватает ли с запасом для следующего шага?
👉 Если хватает, то "продолжай работу по плану протокола!"
👉 Если маловато - берите следующий контекст, делайте CWD на wortree, берите промпт "resume" и восстанавливайте контекст протокола и продолжайте в новом
👉 Если недоследили и агент "стукнулся в лимит контекста" (автокомпакт отключен) - ничего страшного, берём новый контекст, делаем CWD на wortree, делаем "resume" и продолжаем - система должна нормально стартовать с места прерывания;
...
⚪️ Мы остановились в момент, когда новый протокол получил свою ветку и первый технический коммит в PR уже сделан. Можно посмотреть на него в github.
‼️ Важно: в этот момент мы меняем контекст. Почему? Самая важная причина - смена CWD, текущей рабочей папки агента.
Я не смог заставить кодекс надёжно редактировать файлы только внутри worktree. Менял расположение папки, писал инструкции для контроля - ничего не помогает. Часто агент начинает изменять файлы по стандартным путям, а это основной репозиторий на ветке main. Изменения по этому пути считаются внесением правок в ветку main. Это создаёт некоторый хаос и бардак, и приходится переносить изменения - абсолютно неудобно.
👉 Что спасает, причём почти на 100%: мы переходим в новое ворктри, и стартуем агента из этой папки. Когда CWD = нужный нам ворктри, ошибки полностью исчезают. Вот тут и пригождается запасик "прогретых" контекстов.
Для возобновления работы по протоколу используем промпт "protocol (resume)". В этот промпт надо вставить номер протокола, чтобы агент нашёл нужный.
▶️ Далее агент работает в соответствии с промптом:
- найдёт файлы протокола, прочитает, ознакомится
- восстановит контекст
- посмотрит текущий зафиксированный шаг
- возобновит работу с прерванного места
- добавит в "log.md" отметку о восстановлении контекста - это я на всякий случай решил статистику вести, сколько контекстов ушло на протокол; чистое любопытство, особой роли не играет - можно увидеть следом за заголовком лога;
▶️ Когда агент восстановил контекст, он пишет об этом отчёт и предлагает возобновить работу.
‼️ Засеките заполнение контекста в этой контрольной точке, просто запомните цифру.
Дальше мы пишем, в основном, один промпт на протяжении всей работы агента -
продолжай работу по плану протокола
Как правило, агент останавливается в момент завершения шага. Но если шаг попался крупный (а мы помним, что это - зона доработки система Protocol), то может остановиться в середине.
‼️ Важно: когда шаг выполнен, результат работы должен быть закоммичен и сделан пуш. Обычно агентследует формату и пишет что коммит/пуш сделаны, проверки прошли. Обычно! Но иногда внимание агента снижается, и он этого не делает. Поэтому если он вывел отчёт о выполненной работы и планирует переходить к следующему шагу, а вы не видите инфы о проверках/коммите/пуше, то спрашиваем:
Все проверки по протоколу выполнены? Вес прошли, все исправлено? Коммит / пуш сделаны?
Обычно этого достаточно.
▶️ Такими шагами мы движемся к полному выполнению всего протокола. Когда Кодекс выполнил шаг - обратите внимание на процент расхода контекста на выполнение шага. Прикиньте - хватает ли с запасом для следующего шага?
👉 Если хватает, то "продолжай работу по плану протокола!"
👉 Если маловато - берите следующий контекст, делайте CWD на wortree, берите промпт "resume" и восстанавливайте контекст протокола и продолжайте в новом
👉 Если недоследили и агент "стукнулся в лимит контекста" (автокомпакт отключен) - ничего страшного, берём новый контекст, делаем CWD на wortree, делаем "resume" и продолжаем - система должна нормально стартовать с места прерывания;
...
👍1
#DeksdenFlow - 5, Protocol, этап Реализация (2/2)
...
👉 Если недоследили, а в Кодексе включён автокомпакт и этот процесс прошел? Тогда кодекс восстановит контекст "по своему разумению" - там уже не будет изначально "прогретого" меморибанком контекста, и протокол восстановления контекста у него свой, он не факт что будет следовать нашему (хотя и такое случается! у меня даже отметку о восстановлении контекста добавляет);
- тут я пробовал продолжать работу - вроде бы норм, но глубоко не исследовал
- чтобы не рисковать вообще (хотя негатива от продолжения в прежнем контексте не было, повторюсь) - можно взять новый прогретый контекст и "resume" там.
- не надо делать мультикомпакт (проходить через компакт много раз)! Это официалы даже пишут в подсказке Кодекса - я пробовал, начинает чудить - вам это может не понравится
‼️ Не забываем, что для работы в worktree нужён контекст с CWD установленной на это worktree. К сожалению, агент тихонько начинает работать и так, но он почти гарантированно делает ошибки, и пишет по пути основного репозитория, и правки попадают в main. Что делать в этом случае?
- ничего страшного: как заметили правки на main, то делаем так:
- просим перенести изменения в main в рабочую ветку
- когда закончили с переносом, выходим из агента (он покажет как возобновить эту сессию через codex resume ...)
- меняем рабочую директорию
- делаем codex resume (session-id)
- "продолжить!"
▶️ Допустим, все шаги протокола выполнены, агент перевёл PR в статус Ready. Что дальше?
🏁 А дальше - этап Merge.
...
👉 Если недоследили, а в Кодексе включён автокомпакт и этот процесс прошел? Тогда кодекс восстановит контекст "по своему разумению" - там уже не будет изначально "прогретого" меморибанком контекста, и протокол восстановления контекста у него свой, он не факт что будет следовать нашему (хотя и такое случается! у меня даже отметку о восстановлении контекста добавляет);
- тут я пробовал продолжать работу - вроде бы норм, но глубоко не исследовал
- чтобы не рисковать вообще (хотя негатива от продолжения в прежнем контексте не было, повторюсь) - можно взять новый прогретый контекст и "resume" там.
- не надо делать мультикомпакт (проходить через компакт много раз)! Это официалы даже пишут в подсказке Кодекса - я пробовал, начинает чудить - вам это может не понравится
‼️ Не забываем, что для работы в worktree нужён контекст с CWD установленной на это worktree. К сожалению, агент тихонько начинает работать и так, но он почти гарантированно делает ошибки, и пишет по пути основного репозитория, и правки попадают в main. Что делать в этом случае?
- ничего страшного: как заметили правки на main, то делаем так:
- просим перенести изменения в main в рабочую ветку
- когда закончили с переносом, выходим из агента (он покажет как возобновить эту сессию через codex resume ...)
- меняем рабочую директорию
- делаем codex resume (session-id)
- "продолжить!"
▶️ Допустим, все шаги протокола выполнены, агент перевёл PR в статус Ready. Что дальше?
🏁 А дальше - этап Merge.
🔥3
#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
⚪️ Выполнение содержательной части нашего протокола закончено, агент реализовал все запланированные шаги, изменения закоммичены и лежат в 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
🔥4
#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. Важно все осознать и вместо копирования производить "усвоение", и адаптацию. Все что неясно или непонятно - спрашивайте. Самое важное - понять логику процесса, выстраивание процессов и владение этой логикой, кмк, и есть довольно важный скилл нынче.
🏁 Собственно, все
👌 В общем - такое мы практикуем! (ц)
⚪️ Итак, мы прошли все по цепочке этого простого флоу для локальной разработки
Такой порядок действий позволяет довольно легко тянуть 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. Важно все осознать и вместо копирования производить "усвоение", и адаптацию. Все что неясно или непонятно - спрашивайте. Самое важное - понять логику процесса, выстраивание процессов и владение этой логикой, кмк, и есть довольно важный скилл нынче.
🏁 Собственно, все
👌 В общем - такое мы практикуем! (ц)
🔥9👍3🤝3❤1
#DeksdenFlow и Gpt-5.1
Родился небольшой апдейт по флоу в связи с выходом Gpt-5.1
Как можно догадаться по предыдущей новости, я успел затестить.
Не знаю с чем связано, может в момент перехода с модели на модель, контексты формирвоались старой моделью - но Gpt-5.1-codex при реализации протокола (этап, когда она уже идёт "по шагам") стала как gpt-5 останавливаться и переспрашивать после каждой задачи. Замечу, что Gpt-5-codex так не делает, а работает довольно долго без этих вот "испугов" и неуверенностей
Промпт я использовалс стандартный - "Продолжай работу по плану"
И реально, вместо выполнения полного шага, модель останавливалась посередине с промежуточным отчётом.
👉 После разных экспериментов, оказалось что теперь требуется прямо сказать: "выполни шаг полностью, все его задачи" - и тогда она снова работает по 20-40 минут нормально.
В связи с чем такое поведение - не могу сказать.
Вот такое вот наблюдение
Имейте ввиду!
🟢 Upd: вскрытие показало! Видимо, 5.1 доучивали следовать инструкциям. Потому что инструкциям оно следует довольно внимательно.
Оказалось, что если сказать "действуй по плану протокола, выполняй все задачи" - то все задачи оно выполнит, а вот коммит и пуш изменений делать не будет, потому что эти инструкции были не в задачах! Это дополнительные инструкции шага, которые хз как назвать.
а вот если сказать что то вроде "выполняй все задачи шага и дальнейшие инструкции" - то все инструкции полностью выполняет!
🤔 Требования к ясности, непротиворечивости, недвусмысленности промптов, видимо, повысились. Нам нужен ЯСНОМЕТР для промптов.
#post
@deksden_notes
Родился небольшой апдейт по флоу в связи с выходом Gpt-5.1
Как можно догадаться по предыдущей новости, я успел затестить.
Не знаю с чем связано, может в момент перехода с модели на модель, контексты формирвоались старой моделью - но Gpt-5.1-codex при реализации протокола (этап, когда она уже идёт "по шагам") стала как gpt-5 останавливаться и переспрашивать после каждой задачи. Замечу, что Gpt-5-codex так не делает, а работает довольно долго без этих вот "испугов" и неуверенностей
Промпт я использовалс стандартный - "Продолжай работу по плану"
И реально, вместо выполнения полного шага, модель останавливалась посередине с промежуточным отчётом.
👉 После разных экспериментов, оказалось что теперь требуется прямо сказать: "выполни шаг полностью, все его задачи" - и тогда она снова работает по 20-40 минут нормально.
В связи с чем такое поведение - не могу сказать.
Вот такое вот наблюдение
Имейте ввиду!
🟢 Upd: вскрытие показало! Видимо, 5.1 доучивали следовать инструкциям. Потому что инструкциям оно следует довольно внимательно.
Оказалось, что если сказать "действуй по плану протокола, выполняй все задачи" - то все задачи оно выполнит, а вот коммит и пуш изменений делать не будет, потому что эти инструкции были не в задачах! Это дополнительные инструкции шага, которые хз как назвать.
а вот если сказать что то вроде "выполняй все задачи шага и дальнейшие инструкции" - то все инструкции полностью выполняет!
🤔 Требования к ясности, непротиворечивости, недвусмысленности промптов, видимо, повысились. Нам нужен ЯСНОМЕТР для промптов.
#post
@deksden_notes
🔥8👍1
Технически-экономическое
Как вы помните - я за подписки. И за выбор
Вот тут народ прикрутил CLIProxyAPI к Droid CLI чтобы работать поверх текущего CLI с подпиской - chatgpt/claude
🔗 https://github.com/ben-vargas/ai-cli-proxy-api/blob/main/USING_WITH_FACTORY_AND_AMP.md
🤟 Такое мы ценим!
Как вы помните - я за подписки. И за выбор
Вот тут народ прикрутил CLIProxyAPI к Droid CLI чтобы работать поверх текущего CLI с подпиской - chatgpt/claude
🔗 https://github.com/ben-vargas/ai-cli-proxy-api/blob/main/USING_WITH_FACTORY_AND_AMP.md
🤟 Такое мы ценим!
🔥4👍1
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
... выпустил 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
GitHub
GitHub - QwenLM/qwen-code: An open-source AI agent that lives in your terminal.
An open-source AI agent that lives in your terminal. - QwenLM/qwen-code
1❤2👍2
Экономическое, подписочки
🤟 Можем поздравить нас с этапом - $2k подписки уже на рынке.
Вот на фэктори увидел их планы. Не улавливаю в чём смысл - предлагается весьма умеренное количество токенов.
Допустим, токены не включают кэш - но ведь это тоже капец как мало. 200m за $200 и 2B за $2k! Это с х2 бонусным.
Да, есть коэффициенты - GPT-5.1-Codex 0.5×. Но опус 4.1, к слову - 6x. Клод 1.2x.
Вот в этом всем чувствуется некий "кручу/верчу" момент.
На кодексе за 200 лимиты выходят СИЛЬНО больше.
▶️ Мой ноябрь - на третьем скрине. 430m вход/выход чистых токенов (без кэша, input, output, reasonung). 9.8B всего. Не самый нагруженный месяц, к слову, и это без glm.
Это получается у фэктори я уже вышел за $200 план? и мне нужен второй акк? или $2k план? жесть.
А я этим месяцем обошёлся 3 team аккаунтами и 2 plus. итого $130.
🤔 Перекупы как есть: экономика в РАЗЫ другая чем у вендоров.
omfg
(ц) Таки подписочки нас озадачивают!
---
🟢 Upd 1: Директор Factory в беседах в твиттере пояснил - кому они включили такие подписочки. Цитата:
> Generally the profile is small teams that don't care for the enterprise features, but want:
1. lots of tokens
2. lots of touching points with our team
Хм. Вот такие желающие. Я все ещё озадачен.
#post
@deksden_notes
🤟 Можем поздравить нас с этапом - $2k подписки уже на рынке.
Вот на фэктори увидел их планы. Не улавливаю в чём смысл - предлагается весьма умеренное количество токенов.
Допустим, токены не включают кэш - но ведь это тоже капец как мало. 200m за $200 и 2B за $2k! Это с х2 бонусным.
Да, есть коэффициенты - GPT-5.1-Codex 0.5×. Но опус 4.1, к слову - 6x. Клод 1.2x.
Вот в этом всем чувствуется некий "кручу/верчу" момент.
На кодексе за 200 лимиты выходят СИЛЬНО больше.
▶️ Мой ноябрь - на третьем скрине. 430m вход/выход чистых токенов (без кэша, input, output, reasonung). 9.8B всего. Не самый нагруженный месяц, к слову, и это без glm.
Это получается у фэктори я уже вышел за $200 план? и мне нужен второй акк? или $2k план? жесть.
А я этим месяцем обошёлся 3 team аккаунтами и 2 plus. итого $130.
🤔 Перекупы как есть: экономика в РАЗЫ другая чем у вендоров.
omfg
(ц) Таки подписочки нас озадачивают!
---
🟢 Upd 1: Директор Factory в беседах в твиттере пояснил - кому они включили такие подписочки. Цитата:
> Generally the profile is small teams that don't care for the enterprise features, but want:
1. lots of tokens
2. lots of touching points with our team
Хм. Вот такие желающие. Я все ещё озадачен.
#post
@deksden_notes
❤3🔥3
Gemini CLI v0.15
... получила поддержку мыши в TUI. Теперь она работает, на клики реагирует и даже режим копирования по Ctrl+S сделали. 🥳
Глядишь, неровен час и до GUI дойдём!
Шутки-шутками, но с копированием текста и выделением её мышью действительно удобнее
... получила поддержку мыши в TUI. Теперь она работает, на клики реагирует и даже режим копирования по Ctrl+S сделали. 🥳
Глядишь, неровен час и до GUI дойдём!
Шутки-шутками, но с копированием текста и выделением её мышью действительно удобнее
👍5😁3
Вызываем оракла (думателя)
Вот такую штуку встретил:
🔗 https://github.com/steipete/oracle
‼️ Оно может завть gpt-5 PRO🔥 через браузер, давать ему контекст (файлы и папки), промпт, и получать ответ.
Использовать можно в ИИ ассистентах чтобы усилиться при необходимости получить ответ на сложный вопрос. PRO работает иногда минут по 10. Кэш запусков есть.
Работает по-можному, как CLI утилита - значит можно запихать в скилл.
▶️ В общем, запланировал посмотреть поближе,любопытно
#post
@deksden_notes
Вот такую штуку встретил:
🔗 https://github.com/steipete/oracle
‼️ Оно может завть gpt-5 PRO
Использовать можно в ИИ ассистентах чтобы усилиться при необходимости получить ответ на сложный вопрос. PRO работает иногда минут по 10. Кэш запусков есть.
Работает по-можному, как CLI утилита - значит можно запихать в скилл.
▶️ В общем, запланировал посмотреть поближе,любопытно
#post
@deksden_notes
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - steipete/oracle: Ask the oracle when you're stuck. Invoke GPT-5 Pro with a custom context and files.
Ask the oracle when you're stuck. Invoke GPT-5 Pro with a custom context and files. - steipete/oracle
👍1
MCP spec 2025-11-25 Release Candidate
Опубликован драфт новой ревизии спецификации.
Наконец то! Теперь у нас будут нескушные обои! В смысле, icons, конечно.
А если серьёзно - добавляют поддержку tasks. То есть можно серверу дать команду start, он начинает таску, и по её id можем отслеживать прогресс.
Куча воркфлоу отлично под такое попадает! Удобна!
Иконки, кстати, тоже на самом деле добавляют. Мелкое но приятное ux.
https://modelcontextprotocol.io/specification/draft/changelog
(ц) Такое мы отслеживаем
#post
@deksden_notes
Опубликован драфт новой ревизии спецификации.
Наконец то! Теперь у нас будут нескушные обои! В смысле, icons, конечно.
А если серьёзно - добавляют поддержку tasks. То есть можно серверу дать команду start, он начинает таску, и по её id можем отслеживать прогресс.
Куча воркфлоу отлично под такое попадает! Удобна!
Иконки, кстати, тоже на самом деле добавляют. Мелкое но приятное ux.
https://modelcontextprotocol.io/specification/draft/changelog
(ц) Такое мы отслеживаем
#post
@deksden_notes
Model Context Protocol
Key Changes - Model Context Protocol
🔥5
SO в Антропиках - сломались!
Тут накануне в стане SGR небольшой праздник с шампанским - Антропики выкатили поддержку Structured Outputs. То есть теперь модель может генерировать гарантированно валидный JSON.
🔗 https://docs.claude.com/en/docs/build-with-claude/structured-outputs
В СС пока поддержку такого не завезли.
Кстати, чат подкапотов первым обрадовал @yatimur
#post
@deksden_notes
Тут накануне в стане SGR небольшой праздник с шампанским - Антропики выкатили поддержку Structured Outputs. То есть теперь модель может генерировать гарантированно валидный JSON.
🔗 https://docs.claude.com/en/docs/build-with-claude/structured-outputs
В СС пока поддержку такого не завезли.
Кстати, чат подкапотов первым обрадовал @yatimur
#post
@deksden_notes
Claude API Docs
Structured outputs
Get validated JSON results from agent workflows
🔥4😁2
CodexUsage
Отдельная маленькая macOS утилита для трекинга использования лимитов кодекса.
https://github.com/steipete/CodexBar
Полезно, имхо
#post
@deksden_notes
Отдельная маленькая macOS утилита для трекинга использования лимитов кодекса.
https://github.com/steipete/CodexBar
Полезно, имхо
#post
@deksden_notes
5👍4
Ага! попался Кодекс!
Если бы такое выплыло у кого то из китов - поднялся бы дружный вой типа "ну мы знали что они все украли у клозедов/антропиков/гугла!"
А так - периодически codex сыпет иерогливами - и норм!
Что это значит - не знаю, то точно что-то
#post
@deksden_notes
Если бы такое выплыло у кого то из китов - поднялся бы дружный вой типа "ну мы знали что они все украли у клозедов/антропиков/гугла!"
А так - периодически codex сыпет иерогливами - и норм!
Что это значит - не знаю, то точно что-то
#post
@deksden_notes
😁3
И снова QA
Не то чтобы я любил эту часть разработки - но куда деваться!..
Вы в облаке мультиплатформенный софт тестите - или по старинке, в виртуалках?
#post
@deksden_notes
Не то чтобы я любил эту часть разработки - но куда деваться!..
Вы в облаке мультиплатформенный софт тестите - или по старинке, в виртуалках?
#post
@deksden_notes
MS Copilot free на год для студентов
Причастные - могут прибарахлится по ссылке!
🔗 https://www.microsoft.com/en-us/microsoft-copilot/for-individuals/ai-for-students?form=MA140R
Налетай, не зевай! ВПН на США включай!
П.С. Сработает справка "А в душе я - студент?"
П.П.С. Хоть бы кто раздавал агентов free с норм лимитом. Одна надежда - на гугл.
#post
@deksden_notes
Причастные - могут прибарахлится по ссылке!
🔗 https://www.microsoft.com/en-us/microsoft-copilot/for-individuals/ai-for-students?form=MA140R
Налетай, не зевай! ВПН на США включай!
П.С. Сработает справка "А в душе я - студент?"
П.П.С. Хоть бы кто раздавал агентов free с норм лимитом. Одна надежда - на гугл.
#post
@deksden_notes
Microsoft Copilot
AI for Students: Use AI Study Tools to Learn More | Microsoft Copilot
Get access to AI for learning with Copilot. Create AI study guides, use AI as a homework helper, and see how AI for students can supercharge your learning with Copilot.
👍1