Сергей Озеранский

Я всё активнее строю CI-инструментарий внутри компании, и чем глубже закапываюсь, тем очевиднее: GitHub Actions дорогой и медленный. Это не абстракция из бенчмарков, это моя ежедневная боль. И не только моя: почти каждый, с кем я говорил об этом за пределами компании, кивает с тем же выражением лица. В какой-то момент я понял, чего хочу на самом деле. Двух вещей. Первое: честную математику. Чтобы я платил за compute, который реально потратил, а не за округление в чью-то пользу. Классика индустрии: каждый джоб округляют вверх до минуты. Запустил 500 коротких джобов по 8 секунд, плати за 500 минут вместо ~67. Для агентного CI это скрытый налог в разы. Второе: понимать, где и как исполняется мой код. Не чёрный ящик, не слепое доверие, а прозрачность: что крутится, на каком железе, сколько потрачено и сколько осталось, прямо сейчас, а не в инвойсе через две недели с неожиданной суммой. Так что я не стал ждать и пошёл строить своё. А уже в процессе наткнулся на статью Forestwalk, и она будто подписалась под каждым моим тезисом. Короткая суть: команда ушла с GHA на Blacksmith по той же причине, дорого и медленно. "Try for free, no credit card required". Покодили, получили пару писем "добавьте карту, чтобы избежать disruption", а через пару недель прилетел инвойс на $1081. Сразу просроченный. Nice... А "disruption", как выяснилось из ответа саппорта, оказался не остановкой джобов, а "флаггингом аккаунта на review". То есть free-лимит пробит, а джобы продолжают крутиться и копить деньги. Сюрприз. Формально честно. По-человечески: ровно то, против чего я и строю свой продукт. Поэтому в основе tempus.build (именно так называется продукт): • Прозрачность: видишь исполнение и расход в реальном времени. А образ раннера OSS (https://github.com/tempusbuild/runner-images). • Скорость: bare-metal, без оверхеда managed-облака. Та самая причина, по которой с GHA и бегут. • Честное округление: посекундно, платишь за то, что реально использовал. • Prepaid: кредиты кончились, сервис встаёт на паузу, а не в долг. Счёт-сюрприз структурно невозможен. Free значит free. Платишь, видишь за что. Сейчас я открываю продукт и зову тестировать. Если ты сидишь на GitHub Actions и тебе знакома эта боль, давай, го. Мне нужны как раз такие люди. И еще, подписывайся на @tempusbuild: в ближайшие дни выложу первые бенчмарки на реальных больших публичных репо и буду рассказывать про запуск. Будет интересно.

a

Компания SpaceX Маска приобрела стартап, занимающийся разработкой программного обеспечения для искусственного интеллекта, за 60 млрд долларов через несколько дней после IPO. Речь идет про Cursor. Ощущение, что Маск просто на сдачу купил компанию. https://www.bbc.com/news/articles/cvgd5g7d7gyo

У многих компаний есть Telegram-боты, мобильные приложения, внешние интеграции, системы уведомлений и другие сервисы, которые завязаны на доступность определенных внешних площадок. Можно проснуться утром и обнаружить, что часть бизнеса перестала работать. Не из-за бага. Не из-за инцидента внутри компании. А из-за того, что очередной кусок сетевой инфраструктуры перестал быть доступным так, как был доступен еще вчера. В итоге самая большая проблема даже не в отдельных сбоях. Инфраструктура всегда ломалась и всегда будет ломаться. Меня больше беспокоит снижение предсказуемости среды. Когда раньше инженер мог достаточно уверенно прогнозировать поведение инфраструктуры, а теперь приходится учитывать все больше внешних факторов, на которые ты никак не влияешь. И мне кажется, что главная проблема здесь даже не в скорости интернета и не в количестве сервисов. А в росте операционных рисков. Раньше многие вещи воспринимались как данность: облако работает, сеть работает, DNS работает. Теперь все чаще приходится закладывать вероятность того, что проблемы возникнут именно на том уровне, который раньше считался стабильным. И мне кажется, что эхо происходящего мы будем наблюдать еще много лет.

Последние несколько лет по своим ощущениям наблюдаю деградацию качества интернета. И речь даже не про какой-то конкретный регион. Проблемы есть глобально. Хотя, если честно, по моим наблюдениям российский сегмент интернета за последние годы стал заметно менее предсказуемым с точки зрения доступности сервисов и инфраструктуры. При этом замечаю я это не как обычный пользователь сайтов и приложений. В первую очередь я замечаю это как инженер, который постоянно работает с инфраструктурой, облаками, сетями и сервисами. Если посмотреть на мир в целом, то за последние годы мы видели несколько крупных сбоев, например, Cloudflare, которые затрагивали существенную часть интернета. Бывают аварии у магистральных провайдеров. Никто не идеален. Но как пользователь облачной инфраструктуры я стал сталкиваться с крупными инцидентами чаще, чем несколько лет назад. Я по ряду причин принял решение, что часть нашей инфраструктуры должна находиться в России. Это компромисс между надежностью, доступностью, требованиями бизнеса и здравым смыслом. И я хорошо помню время, когда российские облака по моим ощущениям были вполне конкурентны по стабильности. Сейчас ощущения уже другие. Не буду называть конкретного провайдера, но без преувеличений за месяц может происходить один-два крупных инцидента, которые потенциально влияют на мою инфраструктуру. Один такой инцидент уже приводил к частичной недоступности наших сервисов. Другой затронул нас недавно, но там уже спасла подготовка и архитектурные решения. Самое неприятное, что некоторые проблемы невозможно нормально митигаировать. Если у провайдера начинают отказывать внутренние системы управления или биллинг, то мультизональность и резервирование не всегда помогают. Облако без работающего биллинга — это, как ни странно, тоже проблема. Ресурсы нужно учитывать, создавать, удалять и обслуживать. И это может и задевает клиентов облака. Не прошла оплата - блокируется облако. Хотя не прошла она по причине облака. И это уже не тот класс рисков, который решается настройкой еще одного балансировщика. Еще одна история, которая мне кажется недооцененной — это публичные IP-адреса. Кто работает с облаками, наверняка уже сталкивался с тем, что получить нужное количество IPv4 становится все сложнее. Появляются квоты. Появляются согласования. Появляются ограничения на расширение. Мне даже попадались предложения по продаже аккаунтов различных облаков с уже выделенными пулами IP-адресов. И это тоже симптом. Адреса пачками скупаются под VPN. И это сейчас расходник. Заблокировали один, купили другой. При этом появляется проблема — репутация адресов. Освобожденный IP возвращается в пул и может достаться новому владельцу. Но его история никуда не исчезает. Если раньше адрес использовался VPN-сервисом, прокси или чем-то еще, что привлекало внимание различных систем фильтрации и блокировок, новый владелец вполне может получить адрес с уже испорченной репутацией. Причем речь не только про антиспам-системы или внешние блоклисты. Отдельный риск — различные ограничения на уровне сетевой связанности и фильтрации трафика. Если IP раньше использовался сервисом, который попадал под блокировки, последствия вполне могут ощущаться и следующим владельцем адреса. Очень похоже на ситуацию с доменами. Покупаешь домен, а потом выясняется, что несколько лет назад на нем был спам, казино или еще что-нибудь интересное. Приходится отмывать репутацию. С IP-адресами, как мне кажется, ситуация становится все более заметной. Причем это не какая-то теоретическая история. Я уже сталкивался с ситуациями, когда поднимаешь новую виртуальную машину, получаешь новый публичный IP-адрес, а часть внешних ресурсов уже недоступна или работает нестабильно. И таких историй в моем окружении становится больше. Что-то работало вчера. Сегодня не работает. Не потому что кто-то выкатил релиз. Не потому что сломался код. Не потому что упал сервер. А потому что изменилась сетевая связанность между отдельными частями интернета. И проблема даже не в обходе блокировок.

Несколько наблюдений о Сербии: Дисклеймер, я в стране второй день и конечно мои впечатления основаны на первичной оценке и их того что вижу то и думаю. Данный пост не несет никакого негатива, это просто мои наблюдения. 1. Я думал в Валенсии много граффити, но нет. Белград, вот где все творчество уличных художников собрано. 🧑‍🎨 2. Много красивых исторических зданий, но к сожалению они очень уставшие и грязные. Но красиво. 3. Просто много очень уставших и грязных зданий. Как мне сказали, это копоть, из-за отопления углем. Я не проверял, но не исключаю. Похожее видел в Алматы, в отопительный сезон над городом был черный слой. Особенно его было видно с колеса обозрения. 4. Интересный язык. Я сербский раньше не слышал. Интуитивно догадываюсь о чем речь (не всегда конечно), но воспроизвести не могу 😅. 5. Бесплатный общественный транспорт. 6. Жарко. 🥵 По моим ощущениям жарче чем в Валенсии сейчас. 7. Контрастно, есть что-то культурное, а рядом заброшка, например. Но бывает где угодно. Тут просто это бросается в глаза мне сильней. 8. В воздухе пахнут привычные деревья, липа, например. 9. Дунай, крепость на берегу реки. Такое мне нравится 👍. 10. Еда жирная, соленая и везде есть лук (сырой) нескольких видов. Вкусно и понятно для меня. Еще вкусные овощи (помидоры и огурцы). 11. С кем разговаривал, все говорят на Английском. 12. Бутылка обычной воды и мороженое Марс стоит 150 RSD = 1.28 EUR 🤔

Итак, про айтишный кемп. Начнем издалека. Кто вообще эти ребята, которые его организовали (третий год уже, между прочим). Давным-давно, в далекой галактике, инженер под ником “Вастрик” создал свой клуб. Я не знаю деталей создания и мотивации, но вылилось это в очень серьезное и большое комьюнити из очень интересных и разносторонних людей. В сообществе не только айтишники, но и просто гики, увлеченные своим делом. Это может быть стоматолог или ученый-физик. “Всё самое интересное происходит за закрытыми дверями” — так написано на главной странице клуба. И нельзя не согласиться 🙂 И как же открыть эту дверь? Очень просто — 15 евро в год стоит членство в клубе. Это очень формальная сумма, но, судя по всему, этого достаточно, чтобы исключить случайных посетителей. В клубе есть свои правила и ценности. При этом в правилах нет ничего такого, чего не делал бы здравомыслящий человек. Я в клубе уже 4 года, но сам клуб старше — я точно не знаю, сколько ему лет. Узнал я о нем совершенно случайно. Каким-то образом, вероятно через поисковую выдачу, попал на главную страницу клуба и увидел там превью статьи своего знакомого, которого очень уважаю как инженера и стартапера. Спросил у него про клуб и понял, что мне там точно нужно быть. Нет ни дня, чтобы я пожалел о вступлении, и каждый год продление членства даже не стоит вопросом 🙂 Что мне это дает? Многое. В каждом городе и в каждой стране, где я был, есть ячейка часть комьюнити Вастрик Клуба. Есть вастрик-сходки по инициативе членов клуба, где можно поныть об айтишечке, попить пива, познакомиться и просто хорошо провести время. Есть регулярно проходящие крупные мероприятия, информацию о которых можно посмотреть на сайте клуба. И как раз завтра начнется Вастрик Кэмп — в Свободной Республике Либерленд. Да-да, есть такое интересное место на западном берегу Дуная между Хорватией и Сербией. Еще я хотел поучаствовать в Вастрик Флот (можно было даже пройти обучение и получить международную лицензию шкипера), но места раскупили молниеносно, и я не успел попасть. Но ничего, будет еще — и обязательно пойду в море с клубчанами 🙂 Клуб — это не место, где ты только тусуешься. Это еще и контент. Очень интересный и разнообразный. И не только про айти: — путешествия — релокация — наука — секс — да вообще все что угодно, если это интересно клубу Создают контент сами клубчане — бесплатно, но с душой. При этом в клубе очень открытая и теплая атмосфера. Например, соклубник может дать тебе рефералку в свою компанию. Для этого есть отдельные треды каждый месяц: какая компания кого хайрит и кто готов дать реф. НО! Как гласит одно из правил клуба: “Прося что-то у Клуба — давайте ему что-то взамен”. И это логично, понятно и справедливо. Не буду писать почему — мне кажется, это реально не требует пояснений. Если не знаешь, чем помочь — спроси. Или напиши интересную статью для соклубней. Нужно просто проявить немного проактивности. Не хвастаюсь… а может и хвастаюсь 😅 Но я посидел несколько вечеров в исходниках клуба (это OSS, между прочим) и немного поконтрибьютил: 57 commits, 33,059 ++, 18,325 -- В итоге стал №2 контрибьютором после самого основателя и автора клуба. Но в первую очередь мне просто хотелось это сделать, а не потому что это было чем-то обязательным.

Я в будущее попал. Сейчас я в небе. Лечу Air Serbia. А тут Starlink. БЕСПЛАТНО, БЕЗ РЕГИСТРАЦИИ, БЕЗ СМС

Немного пропал, но тому есть причины. Я работал 😅 Много. Так как роль в компании у меня ключевая и многие задачи и процессы в компании завязаны исключительно на мне, то мне, например, нельзя болеть и ходить в отпуск. Что вполне логично и справедливо. Поэтому, чтобы хотя бы недельку посвятить своим желаниям и отдыху, нужно много поработать до этого. Что я и делал. Справедливо спросить: почему многое завязано на мне? Ответ простой. Когда строишь что-то новое внутри компании и важна скорость достижения результата — не до делегирования или какой-то крупной проектной работы с кучей ответственных. Это все будет, но потом. Сначала бизнесу нужно заработать деньги. Собственно, ничто так не стимулирует работу, как желание пойти в отпуск 😅 И последний месяц мой фокус был таким: перестать быть незаменимым. Вообще это стратегия более долгосрочная, но за месяц я избавился почти от любого ручного труда с помощью разработки нужных инструментов, автоматизации и делегирования. Последнее, кстати, было бы невозможно без инструментов и автоматизации. Жить, на самом деле, стало легче всем. Появляется четкая ответственность, снижается ручной труд, а значит и вероятность ошибок. (Код же без багов 😆) Но я, конечно, сейчас про человеческий фактор. Вернемся к тому, ради чего я это все затеял. Я еду в Сербию и буду жить в лесу в палаточном лагере с другими айтишниками и им сочувствующими 😅 Это как конференция, только: — в лесу — в палатках — без HR В планах: жечь костер, спать в палатке и общаться с интересными людьми. В лагерь едет порядка 150 человек. Следующим постом расскажу про сам лагерь и это интересное закрытое комьюнити.

Почему-то вспомнил о самом, наверное, странном фрилансе в моей жизни. И нет, это не история про то, как меня кинули 😅 Мне кажется, это был примерно 3–4 курс института. Учился я тогда в Курске, в Курском институте менеджмента, экономики и бизнеса. И вот каким-то чудом (уже даже не помню каким образом) связала меня судьба с воинской частью. Точнее — с заказчиком оттуда. Моим заказчиком оказался сотрудник воинской части, а задача звучала примерно так: Есть старый компьютер на Windows (и, кажется, там был даже не XP), и нужно разработать десктопную программу для журналирования действий. В определенное время оператор ЭВМ должен нажимать кнопку в программе, а это действие логируется. Примерно как в Lost 😅 (возможно я спас мир?). Так как у нас в институте Java была основным языком на ООП, я и выбрал Java. Сама задача была максимально простая. Но максимально странная 🙈 И я, если честно, так и не понял, зачем вообще была нужна эта программа. Чтобы установить программу, я носил ее на флешке в воинскую часть и ставил на компьютер в каком-то кабинете. Достаточно атмосферно 😁 сейчас бы я не пошел 😂. К слову, если память не изменяет, писал тогда программу на Java 6. А у вас были странные задачи/заказы/проекты?

На фоне очередного инцидента в GitHub, вспомнил о существовании интересного ресурса https://mrshu.github.io/github-statuses/ Это более подробная информация о статусе GitHub сервисов, чем та, что на официальном https://www.githubstatus.com/ Кому-то будет возможно полезно. Этот ресурс из интеренсо показывает реальный SLA. И, по моему мнению, это крайне низкий показатель https://uptime.is/86.75 И еще, "забавный" факт https://damrnelson.github.io/github-historical-uptime/ Этот график показывает Uptime GitHub до покупки их Microsoft и после. Даже не знаю какой вывод сделать 😳🙈

Я очень долго ждал этой фичи в Grafana. Я люблю декларативный подход в описании конфигураций и всего остального. Изъясняться as code намного проще, полезнее и даже безопаснее, чем "накликивать" что-то в UI. И так уж сложилось, что в Grafana годами не было нативного адекватного способа работы с декларативным описанием дашбордов. Да, был экспорт в JSON, и его можно было руками сохранять в Git, но это не решало проблему единого источника правды и не помогало в части декларативности описания конфигурации дашборда. Несколько лет назад я искал инструменты, чтобы иметь возможность описывать дашборды на том же Python, и находил что-то, но выглядело это как нечто экспериментальное и не особо активно развивающееся. Сейчас мы приблизились к решению - Grafana Foundation SDK и Git Sync. Очень интересно.

Стало интересно "пузомеркой" (олды слово вспомнят) помериться 😅 Возьмите свой самый большой сервис и напишите в коментариях • кол-во тестов (параметризиация считается), то есть сколько тестов реально выполняется за прогоц всего, всех. • время за которое прогоняются все тесты у вас на машине. Предполагаю что это в среднем MacBook Pro 2-3 летней давности.

Как мой шестилетний сын подобрался к семафорам Пекли сегодня с сыном (6 лет) пирожки с разными начинками (важно для контекста). Сели есть. Он показывает мне конфету и читает по обертке название - "Semaphor". Меня триггернуло флешбеками (*мем про собаку и Вьетнамские флешбеки*), и я говорю: "Слушай, а ведь в программировании тоже есть семафоры". Он подумал секунду и выдает: "Пап, а давай я угадаю, зачем они нужны". Я: "Давай." Далее ответ шестилетки: "Если у вас что-то идет, в программировании, чтобы это попало в нужное место назначения. И чтобы другое прошло, они ждут то, что надо, чтобы прошло. Ну, например, чтобы изюм попал в пирожок, а слива - в сырник. Чтобы не попало изюм в сырник, а слива в пирожок - вот для этого семафоры." Я сначала сказал: "Ну, сигнал от семафора ждут, да, ты прав". А потом, пока мы продолжали разговор и уже рефлексируя над его мыслями, я начал понимать, что все не так просто. Что описал ребенок. Он самостоятельно, хоть и имея уже за плечами свой первый "Hello, World!" (на Python, конечно же) за плечами, он пришел к идее, что в программе что-то может кого-то ждать. Человек приоткрыл дверь в в мир конкурентности, и он ее открыл сам. Конкретно его метафора, про изюм в пирожок и сливу в сырник, это скорее маршрутизация: каждому ингредиенту свое изделие, каждый едет своей дорогой. В коде это две независимые очереди, и они физически не пересекаются. Семафор тут формально не нужен, но интуиция "что-то должно следить, чтобы все попало куда надо" как раз семафорная по духу. Он почувствовал задачу раньше, чем научился ее точно формулировать, а это, честно говоря, и трудная задача в программировании. Где тут семафор живет по-настоящему. Я попробовал поправить: "Тут скорее, чтобы слива попала по своей очередности в пирожок в тот же, куда попадал изюм". То есть пирожок один, и изюм со сливой оба хотят в него попасть - нужна очередность, кто-то первый, кто-то ждет. Это уже ближе: один общий ресурс, несколько претендентов, правило доступа. Это мьютекс (семафор со счетчиком 1). А если развернуть дальше, то N одинаковых ресурсов и M претендентов, где M > N. Десять пирожков на столе, пятьдесят ягод рвутся внутрь. Пускаем по десять за раз, остальные ждут. Вот это уже полноценный семафор Дейкстры со счетчиком больше единицы. Классический пример в реальном коде это пул из десяти коннекшенов к базе и пятьдесят воркеров, которые эти коннекшены честно делят. Мы с ним по сути прошли путь от интуиции к определению за один разговор на кухне. Он задал верное направление, "что-то ждет, чтобы не было путаницы", а точная модель (одно место, несколько претендентов, очередность) дошла уже дальше при рассуждениях.

🛡️ httptap получил OpenSSF Best Practices Silver Это не просто галочка. OpenSSF (при Linux Foundation) это те ребята, что следят за безопасностью на уровне всего opensource. Silver - средний из трех тиров (passing -> silver -> gold), и чтобы его получить пришлось закрыть 43 критерия поверх 67 passing-уровня. Gold solo-мейнтейнером структурно не берется, так как нужны 2+ активных reviewer'а. Что конкретно сделано - SBOM на каждом релизе (CycloneDX + SPDX), вы видите все зависимости прямо в GitHub Release - SLSA v1.0 build provenance через Sigstore keyless signing, можно проверить артефакт: gh attestation verify httptap-*.whl --repo ozeranskii/httptap - Отсутствует долгоживущий PyPI-токен - OIDC Trusted Publishing, подпись приходит из GitHub, а не лежит в секретах - Все actions в workflows запиннены по SHA (zizmor pedantic в CI блокирует любой unpinned action) - Published threat model (https://docs.httptap.dev/security/assurance-case/) - STRIDE-разбор, trust boundaries, 17 countered CWE, residual risks - GOVERNANCE.md, ROADMAP.md, SECURITY.md - описание кто мейнтейнит, как принимаются решения, continuity plan, план реакции на уязвимости (+ VEX-документ прикладывается к релизам) Зачем это вам Если вы подтаскиваете httptap в корпоративный CI или docker-образ, то комплаенс-вопросы снимаются разом: - CRA-ready (EU Cyber Resilience Act), NIST SSDF-совместимо - OpenSSF Scorecard: ~7.6/10 (структурно выше без соавтора уже не поднять) - Попутно получен OpenSSF Baseline-3 - еще один фреймворк, более регуляторный Пройденные уровни - Passing (67 критериев) → https://www.bestpractices.dev/en/projects/12474/passing - Silver (текущий уровень) → https://www.bestpractices.dev/en/projects/12474/silver - Scorecard → https://scorecard.dev/viewer/?uri=github.com/ozeranskii/httptap - Assurance case → https://docs.httptap.dev/security/assurance-case/ Мне было интересно пройти этот путь, так как я кое-чему научился. А еще подтвердил, что в целом проекте многие пункты уже закрывал автоматически, так как бОльшая часть была уже сделана ранее. То есть сам проект уже писался в парадигме лучших DevSecOps практик.

🚀 httptap 0.5.0 и новая --slo фича Закрыл пробел функциональности: httptap теперь не просто показывает, где деградировал latency, а может фейлить pipeline на нарушении бюджета. Один флаг в команде httptap и latency становится частью CI-gate'а.

httptap --slo total=500,ttfb=200 https://api.example.com/health

Уложились -> exit 0. Деградировали -> exit 4 + полный отчет видно какая фаза убила бюджет. 6 сценариев применения (примеры примитивны, важна идея) 1. Smoke-тест после деплоя в - run: httptap --slo total=2000,tls=300,ttfb=800 https://staging.example.com/ 2. Kubernetes readiness probe

  readinessProbe:
    exec:
      command: [httptap, --slo, "total=5000", "http://localhost:8080/healthz"]

Pod принимает трафик, пока реально не отвечает за требуемое время. 3. Synthetic monitoring cron

  * * * * * httptap --slo total=1000,ttfb=500 https://api/health \
    || curl -X POST https://alerts/page/oncall

On duty просыпается когда latency деградировала, до того, как пользователи начнут жаловаться. 4. Замерили нормальную p95-latency один раз (скажем, 450ms), вшили как --slo total=450 в CI и теперь любой PR, который замедлил endpoint, краснеет автоматически, до того как медленный код доедет до прода. 5. Canary-сравнение по регионам

  for host in prod-eu prod-us prod-ap; do
    httptap --slo total=1500 "https://${host}.example.com/api" \
      || echo "${host}: SLA miss"
  done

Мгновенно видно, какой регион отваливается от SLO. 6. Dependency health в CI Когда ваш сервис зависит от внешнего API, то добавьте httptap --slo total=X этого API в мониторинг. Падение upstream'а вы заметите по алертам мониторинга еще до того, как он повлияет на прод. Что ещe приехало с релизом • Per-phase budgets --slo dns=50,connect=100,tls=300,ttfb=500,total=1000. Не только total. • Точная диагностика: total: 723.4ms > 500ms (+223.4ms), видно не просто деградировали, а на сколько именно. • Совместимость с httpstat: exit 4 и токены slo=pass/fail специально совпадают. Зачем вам это, если у вас есть APM? APM показывает что было. SLO-gate блокирует чтобы не стало. Прод не падает из-за того, что метрика красная в APM, прод падает, потому что медленный код доехал до прод-релиза или есть медленные зависимости API. --slo в CI это linting для latency. PR: https://github.com/ozeranskii/httptap/pull/118

Я использую в работе, каждый день Claude code. Технология LLM продуктов развивается каждый день, что я не успеваю успевать пробовать новое 😅 Накидайте, пожалуйста, ваши любимые MCP, RAG и прочее что вы используете и для чего. У меня набор сейчас крайне маленький: - context7 - Sequential Thinking Чего я хотел бы, это попробовать долговременную память и больше в агентов и скиллы. Я описываю инструкции для проектов для Claude code, но кажется этого мало

И да, мы люди, нам тяжело удерживать эти правила в голове, это нормально. Поэтому существуют инструменты, которые нам помогают не забывать. Это такие инструменты как разного рода линтеры, чекеры и аудиторы. Они как раз и закрывают эту проблему. Вот, например, интересный инструмент для статического анализа GitHub Actions: https://github.com/zizmorcore/zizmor https://docs.zizmor.sh/ И в нем как раз есть правило https://docs.zizmor.sh/audits/#dependabot-cooldown про тот самый dependency cooldown. Я zizmor пока не пробовал, но планирую его попорбовать на https://github.com/ozeranskii/httptap