# SaaS ERP

*Два роки чудової інженерії без жодного запуску. Система вміє тихо заблокувати роботу цеху і не має способу про це повідомити, і саме тому власник двох діючих фабрик щоразу відступає.*

> Звіт · ред. 4 · оновлено 2026-09-19 · 112 тверджень із джерелом · https://vit-panchuk.com/uk/reports/saas-erp/

---

```
Доказова база — 112 тверджень із джерелом
[знайдено]    ████████████████░░░░░░░░░░░░░░░░░░░░   44%  (50)
[веб]         ███████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   20%  (22)
[стейкхолдер] ██████████░░░░░░░░░░░░░░░░░░░░░░░░░░   29%  (32)
[виведено]    █░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░    3%  ( 3)
[припущено]   █░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░    4%  ( 5)
```

---
Два роки розробки, дві пари рук, 95,71% покриття тестами, і жодного дня
реальної роботи на жодній із двох фабрик, які власник має напоготові.

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

Мета ширша за запуск: обидві фабрики власника, продуктизація і продаж системи
як SaaS зовнішнім клієнтам `[user]`. У цій рамці вартість
наповнення даними перестає бути разовою перешкодою і стає юніт-економікою
кожного наступного клієнта.

Що і за який період дивились: репозиторій `main` станом на 2026-08-12, експорт
Telegram за 2024-05-13 → 2026-08-10 (5 735 повідомлень), веб-огляд 2026-08-13.
Тести прогнали і покриття виміряли 2026-08-13 на окремій базі. Доступу до
GitHub Actions і до репозиторію мобільного застосунку не було; там, де це
змінює висновок, сказано прямо. Пізніше додалось одне свідчення зсередини
команди. 2026-08-19 автор представив звіт BE-розробникові, а 2026-09-08
попросив у нього відгук `[user]`. Що саме ця розмова зрушила, записано в журналі
рішень, у [K14](#k14).

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

Майже половина тверджень стоїть на прочитаному в коді, git-історії та експорті
чату, ще п'ята частина — на веб-джерелах. Для питань факту це міцна основа. Слабке місце в іншому: власника фабрик,
головну дійову особу цієї історії, аудит не опитував. Слова стейкхолдера тут
мають два джерела. Більшість сказав автор аудиту — людина поруч із проєктом, а
не учасник команди. Решту, датовану 2026-09-08, — BE-розробник, якому звіт
представили 2026-08-19.

> **ЧОГО ЦЕЙ ЗВІТ НЕ БАЧИВ**
> Мобільний застосунок лежить в окремому репозиторії Mobile/, якого немає на машині аудиту. Це третій клієнт системи і носій головної продуктової обіцянки. Жодне твердження про його код тут не зроблено; там, де його стан важить, стоїть відкрите питання [Q8](#чого-ми-не-знаємо). Так само не прочитано історію запусків GitHub Actions. Прочитані лише самі воркфлоу; про те, як вони завершувалися, цей звіт не свідчить.

## Початок тут

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

### Що таке SaaS ERP

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

Технічно це монорепозиторій із чотирьох частин `[observed]`:

- **Rails 8.1 API** — 138 моделей, 86 контролерів, 442 міграції. Уся доменна
  логіка.
- **`frontend/`** — перший веб-інтерфейс на antd. Виведений з експлуатації в
  липні 2026, лишається в git як довідковий матеріал.
- **`frontend_v2/`** — другий веб-інтерфейс, React 19 + власна дизайн-система.
  Основна лінія роботи з лютого 2026. `[observed]`
- **`docs/`** — сайт документації на Next.js із PRD, user stories і ADR. `[observed]`

Плюс **мобільний застосунок на React Native** в окремому репозиторії — саме він
несе обіцянку продукту.

### Обіцянка продукту

Її сформулював автор аудиту `[user]` так: робітниця в цеху має мобільний застосунок,
підходить до надрукованого документа з QR-кодом, сканує його, і отримує саме той перелік операцій, який має робити сьогодні.

Це не декоративна деталь. Це і є те, за що фабрика платить: керування в
реальному часі замість обліку постфактум.

### Дійові особи

- **Власник** — не з IT.
  Носій предметної експертизи рівня технолога: диктує модель даних, оперує
  поняттями 1С, перелічує канонічні документи швейного виробництва напам'ять
  `[observed]`. Має **дві діючі швейні фабрики**, з яких можна стартувати `[user]`.
- **FE-розробник** — фронтенд. 2 553 коміти (79% усіх). `[observed]` Побудував
  обидва веб-інтерфейси, мобільний застосунок, CI, документацію, ADR,
  e2e-набір і agent harness. Фактично комітить у backend більше, ніж
  backend-розробник.
- **BE-розробник** — backend на Ruby. 692 коміти
  `[observed]`. Володіє інфраструктурою Heroku `[user]`.
- **Автор аудиту** — у проєкті не працює: комітів не має,
  у робочому каналі не пише `[observed]`. Він задав вектор
  дослідження, висував гіпотези і виправляв висновки по ходу роботи.

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

### Як читати позначки

|  |  |
| --- | --- |
| `[observed]` | Побачено безпосередньо в системі — код, виконана команда, git-історія, прогін тестів. |
| `[web]` | Перевірено в зовнішньому джерелі — сайт конкурента, галузева література. |
| `[user]` | Заявлено стейкхолдером. Авторитетно для бізнес-фактів, але переглядається. |
| `[inferred]` | Виведено з доказів міркуванням. Не факт. |
| `[assumed]` | Ані перевірено, ані підтверджено. Усе таке — в розділі невідомого. |

### Коди реєстрів

`PL` політики · `S` стратегії в силі · `RC` першопричини · `R` ризики ·
`D` борги · `C` активи · `E` швидкі перемоги · `B` ставки · `K` рішення ·
`P` пре-мортем · `Q` відкриті питання. Кожна згадка коду несе однорядкову
пам'ятку, щоб не доводилось шукати, що це було.

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

- **2024-05-22** — Перший коміт.
- **2024-11-06** — Власник просить визначити терміни запуску. Відповіді немає, і не буде жодного разу за 27 місяців.
- **2024-12-17** — Власник сам вимірює вартість входу: «для заповнення 1 специфікації з 18 позицій зайняло близько 30 хвилин це дуже довго». Просить авто-пошук при заповненні.
- **2025-01-22** — Власник заповнює обладнання цеху на одній із фабрик — реальна спроба наповнення.
- **2025-07-15** — Тестування на фабриці: сценарій на п'ять пачок не дає закрити виконану роботу.
- **2025-08** — Єдиний пілот на живих робітницях. Петля «друк → скан → робота» розсипається у п'яти місцях.
- **2025-12-29** — FE-розробник знаходить стартап-грант до 100 тис. USD. Умова — запущена версія продукту, бажано з доходом.
- **2026-01-06** — Зустріч по гранту перенесено.
- **gap** — Слово «грант» не зʼявляється в чаті жодного разу за наступні сім місяців.
- **2026-01-25** — «Обнулив продакшн».
- **2026-02-05** — Перший коміт frontend_v2. Починається переписування фронтенду.
- **2026-03** — Хвиля рефакторингу: 70 комітів за місяць проти 1–9 раніше. Триматиметься п'ять місяців.
- **2026-06-24** — Резервний шлях — повний CRUD процесів зміни у вебі — отримує повноцінну розробку.
- **2026-07-30** — FE-розробник: «В мене поки немає завданнь… я можу займатись пошуком роботи?»
- **2026-08-10** — Останній день експорту. Обговорення підпису поля в довіднику матеріалів.
- **2026-08-19** — Автор аудиту представляє звіт BE-розробникові.
- **2026-09-08** — Автор просить у BE-розробника відгук на звіт. Запуску на фабриці досі немає: власник зупинився на тому, як згрупувати обладнання, а в моделі обслуговування обладнання прив'язане до його підгрупи. FE-розробник тим часом переписує мобільний застосунок, BE-розробник робить ролі.

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

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

Одна умова визначає форму всіх шести. Мандату в проєкті немає: власник не має
технічної експертизи, BE-розробник за власним визнанням не бере на себе
покращення машини й інженерне лідерство, FE-розробник — найкращий кандидат у
лідери, але без глибокої BE-експертизи, і саме він щойно питав про пошук
роботи [RC2](#rc2). Тому жодна політика
тут не розраховує на те, що хтось наполягатиме. Ті, що мусять спрацювати
напевно, зроблені рамками CI: вони не питають дозволу. Ті, що рамками стати
не можуть, свідомо ослаблені до рекомендації. Приписова політика, яку нікому
виконувати, це театр згоди, а не стратегія.

**PL1 — Історія Telegram-чату із замовником конвертується в Issue Tracker на GitHub Projects** *(direction · proposed)*
Найдешевша політика в наборі, і водночас та, що б'є в найдорожчий дефект. Ламається все в одному місці: канал, який працює за дошку задач, не має стану. Сказане в ньому не має ні відповідального, ні дати, ні способу перевірити, чи воно зроблене.Три найдорожчі втрати саме такі. 17 грудня 2024 власник сам виміряв вартість входу і попросив конкретне виправлення — перший коміт того класу датований 3 червня 2026, через вісімнадцять місяців, і це не те, про що він просив. Так само розчинилися дата запуску (листопад 2024) і трек гранту на 100 тис. USD (січень 2026).Тому політика починається не з нового правила, а з конвертації того, що вже сказано. У чаті лежать 5 735 повідомлень за 27 місяців, і в них — уся незакрита робота проєкту: вимоги власника з номерами й прикладами, скарги на дефекти, обіцянки «зробимо в наступній версії». Це велика, але механічна робота з розбору тексту, тобто рівно те, що агент робить за один прохід. Після конвертації правило тримається саме собою: якщо задача не в трекері, її немає.Другий канал у той самий трекер — Sentry, що заводить issue сам [E4](#e4). Це не додаткова зручність, а друга половина того самого механізму. Чат ловить те, що власник помітив і не полінувався написати; Sentry ловить те, чого не помітив ніхто, а на фабриці це і є найдорожчий клас [R1](#r1): збій, після якого робітниця просто йде до майстра, а не пише в Telegram. Разом вони закривають обидва боки: людський сигнал перестає розчинятися, машинний уперше зʼявляється.
Що закриває: [RC1](#rc1) · [D6](#d6) · [R5](#r5) · [R1](#r1) · [D3](#d3)
Щодо чинних стратегій: уточнює [S3](#s3)
Механізми: Три дії, жодних зборів. Разова: агент проходить експорт чату і заводить у GitHub Projects кожну незакриту вимогу, скаргу і обіцянку, з датою та автором з оригіналу. Стала: раз на тиждень той самий прохід по новому, з тихим виходом, коли заводити нічого. Автоматична: інтеграція Sentry заводить issue на кожну нову помилку в проді сама, без людини в ланцюгу.
Виконується: GitHub Projects на репозиторії бекенду: разова конвертація історії, щотижневий прохід агентом по чату, інтеграція Sentry → GitHub Issues
Перегляд: 2026-11-13

**PL2 — Гілка main захищена зеленим rspec, і кожен прогін публікує метрику покриття** *(direction · proposed)*
У проєкті є 6 114 прикладів rspec і 95,71% покриття рядків. BE-розробник запускає їх регулярно `[user]`, тож набір не лежить мертвим — він прикриває ті зміни, які проходять через його руки.Проблема в тому, що через його руки проходить менша частина backend-у. FE-розробник зробив у backend 1 089 комітів проти 588 `[observed]`, і робить це власним агентом, який правил BE-розробника не бачить `[user]`. Локальна звичка однієї людини не може прикрити чужі коміти за визначенням: між ними немає спільної точки, крім main.Сім падінь rspec при цьому відомі розробникам, задокументовані і не полагоджені — їх навіть не позначили як skip, вони просто падають `[user]`.Цінність цієї політики не в тому, що вона щось покаже. Показувати нема чого: команда й так знає. Цінність потрійна. По-перше, вона поширює наявну звичку на обидві пари рук замість однієї. По-друге, робить ігнорування дорогим: червоний білд, який нічого не блокує, можна перетерпіти, а рамки, які не пропускають злиття, перетерпіти не можна — їх або лагодять, або свідомо знімають, і обидва варіанти краще за мовчазне терпіння.По-третє — і про це рідко говорять уголос — це частина harness engineering, тобто дисципліни для агентів. Коли агент бачить червоний білд, він його спробує виправити: сигнал у CI для агента є не звітом, який можна відкласти, а задачею, яку видно в момент роботи. У проєкті, де FE-розробник пише бекенд-код своїм агентом `[user]`, це перестає бути абстракцією: зелений білд і є тим механізмом, який тримає чужу за фахом роботу в межах. Без нього агент не має зворотного звʼязку взагалі, і єдиною перевіркою лишається рецензент, який у цій ділянці не має експертизи.Варто наголосити на ціні. Це не побудова процесу з нуля: CI вже стоїть і працює — три джоби в test.yml (Unit Tests, Lint, E2E Tests) плюс окремий воркфлоу для міграцій `[observed]`. Третя з них уже вміє найскладніше: піднімає бекенд у docker, чекає готовності API і розгортає базу. Набір тестів написаний і зелений на 6 114 прикладах. Бракує однієї джоби, яка запускає наявне на кожен PR. З усього, що пропонує цей звіт, це найдешевша дія з найбільшим охопленням.
Що закриває: [RC3](#rc3) · [D1](#d1)
Щодо чинних стратегій: замінює [S2](#s2); ратифікує [S1](#s1)
Механізми: Автоматизація: джоба в наявному воркфлоу. SimpleCov у групі :test, артефакт покриття як вихід джоби і поріг, нижче якого злиття не проходить: сьогодні цифри не бачив ніхто, тож перший крок це зробити їх видимими, а не одразу карантинними. Сім відомих падінь розділяються, а не карантинуються гуртом `[observed]`: шість у відеопідсистемі (videos_spec, aws_events_controller_spec) ідуть у карантин з issue і датою, а сьоме — users_controller_spec — карантину не підлягає, бо це живий дефект, і його лагодять.
Виконується: Обов'язкова перевірка GitHub Actions на main і staging (детерміністична сходинка)
Перегляд: 2026-09-13

**PL3 — Пілот на фабриці стартує лише паралельно з чинним обліком, і чинний облік не вимикають, доки тижнева розбіжність не впаде до нуля** *(direction · proposed)*
Це та політика, що робить запуск можливим, і вона не про софт. У фабрики немає права на простій: якщо система відмовляє, лінія стоїть, а швачка на відрядній оплаті не отримує грошей. Доки збій зупиняє виробництво, раціональна поведінка власника, це не запускати. Саме це ми й бачимо два роки поспіль. Паралельний прогін розриває цей зв'язок: чинний облік продовжує рахувати, система рахує поруч, і дефект стає розбіжністю в таблиці, а не зупинкою цеху.«Чинний облік» тут означає те, чим фабрика рахує сьогодні, хай яким воно буде. Це не обовʼязково папір: може бути Excel, 1С, зошит майстра, чат у телефоні або комбінація всього переліченого. Формат не має значення для політики — має значення лише те, що він не вимикається на час пілоту і що його числа щодня є з чим порівняти. Галузева література описує це як паралельний прогін із папером, бо так історично склалося `[web]`, але суть не в носії, а в наявності другого, незалежного лічильника. У конкурента Scan ERP це тиждень 2 із чотирьох `[web]`.Побічно це знімає ще один ризик, про який легко забути: якщо фабрика вимикає старий облік і система дає збій, відновити дані нема звідки. Другий лічильник є ще й резервною копією.
Що закриває: [RC6](#rc6) · [R1](#r1) · [RC4](#rc4)
Щодо чинних стратегій: заповнює порожнечу: жодна стратегія в силі цього не покриває
Механізми: Інспекція: щоденне звіряння двох чисел, скільки одиниць порахував чинний облік і скільки система. Розбіжність за день є єдиною метрикою пілоту.
Ухвалює: власник (рішення його — це його виробництво)
Виконується: Умова старту пілоту, зафіксована письмово перед першим днем
Перегляд: 2026-10-13

**PL4 — Поки на реальній фабриці не закрито жодної зміни, щонайменше 70% часу розробки йде на роботу, що веде до запуску** *(allocation · proposed)*
Розподіл ресурсу тут не бюрократія. Це єдиний спосіб зробити незапуск дорожчим за переписування. З березня 2026 темп рефакторингових комітів зріс із 1–9 до 70 на місяць і тримається п'ять місяців. Це чудова робота: межі FSD-модулів як помилки CI, ADR-и, зелений білд на кожній фазі міграції. І вона почалась через тиждень після того, як продакшн обнулили, і через два місяці після того, як згас грант, умовою якого був запуск. Поки жодна цифра не розділяє «робота на запуск» і «робота на код», ця заміна відбуватиметься сама собою і виглядатиме бездоганно обґрунтованою щоразу.
Що закриває: [RC2](#rc2) · [RC5](#rc5) · [R4](#r4)
Щодо чинних стратегій: замінює [S6](#s6)
Механізми: Розподіл це найконкретніша форма пріоритету. Механізм: одна таблиця на тиждень, без зборів.
Ухвалює: власник як платник
Виконується: Тижневий огляд: у якій колонці стояла робота кожного розробника
Перегляд: 2026-10-13

**PL5 — Продуктова обіцянка має названого відповідального і дату перевірки; якщо перевірка не відбулась у строк, обіцянку офіційно знімають** *(approval · proposed)*
Обіцянку (робітниця сканує і отримує роботу) перевіряли один раз, у серпні 2025. Вона не спрацювала. Її не полагодили публічно і не зняли: натомість поруч виріс резервний шлях, у якому дані про виконану роботу вводить адміністратор у вебі, і саме він отримав повноцінну розробку в червні 2026 і сім e2e-специфікацій. `[observed]` Так продукт тихо змінив природу — з керування в реальному часі на облік постфактум, і жодного рішення про це не існує. Ця політика не вимагає полагодити петлю. Вона вимагає, щоб хтось був за неї відповідальний і щоб мовчазне відмирання стало неможливим.
Що закриває: [RC4](#rc4) · [R3](#r3) · [R6](#r6)
Щодо чинних стратегій: заповнює порожнечу, названу [S7](#s7)
Механізми: Затвердження з адресою: одне рішення, записане в лог, із датою. Не зустріч, а рядок.
Виконується: Запис у Decision Log репозиторію; ухвалює власник разом із розробниками
Перегляд: 2026-10-13

**PL6 — Нове переписування не починається, доки не записані його причина, критерій завершення і дата** *(guidance · proposed)*
Це єдиний рядок у наборі, свідомо ослаблений до рекомендації, і причина називається прямо: приписати його нікому. Мігація v1→v2 має названу причину (циклічні залежності в v1: 60 доменів, 223 ребра) `[observed]` і рамки якості на кожній фазі — це зразкове переписування. Чого воно не має — критерію виходу і дати, після якої frontend/ перестає отримувати фічі. Тому два веб-клієнти живуть паралельно вже пів року, а разом із мобільним це три клієнти на дві пари рук.
Що закриває: [RC2](#rc2) · [D4](#d4)
Щодо чинних стратегій: уточнює [S6](#s6)
Механізми: Модель-документ-поділись: найслабший механізм із можливих, і свідомо. Виконавця, готового це приписувати, немає.
Виконується: Норма в кореневому AGENTS.md; запис у Decision Log
Перегляд: 2027-02-13

> Дві політики з шести — [PL2](#pl2) і [PL1](#pl1) — не потребують нічиєї волі: одна це рамки CI, друга це щотижневий прохід агента. Саме тому вони перші. Решта чотири вимагають рішення власника, і без нього залишаться текстом.

## Бізнес-контекст: гроші, яких менше, ніж здається

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

Оплата планується наперед («Планую до 05.03 зробити оплату 1750 у.о.»), існує
величина «зароблено, але не виплачено» (BE-розробник випадково затер формулу,
яка її рахує, у спільній Google-таблиці), а поняття заборгованості достатньо
живе, щоб її закриття оголошували окремо: «Заборгованість відсутня»
`[observed]`. Суми коливаються: 85 386 грн за місяць одному
розробнику в серпні 2025 (≈2 000 USD), 1 750 у.о. у лютому 2025, 500 у.о. у
червні 2026. Квитанції надходять парами приблизно щомісяця, з розривом майже на
п'ять місяців між квітнем і вереснем 2025.

Обмеження цього читання назване прямо: квитанції в чаті — неповний облік,
платежі могли йти повз канал, а таблиця з реальним рахунком аудиту недоступна.
Тому висновок — `[inferred]`, а не факт.

Але груба арифметика варта уваги: ≈2 000 USD × 2 розробники × 27 місяців дає
близько 100 тис. USD уже витрачених. Це приблизно дорівнює гранту, який
FE-розробник знайшов у грудні 2025 — з умовою «мати вже хоч якусь запущену
базову версію продукту (в ідеалі з доходом)». Тобто зовнішні гроші, які могли б
подвоїти ресурс проєкту, лежать за тими самими дверима, що й запуск.

Попереду стаття, якої немає в жодній таблиці: вихід на зовнішніх клієнтів
потребуватиме маркетингу. Автор аудиту оцінює його щонайменше в 50 тис. USD
`[assumed]`. Це оцінка порядку, а не розрахунок, але вона показує
масштаб: до продукту на ринку треба вкласти ще щонайменше половину вже
вкладеного.

> Стартап-грант до 100 тис. USD вимагає запущеної версії продукту, бажано з доходом. Тред прожив тиждень у грудні 2025 і згас після перенесеної зустрічі. За наступні сім місяців слово «грант» в експорті не зустрічається жодного разу.

## Продукт: обіцянка, яку перевіряли один раз

Обіцянка звучить так: робітниця підходить до надрукованого маршрутного листа,
сканує QR і отримує свій перелік операцій на день `[user]`.

Реалізація цьому відповідає. QR несуть саме ті два документи, що є документами
партії: маршрутний лист і карта крою, кожен із payload `{ id, type }` на
етикетці 100 × 50 мм разом із кодом, виробом, кольором, розміром і плановою
кількістю `[observed]`. Специфікація QR не має і не повинна: вона є
шаблоном виробу, а не завданням на конкретну партію.

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

Перевірка відбулась у серпні 2025, на живих робітницях, один раз. Петля
розсипалась у п'яти незалежних місцях.

> **Власник** · 2025-08-19
> "Чомусь трішки погано сканується"

> **Власник** · 2025-08-19
> "Хоча роздрукована на принтері з 600 dpi"

> **FE-розробник** · 2025-08-20
> "до речі, код може погано скануватись через те, що зверху немає відступа в етикетці"

> **FE-розробник** · 2025-08-20
> "те що вони натиснули «розпочати, сканувати» не створило їм процес в їх зміні, тобто немає до чого долучатись"

Останній рядок і є обіцянка, що не виконалась, у момент її єдиної перевірки: людина відсканувала і не отримала роботи.

Решта три: після генерації етикетки збивається послідовність друку; під час
сканування на екрані лишається частина попереднього меню; QR несе прив'язку до
місця розташування, через що маршрутний лист, створений в одному підрозділі, не
відкривався у зміні того ж підрозділу. Серверна валідація прив'язки обладнання
до підрозділу з'явилась 2026-07-23 — через одинадцять місяців після того, як
власник про це написав.

І ще одна умова, яку власник назвав ще у березні 2025: петля вимагає двох
сканувань — обладнання і документа — плюс відкритої зміни в правильному
підрозділі. «Кожного разу сканувати одну і ту саму річ не актуально».

> У травні 2025 розробник спроєктував «резервну функцію, щоб адмін міг вручну внести дані про виконанні процеси». У червні 2026 вона отримала повний CRUD процесів зміни у вебі й сім e2e-специфікацій. Мобільна половина петлі — та, що несе обіцянку — з серпня 2025 на людях не перевірялась.

## Організація: у кімнаті немає дорослого

Формулювання належить авторові аудиту `[user]`, не власникові
фабрик і не комусь із команди. Це оцінка ззовні: людина, яка дивиться на
проєкт збоку, не бачить у ньому нікого, хто тримав би інженерний напрям. У
таблиці нижче її немає — там лише ті троє, між якими розподілені ролі.

Розкладка ролей проти потреби:

| роль | що може | чого не може |
| --- | --- | --- |
| Власник | предметна істина, пріоритети, гроші, доступ до двох фабрик | технічна стратегія — немає експертизи |
| BE-розробник | домен backend, інфраструктура Heroku | не бере на себе покращення машини та інженерне лідерство |
| FE-розробник | CI, ADR, PRD, harness, e2e, фактично і backend теж | немає глибокої BE-експертизи; 2026-07-30 питає, чи шукати роботу |

Із цього випливають три речі, і всі три структурні, а не персональні.

Стеля припису низька. Немає людини, яка одночасно має мандат і готова
застосовувати наслідки. Тому приписова політика, що спирається на людську
наполегливість, провалює критерій виконуваності за визначенням — звідси форма
[PL2](#pl2): рамки, які не питають
дозволу.

Інфраструктура і воля до її покращення лежать у різних руках. Heroku належить
BE-розробнику; безперервне покращення машини — не його зона за власним
визнанням. Будь-яка політика, що вимагає змін у деплої чи CI, має або переїхати
до FE-розробника **разом із доступом**, або лишитись невиконаною.

Знаннєвий розрив односторонній і повний. Поза полем зору BE-розробника
перебуває вся інженерна надбудова: устрій CI, ADR-и, PRD, набір із 303
e2e-тестів, harness на 426 рядків `[user]`. У зворотний бік
асиметрії немає: FE-розробник комітить у backend 1 089 разів і робить це власним
агентом. Тобто майже всі інженерні активи проєкту створені однією людиною і відомі лише їй, і це та сама людина, яка щойно запитала про пошук роботи.

## Інженерія: висока якість без жодних рамок

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

- **95,71%** — покриття backend від rspec, 6 114 прикладів
- **79,05%** — покриття backend від e2e, 303 тести
- **80,72%** — покриття frontend від e2e
- **0** — з цього було коли-небудь виміряно до цього аудиту

Покриття виміряно інструментуванням, якого в проєкті ніколи не було:
`simplecov` немає в `Gemfile`, артефакт покриття не генерується, Codecov не
підключений. Тобто жодної з цих цифр не бачив жоден учасник команди — вони
всі виміряні вперше тут. Вихідна теза автора аудиту була саме про це: покриття
не *записується*, і вона вірна.

Два набори міряні окремо. Rspec: 6 114 прикладів, 95,71% рядків і 82,12%
гілок. E2e, знято одним прогоном 2026-08-14 (303 passed): backend 79,05% рядків
(7 193 / 9 099) і 45,56% гілок, frontend 80,72% рядків (21 634 / 26 800)
`[observed]`.

Читати їх треба разом. 79% рядків backend від браузерних тестів — це багато:
303 тести ганяють реальні доменні сценарії, а не димові перевірки. Розрив по
гілках (45,56% проти 82,12%) показує здоровий поділ праці: e2e йде щасливими
шляхами, юніт-специфікації беруть гілки помилок. Тобто backend прикритий із
двох незалежних боків.

І тут потрібне уточнення, бо воно змінює адресу проблеми. **E2e в CI
виконується**: у `test.yml` є джоба `E2E Tests`, яка піднімає бекенд через
`docker compose`, чекає готовності API, розгортає базу і запускає Playwright
`[observed]`. Отже бекенд у CI перевіряється — але з браузера, по
щасливих шляхах, із покриттям гілок 45,56%.

Не виконується в CI саме **rspec**: набір із 6 114 прикладів, який тримає
82,12% гілок, не запускається жодного разу. Це не «тести не підключені» — це
«підключений той із двох наборів, який найгірше ловить помилкові гілки, а той,
що ловить їх найкраще, мовчить».

Шлях до цієї цифри сам є знахідкою. Дві спроби провалились, і кожна показала
окремий дефект:

1. Bootsnap несумісний з інструментуванням покриття — усі 308 файлів падають
   на завантаженні.
2. rspec не стартує у власному тестовому стеку проєкту: сервіс `api` тримає
   ту саму базу, яку `DatabaseCleaner` очищає в `before(:suite)`, і вони
   взаємно блокуються.

Перший вимір після обходу дав 47,94%, і був хибним: жоден приклад не
виконався, число відображало виконання коду під час завантаження Rails. Викрила
це метрика гілок: 0,36%.

### Спостережуваність

Її немає. Перевірено `Gemfile`, `package.json`, `frontend_v2/package.json`:
жодного Sentry, Bugsnag, Rollbar, Honeybadger, AppSignal, Datadog, New Relic
`[observed]`, підтверджено замовником `[user]`.

Є `/up` (застосунок піднявся), логи у stdout із тегом `request_id` без
агрегації — Logplex тримає буфер на \~1 500 рядків і до тижня, тож без drain
вони зникають `[web]`; і скрипт, що
вивантажує сорсмапи в S3 **без приймача помилок**: заготовка під розшифровку
стектрейсів, які нікуди не надсилаються.

### Механізм, що зупиняє цех

Це найважливіша знахідка інженерного розділу, і вона стає видимою лише в
рамці «це фабрика». `ProcessItem` валідує на створенні:

```ruby
# app/models/process_item.rb

```

Читається так: незавершений процес тримає резерв на всю свою планову кількість. Звільнити його можна двома способами — завершити процес або
видалити його, а видалення закрите правом `processes:delete`, тобто доступне
адміністратору, не швачці. Ні таймауту, ні автоматичного звільнення немає.

Ідемпотентності на створення теж немає. Подвійне сканування — рівно те, що
робить людина, коли перший скан не дав видимої реакції, тобто рівно те, що
сталося в серпні 2025 — створює другий процес і з'їдає резерв удруге.

Обидва сценарії вже трапились: «Працівник одночасно запустив 2 процеса на
виконання» (2025-05-23) і, у липні 2025, робота, яку зробили і не дали
закрити: «показало всі п'ять пачок по 50 та не дало нам закрити роботу».

> Резерв кількості без строку давності зупиняє наступну людину на операції. Спостережуваності нуль. Для фабрики час до виявлення дорівнює часу простою, а механізм виявлення сьогодні — це власник, який пише в Telegram.

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

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

| # | Правило, якби його записали | Записано? | Працює? |
| --- | --- | --- | --- |
| S1 | Якість забезпечується локально й добровільно, а не рамками. Доказ `[observed]`: 6 114 прикладів, 95,71% покриття, і жодної джоби, що їх запускає. | ніде не записана | набір чудовий, не захищає нікого |
| S2 | Відомий провал тесту є нормальним станом. Доказ `[observed]`: сім падінь rspec відомі розробникам, задокументовані і терпимі досі. | тіньова — тримається машиною, не документом | працює як норма і руйнує сигнал |
| S3 | Дошка задач — це Telegram. Доказ `[observed]`: 5 735 повідомлень, жодного трекера; дата запуску, грант і виміряна скарга розчинились однаково. | ніде не записана | ні — у каналу немає стану |
| S4 | Архітектурну дисципліну задає фронтенд. Доказ `[observed]`: межі FSD як помилки CI, два ADR, harness на 426 рядків, запінені скіли. | ратифікована у frontend_v2/CLAUDE.md і рамках CI | так — найкраще працююча стратегія проєкту |
| S5 | Backend-контекст живе в приватній пам'яті агента розробника. Доказ `[user]`: кореневого CLAUDE.md чи AGENTS.md немає; на весь репозиторій два harness-артефакти, обидва фронтендові. | ніде не записана | ні — знання не кумулятивне |
| S6 | Коли впровадження буксує — переписуємо. Доказ `[observed]`: v1→v2 з лютого 2026, хвиля 70/44/35 комітів на місяць, переробка моделі матеріалів у липні 2026. З вересня 2026 — переписування мобільного застосунку, тоді як запуску на фабриці так і не було `[user]`. | ніде не записана, але приписова на практиці | продукує якість, не продукує запуск |
| S7 | Продуктову обіцянку ніхто не тримає. Доказ `[observed]`: петля провалилась у серпні 2025, не перевірялась відтоді, резервний шлях виріс поруч, а письмового сліду рішення про це немає `[assumed]`. | за умовчанням — через відсутність рішення | ні |

Рядки оцінюють одне одного. [S4](#s4) —
найздоровіша стратегія проєкту — існує тому, що одна людина взяла її на себе;
[S5](#s5) є її дзеркальною
відсутністю на іншому боці тієї ж кодової бази. А [S2](#s2) є тим, що робить [S1](#s1)
марною: чудовий набір тестів, який ніщо не запускає, захищає рівно нікого.

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

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

**RC1 — Скарзі власника нема куди потрапити**

Роль дошки задач виконує Telegram-канал, у якого немає стану `[observed]`: сказане в ньому
не має власника, дати й способу перевірити виконання. Три однакові випадки:
дата запуску (листопад 2024) — відповіді не було жодного разу; виміряна
вартість входу (грудень 2024) — реакція через вісімнадцять місяців і не та, що
просили; грант на 100 тис. USD (грудень 2025) — тред прожив тиждень.

Що це гарантує: кожен сигнал про вартість чи збій розчиняється в чаті і повертається хіба що повторною скаргою

**RC2 — Немає відповідального за інженерну машину і за послідовність робіт**

Власник не має технічної експертизи, BE-розробник за власним визнанням не бере
на себе лідерство і покращення машини, FE-розробник здатність має, мандату не має, а глибокої BE-експертизи не має
теж. Коли ззовні ніхто не задає порядок денний, кожен інженер робить те, що
вміє добре. Обидва вміють добре інженерію. Тому проєкт виробляє
інженерію.

Що це гарантує: пріоритет задає смак виконавця, а рішення про запуск не ухвалює ніхто

**RC3 — Сигнал є, але він нічого не коштує**

rspec не запускається в CI взагалі; сім падінь rspec відомі, задокументовані і
не позначені навіть як `skip`; покриття не записується. Рамки безпеки і
гігієни залежностей відсутні повністю: ні brakeman, ні bundler-audit, ні
Dependabot `[observed]`.

Справа не в тому, що поломку не видно. Її **бачать**: розробники знали про
падіння, назвали їх і залишили `[user]`. Справа в тому, що
ігнорування нічого не коштує. Червоний білд, який нічого не блокує, є
повідомленням, а не обмеженням, а повідомлення можна перетерпіти.

Що це гарантує: відомий дефект може жити місяцями як прийнятний стан, бо ігнорувати його безплатно

**RC4 — Обіцянку не перевіряють і не знімають**

Петлю «друк → скан → робота» перевіряли один раз, у серпні 2025, і вона
провалилась. Її не полагодили публічно і не зняли. Натомість резервний шлях, де адміністратор вводить дані у вебі, отримав
повноцінну розробку і сім e2e-специфікацій. Продукт перейшов від керування в реальному часі до обліку
постфактум, і в доступних матеріалах немає сліду рішення про це
`[assumed]`. Аудит бачив лише чат і репозиторій; команда зустрічається
в офісі, тож рішення могло бути ухвалене усно і просто ніде не записане. Твердим
є тільки те, що письмового сліду немає.

Що це гарантує: ключове ціннісне твердження продукту лишається неперевіреним нескінченно, а продукт тихо змінює природу

**RC5 — Вхід у систему коштує дорожче, ніж вихід із неї**

Щоб дійти до першого крою, треба створити чотирнадцять сутностей поспіль. Цей
ланцюг записаний власним кодом проєкту, у `cutPrereqs.ts`. `[observed]` Заповнення
однієї специфікації з 18 позицій власник виміряв у 30 хвилин. Жодного механізму масового завантаження немає: ні гема для CSV чи XLSX, ні маршруту
імпорту, ні seed-даних, крім трьох логінів розробників. `[observed]`

У вересні 2026 бар'єр проявився в другій, тоншій формі. Запуск зупинився не на
тому, скільки хвилин забирає специфікація, а на рішенні, як згрупувати
обладнання `[user]`. BE-розробник радить власникові не
перейматись, бо групування завжди можна поміняти. Але в моделі обслуговування
обладнання прив'язане до його підгрупи `[user]`, тож перегрупування
зачіпає і обслуговування. Власник, який зупиняється на цьому рішенні, поводиться
не примхливо, а точно: система робить групування дорогим для зміни
`[inferred]`. Звідси вимога до онбордингу, якої бракувало: перше
завантаження має допускати чернеткову структуру, яку можна переробити без
наслідків.

Що це гарантує: кожна спроба впровадження вмирає до того, як принесе вигоду

**RC6 — Збій тихий і небезпечний одночасно**

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

Що це гарантує: фабрика може стати без жодного сигналу, тому відмова від запуску є раціональною поведінкою власника

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

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

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

**Шість ризиків: імовірність проти помітності**

```mermaid
quadrantChart
  x-axis ймовірність → --> Higher
  y-axis помітність → --> Higher
  quadrant-1 гучні й імовірні
  quadrant-2 гучні, але малоймовірні
  quadrant-3 тихі й малоймовірні
  quadrant-4 тихі й імовірні — найдорожчі
  R1: [0.85, 0.17]
  R3: [0.5, 0.08]
  R6: [0.48, 0.2]
  R4: [0.55, 0.5]
  R5: [0.93, 0.78]
  R2: [0.58, 0.86]
```

*Позиції оцінені з опису кожного ризику в реєстрі нижче, не виміряні.*

**R1 — Конвеєр стає, і ніхто не дізнається**

Якщо станеться: Незавершений процес блокує операцію для наступної робітниці; або подвійний скан з'їдає резерв. Лінія стоїть.
Імовірність: висока в перший же тиждень реальної роботи — обидва сценарії вже траплялись у 2025
Чи помітимо? практично нульова: трекінгу помилок немає, логи Heroku живуть буфером на ~1 500 рядків без пошуку, єдиний надійний канал сигналу — власник пише в Telegram
Вартість відновлення: висока: простій цеху і невиплачена відрядна робота; довіру після цього повертати дорожче, ніж вибудовувати
Що змінило б мою думку: алерт спрацював на штучно заблокованому процесі й був помічений раніше, ніж про це повідомила людина

**R2 — Єдиний носій знань і єдиний кандидат у лідери йде**

Якщо станеться: FE-розробник, який побудував CI, ADR, PRD, e2e, harness, обидва фронтенди і мобільний застосунок, залишає проєкт.
Імовірність: знижена, але не знята: для FE-розробника проєкт — повна зайнятість, і питання 2026-07-30 про пошук роботи виникло саме через брак задач; з вересня 2026 він переписує мобільний застосунок. Завантаження дала нова переробка, а не домовленість, тож ризик повернеться разом із її завершенням
Чи помітимо? висока — про це вже сказано вголос; це рідкісний випадок гучного ризику
Вартість відновлення: критична: майже вся інженерна надбудова відома лише йому, а BE-розробник не знає навіть про існування частини з неї
Що змінило б мою думку: письмова домовленість про завантаження і термін, або передані у репозиторій контекст і доступи

**R3 — Петля скану досі не працює, і це з'ясується вже після онбордингу**

Якщо станеться: Дані завантажили, фабрику підняли, і виявляється, що п'ять серпневих збоїв або частина з них живі.
Імовірність: невідома і саме тому небезпечна: репозиторій мобільного застосунку аудиту недоступний
Чи помітимо? нульова до першого дня в цеху
Вартість відновлення: висока: витрачений онбординг і другий провал довіри власника після дворічної паузи
Що змінило б мою думку: прогін петлі на двох робітницях у реальну зміну з нульовою кількістю збоїв

**R4 — Гроші закінчаться раніше за запуск**

Якщо станеться: Власник припиняє фінансування або воно падає нижче порога, за якого двоє розробників лишаються в проєкті.
Імовірність: середня: суми коливаються, є розрив у виплатах на п'ять місяців, є величина невиплаченого
Чи помітимо? середня — квитанції видно, але справжній рахунок ведеться в таблиці, недоступній аудиту
Вартість відновлення: висока: без FE-розробника проєкт втрачає і машину, і мобільний застосунок
Що змінило б мою думку: пряма відповідь власника на питання, скільки місяців він готовий фінансувати і що станеться далі

**R5 — Власник знову зупиняється на введенні даних**

Якщо станеться: Пілот призначено, але наповнення довідників знову впирається у 30 хвилин на специфікацію, і спроба згасає, як у 2024 і 2026.
Імовірність: справдився: 2026-09-08 запуску на фабриці досі немає, власник зупинився на тому, як згрупувати обладнання; механізму завантаження так само немає
Чи помітимо? висока — це видно за днями мовчання в каналі
Вартість відновлення: середня: втрачений цикл, але дані частково лишаються
Що змінило б мою думку: один виріб повністю завантажено за час, менший за годину сумарної участі власника

**R6 — Мобільний застосунок містить невідомі аудиту дефекти**

Якщо станеться: Третій клієнт системи, носій обіцянки, не прочитаний жодним рядком.
Імовірність: невідома
Чи помітимо? низька
Вартість відновлення: невідома, і сама невідомість є вартістю
Що змінило б мою думку: аудит репозиторію Mobile тією ж дисципліною, що застосована тут

## Реєстр боргів

Ризик може статися; борг оплачується вже зараз, у кожному циклі.

**D1 — rspec поза CI** *(організаційний і технічний)*
6 114 прикладів і 95,71% покриття не захищають жодного злиття. `[observed]` Ціна за цикл: кожна зміна backend іде в main без перевірки, а FE-розробник, який комітить у backend найбільше, робить це власним агентом і без цих рамок.

**D3 — Нуль спостережуваності** *(технічний)*
Трекінгу помилок немає взагалі. Логи Heroku дає, але як буфер: Logplex тримає близько 1 500 рядків і не більше тижня, без пошуку й без збереження, доки не підключено drain або аддон `[web]`. Чи підключений він у цьому проєкті, аудит перевірити не міг: доступу до Heroku не було `[assumed]`. Алертів немає. Ціна за цикл: кожен дефект коштує стільки, скільки часу мине до скарги людини, а після запуску це буде час простою.

**D4 — Дві клієнтські поверхні на дві пари рук** *(стратегічний)*
Веб v2 і мобільний застосунок. frontend/ сюди більше не рахується: його вивели з експлуатації в липні 2026 `[observed]`. Ціна за цикл: кожна доменна зміна множиться на дві поверхні, і мобільна з них не має ані рамок CI, ані аудиту.

**D8 — Нуль рамок безпеки і гігієни залежностей** *(технічний)*
Ні brakeman, ні bundler-audit, ні Dependabot чи Renovate `[observed]`.Що бекенд у CI має: джобу E2E Tests, яка піднімає його в docker і проганяє 303 браузерні сценарії, та окремий воркфлоу, що стежить за номерами міграцій `[observed]`. Тобто це не порожнеча.Але склад цієї перевірки однобокий, і варто вимовити вголос, чого саме бракує. Всі 9 099 рядків Ruby, де живе доменна логіка, зарплата і мультитенантність, дивляться в CI очима браузера: 45,56% гілок, щасливі шляхи, жодного статичного аналізу. Набір, який тримає 82,12% гілок, у CI не запускається; на відомі вразливості гемів не дивиться ніхто; про застарілі залежності не повідомляє ніщо. Ціна за цикл: кожне оновлення гема і кожна зміна помилкової гілки йдуть без перевірки.

**D5 — Backend-контекст існує лише в приватній пам'яті агента** *(знаннєвий)*
Кореневого AGENTS.md чи CLAUDE.md немає. `[observed]` Наслідок уже спостережуваний: FE-розробник пише backend власним агентом, який не має правил BE-розробника, а BE-розробник не знає про існування e2e-набору, ADR і PRD. Ціна за цикл: кожне рішення, ухвалене одним, невидиме другому.

**D6 — Telegram виконує роль дошки задач** *(організаційний)*
5 735 повідомлень без стану, відповідальних і дат `[observed]`. Ціна за цикл: кожен сигнал від власника фабрик має шанс зникнути, і три найдорожчі вже зникли.

**D7 — Резерв кількості без строку давності** *(технічний)*
Незавершений процес блокує операцію, розблокувати може лише адміністратор. `[observed]` Ціна за цикл нульова, поки нема реальних користувачів, і стрибкоподібно зростає в день запуску — тому цей борг варто закрити до нього, а не після.

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

Активи, які платитимуть у кожному наступному циклі. Актив вважається
підтвердженим лише тоді, коли ним справді скористалися повторно, тому проєктні
записи позначені окремо.

**C1 — Набір backend-тестів: 6 114 прикладів, 95,71% рядків, 82,12% гілок** *(працює, але прикриває лише половину змін)*
Це не сплячий актив: BE-розробник запускає набір регулярно `[user]`. Тобто зміни, які пише він, справді перевіряються, і 95,71% покриття роблять свою роботу щодня.Дірка не в наборі, а в його охопленні. Backend змінює не одна людина, а дві, і більше комітів у нього робить FE-розробник — 1 089 проти 588 `[observed]`, причому власним агентом, у якого правил BE-розробника немає `[user]`. Половина змін у домені йде повз звичку, яка захищає другу половину.Ця дірка закривається дешевше за будь-яку іншу в звіті, бо закривати майже нічого не треба: CI вже стоїть і працює, у ньому три джоби плюс окремий воркфлоу для міграцій, і одна з тих джоб уже піднімає бекенд у docker заради e2e `[observed]`. Бракує одної джоби, яка запускає те, що вже написано, на кожен PR [PL2](#pl2). Не інструменту, не набору, не культури — джоби.

**C2 — 303 e2e-тести у 110 файлах, з інфраструктурою фікстур** *(підтверджений — набір проходить повністю)*
Набір живий і підтримується, останній коміт 2026-08-09 `[observed]`. Прогнаний повністю, він проходить цілком: 303 passed, 0 failed за 10 хвилин `[observed]`. Він же дає 79,05% покриття backend і 80,72% frontend [C8](#c8).Одна умова лишається невиконаною, і вона не технічна: правка воркфлоу лежить у робочому дереві, не в комітах. Доки її не заллють, у CI набір і далі не доходить до кінця.

**C3 — Фікстури e2e як еталонний набір для агентного онбордингу** *(підтверджений — найцінніший актив під B3)*
6 474 рядки фікстур створюють увесь домен через публічний API, а cutPrereqs.ts записує ланцюг із чотирнадцяти сутностей до першого крою `[observed]`.Їхня цінність не в тому, що їх можна запустити на реальних даних — не можна [K1](#k1). Вона в тому, що це еталонний набір: відомо-правильний, виконуваний і підтримуваний приклад того, як саме треба створювати кожну сутність, у якому порядку і з якими полями.Для агента це найдорожчий вид входу. Він дає три речі одразу: зразок для наслідування замість здогадів по 138 моделях; оракул, проти якого можна звіряти власний результат; і захист від протухання, бо фікстури ламаються разом з API і чинять опір мовчазному розходженню.Саме тому [B3](#b3) є задачею на тижні, а не на місяці: дослідницьку частину вже виконано і записано кодом.

**C4 — Система вже видає повну технологічну карту виробу** *(підтверджений — це вихід системи, а не вхід)*
PDF-техкарта, яку власник надіслав у чат як «приклад специфікації», — це експорт із самої системи, а не документ фабрики `[user]`. Він доводить, що вихідна сторона працює: система видає технологічну карту одного виробу на 21 операцію з окладами, часом, нормами і вартістю, згруповану по цехах `[observed]`. І принаймні один виріб на момент експорту був заведений у неї повністю `[inferred]`.Чого він не доводить — готовності даних власника. Назви цехів збігаються з довідником дослівно тому, що це той самий довідник. Як виглядають вихідні дані фабрики, аудит не бачив жодного разу: це відкрите питання [Q6](#чого-ми-не-знаємо).

**C8 — e2e дає 79% покриття backend і 81% frontend** *(підтверджений)*
Виміряно 2026-08-14 одним прогоном: backend 79,05% рядків (7 193 / 9 099) і 45,56% гілок, frontend 80,72% рядків (21 634 / 26 800) `[observed]`. Для e2e це високо: 303 браузерні тести ганяють реальні доменні сценарії, а не димові перевірки. Розрив по гілках проти rspec (45,56% проти 82,12%) показує здоровий поділ: e2e йде щасливими шляхами, юніт-специфікації беруть гілки помилок.

**C5 — Документація: PRD, user stories, моделі даних, два ADR** *(підтверджений)*
Сайт на Next.js, підтримується (оновлення 2026-07-25). `[observed]` Це `[observed]` про намір і дизайн, не доказ поведінки, але як носій знання працює.

**C6 — Agent harness фронтенду** *(підтверджений)*
426 рядків CLAUDE.md з правилами, поясненими причинами, запіненими скілами і межами FSD як помилками CI. Найкраще працююча інженерна конструкція проєкту і готовий зразок для кореневого AGENTS.md [E8](#e8).

**C7 — Власник як предметний оракул** *(підтверджений)*
Диктує модель на рівні специфікації, оперує поняттями 1С, реагує на конкретику охоче й точно. Це рідкісний актив: більшість ERP-проєктів гинуть саме через відсутність такої людини.

## Швидкі перемоги

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

| # | Виграш | Живить машину | Агент-день | Статус |
| --- | --- | --- | --- | --- |
| E2 | Джоба rspec у наявному воркфлоу + карантин семи відомих падінь із issue. Виконує [PL2](#pl2). | verification: тести в конвеєрі | 0.5 | — |
| E3 | Записувати покриття обома наборами, а не лише rspec: SimpleCov у групі :test дає 95,71% від юніт-тестів і 79,05% від e2e (той самий SimpleCov у процесі Puma), vite-plugin-istanbul плюс nyc дають 80,72% фронтенду. Артефакт у CI і Codecov роблять [C1](#c1) і [C8](#c8) видимими команді вперше: сьогодні жодної з цих цифр не бачив ніхто. | verification: планка покриття | 0.5 | — |
| E4 | Sentry у backend і в обох фронтендах; сорсмапи вже вивантажуються, приймача бракує. Одразу з інтеграцією Sentry → GitHub Issues, бо саме вона робить [PL1](#pl1) повним: машинний сигнал потрапляє в той самий трекер, що й людський. Закриває половину [D3](#d3). | observability: трекінг помилок | 0.5 | — |
| E5 | Підключити log drain на Heroku. Зараз логи живуть у Logplex: буфер на ~1 500 рядків і щонайбільше тиждень, без пошуку `[web]`. Drain пересилає кожен рядок у зовнішній сервіс, де він зберігається і шукається, тож розбір збою в цеху перестає означати «відтворіть його ще раз». | observability: структуровані логи | 0.2 | — |
| E6 | Окрема база для rspec у тестовому стеку — прибирає deadlock, через який набір не стартує штатно. | verification: швидкий зворотний зв'язок | 0.2 | — |
| E7 | Верхнє поле на етикетці QR — названа розробником причина поганого сканування в серпні 2025. | release safety: якість друку | 0.1 | — |
| E8 | Кореневий AGENTS.md для backend за зразком frontend_v2/CLAUDE.md: правила, команди, пастки, карта доменів. Закриває [D5](#d5). | agent harness: маршрутизація контексту | 1.0 | — |
| E10 | brakeman і bundler-audit як геми плюс дві джоби в наявному воркфлоу. Закриває половину [D8](#d8). | static gates: сканери безпеки | 0.3 | — |
| E11 | .github/dependabot.yml на два екосистеми (bundler і npm). Друга половина [D8](#d8). | dependency hygiene: автоматичні оновлення | 0.2 | — |
| E9 | Скрипт дампу і відновлення продакшн-бази з перевіркою — передумова будь-якого пілоту на реальних даних. | release safety: перевірені бекапи | 0.5 | — |

Десять записів, сумарно ≈4 агенто-дні. Кожен закриває названий у звіті
борг, і жоден не потребує рішення власника. Номер E1 лишається порожнім: та
перемога знята, а номери не перевикористовуються, щоб давніші посилання не
зʼїхали.

## Стратегічні ставки

Ставки оцінено проти прийнятої відповіді на відкрите питання
[Q4](#чого-ми-не-знаємо): припускаємо, що
запас часу **обмежений і невеликий**. Це положення випливає з наявних слідів, а
не з заяви; якщо власник відповість інакше, порядок треба перерахувати.

| # | Ставка | Вердикт | Що закриває | Ціна |
| --- | --- | --- | --- | --- |
| B1 | Зробити збій помітним і безпечним: трекінг помилок, таймаут на резерв незавершеного процесу, ідемпотентність створення процесу, алерт на заблоковану операцію. [R1](#r1) · [RC6](#rc6) · [D3](#d3) · [D7](#d7) | Робити | [R1](#r1) · [RC6](#rc6) · [D3](#d3) · [D7](#d7) | ≈1 тиждень |
| B2 | Один виріб, один цех, паралельно з чинним обліком: завантажити виріб із того джерела, яке власник має насправді ([Q6](#чого-ми-не-знаємо)), руками або агентом. Критерій готовності вже існує: система має видати техкарту, що збігається з паперовою [C4](#c4). Далі пройти повний цикл до закритої зміни й нарахованої зарплати, звіряючи з чинним обліком щодня. [RC4](#rc4) · [RC5](#rc5) · [R3](#r3) · [R5](#r5) | Робити | [RC4](#rc4) · [RC5](#rc5) · [R3](#r3) · [R5](#r5) | ≈6 тижнів, з них 2 у цеху |
| B4 | Призначити відповідального за інженерну машину: одна людина відповідає за CI, деплой, спостережуваність і послідовність робіт — із доступами, які це дозволяють. Кандидат один. [RC2](#rc2) · [R2](#r2) · [D5](#d5) | Робити | [RC2](#rc2) · [R2](#r2) · [D5](#d5) | одна розмова + доступи |
| B3 | Агентний онбординг як повторюваний механізм: скіл, що читає вихідні дані власника — у тому форматі, який з'ясує Q6, — і наповнює фабрику через API, ідемпотентно і з сухим прогоном. Навчається на фікстурах e2e як на еталонному наборі [C3](#c3) і звіряється проти них. [RC5](#rc5) · [C3](#c3) | Чекати на B2 | [RC5](#rc5) · [C3](#c3) | ≈2 тижні після |
| B5 | Мобільний застосунок: або провести аудит тією ж дисципліною, або офіційно визнати веб-режим основним і зняти обіцянку. [R6](#r6) · [RC4](#rc4) | Вирішити | [R6](#r6) · [RC4](#rc4) | ≈3 дні на аудит |
| B7 | Разова консультація QA по наявному набору e2e: чи правильна методологія, яких критичних шляхів бракує. Не наймання — саме зовнішній погляд на те, що вже написано. [C2](#c2) · [R3](#r3) · [RC4](#rc4) | Купити разово | [C2](#c2) · [R3](#r3) · [RC4](#rc4) | кілька годин консультації |
| B6 | Міграція v1→v2 доведена до кінця без цього звіту: збірку v1 прибрали з ланцюга 2026-07-10, сам каталог внесли до .slugignore 2026-07-22. | Зроблено | [D4](#d4) | — |

### Відбір: три ставки на квартал

Робимо [B1](#b1),
[B2](#b2) і
[B4](#b4).

Чому чекають решта:

[B3](#b3) чекає, і це головна зміна
порядку відносно вихідної гіпотези. Вектор, заданий автором аудиту, був саме онбординг, і докази його підтверджують сильніше, ніж очікувалось: власник сам
виміряв 30 хвилин на специфікацію і сам попросив виправлення. Але дешевий вхід
у систему, яка вміє тихо заблокувати роботу і не вміє про це повідомити, лише
швидше приводить до незахищеної точки відмови. Спершу безпека, потім вартість
входу. При цьому мінімальний онбординг не чекає: він входить усередину
[B2](#b2) як завантаження одного
виробу. Механізмом він стає після того, як петля довела свою роботу. Тоді його
масштабують на асортимент, а не будують наосліп.

[B7](#b7) — і варто пояснити,
чому саме разова, а не наймання. Тестувальника в проєкті немає: власник ним не
є, розробники тим більше `[user]`. За інших умов рекомендація була б
очевидною — узяти QA бодай на кілька годин на тиждень. Тут від цього поки варто
утриматися, і не через самі лише гроші:

- бюджет обмежений і без того [R4](#r4);
- покриття автоматичними тестами високе з обох боків
  ([C1](#c1), [C8](#c8)),
  тож найдешевший клас дефектів уже ловить машина;
- і головне — **немає інфраструктури, у якій QA працює**. Без issue tracker
  йому нема куди класти знайдене і нема де бачити стан фічі чи бага
  [D6](#d6). Найняти тестувальника в
  проєкт без трекера означає завести четвертий потік повідомлень у той самий
  чат.

Тому корисна саме разова консультація: досвідчений QA дивиться на наявні
303 тести і каже дві речі, яких зсередини не видно — чи правильна методологія і
яких критичних шляхів бракує. Набори e2e, написані розробниками, регулярно
містять фундаментальні прогалини, очевидні будь-якому тестувальнику й невидимі
авторам. Це вписується в бюджет, не потребує трекера і дає найбільше на вкладену
годину. Після [PL1](#pl1)
питання про постійного QA слід відкрити знову: тоді інфраструктура вже буде.

**[B5](#b5)** чекає
на результат [B2](#b2): пілот сам покаже, чи
петля жива, і дешевше дізнатися це з цеху, ніж із читання коду.

[B6](#b6) зі списку знято: команда зробила
це сама і зробила правильно. Міграція мала названу причину, рамки якості на
кожній фазі та явне перемикання продакшну.

Швидкі перемоги в цьому відборі не беруть участі, вони йдуть паралельно пакетом.

### Найширше заперечення проти головної ставки

Проти [B1](#b1) є сильний
контраргумент, і його варто назвати: це знову інженерна робота, а проєкт хворий
саме на те, що підміняє запуск інженерією. Тиждень на спостережуваність і
таймаути виглядає точно так само, як ті вісімнадцять місяців, коли замість авто-пошуку
з'явився рефакторинг. Ризик, що [B1](#b1) розростеться і поглине квартал, реальний.

Чому ставка все одно лишається першою: її обмежує не обсяг, а дата. Вона існує
тільки як передумова [B2](#b2), і
пілот призначається одночасно з її початком, а не після її завершення. Якщо
через тиждень пілот не стартував, ставка провалилась незалежно від того,
скільки коду написано. Це і є її фальсифікатор.

Друге заперечення сильніше. Можливо, паралельний облік сам знімає ризик [R1](#r1), і
тоді [B1](#b1) до пілоту не потрібна. Почасти це правда: він справді
робить збій нефатальним. Але він не робить його видимим. Без трекінгу помилок
команда дізнається про дефект від власника наступного дня, і на двотижневому
пілоті цикл виправлення зʼїсть половину вікна.

## Пріоритети інвестицій

|  | Зараз (тижні) | Наступний квартал | Горизонт 2 |
| --- | --- | --- | --- |
| **Безпека і машина** | Швидкі перемоги E2‑E11 (≈4 дні) · B1 — збій помітний і безпечний · B4 — відповідальний за машину | — | — |
| **Запуск** | Дата пілоту | B2 — пілот на одному виробі (6 тижнів) | Друга фабрика · Перший зовнішній клієнт |
| **Вартість входу** | — | B3 — агентний онбординг | Онбординг як частина продукту |
| **Клієнти** | — | B5 — рішення щодо мобільного | — |
| **Гроші** | — | — | Самореєстрація і білінг · Трек гранту |

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

## Стратегія еволюції

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

**Вилучення даних із документів** — з `custom` у `product` і далі до
`commodity`, швидко `[web]`. Ринок уже пропонує готові рішення
(OneSchema, Unstract, Spreadsheet Agent від LlamaIndex). Висновок для
[B3](#b3): **не будувати парсер**. Кастомною
лишається лише частина «відобразити на модель SaaS ERP», і вона кастомною й
залишиться, бо схема тут власна.

**Спостережуваність** — давно `commodity`. Будувати щось своє тут було б
класичною помилкою «Build на комодиті», тому [E4](#e4) є покупкою, а не розробкою.

**Нормативи часу на швейні операції** (GSD і подібні) — `product`, ліцензійний
`[web]`. Але для цього проєкту вони не потрібні: нормативи вже є в
голові власника, а для одного виробу вже заведені в систему. Це рідкісний випадок, коли внутрішній актив
дорожчий за ринковий.

### Ринок: ніша зайнята, і зайнята міцніше, ніж здавалося

Оскільки метою є продаж зовнішнім клієнтам, варто сказати, у що цей продукт
виходить. Нижче — веб-огляд від 2026-08-14 `[web]`. Це не
замовлене дослідження ринку: цифри взяті з публічних джерел і сайтів самих
вендорів, тобто частина з них є маркетингом, а не виміряним результатом.

#### Світові гравці, побудовані під ту саму задачу

Найближчий конкурент робить рівно те, що обіцяє SaaS ERP. **Scan ERP**
позиціонується на малі й середні CMT-фабрики (20–500 операторів) і будується
навколо партій, операцій, відрядної оплати та QR-сканування. Ціна публічна і
низька: **$5 за машину на місяць або $0,001 за відстежену одиницю, що
дешевше**, без плати за користувачів і з необмеженою кількістю операторів;
впровадження — два тижні `[web]`. Для фабрики на 50 машин це
близько $250 на місяць.

Поруч ширший ряд: **WFX Cloud ERP** (середній сегмент, ціна лише за запитом),
**Kladana** (від $5 на місяць, є безкоштовний план), **Datatex**,
**MRPeasy**, відкритий **ERPNext**, а зверху **Infor CloudSuite Fashion** і
**NetSuite** у складанні під cut-make-trim. Для порівняння, впровадження
SAP S/4HANA чи Oracle у цій галузі коштує від $50 тис. і триває 6–12 місяців
`[web]`.

Сам ринок росте: ПЗ для дизайну і виробництва одягу оцінюють у $2,95 млрд у
2026 році з CAGR близько 11%, а сегмент apparel management — у $2,25 млрд у
2025 з прогнозом $4,36 млрд до 2034 `[web]`.

#### Український контекст: хто вже стоїть у цій ніші

Локальне галузеве рішення існує, воно зріле і воно не порожнє. **«Швейка 8»**
веде повний цикл від техкарти до продажу, має робоче місце технолога, три
режими розцінки операцій, завдання на розкрій, передачу в цех і розподіл між
швачками — тобто буквально предметне ядро SaaS ERP. Постачальник заявляє
**понад 550 українських підприємств** серед користувачів `[web]`.

Два уточнення, які варто було зробити раніше, бо вони прибирають дві уявні
переваги SaaS ERP.

**Перше: цехове сканування там уже є.** Сторінка продукту описує це прямо —
«штрихкодування техоперацій є у готовому рішенні і найчастіше використовується
на виробництвах, де фіксація виконання операції проходить у момент виконання
операції» `[web]`. Це та сама петля, яку SaaS ERP обіцяє мобільним
застосунком: працівник фіксує операцію в момент її виконання. Отже мобільна
петля [R3](#r3) не є
відмінністю — це очікуваний елемент, який у конкурента відвантажений, а в
SaaS ERP непідтверджений.

**Друге: онбординг там продуктизований і платний.** Він називається
«Примірка» і виглядає так: **2 місяці, 10 годин навчання за 6–7 віддалених
записаних сесій, 11 000 грн** — з порожньою базою на сервері клієнта,
побудовою схеми обліку разом із ним і наскрізним прикладом на його власних
даних. Оплата зараховується в рахунок покупки: повністю від 10 робочих місць,
наполовину від 3 до 9 `[web]`.

Ціна самого продукту: «Швейка 8» коштує 13 500 грн, але купується **тільки
спільно з «BAS Малий бізнес»** за 15 600 грн, разом **29 100 грн за одне
робоче місце** `[web]`.

#### Що таке BAS і чому заборона діє слабше, ніж хотілося б

BAS — це набір конфігурацій на платформі **BAF (Business Automation
Framework)** польської компанії NetHelp, що зʼявилася 2018 року і яку описують
як «наближення до платформи 1С для українського ринку». Системи, що стояли на
1С:Підприємство, після 2021 масово перейшли на BAF і взяли назву BAS
`[web]`. Тобто BAS створювався саме як зʼїзд із 1С — і саме тому
переїзд туди дешевий: та сама парадигма, ті самі інтегратори, та сама звичка
бухгалтера, готові інструменти перенесення довідників і залишків.

Далі цей зʼїзд сам потрапив під заборону. Хронологія: санкції РНБО проти
продуктів BAS ще у 2020; квітень 2023 — санкції проти 1С на десять років, до
2033; 18 липня 2025 — законопроєкт №13505 про заборону ворожих програмних
продуктів зі штрафами до 2% річного обороту; **9 січня 2026 Держспецзвʼязку
опублікувала перелік забороненого ПЗ**, і до кінця місяця в ньому було близько
27 продуктів на BAF, включно з BAS ERP і BAS Бухгалтерія КОРП. Підстава —
«технологічна спорідненість» із 1С `[web]`.

**І тут межу треба тримати чітко, бо від неї залежить, чи є взагалі вікно.**
Заборона стосується **держсектора і критичної інфраструктури**, а не будь-якого
приватного підприємства. Приватна швейна фабрика під неї не підпадає.
Законопроєкт №13505, який поширив би штрафи ширше, зареєстровано, але **не
ухвалено** `[web]`. Тобто юридичного примусу, який виштовхнув би
фабрику зі «Швейки 8», сьогодні немає — є репутаційний і регуляторний фон.

Є ще один поворот, який працює проти нас. Перенесення з 1С проходить гладко на
типових конфігураціях, а ламається на доопрацьованих і галузевих
`[web]`. «Швейка 8» — рівно такий випадок. Це означає, що фабрика
на ній прикута до неї не тільки звичкою, а й вартістю виходу — **і цей замок
тримає її від переходу куди завгодно, включно з SaaS ERP**. Липкість працює на
того, хто вже всередині.

#### Стан самої галузі

Вона стискається, але переорієнтовується. Зайнятість у легкій промисловості
впала зі 133 тисяч у 2019 до 91 тисячі у 2025; від 2022 року 128 підприємств
релокувалися до Закарпаття; виробники скаржаться на зростання цін на
електроенергію, паливо і сировину. Водночас галузева асоціація описує
стратегію як «стати ательє Європи», тобто рух у контрактне виробництво на
європейські бренди `[web]`.

> «Швейка 8» заявляє понад 550 українських підприємств, має штрихкодування техоперацій у готовому рішенні і продуктизований платний онбординг «Примірка» (2 місяці, 11 000 грн, зараховується в покупку). Мобільна петля в цеху — не відмінність SaaS ERP, а очікуваний елемент, який у конкурента відвантажений, а тут непідтверджений.

> Перелік забороненого ПЗ від 9 січня 2026 стосується держсектора і критичної інфраструктури; законопроєкт №13505 зі штрафами не ухвалено. Водночас BAF проєктувався як наближення до 1С, тож переїзд 1С → BAS дешевший за переїзд 1С → SaaS ERP, і хвиля міграції тече переважно туди.

#### Що з цього випливає для стратегії

**Ніша зайнята не платформою, а впровадженнями.** Конкурента тримають у ній
550 підприємств, дилерська мережа і відвантажена функціональність, а не
технологія, на якій він побудований. Тому зміна статусу цієї технології сама
собою нічого не звільняє: заборона не поширюється на приватну фабрику, а
навіть якби поширювалася, найдешевшим виходом для неї лишався б інший продукт
на BAF, а не SaaS ERP.

**Ціна задана ринком, і вона низька.** $5 за машину на місяць у Scan ERP і
29 100 грн разово за робоче місце у «Швейки 8» означають, що юніт-економіка
SaaS ERP мусить зійтися при кількох сотнях доларів на фабрику на місяць.

**А ось тут — несподіване і найкорисніше з усього розділу.** Конкурент, що
працює в цій ніші роками, витрачає на онбординг **два місяці й бере за це
гроші**. Ринок, отже, не вважає довгий онбординг вадою: він вважає його
послугою. Це прямо коригує [RC5](#rc5).
Проблема SaaS ERP не в тому, що онбординг довгий — за галузевою міркою він
нормальний. Проблема в тому, що він **не має ані визначеного кінця, ані ціни,
ані перевірки придатності**: у «Примірці» є порожня база, шість сесій,
наскрізний приклад на даних клієнта і дата, коли все закінчується. У SaaS ERP
немає жодного з цих чотирьох елементів.

Це змінює зміст [B3](#b3).
Ставка лишається, але її мета інша: не «звести онбординг до нуля», а
**зробити його обмеженим, вимірюваним і продаваним**. Агент тут скорочує
частину роботи, а не скасовує процес — і навіть скорочений процес потребує
наскрізного прикладу на даних клієнта, бо саме він є перевіркою придатності
й джерелом зворотного звʼязку.

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

#### Куди має цілитися агентний онбординг

Дотепер [B3](#b3)
описувався як розбір того, що фабрика тримає в себе: Excel, зошити,
PDF-техкарти. Цей розділ дає підстави замінити цільове джерело, і заміна
міняє характер ставки.

Реалістичний зовнішній клієнт SaaS ERP — це не фабрика, яка нічого не
автоматизувала. Це фабрика, яка **вже сидить на «Швейці 8»**: у ніші 550
таких, у них уже є структуровані дані, і в них уже є привід озирнутися.
Тому агентний онбординг варто проєктувати з дугою «міграція зі „Швейки 8“»,
а не «розбір паперу».

Різниця не косметична — вона в тому, чи є ця робота одноразовою, чи
повторюваною:

| дуга                   | джерело                                    | скільки разів працює одна робота     |
| ---------------------- | ------------------------------------------ | ------------------------------------ |
| розбір паперу          | Excel, зошити, PDF — у кожної фабрики свої | щоразу заново: форма інша            |
| міграція зі «Швейки 8» | одна схема, однакова на всіх інсталяціях   | один раз відображення, далі повторно |

Саме тут агент дає непропорційну користь. Структури даних платформи 1С/BAF
відомі своєю непрозорістю: фізичні таблиці мають технічні імена на кшталт
`SC327` і `SP330`, службові поля перемішані з бізнесовими, документ
складається із шапки й кількох табличних частин `[web]`. Людині
писати такий імпортер довго й нудно; агентові — це рівно та задача, яку він
робить добре: дослідити схему, побудувати відображення, показати результат на
наскрізному прикладі. І, на відміну від розбору PDF, це відображення **пишеться
один раз на всю нішу**.

Побічний ефект, який варто назвати окремо: така дуга дає SaaS ERP перевірку
придатності, якої йому бракує. Мігрована база — це чужі дані, чужі назви
операцій, чужі розцінки. Вона одразу показує, де модель SaaS ERP не сходиться з
тим, як галузь насправді веде облік.

> **ЩО ПОТРІБНО, ЩОБ ЦЮ ДУГУ ВЗАГАЛІ ПОЧАТИ**
> Один зразок бази «Швейки 8» — демо, копія від знайомої фабрики або власна інсталяція. Без нього дуга лишається планом на папері, бо схему не можна досліджувати за описом із сайту. Це найдешевша дія з усіх, які цей розділ пропонує, і водночас та, без якої решта не рушить.

> **ЧОГО ЦЕЙ ОГЛЯД НЕ ВСТАНОВИВ**
> Чи є у «Швейки 8» справжній мобільний застосунок, чи штрихкодування працює через настільне робоче місце й сканер; наскільки болісною фабрики вважають привʼязку до BAS; чи присутні Scan ERP, Kladana чи WFX в Україні; скільки з двох фабрик власника вже щось використовують; і головне — чи готовий хтось платити. Усе це вимагає розмов із ринком, а не пошуку. Перед рішенням про позиціонування ці питання дорожчі за будь-яку технічну ставку в цьому звіті.

### Куди це веде: дві фабрики, продуктизація, зовнішні клієнти

Кінцева мета власника ширша за запуск: **вийти на обидві свої фабрики,
продуктизувати систему і продавати її як SaaS реальним клієнтам**
`[user]`. Це змінює вагу однієї зі ставок, тому варто сказати
прямо.

**Що для цього вже є.** Мультитенантність не декларативна, а робоча: 45 із
114 моделей несуть `multi_tenant`, тенант ставиться з `current_user.company`
на кожен запит у `base_controller`, а створення компанії тягне за собою
`after_create`, які засівають типові права, одиниці виміру й системний тип
матеріалу «Тканини» `[observed]`. Тобто ізоляція даних і базовий
провіженинг нового клієнта вже написані — це рідкість для проєкту, який ще не
запустився.

**Чого немає.** Самореєстрації: створення компанії закрите перевіркою
`superuser_check` `[observed]`. Білінгу, тарифів і всього, що
робить SaaS бізнесом, у коді немає взагалі.

**Головний наслідок, і він міняє пріоритет.** У моделі «одна власна фабрика»
вартість наповнення даними є разовою перешкодою на шляху до запуску. У моделі
SaaS вона стає **юніт-економікою кожного клієнта**: 30 хвилин на специфікацію
множаться на асортимент кожної нової фабрики, і платить за це або клієнт своїм
часом, або власник своїм. Те, що зараз виглядає як внутрішній інструмент
[B3](#b3), у цій рамці є частиною продукту, і
саме тією, від якої залежить, скільки коштує підключити наступного клієнта.

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

## Лог рішень

**K1 · rev. 1 · superseded**
~~Фікстури e2e є готовим рушієм онбордингу, що здешевлює головну ставку на порядок~~
Заперечення автора аудиту перевірене й підтверджене: 22 з 26 файлів фікстур імпортують @playwright/test, створення тенанта йде через ендпоінт, закритий if Rails.env.test?, Date.now() вжито 60+ разів для унікалізації, шару відображення з документа немає. Це worker-фікстури Playwright, а не автономний механізм.Але звуження оцінки в першій редакції теж було хибним, у протилежний бік. «Не рушій» не означає «мало користі». Фікстури є еталонним набором: відомо правильним, виконуваним і підтримуваним прикладом створення кожної сутності в потрібному порядку. Для агента це найдорожчий вид входу — зразок, оракул для самоперевірки і захист від протухання в одному [C3](#c3).Тобто правильне формулювання не «зроблено третину», а: непридатне як механізм, найцінніше як еталон. Саме тому [B3](#b3) лишається задачею на тижні.

**K2 · rev. 1 · superseded**
~~Покриття тестами відсутнє, як зазначено у вихідних передумовах~~
Уточнення автора аудиту: передумова була про запис покриття, не про його наявність. Вона вірна — simplecov немає в Gemfile, артефакт не генерується, Codecov не підключений. Вимір 95,71% отримано інструментуванням, якого в проєкті ніколи не існувало, тож команда цієї цифри не бачила. Твердження переформульоване: актив високої якості, невидимий і не підключений до рамок.

**K3 · rev. 1 · standing**
Порядок ставок змінено відносно вихідного вектора: онбординг як механізм переміщено з першої позиції на третю, а мінімальне завантаження одного виробу внесено всередину пілоту. Причина — [RC6](#rc6): здешевлення входу в систему, що вміє мовчки заблокувати роботу, наближає незахищену точку відмови швидше, ніж приносить користь.

**K4 · rev. 1 · standing**
Вихідний вектор цього аудиту — «тертя онбордингу і є причиною незапуску» — задав його автор. Це його теза, а не позиція, задокументована десь у проєкті, і не висновок, до якого аудит дійшов сам.Я спробував її спростувати: якщо тертя справді головне, чому ніхто не пробував бодай ручний пілот на один виріб? Спроба провалилась, і провал зафіксовано тут. 2024-12-17 власник фабрик сам виміряв 30 хвилин на специфікацію з 18 позицій і попросив конкретне виправлення `[observed]`. Тобто теза мала під собою вимір, зроблений двадцять місяців тому людиною, яка мала ним користуватися.Різниця, яку варто тримати: вектор задав автор аудиту, а підтвердив його власник фабрик, і це два незалежні джерела. Якби було лише перше, теза лишилась би гіпотезою людини поруч із проєктом.

**K5 · rev. 1 · standing**
Ризик [R1](#r1) поставлено вище за тертя онбордингу після того, як замовник назвав фабричну рамку: збій тут коштує простою лінії, а не незручності. Це також переоцінює дворічну відмову власника від запуску як раціональну поведінку за відсутності запобіжника, а не як інерцію.

**K6 · rev. 2 · superseded**
~~Два живі фронтенди, і старший досі отримує фічі; ставка B6 — призначити дату, після якої frontend v1 не отримує фіч~~
Живий фронтенд один. .slugignore називає frontend/ виведеним з експлуатації і пояснює чому: збірку v1 прибрали з ланцюга 2026-07-10, сам каталог внесли до .slugignore 2026-07-22, а в public/ немає index.html, тож location / не має що віддавати. Помилка була в тому, що я взяв дату останнього коміту (2026-06-17, справжня фіча) за ознаку живого фронтенду, не перевіривши, чи він розгортається. Наслідки: [D4](#d4) звужено з трьох поверхонь до двох, ставку [B6](#b6) знято як виконану до початку аудиту.Це також пом'якшує читання «теплої ванни»: команда не лише почала міграцію, а й довела її до перемикання продакшну. Варто зафіксувати напрямок помилок цього аудиту: покриття тестами, наявність CI і тепер завершена міграція — усі три рази помилка була на користь суворішої оцінки, ніж заслуговує проєкт.

**K7 · rev. 3 · superseded**
~~Сім падінь rspec — усі в одному кластері, впираються в AWS-креденшели; це середовищні падіння, а не регресії домену~~
Відтворено в ізоляції: падіння реальні, і лише одне справді середовищне (Aws::CloudFront::CookieSigner без ключа). Решта шість — розбіжність специфікацій із кодом (специфікація мокає Video#purge, якого модель не має; чекає поля title і status, яких блупринт не віддає) і одна жива регресія: створення користувача не видає токен скидання, бо after_create із запрошенням закоментовано з 2026-04-01.Тут я помилився в бік поблажливості, а не суворості — на відміну від трьох попередніх випадків. Це варто зафіксувати саме тому: напрямок помилок не є законом, і кожну оцінку треба перевіряти окремо.

**K8 · rev. 3 · superseded**
~~Набір тестів повідомляв про регресію чотири місяці, і ніхто не почув, бо rspec не запускається в CI~~
Сигнал чули. Розробники знали про падіння, задокументували їх і не полагодили; специфікації навіть не позначені як skip `[user]`. Механізм не в детектуванні, а в ціні: ігнорування нічого не коштує. Це переносить вагу з [RC3](#rc3) на [RC1](#rc1) і змінює аргумент за [PL2](#pl2): рамки потрібні як форсинг-функція, а не як детектор. Сама політика від цього не слабшає.

**K9 · rev. 3 · withdrawn**
~~QR не друкується на специфікації; найімовірніше це коректна еволюція задуму, але розбіжність ніде не зафіксована~~
Розбіжності немає. Обіцянка від початку стосувалася маршрутного листа `[user]`, і саме він QR несе. Я прочитав англійське слово specification у першому формулюванні буквально і побудував на цьому знахідку там, де задум і код збігаються.Специфікація QR не має і не потребує: вона шаблон виробу, а не завдання на партію. Решта вузла [RC4](#rc4) не зачеплена — пʼять збоїв петлі в серпні 2025 спостережені прямо в експорті.

**K10 · rev. 3 · standing**
Аудит змінив систему, яку описує. 2026-08-14 при першому прогоні e2e проти стека compose падали 28 специфікацій із 303 — усі в модулях cut, floor, production і equipments. Причина: Sidekiq у контейнері api стукав у localhost:6379, де ніхто не слухає, бо Redis є окремим сервісом compose. Після виправлення: 86 passed на тих самих модулях і 303 passed, 0 failed на повному наборі `[observed]`.Одну річ це залишає нез'ясованою, і чесніше назвати її, ніж домалювати пояснення. .env.test, який CI генерує сам, теж не містить REDIS_URL `[observed]`, тобто конфігурація там була та сама. Проте джоба e2e ніколи не була червоною `[user]`. Чому однакова конфігурація дала різний результат, аудит сказати не може: історія запусків GitHub Actions йому недоступна.Виправлення стоїть у compose/compose-test.yml, поруч із сервісом redis, а не в .env.test. Це навмисно: .env.test не відстежується git-ом і в кожного розробника свій, а в CI його щоразу генерує воркфлоу, тож змінна, яка мусить бути завжди, там завжди й відсутня. У compose вона задається один раз і діє для всіх споживачів цього файлу.Найгостріше те, що сам compose-test.yml цю поломку передбачає в коментарі («Without it the request 500s with Redis::CannotConnectError during e2e runs»). Сервіс додали, змінну не пробросили.Правка лежить у робочому дереві, не в комітах.

**K11 · rev. 3 · withdrawn**
~~У Gemfile дублікат aws-sdk-cloudfront із 2026-05-12; через нього не збирається образ, і саме тому джоба e2e червона три місяці~~
Дефекту не існує. Це артефакт цього аудиту. Гіпотезу висунув автор аудиту, і перевірка її підтвердила.Дублікат є рівно на одному ref — локальному main. На origin/main, origin/staging, локальному staging і heroku/main рядок один `[observed]`. Народився він у мерджі 6ab9f44b9 від 2026-08-12, яким BE-розробник підтягував гілку перед передачею репозиторію. Diff мерджу показує механізм дослівно: кожна сторона мала по одному оголошенню, але на різних рядках — локальна gem "aws-sdk-cloudfront", "~> 1.126", віддалена gem 'aws-sdk-cloudfront', '~> 1'. Git злив обидва без конфлікту, бо текстово вони не перетинались.Що з цього випливає:Твердження «збірка образу зламана три місяці» знято повністю. Догори за течією вона збирається.Моє «відтворив падіння CI локально» відтворювало локальний артефакт, а не стан CI. Формально команда була та сама, ref — інший, і саме ref був вирішальним.Локальний прогін e2e падав з іншої причини — відсутній REDIS_URL [K10](#k10).Правку Gemfile відкочено; у робочому дереві лишається тільки зміна воркфлоу.Урок методологічний і вартий того, щоб бути записаним: я тричі перевірив вміст файлу і жодного разу — гілку, на якій дивлюся. Репозиторій, переданий для аудиту, не є тим самим, що репозиторій команди, і різницю треба перевіряти першою дією, а не останньою.

**K12 · rev. 3 · superseded**
~~Замовник аудиту є BE-розробником проєкту; формулювання «немає дорослого» точне зокрема тому, що автор застосовує його й до себе~~
Це різні люди. Автор аудиту не є backend-розробником і в проєкті не працює: комітів не має, у робочому каналі не пише `[observed]`.Три наслідки, і другий важливіший за саме виправлення:«Немає дорослого» є оцінкою ззовні, а не самовикриттям. Я двічі писав, що автор застосовує формулювання й до себе, бо він один із трьох у таблиці. Його там немає.Провенанс user слабший, ніж я його подавав, там, де йдеться про внутрішню кухню. Твердження про звички BE-розробника, про його необізнаність із CI, ADR і PRD — це свідчення спостерігача про іншу людину, а не учасника про себе. Для бізнес-фактів і рамок цього досить; для тверджень про чужі знання і практики це другий рівень, і підтвердити їх може лише сам розробник.Теза про онбординг має два незалежні джерела: вектор ззовні від автора аудиту і вимір власника фабрик у грудні 2024 [RC5](#rc5). Одного першого було б замало.

**K13 · rev. 3 · superseded**
~~Платформа локальних конкурентів заборонена з січня 2026, отже для SaaS ERP відкрилося вікно; міграція з 1С/BAS є продуктовим клином~~
Огляд ринку спершу прочитано надто оптимістично, і перевірка знесла це прочитання по трьох лініях `[web]`.Заборона не примушує. Перелік Держспецзвʼязку від 9 січня 2026 стосується держсектора і критичної інфраструктури, а не приватного підприємства. Законопроєкт №13505 зі штрафами зареєстровано, але не ухвалено. Приватна швейна фабрика не зобовʼязана нікуди йти.Міграція тече не до нас. BAF будувався як наближення до платформи 1С, тож переїзд 1С → BAS дешевший за переїзд куди завгодно ще: та сама парадигма, ті самі інтегратори, готові інструменти перенесення. Ба більше, галузеві конфігурації переносяться найгірше — а отже фабрика на «Швейці 8» прикута вартістю виходу, і цей замок тримає її від переходу в SaaS ERP так само, як від переходу деінде.Ніша зайнята впровадженнями, а не платформою. У конкурента заявлені 550+ підприємств, дилерська мережа, штрихкодування техоперацій у готовому рішенні і платний продуктизований онбординг. Дві переваги, які звіт приписував SaaS ERP — мобільна петля в цеху й локальність, — виявилися стандартом ніші.Що з цього вціліло і в якому вигляді: сама дуга міграції лишається, але як напрям для агентного онбордингу, а не як ринковий примус. «Швейка 8» є найкращою мішенню саме тому, що її схема одна на всі інсталяції, тобто робота з відображення пишеться раз на нішу — а не тому, що когось звідти виганяють [B3](#b3).

**K14 · rev. 4 · standing**
2026-08-19 автор представив звіт BE-розробникові, а 2026-09-08 попросив у нього відгук `[user]`. Це перше свідчення зсередини команди, і воно зрушило три записи.[R5](#r5) справдився. Запуску на фабриці досі немає; власник зупинився на групуванні обладнання. [RC5](#rc5) отримав другу форму: бар'єр не лише в хвилинах на введення, а й у рішенні, яке модель робить дорогим для зміни.[S6](#s6) спрацювала вдруге. Після v1→v2 — переписування мобільного застосунку. [PL6](#pl6) лишалась запропонованою, тож умову, яку вона ставить, ніхто не перевіряв; рядок у списку спостереження уточнено.[R2](#r2) знижено, але не знято. Для FE-розробника проєкт — повна зайнятість, і питання про пошук роботи виникло через брак задач. Задачі дала S6, а не домовленість.Один факт уточнює термін, а не висновок. Продакшн-середовище існує з самого початку; його базу переписували кілька разів, стейджинг відкрили, вважаючи дані в продакшні вже чистими, а після того їх переписували ще двічі `[user]`. Тому «вийти в продакшн» тут не означає запуску. У цьому звіті запуск — це робота фабрики в системі паралельно з чинним обліком, і її досі не було.Чого розмова не змінила: власника аудит і далі не опитував. У переданій частині розмови BE-розробник заперечує формулювання, а не факти.Попутно у вступі виправлено дві цифри, що застаріли ще до цієї редакції. Частка «знайдено» була записана як «сім десятих» до того, як розділ про ринок додав 22 веб-твердження; тепер це близько половини. Граф мав «45 вузлів» — число з перших днів аудиту; тепер їх 71. Речення «кожна позначка звірена з вузлами» замінено перевірюваним: позначок 108, а вузлів 71, тож відповідність між ними не взаємно однозначна, і стверджувати її не варто.Ще дві поправки знайшлися під час перекладу англійською. Рядок колоди для інвентаря стратегій казав «дві стратегії, жодна не записана», тоді як їх сім і одна, S4, ратифікована в CLAUDE.md і рамках CI; рядок я вписав, розставляючи позначки для колоди, і не звірив із самим блоком. І виноска «Чесність цього звіту» досі казала, що всі слова стейкхолдера походять від автора аудиту, — після розмови 2026-09-08 це вже не так.

**K15 · rev. 4 · superseded**
~~Техкарта власника (PDF) — готовий табличний вхід для онбордингу: джерело даних існує і вже в руках команди~~
PDF-техкарта — експорт із самої системи, а не документ фабрики. Виправлення надійшло від автора аудиту 2026-09-19 `[user]`.Механізм помилки варто записати, бо він повторюваний. Назви цехів у файлі дослівно збігалися з довідником системи, і я прочитав цей збіг як ознаку, що модель підходить фабриці. Насправді збіг був наслідком: документ згенерувала та сама система, з того самого довідника. Ідеальна відповідність між «вхідним» документом і власною лексикою системи мала бути червоним прапорцем кругового доказу, а не підтвердженням.Наслідки:[C4](#c4) перевернувся з вхідного активу на вихідний. Він доводить, що система вміє видати повну техкарту, і тепер слугує критерієм готовності для [B2](#b2).У [B2](#b2) більше немає готового входу. Виріб доведеться завантажувати з того, що власник має насправді.[Q6](#чого-ми-не-знаємо)загострилось: зразка вихідних даних власника аудит не бачив жодного разу. Оцінка [B3](#b3) у два тижні тепер спирається на формат, якого ніхто не знає.Сама ідея, що справжні специфікації фабрики — це водночас корм для онбордингу і дешева перевірка придатності моделі, лишається правильною. Хибним був лише приклад, на якому вона стояла.

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

Рік потому план не спрацював. Ось як — від найімовірнішого.

**P1 — Пілот призначили, і власник знову не почав**

Ранній сигнал: Два тижні тиші в каналі після дати старту; питання власника зміщуються на нові фічі
Що робити: Дата пілоту призначається одночасно з початком B1, а не після її завершення; перший день пілоту не потребує від власника нічого, крім присутності — завантаження одного виробу робить розробник або агент

**P2 — FE-розробник пішов посеред пілоту** *(Найдорожчий сценарій: із ним іде CI, harness, обидва фронтенди і мобільний застосунок)*

Ранній сигнал: Повторне питання про завантаження або про пошук роботи; падіння темпу комітів нижче звичного тижневого рівня
Що робити: B4 (відповідальний за інженерну машину) робиться першою, з доступами; E8 (кореневий AGENTS.md) виносить контекст із приватної пам'яті в репозиторій; письмова домовленість про завантаження на строк пілоту

**P3 — Онбординг зробили першим, петля не запрацювала**

Ранній сигнал: Розмови про парсер техкарт починаються раніше, ніж призначено дату пілоту
Що робити: Порядок зафіксований у K3 і в PL4 (розподіл 70/30): робота на онбординг як механізм не починається, доки не закрито зміну на реальній фабриці

**P4 — Політики ухвалили, і ніхто їх не виконує** *(Найімовірніший тихий провал: у проєкті немає дорослого, який змусить)*

Ранній сигнал: Через місяць після ухвалення жодна політика не була жодного разу застосована
Що робити: Дві політики з шести підняті на детерміністичну сходинку і не потребують волі; решта мають названу дату перегляду, і незастосована політика на перегляді визнається дорогим експериментом, а не продовжується

**P5 — Гроші закінчились посеред пілоту**

Ранній сигнал: Пропущена квитанція; зростання величини невиплаченого в таблиці
Що робити: Питання Q4 (скільки місяців власник готовий фінансувати) задається власнику до старту, а не після; обсяг пілоту (один виріб, один цех, шість тижнів) обраний так, щоб уміститися в найкоротший правдоподібний запас

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

| дата | що перевірити | хто |
| --- | --- | --- |
| 2026-09-13 | [PL2](#pl2): чи рамки увімкнені й чи хоч раз зупинили злиття | технічний відповідальний ([B4](#b4)) |
| 2026-09-13 | Швидкі перемоги [E2](#e2)–[E11](#e11): що відвантажено, що перевищило свій день і що саме чинило опір | технічний відповідальний |
| 2026-10-13 | [PL3](#pl3) і [PL5](#pl5): чи стартував пілот, чи зведено щоденну розбіжність | власник бізнесу |
| 2026-10-13 | [PL4](#pl4): у якій колонці фактично була робота | власник бізнесу |
| 2026-11-13 | [PL1](#pl1): скільки скарг стало issue і скільки з них закрито | технічний відповідальний |
| 2026-11-13 | [C1](#c1) і [C2](#c2): чи перейшли з проєктних у підтверджені | технічний відповідальний |
| 2027-02-13 | [PL6](#pl6): переписування мобільного застосунку почалося у вересні 2026 — чи записані його причина, критерій виходу і дата | технічний відповідальний |

## Чого ми не знаємо

Впорядковано за впливом на рішення: перше питання рухає найбільше.

**[Q6](#чого-ми-не-знаємо) — у якому вигляді й у якому обсязі власник тримає свої дані.**
Це визначає, чи [B3](#b3) є двома тижнями
роботи чи продуктовим модулем. Потрібні числа: скільки виробів в активному
асортименті на кожній фабриці, скільки операцій на виріб, скільки працівників і
машин. І формат: техкарти — це Excel, 1С, PDF чи папір? Єдиний зразок, який
мав аудит, виявився експортом із самої системи `[user]`, тож
зразка вихідних даних власника в аудиту немає зовсім. За 27 місяців у чат не
надіслали **жодного** файлу Excel, тож припущення про «книги в Excel» досі
неперевірене `[assumed]`, і найдорожче з усього неперевіреного.

**[Q8](#чого-ми-не-знаємо) — чи полагоджено петлю скану і чи проганяли її на людях після серпня
2025.** Рухає [R3](#r3) з невідомої в
низьку або високу. Аудит відповісти не може: репозиторію мобільного застосунку
на машині немає. Це названа межа цього звіту, а не пропуск. З вересня 2026
мобільний застосунок переписують `[user]`, тож відповідь
стосуватиметься вже нового застосунку — і петлю варто прогнати на людях до
того, як переписування оголосять завершеним.

**[Q4](#чого-ми-не-знаємо) — скільки місяців власник готовий фінансувати і що станеться далі.**
Одна ця відповідь визначає, чи рекомендація читається як «послідовно за два
квартали», чи як «один цех, один виріб, шість тижнів, і не більше».

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

**Де питати.** Q6, Q4 і Q7 — безпосередньо у власника, у тій самій
Telegram-групі, яка лишається єдиним живим каналом проєкту. Q8 — у
FE-розробника, разом із доступом до репозиторію `Mobile/`.

> **ЧЕСНІСТЬ ЦЬОГО ЗВІТУ**
> Твердження зі слів стейкхолдера `[user]` у цьому звіті мають двох авторів. Більшість сказав автор аудиту, який у проєкті не працює; решту, датовану 2026-09-08, — BE-розробник, якому звіт представили 2026-08-19. Власника фабрик, головну дійову особу, аудит не опитував. Це зміщує звіт передбачувано: сильніше видно те, що видно з боку backend, і слабше — комерційний контекст, реальний обсяг даних і те, як власник сам пояснює дві свої зупинки. Одна розмова з ним, найімовірніше, змінила б [R4](#r4) і [Q6](#чого-ми-не-знаємо), і могла б перевернути висновок про порядок ставок, якби виявилось, що петля скану вже полагоджена й перевірена.