--- name: repo-recon description: Rozpoznanie repozytorium przed zmianą - ustalenie systemu budowania, menedżera zależności, komendy testowej, miejsc użycia biblioteki i realnego promienia rażenia zmiany. Użyj zawsze jako pierwszy krok migracji, upgrade'u SDK lub większego refaktoru. license: Apache-2.0 metadata: owner: pubi-platform version: "1.0.0" --- # Rozpoznanie repozytorium Celem jest **fakt, nie domysł**. Każde stwierdzenie w raporcie musi wynikać z odczytanego pliku lub wyniku wyszukiwania. ## Procedura 1. **System budowania i menedżer zależności** - sprawdź w tej kolejności: `pyproject.toml`, `requirements*.txt`, `setup.cfg`, `pom.xml`, `build.gradle*`, `package.json`, `go.mod`. Zanotuj plik, który realnie deklaruje wersję biblioteki (może być więcej niż jeden - np. `pyproject.toml` + `constraints.txt`). 2. **Aktualna wersja pakietu** - odczytaj dosłownie zapis wersji (`==`, `~=`, `^`, zakres). Zapis ma znaczenie: `~=1.4` migruje się inaczej niż `==1.4.2`. 3. **Miejsca użycia** - `search_repo` po nazwie modułu importu (uwaga: nazwa pakietu dystrybucyjnego bywa inna niż nazwa modułu, np. `acme-sdk` -> `import acme`). Zbierz: pliki, symbole (klasy, metody), liczbę wystąpień. 4. **Komenda weryfikacji** - znajdź jak repozytorium się testuje: sekcja `[tool.pytest.ini_options]`, `Makefile`, `tox.ini`, `.gitlab-ci.yml` (tylko do odczytu!). Jeśli brak - zaraportuj brak, nie wymyślaj komendy. 5. **Promień rażenia** - oceń, czy użycia są skupione w warstwie adaptera (niskie ryzyko), czy rozlane po kodzie domenowym (wysokie ryzyko). ## Wynik Zwróć strukturę zgodną ze schematem `RepoProfile`. Pola, których nie udało się ustalić, oznaczaj jako `null` i wypisz w `gaps` - to sygnał dla planisty, że potrzebna jest decyzja człowieka. ## Antywzorce - Zgadywanie komendy testowej ("pewnie pytest") - jeśli nie ma dowodu, wpisz `gaps`. - Pomijanie plików lock (`poetry.lock`, `package-lock.json`) - one też pinują wersję. - Raportowanie użyć na podstawie samej nazwy pakietu bez sprawdzenia aliasów importu.