1.7 KiB
1.7 KiB
name, description, license, metadata
| name | description | license | metadata | ||||
|---|---|---|---|---|---|---|---|
| merge-request-authoring | Redagowanie tytułu i opisu merge requesta dla zmiany wykonanej przez agenta - struktura opisu, informacja o ryzyku, ślad audytowy i lista kontrolna dla recenzenta. Użyj na końcu przebiegu, gdy zmiana jest gotowa do publikacji. | Apache-2.0 |
|
Opis merge requesta
Odbiorcą jest człowiek, który bierze odpowiedzialność za merge. Opis ma mu pozwolić podjąć decyzję bez czytania całego diffa.
Tytuł
Conventional Commits, tryb rozkazujący, bez kropki na końcu, maks. 72 znaki:
build(deps): podniesienie acme-sdk 1.4.2 -> 2.1.0 wraz z migracją API
Struktura opisu
## Co i dlaczego
2-4 zdania. Cel zmiany i skąd przyszło zadanie (issue / harmonogram / audyt zależności).
## Zakres zmian
- `ścieżka/pliku.py` - co konkretnie zmienione
(tylko pliki realnie w diffie)
## Weryfikacja
Komenda, wynik, liczba testów. Wklej istotny fragment logu.
## Ryzyko i ograniczenia
Co może się zepsuć na produkcji, czego agent NIE zweryfikował,
elementy oznaczone jako `requires_human`.
## Ślad audytowy
ID przebiegu, wersje pakietów kontekstowych (apm.lock.yaml), użyte modele, liczba iteracji.
## Lista kontrolna dla recenzenta
- [ ] Diff nie zawiera zmian spoza zakresu
- [ ] Brak zmian w testach maskujących błąd
- [ ] Wersja zależności zgodna z zadaniem
Zasady
- Zero marketingu. Bez "successfully", "seamlessly", "comprehensive".
- Nie zgaduj wyników. Cytuj wyłącznie realny log weryfikacji.
- Nazywaj to, czego nie wiesz. Sekcja o ryzyku jest ważniejsza niż lista zmian.
- Nigdy nie cytuj sekretów ani fragmentów danych produkcyjnych z logów.