Politica di rilascio

OpenClaw espone attualmente tre canali di aggiornamento rivolti agli utenti:

• stable: il canale di rilascio promosso esistente, che continua a risolversi tramite npm latest fino all'arrivo della milestone separata CLI/canale
• beta: tag di prerelease pubblicati su npm beta
• dev: la testa mobile di main

Separatamente, gli operatori di rilascio possono pubblicare il pacchetto core del mese completato precedente su npm extended-stable, a partire dalla patch 33. La linea finale regolare del mese corrente continua su npm latest; questa separazione di pubblicazione lato operatore non modifica di per se' la risoluzione dei canali di aggiornamento della CLI.

Nomi delle versioni

• Versione mensile npm extended-stable: YYYY.M.PATCH, con PATCH >= 33
  • Tag Git: vYYYY.M.PATCH
• Versione finale giornaliera/regolare: YYYY.M.PATCH, con PATCH < 33
  • Tag Git: vYYYY.M.PATCH
• Versione di correzione fallback regolare: YYYY.M.PATCH-N
  • Tag Git: vYYYY.M.PATCH-N
• Versione prerelease beta: YYYY.M.PATCH-beta.N
  • Tag Git: vYYYY.M.PATCH-beta.N
• Non aggiungere zeri iniziali a mese o patch
• A partire dall'aggiornamento del processo di rilascio di giugno 2026, il terzo componente e' un numero sequenziale mensile del release train, non un giorno di calendario. I rilasci stable e beta determinano il train corrente; i tag solo alpha non consumano ne' avanzano il numero di patch beta/stable. I tag e le versioni npm precedenti all'aggiornamento mantengono i loro nomi esistenti e restano validi; l'automazione di rilascio continua a confrontarli per anno, mese, patch, canale e numero di prerelease o correzione.
• Le build alpha/nightly usano il prossimo patch train non rilasciato e incrementano solo alpha.N per build ripetute. Quando quella patch ha una beta, le nuove build alpha passano alla patch successiva. Ignora i tag legacy solo alpha con numeri di patch piu' alti quando selezioni un train beta o stable.
• Le versioni npm sono immutabili. Se un tag beta e' gia' stato pubblicato, non eliminarlo, ripubblicarlo o riutilizzarlo; crea invece il numero beta successivo o la patch mensile successiva. Poiche' 2026.6.5-beta.1 e' gia' stato pubblicato durante la transizione, i release train di giugno 2026 devono usare la patch 5 o superiore. Non pubblicare nuovi train stable o beta di giugno 2026 come 2026.6.2, 2026.6.3 o 2026.6.4.
• Dopo la finale regolare 2026.6.5, il prossimo nuovo train beta e' 2026.6.6-beta.1, anche se esistono gia' tag automatizzati solo alpha con numeri di patch piu' alti.
• latest continua a seguire la linea npm regolare/giornaliera corrente
• beta indica la destinazione di installazione beta corrente
• extended-stable indica il pacchetto npm supportato del mese precedente, a partire dalla patch 33; la patch 34 e successive sono rilasci di manutenzione su quella linea mensile
• Il percorso mensile dedicato extended-stable pubblica solo il pacchetto core npm. Non pubblica plugin, artefatti macOS o Windows, una GitHub Release, dist-tag di repository privati, immagini Docker, artefatti mobile o download del sito web.

Cadenza dei rilasci

• I rilasci procedono prima in beta
• Stable segue solo dopo la validazione dell'ultima beta
• I maintainer normalmente creano i rilasci da un branch release/YYYY.M.PATCH creato dal main corrente, cosi' la validazione e le correzioni del rilascio non bloccano il nuovo sviluppo su main
• Se un tag beta e' stato inviato o pubblicato e richiede una correzione, i maintainer creano il tag -beta.N successivo invece di eliminare o ricreare il vecchio tag beta
• La procedura di rilascio dettagliata, approvazioni, credenziali e note di ripristino sono riservate ai maintainer

Pubblicazione mensile extended-stable solo npm

Questa e' un'eccezione dedicata alla procedura di rilascio regolare riportata sotto. Per un mese completato YYYY.M, crea extended-stable/YYYY.M.33; pubblica vYYYY.M.33 e le patch di manutenzione successive dallo stesso branch. Il tag di rilascio, la punta del branch, il checkout, la versione del pacchetto, il preflight npm e l'esecuzione di Full Release Validation devono identificare tutti lo stesso commit. Il main protetto deve gia' contenere una versione finale di un mese di calendario strettamente successivo sotto la patch 33; le patch di manutenzione restano idonee dopo che main avanza di piu' di un mese.

Esegui il preflight npm e Full Release Validation dal branch extended-stable esatto, poi salva entrambi gli ID delle esecuzioni:

gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=true \  -f npm_dist_tag=extended-stable gh workflow run full-release-validation.yml \  --ref extended-stable/YYYY.M.33 \  -f ref=extended-stable/YYYY.M.33 \  -f release_profile=stable

release_profile=stable e' il profilo esistente di profondita' della validazione; e' separato dal dist-tag npm extended-stable ed e' intenzionalmente invariato.

Dopo che entrambe le esecuzioni hanno successo e l'ambiente di rilascio npm e' pronto, promuovi il tarball esatto del preflight. La patch P deve essere 33 o superiore:

gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=false \  -f npm_dist_tag=extended-stable \  -f preflight_run_id=<npm-preflight-run-id> \  -f full_release_validation_run_id=<full-validation-run-id>

Per un fork o una prova non di produzione che intenzionalmente non puo' soddisfare la policy mensile .33 o del mese di main protetto, aggiungi -f bypass_extended_stable_guard=true sia ai dispatch di preflight npm sia a quelli di pubblicazione. Il valore predefinito e' false. Il bypass e' accettato solo con npm_dist_tag=extended-stable ed e' registrato nel riepilogo del workflow. Non bypassa il ref canonico del workflow extended-stable/YYYY.M.33, l'uguaglianza branch-tip/tag/checkout, la sintassi del tag finale, l'uguaglianza versione pacchetto/tag, l'identita' delle esecuzioni e del manifest referenziati, la provenienza del tarball, l'approvazione dell'ambiente, la rilettura del registry o le prove di riparazione del selettore.

Il workflow di pubblicazione verifica le identita' delle esecuzioni referenziate, il digest del tarball preparato ed entrambi i selettori del registry npm. Conferma indipendentemente il risultato dopo il successo del workflow:

npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

Entrambi i comandi devono restituire YYYY.M.P. Se la pubblicazione riesce ma la rilettura del selettore fallisce, non ripubblicare la versione immutabile del pacchetto. Usa il singolo comando di riparazione npm dist-tag add openclaw@YYYY.M.P extended-stable stampato nel riepilogo always-run del workflow fallito, poi ripeti entrambe le riletture indipendenti. Il rollback al selettore precedente e' una decisione operativa separata, non il percorso di riparazione della rilettura.

La checklist regolare sotto continua a gestire beta, latest, GitHub Release, plugin, macOS, Windows e altre pubblicazioni di piattaforma. Non eseguire questi passaggi per questo percorso extended-stable solo npm.

Checklist dell'operatore per il rilascio regolare

Questa checklist e' la forma pubblica del flusso di rilascio. Credenziali private, firma, notarizzazione, ripristino dei dist-tag e dettagli di rollback di emergenza restano nel runbook di rilascio riservato ai maintainer.

