- 2026-09-02: Založen projekt: deník + hledání řešení pro AI témata (agenti, kódování s AI, LLM).
- 2026-09-02: Incident „gpt 5.3 se zasekl na PH/PZ/TX z mobilu": rekonstruováno — finální odpověď byla kompletní a verzovaná; problém byl agent loop (guard bloky, retry smyčky, ~6-8 min). Model = glm-5.3:cloud (žádný gpt 5.3). Kanál na kvalitu vliv nemá.
- 2026-09-02: Compaction: uživatel si vyžádal drastické zkrácení incident zápisu; detaily zahoz­deny, zachovány jen závěry.
- 2026-09-08: Série měření na Solarflare X2/X4 (TCPDirect, C# knihovna). Claude Code navrhl měřicí setup, aplikace sockbench na měření, Claude spouštěl scénáře, ukládal a vyhodnocoval výsledky. Fungovalo.
Pak cíl: převést proces na ruční spouštění skriptů (PowerShell) pod vlastní kontrolou. Claude zde selhává opakovaně: skripty zbytečně složité, moc parametrů, špatně čekal na dokončení test setu, testoval zbytečné věci. Zadání v plan modu se nedaří, výsledek stále špatný — frustrace, ztracený čas místo ušetřeného.
Uživatelova diagnóza: nedokáže správně popsat zadání; buď málo informací, nebo špatný přístup. Zvažované cesty: napsat kostry skriptů sám s komentáři a nechat Claude dokodovat; lepší projektový dokument; úplně odpoutat se od současné verze a začít znovu. Hledá efektivní způsob práce.
- 2026-09-08: Upřesnění diagnózy (Solarflare/sockbench): Claude si původně napsal runbook pro sebe — pro agenta byl ok, pro člověka nepoužitelný (moc kroků, moc složitosti). Skripty nebyly úplně špatné, ale měly tunu parametrů. Jádro problému: dvě různé cílové skupiny — agent snese libovolnou složitost, člověk potřebuje mnohem menší míru komplexity. Uživatel se o tom v plan modu snažil mluvit, přiblížil se, ale komunikace nestačila.
- 2026-09-08: correction: „úplně znovu od nuly — ne" z minula bylo nedorozuměním. Uživatel tím nemyslel „znovu bez specifikace", ale nepoužít existující runbook a existující skripty jako základ — ty ho limitují a anchornují ho špatným směrem. Restart s jeho vlastní specifikací (tabulka scénářů + kostry) je v pořádku, jediné co ne: recyklace agent-runbooku.
- 2026-09-08: Destilace postupu „převod agent-nástrojů na nástroje pro člověka" uložena jako artefakt: projects/ai/artifacts/agent-to-human-tools.md. Strukturovaný markdown: proč zjednodušení agent-nástrojů nefunguje (neviditelná hranice složitosti, ukotvení existující podobou, plan mode neřeší design), princip „rozhraní navrhuje člověk, model implementuje", 4krokový postup (čistý adresář → tabulka scénář→příkaz → kostry → dokódování těl) a pravidla pro zadání (čísla místo adjektiv, omezení v kódu ne v promptu, agent-runbook nepřevádět). Po vzájemné korektní diskusi: knowledge/ odmítnut, artefakt patří do projektu ai.
- 2026-09-08: Rozbor článku „Don't Chat With Your AI. Mob With It." (Rodenas) + diskuse s Claude uložen jako artefakt: projects/ai/artifacts/file-based-agent-communication.md. Technikou je komunikace s agentem přes tagy v souborech místo chatu. Článková argumentace odmítnuta (latence ≠ GPU sloty; mob analogie obrácená; autonomní smyčka + mazání tagů = ztráta kontrolního bodu a prodloužení feedback loopu pro člověka). Použitelné jádro: anotace patří tam, kde je předmět anotace (pozice = kontext, jako TODO komentář), trvalost v diffu, tag se nemaže jen se připíše odpověď, max 1–2 tagy na kolo, explicitní spouštění místo autonomní smyčky. Otevřená otázka: jak korigovat agentovy odpovědi — kandidát varianta „vlákno jako komentáře v kódu" oproti vedlejšímu .notes.md souboru. Zájem uživatele o vyzkoušení.
- 2026-09-09: Refactoring C# třídy s Claude: iterativní review smyčka a její selhání. Postup „review v nové session, opravy taky v nové session" vede k regresím — každá další session najde další „problémy", část z nich je reverz dříve odsouhlasených rozhodnutí, ne reálná chyba. Nová session totiž nevidí historii a znovu otevírá už uzavřené otázky.

Závěr (podle kolegy, uživatel souhlasí): lepší je hybrid — **review v čisté nové session** (svěží pohled bez anchoringu na vlastní práci), ale **závěry vkládat zpět do původní session**, kde se provádějí i opravy. Původní session má kompletní historii, ví, která rozhodnutí padla a proč, a drží se jich — takže nevrací odsouhlasené změny.

Souvisí s požadavkem na „čistý refaktor": ověření, že se chování zvenku vůbec nezměnilo, má být cílem review, ne vedlejším produktem.
- 2026-09-09: Rozbor článku „LLM jako virtuální projektový tým" (Root.cz, Tonda) a jeho mapování na naše otevřená témata:

- Článkové „přenášej artefakty, ne historii konverzace" = potvrzení našeho závěru z file-based-agent-communication.md i review smyčky. Formulace: kontext = artefakt + role + zadání, nic víc.
- Naše review smyčka (čistá session na review, opravy v původní session s historií) je přesně článkový workflow; náš přídavek, který článek neřeší: kam závěry oponenta vracet — u nás původní session jako decision-history channel. Článek navíc: iterovaná oponentura (A→B→A/C→B) a různé providery pro procesní nezávislost.
- Aplikace na kód: persony s omezeným mandátem (security, API konzument, ops, výkon) místo generického „udělej review" — řeší regresní problém, že každá nová session reverzne odsouhlasená rozhodnutí; omezený mandát nedovolí otevírat usazené otázky mimo scope.
- „Z nápadu hypotéza" = naše „čísla místo adjektiv" z agent-to-human-tools.md. Stage-Gate přenositelný na testy: gates definované předem = co chybělo u Solarflare scénářů.
- Článek ospravedlňuje strukturu project skill (decision log, živý stav). Nový nápad: explicitní registr předpokladů — seznam neověřených věcí, které držíme za pravdu, s dohledatelností závislostí.
- 2026-09-10: Návod „session lifecycle" (kdy zůstat ve stejné session vs. zahájit novou) uložen jako artefakt session-lifecycle-guide.md. Klíčový test: potřebuje další krok historii rozhodnutí (stejná session) nebo svěží pohled (nová session)? Zkratky: chybová smyčka → nová session; po kompakci → radši nová session nad soubory než faded recollection. Hybrid pattern z 9.9. (review v čisté session, opravy v původní) zobecněn jako hlavní vzorec + doplněny mechaniky (anchoring, lost in the middle, kompakce je ztrátová).
- 2026-09-10: correction: Artefakt session-lifecycle-guide.md z 10.9. byl předčasný — návod jsme ještě neudělali, to teprve probereme. Smazán. Nejdřív research online zdrojů (Anthropic + další), teprve pak závěry a návod.
- 2026-09-10: Research „kdy stejná vs. nová session" — probrány online zdroje, než se udělá návod:

1. Anthropic blog „Using Claude Code: session management and 1M context" (Thariq Shihipar): hlavní pravidlo „new task = new session". Každý turn je branching point s 5 volbami: continue / rewind / clear / compact / subagent. /compact = lossy, model summarizuje, lze řídit hintem; špatný autocompact vzniká, když model neumí předpovědět směr práce — a při kompakci je model ve svém nejslabsším bodě (context rot). /clear = člověk si sám napíše, co má přežít. Subagent na chunky, kde potřebuju jen závěr.
2. Anthropic „Best practices for Claude Code" (docs): po 2 neúspěšných korekcích → /clear + lepší prompt; spec → implementace ve fresh session; review ve fresh context (Writer/Reviewer pattern); kitchen sink session jako antipattern.
3. Anthropic „Effective context engineering for AI agents": context rot napříč všemi modely, „attention budget", 3 techniky pro long-horizon: compaction (ztrácí detaily), structured note-taking (NOTES.md — perzistentní paměť mimo window), sub-agents (čistá okna, vrací jen destilát). Hybridní přístup Claude Code: CLAUDE.md dopředu, zbytek JIT.
4. Chroma „Context Rot" (research, 18 modelů): degradace nastává i na jednoduchých úlohách při konstantní složitosti, non-uniformně, s distraktory hůř; NIAH to maskuje. Zdroj termínu context rot.
5. OpenAI Codex best practices: „one chat per coherent unit of work"; „using one chat for an entire project" je v seznamu častých chyb; /fork, /compact, subagents, AGENTS.md/skills pro přenos mezi sessions — konvergentní s Anthropic.

Špatný zdroj: techbytes.app „complete engineer's guide" = AI slop (generická marketingová vata bez reálného obsahu). Lesson: sekundární „complete guide [2026]" weby ignorovat.

Shoda napříč zdroji: nová session při novém úkolu, review ve fresh context, po chybové smyčce restart s lepším promptem, přenos mezi sessions = artefakty (spec, AGENTS.md, NOTES.md), ne historie chatu. Návod teprve budeme skládat.
- 2026-09-10: Draft návodu session-lifecycle (draft, ne finál) — odpovědi na otázky uživatele:

1. Plánování vs pravidlo „2 neúspěšné korekce": signál není počet kol, ale stejná námitka podruhé. Konvergující iterace (nová rozhodnutí, staré námitky se nevrací) je zdravá — decision history je přesně to, co plánování potřebuje. Anchor loop: opakuju stejnou námitku, model kosmeticky přepracovává vlastní draft. Důvod, proč anchoring u plánování silnější než u kódu: chybí externí verifier — jediným faktem je modelův vlastní text, reviduje sám sebe, kosmetika vypadá jako pokrok. Praktika: iterovat v souboru plánu ne v chatu (náš dodatek k Anthropic „spec → fresh session implementace"); stejná námitka 2× → stop → kostru navrhuje člověk (lesson z agent-to-human-tools).

