openclaw-changelog-update

OpenClaw Changelog Update

Utilisez ceci pour les réécritures du journal des modifications et le texte source des notes de version GitHub. Pour les versions bêta/stables régulières, préparez des notes complètes avant la qualification de la source finale lorsque cela est possible ; le SHA du code peut alors également être le SHA de la version. Le travail éditorial peut chevaucher la validation du code. Ne l'exécutez pas à nouveau par validation-backport de récupération ; lorsque les backports remplacent le SHA du code, exécutez-le une fois après que le SHA du code final soit vert, en tant que descendant légitime uniquement CHANGELOG sous la politique de réutilisation des preuves de produit existante (timing). Pour les versions étendues-stables, exécutez-le avant la validation exacte de la tête et le marquage. Ne l'exécutez pas à nouveau pour les nouvelles tentatives d'outillage, la reprise de publication ou la promotion. Utilisez-le avec release-openclaw-maintainer ; cette compétence possède le contenu du journal des modifications, l'ordre, le regroupement et la discipline d'attribution.

Objectif

Reconstruire la section de version CHANGELOG/<version>.md cible à partir d'un manifeste d'historique complet et généré, et non de notes de projet obsolètes. Produire des notes de version orientées utilisateur groupées, triées par intérêt utilisateur tout en préservant chaque référence de problème/PR pertinente et chaque attribution humaine Thanks @....

CHANGELOG.md est l'index de version généré. Le propriétaire partagé scripts/lib/release-changelog.mjs résout les sections de version et les enregistrements de contribution à partir d'un arbre de travail ou d'une référence Git épinglée, y compris les références historiques qui contiennent encore un monolithe. Utilisez node scripts/release-changelog.mjs read --version <version> [--ref <sha-or-tag>] pour une section, ou ajoutez --record pour son enregistrement de contribution. Un artefact de scission manquant ne doit pas revenir à l'index racine. Les versions historiques sans enregistrements n'obtiennent aucune provenance inventée. Les fichiers CHANGELOG/** générés conservent les octets exacts migrés ou reflétés et sont exclus du formatage générique, comme le journal des modifications racine. Validez-les via leur propriétaire avec pnpm changelog:check.

Les écritures actuelles utilisent la disposition de scission. Pour enregistrer une section initiale complète, utilisez node scripts/release-changelog.mjs write --version <version> --file <section.md> ; il met à jour l'entrée de version, correspondant à CHANGELOG/records/<version>.md lorsqu'elle est présente, et index ensemble. La génération initiale conserve le format de section ci-dessous. Les miroirs de documentation publiés suivent la route post-version séparée à la fin de cette compétence ; la génération initiale ne doit jamais les écraser.

Entrées

• Version cible : YYYY.M.PATCH-beta.N exact pour un delta bêta ; YYYY.M.PATCH pour les notes stables cumulatives. Les entrées et enregistrements bêta sont des artefacts séparés et figés, jamais des copies de la section de base stable.
• Balise de base bêta : capturez la version actuellement sélectionnée par le npm public openclaw@beta avant la publication, et non la dernière version préliminaire GitHub ou la version la plus élevée avec suffixe bêta. Le sélecteur peut nommer une version stable également sélectionnée par latest. Omettez --base (ou utilisez --base npm-beta) avec une version bêta exacte pour la résoudre une fois ; conservez la balise résolue du manifeste généré et réutilisez cette --base explicite pour les modifications, la vérification et la récupération. Si npm sélectionne déjà le candidat ou une version plus récente, la génération refuse de deviner l'état historique du sélecteur ; fournissez la balise précédemment capturée. Lorsque cette balise n'est pas un ancêtre (par exemple un port avant de clôture stable), le vérificateur utilise sa base de fusion accessible et soustrait l'enregistrement PR cumulatif de la balise expédiée capturée via la sémantique --shipped-ref. Le manifeste et l'enregistrement conservent les deux limites ; rejouez avec la balise capturée pour résoudre la même plage, ne sélectionnez jamais une version bêta GitHub plus ancienne à la place.
• Balise de base stable : dernière balise de version stable expédiée accessible. Elle doit être un ancêtre de la cible ; une balise plus récente mais divergente n'est pas une limite d'historique valide. Utilisez un SHA expédié/clôture principale explicite uniquement lorsqu'il est également accessible depuis la cible.
• Référence cible : l'historique exact du produit complet étant documenté. Sa cible d'enregistrement de contribution doit être un ancêtre de la cible de version finale ; elle n'a pas besoin de nommer un commit de journal des modifications pas encore créé. Incluez tous les correctifs ultérieurs avant de finaliser les notes. Les notes finales peuvent être validées avant la qualification, ou après en tant que descendant uniquement CHANGELOG d'un SHA de code vert.
• Référence principale canonique : origin/main actuelle, récupérée avant la vérification. Les notes de version citent la PR principale fusionnée d'origine lorsque le même travail est porté par un backport. Une PR de branche de version est utilisée uniquement lorsqu'aucun port avant n'existe sur la version principale actuelle.

