diff --git a/docs/uk/gateway/diagnostics.md b/docs/uk/gateway/diagnostics.md index 11159ec0f..2c3993d9e 100644 --- a/docs/uk/gateway/diagnostics.md +++ b/docs/uk/gateway/diagnostics.md @@ -1,26 +1,26 @@ --- read_when: - Підготовка звіту про помилку або запиту на підтримку - - Налагодження аварійних завершень Gateway, перезапусків, тиску на пам’ять або надмірно великих корисних навантажень + - Налагодження аварійних завершень Gateway, перезапусків, тиску на пам’ять або завеликих корисних навантажень - Перегляд того, які діагностичні дані записуються або приховуються -summary: Створюйте поширювані діагностичні пакети Gateway для звітів про помилки +summary: Створюйте діагностичні пакети Gateway для звітів про помилки, якими можна ділитися title: Експорт діагностики x-i18n: - generated_at: "2026-05-02T04:01:30Z" + generated_at: "2026-05-03T18:32:10Z" model: gpt-5.5 provider: openai - source_hash: 4d1f7c1e1d96aeeebe30b30c8a23ec3c7b0fb4938f15a3783bf22e861770bf78 + source_hash: f6cf8e00fe8033e339b5c947ce3dd10fdee736048a358ad3a0c2ccb77e939f4b source_path: gateway/diagnostics.md workflow: 16 --- -OpenClaw може створити локальний zip-файл діагностики для звітів про помилки. Він об’єднує -очищені стан Gateway, працездатність, журнали, форму конфігурації та нещодавні -події стабільності без вмісту payload. +OpenClaw може створити локальний zip-архів діагностики для звітів про помилки. Він поєднує +санітизований стан Gateway, справність, журнали, форму конфігурації та нещодавні події +стабільності без payload. Ставтеся до діагностичних пакетів як до секретів, доки не переглянете їх. Вони -спроєктовані так, щоб пропускати або редагувати payload і облікові дані, але все одно підсумовують -локальні журнали Gateway і стан runtime на рівні хоста. +спроєктовані так, щоб пропускати або редагувати payload і облікові дані, але все одно узагальнюють +локальні журнали Gateway і стан середовища виконання на рівні хоста. ## Швидкий старт @@ -28,7 +28,7 @@ OpenClaw може створити локальний zip-файл діагно openclaw gateway diagnostics export ``` -Команда друкує шлях до записаного zip-файлу. Щоб вибрати шлях: +Команда виводить шлях до записаного zip-архіву. Щоб вибрати шлях: ```bash openclaw gateway diagnostics export --output openclaw-diagnostics.zip @@ -43,91 +43,92 @@ openclaw gateway diagnostics export --json ## Команда чату Власники можуть використовувати `/diagnostics [note]` у чаті, щоб запросити локальний експорт Gateway. -Використовуйте це, коли помилка сталася в реальній розмові і вам потрібен один -звіт для підтримки, який можна скопіювати й вставити: +Використовуйте це, коли помилка сталася в реальній розмові й потрібен один +звіт для підтримки, який можна скопіювати та вставити: 1. Надішліть `/diagnostics` у розмові, де ви помітили проблему. Додайте коротку нотатку, якщо це допоможе, наприклад `/diagnostics bad tool choice`. -2. OpenClaw надсилає вступ до діагностики та просить одне явне схвалення exec. - Схвалення запускає `openclaw gateway diagnostics export --json`. - Не схвалюйте діагностику через правило allow-all. -3. Після схвалення OpenClaw відповідає звітом для вставлення, що містить локальний - шлях пакета, підсумок маніфесту, примітки щодо приватності та відповідні ідентифікатори сесій. +2. OpenClaw надсилає преамбулу діагностики й просить одне явне підтвердження exec. + Підтвердження запускає `openclaw gateway diagnostics export --json`. + Не підтверджуйте діагностику через правило allow-all. +3. Після підтвердження OpenClaw відповідає звітом для вставлення, який містить локальний + шлях до пакета, підсумок маніфесту, нотатки про приватність і відповідні ідентифікатори сеансів. -У групових чатах власник усе ще може запустити `/diagnostics`, але OpenClaw не -публікує діагностичні подробиці назад у спільний чат. Він надсилає вступ, -запити схвалення, результат експорту Gateway і розбір сесії/треду Codex -власнику через приватний маршрут схвалення. Група отримує лише коротке повідомлення -про те, що діагностичний потік було надіслано приватно. Якщо OpenClaw не може знайти приватний +У групових чатах власник усе ще може запускати `/diagnostics`, але OpenClaw не +публікує діагностичні деталі назад у спільний чат. Він надсилає преамбулу, +запити підтвердження, результат експорту Gateway і розбивку сеансів/потоків Codex +власнику через приватний маршрут підтвердження. Група отримує лише коротке сповіщення +про те, що діагностичний процес було надіслано приватно. Якщо OpenClaw не може знайти приватний маршрут до власника, команда завершується безпечною відмовою і просить власника запустити її з DM. -Коли активна сесія OpenClaw використовує нативний harness OpenAI Codex, -те саме схвалення exec також покриває завантаження відгуку OpenAI для тредів runtime -Codex, про які знає OpenClaw. Це завантаження окреме від локального zip-файлу -Gateway і з’являється лише для сесій harness Codex. Перед схваленням -запит пояснює, що схвалення діагностики також надішле відгук Codex, але він -не перелічує ідентифікатори сесій або тредів Codex. Після схвалення відповідь у чаті перелічує -канали, ідентифікатори сесій OpenClaw, ідентифікатори тредів Codex і локальні команди resume -для тредів, надісланих на сервери OpenAI. Якщо ви відхилите або проігноруєте -схвалення, OpenClaw не запускає експорт, не надсилає відгук Codex і -не друкує ідентифікатори Codex. +Коли активний сеанс OpenClaw використовує нативний OpenAI Codex harness, +те саме підтвердження exec також охоплює завантаження відгуку OpenAI для потоків +середовища виконання Codex, про які знає OpenClaw. Це завантаження є окремим від локального +zip-архіву Gateway і з'являється лише для сеансів Codex harness. Перед підтвердженням +запит пояснює, що підтвердження діагностики також надішле відгук Codex, але він +не перелічує ідентифікатори сеансів або потоків Codex. Після підтвердження відповідь у чаті перелічує +канали, ідентифікатори сеансів OpenClaw, ідентифікатори потоків Codex і локальні команди відновлення +для потоків, надісланих на сервери OpenAI. Якщо ви відхилите або проігноруєте +підтвердження, OpenClaw не запускає експорт, не надсилає відгук Codex і +не виводить ідентифікатори Codex. -Це робить звичний цикл налагодження Codex коротким: помітили погану поведінку в -Telegram, Discord або іншому каналі, запустили `/diagnostics`, один раз схвалили, поділилися -звітом із підтримкою, а потім локально запустили надруковану команду `codex resume `, -якщо хочете самостійно перевірити нативний тред Codex. Див. -[Harness Codex](/uk/plugins/codex-harness#inspect-a-codex-thread-from-the-cli) для -цього робочого процесу перевірки. +Це робить типовий цикл налагодження Codex коротким: помітили неправильну поведінку в +Telegram, Discord або іншому каналі, запустили `/diagnostics`, один раз підтвердили, поділилися +звітом із підтримкою, а потім локально запустили виведену команду `codex resume `, +якщо хочете самостійно перевірити нативний потік Codex. Див. +[Codex harness](/uk/plugins/codex-harness#inspect-a-codex-thread-from-the-cli) для +цього процесу перевірки. ## Що містить експорт -Zip-файл містить: +Zip-архів містить: -- `summary.md`: зручний для людини огляд для підтримки. -- `diagnostics.json`: машиночитний підсумок конфігурації, журналів, стану, працездатності +- `summary.md`: зручний для читання огляд для підтримки. +- `diagnostics.json`: машинозчитуваний підсумок конфігурації, журналів, стану, справності та даних стабільності. -- `manifest.json`: метадані експорту та список файлів. -- Очищену форму конфігурації та несекретні подробиці конфігурації. -- Очищені підсумки журналів і нещодавні відредаговані рядки журналів. -- Best-effort знімки стану та працездатності Gateway. -- `stability/latest.json`: найновіший збережений пакет стабільності, коли він доступний. +- `manifest.json`: метадані експорту й список файлів. +- Санітизовану форму конфігурації та несекретні деталі конфігурації. +- Санітизовані підсумки журналів і нещодавні відредаговані рядки журналів. +- Найкращі можливі знімки стану й справності Gateway. +- `stability/latest.json`: найновіший збережений пакет стабільності, коли доступний. -Експорт корисний навіть тоді, коли Gateway непрацездатний. Якщо Gateway не може -відповісти на запити стану або працездатності, локальні журнали, форма конфігурації та найновіший -пакет стабільності все одно збираються, коли вони доступні. +Експорт корисний навіть тоді, коли Gateway несправний. Якщо Gateway не може +відповісти на запити стану або справності, локальні журнали, форма конфігурації та найновіший +пакет стабільності все одно збираються, коли доступні. ## Модель приватності -Діагностику спроєктовано так, щоб нею можна було ділитися. Експорт зберігає операційні дані, +Діагностика спроєктована так, щоб нею можна було ділитися. Експорт зберігає операційні дані, які допомагають налагодженню, як-от: -- назви підсистем, ідентифікатори plugin, ідентифікатори провайдерів, ідентифікатори каналів і налаштовані режими -- коди стану, тривалості, кількість байтів, стан черги та показники пам’яті -- очищені метадані журналів і відредаговані операційні повідомлення +- назви підсистем, ідентифікатори Plugin, ідентифікатори провайдерів, ідентифікатори каналів і налаштовані режими +- коди стану, тривалості, кількість байтів, стан черги та показники пам'яті +- санітизовані метадані журналів і відредаговані операційні повідомлення - форму конфігурації та несекретні налаштування функцій Експорт пропускає або редагує: -- текст чату, промпти, інструкції, тіла webhook і результати інструментів +- текст чатів, промпти, інструкції, тіла webhook і результати інструментів - облікові дані, API-ключі, токени, cookies і секретні значення -- сирі тіла запитів або відповідей -- ідентифікатори облікових записів, ідентифікатори повідомлень, сирі ідентифікатори сесій, імена хостів і локальні імена користувачів +- необроблені тіла запитів або відповідей +- ідентифікатори облікових записів, ідентифікатори повідомлень, необроблені ідентифікатори сеансів, імена хостів і локальні імена користувачів -Коли повідомлення журналу схоже на текст користувача, чату, промпта або payload інструмента, -експорт зберігає лише те, що повідомлення було пропущено, і кількість байтів. +Коли повідомлення журналу схоже на текст payload користувача, чату, промпта або інструмента, +експорт зберігає лише факт пропуску повідомлення та кількість байтів. ## Реєстратор стабільності -Gateway типово записує обмежений потік стабільності без payload, коли +Gateway за замовчуванням записує обмежений потік стабільності без payload, коли діагностику ввімкнено. Він призначений для операційних фактів, а не для вмісту. -Той самий діагностичний heartbeat записує зразки життєздатності, коли Gateway продовжує -працювати, але event loop Node.js або CPU виглядає перевантаженим. Ці -події `diagnostic.liveness.warning` містять затримку event loop, використання event loop, -співвідношення CPU-core і кількість активних/очікуваних/поставлених у чергу сесій. Неактивні -зразки залишаються в телеметрії на рівні `info`; вони логуються як попередження Gateway -лише коли діагностична робота активна, очікує або стоїть у черзі. Вони самі по собі -не перезапускають Gateway. +Той самий діагностичний heartbeat записує зразки активності, коли Gateway продовжує +працювати, але event loop Node.js або CPU здаються перевантаженими. Ці події +`diagnostic.liveness.warning` містять затримку event loop, використання event loop, +співвідношення ядер CPU та кількість активних/очікувальних/поставлених у чергу сеансів. Неактивні +зразки залишаються в телеметрії на рівні `info`. Зразки активності стають попередженнями Gateway +лише тоді, коли робота очікує або стоїть у черзі, або коли активна робота збігається зі +сталою затримкою event loop. Тимчасові піки максимальної затримки під час загалом справної +фонової роботи залишаються в журналах debug. Вони самі по собі не перезапускають Gateway. Перевірити активний реєстратор: @@ -137,22 +138,22 @@ openclaw gateway stability --type payload.large openclaw gateway stability --json ``` -Перевірити найновіший збережений пакет стабільності після фатального виходу, тайм-ауту завершення роботи -або помилки запуску після перезапуску: +Перевірити найновіший збережений пакет стабільності після фатального завершення, тайм-ауту +завершення роботи або помилки запуску після перезапуску: ```bash openclaw gateway stability --bundle latest ``` -Створити zip-файл діагностики з найновішого збереженого пакета: +Створити zip-архів діагностики з найновішого збереженого пакета: ```bash openclaw gateway stability --bundle latest --export ``` -Збережені пакети розташовані в `~/.openclaw/logs/stability/`, коли події існують. +Збережені пакети розміщуються в `~/.openclaw/logs/stability/`, коли події існують. -## Корисні параметри +## Корисні опції ```bash openclaw gateway diagnostics export \ @@ -161,20 +162,20 @@ openclaw gateway diagnostics export \ --log-bytes 1000000 ``` -- `--output `: записати до конкретного шляху zip-файлу. -- `--log-lines `: максимальна кількість очищених рядків журналу для включення. +- `--output `: записати в конкретний шлях zip-архіву. +- `--log-lines `: максимальна кількість санітизованих рядків журналу для включення. - `--log-bytes `: максимальна кількість байтів журналу для перевірки. -- `--url `: URL WebSocket Gateway для знімків стану та працездатності. -- `--token `: токен Gateway для знімків стану та працездатності. -- `--password `: пароль Gateway для знімків стану та працездатності. -- `--timeout `: тайм-аут знімків стану та працездатності. +- `--url `: WebSocket URL Gateway для знімків стану й справності. +- `--token `: токен Gateway для знімків стану й справності. +- `--password `: пароль Gateway для знімків стану й справності. +- `--timeout `: тайм-аут знімків стану й справності. - `--no-stability-bundle`: пропустити пошук збереженого пакета стабільності. -- `--json`: надрукувати машиночитні метадані експорту. +- `--json`: вивести машинозчитувані метадані експорту. -## Вимкнення діагностики +## Вимкнути діагностику -Діагностику ввімкнено типово. Щоб вимкнути реєстратор стабільності та -збирання діагностичних подій: +Діагностику ввімкнено за замовчуванням. Щоб вимкнути реєстратор стабільності та +збір діагностичних подій: ```json5 { @@ -184,13 +185,13 @@ openclaw gateway diagnostics export \ } ``` -Вимкнення діагностики зменшує деталізацію звіту про помилку. Воно не впливає на звичайне -логування Gateway. +Вимкнення діагностики зменшує деталізацію звіту про помилку. Це не впливає на звичайне +журналювання Gateway. -## Пов’язане +## Пов'язане -- [Перевірки працездатності](/uk/gateway/health) +- [Перевірки справності](/uk/gateway/health) - [CLI Gateway](/uk/cli/gateway#gateway-diagnostics-export) - [Протокол Gateway](/uk/gateway/protocol#system-and-identity) -- [Логування](/uk/logging) -- [Експорт OpenTelemetry](/uk/gateway/opentelemetry) — окремий потік для передавання діагностики до колектора +- [Журналювання](/uk/logging) +- [Експорт OpenTelemetry](/uk/gateway/opentelemetry) — окремий процес для потокової передачі діагностики до колектора diff --git a/docs/uk/reference/RELEASING.md b/docs/uk/reference/RELEASING.md index 75633c647..2614f415d 100644 --- a/docs/uk/reference/RELEASING.md +++ b/docs/uk/reference/RELEASING.md @@ -1,284 +1,284 @@ --- read_when: - Пошук визначень публічних каналів випуску - - Запуск перевірки релізу або приймального тестування пакета - - Шукаєте іменування версій і періодичність випусків -summary: Релізні лінії, контрольний список оператора, валідаційні бокси, іменування версій і періодичність + - Запуск валідації релізу або приймання пакета + - Пошук відомостей про найменування версій і періодичність випусків +summary: Релізні доріжки, контрольний список оператора, середовища валідації, іменування версій і ритм title: Політика випусків x-i18n: - generated_at: "2026-05-03T11:28:46Z" + generated_at: "2026-05-03T18:32:10Z" model: gpt-5.5 provider: openai - source_hash: edfd7d6a17da68c76d7196856702c59d1e3c2749907f591fe18b4f9df2eb097d + source_hash: 566088d826e1e2bac21b11443b82b62cb73ed1fd9c508c3fb865149cf8a428ba source_path: reference/RELEASING.md workflow: 16 --- OpenClaw має три публічні канали випусків: -- stable: теговані випуски, які типово публікуються в npm `beta`, або в npm `latest` за явним запитом -- beta: передвипускні теги, які публікуються в npm `beta` +- stable: теговані випуски, які за замовчуванням публікуються в npm `beta`, або в npm `latest`, коли це явно запитано +- beta: теги попередніх випусків, які публікуються в npm `beta` - dev: рухома вершина `main` -## Іменування версій +## Назви версій - Версія стабільного випуску: `YYYY.M.D` - Git-тег: `vYYYY.M.D` - Версія стабільного коригувального випуску: `YYYY.M.D-N` - Git-тег: `vYYYY.M.D-N` -- Версія beta-передвипуску: `YYYY.M.D-beta.N` +- Версія beta-попереднього випуску: `YYYY.M.D-beta.N` - Git-тег: `vYYYY.M.D-beta.N` -- Не додавайте початкові нулі до місяця чи дня +- Не додавайте нулі на початку місяця або дня - `latest` означає поточний просунутий стабільний випуск npm - `beta` означає поточну ціль встановлення beta -- Стабільні та стабільні коригувальні випуски типово публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або пізніше просунути перевірену beta-збірку -- Кожен стабільний випуск OpenClaw постачається разом із пакетом npm і застосунком macOS; - beta-випуски зазвичай спочатку перевіряють і публікують шлях npm/пакета, а - збирання/підписування/нотаризацію застосунку mac залишають для стабільних випусків, якщо це явно не запитано +- Стабільні та стабільні коригувальні випуски за замовчуванням публікуються в npm `beta`; оператори випуску можуть явно націлитися на `latest` або просунути перевірену збірку beta пізніше +- Кожен стабільний випуск OpenClaw постачає пакет npm і застосунок macOS разом; + beta-випуски зазвичай спершу перевіряють і публікують шлях npm/пакета, а + збирання/підписування/нотаризацію застосунку mac залишають для stable, якщо це явно не запитано -## Ритм випусків +## Періодичність випусків -- Випуски рухаються спочатку через beta +- Випуски рухаються спершу через beta - Stable виходить лише після перевірки останньої beta -- Maintainers зазвичай створюють випуски з гілки `release/YYYY.M.D`, створеної - з поточного `main`, щоб перевірка випуску та виправлення не блокували нову +- Maintainers зазвичай готують випуски з гілки `release/YYYY.M.D`, створеної + з поточної `main`, щоб перевірка випуску та виправлення не блокували нову розробку в `main` -- Якщо beta-тег уже надіслано або опубліковано і він потребує виправлення, maintainers створюють - наступний тег `-beta.N` замість видалення чи повторного створення старого beta-тега -- Докладна процедура випуску, погодження, облікові дані та нотатки щодо відновлення +- Якщо тег beta було надіслано або опубліковано і він потребує виправлення, maintainers створюють + наступний тег `-beta.N` замість видалення або повторного створення старого тегу beta +- Детальна процедура випуску, затвердження, облікові дані та нотатки з відновлення доступні лише maintainers ## Контрольний список оператора випуску -Цей контрольний список описує публічну форму процесу випуску. Приватні облікові дані, -підписування, нотаризація, відновлення dist-tag і деталі екстреного відкату залишаються в -runbook випуску, доступному лише maintainers. +Цей контрольний список є публічною формою процесу випуску. Приватні облікові дані, +підписування, нотаризація, відновлення dist-tag і подробиці екстреного відкату залишаються в +runbook випуску лише для maintainers. -1. Почніть із поточного `main`: підтягніть останні зміни, підтвердьте, що цільовий коміт надіслано, - і підтвердьте, що поточний CI `main` достатньо зелений, щоб відгалужуватися від нього. -2. Перепишіть верхній розділ `CHANGELOG.md` на основі реальної історії комітів за допомогою - `/changelog`, залишайте записи орієнтованими на користувача, закомітьте їх, надішліть і виконайте rebase/pull +1. Почніть з поточної `main`: отримайте останні зміни, підтвердьте, що цільовий коміт надіслано, + і підтвердьте, що поточний CI `main` достатньо зелений, щоб створити з нього гілку. +2. Перепишіть верхній розділ `CHANGELOG.md` з реальної історії комітів за допомогою + `/changelog`, залиште записи орієнтованими на користувача, закомітьте їх, надішліть і виконайте rebase/pull ще раз перед створенням гілки. 3. Перегляньте записи сумісності випуску в `src/plugins/compat/registry.ts` і `src/commands/doctor/shared/deprecation-compat.ts`. Видаляйте прострочену - сумісність лише тоді, коли шлях оновлення залишається покритим, або зафіксуйте, чому її + сумісність лише тоді, коли шлях оновлення лишається покритим, або зафіксуйте, чому її навмисно збережено. -4. Створіть `release/YYYY.M.D` з поточного `main`; не виконуйте звичайну роботу над випуском +4. Створіть `release/YYYY.M.D` з поточної `main`; не виконуйте звичайну роботу над випуском безпосередньо в `main`. -5. Підвищте версію в кожному потрібному місці для запланованого тега, запустіть - `pnpm plugins:sync`, щоб пакети Plugin, придатні до публікації, мали спільну версію випуску +5. Оновіть кожне обов’язкове місце з версією для запланованого тегу, запустіть + `pnpm plugins:sync`, щоб придатні до публікації пакети Plugin мали спільну версію випуску та метадані сумісності, потім запустіть локальний детермінований preflight: `pnpm check:test-types`, `pnpm check:architecture`, `pnpm build && pnpm ui:build`, `pnpm plugins:sync:check` і `pnpm release:check`. -6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До існування тега - повний 40-символьний SHA гілки випуску дозволений для preflight лише для перевірки. - Збережіть успішний `preflight_run_id`. +6. Запустіть `OpenClaw NPM Release` з `preflight_only=true`. До появи тегу + повний 40-символьний SHA гілки випуску дозволений для validation-only + preflight. Збережіть успішний `preflight_run_id`. 7. Запустіть усі передрелізні тести через `Full Release Validation` для - гілки випуску, тега або повного SHA коміту. Це єдина ручна точка входу - для чотирьох великих тестових середовищ випуску: Vitest, Docker, QA Lab і Package. -8. Якщо перевірка не пройшла, виправте в гілці випуску та повторно запустіть найменший файл, - канал, завдання workflow, профіль пакета, провайдера або allowlist моделі, що + гілки випуску, тегу або повного SHA коміту. Це єдина ручна точка входу + для чотирьох великих тестових боксів випуску: Vitest, Docker, QA Lab і Package. +8. Якщо перевірка не проходить, виправте в гілці випуску й повторно запустіть найменший невдалий + файл, канал, завдання workflow, профіль пакета, provider або allowlist моделей, який доводить виправлення. Повторно запускайте повну парасольку лише тоді, коли змінена поверхня робить попередні докази застарілими. -9. Для beta позначте тегом `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з +9. Для beta позначте `vYYYY.M.D-beta.N`, потім запустіть `OpenClaw Release Publish` з відповідної гілки `release/YYYY.M.D`. Він перевіряє `pnpm plugins:sync:check`, - спочатку публікує всі придатні до публікації пакети Plugin у npm, потім публікує той самий - набір у ClawHub, а після цього просуває підготовлений preflight-артефакт npm OpenClaw - з відповідним dist-tag. Після публікації запустіть package - acceptance після публікації для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або - `openclaw@beta`. Якщо надісланий або опублікований передвипуск потребує виправлення, - створіть наступний відповідний номер передвипуску; не видаляйте й не переписуйте старий - передвипуск. -10. Для stable продовжуйте лише після того, як перевірена beta або release candidate має - потрібні докази перевірки. Публікація stable в npm також проходить через - `OpenClaw Release Publish`, повторно використовуючи успішний preflight-артефакт через - `preflight_run_id`; готовність стабільного випуску macOS також потребує - запакованих `.zip`, `.dmg`, `.dSYM.zip` та оновленого `appcast.xml` у `main`. -11. Після публікації запустіть verifier npm після публікації, необов’язковий автономний - E2E Telegram для опублікованого npm, коли потрібен доказ каналу після публікації, + спершу публікує всі придатні до публікації пакети Plugin в npm, потім публікує той самий + набір у ClawHub як tarball-и ClawPack npm-pack, а далі просуває + підготовлений артефакт preflight npm OpenClaw з відповідним dist-tag. Після + публікації запустіть post-publish package + acceptance для опублікованого пакета `openclaw@YYYY.M.D-beta.N` або + `openclaw@beta`. Якщо надісланий або опублікований попередній випуск потребує виправлення, + створіть наступний відповідний номер попереднього випуску; не видаляйте і не переписуйте старий + попередній випуск. +10. Для stable продовжуйте лише після того, як перевірена beta або release candidate матиме + потрібні докази перевірки. Публікація stable npm також проходить через + `OpenClaw Release Publish`, повторно використовуючи успішний артефакт preflight через + `preflight_run_id`; готовність stable macOS-випуску також потребує + упакованих `.zip`, `.dmg`, `.dSYM.zip` і оновленого `appcast.xml` у `main`. +11. Після публікації запустіть npm post-publish verifier, необов’язковий standalone + published-npm Telegram E2E, коли потрібен доказ каналу після публікації, просування dist-tag за потреби, нотатки GitHub release/prerelease з повного відповідного розділу `CHANGELOG.md` і кроки оголошення випуску. ## Preflight випуску - Запустіть `pnpm check:test-types` перед передрелізною перевіркою, щоб тестовий TypeScript залишався - покритим поза швидшим локальним gate `pnpm check` + покритим поза швидшим локальним шлюзом `pnpm check` - Запустіть `pnpm check:architecture` перед передрелізною перевіркою, щоб ширші перевірки циклів - імпорту та меж архітектури були зеленими поза швидшим локальним gate + імпорту та архітектурних меж були зеленими поза швидшим локальним шлюзом - Запустіть `pnpm build && pnpm ui:build` перед `pnpm release:check`, щоб очікувані - релізні артефакти `dist/*` і bundle Control UI існували для етапу - перевірки пакування -- Запустіть `pnpm plugins:sync` після підняття версії в корені та перед тегуванням. Він - оновлює версії публіковних пакетів plugin, метадані сумісності peer/API - OpenClaw, метадані збірки та заготовки changelog plugin, щоб вони відповідали версії - релізу core. `pnpm plugins:sync:check` — це немутуючий релізний запобіжник; - workflow публікації завершується помилкою до будь-якої мутації registry, якщо цей крок було + релізні артефакти `dist/*` і бандл Control UI існували для кроку + валідації пакування +- Запустіть `pnpm plugins:sync` після підняття версії в корені та перед створенням тега. Він + оновлює версії пакетів публіковних plugins, метадані сумісності OpenClaw peer/API, + метадані збірки та заготовки журналів змін plugins, щоб вони відповідали версії + основного релізу. `pnpm plugins:sync:check` — це немутувальний релізний запобіжник; + workflow публікації завершується з помилкою до будь-якої мутації реєстру, якщо цей крок було забуто. - Запустіть ручний workflow `Full Release Validation` перед схваленням релізу, щоб - запустити всі передрелізні test boxes з однієї точки входу. Він приймає branch, - tag або повний SHA commit, dispatch ручний `CI` і dispatch + запустити всі передрелізні тестові бокси з однієї точки входу. Він приймає гілку, + тег або повний SHA коміту, запускає ручний `CI` і запускає `OpenClaw Release Checks` для install smoke, package acceptance, Docker release-path suite, live/E2E, OpenWebUI, QA Lab parity, Matrix і Telegram lanes. З `release_profile=full` і `rerun_group=all` він також запускає package - Telegram E2E проти артефакту `release-package-under-test` із release + Telegram E2E проти артефакта `release-package-under-test` із release checks. Надайте `npm_telegram_package_spec` після публікації, коли той самий - Telegram E2E має також підтвердити опублікований npm package. Надайте + Telegram E2E також має підтвердити опублікований npm-пакет. Надайте `package_acceptance_package_spec` після публікації, коли Package Acceptance - має запускати свою матрицю package/update проти відвантаженого npm package замість - артефакту, зібраного за SHA. Надайте - `evidence_package_spec`, коли приватний evidence report має підтвердити, що - валідація відповідає опублікованому npm package, без примусового Telegram E2E. + має запускати свою матрицю package/update проти доставленого npm-пакета замість + артефакта, зібраного з SHA. Надайте + `evidence_package_spec`, коли приватний звіт доказів має підтвердити, що + валідація відповідає опублікованому npm-пакету без примусового Telegram E2E. Приклад: `gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D` -- Запустіть ручний workflow `Package Acceptance`, коли потрібне side-channel підтвердження - для кандидата package, поки релізна робота триває. Використовуйте `source=npm` для - `openclaw@beta`, `openclaw@latest` або точної релізної версії; `source=ref`, - щоб спакувати довірений branch/tag/SHA `package_ref` з поточним +- Запустіть ручний workflow `Package Acceptance`, коли вам потрібне побічне підтвердження + для кандидата пакета, поки релізна робота триває. Використовуйте `source=npm` для + `openclaw@beta`, `openclaw@latest` або точної версії релізу; `source=ref`, + щоб запакувати довірену гілку/тег/SHA `package_ref` з поточним harness `workflow_ref`; `source=url` для HTTPS tarball з обов’язковим - SHA-256; або `source=artifact` для tarball, завантаженого іншим run GitHub - Actions. Workflow resolves кандидата в + SHA-256; або `source=artifact` для tarball, завантаженого іншим запуском GitHub + Actions. Workflow розв’язує кандидата до `package-under-test`, повторно використовує Docker E2E release scheduler проти цього tarball і може запускати Telegram QA проти того самого tarball з `telegram_mode=mock-openai` або `telegram_mode=live-frontier`. Коли вибрані - Docker lanes включають `published-upgrade-survivor`, артефакт package є кандидатом, а `published_upgrade_survivor_baseline` вибирає - опублікований baseline. + Docker lanes містять `published-upgrade-survivor`, артефакт пакета є кандидатом, а `published_upgrade_survivor_baseline` вибирає + опубліковану базову версію. Приклад: `gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai` Поширені профілі: - - `smoke`: lanes install/channel/agent, gateway network і config reload - - `package`: artifact-native lanes package/update/plugin без OpenWebUI або live ClawHub - - `product`: профіль package плюс MCP channels, cron/subagent cleanup, - OpenAI web search і OpenWebUI - - `full`: chunks Docker release-path з OpenWebUI - - `custom`: точний вибір `docker_lanes` для сфокусованого rerun -- Запустіть ручний workflow `CI` напряму, коли потрібне лише повне звичайне покриття CI - для релізного кандидата. Ручні CI dispatches обходять changed + - `smoke`: lanes для install/channel/agent, мережі Gateway і перезавантаження конфігурації + - `package`: artifact-native lanes для package/update/plugin без OpenWebUI або live ClawHub + - `product`: профіль package плюс MCP channels, очищення cron/subagent, + вебпошук OpenAI і OpenWebUI + - `full`: фрагменти Docker release-path з OpenWebUI + - `custom`: точний вибір `docker_lanes` для сфокусованого повторного запуску +- Запустіть ручний workflow `CI` напряму, коли вам потрібне лише повне звичайне CI + покриття для кандидата релізу. Ручні dispatch CI обходять changed scoping і примусово запускають Linux Node shards, bundled-plugin shards, channel contracts, сумісність Node 22, `check`, `check-additional`, build smoke, - docs checks, Python skills, Windows, macOS, Android і Control UI i18n + перевірки документації, Python skills, Windows, macOS, Android і Control UI i18n lanes. Приклад: `gh workflow run ci.yml --ref release/YYYY.M.D` -- Запустіть `pnpm qa:otel:smoke` під час валідації релізної telemetry. Він проганяє - QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані імена trace - span, обмежені attributes і редагування content/identifier без - потреби в Opik, Langfuse або іншому зовнішньому collector. -- Запускайте `pnpm release:check` перед кожним tagged release -- Запустіть `OpenClaw Release Publish` для мутуючої послідовності публікації після того, як - tag існує. Dispatch його з `release/YYYY.M.D` (або `main`, коли публікується - tag, reachable з main), передайте release tag і успішний OpenClaw npm - `preflight_run_id`, і залиште стандартну область публікації plugin - `all-publishable`, якщо ви не виконуєте навмисно сфокусований repair. Цей - workflow серіалізує plugin npm publish, plugin ClawHub publish і OpenClaw - npm publish, щоб core package не було опубліковано раніше за його externalized +- Запустіть `pnpm qa:otel:smoke` під час валідації релізної телеметрії. Він проганяє + QA-lab через локальний OTLP/HTTP receiver і перевіряє експортовані назви trace + span, обмежені атрибути та редагування вмісту/ідентифікаторів без + потреби в Opik, Langfuse або іншому зовнішньому колекторі. +- Запускайте `pnpm release:check` перед кожним релізом із тегом +- Запустіть `OpenClaw Release Publish` для мутувальної послідовності публікації після того, як + тег існує. Запускайте його з `release/YYYY.M.D` (або `main`, коли публікуєте + тег, досяжний з main), передайте релізний тег і успішний OpenClaw npm + `preflight_run_id`, а scope публікації plugins за замовчуванням + `all-publishable` залишайте, якщо тільки ви навмисно не виконуєте сфокусований ремонт. Workflow + серіалізує публікацію plugin npm, публікацію plugin ClawHub і публікацію OpenClaw + npm, щоб основний пакет не було опубліковано перед його екстерналізованими plugins. - Release checks тепер запускаються в окремому ручному workflow: `OpenClaw Release Checks` - `OpenClaw Release Checks` також запускає QA Lab mock parity lane плюс швидкий live Matrix profile і Telegram QA lane перед схваленням релізу. Live - lanes використовують environment `qa-live-shared`; Telegram також використовує Convex CI - credential leases. Запустіть ручний workflow `QA-Lab - All Lanes` з - `matrix_profile=all` і `matrix_shards=true`, коли потрібен повний Matrix - transport, media і E2EE inventory паралельно. -- Cross-OS install і upgrade runtime validation є частиною публічних - `OpenClaw Release Checks` і `Full Release Validation`, які викликають - reusable workflow - `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` напряму -- Цей поділ навмисний: зберігайте реальний шлях npm release коротким, - детермінованим і сфокусованим на артефактах, тоді як повільніші live checks залишаються у своєму - окремому lane, щоб вони не затримували й не блокували publish -- Release checks із secrets слід dispatch через `Full Release + lanes використовують середовище `qa-live-shared`; Telegram також використовує leases облікових даних Convex CI. Запустіть ручний workflow `QA-Lab - All Lanes` з + `matrix_profile=all` і `matrix_shards=true`, коли вам потрібна повна інвентаризація Matrix + transport, media та E2EE паралельно. +- Cross-OS валідація runtime для встановлення та оновлення є частиною публічних + `OpenClaw Release Checks` і `Full Release Validation`, які напряму викликають + багаторазовий workflow + `.github/workflows/openclaw-cross-os-release-checks-reusable.yml` +- Цей поділ навмисний: тримайте реальний шлях npm-релізу коротким, + детермінованим і зосередженим на артефактах, тоді як повільніші live checks залишаються у своєму + окремому lane, щоб вони не затримували й не блокували публікацію +- Release checks із секретами слід запускати через `Full Release Validation` або з workflow ref `main`/release, щоб логіка workflow і - secrets залишалися контрольованими -- `OpenClaw Release Checks` приймає branch, tag або повний commit SHA, доки - resolved commit reachable з OpenClaw branch або release tag -- validation-only preflight `OpenClaw NPM Release` також приймає поточний - повний 40-символьний SHA commit workflow-branch без потреби в pushed tag -- Цей шлях SHA призначений лише для validation і не може бути promoted у реальний publish + секрети залишалися контрольованими +- `OpenClaw Release Checks` приймає гілку, тег або повний SHA коміту, доки + розв’язаний коміт досяжний з гілки OpenClaw або релізного тега +- Validation-only preflight `OpenClaw NPM Release` також приймає поточний + повний 40-символьний SHA коміту гілки workflow без вимоги запушеного тега +- Цей шлях SHA призначений лише для валідації й не може бути підвищений до реальної публікації - У режимі SHA workflow синтезує `v` лише для - перевірки package metadata; реальний publish усе ще потребує справжнього release tag -- Обидва workflows тримають реальний шлях publish і promotion на GitHub-hosted - runners, тоді як немутуючий validation path може використовувати більші + перевірки метаданих пакета; реальна публікація все одно потребує справжнього релізного тега +- Обидва workflows тримають реальний шлях публікації та promotion на GitHub-hosted + runners, тоді як немутувальний шлях валідації може використовувати більші Blacksmith Linux runners - Цей workflow запускає `OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache` з використанням workflow secrets `OPENAI_API_KEY` і `ANTHROPIC_API_KEY` -- npm release preflight більше не чекає на окремий release checks lane +- npm release preflight більше не чекає на окремий lane release checks - Запустіть `RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts` (або відповідний beta/correction tag) перед схваленням - Після npm publish запустіть `node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D` - (або відповідну beta/correction version), щоб перевірити опублікований шлях registry - install у свіжому temp prefix + (або відповідну beta/correction version), щоб перевірити шлях встановлення з опублікованого registry + у свіжому тимчасовому prefix - Після beta publish запустіть `OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live` - щоб перевірити installed-package onboarding, Telegram setup і реальний Telegram E2E - проти опублікованого npm package з використанням спільного leased Telegram credential - pool. Локальні одноразові запуски maintainer можуть omit Convex vars і передати три + щоб перевірити onboarding встановленого пакета, налаштування Telegram і справжній Telegram E2E + проти опублікованого npm-пакета з використанням спільного leased pool облікових даних Telegram. + Локальні одноразові перевірки maintainer можуть пропускати Convex vars і передавати три env credentials `OPENCLAW_QA_TELEGRAM_*` напряму. - Maintainers можуть запускати ту саму post-publish check з GitHub Actions через - ручний workflow `NPM Telegram Beta E2E`. Він навмисно manual-only і - не запускається на кожен merge. -- Автоматизація release для maintainer тепер використовує preflight-then-promote: - - реальний npm publish має пройти успішний npm `preflight_run_id` - - реальний npm publish має бути dispatched з тієї самої branch `main` або + ручний workflow `NPM Telegram Beta E2E`. Він навмисно лише ручний і + не запускається під час кожного merge. +- Автоматизація релізів maintainer тепер використовує preflight-then-promote: + - реальна npm publish має пройти успішний npm `preflight_run_id` + - реальна npm publish має запускатися з тієї самої гілки `main` або `release/YYYY.M.D`, що й успішний preflight run - - stable npm releases стандартно використовують `beta` - - stable npm publish може явно target `latest` через workflow input - - token-based npm dist-tag mutation тепер живе в + - стабільні npm-релізи за замовчуванням спрямовуються на `beta` + - stable npm publish може явно націлюватися на `latest` через workflow input + - token-based мутація npm dist-tag тепер живе в `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` з міркувань безпеки, тому що `npm dist-tag add` все ще потребує `NPM_TOKEN`, тоді як - публічний repo зберігає OIDC-only publish - - public `macOS Release` є validation-only; коли tag існує лише на - release branch, але workflow dispatched з `main`, встановіть + публічний repo зберігає publish лише через OIDC + - публічний `macOS Release` призначений лише для валідації; коли тег існує лише в + release branch, але workflow запускається з `main`, задайте `public_release_branch=release/YYYY.M.D` - реальний private mac publish має пройти успішні private mac `preflight_run_id` і `validate_run_id` - - реальні publish paths promote підготовлені артефакти замість повторної - збірки -- Для stable correction releases на кшталт `YYYY.M.D-N` post-publish verifier + - реальні шляхи публікації просувають підготовлені артефакти замість повторної + їхньої збірки +- Для стабільних correction releases на кшталт `YYYY.M.D-N` post-publish verifier також перевіряє той самий temp-prefix upgrade path з `YYYY.M.D` до `YYYY.M.D-N`, - щоб release corrections не могли непомітно залишити старіші global installs на + щоб release corrections не могли непомітно залишити старіші глобальні встановлення на базовому stable payload -- npm release preflight fails closed, якщо tarball не містить одночасно +- npm release preflight завершується закрито, якщо tarball не містить одночасно `dist/control-ui/index.html` і непорожній payload `dist/control-ui/assets/`, - щоб ми знову не відвантажили порожній browser dashboard -- Post-publish verification також перевіряє, що опубліковані plugin entrypoints і - package metadata присутні в установленому registry layout. Реліз, який - відвантажує відсутні plugin runtime payloads, fails postpublish verifier і - не може бути promoted до `latest`. -- `pnpm test:install:smoke` також забезпечує budget npm pack `unpackedSize` для - candidate update tarball, тож installer e2e ловить випадкове pack bloat - до release publish path -- Якщо release work торкалася CI planning, extension timing manifests або - extension test matrices, згенеруйте повторно й перегляньте planner-owned - outputs matrix `plugin-prerelease-extension-shard` з - `.github/workflows/plugin-prerelease.yml` перед схваленням, щоб release notes не - описували застарілий CI layout -- Готовність stable macOS release також включає updater surfaces: - - GitHub release має зрештою містити спаковані `.zip`, `.dmg` і `.dSYM.zip` + щоб ми знову не доставили порожню browser dashboard +- Post-publish verification також перевіряє, що опубліковані entrypoints plugins і + package metadata присутні у встановленому registry layout. Реліз, який + доставляє відсутні runtime payloads plugins, провалює postpublish verifier і + не може бути просунутий до `latest`. +- `pnpm test:install:smoke` також застосовує бюджет npm pack `unpackedSize` до + candidate update tarball, тож installer e2e ловить випадкове роздування пакета + до шляху release publish +- Якщо релізна робота торкалася CI planning, extension timing manifests або + extension test matrices, перед схваленням перегенеруйте й перегляньте outputs матриці + `plugin-prerelease-extension-shard`, якими володіє planner, з + `.github/workflows/plugin-prerelease.yml`, щоб release notes не описували + застарілий CI layout +- Готовність стабільного macOS release також включає updater surfaces: + - GitHub release має зрештою містити запаковані `.zip`, `.dmg` і `.dSYM.zip` - `appcast.xml` на `main` має вказувати на новий stable zip після publish - - спакований app має зберігати non-debug bundle id, непорожній Sparkle feed - URL і `CFBundleVersion` на рівні або вище канонічного Sparkle build floor - для цієї release version + - запакований app має зберігати non-debug bundle id, непорожній Sparkle feed + URL і `CFBundleVersion` на рівні або вище канонічної Sparkle build floor + для цієї версії релізу -## Release test boxes +## Релізні тестові бокси -`Full Release Validation` — це спосіб, яким operators запускають усі pre-release tests з -однієї точки входу. Для pinned commit proof на швидкозмінній branch використовуйте -helper, щоб кожен child workflow запускався з тимчасової branch, зафіксованої на target +`Full Release Validation` — це спосіб, у який оператори запускають усі передрелізні тести з +однієї точки входу. Для pinned commit proof на швидкозмінній гілці використовуйте +helper, щоб кожен дочірній workflow запускався з тимчасової гілки, зафіксованої на цільовому SHA: ```bash pnpm ci:full-release --sha ``` -Helper pushes `release-ci/-...`, dispatches `Full Release Validation` -з цієї branch з `ref=`, перевіряє, що кожен child workflow `headSha` -відповідає target, а потім видаляє тимчасову branch. Це запобігає випадковому підтвердженню -новішого child run `main`. +Helper пушить `release-ci/-...`, запускає `Full Release Validation` +з цієї гілки з `ref=`, перевіряє, що кожен дочірній workflow `headSha` +відповідає цільовому, а потім видаляє тимчасову гілку. Це запобігає випадковому підтвердженню +новішого дочірнього запуску `main`. -Для валідації release branch або tag запустіть його з довіреного workflow -ref `main` і передайте release branch або tag як `ref`: +Для валідації release branch або tag запускайте його з довіреного workflow +ref `main` і передавайте release branch або tag як `ref`: ```bash gh workflow run full-release-validation.yml \ @@ -290,46 +290,48 @@ gh workflow run full-release-validation.yml \ -f evidence_package_spec=openclaw@YYYY.M.D-beta.N ``` -Робочий процес розв’язує цільовий ref, запускає ручний `CI` з +Робочий процес визначає цільовий ref, запускає ручний `CI` з `target_ref=`, запускає `OpenClaw Release Checks`, готує -батьківський артефакт `release-package-under-test` для перевірок, орієнтованих -на пакети, і запускає окремий пакетний Telegram E2E, коли `release_profile=full` з -`rerun_group=all` або коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release -Checks` розгалужується на install smoke, кросплатформні релізні перевірки, live/E2E Docker -покриття релізного шляху, Package Acceptance з пакетним Telegram QA, QA Lab -parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, коли -підсумок `Full Release Validation` -показує `normal_ci` і `release_checks` як успішні. У режимі full/all -дочірній `npm_telegram` також має бути успішним; поза full/all його пропускають, -якщо не було надано опублікований `npm_telegram_package_spec`. Фінальний -підсумок верифікатора містить таблиці найповільніших завдань для кожного дочірнього запуску, щоб release -manager міг бачити поточний критичний шлях без завантаження логів. -Див. [Повна релізна валідація](/uk/reference/full-release-validation) для -повної матриці етапів, точних назв завдань workflow, відмінностей між stable і full -профілями, артефактів і точкових механізмів повторного запуску. -Дочірні workflow запускаються з довіреного ref, який запускає `Full Release -Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на -старішу релізну гілку або тег. Окремого входу Full Release Validation -workflow-ref немає; вибирайте довірений harness, вибираючи ref запуску workflow. -Не використовуйте `--ref main -f ref=` для доказу точного коміту на рухомій `main`; -сирі SHA комітів не можуть бути refs для workflow dispatch, тому використовуйте +батьківський артефакт `release-package-under-test` для перевірок, пов’язаних із +пакунком, і запускає автономний package Telegram E2E, коли `release_profile=full` +з `rerun_group=all` або коли задано `npm_telegram_package_spec`. Потім `OpenClaw Release +Checks` розгалужується на install smoke, cross-OS release checks, покриття +release-path для live/E2E Docker, Package Acceptance з package QA для Telegram, +QA Lab parity, live Matrix і live Telegram. Повний запуск прийнятний лише тоді, +коли підсумок `Full Release Validation` +показує `normal_ci` і `release_checks` як успішні. У режимі full/all дочірній +`npm_telegram` також має бути успішним; поза full/all його пропускають, якщо не +було надано опублікований `npm_telegram_package_spec`. Підсумок фінального +верифікатора містить таблиці найповільніших завдань для кожного дочірнього +запуску, щоб менеджер релізу міг бачити поточний критичний шлях без завантаження +логів. +Див. [Повна перевірка релізу](/uk/reference/full-release-validation) для повної +матриці етапів, точних назв завдань workflow, відмінностей між профілями stable +і full, артефактів і цільових ідентифікаторів повторного запуску. +Дочірні workflow запускаються з довіреного ref, який виконує `Full Release +Validation`, зазвичай `--ref main`, навіть коли цільовий `ref` вказує на старішу +release-гілку або тег. Окремого вхідного параметра workflow-ref для Full Release +Validation немає; вибирайте довірений harness, вибираючи ref запуску workflow. +Не використовуйте `--ref main -f ref=` для доказу точного коміту на рухомій +`main`; сирі commit SHA не можуть бути workflow dispatch refs, тому використовуйте `pnpm ci:full-release --sha `, щоб створити закріплену тимчасову гілку. Використовуйте `release_profile`, щоб вибрати ширину live/provider: -- `minimum`: найшвидший release-critical OpenAI/core live і Docker шлях -- `stable`: minimum плюс stable provider/backend покриття для затвердження релізу -- `full`: stable плюс широке advisory provider/media покриття +- `minimum`: найшвидший release-critical OpenAI/core live і Docker path +- `stable`: minimum плюс stable provider/backend coverage для схвалення релізу +- `full`: stable плюс broad advisory provider/media coverage -`OpenClaw Release Checks` використовує довірений ref workflow, щоб один раз розв’язати цільовий -ref як `release-package-under-test`, і повторно використовує цей артефакт як у -release-path Docker перевірках, так і в Package Acceptance. Це тримає всі -package-facing бокси на тих самих байтах і уникає повторних збірок пакета. -Кросплатформний OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли -задано repo/org змінну, інакше `openai/gpt-5.4`, бо ця lane -доводить встановлення пакета, onboarding, запуск Gateway і один live agent turn, -а не бенчмаркує найповільнішу модель за замовчуванням. Ширша live provider -matrix лишається місцем для model-specific покриття. +`OpenClaw Release Checks` використовує довірений workflow ref, щоб один раз +визначити цільовий ref як `release-package-under-test`, і повторно використовує +цей артефакт як у release-path Docker checks, так і в Package Acceptance. Це +утримує всі package-facing box на однакових байтах і уникає повторних збірок +пакунка. +Cross-OS OpenAI install smoke використовує `OPENCLAW_CROSS_OS_OPENAI_MODEL`, коли +задано repo/org variable, інакше `openai/gpt-5.4`, тому що ця lane доводить +інсталяцію пакунка, onboarding, запуск Gateway і один live agent turn, а не +бенчмарк найповільнішої моделі за замовчуванням. Ширша матриця live provider +залишається місцем для model-specific coverage. Використовуйте ці варіанти залежно від етапу релізу: @@ -361,41 +363,45 @@ gh workflow run full-release-validation.yml \ -f npm_telegram_provider_mode=mock-openai ``` -Не використовуйте повну umbrella як перший повторний запуск після точкового виправлення. Якщо один box -падає, використовуйте невдалий дочірній workflow, job, Docker lane, package profile, model -provider або QA lane для наступного доказу. Запускайте повну umbrella знову лише тоді, -коли виправлення змінило спільну релізну оркестрацію або зробило попередні all-box докази -застарілими. Фінальний верифікатор umbrella повторно перевіряє записані child workflow run -ids, тому після успішного повторного запуску дочірнього workflow перезапускайте лише невдалий -батьківський job `Verify full validation`. +Не використовуйте повну umbrella як перший повторний запуск після цільового +виправлення. Якщо один box не проходить, використовуйте failed child workflow, +job, Docker lane, package profile, model provider або QA lane для наступного +доказу. Запускайте повну umbrella знову лише тоді, коли виправлення змінило +спільну release orchestration або зробило попередні all-box докази застарілими. +Фінальний верифікатор umbrella повторно перевіряє записані ідентифікатори +запусків дочірніх workflow, тому після успішного повторного запуску дочірнього +workflow повторно запускайте лише failed parent job `Verify full validation`. -Для обмеженого відновлення передайте `rerun_group` до umbrella. `all` — це справжній -запуск release-candidate, `ci` запускає лише звичайний дочірній CI, `plugin-prerelease` -запускає лише release-only дочірній Plugin, `release-checks` запускає кожен release -box, а вужчі release groups — це `install-smoke`, `cross-os`, -`live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і `npm-telegram`. -Точкові повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; full/all запуски -з `release_profile=full` використовують пакетний артефакт release-checks. +Для обмеженого відновлення передайте `rerun_group` до umbrella. `all` є справжнім +запуском release-candidate, `ci` запускає лише дочірній normal CI, +`plugin-prerelease` запускає лише release-only plugin child, `release-checks` +запускає кожен release box, а вужчі release groups — це `install-smoke`, +`cross-os`, `live-e2e`, `package`, `qa`, `qa-parity`, `qa-live` і +`npm-telegram`. +Цільові повторні запуски `npm-telegram` потребують `npm_telegram_package_spec`; +full/all запуски з `release_profile=full` використовують package artifact із +release-checks. ### Vitest -Vitest box — це ручний дочірній workflow `CI`. Ручний CI навмисно -обходить changed scoping і примусово запускає звичайний тестовий граф для release -candidate: Linux Node shards, bundled-plugin shards, channel contracts, Node 22 +Vitest box — це ручний дочірній workflow `CI`. Ручний CI навмисно обходить +changed scoping і примусово виконує звичайний test graph для release candidate: +Linux Node shards, bundled-plugin shards, channel contracts, Node 22 compatibility, `check`, `check-additional`, build smoke, docs checks, Python -Skills, Windows, macOS, Android і Control UI i18n. +skills, Windows, macOS, Android і Control UI i18n. -Використовуйте цей box, щоб відповісти: «чи пройшло дерево source повний звичайний test suite?» -Це не те саме, що release-path продуктова валідація. Докази, які треба зберегти: +Використовуйте цей box, щоб відповісти: «чи пройшло дерево вихідного коду повний +звичайний набір тестів?» Це не те саме, що release-path product validation. +Докази, які слід зберегти: - підсумок `Full Release Validation`, що показує URL запущеного `CI` run -- зелений `CI` run на точному target SHA -- назви невдалих або повільних shards із CI jobs під час розслідування регресій -- артефакти таймінгів Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли +- зелений `CI` run на точному цільовому SHA +- назви failed або slow shard із CI jobs під час дослідження регресій +- артефакти часу Vitest, як-от `.artifacts/vitest-shard-timings.json`, коли запуск потребує аналізу продуктивності -Запускайте ручний CI напряму лише тоді, коли релізу потрібен детермінований звичайний CI, але -не потрібні Docker, QA Lab, live, cross-OS або package boxes: +Запускайте manual CI напряму лише тоді, коли релізу потрібен deterministic normal +CI, але не Docker, QA Lab, live, cross-OS або package boxes: ```bash gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D @@ -403,16 +409,16 @@ gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D ### Docker -Docker box живе в `OpenClaw Release Checks` через -`openclaw-live-and-e2e-checks-reusable.yml`, плюс release-mode -workflow `install-smoke`. Він валідовує release candidate через упаковані -Docker середовища, а не лише source-level тести. +Docker box міститься в `OpenClaw Release Checks` через +`openclaw-live-and-e2e-checks-reusable.yml`, а також release-mode workflow +`install-smoke`. Він перевіряє release candidate через packaged Docker +environments, а не лише source-level tests. -Release Docker покриття включає: +Release Docker coverage включає: - повний install smoke з увімкненим повільним Bun global install smoke - підготовку/повторне використання root Dockerfile smoke image за target SHA, з QR, - root/gateway і installer/Bun smoke jobs, що запускаються як окремі install-smoke + root/gateway і installer/Bun smoke jobs, що виконуються як окремі install-smoke shards - repository E2E lanes - release-path Docker chunks: `core`, `package-update-openai`, @@ -422,54 +428,54 @@ Release Docker покриття включає: `plugins-runtime-install-c`, `plugins-runtime-install-d`, `plugins-runtime-install-e`, `plugins-runtime-install-f`, `plugins-runtime-install-g` і `plugins-runtime-install-h` -- OpenWebUI покриття всередині chunk `plugins-runtime-services`, коли запитано +- OpenWebUI coverage всередині chunk `plugins-runtime-services`, коли це запитано - розділені bundled plugin install/uninstall lanes - `bundled-plugin-install-uninstall-0` through + `bundled-plugin-install-uninstall-0` до `bundled-plugin-install-uninstall-23` - live/E2E provider suites і Docker live model coverage, коли release checks включають live suites -Використовуйте Docker артефакти перед повторним запуском. Release-path scheduler завантажує -`.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`, -phase timings, scheduler plan JSON і rerun commands. Для точкового відновлення +Використовуйте Docker artifacts перед повторним запуском. Release-path scheduler +завантажує `.artifacts/docker-tests/` з lane logs, `summary.json`, `failures.json`, +phase timings, scheduler plan JSON і rerun commands. Для цільового відновлення використовуйте `docker_lanes=` у reusable live/E2E workflow замість -повторного запуску всіх release chunks. Згенеровані rerun commands включають попередній -`package_artifact_run_id` і підготовлені Docker image inputs, коли доступні, щоб -невдала lane могла повторно використати той самий tarball і GHCR images. +повторного запуску всіх release chunks. Згенеровані rerun commands включають +попередній `package_artifact_run_id` і підготовлені Docker image inputs, коли +вони доступні, тому failed lane може повторно використати той самий tarball і +GHCR images. ### QA Lab -QA Lab box також є частиною `OpenClaw Release Checks`. Це агентний -behavior і channel-level release gate, окремий від Vitest і Docker -package mechanics. +QA Lab box також є частиною `OpenClaw Release Checks`. Це release gate для +agentic behavior і channel-level, окремий від Vitest і Docker package mechanics. -Release QA Lab покриття включає: +Release QA Lab coverage включає: -- mock parity lane, що порівнює OpenAI candidate lane з Opus 4.6 - baseline за допомогою agentic parity pack -- швидкий live Matrix QA profile з використанням середовища `qa-live-shared` +- mock parity lane, що порівнює OpenAI candidate lane з Opus 4.6 baseline за + допомогою agentic parity pack +- fast live Matrix QA profile з використанням середовища `qa-live-shared` - live Telegram QA lane з використанням Convex CI credential leases -- `pnpm qa:otel:smoke`, коли release telemetry потребує явного local proof +- `pnpm qa:otel:smoke`, коли release telemetry потребує явного локального доказу -Використовуйте цей box, щоб відповісти: «чи реліз поводиться коректно в QA scenarios і -live channel flows?» Зберігайте artifact URLs для parity, Matrix і Telegram -lanes під час затвердження релізу. Повне Matrix покриття лишається доступним як -ручний sharded QA-Lab run, а не default release-critical lane. +Використовуйте цей box, щоб відповісти: «чи поводиться реліз правильно в QA +scenarios і live channel flows?» Зберігайте URL артефактів для parity, Matrix і +Telegram lanes під час схвалення релізу. Full Matrix coverage залишається +доступним як ручний sharded QA-Lab run, а не як default release-critical lane. -### Package +### Пакунок -Package box — це installable-product gate. Його підтримують +Package box — це gate для installable-product. Він підтримується `Package Acceptance` і resolver -`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує -candidate у tarball `package-under-test`, який споживає Docker E2E, валідовує -package inventory, записує package version і SHA-256 та тримає -workflow harness ref окремо від package source ref. +`scripts/resolve-openclaw-package-candidate.mjs`. Resolver нормалізує candidate +у tarball `package-under-test`, який споживає Docker E2E, перевіряє package +inventory, записує package version і SHA-256, а також тримає workflow harness ref +окремо від package source ref. Підтримувані джерела candidate: - `source=npm`: `openclaw@beta`, `openclaw@latest` або точна OpenClaw release version -- `source=ref`: пакує довірену гілку `package_ref`, тег або повний commit SHA +- `source=ref`: пакує довірену `package_ref` branch, tag або full commit SHA з вибраним `workflow_ref` harness - `source=url`: завантажує HTTPS `.tgz` з обов’язковим `package_sha256` - `source=artifact`: повторно використовує `.tgz`, завантажений іншим GitHub Actions run @@ -481,35 +487,36 @@ workflow harness ref окремо від package source ref. `published_upgrade_survivor_scenarios=reported-issues` і `telegram_mode=mock-openai`. Package Acceptance тримає migration, update, stale plugin dependency cleanup, offline plugin fixtures, plugin update і Telegram -package QA проти того самого розв’язаного tarball. Upgrade matrix покриває кожен stable npm-published baseline від `2026.4.23` до `latest`; використовуйте -Package Acceptance з `source=npm` для вже shipped candidate або +package QA проти того самого resolved tarball. Матриця upgrade охоплює кожен stable npm-published baseline від `2026.4.23` до `latest`; використовуйте +Package Acceptance з `source=npm` для вже випущеного candidate або `source=ref`/`source=artifact` для SHA-backed local npm tarball перед публікацією. Це GitHub-native -заміна для більшості package/update покриття, яке раніше вимагало -Parallels. Cross-OS release checks усе ще важливі для OS-specific onboarding, -installer і platform behavior, але package/update product validation має -надавати перевагу Package Acceptance. +заміна для більшості package/update coverage, що раніше вимагало Parallels. +Cross-OS release checks усе ще важливі для OS-specific onboarding, installer і +platform behavior, але package/update product validation має надавати перевагу +Package Acceptance. Канонічний checklist для update і plugin validation — -[Тестування оновлень і Plugin](/uk/help/testing-updates-plugins). Використовуйте його, коли -вирішуєте, яка local, Docker, Package Acceptance або release-check lane доводить -plugin install/update, doctor cleanup або published-package migration change. -Вичерпна published update migration з кожного stable пакета `2026.4.23+` — це -окремий ручний workflow `Update Migration`, а не частина Full Release CI. +[Тестування оновлень і плагінів](/uk/help/testing-updates-plugins). Використовуйте +його, коли вирішуєте, яка local, Docker, Package Acceptance або release-check +lane доводить plugin install/update, doctor cleanup або published-package +migration change. +Вичерпна published update migration з кожного stable пакунка `2026.4.23+` є +окремим ручним workflow `Update Migration`, а не частиною Full Release CI. -Legacy package-acceptance leniency навмисно обмежена в часі. Пакети до -`2026.4.25` можуть використовувати compatibility path для metadata gaps, уже опублікованих -у npm: private QA inventory entries, відсутні в tarball, відсутній -`gateway install --wrapper`, відсутні patch files у tarball-derived git +Legacy package-acceptance leniency навмисно обмежена в часі. Пакунки до +`2026.4.25` включно можуть використовувати compatibility path для metadata gaps, +уже опублікованих у npm: private QA inventory entries, відсутні в tarball, +відсутній `gateway install --wrapper`, відсутні patch files у tarball-derived git fixture, відсутній persisted `update.channel`, legacy plugin install-record locations, відсутня marketplace install-record persistence і config metadata -migration під час `plugins update`. Опублікований пакет `2026.4.26` може попереджати -про local build metadata stamp files, які вже були shipped. Пізніші пакети -мають задовольняти сучасні package contracts; ті самі gaps провалюють release -validation. +migration під час `plugins update`. Опублікований пакунок `2026.4.26` може +попереджати про local build metadata stamp files, які вже були випущені. Пізніші +пакунки мають задовольняти modern package contracts; ті самі gaps провалюють +release validation. Використовуйте ширші Package Acceptance profiles, коли release question стосується -фактичного installable package: +реального installable package: ```bash gh workflow run package-acceptance.yml \ @@ -523,35 +530,32 @@ gh workflow run package-acceptance.yml \ Поширені package profiles: -- `smoke`: швидкі лінії встановлення пакета/каналу/агента, мережі Gateway та - перезавантаження конфігурації -- `package`: контракти встановлення/оновлення/пакета Plugin без живого ClawHub; це типове значення - release-check -- `product`: `package` плюс канали MCP, очищення cron/субагентів, вебпошук OpenAI - та OpenWebUI -- `full`: фрагменти шляху Docker-релізу з OpenWebUI -- `custom`: точний список `docker_lanes` для сфокусованих повторних запусків +- `smoke`: швидке встановлення пакета/каналу/агента, мережа Gateway і смуги перезавантаження конфігурації +- `package`: контракти встановлення/оновлення/пакета Plugin без live ClawHub; це типовий release-check +- `product`: `package` плюс канали MCP, очищення cron/subagent, вебпошук OpenAI і OpenWebUI +- `full`: частини шляху Docker-релізу з OpenWebUI +- `custom`: точний список `docker_lanes` для цільових повторних запусків -Для підтвердження Telegram кандидата пакета увімкніть `telegram_mode=mock-openai` або -`telegram_mode=live-frontier` у Package Acceptance. Робочий процес передає -розв’язаний tarball `package-under-test` у лінію Telegram; окремий робочий процес -Telegram все ще приймає опубліковану npm-специфікацію для перевірок після публікації. +Для підтвердження кандидата пакета в Telegram увімкніть `telegram_mode=mock-openai` або +`telegram_mode=live-frontier` у Package Acceptance. Workflow передає +розв’язаний tarball `package-under-test` у смугу Telegram; окремий +workflow Telegram усе ще приймає опубліковану npm-специфікацію для перевірок після публікації. ## Автоматизація публікації релізу -`OpenClaw Release Publish` є звичайною змінною точкою входу для публікації. Він -оркеструє робочі процеси trusted-publisher у порядку, потрібному для релізу: +`OpenClaw Release Publish` є звичайною мутувальною точкою входу для публікації. Він +оркеструє workflows довіреного видавця в порядку, потрібному релізу: -1. Витягнути тег релізу та визначити його SHA коміту. -2. Перевірити, що тег досяжний з `main` або `release/*`. +1. Отримати release tag і визначити його commit SHA. +2. Перевірити, що tag досяжний із `main` або `release/*`. 3. Запустити `pnpm plugins:sync:check`. 4. Запустити `Plugin NPM Release` з `publish_scope=all-publishable` і `ref=`. -5. Запустити `Plugin ClawHub Release` з тією самою областю та SHA. -6. Запустити `OpenClaw NPM Release` з тегом релізу, npm dist-tag і +5. Запустити `Plugin ClawHub Release` з тією самою областю дії та SHA. +6. Запустити `OpenClaw NPM Release` з release tag, npm dist-tag і збереженим `preflight_run_id`. -Приклад публікації бета-версії: +Приклад публікації beta: ```bash gh workflow run openclaw-release-publish.yml \ @@ -561,7 +565,7 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=beta ``` -Стабільна публікація до типового бета-dist-tag: +Стабільна публікація в типовий beta dist-tag: ```bash gh workflow run openclaw-release-publish.yml \ @@ -581,91 +585,91 @@ gh workflow run openclaw-release-publish.yml \ -f npm_dist_tag=latest ``` -Використовуйте нижчорівневі робочі процеси `Plugin NPM Release` і `Plugin ClawHub Release` -лише для сфокусованого виправлення або повторної публікації. Для виправлення вибраного plugin передайте +Використовуйте нижчорівневі workflows `Plugin NPM Release` і `Plugin ClawHub Release` +лише для цільового ремонту або повторної публікації. Для ремонту вибраного Plugin передайте `plugin_publish_scope=selected` і `plugins=@openclaw/name` до -`OpenClaw Release Publish`, або запускайте дочірній робочий процес безпосередньо, коли +`OpenClaw Release Publish` або запустіть дочірній workflow напряму, коли пакет OpenClaw не має бути опублікований. -## Вхідні дані робочого процесу NPM +## Вхідні параметри workflow NPM -`OpenClaw NPM Release` приймає такі керовані оператором вхідні дані: +`OpenClaw NPM Release` приймає такі вхідні параметри, керовані оператором: -- `tag`: обов’язковий тег релізу, наприклад `v2026.4.2`, `v2026.4.2-1` або +- `tag`: обов’язковий release tag, як-от `v2026.4.2`, `v2026.4.2-1` або `v2026.4.2-beta.1`; коли `preflight_only=true`, це також може бути поточний - повний 40-символьний SHA коміту гілки робочого процесу для preflight лише з валідацією -- `preflight_only`: `true` лише для валідації/збірки/пакета, `false` для + повний 40-символьний commit SHA гілки workflow для preflight лише з перевіркою +- `preflight_only`: `true` для лише перевірки/збірки/пакування, `false` для справжнього шляху публікації -- `preflight_run_id`: обов’язковий у справжньому шляху публікації, щоб робочий процес повторно використовував +- `preflight_run_id`: обов’язковий на справжньому шляху публікації, щоб workflow повторно використав підготовлений tarball з успішного preflight-запуску - `npm_dist_tag`: цільовий npm-тег для шляху публікації; типово `beta` -`OpenClaw Release Publish` приймає такі керовані оператором вхідні дані: +`OpenClaw Release Publish` приймає такі вхідні параметри, керовані оператором: -- `tag`: обов’язковий тег релізу; має вже існувати -- `preflight_run_id`: ідентифікатор успішного preflight-запуску `OpenClaw NPM Release`; +- `tag`: обов’язковий release tag; уже має існувати +- `preflight_run_id`: id успішного preflight-запуску `OpenClaw NPM Release`; обов’язковий, коли `publish_openclaw_npm=true` - `npm_dist_tag`: цільовий npm-тег для пакета OpenClaw - `plugin_publish_scope`: типово `all-publishable`; використовуйте `selected` лише - для сфокусованого виправлення + для цільового ремонту - `plugins`: розділені комами назви пакетів `@openclaw/*`, коли `plugin_publish_scope=selected` -- `publish_openclaw_npm`: типово `true`; встановлюйте `false` лише під час використання - робочого процесу як оркестратора виправлення тільки для plugin +- `publish_openclaw_npm`: типово `true`; встановлюйте `false` лише коли використовуєте + workflow як оркестратор ремонту тільки Plugin -`OpenClaw Release Checks` приймає такі керовані оператором вхідні дані: +`OpenClaw Release Checks` приймає такі вхідні параметри, керовані оператором: -- `ref`: гілка, тег або повний SHA коміту для валідації. Перевірки із секретами - вимагають, щоб визначений коміт був досяжний з гілки OpenClaw або - тегу релізу. +- `ref`: гілка, tag або повний commit SHA для перевірки. Перевірки, + що містять секрети, вимагають, щоб розв’язаний коміт був досяжний з гілки OpenClaw або + release tag. Правила: -- Стабільні теги та теги виправлень можуть публікуватися або до `beta`, або до `latest` -- Бета-теги попереднього релізу можуть публікуватися лише до `beta` -- Для `OpenClaw NPM Release` вхідний повний SHA коміту дозволений лише коли +- Стабільні та корекційні tags можуть публікуватися або до `beta`, або до `latest` +- Beta prerelease tags можуть публікуватися лише до `beta` +- Для `OpenClaw NPM Release` введення повного commit SHA дозволене лише коли `preflight_only=true` -- `OpenClaw Release Checks` і `Full Release Validation` завжди є - лише валідаційними -- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, який використовувався під час preflight; - робочий процес перевіряє ці метадані перед продовженням публікації +- `OpenClaw Release Checks` і `Full Release Validation` завжди + лише перевіряють +- Справжній шлях публікації має використовувати той самий `npm_dist_tag`, що використовувався під час preflight; + workflow перевіряє ці metadata перед продовженням публікації ## Послідовність стабільного npm-релізу Під час підготовки стабільного npm-релізу: 1. Запустіть `OpenClaw NPM Release` з `preflight_only=true` - - До існування тегу можна використати поточний повний SHA коміту гілки робочого процесу - для валідаційного dry run робочого процесу preflight + - До появи tag можна використати поточний повний commit SHA гілки workflow + для пробного запуску preflight workflow лише з перевіркою 2. Виберіть `npm_dist_tag=beta` для звичайного потоку beta-first або `latest` лише - коли ви навмисно хочете пряме стабільне публікування -3. Запустіть `Full Release Validation` на гілці релізу, тегу релізу або повному - SHA коміту, коли потрібні звичайний CI плюс live prompt cache, Docker, QA Lab, - Matrix і покриття Telegram з одного ручного робочого процесу + коли ви навмисно хочете пряму стабільну публікацію +3. Запустіть `Full Release Validation` на release branch, release tag або повному + commit SHA, коли вам потрібні звичайний CI плюс live prompt cache, Docker, QA Lab, + Matrix і покриття Telegram з одного ручного workflow 4. Якщо вам навмисно потрібен лише детермінований звичайний граф тестів, запустіть - ручний робочий процес `CI` на ref релізу натомість + ручний workflow `CI` на release ref натомість 5. Збережіть успішний `preflight_run_id` 6. Запустіть `OpenClaw Release Publish` з тим самим `tag`, тим самим `npm_dist_tag` - і збереженим `preflight_run_id`; він публікує externalized plugins до npm + і збереженим `preflight_run_id`; він публікує зовнішні plugins до npm і ClawHub перед просуванням npm-пакета OpenClaw -7. Якщо реліз потрапив до `beta`, використовуйте приватний робочий процес - `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml` - для просування цієї стабільної версії з `beta` до `latest` -8. Якщо реліз навмисно опублікований безпосередньо до `latest`, а `beta` - має негайно наслідувати ту саму стабільну збірку, використовуйте той самий приватний - робочий процес, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій - self-healing синхронізації перемістити `beta` пізніше +7. Якщо реліз потрапив у `beta`, використайте приватний + workflow `openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml`, + щоб просунути цю стабільну версію з `beta` до `latest` +8. Якщо реліз навмисно опубліковано безпосередньо до `latest` і `beta` + має негайно вказувати на ту саму стабільну збірку, використайте той самий приватний + workflow, щоб спрямувати обидва dist-tags на стабільну версію, або дозвольте його запланованій + самовідновлювальній синхронізації перемістити `beta` пізніше -Зміна dist-tag розміщена в приватному репозиторії з міркувань безпеки, тому що вона все ще -вимагає `NPM_TOKEN`, тоді як публічний репозиторій зберігає OIDC-only публікацію. +Мутація dist-tag розміщена в приватному репозиторії з міркувань безпеки, бо вона все ще +потребує `NPM_TOKEN`, тоді як публічний репозиторій зберігає публікацію лише через OIDC. -Це робить як шлях прямої публікації, так і шлях beta-first просування +Це зберігає і шлях прямої публікації, і шлях beta-first promotion задокументованими та видимими для оператора. -Якщо супровідник мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password -CLI (`op`) лише всередині виділеної tmux-сесії. Не викликайте `op` -безпосередньо з основної оболонки агента; утримання цього всередині tmux робить підказки, -сповіщення та обробку OTP спостережуваними й запобігає повторним сповіщенням хоста. +Якщо maintainer мусить повернутися до локальної npm-автентифікації, запускайте будь-які команди 1Password +CLI (`op`) лише всередині спеціальної сесії tmux. Не викликайте `op` +безпосередньо з основної оболонки агента; утримання його всередині tmux робить prompts, +alerts і обробку OTP спостережуваними та запобігає повторним alerts на хості. ## Публічні посилання @@ -679,7 +683,7 @@ CLI (`op`) лише всередині виділеної tmux-сесії. Не - [`scripts/package-mac-dist.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/package-mac-dist.sh) - [`scripts/make_appcast.sh`](https://github.com/openclaw/openclaw/blob/main/scripts/make_appcast.sh) -Супровідники використовують приватну документацію релізу в +Maintainers використовують приватну документацію релізів у [`openclaw/maintainers/release/README.md`](https://github.com/openclaw/maintainers/blob/main/release/README.md) для фактичного runbook.