fix(owner): додати відсутні залежності vue-macros / vite-plugin-vue-layouts-next

.cspell.json

@@ -106,6 +106,7 @@
     "еміт",
     "еміти",
     "ендпоінти",
+    "епhemeral",
     "ескальовано",
     "ескалювати",
     "заготовками",
@@ -129,6 +130,7 @@
     "крейт",
     "крейта",
     "крейтом",
+    "крейту",
     "леджер",
     "лейбл",
     "лендинг",
@@ -141,12 +143,15 @@
     "метаключ",
     "метаключі",
     "монтирує",
+    "напівналаштованих",
     "напр",
     "нездекларований",
     "нездекларованих",
     "неіснуючого",
     "нерядки",
     "ноди",
+    "одиночного",
+    "одиночної",
     "онбординг",
     "Онбординг",
     "онбордингу",
@@ -196,6 +201,7 @@
     "скоуп",
     "скоупи",
     "скоупитись",
+    "скоупів",
     "скоупом",
     "скоупу",
     "спавнені",
@@ -205,6 +211,7 @@
     "таймлайну",
     "таски",
     "тега",
+    "темізаційних",
     "тернарник",
     "тірів",
     "тріпа",
@@ -214,6 +221,7 @@
     "фейлів",
     "фейлу",
     "флоу",
+    "фронта",
     "фронтенда",
     "фронтматері",
     "хоста",

app/.changes/260727-1538.md

@@ -0,0 +1,5 @@
+---
+bump: minor
+section: Changed
+---
+Нема змін

app/src/composables/docs/use-acp-agent.md

@@ -3,28 +3,33 @@ type: JS Module
 title: use-acp-agent.js
 resource: app/src/composables/use-acp-agent.js
 docgen:
-  crc: 03ee3c4c
+  crc: e2987279
   model: openai-codex/gpt-5.4-mini
   tier: cloud-min
   score: 100
-  issues: judge:inaccurate:0.98
+  issues: judge-refine:kept-original,judge:inaccurate:0.98
   judgeModel: openai-codex/gpt-5.4-mini
 ---
 
 ## Огляд
 
-useAcpAgent надає застосунку доступ до ACP agent-інтеграції в межах поточного робочого контексту й робить це як read-only механізм без запису у ФС чи БД. Він орієнтується на settings.json і поводиться fail-safe: перехоплює помилки та не пропускає винятки назовні.
+Єдина точка входу для in-app ACP-agent gateway, що збирає готовий агентський контур для роботи з каталогом інструментів і сценаріями керування задачами.
+
+Працює як fail-safe адаптер: не кидає винятків назовні й не ламає користувацький потік під час помилок.
+
+Передбачає локальний fallback поза реальним Tauri-runtime, щоб агентський контур лишався доступним у середовищах без повноцінного застосункового runtime.
 
 ## Поведінка
 
-1. `useAcpAgent` збирає in-app ACP agent gateway для роботи з агентами в межах поточного робочого контексту.
-2. `useAcpAgent` підставляє каталоги можливостей і базовий `cwd`, щоб агент міг стартувати з безпечного дефолта навіть поза реальним Tauri runtime.
-3. `useAcpAgent` підключає підтримувані агентські профілі: `codex`, `cursor` і `pi`, щоб у застосунку можна було вибирати потрібний режим роботи без ручної оркестрації.
-4. `useAcpAgent` враховує, що `codex` і `cursor` отримують явні запускові налаштування, а `pi` орієнтується на власний `settings.json`, тому локальні профілі не дублюють його модельні налаштування.
-5. `useAcpAgent` повертає готовий gateway для читання контексту, виконання запитів, відповіді та погодження дій, не змінюючи дані в файловій системі чи базі.
-6. `useAcpAgent` працює fail-safe: якщо зовнішнє середовище недоступне, він не пробиває помилку назовні та зберігає працездатність модуля.
+1. useAcpAgent піднімає єдину точку входу для in-app ACP-agent gateway і повертає готовий до роботи агентський контур для взаємодії з каталогом інструментів та сценаріями керування задачами.
+2. Якщо застосунок працює поза реальним Tauri-runtime, useAcpAgent безпечно переходить на локальний fallback, щоб відсутність домашньої теки не зупинила весь модульний граф.
+3. useAcpAgent обирає базовий контекст запуску для агента з поточного середовища, а не з нав’язаного system prompt, щоб агент сам зчитував робочий контекст проєкту з наявних файлів у cwd.
+4. useAcpAgent передає агенту набір доступних дій і тримає в центрі сценарій роботи з кількома незалежно виявленими робочими просторами, де фактичний tasksDir визначається з вхідних даних і резолвиться через workspace-інструменти.
+5. useAcpAgent підбирає конфігурацію для різних агентських бекендів, включно з Codex, Cursor і pi, щоб інтерфейс застосунку міг працювати з кількома провайдерами без окремої логіки виклику.
+6. useAcpAgent для pi покладається на власні налаштування агента з settings.json, тому рівень моделі тут не перевизначається з боку застосунку.
+7. useAcpAgent працює fail-safe: помилки на старті або під час підготовки контексту не пробиваються назовні, щоб користувацький потік не ламався через технічний збій ініціалізації.
 
 ## Гарантії поведінки
 
