Блог / Стаття 001

Bleverse, Reliverse, Rse: The Initial Announcement

Понад рік я будував щось, що з кожним місяцем ставало дедалі важче пояснити одним реченням. Спочатку це були інструменти для розробки. Потім з'явилися AI-агенти, власні CLI, інфраструктура для збірки й публікації пакетів, а за ними й ідеї, які вже не вміщалися в поняття developer tooling.

Поступово все це виросло у три пов'язані, але різні частини: Reliverse, Rse та Bleverse.

Сьогодні я починаю відкривати їх публічно. Не все готове. Частину вже можна спробувати, частина існує як вихідний код, а деякі речі поки живуть переважно у моїй голові та планах. Проте тепер ця історія нарешті виходить з-за лаштунків 🎉

У цій статті я хочу познайомити вас із трьома головними назвами. Якщо цікаво, звідки взялася вся ця історія, у Article 002 (заплановано 2026-11-14) я розповідаю про свій шлях від GTA, PHP та першого «інтернету» з папок до сучасного Reliverse.

У цій статті: Три назви, одна історія · Reliverse: фундамент, який не повинен ставати лабіринтом · Rse: коли одного CLI стало замало · Bleverse: усе це має бути корисним не тільки розробникам · Що вже можна побачити сьогодні · Що буде далі · Наостанок

Три назви, одна історія

Якщо зовсім коротко:

Reliverse – інструменти, бібліотеки та інфраструктура, з яких я будую програмні системи.
Rse – локально орієнтований CLI та середовище для розробника й AI-агентів, яке використовує можливості цієї інфраструктури.
Bleverse – продукти й платформа для людей: від творчих (деви це також митці!) та соціальних інструментів до застосунків, ігор та інших ідей, заради яких багато що й починалося.

Це не три назви одного й того самого застосунку. І не означає, що для користування кожною частиною потрібні всі інші.

Reliverse: фундамент, який не повинен ставати лабіринтом

Я люблю зручні інструменти. Хороший CLI, зрозумілі назви функцій, передбачувана поведінка й відсутність зайвої магії здатні принести мені майже стільки ж задоволення, скільки готовий продукт.

Reliverse виріс саме з цього захоплення. Я хотів мати власні рішення для роботи з командами, конфігурацією, збіркою, пакетами, якістю коду та керованими операціями. Частина задумів стала окремими бібліотеками, частина поступово склалася у спільну екосистему. Ось, наприклад:

Rempts (Reliverse Prompts) – автоматизує процес створення та підтримки CLI та їх плагінів завдяки file-based організації команд та їх ctx.
RQ (Reliverse Quality) – перевіряє якість й поясненює результати: задум у тому, щоб не лише сказати «щось не так», а й допомогти зрозуміти, що саме.
RPR (Reliverse Package Registry) – життєвий цикл пакетів та артефактів: їхня ідентичність, версії, розміщення й перевірка. Поки публічні релізи ще не були готові, я також використовував локальний, same-machine шлях поширення пакетів між власними проєктами.
GR (Git Reliverse) – робота з Git-станом, контрольованими змінами та кампаніями публікації. Саме GR допомагає мені поступово відкривати код Reliverse.

Це лише кілька прикладів. Не хочу, щоб перша стаття перетворилася на енциклопедію абревіатур.

Мені важливо, щоб ці частини можна було розвивати й використовувати окремо. Великій екосистемі легко перетворитися на місце, де для запуску одного інструмента потрібно встановити двадцять інших. Я зовсім не хочу, щоб це стало визначенням Reliverse. Хоча, як ви ще побачите, іноді я сам дуже старанно рухався саме в цей бік 🫠

GR: як не опублікувати весь хаос одним комітом

У якийсь момент приватний робочий стан Reliverse розрісся до тисяч змінених файлів. Частину коду я писав сам, значну частину звісно допомагали створювати coding agents під моїм керівництвом, хоча через життєві справи я не завжди міг наживо переглядати кожен turn агента. Від цього відповідальність за якість коду, перевірку та публікацію не зникала.

І, знаєте? Спочатку я всерйоз думав просто запушити все одним гігантським комітом 😅

Потім вирішив: гаразд, зроблю приблизно 10–20... Я був оптимістом...

Проблема полягала не лише в розмірі diff. Там були експерименти, застарілі рішення, речі, які ще не варто віддавати зовнішнім розробникам, та залежності, без яких публічний код не працював би. Я не хотів публікувати бібліотеки в npm лише для того, щоб люди одразу зіткнулися з відсутніми частинами.

Так із простого питання «як акуратно запушити зміни?» виросли GR Campaigns: спосіб формувати обмежений набір змін, перевіряти його, окремо авторизувати дії та звіряти результат публікації. Найперший публічний крок, Campaign001, символічно відкрив лише один файл: OPEN-SOURCING.md.

Чи перетворив я звичайний Git push на невеличку науку? Безумовно. Чи довелося потім спрощувати створене? Також так... 🤦‍♀️

Повну історію, включно з не надто героїчними моментами, я залишив для Article 003 (заплановано 2026-11-16).

