Prompt-Motion/ReaReverse

REA-Changelog-Update

Verwenden Sie dies zur Vorbereitung von Release-Notes und zur Beitragenden-Zuordnung. Lesen Sie docs/releasing.md aus dem Repository-Stammverzeichnis für die Veröffentlichungsautorität und die vorhandenen Prüfpunktprüfungen. Dieses Skill bereitet Notes vor; es autorisiert kein Mergen, Taggen oder Veröffentlichen.

Bestandsaufnahme vor der Prosa

Holen Sie die vollständige Historie und Tags. Wählen Sie den veröffentlichten Basis-Tag aus .release-please-manifest.json auf dem Basis-Branch des Release-PRs und legen Sie dessen genauen SHA als redaktionelles Ziel fest. REA-Tags sind rea-agents-VERSION. Verwenden Sie die vorgeschlagene Version einschließlich ihres Prä-Release-Suffixes; ändern Sie nicht die always-bump-minor-Strategie, um die Kalenderversionen von OpenClaw nachzuahmen.

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

Lesen Sie die Bestandsaufnahme, nicht nur den vorhandenen Bot-Entwurf. Sie enthält Side-Branch-Commits, GitHub-assoziierte PRs, deren Merge-Commits im Bereich liegen, Commit- Autoren/Mitautoren und bestätigte schließende Issues mit deren Reportern. GitHub- Verbindungen werden paginiert. Netzwerkfehler stoppen die Generierung; führen Sie das Skript nach der Wiederherstellung in eine neue Ausgabedatei erneut aus. Vorhandene Ausgabedateien werden nie überschrieben.

Ungelöste Commit-Identitäten werden als Namen/E-Mails mit user: null beibehalten; erraten Sie niemals einen Handle oder danken Sie dem Merger als Ersatz. Der Bericht bewahrt Unbekannte. Dies ist ein überprüfter Metadaten-Snapshot, kein unabhängiger Beweis dafür, dass ein Mensch einen Patch verfasst hat. Für nicht zugeordnete Identitäten, ungewöhnliche Merge-Strategien, Backports, Reverts oder Referenzen, die GitHub nicht verknüpft hat, überprüfen Sie die Quell-PRs und Diffs und melden Sie die Einschränkung. Der aktuelle Collector verwendet bestätigte PR-schließende Beziehungen für Issue-Reporter-Gutschriften; nicht zusammenhängende Issue- Erwähnungen werden nicht automatisch gutgeschrieben. Behaupten Sie nicht, dass lediglich inventarisierte Arbeit nach einem Revert noch ausgeliefert wird.

Für Benutzer schreiben und Gutschriften beibehalten

Schreiben Sie nur den neuesten ## [VERSION]-Abschnitt in CHANGELOG.md um, wobei Sie die Version/Datum/Link-Überschrift beibehalten. Verwenden Sie einzeilige Markdown-Listenelemente unter:

• ### Highlights: Einige wenige benutzerdefinierte Ergebnisse, die die Veröffentlichung definieren; keine Quote für kleine Releases.
• ### Changes: Fähigkeiten und sinnvolle Verhaltensänderungen.
• ### Fixes: Zuverlässigkeits-, Korrektheits-, Kompatibilitäts- und Sicherheitskorrekturen.
• ### ⚠ BREAKING CHANGES: Behalten Sie diese bei, wenn zutreffend, mit Migrationen und Original- PR/Commit-Referenzen, die vom vorhandenen Prüfpunkt-Validator benötigt werden.

Gruppieren Sie verwandte Arbeiten nach Analysten-Workflow oder Benutzerauswirkung. Erklären Sie das resultierende Verhalten in kurzen, konkreten Einträgen. Highlights fassen die Veröffentlichung zusammen; vermeiden Sie es, ihre vollständigen Beschreibungen in Changes zu wiederholen. Interne Bereinigung, Tests, CI und routinemäßige Dokumentation gehören im Allgemeinen nur in die Provenienz-Datei. Lesen Sie mehrdeutige PRs/Diffs, bevor Sie Behauptungen aufstellen. Unterscheiden Sie simulierte Provider-Prüfungen von echten Provider-Verifikationen.

Schreiben Sie jeden vertretenen Beitrag einmal in den öffentlichen Notes gut, mit seinem Link und Danke @... für seinen verifizierten menschlichen Autor, bekannte Mitautoren und bestätigte schließende Issue-Reporter. Die Gruppierung bewahrt alle diese Gutschriften in einer Zeile. Wenn Highlights, detaillierte Einträge oder Migrationen auf dieselbe Arbeit verweisen, setzen Sie deren Dank in einen dieser Einträge, nicht in alle. Fügen Sie Issue-Links hinzu. Direkt-Commit-Aufzählungspunkte tragen den Commit-Link und bekannte menschliche Gutschrift. Schließen Sie GitHub-Bots und bekannte Agenten-Konten aus. REAs beobachtete Anthropic-, Cursor- und Codex-Mitautoren-Trailer lösen zu @claude, @cursoragent und @codex mit GitHub-Typ User auf; die Gutschriftspolitik schließt sie aus, während ihre Metadaten beibehalten werden. Auf Wunsch des REA-Maintainers lassen Sie @morluto-Selbstdanksagungen weg, während die Autorschaft in der Bestandsaufnahme erhalten bleibt. Andere menschliche Beitragende bleiben berechtigt. Verwenden Sie explizite GitHub-Links für Cross-Repository-Referenzen, um mehrdeutige #NNN-Nummern zu vermeiden. Unbekannte Handles bleiben unbekannt; Sie sind keine erfundenen Gutschriften.