-- Read-only: не виконує операцій запису (ФС/БД).
+- Власних операцій запису (ФС/БД) у файлі немає; виклики імпортованих модулів можуть писати.
 - Перехоплює помилки і не пропускає винятків назовні (fail-safe).

owner/.changes/260727-1538.md

@@ -0,0 +1,5 @@
+---
+bump: minor
+section: Changed
+---
+Додано vite-plugin-vue-layouts-next та vue-macros до залежностей

owner/docs/vite.config.md

@@ -3,30 +3,26 @@ type: JS Module
 title: vite.config.js
 resource: owner/vite.config.js
 docgen:
-  crc: c5d97a75
-  model: openai-codex/gpt-5.4-mini
-  tier: cloud-min
+  crc: f5f96e2a
+  model: openai-codex/gpt-5.5
+  tier: cloud-avg
   score: 100
-  issues: judge:inaccurate:0.98
   judgeModel: openai-codex/gpt-5.4-mini
 ---
 
 ## Огляд
 
-Файл формує dev-конфігурацію Vite для фронтенда застосунку: визначає налаштування середовища для роботи в режимі розробки та звертається до мережі під час виконання. Це потрібно, щоб Vite отримував очікувані параметри конфігурації під час запуску згідно з <https://vite.dev/config/>.
+Конфігурує dev-середовище на Vite, підключаючи Vue/Quasar-інфраструктуру сторінок і окремий dev-сервер. Існує, щоб dev-сервер працював на власному dev-порті.
 
 ## Поведінка
 
-1. Збирає Vite-конфігурацію для dev-режиму застосунку, щоб підняти фронтенд із потрібними плагінами та інтеграціями.
-2. Підключає автоматичний імпорт Vue-API, щоб зменшити ручні імпорти в компонентах.
-3. Увімкнює Vue-підтримку для шаблонів і коректної обробки asset URL.
-4. Додає Quasar-інтеграцію з підстановкою спільних Sass-змінних, щоб уніфікувати тему й стилі.
-5. Вимикає очистку екрана dev-сервера, щоб консольний контекст залишався доступним під час роботи.
-6. Запускає окремий dev-server на порту 1430, щоб він не конфліктував із app на 1420 і міг працювати поруч.
-7. За потреби прив’язує сервер і HMR до хоста з `TAURI_DEV_HOST`, щоб коректно працювати в Tauri-сценаріях.
-8. Ігнорує зміни в `src-tauri`, щоб фронтенд-перезбірка не реагувала на бекендову частину проєкту.
-9. Орієнтується на офіційну конфігурацію Vite: <https://vite.dev/config/>
+1. Налаштовує dev-збірку на основі Vite-конфігурації: <https://vite.dev/config/>.
+2. Підключає підтримку Vue, макросів Vue, автоматичних імпортів Vue API, layout-ів і Quasar-стилізації, щоб сторінки збиралися з очікуваною UI-інфраструктурою.
+3. Використовує файл змінних Quasar як єдине джерело темізаційних значень для Quasar-компонентів.
+4. Запускає dev-сервер на окремому фіксованому порту, щоб він міг працювати паралельно з основним app-сервером без конфлікту портів.
+5. За наявності хоста для Tauri задає host для dev-сервера й HMR у Tauri-середовищі; без нього залишає локальний режим.
+6. Ігнорує зміни в Tauri-частині під час спостереження за файлами, щоб фронтенд-dev-сервер не перезапускався через зміни бекенд-обгортки.
 
 ## Гарантії поведінки
 
-- Read-only: не виконує операцій запису (ФС/БД).
+- Власних операцій запису (ФС/БД) у файлі немає; виклики імпортованих модулів можуть писати.

