Politique de publication

OpenClaw expose actuellement trois canaux de mise à jour destinés aux utilisateurs :

• stable : le canal de publication promue existant, qui se résout encore via npm latest jusqu’à l’arrivée du jalon CLI/canal séparé
• beta : balises de prépublication publiées sur npm beta
• dev : la tête mouvante de main

Séparément, les opérateurs de publication peuvent publier le package principal du mois terminé précédent sur npm extended-stable, à partir du patch 33. La ligne finale régulière du mois courant continue sur npm latest ; cette séparation de publication côté opérateur ne modifie pas à elle seule la résolution des canaux de mise à jour de la CLI.

Nommage des versions

• Version de publication mensuelle npm extended-stable : YYYY.M.PATCH, avec PATCH >= 33
  • Balise Git : vYYYY.M.PATCH
• Version de publication finale quotidienne/régulière : YYYY.M.PATCH, avec PATCH < 33
  • Balise Git : vYYYY.M.PATCH
• Version de publication corrective de repli régulière : YYYY.M.PATCH-N
  • Balise Git : vYYYY.M.PATCH-N
• Version de prépublication beta : YYYY.M.PATCH-beta.N
  • Balise Git : vYYYY.M.PATCH-beta.N
• Ne pas ajouter de zéro initial au mois ni au patch
• À partir de la mise à jour du processus de publication de juin 2026, le troisième composant est un numéro séquentiel mensuel de train de publication, et non un jour calendaire. Les publications stable et beta déterminent le train courant ; les balises alpha seules ne consomment pas et ne font pas avancer le numéro de patch beta/stable. Les balises et versions npm antérieures à la mise à jour conservent leurs noms existants et restent valides ; l’automatisation de publication continue de les comparer par année, mois, patch, canal, et numéro de prépublication ou de correction.
• Les builds alpha/nightly utilisent le prochain train de patch non publié et incrémentent uniquement alpha.N pour les builds répétés. Dès que ce patch a une beta, les nouveaux builds alpha passent au patch suivant. Ignorer les anciennes balises alpha seules avec des numéros de patch plus élevés lors de la sélection d’un train beta ou stable.
• Les versions npm sont immuables. Si une balise beta a déjà été publiée, ne pas la supprimer, la republier ni la réutiliser ; créer le numéro beta suivant ou le patch mensuel suivant à la place. Comme 2026.6.5-beta.1 a déjà été publié pendant la transition, les trains de publication de juin 2026 doivent utiliser le patch 5 ou supérieur. Ne pas publier de nouveaux trains stable ou beta de juin 2026 sous 2026.6.2, 2026.6.3 ou 2026.6.4.
• Après la finale régulière 2026.6.5, le prochain nouveau train beta est 2026.6.6-beta.1, même si des balises automatisées alpha seules avec des numéros de patch plus élevés existent déjà.
• latest continue de suivre la ligne npm régulière/quotidienne courante
• beta désigne la cible d’installation beta courante
• extended-stable désigne le package npm du mois précédent pris en charge, à partir du patch 33 ; le patch 34 et les suivants sont des publications de maintenance sur cette ligne mensuelle
• Le chemin mensuel dédié extended-stable ne publie que le package npm principal. Il ne publie pas de plugins, d’artifacts macOS ou Windows, de GitHub Release, de dist-tags de dépôt privé, d’images Docker, d’artifacts mobiles ni de téléchargements de site web.

Cadence de publication

• Les publications passent d’abord par beta
• Stable suit seulement après validation de la dernière beta
• Les mainteneurs créent normalement les publications depuis une branche release/YYYY.M.PATCH créée à partir du main courant, afin que la validation de publication et les correctifs ne bloquent pas le nouveau développement sur main
• Si une balise beta a été poussée ou publiée et nécessite un correctif, les mainteneurs créent la balise -beta.N suivante au lieu de supprimer ou recréer l’ancienne balise beta
• La procédure détaillée de publication, les approbations, les identifiants et les notes de récupération sont réservés aux mainteneurs

Publication mensuelle extended-stable npm uniquement

Ceci est une exception dédiée à la procédure de publication régulière ci-dessous. Pour un mois terminé YYYY.M, créer extended-stable/YYYY.M.33 ; publier vYYYY.M.33 et les patchs de maintenance suivants depuis cette même branche. La balise de publication, la pointe de branche, le checkout, la version du package, le précontrôle npm et l’exécution Full Release Validation doivent tous identifier le même commit. Le main protégé doit déjà contenir une version finale d’un mois calendaire strictement ultérieur sous le patch 33 ; les patchs de maintenance restent éligibles après que main a avancé de plus d’un mois.

Exécuter le précontrôle npm et Full Release Validation depuis la branche extended-stable exacte, puis enregistrer les deux identifiants d’exécution :

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 est le profil existant de profondeur de validation ; il est distinct du dist-tag npm extended-stable et reste volontairement inchangé.

Après la réussite des deux exécutions et lorsque l’environnement de publication npm est prêt, promouvoir le tarball exact du précontrôle. Le patch P doit être 33 ou supérieur :

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>

Pour un fork ou une répétition hors production qui ne peut volontairement pas satisfaire la politique mensuelle .33 ou celle du mois de main protégé, ajouter -f bypass_extended_stable_guard=true aux dispatches de précontrôle npm et de publication. La valeur par défaut est false. Le contournement n’est accepté qu’avec npm_dist_tag=extended-stable et est enregistré dans le résumé du workflow. Il ne contourne pas la référence canonique de workflow extended-stable/YYYY.M.33, l’égalité pointe de branche/balise/checkout, la syntaxe de balise finale, l’égalité version du package/balise, l’identité de l’exécution référencée et du manifeste, la provenance du tarball, l’approbation d’environnement, la relecture du registre ni la preuve de réparation du sélecteur.

Le workflow de publication vérifie les identités d’exécution référencées, le condensat du tarball préparé et les deux sélecteurs du registre npm. Confirmer indépendamment le résultat après la réussite du workflow :

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

Les deux commandes doivent retourner YYYY.M.P. Si la publication réussit mais que la relecture du sélecteur échoue, ne pas republier la version immuable du package. Utiliser l’unique commande de réparation npm dist-tag add openclaw@YYYY.M.P extended-stable imprimée dans le résumé toujours exécuté du workflow échoué, puis répéter les deux relectures indépendantes. Le retour arrière vers le sélecteur précédent est une décision opérateur séparée, et non le chemin de réparation de la relecture.

La checklist régulière ci-dessous continue de régir beta, latest, GitHub Release, les plugins, macOS, Windows et les autres publications de plateformes. Ne pas exécuter ces étapes pour ce chemin extended-stable npm uniquement.

Checklist opérateur de publication régulière

Cette checklist est la forme publique du flux de publication. Les identifiants privés, la signature, la notarisation, la récupération de dist-tag et les détails de retour arrière d’urgence restent dans le runbook de publication réservé aux mainteneurs.

