Ana içeriğe atla

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

OpenClaw’ın üç genel kullanıma açık yayın kanalı vardır:
  • stable: varsayılan olarak npm beta kanalına veya açıkça istendiğinde npm latest kanalına yayımlanan etiketli sürümler
  • beta: npm beta kanalına yayımlanan ön sürüm etiketleri
  • dev: main dalının hareketli başı

​
Sürüm adlandırma

  • Kararlı yayın sürümü: YYYY.M.D
    • Git etiketi: vYYYY.M.D
  • Kararlı düzeltme yayın sürümü: YYYY.M.D-N
    • Git etiketi: vYYYY.M.D-N
  • Beta ön sürüm sürümü: YYYY.M.D-beta.N
    • Git etiketi: vYYYY.M.D-beta.N
  • Ayı veya günü başına sıfır ekleyerek yazmayın
  • latest, geçerli yükseltilmiş kararlı npm yayını anlamına gelir
  • beta, geçerli beta kurulum hedefi anlamına gelir
  • Kararlı ve kararlı düzeltme sürümleri varsayılan olarak npm beta kanalına yayımlanır; yayın operatörleri açıkça latest hedefleyebilir veya incelenmiş bir beta derlemesini daha sonra yükseltebilir
  • Her kararlı OpenClaw sürümü npm paketini ve macOS uygulamasını birlikte gönderir; beta sürümleri normalde önce npm/paket yolunu doğrular ve yayımlar; Mac uygulaması derleme/imzalama/noter onayı, açıkça istenmediği sürece kararlı sürüme ayrılır

​
Yayın sıklığı

  • Yayınlar önce beta üzerinden ilerler
  • Kararlı sürüm, yalnızca en son beta doğrulandıktan sonra gelir
  • Bakımcılar normalde yayınları geçerli main dalından oluşturulan bir release/YYYY.M.D dalından keser; böylece yayın doğrulaması ve düzeltmeleri main üzerindeki yeni geliştirmeyi engellemez
  • Bir beta etiketi gönderilmiş veya yayımlanmışsa ve düzeltme gerekiyorsa, bakımcılar eski beta etiketini silmek veya yeniden oluşturmak yerine sonraki -beta.N etiketini keser
  • Ayrıntılı yayın prosedürü, onaylar, kimlik bilgileri ve kurtarma notları yalnızca bakımcılara açıktır

​
Yayın operatörü kontrol listesi

Bu kontrol listesi yayın akışının genel yapısıdır. Özel kimlik bilgileri, imzalama, noter onayı, dist-tag kurtarma ve acil geri alma ayrıntıları yalnızca bakımcılara açık yayın çalışma kılavuzunda kalır.
  1. Geçerli main dalından başlayın: en son değişiklikleri çekin, hedef commit’in gönderildiğini ve geçerli main CI durumunun ondan dal oluşturmak için yeterince yeşil olduğunu doğrulayın.
  2. Üstteki CHANGELOG.md bölümünü gerçek commit geçmişinden /changelog ile yeniden yazın, girdileri kullanıcı odaklı tutun, commit’leyin, gönderin ve dallanmadan önce bir kez daha rebase/pull yapın.
  3. Yayın uyumluluk kayıtlarını src/plugins/compat/registry.ts ve src/commands/doctor/shared/deprecation-compat.ts içinde gözden geçirin. Süresi dolmuş uyumluluğu yalnızca yükseltme yolu kapsanmaya devam ettiğinde kaldırın veya neden bilinçli olarak taşındığını kaydedin.
  4. Geçerli main dalından release/YYYY.M.D oluşturun; normal yayın işini doğrudan main üzerinde yapmayın.
  5. Amaçlanan etiket için gereken her sürüm konumunu yükseltin, ardından pnpm release:prep çalıştırın. Bu komut Plugin sürümlerini, Plugin envanterini, yapılandırma şemasını, paketlenmiş kanal yapılandırma metaverisini, yapılandırma belgeleri temelini, Plugin SDK dışa aktarımlarını ve Plugin SDK API temelini doğru sırayla yeniler. Etiketlemeden önce oluşan üretilmiş sapmaları commit’leyin. Ardından yerel deterministik ön kontrolü çalıştırın: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build ve pnpm release:check.
  6. OpenClaw NPM Release işini preflight_only=true ile çalıştırın. Bir etiket var olmadan önce, yalnızca doğrulama amaçlı ön kontrol için tam 40 karakterlik yayın dalı SHA’sına izin verilir. Başarılı preflight_run_id değerini saklayın.
  7. Yayın dalı, etiket veya tam commit SHA’sı için Full Release Validation ile tüm ön yayın testlerini başlatın. Bu, dört büyük yayın test kutusu için tek manuel giriş noktasıdır: Vitest, Docker, QA Lab ve Package.
  8. Doğrulama başarısız olursa yayın dalında düzeltin ve düzeltmeyi kanıtlayan en küçük başarısız dosyayı, kanalı, workflow job’ını, paket profilini, sağlayıcıyı veya model izin listesini yeniden çalıştırın. Tam şemsiyeyi yalnızca değişen yüzey önceki kanıtı geçersiz kıldığında yeniden çalıştırın.
  9. Beta için vYYYY.M.D-beta.N etiketleyin, ardından eşleşen release/YYYY.M.D dalından OpenClaw Release Publish çalıştırın. Bu iş pnpm plugins:sync:check doğrular, yayımlanabilir tüm Plugin paketlerini npm’e ve aynı seti paralel olarak ClawHub’a gönderir, ardından Plugin npm yayını başarılı olur olmaz hazırlanmış OpenClaw npm ön kontrol yapıtını eşleşen dist-tag ile yükseltir. OpenClaw npm yayın alt işi başarılı olduktan sonra, tam eşleşen CHANGELOG.md bölümünden eşleşen GitHub release/prerelease sayfasını oluşturur veya günceller. npm latest kanalına yayımlanan kararlı sürümler GitHub latest release olur; npm beta kanalında tutulan kararlı bakım sürümleri GitHub latest=false ile oluşturulur. OpenClaw npm yayımlanırken ClawHub yayımlaması hâlâ çalışıyor olabilir, ancak yayın yayımlama workflow’u alt çalışma kimliklerini hemen yazdırır. Varsayılan olarak ClawHub’ı gönderdikten sonra beklemez; bu nedenle OpenClaw npm kullanılabilirliği daha yavaş ClawHub onayları veya kayıt işleri tarafından engellenmez. ClawHub’ın workflow tamamlanmasını engellemesi gerektiğinde wait_for_clawhub=true ayarlayın. ClawHub yolu geçici CLI bağımlılık kurulum hatalarını yeniden dener, bir önizleme hücresi aksasa bile önizlemeden geçen Plugin’leri yayımlar ve kısmi yayınların görünür ve yeniden denenebilir kalması için beklenen her Plugin sürümü için kayıt doğrulamasıyla sona erer. Yayından sonra GitHub prerelease’i, npm beta dist-tag’lerini, npm bütünlüğünü, yayımlanmış kurulum yolunu, ClawHub tam sürümlerini, ClawHub yapıtlarını ve alt workflow sonuçlarını tek komuttan doğrulamak için pnpm release:verify-beta -- YYYY.M.D-beta.N --openclaw-npm-run <run-id> --plugin-npm-run <run-id> --plugin-clawhub-run <run-id> çalıştırın. ClawHub yan işi yalnızca yeniden denenebilir işlerde başarısız olduysa ve yerinde yeniden çalıştırılması gerekiyorsa --rerun-failed-clawhub ekleyin. Ardından yayımlanmış openclaw@YYYY.M.D-beta.N veya openclaw@beta paketine karşı yayın sonrası paket kabulünü çalıştırın. Gönderilmiş veya yayımlanmış bir ön sürümün düzeltmeye ihtiyacı varsa sonraki eşleşen ön sürüm numarasını kesin; eski ön sürümü silmeyin veya yeniden yazmayın.
  10. Kararlı sürüm için yalnızca incelenmiş beta veya yayın adayı gerekli doğrulama kanıtına sahip olduktan sonra devam edin. Kararlı npm yayını da başarılı ön kontrol yapıtını preflight_run_id ile yeniden kullanarak OpenClaw Release Publish üzerinden geçer; kararlı macOS yayın hazırlığı ayrıca paketlenmiş .zip, .dmg, .dSYM.zip ve main üzerindeki güncellenmiş appcast.xml gerektirir. Özel macOS yayın workflow’u, yayın varlıkları doğrulandıktan sonra imzalı appcast’i otomatik olarak herkese açık main dalına yayımlar; dal koruması doğrudan göndermeyi engellerse bir appcast PR’ı açar veya günceller.
  11. Yayından sonra npm yayın sonrası doğrulayıcısını, yayın sonrası kanal kanıtına ihtiyacınız olduğunda isteğe bağlı bağımsız yayımlanmış-npm Telegram E2E’yi, gerektiğinde dist-tag yükseltmesini çalıştırın, oluşturulan GitHub release sayfasını doğrulayın ve yayın duyurusu adımlarını çalıştırın.

