---
title: "Jak działa /monolynx:sprint-end: zamknięcie sprintu, po którym wiedza zostaje w wiki"
description: "Jak skill /monolynx:sprint-end zamyka sprint: wiedza z logów agentów trafia do wiki, potem testy mutacyjne, retro, numer wydania i potwierdzone zamknięcie."
url: "https://monolynx.com/blog/jak-dziala-monolynx-sprint-end"
lang: "pl"
author: "Zespół Monolynx"
published: "2026-10-08T07:15:03.423265+00:00"
modified: "2026-10-09T10:35:21.584962+00:00"
last_verified: "2026-10-08"
tags: ["plugin", "claude-code", "agenci-ai", "scrum", "sprint"]
translations: []
reading_time_minutes: 9
word_count: 1673
---

> [!TLDR]
> - Skill zamyka sprint w dwóch etapach: najpierw przenosi wiedzę z logów agentów do wiki, potem domyka sprint.
> - Logi pracy są kasowane dopiero po udanym przeniesieniu wiedzy. Po nieudanym zostają nietknięte.
> - Testy mutacyjne, retro i numer wydania są opcjonalne i nigdy nie blokują zamknięcia.
> - Samo zamknięcie sprintu jest nieodwracalne, więc zawsze wymaga Twojego potwierdzenia.

## Co się dzieje, gdy sprint się kończy?

Sprint prowadzony przez agentów AI zostawia po sobie dużo materiału: raporty Researchera, logi developerów, oceny krytyka. Na każdy ticket przypada kilka stron logów w wiki. Bez porządków ta wiedza albo ginie, albo zaśmieca wyszukiwanie.

Skill `sprint-end` z pluginu Monolynx dla Claude Code robi z zamknięcia sprintu powtarzalną procedurę. Argumentem jest nazwa sprintu. Bez argumentu skill bierze sprint aktywny, a gdy aktywnych jest kilka, pyta, który zamknąć.


**Zamknięcie aktywnego sprintu**

```console
$ claude
> /monolynx:sprint-end
```



**Statystyki**

- **2** - etapy: aktualizacja wiki i zamknięcie
- **8** - zadań w całym przebiegu, z czego trzy opcjonalne
- **600 s** - budżet testów mutacyjnych na jeden moduł
- **1** - potwierdzenie wymagane przed nieodwracalnym krokiem


Cały przebieg jest widoczny w module Pipelines jako pipeline typu `sprint_close`, z osobnym wpisem dla każdego zadania.

## Dwa etapy, osiem zadań

Przebieg ma stałą kolejność, a zadania idą po sobie, nigdy równolegle. Kolejność nie jest przypadkowa: każde zadanie stoi przed tym, które mogłoby mu odebrać dane.


**Kroki**

1. **wiki-ingest** Wiedza z logów pracy agentów trafia na strony wiki: encje, pojęcia, linki między stronami, katalog i dziennik.
2. **wiki-lint** Audyt wiki szuka stron osieroconych, martwych linków i sprzeczności.
3. **wiki-clean** Strony logów sprintu są usuwane, bo ich treść jest już w wiki.
4. **mutation-run** Opcjonalny przebieg testów mutacyjnych na modułach rdzenia.
5. **retro** Opcjonalne retro: powtarzające się uwagi krytyka stają się regułami.
6. **version-bump** Warunkowe nadanie numeru wydania pluginu.
7. **close-sprint** Faktyczne zamknięcie sprintu, po potwierdzeniu.
8. **summary** Podsumowanie całego przebiegu.


Dwa etapy odpowiadają dwóm kolumnom pipeline'u w panelu. Etap pierwszy, aktualizacja wiki, to zadania 1-3. Etap drugi, domknięcie, to zadania 4-8.

> [!NOTE]
> Przeniesienie wiedzy wymaga włączonej metody LLM Wiki. W projekcie bez niej `wiki-ingest` kończy się informacją, że trzeba najpierw uruchomić `/monolynx:wiki-init`, logi sprintu zostają nietknięte, a sprint nadal można zamknąć.


**Przebieg skilla sprint-end**

Przebieg zaczyna się od przeniesienia wiedzy z logów do wiki. Udane przeniesienie prowadzi przez audyt wiki do usunięcia logów, a nieudane omija usuwanie i zostawia logi. Potem idą trzy zadania opcjonalne: testy mutacyjne, retro i numer wydania. Na końcu skill pyta o potwierdzenie, zamyka sprint i pisze podsumowanie.

```mermaid
flowchart TD
  A[Sprint do zamknięcia] --> B[wiki-ingest]
  B --> C[wiki-lint]
  C --> D{Ingest udany?}
  D -->|tak| E[wiki-clean]
  D -->|nie| F[Logi zostają]
  E --> G[mutation-run]
  F --> G
  G --> H[retro]
  H --> I[version-bump]
  I --> J{Potwierdzenie}
  J -->|tak| K[close-sprint]
  J -->|nie| L[Sprint zostaje otwarty]
  K --> M[summary]
```



**Porównanie**