1. Démarrez depuis le main actuel : tirez la dernière version, confirmez que le commit cible est poussé, et confirmez que la CI actuelle de main est suffisamment verte pour créer une branche à partir de lui.
2. Générez la section supérieure de CHANGELOG.md à partir des PR fusionnées et de tous les commits directs depuis le dernier tag de release accessible. Gardez des entrées orientées utilisateur, dédupliquez les entrées qui se chevauchent entre PR et commits directs, commitez la réécriture, poussez-la, puis rebasez/tirez encore une fois avant de créer la branche.
3. Examinez les enregistrements de compatibilité de release dans src/plugins/compat/registry.ts et src/commands/doctor/shared/deprecation-compat.ts. Supprimez la compatibilité expirée uniquement lorsque le chemin de mise à niveau reste couvert, ou consignez pourquoi elle est intentionnellement conservée.
4. Créez release/YYYY.M.PATCH depuis le main actuel ; ne faites pas le travail de release normal directement sur main.
5. Incrémentez chaque emplacement de version requis pour le tag prévu, puis exécutez pnpm release:prep. Cette commande actualise les versions des plugins, l’inventaire des plugins, le schéma de configuration, les métadonnées de configuration des canaux inclus, la baseline de documentation de configuration, les exports du SDK Plugin, et la baseline d’API du SDK Plugin dans le bon ordre. Commitez toute dérive générée avant de taguer. Exécutez ensuite le preflight local déterministe : pnpm check:test-types, pnpm check:architecture, pnpm build && pnpm ui:build, et pnpm release:check.
6. Exécutez OpenClaw NPM Release avec preflight_only=true. Avant qu’un tag existe, un SHA complet de branche de release à 40 caractères est autorisé pour un preflight de validation uniquement. Le preflight génère une preuve de release des dépendances pour le graphe de dépendances exact extrait et la stocke dans l’artefact de preflight npm. Enregistrez le preflight_run_id réussi.
7. Lancez tous les tests de pré-release avec Full Release Validation pour la branche de release, le tag, ou le SHA complet du commit. C’est l’unique point d’entrée manuel pour les quatre grands bancs de test de release : Vitest, Docker, QA Lab, et Package.
8. Si la validation échoue, corrigez sur la branche de release et relancez le plus petit fichier, lane, job de workflow, profil de package, fournisseur, ou allowlist de modèles en échec qui prouve la correction. Ne relancez l’umbrella complet que lorsque la surface modifiée rend les preuves précédentes obsolètes.
9. Pour un candidat beta tagué, exécutez pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N depuis la branche release/YYYY.M.PATCH correspondante. Pour stable, transmettez aussi la release source Windows requise : pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z. L’assistant exécute les vérifications locales de release générée, déclenche ou vérifie les preuves de validation complète de release et de preflight npm, exécute la preuve Parallels fraîche/mise à jour contre le tarball préparé exact plus la preuve du package Telegram, enregistre les plans npm des plugins et ClawHub, puis affiche la commande exacte OpenClaw Release Publish uniquement lorsque le bundle de preuves est vert. OpenClaw Release Publish publie les packages de plugins sélectionnés ou tous ceux publiables vers npm et le même ensemble vers ClawHub en parallèle, puis promeut l’artefact de preflight npm OpenClaw préparé avec le dist-tag correspondant dès que la publication npm des plugins réussit. Après la réussite de l’enfant de publication npm OpenClaw, le workflow crée ou met à jour la page GitHub release/prerelease correspondante à partir de la section complète correspondante de CHANGELOG.md. Les releases stable publiées sur npm latest deviennent la dernière release GitHub ; les releases stable de maintenance conservées sur npm beta sont créées avec GitHub latest=false. Le workflow téléverse aussi la preuve de dépendances du preflight, le manifeste de validation complète, et la preuve de vérification du registre post-publication vers la release GitHub pour la réponse aux incidents post-release. Le workflow de publication affiche immédiatement les ID des exécutions enfants, approuve automatiquement les portes de l’environnement de release que le token du workflow est autorisé à approuver, résume les jobs enfants en échec avec des fins de journaux, finalise la release GitHub et la preuve de dépendances dès que la publication npm OpenClaw réussit, attend ClawHub lorsque OpenClaw npm est publié, puis exécute pnpm release:verify-beta et téléverse les preuves post-publication pour la release GitHub, le package npm, les packages npm de plugins sélectionnés, les packages ClawHub sélectionnés, les ID d’exécution des workflows enfants, et l’ID d’exécution NPM Telegram facultatif. Le chemin ClawHub réessaie les échecs transitoires d’installation des dépendances CLI, publie les plugins dont la prévisualisation réussit même lorsqu’une cellule de prévisualisation est flaky, et se termine par une vérification de registre pour chaque version de plugin attendue afin que les publications partielles restent visibles et réessayables. Exécutez ensuite l’acceptation de package post-publication contre le package publié openclaw@YYYY.M.PATCH-beta.N ou openclaw@beta. Si une prerelease poussée ou publiée nécessite une correction, coupez le numéro de prerelease correspondant suivant ; ne supprimez pas et ne réécrivez pas l’ancienne prerelease.
10. Pour stable, continuez uniquement après que la beta ou le release candidate validé dispose des preuves de validation requises. La publication npm stable passe aussi par OpenClaw Release Publish, en réutilisant l’artefact de preflight réussi via preflight_run_id ; la préparation de la release macOS stable exige aussi les .zip, .dmg, .dSYM.zip packagés, et le appcast.xml mis à jour sur main. Le workflow de publication macOS publie automatiquement l’appcast signé vers le main public après vérification des assets de release ; si la protection de branche bloque le push direct, il ouvre ou met à jour une PR d’appcast. La préparation du Hub Windows stable exige les assets signés OpenClawCompanion-Setup-x64.exe, OpenClawCompanion-Setup-arm64.exe, et OpenClawCompanion-SHA256SUMS.txt sur la release GitHub OpenClaw. Transmettez le tag exact de release signé openclaw/openclaw-windows-node comme windows_node_tag et sa carte de digests d’installateurs approuvée par candidat comme windows_node_installer_digests ; OpenClaw Release Publish conserve le brouillon de release, déclenche Windows Node Release, et vérifie les trois assets avant publication.
11. Après publication, exécutez le vérificateur npm post-publication, l’E2E Telegram autonome facultatif du npm publié lorsque vous avez besoin d’une preuve de canal post-publication, la promotion du dist-tag si nécessaire, vérifiez la page de release GitHub générée, exécutez les étapes d’annonce de release, puis terminez Clôture stable de main avant de considérer une release stable comme terminée.

Clôture stable de main

La publication stable n’est pas complète tant que main ne porte pas l’état de release réellement livré.

