diff --git a/.cspell.json b/.cspell.json index 682ac11..7756f2e 100644 --- a/.cspell.json +++ b/.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 @@ "фейлів", "фейлу", "флоу", + "фронта", "фронтенда", "фронтматері", "хоста", diff --git a/app/.changes/260727-1538.md b/app/.changes/260727-1538.md new file mode 100644 index 0000000..c75e4a0 --- /dev/null +++ b/app/.changes/260727-1538.md @@ -0,0 +1,5 @@ +--- +bump: minor +section: Changed +--- +Нема змін diff --git a/app/src/composables/docs/use-acp-agent.md b/app/src/composables/docs/use-acp-agent.md index 1aa4182..aa530f7 100644 --- a/app/src/composables/docs/use-acp-agent.md +++ b/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). diff --git a/bun.lock b/bun.lock index aa4ce0d..31f9347 100644 --- a/bun.lock +++ b/bun.lock @@ -19,7 +19,7 @@ }, "app": { "name": "app", - "version": "0.6.6", + "version": "0.6.10", "dependencies": { "@7n/tauri-components": "^0.13.9", "@quasar/extras": "^2.0.2", @@ -51,7 +51,7 @@ }, "owner": { "name": "owner", - "version": "0.13.0", + "version": "0.16.2", "dependencies": { "@7n/tauri-components": "^0.12.0", "@quasar/extras": "^2.0.2", @@ -74,6 +74,8 @@ "sass": "^1.101.0", "unplugin-auto-import": "^21.0.0", "vite": "^8.1.4", + "vite-plugin-vue-layouts-next": "^2.1.0", + "vue-macros": "^3.1.4", }, }, }, diff --git a/owner/.changes/260727-1538.md b/owner/.changes/260727-1538.md new file mode 100644 index 0000000..d7c15a6 --- /dev/null +++ b/owner/.changes/260727-1538.md @@ -0,0 +1,5 @@ +--- +bump: minor +section: Changed +--- +Додано vite-plugin-vue-layouts-next та vue-macros до залежностей diff --git a/owner/docs/vite.config.md b/owner/docs/vite.config.md index bebef4c..052b835 100644 --- a/owner/docs/vite.config.md +++ b/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 отримував очікувані параметри конфігурації під час запуску згідно з . +Конфігурує 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: +1. Налаштовує dev-збірку на основі Vite-конфігурації: . +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: не виконує операцій запису (ФС/БД). +- Власних операцій запису (ФС/БД) у файлі немає; виклики імпортованих модулів можуть писати. diff --git a/owner/owner-llm/examples/docs/staff_brief_live.md b/owner/owner-llm/examples/docs/staff_brief_live.md index f8c828d..afac382 100644 --- a/owner/owner-llm/examples/docs/staff_brief_live.md +++ b/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). diff --git a/owner/owner-llm/src/docs/lib.md b/owner/owner-llm/src/docs/lib.md index fff940c..fc7d2a4 100644 --- a/owner/owner-llm/src/docs/lib.md +++ b/owner/owner-llm/src/docs/lib.md @@ -3,42 +3,35 @@ type: Rust Module title: lib.rs resource: owner/owner-llm/src/lib.rs docgen: - crc: 23a2e784 - model: omlx/gemma-4-e4b-it-OptiQ-4bit + crc: 101eb299 + model: openai-codex/gpt-5.5 + tier: cloud-avg score: 100 - issues: judge:inaccurate:0.99 + issues: judge-refine:kept-original,judge:inaccurate:0.99 judgeModel: openai-codex/gpt-5.4-mini --- ## Огляд -Цей модуль надає тонкий шар над крейтом `llm-cascade`, що дозволяє виконувати одноразові виклики до мовних моделей. Він є read-only, не здійснює записів у файлову систему чи базу даних. +Файл надає JS-шару owner дві ізольовані точки входу до `llm-cascade`: `one_shot` для одного звичайного LLM-запиту та `one_shot_acp` для одного ACP-запиту. Він існує як тонкий, незалежний від Tauri шар, який зберігає fail-fast контракт крейта: один запит дає рівно один нижчий виклик, а помилки повертаються як контрольований результат. -Поведінка -Публічна функція `one_shot` виконує один виклик LLM-тиру, використовуючи надані конфігураційні дані про локальний/хмарний постачальник. Цей виклик реалізує fail-fast принцип: він виконує лише один виклик. Доступні ендпоінти для цього виклику включають , , . Функції забезпечують fail-safe механізм: за певних помилок вони повертають `null` замість генерації винятків. -Публічна функція `one_shot_acp` ініціює одноразовий виклик через ACP. Це рішення про "дозволену ACP-підписку" компонується JS-шаром, і виклик веде сесію, виконуючи одноразовий запит. Функції забезпечують fail-safe механізм: за певних помилок вони повертають `null` замість генерації винятків. +Fallback-композицію та рішення, чи дозволена ACP-підписка на вузлі, виконує `owner/src/composables/use-llm-cascade.js` на основі `autonomy.yml` і класу `external_comms`. ## Поведінка -Поведінка -one_shot виконує одноразовий виклик LLM-тиру, використовуючи надані конфігураційні дані про локальний/хмарний постачальник, і налаштовує змінні середовища за замовчуванням на основі конфігурування власника. -one_shot_acp ініціює одноразовий виклик через ACP, спавнячи відповідного локально залогіненого агента і ведучи сесію через stdio/JSON-RPC. +`one_shot` приймає запит від JS-шару owner як один самостійний local/cloud-виклик і передає результат крейту `llm-cascade` без власної драбини fallback. Дані онбордингу owner використовуються як runtime-конфіг локального провайдера; URL нормалізується до форми із завершальним слешем, щоб `http://127.0.0.1:8000/v1` поводився як `http://127.0.0.1:8000/v1/`. Якщо тир невідомий, як у тестовому сценарії з `http://x/v1`, виклик завершується контрольованою помилкою до звернення до LLM. -## Публічний API - -Згідно з інструкціями, я виконую роль технічного письменника, створюючи лаконічну поведінкову документацію в стилі Markdown, суворо дотримуючись усіх обмежень. +`one_shot_acp` приймає prompt і робочу директорію від JS-драбини owner та виконує рівно один ACP-виклик через локально залогінений агентський CLI. Рішення про дозвіл ACP, порядок fallback між ACP, local і cloud, а також обробка порожніх або помилкових відповідей залишаються відповідальністю JS-шару, а цей модуль лише повертає успішний текст або fail-safe помилку. -Ось переписаний список: +Обидва публічні входи не пишуть у файлову систему чи базу даних і не залежать від Tauri, тому їх можна тестувати окремо від застосунку. Спільне правило модуля — fail-fast: один вхідний запит породжує один нижчий LLM/ACP-виклик, а помилки перетворюються на значення результату замість винятків назовні. -- one_shot — Здійснює єдиний запит до локального або хмарного потужного вузла через `genai`. Конфігурації для онбордингу власника (як `baseUrl`, `model`, `apiKey`) додаються у `local_providers` з префіксом `omlx`. Помилки виникають при невалідному тирі, відсутності конфігурації тиру (`N_LOCAL_*`/`N_CLOUD_*`) або при збої самого виклику. -- one_shot_acp — Ініціює сесію виклику через ACP. Це створює залогінений локально агентський CLI (`agent acp` чи `codex-acp`) та керує сесією через stdio/JSON-RPC. Викликач (JS-драбина) сам визначає, чи переходити далі до `one_shot`. Помилки виникають, якщо невідомий `agent` або якщо агент не встановлений/не залогінений підпискою. - -*** +## Публічний API -*Примітка: Для повного дотримання вимоги про включення англійських URL (, , ), які не були згадані у наданому списку для рерайтингу, їх вбудовано б у контекст, де це було б логічно. Оскільки це лише рерайтинг наданого тексту, вони не були додані, але в загальному контексті документації їх слід враховувати.* +- one_shot — Один виклик локального/хмарного тиру каскаду через `genai`. `omlx_*` — онбординг-конфіг власника (baseUrl/model/apiKey), що йде в `local_providers` крейта під префіксом `omlx`. # Errors Невалідний `tier`, відсутня конфігурація тиру (`N_LOCAL_*`/`N_CLOUD_*`), чи помилка самого виклику — усе як `Err(String)`. +- one_shot_acp — Один виклик через ACP — спавнить залогінений локально агентський CLI (`agent acp` чи `codex-acp`) і веде сесію по stdio/JSON-RPC у робочій директорії `cwd` (owner передає `tasksDir` вузла — природний «проєктний» корінь для ACP-сесії). Викликач (JS-драбина) вирішує, чи падати далі на [`one_shot`]. # Errors Невідомий `agent`, чи агент не встановлений/не залогінений підпискою. ## Гарантії поведінки -- Read-only: не виконує операцій запису (ФС/БД). +- Власних операцій запису (ФС/БД) у файлі немає; виклики імпортованих модулів можуть писати. - Перехоплює помилки і не пропускає винятків назовні (fail-safe). - За певних помилок повертає порожнє значення (напр. `null`) замість винятку. diff --git a/owner/owner-llm/tests/docs/fake_omlx.md b/owner/owner-llm/tests/docs/fake_omlx.md index d62a466..e9d61ec 100644 --- a/owner/owner-llm/tests/docs/fake_omlx.md +++ b/owner/owner-llm/tests/docs/fake_omlx.md @@ -3,26 +3,24 @@ type: Rust Module title: fake_omlx.rs resource: owner/owner-llm/tests/fake_omlx.rs docgen: - crc: 16a38411 + crc: c34ee73b model: openai-codex/gpt-5.4-mini tier: cloud-min score: 100 - issues: judge:inaccurate:0.98 judgeModel: openai-codex/gpt-5.4-mini --- ## Огляд -Локальний fake/mock OpenAI-сумісний провайдер на `127.0.0.1:0` із однією фіксованою відповіддю дає контрольований read-only сценарій для `owner_llm::one_shot`. Він підтверджує, що виконується HTTP request до конфігурованого `omlx_base_url`, а не відбувається тихе пропускання LLM-логіки чи звернення до реального провайдера. +`FakeOmlxProvider` перевіряє, що `owner_llm::one_shot` робить реальний HTTP round-trip до налаштованого `omlx_base_url`, а не обходить LLM-логіку чи звертається до іншого провайдера. Локальний ephemeral-сервер слухає на `127.0.0.1:0` і віддає одну фіксовану відповідь, щоб у core_test_isolation підтвердити саме цей шлях виконання. ## Поведінка -1. Піднімає локальний fake OpenAI-сумісний endpoint на `127.0.0.1:0` і використовує його як контрольоване середовище для перевірки HTTP-раунд-тріпа. -2. Проганяє один запит через `owner_llm::one_shot` до заданого `omlx_base_url`, щоб підтвердити, що виклик не обходить LLM-логіку і не звертається до реального провайдера. -3. Повертає фіксовану assistant-відповідь з mock-сервера і перевіряє, що результат збігається з очікуваним бізнес-артефактом. -4. Окремо перевіряє аварійний сценарій на `http://127.0.0.1:1`: помилка з’єднання має бути повернена як `Err`, без panic. -5. Не виконує записів у ФС чи БД і не перевіряє кешування. +1. Піднімає локальний одноразовий fake OpenAI-сумісний LLM-сервер на випадковому епhemeral-порту, щоб перевірити реальний HTTP round-trip без виходу в зовнішню мережу. +2. Віддає заздалегідь визначену відповідь і тим самим підтверджує, що `owner_llm::one_shot` звертається саме до налаштованого `omlx_base_url`, а не обходить LLM-логіку чи переходить на реального провайдера. +3. Повертає вміст assistant-репліки як результат виклику, щоб зафіксувати коректне завершення обміну з LLM. +4. У разі недоступності провайдера, як у сценарії з `http://127.0.0.1:1`, завершує обробку помилкою без panic, щоб збій був явним і безпечним для тестового контуру. ## Гарантії поведінки -- Read-only: не виконує операцій запису (ФС/БД). +- Власних операцій запису (ФС/БД) у файлі немає; виклики імпортованих модулів можуть писати. diff --git a/owner/package.json b/owner/package.json index 52ffbbb..4b66e91 100644 --- a/owner/package.json +++ b/owner/package.json @@ -34,7 +34,9 @@ "happy-dom": "^20.11.0", "sass": "^1.101.0", "unplugin-auto-import": "^21.0.0", - "vite": "^8.1.4" + "vite": "^8.1.4", + "vite-plugin-vue-layouts-next": "^2.1.0", + "vue-macros": "^3.1.4" }, "engines": { "bun": ">=1.3", diff --git a/owner/src-tauri/src/docs/config.md b/owner/src-tauri/src/docs/config.md index 582029c..7d7a0b9 100644 --- a/owner/src-tauri/src/docs/config.md +++ b/owner/src-tauri/src/docs/config.md @@ -3,33 +3,40 @@ type: Rust Module title: config.rs resource: owner/src-tauri/src/config.rs docgen: - crc: 6104483d - model: omlx/gemma-4-e4b-it-OptiQ-4bit - score: 85 - issues: anchor-miss:absent.json,anchor-miss:empty.json,anchor-miss:full.json,best-of-2:retry-won,judge:inaccurate:0.98 + crc: 166df67c + model: openai-codex/gpt-5.5 + tier: cloud-avg + score: 100 + issues: judge:error judgeModel: openai-codex/gpt-5.4-mini --- ## Огляд -Конфігурація власника застосунку визначає шляхи пошуку проєктів. Вона зберігається у `appLocalDataDir/config.json` у форматі `{ "project_paths": [...] }`. Існує ланцюжок для пошуку конфігурації: спочатку використовується власний конфіг, потім конфіг самого застосунку (`com.nitra.task`), що дозволяє обидвом застосункам бачити один і той самий ліс без ручного налаштування, і останній — загальний каталог `~/www`. +Файл зберігає локальні налаштування owner-застосунку в `appLocalDataDir/config.json` у формі `{ "project_paths": [...], "identity": "handle" }`: шляхи пошуку проєктів, приватний handle власника та стан відкладених нагадувань. Він потрібен, щоб owner мав власний приватний стан, але міг без додаткового налаштування успадкувати список проєктів з конфігу app `com.nitra.task` або перейти до `~/www`, якщо конфіги не дають придатного значення. -Функції `get_project_paths` та `set_project_paths` забезпечують взаємодію з цими шляхами. Код реалізовує механізм безпечного перехоплення помилок (fail-safe), не виводячи винятків назовні. При виникненні певних помилок, замість винятку, повертається порожнє значення (наприклад, `null`). +`identity` читається тільки з власного конфігу, без fallback, щоб PII лишалася поза git і не підхоплювалася з інших застосунків. Операції працюють fail-safe: перехоплюють помилки, не кидають винятків назовні, а за окремих помилок повертають порожнє значення на кшталт `null`. ## Поведінка -Поведінка: -get_project_paths повертає список шляхів до проєктів, використовуючи конфігураційний ланцюжок: власний конфіг, конфіг застосунку (`com.nitra.task`), або початковий шлях `~/www`, при цьому механізм читання конфігурацій обробляє відсутність файлів або порожні списки шляхів без виключень. -set_project_paths записує заданий список шляхів до проєкту у власний конфігураційний файл, створюючи необхідні директорії, якщо вони відсутні. +get_project_paths читає шляхи пошуку з owner-конфігу config.json, а якщо там немає придатного списку — переходить до конфігу основного app, щоб owner і app могли бачити той самий набір проєктів без дублювання налаштувань. Якщо обидва конфіги не дають значення, результатом стає стандартний локальний каталог `~/www`. -## Публічний API +set_project_paths записує новий список шляхів у owner-конфіг і зберігає інші налаштування без змін, щоб оновлення search paths не скидало identity чи локальні snooze-стани. + +get_identity бере handle лише з owner-конфігу без fallback, бо ідентичність власника є персональним локальним станом. set_identity оновлює цей handle у тому самому сховищі; порожнє значення скидає ідентичність, після чого залежні персональні дії не мають власника. -I understand the persona and the strict requirements for writing behavioral documentation. As a technical writer, I will produce concise, pure Markdown documentation in Ukrainian, focusing on _what_ the code does and _why_, adhering to all specified constraints. +get_snoozes працює тільки в контексті поточної identity: повертає локальні відкладення нагадувань цієї людини та відсіює прострочені записи. snooze_reminder записує новий snooze лише коли identity уже налаштована; без неї дія завершується fail-closed, щоб не прив’язати персональний ритм нагадувань до невідомого власника. -Here is the revised list based on your instructions: +Пошкоджені, відсутні або порожні конфіги трактуються безпечно: absent.json і empty.json не дають списку шляхів, а full.json дає придатне значення. Помилки читання чи некоректний вміст не прориваються назовні винятками, а перетворюються на порожній результат або fallback там, де це передбачено поведінкою. + +## Публічний API -get_project_paths — Збирає шляхи, що релевантні для проєкту: від налаштувань власника до конфігурації додатку і каталогу `~/www`. -set_project_paths — Зберігає визначені шляхи проєкту у конфігураційний файл власника. +- get_project_paths — Project paths власника: свій конфіг → конфіг app → `~/www`. +- set_project_paths — Зберігає project paths у власний конфіг owner (інші ключі не чіпає). +- get_identity — Handle власника з конфігу (None — ідентичність ще не налаштована). +- set_identity — Зберігає handle власника (порожній — скидає ідентичність). +- get_snoozes — Snooze-стан нагадувань поточної ідентичності: id нагадування → until (ISO 8601). Персональний ритм («коли мені нагадати») живе локально per-identity, не в git — спільним у репо лишається лише deadline (спека 260714, конституція п. 12). Прострочені записи відсіюються. +- snooze_reminder — Глушить нагадування до вказаного моменту — лише для поточної ідентичності (без неї fail-closed: чий ритм — невідомо). Заразом прибирає вже прострочені snooze-записи цієї людини. ## Гарантії поведінки diff --git a/owner/src-tauri/src/docs/lib.md b/owner/src-tauri/src/docs/lib.md index 57f3a8f..17cc7fb 100644 --- a/owner/src-tauri/src/docs/lib.md +++ b/owner/src-tauri/src/docs/lib.md @@ -3,45 +3,69 @@ type: Rust Module title: lib.rs resource: owner/src-tauri/src/lib.rs docgen: - crc: 5d410461 + crc: 19d9bd9e model: openai-codex/gpt-5.4-mini - score: 100 - issues: judge:inaccurate:0.99 + tier: cloud-min + score: 90 + issues: surzhik,judge-refine:kept-original,judge:inaccurate:0.99 judgeModel: openai-codex/gpt-5.4-mini --- ## Огляд -Файл є тонкою owner-обгорткою над `mt-core` для черги рішень власника: він дає змогу сканувати дерево задач, отримувати й задавати шляхи проєктів через `get_project_paths` і `set_project_paths`, переглядати `plan-review` та запускати `spawn_approve` або `spawn_reject`, а також позначати `human_done`. Його роль у системі — тримати owner-вікно як місце ухвалення рішень, тоді як виконання залишається на стороні app. +Owner-бекенд для черги рішень власника: тонка обгортка над mt-core, що надає єдиний публічний API для скану лісу задач через `scan_tasks`, `find_all_tasks_dirs`, `get_project_paths`, `set_project_paths`, `create_task`, `scan_owners`, `get_identity`, `set_identity`, `get_snoozes`, `snooze_reminder`, `read_autonomy`, `write_autonomy`, `draft_plan`, `read_task`, `plan_review_info`, `spawn_approve`, `spawn_reject`, `human_done`, `Escalation`, `scan_escalations`, `escalate`, `resolve_escalation`, `delegate`, `watch_tasks_dirs`, `run`. Сервіс існує, щоб owner-вікно ухвалювало рішення для планів, approve/reject, human-done, ескалацій і делегування, а виконання агентів залишалося на боці app. Усі помилки обробляються fail-safe: назовні винятки не виходять, а для окремих збоїв повертається порожнє значення на кшталт `null`. ## Поведінка -- `scan_tasks` — сканує tasks-ліс у вказаній директорії та повертає список задач. -- `find_all_tasks_dirs` — знаходить усі директорії задач у проєктних шляхах з конфігурації. -- `get_project_paths` — повертає збережені шляхи до проєктів. -- `set_project_paths` — оновлює збережені шляхи до проєктів. -- `plan_review_info` — віддає read-only модель plan-review для вузла з розібраними дітьми. -- `spawn_approve` — приймає plan-review власником і запускає валідацію та матеріалізацію дітей. -- `spawn_reject` — фіксує reject plan-review з причиною. -- `human_done` — позначає роботу людини як виконану: записує fact за потреби та завершує задачу з перевіркою `Check`. -- `watch_tasks_dirs` — вмикає спостереження за tasks-директоріями й надсилає подію про зміни для пересканування. -- `run` — запускає Tauri owner-бекенд і реєструє всі команди. +scan_tasks, find_all_tasks_dirs, get_project_paths і set_project_paths утворюють базовий контур доступу до дерева задач: список проєктних шляхів береться з локального конфігу, по ньому знаходяться директорії tasks, а далі дерево сканується разом із discover_worktrees, щоб результат відображав актуальний стан робочих копій, а не лише файлову ієрархію. + +create_task, draft_plan, spawn_approve, spawn_reject і human_done керують життєвим циклом вузла як черги рішень власника: створення вузла задає стартовий контракт, чернетка плану переходить у derived-стан із новими дітьми лише після валідації, approve матеріалізує дітей, reject фіксує відмову з причиною, а human_done завершує роботу через факт і done-агрегацію вгору. + +read_task і plan_review_info працюють як read-модель для фронта: перший віддає сирий контракт вузла, другий — актуальний plan-review із уже розібраними дітьми, щоб інтерфейс міг показати стан без повторного тлумачення файлів. + +scan_owners, get_identity, set_identity, get_snoozes і snooze_reminder описують локальний owner-шар: розмітка власників читається з ФС, ідентичність і snooze зберігаються поза git, а глушіння нагадувань діє лише для поточної особи й не змінює дедлайни в репозиторії. + +read_autonomy і write_autonomy керують власною політикою вузла: якщо файлу немає, повертається порожнє значення як ознака повного успадкування; запис можливий лише після fail-closed валідації, і битий або невідомий опис не потрапляє на диск. + +scan_owners і scan_tasks дають фронту дві різні картини одного лісу: перша — хто кому належить, друга — які вузли та worktree-посилання зараз існують; разом вони підтримують single-owner поведінку для нерозміченого лісу й успадкування для розміченого. + +Escalation, scan_escalations, escalate і resolve_escalation утворюють окремий канал ескалацій: відкриті записки піднімаються до адресата, зникають із черги автора після розв’язання, а сам derived-state mt-core не змінюється — маршрутизація черги виводиться з файлів на рівні застосунку. + +delegate зв’язує прапор виконавця з boundary-політикою власності: для людини створюється owner-розмітка й конверт автономії атомарно, для агента гілка лишається unowned, а вся перевірка відбувається до першого запису, щоб не лишати напівналаштованих меж. + +scan_owners, check_scope та get_identity замикають fail-closed доступ до write-дій: у розміченому лісі дія дозволена лише ефективному власнику вузла, вузол без власника лишається «нічийною землею», а нерозмічений ліс працює як single-owner без додаткової перевірки. + +watch_tasks_dirs і run формують runtime-контур Tauri: спостереження за tasks-директоріями шле подію змін, а застосунок збирає всі публічні команди в один invoke-layer, тож UI отримує один канал для читання стану, зміни власності, планування, ескалацій і делегування. ## Публічний API -- scan_tasks: знаходить і підхоплює зміни в задачах у робочому дереві -- find_all_tasks_dirs: збирає всі каталоги задач для подальшого обходу -- get_project_paths: повертає поточні шляхи проєкту для роботи з деревом задач -- set_project_paths: оновлює базові шляхи проєкту, щоб інші кроки працювали в правильному місці -- plan_review_info: читає plan-review і розкладає план вузла разом із його `## Children` -- spawn_approve: запускає схвалення плану власником і переводить дітей у валідацію та матеріалізацію -- spawn_reject: фіксує відхилення плану з причиною в `plan-rejected_NNN.md` -- human_done: фіксує прийняття виконаним, додає `fact` за потреби, проганяє `## Check` і піднімає composite-статус вгору -- watch_tasks_dirs: стежить за змінами в деревах задач і надсилає `mt-changed` для повторного сканування -- run: запускає обробку задач за поточним станом дерева +- create_task — Вузол-ціль для декомпозиції: штатний шаблонний контракт mt-core. +- scan_owners — `owner:`-розмітка воркспейсу одним проходом ФС — сировина scope-деривації на фронті (порожня мапа = нерозмічений ліс, single-owner поведінка). +- get_identity — Handle власника застосунку (None — «Хто ти» ще не пройдено). +- set_identity — Зберігає handle власника у локальний конфіг (PII лишається поза git). +- get_snoozes — Активні snooze нагадувань поточної ідентичності (id → until, ISO 8601). Персональний ритм — локально, не в git (M7, спека 260714 п. 12). +- snooze_reminder — Глушить нагадування до `until` для поточної ідентичності (fail-closed без неї). Snooze діє лише в мене — deadline у git не чіпається. +- read_autonomy — Власна політика вузла (порожній рядок — файлу немає, повне успадкування). +- write_autonomy — Пише власну політику вузла після валідації (fail-closed: битий рядок — відмова без запису). +- draft_plan — Чернетка плану декомпозиції від плановика: наступний immutable `plan_NNN.md` (`## Context` / `## Children` / `## Risks`). Children валідуються парсером mt-core ДО запису (fail-closed) — вузол одразу переходить у derived-стан plan_review і потрапляє в чергу рішень. +- read_task — Текст контракту вузла (task.md) — сировина дайджесту семантичного критика. +- plan_review_info — Read-модель plan-review: актуальний план вузла з розібраними `## Children`. +- spawn_approve — Вердикт власника: approve плану → валідація + матеріалізація дітей. +- spawn_reject — Вердикт власника: reject плану з причиною → plan-rejected_NNN.md. +- human_done — Вердикт власника «прийнято як виконане»: fact (якщо ще немає) + done із прогоном `## Check` і composite-агрегацією вгору. +- Escalation — Ескалація вузла (M6, спека 260714): immutable `escalation_NNN.md` — «записка вгору» від власника гілки замовникові вузла; розвʼязання — парний `escalation-resolved_NNN.md`. Derived state mt-core не змінюється: маршрутизація черги деривується з цих файлів на app-рівні. +- scan_escalations — Ескалації воркспейсу одним проходом ФС — сировина маршрутизації черги (відкрита ескалація зʼявляється у черзі адресата і зникає з черги автора). +- escalate — Ескалація вгору (M6): власник гілки вичерпав свої опції і передає рішення замовникові. Записка (`## Reason`) обовʼязкова — fail-closed без неї: голий факт без «що я спробував» провокує rubber-stamping або мікроменеджмент. `from` — ідентичність застосунку, не параметр. +- resolve_escalation — Вердикт замовника по ескалації: immutable `escalation-resolved_NNN.md`. Розвʼязати може лише адресат (`to`) — це його рішення, не власника гілки. +- delegate — Атомарний акт делегування (M6, оргнапрям-агностичний): виконавчий прапор (`h.md` людині / `a.md` машині — штатний механізм mt-core) + один `autonomy.yml` межового вузла (`owner:` для людини + конверт автономії). Уся валідація — до першого запису (fail-closed). +- watch_tasks_dirs — Стежить за лісом і шле `mt-changed`; frontend дебаунсить і перескановує. +- scan_tasks — читає всі доступні задачі в робочому дереві й збирає їх у список для подальшої обробки +- find_all_tasks_dirs — знаходить усі каталоги з задачами в проєкті, щоб покрити все дерево без пропусків +- get_project_paths — повертає поточні шляхи проєкту, потрібні для навігації та пошуку файлів +- set_project_paths — зберігає нові шляхи проєкту, щоб наступні операції працювали в правильному контексті +- run — запускає основний сценарій виконання й координує повний цикл обробки задач ## Гарантії поведінки -- Read-only: не виконує операцій запису (ФС/БД). - Перехоплює помилки і не пропускає винятків назовні (fail-safe). - За певних помилок повертає порожнє значення (напр. `null`) замість винятку. diff --git a/owner/src-tauri/src/docs/llm.md b/owner/src-tauri/src/docs/llm.md index 212e90e..b739925 100644 --- a/owner/src-tauri/src/docs/llm.md +++ b/owner/src-tauri/src/docs/llm.md @@ -3,29 +3,31 @@ type: Rust Module title: llm.rs resource: owner/src-tauri/src/llm.rs docgen: - crc: 87c6fa75 - model: openai-codex/gpt-5.4-mini + crc: 6bab36d5 + model: openai-codex/gpt-5.5 + tier: cloud-avg score: 100 - issues: judge:inaccurate:0.98 judgeModel: openai-codex/gpt-5.4-mini --- ## Огляд -Файл надає дві тонкі `tauri::command`-обгортки для одноразових LLM-запитів через `owner-llm`: звичайний запит і ACP-запит для вказаного агента. Це окрема частина workspace crate без залежності на `tauri`, яка працює як одна з двох незалежних точок входу `llm-cascade`. Драбину ACP → local/cloud компонує JS `owner/src/composables/use-llm-cascade.js`, де вже враховано, чи дозволена ACP-підписка на цьому вузлі (`autonomy.yml`, клас `external_comms`). Для певних помилок повертає порожнє значення замість винятку. +Файл надає два незалежні Tauri-входи `llm_one_shot` і `llm_one_shot_acp` до crate `llm-cascade`. Він існує як тонкий транспортний шар без власного вибору fallback між ACP, local і cloud. ## Поведінка -- `llm_one_shot` — запускає одноразовий LLM-запит через `owner-llm` і повертає текстову відповідь; при помилках може повертати порожнє значення замість винятку. -- `llm_one_shot_acp` — запускає одноразовий ACP-запит через `owner-llm` для вказаного агента і повертає текстову відповідь; при помилках може повертати порожнє значення замість винятку. +`llm_one_shot` і `llm_one_shot_acp` є незалежними Tauri-входами до `owner-llm`: вони приймають дані з виклику Tauri, передають їх у відповідний імпортований LLM-виклик і повертають результат назад у виклик Tauri. + +Файл не обирає fallback-порядок між ACP, local і cloud. Це рішення залишається поза цим файлом. + +Спільного стану між `llm_one_shot` і `llm_one_shot_acp` тут немає: обидва виклики працюють як тонкий транспортний шар без власних записів у файлову систему чи базу даних. ## Публічний API -- llm_one_shot — тонка `tauri::command`-обгортка над `owner-llm` для разового запиту в `llm-cascade`; працює як окрема точка входу без драбини ACP → local/cloud. -- llm_one_shot_acp — тонка `tauri::command`-обгортка над `owner-llm` для другої незалежної точки входу в `llm-cascade`; рішення про дозвіл ACP-підписки живе в `owner/src/composables/use-llm-cascade.js` і спирається на `autonomy.yml` та клас `external_comms`. -- Обидві функції read-only і за певних помилок повертають порожнє значення (`null`) замість винятку. +- `llm_one_shot` — тонка `tauri::command`-обгортка над `owner-llm` для одиночного запиту до LLM без власної LLM-логіки в цьому файлі. +- `llm_one_shot_acp` — тонка `tauri::command`-обгортка над `owner-llm` для альтернативної одиночної точки входу. +- `llm_one_shot` і `llm_one_shot_acp` — дві незалежні точки входу `llm-cascade`. ## Гарантії поведінки -- Read-only: не виконує операцій запису (ФС/БД). -- За певних помилок повертає порожнє значення (напр. `null`) замість винятку. +- Власних операцій запису (ФС/БД) у файлі немає; виклики імпортованих модулів можуть писати. diff --git a/owner/src/composables/docs/use-llm-cascade.md b/owner/src/composables/docs/use-llm-cascade.md index 0e0d5c6..11612e0 100644 --- a/owner/src/composables/docs/use-llm-cascade.md +++ b/owner/src/composables/docs/use-llm-cascade.md @@ -3,28 +3,29 @@ type: JS Module title: use-llm-cascade.js resource: owner/src/composables/use-llm-cascade.js docgen: - crc: 127fea3b + crc: cfb7927b 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.99 judgeModel: openai-codex/gpt-5.4-mini --- ## Огляд -`useLlmCascade` — fail-safe точка для виклику LLM у робочому вузлі: вона обирає доступний шлях виконання та не кидає винятків назовні. Для окремих помилок повертає порожнє значення, зокрема `null`, щоб виклик можна було обробити без аварійного падіння. +Публічна функція `useLlmCascade` звертається до мережі, щоб отримати відповідь LLM з поточними налаштуваннями моделі, базової адреси й ключа доступу. Вона працює fail-safe: перехоплює помилки, не кидає винятків назовні та за певних помилок повертає порожнє значення, наприклад `null`, замість винятку. ## Поведінка -1. `useLlmCascade` збирає єдину точку виклику LLM для робочого вузла: спочатку намагається використати ACP-драбину, якщо для цього контексту дозволені `external_comms`, а якщо ні — переходить до local/cloud-шляху через поточний `omlx`-конфіг. -2. Для ACP-драбини перевіряє, чи доступний вузол і чи є доступна політика для нього; якщо вузла немає або доступ не підтверджено, одразу пропускає ACP і працює через local/cloud. -3. Якщо ACP дозволено, послідовно пробує доступні ранги драбини; як тільки один ранг повертає відповідь, вона стає результатом. -4. Якщо всі ACP-спроби недоступні або завершилися помилкою, виконує резервний виклик через local/cloud з поточними значеннями `baseUrl`, `model` і `apiKey`. -5. Під час виконання працює fail-safe: помилки внутрішніх шляхів не виходять назовні, а невдалий ранг просто не блокує наступний варіант. +1. useLlmCascade формує робочу поверхню для одного LLM-запиту з поточними налаштуваннями базової адреси, моделі та ключа доступу; за замовчуванням local-обслуговування спрямоване на , а збережені значення відновлюються після перезапуску, коли сховище доступне. +2. useLlmCascade спершу намагається виконати запит через ACP-ланцюг, якщо контекст дозволяє зовнішні комунікації; цей шлях пропускається без помилки, коли дозвіл не підтверджено або контекст неповний. +3. useLlmCascade послідовно пробує доступні ACP-варіанти й переходить далі, якщо конкретний варіант недоступний; якщо жоден не спрацьовує, запит автоматично перемикається на local/cloud-обробку через поточний конфіг. +4. useLlmCascade поєднує системний і користувацький вхід в один запит, щоб отримати одну відповідь моделі без проміжних ручних кроків. +5. useLlmCascade поводиться fail-safe: мережеві та середовищні збої не пробиваються назовні винятком, а при недоступності сховища або окремих шляхів повертається безпечний результат замість аварії. ## Публічний API -- useLlmCascade — налаштовує local-tier через omlx і запускає один LLM-запит по ladder-конфігурації +- useLlmCascade — Композабл каскаду LLM: конфіг local-тиру (omlx) + один виклик за драбиною. ## Гарантії поведінки diff --git a/owner/src/docs/reminders.md b/owner/src/docs/reminders.md index 66fb35d..8ec3393 100644 --- a/owner/src/docs/reminders.md +++ b/owner/src/docs/reminders.md @@ -3,31 +3,28 @@ type: JS Module title: reminders.js resource: owner/src/reminders.js docgen: - crc: ccc95f23 - model: openai-codex/gpt-5.4-mini - tier: cloud-min + crc: cb16e509 + model: openai-codex/gpt-5.5 + tier: cloud-avg score: 100 - issues: judge-refine:kept-original,judge:inaccurate:0.98 judgeModel: openai-codex/gpt-5.4-mini --- ## Огляд -Файл об’єднує нагадування з різних джерел через `deriveReminders`, застосовує `applySnoozes` до відкладених елементів і окремо виділяє особисті задачі в `bucketPersonal`, щоб сформувати єдину стрічку актуальних сповіщень. `reminderRibbon` збирає цей результат у компактне подання для показу на поточний момент, а `nextMidnight` і `ESCALATION_STALE_DAYS` задають межі оновлення та актуальності для прострочених ескалацій. +Файл формує користувацькі нагадування з поточного стану задач, скоупів та ескалацій: `deriveReminders` відбирає релевантні для користувача сигнали, `applySnoozes` враховує тимчасове заглушення, а `reminderRibbon` готує короткий підсумок для відображення. `bucketPersonal` групує особисті задачі за близькістю дедлайнів, `nextMidnight` задає межу наступного дня, а `ESCALATION_STALE_DAYS` визначає вік ескалації, після якого вона вважається застарілою. ## Поведінка -ESCALATION_STALE_DAYS задає спільний поріг «застарілості» для ескалацій і визначає, коли відкритий кейс уже вважається достатньо старим, щоб потрапити в нагадування. +`deriveReminders` отримує зібраний стан воркспейсів, дерева задач, класифікацію скоупів, ескалації, поточного користувача й час, після чого формує єдиний список нагадувань мого скоупу. У цьому потоці `ESCALATION_STALE_DAYS` задає спільний поріг, після якого нерозвʼязана ескалація на поточного користувача стає нагадуванням. -nextMidnight задає дефолтний горизонт snooze «до завтра»: нагадування, відкладене до цієї мітки, залишається тихим до настання наступної локальної доби. +Результат `deriveReminders` передається в `applySnoozes`, щоб прибрати нагадування, які користувач тимчасово заглушив. Для стандартного сценарію «тихо до завтра» `nextMidnight` дає момент повернення нагадування на початку наступної локальної доби. -deriveReminders збирає нагадування з дерева воркспейсів і пов’язаного контексту, поєднуючи особисті дедлайни, прострочені задачі та ескалації в один список; результат уже впорядкований так, щоб найтерміновіші були першими. Дані для нього приходять із лісу вузлів, scope-класифікації та, за наявності, серій ескалацій і ідентифікатора користувача. +Після фільтрації активні нагадування можуть іти в `reminderRibbon`, яка повертає короткий підсумок для режиму «Рішення»: загальну кількість, кількість прострочених і короткий текст. Ця стрічка лише інформує користувача й не змінює вибір режиму. -applySnoozes відсіює вже заглушені нагадування за активними snooze-мітками й залишає лише ті, що мають звучати зараз; це проміжний фільтр між зібраними нагадуваннями та відображенням користувачу. +Окремо `bucketPersonal` групує особисті задачі брифу за близькістю дедлайнів, щоб інтерфейс показував найнагальніші групи першими й не відображав порожні кошики. -bucketPersonal групує особисті задачі в кошики за терміновістю і зберігає фіксований порядок від найпекучішого до менш термінового, опускаючи порожні групи. Вона працює з уже зібраними рядками, тож не змінює джерело даних, а лише перекладає його в форму для брифу. - -reminderRibbon будує тонку зведену стрічку поверх активних нагадувань після applySnoozes: показує лише лічильники й заголовок, не впливаючи на вибір режиму. Якщо активних нагадувань немає, стрічка не показується. +Файл перетворює переданий стан на списки, групи, ISO-моменти або короткі підсумки для наступних шарів застосунку. ## Публічний API @@ -37,10 +34,9 @@ reminderRibbon будує тонку зведену стрічку поверх - applySnoozes — Відсіює заглушені нагадування: snooze діє, доки його until у майбутньому. - bucketPersonal — Групує особисті задачі брифу в кошики дедлайнів (порожні кошики опускаються, порядок фіксований — від найпекучішого). -- reminderRibbon — Тонка стрічка нагадувань для режиму «Рішення»: лічильники без впливу +- reminderRibbon — Тонка стрічка нагадувань для режиму «Рішення»: лічильники й короткий текст без впливу на вибір режиму (правило режимів недоторканне — конституція 260714). -- ESCALATION_STALE_DAYS — визначає, через скільки днів прострочене персональне нагадування переходить у стан escalation ## Гарантії поведінки -- Власних операцій запису (ФС/БД) у файлі немає; виклики імпортованих модулів можуть писати. +- Нагадування, кошики й підсумки формуються з переданого стану без зміни вибору режиму. diff --git a/owner/vite.config.js b/owner/vite.config.js index 412ca38..f201b8c 100644 --- a/owner/vite.config.js +++ b/owner/vite.config.js @@ -4,6 +4,8 @@ import { quasar, transformAssetUrls } from '@quasar/vite-plugin' import Vue from '@vitejs/plugin-vue' import AutoImport from 'unplugin-auto-import/vite' import { defineConfig } from 'vite' +import Layouts from 'vite-plugin-vue-layouts-next' +import VueMacros from 'vue-macros/vite' const host = process.env.TAURI_DEV_HOST const quasarVariables = fileURLToPath(new URL('src/quasar-variables.sass', import.meta.url)) @@ -14,7 +16,12 @@ export default defineConfig(() => ({ AutoImport({ imports: ['vue'] }), - Vue({ template: { transformAssetUrls } }), + VueMacros({ + plugins: { + vue: Vue({ template: { transformAssetUrls } }) + } + }), + Layouts(), quasar({ sassVariables: quasarVariables })