Dokumentace/Claude/skills/doubynet/SKILL.md

name, description, metadata

name	description	metadata
doubynet	Update doubynet dokumentation	version v1

Tvým úkolem je zkontrolovat a případně aktualizovat dokumentaci sítě DoubyNet.

1. Načti dokumentaci

/home/honza/Syncthing/Programy/DoubyNet/ (lokální, Syncthing-synchronizovaná složka na Honza-PCL — žádný manuální upload/download, synchronizace na ostatní zařízení běží na pozadí sama):

• README.md (index služeb + sekce "Router — port-forwarding")
• CLAUDE.md (konvence zápisu dokumentace — dodržuj ji při jakékoli úpravě)
• všechny <Hostname>/<Služba>/<Služba>.md soubory
• <Hostname>/CHANGELOG.md (jeden na hosta, průběžný záznam změn — viz krok 4)

Vytvoř si z toho kompletní obraz zdokumentovaného stavu: hosty, služby, jak se spouští, sítě/porty, VM, autostart, propojení mezi službami (např. Caddy → cíl).

Pozor na historické dokumenty. Některé .md soubory popisují něco, co už neexistuje (např. staré, fyzicky rozebrané disky/pole), a mají to nahoře jasně označené (banner typu "⚠️ pole už neexistuje, dokument je od teď čistě historický"). Takový dokument needituj aktuálními fakty — zjištěné aktuální informace patří do dokumentu, který nahrazuje popisovanou věc (banner na to obvykle přímo odkazuje). Smysl historického dokumentu je zůstat nezměněný jako záznam toho, co bylo.

2. Ověř realitu

Pro každé tvrzení v dokumentaci ověř skutečný stav na příslušném stroji (SSH, systemctl, virsh, ss -tlnp, obsah configů apod.). Ověřuj z relevantního hlediska — např. dostupnost webu přes DNAT/reverse proxy testuj z jiného stroje než je cíl (self-test ze stejného hostu může dát falešně negativní výsledek kvůli tomu, jak netfilter zachází s lokálně generovaným provozem).

Některá fakta nejdou ověřit žádným příkazem — typicky cokoliv, co žije jen v UI zařízení bez API/SSH přístupu (např. nastavení port-forwardingu na routeru). V takovém případě si o autoritativní export/screenshot řekni uživateli přímo, místo abys realitu odhadoval nebo nechal needokumentovanou.

Neprováděj destruktivní ani produkci ovlivňující příkazy bez potvrzení uživatele. Pokud narazíš na to, že nemáš potřebná oprávnění (sudo, SSH klíč), zeptej se uživatele, jak pokračovat — nezkoušej to obcházet.

3. Porovnej a nahlas rozdíly

Sestav přehledný seznam nesrovnalostí mezi dokumentací a realitou (co dokument tvrdí vs. co je skutečně nastavené/běžící). Tenhle přehled ukaž uživateli před jakoukoli úpravou souborů.

4. Aktualizuj dokumentaci

Až uživatel potvrdí (nebo pokud jde o triviální/jednoznačné doplnění), uprav příslušné .md soubory tak, aby odpovídaly realitě:

• Dodržuj šablonu a konvence z CLAUDE.md (formát tabulek, PascalCase názvy, atd.)
• Nikdy nezapisuj hesla/tokeny/klíče v plaintextu — nahraď je <PLACEHOLDER> tokenem
• Pokud přidáváš novou službu/VM, přidej ji i do řádku v README.md
• Fakta, co se netýkají jedné služby na jednom hostu (např. síťová topologie, port-forwarding na routeru), patří do vlastní sekce v README.md — nenuť je do složky jedné služby jen proto, že model "jedna složka = jedna služba" jinam nesedí
• Zapiš stručný záznam do <Hostname>/CHANGELOG.md dotčeného hosta (nejnovější nahoře) — co se zjistilo, co se změnilo, proč
• Po úpravách ověř, že žádný relativní markdown odkaz (](...)) nevede na neexistující soubor — procházka stromem a kontrola existence cíle každého odkazu

Žádný manuální "upload" na server není potřeba — soubory žijí lokálně v Syncthing složce, synchronizace běží sama.

Na konci stručně shrň, co bylo nekonzistentní a co jsi opravil.