1. Démarrez depuis le tout dernier main frais. Auditez release/YYYY.M.PATCH par rapport à lui et forward-portez les vraies corrections absentes de main. Ne fusionnez pas aveuglément dans le main plus récent les adaptateurs de compatibilité, de test ou de validation propres à la release.
2. Réglez main sur la version stable livrée, pas sur un prochain train spéculatif. Exécutez pnpm release:prep après le changement de version racine, puis pnpm deps:shrinkwrap:generate.
3. Faites correspondre exactement la section ## YYYY.M.PATCH de CHANGELOG.md sur main à la branche de release taguée. Incluez la mise à jour stable de appcast.xml lorsque la release mac en a publié une.
4. N’ajoutez pas YYYY.M.PATCH+1, une version beta, ni une section de changelog future vide à main tant que l’opérateur n’a pas explicitement démarré ce train de release.
5. Exécutez pnpm release:generated:check, pnpm deps:shrinkwrap:check, et OPENCLAW_TESTBOX=1 pnpm check:changed. Poussez, puis vérifiez que origin/main contient la version livrée et le changelog avant de considérer la release stable comme terminée.
6. Gardez les variables de dépôt RELEASE_ROLLBACK_DRILL_ID et RELEASE_ROLLBACK_DRILL_DATE à jour après chaque exercice privé de rollback. OpenClaw Stable Main Closeout démarre depuis le push main qui porte la version livrée, le changelog, et l’appcast après la publication stable. Il lit les preuves post-publication immuables pour lier le tag livré à ses exécutions Full Release Validation et Publish, puis vérifie l’état stable de main, la release, le soak stable obligatoire, et les preuves de performance bloquantes. Il attache un manifeste de clôture immuable et une somme de contrôle à la release GitHub. Le déclencheur de push automatique ignore les releases héritées antérieures aux preuves post-publication immuables ; il ne traite jamais cet ignore comme une clôture terminée. Une clôture complète exige les deux assets et une somme de contrôle correspondante. Un manifeste partiel rejoue son SHA main enregistré et l’exercice de rollback pour régénérer des octets identiques, puis attache la somme de contrôle manquante ; une paire invalide, ou une somme de contrôle sans manifeste, reste bloquante. Une exécution déclenchée par push sans variables de dépôt d’exercice de rollback est ignorée sans terminer la clôture ; un enregistrement d’exercice manquant ou vieux de plus de 90 jours bloque encore la clôture manuelle appuyée par preuves. Les commandes de récupération privées restent dans le runbook réservé aux maintainers. Utilisez le déclenchement manuel uniquement pour réparer ou rejouer une clôture stable appuyée par preuves. Un tag de correction de fallback hérité peut réutiliser la preuve du package de base uniquement lorsque le tag de correction se résout vers le même commit source que le tag stable de base. Une correction avec une source différente doit publier et vérifier ses propres preuves de package.

Preflight de release