1. Parti dall'attuale main: esegui il pull dell'ultima versione, conferma che il commit di destinazione sia stato pushato e conferma che la CI attuale di main sia abbastanza verde da creare il branch da lì.
2. Genera la sezione superiore di CHANGELOG.md dalle PR mergiate e da tutti i commit diretti dall'ultimo tag di release raggiungibile. Mantieni le voci rivolte agli utenti, deduplica le voci sovrapposte tra PR e commit diretti, committa la riscrittura, pushala ed esegui ancora un rebase/pull prima di creare il branch.
3. Rivedi i record di compatibilità della release in src/plugins/compat/registry.ts e src/commands/doctor/shared/deprecation-compat.ts. Rimuovi la compatibilità scaduta solo quando il percorso di upgrade resta coperto, oppure registra perché viene mantenuta intenzionalmente.
4. Crea release/YYYY.M.PATCH dall'attuale main; non svolgere il normale lavoro di release direttamente su main.
5. Aggiorna ogni posizione di versione richiesta per il tag previsto, poi esegui pnpm release:prep. Aggiorna le versioni dei Plugin, l'inventario dei Plugin, lo schema di config, i metadati di config dei canali in bundle, il baseline della documentazione di config, gli export del plugin SDK e il baseline dell'API del plugin SDK nell'ordine corretto. Committa qualsiasi deriva generata prima del tagging. Poi esegui il preflight deterministico locale: pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build e pnpm release:check.
6. Esegui OpenClaw NPM Release con preflight_only=true. Prima che esista un tag, è consentito uno SHA completo di 40 caratteri del branch di release per il preflight di sola validazione. Il preflight genera evidenza di release delle dipendenze per il grafo esatto delle dipendenze in checkout e la archivia nell'artefatto di preflight npm. Salva il preflight_run_id riuscito.
7. Avvia tutti i test pre-release con Full Release Validation per il branch di release, il tag o lo SHA completo del commit. Questo è l'unico entrypoint manuale per le quattro grandi box di test della release: Vitest, Docker, QA Lab e Package.
8. Se la validazione fallisce, correggi sul branch di release e riesegui il più piccolo file, lane, job di workflow, profilo di package, provider o allowlist di modello fallito che dimostri la correzione. Riesegui l'umbrella completo solo quando la superficie modificata rende obsoleta l'evidenza precedente.
9. Per un candidato beta taggato, esegui pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N dal branch release/YYYY.M.PATCH corrispondente. Per stable, passa anche la release sorgente Windows richiesta: pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z. L'helper esegue i controlli locali della release generata, avvia o verifica la validazione completa della release e l'evidenza di preflight npm, esegue la prova fresh/update di Parallels contro il tarball preparato esatto più la prova del package Telegram, registra i piani npm dei Plugin e ClawHub, e stampa il comando esatto OpenClaw Release Publish solo dopo che il bundle di evidenze è verde. OpenClaw Release Publish invia i package dei Plugin selezionati o tutti quelli pubblicabili su npm e lo stesso insieme su ClawHub in parallelo, quindi promuove l'artefatto di preflight npm di OpenClaw preparato con il dist-tag corrispondente non appena la pubblicazione npm dei Plugin riesce. Dopo il successo del child di pubblicazione npm di OpenClaw, crea o aggiorna la pagina GitHub release/prerelease corrispondente dalla sezione completa corrispondente di CHANGELOG.md. Le release stable pubblicate su npm latest diventano la release GitHub latest; le release stable di manutenzione mantenute su npm beta vengono create con GitHub latest=false. Il workflow carica inoltre l'evidenza di dipendenza del preflight, il manifesto di validazione completa e l'evidenza di verifica del registry postpublish sulla release GitHub per la risposta agli incidenti post-release. Il workflow di pubblicazione stampa immediatamente gli ID delle run child, approva automaticamente i gate dell'ambiente di release che il token del workflow è autorizzato ad approvare, riassume i job child falliti con le code dei log, chiude la release GitHub e l'evidenza delle dipendenze non appena la pubblicazione npm di OpenClaw riesce, attende ClawHub ogni volta che OpenClaw npm viene pubblicato, poi esegue pnpm release:verify-beta e carica evidenza postpublish per la release GitHub, il package npm, i package npm dei Plugin selezionati, i package ClawHub selezionati, gli ID delle run dei workflow child e l'ID opzionale della run NPM Telegram. Il percorso ClawHub ritenta gli errori transitori di installazione delle dipendenze CLI, pubblica i Plugin che superano la preview anche quando una cella di preview è instabile, e termina con la verifica del registry per ogni versione attesa dei Plugin, così le pubblicazioni parziali restano visibili e ripetibili. Poi esegui l'accettazione package post-publish contro il package pubblicato openclaw@YYYY.M.PATCH-beta.N oppure openclaw@beta. Se una prerelease pushata o pubblicata richiede una correzione, crea il successivo numero di prerelease corrispondente; non eliminare né riscrivere la vecchia prerelease.
10. Per stable, continua solo dopo che la beta o il candidato di release verificato ha la necessaria evidenza di validazione. Anche la pubblicazione npm stable passa attraverso OpenClaw Release Publish, riusando l'artefatto di preflight riuscito tramite preflight_run_id; la prontezza della release macOS stable richiede anche i .zip, .dmg, .dSYM.zip pacchettizzati e appcast.xml aggiornato su main. Il workflow di pubblicazione macOS pubblica automaticamente l'appcast firmato su main pubblico dopo la verifica degli asset di release; se la protezione del branch blocca il push diretto, apre o aggiorna una PR appcast. La prontezza di Windows Hub stable richiede gli asset firmati OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe e OpenClawCompanion-SHA256SUMS.txt sulla release GitHub di OpenClaw. Passa il tag esatto della release firmata openclaw/openclaw-windows-node come windows_node_tag e la sua mappa di digest degli installer approvata dal candidato come windows_node_installer_digests; OpenClaw Release Publish mantiene la bozza di release, avvia Windows Node Release e verifica tutti e tre gli asset prima della pubblicazione.
11. Dopo la pubblicazione, esegui il verificatore npm post-publish, l'E2E Telegram pubblicato-npm standalone opzionale quando serve una prova di canale post-publish, la promozione dist-tag quando necessaria, verifica la pagina GitHub release generata, esegui i passaggi di annuncio della release, quindi completa Chiusura main stable prima di dichiarare conclusa una release stable.

Chiusura main stable

La pubblicazione stable non è completa finché main non contiene lo stato effettivo della release spedita.

