lachtan/nanobot-runtime

Fork 0

Files

lachtan 67e29c8b88 Zalohovani vsech podstatnych souboru

2026-06-10 06:39:52 +02:00

126 KiB

Raw Blame History

History

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:

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ý.
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.
Ověření shody se serverem: rsync + diff -r obou skillů → IDENTICAL, žádná Dream úprava k dotažení.
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.
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-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:

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.
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) — 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).
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).
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:

Zkoumal, kde žijí instrukce agenta — SSH na server, prošel /home/nanobot/.nanobot/workspace/.
Zjistil, že správné místo je AGENTS.md (operační pravidla), ne SOUL.md (osobnost) ani skills.
Přidal sekci ## Databases (SQLite) do workspace/AGENTS.md (anglicky) a pushnu na server.
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.
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:

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í):

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).
Smazán memory/film_policy.md — nebyl čten, jen mátl.
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 — 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").
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):

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ěď.
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.
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".
→ Ú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:

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

Zkontroloval hooks v .claude/settings.json a ~/.claude/settings.json — nenašel nic relevantního.
CronList v harness — žádné naplánované joby tady.
Hledal skripty s "telegram"/"remind" na serveru — našel /home/nanobot/.nanobot/workspace/cron/jobs.json.
V jobs.json identifikoval job remind-check (id 1a7bb634) s "expr": "* * * * *" (každá minuta).
Přečetl remind_check.py — skript správný, tiskne jen skutečné připomínky.
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:

remind_check.py přepsán: Prague timezone přes zoneinfo, zjednodušen z ~70 na ~30 řádků
remind_runner.py smazán
cron/jobs.json — job remind-check přepnut na remind_check.py + delivery kanál změněn na Telegram (byl websocket session)
SKILL.md — odstraněn done field ze schématu, přidány sekce "Telegram — jak zadat příkaz" a "Remind vs. cron tool"
AGENTS.md + TOOLS.md — přepsána sekce o reminderech s jasným rozlišením: osobní notifikace → reminder.yaml, background úlohy → cron tool
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:

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):

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:

Nainstalován curl (chyběl v základní instalaci Debian 13 trixie):
```
apt-get update
apt-get install -y curl
```
Stáhlo se i libcurl4t64 jako závislost.

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:

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

Ověřeno přihlášení ssh nanobot@nanobot.hell stejným klíčem jako root — funguje.
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):
```
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:

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:

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.
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ě.
~/.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)
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).
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.
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:

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

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

"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" }
}

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:

Lingering povolen (vyžaduje root):
```
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.

Unit file /home/nanobot/.config/systemd/user/nanobot.service:

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

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

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.

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:

Pre-reboot boot_id zaznamenán (fe922ca4-...).
ssh root@nanobot.hell 'systemctl reboot' — SSH session dropped (čekáno).
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.
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).
Journal potvrdil, že telegram i websocket channel naběhly bez chyby.
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:

~/.nanobot/config.json upraven přes Python in-place (zachoval ostatní klíče): modelPresets.qwen.model → qwen/qwen3.6-plus-04-02.
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:

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

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`

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

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).
~/.nanobot/config.json rozšířen přes Python in-place editor o nový preset:
```
"glm-5.1-ollama": { "provider": "ollama", "model": "glm-5.1:cloud" }
```
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 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:

sed úprava ~/.config/systemd/user/nanobot.service: ExecStart=… nanobot gateway → … gateway -v.
systemctl --user daemon-reload && restart → active.
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 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 „Postup: přidání nového modelu"):

Ověřeno curl http://nvidia.hell:11434/api/tags → deepseek-v3.2:cloud přítomno.

~/.nanobot/config.json rozšířen přes Python in-place editor:

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

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):

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).
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.
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.
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.
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.
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/ v tomto repu
Plán: /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):

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

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>.
Nový soubor config.json ve skill adresáři:
```
{"fallback_telegram_chat_id": "8826147089"}
```
Editovatelný bez touch daemon kódu, single-user setup vyhraje hardcode.
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`
```
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ží.
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č:

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.
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.").
Deploy: rsync -av skills/keep/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/keep/ — SKILL.md odeslán.
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č:

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.
Deploy přes rsync -av skills/keep/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/keep/ — nanobot user, ownership nanobot:nanobot automaticky.
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č:

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ý).
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).
summary_line rozložen — jednořádkový (result_text.strip().splitlines() or ["(prázdný výstup)"])[0][:200] na 2 čitelné řádky.
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).
Docstring sjednocen na CZ — EN anotace v hlavičce přeložena do češtiny, diff se tím nezvětšil nad limit.
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.
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:

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.
Deploy: rsync -av skills/note/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/note/ — SKILL.md odeslán, ownership nanobot:nanobot.
Žá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:

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.
Confirm krok 8 — odstraněna CZ varianta Zapamatoval jsem:, nechán jen Kept: <fact> + poznámka, že model lokalizuje sám.
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é.
Krok 4 (MEMORY.md dedup lookup) beze změny — uživatel potvrdil ponechat.
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:

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.
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.)
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".
Rules — beze změny (Preserve input language už přítomno).
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:

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).
Ověřeno na serveru: klíč nebyl nastaven (channels mělo jen telegram, websocket) → padalo na default True.
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.

Co jsem zkusil / udělal:

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.
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).
YAML: vnořený blok random: vedle at/cron_exprs. Glanceable ukázka v reminder.example.yaml.
Testy: pytest (nová konvence repa) v skills/remind/tests/ + conftest.py (přidá ../scripts na sys.path). 21 testů.
Ú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:

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.
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.
Refaktor list-tasks.py/read-task.py/tasks-daemon.py → import z tasks_common (tenké entry skripty).
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.
tests/ (nové, pytest + conftest dle remind) — 34 testů čisté logiky.
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 — 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) — 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) + 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:

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ů.)
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.
Ř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 rsyncem 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 rsyncem 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 rsyncem, 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:

/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.
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 rsyncem, 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 rsyncem 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).

126 KiB Raw Blame History Unescape Escape

History

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

reminder.log — doručené připomínky

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

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

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

2026-05-27 — Oprava /remind skilu

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

126 KiB

Raw Blame History

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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