From 873c3eaf85426dd3a509261a26a1c3d17dc2f396 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Mon, 4 May 2026 21:01:05 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/cli/update.md | 152 +++++++------- docs/uk/help/testing-updates-plugins.md | 257 ++++++++++++------------ docs/uk/plugins/manage-plugins.md | 89 +++----- docs/uk/reference/test.md | 126 ++++++------ 4 files changed, 308 insertions(+), 316 deletions(-) diff --git a/docs/uk/cli/update.md b/docs/uk/cli/update.md index 5be343480..3a22923b3 100644 --- a/docs/uk/cli/update.md +++ b/docs/uk/cli/update.md @@ -3,13 +3,13 @@ read_when: - Ви хочете безпечно оновити робочу копію вихідного коду - Ви налагоджуєте вивід або параметри `openclaw update` - Потрібно розуміти поведінку скороченого запису `--update` -summary: Довідка CLI для `openclaw update` (відносно безпечне оновлення джерела + автоматичний перезапуск Gateway) -title: Оновлення +summary: Довідник CLI для `openclaw update` (відносно безпечне оновлення джерела + автоматичний перезапуск Gateway) +title: Оновити x-i18n: - generated_at: "2026-05-03T20:54:32Z" + generated_at: "2026-05-04T20:59:55Z" model: gpt-5.5 provider: openai - source_hash: 53ec06b8db5e2aba4000922f92a36834e8782986a77f6b5889bb19031a59f1b8 + source_hash: b12b1837ae80a3688fb7805d78d5a354f07dccdaba175cfa429e18145e543a1f source_path: cli/update.md workflow: 16 --- @@ -18,7 +18,8 @@ x-i18n: Безпечно оновлюйте OpenClaw і перемикайтеся між каналами stable/beta/dev. -Якщо ви встановили через **npm/pnpm/bun** (глобальне встановлення, без метаданих git), оновлення виконуються через потік пакетного менеджера в [Оновлення](/uk/install/updating). +Якщо ви встановили через **npm/pnpm/bun** (глобальне встановлення, без метаданих git), +оновлення відбуваються через потік менеджера пакетів, описаний у [Оновлення](/uk/install/updating). ## Використання @@ -39,25 +40,31 @@ openclaw --update ## Параметри -- `--no-restart`: пропустити перезапуск служби Gateway після успішного оновлення. Оновлення через пакетний менеджер, які перезапускають Gateway, перевіряють, що перезапущена служба повідомляє очікувану оновлену версію, перш ніж команда завершиться успішно. -- `--channel `: задати канал оновлень (git + npm; зберігається в конфігурації). -- `--tag `: перевизначити ціль пакета лише для цього оновлення. Для встановлень пакета `main` зіставляється з `github:openclaw/openclaw#main`. +- `--no-restart`: пропустити перезапуск служби Gateway після успішного оновлення. Оновлення через менеджер пакетів, які перезапускають Gateway, перевіряють, що перезапущена служба повідомляє очікувану оновлену версію, перш ніж команда завершиться успішно. +- `--channel `: установити канал оновлення (git + npm; зберігається в конфігурації). +- `--tag `: перевизначити ціль пакета лише для цього оновлення. Для встановлень пакетів `main` відповідає `github:openclaw/openclaw#main`. - `--dry-run`: попередньо переглянути заплановані дії оновлення (канал/тег/ціль/потік перезапуску) без запису конфігурації, встановлення, синхронізації plugins або перезапуску. - `--json`: вивести машинозчитуваний JSON `UpdateRunResult`, зокрема - `postUpdate.plugins.integrityDrifts`, коли під час синхронізації Plugin після оновлення - виявлено дрейф артефактів npm Plugin. -- `--timeout `: тайм-аут для кожного кроку (типово 1800с). -- `--yes`: пропустити запити підтвердження (наприклад, підтвердження повернення до старішої версії). + `postUpdate.plugins.integrityDrifts`, коли під час післяоновлювальної синхронізації plugins + виявлено розбіжність артефактів npm plugin. +- `--timeout `: тайм-аут для кожного кроку (типово 1800 с). +- `--yes`: пропустити запити підтвердження (наприклад, підтвердження зниження версії). -`openclaw update` не має прапорця `--verbose`. Використовуйте `--dry-run`, щоб попередньо переглянути заплановані дії каналу/тега/встановлення/перезапуску, `--json` для машинозчитуваних результатів і `openclaw update status --json`, коли потрібні лише відомості про канал і доступність. Якщо ви налагоджуєте журнали Gateway під час оновлення, докладність консолі та рівень файлових журналів є окремими: Gateway `--verbose` впливає на вивід термінала/WebSocket, тоді як файлові журнали потребують `logging.level: "debug"` або `"trace"` у конфігурації. Див. [Журналювання Gateway](/uk/gateway/logging). +`openclaw update` не має прапорця `--verbose`. Використовуйте `--dry-run`, щоб попередньо переглянути +заплановані дії каналу/тега/встановлення/перезапуску, `--json` для машинозчитуваних +результатів і `openclaw update status --json`, коли потрібні лише канал і +відомості про доступність. Якщо ви налагоджуєте журнали Gateway під час оновлення, +докладність консолі та рівень файлового журналу налаштовуються окремо: Gateway `--verbose` впливає +на вивід термінала/WebSocket, тоді як для файлових журналів потрібні `logging.level: "debug"` або +`"trace"` у конфігурації. Див. [Журналювання Gateway](/uk/gateway/logging). -Повернення до старіших версій потребує підтвердження, бо старіші версії можуть пошкодити конфігурацію. +Зниження версії потребує підтвердження, оскільки старіші версії можуть порушити конфігурацію. ## `update status` -Показати активний канал оновлень + тег/гілку/SHA git (для checkout вихідного коду), а також доступність оновлення. +Показати активний канал оновлення + тег/гілку/SHA git (для checkout вихідного коду), а також доступність оновлення. ```bash openclaw update status @@ -68,12 +75,12 @@ openclaw update status --timeout 10 Параметри: - `--json`: вивести машинозчитуваний JSON стану. -- `--timeout `: тайм-аут для перевірок (типово 3с). +- `--timeout `: тайм-аут для перевірок (типово 3 с). ## `update wizard` -Інтерактивний потік для вибору каналу оновлень і підтвердження, чи перезапускати Gateway -після оновлення (типово перезапускати). Якщо ви виберете `dev` без git checkout, він +Інтерактивний потік для вибору каналу оновлення та підтвердження, чи перезапускати Gateway +після оновлення (типово перезапускати). Якщо вибрати `dev` без git checkout, він запропонує створити його. Параметри: @@ -85,111 +92,112 @@ openclaw update status --timeout 10 Коли ви явно перемикаєте канали (`--channel ...`), OpenClaw також підтримує узгодженість методу встановлення: -- `dev` → забезпечує git checkout (типово: `~/openclaw`, перевизначення через `OPENCLAW_GIT_DIR`), +- `dev` → забезпечує git checkout (типово: `~/openclaw`, перевизначається через `OPENCLAW_GIT_DIR`), оновлює його та встановлює глобальний CLI з цього checkout. - `stable` → встановлює з npm за допомогою `latest`. -- `beta` → віддає перевагу dist-tag npm `beta`, але повертається до `latest`, коли beta - відсутня або старіша за поточний стабільний випуск. +- `beta` → надає перевагу npm dist-tag `beta`, але повертається до `latest`, коли beta + відсутній або старіший за поточний stable-випуск. -Автооновлювач ядра Gateway (коли ввімкнений у конфігурації) запускає шлях оновлення CLI -поза активним обробником запитів Gateway. Оновлення `update.run` пакетного менеджера -через control plane примусово виконують невідкладний перезапуск після заміни пакета, -без періоду охолодження, бо старий процес Gateway може ще мати фрагменти в пам'яті, -які вказують на файли, вилучені новим пакетом. +Автооновлювач ядра Gateway (коли ввімкнений через конфігурацію) запускає шлях оновлення CLI +поза активним обробником запитів Gateway. Оновлення через менеджер пакетів control-plane `update.run` +примусово виконують невідкладений перезапуск оновлення без періоду очікування після заміни пакета, +оскільки старий процес Gateway усе ще може мати в памʼяті фрагменти, що вказують на +файли, вилучені новим пакетом. -Для встановлень через пакетний менеджер `openclaw update` визначає цільову версію -пакета перед викликом пакетного менеджера. Глобальні встановлення npm використовують -поетапне встановлення: OpenClaw встановлює новий пакет у тимчасовий npm prefix, перевіряє +Для встановлень через менеджер пакетів `openclaw update` визначає цільову версію +пакета перед викликом менеджера пакетів. Глобальні встановлення npm використовують поетапне +встановлення: OpenClaw встановлює новий пакет у тимчасовий префікс npm, перевіряє там інвентар упакованого `dist`, а потім замінює це чисте дерево пакета в -справжньому глобальному prefix. Якщо перевірка не вдається, post-update doctor, синхронізація Plugin і -робота з перезапуском не виконуються з підозрілого дерева. Навіть коли встановлена версія -вже збігається з цільовою, команда оновлює глобальне встановлення пакета, -а потім виконує синхронізацію Plugin, оновлення завершення основної команди та роботу з перезапуском. Це -підтримує узгодженість упакованих допоміжних компонентів і записів Plugin, що належать каналу, з -установленою збіркою OpenClaw, залишаючи повне перебудування завершень команд Plugin для +реальному глобальному префіксі. Якщо перевірка не вдається, післяоновлювальний doctor, синхронізація plugin і +перезапуск не виконуються з підозрілого дерева. Навіть коли встановлена версія +вже відповідає цілі, команда оновлює глобальне встановлення пакета, +а потім виконує синхронізацію plugin, оновлення завершень основних команд і перезапуск. Це +підтримує узгодженість упакованих sidecar-компонентів і записів plugins, керованих каналом, з +установленою збіркою OpenClaw, залишаючи повні перебудови завершень команд plugins для явних запусків `openclaw completion --write-state`. -Коли встановлена локальна керована служба Gateway і перезапуск увімкнено, -оновлення через пакетний менеджер зупиняють запущену службу перед заміною дерева пакета, -потім оновлюють метадані служби з оновленого встановлення, перезапускають +Коли встановлено локальну керовану службу Gateway і перезапуск увімкнено, +оновлення через менеджер пакетів зупиняють запущену службу перед заміною дерева +пакета, потім оновлюють метадані служби з оновленого встановлення, перезапускають службу та перевіряють, що перезапущений Gateway повідомляє очікувану версію, перш ніж -повідомити про успіх. На macOS перевірка після оновлення також перевіряє, що LaunchAgent -завантажено/запущено для активного профілю, а налаштований порт loopback -справний. Якщо plist встановлено, але launchd не наглядає за ним, OpenClaw -автоматично повторно bootstrap LaunchAgent, а потім знову виконує -перевірки готовності health/version/channel. Свіжий bootstrap завантажує завдання RunAtLoad -напряму, тож відновлення після оновлення не виконує негайно `kickstart -k` для щойно -створеного Gateway. Якщо Gateway і далі не стає справним, команда завершується -з ненульовим кодом і друкує шлях до журналу перезапуску, а також явні інструкції щодо перезапуску, перевстановлення та +повідомити про успіх. На macOS післяоновлювальна перевірка також підтверджує, що LaunchAgent +завантажений/запущений для активного профілю, а налаштований порт loopback +справний. Якщо plist встановлено, але launchd не керує ним, OpenClaw +автоматично повторно завантажує LaunchAgent, а потім повторно виконує +перевірки готовності стану/версії/каналу. Свіже завантаження напряму завантажує завдання RunAtLoad, +тому відновлення після оновлення не виконує негайно `kickstart -k` для щойно +запущеного Gateway. Якщо Gateway усе ще не стає справним, команда завершується +з ненульовим кодом і виводить шлях до журналу перезапуску, а також явні інструкції щодо перезапуску, перевстановлення та відкату пакета. З `--no-restart` -заміна пакета все одно виконується, але керована служба не зупиняється й не -перезапускається, тому запущений Gateway може зберігати старий код, доки ви не перезапустите його +заміна пакета все одно виконується, але керована служба не зупиняється і не +перезапускається, тому запущений Gateway може використовувати старий код, доки ви не перезапустите його вручну. ## Потік git checkout ### Вибір каналу -- `stable`: checkout найновішого не-beta тега, потім build і doctor. -- `beta`: віддати перевагу найновішому тегу `-beta`, але повернутися до найновішого stable тега, коли beta відсутня або старіша. +- `stable`: checkout останнього не-beta тегу, потім збірка й doctor. +- `beta`: надати перевагу останньому тегу `-beta`, але повернутися до останнього stable тегу, коли beta відсутній або старіший. - `dev`: checkout `main`, потім fetch і rebase. ### Кроки оновлення - + Потребує відсутності незакомічених змін. - + Перемикає на вибраний канал (тег або гілку). - - Лише dev. + + Лише для dev. - + Запускає lint і збірку TypeScript у тимчасовому worktree. Якщо tip не проходить, відступає назад до 10 комітів, щоб знайти найновішу чисту збірку. Виконує rebase на вибраний коміт (лише dev). - - Використовує пакетний менеджер репозиторію. Для pnpm checkout оновлювач bootstrap `pnpm` на вимогу (спершу через `corepack`, потім тимчасовий fallback `npm install pnpm@10`) замість запуску `npm run build` усередині pnpm workspace. + + Використовує менеджер пакетів репозиторію. Для pnpm checkout оновлювач завантажує `pnpm` на вимогу (спершу через `corepack`, потім як fallback тимчасовий `npm install pnpm@10`) замість запуску `npm run build` усередині pnpm workspace. - + Збирає gateway і Control UI. - + `openclaw doctor` запускається як фінальна перевірка безпечного оновлення. - - Синхронізує plugins з активним каналом. Dev використовує bundled plugins; stable і beta використовують npm. Оновлює відстежувані встановлення Plugin. + + Синхронізує plugins з активним каналом. Dev використовує bundled plugins; stable і beta використовують npm. Оновлює відстежувані встановлення plugins. -На каналі оновлень beta відстежувані встановлення npm і ClawHub Plugin, що слідують -лінії default/latest, спершу пробують випуск Plugin `@beta`. Якщо Plugin не має -beta-випуску, OpenClaw повертається до записаної специфікації default/latest. Точні -версії та явні теги не переписуються. +На каналі оновлення beta відстежувані встановлення npm і ClawHub plugins, що йдуть +лінією default/latest, спочатку пробують випуск plugin `@beta`. Якщо plugin не має +beta-випуску, OpenClaw повертається до записаної специфікації default/latest. Для npm +plugins OpenClaw також повертається назад, коли beta-пакет існує, але не проходить +перевірку встановлення. Точні версії та явні теги не переписуються. -Якщо оновлення точно закріпленого npm Plugin визначає артефакт, цілісність якого відрізняється від збереженого запису встановлення, `openclaw update` перериває це оновлення артефакта Plugin замість його встановлення. Перевстановлюйте або явно оновлюйте Plugin лише після перевірки, що ви довіряєте новому артефакту. +Якщо оновлення точно закріпленого npm plugin визначає артефакт, цілісність якого відрізняється від збереженого запису встановлення, `openclaw update` перериває оновлення цього артефакту plugin замість його встановлення. Перевстановіть або оновіть plugin явно лише після того, як переконаєтеся, що довіряєте новому артефакту. -Збої синхронізації Plugin після оновлення призводять до збою результату оновлення та зупиняють подальшу роботу з перезапуском. Виправте помилку встановлення або оновлення Plugin, потім повторно запустіть `openclaw update`. +Збої післяоновлювальної синхронізації plugin призводять до невдалого результату оновлення та зупиняють подальший перезапуск. Виправте помилку встановлення або оновлення plugin, потім повторно запустіть `openclaw update`. -Коли оновлений Gateway запускається, завантаження Plugin працює лише в режимі перевірки: startup не запускає пакетні менеджери й не змінює дерева залежностей. Перезапуски `update.run` пакетного менеджера обходять звичайне idle deferral і restart cooldown після заміни дерева пакета, тож старий процес не може продовжувати ледаче завантаження вилучених фрагментів. +Коли оновлений Gateway запускається, завантаження plugin є лише перевіркою: запуск не виконує менеджери пакетів і не змінює дерева залежностей. Перезапуски `update.run` через менеджер пакетів обходять звичайне відкладення через бездіяльність і період очікування перезапуску після заміни дерева пакета, тому старий процес не може продовжувати ліниво завантажувати вилучені фрагменти. -Якщо pnpm bootstrap усе ще завершується помилкою, оновлювач зупиняється рано з помилкою, специфічною для пакетного менеджера, замість спроби `npm run build` усередині checkout. +Якщо початкове завантаження pnpm усе ще не вдається, оновлювач зупиняється рано з помилкою, специфічною для менеджера пакетів, замість спроби виконати `npm run build` усередині checkout. ## Скорочення `--update` -`openclaw --update` переписується на `openclaw update` (корисно для оболонок і launcher scripts). +`openclaw --update` переписується на `openclaw update` (корисно для shell-оболонок і launcher-скриптів). -## Пов'язане +## Пов’язане -- `openclaw doctor` (пропонує спершу запустити оновлення для git checkout) +- `openclaw doctor` (пропонує спочатку запустити оновлення для git checkout) - [Канали розробки](/uk/install/development-channels) - [Оновлення](/uk/install/updating) - [Довідник CLI](/uk/cli) diff --git a/docs/uk/help/testing-updates-plugins.md b/docs/uk/help/testing-updates-plugins.md index 401dc1d4a..8125980ff 100644 --- a/docs/uk/help/testing-updates-plugins.md +++ b/docs/uk/help/testing-updates-plugins.md @@ -2,48 +2,50 @@ read_when: - Зміна поведінки оновлення OpenClaw, doctor, приймання пакета або встановлення Plugin - Підготовка або затвердження реліз-кандидата - - Налагодження регресій оновлення пакета, очищення залежностей Plugin або встановлення Plugin + - Налагодження оновлення пакета, очищення залежностей Plugin або регресій встановлення Plugin sidebarTitle: Update and plugin tests summary: Як OpenClaw перевіряє шляхи оновлення, міграції пакетів і поведінку встановлення/оновлення Plugin -title: 'Тестування: оновлення та Plugins' +title: 'Тестування: оновлення та плагіни' x-i18n: - generated_at: "2026-05-03T08:23:00Z" + generated_at: "2026-05-04T21:00:01Z" model: gpt-5.5 provider: openai - source_hash: 309ac7785a8d49db241989d28580887d3f6739982108af7148b624082c5f23dd + source_hash: e83a847c76f424199b5fccbd9a2b30d0bf01e4f466c4f9822bf7693d1c2ad286 source_path: help/testing-updates-plugins.md workflow: 16 --- Це спеціальний контрольний список для перевірки оновлень і Plugin. Мета -проста: довести, що встановлюваний пакет може оновлювати реальний стан користувача, виправляти застарілий -legacy-стан через `doctor` і досі встановлювати, завантажувати, оновлювати та видаляти -Plugin із підтримуваних джерел. +проста: довести, що інстальований пакет може оновлювати реальний стан +користувача, відновлювати застарілий legacy-стан через `doctor` і далі +встановлювати, завантажувати, оновлювати та видаляти Plugin з підтримуваних +джерел. -Для ширшої мапи засобу запуску тестів див. [Тестування](/uk/help/testing). Для live-ключів провайдерів -і наборів тестів, що торкаються мережі, див. [Live-тестування](/uk/help/testing-live). +Ширшу мапу тестового runner див. у [Тестування](/uk/help/testing). Для ключів +live provider і suite, що торкаються мережі, див. [Live-тестування](/uk/help/testing-live). ## Що ми захищаємо -Тести оновлень і Plugin захищають ці контракти: +Тести оновлень і Plugin захищають такі контракти: -- Tarball пакета є повним, має валідний `dist/postinstall-inventory.json` - і не залежить від розпакованих файлів репозиторію. -- Користувач може перейти зі старішого опублікованого пакета на пакет-кандидат - без втрати конфігурації, агентів, сесій, робочих просторів, allowlist Plugin або - конфігурації каналу. -- `openclaw doctor --fix --non-interactive` володіє шляхами очищення та виправлення - legacy-стану. Startup не має розростатися прихованими міграціями сумісності для застарілого - стану Plugin. -- Встановлення Plugin працює з локальних каталогів, git-репозиторіїв, npm-пакетів і - шляху реєстру ClawHub. +- Tarball пакета є повним, має чинний `dist/postinstall-inventory.json` і не + залежить від розпакованих файлів репозиторію. +- Користувач може перейти зі старішого опублікованого пакета на кандидатний + пакет без втрати config, agents, sessions, workspaces, allowlist Plugin або + config каналів. +- `openclaw doctor --fix --non-interactive` володіє шляхами legacy-очищення та + відновлення. Startup не має нарощувати приховані compatibility-міграції для + застарілого стану Plugin. +- Встановлення Plugin працює з локальних директорій, git repo, npm packages і + шляху registry ClawHub. - npm-залежності Plugin встановлюються в керований npm root, скануються перед - довірою і видаляються через npm під час видалення, щоб hoisted-залежності не + довірою та видаляються через npm під час uninstall, щоб hoisted залежності не залишалися. -- Оновлення Plugin стабільне, коли нічого не змінилося: записи встановлення, resolved - source, структура встановлених залежностей і enabled-стан залишаються неушкодженими. +- Оновлення Plugin стабільне, коли нічого не змінилося: install records, + resolved source, installed dependency layout і enabled state залишаються + незмінними. -## Локальний доказ під час розробки +## Локальне підтвердження під час розробки Починайте вузько: @@ -53,30 +55,32 @@ pnpm check:changed pnpm test:changed ``` -Для змін установлення, видалення, залежностей Plugin або package-inventory також -запустіть сфокусовані тести, що покривають змінений seam: +Для змін у install, uninstall, залежностях або package-inventory Plugin також +запускайте сфокусовані тести, що покривають відредагований seam: ```bash pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts ``` -Перш ніж будь-яка package Docker lane використає tarball, доведіть артефакт пакета: +Перед тим як будь-яка package Docker lane споживатиме tarball, підтвердьте +артефакт пакета: ```bash pnpm release:check ``` -`release:check` запускає перевірки drift для конфігурації/документації/API, записує package dist -inventory, запускає `npm pack --dry-run`, відхиляє заборонені запаковані файли, встановлює -tarball у тимчасовий prefix, запускає postinstall і smoke-тестує bundled entrypoints каналів. +`release:check` запускає перевірки drift config/docs/API, записує package dist +inventory, виконує `npm pack --dry-run`, відхиляє заборонені packed files, +встановлює tarball у тимчасовий prefix, запускає postinstall і smoke-тестує +entrypoints bundled channel. ## Docker lanes -Docker lanes є доказом рівня продукту. Вони встановлюють або оновлюють реальний -пакет усередині Linux-контейнерів і перевіряють поведінку через CLI-команди, -запуск Gateway, HTTP-зонди, RPC-статус і стан файлової системи. +Docker lanes є підтвердженням на рівні продукту. Вони встановлюють або +оновлюють реальний пакет у Linux containers і перевіряють поведінку через CLI +commands, startup Gateway, HTTP probes, RPC status і filesystem state. -Використовуйте сфокусовані lanes під час ітерацій: +Під час ітерацій використовуйте сфокусовані lanes: ```bash pnpm test:docker:plugins @@ -89,32 +93,32 @@ pnpm test:docker:update-migration Важливі lanes: -- `test:docker:plugins` перевіряє plugin install smoke, встановлення локальних папок, - skip-поведінку оновлення локальних папок, локальні папки з попередньо встановленими - залежностями, встановлення `file:`-пакетів, git-встановлення з виконанням CLI, оновлення git - moving-ref, встановлення з npm-реєстру з hoisted transitive - dependencies, no-op оновлення npm, встановлення з локального ClawHub fixture та no-op - оновлення, поведінку marketplace update і enable/inspect для Claude-bundle. Встановіть - `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок ClawHub залишався hermetic/offline. -- `test:docker:plugin-lifecycle-matrix` встановлює пакет-кандидат у чистому - контейнері, проводить npm Plugin через install, inspect, disable, enable, +- `test:docker:plugins` перевіряє smoke install Plugin, installs local folder, + поведінку skip для update local folder, local folders із попередньо + встановленими залежностями, installs `file:` package, git installs із CLI + execution, git moving-ref updates, npm registry installs із hoisted transitive + dependencies, no-op для npm update, installs local ClawHub fixture і no-op + update, поведінку marketplace update і Claude-bundle enable/inspect. Задайте + `OPENCLAW_PLUGINS_E2E_CLAWHUB=0`, щоб блок ClawHub був hermetic/offline. +- `test:docker:plugin-lifecycle-matrix` встановлює candidate package у bare + container, проганяє npm Plugin через install, inspect, disable, enable, explicit upgrade, explicit downgrade і uninstall після видалення коду Plugin. - Він логує RSS і CPU-метрики для кожної фази. -- `test:docker:plugin-update` перевіряє, що незмінений установлений Plugin - не перевстановлюється і не втрачає metadata встановлення під час `openclaw plugins update`. -- `test:docker:upgrade-survivor` встановлює tarball-кандидат поверх брудного - old-user fixture, запускає package update плюс non-interactive doctor, потім запускає - local loopback Gateway і перевіряє збереження стану. -- `test:docker:published-upgrade-survivor` спершу встановлює опублікований baseline, - налаштовує його через baked recipe `openclaw config set`, оновлює його до - tarball-кандидата, запускає doctor, перевіряє legacy cleanup, запускає Gateway і - зондує `/healthz`, `/readyz` і RPC-статус. -- `test:docker:update-migration` — cleanup-heavy lane опублікованого оновлення. Вона - стартує з налаштованого Discord/Telegram-style стану користувача, запускає baseline - doctor, щоб налаштовані залежності Plugin мали шанс матеріалізуватися, сідує - legacy plugin dependency debris для налаштованого packaged Plugin, оновлює до - tarball-кандидата і вимагає від post-update doctor видалити legacy - dependency roots. + Він логуватиме RSS і CPU metrics для кожної фази. +- `test:docker:plugin-update` перевіряє, що незмінений встановлений Plugin не + перевстановлюється і не втрачає install metadata під час `openclaw plugins update`. +- `test:docker:upgrade-survivor` встановлює candidate tarball поверх dirty + old-user fixture, запускає package update плюс non-interactive doctor, потім + стартує Gateway на loopback і перевіряє збереження стану. +- `test:docker:published-upgrade-survivor` спочатку встановлює published + baseline, налаштовує його через baked recipe `openclaw config set`, оновлює + до candidate tarball, запускає doctor, перевіряє legacy cleanup, стартує + Gateway і пробує `/healthz`, `/readyz` та RPC status. +- `test:docker:update-migration` є cleanup-heavy published-update lane. Він + стартує з налаштованого користувацького стану у стилі Discord/Telegram, + запускає baseline doctor, щоб configured plugin dependencies мали шанс + матеріалізуватися, сіє legacy plugin dependency debris для configured + packaged Plugin, оновлює до candidate tarball і вимагає, щоб post-update + doctor видалив legacy dependency roots. Корисні варіанти published-upgrade survivor: @@ -129,15 +133,15 @@ pnpm test:docker:published-upgrade-survivor ``` Доступні сценарії: `base`, `feishu-channel`, `bootstrap-persona`, -`plugin-deps-cleanup`, `configured-plugin-installs`, `tilde-log-path` і -`versioned-runtime-deps`. В aggregate runs, -`OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі reported -issue-shaped сценарії, включно з міграцією configured-plugin install. +`plugin-deps-cleanup`, `configured-plugin-installs`, +`stale-source-plugin-shadow`, `tilde-log-path` і `versioned-runtime-deps`. В aggregate runs +`OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues` розгортається в усі +сценарії, сформовані як reported issues, включно з configured-plugin install migration. -Повна update migration навмисно відокремлена від Full Release CI. Використовуйте -ручний workflow `Update Migration`, коли питання релізу звучить так: "чи може кожен -опублікований stable release від 2026.4.23 і далі оновитися до цього кандидата і -очистити plugin dependency debris?": +Full update migration навмисно відокремлена від Full Release CI. Використовуйте +manual workflow `Update Migration`, коли release question звучить як "чи може +кожен опублікований stable release від 2026.4.23 і далі оновитися до цього +candidate і очистити plugin dependency debris?": ```bash gh workflow run update-migration.yml \ @@ -150,27 +154,27 @@ gh workflow run update-migration.yml \ ## Package Acceptance -Package Acceptance — це GitHub-native package gate. Він resolve-ить один пакет-кандидат -у tarball `package-under-test`, записує версію та SHA-256, а потім +Package Acceptance є GitHub-native package gate. Він розвʼязує один candidate +package у tarball `package-under-test`, записує version і SHA-256, а потім запускає reusable Docker E2E lanes проти саме цього tarball. Workflow harness -ref відокремлений від package source ref, тому поточна логіка тестів може перевіряти -старіші trusted releases. +ref відокремлений від package source ref, тому поточна test logic може +перевіряти старіші trusted releases. -Джерела кандидатів: +Candidate sources: - `source=npm`: перевірити `openclaw@beta`, `openclaw@latest` або точну - опубліковану версію. -- `source=ref`: запакувати trusted branch, tag або commit з вибраним поточним + published version. +- `source=ref`: запакувати trusted branch, tag або commit з вибраним current harness. -- `source=url`: перевірити HTTPS tarball з обов’язковим `package_sha256`. +- `source=url`: перевірити HTTPS tarball з обовʼязковим `package_sha256`. - `source=artifact`: повторно використати tarball, завантажений іншим Actions run. -Full Release Validation за замовчуванням використовує `source=artifact`, побудований із -resolved release SHA. Для post-publish доказу передайте +Full Release Validation типово використовує `source=artifact`, зібраний із +resolved release SHA. Для post-publish proof передайте `package_acceptance_package_spec=openclaw@YYYY.M.D`, щоб та сама upgrade matrix -цілилася в shipped npm package натомість. +цілилася в shipped npm package. -Release checks викликають Package Acceptance з package/update/plugin set: +Release checks викликають Package Acceptance із package/update/plugin set: ```text doctor-switch update-channel-switch upgrade-survivor published-upgrade-survivor plugins-offline plugin-update @@ -184,17 +188,17 @@ published_upgrade_survivor_scenarios=reported-issues telegram_mode=mock-openai ``` -Це тримає package migration, update channel switching, cleanup застарілих plugin dependency, -offline-покриття Plugin, поведінку оновлення Plugin і Telegram package -QA на тому самому resolved artifact. +Це тримає package migration, update channel switching, stale plugin dependency +cleanup, offline plugin coverage, plugin update behavior і Telegram package QA +на одному resolved artifact. -`all-since-2026.4.23` — це upgrade sample Full Release CI: кожен stable npm-published release від `2026.4.23` до `latest`. Для вичерпного покриття published -update migration використовуйте `all-since-2026.4.23` в окремому workflow Update -Migration замість Full Release CI. `release-history` залишається +`all-since-2026.4.23` є upgrade sample для Full Release CI: кожен stable npm-published release від `2026.4.23` до `latest`. Для exhaustive coverage +published update migration використовуйте `all-since-2026.4.23` в окремому +workflow Update Migration замість Full Release CI. `release-history` лишається доступним для ручного ширшого sampling, коли вам також потрібен legacy pre-date anchor. -Запустіть package profile вручну під час перевірки кандидата перед релізом: +Запустіть package profile вручну під час перевірки candidate перед release: ```bash gh workflow run package-acceptance.yml \ @@ -208,70 +212,73 @@ gh workflow run package-acceptance.yml \ -f telegram_mode=mock-openai ``` -Використовуйте `suite_profile=product`, коли питання релізу включає MCP-канали, -cleanup cron/subagent, OpenAI web search або OpenWebUI. Використовуйте `suite_profile=full` -лише тоді, коли потрібне повне Docker-покриття release-path. +Використовуйте `suite_profile=product`, коли release question включає MCP +channels, cleanup cron/subagent, OpenAI web search або OpenWebUI. +Використовуйте `suite_profile=full` лише тоді, коли потрібне повне покриття +Docker release-path. -## Типове значення для релізу +## Стандарт для release -Для release candidates типовий стек доказів такий: +Для release candidates стандартний proof stack такий: -1. `pnpm check:changed` і `pnpm test:changed` для source-level regressions. -2. `pnpm release:check` для цілісності артефакту пакета. -3. Package Acceptance `package` profile або release-check custom package +1. `pnpm check:changed` і `pnpm test:changed` для регресій на рівні source. +2. `pnpm release:check` для цілісності package artifact. +3. Package Acceptance profile `package` або release-check custom package lanes для контрактів install/update/plugin. 4. Cross-OS release checks для OS-specific installer, onboarding і platform behavior. -5. Live-набори лише тоді, коли змінена surface торкається поведінки провайдера або hosted-service. +5. Live suites лише тоді, коли змінена surface торкається provider або hosted-service + behavior. -На maintainer machines широкі gates і Docker/package product proof мають запускатися -в Testbox, якщо явно не виконується local proof. +На maintainer machines широкі gates і Docker/package product proof мають +запускатися в Testbox, якщо явно не виконується local proof. -## Legacy-сумісність +## Legacy compatibility -Leniency сумісності є вузькою і time boxed: +Compatibility leniency є вузькою і обмеженою в часі: -- Пакети до `2026.4.25` включно, включно з `2026.4.25-beta.*`, можуть tolerates - вже shipped package metadata gaps у Package Acceptance. -- Опублікований пакет `2026.4.26` може попереджати про local build metadata stamp - files, які вже були shipped. -- Пізніші пакети мають відповідати modern contracts. Ті самі gaps fail замість - warning або skipping. +- Packages до `2026.4.25` включно, зокрема `2026.4.25-beta.*`, можуть + толерувати вже shipped package metadata gaps у Package Acceptance. +- Опублікований package `2026.4.26` може попереджати про local build metadata + stamp files, які вже shipped. +- Пізніші packages мають відповідати сучасним контрактам. Ті самі gaps + fail замість warning або skipping. -Не додавайте нові startup migrations для цих старих shapes. Додайте або розширте doctor -repair, потім доведіть це за допомогою `upgrade-survivor` або `published-upgrade-survivor`. +Не додавайте нові startup migrations для цих старих форм. Додайте або +розширте doctor repair, потім підтвердьте це через `upgrade-survivor` або +`published-upgrade-survivor`. ## Додавання покриття -Коли змінюєте поведінку оновлення або Plugin, додавайте покриття на найнижчому рівні, який -може fail з правильної причини: +Коли змінюєте update або plugin behavior, додавайте coverage на найнижчому +рівні, який може fail з правильної причини: -- Чиста path або metadata logic: unit test поруч із source. -- Package inventory або packed-file behavior: `package-dist-inventory` або tarball - checker test. +- Pure path або metadata logic: unit test поруч із source. +- Package inventory або packed-file behavior: `package-dist-inventory` або + tarball checker test. - CLI install/update behavior: Docker lane assertion або fixture. -- Published-release migration behavior: сценарій `published-upgrade-survivor`. -- Registry/package source behavior: fixture `test:docker:plugins` або сервер fixture - ClawHub. +- Published-release migration behavior: scenario `published-upgrade-survivor`. +- Registry/package source behavior: fixture `test:docker:plugins` або ClawHub + fixture server. - Dependency layout або cleanup behavior: перевіряйте і runtime execution, і filesystem boundary. npm dependencies можуть бути hoisted під managed npm - root, тому тести мають довести, що root сканується/очищається, замість припускати - package-local дерево `node_modules`. + root, тому тести мають доводити, що root сканується/очищається, замість + припускати package-local дерево `node_modules`. -Нові Docker fixtures за замовчуванням мають бути hermetic. Використовуйте локальні fixture registries і -fake packages, якщо тільки мета тесту не полягає в live registry behavior. +Нові Docker fixtures типово мають бути hermetic. Використовуйте local fixture +registries і fake packages, якщо метою тесту не є live registry behavior. -## Тріаж помилок +## Тріаж збоїв -Починайте з ідентичності артефакту: +Починайте з artifact identity: -- Package Acceptance `resolve_package` summary: source, version, SHA-256 і +- Summary Package Acceptance `resolve_package`: source, version, SHA-256 і artifact name. - Docker artifacts: `.artifacts/docker-tests/**/summary.json`, `failures.json`, lane logs і rerun commands. -- Upgrade survivor summary: `.artifacts/upgrade-survivor/summary.json`, +- Summary upgrade survivor: `.artifacts/upgrade-survivor/summary.json`, включно з baseline version, candidate version, scenario, phase timings і recipe steps. -Віддавайте перевагу повторному запуску точної failed lane з тим самим package artifact над -повторним запуском усього release umbrella. +Надавайте перевагу rerun точного failed lane з тим самим package artifact, а не +rerun усього release umbrella. diff --git a/docs/uk/plugins/manage-plugins.md b/docs/uk/plugins/manage-plugins.md index 715729c09..906e89b5b 100644 --- a/docs/uk/plugins/manage-plugins.md +++ b/docs/uk/plugins/manage-plugins.md @@ -1,24 +1,23 @@ --- read_when: - - Вам потрібні короткі приклади встановлення, виведення списку, оновлення або видалення Plugin - - Ви хочете вибрати між ClawHub і розповсюдженням плагінів через npm + - Вам потрібні швидкі приклади встановлення, перегляду списку, оновлення або видалення Plugin + - Ви хочете вибрати між ClawHub і розповсюдженням Plugin через npm - Ви публікуєте пакет Plugin sidebarTitle: Manage plugins summary: Короткі приклади встановлення, перегляду списку, видалення, оновлення та публікації плагінів OpenClaw title: Керування Plugin x-i18n: - generated_at: "2026-05-02T21:59:46Z" + generated_at: "2026-05-04T20:59:59Z" model: gpt-5.5 provider: openai - source_hash: ec25a811b942f155f5d5e4cac475dbef74f0616bc85ff182c74598184e910320 + source_hash: 7fa7aa78c1ba9c83ba09bea073987ed5e037031f7c7f29307fe18934b0bd2a1c source_path: plugins/manage-plugins.md workflow: 16 --- -Більшість робочих процесів із plugin складаються з кількох команд: пошук, установлення, перезапуск Gateway, -перевірка та видалення, коли plugin більше не потрібен. +Більшість робочих процесів із плагінами складаються з кількох команд: пошук, встановлення, перезапуск Gateway, перевірка та видалення, коли плагін більше не потрібен. -## Список plugins +## Список плагінів ```bash openclaw plugins list @@ -27,20 +26,16 @@ openclaw plugins list --verbose openclaw plugins list --json ``` -Використовуйте `--json` для скриптів. Він містить діагностику реєстру та статичний -`dependencyStatus` кожного plugin, коли пакет plugin оголошує `dependencies` або -`optionalDependencies`. +Використовуйте `--json` для скриптів. Він містить діагностику реєстру та статичний `dependencyStatus` кожного плагіна, коли пакет плагіна оголошує `dependencies` або `optionalDependencies`. ```bash openclaw plugins list --json \ | jq '.plugins[] | {id, enabled, format, source, dependencyStatus}' ``` -`plugins list` — це холодна перевірка інвентаризації. Вона показує, що OpenClaw може виявити -з конфігурації, маніфестів і реєстру plugin; вона не доводить, що вже запущений -процес Gateway імпортував runtime plugin. +`plugins list` — це холодна перевірка інвентарю. Вона показує, що OpenClaw може виявити з конфігурації, маніфестів і реєстру плагінів; вона не доводить, що вже запущений процес Gateway імпортував runtime плагіна. -## Установлення plugins +## Встановлення плагінів ```bash # Search ClawHub for plugin packages. @@ -65,18 +60,16 @@ openclaw plugins install ./my-plugin openclaw plugins install --link ./my-plugin ``` -Після встановлення коду plugin перезапустіть Gateway, який обслуговує ваші канали: +Після встановлення коду плагіна перезапустіть Gateway, який обслуговує ваші канали: ```bash openclaw gateway restart openclaw plugins inspect --runtime --json ``` -Використовуйте `inspect --runtime`, коли потрібен доказ, що plugin зареєстрував runtime- -поверхні, як-от інструменти, хуки, сервіси, методи Gateway або CLI- -команди, що належать plugin. +Використовуйте `inspect --runtime`, коли вам потрібен доказ, що плагін зареєстрував runtime-поверхні, як-от інструменти, хуки, сервіси, методи Gateway або CLI-команди, що належать плагіну. -## Оновлення plugins +## Оновлення плагінів ```bash openclaw plugins update @@ -84,24 +77,18 @@ openclaw plugins update openclaw plugins update --all ``` -Якщо plugin було встановлено з npm dist-tag, наприклад `@beta`, подальші виклики -`update ` повторно використовують цей записаний тег. Передавання явної npm-специфікації -перемикає відстежуване встановлення на цю специфікацію для майбутніх оновлень. +Якщо плагін було встановлено з npm dist-tag, наприклад `@beta`, подальші виклики `update ` повторно використовують цей записаний тег. Передавання явної npm-специфікації перемикає відстежуване встановлення на цю специфікацію для майбутніх оновлень. ```bash openclaw plugins update @scope/openclaw-plugin@beta openclaw plugins update @scope/openclaw-plugin ``` -Друга команда повертає plugin до типової лінії випусків реєстру, -якщо раніше він був закріплений за точною версією або тегом. +Друга команда повертає плагін до стандартної лінії випусків реєстру, якщо раніше він був закріплений за точною версією або тегом. -Коли `openclaw update` запускається на beta-каналі, записи plugin npm і ClawHub -типової лінії спершу пробують відповідний випуск plugin `@beta`. Якщо такого beta- -випуску не існує, OpenClaw повертається до записаної типової/latest специфікації. -Точні версії та явні теги, як-от `@rc` або `@beta`, зберігаються. +Коли `openclaw update` виконується на beta-каналі, записи npm і ClawHub-плагінів зі стандартної лінії спочатку пробують відповідний випуск плагіна `@beta`. Якщо такого beta-випуску не існує, OpenClaw повертається до записаної стандартної/найновішої специфікації. Для npm-плагінів OpenClaw також повертається до неї, коли beta-пакет існує, але не проходить перевірку встановлення. Точні версії та явні теги, як-от `@rc` або `@beta`, зберігаються. -## Видалення plugins +## Видалення плагінів ```bash openclaw plugins uninstall --dry-run @@ -110,20 +97,15 @@ openclaw plugins uninstall --keep-files openclaw gateway restart ``` -Видалення прибирає запис конфігурації plugin, запис індексу plugin, записи списків allow/deny -і пов’язані шляхи завантаження, коли це застосовно. Керовані каталоги встановлення -видаляються, якщо ви не передали `--keep-files`. +Видалення прибирає конфігураційний запис плагіна, запис індексу плагінів, записи списків дозволів/заборон і пов’язані шляхи завантаження, коли це застосовно. Керовані каталоги встановлення видаляються, якщо ви не передасте `--keep-files`. -## Публікація plugins +## Публікація плагінів -Ви можете публікувати зовнішні plugins у [ClawHub](https://clawhub.ai), npmjs.com або -в обох місцях. +Ви можете публікувати зовнішні плагіни в [ClawHub](https://clawhub.ai), npmjs.com або в обидва місця. ### Публікація в ClawHub -ClawHub — це основна публічна поверхня виявлення для plugins OpenClaw. Він надає -користувачам метадані з пошуком, історію версій і результати сканування реєстру перед -установленням. +ClawHub — це основна публічна поверхня виявлення плагінів OpenClaw. Вона надає користувачам доступні для пошуку метадані, історію версій і результати сканування реєстру перед встановленням. ```bash npm i -g clawhub @@ -133,19 +115,18 @@ clawhub package publish your-org/your-plugin clawhub package publish your-org/your-plugin@v1.0.0 ``` -Користувачі встановлюють із ClawHub так: +Користувачі встановлюють із ClawHub за допомогою: ```bash openclaw plugins install clawhub: openclaw plugins install ``` -Форма без префікса все одно спочатку перевіряє ClawHub. +Скорочена форма й надалі спочатку перевіряє ClawHub. ### Публікація в npmjs.com -Нативні npm plugins мають містити маніфест plugin і метадані точки входу OpenClaw -у `package.json`. +Нативні npm-плагіни мають містити маніфест плагіна та метадані точки входу OpenClaw у `package.json`. ```json package.json { @@ -162,7 +143,7 @@ openclaw plugins install npm publish --access public ``` -Користувачі встановлюють npm-only так: +Користувачі встановлюють лише з npm за допомогою: ```bash openclaw plugins install npm:@acme/openclaw-plugin @@ -170,23 +151,19 @@ openclaw plugins install npm:@acme/openclaw-plugin@beta openclaw plugins install npm:@acme/openclaw-plugin@1.0.0 ``` -Якщо той самий пакет також доступний у ClawHub, `npm:` пропускає пошук у ClawHub і -примусово використовує розв’язання через npm. +Якщо той самий пакет також доступний у ClawHub, `npm:` пропускає пошук у ClawHub і примусово використовує розв’язання через npm. ## Вибір джерела -- **ClawHub**: використовуйте, коли потрібні нативне для OpenClaw виявлення, підсумки сканування, - версії та підказки щодо встановлення. -- **npmjs.com**: використовуйте, коли ви вже постачаєте пакети JavaScript або потребуєте npm - dist-tags/робочих процесів приватного реєстру. -- **Git**: використовуйте, коли хочете встановлювати безпосередньо з гілки, тега або коміту. -- **Локальний шлях**: використовуйте, коли розробляєте або тестуєте plugin на тій самій - машині. +- **ClawHub**: використовуйте, коли потрібні нативне для OpenClaw виявлення, підсумки сканування, версії та підказки зі встановлення. +- **npmjs.com**: використовуйте, коли ви вже постачаєте JavaScript-пакети або потребуєте робочих процесів npm dist-tag/приватного реєстру. +- **Git**: використовуйте, коли хочете встановити безпосередньо з гілки, тегу або коміту. +- **Локальний шлях**: використовуйте, коли розробляєте або тестуєте плагін на тому самому комп’ютері. ## Пов’язане -- [Plugins](/uk/tools/plugin) - огляд і усунення несправностей +- [Плагіни](/uk/tools/plugin) - огляд і усунення несправностей - [`openclaw plugins`](/uk/cli/plugins) - повна довідка CLI -- [ClawHub](/uk/tools/clawhub) - публікація та операції реєстру -- [Створення plugins](/uk/plugins/building-plugins) - створення пакета plugin -- [Маніфест plugin](/uk/plugins/manifest) - маніфест і метадані пакета +- [ClawHub](/uk/tools/clawhub) - публікація та операції з реєстром +- [Створення плагінів](/uk/plugins/building-plugins) - створення пакета плагіна +- [Маніфест плагіна](/uk/plugins/manifest) - маніфест і метадані пакета diff --git a/docs/uk/reference/test.md b/docs/uk/reference/test.md index c4c20abbc..fe45e2d1a 100644 --- a/docs/uk/reference/test.md +++ b/docs/uk/reference/test.md @@ -4,60 +4,60 @@ read_when: summary: Як запускати тести локально (vitest) і коли використовувати режими примусового запуску/покриття title: Тести x-i18n: - generated_at: "2026-05-02T18:58:20Z" + generated_at: "2026-05-04T20:59:41Z" model: gpt-5.5 provider: openai - source_hash: 8a88599d079e1ca42d73d354b582d67dd85be40fc92eed5abe6dcef37dc21f4f + source_hash: 7e8421518d63cade24ce8c2a08fa10538b66d2332b1eb5744e47c6d5a5e84605 source_path: reference/test.md workflow: 16 --- -- Повний набір для тестування (набори, live, Docker): [Тестування](/uk/help/testing) -- Перевірка оновлень і пакетів Plugin: [Тестування оновлень і плагінів](/uk/help/testing-updates-plugins) +- Повний набір для тестування (набори тестів, live, Docker): [Тестування](/uk/help/testing) +- Перевірка оновлень і пакетів Plugin: [Тестування оновлень і Plugin](/uk/help/testing-updates-plugins) -- `pnpm test:force`: завершує будь-який залишковий процес gateway, що утримує стандартний порт керування, а потім запускає повний набір Vitest з ізольованим портом Gateway, щоб серверні тести не конфліктували із запущеним екземпляром. Використовуйте це, коли попередній запуск Gateway залишив порт 18789 зайнятим. -- `pnpm test:coverage`: запускає модульний набір із покриттям V8 (через `vitest.unit.config.ts`). Це gate покриття модульних тестів для завантажених файлів, а не покриття всіх файлів усього репозиторію. Пороги: 70% для рядків/функцій/інструкцій і 55% для гілок. Оскільки `coverage.all` має значення false, gate вимірює файли, завантажені набором модульного покриття, замість того щоб вважати кожен split-lane вихідний файл непокритим. -- `pnpm test:coverage:changed`: запускає модульне покриття лише для файлів, змінених відносно `origin/main`. -- `pnpm test:changed`: дешевий інтелектуальний запуск тестів для змін. Він запускає точні цілі з прямих змін тестів, сусідніх файлів `*.test.ts`, явних зіставлень джерел і локального графа імпортів. Широкі зміни конфігурації/пакетів пропускаються, якщо вони не зіставляються з точними тестами. -- `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed`: явний широкий запуск тестів для змін. Використовуйте його, коли зміна test harness/config/package має повертатися до ширшої поведінки Vitest для змінених тестів. -- `pnpm changed:lanes`: показує архітектурні доріжки, спричинені diff відносно `origin/main`. -- `pnpm check:changed`: запускає інтелектуальний check gate для diff відносно `origin/main`. Він запускає typecheck, lint і guard-команди для зачеплених архітектурних доріжок, але не запускає тести Vitest. Використовуйте `pnpm test:changed` або явний `pnpm test ` для тестового підтвердження. -- `pnpm test`: спрямовує явні цілі файлів/каталогів через scoped Vitest-доріжки. Запуски без цілей використовують фіксовані групи шардів і розгортаються до листових конфігурацій для локального паралельного виконання; група розширень завжди розгортається до per-extension shard-конфігурацій замість одного великого процесу root-project. -- Запуски тестового wrapper завершуються коротким підсумком `[test] passed|failed|skipped ... in ...`. Власний рядок тривалості Vitest залишається деталлю для кожного шарда. -- Спільний тестовий стан OpenClaw: використовуйте `src/test-utils/openclaw-test-state.ts` з Vitest, коли тесту потрібні ізольовані `HOME`, `OPENCLAW_STATE_DIR`, `OPENCLAW_CONFIG_PATH`, config fixture, workspace, agent dir або auth-profile store. -- Process E2E helpers: використовуйте `test/helpers/openclaw-test-instance.ts`, коли process-level E2E тесту Vitest потрібні запущений Gateway, CLI env, захоплення логів і очищення в одному місці. -- Docker/Bash E2E helpers: доріжки, що source `scripts/lib/docker-e2e-image.sh`, можуть передати `docker_e2e_test_state_shell_b64