| Zadanie | Charakter | Co je zatrzymuje |
| --- | --- | --- |
| wiki-ingest | zawsze | nic, błąd jest tylko odnotowany |
| wiki-lint | zawsze | decyzje człowieka przy sprzecznościach |
| wiki-clean | tylko po udanym ingest | nieudany ingest |
| mutation-run | opcjonalne | odmowa albo brak konfiguracji |
| retro | opcjonalne | odmowa |
| version-bump | warunkowe | brak pluginu albo brak zmian do wydania |
| close-sprint | zawsze, po zgodzie | brak potwierdzenia |
| summary | zawsze | nic |


## Dlaczego kolejność w wiki ma znaczenie?

Etap wiki ma jedną twardą regułę: logów nie wolno skasować, dopóki ich treść nie trafiła do wiki. Strony logów są jedynym zapisem tego, co agenci ustalili podczas pracy nad ticketami.

> [!WARNING]
> Zadanie `wiki-clean` trwale usuwa strony logów sprintu. Skill wykonuje je tylko wtedy, gdy `wiki-ingest` zakończył się sukcesem. Po nieudanym przeniesieniu wiedzy czyszczenie jest pomijane, a w podsumowaniu pojawia się informacja, że logi zostały zachowane.

Audyt wiki stoi pośrodku z prostego powodu. Świeżo dopisane strony mogą przeczyć starszym, a rozstrzygnięcie sprzeczności bywa decyzją człowieka. Skill czeka wtedy na odpowiedź, zamiast wybierać wersję samodzielnie.

> Nigdy nie czyść logów po nieudanym ingeście. Inaczej skasujesz jedyne źródło wiedzy ze sprintu.
> -- skill sprint-end, ważne zasady

## Testy mutacyjne jako trend, nie bramka

Przebieg mutacyjny odpowiada na pytanie, czy testy faktycznie wykrywają błędy w najważniejszych modułach. Skill go proponuje, ale nigdy nie odpala sam. Konfigurację czyta ze strony wiki `toolchain`, a gdy jej nie ma, pomija zadanie jedną linią w podsumowaniu.

Wynik każdego modułu i wiersz zbiorczy trafiają na stronę wiki "Trend mutacji". Tabela tylko rośnie: skill dopisuje wiersze na końcu i nie poprawia historii.


**Przykładowy trend mutation score i baseline**

| Sprint | Wynik | Baseline |
| --- | --- | --- |
| Sprint 1 | 62.0 | 62.0 |
| Sprint 2 | 68.0 | 68.0 |
| Sprint 3 | 66.5 | 68.0 |
| Sprint 4 | 71.4 | 71.4 |


Baseline działa jak zapadka. Lepszy wynik podnosi punkt odniesienia, gorszy go nie rusza. W przykładzie widać to w trzecim sprincie: wynik spadł, a baseline został na poprzednim poziomie.


**Porównanie**

| Sytuacja | Co robi skill |
| --- | --- |
| Baseline jeszcze nie istnieje | zapisuje wynik jako pierwszy baseline |
| Wynik wyższy od baseline | zapisuje nowy baseline |
| Wynik równy albo niższy | niczego nie zapisuje, pokazuje spadek |


Punkt odniesienia jest jedną linią na stronie `toolchain`:

```text title="Linia baseline na stronie toolchain"
baseline: 71.4% (2026-10-08)
```


**Co zawiera strona Trend mutacji**

| Kolumna | Znaczenie |
| --- | --- |
| data | dzień przebiegu |
| moduł | ścieżka modułu rdzenia albo wiersz zbiorczy "razem" |
| score | odsetek zabitych mutantów albo opis błędu modułu |
| baseline | punkt odniesienia sprzed tego przebiegu |
| delta | różnica wyniku i baseline w punktach procentowych |

Wiersz zbiorczy liczy sumę zabitych mutantów przez sumę wszystkich, tylko z modułów, które dały wynik. Błąd jednego modułu nie przerywa przebiegu pozostałych.


> [!NOTE]
> Spadek wyniku nie zatrzymuje sprintu i nie jest błędem zadania. Zadanie kończy się porażką tylko wtedy, gdy żaden moduł nie dał wyniku.

## Retro i numer wydania przed zamknięciem

Dwa kolejne zadania stoją przed zamknięciem sprintu z konkretnych powodów.

### Retro

Skill pyta, czy uruchomić retro korekt. Retro zbiera uwagi krytyka, zatrzymania i eskalacje z komentarzy ticketów, grupuje te, które się powtarzają, i proponuje dla nich trwałe reguły.

Musi iść przed zamknięciem, bo zamknięcie wypisuje niedokończone tickety ze sprintu do backlogu. A właśnie te tickety niosą najwięcej materiału: eskalacje i oceny poniżej progu. Po zamknięciu lista ticketów sprintu już by ich nie zwróciła.

### Numer wydania

Zadanie `version-bump` dotyczy repozytoriów, które wydają plugin. Tickety sprintu dopisują swoje zmiany do changelogu pod nagłówkiem "Unreleased" i nie ruszają numeru wersji. Numer nadaje dopiero zamknięcie sprintu.


