8.7 KiB
Memory
feedback: při deploymentu skillu synchronizovat celý adresář, ne jen scripts/
Při kopírování skillu na server vždy rsyncovat celý adresář skillu (např. skills/remind/), nikoli jen podadresář scripts/.
Why: 2026-05-29 — fix remind_edit.py byl rsyncem nasazen, ale SKILL.md s novou instrukcí ne. Agent proto stále četl starý SKILL.md a chybné chování přetrvávalo. Druhé kolo čištění dat bylo nutné zbytečně.
How to apply: rsync -av skills/remind/ nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/skills/remind/ — cílový rsync pokrývá vše (SKILL.md i scripts/). Nikdy nekopírovat jen podadresář, pokud si nejsi jistý, že ostatní soubory jsou beze změny.
feedback: Python skripty na serveru spouštět přes uv (PEP 723 + uv run --script)
Nové Python skripty v ~/.nanobot/workspace/ psát s shebang #!/usr/bin/env -S uv run --script a PEP 723 inline metadata (# /// script blok). Žádné přímé cesty do ~/.local/share/uv/tools/<tool>/bin/python jako shebang, žádné python3 s předpokladem správného venv.
Why: Uživatel explicitně řekl „python veci se maji spoustet pres uv" (2026-05-28, iterace #3 detach skillu). Důvod: uv-managed venv má izolaci, cache, a skript je portable — přežije reinstalaci tooly, upgrade Pythonu i přesun stroje.
How to apply: Pro každý nový stand-alone Python skript na serveru → PEP 723 hlavička. Pokud skript poběží přes user systemd unit, doplnit Environment=PATH=%h/.local/bin:/usr/bin:/bin do .service, jinak uv nebude v PATH. Detail pattern viz knowledge.md sekce „Python skripty na serveru".
feedback: zálohy serverových configů ukládat do ~/.nanobot/backup/
Před editací jakéhokoli configu na serveru (zejména ~/.nanobot/config.json) ukládej zálohu do adresáře ~/.nanobot/backup/, ne vedle původního souboru. Pojmenování s timestampem (např. config.json.bak-YYYYMMDD-HHMMSS).
Why: Uživatel to vyžádal 2026-06-02 po editaci context window presetů — záloha vedle configu (config.json.bak-*) zaneřáďuje .nanobot/ root. Centrální backup/ drží root čistý a zálohy pohromadě.
How to apply: mkdir -p ~/.nanobot/backup a cp config.json ~/.nanobot/backup/config.json.bak-$(date +%Y%m%d-%H%M%S) před in-place editem. Platí pro všechny serverové configy, které trackujeme/měníme.
feedback: po změně knowledge/history/memory synchronizovat do serverového develop/
Po každém commitu, který mění knowledge.md, history.md nebo memory.md, rsyncni daný soubor i do nanobot@nanobot.hell:/home/nanobot/.nanobot/workspace/develop/, aby měl serverový nanobot agent aktuální verzi (čte je on-demand jako referenci „jak byla instance rozšiřována a laděna").
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.