Fügen Sie den generierten record --summary-Provenienz-Link wörtlich am Ende dieses Releases an. Die verlinkte Bestandsaufnahme berücksichtigt jeden entdeckten innerhalb des Bereichs liegenden PR und direkten Beitrag, einschließlich interner Arbeiten, die in der Prosa weggelassen wurden. Fügen Sie nicht die vollständige record-Ausgabe in die öffentlichen Notes ein: sie dupliziert Danksagungen und verdeckt die benutzerseitigen Änderungen. Vollständige Datensätze bleiben zur Überprüfung verfügbar. Bearbeiten Sie generierte Gutschriften nicht von Hand, um die Validierung zu bestehen. Aktualisieren Sie die Bestandsaufnahme, wenn sich die Produkthistorie ändert; eine reine Prosa-Korrektur kann den Snapshot wiederverwenden.

Mit Release Please finalisieren

Bevor Sie den Live-Release-PR ändern, haben Sie die Autorisierung für dieses PR-Update. Die lokale Vorbereitung und Validierung können unabhängig voneinander durchgeführt werden.

1. Fügen Sie rea:release-notes-finalized zu dem ausgewählten offenen Release-PR hinzu, bevor Sie seinen Branch/Body bearbeiten. Hauptvorschlags-Pushes respektieren dieses Label. Dies ist unsere Workflow-Sicherung, nicht der autorelease: snooze-Mechanismus von Release Please. Ein bereits laufender Vorschlag muss fertiggestellt werden, bevor Sie bearbeiten. Lösen Sie keine manuelle Vorbereitung über finalisierte Notes aus.

2. Speichern Sie auf diesem Release-Branch die überprüfte Bestandsaufnahme als docs/releases/VERSION.contributions.json. Dies ist eine dauerhafte öffentliche Release- Provenienz, keine temporäre Planungsdatei. Fügen Sie keine Anmeldeinformationen oder lokalen Umgebungsdumps hinzu. Halten Sie die vorhandenen Versionartefakte abgeglichen.

3. Führen Sie den vorhandenen Prüfpunkt-Validator und den neuen Checker aus:

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

   Der Checker unterstützt Inline-PR-Bodies, einschließlich ihrer umgebenden Metadaten, bis zum GitHub-Limit von 65.536 Zeichen. Er schlägt bei größeren Notes fehl, anstatt Gutschriften zu kürzen; die Overflow-Link-Bodies von Release Please sind nicht integriert.

4. Aktualisieren Sie den Release-PR-Body mit dem gerenderten Abschnitt, während Sie dessen Release-Please-Header/Footer und Komponenten-/Versionsstruktur beibehalten. Verwenden Sie eine Body-Datei für gh pr edit --body-file; das Ändern nur der CHANGELOG.md ändert nicht den Release-Body von Release Please. Pushen Sie nur autorisierte Änderungen.

5. Holen Sie den PR-Body frisch in eine Datei und führen Sie check --pr-body DATEI aus. Überprüfen Sie den vollständigen Diff und warten Sie auf das aktuelle CI. Die Veröffentlichung überprüft den Body erneut vor der Release-Erstellung. Vermeiden Sie weitere Body-Bearbeitungen während des Publizierens.

Das Finalisierungs-Label friert Bot-Aktualisierungen ein, nicht den Haupt-Branch. Neue Produktänderungen nach dem Bestandsinventar-Ziel erfordern eine Aktualisierung der Notes vor der Veröffentlichung. Der Workflow überprüft die Ziel-Abstammung und erlaubt nur Release-Metadaten-Pfade nach diesem Ziel. Er erfordert auch, dass das Bestandsinventar-Ziel gleich dem ersten Elternteil des überprüften Merges ist, sodass dazwischenliegende Haupt-Branch-Commits ein frisches Inventar erfordern. Überprüfen Sie Diffs auch innerhalb der erlaubten Release-Metadaten-Pfade: Der Pfadwächter beweist nicht, dass Paketabhängigkeits-/Skriptänderungen nur Versionsänderungen sind. Um automatische Vorschläge wieder aufzunehmen, entfernen Sie das Finalisierungs-Label und lassen Sie den Bot neu generieren; erwarten Sie, dass redaktionelle Änderungen ersetzt werden.

Vorhandene Releases ohne ein Beitragsinventar behalten ihren aktuellen Veröffentlichungspfad bei. Taggen Sie ein Paket nie neu oder veröffentlichen Sie es erneut, um Release-Prosa zu korrigieren.