72 lines
3.9 KiB
Markdown
72 lines
3.9 KiB
Markdown
---
|
|
name: doubynet
|
|
description: Update doubynet dokumentation
|
|
metadata:
|
|
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.
|
|
|
|
|