RVS і RDG: не плутати план із виконанням

Є ще дві назви, які з'являтимуться в моїх матеріалах.

RVS (ReliVerse System) відповідає за середовище та керовані системні операції. Я також створив RVS Browser App, через який я поступово намагаюся зробити ті самі складні workflows зрозумілішими для себе як звичайного користувача. Зокрема, там є інтерфейс для GR Campaigns. Він ще не ідеальний, але це вже крок від нескінченних команд і технічних діалогів до чогось людянішого.

RDG (Reliverse Deploy Gateway) – окрема частина планування й координації deployment: що розгортаємо, куди, за яких умов, як перевіряємо результат і що робити у випадку проблем. Моя майбутня мета: RDG не повинен самостійно ставати привілейованим виконавцем системних команд. Дозволені дії в середовищі належать RVS та іншим відповідним виконавцям.

Цей поділ важливий для мене: вирішити, що потрібно зробити, і мати право це зробити – різні речі.

Rse: коли одного CLI стало замало

Колись я хотів просто зручний CLI. Потім захотів, щоб він допомагав із дедалі більшою кількістю роботи. А після появи сучасних LLM стало важко не поставити собі запитання: що, як поруч із командами житиме агент, який може ними користуватися?

Так поступово розвивався Rse та Rse Gateway: CLI, runtime і шлях до роботи з агентами, моделями, інструментами, задачами та власними робочими середовищами. Я намагаюся будувати це з думкою про local-first: власний комп'ютер і власні дані мають залишатися повноцінним початком роботи, а не лише клієнтом обов'язкового хмарного сервісу.

Моє бачення: Rse не повинен бути прив'язаний до одного AI-провайдера або одного способу запуску агента. Але й «агент попросив» не має означати «система без запитань виконала». Для цього в екосистемі існують окремі контракти операцій, політик та авторизації, зокрема Cap і Gatehouse. Не всі заплановані сценарії вже мають завершений публічний шлях виконання.

Rempts Plugins для Rse

Rse використовує загальну плагінну модель Rempts. Я розвивав, зокрема, інтеграції для Codex, skills та handoff. У моєму робочому дереві вони мають власні шляхи на кшталт extensions/plugins/rse/<codex|skills|handoff>.

Ці шляхи – орієнтири з розробки, не обіцянка, що на момент вашого читання цієї статті всі три вже доступні для незалежного встановлення з публічного GitHub чи registry. Коли їхній release path буде перевірений, я окремо покажу, що саме і як встановлювати.

Rse Overkill, або як я познайомився з власним монстром

У моїх проєктів є одна кумедна риса: іноді я настільки хочу «зробити правильно», що отримую рішення, складніше за початкову проблему.

Я навіть в загальному почав називати це overkill і de-overkill. Згодом практика стримання зайвого отримала власний skill: .agents/skills/avoid-overengineering/SKILL.md.

Про це хочу написати окрему історію. Там буде і про AI-агентів, і про мої промпти, і про те, чому «зроби максимально безпечно» без чітких меж іноді породжує окрему систему управління кожною дрібницею. Сміятися з цього значно приємніше, коли вже навчився виправляти наслідки.

Bleverse: усе це має бути корисним не тільки розробникам

12 листопада 1990 року Тім Бернерс-Лі та Роберт Кайо опублікували документ «WorldWideWeb: Proposal for a HyperText Project». Це була формальна пропозиція проєкту WorldWideWeb, хоча попередні ідеї Бернерс-Лі описав ще 1989 року. Оригінальний документ можна прочитати й сьогодні.

Сьогодні, 12 листопада 2026 року, я представляю Bleverse. Стаття 002 розповідає що Internet Explorer з папок був для мене першим інтернетом, знайомство з html/css/js/php/pawn другим, знайомство з npm/yarn/react третім.

Тут, в 001, я радий оголосити що наступив час на ще одне нове в певному сенсі бачення інтернету (жодного web3, take it easy, ахах 😂) - Bleverse, слоган якому я дав "Твоя нова перша сторінка інтернету" (так, це також відсилка на старий добрий Reddit 🧡), коли це буде більш відкритим, ви зрозумієте чому цей слоган має сенс і що це не просто красиві слова.

Отже, наразі поділ маємо дуже умовно кажучи ось такий:

Reliverse – це dev-first інструменти.
Bleverse – значно ширша історія про продукти для людей.
Rse – один з опційних способів користуватися всім тим що надає Reliverse та Bleverse.

Я хочу, щоб в Bleverse могли співіснувати прості люди, деви, спільноти, агенти, творчі інструменти, контент, додатки, ігри, сервіси й проєкти, які ще навіть не отримали остаточних назв. Не як один велетенський застосунок із сотнею обов'язкових кнопок, а як екосистема, у якій різні продукти можуть розвиватися самостійно й водночас працювати разом.

Це довгостроковий задум. Зараз було б неправильно показувати весь запланований каталог як уже готовий сервіс.

Bleverse UI, Components, UIR і BVF