owner/owner-llm/examples/docs/staff_brief_live.md

@@ -3,35 +3,35 @@ type: Rust Module
 title: staff_brief_live.rs
 resource: owner/owner-llm/examples/staff_brief_live.rs
 docgen:
-  crc: 64b5bf05
+  crc: b74e1236
   model: openai-codex/gpt-5.5
   tier: cloud-avg
   score: 100
-  issues: judge:inaccurate:0.98
+  issues: judge-refine:kept-original,judge:inaccurate:0.98
   judgeModel: openai-codex/gpt-5.4-mini
 ---
 
 ## Огляд
 
-Файл запускає ручний live smoke test для owner one-shot маршруту `use-staff.js` → `llm_one_shot` → `owner_llm::one_shot`, щоб довести, що Tauri-command отримує реальну відповідь через LLM cascade від локального omlx-сервера, а не лише компілюється. Запуск: `cargo run --example staff_brief_live -p owner-llm`. Тест читає `OMLX_BASE_URL`, `OMLX_MODEL`, `OMLX_API_KEY` з оточення або використовує типовий endpoint `http://127.0.0.1:8000/v1` і модель `gemma-4-e4b-it-OptiQ-4bit`, виводить отриманий staff-бриф чи причину провалу, перехоплює помилки й не випускає винятки назовні, не змінюючи файли або базу даних.
+Живий smoke-сценарій вручну перевіряє, що штабний одноразовий LLM-виклик доходить до реального локального omlx-сервера тим самим маршрутом, що й продуктова інтеграція: `use-staff.js` → `llm_one_shot` → `owner_llm::one_shot`. Він потрібен, щоб підтвердити, що Tauri-command відповідає через каскад, а не лише компілюється.
 
-## Поведінка
+Запуск: `cargo run --example staff_brief_live -p owner-llm`. Сценарій читає `OMLX_BASE_URL`, `OMLX_MODEL` і `OMLX_API_KEY` з env; без явних значень використовує типовий локальний omlx `http://127.0.0.1:8000/v1` і модель `gemma-4-e4b-it-OptiQ-4bit`, як в owner-онбордингу. Помилки перехоплюються без винятків назовні.
 
-1. Запускає живу перевірку інтеграції owner-каскаду з локальним omlx-сервером, щоб підтвердити реальну відповідь LLM, а не лише успішну компіляцію.
+## Поведінка
 
-2. Бере адресу сервера, модель і ключ доступу з оточення; якщо значення не задані, використовує типовий локальний endpoint `http://127.0.0.1:8000/v1` і дефолтну модель owner-онбордингу.
+1. Запускає живу перевірку інтеграції зі штабним LLM-шляхом, щоб підтвердити реальну відповідь через каскад, а не лише успішну компіляцію.
 
-3. Формує короткий staff-запит про рішення для вузла, що очікує approve плану декомпозиції, щоб перевірити той самий бізнес-сценарій, який проходить через Tauri-command.
+2. Бере адресу локального omlx-сервера, модель і ключ доступу з оточення; якщо адресу не задано, використовує типовий локальний endpoint `http://127.0.0.1:8000/v1`.
 
-4. Надсилає запит шляхом owner one-shot через LLM cascade, еквівалентним маршруту `use-staff.js` → `llm_one_shot` → `owner_llm::one_shot`.
+3. Формує короткий штабний запит про рішення для вузла, який очікує approval плану декомпозиції.
 
-5. У разі успіху виводить отриманий бриф і його довжину, щоб оператор бачив, що відповідь реально повернулась від моделі.
+4. Надсилає запит через той самий шлях, який використовує owner-онбординг і Tauri-command для одноразового LLM-виклику.
 
-6. У разі помилки виводить причину провалу й завершує процес з помилковим статусом, не передаючи винятки назовні.
+5. У разі успіху виводить отриману відповідь і її довжину, щоб оператор міг швидко перевірити наявність змістовного результату.
 
-7. Не змінює файли чи базу даних; перевірка витрачає реальну LLM-квоту й залежить від доступності локального omlx-сервера.
+6. У разі помилки явно повідомляє про провал і завершує процес з кодом помилки, щоб smoke-перевірка не виглядала успішною помилково.
 
 ## Гарантії поведінки
 
-- Read-only: не виконує операцій запису (ФС/БД).
+- Власних операцій запису (ФС/БД) у файлі немає; виклики імпортованих модулів можуть писати.
 - Перехоплює помилки і не пропускає винятків назовні (fail-safe).