Prompty

Tryb domyślny: zwięźle. Zakładaj doświadczonego użytkownika.

- Bez wstępów, podsumowań i powtarzania pytania.
- Punkty lub krótkie fragmenty. Wyjaśniaj tylko na prośbę.

# Pliki
- Nie czytaj plików bez wyraźnej prośby.
- Gdy musisz — Grep/Glob najpierw, potem wąski zakres (offset/limit). Nigdy całego pliku.
- Nie czytaj ponownie tego, co już czytałeś w tej sesji.
- Nigdy nie streszczaj mi plików.

# Odpowiedzi
- Nie pokazuj kodu, który właśnie zapisałeś — wystarczą zmiany (diff).
- Nie wklejaj długich wyników komend: wynik + max 3 istotne linie.
- Błąd: tylko istotna linia + komunikat.
- Bez tabel porównawczych i list opcji, jeśli nie proszę o wybór.

# Decyzje
- Oczywisty domyślny wybór → podejmij go i napisz jednym zdaniem. Nie pytaj.
- Pytaj tylko gdy zła odpowiedź oznacza wyrzucenie pracy.
- Nie spekuluj o przyczynie błędu bez dowodu (log/test).
- Nie ponawiaj więcej niż raz bez pytania.

# Kod
- Minimalne działające rozwiązanie, bez komentarzy.
- Zadanie >3 kroków: plan max 5 punktów, potem wykonanie. Raport na końcu, nie po każdym kroku.

# Testy
- Najpierw najwęższy wybór (--filter / -k / jeden plik). Pełny zestaw testów dopiero przed commitem.

# Subagenci
- Krótkie polecenie, bez przenoszenia kontekstu.
- Model Haiku do: zmian nazw, formatowania, powtarzalnego kodu szablonowego, wyszukiwania, zadań mechanicznych.
- Wszystko, co wymaga przeszukania wielu plików → subagent.

# Narzędzia
- Zmiany w istniejących plikach przez Edit (fragment), nie przez przepisywanie całego pliku.
- Po edycji nie czytaj pliku ponownie w celu sprawdzenia.
- Niezależne wywołania narzędzi w jednej wiadomości, nie po kolei.
- Komendy z długim wynikiem: tryb cichy (-q, --silent) albo filtr (grep, tail), zanim wynik trafi do kontekstu.
- Nie szukaj w internecie, jeśli odpowiedź jest w kodzie albo w dokumentacji projektu.
- Skille i narzędzia MCP ładuj tylko wtedy, gdy zadanie ich faktycznie wymaga.

# Zakres
- Rób tylko to, o co proszę. Bez refaktoryzacji „przy okazji”, dodatkowych plików, testów czy dokumentacji bez prośby.
- Pytanie → odpowiedź. Bez alternatyw i „możesz też…”, jeśli nie proszę.

Zbuduj mi globalny rejestr moich projektów Claude Code, żebym wiedział, co i gdzie mam, niezależnie od katalogu, z którego uruchamiam Claude. Windows, PowerShell 5.1 (bez zależności: bez modułów, bez Node/Pythona).

Najpierw zapytaj mnie o dwie rzeczy: gdzie ma leżeć rejestr (<ROOT>, np. D:\Projekty\.claude-registry — wspólny dla wszystkich kont Windows na tym komputerze) i w jakich katalogach trzymam projekty. Potem wykonaj wszystko bez dalszych pytań.

## 1. Format wpisów
Jeden plik .md na wpis, frontmatter `klucz: wartość` między liniami `---`, listy jako `[a, b]`, komentarze po ` #`. Pod frontmatterem 2–3 zdania: co to jest i do czego służy. Slug = nazwa pliku (małe litery, myślniki). Daty YYYY-MM-DD.
- projects/<slug>.md: name, path (pełna ścieżka katalogu), user (konto Windows), stack [..], servers [slugi z servers/], status (active|paused|archived), updated
- integrations/<slug>.md (MCP, deploy, cron, service, webhook): name, type, mcp (dla type: mcp — nazwa serwera dokładnie jak w konfiguracji), host (local albo slug serwera), user, installed_by (slug projektu), config_path, status (used|unused|removed), remove (komenda usuwająca), updated
- servers/<slug>.md: name, host, ssh (np. `ssh ovh`), provider, status, updated
- README.md w <ROOT> z tym formatem i przykładem każdego typu.
- NIGDY nie zapisuj sekretów (tokeny, hasła, klucze API, wartości env, nagłówki Authorization) — najwyżej ścieżkę, gdzie leżą.

## 2. bin/build.ps1
- Da się go uruchomić bezpośrednio i dołączyć przez dot-sourcing (`. build.ps1`); przy dot-sourcingu nic nie wykonuje (`if ($MyInvocation.InvocationName -ne '.')`). Eksportuje funkcje Get-Registry i Build-Registry.
- Własny parser frontmattera (bez modułów YAML); ścieżki względem `Split-Path -Parent $PSScriptRoot`.
- Na początku `Remove-TypeData System.Array -ErrorAction SilentlyContinue` (inaczej ConvertTo-Json w PS 5.1 psuje tablice).
- Dla każdego projektu:
  - `missing: true`, gdy katalog z path nie istnieje;
  - `last_used` = najnowszy LastWriteTime dowolnego pliku (rekurencyjnie) w `C:\Users\*\.claude\projects\<enc>`, dla wszystkich kont, z pominięciem katalogów bez dostępu (try/catch). `<enc>` = path bez końcowego `\`, w którym każdy znak spoza [A-Za-z0-9] zamieniasz na `-` (np. `C:\Users\jan\Projekty\Moja Apka` → `C--Users-jan-Projekty-Moja-Apka`). Format `yyyy-MM-dd HH:mm`.
- Sortowanie projektów: najpierw te z last_used (malejąco), potem bez niego (alfabetycznie po slugu).
- Wynik: `{projects, integrations, servers, generated}` jako JSON wstrzyknięty do bin/template.html w miejsce `/*DATA*/null` (w JSON zamień `</` na `<\/`), zapis do <ROOT>\index.html w UTF-8 bez BOM, atomowo (plik tymczasowy + File.Replace).
- Wypisuje: `<ścieżka>: N projektów, N integracji, N serwerów`.

## 3. bin/template.html
Jeden plik, zero zewnętrznych zasobów, działa z file://. `const D=/*DATA*/null;`. Zakładki Projekty/Integracje/Serwery (stan w location.hash), wyszukiwarka pełnotekstowa, filtr po user i status (+ opcja „brak katalogu”, gdy jakiś projekt ma missing). Karty z kotwicami `#<typ>/<slug>` i linkami krzyżowymi: projekt → jego serwery i integracje (po installed_by), integracja → host i projekt, serwer → projekty i integracje. Na karcie projektu: ścieżka (wyróżniona czerwono, gdy missing), stack jako tagi, user, „ostatnio użyty” (last_used), „aktualizacja” (updated), opis. Jasny i ciemny motyw (prefers-color-scheme). Wszystkie wartości escapowane przed wstawieniem do HTML.