​
Yayın ön kontrolü

  • Sürüm ön uçuşundan önce pnpm check:test-types çalıştırın; böylece test TypeScript’i daha hızlı yerel pnpm check geçidi dışında da kapsanır
  • Sürüm ön uçuşundan önce pnpm check:architecture çalıştırın; böylece daha kapsamlı içe aktarma döngüsü ve mimari sınır denetimleri daha hızlı yerel geçit dışında yeşil olur
  • pnpm release:check öncesinde pnpm build && pnpm ui:build çalıştırın; böylece beklenen dist/* sürüm yapıtları ve Control UI paketi, paket doğrulama adımı için mevcut olur
  • Kök sürüm artırmasından sonra ve etiketlemeden önce pnpm release:prep çalıştırın. Bu komut, sürüm/yapılandırma/API değişikliğinden sonra sıkça sapma gösteren tüm deterministik sürüm üreticilerini çalıştırır: plugin sürümleri, plugin envanteri, temel yapılandırma şeması, paketlenen kanal yapılandırma meta verileri, yapılandırma dokümantasyonu başlangıç değeri, plugin SDK dışa aktarımları ve plugin SDK API başlangıç değeri. pnpm release:check, bu korumaları denetim modunda yeniden çalıştırır ve paket sürüm denetimlerini çalıştırmadan önce bulduğu tüm üretilmiş sapma hatalarını tek geçişte raporlar.
  • Sürüm onayından önce manuel Full Release Validation iş akışını çalıştırarak tüm ön sürüm test kutularını tek bir giriş noktasından başlatın. Bir dal, etiket veya tam commit SHA kabul eder, manuel CI tetikler ve kurulum smoke, paket kabulü, çapraz OS paket denetimleri, QA Lab paritesi, Matrix ve Telegram hatları için OpenClaw Release Checks tetikler. Kararlı/varsayılan çalıştırmalar, kapsamlı canlı/E2E ve Docker sürüm yolu bekletmesini run_release_soak=true arkasında tutar; release_profile=full bekletmeyi zorunlu kılar. release_profile=full ve rerun_group=all ile, sürüm denetimlerinden gelen release-package-under-test yapıtına karşı paket Telegram E2E’yi de çalıştırır. Bir beta yayımladıktan sonra, sürüm denetimleri, Package Acceptance ve paket Telegram E2E genelinde gönderilmiş npm paketini sürüm tarball’ını yeniden oluşturmadan yeniden kullanmak için release_package_spec sağlayın. Telegram’ın sürüm doğrulamasının geri kalanından farklı bir yayımlanmış paket kullanması gerektiğinde yalnızca npm_telegram_package_spec sağlayın. Package Acceptance’ın sürüm paketi belirtiminden farklı bir yayımlanmış paket kullanması gerektiğinde package_acceptance_package_spec sağlayın. Özel kanıt raporunun, Telegram E2E’yi zorlamadan doğrulamanın yayımlanmış bir npm paketiyle eşleştiğini kanıtlaması gerektiğinde evidence_package_spec sağlayın. Örnek: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D
  • Sürüm çalışması devam ederken bir paket adayı için yan kanal kanıtı istediğinizde manuel Package Acceptance iş akışını çalıştırın. openclaw@beta, openclaw@latest veya kesin bir sürüm için source=npm; geçerli workflow_ref donanımıyla güvenilir bir package_ref dalı/etiketi/SHA’sını paketlemek için source=ref; gerekli SHA-256 ile bir HTTPS tarball için source=url; ya da başka bir GitHub Actions çalıştırması tarafından yüklenen tarball için source=artifact kullanın. İş akışı adayı package-under-test olarak çözümler, Docker E2E sürüm zamanlayıcısını bu tarball’a karşı yeniden kullanır ve aynı tarball’a karşı telegram_mode=mock-openai veya telegram_mode=live-frontier ile Telegram QA çalıştırabilir. Seçilen Docker hatları published-upgrade-survivor içerdiğinde, paket yapıtı adaydır ve published_upgrade_survivor_baseline yayımlanmış başlangıç değerini seçer. update-restart-auth, aday paketi hem kurulu CLI hem de package-under-test olarak kullanır; böylece aday güncelleme komutunun yönetilen yeniden başlatma yolunu çalıştırır. Örnek: 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 Yaygın profiller:
    • smoke: kurulum/kanal/ajan, gateway ağı ve yapılandırma yeniden yükleme hatları
    • package: OpenWebUI veya canlı ClawHub olmadan yapıt-yerel paket/güncelleme/yeniden başlatma/plugin hatları
    • product: paket profiline ek olarak MCP kanalları, cron/alt ajan temizliği, OpenAI web araması ve OpenWebUI
    • full: OpenWebUI ile Docker sürüm yolu parçaları
    • custom: odaklı bir yeniden çalıştırma için kesin docker_lanes seçimi
  • Yalnızca sürüm adayı için tam normal CI kapsamına ihtiyaç duyduğunuzda manuel CI iş akışını doğrudan çalıştırın. Manuel CI tetiklemeleri değişiklik kapsamlandırmasını atlar ve Linux Node parçalarını, paketlenen-plugin parçalarını, kanal sözleşmelerini, Node 22 uyumluluğunu, check, check-additional, build smoke, dokümantasyon denetimlerini, Python skills, Windows, macOS, Android ve Control UI i18n hatlarını zorunlu kılar. Örnek: gh workflow run ci.yml --ref release/YYYY.M.D
  • Sürüm telemetrisini doğrularken pnpm qa:otel:smoke çalıştırın. QA-lab’i yerel bir OTLP/HTTP alıcısı üzerinden çalıştırır ve Opik, Langfuse veya başka bir harici toplayıcı gerektirmeden dışa aktarılan iz span adlarını, sınırlandırılmış öznitelikleri ve içerik/tanımlayıcı redaksiyonunu doğrular.
  • Her etiketli sürümden önce pnpm release:check çalıştırın
  • Etiket mevcut olduktan sonra mutasyon yapan yayımlama dizisi için OpenClaw Release Publish çalıştırın. Bunu release/YYYY.M.D üzerinden (veya main’den erişilebilir bir etiket yayımlarken main üzerinden) tetikleyin, sürüm etiketini ve başarılı OpenClaw npm preflight_run_id değerini iletin ve odaklı bir onarım çalıştırmıyorsanız varsayılan plugin yayımlama kapsamını all-publishable olarak bırakın. İş akışı plugin npm yayımlamasını, plugin ClawHub yayımlamasını ve OpenClaw npm yayımlamasını sıralı hale getirir; böylece çekirdek paket, dışsallaştırılmış plugin’lerinden önce yayımlanmaz.
  • Sürüm denetimleri artık ayrı bir manuel iş akışında çalışır: OpenClaw Release Checks
  • OpenClaw Release Checks, sürüm onayından önce QA Lab mock parite hattını, hızlı canlı Matrix profilini ve Telegram QA hattını da çalıştırır. Canlı hatlar qa-live-shared ortamını kullanır; Telegram ayrıca Convex CI kimlik bilgisi kiralamalarını kullanır. Tam Matrix taşıma, medya ve E2EE envanterini paralel istediğinizde manuel QA-Lab - All Lanes iş akışını matrix_profile=all ve matrix_shards=true ile çalıştırın.
  • Çapraz OS kurulum ve yükseltme çalışma zamanı doğrulaması, yeniden kullanılabilir iş akışını doğrudan çağıran genel OpenClaw Release Checks ve Full Release Validation kapsamındadır: .github/workflows/openclaw-cross-os-release-checks-reusable.yml
  • Bu ayrım bilinçlidir: gerçek npm sürüm yolunu kısa, deterministik ve yapıt odaklı tutar; daha yavaş canlı denetimler ise yayımlamayı durdurmamak veya engellememek için kendi hattında kalır
  • Sır taşıyan sürüm denetimleri Full Release Validation üzerinden ya da main/sürüm iş akışı ref’inden tetiklenmelidir; böylece iş akışı mantığı ve sırlar kontrollü kalır
  • OpenClaw Release Checks, çözümlenen commit bir OpenClaw dalından veya sürüm etiketinden erişilebilir olduğu sürece dal, etiket veya tam commit SHA kabul eder
  • OpenClaw NPM Release yalnızca doğrulama ön uçuşu, itilmiş bir etiket gerektirmeden geçerli tam 40 karakterlik iş akışı dalı commit SHA’sını da kabul eder
  • Bu SHA yolu yalnızca doğrulama içindir ve gerçek yayımlamaya yükseltilemez
  • SHA modunda iş akışı yalnızca paket meta verisi denetimi için v<package.json version> sentezler; gerçek yayımlama hâlâ gerçek bir sürüm etiketi gerektirir
  • Her iki iş akışı da gerçek yayımlama ve yükseltme yolunu GitHub tarafından barındırılan çalıştırıcılarda tutarken, mutasyon yapmayan doğrulama yolu daha büyük Blacksmith Linux çalıştırıcılarını kullanabilir
  • Bu iş akışı OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache komutunu hem OPENAI_API_KEY hem de ANTHROPIC_API_KEY iş akışı sırlarını kullanarak çalıştırır
  • npm sürüm ön uçuşu artık ayrı sürüm denetimleri hattını beklemez
  • Bir sürüm adayını yerelde etiketlemeden önce RELEASE_TAG=vYYYY.M.D-beta.N pnpm release:fast-pretag-check çalıştırın. Yardımcı, GitHub yayımlama iş akışı başlamadan önce yaygın onay engelleyici hataları yakalayan sırayla hızlı sürüm korumalarını, plugin npm/ClawHub sürüm denetimlerini, derlemeyi, UI derlemesini ve release:openclaw:npm:check komutunu çalıştırır.
  • Onaydan önce RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts komutunu (veya eşleşen beta/düzeltme etiketini) çalıştırın
  • npm yayımlamasından sonra, yayımlanmış registry kurulum yolunu yeni bir geçici önek içinde doğrulamak için node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D komutunu (veya eşleşen beta/düzeltme sürümünü) çalıştırın
  • Bir beta yayımlamasından sonra, paylaşılan kiralanmış Telegram kimlik bilgisi havuzunu kullanarak yayımlanmış npm paketine karşı kurulu paket onboarding’ini, Telegram kurulumunu ve gerçek Telegram E2E’yi doğrulamak için 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 çalıştırın. Yerel maintainer tek seferlik çalıştırmaları Convex değişkenlerini atlayabilir ve üç OPENCLAW_QA_TELEGRAM_* ortam kimlik bilgisini doğrudan iletebilir.
  • Bir maintainer makinesinden tam yayımlama sonrası beta smoke çalıştırmak için pnpm release:beta-smoke -- --beta betaN kullanın. Yardımcı, Parallels npm güncelleme/yeni hedef doğrulamasını çalıştırır, NPM Telegram Beta E2E tetikler, kesin iş akışı çalıştırmasını yoklar, yapıtı indirir ve Telegram raporunu yazdırır.
  • Maintainer’lar aynı yayımlama sonrası denetimi GitHub Actions üzerinden manuel NPM Telegram Beta E2E iş akışıyla çalıştırabilir. Bu iş akışı bilinçli olarak yalnızca manueldir ve her merge işleminde çalışmaz.
  • Maintainer sürüm otomasyonu artık ön uçuş-sonra-yükseltme kullanır:
    • gerçek npm yayımlaması başarılı bir npm preflight_run_id değerini geçmelidir
    • gerçek npm yayımlaması, başarılı ön uçuş çalıştırmasıyla aynı main veya release/YYYY.M.D dalından tetiklenmelidir
    • kararlı npm sürümleri varsayılan olarak beta kullanır
    • kararlı npm yayımlaması, iş akışı girdisi üzerinden açıkça latest hedefleyebilir
    • token tabanlı npm dist-tag mutasyonu artık güvenlik nedeniyle openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml içinde yer alır; çünkü genel repo OIDC-only yayımlamayı korurken npm dist-tag add hâlâ NPM_TOKEN gerektirir
    • genel macOS Release yalnızca doğrulama içindir; bir etiket yalnızca bir sürüm dalında bulunuyor ancak iş akışı main üzerinden tetikleniyorsa public_release_branch=release/YYYY.M.D ayarlayın
    • gerçek özel mac yayımlaması başarılı özel mac preflight_run_id ve validate_run_id değerlerini geçmelidir
    • gerçek yayımlama yolları, yapıtları yeniden oluşturmak yerine hazırlanmış yapıtları yükseltir
  • YYYY.M.D-N gibi kararlı düzeltme sürümleri için yayımlama sonrası doğrulayıcı, aynı geçici önek yükseltme yolunu YYYY.M.D sürümünden YYYY.M.D-N sürümüne de denetler; böylece sürüm düzeltmeleri eski global kurulumları sessizce temel kararlı yükte bırakamaz
  • npm sürüm ön uçuşu, tarball hem dist/control-ui/index.html hem de boş olmayan bir dist/control-ui/assets/ yükü içermedikçe kapalı başarısız olur; böylece boş bir tarayıcı panosunu yeniden göndermeyiz
  • Yayımlama sonrası doğrulama, yayımlanmış plugin giriş noktalarının ve paket meta verilerinin kurulu registry düzeninde mevcut olduğunu da denetler. Eksik plugin çalışma zamanı yükleri gönderen bir sürüm, postpublish doğrulayıcısında başarısız olur ve latest sürümüne yükseltilemez.
  • pnpm test:install:smoke, aday güncelleme tarball’ı üzerinde npm paket unpackedSize bütçesini de zorunlu kılar; böylece installer e2e, yanlışlıkla oluşan paket şişmesini sürüm yayımlama yolundan önce yakalar
  • Sürüm çalışması CI planlamasına, extension zamanlama manifestlerine veya extension test matrislerine dokunduysa, sürüm notlarının eski bir CI düzenini açıklamaması için onaydan önce .github/workflows/plugin-prerelease.yml içinden planner-owned plugin-prerelease-extension-shard matris çıktılarını yeniden üretin ve gözden geçirin
  • Kararlı macOS sürüm hazır oluşu, güncelleyici yüzeylerini de içerir:
    • GitHub sürümü paketlenmiş .zip, .dmg ve .dSYM.zip ile sonuçlanmalıdır
    • yayımlamadan sonra main üzerindeki appcast.xml yeni kararlı zip’e işaret etmelidir; özel macOS yayımlama iş akışı bunu otomatik olarak commit eder veya doğrudan push engellendiğinde bir appcast PR açar
    • paketlenmiş uygulama, hata ayıklama olmayan bir bundle id, boş olmayan bir Sparkle feed URL’si ve bu sürüm için kanonik Sparkle build tabanına eşit ya da ondan yüksek bir CFBundleVersion korumalıdır

​
Sürüm test kutuları

Full Release Validation, operatörlerin tüm ön sürüm testlerini tek bir giriş noktasından başlatma yoludur. Hızla değişen bir dalda sabitlenmiş commit kanıtı için, her alt workflow’un hedef SHA’ya sabitlenmiş geçici bir daldan çalışması amacıyla yardımcıyı kullanın: 
pnpm ci:full-release --sha <full-sha>
Yardımcı release-ci/<sha>-... dalını gönderir, bu daldan ref=<sha> ile Full Release Validation başlatır, her alt workflow headSha değerinin hedefle eşleştiğini doğrular, ardından geçici dalı siler. Bu, yanlışlıkla daha yeni bir main alt çalıştırmasını kanıtlamayı önler. Sürüm dalı veya etiket doğrulaması için, bunu güvenilen main workflow ref’inden çalıştırın ve sürüm dalını ya da etiketini ref olarak geçirin: 
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N
Workflow hedef ref’i çözer, target_ref=<release-ref> ile manuel CI başlatır, OpenClaw Release Checks başlatır, pakete dönük kontroller için üst release-package-under-test artifact’ı hazırlar ve release_profile=full olup rerun_group=all olduğunda ya da release_package_spec veya npm_telegram_package_spec ayarlandığında bağımsız paket Telegram E2E başlatır. Ardından OpenClaw Release Checks, kurulum smoke, çapraz işletim sistemi sürüm kontrolleri, soak etkinken canlı/E2E Docker sürüm yolu kapsamı, Telegram paket QA ile Package Acceptance, QA Lab eşliği, canlı Matrix ve canlı Telegram’a yayılır. Tam bir çalıştırma yalnızca Full Release Validation özetinde normal_ci ve release_checks başarılı görünüyorsa kabul edilebilir. full/all modunda npm_telegram alt çalıştırması da başarılı olmalıdır; full/all dışında, yayımlanmış bir release_package_spec veya npm_telegram_package_spec sağlanmadıkça atlanır. Son doğrulayıcı özeti her alt çalıştırma için en yavaş iş tablolarını içerir, böylece sürüm yöneticisi log indirmeden mevcut kritik yolu görebilir. Tam aşama matrisi, kesin workflow iş adları, stable ile full profil farkları, artifact’lar ve odaklı yeniden çalıştırma tutamaçları için Tam sürüm doğrulaması bölümüne bakın. Alt workflow’lar, hedef ref daha eski bir sürüm dalını veya etiketini gösterse bile Full Release Validation çalıştıran güvenilen ref’ten, normalde --ref main üzerinden başlatılır. Ayrı bir Full Release Validation workflow-ref girdisi yoktur; güvenilen harness’ı workflow çalıştırma ref’ini seçerek belirleyin. Hareketli main üzerinde kesin commit kanıtı için --ref main -f ref=<sha> kullanmayın; ham commit SHA’ları workflow dispatch ref’i olamaz, bu nedenle sabitlenmiş geçici dalı oluşturmak için pnpm ci:full-release --sha <sha> kullanın. Canlı/provider kapsamını seçmek için release_profile kullanın:
  • minimum: en hızlı sürüm açısından kritik OpenAI/core canlı ve Docker yolu
  • stable: sürüm onayı için minimuma ek olarak stable provider/backend kapsamı
  • full: stable’a ek olarak geniş danışma provider/medya kapsamı
Sürümü engelleyen hatlar yeşil olduğunda ve terfi öncesinde kapsamlı canlı/E2E, Docker sürüm yolu ve sınırlı yayımlanmış yükseltme dayanıklılığı taraması istediğinizde stable ile run_release_soak=true kullanın. Bu tarama, son dört stable paketin yanı sıra sabitlenmiş 2026.4.23 ve 2026.5.2 temel çizgilerini ve daha eski 2026.4.15 kapsamını kapsar; yinelenen temel çizgiler kaldırılır ve her temel çizgi kendi Docker runner işine bölünür. full, run_release_soak=true anlamına gelir. OpenClaw Release Checks, hedef ref’i bir kez release-package-under-test olarak çözmek için güvenilen workflow ref’ini kullanır ve soak çalıştığında bu artifact’ı çapraz işletim sistemi, Package Acceptance ve sürüm yolu Docker kontrollerinde yeniden kullanır. Bu, pakete dönük tüm kutuları aynı baytlarda tutar ve tekrarlanan paket derlemelerini önler. Beta zaten npm’deyse, release_package_spec=openclaw@YYYY.M.D-beta.N ayarlayın; böylece sürüm kontrolleri gönderilmiş paketi bir kez indirir, derleme kaynak SHA’sını dist/build-info.json içinden çıkarır ve bu artifact’ı çapraz işletim sistemi, Package Acceptance, sürüm yolu Docker ve paket Telegram hatları için yeniden kullanır. Çapraz işletim sistemi OpenAI kurulum smoke’u, repo/kuruluş değişkeni ayarlandığında OPENCLAW_CROSS_OS_OPENAI_MODEL kullanır; aksi halde openai/gpt-5.4 kullanır, çünkü bu hat en yavaş varsayılan modeli kıyaslamak yerine paket kurulumunu, onboarding’i, gateway başlatmayı ve tek bir canlı ajan turunu kanıtlar. Daha geniş canlı provider matrisi, modele özgü kapsamın yeridir. Sürüm aşamasına göre bu varyantları kullanın: 
# Validate an unpublished release candidate branch.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable

# Validate an exact pushed commit.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=<40-char-sha> \
  -f provider=openai \
  -f mode=both

# After publishing a beta, add published-package Telegram E2E.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f release_package_spec=openclaw@YYYY.M.D-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N \
  -f npm_telegram_provider_mode=mock-openai
Odaklı bir düzeltmeden sonraki ilk yeniden çalıştırma olarak tam şemsiyeyi kullanmayın. Bir kutu başarısız olursa, sonraki kanıt için başarısız alt workflow’u, işi, Docker hattını, paket profilini, model provider’ını veya QA hattını kullanın. Tam şemsiyeyi yalnızca düzeltme paylaşılan sürüm orkestrasyonunu değiştirdiyse ya da önceki tüm kutu kanıtlarını bayat hale getirdiyse yeniden çalıştırın. Şemsiyenin son doğrulayıcısı kaydedilmiş alt workflow çalıştırma kimliklerini yeniden kontrol eder, bu nedenle bir alt workflow başarıyla yeniden çalıştırıldıktan sonra yalnızca başarısız Verify full validation üst işini yeniden çalıştırın. Sınırlı kurtarma için şemsiyeye rerun_group geçirin. all gerçek sürüm adayı çalıştırmasıdır, ci yalnızca normal CI altını çalıştırır, plugin-prerelease yalnızca sürüme özel plugin altını çalıştırır, release-checks her sürüm kutusunu çalıştırır ve daha dar sürüm grupları install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live ve npm-telegramdır. Odaklı npm-telegram yeniden çalıştırmaları release_package_spec veya npm_telegram_package_spec gerektirir; release_profile=full ile full/all çalıştırmaları release-checks paket artifact’ını kullanır. Odaklı çapraz işletim sistemi yeniden çalıştırmaları cross_os_suite_filter=windows/packaged-upgrade veya başka bir işletim sistemi/suite filtresi ekleyebilir. QA release-check başarısızlıkları danışma niteliğindedir; yalnızca QA başarısızlığı sürüm doğrulamasını engellemez.

​
Vitest

Vitest kutusu manuel CI alt workflow’udur. Manuel CI, changed kapsamını bilerek atlar ve sürüm adayı için normal test grafiğini zorunlu kılar: Linux Node parçaları, paketlenmiş Plugin parçaları, kanal sözleşmeleri, Node 22 uyumluluğu, check, check-additional, build smoke, doküman kontrolleri, Python skills, Windows, macOS, Android ve Control UI i18n. Bu kutuyu “kaynak ağacı tam normal test suite’ini geçti mi?” sorusunu yanıtlamak için kullanın. Bu, sürüm yolu ürün doğrulamasıyla aynı değildir. Saklanacak kanıtlar:
  • başlatılan CI çalıştırma URL’sini gösteren Full Release Validation özeti
  • kesin hedef SHA üzerinde yeşil CI çalıştırması
  • regresyonları incelerken CI işlerinden başarısız veya yavaş parça adları
  • bir çalıştırmanın performans analizine ihtiyaç duyduğu durumlarda .artifacts/vitest-shard-timings.json gibi Vitest zamanlama artifact’ları
Manuel CI’yi doğrudan yalnızca sürüm deterministik normal CI gerektiriyor ancak Docker, QA Lab, canlı, çapraz işletim sistemi veya paket kutularını gerektirmiyorsa çalıştırın: 
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D

​
Docker

Docker kutusu, openclaw-live-and-e2e-checks-reusable.yml üzerinden OpenClaw Release Checks içinde ve sürüm modu install-smoke workflow’unda yer alır. Sürüm adayını yalnızca kaynak düzeyi testler yerine paketlenmiş Docker ortamları üzerinden doğrular. Sürüm Docker kapsamı şunları içerir:
  • yavaş Bun global kurulum smoke’u etkin olan tam kurulum smoke’u
  • hedef SHA’ya göre kök Dockerfile smoke imajı hazırlama/yeniden kullanımı; QR, root/gateway ve installer/Bun smoke işleri ayrı install-smoke parçaları olarak çalışır
  • depo E2E hatları
  • sürüm yolu Docker parçaları: core, package-update-openai, package-update-anthropic, package-update-core, plugins-runtime-plugins, plugins-runtime-services, plugins-runtime-install-a, plugins-runtime-install-b, plugins-runtime-install-c, plugins-runtime-install-d, plugins-runtime-install-e, plugins-runtime-install-f, plugins-runtime-install-g ve plugins-runtime-install-h
  • istendiğinde plugins-runtime-services parçası içinde OpenWebUI kapsamı
  • bölünmüş paketlenmiş plugin kurulum/kaldırma hatları bundled-plugin-install-uninstall-0 ile bundled-plugin-install-uninstall-23 arası
  • sürüm kontrolleri canlı suite’leri içerdiğinde canlı/E2E provider suite’leri ve Docker canlı model kapsamı
Yeniden çalıştırmadan önce Docker artifact’larını kullanın. Sürüm yolu zamanlayıcı .artifacts/docker-tests/ dizinini hat logları, summary.json, failures.json, aşama zamanlamaları, zamanlayıcı plan JSON’u ve yeniden çalıştırma komutlarıyla birlikte yükler. Odaklı kurtarma için tüm sürüm parçalarını yeniden çalıştırmak yerine yeniden kullanılabilir canlı/E2E workflow’unda docker_lanes=<lane[,lane]> kullanın. Oluşturulan yeniden çalıştırma komutları, kullanılabilir olduğunda önceki package_artifact_run_id ve hazırlanmış Docker imajı girdilerini içerir; böylece başarısız bir hat aynı tarball’ı ve GHCR imajlarını yeniden kullanabilir.

​
QA Lab

QA Lab kutusu da OpenClaw Release Checks parçasıdır. Vitest ve Docker paket mekaniklerinden ayrı olarak ajan davranışı ve kanal düzeyi sürüm kapısıdır. Sürüm QA Lab kapsamı şunları içerir:
  • ajan eşlik paketiyle OpenAI aday hattını Opus 4.6 temel çizgisiyle karşılaştıran mock eşlik hattı
  • qa-live-shared ortamını kullanan hızlı canlı Matrix QA profili
  • Convex CI kimlik bilgisi kiralamalarını kullanan canlı Telegram QA hattı
  • sürüm telemetrisinin açık yerel kanıta ihtiyaç duyduğu durumlarda pnpm qa:otel:smoke
Bu kutuyu “sürüm QA senaryolarında ve canlı kanal akışlarında doğru davranıyor mu?” sorusunu yanıtlamak için kullanın. Sürümü onaylarken eşlik, Matrix ve Telegram hatları için artifact URL’lerini saklayın. Tam Matrix kapsamı, varsayılan sürüm açısından kritik hat yerine manuel parçalanmış QA-Lab çalıştırması olarak kullanılabilir kalır.

​
Paket

Paket kutusu kurulabilir ürün kapısıdır. Package Acceptance ve scripts/resolve-openclaw-package-candidate.mjs çözücüsü tarafından desteklenir. Çözücü, adayı Docker E2E tarafından tüketilen package-under-test tarball’ına normalleştirir, paket envanterini doğrular, paket sürümünü ve SHA-256 değerini kaydeder ve workflow harness ref’ini paket kaynak ref’inden ayrı tutar. Desteklenen aday kaynakları:
  • source=npm: openclaw@beta, openclaw@latest veya kesin bir OpenClaw sürüm version
  • source=ref: seçilen workflow_ref harness’ı ile güvenilen bir package_ref dalını, etiketini veya tam commit SHA’sını paketle
  • source=url: gerekli package_sha256 ile bir HTTPS .tgz indir
  • source=artifact: başka bir GitHub Actions çalıştırması tarafından yüklenen .tgz dosyasını yeniden kullan
OpenClaw Release Checks, Package Acceptance’ı source=artifact, hazırlanmış sürüm paket artifaktı, suite_profile=custom, docker_lanes=doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor update-restart-auth plugins-offline plugin-update, telegram_mode=mock-openai ile çalıştırır. Package Acceptance; geçiş, güncelleme, yapılandırılmış kimlik doğrulama güncellemesi yeniden başlatması, canlı ClawHub Skills kurulumu, eski Plugin bağımlılığı temizliği, çevrimdışı Plugin fikstürleri, Plugin güncellemesi ve Telegram paket QA kapsamını aynı çözümlenmiş tarball üzerinde tutar. Engelleyici sürüm denetimleri varsayılan en son yayımlanmış paket temelini kullanır; run_release_soak=true veya release_profile=full, 2026.4.23 sürümünden latest sürümüne kadar tüm kararlı npm’de yayımlanmış temellere ve bildirilen sorun fikstürlerine genişler. Zaten gönderilmiş bir aday için Package Acceptance’ı source=npm ile, yayımlamadan önce SHA destekli yerel npm tarball için source=ref/source=artifact ile kullanın. Bu, daha önce Parallels gerektiren paket/güncelleme kapsamının çoğu için GitHub yerelindeki alternatiftir. İşletim sistemine özgü onboarding, yükleyici ve platform davranışı için çapraz işletim sistemi sürüm denetimleri hâlâ önemlidir, ancak paket/güncelleme ürün doğrulaması Package Acceptance’ı tercih etmelidir. Güncelleme ve Plugin doğrulaması için kanonik kontrol listesi Testing updates and plugins sayfasıdır. Bir Plugin kurulumu/güncellemesi, doctor temizliği veya yayımlanmış paket geçiş değişikliğini hangi yerel, Docker, Package Acceptance ya da sürüm denetimi kulvarının kanıtladığına karar verirken bunu kullanın. Her kararlı 2026.4.23+ paketinden kapsamlı yayımlanmış güncelleme geçişi, Full Release CI’ın parçası değil, ayrı bir manuel Update Migration iş akışıdır. Eski package-acceptance toleransı bilinçli olarak süreyle sınırlanmıştır. 2026.4.25 sürümüne kadar paketler, npm’e zaten yayımlanmış metadata boşlukları için uyumluluk yolunu kullanabilir: tarball’da eksik özel QA envanter girdileri, eksik gateway install --wrapper, tarball’dan türetilmiş git fikstüründe eksik yama dosyaları, eksik kalıcı update.channel, eski Plugin kurulum kaydı konumları, eksik marketplace kurulum kaydı kalıcılığı ve plugins update sırasında yapılandırma metadata geçişi. Yayımlanmış 2026.4.26 paketi, zaten gönderilmiş yerel derleme metadata damga dosyaları için uyarı verebilir. Daha sonraki paketler modern paket sözleşmelerini karşılamalıdır; aynı boşluklar sürüm doğrulamasını başarısız kılar. Sürüm sorusu gerçek bir kurulabilir paketle ilgili olduğunda daha geniş Package Acceptance profilleri kullanın: 
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
Yaygın paket profilleri:
  • smoke: hızlı paket kurulumu/kanal/agent, Gateway ağı ve yapılandırma yeniden yükleme kulvarları
  • package: kurulum/güncelleme/yeniden başlatma/Plugin paket sözleşmeleri ve canlı ClawHub Skills kurulum kanıtı; bu, sürüm denetimi varsayılanıdır
  • product: package artı MCP kanalları, cron/subagent temizliği, OpenAI web araması ve OpenWebUI
  • full: OpenWebUI ile Docker sürüm yolu parçaları
  • custom: odaklı yeniden çalıştırmalar için tam docker_lanes listesi
Paket adayı Telegram kanıtı için Package Acceptance üzerinde telegram_mode=mock-openai veya telegram_mode=live-frontier etkinleştirin. İş akışı çözümlenmiş package-under-test tarball’ını Telegram kulvarına geçirir; bağımsız Telegram iş akışı, yayım sonrası denetimler için yayımlanmış bir npm spesifikasyonunu hâlâ kabul eder.

​
Sürüm yayımlama otomasyonu

OpenClaw Release Publish, normal değişiklik yapan yayımlama giriş noktasıdır. Sürümün ihtiyaç duyduğu sırayla trusted-publisher iş akışlarını düzenler:
  1. Sürüm etiketini checkout yapar ve commit SHA’sını çözümler.
  2. Etiketin main veya release/* üzerinden erişilebilir olduğunu doğrular.
  3. pnpm plugins:sync:check çalıştırır.
  4. publish_scope=all-publishable ve ref=<release-sha> ile Plugin NPM Release tetikler.
  5. Aynı scope ve SHA ile Plugin ClawHub Release tetikler.
  6. Sürüm etiketi, npm dist-tag ve kaydedilmiş preflight_run_id ile OpenClaw NPM Release tetikler.
Beta yayımlama örneği: 
gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta
Varsayılan beta dist-tag’e kararlı yayımlama: 
gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta
Doğrudan latest sürümüne kararlı yükseltme açıkça belirtilir: 
gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=latest
Daha düşük seviyeli Plugin NPM Release ve Plugin ClawHub Release iş akışlarını yalnızca odaklı onarım veya yeniden yayımlama işleri için kullanın. Seçili bir Plugin onarımı için plugin_publish_scope=selected ve plugins=@openclaw/name değerlerini OpenClaw Release Publish iş akışına geçirin ya da OpenClaw paketinin yayımlanmaması gerektiğinde alt iş akışını doğrudan tetikleyin.

​
NPM iş akışı girdileri

OpenClaw NPM Release şu operatör kontrollü girdileri kabul eder:
  • tag: v2026.4.2, v2026.4.2-1 veya v2026.4.2-beta.1 gibi zorunlu sürüm etiketi; preflight_only=true olduğunda yalnızca doğrulama preflight’ı için mevcut tam 40 karakterlik iş akışı dalı commit SHA’sı da olabilir
  • preflight_only: yalnızca doğrulama/derleme/paket için true, gerçek yayımlama yolu için false
  • preflight_run_id: gerçek yayımlama yolunda zorunludur; böylece iş akışı başarılı preflight çalışmasından hazırlanmış tarball’ı yeniden kullanır
  • npm_dist_tag: yayımlama yolu için npm hedef etiketi; varsayılanı beta
OpenClaw Release Publish şu operatör kontrollü girdileri kabul eder:
  • tag: zorunlu sürüm etiketi; zaten mevcut olmalıdır
  • preflight_run_id: başarılı OpenClaw NPM Release preflight çalışma kimliği; publish_openclaw_npm=true olduğunda zorunludur
  • npm_dist_tag: OpenClaw paketi için npm hedef etiketi
  • plugin_publish_scope: varsayılanı all-publishable; selected değerini yalnızca odaklı onarım işleri için kullanın
  • plugins: plugin_publish_scope=selected olduğunda virgülle ayrılmış @openclaw/* paket adları
  • publish_openclaw_npm: varsayılanı true; yalnızca iş akışını sadece Plugin onarım düzenleyicisi olarak kullanırken false yapın
  • wait_for_clawhub: varsayılanı false; böylece npm kullanılabilirliği ClawHub sidecar tarafından engellenmez; yalnızca iş akışı tamamlanmasının ClawHub tamamlanmasını da içermesi gerektiğinde true yapın
OpenClaw Release Checks şu operatör kontrollü girdileri kabul eder:
  • ref: doğrulanacak dal, etiket veya tam commit SHA. Gizli içeren denetimler, çözümlenmiş commit’in bir OpenClaw dalından veya sürüm etiketinden erişilebilir olmasını gerektirir.
  • run_release_soak: kararlı/varsayılan sürüm denetimlerinde kapsamlı canlı/E2E, Docker sürüm yolu ve all-since upgrade-survivor soak kapsamını seçer. release_profile=full tarafından zorunlu olarak açılır.
Kurallar:
  • Kararlı ve düzeltme etiketleri beta veya latest etiketlerinden birine yayımlanabilir
  • Beta ön sürüm etiketleri yalnızca beta etiketine yayımlanabilir
  • OpenClaw NPM Release için tam commit SHA girdisine yalnızca preflight_only=true olduğunda izin verilir
  • OpenClaw Release Checks ve Full Release Validation her zaman yalnızca doğrulamadır
  • Gerçek yayımlama yolu, preflight sırasında kullanılan aynı npm_dist_tag değerini kullanmalıdır; iş akışı yayımlamadan önce bu metadata’nın devam ettiğini doğrular

​
Kararlı npm sürüm sırası

Kararlı bir npm sürümü çıkarırken:
  1. preflight_only=true ile OpenClaw NPM Release çalıştırın
    • Bir etiket mevcut olmadan önce, preflight iş akışının yalnızca doğrulama amaçlı kuru çalıştırması için mevcut tam iş akışı dalı commit SHA’sını kullanabilirsiniz
  2. Normal önce beta akışı için npm_dist_tag=beta seçin veya yalnızca bilinçli olarak doğrudan kararlı yayımlama istediğinizde latest seçin
  3. Tek bir manuel iş akışından normal CI artı canlı prompt cache, Docker, QA Lab, Matrix ve Telegram kapsamı istediğinizde sürüm dalı, sürüm etiketi veya tam commit SHA üzerinde Full Release Validation çalıştırın
  4. Bilinçli olarak yalnızca deterministik normal test grafiğine ihtiyacınız varsa, bunun yerine sürüm ref’i üzerinde manuel CI iş akışını çalıştırın
  5. Başarılı preflight_run_id değerini kaydedin
  6. Aynı tag, aynı npm_dist_tag ve kaydedilmiş preflight_run_id ile OpenClaw Release Publish çalıştırın; OpenClaw npm paketini yükseltmeden önce dışsallaştırılmış Plugin’leri npm ve ClawHub’a yayımlar
  7. Sürüm beta üzerinde yayımlandıysa, bu kararlı sürümü beta etiketinden latest etiketine yükseltmek için özel openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml iş akışını kullanın
  8. Sürüm bilinçli olarak doğrudan latest etiketine yayımlandıysa ve beta aynı kararlı derlemeyi hemen izlemeliyse, her iki dist-tag’i de kararlı sürüme yönlendirmek için aynı özel iş akışını kullanın veya zamanlanmış kendi kendini iyileştiren senkronizasyonunun beta etiketini daha sonra taşımasına izin verin
Dist-tag değişikliği güvenlik nedeniyle özel repoda yaşar; çünkü hâlâ NPM_TOKEN gerektirirken, herkese açık repo yalnızca OIDC yayımlamayı korur. Bu, doğrudan yayımlama yolunu ve önce beta yükseltme yolunu hem belgelenmiş hem de operatörün görebileceği durumda tutar. Bir maintainer yerel npm kimlik doğrulamasına geri dönmek zorundaysa, tüm 1Password CLI (op) komutlarını yalnızca ayrılmış bir tmux oturumu içinde çalıştırın. op komutunu ana agent kabuğundan doğrudan çağırmayın; bunu tmux içinde tutmak prompt’ları, uyarıları ve OTP işlemeyi gözlemlenebilir kılar ve yinelenen host uyarılarını önler.

​
Herkese açık referanslar

Maintainer’lar gerçek runbook için özel sürüm dokümanlarını openclaw/maintainers/release/README.md konumunda kullanır.

​
İlgili