# Solidus

*Добре спроєктований опенсорсний комерційний фреймворк, який тихо втратив свого доглядача вдруге за десять років, — і конкурент, що повернувся з мертвих із бізнес-моделлю за плечима.*

> Звіт · ред. 27 · оновлено 2026-08-09 · 118 тверджень із джерелом · https://vit-panchuk.com/uk/reports/solidus/

---

```
Доказова база — 118 тверджень із джерелом
[знайдено]    █████████████████████░░░░░░░░░░░░░░░   58%  (68)
[веб]         ██████████░░░░░░░░░░░░░░░░░░░░░░░░░░   27%  (32)
[стейкхолдер] ████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   10%  (12)
[виведено]    ██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░    5%  ( 6)
[припущено]   ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░    0%  ( 0)
```

---
Добре спроєктований опенсорсний комерційний фреймворк, який тихо втратив свого доглядача вдруге за десять років, — і конкурент, що повернувся з мертвих із бізнес-моделлю за плечима.

Три чверті цього звіту спираються на те, що я прочитав безпосередньо в репозиторії, git-історії та публічних фінансових записах. Це міцна база для питань факту. Вікна свідчень: початковий прохід тривав 18–25 липня 2026 року, 3 серпня один член Core Team відповів на питання, а для цієї редакції твердження, на яких щось тримається, 8 серпня звірено наново з живою системою.

## З чого почати