## 4. bin/check.ps1 — hook SessionStart
- Pierwsze linie: `$ErrorActionPreference='Stop'`, `[Console]::InputEncoding` i `[Console]::OutputEncoding` = UTF8 bez BOM, dot-source build.ps1. Całość w `try { Main } catch {}` — hook nigdy nie może wywalić sesji.
- cwd czyta z JSON-a na stdin (`[Console]::In.ReadToEnd() | ConvertFrom-Json`, pole cwd), fallback Get-Location.
- Wywołuje Build-Registry (przy błędzie Get-Registry), więc index.html odświeża się przy każdym starcie sesji.
- Dopasowuje cwd do projektu po najdłuższym prefiksie path (porównanie po GetFullPath, bez końcowego `\`, lowercase).
- Komunikaty:
  - dopasowany projekt → „Ten katalog to projekt '<slug>' (<plik>)”. Jeśli path ma .git i jest git: `git -C <path> rev-list --count --since=<updated> HEAD` ≥ 20 → poproś o przegląd opisu albo podbicie updated;
  - brak dopasowania i katalog nieignorowany → „Katalog X nie jest zarejestrowany. Jeśli to projekt, gdy go poznasz w tej sesji, dodaj wpis wg <ROOT>\README.md (user: $env:USERNAME), bez pytania i bez komentowania tego użytkownikowi. Wpisz też jego integracje/serwery.”;
  - rozjazd MCP: skonfigurowane = klucze `mcpServers` w `%USERPROFILE%\.claude.json` (globalne oraz w `projects.<ścieżka>.mcpServers`) + `.mcp.json` w cwd i w katalogu projektu. Plik .claude.json bywa duży → parsuj przez `System.Web.Script.Serialization.JavaScriptSerializer` z MaxJsonLength = int.MaxValue. Zgłoś serwery bez wpisu w integrations/ (type: mcp, user = bieżące konto, dopasowanie po polu mcp albo slugu) oraz wpisy z config_path wskazującym .claude.json, których nie ma już w konfiguracji (→ ustaw status: removed).
- Ignorowane (bez przypomnienia o rejestracji): katalog domowy, Downloads, Desktop, Documents, katalog nadrzędny <ROOT>, sam dysk (`X:`), dokładnie; prefiksowo: TEMP, Windows, Program Files (oba), <ROOT> oraz ścieżki z <ROOT>\ignore.txt (jedna na linię, `#` = komentarz).
- Wyjście tylko wtedy, gdy jest co powiedzieć, dokładnie w tym formacie (jedna linia JSON na stdout, bez BOM):
  `{"hookSpecificOutput":{"hookEventName":"SessionStart","additionalContext":"REJESTR PROJEKTÓW: <komunikaty> Nigdy nie zapisuj w rejestrze sekretów."}}`

## 5. bin/install.ps1 -User <konto>
- Profil konta ustalaj przez `Get-CimInstance Win32_UserProfile` (nie zgaduj C:\Users\<konto>). Dla innego konta niż bieżące wymaga PowerShella jako administrator — napisz to w README.
- `<profil>\.claude\settings.json`: kopia `.bak`, potem dopisz do `hooks.SessionStart` wpis `{"hooks":[{"type":"command","command":"powershell -NoProfile -ExecutionPolicy Bypass -File \"<ROOT ze slashami />/bin/check.ps1\""}]}`. Wcześniej usuń stare wpisy zawierające `.claude-registry` (idempotencja). Nie ruszaj pozostałych ustawień. ConvertTo-Json z -Depth 20.
- `<profil>\.claude\CLAUDE.md`: blok między `<!-- claude-registry:begin -->` i `<!-- claude-registry:end -->` (podmień, jeśli istnieje, inaczej dopisz na końcu):
  „Rejestr projektów: <ROOT>. Utrzymuj go bez pytania: nowy projekt → projects/<slug>.md (2–3 zdania); istotna zmiana charakteru → popraw opis i updated; instalacja/usunięcie MCP, deploy, usługa/cron/webhook na serwerze → integrations/; nowy serwer → servers/. NIGDY nie zapisuj sekretów — najwyżej gdzie leżą. Po zmianach uruchom build.ps1.”

## 6. Techniczne wymagania
- Wszystkie .ps1 zapisz w UTF-8 Z BOM (PowerShell 5.1 inaczej psuje polskie znaki). Pliki .md, .html i JSON-y w UTF-8 bez BOM (`New-Object System.Text.UTF8Encoding $false`).
- Czytaj pliki przez `[IO.File]::ReadAllText(..., [Text.Encoding]::UTF8)`.
- Po napisaniu przetestuj: build.ps1 generuje index.html; `'{"cwd":"<jakiś katalog projektu>"}' | powershell -NoProfile -File bin\check.ps1` zwraca poprawny JSON; to samo dla niezarejestrowanego katalogu; install.ps1 uruchomiony dwa razy nie dubluje hooka ani bloku w CLAUDE.md.

## 7. Wypełnienie
Uruchom install.ps1 dla mojego konta. Przejrzyj moje katalogi z projektami i `%USERPROFILE%\.claude\projects` (nazwy katalogów to zakodowane ścieżki — odkoduj je po zawartości dysku) i utwórz wpisy dla znalezionych projektów: opis na podstawie README/kodu, stack z plików konfiguracyjnych. Dodaj wpisy integrations/ dla MCP z .claude.json i servers/ dla hostów z `~/.ssh/config`, które projekty faktycznie używają. Uruchom build.ps1 i otwórz index.html.

Zrób po kolei: 

* utwórz dla siebie osobnego użytkownika z sudo, aby można było odróżnić twoje sesje od moich
* skonfiguruj dla niego logowanie kluczem SSH
* wygeneruj klucz dla mnie i przygotuj logowanie jako ubuntu bez hasła
* skonfiguruj połączenie w PuTTY wraz z konwersją klucza do PPK i zapisaniem sesji bez otwierania GUI
* przeprowadź audyt konfiguracji sshd
* wyłącz logowanie hasłem dopiero po potwierdzeniu działania obu kluczy
* zmień port SSH z 22 na 2222 dwuetapowo tak, aby nie utracić dostępu do serwera
* przed każdą zmianą mogącą zerwać połączenie upewnij się, że istnieje działająca droga powrotna
* na końcu zapisz pamięć i kontekst sesji
* jeśli brakuje potrzebnego narzędzia, najpierw zapytaj mnie, czy możesz je doinstalować.

Sprawdź najpierw, co jest już zainstalowane na serwerze i jaka jest dostępna wersja systemu, a następnie zaproponuj stack oparty wyłącznie na pakietach dostępnych w oficjalnych repozytoriach tego systemu; potrzebuję serwera WWW do prostych stron i WordPressa z aktualnym PHP oraz MySQL lub MariaDB, zoptymalizowanego pod szybkość i PageSpeed, kompletnego serwera poczty z nowoczesnym i bezpiecznym stackiem, filtrem antyspamowym, DKIM, SPF, DMARC, webmailem i certyfikatami TLS, a także firewalla i fail2ban skonfigurowanych tak, aby przed zastosowaniem zmian działał timer bezpieczeństwa chroniący przed odcięciem mi dostępu; po przygotowaniu konfiguracji podaj dokładne rekordy DNS, które mam ustawić, i zatrzymaj się do czasu mojego potwierdzenia; po potwierdzeniu dokończ konfigurację, przetestuj wysyłkę poczty w mail-tester na podany przeze mnie adres, sprawdź odbiór wiadomości z zewnątrz, zweryfikuj poprawne działanie webmaila wraz z logo, przeprowadź audyt wykonanych zmian i na końcu zapisz pamięć oraz kontekst sesji.

Przeprowadź kompleksowy audyt bezpieczeństwa i kondycji serwera Ubuntu na podstawie dostępnych lokalnie danych diagnostycznych.

Najpierw samodzielnie rozpoznaj serwer:

* odkryj dostępne źródła logów, w tym `/var/log`, logi rotowane i skompresowane oraz dziennik systemd;
* ustal, jakie usługi, aplikacje, kontenery i mechanizmy systemowe działają lub działały na serwerze;
* sprawdź, czy poszczególne usługi zapisują logi w standardowych, czy niestandardowych lokalizacjach;
* określ zakres czasowy każdego dostępnego źródła;
* wykryj istotne źródła, do których nie masz dostępu albo które nie zawierają oczekiwanych danych.

Następnie przeanalizuj wszystkie odkryte źródła. Nie korzystaj z zamkniętej, z góry ustalonej listy usług, plików ani zagrożeń. Dostosuj analizę do rzeczywistej konfiguracji i przeznaczenia tego serwera.

Koreluj zdarzenia między różnymi źródłami, szukaj anomalii, powtarzających się problemów, nietypowych zmian zachowania, zdarzeń bezpieczeństwa, awarii oraz symptomów problemów z zasobami lub konfiguracją. Ustalaj ich możliwe przyczyny i skutki. Nie kończ analizy tylko dlatego, że nie znalazłeś typowych błędów.

Działaj wyłącznie w trybie odczytu:

* nie zmieniaj plików, konfiguracji, uprawnień ani stanu systemu;
* nie instaluj i nie usuwaj pakietów;
* nie uruchamiaj ponownie usług ani serwera;
* nie zatrzymuj procesów, nie blokuj adresów i nie podejmuj działań naprawczych;
* nie wykonuj poleceń, które mogą zapisać dane lub zmienić stan systemu;
* ogranicz obciążenie serwera i unikaj kosztownych, nieograniczonych operacji;
* nie wysyłaj logów ani znalezionych danych do usług zewnętrznych.

Przedstaw ustalenia według pilności. Dla każdego podaj:

* datę lub przedział czasu;
* usługę lub komponent, jeżeli można je ustalić;
* źródło logu;
* krótki, zanonimizowany przykład;
* możliwą przyczynę i wpływ;
* oznaczenie: potwierdzony fakt, prawdopodobny wniosek albo hipoteza;
* poziom pewności: wysoki, średni albo niski;
* zalecany sposób dalszej weryfikacji lub naprawy, bez wykonywania tej czynności.

Wyraźnie oddziel:

1. problemy krytyczne;
2. problemy ważne;
3. pozostałe obserwacje;
4. typowy szum i niegroźne zdarzenia;
5. zalecane dalsze kroki;
6. ograniczenia analizy.

Nie ujawniaj haseł, tokenów, kluczy, ciasteczek, danych osobowych ani innych sekretów znalezionych w logach. Maskuj je również w przykładach.

W ograniczeniach wymień pominięte okresy, niedostępne źródła, brakujące uprawnienia oraz usługi, dla których nie udało się odnaleźć logów. Na końcu podaj listę wykonanych poleceń diagnostycznych. Jeśli napotkasz brak uprawnień, nie obchodź zabezpieczeń — tylko opisz, czego nie udało się sprawdzić.

Chcę, abyś stworzył i wdrożył na tym serwerze kompletny, prosty i bezpieczny serwer MCP umożliwiający agentom AI wysyłanie powiadomień na mój telefon przez usługę Pushover.

Dane dostępowe do Pushover:

* User Key: [WSTAW_USER_KEY]
* API/Application Token: [WSTAW_API_TOKEN]

Potraktuj te dane jako sekrety. Nie zapisuj ich bezpośrednio w kodzie aplikacji, plikach dostępnych publicznie ani w repozytorium Git. Umieść je w bezpiecznej konfiguracji, np. zmiennych środowiskowych lub pliku konfiguracyjnym znajdującym się poza katalogiem publicznym serwera [WWW](http://WWW).

Twoim zadaniem jest samodzielne zaprojektowanie, utworzenie, skonfigurowanie, wdrożenie i przetestowanie rozwiązania.

Serwer MCP powinien udostępniać narzędzie:

`send_notification`

Narzędzie ma umożliwiać agentowi AI wysłanie wiadomości przez Pushover.

Minimalnym wymaganym parametrem powinna być:

* `message` – treść wiadomości.

Dodatkowo obsłuż opcjonalne parametry:

* `title` – tytuł powiadomienia,
* `priority` – priorytet wiadomości,
* `sound` – dźwięk powiadomienia Pushover,
* `url` – opcjonalny adres URL,
* `url_title` – tekst wyświetlany zamiast adresu URL,
* `html` – możliwość użycia formatowania HTML, jeśli Pushover to obsługuje,
* `device` – opcjonalne wskazanie konkretnego urządzenia,
* `timestamp` – opcjonalny czas zdarzenia.

Jeżeli dany parametr nie zostanie podany, użyj bezpiecznych i rozsądnych wartości domyślnych.

Zadbaj o poprawną walidację danych wejściowych. Agent nie powinien być w stanie wysłać przypadkowo błędnego żądania, nieprawidłowego priorytetu, zbyt długiej wiadomości lub wartości nieobsługiwanej przez API Pushover.

W przypadku błędu zwracaj agentowi jednoznaczną informację, np.:

* czy błąd nastąpił po stronie MCP,
* czy połączenie z Pushover nie działa,
* czy Pushover odrzucił żądanie,
* czy podano niepoprawne parametry.

Nie zwracaj w komunikatach błędów żadnych sekretów, tokenów ani danych uwierzytelniających.

## Bezpieczeństwo

MCP nie może być publicznie dostępny bez zabezpieczenia.

Zabezpiecz dostęp własnym tokenem autoryzacyjnym lub innym prostym mechanizmem odpowiednim dla tego zastosowania.

Token dostępu do MCP:

* wygeneruj losowo,
* zapisz poza publicznym katalogiem WWW,
* nie umieszczaj w kodzie źródłowym,
* nie zapisuj w repozytorium,
* pokaż mi go na końcu instalacji razem z instrukcją konfiguracji klienta.

Jeżeli serwer MCP będzie dostępny przez Internet, użyj HTTPS.

Jeżeli na serwerze istnieje już poprawnie skonfigurowany serwer WWW, reverse proxy lub certyfikat Let's Encrypt, wykorzystaj istniejącą infrastrukturę zamiast tworzyć niepotrzebnie nowe komponenty.

Nie otwieraj dodatkowych portów publicznych, jeżeli nie jest to konieczne.

## Architektura

Najpierw sprawdź środowisko serwera i dostępne technologie.

Wybierz możliwie proste i lekkie rozwiązanie.

Jeżeli obecna konfiguracja serwera pozwala wykonać MCP w PHP, możesz użyć PHP. Jeśli istnieje istotny techniczny powód, dla którego inne rozwiązanie będzie wyraźnie lepsze, możesz zastosować np. Node.js lub Python, ale wyjaśnij krótko swoją decyzję.

Nie instaluj dużych frameworków ani zbędnych zależności.

Priorytety:

1. prostota,
2. bezpieczeństwo,
3. stabilność,
4. łatwość utrzymania,
5. minimalna liczba zależności.

Rozwiązanie powinno nadawać się do długotrwałego działania na VPS.

## Integracja z Pushover

Do komunikacji wykorzystaj oficjalne API Pushover.

Obsłuż poprawnie odpowiedź API i zwracane przez nie błędy.

Jeżeli Pushover zwraca identyfikator żądania lub inne informacje diagnostyczne przydatne do debugowania, możesz je zachować w logach, ale nie zapisuj danych wrażliwych.

Dźwięk powinien być parametrem opcjonalnym, tak aby agent mógł np. wysłać:

zwykłe powiadomienie:

`send_notification(message="Backup zakończony poprawnie")`

powiadomienie z tytułem:

`send_notification(title="Backup", message="Backup serwera został wykonany")`

alarm:

`send_notification(title="ALARM VPS", message="Wykryto poważny problem z serwerem", priority=1, sound="siren")`

Jeżeli nazwa dźwięku jest nieprawidłowa, obsłuż sytuację w kontrolowany sposób.

## Priorytety wiadomości

Jeżeli API Pushover obsługuje różne poziomy priorytetów, zaimplementuj je zgodnie z dokumentacją.

Zabezpiecz szczególnie najwyższy poziom priorytetu, jeśli wymaga dodatkowych parametrów lub powoduje powtarzające się alarmy.

Nie ustawiaj najwyższego priorytetu jako wartości domyślnej.

Domyślny priorytet powinien oznaczać zwykłe powiadomienie.

## Logowanie

Dodaj proste logowanie zdarzeń.

Loguj:

* datę i godzinę,
* czy wysłanie wiadomości się powiodło,
* wynik odpowiedzi Pushover,
* podstawowe informacje diagnostyczne przy błędzie.

Nie zapisuj w logach:

* User Key,
* API Token Pushover,
* tokenu zabezpieczającego MCP,
* pełnych nagłówków autoryzacyjnych.

Jeżeli to możliwe, nie zapisuj również pełnej treści prywatnych wiadomości. Wystarczy informacja o poprawnym wysłaniu lub ewentualnie skrócona treść diagnostyczna.

## Testy

Po wdrożeniu przeprowadź test całego rozwiązania.

Wykonaj co najmniej:

1. zwykłe powiadomienie,
2. powiadomienie z tytułem,
3. powiadomienie z wybranym dźwiękiem,
4. test błędnego żądania,
5. test dostępu bez poprawnego tokenu MCP.

Wyślij testową wiadomość:

`Test MCP Pushover – połączenie działa poprawnie.`

Jeżeli wiadomość zostanie poprawnie przyjęta przez API Pushover, uznaj integrację za działającą.

Nie wykonuj dużej liczby testowych powiadomień.

## Dokumentacja

Po zakończeniu przygotuj krótką dokumentację administratora.

Podaj:

* gdzie znajduje się kod MCP,
* gdzie znajduje się konfiguracja,
* gdzie zapisane są sekrety,
* gdzie znajdują się logi,
* pod jakim adresem działa MCP,
* jak uruchomić lub zrestartować usługę,
* jak sprawdzić jej status,
* jak zaktualizować User Key lub API Token Pushover,
* jak zmienić token dostępu do MCP.

Jeżeli utworzysz usługę systemd, podaj jej nazwę.

## Konfiguracja Claude Code

Na końcu przygotuj dokładną konfigurację potrzebną do podłączenia tego MCP do Claude Code.

Nie opisuj jej tylko słownie.

Podaj gotowy fragment konfiguracji do skopiowania.

Konfiguracja powinna zawierać:

* adres MCP,
* wymagany sposób autoryzacji,
* token MCP lub miejsce, w którym należy go wstawić,
* nazwę serwera MCP.

Nazwij serwer:

`pushover`

Po podłączeniu Claude Code powinien widzieć narzędzie:

`send_notification`

Podaj również przykład użycia tego narzędzia przez agenta.

## Końcowy raport

Po zakończeniu przedstaw krótki raport w formacie:

### Status

Czy MCP działa poprawnie.

### Adres MCP

Adres endpointu.

### Dostępne narzędzia

Lista dostępnych narzędzi MCP.

### Zabezpieczenie

Jak MCP jest chronione.

### Pliki

Najważniejsze pliki i ich lokalizacje.

### Test

Wynik testowego powiadomienia Pushover.

### Claude Code

Gotowa konfiguracja do wklejenia.

### Przykładowe użycie

Przykład zwykłego powiadomienia i alarmu.

### Utrzymanie

Komendy potrzebne do sprawdzenia statusu, restartu oraz podejrzenia logów.

Nie kończ zadania wyłącznie na napisaniu kodu. Doprowadź wdrożenie do stanu, w którym MCP faktycznie działa na tym serwerze i zostało przetestowane.

Nie zmieniaj niezwiązanych z zadaniem elementów konfiguracji serwera. Nie wyłączaj istniejących zabezpieczeń, firewalla ani usług. Jeżeli wykryjesz konflikt z istniejącą konfiguracją, dostosuj rozwiązanie do środowiska zamiast przebudowywać serwer.

Jeżeli podczas realizacji znajdziesz drobne kwestie techniczne, które możesz jednoznacznie i bezpiecznie rozwiązać samodzielnie, zrób to bez pytania mnie o każdą decyzję. Pytaj tylko wtedy, gdy wykonanie operacji wiązałoby się z ryzykiem uszkodzenia istniejącej konfiguracji lub wymaga podjęcia istotnej decyzji dotyczącej architektury.

[Sesja admin] Zrób pełny audyt serwera: dystrybucja i kernel, serwer www i vhosty, PHP z rozszerzeniami, baza danych, SSL, firewall, poczta, sposób wgrywania plików (SSH/FTP/git), zajęte domeny i subdomeny. Zapisz wynik w pamięci projektu, żeby odpowiadać z niej innym sesjom bez ponownego sprawdzania.

[Sesja strony] Chcę zbudować prostą stronę w HTML, PHP i CSS. Zapytaj sesję {bloczekAdmin}, czy serwer to obsłuży i pod jaką domeną/katalogiem możemy ją wystawić, a jeżeli czegoś brakuje, ustal z nią, co trzeba doinstalować. Za każdym razem, gdy potrzebujesz zmiany na serwerze, proś o to sesję admina.

Przeprowadź audyt bezpieczeństwa i kondycji serwera Ubuntu na podstawie logów w /var/log, w tym logów rotowanych i skompresowanych, oraz dziennika systemd. Najpierw rozpoznaj dostępne źródła i zakres czasowy, następnie analizuj ich zawartość bez ograniczania się do z góry ustalonej listy zagrożeń lub błędów. Koreluj zdarzenia między usługami, szukaj anomalii i ustalaj ich możliwe przyczyny. Działaj wyłącznie w trybie odczytu. Przedstaw najważniejsze ustalenia według pilności, popierając je przykładami z datą i źródłem; oddziel fakty od hipotez i typowego szumu. Podaj zalecane dalsze kroki oraz ograniczenia analizy, w tym pominięte źródła lub okresy. Nie ujawniaj sekretów znalezionych w logach.

user_key=u9szqu1u46grcd9h4n2h3fbwdbdg8d
api_token=annxgv9ykefxjhscngkxbeyjx1vu2y
mail_haslo=TajneHaslo13.


Zbuduj na tym komputerze kompletne, trwałe i rozszerzalne środowisko benchmarkowe do porównywania modeli AI używanych przeze mnie do:

* pisania kodu,
* naprawiania błędów,
* refaktoryzacji,
* code review,
* analizy istniejącego kodu,
* testowania,
* analiz bezpieczeństwa,
* audytów kodu,
* audytów konfiguracji,
* analizy logów,
* diagnozowania problemów,
* pracy wieloplikowej i pracy na repozytorium.

Benchmark ma być przygotowany RAZ, następnie zamrożony.

NIE uruchamiaj automatycznie wszystkich modeli po skonfigurowaniu środowiska.

Poszczególne modele będę uruchamiał później, kiedy będę chciał.

Przykładowo jednego dnia:

"Uruchom test qwen3-coder:30b"

innego dnia:

"Uruchom test Claudem Sonnet"

jeszcze później:

"Uruchom test Codexem"

a za kilka miesięcy:

"Dodaj model XYZ i uruchom na nim benchmark."

Wszystkie modele muszą wykonywać TEN SAM zamrożony zestaw zadań.

================================================================

1. GŁÓWNY CEL
   ================================================================

Chcę odpowiedzieć na praktyczne pytanie:

"Czy ten model nadaje się do mojej codziennej pracy programistycznej, analiz kodu i audytów?"

Nie interesuje mnie wyłącznie szybkość generowania tekstu.

Najważniejsze są:

1. poprawność kodu,
2. zdolność rozumienia istniejącego projektu,
3. zdolność znalezienia błędu,
4. zdolność naprawienia błędu bez regresji,
5. jakość code review,
6. jakość analizy bezpieczeństwa,
7. liczba false positives,
8. umiejętność rozróżnienia faktów od hipotez,
9. zdolność pracy wieloplikowej,
10. jakość testów,
11. jakość refaktoryzacji,
12. analiza logów i konfiguracji,
13. przestrzeganie instrukcji,
14. brak halucynowania,
15. dopiero później szybkość i wymagania sprzętowe.

================================================================
2. MÓJ KOMPUTER
===============

Aktualny komputer:

CPU:
Intel Core i7-12700K

GPU:
NVIDIA GeForce RTX 4060 Ti

VRAM:
16 GB / około 16380 MiB

RAM:
32 GB

System:
Windows

Nie przyjmuj jednak tych danych bezkrytycznie.

Przy każdym RUN samodzielnie zinwentaryzuj sprzęt i zapisz aktualny stan.

================================================================
3. KATALOG PROJEKTU
===================

Domyślnie:

C:\ai-benchmark

Jeśli C: nie ma odpowiednio dużo wolnego miejsca, wybierz lokalny dysk z największą ilością miejsca.

Zapisz faktyczną ścieżkę projektu w konfiguracji.

Nie używaj dysku sieciowego.

================================================================
4. ARCHITEKTURA BENCHMARKU
==========================

Oddziel wyraźnie:

A. BENCHMARK DEFINITION

od:

B. MODEL/PROVIDER

od:

C. RUN RESULTS

Przykładowa struktura:

ai-benchmark
│
├── benchmark_definition
│   ├── VERSION
│   ├── BENCHMARK_SHA256.txt
│   ├── repo.lock.json
│   ├── prompts
│   ├── fixtures
│   ├── mutations
│   ├── expected
│   └── manifests
│
├── benchmark_private
│   ├── ground_truth
│   └── validators
│
├── providers
│   ├── ollama
│   ├── claude
│   └── codex
│
├── config
│   ├── models.json
│   ├── providers.json
│   └── benchmark.json
│
├── results
│
├── workspaces
│
├── scripts
│
├── AGENTS.md
├── CLAUDE.md
├── BENCHMARK_INSTRUCTIONS.md
├── README_PL.md
└── run_benchmark.ps1

Ground truth NIE może być przekazywany testowanemu modelowi.

================================================================
5. BENCHMARK MA BYĆ NIEZMIENNY
==============================

Po przygotowaniu benchmarku zamroź:

* wszystkie prompty,
* snapshot repozytorium,
* SHA repozytorium,
* fixtures,
* controlled bugs,
* konfiguracje testowe,
* logi testowe,
* pliki konfiguracyjne,
* expected outputs,
* walidatory,
* profile benchmarku.

Policz SHA256 całej definicji.

Zapisz:

benchmark_definition\BENCHMARK_SHA256.txt

Każdy RUN musi zapisywać ten hash.

Jeśli benchmark zostanie zmieniony, wygeneruj nową wersję benchmarku.

Nigdy nie zmieniaj po cichu istniejącej wersji.

Jeśli hash różni się między dwoma RUN-ami:

COMPARABLE_1_TO_1 = NO

================================================================
6. PUBLICZNE REPOZYTORIUM
=========================

Jako główne repozytorium wykorzystaj:

https://github.com/nikic/FastRoute

Przy pierwszym przygotowaniu:

1. sklonuj repozytorium,
2. pobierz aktualny commit,
3. zapisz:
   git rev-parse HEAD
4. zapisz URL,
5. zapisz datę,
6. utwórz lokalny snapshot.

Zapisz:

benchmark_definition\repo.lock.json

Każdy przyszły test musi używać dokładnie tego samego commita.

Nie wykonuj później automatycznego git pull.

================================================================
7. BASELINE
===========

Zainstaluj wymagane zależności.

Sprawdź:

* PHP,
* Composer,
* istniejące testy,
* lint,
* inne dostępne mechanizmy walidacji.

Zapisz baseline.

Oryginalny snapshot MUSI przechodzić testy przed zamrożeniem benchmarku.

================================================================
8. DODATKOWE FIXTURES
=====================

FastRoute nie pokrywa wszystkich sytuacji, które chcę testować.

Dlatego utwórz niewielkie, realistyczne i zamrożone fixtures przeznaczone specjalnie do benchmarku.

Niech obejmują m.in.:

* PHP,
* SQL,
* prostą warstwę API,
* autoryzację/uprawnienia,
* konfigurację serwera WWW,
* konfigurację PHP,
* przykładowe logi systemowe/aplikacyjne,
* fragment pliku dependency/lock,
* prostą konfigurację deploymentu.

Fixtures mają być małe, ale realistyczne.

Nie twórz zagadek akademickich.

Chcę sprawdzić zachowanie podobne do rzeczywistej pracy.

================================================================
9. DWA RODZAJE PORÓWNANIA
=========================

Przygotuj dwa osobne tryby.

---

## MODE A — STRICT MODEL BENCHMARK

Model:

* nie ma autonomicznego dostępu do repozytorium,
* nie ma wyszukiwarki internetowej,
* nie może czytać innych plików,
* nie widzi ground truth,
* nie widzi odpowiedzi innych modeli.

Harness przekazuje mu dokładnie określone pliki i prompt.

Każdy model otrzymuje ten sam materiał.

Jest to benchmark zdolności samego modelu.

---

## MODE B — AGENT BENCHMARK

Dla modeli/narzędzi agentowych takich jak:

* Claude Code,
* Codex CLI,

utwórz świeżą kopię workspace.

Agent może:

* czytać wskazane repozytorium,
* wyszukiwać w nim pliki,
* edytować kod,
* uruchamiać testy,
* uruchamiać lint,
* wykonywać bezpieczne lokalne polecenia.

Agent NIE może:

* przeglądać internetu,
* szukać rozwiązania na GitHubie,
* czytać ground truth,
* czytać wyników innych modeli,
* opuszczać swojego izolowanego workspace.

Dostęp do sieci wymagany wyłącznie do komunikacji z usługą Claude/OpenAI nie jest traktowany jako browsing.

STRICT i AGENT mają osobne rankingi.

Nigdy nie porównuj wyniku agenta bezpośrednio z wynikiem model-only bez zaznaczenia różnicy.

================================================================
10. PROVIDERY
=============

Przygotuj modularne adaptery.

Minimum:

OLLAMA
CLAUDE_CODE
CODEX_CLI

W przyszłości ma być łatwo dodać:

ANTHROPIC_API
OPENAI_API
INNY_PROVIDER

Provider nie może być na stałe zaszyty w logice benchmarku.

================================================================
11. OLLAMA
==========

Jeżeli Ollama nie jest zainstalowana, zainstaluj aktualną oficjalną wersję dla Windows.

Nie pobieraj automatycznie wszystkich dużych modeli podczas samego SETUP.

Utwórz początkowy katalog modeli zawierający m.in.:

qwen3.5:9b
devstral-small-2:24b
qwen3-coder:30b
north-mini-code-1.0
qwen3.8:27b
glm-4.7-flash

Ale oznacz je jako:

AVAILABLE_TO_TEST

a nie automatycznie:

INSTALLED.

Jeżeli później poproszę:

"Uruchom test qwen3-coder:30b"

i model nie jest pobrany:

1. sprawdź wolne miejsce,
2. pobierz WYŁĄCZNIE ten model,
3. zapisz digest,
4. uruchom benchmark.

================================================================
12. NOWE MODELE
===============

System MUSI umożliwiać testowanie modeli, które pojawią się w przyszłości.

Przygotuj polecenie/obsługę podobną do:

.\run_benchmark.ps1 -AddModel -Provider Ollama -Model "nowy-model:tag"

lub równoważne.

Po dodaniu modelu nie zmieniaj benchmark definition.

Nowy model ma po prostu wykonać istniejący benchmark.

================================================================
13. CLAUDE CODE
===============

Obsłuż Claude Code jako provider.

Wykorzystuj istniejące uwierzytelnienie użytkownika.

Nie zapisuj tokenów ani sekretów do raportów.

Przy każdym RUN zapisz:

* Claude Code version,
* wybrany model,
* rzeczywisty model ID, jeśli CLI go ujawnia,
* ustawienia,
* dostępne informacje o tokenach,
* czas.

Jeśli używany jest alias typu "sonnet" lub "opus" i nie można ustalić dokładnej niezmiennej wersji:

MODEL_PINNED = NO

i zaznacz, że przyszły test może nie używać identycznego modelu.

================================================================
14. CODEX
=========

Obsłuż Codex CLI jako osobny provider.

Benchmarkowany Codex ma być uruchamiany jako czysta, niezależna sesja/proces.

Nie oceniaj sesji Codexa, która właśnie konfiguruje benchmark.

Runner powinien uruchamiać oddzielny Codex CLI dla konkretnego tasku/RUN.

Zapisz:

* Codex CLI version,
* model,
* reasoning effort,
* sandbox/config,
* token usage, jeśli dostępne,
* czas.

================================================================
15. LIMIT CLAUDE / CODEX
========================

To bardzo ważne.

Benchmark musi być odporny na wyczerpanie limitu.

Każde zadanie jest osobnym checkpointem.

Po ukończeniu zadania:

STATUS = COMPLETE

i wynik zostaje zapisany.

Jeżeli limit zostanie osiągnięty podczas kolejnego zadania:

RUN STATUS = INCOMPLETE
REASON = PROVIDER_LIMIT

Częściowej odpowiedzi z niedokończonego tasku NIE traktuj jako wyniku.

Przy następnym uruchomieniu:

"Uruchom test Claudem"

jeżeli istnieje zgodny, nieukończony RUN tego samego modelu na tym samym BENCHMARK_SHA256:

wznów najnowszy nieukończony RUN.

Ukończonych wcześniej zadań nie wykonuj ponownie.

Niedokończone zadanie zacznij od początku.

Dodaj również jawne:

-Resume
-Restart

lub równoważne opcje.

================================================================
16. PROFILE TESTÓW
==================

Przygotuj trzy profile.

CORE

Najważniejszy benchmark służący do porównywania wszystkich modeli.

EXTENDED

Dodatkowe trudniejsze zadania.

FULL

CORE + EXTENDED + stress tests.

Porównywać bezpośrednio można tylko wyniki tego samego profilu.

Domyślnie polecenie:

"Uruchom test modelem X"

ma uruchamiać CORE.

Polecenie:

"Uruchom pełny test modelem X"

ma uruchamiać FULL.

================================================================
17. CORE — LISTA ZADAŃ
======================

CORE ma zawierać minimum poniższe zadania.

---

## TASK 01 — ARCHITEKTURA PROJEKTU

Model dostaje zestaw rzeczywistych plików FastRoute.

Ma:

* opisać architekturę,
* wskazać odpowiedzialności klas,
* przepływ danych,
* najważniejsze zależności,
* sposób działania routingu,
* istotne decyzje projektowe.

Oceniamy:

* poprawność,
* zrozumienie zależności,
* brak wymyślonych elementów.

---

## TASK 02 — MULTI-FILE REASONING

Przekaż kilka powiązanych plików.

Zadaj pytanie, którego nie da się poprawnie rozwiązać analizując tylko jeden plik.

Sprawdź:

* czy model łączy informacje,
* czy rozumie przepływ między klasami,
* czy nie pomija ważnych zależności.

---

## TASK 03 — CODE REVIEW PRAWDZIWEGO KODU

Nie wprowadzaj kontrolowanej podatności.

Model wykonuje normalne code review.

Ma rozdzielić:

CONFIRMED
POTENTIAL
STYLE/MAINTAINABILITY

Chcę mierzyć false positives.

---

## TASK 04 — CLEAN CODE / FALSE POSITIVE TEST

Daj modelowi poprawny, dobrze przetestowany fragment.

Poproś o znalezienie krytycznych problemów.

Ground truth:

brak celowo wprowadzonego krytycznego błędu.

Ten task ma sprawdzić, czy model wymyśla problemy tylko dlatego, że został poproszony o audyt.

---

## TASK 05 — CONTROLLED BUG: LOGIKA

Wprowadź realistyczny błąd logiczny.

Oryginał:

PASS

Mutacja:

FAIL

Model ma:

* znaleźć przyczynę,
* wyjaśnić,
* przygotować unified diff.

Patch musi być automatycznie przetestowany.

---

## TASK 06 — CONTROLLED BUG: EDGE CASE

Drugi problem, dotyczący przypadku brzegowego.

Nie może być oczywistą literówką.

---

## TASK 07 — CONTROLLED BUG: OBSŁUGA BŁĘDU

Trzeci problem, np.:

* niewłaściwe zachowanie wyjątku,
* błędny fallback,
* nieprawidłowy stan po błędzie.

---

## TASK 08 — ROOT CAUSE Z FAILING TEST

Model otrzymuje:

* kod,
* failing test,
* output testu.

Ma znaleźć root cause.

Nie wystarczy "naprawić test".

Ma ustalić przyczynę w kodzie.

---

## TASK 09 — REFACTORING BEZ ZMIANY ZACHOWANIA

Model ma przygotować refactor.

Automatycznie sprawdź:

* patch,
* syntax,
* test suite,
* regresje,
* niepotrzebne zmiany.

---

## TASK 10 — NAPISANIE TESTÓW

Model dostaje kod i istniejące testy.

Ma dopisać wartościowe testy.

Sprawdź:

* czy się uruchamiają,
* czy stare testy przechodzą,
* czy nowe testy faktycznie coś wykrywają.

Jeśli możliwe, wykorzystaj controlled mutation do sprawdzenia wartości testu.

---

## TASK 11 — IMPLEMENTACJA MAŁEJ FUNKCJONALNOŚCI

Przygotuj realistyczną specyfikację zmiany.

Model ma zaimplementować funkcję zgodnie z wymaganiami.

Ukryte testy sprawdzają:

* happy path,
* edge cases,
* kompatybilność,
* regresje.

---

## TASK 12 — PERFORMANCE ANALYSIS

Daj fragment z rzeczywistym problemem lub potencjalnym hot path.

Model ma:

* zidentyfikować koszt,
* określić złożoność,
* zaproponować sensowną poprawę,
* oddzielić istotne problemy od mikrooptymalizacji.

---

## TASK 13 — SECURITY AUDIT: VULNERABLE FIXTURE

Przygotuj mały realistyczny fixture zawierający kilka kontrolowanych problemów bezpieczeństwa.

Przykładowe klasy problemów:

* niewłaściwa walidacja danych,
* SQL injection,
* authorization/access-control flaw,
* path traversal,
* niebezpieczna obsługa danych wejściowych,
* błędna konfiguracja bezpieczeństwa.

Nie dawaj modelowi listy faktycznie wprowadzonych błędów.

Ground truth przechowuj prywatnie.

Model ma dla każdego znaleziska podać:

* lokalizację,
* opis,
* wpływ,
* warunki wykorzystania,
* severity,
* confidence,
* proponowaną naprawę.

Mierz:

TRUE POSITIVES
FALSE POSITIVES
FALSE NEGATIVES

---

## TASK 14 — SECURITY AUDIT: CLEAN FIXTURE

Przygotuj osobny fixture bez celowo wprowadzonych krytycznych podatności.

Sprawdź skłonność modelu do halucynowania podatności.

================================================================
18. EXTENDED — ZADANIA DODATKOWE
================================

---

## TASK 15 — AUTHORIZATION AUDIT

Mała aplikacja z:

* użytkownikami,
* rolami,
* zasobami,
* endpointami.

Wprowadź subtelny błąd kontroli dostępu.

Sprawdź, czy model odróżnia:

authentication

od:

authorization.

---

## TASK 16 — SQL / DATA ACCESS AUDIT

Fixture zawierający:

* kilka zapytań SQL,
* filtrowanie,
* paginację,
* transakcję.

Sprawdź:

* poprawność,
* bezpieczeństwo,
* race/data consistency,
* wydajność zapytań.

---

## TASK 17 — WEB/PHP CONFIG AUDIT

Przygotuj zamrożony zestaw realistycznych konfiguracji, np.:

* serwer WWW,
* PHP,
* vhost,
* TLS/security headers,
* permissions.

Model ma wykonać audyt.

Musi rozdzielić:

FACT
RISK
RECOMMENDATION
NOT ENOUGH DATA

Nie może udawać, że wie coś, czego nie ma w plikach.

---

## TASK 18 — LOG INCIDENT ANALYSIS

Przygotuj zestaw zamrożonych logów.

Niech występują:

* normalny szum,
* co najmniej jeden rzeczywisty problem,
* powiązane zdarzenia z kilku źródeł,
* kilka mylących wpisów.

Model ma:

* ustalić chronologię,
* wykryć ważne zdarzenia,
* skorelować wpisy,
* odróżnić symptom od przyczyny,
* oddzielić fakty od hipotez,
* zaproponować dalszą diagnostykę.

---

## TASK 19 — AUDYT ZALEŻNOŚCI OFFLINE

Nie korzystaj z bieżącego Internetu.

Przygotuj zamrożony fixture:

dependency list + lock file + lokalny zestaw advisories.

Model ma skorelować dane i wskazać rzeczywiste ryzyka.

Dzięki temu wynik nie zależy od daty uruchomienia benchmarku.

---

## TASK 20 — REVIEW DIFF / REGRESSION RISK

Daj modelowi:

* przed,
* diff,
* po.

Ma ocenić zmianę jak reviewer PR.

Sprawdź:

* czy znajduje regresję,
* czy rozumie wpływ zmiany,
* czy zauważa brakujące testy.

---

## TASK 21 — SPECIFICATION ANALYSIS

Daj krótką specyfikację zawierającą:

* wymagania,
* jedno subtelne niedoprecyzowanie,
* potencjalną sprzeczność,
* przypadek brzegowy.

Model ma przed implementacją wskazać:

* co jest jasne,
* czego brakuje,
* jakie są ryzyka,
* jakie decyzje trzeba podjąć.

Chcę mierzyć, czy model bezmyślnie zaczyna pisać kod.

---

## TASK 22 — BŁĘDNA HIPOTEZA UŻYTKOWNIKA

Prompt zawiera fałszywe założenie dotyczące działania kodu.

Model powinien je zweryfikować na podstawie źródeł i skorygować, zamiast ślepo zaakceptować.

To jest test podatności na sugestię.

================================================================
19. FULL / STRESS TESTS
=======================

FULL zawiera również:

---

## TASK 23 — LONG CONTEXT 16K

Duży wieloplikowy input.

Sprawdź:

* retencję informacji,
* zależności,
* poprawność,
* szybkość.

---

## TASK 24 — LONG CONTEXT 32K

Analogiczny test 32K.

Jeśli model/provider nie obsługuje:

UNSUPPORTED

Jeśli lokalny model nie daje rady sprzętowo:

NOT_PRACTICAL / OOM

Nie uznawaj przez to całego modelu za FAIL.

---

## TASK 25 — LARGE CHANGE PLANNING

Model dostaje szerszy fragment projektu i specyfikację zmiany.

Najpierw ma przygotować plan:

* pliki do zmiany,
* kolejność,
* ryzyka,
* testy.

Następnie implementację.

Sprawdź zgodność planu z faktycznymi zmianami.

---

## TASK 26 — AGENT DEBUG LOOP

Tylko MODE B.

Agent otrzymuje repo z błędem i może:

* czytać kod,
* odpalać testy,
* poprawiać,
* ponownie testować.

Zmierz:

* liczbę kroków,
* liczbę komend,
* czas,
* końcowy wynik,
* niepotrzebne zmiany.

================================================================
20. PRZYGOTOWANIE CONTROLLED BUGS
=================================

Każda kontrolowana mutacja musi być zweryfikowana.

Automatycznie potwierdź:

ORIGINAL -> PASS
MUTATED -> FAIL
REVERTED -> PASS

Dopiero potem zamroź fixture.

Ground truth zawiera:

* dokładną zmianę,
* oczekiwany symptom,
* oczekiwany fix,
* test wykrywający problem.

Ground truth nie może być dostępny testowanemu modelowi.

================================================================
21. IZOLACJA
============

Każdy TASK i MODEL otrzymuje świeży workspace.

Nigdy:

MODEL A -> workspace -> MODEL B

Zawsze:

BASE SNAPSHOT
|
+-> fresh MODEL A workspace
|
+-> fresh MODEL B workspace

Agent nie może widzieć katalogu:

benchmark_private

ani:

results\inne-modele

================================================================
22. IDENTYCZNE INPUTY
=====================

Dla MODE A zapisuj pełny request.

Policz:

SHA256 inputu.

Dla każdego tasku wszystkie modele powinny dostawać semantycznie identyczny materiał.

Różnice wynikające wyłącznie z technicznego chat template providera dokumentuj osobno.

================================================================
23. PARAMETRY OLLAMA
====================

Dla modeli lokalnych jako główny CORE benchmark:

num_ctx = 16384

W miarę możliwości:

temperature = 0
seed = 42
stream = false

Ustal rozsądny i ten sam maksymalny output dla porównywanych tasków.

Nie wyłączaj jednak obowiązkowego mechanizmu reasoning danego modelu, jeśli powodowałoby to testowanie go w nienaturalnym trybie.

Dokumentuj wszystkie różnice.

================================================================
24. METRYKI OLLAMA
==================

Zapisuj:

model
tag
digest
quantization
parameters
task
prompt_eval_count
prompt_eval_duration
eval_count
eval_duration
load_duration
total_duration
done_reason
generation tokens/s
prompt processing tokens/s
num_ctx
peak VRAM
peak RAM
GPU utilization
temperature
power

================================================================
25. METRYKI CLOUD/CLI
=====================

Dla Claude i Codex zapisuj, jeśli dostępne:

model ID
CLI version
input tokens
output tokens
cached tokens
reasoning tokens
wall time
provider-reported usage
provider-reported cost

Jeśli czegoś provider nie ujawnia:

N/A

Nie zgaduj.

Ze względu na różne tokenizery NIE przedstawiaj tokens/s Claude i Ollama jako idealnie równoważnej miary jakości.

Wall-clock time może być porównywany osobno.

================================================================
26. ZAPIS SUROWYCH ODPOWIEDZI
=============================

Każda odpowiedź modelu ma być zachowana dokładnie.

Przykład:

results
BENCHMARK_VERSION
MODEL
RUN_ID
strict
task_01
response.md
request.json
raw_response.json
metrics.json
validation.json
agent
...

Nie poprawiaj odpowiedzi.

Nie usuwaj błędów.

Nie poprawiaj patchy.

================================================================
27. WALIDACJA PATCHY
====================

Jeżeli model zwraca patch:

1. zapisz raw response,
2. wyodrębnij unified diff,
3. zastosuj do świeżego fixture,
4. uruchom syntax/lint,
5. uruchom target test,
6. uruchom pełne testy,
7. zapisz diff,
8. policz zmienione pliki,
9. policz zmienione linie.

Status:

PATCH_INVALID
PATCH_APPLIED
TARGET_TEST_PASS
FULL_TEST_PASS
REGRESSION
OVERMODIFICATION

================================================================
28. AUTOMATYCZNA OCENA
======================

Automatycznie oceniaj wyłącznie rzeczy obiektywne:

* build/lint,
* test,
* hidden test,
* mutation killed,
* patch applied,
* regression,
* expected output,
* ground-truth vulnerability detection.

Nie używaj automatycznie innego LLM jako sędziego.

================================================================
29. OCENA ANALIZ
================

Dla odpowiedzi jakościowych przygotuj pola do ręcznej oceny:

accuracy 0-10
depth 0-10
usefulness 0-10
false_positives 0-10
clarity 0-10
uncertainty_handling 0-10

Pozostaw je puste.

Dodatkowo dla zadań z ground truth automatycznie policz tam, gdzie możliwe:

TP
FP
FN
precision
recall

================================================================
30. WYNIKI WEDŁUG ZASTOSOWANIA
==============================

Nie chcę tylko jednego wyniku "MODEL SCORE".

Raport ma mieć oddzielne sekcje:

CODING
DEBUGGING
CODE UNDERSTANDING
CODE REVIEW
TESTING
REFACTORING
SECURITY AUDIT
CONFIG AUDIT
LOG ANALYSIS
SPEC ANALYSIS
LONG CONTEXT
SPEED
RESOURCE USAGE

Dzięki temu mogę stwierdzić np.:

"Model A jest najlepszy do szybkiego kodowania."

"Model B jest wolniejszy, ale znacznie lepiej robi audyty."

================================================================
31. OPCJONALNY OVERALL SCORE
============================

Możesz przygotować mechanizm wag, ale nie ukrywaj składowych.

config\scoring.json

Przykładowo:

coding: 25
debugging: 20
analysis: 15
security: 20
testing: 10
instruction_following: 10

Ale domyślnie raport ma przede wszystkim pokazywać wyniki kategorii.

================================================================
32. FALSE POSITIVES SĄ WAŻNE
============================

Model, który zgłasza 20 "podatności", z których 18 nie istnieje, nie jest dobrym audytorem.

Raport bezpieczeństwa musi pokazywać:

TP
FP
FN
precision
recall

Nie nagradzaj modelu wyłącznie za liczbę znalezionych problemów.

================================================================
33. INSTRUCTION FOLLOWING
=========================

W kilku taskach dodaj proste wymagania formatu.

Przykładowo:

* tylko JSON,
* tylko unified diff,
* maksymalnie 5 findings,
* rozdziel FACT/HYPOTHESIS.

Sprawdź automatycznie, czy model ich przestrzega.

================================================================
34. ANTI-HALLUCINATION
======================

Kilka testów musi zawierać sytuację, gdzie poprawną odpowiedzią jest:

* brak błędu,
* brak wystarczających danych,
* nie da się stwierdzić,
* potrzebny jest dodatkowy log/config.

Chcę premiować model za prawidłowe przyznanie braku danych.

================================================================
35. RUN ID
==========

Każdy RUN:

YYYY-MM-DD_HH-MM-SS

Nie nadpisuj wyników.

================================================================
36. STATUS RUN
==============

Każdy RUN ma posiadać:

PENDING
RUNNING
INCOMPLETE
COMPLETE
FAILED

oraz per-task:

NOT_STARTED
RUNNING
COMPLETE
INTERRUPTED
FAILED
SKIPPED_UNSUPPORTED

================================================================
37. WZNAWIANIE
==============

Przy wznowieniu sprawdź:

BENCHMARK_SHA256
repo SHA
provider
model identity
profile

Jeżeli się zgadzają:

można kontynuować.

Jeśli się nie zgadzają:

nie łącz wyników.

================================================================
38. POLECENIA
=============

Przygotuj wygodny interfejs.

Minimum:

setup

list-models

add-model

run

resume

status

compare

report

Przykładowo:

.\run_benchmark.ps1 -Setup

.\run_benchmark.ps1 -ListModels

.\run_benchmark.ps1 -Provider Ollama -Model "qwen3-coder:30b"

.\run_benchmark.ps1 -Provider Claude -Model "sonnet"

.\run_benchmark.ps1 -Provider Claude -Model "opus" -Profile Full

.\run_benchmark.ps1 -Provider Codex -Profile Core

.\run_benchmark.ps1 -Resume

.\run_benchmark.ps1 -Compare

Składnię możesz zaprojektować lepiej, jeśli będzie prostsza.

================================================================
39. INSTRUKCJE DLA AGENTÓW
==========================

Utwórz:

BENCHMARK_INSTRUCTIONS.md

oraz odpowiednie pliki instrukcji projektowych dla Claude Code i Codex.

Dzięki temu, gdy później otworzę projekt i napiszę:

"Uruchom test Claudem"

agent ma wiedzieć:

* NIE przebudowywać benchmarku,
* NIE zmieniać promptów,
* NIE aktualizować repo,
* znaleźć właściwy provider,
* użyć CORE,
* wznowić kompatybilny przerwany RUN, jeśli istnieje,
* zapisać wyniki.

Dla:

"Uruchom pełny test Claudem"

użyj FULL.

Dla:

"Uruchom test nowym modelem XYZ"

jeśli model nie jest jeszcze w config:

dodaj go do katalogu modeli, ale NIE zmieniaj benchmark definition.

================================================================
40. PORÓWNANIE MODELI
=====================

compare ma wybierać tylko:

COMPLETE runs
ten sam BENCHMARK_SHA256
ten sam PROFILE
ten sam MODE

Jeżeli model został przetestowany kilka razy, domyślnie użyj najnowszego COMPLETE run, ale pozwól wybrać konkretny.

================================================================
41. RAPORT HTML
===============

Generuj lokalny:

comparison.html

Powinien zawierać:

* tabelę modeli,
* wyniki tasków,
* wyniki kategorii,
* PASS/FAIL,
* TP/FP/FN,
* czas,
* zasoby,
* informacje o modelu,
* datę testu,
* benchmark hash.

Dodaj możliwość kliknięcia modelu/tasku i zobaczenia jego pełnej surowej odpowiedzi.

Raport ma działać lokalnie bez serwera [WWW](http://WWW).

================================================================
42. PORÓWNANIE SPRZĘTU
======================

Dla lokalnych modeli zapisuj dokładny sprzęt.

Chcę móc później wykonać ten sam model np. na:

RTX 4060 Ti 16 GB

a następnie:

RTX 3090 24 GB

i porównać:

tokens/s
prompt speed
VRAM
RAM
GPU utilization
power
czas.

Jakość odpowiedzi nie musi być ponownie oceniana, jeśli digest, benchmark i parametry są identyczne, ale zachowaj nowy RUN.

================================================================
43. MODEL IDENTITY
==================

Dla Ollama:

digest jest kluczowy.

Dla cloud:

zapisuj najdokładniejszy identyfikator, jaki provider udostępnia.

Jeśli model jest aliasem mogącym zmienić się w przyszłości:

MODEL_PINNED = NO

i raport ma to wyraźnie pokazywać.

================================================================
44. SETUP NIE URUCHAMIA PEŁNEGO BENCHMARKU
==========================================

Po wykonaniu tego promptu:

1. zbuduj benchmark,
2. zweryfikuj fixtures,
3. zweryfikuj controlled bugs,
4. zweryfikuj baseline,
5. zamroź benchmark,
6. wygeneruj BENCHMARK_SHA256,
7. skonfiguruj providery,
8. sprawdź, czy Ollama/Claude/Codex są wykrywane,
9. wykonaj mały connectivity/self-test providerów, jeśli możliwe bez dużego zużycia limitów,
10. NIE wykonuj właściwego CORE/FULL benchmarku żadnym modelem bez mojego polecenia.

================================================================
45. WALIDACJA BENCHMARKU
========================

Przed zamrożeniem upewnij się, że:

* każdy controlled bug rzeczywiście psuje właściwy test,
* każdy hidden test działa,
* clean fixtures faktycznie nie zawierają celowo planted vulnerabilities,
* vulnerable fixtures mają udokumentowany ground truth,
* task prompts nie zdradzają odpowiedzi,
* żaden testowany model nie ma dostępu do benchmark_private,
* każdy task jest powtarzalny.

================================================================
46. README PO POLSKU
====================

Przygotuj:

README_PL.md

Wyjaśnij:

* czym jest benchmark,
* jak uruchomić model Ollama,
* jak uruchomić Claude,
* jak uruchomić Codex,
* jak wznowić test po wyczerpaniu limitu,
* jak dodać nowy model,
* jak uruchomić CORE,
* jak uruchomić FULL,
* jak porównać wyniki,
* gdzie są surowe odpowiedzi,
* jak interpretować TP/FP/FN,
* jak powtórzyć test po zmianie GPU.

================================================================
47. NIE ULEPSZAJ BENCHMARKU PODCZAS RUN
=======================================

Jeśli podczas testowania modelu zauważysz, że coś w benchmarku można byłoby zrobić lepiej:

NIE zmieniaj aktywnej wersji.

Zapisz sugestię do:

benchmark_improvements.md

Zmiana benchmarku wymaga stworzenia nowej wersji.

Np.:

Benchmark v1

Benchmark v2

Wyników v1 i v2 nie mieszaj jako 1:1.

================================================================
48. PODSUMOWANIE SETUP
======================

Po zakończeniu konfiguracji przedstaw mi:

* ścieżkę projektu,
* FastRoute SHA,
* BENCHMARK VERSION,
* BENCHMARK_SHA256,
* liczbę tasków CORE,
* liczbę tasków EXTENDED,
* liczbę tasków FULL,
* wykryte providery,
* dostępne modele,
* które modele Ollama są już zainstalowane,
* które są tylko zapisane w katalogu,
* jak uruchomić pierwszy benchmark.

Na końcu podaj mi kilka gotowych przykładów:

"Uruchom test qwen3-coder:30b"

"Uruchom test Claudem Sonnet"

"Uruchom pełny test Codexem"

"Kontynuuj przerwany test Claude"

"Dodaj nowy model Ollama XYZ i przetestuj go"

"Porównaj wszystkie ukończone modele"

Nie uruchamiaj właściwego benchmarku, dopóki wyraźnie o to nie poproszę.

Stwórz na tym serwerze prosty serwer MCP do wysyłania powiadomień przez Pushover. Użyj mojego User Key i API Token. Dodaj narzędzie send_notification, które przyjmuje treść wiadomości oraz opcjonalnie: tytuł, priorytet, dźwięk, URL i HTML. Zabezpiecz dostęp tokenem, przechowuj sekrety poza katalogiem publicznym i po wdrożeniu przetestuj działanie. Na końcu podaj mi konfigurację potrzebną do podłączenia MCP do Claude Code.

Napisz mi lokalny skill projektu bez używania skilli Superpowers; po podaniu linku do YouTube albo samego ID filmu sprawdź, czy w podkatalogu filmy/{id}/ istnieje już plik {id}.mp4, a jeśli go nie ma, pobierz materiał z YouTube, przy czym dla samego ID najpierw zweryfikuj, czy taki film istnieje, a jeśli nie, poproś o link lub ręczne skopiowanie pliku; jeśli obraz nie jest potrzebny do dalszej analizy, pobieraj tylko audio; następnie wykonaj pełną transkrypcję za pomocą Whispera, automatycznie dobierając model i sposób działania do specyfikacji mojego sprzętu, wygeneruj napisy z timecodami w formacie nadającym się bezpośrednio do wgrania na YouTube oraz plik Markdown zawierający trzy propozycje tytułu — opisową, chwytliwą i zoptymalizowaną pod SEO — opis odcinka z rozdziałami i słowami kluczowymi SEO, hasztagi oraz tagi YouTube z zachowaniem obowiązujących limitów; samodzielnie zainstaluj wszystkie wymagane zależności i narzędzia, uporządkuj pliki wynikowe w katalogu filmu i dodaj odpowiedni .gitignore, aby duże pliki multimedialne, modele, cache i pliki tymczasowe nie trafiały do repozytorium.

Przygotuj plik .bat startujący sesje Claude Code; skrypt najpierw aktualizuje Claude Code, ale błąd aktualizacji ma tylko wyświetlić ostrzeżenie i nie blokować dalszego działania, następnie skanuje wszystkie podfoldery bieżącego katalogu i dla każdego uruchamia osobną sesję Claude Code w nowej zakładce tego samego okna Windows Terminal z włączonym remote control i skip permissions; nazwa zakładki oraz nazwa sesji remote control mają być identyczne z nazwą katalogu, a Claude nie może nadpisywać tytułu zakładki; pomiń podfoldery zawierające plik .skipclaude, po zakończeniu sesji zakładka ma pozostać otwarta, abym mógł zobaczyć wynik działania, a cały skrypt ma nadawać się do uruchamiania przy starcie Windows.