runtime

- scripts/ollama_usage_poll.py: per-minute cron sample into db/ollama_usage.sqlite,
  write-on-change; meta table records every poll so a data gap can be told apart
  from a failed or missed poll
- scripts/ollama_usage_report.py: delta report keyed on per-model request_count
  (limits.*.usage has 0.1 % resolution, short-interval deltas are noise)
- SKILL.md: Continuous sampling section

.gitignore

@@ -10,3 +10,6 @@ tasks/
 *.bak
 notes/.compile.lock
 cron/runs/
+wiki/*
+!wiki/config.yaml
+.env

AGENTS.md

@@ -10,70 +10,37 @@ Test: *Who is the recipient?* User gets notified → `/remind` skill (SQLite `db
 
 **Do NOT just write reminders to MEMORY.md** — that won't trigger actual notifications.
 
-## Doručené připomínky — „co dnes přišlo?"
+## Git commit timestamps
 
-Připomínky doručuje **systémový cron uživatele nanobot**
-(`skills/remind/scripts/remind_send.py`) přímo přes Telegram, mimo agenta —
-agent u odeslání není. Když se uživatel ptá na minulé/dnešní připomínky
-(„připomněl jsi mi…?", „co dnes přišlo?"), zavolej
-`uv run skills/remind/scripts/remind_cli.py delivered [--since YYYY-MM-DD]` —
-čte tabulku `reminder_fires` (jen doručené, čas v Praze).
-
-`log/reminder.log` je provozní/debug log všech operací (ADD/EDIT/REMOVE/…/DELIVER,
-UTC) — ne zdroj pravdy pro doručení. `log/reminder_cron.log` zachytává
-stdout/stderr crontabu — za zdravého běhu prázdný, plní se jen při pádech skriptu.
+For commit-message timestamps run `bash scripts/timestamp.sh` — do NOT call `date` directly with a format string. The exec safety guard false-positives on `date '+%Y-%m-%d %H:%M:%S'` (colons in `%H:%M:%S` match its Windows drive-letter path regex) and blocks the command.
 
 ## Heartbeat Tasks
 
-`HEARTBEAT.md` is checked on the configured heartbeat interval. Use file tools to manage periodic tasks:
-
-- **Add**: `edit_file` to append new tasks
-- **Remove**: `edit_file` to delete completed tasks
-- **Rewrite**: `write_file` to replace all tasks
-
-When the user asks for a recurring/periodic task, update `HEARTBEAT.md` instead of creating a one-time cron reminder.
+`HEARTBEAT.md` is checked on the configured heartbeat interval. Manage periodic tasks there with file tools (`edit_file` / `write_file`), not via one-time cron reminders.
 
 ## Databases (SQLite)
 
 Always store SQLite databases under `db/*.sqlite` (relative to the workspace root).
 Never use `/tmp/`, hardcoded absolute paths, or in-memory databases for persistent data.
 
-## How you were extended & tuned
+## Workspace stores
 
-`develop/` records how this instance was extended and tuned — skills, config, service work — with verified facts and a change log you can learn from (not the upstream code). See `develop/README.md`; read on demand.
-
-## Explicit user details
-
-Explicit user facts are stored in `keep.md`. Read at every turn.
-
-## Knowledge base
-
-`knowledge/` holds verified facts and measured values you can draw on when answering (e.g. notes on the models available to you). See `knowledge/README.md` for what's there; read on demand.
+- `develop/` — how this instance was extended and tuned (see `develop/README.md`); read on demand
+- `keep.md` — explicit user facts; read at every turn
+- `projects/<name>/` — deep details about the user, projects, hardware; search those too
+- `knowledge/` — verified facts and measured values (see `knowledge/README.md`); read on demand
 
 ## exec Tool
 
 The exec safety guard blocks commands without an explicit workspace path (e.g. `lua -e '...'`, `which`). Write scripts to files inside the workspace (e.g. `tmp/script.lua`) and run them with `working_dir` set to the workspace root.
 
-On the first safety-guard block: diagnose the cause before retrying — check a missing `working_dir` first, never re-send the same blocked form, and change one variable per test until the cause is identified.
+**Never put prose or user-supplied text into a command string** — not as an argument, not in a heredoc, not through a pipe. The guard scans the raw command string and has no shell parser, so quoting does not help. Any `X:` where `X` is an ASCII letter not preceded by another ASCII letter parses as a Windows drive path and blocks the whole command: Czech `Cíl:`, `Závěr:`, `směr:` all trip it (the diacritic before the letter defeats the guard's ASCII-only lookbehind), and so does `date '+%H:%M:%S'`. A literal `../` anywhere in the command — even inside prose — trips the traversal guard too.
+
+Instead: `write_file` the text to `tmp/`, then pass the **path** (`--file tmp/x.md`, or `< tmp/x.md`). A path in the command is safe, and file tools are not subject to this guard. Skill CLIs that take text follow this — see `skills/project` and `skills/note`.
 
 ## python — use uv
 
-For all Python code (scripts, snippets, one-liners, tools) use `uv`,
-not `python` / `python3` / `pip` directly.
-
-- Run a script: `uv run script.py` (not `python script.py`)
-- One-liner / snippet: `uv run --with <pkg> python -c '...'`
-- Script with declared dependencies: `uv run --script script.py`
-  (PEP 723 header inside the file)
-- Add a project dependency: `uv add <pkg>` (not `pip install`)
-- Remove: `uv remove <pkg>`
-- Sync environment: `uv sync`
-- Run a tool: `uv run pytest`, `uv run ruff`, `uv run mypy`, …
-- REPL: `uv run python`
-
-Do not use `pip`, `pip-tools`, `poetry`, `conda`, or the system `python`.
-Reason: isolated, reproducible environments with no system-level side
-effects, faster resolves, no "works on my machine" surprises.
+For all Python code use `uv`, never `python` / `python3` / `pip` / `poetry` / `conda` directly. Details in `skills/python/SKILL.md`.
 
 ## File / Code Conventions
 
@@ -95,8 +62,6 @@ In addition to Python and Bash, the agent can also write and run:
 - **Rust** — via `rustc` / `cargo` (compile and run inside workspace)
 - **TypeScript** — always via `bun`
 
-Use these when the user explicitly asks for them or when they are the right tool for the job. Default remains Python for non-trivial scripts and Bash for very short shell snippets.
-
 ### Git clones
 - Always clone repos into `workspace/src/<repo-name>`, not directly into workspace root.
 
@@ -114,6 +79,12 @@ something, that is a request for information only. Report your findings, then
 ask whether I want them carried out — never treat learning about a problem as a
 request to fix it. When in doubt, ask first.
 
+## Git commits for workspace changes
+
+Whenever the agent modifies any skill or any file in the workspace (including dream/runtime changes), make a git commit in the workspace repo. Commit message: current date and time in SQL format (`YYYY-MM-DD HH:MM:SS`), prefixed to indicate it's a nanobot agent change, e.g.:
+
+`nanobot: 2026-02-12 14:35:07`
+
 ## Behavioral Guidelines
 
 1. Don't assume. Don't hide confusion. Surface tradeoffs.

SOUL.md

@@ -33,6 +33,8 @@ Jsem [nanobot](https://github.com/HKUDS/nanobot) — lehký osobní asistent. Ml
 - Když existuje víc cest, vynes tradeoff nahlas místo tichého výběru jedné
 - Víc otázek pokládej **postupně, jednu po druhé** — u každé musí být prostor odpovědět
 - **Cron tool** podporuje jen `add`, `list`, `remove` — úprava existujícího jobu vyžaduje delete + create
+- **Exec guard blokuje `rm -rf`, `rm -r` a wildcard/multi-file `rm`** i v tmp/ — čištění dělej vyjmenovaným `rm` jednotlivých souborů + `rmdir`
+- **Exec guard blokuje curl na interní hosty** („internal/private URL detected", např. Ollama endpoint na nvidia.hell) — pro HTTP na interní homelab služby použij Python skript (requests) v tmp/ přes uv
 - Pravidla do `USER.md`/`SOUL.md`/`AGENTS.md` apod. piš **stručně a jasně** — krátké imperativní bullety, klíčové slovo tučně, bez vaty
 
 ## Faktografická pravidla

USER.md

@@ -82,3 +82,6 @@
 ## Cestování
 - Vánoce 2026: Panama (PTY) z Prahy (PRG), ~21.12.2026 – ~4.1.2027, 3 osoby, min 2 týdny pobyt, flexibilní na datech pokud levnější
 
+## Konfigurace a formáty
+- **TOML nepoužívat** — pro konfigurace volit jiné formáty (YAML, JSON, INI)
+

cml/raw/_done/claude-code-goal-command.md

@@ -1,115 +0,0 @@
-# Keep Claude working toward a goal - Claude Code Docs
-
-Source: https://code.claude.com/docs/en/goal
-
-The `/goal` command sets a completion condition and Claude keeps working toward it without you prompting each step. After each turn, a small fast model checks whether the condition holds. If not, Claude starts another turn instead of returning control to you. The goal clears automatically once the condition is met.
-
-Use a goal for substantial work with a verifiable end state:
-
-- Migrating a module to a new API until every call site compiles and tests pass
-- Implementing a design doc until all acceptance criteria hold
-- Splitting a large file into focused modules until each is under a size budget
-- Working through a labeled issue backlog until the queue is empty
-
-## Compare ways to keep a session running
-
-Three approaches keep the current session running between prompts:
-
-| Approach | Next turn starts when | Stops when |
-| --- | --- | --- |
-| `/goal` | The previous turn finishes | A model confirms the condition is met |
-| `/loop` | A time interval elapses | You stop it, or Claude decides the work is done |
-| Stop hook | The previous turn finishes | Your own script or prompt decides |
-
-`/goal` and a Stop hook both fire after every turn. `/goal` is a session-scoped shortcut: you type a condition and it's active for the current session only. A Stop hook lives in your settings file, applies to every session in its scope, and can run a script for deterministic checks or a prompt for model-evaluated ones.
-
-Auto mode on its own approves tool calls within a single turn but doesn't start a new one. Claude stops when it judges the work done. `/goal` adds a separate evaluator that checks your condition after every turn, so completion is decided by a fresh model rather than the one doing the work. The two are complementary: auto mode removes per-tool prompts, and `/goal` removes per-turn prompts.
-
-## Use `/goal`
-
-One goal can be active per session. The same command sets, checks, and clears it depending on the argument.
-
-### Set a goal
-
-Run `/goal` followed by the condition you want satisfied. If a goal is already active, the new one replaces it.
-
-```
-/goal all tests in test/auth pass and the lint step is clean
-```
-
-Setting a goal starts a turn immediately, with the condition itself as the directive. You don't need to send a separate prompt. While the goal is active, a `◎ /goal active` indicator shows how long the goal has been running.
-
-After each turn, the evaluator returns a short reason explaining why the condition is or isn't met. The most recent reason appears in the status view and in the transcript so you can see what Claude is working toward next.
-
-### Write an effective condition
-
-The evaluator judges your condition against what Claude has surfaced in the conversation. It doesn't run commands or read files independently, so write the condition as something Claude's own output can demonstrate. "All tests in `test/auth` pass" works because Claude runs the tests and the result lands in the transcript for the evaluator to read.
-
-A condition that holds up across many turns usually has:
-
-- **One measurable end state**: a test result, a build exit code, a file count, an empty queue
-- **A stated check**: how Claude should prove it, such as "`npm test` exits 0" or "`git status` is clean"
-- **Constraints that matter**: anything that must not change on the way there, such as "no other test file is modified"
-
-The condition can be up to 4,000 characters.
-
-To bound how long a goal runs, include a turn or time clause in the condition, such as `or stop after 20 turns`. Claude reports progress against that clause each turn and the evaluator judges it from the conversation.
-
-### Check status
-
-Run `/goal` with no arguments to see the current state.
-
-```
-/goal
-```
-
-If a goal is active, the status shows:
-
-- The condition
-- How long it has been running
-- How many turns have been evaluated
-- The current token spend
-- The evaluator's most recent reason
-
-If no goal is active but one was achieved earlier in the session, the status shows the achieved condition along with its duration, turn count, and token spend.
-
-### Clear a goal
-
-Run `/goal clear` to remove an active goal before its condition is met.
-
-```
-/goal clear
-```
-
-`stop`, `off`, `reset`, `none`, and `cancel` are accepted as aliases for `clear`. Running `/clear` to start a new conversation also removes any active goal.
-
-### Resume with an active goal
-
-A goal that was still active when a session ended is restored when you resume that session with `--resume` or `--continue`. The condition carries over, but the turn count, timer, and token-spend baseline all reset on resume. A goal that was already achieved or cleared is not restored.
-
-### Run non-interactively
-
-`/goal` works in non-interactive mode, in the desktop app, and through Remote Control. Setting a goal with `-p` runs the loop to completion in a single invocation:
-
-```
-claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"
-```
-
-Interrupt the process with Ctrl+C to stop a non-interactive goal before the condition is met.
-
-## How evaluation works
-
-`/goal` is a wrapper around a session-scoped prompt-based Stop hook. Each time Claude finishes a turn, the condition and the conversation so far are sent to your configured small fast model, which defaults to Haiku. The model returns a yes-or-no decision and a short reason. A "no" tells Claude to keep working and includes the reason as guidance for the next turn. A "yes" clears the goal and records an achieved entry in the transcript.
-
-The evaluator runs on whichever provider your session is configured for. It does not call tools, so it can only judge what Claude has already surfaced in the conversation.
-
-## Requirements
-
-`/goal` runs only in workspaces where you have accepted the trust dialog, because the evaluator is part of the hooks system. `/goal` is also unavailable when `disableAllHooks` is set at any settings level or when `allowManagedHooksOnly` is set in managed settings. In each case, the command tells you why instead of silently doing nothing.
-
-## See also
-
-- Run a prompt repeatedly with `/loop`: re-run on a time interval instead of until a condition holds
-- Prompt-based hooks: write your own Stop hook when you need custom evaluation logic
-- Auto mode: approve tool calls automatically so each goal turn runs unattended
-- Scheduling comparison: run work on a schedule independent of any open session

cml/raw/_done/claude-code-local-cloud-models-ollama-openrouter.md

@@ -1,94 +0,0 @@
-# Run Claude Code with Local & Cloud Models in 5 Minutes (Ollama, LM Studio, llama.cpp, OpenRouter)
-
-**Autor:** Luong NGUYEN
-**URL:** https://medium.com/@luongnv89/run-claude-code-on-local-cloud-models-in-5-minutes-ollama-openrouter-llama-cpp-6dfeaee03cda
-**Datum:** Jan 31, 2026
-
----
-
-Průvodce nastavením Claude Code s alternativními modely — Ollama (lokální i cloud), LM Studio, llama.cpp, OpenRouter a další. Většina konfigurace se dělá přes env vars `ANTHROPIC_BASE_URL`, `ANTHROPIC_AUTH_TOKEN`, `ANTHROPIC_API_KEY`, `ANTHROPIC_MODEL`.
-
-## Doporučené modely pro coding
-
-- **devstral-small-2 (24B)** — dobrý start pro coding quality
-- **qwen3-coder:30b** — lepší coding ability, stále praktický na 32GB RAM
-- **GLM4.7-flash:q8_0** — silný poměr cena/výkon (kvantizovaný)
-
-Minimální spec: 32GB RAM, model 24B+ parametrů. Na 16GB to jde, ale experience je rough.
-
-## Option 1: Ollama Local
-
-```bash
-ollama pull devstral-small-2
-ollama launch claude --model devstral-small-2
-```
-
-Nebo manuálně přes env vars:
-```bash
-export ANTHROPIC_AUTH_TOKEN="ollama"
-export ANTHROPIC_API_KEY=""
-export ANTHROPIC_BASE_URL="http://localhost:11434"
-claude --model devstral-small-2
-```
-
-## Option 2: llama.cpp + HuggingFace
-
-Build llama.cpp s Metal (macOS) nebo CUDA (Linux), spusť server s `--jinja` flag (nutný pro tool calling), připoj Claude Code přes `ANTHROPIC_BASE_URL=http://localhost:8000`.
-
-```bash
-llama-server -hf bartowski/cerebras_Qwen3-Coder-REAP-25B-A3B-GGUF:Q4_K_M \
-  --alias "Qwen3-Coder-REAP-25B-A3B-GGUF" \
-  --port 8000 --jinja --kv-unified \
-  --cache-type-k q8_0 --cache-type-v q8_0 \
-  --flash-attn on --batch-size 4096 --ubatch-size 1024 --ctx-size 64000
-```
-
-## Option 3: LM Studio
-
-GUI i CLI varianta (`llmster`). Server na portu 1234, env vars `ANTHROPIC_BASE_URL=http://localhost:1234`, `ANTHROPIC_AUTH_TOKEN=lmstudio`.
-
-## Option 4: Ollama Cloud Models
-
-```bash
-ollama pull kimi-k2.5:cloud
-ollama pull minimax-m2.1:cloud
-claude --model kimi-k2.5:cloud
-```
-
-Stejný workflow jako lokální, compute v cloudu. Free tier má omezený usage.
-
-## Option 5: Cloud Provider APIs (OpenRouter atd.)
-
-```bash
-export ANTHROPIC_BASE_URL=https://openrouter.ai/api
-export ANTHROPIC_AUTH_TOKEN=YOUR_OPENROUTER_KEY
-export ANTHROPIC_API_KEY=
-export ANTHROPIC_MODEL="openai/gpt-oss-120b:free"
-```
-
-Prázdný `ANTHROPIC_API_KEY` je záměr — zabraňuje autentikaci přes Anthropic API přímo.
-
-Minimax přes OpenRouter: ~98% levnější než Opus 4.5. Podobně GLM, DeepSeek, Kimi.
-
-## Klíčové env vars
-
-| Var | Purpose |
-|-----|---------|
-| `ANTHROPIC_BASE_URL` | API endpoint |
-| `ANTHROPIC_AUTH_TOKEN` | API key pro provider |
-| `ANTHROPIC_API_KEY` | Prázdný = žádný Anthropic fallback |
-| `ANTHROPIC_MODEL` | Model identifier |
-
-## Závěr
-
-- Lokální na M1 32GB: devstral-small-2 (24B) OK, větší modely pomalé
-- Nvidia DGX Spark: široký výběr modelů
-- Cloud: nejrychlejší cesta, Ollama Cloud free tier pro emergency, jinak Kimi/Minimax/DeepSeek/GLM přes OpenRouter
-- Opus 4.5 stále nejlepší quality+speed, ale drahý
-
-## Zdroje
-
-- [Ollama Claude Code Integration](https://docs.ollama.com/integrations/claude-code)
-- [OpenRouter Integration](https://openrouter.ai/docs/guides/guides/claude-code-integration)
-- [cc-compatible-models](https://github.com/Alorse/cc-compatible-models)
-- [claude-flow wiki](https://github.com/ruvnet/claude-flow/wiki/Using-Claude-Code-with-Open-Models)

cml/raw/_done/claude-code-ollama-workflow-free.md

@@ -1,43 +0,0 @@
-# I Tried New Claude Code Ollama Workflow (It's Wild & Free)
-
-**Autor:** Joe Njenga
-**URL:** https://medium.com/@joe.njenga/i-tried-new-claude-code-ollama-workflow-its-wild-free-cb7a12b733b5
-**Datum:** Jan 19, 2026
-**Status:** 🔒 Member-only (paywall) — pouze preview dostupný
-
----
-
-## Dostupný obsah (preview)
-
-Claude Code nyní funguje s Ollama — lokální i cloud modely. Ollama v0.14.0+ je kompatibilní s Anthropic Messages API, takže Claude Code může komunikovat přímo s Ollama modely.
-
-### Klíčové body z preview
-
-- Ollama v0.14.0+ podporuje Anthropic Messages API → Claude Code kompatibilita
-- Ideální pro privacy-conscious projekty, air-gapped systémy, nebo vyhnutí se API costům
-- Autor testoval integraci od oznámení a dokumentoval chyby/pastýřky
-- Workflow: lokální modely bez odesílání každého requestu do cloudu
-
-### Nastavení Ollama s Claude Code
-
-```bash
-# Lokální Ollama
-export ANTHROPIC_AUTH_TOKEN="ollama"
-export ANTHROPIC_API_KEY=""
-export ANTHROPIC_BASE_URL="http://localhost:11434"
-claude --model devstral-small-2
-
-# Cloud modely přes Ollama
-ollama pull kimi-k2.5:cloud
-claude --model kimi-k2.5:cloud
-```
-
-### Varování z preview
-
-- Autor zmiňuje "všechny chyby, které tě budou stát čas" — konkrétní detaily za paywallem
-- Free tier Ollama Cloud má omezený usage
-
-## Zdroje
-
-- [Ollama Claude Code Integration](https://docs.ollama.com/integrations/claude-code)
-- [cc-compatible-models](https://github.com/Alorse/cc-compatible-models)

cml/raw/_done/claude-code-openrouter-beast-mode-low-cost.md

@@ -1,40 +0,0 @@
-# How I'm Using Claude Code Like Cline With OpenRouter (To Go Beast Mode at Low Cost)
-
-**Autor:** Joe Njenga
-**URL:** https://medium.com/@joe.njenga/how-im-using-claude-code-like-cline-with-openrouter-to-go-beast-mode-at-low-cost-8c78e0bdcb67
-**Datum:** Jan 18, 2026
-**Status:** 🔒 Member-only (paywall) — pouze preview dostupný
-
----
-
-## Dostupný obsah (preview)
-
-Claude Code + OpenRouter integrace pro low-cost coding. OpenRouter nedávno přidal Claude Code do své unified API platformy. Článek ukazuje, jak nastavit Claude Code s OpenRouter podobně jako Cline (VS Code extension) — svoboda volby modelu bez lock-in na jednoho providera.
-
-### Klíčové body z preview
-
-- OpenRouter integroval Claude Code do unified API
-- Cline-like workflow: volit jakýkoliv model (GPT-4, Claude, nové modely) bez provider lock-in
-- Nastavení přes env vars: `ANTHROPIC_BASE_URL`, `ANTHROPIC_AUTH_TOKEN`, `ANTHROPIC_API_KEY`, `ANTHROPIC_MODEL`
-- Cílem: x10 budget efficiency oproti nativnímu Claude API
-
-### Nastavení OpenRouter s Claude Code
-
-```bash
-export ANTHROPIC_BASE_URL=https://openrouter.ai/api
-export ANTHROPIC_AUTH_TOKEN=YOUR_OPENROUTER_KEY
-export ANTHROPIC_API_KEY=
-export ANTHROPIC_MODEL="openai/gpt-oss-120b:free"
-```
-
-Prázdný `ANTHROPIC_API_KEY` zabraňuje fallback na Anthropic API.
-
-### Modely zmíněné v článku
-
-- Minimax přes OpenRouter: ~98% levnější než Opus 4.5
-- GLM, DeepSeek, Kimi — další low-cost alternativy přes OpenRouter
-
-## Zdroje
-
-- [OpenRouter Integration](https://openrouter.ai/docs/guides/guides/claude-code-integration)
-- [cc-compatible-models](https://github.com/Alorse/cc-compatible-models)

cml/raw/_done/lego-mindstorms-continued-use.md

@@ -1,3 +0,0 @@
-https://blog.robotmak3rs.com
-
-Topic: How to continue using LEGO Mindstorms products (after discontinuation / in alternative ways).

cml/raw/_done/pi-coding-agent-mario-zechner.md

@@ -1,49 +0,0 @@
-# I Hated Every Coding Agent, So I Built My Own — Mario Zechner (Pi)
-
-**Source URL:** https://www.youtube.com/watch?v=Dli5slNaJu0
-**Type:** Video / Talk
-**Date:** 2026 (approx)
-**Speaker:** Mario Zechner (creator of Pi coding agent, also known as badlogic — libGDX author)
-
-## Why Pi was created
-
-Mario was frustrated by existing coding agents (Claude Code, OpenCode, Codex CLI, AMP) for several reasons:
-
-1. **Feature bloat** — agents pile on features (built-in to-dos, complex tool suites) that aren't needed and add hidden context injection
-2. **Hidden behaviors** — vendors change things under the hood (system prompts, context injection) that make LLMs behave unpredictably with existing workflows
-3. **Poor observability** — hard to see what the agent is actually doing, what context it's using, how much it costs
-4. **Lack of extensibility** — no way for power users to add custom tools or modify behavior without forking
-5. **Approval fatigue** — agents offer either full autonomy or approval for every action; both are bad UX
-6. **Poor context management** — agents like OpenCode rely on session compaction but lose important context
-
-Key quote: *"So obviously they're doing things right, but not for me."*
-
-## Pi's design philosophy
-
-- **Minimal core** — only 4 tools: read file, write file, edit file, bash. That's all you need.
-- **Tiny system prompt** — frontier RL-trained models don't need massive system prompts
-- **Tree-structured sessions** — not linear chat history; sub-agents can branch and read files independently while preserving context/lineage
-- **Full cost tracking** — built-in, not an afterthought
-- **Hot-reloadable TypeScript extensions** — users can define custom tools, UIs, multi-agent setups without modifying core
-- **No hidden context injection** — what you see is what the model gets
-
-## Community extensions
-
-- **pi-annotate** — visual feedback on live websites
-- **pi-messenger** — multi-agent chatroom with custom UI
-- Custom UIs, tool integrations — all as hot-reloadable TS modules
-
-## Performance
-
-On TerminalBench, Pi (with Claude Opus 4.5) scored close to Terminus even before advanced optimizations like compaction.
-
-## Key insight
-
-*"We are in the messing around and finding out stage, and nobody has any idea what the perfect coding agent should look like."* — simplification can lead to effective performance without unnecessary complexity.
-
-## Related
-
-- Pi website: https://pi.dev/
-- Pi GitHub: https://github.com/earendil-works/pi
-- Pi is part of OpenClaw ecosystem
-- Mario Zechner is also the author of libGDX (Java game dev framework)

cml/raw/_done/pi-dev-terminal-limitation.md

@@ -1,5 +0,0 @@
-# pi.dev — terminálová limitace
-
-pi.dev je pěkný projekt, ale limitace na terminal je až moc přísná a omezující. Bez IDE to ztrácí všechny výhodné vlastnosti — podobně jako opencode.
-
-Terminal-only přístup výrazně omezuje uživatelskou zkušenost a produktivitu oproti plnohodnotnému IDE integrovanému řešení.

cml/raw/_hard/pi-dev-video-dli5slnaju0.md

@@ -1,3 +0,0 @@
-# Pi.dev — zajímavé video
-
-Video k pi.dev: https://www.youtube.com/watch?v=Dli5slNaJu0

cml/wiki/.page-template.md

@@ -1,26 +0,0 @@
----
-type: <source|entity|concept|synthesis>
-title: ""
-tags: []
-sources: []
-created: YYYY-MM-DD
-updated: YYYY-MM-DD
----
-
-# Title
-
-Lead paragraph: a clear, encyclopedic definition or framing of what this page is about. Should answer "what is this and why does it matter" in one or two sentences.
-
-## Section 1
-
-Body content. Use `[[wikilinks]]` liberally to cross-reference other pages. (Frontmatter `sources:` list above uses bare slugs; only the body uses double-bracket wikilinks.)
-
-## Section 2
-
-More body content. Hedge claims that aren't yet corroborated by multiple sources ("Source X claims Y, though this is not yet corroborated by other sources in the wiki").
-
-## Where this fits
-
-(For source pages.) List the entity and concept pages this source touches:
-- [[entity-page-1]]
-- [[concept-page-1]]

cml/wiki/SCHEMA.md

@@ -1,121 +0,0 @@
-# Wiki Schema
-
-This file is the configuration for this wiki. It documents the conventions, page types, tag taxonomy, and any workflow customizations. The LLM reads this first when entering the wiki, and its conventions override the defaults documented in the `llm-wiki` skill.
-
-This file is **co-evolved with the user**. When the LLM notices a recurring pattern in your edits or feedback that isn't here, it will propose adding it. When something here stops fitting, prune it.
-
-## Wiki location
-
-- Wiki root: `wiki/`
-- Raw sources: `raw/`
-- Asset/image storage: `raw/assets/`
-
-## Page types
-
-This wiki uses these page types, each with a dedicated subdirectory:
-
-- `source` (in `wiki/sources/`) — one summary page per ingested source.
-- `entity` (in `wiki/entities/`) — pages about specific things: people, papers, products, places, organizations.
-- `concept` (in `wiki/concepts/`) — pages about ideas, methods, frameworks, abstractions.
-- `synthesis` (in `wiki/synthesis/`) — cross-cutting analyses, comparisons, query answers filed back.
-
-Add additional types here as the wiki evolves.
-
-## Tag taxonomy
-
-(Empty initially. Add tags here as you adopt them, with one-line descriptions. Keep this list small and disciplined — a wiki with 200 tags has effectively no tags.)
-
-Example structure:
-- `methodology` — pages about research or analytical methods.
-- `open-question` — pages or sections that flag unresolved questions.
-- `contested` — pages where sources contradict.
-
-## Page sizing
-
-- Soft cap: 400 lines / ~2,000 words. Consider splitting beyond this.
-- Hard cap: 800 lines. Must split.
-
-## Frontmatter requirements
-
-Every page must have:
-- `type`
-- `title`
-- `tags`
-- `created`
-- `updated`
-
-Plus type-specific:
-- `source` pages: `authors`, `url` (if applicable), `raw`, `ingested`
-- Non-source pages: `sources` listing the source-summary pages drawn from
-
-## Optional graph metadata
-
-Pages may declare typed graph metadata under a top-level `graph:` key. This is the source of truth for the compiled knowledge graph under `wiki/graph/`. Markdown remains canonical; the graph is a regenerable index. Pages without `graph:` still appear as nodes (derived from `type`/`kind`) and still contribute `mentions` edges from body `[[wikilinks]]`.
-
-```yaml
-graph:
-  node_id: person:praney-behl       # optional; default <node_type>:<slug>
-  node_type: person                  # optional; default mapped from type/kind via ontology
-  canonical: true                    # mark as canonical when multiple slugs alias the same entity
-  aliases: [Praney, praney@example.com]
-  relationships:
-    - predicate: founded
-      object: company:seedblocks
-      source: praney-founder-context-dump   # source-page slug
-      evidence: "Solo technical founder and sole director..."
-      confidence: high               # high | medium | low
-      status: current                # current | historical | proposed | disputed | superseded
-      # optional:
-      # valid_from: 2025-01-15
-      # valid_to: 2026-03-01
-      # notes: "..."
-      # raw_ref: "raw/founder-dump.md#L42"
-      # contradicts: edge-id-or-source-slug
-      # supersedes: edge-id-or-source-slug
-```
-
-Required fields on every relationship: `predicate`, `object`, `source`, `evidence`, `confidence`, `status`. Predicates and the subject/object types they accept are declared in `wiki/graph/ontology.yaml`. Typed semantic edges must be supported by an explicit source — never emit one inferred from training data alone.
-
-## Index structure
-
-(Update this section when sharding.)
-
-Currently flat: a single `wiki/index.md` listing all pages.
-
-When the wiki passes ~150 pages or `index.md` exceeds 300 lines, shard into `wiki/indexes/<type>.md` and update this section.
-
-## Graph layer
-
-The wiki has an optional compiled graph layer under `wiki/graph/`:
-
-- `wiki/graph/ontology.yaml` — declares node types and predicates. **Tracked.** Edit this when you introduce new predicates or domain types.
-- `wiki/graph/nodes.jsonl`, `wiki/graph/edges.jsonl` — generated. Track in git only if you want graph diffs in PRs.
-- `wiki/graph/graph.sqlite` — generated. Gitignored by default.
-- `wiki/graph/graph.graphml` — generated. Track only if you want to diff it.
-
-Generation is reproducible from markdown via `scripts/wiki_graph_extract.py`. The graph can be deleted at any time and rebuilt without losing knowledge — markdown is canonical.
-
-## Workflow customizations
-
-### Paywalled sources
-
-Sites like `medium.com` (member-only stories) often return only a preview when fetched. When a source is paywalled:
-
-1. **Capture what's available.** Fetch the URL, extract whatever preview/abstract is accessible, and write it into `cml/raw/<slug>.md` with a `🔒 paywall` marker and the original URL.
-2. **Never fabricate.** Do not infer or hallucinate content behind the paywall. If only the title and first paragraph came through, that's all the source page gets.
-3. **Flag in source page frontmatter.** Add `paywall: true` to the frontmatter of the corresponding `wiki/sources/<slug>.md` page so future queries know the coverage is partial.
-4. **Compile normally.** A paywalled source still gets a source-summary page — just with limited content. The wiki should reflect what we actually have, not what we wish we had.
-5. **Known paywall domains** (non-exhaustive): `medium.com`, `substack.com` (paid posts), `ft.com`, `wsj.com`, `nytimes.com` (soft paywall), `bloomberg.com`. When fetching from these, expect partial content and handle accordingly.
-
-## User preferences
-
-(Empty initially. As the user expresses style preferences — "always include a 'Why this matters' section on concept pages", "never use bullet lists in summaries", "prefer comparative tables for synthesis pages" — capture them here so they persist across sessions.)
-
-## Lint cadence
-
-- Structural lint: after every 5 ingests.
-- Semantic lint: weekly or after every 20 ingests.
-- Gap-finding: monthly.
-- Graph lint + extract: after every ingest that adds typed `graph.relationships`.
-
-Adjust based on the wiki's growth rate.

cml/wiki/concepts/coding-agent-setup.md

@@ -1,43 +0,0 @@
----
-type: concept
-title: "Coding agent setup"
-tags: [coding-agent, setup, configuration, workflow]
-sources: [claude-code-local-cloud-models, claude-code-ollama-workflow, claude-code-openrouter-beast-mode]
-created: 2026-06-18
-updated: 2026-06-18
-graph:
-  node_id: concept:coding-agent-setup
-  canonical: true
-  relationships:
-    - predicate: depends_on
-      object: concept:coding-agent
-      source: claude-code-local-cloud-models
-      evidence: "Setup je krok před použitím coding agenta"
-      confidence: high
-      status: current
----
-
-# Coding agent setup
-
-Koncept konfigurace a nastavení coding agentů pro praktické použití. Zahrnuje volbu modelu, API endpointu, nákladovou optimalizaci a workflow.
-
-## Klíčové aspekty
-
-- **Volba modelu** — lokální (Ollama) vs. cloud (OpenRouter, nativní API)
-- **Konfigurace** — `.claude/settings.json`, env vars (`ANTHROPIC_MODEL`, `OPENAI_API_BASE`, `OPENAI_API_KEY`)
-- **Nákladová optimalizace** — OpenRouter pro beast mode, Ollama pro zdarma
-- **Workflow** — jak efektivně pracovat s agentem v terminálu
-
-## Konfigurace Claude Code
-
-1. **Ollama**: `OPENAI_API_BASE=http://localhost:11434/v1`, `OPENAI_API_KEY=ollama`
-2. **OpenRouter**: `OPENAI_API_BASE=https://openrouter.ai/api/v1`, `OPENAI_API_KEY=<klíč>`
-3. **Nativní API**: defaultní konfigurace, `ANTHROPIC_API_KEY`
-
-## Související
-
-- [[product-claude-code]] — hlavní coding agent
-- [[product-ollama]] — lokální inference
-- [[product-openrouter]] — cloud proxy
-- [[local-vs-cloud-models]] — trade-offy
-- [[cost-optimization]] — optimalizace nákladů

cml/wiki/concepts/coding-agent.md

@@ -1,57 +0,0 @@
----
-type: concept
-title: "Coding agent"
-tags: [coding-agent, llm, tool-design, agent-architecture]
-sources: [pi-coding-agent-mario-zechner, pi-dev-terminal-limitation, claude-code-local-cloud-models, claude-code-ollama-workflow, claude-code-openrouter-beast-mode, claude-code-goal-command]
-created: 2026-06-16
-updated: 2026-06-22
-graph:
-  node_id: concept:coding-agent
-  canonical: true
-  relationships:
-    - predicate: depends_on
-      object: concept:llm
-      source: pi-coding-agent-mario-zechner
-      evidence: "Coding agenti využívají LLM jako jádro"
-      confidence: high
-      status: current
----
-
-# Coding agent
-
-Software nástroj, který využívá LLM k autonomnímu nebo poloautonomnímu psaní, úpravě a správě kódu. Typicky nabízí schopnosti jako čtení/zápis souborů, spouštění příkazů, vyhledávání v codebase a správu kontextu.
-
-## Běžné problémy (podle Maria Zechnera)
-
-- **Feature bloat** — agenti nabírají funkce, které nejsou potřeba a přidávají skrytou kontextovou injekci.
-- **Skryté chování** — vendoři mění system prompty a kontext bez transparentnosti.
-- **Špatná pozorovatelnost** — těžké vidět, co agent dělá a kolik stojí.
-- **Chybějící rozšiřitelnost** — power user nemůže přidat vlastní nástroje bez forku.
-- **Approval fatigue** — buď plná autonomie, nebo approval pro každou akci.
-- **Špatná správa kontextu** — session compaction ztrácí důležitý kontext.
-
-## Příklady
-
-- [[product-pi]] — minimalistický agent (4 nástroje, tree-structured sessions)
-- Claude Code, OpenCode, Codex CLI, AMP, Cline — zmínění konkurenti
-
-## Modely a konfigurace
-
-- [[local-vs-cloud-models]] — trade-offy mezi lokálními a cloud modely
-- [[coding-agent-setup]] — konfigurace a nastavení
-- [[cost-optimization]] — optimalizace nákladů na API
-
-## Související
-
-- [[tree-structured-sessions]] — Piův přístup ke správě kontextu
-- [[terminal-limitation]] — společná limitace terminal-only agentů
-- [[pi-coding-agent-mario-zechner]] — zdroj (talk)
-- [[pi-dev-terminal-limitation]] — zdroj (poznámka o terminálové limitaci)
-- [[claude-code-local-cloud-models]] — zdroj (Ollama/OpenRouter/llama.cpp setup)
-- [[claude-code-ollama-workflow]] — zdroj (Ollama workflow návod)
-- [[claude-code-openrouter-beast-mode]] — zdroj (OpenRouter beast mode)
-- [[claude-code-goal-command]] — zdroj (/goal příkaz dokumentace)
-
-## Autonomní běh
-
-- [[goal-driven-agent-loop]] — koncept autonomního agenta s verifikovatelnou koncovou podmínkou

cml/wiki/concepts/cost-optimization.md

@@ -1,42 +0,0 @@
----
-type: concept
-title: "Cost optimization"
-tags: [llm, cost, api, coding-agent]
-sources: [claude-code-openrouter-beast-mode]
-created: 2026-06-18
-updated: 2026-06-18
-graph:
-  node_id: concept:cost-optimization
-  canonical: true
-  relationships:
-    - predicate: depends_on
-      object: concept:coding-agent
-      source: claude-code-openrouter-beast-mode
-      evidence: "Cost optimization je relevantní v kontextu coding agentů"
-      confidence: medium
-      status: current
----
-
-# Cost optimization
-
-Koncept optimalizace nákladů na LLM API při používání coding agentů. Klíčové pro dlouhodobě udržitelné používání.
-
-## Strategie
-
-- **OpenRouter proxy** — přístup k modelům za zlomek ceny nativního API
-- **Lokální modely** — nulové API náklady, ale nižší kvalita
-- **Model switching** — použití levnějších modelů pro jednoduché úkoly, výkonných pro komplexní
-- **Beast mode** — cílené použití nejvýkonnějších modelů přes nízkonákladový proxy
-
-## Praktické poznatky
-
-- OpenRouter ceny jsou výrazně nižší než přímé API přístupy
-- Lokální modely (3B–8B) jsou zdarma, ale kvalita stačí jen pro jednoduché úkoly
-- Hybridní přístup (lokální pro rutinu, cloud pro komplexní úkoly) je nejefektivnější
-
-## Související
-
-- [[product-openrouter]] — klíčový nástroj pro cost optimization
-- [[product-ollama]] — lokální alternativa
-- [[local-vs-cloud-models]] — trade-offy
-- [[coding-agent-setup]] — konfigurace

cml/wiki/concepts/e-waste-reduction.md

@@ -1,29 +0,0 @@
----
-type: concept
-title: "E-waste reduction"
-tags: [e-waste, sustainability, longevity, hardware]
-sources: [source-lego-mindstorms-continued-use]
-created: 2026-06-20
-updated: 2026-06-20
-graph:
-  node_id: concept-e-waste-reduction
-  canonical: true
-  edges:
-    - predicate: improves_on
-      object: concept-software-preservation
----
-
-# E-waste reduction
-
-Koncept prodloužení životnosti elektronických produktů — snižování množství e-waste tím, že hardware zůstává funkční i po ukončení oficiální softwarové podpory.
-
-## Příklad: LEGO Mindstorms
-
-Stovky tisíc až miliony sad Mindstorms po celém světě by se bez softwarové alternativy staly e-waste. [[product-pybricks]] tento trend obrací — open-source firmware dává EV3 brickům nový život s moderním programováním a okamžitým bootem.
-
-Pybricks argumentuje, že technologie LEGO robotiky se za 20 let fundamentálně nezměnila — všechny sady mají smart hub, motory, senzory. Rozdíl je v softwarové zkušenosti, kterou lze obnovit.
-
-## Odkazy
-
-- [[source-lego-mindstorms-continued-use]] — zdroj o Mindstorms a Pybricks
-- [[concept-software-preservation]] — softwarová stránka zachování produktů

cml/wiki/concepts/goal-driven-agent-loop.md

@@ -1,38 +0,0 @@
----
-type: concept
-title: "Goal-driven agent loop"
-tags: [coding-agent, agent-loop, evaluation, autonomy, goal]
-sources: [source-claude-code-goal-command]
-created: 2026-06-22
-updated: 2026-06-22
-graph:
-  node_id: concept-goal-driven-agent-loop
-  canonical: true
----
-
-# Goal-driven agent loop
-
-Koncept autonomního agenta, který pracuje dokud není splněna verifikovatelná koncová podmínka. Po každém turnu nezávislý evaluátor (menší model) posoudí, zda cíl byl dosažen.
-
-## Klíčové vlastnosti
-
-- **Verifikovatelná podmínka** — cíl musí být měřitelný z výstupu agenta (test result, build exit code, file count)
-- **Separátní evaluátor** — jiný model než agent sám posuzuje dokončení, čímž se eliminuje konflikt zájmů
-- **Autonomní iterace** — agent pokračuje bez dalšího promptu uživatele, evaluátor poskytuje guidance pro další turn
-- **Omezení běhu** — turn/time klauzule (např. "or stop after 20 turns") brání nekonečnému běhu
-
-## Implementace v [[product-claude-code]]
-
-Claude Code `/goal` příkaz: podmínka až 4000 znaků, evaluátor defaultně Haiku, funguje v interaktivním i non-interactive režimu. Komplementární s auto mode (schvaluje tool calls) — dohromady umožňují plně autonomní běh.
-
-## Porovnání s jinými přístupy
-
-- **`/loop`** — časový interval místo podmínky; vhodné pro opakující se úlohy
-- **Stop hook** — vlastní skript/prompt pro evaluaci; flexibilnější ale složitější
-- **Auto mode** — schvaluje tool calls v rámci turnu, ale nezačíná další turn
-
-## Související
-
-- [[source-claude-code-goal-command]] — zdroj (oficiální dokumentace)
-- [[product-claude-code]] — implementace /goal příkazu
-- [[coding-agent]] — obecný koncept

cml/wiki/concepts/local-vs-cloud-models.md

@@ -1,48 +0,0 @@
----
-type: concept
-title: "Local vs. cloud models"
-tags: [llm, local-models, cloud-models, cost, privacy]
-sources: [claude-code-local-cloud-models, claude-code-ollama-workflow, claude-code-openrouter-beast-mode]
-created: 2026-06-18
-updated: 2026-06-18
-graph:
-  node_id: concept:local-vs-cloud-models
-  canonical: true
-  relationships:
-    - predicate: depends_on
-      object: concept:coding-agent
-      source: claude-code-local-cloud-models
-      evidence: "Lokální vs. cloud modely jsou relevantní primárně v kontextu coding agentů"
-      confidence: medium
-      status: current
----
-
-# Local vs. cloud models
-
-Koncept volby mezi lokální inference (Ollama, llama.cpp) a cloud API (OpenRouter, nativní API) pro běh LLM modelů, zejména v kontextu coding agentů.
-
-## Trade-offy
-
-| Aspekt | Lokální (Ollama) | Cloud (OpenRouter) |
-|--------|-------------------|-------------------|
-| Náklady | Nulové (vlastní HW) | Pay-per-token |
-| Soukromí | Plné | Omezené |
-| Kvalita | Nižší (menší modely) | Vyšší (nejlepší modely) |
-| Latence | Nízká (lokální) | Vyšší (síť) |
-| Dostupnost | Závislá na HW | Vždy dostupné |
-| Flexibilita | Omezená na lokální modely | Široký výběr |
-
-## Praktické poznatky
-
-- Pro jednoduché úkoly stačí lokální modely (3B–8B parametrů)
-- Pro komplexní úkoly je cloud s výkonnými modely nezbytný
-- OpenRouter umožňuje hybridní přístup — snadné přepínání mezi lokálními a cloud modely
-- Beast mode = cloud s nejvýkonnějšími modely za nízkonákladový proxy
-
-## Související
-
-- [[product-ollama]] — lokální inference server
-- [[product-openrouter]] — cloud proxy
-- [[product-claude-code]] — coding agent podporující oba přístupy
-- [[coding-agent-setup]] — koncept nastavení coding agentů
-- [[cost-optimization]] — optimalizace nákladů

cml/wiki/concepts/micropython.md

@@ -1,23 +0,0 @@
----
-type: concept
-title: "MicroPython"
-tags: [python, firmware, embedded, robotics]
-sources: [source-lego-mindstorms-continued-use]
-created: 2026-06-20
-updated: 2026-06-20
-graph:
-  node_id: concept-micropython
-  canonical: true
----
-
-# MicroPython
-
-Lehká implementace Pythonu 3 optimalizovaná pro mikrokontroléry a embedded zařízení. Používá [[product-pybricks]] jako programovací jazyk pro LEGO robotiku — nahrazuje proprietární LEGO software otevřenou alternativou s plnohodnotným Python API.
-
-## V kontextu LEGO robotiky
-
-Pybricks běží MicroPython přímo na LEGO hubech (EV3, Robot Inventor, SPIKE Prime). Uživatelé píší standardní Python kód, který se spouští na bricku v reálném čase — žádná závislost na cloudových službách nebo proprietárních aplikacích.
-
-## Odkazy
-
-- [[product-pybricks]] — implementace MicroPython pro LEGO huby

cml/wiki/concepts/software-preservation.md

@@ -1,33 +0,0 @@
----
-type: concept
-title: "Software preservation"
-tags: [preservation, software, e-waste, longevity]
-sources: [source-lego-mindstorms-continued-use]
-created: 2026-06-20
-updated: 2026-06-20
-graph:
-  node_id: concept-software-preservation
-  canonical: true
-  edges:
-    - predicate: improves_on
-      object: concept-e-waste-reduction
----
-
-# Software preservation
-
-Koncept zachování softwaru a jeho funkčnosti po ukončení oficiální podpory. Kritický pro produkty, které závisí na aplikacích nebo serverech — bez softwaru se hardware stává e-waste.
-
-## Problém
-
-Jakýkoli gadget vyžadující počítač nebo telefon se rychle stává zastaralým, když původní aplikace přestanou fungovat na nových zařízeních. To platí i pro elektronické LEGO — Mindstorms aplikace mizí z app store a in-app content (tutoriály, build instrukce) je uložen v privátním app storage, který nelze zálohovat bez root přístupu.
-
-## Řešení
-
-- **Archivace instalátorů i app dat** — samotný APK/exe nestačí, potřebné jsou i in-app resources
-- **Komunitní firmware** — [[product-pybricks]] nahrazuje oficiální aplikace open-source alternativou
-- **Root přístup** — na Androidu nutný pro obnovu privátních app dat (blog robotmak3rs.com dokumentuje postupy)
-
-## Odkazy
-
-- [[source-lego-mindstorms-continued-use]] — případová studie Mindstorms
-- [[concept-e-waste-reduction]] — širší kontext snižování e-waste

cml/wiki/concepts/terminal-limitation.md

@@ -1,44 +0,0 @@
----
-type: concept
-title: "Terminal limitation"
-tags: [coding-agent, terminal, ide, ux, limitation]
-sources: [pi-dev-terminal-limitation]
-created: 2026-06-16
-updated: 2026-06-16
-graph:
-  node_id: concept:terminal-limitation
-  canonical: true
-  relationships:
-    - predicate: depends_on
-      object: concept:coding-agent
-      source: pi-dev-terminal-limitation
-      evidence: "Terminal limitation je problém specifický pro coding agenty"
-      confidence: high
-      status: current
----
-
-# Terminal limitation
-
-Koncept omezení coding agentů, kteří fungují pouze v terminálovém prostředí (terminal-only), bez plnohodnotné IDE integrace.
-
-## Problém
-
-Terminal-only přístup u coding agentů:
-- **Ztrácí výhodné vlastnosti** — bez IDE chybí vizuální kontext, navigace v kódu, integrace s debuggerem atd.
-- **Omezuje UX a produktivitu** — terminál není dostatečný pro komplexní interakci s kódem.
-- **Je společný pro více agentů** — např. [[product-pi|Pi]] i OpenCode sdílejí tuto limitaci.
-
-## Srovnání
-
-| Aspekt | Terminal-only | IDE integrovaný |
-|--------|--------------|-----------------|
-| Vizuální kontext | Omezený | Plný |
-| Navigace v kódu | Textová | Grafická |
-| Debugging | Omezený | Plný |
-| Rozšiřitelnost UI | Minimální | Plná |
-
-## Související
-
-- [[product-pi]] — Pi coding agent (terminal-only)
-- [[coding-agent]] — obecný koncept
-- [[pi-dev-terminal-limitation]] — zdroj (poznámka)

cml/wiki/concepts/tree-structured-sessions.md

@@ -1,41 +0,0 @@
----
-type: concept
-title: "Tree-structured sessions"
-tags: [coding-agent, agent-architecture, context-management]
-sources: [pi-coding-agent-mario-zechner]
-created: 2026-06-16
-updated: 2026-06-16
-graph:
-  node_id: concept:tree-structured-sessions
-  relationships:
-    - predicate: depends_on
-      object: concept:coding-agent
-      source: pi-coding-agent-mario-zechner
-      evidence: "Tree-structured sessions jsou designový vzor pro coding agenty"
-      confidence: high
-      status: current
----
-
-# Tree-structured sessions
-
-Designový vzor pro správu kontextu v coding agentech, zavedený v [[product-pi|Pi]]. Místo lineární chat historie (kde se kontext komprimuje a ztrácí) se session větví jako strom — sub-agenti mohou nezávisle číst soubory a pracovat, přičemž zachovávají lineage a kontext rodičovské session.
-
-## Problém, který řeší
-
-Lineární chat historie v coding agentech vede k:
-- Ztrátě důležitého kontextu při compaction
-- Nemožnosti paralelně zkoumat různé větve řešení
-- Nepružnému řízení — buď vše v jedné session, nebo nová session od nuly
-
-## Princip
-
-- Session je strom (tree), ne seznam (list).
-- Sub-agent se může odvětvit od libovolného bodu v konverzaci.
-- Každý uzel má přístup k souborům a může číst nezávisle.
-- Lineage (původ) je zachována — lze sledovat, odkud sub-agent vznikl.
-
-## Související
-
-- [[coding-agent]] — obecný koncept
-- [[product-pi]] — agent, který tento vzor implementuje
-- [[pi-coding-agent-mario-zechner]] — zdroj (talk)

cml/wiki/entities/person-mario-zechner.md

@@ -1,29 +0,0 @@
----
-type: entity
-kind: person
-title: "Mario Zechner"
-tags: [person, developer, coding-agent, game-dev]
-sources: [pi-coding-agent-mario-zechner]
-created: 2026-06-16
-updated: 2026-06-16
-graph:
-  node_id: person:mario-zechner
-  canonical: true
-  relationships:
-    - predicate: works_on
-      object: product:pi
-      source: pi-coding-agent-mario-zechner
-      evidence: "Mario Zechner je tvůrce Pi coding agenta"
-      confidence: high
-      status: current
----
-
-# Mario Zechner
-
-Mario Zechner (aka badlogic) je vývojář a tvůrce Pi coding agenta. Je také autorem libGDX, populárního Java frameworku pro vývoj her.
-
-## Související
-
-- [[product-pi]] — coding agent, který vytvořil
-- [[coding-agent]] — obecný koncept
-- [[pi-coding-agent-mario-zechner]] — zdroj (talk)

cml/wiki/entities/product-claude-code.md

@@ -1,42 +0,0 @@
----
-type: entity
-kind: product
-title: "Claude Code"
-tags: [coding-agent, llm, tool, anthropic]
-sources: [pi-coding-agent-mario-zechner, claude-code-local-cloud-models, claude-code-ollama-workflow, claude-code-openrouter-beast-mode, claude-code-goal-command]
-created: 2026-06-17
-updated: 2026-06-22
-graph:
-  node_id: product:claude-code
-  canonical: true
----
-
-# Claude Code
-
-Coding agent od Anthropic, běžící v terminálu. Podporuje lokální modely (Ollama, llama.cpp) i cloud proxy (OpenRouter) pro cost optimization. Nabízí `/goal` příkaz pro autonomní práci s verifikovatelnou koncovou podmínkou.
-
-## Klíčové funkce
-
-- **`/goal` příkaz** — nastaví verifikovatelnou koncovou podmínku, agent pracuje autonomně dokud není splněna; evaluátor (defaultně Haiku) posuzuje dokončení po každém turnu
-- **Auto mode** — automatické schvalování tool calls v rámci turnu
-- **`/loop`** — opakované spouštění promptu v časovém intervalu
-- **Non-interactive** — běh s `-p` flagou, desktop app, Remote Control
-
-## Konfigurace modelů
-
-- **Ollama** — lokální inference, nulové náklady, `OPENAI_API_BASE=http://localhost:11434/v1`
-- **OpenRouter** — cloud proxy, pay-per-token, beast mode, `OPENAI_API_BASE=https://openrouter.ai/api/v1`
-- **Nativní API** — defaultní, nejvyšší kvalita, nejvyšší náklady
-
-## Související
-
-- [[product-pi]] — konkurenční coding agent
-- [[product-ollama]] — lokální inference server
-- [[product-openrouter]] — cloud proxy
-- [[product-cline]] — konkurenční VS Code agent
-- [[coding-agent]] — obecný koncept
-- [[local-vs-cloud-models]] — trade-offy
-- [[coding-agent-setup]] — konfigurace
-- [[cost-optimization]] — optimalizace nákladů
-- [[goal-driven-agent-loop]] — koncept autonomního agenta s koncovou podmínkou
-- [[claude-code-goal-command]] — zdroj (/goal dokumentace)

cml/wiki/entities/product-cline.md

@@ -1,40 +0,0 @@
----
-type: entity
-kind: product
-title: "Cline"
-tags: [coding-agent, llm, tool, vscode-extension]
-sources: [claude-code-openrouter-beast-mode]
-created: 2026-06-18
-updated: 2026-06-18
-graph:
-  node_id: product:cline
-  canonical: true
-  relationships:
-    - predicate: competes_with
-      object: product:claude-code
-      source: claude-code-openrouter-beast-mode
-      evidence: "Autor srovnává Claude Code s Cline — 'like Cline' v titulku článku"
-      confidence: medium
-      status: current
----
-
-# Cline
-
-VS Code rozšíření fungující jako coding agent. Podobný koncept jako Claude Code, ale integrovaný přímo do IDE (VS Code).
-
-## Klíčové vlastnosti
-
-- **VS Code integrace** — běží přímo v editoru, ne v terminálu
-- **Multi-model** — podporuje různé LLM backendy přes API
-- **Autonomní akce** — čte, píše a spouští kód v kontextu projektu
-
-## Srovnání s Claude Code
-
-- Cline = IDE integrovaný, Claude Code = terminálový
-- Cline má vizuální kontext editoru, Claude Code má větší flexibilitu modelů
-- Oba podporují OpenRouter pro cost optimization
-
-## Související
-
-- [[product-claude-code]] — konkurenční coding agent
-- [[source-claude-code-openrouter-beast-mode]] — zdroj srovnání

cml/wiki/entities/product-lego-mindstorms.md

@@ -1,43 +0,0 @@
----
-type: entity
-title: "LEGO Mindstorms"
-kind: product
-tags: [lego, mindstorms, robotics, education, discontinued]
-sources: [source-lego-mindstorms-continued-use]
-created: 2026-06-20
-updated: 2026-06-20
-graph:
-  node_id: product-lego-mindstorms
-  canonical: true
-  edges:
-    - predicate: competes_with
-      object: product-spike-prime
-    - predicate: extended_by
-      object: product-pybricks
----
-
-# LEGO Mindstorms
-
-Sada robotických stavebnic od LEGO, oficiálně ukončená v říjnu 2022. Existuje ve verzích RCX (1998), NXT (2006), EV3 (2013) a Robot Inventor (2020). Celkem prodáno stovky tisíc až miliony sad po celém světě.
-
-## Ukončení a důsledky
-
-LEGO Group přesunul zdroje na SPIKE Prime a další produkty LEGO Education. Robot Inventor app měl zůstat dostupný do konce 2024, ale postupně přestává fungovat na novějších zařízeních. Oficiální aplikace mizí z app store.
-
-Problém: elektronické LEGO má mnohem kratší životnost než klasické cihly, protože závisí na softwaru. Mnoho škol a FLL týmů stále závisí na EV3 — asi 60 % týmů v roce 2023.
-
-## Nadále použitelné s [[product-pybricks]]
-
-Pybricks nahrazuje oficiální aplikace a umožňuje nadále používat Mindstorms hardware moderním způsobem — sjednocuje programování napříč všemi generacemi.
-
-## Hardware kompatibilita
-
-- Motory a senzory jsou cross-kompatibilní mezi Mindstorms a SPIKE Prime
-- Robot Inventor hub má stejný tvar jako SPIKE hub, ale SPIKE3 firmware na něj nejde nainstalovat
-- EV3 brick s Pybricks bootuje okamžitě (místo desítek sekund s původním Linuxem)
-
-## Odkazy
-
-- [[source-lego-mindstorms-continued-use]] — zdroj o pokračování používání po ukončení
-- [[product-pybricks]] — open-source firmware alternativa
-- [[product-spike-prime]] — nástupce od LEGO Education

cml/wiki/entities/product-ollama.md

@@ -1,43 +0,0 @@
----
-type: entity
-kind: product
-title: "Ollama"
-tags: [llm, inference, local-models, open-source]
-sources: [claude-code-local-cloud-models, claude-code-ollama-workflow]
-created: 2026-06-18
-updated: 2026-06-18
-graph:
-  node_id: product:ollama
-  canonical: true
-  relationships:
-    - predicate: competes_with
-      object: product:openrouter
-      source: claude-code-local-cloud-models
-      evidence: "Ollama a OpenRouter jsou alternativní způsoby připojení modelů k Claude Code"
-      confidence: medium
-      status: current
----
-
-# Ollama
-
-Lokální inference server pro běh LLM modelů. Podporuje širokou škálu modelů (Llama, Qwen, Mistral, Gemma aj.) a poskytuje OpenAI-compatible API endpoint.
-
-## Klíčové vlastnosti
-
-- **Lokální běh** — modely běží na vlastním hardware, žádné API náklady
-- **OpenAI-compatible API** — snadné připojení z Claude Code a dalších nástrojů
-- **Model management** — `ollama pull`, `ollama list`, `ollama run`
-- **Široká podpora modelů** — Llama, Qwen, Mistral, Gemma, Phi a další
-
-## Použití s Claude Code
-
-- Nastav `OPENAI_API_BASE=http://localhost:11434/v1` a `OPENAI_API_KEY=ollama`
-- Vyber model v `.claude/settings.json` nebo přes env var `ANTHROPIC_MODEL`
-- Výhoda: nulové náklady, soukromí. Nevýhoda: nižší kvalita než cloud modely.
-
-## Související
-
-- [[product-claude-code]] — coding agent, který se připojuje k Ollama
-- [[product-openrouter]] — cloud alternativa
-- [[source-claude-code-local-cloud-models]] — přehledový článek
-- [[source-claude-code-ollama-workflow]] — Ollama workflow návod

cml/wiki/entities/product-openrouter.md

@@ -1,43 +0,0 @@
----
-type: entity
-kind: product
-title: "OpenRouter"
-tags: [llm, api-proxy, cloud-models, cost-optimization]
-sources: [claude-code-local-cloud-models, claude-code-openrouter-beast-mode]
-created: 2026-06-18
-updated: 2026-06-18
-graph:
-  node_id: product:openrouter
-  canonical: true
-  relationships:
-    - predicate: competes_with
-      object: product:ollama
-      source: claude-code-local-cloud-models
-      evidence: "OpenRouter a Ollama jsou alternativní způsoby připojení modelů k Claude Code"
-      confidence: medium
-      status: current
----
-
-# OpenRouter
-
-Cloudový API proxy poskytující přístup k mnoha LLM modelům přes jednotné API. Umožňuje snadné přepínání mezi modely bez změny kódu.
-
-## Klíčové vlastnosti
-
-- **Jednotné API** — jeden endpoint pro Claude, GPT-4, Gemini, Mistral, Qwen a další
-- **Pay-per-token** — platíš jen za spotřebované tokeny, žádné měsíční poplatky
-- **Model switching** — snadné přepínání modelů v konfiguraci
-- **Beast mode** — přístup k nejvýkonnějším modelům za zlomek ceny nativního API
-
-## Použití s Claude Code
-
-- Nastav `OPENAI_API_BASE=https://openrouter.ai/api/v1` a `OPENAI_API_KEY=<klíč>`
-- Vyber model přes `model` v settings
-- Výhoda: nízké náklady, široký výběr modelů. Nevýhoda: vyšší latence, rate limity.
-
-## Související
-
-- [[product-claude-code]] — coding agent, který se připojuje přes OpenRouter
-- [[product-ollama]] — lokální alternativa
-- [[source-claude-code-local-cloud-models]] — přehledový článek
-- [[source-claude-code-openrouter-beast-mode]] — beast mode návod

cml/wiki/entities/product-pi.md

@@ -1,49 +0,0 @@
----
-type: entity
-kind: product
-title: "Pi (coding agent)"
-tags: [coding-agent, llm, tool, open-source]
-sources: [pi-coding-agent-mario-zechner, pi-dev-terminal-limitation]
-created: 2026-06-16
-updated: 2026-06-16
-graph:
-  node_id: product:pi
-  canonical: true
-  relationships:
-    - predicate: competes_with
-      object: product:claude-code
-      source: pi-coding-agent-mario-zechner
-      evidence: "Mario byl frustrován Claude Code a dalšími agenty"
-      confidence: medium
-      status: current
----
-
-# Pi (coding agent)
-
-Pi je minimalistický coding agent vytvořený Mariem Zechnerem (badlogic). Součást ekosystému OpenClaw.
-
-## Design
-
-- **4 nástroje**: read file, write file, edit file, bash — minimální jádro.
-- **Malý system prompt** — frontier modely nepotřebují masivní prompty.
-- **[[tree-structured-sessions]]** — větvení místo lineární historie; sub-agenti se mohou větvit a číst soubory nezávisle.
-- **Full cost tracking** — vestavěný.
-- **Hot-reloadable TypeScript extensions** — vlastní nástroje, UI, multi-agent setupy bez forku.
-- **Žádná skrytá kontextová injekce** — transparentní.
-- **Terminal-only** — limitace na terminálové prostředí bez IDE integrace; viz [[terminal-limitation]].
-
-## Výkon
-
-Na TerminalBench dosáhlo Pi (s Claude Opus 4.5) blízko Terminus i před pokročilými optimalizacemi.
-
-## Odkazy
-
-- Web: https://pi.dev/
-- GitHub: https://github.com/earendil-works/pi
-
-## Související
-
-- [[person-mario-zechner]] — tvůrce
-- [[coding-agent]] — obecný koncept
-- [[pi-coding-agent-mario-zechner]] — zdroj (talk)
-- [[pi-dev-terminal-limitation]] — zdroj (poznámka o terminálové limitaci)

cml/wiki/entities/product-pybricks.md

@@ -1,49 +0,0 @@
----
-type: entity
-title: "Pybricks"
-kind: product
-tags: [lego, mindstorms, firmware, open-source, robotics, python]
-sources: [source-lego-mindstorms-continued-use]
-created: 2026-06-20
-updated: 2026-06-20
-graph:
-  node_id: product-pybricks
-  canonical: true
-  edges:
-    - predicate: competes_with
-      object: product-spike-prime
-    - predicate: improves_on
-      object: concept-lego-mindstorms
-    - predicate: depends_on
-      object: concept-micropython
----
-
-# Pybricks
-
-Open-source firmware a vývojové prostředí pro LEGO robotiku — nahrazuje oficiální LEGO aplikace stabilnějším a lepším API. Podporuje všechny generace Mindstorms (NXT, EV3, Robot Inventor), SPIKE Prime, SPIKE Essential, BOOST, Powered Up a další LEGO huby.
-
-## Klíčové vlastnosti
-
-- **MicroPython + blokové programování** v prohlížeči — žádné instalace
-- **Okamžitý boot** — na rozdíl od původního EV3 Linuxu (desítky sekund)
-- **Univerzální API** napříč všemi LEGO huby
-- **Bezplatný firmware**, volitelné placené doplňky (blokové programování)
-- **Konverze bloků → Python** — na rozdíl od LEGO aplikace
-- Běží na Chromeboocích, nepotřebuje instalaci
-
-## Stav projektu EV3 (prosinec 2025)
-
-Pybricks pro EV3 je v aktivním vývoji. Dosud implementováno: instant power on/off, MicroPython firmware bez microSD karty, program storage, download přes Pybricksdev, všechny EV3 motory a senzory, NXT senzory na EV3, custom UART/I2C/analog zařízení. Zbývá: USB/Bluetooth konektivita, browser-based firmware instalace.
-
-## Vztah k [[product-lego-mindstorms]]
-
-Pybricks je hlavní komunitní alternativa k ukončenému Mindstorms softwaru. Umožňuje nadále používat Mindstorms hardware moderním způsobem — sjednocuje programování napříč generacemi a eliminuje závislost na oficiálních aplikacích, které mizí z app store.
-
-## Vztah k [[product-spike-prime]]
-
-SPIKE3 firmware nelze nainstalovat na Mindstorms hub. Pybricks naopak funguje na obou — je to univerzální alternativa, která sjednocuje ekosystém LEGO robotiky.
-
-## Odkazy
-
-- [[source-lego-mindstorms-continued-use]] — zdroj o pokračování používání Mindstorms po ukončení
-- [[concept-software-preservation]] — obecný koncept zachování softwaru

cml/wiki/entities/product-spike-prime.md

@@ -1,33 +0,0 @@
----
-type: entity
-title: "SPIKE Prime"
-kind: product
-tags: [lego, spike, education, robotics]
-sources: [source-lego-mindstorms-continued-use]
-created: 2026-06-20
-updated: 2026-06-20
-graph:
-  node_id: product-spike-prime
-  canonical: true
-  edges:
-    - predicate: competes_with
-      object: product-lego-mindstorms
-    - predicate: extended_by
-      object: product-pybricks
----
-
-# SPIKE Prime
-
-Robotická vzdělávací sada od LEGO Education — oficiální nástupce [[product-lego-mindstorms]]. LEGO přesunulo zdroje z Mindstorms na SPIKE Prime po ukončení Mindstorms v říjnu 2022.
-
-## Vztah k Mindstorms
-
-- SPIKE Prime hub má stejný tvar jako Mindstorms Robot Inventor hub
-- SPIKE2 firmware fungoval na Mindstorms hubu, ale SPIKE3 už ne — chyba při připojení
-- Motory a senzory jsou cross-kompatibilní
-- [[product-pybricks]] funguje na obou platformách a sjednocuje ekosystém
-
-## Odkazy
-
-- [[source-lego-mindstorms-continued-use]] — zdroj o ukončení Mindstorms a alternativách
-- [[product-pybricks]] — univerzální alternativa pro obě platformy

cml/wiki/graph/.gitignore

@@ -1,2 +0,0 @@
-graph.sqlite
-graph.graphml

cml/wiki/graph/README.md

@@ -1,32 +0,0 @@
-# Wiki Graph Layer
-
-This directory holds the compiled knowledge graph derived from the markdown
-wiki. **Markdown is canonical.** Everything here can be deleted and rebuilt
-without losing knowledge:
-
-```bash
-python scripts/wiki_graph_extract.py wiki/ --out wiki/graph
-```
-
-## Files
-
-| File | Purpose | Tracking |
-|------|---------|----------|
-| `ontology.yaml` | Declares node types and predicates the graph recognises. The contract `wiki_graph_lint.py` validates against. | **Tracked. Edit by hand.** |
-| `nodes.jsonl` | One JSON object per node, sorted by id. | Generated. Track if you want graph diffs in PRs; otherwise gitignore. |
-| `edges.jsonl` | One JSON object per edge, sorted by id. Includes typed semantic edges, `mentions`, `sourced_from`, and `summarizes_raw`. | Generated. Same trade-off as `nodes.jsonl`. |
-| `graph.sqlite` | Queryable index used by `wiki_graph_query.py`. Schema: `nodes`, `aliases`, `edges`. | Generated. **Gitignored** — rebuild on demand. |
-| `graph.graphml` | GraphML export for tools like Gephi or yEd. | Generated. Gitignored by default. |
-
-## Workflow
-
-1. Author or edit a wiki page. Add typed `graph.relationships` only when an explicit source supports them.
-2. Run `python scripts/wiki_graph_lint.py wiki/` — catches unknown predicates, broken object references, missing evidence, alias collisions.
-3. Run `python scripts/wiki_graph_extract.py wiki/ --out wiki/graph` — regenerates the artifacts above.
-4. Query with `python scripts/wiki_graph_query.py wiki/ neighbors --node product:konvy` (or `edges`, `path`, `facts`).
-
-## Anti-patterns
-
-- **Hand-editing `nodes.jsonl` / `edges.jsonl` / `graph.sqlite`.** Edit the markdown; regenerate.
-- **Treating graph rows as evidence.** They accelerate navigation. For high-stakes claims, follow the edge's `source` and `evidence` fields back to the wiki page and the raw source.
-- **Adding typed edges the source doesn't support.** Use a normal `[[wikilink]]` instead — the `mentions` edge captures the connection without overclaiming.

cml/wiki/graph/edges.jsonl

@@ -1,148 +0,0 @@
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "005b7b4456e37a361b1b4806", "object": "source:claude-code-openrouter-beast-mode", "page": "concepts/coding-agent-setup.md", "predicate": "sourced_from", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "concept:coding-agent-setup"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "02295972088c9f5c8e30b3a8", "object": "source:claude-code-openrouter-beast-mode", "page": "entities/product-claude-code.md", "predicate": "sourced_from", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "product:claude-code"}
-{"confidence": "high", "evidence": "Článek testuje nový Ollama workflow v Claude Code", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "03072619e5187b95b6ea91f5", "object": "product:claude-code", "page": "sources/claude-code-ollama-workflow.md", "predicate": "mentions", "source": "claude-code-ollama-workflow", "status": "current", "subject": "source:claude-code-ollama-workflow"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "0473b080e02853af2e5d89c0", "object": "source:claude-code-ollama-workflow", "page": "entities/product-ollama.md", "predicate": "sourced_from", "source": "claude-code-ollama-workflow", "status": "current", "subject": "product:ollama"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "08037ca34f81ca2ac93364f8", "object": "concept:coding-agent", "page": "concepts/terminal-limitation.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:terminal-limitation"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "09031c5b37673cdcf3f3bc1e", "object": "concept:local-vs-cloud-models", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "09ba44d58a77188279ed87f3", "object": "concept:local-vs-cloud-models", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "124b065e1f070573c072f0ee", "object": "product:ollama", "page": "sources/claude-code-ollama-workflow.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-ollama-workflow"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "12db9977d67a261ecacec3af", "object": "product:ollama", "page": "sources/claude-code-local-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-local-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "135e60cb41acf2f7be01a1f7", "object": "product-pybricks", "page": "concepts/micropython.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept-micropython"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "13aa325a2d4c93894e4b92cd", "object": "product:pi", "page": "sources/pi-coding-agent-mario-zechner.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:pi-coding-agent"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "14d0badac17898a4cbddc9c2", "object": "source:pi-coding-agent", "page": "concepts/tree-structured-sessions.md", "predicate": "sourced_from", "source": "pi-coding-agent-mario-zechner", "status": "current", "subject": "concept:tree-structured-sessions"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "159a0776ce947905f7c1f90b", "object": "product:claude-code", "page": "sources/claude-code-ollama-workflow.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-ollama-workflow"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "18d439bccd8f98e6ad73391d", "object": "product:ollama", "page": "concepts/cost-optimization.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:cost-optimization"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "191cc6717313156474e2f7a7", "object": "concept:coding-agent", "page": "concepts/tree-structured-sessions.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:tree-structured-sessions"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "1e1d0ddc4cfe11ff12dc3b8a", "object": "product:cline", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "high", "evidence": "Coding agenti využívají LLM jako jádro", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "2400d909b4dd0cb5a5e3276c", "object": "concept:llm", "page": "concepts/coding-agent.md", "predicate": "depends_on", "source": "pi-coding-agent-mario-zechner", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "25260d522577cdaea172cdba", "object": "source:claude-code-local-cloud-models", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "275303ea8901a8aaff1af046", "object": "concept-goal-driven-agent-loop", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "2a7d8a0b7acdf510dfb3dbba", "object": "source:claude-code-local-cloud-models", "page": "entities/product-ollama.md", "predicate": "sourced_from", "source": "claude-code-local-cloud-models", "status": "current", "subject": "product:ollama"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "2a94474900b255b7a29e7b15", "object": "concept:tree-structured-sessions", "page": "sources/pi-coding-agent-mario-zechner.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:pi-coding-agent"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_raw", "extras": {}, "id": "2ac884ca271d51e826665a25", "object": "raw:raw/claude-code-openrouter-beast-mode-low-cost.md", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "summarizes_raw", "source": "", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "2c2accb65865d17b083a3a21", "object": "product:ollama", "page": "entities/product-openrouter.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:openrouter"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "2cd26a265d0666b7a0b9de36", "object": "source-claude-code-goal-command", "page": "entities/product-claude-code.md", "predicate": "sourced_from", "source": "claude-code-goal-command", "status": "current", "subject": "product:claude-code"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "2ee54ce8c92556a5f73655c2", "object": "source:pi-dev-terminal-limitation", "page": "entities/product-pi.md", "predicate": "sourced_from", "source": "pi-dev-terminal-limitation", "status": "current", "subject": "product:pi"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "327579315c7c5f6284938e40", "object": "source:claude-code-local-cloud-models", "page": "concepts/local-vs-cloud-models.md", "predicate": "sourced_from", "source": "claude-code-local-cloud-models", "status": "current", "subject": "concept:local-vs-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "32c73de25bd306c2f1dcf0d9", "object": "concept:cost-optimization", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "362b7dc12de188b16d6e5e3e", "object": "concept:coding-agent", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "3a43f524911111085adf6f60", "object": "source:claude-code-openrouter-beast-mode", "page": "concepts/cost-optimization.md", "predicate": "sourced_from", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "concept:cost-optimization"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "3cd0d9cc13e931d9ed3e0d20", "object": "source:pi-coding-agent", "page": "entities/person-mario-zechner.md", "predicate": "mentions", "source": "", "status": "current", "subject": "person:mario-zechner"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "3d4aac4a18a108906501f410", "object": "product:pi", "page": "concepts/terminal-limitation.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:terminal-limitation"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "42302f758d8d7576e768e918", "object": "source:claude-code-openrouter-beast-mode", "page": "entities/product-openrouter.md", "predicate": "sourced_from", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "product:openrouter"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "42a621e62f258ae38c837785", "object": "concept:coding-agent-setup", "page": "concepts/local-vs-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:local-vs-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "43612f5e8cdbd96c9eeeb93e", "object": "product:claude-code", "page": "entities/product-openrouter.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:openrouter"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "4513d0bea30cb68c9934bfbf", "object": "concept:cost-optimization", "page": "concepts/coding-agent-setup.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent-setup"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "49984558b8c8dcf6b3fff7ab", "object": "concept:local-vs-cloud-models", "page": "sources/claude-code-ollama-workflow.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-ollama-workflow"}
-{"confidence": "high", "evidence": "Mario Zechner je tvůrce Pi coding agenta", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "4a0a06df47d6853455a2c8d8", "object": "product:pi", "page": "entities/person-mario-zechner.md", "predicate": "works_on", "source": "pi-coding-agent-mario-zechner", "status": "current", "subject": "person:mario-zechner"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "4a209994f6e70117bfbf4db9", "object": "concept:local-vs-cloud-models", "page": "concepts/cost-optimization.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:cost-optimization"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "4d07a788abafd2fcea1494a6", "object": "concept:coding-agent-setup", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "4f17d5255cac0b991f04036d", "object": "source-claude-code-goal-command", "page": "concepts/coding-agent.md", "predicate": "sourced_from", "source": "claude-code-goal-command", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "4fd3af685ec3b1e84dd2ae6f", "object": "source:claude-code-ollama-workflow", "page": "concepts/local-vs-cloud-models.md", "predicate": "sourced_from", "source": "claude-code-ollama-workflow", "status": "current", "subject": "concept:local-vs-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "50d6477ee285ded1cd0fa6be", "object": "product-pybricks", "page": "entities/product-lego-mindstorms.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product-lego-mindstorms"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "50e622a2c2bc2520041fc009", "object": "source:pi-dev-terminal-limitation", "page": "concepts/coding-agent.md", "predicate": "sourced_from", "source": "pi-dev-terminal-limitation", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "512096fc452b6bc938440709", "object": "concept:coding-agent-setup", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "5190e9d269ce879b1abf1b07", "object": "product:openrouter", "page": "concepts/cost-optimization.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:cost-optimization"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "52003666339d725a209b15c8", "object": "concept-goal-driven-agent-loop", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "52eb9ba9326643e195b2957d", "object": "source:claude-code-openrouter-beast-mode", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "531e12fbb0a73a0af2ec0373", "object": "product-pybricks", "page": "concepts/e-waste-reduction.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept-e-waste-reduction"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "546b7227bad05cd9b89c6cef", "object": "product:openrouter", "page": "sources/claude-code-local-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-local-cloud-models"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "5646bcd4c869d872ea59aac0", "object": "source:claude-code-local-cloud-models", "page": "entities/product-claude-code.md", "predicate": "sourced_from", "source": "claude-code-local-cloud-models", "status": "current", "subject": "product:claude-code"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "567275b4ad011c88209bf785", "object": "source:pi-dev-terminal-limitation", "page": "entities/product-pi.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:pi"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_raw", "extras": {}, "id": "57e637043e0ada5ff5f1e9f5", "object": "raw:raw/pi-coding-agent-mario-zechner.md", "page": "sources/pi-coding-agent-mario-zechner.md", "predicate": "summarizes_raw", "source": "", "status": "current", "subject": "source:pi-coding-agent"}
-{"confidence": "medium", "evidence": "OpenRouter a Ollama jsou alternativní způsoby připojení modelů k Claude Code", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "58e0d7ebed1a03b6a6dce2bb", "object": "product:ollama", "page": "entities/product-openrouter.md", "predicate": "competes_with", "source": "claude-code-local-cloud-models", "status": "current", "subject": "product:openrouter"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "592eb6b0c67596b642c57391", "object": "product:claude-code", "page": "concepts/local-vs-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:local-vs-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "59ab4f4f0311802e87ee8c0b", "object": "concept:local-vs-cloud-models", "page": "sources/claude-code-local-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-local-cloud-models"}
-{"confidence": "high", "evidence": "Autor srovnává Claude Code s Cline — 'like Cline' v titulku", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "5aac916c2af1e38f2886d48a", "object": "product:cline", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "mentions", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "medium", "evidence": "Mario byl frustrován Claude Code a dalšími agenty", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "5b91a8575682860e61f221bc", "object": "product:claude-code", "page": "entities/product-pi.md", "predicate": "competes_with", "source": "pi-coding-agent-mario-zechner", "status": "current", "subject": "product:pi"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_raw", "extras": {}, "id": "5e6aba6ee6e7c8a7dc775df5", "object": "raw:raw/claude-code-local-cloud-models-ollama-openrouter.md", "page": "sources/claude-code-local-cloud-models.md", "predicate": "summarizes_raw", "source": "", "status": "current", "subject": "source:claude-code-local-cloud-models"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "5ec9acf9e195faa93736e322", "object": "source:claude-code-local-cloud-models", "page": "concepts/coding-agent-setup.md", "predicate": "sourced_from", "source": "claude-code-local-cloud-models", "status": "current", "subject": "concept:coding-agent-setup"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "5edd59d4acd4bcdd28e6a22a", "object": "product:openrouter", "page": "concepts/coding-agent-setup.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent-setup"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "5f368dafb427845520bda202", "object": "concept:coding-agent-setup", "page": "sources/claude-code-ollama-workflow.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-ollama-workflow"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "5f4eb5459b1557f8f36ac2d6", "object": "product:pi", "page": "concepts/tree-structured-sessions.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:tree-structured-sessions"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "60b30be978df0475543ca366", "object": "source:claude-code-ollama-workflow", "page": "concepts/coding-agent-setup.md", "predicate": "sourced_from", "source": "claude-code-ollama-workflow", "status": "current", "subject": "concept:coding-agent-setup"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "60d34ac81a92bc21875c6542", "object": "concept:coding-agent", "page": "entities/person-mario-zechner.md", "predicate": "mentions", "source": "", "status": "current", "subject": "person:mario-zechner"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "6264a1240c1076a953e7cf24", "object": "concept:cost-optimization", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "high", "evidence": "Setup je krok před použitím coding agenta", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "645122ef8f8d9f56b40faab0", "object": "concept:coding-agent", "page": "concepts/coding-agent-setup.md", "predicate": "depends_on", "source": "claude-code-local-cloud-models", "status": "current", "subject": "concept:coding-agent-setup"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "6fc0769cff7ba42e1168ae4a", "object": "product-pybricks", "page": "entities/product-spike-prime.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product-spike-prime"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "729c525e2e1e09f87bf24848", "object": "concept:coding-agent-setup", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "72f5d24df5a450de6a318cd8", "object": "concept:coding-agent-setup", "page": "concepts/cost-optimization.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:cost-optimization"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "7360fca40798521a714c42fc", "object": "source:claude-code-ollama-workflow", "page": "entities/product-claude-code.md", "predicate": "sourced_from", "source": "claude-code-ollama-workflow", "status": "current", "subject": "product:claude-code"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "7566d21d3ccc128d61c5cc1b", "object": "concept:terminal-limitation", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "75fb4ae1c4b16e4c4ee0ee78", "object": "product-lego-mindstorms", "page": "entities/product-spike-prime.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product-spike-prime"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "76237e017f821d894b1a6116", "object": "concept:cost-optimization", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "787e5c76a93cbc50d6484511", "object": "product-spike-prime", "page": "entities/product-lego-mindstorms.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product-lego-mindstorms"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "79a2cb96dacb70b421660a8c", "object": "product:openrouter", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "high", "evidence": "OpenRouter jako cloud provider pro Claude Code", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "7c89b56db95a048b011a0547", "object": "product:openrouter", "page": "sources/claude-code-local-cloud-models.md", "predicate": "mentions", "source": "claude-code-local-cloud-models", "status": "current", "subject": "source:claude-code-local-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "809e0e0d9a89f244543c2bca", "object": "concept:local-vs-cloud-models", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "high", "evidence": "OpenRouter jako klíčový enabler nízkonákladového beast mode", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "82e79892095d86a8d18987b8", "object": "product:openrouter", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "mentions", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "83320df3257a802400610e54", "object": "product:claude-code", "page": "concepts/coding-agent-setup.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent-setup"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_raw", "extras": {}, "id": "85635f92c9f1da522a6d9b59", "object": "raw:claude-code-goal-command.md", "page": "sources/claude-code-goal-command.md", "predicate": "summarizes_raw", "source": "", "status": "current", "subject": "source-claude-code-goal-command"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "86cf09b124c3e57966d68a65", "object": "person:mario-zechner", "page": "sources/pi-coding-agent-mario-zechner.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:pi-coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "87f30dbadb049e7e9b3d0d0c", "object": "concept:coding-agent", "page": "sources/pi-coding-agent-mario-zechner.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:pi-coding-agent"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "89aa3247f6a7f12a65d9bd18", "object": "source:claude-code-openrouter-beast-mode", "page": "entities/product-cline.md", "predicate": "sourced_from", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "product:cline"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "8b9cfec70b91547fd914badb", "object": "product:claude-code", "page": "entities/product-ollama.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:ollama"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "8ff7ad666e9f79012252dd6d", "object": "concept:tree-structured-sessions", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "medium", "evidence": "Cost optimization je relevantní v kontextu coding agentů", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "932df23980dd2aee2e1a7fb6", "object": "concept:coding-agent", "page": "concepts/cost-optimization.md", "predicate": "depends_on", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "concept:cost-optimization"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "9659093034cbdbc62aba0b5a", "object": "product:pi", "page": "sources/pi-dev-terminal-limitation.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:pi-dev-terminal-limitation"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_raw", "extras": {}, "id": "97505665bd7fc6ba98aca3fd", "object": "raw:raw/claude-code-ollama-workflow-free.md", "page": "sources/claude-code-ollama-workflow.md", "predicate": "summarizes_raw", "source": "", "status": "current", "subject": "source:claude-code-ollama-workflow"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "979dedf44033e061301b9348", "object": "product:ollama", "page": "concepts/coding-agent-setup.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent-setup"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "98114d8ce66ff65616642270", "object": "source:pi-coding-agent", "page": "entities/product-pi.md", "predicate": "sourced_from", "source": "pi-coding-agent-mario-zechner", "status": "current", "subject": "product:pi"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "993e772405af6fb11991025b", "object": "product:ollama", "page": "concepts/local-vs-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:local-vs-cloud-models"}
-{"confidence": "high", "evidence": "Ollama jako lokální backend pro Claude Code", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "9998b438a162a6984d497e42", "object": "product:ollama", "page": "sources/claude-code-ollama-workflow.md", "predicate": "mentions", "source": "claude-code-ollama-workflow", "status": "current", "subject": "source:claude-code-ollama-workflow"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "9ae5839b2d57e5c1fe7d6af9", "object": "source:pi-dev-terminal-limitation", "page": "concepts/terminal-limitation.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:terminal-limitation"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "9b50c578bae478c95541f820", "object": "product-spike-prime", "page": "entities/product-pybricks.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product-pybricks"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "9ba7613061a708db9dbe8014", "object": "source:claude-code-local-cloud-models", "page": "concepts/coding-agent.md", "predicate": "sourced_from", "source": "claude-code-local-cloud-models", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "9d7aafb4c5d0e759c353e8ca", "object": "concept:coding-agent-setup", "page": "sources/claude-code-local-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-local-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "9fd872a4975bc78d8c415957", "object": "product-pybricks", "page": "sources/lego-mindstorms-continued-use.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source-lego-mindstorms-continued-use"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "a2b050146f72b027db4d4bdd", "object": "source:claude-code-local-cloud-models", "page": "entities/product-openrouter.md", "predicate": "sourced_from", "source": "claude-code-local-cloud-models", "status": "current", "subject": "product:openrouter"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "a573cd42f850a2f3cef5e6be", "object": "source:claude-code-openrouter-beast-mode", "page": "concepts/local-vs-cloud-models.md", "predicate": "sourced_from", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "concept:local-vs-cloud-models"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_raw", "extras": {}, "id": "a6fbf9102cefbeb68aa8c00b", "object": "raw:lego-mindstorms-continued-use.md", "page": "sources/lego-mindstorms-continued-use.md", "predicate": "summarizes_raw", "source": "", "status": "current", "subject": "source-lego-mindstorms-continued-use"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "a76d8980968571164c707072", "object": "product:openrouter", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "ad08b7552f80104c5ab23689", "object": "source:pi-dev-terminal-limitation", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "high", "evidence": "Článek popisuje konfiguraci Claude Code s lokálními a cloud modely", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "ad4b7b7470e8707aca5cfccd", "object": "product:claude-code", "page": "sources/claude-code-local-cloud-models.md", "predicate": "mentions", "source": "claude-code-local-cloud-models", "status": "current", "subject": "source:claude-code-local-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "ae31e15a7ae5193a2ba72275", "object": "product-lego-mindstorms", "page": "entities/product-pybricks.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product-pybricks"}
-{"confidence": "medium", "evidence": "Lokální vs. cloud modely jsou relevantní primárně v kontextu coding agentů", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "ae629e701056053be56434e6", "object": "concept:coding-agent", "page": "concepts/local-vs-cloud-models.md", "predicate": "depends_on", "source": "claude-code-local-cloud-models", "status": "current", "subject": "concept:local-vs-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "afb0d7f03ddbd4fd8d06f3b8", "object": "source:pi-coding-agent", "page": "entities/product-pi.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:pi"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "b26a3d7ad08193493ae62a44", "object": "source:claude-code-ollama-workflow", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "b79dcf9de688c772d9dba6af", "object": "product:openrouter", "page": "entities/product-ollama.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:ollama"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "b7c72e20f108ecd9ec441ae3", "object": "product:pi", "page": "entities/person-mario-zechner.md", "predicate": "mentions", "source": "", "status": "current", "subject": "person:mario-zechner"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "bba333169c20cbea02f15d17", "object": "product:openrouter", "page": "concepts/local-vs-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:local-vs-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "c06d1064205f533cfff2bdf9", "object": "concept:coding-agent-setup", "page": "sources/claude-code-goal-command.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source-claude-code-goal-command"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "c1e3fc44723a7cadd70cac90", "object": "product:pi", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "c23a69828bcd8f1f997fdf05", "object": "product:claude-code", "page": "entities/product-cline.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:cline"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "c314fe03504dd239c8fe4abe", "object": "source:pi-coding-agent", "page": "concepts/tree-structured-sessions.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:tree-structured-sessions"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "c3bf9880f6571955c3d16e40", "object": "source:claude-code-ollama-workflow", "page": "concepts/coding-agent.md", "predicate": "sourced_from", "source": "claude-code-ollama-workflow", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "c50987e9426ceca82a18c140", "object": "product:pi", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "c92c0cc40dbb685cc064afe8", "object": "person:mario-zechner", "page": "entities/product-pi.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:pi"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "d0f04257b2ce534883ae4237", "object": "source:pi-coding-agent", "page": "entities/person-mario-zechner.md", "predicate": "sourced_from", "source": "pi-coding-agent-mario-zechner", "status": "current", "subject": "person:mario-zechner"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "d1b0835488e15a18e90fa40e", "object": "source:pi-dev-terminal-limitation", "page": "concepts/terminal-limitation.md", "predicate": "sourced_from", "source": "pi-dev-terminal-limitation", "status": "current", "subject": "concept:terminal-limitation"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "d5ca6775fe73d816cd1c77eb", "object": "source-claude-code-goal-command", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "d6e6f6572fb2bcad75fc0ecf", "object": "source:claude-code-openrouter-beast-mode", "page": "concepts/coding-agent.md", "predicate": "sourced_from", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "medium", "evidence": "Ollama a OpenRouter jsou alternativní způsoby připojení modelů k Claude Code", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "d7cc7dac9bfc2d347b8ca3b8", "object": "product:openrouter", "page": "entities/product-ollama.md", "predicate": "competes_with", "source": "claude-code-local-cloud-models", "status": "current", "subject": "product:ollama"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "d92cde592d3e830e65055ca4", "object": "product:claude-code", "page": "sources/claude-code-local-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-local-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "da1043334a481222e994ecde", "object": "concept:coding-agent", "page": "sources/pi-dev-terminal-limitation.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:pi-dev-terminal-limitation"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "db84f36f891a321aa001d16d", "object": "product-pybricks", "page": "concepts/software-preservation.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept-software-preservation"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "dcbb7d15a5ceceeb312b3acd", "object": "source:pi-coding-agent", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "de0c3489258daf8043e93a66", "object": "product:claude-code", "page": "sources/claude-code-goal-command.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source-claude-code-goal-command"}
-{"confidence": "high", "evidence": "Tree-structured sessions jsou designový vzor pro coding agenty", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "df1c02ee6d035b348e0214e6", "object": "concept:coding-agent", "page": "concepts/tree-structured-sessions.md", "predicate": "depends_on", "source": "pi-coding-agent-mario-zechner", "status": "current", "subject": "concept:tree-structured-sessions"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_raw", "extras": {}, "id": "e026f2c43224691cf89df5a5", "object": "raw:raw/pi-dev-terminal-limitation.md", "page": "sources/pi-dev-terminal-limitation.md", "predicate": "summarizes_raw", "source": "", "status": "current", "subject": "source:pi-dev-terminal-limitation"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "e09eeb3421649feadf4e683e", "object": "concept:coding-agent", "page": "entities/product-pi.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:pi"}
-{"confidence": "high", "evidence": "Terminal limitation je problém specifický pro coding agenty", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "e0ad6fc772543c636dfc1d61", "object": "concept:coding-agent", "page": "concepts/terminal-limitation.md", "predicate": "depends_on", "source": "pi-dev-terminal-limitation", "status": "current", "subject": "concept:terminal-limitation"}
-{"confidence": "medium", "evidence": "Autor srovnává Claude Code s Cline — 'like Cline' v titulku článku", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "e1608a8914da09512210b3c3", "object": "product:claude-code", "page": "entities/product-cline.md", "predicate": "competes_with", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "product:cline"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "e203de988033d0c526a205e5", "object": "concept:terminal-limitation", "page": "sources/pi-dev-terminal-limitation.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:pi-dev-terminal-limitation"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "e2f1bef6c7e27adb0a77c153", "object": "concept:terminal-limitation", "page": "entities/product-pi.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:pi"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "e61be465dee933fa6a894d05", "object": "source:pi-coding-agent", "page": "entities/product-claude-code.md", "predicate": "sourced_from", "source": "pi-coding-agent-mario-zechner", "status": "current", "subject": "product:claude-code"}
-{"confidence": "high", "evidence": "Ollama jako jeden ze tří způsobů spuštění lokálních modelů", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "e999dfe34129fd0647dbeee0", "object": "product:ollama", "page": "sources/claude-code-local-cloud-models.md", "predicate": "mentions", "source": "claude-code-local-cloud-models", "status": "current", "subject": "source:claude-code-local-cloud-models"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "ea0867af72d27dba5b072a44", "object": "product:cline", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "ea4a8353699665fea1dafca2", "object": "product:ollama", "page": "entities/product-claude-code.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:claude-code"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "eb6860e090815adfd902fccd", "object": "concept:coding-agent", "page": "sources/claude-code-goal-command.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source-claude-code-goal-command"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "ec168c80d7ba7908d52ff348", "object": "source-claude-code-goal-command", "page": "concepts/coding-agent.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "high", "evidence": "", "extraction_method": "frontmatter_sources", "extras": {}, "id": "ed6693155ca18076d2f5a1ad", "object": "source:pi-coding-agent", "page": "concepts/coding-agent.md", "predicate": "sourced_from", "source": "pi-coding-agent-mario-zechner", "status": "current", "subject": "concept:coding-agent"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "f06ef238e753bec11f28a0ea", "object": "concept:coding-agent", "page": "concepts/goal-driven-agent-loop.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept-goal-driven-agent-loop"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "f0755eba6ae33e45cdf9959e", "object": "concept:tree-structured-sessions", "page": "entities/product-pi.md", "predicate": "mentions", "source": "", "status": "current", "subject": "product:pi"}
-{"confidence": "high", "evidence": "Článek popisuje konfiguraci Claude Code s OpenRouter pro nízkonákladový beast mode", "extraction_method": "explicit_graph_frontmatter", "extras": {}, "id": "f30fc26cb5073c8e9ad3191d", "object": "product:claude-code", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "mentions", "source": "claude-code-openrouter-beast-mode", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "f33992aec3bc47e87845af67", "object": "concept:local-vs-cloud-models", "page": "concepts/coding-agent-setup.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:coding-agent-setup"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "f773bf3fcae8749d1c8576f4", "object": "product:claude-code", "page": "sources/claude-code-openrouter-beast-mode.md", "predicate": "mentions", "source": "", "status": "current", "subject": "source:claude-code-openrouter-beast-mode"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "fc8418c79e357b10ea793919", "object": "product:claude-code", "page": "concepts/goal-driven-agent-loop.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept-goal-driven-agent-loop"}
-{"confidence": "low", "evidence": "", "extraction_method": "body_wikilink", "extras": {}, "id": "ff771180caa2dc1b3c163c1a", "object": "concept:cost-optimization", "page": "concepts/local-vs-cloud-models.md", "predicate": "mentions", "source": "", "status": "current", "subject": "concept:local-vs-cloud-models"}

cml/wiki/graph/nodes.jsonl

@@ -1,26 +0,0 @@
-{"aliases": [], "canonical": true, "created": "2026-06-20", "id": "concept-e-waste-reduction", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/e-waste-reduction.md", "slug": "e-waste-reduction", "tags": ["e-waste", "sustainability", "longevity", "hardware"], "title": "E-waste reduction", "updated": "2026-06-20"}
-{"aliases": [], "canonical": true, "created": "2026-06-22", "id": "concept-goal-driven-agent-loop", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/goal-driven-agent-loop.md", "slug": "goal-driven-agent-loop", "tags": ["coding-agent", "agent-loop", "evaluation", "autonomy", "goal"], "title": "Goal-driven agent loop", "updated": "2026-06-22"}
-{"aliases": [], "canonical": true, "created": "2026-06-20", "id": "concept-micropython", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/micropython.md", "slug": "micropython", "tags": ["python", "firmware", "embedded", "robotics"], "title": "MicroPython", "updated": "2026-06-20"}
-{"aliases": [], "canonical": true, "created": "2026-06-20", "id": "concept-software-preservation", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/software-preservation.md", "slug": "software-preservation", "tags": ["preservation", "software", "e-waste", "longevity"], "title": "Software preservation", "updated": "2026-06-20"}
-{"aliases": [], "canonical": true, "created": "2026-06-16", "id": "concept:coding-agent", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/coding-agent.md", "slug": "coding-agent", "tags": ["coding-agent", "llm", "tool-design", "agent-architecture"], "title": "Coding agent", "updated": "2026-06-22"}
-{"aliases": [], "canonical": true, "created": "2026-06-18", "id": "concept:coding-agent-setup", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/coding-agent-setup.md", "slug": "coding-agent-setup", "tags": ["coding-agent", "setup", "configuration", "workflow"], "title": "Coding agent setup", "updated": "2026-06-18"}
-{"aliases": [], "canonical": true, "created": "2026-06-18", "id": "concept:cost-optimization", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/cost-optimization.md", "slug": "cost-optimization", "tags": ["llm", "cost", "api", "coding-agent"], "title": "Cost optimization", "updated": "2026-06-18"}
-{"aliases": [], "canonical": true, "created": "2026-06-18", "id": "concept:local-vs-cloud-models", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/local-vs-cloud-models.md", "slug": "local-vs-cloud-models", "tags": ["llm", "local-models", "cloud-models", "cost", "privacy"], "title": "Local vs. cloud models", "updated": "2026-06-18"}
-{"aliases": [], "canonical": true, "created": "2026-06-16", "id": "concept:terminal-limitation", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/terminal-limitation.md", "slug": "terminal-limitation", "tags": ["coding-agent", "terminal", "ide", "ux", "limitation"], "title": "Terminal limitation", "updated": "2026-06-16"}
-{"aliases": [], "canonical": false, "created": "2026-06-16", "id": "concept:tree-structured-sessions", "kind": "", "node_type": "concept", "page_type": "concept", "path": "concepts/tree-structured-sessions.md", "slug": "tree-structured-sessions", "tags": ["coding-agent", "agent-architecture", "context-management"], "title": "Tree-structured sessions", "updated": "2026-06-16"}
-{"aliases": [], "canonical": true, "created": "2026-06-16", "id": "person:mario-zechner", "kind": "person", "node_type": "person", "page_type": "entity", "path": "entities/person-mario-zechner.md", "slug": "person-mario-zechner", "tags": ["person", "developer", "coding-agent", "game-dev"], "title": "Mario Zechner", "updated": "2026-06-16"}
-{"aliases": [], "canonical": true, "created": "2026-06-20", "id": "product-lego-mindstorms", "kind": "product", "node_type": "product", "page_type": "entity", "path": "entities/product-lego-mindstorms.md", "slug": "product-lego-mindstorms", "tags": ["lego", "mindstorms", "robotics", "education", "discontinued"], "title": "LEGO Mindstorms", "updated": "2026-06-20"}
-{"aliases": [], "canonical": true, "created": "2026-06-20", "id": "product-pybricks", "kind": "product", "node_type": "product", "page_type": "entity", "path": "entities/product-pybricks.md", "slug": "product-pybricks", "tags": ["lego", "mindstorms", "firmware", "open-source", "robotics", "python"], "title": "Pybricks", "updated": "2026-06-20"}
-{"aliases": [], "canonical": true, "created": "2026-06-20", "id": "product-spike-prime", "kind": "product", "node_type": "product", "page_type": "entity", "path": "entities/product-spike-prime.md", "slug": "product-spike-prime", "tags": ["lego", "spike", "education", "robotics"], "title": "SPIKE Prime", "updated": "2026-06-20"}
-{"aliases": [], "canonical": true, "created": "2026-06-17", "id": "product:claude-code", "kind": "product", "node_type": "product", "page_type": "entity", "path": "entities/product-claude-code.md", "slug": "product-claude-code", "tags": ["coding-agent", "llm", "tool", "anthropic"], "title": "Claude Code", "updated": "2026-06-22"}
-{"aliases": [], "canonical": true, "created": "2026-06-18", "id": "product:cline", "kind": "product", "node_type": "product", "page_type": "entity", "path": "entities/product-cline.md", "slug": "product-cline", "tags": ["coding-agent", "llm", "tool", "vscode-extension"], "title": "Cline", "updated": "2026-06-18"}
-{"aliases": [], "canonical": true, "created": "2026-06-18", "id": "product:ollama", "kind": "product", "node_type": "product", "page_type": "entity", "path": "entities/product-ollama.md", "slug": "product-ollama", "tags": ["llm", "inference", "local-models", "open-source"], "title": "Ollama", "updated": "2026-06-18"}
-{"aliases": [], "canonical": true, "created": "2026-06-18", "id": "product:openrouter", "kind": "product", "node_type": "product", "page_type": "entity", "path": "entities/product-openrouter.md", "slug": "product-openrouter", "tags": ["llm", "api-proxy", "cloud-models", "cost-optimization"], "title": "OpenRouter", "updated": "2026-06-18"}
-{"aliases": [], "canonical": true, "created": "2026-06-16", "id": "product:pi", "kind": "product", "node_type": "product", "page_type": "entity", "path": "entities/product-pi.md", "slug": "product-pi", "tags": ["coding-agent", "llm", "tool", "open-source"], "title": "Pi (coding agent)", "updated": "2026-06-16"}
-{"aliases": [], "canonical": true, "created": "2026-06-22", "id": "source-claude-code-goal-command", "kind": "", "node_type": "source", "page_type": "source", "path": "sources/claude-code-goal-command.md", "slug": "claude-code-goal-command", "tags": ["claude-code", "coding-agent", "goal", "agent-loop", "evaluation", "anthropic"], "title": "Keep Claude working toward a goal — Claude Code /goal command", "updated": "2026-06-22"}
-{"aliases": [], "canonical": true, "created": "2026-06-20", "id": "source-lego-mindstorms-continued-use", "kind": "", "node_type": "source", "page_type": "source", "path": "sources/lego-mindstorms-continued-use.md", "slug": "lego-mindstorms-continued-use", "tags": ["lego", "mindstorms", "robotics", "pybricks", "preservation", "firmware"], "title": "LEGO Mindstorms: continued use after discontinuation", "updated": "2026-06-20"}
-{"aliases": [], "canonical": true, "created": "", "id": "source:claude-code-local-cloud-models", "kind": "", "node_type": "source", "page_type": "source", "path": "sources/claude-code-local-cloud-models.md", "slug": "claude-code-local-cloud-models", "tags": ["claude-code", "ollama", "openrouter", "local-models", "coding-agent", "setup"], "title": "Run Claude Code on Local & Cloud Models in 5 Minutes (Ollama, OpenRouter, llama.cpp)", "updated": ""}
-{"aliases": [], "canonical": true, "created": "", "id": "source:claude-code-ollama-workflow", "kind": "", "node_type": "source", "page_type": "source", "path": "sources/claude-code-ollama-workflow.md", "slug": "claude-code-ollama-workflow", "tags": ["claude-code", "ollama", "local-models", "coding-agent", "workflow", "free-tier"], "title": "I Tried New Claude Code Ollama Workflow — It's Wild (Free)", "updated": ""}
-{"aliases": [], "canonical": true, "created": "", "id": "source:claude-code-openrouter-beast-mode", "kind": "", "node_type": "source", "page_type": "source", "path": "sources/claude-code-openrouter-beast-mode.md", "slug": "claude-code-openrouter-beast-mode", "tags": ["claude-code", "openrouter", "cline", "coding-agent", "cost-optimization", "beast-mode"], "title": "How I'm Using Claude Code Like Cline with OpenRouter (Beast Mode, Low Cost)", "updated": ""}
-{"aliases": [], "canonical": true, "created": "2026-06-16", "id": "source:pi-coding-agent", "kind": "", "node_type": "source", "page_type": "source", "path": "sources/pi-coding-agent-mario-zechner.md", "slug": "pi-coding-agent-mario-zechner", "tags": ["coding-agent", "llm", "tool-design", "agent-architecture", "video"], "title": "I Hated Every Coding Agent, So I Built My Own — Mario Zechner (Pi)", "updated": "2026-06-16"}
-{"aliases": [], "canonical": true, "created": "2026-06-16", "id": "source:pi-dev-terminal-limitation", "kind": "", "node_type": "source", "page_type": "source", "path": "sources/pi-dev-terminal-limitation.md", "slug": "pi-dev-terminal-limitation", "tags": ["coding-agent", "terminal", "ide", "ux", "limitation"], "title": "pi.dev — terminálová limitace", "updated": "2026-06-16"}

cml/wiki/graph/ontology.yaml

@@ -1,135 +0,0 @@
-# Wiki Graph Ontology
-#
-# Declares the node types and predicates that the compiled graph layer
-# (wiki/graph/) recognises. Edit this file when you introduce a new
-# domain-specific predicate or node type — wiki_graph_lint.py reads it
-# to validate every typed edge declared in page frontmatter.
-#
-# Markdown remains canonical. This file is just the contract that makes
-# the graph layer machine-checkable.
-
-node_types:
-  person:
-    maps_from:
-      type: entity
-      kind: person
-  company:
-    maps_from:
-      type: entity
-      kind: company
-  product:
-    maps_from:
-      type: entity
-      kind: product
-  paper:
-    maps_from:
-      type: entity
-      kind: paper
-  place:
-    maps_from:
-      type: entity
-      kind: place
-  organization:
-    maps_from:
-      type: entity
-      kind: organization
-  concept:
-    maps_from:
-      type: concept
-  source:
-    maps_from:
-      type: source
-  synthesis:
-    maps_from:
-      type: synthesis
-  decision:
-    explicit_only: true
-  claim:
-    explicit_only: true
-  raw:
-    explicit_only: true
-
-predicates:
-  # --- Implicit predicates emitted by the extractor. ---
-  mentions:
-    subject_types: ["*"]
-    object_types: ["*"]
-    requires_evidence: false
-    description: |
-      Low-specificity edge derived from body wikilinks. Use it for
-      navigation, not as evidence of a typed relationship.
-  sourced_from:
-    subject_types: ["*"]
-    object_types: [source]
-    requires_evidence: false
-    description: |
-      Derived from each non-source page's frontmatter `sources:` list.
-  summarizes_raw:
-    subject_types: [source]
-    object_types: ["*"]
-    requires_evidence: false
-    description: |
-      Derived from a source page's frontmatter `raw:` field. Object is
-      the raw file path string, not a wiki node id.
-
-  # --- Typed semantic predicates. Add domain-specific ones below. ---
-  founded:
-    subject_types: [person]
-    object_types: [company, organization]
-    requires_evidence: true
-  owns:
-    subject_types: [person, company, organization]
-    object_types: [company, product, organization]
-    requires_evidence: true
-  contains_product:
-    subject_types: [company, organization]
-    object_types: [product]
-    requires_evidence: true
-  works_on:
-    subject_types: [person]
-    object_types: [product, concept]
-    requires_evidence: true
-  chose:
-    subject_types: [person, company, organization]
-    object_types: [product, concept]
-    requires_evidence: true
-  proposed:
-    subject_types: [person]
-    object_types: [decision, claim]
-    requires_evidence: true
-  competes_with:
-    subject_types: [product, company, organization]
-    object_types: [product, company, organization]
-    requires_evidence: true
-  depends_on:
-    subject_types: [product, concept]
-    object_types: [product, concept]
-    requires_evidence: true
-  authored:
-    subject_types: [person, organization]
-    object_types: [paper, source]
-    requires_evidence: true
-  cites:
-    subject_types: [paper, source, synthesis]
-    object_types: [paper, source]
-    requires_evidence: true
-  contradicts:
-    subject_types: [claim, source, synthesis]
-    object_types: [claim, source, synthesis]
-    requires_evidence: true
-  supersedes:
-    subject_types: [claim, source, decision]
-    object_types: [claim, source, decision]
-    requires_evidence: true
-  improves_on:
-    subject_types: [concept, product, claim, paper]
-    object_types: [concept, product, claim, paper]
-    requires_evidence: true
-  extended_by:
-    subject_types: [concept, product]
-    object_types: [concept, product]
-    requires_evidence: true
-  proposes:
-    subject_types: [paper, person]
-    object_types: [concept, product, claim]
-    requires_evidence: true

cml/wiki/index.md

@@ -1,48 +0,0 @@
-# Wiki Index
-
-The catalog of all pages in this wiki. Each entry: a wikilink to the page and a one-line summary. The LLM reads this first when answering queries to identify candidate pages.
-
-Keep summaries tight — one line each. The index is engineered to be cheap to read; a fat index defeats its purpose.
-
-When this file exceeds ~300 lines or the wiki passes ~150 pages, shard into `wiki/indexes/<type>.md` and replace this file with a directory of shards. See the `scaling-playbook.md` reference in the `llm-wiki` skill for the migration procedure.
-
----
-
-## Sources
-
-- [[pi-coding-agent-mario-zechner]] — talk Maria Zechnera o motivaci a designu Pi coding agenta
-- [[pi-dev-terminal-limitation]] — poznámka o terminálové limitaci Pi a podobných agentů
-- [[claude-code-local-cloud-models]] — průvodce konfigurací Claude Code s lokálními a cloud modely
-- [[claude-code-ollama-workflow]] — test nového Ollama workflow v Claude Code (zdarma)
-- [[claude-code-openrouter-beast-mode]] — Claude Code s OpenRouter pro beast mode při nízkých nákladech
-- [[claude-code-goal-command]] — dokumentace /goal příkazu v Claude Code pro autonomní práci s koncovou podmínkou
-- [[lego-mindstorms-continued-use]] — pokračování používání LEGO Mindstorms po ukončení — alternativy, firmware, zachování aplikací
-
-## Entities
-
-- [[person-mario-zechner]] — tvůrce Pi coding agenta, autor libGDX
-- [[product-pi]] — minimalistický coding agent (4 nástroje, tree-structured sessions)
-- [[product-claude-code]] — coding agent od Anthropic, podporuje lokální i cloud modely
-- [[product-ollama]] — lokální inference server pro LLM modely
-- [[product-openrouter]] — cloud API proxy pro přístup k mnoha LLM modelům
-- [[product-cline]] — VS Code coding agent rozšíření
-- [[product-pybricks]] — open-source firmware a vývojové prostředí pro LEGO robotiku (nahrazuje oficiální aplikace)
-- [[product-lego-mindstorms]] — robotická stavebnice od LEGO, ukončená 2022, nadále použitelná s Pybricks
-- [[product-spike-prime]] — robotická vzdělávací sada od LEGO Education, nástupce Mindstorms
-
-## Concepts
-
-- [[coding-agent]] — software nástroj využívající LLM k autonomnímu/poloautonomnímu psaní kódu
-- [[tree-structured-sessions]] — designový vzor pro správu kontextu v coding agentech (větvení místo lineární historie)
-- [[terminal-limitation]] — koncept omezení coding agentů na terminálové prostředí bez IDE integrace
-- [[local-vs-cloud-models]] — trade-offy mezi lokálními a cloud LLM modely
-- [[coding-agent-setup]] — konfigurace a nastavení coding agentů
-- [[cost-optimization]] — optimalizace nákladů na LLM API
-- [[goal-driven-agent-loop]] — koncept autonomního agenta s verifikovatelnou koncovou podmínkou
-- [[software-preservation]] — zachování softwaru a funkčnosti po ukončení oficiální podpory
-- [[e-waste-reduction]] — prodloužení životnosti elektronických produktů snížením e-waste
-- [[micropython]] — lehká implementace Pythonu 3 pro mikrokontroléry, používá Pybricks
-
-## Synthesis
-
-(populated as query answers are filed back)

cml/wiki/log.md

@@ -1,71 +0,0 @@
-# Wiki Log
-
-## 2026-06-16 — Pi coding agent (talk Mario Zechner)
-
-- Zdroj: `raw/pi-coding-agent-mario-zechner.md` (YouTube talk)
-- Vytvořeny stránky: `sources/pi-coding-agent-mario-zechner.md`, `concepts/coding-agent.md`, `concepts/tree-structured-sessions.md`, `entities/person-mario-zechner.md`, `entities/product-pi.md`
-
-## 2026-06-16 — Pi dev: terminal limitation
-
-- Zdroj: `raw/pi-dev-terminal-limitation.md` (poznámka z pi.dev)
-- Vytvořeny stránky: `sources/pi-dev-terminal-limitation.md`, `concepts/terminal-limitation.md`
-
-## 2026-06-17 — Claude Code
-
-- Vytvořena stránka: `entities/product-claude-code.md`
-
-## 2026-06-17 — Cleanup
-
-- Smazány testovací data o pozicových embeddingech (RoPE, ALiBi, YaRN, Flash Attention) — 18 souborů, 58 edges, 4 raw zdroje v _done
-- Obnoveny nodes.jsonl a edges.jsonl na aktuální stav (8 nodes, 34 edges)
-
-## [2026-06-18] ingest | Claude Code — lokální a cloud modely (3 články)
-
-- Zdroje: `raw/claude-code-local-cloud-models-ollama-openrouter.md`, `raw/claude-code-ollama-workflow-free.md`, `raw/claude-code-openrouter-beast-mode-low-cost.md`
-- Vytvořeny source stránky: `sources/claude-code-local-cloud-models.md`, `sources/claude-code-ollama-workflow.md`, `sources/claude-code-openrouter-beast-mode.md`
-- Vytvořeny entity stránky: `entities/product-ollama.md`, `entities/product-openrouter.md`, `entities/product-cline.md`
-- Vytvořeny concept stránky: `concepts/local-vs-cloud-models.md`, `concepts/coding-agent-setup.md`, `concepts/cost-optimization.md`
-- Aktualizovány stránky: `entities/product-claude-code.md` (rozšířeno o modely/konfiguraci), `concepts/coding-agent.md` (přidány zdroje, odkazy)
-- Aktualizován `index.md`
-- Všechny 3 zdroje přesunuty do `_done/`
-
-## [2026-06-18] lint + graph | After Claude Code sources ingest
-
-Graph regenerated: 17 nodes, 125 edges
-Lint report-only (no destructive edits):
-- 1 broken object reference: concept:llm (page not yet created)
-- No destructive edits applied — report-only per policy
-## [2026-06-20] ingest | LEGO Mindstorms — continued use after discontinuation
-
-- Zdroj: `raw/lego-mindstorms-continued-use.md` (blog robotmak3rs.com + Pybricks + Anton's Mindstorms + ToyBrands)
-- Vytvořeny source stránky: `sources/lego-mindstorms-continued-use.md`
-- Vytvořeny entity stránky: `entities/product-pybricks.md`, `entities/product-lego-mindstorms.md`, `entities/product-spike-prime.md`
-- Vytvořeny concept stránky: `concepts/software-preservation.md`, `concepts/e-waste-reduction.md`, `concepts/micropython.md`
-- Aktualizován `index.md` (přidány nové entity a koncepty)
-- Zdroj přesunut do `_done/`
-
-## [2026-06-22] ingest | Claude Code /goal command
-
-- Zdroj: `raw/claude-code-goal-command.md` (oficiální dokumentace code.claude.com/docs/en/goal)
-- Vytvořena source stránka: `sources/claude-code-goal-command.md`
-- Vytvořena concept stránka: `concepts/goal-driven-agent-loop.md`
-- Aktualizovány stránky: `entities/product-claude-code.md` (přidán /goal příkaz, nový zdroj), `concepts/coding-agent.md` (přidán zdroj, sekce o autonomním běhu)
-- Aktualizován `index.md` (přidán zdroj a koncept)
-- Zdroj přesunut do `_done/`
-
-## [2026-06-20] graph | After LEGO Mindstorms ingest
-
-Graph regenerated: 24 nodes, 136 edges
-Lint report-only (no destructive edits):
-- 1 broken object reference: concept:llm (page not yet created) — pre-existing
-- 6 orphan typed nodes (new LEGO/Pybricks pages — expected, will gain edges as related sources are added)
-- No destructive edits applied — report-only per policy
-- No destructive edits applied — report-only per policy
-
-## [2026-06-22] graph | After Claude Code /goal ingest
-
-Graph regenerated: 26 nodes, 148 edges
-Lint report-only (no destructive edits):
-- 1 broken object reference: concept:llm (pre-existing, page not yet created)
-- 7 orphan typed nodes (3 LEGO/Pybricks pages pre-existing, 1 new goal-driven-agent-loop, 3 expected — will gain edges as related sources are added)
-- No destructive edits applied — report-only per policy

cml/wiki/sources/claude-code-goal-command.md

@@ -1,44 +0,0 @@
----
-type: source
-title: "Keep Claude working toward a goal — Claude Code /goal command"
-slug: source-claude-code-goal-command
-tags: [claude-code, coding-agent, goal, agent-loop, evaluation, anthropic]
-sources: []
-raw: "claude-code-goal-command.md"
-url: "https://code.claude.com/docs/en/goal"
-created: 2026-06-22
-updated: 2026-06-22
-graph:
-  node_id: source-claude-code-goal-command
-  canonical: true
----
-
-# Keep Claude working toward a goal — Claude Code /goal command
-
-Oficiální dokumentace Claude Code k příkazu `/goal`, který nastavuje dokončovací podmínku a nechá agenta pracovat autonomně, dokud není splněna. Po každém turnu samostatný menší model (defaultně Haiku) vyhodnocuje, zda podmínka platí.
-
-## Klíčové body
-
-- **`/goal` příkaz** — nastaví verifikovatelnou koncovou podmínku; agent pokračuje v práci bez nutnosti dalšího promptu uživatele
-- **Separátní evaluátor** — po každém turnu se podmínka a konverzace pošlou menšímu rychlému modelu (default Haiku), který vrací yes/no + krátký důvod. "No" znamená pokračuj, "yes" znamená cíl splněn
-- **Efektivní podmínka** — měřitelný koncový stav (test result, build exit code, file count), explicitní způsob ověření, omezení co se nesmí změnit
-- **Porovnání přístupů**: `/goal` (podmínka), `/loop` (časový interval), Stop hook (vlastní skript/prompt)
-- **Komplementární s auto mode** — auto mode schvaluje tool calls v rámci jednoho turnu, `/goal` odstraňuje nutnost promptovat mezi turny
-- **Non-interactive** — funguje s `-p` flagem, v desktop app, přes Remote Control
-- **Resume** — aktivní goal se obnoví při `--resume` nebo `--continue`, s resetem turn count/timer/token spend
-- **Omezení** — max 4000 znaků pro podmínku, vyžaduje accepted trust dialog, nefunguje s `disableAllHooks` nebo `allowManagedHooksOnly`
-
-## Tři přístupy k udržení session
-
-| Přístup | Další turn začíná když | Zastaví když |
-|---------|----------------------|-------------|
-| `/goal` | Předchozí turn skončí | Model potvrdí podmínku |
-| `/loop` | Uplyne časový interval | Uživatel zastaví nebo agent rozhodne |
-| Stop hook | Předchozí turn skončí | Vlastní skript/prompt rozhodne |
-
-## Související
-
-- [[product-claude-code]] — produkt, kde /goal funguje
-- [[concept-goal-driven-agent-loop]] — koncept autonomního agenta s verifikovatelnou koncovou podmínkou
-- [[coding-agent]] — obecný koncept coding agentů
-- [[coding-agent-setup]] — konfigurace coding agentů

cml/wiki/sources/claude-code-local-cloud-models.md

@@ -1,54 +0,0 @@
----
-type: source
-title: "Run Claude Code on Local & Cloud Models in 5 Minutes (Ollama, OpenRouter, llama.cpp)"
-authors: ["Luong Nguyen"]
-url: "https://medium.com/@luongnv89/run-claude-code-on-local-cloud-models-in-5-minutes-ollama-openrouter-llama-cpp-6dfeaee03cda"
-raw: "raw/claude-code-local-cloud-models-ollama-openrouter.md"
-ingested: 2026-06-18
-tags: [claude-code, ollama, openrouter, local-models, coding-agent, setup]
-entities: [product-claude-code, product-ollama, product-openrouter]
-concepts: [local-vs-cloud-models, coding-agent-setup]
-slug: source-claude-code-local-cloud-models
-graph:
-  node_id: source:claude-code-local-cloud-models
-  canonical: true
-  relationships:
-    - predicate: mentions
-      object: product:claude-code
-      source: claude-code-local-cloud-models
-      evidence: "Článek popisuje konfiguraci Claude Code s lokálními a cloud modely"
-      confidence: high
-      status: current
-    - predicate: mentions
-      object: product:ollama
-      source: claude-code-local-cloud-models
-      evidence: "Ollama jako jeden ze tří způsobů spuštění lokálních modelů"
-      confidence: high
-      status: current
-    - predicate: mentions
-      object: product:openrouter
-      source: claude-code-local-cloud-models
-      evidence: "OpenRouter jako cloud provider pro Claude Code"
-      confidence: high
-      status: current
----
-
-# Run Claude Code on Local & Cloud Models in 5 Minutes
-
-Průvodce konfigurací Claude Code s lokálními i cloud modely. Autor popisuje tři cesty: Ollama, OpenRouter a llama.cpp.
-
-## Klíčové body
-
-- **Ollama** — lokální inference server, podporuje širokou škálu modelů. Claude Code se připojí přes OpenAI-compatible API endpoint.
-- **OpenRouter** — cloudový proxy poskytující přístup k mnoha modelům (včetně Claude) přes jednotné API. Umožňuje snadné přepínání modelů.
-- **llama.cpp** — lightweight lokální inference, vhodná pro jednoduché setupy bez závislostí.
-- **Konfigurace** — Claude Code podporuje `model` v `.claude/settings.json` nebo env var `ANTHROPIC_MODEL`. Pro lokální modely se nastavuje `OPENAI_API_BASE` a `OPENAI_API_KEY`.
-- **Trade-offy** — lokální modely = soukromí a nulové náklady, ale nižší kvalita; cloud = vyšší kvalita, ale náklady a latence.
-
-## Související
-
-- [[product-claude-code]] — hlavní subjekt článku
-- [[product-ollama]] — lokální inference server
-- [[product-openrouter]] — cloud proxy
-- [[local-vs-cloud-models]] — koncept lokálních vs. cloud modelů
-- [[coding-agent-setup]] — koncept nastavení coding agentů

cml/wiki/sources/claude-code-ollama-workflow.md

@@ -1,48 +0,0 @@
----
-type: source
-title: "I Tried New Claude Code Ollama Workflow — It's Wild (Free)"
-authors: ["Joe Njenga"]
-url: "https://medium.com/@joe.njenga/i-tried-new-claude-code-ollama-workflow-its-wild-free-cb7a12b733b5"
-raw: "raw/claude-code-ollama-workflow-free.md"
-ingested: 2026-06-18
-tags: [claude-code, ollama, local-models, coding-agent, workflow, free-tier]
-entities: [product-claude-code, product-ollama]
-concepts: [coding-agent-setup, local-vs-cloud-models]
-slug: source-claude-code-ollama-workflow
-graph:
-  node_id: source:claude-code-ollama-workflow
-  canonical: true
-  relationships:
-    - predicate: mentions
-      object: product:claude-code
-      source: claude-code-ollama-workflow
-      evidence: "Článek testuje nový Ollama workflow v Claude Code"
-      confidence: high
-      status: current
-    - predicate: mentions
-      object: product:ollama
-      source: claude-code-ollama-workflow
-      evidence: "Ollama jako lokální backend pro Claude Code"
-      confidence: high
-      status: current
----
-
-# I Tried New Claude Code Ollama Workflow — It's Wild (Free)
-
-Autor testuje nový Ollama workflow v Claude Code a popisuje, jak lze zdarma spouštět lokální modely přímo z Claude Code terminálu.
-
-## Klíčové body
-
-- **Ollama integration** — Claude Code nově podporuje nativní Ollama workflow. Stačí `ollama serve` a nastavit model.
-- **Zdarma** — lokální modely přes Ollama = nulové API náklady. Autor zdůrazňuje "wild" fakt, že jde o plně funkční coding agent zdarma.
-- **Workflow** — autor popisuje konkrétní kroky: instalace Ollama, pull modelu, konfigurace Claude Code, spuštění.
-- **Omezení** — lokální modely (Qwen, Llama) mají nižší kvalitu než Claude, ale pro jednoduché úkoly dostačující.
-- **Praktické tipy** — doporučuje začít s menšími modely (3B–8B) pro rychlost, větší (70B+) pro kvalitu.
-
-## Související
-
-- [[product-claude-code]] — hlavní subjekt
-- [[product-ollama]] — lokální inference
-- [[coding-agent-setup]] — koncept nastavení
-- [[local-vs-cloud-models]] — lokální vs. cloud
-- [[source-claude-code-local-cloud-models]] — související článek (širší přehled)

cml/wiki/sources/claude-code-openrouter-beast-mode.md

@@ -1,58 +0,0 @@
----
-type: source
-title: "How I'm Using Claude Code Like Cline with OpenRouter (Beast Mode, Low Cost)"
-authors: ["Joe Njenga"]
-url: "https://medium.com/@joe.njenga/how-im-using-claude-code-like-cline-with-openrouter-to-go-beast-mode-at-low-cost-8c78e0bdcb67"
-raw: "raw/claude-code-openrouter-beast-mode-low-cost.md"
-ingested: 2026-06-18
-tags: [claude-code, openrouter, cline, coding-agent, cost-optimization, beast-mode]
-entities: [product-claude-code, product-openrouter, product-cline]
-concepts: [coding-agent-setup, cost-optimization, local-vs-cloud-models]
-slug: source-claude-code-openrouter-beast-mode
-graph:
-  node_id: source:claude-code-openrouter-beast-mode
-  canonical: true
-  relationships:
-    - predicate: mentions
-      object: product:claude-code
-      source: claude-code-openrouter-beast-mode
-      evidence: "Článek popisuje konfiguraci Claude Code s OpenRouter pro nízkonákladový beast mode"
-      confidence: high
-      status: current
-    - predicate: mentions
-      object: product:openrouter
-      source: claude-code-openrouter-beast-mode
-      evidence: "OpenRouter jako klíčový enabler nízkonákladového beast mode"
-      confidence: high
-      status: current
-    - predicate: mentions
-      object: product:cline
-      source: claude-code-openrouter-beast-mode
-      evidence: "Autor srovnává Claude Code s Cline — 'like Cline' v titulku"
-      confidence: high
-      status: current
----
-
-# How I'm Using Claude Code Like Cline with OpenRouter (Beast Mode, Low Cost)
-
-Autor popisuje, jak nakonfigurovat Claude Code s OpenRouter pro "beast mode" — přístup k výkonným modelům za zlomek ceny nativního Claude API. Srovnává přístup s Cline.
-
-## Klíčové body
-
-- **OpenRouter jako proxy** — umožňuje přístup k mnoha modelům (Claude, GPT-4, Gemini, Mistral) přes jednotné API. Klíčové pro cost optimization.
-- **Beast mode** — autor volí nejvýkonnější dostupné modely (Claude Opus, GPT-4) přes OpenRouter, ale platí jen za tokeny, které spotřebuje.
-- **Cline-like workflow** — Claude Code v terminálu funguje podobně jako Cline (VS Code extension), ale s větší flexibilitou modelů.
-- **Cost comparison** — OpenRouter ceny jsou výrazně nižší než přímé API přístupy. Autor uvádí konkrétní úspory.
-- **Konfigurace** — nastavení `OPENAI_API_BASE` na OpenRouter endpoint, výběr modelu přes `model` v settings.
-- **Trade-offy** — vyšší latence oproti nativnímu API, občasné rate limity, ale výrazně nižší náklady.
-
-## Související
-
-- [[product-claude-code]] — hlavní subjekt
-- [[product-openrouter]] — cloud proxy
-- [[product-cline]] — srovnávaný nástroj
-- [[coding-agent-setup]] — koncept nastavení
-- [[cost-optimization]] — optimalizace nákladů
-- [[local-vs-cloud-models]] — lokální vs. cloud
-- [[source-claude-code-local-cloud-models]] — širší přehled modelů
-- [[source-claude-code-ollama-workflow]] — Ollama workflow

cml/wiki/sources/lego-mindstorms-continued-use.md

@@ -1,68 +0,0 @@
----
-type: source
-title: "LEGO Mindstorms: continued use after discontinuation"
-slug: source-lego-mindstorms-continued-use
-tags: [lego, mindstorms, robotics, pybricks, preservation, firmware]
-sources: []
-raw: "lego-mindstorms-continued-use.md"
-created: 2026-06-20
-updated: 2026-06-20
-graph:
-  node_id: source-lego-mindstorms-continued-use
-  canonical: true
----
-
-# LEGO Mindstorms: continued use after discontinuation
-
-Zdrojový materiál o tom, jak nadále používat produkty LEGO Mindstorms po jejich ukončení — včetně komunitních alternativ, firmware obnov a zachování aplikací.
-
-## Kontext ukončení
-
-LEGO Mindstorms byl oficiálně ukončen v říjnu 2022. LEGO Group přesunul zdroje na SPIKE Prime a další produkty LEGO Education. Robot Inventor app měl zůstat dostupný minimálně do konce 2024, ale postupně přestává fungovat na novějších zařízeních a platformách.
-
-Problém je zásadní: existují stovky tisíc až miliony sady Mindstorms po celém světě. Mnoho škol a FIRST LEGO League týmů stále používá EV3 — asi 60 % týmů FLL v roce 2023 podle jednoho průzkumu. Elektronické LEGO má mnohem kratší životnost než klasické plastové cihly, protože závisí na softwaru a aplikacích, které rychle zastarávají.
-
-## Alternativy a pokračování používání
-
-### Pybricks — hlavní komunitní alternativa
-
-[[product-pybricks]] je open-source firmware a vývojové prostředí, které nahrazuje oficiální LEGO aplikace. Klíčové vlastnosti:
-
-- Funguje na všech generacích Mindstorms (NXT, EV3, Robot Inventor) i na SPIKE Prime a dalších Powered Up hubech
-- MicroPython a blokové programování v prohlížeči — žádné instalace
-- Okamžitý boot (na rozdíl od původního EV3 Linuxu, který startoval desítky sekund)
-- Stabilnější a lepší API než oficiální aplikace
-- Bezplatný firmware, volitelné placené doplňky (blokové programování)
-- Podporuje všechny oficiální EV3 motory a senzory, plus NXT senzory na EV3 bricku
-- Uživatelé mohou přispívat na Patreon a dostat své jméno do credits při vypínání EV3
-
-Stav projektu Pybricks pro EV3 (k prosinci 2025): instant power on/off, MicroPython firmware bez microSD karty, program storage, download přes Pybricksdev, podpora všech EV3 motorů a senzorů, NXT senzory na EV3, custom UART/I2C/analog zařízení. Zbývá implementovat USB/Bluetooth konektivitu a browser-based firmware instalaci.
-
-### Zachování oficiálních aplikací
-
-Blog [[source-lego-mindstorms-continued-use]] (robotmak3rs.com) dokumentuje postupy obnovy oficiálních Mindstorms aplikací z archivovaných záloh:
-
-- **Android**: Split APK instalace + obnova privátních app dat (vyžaduje root). Záloha obsahuje jak APK, tak stažený in-app content. ARM64 only.
-- **macOS** a **Windows**: Obnova z archivovaných instalátorů (samostatné články na blog.robotmak3rs.com).
-
-Klíčové poznání: samotný instalátor nestačí — in-app content (tutoriály, build instrukce) je uložen v privátním app storage a bez jeho zálohy nelze plně obnovit funkční stav aplikace.
-
-### Kompatibilita hardware
-
-- Mindstorms Robot Inventor hub má stejný tvar jako SPIKE Prime hub, ale SPIKE3 firmware na něj nejde nainstalovat (chyba při připojení)
-- SPIKE2 firmware fungoval na Mindstorms hubu, ale aktuální SPIKE3 už ne
-- Motory a senzory jsou cross-kompatibilní mezi Mindstorms a SPIKE Prime
-- Robot Inventor set (51515) má stále dobrou play value — Anton's Mindstorms doporučuje koupit, pokud je dostupný za dobrou cenu
-
-## Důsledky pro uživatele
-
-- Školy a FLL týmy závislé na EV3 potřebují alternativu — Pybricks je nejlepší volba
-- Druhový trh: zapečetěné EV3 sety se prodávají za dvojnásobek původní ceny
-- Oficiální aplikace postupně mizí z app store — komunitní archivy jsou jediná záchrana
-- Pybricks sjednocuje programování napříč všemi generacemi LEGO robotiky
-
-## Where this fits
-
-- [[product-pybricks]] — open-source firmware alternativa
-- [[concept-software-preservation]] — obecný koncept zachování softwaru po ukončení podpory
-- [[concept-e-waste-reduction]] — prodloužení životnosti elektronických produktů

cml/wiki/sources/pi-coding-agent-mario-zechner.md

@@ -1,67 +0,0 @@
----
-type: source
-title: "I Hated Every Coding Agent, So I Built My Own — Mario Zechner (Pi)"
-authors: ["Mario Zechner"]
-url: "https://www.youtube.com/watch?v=Dli5slNaJu0"
-raw: "raw/pi-coding-agent-mario-zechner.md"
-ingested: 2026-06-16
-created: 2026-06-16
-updated: 2026-06-16
-tags: [coding-agent, llm, tool-design, agent-architecture, video]
-entities: [person-mario-zechner, product-pi]
-concepts: [coding-agent, tree-structured-sessions]
-slug: pi-coding-agent
-graph:
-  node_id: source:pi-coding-agent
-  canonical: true
-  canonical: true
----
-
-# I Hated Every Coding Agent, So I Built My Own — Mario Zechner (Pi)
-
-Shrnutí talku Maria Zechnera (tvůrce Pi coding agenta, aka badlogic — autor libGDX) o motivaci a designu Pi.
-
-## Klíčové body
-
-### Proč Pi vzniklo
-
-Mario byl frustrován existujícími coding agenty (Claude Code, OpenCode, Codex CLI, AMP) z několika důvodů:
-
-1. **Feature bloat** — agenti nabírají funkce (to-dos, komplexní tool suites), které nejsou potřeba a přidávají skrytou kontextovou injekci.
-2. **Skryté chování** — vendoři mění věci pod pokličkou (system prompty, kontextová injekce), což způsobuje nepředvídatelné chování LLM.
-3. **Špatná pozorovatelnost** — těžké vidět, co agent dělá, jaký kontext používá, kolik to stojí.
-4. **Chybějící rozšiřitelnost** — power user nemůže přidat vlastní nástroje bez forku.
-5. **Approval fatigue** — buď plná autonomie, nebo approval pro každou akci; oboje je špatné UX.
-6. **Špatná správa kontextu** — agenti jako OpenCode spoléhají na session compaction, ale ztrácí důležitý kontext.
-
-Klíčový citát: *"So obviously they're doing things right, but not for me."*
-
-### Designová filozofie Pi
-
-- **Minimální jádro** — pouze 4 nástroje: read file, write file, edit file, bash. To stačí.
-- **Malý system prompt** — frontier RL-trénované modely nepotřebují masivní system prompty.
-- **[[tree-structured-sessions]]** — ne lineární chat history; sub-agenti se mohou větvit a číst soubory nezávisle při zachování kontextu/lineage.
-- **Full cost tracking** — vestavěný, ne dodatečný.
-- **Hot-reloadable TypeScript extensions** — uživatelé mohou definovat vlastní nástroje, UI, multi-agent setupy bez úpravy jádra.
-- **Žádná skrytá kontextová injekce** — co vidíš, to model dostává.
-
-### Komunitní rozšíření
-
-- **pi-annotate** — vizuální feedback na živé weby
-- **pi-messenger** — multi-agent chatroom s vlastním UI
-- Vlastní UI, tool integrace — vše jako hot-reloadable TS moduly
-
-### Výkon
-
-Na TerminalBench dosáhlo Pi (s Claude Opus 4.5) blízko Terminus i před pokročilými optimalizacemi jako compaction.
-
-### Klíčový insight
-
-*"We are in the messing around and finding out stage, and nobody has any idea what the perfect coding agent should look like."* — zjednodušení může vést k efektivnímu výkonu bez zbytečné komplexity.
-
-## Kde to zapadá
-
-- [[person-mario-zechner]] — řečník a tvůrce Pi
-- [[product-pi]] — coding agent
-- [[coding-agent]] — obecný koncept
-- [[tree-structured-sessions]] — Piův designový přístup ke správě kontextu

cml/wiki/sources/pi-dev-terminal-limitation.md

@@ -1,29 +0,0 @@
----
-type: source
-title: "pi.dev — terminálová limitace"
-authors: []
-url: "https://pi.dev/"
-raw: "raw/pi-dev-terminal-limitation.md"
-ingested: 2026-06-16
-created: 2026-06-16
-updated: 2026-06-16
-tags: [coding-agent, terminal, ide, ux, limitation]
-entities: [product-pi]
-concepts: [terminal-limitation, coding-agent]
-slug: pi-dev-terminal-limitation
-graph:
-  node_id: source:pi-dev-terminal-limitation
-  canonical: true
----
-
-# pi.dev — terminálová limitace
-
-Osobní poznámka: pi.dev je pěkný projekt, ale limitace na terminal je až moc přísná a omezující. Bez IDE to ztrácí všechny výhodné vlastnosti — podobně jako opencode.
-
-Terminal-only přístup výrazně omezuje uživatelskou zkušenost a produktivitu oproti plnohodnotnému IDE integrovanému řešení.
-
-## Kontext
-
-- [[product-pi]] — Pi coding agent, jehož se tato limitace týká
-- [[coding-agent]] — obecný koncept, kde je terminal-only vs. IDE debata relevantní
-- [[terminal-limitation]] — koncept terminálové limitace coding agentů

cook/caj/karak.md

@@ -0,0 +1,35 @@
+---
+type: caj
+category: tea-milk
+added: 2026-09-08
+origin: blizky-vychod
+tags: [caj]
+---
+
+# Karak
+
+Porce: 2 hrnky
+
+## Ingredience
+
+- 2 plné hrnky vody (~500 ml)
+- zázvor nakrájený najemno — dávka upřesnit
+- kardamom, rozdrcený — dávka upřesnit
+- několik lžic černého čaje (správný druh — upřesnit)
+- mléko + mléko do kávy (kávová smetana), dohromady ~půl hrnku
+- několik lžic třtinového cukru — dávka upřesnit
+
+## Postup
+
+1. Vodu přelij do rendlíku, přiveď k varu.
+2. Vhod nakrájený zázvor a rozdrcený kardamom, vař nějakou dobu.
+3. Přidej čaj, znovu vař.
+4. Mezitím si v hrnku smíchej mléko a mléko do kávy (~půl hrnku směsi).
+5. Směs přilej do rendlíku, přidej třtinový cukr, důkladně rozmíchej.
+6. Přiveď k varu — těsně před přetečením rendlíku ztlum.
+7. Opakuj var celkem třikrát (přetékání = známka správné síly/konzistence).
+8. Hotovo — přeceď přes sítko zpět do hrnku.
+
+## Poznámky
+
+- Neupřesněné dávky (zázvor, kardamom, čaj, cukr) dohledat/vyzkoušet.

cook/caj/teh-tarik.md

@@ -0,0 +1,17 @@
+---
+type: caj
+category: tea-milk
+added: 2026-09-08
+origin: malajsie
+tags: [caj]
+---
+
+# Teh Tarik
+
+Porce pro dvě osoby:
+
+- 700 až 800 ml vody
+- dvě polévkové lžíce čaje (zarovnáno nebo mírný kopeček)
+- louhovat 6 minut
+- 2 polévkové lžíce salka
+- 2 polévkové lžíce kondenzovaného mléka nebo dvě mini mlíčka do kávy

cron/jobs.json

@@ -2,7 +2,7 @@
   "version": 1,
   "jobs": [
     {
-      "id": "e81cda77",
+      "id": "c1e268c8",
       "name": "nanobot-version-check",
       "enabled": true,
       "schedule": {
@@ -14,7 +14,7 @@
       },
       "payload": {
         "kind": "agent_turn",
-        "message": "Check if a new nanobot-ai version is available on PyPI. Compare the latest PyPI version with the currently installed version (run `nanobot --version`). If a new version is found, notify the user via Telegram with: the current version, the new version, and the upgrade command: `uv tool upgrade nanobot-ai`. If already up to date, do nothing.",
+        "message": "Nanobot version check: porovnej nejnovější verzi nanobot-ai na PyPI s nainstalovanou (`nanobot --version`). Pokud je na PyPI novější verze, pošli notifikaci přes Telegram (message tool, chat_id 8826147089) s aktuální verzí, novou verzí a příkazem `uv tool upgrade nanobot-ai`. Pokud jsou verze stejné, nedělej nic a neodepisuj do web session — výstup jen pro poznámku, hlavní kanál je Telegram.",
         "deliver": false,
         "channel": null,
         "to": null,
@@ -24,10 +24,11 @@
         "originChatId": "52d0f338-7a06-42e7-aad2-86a4cabbfb9f",
         "originMetadata": {
           "remote": [
-            "10.20.30.8",
-            51076
+            "192.168.40.104",
+            40926
           ],
           "webui": true,
+          "webui_turn_id": "64d0dc00-72a6-45fb-9e16-c4b8d106a1f4",
           "workspace_scope": {
             "project_path": "/home/nanobot/.nanobot/workspace",
             "access_mode": "restricted"
@@ -36,135 +37,51 @@
         }
       },
       "state": {
-        "nextRunAtMs": 1788415200000,
-        "lastRunAtMs": 1788328800001,
+        "nextRunAtMs": 1789538400000,
+        "lastRunAtMs": 1789452000002,
         "lastStatus": "ok",
         "lastError": null,
         "runHistory": [
           {
-            "runAtMs": 1786687200001,
+            "runAtMs": 1789020000002,
             "status": "ok",
-            "durationMs": 6221,
+            "durationMs": 6281,
             "error": null
           },
           {
-            "runAtMs": 1786773600001,
+            "runAtMs": 1789106400001,
             "status": "ok",
-            "durationMs": 9316,
+            "durationMs": 6997,
             "error": null
           },
           {
-            "runAtMs": 1786860000001,
+            "runAtMs": 1789192800002,
             "status": "ok",
-            "durationMs": 7565,
+            "durationMs": 5526,
             "error": null
           },
           {
-            "runAtMs": 1786946400001,
+            "runAtMs": 1789279200002,
             "status": "ok",
-            "durationMs": 8013,
+            "durationMs": 10674,
             "error": null
           },
           {
-            "runAtMs": 1787032800001,
+            "runAtMs": 1789365600002,
             "status": "ok",
-            "durationMs": 8457,
+            "durationMs": 5495,
             "error": null
           },
           {
-            "runAtMs": 1787119200002,
+            "runAtMs": 1789452000002,
             "status": "ok",
-            "durationMs": 8879,
-            "error": null
-          },
-          {
-            "runAtMs": 1787205600002,
-            "status": "ok",
-            "durationMs": 7420,
-            "error": null
-          },
-          {
-            "runAtMs": 1787292000002,
-            "status": "ok",
-            "durationMs": 7307,
-            "error": null
-          },
-          {
-            "runAtMs": 1787378400001,
-            "status": "ok",
-            "durationMs": 7402,
-            "error": null
-          },
-          {
-            "runAtMs": 1787464800001,
-            "status": "ok",
-            "durationMs": 8817,
-            "error": null
-          },
-          {
-            "runAtMs": 1787551200002,
-            "status": "ok",
-            "durationMs": 9626,
-            "error": null
-          },
-          {
-            "runAtMs": 1787637600002,
-            "status": "ok",
-            "durationMs": 12925,
-            "error": null
-          },
-          {
-            "runAtMs": 1787724000002,
-            "status": "ok",
-            "durationMs": 10899,
-            "error": null
-          },
-          {
-            "runAtMs": 1787810400002,
-            "status": "ok",
-            "durationMs": 5000,
-            "error": null
-          },
-          {
-            "runAtMs": 1787896800002,
-            "status": "ok",
-            "durationMs": 4464,
-            "error": null
-          },
-          {
-            "runAtMs": 1787983200001,
-            "status": "ok",
-            "durationMs": 5148,
-            "error": null
-          },
-          {
-            "runAtMs": 1788069600002,
-            "status": "ok",
-            "durationMs": 5748,
-            "error": null
-          },
-          {
-            "runAtMs": 1788156000001,
-            "status": "ok",
-            "durationMs": 95646,
-            "error": null
-          },
-          {
-            "runAtMs": 1788242400002,
-            "status": "ok",
-            "durationMs": 4653,
-            "error": null
-          },
-          {
-            "runAtMs": 1788328800001,
-            "status": "ok",
-            "durationMs": 3988,
+            "durationMs": 4987,
             "error": null
           }
         ]
       },
-      "createdAtMs": 1782281393634,
-      "updatedAtMs": 1788328803989,
+      "createdAtMs": 1788948314679,
+      "updatedAtMs": 1789452004989,
       "deleteAfterRun": false
     },
     {
@@ -191,135 +108,21 @@
         "originMetadata": {}
       },
       "state": {
-        "nextRunAtMs": 1788360482419,
-        "lastRunAtMs": 1788353282400,
+        "nextRunAtMs": 1789469747898,
+        "lastRunAtMs": 1789462547857,
         "lastStatus": "ok",
         "lastError": null,
         "runHistory": [
           {
-            "runAtMs": 1788216481686,
+            "runAtMs": 1789462547857,
             "status": "ok",
-            "durationMs": 10,
-            "error": null
-          },
-          {
-            "runAtMs": 1788223681698,
-            "status": "ok",
-            "durationMs": 10,
-            "error": null
-          },
-          {
-            "runAtMs": 1788230881709,
-            "status": "ok",
-            "durationMs": 10,
-            "error": null
-          },
-          {
-            "runAtMs": 1788238081720,
-            "status": "ok",
-            "durationMs": 9,
-            "error": null
-          },
-          {
-            "runAtMs": 1788245281730,
-            "status": "ok",
-            "durationMs": 10,
-            "error": null
-          },
-          {
-            "runAtMs": 1788252481740,
-            "status": "ok",
-            "durationMs": 10,
-            "error": null
-          },
-          {
-            "runAtMs": 1788259681751,
-            "status": "ok",
-            "durationMs": 11,
-            "error": null
-          },
-          {
-            "runAtMs": 1788266881764,
-            "status": "ok",
-            "durationMs": 10,
-            "error": null
-          },
-          {
-            "runAtMs": 1788274081775,
-            "status": "ok",
-            "durationMs": 9,
-            "error": null
-          },
-          {
-            "runAtMs": 1788281281786,
-            "status": "ok",
-            "durationMs": 10,
-            "error": null
-          },
-          {
-            "runAtMs": 1788288481797,
-            "status": "ok",
-            "durationMs": 11,
-            "error": null
-          },
-          {
-            "runAtMs": 1788295681809,
-            "status": "ok",
-            "durationMs": 17,
-            "error": null
-          },
-          {
-            "runAtMs": 1788302881827,
-            "status": "ok",
-            "durationMs": 12,
-            "error": null
-          },
-          {
-            "runAtMs": 1788310081840,
-            "status": "ok",
-            "durationMs": 13,
-            "error": null
-          },
-          {
-            "runAtMs": 1788317282062,
-            "status": "ok",
-            "durationMs": 12,
-            "error": null
-          },
-          {
-            "runAtMs": 1788324482170,
-            "status": "ok",
-            "durationMs": 9,
-            "error": null
-          },
-          {
-            "runAtMs": 1788331682180,
-            "status": "ok",
-            "durationMs": 15,
-            "error": null
-          },
-          {
-            "runAtMs": 1788338882198,
-            "status": "ok",
-            "durationMs": 10,
-            "error": null
-          },
-          {
-            "runAtMs": 1788346082210,
-            "status": "ok",
-            "durationMs": 12,
-            "error": null
-          },
-          {
-            "runAtMs": 1788353282400,
-            "status": "ok",
-            "durationMs": 19,
+            "durationMs": 41,
             "error": null
           }
         ]
       },
-      "createdAtMs": 1788151596627,
-      "updatedAtMs": 1788353282419,
+      "createdAtMs": 1789455347840,
+      "updatedAtMs": 1789462547898,
       "deleteAfterRun": false
     },
     {
@@ -346,135 +149,51 @@
         "originMetadata": {}
       },
       "state": {
-        "nextRunAtMs": 1788356882542,
-        "lastRunAtMs": 1788355082541,
+        "nextRunAtMs": 1789467948003,
+        "lastRunAtMs": 1789466148003,
         "lastStatus": "ok",
         "lastError": null,
         "runHistory": [
           {
-            "runAtMs": 1788320882077,
+            "runAtMs": 1789457147995,
             "status": "ok",
             "durationMs": 0,
             "error": null
           },
           {
-            "runAtMs": 1788322682078,
+            "runAtMs": 1789458947996,
+            "status": "ok",
+            "durationMs": 1,
+            "error": null
+          },
+          {
+            "runAtMs": 1789460747999,
             "status": "ok",
             "durationMs": 0,
             "error": null
           },
           {
-            "runAtMs": 1788324482179,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788326282305,
+            "runAtMs": 1789462548000,
             "status": "ok",
             "durationMs": 0,
             "error": null
           },
           {
-            "runAtMs": 1788328082308,
+            "runAtMs": 1789464348001,
+            "status": "ok",
+            "durationMs": 1,
+            "error": null
+          },
+          {
+            "runAtMs": 1789466148003,
             "status": "ok",
             "durationMs": 0,
             "error": null
-          },
-          {
-            "runAtMs": 1788329882515,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788331682517,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788333482519,
-            "status": "ok",
-            "durationMs": 0,
-            "error": null
-          },
-          {
-            "runAtMs": 1788335282521,
-            "status": "ok",
-            "durationMs": 0,
-            "error": null
-          },
-          {
-            "runAtMs": 1788337082522,
-            "status": "ok",
-            "durationMs": 0,
-            "error": null
-          },
-          {
-            "runAtMs": 1788338882524,
-            "status": "ok",
-            "durationMs": 0,
-            "error": null
-          },
-          {
-            "runAtMs": 1788340682525,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788342482527,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788344282529,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788346082530,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788347882532,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788349682534,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788351482536,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
-          },
-          {
-            "runAtMs": 1788353282539,
-            "status": "ok",
-            "durationMs": 0,
-            "error": null
-          },
-          {
-            "runAtMs": 1788355082541,
-            "status": "ok",
-            "durationMs": 1,
-            "error": null
           }
         ]
       },
-      "createdAtMs": 1788151596637,
-      "updatedAtMs": 1788355082542,
+      "createdAtMs": 1789455347851,
+      "updatedAtMs": 1789466148003,
       "deleteAfterRun": false
     }
   ]

develop/history.md

@@ -1,5 +1,134 @@
 # History
 
+## 2026-09-11 — AGENTS.md: pravidlo o exec guardu globálně + srovnání skillu `note`
+
+**Cíl:** Navázat na opravu skillu `project` (záznam níže) a zapsat pravidlo o exec
+guardu na místo, kde pomůže všem skillům, ne jen tomu, kde se zrovna projevilo.
+
+**Co jsem zkusil / co jsem našel:**
+
+Nejdřív jsem zjišťoval, který soubor nanobot vůbec načítá do system promptu.
+`build_system_prompt()` (`agent/context.py:70–121`) skládá prompt z
+`BOOTSTRAP_FILES = ["AGENTS.md", "SOUL.md", "USER.md"]`. Z nich je **`AGENTS.md` jediný
+user-ownovaný** — `SOUL.md`, `USER.md` i `memory/MEMORY.md` přepisuje Dream, bundled
+`templates/` přepíše upgrade balíčku.
+
+Při čtení `AGENTS.md` vyšlo najevo, že **tentýž bug už tam byl zdokumentovaný dvakrát
+izolovaně**: sekce `## Git commit timestamps` říká, že `date '+%Y-%m-%d %H:%M:%S'` guard
+blokuje (ověřeno — token `H:%M:%S`, `H` po `%`), a sekce `## exec Tool` řešila chybějící
+workspace path. Ani jednou se nepojmenovala společná příčina. Třetí výskyt byl živý:
+`note_capture.py --text "Cíl: koupit mléko"` → blok (token `l:`), přičemž
+`note/SKILL.md` explicitně nařizuje „Pass the input **as-is**". Poznámka uživatele
+začínající `Cíl:` tedy tiše selhávala — a capture bere vstup doslova, takže to nebyl
+okrajový případ, ale běžná česká formulace.
+
+**Co fungovalo a proč:**
+
+- **`workspace/AGENTS.md`** — nejdřív dotažena autoritativní serverová verze do repa
+  samostatným commitem (lokální kopie byla zastaralá a server je zdroj pravdy), teprve
+  pak přidáno pravidlo do sekce `## exec Tool`: text nikdy do command stringu, vždy
+  `write_file` do `tmp/` + předání cesty. Sekce `## Git commit timestamps` ponechána —
+  jmenuje konkrétní skript a je jen instancí obecného pravidla.
+- **`skills/note`** — `--text` nahrazen za `--file <path>` (fail fast na chybějící
+  soubor), obě volací místa v SKILL.md převedena na dvoukrok, přidána sekce *Never pass
+  the text on the command line*. Testy 19 → 22.
+
+Ověřeno na serveru proti **nainstalovanému** guardu:
+
+```text
+PROJDE    NOVY  --file -> []
+BLOKOVAN  STARY --text -> ['l:', 'r:']
+```
+
+End-to-end: `write_file` textu `Cíl: koupit mléko. Závěr: zítra.` + `--file` → soubor
+v `notes/inbox/` s korektním frontmatterem, exit 0. Inbox pak uklizen, **`log/note.log`
+ne** — je to append-only audit log a mazat ho by porušilo přesně to pravidlo, které
+tahle práce kodifikuje. Zůstal tam jeden testovací CAPTURE řádek z 15:09.
+
+Ověřeno i to, že se `AGENTS.md` do promptu opravdu dostává (liší se od
+`templates/AGENTS.md`; při shodě by ho `context.py:179–182` tiše vynechalo).
+
+**Co zbývá:**
+
+- `bookmark` (český článek v heredocu) a `remind` (`edit --text`) mají pořád stejnou
+  expozici — vědomě mimo scope, vedeno v `knowledge.md`.
+- `AGENTS.md` se bere z `project_root` aktuálního tahu (`context.py:163`), takže
+  v session scoped do `tmp/<x>` se root verze nenačte. Pro chat workflow to nevadí;
+  univerzální varianta by byl skill s `always: true`.
+- Regex v nanobotu zůstává rozbitý; tohle je workaround, ne fix.
+
+**Jak to vrátit zpět:** `git revert` příslušných commitů + rsync `workspace/AGENTS.md`
+a `skills/note/` na server. Nic se nemazalo kromě vlastních testovacích artefaktů.
+
+## 2026-09-11 — project: zápis do memory.md padal na exec guardu, převeden na --file
+
+**Cíl:** Agent na serveru nedokázal zapsat záznam do `projects/life/memory.md` —
+tři pokusy po sobě spadly na `Command blocked by safety guard (path outside
+working dir)`. Zjistit proč a opravit skill, aby se to neopakovalo.
+
+**Co jsem zkusil / co jsem našel:**
+
+Stažena session `002f2196` z `~/.nanobot/webui/`. Pořadí selhání: quoted heredoc
+→ `printf | pipe` → `--text`, všechny se stejnou chybou; uspěl až `write_file` do
+`tmp/` + `log life < tmp/soubor`. Agent si to ve vlastním shrnutí vyložil jako
+„nedeterministický blok na datu a tečkách" — **to je mylné**.
+
+Skutečná příčina, ověřená spuštěním nainstalovaného guardu
+(`/home/nanobot/.local/share/uv/tools/nanobot-ai/…/nanobot/agent/tools/shell.py`)
+na reálných příkazech: `ExecTool._extract_absolute_paths()` hledá windowsové cesty
+regexem s **ASCII-only negativním lookbehindem** `(?<![A-Za-z])[A-Za-z]:…`. Znak
+s diakritikou před ASCII písmenem lookbehind neutne, takže `Cíl:` → token `l:`,
+`Závěr:`/`směr:` → `r:`. `Path("r:").resolve()` se rozvine vůči cwd démona
+(`/home/nanobot`, ne vůči workdiru příkazu) → `/home/nanobot/r:` → mimo workspace
+→ blok. Guard navíc jede nad **raw command stringem bez shell parseru**, takže
+nerozliší argument od obsahu heredocu — proto padly všechny tři varianty stejně.
+Blokovaný text obsahoval `Diagnóza/směr:`; `artifacts/fyzio-cviky-kycele.md` ani
+lomítko samo o sobě vinné nebyly.
+
+Kontrolní vzorek proti nainstalovanému guardu (`--file` vs. staré varianty):
+
+```text
+PROJDE    NOVY  --file      -> []
+BLOKOVAN  STARY heredoc     -> ['l:', 'r:', 'r:']
+BLOKOVAN  STARY --text      -> ['l:', 'r:', 'r:']
+BLOKOVAN  STARY printf|pipe -> ['l:', 'r:', 'r:']
+```
+
+**Co fungovalo a proč:**
+
+Oprava není „jiný způsob citace", ale **text se nikdy nesmí dostat do command
+stringu**. Konkrétně:
+
+- `project_cli.py`: `--text` odstraněn, přidán `--file <path>` (fail fast na
+  neexistující soubor). Stdin zůstal jako fallback. Flag místo shell redirectu
+  proto, že celý failure mode byl model improvizující shell syntax.
+- `SKILL.md`: sekce „Writing to memory.md" přepsána na dvoukrok `write_file` do
+  `tmp/` + `log <slug> --file …`, s vysvětlením **proč**, ať to nikdo
+  neoptimalizuje zpátky na heredoc.
+- `SKILL.md` Rules: zákaz testovacích zápisů do ostrého projektu — agent si při
+  diagnostice zanesl do append-only `memory.md` dvě test položky a pak je ručně
+  odstranil, čímž porušil „never rewrite history". Od toho je `new <scratch-slug>`.
+- Testy: 15 → 20. Sekce `log` převedena na fixture `entry_file`, takže testuje
+  reálnou cestu přes soubor. Přibyl regresní test s `Cíl:`/`Závěr:`, test na
+  chybějící soubor a pojistka, že `--text` v argparse skončí `SystemExit 2`.
+
+Před nasazením ověřena shoda serveru s repem (`rsync` + `diff -r` → lišil se jen
+`__pycache__`). Nasazeno rsyncem, vlastník `nanobot:nanobot` ověřen, restart
+služby není potřeba. End-to-end test proti scratch projektu `guard-test` (ne proti
+`life`) s textem `Cíl: … Diagnóza/směr: … Závěr: …` prošel, exit 0; scratch
+projekt i `tmp/guard-test.md` pak smazány.
+
+**Co zbývá:**
+
+Guard v nanobotu je pořád rozbitý a **stejnou expozici mají další skilly** —
+`note` (`--text "<raw input>"` se syrovým českým vstupem uživatele, nejrizikovější),
+`bookmark` (český článek v heredocu) a `remind` (`edit --text`). Vědomě mimo scope
+této opravy, zapsáno do `knowledge.md` jako známý dluh. Plošný fix by znamenal
+unicode-aware lookbehind v upstreamu (resp. ve forku `nanobot-custom-commands`).
+
+**Jak to vrátit zpět:** `git revert` commitu se skillem + rsync `skills/project/`
+na server. Žádná data se nemazala kromě scratch projektu `guard-test`.
+
 ## 2026-09-02 — reflect: noční běh padal na timeout a zahazoval hotové dávky
 
 **Cíl:** Noční cron (`30 3 * * *`) neodběhl — ve 4:00 přišlo na Telegram
@@ -3054,3 +3183,679 @@ history`. Čeká na rozhodnutí autora.
   detail nepotřebuje, plná úvaha je v commitu aef90f3.
 
 **Jak vrátit zpět:** `git revert 917afb9` + rsync `skills/reflect/` na server.
+
+---
+
+## 2026-09-04 06:50 — Přeuklizení `keep.md`: rozdělení obsahu do správných úložišť
+
+**Cíl:** `keep.md` na serveru měl 8 položek, ale skill ho definuje pro trvalé osobní
+fakty / preference / rozhodnutí. Zjistit, co tam nepatří, přesunout do správného úložiště
+a zabránit opakování driftu.
+
+**Co jsem zkusil:**
+
+- Triáž všech 8 řádků proti popisu skillů `keep` / `note` / `project` a proti `AGENTS.md`.
+  Verdikt: 4× `notes.md`, 1× `AGENTS.md`, 1× `projects/proxmox/state.md`, 1× smazat, 1× nechat.
+- Sync server → repo **jako první krok** (`skills/keep/SKILL.md` a `workspace/AGENTS.md`) —
+  server byl u obou napřed, viz níže.
+- `notes.md`: stáhnout rsyncem, upravit lokálně Pythonem s unikátní kotvou + `assert`,
+  nahrát zpět, commit `note:` **jen** `git add notes/` v serverovém workspace repu.
+  Stejný postup pro `AGENTS.md`, `projects/proxmox/state.md` a `keep.md`.
+- Do `skills/keep/SKILL.md` vložena sekce `## Triage — before writing anything` před
+  `## Write protocol` + jeden řádek do `## Rules`. Nasazeno rsyncem celého adresáře.
+
+**Co fungovalo a proč:**
+
+- **Klíčové zjištění:** `AGENTS.md` → `## Explicit user details` říká *„Explicit user facts
+  are stored in `keep.md`. **Read at every turn**"*. `keep.md` je tedy v kontextu každého
+  tahu — proto tam pravidla pro agenta (#3, #6) čte model jako fakta o uživateli místo jako
+  instrukce, a věci k vyzkoušení obcházejí `/note`, kde je uživatel hledá. To je důvod
+  přesunu, ne estetika.
+- **Konflikt nalezen:** položka „git repo naklonuj do `tmp/`" byla v přímém rozporu
+  s konvencí `AGENTS.md` *„Always clone repos into `workspace/src/<repo-name>`"*.
+  Rozhodnutí uživatele: platí `AGENTS.md` → položka smazána, `AGENTS.md` beze změny.
+- **Server byl napřed před repem** (potvrzuje pravidlo „nejdřív stáhni, pak přepiš"):
+  serverový `keep/SKILL.md` měl zostřený `description` (`NOT collecting notes … (that is
+  note)`), a serverovému `AGENTS.md` chyběly v lokálním mirroru **dvě sekce**
+  (`## Explicit user details`, odstavec o safety-guard blocku). Slepý rsync repo→server
+  by obojí zahodil.
+- Nové pravidlo v `AGENTS.md` (bod 5, vícekrokový úkol = plán a rovnou provedení) muselo
+  dostat explicitní hranici vůči existující sekci `## No proactive actions`, jinak by si
+  konkurovaly: *„find out / investigate / check" zůstává information-only*.
+- Příčina driftu byla ve skillu, ne v jednotlivých zápisech — `keep` neměl žádný triage
+  krok, šel rovnou od „přeformuluj" k „zapiš".
+
+**Co zbývá:**
+
+- Funkční test triage gate (poslat přes Telegram `/keep <pravidlo pro agenta>` a ověřit,
+  že skill odmítne zapsat a odkáže na `AGENTS.md`) — vyžaduje živý provoz, neověřeno.
+- V `notes.md` sekci `## Claude Code / AI Agents` leží druhá skupina odrážek („Komunikace
+  v češtině", „Informace hledej … i v dokumentaci online", „Pokud si nejsi jistý, ptej se")
+  — to jsou pravidla pro agenta zabloudilá do `notes.md`, stejná třída chyby jako v keep.
+  Mimo zadání, neřešeno.
+- Změněné soubory v serverovém workspace repu (`keep.md`, `AGENTS.md`, `projects/`) jsem
+  **necommitoval** — byly modified už před zásahem (Dream/reflect vlastní zbytek workspace),
+  commituje se tam jen `notes/` přes `note` skill. Ponecháno ve stavu, v jakém repo běží.
+
+**Jak vrátit zpět:**
+
+- `keep.md` (není commitnutý, původní obsah doslovně):
+
+```
+- Podcast "Máš na míň" — moderátor Vašek Matějovský spolumoderuje s Radarem (Michal Vrátný, zakladatel Železné koule)
+- Chce mít filmy uložené lokálně na disku — streaming služby mění podmínky a dostupnost, chce mít obsah trvale k dispozici po zaplacení
+- Při studiu 3+ souborů z git repozitáře (typicky GitHub) naklonuj do tmp/ a zkoumej lokálně — ale jen pokud repo není obrovské (desítky MB OK, stovky MB+ už ne)
+- Otestovat s Claude Code plugin llm-wiki-plugin (https://github.com/praneybehl/llm-wiki-plugin)
+- Vyzkoušet LibreChat
+- Vícekrokový úkol/research: po vypsání plánu v témže turnu rovnou začněn provádět (plán ≠ konec turnu) a hlásit průběžný status — pouhé vypsání plánu a ukončení turnu vypadá jako dokončená odpověď, uživatel pak zbytečně čeká
+- Chce absolvovat kurz/workshop práce se dřevem se základními domácími nástroji; k tomu YouTube videa na teorii: typy dřeva, typy vrutů, typy bitů, moření, lakování, broušení, spojování vruty, lepení
+- Hlavní server proxmox.hell: Dell OptiPlex 9020 Mini Tower, Intel Core i7-4790 @ 3.60GHz, 32GB RAM, GeForce RTX 4060 Ti 16GB, KINGSTON SKC3000D2048G 2TB NVMe, KINGSTON SUV5004 56RI 480GB SSD
+```
+
+- `notes.md`: `ssh nanobot@nanobot.hell 'cd ~/.nanobot/workspace && git revert f136f50'`
+- `AGENTS.md` / `projects/proxmox/state.md`: `git checkout -- AGENTS.md projects/proxmox/state.md` v serverovém workspace repu (pozor: vrátí i případné cizí necommitnuté změny).
+- `skills/keep/`: `git revert a96a5c6` v tomto repu + rsync `skills/keep/` na server.
+
+---
+
+## 2026-09-04 07:20 — `keep` skill: description podle oficiálního formátu + přenositelnost
+
+**Cíl:** Uživatel reklamoval `description` u `skills/keep/SKILL.md` — čeština uvnitř a špatně
+napsaná proti tomu, jak má `description` vypadat. V průběhu doplnil druhou vadu: absolutní
+cesta v těle skillu ho dělá nepřenositelným.
+
+**Co jsem zkusil:**
+
+1. Porovnal serverovou verzi s repem (`ssh nanobot@nanobot.hell cat …`) — **identické**,
+   žádný drift od Dreamu k dotažení.
+2. Dostudoval dokumentaci. `nanobot.wiki` (0.3.0) frontmatter skillů **nedokumentuje** —
+   `/docs/0.3.0/` nemá stránku o skillech, `use-nanobot/concepts` je zmiňuje jen jako obsah
+   workspace. WebFetch na wiki vrací 403, curl s UA projde. Autoritou je proto
+   [Anthropic Skill authoring best practices](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices)
+   (formát je identický) + naše zjištění ze zdrojáku v `knowledge.md`.
+3. Změřil současnou verzi proti pravidlům: ✗ CZ triggery (EN-only + ověřeno, že
+   dvojjazyčné nic nepřidají), ✗ otevírá noun-phrase definicí místo slovesné fráze,
+   ✗ obsahuje *jak* funguje (dedup/compaction/cesta), ✗ interní architektura
+   (MEMORY.md / Dream), ✗ duplicita, ~ chybí odlišení od `/project`.
+   Třetí osoba porušená nebyla.
+4. Přepsal `description` do oficiálního tvaru `<co dělá>. Use when <triggery>.` (385 znaků,
+   limit 1 024), opravil poslední češtinu v těle (`"udělej compaction"` → `the user asks
+   for compaction`) a absolutní cestu → `workspace/keep.md`.
+5. Nasadil rsyncem, ověřil vlastníka.
+
+**Co fungovalo a proč:**
+
+- Grepy čisté: žádná čeština, žádné `/home/nanobot` v `skills/keep/SKILL.md`.
+- **Funkční test routingu:** `nanobot agent -m "zapamatuj si, že testovací server pro
+  staging je stag-07"` → odpověď `Kept: …`, záznam v `keep.md`. Skill se tedy trefil
+  i bez českých triggerů — potvrzuje ověřený předpoklad z `/plan` (2026-05-31), že
+  dvojjazyčné triggery jsou zbytečný token cost.
+- Testovací záznam z `keep.md` smazán (záloha `/tmp/keep.md.bak` na serveru).
+- `nanobot` binárka není v PATH non-login shellu — volat `~/.local/bin/nanobot`
+  (stejná gotcha jako u `uv`).
+
+**Co zbývá:**
+
+- `skills/plan/SKILL.md:45` má stejnou absolutní cestu, přitom řádky 69 a 75 v témže
+  souboru už jsou relativní. `bookmark` má absolutní cesty ve spouštěcích příkazech —
+  tam opodstatněné (PATH gotcha u `uv`). Neřešeno, mimo scope zadání.
+- Ostatní skilly nebyly proti oficiálnímu tvaru `description` proměřeny.
+
+**Jak vrátit zpět:** `git revert 18ab382` + rsync `skills/keep/` na server.
+
+---
+
+## 2026-09-09 20:20 — Final wiki: zhodnocení draftu hybrid RAG a přepis do `final-wiki-hybrid-rag.md`
+
+**Cíl:** Zhodnotit serverový draft `plans/notes-search-hybrid-rag.md` (hybrid RAG index nad
+uživatelovými git poznámkami), rozhodnout, jestli by to tak šlo, a přepsat do finálního plánu.
+
+**Co jsem zkusil:**
+
+1. Přečetl draft a proměřil prostředí místo věření odhadům v něm:
+   - Ollama na `nvidia.hell` dosažitelná; `qwen3-embedding` tam zpočátku nebyl (uživatel dodal).
+   - Cold load modelu 1,81 s vs. warm 0,043 s; throughput 8,9 chunk/s po jednom vs.
+     **108 chunk/s v batchi 32**.
+   - Cosine nad 10⁵×1024 v BLOB+numpy: **594 ms** = read 382 + pack 190 + **dot jen 22**.
+     Přes `.npy` + `mmap_mode='r'` 35 ms.
+   - FTS5: `remove_diacritics 1`+ foldí diakritiku, `záloh*` pokryje českou flexi.
+   - Korpus workspace: 234 md mimo `tmp/` → ~800 chunků (draft počítal 10⁴–10⁵).
+2. Ověřil `sqlite-vec` smoke testem celého navrženého schématu (`chunks` + `files` +
+   `chunks_fts` + triggery + `vec_chunks`) — včetně toho, na čem D3 stálo.
+3. Ověřil model na reálném obsahu: cross-jazyk retrieval test + vliv instruct prefixu.
+4. Přepsal plán do `final-wiki-hybrid-rag.md`, nasadil na server i do repa, starý draft
+   označil `> Superseded by`.
+
+**Co fungovalo a proč:**
+
+- **Díra v návrhu draftu**: RRF slučoval file-level BM25 s chunk-level cosine. Rank-merge dvou
+  různých jednotek nemá definovaný význam. Fix: `chunks` je jediná retrieval jednotka, FTS5 je
+  external-content nad ní, `vec0` má `rowid = chunks.id`, RRF slučuje `chunks.id`. Ověřeno.
+- **`vec0` obstálo ve všech kritických testech**: `DELETE`/re-`INSERT`/`UPDATE` po `rowid`,
+  transakční `ROLLBACK`, `distance_metric=cosine`, `vec0` v témže souboru jako běžné tabulky.
+  KNN k=20: **19 ms @ 10k, 212 ms @ 100k**. Kdyby `DELETE` nešel, D3 by padlo a vracel by se BLOB.
+- **Zdůvodnění D3 v draftu bylo špatné** — stavěl `sqlite-vec` jako „indexovaný KNN" (ANN).
+  Není; dokumentovaná cesta je průchod (lineární 19 → 212 ms to potvrzuje). Skutečná výhoda je,
+  že skenuje v C a odřízne těch 96 % Python režie.
+- **Ollama Cloud embeddingy neexistují** — 18 cloud modelů, žádný s capability `embedding`;
+  `/api/embed` na cloud modelu vrací `unauthorized`, zatímco `/api/generate` na tomtéž projde
+  (takže to není o autorizaci). Katalog na ollama.com potvrzuje: všech 12 embedding modelů
+  je jen ke stažení.
+- **D1 potvrzeno měřením**, ne argumentem: dotaz „jak snížit elektroodpad ze stavebnic" →
+  BM25 **1/5**, embeddingy **3/5**; lexikální dotaz naopak BM25 4/5. Obě poloviny si vydělávají.
+- **`exec` timeout 60 s** vs. plný index ~77 s → indexace nesmí běžet v tahu agenta. V draftu to
+  nebylo; uživatel zvolil offline cron s lockem, čímž `fetch-on-query` z draftu vypadl.
+- **Whitelist místo blacklistu** (na dotaz uživatele): ve workspace je 234 md mimo `tmp/` a
+  použitelných ~99 — zbytek `.venv/` 27, `cml/` 39, `skills/` 32, `backup/` 20, `tasks/` 16;
+  `tmp/` drží dalších 135. Blacklist by musel trvale pokrývat právě adresář určený k balastu.
+  Rozhodující je ale směr selhání: u blacklistu nový adresář *tiše vstoupí* do indexu.
+- DDL vytažené přímo z hotového dokumentu spuštěno proti `:memory:` — prošlo, a FTS5 i `vec0`
+  vrátily shodné `rowid`.
+
+**Co jsem měl špatně (korekce vlastních tvrzení):**
+
+- Tvrdil jsem, že vynechání **instruct prefixu** stojí víc než přechod na menší model. Test na
+  178 chunkách to vyvrátil: recall@5 s prefixem i bez něj **identický** (5/5 vs 5/5, 3/5 vs 3/5),
+  similarita s prefixem dokonce nižší. Prefix zlepšil jen top-1 nejtěžšího dotazu. V plánu
+  zůstává (je zdarma), ale zdůvodnění je teď „bitová identita indexace a dotazu", ne kritičnost.
+- Cold load jsem extrapoloval na 4–6 s; naměřeno **1,81 s**. `keep_alive: -1` je tedy výhodný,
+  ne nutný.
+- Dvě chyby v mých vlastních test skriptech, obě mě zdržely: chybějící
+  `isolation_level=None` (→ „cannot start a transaction within a transaction") a bufferovaný
+  stdout Pythonu, kvůli kterému 9 minut běžící skript neukázal, že visí na síťovém čtení.
+
+**Nálezy pro implementaci:**
+
+- **`ON DELETE CASCADE` z `files` uklidí `chunks` i FTS5 (trigger se na kaskádě spustí), ale
+  řádek ve `vec_chunks` osiří** — `vec0` není cílem foreign key. Indexer musí mazat `vec_chunks`
+  explicitně. Je to v plánu jako regresní test; jinak by index při mazání souborů tiše hnil.
+- `keep_alive` musí být **číslo** `-1` (nebo `"24h"`); string `"-1"` vrací HTTP 400.
+
+**Co zbývá:**
+
+- **Seznam rep** (URL + kam mirrorovat) — jediná věc, kterou musí doplnit autor; bez toho
+  nelze naplnit `config/notes-search.yaml`.
+- Zopakovat cross-jazyk benchmark na reálných repech (proběhl na workspace obsahu).
+- Návrh 6 vět do `decisions.md` je v plánu — **čeká na souhlas autora**, nezapsáno.
+- Mimo scope a jen hlášeno: `llm-wiki` řeší autor sám (zazálohuje a smaže);
+  `wiki-compile` existuje jen na serveru a v žádném commitu (drift, pravděpodobně Dream).
+
+**Jak vrátit zpět:** `git revert 36259d7`; na serveru smazat
+`plans/final-wiki-hybrid-rag.md` a odstranit vložený `> **Superseded by` řádek (druhý řádek)
+z `plans/notes-search-hybrid-rag.md`.
+
+---
+
+## 2026-09-09 — Oprava plánu final-wiki-hybrid-rag po plan-review
+
+**Cíl:** Projet `final-wiki-hybrid-rag.md` skrz `/lab:plan-review` a opravit, co review najde,
+aby byl plán implementovatelný bez hádání.
+
+**Co jsem zkusil:**
+
+Review vrátila verdikt „vrátit k přepracování": 5 blokujících nálezů, 7 k doplnění, 3 poznámky.
+Všechny kotvy, které plán uváděl jako existující, jsem ověřil a všechny sedí
+(`remind/scripts/db.py` symboly, `note_capture.py:25`, `_ascii_fold`, `.compile.lock`,
+`llm-wiki/scripts/wiki_search.py`, `develop/history.md` + `knowledge.md` na serveru, crontab
+vzor, `db/` v `.gitignore`). Plán nebyl superseded — skill neexistoval.
+
+Pět blokujících nálezů:
+
+1. Vrstva 2 (TOC) byla vyhlášená, ale sync ji negeneroval, schéma pro ni nemělo tabulku
+   a Verifikace ji netestovala.
+2. `git clone --mirror` je **bare** repo → vrstva 1 (`rg`) nemá working tree, co grepovat,
+   a chunker neměl řečeno, jak se z mirroru dostane obsah souboru.
+3. Chunky s `embedded_at IS NULL` se nikdy nedobraly: krok 3 syncu končí „nic se nezměnilo
+   → exit 0", jenže po degradovaném běhu se soubory nezměnily. Verifikace bod 4 přitom
+   tvrdila opak a partial index `idx_chunks_pending` nikdo nečetl.
+4. Skupinové klíče v YAML (`sources.git.*`, `sources.nanobot.*`) nešly namapovat na
+   `CHECK(kind IN ('git','workspace'))` — `nanobot` by CHECK odmítl.
+5. RRF neměl jediný parametr: chybělo `k` pro KNN, počet kandidátů z BM25, RRF konstanta,
+   výstupní top-k i váhy.
+
+**Co fungovalo a proč:**
+
+Před opravou jsem si nechal od autora rozhodnout adresářovou strukturu a jméno skillu, protože
+na tom visí deploy cesta, cron řádek i testy — a pak dvě věci **naměřil místo hádání**, když
+padla otázka „jak se to bude chovat, když do `include` dám i `*.py` a `*.cs`":
+
+- markdown-it-py nad Python souborem: komentář `# TODO: fix this` se parsuje jako **ATX
+  heading h1**. Chunker by řezal soubor v komentářích a stavěl breadcrumb
+  `foo.py > TODO: fix this` — ne horší kvalita, ale nesmysl.
+- FTS5 `unicode61`: `send`/`async` uvnitř `SendAsync` → **miss** (camelCase se nedělí);
+  `migrate` i `_migrate` → oba hit, nerozlišitelné. `tokenchars '_'` problém jen převrátí
+  (`get_db` hit, `get` miss). Jediný použitelný tokenizer je `trigram` — a ten je vlastnost
+  **tabulky**, ne řádku, takže smíšený korpus = druhá FTS tabulka a dvojí dotaz.
+
+Tohle rozhodlo D15 (index zůstává md-only) měřením, ne názorem. Náhradou je, že grep vrstva
+jede přes celý klon včetně kódu — soubory už na disku leží, takže to stojí nula.
+
+Dvě zjednodušení nálezy zrušila místo záplatování: **plochá konfigurace** s explicitním `kind`
+(padá nález 4) a **sloučení `workspace` + `develop`** do jednoho zdroje (stejný kořen, stejný
+kind, nebyl důvod je mít dva).
+
+Autor dodal URL obou rep, ověřeno z `nanobot.hell`: obě dostupná klíčem uživatele `nanobot`,
+obě `HEAD → refs/heads/master`. Otevřená otázka 1 tím padla.
+
+**Nálezy pro implementaci:**
+
+- Workspace na serveru **je git repo** a `wiki/` v jeho `.gitignore` chybí. Nasazení musí
+  přidat `wiki/*` + `!wiki/config.yaml`, jinak se do gitu commitne index (komprimovaná kopie
+  osobního obsahu) i klony. Původní plán se opíral o to, že `db/` je gitignorované —
+  přesunem pod `wiki/` ta záruka zmizela.
+- `note_compile.py:85-108` má stale-lock reclaim (mrtvý PID nebo stáří > 30 min). Plán měl
+  jen holý `O_EXCL`, což by po pádu procesu navždy umlčelo minutový cron bez jediného řádku
+  v logu. Převzato doslova.
+- Aritmetika v plánu byla špatně: 10⁴ chunků / 108 chunk/s je ~93 s, ne 77 s. Závěr
+  (> 60 s `exec` timeout) drží.
+
+**Co zbývá:**
+
+- **Pustit `/lab:plan-review` znovu** — skill se nedá vyvolat přes `Skill` tool
+  (`disable-model-invocation`), musí ho spustit autor. Cíl: 0 blokujících nálezů.
+- Návrh 4 vět do `decisions.md` — čeká na souhlas autora, nezapsáno: kořen runtime dat
+  `workspace/wiki/`, non-bare klon místo `--mirror`, plochá konfigurace s explicitním `kind`,
+  index výhradně nad markdownem.
+- Benchmark modelu na uživatelských datech zůstává jako výstup etapy 6.
+
+**Jak vrátit zpět:** `git revert 43688c5`. Na server se nesahalo.
+
+## 2026-09-09 22:10 — implementace a nasazení skillu `wiki` (hybrid RAG index)
+
+**Cíl:** Vykonat plán [plans/final-wiki-hybrid-rag.md](plans/final-wiki-hybrid-rag.md),
+etapy 1–7 včetně nasazení na server.
+
+**Co jsem zkusil / co fungovalo a proč:**
+
+- **Etapy 1–6 implementované a otestované lokálně** (`skills/wiki/`, commit `aecf597`):
+  87 testů, `ruff` i `ty` čisté. Pokrývají body 1–6 a 8 z Verifikace v plánu.
+- **Etapa 7 nasazena** na `nanobot.hell`: rsync skillu, `wiki/config.yaml`,
+  `.gitignore` (`wiki/*` + `!wiki/config.yaml`), první plný index a minutový cron.
+  Plný index: **152 souborů, 601 chunků, 601 vektorů, 0 pending za 45 s**
+  (index 55/123, travel 5/9, workspace 92/469).
+- **Dotaz end-to-end 53–62 ms** (cíl plánu byl pod 1 s). Rozpad odpovídá plánu:
+  embed dotazu ~55 ms, KNN 2–5 ms, BM25 < 1 ms, RRF zanedbatelné.
+- **Odchylky od plánu (mechanické, ne věcné):** moduly nesou prefix `wiki_`, protože
+  `db.py`/`store.py` kolidují s `remind` a `wiki_search.py` s `llm-wiki` ve `ty.toml`
+  `extra-paths` (ploché jmenné prostory, vyhrává první cesta). Přidány dva moduly nad
+  pětici z plánu — `wiki_config.py` (layout + rozsah) a `wiki_embed.py` (Ollama klient
+  + `meta` guard), protože obě vstupní body je potřebují a guard **musí** být identický
+  na obou stranách. `numpy` z dependency setu vypuštěno — `sqlite_vec.serialize_float32`
+  stačí, normalizace je jeden `math.sqrt`.
+- **Reálné selhání sítě ověřeno neplánovaně:** z mého stroje nemá SSH klíč právo na
+  `travel-notes.git`, takže první lokální běh doslova předvedl bod 8 — `WARN`, zdroj
+  přeskočen, `index` dojel. Na serveru (klíč uživatele `nanobot`) projde.
+
+**Nalezené a opravené vady (moje, ne plánu):**
+
+1. **Sekce obsahující jen svůj nadpis vytvářela prázdný chunk.** U běžného tvaru
+   `# Titul` → `## Sekce` by šum lezl skoro do každého dokumentu. Fix: taková sekce se
+   zahodí, nadpis se do indexu dostane přes breadcrumb potomků a `files.headings`.
+2. **Víceřádkový git stderr v logu.** Trvale nedostupný zdroj sype WARN každou minutu;
+   šestiřádkový stderr = tisíce řádků denně. Fix: `_one_line()` + strop 300 znaků.
+   Plán mluví o „řádku WARN" — teď to řádek skutečně je.
+3. **Coverage report hlásil i `wiki/`** (klony v `wiki/remote/` obsahují md).
+   Strukturálně nikdy nekandidát, ne rozhodnutí k revizi → z reportu vyřazen.
+
+**Otevřená otázka č. 1 plánu (benchmark modelu) — uzavřena.** 12 parafrázových dotazů
+s jednoznačným cílovým souborem nad reálnými 123 chunky repa `index`:
+
+| Varianta | recall@5 | recall@10 | MRR |
+|---|---|---|---|
+| BM25 sám | 5/12 | 5/12 | 0,257 |
+| qwen3-embedding:0.6b + instruct prefix | 4/12 | **8/12** | 0,261 |
+| qwen3-embedding:0.6b bez prefixu | 2/12 | 3/12 | 0,204 |
+| mxbai-embed-large | 6/12 | 6/12 | 0,261 |
+| nomic-embed-text | 3/12 | 4/12 | 0,170 |
+| **RRF hybrid** | 6/12 | 6/12 | **0,367** |
+
+D1 i D2 platí: hybrid má lepší MRR než obě poloviny samostatně, `nomic` je nejhorší
+(plán ho zamítal správně). V top-10 najde cíl **jen vektory u 3 dotazů, jen BM25 u 0** —
+vektorová polovina na tomhle korpusu lexikální pokrytím dominuje, BM25 ale dává lepší
+top-1 rank když trefí. Čtyři dotazy nenašel nikdo, protože cílové soubory jsou stuby
+(50–483 B, většinou shell příkazy) — chyba mých labelů, ne retrievalu; na odpověďorelných
+dotazech je hybrid 6/8.
+
+**Co nesouhlasí s plánem:**
+
+- **Instruct prefix NENÍ „nekritická vlastnost"** (plán, Query kontrakt). Naměřeno
+  recall@10 **8/12 s prefixem vs. 3/12 bez** na uživatelských datech. Plán měřil
+  5/5 vs 5/5 na 178 chuncích jiného korpusu. Prefix je load-bearing; je zapsán
+  v `meta.query_prefix` a jeho změna vyžaduje `--full`.
+- **D6 („prefix wildcard pokryje českou flexi") platí jen na půl.** Prokázáno na
+  serveru: `cestu*` → 0 chunků v `travel/packaging-list.md`, `cesty*` → 3, `cest*` → 4.
+  Wildcard je **prefixový**, takže pomůže jen když je dotazové slovo prefixem tvaru
+  v dokumentu; „cestu" prefixem „cesty" není. Plán to dokládal dotazem `záloh*`, což
+  je už samotný **kmen**, ne skloněné slovo. Důsledek: na dotaz „co si vzít na cestu
+  do zahraničí" se doslovný seznam věcí na cestu nedostal ani do top 10.
+
+**Co zbývá:** viz [todo.md](todo.md) — rozhodnout o dotazové vrstvě u české flexe
+a návrh 4 vět do `decisions.md` (čeká na souhlas autora, nezapsáno).
+
+**Jak vrátit zpět:** na serveru `crontab ~/.nanobot/backup/crontab.bak-20260909-220814`,
+pak `rm -rf ~/.nanobot/workspace/wiki ~/.nanobot/workspace/skills/wiki` a vrátit řádky
+`wiki/*` + `!wiki/config.yaml` z `.gitignore`. Lokálně `git revert aecf597`.
+
+## 2026-09-09 23:25 — README ke skillu `wiki` + oprava prázdných titulků
+
+**Cíl:** Doplnit ke skillu `wiki` lidsky psaný `README.md` (mentální model, proč je co tak,
+operátorský runbook), protože vysvětlení bylo rozeseté po `history.md`, result dokumentu
+a konverzaci. `SKILL.md` je záměrně EN instrukce pro agenta — tohle do něj nepatří.
+
+**Co jsem zkusil / co fungovalo a proč:**
+
+- **`skills/wiki/README.md`** (214 řádků), česky, druhá osoba, ve stylu existujících
+  `skills/reflect/README.md` a `skills/compact-memory/README.md` — což jsou jediné dva
+  README v repu, takže konvence se dala odečíst přímo z nich. Sekce: tři vrstvy, offline
+  indexace a proč, co se v tiku děje, proč hybrid, česká flexe, index jako nápověda,
+  rozsah indexace, kde co leží, ruční spuštění, hlášky, ověření.
+- **Ze `SKILL.md` na README záměrně nevede odkaz.** Ani `reflect`, ani `compact-memory` ho
+  nemají; README je pro člověka a nesmí stát agenta kontext. (`detach/architecture.md`
+  odkaz má, ale to je anglický dokument jiného žánru.)
+- **Každé tvrzení v README ověřeno proti kódu**, ne napsáno z hlavy: hlášky doslova
+  grepem z `wiki_search.py`/`wiki_embed.py`, cesty vyhodnocením konstant z `wiki_config.py`,
+  flagy z `parse_args()`. Příkazy ze sekce „Ruční spuštění" spuštěny naostro na serveru
+  včetně `--source` s neexistujícím id (exit 1, `WARN unknown source`).
+
+**Nalezená a opravená vada — `files.title` byl NULL u všech 152 souborů.**
+
+Vyšlo to při ověřování příkladu z README: `toc` tiskl prázdný sloupec s titulkem pro
+**celý korpus**, přitom plán ho ukazuje jako podstatnou část výstupu. Příčina: `title` se
+bral výhradně z frontmatteru `title:`, ale uživatelovy poznámky nesou titulek jako `# H1`.
+
+Fix: fallback na první nadpis. Po `--full` je pokrytí **117/152** (`index` 55/55,
+`travel` 5/5, `workspace` 57/92); zbylých 35 jsou raw zachyty `/note` v `notes/done/`
+bez jediného H1–H3 nadpisu — tam není z čeho titulek vzít a slug v názvu souboru ho nese.
+
+Podstatné rozhodnutí u toho fixu: fallback plní **jen katalog, ne breadcrumb root**.
+Kdyby šel do rootu, přepsal by se text všech chunků (breadcrumb je součástí embedovaného
+textu) a musel by se bumpnout `chunker_version` s vynuceným `--full` u každého uživatele.
+Takhle je to změna jednoho sloupce v `files`.
+
+**Vedlejší nález:** padl existující test `test_malformed_frontmatter_stays_body`. Nebyla to
+regrese — u rozbitého frontmatteru (`---\ntitle: [unclosed\n---`) udělá markdown-it z toho
+řádku **setext nadpis**, takže ho fallback vezme jako titulek. Frontmatter se opravdu
+nespotřeboval (tagy zůstaly prázdné, text zůstal v těle), jen test tvrdil něco jiného,
+než byl jeho záměr. Přepsán na to, co má tvrdit.
+
+**Co zbývá:** nic z tohoto zásahu. Otevřené položky skillu `wiki` v `todo.md` (česká flexe,
+návrh do `decisions.md`) se nemění.
+
+**Jak vrátit zpět:** `git revert 3adc2ef`, pak na serveru rsync skillu a
+`wiki_sync.py --full` (titulky se vrátí na NULL). Index se tím nerozbije — `title` je
+jen sloupec v katalogu, retrieval na něm nestojí.
+
+---
+
+## 2026-09-15 06:20 — Ollama usage poller: revize serverového plánu + nasazení sběru
+
+**Cíl:** Uživatel chtěl dotáhnout serverový plán `plans/ollama-usage-poller.md`
+(napsal si ho nanobot sám 2026-09-14) do repa a probrat, jak ho realizovat a kde
+má slabiny. Záměr plánu: minutový cron → SQLite, aby šlo zpětně zjistit, kolik
+která session stála.
+
+**Co jsem zkusil:** Nejdřív ověření předpokladů plánu proti reálnému serveru
+(ne proti tomu, co plán tvrdí). Nálezy, kvůli kterým se návrh měnil:
+
+- **`memory/history.jsonl` nemá tokeny.** Plán na něm stavěl budoucí atribuci
+  („per-request timestamps, token counts, session ids"). Reálně obsahuje jen
+  `{cursor, timestamp, content}` (+ `session_key` u 59 ze 430 řádků) — je to
+  destilát paměti z Dreamu. `sessions/*.jsonl` má `role/content/timestamp/
+  tool_calls/reasoning_content/latency_ms`, **taky bez tokenů a bez modelu**.
+  Jediný zdroj tokenů je `LLM usage:` v journalu, což je DEBUG a `-v` už v
+  `ExecStart` **není** (poslední takový řádek je z 2026-05-27) — `knowledge.md`
+  tvrdila opak, opraveno.
+- **`limits.*.usage` má rozlišení 0,1 %** (API vrací 3 desetinná místa).
+  Plánovaný report `Δsession %, Δweekly %` per dvojice vzorků sliboval přesnost,
+  kterou data nemají → osa reportu přepnuta na `request_count` per model.
+- **`models` je pole `[{name, request_count}]`**, ne slovník jak tvrdil komentář
+  ve schématu → kanonizace na setříděný dict, jinak by se zapisovalo každou minutu.
+- **Umístění `workspace/scripts/`** odporovalo vzoru — všech 6 existujících cron
+  entry míří do `skills/<name>/scripts/` → přesunuto do `skills/usage/scripts/`,
+  čímž odpadl i `sys.path` hack kolem reuse `load_api_key`.
+- **Write-on-change nerozliší klid od výpadku** → doplněna tabulka
+  `meta(last_ts, last_status)`, přepisovaná při každém běhu včetně chybového.
+- Ukládá se i `session.models` (plán si nechával jen `weekly`).
+
+**Co fungovalo a proč:** Skill `usage` dotažen do repa (dosud tam vůbec nebyl),
+přidány `ollama_usage_poll.py` + `ollama_usage_report.py` (stdlib only, EN),
+sekce „Continuous sampling" do `SKILL.md`, rsync na server (`nanobot:nanobot`),
+cron entry `* * * * *`. Ověřeno:
+
+1. Dva běhy po sobě → `samples` má 1 řádek, `meta.last_ts` se posunulo oběma
+   (04:19:46 → 04:19:53). Write-on-change funguje.
+2. `OLLAMA_API_KEY=bogus` → exit 0, `meta.last_status = 'http_401'`,
+   žádný nový řádek. Cron se tím nezanáší.
+3. Logika reportu ověřena na syntetické DB ve scratchpadu: hranice session okna
+   (pokles `session_usage` i součtu `session_models`), mezera v datech,
+   per-model delty, souhrn.
+4. Cron potvrzen (`meta.last_ts` se posouvá bez ručního spuštění,
+   `log/ollama_usage_cron.log` prázdný).
+
+**Co zbývá:** Atribuce na sessions — přesunuto do `todo.md`, až bude pár dní dat.
+Vedlejší přínos, který plán nepojmenoval: minutová řada ověří/vyvrátí domněnku
+ve `skills/usage/SKILL.md`, že session okno je kalendářní hodina
+(`until_next_full_hour` je odhad, ne údaj z API).
+
+**Jak vrátit zpět:** `crontab -e` a smazat entry `ollama-usage`;
+`rm ~/.nanobot/workspace/db/ollama_usage.sqlite`;
+`rm ~/.nanobot/workspace/skills/usage/scripts/ollama_usage_{poll,report}.py`
+a rsync `SKILL.md` z gitu před commitem. Lokálně `git revert`.
+
+---
+
+## 2026-09-15 10:05 — Session okno: fixní 5h blok, fáze kalibrovaná z DB
+
+**Cíl:** Skill `/usage` hlásil „Session: … resets in 2 minutes", zatímco web
+ukazoval 4 hodiny. Zjistit proč a dát tomu odhad, který se dá věřit.
+
+**Co jsem zkusil:**
+
+1. Porovnání serveru s repem — server běžel se starou verzí z 14. 9.
+   (`until_next_full_hour()`). **Oprava z předchozí session se nikdy nenasadila**
+   a ležela necommitnutá v repu. To je celé vysvětlení „2 minut" (běželo 06:58 UTC).
+2. Data z `db/ollama_usage.sqlite`: session spadla z `0.077`/21 req na `0.0`/`{}`
+   mezi vzorky 04:28:01 a 06:00:01 → **fixní blok, ne rolling okno** (rolling by
+   se rozpadal postupně).
+3. Kalibrace proti webu (uživatel hlásil, co vidí): ~06:58 „4 hodiny",
+   ~07:05 „3 hodiny", session **2,3 %** — procento přesně sedí s API, takže
+   dashboard a `/api/usage` čtou totéž.
+4. Délka okna z primárního zdroje — [transparent-pricing](https://ollama.com/blog/transparent-pricing):
+   nové plány zrušily „5-hour or weekly limits", tenhle klíč je má → **5 h**.
+5. Původní návrh přidával do polleru heartbeat, aby šlo mezeru v `samples`
+   odlišit od výpadku. **Uživatel ho zamítl** — DB má zůstat čistě změnová.
+   Ukázalo se, že je zbytečný (viz níže).
+
+**Co fungovalo a proč:** Mřížka je periodická, takže každý pozorovaný reset
+omezuje **tutéž fázi**. Jedno pozorování ohraničí hranici intervalem
+`(poslední vzorek před, první vzorek po]`; průnik těch intervalů **modulo 300
+minut** fázi dopočítá. Dvě vlastnosti, proč to heartbeat nepotřebuje:
+
+- Ohraničení platí, i když poller neběžel — **výpadek interval jen rozšíří**,
+  nikdy nezpůsobí špatný závěr. Není tedy co dokazovat.
+- Když je délka bloku špatně, průnik se **vyprázdní** místo tiché chyby.
+
+Dokud je kandidátů víc než `MAX_SPREAD`, reset se nevypisuje — dnešní data dávají
+93 z 300, takže skill zatím hlásí holé `Session: 2.4 %`. To je správný výstup.
+
+Nález při psaní výpisu mřížky: **5 h nedělí 24 h**, takže „mřížka 00/05/10/15/20
+UTC" nemůže být stálá — buď startuje denně (s kratším posledním blokem), nebo
+plave. Obě hypotézy jsou zatím konzistentní s daty a průnik je rozliší; report
+proto tiskne jen **příští hranici**, ne seznam denních.
+
+Časy ve výstupu jsou v lokální zóně serveru (`.astimezone()`, nic
+nehardcodováno), ale výpočet zůstává v UTC — v lokálním čase by ho přechod na
+zimní čas 25. 10. posunul o hodinu a zahodil kalibraci.
+
+Ověřeno: 19 kontrol na syntetických datech (zúžení průniku, prázdný průnik,
+bracket ≥ 300 min, drift přes den, rozestup přes DST), proti reálné DB
+(93 kandidátů → `None`), formátování pod `TZ=Europe/Prague`/`UTC`/`America/New_York`,
+a po nasazení přímo na serveru včetně běhu polleru. Uzavírá položku
+z `todo.md` o ověření domněnky o kalendářní hodině.
+
+**Co zbývá:** Rozhodující pozorování — příští hranice ve **12:00 nebo 13:00
+CEST**. Podle toho, jak blízko ní bude poslední aktivita, se fáze zúží a skill
+začne reset hlásit sám. Pak porovnat s webem.
+
+**Jak vrátit zpět:** `git revert ff9ac3e` + rsync `skills/usage/` na server.
+
+## 2026-09-15 10:15 — Session okno se kotví requestem, ne mřížkou (oprava modelu)
+
+**Cíl:** Uživatel namítl dvě věci k předchozímu záznamu: (a) mlčení místo odhadu
+mu nepomáhá, „lepší něco než nic"; (b) **hranice přece nemusí být pevná — nemůže
+se začít počítat od prvního dotazu po pauze?**
+
+**Co jsem zkusil:** Bod (b) je testovatelný, tak jsem šel do dat dřív, než jsem
+dodělal (a). Z `sessions/*.jsonl` jsem vytáhl timestampy assistant zpráv a
+poskládal bloky aktivity oddělené pauzami. Rekonstrukce (UTC):
+
+| Okno | Start | Konec |
+|---|---|---|
+| W2 | 00:00 (první request po vypršení W1) | 05:00 |
+| W3 | 06:00 (první request po vypršení W2) | 11:00 |
+
+**Co fungovalo a proč:** Rozhodl **chybějící zápis v 05:00**. Kdyby existovala
+pevná mřížka, usage by se v 05:00 vynulovala a poller (běží každou minutu) by
+změnu zapsal. Místo toho se nezměnilo nic až do 06:00, kdy přišel první request
+po 93minutové pauze. Vzorek `0.0`/`{}` v 06:00:01 tedy **není okamžik resetu, ale
+okamžik startu nového okna**. Pevná mřížka by navíc vyžadovala, aby ten request
+padl na hranici náhodou (~1:93).
+
+Počty requestů to nerozhodly (23 v 00:00–05:00 vs 19 v 01:00–06:00 proti
+hlášeným 21) — assistant zprávy nejsou 1:1 s LLM requesty.
+
+Model přepsán na **poslední pozorovaný přechod + 5 h**. Vedlejší efekt: je to
+výrazně jednodušší než průnik kandidátních fází modulo 300 min, který jsem
+nasadil o hodinu dřív, a **hlásí reset okamžitě** — čímž vyřešil i bod (a).
+Server teď říká `Session: 2.5 %, resets 13:00 CEST (in 2 h 47 min)`.
+
+Za konec okna se nic neextrapoluje: po vypršení výstup řekne, že další okno
+začne dalším requestem. Report dostal `Rollover gap:` řádky jako průběžný test
+modelu — rozestup delší než blok potvrzuje kotvení requestem, rozestup přesně
+roven bloku přes dlouhou nečinnost by ukazoval zpět na pevnou mřížku.
+
+Ověřeno 15 kontrolami na syntetické DB (kotva, víc přechodů, chybějící DB,
+vypršelé okno, okno přes přechod na zimní čas, formátování v UTC i CEST),
+proti reálné DB a po nasazení na serveru.
+
+**Poučení:** Předchozí záznam (09:xx) tvrdil „fixní blok" a stavěl na tom celou
+kalibrační mašinerii. Hypotézu „start prvním requestem" jsem měl v úvahách na
+začátku, ale zahodil ji bez testu — přitom šla ověřit ze `sessions/*.jsonl`,
+které jsem měl celou dobu k dispozici. Past, která to držela naživu: crony
+běží na celé hodiny, takže hranice *vypadaly* jako mřížka.
+
+**Jak vrátit zpět:** `git revert 9f39d29` + rsync `skills/usage/` na server.
+Předchozí (mřížkový) model je `ff9ac3e`.
+
+## 2026-09-15 10:40 — Review a zeštíhlení skillu `usage`
+
+**Cíl:** Projít `skills/usage/SKILL.md` — jestli splňuje náležitosti skillu a jestli
+v něm nejsou zbytečnosti. Plus odpovědět, k čemu je v DB tabulka `meta`.
+
+**Co jsem zkusil:** Přečetl SKILL.md, všechny tři skripty, `knowledge.md`, porovnal
+serverovou verzi s lokální (server == HEAD, žádný drift). Review podle
+`core:skill-authoring`.
+
+**Co fungovalo a proč:**
+
+- **Zbytečnosti.** Sekce „Reset times" byla ze ~40 řádků z větší části forenzní důkaz
+  — *jak* jsme model session okna naměřili. 1:1 duplikát `knowledge.md` („Ollama session
+  okno"), history 2026-09-15 10:15 a docstringů `window_rollovers()` / `print_window()`.
+  V SKILL.md se platí kontextem při každém načtení a agentovi neříká, co má dělat —
+  vyhozeno, důkazy zůstávají v tracking souborech a v kódu. Pravidlo „žádné modely na
+  Session/Weekly řádcích" bylo řečené třikrát, falzifikační odstavec o `Rollover gap:`
+  dvakrát. 117 → 96 řádků.
+- **Nepřesnosti vůči skriptům** (všechny opraveny): `print_session()` má tři větve,
+  dokumentovaná byla jedna (chybělo „window expired…" a samotné procento); Weekly řádek
+  slíbený jako „resets in Y days", ale `fmt_delta_short()` pod 24 h tiskne hodiny;
+  „report ends with `Session window:`" — ve skutečnosti končí `Last poll:`; zdroj klíče
+  je env **pak** `workspace/.env`, ne jen `.env`.
+- **Tabulka `meta` — odpověď na otázku.** Zapisuje se do ní (`record_poll()` na všech
+  třech cestách pollu: `ok`, `http_<kód>`, `unreachable`), ale je to **jeden řádek**
+  (`id = 1`), ne log. Čte ji jen `print_poll_status()` → `Last poll: <ts> (status)`.
+  Smysl: `samples` se plní jen při změně, takže bez `meta` nejde odlišit „nic se
+  nezměnilo" od „poller je mrtvý / API vrací 401". Zůstává; zapisovat vzorek při každém
+  pollu bylo dřív zamítnuto (knowledge „Zamítnuto: heartbeat v usage polleru"), `meta`
+  je právě ta zmenšená náhrada. Opraven ale **popis** v SKILL.md i v docstringu polleru
+  — tvrdil „records every poll, so a gap can be told apart from a failed poll", což
+  naznačuje historii; přepsaný řádek rozsoudí jen liveness *teď*.
+- **Trigger fráze** ukotveny na „ollama" (`ollama usage/quota/credits/limits`, `how much
+  of the ollama plan is left`, `ollama usage report`). `"usage history"` zrušeno a obecné
+  `"quota"` zamítnuto uživatelem — netriggerovalo by, tahalo by skill na cizí dotazy.
+- **Verifikace na serveru:** `ollama_usage.py` → `Session: 2.8 %, resets 13:00 CEST
+  (in 2 h 22 min)` / `Weekly: 16.2 %, resets in 5 days` + Models sekce — sedí se šablonou
+  řádek po řádku. Report končí `Last poll: 2026-09-15T08:37:01+00:00 (ok)`, `meta` má
+  jeden řádek s čerstvým timestampem. Verifikace odhalila i poslední nepřesnost: při
+  jediném rolloveru v historii report žádné `Rollover gap:` řádky netiskne
+  (`itertools.pairwise`) — formulace upravena na „from the second recorded rollover on".
+  Nasazeno rsyncem, md5 lokál == server, vlastník `nanobot:nanobot`, bez restartu služby.
+
+**Co zbývá:** Nic. Commit `a7a725e`.
+
+## 2026-09-16 07:20 — Fix po přejmenování presetů `glm53`→`glm`, `kimi27`→`kimi`
+
+**Cíl:** Uživatel přejmenoval aliasy modelů v serverovém `config.json`. Rozbily se dvě
+noční cron úlohy (`KeyError: "model_preset 'kimi27' not found"` z compact-memory,
+`'glm53'` z reflectu). Vrátit je do provozu a najít i místa, kde je rozbití tiché.
+
+**Co jsem zkusil / co jsem našel:**
+
+Dva paralelní skeny — lokální repo a server. Aktuální stav configu: 11 presetů, default
+`glm` (= `glm-5.3:cloud`), fallback `kimi` (= `kimi-k2.7-code:cloud`). Obě přejmenování
+jsou 1:1 na stejný model string, takže oprava je mechanická a joby poběží na tomtéž
+modelu jako dřív.
+
+*Proč to nechytila validace:* `Config._validate_model_preset` (nanobot `config/schema.py`,
+model_validator mode="after") ověřuje při startu **jen** `agents.defaults.modelPreset` a
+`fallbackModels`. Obojí uživatel přejmenoval správně, takže gateway nastartovala bez
+chyby. Preset předaný ad-hoc do `Nanobot.from_config(model_preset=...)` — což dělají
+právě oba cron skripty — neprochází žádnou statickou kontrolou a spadne až za běhu
+v `Config.resolve_preset()`.
+
+*Tichá část (to, co „není vidět"):* serverový `~/.nanobot/workspace/knowledge/models.md`
+je tabulka presetů, podle které si agent vybírá `/model`. Obsahovala neplatné aliasy —
+a navíc **neodpovídala configu ani před přejmenováním**: `glm` měl model id
+`glm-5.3-flash` (reálně `glm-5.3`, flash je samostatný preset `flash`), překlep `glmi51`
+místo `glm51`, chyběly presety `flash`, `sonnet`, `haiku`, `gemini-flash(-lite)`, a řádek
+„Kódování: `kimi27` (fallback: `kimi`)" byl po přejmenování sebereferenční nesmysl.
+Uživatel rozhodl srovnat celou tabulku s realitou a sjednotit daily driver i těžké úlohy
+na `glm` (glm-5.3); eskalační sekce „Kdy přepnout na glm53" tím ztratila smysl a je
+nahrazena „Kdy sáhnout po `flash`" (multimodální vstup — `glm` je text-only — a levné
+rutinní tahy).
+
+*Co rozbité nebylo:* `skills/detach/` (resolvuje presety dynamicky přes
+`load_preset_names()`/`resolve_preset()`), `skills/usage/`, `cron/jobs.json`
+(dream/heartbeat/version-check preset nenastavují, `dream.modelOverride` je `null`),
+systemd unity, `workspace/USER.md` (`Preset: glm` je dál platné), fronty
+`tasks/{inbox,new,running}`. Komentáře v `reflect_auto.py:49` a `reflect_distill.py:55`
+zmiňují **model** `glm-5.3:cloud`, ne preset — zůstaly.
+
+**Co fungovalo a proč:**
+
+1. Nejdřív `rsync` serverového `knowledge/models.md` do repa vlastním commitem (`3d17bf8`) —
+   lokální verze byla z 2026-06 a úplně jiný soubor, slepý přepis by serverovou verzi
+   (přepsanou 2026-08-29) zahodil. Pravidlo „server je zdroj pravdy" se vyplatilo.
+2. `MODEL_PRESET` opraven na `"glm"` / `"kimi"`, `compact-memory/README.md` srovnán,
+   `knowledge/models.md` přepsán proti reálnému `modelPresets` (commit `dcb66d5`).
+3. Nasazeno rsyncem celých adresářů skillů + `knowledge/models.md`, vlastník
+   `nanobot:nanobot`, bez restartu služby.
+4. Verifikace: `Nanobot.from_config(model_preset=...)` pro `glm` i `kimi` proběhne a loguje
+   přepnutí na `glm-5.3:cloud` / `kimi-k2.7-code:cloud` (přesně ta cesta, co padala);
+   grep starých aliasů přes `skills/`, `knowledge/` a `config.json` je prázdný; reflect
+   `--dry-run --max-batches 1` exit 0; lokálně 219 testů zelených.
+5. Grep zpočátku hlásil zbylý výskyt v `skills/reflect/scripts/__pycache__/*.pyc` —
+   zastaralý bytecode ze 2. 9., smazán (Python si ho vygeneruje znovu).
+
+**Gotcha pro příště:** `~/.local/bin/uv` plnou cestou — v neinteraktivním SSH není `uv`
+v `PATH` (`bash: uv: command not found`).
+
+**Co zbývá:**
+
+- E2E potvrzení nočního běhu (02:00 compact-memory, 03:30 reflect) — v logu nesmí být
+  `KeyError` a má přijít Telegram report. `compact_memory_auto.py` nemá dry-run a mutuje
+  `memory/MEMORY.md`, takže ruční spuštění jsem nedělal.
+- Mimo rozsah, hlášeno uživateli: `src/MiniLoop/config.json` je commitnutý v gitu včetně
+  živého OpenRouter API klíče v plaintextu (řádek v `src/MiniLoop/.gitignore` je
+  zakomentovaný). Vyžaduje rotaci klíče a odstranění z historie.
+- Automatický validátor presetů uživatel zamítl — Telegram alert z nočního běhu je jako
+  detekce dostatečný. Postup ruční kontroly zapsán do `knowledge.md`.

develop/knowledge.md

@@ -260,12 +260,21 @@ Modely se přidávají jako položky do `model_presets` v `~/.nanobot/config.jso
 
 4. **V chatu** (Telegram/WebUI) přepneš příkazem `/model <preset-name>`.
 
-**Konvence pojmenování presetů:** krátký alias podle modelu — `kimi`, `kimi27`, `kimi3`, `glm`, `glm52`, `sonnet`, `haiku`, `gemini-flash`. (Dřív tu stálo `<model>-<provider>` jako `kimi-k2.6-openrouter`; reálný stav na serveru je od nějaké doby krátká forma, ověřeno 2026-07-27.)
+**Konvence pojmenování presetů:** krátký alias podle modelu. Aktuální sada (ověřeno 2026-09-16): `glm`, `flash`, `glm52`, `glm51`, `kimi`, `kimi26`, `kimi3`, `sonnet`, `haiku`, `gemini-flash`, `gemini-flash-lite`. **Nepojmenovaný alias = aktuální generace** (`glm` = glm-5.3, `kimi` = kimi-k2.7-code), číslovaný = zamrzlá starší verze. (Dřív tu stálo `<model>-<provider>` jako `kimi-k2.6-openrouter`, pak `glm53`/`kimi27`; 2026-09-16 přejmenováno na současnou formu.)
 
 **Parametry presetu:** `maxTokens` 16384 a `temperature` 0.1 napříč všemi presety. `contextWindowTokens` se drží na **~97 % reálného okna modelu** (rezerva na výstup), reálné okno se čte z `curl http://nvidia.hell:11434/api/show -d '{"model":"<id>"}'` → `model_info["<family>.context_length"]`. `reasoningEffort: null` = zachovat default providera (`schema.py:141`), explicitní hodnota jen kde ji chceme vynutit (`glm52: high`).
 
 **Ollama gotcha:** `providers.ollama.apiBase` musí končit `/v1` (`http://nvidia.hell:11434/v1`) — viz [[Ollama provider potřebuje `/v1` suffix v `apiBase`]].
 
+**Gotcha — přejmenování presetu validace nechytí.** `Config._validate_model_preset` (nanobot `config/schema.py`, model_validator mode="after") ověřuje při startu **jen** `agents.defaults.modelPreset` a `fallbackModels`. Preset předaný ad-hoc do `Nanobot.from_config(model_preset=...)` neprojde žádnou statickou kontrolou a spadne až za běhu v `Config.resolve_preset()` — u nočních cron jobů tedy ve 2:00 do logu a Telegramu, ne při editaci configu. **Po každém přejmenování presetu projdi tahle místa:**
+
+- `skills/reflect/scripts/reflect_auto.py` → `MODEL_PRESET`
+- `skills/compact-memory/scripts/compact_memory_auto.py` → `MODEL_PRESET`
+- serverový `~/.nanobot/workspace/knowledge/models.md` — tabulka presetů, podle které si agent vybírá `/model`; neplatný alias tam je tichá chyba (agent zkusí neexistující preset)
+- `skills/detach/` řešit nemusíš — preset resolvuje dynamicky přes `load_preset_names()`/`resolve_preset()`
+
+Jednorázový check: `ssh nanobot@nanobot.hell 'grep -rn -e <starý-alias> ~/.nanobot/workspace/skills/ ~/.nanobot/workspace/knowledge/ ~/.nanobot/config.json'` (pozor na `__pycache__` — zastaralý `.pyc` matchne, ale nic neovlivní). Automatický validátor uživatel 2026-09-16 explicitně zamítl: Telegram alert z nočního běhu je jako detekce dostatečný. Plný záznam: history 2026-09-16.
+
 ## Ollama Cloud: některé modely jsou „extra usage only" (kimi-k3)
 
 `kimi-k3:cloud` je v `api/tags` vidět a `/model kimi3` v nanobotu se přepne bez chyby, ale **každé volání skončí HTTP 402**:
@@ -292,7 +301,7 @@ Nanobot defaultně **vypíná vlastní logy** (`logger.disable("nanobot")`), pro
 
 Žádná env proměnná ani config klíč pro log level mimo tyhle flagy neexistuje.
 
-**Nasazení u nás:** `-v` přidáno do `ExecStart` v `~/.config/systemd/user/nanobot.service` na `nanobot.hell`. Logy živě: `ssh nanobot@nanobot.hell 'journalctl --user -u nanobot.service -f --no-pager'`.
+**Nasazení u nás:** `-v` bylo v `ExecStart` v `~/.config/systemd/user/nanobot.service` na `nanobot.hell`, ale **už tam není** (ověřeno 2026-09-15: `ExecStart=/home/nanobot/.local/bin/nanobot gateway`, poslední `LLM usage` řádek v journalu je z 2026-05-27). Bez `-v` tedy **tokeny nikde nejsou** — `Processing message`/`Response to` jsou INFO a logují se dál, `LLM usage` je DEBUG a ne. Logy živě: `ssh nanobot@nanobot.hell 'journalctl --user -u nanobot.service -f --no-pager'`.
 
 **Co `-v` ukáže v jednom tahu** (ověřeno na WebUI zprávě):
 
@@ -347,6 +356,16 @@ Pole `description` ve frontmatteru non-always skillu je **routing signál**, ne
 
 Zdroj: `nanobot/agent/skills.py:111-159` (`build_skills_summary`, `_get_skill_description`), `skills.py:94-109` (`load_skills_for_context`, always skilly), `nanobot/agent/context.py:87-95`.
 
+**Oficiální tvar `description`** ([Anthropic — Skill authoring best practices](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices), platí i pro nanobot, formát je identický). Nanobot wiki frontmatter skillů nedokumentuje — autoritou je tenhle dokument plus zjištění ze zdrojáku výše.
+
+- Tvar: `<co skill dělá, slovesná fráze>. Use when <triggery/kontexty>.` Např. `Extract text and tables from PDF files, fill forms, merge documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.`
+- **Vždy třetí osoba** — `Processes Excel files…`, nikdy `I can help you…` ani `You can use this to…`; nekonzistentní osoba zhoršuje discovery.
+- Musí obsahovat **co dělá i kdy použít**, klíčový use case první, konkrétní klíčové termíny. Vágní (`Helps with documents`) je anti-pattern.
+- Limit **1 024 znaků** (Agent Skills spec); Claude Code listing ořezává na 1 536.
+- Nanobotí dodatek k tomu: „co dělá" = **schopnost**, ne postup. `Adds, deduplicates, and compacts entries in keep.md` je *jak* → do těla.
+
+Aplikováno na `keep` (history 2026-09-04).
+
 ## Dream procesor — automatické self-improvement
 
 Nanobot má vestavěný Dream procesor (`agent/memory.py:Dream`) který běží každé 2 hodiny. Jde o **dvou-fázový LLM pipeline** nad `history.jsonl`:
@@ -560,6 +579,28 @@ Daemon notifikuje **jen Telegram** (přes Bot API, deterministicky). Když task
 
 ---
 
+## Exec safety guard shazuje český text — diakritika + dvojtečka = „windowsová cesta"
+
+**Problém → příčina → pravidlo.** `exec` vrátí `Command blocked by safety guard (path outside working dir)` u příkazu, který obsahuje běžnou českou prózu. Příčina: `ExecTool._extract_absolute_paths()` (`agent/tools/shell.py`) hledá windowsové cesty regexem `(?<![A-Za-z])(?:[A-Za-z]:[^\s"'|><;]*|…)`. Lookbehind je **ASCII-only**, takže znak s diakritikou před ASCII písmenem ho neutne — `Cíl:` dá token `l:`, `Závěr:`/`směr:` dají `r:`. `Path("r:").resolve()` to rozvine vůči cwd démona (`/home/nanobot`, ne vůči workdiru příkazu) na `/home/nanobot/r:` → mimo workspace → blok. Ověřeno 2026-09-11 spuštěním nainstalovaného guardu na reálných příkazech.
+
+**Guard jede nad raw command stringem, bez shell parseru** (`_split_shell_segments` se používá jen na allow/deny patterns). Nerozliší tedy argument od obsahu heredocu — heredoc, `--text` i `printf | pipe` s týmž textem padnou identicky. Citování a quoted heredoc **nepomáhají**.
+
+**Pravidlo pro psaní skillů: český text nikdy nedávej do command stringu.** Vždy `write_file` do `tmp/` + předání **cesty** (`--file <path>`, nebo `< tmp/soubor`). Cesta v příkazu je neškodná; relativní cesty žádný z regexů nechytá.
+
+**Pravidlo je od 2026-09-11 zapsané globálně** v `workspace/AGENTS.md`, sekce `## exec Tool` — tedy v system promptu při každém tahu, nezávisle na tom, jaký skill se triggerne. `AGENTS.md` je jediný z `BOOTSTRAP_FILES` (`agent/context.py:57`), který je user-ownovaný; `SOUL.md`, `USER.md` i `memory/MEMORY.md` přepisuje Dream a bundled `templates/` přepíše upgrade balíčku. **Dvě omezení:** (1) `AGENTS.md` se bere z `project_root` aktuálního tahu (`context.py:163`), takže v session scoped do `tmp/<x>` se root verze nenačte — pro běžný chat platí; (2) kdyby byl obsah identický s `templates/AGENTS.md`, soubor se do promptu tiše nedá (`context.py:179–182`). Tentýž guard byl v `AGENTS.md` předtím zdokumentovaný **dvakrát izolovaně** (sekce `## Git commit timestamps` o `date '+%H:%M:%S'` → token `H:%M:%S`, a původní věta o chybějícím workspace path), aniž by se pojmenovala společná příčina.
+
+Co blokuje a co ne (ASCII písmeno + `:`, kde znak **před** písmenem není ASCII písmeno):
+
+| Blokuje | Projde |
+|---|---|
+| `Cíl:`, `Závěr:`, `směr:`, `díl:` | `Úkol:`, `Stav:`, `Řešení:`, `Otázky:`, `Poznámka:` |
+
+Pozor i na druhý guard nad raw stringem: `if "..\\" in cmd or "../" in cmd` → jakákoli **prozaická** zmínka `../` shodí příkaz na `path traversal detected`.
+
+**Stav skillů.** Opraveno na `--file`: `project` (`log --file`) a `note` (`note_capture.py --file`, 2026-09-11 — byl nejrizikovější, protože bere vstup uživatele doslova, takže poznámka „Cíl: …" tiše selhala). **Zbývá dluh:** `bookmark` (český článek v heredocu) a `remind` (`edit --text "…"`). Upstream regex zůstává rozbitý — fix by chtěl unicode-aware lookbehind.
+
+---
+
 ## Prostředí `exec` toolu — PATH z procesu tam nedosáhne
 
 `ExecTool._build_env()` (`agent/tools/shell.py`) staví prostředí subprocessu **od nuly**. Na Unixu předá jen `HOME`, `LANG`, `TERM`, `PYTHONUNBUFFERED` (+ cokoli v `tools.exec.allowedEnvKeys`). **`PATH` se z `os.environ` nekopíruje** — na Windows ano, na Unixu ne. Cokoli nastavíš v systemd unitu, `~/.profile` nebo wrapperu, `exec` neuvidí.
@@ -713,7 +754,7 @@ Substituce Claude.ai "Projects". Adresář na projekt, ne jeden soubor: `workspa
 
 **Nahradil netrackovaný server-side skill** (existoval na serveru mimo tento repo, žádná zmínka v history/knowledge/decisions před tímto datem): plochý soubor `projects/<slug>.md` s frontmatterem `status`/`priority`/`created`, CLI backend (`scripts/project.py`: add/list/show/status), `switch` ukládal aktivní projekt do `my` scratchpad nástroje (viz níže). Reálná data (`projects/radio-1.md`, projekt na stříhání audio streamu Radia 1, 2026-06-09) přemigrována do nového formátu jako `projects/radio1/`. Plná historie: history.md 2026-07-22.
 
-**Zápis do `memory.md` jde výhradně přes `skills/project/scripts/project_cli.py log`** (od 2026-09-02). Subcommandy `activate` / `log` / `list` / `new`; volat workspace-relativně `uv run skills/project/scripts/project_cli.py …`. Skript vlastní datum (systémové hodiny, Europe/Prague) a koncový newline — obojí model prokazatelně kazil: `chata/memory.md` měl dva záznamy s vymyšleným datem `2026-09-14` (zapsané 09-01) a `proxmox/memory.md` slepený append na předchozím řádku, protože `edit_file` kotva se hádala bez přečtení souboru. Text se předává **stdin quoted heredocem** (`<<'NOTE'`), ne `--text` — shell obsah neinterpretuje, takže `„"`, `'` i `"` projdou doslova (v `log/note.log` je doložený případ, kdy model `--text` argument zmršil na `...`). Stav skriptu přepisuje env `PROJECTS_DIR` (testy). Plný kontext: history.md 2026-09-02.
+**Zápis do `memory.md` jde výhradně přes `skills/project/scripts/project_cli.py log`** (od 2026-09-02). Subcommandy `activate` / `log` / `list` / `new`; volat workspace-relativně `uv run skills/project/scripts/project_cli.py …`. Skript vlastní datum (systémové hodiny, Europe/Prague) a koncový newline — obojí model prokazatelně kazil: `chata/memory.md` měl dva záznamy s vymyšleným datem `2026-09-14` (zapsané 09-01) a `proxmox/memory.md` slepený append na předchozím řádku, protože `edit_file` kotva se hádala bez přečtení souboru. Text se předává **výhradně souborem**: `write_file` do `tmp/` + `log <slug> --file tmp/…` (od 2026-09-11). Dřív to byl stdin quoted heredoc (`<<'NOTE'`), protože `--text` model prokazatelně mrzačil (v `log/note.log` je doložený případ, kdy argument zmršil na `...`) — jenže heredoc padl na exec safety guardu, který sejme jakýkoli český text v command stringu bez ohledu na citování (viz sekce „Exec safety guard shazuje český text" výše; doloženo session `002f2196`, kdy tři varianty po sobě selhaly na `Diagnóza/směr:`). `--text` je proto z CLI **odstraněn**, stdin zůstal jako fallback. Stav skriptu přepisuje env `PROJECTS_DIR` (testy). Plný kontext: history.md 2026-09-02.
 
 **Projektová data nemají strop ani konsolidaci** — `memory.md` roste neomezeně a nikdy se nekomprimuje ani nearchivuje. Velikost se řeší **výhradně na straně čtení**: `activate` nad limitem tool výsledku vypustí z výstupu nejstarší záznamy a ukáže cestu k plnému logu, soubor na disku nechá beze změny. Zamítnutá varianta: prahy 8 000 / 12 000 znaků s nabídkou konsolidace — ztráta zadaného obsahu je horší failure mode než jakákoli úspora kontextu (a čísla stála na špatném okně, viz níže).
 
@@ -760,7 +801,7 @@ Nanobot má **hardcoded default `context_window_tokens = 65_536`** pro `ModelPre
 
 Nastaveno 2026-06-02 per-preset na reálné limity modelů (kimi-k2.6 / qwen3.5 / nemotron-3-super 262144, minimax-m2.7 204800, glm-5.1 196608, deepseek-v4-flash 1048576) + `maxTokens` 16384. **Bez restartu** — `modelPresets` se hot-reloadují (viz sekce „Kdy je a není potřeba restart"). U `:cloud` modelů hostí kontext Ollama cloud, takže `contextWindowTokens` reálně rozšíří budget — není to lokální `num_ctx` žeroucí RAM. Plný záznam: history 2026-06-02.
 
-**Gotcha — `agents.defaults.contextWindowTokens` je zavádějící číslo.** V serverovém `config.json` je `65536`, ale to platí jen když preset vlastní hodnotu nemá. Reálné okno aktuálního defaultu (**`glm53`: 976 000**, `glm52`/`glm-flash` 976 000, `kimi3` 1 020 000, `sonnet`/`gemini-flash` 256 000) je ~15× větší, než `defaults` napovídá. **Než z 65k něco odvodíš, přečti `model_presets`, ne `agents.defaults`** — na tomhle jsem 2026-09-02 postavil celý (zamítnutý) rozpočet velikosti pro `/project`. Limit, který v praxi kouše, je `maxToolResultChars: 16000`, ne okno.
+**Gotcha — `agents.defaults.contextWindowTokens` je zavádějící číslo.** V serverovém `config.json` je `65536`, ale to platí jen když preset vlastní hodnotu nemá. Reálné okno aktuálního defaultu (**`glm`: 976 000**, `flash`/`glm52` 976 000, `kimi3` 1 020 000, `sonnet`/`gemini-flash` 256 000) je ~15× větší, než `defaults` napovídá. **Než z 65k něco odvodíš, přečti `model_presets`, ne `agents.defaults`** — na tomhle jsem 2026-09-02 postavil celý (zamítnutý) rozpočet velikosti pro `/project`. Limit, který v praxi kouše, je `maxToolResultChars: 16000`, ne okno.
 
 **Důsledky (trade-off, ne čistá výhra):**
 
@@ -1105,7 +1146,7 @@ Naměřeno na reálném destilátu (90 kB promptu → 75 135 tokenů podle tikto
 
 ## `contextWindowTokens` presetu přebíjí `agents.defaults`
 
-`agents.defaults.contextWindowTokens` je 65536, ale preset `glm53` má 976000 a **vyhrává** — `agent/loop.py:476` (`context_window_tokens = extra.pop(...) or resolved.context_window_tokens`). Efektivní input budget = `contextWindowTokens - maxTokens - 1024` (`SNIP_SAFETY_BUFFER`, `agent/context_governance.py:105`), tedy ~958k tokenů pro glm53.
+`agents.defaults.contextWindowTokens` je 65536, ale preset `glm` má 976000 a **vyhrává** — `agent/loop.py:476` (`context_window_tokens = extra.pop(...) or resolved.context_window_tokens`). Efektivní input budget = `contextWindowTokens - maxTokens - 1024` (`SNIP_SAFETY_BUFFER`, `agent/context_governance.py:105`), tedy ~958k tokenů pro `glm`.
 
 ## Velká zpráva projde, `snip_history` krátí jen historii
 
@@ -1145,3 +1186,179 @@ history 2026-09-02.
 v `tmp/`) a ostrý store i cílový soubor zůstanou nedotčené. Použito při ověření draftování
 patche na reálném nálezu `f5c34`. Zdroj: `skills/reflect/scripts/reflect_apply.py:250`,
 history 2026-09-02.
+
+## `keep.md` je v kontextu každého tahu — proto je jeho čistota load-bearing (2026-09-04)
+
+`AGENTS.md` → `## Explicit user details` říká *„Explicit user facts are stored in `keep.md`.
+**Read at every turn**"*. Co v `keep.md` leží, platí model každý tah. Dva praktické důsledky:
+pravidlo pro agenta uložené v keep se čte jako *fakt o uživateli*, ne jako instrukce (slabší
+tah než `AGENTS.md`), a referenční materiál tam obchází `/note`, kde ho uživatel hledá přes
+`/note search`. Do keep patří jen trvalý fakt / preference / rozhodnutí o uživateli; ostatní
+routuje `## Triage` v `skills/keep/SKILL.md`. Zdroj: history 2026-09-04.
+
+## `notes/` v serverovém workspace repu commituje výhradně skill `note` (2026-09-04)
+
+`skills/note/SKILL.md` → *Versioning*: Dream se `notes/` nedotýká, takže `note` je jediný,
+kdo tam commituje — a vždy jen `git add notes/`, nikdy `git add -A` (zbytek workspace vlastní
+Dream). Zbytek serverového workspace repa běžně stojí s necommitnutými změnami
+(`keep.md`, `AGENTS.md`, `cron/jobs.json`, `reflect/*`) — to je normální stav, ne rozbité repo.
+Při ruční editaci `notes.md` proto commitni s prefixem `note:` a stage jen `notes/`.
+Zdroj: history 2026-09-04.
+
+## Ollama Cloud embeddingy neexistují — cloud tier je completion-only (2026-09-09)
+
+Žádný z 18 cloud modelů nemá capability `embedding`; `/api/embed` na cloud modelu vrací
+`unauthorized`, **zatímco `/api/generate` na tomtéž modelu projde** — takže to není problém
+autorizace, cloud tier ten endpoint prostě neobsluhuje a hláška je zavádějící. Katalog na
+ollama.com to potvrzuje: filtr `c=embedding` vrací 12 modelů, všechny jen ke stažení, žádný
+s cloud tagem. Embeddingy je tedy nutné hostovat lokálně. Zdroj: history 2026-09-09.
+
+## Cena brute-force cosine v SQLite je z 96 % Python režie, ne matmul (2026-09-09)
+
+Nad 10⁵×1024 float32: **594 ms = read 382 + pack 190 + dot 22**. Samotný numpy matmul je
+zanedbatelný; platí se za extrakci BLOBů a jejich složení do matice. Proto `sqlite-vec`
+(`vec0`) dá **19 ms @ 10k a 212 ms @ 100k** — skenuje v C. `.npy` + `mmap_mode='r'` je
+ještě rychlejší (35 ms), ale za cenu druhého souboru mimo DB. Pozor: `vec0` **není ANN
+index** — lineární škálování 19 → 212 ms to potvrzuje, výhoda je konstanta, ne asymptotika.
+Zdroj: history 2026-09-09.
+
+## FTS5 a čeština: `remove_diacritics` + prefix wildcard stačí, trigram netřeba (2026-09-09)
+
+`unicode61 remove_diacritics 1` a výš foldí diakritiku (dotaz `zaloha` najde `záloha`;
+hodnota `0` ne). Stemming `unicode61` neumí, ale **prefix wildcard to pokryje**: `záloh*`
+i `zaloh*` najdou *záloha, zálohování, zálohy*. Dotazová vrstva tedy lepí `*` na termy —
+trigram tokenizer není potřeba. Souvisí s varováním v `remind/scripts/store.py`
+(`find_active_by_exact_text()`), že SQLite `lower()` foldí jen ASCII. Zdroj: history 2026-09-09.
+
+## `vec0` není cílem foreign key — kaskáda ho nevyčistí (2026-09-09)
+
+`ON DELETE CASCADE` z nadřazené tabulky uklidí navázané řádky **i FTS5 external-content
+tabulku** (AFTER DELETE trigger se na kaskádě spustí), ale řádek ve `vec0` virtuální tabulce
+**osiří** — indexer ho musí mazat explicitně. Jinak index při mazání souborů tiše plní mrtvými
+vektory. Ověřeno smoke testem; `DELETE`/re-`INSERT`/`UPDATE` po `rowid` a `ROLLBACK` ve `vec0`
+jinak fungují normálně (sqlite-vec v0.1.6). Zdroj: history 2026-09-09.
+
+## Ollama `keep_alive` musí být číslo, ne string (2026-09-09)
+
+`{"keep_alive": -1}` i `{"keep_alive": "24h"}` → HTTP 200; **`{"keep_alive": "-1"}` → HTTP 400**.
+Cold load `qwen3-embedding:0.6b` (639 MB) je 1,81 s vs. warm 0,043 s, takže připíchnutí modelu
+se vyplatí, ale není kritické. Batching je naopak podstatný: 8,9 chunk/s po jednom vs.
+**108 chunk/s v batchi 32**. Zdroj: history 2026-09-09.
+
+## Instruct prefix je u `qwen3-embedding` load-bearing, ne kosmetika (2026-09-09)
+
+Na 12 parafrázových dotazech nad 123 reálnými chunky: **recall@10 8/12 s prefixem
+vs. 3/12 bez něj** (MRR 0,261 vs 0,204). Plán `final-wiki-hybrid-rag` ho označoval za
+„nekritickou vlastnost" na základě 5/5 vs 5/5 na jiném korpusu — na uživatelských datech
+to neplatí. Prefix musí být **bitově identický** při indexaci i dotazu, proto žije
+v `meta.query_prefix` a jeho změna vyžaduje `wiki_sync.py --full`. Zdroj: history 2026-09-09.
+
+## FTS5 prefix wildcard NEfolduje českou flexi — jen prefixy (2026-09-09)
+
+`záloh*` najde *záloha/zálohování/zálohy* jen proto, že `záloh` je **kmen**. Se skutečně
+skloněným dotazovým slovem to selže: naměřeno `cestu*` → **0** chunků v
+`travel/packaging-list.md`, `cesty*` → 3, `cest*` → 4. Wildcard je prefixový, takže pomůže
+jen když je dotazové slovo prefixem tvaru v dokumentu — a česká flexe mění koncovku, ne
+začátek. Důsledek: dotaz „co si vzít na cestu do zahraničí" nedostal doslovný seznam věcí
+na cestu ani do top 10. Tohle je polovičnost D6 v plánu, ne chyba implementace.
+Zdroj: history 2026-09-09.
+
+## Hybrid RRF zlepšuje rank, ne pokrytí (2026-09-09)
+
+Nad reálnými poznámkami: MRR **0,367 u RRF** vs 0,257 (BM25 sám) a 0,261 (vektory samy) —
+merge dvou ranků téže množiny opravdu vyhrává. Ale `recall@10` u RRF je **6/12**, zatímco
+vektory samotné 8/12: RRF řadí podle **shody** obou polovin, takže chunk, který našla jen
+vektorová polovina na ranku #9, vytlačí z top-10 chunky, na kterých se poloviny shodnou.
+Očekávaný kompromis, ne vada. Zdroj: history 2026-09-09.
+
+## Bare `python3` neotevře `vec_chunks` — potřebuje `sqlite_vec.load()` (2026-09-09)
+
+Dotaz na běžné tabulky (`chunks`, `files`) přes systémový `python3` projde, ale jakmile se
+sáhne na `vec0` virtuální tabulku, přijde `sqlite3.OperationalError: no such module: vec0`.
+Extension se musí načíst explicitně (`enable_load_extension(True)` + `sqlite_vec.load(conn)`),
+což skill dělá v `wiki_db.get_db()`. Při ruční inspekci indexu na serveru je proto nutné
+`uv run --with "sqlite-vec==0.1.6"`. Zdroj: history 2026-09-09.
+
+## `ty.toml` `extra-paths` je plochý jmenný prostor — kolize modulů mezi skilly (2026-09-09)
+
+Typechecker `ty` řeší `import store` proti seznamu `extra-paths` a **vyhrává první cesta**,
+takže dva skilly se stejným jménem modulu si navzájem rozbijí kontrolu (testy `wiki`
+dostávaly `store` z `remind`). Proto všechny skilly kromě `remind` prefixují moduly jménem
+skillu (`note_capture.py`, `wiki_sync.py`) — je to nutnost, ne estetika. U kolize, které se
+nelze vyhnout (`wiki_search.py` je i v retired `llm-wiki`), rozhoduje **pořadí** v
+`extra-paths`. Zdroj: history 2026-09-09.
+
+## Ollama usage API: co v odpovědi je a co ne
+
+`GET https://ollama.com/api/usage` (Bearer klíč z `workspace/.env`) vrací
+`limits.session` (hodinové okno) a `limits.weekly`, každé s `usage` (zlomek limitu)
+a `models: [{name, request_count}]` — **pole, ne slovník**. `activity.cost` je na Pro
+plánu rozbité (vždy `0.00000`). Žádné reset timestampy, žádné tokeny, žádný cost split.
+
+**`usage` má 3 desetinná místa** (`0.072`, `0.156`) → rozlišení 0,1 % limitu.
+Delta za minutu je proto skoro vždy 0 — jediná přesná veličina je `request_count`
+per model. Ověřeno 2026-09-15.
+
+## Nanobot nemá nikde per-session spotřebu tokenů
+
+- `memory/history.jsonl` = destilát paměti z Dream procesoru (`cursor`, `timestamp`,
+  `content`, u části `session_key`) — **není** to účtovací log, žádné tokeny.
+- `sessions/*.jsonl` = per-turn zprávy (`role`, `content`, `timestamp`, `tool_calls`,
+  `reasoning_content`, `latency_ms`) — **taky bez tokenů a bez názvu modelu**.
+- Jediný zdroj tokenů je `LLM usage: prompt=… completion=… cached=…` v journalu, což je
+  **DEBUG** (vyžaduje `-v` v `ExecStart`, viz sekce o log levelu) a navíc nenese session id.
+
+→ Atribuce spotřeby na session jde jen **časovou korelací** (timestampy v `sessions/*.jsonl`
+a `Processing message from …` v journalu) proti řadě vzorků z `db/ollama_usage.sqlite`.
+Ověřeno 2026-09-15, zdroj: [[plans/ollama-usage-poller.md]] sekce Revize.
+
+---
+
+## Ollama session okno: 5 h kotvených prvním requestem, ne pevná mřížka
+
+Okno **nezačíná na pevné mřížce** — začíná prvním requestem po vypršení
+předchozího (jako 5h sessions v Claude Code). Naměřeno 2026-09-15: usage
+zůstala na `0.077`/21 req přes 05:00 UTC (pevná mřížka by ji tam vynulovala
+a poller by to zapsal) a resetovala se až s requestem v 06:00, po 93minutové
+pauze. Rekonstrukce aktivity z `sessions/*.jsonl` dává souvislý řetězec
+00:00–05:00, pak 06:00–11:00 UTC.
+
+Délka 5 h je z primárního zdroje
+[transparent-pricing](https://ollama.com/blog/transparent-pricing) („no 5-hour
+or weekly limits" je to, co **nové** plány zrušily; tenhle klíč je pořád má).
+Že jde o okno a ne rolling counter je taky měřené — pokles `0.077`/21 → `0.0`/`{}`
+naráz, rolling by se rozpadal postupně.
+
+**Praktický důsledek:** konec okna = poslední pozorovaný přechod v `samples`
++ 5 h. Za konec se nesmí extrapolovat — další okno začne až dalším requestem,
+takže čas neexistuje, dokud request nepřijde. Detail: history 2026-09-15 10:15.
+
+**Pozor na past:** crony nanobota běží na celé hodiny (Dream po 2 h atd.), takže
+první request po pauze často padne na celou hodinu. Hranice pak *vypadají* jako
+pevná mřížka, i když nejsou.
+
+**Zamítnuto:** kalibrace fáze průnikem kandidátů modulo 300 min. Stála na
+předpokladu pevné mřížky a navíc potřebovala víc pozorování, než začala hlásit
+cokoli. Nahrazeno výše. Vedlejší poznatek, který z ní zbyl: **5 h nedělí 24 h**,
+takže „mřížka 00/05/10/15/20 UTC" nemůže být stálá tak jako tak.
+
+## `limits.session.usage` == procento na dashboardu; countdown na webu ne
+
+API `2.3 %` sedělo přesně s tím, co uživatel viděl na webu. **Countdown na webu
+je ale ke kalibraci nepoužitelný** — zaokrouhluje neznámo jak: v 06:58 UTC
+ukazoval „4 hodiny" a v 07:05 „3 hodiny". Proto skill tiskne i konkrétní čas,
+ne jen „resets in X".
+
+## Zamítnuto: heartbeat v usage polleru
+
+Nápad zapisovat vzorek i beze změny (aby mezera v `samples` znamenala výpadek)
+je **zbytečný** — interval `(poslední před, první po]` kolem resetu je pravdivý
+bez ohledu na to, jestli poller běžel; výpadek ho jen rozšíří. Uživatel ho
+zamítl a měl pravdu: DB zůstává čistě změnová.
+
+## `uv` není v PATH při neinteraktivním SSH
+
+`ssh nanobot@nanobot.hell 'uv run …'` selže na `uv: command not found` — je
+v `~/.local/bin`, který se nenačte. Crontab to řeší vlastním řádkem
+`PATH=/home/nanobot/.local/bin:/usr/bin:/bin`. Při ručním spuštění přes SSH
+předřadit `export PATH=/home/nanobot/.local/bin:$PATH`.

develop/memory.md

@@ -31,3 +31,60 @@ Po každém commitu, který mění `knowledge.md`, `history.md` nebo `memory.md`
 **Why:** Uživatel 2026-06-02 chtěl agentovi zpřístupnit develop kontext a zvolil průběžnou synchronizaci (ne jednorázovou kopii) — jinak agent časem uvidí zastaralý stav.
 
 **How to apply:** `rsync -av <soubor> nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/develop/`. `README.md` v `develop/` je statický popis, ten se nesynchronizuje. Owner zůstává `nanobot:nanobot` (jdeme jako `nanobot`).
+
+## feedback: než navrhneš řešení, nejdřív se podívej na reálný stav souborů na serveru
+
+Když uživatel navrhuje změnu/přidání do serverové konfigurace (skill, `SOUL.md`/`AGENTS.md`/ostatní workspace soubory, config), **nejdřív si stáhni a přečti aktuální serverovou verzi** a ověř, zda navrhovaná věc už neexistuje nebo není vyřešená jinak — teprve pak navrhuj postup.
+
+**Why:** Uživatel 2026-06-07 — na otázku „má smysl zapsat nanobotovi reasoning anglicky?" jsem rovnou navrhl formulaci a celý deployment, ale pravidlo už v `SOUL.md` dávno bylo (napsal si ho Dream procesor sám 2026-05-27). Celý návrh byl zbytečný. Uživatel to označil za podstatnější poznatek než samotnou odpověď. Server se navíc mění autonomně (Dream), takže předpoklady z paměti/repa můžou být zastaralé.
+
+**How to apply:** U čehokoli, co se týká serverového stavu, je první krok `rsync`/`ssh cat` reálného souboru + kontrola, jestli problém už není vyřešený. Návrh řešení až po ověření. Platí i pro „malé" změny, které vypadají triviálně.
+
+## feedback: u bugu nejdřív najdi a dolož PŘÍČINU, neiteruj workaroundy
+
+Než navrhnu jakýkoli fix chování (zvlášť rendering/UI bug), musím **nejdřív najít a doložit kořenovou příčinu** — přečíst reálný **nasazený** kód, který chování produkuje (ne upstream/podobnou verzi), a získat **přímý důkaz** (např. session log s tím, co model skutečně vrátil). Teprve s prokázanou příčinou navrhovat řešení.
+
+**Why:** 2026-06-14 (`/note` + URL ve WebUI, viz [[plans/note-wrong-urls.md]]) jsem několik kol nasazoval kosmetické obezličky (linkify → backtick → odrážky → tučné číslo), všechny selhaly, a teprve pak našel příčinu: custom fork WebUI má `li` handler, co přebalí každou položku seznamu s odkazem na kartu. Kdybych nejdřív přečetl nasazený renderer a session log (důkaz, že model echovuje verbatim → chyba je v rendereru, ne v modelu/formátu), ušetřil bych celá kola deploy-test a autorovo zklamání. Nabízená „řešení" pak byly workaroundy, ne systémová oprava — autor je všechny zamítl jako „nesystémové".
+
+**How to apply:** U bug reportu: (1) lokalizuj a přečti reálný nasazený kód zodpovědný za chování; (2) seženi přímý důkaz, kde přesně se to láme (logy, session transcript, raw výstup) a vyluč nesprávné hypotézy (model vs renderer apod.); (3) až pak navrhuj fix — a měř ho proti příčině: pokud neopravuje příčinu, řekni to nahlas a označ za workaround. Doplňuje [[memory.md]] „než navrhneš řešení, nejdřív se podívej na reálný stav souborů na serveru".
+
+## feedback: skill nemá opakovat ani vysvětlovat to, co už je v system promptu
+
+Do `SKILL.md` (nanobotího skillu) nepatří konvence a fakta o prostředí, která už žijí
+v system promptu — `AGENTS.md` (nástroje, `uv`, temp soubory, exec guard, git) a `SOUL.md`
+(osobnost, styl výstupu, jazyk reasoningu). Skill popisuje **svůj vlastní postup**, ne to,
+jak se v tomhle prostředí obecně pracuje. Než něco takového do skillu napíšu, ověřit
+`grep` v `AGENTS.md`/`SOUL.md`, jestli to tam už není.
+
+**Why:** 2026-09-02 jsem při zkracování skillu `reflect` do STOP gate 1 *přidal* půlvětu
+vysvětlující, proč se `uv` volá plnou cestou („`uv` není v `PATH` v neinteraktivním SSH;
+uvnitř tahu stačí `uv run`"). Uživatel se zeptal, proč to tam vůbec je — `AGENTS.md` má
+celou sekci `## python — use uv`. Byla to dvojí chyba: environmentální meta-znalost ve
+skillu, a druhá polovina věty navíc doslova opakovala, co `AGENTS.md` agentovi říká.
+Zvlášť trapné v commitu, jehož cílem bylo skill **zkrátit**. Viz `history.md` 2026-09-02
+14:15.
+
+**How to apply:** Fakt o prostředí → `AGENTS.md`/`SOUL.md`. Vysvětlení „proč je ten příkaz
+takhle" pro člověka → `README.md` skillu (nenačítá se do kontextu, takže nestojí tokeny).
+Do `SKILL.md` jen to, co agent potřebuje k provedení **tohoto** postupu. A pozor na
+asymetrii: přidat do system promptu se vyplatí jen tehdy, když to agent reálně potřebuje —
+`PATH` gotcha se do `AGENTS.md` nakonec taky nepřidala, protože agentovi bare `uv run`
+funguje a týkala se jen člověka v SSH. Souvisí s [[memory.md]] „než navrhneš řešení,
+nejdřív se podívej na reálný stav souborů na serveru".
+
+## feedback: YAML seznamy — víc položek nebo dlouhé stringy jdou do block stylu
+
+Seznam s jedinou krátkou položkou zůstává flow (`include: ["*.md"]`, `paths: ["**"]`,
+`exclude: []`). Jakmile má **víc položek** nebo jsou položky **dlouhé stringy** (typicky
+cesty a globy), píše se **block stylem, každá položka na vlastním řádku**.
+
+**Why:** 2026-09-09 jsem v plánu `final-wiki-hybrid-rag` napsal `exclude` jako flow seznam
+zalomený přes dva řádky (`["**/node_modules/**", "**/vendor/**",` / `"**/.venv/**", …]`).
+Uživatel to vrátil: zalomený flow seznam je nejhorší z obou světů — nevejde se na řádek,
+nejde u položky mít komentář a diff jedné změněné položky přepíše celý blok.
+
+**How to apply:** Platí pro jakýkoli YAML, který píšu nebo který generuje kód (configy
+skillů, frontmatter, CI). Rozhoduj podle obsahu, ne podle délky výsledku: dva dlouhé globy
+jdou do block stylu, i kdyby se na jeden řádek vešly. Block styl navíc umožní komentář
+u konkrétní položky, což u whitelistů a excludů nese hodnotu. Souvisí s pravidlem
+v `CLAUDE.md`, že config je YAML právě kvůli komentářům.

keep.md

@@ -1 +1,3 @@
 - Chce mít filmy uložené lokálně na disku — streaming služby mění podmínky a dostupnost, chce mít obsah trvale k dispozici po zaplacení
+- Má předplatné: Netflix, HBO Max, SkyShowtime, Disney+
+- Skills (SKILL.md + skripty) vždy anglicky, pokud uživatel explicitně neřekne jinak

knowledge/models.md

@@ -7,44 +7,44 @@ trvalá změna defaultu = `agents.defaults.modelPreset` v `~/.nanobot/config.jso
 
 ## Nakonfigurované presety (`/model`)
 
-Zdroj: `~/.nanobot/config.json` → `model_presets`. Všechny mají `maxTokens = 16384`,
-`temperature = 0.1`, `provider = ollama`.
+Zdroj: `~/.nanobot/config.json` → `model_presets`. Všechny mají `maxTokens = 16384`
+a `temperature = 0.1`. Default je `glm`, fallback `kimi`.
 
-| Preset | Model id | Kontext | reasoningEffort |
-|---|---|---|---|
-| `glm` *(default)* | `glm-5.3-flash:cloud` | 976 000 | high |
-| `glm53` | `glm-5.3:cloud` | 976 000 | high |
-| `glm52` *(legacy)* | `glm-5.2:cloud` | 976 000 | high |
-| `glmi51` *(legacy)* | `glm-5.1:cloud` | 196 608 | — |
-| `kimi` | `kimi-k2.6:cloud` | 262 144 | — |
-| `kimi27` | `kimi-k2.7-code:cloud` | 262 144 | — |
-| `kimi3` | `kimi-k3:cloud` | 1 020 000 | — |
+| Preset | Provider | Model id | Kontext | reasoningEffort |
+|---|---|---|---|---|
+| `glm` *(default)* | ollama | `glm-5.3:cloud` | 976 000 | high |
+| `flash` | ollama | `glm-5.3-flash:cloud` | 976 000 | high |
+| `glm52` *(legacy)* | ollama | `glm-5.2:cloud` | 976 000 | high |
+| `glm51` *(legacy)* | ollama | `glm-5.1:cloud` | 196 608 | — |
+| `kimi` | ollama | `kimi-k2.7-code:cloud` | 262 144 | — |
+| `kimi26` | ollama | `kimi-k2.6:cloud` | 262 144 | — |
+| `kimi3` | ollama | `kimi-k3:cloud` | 1 020 000 | — |
+| `sonnet` | openrouter | `anthropic/claude-sonnet-4.6` | 256 000 | — |
+| `haiku` | openrouter | `anthropic/claude-haiku-4.5` | 200 000 | — |
+| `gemini-flash` | openrouter | `google/gemini-3.5-flash` | 256 000 | — |
+| `gemini-flash-lite` | openrouter | `google/gemini-3.1-flash-lite` | 256 000 | — |
 
-`glmi51` a `glm52` jsou legacní — jen pro regression srovnání, k práci nepoužívat.
+`glm51` a `glm52` jsou legacní — jen pro regression srovnání, k práci nepoužívat.
 `kimi3` nepoužívat (viz níž), zvaž odstranění presetu z configu.
 
 ---
 
-## Strategie modelů (potvrzeno uživatelem, 2026-02)
+## Strategie modelů (potvrzeno uživatelem, 2026-09)
 
 | Role | Model |
 |---|---|
-| **Daily driver** | `glm` — glm-5.3-flash |
-| **Těžké úlohy** | `glm53` — glm-5.3 |
-| **Kódování** | `kimi27` — kimi-k2.7-code (fallback: `kimi`) |
-| **Běžné agentní práce na Kimi** | `kimi` — kimi-k2.6 |
+| **Daily driver + těžké úlohy** | `glm` — glm-5.3 |
+| **Kódování** | `kimi` — kimi-k2.7-code |
+| **Běžné agentní práce na Kimi** | `kimi26` — kimi-k2.6 |
+| **Levnější/rychlejší + multimodální vstup** | `flash` — glm-5.3-flash |
 | **Nepoužívat** | `kimi3` — extra high usage, zasekávání v agentním modu (2026-02) |
 
-### Kdy přepnout na glm53 („těžká úloha")
+### Kdy sáhnout po `flash`
 
-- Multi-step research / deep-research skill (30+ iterací, cross-checking, dlouhé syntézy).
-- Multi-file refactor (5+ souborů, velký kontext).
-- Dlouhý debug / root-cause analýza přes víc systémů.
-- Wiki-compile s velkými vstupy (drain tisíců řádků).
-- Prompt injection / security analýza.
-
-Pravidlo: nejdřív `glm` (flash); když task „cuchne" (model ztrácí nit, opakuje tool
-call, potřebuje přes 100 iterací), restartuj na `glm53`.
+- **Multimodální vstup** — obrázek, screenshot, sken, video. `glm` (glm-5.3) je
+  **text-only**, flash je jediný GLM preset, co obrázky přijme (viz níž).
+- Levné rutinní tahy, kde nejde o maximální kvalitu a záleží na rychlosti
+  (TTFT ~0,4 s vs ~0,7 s).
 
 ### GLM-5.3 řada — srovnání (deep research, 2026-06)
 

memory/.cursor

@@ -1 +1 @@
-424
+430

memory/.dream_cursor

@@ -1 +1 @@
-424
+430

memory/MEMORY.md

@@ -21,6 +21,12 @@ This file stores important information that should persist across sessions.
 
 - Cross-channel session continuity via `unifiedSession: true`; backups: wood.hell → pivo.hell (recursive)
 
+## Wiki embeddings
+
+- Embeddings pro wiki běží přes ollama (`qwen3-embedding:0.6b`) na nvidia.hell
+- Migrace na static llama.cpp server (nvidia.hell:8081) zrušena: ollama a llama.cpp produkují fundamentálně odlišné vektory i na identickém inputu (cosine ~0.36); kvantizace, pooling, special tokens, BOS, chat templates a normalizace vyloučeny; reuse ollama GGUF blobu paritu nezajišťuje
+- Důsledek: přechod wiki embeddings na jiný engine vyžaduje plný reindex
+
 ---
 
 *This file is automatically updated by nanobot when important information should be remembered.*

memory/history.jsonl

@@ -422,3 +422,9 @@
 {"cursor": 422, "timestamp": "2026-08-25 20:06", "content": "- [durable] `uv` is unavailable and system Python lacks `croniter`; the remind skill CLI cannot be executed via `uv run` and requires direct SQLite database access.\n- [permanent] Safety guard enforces a hard working-directory boundary on shell commands; blocked commands must not be retried with symlinks, base64 piping, alternative tools, or working_dir overrides.\n- [ephemeral] Model preset for this session is `kimi-k2.6:cloud` with a 262144-token context window and 16384 max output tokens.", "session_key": "telegram:8826147089"}
 {"cursor": 423, "timestamp": "2026-08-28 13:26", "content": "- [ephemeral] User switched model preset to `kimi27` (`kimi-k2.7-code:cloud`) for the current session.", "session_key": "websocket:f6e1e265-7a37-451c-ad7a-f601c40fdc5a"}
 {"cursor": 424, "timestamp": "2026-08-31 09:17", "content": "- [skip] Background cron drain task: compiled 17 inbox files from notes/inbox/ into notes/notes.md (created new, 7 thematic sections), moved all sources to notes/done/\n- [skip] Per note SKILL.md, the notes/ store is separate from agent memory (keep/MEMORY.md) — Dream must not touch notes/, so the compiled note contents (chata shopping list, DT Glass product details, ZOT work items, 25.5 cm chair-to-table measurement, etc.) live only in notes/notes.md and are not mirrored here\n- [skip] Two DT Glass product URLs (UNIVERSAL and Amber wine-bottle glasses, 69 Kč) fetched successfully — details filed under \"## DT Glass\" section in notes/notes.md\n- [skip] notes/notes.md did not exist before this compile; it was created fresh with sections: DevOps/Infra, Nanobot, Chata, DT Glass, Měření, 3D tisk, Work/ZOT", "session_key": "note-compile"}
+{"cursor": 425, "timestamp": "2026-09-08 20:54", "content": "(nothing)", "session_key": "telegram:8826147089"}
+{"cursor": 426, "timestamp": "2026-09-14 08:33", "content": "- [ephemeral] Active plan: run qwen3-embedding:0.6b as a static llama.cpp server on nvidia.hell:8081 (instead of via ollama) to isolate wiki embeddings from ollama's unstable load path; parity test script prepared at tmp/embed-parity-test.py — embed same chunks via both endpoints, cosine > 0.999 → switch wiki/config.yaml endpoint without reindex\n- [durable] qwen3-embedding:0.6b GGUF can be reused from ollama blob store: /usr/share/ollama/.ollama/models/blobs/sha256-06507c7b42688469c4e7298b0a1e16deff06caf291cf0a5b278c308249c3e439 — copy to own path (e.g. ~/models/) before use, ollama pull can swap the blob\n- [durable] On nvidia.hell, `llama` binary v0.4.0-dev build 10909 installed via official `curl -LsSf https://llama.app/install.sh | sh` (llama.app is the official llama.cpp installer; GitHub nightly releases have NO Linux CUDA build, CUDA prebuilts exist only via llama.app on Linux)\n- [durable] Verified `llama serve` on nvidia.hell supports all required embedding flags: --embeddings, --pooling {none,mean,cls,last,rank}, -c/--ctx-size, -ngl; launch command: `llama serve -m ~/models/qwen3-embedding-0.6b.gguf --embeddings --pooling last -ngl 999 -c 1024 --host 0.0.0.0 --port 8081` (needs --host 0.0.0.0 so nanobot can reach it)\n- [correction] nanobot.hell is NOT a persistent load source on local ollama — the batch requests over ~10 models were one-time tool-calling tests; in normal operation nanobot uses local ollama only for (a) wiki embedding (qwen3-embedding:0.6b) and (b) :cloud model proxying — report todo #1 \"stop nanobot batches\" is not an operational risk\n- [durable] Ollama on nvidia.hell root cause (from two saved Claude Code reports, artifacts in projects/devops/artifacts/): broken mmap decision + load interruption leaks pinned host memory (only reboot frees it, not rmmod); verified mitigation is cgroup limit MemoryMax=6G + MemorySwapMax=0 (no MemoryHigh); earlyoom rejected — external killer makes the leak worse\n- [durable] Embedding models need KV buffer sized only for max input length (-c 1024 suffices for wiki chunks); llama.cpp default reads full context from model metadata and over-allocates for embedding use\n- [skip] User will confirm when the llama.cpp server is running so the agent can run the parity test; exact HF repo name for Qwen3-Embedding GGUF not confirmed from memory", "session_key": "websocket:0d81522a-4774-490a-a2c3-10d72dcd4680"}
+{"cursor": 427, "timestamp": "2026-09-14 08:42", "content": "- [durable] Ollama vs llama.cpp embedding parity test for qwen3-embedding:0.6b (GGUF blob sha256-06507c7b...) failed — cosine only 0.87–0.93, not >0.999. Special tokens (EOS 151643, `</s>` 128247), BOS, chat templates (`<|im_start|>`), query prefixes, and normalization were all systematically ruled out. Main hypothesis: ollama uses mean pooling while llama.cpp server runs `--pooling last`; next step is restarting llama server with `--pooling mean` and re-running the parity test.\n- [durable] Model oddity: the GGUF blob has `</s>` at token 128247 flagged as \"control-looking token, probably a bug in the model\"; llama.cpp auto-appends Qwen EOS 151643 on tokenize (add_special=true).\n- [durable] llama.cpp server per-request `pooling` field in `/embedding` payload is ignored — server-level `--pooling` flag wins.\n- [durable] Workspace pitfall: `tmp/queue.py` in the nanobot workspace shadows Python stdlib `queue` module (breaks urllib3 imports in uv scripts); run test scripts from a separate subdirectory like `tmp/embed-test/` instead.\n- [durable] llama.cpp `/v1/embeddings` response shape: top-level is a list of items with keys `['index', 'embedding']` (OpenAI-style), not `{\"embedding\": ...}`.\n- [durable] Environment: ollama at http://nvidia.hell:11434 (qwen3-embedding:0.6b), llama.cpp server at http://nvidia.hell:8081; llama server run with `--embeddings --pooling last -ngl 999 -c 1024 --host 0.0.0.0 --port 8081`, n_slots=4.\n- [permanent] User preference: do not switch the wiki embedding pipeline from ollama to llama.cpp without resolving the parity issue (decision: \"NEPREPINAT bez reseni\").", "session_key": "websocket:0d81522a-4774-490a-a2c3-10d72dcd4680"}
+{"cursor": 428, "timestamp": "2026-09-14 08:44", "content": "- [durable] llama.cpp server and ollama produce fundamentally different embeddings for `qwen3-embedding:0.6b` even on identical single-token input (`cat` → cosine 0.36); parity by reusing the ollama blob is not achievable — the forward pass itself yields different vectors.\n- [durable] Both engines read the same blob `sha256-06507c7b…` (Q8_0, `general.file_type=7`, `pooling_type=3`), so quantization was ruled out as the cause; suspected different GGUF build/tokenizer handling in ollama's vendored llama.cpp.\n- [durable] `tmp/queue.py` in the nanobot workspace shadows the stdlib `queue` module and breaks Python scripts importing `requests`/`urllib3` — run scripts from a subdirectory (e.g. `tmp/embed-test/`) instead.\n- [durable] ollama 0.34.0 at `nvidia.hell:11434` has no `/api/tokenize` endpoint; `/api/embed` options `raw`, `truncate`, `num_ctx` (512/1024/8192) have zero effect on output vectors.\n- [durable] llama.cpp server is fully deterministic (5× same input → cosine 1.000000) and `--pooling last` is the best-fitting pooling for qwen3-embedding (mean pooling measured worse: 0.50–0.71 vs 0.87–0.93 cosine).\n- [durable] Reference: GitHub issue ollama/ollama#14121 documents the same qwen3-embedding mismatch; note llama-cpp-python `n_batch=512` chunk-splitting corrupts embeddings for inputs >512 tokens (not the cause here, inputs were ~79 tokens).\n- [ephemeral] Decision pending: three paths offered for the wiki embedding index — (1) pull the same GGUF directly in llama.cpp and retest parity, (2) reindex wiki with llama.cpp server (port 8081, `--pooling last`) as the new source of truth (assistant's recommendation), (3) stay on ollama for embeddings (loses the goal of isolating embeddings from ollama's load-path instability). User has not yet chosen.\n- [skip] Context: this debugging is part of an ongoing embed-parity test effort to migrate embeddings away from ollama's unstable load path.", "session_key": "websocket:0d81522a-4774-490a-a2c3-10d72dcd4680"}
+{"cursor": 429, "timestamp": "2026-09-14 21:21", "content": "- [permanent] User communicates in Czech.\n- [skip] User has noted recipes for Karak (Middle Eastern milk tea) and Teh Tarik (Malaysian pulled tea) in their `caj/` directory.\n- [skip] Karak recipe serves 2 cups; ingredient amounts for ginger, cardamom, black tea, and cane sugar are unspecified and marked for future refinement.\n- [skip] Teh Tarik recipe serves 2; uses 700–800 ml water, 2 tbsp tea (steep 6 min), 2 tbsp condensed milk + 2 tbsp condensed milk/coffee creamer.\n- [skip] User's `recepty/` directory is currently empty.", "session_key": "telegram:8826147089"}
+{"cursor": 430, "timestamp": "2026-09-15 03:33", "content": "- [durable] The exec deny-pattern filter blocks `rm -rf`, `rm -r`, wildcard and multi-file `rm` in tmp/ — the working cleanup shape is an explicitly enumerated `rm` of individual files followed by `rmdir`; proposed an AGENTS.md patch documenting this\n- [durable] The exec safety guard blocks `curl` to `nvidia.hell:11434` as \"internal/private URL detected\"; workaround is writing a uv Python script (requests.post) to tmp/ and running it — block was routed around without diagnosis, flagged as recurring pattern\n- [correction] User corrected store routing: project-scoped decisions (e.g. the llama.cpp reindex decision) belong in `projects/<name>/memory.md`, not `keep.md` — keep.md is only for global user facts; entry was reverted and re-filed into projects/devops\n- [durable] llama.cpp stable releases (v0.4.0) ship no Linux CUDA binaries — prebuilt CUDA builds are distributed via the official installer `curl -LsSf https://llama.app/install.sh | sh` (llama.app, probing CUDA first on Linux)\n- [durable] Embedding parity between ollama and llama.cpp is unachievable for qwen3-embedding:0.6b even with the same GGUF blob — 1-token test gives cosine 0.36, not explainable by pooling, special tokens, or quantization; user decision: switching to pure llama.cpp requires a full reindex of the wiki base\n- [durable] `tmp/queue.py` in the workspace shadows stdlib `queue` — Python test scripts run from tmp/ fail on import; workaround is running them from a tmp subdirectory (e.g. tmp/embed-test/)\n- [durable] Typo \"pozlatejšího\" (instead of \"pozdějšího\") persists in the `projects/ai/state.md` section heading — the verification read targeted the wrong lines and the fix was claimed but never applied\n- [ephemeral] User preference during the embed migration: refuses to copy the ollama GGUF blob to a separate path (\"nic nikam kopirovat nebudu, llama to menit nebude\") — serve directly from the ollama blob store\n- [durable] The safety guard blocked `web_fetch` with \"repeated external lookup blocked\" on a URL already fetched — reuse existing results instead of re-fetching", "session_key": "reflect:20260915-033001-0"}

notes/done/2026-09-04_21_13_39_879355-chci-si-stahnout-film.md

@@ -0,0 +1,5 @@
+---
+captured_at: 2026-09-04T21:13:39+02:00
+---
+
+Chci si stáhnout film Wrath of Man (2021, Guy Ritchie, Jason Statham) — ostraha obrněného vozu, pomsta za zavražděného syna.

notes/done/2026-09-08_08_54_08_712006-clanek-don-t-chat-with.md

@@ -0,0 +1,6 @@
+---
+captured_at: 2026-09-08T08:54:08+02:00
+channel: webui
+---
+
+Článek 'Don't Chat With Your AI. Mob With It.' (David Rodenas, Medium): instrukce pro AI agenta psát jako tagy přímo do souborů místo chatu ([[CLAUDE: ...]] instrukce, [[DAVID: ...]] odpověď agenta). Autor tvrdí, že tím řeší latenci agent loopu přes paralelizaci (mob programming analogie). Diagnóza s Claude: latenční argument je špatný (nejde o GPU sloty, ale round-trip a sériovost kroků; je to fronta, ne zrychlení), mob analogie obrácená, a mazání tagů po provedení ničí kontrolní bod. Použitelné jádro: anotace patří tam, kde je předmět anotace — pozice v souboru je kontext (jako TODO komentář), přežije session, vidět v diffu. S tím, že se agent nechá běžet ve smyčce autonomně a tag se nemaže, jen připíše odpověď, a max 1-2 tagy na kolo. Detailní rozbor: projects/ai/artifacts/file-based-agent-communication.md

notes/done/2026-09-11_13_51_11_210550-sdr-zdroje.md

@@ -0,0 +1,10 @@
+---
+captured_at: 2026-09-11T13:51:11+02:00
+channel: telegram
+chat_id: "8826147089"
+---
+
+SDR zdroje:
+https://gnuradioworld.com — GNU Radio World: flowgraph editor a runtime GNU Radio přímo v prohlížeči (WebAssembly, bez instalace, bez serveru). Čte a zapisuje nativní .grc soubory, obsahuje ukázkové flowgraphy a IQ nahrávky, přes WebUSB podporuje RTL-SDR, PlutoSDR a HackRF (source i sink). Autoři: 777arc (Marc Lichtman) na GitHubu.
+https://pysdr.org — PySDR: bezplatná online učebnice SDR a DSP v Pythonu od Dr. Marca Lichtmana. FFT, filtry, IQ sampling, digitální modulace, synchronizace, multipath fading; kapitoly pro PlutoSDR a další SDR v Pythonu. Open source na GitHubu 777arc/PySDR. Od srpna 2026 obsahuje ukázkové GNU Radio flowgraphy spustitelné přes GNU Radio World (desítky ukázkových signálů).
+Kontext: SDR zajímá uživatele — má HackRF One a RTL-SDR.

notes/done/2026-09-14_10_19_30_263437-kombinace-duckdb-apache.md

@@ -0,0 +1,15 @@
+---
+captured_at: 2026-09-14T10:19:30+02:00
+---
+
+Kombinace DuckDB + Apache Iceberg + dbt vypadá zajímavě. Vytáhni z článku a případně online zajímavé informace a ulož je, hlavně pro jaký usecase je tato kombinace užitečná. Není třeba ukládat celý článek.
+
+Klíčové body z článku (DuckDB Just Put a $400K/Year Skill on Your Laptop, DataExpert, Medium, 2026-09-03):
+- DuckDB v1.5.3 (květen 2026): plná podpora zápisu do Iceberg tabulek (MERGE INTO, ALTER TABLE, partition transforms, Iceberg V3). Dřív jen čtení — teď i správa tabulek lokálně, bez Spark clusteru.
+- Apache Iceberg: enterprise standard, Apache Polaris (volný self-hostable REST catalog) graduoval na top-level Apache projekt (únor 2026).
+- dbt Core: Apache 2.0, bez seat limitů, baseline skill v data engineeringu; dbt-duckdb adapter — SQL/modely identické lokálně i na produktion (Snowflake/BigQuery), jen se mění target.
+- DuckLake (duben 2026, v1.0): lakehouse formát s metadaty v SQL databázi (SQLite/Postgres/DuckDB) místo metadata souborů v object storage. Řeší catalog problem i small-file problem (data inlining).
+- Use case: celý enterprise lakehouse skill stack (incremental loading, SCD Type 2, partition pruning, schema evolution, data quality, compaction) se dá naučit a prototypovat na laptopu za $0, místo placeného Snowflake/Databricks compute.
+- Benchmarky z článku: FinQore 8h pipeline → 8 min na DuckDB (60x); dashboard dotazy 200–400ms vs 2–5s Snowflake X-Small; MotherDuck: 6–7x rychlejší než ekvivalentně ceněné Snowflake/Redshift pro 10–100GB data.
+- Omezení: DuckDB 1 writer (concurrency), Iceberg+Parquet 2–3x pomalejší než nativní DuckDB formát, small-file/manifest explosion se na laptopu neprojeví (data moc malá) — production problémy se naučí až na produkci.
+- AWS acquirenul DuckLabs (tým za DuckDB) v srpnu 2026; projekt zůstává MIT pod DuckDB Foundation.

notes/notes.md

@@ -52,6 +52,7 @@
 - Komunikace v češtině
 - Informace hledej nejenom ve zdrojovém kódu, ale i v dokumentaci online
 - Pokud si nejsi jistý, ptej se
+- Článek „Don't Chat With Your AI. Mob With It." (David Rodenas, Medium): instrukce pro AI agenta psát jako tagy přímo do souborů místo chatu (`[[CLAUDE: …]]` instrukce, `[[DAVID: …]]` odpověď agenta), pravidlo v CLAUDE.md. Článek argumentuje špatně (latence nejsou GPU sloty, ale round-trip a sériovost kroků; „zrychlení" je ve skutečnosti fronta), ale jádro drží: anotace patří tam, kde je předmět anotace — pozice v souboru je kontext (jako TODO komentář), přežije session, je vidět v diffu. Korekce oproti článku: agent tag nemaže, jen připíše odpověď (mazání jen člověk před commitem), agent neběží autonomně ve smyčce (explicitní „projdi tagy"), max 1–2 tagy na kolo. Detailní rozbor: projects/ai/artifacts/file-based-agent-communication.md
 
 ## Work 
 
@@ -76,6 +77,7 @@
 ## Filmy ke stažení / potřebuju vlastnit
 
 - *The Beekeeper* (2024) — akční thriller, Jason Statham v hlavní roli; vítězství pomsty bývalého agenta tajné organizace "Beekeepers"
+- *Wrath of Man* (2021) — Guy Ritchie, Jason Statham jako ostraha obrněného vozu na převážení peněz; ve skutečnosti sleduje bandu, která při přepadení zabila jeho syna, a mstí se
 
 ## Viděl jsem
 
@@ -103,3 +105,11 @@
   - broušení
   - spojování vruty
   - lepení
+
+## SDR / radio
+
+- GNU Radio World — https://gnuradioworld.com · https://github.com/777arc/gnuradio-world
+  Flowgraph editor a runtime GNU Radio přímo v prohlížeči: GNU Radio DSP stack a Qt GUI sinks zkompilované do WebAssembly, bez instalace a bez serveru. Čte a zapisuje nativní `.grc` soubory, obsahuje ukázkové flowgraphy a IQ nahrávky. Přes WebUSB podporuje RTL-SDR, PlutoSDR a HackRF (source i sink). GitHub: 777arc/gnuradio-world.
+- PySDR — https://pysdr.org
+  Bezplatná online učebnice SDR a DSP v Pythonu od Dr. Marca Lichtmana (pysdr@vt.edu). FFT, filtry, IQ sampling, digitální modulace, synchronizace, multipath fading; kapitoly pro PlutoSDR a další SDR v Pythonu. Open source: GitHub 777arc/PySDR. Od srpna 2026 obsahuje ukázkové GNU Radio flowgraphy spustitelné přímo přes GNU Radio World (desítky ukázkových signálů).
+- Kontext: SDR zajímá — doma je HackRF One a RTL-SDR (+ další).

plans/2026-09-02_reflect-review-findings.md

@@ -0,0 +1,133 @@
+# Reflect skill — review 2026-09-02
+
+Stav: nálezy review, opravy navrženy, čekají na schválení implementace
+Datum: 2026-09-02
+
+Review prošlo celý skill: SKILL.md, README.md, `reflect_apply.py`, `reflect_auto.py`,
+`reflect_distill.py` a všech 168 testů (prošly, 1.1 s). Celkový verdikt: nadprůměrně
+dobře napsaný — „záruky v kódu, ne v promptu" je proveden důsledně, testy kódují
+racionalu u každého assertu. Níže jsou problémy v pořadí závažnosti + návrh opravy
+u každého.
+
+## 1. Fold přeloženého open nálezu zahodí drafted patch a skip count (bug)
+
+`merge_findings` (reflect_auto.py ~522) dědí `regression_of` a `history`, ale ne
+`patch`, `patch_drafted_at` ani `skipped`. Jakmile noční běh znovu spatří stejný
+`open` pattern, `supersede` starý záznam zahodí a nový vzniká bez těchto polí.
+
+Následky:
+
+- patch složený při review přes `--set-patch` (agent ho pracně ověřil proti
+  souboru) zmizí; SKILL.md krok 2 tvrdí „`patch_drafted_at` says an earlier
+  review drafted it" — po jedné noci to neplatí
+- „deferred 2× already" z kroku 3 se vynuluje — nález se předkládá donebezedne
+  bez viditelné historie odkladů, i když ho uživatel už několikrát odložil
+- audit log (`DRAFTED`, `SKIPPED`) ukazuje práci, na kterou store už neodkazuje
+
+**Fix:** v `merge_findings` při foldu open/watch předchozího záznamu přenést:
+
+```python
+if previous and previous["status"] == STATUS_OPEN:
+    if previous.get("patch") and not item.get("patch"):
+        # drafted during a review, verified against the file — do not throw it away
+        patch = previous["patch"]          # do Finding(...)
+        patch_drafted_at = previous.get("patch_drafted_at")
+    skipped = previous.get("skipped")      # deferral history survives the fold
+```
+
+Pole `patch_drafted_at` a `skipped` je potřeba přidat do `Finding` dataclass a
+`to_json()` (podmíněně jako ostatní volitelná pole). Nový patch z analýzy má
+přednost před starým draftem; jinak se drží draft z review. Testy: fold open
+nálezu s `skipped={count:2}` a drafted patchem → nový záznam obojí nese;
+nový patch z modelu draft nepřepisuje, ale nahrazuje.
+
+## 2. `reflect_apply.py` nechrání vlastní store jako cíl patche (designová mezera)
+
+`_resolve_target` odmítne cestu mimo workspace, ale klidně aplikuje patch na
+`reflect/findings.jsonl`, `reflect/state.json` nebo `log/reflect.log`. Celá
+filozofie skillu je „do audit trail píše jen reflect_apply" — ale reflect_apply
+sám může patchem přepsat audit trail (typicky změnit `rejected` záznam zpět na
+`open`, což oživí zamítnutý vzor). Stane se to „se schválením uživatele", které
+v diffu snadno přehlédne, že jde o store.
+
+**Fix:** explicitní blocklist v `check_patch` / `_resolve_target`
+(reflect_apply.py):
+
+```python
+PROTECTED = ("reflect/", "log/reflect.log")
+
+def _resolve_target(workspace, relative):
+    target = (workspace / relative).resolve()
+    if not target.is_relative_to(workspace.resolve()):
+        raise ApplyError(f"{relative} resolves outside the workspace")
+    if target == (workspace / FINDINGS_REL).resolve() or \
+       any(target.is_relative_to(workspace / prefix) for prefix in PROTECTED):
+        raise ApplyError(f"{relative} is part of the reflect store — not a patch target")
+    ...
+```
+
+Důvod zdůvodnit v chybové hlášce („the audit trail is never a patch target").
+Pozn.: `set_patch` tím kryje i draft, nejen apply. Test: patch s
+`file: reflect/findings.jsonl` → exit 2, store netčen.
+
+## 3. Vakuózní assert v testu (test_reflect_auto.py)
+
+`test_first_run_has_no_trend_to_show` tvrdí `"(minule" not in report`, ale
+`_rate_line` generuje anglické „(previous run …)". Assert nikdy nemůže selhat,
+test tedy nic nehlídá.
+
+**Fix:** `assert "(previous" not in report`. Jednořádková změna.
+
+## 4. Noise prefix `"cli"` chytá i `client*` (případné falešné vyřazení)
+
+`key.startswith(NOISE_PREFIXES)` — session `client_xyz` (nebo cokoli začínající
+„cli") se tiše vyřadí z analýzy. Prefix-match na krátkých prefixech je
+přístřelen. Podobně base64 session jména obsahující `-`/`_` (jsou v urlsafe
+abecedě) se nedekódují kvůli heuristice `"_" in stem or "-" in stem` —
+legitimní stará session se pak chytne prefixem, nebo naopak neprojde.
+
+**Fix:** noise match na hranici klíče: session klíče mají tvar
+`<prefix>_<rest>` resp. base64 bez `_`, takže matchovat
+`key == prefix or key.startswith(prefix + "_")`. Případně (jednodušeji)
+přejmenovat prefix na `cli_` v NOISE_PREFIXES, protože reálné machinery session
+jsou `cli_<…>`. Test: `client_abc` prochází, `cli_kimi-ollama-test` ne.
+
+## Menší
+
+### 5. Git fingerprint se nekontroluje při LLM error cestě
+
+`_resolve_findings`: fingerprint se porovná jen po úspěšném tahu. Když tah
+skončí LLM errorem a agent v tu chvíli něco zapsal, guard se neprojeví a
+run pokračuje. Riziko je teoretické (error odpověď znamená, že k zápisu
+s nejvyšší pravděpodobností nedošlo), ale guard je zadarmadlo dokončit.
+
+**Fix:** porovnat fingerprint i na začátku error větve
+(`if result.stop_reason == "error" or result.error:`) — stejná kontrola,
+stejná hláška.
+
+### 6. `MIN_MESSAGES=5` počítá i tool výsledky
+
+`distill_session` inkrementuje `message_count` pro user, assistant i tool
+role. Session s 1 user zprávou a 2 tool cally (celkem 5 záznamů) projde
+prahem, přestože je to jeden dotaz — nižší signál, ne rovnou chyba.
+
+**Fix (volitelné):** počítat jen user + assistant zprávy
+(`message_count += 1` jen v těch dvou větvích). Tool results počítat jako
+součást tahu, ne jako zprávu. Existující testy `message_count == 6` adaptovat.
+
+### 7. Neatomičnost mezi `git commit` patche a `_save(findings)`
+
+Crash mezi commitem patche a zápisem store zanechá soubor patched, ale store
+`open` (bez audit linky). Re-apply se správně odmítne na chybějícím `old_text`,
+ale audit stopa pro ten commit chybí. U single-user workspace akceptovatelné;
+zmiňuju pro úplnost. Plná atomicita (např. save-first-then-commit s rollbackem
+store) nedoporučuju — přidá složitost pro okrajový scénář. Spíš uvážit
+pořadí: nejdřív `_save` + audit, pak commit; pak crash zanechá `applied`
+záznam bez commitu, což reflektuje hlášku `git revert` — ale zase commit
+refusu zanechá store applied bez commitu. Trade-off, nechává rozhodnutí
+na implementaci.
+
+## Pořadí implementace
+
+1 → 2 → 3 → 5 → 4 → (6, 7 volitelné). Položky 1–3 jsou přímé rozpory se
+zárukami deklarovanými v README („Záruky"), 5 a 4 jsou levné tvrdnutí guardů.

plans/cook-skill-design.md

@@ -0,0 +1,70 @@
+# Cook skill — final design
+
+## Context
+
+User wants a personal store for recipes and tea notes (origins, brewing
+parameters, tasting). Wiki/note rejected as too heavy. Agreed design:
+`cook/` data dir + thin `skills/cook/` skill manifest + a small safety
+script. This plan finalizes the design agreed question-by-question in chat
+(2026-09-08) and supersedes the quick-draft SKILL.md already written.
+
+## Decisions (locked with user)
+
+1. **Script, not raw file tools** — `cook.py` guards against accidental
+   overwrite/delete; frontmatter always machine-generated (no drift).
+   Keep it **minimal — shortest working code, no speculative features**.
+2. **Frontmatter** (free-form values, only `type` is fixed):
+   `type: recept|caj`, `category`, `cuisine` (recepts only),
+   `origin` (caj only), `tags` (user hashtags, no `#`), `added` (auto date).
+   Can be lightened later.
+3. **Hashtags live in frontmatter `tags`**, not in body.
+4. **Search via script**: frontmatter filtering + fulltext body grep.
+   Start simple; enrich later.
+5. **Slug collision**: `add` on existing slug → error; agent shows the
+   existing item, user decides edit vs. new slug. No auto `-2` suffixes.
+6. **Assets**: `cook/assets/<slug>/` when documents/photos ever arrive;
+   not created upfront.
+
+## Steps
+
+1. Rewrite `skills/cook/SKILL.md` to the final design:
+   - layout (`cook/recepty/`, `cook/caj/`, `cook/assets/` — created on demand)
+   - all file mutations via `cook.py` subcommands; agent never `write_file`s
+     into `cook/` directly except body edits via `edit_file`/`apply_patch`
+     after `add` creates the skeleton
+   - capture inline (same turn), commit after each change
+     (`git add cook/ && git commit -m "cook: ..."`; never `git add -A`)
+   - search/answer flow: `list`/`search` to narrow, then read files, answer
+     from files only, no confabulation
+   - edit/delete: two-turn confirm flow (show exact text → user confirms →
+     apply → commit)
+   - slug conventions: kebab-case; collision handling per decision 5
+2. Write `skills/cook/scripts/cook.py` — minimal (~150 lines), stdlib only:
+   - `add <slug> --type recept|caj [--category C] [--cuisine C] [--origin O]
+     [--tags a,b] [--body-file F]` → creates file with frontmatter;
+     **exit 1 if slug exists**; reads body from stdin or `--body-file`
+   - `edit <slug>` → prints file path; **exit 1 if missing** (no silent
+     create); actual text edits done by agent with `edit_file` on the path
+   - `list [--type T] [--category C] [--tag X]` → one line per item:
+     `slug  type  category  added  title`
+   - `show <slug>` → full file content
+   - `search <text>` → fulltext grep across bodies, prints matching lines
+     with slug context
+   - `rename <old> <new>` → moves file (+ its assets dir if present);
+     exit 1 if target exists
+   - `delete <slug>` → removes file (and empty assets dir); only run
+     after user confirmation per SKILL.md flow
+   - `validate` → checks every file has parseable frontmatter and `type`
+   - Frontmatter: minimal hand-rolled parse (no external deps).
+3. Test drive: `add` a sample recipe + sample tea, verify frontmatter,
+   `list`, `search`, collision error, `validate`, then delete samples and
+   commit the real state.
+
+## Verification
+
+- `cook.py add` twice on same slug → second exits 1
+- `edit`/`show`/`rename`/`delete` on missing slug → exit 1
+- `list --tag chata` filters on frontmatter tags
+- `search <word>` finds body text
+- `validate` passes on script-created files, fails on a hand-mangled one
+- SKILL.md contains no leftover pipeline cruft (inbox/compile/lock)

plans/final-wiki-hybrid-rag.md

@@ -0,0 +1,493 @@
+# Final Wiki — hybrid RAG index nad poznámkami
+
+**Stav:** připraveno k implementaci. **Vznik:** 2026-09-09.
+**Nahrazuje** draft `notes-search-hybrid-rag.md` (server, 2026-09-09) — ten je superseded.
+
+Veškerá čísla v tomto dokumentu jsou **naměřená na reálném prostředí**
+(`nanobot.hell` → `nvidia.hell`, 2026-09-09), ne odhadnutá. Kde jde o odhad, je to napsané.
+
+## Cíl
+
+Uživatel vede poznámky ve vlastních git repozitářích (adresářová struktura, md soubory; témata
+devops, traveling, mix). Nanobot dostane **read-only přístup** k mirrorům těchto repů a postaví
+nad nimi index pro rychlé hledání — tematické i syntaktické. Druhým zdrojem je **nanobot
+workspace** (živá data).
+
+Poznámky zůstávají kanonickými daty v gitu; **index je derived artifact, regenerovatelný**.
+Do uživatelových repů se nikdy nezapisuje.
+
+Skill je **plně samostatný** — žádná závislost na jiném nanobot skillu.
+
+## Ověřená fakta o prostředí
+
+| Co | Naměřeno |
+|---|---|
+| Ollama endpoint `http://nvidia.hell:11434` | dosažitelný z nanobota |
+| `qwen3-embedding:0.6b` | nainstalován; 595,78M params, **1024 dims**, capability `embedding` |
+| Cold load modelu / warm | **1,81 s** / **0,043 s** |
+| Embed throughput | 8,9 chunk/s po jednom → **108 chunk/s** v batchi 32 (12×) |
+| `keep_alive` tvar | číslo `-1` i `"24h"` → 200; **string `"-1"` → HTTP 400** |
+| Ollama **Cloud** embeddingy | **neexistují** — 18 cloud modelů, žádný s capability `embedding`; `/api/embed` na cloud modelu vrací `unauthorized`, zatímco `/api/generate` na tomtéž projde |
+| SQLite | 3.46.1; FTS5 `unicode61`/`trigram`/`porter`; **`enable_load_extension` funguje** |
+| `sqlite-vec` | **v0.1.6**, `vec0(float[1024] distance_metric=cosine)` v témže souboru jako `chunks`+FTS5 |
+| `vec0` KNN k=20 | **19 ms @ 10k** chunků, **212 ms @ 100k** (BLOB+numpy: 594 ms) |
+| `vec0` zápis | 10k = 2,1 s; 100k = 25,3 s; soubor 466 MB (BLOB 461 MB — bez režie) |
+| `vec0` mutace | `DELETE`/re-`INSERT`/`UPDATE` po `rowid` **fungují**; `ROLLBACK` je transakční |
+| BLOB+numpy rozpad @ 100k | read 382 ms + pack 190 ms + **dot 22 ms** → 96 % je Python režie |
+| FTS5 čeština | `remove_diacritics 1`+ foldí (`zaloha` najde `záloha`); `záloh*` najde *záloha/zálohování/zálohy* |
+| Reálný korpus workspace | 234 md mimo `tmp/` (1,28 MB) → **~800 chunků**; z toho použitelných ~99 souborů |
+| `exec` tool timeout | **60 s** |
+| `db/` ve workspace | gitignorováno → index je automaticky mimo git |
+
+**Retrieval kvalita — měřeno na 178 chunkách reálného obsahu:**
+
+| Dotaz | BM25 | embeddingy |
+|---|---|---|
+| „prodloužení životnosti LEGO" | 4/5 | **5/5** |
+| „jak snížit elektroodpad ze stavebnic" | **1/5** | **3/5** |
+
+Druhý řádek je přesně ten parafrázový/cross-jazyk případ, pro který tu hybrid je: BM25 selže,
+vektory najdou. První řádek je opačný — lexikálně snadný dotaz zvládne BM25. **Obě poloviny
+si vydělávají**, což potvrzuje D1 měřením, ne argumentem.
+
+## Architektura
+
+Klíčová vlastnost: **`chunks` je jediná retrieval jednotka.** RRF slučuje dva ranky *téže*
+množiny — kdyby BM25 řadil soubory a vektory chunky, merge by neměl definovaný význam.
+
+```
+Zdroje:
+  git mirrory (RO clone/fetch, keyed na indexed-rev)
+  nanobot workspace (walk path+size+mtime)
+    ↓ ingest driver (git-diff / fs-scan — dva drivery, jeden indexer)
+    ↓ chunker (md → chunky po heading struktuře, markdown-it-py)
+    ↓ embeddings: Ollama /api/embed (qwen3-embedding:0.6b), batch 32, jen změněné chunky
+    ↓
+  db/notes-index.sqlite:
+
+    chunks  (kanonické: metadata + text + stav embeddingu)
+      ├── chunks_fts    FTS5 external-content  → BM25 rank nad chunks.id
+      └── vec_chunks    vec0 virtual table     → KNN rank nad chunks.id (rowid = chunks.id)
+                                                    ↓
+                                              RRF merge nad chunks.id
+```
+
+Tenhle tvar drží `vec0` **vyměnitelné**: kdyby pre-v1 breaking change zabolel, přidá se
+`embedding BLOB` zpět do `chunks` a nic jiného se nemění.
+
+### Schéma
+
+```sql
+CREATE TABLE IF NOT EXISTS meta (key TEXT PRIMARY KEY, value TEXT NOT NULL);
+-- embedding_model, embedding_dims, normalized, query_prefix,
+-- chunker_version, schema_version, sqlite_vec_version
+
+CREATE TABLE IF NOT EXISTS sources (
+  source_id    TEXT PRIMARY KEY,               -- klíč z YAML, stabilní
+  kind         TEXT NOT NULL CHECK(kind IN ('git','workspace')),
+  indexed_rev  TEXT,                           -- jen git driver
+  last_sync_at TEXT
+);
+
+CREATE TABLE IF NOT EXISTS files (
+  source_id  TEXT NOT NULL REFERENCES sources(source_id),
+  path       TEXT NOT NULL,                    -- relativní ke zdroji
+  title      TEXT, tags TEXT, headings TEXT,   -- tags/headings jako JSON array
+  sha256     TEXT NOT NULL,
+  size       INTEGER NOT NULL,
+  mtime      REAL,                             -- rychlý pre-filter workspace driveru
+  indexed_at TEXT NOT NULL,
+  PRIMARY KEY (source_id, path)
+);
+
+CREATE TABLE IF NOT EXISTS chunks (
+  id          INTEGER PRIMARY KEY AUTOINCREMENT,
+  source_id   TEXT NOT NULL,
+  path        TEXT NOT NULL,
+  chunk_idx   INTEGER NOT NULL,
+  breadcrumb  TEXT NOT NULL,                   -- "soubor > sekce > podsekce"
+  text        TEXT NOT NULL,
+  embedded_at TEXT,                            -- NULL = čeká na vektor (degradovaný režim)
+  UNIQUE (source_id, path, chunk_idx),
+  FOREIGN KEY (source_id, path) REFERENCES files(source_id, path) ON DELETE CASCADE
+);
+CREATE INDEX IF NOT EXISTS idx_chunks_pending ON chunks(id) WHERE embedded_at IS NULL;
+
+CREATE VIRTUAL TABLE IF NOT EXISTS chunks_fts USING fts5(
+  breadcrumb, text,
+  content='chunks', content_rowid='id',
+  tokenize='unicode61 remove_diacritics 2'
+);
+
+CREATE TRIGGER IF NOT EXISTS chunks_ai AFTER INSERT ON chunks BEGIN
+  INSERT INTO chunks_fts(rowid, breadcrumb, text) VALUES (new.id, new.breadcrumb, new.text);
+END;
+CREATE TRIGGER IF NOT EXISTS chunks_ad AFTER DELETE ON chunks BEGIN
+  INSERT INTO chunks_fts(chunks_fts, rowid, breadcrumb, text)
+    VALUES('delete', old.id, old.breadcrumb, old.text);
+END;
+CREATE TRIGGER IF NOT EXISTS chunks_au AFTER UPDATE ON chunks BEGIN
+  INSERT INTO chunks_fts(chunks_fts, rowid, breadcrumb, text)
+    VALUES('delete', old.id, old.breadcrumb, old.text);
+  INSERT INTO chunks_fts(rowid, breadcrumb, text) VALUES (new.id, new.breadcrumb, new.text);
+END;
+
+CREATE VIRTUAL TABLE IF NOT EXISTS vec_chunks USING vec0(
+  embedding float[1024] distance_metric=cosine
+);
+```
+
+Poznámky ke schématu, všechny ověřené smoke testem:
+
+- **Klíč je `(source_id, path, chunk_idx)`**, nikdy jen `path` — `DELETE WHERE path = ?` by
+  mazalo chunky cizího zdroje.
+- **Stav embeddingu je sloupec `chunks.embedded_at`**, ne absence řádku ve `vec_chunks`.
+  U `vec0` se „chybějící vektor" dotazuje blbě, a degradovaný režim potřebuje levný
+  `WHERE embedded_at IS NULL` (proto ten partial index).
+- **PAST: `ON DELETE CASCADE` uklidí `chunks` i `chunks_fts` (trigger se na kaskádě spustí),
+  ale řádek ve `vec_chunks` osiří** — `vec0` není cílem foreign key. Indexer **musí** mazat
+  `vec_chunks` explicitně. Patří to do regresního testu.
+- Vektory se ukládají **L2-normalizované** (`meta.normalized`), takže cosine == dot product.
+- `sqlite3.connect(path, isolation_level=None)` — autocommit, transakce řízené explicitně.
+  Bez toho `BEGIN` spadne na „cannot start a transaction within a transaction".
+
+## Chunking
+
+Strukturně vědomý, po heading hierarchii — uživatelovy poznámky jsou md se smysluplnou
+strukturou (adresáře = témata, soubory, H1–H3 sekce), takže slepování přes hranice sekcí by
+embeddingy kazilo.
+
+- Rozdělení po heading sekcích (H1–H3); každý chunk nese **breadcrumb** (`soubor > sekce >
+  podsekce`) v metadatech **i v embedding textu** — vektor tak nese kontext, ne izolovaný odstavec.
+- Merge malých sousedních sekcí pod stejným rodičem (< ~200 tokenů).
+- Split velkých sekcí (> ~800 tokenů) po odstavcích s overlap ~50–80 tokenů.
+  Cílová granularita ~200–800 tokenů/chunk.
+- Kód bloky a tabulky se nerozbíjejí; checklistové soubory chunkujeme po bullet blocích.
+- Frontmatter tagy jdou do `files.tags` (na filtrování), do embedding textu jde jen title.
+- Token counting: aproximace ~4 znaky/token (přesný tokenizer pro sizing netřeba).
+
+Parser je **markdown-it-py** (zná CommonMark edge cases — setext headings, nested listy,
+HTML bloky), **chunkovací politika je vlastní** (~50 řádků nad tokeny).
+
+## Hledání — tři vrstvy, od nejlevnější
+
+1. **Syntakticky — live grep** (ripgrep přes mirror): exact match, názvy souborů, hostname,
+   tagy, čísla. Žádný index, vždy aktuální. Základ, ne fallback.
+2. **Tematicky — generovaný TOC** (`toc.md` per zdroj: kategorie → soubor → jedna řádka;
+   title + tagy + headings). Index-first navigace, generovaná syncem.
+3. **Fuzzy/sémanticky — hybrid**: FTS5 (BM25) + `vec0` (KNN), merge přes RRF.
+
+### Query kontrakt
+
+- **Instruct prefix**: dotaz embedovat jako `Instruct: <task>\nQuery: <text>`, dokumenty bez
+  prefixu (Qwen3-Embedding je asymetrický instruct-tuned model; Ollama prefix nepřidá).
+  **Měření ale ukázalo, že to není kritická vlastnost**: recall@5 byl s prefixem i bez něj
+  identický (5/5 vs 5/5, 3/5 vs 3/5) a absolutní similarita s prefixem dokonce nižší.
+  Prefix zlepšil jen **top-1 na nejtěžším dotazu** (`e-waste-reduction.md` místo
+  `software-preservation.md`). Zavádíme ho, protože je zdarma a na hraničním dotazu pomohl —
+  a hlavně proto, že **musí být bitově identický při indexaci i dotazu**, což je skutečný
+  důvod, proč hodnota žije v `meta.query_prefix`.
+- **FTS5 termy s prefix wildcardem** (`záloh*`) — pokrývá českou flexi, kterou `unicode61`
+  nestemuje. Ověřeno: `záloh*` i `zaloh*` najdou *záloha/zálohování/zálohy*.
+- **RRF** se dělá v Pythonu nad dvěma seznamy `chunks.id` (`vec0` KNN vyžaduje `k`).
+- **Mismatch `meta` vs. config** (jiný model/dims/prefix/chunker_version) → **dotaz odmítnout**
+  s „reindex needed". Nikdy tiše nemíchat vektory ze dvou modelů.
+- **Ollama nedostupná** → FTS-only a **říct to ve výstupu**, ne tiše degradovat.
+
+## Provozní model — offline sync
+
+**Indexace nikdy neběží v tahu agenta.** `exec` má timeout 60 s a plný index ~10⁴ chunků při
+108 chunk/s je ~77 s. Agent v tahu jen **čte** hotový index.
+
+```
+cron: * * * * *     (vzor: existující remind_send / note_compile řádky; PATH v hlavičce crontabu)
+  ↓
+notes_sync.py
+  1. lock: db/.notes-sync.lock (O_EXCL). Držený → exit 0 bez výpisu. Žádný souběh.
+  2. levná detekce změn, BEZ indexace:
+       git zdroje:       git ls-remote <url> HEAD  vs. sources.indexed_rev   (síť, ne fetch)
+       workspace zdroje: walk + (path, size, mtime) vs. files                (sha256 jen na mismatch)
+  3. nic se nezměnilo → exit 0   (běžný případ, drtivá většina tiků)
+  4. změněné soubory: chunk → embed (batch 32, keep_alive -1) → upsert v transakci
+       smazaný/přejmenovaný soubor: DELETE z files (kaskáda uklidí chunks+FTS)
+                                    + EXPLICITNÍ DELETE z vec_chunks
+  5. update sources.indexed_rev / last_sync_at
+  6. coverage report: zaloguj top-level adresáře s *.md, které nepokrývá žádný source
+  7. log do log/notes_sync.log
+```
+
+- `git ls-remote` je pro minutovou kadenci správný nástroj — zjistí remote HEAD **bez** `fetch`.
+  `fetch` teprve když se rev liší.
+- **Idempotentní**: re-run nad stejnou revizí = no-op.
+- Lock řeší souběh sám, žádná externí orchestrace.
+- **Plný re-index** = tentýž skript s `--full`. Vzácná operace (změna modelu nebo chunkeru).
+- `keep_alive: -1` na embed requestech drží model resident. Není kritické (cold load je 1,81 s),
+  ale je to zdarma. Pozn.: pod tlakem na VRAM od velkých chat modelů (gemma4:12b má 7,5 GB)
+  může scheduler potřebovat místo — při 639 MB je to nepravděpodobné, ale garance to není.
+
+## Rozsah indexace — whitelist primárně, blacklist jako skalpel
+
+**Precedence:** `paths` (whitelist — co v něm není, pro index neexistuje) → `include`
+(whitelist přípon, default `*.md`) → `exclude` (skalpel, vyhrává nad oběma).
+
+**Proč whitelist ve workspace — směr selhání.** U blacklistu nový adresář *tiše vstoupí* do
+indexu, u whitelistu *tiše chybí*. Embedding tabulka je de facto komprimovaná kopie obsahu
+(včetně osobních věcí), takže „tiše zaindexováno" je horší porucha. A workspace se mění
+autonomně — Dream přepisuje soubory, skilly appendují, cron zapisuje.
+
+**Doloženo měřením:** ve workspace je 234 md mimo `tmp/` a použitelných je ~99. Zbytek je
+`cml/` 39, `skills/` 32, `.venv/` 27, `backup/` 20, `tasks/` 16, `.pytest_cache` 1.
+A `tmp/` drží **dalších 135 md** (git klony, 5× reflect dump po ~200 kB). Blacklist by musel
+hned první den správně pokrýt pět a půl adresáře a zůstat správný navždy — a nejhorší z nich
+je právě ten, který je určený k tomu, aby se v něm hromadil balast.
+
+**Proč opt-out u git rep.** Uživatelova poznámková repa jsou kurátorovaná a homogenní;
+vyjmenovávat v nich podadresáře je zbytečná friction. Tam `paths: ["**"]` a malý `exclude`.
+
+### Co se indexuje
+
+| Zdroj | Cesty |
+|---|---|
+| `workspace` | `notes/**`, `projects/**`, `plans/**`, `knowledge/**`, `results/**`, `cook/**` |
+| `develop` | `develop/**` mimo `develop/history.md` |
+| git zdroje | celé repo, `*.md` |
+
+`results/` (21 souborů, 256 kB výstupů deep-research) a `develop/knowledge.md` (113 kB hutných
+ověřených faktů o instanci) jsou vědomé **přírůstky** — whitelist z nich dělá rozhodnutí.
+
+### Co se neindexuje a proč
+
+| Cesta | Důvod |
+|---|---|
+| `tmp/` (135 md) | git klony + reflect dumpy po 200 kB; adresář určený k balastu |
+| `.venv/` (27), `.pytest_cache/`, `.ruff_cache/` | dokumentace balíčků a cache |
+| `backup/` (20) | **near-duplicate kopie indexovaného obsahu** — otrávily by top-k redundantními hity; to je horší porucha než chybějící dokument |
+| `develop/history.md` (331 kB) | append-only deník; ~200 chunků repetitivní narativy = ~25 % indexu při nízké hustotě signálu. `develop/knowledge.md` vedle něj zůstává |
+| `skills/**` (32) | instrukce pro agenta, ne znalosti; agent si skilly načítá sám |
+| `cml/` (39) | llm-wiki, ruší se mimo tento plán |
+| root `AGENTS.md`/`SOUL.md`/`USER.md`/`keep.md`/`HEARTBEAT.md`, `memory/MEMORY.md` | vždy v kontextu nebo triviálně krátké → čistý šum |
+| `log/`, `sessions/`, `db/`, `cron/`, `tasks/` | provozní stav, ne obsah |
+| `memory/history.jsonl`, binárky | vyřazuje už `include: ["*.md"]` — do `exclude` psát netřeba |
+
+**Záchranná síť proti jediné slabině whitelistu:** sync na konci zaloguje top-level adresáře,
+které obsahují `*.md` a nepokrývá je žádný source. Tím se „tiše chybí" změní z neviditelné
+poruchy na řádek v `log/notes_sync.log`.
+
+## Konfigurace
+
+`config/notes-search.yaml`. **Klíč sekce = source id** (stabilní; visí na něm katalog i vektory;
+URL/path se můžou změnit, klíč ne; rename = explicitní invalidace indexu daného zdroje).
+Source id nesmí kolidovat mezi sekcemi — katalog je sdílený přes `source_id`.
+
+Formát je **YAML** (ne TOML — zamítnuto uživatelem, zapsáno v `USER.md`): config se edituje
+ručně a komentáře v něm mají hodnotu, což JSON neumí.
+
+```yaml
+embedding:
+  endpoint: http://nvidia.hell:11434
+  model: qwen3-embedding:0.6b       # tag psát VŽDY explicitně (latest = 8b, 4,7 GB)
+  dims: 1024
+  batch: 32
+  keep_alive: -1                    # číslo, ne string ("-1" vrací HTTP 400)
+  query_prefix: "Instruct: Given a web search query, retrieve relevant passages that answer the query\nQuery: "
+
+sources:
+  git:
+    travel:
+      url: git@host:travel-notes.git
+      mirror: tmp/mirrors/travel.git
+      paths: ["**"]
+      include: ["*.md"]
+      exclude: []
+    devops:
+      url: https://host/devops-notes.git
+      mirror: tmp/mirrors/devops.git
+      paths: ["**"]
+      include: ["*.md"]
+
+  nanobot:
+    workspace:
+      paths: ["notes/**", "projects/**", "plans/**", "knowledge/**", "results/**", "cook/**"]
+      include: ["*.md"]
+      exclude: ["**/inbox/**"]      # rozpracované zachyty před compile
+    develop:
+      paths: ["develop/**"]
+      include: ["*.md"]
+      exclude: ["develop/history.md"]
+```
+
+## Rozhodnutí
+
+### D1 — Embeddings jako vrstva nad BM25, ne místo něj
+
+Embeddingy přidávají parafrázi a cross-jazyk („prodloužení životnosti LEGO" najde „e-waste,
+Mindstorms po ukončení podpory" — žádná slova se nepřekrývají) a chunk-level relevanci.
+Nevyřeší exact match a čísla. Proto **hybrid**: FTS5 lexikálně, vektory sémanticky, RRF merge.
+
+**Potvrzeno měřením**, ne argumentem — viz tabulka retrieval kvality výše: na těžkém dotazu
+BM25 1/5 vs. embeddingy 3/5, na lexikálním naopak BM25 4/5.
+
+### D2 — Model `qwen3-embedding:0.6b`
+
+1024 dims, 32k ctx, 639 MB (q8_0), multilingual s češtinou jako first-class. Naměřeno:
+cold 1,81 s, warm 0,043 s, 108 chunk/s v batchi 32. Na parafrázových dotazech 5/5 — **0,6B stačí**.
+
+- **Tag psát vždy explicitně**: `latest` je 8b (4,7 GB), ne šestistovka.
+- `keep_alive: -1` (číslo).
+- **Volba modelu NENÍ silně vážící rozhodnutí.** Při 10³–10⁴ chunků je plný re-embed jednotky
+  minut, takže přechod na `4b-q8_0` je odpoledne, ne rewrite. Signál pro upgrade: parafrázový
+  dotaz, kde správný chunk existuje a keyword dotaz ho najde, ale sémantická polovina ho
+  nevrátí ani v top-10.
+- Storage není omezení: 10⁴ × 1024 × 4 B ≈ 40 MB. Matryoshka truncation netřeba.
+
+### D3 — Vektory v `sqlite-vec` (`vec0`), ne BLOB + numpy
+
+Rozhodující je rozpad nákladu, ne teorie: u BLOB+numpy je při 100k chunků 594 ms celkem, z toho
+**read 382 ms + pack 190 ms a samotný dot jen 22 ms** — 96 % je Python režie na extrakci
+a packování. `vec0` ji odřízne skenem v C: **19 ms @ 10k, 212 ms @ 100k**.
+
+Pozor na zdůvodnění: **`vec0` není ANN index.** Dokumentovaná cesta dotazu je průchod
+(lineární škálování 19 → 212 ms to potvrzuje). Výhoda je konstanta, ne asymptotika.
+
+**Cena:** `sqlite-vec` je pre-v1 a README píše „expect breaking changes"; užší dotazovací plocha
+(max 16 metadata sloupců, 4 partition keys, `IS NULL`/`LIKE` na metadatech nefunguje, auxiliary
+sloupce nesmí do KNN `WHERE`); ztráta volné numpy matematiky (MMR re-ranking, truncation za běhu).
+
+**Mitigace:** verze připíchnutá (`sqlite-vec==0.1.6`) a zapsaná v `meta.sqlite_vec_version`;
+index je derived, `db/` gitignorovaná a rebuild jsou jednotky minut; `chunks` zůstává kanonická,
+takže **návrat k BLOBu je přidání jednoho sloupce**. Blast radius breaking changu je „zůstaň na
+staré verzi, nebo přizpůsob a přeindexuj", ne ztráta dat.
+
+**Ověřeno smoke testem** (jinak by D3 padlo): `DELETE`/re-`INSERT`/`UPDATE` po `rowid`,
+transakční `ROLLBACK`, `distance_metric=cosine`, `vec0` v témže souboru jako běžné tabulky,
+join `vec_chunks.rowid = chunks.id`.
+
+### D4 — Chunking strukturně vědomý
+
+Viz sekce Chunking. Fixed-size sliding window zamítnuto.
+
+### D5 — markdown-it-py, ne vlastní parser a ne frameworky
+
+Dva různé případy:
+
+- **Parser patří do knihovny.** Vlastní regex zná CommonMark edge cases jen do té míry, do jaké
+  si je ošetříš. markdown-it-py je malá, stabilní, zero-bloat (jen `mdurl`), dává proper AST.
+  Chunkovací **politika** ale zůstává vlastní.
+- **Glue kód neobírat frameworkem.** Sync orchestrace, katalog, hybrid search — tady neexistuje
+  „malá dobrá knihovna", nabídka je binární: langchain/llama-index (stovky MB, abstrakce nad
+  sqlite3/subprocess/HTTP, měnící se API) nebo vlastních ~500 řádků. Tady „psát si sám" není
+  NIH, je to jediná racionální volba, protože alternativa obaluje čtyři stdlib volání.
+
+Dependency set: `markdown-it-py`, `requests`, `numpy`, `pyyaml`, `sqlite-vec==0.1.6`.
+
+### D6 — FTS5 tokenizer `unicode61 remove_diacritics 2` + prefix wildcardy
+
+**Zavřeno měřením, ne odloženo na testování.** `remove_diacritics 1` a výš foldí diakritiku
+(dotaz `zaloha` najde `záloha`; `0` ne). `unicode61` nestemuje, ale prefix wildcard to pokryje:
+`záloh*` najde *záloha, zálohování, zálohy*. **Trigram tokenizer zamítnut** — netřeba.
+Dotazová vrstva lepí `*` na termy delší než 2 znaky.
+
+### D7 — Skill je samostatný, bez závislostí na jiné skilly
+
+Vzory z `remind`/`note` se **kopírují, neimportují**. Vlastní `db.py`/`store.py`, vlastní
+lockfile, **žádný `detach`**, nepřebírat `wiki_search.py` ani `note_capture._ascii_fold()`
+(FTS5 `remove_diacritics` folding stejně řeší). Cena je duplikace kódu; hodnota je, že skill
+nespadne s ničím jiným a dá se přenést.
+
+### D8 — Mirror jako zdroj, sync offline
+
+Git repa jsou kanonická data, index je derived. Mirror přes `git clone --mirror` / `fetch`.
+
+**`fetch-on-query` zamítnut**: přidával `git fetch` *i embed nových chunků* do latence dotazu,
+a při nedostupné Ollamě dělal z čerstvého dokumentu FTS-only výsledek. Místo toho offline cron
++ lock (viz Provozní model).
+
+**Staleness není problém**: index je retrieval hint, ne source of truth — před odpovědí se
+soubor vždy přečte čerstvý z disku. Dotaz může vidět index o minutu starší, což je přijatelné.
+
+### D9 — `chunks` je jediná retrieval jednotka
+
+`chunks_fts` i `vec_chunks` vracejí `chunks.id`, RRF slučuje je. Klíč `(source_id, path,
+chunk_idx)`. Rank-merge dvou různých jednotek nemá definovaný význam → file-level BM25 vyloučen.
+
+### D10 — Identita embedding prostoru v `meta`
+
+`embedding_model`, `embedding_dims`, `normalized`, `query_prefix`, `chunker_version`.
+Mismatch proti configu **odmítne dotaz** s „reindex needed". Bez toho by se smíchané vektory
+ze dvou modelů projevily jako **tiché zhoršení výsledků, ne jako chyba** — nejdražší druh bugu.
+
+### D11 — Indexace výhradně offline
+
+Cron + lockfile, nikdy v tahu agenta. Důvod: `exec` timeout 60 s vs. plný index ~77 s.
+
+### D12 — Rozsah indexace whitelistem
+
+Viz sekce Rozsah indexace. `paths` je hradlo, `exclude` skalpel; workspace opt-in, git repa opt-out.
+
+## Zamítnuté varianty
+
+| Varianta | Proč ne |
+|---|---|
+| **Ollama Cloud embeddingy** | Cloud tier embedding endpoint **neservíruje** — 18 cloud modelů, žádný s capability `embedding`; `/api/embed` vrací `unauthorized`, zatímco completion na tomtéž modelu projde. Katalog na ollama.com to potvrzuje: všech 12 embedding modelů je jen ke stažení. Navíc by to porušilo lokalitu dat (celý korpus osobních poznámek do cizí služby) a plný re-index = ~10⁴ requestů na externí API |
+| Generativní cloud model + pooling hidden states | Generativní modely nejsou kontrastivně trénované na retrieval; proto je capability oddělená |
+| `nomic-embed-text` (137M) | EN-centric, pro češtinu nevýhodný |
+| `bge-m3` (567M) | Umí dense+sparse hybrid z jednoho modelu, ale přes Ollama embeddings API jde dostat jen dense — výhoda mizí, FTS5 dělá tutéž roli levněji |
+| `qwen3-embedding` 4b/8b jako start | Lepší multilingual skóre, ale 2,5–15 GB na kartě sdílené s chat modely. Upgrade je odpoledne (re-embed = minuty), tak začít malým |
+| `*-q4_K_M` kvantizace | 4bit u embeddingu; šestistovka q4 v nabídce ani není |
+| BLOB + numpy cosine | 96 % nákladu je Python režie; viz D3 |
+| `.npy` + `mmap_mode='r'` (35 ms @ 100k) | Nejrychlejší, ale druhý soubor mimo DB, který se musí držet v sync s `chunks` — složitost bez přínosu, když `vec0` dává 19 ms na reálné škále |
+| Externí vektorová DB (Chroma/Qdrant/pgvector) | Řeší problém, který na této škále neexistuje (server, jiná backup story, >10⁶ vektorů) |
+| Trigram tokenizer | Netřeba, `remove_diacritics 2` + prefix wildcardy stačí (D6) |
+| Entity/concept pages jako v llm-wiki | Uživatel poznámky strukturoval sám; LLM-kurátorovaná druhá vrstva by byla duplikace. Adresářová struktura repů JE primární tematický index — zpřístupňujeme ji (TOC), nereimplementujeme |
+| `fetch-on-query` / `scan-on-query` | Viz D8 |
+| Blacklist jako primární gate | Viz D12 |
+| Embeddingy až když fuzzy dotazy selžou | Zamítnuto — jsou součástí od začátku |
+
+## Konvence implementace
+
+Vzory z existujících skillů (kopírovat, neimportovat — D7):
+
+| Věc | Vzor | Zdroj |
+|---|---|---|
+| Rozdělení kódu | `db.py` (SCHEMA, `get_db()`, `_migrate()`, `init_db()`) + `store.py` (`connection()`/`transaction()` + veškeré SQL) + CLI bez inline SQL | `skills/remind/scripts/` |
+| Migrace | idempotentní `CREATE ... IF NOT EXISTS` v jednom `SCHEMA` přes `executescript()` + `_migrate()` s `PRAGMA table_info` a `ALTER TABLE ADD COLUMN`. Žádná `schema_version` tabulka, žádný framework | `remind/scripts/db.py` |
+| Connection | `sqlite3.connect(path, isolation_level=None)` + `PRAGMA journal_mode=WAL`, `foreign_keys=ON`, `row_factory=sqlite3.Row` | `remind/scripts/db.py` |
+| Cesta k DB | `WORKSPACE = Path(__file__).resolve().parents[3]`, `WORKSPACE/"db"/"notes-index.sqlite"`, env override pro testy | `note/scripts/note_capture.py:25` |
+| Shebang | entry point `#!/usr/bin/env -S uv run --script` + PEP 723; importovaný modul `#!/usr/bin/env python3` + PEP 723 | `remind/scripts/*` |
+| Cron řádek | `* * * * * uv run .../scripts/notes_sync.py >> log/notes_sync_cron.log 2>&1` (`PATH` je v hlavičce crontabu) | server `crontab -l` |
+| Lockfile | `notes/.compile.lock` je precedens → `db/.notes-sync.lock` | `note/scripts/note_compile.py` |
+| SKILL.md | frontmatter jen `name` + `description` (folded `>`, EN, s `Triggers on:` a **funkční** negativní delimitací — nikdy jménem jiného skillu); tělo ~100 řádků; workspace-relativní `uv run skills/<name>/scripts/x.py` | `remind/SKILL.md` |
+| Testy | `skills/<name>/tests/`, `uv run --with pytest pytest ...`, izolace přes `tmp_path` + monkeypatch modulového `DB_PATH` | `remind/tests/` |
+| Deploy | `rsync -av --exclude '__pycache__' --exclude '.pytest_cache' skills/<name>/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/<name>/` | `CLAUDE.md` |
+
+Query interface: skill s CLI skriptem `notes_search.py` (vzor `remind_cli.py` — argparse,
+subcommandy, `--help` místo plné flag reference v SKILL.md).
+
+## Otevřené otázky
+
+1. **Seznam rep** — která repa, jejich URL, kam mirrorovat, velikost/historie (vliv na fetch čas).
+   Musí doplnit autor; bez toho nelze naplnit `config/notes-search.yaml`.
+2. **Benchmark modelu na uživatelských datech** — cross-jazyk test výše proběhl na workspace
+   obsahu (`cml/wiki`, `plans/`). Po přidání reálných rep ho zopakovat na nich.
+
+## Verifikace
+
+**Hotovo (2026-09-09)** — schéma i model ověřené smoke testem, viz tabulky faktů:
+`vec0` mutace a transakčnost, KNN latence na dvou škálách, FTS5 external-content triggery
+s češtinou, RRF merge nad `chunks.id`, cold load / throughput modelu, retrieval kvalita.
+
+**Při implementaci:**
+
+1. **Regresní test na osiřelé vektory** — smaž soubor → `vec_chunks` nesmí obsahovat jeho
+   rowidy. Tohle je jediná past, kterou schéma samo neochrání (kaskáda na `vec0` nedosáhne).
+2. **Idempotence syncu** — dvakrát za sebou nad stejnou revizí: druhý běh nesmí nic změnit
+   (počty v `chunks`/`vec_chunks`/`chunks_fts` shodné, `indexed_rev` stejná).
+3. **Lock** — spustit dva syncy současně; druhý musí skončit exit 0 bez zápisu.
+4. **Degradovaný režim** — s vypnutou/nedosažitelnou Ollamou: sync uloží chunky
+   s `embedded_at IS NULL`, dotaz vrátí FTS-only výsledek a **řekne to**; po obnovení
+   Ollamy další sync vektory dosadí.
+5. **`meta` guard** — podvrhni v configu jiný `model`/`dims` → dotaz musí skončit
+   „reindex needed", ne vrátit výsledky.
+6. **Coverage report** — přidej md soubor do adresáře mimo `paths` → sync ho musí ohlásit v logu.
+7. **Latence dotazu end-to-end** — cíl: pod 1 s při teplém modelu (embed dotazu 0,043 s
+   + KNN ~19 ms + BM25 + RRF).

plans/notes-search-hybrid-rag.md

@@ -0,0 +1,330 @@
+# Notes Search — RO git repa → hybrid RAG index
+
+> **Superseded by `final-wiki-hybrid-rag.md`** (2026-09-09) — tento draft je historie.
+
+Stav: DRAFT — budeme ještě opracovávat, než se pustíme do realizace.
+Vznik: diskuze 2026-09-XX (nahradit přesným datem při finalizaci).
+
+## Cíl
+
+Uživatel vede poznámky ve vlastních git repozitářích (adresářová struktura, md
+soubory; témata: devops, traveling, mix všeho možného). Nanobot dostane
+**read-only přístup** k mirrorům těchto repů a postaví nad nimi index, který
+umožní rychlé hledání — tematické i syntaktické. Poznámky zůstávají
+kanonickými daty v gitu; index je jen derived artifact, regenerovatelný.
+
+Repozitáře jsou read-only z pohledu agenta — nikdy nic nezapisujeme do
+uživatelových repů, všechno derived žije ve workspace nanobota.
+
+## Vstupní fakta a omezení (ověřené v diskuzi)
+
+- **HW pro embedding inference**: RTX 4060/16 GB na serveru `nvidia.hell`
+  — **fyzicky jiný host** než běžiště nanobota. Embedding je network call
+  na Ollama HTTP API, ne lokální volání. Dosažitelnost endpointu zatím
+  neověřena (TODO před realizací).
+- Uživatel sám navrhl dodat embeddings přes vlastní Ollama server —
+  embedding inference tedy není omezující faktor.
+- Škála datasetu: pár repů, řádově stovky až tisíce md souborů,
+  po chunkování ~10⁴–10⁵ chunků.
+- Obsah převážně česky + anglicky.
+- Uživatel ukládá i embedding vektory — potřebujeme vektorové úložiště,
+  otázka je jen jaké (viz rozhodnutí D3).
+
+## Architektura
+
+```
+Zdroje:
+  git mirrory (RO clone/fetch, keyed na indexed-rev)
+  + nanobot workspace (živá data, scan path+size+mtime)
+  → ingest driver (git-diff / fs-scan — dva drivery, jeden indexer)
+  → chunker (md → chunky po heading struktuře)
+  → embeddings: Ollama API (qwen3-embedding:0.6b) — jen změněné chunky
+  → SQLite: catalog + FTS5 tabulka + embedding BLOB sloupce
+  → query: hybrid search (BM25 via FTS5 + cosine), top-k merge (RRF)
+```
+
+Konfigurace zdrojů: `config/notes-search.yaml` (viz sekce Konfigurace).
+
+Jeden SQLite soubor (`db/notes-index.sqlite` dle konvence AGENTS.md:
+databáze do `db/*.sqlite`), který nese:
+- **catalog**: `repo, path, title, tags, headings, sha, indexed_at`
+- **FTS5 tabulka**: fulltext s BM25 rankingem (exact/lexikální půlka)
+- **embedding tabulka**: `path, chunk_idx, text, embedding BLOB`
+  (sémantická půlka; BLOB + numpy cosine brute-force)
+
+## Hledání — tři vrstvy, od nejlevnější
+
+1. **Syntakticky — live grep** (ripgrep přes mirror): exact match,
+   názvy souborů, hostname, tagy, čísla. Žádný index potřeba, vždy
+   aktuální. Základ, ne fallback.
+2. **Tematicky — vygenerovaný TOC** (`toc.md` per repo: kategorie →
+   soubor → jedna řádka; title + tagy + headings). Index-first navigace
+   jako v llm-wiki, ale generovaná, ne LLM-kurátorovaná.
+3. **Fuzzy/sémanticky — hybrid search**: FTS5 (BM25) + embeddings
+   (cosine), merge přes RRF. Používá se, když TOC browsing nezabere.
+
+## Incrementální update (nové dokumenty ve zdrojích)
+
+1. `git fetch` mirroru; `git diff --name-status <indexed-rev>..HEAD`
+   → seznam přidaných/změněných/smazaných/přejmenovaných md souborů.
+2. Chunker zpracuje jen změněné soubory; staré chunky daného `path`
+   se smažou (`DELETE WHERE path = ?`), nové se vloží.
+3. Embedding: jen změněné chunky → Ollama API → upsert do SQLite.
+   Nový soubor = pár desítek chunků, sekundy.
+4. FTS5 sync ve stejné transakci.
+5. Commit `indexed-rev = HEAD`; smazaný soubor = delete chunků + FTS.
+
+Vlastnosti: **idempotentní** (re-run nad stejnou revizí = no-op),
+degradovaný režim (Ollama nedostupná → FTS5 funguje dál, chunky
+bez vektoru poznáme přes `embedding IS NULL`, dosadí se při dalším
+syncu). Full re-index jen při změně embedding modelu.
+
+## Rozhodnutí a důvody (včetně diskuze)
+
+### D1: Embeddings ano — jako vrstva nad BM25, ne místo něj
+
+Diskuze: nejprve navržen „zero embedding" stack (grep + TOC + FTS5).
+Uživatel reagoval, že embeddings může dodat přes vlastní Ollama server,
+a upřesnil, že embedding vektory se někam musí ukládat.
+
+Embeddings přidávají nad BM25 dvě věci: parafráze a cross-jazyk
+(„prodloužení životnosti LEGO" najde „e-waste, Mindstorms po ukončení
+podpory" — žádná slova se nepřekrývají, BM25 selže) a chunk-level
+relevance (najde konkrétní odstavec v dlouhém souboru, ne jen soubor).
+Nevyřeší ale exact match a čísla — proto **hybrid**: FTS5 pro
+lexikální, embeddings pro sémantickou stranu, top-k merge (RRF).
+Embeddings jsou doplněk, ne náhrada.
+
+### D2: Embedding model — Qwen3-Embedding-0.6B
+
+Kritéria (od uživatele): běží na 4060/16 v jeho lokálním serveru,
+rozumná velikost uložení vektorů.
+
+- **VRAM ~1.2 GB** — pohodové vedle dalších modelů na Ollamě.
+- **32k context** — dlouhé dokumenty bez omezování chunkování.
+- **Multilingual, top MTEB ve své třídě** — čeština first-class,
+  klíčové pro české poznámky.
+- **1024 dims** — ~10⁵ chunků × 1024 × 4 B ≈ 400 MB v SQLite. Pohodové.
+  Podporuje Matryoshka truncation (512/256/128 dims) kdyby storage
+  vadil — u této škály netřeba.
+
+Alternativy zvažované a zamítnuté:
+- **nomic-embed-text** (137M params, nejpoužívanější na Ollamě) — EN-centric,
+  pro češtinu nevýhodný.
+- **bge-m3** (567M) — multilingual a umí z jednoho modelu dense+sparse
+  hybrid; ale přes Ollama embeddings API jde dostat jen dense výstup,
+  takže výhoda sparse v našem stacku mizí (FTS5 dělá tutéž roli levněji).
+
+Poznámka k jistotě: čísla a pozice z web-searchů (MTEB srovnání),
+ne osobní benchmark. Před realizací ověřit na reálných datech
+(dotaz „e-waste" vs „prodloužení životnosti" atp.).
+
+**Volba modelu je vážící rozhodnutí** — změna = re-embed celého
+datasetu. Při ~10⁵ chunků na 4060 je full re-index otázkou minut,
+přijatelné, ale ne měnit z rozmaru.
+
+### D3: Vektorové úložiště — embeddings jako BLOB v SQLite
+
+Diskuze: já jsem zpočátku tvrdil „vektorovou databázi nepotřebuješ";
+uživatel oprávněně namítl, že **sqlite-vec je svým způsobem taky
+vektorová databáze, i když embedded** — a že nikdy neříkal, že buduje
+externí službu, jen že vektory někam ukládat potřebuje. Souhlas:
+šlo o spor o pojem, ne o věc.
+
+Na škále ~10⁴–10⁵ vektorů je brute-force cosine v numpy pod 100 ms;
+ANNS indexy (HNSW apod.) dávají smysl nad ~10⁶ vektorů. Konkrétní volby:
+
+| | Embeddings v SQLite (BLOB) | sqlite-vec (`vec0`) | Chroma/Qdrant/pgvector |
+|---|---|---|---|
+| Tvar | BLOB sloupec, cosine v Pythonu | virtuální tabulka, KNN v SQL | samostatný service/DB |
+| Vyhledávání | načti vše, spočítej top-k | `MATCH` operátor, indexovaný | KNN server-side |
+| Infra | nic | load extension | server, jiná backup story |
+| Kdy se vyplatí | do ~10⁵ vektorů | ~10⁵–10⁶, metadata filter + KNN v jednom dotazu | >10⁶ vektorů |
+
+Volba: **BLOB v SQLite nyní**, schéma navrženo tak, aby migrace na
+sqlite-vec byla mechanická (import jednoho sloupce do `vec0` tabulky,
+žádná regenerace). Externí vektorové DB zamítnuty — řeší problém,
+který na této škále neexistuje (YAGNI).
+
+### D4: Chunking — strukturně vědomý, po heading hierarchii
+
+- Rozdělení po heading sekcích (H1–H3), každý chunk nese breadcrumb
+  (`soubor > sekce > podsekce`) v metadatech i v embedding textu —
+  vektor tak nesou kontext, ne izolovaný odstavec.
+- Merge malých sousedních sekcí pod stejným rodičem (< ~200 tokenů).
+- Split velkých sekcí (> ~800 tokenů) po odstavcích s overlap ~50–80
+  tokenů. Cílová granularita ~200–800 tokenů per chunk; menší chunk =
+  přesnější hit na místo v dokumentu. Qwen3-Embedding má 32k ctx,
+  takže se krčit nemusíme.
+- Frontmatter tagy zůstávají v katalogu (na filtrování), do embedding
+  textu jde jen title.
+- Kód bloky a tabulky se nerozbíjejí (drží pohromadě); checklistové
+  soubory chunkujeme po bullet blocích.
+- Token counting: aproximace ~4 znaky/token (přesný tokenizer pro
+  chunk sizing netřeba, cílové okno je široké).
+
+Proč strukturní: uživatelovy poznámky jsou md se smysluplnou strukturou
+(adresáře = témata, soubory, H1–H3 sekce); slepování přes hranice sekcí
+by embeddings kazilo. Fixed-size sliding window zamítnuta.
+
+### D5: Knihovny — markdown-it-py, ne vlastní parser a ne frameworky
+
+Diskuze: původní návrh byl „100 řádků vlastního regex chunkeru,
+stdlib only". Uživatel zpochybnil, dává smysl psát si všechno sám.
+Výsledek revize — rozlišit dva případy:
+
+- **Parser do knihovny**: vlastní regex zná CommonMark edge cases
+  (setext headings `===`, nested listy, HTML bloky) jen do té míry,
+  do jaké si je ošetříš. markdown-it-py je malá, stabilní, zero-bloat
+  (jen `mdurl`), dává proper AST. Chunkovací **politika** (split body
+  vs merge prahy, breadcrumb) ale zůstává vlastní (~50 řádků nad
+  tokeny). Původní „vlastní regex" byla varianta šetřící na špatném
+  místě — parsery patří do knihoven.
+- **Glue kód neobírat frameworkem**: sync orchestrace, katalog,
+  hybrid search — tady neexistuje „malá dobrá knihovna", nabídka je
+  binární: langchain / llama-index (frameworky, stovky MB, abstrakce
+  nad sqlite3/subprocess/HTTP, API se mění pod rukama) nebo vlastní
+  ~500 řádků. „Psát si sám" tady není NIH syndrom, je to jediná
+  racionální volba, protože alternativou je framework obalující
+  4 stdlib/utility volání.
+
+Výsledný externí dependency set: **markdown-it-py, requests, numpy**.
+Vše malé, stabilní, žádný framework. Konkrétní volby per část:
+
+| Část | Řešení | Proč |
+|---|---|---|
+| MD parsing + chunking | markdown-it-py + vlastní split politika | parser hotový/testovaný, politika naše |
+| Git sync | subprocess + git CLI | nic knihovního netřeba |
+| Katalog/FTS5/BLOB | sqlite3 (stdlib) | nic k přidání |
+| Ollama client | requests | pár řádků, knihovna nic nepřidá |
+| Hybrid merge (RRF) | numpy | ~20 řádků |
+| Config (notes-search.yaml) | pyyaml | ruční editace + komentáře; TOML zamítnut uživatelem |
+
+### D6: FTS5 tokenizer — unicode61, s vědomím české mezer
+
+`unicode61` dělá diakritiku-case-folding („ZALOŽIT" najde „založit"),
+ale nemá stemming — „záloha" nenajde „zálohování". Nástřel: doufat,
+že BM25 + embeddings hybrid mezeru překryjí (u hybridu obvykle ano);
+záložní volba trigram tokenizer (SQLite 3.34+) pro substring matching,
+kdyby se ukázalo, že hybrid nestačí. Rozhodnutí odloženo na testování
+na reálných datech.
+
+### D7: Oddělené patterny — notes search ≠ llm-wiki
+
+llm-wiki (`cml/`) je kurátorovaný knowledge store pro cílené
+ingestování cizích zdrojů (LLM píše entity/concept pages). Notes
+search je **search index nad existujícími uživatelskými poznámkami**
+— uživatel je strukturoval sám, LLM-kurátorovaná druhá vrstva by
+byla duplikace. Dva patterny, nemíchat; adresářová struktura repů je
+primární tematický index, který jen zpřístupňujeme (TOC), nereimplementujeme.
+
+Kontext: současný obsah llm-wiki (7 zdrojů o coding agentech + 1 o
+LEGO Mindstorms) uživatel hodnotí jako „nic moc, bude to chtít pojmout
+úplně jinak" — tohle řešení je odpovědí na ten směr.
+
+### D8: Mirror jako zdroj, fetch-on-query vs cron sync
+
+Git repa jsou kanonická data; index je derived. Mirror přes
+`git clone --mirror` / fetch. Staleness mirroru je jediné reálné
+riziko — mitigace: fetch-on-query (fetch vteřiny, voláno před
+dotazem) s idempotentním index update; cron/heartbeat sync volitelně
+navíc. Incremental reindex jen změněných souborů (typicky pár
+souborů per sync).
+
+## Ingest zdrojů — dva drivery, jeden indexer
+
+Index přijímá dva typy zdrojů, podle toho se liší jen detekce změn;
+chunker, embedding, ukládání i query vrstva jsou společné.
+
+### Driver: git (RO mirrory)
+
+- Detekce změn: `git fetch` + `git diff --name-status <indexed-rev>..HEAD`
+  (R-status = rename → přesun záznamů, M = reindex, D = delete).
+- Uložená `indexed-rev` per source v katalogu je vstupní bod.
+- Fetch-on-query (fetch vteřiny) před dotazem; idempotentní update.
+
+### Driver: nanobot workspace (živá data)
+
+- Detekce změn: walk stromu + porovnání `(path, size, mtime)` proti
+  katalogu; content hash (SHA-256) jako autorita, mtime jako rychlý
+  pre-filter. Žádný git, žádný rev — soubory se mění pod rukama
+  (Dream přepisuje MEMORY.md, skilly appendují logy).
+- Scan-on-query místo fetch-on-query (walk workspace je levný).
+- Nekonzistence v čase nevadí: index je retrieval hint, ne source of
+  truth — před odpovědí se soubor vždy přečte čerstvý z disku.
+- Embeddings tabulka je de-facto komprimovaná kopie obsahu (i keep.md,
+  osobní věci) v jednom SQLite souboru — vše lokální (vlastní Ollama,
+  žádná třetí služba), ale uvědomit si to v backup story.
+- Vyloučené z indexace (rozumný start, doladíme měřením): `MEMORY.md`,
+  `SOUL.md`, `USER.md` (krátké, vždy v kontextu — jen noise), `tmp/`,
+  `src/` (git klony), binárky, `history.jsonl` (obří, low signal).
+
+## Konfigurace zdrojů (YAML)
+
+Formát rozhodnut v diskuzi: **YAML** (ne TOML — uživatel výslovně
+zamítl; zapsáno do USER.md). Důvod volby YAML nad JSON: config se
+edituje ručně (uživatel při přidání repa), komentáře v configu mají
+hodnotu; JSON komentáře nemá. `pyyaml` přidán do dependency set.
+
+Jeden soubor `config/notes-search.yaml`, dvě sekce podle typu zdroje.
+**Klíč sekce = source id** (stabilní, visí na něm katalog i embeddingy;
+URL/path se můžou změnit, klíč ne; rename = explicitní invalidace indexu
+daného zdroje — chceme pod kontrolou, ne implicitní).
+
+```yaml
+# Git zdroje — RO mirrory. Klíč = source id.
+sources:
+  git:
+    travel:                                  # source id (stabilní)
+      url: git@host:travel-notes.git
+      mirror: tmp/mirrors/travel.git          # kam clone --mirror
+    devops:
+      url: https://host/devops-notes.git
+      mirror: tmp/mirrors/devops.git
+
+  # Nanobot workspace zdroje — glob vzory
+  nanobot:
+    notes:
+      paths: ["notes/**"]
+      include: ["*.md"]                      # default *.md
+      exclude: []                            # volitelné
+    projects:
+      paths:
+        - "projects/**"
+        - "cook/**"
+        - "knowledge/**"
+        - "plans/**"
+        - "results/**"
+      include: ["*.md"]
+```
+
+Pravidla:
+- `paths` = glob vzory (vyjmenovat lze celý adresář i podstrom).
+- `include` default `*.md`; jiné přípony explicitně až kdyby.
+- `exclude` deny-list přidáme až když se šum objeví (YAGNI).
+- Source id nesmí kolidovat mezi `git` a `nanobot` sekcemi —
+  katalog je sdílený (`source` sloupec).
+
+## Otevřené otázky (před realizací)
+
+1. **Adresa/endpoint Ollamy na nvidia.hell** — dohledat v projects/
+   keep.md nebo od uživatele; ověřit reachability z runtime nanobota.
+2. **Benchmark embedding modelu na reálných datech** — ověřit MTEB
+   pozice na pár českých dotazech (parafráze cross-jazyk test).
+3. **Seznam rep** — která repa, kde mirrorovat, velikost/historie
+   (vliv na fetch čas).
+4. **Trigger syncu** — fetch/scan-on-query, heartbeat, nebo obojí.
+5. **Query interface** — jak se nanobota ptát: ad-hoc dotazy v chatu,
+   skill (`search my notes`), nebo obojí.
+6. **Vyloučené workspace cesty** — potvrdit výchozí blacklist
+   (MEMORY.md/SOUL.md/USER.md, tmp/, src/, history.jsonl) měřením.
+7. **Presné datum vzniku plánu** — doplnit.
+
+## Nezávislá rozhodnutí (odloženo, YAGNI)
+
+- Embeddings až když fuzzy dotazy selžou — **zamítnuto v diskuzi**,
+  embeddings jsou součástí od začátku (uživatel je dodává přes Ollamu).
+- Externí vektorová DB (Chroma/Qdrant/pgvector) — zamítnuta (D3).
+- Entity/concept pages jako v llm-wiki — zamítnuty (D7).
+- Full re-index strategie mimo změnu modelu — netřeba (idempotentní
+  incremental, D-sync).

plans/ollama-usage-poller.md

@@ -0,0 +1,84 @@
+# Ollama Usage Poller — Continuous Collection
+
+## Context
+
+The `/usage` skill shows Ollama Cloud credit usage on demand. The user wants
+continuous collection: poll `GET https://ollama.com/api/usage` every minute,
+store a sample whenever anything changed since the last one. Goal: later
+analysis of how much each nanobot session cost, and when.
+
+Constraints found in exploration:
+
+- The API (`ollama.com/api/usage`, Bearer key from `workspace/.env`) returns:
+  `limits.session.usage` (fraction of plan limit, rolling 1-hour window),
+  `limits.weekly.usage` (weekly window), per-model `request_count` for both
+  windows, `activity.cost` (broken, always $0.00000 on Pro).
+- No reset timestamps, no per-model cost split, no token counts in the API.
+- Existing pattern: per-minute system crontab entries running `uv run <script>`
+  with output to `workspace/log/<name>_cron.log` (remind, wiki-compile,
+  wiki-sync). Reuse this pattern.
+- Session attribution later needs `memory/history.jsonl` (per-request
+  timestamps, token counts, session ids) — out of scope for this plan, this
+  plan only builds the collector + a delta report.
+
+## Steps
+
+1. **Collector** — `scripts/ollama_usage_poll.py` (English, stdlib only,
+   reuse `load_api_key` from `skills/usage/scripts/ollama_usage.py`):
+   - GET the API, on network/HTTP error log to stderr and exit 0
+     (never noisy, never blocks cron).
+   - SQLite `db/ollama_usage.sqlite`, table `samples`:
+     ```sql
+     CREATE TABLE IF NOT EXISTS samples (
+       ts       TEXT PRIMARY KEY,   -- UTC ISO 8601
+       session  REAL NOT NULL,      -- limits.session.usage fraction
+       weekly   REAL NOT NULL,      -- limits.weekly.usage fraction
+       models   TEXT NOT NULL       -- JSON: weekly {"model": count}
+     );
+     ```
+   - Write-on-change: compare against the latest row; insert only when
+     session, weekly, or models JSON differ. Unchanged minutes are noise.
+   - Session-window reset detection (usage drops instead of rising) is
+     implicit — we store raw values; deltas are computed at report time.
+
+2. **Crontab** — add system crontab entry (user's crontab, alongside the
+   existing ones):
+   ```
+   # ollama-usage: continuous usage sampling into db/ollama_usage.sqlite
+   * * * * * uv run /home/nanobot/.nanobot/workspace/scripts/ollama_usage_poll.py >> /home/nanobot/.nanobot/workspace/log/ollama_usage_cron.log 2>&1
+   ```
+
+3. **Report** — `scripts/ollama_usage_report.py` (English, stdlib only):
+   - No args: last 24 h delta summary (session/weekly spend per hour, model
+     request deltas).
+   - `--since ISO` / `--until ISO`: arbitrary window.
+   - Output: plain text table — for each consecutive sample pair:
+     `ts, Δsession %, Δweekly %, Δrequests per model`. Detect hourly reset
+     (session drops) and mark it as a new window boundary.
+   - Extend the `/usage` skill SKILL.md with a "Reports" section pointing
+     at this script (does not change the on-demand output format).
+
+4. **Skill update** — `skills/usage/SKILL.md`: add a short note that
+   continuous sampling runs via crontab into `db/ollama_usage.sqlite` and
+   reports are available via `scripts/ollama_usage_report.py`.
+
+5. **Git commit** — workspace repo, timestamped message.
+
+## Out of scope (later)
+
+- Session-level attribution (join with `memory/history.jsonl` token counts
+  per session) — separate plan once we have a few days of samples.
+- Notification thresholds (e.g. Telegram alert at 80 % weekly).
+- Retention/compaction of the samples table (1 row per change, negligible
+  size for months).
+
+## Verification
+
+1. Run `uv run scripts/ollama_usage_poll.py` twice back to back → second run
+   writes nothing (no change), DB has 1 row.
+2. Wait for a real request (or make one via nanobot) → next poll writes a
+   new row with changed session fraction / model counts.
+3. Run the report script → delta table renders, hourly reset detected as
+   boundary when a session window rolls over.
+4. `crontab -l` shows the new entry; after ~5 minutes `log/ollama_usage_cron.log`
+   is empty or minimal, DB grew.

projects/ai/artifacts/agent-to-human-tools.md

@@ -0,0 +1,43 @@
+# Převod agent-nástrojů na nástroje pro člověka
+
+Ověřený postup. Když AI agent napsal nástroj (runbook, skripty) původně
+**pro sebe**, nejde ho přímočaře zjednodušit pro lidské použití.
+
+## Proč opačný postup nefunguje
+
+- Model nevidí hranici, kde končí pro člověka použitelná složitost —
+  „zjednoduš to" produkuje kosmetické úpravy, ne redesign.
+- Existující podoba psaná pro agenta (hromada parametrů, dlouhé runbooky)
+  model **ukotvuje** — upravuje, co vidí, místo aby navrhl jiné rozhraní.
+- Plan mode u designu rozhraní nestačí: plánuje implementaci, ne podobu
+  rozhraní. Tu musí určit člověk.
+
+## Princip
+
+**Rozhraní navrhuje člověk, model implementuje.** LLM je nejsilnější v
+dokódování těla funkce se zadaným podpisem — přebírání designu je jeho slabá
+stránka.
+
+## Postup
+
+1. **Existující agent-runbook ani skripty nepoužívat jako základ** — jen jako
+   zdroj doménových faktů (co nástroj umí, jaké scénáře existují, jak se čeká
+   na konec testu). Strukturu ne. Začít v čistém adresáři.
+2. **Tabulka scénář → příkaz** — člověk ručně napíše, co kdy spouští.
+   To je celý human-runbook; žádný postup kroků.
+3. **Kostry skriptů píše člověk** — param block, komentáře po sekcích,
+   protokol čekání na dokončení (např. čekat na exit procesu, žádný polling).
+   Složitost je tím rozhodnutá předem.
+4. **Model jen dokódovává těla** — zadání: „dokóduj těla, parametry
+   a strukturu neměň, nic nepřidávej.“ Review pak kontroluje jen implementaci,
+   ne design.
+
+## Pravidla pro zadání
+
+- Složitost zadávat **čísly, ne adjektivy**: max počet parametrů na skript,
+  max počet kroků, jeden skript = jeden scénář. Model na numerické limity
+  reaguje spolehlivě; na „simple" ne.
+- Negativní omezení („žádné extra parametry") prosadit **v kódu kostry,
+  ne v promptu** — když param block má 3 parametry, model 15 nedoplní.
+- Agent-runbook pro sebe si nechat vedle — převod „agent-runbook →
+  human-runbook" je cesta, kde se to pořád láme. Nejsou to stejný dokument.

projects/ai/artifacts/file-based-agent-communication.md

@@ -0,0 +1,54 @@
+# Anotace v souborech místo chatu („mob with AI")
+
+Zdroj: článek „Don't Chat With Your AI. Mob With It." (David Rodenas, Medium,
+2026). Článek sám je slabý — argument o latenci (GPU sloty, uvolňování/
+načítání inference) je nedoložený a nesedí; reálná latence je round-trip
+klient↔server, sériovost kroků a opakovaný prefill. Analogie s mob
+programmingem taky ne — v mobu píše jeden driver a víc lidí řídí, tady je to
+obráceně. Jádro je ale použitelné.
+
+## Co drží (jádro oddělené od balastu)
+
+- **Instrukce patří tam, kde je předmět instrukce.** Tag na konkrétním řádku
+  dá kontext pozicí — agent nepotřebuje popis „v tom souboru, u té funkce".
+  Stejný princip jako TODO komentář / poznámka v code review.
+- **Trvalost:** anotace nesedí v chatu, který se zavře — je v souboru, vidět
+  v diffu, přežije session.
+- Není to o latenci ani paralelizaci. „Zrychlení" je ve skutečnosti **fronta**:
+  zadám a nejdu čekat. Round-trip se nezkrátil, jen u něj nestojím.
+- Článek si protiřečí vlastním východiskem (DORA/TDD = rychlý feedback):
+  hromadné zadání a společný review na konci **prodlouží feedback loop pro
+  člověka**, ne pro agenta. „Hotovo dřív, než si všimnu" je z tohoto pohledu
+  špatná zpráva, ne dobrá.
+
+## Mechanismus
+
+Komunikace přes tagy přímo v souborech (autor: `[[CLAUDE: …]]` instrukce,
+`[[DAVID: …]]` dotaz agenta). Pravidlo v CLAUDE.md: agent tagy hledá, provádí,
+odpovídá. Autor tag po provedení maže — to je chyba.
+
+## Úpravy oproti článku
+
+- **Tag nemaže, jen připisuje odpověď pod něj** — vlákno zůstane v souboru
+  a v diffu; mazání je jen člověk, před commitem (grep na prefix).
+- **Nespouštět agenta ve smyčce nad soubory** (autonomní reakce = ztráta
+  kontrolního bodu). Místo toho explicitní příkaz „projdi tagy a vyjádři se".
+- **Max 1–2 tagy na kolo.** Deset tagů = deset změn ke společnému review =
+  nejasné, co odkud přišlo.
+
+## Varianty kam dát vlákno
+
+1. **Anotace jako komentáře v kódu** — nulová infrastruktura, funguje všude,
+   diff ukáže celou historii výměny. Nevýhoda: zaneřádí kód, hlídání ručně.
+   Dobré na krátké výměny u konkrétního místa.
+2. **Vedlejší soubor** (`file.notes.md` vedle zdrojáku, odkaz na symbol,
+   ne na číslo řádku) — kód čistý, vlákna libovolně dlouhá, .gitignore.
+   Dobré na dlouho se vlečoucí věci.
+
+## Otevřené otázky
+
+- Korekce agentových odpovědí („odpověď chci přepsat") — chat to řeší tím,
+  že je mimo kód; anotace v souboru to nemají kde. Varianta 1 to řeší
+  nejlíp (přepis = nová verze vlákna na místě), ale je potřeba vyzkoušet.
+- Vazba na symboly místo řádků u varianty 2 — jinak se odkazy rozbijí
+  při každém editu.

projects/ai/artifacts/handoff-skill.md

@@ -0,0 +1,77 @@
+# /handoff skill for Claude Code
+
+## My take
+
+Good idea. Rationale:
+
+- The handoff brief is the cheapest reliable carrier of context between
+  sessions, but it is written at the exact moment nobody wants to write it:
+  at a session boundary, from a bloated context, by hand.
+- A skill turns it into one word: `/handoff`. The effort argument against
+  "transfer via artifacts" disappears.
+- Skills follow the Agent Skills open standard (agentskills.io), so the same
+  SKILL.md works in Codex and other tools with a compatible loader.
+- One important design decision: the brief must be written **for the next
+  agent as the reader**, not as a human retrospective. That changes the
+  content: no narrative, no chronology — just state, decisions, and
+  constraints, in an order optimized for cold-context consumption.
+
+## Installation
+
+Pick a location by scope:
+
+| Scope | Path |
+|---|---|
+| Personal (all your projects) | `~/.claude/skills/handoff/SKILL.md` |
+| One repo (shareable, commit it) | `<repo>/.claude/skills/handoff/SKILL.md` |
+
+(`.claude/commands/handoff.md` is the older format and still works, but
+skills are preferred for new work.)
+
+Invoke with `/handoff`. The brief is rendered in the chat as a markdown
+block, ready to copy-paste. If you ask for a file, it saves to `HANDOFF.md`
+in the repo root (or a path you give).
+
+## SKILL.md content
+
+```markdown
+---
+name: handoff
+description: Format this session's key context as a copy-pasteable handoff brief for a fresh session or another agent. Use when the user asks for a handoff, wants to carry context over, or is about to /clear, compact or restart.
+disable-model-invocation: true
+---
+
+# Handoff
+
+Render this session's context as one fenced markdown block, ready to copy
+into a fresh session. The reader has the repo but no conversation history,
+so write only what the repo does not show: decisions and their reasons,
+what was ruled out and why, constraints the user set, what is left.
+No chronology, no code, no narrative. Omit empty sections. Mark anything
+you are not sure about with `(unverified)`.
+
+```markdown
+# Handoff: <task in one line>
+
+## Current state
+## Constraints
+## Decisions
+## Ruled out
+## Next step
+## Done when
+```
+```
+
+## Notes / tradeoffs
+
+- First draft was 3× longer (rules, per-section explanations, a review
+  procedure, file-save flow). Simplified after review: `(unverified)`
+  inline markers replace the separate review-callout procedure, and
+  everything that was merely obvious or speculative got cut — iterate
+  by adding lines only after real failures, not upfront.
+- `disable-model-invocation: true` keeps it manual — a brief is a session
+  boundary action, and auto-triggering mid-task would produce noise.
+- Output stays in chat by default; saving to a file is outside the skill
+  (ask for it ad hoc). The brief is disposable. Anything durable belongs
+  in existing stores: recurring mistake → CLAUDE.md/AGENTS.md, project
+  decision → project memory/decision log.

projects/ai/artifacts/ollama-model-capabilities.py

@@ -0,0 +1,31 @@
+#!/usr/bin/env python3
+"""List Ollama models on nvidia.hell:11434 with size + capabilities."""
+import json
+import urllib.request
+
+BASE = "http://nvidia.hell:11434"
+
+with urllib.request.urlopen(f"{BASE}/api/tags", timeout=10) as r:
+    tags = json.load(r)
+
+models = []
+for m in tags.get("models", []):
+    name = m.get("name")
+    size = m.get("size", 0)
+    # fetch capabilities via /api/show
+    req = urllib.request.Request(
+        f"{BASE}/api/show",
+        data=json.dumps({"model": name}).encode(),
+        headers={"Content-Type": "application/json"},
+    )
+    try:
+        with urllib.request.urlopen(req, timeout=10) as r:
+            show = json.load(r)
+        caps = show.get("capabilities", [])
+    except Exception as e:
+        caps = [f"ERR: {e}"]
+    models.append({"name": name, "size_gb": round(size / 1e9, 1), "capabilities": caps})
+
+models.sort(key=lambda x: x["size_gb"])
+for m in models:
+    print(f"{m['size_gb']:>6.1f} GB  {','.join(m['capabilities']):<40}  {m['name']}")

projects/ai/artifacts/ollama-toolcall-test.py

@@ -0,0 +1,373 @@
+#!/usr/bin/env python3
+"""Functional tool-calling test suite for local Ollama models (<10 GB, tools capability).
+
+10 scenarios per model, increasing difficulty, English-only prompts.
+
+  S1  direct call            explicit "use the tool", simple city arg
+  S2  implied call           no explicit tool instruction, model must infer
+  S3  tool selection         3 tools available, must pick get_weather
+  S4  context resolution     city referenced indirectly ("there") from context
+  S5  multiple parameters    city + unit, unit must be extracted from request
+  S6  no-tool restraint      answerable without tools -> must NOT call
+  S7  multi-call             two cities compared -> both calls expected
+  S8  result reasoning       use result to answer a yes/no derived question
+  S9  argument fidelity      city with diacritics must be preserved
+  S10 distractor selection   5 tools, must pick the non-obvious get_stock_price
+
+Per scenario: PHASE 1 (emit valid tool call) + PHASE 2 (use the returned result).
+Verdicts: PASS = 1, PARTIAL = 0.5, FAIL = 0. Prints each scenario result
+immediately (unbuffered). Usage:
+
+  PYTHONUNBUFFERED=1 uv run ollama-toolcall-test.py <model-name>
+"""
+import json
+import sys
+import time
+import unicodedata
+import urllib.request
+
+BASE = "http://nvidia.hell:11434"
+TIMEOUT = 120  # per request; abort the model run if exceeded
+
+MODELS = [
+    "lfm2.5-thinking",        # 0.7
+    "deepseek-v3",             # 2.0
+    "llama3.2",                # 2.0
+    "granite4",                # 2.1
+    "phi4-mini",               # 2.5
+    "nemotron-mini",           # 2.7
+    "phi4-mini-reasoning",     # 3.2
+    "mistral",                 # 4.1
+    "granite4:tiny-h",         # 4.2
+    "granite3.3",              # 4.9
+    "aya-expanse",             # 5.1
+    "qwen3",                   # 5.2
+    "granite4.1:8b",           # 5.3
+    "gemma4-uncensored",       # 5.3
+    "ornith",                  # 5.6
+    "qwen3.5-uncensored",      # 5.6
+    "ministral-3",             # 6.0
+    "qwen3.5:9b",              # 6.6
+    "qwen3.5",                 # 6.6
+    "mistral-nemo",            # 7.1
+]
+
+
+def strip_accents(s):
+    return "".join(c for c in unicodedata.normalize("NFD", s) if unicodedata.category(c) != "Mn")
+
+
+def trunc(s, n=200):
+    s = (s or "").replace("\n", " ").strip()
+    return s[:n] + ("…" if len(s) > n else "")
+
+
+LAST_TIMING = {}
+
+
+def chat(payload, timeout=TIMEOUT):
+    req = urllib.request.Request(
+        f"{BASE}/api/chat",
+        data=json.dumps(payload).encode(),
+        headers={"Content-Type": "application/json"},
+    )
+    with urllib.request.urlopen(req, timeout=timeout) as r:
+        return json.load(r)
+
+
+def fdef(name, description, properties, required):
+    return {"type": "function", "function": {
+        "name": name, "description": description,
+        "parameters": {"type": "object", "properties": properties, "required": required},
+    }}
+
+
+W_CITY = {"city": {"type": "string", "description": "City name"}}
+
+
+def weather_tool(unit=False):
+    props = dict(W_CITY)
+    if unit:
+        props["unit"] = {"type": "string", "enum": ["celsius", "fahrenheit"],
+                         "description": "Temperature unit for the result"}
+    return fdef("get_weather", "Get the current weather for a city", props, ["city"])
+
+
+def get_time_tool():
+    return fdef("get_time", "Get the current local time in a timezone",
+                {"timezone": {"type": "string", "description": "IANA timezone, e.g. Europe/Prague"}}, ["timezone"])
+
+
+def get_currency_tool():
+    return fdef("get_currency_rate", "Get the current exchange rate between two currencies",
+                {"from": {"type": "string"}, "to": {"type": "string"}}, ["from", "to"])
+
+
+def get_stock_tool():
+    return fdef("get_stock_price", "Get the current stock price for a company",
+                {"symbol": {"type": "string", "description": "Stock ticker symbol, e.g. GOOG"}}, ["symbol"])
+
+
+def send_email_tool():
+    return fdef("send_email", "Send an email to someone",
+                {"to": {"type": "string", "description": "Recipient email"},
+                 "subject": {"type": "string"}, "body": {"type": "string"}}, ["to"])
+
+
+def translate_tool():
+    return fdef("translate_text", "Translate a text to another language",
+                {"text": {"type": "string"}, "target_language": {"type": "string"}}, ["text"])
+
+
+def tool_result(city, **kw):
+    d = {"city": city}
+    d.update(kw)
+    return json.dumps(d)
+
+
+SCENARIOS = [
+    {   # 1 easy: explicit instruction, trivial extraction
+        "id": "S1", "name": "direct call",
+        "tools": [weather_tool()],
+        "messages": [{"role": "user", "content": "What is the current weather in Brno right now? Use the tool."}],
+        "expect_tool": "get_weather", "expect_args": {"city": "brno"},
+        "phase2": True,
+        "result": tool_result("Brno", temperature_c=18, condition="partly cloudy", wind_kmh=7),
+        "answer_any": ["18"],
+    },
+    {   # 2: no "use the tool" hint at all
+        "id": "S2", "name": "implied call",
+        "tools": [weather_tool()],
+        "messages": [{"role": "user", "content": "I'm about to head out. Can you check what the weather's like in Prague?"}],
+        "expect_tool": "get_weather", "expect_args": {"city": "prague"},
+        "phase2": True,
+        "result": tool_result("Prague", temperature_c=14, condition="overcast", wind_kmh=10),
+        "answer_any": ["14"],
+    },
+    {   # 3: pick the right tool out of 3
+        "id": "S3", "name": "tool selection",
+        "tools": [weather_tool(), get_time_tool(), get_currency_tool()],
+        "messages": [{"role": "user", "content": "Should I take an umbrella when going to work in Ostrava today?"}],
+        "expect_tool": "get_weather", "expect_args": {"city": "ostrava"},
+        "phase2": True,
+        "result": tool_result("Ostrava", temperature_c=12, condition="rain", wind_kmh=20, precipitation_prob="85%"),
+        "answer_any": ["umbrella", "rain"],
+    },
+    {   # 4: city only implied by conversation context
+        "id": "S4", "name": "context resolution",
+        "tools": [weather_tool()],
+        "messages": [
+            {"role": "user", "content": "My sister lives in Pardubice."},
+            {"role": "assistant", "content": "Nice! Pardubice is a lovely city. Is there anything I can help you with?"},
+            {"role": "user", "content": "What's the weather like there right now?"},
+        ],
+        "expect_tool": "get_weather", "expect_args": {"city": "pardubice"},
+        "phase2": True,
+        "result": tool_result("Pardubice", temperature_c=21, condition="clear", wind_kmh=5),
+        "answer_any": ["21"],
+    },
+    {   # 5: two parameters, second one from wording
+        "id": "S5", "name": "multiple parameters",
+        "tools": [weather_tool(unit=True)],
+        "messages": [{"role": "user", "content": "What's the weather in Vienna? I'd like it in Fahrenheit."}],
+        "expect_tool": "get_weather", "expect_args": {"city": "vienna", "unit": "fahr"},
+        "phase2": True,
+        "result": json.dumps({"city": "Vienna", "temperature_f": 64, "condition": "sunny", "humidity": "35%"}),
+        "answer_any": ["64"],
+    },
+    {   # 6: must NOT call any tool
+        "id": "S6", "name": "no-tool restraint",
+        "tools": [weather_tool()],
+        "messages": [{"role": "user", "content": "What is the capital of Germany?"}],
+        "no_call": True, "phase2": False,
+        "answer_any": ["berlin"],
+    },
+    {   # 7: two tool calls in one answer
+        "id": "S7", "name": "multi-call",
+        "tools": [weather_tool()],
+        "messages": [{"role": "user", "content": "Compare the current weather in Brno and Olomouc."}],
+        "multi_call": ["brno", "olomouc"],
+        "phase2": False,
+    },
+    {   # 8: answer a derived yes/no question from the result
+        "id": "S8", "name": "result reasoning",
+        "tools": [weather_tool()],
+        "messages": [{"role": "user", "content": "Is it too hot for a run in Plzen right now?"}],
+        "expect_tool": "get_weather", "expect_args": {"city": "plzen"},
+        "phase2": True,
+        "result": tool_result("Plzen", temperature_c=31, condition="sunny", humidity="40%"),
+        "answer_any": ["31"],
+    },
+    {   # 9: diacritics must survive argument extraction
+        "id": "S9", "name": "argument fidelity",
+        "tools": [weather_tool()],
+        "messages": [{"role": "user", "content": "What's the current weather in České Budějovice? Use the tool."}],
+        "expect_tool": "get_weather", "expect_args": {"city": "budejovice"},
+        "phase2": True,
+        "result": tool_result("Ceske Budejovice", temperature_c=23, condition="cloudy", wind_kmh=8),
+        "answer_any": ["23"],
+    },
+    {   # 10 hardest: non-obvious tool among 5, arg is a ticker not a city
+        "id": "S10", "name": "distractor selection",
+        "tools": [weather_tool(), get_time_tool(), get_stock_tool(), send_email_tool(), translate_tool()],
+        "messages": [{"role": "user", "content": "How are Google shares doing today?"}],
+        "expect_tool": "get_stock_price", "expect_args": {"symbol": "goog"},
+        "phase2": True,
+        "result": json.dumps({"symbol": "GOOG", "price_usd": 172.5, "currency": "USD", "change_pct": 1.2}),
+        "answer_any": ["172", "goog"],
+    },
+]
+
+
+def parse_args(tc):
+    """Return (name, args_dict) from a tool_call entry, tolerating str/dict args."""
+    fn = tc.get("function", {})
+    name = fn.get("name", "")
+    raw = fn.get("arguments", {})
+    if raw is None:
+        raw = {}
+    if isinstance(raw, str):
+        try:
+            raw = json.loads(raw)
+        except json.JSONDecodeError:
+            raw = None
+    return name, (raw if isinstance(raw, dict) else None)
+
+
+def args_ok(args, expected):
+    if not isinstance(args, dict):
+        return False, "arguments not a valid object"
+    for key, substr in expected.items():
+        val = str(args.get(key, ""))
+        if substr.lower() not in val.lower() or (substr.lower() not in strip_accents(val.lower()) and False):
+            if substr.lower() not in strip_accents(val.lower()):
+                return False, f"{key}={args.get(key)!r} (want substring {substr!r})"
+    return True, ""
+
+
+def answer_ok(answer, needles):
+    low = strip_accents(answer.lower())
+    return any(n.lower() in low for n in needles)
+
+
+def run_scenario(model, sc):
+    global LAST_TIMING
+    msgs = list(sc["messages"])
+    try:
+        r1 = chat({"model": model, "messages": msgs, "tools": sc["tools"], "stream": False})
+    except Exception as e:
+        print(f"PHASE1 ERROR: {e}")
+        return "ERROR"
+    LAST_TIMING = {
+        "load_ms": r1.get("load_duration") or 0,
+        "prompt_ms": r1.get("prompt_eval_duration") or 0,
+        "eval_ms": r1.get("eval_duration") or 0,
+    }
+    m1 = r1.get("message", {})
+    calls = m1.get("tool_calls") or []
+
+    # --- no-call scenario ---
+    if sc.get("no_call"):
+        if calls:
+            print(f"  called {calls[0].get('function', {}).get('name', '?')} despite no tool needed -> FAIL")
+            return "FAIL"
+        content = m1.get("content", "") or ""
+        ok = answer_ok(content, sc["answer_any"])
+        print(f"  no tool call: ok; answer: {trunc(content, 150)}")
+        return "PASS" if ok else "FAIL"
+
+    # --- multi-call scenario ---
+    if sc.get("multi_call"):
+        found = set()
+        names_ok = True
+        for tc in calls:
+            name, args = parse_args(tc)
+            if name != "get_weather":
+                names_ok = False
+            if isinstance(args, dict):
+                found.add(strip_accents(str(args.get("city", "")).lower()))
+        want = set(sc["multi_call"])
+        hit = want & found
+        verdict = "FAIL" if not calls else ("PASS" if hit == want else "PARTIAL")
+        print(f"  calls: {len(calls)}; cities: {sorted(found) or 'none'}; names_ok={names_ok}")
+        return verdict
+
+    # --- standard call scenario ---
+    if not calls:
+        print(f"  no tool_calls; content: {trunc(m1.get('content', ''), 180)}")
+        return "FAIL"
+    name, args = parse_args(calls[0])
+    print(f"  call: {name} {json.dumps(args, ensure_ascii=False) if args else calls[0]}")
+    p1 = "PASS"
+    if name != sc["expect_tool"]:
+        p1 = "PARTIAL"
+    else:
+        ok, why = args_ok(args, sc.get("expect_args", {}))
+        if not ok:
+            p1 = "PARTIAL"
+            print(f"  arg mismatch: {why}")
+    print(f"  PHASE1 -> {p1}")
+
+    if not sc.get("phase2"):
+        return p1
+
+    # --- phase 2: feed result back ---
+    msgs.append(m1)
+    msgs.append({"role": "tool", "name": sc["expect_tool"], "content": sc["result"]})
+    try:
+        r2 = chat({"model": model, "messages": msgs, "tools": sc["tools"], "stream": False})
+    except Exception as e:
+        print(f"PHASE2 ERROR: {e}")
+        return "ERROR"
+    answer = (r2.get("message", {}) or {}).get("content", "") or ""
+    p2ok = answer_ok(answer, sc["answer_any"])
+    print(f"  answer: {trunc(answer, 200)}")
+    print(f"  PHASE2 -> {'PASS' if p2ok else 'FAIL'}")
+
+    if p1 == "PASS":
+        return "PASS" if p2ok else "PARTIAL"
+    return p1 if p1 == "FAIL" else "PARTIAL"
+
+
+def main():
+    if len(sys.argv) < 2:
+        print(f"usage: {sys.argv[0]} <model-name>\nmodels (smallest first): {', '.join(MODELS)}")
+        sys.exit(2)
+    model = sys.argv[1]
+    if model not in MODELS:
+        print(f"unknown model {model!r}; known: {', '.join(MODELS)}")
+        sys.exit(2)
+
+    print(f"MODEL: {model} — {len(SCENARIOS)} scenarios, English prompts\n" + "=" * 70)
+    score, verdicts, t0 = 0.0, {}, time.monotonic()
+    aborted = False
+    for sc in SCENARIOS:
+        print(f"\n{sc['id']}  {sc['name']}")
+        try:
+            v = run_scenario(model, sc)
+        except KeyboardInterrupt:
+            v = "ERROR"
+        if v == "ERROR":
+            print("  -> aborting remaining scenarios for this model (no response in reasonable time)")
+            aborted = True
+        verdicts[sc["id"]] = v
+        score += {"PASS": 1.0, "PARTIAL": 0.5}.get(v, 0.0)
+        if v != "ERROR":
+            print(f"  => {v}")
+        if aborted:
+            break
+
+    dt = time.monotonic() - t0
+    print(f"\n{'=' * 70}\nSUMMARY {model}")
+    line = ", ".join(f"{sid}:{v}" for sid, v in verdicts.items())
+    print(line)
+    n = sum(1 for v in verdicts.values() if v != "ERROR")
+    print(f"SCORE: {score:.1f}/{len(SCENARIOS)}  ({n}/{len(SCENARIOS)} scenarios answered)")
+    t = LAST_TIMING
+    if t:
+        load = t.get("load_ms", 0) / 1e9
+        print(f"timing of last request: load {load:.1f}s, prompt {t.get('prompt_ms', 0)/1e6:.0f}ms, eval {t.get('eval_ms', 0)/1e6:.0f}ms (load only on first run of a model)")
+
+
+if __name__ == "__main__":
+    main()

projects/ai/artifacts/session-lifecycle-draft.md

@@ -0,0 +1,98 @@
+# Session lifecycle — DRAFT (rozpracováno postupně, finální návod až po dohodě)
+
+## Body 1–5 (shoda zdrojů z researchu 10.9.)
+Nový task = nová session; review ve fresh context; přenos mezi sessions artefakty;
+po 2 neúspěšných opravách restart; compact = pojistka, ne plán.
+
+---
+
+## 6. Vztahuje se „2 neúspěšné korekce → restart" i na plánování?
+
+**Ne na počet kol — na typ iterace.** U plánování se 6 kol může znamenat dvě
+naprosto různé věci:
+
+**Konvergující iterace** (zdravá):
+- každé kolo uzavře nová rozhodnutí a staré námitky se nevracejí
+- context roste o decision history — přesně to, co pro plánování chceme
+- ukončit ji = zahodit nashromážděné rozhodnutí, ne ušetřit
+
+**Kruhová iterace — anchor loop** (selhání):
+- opakuji **stejnou** námitku, model kosmeticky přepracovává vlastní draft
+- výstup nesleduje vstup; každá další korekce stejného typu nepřidává informaci
+
+**Signál je „stejná námitka podruhé", ne počet kol.** Zdůvodnění:
+
+1. Počet kol nedokáže odlišit konvergenci od smyčky — 6 kol konvergující
+   iterace je v pořádku, 3 kola smyčky jsou ztracený čas.
+2. Stejná námitka podruhé je **důkaz**, že výstup nesleduje vstup. Třetí korekce
+   stejného typu nemá žádnou novou informační hodnotu — jen přidává tokeny
+   mrtvých pokusů, kterými se model dál ukotví.
+3. V plánování chybí verifier. U kódu každý pokus narazí na realitu (build,
+   testy) a force korekci kurzu; u plánu je jediným „faktem" text, který model
+   sám napsal — reviduje se sám vůči sobě a kosmetika vypadá jako pokrok.
+   Proto je anchoring u plánování **silnější** než u kódu, ne slabší.
+
+**Praktika pro plánování:**
+
+1. Iterovat **v souboru plánu, ne v chatu.** Po každém kole se upraví soubor
+   (plán, tabulka scénářů); chat je jen médium. Soubor je single source of
+   truth — přežije kompakci i restart a nová session z něj může spustit
+   implementaci bez rekonstrukce z historie.
+   *(Naše extenze — Anthropic jen říká „plan file → fresh session na
+   implementaci"; iterovat přímo soubor plyne z mechaniky: soubor je imunní
+   vůči context rot.)*
+2. Námitka podruhé → stop → **kostru navrhnu sám** (tabulka scénářů, skeleton,
+   rozhraní) a model ji doplňuje. Lesson z agent-to-human-tools.md: rozhraní
+   navrhuje člověk, protože model je anchorovaný na svůj první draft a není
+   schopen ho opustit.
+3. Plán hotov → implementace **ve fresh session ze souboru plánu**
+   (Anthropic: „Once the spec is complete, start a fresh session to execute it.")
+
+## 7. „Přenos mezi sessions = artefakty" — jak to dělat snadno
+
+Artefakt není nová povinnost, ale věc, která v práci stejně existuje. Tři druhy:
+
+| Artefakt | Kdy vzniká | Co nese | Životnost |
+|---|---|---|---|
+| **Repo / kód / diff** | pořád | kompletní stav implementace | trvalá |
+| **Spec / plan soubor** | při plánování | zadání, constrainty, done-when | do konce úkolu |
+| **Handoff brief** | při ukončování session | rozhodnutí, vyloučené cesty, další krok | jednorázová |
+
+**Repo je hlavní artefakt.** Pro pokračování v kódu nepotřebuju vůbec nic
+přenášet: nová session si přečte kód. Historie chatu nenese hodnotu navíc —
+všechno, co v ní bylo smysluplného, je buď v kódu, nebo patří do briefu
+(rozhodnutí a vyloučené cesty **nejsou** v kódu vidět, proto brief existuje).
+
+**Handoff brief — kdo ho píše: model, ne já.** Low-effort postup na hranici
+session (před `/clear`, před ukončením práce):
+
+1. Jedna zpráva: „sepiš handoff: cíl, constrainty, padnutá rozhodnutí,
+   vyloučené přístupy a proč, soubory které se týkají, další krok."
+2. Uložit do souboru (tmp/plán/noty), 30 s review.
+3. `/clear`, nová session: „přečti <soubor>; úkol: <X>; hotovo když <Y>."
+
+Moje práce: jedna věta + 30 sekund review. (Anthropic o /clear říká „you write
+down what matters" — varianta s model-drafted briefem je naše zjednodušení;
+caveat: model píše brief s plným kontextem, tedy ve slabším stavu, proto to
+review. Zkrácená verze: klíčová rozhodnutí/vyloučené cesty si nadiktuju sám,
+model doplní stav souborů.)
+
+**Proč to není zbytečná práce:**
+- píše se **jednou na hranici session**, ne průběžně
+- je to pár vět, ne dokumentační projekt
+- po použití se brief zahodí; trvalé části odtékají do store, které stejně
+  vedu — rozhodnutí → memory.md, opakující se chyba → CLAUDE.md/AGENTS.md
+  (OpenAI: „when Codex makes the same mistake twice, update AGENTS.md")
+
+**Co se nedělá:** nepřesouvat historii chatu („prosím pokračuj"), nepsat
+retrospektivy, neduplikovat do souborů, co už je v kódu/diffu.
+
+**Mapping na současné nástroje:**
+- nanobot project skill už to dělá: memory.md = decision log, state.md =
+  handoff brief (activate = „přečti soubor a pokračuj")
+- Claude Code: plan file v repu + CLAUDE.md pro trvalá pravidla
+- Codex: AGENTS.md + skills
+
+## Otevřené otázky
+- Kde přesně vede hranice „related task" — dokumentace k hotové feature?
+  Anthropic: může zůstat (reread by byl dražší), ale jde o stejný úkol.

projects/ai/memory.md

@@ -1,3 +1,146 @@
 - 2026-09-02: Založen projekt: deník + hledání řešení pro AI témata (agenti, kódování s AI, LLM).
 - 2026-09-02: Incident „gpt 5.3 se zasekl na PH/PZ/TX z mobilu": rekonstruováno — finální odpověď byla kompletní a verzovaná; problém byl agent loop (guard bloky, retry smyčky, ~6-8 min). Model = glm-5.3:cloud (žádný gpt 5.3). Kanál na kvalitu vliv nemá.
 - 2026-09-02: Compaction: uživatel si vyžádal drastické zkrácení incident zápisu; detaily zahoz­deny, zachovány jen závěry.
+- 2026-09-08: Série měření na Solarflare X2/X4 (TCPDirect, C# knihovna). Claude Code navrhl měřicí setup, aplikace sockbench na měření, Claude spouštěl scénáře, ukládal a vyhodnocoval výsledky. Fungovalo.
+Pak cíl: převést proces na ruční spouštění skriptů (PowerShell) pod vlastní kontrolou. Claude zde selhává opakovaně: skripty zbytečně složité, moc parametrů, špatně čekal na dokončení test setu, testoval zbytečné věci. Zadání v plan modu se nedaří, výsledek stále špatný — frustrace, ztracený čas místo ušetřeného.
+Uživatelova diagnóza: nedokáže správně popsat zadání; buď málo informací, nebo špatný přístup. Zvažované cesty: napsat kostry skriptů sám s komentáři a nechat Claude dokodovat; lepší projektový dokument; úplně odpoutat se od současné verze a začít znovu. Hledá efektivní způsob práce.
+- 2026-09-08: Upřesnění diagnózy (Solarflare/sockbench): Claude si původně napsal runbook pro sebe — pro agenta byl ok, pro člověka nepoužitelný (moc kroků, moc složitosti). Skripty nebyly úplně špatné, ale měly tunu parametrů. Jádro problému: dvě různé cílové skupiny — agent snese libovolnou složitost, člověk potřebuje mnohem menší míru komplexity. Uživatel se o tom v plan modu snažil mluvit, přiblížil se, ale komunikace nestačila.
+- 2026-09-08: correction: „úplně znovu od nuly — ne" z minula bylo nedorozuměním. Uživatel tím nemyslel „znovu bez specifikace", ale nepoužít existující runbook a existující skripty jako základ — ty ho limitují a anchornují ho špatným směrem. Restart s jeho vlastní specifikací (tabulka scénářů + kostry) je v pořádku, jediné co ne: recyklace agent-runbooku.
+- 2026-09-08: Destilace postupu „převod agent-nástrojů na nástroje pro člověka" uložena jako artefakt: projects/ai/artifacts/agent-to-human-tools.md. Strukturovaný markdown: proč zjednodušení agent-nástrojů nefunguje (neviditelná hranice složitosti, ukotvení existující podobou, plan mode neřeší design), princip „rozhraní navrhuje člověk, model implementuje", 4krokový postup (čistý adresář → tabulka scénář→příkaz → kostry → dokódování těl) a pravidla pro zadání (čísla místo adjektiv, omezení v kódu ne v promptu, agent-runbook nepřevádět). Po vzájemné korektní diskusi: knowledge/ odmítnut, artefakt patří do projektu ai.
+- 2026-09-08: Rozbor článku „Don't Chat With Your AI. Mob With It." (Rodenas) + diskuse s Claude uložen jako artefakt: projects/ai/artifacts/file-based-agent-communication.md. Technikou je komunikace s agentem přes tagy v souborech místo chatu. Článková argumentace odmítnuta (latence ≠ GPU sloty; mob analogie obrácená; autonomní smyčka + mazání tagů = ztráta kontrolního bodu a prodloužení feedback loopu pro člověka). Použitelné jádro: anotace patří tam, kde je předmět anotace (pozice = kontext, jako TODO komentář), trvalost v diffu, tag se nemaže jen se připíše odpověď, max 1–2 tagy na kolo, explicitní spouštění místo autonomní smyčky. Otevřená otázka: jak korigovat agentovy odpovědi — kandidát varianta „vlákno jako komentáře v kódu" oproti vedlejšímu .notes.md souboru. Zájem uživatele o vyzkoušení.
+- 2026-09-09: Refactoring C# třídy s Claude: iterativní review smyčka a její selhání. Postup „review v nové session, opravy taky v nové session" vede k regresím — každá další session najde další „problémy", část z nich je reverz dříve odsouhlasených rozhodnutí, ne reálná chyba. Nová session totiž nevidí historii a znovu otevírá už uzavřené otázky.
+
+Závěr (podle kolegy, uživatel souhlasí): lepší je hybrid — **review v čisté nové session** (svěží pohled bez anchoringu na vlastní práci), ale **závěry vkládat zpět do původní session**, kde se provádějí i opravy. Původní session má kompletní historii, ví, která rozhodnutí padla a proč, a drží se jich — takže nevrací odsouhlasené změny.
+
+Souvisí s požadavkem na „čistý refaktor": ověření, že se chování zvenku vůbec nezměnilo, má být cílem review, ne vedlejším produktem.
+- 2026-09-09: Rozbor článku „LLM jako virtuální projektový tým" (Root.cz, Tonda) a jeho mapování na naše otevřená témata:
+
+- Článkové „přenášej artefakty, ne historii konverzace" = potvrzení našeho závěru z file-based-agent-communication.md i review smyčky. Formulace: kontext = artefakt + role + zadání, nic víc.
+- Naše review smyčka (čistá session na review, opravy v původní session s historií) je přesně článkový workflow; náš přídavek, který článek neřeší: kam závěry oponenta vracet — u nás původní session jako decision-history channel. Článek navíc: iterovaná oponentura (A→B→A/C→B) a různé providery pro procesní nezávislost.
+- Aplikace na kód: persony s omezeným mandátem (security, API konzument, ops, výkon) místo generického „udělej review" — řeší regresní problém, že každá nová session reverzne odsouhlasená rozhodnutí; omezený mandát nedovolí otevírat usazené otázky mimo scope.
+- „Z nápadu hypotéza" = naše „čísla místo adjektiv" z agent-to-human-tools.md. Stage-Gate přenositelný na testy: gates definované předem = co chybělo u Solarflare scénářů.
+- Článek ospravedlňuje strukturu project skill (decision log, živý stav). Nový nápad: explicitní registr předpokladů — seznam neověřených věcí, které držíme za pravdu, s dohledatelností závislostí.
+- 2026-09-10: Návod „session lifecycle" (kdy zůstat ve stejné session vs. zahájit novou) uložen jako artefakt session-lifecycle-guide.md. Klíčový test: potřebuje další krok historii rozhodnutí (stejná session) nebo svěží pohled (nová session)? Zkratky: chybová smyčka → nová session; po kompakci → radši nová session nad soubory než faded recollection. Hybrid pattern z 9.9. (review v čisté session, opravy v původní) zobecněn jako hlavní vzorec + doplněny mechaniky (anchoring, lost in the middle, kompakce je ztrátová).
+- 2026-09-10: correction: Artefakt session-lifecycle-guide.md z 10.9. byl předčasný — návod jsme ještě neudělali, to teprve probereme. Smazán. Nejdřív research online zdrojů (Anthropic + další), teprve pak závěry a návod.
+- 2026-09-10: Research „kdy stejná vs. nová session" — probrány online zdroje, než se udělá návod:
+
+1. Anthropic blog „Using Claude Code: session management and 1M context" (Thariq Shihipar): hlavní pravidlo „new task = new session". Každý turn je branching point s 5 volbami: continue / rewind / clear / compact / subagent. /compact = lossy, model summarizuje, lze řídit hintem; špatný autocompact vzniká, když model neumí předpovědět směr práce — a při kompakci je model ve svém nejslabsším bodě (context rot). /clear = člověk si sám napíše, co má přežít. Subagent na chunky, kde potřebuju jen závěr.
+2. Anthropic „Best practices for Claude Code" (docs): po 2 neúspěšných korekcích → /clear + lepší prompt; spec → implementace ve fresh session; review ve fresh context (Writer/Reviewer pattern); kitchen sink session jako antipattern.
+3. Anthropic „Effective context engineering for AI agents": context rot napříč všemi modely, „attention budget", 3 techniky pro long-horizon: compaction (ztrácí detaily), structured note-taking (NOTES.md — perzistentní paměť mimo window), sub-agents (čistá okna, vrací jen destilát). Hybridní přístup Claude Code: CLAUDE.md dopředu, zbytek JIT.
+4. Chroma „Context Rot" (research, 18 modelů): degradace nastává i na jednoduchých úlohách při konstantní složitosti, non-uniformně, s distraktory hůř; NIAH to maskuje. Zdroj termínu context rot.
+5. OpenAI Codex best practices: „one chat per coherent unit of work"; „using one chat for an entire project" je v seznamu častých chyb; /fork, /compact, subagents, AGENTS.md/skills pro přenos mezi sessions — konvergentní s Anthropic.
+
+Špatný zdroj: techbytes.app „complete engineer's guide" = AI slop (generická marketingová vata bez reálného obsahu). Lesson: sekundární „complete guide [2026]" weby ignorovat.
+
+Shoda napříč zdroji: nová session při novém úkolu, review ve fresh context, po chybové smyčce restart s lepším promptem, přenos mezi sessions = artefakty (spec, AGENTS.md, NOTES.md), ne historie chatu. Návod teprve budeme skládat.
+- 2026-09-10: Draft návodu session-lifecycle (draft, ne finál) — odpovědi na otázky uživatele:
+
+1. Plánování vs pravidlo „2 neúspěšné korekce": signál není počet kol, ale stejná námitka podruhé. Konvergující iterace (nová rozhodnutí, staré námitky se nevrací) je zdravá — decision history je přesně to, co plánování potřebuje. Anchor loop: opakuju stejnou námitku, model kosmeticky přepracovává vlastní draft. Důvod, proč anchoring u plánování silnější než u kódu: chybí externí verifier — jediným faktem je modelův vlastní text, reviduje sám sebe, kosmetika vypadá jako pokrok. Praktika: iterovat v souboru plánu ne v chatu (náš dodatek k Anthropic „spec → fresh session implementace"); stejná námitka 2× → stop → kostru navrhuje člověk (lesson z agent-to-human-tools).
+
+2. „Přenos = artefakty" konkretizace: 3 druhy — repo/diff (hlavní, nese celý stav implementace, nic přenášet nemusím), spec/plan soubor (při plánování), handoff brief (jen na hranici session: rozhodnutí + vyloučené cesty — to nejsou vidět v kódu). Brief píše MODEL na jednu žádost, já jen 30s review — moje práce jedna věta. Trvalé části odtékají do store, které stejně vedu (rozhodnutí → memory.md, opakovaná chyba → CLAUDE.md/AGENTS.md). Nepřenášet: historii chatu, retrospektivy, duplicity kódu.
+
+Draft uložen: projects/ai/artifacts/session-lifecycle-draft.md. Otevřená otázka: hranice „related task" (dokumentace k hotové feature — Anthropic nechává intuici).
+- 2026-09-10: Nápad uživatele: /handoff skill pro Claude Code, který sepíše handoff brief pro dalšího agenta. Zhodnoceno jako dobrý (odstraňuje hlavní argument proti „přenos artefakty" — práci navíc na hranici session) a připraven jako artefakt: projects/ai/artifacts/handoff-skill.md (anglicky, instalační cesty personal/project, SKILL.md obsah v markdown fence).
+
+Klíčová designová rozhodnutí: (1) brief je psaný pro čtenáře-agenta se ZERO historií — ne retrospektiva pro člověka: žádná chronologie ani narativ, jen stav+rozhodnutí+vyloučené cesty; neduplikovat repo (reader si přečte kód/diff); nejcennější sekce „Ruled out" — brání dalšímu agentovi chodit do mrtvých endů. (2) disable-model-invocation: true — session boundary akce, ne auto-trigger. (3) user zůstává v loopě jako fact-checker (model píše brief z plného, tedy degradovaného kontextu — rule 5: „if not sure it was decided, mark as open"). (4) Brief je jednorázový; trvalé části odtékají do CLAUDE.md/AGENTS.md/decision logu. Skills = Agent Skills open standard (agentskills.io), takže stejné SKILL.md funguje i v Codexu.
+- 2026-09-10: Úprava /handoff skillu po review uživatele: default output je markdown blok v chatu ke zkopírování, NE soubor. Soubor jen na explicitní požádání (default HANDOFF.md v repo root). Důvod: brief je jednorázový, soubor bez čtenáře je clutter; navíc paste funguje i tam, kde target agent nemá přístup k souboru (jiný stroj, jiný nástroj). Upravena description (bez "side-effect: writes a file"), Procedure (render do chatu → unsurity callout → file jen on request → navrh fresh prompt) a Notes/tradeoffs.
+- 2026-09-10: Zjednodušení /handoff skillu na návrh uživatele: 3x kratší verze (jeden akapát pravidel + samotná kostra šablony v fenced markdown bloku, bez Rules/Procedure sekcí). Co zůstalo: co psát (jen to, co repo neukazuje), co nepsat (chronologie, kód, narativ), (unverified) markery, kostra sekcí. Co vypadlo: Goal sekce (redundantní s titulkem), per-section vysvětlení, review procedura jako proces (nahrazeno (unverified) inline), file-save flow. Souhlasím — původní verze vysvětlovala věci, které model umí implikovat z šablony. Lessons: skill = šablona + constrainty, ne tréninkový dokument; iterovat přidáváním řádků po reálných selháních, ne upfront.
+- 2026-09-10: Self-analysis (na dotaz uživatele „proc jsi sám nevytvořil minimalistickou verzi?"): tři příčiny přepsání /handoff skillu. (1) Psal jsem pro špatného čtenáře — skill čte model, který potřebuje šablonu výstupu + constrainty, ne tréninkový dokument; defaultl jsem na dokumentační styl, protože většina mých artefaktů je pro člověka. Ukázková šablona > popis šablony. (2) Optimalizoval jsem na vypadání důkladně (Rules/Procedure jako zviditelněné uvažování) místo na funkci — uvažování patří do konverzace, ne do artefaktu. (3) Chyběl test „vyrobí tohle spolehlivě dobrý brief?", který se ověřuje použitím a ořezáváním, ne dodáním plné verze bez jediného běhu. Paradox: vlastní rule 4 skillu („be specific, not complete") jsem v samotném skillu porušil. Společný jmenovatel: rozhodnutí podle spotřebitele výstupu, ne podle vlastních zvyků. Diagnostika zrcadlová k Solarflare: tam runbook pro agenta místo člověka, tady pro člověka místo agenta. Pravidlo: před sepsáním skillu určit, kdo ho čte v momentě použití, a psát pro něj.
+- 2026-09-10: Prompting recept (na dotaz uživatele „jak to příště zadat, abych dostal lepší výstup?"): pro skládání skillů/artefaktů zadat 4 věci, které mě vedly k přepsání /handoffu: (1) kdo čte výstup v momentě použití (model vs člověk), (2) ukázka/kostra cílové podoby — „chci tohle, jen to napiš pořádně", (3) constraint na délku — „nejkratší verze, která funguje", (4) požadavek na ukázku použití („ukaž výstup na reálném příkladu") — tím se spustí test místo speculativního dodání plné verze. Poznámka pro mě: i bez zadání bych měl (1) a (4) udělat sám; (2) a (3) jsou legitimní požadavky na uživatele, protože definují chuť výstupu.
+- 2026-09-10: correction: Položku (1) „kdo čte výstup" z prompting receptu stahuji — u skillů plyne ze samotné definice (soubor pro model v momentě použití), není to legitimní zadání od uživatele, ale moje povinnost. Skutečná příčina: nezapátrání targetu PŘED psaním; default dokumentačního stylu vyhrál, protože čtenář nebyl první určující otázkou. Recept zredukován na 2 položky od uživatele (ukázka/kostra cílové podoby, constraint na délku) + 2 položky moje (čtenář z definice typu souboru, ukázka výstupu na reálném příkladu).
+- 2026-09-11: OpenWebUI zakázáno (2026-09-12) — žere sílně paměť a občas zasekne celý server. Jako náhradu chci vyzkoušet LibreChat, konkrétně self-hosted Docker variantu dle oficiální dokumentace:
+
+https://www.librechat.ai/docs/local/docker
+- 2026-09-11: LibreChat research done — navrh postupu spusteni pres rootless podman + systemd Quadlet, artefakt: projects/ai/artifacts/librechat-podman/ (README + librechat.network + librechat.container + librechat-mongodb.container + librechat-meilisearch.container). Minimal stack api+mongo (RAG/vectordb/admin-panel vynechany kvuli RAM — duvod odstraneni OpenWebUI). MONGO_URI/MEILI_HOST nutno prepsat na DNS jmena kontejneru (quadlet sit), trvale CREDS_KEY/CREDS_IV/JWT secrets. Quadlet zvolen nad generate systemd (deprecated) a nad podman-compose-oneshot (systemd nevidi kontejnery). Rootless + linger, port 3080. Naseptany plan: nasadit na server (ktery?), pripojit Ollama/litellm endpointy pres librechat.yaml.
+- 2026-09-13: - Zjišťování tool-calling schopností Ollama modelů na `nvidia.hell:11434` — jak ověřovat a co metadata neříkají:
+
+**Metoda:** `GET /api/tags` (seznam modelů + `size`) a pro každý model `POST /api/show` → pole `capabilities` (např. `["completion","tools","thinking","vision","embedding","insert","audio"]`). Kombinace těchto dvou endpointů dá kompletní tabulku model × velikost × schopnosti (skript: `workspace/tmp/list_ollama_models.py`, lze přesunout do artifacts).
+
+**Co `capabilities` je a není:** je to deklarace odvozená z Modelfile/manifestu modelu — Ollama tak *inzeruje* model jako tool-capable. Není to funkční test: neznamená to, že model vrátí validní `tool_calls` v odpovědi na `POST /api/chat` se `tools` v requestu. Metadata ⇒ kandidáti; funkční test ⇒ skutečná podpora.
+
+**Zásek: `qwen3-embedding` hlásí `tools` v capabilities, ale je to embedding model** — capabilities u něj nelze brát doslova, vždy křižovat s rodinou modelu.
+
+**Zjištěné výsledky (2026-09-12):** 57 modelů na instanci; lokálních s `tools` pod 10 GB cca 24 (nejmenší `lfm2.5-thinking` 0.7 GB, největší `gemma4`/`gemma4:e4b` 9.6 GB). `:cloud` modely mají size 0 GB (pointer na Ollama Cloud, neběží lokálně — do kritéria velikosti na disku nepatří). `gemini-3-flash-preview:cloud` vrací `POST /api/show` HTTP 410 Gone — mrtvý pointer, Ollama Cloud model stáhla.
+
+**Otevřené:** funkční test tool callingu (reálný `tools` request na každý kandidát a ověření validního `tool_calls` v odpovědi) ještě neproveden — nabídka visí.
+- 2026-09-13: Funkční test tool callingu lokálních Ollama modelů na `nvidia.hell` dokončen (18 modelů, 10 scénářů, anglické prompty).
+
+**Skript:** `projects/ai/artifacts/ollama-toolcall-test.py` — 10 scénářů rostoucí obtížnosti (S1 direct call, S2 implied call, S3 tool selection ze 3, S4 context resolution, S5 více parametrů, S6 no-tool restraint — NESMÍ volat, S7 multi-call dvě volání, S8 result reasoning, S9 diakritika v argumentu, S10 distractor selection z 5 nástrojů). Každý scénář 2 fáze: vyslat správný tool call + zpracovat vrácený výsledek. Spouští se per model: `PYTHONUNBUFFERED=1 uv run ollama-toolcall-test.py <model>`. Přísný parser (odmítl vnořené arguments u nemotronu — reálný klient unwrap nedělá).
+
+**Čisté 10/10:** granite4.1:8b (5.3 GB, 26s, nejlepší balance), lfm2.5-thinking (0.7 GB, 27s — pozor, 1B model, slabá sémantika, ale mechanika solidní), ministral-3 (6.0 GB, 27.5s, nejrychlejší eval ~332ms), ornith (5.6 GB, 46s), qwen3.5:9b (6.6 GB, 73s), qwen3 (5.2 GB, 89s — pomalý, thinking model).
+
+**Selhání podle vzorců:**
+- Over-eager calling (S6 fail — volá i když nemá): deepseek-v3, llama3.2 (jinak 9/10).
+- S7 multi-call bug (jen jedno volání z dvou): granite4 (9.5/10), granite4:tiny-h (8/10).
+- Prázdné odpovědi/args: granite4:tiny-h (S3), granite3.3 (S7.5/10 — S6 odpověděl prázdný text, S3 prázdné arguments).
+- Iniciativa (umí volat jen na explicitní pokyn, jinak čeká/odpovídá textem): mistral-nemo (7/10 — S4/S8 „Shall I proceed?", S8 vrátil giphy GIF link), mistral (5/10 — při implied call vypíše JSON volání jako text a **halucinuje výsledek**, S6 odpověděl voláním get_weather s city=Berlin).
+- Template mismatch (tool call jako plaintext, syrové speciální tokeny): phi4-mini (1.5/10), phi4-mini-reasoning (netestovatelný — reasoning CoT tolik zpomalí, že ~3 min bez odpovědi).
+- Vnořené arguments (`{"type":..., "arguments":{...}}` místo přímých parametrů — sémanticky správně, formálně rozbité pro standardního klienta): nemotron-mini (5.5/10), dřív i aya-expanse.
+- Sejmuly server (memory watchdog na nvidia.hell zabil llama-server — `Remote end closed connection`): aya-expanse (5.1 GB, hned na S1), qwen3.5 (6.6 GB, na S10 s 5 nástroji; do S9 byl 9/9 PASS, qwen3.5:9b S10 ale zvládl — rozdíl mezi tagy nebo náhoda v načítání).
+- Vynechané dle zadání uživatele: gemma4-uncensored, qwen3.5-uncensored; gemma4/gemma4:e4b (9.6 GB) dřív sejmul server, scope ukončen u mistral-nemo (7.1 GB).
+
+**Poznatky pro budoucí testy:**
+1. Jeden prompt nestačí — s českým promptem lfm2.5-thinking failoval na S1 (city=„Berlin"), s anglickým 10/10. Malé modely rozhoduje jazyk promptu, ne schopnost.
+2. S6 no-tool restraint je filtr, který vypadlo víc modelů než kterákoli jiná kategorie.
+3. Více nástrojů v promptu = vyšší paměťové nároky = watchdog kill. Testovat vícenástrojové scénáře jen u finálních kandidátů.
+4. Rodinné vzorce: granite = disciplína (S6 umí), qwen = spolehlivý tool calling, phi4 = rozbitý, mistral rodina = problém s iniciativou.
+5. Čas v summary skriptu je wall-clock celého běhu včetně prvního načtení modelu; `load_duration` z API se vypisuje zvlášť (load>0 jen při prvním requestu).
+
+**Doporučení pro agenta / tool use:** granite4.1:8b (nejlepší balance), ministral-3 (nejrychlejší), qwen3 (spolehlivost, pomalejší).
+- 2026-09-13: Cena/výkon srovnání plných desítek + rozhodnutí testovat finální kandidáty doplněk: uživatel si vybral tři finalisty (lfm2.5-thinking, granite4.1:8b, ministral-3), lfm vypadá nejlépe (nejmenší velikost + rozumný čas). Domluveno: na finalisty pustím **náročnější sadu testů** pro lepší rozlišení — vstupní 10 scénářů už je plní neseparuje (všichni 10/10).
+- 2026-09-13: Uživatelova zkušenost: **Ollama na nvidia.hell je výrazně nestabilní** — padá, když něco nezvládne (neznámý request, špatně zvládnutý model/template) nebo když přetíží stroj (paměť). Pro uživatele **v praxi nepoužitelné**; je z toho dost zklamaný.
+
+Koreluje s dřívějšími nálezy z tool-call testů (2026-09-12/13), kdy nestabilita nebyla ojedinělá, ale systémový vzorec:
+- Memory watchdog na nvidia.hell opakovaně zabíjel llama-server (`Remote end closed connection`) — sejmul ho aya-expanse (hned na S1), qwen3.5 (na S10 s 5 nástroji), dřív i gemma4/gemma4:e4b (9.6 GB).
+- Více nástrojů v promptu = vyšší paměťové nároky = watchdog kill. Pády nejsou náhodné — spouští je kombinace velkého modelu + většího kontextu.
+- phi4-mini-reasoning: reasoning CoT tolik zpomalí, že ~3 min bez odpovědi — Ollama se nezachytí ani graciozně.
+- gemini-3-flash-preview:cloud vracel HTTP 410 Gone — mrtvý cloud pointer v instanci.
+
+Závěr uživatele: současný stav (modely pod 10 GB na této GPU instanci) není použitelný pro reálný provoz, jen pro testy. Otevřené otázky pro případné hledání řešení: stabilizace Ollama serveru (limit paměti per model, OLLAMA_MAX_LOADED_MODELS, auto-restart), alternativní runtime (llama.cpp server přímo, vLLM), nebo kapacitnější hardware.
+- 2026-09-13: Research alternativ k Ollama (uživatel: nestabilita na nvidia.hell je v praxi nepoužitelná). Root cause potvrzen: watchdog killy = OOM na RAM, llama-server je stejně llama.cpp — problém je Ollamina heuristika offloadingu/kontextu, ne engine sám. Alternativy ověřeny z více zdrojů (codersera, local-llm.net, inventivehq, r/LocalLLaMA thread k postu „Friends Don't Let Friends Use Ollama", duben 2026): (1) llama.cpp llama-server + llama-swap — konsensus komunity, OpenAI-compatible API, hot-swap modelů, explicitní -c/-ngl kontrola → doporučeno uživateli; (2) vLLM — pro multi-user serving, na RTX 4060 tight (safetensors, KV cache overhead), odloženo; (3) LM Studio/Jan — zavrhnuté (Electron, closed source); (4) zůstat na Ollama + hardening (OLLAMA_MAX_LOADED_MODELS=1, systemd Restart/MemoryMax) — fallback. Čeká se na rozhodnutí uživatele, nabídka přípravy llama-swap yaml + systemd unit + litellm wiring.
+- 2026-09-14: Tool llmfit — poznámka z článku uloženého přes /bookmark (Medium, Data Science Collective, Anubhav, 5 dní zpět; fulltext v db/bookmark.sqlite, bookmark #1):
+
+- **llmfit** = CLI tool (brew install llmfit, binárky na releases page), projde ~13k modelů a ohodnotí, co se vejde do RAM/VRAM na daném stroji + odhad tokens/s.
+- **Fit je spolehlivý** — je to aritmetika (parametry × bits ÷ 8 + context cache), kterou si může každý spočítat sám. Článek: „the arithmetic behind it is arithmetic you can check yourself".
+- **Tokens/s je guess** — vzorec memory bandwidth ÷ model size × konstantní efficiency factor 0.55 (nikdo nevypočítal, ručně zvoleno, ověřeno na 3 mašinách, stejné pro všechny karty). Deklarovaná 30% error band, reálně až 2x off (quoted 337 → measured 16). Počítá proti celkové VRAM karty, ne proti volné.
+- **Klíčové pravidlo čtení**: vedle čísla je label zdroje (measured vs formula) — formule = ceiling, nikdy reálný výkon. Katalog má jen 1412 reálných měření vs ~13k modelů.
+- Další příkazy: `llmfit info "<model>"` (odkud číslo přišlo), `llmfit plan` (jaký HW model potřebuje), `llmfit bench` (reálné měření 3 inference passes — tohle nahrazuje odhad).
+- Skórovací heuristika je zastaralá — kvalita se dědí podle nejdelšího rozpoznaného prefixu rodiny, tabulka má 20 řádků, takže qwen3.6/3.8 dědí skóre po starších verzích → často doporučuje zastaralé modely.
+- Relevantní pro náš kontext: potvrzuje naši zkušenost z tool-call testů, že tokens/s a výkon závisí na loaderu, ne jen na HW (13.69 vs 4.51 tok/s pro tentýž 4-bit model na stejné kartě, jiný engine). Alternativa pro sizing: llama-fit-params z llama.cpp — čte volnou paměť v reálném čase, říká, co musel ořezat.
+- 2026-09-14: Zhodnocení článku „A global CLAUDE.md and its best pieces" (Reza Rezvani, Medium, 2026-09-06) — global CLAUDE.md jako kontrakt s modelem, 8 pravidel, ~130 řádků.
+
+**Co už máme:** surgical changes, minimal code, escalate jen u nevratných akcí, „green není důkaz" — vše už v AGENTS.md skoro doslova. Článek = potvrzení, ne novinka.
+
+**Přínosné pro nás:**
+- Decay mechanism: chyba 1× → řádek s datem do lessons-logu, 2× → do pravidel, po 90 dnech bez výskytu → demotion zpět do logu. Naše AGENTS.md/SOUL.md jen rostou; compact-memory řeší MEMORY.md, ne soubory pravidel. Kandidát na heartbeat task nebo rozšíření compact-memory.
+- „Každé pravidlo pojmenovává konkrétní selhání" — test před přidáním řádku; píšeme pravidla i spekulativně.
+- Closing report per acceptance criterion, silence = not met — silnější než naše „neohlašuj splnění bez toolu"; kryje vynechaný krok v reportu (omission is not lying).
+- Prose rule broken twice → hook, konvence [hook] tagu — potvrzení našeho exec guard přístupu.
+
+**Pro uživatele přímo:** Prompt 1 (merge CLAUDE.md template s inventářem prostředí) a Prompt 6 (quarterly trim) použitelné v Claude Code na devlin.hell.
+
+**Odmítnuto:** kopírovat celý soubor (polovina řádků specific pro autorův stroj); článek je anekdotický, bez měření.
+- 2026-09-14: Zhodnocení článku „Frontier AI: Claude Code and Codex Still Use grep. Why?" (Stéphane Derosiaux, Level Up Coding / Medium, ~2026-09) — proč frontier agenti místo AST/LSP/grafů/embeddings používají rg, find, cat.
+
+**Hlavní zjištění autora:**
+
+- **Discovery vs. navigation vs. verification.** Klíčová myšlenka: LSP/AST je skvělý, jen když už agent ví, co hledá (symbol `PaymentRetryHandler`). Při otevřené otázce („co způsobuje duplicitní platby?") musí agent nejdřív objevit slovník problému — retry, idempotency, webhook… — a k tomu je textové hledání nejlepší nástroj. Pipeline: grep = discovery, LSP/AST = navigation, compiler/testy/runtime = verification. grep je začátek, ne celý workflow.
+- **Kód je malá část repa.** Repo = kód + YAML, Terraform, Helm, SQL, markdown, ADR, migrace, feature flags, config. Jeden `rg "PAYMENT_TIMEOUT"` najde zdroj + test + helm values + README + migration notes — jedním dotazem rekonstruuje chování + config + historii + očekávání testů. Code graph je jen jedna projekce systému.
+- **Strukturované nástroje mají model boundary.** LSP/AST vidí jen statické symbolické relace; nevidí reflection, DI, makra, dynamické importy, plugin loading, dispatch z configu, SQL stringy, Kafka topicy. `Class.forName(config.get("processor"))` — call graph je neúplný, text/config prozradí skutečnou hranu. grep ukazuje hrany, které žijí mimo model nástroje.
+- **Negative evidence.** Nula výsledků v `rg` = silný důkaz o repu. U indexované abstrakce může nula znamenat cokoli (neindexováno, nevyřešeno, generováno jinde, špatný workspace). Agent potřebuje nástroje, kde absence je signál, ne hluchá místa middlewaru.
+- **grep = univerzální fallback.** Stejné primitivy fungují v Javě, Rustu, Terraformu, SQL i mixed monorepu. LSP per jazyk (jdtls, rust-analyzer, gopls, pyright, tsserver, clangd) = instalace, indexace, udržování middlemana. Harness je lepší s primitivy se stabilní sémantikou napříč repozitáři.
+- **Kompozice > velký tool vocabulary.** Malá shell slovní zásoba (rg, find, sed, head, xargs, git log -S) se skládá do obrovského prostoru dotazů a je masivně v trénovacích datech. Oproti 20+ úzkých specializovaných toolů (find_symbol, find_references, find_callers…). Kompoziční primitivum > inteligentnější ale užší tool.
+- **Trénink je jen půl vysvětlení.** Modely jsou výborné v shellu (GitHub, Stack Overflow, tutorials), ale to nevysvětluje, proč grep zůstává *architektonicky* užitečný — to dělají výše uvedené důvody.
+- **Repo není správná jednotka.** Systém žije napříč kódem, configem, infrastrukturou, runtime chováním, datovými toky, schématy, ownershipem a business pravidly (příklad: POST /payments → PaymentService → Kafka topic → consumer → DB tabulka → PCI policy → tým). Budoucnost: kombinace lexikálního + strukturálního + runtime pohledu v jednom modelu systému („system graph"), ne file navigation „stylem 2000s".
+
+**Relevance pro nás:** článek je přesně o našem denním chodu (harness design, tool vocabulary, guard proti exec). Hlavní lessony:
+- U nanobot toolů držet primitiva kompoziční (read/grep/exec) místo trendu „20 specializovaných toolů" — potvrzuje současnou architekturu.
+- Negative evidence jako designové kritérium toolu: výsledek musí být jednoznačně interpretovatelný, žádný fallibilní middleman.
+- grep/rg nejsou legacy z tréninku, ale strukturálně správná volba pro fázi discovery — relevantní pro debaty o embeddings/indexech (náš wiki embeddings: full reindex při změně enginu, index = middleman s boundary).
+- 2026-09-14: correction: dnešní dva zápisy (výuková session o RTX 4060 Ti a zpětná vazba na ni) byly omylem oříznuty z paměti — uživatel chtěl smazat jen artifact soubor, paměť ponechat. Obnoveno v plném znění:
+
+[obnovený zápis 1] Výuková session: uživatel chce rozumět hardwarové vrstvě své RTX 4060 Ti 16GB — výpočetní jednotky (SM/CUDA/tensor cores), data path RAM→VRAM→jednotky, rozdíl inference vs trénink, memory-bound decode. Motivace: lépe chápat chování Ollamy na nvidia.hell (OOM killy watchdogu, layer offload, limity tok/s dle bandwidth). Klíčové spojitosti: 288 GB/s bandwidth = horní limit decode tok/s, KV cache roste s kontextem (koreluje s watchdog killy). Artifact soubor později na žádost uživatele smazán.
+
+[obnovený zápis 2] Zpětná vazba na výukovou session o RTX 4060 Ti: první verze byla odmítnuta — příliš "hop", hromada spec-čísel místo mechanistického vysvětlení. Uživatel chce proces: co se skutečně počítá v transformeru, jak interní jednotky (CUDA core vs tensor core mechanicky) fungují a kde se zapojují, detailní inference vs trénink průchod. Lesson: u výukových dotazů tohoto typu -- mechanistický průchod, ne spec tabulky.
+- 2026-09-15: - Zkušenost s navrhováním skillů v nanobotu: výsledky jsou dost žalostné — kostra není špatná, ale nanobot nedohledá různé detaily a problémy tak, jak je to pak udělá Claude Code. To je důvod, proč všechny zásadní opravy a nové skilly dělá uživatel v Claude Code. Nanobot plánovač jde ale točit a ladit — sám odchytí plno chyb a doladí se k uživatelově spokojenosti (příklad: skill /usage). Uživatelův rozbor: není to úplně chyba modelu, který nanobot používá, a asi ani ne nanobota samotného — spíš to je dáno tím, jak je nanobot koncipovaný.
+- 2026-09-15: - Rozbor, proč je navrhování skillů v nanobotu slabé (uživatel přímo): (1) nanobot je s řešením moc rychle hotov — žádný důsledkový průzkum po prvním návrhu, (2) chybí plánovací mód, kde uživatel může komentovat, co se mu nelíbí, dřív než se něco implementuje, (3) nanobot je málo kritický ke svým vlastním řešením. Odtud workflow: návrh/ladění plánu s nanobotem (iterativně, /usage jako důkaz, že to jde), finální implementace v Claude Code.

projects/ai/state.md

@@ -3,7 +3,27 @@
 ## Otevřená témata
 - Při hlášení nestabilit ověřit reálný model/preset (session metadata ho nezaznamenávají).
 
+## Nápady k pozlatejšímu použití — pozastaveno, neimplementovat
+
+Zdroj: Rezvani — „A global CLAUDE.md and its best pieces" (zhodnocení v memory.md 2026-09-14):
+- **Decay mechanism pro pravidla** — 1. výskyt chyby → datovaný řádek do lessons-logu, 2. výskyt → pravidlo do AGENTS.md/SOUL.md; po 90 dnech bez výskytu demotion zpět do logu. Kandidát na heartbeat task nebo rozšíření compact-memory (ten dnes řeší jen MEMORY.md).
+- **Closing report per acceptance criterion, silence = not met** — každé kritérium dostane verdict splněno/nesplněno s evidencí session; mlčení o kroku = nesplněno. Kryje vynechaný krok v reportu.
+- **Test před přidáním pravidla** — každé pravidlo musí pojmenovávat konkrétní selhání, které se stalo; spekulativní pravidla nepřidávat.
+- Pro Claude Code na devlin.hell: Prompt 1 (merge CLAUDE.md template s inventářem prostředí) a Prompt 6 (quarterly trim).
+
+## Nápady k pozdějšímu použití (z článku „LLM jako virtuální projektový tým")
+
+Zdroj:
+https://blog.root.cz/tonda/llm-jako-virtualni-projektovy-tym-od-generovani-textu-k-rizene-oponenture-podnikatelskeho-planu/
+- **Persona s omezeným mandátem** místo generického „udělej review" (security, API konzument, ops, výkon) — omezený scope brání reverzům odsouhlasených rozhodnutí.
+- **Multi-provider oponentura** — jiný model/preset na review pro procesní nezávislost (ne anchoring na terminologii tvůrce); v nanobotu via `model_preset`.
+- **Registr předpokladů** — explicitní seznam neověřených věcí držených za pravdu, s vazbou předpoklad → závislá rozhodnutí.
+- **Stage-Gate pro testy** — pass/fail podmínky další fáze definované předem, ne ad-hoc po běhu.
+- **Iterovaná oponentura** (A→B→A/C→B) — opakovat review po přepracování, ne jen jednou.
+
 ## Lessons learned
+- Skill design: nanobot samotný navrhne jen kostru, nedohledá detaily a problémy jako Claude Code → zásadní opravy a nové skilly dělat v Claude Code; nanobot plánovač ale jde točit a ladit iterativně (příklad: /usage). Proč (rozbor uživatele): nanobot je s řešením moc rychle hotov (žádný důsledkový průzkum), chybí plánovací mód s možností komentovat, málo kritický k vlastním řešením. Příčina: podle uživatele to není úplně chyba modelu ani nanobota samotného, spíš koncept, jak je nanobot postavený.
+- Review iterací: nová session na review = svěží pohled, ale opravy dělat v původní session s plnou historií rozhodnutí — jinak hrozí regrese (reverzy odsouhlasených rozhodnutí).
 - Inline `python -c` s cestami blokuje exec guard i uvnitř workspace → write_file do tmp/ + `uv run` s working_dir.
 - Před re-runem vždy rekonstruovat loop ze sessions/ — rozhodnout model vs. tooling chyba.
 - Možný upstream report na nanobot: guard blokuje legit `python -c` s workspace cestami.

projects/chata/artifacts/2025-12-03_rozbor-vody-vrt-cerne-voderady.md

@@ -0,0 +1,98 @@
+# Rozbor vody — vrt, Černé Voděrady
+
+**Zdroj:** PDF protokol `f0b1ca473c35_Černé Voděrady rozbor vody.pdf` (původní soubor
+dorazil do chatu; zde uložena věrná transkripce celého obsahu).
+
+## Základní údaje
+
+- Laboratoř: VZ lab, Jindřicha Plachty 535/16, 150 00 Praha 5, tel. 222 200 225, www.vzlab.cz
+- Zkušební laboratoř č. 1402, akreditovaná ČIA podle ČSN EN ISO/IEC 17025:2018
+- Protokol č.: 137551
+- Rozbor č.: 344109
+- Zakázka: č. 013001, Sedláček Tomáš (odběratel: Karla Hlaváčka 2287/9, 180 00 Praha 8)
+- **Místo odběru:** Přestvůrka 5087: vrt (Černé Voděrady, chata)
+- **Datum odběru: 03.12.2025, 08:00** (odebral zákazník)
+- Datum převzetí: 03.12.2025
+- Analýza provedena: 03.12.–15.12.2025
+- Protokol vystaven: 17.12.2025
+- Schválila: Ing. Marcela Janochová, manažer kvality
+
+## Fyzikální a chemické ukazatele
+
+| Ukazatel | Hodnota | Limit | Stav | Metoda |
+|---|---|---|---|---|
+| pach | žádný | — | OK | — |
+| pH při 25 °C | 6,8 | MH 6,5–9,5 / 7 % | OK (mírně kyselá) | SOP 1 (ČSN ISO 10523) |
+| konduktivita při 25 °C | 32,9 mS/m | MH 125 / 7 % | OK | SOP 2 (ČSN EN 27888) |
+| barva | 6,5 mgPt/l | MH 20 / 10 % | OK | SOP 5 (ČSN EN ISO 7887) |
+| zákal | 1,7 ZF | MH 5 / 15 % | OK | SOP 6 (ČSN EN ISO 7027-1) |
+| tvrdost celková | 1,1 mmol/l | DH 2–3,5 / 17 % | velmi měkká | — |
+| KNK 4,5 | 1,4 mmol/l | — | — | SOP 3 (ČSN EN ISO 9963-1) |
+| ZNK 8,3 | 0,25 mmol/l | — | — | SOP 3 (ČSN EN ISO 9963-1) |
+| CO2 volný | 11,0 mg/l | — | — | SOP 4 (ČSN 757372, 757373) |
+| amonné ionty | <0,03 mg/l | MH 0,5 | OK | SOP 8 (ČSN ISO 7150-1, Z1) |
+| dusitany | <0,1 mg/l | NMH 0,5 | OK | SOP 7 (ČSN EN ISO 10304) |
+| dusičnany | <0,1 mg/l | NMH 50 | OK | SOP 7 (ČSN EN ISO 10304) |
+| chloridy | 9,0 mg/l | MH 250 / 10 % | OK | SOP 7 (ČSN EN ISO 10304) |
+| sírany | 78,5 mg/l | MH 250 / 10 % | OK | SOP 7 (ČSN EN ISO 10304) |
+| hydrogenuhličitany | 85,4 mg/l | — | — | — |
+| fluoridy | 0,25 mg/l | NMH 1,5 / 10 % | OK | SOP 7 (ČSN EN ISO 10304) |
+| sodík | 15,2 mg/l | MH 200 / 10 % | OK | SOP 28A (ČSN ISO 8288) |
+| draslík | 0,78 mg/l | DH 1–10 / 10 % | nízký | SOP 28A (ČSN ISO 8288) |
+| vápník | 21,7 mg/l | NMH* min. 30 / 10 % | nízký | SOP 28A (ČSN ISO 8288) |
+| hořčík | 13,1 mg/l | MH* min. 10 / 10 % | OK | SOP 28A (ČSN ISO 8288) |
+| **železo** | **1,4 mg/l** | **MH 0,2 / 10 %** | **NEVYHOVUJE — 7× nad limitem** | SOP 28A (ČSN ISO 8288) |
+| **mangan** | **0,11 mg/l** | **MH 0,05** | **NEVYHOVUJE — ~2× nad limitem** | SOP 28A (ČSN ISO 8288) |
+| celková mineralizace | 224 mg/l | — | — | SOP 19 (ČSN 757346, 757347) |
+| CHSK-Mn | 0,64 mg/l | MH 3 / 15 % | OK (nízké organické látky) | SOP 16 (ČSN EN ISO 8467, Z1) |
+
+## Mikrobiologické ukazatele (limity pro individuální zásobování)
+
+| Ukazatel | Hodnota | Limit | Metoda |
+|---|---|---|---|
+| Escherichia coli | 0 KTJ/100 ml | NMH 0 | SOP 55 (ČSN ISO 9308-1) |
+| Koliformní bakterie | 0 KTJ/100 ml | MH 0 | SOP 55 (ČSN ISO 9308-1) |
+| Intestinální enterokoky | 0 KTJ/100 ml | NMH 0 | SOP 49 (ČSN EN ISO 7899-2) |
+| Počet kolonií při 36 °C | 0 KTJ/1 ml | DH 100 | SOP 53 (ČSN ISO 6222) |
+| Počet kolonií při 22 °C | 63 KTJ/1 ml | DH 500 / 26 % | SOP 53 (ČSN ISO 6222) |
+
+Mikrobiologie: **zcela v pořádku.**
+
+## Poznámky z protokolu
+
+- Položky označené **N** nevyhovují limitům vyhl. č. 252/2004 Sb. pro pitnou vodu (železo, mangan).
+- Při hodnocení shody nebyla nejistota měření uvažována.
+- DH = doporučená hodnota, MH = mezní hodnota, NMH = nejvyšší mezní hodnota,
+  MHRR = mezní hodnota referenčního rizika, MH* = platí pouze pro změkčovanou vodu.
+- Limitní hodnoty dány vyhláškou MZ ČR č. 252/2004 Sb., příloha 1.
+- Nejistoty = standardní nejistota × koeficient rozšíření (k=2), ~95 % pokrytí;
+  nejistota vzorkování nezapočítána. Stanovení Ca/Mg a Na/K mimo rámec akreditace.
+- `<` = hodnota pod mezí stanovitelnosti.
+
+## Interpretace (2026-09-13)
+
+- **Hlavní problém: železo 1,4 mg/l (7× limit) + mangan 0,11 mg/l (2× limit).**
+- Železo pravděpodobně hlavně **rozpuštěné, ne koloidní** — CHSK-Mn 0,64 (nízké
+  organikum), zákal 1,7, barva 6,5, mikrobiologie čistá. Pro koloidní železo typické
+  zvýšení barvy/CHSK tu chybí.
+- Voda **velmi měkká** (1,1 mmol/l), mírně kyselá (pH 6,8, CO2 volný 11 mg/l) →
+  mírně agresivní vůči kovům (riziko korozní rezavění → sekundární Fe v potrubí).
+- Bakterie: čisté, žádné Fe-bakterie indikace (počty kolonií v normě).
+
+## Závěr pro filtrační sestavu
+
+Sestava: 1) hrubá filtrace — kovová mřížka, 2) jemná mechanická filtrace,
+3) filtrace Fe/Mn (dosud Geyser Fe MIX 10"x2,5", kód P10558, vyprodáno všude).
+
+- Železo 1,4 mg/l < 2 mg/l → **stačí obyčejný Geyser Fe 10SL** (kationtoměničové
+  vlákno Catalon, rozpuštěné + oxidované Fe do ~2 mg/l, mangan taky). Fe MIX
+  (bonus pro koloidní železo, limit 5 mg/l) není potřeba.
+- Doporučený nákup: **Geyser Fe 10SL, filtry-vodni.cz, 599 Kč**, dostupnost
+  „na cestě, očekáváme do 19 pracovních dní":
+  https://www.filtry-vodni.cz/filtracni-vlozka-geyser-fe-10sl-pro-odstraneni-zeleza-a-manganu-x1557
+- Kapacita Fe 10SL ~12 000 l při Fe ~1 mg/l → při Fe 1,4 mg/l cca 8–9 m³;
+  víkendový provoz → výměna ~1× ročně (sezónně/pololetně).
+- Plošný odželezňovač s proplachem nedoporučen: Birm při pH 6,8 pro mangan
+  neúčinný (chce pH ~8), na 1,4 mg/l a víkendovou spotřebu zbytečná investice.
+- PHTrade USTM IR-10 (229 Kč, skladem) = fallback: neznámá náplň, nedeklarovaná
+  účinnost na Fe, průtok jen 5 l/min — neověřený ekvivalent.

projects/chata/artifacts/2025-12-03_rozbor-vody-vrt-cerne-voderady_protokol-transkripce.txt

@@ -0,0 +1,96 @@
+--- 
+doc: transkripce PDF protokolu VZ lab č. 137551 (rozbor č. 344109)
+zdroj: f0b1ca473c35_Černé Voděrady rozbor vody.pdf
+---
+
+Strana: 1 z 1
+
+ROZBOR VODY
+
+Jindřicha Plachty 535/16
+Protokol č.: 137551
+Zkušební laboratoř číslo 1402 akreditovaná ČIA podle ČSN EN ISO/IEC 17025:2018
+Název zakázky: Sedláček Tomáš
+Číslo zakázky: 013001
+Datum převzetí: 03.12.2025 Odběratel: Sedláček Tomáš
+Den odběru: 03.12.2025 08:00 hod. Karla Hlaváčka 2287/9
+Odebral: zákazník 180 00 Praha 8
+Číslo rozboru: 344109
+Místo odběru: Přestvůrka 5087: vrt
+
+Výsledek:
+
+Fyzikální a chemické ukazatele:
+- pach: žádný
+- pH při 25°C (laboratoř): 6,8  MH 6,5-9,5 / 7 %
+- konduktivita při 25°C: 32,9 mS/m  MH 125 / 7 %
+- barva: 6,5 mgPt/l  MH 20 / 10 %
+- zákal: 1,7 ZF  MH 5 / 15 %
+- tvrdost celková: 1,1 mmol/l  N  DH 2-3,5 / 17 %
+- KNK 4,5: 1,4 mmol/l
+- ZNK 8,3: 0,25 mmol/l  SOP 4 (ČSN 757372, ČSN 757373)
+- CO2 volný: 11,0 mg/l  SOP 4 (ČSN 757372, ČSN 757373)
+- amonné ionty: <0,03 mg/l  MH 0,5
+- dusitany: <0,1 mg/l  NMH 0,5  SOP 7 (ČSN EN ISO 10304)
+- dusičnany: <0,1 mg/l  NMH 50  SOP 7 (ČSN EN ISO 10304)
+- chloridy: 9,0 mg/l  MH 250 / 10 %  SOP 7 (ČSN EN ISO 10304)
+- sírany: 78,5 mg/l  MH 250 / 10 %  SOP 7 (ČSN EN ISO 10304)
+- hydrogenuhličitany: 85,4 mg/l
+- fluoridy: 0,25 mg/l  NMH 1,5 / 10 %  SOP 7 (ČSN EN ISO 10304)
+- sodík: 15,2 mg/l  MH 200 / 10 %  SOP 28A (ČSN ISO 8288)
+- draslík: 0,78 mg/l  N  DH 1-10 / 10 %  SOP 28A (ČSN ISO 8288)
+- vápník: 21,7 mg/l  N  MH* min. 30 / 10 %  SOP 28A (ČSN ISO 8288)
+- hořčík: 13,1 mg/l  MH* min. 10 / 10 %  SOP 28A (ČSN ISO 8288)
+- železo: 1,4 mg/l  N  MH 0,2 / 10 %  SOP 28A (ČSN ISO 8288)
+- mangan: 0,11 mg/l  N  MH 0,05  SOP 28A (ČSN ISO 8288)
+- celková mineralizace: 224 mg/l  SOP 19 (ČSN 757346, ČSN 757347)
+- CHSK-Mn: 0,64 mg/l  MH 3 / 15 %
+
+Mikrobiologické ukazatele:
+- Escherichia coli: 0 KTJ ve 100 ml  NMH 0  SOP 55 (ČSN ISO 9308-1)
+- Koliformní bakterie: 0 KTJ ve 100 ml  MH 0  SOP 55 (ČSN ISO 9308-1)
+- Intestinální enterokoky: 0 KTJ ve 100 ml  NMH 0  SOP 49 (ČSN EN ISO 7899-2)
+- Počet kolonií při 36 °C: 0 KTJ v 1 ml  DH 100  SOP 53 (ČSN ISO 6222)
+- Počet kolonií při 22 °C: 63 KTJ v 1 ml  DH 500 / 26 %  SOP 53 (ČSN ISO 6222)
+
+Položky označené N nevyhovují limitům uvedeným ve Vyhl. č. 252/2004 Sb. v platném znění pro pitnou vodu.
+Při hodnocení shody nebyla nejistota měření uvažována.
+DH=doporučená hodnota MH=mezní hodnota NMH=nejvyšší mezní hodnota
+MHRR=mezná hodnota referenčního rizika MH*=platí pouze pro změkčovanou vodu
+Limitní hodnoty jsou dány vyhláškou Min. zdravotnictví č. 252/2004 Sb. v platném znění, příloha 1.
+Mikrobiologické ukazatele jsou hodnoceny podle limitních hodnot pro individuální zásobování.
+Uvedené nejistoty jsou součinem standardní nejistoty měření a koeficientu rozšíření (k=2), což pro normální rozdělení odpovídá pravděpodobnosti pokrytí cca 95 %, nebyla započítána nejistota vzorkování.
+* Stanovení mimo rámec akreditace.
+< hodnota stanovení se nachází pod mezí stanovitelnosti
+Laboratoř nemá odpovědnost za informace dodané zákazníkem (datum odběru, místo odběru, odebral), pokud mohou mít vliv na platnost výsledků.
+Zkoušky byly provedeny na adrese laboratoře. část pouze s písemným souhlasem laboratoře VZ lab.
+
+Analyzováno: 03.12.-15.12.2025
+Protokol vystaven dne: 17.12.2025
+Konec protokolu
+
+Metoda stanovení:
+SOP 1 (ČSN ISO 10523)
+SOP 2 (ČSN EN 27888)
+SOP 3 (ČSN EN ISO 9963-1)
+SOP 4 (ČSN 757372, ČSN 757373)
+SOP 5 (ČSN EN ISO 7887)
+SOP 6 (ČSN EN ISO 7027-1)
+SOP 7 (ČSN EN ISO 10304)
+SOP 8 (ČSN ISO 7150-1, Z1)
+SOP 16 (ČSN EN ISO 8467, Z1)
+SOP 19 (ČSN 757346, ČSN 757347)
+SOP 28A (ČSN ISO 8288)
+SOP 43 (TNV 75 7340)
+SOP 49 (ČSN EN ISO 7899-2)
+SOP 53 (ČSN ISO 6222)
+SOP 55 (ČSN ISO 9308-1)
+
+VZ lab
+150 00 Praha 5
+tel.: 222 200 225, www.vzlab.cz
+
+Za laboratoř schválila:
+Ing. Marcela Janochová, manažer kvality
+
+Výsledky rozborů se týkají pouze analyzovaných vzorků, tak jak byly přijaty. Protokol může být reprodukován pouze celý,

projects/chata/memory.md

@@ -2,3 +2,14 @@
 - 2026-09-01: ROZHODNUTÍ — nákup palivového dřeva do krbu s okenkem (dřevník 4 m³): koupit úplně suchý dub za 1 995 Kč/PRMs (sypaný metr), délka 33 cm. Důvody: cena pod trhem (suchý dub okolí Prahy 2 300–2 600 Kč/PRMs, Libeznice 2 590 Kč/PRMs; přepočet na rovný metr ~1 300 Kč/PRMr); čerstvé tvrdé dřevo by potřebovalo 2–3 roky sušení (letos by se topit nedalo, rozdíl jen 680 Kč za 4 m³); suchý dub levnější na jednotku tepla (~265 Kč/GJ) než suchý smrk (~360 Kč/GJ); krb s okenkem vyžaduje suché dřevo (mokré špiní sklo sazami, dehet v komíně) a dub hoří déle a klidněji než smrk (ten prská iskrami). Délka 33 cm ne 25 cm: dvě polínka za sebou do dřevníku, sedí i do kamen — těsnější uložení 25 cm je proti tomu irelevantní. Jednotky: 4 PRMs ≈ 2,4–2,6 rovných m³; na plné naplnění dřevníku ~6 PRMs (8 970 Kč). Kontrola při dodání: vlhkoměr dřeva (Ermenrich Wett MW20, ~450 Kč), dub ~15 % vlhkosti, měřit do čerstvého řezu na více polínech; cenu dopravy (nad 5 km symbolicky účtovaná) vyjasnit předem.
 - 2026-09-01: Dřevo (suchý dub, 4 m³, 33 cm) OBJEDNÁNO — dodání až za měsíc, hlavní sezóna, vysoká poptávka. Mezitím ve starém dřevníku ~0,5 m³ zásoba. Vlhkoměr objednán k měření při dodání.
 - 2026-09-01: OTEVŘENÁ OTÁZKA — zazimování chaty. Možnosti a rizika: (a) zazimovat (vypustit vodu) → obavy z náročného opětovného natlakování domácí vodárny na jaře (neprověřeno); (b) nezazimovat → riziko prasknutí vody jako loni (vytopilo sklep, zdi nasákly); (c) temperovat elektrickým kotlem → při větší zimě až ~300 Kč/den. Rozhodnutí zatím nepadlo.
+- 2026-09-13: V domácí vodárně je filtrační vložka **Geyser Fe MIX 10"x2,5"** na železo a mangan (kód P10558, upravvodu.cz, ~595 Kč):
+
+https://www.upravvodu.cz/geyser-fe-mix-10-x2-5--filtracni-vlozka-na-zelezo-a-mangan/
+
+Specifikace: kationtoměničová nitě namotaná metodou Topfir (patentovaná technologie Geyser); odstraňuje železo až do 5 mg/l (rozpuštěné i koloidní, už v první fázi filtrace) a mangan do 0,5 mg/l. Náhradní vložka se kupuje stejná — 10"x2,5" standard.
+- 2026-09-13: Rozbor vody z vrtu (chata, Černé Voděrady, místo odběru Přestvůrka 5087): **železo 1,4 mg/l (7× nad limitem 0,2) a mangan 0,11 mg/l (2× nad limitem 0,05)** — jediné nevyhovující ukazatele. Zbytek v pořádku: pH 6,8, velmi měkká voda (tvrdost 1,1 mmol/l), CHSK-Mn 0,64 (nízké organikum), zákal 1,7, mikrobiologie zcela čistá (E. coli 0, koliformy 0). Odběr 03.12.2025, protokol VZ lab č. 137551 (rozbor 344109), zákazník Sedláček Tomáš. Interpretace: železo pravděpodobně hlavně rozpuštěné, ne koloidní (nízká CHSK/barva/zákal, čistá mikrobiologie) → na Fe 1,4 mg/l stačí obyčejný Geyser Fe 10SL (rozpuštěné+oxidované Fe do ~2 mg/l), Fe MIX (koloidní Fe, do 5 mg/l) není potřeba. Doporučená náhrada za vyprodanou Fe MIX: **Geyser Fe 10SL, filtry-vodni.cz, 599 Kč, „na cestě do 19 prac. dní"**; kapacita ~12 000 l při Fe ~1 mg/l → při 1,4 mg/l cca 8–9 m³, výměna ~1× ročně. Plošný odželezňovač s proplachem nedoporučen (Birm pro Mn při pH 6,8 neúčinný, zbytečná investice na víkendovou chatu). Celý rozbor + transkripce protokolu uloženy v artifacts.
+- 2026-09-13: Zápach vody (bahno/zdechlina, popis ženy) od ~září 2026, nastupuje náhle; jezdí se pravidelně, stagnace nevysvětluje. Vložka Fe MIX naposled vyměněna ~začátek května 2026 → ~4 měsíce provozu, saturace pravděpodobná (Fe 1,4 mg/l). Diagnóza: nasycená Fe vložka + biofilm/železité bakterie; přispívat může i sezónní pokles hladiny vrtu (konec léta, kyslíkový deficit). Náhodné nalévání čehokoli do vrtu odmítnuto (mikrobiologie v rozboru čistá — není co dezinfikovat, chemie naslepo riziková).
+
+PLÁN ÚPRAAVY SESTAVY (vodárna na 3 patrony): 1) hrubý splachovací filtr s výpusťí dole — zůstává, mechanicky čistit, při příjezdu po pauze spláchnout první vodu do odpadu; 2) korpus → **Geyser Fe 10SL** (599 Kč, filtry-vodni.cz, do 19 dní); 3) korpus → **uhlík GAC 10"x2,5"** (~150–250 Kč). Kritické pořadí: Fe PŘED uhlím (železo 1,4 mg/l by GAC rychle zaslzpil) — tedy fyzicky prohodit obsah korpusů 2 a 3, nevkládat uhlík na původní místo Fe. Uhlík chytá pach (biofilm, H2S nízké koncentrace), Fe/Mn neřeší; po delší pauze (2+ týdny) nechat uhlíkovou vodu odtéct (biofilm v uhlí). Celkem ~800 Kč, bez zásahu do rozvodu.
+
+Eskalace: pokud zápach neustoupí do ~2 týdnů po výměně → nový rozbor (H2S, mikrobiologie, Fe-bakterie), řešení pak na straně vrtu (chlorace vrtu / provzdušnění).

projects/chata/state.md

@@ -26,3 +26,48 @@ požadavky krbu s okénkem, délka 33 vs. 25 cm) je v `memory.md` u záznamu
 - **Nezazimovat** — riziko prasknutí vody jako loni: vytopilo sklep, zdi
   nasákly.
 - **Temperovat elektrickým kotlem** — při větší zimě až ~300 Kč/den.
+
+## Domácí vodárna — filtrace
+
+Sestava: 1) hrubá filtrace — kovová mřížka, 2) jemná mechanická filtrace,
+3) vložka na Fe/Mn.
+
+Nainstalovaná vložka (stupeň 3): **Geyser Fe MIX 10"x2,5"** na železo a mangan
+(kód P10558, upravvodu.cz, ~653 Kč). Kationtoměničová nitě (metoda Topfir,
+patent Geyser); železo až 5 mg/l (rozpuštěné i koloidní), mangan do 0,5 mg/l.
+
+https://www.upravvodu.cz/geyser-fe-mix-10-x2-5--filtracni-vlozka-na-zelezo-a-mangan/
+
+**Fe MIX je vyprodaná plošně (2026-09-13, ověřeno: upravvodu, filtry-vodni.cz,
+geyser.rs, fpwater.eu — ruská značka, dodávky do EU přerušené).**
+
+**Rozbor vody (03.12.2025, vrt, VZ lab):** Fe 1,4 mg/l (7× limit), Mn 0,11 mg/l
+(2× limit); ostatní v pořádku — pH 6,8, tvrdost 1,1 mmol/l (velmi měkká),
+CHSK-Mn 0,64, mikrobiologie čistá. Železo hlavně rozpuštěné, ne koloidní.
+→ Fe MIX nebyla nutná; **stačí Geyser Fe 10SL** (rozpuštěné+oxidované Fe
+do ~2 mg/l). Doporučený nákup: filtry-vodni.cz, 599 Kč, na cestě do 19 dnů;
+výměna ~1× ročně (kapacita ~8–9 m³ při Fe 1,4 mg/l). Celý rozbor:
+`artifacts/2025-12-03_rozbor-vody-vrt-cerne-voderady.md`.
+
+Náhradní vložka: standard 10"x2,5" — Fe 10SL, nebo fallback USTM IR-10
+(PHTrade, 229 Kč, skladem, ale neověřený ekvivalent, průtok jen 5 l/min).
+
+## Zápach vody (od ~září 2026)
+
+Voda páchne „po bahně/zdečelině" (biofilm / Fe-bakterie, možná i H2S složka).
+Poslední výměna Fe vložky: začátek května 2026 → saturace. Nepije se,
+užitková voda.
+
+**Plán nové sestavy** (vodárna 3 patrony; ~800 Kč, bez zásahu do rozvodu):
+
+1. Hrubý splachovací filtr s výpusťí — **zůstává** (mechanicky čistitelný,
+   po pauze spláchnout první vodu do odpadu)
+2. **Geyser Fe 10SL** — 599 Kč, filtry-vodni.cz, do 19 dní
+3. **Uhlík GAC 10"x2,5"** — ~150–250 Kč, na pach
+
+Kritické pořadí: **Fe před uhlím** — fyzicky prohodit obsah korpusů 2 a 3,
+nevkládat uhlík na původní místo Fe (železo 1,4 mg/l by GAC zaslzpil).
+Uhlík po pauze 2+ týdnů nechat odtéct (biofilm v uhlí).
+
+**Eskalace:** zápach neustoupí do ~2 týdnů po výměně → rozbor na H2S,
+mikrobiologii, Fe-bakterie; pak řešení na straně vrtu (chlorace / provzdušnění).

projects/devops/artifacts/2026-09-13_ollama-nvidia-full-report.md

@@ -0,0 +1,498 @@
+# Ollama na nvidia.hell — ucelený report
+
+**Stav k:** 2026-09-13 21:30 (poslední ověřený záznam)
+**Pro:** agenta, který na problému bude pokračovat
+**Zdroje:** `history.md` (záznamy 2026-09-12 21:10 až 2026-09-13 21:30),
+`knowledge.md`, `todo.md`, `done.md`, `explore/negativni-zjisteni.md`
+
+---
+
+## 1. Shrnutí v pěti větách
+
+Ollama na `nvidia.hell` opakovaně shodila celý stroj (load 81 na 4 jádrech,
+SSH neprošlo ani banner exchange, 45 minut nedostupnosti). Příčina není jeden
+bug, ale **řetěz tří nezávislých mechanismů**: (1) ollama vypíná `mmap` podle
+vzorce, který na tomhle stroji **nemůže být nikdy splněn**, takže model teče
+do anonymní paměti místo zahoditelné page cache; (2) architektura PLE u
+`gemma4` drží 5,9 GiB vah v RAM hostitele bez ohledu na volnou VRAM;
+(3) každé přerušení loadu (kill i vlastní timeout scheduleru) **natrvalo
+leakne napinovanou host paměť** v nvidia driveru — uvolní ji jen reboot.
+Nasazená pojistka je cgroup strop na `ollama.service`; ověřeně drží dostupnost
+stroje (240/240 heartbeatů), ale **retest v konečné podobě ještě neproběhl**.
+
+---
+
+## 2. Prostředí
+
+| Položka | Hodnota |
+|---|---|
+| Stroj | `nvidia.hell` — VM pod Proxmox (`pve.hell`, 192.168.4.47) |
+| RAM | původně 11,4 GiB, uživatel **snížil na 9,5 GiB** (viz §5.3) |
+| Swap | 32 GB, `vm.swappiness=60` |
+| CPU | 4 jádra |
+| GPU | NVIDIA RTX 4060 Ti 16 GB (16380 MiB) |
+| Ollama | 0.33.2 nativně (ne v kontejneru), unit `/etc/systemd/system/ollama.service` |
+| Nejnovější upstream | v0.34.0 (5. 9. 2026) — release notes neřeší scheduler ani mmap |
+| Frontendy | OpenWebUI (podman, `:8080`), LibreChat (192.168.4.45), **nanobot.hell (192.168.4.64)** |
+| Další služby | `traefik`, `jupyterhub`, `docker`, `nvidia-persistenced`, `zabbix-agent` |
+
+**Klienti jsou důležití:** `nanobot.hell` je skutečný zdroj zátěže — posílá
+dávky desítek `POST /api/chat` a `/v1/chat/completions` přes ~10 různých modelů
+během minut a drží `qwen3-embedding:0.6b` periodickými `POST /api/embed`.
+LibreChat byl v obou incidentech jen **zesilovač** (po 15min timeoutu load
+okamžitě zopakoval).
+
+---
+
+## 3. Kauzální řetěz — jak se stroj položí
+
+```
+nanobot.hell pošle dávku requestů přes ~10 modelů
+        │
+        ▼
+[1] ollama rozhoduje "fits alongside existing models" podle VRAM,
+    ne podle volné RAM  →  pustí další model i při system_free = 115 MiB
+        │
+        ▼
+[2] týmž dechem "disabling mmap due to host memory pressure"
+    (podmínka nemůže být na 9,5GiB stroji nikdy nesplněna)
+    →  model jde do ANONYMNÍ paměti místo page cache
+        │
+        ▼
+[3] u gemma4 navíc PLE drží 5901 MiB vah v host bufferu
+    (do VRAM jde jen 2966 MiB z 16076 volných)
+        │
+        ▼
+[4] RAM dojde → swap thrashing (pswpin 4512/s), %system 90 %, load 81
+    → stroj nedostupný, SSH neprojde
+        │
+        ▼
+[5] load je přerušen (kill zvenčí NEBO vlastní timeout scheduleru)
+    →  llama-server umírá uprostřed CUDA init
+    →  napinovaná host paměť se NEUVOLNÍ  →  trvalý leak
+        │
+        └──► leak ubere RAM → další load se vejde ještě hůř → smyčka
+```
+
+**Klíčové:** body [1] a [2] jdou proti sobě — jedno rozhodnutí říká „vejde se",
+druhé v téže vteřině říká „je málo paměti". Bod [5] je ta část, která z jednoho
+incidentu udělá degradaci trvající do rebootu.
+
+---
+
+## 4. Ověřená fakta (co platí a čím je to doloženo)
+
+### 4.1 Vypínání mmapu
+
+`sched.go`, `disableMmapForHostPressure`:
+
+```
+FreeMemory < modelSize + max(8 GB, TotalMemory/10)   → vypni mmap
+```
+
+Headroom je **konstanta 7,45 GiB** až do 80 GB RAM. Pro `gemma4`
+(`model_size="8.9 GiB"`) je potřeba **16,4 GiB volné RAM**. Stroj má 9,5 GiB
+celkem → podmínka je splněná **nepodmíněně, bez ohledu na klienta i na to,
+kolik je zrovna volno**.
+
+Důkaz z journalu — tři loady při zcela různé volné paměti, všechny tři
+`disabling mmap ... headroom="7.5 GiB"`:
+
+| čas | `system_free` |
+|---|---|
+| 12:09:20 | 8,4 GiB |
+| 12:44:50 | 3,4 GiB |
+| 13:00:03 | 115,1 MiB |
+
+**Kontraintuitivní důsledek:** čím prázdnější je karta, tím spíš se mmap vypne —
+při těsné VRAM zůstává zapnutý (`sched.go` ř. 1235).
+
+### 4.2 gemma4 / PLE
+
+`gemma4:e4b` (8,95 GiB, `gemma4:latest` je alias téhož blobu) hlásí
+`offloaded 43/43 layers to GPU`, ale reálně:
+
+```
+| - CUDA0 (RTX 4060 Ti) | 16076 = 15951 + (2966 = 2829 + 29 + 107) + -2842 |
+| - Host                |                 5938 = 5901 +  0 +  37           |
+```
+
+Per-Layer Embeddings drží embeddingy na CPU **záměrně**
+([HuggingFace blog](https://huggingface.co/blog/gemma3n): „PLE reduces
+accelerator memory usage by offloading embeddings to the CPU"). Ollama si
+ten CPU buffer započítá do předpovědi `predicted="9.4 GiB"`, jako by šel celý
+do VRAM. Na 9,5GiB stroji je 5,9 GiB host bufferu neufinancovatelné —
+**gemma4 se sem nevejde a nikdy nevejde**, ať je karta jakkoli prázdná.
+
+### 4.3 Leak napinované paměti (nejzávažnější zjištění)
+
+Každé přerušení loadu llama-serveru uprostřed CUDA inicializace natrvalo ztratí
+host paměť napinovanou přes GUP (get_user_pages).
+
+**Nezáleží na tom, kdo proces ukončil.** Doloženo pro obě varianty:
+- externí `SIGTERM` od earlyoomu (~15 killů = 9,27 GiB),
+- zrušení samotným ollama schedulerem (`Load failed: timed out waiting for
+  llama-server to start: context canceled` po odpadnutí klienta) = **5,19 GiB
+  z jednoho zrušení**.
+
+**Diagnostika** (jediné, co leak ukáže):
+```bash
+# počet napinovaných stránek
+awk '/nr_foll_pin_acquired/{a=$2} /nr_foll_pin_released/{r=$2} END{print a-r, "stránek =", (a-r)*4096/1073741824, "GiB"}' /proc/vmstat
+
+# druhý příznak: Active(anon)+Inactive(anon) >> AnonPages
+grep -E 'AnonPages|Active\(anon\)|Inactive\(anon\)|MemAvailable' /proc/meminfo
+```
+
+**Co leak NEUKÁŽE:** `ps -eo rss` (~250 MB přes všechny procesy),
+`nvidia-smi` (2 MiB / 16380 MiB, „No running processes found"),
+`systemd-cgtop` (žádná služba nic nedrží), `sar` (nemá pro to sloupec —
+proto ve vzorcích z 13:40 nesedělo 9,4 GB do žádné kategorie).
+
+**Co leak neuvolní:**
+- `systemctl restart ollama` — `foll_pin` delta identická, navíc paměť
+  **uteče z cgroup do rodiče** (`memory.current` ollamy spadne na 18 MB,
+  `system.slice` si 5,9 GiB nese dál) → kontejnerování platí jen do prvního restartu.
+- `rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia` — proběhl čistě
+  (`lsmod` prázdný), delta **bit za bit stejná** (2 307 318 stránek).
+  Ověřeno 2026-09-13 20:20. Tím padl dřívější předpoklad, že teardown pomůže.
+
+**Co leak uvolní:** **jen reboot.** Ověřeno 2026-09-13 20:26 —
+`MemAvailable` 89 MB → 7,6 GiB, `Inactive(anon)` 5,9 GiB → 0.
+
+Poznámka: nenulová `foll_pin` delta při běžícím modelu je normál
+(po rebootu 252 949 stránek = 0,96 GiB pro načtený `qwen3-embedding:0.6b`).
+Leak se pozná podle toho, že delta zůstane, když neběží žádný llama-server.
+
+### 4.4 Cgroup pojistka — co funguje
+
+Nasazeno v `/etc/systemd/system/ollama.service.d/override.conf`
+(záloha `override.conf.bak-20260913`):
+
+```ini
+MemoryMax=6G
+MemorySwapMax=0      # nejdůležitější řádek
+CPUQuota=200%
+CPUWeight=20
+# MemoryHigh záměrně NENASTAVENO — viz §5.1
+```
+
+Plus `/etc/systemd/system/ssh.service.d/10-oom-protect.conf`:
+`OOMScoreAdjust=-900`, `MemoryMin=32M` (ověřeno, že `ssh.socket` má
+`Accept=no`, takže listener žije v `ssh.service`).
+
+**Zátěžový test 2026-09-13 16:55–17:05** (heartbeat à 2 s, každý úder nové SSH
+spojení; spouštěč `curl /api/generate` na `gemma4:latest`):
+
+| Kritérium | Výsledek |
+|---|---|
+| Dostupnost SSH | **240/240 úderů, 0 výpadků** |
+| `MemAvailable` minimum | 3204 MiB (kritérium bylo 2 GiB) |
+| `loadavg` max | **3,41** (při incidentu 81) |
+| OOM killer v `dmesg` | žádný |
+
+`MemorySwapMax=0` je z toho nejdůležitější — **nedostupnost dělal swap thrash,
+ne OOM**. `MemoryMax=` sám o sobě mapuje na `memory.max`, což je strop jen pro
+RAM; po jeho dosažení kernel proces nezabije, ale začne ho swapovat.
+
+### 4.5 Rozlišení, proč ollama spadla
+
+```bash
+dmesg | grep -i 'oom\|constraint'
+```
+- `constraint=CONSTRAINT_NONE ... global_oom` → **globální OOM killer**,
+  pojistka nezasáhla (stroj byl sežraný leakem, ollama se ke svému 6G stropu
+  vůbec nedostala)
+- `constraint=CONSTRAINT_MEMCG` → **cgroup limit**, pojistka zafungovala
+
+Smyčku `Start request repeated too quickly` dělá `Restart=always` +
+`RestartSec=30` + `StartLimitBurst=3/300s` z drop-inu — **to je záměr**, ne chyba.
+
+---
+
+## 5. Slepé uličky — co nezkoušet znovu
+
+### 5.1 `MemoryHigh` je past
+
+Nastaveno `MemoryHigh=5G` + `MemoryMax=6G`. gemma4 potřebuje host buffer
+5901 MiB → padlo **přesně doprostřed pásma**:
+
+```
+memory.events:  high 84358   max 0   oom 0   oom_kill 0
+memory.peak:    5,46 GiB
+```
+
+Cgroup 84 tisíckrát reclaimovala, proces se plazil, tvrdý strop nezasáhl ani
+jednou a load **visel 600 s bez jediné chybové odpovědi** — ani neselhal,
+ani neproběhl. Pro chování „rychle selhat" se `MemoryHigh` **nesmí nastavit**.
+Odstraněno.
+
+### 5.2 earlyoom — zavržen, odinstalován
+
+Nasazen 14:20, do večera pryč. Tři samostatné problémy:
+
+1. **Ve výchozí konfiguraci by nezasáhl nikdy.** Podmínky `-m` a `-s` platí
+   **současně**. Ze swapu bylo obsazeno 1,4 z 32 GB (~95 % volných), takže
+   `swap <= 10 %` nemohlo nastat. Man page: „You can use `-s 100` to have
+   earlyoom effectively ignore swap usage."
+2. **SIGKILL práh je polovina zadané.** `-s 100` dá kill až při `swap <= 50 %`
+   → nutné psát `-s 100,100`.
+3. **Je to zesilovač, ne pojistka.** Killy llama-serveru uprostřed CUDA init
+   leakují (§4.3). Po ~15 killech chybělo 9,27 GiB, práh `-m 10` se trvale
+   posunul pod klidovou spotřebu a ollama už nenačetla vůbec nic — každý nový
+   llama-server umíral už při 300 MiB RSS. **Kladná zpětná vazba.**
+
+**Poučení: proti procesu, který drží GPU kontext, je externí zabíječ horší než
+nic.** Totéž se dá čekat od `systemd-oomd` (PSI varianta téhož principu) —
+nenasazováno, odvozeno, neověřeno měřením. Balík earlyoom je ve stavu `rc`,
+zbývá `apt purge`.
+
+### 5.3 Navýšení RAM neřeší nic
+
+Headroom je konstanta 7,45 GiB do 80 GB RAM → pro gemma4 by mmap zůstal zapnutý
+až u ~20GiB VM. Uživatel proto paměť naopak **ubral** z 11,4 na 9,5 GiB.
+
+### 5.4 Konfigurace ollamy nemá páku
+
+- **`OLLAMA_NO_MMAP` neexistuje.** [Issue #4895](https://github.com/ollama/ollama/issues/4895),
+  [PR #6854](https://github.com/ollama/ollama/pull/6854) nikdy nesloučen
+  („upstream changes broke this patch"). V `ollama serve --help` volba pro mmap
+  není. Jediné, co existuje, je `PARAMETER use_mmap` v Modelfile — a **není
+  doloženo**, že `true` přebije automatické vypnutí kvůli host memory pressure.
+- **Ollama nemá admission control.** Ověřeno z `--help` (v0.33.2): neexistuje
+  proměnná „odmítni load, když se nevejde do VRAM". K dispozici je jen
+  `OLLAMA_MAX_LOADED_MODELS`, `OLLAMA_MAX_QUEUE`, `OLLAMA_NUM_PARALLEL`,
+  `OLLAMA_GPU_OVERHEAD`, `OLLAMA_CONTEXT_LENGTH`, `LLAMA_ARG_FIT_TARGET`,
+  `OLLAMA_LOAD_TIMEOUT`. Ollama je navržená tak, že do CPU přeteče vždycky.
+- **Omezování počtu modelů završeno.** `OLLAMA_MAX_LOADED_MODELS=1` +
+  `NUM_PARALLEL=1` + `MAX_QUEUE=8` byly v plánu a uživatel je vyhodil oprávněně:
+  stroj shodila **hostitelská RAM, ne VRAM** (karta má 16 GB volných) a 49
+  requestů z nanobotu nepoložilo stroj frontou, ale **sekvencí loadů**, na což
+  `MAX_QUEUE` nesahá.
+- **Zvedat `OLLAMA_LOAD_TIMEOUT` zavrženo** (online se doporučuje jako „turns
+  a hard failure into a slow success") — u nás by jen prodloužilo thrashing
+  z 5 na 15 minut.
+- **Upgrade ollamy neřeší nic** — v0.34.0 release notes: ChatGPT Desktop,
+  structured output na Apple Silicon, OpenAI tool search. Nic o scheduleru
+  ani mmapu.
+
+### 5.5 Proxmox ballooning je pro LLM stroje nevhodný
+
+`pvestatd` (`auto_ballooning`) počítá cíl z **volné paměti hostitele**, ne
+z tlaku v guestu — ten určuje jen prioritu ve frontě. `maxchange` je 100 MB
+na cyklus à 10 s (~10 MB/s): navýšení o 8 GB trvá ~14 minut, zatímco načtení
+modelu 17 s. Během incidentu zůstalo `total` na 7,4 GiB, přestože guest padl
+na 136 MB volných. **Řešení: `balloon: 0` a pevná paměť.**
+
+---
+
+## 6. Chybné závěry, které byly cestou opraveny
+
+| Původní závěr | Oprava |
+|---|---|
+| „Viníkem je LibreChat" | Uživatel reprodukoval zatuhnutí i z `ollama` CLI. LibreChat byl jen zesilovač; spouštěčem je samotný model. |
+| „Embedding drží LibreChat" | Drží ho **nanobot.hell (192.168.4.64)**, ne LibreChat (192.168.4.45). |
+| „Regresi 0.32.10 způsobil Vulkan" | [Rozbor na dev.to](https://dev.to/milkyway008/ollama-model-loads-time-out-after-the-03210-upgrade-the-load-mode-change-and-the-fix-25m) ji připisuje Vulkanu na iGPU — na nás nesedí (CUDA, diskrétní karta). Náš log uvádí jiný spouštěč (`host memory pressure`), ale ústí do téhož `--load-mode none`. Potvrzuje #18373. |
+| „Leakuje jen externí kill" | Leakuje i zrušení vlastním schedulerem — jedno stálo 5,19 GiB. |
+| „Leak uvolní teardown nvidia driveru" | `rmmod` neuvolnil ani stránku. **Jen reboot.** |
+| „`failed (Result: oom-kill)` = zafungoval cgroup strop" | `constraint=CONSTRAINT_NONE` → globální OOM. Pojistka nezasáhla. |
+| „~9,4 GB v `sar` nesedí do žádné kategorie" | Byla to právě ta napinovaná paměť; `sar` pro ni nemá sloupec. |
+
+---
+
+## 7. Upstream — nahlášené a neopravené
+
+| Issue | Co říká | Stav |
+|---|---|---|
+| [#18373](https://github.com/ollama/ollama/issues/18373) | Regrese načítání: 0.33.3 load 2m34s vs. 0.23.4 28s, SSD 600 MB/s místo 3 GB/s. Explicitně „all models", hlášeno i na NVIDII. | otevřené, bez reakce maintainerů |
+| [#10104](https://github.com/ollama/ollama/issues/10104) | 200 GB RAM, 80 GB VRAM, ollama sama nasadí `--no-mmap` a load selže. | zavřené bez řešení |
+| [#10341](https://github.com/ollama/ollama/issues/10341) | gemma plní RAM navzdory volné VRAM, **na RTX 4060 Ti 16 GB** — stejná karta. | duplikát #10040 |
+| [#8654](https://github.com/ollama/ollama/issues/8654) | „Available memory check should be disabled when mmap is in use" | otevřené od 1/2025 |
+| [#4895](https://github.com/ollama/ollama/issues/4895) + [PR #6854](https://github.com/ollama/ollama/pull/6854) | Žádost o globální řízení mmapu. | PR nesloučen |
+
+První výskyt `disabling mmap` v journalu nvidia.hell je **2026-06-05** —
+předtím ani jednou za 13 měsíců. Jde tedy o regresi, ne o vlastnost od začátku.
+
+---
+
+## 8. Chyby v systemd konfiguraci (obecně použitelné)
+
+- **`StartLimitIntervalSec` / `StartLimitBurst` patří do `[Unit]`, ne `[Service]`** —
+  tam se tiše ignorují. `RestartSec` naopak do `[Service]`. Property se navíc
+  jmenuje `RestartUSec` → `systemctl show -p RestartSec` nevrátí nic.
+- **`MemoryMax` sám nelimituje swap** → nutné `MemorySwapMax` (§4.4).
+- **Instalátor ollamy přepisuje unit soubor.** `install.sh` (ř. 215)
+  bezpodmínečně přepíše `/etc/systemd/system/ollama.service` přes `tee`,
+  do `ollama.service.d/` nesahá → vlastní nastavení patří do drop-inu.
+  *Zavrženo:* držet kopii unitu a po upgradu ji kopírovat zpět — konzervuje
+  i upstream řádky (`ExecStart`, `User`, `PATH`).
+- **⚠ Limity z 12. 9. ze stroje nevysvětleně zmizely.** Zapsány ve 21:10,
+  ve 21:44 už v `override.conf` nebyly (zůstaly jen `StartLimit*`, `RestartSec`,
+  `Environment`). Při incidentu 13. 9. proto `systemctl show ollama` hlásil
+  `MemoryMax=infinity`. **Příčina nikdy nezjištěna.** Proto existuje záloha
+  `override.conf.bak-20260913` a **kontrola limitů musí být součástí každého ověření**.
+- **Překlep v drop-inu:** zakomentovaný řádek `Environment="LLAMA_MAX_LOADED_MODELS=1"`
+  — správně `OLLAMA_MAX_LOADED_MODELS`, nefungoval by ani po odkomentování.
+
+---
+
+## 9. Ostatní zjištění k ollamě / modelům
+
+### `OLLAMA_KV_CACHE_TYPE=q4_0` rozbíjí modely s head_dim nedělitelným 32
+
+`granite-code` (`n_embd_head_k=80`) padá na
+`K cache type q4_0 with block size 32 does not divide n_embd_head_k=80`.
+12. 9. kvůli tomu spadl **6× po sobě** (12:08:36–12:09:04) a každý pokus přitom
+nastartoval llama-server a načetl 1,9 GiB s vypnutým mmapem. Proměnná je
+**globální** — nastavit jde jen pro všechny modely naráz.
+**Stále nastaveno, neopraveno.**
+
+### Capability `tools` neznamená, že model nástroje použije
+
+Za 13. 9. odešly jen 3 `tools/call`: `gemma4:e4b` (2×) a `glm-5.3:cloud` (1×).
+`mistral:latest` dostal ve stejné relaci **stejných 5 nástrojů** jako glm-5.3
+a nezavolal ani jeden (job skončil za 4 s textovou odpovědí), přestože
+v `ollama show` **má** capability `tools`. Flag říká jen to, že šablona
+nástroje podporuje.
+
+Modely **bez** `tools` (nikdy nebudou fungovat): `llama3`, `llama2-uncensored`,
+`tinyllama`, `aya`, `phi4`, `phi3.5`, `codellama`, `exaone-deep`,
+`deepseek-coder-v2`, `granite-code:8b`.
+
+### `sar` přežije reboot a chybějící vzorek je sám o sobě důkaz
+
+`/var/log/sysstat/saDD` + perzistentní journal umožnily dohledat incident až
+po restartu VM. Kolektor `sa1` běží à 10 min z `/etc/cron.d/sysstat`; **když
+vzorek ve výpisu chybí, stroj byl v tu chvíli tak zahlcený, že cron nedoběhl** —
+tím se dá datovat začátek incidentu (vzorek 12:50 chyběl).
+
+---
+
+## 10. Aktuální stav (po rebootu 2026-09-13 20:26)
+
+```
+MemAvailable   7,6 GiB      (bylo 89 MB)
+MemFree        5,8 GiB
+Inactive(anon) 0            (bylo 5,9 GiB)
+foll_pin delta 252 949 stránek = 0,96 GiB  ← legitimní, drží běžící model
+OOM killů od bootu: 0
+```
+
+Běží: `ollama`, `nvidia-persistenced`, `traefik`, `jupyterhub`, `docker`, `ssh`.
+Cgroup pojistka aktivní a ve správné podobě: `MemoryMax=6G`, `MemorySwapMax=0`,
+`MemoryHigh=infinity`, `CPUQuota=200%`, `StartLimitBurst=3/5min`.
+
+---
+
+## 11. Co zbývá udělat
+
+Seřazeno podle priority:
+
+1. **Zastavit dávky z nanobot.hell (192.168.4.64)** — bez toho je leak zpátky
+   během minut. Zatím neuděláno.
+2. **Retest cgroup pojistky bez `MemoryHigh`** — potvrdit, že load selže
+   v řádu sekund přes cgroup OOM (`memory.events` → `oom_kill > 0`) místo
+   desetiminutového plazení. **Odblokováno** rebootem. Kritéria z minulého testu:
+   SSH heartbeat à 2 s bez výpadku, `MemAvailable` > 2 GiB, `loadavg` pod kontrolou,
+   `dmesg` → `constraint=CONSTRAINT_MEMCG` (ne `CONSTRAINT_NONE`).
+3. **Doladit `MemoryMax`** podle naměřeného `memory.peak` z retestu.
+4. **Rozhodnout osud gemma4** — `gemma4:latest` / `gemma4:12b` / `gemma4:e4b`
+   potřebují kvůli PLE ~5,9 GiB host bufferu bez ohledu na volnou VRAM.
+   Na 9,5GiB stroji se nevejdou nikdy. *Otázka pro uživatele: vyřadit je?*
+   Jediné skutečné „admission control", které ollama nabízí, je nenabízet
+   nebezpečné modely.
+5. **`OLLAMA_KV_CACHE_TYPE=q4_0`** — buď proměnnou zrušit, nebo `granite-code`
+   nepoužívat.
+6. Drobnosti:
+   - `apt purge earlyoom` (balík ve stavu `rc`, zbyly `/etc/default/earlyoom`
+     a `/etc/default/earlyoom.bak-20260913`)
+   - snížit `--log-verbosity 4` u llama-serveru (journald při incidentu žral
+     1,9 % CPU, journal zaplevelený)
+   - opravit `Hostname=Zabbix server` v `/etc/zabbix/zabbix_agentd.conf`
+     na `nvidia` (agent běží a míří na `zabbix.hell`, ale s defaultním jménem)
+   - LibreChat: `titleConvo: true` + `titleModel: "current_model"` posílá na týž
+     model druhý souběžný požadavek (v logu `Title generation timeout`)
+   - *otázka:* jaký monitoring doinstalovat? `sysstat` na postmortem stačil.
+     Chybí (a) alerting v reálném čase a (b) hlídač, který zakročí — ale
+     pozor, „hlídač, který killuje" je právě ta zavržená cesta (§5.2).
+
+---
+
+## 12. Rychlá kuchařka pro triáž
+
+```bash
+# 1) Leakuje pinned paměť?
+awk '/nr_foll_pin_acquired/{a=$2} /nr_foll_pin_released/{r=$2} \
+     END{print (a-r), "stránek =", (a-r)*4096/1073741824, "GiB"}' /proc/vmstat
+grep -E 'MemAvailable|AnonPages|Active\(anon\)|Inactive\(anon\)' /proc/meminfo
+# Active+Inactive(anon) >> AnonPages  →  leak.
+# Když neběží žádný llama-server a delta je nenulová → leak. Řešení: REBOOT.
+
+# 2) Platí vůbec limity? (už jednou zmizely!)
+systemctl show ollama -p MemoryMax -p MemorySwapMax -p MemoryHigh -p CPUQuotaPerSecUSec
+grep . /sys/fs/cgroup/system.slice/ollama.service/memory.{max,swap.max,high,current,peak}
+cat /sys/fs/cgroup/system.slice/ollama.service/memory.events
+
+# 3) Spadla ollama na cgroup stropu, nebo globálně?
+dmesg | grep -iE 'oom|constraint'
+#   CONSTRAINT_MEMCG → pojistka zafungovala
+#   CONSTRAINT_NONE / global_oom → stroj byl sežraný leakem, pojistka se nedostala ke slovu
+
+# 4) Kdo to spustil?
+journalctl -u ollama --since -2h | grep -E 'disabling mmap|fits alongside|Load failed|system_free'
+journalctl -u ollama --since -2h | grep -oE '192\.168\.4\.[0-9]+' | sort | uniq -c
+#   192.168.4.64 = nanobot.hell (skutečný zdroj), 192.168.4.45 = LibreChat (zesilovač)
+
+# 5) Postmortem po rebootu
+sar -r -f /var/log/sysstat/sa$(date +%d)     # chybějící vzorek = stroj nestíhal ani cron
+sar -q -f /var/log/sysstat/sa$(date +%d)     # ldavg
+journalctl -b -1 -u ollama
+```
+
+---
+
+## 13. Zálohy a rollback na stroji
+
+| Co | Kde |
+|---|---|
+| Unit + skripty před zásahem 12. 9. | `~/backup/ollama-20260912-2108/` |
+| Drop-in před cgroup pojistkou | `/etc/systemd/system/ollama.service.d/override.conf.bak-20260913` |
+| earlyoom config | `/etc/default/earlyoom.bak-20260913` |
+| SSH OOM ochrana (přidáno) | `/etc/systemd/system/ssh.service.d/10-oom-protect.conf` |
+| Upgrade skripty | `~/bin/upgrade-ollama.sh`, `~/bin/upgrade-openwebui.sh` |
+
+```bash
+# rollback cgroup pojistky
+sudo cp -a /etc/systemd/system/ollama.service.d/override.conf.bak-20260913 \
+           /etc/systemd/system/ollama.service.d/override.conf
+sudo rm -f /etc/systemd/system/ssh.service.d/10-oom-protect.conf
+sudo systemctl daemon-reload && sudo systemctl restart ollama ssh
+
+# návrat driveru po rmmod (kdyby to někdo zkusil znovu — nemá to smysl)
+sudo modprobe nvidia && sudo modprobe nvidia_uvm && sudo modprobe nvidia_modeset
+sudo systemctl start nvidia-persistenced
+```
+
+**Pozn.:** `~/bin/nvidia-reload` na stroji existuje, ale **nemá smysl** —
+postaven na předpokladu, že `rmmod` leak uvolní, což bylo vyvráceno (§4.3).
+
+---
+
+## 14. Plné záznamy
+
+Chronologicky v `history.md`:
+
+| Záznam | Obsah |
+|---|---|
+| 2026-09-12 21:10 | Paměťové limity přes systemd drop-in (limity pak záhadně zmizely) |
+| 2026-09-13 12:05 | LibreChat: web search bez klíčů + Python přes MCP |
+| 2026-09-13 13:40 | Průzkum: nvidia.hell zahlcená na 45 minut (load 81) |
+| 2026-09-13 14:00 | Oprava diagnózy: viník není LibreChat, ale práh pro mmap |
+| 2026-09-13 14:20 | Rešerše upstreamu + nasazení earlyoom |
+| 2026-09-13 15:45 | Ollama nefunkční, 9,3 GiB leaklé pinned paměti |
+| 2026-09-13 17:10 | Cgroup pojistka nasazena a otestována, `MemoryHigh` past |
+| 2026-09-13 20:20 | `rmmod` nvidia leak NEuvolnil, leak vyrostl na 8,8 GiB |
+| 2026-09-13 21:30 | Reboot uvolnil leak, stroj zdravý |
+
+Další: `knowledge.md` (ověřená fakta), `todo.md` (otevřené body),
+`explore/negativni-zjisteni.md` (podrobný soupis negativních zjištění).

projects/devops/artifacts/2026-09-13_ollama-nvidia-negative-findings.md

@@ -0,0 +1,278 @@
+# Negativní zjištění — nvidia.hell / ollama
+
+Co selhalo, co nefunguje a co jsme zkusili marně. Sesbíráno z incidentů
+12.–13. 9. 2026. Plné záznamy jsou v [history.md](history.md), ověřená
+pozitivní fakta v [knowledge.md](knowledge.md).
+
+Rozsah: jen stroj nvidia.hell a ollama. Slepé uličky z PVE migrace tu nejsou —
+ty jsou v [knowledge.md](knowledge.md).
+
+---
+
+## 1. Pojistky, které selhaly
+
+### earlyoom jako ochrana ollamy — zavrženo, odinstalováno
+
+Nasazen 13. 9. ve 14:20, do večera odinstalován. Killoval `llama-server`
+uprostřed CUDA inicializace a nvidia driver při tom natrvalo ztratil
+napinovanou host paměť. Po ~15 killech chybělo **9,27 GiB** a ollama nenačetla
+vůbec nic.
+
+Tím vznikla kladná zpětná vazba: leak ubere RAM → práh `-m 10` je blíž →
+earlyoom zabíjí dřív → další leak. Nakonec umíral každý nový `llama-server`
+už při 300 MiB RSS.
+
+**Poučení:** proti procesu, který drží GPU kontext, je externí zabíječ horší
+než nic. Náhradou je cgroup strop, který nenechá tlak vzniknout.
+→ [history.md](history.md) 2026-09-13 15:45
+
+### earlyoom ve výchozí konfiguraci by nezasáhl nikdy
+
+Balík byl na stroji nainstalovaný a běžel už před incidentem, jen ve výchozím
+`-m 10 -s 10`. earlyoom zabíjí **jen když jsou obě podmínky splněné současně**.
+Ze swapu bylo obsazeno 1,4 z 32 GB, tedy ~95 % volných — podmínka
+`swap <= 10 %` nemohla nastat. Běžící earlyoom tedy nebyl žádná ochrana.
+
+### earlyoom odvozuje SIGKILL práh jako polovinu zadaného
+
+První pokus s `-s 100` dal SIGKILL práh `swap <= 50 %`, takže při 95 % volného
+swapu by eskalace nikdy nenastala. Musí se psát `-s 100,100`.
+
+### MemoryHigh mezi spotřebou a MemoryMax = past
+
+Nastaveno `MemoryHigh=5G` + `MemoryMax=6G`. gemma4 potřebuje host buffer
+**5901 MiB**, což padlo přesně doprostřed. Výsledek při testu 13. 9. 17:05:
+
+```
+memory.events:  high 84358   max 0   oom 0   oom_kill 0
+memory.peak:    5,46 GiB
+```
+
+Cgroup 84 tisíckrát reclaimovala, proces se plazil, tvrdý strop nezasáhl ani
+jednou a load **visel 600 s bez jediné chybové odpovědi**. Ani neselhal, ani
+neproběhl.
+
+**Poučení:** když má konfigurace „rychle selhat", `MemoryHigh` se nesmí
+nastavit — ať se narazí rovnou do `MemoryMax`. Odstraněno.
+→ [history.md](history.md) 2026-09-13 17:10
+
+### systemd-oomd — nepoužito
+
+Na stroji není nainstalovaný. Nenasazovali jsme ho: je to PSI varianta téhož
+principu jako earlyoom, tedy SIGKILL zvenčí, takže se dá čekat týž leak.
+Neověřeno měřením, jen odvozeno.
+
+---
+
+## 2. Slepé uličky v konfiguraci ollamy
+
+### Ollama nemá admission control
+
+Ověřeno z `ollama serve --help` (v0.33.2): **neexistuje proměnná typu
+„odmítni load, když se nevejde do VRAM"**. Ollama je navržená tak, že přeteče
+do CPU vždycky. K dispozici je jen `OLLAMA_MAX_LOADED_MODELS`,
+`OLLAMA_MAX_QUEUE`, `OLLAMA_NUM_PARALLEL`, `OLLAMA_GPU_OVERHEAD`,
+`OLLAMA_CONTEXT_LENGTH`, `LLAMA_ARG_FIT_TARGET`, `OLLAMA_LOAD_TIMEOUT` —
+nic z toho není admission control.
+
+Jediné skutečné odmítnutí je nenabídat nebezpečné modely.
+
+### `OLLAMA_NO_MMAP` neexistuje
+
+Žádost o globální řízení mmapu je [#4895](https://github.com/ollama/ollama/issues/4895),
+[PR #6854](https://github.com/ollama/ollama/pull/6854) nebyl nikdy sloučen
+(„upstream changes broke this patch"). Lidé to žádají ještě 6/2026.
+Vypnutý mmap se tedy konfigurací obejít nedá.
+
+### Navýšení RAM problém neřeší
+
+Podmínka je `FreeMemory < modelSize + max(8 GB, TotalMemory/10)`. Headroom je
+tedy **konstanta 7,5 GiB** až do 80 GB RAM. Pro gemma4 (8,9 GiB) je potřeba
+16,4 GiB *volné* RAM, takže mmap by zůstal zapnutý až u ~20GiB VM.
+
+Důkaz z journalu — tři loady při zcela různé volné paměti, všechny tři
+`disabling mmap ... headroom="7.5 GiB"`:
+
+| čas | `system_free` |
+|---|---|
+| 12:09:20 | 8,4 GiB |
+| 12:44:50 | 3,4 GiB |
+| 13:00:03 | 115,1 MiB |
+
+Volná paměť nikdy nehrála roli. Uživatel proto paměť naopak **ubral**
+z 11,4 na 9,5 GiB.
+
+### Omezování počtu modelů — zavrženo
+
+`OLLAMA_MAX_LOADED_MODELS=1` + `NUM_PARALLEL=1` + `MAX_QUEUE=8` byly v plánu
+a uživatel je oprávněně vyhodil: stroj shodila **hostitelská RAM, ne VRAM**
+(karta má 16 GB volných), a 49 requestů z nanobotu nepoložilo stroj frontou,
+ale sekvencí loadů — na což `MAX_QUEUE` vůbec nesahá. Byly to škrty
+bez vazby na příčinu, které by degradovaly běžný provoz.
+
+### Upgrade ollamy problém neřeší
+
+Nainstalovaná 0.33.2, nejnovější v0.34.0 (5. 9. 2026). Release notes obsahují
+jen ChatGPT Desktop, structured output na Apple Silicon a OpenAI tool search —
+**nic o scheduleru ani mmapu**.
+
+### `OLLAMA_KV_CACHE_TYPE=q4_0` rozbíjí modely
+
+Proměnná je globální a shodí modely s `n_embd_head_k=80`. `granite-code` kvůli
+ní 12. 9. spadl **6× po sobě** na `K cache type q4_0 with block size 32 does
+not divide n_embd_head_k=80` — a každý pokus přitom nastartoval llama-server
+a načetl 1,9 GiB s vypnutým mmapem. Stále nastaveno, neopraveno.
+
+### gemma4 se na tenhle stroj nevejde a nikdy nevejde
+
+Není to otázka velikosti modelu. Architektura Per-Layer Embeddings drží
+embeddingy na CPU **záměrně**:
+
+```
+| - CUDA0 (RTX 4060 Ti) | 16076 = 15951 + (2966 = 2829 + 29 + 107) + -2842 |
+| - Host                |                 5938 = 5901 +  0 +  37           |
+```
+
+Do VRAM jde 2966 MiB z 16076 volných, zatímco host drží 5901 MiB. Kontraintuitivní
+důsledek: **čím prázdnější karta, tím spíš se mmap vypne** — při těsné VRAM
+zůstává zapnutý. Ollama si navíc CPU buffer započítá do předpovědi
+`predicted="9.4 GiB"` jako by šel celý do VRAM.
+
+---
+
+## 3. Chyby v systemd konfiguraci
+
+### `StartLimitIntervalSec` / `StartLimitBurst` v `[Service]` se tiše ignorují
+
+Patří do `[Unit]`. `RestartSec` naopak do `[Service]`. Property se navíc
+jmenuje `RestartUSec` — `systemctl show -p RestartSec` nevrátí nic.
+
+### `MemoryMax` sám o sobě nelimituje swap
+
+Mapuje na `memory.max`, což je strop **jen pro RAM**. Po jeho dosažení kernel
+proces nezabije, ale začne ho swapovat. Se swapem 32 GB to znamená thrashing
+místo rychlého OOM killu. Tvrdý strop vznikne až s `MemorySwapMax`.
+
+### Instalátor ollamy přepisuje unit soubor
+
+`install.sh` (ř. 215) bezpodmínečně přepíše `/etc/systemd/system/ollama.service`
+přes `tee`. Do `ollama.service.d/` nesahá, takže vlastní nastavení patří
+do drop-inu.
+
+Zavrženo: držet kopii unitu a po upgradu ji kopírovat zpět — konzervuje
+i upstream řádky (`ExecStart`, `User`, `PATH`), takže upstream změna se ztratí.
+
+### Limity z 12. 9. ze stroje nevysvětleně zmizely
+
+Zapsány v 21:10, v 21:44 už v `override.conf` nebyly (zůstaly jen
+`StartLimit*`, `RestartSec` a `Environment`). Při incidentu 13. 9. proto
+`systemctl show ollama` hlásil `MemoryMax=infinity`. **Příčina zmizení
+nebyla nikdy zjištěna.** Proto teď existuje záloha
+`override.conf.bak-20260913` a kontrola limitů je součástí ověření.
+
+### Překlep `LLAMA_MAX_LOADED_MODELS`
+
+V drop-inu je zakomentovaný řádek `Environment="LLAMA_MAX_LOADED_MODELS=1"`.
+Proměnná se jmenuje `OLLAMA_MAX_LOADED_MODELS` — nefungovala by ani po
+odkomentování.
+
+---
+
+## 4. Co nástroje neukážou
+
+### Napinovanou paměť neukáže `ps`, `nvidia-smi` ani `systemd-cgtop`
+
+Při leaku 9,27 GiB hlásily:
+
+- `ps -eo rss` přes všechny procesy dohromady ~250 MB
+- `nvidia-smi`: 2 MiB / 16380 MiB, **No running processes found**
+- `systemd-cgtop`: žádná služba nic nedrží
+- `/proc/meminfo`: `AnonPages` 135 MiB, ale `Active(anon)+Inactive(anon)` 9,4 GiB
+
+Jediné, co to ukáže, je rozdíl `nr_foll_pin_acquired − nr_foll_pin_released`
+ve `/proc/vmstat`. Na to je teď skript `~/bin/nvidia-reload` na nvidia.hell.
+
+### Nedopočet paměti v `sar` z 13. 9. byl tentýž leak
+
+Záznam z 13:40 skončil otevřeným bodem: `kbmemused` 10,6 GB proti `kbanonpg`
+54–126 MB, `kbcached` 975 MB, `kbslab` 187 MB — ~9,4 GB nesedělo do žádné
+kategorie a po rebootu to nešlo dovyšetřit. **Vysvětleno až v 15:45:** byla
+to právě ta napinovaná paměť. `sar` pro ni nemá sloupec.
+
+### Restart ollamy leak neuvolní a vystrčí ho z cgroup
+
+Během incidentu je leak účtovaný cgroup ollamy (`memory.current` 5,59 GiB
+při `anon` jen 15,9 MB), takže ho `MemoryMax` drží. Po `systemctl restart
+ollama` je `foll_pin` delta **identická**, ale `memory.current` spadne
+na 18 MB a paměť si nese `system.slice`.
+
+Kontejnerování tedy platí jen do prvního restartu; pak leak uteče ze stropu
+a trvale ubere stroji RAM. Uvolní ho až teardown nvidia driveru nebo reboot.
+
+### Proxmox ballooning je pro LLM stroje nevhodný
+
+`pvestatd` (`auto_ballooning`) počítá cíl z **volné paměti hostitele**, ne
+z tlaku v guestu. `maxchange` je 100 MB na cyklus á 10 s, tedy ~10 MB/s:
+navýšení o 8 GB trvá ~14 minut, zatímco načtení modelu 17 s. Během OOM
+incidentu zůstalo `total` na 7,4 GiB, přestože guest padl na 136 MB volných.
+
+---
+
+## 5. Chybné závěry, které jsme museli opravit
+
+### „Viníkem je LibreChat" — ne
+
+První diagnóza (13:40) označila LibreChat za spouštěč. Uživatel zatuhnutí
+reprodukoval i z `ollama` CLI, čímž závěr padl. LibreChat byl jen zesilovač:
+po 15minutovém timeoutu load okamžitě zopakoval při 115 MiB volných.
+Spouštěčem je samotný model.
+
+### „Embedding drží LibreChat" — ne
+
+`qwen3-embedding:0.6b` drží **nanobot.hell (192.168.4.64)**, ne LibreChat
+(192.168.4.45). Periodické `POST /api/embed`. Nanobot je zároveň zdrojem
+dávek desítek requestů přes ~10 různých modelů během minut.
+
+### „Regresi 0.32.10 způsobil Vulkan" — na nás nesedí
+
+[Rozbor na dev.to](https://dev.to/milkyway008/ollama-model-loads-time-out-after-the-03210-upgrade-the-load-mode-change-and-the-fix-25m)
+připisuje regresi Vulkanu na integrovaných GPU. Máme CUDA a diskrétní kartu.
+Náš log uvádí jiný spouštěč (`host memory pressure`), ale ústí do téhož
+`--load-mode none`. Že to není jen Vulkan, potvrzuje
+[#18373](https://github.com/ollama/ollama/issues/18373).
+
+### „Leakuje jen externí kill" — ne
+
+Leak vznikne i když load zruší **sám ollama scheduler**
+(`Load failed: timed out waiting for llama-server to start: context canceled`
+po odpadnutí klienta). Jedno takové zrušení stálo 5,19 GiB. Nezáleží tedy
+na tom, kdo `llama-server` ukončí — záleží na tom, že byl ukončen uprostřed
+loadu.
+
+---
+
+## 6. Upstream — nahlášené a neopravené
+
+| Issue | Co říká | Stav |
+|---|---|---|
+| [#18373](https://github.com/ollama/ollama/issues/18373) | Regrese načítání: 0.33.3 load 2m34s vs. 0.23.4 28s, SSD 600 MB/s místo 3 GB/s. Explicitně „all models", hlášeno i na NVIDII. | otevřené, bez reakce maintainerů |
+| [#10104](https://github.com/ollama/ollama/issues/10104) | 200 GB RAM, 80 GB VRAM, ollama sama nasadí `--no-mmap` a load selže. | zavřené bez řešení |
+| [#10341](https://github.com/ollama/ollama/issues/10341) | gemma plní RAM navzdory volné VRAM, **na RTX 4060 Ti 16 GB** — stejná karta. | duplikát #10040 |
+| [#8654](https://github.com/ollama/ollama/issues/8654) | „Available memory check should be disabled when mmap is in use" | otevřené od 1/2025 |
+| [#4895](https://github.com/ollama/ollama/issues/4895) + [PR #6854](https://github.com/ollama/ollama/pull/6854) | Žádost o globální řízení mmapu. | PR nesloučen |
+
+Námitka uživatele, že by tohle muselo trápit spoustu lidí, byla správná —
+jen míří opačným směrem: problém je široce hlášený a upstream ho neřeší.
+
+---
+
+## 7. Drobnosti k opravě
+
+- `zabbix-agent` běží a míří na `zabbix.hell`, ale má `Hostname=Zabbix server`
+  (defaultní hodnota) — stroj se nehlásí jako `nvidia`.
+- `llama-server` běží s `--log-verbosity 4`; journald kvůli tomu při incidentu
+  žral 1,9 % CPU a journal je zaplevelený.
+- LibreChat `titleConvo: true` + `titleModel: "current_model"` posílá na týž
+  model druhý souběžný požadavek (v logu `Title generation timeout`).
+- Balík `earlyoom` je ve stavu `rc` — zbývá `apt purge`, na disku jsou
+  `/etc/default/earlyoom` a `/etc/default/earlyoom.bak-20260913`.

projects/devops/artifacts/librechat-podman/README.md

@@ -0,0 +1,85 @@
+# LibreChat — Podman (rootless) + systemd Quadlet
+
+Náhrada OpenWebUI. Minimal stack: **api + mongodb** (bez RAG/vectordb/admin-panel,
+kvůli RAM). Volitelně meilisearch pro fulltext search (`SEARCH=true`).
+
+Zdroje:
+- https://www.librechat.ai/docs/local/docker
+- https://www.librechat.ai/docs/remote/docker_linux
+- https://www.librechat.ai/docs/configuration/dotenv
+- Quadlet: https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html
+
+## Instalace (rootless, user services)
+
+1. Předpoklady: `podman` ≥ 4.4 (ideálně 5.x), uživatelský účet na serveru.
+
+2. Linger, aby user services běžely bez loginu:
+
+       loginctl enable-linger <user>
+
+3. Adresář s konfigem:
+
+       mkdir -p ~/librechat
+       # .env ze šablony z repa LibreChat (.env.example)
+       cp .env.example ~/librechat/.env
+
+   V `~/librechat/.env` nastavit:
+   - `MONGO_URI=mongodb://librechat-mongodb:27017/LibreChat`
+     (DNS jméno kontejneru v quadlet síti; default v šabloně je 127.0.0.1)
+   - `MEILI_HOST=http://librechat-meilisearch:7700`
+   - Trvalé secrets — vygenerovat (např. `openssl rand -hex 32`):
+     `CREDS_KEY` (64 hex znaků), `CREDS_IV` (32 hex), `JWT_SECRET`, `JWT_REFRESH_SECRET`
+     (jinak se vygenerují do `/app/data/.env.temp` — funguje, ale po ztrátě volume
+     jsou session/šifrované záznamy nenávratně pryč)
+   - `SEARCH=true` jen při provozu meilisearch + `MEILI_MASTER_KEY`
+
+4. Quadlet unity nakopírovat do `~/.config/containers/systemd/user/`:
+
+       cp librechat.network librechat-mongodb.container librechat.container \
+          ~/.config/containers/systemd/user/
+       # volitelně: cp librechat-meilisearch.container ~/.config/containers/systemd/user/
+
+   Cestu k `.env` v unitách případně upravit (výchozí `%h/librechat/.env`
+   = `~/.config/...` patřičně).
+
+5. Start:
+
+       systemctl --user daemon-reload
+       systemctl --user enable --now librechat-mongodb.service
+       systemctl --user enable --now librechat.service
+       # volitelně: systemctl --user enable --now librechat-meilisearch.service
+
+6. UI na `http://<host>:3080`. První registrace = admin účet single-tenant
+   deploymentu. **Po vytvoření účtu** v `.env` doplnit `ALLOW_REGISTRATION=false`
+   a restart (`systemctl --user restart librechat.service`).
+
+## Volitelné doplňky
+
+- `librechat.yaml` (custom endpointy — Ollama/litellm proxy na nvidia.hell,
+  preset modelů atd.): soubor do `~/librechat/librechat.yaml` +
+  v `librechat.container` odkomentovat Volume řádek. Validace YAML fail-fast.
+- RAG (vectordb + rag_api): až když bude potřeba, ~1 GB RAM navíc.
+- Aktualizace: `podman auto-update` (quadlet unity mají default label),
+  nebo ručně `podman pull registry.librechat.ai/danny-avila/librechat-dev:latest`
+  + `systemctl --user restart librechat.service`.
+
+## Provoz / debugging
+
+- Logy: `journalctl --user -u librechat.service` (nebo `-u librechat-mongodb`)
+- Stav kontejnerů: `podman ps`
+- Port konflikt: `PublishPort` v `librechat.container` (default 3080:3080)
+
+## Designová rozhodnutí
+
+- **Quadlet** místo `podman generate systemd` (deprecated) a místo
+  systemd-oneshot nad `podman compose` (systemd neví o kontejnerech,
+  špatný restart/watchdog).
+- **Společná quadlet síť** (`librechat.network`) — DNS mezi api a mongo
+  přes ContainerName, žádné porty mimo host kromě 3080.
+- **Rootless + linger** — žádný root daemon na hostu; port 3080 > 1024,
+  žádný konflikt s privileged porty.
+- **Bind-mount `.env` do /app/.env** — stejně jako upstream compose
+  (aplikace čte /app/.env za běhu, env_file samotný nestačí).
+- Data v pojmenovaných volumech: `librechat-data` (/app/data — session,
+  temp credentials), `librechat-mongodb-data` (/data/db). Záloha:
+  `podman volume export`.

projects/devops/artifacts/librechat-podman/librechat-meilisearch.container

@@ -0,0 +1,16 @@
+[Unit]
+Description=LibreChat Meilisearch (fulltext)
+
+[Container]
+Image=docker.io/getmeili/meilisearch:v1.35.1
+ContainerName=librechat-meilisearch
+Network=librechat.network
+Environment=MEILI_NO_ANALYTICS=true
+EnvironmentFile=%h/librechat/.env
+Volume=librechat-meilisearch-data:/meili_data
+
+[Service]
+Restart=on-failure
+
+[Install]
+WantedBy=default.target

projects/devops/artifacts/librechat-podman/librechat-mongodb.container

@@ -0,0 +1,16 @@
+[Unit]
+Description=LibreChat MongoDB
+
+[Service]
+# startup ordering: restart until api comes up
+Restart=on-failure
+
+[Container]
+Image=docker.io/mongo:8.0.20
+ContainerName=librechat-mongodb
+Network=librechat.network
+Volume=librechat-mongodb-data:/data/db
+Exec=mongod --noauth
+
+[Install]
+WantedBy=default.target

projects/devops/artifacts/librechat-podman/librechat.container

@@ -0,0 +1,24 @@
+[Unit]
+Description=LibreChat
+Requires=librechat-mongodb.service
+After=librechat-mongodb.service
+
+[Container]
+Image=registry.librechat.ai/danny-avila/librechat-dev:latest
+ContainerName=librechat
+Network=librechat.network
+PublishPort=3080:3080
+Environment=HOST=0.0.0.0
+Environment=MONGO_URI=mongodb://librechat-mongodb:27017/LibreChat
+EnvironmentFile=%h/librechat/.env
+Volume=%h/librechat/.env:/app/.env:Z
+Volume=librechat-data:/app/data
+Volume=%h/librechat/uploads:/app/uploads:Z
+# custom endpoints (Ollama/litellm): odkomentovat a vytvorit soubor
+#Volume=%h/librechat/librechat.yaml:/app/librechat.yaml:Z
+
+[Service]
+Restart=on-failure
+
+[Install]
+WantedBy=default.target

projects/devops/artifacts/librechat-podman/librechat.network

@@ -0,0 +1,2 @@
+[Network]
+NetworkName=librechat

projects/devops/artifacts/podman-systemd-summary.md

@@ -0,0 +1,74 @@
+# Podman + systemd — souhrn diskuse (11.9.2026)
+
+Poznámka: toto je přehled informací a hledisek, **ne hotová rozhodnutí** —
+rozhodnutí o přístupu dělá uživatel po nastudování.
+
+## Historie: `podman generate systemd` (starý model)
+
+- Spustíš `podman run --detach`, pak `podman generate systemd --name X`
+  vygeneruje `.service` unit s napevno zadrátovaným `podman start X` / `podman stop X`.
+- Problémy:
+  - Unit je snapshot příkazové řádky — změna parametrů = ručně přepsat
+    unit nebo regenerovat; drift mezi realitou a unitem.
+  - systemd neví, co se děje — unit sleduje jen "podman start vrátil 0".
+    Kontejner spadne vnitřně → systemd spí, watchdog nefunguje.
+- Deprecated od Podman 4.4, od 5.0 jen bugfixy. LibreChat podman blog
+  (8/2023) ho ještě používá — historický.
+
+## Současný model: Quadlet (od 4.4, komfortně 5.x)
+
+Quadlet je systemd generator:
+- čte deklarativní unity z `~/.config/containers/systemd/user/` (rootless)
+  nebo `/etc/containers/systemd/` (rootful)
+- přípony: `.container`, `.volume`, `.network`, `.pod`, `.kube`
+- při `systemctl daemon-reload` generuje skutečné `.service` unity
+  do `/run/systemd/generator/`
+
+Praktické rozdíly:
+- Deklarativní, idempotentní — unit je zdroj pravdy; změna `Image=`/`Volume=`
+  → `daemon-reload` + `restart` a podman kontejner rekne podle unitu.
+- Životní cyklus v systemd — generovaný service spouští `podman run`
+  na popředí, ne detached; kontejner umře → systemd to vidí → `Restart=on-failure`
+  funguje opravdu, `journalctl -u`, `systemctl status`, závislosti
+  (`Requires=`/`After=`).
+- Volumes a sítě jsou taky unity (`.network`, `.volume`) — v unitu se
+  odkazuješ `Network=librechat.network`, žádné ruční `podman network create`.
+- Auto-update: quadlet defaultně labeluje `io.containers.autoupdate=registry`;
+  `podman auto-update` (typicky timer) porovná digest, pulzne a restartne.
+
+## Třetí cesta: `podman compose` v systemd oneshotu
+
+- `Type=oneshot` + `ExecStart=podman compose up -d` funguje, ale systemd
+  vidí jen wrapper proces — restart-per-container, závislosti a logy
+  per-service zmizí, celý stack = jedna monolitní jednotka.
+
+## Hlediska pro LibreChat (ne rozhodnutí)
+
+- Rootless vyžaduje `loginctl enable-linger` (běh bez loginu); port > 1024
+  bez proxy OK (3080).
+- DNS jména mezi kontejnery = `ContainerName=` z quadlet unitů, ne názvy
+  compose služeb → `MONGO_URI` by mířila na `librechat-mongodb`.
+- Verze podmana v distro repu: Debian/Ubuntu mají staré (4.3.x), quadlet
+  user unity od 4.4 — zkontrolovat `podman --version` před nasazením.
+
+## Zdroje k prostudování
+
+- https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html — kompletní reference quadlet direktiv
+- https://docs.podman.io/en/latest/markdown/podman-quadlet.1.html — přehled generatoru, search paths
+- https://www.redhat.com/en/blog/quadlet-podman — motivace, srovnání s generate systemd
+- https://podman.io/docs/podman-installation — verze v distro repozitářích
+- https://docs.podman.io/en/latest/markdown/podman-auto-update.1.html — auto-update přes registry labely
+- https://www.librechat.ai/blog/2023-08-18_podman — historický (generate systemd), užitečný co kontejnery potřebují
+
+## LibreChat zdroje
+
+- https://www.librechat.ai/docs/local/docker — základní compose instalace
+- https://www.librechat.ai/docs/remote/docker_linux — remote Linux detaily, secrets (CREDS_KEY/CREDS_IV/JWT)
+- https://www.librechat.ai/docs/configuration/dotenv — reference .env proměnných
+- https://www.librechat.ai/docs/configuration/librechat_yaml — custom endpointy (Ollama/litellm přes baseURL)
+
+Připravený návrh unity (před nastudováním, ke zvážení):
+`artifacts/librechat-podman/` v tomto projektu — README + librechat.network
++ librechat.container + librechat-mongodb.container + librechat-meilisearch.container.
+Minimal stack api+mongo (RAG/vectordb/admin-panel vynechány kvůli RAM —
+důvod zrušení OpenWebUI); meilisearch volitelný pro fulltext.

projects/devops/memory.md

@@ -0,0 +1,167 @@
+- 2026-09-11: Projekt založen. Uživatel ho chce jako úložiště pro admin/root poznámky — infrastruktura, servery, provoz, podobně. Záměrně volné zaměření, strukturu a upřesnění odkládá na později. prompt.md naplněn základním homelab kontextem (Proxmox cluster, wood/pivo/nvidia/devlin.hell, Zabbix, zálohy), state.md obsahuje výchozí „kde to je / co dál".
+- 2026-09-11: Presun LibreChat podman topicu z projektu ai do devops (tematicky patri sem). Artefakt librechat-podman presunut z projects/ai/artifacts/ do projects/devops/artifacts/ (README + quadlet unity). Kontext: OpenWebUI zakazano (RAM problemy), jako nahraada LibreChat; uzivatel si tema nejdřív nacte sam a rozhodne o pristupu — agent dodava info, nereshi rozhodnuti. Soucasti presunu i souhrn diskuse o podman+systemd (generate systemd deprecated od 4.4, quadlet jako hlediska, ne hotova volba).
+- 2026-09-11: Doplneni motivace pro LibreChat: chci neco lite, kde snadno muzu menit LLM modely, testovat tool calling, mit preddefinovane system prompty, vyuzivat skills (LibreChat ma vlastni Skills/Agents system). OpenWebUI odstraneno kvuli RAM; LibreChat ma byt lehci alternativa s temito vlastnostmi.
+- 2026-09-13: Research sandbox kontejnerů pro AI harness (LibreChat Code Interpreter). Vybrané řešení: LibreCodeInterpreter (https://github.com/GlydePath/librecodeinterpreter) — komunitní nsjail reimplementace LibreChat Code Interpreter API, Apache 2.0, GHCR image `ghcr.io/usnavy13/librecodeinterpreter` (amd64+arm64, pinovat tag, ne main). Stack: 1 API kontejner + Redis + Garage (S3). 13 jazyků (Python, JS, TS, Go, Java, C, C++, PHP, Rust, R, Fortran, D, Bash), Python REPL pool ~20-40ms exec, ostatní jazyky one-shot. Sandbox default bez sítě; ENABLE_SANDBOX_NETWORK=true zapne inline allowlist HTTPS proxy (pip/npm/cargo instally, cache ve skill-deps volume). Autentizace: x-api-key header nebo URL credentials (LibreChat LIBRECHAT_CODE_BASEURL=https://<key>@host/v1 → Basic auth).
+
+Speciální práva kontejneru (klíčové zjištění z researchu):
+
+- `cap_add: SYS_ADMIN` — nsjail potřebuje clone namespaces, mount, cgroups. NEVYJEDNATELNÉ, bez toho nsjail nefunguje. SYS_ADMIN je nejsilnější kontejnerová capa — kontejner s ní je de facto root co umí mountovat.
+- `cap_add: NET_ADMIN` — pouze pro ENABLE_SANDBOX_NETWORK=true (iptables egress allowlist v sandbox netns). Při offline sandboxech lze vynechat.
+- `security_opt: apparmor:unconfined` — nutné na hostech s AppArmor (Ubuntu/Debian), jinak mount() v nsjailu padá na EPERM. Na distrubu bez AppArmor (Alpine) no-op.
+- `init: true` (tini) — reapuje zombie nsjail/python child procesy.
+
+Význam pro nasazení: API kontejner běží jako near-host privilegia (root + SYS_ADMIN + unconfined) na sdíleném kernelu. Nejedná se o „kontejner izoluje nevěřený kód", ale „API proces musí být skoro-host, aby mohl sám izolovat kód pomocí nsjailu". Skutečná sandbox hranice pro LLM kód je nsjail (PID/mount/net namespaces, seccomp, cgroups, rlimits, non-root UID 1001) — sdílený kernel. Únik z nsjailu = kernel hostu = všechno co na něm běží.
+
+Závěry nasazení:
+- Proxmox VM > LXC pro tento use case (nevěřený LLM kód + near-host capy kontejneru). V LXC by únik z nsjailu dosáhl PVE host kernelu; VM dává druhou hranici + možnost nested virt pro microsandbox později.
+- Alternativa: běží-li Docker VM jako čistý AI stack (LibreChat + interpreter, žádná produkční data), je jeden host logický celek. Na obecném provozním Docker hostu raději dedikovaná malá VM (1.5-2 GB RAM).
+- Rootless podman nefunkční out-of-the-box (user namespace v user namespace, cgroup delegace) — projekt to netestuje; rootful podman/quadlet OK.
+- Kompromis vs oficiální codeapi: ta řeší stejný problém microVM režimem (libkrun), ale stojí 5 komponent + Redis + MinIO.
+- 2026-09-14: Záznam reportu od Claude Code (uživatel ho přinesl 2026-09-13): „Negativní zjištění — nvidia.hell / ollama" — co selhalo a co je slepá ulička z incidentů 12.–13. 9. 2026. Plný report uložen verbatim jako artifact: `projects/devops/artifacts/2026-09-13_ollama-nvidia-negative-findings.md` (report odkazuje na history.md a knowledge.md na stroji, ty v workspace nejsou — jen v artifactu).
+
+Shrnutí obsahu:
+
+**Pojistky, které selhaly:** earlyoom zavržen a odinstalován — killuje llama-server uprostřed CUDA initu, čímž nvidia driver natrvalo ztratí napinovanou host paměť (po ~15 killech −9,27 GiB, kladná zpětná vazba: méně RAM → dřívější killy). Výchozí earlyoom konfigurace by nezasáhla nikdy (obě podmínky mem+swap musí platit současně); SIGKILL práh je polovina zadané hodnoty, musí se psát `-s 100,100`. MemoryHigh mezi spotřebou a MemoryMax = past (gemma4 host buffer 5901 MiB padl doprostřed → 84k reclaimů, load visel 600 s bez chyby) — při „rychlém selhání" se MemoryHigh nesmí nastavit. systemd-oomd nepoužit (PSI varianta earlyoomu, čekali by týž leak).
+
+**Slepé uličky v konfiguraci ollamy:** žádný admission control v 0.33.2 (přeteče do CPU vždycky); `OLLAMA_NO_MMAP` neexistuje (issue #4895, PR #6854 nesloučen); navýšení RAM neřeší nic — podmínka mmap disable je `FreeMemory < modelSize + max(8GB, Total/10)`, headroom konstanta 7,5 GiB, potvrzeno 3 loady při různé volné paměti (uživatel RAM naopak ubral z 11,4 na 9,5 GiB); limitování počtu modelů vyhozeno (stroj shodila host RAM, ne VRAM, a MAX_QUEUE nesahá na sekvenci loadů); upgrade na 0.34.0 nic řeší; `OLLAMA_KV_CACHE_TYPE=q4_0` globálně rozbíjí modely s `n_embd_head_k=80` (granite-code padl 6×, stále nastaveno, neopraveno); gemma4 se na stroj nevejde nikdy (Per-Layer Embeddings drží embeddingy na CPU záměrně, host drží 5901 MiB i při 16 GB volné VRAM; kontraintuitivně: čím prázdnější karta, tím spíš se mmap vypne).
+
+**Chyby v systemd konfiguraci:** StartLimit* patří do `[Unit]` (v `[Service]` se tiše ignorují); `systemctl show` property je `RestartUSec`; MemoryMax nelimituje swap → s 32 GB swapu thrashing místo OOM killu, tvrdý strop až MemorySwapMax; instalátor ollamy bezpodmínečně přepisuje unit soubor (vlastní nastavení do drop-inu, ne kopírování unitu); limity z 12. 9. z override.conf nevysvětleně zmizely (21:10 zapsány, 21:44 pryč) — příčina nezjištěna, proto záloha override.conf.bak-20260913; v drop-inu překlep `LLAMA_MAX_LOADED_MODELS` (má být OLLAMA_).
+
+**Co nástroje neukážou:** napinovanou paměť nevidí ps/nvidia-smi/systemd-cgtop/proc-meminfo (AnonPages 135 MiB, ale anon sum 9,4 GiB) — jediný indikátor je `nr_foll_pin_acquired − nr_foll_pin_released` v /proc/vmstat (skript ~/bin/nvidia-reload na nvidia.hell); sar dopad „unaccounted" paměti z 13:40 vysvětlen jako týž leak; restart ollamy leak neuvolní — paměť uteče z cgroup do system.slice, uvolní jen driver teardown/reboot; Proxmox ballooning nevhodný pro LLM stroje (počítá cíl z volné paměti hostitele, ~10 MB/s navýšení vs 17 s load modelu).
+
+**Opravené chybné závěry:** spouštěčem nebyl LibreChat (jen zesilovač — retry po timeoutu), ale samotný model; embedding drží nanobot.hell (192.168.4.64), ne LibreChat — nanobot je zdroj dávek desítek requestů přes ~10 modelů; regrese 0.32.10 není jen Vulkan na iGPU (my CUDA + diskrétní karta, jiný spouštěč, stejný `--load-mode none`, potvrzuje #18373); leak vzniká i při zrušení loadu vlastním schedulerem po odpadnutí klienta (5,19 GiB) — nezáleží na tom, kdo llama-server ukončí, ale že to bylo uprostřed loadu.
+
+**Upstream (otevřené/neopravené):** #18373 load regrese (2m34s vs 28s), #10104 zavřen bez řešení, #10341 gemma RAM na RTX 4060 Ti 16 GB (stejná karta, duplikát #10040), #8654 memory check vs mmap, #4895+PR#6854 mmap řízení. Problém široce hlášený, upstream neřeší.
+
+**Drobnosti k opravě (otevřené):** zabbix-agent má defaultní `Hostname=Zabbix server` (má být nvidia); llama-server `--log-verbosity 4` (journald žral 1,9 % CPU, zaplevelený journal); LibreChat titleConvo posílá druhý souběžný požadavek na týž model; earlyoom ve stavu `rc` — zbývá `apt purge` (na disku /etc/default/earlyoom a .bak).
+
+Koresponduje s dřívějším zjištěním z projektu ai (2026-09-13): Ollama na nvidia.hell v praxi nepoužitelná, memory watchdog zabíjí llama-server. Tenhle report dodává root cause: kill uprostřed CUDA loadu → leak napinované paměti, kterou neukáží standardní nástroje.
+- 2026-09-14: Záznam druhého reportu od Claude Code: „Ollama na nvidia.hell — ucelený report" (stav k 2026-09-13 21:30). Uložen verbatim jako artifact: `projects/devops/artifacts/2026-09-13_ollama-nvidia-full-report.md`. Je to nadstavba předchozího „Negativní zjištění" reportu (uložený den předtím) — obsahuje kauzální řetěz, ověřená fakta, aktuální stav a todo list.
+
+**Kauzální řetěz (5 kroků):** (1) ollama rozhoduje „fits alongside existing models" podle VRAM, ne volné RAM → pustí model i při system_free 115 MiB; (2) týž dechem vypne mmap (podmínka na 9,5 GiB stroji nesplnitelná nikdy) → model jde do anonymní paměti místo page cache; (3) gemma4 PLE drží 5,9 GiB host bufferu navíc; (4) RAM dojde → swap thrashing (pswpin 4512/s, %system 90 %, load 81, SSH nedostupné 45 min); (5) přerušený load → leak napinované paměti. Body [1] a [2] si odporují v téže vteřině.
+
+**Nová fakta oproti předchozímu reportu:**
+- **correction: rmmod nvidia driveru leak NEUVOLNÍ** — ověřeno 20:20, proběhl čistě, foll_pin delta bit za bit stejná (2 307 318 stránek). Moje předchozí shrnutí říkalo „uvolní ho jen driver teardown nebo reboot" — platí **jen reboot** (ověřeno 20:26: MemAvailable 89 MB → 7,6 GiB). Skript `~/bin/nvidia-reload` na stroji je tedy bezcenný.
+- **Cgroup pojistka funguje a je ověřená**: `MemoryMax=6G`, `MemorySwapMax=0` (klíčový řádek — nedostupnost dělal swap thrash, ne OOM; MemoryMax sám swap nelimituje), `CPUQuota=200%`, `CPUWeight=20`, MemoryHigh záměrně vynechán. Plus SSH ochrana (`OOMScoreAdjust=-900`, `MemoryMin=32M` v ssh.service.d/10-oom-protect.conf). Zátěžový test 16:55–17:05 (gemma4 load, SSH heartbeat à 2 s): 240/240 úderů, 0 výpadků, load max 3,41 (vs 81 při incidentu), MemAvailable min 3204 MiB.
+- **Diagnostika OOM**: `dmesg` rozlišuje `constraint=CONSTRAINT_MEMCG` (pojistka zafungovala) vs `CONSTRAINT_NONE/global_oom` (stroj sežraný leakem, pojistka se ke slovu nedostala). `failed (Result: oom-kill)` tedy neznamená automaticky zafungovaný strop.
+- **První výskyt `disabling mmap` v journalu je 2026-06-05** — předtím 13 měsíců čisto. Jde o regresi, ne stávající vlastnost.
+- **`sar` chybějící vzorek = sám o sobě důkaz** (stroj nestíhal ani cron à 10 min) — datování začátku incidentu.
+- **Zavržené nově:** zvedání `OLLAMA_LOAD_TIMEOUT` („turns a hard failure into a slow success" — jen by prodloužilo thrashing); Proxmox ballooning → řešení `balloon: 0` + pevná paměť (pvestatd počítá cíl z volné paměti hostitele, ~10 MB/s vs 17 s load modelu).
+- **Capability `tools` ≠ model nástroje použije**: mistral:latest dostal stejných 5 nástrojů jako glm-5.3, nezavolal ani jeden; flag říká jen, že šablona podporuje tools. Seznam modelů bez `tools` capability (nikdy nebudou fungovat): llama3, llama2-uncensored, tinyllama, aya, phi4, phi3.5, codellama, exaone-deep, deepseek-coder-v2, granite-code:8b.
+- **Prostředí:** VM pod pve.hell (192.168.4.47), RAM snížena 11,4 → 9,5 GiB, swap 32 GB swappiness=60, 4 jádra, RTX 4060 Ti 16 GB, ollama 0.33.2 nativně. Skutečný zdroj zátěže = nanobot.hell (192.168.4.64), LibreChat jen zesilovač.
+- **Kuchařka pro triáž** (awk foll_pin delta, kontrola cgroup limitů — už jednou zmizely, constraint grep, journalctl IP grep, sar postmortem) + **zálohy a rollback** (override.conf.bak-20260913, ~/backup/ollama-20260912-2108/, upgrade skripty).
+
+**Otevřené body (prioritně, z §11):** (1) zastavit dávky z nanobot.hell — bez toho leak zpátky během minut; (2) retest cgroup pojistky bez MemoryHigh (odblokováno rebootem, kritéria: heartbeat bez výpadku, MemAvailable > 2 GiB, constraint=MEMCG); (3) doladit MemoryMax podle memory.peak z retestu; (4) rozhodnout osud gemma4 (PLE ~5,9 GiB host bufferu, na 9,5 GiB stroji nikdy); (5) OLLAMA_KV_CACHE_TYPE=q4_0 zrušit nebo nepoužívat granite-code; (6) drobnosti: apt purge earlyoom, log-verbosity 4, zabbix Hostname, LibreChat titleConvo, otázka monitoringu (hlídač co killuje = zavržená cesta).
+
+**Stav po rebootu 20:26:** stroj zdravý (MemAvailable 7,6 GiB, 0 OOM killů), pojistka aktivní ve správné podobě.
+- 2026-09-14: correction: K bodu „Zastavit dávky z nanobot.hell (192.168.4.64)" z reportu i mého shrnutí z 2026-09-14 — nanobot.hell **není trvalý zdroj zátěže**. Dávky chat requestů přes ~10 modelů byly **testovací tool-calling requesty** (testy schopností lokálních modelů, viz projekt ai, memory 2026-09-12/13 — skript `projects/ai/artifacts/ollama-toolcall-test.py`). Jednorázová testovací zátěž, ne provoz.
+
+Běžný provoz nanobota na lokální ollamu **nesahá**: používá ji jen na (a) embeddingy (`qwen3-embedding:0.6b` pro wiki skill, periodicita z wiki syncu) a (b) cloud modely (`:cloud` presety, `glm`/`kimi` — ty neběží lokálně, jen se proxy přes ollama endpoint). Chat na lokálních modelech není součást provozu.
+
+Důsledek pro open body: bod 1 reportu („zastavit dávky z nanobotu — bez toho leak zpátky během minut") **neplatí jako provozní riziko**, jen jako poučení pro případné budoucí testovací dávky. Zbylé open body (retest pojistky, MemoryMax, gemma4, KV_CACHE_TYPE, drobnosti) zůstávají. Trvalé součásti povrchu nanobot→ollama zůstávají embeddingy — izolace embeddingů na samostatný statický server (llama.cpp/vLLM) tím dává ještě větší smysl: po ní lokalně nezůstane téměř žádný nanobot provoz, který by ollamu mohl shodit.
+- 2026-09-14: Závěr embed-parity snažení (qwen3-embedding:0.6b, ollama vs llama.cpp server na :8081, `--pooling last`): parita **neexistuje** — stejné vstupy dávají fundamentálně odlišné vektory (i jednotokenový vstup `cat` → cosine 0,36; delší vstupy 0,87–0,93), reuse ollama blobu v llama.cpp paritu nezajistí, pooling ani input wrapping (speciální tokeny, chat template) rozdíl nevysvětlují (vše systematicky vyzkoušeno a vyloučeno). Uživatelovo závěrečné rozhodnutí: **při přechodu na čistý llama.cpp se reindexuje celá wiki báze** — žádná snaha o bezreindex migraci; přepnout endpoint v wiki/config.yaml na nvidia.hell:8081 + full reindex jedním krokem.
+- 2026-09-14: Z článku "10 Linux Tools" potvrzený stávající tooling: uživatel používá tmux, lazydocker, bat, mosh. Z výčtu nevyužité kandidáti: fzf, zoxide, ripgrep, fd, delta, btop.
+- 2026-09-14: Druhý článek ("10 CLI Tools That 10x Backend Productivity") — potvrzeno: just už zkoušel a líbí se mu hodně (jedina výtka: málo rozšířený), jq používá, zůstává u curl (httpie viděl, ale nepřepnul). Další kandidáti z článku k nezavedení: watchexec/entr, xh, eza, mise, pgcli, gh.
+- 2026-09-14: Z článku (Medium, DataExpert, 2026-09-03) a online verifikace — poznámka ke stacku DuckDB + Apache Iceberg + dbt:
+
+Use case: celý enterprise lakehouse workflow (incremental loading, SCD Type 2, partition pruning, schema evolution, data quality testy, compaction) lze prototypovat a učit na laptopu za $0, místo placeného Snowflake/Databricks compute. dbt-duckdb adapter = stejné SQL/modely lokálně i na produkci (Snowflake/BigQuery), mění se jen dbt target. Relevance pro homelab: levná varianta pro vlastní analytické pipeline na malých/ Středních datech (10–100 GB), kde by jinak byl nutný Spark cluster.
+
+Ověřené fakta (primární zdroje):
+- DuckDB v1.5.3 (2026-05-29): plná podpora zápisu do Iceberg tabulek — MERGE INTO (merge-on-read, positional deletes), ALTER TABLE (schema evolution, metadata-only), partition transforms bucket/truncate, Iceberg V3 (deletion vectors jako Puffin, VARIANT, TIMESTAMP_NS). Dřív jen čtení; zápis vyžadoval Spark. Zdroj: https://duckdb.org/2026/05/29/new-iceberg-features a https://duckdb.org/2025/11/28/iceberg-writes-in-duckdb
+- DuckLake v1.0 (2026-04-13): lakehouse formát, metadata v SQL databázi (catalog SQLite/Postgres/DuckDB) místo metadata souborů v object storage; data inlining (default threshold 10 řádků) řeší small-file problem; volitelná Iceberg kompatibilita. Zdroj: https://ducklake.select/2026/04/13/ducklake-10/
+- Apache Polaris: free self-hostable Iceberg REST catalog, top-level Apache projekt (únor 2026) — náhrada Hive Metastore/Glue pro lokální setup.
+- AWS acquirenul DuckLabs (tým za DuckDB, srpen 2026); projekt zůstává MIT pod nezávislou DuckDB Foundation.
+
+Benchmarky jen z Medium článku, neověřitelné, brát s rezervou: FinQore pipeline 8 h → 8 min (60×, migrace z Postgres); dashboard dotazy 200–400 ms vs 2–5 s Snowflake X-Small; MotherDuck 6–7× rychlejší než ekvivalentně ceněné Snowflake/Redshift na 10–100 GB.
+
+Limity stacku: DuckDB 1 writer (multi-process writes selhávají), Iceberg+Parquet 2–3× pomalejší než nativní DuckDB formát, small-file/manifest explosion se na laptopových datech neprojeví — produkční operační zkušenost se musí nabýt na produkci.
+- 2026-09-14: Poznámka z článku (Medium, Jesse L, ~2026-11): **Posting** — TUI HTTP klient jako alternativa k Postman/Insomnia. Relevance pro homelab: běží v terminálu přes SSH, takže se dá testovat API přímo ze stroje, který na něj dosáhne (uvnitř VPC, za bastionem, interní služby v Proxmox/LXC) — žádný port forwarding ani tunel GUI klientu.
+
+Klíčové fakta:
+- Python + Textual framework; zdroj https://github.com/darrenburns/posting, dokumentace https://posting.sh; verze k psaní článku v2.10.0
+- Instalace: `uv tool install --python 3.13 posting` (izolovaný Python, nesahá na systémovou verzi); Homebrew/NixOS oficiálně nepodporované
+- Requesty jsou čitelné **YAML soubory** (`.posting.yaml`), kolekce = adresář — commitovatelné vedle kódu, čitelné diffy v PR, žádný export/import JSON s generovanými ID
+- Prostředí přes `.env` soubory: `posting --env dev.env` / `posting --env staging.env` — stejné env soubory jako zbytek projektu, tajemství se necommitují
+- Import z Postman/OpenAPI: `posting import -t postman collection.json` / `-t openapi openapi.yaml` — z OpenAPI specu lze vygenerovat sadu requestů bez ruční práce
+- Klávesy: `Ctrl+P` command palette (jako VS Code), `Ctrl+J` odeslat, Tab/j/k navigace, jump mode s písmeny na widgetech
+- Konfig: `~/.config/posting/config.yaml` (témata, keybindings, default headers) → vhodné do dotfiles repa; default kolekce `~/.local/share/posting/default`
+- `posting locate config` / `posting locate collection` vypíše cesty
+
+Kdy se nehodí: automatizované testy/CI (na to pytest+httpx nebo newman), sdílené workspaces/mock servery (komerční klienty), API design/dokumentace.
+
+Alternativy: **atac** (Rust TUI, podobný cíl), **httpie**/**curlie** (CLI, rychlejší na jednorázovky), **Bruno** (GUI, ale stejná file-based Git-friendly filozofie).
+
+Vzetá idea i bez instalace: API requesty patří do repa jako soubory vedle kódu, který testují — ne do proprietárního formátu v cizím cloudu.
+- 2026-09-14: Poznámka z článku (Medium, Jesse L) + dohledané info z primárních zdrojů: **below** — "time traveling resource monitor" od Meta (facebookincubator), Rust TUI. Neustále nahrává detailní stav systému (per-process, per-cgroup, PSI) na lokální disk a umožňuje replay jakéhokoli okamžiku minulosti: `below replay -t "3m ago"`. Zaplněná díra: live monitory mají detail bez paměti, metriky (Prometheus/Zabbix) paměť bez detailu — "který proces to způsobil v 3:07" neodpoví ani jeden.
+
+Relevance pro homelab (nvidia.hell incident 12.–13. 9.): přesně tenhle use case — swap thrash, SSH nedostupné 45 min, po návratu žádné per-process data. below s cgroup pohledem + PSI by ukázal kauzální řetěz zpětně. PSI (Pressure Stall Information) je relevantní i jako koncept: "disk je busy" vs "procesy čekají na disk" — tlak, ne vytížení, ukazuje bottleneck.
+
+Ověřená fakta (primární zdroje):
+- Repo: https://github.com/facebookincubator/below, Apache 2.0, ~2,5k stars. Poslední release **v0.11.0 (24. 9. 2025)** — article verze potvrzena. Vývoj: Meta resource control team (kernel/container/hardware lidi) s inputem atop power userů.
+- Balíčky: **Fedora 34+, Alpine 3.17+, Gentoo (sys-process/below), Amazon Linux 2023.9**. **Debian/Ubuntu apt balíček NENÍ** — na Debian strojích (celý Proxmox cluster, LXC) nutné `cargo install below` z source (build deps v docs/building.md: clang, libelf-dev, libssl-dev, zlib1g-dev…).
+- Dlouholeté defekty atopu, proti kterým below stavěli (Fedora Magazine): žádná cgroup podpora; custom delta compression ztrácí data zrovna pod resource pressure; strná learning curve.
+- Comparison doc (oficiální): below "goes to great lengths to avoid priority inversions during host resource contention"; **žádná vestavěná komprese dat — doporučují btrfs transparent compression**. Zbylé alternativy: htop (žádná historie), sysstat/sar (binárka, žádný interaktivní interface, žádné cgroups), cAdvisor (cgroup1 only, vyžaduje externí storage), collectd (žádné UI).
+- Subcommandy: `below live` / `below replay -t "5m ago"` / `below dump` (JSON/CSV/OpenMetrics → Prometheus/Grafana, contrib/grafana) / `below snapshot` (replayovatelný soubor time range → přiložit k incident ticketu). Klíče TUI: **t/T** vpřed/vzad, **p** process view, **s** system view, **z** zoom do cgroup, **?** help.
+- Data ukládá do **/var/log/below/store** — nutné ohlídat místo na disku (nahrávání běží continuous, retention konfigurovatelné).
+
+Bezpečnost (důležité při instalaci):
+- **CVE-2025-27591 / RUSTSEC-2025-0149** (CVSS 7.3): do v0.8.1 below vytvářel world-writable `/var/log/below` (mode 0777) → symlink attack = lokální privilege escalation. **Opraveno od v0.9.0** — instalovat jen >=0.9.0, současný v0.11.0 čistý.
+- Dále v0.8.1 i po opravě: vnitřní data ve `/var/log/below/store` world-readable — info leak pro neprivilegované lokální uživatele.
+
+Limity: Linux only, **cgroup v2 only** (Proxmox/Debian moderní = OK), root pro plnou viditelnost, per-host (žádný fleet view), musí běžet dopředu ("kouřový detektor" — po incidentu instalovaný below nic neříká).
+
+Neověřitelné/nezjištěné: přesná spotřeba místa na disk per den a reálný CPU overhead daemonu — v dokumentaci čísla nejsá,Community údaje chybí; před nasazením na stroj s malým rootem změřit vlastní.
+- 2026-09-14: Z článku o ncdu (Medium, Jesse L, ncdu 1.19): uživatel ncdu aktivně používá a je spokojený. Vyhodnocení tipů z článku:
+
+Pro uživatele potenciálně nové/užitečné:
+- **Export/import scanu**: `ncdu -0 -o scan.json <dir>` (scan do JSON bez UI) + `ncdu -f scan.json` (prohlížení kdekoli) — offline analýza, scan pod rootem → prohlížení pod běžným uživatelem, scp JSON na jiný stroj, týdenní scany z cronu → diff růstu adresářů („roste 3 GB/týden od března").
+- **`-r` read-only** — na produkci zakáže delete klávesu `d`; doporučenej habit `ncdu -rx -o /tmp/scan.json /`.
+- **`C` sort podle počtu položek** — najde adresáře s miliony malých souborů (nevyniknou podle velikosti, ale jsou pomalé na zálohu/smazání).
+- **`-e` extended info** — mtime v detailech (`i`), rozlišení starého bordelu vs čerstvého nárůstu.
+- **`b`** — otevře shell v prohlíženém adresáři.
+- **`--exclude-caches`** (CACHEDIR.TAG), **`--exclude-kernfs`** (procfs/sysfs), **`-q`** quiet mode pro pomalé SSH.
+- **ncdu 2.x** — rewrite v Zigu, rychlejší na obřích stromech (miliony souborů), lepší hardlink handling; distribuce většinou shippují 1.x, interface téměř identický.
+
+Zbytek článku (základní navigace, instalace, `-x`, alternativy gdu/dust/duf/baobab) známý/irrelevantní.
+- 2026-09-14: Potvrzený top tip z ncdu článku: kombinace `ncdu -0 -o scan.json /var` → `ncdu -f scan.json` — uživatel ji hodnotí jako největší přínos (mega hodí se) — přenos výsledků na jiný stroj, pozdější zkoumání bez rescenu, zvlášť u velkých stromů s mnoha soubory.
+- 2026-09-14: Uživatel preferuje rsync místo scp pro přenos souborů (např. ncdu scan JSONů mezi stroji). V budoucích doporučeních a skriptech používat rsync, ne scp.
+- 2026-09-14: Doplněná čísla ke studii HDD spolehlivosti (Siemroth & Park, "Are There Manufacturer Differences in Hard-Drive Reliability?", IEEE Transactions on Cloud Computing 14(2), pp. 1015–1024, DOI 10.1109/TCC.2026.3679404; data Backblaze 2013–Q2/2025) — k výchozímu článku z VTM.cz přidáno.
+
+Primární zdroje:
+- https://arxiv.org/abs/2606.29078 (arXiv, plný text: https://arxiv.org/html/2606.29078)
+- https://doi.org/10.1109/TCC.2026.3679404 (IEEE Xplore)
+- https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data (Drive Stats dataset, CSV + Iceberg)
+- Sekundárně: https://www.tomshardware.com/pc-components/hdds/peer-reviewed-study-of-443000-backblaze-drivers-ranks-hgst-most-reliable-and-toshiba-least
+
+**Hazard ratios vůči Seagate (Table I, robustní SE, p<.001 pokud není uvedeno jinak):**
+- Cox: HGST 0,395 (SE 0,009), Toshiba 1,070 (SE 0,033, signifikantní jen na 5 % — nejnástojnější rozdíl dvojice), WD 0,514 (SE 0,021), teplota 1,021/°C
+- Weibull: HGST 0,411, Toshiba 1,073, WD 0,520 — oba modely do 2 p.b. od sebe, výsledky robustní
+- Test HGST = WD: p = 0,000 — HGST signifikantně lepší než WD i po akvizici (možný shared technology/procedures od 2012)
+
+**Vzorek (detaily přípravy dat):**
+- 443 156 HDD; 442 998 s kladnou durací; v regresích 442 992 (6 bez teplot); 21 195 s neznámým datem instalace vyloučeno (<5 %); 4 Samsung HDD a SSD vyloučeny
+- 146 943 disků (~31 %) vyřazeno bez poruchy (Backblaze personal communication: upgrade na větší kapacity, úspora proudu) — right-censored, v modelech ponechány
+- Jen 0,52 % disků má duraci > 10 let → výsledky jen krátkodobá/střednědobá spolehlivost
+
+**Teplota (Table I):** HR 1,021 na 1 °C; 10 °C → 1,021^10 = 1,231 ≈ +23,1 %. Vnitřních 90 % průměrných teplot v datech: 22,5–40 °C. Příklad z paperu: disk na 40 °C s AFR 2 % → snížení o 10 °C dá ~1,625 %.
+
+**Kapacita (Table III, lineární člen místo dummies):** HR 0,966 na 1 TB (−3,4 %, p<.001; Weibull 0,961). Footnote: 1TB disk s AFR 2 % → 2TB disk ~1,93 %. Vysvětlení: novější výrobní procesy (Damascene head fab u WD), heliová náplň (nižší aerodynamický odpor, méně tepla, méně opotřebení ložisek), posun poptávky k enterprise; SMR výjimka (zvyšuje komplexitu, spíš nepřispívá). Form factor 2,5" neověřitelný — jen ~0,6 % vzorku.
+
+**Pozice v datacentru (Table II, cluster controls, podvzorek 355 429 disků — ztráta ~90 000, cluster proměnná až od Q2/3 2023):**
+- 7 clusterů, HR: cluster 20 = 1,287 (nejhorší), 31 = 1,229, 50 = 1,154, 40 = 0,736, 52 = 0,511, 60 = 0,489 (nejlepší) → worst/best ≈ 2,63× i po konrolách (výš bez kontroly teploty)
+- S cluster controls: HGST 0,833, Toshiba 1,029, WD 0,471 — pořadí a poměry značek prakticky nezměněné; autoři ale preferují Table I (větší vzorek)
+
+**Věk disků (Figure 2, non-parametrický odhad, Epanechnikov kernel bw 5 měsíců):**
+- Do 50 měsíců žádná značka > 2 poruchy/1000 disků/měsíc (~2,4 % anualizovaně)
+- 50–100 měsíců: Toshiba 5–6/1000/měsíc, ostatní ≤ 2,5/1000/měsíc
+- Toshiba po 60 měsících: >4× nárůst měsíční poruchovosti vs mladý věk — spike, který žádná jiná značka nemá
+- Seagate stabilní, HGST mírně volatilní ale nejnižší; WD lepší než HGST po ~40 měsících (ale malý vzorek — WD ve velkém až od ~2024, <1000 disků at risk v 60. měsíci; HGST <1000 až ~115. měsíc)
+- Věk není lineární ani monotónní efekt; Toshiba se v průběhu života mění až 5×
+
+**Ekonomika (rovnice P_premium ≤ Δ×C×L):**
+- Příklad: L=10 let, C=$100 (náhrada), Δ Seagate→HGST = 0,02×0,59 = 0,0118 → max přirážka za HGST $11,8
+- Backblaze (~300k aktivních disků): zdvojnásobení AFR 1 % (Toshiba)→2 % (Seagate) = +3000 výměn/rok; při stejné ceně disků flota Seagate stojí >$3m navíc
+
+**Srovnávací kontext Backblaze Drive Stats (Q1 2026 snapshot, primární zdroj backblaze.com):** 341 263 disků, 1 030 poruch, AFR Q1/2026 = 1,24 %; rok 2025 AFR = 1,36 % (115,6M drive-days, 4 317 poruch); lifetime AFR = 1,39 % (529,9M drive-days, 20 212 poruch). Podíl značek: Toshiba 33,93 %, Seagate 33,02 %, WDC 25,30 %, HGST 7,75 %. Dataset open-source, CSV i Apache Iceberg formát (query přes DuckDB/Trino/Snowflake).
+
+Praktický takeaway pro nákup disků do homelabu: HGST už nejde koupit nové (WD brand zrušen), takže reálné pořadí dnešních značek: WD > Seagate ≈ Toshiba, ale Seagate/Toshiba ~2× vyšší poruchovost; nižší teplota a vyšší kapacita pomáhají. Závěry platí pro enterprise disky v datacentru — na konzumerní disky nejsou nutně přenositelné, workload data nejsou k dispozici.

projects/devops/prompt.md

@@ -0,0 +1,14 @@
+# DevOps / infrastruktura
+
+## Účel
+Ad-hoc admin/root poznámky: infrastruktura, servery, provoz, věci k vyřešení.
+
+## Kontext
+- Homelab: Proxmox cluster, GPU host nvidia.hell (Ollama), servery wood.hell, pivo.hell, devlin.hell, LXC kontejnery
+- Samostatný Linux server s Dockerem (vedle Proxmox clusteru)
+- Monitoring přes Zabbix
+- Zálohování: wood.hell → pivo.hell (recursive)
+
+## Scope
+- Uživatel bude strukturu a zaměření projektu postupně upřesňovat — projekt je teď nový a záměrně volný.
+- Zapisovat sem poznámky o infrastruktuře, provozu a admin úkolech.

projects/devops/state.md

@@ -0,0 +1,16 @@
+---
+timestamp: draft
+---
+
+# Project devops
+
+## Kde to je
+- Projekt založen jako volný prostor pro admin/root poznámky o infrastruktuře a provozu.
+- LibreChat: běží jako podman kontejnery; jako Code Interpreter sandbox vybrán LibreCodeInterpreter (nsjail, 3 kontejnery). Research hotový (2026-09-13), rozhodnutí o nasazení (sdílená Docker VM vs dedikovaná Proxmox VM) ještě nepadlo.
+- Ollama na nvidia.hell: po incidentech 12.–13. 9. 2026 zaevidován root cause pádů — kauzální řetěz: ollama rozhoduje load podle VRAM ne volné RAM + vypíná mmap (podmínka na 9,5 GiB stroji nesplnitelná nikdy, regrese od 2026-06-05) + PLE host buffer u gemma4 + přerušený load leakuje napinovanou host paměť (neviditelná pro ps/nvidia-smi/cgtop, detekce jen `nr_foll_pin` delta v /proc/vmstat), uvolní **jen reboot** (rmmod driveru ověřeně NE). Cgroup pojistka (`MemoryMax=6G`, `MemorySwapMax=0`, bez MemoryHigh) ověřena zátěžovým testem: 240/240 SSH heartbeatů, load 3,41 vs 81 při incidentu. Skutečný zdroj zátěže = nanobot.hell (dávky přes ~10 modelů + embedding), LibreChat jen zesilovač. Reporty v `artifacts/2026-09-13_ollama-nvidia-full-report.md` (ucelený, s kuchařkou pro triáž) a `artifacts/2026-09-13_ollama-nvidia-negative-findings.md` (negativní zjištění), shrnutí v memory.md 2026-09-14. Zavržené cesty: earlyoom i jakákoli externí kill varianta, MemoryHigh pod MemoryMax, navýšení RAM (headroom konstanta 7,5 GiB), limit počtu modelů, OLLAMA_LOAD_TIMEOUT, upgrade ollamy, mmap override (neexistuje), ballooning (`balloon: 0` + pevná paměť), rmmod jako remedy.
+
+## Co dál
+- Rozhodnout umístění LibreCodeInterpreter (AI stack VM vs dedikovaná VM) a nasadit — viz memory.md 2026-09-13 pro capability požadavky (SYS_ADMIN, NET_ADMIN, apparmor:unconfined).
+- Ollama open body dle priority (report §11): (1) ~~zastavit dávky z nanobot.hell~~ — **neplatí jako provozní riziko** (dávky byly testovací tool-calling requesty, běžný provoz nanobot nesahá na lokální modely); (2) retest cgroup pojistky bez MemoryHigh (odblokováno rebootem; kritéria: heartbeat bez výpadku, MemAvailable > 2 GiB, dmesg constraint=MEMCG); (3) doladit MemoryMax podle memory.peak; (4) rozhodnout osud gemma4 (PLE ~5,9 GiB host bufferu, na 9,5 GiB stroji nikdy); (5) `OLLAMA_KV_CACHE_TYPE=q4_0` zrušit nebo nepoužívat granite-code; (6) drobnosti: `apt purge` earlyoom (rc), llama-server `--log-verbosity 4`, zabbix `Hostname=Zabbix server` → nvidia, LibreChat titleConvo duplicitní requesty, otázka real-time monitoringu (hlídač co killuje = zavržená cesta).
+- Návrh k rozhodnutí: izolovat embedding pipeline (wiki skill) ze ollamy na statický llama.cpp server (`llama-server --embeddings --pooling last`, stejný GGUF, /v1/embeddings) — obejde load path, kde vzniká leak; po ní nanobot nezůstane na lokální ollamě žádný provoz krom cloud proxy. Vyžaduje: úprava wiki_embed.py klienta, config.yaml endpoint, reindex --full.
+- Uživatel bude psát poznámky; podle obsahu doladit strukturu projektu.

projects/en/artifacts/phrases.md

@@ -0,0 +1,5 @@
+# Phrases
+
+| EN | CZ | poznámka |
+|----|----|----------|
+| a means to an end | prostředek k cíli | něco, co má smysl jen jako cesta k cíli, ne samo o sobě; work is a means to an end |

projects/en/artifacts/vocab.md

@@ -0,0 +1,5 @@
+# Vocabulary
+
+| EN | CZ | poznámka |
+|----|----|----------|
+| culprit (!) | viník, původce (problému) | ten, kdo za něco může; the culprit behind the outage |

projects/en/memory.md

@@ -0,0 +1,2 @@
+- 2026-09-16: Vznikl projekt 'en' pro učení angličtiny a psaní různých poznámek. Uživatel schválil název 'en' (zvažovali jsme i 'english' / 'anglictina').
+- 2026-09-16: Uživatel chce v rámci projektu sbírat anglická slovíčka, fráze a části vět. Některá slovíčka jsou pro něj opakovaný boj — ty je potřeba vidět a vracet se k nim.

projects/en/prompt.md

@@ -0,0 +1,13 @@
+# English (en)
+
+## Účel
+Projekt pro učení angličtiny a psaní si různých poznámek.
+
+## Rozsah
+- Poznámky k učení angličtiny: slovíčka, fráze, gramatika, pokroky
+- Různé soukromé poznámky v angličtině (cvičení psaní, deník, …)
+- Cokoliv, co uživatel do projektu uloží
+
+## Jak pracovat
+- Psát soubory do `artifacts/` s popisnými názvy
+- Vysvětlovat v češtině, ukázky a cvičné texty v angličtině

projects/iot/memory.md

@@ -0,0 +1,82 @@
+- 2026-09-09: Založen projekt iot — zaměření na hardware, IoT a bastlení obecně (ESP32, Raspberry Pi, senzory). Motivace: teplotní senzor v pokoji „chlívek" (okno s holubími hřebí), zájem o ESP32 a RPi na testování. Serverové/Proxmox věci zůstávají v projektu proxmox.
+- 2026-09-09: Vytyčeny čtyři témata projektu: 1) znovu zapojit měření teploty/vlhkosti v pokoji „chlívek"; 2) samostatný Proxmox LXC kontejner na MQTT broker; 3) provozovat Home Assistant ve VM na Proxmoxu; 4) otevřená otázka — jak dotáhnout čidla k HA, když jsou fyzicky jinde, hlavně Zigbee a Matter.
+- 2026-09-09: Rozhodnutí k Zigbee architektuře: USB dongle v serveru/RPi odmítnut jako nepraktický — čidla jsou na místech bez počítače, RPi tam mít nechce, brána musí být jednoduchá, spolehlivá a okamžitě funkční (žádný boot, žádný maintenance). Směr: Ethernet Zigbee coordinator (SLZB-06 / UZG-01 typ), umístěný strategicky pro rádiový dosah, připojený přes LAN; Zigbee2MQTT + MQTT broker v LXC na Proxmoxu se k němu dostanou po TCP.
+- 2026-09-09: Rozšíření rozhodnutí o Zigbee bráně: kladné volby — brána nesmí vyžadovat počítač (RPi ani nic jiného na místě čidel), musí být jednoduchá, okamžitě po power-loss funkční, bez boot procesu a maintenance. Navíc: **WiFi nutně, Ethernet kabel vyřazen jako nepoužitelný v daných místech**. Postavení vlastního routeru/bridge z RPi nechce. Max. zásah = přehrání firmware.
+
+Ověřené kandidáty (network coordinator s WiFi):
+
+1. **SMLIGHT SLZB-06p10 / SLZB-06M** — Zigbee 3.0 coordinator, podporuje Ethernet, USB i **WiFi** v jednom; firmware bez OS, okamžitý start; Z2M připojení `tcp://<ip>:6638`; správa přes vlastní web UI (vč. remote flash). Nejrozšířenější v komunitě, Z2M oficiálně podporuje jako síťový adapter.
+2. **SONOFF ZB Bridge Pro (ZBBridge-P)** — WiFi Zigbee brána, **vyžaduje Tasmota flash** (EZSP firmware pro EFR32MG21), poté funguje jako network coordinator pro Z2M (`tcp://ip:8888` přes tasmota ZBBridge režim). Levnější, ale hacknutá cesta — flash přes webový proces, komunitní návody existují (stephengrier.com, haade.fr).
+3. **SONOFF ZBDongle-Max (Dongle-Max)** — Zigbee/Thread PoE dongle (EFR32MG24 + ESP32), podporuje Ethernet, WiFi i USB; síťový mód pro Z2M. Novější kus, méně zavedený v Z2M než SLZB-06, ale funguje jako network adapter.
+
+Zdroj: zigbee2mqtt.io (remote adapter how-to), smlight.tech manual, blakadder.com — vyhledáno, částečně ověřeno (Z2M remote adapter stránka potvrzuje síťový mód SONOFF ZBBridge přes Tasmota).
+- 2026-09-09: Correction k Zigbee meshu: user opravuje dřívější tvrzení, že se Zigbee síť "doroste" k náplňovým čidlům přes mesh. Teoreticky Zigbee je mesh, ale prakticky to u čidel na CR2032 (a malé) baterky nefunguje — čidlo se probudí jednou za čas, odvysílá naměřené hodnoty, a v tu chvíli většinou nikdo jiný nevysílí (routery spí/nemají co přenášet), takže relay cesta přes mesh zařízení reálně nevzniká. Ověřeno prakticky mnohokrát. **Náplňové čidlo musí mít přímý rádiový dohled na coordinator**, jinak má smolíka (ztracené zprávy, odpojené čidlo). Důsledek pro architekturu: umístění WiFi coordinatoru je ještě kritičtější — musí být fyzicky blízko / v dohledu všech čidel, případně více coordinatorů na více místech (každý s vlastní Z2M instancí).
+- 2026-09-09: Volba Zigbee brány: SONOFF ZB Bridge Pro (ZBBridge-P). Důvody: kompaktní provedení, rozumná cena (~29 USD), napájení USB (flexibilní umístění kdekoliv se zásuvkou/USB adaptérem, bez Ethernet kabelu). Přijatý tradeoff: vyžaduje Tasmota flash (EZSP firmware pro EFR32MG21) před použitím jako network coordinator pro Zigbee2MQTT (připojení tcp://ip:8888). Flash je v rámci akceptovaného zásahu (max. přehrání firmware). Odmítnuty: SLZB-06M (dražší, Ethernet-zaměřený tvar), ZBDongle-Max (dražší, PoE dongle tvar).
+- 2026-09-09: User potvrzuje: napájení i Tasmota flash si zvládne sám, žádná asistence od agenta při fyzické instalaci není potřeba. Další krok až po fyzickém pořízení ZB Bridge Pro — pak navázat software stack (MQTT LXC, Z2M, HA VM) na Proxmoxu.
+- 2026-09-09: Téma: Tuya WiFi čidla. User by je rád používal (levná, dostupná), ale problém: mají natvrdo vypálenou HTTPS adresu (cloud endpoint) — lokálně mluvit s nimi nejde přímo. Čidla jsou battery-powered, připojují se na WiFi jen v krátkých časových úsecích, když právě vysílají (probudí se, pošlou data na Tuya cloud, zase spí). Tím pádem: nelze je směrovat do vlastní sítě a čekat na trvalé spojení; lokální integrace by vyžadovala zachytit komunikaci v okamžiku vysílání (prakticky nespolehlivé) nebo přesměrovat DNS (ale čidlo mluví HTTPS na natvrdo daný endpoint — MITM/TLS pinning problém). Zatím otevřená otázka, jak s nimi pracovat, aniž by data šla do Tuya cloudu.
+- 2026-09-09: User vlastní hromadu Tuya čidel, z nich velká část WiFi (historicky vybraná pro nejsnazší zapojení). Tuya aplikace hodnotí jako nahovno, Tuya cloud má omezení počtu API volání (rate limity). Požadavek: vycítání čidel mít plně ve vlastní režii (žádná závislost na Tuya cloudu, žádná API volání). Diskutované cesty: (a) cloud API bridge — nevyhovující, právě kvůli limitům a cloudu; (b) reflash na Tasmota/OpenBK — u WiFi čidel záleží na chipu (Realtek/ESP/Beken), ne vše jde reflashovat, battery čidla navíc vysílají jen krátce; (c) zachytávat Tuya lokální protokol — u battery WiFi čidel nemožné (krátká spojení, HTTPS pinning). Otevřená otázka zůstává: jak dostat existující Tuya WiFi battery čidla do vlastní režie; reálně znamená inventuru — projít jednotlivá čidla, zjistit chipy a určit, která jdou reflashovat, a která jsou mrtvá pro lokální použití.
+- 2026-09-09: Vyřazeny cesty k Tuya WiFi čidlům: reflash nereálný — user má většinou novější Tuya čidla (chipy bez komunitní podpory, ne Beken/ESP generace); sniff/MITM zachytávání hodnoceno jako kravina, nedává to smysl jako režie. Zbývá jediné rozvětvení: (a) Tuya cloud API s rozumným pollingem — teplota/vlhkost se mění pomalu, takže limit volání nemusí být reálný problém, pokud se dotazuje např. jednou za 5-15 min a ne po každém čidle zvlášť; nebo (b) postupná náhrada Tuya WiFi battery čidel Zigbee variantami (brána ZB Bridge Pro už je zvolená). Fyzicky: čidla mluví HTTPS na natvrdo vypálený endpoint — data nelze dostat lokálně vůbec, jediná cesta ven je cloud API.
+- 2026-09-09: Plan rozšířen o Tuya cloud API včítání: polling s nízkou frekvencí, cílově 10-15 min (user preference max 10-15 min). Data se publikují na MQTT jako u ostatních čidel.
+
+Ověřeno na developer.tuya.com (primární zdroj), že cloud REALNĚ ví, kdy hodnota naposledy přišla:
+- GET /v1.0/devices/{device_id} vrací kromě status[] (code/value) také "update_time" (timestamp poslední aktualizace stavu zařízení, sekundy) a "online" flag — stačí z jednoho endpointu.
+- GET /v2.0/cloud/thing/{device_id}/report-logs (nebo /v1.0/iot-03/.../report-logs) vrací per-DP logy s "event_time" pro každý kód — přesná historie kdy co došlo, vč. časů jednotlivých reportů.
+- Tzn. problém "app ukazuje hodnotu starou týden a neumí říct že neplatí" je řešitelný: náš tuya2mqtt script bude porovnávat update_time/event_time proti aktuálním časem a ke každé hodnotě připojí timestamp posledního reálného reportu (a/nebo flag "stale"), takže HA/možné notifikace můžou detekovat mrtvá čidla.
+- 2026-09-09: Upřesnění tuya2mqtt designu: nechat API vrátit update_time pro každé zařízení, držet lokálně poslední známý update_time; pokud se mezi pollly nezměnil, hodnoty se na MQTT nepublikují vůbec (žádný stale flag ve zprávě, žádné opakované posílání stejných dat). MQTT tak zůstane čistý — zpráva = nová data. Detekce mrtvého čidla se pak dělá na straně konzumenta (HA/možný watchdog): absence zprávy na topicu za dlouhý čas = stale/offline; příp. HA MQTT device triggers / last_change sensor. Je to jednodušší a idempotentní, žádné duplikáty v brokeru.
+- 2026-09-09: Ověřeno z Tuya primárních zdrojů (developer.tuya.com membership-service + support.tuya.com): IoT Core **Trial Edition** (free, jen pro osobní/debug použití) — basic resource pack = **26 000 API volání / měsíc** (+ 68 000 messages). Po vyčerpání: přístup omezen, Trial neumí overage (nelze dokoupit), obnoví se začátkem dalšího měsíce. Další Trial limity: max 50 zařízení v projektu, max 10 controllable devices, 1 data center, žádný log backtracking. Trial je navíc oficiálně časově omezený (6 měsíců, pak žádost o prodloužení — dle support.tuya.com lze prodloužit opětovnou žádostí). Rate limit navíc per-endpoint (např. ~10 req/s na některé, 500/s celkové API maximum) — pro náš use case irelevantní.
+
+Spotřeba našeho designu: 1 hromadné volání za poll (GET /v1.0/iot-03/devices/status vrací status pro všechny device_id najednou) — při pollu co 15 min = 96 volání/den = ~2 880/měsíc, tj. cca 11 % kvóty. I s per-device report-logs voláními (pokud bychom chtěli event_time per DP) se do 26k vejdeme, ale hromadný status endpoint to pravděpodobně vyřeší i s update_time. Konec vahy: 15-min poll bezpečně v limitu; 10-min poll taky (~4 320/měsíc).
+- 2026-09-09: Oprava/uhrazení hromadného status endpointu: GET /v1.0/iot-03/devices/status (Get the latest status of multiple devices) — ověřeno v API reference: vrací POUZE code/value per DP, ŽÁDNÝ timestamp (žádné update_time, žádný event_time). Navíc limit max 20 device_ids per volání. Userova zkušenost tedy potvrzena dokumentací — hromadný endpoint pro náš dedup-design (aktualizace dle update_time) NEVYHOVUJE, protože nevrací čas posledního reportu.
+
+Zpětný dopad na design kvót: musí se volat per-device endpoint, který update_time vrací. Kandidáti:
+(a) GET /v1.0/devices/{device_id} (Device Management) — vrací status[] + update_time + online (ověřeno dříve v docs); 1 volání per zařízení.
+(b) GET /v2.0/cloud/thing/batch (Query Device Details in Bulk) — nutné ověřit, zda vrací update_time.
+(c) GET /v2.0/cloud/thing/{device_id}/report-logs — event_time per DP, ale těžší volání.
+
+Matematika s per-device voláním (a) při N čidlech:
+- 10 čidel: poll 15 min = 96 pollů/den × 10 = 960 volání/den ≈ 29k/měsíc — TĚSNĚ PŘES 26k Trial limitem.
+- 10 čidel, poll 20 min: 72 × 10 × 30 = 21 600 — pod limitem.
+- Závěr: per-device read s update_time na Trial edici vyžaduje poll ≥ ~20 min při 10 čidlech, NEBO batch endpoint (b) pokud vrací update_time (ověřit), NEBO Message Service (push namísto pollingu — 68k messages/měsíc kvóta, nutno prověřit).
+
+Dotaz usera "co znamená +68k zprav": 68 000 messages = kvóta Message Service — push zprávy od Tuya cloudu (device status changes doručené aktivně, ne polling). Zatím neověřeno, zda/v jakém formátu to zahrnuje device status reports; potenciálně řeší celý problém (push místo poll), ale vyžaduje ověření API a vlastní endpoint (MQTT bridge / webhook receiver).
+- 2026-09-09: Ověření Tuya Message Service jako skalabilní cesty (místo per-device pollingu): Tuya Message Service používá Apache Pulsar (ne MQTT/HTTP webhook) — po aktivaci subscription na cloud projektu cloud aktivně PUSHuje event data, když se stav zařízení změní (data reporting, offline events, registrace). Klient se připojuje Pulsar SDK/consumerem, cloud doručuje zprávy do fronty, čte se pull-style z Pulsar topicu. Zdroj: developer.tuya.com (Get Messages by Message Queue — device-msg-queue-practice, subscribe-mq, integrate-mq). Klíčové fakty: "If the device status in the project changes, such as registration, data reporting, and offline events, Message Service is used to actively push event data to you with Pulsar" — tedy přesně náš use case, device status reports pushnuté okamžitě po reportu čidla.
+
+Význam pro design: tím pádem NULOVÝ polling nutný pro běžný provoz — čidlo reportuje → cloud pushne zprávu → náš consumer publikuje na MQTT. 68k messages/měsíc Trial kvóta je v pohodě (čidlo reportuje typicky 1-2×/hodinu, 20 čidel = ~1-2k zpráv/den = max ~60k/měsíc, na hraně ale reálně méně, protože ne každý report = nová zpráva pro každé DP). Per-device poll (GET /v1.0/devices/{id}) si necháváme jako bootstrap/fallback (první načtení stavu po restartu, ověření že jsme nezmeškali nic).
+
+Dopad na kvóty: API volání klesnou na minimum (bootstrap + health-check), messages se posunou do 68k kvóty. Skaluje se lineárně s počtem čidel bez nutnosti měnit poll frekvenci.
+
+Otevřené body k doladění: (a) Pulsar consumer běží v našem LXC (Python klient existuje — tuya-iot-pulsar-sdk), (b) formát zprávy obsahuje data + timestamp (nutno ověřit na reálných datech), (c) offline events umožňují detekovat mrtvá čidla pushem, ne pollingem.
+- 2026-09-09: User vytýká principiální problém pollingu: čidlo reportuje klidně každou minutu, ale uživatel to v HA vidí až za 20 minut (worst case = poll period). Tohle je přesně argument, proč polling je špatný model pro čidla, která reportují často. Pulsar push (Message Service) to řeší — zpráva dorazí okamžitě po reportu, tedy latence = sekundy, ne minuty. Tímto je designový směr definitivně: PULL (polling) jen jako fallback/bootstrap, primární tok = PUSH (Pulsar). 20-min poll fallback zůstává jako safety net pro případ výpadku consumeru, ale pro data je hlavní cesta push.
+- 2026-09-09: DEFINITIVNÍ ZÁVĚR k Tuya WiFi čidlům: architektonický slepý konec. Tuya cloud brutálně omezuje přístup k vlastním datům — kvóty (26k API volání/měsíc, 68k messages), Trial limit 50 zařízení, žádný overage dokup, data nutně přes cizí cloud. Žádná z probraných cest (per-device poll, hromadný poll, Pulsar push) tohle neobejde — limit je v samotném modelu "data musí projít Tuya cloud", ne v designu.
+
+Rozhodnutí:
+- Target architektura = Zigbee (ZB Bridge Pro) + MQTT lokálně, plná vlastní režie, žádné kvóty.
+- Alternativa = WiFi senzory ve vlastní režii (ESP32 DIY) publikující přímo na MQTT.
+- Zpracování pravděpodobně v HA, ale ne nutně — MQTT je neutrální sběrnice, konzument může být cokoliv.
+- tuya2mqtt bridge degradován na legacy: běží pro existující Tuya WiFi čidla, dokud se nevymění. Neškáluje a jednou vymře.
+- Migrace postupná: Tuya čidlo umře / slabá baterie / špatné měření → náhrada Zigbee/ESP32 variantou. Žádná aktivní hromadná náhrada zdravých čidel.
+- DŮLEŽITÉ DO BUDOUCNA: nekupovat už žádná Tuya WiFi battery čidla. Lekce: před nákupem čidla ověřit, že data jdou dostat v plné vlastní režii (MQTT-first, žádný povinný cloud).
+- 2026-09-11: User má doma HackRF One a RTL-SDR (+ další SDR hardwar), SDR ho zajímá. Indexované zdroje: GNU Radio World (https://gnuradioworld.com — GNU Radio flowgraphy v prohlížeči přes WebAssembly, WebUSB podpora RTL-SDR/PlutoSDR/HackRF) a PySDR (https://pysdr.org — online učebnice SDR/DSP v Pythonu od Marca Lichtmana). Oba zdroje od téhož autora (777arc), vzájemně propojené — PySDR má ukázkové flowgraphy spustitelné přes GNU Radio World. Zapsáno do notes/notes.md sekce SDR/radio.
+- 2026-09-11: Research: jak se GNU Radio World připojuje k SDR hardware. Ověřeno přímo ve zdrojácích (repo 777arc/gnuradio-world, docs/hackrf.md + editor/src/hackrf.ts + runner/src/hackrf_worker.js):
+
+- Připojení je čistě přes WebUSB (navigator.usb) — žádný server, žádný native driver, žádný helper proces. Funguje jen v Chromiu (Chrome/Edge/Opera); Firefox a Safari WebUSB nemají.
+- Detekce: USB filtr vendorId 0x1d50, productId 0x6089 (HackRF One). Pro RTL-SDR a PlutoSDR analogické filtry.
+- Oprávnění: uživatel klikne „Add" u Device parametru nebo stiskne Run → browser requestDevice() prompt. WebUSB permise je per-origin a přežije zavření tabu; v .grc se ukládá jen USB serial number a runner si zařízení znovu nabhádne přes getDevices().
+- Runtime: editor drží WebUSB, ale USBDevice nikdy nepřechází mezi frames ani do Wasm. runner.html spustí hackrf_worker.js (JS worker), který claimne interface, posílá vendor control requesty (mode/sample rate/bw/freq/gainy — stejné requesty jako libhackrf) a drží 4 paralelní bulk transfery v letu. Data jdou přes shared-memory ring + futex-like control blok do Wasm GNU Radio scheduleru (thread-per-block, SharedArrayBuffer). libhackrf/libusb se do Wasm záměrně nekompiluje.
+- HackRF je half-duplex; jedno fyzické zařízení může vlastnit jen jeden aktivní Source/Sink; víc jednotek OK při explicitních serialech.
+- Linux: browser user musí mít přístup k USB nodu (udev), žádný native program nesmí mít HackRF otevřený. Snap Chromium nemusí USB dosáhnout. Windows: nutná WinUSB binding přes Zadig.
+- Fallback bez HW: device „fake" / „fake:<tone-hz>" vygeneruje testovací tón, žádný USB se neotevírá; kromě toho ukázkové IQ nahrávky streamované z Cloudflare R2 (recordings.gnuradioworld.com).
+- 2026-09-11: GRWire — síťový přístup k SDR pro GNU Radio World (klíčové zjištění, user to chce vyzkoušet):
+- GRWire = malý Rust daemon na stroji se SDR + blok „GRWire Source" v GNU Radio World (v repo 777arc/gnuradio-world, adresář grwire/, first cut 2026-09-10).
+- Dolů mluví SoapySDR (podpora všeho s Soapy driverem: RTL-SDR, HackRF, …), nahoru jeden WebSocket wss:// (protokol grwire.v1: control JSON text frames + IQ binární frames, header 32 B fixed).
+- Setup: na stroji se SDR „grwire serve" → self-signed cert, vytiskne https://host:8073/ (otevřít jednou v browseru, akceptovat cert — jinak https stránka nesmí otevřít wss:// na LAN kvůli mixed content) + wss:// URL s tokenem. Token se ukládá do localStorage, NE do .grc (sharenutý flowgraph nesmí rozdávat přístup k rádiu). Origin allowlist jako defence in depth.
+- Daemon umí mix NCO (offset ladí v pásme bez HW retune glitche) + decimaci halfband kaskádou; Decimation=0 = automatický plán. HackRF nejde pod 1 MS/s hardwarově — 250 kS/s jen přes decimaci; 20 MS/s ci8 = 320 Mbit/s, WiFi nezvládne, proto decimace na straně daemona.
+- Backpressure: flow ack každých 8 frames, max quarter-second za posledním ackem; drop counters per vrstva (dev_overruns/host_drops/net_drops/client_drops), drop-oldest + FLAG_DISCONTINUITY.
+- Gain stages poziční (Stage 1/2/3 → u HackRF LNA/AMP/VGA), dialog relabelne dle rádia; výchozí -1000 = „nedriven" (0 dB je reálný gain).
+- Jeden client najednou (druhý refused, --takeover). Alternativa SoapyRemote z browseru nefunguje (TCP+UDP, raw sockety v browseru nejsou a nebudou).
+- Status: first cut, commit msg přiznává „hackrf signal doesnt look right though, rtl looks good" — RTL přes GRWire OK, HackRF zatím podezřelý; lokální WebUSB HackRF je plně funkční.
+- User to URČITĚ chce vyzkoušet (SDR na jiném počítači, dotáhnout přes síť do browseru).
+
+GNU Radio World self-hosting: ano, opensource (GPLv3+, copyright Marc Lichtman). Build celého stacku ze zdrojáků (README dev quickstart): Ubuntu 24.04+, emsdk 3.1.70, Qt 6.9.1 wasm_multithread, GNU Radio kompilované do WebAssembly bez Pythonu; ~10 GB disk, první build ~1 h. Provoz přes „node server.mjs 8090" — nutné kvůli COOP/COEP headerům (SharedArrayBuffer pro thread-per-block scheduler). Ukázkové IQ nahrávky streamují z Cloudflare R2 (recordings.gnuradioworld.com), CORS povoluje origin portu 8090 — na vlastním portu nahrávky nefungují (nebo vlastní kopie bucketu).
+- 2026-09-11: GNU Radio World repo adresa (user request, poznamenej): https://github.com/777arc/gnuradio-world — GPLv3+, autor Marc Lichtman (777arc). Docker: oficiální prebuilt image neexistuje — v repo není Dockerfile, na Docker Hub / ghcr nic relevantního (jen cizí staré GNU Radio kontejnery, ne GNU Radio World). Self-host = build ze zdrojáků (emsdk 3.1.70 + Qt 6.9.1 wasm_multithread, ~10 GB, ~1 h). Live verze na gnuradioworld.com je aktualní vždy — self-host hlavně kombinovaně s GRWire daemonem na stroji se SDR.
+- 2026-09-11: correction: GRWire zkoušení není urgentní — user řekl „se to vyřeší až a jestli vůbec to budu zkoušet". Self-host (wasm-site artifact z Actions / cargo build grwire) odloženo, nic nepřipravovat, dokud sám neřekne.

projects/iot/prompt.md

@@ -0,0 +1,16 @@
+# IoT / bastlení
+
+## Účel
+Projekt pro hardware, IoT a bastlení obecně — vše od malých deskek po senzory,
+co nepatří do serverových projektů (Proxmox má vlastní projekt).
+
+## Rozsah
+- ESP32 (hardware i firmware)
+- Raspberry Pi na testování
+- Senzory a měření (teplota, …)
+- Další bastlení dle nálady
+
+## Způsob práce
+- Tykání, stručně, technicky.
+- Důraz na nejjednodušší funkční řešení.
+- Fakta a měřené hodnoty ověřovat, ne tipovat.

projects/iot/state.md

@@ -0,0 +1,90 @@
+# State
+
+## Témata projektu
+
+1. **Měření teploty/vlhkosti v „chlívku"** — znovu zapojit (dříve provozované,
+   nyní nedopadá). Detaily hardware a důvod odstavení neznám.
+2. **MQTT broker** — plán: samostatný LXC kontejner na Proxmoxu.
+3. **Home Assistant** — plán: provozovat ve VM na Proxmoxu.
+4. **Otevřená otázka: čidla fyzicky jinde** — jak dotáhnout čidla k HA,
+   když nejsou u HA; hlavně Zigbee (rádiová, potřeba koordinator v dosahu)
+   a Matter (obvykle přes Wi-Fi/Thread).
+5. **SDR / radio** — user má HackRF One a RTL-SDR (+ další). Zdroje
+   indexované v notes (sekce SDR/radio): GNU Radio World, PySDR.
+
+## Tuya WiFi čidla — DEFINITIVNÍ ZÁVĚR: slepý konec
+Data nelze dostat lokálně (HTTPS pinning, krátká spojení), jediná
+cesta: Tuya cloud API. Reflash nereálný (novější chipy), sniffing
+zamítnut. Všechny cesty (per-device poll, hromadný poll, Pulsar
+push) limituje samotný model „data musí projít Tuya cloud“ —
+kvóty Trial Edition (26k API volání/měsíc, 68k messages, 50 zařízení,
+bez overage) to neobejde žádným designem. Neškáluje.
+
+**Rozhodnutí:**
+- **Target = Zigbee (ZB Bridge Pro) + MQTT lokálně** — plná vlastní
+  režie, žádné kvóty. Alternativa: WiFi senzory ve vlastní režii
+  (ESP32 DIY) publikující přímo na MQTT.
+- Zpracování pravděpodobně HA, ale **ne nutně** — MQTT je neutrální
+  sběrnice, konzument cokoliv.
+- **tuya2mqtt bridge = legacy** — pro existující Tuya WiFi čidla,
+  dokud se nevymění. Jednou vymře.
+- Migrace postupná: čidlo umře / slabá baterie / špatné měření →
+  náhrada Zigbee/ESP32. Žádná aktivní hromadná náhrada zdravých čidel.
+- **Lekce: nekupovat další Tuya WiFi battery čidla.** Před nákupem
+  čidla ověřit, že data jdou v plné vlastní režii (MQTT-first,
+  žádný povinný cloud).
+
+**Pro reference (co jsme ověřili):**
+- Hromadný `/v1.0/iot-03/devices/status` — jen code/value, bez
+  timestampu, limit 20 IDs.
+- Per-device `GET /v1.0/devices/{id}` — status[] + `update_time` +
+  `online`; 10 čidel × 15 min ≈ 29k/měsíc — přes limitem.
+- Message Service (Pulsar push) — existuje, latence sekundy, ale
+  žere message kvótu (68k/měsíc) a při častém reportu ji vydře.
+- Pokud by se legacy bridge přece jen stavěl: Pulsar push primárně,
+  pomalý poll (1×/h) fallback, dedup na update_time.
+
+## Zigbee brána — rozhodnutí
+
+Požadavky: bez počítače na místě (žádný RPi, žádný server), okamžitě
+funkční po power-loss, žádný boot/maintenance, **WiFi nutně, Ethernet
+kabel nepoužitelný**. Max. zásah = přehrání firmware. NIC nestavíme.
+
+Kandidáti (network coordinator s WiFi):
+
+1. **SMLIGHT SLZB-06M / SLZB-06p10** — ETH+USB+WiFi v jednom, firmware
+   bez OS, vlastní web UI vč. remote flash, Z2M připojení
+   `tcp://<ip>:6638`. Nejrozšířenější v komunitě, oficiálně podporovaný
+   síťový adapter v Z2M.
+2. **SONOFF ZB Bridge Pro (ZBBridge-P)** — WiFi brána, potřebuje Tasmota
+   flash (EZSP, EFR32MG21), pak network coordinator pro Z2M přes
+   `tcp://ip:8888`. Levnější (~29 USD, OpenELAB), ale hacknutá cesta.
+3. **SONOFF ZBDongle-Max (Dongle-M)** — EFR32MG24 + ESP32, ETH/WiFi/USB,
+   síťový mód pro Z2M. Novější, méně zavedený. Cena ~43 USD
+   (sonoff.tech, ETH+PoE zaměřený — WiFi podporuje, ale je to spíš
+   PoE dongle).
+
+## Zigbee mesh — praktická zkušenost
+Mesh u náplňových čidel (CR2032) reálně **nefunguje**: čidlo se probudí,
+odvysílá a v tu chvíli nikdo jiný nevysílí, relay cesta nevzniká.
+Ověřeno prakticky mnohokrát. **Čidlo musí mít přímý dohled na
+coordinator**, jinak smolík. Umístění coordinatoru je kritické;
+případně více coordinatorů (každý s vlastní Z2M instancí).
+
+Preference: **SONOFF ZB Bridge Pro** — zvoleno. Kompaktní, ~29 USD,
+USB napájení, WiFi. Tradeoff: Tasmota flash (EZSP, EFR32MG21) nutný
+před použitím; pak network coordinator pro Z2M přes `tcp://ip:8888`.
+
+## Čidla fyzicky jinde — vyřešeno
+Zigbee: síťový coordinator umístěný pro rádiový dosah + mesh z
+mains-powered zařízení (routery). Náplňová čidla jsou end-devices.
+Matter: Wi-Fi čidla pokryje WiFi síť; Thread potřebuje OTBR
+(experimentální v HA, nižší preference než Zigbee).
+
+## Tuya WiFi čidla — otevřená otázka
+User by je chtěl používat (levná), ale: natvrdo vypálená HTTPS adresa
+(Tuya cloud), čidlo se na WiFi připojí jen krátce při vysílání.
+Lokální odběr dat tedy prakticky nemožný — data jdou do Tuya cloudu
+a ven se dostanou jen přes cloud API, nebo vůbec. Možnosti probrat:
+Tuya cloud API integrace (LocalTuya nefunguje na battery WiFi čidla),
+nahrazení firmware (ne vždy existuje), nebo se Tuya WiFi čidlům vyhnout.