Flux de travail

1. Confirmez la branche de version et la cible d'historique exacte :

   • git fetch --tags origin
   • confirmez git status -sb propre
   • enregistrez git rev-parse HEAD comme cible d'historique
   • enregistrez l'ID d'exécution et la tentative de validation complète de la version lorsque la qualification existe déjà
   • terminez les modifications produit/version/backport en attente avant de geler la source finale ; actualisez l'inventaire pour les modifications réelles

2. Auditez l'historique, y compris les commits directs :

   • git log --topo-order --date=iso-strict --pretty=format:'%h%x09%ad%x09%s' <base-tag>..<target-ref>
   • git log --topo-order --grep='(#' --date=short --pretty=format:'%h%x09%ad%x09%s' <base-tag>..<target-ref>
   • Incluez tous les commits accessibles depuis la cible mais pas la base, y compris les branches latérales fusionnées. Résolvez les associations PR avant de dédupliquer et de soustraire les enregistrements expédiés ; conservez les exclusions de restauration existantes.
   • inspectez également --since='24 hours ago' lorsque la version principale a bougé pendant la version.

3. Générez l'enregistrement de contribution complet et le manifeste éditorial avant d'écrire la prose groupée :

   node --import tsx .agents/skills/openclaw-changelog-update/scripts/verify-release-notes.mjs \
     --base <base-tag> \
     --target <target-ref> \
     --main-ref origin/main \
     --version <YYYY.M.PATCH> \
     --manifest /tmp/openclaw-release-<YYYY.M.PATCH>.json \
     --write-ledger
   

   Pour la génération bêta, utilisez --version YYYY.M.PATCH-beta.N et omettez --base lors du premier exécution d'inventaire. Commencez une section de version exacte avec les Points forts, Modifications et Correctifs à l'aide du rédacteur partagé ; générez le manifeste delta, puis écrivez la prose pour cette plage uniquement. Les exécutions suivantes utilisent la balise de base npm capturée explicitement (pas seulement le SHA de base de fusion d'une plage divergente). N'interrogez pas npm à nouveau après la publication et n'écrasez pas l'entrée stable cumulative. Régénérez les notes stables cumulatives lors de la préparation stable.

   Ajoutez des entrées --release-provenance '<40sha> -> #PR[, #PR]' répétables lorsque les commits de version ne peuvent pas porter de métadonnées de provenance. Ceux-ci utilisent la même grammaire de marqueur exacte et la même validation principale actuelle que les marqueurs de corps de commit.

   Le vérificateur réutilise automatiquement les réponses publiques GraphQL GitHub d'un instantané exact base/cible SHA sous les métadonnées Git du répertoire de travail. Les réécritures itératives à la même cible évitent la découverte réseau répétée. Utilisez --refresh-github-snapshot après des données API suspectes, --github-snapshot <path> pour un artefact explicite, ou --no-github-snapshot pour un audit en direct uniquement. Les corps de publication GitHub sont toujours lus en direct. Les références explicites CI #, CI run #, Actions run #, et workflow run # dans la source active sont classées séparément uniquement lorsque la résolution problème/PR échoue et qu'une recherche en direct Actions du même référentiel confirme l'ID d'exécution exact. Toute occurrence ordinaire de ce numéro dans la source active, les notes ou l'enregistrement de contribution reste une exigence stricte problème/PR. Les exécutions confirmées apparaissent comme workflowRuns dans la sortie de vérification et le manifeste, jamais comme des associations PR ou un crédit de contributeur. Seules les références GitHub NOT_FOUND confinées au texte contextuel du corps du commit, absentes des sujets, des références de clôture, de la provenance et des notes/enregistrements, et en dessous du nombre résolu le plus élevé peuvent être omises et signalées comme unavailableReferences du manifeste sans crédit.

   • le manifeste est l'entrée requise pour la réécriture, pas un audit après coup ; il contient toutes les PR référencées, le crédit de contributeur éligible, le contexte de problème en ligne, tous les commits directs et une classification d'éligibilité éditoriale pour les PR et les commits directs
   • la version de schéma 3 est le contrat de manifeste éphémère requis. Régénérez les manifestes plus anciens ; la version 2 n'est pas une limite de lecteur en aval prise en charge
   • pour un backfill historique, ajoutez --seed-ref <pre-backfill-ref> une fois que les enregistrements de contribution du journal des modifications précédent sont conservés même lorsqu'un commit fusionné plus ancien a omis son numéro de PR ; le vérificateur exclut les enregistrements pour le travail annulé après la balise de base, y compris le travail bêta annulé avant la version stable
   • les rapports de provenance générés listent les PR dans la plage séparément des PR conservées uniquement comme seed, puis indiquent le total de lignes unique. Une PR présente dans les deux inventaires compte comme dans la plage ; ne décrivez jamais le total incluant les seed comme un travail fusionné dans la plage de version actuelle
   • ajoutez --shipped-ref <prior-shipped-tag> répétable lorsque la clôture principale accessible diffère de la balise expédiée ou des commits de port avant ultérieurs ré-associent des PR qui ont déjà été publiées. Chaque balise est une limite expédiée cumulative : le vérificateur fusionne les lignes PR explicites des enregistrements de contribution complets dans les sections de version numérotées, exclut uniquement les PR qui se chevauchent, et ignore Unreleased. N'inférez jamais cette limite du SHA de base, de la prose cible ou de l'enregistrement cible. Le manifeste et la provenance générée conservent chaque balise plus l'inventaire exact des PR exclues et le nombre pour une validation de candidat déterministe
   • la découverte des PR sources borne les associations de commit GitHub à l'historique cible sélectionné, ou à l'historique principal figé pour les porteurs canoniques. Une référence source contextuelle devient une contribution uniquement lorsque son commit fusionné est accessible dans l'historique cible et que son heure de fusion est dans la cible. Conservez toutes les références résolubles, mais ne promeuvez pas de PR non liées simplement parce qu'elles fusionnent pendant que la préparation de la version continue. Les seeds explicites conservent leur appartenance historique et restent uniquement seed sauf preuve indépendante dans la plage. Résolvez chaque page d'association ; les contrats canoniques, de cherry-pick et de provenance existants restent faisant autorité.
   • les annulations de commits multi-parents explicites nécessitent un sujet d'annulation et une déclaration Reverts <full SHA> and <full SHA>. autonome (les listes séparées par des virgules avec and final fonctionnent également). La fin exacte to restore the previous behavior. est acceptée. Les déclarations dupliquées, abrégées, intégrées ou répétées n'établissent pas d'annulation. Chaque commit nommé doit être un ancêtre à parent unique, et l'application inverse de tous les correctifs nommés doit reproduire l'arbre d'annulation complet. Les déclarations reconnues qui échouent à cette preuve arrêtent la vérification. La preuve utilise le stockage d'index/objet Git privé sans hooks ni diffs externes ; la comptabilité d'annulation unique et d'annulation d'annulation canonique reste intacte.
   • canonisez les backports vers la PR fusionnée d'origine sur main : les origines explicites de cherry-pick gagnent, puis une correspondance de sujet normalisé unique nécessite le même auteur et un chemin modifié qui se chevauche. Supprimez les PR de version/backport chaque fois que la PR principale correspondante existe sur origin/main actuelle. Conservez une PR de branche de version uniquement lorsque cette modification y a atterri en premier et n'a pas encore été portée avant vers main
   • lisez le manifeste avant de modifier ### Highlights, ### Changes, ou ### Fixes ; ne portez pas la prose groupée ancienne sans la ré-auditer
   • inspectez les PR/problèmes liés ou les diffs pour les commits ambigus. Les commits directs sont une entrée éditoriale, pas des lignes de registre public ; inférer les résultats utilisateur matériels à partir du sujet, du corps, des fichiers touchés, des tests et des commits voisins

4. Réécrivez une seule section de version sélectionnée uniquement :

   • bêta : ## YYYY.M.PATCH-beta.N, contenant uniquement les modifications depuis la ligne de base npm bêta capturée
   • stable : ## YYYY.M.PATCH, cumulative depuis la ligne de base stable précédente
   • ne laissez pas une section ## Unreleased obsolète au-dessus de la version cible
   • si Unreleased contient des notes liées à la version, fusionnez-les dans la section cible plutôt que de les supprimer

5. Forme de la section :

   • ### Highlights : 5-8 puces pour stable, 0-8 pour un delta bêta ; n'inventez pas de points forts pour les petites versions bêta de correctif
     • incluez uniquement une capacité ou un déverrouillage de flux de travail clair visible par l'utilisateur, un correctif matériel de fiabilité/sécurité, une amélioration large multi-surface, ou une étape d'intégration/compatibilité définissant la version
     • chaque point fort doit dire ce qui a changé pour un utilisateur en une phrase ; utilisez un cas d'utilisation par puce et regroupez ses PR de support
     • excluez les tests, CI, refontes, documentation, rotation de catalogue et détail d'implémentation sauf si le résultat est une installation/mise à jour, une sécurité des données, ou une amélioration utilisateur largement visible
   • ### Changes : nouvelles capacités et modifications de comportement
   • ### Fixes : correctifs orientés utilisateur en premier, groupés par impact et surface
   • regroupez les modifications/correctifs liés par surface et impact utilisateur ; évitez une puce par petit commit lorsque plusieurs commits racontent une histoire utilisateur
   • ### Complete contribution record : enregistrement généré en premier par PR après la prose groupée ; c'est la surface de comptabilité exhaustive, pas un second résumé de version

6. Préservez l'attribution :

   • conservez #issue, (#PR), Fixes #..., et Thanks @...
   • chaque PR humaine fusionnée représentée par une entrée orientée utilisateur a besoin de sa référence PR et de Thanks @author, même lorsque la PR n'avait pas de problème lié
   • chaque rapporteur humain de problème pour un Fixes #... ou un problème de bogue référencé représenté par une entrée orientée utilisateur a besoin de Thanks @reporter sauf si le même pseudonyme est déjà remercié dans cette puce
   • chaque contributeur humain Co-authored-by sur un travail orienté utilisateur représenté a besoin de Thanks @handle lorsqu'un pseudonyme GitHub est connu
   • lors du regroupement de plusieurs PR/problèmes dans une seule puce, incluez chaque référence PR/problème pertinente et chaque humain