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