Mise à jour du changelog REA
Utilisez ceci pour la préparation des notes de version et l'attribution des contributeurs. Lisez docs/releasing.md à la racine du dépôt pour l'autorité de publication et les vérifications des points de contrôle existants. Cette compétence prépare les notes ; elle n'autorise pas la fusion, le marquage ou la publication.
Inventaire avant la prose
Récupérez l'historique complet et les tags. Sélectionnez le tag de base publié depuis
.release-please-manifest.json sur la branche de base de la PR de version, et épinglez
le SHA exact de cette branche comme cible éditoriale. Les tags REA sont rea-agents-VERSION.
Utilisez la version proposée, y compris son suffixe de pré-version ; ne modifiez pas la
stratégie always-bump-minor pour imiter les versions de calendrier d'OpenClaw.
node scripts/release-notes.mjs inventory \
--repository morluto/rea --base rea-agents-PREVIOUS \
--target FULL_BASE_BRANCH_SHA --version VERSION \
--manifest /tmp/rea-VERSION.contributions.json
node scripts/release-notes.mjs record \
--manifest /tmp/rea-VERSION.contributions.json \
--summary \
--output /tmp/rea-VERSION.record.md
Lisez l'inventaire, pas seulement le brouillon existant du bot. Il inclut les commits sur les branches secondaires, les PR GitHub associées dont les commits de fusion sont dans la plage, auteurs/co-auteurs de commits, et les issues fermées confirmées avec leurs rapporteurs. Les connexions GitHub sont paginées. Les erreurs réseau arrêtent la génération ; relancez dans un nouveau fichier de sortie après la récupération. Les fichiers de sortie existants ne sont jamais écrasés.
Les identités de commit non résolues sont conservées en tant que noms/emails avec user: null ;
ne devinez jamais un identifiant ou remerciez le fusionneur à la place. Le rapport préserve les
inconnus. Ceci est un instantané de métadonnées révisé, pas une preuve indépendante qu'un humain
a écrit un patch. Pour les identités non attribuées, les stratégies de fusion inhabituelles, les
backports, les réversions, ou les références que GitHub n'a pas associées, inspectez
les PR sources et les diffs et signalez la limitation. Le collecteur actuel utilise
les relations confirmées de fermeture de PR pour créditer le rapporteur d'issue ; les mentions d'issues sans rapport
ne sont pas automatiquement créditées. N'affirmez pas que le travail simplement inventorié
est toujours livré après une réversion.
Écrivez pour les utilisateurs et conservez le crédit
Réécrivez uniquement la section la plus récente ## [VERSION] dans CHANGELOG.md, en conservant son
en-tête de version/date/lien. Utilisez des éléments de liste Markdown sur une seule ligne sous :
### Points forts: quelques résultats utilisateur définissant la version ; pas de quota pour les petites versions.### Changements: capacités et changements de comportement significatifs.### Corrections: correctifs de fiabilité, d'exactitude, de compatibilité et de sécurité.### ⚠ CHANGEMENTS RADICAUX: conservez si applicable, avec des migrations et les références originales de PR/commit requises par le validateur de point de contrôle existant.
Regroupez les travaux connexes par flux de travail d'analyste ou impact utilisateur. Expliquez le comportement résultant en entrées courtes et concrètes. Les points forts résument la version ; évitez de répéter leurs descriptions complètes dans les Changements. Le nettoyage interne, les tests, l'IC, et la documentation de routine appartiennent généralement uniquement au fichier de provenance. Lisez les PRs/diffs ambigus avant de faire des affirmations. Distinguez les vérifications de fournisseur simulé de la vérification de fournisseur réel.
Créditez chaque contribution représentée une fois dans les notes publiques avec son lien
et Merci @... pour son auteur humain vérifié, les co-auteurs connus, et les rapporteurs confirmés
fermant l'issue. Le regroupement préserve tous ces crédits dans une seule ligne.
Lorsque les points forts, les entrées détaillées ou les migrations font référence au même travail,
mettez ses remerciements dans une de ces entrées, pas dans toutes. Incluez les liens d'issues.
Les puces de commit direct portent le lien du commit et le crédit humain connu.
Excluez les bots GitHub et les comptes agents connus. Les bandes-annonces de co-auteurs observées chez Anthropic, Cursor,
et Codex pour REA se résolvent en @claude, @cursoragent et @codex
avec le type GitHub User ; la politique de crédit les exclut tout en conservant leurs métadonnées.
À la demande du mainteneur REA, omettez les auto-remerciements de @morluto tout en préservant la paternité
dans l'inventaire. Les autres contributeurs humains restent éligibles.
Utilisez des liens GitHub explicites pour les références inter-dépôts afin d'éviter les numéros #NNN
ambigus. Les identifiants inconnus restent inconnus ; ils ne sont pas des crédits fabriqués.
Ajoutez le lien de provenance record --summary généré textuellement à la fin
de cette version. L'inventaire lié rend compte de chaque PR découverte dans la plage
et contribution directe, y compris le travail interne omis de la prose.
Ne collez pas la sortie complète de record dans les notes publiques : elle duplique les remerciements
et obscurcit les changements visibles par l'utilisateur. Les enregistrements complets restent disponibles pour révision.
Ne modifiez pas manuellement les crédits générés pour faire passer la validation. Rafraîchissez l'inventaire
lorsque l'historique du produit change ; une correction en prose uniquement peut réutiliser l'instantané.
Finalisez avec Release Please
Avant de modifier la PR de version en cours, ayez l'autorisation pour cette mise à jour de PR. La préparation locale et la validation peuvent se dérouler indépendamment.
-
Ajoutez
rea:release-notes-finalizedà la PR de version ouverte sélectionnée avant de modifier sa branche/corps. Les propositions principales respectent ce label. C'est notre garde de flux de travail, pas le mécanismeautorelease: snoozede Release Please. Une proposition déjà en cours doit se terminer avant la modification. Ne déclenchez pas de préparation manuelle sur des notes finalisées. -
Sur cette branche de version, enregistrez l'inventaire révisé sous
docs/releases/VERSION.contributions.json. C'est une provenance de version publique durable, pas un fichier de planification temporaire. N'ajoutez pas d'identifiants ou de vidages d'environnement local. Gardez les artefacts de version existants alignés. -
Exécutez le validateur de point de contrôle existant et le nouveau vérificateur :
node scripts/release-notes.mjs check \ --manifest docs/releases/VERSION.contributions.json node scripts/release-notes.mjs render \ --manifest docs/releases/VERSION.contributions.json \ --output /tmp/rea-VERSION.notes.mdLe vérificateur prend en charge les corps de PR en ligne, y compris leurs métadonnées environnantes, jusqu'à la limite de 65 536 caractères de GitHub. Il échoue sur les notes plus volumineuses plutôt que de tronquer le crédit ; les corps de lien de débordement de Release Please ne sont pas intégrés.
-
Mettez à jour le corps de la PR de version avec la section rendue tout en préservant son en-tête/pied de page Release Please et la structure composant/version. Utilisez un fichier de corps pour
gh pr edit --body-file; modifier uniquementCHANGELOG.mdne modifie pas le corps de version de Release Please. Ne poussez que des modifications autorisées. -
Récupérez à nouveau le corps de la PR dans un fichier et exécutez
check --pr-body FILE. Examinez le diff complet et attendez l'IC en cours. La publication vérifie le corps à nouveau avant la création de la version. Évitez d'autres modifications du corps pendant la publication.
Le label de finalisation gèle les rafraîchissements du bot, pas la branche principale. Les nouveaux changements de produit après la cible de l'inventaire nécessitent de rafraîchir les notes avant la publication. Le flux de travail vérifie l'ascendance de la cible et autorise uniquement les chemins de métadonnées de version après cette cible. Il exige également que la cible de l'inventaire soit égale au premier parent de la fusion révisée, donc les commits principaux intervenants nécessitent un nouvel inventaire. Examinez les diffs dans les chemins de métadonnées de version autorisés également : le garde de chemin ne prouve pas que les modifications de dépendance de package/script sont uniquement des changements de version. Pour reprendre les propositions automatiques, retirez le label de finalisation et laissez le bot régénérer ; attendez-vous à ce que les modifications éditoriales soient remplacées.
Les versions existantes sans inventaire de contribution conservent leur chemin de publication actuel. Ne re-taguez ni ne republiez jamais un package pour corriger la prose de version.