2. „Přenos = artefakty" konkretizace: 3 druhy — repo/diff (hlavní, nese celý stav implementace, nic přenášet nemusím), spec/plan soubor (při plánování), handoff brief (jen na hranici session: rozhodnutí + vyloučené cesty — to nejsou vidět v kódu). Brief píše MODEL na jednu žádost, já jen 30s review — moje práce jedna věta. Trvalé části odtékají do store, které stejně vedu (rozhodnutí → memory.md, opakovaná chyba → CLAUDE.md/AGENTS.md). Nepřenášet: historii chatu, retrospektivy, duplicity kódu.

Draft uložen: projects/ai/artifacts/session-lifecycle-draft.md. Otevřená otázka: hranice „related task" (dokumentace k hotové feature — Anthropic nechává intuici).
- 2026-09-10: Nápad uživatele: /handoff skill pro Claude Code, který sepíše handoff brief pro dalšího agenta. Zhodnoceno jako dobrý (odstraňuje hlavní argument proti „přenos artefakty" — práci navíc na hranici session) a připraven jako artefakt: projects/ai/artifacts/handoff-skill.md (anglicky, instalační cesty personal/project, SKILL.md obsah v markdown fence).

Klíčová designová rozhodnutí: (1) brief je psaný pro čtenáře-agenta se ZERO historií — ne retrospektiva pro člověka: žádná chronologie ani narativ, jen stav+rozhodnutí+vyloučené cesty; neduplikovat repo (reader si přečte kód/diff); nejcennější sekce „Ruled out" — brání dalšímu agentovi chodit do mrtvých endů. (2) disable-model-invocation: true — session boundary akce, ne auto-trigger. (3) user zůstává v loopě jako fact-checker (model píše brief z plného, tedy degradovaného kontextu — rule 5: „if not sure it was decided, mark as open"). (4) Brief je jednorázový; trvalé části odtékají do CLAUDE.md/AGENTS.md/decision logu. Skills = Agent Skills open standard (agentskills.io), takže stejné SKILL.md funguje i v Codexu.
- 2026-09-10: Úprava /handoff skillu po review uživatele: default output je markdown blok v chatu ke zkopírování, NE soubor. Soubor jen na explicitní požádání (default HANDOFF.md v repo root). Důvod: brief je jednorázový, soubor bez čtenáře je clutter; navíc paste funguje i tam, kde target agent nemá přístup k souboru (jiný stroj, jiný nástroj). Upravena description (bez "side-effect: writes a file"), Procedure (render do chatu → unsurity callout → file jen on request → navrh fresh prompt) a Notes/tradeoffs.
- 2026-09-10: Zjednodušení /handoff skillu na návrh uživatele: 3x kratší verze (jeden akapát pravidel + samotná kostra šablony v fenced markdown bloku, bez Rules/Procedure sekcí). Co zůstalo: co psát (jen to, co repo neukazuje), co nepsat (chronologie, kód, narativ), (unverified) markery, kostra sekcí. Co vypadlo: Goal sekce (redundantní s titulkem), per-section vysvětlení, review procedura jako proces (nahrazeno (unverified) inline), file-save flow. Souhlasím — původní verze vysvětlovala věci, které model umí implikovat z šablony. Lessons: skill = šablona + constrainty, ne tréninkový dokument; iterovat přidáváním řádků po reálných selháních, ne upfront.
- 2026-09-10: Self-analysis (na dotaz uživatele „proc jsi sám nevytvořil minimalistickou verzi?"): tři příčiny přepsání /handoff skillu. (1) Psal jsem pro špatného čtenáře — skill čte model, který potřebuje šablonu výstupu + constrainty, ne tréninkový dokument; defaultl jsem na dokumentační styl, protože většina mých artefaktů je pro člověka. Ukázková šablona > popis šablony. (2) Optimalizoval jsem na vypadání důkladně (Rules/Procedure jako zviditelněné uvažování) místo na funkci — uvažování patří do konverzace, ne do artefaktu. (3) Chyběl test „vyrobí tohle spolehlivě dobrý brief?", který se ověřuje použitím a ořezáváním, ne dodáním plné verze bez jediného běhu. Paradox: vlastní rule 4 skillu („be specific, not complete") jsem v samotném skillu porušil. Společný jmenovatel: rozhodnutí podle spotřebitele výstupu, ne podle vlastních zvyků. Diagnostika zrcadlová k Solarflare: tam runbook pro agenta místo člověka, tady pro člověka místo agenta. Pravidlo: před sepsáním skillu určit, kdo ho čte v momentě použití, a psát pro něj.
- 2026-09-10: Prompting recept (na dotaz uživatele „jak to příště zadat, abych dostal lepší výstup?"): pro skládání skillů/artefaktů zadat 4 věci, které mě vedly k přepsání /handoffu: (1) kdo čte výstup v momentě použití (model vs člověk), (2) ukázka/kostra cílové podoby — „chci tohle, jen to napiš pořádně", (3) constraint na délku — „nejkratší verze, která funguje", (4) požadavek na ukázku použití („ukaž výstup na reálném příkladu") — tím se spustí test místo speculativního dodání plné verze. Poznámka pro mě: i bez zadání bych měl (1) a (4) udělat sám; (2) a (3) jsou legitimní požadavky na uživatele, protože definují chuť výstupu.
- 2026-09-10: correction: Položku (1) „kdo čte výstup" z prompting receptu stahuji — u skillů plyne ze samotné definice (soubor pro model v momentě použití), není to legitimní zadání od uživatele, ale moje povinnost. Skutečná příčina: nezapátrání targetu PŘED psaním; default dokumentačního stylu vyhrál, protože čtenář nebyl první určující otázkou. Recept zredukován na 2 položky od uživatele (ukázka/kostra cílové podoby, constraint na délku) + 2 položky moje (čtenář z definice typu souboru, ukázka výstupu na reálném příkladu).
- 2026-09-11: OpenWebUI zakázáno (2026-09-12) — žere sílně paměť a občas zasekne celý server. Jako náhradu chci vyzkoušet LibreChat, konkrétně self-hosted Docker variantu dle oficiální dokumentace:

https://www.librechat.ai/docs/local/docker
- 2026-09-11: LibreChat research done — navrh postupu spusteni pres rootless podman + systemd Quadlet, artefakt: projects/ai/artifacts/librechat-podman/ (README + librechat.network + librechat.container + librechat-mongodb.container + librechat-meilisearch.container). Minimal stack api+mongo (RAG/vectordb/admin-panel vynechany kvuli RAM — duvod odstraneni OpenWebUI). MONGO_URI/MEILI_HOST nutno prepsat na DNS jmena kontejneru (quadlet sit), trvale CREDS_KEY/CREDS_IV/JWT secrets. Quadlet zvolen nad generate systemd (deprecated) a nad podman-compose-oneshot (systemd nevidi kontejnery). Rootless + linger, port 3080. Naseptany plan: nasadit na server (ktery?), pripojit Ollama/litellm endpointy pres librechat.yaml.
- 2026-09-13: - Zjišťování tool-calling schopností Ollama modelů na `nvidia.hell:11434` — jak ověřovat a co metadata neříkají:

**Metoda:** `GET /api/tags` (seznam modelů + `size`) a pro každý model `POST /api/show` → pole `capabilities` (např. `["completion","tools","thinking","vision","embedding","insert","audio"]`). Kombinace těchto dvou endpointů dá kompletní tabulku model × velikost × schopnosti (skript: `workspace/tmp/list_ollama_models.py`, lze přesunout do artifacts).

**Co `capabilities` je a není:** je to deklarace odvozená z Modelfile/manifestu modelu — Ollama tak *inzeruje* model jako tool-capable. Není to funkční test: neznamená to, že model vrátí validní `tool_calls` v odpovědi na `POST /api/chat` se `tools` v requestu. Metadata ⇒ kandidáti; funkční test ⇒ skutečná podpora.

**Zásek: `qwen3-embedding` hlásí `tools` v capabilities, ale je to embedding model** — capabilities u něj nelze brát doslova, vždy křižovat s rodinou modelu.

**Zjištěné výsledky (2026-09-12):** 57 modelů na instanci; lokálních s `tools` pod 10 GB cca 24 (nejmenší `lfm2.5-thinking` 0.7 GB, největší `gemma4`/`gemma4:e4b` 9.6 GB). `:cloud` modely mají size 0 GB (pointer na Ollama Cloud, neběží lokálně — do kritéria velikosti na disku nepatří). `gemini-3-flash-preview:cloud` vrací `POST /api/show` HTTP 410 Gone — mrtvý pointer, Ollama Cloud model stáhla.

**Otevřené:** funkční test tool callingu (reálný `tools` request na každý kandidát a ověření validního `tool_calls` v odpovědi) ještě neproveden — nabídka visí.
- 2026-09-13: Funkční test tool callingu lokálních Ollama modelů na `nvidia.hell` dokončen (18 modelů, 10 scénářů, anglické prompty).

**Skript:** `projects/ai/artifacts/ollama-toolcall-test.py` — 10 scénářů rostoucí obtížnosti (S1 direct call, S2 implied call, S3 tool selection ze 3, S4 context resolution, S5 více parametrů, S6 no-tool restraint — NESMÍ volat, S7 multi-call dvě volání, S8 result reasoning, S9 diakritika v argumentu, S10 distractor selection z 5 nástrojů). Každý scénář 2 fáze: vyslat správný tool call + zpracovat vrácený výsledek. Spouští se per model: `PYTHONUNBUFFERED=1 uv run ollama-toolcall-test.py <model>`. Přísný parser (odmítl vnořené arguments u nemotronu — reálný klient unwrap nedělá).

**Čisté 10/10:** granite4.1:8b (5.3 GB, 26s, nejlepší balance), lfm2.5-thinking (0.7 GB, 27s — pozor, 1B model, slabá sémantika, ale mechanika solidní), ministral-3 (6.0 GB, 27.5s, nejrychlejší eval ~332ms), ornith (5.6 GB, 46s), qwen3.5:9b (6.6 GB, 73s), qwen3 (5.2 GB, 89s — pomalý, thinking model).

**Selhání podle vzorců:**
- Over-eager calling (S6 fail — volá i když nemá): deepseek-v3, llama3.2 (jinak 9/10).
- S7 multi-call bug (jen jedno volání z dvou): granite4 (9.5/10), granite4:tiny-h (8/10).
- Prázdné odpovědi/args: granite4:tiny-h (S3), granite3.3 (S7.5/10 — S6 odpověděl prázdný text, S3 prázdné arguments).
- Iniciativa (umí volat jen na explicitní pokyn, jinak čeká/odpovídá textem): mistral-nemo (7/10 — S4/S8 „Shall I proceed?", S8 vrátil giphy GIF link), mistral (5/10 — při implied call vypíše JSON volání jako text a **halucinuje výsledek**, S6 odpověděl voláním get_weather s city=Berlin).
- Template mismatch (tool call jako plaintext, syrové speciální tokeny): phi4-mini (1.5/10), phi4-mini-reasoning (netestovatelný — reasoning CoT tolik zpomalí, že ~3 min bez odpovědi).
- Vnořené arguments (`{"type":..., "arguments":{...}}` místo přímých parametrů — sémanticky správně, formálně rozbité pro standardního klienta): nemotron-mini (5.5/10), dřív i aya-expanse.
- Sejmuly server (memory watchdog na nvidia.hell zabil llama-server — `Remote end closed connection`): aya-expanse (5.1 GB, hned na S1), qwen3.5 (6.6 GB, na S10 s 5 nástroji; do S9 byl 9/9 PASS, qwen3.5:9b S10 ale zvládl — rozdíl mezi tagy nebo náhoda v načítání).
- Vynechané dle zadání uživatele: gemma4-uncensored, qwen3.5-uncensored; gemma4/gemma4:e4b (9.6 GB) dřív sejmul server, scope ukončen u mistral-nemo (7.1 GB).

**Poznatky pro budoucí testy:**
1. Jeden prompt nestačí — s českým promptem lfm2.5-thinking failoval na S1 (city=„Berlin"), s anglickým 10/10. Malé modely rozhoduje jazyk promptu, ne schopnost.
2. S6 no-tool restraint je filtr, který vypadlo víc modelů než kterákoli jiná kategorie.
3. Více nástrojů v promptu = vyšší paměťové nároky = watchdog kill. Testovat vícenástrojové scénáře jen u finálních kandidátů.
4. Rodinné vzorce: granite = disciplína (S6 umí), qwen = spolehlivý tool calling, phi4 = rozbitý, mistral rodina = problém s iniciativou.
5. Čas v summary skriptu je wall-clock celého běhu včetně prvního načtení modelu; `load_duration` z API se vypisuje zvlášť (load>0 jen při prvním requestu).

**Doporučení pro agenta / tool use:** granite4.1:8b (nejlepší balance), ministral-3 (nejrychlejší), qwen3 (spolehlivost, pomalejší).
- 2026-09-13: Cena/výkon srovnání plných desítek + rozhodnutí testovat finální kandidáty doplněk: uživatel si vybral tři finalisty (lfm2.5-thinking, granite4.1:8b, ministral-3), lfm vypadá nejlépe (nejmenší velikost + rozumný čas). Domluveno: na finalisty pustím **náročnější sadu testů** pro lepší rozlišení — vstupní 10 scénářů už je plní neseparuje (všichni 10/10).
- 2026-09-13: Uživatelova zkušenost: **Ollama na nvidia.hell je výrazně nestabilní** — padá, když něco nezvládne (neznámý request, špatně zvládnutý model/template) nebo když přetíží stroj (paměť). Pro uživatele **v praxi nepoužitelné**; je z toho dost zklamaný.

Koreluje s dřívějšími nálezy z tool-call testů (2026-09-12/13), kdy nestabilita nebyla ojedinělá, ale systémový vzorec:
- Memory watchdog na nvidia.hell opakovaně zabíjel llama-server (`Remote end closed connection`) — sejmul ho aya-expanse (hned na S1), qwen3.5 (na S10 s 5 nástroji), dřív i gemma4/gemma4:e4b (9.6 GB).
- Více nástrojů v promptu = vyšší paměťové nároky = watchdog kill. Pády nejsou náhodné — spouští je kombinace velkého modelu + většího kontextu.
- phi4-mini-reasoning: reasoning CoT tolik zpomalí, že ~3 min bez odpovědi — Ollama se nezachytí ani graciozně.
- gemini-3-flash-preview:cloud vracel HTTP 410 Gone — mrtvý cloud pointer v instanci.

Závěr uživatele: současný stav (modely pod 10 GB na této GPU instanci) není použitelný pro reálný provoz, jen pro testy. Otevřené otázky pro případné hledání řešení: stabilizace Ollama serveru (limit paměti per model, OLLAMA_MAX_LOADED_MODELS, auto-restart), alternativní runtime (llama.cpp server přímo, vLLM), nebo kapacitnější hardware.
- 2026-09-13: Research alternativ k Ollama (uživatel: nestabilita na nvidia.hell je v praxi nepoužitelná). Root cause potvrzen: watchdog killy = OOM na RAM, llama-server je stejně llama.cpp — problém je Ollamina heuristika offloadingu/kontextu, ne engine sám. Alternativy ověřeny z více zdrojů (codersera, local-llm.net, inventivehq, r/LocalLLaMA thread k postu „Friends Don't Let Friends Use Ollama", duben 2026): (1) llama.cpp llama-server + llama-swap — konsensus komunity, OpenAI-compatible API, hot-swap modelů, explicitní -c/-ngl kontrola → doporučeno uživateli; (2) vLLM — pro multi-user serving, na RTX 4060 tight (safetensors, KV cache overhead), odloženo; (3) LM Studio/Jan — zavrhnuté (Electron, closed source); (4) zůstat na Ollama + hardening (OLLAMA_MAX_LOADED_MODELS=1, systemd Restart/MemoryMax) — fallback. Čeká se na rozhodnutí uživatele, nabídka přípravy llama-swap yaml + systemd unit + litellm wiring.
- 2026-09-14: Tool llmfit — poznámka z článku uloženého přes /bookmark (Medium, Data Science Collective, Anubhav, 5 dní zpět; fulltext v db/bookmark.sqlite, bookmark #1):

- **llmfit** = CLI tool (brew install llmfit, binárky na releases page), projde ~13k modelů a ohodnotí, co se vejde do RAM/VRAM na daném stroji + odhad tokens/s.
- **Fit je spolehlivý** — je to aritmetika (parametry × bits ÷ 8 + context cache), kterou si může každý spočítat sám. Článek: „the arithmetic behind it is arithmetic you can check yourself".
- **Tokens/s je guess** — vzorec memory bandwidth ÷ model size × konstantní efficiency factor 0.55 (nikdo nevypočítal, ručně zvoleno, ověřeno na 3 mašinách, stejné pro všechny karty). Deklarovaná 30% error band, reálně až 2x off (quoted 337 → measured 16). Počítá proti celkové VRAM karty, ne proti volné.
- **Klíčové pravidlo čtení**: vedle čísla je label zdroje (measured vs formula) — formule = ceiling, nikdy reálný výkon. Katalog má jen 1412 reálných měření vs ~13k modelů.
- Další příkazy: `llmfit info "<model>"` (odkud číslo přišlo), `llmfit plan` (jaký HW model potřebuje), `llmfit bench` (reálné měření 3 inference passes — tohle nahrazuje odhad).
- Skórovací heuristika je zastaralá — kvalita se dědí podle nejdelšího rozpoznaného prefixu rodiny, tabulka má 20 řádků, takže qwen3.6/3.8 dědí skóre po starších verzích → často doporučuje zastaralé modely.
- Relevantní pro náš kontext: potvrzuje naši zkušenost z tool-call testů, že tokens/s a výkon závisí na loaderu, ne jen na HW (13.69 vs 4.51 tok/s pro tentýž 4-bit model na stejné kartě, jiný engine). Alternativa pro sizing: llama-fit-params z llama.cpp — čte volnou paměť v reálném čase, říká, co musel ořezat.
- 2026-09-14: Zhodnocení článku „A global CLAUDE.md and its best pieces" (Reza Rezvani, Medium, 2026-09-06) — global CLAUDE.md jako kontrakt s modelem, 8 pravidel, ~130 řádků.

**Co už máme:** surgical changes, minimal code, escalate jen u nevratných akcí, „green není důkaz" — vše už v AGENTS.md skoro doslova. Článek = potvrzení, ne novinka.

**Přínosné pro nás:**
- Decay mechanism: chyba 1× → řádek s datem do lessons-logu, 2× → do pravidel, po 90 dnech bez výskytu → demotion zpět do logu. Naše AGENTS.md/SOUL.md jen rostou; compact-memory řeší MEMORY.md, ne soubory pravidel. Kandidát na heartbeat task nebo rozšíření compact-memory.
- „Každé pravidlo pojmenovává konkrétní selhání" — test před přidáním řádku; píšeme pravidla i spekulativně.
- Closing report per acceptance criterion, silence = not met — silnější než naše „neohlašuj splnění bez toolu"; kryje vynechaný krok v reportu (omission is not lying).
- Prose rule broken twice → hook, konvence [hook] tagu — potvrzení našeho exec guard přístupu.

**Pro uživatele přímo:** Prompt 1 (merge CLAUDE.md template s inventářem prostředí) a Prompt 6 (quarterly trim) použitelné v Claude Code na devlin.hell.

**Odmítnuto:** kopírovat celý soubor (polovina řádků specific pro autorův stroj); článek je anekdotický, bez měření.
- 2026-09-14: Zhodnocení článku „Frontier AI: Claude Code and Codex Still Use grep. Why?" (Stéphane Derosiaux, Level Up Coding / Medium, ~2026-09) — proč frontier agenti místo AST/LSP/grafů/embeddings používají rg, find, cat.

**Hlavní zjištění autora:**

- **Discovery vs. navigation vs. verification.** Klíčová myšlenka: LSP/AST je skvělý, jen když už agent ví, co hledá (symbol `PaymentRetryHandler`). Při otevřené otázce („co způsobuje duplicitní platby?") musí agent nejdřív objevit slovník problému — retry, idempotency, webhook… — a k tomu je textové hledání nejlepší nástroj. Pipeline: grep = discovery, LSP/AST = navigation, compiler/testy/runtime = verification. grep je začátek, ne celý workflow.
- **Kód je malá část repa.** Repo = kód + YAML, Terraform, Helm, SQL, markdown, ADR, migrace, feature flags, config. Jeden `rg "PAYMENT_TIMEOUT"` najde zdroj + test + helm values + README + migration notes — jedním dotazem rekonstruuje chování + config + historii + očekávání testů. Code graph je jen jedna projekce systému.
- **Strukturované nástroje mají model boundary.** LSP/AST vidí jen statické symbolické relace; nevidí reflection, DI, makra, dynamické importy, plugin loading, dispatch z configu, SQL stringy, Kafka topicy. `Class.forName(config.get("processor"))` — call graph je neúplný, text/config prozradí skutečnou hranu. grep ukazuje hrany, které žijí mimo model nástroje.
- **Negative evidence.** Nula výsledků v `rg` = silný důkaz o repu. U indexované abstrakce může nula znamenat cokoli (neindexováno, nevyřešeno, generováno jinde, špatný workspace). Agent potřebuje nástroje, kde absence je signál, ne hluchá místa middlewaru.
- **grep = univerzální fallback.** Stejné primitivy fungují v Javě, Rustu, Terraformu, SQL i mixed monorepu. LSP per jazyk (jdtls, rust-analyzer, gopls, pyright, tsserver, clangd) = instalace, indexace, udržování middlemana. Harness je lepší s primitivy se stabilní sémantikou napříč repozitáři.
- **Kompozice > velký tool vocabulary.** Malá shell slovní zásoba (rg, find, sed, head, xargs, git log -S) se skládá do obrovského prostoru dotazů a je masivně v trénovacích datech. Oproti 20+ úzkých specializovaných toolů (find_symbol, find_references, find_callers…). Kompoziční primitivum > inteligentnější ale užší tool.
- **Trénink je jen půl vysvětlení.** Modely jsou výborné v shellu (GitHub, Stack Overflow, tutorials), ale to nevysvětluje, proč grep zůstává *architektonicky* užitečný — to dělají výše uvedené důvody.
- **Repo není správná jednotka.** Systém žije napříč kódem, configem, infrastrukturou, runtime chováním, datovými toky, schématy, ownershipem a business pravidly (příklad: POST /payments → PaymentService → Kafka topic → consumer → DB tabulka → PCI policy → tým). Budoucnost: kombinace lexikálního + strukturálního + runtime pohledu v jednom modelu systému („system graph"), ne file navigation „stylem 2000s".

**Relevance pro nás:** článek je přesně o našem denním chodu (harness design, tool vocabulary, guard proti exec). Hlavní lessony:
- U nanobot toolů držet primitiva kompoziční (read/grep/exec) místo trendu „20 specializovaných toolů" — potvrzuje současnou architekturu.
- Negative evidence jako designové kritérium toolu: výsledek musí být jednoznačně interpretovatelný, žádný fallibilní middleman.
- grep/rg nejsou legacy z tréninku, ale strukturálně správná volba pro fázi discovery — relevantní pro debaty o embeddings/indexech (náš wiki embeddings: full reindex při změně enginu, index = middleman s boundary).
- 2026-09-14: correction: dnešní dva zápisy (výuková session o RTX 4060 Ti a zpětná vazba na ni) byly omylem oříznuty z paměti — uživatel chtěl smazat jen artifact soubor, paměť ponechat. Obnoveno v plném znění:

[obnovený zápis 1] Výuková session: uživatel chce rozumět hardwarové vrstvě své RTX 4060 Ti 16GB — výpočetní jednotky (SM/CUDA/tensor cores), data path RAM→VRAM→jednotky, rozdíl inference vs trénink, memory-bound decode. Motivace: lépe chápat chování Ollamy na nvidia.hell (OOM killy watchdogu, layer offload, limity tok/s dle bandwidth). Klíčové spojitosti: 288 GB/s bandwidth = horní limit decode tok/s, KV cache roste s kontextem (koreluje s watchdog killy). Artifact soubor později na žádost uživatele smazán.

[obnovený zápis 2] Zpětná vazba na výukovou session o RTX 4060 Ti: první verze byla odmítnuta — příliš "hop", hromada spec-čísel místo mechanistického vysvětlení. Uživatel chce proces: co se skutečně počítá v transformeru, jak interní jednotky (CUDA core vs tensor core mechanicky) fungují a kde se zapojují, detailní inference vs trénink průchod. Lesson: u výukových dotazů tohoto typu -- mechanistický průchod, ne spec tabulky.
- 2026-09-15: - Zkušenost s navrhováním skillů v nanobotu: výsledky jsou dost žalostné — kostra není špatná, ale nanobot nedohledá různé detaily a problémy tak, jak je to pak udělá Claude Code. To je důvod, proč všechny zásadní opravy a nové skilly dělá uživatel v Claude Code. Nanobot plánovač jde ale točit a ladit — sám odchytí plno chyb a doladí se k uživatelově spokojenosti (příklad: skill /usage). Uživatelův rozbor: není to úplně chyba modelu, který nanobot používá, a asi ani ne nanobota samotného — spíš to je dáno tím, jak je nanobot koncipovaný.
- 2026-09-15: - Rozbor, proč je navrhování skillů v nanobotu slabé (uživatel přímo): (1) nanobot je s řešením moc rychle hotov — žádný důsledkový průzkum po prvním návrhu, (2) chybí plánovací mód, kde uživatel může komentovat, co se mu nelíbí, dřív než se něco implementuje, (3) nanobot je málo kritický ke svým vlastním řešením. Odtud workflow: návrh/ladění plánu s nanobotem (iterativně, /usage jako důkaz, že to jde), finální implementace v Claude Code.