1. Parti dall'ultimo main fresco. Esegui l'audit di release/YYYY.M.PATCH rispetto a esso e porta in avanti le correzioni reali assenti da main. Non mergiare alla cieca adattatori di compatibilità, test o validazione solo di release nel main più nuovo.
2. Imposta main alla versione stable spedita, non a un prossimo train speculativo. Esegui pnpm release:prep dopo la modifica della versione root, poi pnpm deps:shrinkwrap:generate.
3. Fai in modo che la sezione ## YYYY.M.PATCH di CHANGELOG.md su main corrisponda esattamente al branch di release taggato. Includi l'aggiornamento stable di appcast.xml quando la release mac lo ha pubblicato.
4. Non aggiungere YYYY.M.PATCH+1, una versione beta o una sezione changelog futura vuota a main finché l'operatore non avvia esplicitamente quel train di release.
5. Esegui pnpm release:generated:check, pnpm deps:shrinkwrap:check e OPENCLAW_TESTBOX=1 pnpm check:changed. Pusha, poi verifica che origin/main contenga la versione spedita e il changelog prima di dichiarare conclusa la release stable.
6. Mantieni aggiornate le variabili del repository RELEASE_ROLLBACK_DRILL_ID e RELEASE_ROLLBACK_DRILL_DATE dopo ogni drill di rollback privato. OpenClaw Stable Main Closeout parte dal push su main che contiene la versione spedita, il changelog e l'appcast dopo la pubblicazione stable. Legge evidenza postpublish immutabile per legare il tag spedito alle sue run di Full Release Validation e Publish, poi verifica lo stato stable di main, la release, il soak stable obbligatorio e l'evidenza bloccante di performance. Allega un manifesto di closeout immutabile e un checksum alla release GitHub. Il trigger automatico su push salta le release legacy precedenti all'evidenza postpublish immutabile; non tratta mai quel salto come un closeout completato. Un closeout completo richiede entrambi gli asset e un checksum corrispondente. Un manifesto parziale riesegue lo SHA main registrato e il drill di rollback per rigenerare byte identici, poi allega il checksum mancante; una coppia non valida, o un checksum senza manifesto, resta bloccante. Una run attivata da push senza variabili del repository per il drill di rollback viene saltata senza completare il closeout; un record di drill mancante o più vecchio di 90 giorni blocca comunque il closeout manuale supportato da evidenze. I comandi di recovery privati restano nel runbook riservato ai maintainer. Usa il dispatch manuale solo per riparare o rieseguire un closeout stable supportato da evidenze. Un tag di correzione fallback legacy può riusare l'evidenza del package base solo quando il tag di correzione risolve allo stesso commit sorgente del tag stable base. Una correzione con sorgente diverso deve pubblicare e verificare la propria evidenza di package.

Preflight della release

