diff --git a/projects/devops/memory.md b/projects/devops/memory.md
index 62089d7..3a7c30e 100644
--- a/projects/devops/memory.md
+++ b/projects/devops/memory.md
@@ -205,3 +205,4 @@ Z toho plyne, že motivace pro novější HW (nebo rychlou záložní cestu) je
 - nebo prevence: HW stavěný na 24/7
 
 Otevřené rozhodnutí: novější mašina (AM5?) vs. hot standby (Aukro 9020 deska za 3 k) vs. jen pořádné zálohy + runbook pro rychlou obnovu.
+- 2026-09-18: correction: HP Z440 z práce **není dostupný** — místo něho uživatel dostal z práce právě ten Optiplex 9010, na který teď provozuje Proxmox. Z440 jako dlouhodobý kandidát na lepší host padá. Hot-spare cesta tedy zatím nemá konkrétního kandidáta (Aukro deska 9020 za ~3 k zůstává jedinou levnou opcí, po proměření kabelu).
diff --git a/projects/devops/state.md b/projects/devops/state.md
index a64c637..ea5fb40 100644
--- a/projects/devops/state.md
+++ b/projects/devops/state.md
@@ -5,7 +5,7 @@ timestamp: draft
 # Project devops
 
 ## Kde to je
-- **HW základna: Dell Optiplex 9010** (od 2026-09-18). Původní server — **Dell Optiplex 9020** workstation z raných dob RSJ, dlouholetý server (měněny zdroj/kabely/větrák, přidána RTX 4060 (deník: 4060 Ti — neověřeno) + hromada disků) — náhle zemřel (večer 2026-09-17, po vyjmutí RAM pípání chybových kódů; podezření CPU/DDR/deska). Proměřitelná hypotéza: AliExpress kabel zdroj→deska (odcházející měnič). Do 9010 přesunuty RAM, disky i GPU — vše jede; BIOS měl problémy (celý přesun >1 h), změny v BIOSu se neukládají — k dořešení. **Ergonomie 9010 je špatná**: stísněný case, grafika na krev, druhý NVme jen přes placatou PCIe redukci (slot pod grafikou); 550 W noční zdroj dává rezervu, ale práce s mašinou je nepříjemná. **Kapacita vyčerpaná: nic dalšího se do 9010 už nenacpe, max tocivý disk.** Hlavní riziko: 15+ let starý HW nedělany na 24/7 provoz → motivace pro novější HW je spolehlivost (RTO/RPO), ne výkon. Nová sestava (B550-PLUS + Ryzen 7 5700X + 32 GB DDR4 + chladic + case ≈ 16 k) zvažována vícekrát — vždy odložena; marginální upgrade na dead-end AM4/DDR4. Dlouhodobý kandidát na lepší host: HP Z440 z práce (Xeon E5-1650, 6c/12t, 32 GB, 4 volné sloty), pokud ho dostane z vyřazování; zvažováno i vlastní PC z chlívku jako Proxmox host + Windows VM přes RDP. Vyřčená lekce: zálohovat kontejnery z Proxmoxu (nemá se kam — PBS chybí).
+- **HW základna: Dell Optiplex 9010** (od 2026-09-18). Původní server — **Dell Optiplex 9020** workstation z raných dob RSJ, dlouholetý server (měněny zdroj/kabely/větrák, přidána RTX 4060 (deník: 4060 Ti — neověřeno) + hromada disků) — náhle zemřel (večer 2026-09-17, po vyjmutí RAM pípání chybových kódů; podezření CPU/DDR/deska). Proměřitelná hypotéza: AliExpress kabel zdroj→deska (odcházející měnič). Do 9010 přesunuty RAM, disky i GPU — vše jede; BIOS měl problémy (celý přesun >1 h), změny v BIOSu se neukládají — k dořešení. **Ergonomie 9010 je špatná**: stísněný case, grafika na krev, druhý NVme jen přes placatou PCIe redukci (slot pod grafikou); 550 W noční zdroj dává rezervu, ale práce s mašinou je nepříjemná. **Kapacita vyčerpaná: nic dalšího se do 9010 už nenacpe, max tocivý disk.** Hlavní riziko: 15+ let starý HW nedělany na 24/7 provoz → motivace pro novější HW je spolehlivost (RTO/RPO), ne výkon. Nová sestava (B550-PLUS + Ryzen 7 5700X + 32 GB DDR4 + chladic + case ≈ 16 k) zvažována vícekrát — vždy odložena; marginální upgrade na dead-end AM4/DDR4. Dlouhodobý kandidát na lepší host: ~~HP Z440 z práce~~ — padlo, z práce dostal právě ten 9010 (místo Z440); hot-spare zatím bez konkrétního kandidáta, levná opce zůstává Aukro deska 9020 (~3 k, po proměření kabelu). Zvažováno i vlastní PC z chlívku jako Proxmox host + Windows VM přes RDP. Vyřčená lekce: zálohovat kontejnery z Proxmoxu (nemá se kam — PBS chybí).
 - LibreChat: běží jako podman kontejnery; jako Code Interpreter sandbox vybrán LibreCodeInterpreter (nsjail, 3 kontejnery). Research hotový (2026-09-13), rozhodnutí o nasazení (sdílená Docker VM vs dedikovaná Proxmox VM) ještě nepadlo.
 - Ollama na nvidia.hell: po incidentech 12.–13. 9. 2026 zaevidován root cause pádů — kauzální řetěz: ollama rozhoduje load podle VRAM ne volné RAM + vypíná mmap (podmínka na 9,5 GiB stroji nesplnitelná nikdy, regrese od 2026-06-05) + PLE host buffer u gemma4 + přerušený load leakuje napinovanou host paměť (neviditelná pro ps/nvidia-smi/cgtop, detekce jen `nr_foll_pin` delta v /proc/vmstat), uvolní **jen reboot** (rmmod driveru ověřeně NE). Cgroup pojistka (`MemoryMax=6G`, `MemorySwapMax=0`, bez MemoryHigh) ověřena zátěžovým testem: 240/240 SSH heartbeatů, load 3,41 vs 81 při incidentu. Skutečný zdroj zátěže = nanobot.hell (dávky přes ~10 modelů + embedding), LibreChat jen zesilovač. Reporty v `artifacts/2026-09-13_ollama-nvidia-full-report.md` (ucelený, s kuchařkou pro triáž) a `artifacts/2026-09-13_ollama-nvidia-negative-findings.md` (negativní zjištění), shrnutí v memory.md 2026-09-14. Zavržené cesty: earlyoom i jakákoli externí kill varianta, MemoryHigh pod MemoryMax, navýšení RAM (headroom konstanta 7,5 GiB), limit počtu modelů, OLLAMA_LOAD_TIMEOUT, upgrade ollamy, mmap override (neexistuje), ballooning (`balloon: 0` + pevná paměť), rmmod jako remedy.