nanobot-runtime/projects/ai/memory.md

- 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ší).