Що вже є · що йде далі

Стан компанії · висновок директора · CJ snapshot · картки агентів · план 7/30 · аномалії

Cockpit зі spec-aligned 40/35/15/10 (Результат/Здоров'я/Шлях/Впровадження)

Алгоритм генерації загальної оцінки 0-100: 40% результат + 35% здоров'я + 15% шлях клієнта + 10% впровадження

Нова сторінка/вкладка: референс (середній день) vs порівнюваний період, накопичено до тієї ж години. Сайт (GA4 погодинно) + Instagram (локальні таблиці), Кількісні/Якісні, шкала відхилення, Висновки/Сигналізація/Тестування, Clarity.

v1: головна воронка + фільтр-пресети + 3 блоки + Clarity. Deferred: підетапи (drilldown), zoom нижньої воронки, custom date-range UX, авто-сигналізація кожні 30 хв через heartbeat → Telegram, LLM-наратив висновків.

Що ми перевіряємо НА БОЦІ сайту: robots.txt дозволи, llms.txt, JSON-LD, server-side рендеринг, мета-теги. 5 рингів + LLM висновок

Оцінка сайту за поведінкою (score /100) + таблиця UX-сигналів (rage/dead clicks, quick backs) з фільтрами, впевненістю та впливом. Числа з Clarity API, тексти — AI

services/clarity-signals.ts: скан 2-3 NL-запити (totals + page×device×source, top 30) раз на добу, кеш 24г у tenant_meta. Score детермінований (рейти на сесію: quick backs/rage/dead/JS/scrolls, формула в коді); LLM (cheap tier) лише назви проблем + confidence/impact + верхній блок (status/що бачимо/чому важливо/порада), заборона вигадувати елементи й числа, fallback-тайтли при відмові LLM. КВОТА Clarity 10 запитів/день: добовий бюджет вкладки 6 (лічильник clarity_signals_calls_<date>), кулдаун форс-оновлення 30 хв, stale-кеш до 7 днів як fallback. UI: донат-score + 3 пояснювальні блоки + 5 summary-карток (сесії/проблеми/критичні/найбільший ризик/найчастіший сигнал) + 4 фільтри + таблиця з пагінацією + «Останні докази» (heatmap/recordings deep-links через tenant_meta clarity_project_id, інлайн-інпут) + кнопка «Відкрити в Microsoft Clarity». Verified: live скан Romashka (43,5к сесій, score 61, 20 сигналів, 3-dim розбивка з джерелами ig/organic) + Playwright скрін. DEEP-LINKS (07-02 v3): «Відкрити» веде на ТОЧНУ проблему в Clarity — реверс-інженерений формат URL (верифіковано на живому demo-проєкті Clarity): impressions?URL=2;6;^regex$ (записи по сторінці), heatmaps?heatmapDeviceType=0|1|2(Mobile/Tablet/PC)&heatmapType=0|1|3|4(Click/Scroll/Dead/Rage)&URL=2;6;^regex$ (карта конкретного типу/пристрою/сторінки). rage/dead/scroll-сигнали → теплокарта, quick backs/JS → відфільтровані записи. Regex-формат Clarity: ^escaped(?.*)?$. ID проєкту Romashka w1ri5ubl76 (з трекінг-тега сайту) записано в staging tenant_meta.

Управлінський екран: проблеми з Clarity + GA4 + HTML-аудиту в одному ранжованому списку. Пріоритет = (вплив на прибуток × впевненість) / складність, формула показана власнику

services/site-priorities.ts + /api/dashboard/site/priorities (кеш 1г; читає ЛИШЕ кеші джерел через їх getter-и — сам зовнішні API не смикає). Нормалізація: Clarity signals (₴-оцінка = events/міс × CR × recovery 0.5/0.25/0.1 × AOV, консервативно, «оцінка не гарантія»; AOV/CR додані в ga-signals payload), GA problems (₴/тиж × 4.33), SEO-аудит checks (critical/warning → критичні/контентні/покращення). КРОС-МАТЧИНГ: Clarity-сторінка ↔ GA-етап (stageOfPath: catalog/product/checkout) + merge → «Підтверджено 2 джерелами», confidence high, ₴ з GA. Типи: критичні/UX/контентні/аналітичні/покращення (детерміновано). Пріоритет-скор = (impactUah|сурогат типу × confW 1/.7/.4) / diffW 1/1.6/2.5 → P1-P3. «Потенційний прибуток» НЕ рахує GA-рядки сегмента «Всі» (дублюють суму сегментів). Резерв слотів: до 4 аналітичних + 6 аудиту (інакше ₴-скоринг їх витісняє). LLM (cheap, purpose site_priorities) лише верхній блок: statusLine/висновок/3 аргументи джерел/порада, БЕЗ сумарних грошей. UI: донат-score (середнє 3 джерел) + 4 стат-картки (проблеми з розбивкою по типах, критичні з кнопкою-фільтром, ≈₴/міс «оцінка не гарантія», джерела даних + сторінок перевірено) + 5 фільтрів + таблиця 11 колонок (джерела-бейджі, чому пріоритет) + футер формули. «Відкрити» перемикає на вкладку-джерело. ОБʼЄДНАНО З «ГОЛОВНОЮ» (07-03 v2, кеш site_priorities_cache_v2): вкладки «Пріоритети» нема — воронка зверху «Головної», під нею пріоритетний блок. Рядок таблиці розгортається у 4 квадранти «Що / Чому / Як виправити / Очікуваний результат» (howToFix+expectedResult — детерміновані плейбуки по джерелу/етапу/типу) + кнопки «Створити ТЗ» (TechSpecModal з ProblemContext) і «Відкрити джерело». З «Головної» прибрані SiteAgentCard і ClarityBlock-ROI (prefetch clarity-insights вимкнено — квота), TechReadiness → нагору SEO + AI. Виправлені баги: session-guard у buildTracking ховав Unassigned-артефакти (знайдено 4 діри трекінгу). site-seo-audit.ts: прибрано import server-only (tsx gotcha §13).

Оцінка воронки за GA4 (score /100) + таблиця просідань конверсії по сегментах (пристрій×канал) проти еталону (минулі 7 днів), z-score аномалії CR/доходу, детерміновані проблеми трекінгу подій. ₴-вплив на тиждень

services/ga-signals.ts + /api/dashboard/site/ga-signals (кеш 6г, ?refresh=1). Метод: 3 GA4-звіти через новий runGa4RawReport (2 dateRanges → синтетичний вимір date_range_0/1; eventName inList view_item/add_to_cart/begin_checkout/purchase; daily 28д). Воронка: Каталог→Картка→Кошик→Оформлення→Покупка по сегментах device×sessionDefaultChannelGroup. Числа лише з коду: CR клампиться ≤100% (інакше мікро-знаменники давали -17233 п.п.), мін. база етапу 20, мін. сегмент 30 сесій; ₴-вплив = |Δ|×база×AOV ±30%; score = 100 − топ-4 просідань − 6×трекінг − 4×аномалії. Трекінг-чеки: view_item без add_to_cart; transactions без begin_checkout (<30%); purchase events vs transactions ×1.25/×0.8. Аномалії: z-score CR і доходу за день проти 21д базлайну, |z|≥2, картки зі спарклайнами (14д). LLM (cheap) лише назви+confidence+верхній блок (status/бачимо/ризик/порада), fallback-тайтли. UI: донат-score (reuse CsScoreDonut) + 5 карток (drop-off/сегмент/відхилення/аномалії/трекінг) + 4 фільтри + таблиця P1-P3 з ₴/тиж + картки аномалій + «Відкрити в GA» (analytics.google.com/#/p<propertyId>). Verified live Romashka: -17.22 п.п. Кошик→Оформлення, z=-3.2 дохід 26.06, трекінг-діра Mobile·Unassigned (206 tx / 3 begin_checkout). Вкладка «Аналітика» стане deprecated — приберемо після приймання. АУДИТ ЦИФР v2 (07-02 PM, кеш-ключ ga_signals_cache_v2): (1) ₴-вплив тепер множиться на P(purchase|entity воронки) — верхні етапи були завищені ~20-50× (Tablet·OrgSocial ₴58-108к → ₴318-591); (2) ранжування просідань за ₴ (не |Δ|×√base) — грошові попереду, мікро-сегменти вниз; (3) «Найгірший сегмент» лише якщо реально впав (else «—»); (4) «Відхилення від еталону» = МЕДІАНА просідань (типове); (5) аномалії = унікальні ДНІ; (6) назви LLM без цифр + трекінг-назви детерміновані (LLM їх ковервкав); (7) трекінг-рядки завжди в списку (5 слотів, P3). Блок аномалій зрозумілий: зелений коридор норми (mean±2σ), пунктир середнього, ЧЕРВОНА точка аномального дня, легенда «норма X–Y», людський текст «26.06 конверсія впала до 0.58% — за межами коридору 0.70–1.27%». + перенесені 3 міні-чарти переходів (Перегляд→Кошик/Кошик→Оформлення/Оформлення→Покупка, SiteFunnelMini reuse, дані funnelDaily 28д з 4-го GA4-звіту date×eventName).

Орден з підозрілим патерном лишається оператору замість автопроведення

Три блокери у /api/sales/orders/inbound: customer comment, pickup delivery, та (новий) сумарна кількість одного SKU > 1 (одна позиція з qty>=2 або кілька рядків того ж product_id)

Кожен статус несе промпт для ШІ; ШІ сам визначає етап діалогу та враховує його промпт у відповіді; таймлайн історії статусів над діалогом

Опційний чекбокс auto-detect (default off). Класифікація через failover-чейн (web) + Haiku (worker). «Оплачено»/«Приховано» лишаються ручними. Історія у dm_thread_status_history (migration 0042) — живить майбутню аналітику. Romashka seeded 12 статусами з sales-script. + Галочка «Будь-яка оплата → Оплачено» біля статусу: payment sweep флипає на будь-який матчений платіж (навіть часткова передоплата 150 грн, без порогу 80%) і silently — без Задач та Telegram (tenant_meta paid_on_any_payment).

ШІ розпізнає мод.ряд/артикул чи назву моделі з фото/скріну/шерд-поста клієнта → знаходить товар у каталозі → блок «Обрані товари» на діалозі → правильні відповіді про розмірну сітку/наявність (числа з каталогу).

Ф1: фід emits <article>+<model_line> → колонки products (mig 0043) + findProductsByCode (article→варіант, model_line→весь ряд) + thread_selected_products (0044) + блок у IG-панелі + ін'єкція у generate. Ф2/3: vision (Haiku) для скрінів + failover для caption-reels; webhook вже віддає CDN-фото+підпис (IG Graph API НЕ потрібен) → recognizeProductOnInbound (код→точно / назва→пошук, conf≥60) auto-add source=ai; прапорець product_recognition_auto (default off, «🤖 авто» у блоці). Числа лише з каталогу. Verified: 2010611→4 кольори «Біссен», «Мелісса»→1010228, квитанція→0. Не верифіковано наживо лише: vision зчитування ВИДРУКУВАНОГО коду з реального фото (механізм перевірено, бракувало фото з кодом). Відповідь тепер ВЕДЕ діалог по розпізнаному товару (питає колір/розмір, називає наявність) і НІКОЛИ не каже «не можу відкрити Instagram/посилання». ПІДБІР РОЗМІРУ: заміри (довжина по спині/обхвати/рукав) яких немає у фіді — скрейпляться зі сторінки товару (feed <link>) per-size + кешуються (product_page_info, mig 0045); ШІ радить розмір за параметрами клієнта + параметрами моделі на фото. Verified: Дарока→XS|S/S|M/M|L заміри, AI рекомендує M|L. Deferred: worker reply path injection (не активний). АУДИТ 2026-06-24 (.planning/AUDIT-ig-product-pipeline.md) + P0-фікси 2026-06-25: (A) base-правило «уточню/перевірю» зроблено умовним — лише коли даних НЕМАЄ в блоках; (B) у блок «Обрані товари» додано Посилання на товар + Фото (раніше ШІ «не бачив посилання»); (C) один активний товар — нове розпізнавання прибирає попередні авто-здогадки (кінець плутанини Дарока+Магнолія). Verified e2e: ШІ дає посилання + точні см одразу, deflectить лише коли даних справді нема. P1 2026-06-25 (resolution-крок перед відповіддю): (D) визначає товар із сигналів — variation_id з лінка / код у тексті / LLM-назва моделі (з опискою «манголія»→Магнолія) → закріплює в «Обрані» або дає хінт дизамбігуації/уточнення; (E) текстова назва товару тригерить пошук БЕЗ кнопки. Статуси: resolved/ambiguous(питає X чи Y)/none(питає назву)/skip(привітання+колаборації не чіпає). + фікс WAF: скрейп замірів з прод-IP (DE) діставав 403 → accept/accept-language headers; error більше не кешується на 30д. + ціна: коли фід дає 0 — скрейпиться зі сторінки (JSON-LD), mig 0046. + ДВА РІВНІ товарів (mig 0047): кандидати (розглядає, P0-C один активний) → ПІДТВЕРДЖЕНІ (клієнт обрав — пін, не чиститься, КІЛЬКА для мульти-замовлення; для суми ШІ бере звідси). Підтвердження: кнопка ✅ у панелі + AI авто коли клієнт каже «беру/оформлюю». + UI 2 колонки (🔎 Пошук | ✅ Підтверджені) + підтверджені = позиції замовлення з обраним КОЛІР+РОЗМІР (dropdown + AI авто-захоплення з діалогу, mig 0048) + Сума замовлення. + AI ВИДАЛЕННЯ товарів на прохання клієнта (single/named детерміновано, мульти/«лиши тільки X» — LLM-резолвер). Ціна у GET/UI: каталог або скрейп.

ШІ сам передає діалог менеджеру: холд треду (пауза) + Telegram-пінг власнику + одне прощальне повідомлення клієнту без продовження продажу

Тригери (детерміновані regex, без LLM, лише останнє вхідне): (1) клієнт просить живу людину/менеджера/оператора або питає «ви бот?»; (2) сильний негатив/скарга (обман, поверніть гроші, поліція/юрист); (3) поза каталогом — повернення/обмін/індивідуальне пошиття/опт; (4) ≥3 послідовних невдалих resolution товару (лічильник resolution_fail_count, «resolved» скидає). Дія: dm_thread_reads.paused_at (існуючий холд — авто-відповіді його вже поважають) + escalated_at/escalation_reason (mig 0049) + Telegram пінг (клієнт/причина/останнє повідомлення/лінк на панель, purpose=other) + hint у промпт «передай менеджеру, не продовжуй продаж». Ідемпотентно: поки escalated_at стоїть — без повторних пінгів. Зняття паузи в панелі скидає ескалацію+лічильник (менеджер розібрався). Verified tsx-симуляцією: 13/13 тригер-кейсів + повний цикл + Telegram delivery ok.

Ескалації (дата поставки, магазин, мульти-пости), пам'ять обговорених товарів, чесність по замірах, бронь при запереченнях, фікс IBAN-тригера, автосинк фіда на проді

Director у chat може делегувати: «передай аналітику питання по ROAS» → ask_specialist(analytics, ...)