nanobot: 2026-09-09 14:57:29

USER.md: +3 -0
1 file changed, 3 insertions(+), 0 deletions(-)

```diff
--- USER.md
+++ 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)
+
```

AGENTS.md

@@ -10,74 +10,33 @@ 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**
+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.
-(`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.
 
 ## Heartbeat Tasks
 
-`HEARTBEAT.md` is checked on the configured heartbeat interval. Use file tools to manage periodic tasks:
+`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.
-
-- **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.
 
 ## 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.
+- `develop/` — how this instance was extended and tuned (see `develop/README.md`); read on demand
-
+- `keep.md` — explicit user facts; read at every turn
-## Explicit user details
+- `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
-Explicit user facts are stored in `keep.md`. Read at every turn.
-
-## Projects (deep details)
-
-More details about the user, projects, hardware etc. live in `projects/<name>/` (memory.md, state.md) — search those too.
-
-## 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.
 
 ## 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.
-
 ## python — use uv
 
-For all Python code (scripts, snippets, one-liners, tools) use `uv`,
+For all Python code use `uv`, never `python` / `python3` / `pip` / `poetry` / `conda` directly. Details in `skills/python/SKILL.md`.
-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.
 
 ## File / Code Conventions
 
@@ -99,8 +58,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.
 
@@ -118,6 +75,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.

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

memory/.dream_cursor

@@ -1 +1 @@
-424
+425

projects/ai/memory.md

@@ -8,3 +8,15 @@ Uživatelova diagnóza: nedokáže správně popsat zadání; buď málo informa
 - 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í.

projects/ai/state.md

@@ -3,7 +3,18 @@
 ## Otevřená témata
 - Při hlášení nestabilit ověřit reálný model/preset (session metadata ho nezaznamenávají).
 
+## 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
+- 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/iot/memory.md

@@ -0,0 +1,58 @@
+- 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).

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,88 @@
+# 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).
+
+## 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.

scripts/timestamp.sh

@@ -0,0 +1,5 @@
+#!/usr/bin/env bash
+# Current timestamp for git commit messages (SQL format).
+# Exists because the exec safety guard false-positives on `date '+...%H:%M:%S'`
+# (the %H:%M:%S colons match the Windows drive-letter regex).
+date +%F_%T | tr '_' ' '

skills/cook/SKILL.md

@@ -3,8 +3,8 @@ name: cook
 description: >
   Capture and search recipes and tea notes (brewing parameters, origins, tasting
   notes) in the cook/ directory — one markdown file per item. Triggers on:
-  "cook: X", "zapiš recept X", "save recipe X", "co mám na X" (tea/food lookup),
+  "cook: X", "save recipe X", "what do I have for X" (tea/food lookup),
-  "čaj X", tea temperature/time questions against stored notes. For growing
+  "tea X", tea temperature/time questions against stored notes. For growing
   personal food & tea knowledge — not a one-off task or a durable user fact.
 ---
 
@@ -36,10 +36,10 @@ Subdirs are created by the script on first `add`.
 
 ```yaml
 type: recept | caj      # the only fixed value
-category: volná hodnota   # polévka, hlavní-chod / zelený, černý...
+category: free value     # soup, main-course / green, black...
-cuisine: volná            # recepts only
+cuisine: free value      # recepts only
-origin: volná             # caj only
+origin: free value       # caj only
-tags: [chata, zima]       # user hashtags, no '#'
+tags: [chata, winter]    # user hashtags, no '#'
 added: 2026-09-08        # auto
 ```
 
@@ -56,14 +56,17 @@ Taxonomy is deliberately free-form — it settles over time, don't force enums.
    `cook/` — never `git add -A`.
 4. Confirm the file path and quote what was filed.
 
-Language: user's (Czech), verbatim where sensible. New content appends **at
+Body language: the user's own (Czech), verbatim where sensible — the content
-the end** of a file; never insert into the middle.
+stays in whatever language the user sends. New content appends **at the end**
+of a file; never insert into the middle.
 
 ### Body formats — conventions, not rigid schemas
 
-Recipe: `# <název>`, **Ingredience**, **Postup**, **Zdroj**, **Poznámky**.
+Recipe: `# <name>`, **Ingredients**, **Steps**, **Source**, **Notes**.
-Tea: `# <název čaje>`, **Země/Typ/Teplota/Čas**, **Poznámky** (chuť, vůně,
+Tea: `# <tea name>`, **Country/Type/Temperature/Time**, **Notes** (taste,
-odkud koupeno). Adapt to what the user sends; don't force empty fields.
+smell, where bought). Adapt to what the user sends; don't force empty fields.
+Body section headings are free-form — match the user's language and material;
+the formats above are defaults, not enforced schemas.
 
 ## Search / answer