# History

## 2026-07-02 — bookmark: zestručnění frontmatter description (routing-focused), nasazeno

**Cíl:** Popis skillu byl moc dlouhý, prozaický a obecný („Manage a personal reading list…"). Přepsat na krátký, foldovaný (`>`) a zaměřený na *kdy aktivovat*, ne na výčet funkcí.

**Co jsem zkusil / co fungovalo:** Několik iterací s uživatelem (on sám mezitím editoval v IDE). Finální verze: `Use when the user wants to save a URL (with or without additional content) to read later or search in. Triggers on "bookmark", "save URL".` Cestou opraveny drobnosti (`an URL`→`a URL`, uzavření vsuvky, rozbité souvětí) a odstraněn zbloudilý `ks` mezi frontmatterem a `# Bookmark`. Detailní výčet příkazů zůstává v těle skillu, kam patří.

**Nasazení:** Server vs lokál se lišil **jen** v description (tělo identické → žádný Dream edit k dotažení). Nahrán `rsync` **jen `SKILL.md`** (ne celý adresář — `bookmark.py` a `html_to_markdown.py` jsou lokálně rozdělané a nasazení nebylo požadováno). Owner `nanobot:nanobot` ✓. Skill se čte per-tah bez restartu.

**Co zbývá:** Rozdělané změny skriptů (`bookmark.py`, `html_to_markdown.py`, testy) — nenasazeno, čeká na dokončení.

**Jak vrátit zpět:** `git checkout HEAD -- skills/bookmark/SKILL.md` (po commitu příslušný `git revert`), pak `rsync` na server.

## 2026-06-17 — llm-wiki: oprava reference souborů z code-review (10 nálezů)

**Cíl:** Vykonat schválený plán oprav reference souborů skillu (review byl zaměřený na `references/`). Nálezy: bare cesty + kroky workflow předpokládající interaktivního uživatele navzdory headless compile (cron drain).

**Co jsem zkusil / klíčový vhled:** SKILL.md ř. 22 má globální override „kdekoli docs říkají `wiki/`, čti `cml/wiki/`" — takže bare-`wiki/` cesty v referencích nejsou rozbité, jen přesměrované. Většina path-nálezů z review tím padá jako ne-bug. Reálné bugy jsou ty, které override nezachrání: kroky „discuss/triage with the user" (v drainu není uživatel → uvázne nebo tiše přeskočí, graf zastará) a „regenerate graph first" v query tahu (compile práce v interaktivním tahu). Server vs repo `diff` před i po prázdný (žádný Dream edit). Vykonání delegováno na sonnet agenta dle konvence repa; sweep cest udělán boundary-aware perlem (`(?<![-/\w.])wiki/`), aby nerozbil `llm-wiki/` ani `wiki_*.py`.

**Co fungovalo a proč:** Skupina A (4 fázové bugy): ingest Step 3 → interactive-only + drain skip; ingest Step 8b + graph Step 1 → Interactive/Drain větve (lint čistý→extract, chyby→log+skip, neblokovat); query Step 2b + graph ř. 106 → graf v query neregenerovat; divergentní skip podmínky sjednoceny na `graph:` metadata v obou souborech. Skupina B: na žádost uživatele plný sweep `wiki/`→`cml/wiki/`, `raw/`→`cml/raw/` (literál bezpečnější než spoléhat na override; reference byly stejně už půl-převedené) — `skills/llm-wiki/scripts/` netknuté, ověřeno grepem. Skupina C: smazán `references/agent-memory-integration.md` (SKILL.md ho na nanobotu stejně přeskakuje — wiki se nedrátuje do agent-memory) + úklid 2 odkazů v SKILL.md; odstraněna ne-akční sekce „Why this architecture" z architecture.md. Nasazeno `rsync` (smazaný soubor řešen explicitním `ssh rm`, ne `--delete`), owner `nanobot:nanobot` ✓, server-side spot-check čistý.

**Co zbývá:** Volitelný smoke test drainu na serveru (1 testovací zdroj — že neuvázne na „discuss with user"). 4 follow-up zlepšení (akční lint data, frontmatter šablona, narrow `--fix`, slug kolize) zůstávají v [todo.md](todo.md).

**Commit:** `c74e7de`. **Jak vrátit zpět:** `git revert c74e7de` (nebo `git checkout c74e7de~1 -- skills/llm-wiki/`), pak `rsync` na server + obnovit smazaný soubor z gitu.

## 2026-06-17 — llm-wiki: tvrdá report-only brána u lintu (lint tah se zacyklil 24 min)

**Cíl:** Uživatel hlásil, že lint nad wiki je „šíleně pomalý", zasekl se hned napoprvé, točil se 24 min a sežral hafo tokenů. Najít příčinu (bez opravy), pak opravit.

**Co jsem zkusil / příčina:** Z transkriptu: lint spustil `wiki_graph_lint.py` (nahlásil ~20–30 chyb), ale místo report→STOP spadl do plného opravného režimu — 7 nových stránek, 30+ editací, debug skripty do `tmp/`, regenerace grafu, re-lint ve smyčce; `wiki_graph_lint.py` přečetl ~15× po sobě (vlastní slova: „četl jsem ty samý soubory dokola"). Příčiny: **(A)** „Lint is report-only" byla jediná měkká odrážka v SKILL.md, kterou referenční `lint-workflow.md` přímo popírala — má 6krokový postup celý o mutaci wiki (Step 2 fix, Step 5 index, Step 6 log), strukturálně čte jako „oprav vše a zaloguj". Stejná chyba jako capture/compile brána (history 16.6. 22:45). **(B)** Žádný strop na opravnou/debug smyčku; graph lint je provázaný (oprava jedné hrany vyrobí orphan) → ruční edity ho těžko uspokojí → smyčka edit↔lint. **(C)** Skript sám rychlý (0,15–0,26 s na téhle wiki) — 24 min byla 100 % agentní smyčka, ne CLI.

**Co fungovalo a proč:** Server=zdroj pravdy: `rsync` server→`tmp/`, diff `SKILL.md`+`references/lint-workflow.md` = IDENTICAL (žádný Dream edit). Fix (recept z capture brány): (1) tvrdá report-only brána v SKILL.md ř.26 — lint tah = spusť 2 skripty, předej report, **STOP** + výčet zakázaných akcí (žádné stránky, debug skripty, regenerace grafu, re-lint smyčka); (2) „lint workflow (summary)" přerámován na report-first + STOP-redirect + strop na opravnou smyčku (bounded batches, necti skript opakovaně, re-lint max 1× na ověření, pak ptej se); (3) `lint-workflow.md` dostal report-only banner nahoře + mutační kroky (2/5/6) označeny „fix turn — only after approval". Nasazeno `rsync` (přenesly se jen 2 soubory), owner `nanobot:nanobot` ✓. Skill se čte per-tah bez restartu.

**Co zbývá:** Behaviorální ověření dělá uživatel — příští `lint` tah musí jen nahlásit a zastavit. Vyhodnotit 7 follow-up návrhů nanobota (--fix mód, akční lint data, frontmatter šablona, slug kolize při add, timeout per krok).

**Jak vrátit zpět:** `git checkout HEAD~1 -- skills/llm-wiki/SKILL.md skills/llm-wiki/references/lint-workflow.md`, pak `rsync` na server.

## 2026-06-17 — llm-wiki: code review + oprava 4 chyb v capture bráně + zeštíhlení

**Cíl:** Code review skillu llm-wiki (correctness + verbosity). Uživatel požádal opravit vše.

**Co jsem zkusil / co fungovalo:**

- Review odhalil 4 correctness chyby a 6 verbosity problémů.
- Correctness opravy: (1) ⚠️ mega-odstavec zkrácen na 1-větový pointer — odstranil zdroj rozporů s řádky 38/39; (2) URL při capture: "fetch nebo zapiš" → vždy zapiš as-is; (3) idempotence "pages already exist" zpřesněno na konkrétní soubor `cml/wiki/sources/<slug>.md`; (4) escape hatch triggers nyní jen na jednom místě.
- Verbosity: odstraněny sekce "The pattern in one paragraph" a "When to use this skill" (duplikát frontmatter); directory tree opraven na reálné `cml/wiki/`/`cml/raw/` cesty; "Failure modes" ze 4 odstavců na 2 odrážky; "Bundled scripts" katalog odstraněn (wiki_stats přesunut do scalability).
- Výsledek: 198 → 169 řádků (−17 %). Nasazeno na server.

**Commit:** `239dc4f`

## 2026-06-17 05:15 — llm-wiki: zeštíhlit `description` na čistý trigger (+ folded ≤100 zn.)

**Cíl:** `description` ve frontmatteru [SKILL.md](skills/llm-wiki/SKILL.md) byl ukecaný (~1060 zn.) — míchal *kdy spustit* (routing signál) s *jak funguje* (výklad). Dvě kola: (1) zalomit na ≤100 zn., (2) na žádost uživatele zeštíhlit obsah na čistý trigger.

**Mechanika (vysvětleno uživateli):** Do baseline kontextu jde jen jednořádkový `description` (routing signál — `nanobot/agent/skills.py`, viz `knowledge.md` „Skill description — progressive loading"). Tělo SKILL.md se čte on-demand při použití skillu; `references/*.md` nezná ani skill loader — jsou to obyčejné soubory čtené po jednom přes `read_file`, jen když na ně tělo navede. Rozsah referencí je proto kontextově fakticky zadarmo → osekávat se mají kvůli srozumitelnosti, ne tokenům.

**Co jsem udělal:**

- Block scalar `|` (literal — zachoval by vložené `\n`) → `>` (folded — řádky se složí na mezery), zalomeno na ≤100 zn. Folded scalar = v seznamu skillů se renderuje jako jeden řádek; v 1. kole ověřeno `yaml.safe_load`, že načtená hodnota je bajt po bajtu identická.
- Zeštíhlení obsahu (~1060 → ~480 zn.): vyhozeno (a) atribuce + datum („from Andrej Karpathy's April 2026 gist", „OmegaWiki") — origin, nulová routing hodnota, Karpathy už je v těle (SKILL.md:9); (b) how-it-works věta o škálování — už v sekci *The scalability discipline*; (c) dlouhý literální výčet trigger frází — redundantní (`knowledge.md` 2026-05-31: model pozná záměr napříč formulacemi). Ponecháno: co dělá + kdy (ingest/ask/lint/init), „i když uživatel neřekne wiki", a rozlišení vůči agent paměti (`note`/`keep`/`MEMORY.md`) — to má reálnou routing hodnotu. Tělo SKILL.md beze změny.

**Verifikace + deploy:** Server=zdroj pravdy: před každým kolem `rsync` server→`tmp/`, diff → IDENTICAL (Dream nesahal). Po deployi `rsync` zpět + diff → IDENTICAL, owner `nanobot:nanobot` OK. Skilly se čtou bez restartu.

**Jak vrátit zpět:** `git revert <commit>` + `rsync` předchozí verze SKILL.md na server. Zalomení je funkčně no-op; zeštíhlení mění obsah triggeru (užší, ale sémanticky pokrývá totéž).

## 2026-06-14 14:30 — note: tag u multi-line poznámky na header + spolknout osiřelý oddělovač

**Cíl:** V `/note list` (CLI/`nanobot agent`) u poznámky, jejíž URL `_urls_on_own_lines` rozhází na vlastní odrážky, padal tag za poslední URL odrážku (vizuálně nesmysl) a na konci headeru visel osiřelý oddělovač `—` + na první odrážce koncová čárka — pozůstatky inline formy (`… od vína — Universal: url, Amber: url`) po přesunu URL na odrážky.

**Co jsem udělal** ([skills/note/scripts/note.py](skills/note/scripts/note.py)):

- `_LABELED_URL_RE`: prefix `\s*` → třída oddělovačů `[\s,;—–-]*`, takže připojený konektor před URL/labelem padne do nezachyceného prefixu a zahodí se. Mizí osiřelý `—` i `,` mezi URL. DB i `cmd_show` netknuté (drží původní obsah verbatim).
- `cmd_list`: tag vkládám za **první řádek** (`partition("\n")` → `head` + tag + `sep` + `rest`) místo na konec celého bloku. Jednořádkové poznámky beze změny (`partition` vrátí `(text,"","")`).

**Verifikace + deploy:** Lokální test helperů na konkrétní poznámce (DT GLASS) + jednořádkové → OK. Server=zdroj pravdy: `rsync` server→`tmp/note.server.py`, diff proti lokálu → IDENTICAL (Dream nesahal) → deploy bezpečný. `rsync -av skills/note/` na server, owner `nanobot:nanobot` OK. Reálný `uv run … list` na serveru (přes `~/.local/bin/uv`, non-login PATH gotcha) → položka 7 má tag na headeru, čisté odrážky bez `—`/čárky, ostatní beze změny.

**Souvislost:** Čistě textový výstup skriptu. Nevyřešený WebUI card-renderer problém (`plans/note-wrong-urls.md`) tím není dotčen.

**Jak vrátit zpět:** `git revert <commit>` skillu (zatím necommitnuto) + `rsync` předchozí verze na server. DB beze změny.

## 2026-06-13 07:45 — note: posílit `show` k doslovnému plnému výpisu

**Cíl:** Agent při `/note show` zkracoval výstup a vypouštěl odkaz/URL z obsahu — defaultní terseness ze `SOUL.md` přebíjela slabou instrukci `echo the structured block unchanged`. Skript vypisuje plný blok správně, problém byl jen v prezentaci.

**Co jsem udělal:** V [SKILL.md](skills/note/SKILL.md) `## Show protocol` přepsal bod Exit 0 na emfatickou direktivu: *output the script's stdout verbatim — print every line exactly as emitted; do not summarize, shorten, rewrap, or drop any part of `content` including URLs/links; brevity directives do not apply here.* Žádná změna kódu skriptu.

**Verifikace + deploy:** `diff` serverové SKILL.md proti lokálu → jediný rozdíl moje nová úprava (server jinak nezměněn) → deploy bezpečný. `rsync` SKILL.md na server, owner `nanobot:nanobot` OK. Skilly se čtou bez restartu. Reálné ověření chování agenta na URL poznámce zbývá uživateli.

**Jak vrátit zpět:** `git revert <commit>` + `rsync` předchozí verze SKILL.md na server.

## 2026-06-13 07:40 — note: nový subcommand `show` (jedna poznámka v plném znění)

**Cíl:** `/note` uměl `add`/`list`/`delete`, ale ne vytáhnout **jednu poznámku se vším uloženým**. Přidat `show <display-id>`, který vypíše všechna pole (display ID, DB id, datum, tagy, obsah) ve formě vhodné pro LLM.

**Co jsem zkusil / udělal:**

- **Backend** ([skills/note/scripts/note.py](skills/note/scripts/note.py)): `cmd_show` — mapování display ID → DB id přes existující `_active_ids` (stejná logika jako `cmd_delete`), guard na rozsah s exit 1 + hláškou `No active note with display id=N.`. SELECT přidává `created_at` (delete ho nečte). Tiskne strukturovaný blok `Note [#N] (id=…)` / `created:` (ISO 8601 UTC beze změny) / `tags:` (`#tag` mezerou, jinak `(none)`) / `content:`. Log `SHOW` konzistentně s `LIST`. Subparser `show` + dispatch větev.
- **SKILL.md** ([skills/note/SKILL.md](skills/note/SKILL.md)): sekce `## Show protocol` (triggery, read-only, display IDs jako u list/delete) + edge case `/note show` bez ID.
- **Verifikace lokálně:** add (s tagy / bez) → list → `show` u obou (tagovaná i `tags: (none)`) → `show 999` exit 1 → delete úklid. Vše OK.
- **Server = zdroj pravdy:** `rsync` server→`tmp/note-server/`, `diff` SKILL.md i note.py → jediný rozdíl jsou moje nové `show` přírůstky, žádná autonomní divergence (Dream nesahal) → deploy bezpečný.
- **Deploy:** `rsync -av skills/note/` na server, owner `nanobot:nanobot` OK. Smoke `show 999` na serveru přes plnou cestu `/home/nanobot/.local/bin/uv` (interaktivní `uv` v non-login SSH PATH chybí — známý gotcha) → exit 1, OK.

**Co fungovalo a proč:** Skilly se čtou bez restartu. `show` je čistě čtecí — žádný dopad na DB ani delete logiku. Reuse `_active_ids` znamená, že display IDs jsou konzistentní napříč list/show/delete.

**Co zbývá:** Commit (tracking + skill zvlášť dle konvence).

**Jak vrátit zpět:** `git revert <commit>` skillu + `rsync` předchozí verze na server. DB beze změny.

## 2026-06-10 10:47 — remind: nový subcommand `upcoming` (co a kdy odejde)

**Cíl:** `/remind` neuměl dopředu říct, co a kdy odejde. Výpočet kdy reminder vystřelí už existoval (`remind_send.py` `_due_*`), šlo o jeho vystavení jako dotazu — **bez nafouknutí `remind_cli.py`** (491 řádků).

**Co jsem udělal:**

- Nový sdílený modul `scripts/forecast.py` — `window_for()`, `fires_in_window()`, `format_upcoming()`. Veškerá výpočetní + formátovací logika sem; CLI dostalo jen tenký handler `cmd_upcoming`.
- Znovupoužity hotové primitivy: `compute_fire_times` (random), `croniter.get_next` (cron), ISO string compare (at). Forecast je čistá projekce rozvrhu — **bez** dedupu proti `reminder_fires` a bez tolerance (na rozdíl od `delivered`, který ukazuje skutečnost).
- DRY: sestavení cfg z `schedule_random` řádku vytaženo do `random_times.random_cfg_from_row()`, použito ve `forecast` i `remind_send` (daemon jinak netknutý).
- Rozhraní: `upcoming` (= zbytek dneška), `--date YYYY-MM-DD` (celý den), `--days N` (N kalendářních dní vč. dneška); `--date`+`--days` se vylučují.
- SKILL.md: řádek do NL→command tabulky + věta do behavioral contractu.
- Testy `tests/test_forecast.py` (16 testů: window_for, at/cron/random, filtry, řazení, formát).

**Co fungovalo a proč:** Lokálně 46 testů green (`uv run --with pytest --with croniter pytest`). Smoke test CLI proti temp DB i mutual-exclusion chyba OK. Nasazeno na server `rsync -av` (vlastník `nanobot:nanobot`), `upcoming --days 2` proti ostré DB vypsalo korektní rozvrh.

**Jak vrátit zpět:** `git revert` příslušného kódového commitu; na serveru smazat `scripts/forecast.py` a `rsync` předchozí verze `random_times.py`/`remind_cli.py`/`remind_send.py`/`SKILL.md`.

**Pozn.:** `uv` na serveru není v non-interaktivním SSH PATH — je v `~/.local/bin/uv` (cron používá shebang `#!/usr/bin/env -S uv run --script`).

## 2026-06-07 19:57 — imageGeneration: provider z openrouter na ollama (žádný paid path)

**Cíl:** `tools.imageGeneration` v serverovém configu odkazoval na `openai/gpt-5.4-image-2` přes provider `openrouter` (placený). Uživatel nechce, aby cokoli kolem obrázků šlo přes openrouter — jen ollama provider / cloud modely.

**Zjištění:**

- `openai/...` byl jen default vypnutého toolu (`enabled: false`) — je to OpenRouter naming convention `vendor/model`, ne odkaz na (neexistující) OpenAI provider. Providery nakonfigurované jen tři: `openrouter`, `ollama`, `gemini`.
- Nanobot **podporuje** image-gen přes ollama (`OllamaImageGenerationClient` → `POST /api/generate` s `width/height/steps`).
- ALE **Ollama Cloud nemá žádný text→image model** — ověřeno z `ollama.com/search?c=cloud` i z `curl nvidia.hell:11434/api/tags`: samé LLM, vision-LLM (obrázky na *vstupu*) a embeddingy, žádný flux/SD/diffusion. Takže image-gen na ollama reálně nepoběží, není na co model namířit.

**Co jsem udělal:**

- Záloha: `cp -a ~/.nanobot/config.json ~/.nanobot/config.json.bak-imggen`.
- In-place Python edit `~/.nanobot/config.json` → `tools.imageGeneration`: `provider` `openrouter`→`ollama`, `model` `openai/gpt-5.4-image-2`→`""`, `enabled` ponecháno `false`. Config re-parsnut OK.

**Co fungovalo a proč:** Splňuje záměr — žádná cesta image-gen přes placený openrouter. Tool je `enabled: false`, takže neutrácí; i kdyby se zapnul, generace na ollama selže (žádný image model), nezačne nic platit.

**Co zbývá / pozn.:** Funkční generování obrázků by vyžadovalo placený provider (gemini/openrouter) nebo lokální diffusion mimo Ollamu. Na ollama to nejde.

**Jak vrátit zpět:** `cp -a ~/.nanobot/config.json.bak-imggen ~/.nanobot/config.json`.

## 2026-06-07 19:07 — Přidán model preset `gpt` (gpt-oss:120b-cloud, ollama)

**Cíl:** Přidat do serverové konfigurace nový model preset `gpt` = `gpt-oss:120b-cloud` přes Ollama.

**Co jsem zkusil / udělal:**

- Ověřil dostupnost: `curl http://nvidia.hell:11434/api/tags` → `gpt-oss:120b-cloud` v seznamu (přesná shoda).
- Záloha: `cp ~/.nanobot/config.json ~/.nanobot/backup/config.json.bak-20260607-190745`.
- In-place Python edit `~/.nanobot/config.json`: do `model_presets` (snake_case na disku) přidán klíč `gpt` se strukturou jako ostatní ollama presety — `provider: ollama`, `model: gpt-oss:120b-cloud`, `maxTokens: 16384`, `contextWindowTokens: 131072` (gpt-oss-120b = 128k kontext), `temperature: 0.1`, `reasoningEffort: null`, `label: null`.
- Restart **neproveden** — `model_presets` se hot-reloadují (`_refresh_provider_snapshot()` před každým tahem), preset je dostupný okamžitě přes `/model gpt`.

**Co fungovalo a proč:** In-place Python edit zachoval ostatní klíče včetně secrets. Hot-reload presetů ověřen v knowledge.md → žádný výpadek služby.

**Jak vrátit zpět:** `cp ~/.nanobot/backup/config.json.bak-20260607-190745 ~/.nanobot/config.json` (nebo Python `del c["model_presets"]["gpt"]`).

## 2026-06-07 18:08 — Detach skill: ms timestamp + detach.log + popis ve výpisu

**Cíl:** Opravit tři problémy v `/detach` skillu: (1) riziko přepsání souboru úlohy při shodě slugu a sekundy, (2) neúplné logování (create a archive nelogoval vůbec), (3) výpis `list` ukazoval jen slug bez popisu co úloha dělá.

**Co jsem zkusil / udělal:**

- `create-task.py`: timestamp přepnut z `%Y-%m-%dT%H%M%S` (sekundy) na `%Y-%m-%d_%H_%M_%S_%f` (mikrosekundy); filename `2026-06-07_15_00_00_123456-slug.md`. Dvě souběžná volání se stejným slugem teď nemohou kolidovat na úrovni souboru.
- `tasks_common.py`: FILENAME_RE rozšířen pro oba formáty (starý T-joined zpětně kompatibilní); přidán `parse_timestamp()` s fallback na oba formáty; sdílená `log()` → `~/.nanobot/workspace/log/detach.log`; `render_table()` přijímá `list[Path]` místo `list[str]` a přidává sloupec `what` (první věta `# Goal` sekce); `goal_summary()` helper.
- `tasks-daemon.py`: importuje `log` z `tasks_common` místo vlastní implementace; maže lokální `WORKSPACE`, `LOG`, `log()`.
- `create-task.py`: loguje `CREATE <filename> slug=<slug>` po úspěšném `os.replace()`.
- `archive-tasks.py`: loguje `ARCHIVE <filename>` pro každý přesun.
- `list-tasks.py`: `list_dir()` vrací `list[Path]`, předává cestu do `render_table()`.
- Testy: 56/56 pass; přidány testy pro nový timestamp formát, `parse_timestamp`, `goal_summary`, `render_table` s reálnými soubory.
- Nasazení: `rsync -av skills/detach/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/detach/` (7 souborů).

**Co fungovalo a proč:** Mikrosekundový timestamp je deterministické a jednoduché řešení — žádný slug-dedup ani zámky. Sdílený `log()` v `tasks_common.py` je správné místo pro sdílené utility.

**Jak vrátit zpět:** `git revert 587cb42` a redeployovat. Starý daemon log byl v `~/.nanobot/workspace/log/tasks-daemon.log` — po revertu bude daemon logovat tam; `detach.log` zůstane prázdný (nevadí, není kritický).

## 2026-06-07 — `/note`: display ID (1..N) místo rostoucího AUTOINCREMENT ID

**Cíl:** Zabránit tomu, aby museli uživatelé psát stále větší čísla (např. `delete 847`) při mazání poznámek.

**Co jsem zkusil:** Přidat display ID jako druhé ID pro manipulaci — 1..N mezi aktivními poznámkami, nejnovější = 1, přepočítá se po každém smazání.

**Co fungovalo a proč:**

- `_active_ids(conn)` vrátí seznam interních ID v pořadí `created_at DESC`
- `cmd_list` builduje `id_to_display` dict ze stejného pořadí → globálně konzistentní i při `--tag` filtru a `--offset` stránkování
- `cmd_delete` resolvuje display ID na interní ID přes `_active_ids`, log zaznamenává obě ID
- `cmd_add` hardcode `#1` — nová poznámka je vždy nejnovější
- Nasazeno na server přes rsync

**Co zbývá:** Nic.

## 2026-06-07 — `/note` skill: tagy, soft-delete, operation log, zkrácený SKILL.md

**Cíl:** Přidat tagy, soft-delete místo fyzického mazání, append-only operation log a zkrátit/přepsat SKILL.md (fully EN, bez 5–15 word limitu).

**Co jsem udělal:**

- `note.py` přepsán: nové schema (`tags TEXT DEFAULT '[]'`, `deleted_at TEXT`); `_connect()` context manager s WAL + row_factory (dle `bookmark.py` vzoru); `_migrate()` idempotentně přidá chybějící sloupce existující DB; `_validate_tags()` regex `^[a-z][a-z0-9-]*$`; `_tags_display()` formátuje `[#cli #tools]`; `_log()` ms-přesný timestamp `YYYY-MM-DD HH:MM:SS.mmm`; `cmd_delete()` je soft (UPDATE, ne DELETE); `cmd_list()` filtruje `deleted_at IS NULL`, podporuje `--tag` OR filtr přes `json_each()`; `cmd_add()` přijímá `--tags`.
- `SKILL.md` přepsán do EN: odstraněn 5–15 word limit → "one concept per entry, split if too complex"; přidána sekce Tag protocol (inline tagy jako první token, `arch`, `hw,linux`); delete protokol odkazuje na soft-delete a `log/note.log` jako primární audit trail.
- Migrace proběhla automaticky při prvním spuštění na serveru — 4 existující záznamy dostaly `tags='[]'`, `deleted_at=NULL`.

**Ověření:** Lokální smoke test (add s tagy, list, `--tag` OR filtr, delete, invalid tag, log) → vše OK. Na serveru ověřeno list (4 záznamy), add+delete test záznamu, `log/note.log` obsahuje všechny operace.

**Co zbývá:** `/keep` — zvážit analogický přechod na Python skript + logování (otevřený úkol v `todo.md`).

---

## 2026-06-07 — Konsolidace skillů `mind` + `note` → jeden `note` (SQLite backend)

**Cíl:** `mind` a `note` byly funkční dvojče (stejný účel, triggery, protokol), lišily se jen backendem — `mind` SQLite přes `mind.py`, `note` plochý `notes.md` editovaný LLM. Zachovat SQLite variantu (dělba rolí + determinismus + budoucí logování, viz todo.md a serverová MEMORY.md), zrušit markdown variantu, a výsledek pojmenovat `note` (uživatelské jméno skillu).

**Co jsem zkusil:**

1. **Porovnání + rozhodnutí:** `mind` zachovat (skill orchestruje, `mind.py` deterministicky zapisuje/čte/maže; má `id` + `created_at`; sedí na zamrzlé rozhodnutí „perzistentní SQLite vždy `db/*.sqlite`"). `note` (LLM sám edituje markdown) je opak — nedeterministický, neloggovatelný.
2. **Migrace dat:** 3 poznámky ze serverového `notes.md` přetaženy do `mind.sqlite` přes `mind.py add` (jazyk zachován, CZ). Po migraci 4 záznamy (id 2–5), nic se neztratilo.
3. **Ověření shody se serverem:** `rsync` + `diff -r` obou skillů → IDENTICAL, žádná Dream úprava k dotažení.
4. **Přejmenování (lokálně):** `git rm skills/note/SKILL.md` (markdown), `git mv skills/mind skills/note`, `git mv .../mind.py .../note.py`. V `note.py`: `DB_PATH` → `db/note.sqlite`, docstring + argparse description. SKILL.md přepsán `mind`→`note` napříč (frontmatter, triggery, cesty, `# Note`). Smoke test add/list/delete lokálně OK.
5. **Nasazení:** na serveru `mv db/mind.sqlite db/note.sqlite`, `rm -rf skills/mind skills/note`, `rm notes.md`, `rsync` nového `skills/note/`. Ověřeno: ownership `nanobot:nanobot`, `note.py list` vrací všechny 4 poznámky z `note.sqlite`, ve `skills/` zbyl jen `note` + `remind`.

**Co fungovalo a proč:** SQLite varianta přežila, protože jako jediná splňuje směr zapsaný v todo.md (dělba rolí skill+skript) i v serverové MEMORY.md (`/note`: SQLite, deterministický, krátký prompt + python skript). Migrace přes `add` zachovala terse styl i jazyk. Skilly se čtou per-tah bez restartu → `note` hned aktivní.

**Jak vrátit zpět:** Data jsou v `db/note.sqlite` (jen přejmenovaná z `mind.sqlite`, ne smazaná). Obnova skillů: `git revert`/`git checkout` lokálně + re-`rsync`; server `notes.md` byl smazán, ale jeho 3 řádky žijí v `note.sqlite` (id 3–5).

**Co zbývá:** Druhé kolo — `note.py` zatím **neloguje operace** (má `created_at` per řádek, ale `delete` nemaže do žádného audit logu → nejde dohledat, proč/kdy něco zmizelo). Doplnit append-only operation log (op + obsah + čas) do skriptu. Sleduje todo.md a MEMORY.md požadavek „logovat všechny provedené operace".

---

## 2026-06-03 — MiniLoop gemini-flash-lite a mistral-small-3.2 cache

**Cíl:** Otestovat `google/gemini-3.1-flash-lite` (OpenRouter) a ověřit `mistral-small-3.2`.

**Co jsem zkusil:** `dotnet run --no-build -- test gemini-flash-lite` a `dotnet run --no-build -- test mistral-small-3.2`.

**Co fungovalo a proč:** `gemini-flash-lite` — 17/17 ok, median **683 ms**, avg 719 ms, out 559 tok. Nejlepší výsledek ze všech dosud měřených OpenRouter modelů; poráží haiku-4.5 (1064 ms), gemma-3-27b (1413 ms) i glm-5.1-ollama (1690 ms). Žádný reasoning, přímý parse.

**Problém — `mistral-small-3.2` byl dřív naměřen s cache:** Původní výsledek 934 ms median (history 2026-06-03 „MiniLoop levné OSS") zřejmě těžil z cache providera. Opakovaný cold test ukázal 3 400–7 400 ms na prvních 4 příkladech — přibližně 3–8× horší. Skutečná cold performance je cca 4–5 s median. Označeno v knowledge.md.

**Co zbývá:** ověřit gemini-flash-lite v plném produkčním nasazení (nanobot remind skill), zhodnotit cenu.

## 2026-06-03 — MiniLoop phi4:latest zamítnut

**Cíl:** Otestovat lokální `phi4:latest` (14.7B) jako kandidáta pro MiniLoop.

**Výsledek:** Zamítnut — 15/17, median 1744 ms / avg 1676 ms. Dvě skutečné chyby: (1) `příští pondělí` → `2026-06-05` (čtvrtek) místo `2026-06-08` — horší než codestral, který vrátil neděli; (2) `dopoledne` → window `09:00-12:00` místo `08:00-12:00`. Navíc pomalejší než gemma4:e4b (1744 vs 1136 ms). „Punches above weight" reputace se pro tuto úlohu nepotvrdila.

## 2026-06-03 — MiniLoop codestral:22b zamítnut

**Cíl:** Otestovat lokální `codestral:22b` jako kandidáta pro MiniLoop.

**Výsledek:** Zamítnut — 16/17, median 2483 ms / avg 2621 ms, skutečná chyba data: `příští pondělí` → `2026-06-07` (neděle) místo `2026-06-08` (pondělí). Stejná třída chyby jako ministral-3:8b (weekday aritmetika). Zároveň 2× pomalejší než gemma4:e4b (1136 ms). Coder specializace nepomohla u česky popsaných relativních dat.

## 2026-06-03 — MiniLoop gemma4:e4b local

**Cíl:** Otestovat lokální `gemma4:e4b` (8B, nvidia.hell) v MiniLoop — jestli zvládne 17/17 a jaké jsou časy.

**Co jsem zkusil:** `dotnet run -- test gemma4-local` — jediný model, bez gate (lokální Ollama, žádná kvóta).

**Co fungovalo a proč:** 17/17, median 1136 ms / avg 1719 ms, out=1530 tok. Žádné chyby data ani cronu. Odlehlé hodnoty (3–4 s) u složitějších vstupů (random times, multiple windows). Výsledek překvapivě silný pro lokální 8B model — lepší median než glm-5.1 cloud (1690 ms) a blízko gemma-3-27b-it OpenRouter (1413 ms). Bez reasoning skluzu (porovnej nemotron-nano: out=7805).

**Co zbývá:** porovnat s dalšími lokálními modely (codestral:22b, phi4) pokud bude potřeba offline fallback.

## 2026-06-02 — Fix: dynamická detekce verze nanobotu v check_nanobot_version.py

**Cíl:** Opravit hardcoded `CURRENT_VERSION = "0.2.0"` v `~/.nanobot/workspace/scripts/check_nanobot_version.py` — po upgradu na 0.2.1 by cron job navždy hlásil 0.2.1 jako "novou verzi".

**Co jsem zkusil:** Tři varianty detekce aktuální verze: `nanobot --version` (funguje, ale potřeba parsovat emoji prefix), `importlib.metadata` v systémovém Pythonu (nefunguje — nanobot-ai tam není), `importlib.metadata` s PEP 723 hlavičkou (funguje spolehlivě).

**Co fungovalo a proč:** PEP 723 shebang (`#!/usr/bin/env -S uv run --script`) + `dependencies = ["nanobot-ai"]` zajistí, že skript běží ve venv kde `nanobot-ai` je nainstalován → `importlib.metadata.version("nanobot-ai")` vrátí správnou verzi. Žádný subprocess, žádné parsování. Shodné s projekční konvencí.

**Ověření:** `uv run check_nanobot_version.py` vrátil `Current nanobot version: 0.2.1` a všechny tři zdroje (PyPI, GitHub, Docker) také 0.2.1 → žádná falešná notifikace.

**Co zbývá:** nic.

---

## 2026-05-31 — Skill `/plan` — plan mode jako v Claude Code

**Cíl:** Vytvořit nanobot skill `/plan`, který replikuje chování plan mode z Claude Code: nejdřív task read-only prozkoumat a naplánovat, plán předložit ke schválení, a teprve po explicitním schválení (klidně později) vykonat.

**Co jsem zkusil:**

1. **Průzkum** — prošel strukturu `skills/` (note, keep, deep-research jako vzory): skill = `SKILL.md` s YAML frontmatterem (`name` + víceřádkový `description` s triggery) + EN-only markdown tělo. Žádný harness, vše je promptová instrukce.
2. **Ověření subagentů** — původně jsem v plánu chybně tvrdil, že nanobot nemá subagenty. Uživatel mě opravil, ověřil jsem v upstreamu: nanobot **má** builtin `spawn` tool ([spawn.py](https://github.com/HKUDS/nanobot/blob/main/nanobot/agent/tools/spawn.py)) — hlavní agent spawne subagenta, ten běží **async** v pozadí a výsledek vrací přes MessageBus. Lokálně to potvrzují zmínky v `workspace/picoclaw/` (`spawn, subagent — vše enabled`).
3. **Návrh** — 4 lineární fáze: Explore (read-only) → Design → zápis plánu do `workspace/plans/<slug>.md` → zastavení a dotaz na schválení/vykonání. Read-only vynuceno promptem (`## Rules`), schvalovací smyčka přes chat jako náhrada `ExitPlanMode`. `spawn` jen volitelně pro velký dělitelný průzkum (async povaha by běžné iterativní plánování spíš zdržovala).
4. **Deploy** — `rsync -av skills/plan/ nanobot@nanobot.hell:.../skills/plan/`, ownership `nanobot:nanobot` ověřeno. Skilly se čtou při každém tahu bez restartu → `/plan` hned aktivní.

**Co fungovalo a proč:** Konzistence se stylem `note`/`deep-research` (EN-only tělo, triggery CZ+EN, fázová struktura se status zprávami jako deep-research). Lineární default + volitelný `spawn` odpovídá tomu, že `spawn` je async — synchronní lineární čtení je pro plánování plynulejší.

**Jak vrátit zpět:** `ssh nanobot@nanobot.hell 'rm -rf ~/.nanobot/workspace/skills/plan'` + smazat lokální `skills/plan/`.

**Co zbývá:**

- Smoke test přes Telegram/WebUI: `/plan <malý úkol>` → ověřit read-only průzkum, zápis plánu do `workspace/plans/`, zastavení s dotazem, a vykonání až po „ano, vykonej" (po „ne" plán zůstane uložený).

## 2026-05-29 — Instalace nvm + zpřístupnění npx pro nanobot service

**Cíl:** Zprovoznit `npx` (a tím clawhub CLI) na serveru nanobot.hell.

**Co jsme zkusili:**

- Instalace nvm pro uživatele `nanobot`: `curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash`
- Instalace Node.js: `nvm install --lts` → nainstaloval se v24.16.0 do `/home/nanobot/.nvm/versions/node/v24.16.0/`
- nvm přidal inicializaci do `.bashrc` — to funguje v interaktivním shellu, ale systemd user service `.bashrc` nesourcuje

**Co fungovalo a proč:**

- Přidáno `Environment=PATH=/home/nanobot/.nvm/versions/node/v24.16.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin` do `/home/nanobot/.config/systemd/user/nanobot.service`
- Reload + restart přes `ssh nanobot@nanobot.hell "systemctl --user daemon-reload && systemctl --user restart nanobot"` (root přes sudo/machine nefunguje, přímé SSH jako nanobot ano)
- Ověřeno: `/proc/<pid>/environ` obsahuje správnou PATH s nvm cestou

**Co zbývá:** Při upgradu Node.js přes nvm je potřeba aktualizovat verzi v service souboru ručně.

**Jak vrátit zpět:** Odstranit řádek `Environment=PATH=...` ze service souboru, daemon-reload, restart.

## 2026-05-29 — SQLite konvence + sync workspace/*.md

**Cíl:** Přidat do AGENTS.md instrukci, že agent má SQLite databáze ukládat do `db/*.sqlite`.

**Co jsem zkusil / udělal:**

1. Zkoumal, kde žijí instrukce agenta — SSH na server, prošel `/home/nanobot/.nanobot/workspace/`.
2. Zjistil, že správné místo je `AGENTS.md` (operační pravidla), ne `SOUL.md` (osobnost) ani skills.
3. Přidal sekci `## Databases (SQLite)` do `workspace/AGENTS.md` (anglicky) a pushnu na server.
4. Při té příležitosti zjistil, že lokální `workspace/*.md` jsou zaostalé — chyběly sekce `Faktografická pravidla`, Telegram ID, `Scheduling`, `Životní filozofie`, apod.
5. Přepsal všech 5 souborů aktuální verzí ze serveru a commitnul do gitu.

**Co fungovalo:** Přímý SCP push AGENTS.md na server. Lokální `workspace/` jako tracking directory pro server soubory.

**Co zbývá:** sqlite MCP server v `config.json` je hardcoded na `/home/nanobot/.nanobot/workspace/tmp/test_mcp.db` — neodpovídá nové konvenci `db/*.sqlite`.

## 2026-05-29 — remind_edit.py: deterministický CRUD pro reminder.yaml

**Cíl:** Skill `remind` nechával LLM přímo editovat `reminder.yaml` — žádná validace cron výrazu, riziko poškozený YAML, potenciální race s `remind_send.py` (crontab každou minutu).

**Co jsem zkusil:** Zvažovaná alternativa MCP server — zamítnuta jako overkill (zbytečná vrstva pro jednoduchý YAML CRUD). Zvoleno: CLI Python skript volaný přes `exec`, stejný pattern jako `remind_send.py`.

**Co fungovalo:** Napsán `/home/nanobot/.nanobot/workspace/skills/remind/scripts/remind_edit.py` (PEP 723, `uv run`, `argparse`). Subcommandy `list`, `add --text ... --cron|--at ...`, `remove --keyword ...`. Atomický zápis přes `.yaml.tmp` + `os.replace()`. Validace: `croniter.is_valid()` pro cron výrazy, `datetime.fromisoformat()` pro `--at`. Všechny výstupy JSON; chyby na stderr + non-zero exit. Aktualizován `SKILL.md` — workflowy Create/List/Remove teď volají `remind_edit.py` místo přímé editace YAML.

**Verifikace:** Prošly testy 1–7 (list baseline, add cron, add at, invalid cron, remove ambiguous, remove unique, cleanup). YAML na serveru po testech obsahuje původní 4 připomínky beze změny.

**Co zbývá:** —

## 2026-05-28 — detach skill: odstranění hardcoded chat_id

**Cíl:** `skills/detach/config.json` obsahoval soukromé Telegram chat ID přímo v gitu. Skill nebyl generický.

**Co jsem zkusil:** Přečetl jsem strukturu `~/.nanobot/config.json` na serveru a zjistil, že ID je uloženo pod `channels.telegram.allowFrom[0]`.

**Co fungovalo:** Odstraněn `DETACH_CONFIG` z `tasks-daemon.py`, `resolve_telegram_chat_id()` nyní čte `cfg["channels"]["telegram"]["allowFrom"][0]` z hlavního configu. `skills/detach/config.json` smazán z repo i ze serveru.

**Co zbývá:** —

## 2026-05-28 — Smazán mrtvý skill `deliver-reminder-notifications`

**Cíl:** Uživatel si všiml, že na serveru ve `workspace/skills/` leží skill `deliver-reminder-notifications` z minulé session. Zjistit, proč tam je, a pokud je mrtvý, smazat.

**Co jsem zjistil:**

- Skill `deliver-reminder-notifications` (vytvořen 28. 5. 12:07) je zbytek po staré agentní architektuře připomínek. Volá skript `remind/scripts/remind_check.py`, který už neexistuje (v `remind/scripts/` je jen `remind_send.py`).
- Aktuální doručování běží přes system crontab (`uv run remind_send.py` každou minutu) přímo přes Telegram Bot API — žádný agent v loopu. Viz `remind/SKILL.md` na serveru, který explicitně píše *"Do not recreate a `remind-check` job"*.
- Žádný cron ani jiný skill `deliver-reminder-notifications` netriggeruje.

**Co fungovalo:**

```bash
ssh root@nanobot.hell "rm -rf /home/nanobot/.nanobot/workspace/skills/deliver-reminder-notifications"
```

Po smazání ve `workspace/skills/` zbývají: `detach`, `grill-me`, `remind`.

**Jak vrátit zpět:** Obnovit adresář se souborem `SKILL.md` (frontmatter `name: deliver-reminder-notifications`, popis polling + Telegram delivery v češtině). Ale nemělo by smysl — skript, na který odkazoval, neexistuje a delivery dělá cron.

## 2026-05-28 — Faktografická pravdomluvnost do SOUL.md, demystifikace `memory/`

**Cíl:** Uživatel pozoroval, že nanobot v chatu halucinoval o filmech. Pokusil se to „opravit" tak, že agentovi řekl pravidlo a ten si ho uložil do `~/.nanobot/workspace/memory/film_policy.md`. Halucinace pokračovaly. Otázka: jak to opravit správně + obecně zvýšit pravdomluvnost.

**Klíčové zjištění (ověřeno ve zdrojáku):** Z adresáře `memory/` se do system promptu auto-loaduje **výhradně `MEMORY.md`**. ContextBuilder ani MemoryStore žádné jiné soubory v `memory/` nečte. Tj. `memory/film_policy.md` byl pro agenta **neviditelný** — vytvořil ho, ale v dalším tahu už ho neměl v kontextu, takže pravidlo neaplikoval.

Zdroj: `/home/nanobot/.local/share/uv/tools/nanobot-ai/lib/python3.13/site-packages/nanobot/agent/{context.py,memory.py}` — verze 0.2.0:

- `context.py:25` — `BOOTSTRAP_FILES = ["AGENTS.md", "SOUL.md", "USER.md", "TOOLS.md"]`
- `memory.py:55,205,229` — `memory_file = memory_dir / "MEMORY.md"`, `get_memory_context()` čte výhradně tento jeden soubor

**Pozn. k upstream HEAD:** v `HKUDS/nanobot` master branch už `BOOTSTRAP_FILES` neobsahuje `TOOLS.md` (jen `AGENTS`, `SOUL`, `USER`). Naše verze 0.2.0 ho ještě má. Při budoucím upgrade nanobotu to ověřit a případně přesunout obsah `TOOLS.md` jinam.

**Co fungovalo (řešení):**

1. **Nová sekce v SOUL.md** — `## Faktografická pravidla`, vložená před `## Styl výstupu` na serveru. Obsah: imperativní pravidlo „když nevím, řeknu to" + „u faktografických dotazů nejdřív dohledám tooly, pak odpovídám" + „halucinace = vážná chyba, ne kosmetika". Patch přes Python in-place na serveru (idempotence ověřena `assert "## Faktografická pravidla" not in text`), žádný restart nepotřeba (bootstrap soubor).
2. **Smazán `memory/film_policy.md`** — nebyl čten, jen mátl.
3. **Knowledge.md doplněn** o dvě nové sekce: „Co se auto-loaduje do system promptu (verze 0.2.0)" + tabulka „K čemu slouží jednotlivé workspace soubory" (SOUL/AGENTS/USER/TOOLS/MEMORY/HEARTBEAT). Stará minimální sekce „Workspace bootstrap soubory se čtou každý tah" nahrazena bohatší variantou; sekce „Workspace vzniká při prvním spuštění agenta" ponechána beze změny.

**Proč SOUL.md a ne AGENTS.md / skill:**

- AGENTS.md drží procesní pravidla (jaký tool kdy) — pravdomluvnost je hodnota, ne proces.
- Always-on skill pro jedno pravidlo je overkill. Skilly dávají smysl, když potřebuje izolaci (own helper scripts, modulární distribuce). Sémanticky horší než SOUL pro hodnotové pravidlo.
- MEMORY.md by Dream při konsolidaci mohl přepsat — nehodí se na trvalá pravidla chování.

**Co jsem zkusil mimo úspěšnou cestu:**

- Explore agent na začátku trval na konkrétních line numbers v `/tmp/nanobot-src/...` ještě před tím, než tam upstream byl klonovaný — fabulace zdroje, kterou jsem musel přebít přímým ověřením. Jasná ilustrace toho, proč user chce pravdomluvnost: i podagent halucinoval citace zdroje. Pravidlo „neopakuj číslo řádku, dokud jsi ho neviděl" by se hodilo i na můj vlastní workflow, ne jen na nanobota.
- Místně bylo `BOOTSTRAP_FILES = [AGENTS, SOUL, USER]` v upstream HEAD — málem jsem usoudil, že `TOOLS.md` se nečte. Ověření verze na serveru (`nanobot --version` → 0.2.0, `grep BOOTSTRAP_FILES` v nainstalovaném wheelu) odhalilo divergenci verzí.

**Jak to vrátit zpět:**

- SOUL.md: `ssh nanobot@nanobot.hell 'python3 -c "from pathlib import Path; p=Path.home()/\".nanobot/workspace/SOUL.md\"; t=p.read_text(); import re; p.write_text(re.sub(r\"## Faktografická pravidla.*?(?=## Styl výstupu)\", \"\", t, flags=re.S))"'`
- film_policy.md: obnovit z paměti (krátký, obsah je teď v history.md SOUL.md patchi nebo v původní git komitové historii local repo, pokud byl).

**Co zbývá:**

- Live verifikace v Telegramu — dotaz na film, sledování `journalctl -u nanobot.service -f` na `web_search`/`web_fetch` tool call před odpovědí. Cross-test s netriviálním dotazem (ověřit „nevím" místo improvizace). Negativní kontrola s in-context dotazem (např. „jaký mám preset?") — nesmí spustit zbytečné web search.

---

## 2026-05-28 — Pilot mattpocock skillu `grill-me`

**Cíl:** Ověřit, jestli Claude Code skilly (Anthropic Skills format) jdou pustit v nanobotovi bez konverze. Jako kanárek vybrán `grill-me` z [nicecode/plugins/mattpocock](https://github.com/lachtan/nicecode/tree/master/plugins/mattpocock) — nejmenší možná povrchová plocha (10 řádků, žádné helper skripty, žádné `@`-reference, žádné Claude-Code-specific tooly v těle).

**Co fungovalo:**

- Formát `SKILL.md` (YAML `name`+`description` + markdown tělo) je identický s nanobot skill formátem. Kopie 1:1, žádná konverze.
- Deploy přímo na server jedním SSH+curl one-linerem (`ssh nanobot@nanobot.hell` → `mkdir -p ~/.nanobot/workspace/skills/grill-me` → `curl -sSfL <raw github URL> -o SKILL.md`). Server-to-GitHub, lokálně se nic neukládá.
- Restart nanobot.service není potřeba — bootstrap soubory ve `workspace/skills/` se čtou každý tah ([knowledge.md "Workspace bootstrap soubory se čtou každý tah"](knowledge.md)).
- Uživatel ověřil v chatu: agent na trigger frázi začal pokládat otázky jednu po druhé s recommended answers, místo aby plán rovnou implementoval. Chování přesně podle popisu skillu.

**Co jsem zkusil mimo úspěšnou cestu:**

- WebFetch na `diagnose/SKILL.md` při průzkumu vrátil výstup s **fake `<system-reminder>` tagem** uvnitř markdown těla (prompt-injection patrně v Anthropic-fetch pipeline). Zaznamenáno v knowledge.md jako gotcha pro budoucí mattpocock skilly — markdown těla je nutné prohlédnout před deployem, protože nanobot je čte do system contextu.
- `WebFetch` celkově nedával užitečné odpovědi na otázky typu „obsahuje tento soubor X?" — vracel jen echo dotazu. Přepnul jsem na `curl | grep` přes Bash a dostal jednoznačné odpovědi.

**Manifest `.claude-plugin/plugin.json` se nekopíruje** — je Claude-Code-specific metadata pro marketplace, nanobot ho ignoruje. Přenositelná je jen složka `skills/`.

**Jak to vrátit zpět:** `ssh nanobot@nanobot.hell 'rm -rf ~/.nanobot/workspace/skills/grill-me'`. Žádné side effecty mimo tu složku.

**Co zbývá:** Zatím nic — uživatel zvolil pilotně jen jeden skill, další (`caveman`, `diagnose`, `tdd`, `triage`, `zoom-out`, `grill-with-docs`, `improve-codebase-architecture`) zatím neinstalovat. Plán nasazení existuje v `~/.claude/plans/jak-by-sel-pouzit-agile-thimble.md` — při rozšíření projít každý další skill na (a) Claude-Code-specific tool refs, (b) prompt-injection v markdown těle. `to-issues` a `to-prd` vyžadují `gh` CLI a GitHub kontext — na serveru pravděpodobně nepoužitelné bez adaptace.

---

## 2026-05-28 — Reminder logy do `log/` a čitelnější formát

**Cíl:** Logy `/remind` skiluu byly v rootu workspace (smetí v hlavním adresáři), formát byl `ISO+02:00 \t text` (tabulátor, timezone suffix nechtěný).

**Co fungovalo:**

- `LOG_DIR = WORKSPACE / "log"` v `skills/remind/scripts/remind_send.py`, `LOG_DIR.mkdir(parents=True, exist_ok=True)` před zápisem.
- Formát změněn na `datetime.now(TZ).replace(tzinfo=None).isoformat(timespec="seconds")` + mezera + text + `\n` → `YYYY-MM-DDTHH:MM:SS <text>`. TZ zůstává Prague, jen se nepíše do řetězce.
- Crontab pod nanobot userem přepsán: `>> /home/nanobot/.nanobot/workspace/log/reminder_cron.log 2>&1`. Soubor `reminder_cron.log` zůstává — chytá stdout/stderr crontabu pro debug (za zdravého běhu prázdný).
- Stávající `reminder.log` (8 řádků) přepsán do nového formátu a přesunut do `log/`; `reminder_cron.log` (0 B) jen přesunut.
- Ověřeno: cron tick `(nanobot) CMD (uv run …remind_send.py >> /home/nanobot/.nanobot/workspace/log/reminder_cron.log 2>&1)` v journalu, exit 0, log/ vznikl, root workspace už neobsahuje `*.log`.
- `TOOLS.md` a `skills/remind/SKILL.md` aktualizovány na novou cestu i formát; agent dostane upozornění při příštím tahu (always-on bootstrap).

**Proč dva logy:** `log/reminder.log` = aplikační (úspěšná doručení, čte agent). `log/reminder_cron.log` = zachytávka stdout/stderr crontabu (`>> ... 2>&1`) — bezpečnostní síť pro tracebacky / chyby uv. Funkce se nepřekrývají.

**Co selhalo / zákoutí:**

- První patch `remind_send.py` jsem zkusil pod `sudo -u nanobot` → `PermissionError`. Soubor byl owned `root:root` (vytvořen v předchozí session přes SSH jako root). Fix: patch jako root + `chown nanobot:nanobot` po editaci.
- Reformat stávajícího `reminder.log` přes „chytrý" Python jednořádkový regex (`ts.split("+")[0].split("-0")[0]`) zmrvil obsah na samé `2026 <text>` — `-0` matchlo už `-05` v datu. Fix: přepsat soubor staticky známým obsahem (8 řádků jsem stejně měl před očima z předchozího `cat`).
- Manuální dry-run `sudo -u nanobot uv run …` selhal dvakrát: nejdřív `uv: command not found` (PATH bez `~/.local/bin`), pak `failed to open /root/uv.toml` (cwd zůstal `/root`). Funguje až `cd /home/nanobot && sudo -Hu nanobot bash -lc "uv run …"`. Cron tohle neřeší — má vlastní `HOME` a `PATH` v hlavičce crontabu a běží z domovského adresáře nanobota.

**Jak to vrátit zpět:** v `remind_send.py` vrátit `LOG_FILE = WORKSPACE / "reminder.log"` a starý zápis s `\t` + tz, v crontabu vrátit cestu bez `log/`, soubory přesunout zpět.

---

## 2026-05-27 — Spam "Output was empty": skutečná příčina + přechod /remind mimo agenta

**Cíl:** Pochopit, proč chodí na Telegram zprávy "(Output was empty — no message sent.)" / "(Výstup byl prázdný…)" — a ne každou minutu, ale jen sem tam a pokaždé jinak formulované. Předchozí fix ("exit silently" v promptu) nestačil.

**Skutečná příčina (oprava dřívějšího závěru):**

1. Prompt `"The scheduled time has arrived. Deliver this reminder to the user now…"` **není** z jobs.json — je **natvrdo ve zdrojáku** `nanobot/cli/commands.py:on_cron_job`. `payload.message` z jobs.json se jen přilepí za `Reminder:`. Takže každý cron job dostane konfliktní zadání (kód přikazuje doručit, můj text říká mlčet) → agent improvizuje meta-odpověď.
2. Cron job VŽDY jede přes agenta (`agent.process_direct`) — neagentní typ jobu neexistuje. Agent komentuje své mlčení místo aby skutečně mlčel.
3. Doručení hlídá druhý LLM `evaluate_response` (`nanobot/utils/evaluator.py`), který je **fail-open**: při jakékoli chybě nebo když model nevrátí tool-call → `return True` (doruč). V journalu ~20×/den `"no tool call returned, defaulting to notify"`.
4. → Únik nastane jen v minutách, kdy evaluator LLM selže. Nedeterministické a model-závislé (zhoršilo se po přepnutí na slabší Ollama-cloud modely) → "jen sem tam". Text je pokaždé čerstvě generovaný → "pokaždé jiná zpráva".

**Co fungovalo (řešení — Design A, mimo agenta):**

- Nový `skills/remind/scripts/remind_send.py`: čte reminder.yaml, při shodě posílá **přímo přes Telegram Bot API** (token z `~/.nanobot/config.json` → `channels.telegram.token`), deduplikuje přes `.reminder_state.json` (každý fire 1×), loguje do `reminder.log` (`ISO-čas \t text`). Žádný LLM, žádný nanobot proces. Stdlib `urllib` (deps jen croniter+pyyaml).
- Odebrán nanobot cron job `remind-check` (id 1a7bb634): stop service → filtr v jobs.json → start. Po restartu se nevrátil. Záloha `cron/jobs.json.bak-*`.
- Crontab pod uživatelem nanobot (`crontab -l`): `* * * * * uv run …/remind_send.py >> reminder_cron.log 2>&1`, s `HOME` + `PATH` v hlavičce (cron má holé prostředí). Cron daemon `cron.service` na hostu běží. Ověřeno: `(nanobot) CMD (uv run …remind_send.py)` v journalu každou minutu, log prázdný (běží čistě).
- `TOOLS.md` (always-on bootstrap) dostal ukazatel na `reminder.log`; `SKILL.md` přepsána architektura; smazán starý `remind_check.py`.

**Co konkrétně přibylo do system promptů** (always-on bootstrap = každý tah agenta):

- `TOOLS.md` — nová sekce na konci souboru (řádky 51+):

  > ## reminder.log — doručené připomínky
  >
  > Odeslané připomínky se logují do `reminder.log` v rootu workspace (append-only, formát `ISO-čas \t text`). Posílá je **systémový cron uživatele nanobot** (`skills/remind/scripts/remind_send.py`) přímo přes Telegram, mimo agenta. Když se uživatel ptá na minulé/dnešní připomínky („připomněl jsi mi…?", „co dnes přišlo?"), přečti tento soubor.

  *(Pozn.: 28.5. tato sekce dostala druhý revize na `log/reminder.log` + nový formát — viz entry o `log/`.)*

- `skills/remind/SKILL.md` — sekce **Architecture** přepsána na popis systémového crontabu + `remind_send.py` + Bot API + dedup + audit log. Sekce **Cron Tool Usage** přejmenována na **Cron Tool — NOT used for reminders** s explicitním zákazem znovu vytvořit `remind-check` job přes `cron` tool (jinak by se vrátil starý fail-open agentní problém). Reference v dokumentaci přepnuta z `remind_check.py` → `remind_send.py`.
- Token + API ověřeno přes `getMe`; živý test `sendMessage` doručen (uživatel potvrdil "prislo").

**Jak to vrátit zpět:** obnovit `cron/jobs.json.bak-*` + restart service (vrátí agentní job `remind-check`); `crontab -r` jako nanobot (smaže crontab).

**Co zbývá:** Ověřit reálné doručení ostré připomínky (zítra 9:00, příp. 9:30 čt). Zvážit nahlášení fail-open evaluatoru upstream (HKUDS/nanobot).

---

## 2026-05-27 — Průzkum nanobot skill systému a Dream procesoru

**Cíl:** Zjistit jak se instalují nové skilly (konkrétně clawhub.ai/pskoett/self-improving-agent) a jestli má smysl ho nasadit.

**Co jsem zjistil:**

1. **Skill systém nanobot:** Skill = složka `~/.nanobot/workspace/skills/<name>/` se souborem `SKILL.md` (YAML frontmatter + markdown instrukce). Žádný `install` příkaz neexistuje — skill se vytvoří ručně. Bootstrap soubory se čtou při každém tahu → restart není potřeba.

2. **Clawhub.ai je pro jiný systém.** Clawhub / OpenClaw není nanobot. Instalace přes `clawdhub install` nebo `openclaw skills install` jsou příkazy pro ten jiný ekosystém. Skilly z clawhub se musí ručně adaptovat pro nanobot.

3. **Dream procesor** (`nanobot/agent/memory.py:Dream`) dělá přesně to, co má self-improving-agent skill — automaticky, každé 2 hodiny:
   - **Fáze 1:** Plain LLM call projde `history.jsonl`, hledá fakta → `MEMORY.md`, korekce → `SOUL.md`/`USER.md`, opakující se workflow → `[SKILL]` kandidáti
   - **Fáze 2:** AgentRunner s `read_file`/`edit_file` tools chirurgicky zapíše změny, umí sám vytvářet nové skilly (`write_file` do `skills/<name>/SKILL.md`), deuplikuje, detekuje stale content přes git blame

4. **Self-improving-agent skill je z 80 % redundantní s Dream.** Přidal by jen: explicitní error log s formátem `ERR-YYYYMMDD-XXX`, feature request tracking, okamžité zachycení (Dream čeká 2h). Nasazen jako experimentální `skills/self-improving-agent/SKILL.md` lokálně (zatím nedoručen na server).

5. **Modely pro dreaming:** DeepSeek V3 > Qwen 3.6+ > Kimi K2 ≈ GLM-5.1 > MiniMax M2 pro structured editing / instruction following. GLM-5.1 nijak nevyniká. Dream používá stejný model jako aktivní preset.

**Výsledek:** Skill nebylo potřeba nasazovat — Dream ho pokrývá. Lokální soubor `skills/self-improving-agent/SKILL.md` existuje pro případné budoucí použití.

---

## 2026-05-27 — Oprava spamu "Žádné připomínky" z cron jobu remind-check

**Cíl:** Zastavit opakované Telegram zprávy "Žádné připomínky k doručení." chodicí každou minutu.

**Co jsem zkusil:**

1. Zkontroloval hooks v `.claude/settings.json` a `~/.claude/settings.json` — nenašel nic relevantního.
2. `CronList` v harness — žádné naplánované joby tady.
3. Hledal skripty s "telegram"/"remind" na serveru — našel `/home/nanobot/.nanobot/workspace/cron/jobs.json`.
4. V `jobs.json` identifikoval job `remind-check` (id `1a7bb634`) s `"expr": "* * * * *"` (každá minuta).
5. Přečetl `remind_check.py` — skript správný, tiskne jen skutečné připomínky.
6. Problém: prompt agenta říkal "If output is non-empty, forward" — LLM to ignoroval a posílal "Žádné připomínky" jako potvrzení.

**Co fungovalo a proč:**

- Upravil `payload.message` v `jobs.json` přes Python in-place editor na serveru — přidal explicitní instrukci "If the output is EMPTY, do NOT send any message — exit silently."
- Restart nanobot služby: `su - nanobot -s /bin/bash -c 'XDG_RUNTIME_DIR=/run/user/$(id -u nanobot) DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$(id -u nanobot)/bus systemctl --user restart nanobot.service'`

**Slepá ulička:**

- `kill -HUP <pid>` na gateway proces — nanobot se nerestartoval, ale **skončil** a nenaskočil zpět. Poté bylo třeba ho ručně nastartovat výše uvedeným příkazem.
- `su - nanobot -c 'systemctl --user restart ...'` bez `XDG_RUNTIME_DIR` a `DBUS_SESSION_BUS_ADDRESS` selhalo s "bus not defined".

**Co zbývá:** Ověřit za pár minut, že spam ustal.

## 2026-05-27 — Doladění /remind skilu: path bug + jobs.json neuloženy

**Cíl:** Dokončit opravu /remind skilu — ověřit end-to-end doručení na Telegram.

**Co jsem zkusil / Co fungovalo:**

Skript `remind_check.py` vracelo prázdný výstup i po přepsání. Přímé testování odhalilo **path bug**: `Path(__file__).parent.parent.parent` z `.../skills/remind/scripts/remind_check.py` vede na `.../workspace/skills/` — `reminder.yaml` tam neexistuje → skript tiše skončil na `if not REMINDER_YAML.exists(): return`. Oprava: 4 levely nahoru (`parent.parent.parent.parent`).

Změny v `jobs.json` z předchozí session se **neuložily** — soubor stále obsahoval `remind_runner.py` a `channel: websocket` na ephemeral session ID. Opraveno přes Python in-place edit na serveru + restart service.

**Výsledek:** Cron job spouští `uv run remind_check.py` → stdout → nanobot `evaluate_response: should_notify=True` → doručeno na Telegram. Ověřeno uživatelem.

**Co zbývá:** Testovací záznam `TEST každou minutu` smaže uživatel přes chat.

---

## 2026-05-27 — Oprava /remind skilu

**Cíl:** Diagnostika a oprava nefunkčního /remind skilu — notifikace se neodesílaly správně, LLM občas vytvářel cron joby místo záznamu do reminder.yaml, Telegram polyká `/remind` příkazy.

**Co jsem zkusil / Co fungovalo:**

Průzkum ukázal dva Python skripty se odlišnou architekturou:

- `remind_runner.py` byl aktivní (cron job ho spouštěl), ale špatný — posílal Telegram přímo přes API (obcházel nanobot), neměl `at` field support, měl hardcoded UTC+2
- `remind_check.py` měl správnou architekturu (stdout → nanobot → user), podporoval `at` field, ale měl UTC timezone místo Prague

**Provedené opravy:**

1. `remind_check.py` přepsán: Prague timezone přes `zoneinfo`, zjednodušen z ~70 na ~30 řádků
2. `remind_runner.py` smazán
3. `cron/jobs.json` — job `remind-check` přepnut na `remind_check.py` + delivery kanál změněn na Telegram (byl websocket session)
4. `SKILL.md` — odstraněn `done` field ze schématu, přidány sekce "Telegram — jak zadat příkaz" a "Remind vs. cron tool"
5. `AGENTS.md` + `TOOLS.md` — přepsána sekce o reminderech s jasným rozlišením: osobní notifikace → reminder.yaml, background úlohy → cron tool
6. `reminder.yaml` vyčistěn: odstraněny `done: false` záznamy a zastaralý testovací záznam

**Telegram problém:** `/remind text` v Telegramu = bot příkaz, ne text. Řešení: psát přirozeně (`připomeň mi...`). SKILL.md má triggery na tato slova, ale uživatel o tom nevěděl — přidána sekce do SKILL.md.

**Co zbývá:** Ověřit v praxi že notifikace z Telegramu dorazí správně.

## 2026-05-26 — Přepracování CLAUDE.md a vytvoření šablony

**Cíl:** Zjednodušit a zpřehlednit CLAUDE.md pro nanobot projekt + vytvořit čistou šablonu pro reuse v dalších projektech.

**Změny (první vlna):**

- CLAUDE.md zkráceno z ~84 na ~46 řádků — pravidla přepsána do kompaktní tabulky + odrážkových sekcí
- Přidán `plans.md` do tabulky tracking souborů (byl osiřelý, v CLAUDE.md nezmiňovaný)
- Sekce commitu zhuštěna na 4 odrážky (byl zbytečně rozvláčný)
- Odstraněn slug z instrukce pro auto-memory override (byl křehký a projekt-specifický)
- Záložní šablona uložena do `/home/lachtan/CLAUDE.template.md`

**Změny (druhá vlna — workflow zkoušení/ladění):**

- **Distilace history → knowledge:** vyřešené netriviální chyby se z deníku vytahují jako jednořádkové *problém → příčina → fix* do `knowledge.md` s odkazem zpět. Automaticky, hned po vyřešení.
- **Otevřené otázky** mají domov v `todo.md` (prefix `otázka:`); po uzavření odpověď → `knowledge.md`.
- **Zamítnuté možnosti** se zaznamenávají do `knowledge.md` (co a proč zavrženo, ať se netestuje znovu).
- **Struktura záznamu v history.md** kodifikována: Cíl / Co jsem zkusil / Co fungovalo a proč / Co zbývá + rollback u destruktivních zásahů.
- **Secrets** přidány do NEDĚLEJ (nikdy do tracking souborů — jsou v gitu).
- Stejné změny promítnuty do šablony.

## 2026-05-26 — Nastavení locale en_US.UTF-8 na nanobot.hell

**Problém:** SSH session do `root@nanobot.hell` házelo opakované warningy:

```
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8): No such file or directory
locale: Cannot set LC_CTYPE to default locale: No such file or directory
```

**Diagnóza:**

- `locale -a` na serveru ukázal jen `C`, `C.utf8`, `POSIX` — `en_US.UTF-8` nebyl vygenerován.
- `/etc/locale.gen` byl bez aktivních řádků (vše zakomentované).
- `/etc/default/locale` měl `LANG="C"`.
- SSH klient přitom přes `AcceptEnv LANG LC_*` posílal `LC_ALL=en_US.UTF-8` atd. → server warning.

**Řešení (proběhlo na serveru):**

Nejdřív manuálně přes `locale-gen` + `update-locale`:

```bash
sed -i 's/^# *en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen
locale-gen
update-locale LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8
```

Pak na žádost uživatele přepnuto na `dpkg-reconfigure` (uloží volbu do debconf DB, takže příští reconfigure si ji pamatuje):

```bash
echo 'locales locales/locales_to_be_generated multiselect en_US.UTF-8 UTF-8' | debconf-set-selections
echo 'locales locales/default_environment_locale select en_US.UTF-8' | debconf-set-selections
rm -f /etc/locale.gen
DEBIAN_FRONTEND=noninteractive dpkg-reconfigure -f noninteractive locales
```

**Ověření:** Po fixu žádné `setlocale` warningy. `/etc/default/locale` obsahuje `LANG=en_US.UTF-8` a `LC_ALL=en_US.UTF-8`. Locale `en_US.UTF-8` je v `locale -a`.

**Poznámka:** V interaktivní session se stále zobrazuje `LANG=C` — to je hodnota poslaná SSH klientem (sshd má `AcceptEnv LANG LC_* COLORTERM NO_COLOR`), nikoli problém serveru. Defaulty serveru jsou správně nastavené.

## 2026-05-26 — Založení uživatele `nanobot` a instalace `uv`

**Cíl:** Pod uživatelem `nanobot` provozovat nanobot agenta. SSH klíče sdílené s rootem, `uv` nainstalované do user-local prefixu.

**Provedeno na serveru `nanobot.hell`:**

1. Nainstalován `curl` (chyběl v základní instalaci Debian 13 trixie):

   ```bash
   apt-get update
   apt-get install -y curl
   ```

   Stáhlo se i `libcurl4t64` jako závislost.

2. Vytvořen uživatel `nanobot` (UID 1000, GID 1000) s home `/home/nanobot` a shellem `/bin/bash`. Heslo zůstalo locked (`!` v shadow) — login jen přes SSH klíče:

   ```bash
   useradd -m -s /bin/bash nanobot
   install -d -m 700 -o nanobot -g nanobot /home/nanobot/.ssh
   install -m 600 -o nanobot -g nanobot /root/.ssh/authorized_keys /home/nanobot/.ssh/authorized_keys
   ```

3. Ověřeno přihlášení `ssh nanobot@nanobot.hell` stejným klíčem jako root — funguje.

4. Pod uživatelem `nanobot` nainstalováno `uv` přes oficiální installer (uživatel spustil ručně, automatický pokus přes `curl … | sh` byl zablokován harness klasifikátorem na sdíleném remote hostu):

   ```bash
   curl -LsSf https://astral.sh/uv/install.sh | sh
   ```

   Výsledek: `uv 0.11.16 (x86_64-unknown-linux-gnu)` nainstalované do `/home/nanobot/.local/bin/{uv,uvx}`. Pro načtení do PATH je potřeba `source ~/.local/bin/env` (nebo nová shell session s upraveným `.profile`/`.bashrc`).

**Ověření:** `ssh nanobot@nanobot.hell '~/.local/bin/uv --version'` → `uv 0.11.16`.

## 2026-05-26 — Časová zóna Europe/Prague a NTP na nanobot.hell

**Cíl:** Přepnout timezone z `Etc/UTC` na `Europe/Prague` a aktivovat NTP.

**Stav před:**

```
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: inactive
```

**Provedeno:**

```bash
timedatectl set-timezone Europe/Prague
timedatectl set-ntp true
```

**Stav po:**

```
Local time: Tue 2026-05-26 18:08:44 CEST
Time zone: Europe/Prague (CEST, +0200)
System clock synchronized: yes
NTP service: inactive
```

**Poznámka k NTP:** `systemd-timesyncd` zůstává `inactive` záměrně — jednotka má `ConditionVirtualization=!container`, a protože `nanobot.hell` běží jako kontejner (LXC), service se přeskočí. Čas se dědí z hosta a `System clock synchronized: yes` to potvrzuje. V kontejneru tedy nemá smysl NTP klienta spouštět; pokud by bylo potřeba nezávislé synchronizace, musela by se na hostiteli zapnout odpovídající podpora (a/nebo se kontejneru povolit `CAP_SYS_TIME`).

## 2026-05-26 — Instalace nanobot-ai a zprovoznění Telegramu + WebUI

**Cíl:** Nainstalovat `nanobot-ai` pod uživatelem `nanobot` na `nanobot.hell`, napojit OpenRouter (model Kimi K2.6) a zprovoznit dva kanály — Telegram bot a WebUI.

**Provedeno:**

1. `uv tool install nanobot-ai` (verze 0.2.0) — uv stáhl 114 balíčků, vytvořil izolovaný venv v `/home/nanobot/.local/share/uv/tools/nanobot-ai/`, exposed CLI binárku `/home/nanobot/.local/bin/nanobot`.

2. Wizard `nanobot onboard --wizard` přeskočen — schéma configu z `docs/chat-apps.md` + `docs/websocket.md` + `docs/deployment.md` na GitHubu, config.json zapsán ručně.

3. `~/.nanobot/config.json` (mode 600, obsahuje secrets):
   - `providers.openrouter.apiKey` — OpenRouter klíč
   - `agents.defaults.provider=openrouter`, `model=moonshotai/kimi-k2.6`
   - `channels.telegram` — `enabled`, bot token, `allowFrom: ["8826147089"]` (whitelist Telegram user ID)
   - `channels.websocket` — `enabled`, `host: 0.0.0.0`, statický `token` (32B hex)
   - `gateway.host: 0.0.0.0` — bind všech rozhraní (jinak gateway odmítne startnout s `websocket.host: 0.0.0.0` bez tokenu)

4. **Test LLM:** `nanobot agent --message "..."` přes OpenRouter odpověděl modelem `moonshotai/kimi-k2.6`. Workspace `~/.nanobot/workspace` se vytvořil při prvním spuštění (AGENTS.md, USER.md, SOUL.md, HEARTBEAT.md, TOOLS.md, memory/, git store).

5. **Test Telegramu:** `nanobot gateway --verbose` v popředí → bot `@lachran_nanobot` se připojil (polling mode). Uživatel poslal zprávu v Telegramu, bot odpověděl ("Běžím na modelu Moonshot AI Kimi K2.6. 🐈"). LLM usage: prompt=6464, completion=62, latency ~5.3s.

6. **Test WebUI:** `curl http://nanobot.hell:8765/` → HTTP 200, HTML SPA z `nanobot/web/dist/index.html`. WebUI HTML i WebSocket auth endpoint jsou na stejném portu 8765 (gateway zdraví zvlášť na 18790).

**Otevřené:** systemd unit (user-level), enable lingering, restart test.

**Hraniční zjištění:**

- WebUI HTML je v `~/.local/share/uv/tools/nanobot-ai/lib/python3.13/site-packages/nanobot/web/dist/` — součást wheelu, není to externí asset.
- README projektu odkazuje na `docs/configuration.md`, ale schéma `websocket` channelu v něm chybí — k poznání klíčů `host/port/path/token/allowFrom/streaming/websocketRequiresToken` jsem se dostal přes `docs/websocket.md` a `docs/deployment.md`.
- `nanobot status` ukázal `OpenAI Codex: ✓ (OAuth)` a `Github Copilot: ✓ (OAuth)` přestože nejsou v configu — patrně automatická detekce systémových OAuth tokenů. Žádný efekt na běh, ignoruji.
- Port 8765 je teď otevřený na všech rozhraních `nanobot.hell` — chráněn statickým bearer tokenem. Až nasadíme nginx reverse proxy na `nano.hell.cz`, vrátíme bind na `127.0.0.1`.

## 2026-05-26 — modelPresets: Kimi + Minimax + Qwen

**Cíl:** Mít víc modelů na výběr — Kimi K2.6 jako default, Minimax M2.7 a Qwen 3.7 Max jako alternativy.

**Zjištění:** Nanobot nepodporuje víc *pojmenovaných agentů*, ale **`modelPresets`** — pojmenované sady (provider, model), mezi kterými se přepíná za běhu `/model <preset>` v chatu (Telegram i WebUI). Jeden agent, několik presetů.

**Provedeno:**

1. Nejnovější Qwen na OpenRouteru zjištěn dotazem na `/api/v1/models` → `qwen/qwen3.7-max` (flagship Qwen 3.7 série).

2. `~/.nanobot/config.json` rozšířen o:

   ```json
   "agents": { "defaults": { "modelPreset": "kimi" } },
   "modelPresets": {
     "kimi":    { "provider": "openrouter", "model": "moonshotai/kimi-k2.6" },
     "minimax": { "provider": "openrouter", "model": "minimax/minimax-m2.7" },
     "qwen":    { "provider": "openrouter", "model": "qwen/qwen3.7-max" }
   }
   ```

3. Gateway restartován. `nanobot status` potvrdil `Model: moonshotai/kimi-k2.6 (preset: kimi)`. Startup log: `Runtime model switched for next turn: moonshotai/kimi-k2.6 -> moonshotai/kimi-k2.6` (preset resolver běží na začátku každého turn).

**Použití:** v chatu napsat `/model minimax` nebo `/model qwen` — od dalšího tahu se přepne. `/model` bez argumentu vrátí aktuální preset.

## 2026-05-26 — user-level systemd služba `nanobot.service`

**Cíl:** Aby `nanobot gateway` běžel perzistentně (přežil odhlášení uživatele i restart serveru), bez root práv pro vlastní službu.

**Volba:** user-level systemd unit (`~/.config/systemd/user/`) místo system-level. Důvod: služba sahá jen do home uživatele `nanobot`, není důvod ji mít v `/etc/systemd/system/` s root vlastnictvím. Lingering vyřeší to, že user manager (`user@1000.service`) běží nezávisle na přihlášení.

**Provedeno:**

1. **Lingering povolen** (vyžaduje root):

   ```bash
   ssh root@nanobot.hell 'loginctl enable-linger nanobot'
   ```

   `loginctl show-user nanobot` po fixu: `Linger=yes`. Vytvoří se `/run/user/1000/` při bootu automaticky, user manager je v `user@1000.service`.

2. **Unit file** `/home/nanobot/.config/systemd/user/nanobot.service`:

   ```ini
   [Unit]
   Description=nanobot AI gateway (Telegram + WebUI)
   After=network-online.target

   [Service]
   Type=simple
   ExecStart=/home/nanobot/.local/bin/nanobot gateway
   Restart=on-failure
   RestartSec=5
   Environment=LANG=en_US.UTF-8
   Environment=LC_ALL=en_US.UTF-8

   [Install]
   WantedBy=default.target
   ```

   `After=network-online.target` je system unit — pro user-scope to nemá tvrdou závislost, ale ordering systemd respektuje, dokud lingering startuje user manager *po* network-online.

3. **Aktivace** (přes SSH, kde `XDG_RUNTIME_DIR` neexistuje v non-login session — nutno nastavit ručně):

   ```bash
   ssh nanobot@nanobot.hell 'XDG_RUNTIME_DIR=/run/user/1000 systemctl --user daemon-reload \
                              && systemctl --user enable --now nanobot.service'
   ```

   Symlink `default.target.wants/nanobot.service` → enabled.

4. **Ověření:** `systemctl --user status nanobot.service` ukázal `active (running)`, Main PID 5657. Endpointy: WebUI `http://nanobot.hell:8765/` → HTTP 200, health `http://nanobot.hell:18790/health` → `{"status":"ok"}`, Telegram bot `@lachran_nanobot` připojený.

**Logování:** `journalctl --user -u nanobot.service -f` (nutno mít `XDG_RUNTIME_DIR=/run/user/1000` v env, pokud se přihlašuju non-login SSH session).

**Otevřené:** test, že služba přežije `reboot` serveru.

## 2026-05-26 — Reboot test: `nanobot.service` přežije restart serveru

**Cíl:** Potvrdit, že lingering + `WantedBy=default.target` opravdu nastartuje gateway i po cold rebootu, ne jen při interaktivním přihlášení.

**Provedeno:**

1. Pre-reboot `boot_id` zaznamenán (`fe922ca4-...`).
2. `ssh root@nanobot.hell 'systemctl reboot'` — SSH session dropped (čekáno).
3. Polling `ssh -o ConnectTimeout=3` v 3-sec intervalech, server zpátky po ~15 s, nový `boot_id` (`3d20399d-...`), `uptime -p` = `up 0 minutes`, `systemctl is-system-running` = `running`.
4. `nanobot.service` status: `active (running) since 18:36:13`, Main PID **233** (nízké PID = startovalo brzy v bootu, hned jak naběhl `user@1000.service`).
5. Journal potvrdil, že telegram i websocket channel naběhly bez chyby.
6. **Externí ověření** z mé strany: `curl http://nanobot.hell:8765/` → HTTP 200 (WebUI), `curl http://nanobot.hell:18790/health` → `{"status":"ok"}`.

**Závěr:** Lingering + user-level systemd unit funguje přesně jak má — žádný manuální zásah po rebootu není potřeba.

## 2026-05-26 — Swap `qwen` presetu na qwen3.6-plus

**Změna:** Uživatel chtěl místo `qwen3.7-max` použít "qwen-plus". Čistý `qwen-plus` slug na OpenRouteru neexistuje — dvě "plus" varianty:

- `qwen/qwen3.5-plus-20260420` — multimodal (text/image/video), 1M context
- `qwen/qwen3.6-plus-04-02` — hybridní lineární attention + sparse MoE

Zvolen novější `qwen/qwen3.6-plus-04-02` (vyšší verze + novější architektura).

**Provedeno:**

1. `~/.nanobot/config.json` upraven přes Python in-place (zachoval ostatní klíče): `modelPresets.qwen.model` → `qwen/qwen3.6-plus-04-02`.
2. `systemctl --user restart nanobot.service` — service `active`, oba kanály naběhly bez chyby.

**Poznámka:** `done.md` záznam o "Qwen 3.7 Max" upraven přímo (model je implementační detail dokončeného úkolu "přidej Qwen jako alternativu"), aby done.md odráželo realitu. History je append-only, tady je proto kompletní stopa.

## 2026-05-26 — Ollama na `nvidia.hell` jako druhý provider + přejmenování presetů

**Cíl:** Vedle OpenRouteru zapojit lokální Ollama instanci, která běží na `nvidia.hell:11434`. Ta hostuje i `:cloud`-tagované modely (Ollama si je tahá ze své cloud služby na vyžádání, takže lokální endpoint nabízí nejen lokálně stažené modely, ale i cloudové).

**Korekce hostname:** V dřívějším todo bylo `nvidila.hell` — překlep podle uživatelovy zprávy. Správně je `nvidia.hell` (192.168.4.45). `nvidila.hell` neexistuje v DNS.

**Zjištění Ollama modelů:** `curl http://nvidia.hell:11434/api/tags` — 57 modelů. Z toho cloud-tagované (`:cloud` suffix, ne `-cloud`):

```
deepseek-v3.2:cloud, gemma4:31b-cloud, glm-5.1:cloud, gpt-oss:120b-cloud,
kimi-k2.5:cloud, kimi-k2.6:cloud, minimax-m2.7:cloud,
nemotron-3-super:cloud, qwen3.5:cloud
```

Pro nás zajímavé: `kimi-k2.6:cloud` (nejvyšší Kimi) a `minimax-m2.7:cloud` (jediný dostupný Minimax).

**Provedeno:**

1. Přidán provider `ollama` s `apiBase: http://nvidia.hell:11434` (klíč `apiBase`, nikoli `baseUrl` — viz `docs/configuration.md`).

2. `modelPresets` přejmenovány a doplněny (uživatel chtěl rozlišit Ollama vs. OpenRouter v názvu):

   | preset | provider | model |
   |---|---|---|
   | `kimi-k2.6-openrouter` (default) | openrouter | `moonshotai/kimi-k2.6` |
   | `minimax-m2.7-openrouter` | openrouter | `minimax/minimax-m2.7` |
   | `qwen-3.6-plus-openrouter` | openrouter | `qwen/qwen3.6-plus-04-02` |
   | `kimi-k2.6-ollama` | ollama | `kimi-k2.6:cloud` |
   | `minimax-m2.7-ollama` | ollama | `minimax-m2.7:cloud` |

3. `agents.defaults.modelPreset` přesměrován na `kimi-k2.6-openrouter` (původně `kimi`, nyní s novým názvem). Default zůstal stejný (Kimi K2.6 přes OpenRouter).

4. `systemctl --user restart nanobot.service` — service `active`, oba kanály naběhly. `nanobot status` potvrdil `Model: moonshotai/kimi-k2.6 (preset: kimi-k2.6-openrouter)`.

5. **Konektivita ověřena:** `curl http://nvidia.hell:11434/api/tags` z `nanobot.hell` projde, `kimi-k2.6:cloud` k dispozici. Reálné odeslání zprávy přes Ollama preset zatím netestováno — proběhne automaticky, jakmile někdo v Telegramu/WebUI udělá `/model kimi-k2.6-ollama`.

**Edit configu in-place:** Použit `python3 -c` na serveru (`json.loads → mutate → json.dumps`), aby se zachovaly ostatní klíče (token, telegram, gateway, websocket). Předtím jsem to dělal přepsáním celého souboru přes heredoc — bezpečnější, ale upovídanější.

## 2026-05-26 — Oprava Ollama provideru: `/v1` suffix v `apiBase`

**Problém:** Uživatel hlásil, že ollama presety nefungují. Test přes `nanobot agent --message ... --logs` s dočasným přepnutím default presetu na `kimi-k2.6-ollama`:

```
LLM returned error: Error: 404 page not found
```

Streamovaný startup log předtím říkal `Runtime model switched for next turn: kimi-k2.6:cloud -> kimi-k2.6:cloud`, takže slug modelu byl správný a request odešel — Ollama jen na cestě, kterou nanobot zavolal, vrátil 404.

**Diagnóza:** Přímý curl na `http://nvidia.hell:11434/api/chat` s payloadem `{"model":"kimi-k2.6:cloud","messages":[...]}` fungoval (model odpověděl). Z toho plyne, že nanobot **nevolá Ollama-native `/api/chat`, ale OpenAI-kompatibilní `/v1/chat/completions`**, který Ollama servíruje pod prefixem `/v1`. V configu jsem měl `apiBase: http://nvidia.hell:11434` — bez `/v1`.

**Fix:** `providers.ollama.apiBase` → `http://nvidia.hell:11434/v1`.

**Ověření:**

- `kimi-k2.6-ollama` přes `nanobot agent` → streamovaná odpověď, OK.
- `minimax-m2.7-ollama` → log `Runtime model switched for next turn: minimax-m2.7:cloud -> minimax-m2.7:cloud`, request prošel, model odpověděl. (Identifikoval se jako "Kimi K2.6" — halucinace modelu kvůli sdíleným session ID `cli:direct`, ne chyba nanobotu.)

Gateway restartován, `nanobot.service` aktivní s opraveným configem.

**Učení pro příště:** `docs/configuration.md` říká, že `apiBase` je "the Ollama server endpoint" a uvádí příklad `http://localhost:11434` — bez `/v1`. To je zavádějící pro nanobot, který interně používá OpenAI klienta proti Ollama. Pro Ollamu vždy přidat `/v1` na konec apiBase.

## 2026-05-26 — Přidán preset `glm-5.1-ollama`

**Cíl:** Mít GLM 5.1 (z Ollama na `nvidia.hell`) jako další volitelný model.

**Provedeno:**

1. Ověřeno, že `glm-5.1:cloud` je v `curl http://nvidia.hell:11434/api/tags` (figurovalo už ve výpisu cloud modelů z [záznamu o Ollama provideru](#2026-05-26--ollama-na-nvidiahell-jako-druhý-provider--přejmenování-presetů)).
2. `~/.nanobot/config.json` rozšířen přes Python in-place editor o nový preset:

   ```json
   "glm-5.1-ollama": { "provider": "ollama", "model": "glm-5.1:cloud" }
   ```

3. **Restart služby zablokován** auto-mode klasifikátorem (`systemctl --user restart nanobot.service` přes SSH). Uživatel musí restart spustit ručně, nebo povolit Bash pravidlo.

**Otevřené:** restart `nanobot.service`, ověřit `/model glm-5.1-ollama` v chatu.

**Generalizace** zapsána do [knowledge.md](knowledge.md) jako recept "Postup: přidání nového modelu (preset)" — bude se hodit i pro další modely.

## 2026-05-26 20:39 — Zapnutí verbose logování gateway (`-v`)

**Cíl:** vidět průběh zpracování zprávy — volané tooly, odpovědi, tok tahu. Platí i pro WebUI.

**Zjištění (zdroj: DeepWiki CLI reference + `nanobot gateway --help`):** nanobot defaultně `logger.disable("nanobot")`. Gateway má `-v`/`--verbose` (DEBUG), agent má `--logs`. WebUI běží uvnitř gateway (websocket channel, port 8765) → `-v` ho pokrývá, separátní přepínač není.

**Provedeno:**

1. `sed` úprava `~/.config/systemd/user/nanobot.service`: `ExecStart=… nanobot gateway` → `… gateway -v`.
2. `systemctl --user daemon-reload && restart` → `active`.
3. Test: přes WebUI poslána zpráva „pouzij python pro zjisteni aktualniho casu“.

**Výsledek (journal):** plně vidět tok tahu — `Processing message …`, stavy `RESTORE→…→RESPOND`, `Tool call: exec({...})`, `LLM usage: prompt/completion/cached`, `Response to …`. NEloguje se tělo tool výsledku ani thinking (to jde do WebUI klienta zvlášť).

**Pozn.:** edit unitu přes SSH zprvu blokoval auto-mode klasifikátor i po vlastní AskUserQuestion; vyřešeno přidáním `Bash(ssh nanobot@nanobot.hell:*)` do `.claude/settings.json`.

**Zapsáno** do [knowledge.md](knowledge.md) jako "Logování: gateway `-v`/`--verbose`, agent `--logs`".

## 2026-05-26 — Přidán preset `deepseek-v3.2-ollama`

**Cíl:** zpřístupnit `deepseek-v3.2:cloud` z Ollama (přes `nvidia.hell`) jako přepínatelný model — kandidát na levný autonomní workhorse (cron/heartbeat). Vychází z rozvahy „top 10 modelů pro nanobot" (Ollama cloud + OpenRouter, bez Anthropic/OpenAI).

**Provedeno (postup dle [knowledge.md](knowledge.md) „Postup: přidání nového modelu"):**

1. Ověřeno `curl http://nvidia.hell:11434/api/tags` → `deepseek-v3.2:cloud` přítomno.
2. `~/.nanobot/config.json` rozšířen přes Python in-place editor:

   ```json
   "deepseek-v3.2-ollama": { "provider": "ollama", "model": "deepseek-v3.2:cloud" }
   ```

3. `systemctl --user restart nanobot.service` → `active`.

**Výsledek:** preset funkční, v chatu přepnutelný `/model deepseek-v3.2-ollama`. Rutinní změna, žádné nové zjištění do knowledge.md.

## 2026-05-27 — Aktualizace šablony CLAUDE.md podle vzoru

**Cíl:** sjednotit šablonu `.claude/templates/CLAUDE.md` s dozrálým kořenovým `CLAUDE.md` (vzorem), aby nové projekty dostaly aktuální strukturu pravidel.

**Co jsem zkusil:** porovnal šablonu vs. kořenový CLAUDE.md. Šabloně chyběly soubory `knowledge.md` a `plans.md`, tabulkový přehled tracking souborů a per-soubor poznámky (struktura záznamu history, vyřešené chyby/zamítnuté možnosti v knowledge, otázky→knowledge). Přepsal šablonu: tabulka 6 souborů + per-soubor sekce + commit pravidlo s prefixy + NEDĚLEJ. Projektově specifické věci (SSH nanobot.hell, popis nanobota) jsem vynechal — šablona zůstává generická.

**Co fungovalo a proč:** Write přes celý soubor; obsah převzat ze vzoru a zobecněn (`<slug>` místo konkrétní cesty).

**Co zbývá:** nic; rutinní synchronizace.

## 2026-05-28 17:23 — Skill `detach` + tasks-daemon (background úlohy mimo agent loop)

**Cíl:** umožnit uživateli v chatu (Telegram/WebUI) říct „udělej X na pozadí, dej vědět až bude hotovo" a vrátit se k jiné práci. Use cases: deep research, wiki ingest, libovolný úkol moc dlouhý na synchronní čekání v chatu.

**Co jsem zkusil (cesta k finálnímu designu):**

1. **Cron tool + `at` schedule** (zavrženo). Builtin `cron(action="add", at=ISO, deliver=true)` auto-injektuje channel context (`cron.py:173-218`) a `delete_after_run=True` se zapne sám pro `at` schedule. Krásně jednoduché, ale `on_cron_job` v `commands.py:891-897` obaluje payload v hardcoded preamble *„The scheduled time has arrived. Deliver this reminder…do not narrate progress, summarize, include user IDs, or add status reports like 'Done'"*. To přímo odporuje tomu, co background úloha potřebuje — provést úkol, zapsat výsledek do souboru, vrátit informativní větu. Stejný preamble bug už dřív vedl k „Output was empty" spamu reminderů (history 2026-05-27).

2. **Externí daemon mimo agent loop** (uživatelův návrh, finální). Replikuje pattern `/remind` skillu — doručování úplně mimo agenta. Skill jen zapíše task soubor do `tasks/inbox/`, daemon ho přečte, projede `nanobot agent` v izolované session, výsledek uloží do souboru, pošle Telegram zprávu přes Bot API.

3. **Subprocess `nanobot agent --message` vs Python API** (Python API). CLI funguje, ale streamuje chaoticky (`✻` prefixované delty + finální čistá odpověď na konci). Postprocesovat by bylo křehké. `Nanobot.from_config().run()` (`nanobot.py:71-102`) vrací `RunResult.content` jako čistý string, bez streamovacích nečistot.

4. **Systemd `.timer` vs `.path` unit** (`.path`). Timer (každou minutu) by zaváděl zbytečné polling + 1-min latenci, kterou pro detach nepotřebujeme. `.path` unit s `DirectoryNotEmpty=` (inotify-driven) reaguje do desítek ms, navíc se `Type=oneshot` automaticky neserializuje souběh. Ověřeno test unitem před deployem.

5. **`flock` proti souběhu** (zavrženo, uživatelův návrh). Systemd `Type=oneshot` se nespustí podruhé, dokud první běh trvá; level-triggered `.path` ho po doběhu restartne, pokud kondice stále platí. Partial-write race řeší skill atomickým `mv` z `tasks/tmp/` (nehlídané systemd) do `tasks/inbox/` (hlídané) — daemon nikdy neuvidí napůl zapsaný soubor.

6. **Chat_id discovery** (vyřešeno bez patche). ContextBuilder vkládá do runtime contextu zprávy `Channel: <name>` a `Chat ID: <id>` (`context.py:123-139`). Skill v SKILL.md instruuje agenta, ať si chat_id přečte odtud, takže žádný session_info() helper tool nepotřebujeme.

**Co fungovalo a proč:** Smoke test prošel za 3 sekundy end-to-end:

- Vytvořen fake task soubor `2026-05-28T172259-smoke-test.md` v `tasks/tmp/`, `mv` do `tasks/inbox/`.
- Systemd `.path` unit spustil `tasks-daemon.service` okamžitě (z `inactive` do `active`).
- Daemon přesunul `inbox/ → running/`, zavolal `Nanobot.run("Odpověz jedním slovem: kolik je 2+2?")`, dostal `"čtyři"`.
- Appendnut `## Result` + metadata footer (`completed`, `duration_seconds`, `status`), `mv → done/`.
- `telegram_send(chat_id, "✅ Hotovo: čtyři. Detail: workspace/tasks/done/…")` — `NOTIFIED 8826147089` v daemon logu.

Logy:

```
2026-05-28T17:23:00 DRAIN start 1 task(s)
2026-05-28T17:23:00 START 2026-05-28T172259-smoke-test.md
2026-05-28T17:23:03 NOTIFIED 2026-05-28T172259-smoke-test.md → 8826147089
2026-05-28T17:23:03 END 2026-05-28T172259-smoke-test.md status=done duration=3s
```

**Architektura (finální):**

```
[uživatel v Telegram]
       │
       ▼
[skill detach]
   1. write_file workspace/tasks/tmp/<ts>-<slug>.md
   2. exec mv tmp/ → inbox/   (atomický)
   3. ack uživateli 1 větou
       │
       ▼
[systemd .path: DirectoryNotEmpty=tasks/inbox]  (inotify)
       │
       ▼
[tasks-daemon.service Type=oneshot]
   tasks-daemon.py — Python API Nanobot.run() v izolované session detach:<stem>,
   append ## Result, mv → done|failed, Telegram Bot API zpráva
```

**Soubory:**

- `~/.nanobot/workspace/skills/detach/SKILL.md` + `scripts/tasks-daemon.py` + `systemd/tasks-daemon.{path,service}` (server)
- Tracking: [skills/detach/](skills/detach/) v tomto repu
- Plán: [/home/lachtan/.claude/plans/pojdme-jeste-chvili-planovat-binary-harp.md](/home/lachtan/.claude/plans/pojdme-jeste-chvili-planovat-binary-harp.md) (kompletní rozhodovací stopa)

**Co zbývá:**

- Reálný test skillu z chatu (uživatel triggerne přes Telegram, ověří, že agent správně přečte Chat ID z runtime contextu, vyrobí slug+timestamp, atomicky přesune do inbox/).
- Smoke test #2 — timeout (úkol >15min → status=failed).
- Smoke test #3 — primární use case (deep research s `subagent`/`web_fetch`).
- **Python skript se uživateli moc nelíbí — bude pročištěn v dalším kole** (čistší struktura, méně kódu, lepší error handling).
- Zvážit přesun plánu do tracking repa do `plans/detach-background-tasks.md` (zatím žije v `~/.claude/plans/`).

**Zapsáno do knowledge.md:** „Non-interactive nanobot CLI vs Python API", „Agent vidí Channel/Chat ID v runtime contextu", „Cron preamble je hardcoded — pro non-reminder background úlohy obejít", „Detach skill — background úlohy přes externí daemon", „Systemd .path unit s DirectoryNotEmpty=". Opraveno zastaralé tvrzení „jobs.json změna se projeví po restartu" — hot reload funguje, `_load_store()` per tick.

## 2026-05-28 18:37 — Detach skill iterace #2: fallback chat_id + subactions list/read + SKILL.md do EN

**Cíl:** opravit dva nedostatky z reálného testu (uživatel pustil úkol z WebUI):

1. **Bug 1**: Telegram notifikace selhala HTTP 400, protože WebSocket session má v runtime contextu `Chat ID: <UUID>`, ne Telegram chat ID. Skill ho poslušně dal do frontmatteru, daemon ho strčil do Bot API.
2. **Bug 2**: i kdyby notifikace dorazila, je v ní jen jednořádkové shrnutí + cesta k souboru — chyběl ergonomický mechanismus pro přečtení výsledku v chatu.

**Rozhodnutí (uživatel):** Telegram + WebUI současně (Fáze 2a = fallback Telegram chat_id, Fáze 2b = WebSocket push odloženo); rozšířit `detach` skill o subactions (`list`, `read`), ne nový skill. **SKILL.md přepsat do angličtiny** — slabší modely lépe následují anglické instrukce (stejný pattern jako `deep-research/SKILL.md`).

**Co jsem zkusil a co fungovalo:**

1. **Daemon `resolve_telegram_chat_id(fm)`:** vrátí `(chat_id, source)`. Když `fm.channel == "telegram"` → použij `fm.chat_id` (multi-user ready). Jinak → načti `fallback_telegram_chat_id` z `~/.nanobot/workspace/skills/detach/config.json`. Log line `NOTIFY chat=<id> source=<frontmatter|fallback>`.

2. **Nový soubor `config.json` ve skill adresáři:**

   ```json
   {"fallback_telegram_chat_id": "8826147089"}
   ```

   Editovatelný bez touch daemon kódu, single-user setup vyhraje hardcode.

3. **Telegram notifikace text** přepracován — obsahuje slug v první řádce + výzvu „v chatu si vyžádej plný report: `výsledek <slug>`":

   ```
   ✅ Hotovo: `fallback-test`

   hello

   V chatu si vyžádej plný report: `výsledek fallback-test`
   ```

4. **SKILL.md kompletně přepsán anglicky** — tělo (postup, příklady, failure handling) v EN, trigger fráze v `description` zachovány dvojjazyčné (CZ + EN, uživatel mluví česky). Skill explicitně instruuje agenta „respond to user in their language" — ack zpráva a notifikace se přeloží.

5. **Tři subactions v jednom skillu:**
   - **`detach`** (default) — beze změny krom slug v ack zprávě.
   - **`list`** — `exec ls -1t tasks/{running,done,failed}/`, markdown tabulka grouped by status.
   - **`read <identifier>`** — identifier = slug, část slugu, timestamp fragment, nebo prázdný (nejnovější done). `grep -i` přes ls výstup, `read_file` matche, předlož `# Result` sekci + metadata footer.

**Co fungovalo (smoke test fallback):**

```
2026-05-28T18:37:18 DRAIN start 1 task(s)
2026-05-28T18:37:18 START 2026-05-28T183718-fallback-test.md
2026-05-28T18:37:25 NOTIFY 2026-05-28T183718-fallback-test.md chat=8826147089 source=fallback
2026-05-28T18:37:25 END 2026-05-28T183718-fallback-test.md status=done duration=6s
```

Fake task s `channel: websocket`, `chat_id: "68254619-fake-websocket-uuid-test"` → daemon rozeznal non-telegram channel → použil fallback `8826147089` → HTTP 200 OK. Trvání 6s (krátký úkol bez tools).

**Co zbývá:**

- **Reálný retest Bug 1**: uživatel spustí detach z WebUI → Telegram zpráva musí dorazit.
- **Reálný retest Bug 2**: v chatu (Telegram nebo WebUI) řekni „výsledek fallback-test" → agent musí přečíst soubor a předložit Result sekci. Také „výsledky?" → list všech.
- **Fáze 2b odložena** (Fáze 3): WebSocket push z daemonu do nanobot gateway pro live notifikaci v aktivní WebUI session. Důvod: nanobot WS gateway vyžaduje JWT auth (`channels.websocket.token_issue_secret`), WS klient v daemonu, envelope format — komplexní, zatím vyřešeno přes `výsledek <slug>` pull mechanismus.
- **Pročištění Python skriptu** — uživatel řekl v iteraci #1, že to udělá sám v dalším kole.

---

## 2026-05-29 — Skill `/keep` — doplnění MEMORY.md cross-check (dedup krok 4)

**Cíl:** Skill `/keep` deduplikoval pouze v rámci `keep.md`. Dream pipeline destiluje fakta do `workspace/memory/MEMORY.md` na pozadí — pokud tam podobný fakt už je, zápis téhož do `keep.md` je zbytečná duplicita. Doplnit do write protokolu krok, který před appendem přečte `MEMORY.md` a pokud tam je sémanticky podobný fakt, uživatele upozorní a defaultně přeskočí.

**Co jsem zkusil / Co fungovalo a proč:**

1. **`skills/keep/SKILL.md` — write protocol:** vložen nový krok 4 (čti `workspace/memory/MEMORY.md`, porovnej sémanticky; pokud shoda → zeptat se, default: skip). Původní kroky 4–7 přečíslovány na 5–8.
2. **`skills/keep/SKILL.md` — Rules:** řádek `"do not cross-write"` nahrazen přesnější formulací (`"never cross-write. Read MEMORY.md only for dedup check (step 4); never edit it from this skill."`).
3. **Deploy:** `rsync -av skills/keep/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/keep/` — `SKILL.md` odeslán.
4. **Ověření na serveru:** `grep -A4 'MEMORY.md'` vrátil nový krok 4 a nový Rules řádek — obojí správně.

**Co zbývá (pro uživatele):**

- End-to-end test: vybrat fakt, který již je v `workspace/memory/MEMORY.md`, poslat ho agentem jako `keep: <fakt>` → agent by měl reagovat hláškou „Already in MEMORY.md: …" a defaultně nepsat.
- Regrese dedup v `keep.md` pořád funguje: nový fakt 2× po sobě → při druhém pokus se agent zeptá na duplicitu v `keep.md`.

---

## 2026-05-29 14:04 — Skill `/keep` — explicit memory store

**Cíl:** Vytvořit on-demand skill pro okamžitou explicitní paměť. Uživatel řekne "keep X" → agent reformuluje → zapíše do `workspace/keep.md`. Trvalé povědomí zajistit referencí v `USER.md` (auto-loadovaný každý tah), nikoli `always: true` skillem — šetří context window.

**Klíčové rozhodnutí (přijaté před implementací):** `BOOTSTRAP_FILES` v `nanobot/agent/context.py:25` jsou hardcoded — nelze přidat vlastní soubor bez patche. Persistent awareness `keep.md` tedy řeší krátká sekce v `USER.md` (ten je bootstrap), ne further always-on skill. Skill `/keep` je čistě on-demand write endpoint.

**Co jsem zkusil / Co fungovalo a proč:**

1. **Lokální `skills/keep/SKILL.md`** — vytvořen dle plánu. Frontmatter on-demand (bez `always`), tělo anglicky: write protocol (extract fact → reformulate → read → dedup → append), compaction (>150 řádků), edge cases, pravidla.
2. **Deploy** přes `rsync -av skills/keep/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/keep/` — nanobot user, ownership `nanobot:nanobot` automaticky.
3. **USER.md reference** — append sekce `## workspace/keep.md` + popis na konec `/home/nanobot/.nanobot/workspace/USER.md` (jako `nanobot` user přes SSH, tee -a). Ověřeno `tail -7`.

**Ověření (sanity check):**

- `ls -la /home/nanobot/.nanobot/workspace/skills/keep/` → `SKILL.md` owned `nanobot:nanobot`.
- `head -25 SKILL.md` → frontmatter + tělo správně.
- `tail -7 USER.md` → sekce `## workspace/keep.md` na konci.

**Co zbývá (pro uživatele):**

- End-to-end test: v Telegramu/WebUI říct „keep: Honza z marketingu má alergii na arašídy" → ověřit `keep.md` na serveru.
- Persistent awareness test: v nové session se zeptat na Honzu → agent zmíní alergii.
- Compaction test: naplnit `keep.md` na 151+ řádků, spustit `/keep`, ověřit compaction report.

---

## 2026-05-28 19:46 — Detach skill iterace #3 — uv-native + čitelnostní cleanup

**Cíl:** Přepnout `tasks-daemon.py` na uv-native invokaci (PEP 723 + `uv run --script`) a provést drobné čitelnostní úpravy: modulový import, rozložit `summary_line` oneliner, odstranit zbytečné `str()` wrappy v `shutil.move()`. Žádné nové abstrakce.

**Co jsem zkusil / Co fungovalo a proč:**

1. **Shebang + PEP 723 hlavička** — `#!/usr/bin/env -S uv run --script` + inline script metadata (`requires-python = ">=3.11"`, `dependencies = ["nanobot-ai"]`). `uv run --script` samo vytvoří izolované venv s `nanobot-ai`, bez závislosti na konkrétní cestě `~/.local/share/uv/tools/nanobot-ai/bin/python`. Lokální dry-run: `uv` stáhl 114 packages, skript skončil 0 (inbox prázdný).
2. **Modulový `from nanobot import Nanobot`** — přesun z těla `run_agent()` na úroveň modulu (Python konvence: import uvnitř funkce jen pro circular deps nebo heavy optional deps, `nanobot` je core dep).
3. **`summary_line` rozložen** — jednořádkový `(result_text.strip().splitlines() or ["(prázdný výstup)"])[0][:200]` na 2 čitelné řádky.
4. **`str()` wrappy pryč** — `shutil.move()` přijímá path-like objekty od Python 3.9, `str()` byl cargo-cult. Odstraněno ze 4 výskytů (3× v `process_task()`, 1× zbyl jen argument `running → target_dir`).
5. **Docstring sjednocen na CZ** — EN anotace v hlavičce přeložena do češtiny, diff se tím nezvětšil nad limit.
6. **tasks-daemon.service doplněn o `Environment=PATH=%h/.local/bin:/usr/bin:/bin`** — bez toho by systemd nenašel `uv` (není v defaultní PATH user unitů). `daemon-reload` přes `XDG_RUNTIME_DIR=/run/user/1000`.
7. **Smoke test prošel**: task `2026-05-28T174616-uv-smoke.md` (`channel=telegram`, `chat_id=8826147089`, goal=`odpověz \`hotovo\``) → daemon zpracoval za 4s, log:`START`,`NOTIFY chat=8826147089 source=frontmatter`,`END status=done duration=4s`. Telegram zpráva dorazila.

**Diff:** 23 changed lines v `tasks-daemon.py` (14 insertions, 9 deletions) — pod limitem 30.

**Rsync:** `rsync` přes `nanobot` uživatele selhal (`rsync: command not found` na straně serveru), použit `scp` přes `root` + `chown nanobot:nanobot`.

**Co zbývá:**

- Verifikace z plánu: `uv tool uninstall nanobot-ai && uv tool install nanobot-ai` přežití (důkaz nezávislosti na tool venv cestě) — nízká priorita, PEP 723 pattern to garantuje designově.

---

## 2026-05-29 — Skill `/note` — explicit notes bez auto-loadu

**Cíl:** Vytvořit skill pro ukládání poznámek do `workspace/notes.md`. Na rozdíl od `/keep` se soubor neauto-loaduje do context window, nemaže se automaticky, a mazání probíhá pouze explicitně přes `/note delete <pattern>`.

**Klíčové rozhodnutí:** Žádná reference v `USER.md` ani jiném bootstrap souboru — `notes.md` nikdy nevstupuje do kontextu automaticky. Žádná auto-kompakce. Žádný dedup check (ani proti `notes.md`, ani `keep.md`, ani `MEMORY.md`) — blind append.

**Co jsem udělal:**

1. Vytvořen lokální `skills/note/SKILL.md` s write protokolem (extract → reformulate → append), delete protokolem (by index nebo substring, multi-match ukáže seznam), edge cases a rules.
2. Deploy: `rsync -av skills/note/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/note/` — `SKILL.md` odeslán, ownership `nanobot:nanobot`.
3. Žádný patch `USER.md` — záměrně, notes jsou off-context.

**Co zbývá:**

- Verifikace end-to-end: `note: testovací poznámka` v Telegramu/WebUI → ověřit `notes.md` na serveru.
- Test delete by substring, by index, multi-match.
- Ověřit, že notes nejsou v auto-contextu: `grep -i note /home/nanobot/.nanobot/workspace/USER.md` → žádná shoda.

---

## 2026-05-29 — Skill `/keep` — EN-only tělo + pravidlo o jazyku

**Cíl:** Revize kvality `skills/keep/SKILL.md`. Hlavní vada: chybělo pravidlo „zachovej jazyk vstupu = výstupu", které `/note` nedávno dostal (`ea81761`, `c8667eb`) — keep na fix zapomněl, takže český vstup se mohl uložit anglicky.

**Klíčové rozhodnutí uživatele:** tělo skillu držet **striktně anglicky**, žádné české příklady. Stačí jasné pravidlo *„preserve input language, never translate"* — model ho dodrží sám. Dvojjazyčné triggery v `description` frontmatteru **ponechat** (nutné pro routing; bez českých frází se skill na český vstup nespustí). Potvrzovací hlášku model lokalizuje sám podle jazyka odpovědi → CZ varianta `Zapamatoval jsem:` v těle byla redundantní.

**Co jsem udělal:**

1. **Write protocol krok 2** — přidána věta *„Preserve the language of the input — never translate. Czech input → Czech entry, English input → English entry."* Bez českého příkladu, stávající EN příklad ponechán.
2. **Confirm krok 8** — odstraněna CZ varianta `Zapamatoval jsem:`, nechán jen `Kept: <fact>` + poznámka, že model lokalizuje sám.
3. **Rules** — přidána odrážka „Preserve input language; never translate." a sloučeny dvě překrývající se odrážky o separaci od MEMORY.md/Dream do jedné.
4. Krok 4 (MEMORY.md dedup lookup) **beze změny** — uživatel potvrdil ponechat.
5. Deploy: `rsync -av skills/keep/SKILL.md nanobot@nanobot.hell:.../skills/keep/SKILL.md`, ownership `nanobot:nanobot` ověřeno, nasazená verze == lokální (diff = IDENTICAL).

**Co fungovalo a proč:** EN-only tělo + explicitní pravidlo o jazyku je čistší než dvojjazyčné příklady — méně šumu, model jazyk dodrží sám. Triggery v `description` jsou oddělená vrstva (routing), proto zůstaly dvojjazyčné.

**Co zbývá:**

- Smoke test přes Telegram: česky „zapamatuj si že schůzka je v pátek" → očekávaný zápis i potvrzení česky; anglicky „keep the deploy window is Friday" → zápis i potvrzení anglicky.

---

## 2026-05-30 — Skill `/note` — sjednocení s EN-only principem (jako `/keep`)

**Cíl:** Aplikovat na `skills/note/SKILL.md` stejnou revizi, jakou prošel `/keep`. `/note` jazykové pravidlo *měl* (na rozdíl od keepu), ale drželo se upovídaně se dvěma příklady (CZ + EN) — přesně to, co uživatel z keepu odstranil. Navíc dvě vady, které keep neměl: smart-quote překlepy a český placeholder.

**Co jsem udělal:**

1. **Write protocol krok 2** — zkráceno: pravidlo *„Preserve the language of the input — never translate. Czech input → Czech entry, English input → English entry."* + **jediný anglický příklad** (`deploy window — Fridays after 18:00`). Odstraněna dvojice CZ/EN příkladů. Sjednoceno s keepem.
2. **Confirm krok 5** — odstraněna CZ varianta `Zapsal jsem: <zkratka>`, nechán jen `Noted: <terse fact>` + poznámka, že model lokalizuje potvrzení sám. (Zarovnáno s keep krokem 8.)
3. **Edge cases** — opraveny smart-quote překlepy `„…"` → rovné `"…"` (ř. 53-57; uvnitř anglických vět byly české uvozovky, zbytek souboru má rovné ASCII). Český příklad `"tamtu věc"` → `"that thing"`.
4. **Rules** — beze změny (`Preserve input language` už přítomno).
5. Deploy: `rsync -av skills/note/SKILL.md nanobot@nanobot.hell:.../skills/note/SKILL.md`, ownership `nanobot:nanobot` ověřeno, nasazená == lokální (diff = IDENTICAL). 70 → 68 řádků.

**Ověřeno:** `notes` není v `USER.md` (`grep` = žádná shoda) → tvrzení skillu „no auto-load" platí. Live `notes.md` na serveru potvrzuje, že skill funguje dle návrhu (terse CZ fakta, bez dat).

**Co fungovalo a proč:** Symetrie s keepem — stejný EN-only vzor v obou near-identických skillech. Méně šumu, jazyk dodrží model sám z pravidla.

**Co zbývá:**

- Smoke test přes Telegram: česky „poznamenej si že deploy je v pátek" → zápis i potvrzení česky; anglicky „note the deploy window is Friday" → zápis i potvrzení anglicky.

---

## 2026-06-01 17:37 — Vypnutí reasoning streamu (`✻`) na konzoli

**Cíl:** Uživatele rušily na konzoli (`nanobot agent` CLI chat) řádky prefixované `✻`, streamované token po tokenu (`✻ The`, `✻ user wants`, …). Identifikováno jako **reasoning/thinking stream** modelu, ne debug ani chyba.

**Co jsem zkusil / zjistil:**

1. Prošel upstream (`tmp/nanobot-upstream`, HEAD `2b4c984`). Zobrazení `✻` řídí jediný config klíč `channels.show_reasoning` (default `True`).
   - Schema: `nanobot/config/schema.py:39` (`show_reasoning: bool = True`).
   - Gate: `nanobot/cli/commands.py:345` a `:354` — když `not channels_config.show_reasoning`, reasoning buffer se vyprázdní a netiskne. Vykreslení `✻` na `commands.py:301`.
   - Žádný runtime flag `nanobot agent` na to neexistuje (`--logs/--no-logs` řídí jen loguru runtime log, ne reasoning stream).
2. Ověřeno na serveru: klíč nebyl nastaven (`channels` mělo jen `telegram`, `websocket`) → padalo na default `True`.
3. **Per-channel to NEJDE** — `show_reasoning` je jeden globální flag na celém bloku `channels`, gate čte globální `channels_config.show_reasoning`. Nelze vypnout jen pro konzoli a nechat zapnuté ve WebUI.

**Co fungovalo a proč:** Uživatel nastavil `channels.showReasoning = false` v `~/.nanobot/config.json` a potvrdil, že `✻` řádky na konzoli zmizely. Progress (`↳`) a tool-hinty ponechány. CLI čte config čerstvě při startu (restart service netřeba); pro gateway/WebUI/Telegram by se projevilo až po restartu služby.

**Jak vrátit zpět:** smazat klíč `channels.showReasoning` z `~/.nanobot/config.json`, nebo nastavit na `true` (default).

**Co zbývá:** Reasoning se ve WebUI hodí při ladění („proč něco jde/nejde") — globální vypnutí ho zruší i tam. Per-channel přepínač upstream nemá → viz otázka v `todo.md`.

---

## 2026-06-02 06:30 — Remind skill: náhodný (deterministický) čas

**Cíl:** Rozšířit skill `remind` o režim „N× denně v náhodný, ale deterministický čas" uvnitř časového okna — aby libovolný skript spočítal pro daný den stejné časy a sender zůstal bezstavový. Návrh a rozhodnutí v [plans/remind-random-time.md](plans/remind-random-time.md).

**Co jsem zkusil / udělal:**

1. Nový sdílený modul `skills/remind/scripts/random_times.py` (stdlib only): `MIN_GAP_MIN = 15` + `compute_fire_times(date, text, cfg)`. Seed = `f"{datum}|{text}"` (per-reminder, jinak by všechny náhodné připomínky padaly ve stejné minuty). Strukturální validace (okno, počet, dny, data, feasibilita) běží *před* datovými filtry → jeden průchod validuje config nezávisle na datu.
2. Napojeno do `remind_send.py` (větev `random` v `_due_fire`, dedup/log beze změny) a `remind_edit.py` (`add --random-times-per-day/-window/-days/-from/-until`, validace přes `compute_fire_times`).
3. YAML: vnořený blok `random:` vedle `at`/`cron_exprs`. Glanceable ukázka v `reminder.example.yaml`.
4. Testy: **pytest** (nová konvence repa) v `skills/remind/tests/` + `conftest.py` (přidá `../scripts` na sys.path). 21 testů.
5. Úklid SKILL.md na žádost uživatele: celý skill EN-only (folded `description`, žádná čeština, doručovaný prefix `⏰ Reminder:`), žádné absolutní cesty (relativní `scripts/...`), odstraněna sekce `## Architecture` (provozní detail žije v knowledge.md, řádek 167).

**Co fungovalo a proč:** Před nasazením ověřena shoda serveru s baseline (commit `5a748f9`) — žádný autonomní drift. Nasazeno `rsync -av` (bez `__pycache__`), vlastník `nanobot:nanobot` OK. Na serveru `uv run --with pytest pytest tests/` → 21 passed. `remind_edit.py list` čte reálný `reminder.yaml` (stávající cron/at/at_times kompatibilní), infeasible add korektně chybuje bez zápisu. Commity: skill `bc2cf51` + předchozí, plán, todo.

**Jak vrátit zpět:** `git revert` skill commitů + `rsync` staré verze; nové soubory (`random_times.py`, `tests/`, `reminder.example.yaml`) na serveru smazat. Crontab se neměnil (stejná cesta `remind_send.py`).

**Co zbývá:** Reálná zkouška doručení přes Telegram (přidat random připomínku s krátkým oknem, ověřit doručení + `log/reminder.log`, pak smazat) — posílá skutečné notifikace, takže až na výzvu. Doladit `MIN_GAP_MIN` podle provozu.

---

## 2026-06-02 — Remind skill: per-entry ID (rozbor, zavrženo)

**Cíl:** Posoudit, jestli by přidání unikátního `id` ke každému záznamu v `reminder.yaml` přineslo skillu `remind` výhodu (lepší mazání nebo jiné), nebo ne.

**Co jsem zkusil:** Přečetl celý skill — `SKILL.md`, `remind_edit.py` (remove = `--keyword` substring na `text`, chyba při 0/>1 shodě), `remind_send.py` (dedup klíč `sha1(text)[:8]` ve `.reminder_state.json`). Zjistil, že identitou reminderu je `text` na obou místech.

**Co fungovalo a proč (závěr):** Pro běžné použití (hrstka reminderů s odlišnými texty, řízené konverzačně) ID **nepřináší nic** — keyword-remove i text-dedup fungují a jsou jednodušší; ID by jen přidalo list-then-remove krok. Jediný reálný zisk = **scénář duplicitních textů**: Create Workflow je v `SKILL.md` výslovně připouští, ale `remove` je neumí rozlišit (`ambiguous`) a dedup klíč `sha1(text)` je pro oba stejný (jeden odpal může potlačit druhý). Podle „prefer the simpler solution" ID **nezavádět plošně**. Pokud by duplicity byly reálně potřeba → buď interní dedup klíč `sha1(text+schedule)` (vyřeší jen dedup, nula změn v UX/YAML), nebo plné `id` (vyřeší i mazání). Levnější alternativa bez ID: zakázat duplicitní `text` při `add`.

**Co zbývá:** Otevřená otázka, která rozsekne směr — *chceme reálně umět dva remindery se stejným textem?* Dokud nepadne, zůstává status quo (bez ID). Zaznamenáno do knowledge.md (gotcha + zamítnutá možnost).

---

## 2026-06-02 — Detach skill: úklid SKILL.md + extrakce capture do skriptu (jako remind)

**Cíl:** Stejná revize, jakou prošel `/remind` — SKILL.md čistý a EN-only, žádné zavádějící cesty, a co má dělat skript ať dělá skript (ne agent rukama).

**Co jsem zkusil / udělal:**

1. **`scripts/tasks_common.py`** (nový, stdlib-only, importovatelný) — vystěhované sdílené čisté helpery: `TASKS`, `FILENAME_RE`, `parse_frontmatter`, `parse_kv`, `parse_filename`, `format_time/age`, `render_table`, `extract_section`, `format_result`, `build_task_filename/content`. DRY — dřív duplikované napříč třemi skripty.
2. **`scripts/create-task.py`** (nový, PEP 723, deps `[]`) — capture: `--goal/--slug/--channel/--chat-id [--constraint]`, vygeneruje timestamp + frontmatter, zajistí fronty, atomicky `tmp→inbox`. Nahrazuje ruční `date`+`write_file`+`mv`+`mkdir` v SKILL.md.
3. **Refaktor** `list-tasks.py`/`read-task.py`/`tasks-daemon.py` → import z `tasks_common` (tenké entry skripty).
4. **SKILL.md** přepsán: description trim na core EN triggery, capture = jediný `exec skills/detach/scripts/create-task.py …`, confirm jako EN instrukce (ne český natvrdo template), list/read triggery EN-only, cesty workspace-relativní, „respond in user's language" sjednoceno do jedné Rules sekce.
5. **`tests/`** (nové, pytest + conftest dle remind) — 34 testů čisté logiky.
6. **`systemd/tasks-daemon.service`** — doplněn `Environment=PATH=%h/.local/bin:/usr/bin:/bin` (repo bylo zastaralé, server ho měl → drift fix dle „server je zdroj pravdy").

**Co fungovalo a proč:** Ověřeno CWD chování v upstreamu (`shell.py:148` `working_dir=ctx.workspace`, `:370` `cwd = working_dir or workspace_root`) → `exec` běží z **workspace rootu**, ne ze skill dir; proto stávající home cesty nebyly bug a relativizace na `scripts/…` by skill rozbila. Zvoleny workspace-relativní `skills/detach/scripts/…`. Před nasazením ověřena shoda serveru s baseline session (žádný autonomní drift). Nasazeno `rsync -av` (bez `tests/`+`__pycache__`), vlastník `nanobot:nanobot`, `+x` obnoveno na entry skriptech (rsync je přinesl jako 644). Smoke test na serveru pod reálným uv: `list-tasks.py` čte/renderuje, `create-task.py --help` postaví venv + import OK, `tasks-daemon.py` s prázdným inboxem naběhne (nanobot-ai venv + `tasks_common` import, exit=0, žádný task nespuštěn). Lokálně 34 pytest zelených.

**Jak vrátit zpět:** `git revert` skill commitu + `rsync` starých verzí; nové soubory (`tasks_common.py`, `create-task.py`) na serveru smazat. systemd `Environment=PATH` na serveru ponechat (byl tam před touto změnou).

**Co zbývá:** Plný live e2e (create → daemon → agent → Telegram → done/) — posílá skutečnou Telegram notifikaci a spustí agenta, takže až na výzvu uživatele.

---

## 2026-06-02 19:02 — Context window presetů: zvednut z defaultních 65k na limit modelů

**Cíl:** Uživatel se ptal proč má nanobot kontext jen 65k. Zjistit příčinu a zvednout na reálné limity modelů.

**Co jsem zkusil / co fungovalo a proč:** Příčina = nanobot má hardcoded default `context_window_tokens = 65_536` (upstream `nanobot/config/schema.py:101,124` — `ModelPresetConfig` i `AgentDefaults`). Žádný preset v serverovém `config.json` tuto hodnotu nepřepisoval (měly jen `provider` + `model`), takže každý model jel na 65k bez ohledu na schopnosti. Klíč v JSON: `contextWindowTokens` (Base má `alias_generator=to_camel`, `populate_by_name=True` → projde camelCase i snake_case, `schema.py:24`). Reálné limity ověřeny z ollama.com: kimi-k2.6 256k, qwen3.5 256k, nemotron-3-super 256k, minimax-m2.7 200k, glm-5.1 198k, deepseek-v4-flash 1M. Nastaveno per-preset (`contextWindowTokens`: kimi/qwen/nemotron 262144, minimax 204800, glm 196608 [bezpečně pod 198k], deepseek 1048576; openrouter kimi 262144) + `maxTokens` 16384 u všech (default byl jen 8192). Editováno in-place Python skriptem přes `ssh nanobot@`, záloha `config.json.bak-20260602-190206`. Vlastník zůstal `nanobot:nanobot`. **Bez restartu** — `modelPresets` se hot-reloadují (`_refresh_provider_snapshot()` před každým tahem, viz knowledge.md). Pozn.: `:cloud` modely hostí kontext Ollama cloud, takže `contextWindowTokens` reálně rozšíří budget, není to lokální `num_ctx` žeroucí RAM.

**Jak vrátit zpět:** `cp ~/.nanobot/config.json.bak-20260602-190206 ~/.nanobot/config.json` na serveru jako nanobot.

**Co zbývá:** Sledovat, zda u velmi dlouhých sessions neklesá kvalita / neroste latence u slabších modelů (viz odpověď na dotaz uživatele).

---

## 2026-06-02 19:50 — Develop kontext zpřístupněn serverovému agentovi (workspace/develop/)

**Cíl:** Dát nanobot agentovi na serveru přístup k tracking dokumentům (`knowledge.md`, `history.md`, `memory.md`), aby věděl, jak byla tahle instance rozšiřována a laděna, a mohl z toho těžit.

**Co jsem zkusil / co fungovalo a proč:** Bootstrap soubory jsou hardcoded (`BOOTSTRAP_FILES` v `nanobot/agent/context.py:25`), takže vlastní auto-loadovaný soubor přidat nelze — odkaz musí být reference v existujícím bootstrap souboru (precedent: `keep.md` ref v `USER.md`). Soubory v `develop/` nejsou v žádné auto-load cestě ani je nekonzumuje Dream → bezpečné, neplýtvají context window, čtou se on-demand. Postup: (1) `rsync` tří tracking souborů do `~/.nanobot/workspace/develop/` (adresář už existoval, prázdný); (2) vytvořen `develop/README.md` (česky) vysvětlující, co to je a jak to používat, vč. „ne upstream kód, do toho nezasahujeme"; (3) do `AGENTS.md` připojena krátká sekce „## How you were extended & tuned" (1 věta + odkaz na README) — nejdřív re-fetch serverové verze (1155 B, žádný drift), pak append a upload zpět; (4) pravidlo o průběžné synchronizaci do `memory.md`. Vše owner `nanobot:nanobot`, bez restartu (workspace soubory se čtou každý tah fresh). Rozhodnutí uživatele: synchronizovat develop/ po každé změně tracking souborů (ne jednorázová kopie).

**Jak vrátit zpět:** Na serveru `rm -rf ~/.nanobot/workspace/develop/*` a z `AGENTS.md` smazat sekci „## How you were extended & tuned" (poslední 4 řádky). Lokálně revert commitu pravidla v `memory.md`.

**Co zbývá:** Volitelný funkční test v chatu s agentem (zeptat se „co je develop/") — na výzvu uživatele.

---

## 2026-06-03 06:26 — MiniLoop: realizace .NET PoC `/remind add` parseru

**Cíl:** Naimplementovat v nejmenší možné míře .NET PoC ze [plans/remind-standalone-bot-dotnet.md](plans/remind-standalone-bot-dotnet.md) — jediná LLM cesta `add` (text → JSON dle `reminder.yaml`). Dvě věci: zadávací smyčka (REPL, hned odpoví) a testovací běh, který projede všechny páry z `remind-prompt-examples.txt`, porovná s očekávaným JSON a protočí to nad seznamem modelů + změří wall-clock a tokeny. Zdroje do `src/MiniLoop/`.

**Co jsem zkusil / co fungovalo a proč:** .NET 10 console app, prompt-only přístup (ne `GetResponseAsync<T>` — schéma z `remind-prompt.md` má optional/nested pole, do striktního typu se mapují krkolomně a slabé modely by selhaly). Jeden `IChatClient` (`Microsoft.Extensions.AI` nad `OpenAI` SDK) s konfigurovatelným `Endpoint` → swap providera = jen jiný řádek configu. Soubory: `Config.cs` (providers + models + cesty k promptu/příkladům, klíče v configu), `PromptSource.cs` (extrahuje ` ```text ` blok z `remind-prompt.md`, substituuje `{{NOW}}`; parsuje páry z examples), `ReminderParser.cs` (volání + `Stopwatch` + `UsageDetails`, extrakce JSON od prvního `{` po poslední `}`), `JsonCompare.cs` (sémantická rovnost — klíče objektu order-insensitive, pole order-sensitive, čísla podle hodnoty), `Program.cs` (routing `repl [model]` / `test`). Režim 1. argumentem, model 2. argumentem. NOW: repl = reálný Prague čas, test = fixní `2026-06-03T14:30:00 (Wednesday)`. Provideři: ollama `http://nvidia.hell:11434/v1` (kimi-k2.6:cloud, glm-5.1:cloud), openrouter (claude-haiku-4.5, gpt-5.4-nano, klíč zkopírován z `openrouter.key.txt` do `config.json`). `config.json` + `openrouter.key.txt` v `.gitignore`.

Build čistý (0 warnings). Repl smoke: kimi na „za 10 minut vyndat pizzu" → `{"text":"vyndat pizzu z trouby","at_times":[<teď+10min>]}` správně. Plný test (17 párů × 4 modely):

| Model | Úspěšnost | Wall median / avg | Tokeny in / out |
|---|---|---|---|
| kimi-k2.6 (ollama) | 17/17 | 5981 / 7327 ms | 21536 / 6698 |
| glm-5.1 (ollama) | 17/17 | 1279 / 1410 ms | 21118 / 2765 |
| claude-haiku-4.5 (openrouter) | 16/17 | 917 / 1200 ms | 23668 / 691 |
| gpt-5.4-nano (openrouter) | 17/17 | 1426 / 1621 ms | 20987 / 553 |

To jediné „FAIL" (haiku) je **false negative v testovacích datech**: model vrátil gramaticky správné `"zkontrolovat pečení"`, očekávané je `"pečeni"`. JsonCompare porovnává `text` přesně. Potvrzení teze PoC: ~1,2k input tokenů na `add` (vs ~28–32k přes nanobot agent loop), ~1–1,5 s wall-clock u rychlých modelů (vs ~10 s změřených u `/remind list`). Řádově sedí s odhady z `remind-standalone-bot.md`.

**Co zbývá:** Zdrojový kód v `src/MiniLoop/` zatím necommitnut (CLAUDE.md: commituj jen tracking soubory; src commit na výzvu uživatele). Vědomě mimo PoC: `reminder.yaml`/`list`/`delete`, Cronos validace, retry, structured-output schema. Případná oprava `pečeni`→`pečení` v examples (na rozhodnutí uživatele).

## 2026-06-03 — MiniLoop: paralelizace testu + nová sada modelů

**Cíl:** Testovací běh `test` jel striktně sekvenčně (`foreach` přes modely čekal na dokončení každého) — u pomalého modelu to trvalo moc dlouho. Uživatel: modely musí běžet souběžně; každý řádek výstupu musí nést značku modelu, pořadové číslo (`6/17`) a vlastní wall-clock (tokeny stačí jako součet per model). Souběžnost zvolena „jen modely" (příklady uvnitř modelu sekvenčně, šetrnější k provideru).

**Co jsem zkusil / co fungovalo a proč:** Změna jen v `Program.cs`. `RunTest` nahradil sekvenční `foreach` za `await Task.WhenAll(cfg.Models.Select(entry => RunModel(...)))`; blokovou hlavičku `## {model}` zrušil (výstup se prolíná) a per-model souhrn sebral do závěrečné tabulky `## Souhrn` po `WhenAll`. `RunModel` teď vrací `record ModelResult` (název, provider, passed, count, wallMs, tokeny, SkipReason) místo tisku souhrnu uvnitř; každý dokončený příklad vypíše atomický blok `[model] N/17 ok|FAIL|ERR  <ms> ms  <request>`. Souběžné tasky píšou do stejné konzole → víceřádkový FAIL/ERR blok by se prokládal, proto top-level `object consoleLock` + `lock` kolem `Console.WriteLine(block)` (per-volání je `Console` thread-safe, víceřádkový blok ne). Build čistý. Ověřeno: řádky 6 modelů se reálně prolínají, FAIL bloky drží pohromadě, pořadí 1→17 roste (sekvenční foreach uvnitř modelu), na konci souhrnná tabulka.

Plný paralelní běh 6 modelů (NOW fixní `2026-06-03T14:30:00`):

| Model | Úspěšnost | Wall median / avg | Tokeny in / out |
|---|---|---|---|
| glm-5.1 (ollama) | 17/17 | 3240 / 5048 ms | 21118 / 3029 |
| deepseek-v4-flash (ollama) | 17/17 | 7005 / 8848 ms | 21654 / 3480 |
| qwen3.5 (ollama) | 15/17 | 10852 / 16845 ms | 22871 / 22671 |
| gemma4-31b (ollama) | 15/17 | 752 / 815 ms | 23571 / 600 |
| claude-haiku-4.5 (openrouter) | 16/17 | 894 / 988 ms | 23668 / 691 |
| gpt-5.4-nano (openrouter) | 17/17 | 1400 / 2615 ms | 20987 / 553 |

**Klíčové zjištění (proti očekávání z plánu):** předpoklad „per-model latence se paralelizací nezmění" **neplatí**. Všechny 4 ollama `:cloud` modely sdílí jeden backend → při souběhu si konkurují a latence se nafoukne (glm median sekvenčně ~1,3 s → paralelně 3,2 s; jednotlivá qwen volání až 59 s). OpenRouter (haiku, gpt-nano) na vlastní infře skoro netknutý. Takže paralelní `test` = rychlý celkový průchod + spolehlivý pass/fail, ale per-model latenci u sdíleného providera nadhodnocuje; čistou latenci měřit izolovaně. Reasoning modely (qwen out=22671 tok ≈ jako in!, deepseek) jsou pomalé bez ohledu na kontenci. FAILy: gemma „příští pondělí" → `2026-06-09` (úterý) místo `06-08` = skutečná chyba data; zbytek false negatives (`pečení`/`pečeni`, `jít na trénink`/`trénink`, `mít poradu`/`porada`).

**Co zbývá:** Zdroje `src/MiniLoop/` (vč. této změny) stále necommitnuté — čeká na výslovnou výzvu uživatele. Souhrn čísel viz knowledge.md „MiniLoop".

## 2026-06-03 — MiniLoop: strop souběžnosti per provider + qwen→minimax

**Cíl:** Po paralelizaci se ollama modely při souběhu drasticky zpomalily (qwen volání až 59 s). Uživatel doplnil příčinu: jeho ollama předplatné povoluje **max 3 paralelní dotazy** ([ollama.com/pricing](https://ollama.com/pricing)) — se 4 ollama modely naráz 4. dotaz přeteče kvótu a čeká ve frontě, což se počítá do wall-clocku. Zároveň zahodit qwen3.5 (pomalý reasoning, out=22671 tok) a přidat minimax-m2.7:cloud.

**Co jsem zkusil / co fungovalo a proč:** Nejdřív jsem mylně tvrdil „víc spojení nepomůže, je to sdílený výpočet" — uživatel upřesnil, že jde o kvótu paralelních dotazů. To je správná diagnóza. Řešení: per-provider strop souběžnosti přes `SemaphoreSlim`. `Provider` record rozšířen o `int? MaxConcurrency` (Config.cs); `RunTest` z providerů se stropem postaví slovník semaforů a předá ho do `RunModel`. Nový helper `Parse(parser, gate, request)` získá slot `await gate.WaitAsync()` **před** voláním (tedy mimo stopky v `ParseAsync`, které obalují jen HTTP call) a uvolní ve `finally` → čekání na slot se nezapočte do měřené latence. config.example.json: ollama `maxConcurrency:3`, qwen→minimax. Reálný config.json (gitignored): uživatel ho mezitím sám protrimoval na 4 modely; po dohodě přidán jen minimax (→ 5 modelů: glm, deepseek, minimax, haiku, gpt-nano) + `maxConcurrency:3`. Build čistý.

Běh 5 modelů s gate=3:

| Model | Úspěšnost | Wall median / avg | Tokeny in / out |
|---|---|---|---|
| glm-5.1 (ollama) | 17/17 | 1690 / 1927 ms | 21118 / 2896 |
| deepseek-v4-flash (ollama) | 17/17 | 4894 / 6118 ms | 21654 / 3487 |
| minimax-m2.7 (ollama) | 17/17 | 4815 / 4604 ms | 21969 / 2317 |
| claude-haiku-4.5 (openrouter) | 16/17 | 1064 / 1135 ms | 23668 / 691 |
| gpt-5.4-nano (openrouter) | 17/17 | 3034 / 4003 ms | 20987 / 553 |

**Co fungovalo:** glm median spadl z 3240 ms (kontence) na 1690 ms, žádné 20–60 s odlehlé hodnoty. minimax 17/17 (čistší než qwen). Pozn.: se 3 ollama modely strop (3) zatím nepřekáží — funguje jako pojistka, kdyby přibyl 4. ollama model. Gotcha: `dotnet run --project src/MiniLoop` z repo rootu nenajde `config.json` (relativní k cwd) → spouštět s `MINILOOP_CONFIG=src/MiniLoop/config.json` nebo z adresáře projektu.

**Co zbývá:** Zdroje `src/MiniLoop/` stále necommitnuté — čeká na výslovnou výzvu. config.example.json má pro ilustraci 6 modelů (vč. gemma4-31b), reálný config.json 5 (bez gemmy) — záměrný rozdíl (template vs. pracovní sada).

## 2026-06-03 — MiniLoop: test levných/OSS modelů z OpenRouteru

**Cíl:** Uživatel chtěl projít nabídku ollama cloud ([ollama.com/search?c=cloud](https://ollama.com/search?c=cloud)) + levné/OSS z OpenRouteru a vybrat, co stojí za vyzkoušení. Pak přidat vybrané do configu a pustit test jen na ně (ne přetáčet už známé). Mezitím uživatel sám upravil `Program.cs`: `test` teď bere výčet modelů nebo `all` (`test <model...> | test all`) — díky tomu jdou nové modely testovat samostatně.

**Co jsem zkusil / co fungovalo a proč:** Z OpenRouteru (katalog přes `curl https://openrouter.ai/api/v1/models`, filtr na OSS klíče + cena) vybráno 5 levných instruct (ne-thinking) modelů a přidáno do config.json (provider openrouter): `mistralai/mistral-small-3.2-24b-instruct`, `qwen/qwen3-30b-a3b-instruct-2507`, `google/gemma-3-27b-it`, `z-ai/glm-4-32b`, `openai/gpt-oss-120b`. Spuštěno `test mistral-small-3.2 qwen3-30b-a3b gemma-3-27b glm-4-32b gpt-oss-120b`.

| Model | Cena $/M | Úspěšnost | Wall median / avg | out tok |
|---|---|---|---|---|
| mistral-small-3.2 | 0.075/0.20 | 17/17 | 934 / 1050 ms | 610 |
| gemma-3-27b | 0.08/0.16 | 17/17 | 1413 / 1611 ms | 608 |
| glm-4-32b | 0.10/0.10 | 16/17* | 1905 / 2072 ms | 519 |
| qwen3-30b-a3b | 0.043/0.17 | 16/17* | 1991 / 1866 ms | 588 |
| gpt-oss-120b | levný | 16/17 | 7238 / 12164 ms | 3769 |

\* false negative (slovosled `se protáhnout`/`protáhnout se`; `pečení`/`pečeni`). gpt-oss got = expected (rozvrh sedí, JsonCompare škobrtl na formátu). Žádná skutečná chyba.

**Co fungovalo a proč:** `mistral-small-3.2` je nejlepší poměr ze všech dosud měřených (934 ms median, rychlejší než glm-5.1 1690 ms i haiku 1064 ms; 17/17; out 610 tok; cena pakatel) — potvrzená evropská/česká stopa Mistralu. `gemma-3-27b` těsně za ním. `gpt-oss-120b` jediný propadák — reasoning → 7 s a 6× víc out tokenů. Silné potvrzení teze o thinkingu: `qwen3-30b-a3b-instruct` 1991 ms vs cloud `qwen3.5` (thinking) 10852 ms + out=22671 — past byl režim thinking, ne qwen rodina.

**Co zbývá:** Zvážit prořezání gpt-oss-120b z config.json (propadák). Ollama cloud tipy k případnému pullnutí na nvidia.hell (netestováno): `gemini-3-flash-preview`, `gemma4:26b`, `nemotron-3-nano:30b`; už stažené netestované `nemotron-3-super`, `deepseek-v4-pro`. Souhrn čísel: knowledge.md „Levné / OSS modely z OpenRouteru".

## 2026-06-03 — MiniLoop: test ministral-3 a nemotron-3-nano přes ollama

**Cíl:** Uživatel chtěl vyzkoušet ještě `ministral-3` a `nemotron-3-nano` přes ollama (mezitím sám prořezal config.json na 5 modelů + nastavil mistral-small-3.2 jako interactive).

**Co jsem zkusil / co fungovalo a proč:** Oba mají `:cloud` variantu → žádný GB download, jen registrace pointeru na ollama cloud přes `curl POST http://nvidia.hell:11434/api/pull {"model":"…","stream":false}` → `{"status":"success"}`. Vybráno `ministral-3:8b-cloud` (8b = „latest", 3b by na CZ byl slabý) a `nemotron-3-nano:30b-cloud`. Přidáno do config.json (provider ollama), spuštěno `test ministral-3-8b nemotron-3-nano-30b`. **Vrácení zpět:** `curl POST /api/delete {"model":"…"}` nebo `ollama rm` na nvidia.hell.

| Model | Úspěšnost | Wall median / avg | out tok |
|---|---|---|---|
| ministral-3:8b-cloud | 15/17 | 1043 / 1169 ms | 653 |
| nemotron-3-nano:30b-cloud | 16/17 | 2015 / 2277 ms | 7805 |

**Výsledek — oba zavrženy, nepřekonaly mistral-small-3.2:** `ministral-3-8b` udělal skutečnou chybu dne v týdnu (`každý pátek` → cron `* * 6` sobota místo `* * 5`) — u připomínek vážné, na 8b znát; navíc není ani rychlejší než mistral-small (1043 vs 934 ms). `nemotron-3-nano-30b` má reasoning sklony (out=7805 tok ≈ 12× mistral), 2× pomalejší; jediný FAIL = rozsekání `1,3,5` na tři cron výrazy (rozvrh ekvivalentní, formát ne). Poznatek: pod ~24b instruct klesá spolehlivost cronu, malé „nano" buď chybují, nebo zbytečně reasonují.

**Co zbývá:** mistral-small-3.2 zůstává vítěz. ministral/nemotron-nano v config.json ponechány pro případné srovnání (lze prořezat). Souhrn: knowledge.md „Malé ollama modely".

## 2026-06-06 11:01 — Skill `/keep`: ukládání *why*, ne jen *what*

**Cíl:** Uživatel zaznamenal, že Claude memory.md vzor ukládá u feedback/project paměti i *why* (`**Why:**` / `**How to apply:**`), a ptal se, zda by `/keep` neměl dělat totéž. Cílem bylo minimalisticky upravit prompt skillu, aby why ukládal — ale jen kde to dává smysl.

**Co jsem zkusil / co fungovalo a proč:**

- Analýza: Claude vzor přidává why **jen podle typu** — feedback/project ano, reference/fakt ne. `/keep` je ekvivalent reference/fakt vrstvy (terse, auto-load každý tah přes USER.md referenci), why-vrstvou nanobotu je Dream → MEMORY.md. Bloat why ke každému řádku by zdvojnásobil trvalý token cost.
- Potvrzeno článkem Nick Babich „MEMORY.md for Claude Code projects" (UX Planet, 2026-05-28): bod #3 „Explain WHY, Not Just WHAT" + #5 „Record Failures and Dead Ends" — ale jeho příklad why (`Switched to Redis because…`) je **rozhodnutí**, ne fakt → potvrzuje úzkou variantu.
- Iterace promptu (3 kola): (1) přidán why-řádek do kroku 2 + mantinel do Rules, s 2 few-shot příklady (decision, dead-end). (2) Po dotazu na model: lokální modely zavrženy, reálně běží Ollama Cloud (kimi-k2.6, deepseek-v3.2, qwen, glm-5.1) + OpenRouter (sonnet/haiku/gemini) — silné modely → fakt-vs-rozhodnutí zvládnou zero-shot → **oba příklady odebrány**. (3) Přidáno: pokud je vstup rozhodnutí/dead-end **bez důvodu**, model se **jednou doptá** na why (decline/self-evident → ulož bez něj).
- Finální změny v `skills/keep/SKILL.md`: krok 2 Write protokolu (3 pravidla pro why) + 1 mantinel v Rules. Žádná změna formátu souboru (pořád 1 řádek = 1 záznam), why jen u rozhodnutí/preferencí/dead-endů.

**Nasazení:** ověřeno server == lokál HEAD před přepisem (žádná Dream úprava nezahozena) → `rsync -av skills/keep/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/keep/`. Vlastník `nanobot:nanobot`, příklady ověřeně pryč. Skilly se čtou každý tah bez restartu.

**Co zbývá:** Sledovat, jestli silné modely doptávání na why nepřehánějí (riziko nagování u hraničních „rozhodnutí"). Pokud ano → zúžit trigger nebo doplnit 1 negativní příklad.

## 2026-06-06 11:16 — Nový skill `python` (coding conventions)

**Cíl:** Dát nanobotovi pravidla pro práci s Pythonem — uv tool, type hints, linter/formatter, PEP + clean code.

**Co jsem zkusil / udělal:**

- Založen `skills/python/SKILL.md`. Tělo vychází z `.claude/rules/python.md` (použito celé) + doplněna sekce **Tooling** (uv, `ruff format`, `ruff check --fix`, definice „done").
- Z `.claude/rules/clean-code.md` přidány jen body zvyšující čitelnost/strukturu: boolean flag args, CQS, param count 0–3, fail fast / guard clauses, max zanoření, magic numbers → konstanty. Designové body (composition, DI, immutability) vynechány.
- Na žádost uživatele vyházeny věci, které modely dělají samy: casing (snake_case/PascalCase), 4-mezery, f-stringy, řazení importů. Naming + Imports sekce zrušeny, Style zúžen na line-length 120.
- `description` schválně vágní („Use for anything involving Python code") — ať se skill aktivuje skoro vždy.

**Co fungovalo a proč:** `rsync -av skills/python/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/python/`. Vlastník `nanobot:nanobot` ověřen. Skilly se čtou každý tah bez restartu.

**Co zbývá:** Sledovat, jestli vágní description nezpůsobuje načítání i mimo Python kontext (přijatelné — „lepší načíst zbytečně než minout").

## 2026-06-06 11:20 — Nový skill `bash` (shell conventions)

**Cíl:** Stejně jako `python` — převést `.claude/rules/bash.md` na nanobotí skill.

**Co jsem udělal:**

- Založen `skills/bash/SKILL.md` z `.claude/rules/bash.md`.
- Vyházeno: Naming sekce (casing — modely trefují samy), `[[ ]]` vs `[ ]` (default), zmínka o `check-bash.sh` hooku (hook tohoto repa, na serveru irelevantní), `paths:` frontmatter (Claude Code feature).
- Ponecháno to, kde modely v bashi reálně chybují / projektový standard: strict mode, double-quoting, local/readonly + návrat přes stdout, arrays vs IFS, `command -v` místo `which`, stderr, mktemp+trap, script_dir idiom, shellcheck, hook exit kódy 0/2.
- `description` vágní, ať se aktivuje široce.

**Co fungovalo:** `rsync -av skills/bash/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/bash/`. Vlastník `nanobot:nanobot` ověřen.

**Co zbývá:** nic.

## 2026-06-07 — Měření rychlosti glm-5.1 vs minimax-m3 (Ollama nativní streaming)

**Cíl:** Tvrdá data na dotaz „je minimax línej?" — porovnat time-to-first-token, rychlost generování a celkovou dobu odpovědi mezi `glm-5.1:cloud` a `minimax-m3:cloud` na reálné úloze typu `/remind list`.

**Co jsem zkusil:**

1. **Journal nestačí.** `journalctl --user -u nanobot` loguje jen `Processing message → Tool call → Response` (časové značky). **Žádné počty tokenů, žádné tok/s, žádný TTFT.** Wall-clock z journalu navíc míchá běh nástrojů (`uv run` cold-start ~2–7 s) a víc kol tool-callů → na rychlost modelu nepoužitelné. (Z journalu jen kontext: na `minimax-m3` přepnuto poprvé 2026-06-05, dnes 09:03; jeden reálný `/remind list` pod m3 trval wall 37 s včetně 2 tool-callů.)
2. **Ollama `:cloud` nativní timing fields jsou `None`** (`eval_duration`, `prompt_eval_duration`, `load_duration`) — výpočet jede přes Ollamin cloud, lokální server na `nvidia.hell` je nezná. Vrací jen `eval_count` (out tok) + `total_duration`.
3. **Řešení = streaming `/api/chat`.** Skript `/tmp/bench_ollama.py` (na serveru): TTFT = čas prvního content chunku, generace = `eval_count / (total − TTFT)`, identický prompt (`/remind list` formátování 8 položek do češtiny), 3 běhy/model.

**Naměřeno (per běh):**

| Model | TTFT | Total wall | Out tok | Generace* |
|---|---|---|---|---|
| glm-5.1 | 5,50 / 7,78 / 5,93 s | 6,43 / 8,83 / 7,15 s | 1209 / 1729 / 1511 | ~1290 / 1650 / 1240 tok/s |
| minimax-m3 | 5,98 / 7,25 / 6,75 s | 9,76 / 11,36 / 11,28 s | 457 / 419 / 428 | ~121 / 102 / 95 tok/s |

\* `eval_count / (total − TTFT)`.

**Co fungovalo a proč:**

- **TTFT srovnatelný (~6–7 s u obou)** — minimax neprohrává startem, oba mají podobný cloud cold start.
- **Celková doba: minimax ~50 % delší** (medián ~10,8 s vs ~7,5 s glm), a to **přestože generuje 3–4× MÉNĚ tokenů** (~430 vs ~1480). To je hlavní důkaz „lenosti" minimaxu.
- **Generace tok/s:** minimax **~95–120 tok/s je čisté číslo** (streamuje token po tokenu). GLM hodnotu „1300 tok/s" NEbrat doslovně — je to **artefakt cloud bufferu** (glm flushne odpověď v dávce po TTFT). Robustní srovnatelná metrika je **end-to-end průtok = out/total: glm ~198 tok/s vs minimax ~40 tok/s → glm ~5×.**

**Závěr:** Intuice potvrzena tvrdě — **minimax-m3 je výrazně línější**: pomalý decode (~100 tok/s) + delší celková doba i u kratšího výstupu. Na interaktivní úlohy je glm-5.1 jednoznačně svižnější. Pozn.: glm je upovídaný (1200–1700 tok vs ~430), ale i tak hotový dřív.

**Jak vrátit zpět:** nic se na serveru nemĕnilo (jen read-only měření + dočasný `/tmp/bench_ollama.py`).

**Co zbývá:** nic.

---

## 2026-06-07 09:54 — Znalostní báze modelů pro nanobot agenta (workspace/knowledge/)

**Cíl:** Dát nanobot agentovi na serveru znalostní bázi o modelech, ze které může těžit při dotazech typu „jaký model na kódování / na zpracování fotky" — fakta a naměřené hodnoty, žádná hotová doporučení (volba je na agentovi).

**Co jsem zkusil:**

- Vytáhl reálné presety ze serverového `config.json` → `model_presets` (7 presetů: glm-5.1 default, minimax-m3, kimi-k2.6 na ollama; sonnet, haiku na openrouter; gemini-flash na gemini; gemini-flash-lite na openrouter). Liší se od lokálního `models.md`, který řešil jen 3 Ollama Cloud modely.
- Konsolidoval do `knowledge/models.md` (CZ, facts-only): tabulka presetů (provider, model id, kontext, multimodalita), přímé měření rychlosti na Ollama Cloud (glm ~198 tok/s vs m3 ~40 tok/s, m3 o ~50 % pomalejší), AA profil verbozity, rozdíly ve schopnostech (multimodál, HLE, kódování, dlouhý kontext), caveaty (vendor vs produkce, prompt caching jen openrouter/anthropic/bedrock, ollama kvóta 3 paralelní), kontextová okna, appendix s MiniLoop měřeními (jasně označeno jako jiný kontext, ne agent presety).
- `knowledge/README.md` jako rozcestník (vzor podle `develop/README.md`).
- Napojení: přidána sekce `## Knowledge base` do `AGENTS.md` (bootstrap, čte se každý tah) odkazující na `knowledge/README.md` „read on demand" — stejný vzor jako existující odkaz na `develop/README.md`.
- Kanonická kopie v repu `knowledge/`; nasazeno `rsync`em do `~/.nanobot/workspace/knowledge/`. AGENTS.md staženo, upraveno lokálně, posláno zpět.

**Co fungovalo a proč:** Vlastník na serveru `nanobot:nanobot`, ověřeno. `knowledge/` se čte bez restartu (bootstrap soubory i workspace soubory čte agent při tahu). AGENTS.md napojení znamená, že agent o bázi ví a sáhne tam on-demand.

**Jak vrátit zpět:** `ssh nanobot@nanobot.hell 'rm -rf /home/nanobot/.nanobot/workspace/knowledge'` + smazat sekci `## Knowledge base` z `~/.nanobot/workspace/AGENTS.md`.

**Co zbývá:** nic. Případně až nanobot bázi reálně použije, ověřit, že odpovídá rozumně.

**Oprava (09:5x):** Sekce `## Knowledge base` v `AGENTS.md` byla moc konkrétní (vyjmenovávala modely). Zobecněna — `knowledge/` je obecná báze, modely uvedeny jen jako příklad; konkrétní výčet zůstává v `knowledge/README.md` (read on demand).

---

## 2026-06-07 13:14 — Detach: volitelný výběr modelu pro background task

**Cíl:** Umožnit, aby detached task běžel na explicitně zvoleném modelu (jiném než default) — background = latence nebolí, vyplatí se silnější model. Když se model neuvede → default (zpětně kompatibilní).

**Co jsem zkusil:**

- Ověřil v upstreamu (`tmp/nanobot-upstream`), že `Nanobot.run()` model override nepřijímá, ale `AgentLoop.set_model_preset(name)` existuje (přesně to dělá `/model <preset>` v chatu) a hodí `KeyError` na neznámý preset.
- Zamítl variantu „zdědit aktivní model na kanálu": `/model` přepnutí je in-memory, globální (ne per-kanál), neperzistuje a daemon (samostatný proces) ho nevidí; šlo by jen patchem upstream `_build_runtime_context` → fork balíčku. Příliš drahé. Rozhodnutí s uživatelem: **explicitně v požadavku, jinak default**; resolve názvu **fuzzy proti `config.json`**.
- `tasks_common.py`: `load_preset_names()` (čte `modelPresets` i `model_presets` — server má na disku snake_case), `resolve_preset(token, names)` (exact CI → unikátní substring → `KeyError` not found / ambiguous), `build_task_content(..., model=…)` přidá frontmatter řádek `model:` jen když je zadán. `format_result` ukáže `model:` v meta řádku.
- `create-task.py`: `--model` (optional) → resolve při captue, na `KeyError` vypíše hlášku na stderr a `return 1` (fail-fast, nic nezapíše).
- `tasks-daemon.py`: `preset = fm.get("model")`, `run_agent(..., preset)` → `bot._loop.set_model_preset(preset)` před `run()`. Log `START … preset=<x|default>`.
- Dokumentace: `SKILL.md` (krok „Optional model" + failure handling pro unknown/ambiguous), `architecture.md` (frontmatter `model:`, resolve při captue, daemon switch). Testy: +9 v `tests/test_tasks_common.py` (43 passed).
- Nasazeno `rsync`em na server, vlastník `nanobot:nanobot` ověřen.

**Co fungovalo a proč:**

- Resolve proti reálnému serverovému configu: 7 presetů (`gemini-flash, gemini-flash-lite, glm, haiku, kimi, minimax, sonnet`), `kimi→kimi`, `flash-lite→gemini-flash-lite`, `gemini→ambiguous`, `nonsense→not found`.
- Fail-fast: `create-task.py --model nosuchmodel` → exit 1, hláška se seznamem, `inbox/` beze změny.
- **E2e:** task `model-test-kimi` (`--model kimi`, goal „reply PONG") doběhl za 3 s, log `START … preset=kimi`, výsledek `PONG`, `read-task` ukázal `model: kimi`. Tím ověřeno, že `bot._loop.set_model_preset` funguje i s **nainstalovaným** balíčkem nanobota (ne jen v upstream klonu). Testovací task zarchivován.
- Gotcha potvrzen: serverový `config.json` má top-level klíč **`model_presets` (snake_case)**, ne camelCase; `agents.defaults.modelPreset` je naopak camelCase. Proto `load_preset_names` čte oba tvary — nebýt toho, vracelo by prázdno a každý `--model` by failoval.

**Jak vrátit zpět:** přenasadit předchozí verzi skillu ze staré git revize: `git checkout <rev> -- skills/detach` + `rsync -av --exclude __pycache__ skills/detach/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/detach/`. Bez `--model` se chování nemění, takže rollback není urgentní.

**Co zbývá:** Návrh do `decisions.md` (load-bearing) — čeká na souhlas autora. Zvážit zvednutí 15-min timeoutu u explicitně zvoleného „heavy" modelu (M3/Kimi jsou pomalé/verbózní) — samostatné rozhodnutí.

---

## 2026-06-07 13:xx — Detach: zvednut timeout 15 → 45 min

**Cíl:** Background tasky na silnějších modelech (M3/Kimi — na Ollama Cloud pomalé/verbózní) můžou u hlubokého researche přerůst 15 min. Uživatel nemá v příkazu řešit timeout, tak zvednout globální strop.

**Co jsem zkusil:**

- Ověřil, že systemd `tasks-daemon.service` nemá vlastní start-timeout: `Type=oneshot` → `TimeoutStartUSec=infinity`, `RuntimeMaxUSec=infinity` (`systemctl --user show`). Jediný strop je tedy Python `asyncio.wait_for(TIMEOUT_SECONDS)`.
- `TIMEOUT_SECONDS = 15*60 → 45*60` v `tasks-daemon.py`; sjednoceny zmínky „15 min" v docstringu, `architecture.md`, `knowledge.md`.
- Nasazeno `rsync`em, vlastník `nanobot:nanobot`, konstanta na serveru ověřena. Bez restartu (oneshot = nový proces na každý běh).

**Co fungovalo a proč:** Timeout je čistě pojistka proti zaseknutému běhu — reálný task doběhne dřív; delší strop nic nestojí kromě toho, že zaseknutý task déle drží frontu (u single-user low-volume OK). 45 min dává headroom pro deep research na silném modelu.

**Jak vrátit zpět:** v `tasks-daemon.py` zpět na `15 * 60` + rsync.

**Co zbývá:** nic. Sledovat, zda 45 min stačí / nepřehání.

---

## 2026-06-07 17:51 — Měření rychlosti glm-5.1 vs minimax-m2.7 (Ollama nativní streaming)

**Cíl:** Na dotaz „jak je m2.7 rychlý oproti glm-5.1" dát tvrdá apples-to-apples data — m2.7 zvažovaný jako náhrada za m3 (BLOCKED, viz knowledge.md). Předchozí streaming benchmark (téhož dne) měřil jen m3, ne m2.7.

**Co jsem zkusil:**

1. `/api/tags` na `nvidia.hell` ukázal jen `minimax-m3:cloud` (m2.7 z katalogu zmizel — Ollama Cloud ho nahradila m3). `POST /api/pull {"model":"minimax-m2.7:cloud"}` ale vrátil `{"status":"success"}` → cloud pointer **jde dotáhnout**, jen není v defaultním seznamu.
2. Streaming `/api/chat` benchmark (`/tmp/bench_ollama2.py`), identický `/remind list` prompt (8 položek do češtiny), **5 kol prokládaně** (každé kolo glm pak m2.7, ať sdílí stejnou zátěž cloudu) + mediány. TTFT = 1. content chunk; e2e = `eval_count / total`.

**Naměřeno (mediány, 5 kol):**

| Model | TTFT | Total wall | Out tok | e2e (out/total) |
|---|---|---|---|---|
| glm-5.1 | 15,4 s | 18,3 s | 1558 | **~91 tok/s** |
| minimax-m2.7 | 9,2 s | 11,3 s | 351 | **~28 tok/s** |

**Co fungovalo a proč:**

- Absolutní čísla nafouklá oproti rannímu m3 měření (glm TTFT 15 s vs ~6 s ráno) — cloud byl vytížený. Proto bráno jen jako **poměr v rámci běhu**, prokládání kol drží srovnatelnost.
- **Decode m2.7 ~3× pomalejší než glm** (~28 vs ~91 tok/s e2e) — dokonce **horší než m3** (~40 tok/s). Líný decode je rys celé MiniMax řady, m2.7 to nezlepšil.
- **m2.7 doběhne dřív ve wall-clocku** (11 vs 18 s) **jen díky terseness** — vygeneroval ~4,5× méně tokenů (351 vs 1558). glm je upovídaný, ale per-token mnohem rychlejší. Konzistentní s MiniLoop 2026-06-03 (m2.7 4815 ms vs glm 1690 ms, tam podobné token county → glm vyhrál decodem).

**Závěr:** m2.7 není pro agenta rychlostní výhra — pomalý decode bolí u delších výstupů (tool args, kód). Wall-clock výhoda platí jen pro krátké odpovědi. Pro background deep-research drž glm-5.1 / Kimi.

**Jak vrátit zpět:** read-only měření + dočasný `/tmp/bench_ollama2.py`. Na ollamě přibyl pointer `minimax-m2.7:cloud` (`ollama rm minimax-m2.7:cloud` na `nvidia.hell` ho odebere, pokud nemá zůstat).

**Co zbývá:** ověřit m2.7 v reálném detach běhu (jestli neskončí ve smyčce jako m3).

---

## 2026-06-07 18:26 — Detach `list`: odrážkový výpis místo markdown tabulky + reconciliace driftu

**Cíl:** `/detach list` na minimax-m2.7 rozsypal formát — Running se vyrenderoval jako tabulka, Done/Failed jako syrové `| … |` roury (na GLM OK). Příčina: výstup relayuje LLM token po tokenu a markdown tabulka má dálkovou závislost (hlavička + `|---|`); slabý model u 2./3. sekce hlavičku zahodí. Cíl = formát robustní vůči LLM relay.

**Co jsem zkusil:**

- `render_table` → `render_list` v `tasks_common.py`: dvouřádková odrážka na úkol (slug · čas · stáří + odsazený popis), žádná tabulková gramatika. Popis se vynechá, když chybí `# Goal`. JSON zamítnut — jen posouvá křehkost na model, který ho převádí pro člověka.
- `list-tasks.py` přepnut na `render_list`; `SKILL.md` `list` zpřísněn na „output verbatim, do not convert to a table".
- Testy přepsány (`test_render_list_*`, +`omits_goal_line_when_empty`) → **57 passed**. Lokální render proti dočasnému workspace ověřil starý i nový timestamp, soubor bez Goalu i neparsovatelný filename.
- **Drift na serveru** (uživatel varoval): nanobot si sám opravil `NameError` v `tasks-daemon.py` — repo volá `LOG.parent.mkdir` na ř. 152, ale `LOG` nebyl importován (zaneseno minulou session). Server záplatoval lokálním `from tasks_common import LOG as _LOG`. Dotaženo do repa čistší formou — `LOG` přidán do top-level importu (ř. 37), což serverový workaround subsumuje.
- Deploy `rsync`em, vlastník `nanobot:nanobot`, deployed `list-tasks.py` ověřen proti reálným serverovým taskům (odrážky, truncation `…` na 80 zn., žádné `|`).

**Co fungovalo a proč:** Odrážkový seznam přežije relay, protože každý `- …` řádek stojí sám — není hlavička, jejíž ztráta rozbije vše pod ní. Je to zároveň drátový i zobrazovací formát, takže odpadá transformační krok, kde slabý model selhával.

**Jak vrátit zpět:** `git revert` commitu se skill změnami + `rsync` repa zpět na server (vrátí i `render_table`). Pozn.: vrácení daemon importu by znovu zavedlo `NameError` — opravu importu `LOG` ponechat.

**Co zbývá:** end-to-end potvrzení v chatu na minimax-m2.7 i GLM (uživatel ověří interaktivně).

---

## 2026-06-07 19:33 — tasks-daemon zaseknutý v start-limit-hit + hardening retry

**Cíl:** Uživatel hlásil problém s user systemd službami `tasks-daemon.path` / `tasks-daemon.service`. Zjistit příčinu, navrhnout fix, nasadit po schválení.

**Co jsem zkusil / zjistil:**

- `systemctl --user status` → obě unity `failed`, `.service` s `Result: unit-start-limit-hit`, „Start request repeated too quickly".
- `stderr.log` + journal: v 18:19 daemon 5× po sobě spadl na `NameError: name 'LOG' is not defined` (`tasks-daemon.py:152`) → za <2 s vyčerpal default rate-limit (`StartLimitIntervalSec=10s`, `Burst=5`) → systemd zalatchoval **`.service` i `.path`**.
- Časová osa: do 17:29 OK (4× done); 17:44 task na `minimax`; **18:19:14 SIGTERM (status=143)** — žádný timeout v unitu (předchozí běhy i 1553 s doběhly), takže externí stop (deploy fixu); 18:19:36–38 `.path` (level-triggered, inbox neprázdný) hned restartoval → 5× NameError → latch.
- **Klíčové:** ten `NameError` už byl opravený předchozí session (import `LOG` na ř. 37, viz záznam výše) a fix byl na serveru nasazený. Ruční test daemonu s korektní PATH → **`exit=0`**. Příčina pádu pryč; jediný zbytek = systemd zaseknutý ve `failed`, který se sám nezotaví.

**Co fungovalo a proč:**

- **A — recovery:** `systemctl --user reset-failed tasks-daemon.service tasks-daemon.path` + `restart tasks-daemon.path` → `.path` zpět `active (waiting)`. Inbox prázdný, nic se hned nespustilo.
- **B — orphan:** smazán `failed/2026-06-07_18_28_43_…-gemini.md` (vznikl 18:28 po latchi, nikdy nezpracován — bez `## Result` sekce).
- **C — hardening unitu** (`skills/detach/systemd/tasks-daemon.service`): přidáno `Restart=on-failure` + `RestartSec=60` (delay mezi pokusy po pádu; čistý exit 0 i SIGTERM od systemd nerestartují) a `StartLimitIntervalSec=1800` + `StartLimitBurst=20` (až 20 pokusů / 30 min, pak pauza + auto-resume jak okno klouže — už žádný permanentní latch ani ruční `reset-failed`). Doc ověřena: `man systemd.service` — pro `Type=oneshot` jsou zakázané jen `Restart=always/on-success`, `on-failure` povolený.
- Deploy `rsync`em jen `systemd/` podadresáře (změna izolovaná do unitu), `daemon-reload`, vlastník `nanobot:nanobot`. `systemctl show` potvrdil `Restart=on-failure / RestartUSec=1min / StartLimitIntervalUSec=30min / StartLimitBurst=20`.

**Jak vrátit zpět:** `git revert` commitu se změnou `tasks-daemon.service` + `rsync` `systemd/` zpět na server + `daemon-reload`. Recovery (A) a smazaný orphan (B) se nevrací.

**Co zbývá:** End-to-end potvrzení (nový detach task projde `.path` → drain → done) — uživatel ověří interaktivně; daemon na prázdném inboxu už ověřen (`exit=0`).

---

## 2026-06-10 07:35 — git cleanup: přestat trackovat gitignored soubory na serveru

**Cíl:** `.gitignore` v serverovém repu (`~/.nanobot/workspace`) přibyl pozdě — `__pycache__/*.pyc` a `MEMORY.md.bak` se dostaly do gitu dřív, takže je ignore neřešil a pořád byly trackované. Vyndat je z gitu, nechat na disku.

**Co jsem zkusil:**

- `git ls-files -i -c --exclude-standard` → **11 souborů** trackovaných i přes `.gitignore`: 10× `*.pyc` v `__pycache__/` (skills `detach`/`remind`) + `memory/MEMORY.md.bak`.
- `git ls-files -i -c --exclude-standard -z | xargs -0 git rm --cached` → odstranění z indexu, soubory na disku zůstaly (ověřeno `ls`).
- Commit `f93c1cf` jen s těmito removaly (explicitní pathspec) — repo mělo rozdělanou autonomní práci (Dream procesor: `cron/jobs.json`, `memory/history.jsonl`, skripty `remind/`), té se commit nedotkl. Po commitu `git ls-files -i -c --exclude-standard` = **0**.

**Co fungovalo a proč:** `.gitignore` ignoruje jen *netrackované* soubory; co už je v indexu, musí ven přes `git rm --cached` (smaže z indexu, nechá na disku). Od teď se nové `__pycache__/` už necommitují.

**Jak vrátit zpět:** `git revert f93c1cf` (znovu je začne trackovat).

---

## 2026-06-10 07:55 — Revize přepsaného remind skillu (YAML → SQLite)

**Cíl:** Uživatel nechal nanobota přepsat `/remind` skill z `reminder.yaml` na SQLite. Zkontrolovat výsledek, posoudit funkčnost, otestovat, navrhnout změny (vč. textu SKILL.md). Nic neměnit bez souhlasu.

**Co jsem zkusil:**

- Stáhl serverový skill (`rsync`) do `tmp/server-remind/`, přečetl `SKILL.md`, `db.py`, `remind_edit.py`, `remind_send.py`, `random_times.py` + všechny testy.
- Ověřil reálný stav serveru: schema `reminders.sqlite` (nové: `days_filter/from_date/until_date`), 14 reálných připomínek migrováno (25 `at`, 6 cron, 9 random), `reminder_fires`=0.
- Pustil test suite na serveru: **43 passed**.
- Read-only kontrola deployed senderu proti **kopii** prod DB (`REMIND_DB`, bez odeslání) — všech 9 random se spočítá bez výjimky, nic chybně due.
- Live test doručení: `remind_edit.py add --at` na +2 min (id=15), ověřeno `reminder_fires` zápis `('at', delivered, 07:54:01)` + DELIVER v logu + reálný příchod na Telegram (potvrdil uživatel), pak `remove --keyword` (soft-delete).

**Co fungovalo a proč:** Přechod na DB je funkčně nasazený a doručování jede. Nalezené defekty:

- **P1 schedule_type collision:** `schedule_{at,cron,random}` mají vlastní AUTOINCREMENT id → překryv (at 1–25, cron 1–6, random 1–9). UNION-ALL inference v `remind_send.main()` označí každý cron/random fire jako `'at'` → `reminder_fires.schedule_type` špatně + dedup pro cron/random nefunkční (maskuje jen 60s tolerance). Fix: každá `_due_*` vrací svůj typ.
- **P1 stale bootstrap:** serverové `AGENTS.md` + `TOOLS.md` pořád mluví o `reminder.yaml` a starém formátu `reminder.log` (auto-load každý tah).
- **P2 log regrese:** `log_operation` píše UTC + míchá ADD/EDIT/…/DELIVER; `TOOLS.md` „co dnes přišlo“ čeká Prague-time delivery-only.
- **P3:** mrtvý `import yaml`/pyyaml dep, ignorovaný sloupec `timezone`, hardcoded `CHAT_ID`, duplicitní text neřešitelný přes keyword (chybí `--id`), `__import__("datetime")`, `--replace-schedules` bez schedule → němá připomínka.
- **SKILL.md text:** matoucí „python3 required“, chybí instrukce odpovídat jazykem uživatele a jak řešit read-back doručení.
- **Repo desync:** lokální `skills/remind/` je pořád YAML verze + `IMPROVEMENTS_REPORT.md` + `reminder.example.yaml`; `knowledge.md` /remind sekce neplatná.

**Co zbývá:** Uživatel odsouhlasil rozsah oprav (P1 schedule_type, P1 bootstrap docs, P3 cleanupy, repo+knowledge sync); P2 (reminder_fires dotaz vs. čistý delivery-log) ještě nerozhodnuto.

**Jak vrátit zpět:** Test připomínka (id=15) už odstraněna (soft-delete). Žádná jiná změna na serveru neproběhla.

---

## 2026-06-10 08:10 — Implementace oprav remind skillu (po odsouhlasení)

**Cíl:** Provést odsouhlasené opravy z revize výše: P1 schedule_type, P1 bootstrap docs, P2 read-back přes reminder_fires, P3 cleanupy, repo+knowledge sync.

**Co jsem zkusil / udělal:**

- **remind_send.py:** každá `_due_{at,cron,random}` vrací `schedule_type`; smazána chybná UNION-ALL inference v `main()`. Odstraněn mrtvý `import yaml` + dep `pyyaml`. `CHAT_ID` → `_telegram_config()` čte `channels.telegram.allowFrom[0]` z configu, fallback konstanta.
- **remind_edit.py:** helper `_resolve_one` (výběr přes `--id` nebo `--keyword`, ambiguous vypíše ids); `--id` přidáno k remove/edit/enable/disable; guard na `--replace-schedules` bez nového schedule; nový subcommand `delivered [--since]` (čte `reminder_fires`, Prague time); `from datetime import date` místo `__import__`; dep `croniter` only.
- **SKILL.md:** instrukce odpovídat jazykem uživatele, dokumentace `delivered` + `--id` + duplicit, oprava matoucího Environment.
- **Testy:** +5 (schedule_type collision, --id disambiguace, resolve vyžaduje id/keyword, replace-schedules guard, delivered) → **48 passed** lokálně i na serveru.
- **Nasazení:** ověřeno, že server skill mezitím nikdo nesáhl (diff = jen mé změny), `rsync` na server, owner `nanobot:nanobot`, server pytest 48 OK, smoke `list`+`delivered` proti reálné DB OK. `delivered` ukázal reálné doručení „Panama" 08:02 — potvrdilo, že stará verze zapsala random odpal jako `schedule_type='at'` (P1 bug v praxi).
- **Bootstrap:** `AGENTS.md` + `TOOLS.md` na serveru — `reminder.yaml` → SQLite `db/reminders.sqlite`, sekce o `reminder.log` přepsána na `delivered`/`reminder_fires`. Push ověřen.
- **Repo:** `skills/remind/` synced z deploye, smazány `reminder.example.yaml` + `IMPROVEMENTS_REPORT.md` (commit `b244c01`). `knowledge.md` /remind sekce přepsána.

**Co fungovalo a proč:** Skilly se čtou bez restartu (exec subprocess + bootstrap fresh každý tah), takže fix je živý okamžitě. Dedup pro cron/random teď reálně funguje (správný schedule_type), ne jen díky 60s toleranci.

**Co zbývá:** Jeden historický řádek `reminder_fires` (reminder 7, 08:02) má pořád `schedule_type='at'` z bugu — oprava přes přímý prod UPDATE byla blokována auto-classifierem (neautorizovaný prod write), čeká na svolení uživatele. Kosmetické (znovu se neodpálí). Kandidáti do `decisions.md` (čekají na přeformulování autorem): úložiště = SQLite; read-back i audit = reminder_fires.

**Jak vrátit zpět:** Skill: `git revert b244c01` + rsync zpět na server. Bootstrap: serverové AGENTS.md/TOOLS.md vrátit na `reminder.yaml` formulaci (DB ale existuje, takže to nedává smysl). DB schema/data beze změny.

**Dodatek (08:13):** Po svolení uživatele opraven zaseknutý audit řádek — `UPDATE reminder_fires SET schedule_type='random' WHERE reminder_id=7 AND fire_time='2026-06-10T08:02:00'` (1 řádek). Tím je audit konzistentní s fixem.

---

## 2026-06-10 08:50 — Code review remind skillu + cleanup (P1+P2+P3)

**Cíl:** Detailní revize skillu `/remind`, ověřit shodu lokál↔server, navrhnout a po schválení provést zlepšení (čistota, čitelnost, normy).

**Co jsem zkusil / udělal:**

- **Review:** stáhl serverovou verzi, `diff` všech 5 skriptů + SKILL.md → **lokál identický se serverem**. Nálezy rozděleny P1/P2/P3, plán odsouhlasen uživatelem (rozsah: vše; `list` nemá vracet JSON).
- **P1 — korektnost:** `cmd_list` vypisoval **pozici** `{idx}.`, ne skutečné DB `id` → agent z `list` četl špatné číslo pro `--id`. Přepsáno na čitelný formát `#<id>  text  [status]` + odsazené schedule řádky, HH:MM okno, prázdný store → `(no active reminders)`. Helper `_schedule_lines`. SKILL.md popisuje nový formát místo neexistujícího „JSON". `db.log_operation(details: str)` → `str | None` (volá se s `None`).
- **P2 — struktura:** `cmd_edit` validace (prázdný text, `_build_random`) přesunuta **před** `BEGIN` (žádná otevřená transakce na early-return). Duplicitní `_parse_window`/`_hhmm_to_minutes` v `remind_edit.py` smazány → reuse `parse_window` z `random_times.py` (publikováno odebráním podtržítka). `_build_random` se volá jen jednou — `_insert_schedules` dostává hotový `random_cfg`.
- **P3:** `remind_send._now` → `_now_prague() -> datetime` (konec kolize s `remind_edit._now`, který vrací str); `_telegram_config()` čteno jednou v `main()` + early-return na prázdné `due`; `cmd_delivered` f-string SQL → dvě parametrizované query; `_find_by_keyword` escapuje LIKE wildcardy + `ESCAPE`; shebang obou skriptů → `uv run --script`. Testy: odstraněn nepoužitý `capsys`, `_run_send` korektně zachytává/obnovuje funkce, +3 testy (random `days_filter` e2e, retry po failed fire, `delivered` default „dnes").
- **Verifikace:** lokálně **51 passed**. Deploy `rsync` celý adresář, owner `nanobot:nanobot`. Server pytest **51 passed**. Smoke produkční `list` (reálná id, nový formát), `_due_random` dotaz proti reálné DB OK (9 random reminderů). Ověřeno, že produkční schéma `schedule_random` má `days_filter/from_date/until_date`.

**Co fungovalo a proč:** Skilly se čtou bez restartu. `reminder_cron.log` mtime 07:36 (před deployem) = od deploye crontab sender nezapsal žádnou novou chybu → běží čistě. Staré traceby v logu pochází z dávno mrtvé verze (`_process_reminder`, sloupce `days/start_date/end_date`, `ROLLBACK` v main) — irelevantní.

**Co zbývá / gotcha:**

- **`log_operation` ignoruje `REMIND_DB`** — píše vždy do reálného `workspace/log/reminder.log` přes `__file__`-relativní cestu. Spuštění test suite **na serveru** proto zapsalo 24 fixture řádků (timestamp `2026-06-10T06:47:32`) do reálného logu. **Poučení: testy spouštět jen lokálně.** Úklid logu (odstranit 24 řádků + truncate staré traceby v `reminder_cron.log`) byl blokován auto-classifierem (neautorizovaný prod write) — čeká na svolení uživatele.

**Jak vrátit zpět:** `git revert <commit>` skillu + rsync předchozí verze na server. DB schema/data beze změny.

## 2026-06-10 09:50 — Remind skill úklid: rename `remind_edit.py`→`remind_cli.py`, edit-guidance, hybrid SKILL.md

**Cíl:** Tři papercuts najednou (jeden deploy): (1) zavádějící název `remind_edit.py` (dělá i `list`/`delivered`, read-only); (2) agent při opravě textu maže+vytváří záznam znovu, místo `edit --text` (skript to **už uměl**, jen SKILL.md k tomu nenaváděl); (3) SKILL.md duplikoval výčet flagů s argparse → drift. Plán: [plans/](plans/) (schválen v plan mode).

**Co jsem zkusil / udělal:**

- **A. Rename** `git mv remind_edit.py → remind_cli.py` + `test_remind_edit.py → test_remind_cli.py` (import + `remind_cli.*` + argv[0]). Cross-importy nedotčené (`remind_send` importuje jen z `db`/`random_times`). **Crontab nezměněn** — spouští `remind_send.py`.
- **B. Dedup:** `_minutes_to_hhmm` byl doslova zkopírovaný v cli i send → přesunut do `random_times.py` jako veřejné `minutes_to_hhmm`, obě kopie smazány, importy upraveny.
- **C. Edit-guidance + test:** SKILL.md explicitně „oprava textu = `edit --id <n> --text`, NIKDY remove+add"; nový test `test_edit_text_by_id` (pokrývá dřív netestovanou `--id` větev editace).
- **D. SKILL.md → hybrid:** zachován NL→příkaz mapping + behaviorální kontrakt (formát `list`, JSON mutace, keyword/id ambiguous, `delivered`); vyčerpávající výčet flagů → `<cmd> --help`. Řeší drift z [memory.md](memory.md).
- Lokální změny delegovány na sonnet agenta; deploy + verifikaci řídil opus.

**Co fungovalo a proč:**

- Lokálně **52 passed** (51 + nový test).
- Server = zdroj pravdy: `rsync` server→`tmp/server-remind/`, `diff` všech 10 zdrojů proti **HEAD** → **identické**, žádná autonomní divergence (Dream procesor nesahal) → deploy bezpečný.
- Deploy `rsync` (exclude `__pycache__`/`.pytest_cache`/`.venv`), stale `remind_edit.py` + starý test **explicitně `rm`** (rsync bez `--delete` je nechává). Owner `nanobot:nanobot` OK.
- Server `remind_cli.py --help` + `list` (reálná data) OK; `remind_edit.py` pryč; crontab dál `remind_send.py`.
- **Živý edit test (bez Telegram fire):** `add --at 2020-01-01` (v minulosti → nikdy due), `edit --id 17 --text "TEST opraveny text"` → text změněn, `at` schedule (id 27) **zachován**, pak `remove --id 17` (úklid).

**Co zbývá:** Commit + push (tracking zvlášť dle konvence). `tmp/server-remind/` je v `.gitignore`.

**Jak vrátit zpět:** `git revert <commit>` skillu + na serveru rsync předchozí verze a `mv remind_cli.py remind_edit.py` zpět (DB beze změny).

## 2026-06-13 07:48 — note skill: zákaz vymýšlení tagů

**Cíl:** Odstranit nešvar, kdy agent při zakládání poznámky automaticky vymýšlí tagy z obsahu. Tagy se mají přidat jen když je uživatel explicitně napíše (první token za triggerem).

**Co jsem zkusil:** Příčina čistě v textu `skills/note/SKILL.md` — skript `note.py` je v pořádku (`--tags` volitelný, default `[]`, žádné auto-tagování). Svádějící formulace: hlavička „extract tags", věta „Tags are created automatically on first use", krok 1 Write protocolu „Extract inline tags". Upravil jsem všechny tři: hlavička → „take only explicitly-typed tags"; do Tag protocolu přidáno tvrdé pravidlo, že tagy pochází *jen* z prvního tokenu, nikdy se neodvozují z obsahu; přeformulováno „DB accepts any new tag without prior registration — not a license to make up tags"; krok 1 → „Take … only … tags field stays empty — never fill it from the content".

**Co fungovalo a proč:** Server↔lokál před úpravou shoda (diff prázdný). Nasazeno `rsync -av skills/note/ nanobot@nanobot.hell:…/skills/note/`, vlastník `nanobot:nanobot` ověřen. Skilly se čtou každý tah bez restartu.

**Co zbývá:** Verifikace reálným chováním (poznámka bez explicitního tagu → žádné tagy). Commit tracking zvlášť.

**Jak vrátit zpět:** `git revert <commit>` + rsync předchozí verze SKILL.md na server. DB beze změny.

## 2026-06-13 10:25 — Display ID (přečíslování on-the-fly) do /remind a /bookmark

**Cíl:** Přenést mechanismus z `/note` (sekvenční display ID 1..N počítané on-the-fly, nezávislé na rozházených interních DB id, přečíslování po každém smazání → snazší mazání/úpravy podle krátkého čísla) do `/remind` a `/bookmark`. Uživatel řekl „/article", ale to je čistě sumarizační skill bez seznamu — potvrzeno, že myslel `/bookmark`. Plán: [plans/](../.claude/plans/) (schválen v plan mode).

**Co jsem zkusil / udělal:**

- **Vzor z note (zrcadlit, ne vymýšlet):** helper vrací seřazené interní id aktivní množiny → výpis postaví `{interní_id: pořadí}` → mutace berou display ID, `idx = n-1`, bounds-check, přeloží na interní id.
- **remind** (`remind_cli.py`, `forecast.py`): nový `_active_display_order` (řazení `ORDER BY id`); `cmd_list` tiskne `#{display}`; **load-bearing: `--id` u remove/edit/enable/disable přeznačeno z interního DB id na display ID** + `--keyword` beze změny; `_resolve_one` bounds-check (`{"error":"no match","display_id":n}`), nejednoznačný keyword vrací `matches:[{"display_id":…}]`; `upcoming` + `format_upcoming(fires, id_to_display)` tisknou stejné display ID jako `list`; interní id zmizelo z user-facing výstupu (zůstává v audit logu a v JSON mutací).
- **bookmark** (`bookmark.py`): dvě množiny — `_ordered_ids(read=False)` nepřečtené (`created_at DESC`), `read=True` přečtené (`read_at DESC`); `read`/`show` řeší proti `list`, `unread` proti `history`; `_print_bookmark(row, display_id)`; `cmd_list` počítá display ID nad **celou** nepřečtenou množinou (filtr `--tag` drží globální čísla → očekávané mezery, jako note); `cmd_add` echo `#1` (newest-first); odstraněn dead `bid`.
- SKILL.md obou skillů aktualizovány (EN-only): display ID = sekvenční, on-the-fly, přečíslovává se; který výpis pro který příkaz; interní id se neukazuje.
- Testy remind: `test_forecast.py` opraven na novou signaturu `format_upcoming` (+ ověřuje překlad interní→display); přidány `test_display_id_renumbers_after_remove`, `test_id_out_of_range_reports_display_id`, `test_ambiguous_keyword_returns_display_ids`.

**Co fungovalo a proč:**

- Lokálně **71 passed** (`uv run --with pytest --with croniter pytest`).
- bookmark nemá testy → ruční ověření přes import s patchnutým `DB_PATH` na temp DB: add→#1, list 1..3 newest-first, `read 2` → přečíslování, `show 1`, `--tag` global ID, `history` vlastní číslování, `unread 1` přes history pořadí. Vše dle návrhu.
- Server = zdroj pravdy: `rsync` server→`tmp/srv/`, diff všech zdrojů proti **HEAD** → identické (žádná autonomní divergence Dreamem) → deploy bezpečný.
- Deploy `rsync` (exclude `__pycache__`); omylem se nahrál `.pytest_cache/` → smazán ze serveru. Owner `nanobot:nanobot` OK. Smoke test server `remind list` → display ID #1–#4 (interní id rozházená po smazáních). Skilly se čtou bez restartu.

**Co zbývá:** Commit kódu skillů (tracking zvlášť dle konvence — řeší uživatel). Návrh zápisu do `decisions.md`: load-bearing volba „`--id` u remind mutací = display ID, ne interní DB id".

**Jak vrátit zpět:** `git revert <commit>` skillů + rsync předchozí verze (HEAD) na server. DB schema/data beze změny.

## 2026-06-13 19:24 — Detach: recovery démona + úklid (code-review fixy #1,#2,#4,#5,#6,#7)

**Cíl:** Opravit 6 nálezů z code-review skillu `/detach` — dvě reálné díry v recovery démona (#1 osiřelé `running/`, #2 poison-loop) a čtyři úklidové (#4 duplicitní CONFIG, #5 duplicitní ensure_queue_dirs, #6 Markdown notifikace posílaná jako plain text, #7 duplicitní řazení v read-task). Plán: [plans/](../.claude/plans/) (schválen v plan mode). Implementaci lokálních editů dělal sonnet subagent (konvence „plány vykonává sonnet"), opus revize + deploy.

**Co jsem zkusil / udělal:**

- **#1+#2 společný refactor** `tasks-daemon.py`: vytažen `finalize_task(...)` (zápis Result+meta, mv do done/failed, resolve chat_id v `try`, guardovaná notifikace) — sdílí ho `process_task` i nový `reclaim_orphans()`. `process_task` přeskládán na **move-first** (resolve chat_id už neběží před mv ani mimo try → konec poison-loopu u ne-telegram kanálu s vadným `allowFrom`). `reclaim_orphans()` na startu `main()` označí přežité `running/*.md` jako `failed` + `(INTERRUPTED…)` + best-effort notifikace.
- **#1d** `tasks-daemon.path`: přidán druhý `DirectoryNotEmpty=…/tasks/running`, aby reclaim nečekal na další inbox task.
- **#4** `CONFIG` importováno z `tasks_common` (smazána lokální definice). **#5** `QUEUE_DIRS` + `ensure_queue_dirs()` do `tasks_common`, použito v create-task i daemonu. **#6** notifikace bez zpětných apostrofů. **#7** `find_matches` reuse `completed_files()`.
- **Drift při porovnání se serverem:** server měl `TIMEOUT_SECONDS = 20 * 60` (repo/HEAD = 45), upraveno mimo repo. Per „server je zdroj pravdy" zachováno 20 min, dotaženo do repa **samostatným commitem** (5581411) PŘED refactorem. Potvrzeno uživatelem.

**Co fungovalo a proč:**

- Lokálně **57 passed** (`uv run --with pytest pytest`).
- Server = zdroj pravdy: `rsync` server→`tmp/detach-server/`, diff proti HEAD → jediný drift `tasks-daemon.py` (timeout). Ostatní soubory identické.
- Deploy `rsync` (exclude `__pycache__`, `.pytest_cache`). `.path` unit je **symlink** z `~/.config/systemd/user/` do skill dir → rsync ho aktualizoval; `systemctl --user daemon-reload` + `restart tasks-daemon.path` (active). Owner `nanobot:nanobot` OK.
- **Live #1 verifikace:** dummy `running/2026-06-13_11_30_00_000001-reclaim-test.md` (chat_id `"1"` = neplatný, ať nespamuje reálný Telegram) → nový `running/` watch spustil démona → reclaim → přesun do `failed/` se `status: failed` + `(INTERRUPTED…)`. Log: `RECLAIM` + `END status=failed` + `NOTIFY-FAILED HTTP 400` (guard zafungoval). Test artefakt smazán z `failed/`.
- **#2** ověřeno strukturálně (resolve uvnitř finalize po mv, v try) + reclaim test exercoval guardovanou notify cestu; live failure-injection na prod config zbytečně invazivní.

**Co zbývá:** Návrh zápisu do `decisions.md` (load-bearing, čeká na souhlas autora): (a) `.path` unit hlídá i `running/` jako self-heal mechanismus reclaimu; (b) osiřelý task → `failed` (ne retry/re-queue) kvůli neopakování side-effectů agenta.

**Jak vrátit zpět:** `git revert 999b33c` (refactor) a/nebo `git revert 5581411` (timeout) + rsync předchozí verze (HEAD) na server; obnovit původní `.path` unit (jen inbox watch) + `daemon-reload` + `restart tasks-daemon.path`. DB/tasks data beze změny.

## 2026-06-14 08:46 — note: explicitní registrace tagů (konec auto-create)

**Cíl:** `/note` už nesmí tagy zakládat implicitně prvním použitím. Vznik tagu = samostatný explicitní příkaz; neznámý tag při zakládání poznámky → skill se zeptá, zda ho založit.

**Co jsem zkusil / udělal:**

- `note.py`: nová tabulka `tags(name PRIMARY KEY, created_at)`; `_backfill_tags` v migraci nasází distinct tagy z existujících poznámek (jen když je registr prázdný — idempotentní).
- `cmd_add`: po formát-validaci kontrola proti registru; neznámý tag → stderr `Unknown tag(s): …` + **exit 2**, poznámka se NEUKLÁDÁ. Exit kódy: 0 ok / 1 špatný formát / 2 neznámý tag.
- Nové příkazy `tag-add NAME` (idempotentní, reuse `_validate_tags`) a `tag-list` (řazení podle jména, bez display ID — tagy se referencují jménem; mazání se nezavádí).
- `SKILL.md`: přepsán Tag protocol (registrace povinná), Write protocol (větev na exit 2 — Ano→`tag-add`+re-run, Ne→re-run bez tagu), nová sekce Tag management, edge case `tag add` bez jména.

**Co fungovalo a proč:** Lokální verifikace na throwaway kopii (`tmp/verify`, real db naseedovaná) — backfill (arch/cli/test), known tag exit 0, unknown exit 2 + neuloženo, `tag-add` idempotentní, špatný formát exit 1, mixed known+unknown exit 2. Server je zdroj pravdy: před nasazením `rsync` serverové verze do `tmp/` + diff = jen mé změny (žádný Dream edit k záchraně). Nasazeno `rsync -av`, vlastník `nanobot:nanobot`. Migrace+backfill na serveru proběhla při prvním `tag-list` — zaregistrováno 5 tagů (chata/devops/dt-glass/shop/test). `uv` na serveru je v `~/.local/bin/uv` (není na non-interactive PATH).

**Co zbývá:** Návrh zápisu do `decisions.md` (čeká na souhlas autora): (a) registr tagů jako separátní tabulka + `add` odmítá neznámé (exit 2), vznik výhradně `tag-add` — load-bearing; (b) tagy se referencují jménem (bez display ID), mazání se nezavádí; (c) backfill jen při prázdném registru.

**Jak vrátit zpět:** `git revert <tento commit kódu>` + `rsync -av` předchozí verze `skills/note/` na server. Tabulka `tags` v DB může zůstat (stará verze ji ignoruje); pokud vadí: `sqlite3 db/note.sqlite "DROP TABLE tags;"` lokálně i na serveru.

## 2026-06-14 10:11 — note: render-safe URL ve `list` (inline Markdown odkaz)

**Cíl:** Ve `/note list` se u poznámky s holými URL (#7 „DT GLASS") v chat UI nevykreslilo pořadové číslo. Diagnóza (read-only): skript i data jsou OK — `note.py list` tiskne `N.` správně a model dostává správný text. Rozbíjí to až render chatu: řádek je položka číslovaného seznamu a holé `https://` URL se zároveň autolinkne do rich-link „chipu" (favicon „DG"), který se vykreslí na začátek řádku a překryje marker čísla. Ostatní řádky bez URL OK.

**Co jsem udělal:**

- `note.py`: nový helper `_linkify(text)` — regexem `https?://\S+` obalí holé URL do inline Markdown odkazu `[url](url)` (inline odkaz se nerenderuje jako chip → číslo přežije, URL zůstane celé i klikací). Trailing-punctuation peel (`.,;:!?)]`) drží čárku/závorku za URL mimo cíl odkazu.
- Použito jen v `cmd_list` (řádek výpisu). `cmd_show` záměrně netknut — má verbatim kontrakt; navíc není číslovaný seznam, ke kolizi nedochází. `add`/`delete` jednořádkové, bez kolize.
- `SKILL.md` List protocol: věta, že skript URL vypisuje jako inline odkazy a model má echovat beze změny (ať nepřebaluje zpět na holé URL).

**Co fungovalo a proč:** Regex izolovaně lokálně (čárka i `)` mimo odkaz). Server = zdroj pravdy: `rsync` server→`tmp/` + diff `note.py`/`SKILL.md` proti HEAD = IDENTICAL (žádný Dream edit k záchraně). Nasazeno `rsync -av skills/note/`, vlastník `nanobot:nanobot`. Server `note.py list` po deployi: #7 má URL ve tvaru `[https://…](https://…)`, marker `7.` na začátku. Prezentační změna — DB obsah i display-ID logika beze změny.

**Co zbývá:** Reálné ověření renderu v nanobot UI na konkrétním modelu dělá uživatel (zda inline odkaz UI neunfurluje do chipu). Fallback při unfurlu: backtick `` `url` `` (bez klik) nebo zkrácený popisek `[odkaz](url)`. Změna kódu `skills/note/` zatím necommitnuta (čeká na pokyn).

**Jak vrátit zpět:** `git checkout HEAD -- skills/note/scripts/note.py skills/note/SKILL.md` + `rsync -av skills/note/` předchozí verze na server. Bez dopadu na DB.

## 2026-06-14 11:33 — note: URL ve `list` — revert `_linkify`, model formátuje (bare URL na vlastní řádky)

**Cíl:** Dotáhnout render `/note list` u poznámek s URL tak, aby bylo vidět pořadové číslo **i** klikací odkaz. Předchozí iterace (`_linkify` → `[url](url)`, viz záznam 10:11) v reálném testu selhala stejně jako holé URL.

**Klíčové zjištění (přímý test s nanobot agentem):** Chyba je v markdown rendereru UI, ne v textu. UI **slučuje dva sousední inline odkazy `[text](url)`** do jednoho klikacího bloku a druhý URL schová → přebije i číslo položky. Naopak **holé URL se renderují správně a jsou klikací** (autolink); když je každý URL na vlastním řádku / pod odrážkou, neslučují se a číslo zůstane. `_linkify` (`[url](url)`) tedy dělal přesně tu rozbíjející věc.

**Co jsem udělal:**

- `note.py`: smazán helper `_linkify`; `cmd_list` vrácen na čistý výpis `N. {content}{tags}` (bare URL, jeden řádek). `cmd_show`/`add`/`delete` netknuty, DB i display-ID logika beze změny.
- `SKILL.md` List protocol: místo věty o „inline Markdown links" nová sekce *URLs in a note* s příkladem vstup→výstup — model má každý URL dát na vlastní řádek pod odrážku, **holý (nikdy `[text](url)`)**, popisek spárovat s URL, číslo i `[#tag]` zachovat. Důvod (slučování sousedních inline odkazů) ve skillu stručně.
- **Architektura:** formátování dělá model dle příkladu (umí spárovat popisek s URL). Deterministické formátování ve skriptu (zlom před každý URL) drženo **v záloze** v plánu pro případ, že glm příklad nedodrží.

**Co fungovalo a proč:** Server = zdroj pravdy: `rsync` server→`tmp/note-server` + diff proti repu = IDENTICAL (žádný Dream edit). `ast.parse` OK, `_linkify` pryč, `re` stále používáno (`_TAG_RE`). Nasazeno `rsync -av skills/note/`, vlastník `nanobot:nanobot`. Server `note.py list`: #7 „DT GLASS" má bare URL na jednom řádku, marker `7.` na začátku, žádný `[url](url)`.

**Co zbývá:** Reálné ověření v nanobot UI dělá uživatel — zda model (glm) příklad dodrží a render ukáže číslo + klikací URL pod odrážkami; otestovat i konzoli/Telegram. Když glm příklad nedodrží → přepnout na zálohu (deterministika ve skriptu). Změna kódu `skills/note/` zatím necommitnuta (čeká na pokyn).

**Jak vrátit zpět:** `git checkout HEAD -- skills/note/scripts/note.py skills/note/SKILL.md` + `rsync -av skills/note/` předchozí verze na server. Bez dopadu na DB.

## 2026-06-14 11:39 — note: URL ve `list` — fallback do skriptu (model příklad nedodržel)

**Cíl:** Přístup „model formátuje dle SKILL příkladu" v reálném testu selhal — glm vypsal raw řádek beze změny (jeden řádek, holé URL), UI ho celý udělalo klikací a číslo přebilo. Přepnuto na zálohu: formátování deterministicky ve skriptu.

**Co jsem udělal:**

- `note.py`: helper `_urls_on_own_lines(text)` + regex `_LABELED_URL_RE` (`\s*([^\s,]+:\s*)?(https?://[^\s,]+)`) — každý URL i s předsazeným „Label:" tokenem (pokud je) na vlastní odrážku ` - `. URL zůstává holé (autolink), comma/space url neukončuje předčasně (`[^\s,]+`). Použito jen v `cmd_list`.
- `SKILL.md` *URLs in a note*: model už neformátuje — **echovuje verbatim** (skript dodá odrážky); zákaz collapse zpět na jeden řádek a `[text](url)` zůstává.
- Heuristika popisku: „Label:" se spáruje s URL jen když je těsně před ním (jen `\s*` mezi) — vzdálený dvojtečkový token (např. „poznámka: … url") se nechytí. Cena: u prvního URL zůstane oddělovač („—") viset na konci hlavičkového řádku; přijatelné.

**Co fungovalo a proč:** Lokální test helperu na 4 vstupech (dvě labeled URL, bez URL, url uprostřed věty, jediný url) — výstup čistý, popisky spárované, no-URL poznámka beze změny. `ast.parse` OK. Nasazeno `rsync -av`, vlastník `nanobot:nanobot`. Server `note.py list`: #7 „DT GLASS" má hlavičku + dvě odrážky `- Universal: <url>` / `- Amber: <url>`, číslo `7.` na začátku.

**Co zbývá:** Reálné ověření v nanobot UI dělá uživatel (číslo + klikací URL pod odrážkami; ať model echovuje verbatim a neslepí to). Otestovat i konzoli/Telegram. Změna kódu `skills/note/` zatím necommitnuta (čeká na pokyn).

**Jak vrátit zpět:** `git checkout HEAD -- skills/note/` + `rsync -av skills/note/` předchozí verze na server. Bez dopadu na DB.

## 2026-06-11 20:02 — SOUL.md: přidány 2 behaviorální principy + zachycena autonomní divergence serveru

**Cíl:** Uživatel zvažoval přidat do nanobotových instrukcí blok behaviorálních pravidel (simplest approach, don't assume, surface tradeoffs, minimal code, loop-until-verified). Posoudit přínos a případně přidat.

**Co jsem zkusil / udělal:**

- Analýza navrženého textu proti `SOUL.md`/`AGENTS.md` (oba se čtou do system promptu každý tah, fresh — viz knowledge.md). Závěr: ~80 % už pokryto v SOUL.md (execute-immediately ř.19, don't-assume ř.21, ask-when-unsure ř.10/23/27, verify-after-changes ř.24). Coding-specific body (minimal code, surgical diffs, clean up orphans) pro asistenta irelevantní. Reálně nové jen 2: **jednoduchost** a **surface tradeoffs**.
- Stáhl serverové `SOUL.md`+`AGENTS.md` (`rsync`→`tmp/`). `diff` serveru proti `workspace/SOUL.md` (repo).
- **Server autonomně divergoval od posledního sync (`7d89c56`):** zahodil 3 řádky (`Předpokládám znalost u uživatele…`, `U nevratných akcí raději počkat na potvrzení`, `Žádné emojis…`) a přidal 1 (`Čísla, limity, kvóty… ověřuj na primárním zdroji`). Pravděpodobně Dream procesor.
- Dle pravidla „server = zdroj pravdy": server vyhrává, 3 zahozené řádky **nekřísím**. Mé 2 řádky přidal do serverové kopie:
  - `## Hodnoty`: „Jednoduchost před komplexností — nejjednodušší funkční řešení; složitější vzory nenavrhuj, dokud o ně uživatel neřekne"
  - `## Pravidla provedení`: „Když existuje víc cest, vynes tradeoff nahlas místo tichého výběru jedné"
- `rsync` zpět na server, ověřen owner `nanobot:nanobot` + oba řádky (ř.14, ř.26). Repo `workspace/SOUL.md` dotaženo na nový serverový stav (vč. autonomních změn serveru).

**Co fungovalo a proč:** SOUL.md se čte fresh každý tah → **bez restartu** platí od příští zprávy. Porovnání se serverem odhalilo autonomní divergenci dřív, než by ji slepý přepis lokální verzí zahodil.

**Co zbývá:** Zvážit, zda 3 řádky zahozené serverem (zvlášť „U nevratných akcí raději počkat na potvrzení") chceme obnovit, nebo respektovat rozhodnutí Dreamu. Zatím ponecháno tak, jak je server nastavil.

**Jak vrátit zpět:** `git revert <commit>` + rsync předchozí verze na server.

## 2026-06-11 20:06 — SOUL.md: obnoven řádek o potvrzení nevratných akcí

**Cíl:** Z 3 řádků, které server autonomně zahodil (viz záznam 20:02), obnovit ten bezpečnostně relevantní.

**Co jsem udělal:** Posoudil všechny 3 zahozené řádky proti zbytku SOUL.md. Jen `U nevratných akcí raději počkat na potvrzení` byl skutečná mezera (ostatní 2 — „předpokládám znalost", „žádné emojis" — pokryto `bez ozdob`/terseness/USER.md, ponechány zahozené). Obnoven do `## Pravidla provedení` k pravidlu o potvrzování vícekrokových úkolů, přeformulován obecněji: „U nevratných akcí (smazání, přepis, odeslání) raději počkej na potvrzení — i u jednokrokových". `rsync` na server, ověřen owner + řádek (ř.22), repo dotaženo.

**Co fungovalo a proč:** Fresh read každý tah → bez restartu.

**Jak vrátit zpět:** `git revert <commit>` + rsync předchozí verze na server.

## 2026-06-15 05:30 — /remind: náhodný rozvrh napříč týdnem + sync display-id featury ze serveru

**Cíl:** Rozšířit `/remind` o „N× náhodně v týdnu" (vedle stávajícího N× za den) — N náhodných odpálení rozprostřených přes celý týden.

**Co jsem zkusil / udělal:**

- **Návrh:** engine `compute_fire_times(target_date, text, cfg)` zůstává **per-day volaný** — pro weekly režim spočítá celý týdenní plán (seed = pondělí týdne + text, ne den) a vrátí jen fires daného dne. Tím daemon i forecast nemění iterační logiku. Semantika (potvrzeno uživatelem): N **různých** dnů (Po–Ne), 1 čas na den, okno povinné; `min(count, dostupné dny)` clamp pro hraniční týdny.
- **Změny:** sloupec `schedule_random.period` ('day'/'week', default 'day') + idempotentní `_migrate(conn)` v `get_db` (PRAGMA-guarded ALTER, protože `init_db` na živou DB nesahá); `_weekly_fire_times` v `random_times.py`; flag `--random-times-per-week` (add+edit, mutually exclusive s `--random-times-per-day`); `period` do INSERT/SELECT/list výpisu (`× weekly`/`× daily`). +10 testů.
- **Server = zdroj pravdy (klíčový krok):** `rsync` server→`tmp/server-remind/`, `diff` proti **git HEAD** odhalil, že server **autonomně divergoval** — měl feature **display IDs** (přečíslování reminderů na 1-based pozici v `list`/`upcoming`, `--id` i chybové hlášky pracují s display ID), která **nebyla v repu**. Pravděpodobně Dream procesor.
- Postup dle pravidla: weekly diff uložen jako patch (`git diff HEAD > /tmp/weekly.patch`), pracovní strom resetován na HEAD, serverové verze 5 divergovaných souborů (`SKILL.md`, `remind_cli.py`, `forecast.py`, `test_remind_cli.py`, `test_forecast.py`) přeneseny do repa → **commit „sync display IDs"** (71 testů). Pak `git apply --3way` weekly patche — všechny `.py` čistě, konflikt jen v `SKILL.md` (oba odstavce do stejného místa, ponechány oba) → **commit weekly** (80 testů).
- **Deploy:** `rsync` (exclude `__pycache__`/`.venv`/`.pytest_cache`), owner `nanobot:nanobot` OK. `list` na serveru → prod DB se zmigrovala (`period` přidán), stávajících 13 reminderů dál `× daily`.

**Co fungovalo a proč:** Per-day volací rozhraní enginu = daemon/forecast bez změny logiky (jen `sr.period` do SELECTů, protože `random_cfg_from_row` ho čte). Porovnání se serverem proti **HEAD** (ne proti pracovnímu stromu, kde už byly mé editace) odhalilo cizí divergenci — slepý rsync by display-id feature smazal. Dvoukrokový merge (sync commit → weekly na něj) zachoval obě featury, ověřeno 80 zelenými testy + kombinovaným smoke testem (display IDs #1/#2 + `2× weekly` + 2 různé dny).

**Co zbývá:** Commit tracking souborů. Skripty se čtou per-invocation → daemon bere nový kód bez restartu.

**Jak vrátit zpět:** `git revert 17feee6` (weekly) a `git revert fcfe794` (display-id sync), pak `rsync` předchozí verze skillu na server. Sloupec `period` v prod DB lze nechat (default 'day' = původní chování) nebo `ALTER TABLE schedule_random DROP COLUMN period`.

## 2026-06-15 05:44 — /remind: vytažení data-access vrstvy do `store.py`

**Cíl:** Reakce na uživatelovu otázku, zda `remind_cli.py` (534 ř.) není moc dlouhý. Po re-review ne kvůli délce, ale kvůli dvěma smellům: (1) `db.py` deklarovaný jako storage layer neobsahoval žádné dotazy — veškeré SQL žilo v CLI; (2) transaction boilerplate (`get_db`/`BEGIN`/`COMMIT`/`ROLLBACK`/`close`) duplikovaný ~7× napříč `cmd_*`. Cíl: CLI = čistá prezentační vrstva, SQL + lifecycle do nového modulu. Veřejné API beze změny (testy musí projít).

**Co jsem zkusil:** Plán (`plans/` přes plan mode), implementaci delegoval na sonnet agenta dle konvence. Nový `scripts/store.py` (240 ř.): context managery `connection()`/`transaction()` + dotazové funkce (`insert_reminder`, `insert_schedules`, `fetch_reminder`, `schedules_for`, `list_active`, `find_active_by_id/keyword`, `active_display_order`, `soft_delete`, `update_text`, `delete_schedules`, `touch`, `set_enabled`, `delivered_since/today`). `remind_cli.py` 534→400 ř., všechny `cmd_*` přes `store.*`, žádné inline SQL ani `BEGIN/COMMIT`. `remind_send.py` zatím nedotčen (volitelný krok).

**Co fungovalo a proč:** 80/80 testů zelených (`uv run --with croniter --with pytest pytest`), smoke add→list→remove OK. **Past, do které jsem nespadl:** working tree měl na startu necommitnutý revert display-ID → raw-DB-id v `remind_cli.py` (testy k němu neupravené → padaly by). Ověřením proti **serveru (zdroj pravdy přes `ssh`)** potvrzeno, že server i HEAD mají display-ID → raw-id byl stray edit, který agent správně zahodil. Bez ověření serveru bych mohl chybně „zachovat" rozbitý stav.

**Co zbývá:** Nasadit na server (`rsync` celého skillu) — server má pre-refactor display-ID verzi bez `store.py`; před přepisem porovnat se serverem (žádná autonomní divergence se nečeká, ověřeno). Skripty se čtou per-invocation → bez restartu. Případný `decisions.md` zápis (samostatný `store.py` vs. growth `db.py`) k odsouhlasení autorem.

**Jak vrátit zpět:** `git checkout HEAD -- skills/remind/scripts/remind_cli.py && rm skills/remind/scripts/store.py` (lokálně necommitnuto). Na serveru: `rsync` předchozí verze skillu zpět.

## 2026-06-15 05:50 — /remind: dokončení refaktoru (remind_send.py) + nasazení na server

**Cíl:** Dotáhnout volitelný krok — přesun read dotazů `remind_send.py` do `store.py` — a nasadit celý refaktor na server.

**Co jsem zkusil:** Do `store.py` přidány sender helpery (`due_at`, `enabled_cron`, `enabled_random`, `is_fire_delivered`, `record_fire`). `remind_send.py` přepsán: `_due_*` volají `store.*`, `main()` přes `store.connection`, žádné inline SQL ani `get_db`/`init_db`/`conn.close`. `record_fire` bez časové logiky (store je bezčasový) — `delivered_at` počítá `remind_send._record_fire` a předává explicitně. Nasazení: `rsync` server→`tmp/server-remind/` + diff proti lokálu — `db.py`/`forecast.py`/`random_times.py`/`SKILL.md` shodné (žádná autonomní divergence), lišil se jen refaktor → `rsync` lokál→server, owner `nanobot:nanobot` ověřen.

**Co fungovalo a proč:** 80/80 testů zelených (testy volají jen `main()`+patch `_send_telegram`/`_now_prague`/`DB_PATH`, vnitřní `_due_*` netestují přímo → přesun bezpečný). Server smoke: `list` (display-ID #1/#2/#3) + import `remind_send`+`store` OK. Cron sender (`* * * * * uv run .../remind_send.py`) vezme nový kód při příštím běhu — per-invocation read, bez restartu. **Lokálně necommitnuto** (kód skillu commituji jen na vyžádání).

**Jak vrátit zpět:** `git checkout HEAD -- skills/remind/scripts/remind_cli.py skills/remind/scripts/remind_send.py && rm skills/remind/scripts/store.py`, pak `rsync` HEAD verze skillu na server.

## 2026-06-15 13:21 — /remind: explicitní instrukce pro vypsání čtecích příkazů

**Cíl:** Uživatel hlásil, že po nedávných úpravách `/remind` dva různé modely „nedokážou vrátit celou tabulku" a každý to obchází jinak. Najít příčinu (nic neměnit), pak opravit instrukce ve skillu.

**Co jsem zkusil:** Reprodukce CLI lokálně i na serveru (`uv run … list`) → **exit 0, kompletní 18řádková tabulka**. Vyloučeno: pád, `uv`/PATH (uv jen v login shellu `~/.local/bin`, ale nanobot `exec` ho má), chybějící croniter (systémový python3 ho nemá — `from croniter import croniter` na ř. 22 → ImportError, ale agent jede přes uv), i refaktor `store.py` (`3de1d6b` sáhl jen na Python, `SKILL.md` se nedotkl). Stáhl jsem dvě webui session z poslední hodiny (`workspace/sessions/`): `552c62c9` (**kimi27**) i `ee623e4b` (default model) — **obě** spustily `list` úspěšně a dostaly celou tabulku, ale kimi27 odpověděl jen *„Máš 18 aktivních připomínek."* a druhý si postavil vlastní parafrázovanou markdown tabulku.

**Co fungovalo a proč:** Příčina = **mezera v `SKILL.md`, sekci `## Behavioral contract`**: popisuje *formát* výstupu `list` (uvozený jako ``` ukázka → vypadá jako schéma dat), ale nikde neříká „výstup předej uživateli kompletní". Modely to čtou jako surová data a každý si je naformátuje/zkrátí po svém. Fix: nový odstavec **Showing read results** na začátku sekce — `list`/`upcoming`/`delivered` vrací user-ready text, vypsat každou položku, nesumarizovat na počet, nevynechávat řádky; hezčí formát (tabulka, parafráze cronu) povolen, pokud zůstane `#display-id`. Plus oprava zastaralé argparse help hlášky `remind_cli.py` (`list` „as JSON" → „as readable text"). Nasazeno `rsync`em (owner `nanobot:nanobot` OK), CLI dál exit 0 / text, help aktualizován. Skilly se čtou per-tah bez restartu.

**Co zbývá:** Behaviorální ověření dělá uživatel ve webui — znovu `/remind list` s kimi27 i default modelem, ověřit že oba vypíšou všech 18 položek s `#display-id`. CLI test to neověří (chyba byla v chování modelu, ne ve skriptu).

**Jak vrátit zpět:** `git checkout HEAD -- skills/remind/SKILL.md skills/remind/scripts/remind_cli.py`, pak `rsync` předchozí verze skillu na server.

## 2026-06-15 13:28 — /remind: iterace formátu výpisu — kompaktní, model-side, jen enabled

**Cíl:** Po prvním kole (13:21) modely vypisovaly *všech* 18 položek, ale věrně relayovaly raw formát CLI → ukecané, víceřádkové, `[enabled]` u všech, nečitelné. Uživatel chce, ať to **model sám přepíše do pěkné kompaktní podoby**, vypíše **jen enabled** a `[enabled]` tag vynechá. **CLI se nemění — dělá to model.**

**Co jsem zkusil:** Přepsán odstavec **Showing read results** v `SKILL.md` (ř. 35): pro `list` model přepíše raw výstup do kompaktní podoby vlastní volby (řádek na připomínku, cron parafrázovaný do přirozené řeči), vypíše jen enabled (disabled přeskočí), zachová `#display-id` přesně jak je CLI vypsalo (mezery z přeskočených disabled OK — aby `--id` dál sedělo na `active_display_order`, které zahrnuje i disabled), bez `[enabled]` tagu. Obecné „nesumarizovat na počet" zůstává pro list/upcoming/delivered. Raw-formát blok pod tím ponechán (dokumentuje vstup, který model přepisuje). CLI `cmd_list`, `store.py` ani testy nedotčeny.

**Co fungovalo a proč:** Záměrně model-side render, ne změna Pythonu — uživatel chce „pěknou podobu podle sebe", což je prezentační volba, ne deterministický kontrakt. Klíčový constraint v instrukci: zachovat původní `#display-id` i při skrytí disabled, jinak by se rozbila vazba `--id` ↔ pořadí v CLI. Nasazeno `rsync`em (owner `nanobot:nanobot` OK), bez restartu.

**Co zbývá:** Behaviorální ověření dělá uživatel ve webui — `/remind list` s kimi27 i default modelem: kompaktní seznam, řádek/připomínka, bez `[enabled]`, jen enabled, se zachovanými `#display-id`.

**Jak vrátit zpět:** `git checkout HEAD -- skills/remind/SKILL.md` (vrátí na verzi z 13:21), pak `rsync` na server.

**Potvrzeno (13:3x):** Uživatel ve webui ověřil — výpis vypadá pěkně, kompaktní. Smyčka uzavřená.

## 2026-06-16 21:20 — llm-wiki: port pluginu jako skill (lokální PoC) + nasazení na server

**Cíl:** Portovat [llm-wiki-plugin](https://github.com/praneybehl/llm-wiki-plugin) (Karpathyho „LLM Wiki" pattern) jako nanobot skill — PoC, čistě lokálně, wiki v `workspace/cml/`, git nad `workspace/` = safety net. Plán: [plans/llm-wiki-skill.md](plans/llm-wiki-skill.md). (Širší multi-klient vize je odložená case study `plans/wiki-znalostni-baze.md`.)

**Co jsem zkusil:** Naklonoval plugin do `tmp/`. Zjištění proti WebFetch odhadu: **SKILL.md má jen 160 ř.** (ne 2200 — tělo už rozdělené, detaily v `references/`), 7 stdlib skriptů (PyYAML jen `wiki_graph_lint`+`wiki_graph_extract`, `wiki_graph_query` čte sqlite). Zkopíroval `SKILL.md`+`scripts/`+`references/`+`assets/` (assets nutné — `init_wiki.py` z nich kopíruje šablony) do `skills/llm-wiki/`; vynechal `commands/` (CC-only slash, duplikují SKILL.md), `.claude-plugin/`, `integrations/`. Skripty: PEP 723 hlavička (`uv run --script`, deps `[]` / `["pyyaml"]`); default cesty `Path("wiki")`→`Path("cml/wiki")` u 4 skriptů s defaultem (robustní — agent nemusí cestu pamatovat). Docstringy skriptů nechal generické (skript je generický, nanobot-ismus patří do SKILL.md). SKILL.md: sed `python …scripts/`→`uv run skills/llm-wiki/scripts/`, `.py wiki/`→`.py cml/wiki/`; přidal **„Nanobot adaptation"** sekci (fixní `cml/wiki`+`cml/raw`, uv run, separate store mimo note/keep/MEMORY, **Dream nesahá do cml/**, **lint report-only**, jazyk uživatele, local PoC); krok agent-memory-integration vypnut. Bootstrap: `init_wiki.py . --wiki-dir cml/wiki --raw-dir cml/raw` (root `.` existuje, init `<project-root>` sám nevytváří).

**Co fungovalo a proč:** Lokální smoke (`tmp/wiki-test`): init→2 vzorové stránky→lint (detekoval broken `[[wikilink]]`)/stats/search (BM25)/graph_lint (validace ontologie)/graph_extract (2 nodes/3 edges, 0,15 s)/graph_query (neighbors prochází `mentions`+typed edge) — vše přes `uv run` s defaultem `cml/wiki` bez předání cesty. Server: `rsync` skillu (owner `nanobot:nanobot` ✓), git nad `workspace/` potvrzen, `uv` v `~/.local/bin/uv` (mimo non-login PATH — pro SSH/cron plná cesta, gotcha #8). Init na serveru vytvořil `cml/wiki`+`cml/raw` (`nanobot:nanobot`), lint/stats/graph_extract běží pod serverovým `uv` (PyYAML stažen, 0,26 s). Skill se čte per-tah bez restartu. **Pattern sedí na nanobot 1:1** — `edit_file`=chirurgické `str_replace`, exec=python, nezávislost na CC hooks/MCP potvrzena.

**Co zbývá:** (1) Behaviorální E2E přes Telegram/WebUI — NL trigger („ingest this into my wiki…", „what does my wiki say about X") dělá uživatel; ověřit reálný ingest (chunkování velkého zdroje vs 60 s exec limit, #5). (2) **Fáze B:** periodický `wiki_lint` přes HEARTBEAT (report-only). (3) Kód skillu lokálně **necommitnuto** (commituji jen na vyžádání).

**Jak vrátit zpět:** Lokálně `rm -rf skills/llm-wiki`. Server: `ssh nanobot@nanobot.hell 'rm -rf ~/.nanobot/workspace/skills/llm-wiki ~/.nanobot/workspace/cml'`.

## 2026-06-16 22:15 — llm-wiki: rychlý capture + dávkový compile (systémový cron → wiki_compile.py)

**Cíl:** PoC ingest přes WebUI trval **1:41** (agentní compile, ne skripty) → nepoužitelný interaktivně. Oddělit **capture** (instantní hod zdroje do `cml/raw/`) od **compile** (těžký raw→wiki) a compile spouštět na pozadí přes systémový cron. Plán: [plans/llm-wiki-skill.md](plans/llm-wiki-skill.md), sekce „Capture + dávkový compile".

**Co jsem zkusil:** Nový `skills/llm-wiki/scripts/wiki_compile.py` (vzor `detach/tasks-daemon.py`): shebang `uv run --script` + PEP 723 `["nanobot-ai"]`, ale **`from nanobot import Nanobot` odložen do `run_compile()`** — levná per-minutová pre-kontrola nesmí platit import těžkého balíku. Tok: (1) scan `cml/raw/` na pending regulérní soubory (mimo `_done/`/`_hard/`/`assets/`) → prázdno = exit 0 bez LLM; (2) atomický lockfile `cml/.compile.lock` (PID+timestamp) přes `os.open(O_CREAT|O_EXCL)`, stale-detekce (mrtvý PID přes `os.kill(pid,0)` / stáří > 30 min se přebere); (3) `Nanobot.from_config()` + `asyncio.wait_for(bot.run(drain_goal, session_key="wiki-compile"), 25min)` — drain = všechno nasbírané v jednom dávkovém běhu; (4) tiše, jen log do `log/wiki_compile_cron.log`. SKILL.md: nová sekce **„Capture vs compile"** (capture zapíše `cml/raw/<slug>.md` + STOP, escape hatch „compile now"; `_done/`/`_hard/` konvence) + ingest workflow zarámován jako compile/drain + **fix slug-kolize** (concept/entity = krátký název pojmu, source = slug zdroje — řeší původní kolizi RoPE). Crontab `nanobot` (PATH= už nastaven kvůli remind): `* * * * * uv run …/wiki_compile.py >> …/wiki_compile_cron.log 2>&1` (forma `uv run <path>` jako remind, **ne** holý shebang — non-login/cron PATH nemá uv → `env: uv: No such file or directory`, gotcha #8).

**Co fungovalo a proč:** Lokálně (mock workspace v `tmp/`, `--dry-run`, čistý stdlib bez uv) ověřeny všechny větve: prázdný inbox→exit 0 bez logu; pending→dry-run+lock uvolněn; živý lock (reálný PID)→SKIP, lock zachován; stale lock (mrtvý PID)→reclaim. Server: deploy `rsync` (owner ✓), **reálný compile** leftover `rotary-position-embedding.md` proběhl na pozadí za 100 s, `remaining=0`, přesun do `_done/`, vznikly `concepts/rope.md` + `sources/rotary-position-embedding.md` + `entities/paper-rope.md` (slug fix drží — žádná kolize), index+log+graph (nodes/edges/sqlite/graphml) regenerovány. **Empty-inbox fast path: 0,119 s, exit 0, žádné volání LLM** — to je jádro efektivity minutového pollingu. **Živý cron test:** dropnut `alibi-position.md` → cron ho zvedl za ~50 s (hranice minuty), compile 107 s, přesun do `_done/`, `concepts/alibi.md`+`entities/paper-alibi.md`+`sources/alibi-position.md`, cross-link `[[rope]]`. Celý pipeline (capture instant → cron compile dávkově) běží end-to-end.

**Co zbývá:** (1) Capture přes WebUI/Telegram ověří uživatel — „ulož X" musí vrátit **instant ack** bez 1:41 (kód capture je instrukce v SKILL.md, ne skript → behaviorální). (2) Drobnost: agent v `log.md` napsal concept jako `concepts/rotary-position-embedding.md`, reálný soubor je `concepts/rope.md` (kosmetické, `[[rope]]` v indexu sedí). (3) Kód skillu lokálně **necommitnuto** (commituji jen na vyžádání). (4) Fáze B periodický lint přes HEARTBEAT — stále odloženo.

**Jak vrátit zpět:** Crontab: `ssh nanobot@nanobot.hell 'crontab -l | grep -v wiki_compile | crontab -'` (smaž i komentář řádek). Skill: `git checkout HEAD -- skills/llm-wiki/SKILL.md && rm skills/llm-wiki/scripts/wiki_compile.py`, pak `rsync` na server. Test artefakty (PoC demo obsah, lze nechat): pages pro rope/alibi v `cml/wiki/` + `cml/raw/_done/*` + `log/wiki_compile_*.log`.

## 2026-06-16 22:45 — llm-wiki: zpřísnění capture brány (capture/compile split se nedodržoval)

**Cíl:** Ověřit capture chování (uživatel chtěl testovat přes WebUI). Test odhalil regresi: capture/compile split se nedodržuje.

**Co jsem zkusil:** Pustil capture-style goal přes `bot.run(session_key="wiki-capture-test")` (transport-nezávislé, jako WebUI tah): „Ulož mi do wiki: <YaRN fakt>". **Agent ignoroval capture instrukci a udělal celý inline compile za 233 s** — vytvořil concept/entity/source stránky, upravil rope.md, rozšířil ontologii, překompiloval graf. Tedy přesně to, čemu jsme se chtěli vyhnout (původně 1:41, teď ještě hůř). Příčina: tělo SKILL.md je převážně návod „jak udělat plný ingest", a model „ulož do wiki" čte jako „proveď ten workflow"; moje sekce „Capture vs compile" to nepřebila — byla příliš měkká a tonula v okolním textu. **Druhý problém:** inline compile nepřesunul zdroj do `_done/`, takže cron pak zvedl `cml/raw/yarn.md` znovu a drain agent se **zacyklil** (132 iterací) reconciliací už existujících stránek. Runaway proces (PID 320950, ~6 min) jsem `pkill -TERM`-l, smazal lock, přesunul `yarn.md` → `_done/` (zastavilo příští cron tik). Fix SKILL.md: (1) **tvrdé pravidlo nahoře** v „read this first" — interaktivní požadavek = CAPTURE ONLY, inline compile je bug; (2) capture bullet přepsán na 3 kroky (zápis do `cml/raw/`, jednořádkový ack, STOP) + **výčet zakázaných akcí** (žádné čtení SCHEMA/index, žádné stránky, žádné skripty, žádný graf); (3) escape hatch zúžen („add to wiki" NENÍ escape); (4) STOP-redirect na začátku ingest workflow sekce. `wiki_compile.py` drain goal dostal **idempotenci** (existující stránky → `_done/`, necyklit; vždy přesunout z `cml/raw/`).

**Co fungovalo a proč:** Po redeploy znovu-test (Flash Attention): **capture 26 s** (jen cold-start `bot.run`, ne compile), odpověď „Zachyceno — zkompiluju na pozadí.", vznikl jen `cml/raw/flash-attention.md`, **žádná wiki stránka inline** — brána drží. Cron pak flash-attention zkompiloval na pozadí čistě (188 s, `remaining=0`, přesun do `_done/`, 3 stránky, **bez loopu** — idempotence + nový zdroj). Skill commitnut (`751a11a` celý skill na výslovnou žádost; `9bc52d8` zpřísnění brány).

**Co zbývá:** (1) Uživatel otestuje capture/query/lint sám přes WebUI (teplá session → svižnější než 26 s). (2) **Drobnost — slug kolize u Flash Attention:** source i concept dostaly slug `flash-attention` (u RoPE se přirozeně lišily `rope`/`rotary-position-embedding`); pravidlo „při kolizi suffixuj" agent neaplikoval → `[[flash-attention]]` dvojznačný mezi `sources/`+`concepts/`. Demo obsah, ne pipeline bug. (3) **Compile time roste s velikostí wiki** (100→188 s) — agent čte víc kontextu; na pozadí nevadí latencí, ale roste token cost. (4) Fáze B periodický lint přes HEARTBEAT — odloženo.

**Jak vrátit zpět:** `git checkout HEAD~2 -- skills/llm-wiki/SKILL.md skills/llm-wiki/scripts/wiki_compile.py` (před zpřísněním), `rsync` na server. Runaway compile už zabit, lock čistý, `cml/raw/` prázdné (vše v `_done/`).

## 2026-07-01 10:40 — note: kompletní přepis na capture → compile pipeline (nasazeno)

**Cíl:** Překopat `/note` z SQLite row-store (add/list/show/delete/tagy/display ID) na osobní znalostní bázi: dumb capture z různých kanálů → periodický compile do JEDNOHO strukturovaného `notes/notes.md` s tematickými sekcemi; hledání = načíst celý dokument. Bez DB, čistě detach-style adresáře. Plán: [plans/note-prepis.md](plans/note-prepis.md).

**Návrh (brainstorming + serverová verifikace):** Architektonicky stejný vzor jako `/llm-wiki`, ale záměrně lehčí (jeden doc, žádný index/graph/lint). Rozhodnutí: oddělený lehký skill; tematické sekce řídí LLM; **dual-mode** `/note <text>` = okamžitě inline compile (default), `/note cron <text>` = odloženě přes cron; tagy zrušeny; mazání = editace dokumentu. Ověřeno na serveru před psaním kódu: **`web` tool JE zapnutý** (config `tools.web`: DuckDuckGo + Jina Reader fetch — `TOOLS.md` ho nezmiňuje!) → URL fetch přes něj, ne curl; crontab uživatele `nanobot` má `PATH=` hlavičku → bare `uv run` funguje; `notes/` existoval prázdný; žádný drift skillu; `note.sqlite` = 17 aktivních notes.

**Co jsem udělal:**

- `note_capture.py` — dumb atomic capture (timestamp `%Y-%m-%d_%H_%M_%S_%f`, staging→`os.replace`, frontmatter provenience, ASCII-fold slug pro diakritiku) → `notes/inbox/` + řádek do `log/note.log`.
- `note_compile.py` — tenký launcher (kostra z `wiki_compile.py`): fs pre-check bez importu nanobota, lockfile se stale-reclaim, `Nanobot.from_config().run(DRAIN_GOAL)` (process_direct, **bez cron preamble** — proto systémový crontab, ne jobs.json), timeout 15 min. DRAIN_GOAL jmenuje skill → headless agent načte SKILL.md.
- `SKILL.md` přepsán (EN, dual-mode, sdílený compile workflow, URL přes `web` tool + paywall→`hard/`, search = celý `notes.md`). Description zpřesněn proti kolizi s `keep`.
- Lokální pytest (16, zelené). Starý `note.py` odstraněn z repa. Commity: `a8f1997` (plán), `afe05d8` (skill), `02f9e7a` (description/search fix).
- Nasazeno `rsync`, crontab řádek přidán (`* * * * * uv run …/note_compile.py`, každou minutu jako wiki/remind). Migrace: 17 aktivních notes → inbox seeding → první drain postavil `notes.md`. Starý `note.sqlite` → `backup/note-retired/`; stray `notes.db`/`note.py`/`__pycache__` smazány.

**Co fungovalo a proč:** První manuální drain 17 notes = **45 s**, `notes.md` s čistými sekcemi (DevOps, Chata, DT Glass, Work/ZOT…); **URL reálně stažena** (Jina Reader) — DT Glass expandováno na produkty s cenami/rozměry, obě URL bare na vlastních řádcích, žádná fabrikace. E2e přes reálného agenta: cron **auto-fire** (deferred zachyt zpracován do ~80 s), `/note <text>` **immediate** (routing → note skill, capture + inline compile → nová sekce), `/note search` (načte `notes.md`, odpoví). Vše zelené.

**Co zbývá / poznámky:** (1) **Kolize triggerů `note` vs `keep`:** NL „poznamenej si …" původně spadlo do `keep` (obě claimovaly „ulož si"). Fix: description zpřesněn (odstraněno „ulož si", přidán kontrast „NOT durable facts → keep"). Spolehlivý je explicitní `/note` prefix (ten routuje správně — ověřeno). Uživatel ať v Telegramu používá `/note …` / `/note cron …`. (2) Paywall detekce je prompt-driven, live paywall netestován (logika ověřena návrhem). (3) Compile běží na default presetu; volitelně jde přepnout na rychlejší. (4) Immediate režim blokuje tah 15–100 s a roste s velikostí `notes.md` — proto `/note cron` pro dávkové syp­ání.

**Jak vrátit zpět:** Repo: `git revert 02f9e7a afe05d8` (nebo `git checkout afe05d8~1 -- skills/note/`). Server: `git`-verzi note skillu `rsync`-ni zpět + obnov data `mv ~/.nanobot/workspace/backup/note-retired/note.sqlite ~/.nanobot/workspace/db/`. Crontab: `crontab -l | grep -v note_compile | crontab -` (smaž i komentář). `notes/` (notes.md, inbox/done/hard) lze smazat — původní data jsou v `backup/note-retired/note.sqlite`.

## 2026-07-01 11:35 — note: mazání s odsouhlasením + git commit `notes.md` po každé změně

**Cíl:** Doplnit do přepsaného `/note` (viz 10:40) dvě chybějící provozní věci, na které uživatel upozornil: (1) **mazání poznámek** — s tvrdým pravidlem, že model před smazáním vždy ukáže přesný text a čeká na odsouhlasení; (2) **verzování `notes.md`** — po každé změně `git add notes/` + `git commit`. Plán: `~/.claude/plans/u-nove-vytvoreneho-skillu-declarative-unicorn.md`.

**Klíčové zjištění (proč to bylo potřeba):** Workspace `~/.nanobot/workspace/` **je** git repo, ale commituje ho **jen Dream** (`dream: periodic memory consolidation`) a ten se `notes/` dotýkat nesmí. Ověřeno na serveru: celé `notes/` bylo **untracked** (`?? notes/`) → `notes.md` se nikdy necommitovalo. Žádný existující skill vlastní commit nedělá → vzor nový.

**Rozhodnutí (dotazy na uživatele):** Mazání = **přirozeným popisem** (žádná display ID / `/note list` — sedí na prózový návrh). Před smazáním **hard-gate**: ukázat verbatim text + čekat na „ano". Commit = `git add notes/` + `git commit` (verzuje se celé `notes/`, jen `.compile.lock` do `.gitignore`). **Jeden committer per cesta, žádné dvojité commity:** inline `/note <text>` a mazání → agent přes `exec`; cron drain → **deterministicky v Pythonu** v `note_compile.py`. Sdílený *Compile workflow* zůstává bez commitu (commit je odpovědnost volajícího). Prefix `note:` (konzistentní s `dream:`).

**Co jsem udělal:**

- `SKILL.md`: do `description` přidány delete trigger fráze (`smaž poznámku o X`, `zapomeň X`, `uprav poznámku o X`); do `/note <text>` krok commit přes `exec`; sekce `Delete / edit` přepsána na tvrdý dvoukrok (najdi → **ukaž přesný text + čekej na potvrzení** → surgical `str_replace` + commit; totéž pro edit; pending zachyt = smaž soubor v `inbox/`); nová sekce `Versioning (git)`.
- `note_compile.py`: `commit_notes(count)` — po úspěšném drainu (za drženého locku, `.compile.lock` je gitignored → nestaguje se) `git status --porcelain notes/` → prázdné = no-op; jinak `git add notes/` + `git commit -m "note: cron drain (N captures)"`. Nikdy `git add -A` (Dream vlastní zbytek). Chyba commitu se jen loguje (drain už uspěl, nesmí se hlásit jako fail).
- Testy `test_note_compile.py`: +3 (`commit_notes` vytvoří commit / no-op při čistém stavu / respektuje gitignored lock), fixture dostal `WORKSPACE`. **19 zelených** lokálně.
- Server `.gitignore`: přidán `notes/.compile.lock` **před** deployem (živý pid-lock držený během commitu do gitu nepatří) — commit `ad3337f`.
- Deploy `rsync` (`--exclude __pycache__`), owner `nanobot:nanobot` ✓.

**Co fungovalo a proč:** **E2E cron cesta ověřena na reálné infře:** seed testovacího zachytu (unikátní marker `ZZZTESTVERIFY…`, přímo do `inbox/` — ne přes capture, aby nešpinil `note.log`) → cron tik do ~80 s → agent zařadil do `notes.md` pod sekci, launcher udělal commit `note: cron drain (1 captures)`, `git status notes/` **čistý** (`.compile.lock` se nepletl → gitignore OK), cron log `END … COMMIT notes/ (1 captures)`. Tento první commit navíc **bootstrapnul celý dosud untracked `notes/` strom** (notes.md + 18 done souborů) — přesně očekávané. `git` je `/usr/bin/git` v2.47.3, `tools.exec` má prázdné `allowPatterns`/`denyPatterns` (git neblokovaný) + reálný workspace commit prošel → exec-git i launcher jsou spolehlivé. Úklid **forward** (bez přepisu historie): odstraněn testovací řádek + done soubor, commit `chore: remove note commit verification test` — marker pryč, `## Nanobot` sekce nedotčená. Serverové commity: `ad3337f` (.gitignore), `cffe3b3` (drain — bootstrap notes/), `5ed6832` (cleanup).

**Co zbývá:** Inline `/note <text>` commit přes `exec` a **mazání s odsouhlasením** nebyly spuštěny živě (LLM-driven; mazání navíc čeká na interaktivní potvrzení → nejde smysluplně headless). Vysoká jistota ze statického ověření (git dostupný, exec bez denylistu, workspace commit funguje) — dořeší reálné použití přes Telegram (`/note …` / „smaž poznámku o …"). Poznámka: `git add notes/` verzuje i `done/` → historie poroste (dle přání uživatele; případné prořezání mimo rozsah).

## 2026-07-01 — note/keep/bookmark: zpřesnění description o vzájemné hranice (routing)

**Cíl:** Dispatcher nanobota má jednoznačně poznat, kam vstup patří — `note`, `keep` a `bookmark` mají překrývající se doménu (poznámka vs. fakt vs. URL na přečtení). Vykonání schváleného plánu: doplnit do `description` všech tří skillů explicitní hranice vůči sousedům.

**Co jsem zkusil:** Server byl před editací ověřen jako shodný s lokálem (žádný Dream zásah), takže editace šla přímo do lokálního repa bez tahání ze serveru. Tři exact-string úpravy `description`:

- `skills/keep/SKILL.md` — nově explicitně „durable personal facts, preferences, and decisions" + „NOT collecting notes, links, or articles (that is note)".
- `skills/note/SKILL.md` — poslední dva řádky přeformulovány na „reference material you file and later query" + „NOT durable personal facts, preferences, or decisions (that is keep), and NOT a bare URL you just want to read later (that is bookmark)".
- `skills/bookmark/SKILL.md` — doplněno „NOT filing or summarizing content into a knowledge base (that is note)".

**Co fungovalo a proč:** První pokus o editaci `note/SKILL.md` selhal (`old_string` s pouze poslední dvěma řádky nebyl v souboru nalezen), oprava — rozšířil jsem `old_string` o předchozí kontextový řádek, čímž byl znovu jednoznačný, a editace prošla; obsah po opravě odpovídal plánu přesně. Nasazeno `rsync -av` (celé adresáře, ne jen `SKILL.md`) na server přes IP `192.168.4.64` (hostname `nanobot.hell` se z tohoto stroje nerozeznává) pro všechny tři skilly. Vlastník na serveru ověřen `ls -l` — všechny tři `SKILL.md` `nanobot:nanobot`. Zpětné stažení serverových `SKILL.md` a `diff` proti lokálu — pro všechny tři soubory prázdný diff (plná shoda). Skilly se čtou při každém tahu bez restartu služby, takže zpřesnění je live okamžitě.

**Co zbývá:** Nic — nasazeno a ověřeno. Behaviorální potvrzení (že dispatcher skutečně routuje lépe na hraničních vstupech) přijde z reálného použití přes Telegram/WebUI.

**Jak vrátit zpět:** Repo: `git checkout HEAD~1 -- skills/note/` (vrátí SKILL.md + launcher + testy). Server: `rsync` starší verzi skillu zpět; `git.gitignore` řádek `notes/.compile.lock` odstranit + `git revert ad3337f`. Feature je aditivní — necommitování `notes.md` je návrat k původnímu chování (Dream se `notes/` stejně nedotýká).

## 2026-07-01 12:00 — note: bug při `/note delete` (hledal v SQL DB, neptal se, mazal done) → hardening SKILL.md

**Cíl:** Uživatel po nasazení mazání hlásil, že `/note delete zot dokumentace` (a) se na nic nezeptalo, (b) smazalo i soubor v `done/`, (c) agent se to snažil hledat v SQL DB. Najít příčinu (systematic-debugging), pak opravit.

**Co jsem zjistil (z reálné stopy `sessions/websocket_*.jsonl`):** Přesná sekvence tahu: agent paralelně `read_file SKILL.md` **a zároveň** `grep "zot" v db/` → `exec sqlite3 db/notes.sqlite "SELECT … FROM notes WHERE …"` (tím **vytvořil prázdný `db/notes.sqlite`**) → `.tables` → `find_files db` → teprve pak `grep *.md` → našel v `notes.md` + `done/…zot.md` → `edit_file` + `rm done` **bez potvrzení**. Reasoning: *„Let me check the notes database more carefully."* **Příčiny:** (1) model má silný prior „`/note delete` = smaž řádek v notes DB" (chování STARÉHO SQLite note skillu) + `AGENTS.md` konvence „SQLite do `db/*.sqlite`"; (2) `SKILL.md` **nikde nezakazoval** DB/sqlite a **nedokumentoval `/note delete`/`/note edit` jako příkazy** → model spadl do starého vzoru; (3) potvrzovací brána byla jen „prozaická", ne tvrdá STOP jako u `/note cron`. **NENÍ to stará paměť:** `MEMORY.md` note nezmiňuje, `history.jsonl` (kde stará „note=sqlite" lekce je, ř. 344) agent per-tah nečte (jen Dream) — je to prior modelu + slabý model (kimi/glm třída).

**Fix (SKILL.md hardening, per rozhodnutí uživatele „done/ nechat jako interní"):**

- **Anti-DB callout** v Architecture: „No database — ever … never search `db/`, never run `sqlite3`, never create/open `.sqlite`/`.db`; AGENTS.md SQLite konvence se na notes nevztahuje; starší verze DB měla, je pryč." Přímo proti krokům ze stopy.
- **Delete/edit přepsán** na `## /note delete <query> / /note edit <query>` (mapování na příkaz, který uživatel reálně napsal) + **tvrdá dvou-tahová STOP brána** (vzor z `/note cron`, který prokazatelně funguje): Turn 1 = najdi **jen v `notes.md`** (zákaz db/sqlite/inbox/done/hard) + ukaž verbatim text + **STOP the turn** (zakázáno `str_replace`/`rm`/`git`); Turn 2 = teprve po explicitním „ano" smaž + commit. **Mazání se dotýká jen `notes.md`, NE `done/`** (breadcrumb je interní plumbing).
- Úklid: smazán prázdný `db/notes.sqlite` (0 B, artefakt chybného SQL pokusu) — jeho existence agenta utvrzovala v mylné víře (`find_files db` → notes.sqlite).

**Co fungovalo:** Deploy `rsync` (jen SKILL.md), owner `nanobot:nanobot` ✓, oba fixy v nasazeném souboru ověřeny grepem. Skill se čte per-tah bez restartu → příští `/note delete` běží na opravené verzi.

**Co zbývá:** Behaviorální potvrzení dělá uživatel (příští `/note delete` musí: hledat jen v `notes.md`, ukázat text, zastavit a čekat, nesahat na `done/`). U slabšího modelu STOP brána riziko silně snižuje, ale negarantuje 100 %. Poznámka: smazaná poznámka „ZOT dokumentace" byla reálná (ne testovací) — jde obnovit z gitu (`git show cffe3b3:notes/notes.md`), nabídnuto uživateli.

**Jak vrátit zpět:** Repo `git checkout HEAD~1 -- skills/note/SKILL.md`, pak `rsync` na server. (Aditivní/behaviorální změna — revert jen oslabí brány, nerozbije data.)

## 2026-07-01 12:15 — note: čeština v SKILL.md + zbytečné `/note` varianty v description

**Cíl:** Uživatel v IDE otevřel `skills/note/SKILL.md` a upozornil na dvě věci: (1) v souboru je čeština, ačkoli EN-only pravidlo je explicitní v projektovém `CLAUDE.md`; (2) proč description obsahuje `/note X`/`/note cron X` varianty, když nanobot ví, jak skill spustit. Požádal i o celkovou kontrolu kvality promptu.

**Co jsem zjistil:** Čeština byla na 4 místech (description trigger fráze + 3 místa v těle — cron potvrzení, delete/edit triggery, potvrzovací slova Turn 2). Pro otázku 2 jsem našel přímý podklad v `knowledge.md` („Skill description — k čemu reálně slouží"): description je čistě routing signál (kdy/proč, ne jak) a viditelný jako jeden řádek `- **note** — <description>`, kde jméno skillu je vždy vidět — `/note X` a `note X` tedy nic nerozlišují nad rámec samotného jména, a `/note cron X` je navíc detail subakce („jak"), ne routing info. Sesterský `bookmark` (upravovaný ve stejném committu jako `note`) tento princip u slash-forem už dodržuje.

**Co fungovalo a proč:** Oprava description (odstraněny CZ fráze + `/note X`/`/note cron X`, zachována jen anglická disambiguace od `keep`/`bookmark`) + 3 CZ místa v těle převedena na anglické ekvivalenty + doplněn jazykový tag ```text``` k fencovanému stromu adresářů (chybějící dle `markdown-style.md`). Uživatel si mezitím sám upravil první větu description na „Capture notes, texts, ideas…" — necháno beze zásahu. Vedlejší nález: `fix-markdown.ps1` hook po Edit tahu měnil emphasis z hvězdiček na podtržítka (`*only*`→`_only_`, `*Versioning*`→`_Versioning_`) — v rozporu s `markdown-style.md` („Never underscores"); opraveno zpět, hook to už neměnil zpátky. Nasazeno na server: hostname `nanobot.hell` se z tohoto stroje nerozeznává (`Could not resolve hostname`), IP `192.168.4.64` z `CLAUDE.md` funguje. Server byl před přepisem ověřen jako identický s předchozím lokálem (žádný Dream zásah) — `rsync -av` bezpečný. Po nasazení `diff` server↔lokál prázdný, owner `nanobot:nanobot` ✓.

**Co zbývá:** Stejný „zbytečná /command varianta" vzor mají i `keep` (`/keep X`), `remind` (`/remind`) a `plan` (`/plan X`) — mimo scope tohoto zadání (uživatel se ptal jen na `note`), zmíněno uživateli jako volitelný follow-up, nikam nezapsáno jako todo (čeká na rozhodnutí, jestli o to stojí).

**Jak vrátit zpět:** Repo `git checkout HEAD~1 -- skills/note/SKILL.md`, pak `rsync` na server (IP `192.168.4.64`).

## 2026-07-01 19:33 — note: doplnění diakritiky při reformulaci + echo přesného uloženého textu

**Cíl:** Uživatel chtěl dvě vylepšení `/note`: (1) když napíše text bez diakritiky, skill má diakritiku při reformulaci doplnit; (2) u okamžitého režimu (`/note <text>`) má potvrzovací zpráva ukázat přesný zapsaný text, ne jen název sekce. Přes plan mode (Explore + diff proti serveru) potvrzeno, že jde jen o immediate mode — `/note cron` v daném tahu nic nereformuluje, takže echo tam nedává smysl.

**Blocker a jeho vyřešení:** SSH na `nanobot.hell` (pod `nanobot` i `root`, stejný klíč) nejdřív padalo na `Permission denied (publickey,password)` a lokálně chyběl `rsync` — sandbox tohoto sezení neměl potřebný klíč/nástroj. Uživatel obojí mimo tuto session doplnil („uz funguje, opravil jsem to" / „uz jsem dodal i rsync"), pak SSH i rsync fungovaly bez úprav z naší strany.

**Co fungovalo a proč:** V `skills/note/SKILL.md` (1) bod „Reformulate" v Compile workflow rozšířen o instrukci: text bez diakritiky (příklad „kdyz uz to psal bez hacku") se při reformulaci opraví na spisovnou diakritiku, už-diakritizovaný a ne-český text se nechá být; (2) krok 5 v `/note <text>` nahrazen tak, aby kromě sekce citoval i doslovný zapsaný text (verbatim, ne převyprávění). Před přepisem staženo `rsync` ze serveru a porovnáno s lokálem — server měl starší, ale skriptově identickou verzi (chyběly jen předchozí neasazené kosmetické commity popisu, žádný Dream zásah) → bezpečné nahradit celý adresář. Nasazeno `rsync -av skills/note/` (celý adresář, vč. `scripts/`, `tests/`), owner `nanobot:nanobot` ověřen.

**Co zbývá:** Ruční test v chatu — `/note psal jsem bez hacku a carek` (diakritika v `notes.md`) a `/note <krátký text>` (potvrzení obsahuje přesný zapsaný text). Po ověření přesunout z `todo.md`/nezapsáno jako todo, protože šlo o přímé zadání bez čekání ve frontě.

## 2026-07-02 15:25 — bookmark: archivace plného textu článku jako čistý markdown

**Cíl:** Uživatel se zeptal, co skill `bookmark` udělá, když vloží URL a k tomu celý zkopírovaný článek (Ctrl+A/Ctrl+C). Zjištěno, že skill neměl žádné pravidlo — celý neočištěný článek by teoreticky přistál do `description` (`TEXT` bez limitu) a rozbil formát výpisů. Zadání: skill má rozpoznat plný článek, vyčistit ho (navigace, menu, reklamy, patičky), převést na markdown a uložit; `description` si dogenerovat sám, pokud ho uživatel neuvede.

**Klíčové zjištění (přes plan mode, 2× Explore agent):** Novou pip závislost (markdownify/trafilatura) na server **nedostanu** — bwrap sandbox na bare-metal `nanobot.hell` nemá přístup k uv cache/data adresářům (`knowledge.md` ř. 615–634), balíčky by při stahování padaly. Proto **čištění a převod do markdownu dělá agent (LLM)** na úrovni instrukcí v `SKILL.md`, skript zůstává **stdlib-only**. Precedent pro echo uloženého textu už existuje v `/note` (commit 739b9c8) — přejat.

**Co fungovalo a proč:**
- `bookmark.py`: schéma rozšířeno o nullable `content TEXT` + idempotentní migrace v `_init_db` (`PRAGMA table_info` → `ALTER TABLE ADD COLUMN`, protože `CREATE IF NOT EXISTS` sloupec do existující DB nepřidá). `add --content-file <path>` (`-` = stdin, agent volá přes heredoc `<<'ARTICLE'` — jedno atomické volání, žádné shell-escapování). Nový `content <id>` vypíše uložený markdown. 📄 marker v `list`/`history`/`show` u bookmarků s obsahem (SELECT tahá `content IS NOT NULL AS has_content`, ne celý blob).
- Migrace ověřena na **kopii reálné serverové DB** (11 řádků) před nasazením — všech 11 řádků zachováno, `content` přidán jako NULL. ALTER ADD COLUMN je nedestruktivní.
- Testy `skills/bookmark/tests/test_bookmark.py` (6×, vzor z `note`): migrace legacy DB, add s/bez obsahu, `content` příkaz, 📄 marker. Všechny zelené.
- `SKILL.md`: nová sekce „Saving an article's full text" (detekce + čištění + heredoc + echo verbatim), pravidlo pro URL bez textu (zkus `web`/Jina Reader, ale paywall/nesmysl NEUKLÁDAT, `⚠ paywall/incomplete`, nefabrikovat), `content` příkaz, marker v Output formatting, rozšířený Workflow.
- Před zásahem dotažena serverová drift úprava frontmatteru (`NOT ... (that is note)`) do repa (samostatný commit) — server byl zdroj pravdy.
- Nasazeno `rsync -av skills/bookmark/`, owner `nanobot:nanobot` ✓ (omylem nahrané `__pycache__` uklizeny na serveru i lokálně). End-to-end na serveru přes heredoc: obsah uložen, 📄 naskočil, `content 1` vypsal přesný markdown vč. zachované diakritiky. Testovací řádek pak smazán z reálné DB přes `sqlite3` (skill nemá delete příkaz) → zpět na 11 řádků.

**Co zbývá:** Behaviorální ověření dělá uživatel v chatu — vložit URL + článek a zkontrolovat, že agent text vyčistí, uloží a odcituje verbatim úsek; otestovat i URL-only (fetch) a paywall (neuloží obsah). Známé omezení: `content <id>` čte jen z **unread** setu (jako `show`) — obsah už přečtených bookmarků z `history` zatím nedostupný.

**Jak vrátit zpět:** Repo `git checkout HEAD~1 -- skills/bookmark/` + `git rm skills/bookmark/tests/`, pak `rsync` na server. Migrace DB je aditivní a nedestruktivní — `content` sloupec může na serveru zůstat (ignoruje ho starší verze skriptu). Data v `content` by revert skriptu zneviditelnil, ne smazal.

## 2026-07-02 17:00 — bookmark: soft delete, HTML→markdown utilita (trafilatura), fetch-fail výzva

**Cíl:** Tři navazující požadavky na `bookmark` (přes plan mode, opakované AskUserQuestion): (A) když se nepodaří stáhnout obsah URL, agent si má o vložení článku sám říct; (B) delete pro mazání článků (omylem vložený duplikát); (C) když je vložený obsah HTML, převést ho na markdown Python utilitou, ať to nedělá drahý model.

**Klíčová oprava předpokladu:** U hlavní feature (viz záznam 15:25) jsem tvrdil, že bwrap sandbox nepustí pip závislost. **Ověřeno naživo — na `nanobot.hell` to neplatí:** produkční `exec` běží `"sandbox": ""` (bez bwrap), `uv` + PyPI fungují, `uv run --with trafilatura` stáhne a naimportuje (v2.1.0). Jiné skilly reálně jedou se závislostmi (remind→croniter, llm-wiki→pyyaml). Bwrap limit z `knowledge.md` ř. 615–634 platí jen pro nasazení se zapnutým sandboxem. → doplněna korekce do `knowledge.md`.

**Rozhodnutí uživatele (AskUserQuestion):** delete = **jen soft delete** (flag `deleted_at`, skryje z výpisů, řádek zůstává v DB; **bez** restore/deleted příkazů) + **potvrzení před smazáním** (řeší agent). HTML převod: uživatel navrhl markitdown; ověřeno ze zdrojáku, že markitdown pro HTML = markdownify (převede celé `<body>`, **neodstraní boilerplate**) + těžší (magika/onnxruntime) → dominovaná. Zvolena **trafilatura** (odstraní boilerplate A vrátí markdown v jednom kroku). Plain text: model čistí **jen při zjevném balastu**. Detekce HTML: **rozhodne agent**.

**Co fungovalo a proč:**
- `bookmark.py`: `deleted_at TEXT` + migrace (idempotentní ALTER, vzor jako `content`); `AND deleted_at IS NULL` do obou větví `_ordered_ids` + přímých SELECTů v `list`/`history` (žádný „subset" refaktor — unread/read je jen negace `read_at`, na připomínku uživatele); nový `cmd_delete` (soft, resolve z unread setu). Potvrzení je záměrně na úrovni agenta (SKILL.md), ne skriptu.
- `html_to_markdown.py`: nový PEP 723 helper (`dependencies=["trafilatura"]`, shebang `uv run --script`), stdin HTML → stdout markdown; prázdný vstup exit 1, nic neextrahováno exit 2. Agent ho **pipe-uje** do `bookmark.py add … --content-file -` → převedený markdown teče shellem, **neprochází kontextem modelu** (levné). Když trafilatura nic nevrátí → prázdný content → NULL → fallback na čištění modelem.
- `SKILL.md`: rozcestník HTML (pipe helper) vs plain text (uložit rovnou, čistit jen při balastu); delete + potvrzovací flow + display-ID caveat; při paywallu/nezdaru stažení agent **požádá uživatele o vložení článku** místo tichého fallbacku.
- Testy (10× zelené): soft delete (skryje, řádek zůstává), delete out-of-range, migrace `deleted_at`, `html_to_markdown` extrakce (boilerplate pryč, `#`/`##` nadpisy) + prázdný vstup. Lokálně ověřeno i na realistickém HTML (nav/reklama/patka odstraněny) a exact pipe konstrukt.
- Migrace `deleted_at` ověřena na kopii reálné serverové DB (16 řádků zachováno, NULL). Nasazeno `rsync -av --exclude=__pycache__`, owner `nanobot:nanobot`. E2E na serveru: HTML pipe → `content 1` vrátí čistý markdown; `delete 1` → soft (`deleted_at` set, řádek v DB). Testovací řádek pak hard-smazán přes `sqlite3` → zpět 16.

**Co zbývá:** Behaviorální ověření uživatelem v chatu (agent má u HTML pipe-ovat helper, u plain textu čistit jen při balastu, u paywallu požádat o vložení, před delete potvrdit). Známá omezení: `delete`/`content` jen z unread setu (`list`), ne z `history`; žádný restore (soft-smazané jen ručně přes DB); trafilatura potřebuje realistickou stránku — na drobném snippetu boilerplate nepozná (fallback na model to řeší).

**Jak vrátit zpět:** Repo `git revert` skill committu + `rsync` na server. Migrace (`deleted_at`) aditivní/nedestruktivní — sloupec může na serveru zůstat. Soft-smazané řádky mají `deleted_at` set; revert skriptu je zase zviditelní (data se neztratí).

## 2026-07-06 — remind: deterministická pojistka proti duplicitnímu textu + steering

**Cíl:** `/remind` občas místo jednoho reminderu s víc časy založil víc samostatných reminderů se stejným textem. Nanobot (Dream) na to reagoval přidáním jednoho příkladu do serverového `SKILL.md`. Uživatel se ptal, jestli to stačí — po rozboru padlo rozhodnutí přidat i tvrdou pojistku: jeden text nikdy nepotřebuje víc záznamů, takže `add`/`edit` mají duplicitu odmítat chybou.

**Důkaz příčiny (ne bug v kódu):** Serverový `log/reminder.log` — „UFO burger" `id=46` (18:00) + `id=47` (07:00) 7 s po sobě (split jednoho zadání); dřív totéž „note #work" `id=41/42/43`. CLI mechanismus byl přitom vždy správný: `--at`/`--cron` jsou `action="append"`, `insert_schedules` vloží všechny naráz → `add --at X --at Y` = jeden reminder, dva časy. Příčina = chování agenta, který zadání rozdělil do víc `add` volání.

**Co jsem udělal:**
- `store.py`: `find_active_by_exact_text(conn, text, exclude_id=None)` — porovnání Python-side `casefold()` na trimnutém textu (ne SQL `lower()`, to v SQLite nefolduje unicode diakritiku → „Čaj"/„čaj" by prošlo).
- `remind_cli.py`: helper `_reject_duplicate_text` (vrací `{"error":"duplicate text", display_id, hint}` na stderr, exit 1). Zapojen v `cmd_add` (před transakcí) a `cmd_edit` (při změně textu, `exclude_id=rid` → přejmenování na vlastní text projde). Hint navádí na recovery po splitu: `edit --id N --replace-schedules` se všemi časy.
- `SKILL.md`: do mapovací tabulky přidán cron multi-time řádek (`--cron … --cron …`), zachován serverový `--at`/`--at` příklad (dotažen do repa); do Behavioral contract explicitní pravidlo „jeden text = jeden reminder".
- Testy: 3 nové (`test_add_rejects_duplicate_text`, `test_add_duplicate_case_and_diacritics_insensitive`, `test_edit_text_collision_rejected`); 2 existující dup testy (`test_remove_by_id_disambiguates_duplicates`, `test_ambiguous_keyword_returns_display_ids`) staví duplicitu přes nový helper `_seed_duplicate` (přímý `store.insert_reminder`, obchází guard) — disambiguace pre-existujících dupů zůstává validní.

**Co fungovalo a proč:** 83 testů zelených. Lokální smoke (temp `REMIND_DB`): add#1 OK, add#2 stejný text → odmítnut (exit 1, display_id, hint), správná cesta `add --at … --at …` → jeden reminder se dvěma `at`. Před deployem ověřeno, že serverové skripty == git HEAD (žádná autonomní divergence Dreamem), SKILL.md se lišil jen o ten jeden `--at` řádek (dotažen). Nasazeno `rsync -av skills/remind/`, owner `nanobot:nanobot` ✓. Server == lokál u všech změněných souborů. Na serveru jsem mutace nespouštěl (`log_operation` ignoruje `REMIND_DB` → zapsalo by do reálného `reminder.log`).

**Co zbývá:** Zápis do `decisions.md` (návrh připraven, čeká na formulaci autora — ruší dosavadní rámování „duplicitní texty povoleny by design"). Behaviorální ověření dělá uživatel v chatu.

**Jak vrátit zpět:** Repo `git revert 61e7068` + `rsync` na server. Změna je čistě logika CLI (žádná migrace DB), revert je bezpečný.

## 2026-07-15 — sync skillů ze serveru: bookmark autonomně upravený Dreamem

**Cíl:** Uživatel požádal o obecný sync skillů ze serveru do repa (bez upřesnění, který). Podle pravidla v `CLAUDE.md` („server je zdroj pravdy") jsem prošel checksumem všechny lokální skilly proti serveru před jakýmkoli přepisem.

**Co jsem zkusil:** `rsync --dry-run --checksum --itemize-changes` pro každý skill (`article`, `bash`, `bookmark`, `deep-research`, `detach`, `grill-me`, `keep`, `llm-wiki`, `note`, `plan`, `python`; `remind` ověřen zvlášť plným stažením a `diff -rq`).

**Co fungovalo a proč:** `remind` beze změny (server == lokál, potvrzuje předchozí záznam). `detach` a `llm-wiki` hlásily rozdíl jen v mtime (`.f..t......`, bez `c`/`s`) → obsah identický, ignorováno. `bookmark/SKILL.md` měl skutečný obsahový rozdíl (`>fcst......`) — server má autonomní úpravu (pravděpodobně Dream): (1) přehozené pořadí ve formátu výpisu — `<description>` teď před `[<tags>]`, ne za nimi; (2) nová sekce „Known limitations" (chybí `edit`/`update`, `delete` je jen soft-delete, weby za Cloudflare nejdou auto-fetchnout). Stáhl jsem přesně tuto verzi do `skills/bookmark/SKILL.md`, ověřeno `diff` na 100% shodu.

**Co zbývá:** Server != repo u `keep` (SKILL.md) — dry-run to ukázal, ale nebylo součástí zadání, needitoval jsem. Zvážit v příští session. Drobná nekonzistence, kterou sync odhalil a nechal beze změny: příklad výpisu na řádku `#3 [hackaday.com](...) [linux, strace] — lepší strace` v `bookmark/SKILL.md` neodpovídá nově popsanému formátu (description by měl být před tagy) — je to takto i na serveru, nešlo o repo vs. server rozdíl, takže jsem to nepravil bez zeptání.

## 2026-07-15 — compact-memory-auto-daily: diagnóza "podivných hlášek" na Telegramu + migrace na crontab s čerstvou session

**Cíl:** Uživatel hlásil podivné/nesmyslné hlášky na Telegramu z posledních dní; v noci má běžet `compact-memory` z cronu, ale něco je špatně. Nejdřív jen prozkoumat (bez zásahu), pak — po potvrzení, že denní doručení je záměr — opravit kontaminaci kontextu.

**Diagnóza (nainstalovaný `nanobot-ai` v0.2.2):** Cron job `compact-memory-auto-daily` (`jobs.json`, id `69484aa6`) byl `agent_turn` s `payload.session_key = "telegram:8826147089"` — **stejná trvalá session jako běžný Telegram chat** (potvrzeno v `sessions/telegram_8826147089.jsonl`: 75/77 zpráv obyčejná konverzace, jen 2 cron marker). `is_bound_cron_job`/`run_bound_cron_job` (nahrazuje starý "hardcoded reminder preamble + evaluate_response" mechanismus popsaný výše v knowledge.md pro starší verzi) doručuje odpověď **bez jakéhokoli gatingu** — cokoli agent v tahu napíše, jde přímo do Telegramu. Navíc `origin_delivery_context` (kam se doručí) je **nezávislé** na `session_key` (do jaké session/historie se zapíše) — to je klíč k opravě. 2026-07-14 se agent v cron tahu spletl a pokusil se spustit neexistující `scripts/compact_memory.py` (skill ho nikdy neměl mít), napsal do chatu zmatenou zprávu, uživatel ho opravil ve stejné session — a protože session je trvalá, ten omyl kontaminoval i další noci (přesně text, co uživatel citoval jako "podivnou hlášku", je z nočního běhu 2026-07-15 02:00).

**Řešení (schváleno přes plan mode):** Migrace na vzor `/remind`/`detach` — systémový crontab + samostatný skript mimo nanobot `cron/jobs.json`, s **unikátní `session_key` per běh** (nikdy znovu použitý → nikdy žádná akumulace historie), doručení přímo přes Telegram Bot API (mimo nanobot channel pipeline).

**Co jsem udělal:**
- Stáhl `skills/compact-memory/SKILL.md` ze serveru do repa poprvé (skill dosud nebyl trackovaný lokálně) + přidal větu "This skill has no accompanying script — every step below is performed by you, the agent..." — cílená prevence přesně té 07-14 halucinace.
- Nový `skills/compact-memory/scripts/compact_memory_auto.py` (PEP 723, vzor `tasks-daemon.py`/`remind_send.py`): `Nanobot.from_config().run(GOAL, session_key=f"compact-memory-auto:{timestamp}")` s 10min timeoutem, výsledek poslán přímo `urllib` na Telegram Bot API (token/chat_id z `config.json`, stejný `_telegram_config()` vzor).
- Nasazeno `rsync -av skills/compact-memory/` (celý adresář), owner `nanobot:nanobot` ✓.
- Přidán řádek do system crontabu (`0 2 * * * uv run .../compact_memory_auto.py >> log/compact_memory_auto_cron.log`), stávající 3 řádky (remind/wiki-compile/note-compile) nedotčené.
- Odebrán job `69484aa6` z `jobs.json` (in-place Python edit, bez restartu — zbylé 3 joby beze změny).
- Opravena zastaralá věta v serverovém `memory/MEMORY.md` (psala, že job běží v Telegram session — teď už neplatí).

**Co fungovalo a proč:** Ruční test skriptu na serveru proběhl čistě (exit 0): reálný audit MEMORY.md (32 řádků), skutečně smazal 1 duplicitu a sloučil 2 dvojice, zapsal zálohu do `backup/2026-07-15_0541_memory.backup.md` i do `log/memory-clean.log`, report doručen do Telegramu. Ověřeno, že vznikla **nová izolovaná** session `sessions/compact-memory-auto_20260715-054147.jsonl` a `telegram_8826147089.jsonl` zůstal nedotčený (78 řádků beze změny) — potvrzuje, že `session_key` a `origin_channel`/`origin_chat_id` jsou v `nanobot-ai` 0.2.2 opravdu nezávislé, přesně jak ukázala explorace zdrojáku.

**Co zbývá:** Počkat na první reálný noční běh (příští 2:00) a ověřit stejné chování automaticky. Navrhnout uživateli větu do `decisions.md` (čeká na formulaci autora): "Nanobot `agent_turn` cron joby pro neinteraktivní/background úlohy vždy mimo `jobs.json`, přes systémový crontab + přímé `Nanobot.run()` s per-run unikátní `session_key` — stejný vzor jako `/remind` a `detach`." Zvážit doplnění knowledge.md o `is_bound_cron_job`/`origin_delivery_context` mechanismus 0.2.2 (nahrazuje starší popsaný "hardcoded preamble + evaluate_response" — ten je teď verzí-specifický/zastaralý).

**Jak vrátit zpět:** V `jobs.json` přidat job `69484aa6` zpět (zálohovaný obsah je v git historii commitu před touto změnou), odebrat řádek z crontabu (`crontab -e`), smazat `skills/compact-memory/scripts/compact_memory_auto.py`. Migrace `MEMORY.md` (smazaná duplicita, sloučené bullet) je nedestruktivní — plný snapshot je v `backup/2026-07-15_0541_memory.backup.md` na serveru.

## 2026-07-22 — nový skill `project` (nahrazen netrackovaný server-side skill, migrace `radio-1`)

**Cíl:** Uživatel chtěl nový skill `project`, analogii Claude.ai "Projects" — pojmenované dlouhodobé pracovní kontexty s vlastním promptem, historií a artefakty. Plánováno v plan mode: prozkoumáno 13 existujících skillů + `knowledge.md` pro konvence (`description` = jen routing signál s "Triggers on:", cesty workspace-relativní, žádný sticky session-state u nanobota). Uživatel v review odmítl jmenovat konkrétní jiné skilly v description/těle (odlišení jen funkčně) a trval na tom, že skill smí zakládat nový projekt jen po explicitním potvrzení, nikdy automaticky. Přidán čtvrtý soubor `state.md` (živý, přepisovaný dokument "kde to teď je") vedle append-only `memory.md`.

**Co jsem zkusil:** Před nasazením (pravidlo "server je zdroj pravdy") jsem ověřil `~/.nanobot/workspace/skills/project/` na serveru — **a objevil tam už existující, plně funkční `project` skill, nikde v tomto repu netrackovaný** (žádná zmínka v `history.md`/`knowledge.md`/`decisions.md`, žádná git historie k `skills/project/`). Starý design: plochý soubor `projects/<slug>.md` s YAML frontmatterem (`status: active|paused|done`, `priority: high|medium|low`), tělo se sekcemi `## Poznámky`/`## Další krok`, CLI backend `scripts/project.py` (add/list/show/status), `switch` ukládající aktivní projekt do `my(action="set", key="project_context", ...)` scratchpad nástroje, frontmatter měl i `aliases: [proj]`. Existovala reálná data: `projects/radio-1.md` (založeno 2026-06-09, projekt na stříhání audio streamu Radia 1).

**Co fungovalo a proč:** Zastavil jsem se a nechal uživatele rozhodnout (AskUserQuestion) — odpověď: přepsat novým designem, `radio-1` migrovat na `radio1`. Provedeno: `rsync -av --delete skills/project/ nanobot@...` (smazal starý `scripts/project.py`, nahradil `SKILL.md` novým), obsah `radio-1.md` ručně rozparsován do nového formátu — dated bullet z `## Poznámky` → `projects/radio1/memory.md`, cíl+stav+priorita syntetizovány do `projects/radio1/state.md`, `prompt.md` prázdný (nic k migraci), `artifacts/` prázdný adresář — nahráno přes `rsync` do `~/.nanobot/workspace/projects/radio1/`, starý `projects/radio-1.md` smazán. Ověřeno vlastnictví `nanobot:nanobot` u všech nových souborů/adresářů.

**Co zbývá:** Ověřit na živém chatu, že skill funguje end-to-end (aktivace, switch, ukončení, listing, zápis do `memory.md`/`state.md`) — zatím jen nasazeno a data migrována, ne vyzkoušeno v konverzaci. Zvážit zápis do `knowledge.md`: nanobot má `my(action="set"/"get", key=..., value=...)` scratchpad nástroj pro perzistentní stav napříč tahy (starý skill ho používal pro `project_context`) — objeveno náhodou, nebylo součástí dřívějšího průzkumu "nanobot nemá sticky session-state"; stálo by za ověření zdrojáku, jak přesně `my` funguje (per-session, nebo globální — starý skill sám poznamenává "lost on restart", žádnou zmínku o per-session scoping). Navrhnout `decisions.md` zápis (viz níže, čeká na souhlas autora).

**Jak vrátit zpět:** Stará verze skillu (`SKILL.md` + `scripts/project.py`) je stažená v `tmp/server-project-check/` (negitované, lokální). Obsah `radio-1.md` je beze změny zachycen ve stejném adresáři přes `git show`/`cat ~/.nanobot/workspace/projects/radio1/memory.md`+`state.md` (sloučit zpět ručně). Žádná záloha stažené staré verze v gitu — je jen v `tmp/`, které je gitignored; pokud má mít trvalou stopu, je potřeba ji dodatečně zkopírovat mimo `tmp/`.

## 2026-07-22 — nový projekt `life` založen na serveru

**Cíl:** Uživatel chtěl na serveru přes skill `project` založit dlouhodobý projekt `life` — osobní průvodce/deníček k udržitelnému životnímu stylu (cvičení, běh, jídelní návyky, skloubení s rodinou a dítětem), kam si bude průběžně zapisovat úvahy. Primární cíl projektu: změna váhy + dobrá kondice.

**Co jsem zkusil:** Ověřil stav serveru (skill `project` nasazený a identický s repem, existoval jen `radio1`, žádný `life`). V plan mode přes AskUserQuestion vyjasnil scope. Rozhodnutí uživatele: jídlo řešit jako návyky (večerní jedení, sladké), NE počítat kalorie ani zapisovat jídlo (kalorické tabulky má stranou); oblasti navíc = alkohol + protahování/mobilita (dělá po běhu, chce integrovat pravidelněji); cvičení (vlastní váha/kettlebell) i běh zatím nepravidelné; pokrok sleduje denním vážením + vnímanou kondicí a bolestmi; role agenta = průvodce/deníček, přístup se bude zpřesňovat; do `artifacts/` jdou prohřešky a reálné překážky.

**Co fungovalo a proč:** Připravil 4 soubory lokálně ve scratchpadu a nasadil `rsync -av scratchpad/life/ nanobot@nanobot.hell:.../projects/life/` — `prompt.md` (kontext + oblasti + kam co zapisovat + „první session" checklist), `state.md` (skeleton výchozího stavu/cílů), `memory.md` (první záznam se založením), `artifacts/prekazky-a-prohresky.md` (prázdný starter). Ověřeno: strom 4 soubory + adresář, vše `nanobot:nanobot`. Skilly/projekty se čtou bez restartu služby.

**Co zbývá:** Vyzkoušet v živém chatu aktivaci („projekt life" → načtení `prompt.md`). Výchozí čísla (aktuální váha, časový rozpočet, cílová váha/horizont) doplní uživatel v první session — záměrně nevyplněno (skill: nefabrikovat obsah). Projekt žije jen na serveru, do repa se necommituje (stejně jako `radio1`).

---

## 2026-07-25 — compact-memory: zkrácení nočního reportu (jeden řádek při nule) + append-only fix logu

**Cíl:** Noční běh `compact-memory` (crontab `0 2 * * *`) posílal na Telegram 700–1300 znaků i v nocích, kdy nic nesmazal. Uživatel: při nule stačí věta „nebylo nic k smazání", při reálné změně stačí *co* bylo smazáno/sloučeno a *proč*. Frekvence zůstává.

**Diagnóza:** Server = repo (`diff` čistý, žádný drift). Poslední 4 noci (07-22…07-25) všechny `deleted: 0, merged: 0` a přesto narativní walkthrough sekce po sekci + statistický code block + „Borderline kept". Čtyři zdroje, všechny předepsané:

1. `SKILL.md` Auto mode krok 4 — „Print a detailed list of changes."
2. `SKILL.md` Output format → Auto mode report — vynucený blok `deleted/merged/unchanged` + sekce `Details:`, kterou agent vyplnil i při nule.
3. `SKILL.md` Rules — „list the borderline items you kept in the report" (vyrobilo dvoubodový seznam 07-25).
4. `GOAL` ve skriptu — žádné omezení výstupu + formulace jako uživatelský příkaz → agent si to vyložil jako explicitní vyvolání („protože jsi explicitně vyvolal skill, dělal jsem full audit" — 3 ze 4 nocí).

**Co jsem zkusil:** `SKILL.md` Auto mode přepsán na dvě výstupní cesty (nula → jedna věta, stop, žádná záloha ani log; změna → záloha + řádek per položku s kategorií a důvodem), zrušeno hlášení borderline-kept a přidán explicitní zákaz narace auditu, `Output format` má teď dva auto tvary. `GOAL` doplněn o „unattended nightly run, not an interactive request" + převeden z implicitní konkatenace literálů na triple-quoted string (precedens `SCHEMA = """…"""` v `bookmark.py`/`db.py`). Interactive mode nedotčen. Nasazeno `rsync -av skills/compact-memory/` (celý adresář), owner ✓, bez restartu.

**Co fungovalo a proč:** Tři reálné běhy na serveru (exit 0):

- **Nula změn:** doručeno 56 znaků (`Memory compact: nothing to delete (MEMORY.md, 28 lines).`), žádná nová záloha, log nedotčen, `MEMORY.md` beze změny.
- **Se změnou** (reverzibilní test — vložena zjevně ephemeral odrážka do `MEMORY.md`): doručeno 165–207 znaků = hlavička + jeden řádek `[ephemeral] "…" — důvod`, smazána právě ta odrážka, vznikla záloha `backup/2026-07-25_0640_memory.backup.md`, `MEMORY.md` se vrátil do původního stavu (`diff` vs. pretest kopie čistý až na doplněný trailing newline).

**Vedlejší nález a fix — agent přepisoval `memory-clean.log`:** V prvním testu změnové cesty log po zápisu **zmenšil** (246 → 196 B) — starý řádek z 07-19 zmizel. Tohle je stejná ztráta, jaká už 07-15 spolkla zápisy o reálném mazání; prózové „append-only" nestačí, když má agent `write_file`, a moje nová formulace („log obsahuje jen smazané položky") ho ještě pozvala nevyhovující řádek „uklidit". Fix: `SKILL.md` teď předepisuje **deterministický append přes `exec`** (`printf '%s\n' '…' >> log/memory-clean.log`), zakazuje `write_file`/`edit_file` na log a explicitně zakazuje mazat/reformátovat existující řádky, i když neodpovídají aktuálnímu formátu. Po redeployi třetí běh: 196 → 350 B, starý řádek zůstal ✓. (Oba záznamy skončily na jednom řádku, protože předchozí zápis neměl trailing newline — soubor teď newline má, takže se to samo srovná.)

**Co zbývá:** Zkontrolovat noční běh 2026-07-26 v `log/compact_memory_auto_cron.log` (řádek `Response to cli:user:` má být krátký).

**Jak vrátit zpět:** `git checkout ef0d6cc~1 -- skills/compact-memory/` + `rsync -av skills/compact-memory/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/compact-memory/`. Testovací zásahy do `MEMORY.md` jsou už vrácené (agent smazal právě ty vložené odrážky); zálohy z běhů jsou v `backup/2026-07-25_06*`.

## 2026-07-26 — compact-memory: model navrhuje, skript validuje a aplikuje (konec prompt-compliance)

**Cíl:** Noční běh 2026-07-26 02:00 poslal na Telegram 1737 znaků narace („Now I have all four files. Let me audit MEMORY.md systematically…"), přestože včerejší oprava přesně tohle zakazovala. Uzavírá položku „zkontrolovat noční běh 07-26" z předchozího záznamu — a odpovídá na ni negativně.

**Diagnóza:** Skill na serveru identický s repem (`diff -ru` → IDENTICAL), takže žádný drift. V session `compact-memory-auto_20260726-020001.jsonl` je finální assistant zpráva 1737 znaků: celá úvaha jako text, na konci správný jednořádkový report. Skript posílal `result.content` beze změny → doručilo se všechno. Srovnání s včerejšími testy (56 a 165 znaků, 3 iterace, dávkové tool cally) vs. dnešek (8 iterací po jednom volání, soubory čtené přes `grep pattern="."`): stejný skill, stejný `GOAL`, stejný model `glm-5.1:cloud`, jiné chování. Závěr: formát výstupu nesmí viset na prompt-compliance, 3 čisté testy nedokazují nic.

**Co jsem zkusil (návrh schválen v plan mode, plán `~/.claude/plans/dobre-pojme-vylepsit-ten-buzzing-quasar.md`):** Obrácení zodpovědností — agent v nočním režimu **needituje nic** a vrací jen JSON change-set (`{"changes": [{op, category, original, new_text, reason}]}`), skript ho validuje, aplikuje, zálohuje, loguje a **sám skládá českou zprávu**. Klíčové volby: `original`/`new_text` jsou **pole řádků** (ne string s `\n` — tam modely kazí escapování); položky se identifikují **doslovným textem, ne čísly řádků**, a blok se musí v souboru vyskytovat právě jednou (halucinovaný citát spadne na validaci místo aby smazal špatný řádek); cílový soubor je **konstanta ve skriptu**, ne pole v JSON (uživatelova připomínka: pole `file` je zbytečná ceremonie, když je whitelist jednoprvkový); limity (`reason` ≤ 120 znaků, `new_text` ≤ 3 řádky/300 znaků, `original` ≤ 20 řádků, smazání < 50 % souboru) jsou **chyba, ne oříznutí**; nevalidní výstup se až **3× vrací modelu** s konkrétním seznamem chyb ve stejné (jednorázové) session; **SHA-256 guard** pozná, kdyby agent soubor upravil sám — agent má `write_file`/`exec` pořád k dispozici, takže zákaz v promptu je jen prosba. Noční běh navíc přepnut z `glm` na preset **`kimi27`** (`kimi-k2.7-code:cloud`) přes `Nanobot.from_config(model_preset=…)` — dopad omezen na tento job. Tvrdá selhání (timeout, výjimka) nově taky posílají jednořádkovou hlášku, dřív skončila tiše exit kódem 1.

**Co fungovalo a proč:**

- **Offline testy parseru** (30 kontrol, `scratchpad/test_parser.py`, stub modulu `nanobot` + `importlib`): validní delete/merge, prázdný change-set, bare JSON bez fence, JSON obalený narací, `reason` přes limit, citát co v souboru není, citát vyskytující se 11×, neznámé pole, špatná kategorie/`op`, merge co nezkracuje, překryv bloků, smazání 19 z 28 řádků, sběr chyb ze všech položek najednou — plus aplikace na kopii (záloha, append-only log, přestavěný soubor) a formát reportu. Vše zelené.
- **Test 1 (nic k smazání):** jeden pokus, model vrátil přesně `{"changes": []}`, exit 0, hash `MEMORY.md` beze změny, log 350 B beze změny, žádná nová záloha.
- **Test 2 (reverzibilní změna):** vložena ephemeral odrážka → model ji jako jedinou navrhl smazat, skript aplikoval, `diff` proti pretest kopii čistý, log 350 → 550 B (starý řádek zachován), nová záloha `backup/2026-07-26_0648_memory.backup.md`.
- **Test 3a (chybová cesta):** kopie skriptu s `GOAL`, který vynucuje prózu → 3 pokusy, model postupně konvergoval (próza → JSON bez `changes` → JSON se špatným `op`), exit 1, na Telegram 145 znaků `Memory compact: CHYBA — po 3 pokusech: …`, `MEMORY.md` nedotčen.
- **Test 3b (zotavení po odmítnutí):** kopie s uměle odmítnutým prvním pokusem → follow-up přijat, druhý pokus prošel, exit 0.
- **`kimi27` uspěl na první dobrou** ve všech reálných bězích a i pod chybovým tlakem reagoval na konkrétní validační hlášky.

**Co zbývá:** Zkontrolovat noční běh 2026-07-27 (`log/compact_memory_auto_cron.log`) — odpověď modelu tam teď bude JSON, ale doručená zpráva z ní nevzniká. Zvážit zápis do `knowledge.md` (jak SDK přepíná model per běh, seznam presetů) a návrh do `decisions.md` (viz níže, čeká na formulaci autora). Interaktivní režim skillu zůstal beze změny a nebyl retestován.

**Pozor na `__pycache__`:** Lokální test skriptu přes `importlib` vyrobil `skills/compact-memory/scripts/__pycache__/`, který se `rsync -av` dostal na server (smazáno na obou stranách). Deploy skillů se skripty dělat s `--exclude='__pycache__'`.

**Jak vrátit zpět:** `git checkout 9c82894~1 -- skills/compact-memory/` + `rsync -av --exclude='__pycache__' skills/compact-memory/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/compact-memory/`. Testovací zásahy do `MEMORY.md` jsou vrácené (ověřeno `diff` proti kopii pořízené před testy, hash `249015fd…` shodný před i po). Testovací záznam v `log/memory-clean.log` a záloha `backup/2026-07-26_0648_*` zůstávají jako stopa po testu — log je append-only, nemažou se.

## 2026-07-27 — compact-memory: anglické hlášky + testy, a ruff/ty lint hook pro celý repo

**Cíl:** Tři věci na jedno zadání. (1) `compact_memory_auto.py` měl anglické docstringy, prompty i validátorové hlášky, ale sedm uživatelských hlášek zůstalo česky — doručený report byl jazykově rozpolcený. (2) Skript má bohatou čistou logiku (parser, validátor, přestavba souboru, report), ale jako jediný netriviální skill neměl `tests/`; offline testy parseru z 07-26 žily jen ve scratchpadu a zmizely. (3) V repu nebyla žádná Python lint konfigurace ani hook, přestože `skills/python/SKILL.md` definuje hotovo jako `ruff format` + `ruff check --fix`.

**Co jsem zkusil:** Plán `~/.claude/plans/vsechny-hlasky-do-anglictiny-curious-lantern.md`, schválený v plan mode.

- **Jazyk:** přeloženo všech 7 českých hlášek (`nebylo nic k smazání` → `nothing to remove`, `CHYBA —` → `ERROR —`, atd.). Součástí byla i změna `SKILL.md`: pravidlo `reason` — max 120 characters, **in Czech** → **in English** plus dva příklady v JSON schématu. Bez toho by report zůstal míchaný, protože `reason` od modelu se vkládá doslova do Telegram zprávy i do `log/memory-clean.log`.
- **Testy:** nový `skills/compact-memory/tests/test_compact_memory_auto.py` — 51 testů, vzor podle `skills/note/tests/test_note_compile.py` (`sys.path.insert` na `../scripts`, `tmp_path` fixtura). Pokrývá `_extract_json`, validaci všech polí, agregaci chyb, hledání/unikátnost bloku, překryv, 50% limit, `apply_change_set` (obsah, záloha, append-only log, počet řádků), `format_report`, `_log_line`, `_shorten`, `_quote`, `_telegram_config`, `_workspace`. Aby to šlo importovat bez `nanobot-ai`, přesunut `from nanobot import Nanobot` z module-level do `_run()` + `TYPE_CHECKING` import pro anotaci — stejný vzor, jaký už používá `note_compile.py`.
- **Lint:** nový `ruff.toml` (line-length 120, target py311, `select = ["E","F","I","UP","B","BLE","SIM","C4","RUF"]`), nový `ty.toml` (extra-paths na všechny `skills/*/scripts`, `unresolved-import = "ignore"`), nový hook `.claude/hooks/python-check.sh` registrovaný jako třetí položka v existující `PostToolUse` skupině `Edit|Write|MultiEdit`.

**Co fungovalo a proč:**

- **Hook je fail-fast a ověřený všemi cestami:** non-`.py` → exit 0; soubor pod `tmp/` → exit 0; neopravitelný ruff nález (`F821`) → exit 2 s `ruff findings`; čistý lint ale typová chyba → exit 2 s `ty findings`; čistý soubor → exit 0. Auto-fix ověřen (nepoužitý import ruff sám smazal). Latence: ruff ~10 ms, ty ~95 ms.
- **`unset VIRTUAL_ENV` v hooku je nutnost, ne opatrnost.** V tomhle prostředí je proměnná zděděná a ukazuje na neexistující `/home/lachtan/.pyenv/versions/3.11.5`; `ty` na tom padá s `Failed to discover local Python environment` ještě před kontrolou.
- **Explicitní `select` v `ruff.toml` je taky nutnost.** Ruff 0.16 má bez configu velmi širokou výchozí sadu (125 nálezů repo-wide včetně `DTZ*` a `EXE001`) a délku řádku 88, což odporuje `.claude/rules/python.md` (120). `BLE` je ve výběru schválně: skript má dvě promyšlená `# noqa: BLE001` a bez `BLE` by je `RUF100` označil za mrtvá a `--fix` je i s vysvětlujícím komentářem smazal.
- **Ruff sám opravil, co jsem nehledal:** `asyncio.TimeoutError` → `TimeoutError` (`UP041`) a sloučení tří zalomených `raise ChangeSetError(...)` na jeden řádek (dřív zalomené kvůli 88 znakům).
- **`ty` našel reálnou chybu:** `sorted(set(raw) - allowed)` — klíče jsou po `isinstance` zúžení typované `object`, což nesplňuje `SupportsRichComparison`. Opraveno na `sorted(str(key) for key in set(raw) - allowed)`.
- **Server byl před nasazením identický s repo HEAD** (`rsync` do `tmp/srv-check-cm/` + `diff -r`) — žádný drift od Dream procesoru. Po nasazení `md5sum` shodné na obou stranách, vlastník `nanobot:nanobot`, `py_compile` na serveru OK, crontab beze změny.

**Zádrhel — PEP 723 přepíná `ty` do script-mode, kde projektový `ty.toml` neplatí na pravidla.** `unresolved-import = "ignore"` fungovalo na běžné moduly, ale ne na `compact_memory_auto.py`. Izolováno probe souborem: identický soubor **s** `# /// script` hlavičkou hlásí `unresolved-import`, **bez** ní projde. `--project .` nepomůže; `--config "rules.unresolved-import='ignore'"` ano, ale flag v hooku by znamenal, že ruční `ty check` dělá něco jiného než hook. Řešení: inline `# ty: ignore[unresolved-import]` u obou `nanobot` importů + komentář v `ty.toml`, že sekce `[rules]` na PEP 723 skripty nedosáhne.

**Zádrhel — `rsync` dvou souborů naráz je položil do stejného cílového adresáře.** `rsync SKILL.md scripts/compact_memory_auto.py server:.../compact-memory/` udělal na serveru `compact-memory/compact_memory_auto.py` vedle `compact-memory/scripts/compact_memory_auto.py`. Stray kopie smazána, skript nasazen zvlášť do `scripts/`. Příště buď celý adresář, nebo jeden soubor na jeden `rsync`.

**Co zbývá:** Ostrý noční běh 2026-07-28 02:00 — první, který poběží s anglickými hláškami a anglickým `reason`; zkontrolovat `log/compact_memory_auto_cron.log` a nové řádky v `log/memory-clean.log` (historické české řádky zůstávají, log je append-only). Manuální ostrý běh jsem nedělal — mutuje reálný `MEMORY.md` a posílá Telegram. Repo-wide zbývá 92 ruff a 16 ty nálezů v ostatních skriptech; hook je nahlásí, až se těch souborů někdo dotkne (nejvíc `skills/llm-wiki/scripts/wiki_lint.py` = 9). Ostatní skripty s českými hláškami (`tasks-daemon.py`, `wiki_compile.py`, `note_compile.py`) zůstaly podle rozhodnutí česky. `.claude/rules/bash.md` řádek 45 tvrdí, že bash formátování hlídá `check-bash.sh` PostToolUse hook — ten v repu neexistuje ani není registrovaný; dokument je rozsynchronizovaný.

**Jak vrátit zpět:** `git checkout <tento commit>~1 -- skills/compact-memory/ .claude/settings.json` + `rm ruff.toml ty.toml .claude/hooks/python-check.sh` + `rsync -av --exclude='__pycache__' --exclude='tests' skills/compact-memory/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/compact-memory/`. Na serveru se nic nemazalo ani nemutovalo mimo dva přepsané soubory (`SKILL.md`, `scripts/compact_memory_auto.py`) — `MEMORY.md`, zálohy ani logy zásah nepotkal.

## 2026-07-27 — Kontrola presetu `kimi3` (Kimi K3 na Ollama Cloud) + oprava context window

**Cíl:** Ověřit, že nově vydaný Kimi K3 (`kimi-k3:cloud` na Ollamě) je v `~/.nanobot/config.json` nastavený správně a má správné parametry.

**Co jsem zkusil:**

- `ssh nanobot@nanobot.hell` → dump `config.json`. Pozor: top-level klíč je `model_presets` (snake_case), ne `modelPresets`, jak tvrdila knowledge — první pokus o výpis vrátil `null`.
- `curl http://nvidia.hell:11434/api/tags` (model v katalogu je) a `api/show` pro `kimi-k3:cloud` i pro srovnání `kimi-k2.6`, `kimi-k2.7-code`, `glm-5.1`, `glm-5.2`.
- Funkční test: `curl .../v1/chat/completions` s `kimi-k3:cloud`, pak totéž s `glm-5.2:cloud` a `kimi-k2.7-code:cloud` jako kontrolní skupina.
- `journalctl --user -u nanobot.service` — hledání stop po přepnutí na preset.
- Online ověření na žádost uživatele: [ollama.com/pricing](https://ollama.com/pricing), [ollama.com/library/kimi-k3](https://ollama.com/library/kimi-k3), oznámení Ollamy na X.
- `curl https://openrouter.ai/api/v1/models` — hledání alternativní cesty ke stejnému modelu.

**Co fungovalo a proč:**

- **Konfigurace presetu je věcně správná.** `kimi3` = `{model: kimi-k3:cloud, provider: ollama, maxTokens: 16384, temperature: 0.1, reasoningEffort: null}`. Název modelu přesně sedí s `api/tags`, `apiBase` má povinný `/v1` suffix, model má capabilities `tools`+`thinking`+`vision`. Journal potvrdil, že runtime přepnutí funguje: `Runtime model switched for next turn: glm-5.1:cloud -> kimi-k3:cloud`. `reasoningEffort: null` není opomenutí — `schema.py:141` říká, že `None` zachovává default providera.
- **Blokuje to Ollama, ne config.** Přímé volání endpointu vrací HTTP 402 `this model uses extra usage only (not included plan usage) and your extra usage balance is empty`. Kontrolní skupina (`glm-5.2:cloud`, `kimi-k2.7-code:cloud`) přitom odpovídá normálně → není to stav účtu ani API klíč, je to per-model politika. Online potvrzeno: K3 vyžaduje Pro/Max **a** nenulový dokoupený extra usage balance, kapacita se teprve rozšiřuje. Nanobotí hláška *„API key is out of quota or the account is in arrears"* je zavádějící překlad tohoto 402.
- **Oprava parametru:** `contextWindowTokens` bylo `967000` proti reálnému `1048576` (z `api/show`, klíč `kimi-k3.context_length`) — ~81k tokenů ležel ladem. Ostatní presety drží ~97 % reálného okna (`glm-5.1`: 196608/202752, `glm-5.2`: 976000/1000000, kimi K2.x: 262144 = přesně). Srovnáno na **1 020 000**. Záloha `~/.nanobot/backup/config.json.bak-20260727-202245`, `diff` proti ní ukazuje jediný změněný řádek, vlastník `nanobot:nanobot` a práva `600` beze změny. Restart nebyl potřeba — presety se načítají každý tah (`_refresh_provider_snapshot`).
- **Vedlejší nález:** knowledge tvrdila konvenci pojmenování presetů `<model>-<provider>` (`kimi-k2.6-openrouter`), reálně jsou na serveru krátké aliasy (`kimi`, `kimi27`, `kimi3`, `glm`, `glm52`, `sonnet`, `haiku`, `gemini-flash`). Opraveno v `knowledge.md` spolu s názvem klíče `model_presets`.

**Co zbývá:** Model je do dobití extra usage na ollama.com nepoužitelný. Alternativa bez dobíjení, pokud ji uživatel bude chtít: preset přes OpenRouter (`moonshotai/kimi-k3`, ctx 1 048 576, $3/M in + $15/M out) — provider `openrouter` je v configu už nakonfigurovaný. Nezakládal jsem ho, nebylo zadáno.

**Jak vrátit zpět:** `ssh nanobot@nanobot.hell 'cp ~/.nanobot/backup/config.json.bak-20260727-202245 ~/.nanobot/config.json'` — mimo tuhle jednu hodnotu jsem na serveru nic neměnil.