Тут є чотири назви, які легко переплутати.

Bleverse UI – SaaS, продуктова поверхня й майбутнє місце, де люди зможуть працювати з інтерфейсами та відповідними інструментами.
Bleverse Components – повторно використовувані компоненти й візуальні елементи. Ви можете уявляти собі це як щось типу shadcn/ui. Вони не повинні бути прив'язані лише до одного застосунку.
UIR – незалежний семантичний UI-шар. Для нього я жартівливо зберіг два значення назви: User Interface Reliverse як систему та User Interface Intermediate Representation як представлення інтерфейсу. Ідея в тому, щоб опис UI не дорівнював жорстко одному React-компоненту чи одному способу рендерингу.
BVF (BleVerse Framework) – декларативна система опису й матеріалізації застосунків: сторінки, маршрути, дані, дії, політики та інші складники. Вона може створювати проєкції на кшталт API та вебзастосунку, використовуючи UIR у відповідному UI-шарі.

Наприклад, я хочу, щоб опис застосунку у BVF bvf/apps/main міг матеріалізуватися у реальну структуру apps/api/main та apps/web/main, а не залишався красивою схемою. Важливо: це архітектурний напрямок, а не твердження, що всі його варіанти вже працюють end-to-end.

Мені подобається ідея, що людина зможе створювати продукт візуально, з допомогою Rse або без нього, і за потреби отримати зрозумілий вихідний код. Не опинитися у пастці інструмента, без якого її власний застосунок більше не живе.

Важлива фішка BVF: це не фреймворк конкурент Next.js/TanStack Start/тощо (хоч і матиме опційний runtime шар), натомість це фреймворк який дозволяє вам написати BVF TS DSL файл один раз -> матеріалізувати під Next.js (до речі, генерація апки з нуля не обов'язкова, GR генерує патчі оновлення) -> за кілька місяців ви вирішили перейти на TanStack Start чи Nuxt -> відредагували DSL -> міграція в ідеальному сценарії в майбутньому займе кілька хвилин/годин, а не днів/тижнів (навіть якщо використовувати агентів).

Сервіси та Service Credits

У майбутніх Bleverse-hosted Reliverse Services я планую відрізняти підписки, включене використання та оплату додаткових ресурсів.

SC (Service Credits) – задумана одиниця вартості використання сервісів. Базовий орієнтир: 1 SC відповідає 1 USD вартості відповідних сервісних послуг, але правила й коефіцієнти конкретного host/provider можуть відрізнятися. Це не долари на балансі й не грошовий гаманець.

IU (Included Usage) – використання, покрите певним планом або правом доступу. Наприклад, Rse IU та RVS IU стосуються різних типів ресурсів. IU не треба плутати із SC, а зовнішні підписки або кредити AI-провайдерів не стають автоматично внутрішніми кредитами Bleverse.

Поки це пояснення принципів, а не анонс готової каси, тарифів чи конкретного продажу кредитів.

Що вже можна побачити сьогодні

Замість обіцяти все одразу, я почав із малого. Одна з моїх перших GR Campaigns відкрила у публічному reliverse/reliverse приклад read-only GR source inspection. Він показує стан Git-репозиторію, не встановлюючи повний GR CLI та не виконуючи commit, push чи publication. Це також працює з GitHub CI.

bun --no-install --no-env-file examples/gr/inspect.ts .

У репозиторії є також окремий тест для цього прикладу. Я свідомо не називаю це повноцінним релізом усієї системи. На мою думку один перевірюваний крок корисніший за десятки сторінок обіцянок.

Що буде далі

На момент написання цієї статті я планую:

Продовжувати відкривати код невеликими, перевірними GR Campaigns.
Показувати більше справжніх прикладів, які зовнішній розробник може повторити без моєї VPS.
Поступово знайомити вас із Rse, BVF, Bleverse та іншими частинами через окремі статті.
Відновлювати спільноту навколо Reliverse й запрошувати людей до обговорень, тестування та внесків.

Наостанок

Раніше ці проєкти здебільшого жили між моїм IDE, терміналом, агентами та величезною кількістю нотаток. Тепер я хочу, щоб вони поступово ставали чимось, до чого можуть долучатися інші люди.

Не обіцяю, що кожна моя ідея переживе наступний місяць у незмінному вигляді. Насправді досвід підказує протилежне. Але саме тому й хочу відкривати Reliverse поступово: показувати те, що вже існує, чесно розповідати про те, що ще не працює, і вчитися разом із тими, кому це цікаво.

А якщо хочеться зрозуміти, як я взагалі дійшов до того, що для звичайного git push мені знадобилася окрема система, читайте мою історію (заплановано 2026-11-14) і історію GR Campaigns (заплановано 2026-11-16) 😄

Дякую, що знайшли час прочитати цю статтю! Мені дуже приємно!

До початку

Автор: blefnk · Опубліковано: 2026-11-12T00:54:00Z · Мова: Українська · Серія: Introducing Bleverse

Усі статті

Built from BVF application composition and independent UIR presentation. No account required. GitHub · Community