• Exécutez pnpm check:test-types avant le contrôle préalable de publication afin que le TypeScript des tests reste couvert en dehors de la porte locale plus rapide pnpm check
• Exécutez pnpm check:architecture avant le contrôle préalable de publication afin que les vérifications plus larges des cycles d’importation et des limites d’architecture soient au vert en dehors de la porte locale plus rapide
• Exécutez pnpm build && pnpm ui:build avant pnpm release:check afin que les artefacts de publication dist/* attendus et le bundle Control UI existent pour l’étape de validation du pack
• Exécutez pnpm release:prep après l’incrément de version racine et avant le tag. Il exécute tous les générateurs déterministes de publication qui dérivent couramment après un changement de version/configuration/API : versions des plugins, inventaire des plugins, schéma de configuration de base, métadonnées de configuration des canaux groupés, base de référence de la documentation de configuration, exports du plugin SDK et base de référence de l’API du plugin SDK. pnpm release:check réexécute ces garde-fous en mode vérification et signale en une seule passe chaque échec de dérive générée qu’il trouve avant d’exécuter les vérifications de publication du package.
• La synchronisation des versions de plugin met à jour par défaut les versions des packages de plugins officiels et les planchers openclaw.compat.pluginApi existants vers la version de publication d’OpenClaw. Traitez ce champ comme le plancher de l’API plugin SDK/runtime, et non comme une simple copie de la version du package : pour les publications propres à un plugin qui restent volontairement compatibles avec d’anciens hôtes OpenClaw, conservez le plancher à la plus ancienne API d’hôte prise en charge et documentez ce choix dans la preuve de publication du plugin.
• Exécutez le workflow manuel Full Release Validation avant l’approbation de la publication pour lancer toutes les boîtes de test de prépublication depuis un seul point d’entrée. Il accepte une branche, un tag ou un SHA de commit complet, déclenche le CI manuel et déclenche OpenClaw Release Checks pour le smoke d’installation, l’acceptation de package, les vérifications de package multi-OS, la parité QA Lab, Matrix et les voies Telegram. Les exécutions stables et complètes incluent toujours les parcours live/E2E exhaustifs et le soak du chemin de publication Docker ; run_release_soak=true est conservé pour un soak bêta explicite. Package Acceptance fournit l’E2E Telegram canonique du package pendant la validation du candidat, évitant un second poller live concurrent. Fournissez release_package_spec après la publication d’une bêta pour réutiliser le package npm publié dans les vérifications de publication, Package Acceptance et l’E2E Telegram du package sans reconstruire le tarball de publication. Fournissez npm_telegram_package_spec uniquement lorsque Telegram doit utiliser un autre package publié que le reste de la validation de publication. Fournissez package_acceptance_package_spec lorsque Package Acceptance doit utiliser un autre package publié que la spécification de package de publication. Fournissez evidence_package_spec lorsque le rapport de preuve de publication doit prouver que la validation correspond à un package npm publié sans imposer l’E2E Telegram. Exemple : gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.PATCH
• Exécutez le workflow manuel Package Acceptance lorsque vous voulez une preuve par canal secondaire pour un candidat package pendant que le travail de publication continue. Utilisez source=npm pour openclaw@beta, openclaw@latest ou une version de publication exacte ; source=ref pour empaqueter une branche/un tag/un SHA package_ref fiable avec le harnais workflow_ref actuel ; source=url pour un tarball HTTPS public avec un SHA-256 requis et une politique stricte d’URL publique ; source=trusted-url pour une politique de source fiable nommée utilisant trusted_source_id et SHA-256 obligatoires ; ou source=artifact pour un tarball téléversé par une autre exécution GitHub Actions. Le workflow résout le candidat vers package-under-test, réutilise le planificateur de publication Docker E2E contre ce tarball et peut exécuter la QA Telegram contre le même tarball avec telegram_mode=mock-openai ou telegram_mode=live-frontier. Lorsque les voies Docker sélectionnées incluent published-upgrade-survivor, l’artefact de package est le candidat et published_upgrade_survivor_baseline sélectionne la base publiée. update-restart-auth utilise le package candidat comme CLI installé et comme package-under-test afin d’exercer le chemin de redémarrage géré de la commande de mise à jour du candidat. Exemple : 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 Profils courants :
  • smoke : voies installation/canal/agent, réseau Gateway et rechargement de configuration
  • package : voies package/mise à jour/redémarrage/plugin natives de l’artefact, sans OpenWebUI ni ClawHub live
  • product : profil package plus canaux MCP, nettoyage cron/sous-agent, recherche web OpenAI et OpenWebUI
  • full : segments du chemin de publication Docker avec OpenWebUI
  • custom : sélection exacte de docker_lanes pour une réexécution ciblée
• Exécutez directement le workflow manuel CI lorsque vous n’avez besoin que d’une couverture CI normale déterministe pour le candidat de publication. Les déclenchements CI manuels contournent le périmètre des changements et forcent les shards Linux Node, les shards des plugins groupés, les shards de contrats de plugins et de canaux, la compatibilité Node 22, check-*, check-additional-*, les smoke checks des artefacts construits, les vérifications de documentation, les Skills Python, Windows, macOS et les voies i18n de Control UI. Les exécutions CI manuelles autonomes n’exécutent Android que lorsqu’elles sont déclenchées avec include_android=true ; Full Release Validation transmet cette entrée à son enfant CI. Exemple avec Android : gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true
• Exécutez pnpm qa:otel:smoke lors de la validation de la télémétrie de publication. Cela exerce QA-lab via un récepteur OTLP/HTTP local et vérifie l’export des traces, métriques et journaux ainsi que les attributs de trace bornés et la rédaction du contenu/des identifiants sans nécessiter Opik, Langfuse ni un autre collecteur externe.
• Exécutez pnpm qa:otel:collector-smoke lors de la validation de la compatibilité du collecteur. Cela fait passer le même export OTLP QA-lab par un véritable conteneur Docker OpenTelemetry Collector avant les assertions du récepteur local.
• Exécutez pnpm qa:prometheus:smoke lors de la validation du scraping Prometheus protégé. Cela exerce QA-lab, rejette les scrapes non authentifiés et vérifie que les familles de métriques critiques pour la publication restent exemptes de contenu de prompt, d’identifiants bruts, de jetons d’authentification et de chemins locaux.
• Exécutez pnpm qa:observability:smoke lorsque vous voulez enchaîner les voies smoke OpenTelemetry et Prometheus depuis le checkout source.
• Exécutez pnpm release:check avant chaque publication taguée
• Le contrôle préalable OpenClaw NPM Release génère les preuves de publication des dépendances avant d’empaqueter le tarball npm. La porte des vulnérabilités de l’avis npm est bloquante pour la publication. Le risque du manifeste transitif, la surface de propriété/installation des dépendances et les rapports de changement de dépendances sont uniquement des preuves de publication. Le rapport de changement de dépendances compare le candidat de publication avec le tag de publication atteignable précédent.
• Le contrôle préalable téléverse les preuves de dépendances sous le nom openclaw-release-dependency-evidence-<tag> et les intègre aussi sous dependency-evidence/ dans l’artefact de contrôle préalable npm préparé. Le vrai chemin de publication réutilise cet artefact de contrôle préalable, puis attache les mêmes preuves à la publication GitHub sous le nom openclaw-<version>-dependency-evidence.zip.
• Exécutez OpenClaw Release Publish pour la séquence de publication mutante après l’existence du tag. Déclenchez-le depuis release/YYYY.M.PATCH (ou main lors de la publication d’un tag atteignable depuis main), transmettez le tag de publication, le preflight_run_id npm OpenClaw réussi et le full_release_validation_run_id réussi, et conservez la portée de publication de plugin par défaut all-publishable, sauf si vous exécutez délibérément une réparation ciblée. Le workflow sérialise la publication npm des plugins, la publication ClawHub des plugins et la publication npm OpenClaw afin que le package principal ne soit pas publié avant ses plugins externalisés.
• Le OpenClaw Release Publish stable exige un windows_node_tag exact après l’existence de la publication non-prérelease correspondante openclaw/openclaw-windows-node. Il exige aussi la carte windows_node_installer_digests approuvée pour le candidat. Avant de déclencher tout enfant de publication, il vérifie que la publication source est publiée, non-prérelease, contient les installateurs x64/ARM64 requis et correspond toujours à cette carte approuvée. Il déclenche ensuite Windows Node Release pendant que la publication OpenClaw est encore un brouillon, en transmettant inchangée la carte figée des condensats d’installateurs. Le workflow enfant télécharge les installateurs Windows Hub signés depuis ce tag exact, les compare aux condensats figés, vérifie sur un runner Windows que leurs signatures Authenticode utilisent le signataire OpenClaw Foundation attendu, écrit un manifeste SHA-256 et téléverse les installateurs ainsi que le manifeste sur la publication GitHub canonique d’OpenClaw, puis retélécharge les ressources promues et vérifie l’appartenance au manifeste et les hachages. Le parent vérifie le contrat actuel des ressources x64, ARM64 et checksum avant publication. La récupération directe rejette les noms de ressources OpenClawCompanion-* inattendus avant de remplacer les ressources de contrat attendues par les octets source figés. Déclenchez manuellement Windows Node Release uniquement pour la récupération, et transmettez toujours un tag exact, jamais latest, ainsi que la carte JSON explicite expected_installer_digests issue de la publication source approuvée. Les liens de téléchargement du site web doivent cibler les URL exactes des ressources de publication OpenClaw pour la publication stable actuelle, ou releases/latest/download/... uniquement après avoir vérifié que la redirection latest de GitHub pointe vers cette même publication ; ne créez pas de lien uniquement vers la page de publication du dépôt compagnon.
• Les vérifications de publication s’exécutent désormais dans un workflow manuel séparé : OpenClaw Release Checks
• OpenClaw Release Checks exécute aussi la voie de parité mock QA Lab ainsi que le profil Matrix live rapide et la voie QA Telegram avant l’approbation de la publication. Les voies live utilisent l’environnement qa-live-shared ; Telegram utilise aussi les baux d’identifiants CI Convex. Exécutez le workflow manuel QA-Lab - All Lanes avec matrix_profile=all et matrix_shards=true lorsque vous voulez l’inventaire complet du transport Matrix, des médias et de l’E2EE en parallèle.
• La validation runtime d’installation et de mise à niveau multi-OS fait partie des workflows publics OpenClaw Release Checks et Full Release Validation, qui appellent directement le workflow réutilisable .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• Cette séparation est intentionnelle : garder le vrai chemin de publication npm court, déterministe et centré sur les artefacts, tandis que les vérifications live plus lentes restent dans leur propre voie afin qu’elles ne ralentissent ni ne bloquent la publication
• Les vérifications de publication portant des secrets doivent être déclenchées via Full Release Validation ou depuis la référence de workflow main/release afin que la logique du workflow et les secrets restent contrôlés
• OpenClaw Release Checks accepte une branche, un tag ou un SHA de commit complet tant que le commit résolu est atteignable depuis une branche OpenClaw ou un tag de publication
• Le contrôle préalable de validation seule OpenClaw NPM Release accepte aussi le SHA de commit complet de 40 caractères de la branche de workflow actuelle sans exiger de tag poussé
• Ce chemin SHA est réservé à la validation et ne peut pas être promu en vraie publication
• En mode SHA, le workflow synthétise v<package.json version> uniquement pour la vérification des métadonnées de package ; la vraie publication exige toujours un vrai tag de publication
• Les deux workflows conservent le vrai chemin de publication et de promotion sur les runners hébergés par GitHub, tandis que le chemin de validation non mutant peut utiliser les runners Linux Blacksmith plus grands
• Ce workflow exécute OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache en utilisant les secrets de workflow OPENAI_API_KEY et ANTHROPIC_API_KEY
• Le contrôle préalable de publication npm n’attend plus la voie séparée des vérifications de publication
• Avant de taguer localement un candidat de publication, exécutez RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check. L’aide exécute les garde-fous rapides de publication, les vérifications de publication npm/ClawHub des plugins, le build, le build UI et release:openclaw:npm:check dans l’ordre qui détecte les erreurs courantes bloquant l’approbation avant le démarrage du workflow de publication GitHub.
• Exécutez RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (ou le tag bêta/correctif correspondant) avant approbation
• Après la publication npm, exécutez node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (ou la version bêta/correction correspondante) pour vérifier le chemin d’installation du registre publié dans un préfixe temporaire neuf
• Après une publication bêta, exécutez 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 pour vérifier l’intégration du package installé, la configuration de Telegram et l’E2E Telegram réel avec le package npm publié en utilisant le pool partagé d’identifiants Telegram loués. Les exécutions ponctuelles locales des mainteneurs peuvent omettre les variables Convex et transmettre directement les trois identifiants d’environnement OPENCLAW_QA_TELEGRAM_*.
• Pour exécuter le smoke bêta complet après publication depuis la machine d’un mainteneur, utilisez pnpm release:beta-smoke -- --beta betaN. L’assistant exécute la validation Parallels de mise à jour npm et de cible fraîche, déclenche NPM Telegram Beta E2E, interroge l’exécution exacte du workflow, télécharge l’artéfact et affiche le rapport Telegram.
• Les mainteneurs peuvent exécuter la même vérification après publication depuis GitHub Actions via le workflow manuel NPM Telegram Beta E2E. Il est volontairement manuel uniquement et ne s’exécute pas à chaque fusion.
• L’automatisation de release des mainteneurs utilise désormais prévol-puis-promotion :
  • la publication npm réelle doit réussir avec un npm preflight_run_id
  • la publication npm réelle doit être déclenchée depuis la même branche main ou release/YYYY.M.PATCH que l’exécution de prévol réussie
  • les releases npm stables ciblent beta par défaut
  • la publication npm stable peut cibler explicitement latest via l’entrée du workflow
  • la mutation de npm dist-tag basée sur un jeton vit désormais dans openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml, car npm dist-tag add a toujours besoin de NPM_TOKEN, tandis que le dépôt source conserve une publication OIDC uniquement
  • macOS Release public est uniquement destiné à la validation ; lorsqu’un tag n’existe que sur une branche de release mais que le workflow est déclenché depuis main, définissez public_release_branch=release/YYYY.M.PATCH
  • la publication macOS réelle doit réussir avec un preflight_run_id macOS et un validate_run_id
  • les chemins de publication réelle promeuvent les artéfacts préparés au lieu de les reconstruire à nouveau
• Pour les releases de correction stables comme YYYY.M.PATCH-N, le vérificateur après publication vérifie aussi le même chemin de mise à niveau avec préfixe temporaire de YYYY.M.PATCH vers YYYY.M.PATCH-N, afin que les corrections de release ne puissent pas laisser silencieusement les anciennes installations globales sur la charge utile stable de base
• Le prévol de release npm échoue en mode fermé sauf si le tarball inclut à la fois dist/control-ui/index.html et une charge utile dist/control-ui/assets/ non vide, afin de ne pas réexpédier un tableau de bord navigateur vide
• La vérification après publication vérifie aussi que les points d’entrée des Plugins publiés et les métadonnées de package sont présents dans la disposition installée du registre. Une release qui expédie des charges utiles d’exécution de Plugin manquantes échoue au vérificateur après publication et ne peut pas être promue vers latest.
• pnpm test:install:smoke applique aussi le budget npm pack unpackedSize sur le tarball candidat de mise à jour, afin que l’e2e de l’installateur détecte les gonflements accidentels de package avant le chemin de publication de release
• Si le travail de release a touché la planification CI, les manifestes de timing des extensions ou les matrices de test des extensions, régénérez et révisez les sorties de matrice plugin-prerelease-extension-shard détenues par le planificateur depuis .github/workflows/plugin-prerelease.yml avant approbation, afin que les notes de release ne décrivent pas une disposition CI obsolète
• La préparation d’une release macOS stable inclut aussi les surfaces de mise à jour :
  • la release GitHub doit finir avec les fichiers packagés .zip, .dmg et .dSYM.zip
  • appcast.xml sur main doit pointer vers le nouveau zip stable après publication ; le workflow de publication macOS le valide automatiquement, ou ouvre une PR appcast lorsque le push direct est bloqué
  • l’application packagée doit conserver un identifiant de bundle non-debug, une URL de flux Sparkle non vide et un CFBundleVersion égal ou supérieur au plancher canonique de build Sparkle pour cette version de release

Boîtes de test de release

Full Release Validation est la façon dont les opérateurs lancent tous les tests de pré-release depuis un seul point d’entrée. Pour une preuve de commit épinglé sur une branche qui évolue rapidement, utilisez l’assistant afin que chaque workflow enfant s’exécute depuis une branche temporaire fixée au SHA cible :

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

L’assistant pousse release-ci/<sha>-..., déclenche Full Release Validation depuis cette branche avec ref=<sha>, vérifie que chaque workflow enfant headSha correspond à la cible, puis supprime la branche temporaire. Cela évite de prouver accidentellement une exécution enfant plus récente de main.

Pour la validation d’une branche ou d’un tag de release, exécutez-la depuis la ref de workflow main approuvée et passez la branche ou le tag de release comme 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

Le workflow résout la ref cible, déclenche manuellement CI avec target_ref=<release-ref>, puis déclenche OpenClaw Release Checks. OpenClaw Release Checks déploie en éventail le smoke test d’installation, les vérifications de release cross-OS, la couverture live/E2E du chemin de release Docker lorsque le soak est activé, Package Acceptance avec l’E2E canonique du package Telegram, la parité QA Lab, la Matrix live et Telegram live. Une exécution full/all n’est acceptable que lorsque le résumé de Full Release Validation indique normal_ci, plugin_prerelease et release_checks comme réussis, sauf si une relance ciblée a intentionnellement ignoré l’enfant Plugin Prerelease séparé. Utilisez l’enfant autonome npm-telegram uniquement pour une relance ciblée du package publié avec release_package_spec ou npm_telegram_package_spec. Le résumé final du vérificateur inclut des tableaux des jobs les plus lents pour chaque exécution enfant, afin que le responsable de release puisse voir le chemin critique actuel sans télécharger les journaux. Consultez Validation complète de release pour la matrice complète des étapes, les noms exacts des jobs de workflow, les différences entre profils stable et full, les artefacts et les identifiants de relance ciblée. Les workflows enfants sont déclenchés depuis la ref approuvée qui exécute Full Release Validation, normalement --ref main, même lorsque la ref cible pointe vers une branche ou un tag de release plus ancien. Il n’existe pas d’entrée séparée de ref de workflow Full Release Validation ; choisissez le harnais approuvé en choisissant la ref d’exécution du workflow. N’utilisez pas --ref main -f ref=<sha> pour une preuve exacte de commit sur main en mouvement ; les SHA de commits bruts ne peuvent pas être des refs de dispatch de workflow, donc utilisez pnpm ci:full-release --sha <sha> pour créer la branche temporaire épinglée.

Utilisez release_profile pour sélectionner l’étendue live/provider :

• minimum : chemin live et Docker OpenAI/core critique pour la release le plus rapide
• stable : minimum plus couverture stable provider/backend pour l’approbation de release
• full : stable plus large couverture consultative provider/médias

Les validations stable et full exécutent toujours le balayage exhaustif live/E2E, du chemin de release Docker et bounded published upgrade-survivor avant la promotion. Utilisez run_release_soak=true pour demander le même balayage pour une bêta. Ce balayage couvre les quatre derniers packages stables plus les références épinglées 2026.4.23 et 2026.5.2 plus la couverture plus ancienne 2026.4.15, avec les références dupliquées supprimées et chaque référence fragmentée dans son propre job runner Docker.

OpenClaw Release Checks utilise la ref de workflow approuvée pour résoudre la ref cible une seule fois comme release-package-under-test et réutilise cet artefact dans les vérifications cross-OS, Package Acceptance et Docker du chemin de release lorsque le soak s’exécute. Cela maintient toutes les boîtes orientées package sur les mêmes octets et évite les builds de package répétés. Après qu’une bêta est déjà sur npm, définissez release_package_spec=openclaw@YYYY.M.PATCH-beta.N afin que les vérifications de release téléchargent une seule fois le package expédié, extraient son SHA source de build depuis dist/build-info.json, et réutilisent cet artefact pour les voies cross-OS, Package Acceptance, Docker du chemin de release et package Telegram. Le smoke test d’installation cross-OS OpenAI utilise OPENCLAW_CROSS_OS_OPENAI_MODEL lorsque la variable repo/org est définie, sinon openai/gpt-5.4, car cette voie prouve l’installation du package, l’onboarding, le démarrage du gateway et un tour d’agent live plutôt que de mesurer le modèle par défaut le plus lent. La matrice live provider plus large reste l’endroit dédié à la couverture propre aux modèles.

Utilisez ces variantes selon l’étape de release :

# 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

N’utilisez pas le parapluie complet comme première relance après un correctif ciblé. Si une boîte échoue, utilisez le workflow enfant, le job, la voie Docker, le profil de package, le provider de modèle ou la voie QA échoué pour la preuve suivante. Réexécutez le parapluie complet uniquement lorsque le correctif a modifié l’orchestration de release partagée ou a rendu obsolète la preuve all-box précédente. Le vérificateur final du parapluie revérifie les identifiants enregistrés d’exécution des workflows enfants ; ainsi, après la réussite de la relance d’un workflow enfant, relancez uniquement le job parent échoué Verify full validation.

Pour une récupération bornée, passez rerun_group au parapluie. all est la véritable exécution de release-candidate, ci exécute uniquement l’enfant CI normal, plugin-prerelease exécute uniquement l’enfant Plugin réservé à la release, release-checks exécute toutes les boîtes de release, et les groupes de release plus étroits sont install-smoke, cross-os, live-e2e, package, qa, qa-parity, qa-live et npm-telegram. Les relances ciblées npm-telegram nécessitent release_package_spec ou npm_telegram_package_spec ; les exécutions full/all utilisent l’E2E canonique package Telegram dans Package Acceptance. Les relances ciblées cross-OS peuvent ajouter cross_os_suite_filter=windows/packaged-upgrade ou un autre filtre OS/suite. Les échecs QA release-check bloquent la validation de release normale, y compris la dérive requise des outils dynamiques OpenClaw au niveau standard. Les exécutions alpha Tideclaw peuvent encore traiter les voies release-check non liées à la sûreté du package comme consultatives. Lorsque live_suite_filter demande explicitement une voie QA live gated telle que Discord, WhatsApp ou Slack, la variable repo OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED correspondante doit être activée ; sinon la capture d’entrée échoue au lieu d’ignorer silencieusement la voie.

Vitest

La boîte Vitest est le workflow enfant manuel CI. La CI manuelle contourne intentionnellement le scoping des changements et force le graphe de tests normal pour le release candidate : fragments Linux Node, fragments de bundled-plugin, fragments de contrats de Plugin et de canal, compatibilité Node 22, check-*, check-additional-*, smoke checks d’artefacts construits, vérifications docs, Skills Python, Windows, macOS, et i18n Control UI. Android est inclus lorsque Full Release Validation exécute la boîte, car le parapluie passe include_android=true ; la CI manuelle autonome requiert include_android=true pour la couverture Android.

Utilisez cette boîte pour répondre à « l’arbre source a-t-il réussi toute la suite de tests normale ? » Ce n’est pas la même chose que la validation produit du chemin de release. Preuves à conserver :

• résumé Full Release Validation montrant l’URL de l’exécution CI déclenchée
• exécution CI verte sur le SHA cible exact
• noms des fragments échoués ou lents depuis les jobs CI lors de l’investigation de régressions
• artefacts de chronométrage Vitest tels que .artifacts/vitest-shard-timings.json lorsqu’une exécution nécessite une analyse de performance

Exécutez la CI manuelle directement uniquement lorsque la release nécessite une CI normale déterministe mais pas les boîtes Docker, QA Lab, live, cross-OS ou package. Utilisez la première commande pour une CI directe non Android. Ajoutez include_android=true lorsque la CI directe du release-candidate doit couvrir 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

La boîte Docker vit dans OpenClaw Release Checks via openclaw-live-and-e2e-checks-reusable.yml, ainsi que dans le workflow install-smoke en mode release. Elle valide le release candidate au moyen d’environnements Docker packagés au lieu de tests uniquement au niveau source.

La couverture Docker de release inclut :

• smoke test d’installation complet avec le smoke test lent d’installation globale Bun activé
• préparation/réutilisation de l’image smoke du Dockerfile racine par SHA cible, avec des jobs QR, root/gateway et installer/Bun exécutés comme fragments install-smoke séparés
• voies E2E du dépôt
• blocs Docker du chemin de release : 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 et plugins-runtime-install-h
• couverture OpenWebUI dans le bloc plugins-runtime-services lorsqu’elle est demandée
• voies scindées d’installation/désinstallation de Plugins groupés bundled-plugin-install-uninstall-0 jusqu’à bundled-plugin-install-uninstall-23
• suites provider live/E2E et couverture de modèles live Docker lorsque les vérifications de release incluent des suites live

Utilisez les artefacts Docker avant de relancer. Le planificateur du chemin de release téléverse .artifacts/docker-tests/ avec les journaux de voies, summary.json, failures.json, les chronométrages de phase, le JSON de plan du planificateur et les commandes de relance. Pour une récupération ciblée, utilisez docker_lanes=<lane[,lane]> sur le workflow réutilisable live/E2E au lieu de relancer tous les blocs de release. Les commandes de relance générées incluent le package_artifact_run_id précédent et les entrées d’image Docker préparées lorsqu’elles sont disponibles, afin qu’une voie échouée puisse réutiliser le même tarball et les mêmes images GHCR.

QA Lab

La boîte QA Lab fait également partie de OpenClaw Release Checks. C’est le gate de release pour le comportement agentique et au niveau canal, distinct de Vitest et des mécaniques de package Docker.

La couverture QA Lab de release inclut :

• voie de parité mock comparant la voie candidate OpenAI à la référence Opus 4.6 à l’aide du pack de parité agentique
• profil QA Matrix live rapide utilisant l’environnement qa-live-shared
• voie QA Telegram live utilisant les baux d’identifiants Convex CI
• pnpm qa:otel:smoke, pnpm qa:otel:collector-smoke, pnpm qa:prometheus:smoke ou pnpm qa:observability:smoke lorsque la télémétrie de release nécessite une preuve locale explicite

Utilisez cette boîte pour répondre à « la release se comporte-t-elle correctement dans les scénarios QA et les flux de canaux live ? » Conservez les URL d’artefacts pour les voies de parité, Matrix et Telegram lors de l’approbation de la release. La couverture Matrix complète reste disponible sous forme d’exécution QA-Lab manuelle fragmentée plutôt que comme voie critique par défaut de release.

Package

La boîte Package est le gate du produit installable. Elle est soutenue par Package Acceptance et le résolveur scripts/resolve-openclaw-package-candidate.mjs. Le résolveur normalise un candidat en tarball package-under-test consommé par Docker E2E, valide l’inventaire du package, enregistre la version du package et le SHA-256, et garde la ref du harnais de workflow séparée de la ref source du package.

Sources de candidats prises en charge :

• source=npm : openclaw@beta, openclaw@latest ou une version exacte de publication OpenClaw
• source=ref : empaqueter une branche, une balise ou un SHA de commit complet package_ref fiable avec le harnais workflow_ref sélectionné
• source=url : télécharger un .tgz HTTPS public avec le package_sha256 requis ; les identifiants dans l’URL, les ports HTTPS non par défaut, les noms d’hôte ou adresses résolues privés/internes/à usage spécial, ainsi que les redirections non sûres sont rejetés
• source=trusted-url : télécharger un .tgz HTTPS avec le package_sha256 requis et le trusted_source_id depuis une stratégie nommée dans .github/package-trusted-sources.json ; utilisez ceci pour les miroirs d’entreprise ou les dépôts de paquets privés détenus par les mainteneurs au lieu d’ajouter un contournement de réseau privé au niveau de l’entrée à source=url
• source=artifact : réutiliser un .tgz téléversé par une autre exécution GitHub Actions

OpenClaw Release Checks exécute Package Acceptance avec source=artifact, l’artefact de paquet de publication préparé, 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 conserve l’AQ des migrations, mises à jour, redémarrage de mise à jour avec authentification configurée, installation de Skills ClawHub en direct, nettoyage des dépendances de Plugins obsolètes, fixtures de Plugins hors ligne, mise à jour de Plugins et paquet Telegram contre le même tarball résolu. Les contrôles de publication bloquants utilisent la référence par défaut du dernier paquet publié ; le profil bêta avec run_release_soak=true, release_profile=stable ou release_profile=full s’étend à chaque référence stable publiée sur npm de 2026.4.23 à latest, ainsi qu’aux fixtures de problèmes signalés. Utilisez Package Acceptance avec source=npm pour un candidat déjà livré, source=ref pour un tarball npm local adossé à un SHA avant publication, source=trusted-url pour un miroir d’entreprise/privé détenu par les mainteneurs, ou source=artifact pour un tarball préparé téléversé par une autre exécution GitHub Actions. C’est le remplacement natif GitHub de la majeure partie de la couverture paquet/mise à jour qui nécessitait auparavant Parallels. Les contrôles de publication multi-OS restent importants pour l’intégration initiale propre à l’OS, l’installateur et le comportement de plateforme, mais la validation produit des paquets/mises à jour doit privilégier Package Acceptance.

La liste de contrôle canonique pour la validation des mises à jour et des Plugins est Tester les mises à jour et les Plugins. Utilisez-la pour décider quelle piste locale, Docker, Package Acceptance ou de contrôle de publication prouve une installation/mise à jour de Plugin, un nettoyage par doctor ou un changement de migration de paquet publié. La migration exhaustive de mise à jour publiée depuis chaque paquet stable 2026.4.23+ est un workflow manuel distinct Update Migration, et ne fait pas partie de Full Release CI.

La tolérance héritée de package-acceptance est volontairement limitée dans le temps. Les paquets jusqu’à 2026.4.25 peuvent utiliser le chemin de compatibilité pour les lacunes de métadonnées déjà publiées sur npm : entrées d’inventaire AQ privées absentes du tarball, gateway install --wrapper manquant, fichiers de correctif manquants dans la fixture git dérivée du tarball, update.channel persistant manquant, emplacements hérités d’enregistrements d’installation de Plugins, persistance manquante d’enregistrements d’installation de marketplace, et migration des métadonnées de configuration pendant plugins update. Le paquet publié 2026.4.26 peut émettre un avertissement pour les fichiers d’empreinte de métadonnées de build local qui ont déjà été livrés. Les paquets ultérieurs doivent satisfaire les contrats de paquet modernes ; ces mêmes lacunes font échouer la validation de publication.

Utilisez des profils Package Acceptance plus larges lorsque la question de publication porte sur un paquet réellement installable :

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

Profils de paquet courants :

• smoke : pistes rapides d’installation de paquet/canal/agent, réseau Gateway et rechargement de configuration
• package : contrats d’installation/mise à jour/redémarrage/paquet Plugin, plus preuve d’installation de Skills ClawHub en direct ; c’est la valeur par défaut des contrôles de publication
• product : package plus canaux MCP, nettoyage cron/sous-agent, recherche web OpenAI et OpenWebUI
• full : blocs de chemin de publication Docker avec OpenWebUI
• custom : liste exacte docker_lanes pour les réexécutions ciblées

Pour la preuve Telegram d’un candidat de paquet, activez telegram_mode=mock-openai ou telegram_mode=live-frontier sur Package Acceptance. Le workflow transmet le tarball résolu package-under-test à la piste Telegram ; le workflow Telegram autonome accepte toujours une spécification npm publiée pour les contrôles post-publication.

Automatisation de publication des versions régulières

Pour la publication bêta, latest, Plugin, GitHub Release et plateforme, OpenClaw Release Publish est le point d’entrée mutant normal. Le chemin mensuel .33+ extended-stable uniquement npm n’utilise pas cet orchestrateur. Le workflow régulier orchestre les workflows de publication fiable dans l’ordre requis par la publication :

1. Extraire la balise de publication et résoudre son SHA de commit.
2. Vérifier que la balise est accessible depuis main ou release/*.
3. Exécuter pnpm plugins:sync:check.
4. Déclencher Plugin NPM Release avec publish_scope=all-publishable et ref=<release-sha>.
5. Déclencher Plugin ClawHub Release avec le même périmètre et le même SHA.
6. Déclencher OpenClaw NPM Release avec la balise de publication, la dist-tag npm et le preflight_run_id enregistré après vérification du full_release_validation_run_id enregistré.
7. Pour les versions stables, créer ou mettre à jour la publication GitHub en brouillon, déclencher Windows Node Release avec le windows_node_tag explicite et les windows_node_installer_digests approuvés pour le candidat, puis vérifier les artefacts canoniques d’installateur/somme de contrôle avant de publier le brouillon.

Exemple de publication bêta :

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

Publication stable vers la dist-tag bêta par défaut :

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 promotion stable directement vers latest est explicite :

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

Utilisez les workflows de niveau inférieur Plugin NPM Release et Plugin ClawHub Release uniquement pour des travaux ciblés de réparation ou de republication. OpenClaw Release Publish rejette plugin_publish_scope=selected lorsque publish_openclaw_npm=true, afin que le paquet principal ne puisse pas être livré sans tous les Plugins officiels publiables, y compris @openclaw/diffs-language-pack. Pour une réparation de Plugin sélectionné, définissez publish_openclaw_npm=false avec plugin_publish_scope=selected et plugins=@openclaw/name, ou déclenchez directement le workflow enfant.

Entrées du workflow NPM

OpenClaw NPM Release accepte ces entrées contrôlées par l’opérateur :

• tag : balise de publication requise, comme v2026.4.2, v2026.4.2-1 ou v2026.4.2-beta.1 ; lorsque preflight_only=true, elle peut aussi être le SHA de commit complet à 40 caractères de la branche de workflow actuelle pour une prévalidation limitée à la validation
• preflight_only : true pour validation/build/paquet uniquement, false pour le chemin de publication réel
• preflight_run_id : requis sur le chemin de publication réel afin que le workflow réutilise le tarball préparé depuis l’exécution de prévalidation réussie
• full_release_validation_run_id : requis pour la vraie publication mensuelle extended-stable et la publication régulière non bêta, afin que le workflow authentifie l’exécution de validation exacte
• npm_dist_tag : balise npm cible pour le chemin de publication ; accepte alpha, beta, latest ou extended-stable et vaut beta par défaut. Le correctif final 33 et les suivants doivent utiliser extended-stable ; par défaut, extended-stable rejette les correctifs antérieurs, et rejette toujours les balises non finales.
• bypass_extended_stable_guard : booléen réservé aux tests, valeur par défaut false ; avec npm_dist_tag=extended-stable, contourne l’éligibilité mensuelle extended-stable tout en préservant les contrôles d’identité de publication, d’artefact, d’approbation et de relecture.

OpenClaw Release Publish accepte ces entrées contrôlées par l’opérateur :

• tag : balise de publication requise ; elle doit déjà exister
• preflight_run_id : identifiant d’exécution de prévalidation OpenClaw NPM Release réussie ; requis lorsque publish_openclaw_npm=true
• full_release_validation_run_id : identifiant d’exécution Full Release Validation réussie ; requis lorsque publish_openclaw_npm=true
• windows_node_tag : balise de publication exacte non préversion openclaw/openclaw-windows-node ; requise pour une publication stable OpenClaw
• windows_node_installer_digests : carte JSON compacte approuvée pour le candidat, des noms actuels d’installateurs Windows vers leurs condensats sha256: épinglés ; requise pour une publication stable OpenClaw
• npm_dist_tag : balise npm cible pour le paquet OpenClaw
• plugin_publish_scope : vaut all-publishable par défaut ; utilisez selected uniquement pour un travail ciblé de réparation de Plugin seul avec publish_openclaw_npm=false
• plugins : noms de paquets @openclaw/* séparés par des virgules lorsque plugin_publish_scope=selected
• publish_openclaw_npm : vaut true par défaut ; définissez false uniquement lorsque vous utilisez le workflow comme orchestrateur de réparation de Plugin seul
• wait_for_clawhub : vaut false par défaut afin que la disponibilité npm ne soit pas bloquée par le sidecar ClawHub ; définissez true uniquement lorsque l’achèvement du workflow doit inclure l’achèvement ClawHub

OpenClaw Release Checks accepte ces entrées contrôlées par l’opérateur :

• ref : branche, balise ou SHA de commit complet à valider. Les contrôles avec secrets exigent que le commit résolu soit accessible depuis une branche OpenClaw ou une balise de publication.
• run_release_soak : active le soak exhaustif live/E2E, le chemin de publication Docker et l’upgrade-survivor depuis toutes les versions pour les contrôles de publication bêta. Il est forcé par release_profile=stable et release_profile=full.

Règles :

• Les versions finales régulières et de correction sous le correctif 33 peuvent être publiées vers beta ou latest. Les versions finales au correctif 33 ou supérieur doivent être publiées vers extended-stable, et les versions avec suffixe de correction à cette frontière sont rejetées.
• Les balises de préversion bêta ne peuvent être publiées que vers beta
• Pour OpenClaw NPM Release, l’entrée SHA de commit complet n’est autorisée que lorsque preflight_only=true
• OpenClaw Release Checks et Full Release Validation sont toujours uniquement de validation
• Le chemin de publication réel doit utiliser le même npm_dist_tag que celui utilisé pendant la prévalidation ; le workflow vérifie que les métadonnées avant publication continuent de correspondre

Séquence de publication stable bêta/latest régulière

Cette séquence héritée concerne la publication régulière orchestrée qui possède aussi les Plugins, GitHub Release, Windows et les autres travaux de plateforme. Ce n’est pas le chemin mensuel .33+ extended-stable uniquement npm documenté en haut de cette page.

Lors de la préparation d’une publication stable orchestrée régulière :

1. Exécutez OpenClaw NPM Release avec preflight_only=true
   • Avant qu’une balise existe, vous pouvez utiliser le SHA du commit actuel complet de la branche de workflow pour un essai à blanc de validation uniquement du workflow de prévérification
2. Choisissez npm_dist_tag=beta pour le flux normal beta-first, ou latest uniquement lorsque vous voulez intentionnellement une publication stable directe
3. Exécutez Full Release Validation sur la branche de publication, la balise de publication ou le SHA complet du commit lorsque vous voulez la CI normale plus la couverture live prompt cache, Docker, QA Lab, Matrix et Telegram depuis un seul workflow manuel
4. Si vous avez intentionnellement seulement besoin du graphe de tests normal déterministe, exécutez plutôt le workflow manuel CI sur la référence de publication
5. Sélectionnez la balise de publication exacte non préliminaire openclaw/openclaw-windows-node dont les installateurs signés x64 et ARM64 doivent être livrés. Enregistrez-la sous windows_node_tag, et enregistrez leur carte d’empreintes validées sous windows_node_installer_digests. L’assistant de version candidate enregistre les deux et les inclut dans sa commande de publication générée.
6. Enregistrez les preflight_run_id et full_release_validation_run_id réussis
7. Exécutez OpenClaw Release Publish avec le même tag, le même npm_dist_tag, le windows_node_tag sélectionné, son windows_node_installer_digests enregistré, le preflight_run_id enregistré et le full_release_validation_run_id enregistré ; il publie les plugins externalisés vers npm et ClawHub avant de promouvoir le paquet npm OpenClaw
8. Si la publication a atterri sur beta, utilisez le workflow openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml pour promouvoir cette version stable de beta vers latest
9. Si la publication a intentionnellement été publiée directement vers latest et que beta doit suivre immédiatement la même build stable, utilisez le même workflow de publication pour faire pointer les deux dist-tags vers la version stable, ou laissez sa synchronisation planifiée d’auto-réparation déplacer beta plus tard

La mutation dist-tag vit dans le dépôt du registre de publication parce qu’elle nécessite encore NPM_TOKEN, tandis que le dépôt source conserve une publication uniquement OIDC.

Cela garde le chemin de publication directe et le chemin de promotion beta-first à la fois documentés et visibles par l’opérateur.

Si un mainteneur doit se rabattre sur l’authentification npm locale, exécutez les commandes CLI (op) 1Password uniquement dans une session tmux dédiée. N’appelez pas op directement depuis le shell principal de l’agent ; le garder dans tmux rend les invites, alertes et la gestion OTP observables et empêche les alertes hôte répétées.

Références publiques

• .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

Les mainteneurs utilisent la documentation de publication privée dans openclaw/maintainers/release/README.md pour le runbook réel.

Associé

• Canaux de publication