Ризики і нотатки
BIGPICTURE v2 · зріз 26.07.2026 · компаньйон-сторінка до огляду і черги рішень. Дев'ять наскрізних ризиків, словник слововжитку, незакриті QA-перевірки і коротко про те, як зроблено сам документ.
Наскрізні ризики R1–R9
R1 · Двоголосся до Френка найгостріше — дата Hyvä
У Френка одночасно дві несумісні версії стану релізу: «відкат, дати нема» (Богдан→Френк, Slack) проти «завтра» (дзвінок тієї ж ночі, Андрій) — і невідомо, чи Андрій знав про відкат, коли обіцяв. Хронічність: чотири зірвані дати поспіль — 10.06 → 01.07 → 10.07 → 26.07. Це збій комунікаційного контуру, не розробки: Френку пишуть щонайменше троє. [Slack 25.07 12:01; _conflicts-platform К2; D09]
Як тримати: один власник комунікації на трек; дата назовні — тільки після перевірки прода і відповіді, хто робить оптимізацію БД; усі відкриті питання до Френка зведені в один пакет (зараз 21 [BIGPICTURE_v2 §4.3]).
R2 · Jira відстає від живих рішень
BALL-644/335/629/660 стоять у Waiting for Review при свіжішій усній реальності. Найгостріше — BALL-644: рішення розвернулось за ~24 год, підсумок дзвінка в тікет не потрапив, і тікет дезінформує виконавця прямо перед апрувом 27.07. Окремо — BALL-660: коментар Френка від 09.06 (Hide Price + Credit Limit) без відповіді ~7 тижнів. [#3; A03; arbitration «Обмеження»]
Як тримати: рішення з дзвінка лягає в тікет протягом 24 год; статус береться тільки з трекера (Plane/Jira), ніколи з переказу чи braindump; при конфлікті свіжий дзвінок б'є трекер за змістом, але факт «запущено / не запущено» перевіряється, а не переказується.
R3 · Scope creep POS
Френк 25.07 попередив прямо: POS «мав бути простим», запитів буде більше. Уже заявлено три носії — web + APK (рішення 25.07) + desktop-Electron (вимога 26.07) — плюс 8 пунктів фідбеку без тікетів; частина перетинається з уже залитим POS-8 (фільтри) і приходить двома каналами (shelf-location). [A08; A09; картка A21; transcripts-recent 25.07]
Як тримати: нарізати всі 8 пунктів одним заходом з явним «прийнято / відкладено» на кожен; Electron не заводити, поки немає відповіді «навіщо desktop», і тільки після доробки POS і живого тесту; не переоткривати вже закрите (APK vs адаптивний view — закрито 25.07).
R4 · Слова, що означають різне
Кілька термінів у корпусі мають по 2–3 незалежні значення з різними власниками («chatbot», «аналітика», NewBMS vs стара BMS, ID-простори карток і рішень) — сплутування дає хибне відчуття «вже готово» там, де готова лише одна з карток. Повна таблиця — у розділі «Словник і правила слововжитку» нижче. [strategy_v2 §4 R4]
Як тримати: не вживати ці слова без уточнення, яке саме значення; перед публікацією — grep-перевірка колізій ID між реєстром v1.3 і v2.
R5 · NSB-потік — половина трекера без видимого власника
Plane NSB = 532 issues — найбільший проєкт workspace (усього 1051 issue у 23 проєктах). 128 у застиглих станах (Backlog 63 · On Hold 37 · Paused 16 · Reopened 12); хто веде — не встановлено (assignee цим знімком не витягувався). BAU в жодній хвилі не планується — він просто з'їдає капасіті, тож будь-яка черга без нього завищена. [plane-snapshot.md; A22]
Як тримати: витягнути assignee по NSB; Богдан розбирає 128 застиглих; РА-30 — чи виносимо BAU в окрему смугу з власною капасіті; не читати обсяг NSB як обсяг міграції Hyvä (завищує «скільки лишилось» у рази); три urgent на шляху покупки — це гейт якості релізу [A01], а не гейт хвилі.
R6 · Бекенди множаться швидше, ніж зводяться
Шість тредів «свій Go-бекенд» (newBMS, NewBMS/раніше UBMS, unified mini-backend DOT-39, паралельний бекенд Діми, портал-мікросервіс, афіліат-мікросервіс) — і нуль зведених карт; афіліатний став шостим за 9 днів (16.07 → зріз 25.07). Точність цитати: джерело-власник (B05) формулює своє завдання як «звести 5 тредів» — шостий додав арбітраж, тож цитувати варто саме як [#5; B05], а не як пряму цитату B05.
Як тримати: нових Go-сервісів не заводити до зведеної карти; поява сьомого — тригер переглянути ступінь уніфікації; координація з бекендом Діми — окреме відкрите рішення [РА-10], не частина карти.
R7 · Планування стоїть на цифрі, якої немає
Оцінка newBMS не зведена в жодному з 4 джерел: 4–7 / ~4–8,5 / 8–16 люд.-міс. — розкид 4×, досі не консолідовано. Паралельно 244 вимоги ERP-партнера проти вікна 9–11 роб. днів — той самий клас розриву, але вже названий і закритий фазуванням (фаза «Демо» ≈50–70 з 244). [legacy-bigpicture.md; B02; B06; erp-partner.md]
Як тримати: консолідація естімейту — окрема задача з датою (РА-28), і в Claude-Code-темпі (дні/тижні), не в класичних людино-місяцях [C-4]; у документі свідомо лише розміри S/M/L/XL, без тривалостей — власних оцінок темпу в джерелах немає, а вигадувати їх було б тим самим дефектом.
R8 · Безпековий хвіст, який ніхто не закрив
53 + 56 + 3 записи чекають ротації; 4 найгарячіші названі поіменно. Статус ротації станом на 26.07 не встановлено для жодного. Окремо: номер BALL-729 розведено — це Q&A-категорія, не носій ключа, — але з цього не випливає, що витоку не було: жодне джерело run_dir не каже, що ключ ротовано. [D06; #16]
Як тримати: єдиний ризик без «правильної хвилі за замовчуванням» — або закривається у W1 як страховка (поточний вибір автора документа), або лишається відкритим свідомо, з підписом власника; мовчазного «забути» немає.
R9 · Шар 2 рекомендації не має прод-контуру новий у v2
Ступінь B спирається на «єдиний BFF перед Magento» (CDC MySQL→Postgres) як на шар, що окупається найшвидше. Фактично: CDC працює в dev і вже живить POS + бота, але сервер «зовсім не prod ready», хостинг GCP vs Varnish не вирішено, прод впирається в чергу Юри — а Юра з 15.07 11:00 повністю на Indigo; «DOT-8 Resolved на папері ≠ підтверджений стан». [B05; B08]
Як тримати: РА-9 (хостинг + прод-сервер) стоїть у W1 з явно названою колізією за Юру; верифікація реального стану DOT-8, а не поля статусу, — задача команди; якщо Юру не вивільнити — чесно перенести шар 2 і переписати рекомендацію, а не залишати обіцянку без носія.
Словник і правила слововжитку
Терміни, на яких у корпусі найчастіше ламається читання — з тим, що саме НЕ мається на увазі.
| Термін | Що означає | Що НЕ означає | Реф |
|---|---|---|---|
| NewBMS / стара BMS / | NewBMS — кодова назва власної платформи Axiom, два флейвори (Light, Heavy) | НЕ стара BMS (BoostMyShop-модуль усередині Magento, який якраз виносимо). Термін «UBMS» знято — це та сама платформа, що й NewBMS, не інша | C-5 п.1 |
| «chatbot» | Три різні речі: (1) Q&A-канон BALL-711 (18 з 26 категорій без відповіді Метта); (2) віджет-показ Френку, прив'язаний до релізу Hyvä; (3) нова мультимодальна AI-система замовлень — окремий продукт (картка C04) | «Все зрозуміло» стосується щонайбільше базового вже задеплоєного бота (1) і НЕ приймається як статус для (2) чи (3) | strategy_v2 §4 R4 |
| «аналітика» | Три різні речі: (1) командна BI-інфраструктура (COGS не працює); (2) готовий Python-дашборд v1–v8 (працює); (3) COGS-репортинг для Френка всередині BMS | «COGS не працює» стосується (1) і (3) і НЕ спростовує (2) — головна пастка читання | strategy_v2 §4 R4 |
| Hive → Hyvä | На слух «Hive» = Hyvä — фронтенд-тема Magento; та сама плутанина в іменах серверів (devhyvagcp, infra-hyvagcp) | Не окремий продукт і не назва компанії | BIGPICTURE_v2 §5 |
| BRSW | brsw.atlassian.net = Jira-простір Balloons (тікети BALL-*) | НЕ податковий проєкт BRSW (Track A/B) — той поза скоупом BIGPICTURE v2, не плутати | strategy_v2 §4 R4; registry_v1 «Межі скоупу v2» |
| RAG | Два різні: (1) товарний пошук BOL (картка A15); (2) корпоративна база знань (картка C05) | Не одне й те саме — різні власники, різні корпуси; писати «товарний RAG» / «RAG бази знань» | strategy_v2 §4 R4 |
| NSB | Потік підтримки сторфронту — Plane-проєкт, 532 issues | НЕ NEWBMS (платформа); префікс NSB- трапляється і в PR стороннього клієнтського сайту — завжди з номером і контекстом | strategy_v2 §4 R4; A22 |
| ID-простори | У цьому документі: рішення Андрія = РА-* (кирилицею), картки реєстру = A**/B**/C**/D** (латиницею); Р-01…Р-16 — окрема внутрішня нумерація §18 ТЗ ERP-партнера | A10/A11/A12 у реєстрі v1.3 і у v2 означають РІЗНЕ — старий ID тільки з префіксом v1.3:; РА-* не плутати з Р-* партнера | strategy_v2 §4 R4 |
| «07–10.08» | Перерахунок реєстру вимог ERP-партнера від 27.07 на вікні 9–11 роб. днів | НЕ дата, названа партнеру («десь тижні через два»); писати «оцінка ~07–10.08», не будувати на ній аргументів «неможливо за датами» | strategy_v2 §4 R4; B03 |
| «FrenkyCore» | Термін згадувався в матеріалах начитки | Ніде не визначений, порожній термін — нічого на ньому не будувати | strategy_v2 §4 R4 |
Незакриті перевірки
Спот-фактчек qa-facts.md перевірив 15 найнавантаженіших тверджень strategy_v2.md (§1, §2, §4): 12 підтверджено дослівно, 3 нижче — розбіжність або розрив, який рендер має закривати свідомо, а не мовчки. [qa-facts.md]
| Що перевірити | Чому висить | Реф |
|---|---|---|
| Версія Angular у картці A06 | README репо каже «Angular 19 SSR», але лог комітів того ж репо — «Angular 21 upgrade» (10.06); застаріле «19» пройшло ланцюг github-a.md → registry_v1.md (A06) → strategy_v2.md і на дату рендеру не виправлене в чернетках. Наслідок: аргумент «розрив у 3 мажорні версії до POS (Angular 22)» фактично ~1 версія (21→22) — суттєво слабший ризик, ніж написано | qa-facts №5; github-a.md |
| newBMS-естімейт без Claude-Code-темпу | Розкид 4–7 / ~4–8,5 / 8–16 люд.-міс. підтверджений у всіх 4 джерелах, але §1/§4 strategy_v2 подають його без застереження C-4 про масштаб у днях/тижнях Claude-Code-темпу — файл поправок оновлено 11:59, strategy_v2.md написано раніше, 04:49; чернетка фізично не встигла. Цей рендер застереження вже застосовує, попередні чернетки — ще ні | qa-facts №9, №15; C-4 |
| «Сценарій 1/2» межі платформи | strategy_v2 §1–§2 досі описує межу платформи як «Сценарій 1 (ERP партнера = перша інсталяція UBMS)» / «Сценарій 2 (окремий продукт)»; пізніша й авторитетна C-5 замінює це конструкцією двох флейворів NewBMS-Light/Heavy (два окремі кодові проєкти на старті). Чернетка ще не перероблена — той самий хронологічний розрив (04:49 vs 11:59) | qa-facts, процесна примітка; C-5 п.1–2 |
| «Штрихкоди Діми» | Згадка фігурувала в ресурсних таблицях чернеток; на прямому уточненні Андрій відповів «хз» — штрихкоди Діми — знято як факт, джерело не підтверджене. Лишається лише приміткою «згадка без підтвердженого джерела», прибрано з ресурсних таблиць | C-5 п.7 |
Методологія рану
Чотири рої агентів, усе 26.07: WF-1 HARVEST (24 агенти: 3×Opus начитка A/B/детектив + 17×Sonnet харвестерів + 2 аудитори + 2 конфлікт-скани) → WF-2 REGISTRY (11: архітектор, 6 писарів батчами, арбітраж конфліктів, редактор-збирач, критик повноти, фіксер) → WF-3 STRATEGY (3: стратег → критик наосліп → фіксер) → WF-4/5 QA+RENDER (~9: 2×QA — дельта рішень 22 карток і факт-спотчек 15 тверджень — core-канон, 5 HTML-сторінок, фінальний аудитор). [STATE.md]
Палітра джерел (кожен пункт — зріз або явне «порожньо»): начитка 26.07 дослівно · Jira (BALL-*) · Plane self-hosted (23 проєкти, 1051 issue) · GitHub · Slack · транскрипти дзвінків і звіти · канони та ТЗ у Vibe099/_global/ · дос'є трьох машин · пам'ять і хендофи · спадковий BIGPICTURE v1.3. [BIGPICTURE_v2 §6]
Дати зрізів: начитка й факти — ранок 26.07; strategy_v2.md записано 26.07 04:49; _corrections-20260726.md (авторитетний шар) оновлювався до 26.07 11:59; QA факт-спотчек — 26.07 12:14; QA дельта рішень — 26.07 12:17; цей рендер — пізніше того самого дня. Розрив між 04:49 і 11:59 — причина трьох незакритих перевірок вище, не помилка факту.
Проміжні артефакти — у ~/Documents/Vibe099/_global/bigpicture-20260726/: facts/ (23 зрізи + _corrections-20260726.md = авторитетний шар) · drafts/registry_v1.md (311КБ, 48 карток) · drafts/arbitration.md (57КБ) · drafts/strategy_v2.md (114КБ) · drafts/qa-*.md · raw/braindump-20260726-verbatim.md.
Дисципліна фактів. Кожне твердження має реф; де джерела розходяться — розбіжність показана, а не згладжена; UNVERIFIED означає «сліду в джерелах немає», а не «неправда». Три місця, де цей канон свідомо виправляє чернетку: Angular 19 → фактично 21 [qa-facts №5] · людино-місяці → Claude-Code-темп [C-4] · «Сценарій 1/2» межі платформи → знято конструкцією двох флейворів [C-5].
Що це НЕ. Не енциклопедія (повні картки — в реєстрі), не план з датами, не фінансовий документ. Після пріоритетів від колег — другий прохід окремим раном. [BIGPICTURE_v2 §6]