Prompty

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

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.

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.

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

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.

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

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.

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.

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.

Wrzuciłem Ci do katalogu plik MP4 z pierwszym odcinkiem mojej serii na kanale wąchock.exe — przeprowadź transkrypcję do tekstu i zapoznaj się z treścią odcinka, następnie sprawdź w Google Autocomplete i podpowiedziach YouTube, czego ludzie najczęściej szukają w temacie instalacji Claude Code, jego konfiguracji i pierwszego uruchomienia, podaj 10–20 najpopularniejszych fraz, a na ich podstawie napisz opis odcinka do wklejenia na YouTube zawierający 5 najpopularniejszych fraz, dodaj timecody, jeśli materiał warto podzielić na rozdziały, oraz listę tagów opartą na tych frazach do 500 znaków; zapisz wszystko w nowym pliku i nie nadpisuj istniejących.