Тред: Самопиар — покажи свой пет-проджект (Август-Сентябрь 2026)

🔗 Ссылка:

• 🔗 GitHub / NoemaForge
• 📖 README — что уже есть и как устроено
• 👍 LinkedIn — лайкосборник — если хочется помочь проекту самым ленивым способом, можно потыкать лайк/коммент там :)
• 🔐 Trust boundaries — что системе принципиально нельзя делать автоматически

❓ Что это такое?

Делаю NoemaForge — local-first AI operating layer / control plane для моделей, агентов, инструментов и пайплайнов.

Начиналось примерно с мысли:

«Хочу, чтобы несколько ИИ могли сами делать полезные вещи на моём компьютере, БЕЗ безумной оплаты токенов и желательно чтобы сами».

Потом появилась вторая, несколько более важная мысль:

«…но, наверное, не стоит просто давать им sudo, GitHub, видеокарту и надежду на лучшее».

Так постепенно выросла система, в которой локальные и внешние модели можно объединять в пайплайны и роли, но действия проходят через управляемый control plane: политики, approval gates, capability tokens, журнал событий и попытку всегда иметь ответ на вопрос кто, что, зачем и с каким результатом сделал.

То есть идея не в очередном чате с выбором модели в dropdown, а скорее в локальной ОС / среде исполнения для AI, где агенты могут долго жить и работать, но не должны получать бесконтрольную власть над машиной.

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

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

Поэтому NoemaForge — ещё и эксперимент на тему «сколько AI можно вернуть пользователю домой», не отказываясь при этом от внешних моделей там, где они действительно лучше.

🎉 Обновления и достижения за прошлый месяц

За последний месяц проект довольно бодро перешёл из стадии «у меня есть прекрасная архитектурная диаграмма» в стадию «чёрт, теперь всё это ещё и надо заставить работать вместе».

Что успело произойти:

• появился более цельный Admin GUI / Control Plane и единый CLI noema;
• продолжил оформляться ToolProxy — deny-by-default шлюз между агентами и реальными инструментами;
• сильнее разделились обычные действия, привилегированные действия и действия, требующие явного подтверждения человека;
• продолжилась сборка agent/pipeline runtime с ролями, контекстом, evidence и независимыми проверками;
• заметно разрослись CI, security checks, release validation и система доказательств того, что «оно работает» означает чуть больше, чем зелёная галочка одного теста;
• отдельно начал интегрироваться night_watch — внешний контур, который должен оставлять агентов работать без меня, находить проблемы, предлагать исправления и проверять их, не получая возможности незаметно переписать себе тесты и объявить победу;
• часть night_watch уже дошла до UAT/read-only integration и idempotency-проверок, часть всё ещё с удовольствием ломается на реальной машине. То есть всё по плану;
• параллельно продолжаю собирать миссию, ограничения и направления будущих пайплайнов: knowledge, assistants, multimodal, 3D/media generation и прочие вещи, которые зачем-то решил поместить в одну систему.

Желаемый цикл для автономной разработки сейчас выглядит примерно так:

нашёл проблему → локализовал → предложил patch → проверил → regression tests → независимая проверка → evidence → только потом изменение

вместо:

что-то не работает → поменял 17 файлов → поменял тест → тест зелёный → всем спасибо

А ещё постепенно строю промышленную систему для культурного крысинга хороших идей из open source с обязательным творческим переосмыслением.

До «готового продукта» ещё далеко. Но уже достаточно близко к работающей системе, чтобы ошибки стали гораздо интереснее :)

Что-то кажется, формат комментов не из того треда)

🔗 piburn

Относительно недавно я решил собрать небольшой kubernetes-кластер из raspberry pi. Пока самый простой: n raspberry, n карт памяти, соединение самым тупым способом - через wi-fi. И тут оказалось, что для простого действия "подготовить n карт памяти, чтобы вставить их в малины" - требуется куча лишних фрикций:

• Проверить карту памяти с помощью специальной тулзы для проверок карт памяти.
• Выбрать все настройки по типу имени пользователя и так далее.
• Скачать и установить прошивку на карту.
• Потом отдельно для каждой карты настраивать avahi, чтобы в локальной сети карточки откликались на имена вроде pi-1.local, pi-2.local и так далее.
• Раскатать дистрибутив k3s.

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

piburn представляет из себя CLI-утилиту, которая последовательно задает тебе вопросы по типу:

• Сколько малин ты хочешь прошить?
• Какой у тебя wifi?

... и так далее.

После чего она тебе предлагает по очереди вставлять карты памяти в кард-ридер, и для каждой абсолютно автоматически проделывает все нужные действия: проверяет карту памяти, скачивает образ ubuntu, закидывает его на карту, проверяет валидность записи, проводит все базовые настройки. Ты потом вставляешь карты в малины и они тебе из коробки становятся доступны по локальным адресам для подключения по ssh командами вроде ssh pomponchik@pi-4.local.

Больше того, утилита также предлагает сгенерить готовый ansible inventory файлик для всех прошитых малин, и если ты соглашаешься - делает это. Это позволяет потом накинуть на малины вещи вроде k3s (дистрибутив kubernetes) одной командой.

По пути пришлось решить некоторые технические проблемы. Например я обнаружил, что в процессе прошивки мак иногда засыпает, и в этом случае прогресс может сбрасываться. Поэтому в утилиту была добавлена временная защита от засыпания.

ⓘ Работает пока только для маков. Навайбкожено, но с любовью: реально используется, багфиксится, покрыто сотнями тестов.