Цей розділ потрібен, щоб решта звіту мала сенс без попереднього знання Solidus. Якщо ви вже знаєте проєкт і гравців, переходьте одразу до [Політик і операцій](#політики-й-операції) — шар ухвалених рішень іде першим, а [хронологія](#хронологія) одразу після нього несе історію.

### Що таке Solidus насправді

Solidus — це не хостований магазин, у якому ви реєструєтеся, як Shopify. Це **набір бібліотек Ruby on Rails, які ви встановлюєте у власний застосунок** — ви запускаєте сервери, ви володієте базою даних, ви пишете кастомізації. У Ruby такі бібліотеки поширюються як «геми», і Solidus постачає їх близько восьми.

Ті, що важать для цього звіту:

- `solidus_core` — комерційний домен: замовлення, товари, платежі, доставка, податки.
- `solidus_backend` — *оригінальний* адмін-інтерфейс. Збудований у старішому стилі Rails на jQuery. Досі той, яким користуються.
- `solidus_admin` — *новий* адмін-інтерфейс, розпочатий 2023 року, щоб замінити старий. Досі незавершений. Значна частина цього звіту — про те, чому.
- `solidus` — «мета-гем»: пакет, який сам нічого не встановлює і просто перелічує, які з решти ви отримуєте за замовчуванням. **Те, які геми він називає, — фактично офіційна позиція проєкту щодо того, що готове.** Стежте за ним.

> Solidus — не хостований магазин: це набір бібліотек для Rails, які ви встановлюєте у власний застосунок — ви запускаєте сервери, ви володієте базою даних, ви тримаєте в себе кожну кастомізацію.

### Хто причетний

- **Nebulab** — італійська e-commerce-консалтингова компанія, \~27 людей. Названі в документі про врядування Директором проєкту — роль, що охоплює бізнесовий та організаційний напрям. Перебрали опіку 2018 року й залишаються фандером верхнього рівня. Їхній *інженерний* внесок від 2024 року впав майже до нуля — центральна нитка цього звіту.
- **Super Good Software** — канадська консалтингова компанія на чолі з Джаредом Норманом. Нині найбільший контриб'ютор коду і, нарівні з іншими, найбільший фандер. Здорова й активна.
- **Stembolt** — агенція, що створила Solidus 2015 року, форкнувши Spree. Придбана JUUL Labs 2018 року — і зупинила роботу. Перший доглядач, який пішов.
- **Spree · Vendo** — Spree — проєкт, від якого Solidus відгалузився: покинутий 2015-го, комерційно відроджений, нині головний конкурент. Vendo — компанія, що продає його платну Enterprise Edition.
- **Open Source Collective** — американська неприбуткова організація, «фіскальний хост». Solidus — не юридична особа й власних грошей не тримає; OSC юридично тримає пожертви й оплачує схвалені витрати.
- **Мерчанти** — онлайн-магазини середнього сегмента: direct-to-consumer-бренди, продавці автозапчастин, книгарні. Більшість прийшла через одну з агенцій, і чимало з них фінансували проєкт напряму.

### Як читати нотацію

Кожне фактичне твердження несе тег, що показує, звідки воно взялося. Це базова дисципліна фреймворку — вона не дає впевненим на слух здогадам зійти за знахідки.

|  |  |
| --- | --- |
| `[observed]` | Побачено безпосередньо в системі — код, прочитаний у репозиторії, виконана команда, git-історія, відповідь API. |
| `[web]` | Перевірено за зовнішнім джерелом — власний сайт вендора, перелік релізів, преса. |
| `[user]` | Сказано стейкхолдером — кимось із проєкту, хто відповів напряму. Авторитетно для бізнес-фактів, але може бути переглянуте; перепідтверджується там, де на ньому щось тримається. |
| `[inferred]` | Виведено зі свідчень. Правдоподібно, але не встановлено. Не спирайтеся на це як на факт. |
| `[assumed]` | Не перевірено й не підтверджено. Усе, що позначене так, перелічене в [§22](#чого-я-не-зміг-встановити). |

Це живий звіт, написаний за ESF v0.7 — фреймворком інженерної стратегії, чиї правила цитуються там, де вони зобов'язують; «rev N» означає N-ту нумеровану редакцію цього документа, а Журнал рішень фіксує, що змінила кожна з них. До 24-ї редакції в цьому звіті ніде не було стейкхолдерського тега, бо ніхто з проєкту не озвався. Вікно ввічливості — чернетку виклали у Slack проєкту перед ширшою публікацією, запросивши виправляти, — це змінило: один член Core Team відповів там двома репліками з годиною між ними (24-та й 25-та редакції), закривши два з трьох ранжованих питань, які поставив цей звіт, і кожне позначене стейкхолдером твердження веде до того обміну. Один набір відповідей — це підтвердження, а не доступ; межі, що лишаються, чесно обговорені в [§22](#чого-я-не-зміг-встановити).

**Коди елементів.** [PL1…PL5](#політики-й-операції) — запропоновані політики: постійні правила, які проєкт може прийняти, змінити чи відхилити; це шар, який додає 26-та редакція. [R1…R5](#реєстр-ризиків) — це ризики (те, що *може* статися). [D1…D4](#журнал-боргу) — борги (витрати, які вже сплачуються щоциклу). [S1…S7](#стратегія-що-вже-діє) — стратегії, що вже діють. [RC1/RC2](#першопричини) — першопричини. [F1…F3](#f1) — фактори провалу адмінки. [E1…E5](#легкі-перемоги) — швидка смуга: дрібні покращення машини, які ніколи не конкурують зі складними рішеннями. [B2…B10](#ставки--вирішувати-вам) — запропоновані ставки: B1 відкликано разом із рядком стратегії, а B3 і B4 на 26-й редакції перейшли у смугу Легких перемог; нумерація зберігає прогалини, щоб ранні анотації досі сходилися. [C1…C9](#журнал-кредиту) — кредити: інвестиції, що окупаються щоциклу, — підтверджені або поки що прогнозовані. [P1…P5](#пре-мортем) — записи пре-мортему: способи, якими провалюється власний план цього звіту.

## Політики й операції

> Solidus технічно здоровий і стратегічно дрейфує. Обидва твердження правдиві, і розрив між ними — уся ця історія.

Цей розділ заміняє стислий підсумок, бо підсумок описує, а політика вирішує. Усе, що читачеві треба для дії, — тут; кожне правило веде вниз, до свідчень, з яких воно виросло. Ситуація коротко: Solidus технічно здоровий і стратегічно дрейфує — машинерія доставлення з верхнього дециля, одна по-справжньому застрягла ініціатива, доглядач, чия інженерія тихо пішла, і конкурент, що повернувся з виторгом за плечима. Проєкт не може виграти бій за нових мерчантів, але тримає одне твердження, якого ніхто не оскаржить: це комерційний фреймворк, який і через десять років буде твоїм. Правила нижче — те, що з цього діагнозу випливає, записане як постійна політика, а не разова порада. Читайте цей реєстр разом із двома його супутниками — [§17](#легкі-перемоги) та [§18](#ставки--вирішувати-вам), — бо всі три разом це один фундамент: політики правлять тим, що повторюється, швидка смуга відвантажує дрібні покращення машини без церемоній, а ставки несуть рішення, які й далі потребують судження власника. Прийміть усі три шари — і стратегія стоїть, хай яку роль проєкт обере.

- **60% → 0.8%** — Частка комітів Nebulab, 2023 → останні 12 місяців
- **$45,760** — Уже витрачено на адмінку, яка так і не вийшла
- **3 yr 3 mo** — Вік нової адмінки, досі версія 0.4
- **$133,750** — Готівка на руках · тринадцять місяців без жодної витрати

### Хто це приймає — і що цей звіт може й не може мандатувати

Фреймворк, за яким написано цей звіт (ESF v0.7 — див. примітку про нотацію в «З чого почати»), вимагає відповісти на питання про мандат до того, як пропонувати політику, — тож ось відповідь, прямо. **Автор не має жодного мандата над Solidus.** Це аудит ззовні; ніщо нижче не є прийнятим, і зовнішній аналітик прийняти його не може. Кожен рядок PL виходить у стані `proposed`, адресований людям, яких справді уповноважує документ про врядування: **Core Team** — для всього, що торкається коду й релізів, і **голосування стейкхолдерів** — для всього, що торкається грошей `[observed]`.

Solidus тримається на волонтерах: нікому не можна призначити дедлайн, за який йому не платять, — тож політика, яка вимагала б постійної праці від названих волонтерів, померла б у момент появи. Те, що проєкт *може* запроваджувати, він уже запроваджує добре — машинами. Депрекації валять збірку; стиль лінтується, а не обговорюється; мердж вимагає рев'ю Core Team `[observed]`. Правила нижче цю межу шанують: це або заяви політики, які нічого не коштує тримати (назвати дату, опублікувати рішення), або правила розподілу грошей, якими колектив і так розпоряджається, або настанови, чиє запровадження лишається наявній машинерії. Жодне з них не просить волонтера працювати.

Ще один обов'язок, який накладає фреймворк: перш ніж писати стратегію, перевірити, чи стратегічна робота вже не ведеться. Ведеться. Провідний мейнтейнер опублікував цілісну стратегічну позицію в травні 2026-го — широке врядування, свобода ліцензії, свідома відмова від шляху JavaScript-фреймворків `[web]`. Політики тут приєднуються до цієї позиції, а не змагаються з нею; [PL3](#pl3) існує здебільшого для того, щоб перенести її з блогу консалтингової фірми у власні артефакти проєкту.

### Запропонований реєстр політик

**PL1 — Кожна заміна називає реліз, який прибирає те, що вона замінює** *(direction · proposed)*
Проєкт добре проєктує міграції і ніколи не планує їх у часі — [RC1](#rc1) є механізмом за найбільшою повторюваною витратою в журналі, [D1](#d1). Промоакції вже два роки мають завершений движок і гайд міграції на 190 рядків — і жоден реліз ніде не каже, коли легасі-движок піде. Це правило закриває прогалину біля джерела: наступник виходить як паралельний opt-in лише поруч із названим релізом, що прибирає попередника. Rails і Ruby публікують таймлайни депрекації саме так; заява нічого не коштує й нікому не призначає праці. Її перше застосування — [B5](#b5), і зробити його можна було безплатно вже два роки.
Addresses: [RC1](#rc1), [D1](#d1)
Relation: доповнює [S3](#s3), додаючи критерій виходу, якого їй бракує; підсилює [S2](#s2) — опублікована дата тримає «депрекуй перед видаленням» чесним
Operations: рядок критеріїв виходу в шаблоні релізних нотаток (та сама автоматизація, що вже генерує чейнджлоги); порада «мігруйте вже» з гема промоакцій — як зразковий документ
Accepted by: Core Team (запропоновано)
Executed by: чекліст релізу — рядок критеріїв виходу в релізній автоматизації
Review: 2027-02-08

**PL2 — Гроші колективу купують названі результати, а не час** *(allocation · proposed)*
Кожен рік серйозних витрат фінансував одну-єдину співпрацю, і провалилася саме та, що купила активність замість результату — $45,760 за шість «Agile Design Sprints» 2023 року ([F1](#f1)). Правило: оплачувана співпраця називає свій артефакт, критерій завершення і того, хто нестиме роботу після того, як гроші скінчаться. Сама модель фінансування вже усталена й свідома — незалежні розробники, оплачувані з колективу, поки фірми-мейнтейнери лишаються на клієнтській роботі `[user]`, — тож цей рядок ратифікує норму, яку проєкт уже тримає, і записує стандарт відстані витягнутої руки, який сьогодні існує лише у Slack та в голові одного мейнтейнера. Перевірено на минулому: співпраці 2020, 2024 і 2025 років проходять за формою і провалюються на наступності; купівля 2023-го провалюється повністю — і різниця якраз у цьому правилі.
Addresses: [RC1](#rc1), [R3](#r3), [F1](#f1)
Relation: заповнює порожнечу — писаного правила розподілу не існує; ратифікує неписану норму фінансування, яку Core Team назвала на 25-й редакції
Operations: наявне щотижневе голосування стейкхолдерів як місце затвердження; перевірка фіскального хоста як незалежний контроль; опис витрати сам несе результат і критерій, тож інспекція відбувається в момент затвердження без нової машинерії
Accepted by: голосування стейкхолдерів (запропоновано)
Executed by: крок затвердження витрати — витрату без названого результату повертають, а не затверджують
Review: 2027-02-08

**PL3 — Рішення публікуються там, де їх прочитає той, хто обирає** *(guidance · proposed)*
Core Team тримає явні технічні повноваження, спільнота збирається щотижня — і жодне рішення не досягає публічного артефакту: дошка роадмапу — чейнджлог, що носить ім'я роадмапу, а найясніша заява стратегії проєкту живе в маркетинговому блозі консалтингової фірми ([S1](#s1)). Потенційний користувач знаходить доглянутий запис того, що проєкт мав минуле, — і жодного свідчення, що він має майбутнє. Правило: кожне рішення Core Team упродовж місяця лягає статус-постом або майбутнім пунктом на дошці роадмапу. Це публікація, а не врядування — рішення, можливо, і так ухвалюються; просто їх не видно. Блог уже наполовину прокинувся сам: один реліз-анонс у травні 2026-го `[web]`; це правило перетворює поодинокий вчинок на звичку.
Addresses: [D2](#d2), [D3](#d3), [R4](#r4)
Relation: ратифікує [S1](#s1), переносячи опубліковану стратегію у власні артефакти проєкту; підсилює [S5](#s5)
Operations: обидва канали вже існують і дрімають — перезапуск коштує годину на місяць; [E1](#e1) та [E5](#e5) — перші два кроки, на хвилини
Accepted by: Core Team (запропоновано)
Executed by: два наявні канали — статус-пости й майбутні пункти роадмапу — на щомісячному нагадуванні
Review: 2027-02-08

**PL4 — Кожна паралельна ініціатива щокварталу дістає вердикт, зафіксований публічно** *(approval · proposed)*
Адмінку три роки ані відвантажили, ані скасували — всередині структури врядування, яка прямо дозволяє і те, і те: повноваження є, місця для них нема ([S5](#s5), [D2](#d2)). Правило дає повторюваному рішенню адресу: раз на квартал кожна паралельна ініціатива оголошується — просувається, фінансується, призупиняється до названої дати або скасовується, — і відповідь записується там, де її прочитають зовні. Механізм не може провалитися тихо, і саме ця властивість важить: квартал без списку вердиктів сам собою видно. Це той рядок, який упіймав би зупинку адмінки ще 2024 року, замість лишати архітектурі, що ховає покинутість ([R3](#r3)), ховати її ще два роки.
Addresses: [R3](#r3), [D1](#d1), [RC2](#rc2)
Relation: доповнює [S5](#s5) — повноваження лишаються рівно там, де були; це додає місце, каденцію і запис, яких у них ніколи не було
Operations: їде на наявній щотижневій зустрічі, чотири рази на рік; запис — пункт на дошці роадмапу, що заразом годує [PL3](#pl3)
Accepted by: Core Team (запропоновано)
Executed by: один пункт порядку денного на квартал у наявній щотижневій зустрічі; список вердиктів живе на дошці роадмапу
Review: 2027-02-08

**PL5 — Роботу контриб'ютора, що пішов, підхоплюють або закривають за релізний цикл** *(guidance · proposed)*
Коли 2025 року зупинився оплачуваний розробник, сім адмінських pull request-ів застигли там, де стояли, і єдиним порятунком досі був один контриб'ютор, що зголосився вручну через рік ([F3](#f3)). Той порятунок спрацював — 30 липня 2026-го він переїхав у свіжий pull request, з підходом, якому надавав перевагу рев'юер `[observed]`, — і це водночас доводить механізм і виказує його покриття: один сирота з шести знайшов нового автора, випадково. Правило робить випадковість рутиною. Коли контриб'ютор іде, кожна його відкрита чернетка впродовж одного релізного циклу дістає явне рішення: підхопити чи закрити. Закрити — легітимний результат; нелегітимний лише теперішній дефолт — безстрокове підвішення, яке правило сумісності потім зберігає вічно.
Addresses: [RC2](#rc2), [F2](#f2), [F3](#f3)
Relation: заповнює порожнечу — і ратифікує механізм порятунку, який спільнота вже раз продемонструвала
Operations: збережений пошук GitHub за чернетками без активності автора N місяців — оце й уся інспекція; нагадування йде лише в реально застояні гілки, мовчить в усіх інших
Accepted by: Core Team (запропоновано)
Executed by: прохід по застояних чернетках (збережений пошук або запланований action) плюс коментар з одним питанням: підхопити чи закрити?
Review: 2027-02-08

### Що реєстр свідомо не покриває

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

- **[R2](#r2) — концентрація.** Жодна політика не виколдує третю фірму. Реєстр зменшує радіус ураження ([PL2](#pl2) вимагає наступника; [PL5](#pl5) дає раду уламкам), але сама концентрація сьогодні не має механізму, який варто було б пропонувати. Повернутися, коли з'явиться наступна оплачувана співпраця, — це момент, коли нова сторона реально може увійти.
- **[R5](#r5) — поламка розширень.** Заявлена властивість, а не небезпека; обмежена, з очевидним пом'якшенням на першу вимогу. Відкладено, доки не вкусить когось конкретного.

Реєстр також перевірено на власному журналі рішень цього звіту, як вимагає фреймворк: [PL2](#pl2) перекроїла б купівлю, яку розбирає запис 31; [PL4](#pl4) поставила б руба питання, яке записи 07 і 34 реконструювали три редакції поспіль; [PL3](#pl3) — це виправлення із запису 28, перетворене на постійне правило. Політика, яка не змінила б жодного записаного рішення, не робить роботи; ці три несуть реєстр.

> **ЄДИНИЙ ВИСНОВОК, ЯКИЙ ВАРТО ЗАБРАТИ З СОБОЮ**
> Solidus не може виграти бій за нових мерчантів — ні фічами, ні швидкістю, ні фінансуванням. У нього лишилося одне неоскаржене твердження: він ліцензований під BSD-3 і не має комерційної сутності, яка могла б колись змінити ліцензію, у нього немає JavaScript-ланцюга постачання, він працює на одному рантаймі, а його дисципліна оновлень справжня, і її пильнує машина. Spree структурно не може цього сказати, бо його Enterprise-модулі комерційні. Shopify ніколи б і не захотів.
> 
> Це вказує на роль, а не на камбек: комерційний фреймворк, який і через десять років буде твоїм. Служити мерчантам, які його вже обрали, замість ганятися за тими, які не оберуть ніколи. [§15](#кому-solidus-ще-може-служити)–[§18](#ставки--вирішувати-вам) розбирають, що з цього випливає, а політики вище — постійні правила, які переживуть будь-який вибір ролі.

> Шар політик одним рядком: плануй те, що заміняєш, купуй результати, а не час, публікуй рішення, давай ініціативам квартальний вердикт, підхоплюй або закривай роботу тих, хто пішов. П'ять правил — і жодне не просить волонтера працювати.

## Хронологія

Уся історія за один прохід. Важкі маркери — моменти, на яких вона тримається; зелений — єдина справжня світла пляма.

- **February 2015** — Solidus народжується. Агенція Stembolt форкає Spree 2.4, бо їй не подобається, куди прямує Spree. Обіцянка на старті — стабільність, легкі оновлення та зворотна сумісність `[web]`.
- **September 2015** — First Data купує Spree, і розробка повністю зупиняється. Форк виглядає далекоглядним; значна частина спільноти Spree мігрує на Solidus `[web]`.
- **July 2018** — Перший доглядач іде. JUUL Labs купує Stembolt, і робота над Solidus припиняється. Опіку підхоплює Nebulab `[web]`.
- **2019 onward** — Фінансування йде через Open Collective. Агенції та мерчанти спонсорують щомісяця. Спонсори також починають скасовувати підтримку — сім 2019 року, сім 2020-го, сім 2021-го. Цей відтік так і не зупиняється `[observed]`.
- **May 2023** — Починається нова адмінка. Стартує робота над solidus_admin, що має замінити застарілий інтерфейс `[observed]`.
- **April–August 2023** — На неї витрачено $45,760. Шість платежів по $6,000 для Nebulab за «Agile Design Sprints», плюс $9,760 за аналіз редизайну. 2023-й стає найбільшим роком проєкту: 1,810 комітів, приблизно 60% — від людей Nebulab `[observed]`.
- **2024** — Інженерія Nebulab обвалюється. Їхній провідний розробник падає з 696 комітів до 46. Робота над адмінкою просідає з 618 комітів до 205. Оголошення так і не з'являється `[observed]`.
- **June 2024** — Стартує друге паралельне переписування: solidus_promotions, поруч із наявним движком промоакцій. Жоден не стає дефолтом `[observed]`.
- **April 2025** — Spree повертається комерційно. Версія 5.0 розділяється на безплатну редакцію та платну Enterprise Edition за підтримки Vendo `[web]`.
- **May 2025** — Solidus починає публікувати щомісячні статус-апдейти. Одну людину — Юджина Чайкіна — публічно називають тим, хто рухає нову адмінку вперед. Він напише 78% адмінських комітів того року `[web]` `[observed]`.
- **5 July 2025** — Оплачено останню витрату. Фінансована розробка зупиняється. Гроші продовжують надходити; назовні більше нічого не йде `[observed]`.
- **October 2025** — Щомісячні апдейти обриваються. Після п'яти випусків каденція статус-постів завершується. У травні 2026-го виходить один реліз-анонс — і далі знову тиша `[web]`.
- **April 2026** — Виходить Solidus v4.7.0 — Ruby 3.2+, Rails 7.2+, а CI вже покриває Rails 8.1 і Ruby 4.0, кожен підхоплений за лічені тижні після релізу `[observed]` `[web]`. Інженерна дисципліна досі відмінна.
- **June 2026** — solidus_starter_frontend — сторфронт, який роками жив окремим репозиторієм — перейменовано й поглинуто в монорепо як storefront/, разом із набором тестів на 64 файли й 5,510 рядків `[observed]`.
- **July 2026** — Spree відвантажує шість платформних релізів за п'ять тижнів. Solidus не відвантажив жодного з квітня. Баланс колективу лежить невитраченим. Дві фірми дають 78% фінансування. Нова адмінка — на версії 0.4 з вимкненими головними екранами `[observed]`.
- **3 August 2026** — Проєкт відповідає. Чернетка, викладена у Slack проєкту, за годину отримує відповідь Core Team — «не стовідсотково точно… але точно корисно побачити, який вигляд має публічний стан проєкту, коли зібрати його докупи» — і два найцінніші невідомі дістають відповіді `[user]`.
- **8 August 2026** — Перевірено наново для цієї редакції: видатків досі немає — вже тринадцять місяців — при $133,750 на балансі; мета-гем без змін; порятунок осиротілого pull request-а 30 липня переїхав у свіжий `[observed]`.

> Уся дуга одним рядком: форк Spree 2015 року, творець зник до 2018-го, інженерія доглядача — до 2024-го, а машина досі їде на дисципліні, яку збудували ті, хто пішов.

## Гроші

Фінанси Solidus повністю публічні — що незвично й корисно: цей розділ спирається на записи, а не на здогади. Усі цифри — з API Open Collective `[observed]`; баланс і журнал виплат для цієї редакції перевірено ще раз 8 серпня 2026 року.

### Як влаштовані гроші

Solidus — не компанія і не фундація. Він не існує юридично. Його гроші тримає **Open Source Collective**, американська неприбуткова організація в ролі «фіскального хоста» — вона приймає пожертви, тримає баланс і виплачує витрати, які затверджують адміністратори проєкту. Це поширена схема для проєктів із відкритим кодом, і вона дає справжню зовнішню перевірку: хтось поза проєктом переглядає кожен платіж.

**Стан — баланс перевірено ще раз 8 серпня 2026; сукупні підсумки станом на 25 липня 2026**

| Стаття | Сума |
| --- | --- |
| Кошти на рахунку | $133,750 |
| Отримано загалом з 2018 року | $329,677 |
| Виплачено загалом | $154,612 |
| Комісії хоста і платіжних систем (залишок, обчислений на знімку від 25 липня) `[inferred]` | ~$42,885 · ≈13% |
| Надходження за останні дванадцять місяців | $26,322 |

*Заувага щодо останньої цифри.* Публічна сторінка Open Collective позначає її як «орієнтовний річний бюджет», і це звучить як план. Це не план — це просто те, що надійшло за попередній рік. Ніхто нічого не бюджетував.

### Звідки гроші — і хто перестав давати

Сукупні підсумки сильно прикрашають картину, бо враховують і спонсорів, які давно пішли. Чесне число — **активні регулярні внески: їх дев'ять, разом $1,931 на місяць** — набір, повторно підтверджений незмінним у циклі списань за серпень 2026 `[observed]`:

| Досі платять щомісяця | Сума | Частка | Відколи |
| --- | --- | --- | --- |
| Super Good Software | $750 | 39% | 2019-01 |
| Nebulab | $750 | 39% | 2019-01 |
| 3llideas | $100 | 5% | 2025-11 |
| DevOutsourcing | $100 | 5% | 2024-03 |
| FCP Euro | $100 | 5% | 2020-03 |
| TCW Equipment | $100 | 5% | 2019-10 |
| wemove digital solutions | $20 | 1% | 2019-08 |
| weLaika | $10 | <1% | 2019-10 |
| Karma Creative — колись спонсор із $19,561 сукупно | $1 | <1% | 2019-05 |

> 78% усіх регулярних грошей надходить від двох агенцій, які водночас підтримують код. Приберіть їх — і вся решта світу вносить $431 на місяць у фреймворк, який обробляє реальні платежі реальних магазинів.
> 
> Падіння Karma Creative від великого спонсора до символічного $1/місяць — найпромовистіша ілюстрація тренду.

Понад тридцять спонсорів скасували підписку, серед них великі: Engine Commerce ($1,000/місяць), Modded Euros ($850 за трьома підписками), Firstleaf ($325), Magmalabs ($325) і Deseret Book ($200). Більшість — мерчанти, а не агенції: справжні магазини, які перестали платити `[observed]`.

> **ВАЖЛИВА ДЕТАЛЬ У ЧАСІ**
> Скасування за роками: 2019: 7 · 2020: 7 · 2021: 7 · 2022: 4 · 2023: 5 · 2024: 2 · 2025: 5 · 2026: 2 .
> 
> Це стабільне вимивання з 2019 року, а не недавній обвал — і жодного сплеску після комерційного перезапуску Spree у квітні 2025. Ба більше, 2024 і 2026 — два найнижчі роки за всю історію. Хай що не так із Solidus, Spree цього не спричинив. Це дуже важливо для [§16](#виберіть-роль).

### Куди пішли гроші — і коли це припинилось

Проєкт оплатив 67 витрат на загальну суму $154,612. Баланс лежить *не* тому, що ніхто не знає, як його витратити — проєкт точно знає як, і робив це не раз.

**Витрати за роками — і хто отримав основну частину**

| Рік | Виплачено | Витрат | Куди пішло |
| --- | --- | --- | --- |
| 2019 | $11,768 | 10 | Витрати на конференцію — Sean Denny 43%, Cindy Backman 42% |
| 2020 | $35,736 | 24 | Peter Berkenbosch 80% — щомісячні «Development & Maintenance» |
| 2021 | $0 | 0 | геть нічого |
| 2022 | $500 | 1 | Один інвойс за монтаж відео з конференції |
| 2023 | $45,760 | 7 | Адмінка — Nebulab 79%, Andrea Iurisci 21%. 100% року. |
| 2024 | $32,506 | 16 | Logicielle B.V. 100% — 16 інвойсів за розробку, серпень–грудень |
| 2025 | $16,888 | 6 | «e.c441» 100% — 6 інвойсів за розробку, лютий–липень |
| 2026 | $0 | 0 | геть нічого |

**Сукупні суми за отримувачами — окремий рейтинг, а не річні цифри**

| Отримувач | За весь час | Активні роки |
| --- | --- | --- |
| Nebulab | $36,419 | 2023 ($36,000, адмінка) · 2020 ($419) |
| Logicielle B.V. — особу не верифіковано | $32,506 | лише 2024 |
| Peter Berkenbosch | $28,650 | лише 2020 |
| «e.c441» — анонімізований отримувач | $16,888 | лише 2025 |
| Sean Denny — конференція | $11,262 | 2019, 2020 |
| Andrea Iurisci | $10,250 | 2023 ($9,760, адмінка) · 2020 ($490) |
| Cindy Backman, Thomas Sample, Daniel Gayfer, Shana Remigio, Matteo Galliani | $7,183 | 2019, 2022 |
| Разом | $143,158 | 64 оплачені витрати |

> **ЩО ПОКАЗУЄ РІЧНИЙ ЗРІЗ: ОДИН ФІНАНСОВАНИЙ КОНТРАКТ ЗА РАЗ**
> У кожен рік, коли проєкт витрачав серйозно, практично все йшло на один контракт `[observed]`:
> 
> 2020 — оплачуваний мейнтейнер, Peter Berkenbosch, на щомісячному ретейнері (80% року)2023 — ривок з адмінкою, Nebulab плюс дизайнер (100% року)2024 — оплачуваний розробник, Logicielle B.V. (100% року)2025 до липня — оплачуваний розробник, «e.c441» (100% року)
> 
> А між ними: 2021 і 2026 — цілком сухі, 2022 — майже.
> 
> Через це липень 2025-го читається інакше. Це не момент, коли проєкт здався — це втретє фінансований контракт закінчився, і його не продовжили. Проєкт тричі окремо наймав мейнтейнера і тричі окремо зупинявся. Сухі роки — частина його звичного ритму.
> 
> Це помітно загострює відкрите питання в [§22](#чого-я-не-зміг-встановити). Правильне питання не «чому припинилось фінансування?», а «чому цей контракт не продовжили, якщо дві попередні паузи врешті заповнилися?» Тринадцять місяців — це вже довше за паузу 2021–22, яка передувала адмінковому ривку 2023-го.

> **2023 — РЯДОК, ЯКИЙ МАЄ ЗНАЧЕННЯ**
> Шість платежів по $6,000 кожен на Nebulab, усі з підписом «Solidus Admin Dashboard Agile Design Sprint 1–6», плюс $9,760 для Andrea Iurisci за «Admin Panel Redesign Analysis» `[observed]`.
> 
> Проєкт уже купив переписування адмінки — приблизно за $45,760. Воно так і не вийшло. За ці гроші купили шість спринтів — активність — без готових екранів, без дати завершення і без визначеного власника після фінального спринту. Саме заради того, щоб така покупка стала неможливою, існує [PL2](#pl2).
> 
> Про процес: дві раніші заявки Nebulab по $7,320 кожна відхилили, перш ніж оплатили шість затверджених спринтів. Процес затвердження таки працює.

Фінансована розробка після цього тривала — $32,506 нідерландській компанії за 16 інвойсами наприкінці 2024-го, $16,888 анонімізованому отримувачу за шістьма інвойсами в першій половині 2025-го — а тоді **повністю зупинилась: останню витрату оплачено 5 липня 2025 року**. Відтоді надійшло тринадцять місяців доходу, і жодної виплати не було. Перевірено ще раз 8 серпня 2026 року: найсвіжіший дебет у журналі — досі той інвойс за липень 2025-го `[observed]`.

> **НАСКІЛЬКИ ТВЕРДЕ ТВЕРДЖЕННЯ ПРО «НЕВИТРАЧЕНІ» ГРОШІ?**
> Твердіше за більшість цифр у цьому звіті, бо його оскаржили й перевірили ще раз — тепер уже двічі. Баланс звітують два незалежні ендпоінти Open Collective, і цифри точно збігаються — він не виведений відніманням витрат від надходжень, тож не залежить від жодної арифметики в цьому звіті.
> 
> Перший прохід дивився лише на оплачені витрати, а так можна було б пропустити гроші, вже затверджені й поставлені в чергу на виплату. Запит за всіма станами повертає 67 витрат: 64 оплачені, 3 відхилені, і жодної в очікуванні, затвердженої чи в обробці. Найсвіжіша витрата будь-якого статусу — з липня 2025 року. Отже, ніщо не зарезервоване і не в дорозі `[observed]`. Повторна перевірка 8 серпня ще раз прочитала журнал дебетів і побачила ту саму картину; єдине, чого не прочитати без автентифікації, — витрати, подані, але ще не затверджені: це обмеження назване, а не приховане `[observed]`.
> 
> Дві розбіжності звірки лишаються відкритими, і їх варто назвати. 64 оплачені витрати дають у сумі $143,158 проти звітованих загальних витрат $154,612 — різниця $11,453, найімовірніше комісії за виплати. А отримане-мінус-витрачене перевищує баланс на $42,885, тобто 13% усього отриманого — що узгоджується з комісією хоста плюс обробкою платежів. Жодне з цього не верифіковано `[inferred]`. Ще варто зазначити: 2021 року витрат було нуль, тож сухий рік для проєкту не новина.

> **ВАЖЛИВА МЕЖА ТОГО, ЩО ОЗНАЧАЮТЬ «БЕЗДІЯЛЬНІ ГРОШІ»**
> Сума $133,750 описує лише рахунок Open Collective. Це не міра того, скільки інвестується в Solidus.
> 
> Super Good Software за останні дванадцять місяців внесли приблизно 188 комітів, а Nebulab досі платить найвищий спонсорський рівень. За будь-якою консалтинговою ставкою цей подарований інженерний час затьмарює весь грошовий баланс. Готівка бездіяльна; загальна інвестиція в проєкт — ні.
> 
> Точна й вужча знахідка: спільні, колективно врядовані гроші — єдині гроші, якими спільнота як ціле може розпоряджатися, через єдиний механізм, який її врядування насправді визначає — стояли на місці тринадцять місяців, поки її ж заявлені пріоритети лишалися без фінансування. Це залишається справжньою знахідкою. Але це не «ніхто не інвестує в Solidus».

### Хто може їх витратити

Адміністраторів, які можуть затверджувати витрати на Open Collective, семеро: tvdeyen, Gregor MacDougall, **Alberto Vena (Nebulab)**, Matteo Latini, Andrea Iurisci, **Alessandro Desantis (співзасновник Nebulab)** і **Джаред Норман (Super Good)** `[observed]`. Щонайменше двоє — з організації, яка перестала вносити код.

> **ПРО ОЧЕВИДНЕ ПИТАННЯ**
> Nebulab — водночас найбільший окремий отримувач грошей проєкту ($36,419) і один із затверджувачів. Це варто сказати прямо — як і контекст, що робить «викачування» хибним прочитанням: Nebulab внесли $80,750 і отримали $36,419 — чистий внесок $44,331. Вони досі щомісяця платять найвищий рівень. Дві їхні заявки були відхилені. Незалежний фіскальний хост переглядає кожен платіж.
> 
> Знахідка, яку можна обстояти, вужча — і все одно серйозна: платіж повʼязаній стороні на $45,760 затвердили без жодного критерію завершення, і він не дав готового результату. Прогалина не в розкраданні, а в тому, що для оплати інсайдера немає стандарту незалежної угоди.
> 
> Суміжна теорія — що спонсорство було грою за голоси — не витримує зіткнення з механікою. Вага голосу дорівнює місячному внеску з лімітом 1000; Nebulab і Super Good нарівні по $750, і жоден не витратив додаткові $250, які б добили ліміт. Голоси врядують лише тим, як витрачаються кошти і хто стає радником; вони не дають жодної влади над тим, який код мерджиться. А економіка йде на $44k не в той бік `[observed]`.
> 
> На 25-й редакції стандарт незалежної угоди, якого, за цією знахідкою, бракувало, виявився заявленою нормою: мейнтейнери воліють взагалі не брати колективних грошей — «я волію уникати будь-якого враження, що ті з нас, хто підтримує Solidus, прямо заробляють на фінансуванні з OpenCollective» — а робота «кошти агенціям» прийнятна, «поки це прозоро і чесно оцінено», з перевагою для вправних третіх сторін `[user]`. Норма, промовлена в Slack, — не документ врядування, тож знахідка звужується, а не закривається: стандарт існує в голові власника, а тепер і в записі; він досі ніде не записаний так, щоб його прочитав наступний затверджувач. [PL2](#pl2) — це і є той абзац, уже написаний начорно.

> Гроші одним рядком: фінансована розробка зупинилася в липні 2025 року, відтоді надійшло тринадцять місяців доходу, і $133,750 лежать невитраченими.

## Продукт

Що насправді лежить у репозиторії — і патерн, що повʼязує три незавершені переписування.

**Компоненти на коміті cdcdfaf3 · Ruby без спеків · ERB = шаблони вʼю**

| Компонент | Ruby | Спеки | ERB | Початок | Типовий? |
| --- | --- | --- | --- | --- | --- |
| solidus_core — домен комерції | 543 | 312 | 17 | 2015 | так |
| solidus_admin — нова адмінка | 235 | 93 | 111 | 2023-05 | ні |
| solidus_promotions — нові промоакції | 165 | 113 | 78 | 2024-06 | ні |
| solidus_legacy_promotions — старі промоакції | 101 | 92 | 58 | 2024-01 | так |
| solidus_backend — стара адмінка | 79 | 87 | 277 | 2015 | так |
| solidus_api — REST API | 57 | 41 | 0 | 2015 | так |
| storefront/ — шаблон Rails-застосунку | 54 | 64 | 103 | 2026-06 (репозиторій: роки) | через генератор |
| solidus_sample — сід-дані | 25 | 1 | 0 | 2015 | так |

Колонку «Типовий?» перевірено ще раз 8 серпня 2026 року: мета-гем досі називає `solidus_api`, `solidus_backend`, `solidus_core`, `solidus_legacy_promotions` і `solidus_sample` — і досі оминає `solidus_admin` та `solidus_promotions` `[observed]`.

> Колонка ERB — це те, де насправді живе стара адмінка. У solidus_backend 79 файлів Ruby і 277 шаблонів вʼю — це серверно-рендерений UI, і рахувати його за файлами Ruby означає сильно його недооцінити. Нова адмінка має 111 шаблонів проти 277 у старої — незалежна міра того, як далеко ще йти цьому портуванню ([§08](#розтин-адмінки)).

### Три паралельні компоненти — але три різні історії

Разом вони виглядають як системна нездатність доводити до кінця. Поодинці — в біді лише один.

| Ділянка | Старе | Нове | Вік | Чим воно є насправді |
| --- | --- | --- | --- | --- |
| Промоакції | legacy_promotions | solidus_promotions | 2 р. 2 міс. | керована міграція, якій бракує лише дати |
| Сторфронт | solidus_frontend | storefront/ | роки, як окремий репозиторій | успіх — див. нижче |
| Адмінка | solidus_backend | solidus_admin v0.4 | 3 р. 3 міс. | єдиний справжній застій |

> **ПРОМОАКЦІЇ — НЕ ЗАСТРЯГЛЕ ПЕРЕПИСУВАННЯ, А ХРЕСТОМАТІЙНА ПОЕТАПНА МІГРАЦІЯ**
> Гем має гайд міграції на 190 рядків, який покриває встановлення, міграцію наявних даних промоакцій, перемикання поведінки магазину, синхронізацію легасі-промоакцій у замовленнях, роботу з кастомними сторфронтами, портування кастомних правил і, нарешті, видалення легасі-гема з Gemfile `[observed]`.
> 
> Його README формулює намір прямо: «Він має замінити систему промоакцій із гема legacy_promotions… Хоча поточна версія Solidus досі встановлює легасі-систему промоакцій, ми радимо мігрувати за першої нагоди, щоб потім не довелося робити це поспіхом».
> 
> Старий движок ставиться за замовчуванням навмисно — правило [S2](#s2) вимагає періоду opt-in перед ламкою міграцією даних. Зміну архітектури обґрунтовано продуктивністю (обробку промоакцій централізовано в апдейтері замовлення).
> 
> Єдине, чого справді бракує, — це дата. Ніде немає графіка депрекації — жодного «Solidus 5 це прибирає». Шлях повністю зінженерений; перемикання не заплановане. Це значно менша й значно дієвіша знахідка, ніж «застрягле переписування», — і саме цей випадок узагальнює правило [PL1](#pl1).

> **СТОРФРОНТ — ЦЕ УСПІХ, І ПРИЧИНА ЙОГО ПОВЧАЛЬНА**
> Одинадцять комітів за шість тижнів, чотири людини з двох організацій, включно з Альберто Веною з Nebulab `[observed]`. Що ввійшло: перенесення з перейменуванням, налаштоване покриття коду, скопійований додатковий спек PayPal, README, вирівняний із сусідніми компонентами, підчищені ліцензія й документація.
> 
> Разом із ним прийшов не семитижневий скелет. solidus_starter_frontend роками жив як окремий репозиторій і приніс 64 файли спеків і 5,510 рядків тестів — компоненти, контролери, хелпери, мейлери, request-спеки включно з авторизацією і 19 системних спеків на автентифікацію й кешування. Ці спеки копіюються в кожен згенерований магазин, а CI на кожен push встановлює магазин і ганяє їх наскрізно `[observed]`.
> 
> Це спрацювало, бо це не було переписування. solidus_starter_frontend уже існував, уже працював і вже підтримувався як окремий репозиторій. Робота червня 2026-го ввела під намет готову річ, а не будувала нову з нуля.
> 
> Порівняйте з адмінкою і промоакціями — обидві будували наново з нічого. Урок, який проєкт уже сам собі продемонстрував: обмежена, завершувана робота з чітким кінцевим станом доводиться до кінця, а міжорганізаційна співпраця досі працює, коли робота має таку форму.

Залишкова ціна реальна, але вужча, ніж звучало раніше: два движки промоакцій — це 205 файлів тестів на той самий домен, і кожна нова інсталяція досі тягне дві адмінки `[observed]`.

### Обсяг розробки за роками

| item | value |
| --- | --- |
| 2015 | 2,194 |
| 2016 | 2,244 |
| 2017 | 1,980 |
| 2018 | 1,070 |
| 2019 | 883 |
| 2020 | 1,252 |
| 2021 | 817 |
| 2022 | 828 |
| 2023 | 1,810 |
| 2024 | 1,016 |
| 2025 | 685 |
| 2026 дотепер | 223 |

Пік 2023-го і його обвал — не загальна крива втоми. Це **одна організація, що прийшла й пішла** — див. [§06](#люди).

### Як Solidus насправді використовують — і майже повна відсутність публічних прикладів

Для комерційної платформи найпереконливіше свідчення — справжній магазин. Пошук публічних репозиторіїв, що залежать від Solidus, дає близько тридцяти результатів `[observed]` — і серед них майже немає продакшн-магазинів:

- **Розширення й інструменти** — `boomerdigital/solidus_flexi_variants`, `solidus_pca_address_validation`, `jtapia/solidus_picker`, `Whelton/solidus_editor`, `StemboltHQ/solidus_chimpy`
- **Демо, шаблони й навчальні проєкти** — `mrenoon/solidus-template-store`, `kennyadsl/solidus-searchkick-example`, `ArkieCoder/dockerized-solidus`, вправи з буткемпів
- **Референсні роботи агенцій** — `madetech/market_town` і `order_reporting`, `nebulab/bretelline`, `peterberkenbosch/blogstore`

> Публічного прикладу справжнього магазину на Solidus фактично немає. Це очікувано — комерційні впровадження пропрієтарні — але це стратегічна ціна, якої Spree не платить: Spree пропонує хостовану пісочницю і скафолд однією командою, тож той, хто оцінює, може побачити, як воно працює, за лічені хвилини.
> 
> Джаред Норман сам назвав це у How to Fail at Solidus, зауваживши, що багато впроваджень Solidus лишаються невидимими для спільноти `[web]`. Платформа, чиї успіхи всі приватні, змагається з постійним дефіцитом свідчень — а єдиний артефакт, який дешево закрив би цю прогалину, робочий публічний демо-магазин, не існує.

### Екосистема розширень

Опціональні можливості Solidus тримає в окремих репозиторіях. Із 35 в офіційній організації у 2026-му ще працюють над платежами (Stripe, PayPal), підписками, автентифікацією, перекладами та інструментами для розробників. **Сплять із жовтня 2023-го: GraphQL API, вебхуки і старий сторфронт** `[observed]`. Екосистема найтонша саме там, куди Spree інвестує найзавзятіше, — API та headless-сторфронти.

> Продукт одним рядком: три паралельні переписування читаються як системна нездатність доводити до кінця, але промоакції — керована міграція, сторфронт — успіх; застрягла лише адмінка.

## Люди

Хто пише код — і передача, якої так і не сталося. Це причиновий центр звіту.

**Внески за останні дванадцять місяців — 493 коміти, 27 людей**

| Хто | Коміти | Частка |
| --- | --- | --- |
| Super Good Software | ~188 | 38% |
| Мартін Меєргофф — окрема людина, без компанії за спиною | 147 | 30% |
| blish.cloud — фон Даєн, Карнац | 74 | 15% |
| Ці троє разом | ~409 | 83% |
| Nebulab — 60% комітів 2023 року | 4 | 0.8% |

### Відхід, рік за роком

| Людина (організація) | 2022 | 2023 | 2024 | 2025 | 2026 |
| --- | --- | --- | --- | --- | --- |
| Елія Скіто (Nebulab) | 133 | 696 | 46 | 4 | 0 |
| Альберто Вена (Nebulab) | 70 | 232 | 52 | 12 | 3 |
| Райнер Дема (Nebulab) | — | 168 | 2 | 0 | 0 |
| Super Good Software (усі) | 34 | 3 | 140 | 62 | 136 |

Nebulab дали приблизно 1,096 з 1,810 комітів 2023 року — близько 60% — і приблизно 3 з 223 у 2026-му. **Жодного публічного оголошення про цей перехід не було**; ретельний пошук нічого не знайшов `[web]`. Це зміна того, хто пише код, — не обовʼязково того, хто кермує проєктом: це дві окремі ролі, і ззовні видно лише одну.

> **NEBULAB ДОСІ АКТИВНІ — ПРОСТО ДЕІНДЕ**
> Вони лишаються активною консалтинговою компанією на 27 людей і досі платять за найвищий рівень спонсорства. Але їхня сторінка послуг тепер перелічує «Shopify Development» точно нарівні з «Solidus Development» `[web]`. Доглядач диверсифікувався в конкурентну платформу: і далі фінансує, а його інженери пішли деінде — і ця картина точно збігається з кривою комітів.

### Де ухвалюються рішення — і де ні

| Інтерфейс | Гарантований строк відповіді? | Що відбувається насправді |
| --- | --- | --- |
| Pull request → мердж | ні | 40 відкритих; найстаріші — з 2021 і 2022 років, але див. примітку нижче |
| Вступ до Core Team | ні | «напишіть Альберто Вені в Slack у директ» — людина, а не процес |
| Стати партнером чи радником | ні | «напишіть Шону Денні в Slack у директ» |
| Рішення, як витрачати кошти | частково | голосування стейкхолдерів на задокументованій щотижневій зустрічі |
| Рішення про технічний напрям | повноваження — так, майданчик — ні | останнє слово за Core Team; немає заявленого ритму, кворуму чи запису |

> **ПРОГАЛИНА В УХВАЛЕННІ РІШЕНЬ ВУЖЧА, НІЖ ЗДАЄТЬСЯ СПЕРШУ, — І ЇЇ ВАЖЧЕ ПОБАЧИТИ ЗЗОВНІ**
> Дві речі з документа про врядування варто процитувати точно, бо разом вони чітко окреслюють прогалину `[observed]`.
> 
> Технічні повноваження призначено. «Члени core team ухвалюють остаточне рішення про те, що потрапляє в ядро та будь-які інші немаркетингові матеріали… розміщені в офіційних GitHub-організаціях Solidus». Отже, орган, уповноважений вирішити, чи нова адмінка відвантажується, чи скасовується, існує. Це Core Team, і повноваження явні.
> 
> Регулярні зустрічі існують — і за своїм скоупом обходять це питання. Стейкхолдери «координуються на щотижневих зустрічах і долучаються до Solidus зазвичай нетехнічними способами — наприклад, обирають, які конференції відвідати чи організувати, шукають маркетингові можливості або вирішують, як використати кошти в Open Collective». Тобто єдиний задокументований постійний форум, за власним описом, — про конференції, маркетинг і гроші.
> 
> Отже, бракує не повноважень і не зустрічей. Бракує майданчика, ритму й запису для здійснення повноважень, які вже є. Core Team може вирішити долю адмінки будь-коли; ніде не сказано, коли вони збираються це робити, що вважається рішенням і де записується результат. [PL4](#pl4) пропонує саме — і тільки — цей відсутній шматок.

> **ВІДКРИТИЙ КОД, ПРИВАТНІ РІШЕННЯ**
> Саме тут прогалина стає знахідкою, а не формальністю. Обидва артефакти, які могли б нести публічний технічний напрям, не несуть майже нічого.
> 
> Публічна дошка роадмапу містить 76 пунктів — 65 змерджених pull request-ів і 7 закритих issue проти 3 відкритих, спрямованих уперед. Вона записує те, що вже зроблено `[observed]`.Блог публікував щомісячні статус-апдейти з травня по жовтень 2025-го, затих — і відтоді опублікував одне оголошення про реліз: для v4.7, у травні 2026 `[web]`.
> 
> Чи ухвалюються рішення в Slack, чи на щотижневій зустрічі — зовнішній читач сказати не може, як не може й мерчант, що вирішує, чи будувати на цій платформі наступне десятиліття. Ніщо в цьому аудиті не встановлює, що рішень немає; він встановлює, що майже жодне не публікується.
> 
> Це переінакшує фікс і робить його значно дешевшим за «створити процес врядування». Core Team уже має повноваження, а спільнота вже зустрічається щотижня. Бракує артефакту — опублікованого запису, а в проєкту є два канали, створені саме для того, щоб такий запис нести. Відновити статус-пости як звичку, а не як виняток на день релізу, і заводити на дошку роадмапу спрямовані вперед пункти — і невидимий процес стає видимим майже задарма; це і є [PL3](#pl3) одним реченням.
> 
> Межа цієї знахідки: я не встановив, чи існують протоколи зустрічей десь непублічно. Твердження тут лише про те, що ззовні жодного запису не знайти `[inferred]`.

> **КУПА ВІДКРИТИХ PULL REQUEST-ІВ — ПОЧАСТИ ЗОВНІШНІЙ ШУМ, І З НИМ АКТИВНО РОЗІБРАЛИСЯ**
> Не читайте всі 40 відкритих pull request-ів як недбалість мейнтейнерів. У квітні 2026-го Джаред Норман опублікував оголошення, яке пояснило раптову хвилю перших внесків: онлайн-дошка вакансій давала кандидатам завдання виправляти issue Solidus як етап відбору `[observed]`.
> 
> Його розповідь варто процитувати — вона багато каже про опіку: «багато з них були низької якості — згенеровані LLM або людьми без досвіду з проєктом… ми на це не підписувалися й цього не хотіли, а воно створило зайвий тягар супроводу. Я звʼязався з дошкою вакансій, і вони попросили автора оголошення прибрати цей етап». Далі він не полінувався підбадьорити справжніх новачків і показати їм хороші перші issue.
> 
> Це мейнтейнер, який діагностує зовнішню причину, втручається вище за течією, щоб зупинити її біля джерела, і водночас захищає лійку контриб'юторів. Це свідчення активної опіки, і воно працює проти прочитання беклогу як занепаду.

> Люди одним рядком: Nebulab дали приблизно 60% усіх комітів 2023 року і 0.8% за останні дванадцять місяців — і жодного оголошення так і не було.

## Машина

Автоматизовані системи, які збирають, тестують і релізять софт. Тут Solidus по-справжньому сильний — і кожна прогалина вказує в один і той самий бік.

| Спроможність | Є? | Деталі |
| --- | --- | --- |
| Тести на кожну зміну | так | вісім окремих тестових джобів |
| Широта тестової матриці | сильна | Rails 7.2 / 8.0 / 8.1 × Ruby 3.2 / 3.3 / 3.4 / 4.0, три бази даних |
| Депрекований код валить збірку | так | SOLIDUS_RAISE_DEPRECATIONS: true — саме на цьому тримається обіцянка оновлень |
| Стиль коду контролюється автоматично | так | standardrb, лінтинг ERB і JavaScript |
| Покриття тестами вимірюється | так | шість компонентів звітують у Codecov |
| Релізи автоматизовані | так | changelog генерується з лейблів |
| Фікси бекпортуються в старі версії | так | автоматизовано для п'яти підтримуваних ліній |
| Розгортання середовища однією командою | так | Docker Compose, bin/setup |
| Політика розкриття вразливостей | сильна | програма на HackerOne, підтвердження за 5 днів, трифазне координоване розкриття |
| Вікно безпекових патчів | так | 18 місяців; наразі підтримуються 4.7, 4.6 і 4.5 |
| Автоматичні оновлення безпекових залежностей | так | заявлено в політиці безпеки; увімкнено через GitHub, а не через конфіг-файл |
| Захист релізного акаунта | так | багатофакторна автентифікація обов'язкова для прав на релізи в RubyGems |
| Контроль рев'ю | так | два обов'язкові рев'ю Core Team перед мерджем |
| Автоматичні оновлення рутинних залежностей | ні | немає конфігурації Dependabot чи Renovate для небезпекових підвищень версій — [E2](#e2) |
| Крок аудиту залежностей у CI | ні | немає джоба bundler-audit чи brakeman — але див. апарат розкриття вище; [E3](#e3) |
| Харнес для AI-агентів | ні | ні AGENTS.md, ні CLAUDE.md, нічого — повторно перевірено 8 серпня 2026; [E4](#e4) |
| Архітектурні доки / записи рішень | ні | немає; репозиторій роадмапу спить із травня 2023 |
| Маршрутизація рев'ю | так | CODEOWNERS веде кожен шлях до core team — див. примітку |
| Шаблони для контриб'юторів | так | шаблони pull request та issue, успадковані від організації |

> **БЕЗПЕКА — НАЙКРАЩЕ НАЛАГОДЖЕНИЙ ПРОЦЕС У ПРОЄКТІ**
> У репозиторії немає SECURITY.md, і це підштовхує до висновку, що платіжний фреймворк живе без політики розкриття вразливостей. Це не так. Політика живе на рівні організації і вказує на опублікований процес, помітно сильніший, ніж у більшості проєктів такого розміру `[observed]` `[web]`:
> 
> Програма розкриття вразливостей на HackerOne, де звіти явно скеровано повз публічні канали.Заявлене зобов'язання реагувати — «Ваш звіт буде підтверджено якнайшвидше, і ми спробуємо зв'язатися протягом 5 днів» — з оновленнями не рідше ніж раз на п'ять робочих днів і названим шляхом ескалації на випадок, якщо це зірветься.Трифазне координоване розкриття: призначити відповідального й проаудитувати уражені версії; приватно підготувати фікси через GitHub Security Advisories для кожного підтримуваного релізу; тоді опублікувати advisory, повідомлення в розсилці, релізи гемів і пост у блозі — «в межах того самого робочого дня».18 місяців безпекової підтримки, наразі для 4.7, 4.6 і 4.5.Два обов'язкові рев'ю Core Team перед будь-яким мерджем і обов'язкова багатофакторна автентифікація для прав на релізи в RubyGems.Автоматичні оновлення безпекових залежностей — заявлені в політиці, і саме це закриває єдине, чого не показав сам репозиторій.
> 
> За цим стоїть трек-рекорд: п'ять опублікованих advisories між 2020 і 2022, з оцінкою серйозності, один із CVE `[observed]`.
> 
> Два спостереження, які варто тримати в голові. Перше: список підтримуваних версій актуальний — у ньому названа 4.7, випущена в квітні 2026, — тобто цю політику підтримують, поки блог і роадмап стоять. Це чесний сигнал того, що саме проєкт продовжує тягнути, коли вважає ставки достатньо високими. Друге: жодного advisory не опубліковано з 2022 року. Це чотири тихі роки: або нічого не знайшли, або процес затих разом з усім іншим; ніщо тут не дозволяє розрізнити ці два варіанти `[inferred]`.

> Машина одним рядком: кожна зміна тестується проти чотирьох комбінацій Ruby–Rails, де найновішу з кожного підхоплюють за лічені тижні після релізу, депрекації валять збірку, фікси бекпортуються автоматично — машинерія доставлення з верхнього дециля для проєкту такого розміру.

> **ПРО ОДНОРЯДКОВИЙ CODEOWNERS — ЦЕ НЕ ДЕФЕКТ**
> .github/CODEOWNERS містить одне правило: * @solidusio/core-team `[observed]`. За генеричним чеклістом це читається як брак гранулярності. Але для цього проєкту це, мабуть, правильна конфігурація.
> 
> Гранулярне володіння виправдовує себе, коли є окремі підкоманди, між якими треба маршрутизувати. У Solidus 27 контриб'юторів на рік і три сторони, що пишуть 83% коду ([§06](#люди)); підкоманд, до яких маршрутизувати, просто немає. Гірше того: закріпити компоненти за названими людьми в проєкті, чий визначальний режим відмови — відхід людей, означало б перетворити кожен відхід на застряглу чергу — саме це сталося з адмінкою, коли її власник перестав контриб'ютити.
> 
> Натомість catch-all гарантує, що кожен шлях досягає того з core team, хто доступний, і саме він стоїть за заявленими в політиці безпеки «двома обов'язковими рев'ю Core Team на PR перед мерджем» ([§07](#машина)). Це, правдоподібно, несуча конструкція, а не рудимент.
> 
> Чого я не зміг перевірити: і налаштування захисту гілок, і членство в core team вимагають адмінських прав в організації, а запити повернули помилки доступу, а не відсутності. Тож вимога рев'ю спирається на опубліковану політику `[web]`, а не на пряме спостереження за виконанням.

### Перевага «Rails way» — де Solidus на покоління позаду самого Rails

Ключове стратегічне твердження Solidus — що він робить речі в стилі «Rails way». Це твердження варто звірити з тим, чим «Rails way» *є* зараз.

| Аспект | Дефолт Rails 8 | Solidus | Вердикт |
| --- | --- | --- | --- |
| Інтерактивність фронтенду | Hotwire — Turbo + Stimulus | Turbo + Stimulus у новій адмінці; jQuery у старій | актуально там, де нове |
| Доставка JavaScript | importmap, без Node | importmap, без Node | актуально |
| Пайплайн асетів | Propshaft | require "sprockets/railtie" у ядрі; sprockets-rails у старій адмінці | на покоління позаду |
| CSS | різне; Tailwind добре підтримується | tailwindcss-rails у новій адмінці, Sass у старій | змішано |

> Rails 8 постачає Propshaft як дефолтний пайплайн асетів; Sprockets — попереднє покоління `[web]`. Ядро Solidus жорстко вимагає Sprockets `[observed]`, а отже, кожен застосунок на Solidus прибитий до легасі-пайплайна незалежно від того, що обрав би сам хост-застосунок.
> 
> Це найгостріша форма розриву з «Rails way»: диференціатор — не «ми використовуємо Rails», а «ми використовуємо Rails так, як це роблять зараз». У новій адмінці Solidus актуальний. У фундаменті, який завантажує кожен магазин, — ні. І зв'язка проходить через solidus_core, тож окремий магазин не може від неї відмовитися.

#### Скільки насправді коштує пін на Sprockets — історія інсталятора

Це не абстрактна теза про модернізацію. Це пряма причина найтривалішого класу баг-репортів Solidus, і зв'язок задокументовано всередині власного CI проєкту.

> Шлях встановлення вже покритий безперервною інтеграцією, і покритий ґрунтовно. solidus_installer.yml запускається на кожен push і pull request у main: він встановлює нативну бібліотеку для зображень, запускає справжній інсталятор зі справжніми прапорцями, піднімає застосунок і перевіряє, що головна сторінка рендериться, звіряє резолвнуту версію платіжного гема, а потім запускає власний набір тестів згенерованого застосунку зі звітом про покриття. Другий воркфлоу покриває шлях генератора розширень `[observed]`.

Але композитний екшн, який викликає CI, робить дещо перед тим, як запустити інсталятор:

```sh
# prepare_solidus_app/action.yml

```

*Композитний екшн патчить застосунок до запуску інсталятора — обхідний маневр, який CI носить із собою, щоб шлях встановлення лишався зеленим.*

> CI зелений на шляху встановлення, якого документація не описує. Офіційний гайд дає дві команди. CI тихо виконує три. Розробник, який іде за гайдом, влучає точно в той баг, який CI обходить, — а пояснення живе в коментарі до коду, а не там, де читає користувач `[observed]`.
> 
> Це і є механізм за десятиліттям issues про встановлення: [#6327](https://github.com/solidusio/solidus/issues/6327) (інсталятор падає з помилкою Sprockets), [#5410](https://github.com/solidusio/solidus/issues/5410) (нова адмінка ламає компіляцію асетів, коли в хост-застосунку є Tailwind), [#6516](https://github.com/solidusio/solidus/issues/6516) (відкритий — узгодити інструкції встановлення зі сторфронтом) і [#6035](https://github.com/solidusio/solidus/issues/6035) (відкритий 19 місяців — інсталятор може падати мовчки).
> 
> Ще дві межі того, що CI доводить: він встановлює з робочого дерева, а не з випущеного гема, і передає --sample=false, тож завантаження демо-даних — яке для реальних користувачів увімкнене за замовчуванням — ніколи не перевіряється.

#### Чекати на апстрім не вийде

|  |  |
| --- | --- |
| Апстрімний фікс — rails/sprockets-rails #546, «Warn instead of raising on missing manifest.js» | відкритий із лютого 2025, не змерджений |
| Останній реліз sprockets-rails | v3.5.2, липень 2024 |
| Власний рядок залежності Solidus | sprockets-rails != 3.5.0 — захисне виключення поганого релізу |
| Rails 8 | уже замінив його на Propshaft |

Фікс, на який Solidus неявно чекає, лежить незмердженим у гемі, що не релізився два роки і вже витіснений апстрімом `[observed]` `[web]`.

#### Наскільки глибоко насправді сягає зв'язка?

Нерівномірно — і саме тому поетапна міграція цілком здійсненна.

| Компонент | Зв'язка | Складність портування |
| --- | --- | --- |
| solidus_core | require "sprockets/railtie", плюс один асетний ERB-файл | неглибока |
| solidus_admin (нова) | немає — importmap і tailwindcss-rails | уже сумісна |
| solidus_backend (стара) | 151 директива Sprockets, конкатенація вендорених jQuery, Backbone, Handlebars, select2, underscore | глибока |

Зв'язка в ядрі менша, ніж підказує заголовок. Її єдиний асетний ERB використовує ERB рівно для одного — інтерполяції шляху монтування в `Spree.mountedAt()`, — і мета-тег замінює це за пів дня. Зауважте: в усьому дереві лише два ERB-файли взагалі належать пайплайну асетів; решта — в'ю-шаблони, що відповідають на AJAX-запити, і Propshaft їх ніколи не торкається.

> **СТАРА АДМІНКА — ЦЕ ЯКІР, І ЙОГО МОЖНА ОБІЙТИ**
> Оскільки мета-гем досі постачає solidus_backend, перевести нові встановлення на Propshaft за замовчуванням, здається, можна лише після розв'язання питання адмінки — залежність від того єдиного рішення, якого цей проєкт не ухвалює вже три роки.
> 
> Це можна обійти збоку. JavaScript старої адмінки — легасі й заморожений; ніхто не пише нові Backbone-в'ю у 2026. Sprockets тут потрібен, щоб збирати ці асети на кожному завантаженні, тоді як насправді досить уже зібраного артефакту. Скомпілюйте all.js і all.css один раз, покладіть їх статичними файлами — і Propshaft просто їх віддаватиме.
> 
> Це повністю розчіплює рішення про пайплайн асетів від рішення про адмінку — і це той самий патерн, завдяки якому вдався сторфронт у [§05](#продукт): увібрати готову річ замість переписувати її.

### Історія з рантаймом, яка важить більше, ніж здається

У Solidus **немає `package.json`, немає lock-файла і немає графа npm-залежностей ніде в репозиторії** `[observed]`. Він використовує `importmap-rails` — інструмент, що існує саме для того, щоб обходитися без Node.js, — і `tailwindcss-rails`, який постачає standalone-бінарник. JavaScript є — jQuery у старій адмінці, Turbo і Stimulus у новій — але це Rails-нативний стиль додавання поведінки до відрендерених на сервері сторінок, а не окремий застосунок.

Spree, для порівняння, носить `package.json`, `pnpm-lock.yaml`, pnpm-воркспейс, Turborepo і Biome, плюс одинадцять JavaScript-пакетів `[observed]`.

Практична різниця для мерчанта: **один рантайм в експлуатації і жодного JavaScript-ланцюга постачання для аудиту — проти двох рантаймів і двох ланцюгів постачання.** Це одна з небагатьох справжніх і тривких переваг, які Solidus ще тримає, і [§16](#виберіть-роль) будує саме на ній.

## Розтин адмінки

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

- **v0.4.0** — Версія — за три роки і три місяці
- **вимкнено** — Редагування замовлень і товарів, за замовчуванням
- **27 екранів** — У старій адмінці — без жодної заміни

Спершу віддамо належне: нова адмінка *добре збудована*. Це сучасний Rails-движок на ViewComponent, Turbo, Stimulus і Tailwind, зі 132 компонентами та 93 файлами тестів. Це не проблема якості.

> **ЧОМУ АДМІНКА СТОЇТЬ У ЦЬОМУ ЗВІТІ ВИЩЕ ЗА ВСЕ ІНШЕ**
> Для хостованої платформи продукт — це сторфронт. Для фреймворку все навпаки. Сторфронт Solidus постачається як шаблон застосунку — ти копіюєш його у свій застосунок і змінюєш, і так робить кожен серйозний мерчант. Ніхто не запускає еталонний сторфронт без змін; кастомізувати його — і є суть.
> 
> Адмінка — це той компонент, яким мерчанти користуються як є, щодня, щоб вести бізнес: прийняти платіж, оформити повернення коштів, відредагувати варіант, скоригувати запаси, обробити повернення. Це єдина частина комерційного фреймворку, яка мусить працювати з коробки, бо це єдина частина, яку ніхто не хоче перебудовувати.
> 
> Це перевертає інтуїцію, що найбільше важить поверхня, звернена до покупця. Сторфронт, який не подобається, мерчант може обійти, написавши власний. Відсутній процес повернень обійти не можна. Саме тому 27 неперенесених екранів — це ядро щоденних операцій, а не довгий хвіст, і саме тому на вершині реєстру стоїть [R3](#r3), а не конкурентний ризик.

### Знахідка 1 — два екрани, в яких мерчант живе, за замовчуванням не працюють

Свої вебадреси Rails-застосунок оголошує у файлі маршрутів. Нова адмінка Solidus загортає свої найважливіші маршрути в умову:

|  |
| --- |
| admin_resources :products, only: [:show, :edit], constraints: -> { SolidusAdmin::Config.enable_alpha_features? && … } |
| admin_resources :orders, except: [:destroy, :index], constraints: -> { SolidusAdmin::Config.enable_alpha_features? } |

А у файлі конфігурації: `preference :enable_alpha_features, :boolean, default: false`.

> З коробки нова адмінка може показати список замовлень і список товарів — але не може відкрити жодного з них. Переглянути замовлення, відредагувати товар — екрани, в яких менеджер магазину проводить цілий день, — за вимикачем, який вимкнено. А що справді працює за замовчуванням, то це розділ налаштувань.
> 
> Це водночас і власний опублікований вердикт команди: робота не готова. Вимкнено вже роками.

### Знахідка 2 — більшість зробленого — часткове

У новій адмінці 32 контролери проти 50 у старій. Але гола кількість перебільшує прогрес. Тринадцять із 32 автоматично успадковують типову поведінку create/read/update/delete — і всі тринадцять — це маловідвідувані екрани налаштувань (причини, категорії, зони, ролі). Із сімнадцяти написаних вручну **шість уміють лише показувати список і видаляти, без жодного способу створити чи відредагувати**: методи оплати, податкові ставки, методи доставки, магазини, типи опцій і таксономії.

### Знахідка 3 — 27 екранів не мають заміни взагалі

- **Увесь процес повернень і відшкодувань** — платежі, повернення коштів, компенсації, авторизації повернень, позиції повернень, повернення покупців, скасування
- **Дані товару поза самим записом товару** — варіанти, ціни, зображення, значення опцій, властивості товарів
- **Мерчандайзинг** — таксони (дерево категорій), рухи запасів
- **Сам дашборд**
- Плюс загальні налаштування, теми, локалі, ключі API, пошук, дані покупця

Перенесено довгий хвіст конфігурації. Бракує ядра щоденних операцій. **«64% готовності за кількістю контролерів» сильно завищує повноту, якщо міряти тим, що мерчант насправді робить.**

### Знахідка 4 — заміна залежить від того, що вона заміняє

> Визначення пакета нової адмінки оголошує жорстку залежність від solidus_backend — старої адмінки, — а її компоненти посилаються на вебадреси старої адмінки для коригувань, рухів запасів та історії store credit `[observed]`.
> 
> Нова адмінка потребує старої, щоб функціонувати. Це накладка, а не заміна. Ось чому інсталяція за замовчуванням досі постачає стару адмінку і чому кожен новий магазин отримує обидві. Це також означає, що навіть за повного паритету функцій прибрати стару адмінку — то другий проєкт, а не фінішна риска цього.

### Чому все зупинилось — три причини, що підсилюють одна одну

#### F1 — Визначення «готово» існувало, і гроші до нього не підключили

$45,760 купили шість «Agile Design Sprints» і один «Redesign Analysis». Ніщо в тій покупці не називало жодного відвантаженого екрана, дати завершення чи власника після останнього спринту.

**Найгостріше тут те, що чекліст завершення вже існував.** Issue [#5391](https://github.com/solidusio/solidus/issues/5391), відкритий у вересні 2023-го і досі відкритий, викладає план перенесення з явним обґрунтуванням послідовності — *«Ми хочемо взятися спершу за легкі сторінки, щоб поступово покращувати й нарощувати компоненти нашого UI-kit, а потім перевикористати їх для міграції складніших сторінок (напр. промоакцій)»* — а далі список задач `[observed]`:

| [#5391](https://github.com/solidusio/solidus/issues/5391) · «низько навислі плоди» | Відмічено? | Фактичний стан у коді сьогодні |
| --- | --- | --- |
| Налаштування > Зони | ні | повний CRUD через ResourcesController — зроблено |
| Налаштування > Податки | ні | податкові категорії зроблено; податкові ставки — лише список |
| Налаштування > Повернення й відшкодування | ні | довідники причин зроблено; сам процес повернень відсутній |
| Налаштування > Доставка | ні | категорії зроблено; методи — лише список |
| Налаштування > Платежі | ні | лише список |
| Налаштування > Магазини | ні | лише список |

Зауважте, що це за чекліст: **шість найлегших екранів у застосунку** — а нижче видно, чому вибрати їх першими було помилкою. Проєкт визначив, що означає «готово», опублікував це — а потім перестав доглядати визначення. **Жоден пункт не відмічено за три роки, включно з роботою, яка доказово завершена** — перевірено ще раз 8 серпня 2026 року: всі шість пунктів досі порожні `[observed]`. Був і публічний наратив: блогопост за Q2 2023 повідомляв, що «новий досвід адмінки потребував певних початкових зусиль; тепер, коли головні компоненти збудовано, реалізувати решту розділів буде легше і швидше» `[web]`.

Отже, провал — не у відсутності гейта. Це **гейт, за закриття якого ніхто не відповідав**, і покупка, що придбала спринти, а не галочки.

#### F2 — Збудовано однією організацією, передано нікому

Авторство адмінки 2023 року: Елія Скіто 370, Райнер Дема 132, Марк Буске 102, Альберто Вена 6 — приблизно 98% з орбіти Nebulab. 2024-й розпорошився між шістьма людьми, поки вони згортались. **2025-й витягнула одна людина, Юджин Чайкін (комітить як chaimann), — 151 зі 193 комітів.** 2026-й має 19 комітів від п'яти людей і жодного власника `[observed]`.

#### F3 — Роботу останнього розробника покинули на півдорозі

Сім pull request-ів, відкритих уже рік, наводять на думку, що готова робота чекає на рев'юерів. Читання самих тредів — комітів, інлайн-коментарів рев'ю і розмов — дає точнішу відповідь `[observed]`:

| Pull request | Автор | Стан | Останній людський коміт | Активність рев'ю |
| --- | --- | --- | --- | --- |
| [#6302](https://github.com/solidusio/solidus/pull/6302) створення/редагування методів оплати | chaimann | чернетка | 2025-07-04 | жодної |
| [#6298](https://github.com/solidusio/solidus/pull/6298) створення/редагування податкових ставок | chaimann | чернетка | 2025-06-27 | жодної |
| [#6296](https://github.com/solidusio/solidus/pull/6296) категорії товарів | chaimann | чернетка | 2025-06-17 | жодної |
| [#6236](https://github.com/solidusio/solidus/pull/6236) типи опцій | chaimann | чернетка | 2025-05-26 | жодної |
| [#6228](https://github.com/solidusio/solidus/pull/6228) створення/редагування магазину | chaimann | чернетка | 2025-06-27 | жодної |
| [#6232](https://github.com/solidusio/solidus/pull/6232) методи доставки | JustShah | чернетка | 2025-05-07 | 4 інлайн-коментарі, рев'ю від elia та бота Copilot |
| [#6295](https://github.com/solidusio/solidus/pull/6295) діалог підтвердження | chaimann | готово | 2025-06 | підхоплений іншим контриб'ютором, липень 2026 |

**Застереження щодо часових міток.** GitHub показує кілька цих чернеток як оновлені за лічені дні до цієї редакції, що читається як активна робота. Це не так — останні людські коміти датовані серединою 2025-го. Ці мітки — рух базової гілки та переобчислення можливості злиття.

**П'ять із семи — чернетки з буквально нульовою активністю рев'ю** — жодних рев'ю, жодних інлайн-коментарів, жодної розмови. Для чернетки це коректна поведінка; ніхто не рев'ює роботу, позначену як неготову. Але це означає, що затор на тих п'ятьох — авторство: їх так і не подали, і вони лежать без руху із середини 2025-го, від останнього коміту автора.

> **#6295 НЕ ПОКИНУТИЙ — ЙОГО ПІДХОПИЛИ, І ПІДХОПЛЕННЯ ВЖЕ ДАЄ РЕЗУЛЬТАТ**
> Єдиний PR, позначений готовим до рев'ю, має живий тред. Після повідомлення про конфлікт (липень 2025) і технічного заперечення від мейнтейнера, який волів нативну поведінку Turbo замість нової бібліотечної залежності (серпень 2025), долучився інший контриб'ютор `[observed]`:
> 
> > **forkata** · 2026-06-30
> > "Думаю взятися за оновлення цього PR, щоб ми могли його змерджити. Хотів звіритися з тобою, чи ти активно над ним працюєш…"
> 
> > **tvdeyen** · 2026-07-01
> > "звісно, вперед. Я активно над цим не працюю. Досі не в захваті від бібліотеки, якої нам не треба, але й воювати за це не буду. Хоча одна остання спроба: це не так уже й складно 😉"
> 
> > **forkata** · 2026-07-06
> > "Звучить чудово, спробую прибрати залежність і отримати ту саму поведінку нативною функціональністю Turbo!"
> 
> Це здорова спільнота, яка добре робить складну річ: мейнтейнер поступається в дизайнерській суперечці замість блокувати нею, а контриб'ютор зголошується підхопити чужу застряглу роботу і приймає підхід, якому віддає перевагу рев'юер. І обіцянку дотримано: 30 липня 2026 року forkata відкрив [#6528](https://github.com/solidusio/solidus/pull/6528) — «Admin confirm modal without external dependency» — ту саму функцію, перебудовану так, як хотів рев'юер `[observed]`. У проєкту є робочий механізм порятунку осиротілої роботи, і він працює просто зараз.
> 
> Чого механізм не зробив, так це не спрацював системно. Один із шести осиротілих pull request-ів знайшов нового господаря — через рік після того, як його автор зупинився. Решта п'ять лежать неторканими. [PL5](#pl5) — це той самий механізм, зроблений рутиною.

Отже, скориговане прочитання: затор — це авторство, а не пропускна здатність рев'ю, але «покинуто» — перебільшення. Роботу залишили в чернетках, і вона зачерствіла; механізм відповіді проєкту працює, коли хтось запускає його вручну, і для решти ніхто його не запустив. Зауважте, що саме покривають ці сім — методи оплати, податкові ставки, магазини, типи опцій, методи доставки — **саме ті шість екранів «лише список» зі Знахідки 2.** План був цілісний; людина, що його несла, зупинилась, і відтоді підхоплено лише один тред.

*Побіжне спостереження:* бот-рев'юер pull request-ів Copilot залишив рев'ю на [#6232](https://github.com/solidusio/solidus/pull/6232) у травні 2025 `[observed]`. Тож якесь агентське інструментування вже сидить на шляху рев'ю, хоча ніщо не підтримує агентське *авторство* ([§07](#машина)).

> **ЧОМУ ЖОДНА ТРИВОГА НЕ ПРОЛУНАЛА**
> Архітектура робить зупинку на півдорозі цілком стабільною. Оскільки нова адмінка залежить від старої і сама вимикає свої незавершені екрани, напівзбудоване переписування ззовні виглядає абсолютно здоровим: тести проходять, релізи виходять, жодна сторінка не віддає 404, жоден мерчант не бачить помилки. Система збудована так, що покинутість не дає жодного симптому.

> Найдорожча ініціатива в історії проєкту зупинилась без жодного звуку: три роки і $45,760 по тому нова адмінка — на версії 0.4, а архітектура влаштована так, що покинутість не дає жодного симптому.

### Скільки насправді треба, щоб закрити розрив?

Варто оцінити розмір, бо «три роки і незавершено» натякає, що роботи лишилося більше, ніж показує код.

132 наявні компоненти разом дають **7,716 рядків** і покривають приблизно дев'ятнадцять робочих екранів. Контролер «лише список» — це 30–36 рядків з одним-двома файлами компонентів `[observed]`. Якщо екстраполювати з тією ж щільністю, відсутня поверхня — порядку **8,000–11,000 рядків**: відчутно, але не політ на Місяць.

Друга, незалежна міра показує те саме. Оскільки обидві адмінки рендеряться на сервері, шаблони в'ю — чесний прокси поверхні екранів: стара адмінка несе **277 ERB-шаблонів проти 111 у новій** `[observed]`. Це ставить перенесення приблизно на **40% за кількістю шаблонів** — до 64% за контролерами воно наближається, лише якщо вірити, що всі контролери рівні, а знахідки вище кажуть, що це не так. Дві різні міри, і обидві лягають добряче нижче голого співвідношення контролерів.

| Робота | Розмір | Природа |
| --- | --- | --- |
| Додати create/edit до шести екранів «лише список» | мала | код здебільшого вже існує — у п'яти осиротілих чернеткових pull request-ах |
| Перенести ~15 простих екранів (локалі, теми, ключі API, налаштування, зображення, властивості) | середня | механічна, легко делегується, дружня до агентів |
| Перенести процес повернень і відшкодувань (7 контролерів) | велика | по-справжньому складна доменна логіка, не механіка |
| Перенести варіанти, ціни, таксони, рухи запасів | велика | серце мерчандайзингу; глибока взаємодія з ядром |
| Визнати екрани замовлень і товарів готовими та увімкнути альфа-вимикач | судження | жодного коду — рішення, яке нині ніхто не має повноважень ухвалити |
| Прибрати залежність від старої адмінки | окремий проєкт | можливо лише після всього переліченого |

> Чесна відповідь: решта роботи — кілька зосереджених місяців для однієї людини, або значно менше, якщо механічну середню смугу делегувати агентам, — але її гейтять дві речі, яких за гроші не купити.
> 
> По-перше, робота над поверненнями/відшкодуваннями і мерчандайзингом — це справжня доменна інженерія, а не перенесення. По-друге, і це вагоміше: хтось має тримати це два-три квартали поспіль. Саме цього ресурсу проєкт не спромігся дати з 2024 року, і саме тому обмежувальний чинник — [F2](#f2), а не обсяг коду.

### Послідовність була перевернута, і це хрестоматійний провал

Плейбук міграцій Вілла Ларсона — стандартний довідник з виплати технічного боргу в масштабі — задає три фази `[web]`:

- **Derisk** — «Напишіть дизайн-документ і обкатайте його з командами, яким, на вашу думку, мігрувати буде найважче.» Він явно застерігає не починати з легких випадків, бо це «створює оманливе відчуття прогресу».
- **Enable** — збудуйте інструментування, щоб «програмно мігрувати легкі дев'яносто відсотків».
- **Finish** — зупиніть кровотечу, згенеруйте тікети відстеження і прийміть, що довгий хвіст вимагає, щоб команда міграції «сама залізла в усі закутки».

> План перенесення Solidus формулює протилежну стратегію власними словами. Issue [#5391](https://github.com/solidusio/solidus/issues/5391): «Ми хочемо взятися спершу за легкі сторінки, щоб поступово покращувати й нарощувати компоненти нашого UI-kit, а потім перевикористати їх для міграції складніших сторінок (напр. промоакцій)» `[observed]`.
> 
> Передбачений провал — саме той, який ми й спостерігаємо. Легкі сторінки налаштувань перенесли частково. Упевненість бігла попереду реальності — пост за Q2 2023 повідомляв, що «головні компоненти збудовано, реалізувати решту розділів буде легше і швидше» `[web]`. А тверде ядро, де насправді живе доменна складність, — повернення, відшкодування, компенсації, варіанти, ціни, таксони — так і не почали взагалі.
> 
> Три роки по тому проєкт має напівперенесену поверхню налаштувань, невідмічений чекліст і жодного свідчення в будь-який бік про те, чи здатна обрана архітектура виразити складні екрани. Оце і є справжня ціна «спершу легкого»: після $45,760 і трьох років центральне технічне питання досі без відповіді.
> 
> На 24-й редакції Core Team відповіла на цю знахідку прямо: часткова поступка щодо послідовності — «є аргумент, що варто було почати з важкого, або принаймні дійти до нього швидше» — але суперечка щодо ставок: «viability isn't a concern… не думаю, що хтось переймається, ніби їх неможливо збудувати. Поки проєкт до 1.0, переробки — не така вже й біда» `[user]`. Упевненість інсайдера — це судження стейкхолдера, а не перенесений екран повернень: питання звужується з чи можна це збудувати до скільки доведеться переробити, і один складний екран — досі єдине свідчення, яке закриває його для зовнішнього читача.

### Чи відкинули її мерчанти?

Розумна теорія, і свідчення її не підтримують. Відкриті issue про адмінку — переважно *запити на відсутні функції*: «додайте створення таксономій», «додайте характеристики товару», «редагування кількості товару на складі», «увімкніть створення типів опцій» — підпис незавершеного, а не нелюбого. Тікетів про юзабіліті існує два. Статус-апдейт за травень 2025 відгукувався про роботу позитивно `[observed]` `[web]`.

Єдиний справжній аргумент «за»: альфа-вимикач роками вимкнений, а це власний вердикт команди щодо якості. І приватний фідбек у Slack невидимий для цього аудиту, тож **теорія не закрита повністю**.

## Spree, виміряний

Конкурент, від якого Solidus відгалузився форком у 2015 році, — той потім помер, а тепер повернувся з грошима за спиною. Цифри з GitHub API за 25 липня 2026 року; релізи перевірено ще раз 8 серпня.

Одна поправка до народного наративу — від Core Team на 24-й редакції: на старті жодної ворожнечі не було. Після розколу проєкти якийсь час співпрацювали напряму — надто щодо проблем безпеки, які зачіпали обидва, — а зв'язки обірвалися пізніше, зі зсувами стратегії та зміною тих, хто вів цей проєкт. «Єдина справжня „драма“ — хіба те, що вони використовують проєкти на Solidus як кейси на сайті Spree» `[user]`. Теперішній час, той самий голос на 25-й редакції: «дуже різні підходи», незгода щодо ліцензування й технічної стратегії, і «no beef these days, though. Just different directions» `[user]`.

| Метрика | Solidus | Spree |
| --- | --- | --- |
| Коміти за останні 52 тижні (власний ряд GitHub — git log у [§06](#люди) нараховує 493 за те саме вікно; співвідношення 5.5× береться одним інструментом з обох боків) | 400 | 2,190 — 5.5× |
| Зірки GitHub | 5,317 | 15,572 |
| Форки | 1,400 | 5,287 |
| Останній реліз | v4.7.0 · 15 квіт. 2026 | v5.6.1 · 28 лип. 2026 |
| Платформні релізи в липні 2026 | 0 | 6 |
| Сукупні завантаження пакетів | 3.22M | 2.85M |

### Порівняння можливостей

| Можливість | Solidus v4.7.0 | Spree v5.6 |
| --- | --- | --- |
| REST API | так | з OpenAPI-специфікацією |
| GraphQL | заморожений з жовтня 2023 | не пропонується |
| Адмін-інтерфейс | два — старий, плюс v0.4 з вимкненими головними екранами | один, із системою плагінів |
| Сторфронт | серверний Rails-шаблон, 64 файли спеків, ставиться генератором | Next.js 16 / React 19 / TypeScript, окремий репозиторій |
| TypeScript SDK | ні | три пакети |
| Інструмент командного рядка | ні | запуск, генерація, міграції, запити до API |
| Налаштування проєкту однією командою | багатокрокове ручне встановлення | npx create-spree-app — 1,607 завантажень за останній місяць |
| Хостована проба | ні | безкоштовна пісочниця, нічого не треба ставити |
| Агентський харнес для AI | немає | AGENTS.md, CLAUDE.md, закомічені налаштування агентів, хуки, скіли |
| Опубліковані агентські скіли | ні | для «Claude Code, Cursor, Copilot і 60+ інших інструментів» |
| MCP-сервер документації | ні | так |
| Канали продажів, резервування запасів, маршрутизація замовлень | ні | безкоштовна редакція |
| B2B — прайс-листи, процеси погодження | ні | платний Enterprise |
| Маркетплейс із кількома продавцями | ні | платний Enterprise |
| Мультитенантний white-label | ні | платний Enterprise |
| Без JavaScript-ланцюга постачання | нуль npm-залежностей | pnpm, Turborepo, 11 JS-пакетів |
| Ніхто не може переліцензувати | BSD-3 повсюдно | Enterprise-модулі комерційні |
| Підтримка | спільнотний Slack | спільнотний Slack · або платні SLA, 24/7, виділений менеджер |

**Прочитайте три останні рядки разом.** Це єдині рядки, де Solidus виграє, і це не випадковість — це наслідок того, що Solidus лишився тим, чим Spree бути перестав.

> **ЩО НАСПРАВДІ ОЗНАЧАЄ «КРАЩЕ ПРОФІНАНСОВАНИЙ»**
> Безкоштовна редакція Spree містить сторфронт, чекаут, канали продажів, резервування запасів, маршрутизацію замовлень і API. Enterprise Edition додає три окремо ліцензовані комерційні модулі — маркетплейс, B2B, мультитенантність — плюс рівень підтримки з градуйованими гарантіями часу відповіді, релізами з довгостроковою підтримкою та цілодобовим моніторингом `[web]`. Ціни не опубліковані; за однією сторонньою оцінкою, ліцензія та впровадження першого року обійдуться в п'яти-шестизначні суми `[web]`.
> 
> Безкоштовна редакція Spree — воронка продажів для enterprise-ліцензій. Безкоштовна редакція Solidus — це весь продукт, і за ним нічого немає.
> 
> Це структурна різниця, а не збіг обставин. Опенсорсна робота Spree — це витрата на маркетинг і R&D, вписана в enterprise-звіт про прибутки й збитки; робота Solidus тримається на банці пожертв, що приносить близько $25k на рік. Колектив зі спільнотним врядуванням не може відтворити цю модель, не переставши ним бути `[inferred]`.

> Опенсорс Spree — маркетингова витрата на плечах справжнього бізнесу; опенсорс Solidus тримається на банці пожертв у $25k на рік.

> **РОЗРИВ У ХАРНЕСІ ЗАСЛУГОВУЄ НА ОКРЕМИЙ АБЗАЦ**
> Spree публікує скіли для AI-агентів, які встановлюються однією командою, тримає MCP-сервер документації й рекламує свій інструмент командного рядка як такий, що працює «hands-free для AI-агентів». Усередині він несе файли інструкцій для агентів, закомічені дозволи, хуки та скіли із зафіксованими версіями `[observed]` `[web]`. У Solidus нічого з цього немає — перевірено ще раз 8 серпня 2026 року: в корені репозиторію досі немає жодного файлу інструкцій для агентів `[observed]`.
> 
> Це харнес-інжиніринг як продуктова стратегія: зробити фреймворк читабельним для AI-агентів — це канал дистрибуції, бо дедалі більша частка нових проєктів починається з того, що розробник просить агента його побудувати. Spree бореться за канал, де тепер стартують нові магазини, а Solidus у ньому відсутній.
> 
> Чесне застереження: причинність не доведена. Spree має ще й комерційне фінансування, тож харнес може бути симптомом ресурсів, а не причиною пропускної здатності. А одна стороння стаття стверджує, що сплеск активності Spree «насамперед рухають LLM-згенеровані контрибуції» `[web]` — якщо це правда, це поставило б під сумнів цифру 5.5×, бо обсяг не дорівнював би цінності.

> **АЛЕ ЗАНЕПАД SOLIDUS СПРИЧИНИВ НЕ SPREE**
> Spree комерційно перезапустився у квітні 2025-го. Скасування спонсорств Solidus — 7 · 7 · 7 · 4 · 5 · 2 · 5 · 2 на рік, починаючи з 2019-го, — причому 2024 і 2026 — два найнижчі роки за всю історію. Жодного виходу спонсорів після перезапуску немає. Інженерія Nebulab обвалилася ще 2024 року, за цілий рік до Spree 5.0 `[observed]`.
> 
> Занепад Solidus ендогенний — довготривале виснаження спонсорів, втрата доглядача й обвал потужності в середині 2025-го. Відродження Spree — окрема, паралельна подія. Змінює вона не причину, а опції: закриває варіант «наздоженемо потім».

> Конкурент одним рядком: Spree відвантажує у п'ять з половиною разів більше комітів, ніж Solidus, шість платформних релізів лише за липень 2026-го, а його безкоштовна редакція — воронка продажів платного enterprise-продукту.

## Стратегія, що вже діє

Перш ніж пропонувати нову стратегію, варто записати ту, що вже керує рішеннями — незалежно від того, чи хтось її записував. Вона є завжди. Пропозиції, які суперечать неназваному правилу, наштовхуються на опір механізмів, на які ніхто в кімнаті не може вказати. Саме тому кожна політика в [§02](#політики-й-операції) називає свій стосунок до цих рядків.

| # | Правило, якби його записали | Записано? | Працює? |
| --- | --- | --- | --- |
| S1 | Свідомо відкинути напрям JavaScript-фреймворків. Простота, один стек, жодних оплат, розподілене врядування. | у блозі компанії провідного мейнтейнера | Фактична стратегія проєкту — сформульована, просто не тут |
| S2 | Ніколи не ламати наявний магазин. Депрекація перед видаленням; бекпорт виправлень у старі версії. | ратифіковано | Тримається — ціною, яку ніхто не порахував |
| S3 | Постачати заміни поруч зі старою версією як opt-in, з написаним гайдом міграції; стара лишається, доки магазини не переїхали. | у гемах, не у врядуванні | Працює — див. гайд міграції промоакцій |
| S4 | Ядро лишається худим; можливості живуть в окремих розширеннях. | ніде | Слабшає — чотири офіційні розширення заморожені |
| S5 | Право мерджити належить Core Team, яка сама себе призначає. Гроші купують голоси щодо витрат, ніколи — щодо коду. | ратифіковано | Так — розділення навмисне і здорове |
| S6 | Якість забезпечують машини; про стиль не сперечаються. | лише в конфігурації CI | Правило, що працює в проєкті найкраще |
| S7 | Усю доставку роблять люди. | мовчазно, через відсутність | Неперевірено — агентського харнеса не існує |

### Стратегія записана — просто не проєктом

> Технічний напрям Solidus записаний — його просто легко проґавити через те, де він живе. Провідний мейнтейнер опублікував його 12 травня 2026 року — в пості, що порівнює Solidus і Spree `[web]`. Заявлені стовпи:
> 
> Врядування — «Spree керує одна компанія. За останні два роки понад 90% комітів у проєкт приходять від цієї компанії» — проти core team Solidus, «складеної з представників багатьох різних компаній».Ліцензування — «Solidus лишається повністю безкоштовним. Жодних оплат взагалі. Ви володієте своїм eCommerce-стеком».Технічний напрям — шлях JavaScript-фреймворків відкинуто свідомо: команди виявляють, що «зросла складність була того не варта», а «бізнесам цифрової комерції потрібні прості й ефективні рішення, а не кілька веб-стеків».Філософія — «стабільність, вдумливість і контроль».
> 
> Цей звіт незалежно дійшов майже того самого позиціонування в [§16](#виберіть-роль). Ця збіжність заспокоює щодо аналізу і невтішна щодо знахідки: це не було відкриттям. Стратегія існує, вона артикульована — і живе в маркетинговому блозі консалтингу, а не у власних артефактах проєкту.
> 
> Оце і є справжня знахідка про борг знань — гостріша, і виправити її легше, ніж «стратегії не існує». Перенести [S1](#s1) у керівний документ коштує пів дня роботи: [E5](#e5) у швидкій смузі, [PL3](#pl3) як постійне правило.

### Що ще ловить ця таблиця

- **[S3](#s3) працює краще, ніж натякає лічильник незавершених міграцій.** Гем промоакцій постачає гайд міграції на 190 рядків і явну пораду «мігруйте за першої нагоди». Дисципліна є; бракує *запланованої дати видалення*, а не практики. Саме цю поправку вносить [PL1](#pl1).
- **[S2](#s2) забезпечує машина, і це саме те, що треба** — гейт збірки, а не добрий намір.
- **[S5](#s5) призначає повноваження — і на цьому зупиняється.** Він дає Core Team останнє слово щодо того, що йде в ядро, а групі стейкхолдерів — зважений голос щодо грошей, — і далі нічого не каже про те, коли будь-який із цих органів збирається щодо технічного питання, що саме він вирішує і де записується відповідь. Адмінку три роки ані відвантажено, ані скасовано — всередині структури, яка явно дозволяє і те, і те. [PL4](#pl4) додає відсутній майданчик, не зсуваючи повноваження ані на міліметр.

### Роадмап записує минуле і не планує нічого

Статусне оновлення травня 2025-го обіцяло «подвоїти ставку на наявний GitHub-проєкт під назвою Roadmap» заради прозорості. Його справді тримали живим — оновлювали в червні 2026-го. Але з його **76 пунктів 65 — це змерджені pull request-и, а 7 — закриті issue. Рівно три відкриті issue й один відкритий pull request дивляться вперед**, і один із цих трьох — господарський пункт, якого востаннє торкалися у травні 2025-го `[observed]`.

> Це чейнджлог, що носить ім'я роадмапу. Не застарілий — активно підтримуваний — але він документує, що сталося, а не каже, що станеться. Потенційний користувач, який перевіряє, чи має Solidus майбутнє, знаходить добре ведений запис того, що в нього було минуле.
> 
> Це той самий режим відмови, що й у [S1](#s1): проєкт робить роботу і не заявляє наміру.

## Першопричини

Два механізми породжують майже кожен симптом у цьому звіті, і вони підсилюють один одного.

**RC1 — Міграції спроєктовано, але ніколи не заплановано**

Проєкт очевидно *вміє* добре проводити міграції. Промоакції йдуть із 190-рядковим гайдом, що покриває міграцію даних, перемикання поведінки, кастомні правила й видалення легасі, а на додачу прямо радить мігрувати вже зараз. Сторфронт чисто поглинули за шість тижнів чотири людини з двох організацій `[observed]`.

Проблема й не у відсутності планів. Адмінка має опублікований чекліст перенесення з обґрунтуванням послідовності ([#5391](https://github.com/solidusio/solidus/issues/5391), [§08](#розтин-адмінки)); промоакції мають 190-рядковий гайд міграції; є майлстоуни для 4.8 і 5.0. **Артефакти існують і стоять занедбані.**

**Але «призначте власника й дату» — хибний рецепт для волонтерського проєкту, і тут варто бути обережним.** Не можна призначити людині дедлайн, якщо за його дотримання їй не платять. Робота без власника й без дати — це *нормальний* стан волонтерського опенсорсу, а не патологія; трактувати це як провал врядування означає не розуміти режим, у якому живе проєкт.

Двом застряглим міграціям потрібні різні речі, і змішати їх — означає цю різницю стерти:

- **Промоакціям потрібна заява про політику, а не потужності.** Робота вже зроблена — повний движок зі 113 файлами спеків і 190-рядковим гайдом міграції. Дата видалення легасі-движка («Solidus 5.0 його прибирає») не вимагає ні від кого жодної роботи; це зобов'язання, яке проєкт може просто взяти. І Rails, і Ruby публікують графіки депрекацій саме так. **Це справді безкоштовно — і це досі не зроблено.**
- **Адмінці потрібні оплачені потужності, і їх не наволонтериш.** Двадцять сім відсутніх екранів, включно з процесом повернень, — цього безгоспний чекліст не породить. Такого й не могло статися, і сподіватися на інше — ось справжня помилка в цій історії.

> І це вказує на справжню прогалину: із липня 2025 нікому за це не платять, а заплатити є чим — $133,750.
> 
> Проєкт чотири рази оплачував розробку — ритейнер мейнтейнера 2020 року, ривок з адмінкою 2023-го, контрактні розробники впродовж 2024-го й на початку 2025-го ([§04](#гроші)). Щоразу гроші купували рух. Відколи скінчилася остання угода, баланс зріс, а в адмінці нічого не зрушило.
> 
> Тож [RC1](#rc1) — це не «немає календаря». Це непрофінансована ініціатива поруч із невитраченим бюджетом — а артефакти виглядають занедбаними, бо роботу, за яку треба було платити, лишили на руках у волонтерів.

Ensures: Міграція може застрягти на невизначений час, і ніхто цього не помітить

**RC2 — Доглядач змінився в коді, але не у врядуванні**

Nebulab пішли з \~60% комітів до \~1% без жодного публічного оголошення `[observed]` `[web]`. Два симптоми, зафіксовані окремо в інших місцях, походять з цього одного факту: переписування адмінки застрягло, а його pull request-и осиротіли.

Провина не в самому відході. Ротація спонсорів — це нормально, і Nebulab лишається найбільшим сукупним фандером. Провина в тому, що **проєкт має механізм передачі грошей і жодного механізму передачі спонсорства незавершеної роботи.** Коли спонсор іде, його ставки ніхто не переприсвоює і не скасовує — вони сиротіють у стані, який правило [S2](#s2) далі зберігає безстроково.

**І це вже вдруге.** Stembolt купили 2018 року, і вони теж пішли. Передача 2018-го вдалася лише тому, що охочий наступник випадково знайшовся. Ланцюг опіки читається так: Stembolt → Nebulab → ніхто `[inferred]`.

> Втрата доглядача — це не шок, який цей проєкт пережив один раз; це його нормальний стан, і за десять років врядування так і не виростило механізму давати цьому раду.

Ensures: Що наступною станеться саме одна із застряглих міграцій

> Дві причини складаються в один стан: непрофінансована ініціатива поруч із невитраченим бюджетом.

## Реєстр ризиків

Те, що може статися, — ранжовано за шкодою × ймовірністю × *шансом, що ти помітиш до того, як вкусить* × вартістю відновлення. Третій множник легко проґавити: тихий провал важить більше за гучний того ж розміру, бо ніщо тебе не попереджає.

**R1 — Рутинний дрейф залежностей між безпековими релізами** *(понижено)*
Вужче, ніж підказує читання самого лише репозиторію. Solidus має програму розкриття вразливостей на HackerOne, автоматичні безпекові оновлення залежностей, 18-місячне вікно патчів для трьох підтримуваних версій, два обов'язкові рев'ю перед мерджем і багатофакторну автентифікацію на релізних акаунтах ([§07](#машина)) `[web]`. Шлях, яким відома вразливість дістається магазинів, добре захищений.Лишається прогалина довкола цього шляху: немає автоматичних рутинних підвищень версій і немає кроку bundler-audit у збірці, тож звичайний дрейф залежностей накопичується між безпековими подіями і ловиться лише тоді, коли хтось подивиться `[observed]`. Виправлення — два конфігураційні файли: [E2](#e2) і [E3](#e3) у швидкій смузі.
If it happens: Застарілі транзитивні залежності тихо старіють; вікно експозиції до моменту, коли розкриту проблему помітять, ширшає
Likelihood: Низька для розкритих вразливостей — цей шлях покрито. Середня для дрейфу
Would you notice? Для розкритої CVE — так. Для поступового дрейфу — ні
Cost: Помірна, не критична
What would change my mind: Поява конфігурації версійних оновлень Renovate чи Dependabot, яка закриє це повністю

**R2 — Дві фірми — це 78% грошей і більшість коду** *(важко помітити)*
Концентрація коду й концентрація фінансування — одна й та сама залежність, побачена з двох боків. Найбільший індивідуальний контриб'ютор комітить з особистої адреси, без організації за спиною. Одна з двох фірм тепер рекламує роботу з Shopify нарівні з Solidus `[observed]` `[web]`. Жодна політика в цьому звіті не береться за саму концентрацію — це відкладення аргументовано в [§02](#політики-й-операції).
If it happens: Втрата будь-якої з двох фірм забирає одразу ~39% фінансування і чималу частку пропускної здатності
Likelihood: Середня — це вже ставалося двічі
Would you notice? Місяцями — ні. Відхід виглядає точнісінько як тихий квартал
Cost: Висока
What would change my mind: Шість місяців поспіль, коли жодна окрема сторона не перевищує 25% змерджених комітів

**R3 — Напівзбудована адмінка стає постійним третім станом** *(важко помітити)*
Три роки, версія 0.4, 19 комітів за 2026 рік на цей момент, обидві адмінки в кожній інсталяції — і архітектура активно ховає проблему. Редакція 24, від Core Team: адмінка жива, і темп свідомий — реальні магазини вже сьогодні працюють на ній, хоч вона й неповна, а робота «відновиться в темпі, щойно матимемо нового кандидата на місці» `[user]`. Це саме та відповідь, про яку [§22](#чого-я-не-зміг-встановити) казав, що вона зсуне цей ризик з високого до низького, — і вона зсуває, з одним застереженням: зниження тримається на заявленому намірі, а закриває ризик лише фальсифікатор. Наступна видаткова операція в бухгалтерії — ось спостережуване, яке підтвердить кандидата, і станом на 8 серпня 2026 воно не з'явилося — останній видаток у бухгалтерії досі за липень 2025 `[observed]`. На 25-й редакції намір здобув другу опору: «Адмінка — пріоритет», і модель із кандидатом свідома — незалежні розробники, оплачувані з колективу, поки фірма-мейнтейнер лишається на клієнтській роботі `[user]`. Заявлений намір стоїть; на перевірці 8 серпня, за п'ять днів після того, як він здобув другу опору, підтверджувальних свідчень так і не з'явилося.
If it happens: Головна поверхня оцінювання для нових користувачів лишається зламаною, а рахунок за підтримку подвоюється безстроково
Likelihood: Знижена на 24-й редакції — за версією Core Team темп свідомий; підтверджувальне спостережуване ще не спрацювало
Would you notice? Ні. Кожен сигнал, на який дивиться мейнтейнер, зелений
Cost: Висока і зростає в міру старіння старої адмінки
What would change my mind: Версія 1.0 стає типовою — або зафіксоване рішення скасувати її

**R4 — Spree забирає ринок нових проєктів** *(видно здалеку)*
Виміряно в [§09](#spree-виміряний). Зауважте: цей ризик стоїть нижче за [R1](#r1)–[R3](#r3) попри високий вплив — саме тому, що він гучний і публічний: проєкт побачить, як це відбувається. Чого я не можу встановити — чи мерчанти справді переходять: сукупні завантаження досі на користь Solidus, а темпи завантажень на реліз спотворені швидшою релізною каденцією Spree `[observed]`.

**R5 — Новий сторфронт ламає наявні розширення за задумом**
Його власний README каже, що розширення, які покладаються на старий сторфронт, «не працюватимуть із цим сторфронтом». Вплив середній, імовірність стовідсоткова — заявлена властивість, а не загроза `[observed]`.

> **ЯКЩО ВЗЯТИСЯ МОЖНА ЛИШЕ ЗА ТРИ**
> [R3](#r3), потім [R2](#r2), потім [R4](#r4). R3 — найбільше живе розбазарювання капіталу й уваги, і зсередини його не видно. R2 повільний і структурний, але саме цей механізм породив R3, тож залишити його — гарантувати повторення. R4 третій, бо хоч він дуже помітний — що зазвичай знижує пріоритет, — виміряний розрив уже такий великий, що помітність перестає бути великою розрадою.
> 
> [R1](#r1) вийшов із першої трійки. Раніше ранжування ставило його першим на підставі читання самого лише репозиторію; опублікована безпекова політика показує, що серйозні шляхи покриті, а лишається рутинний дрейф, вартий конфігураційного файла, а не кварталу уваги.
> 
> [R5](#r5) чекає, бо він відомий, обмежений і має очевидне пом'якшення — щойно комусь захочеться.

**Експозиція до ризиків**

```mermaid
quadrantChart
  x-axis Імовірність упродовж дванадцяти місяців --> Higher
  y-axis Вплив, якщо станеться --> Higher
  quadrant-1 Планувати й моніторити
  quadrant-2 Діяти зараз
  quadrant-3 Список спостереження
  quadrant-4 Запасний план
  R3: [0.9, 0.82]
  R2: [0.5, 0.75]
  R4: [0.5, 0.6]
  R5: [0.9, 0.44]
  R1: [0.5, 0.33]
```

## Журнал боргу

Не плутати з ризиками. Ризик *може* статися; борг — це вартість, яку вже платять, кожен-кожнісінький реліз. Ранжовано за вартістю на цикл, помноженою на кількість майбутніх циклів, які її платитимуть.

**D1 — Три незавершені переписування** *(strategic)*
Кожна зміна поведінки промоакцій, адмінки чи сторфронту проєктується двічі, пишеться двічі, тестується двічі й релізиться двічі. Запланованого кінця немає. Це найбільша регулярна вартість у проєкті — і її не видно на жодному з дашбордів проєкту, бо обидві половини зелені. [PL1](#pl1) і [PL4](#pl4) — постійні правила, які не дають журналу відростити четвертий запис такого роду.

**D2 — Врядування описує проєкт, якого більше не існує** *(organizational)*
Вхід до Core Team проходить через особисті повідомлення однієї людини; технічну владу призначено, але вона не має ні опублікованого майданчика, ні каденції, ні протоколу; жодне рішення не досягає публічного артефакту. Платиться в кожному оцінюванні потенційного користувача і в кожному контриб'юторі, який не може знайти двері.

**D3 — Архітектурні рішення ніколи не фіксуються** *(knowledge)*
Жодного документа з архітектури, жодних записів рішень, репозиторій роадмапу спить із травня 2023. Рішення живуть у щотижневому дзвінку та в Slack. Кожна міграція заново виводить контекст, якого ніхто ніколи не записував, — а правило [S3](#s3), яке керує всіма трьома, існує лише в головах людей.

**D4 — Агентський харнес і дві дрібні прогалини в автоматизації** *(technical)*
Головне тут — відсутній агентський харнес для ШІ. Поруч дві дрібні прогалини: автоматизація рутинних оновлень залежностей і крок аудиту в збірці — обидві вужчі, ніж здаються спершу, бо автоматичні безпекові оновлення вже працюють, а за ними стоїть повноцінна програма розкриття вразливостей ([§07](#машина)).За сьогоднішніми цінами, з допомогою агентів, усі три разом — це приблизно день роботи: репозиторій уже має Docker Compose, скрипт налаштування і тестовий цикл в одну команду, а це більша частина передумов. Будь-яке минуле рішення відкласти це ухвалювалося за доагентськими цінами і вже застаріло. Усі три тепер лежать у швидкій смузі як [E2](#e2), [E3](#e3) і [E4](#e4) — там вони більше не конкурують за увагу зі складними рішеннями.

## Журнал кредиту

Бік активів. Що збудовано такого, що окуповується кожен цикл, — і що було *заявлено* як інвестицію, але ще не окупилося. Інвестиція вважається справжньою лише тоді, коли щось її справді повторно використовує.

#### Підтверджено — повторне використання справді відбулося

**C1 — Тестова матриця, актуальна до найновіших Rails і Ruby**
Кожен pull request її ганяє; Rails 8.1 і Ruby 4.0 потрапили в матрицю за лічені тижні після своїх релізів.

**C2 — Гейт збірки на депрекаціях**
Саме це робить обіцянку апгрейдів правдоподібною, а не декларативною.

**C3 — Автоматизовані бекпорти**
П'ять підтримуваних релізних ліній тягнуться без ручної роботи.

**C4 — Автоматизований стиль коду**
Суперечки про стиль прибрано з кожного рев'ю, починаючи з v4.7.0.

**C5 — Автоматизація релізів і чейнджлогів**
Кожен реліз генерується з лейблів.

**C6 — Відтворюване середовище розробки**
Ним користується кожен контриб'ютор — і це вже більша частина агентського харнеса.

**C7 — Сторфронт**
64 файли спеків, які встановлюються в кожен згенерований магазин і які CI наскрізно проганяє на кожен push, — і типовий фронтенд генератора.

#### Прогнозовано — заявлено, ще не реалізовано

**C8 — solidus\_promotions** *(overdue)*
2 роки 2 місяці від початку. Бенефіціаром мала б бути типова інсталяція.

**C9 — solidus\_admin** *(past the point of write-off)*
3 роки 3 місяці від початку, досі версія 0.4.

> Сім підтверджених із дев'яти записаних — але два нереалізовані записи — це якраз дві найбільші продуктові інвестиції в журналі. Кожне покращення машини окупилося. Єдина продуктова ставка, що окупилася, зробила це, поглинувши готовий проєкт; обидві збудовані з нуля застрягли.

> **ЦЯ АСИМЕТРІЯ МАЄ ПОЯСНЕННЯ, І ВОНО — КЛЮЧ ДО ВСЬОГО ЗВІТУ**
> Волонтерське зусилля підтримує ті частини, які автоматизуються. Воно не підтримує ті, що потребують тривалої людської уваги.
> 
> Безперервна інтеграція, лінтинг, бекпорти й автоматизація релізів потребують уваги один раз, а далі працюють самі вічно. Добудувати адмінку, портувати 27 екранів, довезти сторфронт — тут треба, щоб хтось дбав чотири квартали поспіль. Модель Solidus працює саме там, де працює автоматизація, і падає саме там, де вона не працює.
> 
> Ось чому «спільнота його любить» цілком сумісне зі $133,750, яких ніхто не витрачає, і 78% фінансування від двох фірм. Любов породила відмінну машину — і жодного наступника.

## Кому Solidus ще може служити

З огляду на все сказане вище, чесне питання — не «як Solidus відновиться», а «хто лишився з тих, кому він справді може добре служити». Три аудиторії-кандидати, звірені зі свідченнями.

#### Новий мерчант, якому потрібен сторфронт швидко *(нежиттєздатно)*

Spree: `npx create-spree-app my-store` — або хостована пісочниця, де нічого не треба встановлювати. П'ять хвилин.

Solidus, за його ж власною документацією: створи Rails-застосунок, додай гем, руками напиши файл маніфесту асетів, запусти генератор і, можливо, руками збери CSS, бо «ця проблема зазвичай виникає, коли ви бандлите з гілки». А потім опинися в адмінці, яка не може відкрити замовлення `[observed]`.

**Нежиттєздатно без агенції** — що, втім, так було завжди. Solidus від народження опосередкований агенціями.

#### Соло-розробник, який любить класичний опенсорс *(найслабша з трьох)*

Спокусливо, але свідчення вказують у протилежний бік. Соло-розробник — це саме та людина, якій потрібні скафолдер, CLI, хостований тріал і робоча адмінка — точний список того, чого Solidus не має.

Ще вирішальніше: **найбільший контриб'ютор самого проєкту публічно відмовляється від цього сегмента.** *How to Fail at Solidus* Джареда Нормана (листопад 2024) стверджує, що Solidus пасує магазинам із великими обсягами, великим каталогам і маркетплейсам — *а не простим маленьким крамницям* `[web]`. Коли твій провідний мейнтейнер каже, що цей сегмент проєктові не пасує, — це не твій запасний варіант.

#### Усталений мерчант, що йде з платформи, яка бере комісію *(справжня аудиторія)*

Єдиний сегмент, де решта переваг Solidus вирішальні, а не сентиментальні:

- **BSD-3 без комерційної сутності, яка колись могла б змінити ліцензію.** Spree такого сказати не може — його Enterprise-модулі комерційні, а роадмап підзвітний інвесторам. Після Redis, HashiCorp і Terraform це жива тривога, а не теоретична.
- **Жодного JavaScript-ланцюга постачання, один рантайм.** Менше експлуатувати й менше аудитувати — назавжди.
- **Безпека оновлень зі справжніми зубами** — гейт у збірці й п'ять підтримуваних ліній релізів, а не обіцянка.

Портрет: середній сегмент ринку, глибока кастомізація, наявна або доступна для найму Rails-компетенція, довгий горизонт, **переїзд геть із чогось — і рішучість більше ніколи цього не повторювати.**

> Зверніть увагу, кого описує третій сегмент: мерчантів, які в Solidus уже є. Його досяжний ринок — люди, схожі на його теперішніх клієнтів. Це не стратегія зростання — це стратегія опіки, і саме вона чесна.

## Виберіть роль

Інстинктивне питання — «як Solidus відновиться?». На зібраних тут свідченнях це неправильне питання — проєкт не може профінансувати боротьбу за нових мерчантів. Правильне питання — яку роль він свідомо вибирає. Усі три нижче легітимні; дрейфувати між ними — ні.

> Висновок, який підтримують ці свідчення, — роль, а не камбек: комерційний фреймворк, яким ви ще володітимете через десять років і який служить мерчантам, що його вже вибрали.

#### Role A — доглядати встановлену базу

Оголосіть це відкрито: жодних нових ініціатив. Гарантуйте безпеку оновлень, патчі безпеки й підтримку актуальних Rails/Ruby. Завершіть міграцію промоакцій, бо вона майже готова. **Скасуйте нову адмінку й новий сторфронт.**

*За:* чесно, відповідає бюджету $25k на рік, монетизує єдину справжню перевагу й одразу списує найбільшу повторювану витрату з Журналу боргу. *Проти:* це явне прийняття керованого занепаду, і частина контриб'юторів через це піде.

#### Role B — боротися за агентський канал

Єдине місце, де малий бюджет ще може купити асиметрію. Rails-фреймворк з одним рантаймом справді простіший для роботи AI-агента, ніж монорепо Rails-плюс-Next.js-плюс-TypeScript: один граф залежностей, одна команда тестів, жодного перемикання контексту через мовний кордон. Ціна — харнес, а не переписування.

Аргумент другого порядку, який варто назвати, бо він б'є по очевидному запереченню: *компетентність* агента корелює з тим, скільки стека є в тренувальних даних, — а це на користь React і Next.js. Але *надійність* агента корелює зі щільністю конвенцій — тим, як мало обґрунтованих способів зробити конкретну річ, — а Rails із Turbo і Stimulus куди категоричніший у своїх конвенціях, ніж React. **Розмір корпусу на користь Spree; щільність конвенцій на користь Solidus.** Ці чинники значною мірою гасять один одного.

*Пітч:* «Одна кодова база, одна мова, одна команда тестів, жодного JavaScript-ланцюга постачання для аудиту. Ваш агент працює в Rails, а не через кордон монорепо». Spree структурно не може такого сказати — уся їхня стратегія 5.x — це протилежна ставка.

**Два харнеси, а не один.** Проєкту потрібен один для власних контриб'юторів — ця половина тепер пункт швидкої смуги, [E4](#e4), бо коштує близько дня. Цінніша половина — та, якої *будівники магазинів* потребують для своїх застосунків. Solidus уже серйозно інвестує в інструменти для тих, хто на ньому будує: `solidus_dev_support`, опублікований GitHub Action для тестування розширень, edge-гайди. Власна порада Джареда Нормана — «спирайся на платформу… Solidus іде з чудовою підтримкою тестування, CI, CD». **Агентський харнес — це член цієї самої родини зразка 2026 року, і саме його бракує в наборі, у який проєкт уже вірить.** Половина для будівників магазинів чекає на судження про вибір ролі — тому вона й лишається поза швидкою смугою.

Spree вже відвантажив половину для будівників магазинів — скіли, що встановлюються однією командою й націлені на Claude Code, Cursor і Copilot. Асиметрія, на яку Solidus ще може претендувати, — не першість, а те, що Rails-магазин з одним рантаймом — менша й чистіша річ для міркувань агента, ніж монорепо Rails-плюс-Next.js.

#### Role C — зійтися зі Spree

Неприємно — і саме тому стратегічний документ мусить це назвати. Засадниче виправдання форку — що Spree покинули — померло, коли Spree повернувся. Обидва BSD-3. В одного з них є фінансування й підтримувана адмінка.

Ніхто всередині проєкту цього не запропонує. Та це не причина лишати варіант незаписаним.

**Три ролі поряд**

| Роль | Хід | Заковика |
| --- | --- | --- |
| A — доглядати встановлену базу | Жодних нових ініціатив; гарантувати оновлення й безпеку; завершити промоакції; скасувати адмінку й сторфронт | Явне прийняття керованого занепаду — частина контриб'юторів піде |
| B — боротися за агентський канал | Відвантажити відсутній агентський харнес; продавати «один рантайм, одна команда тестів» будівникам, що працюють через агентів | Spree відвантажив свій першим — модифікатор до Role A, а не альтернатива |
| C — зійтися зі Spree | Влитися назад у проєкт, від якого Solidus відгалузився | Ніхто всередині цього не запропонує — саме тому це мусить бути записано |

> **РЕД-ТИМІНГ ROLE B, БО САМЕ ВОНА СПОКУСЛИВА**
> Spree вже опублікував агентські скіли й MCP-сервер документації. Прийти до харнеса другим із двадцятою часткою грошей — не очевидно виграшна позиція, і обізнаність агента з React може побити легкість, з якою агент орієнтується в Rails. Асиметрія тонша, ніж здається на перший погляд.
> 
> Це залишається найдешевшою ставкою на дошці — але це диференціатор, а не порятунок. [Role B](#role-b) — модифікатор до [Role A](#role-a), а не альтернатива їй.

### Позиціонування, якщо вибрано Role A або A+B

Теперішній публічний слоган — *«Безплатна опенсорсна e-commerce платформа, що дає вам повний контроль над вашим магазином»*. Половина про «повний контроль» — сильніше твердження у 2026-му, ніж було у 2015-му. Половина про «платформу» наразі не заслужена — платформа, чия адмінка не може відкрити замовлення, — це будмайданчик, до якого прикріпили обіцянку.

Комерційний фреймворк, яким ви ще володітимете через десять років.

Це обіцянка опіки, а не обіцянка фіч, — і це єдине твердження в усьому цьому порівнянні, якого Spree структурно не може зробити, а Shopify ніколи не захотів би.

## Легкі перемоги

Швидка смуга, нова у 26-й редакції. Ці пункти проходять три гейти — близько дня роботи з допомогою агента або менше, делеговні й оборотні, і кожен безпосередньо живить машину доставлення, — тож вони біжать *поруч* зі стратегією, а не всередині неї. Вони ніколи не займають місця в остаточному відборі, і суперечка про складні ставки нижче ніколи на них не посилається. Дві колишні ставки переїхали сюди: B3 стала [E2](#e2) і [E3](#e3); внутрішньорепозиторійна половина B4 стала [E4](#e4). Пункт, який не вкладається у свій день або виявляється таким, що потребує судження, викидається назад до таблиці ставок — із назвою того, що саме опиралося.

| # | Виграш | Живить машину | Агент-день | Статус |
| --- | --- | --- | --- | --- |
| E1 | Проставити в [#5391](https://github.com/solidusio/solidus/issues/5391) галочки за тим, що код показує вже зробленим, — Settings > Zones уже давно має повний CRUD. Чекліст, який ніхто не оновлює, каже, що робота зупинилася; той самий чекліст в актуальному стані каже, що ні. Повторно підтверджено: галочки досі не проставлені станом на 8 серпня 2026 `[observed]`. | знання | хвилини | — |
| E2 | Конфіг Renovate або Dependabot для рутинних підвищень версій. Оновлення безпеки вже працюють; це закриває розрив дрейфу, який тримає [R1](#r1) в реєстрі. (Колишня ставка B3.) | гігієна залежностей | година | — |
| E3 | Джоб bundler-audit у CI, щоб версії залежностей із відомими вразливостями валили збірку, а не чекали, поки хтось подивиться. | статичні гейти | година | — |
| E4 | AGENTS.md/CLAUDE.md плюс закомічені дозволи агента — поверх Docker Compose-сетапу, bin/setup і тестової петлі в одну команду, які вже існують: більшість харнеса вже на місці. Перші завдання: виконати [E2](#e2) і [B5](#b5). (Колишня внутрішньорепозиторійна половина ставки B4; половина для будівників магазинів чекає на судження про Role B і лишається серед ставок.) | агентський харнес | ~день | — |
| E5 | Переопублікувати заяву стратегії — чотири стовпи, які провідний мейнтейнер уже написав у травні 2026, — у власному README проєкту або документі врядування, щоб [S1](#s1) перестала жити в маркетинговому блозі однієї консалтингової фірми. Заразом це найдешевший перший акт [PL3](#pl3). | знання | година | — |

## Ставки — вирішувати вам

Оцінено з розрахунку на [Role A](#role-a)+B, бо саме туди вказують свідчення. Свідомо залишено як стартову позицію, а не готовий план — вибір ролі в [§16](#виберіть-роль) — це судження, і ці ставки слід переоцінити відповідно до тієї ролі, яку буде фактично вибрано. Тривіальні пункти зникли з цієї таблиці навмисно: тепер вони живуть у [§17](#легкі-перемоги), тож тут лишилися тільки рішення, що потребують судження власника.

| # | Ставка | Вердикт | Що закриває | Ціна |
| --- | --- | --- | --- | --- |
| B2 | Перезапустити фінансовану розробку — купуючи результат, а не спринти | Do | [R3](#r3), [D1](#d1) | один пункт порядку денного наради |
| B5 | Назвати реліз, що прибирає легасі-промоакції — заява про політику, а не праця; перше застосування [PL1](#pl1) | Do | [D1](#d1), [RC1](#rc1) | безплатно |
| B6 | Вирішити долю адмінки — виготовивши свідчення, а не розмірковуючи без них | Decide | [R3](#r3), [D1](#d1) | один складний екран |
| B7 | Наздогнати React-сторфронт Spree | Kill | [R4](#r4) | — |
| B8 | GraphQL / headless-поверхня | Wait | [R4](#r4) | — |
| B9 | Подвійна підтримка асет-пайплайнів, з міграцією, яку виконує агент | Do | суміжне з [R1](#r1), [D3](#d3), [D4](#d4), онбординг | див. шаблон |
| B10 | Публікувати технічні рішення — перезапустити статусні пости, заводити перспективні пункти роадмапу; одноразовий акт, що стоїть за [PL3](#pl3) | Do | [D2](#d2), [D3](#d3), [S1](#s1), [R4](#r4) | година на місяць |

> **B10 — НАЙДЕШЕВША СТАВКА НА ДОШЦІ**
> Core Team уже тримає технічну владу. Група стейкхолдерів уже збирається щотижня. Проєкт уже володіє двома каналами, створеними саме для того, щоб нести публічний напрям, — дошкою роадмапу і блогом. Нічого не треба створювати; дві приспані речі треба перезапустити. Блог навіть ворухнувся сам: один анонс релізу в травні 2026 — і знову тиша `[web]`.
> 
> Що це лагодить: потенційний користувач, який оцінює Solidus сьогодні, знаходить роадмап із самої лише завершеної роботи й блог, що озивається раз чи два на рік, — і не може зрозуміти, чи має платформа майбутнє. Це не проблема врядування — рішення цілком можуть ухвалюватися. Це проблема публікації, і вона коштує годину на місяць.
> 
> Це також дешево закриває знахідку [S1](#s1). Найчіткіша заява стратегії проєкту нині живе в маркетинговому блозі однієї консалтингової фірми; ті самі слова у блозі самого проєкту роблять її позицією проєкту, а не думкою однієї фірми.
> 
> Робити це так: короткий щомісячний пост, що називає ухвалені й відкладені рішення, плюс перспективні пункти на дошці роадмапу — де їх зараз три, і одного з них ніхто не торкався з травня 2025. П'ятихвилинний старт — [E1](#e1).

### Шаблон рішення — B9, подвійна підтримка асет-пайплайнів

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

**Рішення**

**Підтримувати обидва асет-пайплайни в Solidus.** Нові інсталяції за замовчуванням отримують Propshaft і можуть відмовитися на користь Sprockets. Наявні магазини лишаються на Sprockets і переходять на Propshaft, коли будуть готові. Відвантажити **агентський скіл, що виконує міграцію** на магазині клієнта й верифікує її, завантаживши застосунок і прогнавши набір тестів.

**Контекст**

Rails 8 за замовчуванням іде з Propshaft. Ядро Solidus жорстко вимагає Sprockets, чий супровідний гем не мав релізу з липня 2024, а релевантний фікс лишається незмердженим уже 18 місяців. Цей пін — задокументована причина класу багів із найдовшою історією в проєкті, і CI зараз лишається зеленим лише завдяки незадокументованому обхідному кроку ([§07](#машина)).

**Чому саме така форма**

Вона збігається зі стратегією, що вже діє. Правило [S2](#s2) забороняє ламати наявні магазини; правило [S3](#s3) відвантажує заміни як опційні поруч із чинним. Це патерн промоакцій, застосований до асет-пайплайна, — **ставка, що не суперечить жодній чинній стратегії, а отже не зустріне неназваного опору.**

**Альтернативи**

**(а) Чекати на апстрім** — недоступно; фікс не змерджено в приспаному гемі. **(б) Жорсткий перехід на Propshaft** — порушує [S2](#s2) і ламає налаштування асетів кожного наявного магазину. **(в) Лишитися на Sprockets** — статус-кво; коштує твердження про актуальність Rails, шляху онбордингу і зрештою змушує до аварійної міграції, коли Rails зніме підтримку. **(г) Мігрувати лише тоді, коли приземлиться нова адмінка** — прив'язує це до єдиного рішення, що вже три роки опирається розв'язанню.

**Гейт, і як його пройти**

Стара адмінка несе 151 директиву Sprockets і в написаному вигляді не може працювати на Propshaft, тож дефолт Propshaft для нових інсталяцій, здавалося б, залежить від її виведення. **Обхід: один раз прекомпілювати заморожені асети старої адмінки й відвантажити їх статичними файлами.** Propshaft чудово роздає статичні асети. Це повністю розчіплює [B9](#b9) і питання адмінки та перевикористовує патерн, що приніс успіх сторфронту.

**Зменшені ризики**

Закриває клас відмов за issue [#6327](https://github.com/solidusio/solidus/issues/6327), [#5410](https://github.com/solidusio/solidus/issues/5410) і [#6516](https://github.com/solidusio/solidus/issues/6516). Прибирає залежність від непідтримуваного гема з платіжного фреймворку. Кладе край розбіжності між тестованим шляхом встановлення й задокументованим. Закриває розрив поколінь Rails у [§07](#машина).

**Внесені ризики**

**Серйозний: четвертий тягар подвійної підтримки** в проєкті, чия найбільша повторювана витрата ([D1](#d1)) — і без того плата за все двічі. Обидва пайплайни потребують покриття в CI, що подвоює ту матрицю. Другорядне: прекомпільовані асети адмінки стають артефактом збірки, який хтось мусить не забути перегенерувати, якщо легасі-адмінки хтось колись торкнеться.

**Умова, що робить це прийнятним**

**Це відвантажується з датою депрекації — або не відвантажується взагалі.** Першопричина [RC1](#rc1) у тому, що цей проєкт добре проєктує міграції й ніколи не планує їх у часі. Назвіть мажорну версію, що прибирає підтримку Sprockets, покладіть це в README гема поруч із гайдом міграції промоакцій і додайте на дошку роадмапу як перспективний пункт. Це [PL1](#pl1), застосоване від народження, а не заднім числом.

**Ціна**

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

**Вироблений кредит**

**Перевикористовуваний актив — агентський скіл, а не зміна пайплайна.** Його перше назване перевикористання — міграція промоакцій, яка вже два роки має чудовий гайд на 190 рядків і зрушила приблизно нікого. Гайд — дорадчий; скіл — виконуваний. Якщо форма скілу спрацює тут, це механізм доставки для кожної майбутньої опційної міграції, яку цей проєкт відвантажить.

**Уточнення**

Найвужчий корисний зріз: агентський скіл мігрує один еталонний магазин на Propshaft і доводить це, завантаживши застосунок і прогнавши згенерований набір тестів, — до будь-яких змін дефолтів. Понад це розгортання не потребує окремого формального тесту, бо зміна опційна й оборотна: сам період опційності і є тестом суворішої майбутньої версії — перемкнутого дефолту. Якщо скіл не може чисто змігрувати еталонний магазин, ставка на цьому зупиняється, коштувавши роботи обсягом в один магазин.

**Хто приймає**

Core Team — за нею явне останнє слово щодо того, що йде в ядро. Повноваження недвозначні; невизначено інше — коли вони з цього приводу збираються й де записується рішення ([§06](#люди)), — тож цю ставку слід прийняти в публічно видимому місці, що само по собі і є суттю [PL3](#pl3).

**Хто виконує**

Детерміністична перевірка — найсильніший вид забезпечення, попереду писаних норм і нагадувань: CI проганяє задокументований шлях встановлення, з випущених гемів, на обох пайплайнах. Дрейф документації тоді валить збірку, а не доходить до користувача.

**Критерії успіху — контрольовані**

Подвійну підтримку змерджено · нові інсталяції за замовчуванням на Propshaft · обхід `manifest.js` видалено і з CI, і з доків · [#6516](https://github.com/solidusio/solidus/issues/6516) закрито · агентський скіл мігрує еталонний магазин до зеленого · версію депрекації названо письмово.

**Сигнали, про які звітувати, але якими не гейтити**

Скільки наявних магазинів фактично мігрує. Це залежить від їхнього апетиту, а не від виконання з боку проєкту.

**Стратегія виходу**

Якщо подвійна підтримка виявиться занадто дорогою в утриманні, запасний варіант — лише Sprockets плюс задокументований, асистований агентом аварійний вихід для магазинів, що хочуть Propshaft, — втрачаємо дефолт, але зберігаємо шлях міграції.

**Фальсифікатор**

Скіл відвантажено, а через дванадцять місяців мігровані магазини — така сама рідкість, як сьогодні міграції промоакцій. Це довело б, що обмеженням ніколи не була *складність* міграції — нею була відсутність *причини* мігрувати, — що поставило б під питання всю тезу «тримати перевагу Rails-way», а не інструменти.

**Дата перегляду**

2027-01-25, або перший мажорний реліз після мерджу — що настане раніше.

> **РЕД-ТИМ B9**
> Чесний аргумент проти: це ставка на досвід розробника у звіті, який дійшов висновку, що життєздатна аудиторія — наявні мерчанти, які онбордилися роки тому ([§15](#кому-solidus-ще-може-служити)). Цим мерчантам байдуже, який асет-пайплайн використовує їхня агенція.
> 
> Аргумент виживає, але на вужчих підставах, ніж «онбординг». Його справжня цінність — прибрати непідтримувану залежність із платіжного фреймворку, відновити цілісність твердження про актуальність Rails, на якому стоїть позиціонування з [§16](#виберіть-роль), і довести механізм доставки через агентський скіл на малій, верифіковній міграції, перш ніж ставити на нього перехід промоакцій. Як аргумент про онбординг це приємний бонус. Як зняття ризику мертвої залежності й репетиція механізму доставки — найсильніший пункт цієї таблиці.

### B6 — як зробити рішення, якому три роки, розв'язним

«Фінансуйте або скасуйте» — судження, якого ніхто не зміг ухвалити, і питати знову не допоможе. Вихід — прогнати найдешевший можливий крок, що виробляє відсутні свідчення, — який заразом, не випадково, є першою фазою стандартного плейбука міграцій, яку проєкт пропустив. У термінах фреймворку B6 і *є* зрізом-уточненням для адмінки: найвужчий, найглибший тест, що каже, чи працює механіка стратегії, перш ніж хтось зобов'яжеться до розгортання.

#### Step 1 — зняти ризик — портувати найскладніший екран першим, руками

**Не Zones. Процес повернень і відшкодувань — або варіанти й ціни.** Саме там живе складність домену, і це єдине місце, що відповідає на питання, на яке три роки сторінок налаштувань не відповіли: *чи здатна ця архітектура взагалі виразити складні екрани?*

Це крок, який Ларсон ставить першим, а Solidus поставив останнім. У руках досвідченого інженера він коштує один екран і закриває все питання фінансування — бо якщо патерни ViewComponent і Turbo чисто справляються з процесом повернень, решта механічна; а якщо ні, жодне фінансування цього не виправить, і правильна відповідь — запаркувати адмінку.

**Заплатіть за це.** Це не волонтерська робота, і вона не має чекати на чиїсь вечори — це найцінніше інженерне питання в проєкті, а колектив тримає $133,750, які вже чотири рази купували саме такий тип роботи ([§04](#гроші)). Один профінансований екран — найдешевше можливе використання цього балансу, і, на відміну від раунду 2023-го, він купує *відповідь*, а не кількість спринтів.

#### Step 2 — увімкнути — закодувати патерн як агентський скіл

Позиція Solidus тут напрочуд вигідна. **132 наявні компоненти вже задають домашній стиль**, а п'ять осиротілих чернеткових pull request-ів — робочі приклади саме того патерну добудови CRUD, якого скіл мав би навчитися ([§08](#розтин-адмінки)). Навчальний матеріал написано; ніхто його не зібрав.

**Є й доведений ручний прецедент для автоматизації.** Контриб'ютор підхопив один застряглий PR адмінки, погодив підхід, якому віддавав перевагу рев'юер, і доставив перебудову свіжим pull request-ом 30 липня 2026 ([§08](#розтин-адмінки)). Це точно та сама петля — підняти осиротілу роботу, привести її до домашнього стилю, приземлити, — повторена ще п'ять разів. Спільнота продемонструвала процес руками; скіл робить його повторюваним.

Тут же машинерія агентського скілу з [B9](#b9) окупається вдруге — той самий механізм доставки, застосований до другої міграції.

#### Step 3 — масово змігрувати механічну смугу

\~15 простих екранів — локалі, теми, API-ключі, налаштування, зображення, властивості — плюс create/edit на шести контролерах, що мають лише списки. Це клас «делеговане, паралелізовне, добре специфіковане», який фреймворк оцінює в **астрономічному часі агента під фан-аутом, а не в днях розробника**. Доагентні оцінки цієї смуги застарілі приблизно на порядок.

#### Step 4 — завершити — закутки й шпарини

Руками добити залишок, проставляти галочки [#5391](https://github.com/solidusio/solidus/issues/5391) у міру приземлення, перемкнути альфа-прапорець, щойно замовлення й продукти буде визнано готовими, і трактувати видалення залежності `solidus_backend` як окремий наступний проєкт.

> **ЩО РОБИТЬ ЦЮ ФОРМУ ПРАВИЛЬНОЮ**
> Це перетворює рішення, якого ніхто не може ухвалити, на експеримент, який може прогнати будь-хто. Один складний екран каже вам, чим є решта перенесення — кількома агентськими тижнями чи переписуванням, замаскованим під перенесення. Обидві відповіді придатні до дії; теперішній стан — три роки незнання — єдиний результат, що ні.
> 
> Фальсифікатор усього плану: крок 1 зроблено, і процес повернень не виражається чисто в патернах нової адмінки. Це означало б, що справжнє обмеження — архітектура, а не фінансування чи власність, — і правильною реакцією стає скасування адмінки, а не її ресурсування. Такий результат вартий $45,760 заднього розуму й одного екрана передбачення.

### Аргумент послідовності

[B6](#b6) і [B10](#b10) — судження, що майже нічого не коштують і розблоковують усе, що нижче за течією. Жодні інструменти їх не замінять, і AI-асистування їх не стискає — це рішення, а не задачі. Усе після них — делеговна робота, чиї доагентні оцінки вартості застарілі на порядок, а справді тривіальні пункти вже повністю винесено із самої суперечки — до [§17](#легкі-перемоги).

**Поставити рішення першими, а задачі другими — у цьому вся суть.** План, чиї віхи — завершення задач, приховав би факт, що цей проєкт застрягає на рішеннях, а не на коді.

> **B2, СФОРМУЛЬОВАНА ТОЧНО**
> Це не «проголосувати, щоб витратити невикористаний баланс». Механізм фінансування добре обкатаний — 67 витрат, $154,612 і $45,760, націлені на саме цю проблему у 2023-му.
> 
> Ставка не про те, чи витрачати, а про те, як оформити покупку. Профінансувати названу міграцію до статусу дефолтної — не спринти, не години, не фази дизайну. Назвати власника, який залишиться після того, як гроші скінчаться. Поставити цільовий реліз. [PL2](#pl2) — це та сама ставка, узагальнена до постійного правила.
> 
> І зауважте: фальсифікатор уже наполовину справдився: гроші виділили у 2023-му, а міграція все одно не відвантажилася. Що самих грошей тут не досить — уже доведено. Неперевіреним лишається одне: гроші, прив'язані до критерію завершення. Якщо другий, оформлений під результат раунд теж провалиться, обмеження — це увага і повноваження, а не фінансування, — і правильною відповіддю стає скасувати адмінку, а не фінансувати її.

### Послідовність

|  | Зараз — тижні | Наступний квартал | Горизонт 2 |
| --- | --- | --- | --- |
| **Ставки** | B6 · портувати один складний екран адмінки · B10 · знову публікувати рішення | E1–E5 · спорожнити швидку смугу · PL1–PL5 · прийняти, змінити або відхилити реєстр | B5 · назвати реліз, що прибирає легасі-промоакції · Role A або A+B оголошено публічно |

> Ходи одним рядком: жоден із перших кроків не дорогий — публікуйте рішення, які ухвалюєте, назвіть реліз, що прибирає легасі-промоакції, і фінансуйте результати, а не спринти.

## Пре-мортем

Не як провалюється *система* — як провалюється цей *план*. Уявіть, що минув рік, і нічого не змінилося. Чому?

**P1 — Складний екран відкладають заради легкого** *(найімовірніше)*
Крок 1 у [B6](#b6) просить когось досвідченого витратити реальний час на процес повернень без жодної гарантії результату, який можна відвантажити. Шлях найменшого опору — натомість портувати ще одну сторінку налаштувань; а це саме те рішення, яке породило нинішню ситуацію, і воно знову скидатиметься на прогрес.
Early warning: Перший узятий у роботу екран — той, що вже є в чеклісті #5391
Mitigation: Назвіть екран до старту, публічно, і трактуйте «ми дізналися, що це не працює» як успішний результат, а не провалений спринт

**P2 — Ніхто не ставить рішення про фінансування на порядок денний**
Запропонувати це означає покритикувати статус-кво людей, яких бачиш щотижня.
Early warning: Дві зустрічі стейкхолдерів минають без цього пункту в порядку денному
Mitigation: Розішліть це як односторінковий бюлетень із кількома варіантами щодо трьох міграцій — його легше винести на розгляд, ніж суперечку

**P3 — Харнес збудовано, але ним ніхто не користується**
Право мерджити належить невеликій групі з усталеними робочими процесами. Харнес, який ніхто не впроваджує, — це похибка округлення, що скидається на прогрес.
Early warning: Жоден pull request не посилається на нього впродовж двох релізних циклів
Mitigation: Звузьте його до E2 і B5. Якщо вони приземляться, він окупився незалежно від ширшого впровадження

**P4 — Профінансовану міграцію обирають гроші, а не готовність**
Голосування, зважене за внесками, може обрати адмінку — найбільшу, найбільш застряглу, найдорожчу — замість промоакцій, де залишковий розрив найменший, а тестове покриття повне.
Early warning: Бюлетень з одним варіантом вибору
Mitigation: Кілька варіантів, що дають ранжований список

**P5 — Діагноз хибний, і обмеження — увага, а не гроші** *(частково вже спостережено)*
Цей сценарій не гіпотетичний: $45,760 виділили 2023 року, а адмінка через три роки досі не стала типовою. Експеримент запустили один раз, і він провалився.Виживає вужче твердження: гроші без критерію завершення тут міграцію не відвантажують. Гроші з ним — не перевірені.
Early warning: Другий раунд фінансування, оформлений під результат, теж нічого не відвантажує
Mitigation: Якщо гроші, привʼязані до критерію завершення, теж провалюються — скасуйте адмінку

> **І ОДИН ДЛЯ НОВОГО ШАРУ: РЕЄСТР ВВІЧЛИВО КЛАДУТЬ У ШУХЛЯДУ**
> Реєстр політик — та частина цього звіту, якій найімовірніше судилося померти від ввічливості. П'ять запропонованих правил, що приходять іззовні, жодне не термінове в будь-який окремий день, за кожне легко подякувати — і відкласти — та сама динаміка, що й у [P2](#p2), тільки застосована до паперу замість грошей. Ранній сигнал: минають два квартали, і жоден рядок PL не був прийнятий, змінений чи відхилений. Пом'якшення вбудоване в самі рядки: кожен достатньо малий, щоб вирішити за одну зустріч, а [PL4](#pl4) можна випробувати раз, нічого не приймаючи, — проведіть один прохід вердиктів і подивіться, чи був він вартий пункту в порядку денному.

## Журнал рішень

Що цей звіт вирішив і — що корисніше — де він помилився та виправився. Закреслені записи скасовані пізнішими свідченнями.

**01 · standing**
Трактувати це як аудит наявної системи з глибиною одного рішення в питанні адмінки. (Прийнято)

**02 · superseded**
~~Почати з інженерії агентського харнеса на тій підставі, що свідомої стратегії не існує.~~
Свідома стратегія існує: сумісність, право мерджити та якість, яку забезпечує машина, — усе це реальні, чинні правила. Харнес поставлено нижче двох суджень і переокреслено як їхнього виконавця

**03 · withdrawn**
~~Заявити «відсутність безпекової політики у платіжного фреймворку» як ризик.~~
Політика існує на рівні організації; вона знайшлася, щойно пошук розширили

**04 · standing**
Записати розбіжність між врядуванням і реальністю як борг, а не ризик. (Прийнято — це вже правда, тож це ціна, яку платять, а не подія, що може статися)

**05 · superseded**
~~Подати баланс $132,180 як капітал, який нема механізму витратити.~~
67 витрат на загальну суму $154,612 кажуть, що механізм працює і вже був націлений на цю проблему. Ставка стала «оформити покупку», а не «зробити покупку»

**06 · superseded**
~~Цитувати «річний бюджет $26,322» і «зібрано $287,359» з відрендереної сторінки пожертв.~~
Виправлено за API: отримано $329,677, витрачено $154,612, а цифра «бюджету» — просто дохід за останні дванадцять місяців

**07 · superseded**
~~Застрягла адмінна робота 2025 року завершена й заблокована на рев'ю; вузьке місце — спроможність рев'юерів.~~
Хибно. Шість із семи pull request-ів — чернетки, які ніколи не подавали на рев'ю, і всі, крім одного, мають конфлікти. Вузьке місце — авторство. Діагноз змістився з «немає майданчика» на «люди пішли»

**08 · superseded**
~~Заявити нову адмінку як «завершену на 64% за кількістю контролерів».~~
Оманливо: редагування замовлень і товарів вимкнене, шість контролерів — лише списки, а 27 відсутніх екранів — це ядро щоденних операцій

**09 · superseded**
~~Описати Solidus як такий, що платить ціну багатомовності, посилаючись на 246 файлів JavaScript.~~
Хибна міра. Немає ні package.json, ні lock-файлу, ні npm-графа. jQuery і Hotwire — це рідний для Rails стиль, а не другий рантайм. Перевага єдиного рантайму реальна й тепер несуча в [§16](#виберіть-роль)

**10 · superseded**
~~«Понад тридцять спонсорів скасували підтримку, тож базова частота не гіпотетична».~~
Підрахунок правильний, висновок хибний: це читається як нещодавній масовий вихід. Насправді це шість років рівномірного відтоку, а 2024 і 2026 — найнижчі роки за всю історію

**11 · standing**
Відкинути теорію, що спонсорство Nebulab було грою за право голосу. (Два головні спонсори йдуть нарівні під стелею, якої жоден не вичерпав, голоси не дають влади над кодом, а економіка йде в мінус на $44k. Маркетингова позиція — краще пояснення)

**12 · standing**
Відмовитися характеризувати платежі Nebulab як викачування. (Чистий внесок — +$44,331, дві заявки на витрати відхилено, а платежі переглядає незалежний хост. Обґрунтована знахідка — інсайдерський платіж без критерію завершення)

**13 · standing**
Відкинути «занепад спричинив Spree». (Скасування йдуть рівно з 2019 року, без сплеску після перезапуску. Це підсилює рішення вбити [B7](#b7) — наздоганяти конкурента, який цього не спричинив, — програшний хід)

**14 · standing**
Відмовитися стверджувати, що нові мерчанти обирають Spree замість Solidus. (Цього не виміряти з публічних даних. Розрив у можливостях доведено; твердження про вибір — ні)

**15 · standing**
Переформатувати звіт із «як відновитися» на «виберіть роль». (Прийнято — свідчення не підтримують тезу про відновлення, і подати її було б відповіддю зручнішою, а не правдивою)

**16 · superseded**
~~«Три незавершені переписування» як системний патерн, що породжує першопричину RC1.~~
Надмірне узагальнення з одного випадку. Промоакції мають 190-рядковий гайд міграції та пораду мігрувати вже; сторфронт успішно поглинули за шість тижнів. Застрягла лише адмінка. [RC1](#rc1) звужено з «немає воріт завершення» до «немає календаря»

**17 · superseded**
~~Вважати технічний напрям проєкту незаписаним і вивести його.~~
Він записаний: провідний мейнтейнер опублікував його 12 травня 2026. Цей звіт незалежно реконструював майже ту саму позицію, що підтверджує аналіз і понижує знахідку. Справжній борг — те, що стратегія живе в блозі консалтингу, а не у власних артефактах проєкту

**18 · withdrawn**
~~Узагалі трактувати опис ролі Nebulab у документі про врядування як знахідку (рядок стратегії про врядувальний титул, його ставку та його запис у пре-мортемі).~~
Вектор прибрано повністю. «Директор» охоплює бізнесовий та організаційний напрям, якого цей аудит не бачить; виводити будь-що про врядування з кількості комітів було хлипко й недоброзичливо. Nebulab цілком може лишатися головною керівною фігурою проєкту незалежно від того, хто пише код. Знахідка про інженерну передачу ([RC2](#rc2), [F2](#f2)) стоїть на власних свідченнях і не зачеплена

**19 · superseded**
~~Прочитати 40 відкритих pull request-ів як свідчення занедбаного рев'ю.~~
Частково зовнішнє. Дошка вакансій давала кандидатам issues Solidus як відбіркове завдання; мейнтейнер це діагностував і втрутився, щоб зупинити це біля джерела — на самій дошці вакансій. Це активна опіка, а не занепад

**35 · superseded**
~~RC1: «ворота збудовано; ніхто не відповідає за їх закриття, і жоден календар не каже коли».~~
Хибний рецепт для цього режиму. Робота без власника й без дати — нормальний стан волонтерського відкритого коду: нікому не можна призначити дедлайн, за дотримання якого йому не платять. Розділено надвоє: промоакціям потрібна лише заява про політику (назвати реліз, що прибирає легасі-движок, — безкоштовно, і робота вже зроблена), а адмінці потрібна оплачена спроможність, і волонтерськими зусиллями вона ніколи б не приїхала. Переформульовано як: непрофінансована ініціатива поруч із невитраченим бюджетом. [B5](#b5) переокреслено з «зробити типовими» на «назвати реліз вилучення»

**34 · superseded**
~~Усі сім застряглих адмінних PR-ів охарактеризовано з метаданих API: «автор так і не повернувся», «рев'юери долучалися всюди, де їх просили».~~
Метадані вводили в оману; треди кажуть більше. П'ять чернеток chaimann не мають жодної рев'ю-активності взагалі. [#6232](https://github.com/solidusio/solidus/pull/6232) — від іншого автора, і його рев'ю провели як слід. А [#6295](https://github.com/solidusio/solidus/pull/6295) підхопив інший контриб'ютор 2026-06-30 — за три тижні до цього аудиту, — і мейнтейнер поступився в суперечці про дизайн замість блокувати. «Покинуті» — перебільшення: рятувальний механізм проєкту працює і спрацював раз, але не системно. Також: позначки «оновлено сьогодні» на двох чернетках — це переобчислення базової гілки, а не людська активність. І бот-рев'юер Copilot уже стоїть на шляху рев'ю

**33 · superseded**
~~«Диференційоване володіння кодом ✗ — CODEOWNERS — один рядок на все».~~
Хибно двічі. Файл існує і працює, тож позначати його відсутнім було неправильно; та й гранулярне володіння тут було б хибним дизайном: коли три сторони пишуть 83% коду, а відхід людей — визначальний режим відмови, називання персональних власників перетворює кожен вихід на застряглу чергу. Рядок на все — правдоподібно, саме той механізм, що стоїть за обов'язковими рев'ю Core Team з політики. Пункт потрапив до списку, бо CODEOWNERS стоїть у постійному чеклісті, а не тому, що свідчення вказували на проблему. Принагідно розв'язано: шаблони pull request-ів та issues існують, успадковані від організації, — це закриває відкритий пункт [§22](#чого-я-не-зміг-встановити)

**32 · standing**
Продіагностувати послідовність робіт над адмінкою за міграційним плейбуком Ларсона й переписати [B6](#b6) як експеримент. (Плейбук — Derisk → Enable → Finish, і він попереджає, що старт із легких випадків «створює оманливе відчуття прогресу». Issue [#5391](https://github.com/solidusio/solidus/issues/5391) дослівно формулює обернену стратегію («беріться спершу за легкі сторінки»), і передбачений провал — саме той, який ми й бачимо: напівпортовані налаштування, непозначений чекліст, складне ядро так і не почате. [B6](#b6) стає «портуйте один складний екран руками» — це і виготовляє свідчення, яких рішенню про фінансування бракувало три роки. Перевірка атрибуції: трифазний плейбук — Ларсонів, звірений з першоджерелом; твердження «агенти чудово справляються з цим класом робіт» — не його, це власна дисципліна оцінювання цього фреймворку, і цитується як така)

**31 · superseded**
~~Покупка адмінки за $45,760 показує «відсутні в проєкту ворота завершення, що з'являються в замовленні на покупку, а не в коді» — визначення завершеності не існувало.~~
Визначення існувало. Issue [#5391](https://github.com/solidusio/solidus/issues/5391) (відкритий із вересня 2023) публікує чекліст перенесення з явним обґрунтуванням послідовності, а блогопост за Q2 2023 переповідав план. Але за три роки не позначено жодного з його шести пунктів — включно з Settings > Zones, які код показує повністю портованими. Виправлено на: ворота збудовано, і ніхто не відповідає за їх закриття. Також знайдено: milestones існують, і milestone 5.0 містить нуль issues

**30 · superseded**
~~R1, перший у рейтингу: «немає автоматичного оновлення залежностей і кроку аудиту вразливостей — вразлива залежність доходить до кожного магазину, і ти дізнаєшся про це з чужого звіту нижче за течією».~~
Хибно — і це був ризик номер один. Опублікована безпекова політика показує програму розкриття на HackerOne, автоматичні безпекові оновлення залежностей, 18-місячне вікно патчів на три версії, два обов'язкові рев'ю перед мерджем, MFA на релізних акаунтах і трифазне координоване розкриття — з п'ятьма advisories, опублікованими 2020–2022. [R1](#r1) понижено до рутинного дрейфу версій, і він випав з першої трійки; реєстр тепер зрізається до [R3](#r3), [R2](#r2), R4. Оцінювання безпеки лише з файлів репозиторію проґавило процес, задокументований за один редирект звідси

**29 · superseded**
~~Цифри «файли Ruby» в таблиці компонентів: 855 / 328 / 278 / 193 / 166 / 98.~~
Кожна порахована двічі. Підрахунок включав *_spec.rb, тож колонки Ruby і Test повністю перекривалися — стара цифра = нові Ruby + Specs у кожному рядку. Перераховано без спек: 543 / 235 / 165 / 101 / 79 / 57. Додана колонка ERB виявила те, що ховав підрахунок Ruby: стара адмінка — це 79 файлів Ruby і 277 шаблонів вʼю, що дає другу, незалежну міру портування адмінки — ~40% за кількістю шаблонів

**28 · superseded**
~~«Документ про врядування не визначає жодного механізму ухвалення технічного напряму, тож жоден форум не має повноважень вирішити долю адмінки».~~
Перебільшено. Документ віддає Core Team «остаточне рішення про те, що потрапляє в ядро», а стейкхолдери справді проводять задокументовані щотижневі зустрічі — щоправда, ті явно обмежені «нетехнічними способами… конференціями… маркетингом… коштами». Виправлено на: повноваження призначені й зустрічі існують; бракує майданчика, ритму та опублікованого запису для технічних рішень. Це переводить виправлення зі створення врядування на його публікацію і додає ставку [B10](#b10)

**27 · superseded**
~~Новий сторфронт має нуль тестів.~~
Хибно, і це перевернуло знахідку. Він містить 64 файли спеків і 5,510 рядків у templates/spec/ — бо шаблон Rails-застосунку копіює свої спеки в згенерований застосунок. Перевірка шукала storefront/spec і нічого не знайшла. CI ганяє набір тестів наскрізно в згенерованому магазині на кожен push. Сторфронт переходить із прогнозованого кредиту в підтверджений, а «7 тижнів від роду» стає «роки від роду, сім тижнів у цьому репозиторії»

**26 · superseded**
~~Подати витрати однією таблицею, що поєднує річні підсумки з підсумками отримувачів за весь час.~~
Оманливо: читання вздовж рядка породжувало хибні твердження («2020 · Logicielle B.V.» натякав на платіж, що стався 2024-го). Розділено на дві таблиці. Виправлений порічний вигляд оголив знахідку, яку ховала зламана таблиця: кожен активний рік фінансував по суті одну співпрацю, і липень 2025 — це третя така співпраця, що завершилася, а не проєкт, що здався. Також виправлено: Logicielle надіслала 16 інвойсів, а не 22

**24 · standing**
Переперевірити баланс $132,180, узявши його під сумнів. (Вистояв і зміцнів. Два незалежні ендпоінти збігаються точно; запит усіх станів витрат (не лише оплачених) підтверджує: нічого не висить у pending чи approved. Дві розбіжності звірки тепер названі відкрито, а не замазані)

**25 · superseded**
~~«$132,180 лежать без діла» як характеристика інвестицій проєкту.~~
Пом'якшено. Ця цифра охоплює лише рахунок Open Collective. Подарований інженерний час двох агенцій значно її переважує. Знахідка звужується до: колективно врядовані гроші стоять нерухомо 12.5 місяця, поки заявлені пріоритети лишаються без фінансування

**21 · superseded**
~~Порадити додати CI, який перевіряє шлях встановлення.~~
Хибно — він уже існує і сильніший. Воркфлоу інсталятора запускає згенерований застосунок, перевіряє, що головна сторінка рендериться, і ганяє його набір тестів; другий воркфлоу покриває генератор розширень. Утретє за цей аудит знахідка «бракує можливості» померла за першого ж контакту. Пріор щодо цього проєкту я послідовно калібрував надто низько

**22 · standing**
Знайти справжній розрив: CI зелений на незадокументованому шляху встановлення. (Композитний action пише manifest.js перед запуском інсталятора, обходячи незмерджений апстрімний баг Sprockets. Задокументований шлях ≠ протестований шлях, що пояснює десятиліття проблем із встановленням. Стало ставкою [B9](#b9))

**23 · superseded**
~~Порахувати 12 ERB-файлів активів як блокери Propshaft.~~
Десять із дванадцяти — шаблони вʼю, що відповідають на AJAX-запити, а їх Propshaft ніколи не торкається. Лише два — асетні ERB, і один із них використовує ERB заради єдиного хелпера маршруту

**20 · standing**
Додати розрив у поколіннях Rails як окрему знахідку. (Rails 8 типово ставить Propshaft; solidus_core жорстко вимагає Sprockets. Відмінність не в «ми використовуємо Rails», а в «ми використовуємо Rails так, як це роблять зараз» — і на фундаменті, який завантажує кожен магазин, Solidus відстає на покоління)

**36 · standing**
Записати відповіді з вікна ввічливості; стейкхолдери «нікого не досягнуто» → «частково». (Чернетка, викладена в Slack проєкту, за годину зібрала відповідь Core Team: на питання 1 і 5 з §22 відповіли, [R3](#r3) знижено за його власним попередньо зареєстрованим правилом, знахідку «спершу легке» кваліфіковано — життєздатність оскаржено, послідовність частково визнано. Загальне застереження «не на 100% точний» саме по собі нічого не викреслює: жодне конкретне твердження не назване, а наступна конкретна суперечка розширює пошук щодо того твердження. Один набір відповідей — це підтвердження, а не доступ; фолоу-апи без відповіді лишаються в §22)

**37 · standing**
Записати відповіді на фолоу-апи. (Той самий тред, друга відповідь Core Team, ~через годину: адмінка — пріоритет, а модель фінансування свідома — незалежних розробників фінансують з колективу, щоб мейнтейнери уникали враження, ніби наживаються на ньому; робота за схемою «кошти агенціям» прийнятна, коли вона прозора й чесно оцінена; стосунки Solidus–Spree — «no beef these days, just different directions». Наслідки зібрано в [R3](#r3), у врізку про повʼязані сторони — відсутній стандарт незалежної угоди існує як проговорена норма, ніде не записана так, щоб її прочитав той, хто затверджує платежі, — і в пункт 3 §22, де патерн зовнішніх отримувачів тепер пояснено, а особи лишаються відкритими)

**38 · superseded**
~~«Останній блогопост — жовтень 2025. Далі — дев'ять місяців публічної тиші».~~
Існує пост, який первинний прохід проґавив: «Solidus Status Update – Solidus v4.7», опублікований 5 травня 2026, з анонсом релізу v4.7.0. Знайдений під час переперевірки rev-26, підтверджений завантаженням самого поста. Виживає вужче твердження: щомісячний ритм справді зупинився після жовтня 2025, і блог тепер говорить лише про релізи — один пост за останні десять місяців. Виправлення йде на користь предмета дослідження, як і кожне попереднє виправлення в цьому журналі

**39 · standing**
Записати переперевірку rev-26 (вікно свідчень — 8 серпня 2026). (Попередньо зареєстроване спостережуване з [R3](#r3) не спрацювало: через п'ять днів після заяви «новий кандидат у роботі» останній дебет у бухгалтерії — досі липень 2025, а баланс виріс до $133,750. Набір постійних спонсорів незмінний: дев'ять, $1,931/місяць. Мета-гем, непозначений чекліст і відсутній агентський харнес — кожне підтверджено повторно. Єдиний справді новий факт — на користь проєкту: forkata виконав обіцяне підхоплення застряглої роботи над діалогом підтвердження свіжим PR без спірної залежності, #6528, 30 липня. Spree відвантажив v5.6.1 28 липня)

**41 · superseded**
~~«Протестований проти Rails 8.1 і Ruby 4.0 ще до виходу обох» — тестова матриця покриває версії, яких ще не існує.~~
Помилка в датах — і впіймав її власник цього звіту, звіривши з самим файлом workflow. Rails 8.1 вийшов 22 жовтня 2025-го, Ruby 4.0 — у грудні 2025-го; Solidus додав їх у CI 23 та 29 січня 2026-го — на один-три місяці після релізу, а не до. Самі рядки матриці завжди були справжніми; формулювання «до виходу» — правдоподібна похибка початкового проходу (номери версій, що звучали як майбутнє, ніхто не звірив із датами), і вона пережила двадцять шість редакцій. Виправлено всюди до того, що підтверджують свідчення: найновіші Rails і Ruby, підхоплені за лічені тижні після релізу — досі верхній дециль актуальності, лише на риску менш надзвичайно. І ще одне, що варто зафіксувати: це перше виправлення в журналі, яке рухається проти напрямку «суб'єкт виглядає краще», встановленого попередніми сорока записами

**40 · standing**
Реструктурувати під фреймворк v0.7 (ця редакція). (Executive Summary замінено на «Політики й операції» — п'ять постійних правил, PL1–PL5, усі в стані «запропоновано», бо зовнішній аудитор не може приймати політику за проєкт, яким не володіє. Додано смугу «Легкі перемоги», і дві колишні ставки перетікають у неї: B3 стала E2 та E3, внутрішньорепозиторійна половина B4 стала E4; ідентифікатори лишаються списаними. Розділ «Список спостереження» тепер збирає всі дати перегляду. B9 отримує поле Refinement; B6 і так була рафінувальним зрізом адмінки й тепер названа такою явно. Жодна знахідка не змінилася внаслідок реструктуризації — всі виправлення цієї редакції походять з переперевірки й записані окремо в пунктах 38 і 39 вище)

## Список спостереження

Кожна дата, на яку чекає цей звіт, в одному місці — бо дата перегляду, яку ніхто не запланував побачити, — не дата перегляду.

| Пункт | Що його запускає | Коли | Хто стежить |
| --- | --- | --- | --- |
| Наступна вихідна витрата Open Collective — спостережуване, яке підтверджує профінансованого кандидата і на яке тепер спирається [R3](#r3) | Будь-який дебет у публічній бухгалтерії | прострочено — «у роботі» заявлено 3 серпня 2026; нічого не з'явилося | цей звіт, у кожній редакції |
| Мердж [#6528](https://github.com/solidusio/solidus/pull/6528) — рятувальний механізм завершує свій перший повний цикл | Мердж або закриття | наступний релізний цикл | цей звіт, у кожній редакції |
| [C8](#c8) — кредит промоакцій, прогнозований і прострочений | Названий реліз вилучення ([B5](#b5), [PL1](#pl1)) | списати, якщо на наступний мажорний реліз досі не заплановано | запропоновано: Core Team |
| [C9](#c9) — кредит адмінки, за точкою списання | Вердикт за [PL4](#pl4) або експеримент [B6](#b6) | перший квартальний прохід | запропоновано: Core Team |
| Перегляд [B9](#b9) | Дата перегляду | 2027-01-25, або перший мажорний реліз після мерджу | запропоновано: Core Team |
| Реєстр політик — прийнято, змінено чи відхилено | Будь-який рядок PL, що змінює стан; два квартали тиші — тривожний сигнал із пре-мортему | 2027-02-08 | цей звіт, у кожній редакції |
| Чи обсяг комітів Spree людський, а чи згенерований (пункт 7 у [§22](#чого-я-не-зміг-встановити)) | Будь-який публічний аналіз складу внесків Spree | відкрито | цей звіт, у кожній редакції |

## Чого я не зміг встановити

Усе тут неперевірене. На це не варто спиратися як на факт — і більшість цього розв'язала б одна розмова.

1. **Чому співпрацю 2025 року не продовжили.** Найцінніше невідоме у звіті. Проєкт тричі окремо фінансував розробника (2020, 2024, 2025) і тричі окремо зупинявся, з повністю сухими роками між ними. Тож питання не «чому фінансування зупинилося» — зупинки тут норма, — а **чому ця пауза триває тринадцять місяців, коли попередні зрештою заповнювалися.** Бюджетна обережність, підрядник, що пішов далі, свідома пауза чи просто ніхто не запропонував наступної співпраці — усе це дає ідентичну бухгалтерію і передбачає протилежні відповіді. **Відповідь на rev 24:** «Кандидата немає. Просто зараз у нас у роботі новий кандидат, але поділитися нам нічим, окрім того, що ми над цим працюємо» `[user]`. Кадрова прогалина, а не рішення зупинитися — і «в роботі» дивиться вперед: наступна вихідна витрата в бухгалтерії — те спостережуване, що це підтвердить. Станом на 8 серпня вона не з'явилася.
2. **Чому Nebulab згорнулися.** Патерн однозначний; причина — ні. Бізнес-рішення, свідома передача чи природний відтік — усе дає ту саму криву.
3. **Хто такі «Logicielle B.V.» та «e.c441».** Разом вони отримали $49,394 — майже третину всіх коли-небудь виплачених грошей — упродовж 2024 і 2025. Особу не встановити з публічних записів, а від неї залежить, чи купували ці витрати тяглість, чи разову роботу. **Контекст на rev 25:** зовнішні отримувачі — це *проговорена перевага*, а не аномалія: колектив свідомо фінансує незалежних розробників з досвідом Solidus, щоб мейнтейнери трималися осторонь грошей `[user]`. Особи лишаються відкритими; патерн — уже ні.
4. **Чи зарезервований баланс під щось.** Жодна політика цього не документує, але причина може критися в протоколах зустрічей.
5. **Чи вважає Core Team нову адмінку живою.** Виведено цілком із загасання комітів. Мейнтейнер може сказати, що темп навмисний. *Ця єдина відповідь пересуває [R3](#r3) з високого в низький.* **Відповідь на rev 24:** жива і навмисно розмірена — реальні магазини вже сьогодні використовують незавершену адмінку в продакшені, і це сигнал використання, якого аудит, що читав лише загасання комітів, побачити не міг `[user]`. R3 опускається, як попередньо зареєстровано; застереження живе на самому рядку ризику.
6. **Налаштування захисту гілок і склад Core Team.** Обидва потребують адмінських прав в організації й повернули помилки доступу, а не відсутність, тож «два обов'язкові рев'ю Core Team» з безпекової політики спираються на опубліковану заяву, а не на спостережене виконання. Та сама межа стосується того, чи ввімкнене сканування вразливостей через інтерфейс GitHub.
7. **Чи відображає обсяг комітів Spree людську роботу, а чи згенеровану.** Одне неперевірене стороннє твердження каже, що другу. Це найвагоміше відкрите питання щодо порівняння в [§09](#spree-виміряний).

> **ДЕ ПИТАТИ — ЦІ КАНАЛИ ПУБЛІЧНІ Й ЖИВІ**
> Slack — http://slack.solidus.io перенаправляє на робоче спільне запрошення. Саме тут живуть щотижневі зустрічі стейкхолдерів, канал підтримки та приватний партнерський канал.Безпековий список розсилки — groups.google.com/forum/#!forum/solidus-securityGitHub Discussions — включно з категорією «New Admin UI Ux», яку цей аудит не зміг прочитати через API.

> **ПУБЛІЧНОГО ОПИСУ ЦЬОГО ЗАНЕПАДУ НЕ ІСНУЄ**
> Цільові пошуки публікацій про те, що Solidus застряг, покинутий чи здає позиції Spree, не повернули нічого — повторний запуск 8 серпня 2026 дав той самий результат `[web]`. Натомість існує шар агентських порівняльних статей, кілька з них датовані 2026-м, і вони досі пишуть, що Solidus показує «стабільнішу розробку», ніж Spree, — протилежне тому, що показують репозиторії.
> 
> Публічний наратив не наздогнав дані, а в найкращій позиції написати його — дві фірми, чий бізнес залежить від платформи.

> **СТРУКТУРНА МЕЖА ВСЬОГО ЦЬОГО ЗВІТУ**
> До rev 24 ніхто з проєкту не говорив. Бізнес-цілі, пріоритети й судження про те, на які ризики варто реагувати, — усе було реконструйовано з публічних записів, а не проговорено кимось, — і ранжування досі обрізається об виведену ціль (що Solidus існує, аби уможливлювати клієнтську роботу агенцій, які його фінансують) — висновок, несучий для всієї пріоритизації. Якщо він хибний, ранжування змінюється — а з ним і реєстр політик, укладений з того самого діагнозу.
> 
> Вікно ввічливості звузило цю межу, не прибравши її. Один член Core Team — Джаред Норман, Super Good — відповів у Slack проєкту, і його вердикт про звіт — водночас і епістемічний статус самого звіту: «Оскільки він ґрунтується на публічно доступній інформації, він не на 100% точний, і я не з усіма оцінками тут згоден, але безумовно корисно побачити, який вигляд має публічний стан проєкту, зібраний докупи» `[user]`. Жодне конкретне твердження не оскаржене, тож нічого не викреслено; наступна конкретна суперечка розширює пошук щодо того твердження, за контрактом. Власне виправлення цієї редакції — про тишу в блозі — нагадує, що вердикт був заслужений: твердження, яке він міг би назвати, першою знайшла повторна перевірка.
> 
> Найясніша ілюстрація — запис 07 у журналі рішень: я прочитав «відкритий рік» як «чекає на рев'ю» і збудував на цьому діагноз. Один мейнтейнер відповів би на це одним реченням. Кожна редакція цього звіту до rev 24 була висновуванням замість розмови, якої ніхто не провів. Rev 24 — перший виняток, і кожна з його перших трьох відповідей щось зрушила.
> 
> Ніщо тут не просить, щоб йому вірили: кожне фактичне твердження в цьому звіті несе позначку, як до нього дійшли, а позначки рахує збірка — їх ніколи не пишуть руками.