• Esegui pnpm check:test-types prima del preflight di rilascio, così il TypeScript dei test resta coperto al di fuori del gate locale più veloce pnpm check
• Esegui pnpm check:architecture prima del preflight di rilascio, così i controlli più ampi sui cicli di importazione e sui confini architetturali sono verdi al di fuori del gate locale più veloce
• Esegui pnpm build && pnpm ui:build prima di pnpm release:check, così gli artifact di rilascio dist/* previsti e il bundle della Control UI esistono per il passaggio di convalida del pack
• Esegui pnpm release:prep dopo l'incremento della versione root e prima del tagging. Esegue ogni generatore di rilascio deterministico che comunemente deriva dopo una modifica di versione/config/API: versioni dei plugin, inventario dei plugin, schema di config base, metadati di configurazione dei canali in bundle, baseline della documentazione di config, esportazioni dell'SDK dei plugin e baseline API dell'SDK dei plugin. pnpm release:check riesegue quelle guardie in modalità check e segnala in un unico passaggio ogni errore di drift generato che trova prima di eseguire i controlli di rilascio del pacchetto.
• La sincronizzazione delle versioni dei plugin aggiorna per impostazione predefinita le versioni dei pacchetti dei plugin ufficiali e i floor openclaw.compat.pluginApi esistenti alla versione di rilascio di OpenClaw. Tratta quel campo come il floor dell'API SDK/runtime del plugin, non solo come una copia della versione del pacchetto: per rilasci solo plugin che intenzionalmente restano compatibili con host OpenClaw più vecchi, mantieni il floor all'API host meno recente supportata e documenta tale scelta nella prova di rilascio del plugin.
• Esegui il workflow manuale Full Release Validation prima dell'approvazione del rilascio per avviare tutti i test box pre-rilascio da un unico entrypoint. Accetta un branch, tag o SHA completo di commit, dispatcha manualmente CI e dispatcha OpenClaw Release Checks per install smoke, accettazione pacchetto, controlli pacchetto cross-OS, parità QA Lab, Matrix e lane Telegram. Le esecuzioni stable e complete includono sempre live/E2E esaustivi e soak del percorso di rilascio Docker; run_release_soak=true è mantenuto per un soak beta esplicito. Package Acceptance fornisce l'E2E Telegram canonico del pacchetto durante la convalida del candidato, evitando un secondo poller live concorrente. Fornisci release_package_spec dopo la pubblicazione di una beta per riutilizzare il pacchetto npm distribuito tra controlli di rilascio, Package Acceptance ed E2E Telegram del pacchetto senza ricostruire il tarball di rilascio. Fornisci npm_telegram_package_spec solo quando Telegram deve usare un pacchetto pubblicato diverso dal resto della convalida di rilascio. Fornisci package_acceptance_package_spec quando Package Acceptance deve usare un pacchetto pubblicato diverso dalla specifica del pacchetto di rilascio. Fornisci evidence_package_spec quando il report delle evidenze di rilascio deve provare che la convalida corrisponde a un pacchetto npm pubblicato senza forzare l'E2E Telegram. Esempio: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.PATCH
• Esegui il workflow manuale Package Acceptance quando vuoi una prova side-channel per un candidato pacchetto mentre il lavoro di rilascio continua. Usa source=npm per openclaw@beta, openclaw@latest o una versione di rilascio esatta; source=ref per impacchettare un branch/tag/SHA package_ref attendibile con l'harness workflow_ref corrente; source=url per un tarball HTTPS pubblico con SHA-256 richiesto e policy rigorosa sugli URL pubblici; source=trusted-url per una policy di sorgente attendibile nominata usando trusted_source_id e SHA-256 obbligatori; oppure source=artifact per un tarball caricato da un'altra esecuzione di GitHub Actions. Il workflow risolve il candidato in package-under-test, riutilizza lo scheduler di rilascio Docker E2E contro quel tarball e può eseguire la QA Telegram contro lo stesso tarball con telegram_mode=mock-openai o telegram_mode=live-frontier. Quando le lane Docker selezionate includono published-upgrade-survivor, l'artifact del pacchetto è il candidato e published_upgrade_survivor_baseline seleziona la baseline pubblicata. update-restart-auth usa il pacchetto candidato come CLI installata e come package-under-test, così esercita il percorso di riavvio gestito del comando di aggiornamento del candidato. Esempio: 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 Profili comuni:
  • smoke: lane di installazione/canale/agent, rete Gateway e ricaricamento config
  • package: lane native dell'artifact per pacchetto/aggiornamento/riavvio/plugin senza OpenWebUI o ClawHub live
  • product: profilo package più canali MCP, pulizia cron/subagent, ricerca web OpenAI e OpenWebUI
  • full: chunk del percorso di rilascio Docker con OpenWebUI
  • custom: selezione esatta di docker_lanes per una riesecuzione mirata
• Esegui direttamente il workflow manuale CI quando ti serve solo copertura CI normale deterministica per il candidato di rilascio. I dispatch manuali della CI bypassano lo scoping basato sulle modifiche e forzano gli shard Linux Node, shard dei plugin in bundle, shard dei contratti di plugin e canali, compatibilità Node 22, check-*, check-additional-*, controlli smoke sugli artifact compilati, controlli docs, Skills Python, Windows, macOS e lane i18n della Control UI. Le esecuzioni CI manuali standalone eseguono Android solo quando dispatchate con include_android=true; Full Release Validation passa quell'input al suo child CI. Esempio con Android: gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true
• Esegui pnpm qa:otel:smoke quando convalidi la telemetria di rilascio. Esercita QA-lab tramite un receiver OTLP/HTTP locale e verifica l'esportazione di trace, metriche e log più attributi trace limitati e redazione di contenuti/identificatori senza richiedere Opik, Langfuse o un altro collector esterno.
• Esegui pnpm qa:otel:collector-smoke quando convalidi la compatibilità del collector. Instrada la stessa esportazione OTLP di QA-lab tramite un container Docker reale di OpenTelemetry Collector prima delle asserzioni del receiver locale.
• Esegui pnpm qa:prometheus:smoke quando convalidi lo scraping Prometheus protetto. Esercita QA-lab, rifiuta gli scrape non autenticati e verifica che le famiglie di metriche critiche per il rilascio restino prive di contenuto dei prompt, identificatori raw, token auth e percorsi locali.
• Esegui pnpm qa:observability:smoke quando vuoi le lane smoke OpenTelemetry e Prometheus del checkout sorgente in sequenza.
• Esegui pnpm release:check prima di ogni rilascio taggato
• Il preflight di OpenClaw NPM Release genera evidenze di rilascio delle dipendenze prima di impacchettare il tarball npm. Il gate sulle vulnerabilità degli advisory npm è bloccante per il rilascio. I report su rischio del manifesto transitivo, superficie di ownership/installazione delle dipendenze e modifiche delle dipendenze sono solo evidenze di rilascio. Il report delle modifiche delle dipendenze confronta il candidato di rilascio con il precedente tag di rilascio raggiungibile.
• Il preflight carica le evidenze delle dipendenze come openclaw-release-dependency-evidence-<tag> e le incorpora anche sotto dependency-evidence/ dentro l'artifact preflight npm preparato. Il percorso reale di pubblicazione riutilizza quell'artifact preflight, poi allega le stesse evidenze al rilascio GitHub come openclaw-<version>-dependency-evidence.zip.
• Esegui OpenClaw Release Publish per la sequenza mutante di pubblicazione dopo che il tag esiste. Dispatchalo da release/YYYY.M.PATCH (o main quando pubblichi un tag raggiungibile da main), passa il tag di rilascio, il preflight_run_id npm OpenClaw riuscito e il full_release_validation_run_id riuscito, e mantieni lo scope di pubblicazione plugin predefinito all-publishable salvo che tu stia deliberatamente eseguendo una riparazione mirata. Il workflow serializza pubblicazione npm dei plugin, pubblicazione ClawHub dei plugin e pubblicazione npm di OpenClaw, così il pacchetto core non viene pubblicato prima dei suoi plugin esternalizzati.
• OpenClaw Release Publish stable richiede un windows_node_tag esatto dopo l'esistenza del rilascio openclaw/openclaw-windows-node non prerelease corrispondente. Richiede inoltre la mappa windows_node_installer_digests approvata per il candidato. Prima di dispatchare qualsiasi child di pubblicazione, verifica che il rilascio sorgente sia pubblicato, non prerelease, contenga gli installer x64/ARM64 richiesti e corrisponda ancora a quella mappa approvata. Poi dispatcha Windows Node Release mentre il rilascio OpenClaw è ancora una bozza, portando invariata la mappa di digest degli installer fissata. Il workflow child scarica gli installer Windows Hub firmati da quel tag esatto, li confronta con i digest fissati, verifica su un runner Windows che le loro firme Authenticode usino il firmatario OpenClaw Foundation previsto, scrive un manifesto SHA-256 e carica gli installer più il manifesto sul rilascio GitHub canonico di OpenClaw, quindi riscarica gli asset promossi e verifica appartenenza al manifesto e hash. Il parent verifica il contratto asset corrente x64, ARM64 e checksum prima della pubblicazione. Il recupero diretto rifiuta nomi asset OpenClawCompanion-* inattesi prima di sostituire gli asset del contratto previsti con i byte sorgente fissati. Dispatcha manualmente Windows Node Release solo per recupero, e passa sempre un tag esatto, mai latest, più la mappa JSON esplicita expected_installer_digests dal rilascio sorgente approvato. I link di download del sito web dovrebbero puntare agli URL esatti degli asset di rilascio OpenClaw per il rilascio stable corrente, oppure releases/latest/download/... solo dopo aver verificato che il redirect latest di GitHub punti a quello stesso rilascio; non collegare solo alla pagina di rilascio del repo companion.
• I controlli di rilascio ora vengono eseguiti in un workflow manuale separato: OpenClaw Release Checks
• OpenClaw Release Checks esegue anche la lane di parità mock QA Lab più il profilo Matrix live veloce e la lane QA Telegram prima dell'approvazione del rilascio. Le lane live usano l'ambiente qa-live-shared; Telegram usa anche lease di credenziali CI Convex. Esegui il workflow manuale QA-Lab - All Lanes con matrix_profile=all e matrix_shards=true quando vuoi inventario completo Matrix su trasporto, media ed E2EE in parallelo.
• La convalida runtime di installazione e aggiornamento cross-OS fa parte dei workflow pubblici OpenClaw Release Checks e Full Release Validation, che chiamano direttamente il workflow riutilizzabile .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• Questa separazione è intenzionale: mantieni il percorso reale di rilascio npm breve, deterministico e focalizzato sugli artifact, mentre i controlli live più lenti restano nella loro lane così non rallentano né bloccano la pubblicazione
• I controlli di rilascio che portano segreti dovrebbero essere dispatchati tramite Full Release Validation o dal ref workflow main/release, così logica del workflow e segreti restano controllati
• OpenClaw Release Checks accetta un branch, tag o SHA completo di commit purché il commit risolto sia raggiungibile da un branch OpenClaw o da un tag di rilascio
• Anche il preflight solo convalida di OpenClaw NPM Release accetta l'attuale SHA completo di commit del branch workflow a 40 caratteri senza richiedere un tag pushato
• Quel percorso SHA è solo di convalida e non può essere promosso a una pubblicazione reale
• In modalità SHA il workflow sintetizza v<package.json version> solo per il controllo dei metadati del pacchetto; la pubblicazione reale richiede comunque un tag di rilascio reale
• Entrambi i workflow mantengono il percorso reale di pubblicazione e promozione su runner ospitati da GitHub, mentre il percorso di convalida non mutante può usare i runner Linux Blacksmith più grandi
• Quel workflow esegue OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache usando entrambi i segreti workflow OPENAI_API_KEY e ANTHROPIC_API_KEY
• Il preflight di rilascio npm non attende più la lane separata dei controlli di rilascio
• Prima di taggare localmente un candidato di rilascio, esegui RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check. L'helper esegue guardrail di rilascio veloci, controlli di rilascio npm/ClawHub dei plugin, build, build UI e release:openclaw:npm:check nell'ordine che intercetta errori comuni che bloccano l'approvazione prima dell'avvio del workflow di pubblicazione GitHub.
• Esegui RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (o il tag beta/correzione corrispondente) prima dell'approvazione
• Dopo la pubblicazione npm, esegui node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (o la versione beta/correzione corrispondente) per verificare il percorso di installazione del registry pubblicato in un nuovo prefisso temporaneo
• Dopo una pubblicazione beta, esegui OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live per verificare l'onboarding del pacchetto installato, la configurazione di Telegram e l'E2E reale di Telegram rispetto al pacchetto npm pubblicato usando il pool condiviso di credenziali Telegram noleggiate. Le esecuzioni locali una tantum dei maintainer possono omettere le variabili Convex e passare direttamente le tre credenziali env OPENCLAW_QA_TELEGRAM_*.
• Per eseguire lo smoke beta completo post-pubblicazione da una macchina maintainer, usa pnpm release:beta-smoke -- --beta betaN. L'helper esegue la validazione Parallels di aggiornamento npm/target nuovo, invia NPM Telegram Beta E2E, esegue il polling dell'esecuzione workflow esatta, scarica l'artefatto e stampa il report Telegram.
• I maintainer possono eseguire lo stesso controllo post-pubblicazione da GitHub Actions tramite il workflow manuale NPM Telegram Beta E2E. È intenzionalmente solo manuale e non viene eseguito a ogni merge.
• L'automazione di release dei maintainer ora usa preflight-poi-promozione:
  • la pubblicazione npm reale deve superare un preflight_run_id npm riuscito
  • la pubblicazione npm reale deve essere inviata dallo stesso branch main o release/YYYY.M.PATCH dell'esecuzione preflight riuscita
  • le release npm stabili hanno come valore predefinito beta
  • la pubblicazione npm stabile può puntare esplicitamente a latest tramite input del workflow
  • la mutazione npm dist-tag basata su token ora risiede in openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml perché npm dist-tag add richiede ancora NPM_TOKEN mentre il repo sorgente mantiene la pubblicazione solo OIDC
  • macOS Release pubblico è solo di validazione; quando un tag esiste solo su un branch di release ma il workflow viene inviato da main, imposta public_release_branch=release/YYYY.M.PATCH
  • la pubblicazione macOS reale deve superare preflight_run_id e validate_run_id macOS riusciti
  • i percorsi di pubblicazione reale promuovono gli artefatti preparati invece di ricostruirli di nuovo
• Per le release stabili di correzione come YYYY.M.PATCH-N, il verificatore post-pubblicazione controlla anche lo stesso percorso di aggiornamento con prefisso temporaneo da YYYY.M.PATCH a YYYY.M.PATCH-N così le correzioni di release non possono lasciare silenziosamente le installazioni globali più vecchie sul payload stabile di base
• Il preflight della release npm fallisce in modo chiuso a meno che il tarball includa sia dist/control-ui/index.html sia un payload dist/control-ui/assets/ non vuoto così non spediamo di nuovo una dashboard browser vuota
• La verifica post-pubblicazione controlla anche che gli entrypoint dei Plugin pubblicati e i metadati del pacchetto siano presenti nel layout del registry installato. Una release che spedisce payload runtime dei Plugin mancanti fallisce il verificatore postpublish e non può essere promossa a latest.
• pnpm test:install:smoke applica anche il budget npm pack unpackedSize sul tarball candidato di aggiornamento, così l'e2e dell'installer intercetta aumenti accidentali delle dimensioni del pacchetto prima del percorso di pubblicazione della release
• Se il lavoro di release ha toccato la pianificazione CI, i manifest di temporizzazione delle estensioni o le matrici di test delle estensioni, rigenera e rivedi gli output della matrice plugin-prerelease-extension-shard di proprietà del planner da .github/workflows/plugin-prerelease.yml prima dell'approvazione, così le note di release non descrivono un layout CI obsoleto
• La prontezza della release macOS stabile include anche le superfici dell'updater:
  • la release GitHub deve finire con i pacchetti .zip, .dmg e .dSYM.zip
  • appcast.xml su main deve puntare al nuovo zip stabile dopo la pubblicazione; il workflow di pubblicazione macOS lo committa automaticamente, oppure apre una PR appcast quando il push diretto è bloccato
  • l'app pacchettizzata deve mantenere un bundle id non di debug, un URL feed Sparkle non vuoto e un CFBundleVersion pari o superiore al floor canonico della build Sparkle per quella versione di release

Ambienti di test di rilascio

Full Release Validation è il modo in cui gli operatori avviano tutti i test pre-rilascio da un unico punto di ingresso. Per una prova di commit fissato su un branch in rapido movimento, usa l'helper così ogni workflow figlio viene eseguito da un branch temporaneo fissato allo SHA di destinazione:

pnpm ci:full-release --sha <full-sha>

L'helper esegue il push di release-ci/<sha>-..., avvia Full Release Validation da quel branch con ref=<sha>, verifica che ogni headSha dei workflow figli corrisponda alla destinazione, quindi elimina il branch temporaneo. Questo evita di provare per errore un'esecuzione figlia più recente di main.

Per la validazione di un branch o tag di rilascio, eseguila dal riferimento workflow main attendibile e passa il branch o tag di rilascio come ref:

gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=stable \  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N

Il workflow risolve il riferimento di destinazione, avvia manualmente CI con target_ref=<release-ref>, quindi avvia OpenClaw Release Checks. OpenClaw Release Checks distribuisce install smoke, controlli di rilascio cross-OS, copertura live/E2E del percorso di rilascio Docker quando il soak è abilitato, Package Acceptance con l'E2E canonico del pacchetto Telegram, parità QA Lab, Matrix live e Telegram live. Un'esecuzione completa/all è accettabile solo quando il riepilogo di Full Release Validation mostra normal_ci, plugin_prerelease e release_checks come riusciti, a meno che una riesecuzione mirata non abbia intenzionalmente saltato il figlio separato Plugin Prerelease. Usa il figlio autonomo npm-telegram solo per una riesecuzione mirata del pacchetto pubblicato con release_package_spec o npm_telegram_package_spec. Il riepilogo finale del verificatore include tabelle dei job più lenti per ogni esecuzione figlia, così il release manager può vedere il percorso critico corrente senza scaricare i log. Consulta Validazione completa del rilascio per la matrice completa delle fasi, i nomi esatti dei job workflow, le differenze tra profilo stable e full, gli artefatti e gli handle per le riesecuzioni mirate. I workflow figli vengono avviati dal riferimento attendibile che esegue Full Release Validation, normalmente --ref main, anche quando il ref di destinazione punta a un branch o tag di rilascio precedente. Non esiste un input separato per il riferimento workflow di Full Release Validation; scegli l'harness attendibile scegliendo il riferimento dell'esecuzione workflow. Non usare --ref main -f ref=<sha> per una prova esatta di commit su main in movimento; gli SHA di commit grezzi non possono essere riferimenti di workflow dispatch, quindi usa pnpm ci:full-release --sha <sha> per creare il branch temporaneo fissato.

Usa release_profile per selezionare l'ampiezza live/provider:

• minimum: percorso OpenAI/core live e Docker più rapido e critico per il rilascio
• stable: minimum più copertura stabile di provider/backend per l'approvazione del rilascio
• full: stable più ampia copertura consultiva di provider/media

La validazione stable e full esegue sempre l'esaustivo sweep live/E2E, del percorso di rilascio Docker e dei survivor di upgrade pubblicati e delimitati prima della promozione. Usa run_release_soak=true per richiedere lo stesso sweep per una beta. Quello sweep copre gli ultimi quattro pacchetti stable più le baseline fissate 2026.4.23 e 2026.5.2 più la copertura precedente 2026.4.15, con le baseline duplicate rimosse e ogni baseline suddivisa nel proprio job runner Docker.

OpenClaw Release Checks usa il riferimento workflow attendibile per risolvere una volta il riferimento di destinazione come release-package-under-test e riutilizza quell'artefatto nei controlli cross-OS, Package Acceptance e Docker del percorso di rilascio quando il soak viene eseguito. Questo mantiene tutti gli ambienti orientati al pacchetto sugli stessi byte ed evita build ripetute del pacchetto. Dopo che una beta è già su npm, imposta release_package_spec=openclaw@YYYY.M.PATCH-beta.N così i controlli di rilascio scaricano una volta il pacchetto distribuito, estraggono il suo SHA sorgente di build da dist/build-info.json e riutilizzano quell'artefatto per cross-OS, Package Acceptance, Docker del percorso di rilascio e lane Telegram del pacchetto. L'install smoke OpenAI cross-OS usa OPENCLAW_CROSS_OS_OPENAI_MODEL quando la variabile repo/org è impostata, altrimenti openai/gpt-5.4, perché questa lane sta provando l'installazione del pacchetto, l'onboarding, l'avvio del gateway e un turno agente live anziché misurare il modello predefinito più lento. La matrice più ampia dei provider live rimane il luogo per la copertura specifica per modello.

Usa queste varianti a seconda della fase di rilascio:

# Validate an unpublished release candidate branch.gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -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.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=full \  -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \  -f npm_telegram_provider_mode=mock-openai

Non usare l'ombrello completo come prima riesecuzione dopo una correzione mirata. Se un ambiente fallisce, usa il workflow figlio, il job, la lane Docker, il profilo pacchetto, il provider di modello o la lane QA falliti per la prova successiva. Esegui di nuovo l'ombrello completo solo quando la correzione ha modificato l'orchestrazione di rilascio condivisa o ha reso obsolete le prove precedenti di tutti gli ambienti. Il verificatore finale dell'ombrello ricontrolla gli ID registrati delle esecuzioni workflow figlie, quindi dopo che un workflow figlio è stato rieseguito con successo, riesegui solo il job padre Verify full validation fallito.

Per un recupero delimitato, passa rerun_group all'ombrello. all è la vera esecuzione del release candidate, ci esegue solo il figlio CI normale, plugin-prerelease esegue solo il figlio Plugin di solo rilascio, release-checks esegue ogni ambiente di rilascio e i gruppi di rilascio più ristretti sono install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live e npm-telegram. Le riesecuzioni mirate npm-telegram richiedono release_package_spec o npm_telegram_package_spec; le esecuzioni full/all usano l'E2E Telegram del pacchetto canonico dentro Package Acceptance. Le riesecuzioni mirate cross-OS possono aggiungere cross_os_suite_filter=windows/packaged-upgrade o un altro filtro OS/suite. I fallimenti QA release-check bloccano la normale validazione del rilascio, incluso il drift richiesto degli strumenti dinamici OpenClaw nel livello standard. Le esecuzioni alpha Tideclaw possono ancora trattare le lane release-check non legate alla sicurezza del pacchetto come consultive. Quando live_suite_filter richiede esplicitamente una lane QA live protetta come Discord, WhatsApp o Slack, la variabile repo corrispondente OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED deve essere abilitata; altrimenti la cattura degli input fallisce invece di saltare silenziosamente la lane.

Vitest

L'ambiente Vitest è il workflow figlio manuale CI. La CI manuale bypassa intenzionalmente lo scoping basato sulle modifiche e forza il grafo di test normale per il release candidate: shard Linux Node, shard dei Plugin in bundle, shard dei contratti di Plugin e canali, compatibilità Node 22, check-*, check-additional-*, controlli smoke sugli artefatti buildati, controlli docs, Skills Python, Windows, macOS e i18n della Control UI. Android è incluso quando Full Release Validation esegue l'ambiente perché l'ombrello passa include_android=true; la CI manuale autonoma richiede include_android=true per la copertura Android.

Usa questo ambiente per rispondere a "l'albero sorgente ha superato l'intera suite di test normale?" Non è la stessa cosa della validazione prodotto del percorso di rilascio. Prove da conservare:

• riepilogo Full Release Validation che mostra l'URL dell'esecuzione CI avviata
• esecuzione CI verde sullo SHA di destinazione esatto
• nomi degli shard falliti o lenti dai job CI quando si indagano regressioni
• artefatti di tempistica Vitest come .artifacts/vitest-shard-timings.json quando un'esecuzione richiede analisi delle prestazioni

Esegui direttamente la CI manuale solo quando il rilascio richiede CI normale deterministica ma non gli ambienti Docker, QA Lab, live, cross-OS o package. Usa il primo comando per la CI diretta non Android. Aggiungi include_android=true quando la CI diretta del release candidate deve coprire Android:

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCHgh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH -f include_android=true

Docker

L'ambiente Docker vive in OpenClaw Release Checks tramite openclaw-live-and-e2e-checks-reusable.yml, più il workflow install-smoke in modalità rilascio. Valida il release candidate tramite ambienti Docker pacchettizzati invece che solo test a livello sorgente.

La copertura Docker di rilascio include:

• install smoke completo con lo smoke dell'installazione globale Bun lenta abilitato
• preparazione/riutilizzo dell'immagine smoke Dockerfile root per SHA di destinazione, con job smoke QR, root/gateway e installer/Bun eseguiti come shard install-smoke separati
• lane E2E del repository
• chunk Docker del percorso di rilascio: 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 e plugins-runtime-install-h
• copertura OpenWebUI dentro il chunk plugins-runtime-services quando richiesta
• lane divise di installazione/disinstallazione dei Plugin in bundle da bundled-plugin-install-uninstall-0 a bundled-plugin-install-uninstall-23
• suite provider live/E2E e copertura modello live Docker quando i controlli di rilascio includono suite live

Usa gli artefatti Docker prima di rieseguire. Lo scheduler del percorso di rilascio carica .artifacts/docker-tests/ con log delle lane, summary.json, failures.json, tempistiche delle fasi, JSON del piano dello scheduler e comandi di riesecuzione. Per il recupero mirato, usa docker_lanes=<lane[,lane]> sul workflow live/E2E riutilizzabile invece di rieseguire tutti i chunk di rilascio. I comandi di riesecuzione generati includono il precedente package_artifact_run_id e gli input dell'immagine Docker preparata quando disponibili, così una lane fallita può riutilizzare lo stesso tarball e le stesse immagini GHCR.

QA Lab

L'ambiente QA Lab fa anch'esso parte di OpenClaw Release Checks. È il gate di rilascio del comportamento agentico e a livello di canale, separato da Vitest e dai meccanismi del pacchetto Docker.

La copertura QA Lab di rilascio include:

• lane di parità mock che confronta la lane candidata OpenAI con la baseline Opus 4.6 usando il pacchetto di parità agentica
• profilo QA Matrix live rapido usando l'ambiente qa-live-shared
• lane QA Telegram live usando lease di credenziali CI Convex
• pnpm qa:otel:smoke, pnpm qa:otel:collector-smoke, pnpm qa:prometheus:smoke o pnpm qa:observability:smoke quando la telemetria del rilascio richiede una prova locale esplicita

Usa questo ambiente per rispondere a "il rilascio si comporta correttamente negli scenari QA e nei flussi dei canali live?" Conserva gli URL degli artefatti per le lane parità, Matrix e Telegram quando approvi il rilascio. La copertura Matrix completa rimane disponibile come esecuzione QA-Lab sharded manuale invece che come lane predefinita critica per il rilascio.

Package

L'ambiente Package è il gate del prodotto installabile. È supportato da Package Acceptance e dal resolver scripts/resolve-openclaw-package-candidate.mjs. Il resolver normalizza un candidato nel tarball package-under-test consumato da Docker E2E, valida l'inventario del pacchetto, registra la versione del pacchetto e SHA-256, e mantiene il riferimento dell'harness workflow separato dal riferimento sorgente del pacchetto.

Sorgenti candidate supportate:

• source=npm: openclaw@beta, openclaw@latest oppure una versione esatta di una release OpenClaw
• source=ref: impacchetta un branch, tag o SHA commit completo package_ref attendibile con l'harness workflow_ref selezionato
• source=url: scarica un .tgz HTTPS pubblico con package_sha256 obbligatorio; credenziali URL, porte HTTPS non predefinite, nomi host o indirizzi risolti privati/interni/a uso speciale e reindirizzamenti non sicuri vengono rifiutati
• source=trusted-url: scarica un .tgz HTTPS con package_sha256 e trusted_source_id obbligatori da una policy denominata in .github/package-trusted-sources.json; usalo per mirror enterprise di proprietà dei maintainer o repository di pacchetti privati invece di aggiungere a source=url un bypass della rete privata a livello di input
• source=artifact: riusa un .tgz caricato da un'altra esecuzione di GitHub Actions

OpenClaw Release Checks esegue Package Acceptance con source=artifact, l'artefatto del pacchetto di release preparato, 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. Package Acceptance mantiene la migrazione, l'aggiornamento, il riavvio dell'aggiornamento con autenticazione configurata, l'installazione live di Skills ClawHub, la pulizia delle dipendenze obsolete dei Plugin, i fixture dei Plugin offline, l'aggiornamento dei Plugin e la QA del pacchetto Telegram rispetto allo stesso tarball risolto. I controlli di release bloccanti usano la baseline predefinita dell'ultimo pacchetto pubblicato; il profilo beta con run_release_soak=true, release_profile=stable o release_profile=full si espande a ogni baseline stabile pubblicata su npm da 2026.4.23 fino a latest, più i fixture dei problemi segnalati. Usa Package Acceptance con source=npm per un candidato già distribuito, source=ref per un tarball npm locale basato su SHA prima della pubblicazione, source=trusted-url per un mirror enterprise/privato di proprietà dei maintainer, oppure source=artifact per un tarball preparato caricato da un'altra esecuzione di GitHub Actions. È il sostituto nativo di GitHub per la maggior parte della copertura pacchetto/aggiornamento che in precedenza richiedeva Parallels. I controlli di release cross-OS restano importanti per onboarding, installer e comportamento della piattaforma specifici del sistema operativo, ma la validazione prodotto di pacchetto/aggiornamento dovrebbe preferire Package Acceptance.

La checklist canonica per la validazione di aggiornamenti e Plugin è Testing updates and plugins. Usala quando decidi quale lane locale, Docker, Package Acceptance o di controllo release dimostra una modifica di installazione/aggiornamento Plugin, pulizia doctor o migrazione del pacchetto pubblicato. La migrazione esaustiva degli aggiornamenti pubblicati da ogni pacchetto stabile 2026.4.23+ è un workflow manuale Update Migration separato, non parte di Full Release CI.

La tolleranza legacy di package-acceptance è intenzionalmente limitata nel tempo. I pacchetti fino a 2026.4.25 possono usare il percorso di compatibilità per lacune nei metadati già pubblicate su npm: voci dell'inventario QA privato mancanti dal tarball, gateway install --wrapper mancante, file di patch mancanti nel fixture git derivato dal tarball, update.channel persistito mancante, posizioni legacy dei record di installazione dei Plugin, persistenza mancante dei record di installazione del marketplace e migrazione dei metadati di configurazione durante plugins update. Il pacchetto 2026.4.26 pubblicato può emettere avvisi per file locali di marcatura dei metadati di build che erano già stati distribuiti. I pacchetti successivi devono soddisfare i contratti moderni dei pacchetti; quelle stesse lacune fanno fallire la validazione di release.

Usa profili Package Acceptance più ampi quando la domanda sulla release riguarda un pacchetto effettivamente installabile:

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

Profili di pacchetto comuni:

• smoke: lane rapide per installazione pacchetto/canale/agente, rete Gateway e ricaricamento configurazione
• package: contratti di pacchetto per installazione/aggiornamento/riavvio/Plugin più prova di installazione live di Skills ClawHub; è il valore predefinito dei controlli di release
• product: package più canali MCP, pulizia cron/subagente, ricerca web OpenAI e OpenWebUI
• full: blocchi del percorso di release Docker con OpenWebUI
• custom: elenco esatto docker_lanes per riesecuzioni mirate

Per la prova Telegram di un pacchetto candidato, abilita telegram_mode=mock-openai oppure telegram_mode=live-frontier su Package Acceptance. Il workflow passa il tarball package-under-test risolto nella lane Telegram; il workflow Telegram autonomo accetta comunque una specifica npm pubblicata per i controlli post-pubblicazione.

Automazione di pubblicazione delle release regolari

Per beta, latest, Plugin, GitHub Release e pubblicazione su piattaforme, OpenClaw Release Publish è il normale entrypoint mutante. Il percorso monthly .33+ npm-only extended-stable non usa questo orchestratore. Il workflow regolare orchestra i workflow trusted-publisher nell'ordine richiesto dalla release:

1. Esegui il checkout del tag di release e risolvi il suo SHA commit.
2. Verifica che il tag sia raggiungibile da main o release/*.
3. Esegui pnpm plugins:sync:check.
4. Esegui il dispatch di Plugin NPM Release con publish_scope=all-publishable e ref=<release-sha>.
5. Esegui il dispatch di Plugin ClawHub Release con lo stesso scope e SHA.
6. Esegui il dispatch di OpenClaw NPM Release con il tag di release, il dist-tag npm e il preflight_run_id salvato dopo aver verificato il full_release_validation_run_id salvato.
7. Per le release stabili, crea o aggiorna la release GitHub come bozza, esegui il dispatch di Windows Node Release con il windows_node_tag esplicito e windows_node_installer_digests approvati per il candidato, quindi verifica gli asset canonici dell'installer/checksum prima di pubblicare la bozza.

Esempio di pubblicazione beta:

gh workflow run openclaw-release-publish.yml \  --ref release/YYYY.M.PATCH \  -f tag=vYYYY.M.PATCH-beta.N \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f npm_dist_tag=beta

Pubblicazione stabile al dist-tag beta predefinito:

gh workflow run openclaw-release-publish.yml \  --ref release/YYYY.M.PATCH \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f npm_dist_tag=beta

La promozione stabile direttamente a latest è esplicita:

gh workflow run openclaw-release-publish.yml \  --ref release/YYYY.M.PATCH \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f npm_dist_tag=latest

Usa i workflow di livello inferiore Plugin NPM Release e Plugin ClawHub Release solo per riparazioni o ripubblicazioni mirate. OpenClaw Release Publish rifiuta plugin_publish_scope=selected quando publish_openclaw_npm=true, così il pacchetto core non può essere distribuito senza ogni Plugin ufficiale pubblicabile, incluso @openclaw/diffs-language-pack. Per una riparazione di Plugin selezionato, imposta publish_openclaw_npm=false con plugin_publish_scope=selected e plugins=@openclaw/name, oppure esegui direttamente il dispatch del workflow figlio.

Input del workflow NPM

OpenClaw NPM Release accetta questi input controllati dall'operatore:

• tag: tag di release obbligatorio come v2026.4.2, v2026.4.2-1 o v2026.4.2-beta.1; quando preflight_only=true, può essere anche lo SHA commit completo di 40 caratteri corrente del branch del workflow per preflight di sola validazione
• preflight_only: true solo per validazione/build/pacchetto, false per il percorso di pubblicazione reale
• preflight_run_id: obbligatorio nel percorso di pubblicazione reale, così il workflow riusa il tarball preparato dall'esecuzione preflight riuscita
• full_release_validation_run_id: obbligatorio per pubblicazione reale monthly extended-stable e regolare non beta, così il workflow autentica l'esecuzione di validazione esatta
• npm_dist_tag: tag npm di destinazione per il percorso di pubblicazione; accetta alpha, beta, latest o extended-stable e il valore predefinito è beta. La patch finale 33 e successive devono usare extended-stable; per impostazione predefinita, extended-stable rifiuta patch precedenti e rifiuta sempre tag non finali.
• bypass_extended_stable_guard: booleano solo per test, predefinito false; con npm_dist_tag=extended-stable, bypassa l'idoneità monthly extended-stable preservando identità di release, artefatto, approvazione e controlli di rilettura.

OpenClaw Release Publish accetta questi input controllati dall'operatore:

• tag: tag di release obbligatorio; deve già esistere
• preflight_run_id: id dell'esecuzione preflight riuscita di OpenClaw NPM Release; obbligatorio quando publish_openclaw_npm=true
• full_release_validation_run_id: id dell'esecuzione riuscita di Full Release Validation; obbligatorio quando publish_openclaw_npm=true
• windows_node_tag: tag di release esatto non prerelease di openclaw/openclaw-windows-node; obbligatorio per la pubblicazione stabile di OpenClaw
• windows_node_installer_digests: mappa JSON compatta, approvata per il candidato, dei nomi correnti degli installer Windows ai rispettivi digest sha256: bloccati; obbligatoria per la pubblicazione stabile di OpenClaw
• npm_dist_tag: tag npm di destinazione per il pacchetto OpenClaw
• plugin_publish_scope: valore predefinito all-publishable; usa selected solo per lavori mirati di riparazione solo Plugin con publish_openclaw_npm=false
• plugins: nomi di pacchetti @openclaw/* separati da virgole quando plugin_publish_scope=selected
• publish_openclaw_npm: valore predefinito true; imposta false solo quando usi il workflow come orchestratore di riparazione solo Plugin
• wait_for_clawhub: valore predefinito false, così la disponibilità npm non viene bloccata dal sidecar ClawHub; imposta true solo quando il completamento del workflow deve includere il completamento di ClawHub

OpenClaw Release Checks accetta questi input controllati dall'operatore:

• ref: branch, tag o SHA commit completo da validare. I controlli che usano segreti richiedono che il commit risolto sia raggiungibile da un branch OpenClaw o da un tag di release.
• run_release_soak: abilita soak esaustivo live/E2E, percorso di release Docker e all-since upgrade-survivor per i controlli di release beta. Viene forzato da release_profile=stable e release_profile=full.

Regole:

• Le versioni finali regolari e di correzione sotto la patch 33 possono pubblicare su beta o latest. Le versioni finali alla patch 33 o superiore devono pubblicare su extended-stable, e le versioni con suffisso di correzione a quella soglia vengono rifiutate.
• I tag prerelease beta possono pubblicare solo su beta
• Per OpenClaw NPM Release, l'input SHA commit completo è consentito solo quando preflight_only=true
• OpenClaw Release Checks e Full Release Validation sono sempre solo validazione
• Il percorso di pubblicazione reale deve usare lo stesso npm_dist_tag usato durante il preflight; il workflow verifica che i metadati prima della pubblicazione continuino a corrispondere

Sequenza di release stabile regolare beta/latest

Questa sequenza legacy è per la release regolare orchestrata che possiede anche Plugin, GitHub Release, Windows e altro lavoro di piattaforma. Non è il percorso monthly .33+ npm-only extended-stable documentato all'inizio di questa pagina.

Quando si prepara una release stabile regolare orchestrata:

1. Esegui OpenClaw NPM Release con preflight_only=true
   • Prima che esista un tag, puoi usare lo SHA del commit completo corrente del branch del workflow per una prova a secco solo di convalida del workflow di preflight
2. Scegli npm_dist_tag=beta per il normale flusso beta-first, oppure latest solo quando vuoi intenzionalmente una pubblicazione stabile diretta
3. Esegui Full Release Validation sul branch di rilascio, sul tag di rilascio o sullo SHA completo del commit quando vuoi la normale CI più copertura live per prompt cache, Docker, QA Lab, Matrix e Telegram da un unico workflow manuale
4. Se intenzionalmente ti serve solo il grafo di test normale deterministico, esegui invece il workflow manuale CI sul ref di rilascio
5. Seleziona l'esatto tag di rilascio non prerelease openclaw/openclaw-windows-node i cui installer firmati x64 e ARM64 devono essere distribuiti. Salvalo come windows_node_tag e salva la loro mappa di digest convalidata come windows_node_installer_digests. L'helper della release candidate registra entrambi e li include nel comando di pubblicazione generato.
6. Salva i preflight_run_id e full_release_validation_run_id riusciti
7. Esegui OpenClaw Release Publish con lo stesso tag, lo stesso npm_dist_tag, il windows_node_tag selezionato, i relativi windows_node_installer_digests salvati, il preflight_run_id salvato e il full_release_validation_run_id salvato; pubblica i plugin esternalizzati su npm e ClawHub prima di promuovere il pacchetto npm OpenClaw
8. Se il rilascio è arrivato su beta, usa il workflow openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml per promuovere quella versione stabile da beta a latest
9. Se il rilascio ha pubblicato intenzionalmente direttamente su latest e beta deve seguire subito la stessa build stabile, usa lo stesso workflow di rilascio per puntare entrambi i dist-tag alla versione stabile, oppure lascia che la sua sincronizzazione pianificata di autoriparazione sposti beta in seguito

La mutazione dei dist-tag vive nel repository del registro di rilascio perché richiede ancora NPM_TOKEN, mentre il repository sorgente mantiene la pubblicazione solo tramite OIDC.

Questo mantiene documentati e visibili agli operatori sia il percorso di pubblicazione diretta sia il percorso di promozione beta-first.

Se un maintainer deve ricorrere all'autenticazione npm locale, esegui qualsiasi comando della CLI (op) di 1Password solo all'interno di una sessione tmux dedicata. Non chiamare op direttamente dalla shell principale dell'agente; mantenerlo dentro tmux rende prompt, avvisi e gestione OTP osservabili e impedisce avvisi host ripetuti.

Riferimenti pubblici

• .github/workflows/full-release-validation.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-npm-release.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• scripts/resolve-openclaw-package-candidate.mjs
• scripts/openclaw-npm-release-check.ts
• scripts/package-mac-dist.sh
• scripts/make_appcast.sh

I maintainer usano la documentazione privata di rilascio in openclaw/maintainers/release/README.md per il runbook effettivo.

Correlati

• Canali di rilascio