**Porównanie**

| Rodzaj | Kiedy | Przykład |
| --- | --- | --- |
| minor | od ostatniego wydania doszedł nowy skill, hook albo skrypt | 1.24.0 na 1.25.0 |
| patch | same poprawki i zmiany istniejących skilli | 1.24.0 na 1.24.1 |


Skill przygotowuje wydanie w osobnym katalogu roboczym, na osobnym branchu, i sprawdza je walidatorem. Twój checkout zostaje nietknięty. Commit, push i merge request powstają tylko przy włączonych flagach, tak jak w skillu opisanym we wpisie [jak działa /monolynx:work](https://monolynx.com/blog/jak-dziala-monolynx-work).

> [!TIP]
> Projekt bez pluginu albo bez zmian czekających na wydanie nie dostaje żadnego pytania. Zadanie jest pomijane, a w podsumowaniu zostaje jedna linia z powodem.

## Zamknięcie, którego nie da się cofnąć

Zamknięcie sprintu jest jedynym krokiem w tym etapie, którego nie odwróci żadna komenda. Niedokończone tickety wracają do backlogu i tracą przypisanie do sprintu.


**Pytanie przed zamknięciem sprintu**

```console
Zamykam sprint "Blog". Niedokończone tickety wrócą do backlogu. Kontynuować?
  1. Tak, zamknij sprint
  2. Nie, przerwij
```


Odpowiedź "nie" kończy przebieg bez zamykania sprintu. Praca wykonana wcześniej zostaje: wiki jest zaktualizowana, trend dopisany.

> [!IMPORTANT]
> Raportowanie do modułu Pipelines nie jest bramką. Błąd zapisu do pipeline'u nigdy nie przerywa zamknięcia sprintu, a na serwerze bez modułu Pipelines skill wykonuje całą pracę bez raportowania[^pipelines].

Podsumowanie na końcu zbiera wszystko w jednym miejscu: wynik przeniesienia wiedzy i audytu, liczbę usuniętych stron logów, wynik testów mutacyjnych, zapisane reguły z retro i numer wydania.

## Najczęstsze pytania

Pytania poniżej dotyczą sytuacji, które zdarzają się przy pierwszym zamknięciu sprintu skillem.


**FAQ**

### Co, jeśli przeniesienie wiedzy do wiki się nie powiedzie?
Skill odnotowuje błąd, pomija kasowanie logów i idzie dalej. Logi zostają w wiki, więc przeniesienie można powtórzyć później.

### Czy muszę uruchamiać testy mutacyjne?
Nie. Skill pyta, a odpowiedź "nie" pomija zadanie. Projekt bez skonfigurowanego narzędzia nie dostaje nawet pytania.

### Co dzieje się z niedokończonymi ticketami?
Wracają do backlogu i przestają należeć do sprintu. Dlatego skill ostrzega przed zamknięciem i czeka na potwierdzenie.

### Czy słabszy wynik mutacji obniży baseline?
Nie. Baseline może tylko rosnąć. Spadek jest widoczny w tabeli trendu jako ujemna delta, ale punktu odniesienia nie zmienia. Etap CI na merge requestach ma osobną wartość bazową w pliku `cicd/mutation-baseline.json`; opisuje ją wpis [Graf kodu i testy mutacyjne](https://monolynx.com/blog/graf-kodu-i-testy-mutacyjne).

### Czy mogę zamknąć sprint inny niż aktywny?
Tak. Podaj jego nazwę jako argument. Gdy skill nie znajdzie sprintu o takiej nazwie, wypisuje dostępne sprinty i kończy bez zmian.


## Słownik i następny krok

Pojęcia z tego wpisu, w jednym miejscu:


**Słownik**

- **Ingest** - przeniesienie wiedzy ze źródła do stron wiki, z linkami i wpisem w dzienniku
- **Lint wiki** - audyt spójności wiki: strony osierocone, martwe linki, sprzeczności
- **Test mutacyjny** - sprawdzenie, czy testy wykryją celowo wprowadzoną zmianę w kodzie
- **Baseline** - punkt odniesienia dla wyniku mutacji, który może tylko rosnąć
- **Moduły rdzenia** - uzgodniona lista najważniejszych modułów mierzonych w trendzie
- **Retro** - przegląd powtarzających się korekt ze sprintu, zakończony regułami


Sprint, który zamykasz, wcześniej przerabiają tickety pisane skillem z wpisu [jak działa /monolynx:ticket-create](https://monolynx.com/blog/jak-dziala-monolynx-ticket-create).


**Wezwanie do działania**

Każde zamknięcie sprintu zostawia ślad w module Pipelines: etapy, zadania i ich logi. Zobacz, jak wygląda taki przebieg.

[Poznaj moduł Pipelines w Monolynx](https://monolynx.com/features/pipelines)


[^pipelines]: Przeniesienie wiedzy, audyt, czyszczenie logów, przebieg mutacyjny i zamknięcie sprintu korzystają z narzędzi wiki i sprintów, a nie z modułu Pipelines.